Jusletter IT

Im Jahre 2009 diskutierte der Gesprächskreis der 26ten Sylter Runde, das Thema «Finanzkrise und Informatik – Tragen IT-Anwendungen eine Mitschuld?». [Szyperski (2009)] Im Ergebnis dessen wurden IT-Anwendungen als «enabler» bezeichnet, durch welche der Zusammenbruch von Lehmann Brothers im Jahr davor und die darauf folgende Finanzkrise überhaupt erst möglich wurden. Dies kann dann leicht nachvollzogen werden, wenn man sich vor Augen führt, dass der Einsatz der modernen IuK-Technologie die Abwicklung einer Vielzahl von riskanten Finanztransaktionen unterstützte, ohne dabei auf die entstandenen Risiken reagiert oder auch nur auf möglichen Auswirkungen hingewiesen zu haben.

Damit IT-Anwendungen in der Zukunft nicht erneut die Rolle des «enablers» für eine Krise einnehmen, wurde von der Sylter Runde der Einsatz sachgerechter (IT-)Modelle gefordert, in denen die Auswirkungen der IT-Anwendungen berücksichtigt werden. Wären solche Modelle zu Grunde gelegt worden – so der Standpunkt  hätten möglichweise die Abwicklung hochriskanter Finanztransaktionen durch die IT-Anwendungen unterbunden werden können. So spekulativ diese Forderungen erscheinen mögen, das Memorandum verdeutlicht, dass bereits beim Entwurf der IT-Lösung die Auswirkungen des Einsatzes von IT-Anwendungen auch die Realwelt berücksichtigt werden sollten. Um dieser Forderung gerecht zu werden, muss zunächst der Umfang des zu lösenden Problems geklärt werden, was den Begriff des Anwendungssystems in den Vordergrund der Betrachtung rückt.

Der Begriff des Anwendungssystems  so wie er von den Autoren verstanden wird  spannt ein weites Feld der im Zuge der Entwicklung zu berücksichtigenden Aspekte auf. Angefangen beim Technologieträger (auf dem das IT-System untergebracht ist) reicht dieses bis hin zur betrieblichen Organisation (in dem die zu entwickelnde IT-Lösung eingesetzt wird). Damit umfasst das Anwendungssystem nicht nur Maschinen, sondern auch Menschen und deren Interaktion [Ferstl/Sinz (2006), S. 4], was zu einer ganzheitlichen Sichtweise auf das Problem der Entwicklung führt und verhindert, dass das zu entwickelnde Produkt nur einigen spezifizierten Anforderungen genügt. Vor allem aber verhindert eine solche Sichtweise auch, dass die Entwicklungsaufgabe allein als ein Problem der Softwareentwicklung betrachtet wird. Die im Zuge der Entwicklung somit zu berücksichtigende Aspekte sind so variantenreich wie die zugrundeliegenden Probleme, was es leider auch schwierig macht, genaue Vorgaben zu machen. Trotzdem lassen sich einige generische Perspektiven im Vorfeld bestimmen und beispielsweise der Aufteilung von Lonthoff bzw. Ortner entnehmen. [Lonthoff (2007), S. 13]

Allgemein lässt sich aus dieser entnehmen, dass die Anwendungssystemsoftware in aller Regel auf verschiedenen Basissystemen fußt, welche fachliche und oder grobgranulare technische Dienste anbieten, diese wiederum auf der Systemsoftware zum Betreiben der Hardware, der Hardware selbst und den jeweiligen Technologieträgern. Letztere werden nur all zu leicht bei der Lösungsfindung vergessen, dennoch sind auch diese ein wichtiger Bestandteil einer funktionierenden Lösung. Beispiele hierfür sind der Stoff auf dem ein Embedded Devices angebracht ist oder aber der tendenziell weiter verbreitete Fall eines Rack-Gehäuses in einem Rechenzentrum nebst der störungsfreien Energiezuführung und den zugehörigen Anlagen zum Kühlen.

Die im Rahmen dieses Papers herausgehobene Perspektive ist jedoch die Perspektive der Organisation, welche den allgemeinen Rahmen für das zu entwickelnde Produkt und die Schnittstelle zu den von der Entwicklung betroffenen Rechtsbereichen bildet. Der Rahmen bestimmt sich durch die Organisationsstruktur und dem damit verbundenen Rollenmodell, Weisungsbefugnissen und Informationsflüssen, aber auch den Zielen und Prinzipien der Organisation und insbesondere den in der Organisation ablaufenden Prozessen.

Der Umfang des Begriffs Anwendungssystem macht deutlich, dass die Anwendungssystem-Entwicklung nicht auf der grünen Wiese beginnt, sondern immer auf die bestehende Gegebenheiten Rücksicht nehmen muss. Damit kann das Problem nicht auf die Implementierung einer Software begrenzt werden, denn neben dieser Aufgabe müssen weitere Aufgaben, wie beispielsweise die Geschäftsprozessoptimierung, berücksichtigt werden. Folgt man dem Gedanken, darf die Automatisierbarkeit von Abläufen nicht wie zuweilen vorgeschlagen [Leist-Galanos (2006), S. 235] als Kriterium der Abgrenzung gesehen werden. Gleichzeitig darf man aber auch nicht darauf verfallen, die gesamte Organisation vollständig beschreiben zu wollen, da dies eine utopische und damit nicht lösbare Aufgabe ist. [Ortner (2000), S. 2-3]

Durch den bestehenden Kontext, der auch durch die Rahmenbedingungen des Entwicklungsprojekts definiert ist, sind die Entwickler in Bezug auf die mögliche Lösung eingeschränkt. Gleichzeitig sind aber die verschiedenen Perspektiven in der Entwicklung zu berücksichtigen, was zu einer erweiterten Modellierungs- und Entwicklungsaufgabe führt und die Lösungsfindung erschwert, sodass dass diese schrittweise konkretisiert werden muss. In diesem Sinne erscheint es ratsam, die Lösung über wiederholte Modellbildung inkrementell [Breedveld (1993), S. 209] zu verbessern.

Für diese Aufgabe bedarf es Modelle, die den Kontext der Entwicklung reflektieren. Modelle übernehmen aber in der Entwicklung auch andere Funktionen. [Fieber/Huhn/Rumpe (2008), S. 409] Zum einen helfen sie über die von Stachowiak identifizierte Verkürzungsfunktion [Stachowiak (1973), S. 131-133] die Entwicklungsaufgabe besser zu verstehen, zum anderen aber auch Lösungsalternativen fassbar zu machen. Hierdurch können gefundene Teillösungen kommuniziert und Sprachbarrieren verschiedener Spezialdisziplinen (BWL, IT, Recht) und Kulturunterschiede im Entwicklungsteam überwunden werden. [Breedveld (1993), S. 210] Eine Hauptaufgabe besteht jedoch in der oben beschriebenen Möglichkeit sich an die wirkliche Lösung über Abstraktionsebenen heranzutasten. Am Ende dieser Entwicklung übernehmen Modelle dann eine weitere Funktion, indem sie als Konstruktionsplan eine Vorlage zur Realisierung der Lösung darstellen. Damit ist «das Modell» der maßgebliche Garant für das «fachliche Funktionieren» der IT-Lösung.

Normen und Gesetze sind immer dann ein Problem, wenn sich diese widersprechen. Dies erfolgt leicht bei international diversifizierten Unternehmen, die in verschiedenen Rechtsräumen agieren bei gleichzeitigem Einsatz betriebswirtschaftlicher Anwendungssysteme. Diese Probleme können offensichtlich sein, wie zum Beispiel bei der Rechnungslegung nach HGB, IAS oder US-GAAP, aber auch verdeckt im Falle von Kulturunterschieden, welche ebenfalls als Normen begriffen werden können. Beispiele hierfür sind die Preisfindung oder das Berichtswesen. [Bayer (2006), S. 32] Verstöße gegen Normen reduzieren die Qualität der Lösung und führen kurz- und mittelfristig zu finanziellen Einbußen und oder setzen die Organisation erheblichen juristischen Risiken aus, was die Fokussierung und die Suche nach einer umfassenden Lösungen, möglicherweise auf Basis von Varianten, rechtfertigt.

Es soll aber nicht verschwiegen werden, dass der Aufwand zum Erstellen einer solchen fachlichen Lösung hoch sein kann, die finanziellen Mittel und der personelle (Zeit-)Aufwand für den Transfer von Wissen sollte vom Auftraggeber trotz allem nicht gescheut werden. Die Kosten für die Prüfung können dann reduziert werden, wenn die Prüfung der Modelle schematisiert oder gar automatisiert werden kann. So kann die rechtliche Konformität der betrieblichen Prozesse forciert werden, falls es im Vorfeld gelingt, Regeln für die Modellierung aufzustellen. Ein Beispiel hierfür ist die Methode der anforderungskonformen Prozessmodellierung und Motivation (aPM²). [Link (2012)].

Sind die ablauforganisatorischen Fragestellungen umfassend geklärt, kann ein Anwendungssystem normiert und kontrolliert werden, weil die umfassende «von Lieferant zu Kunde» Sichtweise auf nahezu alle Unternehmensbereiche ausstrahlt. Dies gilt insbesondere auch für die bereits als kritisch identifizierten rechtlichen Fragestellungen.

Kontrolle der Abläufe kann im Falle betriebswirtschaftlicher Anwendungssysteme mit der Kontrolle des Anwendungssystems gleichgesetzt werden. Diese prozesszentrische Sichtweise fußt auf dem Konzept von Schema und Ausprägung und der Idee, dass wenn immer etwas unter ein Schema gebracht, dies auch kontrolliert und genutzt werden kann (frei nach Kamlah und Lorenzen [Kamlah/Lorenzen (1992), S. 58]). Demnach liegt der Schlüssel der Kontrolle im Beschreiben des Sollzustands.

In Bezug auf Abläufe hat es hierzu in der Vergangenheit verschiedene Ansätze aus verschiedenen Fachdisziplinen gegeben, die auf Basis unterschiedlicher Modellierungssprachen versucht haben, die Abläufe fachlich und oder technisch zu beschreiben (Wertekettendiagramme, Netzplantechniken, Arbeitsablaufkarten, IDEF, Aktivitätsdiagramme, Flussdiagramme oder Arbeitsablaufbeschreibungen nach Henning). Dies aber nur mit mäßigem Erfolg, weil die mit den Modellierungssprachen verfolgten Ziele teilweise zu «eng gesteckt» wurden und sich vornehmlich an den Bedürfnissen der jeweiligen Fachdisziplin ausgerichtet haben. Mit den (erweiterten) Prozesskettendiagrammen (e)PKs und spätestens mit dem Aufkommen der BPMN hat sich das leicht verändert, sodass die Abläufe mit Hilfe dieser Modellierungssprachen nun tendenziell umfassend und einheitlich beschrieben werden können. Da bei diesen beiden Notationen aber auch durch IT-Systeme verarbeitet werden können, stellen sie eine geeignete Basis zur Spezifikation der betrieblichen Abläufe im Rahmen der Anwendungssystem-Entwicklung dar.

Der typische Planungskreislauf lehrt uns, dass der Planung die Überwachung folgt. [Ulrich/Fluri (1995)] Übertragen auf die obige Problemstellung der Kontrolle des Anwendungssystems bedeutet dies, dass mit der Erstellung der Ablaufbeschreibung gleichzeitig auch Instrumente zu deren Überwachung geschaffen werden müssen. Eine solche ist nicht einfach einzurichten und bindet Personal zur Erhebung von Informationen und Treffen von Anordnungen, sodass dies aller Regel nach nur auszugsweise erfolgt.

Dies ändert sich mit einem direkten IT-Bezug. Denn mit der Anwendungssystem-Software – als wesentliches Element des Anwendungssystems  werden Teile des Ablaufs in «Silizium gegossen» und können damit nicht mehr ohne weiteres vermieden werden [Gaitanides (2007), S. 3], sofern die handelnden Subjekte bei der Erledigung ihrer Aufgaben auch auf die Anwendungssystem-Software angewiesen sind. Das heißt aber auch, dass wenn das Modell des Ablaufs korrekt und rechtlich einwandfrei formuliert wurde, sich «automatisch» ein Normenkonformes Handeln der Betroffenen ergibt. [Heinemann (2013)] Dieser Sachverhalt wird heute allgemein auch oft mit Compliance bezeichnet, wobei es sich hierbei jedoch um einen insgesamt vagen Begriff handelt. [Bayer (2006), S. 61-62] Ein normenkonformes Handeln wird dann zumindest überall dort erreicht, wo die Anwendungssoftware eingesetzt wird oder zumindest steuernd auf den Ablauf Einfluss nimmt. Im Umkehrschluss dazu muss eine «Software» aber auch gewissenhaft entworfen werden, damit es nicht zu wiederholten Regelverstößen kommt. Modelle stellen hierbei das wichtigste Entwicklungsartefakt dar. [Fieber/Huhn/Rumpe (2008), S. 409] Die «IT» ist in diesem Fall aber nicht nur ein Mittel für die Einhaltung von Regeln, sie ist auch ein Akzelerator, der die Ablaufausführung beschleunigt. Demnach kann es im Falle einer fehlerhaft konzipierten Lösung auch zu einem regelmäßigen Verstoß gegen Normen kommen, was es unbedingt zu vermeiden gilt.

Ein Beispiel für mögliche Probleme ist der insgesamt noch leicht überblickbare Freizeichnungsprozess für Lieferantenrechnungen. In diesem sind Rechnungen von verschiedenen Kostenstellenverantwortlichen im Hinblick auf ihre sachliche Korrektheit zu bewerten und für die Zahlung «freizugeben». Der an sich zunächst simpel anmutende Sachverhalt berührt verschiedene organisationsexterne, -interne und kulturelle «Normen». Dies sind steuerrechtliche Anforderungen an die Gestaltung und den Inhalt der jeweiligen Rechnung, die Anforderungen des Strafrechts im Zuge der «Korruptionsbekämpfung», aber auch organisationsinterne Vorgaben.

Ein strukturierter Ablauf beschränkt die Freiheiten des Einzelnen in der Ausübung seiner Arbeit. Diese wird zu einem kulturellen Problem, wenn dies die Betroffenen nicht «gewohnt» sind. Möglicherweise sogar zu einem Zielkonflikt, wenn demselben Personenkreis freie Lieferantenauswahl zugesichert wurde, der Prozess jedoch die Freigabe der Rechnung durch eine andere Person erfordert und damit die Lieferantenauswahl hinterfragt. Dies verhindert ebenso die Möglichkeit für die Straftatbestände der Vorteilsnahme und Vorteilsgewährung. Die Liste der Konflikte ließe sich leicht erweitern, soll aber auf die genannten beschränkt werden, da bereits hier deutlich werden kann, wie die IT-Lösung dem Problem begegnet. Denn durch den Einsatz von IT kann ein mehrstufiges «Vier-Augen-Prinzip» so realisiert werden, dass der Ablauf für die betroffenen Sachbearbeiter auch dann handhabbar bleibt, wenn es erforderlich ist, die zur Freigabe herangezogenen Personen in Abhängigkeit der Kostenstelle, der Kostenart oder auch des Rechnungsbetrags auszuwählen. Automatisch generierte Berichte erlauben Kontrollen, wie das systematische Unterlaufen von Bagatellgrenzen, die bei einem manuellen Verfahren nicht ohne hohen Personalaufwand möglich sind und deshalb meistens vermieden werden.

Ein großes Problem einer umfassenden Herangehensweise ist es, dass durch die ganzheitliche Sichtweise die zu lösenden Probleme aufgrund der hohen Zahl an Interdependenzen stark zunehmen. Konsequent zu Ende gedacht ist die Aufgabe dann auch meistens nicht mehr für eine gegebene Menge an Ressourcen lösbar. Dies muss verhindert werden wenn Entwicklungs-Projekte nicht bereits im Keim zum Scheitern verurteilt werden sollen. Das heißt, es müssen im Vorfeld des Projektes innerhalb der Rahmenbedingungen unantastbare Bereiche formuliert werden, die aus Sicht des Entwicklungsprojekts ein Datum darstellen und damit unveränderlich sind. Hierbei ist Fingerspitzengefühl gefragt, denn grenzt man das Handlungsfeld zu sehr ein, bleibt von der angestrebten ganzheitlichen Betrachtung nicht viel übrig.

Der bei der Lösung betrachtete Rahmen sollte also umfassend gewählt werden, gleichzeitig muss aber nicht jedes identifizierte Problem im Rahmen des Entwicklungsprojektes auch zwangsweise vollständig ausmodelliert oder gar umgesetzt werden. Es besteht meist die Möglichkeit, die identifizierten Probleme «aufzuschieben» und erst in anderen Projekten anzugehen, womit der Maxime gefolgt wird, dass es klüger ist, Probleme zu erkennen und bewusst nicht anzugehen (sofern möglich), als komplett ohne Modellierung, d.h. ohne Kenntnis des Kontextes, zu entwickeln.

Im Idealfall kann man bei der Entwicklung der fachlichen Lösung auf bestehende Modelle zurückgreifen und somit den Entwicklungsaufwand stark reduzieren, sofern hier die notwendigen technischen (Dateiformate) und inhaltlichen Gegebenheiten (Modellqualität, Normsprache, Systematischer Entwurf) vorgefunden werden können. Eine Einsparung ergibt sich auch dann, wenn man im Zuge der Entwicklung auf Referenzmodelle und oder Standardsoftware zurückgreifen kann.

Der Aufwand für die fachliche Modellbildung muss grundsätzlich als Versicherung für ein gerichtetes und planvolles Vorgehen gesehen werden und deren Ergebnisse dürfen nicht alleinig dem jeweiligen Entwicklungsprojekt angelastet, sondern sollten als Aufwendungen für die Organisationsentwicklung gewertet werden. Je qualitativ besser das Modell ist, desto langfristiger kann man von diesen profitieren.

Unter Qualität ist nach DIN ISO 9000:2005 ganz allgemein der Grad zu verstehen, in dem objektiv bewertbare Merkmale (Eigenschaften) erfüllt werden. [DIN (2005), S. 13] Auf Modelle bezogen bedeutet dies, dass die Modellqualität dadurch bestimmt wird, in welchem Maße die Modellmerkmale den geforderten bzw. erwünschten Merkmalen entsprechen. Eine Unterteilung der Merkmale findet sich bei den Grundsätzen ordnungsmäßiger Modellierung, welche beispielsweise den Grundsatz der Richtigkeit vorsehen. Dieser fordert die syntaktische (formale) und semantische (inhaltliche) Richtigkeit eines Modells. [Becker/Rosemann/Schütte (1995), S. 437-478]

Syntaktisch oder formal korrekt bedeutet, dass die verwendeten Modellierungsobjekte in der Modellierungssprache definiert und die Notationsregeln der Modellierungssprache eingehalten werden. Durch die Einhaltung der formalen Vorgaben wird es ermöglicht, dass das Modell von jeder Person die die Modellierungssprache beherrscht, richtig interpretiert werden kann. Ob ein Modell inhaltlich angemessen ist, wird durch die Semantik bzw. den Inhalt des Modells bestimmt. Was inhaltlich richtig ist, ergibt sich aus einem Konsens zwischen Modellierer und den Stakeholdern (Modellnutzer) und in Abhängigkeit des Kontextes. [Fieber/Huhn/Rumpe (2008), S. 413] Das Modell eines Geschäftsprozesses kann den Ablauf eines Buchhaltungsprozess darstellen, was jedoch inhaltlich nicht korrekt wäre, falls tatsächlich ein Inventurprozess beschrieben wird.

Werden Modelle als Konstruktionsbeschreibungen gesehen, beispielsweise von Prozessen, dann handelt es sich um eine sprachliche Beschreibung und somit um Sprachartefakte. [Wedekind/Görz/Kötter/Inhetveen (1998), S. 265-272] In Anlehnung an die Semiotik (Zeichenlehre) [Morris (1972), S. 32-68] gibt es neben den bereits behandelten Dimensionen der Syntax (formal) und Semantik (Inhalt) zusätzlich eine dritte, die pragmatische Dimension, welche von Zeichen auch auf Sprachartefakte übertragen werden kann und als die Wirkung des Sprachartefaktes zu verstehen ist. [Ortner (2005), S. 63-65] Die Fragestellung die sich aus dieser Dimension ergibt ist, ob das Modell pragmatisch gerechtfertigt ist, was durch die Wirkung der Modelldarstellung und der Wirkung des Modellinhalts bestimmt wird. Sowohl für die Modelldarstellung, als auch für den Inhalt kann jeweils hinterfragt werden, ob die vom Modellierer gewünschte Wirkung erzielt wird (Effektivität) und ob dies auf optimale Weise (Effizienz) geschieht. Bezogen auf die vorgebrachten Beispiele sind dies Fragestellungen, ob durch ein Modell geltendes Recht und die Normen einer Gesellschaft ausreichend berücksichtigt werden und zwar bezogen auf die Modelldarstellung und den Modellinhalt.

Die Effektivität der Modelldarstellung beschreibt, ob die Darstellung des Modells in der Praxis den gewünschten Zweck erfüllt. Hierbei sind die Lesbarkeit und Verständlichkeit des Modells durch den Modellnutzer sowie rechtliche und gesellschaftliche Vorgaben zu berücksichtigen. Beispielsweise wenn ein Prozessmodell als Arbeitsplan eingesetzt wird. Die Darstellung ist dann effektiv, wenn der Mitarbeiter das Modell versteht und seine zu leistenden Arbeitsschritte daraus ableiten kann. Versteht der Mitarbeiter aber das Modell nicht, da es z.B. in einer ihm nicht bekannten (Modellierungs-)Sprache erstellt wurde, kann er die Arbeitsschritte nicht erkennen. Die Modelldarstellung ist in diesem Fall nicht effektiv einsetzbar. Neben sprachlichen Aspekten sind rechtliche Rahmenbedingungen für die Effektivität einer Modelldarstellung relevant. Werden in der Darstellung unangemessene oder verbotene Zeichen eingesetzt, dann ist diese Modelldarstellung unabhängig davon ob der Inhalt verstanden wird, «effektiv» nicht einsetzbar.

Unter der Effektivität des Modellinhalts ist zu verstehen, dass das Modell entsprechend seinem Zweck in der Realwelt eingesetzt werden kann. Bei einem Prozessmodell, das als Arbeitsplan eingesetzt wird, kann die Darstellung effektiv sein. Bezogen auf den obigen Fall kann der Mitarbeiter den Arbeitsplan möglicherweise zwar verstehen, aber aufgrund der gegeben Rahmenbedingungen den Ablauf inhaltlich effektiv nicht umsetzen. Dabei kann es sich beispielsweise um Modellierungsfehler aufgrund unberücksichtigter Rahmenbedingungen handeln. Exemplarisch sei hier auf die am Einsatzort geltenden gesetzlichen Vorschriften verwiesen, gegen die ein Prozessmodell verstoßen kann. Der Inhalt des Modells, wäre in diesem Fall nicht «effektiv» einsetzbar.

Unter der Effizienz einer Modelldarstellung ist zu verstehen, dass eine Modelldarstellung effizienter als eine andere ist, sofern erstere im Hinblick auf ein gewähltes Effizienzkriterium vorteilhafter ist. Dies lässt sich auch hier leicht an einem Prozessmodellbeispiel aufzeigen. Damit ein in BPMN modellierter Prozess im Rahmen der Softwareentwicklung zur Spezifikation der betrieblichen Prozesse eingesetzt werden kann, muss der Mitarbeiter zur Nachvollziehbarkeit des Modells die Modellierungssprache zunächst erlernen und die Möglichkeit haben «gegenzusteuern», falls sich die Entwicklung in die falsche Richtung bewegt [Rupp (2001) S.4]. Liegt das Prozessmodell dagegen in einer für den Mitarbeiter verständlichen Sprache vor, kann der Mitarbeiter das Modell in natürlicher Sprache lesen und es in diesem Fall ohne zusätzlichen Ausbildungsaufwand verstehen.

Ein in natürlicher Sprache vorliegendes Prozessmodell ist bezogen auf das Effizienzkriterium «Ausbildungskosten» effizienter als eines in BPMN, da bei ersterem der Ausbildungsaufwand für den Mitarbeiter entfällt und somit ein geringerer Kostenaufwand entsteht. Andererseits lassen sich BPMN-Diagramme beschränkt zwischen IT-Systemen austauschen und so Entwicklungsergebnisse wiederverwenden, was sie für die Entwicklung effizienter macht als proprietäre Notationen.

Analog zu der Effizienzbetrachtung von Modelldarstellungen kann eine solche Betrachtung ebenso für die Inhalte verschiedener Modelle durchgeführt werden. Bei Prozessmodellen kann die Effizienz beispielsweise anhand der Anzahl der Prozesschritte bewertet werden. Kommt ein Modell mit weniger Schritten für die Durchführung eines Prozesses aus, ist es im Hinblick auf die «Anzahl der Prozesschritte» effizienter als ein anderes Modell, welches für den gleichen Prozess mehr Schritte benötigt.

Bei der Entwicklung von IT-Lösungen (Prozesse und Software) hat sich in den letzten Jahren der Einsatz von agilen Vorgehensmodellen etabliert. Bei einer Umfrage von Analysis.Net Research und Version One, bei der 6.000 Personen aus verschiedenen Bereichen der Softwareentwicklungsindustrie befragt wurden, gaben 80% der Befragten an, dass in ihren Unternehmen agile Methoden bei der Softwareentwicklung zum Einsatz kommen [Version One (2011)].

Ein Vorteil, den Unternehmen wie die SAP AG in den agilen Vorgehensmodellen wie beispielsweise Scrum sehen ist, dass eine Anpassung des zu erreichenden Ziels bei Auftreten von Veränderungen einfach durchgeführt werden kann. Ein möglicher Grund für das Auftreten von Veränderungen ist, dass zu Beginn eines Entwicklungsprojekts nicht alle Rahmenbedingungen bekannt sind und diese erst im Laufe des Projektes präzisiert werden können. Wird beispielsweise eine Gesetzesänderung oder ein neues Gesetz relevant, welches zu Beginn des Entwicklungsprojektes nicht bekannt oder berücksichtigt wurde, könnte dies zu einer Anpassung der gerade in Entwicklung befindlichen IT-Lösung führen. Agile Entwicklungsmodelle sind darauf ausgelegt, mit Änderungen und Zielanpassungen umzugehen [Coldewey (2002), S. 70-77], wie es nachfolgend am Beispiel von Scrum deutlich wird.

Die agilen Methoden unterscheiden sich von den klassischen nicht nur dadurch, dass eine schnelle Reaktion bei Änderungen möglich ist. Vielmehr basieren agile Vorgehensmodelle auf anderen Werten als die klassischen. Änderungen werden im Sinne einer agilen Entwicklung als etwas Positives empfunden, da die Änderung hilfreich und notwendig ist, damit das gewünschte (geänderte) Ziel erreicht werden kann. In der klassischen Entwicklung wird dagegen eine Änderung meist als negativ empfunden, denn diese führt zu einer Abweichung vom ursprünglichen Plan. Die Werte auf denen die agilen Entwicklungsmethoden beruhen, sind in dem agilen Manifest beschrieben. [Agile Alliance (2001)] Dort gilt beispielsweise, dass die Fähigkeit auf Änderungen zu reagieren wichtiger und wertvoller ist, als die Fähigkeit einen Plan verfolgen zu können [Coldewey (2002), S. 70-77].

Bezogen auf die agile Softwareentwicklung ist die Aufgabe der Modellierung die Erstellung formal und inhaltlich korrekter Konstruktionsbeschreibungen einer pragmatisch gerechtfertigten IT-Lösung. Dies setzt wie beschrieben voraus, dass der Kontext durch die IT-Lösung berücksichtigt ist.

Da Modelle die Grundlage für die Entwicklung der IT-Lösung sind, sollten die Rahmenbedingungen und deren Änderungen bereits in den Modellen berücksichtigt werden, denn nur was modelliert ist, wird auch realisiert. Aus Sicht der Modellierung ergibt sich daraus die Forderung, dass eine einmalige Modellierung der IT-Lösung oder gar nur einzelner Bestandteile nicht ausreichend ist. Stattdessen ist es notwendig, die Modelle während des gesamten Entwicklungsprozesses ständig anzupassen, um den geänderten Rahmenbedingungen Rechnung zu tragen.

Maßnahme 1: Qualitätsmerkmale in einem Katalog zusammenfassen

Aus den vorangegangenen Ausführungen lässt sich ableiten, dass die Qualität von Modellen durch formale, materiale (inhaltliche) und pragmatische Merkmale bestimmt wird. Das Erstellen eines Katalogs mit Anforderungen an das Modell aus all diesen Bereichen ist hilfreich, gibt dem Modellierer eine Orientierung und sensibilisiert ihn auf die eingangs diskutierten Aspekte, die die Qualität seiner Modelle beeinflussen. Ein Auflistung von Merkmalen ist beispielsweise bei Kneuper [Kneuper (2011), S. 467] zu finden, der diese für qualitative gute Prozessmodelle ausgearbeitet hat, Röder et al. [Röder (2009)] stellt einen vergleichbaren Katalog für Anforderungsspezifikationen vor. Zusätzlich kann ein solcher Katalog als Basis für die Ableitung von Qualitätsmaßnahmen dienen, indem für alle im Katalog aufgeführten Merkmale Testfälle erstellt werden.

Maßnahme 2: Einsatz von Modellierungssprints

Die Möglichkeit bei agilen Vorgehensmodellen flexibel mit Änderungen umgehen zu können bedeutet nicht, dass der Entwicklungsprozess unstrukturiert abläuft und das die Modellierung vernachlässigt oder auf diese gar verzichtet werden kann. Es gilt für die klassischen und für die agilen Vorgehensmodelle der Grundsatz, dass vor der Realisierung zuerst modelliert werden muss, damit die Entwicklungsinhalte klar definiert sind und dadurch einer «Bastlerlösung» entgegengewirkt werden kann. Die Modellierungsaufgabe kann bei Scrum in den Produkt- und Sprintbacklog aufgenommen werden und durch die Priorisierung als eine der Realisierung vorgelagerte Aufgabe eingestuft werden. Besteht, beispielsweise zu Beginn eines Entwicklungsprojektes ein großer Modellierungsbedarf, können ein oder mehrere «Modellierungssprints» durchgeführt werden, in denen ausschließlich Modellierungsaufgaben bearbeitet werden.

Maßnahme 3: Pragmatische Rechtfertigung als Qualitätsmerkmal berücksichtigen

Durch den Einsatz der IT-Lösung in der Realwelt ist eine Überprüfung möglich, ob die Lösung pragmatisch gerechtfertigt ist oder ob möglicherweise Rahmenbedingungen nicht berücksichtigt wurden. Dem Grundsatz folgend, dass erst nach der Modellierung die Realisierung folgt, müssen identifizierte Einschränkungen aufgedeckt werden, damit der Modellierer die zugrundeliegenden Modelle anpassen kann. Nach Anpassung der IT-Lösung ist letztlich eine erneute Überprüfung der pragmatischen Merkmale möglich. Von großer Bedeutung ist hierbei, dass die IT-Lösung auf deren pragmatische Wirkung hinterfragt wird. Bestenfalls ist der Test der pragmatischen Merkmale als Bestandteil des Entwicklungsvorgehensmodells instrumentalisiert, indem die Aufgabe für einen solchen Test für jede Entwicklungsaufgabe in den Sprintbacklog aufgenommen wird.

Maßnahme 4: Durchhalten des Grundsatze «erst Modellierung, dann Realisierung»

Ein Problem kann das Durchhalten des Grundsatzes «erst modellieren, dann realisieren» sein, wenn mitten in der Entwicklungszeit nach einem Einsatztest der IT-Lösung ein großer Änderungsbedarf ansteht. Die Durchführung eines notwendigen Modellierungssprints verlängert die Entwicklungszeit, dies gefährdert möglicherweise einen vertraglich vereinbarten Fertigstellungstermin. In solchen Situationen sollte berücksichtigt werden, dass der Verzicht auf einen Modellierungssprint dazu führt, den Weg einer zielorientierten Entwicklung zu verlassen. Daher sollte nach anderen erstrebenswerten Lösungen gesucht werden. Denkbar wäre, über eine andere Art der Vertragsgestaltung zu diskutieren und zwar eine solche, die im Sinne aller Beteiligten eine zielorientierte Entwicklung erlaubt. [Stevens (2009)]

Es wurde gezeigt, dass im Falle betriebswirtschaftlicher Anwendungssysteme der fachlichen Modellbildung eine entscheidende Bedeutung zukommt. Hier stehen insbesondere die betrieblichen Prozesse im Vordergrund, welche insbesondere auch vor dem Hintergrund rechtlicher Fragestellungen sorgfältig entworfen werden müssen. Da diese zumindest in Teilen durch die IT-Lösung automatisiert werden, ergibt sich hierdurch die Möglichkeit der Ausrichtung des gesamten Anwendungssystems.

Dadurch erhöht sich die Verantwortung der «IT» für den Erfolg der gesamten Organisation. Die Überführung der fachlichen Lösung in eine IT-Lösung bringt den Vorteil mit sich, dass hierdurch die geplanten Abläufe und damit die Einhaltung geltender Normen tendenziell besser kontrolliert werden können. Die besondere Berücksichtigung fachlicher Belange in der Anwendungssystem-Entwicklung ist ein wesentlicher Faktor für eine qualitativ gute Entwicklung.

Nur durch die Berücksichtigung der pragmatischen Aspekte kann gewährleistet werden, dass nach der Entwicklung der Einsatz der IT-Lösung im Anwendungssystem wie erwartet funktioniert. Dies stellt eine Herausforderung dar, weil das Qualitätsbewusstsein der Entwicklungsteams formale, inhaltliche und pragmatische Kriterien umfassen muss.

Aufgrund der hohen Flexibilität der agilen Entwicklungsmethoden werden diese Untersuchungen bei Anwendung des SCRUM-Ansatzes durchgeführt. Herausforderung und Ziel ist es, in einem agilen Umfeld durch die Modellierung eine zielführende und mit einem ganzheitlichen Qualitätsbewusstsein verbundene Vorgehensweise auszuarbeiten. Das Paper gibt Hinweise darauf, wie dieses Ziel erreicht werden kann.

Agile Alliance; Manifesto for Agile Software Development, http://www.agilealliance.org/ aufgerufen: 21.11.2012 (2001).

 

Bayer: Welches ERP-System soll ans Ruder? In: Computerwoche (30), S. 32 (2006).

 

Becker/Rosemann/Schütte; Grundsätze ordnungsmäßiger Modellierung, Wirtschaftsinformatik Heft 37, S. 437-438 (1995).

 

Breedveld: Computer-aids for modelling and conceptual design. In: IEEE Systems Man & Cybernetics Society (Hg.): Systems Engineering in the Service of Humans 1993. Proceedings of the International Conference on Systems, Man, and Cybernetics; New York, NY., S. 209 (1993).

 

Coldewey; Multi-Kulti: Ein Überblick über die agile Entwicklung, Objektspektrum 1, S. 70-77 (2002).

 

Deutsches Institut für Normung; Qualitätsmanagementsysteme; DIN 9000:2005 Qualitätsmanagementsysteme – Grundlagen und Begriffe, Berlin, S. 13 (2005).

 

Ferstl/Sinz: Grundlagen der Wirtschaftsinformatik. 5., überarb. und erw. Aufl. München: Oldenbourg., S. 4 (2006).

 

Fieber/Huhn/Rumpe: Modellqualität als Indikator für Softwarequalität. Eine Taxonomie. In: Informatik-Spektrum 31 (5), S. 409 (2008).

 

Gaitanides: Prozessorganisation. Entwicklung, Ansätze und Programme des Managements von Geschäftsprozessen Vahlen, München (2007)

 

Gloger; Scrum – Produkte zuverlässig und schnell entwickeln, Carl Hanser, München, S. 9-11 (2009).

 

Heineman: Der Fall Bettina W. oder: Vom Versuch, einen Algorithmus zu verklagen. Vortrag IRIS2013, Salzburg (2013).

 

Kamlah/Lorenzen: Logische Propädeutik. Vorschule des vernünftigen Redens. 2., verb. und erw. Aufl. Mannheim, S. 58 (1992).

 

Kneuper; Was ist eigentlich Prozessqualität, Informatik 2011, Lectures Notes in Informatics, S. 467 (2011).

 

Leist-Galanos: Methoden zur Unternehmensmodellierung. Vergleich, Anwendungen und Diskussion der Integrationspotenziale. Berlin: Logos-Verl., S. 235 (2006).

Link: Anforderungskonforme Prozessmotivation. Ein stufenweiser Ansatz zum anforderungskonformen Prozessmanagement mit BPMN. Technische Universität Darmstadt, Darmstadt. (2012).

 

Lonthoff: Externes Anwendungsmanagement. Dissertation. TU-Darmstadt, Darmstadt., S. 13 (2007).

 

Morris; Grundlagen der Zeichentheorie, Hanser, München, S. 32-68 (1972).

 

One/Analysis.Net Research; State of agile survey 2011, http://www.versionone.com/state_of_agile_development_survey/10/ aufgerufen: 21.11.2012 (2011).

 

Ortner; Sprachbasierte Informatik: Wie man mit Wörtern die Cyber-Welt bewegt, Edition am Gutenbergplatz, Leipzig, S. 19-20, 63-65 (2005).

 

Ortner: Terminologiebasierte, komponentenorientierte Entwicklung von Anwendungssystemen. In: Rony G. Flatscher und Klaus Turowski (Hg.): Proceedings des 2. Workshop komponentenorientierte betriebliche Anwendungssysteme (WKBA 2). Wien, S. 2–3 (2000).

 

Röder/Franke/Müller/Przybylski; Ein Kriterienkatalog zur Bewertung von Anforderungsspezifikationen, Softwaretechnik-Trends, Band 29, Heft 4, (2009).

 

Rupp: Requirements Engineering. Der Einsatz einer natürlichsprachlichen Methode bei der Ermittlung und Qualitätsprüfung von Anforderungen. Fachtagung zur Software-Qualitätsmanagement in der Praxis vom 18. Mai 2001. Wien, S. 4 (2001).

 

Stachowiak: Allgemeine Modelltheorie, Springer, Wien, S. 131-133 (1973).

 

Stevens; Peter Stevens Blog on agilesoftwaredevelopment.com, http://agilesoftwaredevelopment.com/blog/peterstev/contracting-agile-software-projects aufgerufen: 21.11.2012 (2009).

 

Szyperski, Memorandum der 26ten Sylter Runde. http://www.sylter-runde.de/mediapool/6/63715/data/SR_26_Finanzkrise_IT_Download.pdf aufgerufen: 21.11.2012 (2009).

 

Technum; ComTOOLs BPMN-to-Text. http://technum.metainformationen.de aufgerufen: 21.11.2012 (2010).

 

Ulrich/Fluri: Management. Eine konzentrierte Einführung. 7., verb. Aufl. Bern, S. 107 (1995).

 

Wedekind/Görz/Kötter/Inhetveen; Modellierung, Simulation, Visualisierung: Zu aktuellen Aufgaben in der Informatik, in Informatik-Spektrum 21, S. 265-272 (1998).

 

---

 

Sascha Alber, SAP AG.

 

Marcus Elzenheimer, Technische Universität Darmstadt, Fachgebiet Entwicklung von Anwendungssystemen.

 

---