Informationsflussoptimierung eines Softwareentwicklungsprozesses aus der Bankenbranche

Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Informationsflussoptimierung eines Softwareentwicklungsprozesses aus der Bankenbranche Masterarbeit im Studiengang Informatik von Kai Stapel Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Nicola Henze Hannover, 18.10.2006

Erklärung Hiermit versichere ich, dass ich die vorliegende Masterarbeit selbständig und ohne fremde Hilfe verfasst und keine anderen als die in der Arbeit angegeben Quellen und Hilfsmittel verwendet habe. Hannover, 18.10.2006 Kai Stapel II

Zusammenfassung Geschäftsprozessmodelle werden seit geraumer Zeit in der Softwareentwicklung benutzt, um Ergebnisse wiederholbar, Erfahrungen wieder verwendbar, die Projektdauer vorhersagbar und die entwickelte Software qualitativ hochwertiger zu machen. Insbesondere in großen, schon lange existierenden IT-Unternehmen sind diese Prozessmodelle meist historisch gewachsen und sehr umfangreich. Bedingt durch ihre Entstehung und ihre Größe beinhalten die Prozessmodelle viele Fehler. Ein Unternehmen versucht daher ständig diese Fehler zu beseitigen und damit das Geschäftsprozessmodell zu optimieren. Ziel der vorliegenden Masterarbeit ist es, einen als Prozessmodell vorliegenden Softwareentwicklungsprozess eines großen IT-Unternehmens aus der Bankenbranche in Bezug auf die darin enthaltenen Informationsflüsse zu optimieren. Dazu wurde sich zunächst mit den Begriffen Information, Informationsfluss, Dokument und Dokumentenfluss auseinandergesetzt. Dies war notwendig, um die eigentliche Aufgabe genauer abgrenzen zu können. Eine Optimierung des Prozessmodells wurde durch die Schaffung von Möglichkeiten zur Analyse von Dokumentenflüssen und Informationsflüssen, durch das Aufzeigen von Problemstellen und deren Visualisierung und durch Optimierungsvorschläge unterstützt. III

Inhaltsverzeichnis Abbildungsverzeichnis...VI Tabellenverzeichnis...VIII 1 Einleitung... 1 1.1 Problemstellung... 1 1.2 Motivation und Zielsetzung... 2 1.3 Gliederung der Arbeit... 3 2 Allgemeine Grundlagen... 4 2.1 Geschäftsprozesse... 4 2.2 Notationen zur Prozessmodellierung... 6 2.2.1 EPK Ereignisgesteuerte Prozessketten... 7 2.2.2 BPMN Business Process Modeling Notation... 9 2.2.3 ADONIS-Standard-Methode... 12 2.3 Geschäftsprozessmodell des Unternehmens... 14 2.3.1 Notation... 14 2.3.2 Aufbau... 15 3 Informationen und Dokumente... 16 3.1 Information... 16 3.1.1 Information als Verringerung von Ungewissheit... 17 3.1.2 Daten Information Wissen... 18 3.1.3 Information als Daten plus Bedeutung... 19 3.1.4 Information als Daten plus Bedeutung plus Wahrheit... 20 3.1.5 Information als abstrahierender relationaler Begriff... 21 3.2 Informationsfluss... 25 3.2.1 Was ist Informationsfluss?... 25 3.2.2 Wie fließt Information?... 26 3.3 Dokument... 27 3.4 Dokumentenfluss... 28 3.5 Sieht man einem Dokument an, welche Informationen in ihm stecken?... 28 3.6 Informationsfluss versus Dokumentenfluss... 30 4 Dokumentenfluss... 31 4.1 Notation DocFLOW... 31 4.1.1 Zeichenvorrat und Semantik... 31 4.1.2 Syntax... 32 4.2 Dokumentenflussextraktion... 33 4.2.1 Vorgehen... 33 4.2.2 Manuelle Extraktion... 37 4.2.3 Automatische Extraktion... 37 4.3 Problemstellen... 43 4.3.1 Charakterisierung... 43 4.3.2 Beispiele automatisch erkennbarer Problemstellen... 43 4.3.3 Beispiele nur manuell erkennbarer Problemstellen... 49 IV

4.4 Visualisierung... 53 4.4.1 Tool-Auswahl und Datenformat... 53 4.4.2 Transformation... 57 4.4.3 Problemstellen markieren... 59 4.5 Optimierungsmöglichkeiten... 61 4.5.1 Erweiterte Modellierungsrichtlinie... 61 4.5.2 Dokumentenklassifikation... 63 5 Informationsfluss... 66 5.1 Notation FLOW... 67 5.1.1 Zeichenvorrat und Semantik... 68 5.1.2 Syntax... 70 5.2 Informationsflussextraktion... 71 5.2.1 Vorgehen... 71 5.2.2 Manuelle Extraktion... 73 5.2.3 Automatische Extraktion... 78 5.3 Problemstellen... 79 5.3.1 Charakterisierung... 79 5.3.2 Beispiele automatisch erkennbarer Problemstellen... 80 5.3.3 Beispiele nur manuell erkennbarer Problemstellen... 82 5.4 Visualisierung... 84 5.5 Optimierungsmöglichkeiten... 84 5.5.1 Vision: Informationsmanagementsystem... 85 5.5.2 Einsatz von FLOW... 87 6 Zusammenfassung und Ausblick... 88 6.1 Zusammenfassung... 88 6.2 Ausblick... 89 6.3 Fazit... 90 Anhang... 91 A Beschreibung zur Transformation ADONIS-Export GXL... 91 B Vollständige Facettenklassifikation... 92 Glossar... 93 Literaturverzeichnis... 95 V

Abbildungsverzeichnis Abbildung 1-1: Ziele der Arbeit...2 Abbildung 2-1: EPK Symbole...7 Abbildung 2-2: Beispiel EPK Syntax...8 Abbildung 2-3: BPMN Symbole...9 Abbildung 2-4: Beispiel BPMN Syntax... 11 Abbildung 2-5: ADONIS-Standard-Methode Geschäftsprozessmodell Symbole...13 Abbildung 2-6: Beispiel ADONIS-Standard-Methode Geschäftsprozessmodell Syntax...14 Abbildung 2-7: ADONIS Geschäftsprozessmodell Symbole...15 Abbildung 3-1: Information im Zusammenhang mit Wissen und Daten...22 Abbildung 3-2: Vom Dokument zu den darin enthaltenen Informationen...29 Abbildung 4-1: DocFLOW Symbole...31 Abbildung 4-2: Beispiel DocFLOW Syntax...32 Abbildung 4-3: Dokumentenflussextraktion: Prinzipielles Vorgehen...34 Abbildung 4-4: Dokumentenflussextraktion: Parallelität...35 Abbildung 4-5: Dokumentenflussextraktion: Entscheidung...36 Abbildung 4-6: Dokumentenflussextraktion: Prozessaufruf...37 Abbildung 4-7: Beispiel ADONIS-XML-Export...39 Abbildung 4-8: Algorithmus: Prinzipielles Vorgehen Dokumentenflussextraktion (Pseudocode)...40 Abbildung 4-9: Algorithmus: Erweitertes Vorgehen Dokumentenflussextraktion (Pseudocode)...40 Abbildung 4-10: Algorithmus: Funktion searchfirstoutput() (Pseudocode)...41 Abbildung 4-11: Algorithmus: Funktion extractdocflow() (Pseudocode)...41 Abbildung 4-12: Problem: Dokument ist nur Input...44 Abbildung 4-13: Problem: Dokument ist nur Output...45 Abbildung 4-14: Problem: Dokument wird nicht benutzt...46 Abbildung 4-15: Parallele und sequentielle Modellierung von Geschäftsprozessen...47 Abbildung 4-16: Problem: Unterbrochener Fluss...48 Abbildung 4-17: Problem: Allgemeine Prozesse werden auf Basis konkreter Dokumente modelliert...49 Abbildung 4-18: Problem: Fehlende Verzweigungen...50 Abbildung 4-19: Problem: Nicht abgestimmte Schnittstelle...52 Abbildung 4-20: Screenshot von SHriMP...54 Abbildung 4-21: SHriMP Problem: zu viele Pfeile...55 VI

Abbildung 4-22: Fehlerhafte Darstellung in SHriMP: ein Beispiel...56 Abbildung 4-23: GXL Beispiel...57 Abbildung 4-24: Problemstellenmarkierung in SHriMP...60 Abbildung 4-25: Facettenklassifikation für Dokumente...64 Abbildung 5-1: FLOW Symbole...68 Abbildung 5-2: FLOW erweiterte Notation für Informationsflüsse...69 Abbildung 5-3: Beispiel FLOW Syntax...70 Abbildung 5-4: FLOW: kleines Softwareprojekt...74 Abbildung 5-5: FLOW: Dokument erstellen...74 Abbildung 5-6: FLOW: Implementierung...75 Abbildung 5-7: FLOW: Dokument erstellen erweitert...76 Abbildung 5-8: FLOW: kleines Softwareprojekt erweitert...77 Abbildung 5-9: FLOW: Nachträgliche Erstellung des s...77 Abbildung 5-10: Beispiel: Dokumentenabhängigkeitsgraph...80 Abbildung 5-11: Problem: Zirkulärer Informationsfluss...81 Abbildung 5-12: Problem: Mehrfache Datenhaltung derselben Information...82 Abbildung 5-13: Problem: Mehrfache Erstellung derselben Information...83 VII

Tabellenverzeichnis Tabelle 3-1: Typisierung von Informationsflüssen...25 Tabelle 3-2: Beispiele für materielle und elektronische Dokumente...27 Tabelle 4-1: Charakterisierung der Problemstellen bei Dokumentenflüssen...43 Tabelle 4-2: XSLT Schablonen der ADONIS-XML-Export GXL Transformation...59 Tabelle 5-1: Charakterisierung der Problemstellen bei Informationsflüssen...79 VIII

1 Einleitung Softwareentwicklung ist seit geraumer Zeit keine einfache Aufgabe einer kleinen Gruppe von Programmierern mehr. Insbesondere bei der Entwicklung von Bankensoftware, bei der viele Vorgaben eingehalten werden müssen und die Sicherheit eine bedeutende Rolle spielt, muss das Vorgehen im Entwicklungsprojekt exakt geplant, gemanaged und kontrolliert werden. Ergebnisse sollten wiederholbar, Erfahrungen wieder verwendbar, die Projektdauer vorhersagbar und die Qualität gesichert sein. Die Arbeit im Team oder gar das Zusammenspiel mehrerer Teams muss möglich sein. Prozessmodelle unterstützen und vereinfachen diese Aufgaben oder ermöglichen sie erst. Sie sind in großen IT-Unternehmen meist historisch gewachsen. Das bisherige Vorgehen bei der Erstellung von Software wird in Prozessen festgehalten und über Jahre immer wieder aktualisiert. Dabei wird oft versucht, Optimierungen bereits in die Vorgehensweisen mit einfließen zu lassen, zum Beispiel durch das Anlehnen an ein standardisiertes Modell, wie das Wasserfallmodell, das V-Modell oder den Rational Unified Process. Diese Mischung aus alten Vorgehensweisen und neuen Methoden, die vorwiegend aus dem universitären Umfeld oder der Fachpresse stammen, birgt ein erhöhtes Fehlerpotential. 1.1 Problemstellung Ein sehr umfangreicher, historisch gewachsener aber modernisierter Softwareentwicklungsprozess steht im Mittelpunkt dieser Arbeit. Er ist Teil eines sehr großen Prozessmodells eines IT- Dienstleisters aus der Bankenbranche. Das Unternehmen beschäftigt 2700 Mitarbeiter, von denen ca. 800 in der Softwareentwicklung tätig sind. Das Gesamtprozessmodell beinhaltet alle Unternehmensvorgänge. Es besteht aus 5 Prozessgruppen mit insgesamt 23 Prozessen. Jeder dieser Prozesse besteht aus 4 bis 5 Teilprozessen, die wiederum weiter aufgeteilt sein können. Der Softwareentwicklungsprozess ist einer der 5 Prozessgruppen. Er besteht aus 4 Prozessen und insgesamt 18 Teilprozessen, die je nochmals in drei weitere Ebenen unterteilt sein können. Die Prozesse orientieren sich am Rational Unified Process [RUP 2003]. Für jeden Bereich der Softwareentwicklung gibt es einen so genannten Prozessexperten, der für die Modellierung der Prozesse in seinem Bereich zuständig ist. Dieser hat die Aufgabe, das bisherige Vorgehen in seinem Bereich unter Einhaltung bestimmter Vorgaben als Prozess abzubilden. Die Arbeit vieler Modellierer an einem übergreifenden Prozessmodell erfordert einen zusätzlichen Abstimmungsaufwand, der eine erhebliche Fehlerquelle darstellt. Insgesamt lassen sich drei markante Fehlerquellen ausmachen: Es ist ein sehr großer, historisch gewachsener und von vielen Modellierern bearbeiteter Softwareentwicklungsprozess.

Insbesondere der Fluss von Informationen in dem Modell ist undurchsichtig und enthält einige Problemstellen. So kann es zum Beispiel vorkommen, dass eine Information, die für die Ausführung eines bestimmten Prozessschrittes benötigt wird, zum Zeitpunkt des Prozessstarts noch gar nicht vorhanden ist. Genauso kann es passieren, dass eine Information aufwendig bereitgestellt, aber dann nicht weiter verwendet wird. Diese Fehler sind schwer zu identifizieren, da der Informationsfluss nicht direkt aus dem Prozessmodell ablesbar ist. Darüber hinaus passiert es häufiger, dass an verschiedenen Stellen im Modell Dokumente erstellt werden, die teilweise übereinstimmende Informationen beinhalten. Da aber nicht bekannt ist, dass diese Informationen eigentlich identisch sein sollten, werden sie mehrfach erstellt. Es kommt zu Inkonsistenzen, weil nicht mehr klar ist, welches die korrekte Information ist und mit welcher weitergearbeitet werden soll. Es fehlen Untersuchungen, welche Informationen in welchen Dokumenten stecken und wie diese zusammenhängen. Auch der Unterschied zwischen Informationen und Dokumenten ist oft nicht klar. 1.2 Motivation und Zielsetzung Jedes Unternehmen, das in polypolistischen Märkten tätig ist, versucht besonders effektiv zu produzieren, damit es trotz Preisdruck noch wirtschaftlich arbeiten kann. Daher ist ein nicht nur funktionierender, sondern darüber hinaus effizienter Prozess ein kritischer Erfolgsfaktor. Der Prozess wird deshalb kontinuierlich verbessert. Fehler werden gesucht und beseitigt. Abläufe werden optimiert, um die Leistungserstellung ressourcenschonender und schneller zu machen. Oberstes Ziel dieser Masterarbeit ist deshalb die Optimierung des Softwareentwicklungsprozesses. Sie konzentriert sich dabei auf die Informationsflüsse, da bei diesen viele Fehlerquellen liegen und sie bisher noch nicht näher untersucht wurden. Um den Informationsfluss optimieren und darin enthaltene Fehler korrigieren zu können, müssen diese zunächst erkannt und identifiziert werden. Dies geht einfacher und schneller, wenn der Fluss und die Fehler, durch eine visuelle Darstellung unterstützt, untersucht werden können. Eine Visualisierung ist nur möglich, wenn der implizit im Prozessmodell vorhandene Informationsfluss daraus extrahiert wird. Es ergeben sich folgende aufeinander aufbauende Ziele: Prozessmodell verbessern Unternehmensziele Informationsfluss optimieren / Fehler korrigieren Kritische Stellen / Fehler im Informationsfluss finden Kritische Stellen / Fehler im Informationsfluss visualisieren Informationsfluss visualisieren Ziele dieser Arbeit Informationsfluss aus Prozessmodell extrahieren Abbildung 1-1: Ziele der Arbeit 2

Problematisch bei der Extraktion ist, dass der Informationsfluss nicht direkt aus dem Modell ableitbar ist. Er liegt vielmehr als Dokumentenfluss vor, der allerdings nur einen Teil des Informationsflusses widerspiegelt. Ein weiteres Ziel ist deshalb auch, die beiden Begriffe Informationsfluss und Dokumentenfluss voneinander abzugrenzen und auf die Schwierigkeiten, die sich dadurch für die Erreichung der oben genannten Ziele ergeben, einzugehen. Da Änderungen am Modell nur von den Prozessexperten vorgenommen werden dürfen und bei größeren bereichsübergreifenden Maßnahmen ein Abstimmungsprozess durchlaufen werden muss, können im Rahmen dieser Arbeit gefundene Fehler nicht direkt korrigiert, sondern nur Lösungsvorschläge erarbeitet werden. 1.3 Gliederung der Arbeit Die vorliegende Masterarbeit gliedert sich wie folgt: Kapitel 2: Kapitel 3: Kapitel 4: Kapitel 5: Kapitel 6: In Kapitel 2 werden zunächst die Begriffe Geschäftsprozess und Geschäftsprozessmodell eingeführt. Anschließend werden drei Notationen zur Geschäftsprozessmodellierung beschrieben. Schließlich wird das Geschäftsprozessmodell, das das in dieser Arbeit betrachtete Unternehmen einsetzt, vorgestellt. Kapitel 3 setzt sich mit den für das Verständnis der Arbeit wichtigen Begriffen Information, Dokument, Informationsfluss und Dokumentenfluss auseinander. Jeder Begriff wird zunächst definiert um anschließend, ausgehend von der Definition, deren Beziehungen untereinander zu verdeutlichen. In Kapitel 4 wird nachdem eine zur Illustration von Beispielen notwendige Notation vorgestellt wurde beschrieben, wie Dokumentenflüsse aus dem Geschäftsprozessmodell extrahiert werden können, wie die darin enthaltenen Problemstellen aussehen und gefunden werden können, wie Dokumentenflüsse visualisiert werden können, und schließlich, wie sie optimiert werden können. Analog zur Vorgehensweise in Kapitel 4, wird in Kapitel 5 nach Vorstellung der zum Verständnis notwendigen Notation FLOW beschrieben, wie Informationsflüsse aus dem Geschäftsprozessmodell und aus Projekterfahrungen extrahiert werden können und wie darin enthaltene Probleme aussehen. Schließlich wird kurz vorgestellt, was bei einer Visualisierung von Informationsflüssen zu beachten ist und welche Ansätze zur Informationsflussoptimierung verfolgt werden können. In Kapiteln 6 werden die Ergebnisse dieser Masterarbeit zusammengefasst und es wird ein Ausblick auf mögliche zukünftige Arbeitsbereiche gegeben. Ein Fazit bildet den Schluss dieser Masterarbeit. 3

2 Allgemeine Grundlagen In diesem Kapitel sollen allgemeine Grundlagen für das Verständnis dieser Masterarbeit gelegt werden. Diese Arbeit entsteht im Umfeld eines großen IT-Dienstleisters aus der Bankenbranche. Dort trifft man immer wieder auf die Begriffe Prozesse, Prozessmodell, Prozessmodellierung usw. Diese werden in der Regel abkürzend für Geschäftsprozesse und deren Darstellung benutzt. Im folgenden Abschnitt wird eine Definition von Geschäftsprozessen gegeben und ausgehend davon die Verwendung der genannten Begriffe im Laufe der Arbeit abgeleitet. Dabei wird auf die oft unterschiedliche sich teilweise überschneidende Verwendung der Begriffe im Unternehmensalltag eingegangen. Anschließend werden drei Notationen, die zur grafischen Dokumentation von Geschäftsprozessen eingesetzt werden können, vorgestellt. 2.1 Geschäftsprozesse Ein Geschäftsprozess besteht aus einer zusammenhängenden, abgeschlossenen zeitlichlogischen Abfolge von Aktivitäten oder Funktionen, die zur Erfüllung einer betrieblichen Aufgabe notwendig sind [ALLWEYER 2005], [STAUD 2006]. Jede Aktivität oder Funktion benötigt bestimmte Ressourcen als Voraussetzung und erzeugt bestimmte Ressourcen als Ergebnis. Ressourcen können neben Materialien insbesondere auch Informationen sein. Die zeitliche Abfolge von Aktivitäten resultiert aus deren logischen Abhängigkeiten. Eine Aktivität muss zeitlich nach einer anderen ausgeführt werden, wenn diese ein Ergebnis der vorangehenden Aktivität als Voraussetzung hat. Sie kann erst ausgeführt werden, wenn die erste Aktivität abgeschlossen ist und das Ergebnis vorliegt. Die zeitlich-logische Folge von Aktivitäten oder Funktionen wird als Kontrollfluss bezeichnet. Der Kontrollfluss kann je nach logischer Abhängigkeit sowohl sequentielle als auch parallele Abfolgen von Aktivitäten enthalten. Einige Aktivitäten können Entscheidungen auslösen oder werden abhängig von einer Entscheidung ausgeführt. Der Kontrollfluss ist abhängig von diesen Entscheidungen. Geschäftsprozesse können verschiedene Detaillierungsebenen widerspiegeln. Die Funktionen eines grob dargestellten Geschäftsprozesses lassen sich durch detailliertere Geschäftsprozesse beschreiben. So lassen sich Geschäftsprozesshierarchien aufbauen. Die oberste Ebene enthält eine grobe Übersicht der Hauptprozesse des Unternehmens, die in den darunter liegenden Ebenen jeweils schrittweise verfeinert werden. Eine Verfeinerung erfolgt, bis der Aufwand einer weiteren Aufteilung dessen Nutzen übersteigen würde. Es gilt abzuschätzen, welche Detaillierungsebene sinnvoll für den Einsatzzweck ist. Ein zu grober Geschäftsprozess gibt nur einen Überblick, lässt aber keine detaillierteren Betrachtungen zu. Ein zu feiner Geschäftsprozess wird hingegen schnell unübersichtlich. Die Aktivitäten auf der untersten Ebene werden als elementare Aktivitäten bezeichnet. Sie können durch Arbeitsschrittabläufe (Workflows) weiter verfeinert werden. Hier steht aber nicht mehr die Aktivität oder Funktion mit einem definierten Ergebnis (Was), sondern das schrittweise Vorgehen (Wie) im Vordergrund. Geschäftsprozesse sind im Gegensatz zu Workflows keine Arbeitsanweisungen. Ziel der Modellierung von Geschäftsprozessen ist unter anderem deren Dokumentation für 4

die Mitarbeiter. Ziel von Workflows hingegen ist eine mögliche (Teil-)Automatisierbarkeit der Abläufe [FREUND 2006]. Die hier vorgestellte Definition von Geschäftsprozessen stellt ein sehr allgemeines Konzept dar. Im Unternehmensalltag wird der Begriff Geschäftsprozess teilweise in leicht abgeänderter Bedeutung verwendet. Dies kann zu Missverständnissen führen. Prof. Thomas Allweyer 1 gibt in seinem Lehrbuch Geschäftsprozessmanagement [ALLWEYER 2005] einen Überblick über die unterschiedlichen Verwendungen des Begriffs. Die folgenden Erläuterungen sind in Anlehnung an die Ausführungen in diesem Buch entstanden: Betriebswirtschaftlich orientiert: Gemäß der eingangs genannten Definition umfasst ein Geschäftsprozess eine zeitlich-logische Folge von Aktivitäten oder Funktionen zur Erfüllung einer betrieblichen Aufgabe. Dabei wird eine Leitung in Form einer Material- und/oder Informationsverarbeitung erbracht. Diese Definition ist sehr allgemein gehalten und beinhaltet Prozesse innerhalb eines Unternehmens, aber auch Prozesse, die unternehmensübergreifend sind. Mit ihr lassen sich sowohl umfassende Gesamtprozesse im Groben, als auch kleine Teilprozesse im Detail betrachten. Automatisierungsbezogen: Ist die Rede von Informationssystemen, die als Ziel die Automatisierung von Abläufen haben, so werden häufig die von diesen Systemen durchgeführten Abläufe als Geschäftsprozesse bezeichnet. Wenn diese Abläufe der Erfüllung einer betrieblichen Aufgabe dienen, fallen sie unter die oben genannte betriebswirtschaftliche Definition. Der Fokus liegt hier aber eher auf dem von einem Computer ausführbaren Teil eines Prozesses. Daher reduziert diese Betrachtung Geschäftsprozesse auf einen Teilaspekt. Der bereits diskutierte Begriff Workflow würde hier besser passen. Schnittstellenbezogen: In so genannten E-Business-Projekten geht es hauptsächlich darum, Dokumente in elektronischer Form zwischen den Datenverarbeitungssystemen der beteiligten Partner auszutauschen. Hierzu muss zunächst definiert werden, welche elektronischen Dokumente zur Durchführung eines Geschäfts ausgetauscht werden sollen. Gelegentlich wird die Reihenfolge der Dokumente, die zwischen den Systemen ausgetauscht werden, als gemeinsamer Geschäftsprozess bezeichnet. Auch diese Sichtweise umfasst nur einen Teilaspekt eines Geschäftsprozesses. Es wird nur auf den stattfindenden Datenfluss (vgl. dazu Kapitel 3.4 Dokumentenfluss auf S.28) eingegangen. Die durchgeführten Aktivitäten werden hingegen nicht betrachtet. Anwendungssystembezogen: Bei der Anwendungsentwicklung werden häufig Use Cases betrachtet, die beschreiben, wie ein Benutzer eine bestimmte Aufgabe in Wechselwirkung mit dem System durchführt. Der englische Begriff Use Case wird uneinheitlich ins Deutsche übersetzt, meist als Anwendungsfall, teilweise aber auch als Geschäftsprozess. Letzteres ist insofern gerechtfertigt, als es sich zumindest bei betrieblichen Anwendungssystemen bei den meisten Use Cases um kleine Abläufe handelt, die der Er- 1 Unternehmensberater und Professor für Unternehmensmodellierung und Geschäftsprozessmanagement an der Fachhochschule Kaiserslautern 5

füllung einer betrieblichen Aufgabe dienen. Diese Sicht erfasst aber wieder nur einen Teil aller Geschäftsprozesse. Übergeordnete, mehrere Use Cases umfassende Prozesse sowie rein manuelle und rein automatische Prozessschritte können nicht berücksichtigt werden. Softwareentwicklungsbezogen: Bei der Softwareentwicklung spricht man von einem Prozess, wenn es darum geht, zu beschreiben, aus welchen Phasen die Entwicklung besteht, in welcher Reihenfolge diese durchgeführt werden und welche Ergebnisse darin erarbeitet werden. Ein solcher Softwareentwicklungsprozess wird durch Prozessmodelle oder Vorgehensmodelle beschrieben. Auch diese spezielle Sicht beschreibt einen Geschäftsprozess im Sinne der betriebswirtschaftlichen Definition. Alle anderen Aktivitäten im Unternehmen fallen nicht unter diesen Prozessbegriff. Viele Softwareentwicklungen zielen darauf ab, durch ein geeignetes Anwendungssystem Geschäftsprozesse eines Unternehmens (im betriebswirtschaftlichen Sinne) zu unterstützen. Bei der Entwicklung solcher Anwendungssysteme kann es leicht zu Verwirrungen kommen, wenn einmal von Prozessen als verwendete Vorgehensweise und einmal als von der Software unterstützte Geschäftsprozesse des Kunden gesprochen wird. Der Unterschied sollte jedem Mitwirkenden der Softwareentwicklung klar sein und es sollten vorher abgestimmte verschiedene Begriffe verwendet werden (zum Beispiel Softwareprozess und Geschäftsprozess). Obwohl sich diese Masterarbeit mit einem Softwareentwicklungsprozess beschäftigt, wird im Folgenden die eingangs genannte betriebswirtschaftlich orientierte Definition eines Geschäftsprozesses verwendet. Diese schließt, wie beschrieben, auch den Softwareentwicklungsprozess mit ein, ist aber allgemeiner und umfasst damit mehr Anwendungsgebiete. Wenn im weiteren Verlauf der Arbeit von Prozessen die Rede ist, sind damit immer Geschäftsprozesse gemeint. Die in einem Unternehmen durchgeführten Geschäftsprozesse können zu Dokumentationszwecken und eventuell späteren Optimierungen notiert werden. Dies geschieht meist mit einer grafischen Notation. Der Geschäftsprozess wird in ein Modell überführt. Man spricht von einem Geschäftsprozessmodell oder kürzer: Prozessmodell. In den folgenden Unterkapiteln werden drei grafische Notationen zur Geschäftsprozessmodellierung vorgestellt. 2.2 Notationen zur Prozessmodellierung Eine Notation gibt eine Menge von Symbolen, sowie deren Verwendung (Syntax) vor. Die Symbole sind Zeichen mit einer festgelegten Bedeutung (Semantik). Somit ermöglicht eine Notation über die Anordnung von Zeichen mit einer bestimmten Bedeutung nach festen Syntaxregeln die Modellierung eines Sachverhalts. Es existiert eine große Anzahl von Notationen, die entwickelt wurden, um Modelle von Geschäftsprozessen abzubilden. Im Folgenden soll exemplarisch auf drei dieser Notationen eingegangen werden, die Geschäftsprozesse grafisch abbilden können. Dies sind im Einzelnen die Ereignisgesteuerten Prozessketten (EPK), die Business Process Modelling Notation (BPMN) und die ADONIS-Standard-Methode. 6

2.2.1 EPK Ereignisgesteuerte Prozessketten Zeichenvorrat und Semantik UND ODER XODER Name Name Name Name Die Ereignisgesteuerten Prozessketten (EPK) sind eine Notation, die von Prof. August-Wilhelm Scheer 2 zur Modellierung der Abläufe in einer der fünf Sichten seines ARIS-Konzepts (Architektur integrierter Informationssysteme, vgl. dazu [STAUD 2006] S. 27) entwickelt wurde. Diese Steuerungssicht dient der Integration der anderen vier Sichten. In ihr werden mit Hilfe von EPK Funktionen und Ereignisse in einem Kontrollfluss dargestellt. Dies entspricht einer zeitlich-logischen Abfolge von Aktivitäten, also einem Geschäftsprozess. EPK dienen damit der Modellierung von Geschäftsprozessen. Funktion Ereignis Organisationseinheit Informationsobjekt Operatoren Abbildung 2-1: EPK Symbole In Abbildung 2-1 sind die Symbole Ereignisgesteuerter Prozessketten abgebildet. Im Folgenden wird auf deren Bedeutung näher eingegangen (in Anlehnung an [STAUD 2006]): Funktion: Ereignis: Funktionen beschreiben die zu leistenden Tätigkeiten in einem Geschäftsprozess (auch Aktivitäten). Der Umfang an ausgewählten Tätigkeiten, den eine ausgewiesene Funktion umfasst, bleibt dem Modellierer überlassen. Ereignisse sind in EPK betriebswirtschaftlich relevante Ereignisse, die auf unterschiedliche Art und Weise die Abläufe in einem Unternehmen steuern. Ereignisse beschreiben Bedingungen oder Ergebnisse der Ausführung von Funktionen. Organisationseinheit: Eine Organisationseinheit beschreibt den Ort, an dem eine in einer Funktion erfassten Aufgabe erfüllt wird. Der Ort ist dabei weniger räumlich, sondern vielmehr funktional zu sehen. Er kann zum Beispiel eine Fachabteilung oder eine spezialisierte Gruppe meinen. Sie hilft bei einer späteren Analyse des Prozessmodells festzustellen, welche Mitarbeiter eine bestimmte Tätigkeit ausführen sollen. Informationsobjekt: Informationsobjekte sind die für eine Funktion benötigten oder in einer Funktion erstellten Daten. Diese sind von Bedeutung für das Unternehmen und den Geschäftsprozess. Es kann grundsätzlich jede Information 2 Leiter des Instituts für Wirtschaftsinformatik an der Universität des Saarlandes bis 2005 und Begründer der heutigen IDS Scheer AG 7

auf jedem Informationsträger berücksichtigt werden, egal ob in elektronischer oder anderer Form. Operatoren: In Geschäftsprozessen können sowohl parallele als auch alternative Tätigkeiten vorkommen. Genauso können mehrere Ereignisse Bedingung einer Tätigkeit sein oder alternative Ereignisse dieselbe Tätigkeit auslösen. Diese Parallelitäten oder Alternativen werden durch unterschiedliche Operatoren modelliert. Parallele Tätigkeiten oder Ereignisse werden durch einen UND-Operator, Alternativen durch einen ODER- oder XO- DER-Operator symbolisiert. Die Position der Operatorsymbole ( - UND, - ODER, - XODER) oberhalb oder unterhalb der mittleren Trennlinie gibt an, ob mehrere Stränge zusammengeführt oder ob ein Strang verzweigt wird. Die Operatorsymbole können auch gleichzeitig in den beiden Hälften des Operatorkreises vorkommen. Der Kontrollfluss, der die Funktionen, Ereignisse und Operatoren verbindet, wird durch eine gestrichelte Linie dargestellt. Die Richtung des Kontrollflusses wird durch einen entsprechenden Pfeil angegeben. Syntax Entwurf Entwurf erstellen Entwurf erstellt Entwicklung Entwurf Protokoll Review QS Entwurf nicht ok Entwurf ok Abbildung 2-2: Beispiel EPK Syntax Wie die Symbole in Ereignisgesteuerten Prozessketten anzuordnen sind, ist beispielhaft in Abbildung 2-2 gezeigt. Die Modellierung erfolgt vertikal in diesem Fall: von oben nach unten wobei weiter oben gelegene Funktionen und Ereignisse vor weiter unten gelegenen ausgeführt werden bzw. eintreten. Entlang eines Kontrollflusses sind alternierend Funktionen und Ereignisse anzugeben. Es folgt nie ein Ereignis direkt auf ein anderes Ereignis und nie eine Funktion direkt auf eine andere Funktion. Der Geschäftsprozess beginnt durch ein Startereignis und endet mit einem Endereignis. Die Operatoren sind entsprechend ihrer Bedeutung zwischen Ereignis(sen) und Funktion(en) oder Funktion(en) und Ereignis(sen) anzuordnen. Die Voraussetzungen oder Ergebnisse einer Funktion werden mit Hilfe von Informationsobjekten dargestellt. Sie werden mit 8

einem Pfeil an eine Funktion geknüpft. Je nach Richtung des Pfeils ist das Informationsobjekt entweder notwendige Voraussetzung oder Ergebnis der Funktion. Schließlich kann man einer Funktion noch eine Organisationseinheit zuweisen. Diese wird über eine Linie mit der Funktion verknüpft. Die Verbindung ist ungerichtet. 2.2.2 BPMN Business Process Modeling Notation Die Business Process Modeling Notation (BPMN) wurde 2002 durch Stephen A. White, einem Mitarbeiter von IBM, zur Modellierung von Geschäftsprozessen erarbeitet und durch die Business Process Management Initiative (BPMI) veröffentlicht. Nach der Fusion der BPMI mit der Object Management Group (OMG) im Jahr 2005 wurde auch die BPMN ein Standard der OMG. Die folgenden Ausführungen beruhen auf der BPMN Spezifikation 1.0 der OMG vom Februar 2006 [BPMN 2006]. Zeichenvorrat und Semantik Name Aktivität Ereignis Gateway Sequenzfluss Nachrichtenfluss Assoziation Fluss-Objekte Verbindungs-Objekte Pool Name Text Bahn Name Name Name Datenobjekt Gruppe Anmerkung Schwimmbahnen Abbildung 2-3: BPMN Symbole Artefakte Die Grundsymbole der BPMN sind in vier Kategorien unterteilt. Diese Unterteilung soll es erleichtern, eine leicht erlern- und anwendbare Notation, die gleichzeitig der Komplexität von Geschäftsprozessen gewachsen ist, zu schaffen. Im Einzelnen sind das: Fluss-Objekte Verbindungs-Objekte Schwimmbahnen Artefakte Fluss-Objekte sind die Hauptelemente zur Darstellung von Geschäftsprozessen. Es gibt drei Arten von Verbindungs-Objekten, die die Fluss-Objekte und andere Informationen miteinander verbinden können. Schwimmbahnen dienen der Gruppierung der primären Modellierungselemente. Artefakte bieten die Möglichkeit, zusätzliche Informationen im Prozess unterzubringen. 9

Die vier Kategorien sind mit den jeweiligen Grundsymbolen in Abbildung 2-3 dargestellt. Die Bedeutung der einzelnen Symbole wird in folgender Auflistung geklärt: Aktivität: Ereignis: Gateway: Sequenzfluss: Eine Aktivität ist ein allgemeiner Begriff für jegliche Art von Arbeit, die in einem Unternehmen geleistet wird. Sie kann atomar oder zusammengesetzt sein. Eine atomare Aktivität ist eine Aufgabe oder Funktion. Eine zusammengesetzte Aktivität ist ein Prozess oder Sub-Prozess. Ein Sub- Prozess kann durch ein zusätzliches Plus-Symbol im Aktivitäten-Symbol markiert werden. Ein Ereignis ist das, was während des Ablaufes eines Geschäftsprozesses passieren kann. Ereignisse bestimmen den Fluss eines Prozesses und haben für gewöhnlich eine Ursache oder eine Wirkung. Es gibt drei Arten von Ereignissen: Start-, Zwischen- und Endereignisse. Ein Startereignis wird durch einen Kreis mit einem einfachen schmalen Rand, ein Zwischenereignis durch einen Kreis mit doppeltem Rand und ein Endereignis durch einen Kreis mit dickem Rand dargestellt. Ein Gateway markiert Abzweigungen und/oder Zusammenführungen im Sequenzfluss. Damit bestimmt es Verzweigungen, Gabelungen, Verbindungen und Zusammenlegungen von Pfaden. Interne Markierungen legen den genauen Typ eines Gateways fest. Sequenzflüsse zeigen die Reihenfolge der Durchführung von Aktivitäten in einem Geschäftsprozess an. Nachrichtenfluss: Nachrichtenflüsse zeigen den Nachrichtenfluss zwischen mitwirkenden Einheiten des Prozesses an. Sie fließen zwischen durch Pools oder Bahnen dargestellte - Geschäftseinheiten oder Rollen. Assoziation: Pool: Bahn: Datenobjekt: Gruppe: Assoziationen assoziieren (zusätzliche) Informationen mit Flussobjekten. Diese können entweder gerichtet oder ungerichtet sein. Pools repräsentieren die Beteiligten an einem Geschäftsprozess. Sie fungieren als grafische Container zur Partitionierung von Geschäftsprozessen. (Schwimm-)Bahnen sind Unterteilungen von Pools, die es ermöglichen, Aktivitäten weiter zu gruppieren und bestimmten Geschäftsbereichen o- der Rollen zuzuordnen. Datenobjekte werden als Artefakte angesehen, weil sie keinen direkten Einfluss auf den Sequenzfluss haben, aber trotzdem wichtige Informationen darüber enthalten, was bestimmte Aktivitäten benötigen, um ausgeführt zu werden, oder was sie erzeugen. Eine Gruppe kennzeichnet eine Menge von Aktivitäten zu Dokumentations- oder Analysezwecken. Sie kann auch benutzt werden, um die Zusammengehörigkeit von über verschiedene Pools verteilte Aktivitäten einer verteilten Transaktion anzuzeigen. 10

Anmerkung: Eine Anmerkung kann ein beliebiges Objekt mit einer zusätzlichen textuellen Information versehen. Diese Grundelemente zur Modellierung können durch bestimmte zusätzliche Markierungen und verschiedene Varianten der Symbole noch erweitert werden. Da an dieser Stelle nur eine kurze Einführung in die BPMN gegeben werden soll, sei für die komplette Menge der BPMN-Symbole auf [BPMN 2006] verwiesen. Syntax IT-Unternehmen Qualitätssicherung Review + Entwurf Dok. ok? nein ja Entwicklung Entwurf erstellen Entwurf verbessern Abbildung 2-4: Beispiel BPMN Syntax Ein Beispiel für die Anordnung der BPMN-Symbole ist in Abbildung 2-4 gegeben. Prinzipiell erfolgt die Modellierung von links nach rechts. Zusammengehörige Aktivitäten werden in einem Pool zusammengefasst. Dieser kann weiter in verschiedene Aufgabenbereiche, Abteilungen, Rollen usw. unterteilt werden. Dies geschieht durch Schwimmbahnen. Ein Prozess beginnt mit dem Startereignis und endet mit dem Endereignis. Dazwischen wird der Prozess mit einer durch einen Sequenzfluss verbundenen Menge aus Aktivitäten, Zwischenereignissen und Gateways dargestellt. Das dargestellte Gateway entspricht einer XODER-Entscheidung, das heißt, es wird entweder der Ja- Pfad oder der Nein-Pfad, aber nie beide gleichzeitig, verfolgt. Der Querstrich am Nein-Pfad des Gateways kennzeichnet den Standard-Sequenzfluss. In diesem Beispiel deutet er darauf hin, dass ein Dokument meist mehrfach überarbeitet werden muss, bevor es die Qualitätssicherung besteht. Es können auch verschiedene Gatewaytypen benutzt werden, die dann durch unterschiedliche innere Markierungen voneinander abgegrenzt werden müssen. So können unter anderem auch parallele Zweige (UND-Gateway) oder Auswahlentscheidungen (ODER-Gateway) modelliert werden. Zusätzliche Informationen, insbesondere auch Datenobjekte, können mit Artefakten bestimmten Aktivitäten zugewiesen werden. Schließlich ist es noch möglich, Nachrichten zwischen Pools darzustellen (nicht im Beispiel abgebildet). Dies findet meist bei der Modellierung unternehmensübergreifender Prozesse Anwendung (Stichwort B2B). 11

2.2.3 ADONIS-Standard-Methode Die BOC Information Technologies Consulting GmbH, ein Beratungs- und Softwarehaus mit Sitz in Wien, hat für seine Produktfamilie, zu der auch das Geschäftsprozessmanagement-Werkzeug A- DONIS gehört, ein Metamodellierungs-Konzept [BOC 2006] entwickelt. Dieses Konzept ermöglicht ohne großen Programmieraufwand die Anpassung verschiedener Modellierungs- und Auswertungstechniken an die Wünsche des Kunden. BOC hat unter Nutzung des eigenen Meta-Konzepts die ADONIS-Standard-Methode entwickelt. Sie ist eine universelle Modellierungstechnik zur Abbildung von Unternehmensabläufen und Organisationen. In ihr wurden die langjährigen Erfahrungen von BOC im Geschäftsprozess- und Wissensmanagement eingebracht. Sie ist branchenunabhängig zur Modellierung, Analyse, Dokumentation und Optimierung von Geschäftsprozessen einsetzbar. Die ADONIS-Standard-Methode besteht aus fünf Modelltypen: Prozesslandkarte: Eine Prozesslandkarte ermöglicht den schnellen Überblick über die Prozesse eines Unternehmens. Es können Prozessverbindungen und Hierarchien dargestellt werden. Geschäftsprozessmodell: Das Geschäftsprozessmodell ist der Kern der Unternehmensmodellierung. Es stellt die Abläufe in der Organisation dar. Ein Prozess ist hier eine Folge von Aktivitäten, die zur Erledigung einer bestimmten Aufgabe dienen. Arbeitsumgebungsmodell: Arbeitsumgebungsmodelle stellen die Aufbauorganisation eines Unternehmens dar. Diese besteht aus verschiedenen Organisationseinheiten, denen Mitarbeiter zugeordnet sind, die eine bestimmte Rolle ausfüllen. Dokumentenmodell: Dokumentenmodelle sind ein Pool für alle Dokumente, die mit den Prozessen und Arbeitsumgebungen in Verbindung stehen. Jedes enthaltene Dokument kann mit dem realen Gegenstück (der Datei) verknüpft werden. Anwendungsfalldiagramm: Anwendungsfalldiagramme stellen die Interaktion zwischen Nutzer und System übersichtlich dar. Die Benutzer stehen dabei mit dem System über Schnittstellen in Verbindung. Sie können helfen, die Anforderungen an ein System zu klären. Der für die Modellierung von Geschäftsprozessen wichtigste Typ ist das Geschäftsprozessmodell. Die darin verwendete Notation wird in den folgenden beiden Abschnitten vorgestellt. 12

Zeichenvorrat und Semantik Name Name Name Start Prozessaufruf Aktivität Frage? Entscheidung Parallelität Vereinigung Ende Abbildung 2-5: ADONIS-Standard-Methode Geschäftsprozessmodell Symbole Auch hier findet man die meisten der aus den bisher vorgestellten Notationen bekannten Symbole, allerdings durch teilweise andere Zeichen repräsentiert, wieder. Einen Überblick gibt Abbildung 2-5. Die Bedeutung der Symbole ist, wie folgt, festgelegt: Start: Prozessaufruf: Aktivität: Entscheidung: Jedes Geschäftsprozessmodell enthält genau ein Start-Objekt. Es stellt den Anfang des Geschäftsprozesses dar. Mit einem Prozessaufruf können andere Geschäftsprozessmodelle in einen Prozess eingebunden werden. Dies ist sinnvoll zur Strukturierung umfangreicher Geschäftsprozesse. Ein Prozessaufruf ermöglicht darüber hinaus eine Hierarchisierung der Prozesse. Aktivitäten beschreiben die Tätigkeiten, die in einem Geschäftsprozess ausgeführt werden. Eine Entscheidung ermöglicht die Verzweigung eines Pfades. Abhängig von einem vorher gesetzten Wert wird bei einem Prozessdurchlauf genau ein Pfad gewählt. Parallelität und Vereinigung: Eine Parallelität ermöglicht die Modellierung gleichzeitig zu erledigender Tätigkeiten eines Geschäftsprozesses. Dies ist sinnvoll, wenn bestimmte Aktivitäten unabhängig voneinander sind. Parallele Pfade werden durch eine Vereinigung wieder zusammengeführt. Ende: Das Objekt Ende kennzeichnet den Endpunkt eines Pfades in einem Geschäftsprozess. Es können mehrere Endpunkte vorkommen, wenn ein Geschäftsprozess mehrere mögliche Ergebnisse hat. Die Verbindung zwischen diesen Elementen erfolgt durch eine Nachfolgerbeziehung, repräsentiert durch einen Pfeil mit durchgezogener Linie. 13

Syntax ja Entwurf erstellen beginnen Entwurf erstellen Review Dokument ok? nein Entwurf verbessern Abbildung 2-6: Beispiel ADONIS-Standard-Methode Geschäftsprozessmodell Syntax Die Symbole der Notation zur Geschäftsprozessmodellierung aus der ADONIS-Standard-Methode sind, wie beispielhaft in Abbildung 2-6 gezeigt, anzuordnen. Es wird horizontal, von links nach rechts, modelliert. Begonnen wird mit dem Startsymbol. Es hat genau einen Nachfolger und keinen Vorgänger. Danach können entweder eine Aktivität, ein Prozessaufruf, eine Entscheidung oder eine Parallelität folgen. Eine Aktivität hat mindestens einen Vorgänger und genau einen Nachfolger. Gleiches gilt für einen Prozessaufruf. Eine Entscheidung hat mindestens einen Vorgänger und mindestens zwei Nachfolger. Mit ihr können auch Rückführungen modelliert werden. Diese münden entweder in einer Aktivität, in einem Prozessaufruf, in einer Entscheidung oder in einer Parallelität. Eine Parallelität hat mindestens einen Vorgänger und mindestens zwei Nachfolger. Sie wird von einer entsprechenden Vereinigung beendet. Diese hat genau so viele Vorgänger, wie die zugehörige Parallelität Nachfolger hat und hat selbst genau einen Nachfolger. Die einzige Ausnahme stellt die Existenz von Entscheidungen zwischen Parallelität und Vereinigung dar, da Entscheidungen die Pfade weiter teilen. 2.3 Geschäftsprozessmodell des Unternehmens Der IT-Dienstleister, mit dessen Prozessmodell sich diese Masterarbeit beschäftigt, benutzt zur Geschäftsprozessmodellierung das Werkzeug ADONIS von BOC [BOC 2006]. Im Folgenden soll zunächst die dort verwendete Notation und anschließend das modellierte Geschäftsprozessmodell selbst vorgestellt werden. 2.3.1 Notation Wie bereits erwähnt, ermöglicht BOC seinen Kunden durch das Metamodellierungs-Konzept eine individuelle Anpassung der verwendeten Modellierungstechniken. Auch das hier betrachtete Unternehmen hat davon gebrauch gemacht und, ausgehend von der ADONIS-Standard-Methode, eigene Anpassungen vorgenommen. Dementsprechend finden die fünf Modelle der Standard-Methode Anwendung. Insbesondere die Notation für Geschäftsprozessmodelle wurde verändert. Die Syntax ist dabei fast gleich geblieben, bis auf die vertikale, statt horizontale, Modellierungsrichtung. Diese 14

Änderung wurde hauptsächlich wegen besserer horizontaler Scrollmöglichkeiten in Modellierungstools und Browsern vorgenommen. Die Symbole hingegen unterscheiden sich teilweise stark von der Ausgangsnotation. In Abbildung 2-7 sind die veränderten Symbole dargestellt. Input Output Name Verantwortlicher Name Frage? Parallelität Ereignis Start Ergebnis Aktivität Prozessaufruf Entscheidung Vereinigung Ende Abbildung 2-7: ADONIS Geschäftsprozessmodell Symbole Die Bedeutung der Symbole hat sich gegenüber dem Modell der ADONIS-Standard-Methode nicht geändert. Lediglich die Aktivität wurde um zwei zusätzliche Attribute erweitert. Ihr können nötige Voraussetzungen (Inputs) und Ergebnisse (Outputs) mitgegeben werden. Diese sind Referenzen auf Dokumente aus einem Dokumentenmodell. 2.3.2 Aufbau Der von dem Unternehmen modellierte Geschäftsprozess umfasst neben dem Softwareentwicklungsprozess alle anderen für den betrieblichen Ablauf relevanten Prozesse. Der Gesamtgeschäftsprozess ist auf der obersten Hierarchieebene in fünf Prozessgruppen (PG) unterteilt. Jede der fünf Prozessgruppen ist in drei bis sieben Prozesse (P) gegliedert. Insgesamt gibt es 23 dieser Prozesse (P). Ein Prozess ist in weitere drei bis acht Teilprozesse (TP) strukturiert. Diese können je nach Bedarf mit weiteren Hierarchieebenen feinstrukturiert werden. Das Gesamtprozessmodell ist damit sehr umfangreich. Der Softwareentwicklungsprozess, der in dieser Masterarbeit im Mittelpunkt steht, ist einer der 5 Prozessgruppen (PG). Durch die große strukturelle Ähnlichkeit der Prozesse gelten viele der Erkenntnisse und Ergebnisse dieser Arbeit auch für die anderen, nicht softwarespezifischen Prozesse des Modells. Begründet durch die Größe des Prozessmodells, gibt es keine zentrale Stelle, die mit der Modellierung und Pflege des gesamten Geschäftsprozessmodells betraut ist. Vielmehr gibt es für jeden Bereich einen zuständigen Modellierer, den so genannten Prozessexperten. Ein Bereich umfasst dabei meist einen Teilprozess (TP). Für jeden übergeordneten Prozess und die Prozessgruppen auf der obersten Ebene gibt es auch je einen Prozessexperten, der in letzter Instanz verantwortlich für die darunter liegenden Prozesse und Teilprozesse ist. Dementsprechend gibt es sehr viele Prozessexperten, deren Arbeit auf den höheren Hierarchieebenen zusammengeführt werden muss. Es entsteht ein erhöhter Abstimmungsaufwand. Die Koordination wird von den übergeordneten Prozessexperten übernommen. 15

3 Informationen und Dokumente Im vorangegangenen Kapitel wurde erklärt, was Geschäftsprozesse sind und was ein Geschäftsprozessmodell ist. Abschließend wurde der Softwareentwicklungsprozess und das Gesamtprozessmodell des in dieser Masterarbeit betrachteten IT-Unternehmens beschrieben. Ausgehend davon kann in den folgenden beiden Kapiteln 4 und 5 an der Optimierung der in diesem Prozessmodell vorhandenen Dokumenten- und Informationsflüsse gearbeitet werden. Um Informationsflüsse und insbesondere die in dieser Arbeit vorgenommene Trennung zwischen Informations- und Dokumentenflüssen besser verstehen zu können, müssen zuerst die Begriffe Information und Dokument selbst geklärt werden. Anschließend werden die Beziehungen zwischen den Begriffen Information und Dokument sowie zwischen Dokumentenfluss und Informationsfluss näher betrachtet. Eine detaillierte Betrachtung dieser Begriffe hilft auch, die Vorgänge eines Unternehmens, die mit Informationen und deren Weitergabe und Verarbeitung zu tun haben, besser zu verstehen. 3.1 Information Der Begriff Informationsfluss setzt sich aus den Wörtern Information und Fluss zusammen. Eine Auseinandersetzung mit dem Thema Informationsfluss setzt eine Klärung dieser Begrifflichkeiten voraus. Was ist Information und was ist Fließen? Letzteres wird in Kapitel 3.2 ab Seite 25 erörtert. Die erste Frage kann leider nicht mit einer allgemein anerkannten und fachbereichsübergreifend gültigen Definition beantwortet werden, da es sie bis heute nicht gibt. Sie hat eine lange Tradition [CAPURRO 2000, KAP.4] und hat ganze Wissenschaftszweige hervorgebracht. So beschäftigen sich zum Beispiel die Informationstheorie, die Informationswissenschaft sowie die Semiotik mit Information. Trotz seiner oft unklaren oder ungenauen Bedeutung wird Information in vielen Gebieten der Wissenschaft als zentrales Element benutzt. So wird Information in der Informatik systematisch oft auch automatisch maschinell unterstützt verarbeitet. Information wird in der Nachrichtentechnik übertragen. In der Betriebswirtschaftslehre zählt Information als wichtige Ressource. Die Dokumentationswissenschaft speichert Information so, dass sie später gezielt wiederbeschafft werden kann. Viele Wissenschaftler aus den unterschiedlichsten Disziplinen haben sich bereits mit der Bedeutung von Information auseinandergesetzt. Trotz der vielfältigen Verwendung in den verschiedensten Bereichen wird mit Information meist zumindest etwas Ähnliches bezeichnet. Der Begriff wird nicht für vollkommen verschiedene Konzepte gebraucht. Es gibt aber immer geringe Abweichun- 16

gen in der Bedeutung, bedingt durch die verschiedenen Kontexte der Verwendung 3. Einleitend soll zunächst die alltägliche Bedeutung betrachtet werden: Laut Duden [DUDEN 1996] ist Information eine Auskunft, eine Nachricht, eine Belehrung. Das Verb informieren ist dem lateinischen informare entlehnt. Dort hat es zwei Bedeutungen: 1. Die eigentliche: eine Gestalt geben, formen, bilden 2. Die übertragene: durch Unterweisung bilden, unterrichten Lediglich die übertragene Bedeutung wurde im 15. Jh. entlehnt. Sie ist die auch heute noch gebräuchliche alltägliche Bedeutung des Begriffs informieren [DUDEN ETYM. 1989]. Im Folgenden wird auf verschiedene Ansätze zur Definition von Information in einigen Wissenschaftsbereichen eingegangen, um anschließend eine für diese Arbeit gültige Begriffsabgrenzung zu geben. 3.1.1 Information als Verringerung von Ungewissheit In A Mathematical Theory of Communication [SHANNON 1948] stellt der Mathematiker und spätere Begründer der Informationstheorie, Claude Elwood Shannon, seine berühmte Kommunikationstheorie vor. Sie beruht auf einem quantitativen Informationsbegriff, der es ermöglicht, die Menge der über einen Kanal transportierten Information anzugeben. Die Bedeutung, die eine Information hat, spielt für seine Betrachtungen keine Rolle und wird deshalb außen vor gelassen. Bei der Kommunikation werden Entscheidungen eines Auswahlprozesses aus einer Menge von Zeichen über einen Kanal geschickt. Der Auswahlprozess entscheidet, welches Zeichen aus einer festgelegten Menge gemeint ist. Bei zwei Zeichen bedarf es einer Ja-/Nein-Entscheidung. Bei vier Zeichen hingegen bedarf es mindestens zwei solcher Entscheidungen, usw. Da sich alle Entscheidungsprozesse auf eine Folge von binären Entscheidungen reduzieren lassen, kann man diese auch binär kodieren und die einzelnen Bits verschicken. Der Empfänger wertet diese aus, bis er mit Sicherheit sagen kann, welches Zeichen ihm geschickt wurde. Angenommen, die Zeichenmenge sei {A, B, C, D} kodiert als {00, 01, 10, 11}, dann ist der Empfänger solange noch keine Entscheidung geschickt wurde ungewiss, ob A, B, C oder D gemeint ist. Wird ihm nun das erste Bit 0 mitgeteilt, nimmt seine Ungewissheit ab. Die Auswahl beschränkt sich jetzt nur noch auf A oder B. Nach Empfang des 2. Bits 0 ist seine Ungewissheit beseitigt. Er hat die Entscheidungen in Form der beiden Bits 00 und damit die Information A erhalten. Information ist demnach die Verringerung von Ungewissheit. Ein Maß für die Ungewissheit genauer die Menge der Information ist der Logarithmus Dualis über die Anzahl verschiedener Zeichen. Dieser Wert entspricht aufgerundet der Anzahl zu übertragender Ja-/Nein-Entscheidungen (Bits) und bietet den weiteren Vorteil, dass die übertragene Informationsmenge eher dem intuitiven Verständnis entspricht: Werden zwei Zeichen aus der oben genannten 4-elementigen Menge hintereinander über einen Kanal übertragen, gibt es 4 4=16 verschiedene Kombinationsmöglichkeiten. Intuitiv würde sich der Informationsgehalt bei der Übertra- 3 Einen guten Überblick gibt der Philosoph und Professor für Informationsethik an der Hochschule der Medien Stuttgart Rafael Capurro in seinem Vorlesungsskript Einführung in den Informationsbegriff [Capur ro 2000]. 17