Geschäftsprozessmodellierung

Geschäftsprozessmodellierung oder GPM (englisch Business Process Modeling oder BPM), überwiegend im Rahmen des Geschäftsprozessmanagements, der Softwareentwicklung oder der Systementwicklung eingesetzt, ist die – meist graphische – Tätigkeit der Erfassung und Darstellung von Geschäftsprozessen eines Unternehmens (also deren Modellierung), damit die vorhandenen Geschäftsprozesse analysiert, sicher und konsistent angewendet, verbessert oder automatisiert werden können. GPM wird in der Regel von Unternehmensanalytikern durchgeführt, die über Fachwissen in der Modellierungsdisziplin verfügen, oder von Fachexperten, die über spezielle Kenntnisse der zu modellierenden Prozesse verfügen, oder häufiger von einem Team, das aus beiden besteht. Alternativ kann das Prozessmodell auch direkt aus digitalen Spuren in IT-Systemen (wie Ereignisprotokollen) mithilfe von Process-Mining Tools abgeleitet werden.

Nach Andreas Gadatsch geht es in der Prozessmodellierung «darum, Realitätsausschnitte aus einem Geschäftsfeld unter einer fachlich-konzeptionellen Perspektive in einem Geschäftsprozess abzubilden.»^{[1] (Kapitel 1.1 Prozess-Management)}

Die Geschäftsprozessmodellierung ist nach der European Association of Business Process Management EABPM eine Disziplin des Geschäftsprozessmanagements, das folgende fünf Disziplinen umfasst:^{[2] (Kapitel 1.4 CBOK® Struktur)}

• Prozessmodellierung
• Prozessanalyse (Verständnis der Ist-Prozesse und deren Ausrichtung auf die Unternehmensziele - Analyse der Geschäftstätigkeit)
• Prozessdesign (Neugestaltung - Business Process Reengineering - oder Umgestaltung der Geschäftsprozesse - Geschäftsprozessoptimierung)
• Prozessleistungsmessung (kann sich ausrichten auf die Faktoren Zeit, Kosten, Kapazität und Qualität oder auf die übergreifende Sicht Verschwendung)
• Prozessumsetzung (planvolle, strukturierte Entwicklung, technische Realisierung und Überführung in den laufenden Betrieb)

Eine vollkommen getrennte Betrachtung der Disziplinen ist jedoch nicht möglich: Die Geschäftsprozessmodellierung bedingt für die Modellierung der Ist-Prozess immer eine Geschäftsprozessanalyse (siehe Abschnitt Analyse der Geschäftstätigkeit) oder für die Modellierung der Soll-Prozesse Vorgaben aus dem Prozessdesign (siehe Abschnitte Business Process Reengineering und Geschäftsprozessoptimierung).

Der Schwerpunkt der Geschäftsprozessmodellierung liegt auf der Darstellung des Ablaufs von Tätigkeiten (Aktivitäten), nach Hermann J. Schmelzer und Wolfgang Sesselmann bestehend «aus der funktionsüberschreitenden Verkennung wertschöpfender Aktivitäten, die spezifische, vom Kunden erwartete Leistungen erzeugen und deren Ergebnisse strategische Bedeutung für das Unternehmen haben. Sie können sich über Unternehmensgrenzen hinweg erstrecken und Aktivitäten von Kunden, Zulieferern oder auch Konkurrenten einbinden.»^{[3] (Kapitel 2.1 Unterschiede zwischen Prozessen und Geschäftsprozessen)}

Aber auch weitere Merkmale (Sachverhalte) wie Daten und Geschäftsobjekte (Inputs / Outputs), Organisationseinheiten und Rollen (ausführende/verantwortliche/konsultierte/informierte Person, siehe RACI), Ressourcen und Systeme sowie Richtlinien/Vorgaben (Arbeitsmittel), Anforderungen, Kennzahlen usw. können modelliert werden.

Je mehr dieser Merkmale in die Geschäftsprozessmodellierung eingebracht werden, desto besser bildet die Abstraktion der Geschäftsprozessmodelle die Wirklichkeit ab – und desto komplexer werden die Geschäftsprozessmodelle. «Zur Reduktion der Komplexität und zur Verbesserung der Verständlichkeit und Transparenz der Modelle empfiehlt sich die Anwendung eines Sichtenkonzepts.»^{[1] (Kapitel 2.4 Sichten der Prozessmodellierung)} Dort findet sich auch eine knappe Gegenüberstellung der Sichtenkonzepte von fünf relevanten deutschsprachigen Schulen der Wirtschaftsinformatik: 1) August W. Scheer, 2) Hubert Österle, 3) Otto K. Ferstl und Elmar J. Sinz, 4) Hermann Gehring und 5) Andreas Gadatsch Weitere Details zu Sichtenkonzepten finden sich auch in Unternehmensabbildung.

Die Bezeichnung Sichten (August W. Scheer, Otto K. Ferstl und Elmar J. Sinz, Hermann Gehring und Andreas Gadatsch) ist nicht in allen Schulen der Wirtschaftsinformatik einheitlich – alternative Bezeichnungen sind Gestaltungsdimensionen (Hubert Österle) oder Perspektiven (Zachman).

M. Rosemann, A. Schwegmann und P. Delfmann sehen im Sichtenkonzept jedoch auch Nachteile: «Dabei ist es denkbar, Informationsmodelle für jede Perspektive separat und damit teilweise redundant zu erstellen. Redundanzen bedeuten jedoch immer einen erhöhten Pflegeaufwand und gefährden die Konsistenz der Modelle.»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle)}

Nach Andreas Gadatsch wird die Geschäfts-Prozessmodellierung neben Prozessabgrenzung und Prozessführung als ein Teil des Geschäfts-Prozessmanagements verstanden.^{[1] (Kapitel 1.1 Prozess-Management)}

Ebenso ist die Geschäftsprozessmodellierung ein zentraler Aspekt der ganzheitlichen Unternehmensabbildung – die sich darüber hinaus auch noch mit der Abbildung des Unternehmensleitbildes, der Unternehmenspolitik/Corporate Governance, der Aufbauorganisation, der Ablauforganisation, der Anwendungsarchitektur, den Regelungen und den Interessengruppen sowie dem Markt beschäftigt.

Nach der European Association of Business Process Management EABPM «werden drei verschiedene Arten von End-To-End Geschäftsprozessen unterschieden:

• Führungsprozesse
• Ausführungsprozesse und
• Unterstützungsprozesse.»^{[2](Kapitel 2.4 Prozessarten)}

Diese drei Prozessarten lassen sich in jedem Unternehmen identifizieren und werden in der Praxis beinahe ausnahmslos als oberste Ebene zur Strukturierung der Geschäftsprozessmodelle verwendet.^[5] Für die Bezeichnung Führungsprozesse findet sich auch häufig die Bezeichnung Managementprozesse und für die Bezeichnung Unterstützungsprozesse findet sich auch häufig die Bezeichnung Supportprozesse. Statt der Bezeichnung Ausführungsprozesse hat sich jedoch weitgehend die Bezeichnung Kernprozesse durchgesetzt.^{[3] (Kapitel 6.2.1 Ziele und Konzept), [6] (Kapitel 1.3 Der Prozessbegriff), [7] (Kapitel 4.12.2 Unterscheidung in Kern- und Supportziele), [8] (Kapitel 6.2.2 Identifikation und Grobentwurf)}

Werden die Kernprozesse dann in der nächsten Ebene in Supply-Chain-Management (SCM), Customer-Relationship-Management (CRM) und Product-Lifecycle-Management (PLM) gegliedert, lassen sich auch Standard-Modelle großer Organisationen und Industrieverbände wie das SCOR-Modell in die Geschäftsprozessmodellierung integrieren.

Ziel der Geschäftsprozessmodellierung ist eine – meist grafische – Darstellung von End-To-End Prozessen, wobei komplexe Sachverhalte der Realität mittels einer einheitlichen (systematisierten) Abbildung dokumentiert und auf die substantiellen (Merkmale) reduziert werden. Dabei spielen oft auch regulatorische Vorgaben an die Dokumentation von Prozessen eine Rolle (z. B. Dokumentenlenkung, Rückverfolgbarkeit oder Integrität), etwa aus dem Qualitätsmanagement, Informationssicherheitsmanagement oder Datenschutz.

Die Geschäftsprozessmodellierung beginnt typischerweise mit der Bestimmung der Umfeldanforderungen: Als Erstes ist der Zweck der Modellierung (Einsatzzwecke) zu ermitteln. Dabei ist zu berücksichtigen, dass Geschäftsprozessmodelle inzwischen häufig eine multifunktionale Verwendung erfahren (siehe oben). Als Zweites sind die Modelladressaten zu bestimmen, da die Eigenschaften des zu erstellenden Modells ihren Anforderungen gerecht werden müssen. Daran schließt sich dann die Bestimmung der zu modellierenden Geschäftsprozesse an.

Entsprechend der Zielsetzung der Modellierung werden die Merkmale des Geschäftsprozesses spezifiziert, die im Modell abgebildet werden sollen. Dies sind in der Regel nicht nur die den Prozess konstituierenden Funktionen, einschließlich der zwischen ihnen vorhandenen Beziehungen, sondern noch eine Anzahl weiterer Merkmale, wie z. B. Organisationseinheiten, Input, Output, Ressourcen, Informationen, Medien, Transaktionen, Ereignisse, Zustände, Bedingungen, Operationen und Methoden.

Im Einzelnen können zu den Zielen der Geschäftsprozessmodellierung gehören (vergleiche: Association of Business Process Management Professionals (ABPMP)^{[2] (Kapitel 3.1.2 Prozessmerkmale und Eigenschaften)}):

• Dokumentation der Geschäftsprozesse des Unternehmens
  • um Kenntnis über die Geschäftsprozesse zu erlangen
  • um Unternehmenseinheit(en) mit den geltenden Regelungen abzubilden
  • um Geschäftsprozesse an andere Standorte zu übertragen
  • um die Anforderungen neuer Geschäftsaktivitäten zu ermitteln
  • um dem Regelwerk aus Verfahrens- und Arbeitsanweisungen einen äußeren Rahmen zu geben
  • um Auflagen von Geschäftspartnern oder Verbänden zu erfüllen (zum Beispiel Zertifizierungen)
  • um Vorteile gegenüber Mitbewerbern zu erlangen (zum Beispiel bei Ausschreibungen)
  • um gesetzlichen Vorschriften zu genügen (zum Beispiel für Betreiber kritischer Infrastrukturen, Banken oder Produzenten von Rüstungsgütern)
  • um die Erfüllung von Standards und Compliance-Anforderungen zu überprüfen
  • um die Basis für Kommunikation und Diskussion zu schaffen
  • um Mitarbeiter zu schulen oder einzuarbeiten
  • um Wissensverlust (zum Beispiel durch Mitarbeiterabgang) zu vermeiden
  • um das Qualitäts- und Umweltmanagement zu unterstützen
• Festlegung von KPIs und Überwachung der Prozessleistung
  • um die Prozessgeschwindigkeit zu erhöhen
  • im die Zykluszeit zu reduzieren
  • um die Qualität zu erhöhen
  • um die Kosten zu senken, wie Arbeits-, Material-, Ausschuss- oder Kapitalkosten
• Vorbereitung / Durchführung einer Geschäftsprozessoptimierung (die i. d. R. mit einer Analyse der aktuellen Situation beginnt)
  • um die Analyse der Ist-Situation zu unterstützen
  • um alternative Prozesse zu entwickeln
  • um neue Organisationsstrukturen einzuführen
  • um Unternehmensaufgaben auszulagern
  • um Unternehmensabläufe umzugestalten, zu straffen oder zu verbessern (z. B. mit Hilfe des CMM)
• Vorbereitung eines Informationstechnik-Projektes
  • um eine Softwareauswahl zu unterstützen
  • um das Customizing einer Standardsoftware zu unterstützen
  • um eine Automatisierung bzw. IT-Unterstützung mit einem Workflow-Management-System einzuführen
• Definition von Schnittstellen und SLAs
• Modularisierung der Unternehmensabläufe
• Benchmarking zwischen Unternehmensteilen, Partnern und Konkurrenten
• Prozesskostenrechnung und Simulation durchführen
  • um zu verstehen, wie der Prozess auf unterschiedliche Belastungssituationen oder erwartete Veränderungen reagiert
  • die Wirksamkeit von Maßnahmen zur Geschäftsprozessoptimierung zu bewerten und Alternativen zu vergleichen
• Best Practice finden
• organisatorische Veränderungen begleiten
  • wie Veräußerung oder Teilveräußerung
  • wie Zukauf und Integration von Unternehmen oder Unternehmensteilen
  • wie Einführung oder Wechsel von IT-Systemen oder Organisationsstrukturen
• Teilnahme an Wettbewerben (wie EFQM).

Da die Geschäftsprozessmodellierung an sich keinen direkten Beitrag zum finanziellen Erfolg eines Unternehmens leistet, ergibt sich aus dem wichtigsten Ziel eines Unternehmens, der Gewinnerzielungsabsicht, keine Motivation zur Geschäftsprozessmodellierung. Die Motivation eines Unternehmens, Geschäftsprozessmodellierung zu betreiben, ergibt sich daher immer aus dem jeweiligen Einsatzzweck. Michael Rosemann, Ansgar Schwegmann und Patrick Delfmann listen eine Reihe von Einsatzzwecken als Motivation für die Geschäftsprozessmodellierung auf:

• Organisations-Dokumentation, mit der «Zielsetzung, die Transparenz über die Prozesse zu erhöhen, um dadurch die Kommunikation über die Prozesse in ihrer Effizienz zu erhöhen»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle), [1] (Kapitel 2.5.4 Einsatzbereiche der Prozessmodellierung in der Praxis)} einschließlich der Möglichkeit für die Erstellung von Prozess-Templates, um Unternehmensfunktionen zu verlagern oder zu replizieren, oder dem Ziel ein komplettes Unternehmensmodell zu erstellen
• Prozessorientierte Reorganisation, sowohl im Sinne des «(revolutionären) Business Process Reengineering als auch im Sinne einer kontinuierlichen (evolutionären) Prozessverbesserung»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle)} mit dem Ziel einer Schwachstellenanalyse^{[1] (Kapitel 2.5.4 Einsatzbereiche der Prozessmodellierung in der Praxis)}, Prozessoptimierung (z. B. durch Kontrolle und Reduktion der Total Cycle Time^[9] (TCT), durch Kaizen, Six Sigma usw.) oder einer Prozess-Standardisierung
• Kontinuierliches Prozessmanagement, als «eine auf Dauerhaftigkeit ausgerichtete Planung, Durchführung und Kontrolle der Prozesse»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle)}
• Zertifizierungen nach DIN ISO/IEC 9001 (oder ebenso nach ISO/IEC 14001, ISO/IEC 27001 usw.)
• Benchmarking, definiert als «Vergleich unternehmensindividueller Strukturen und Performance mit ausgewählten internen oder externen Referenzen. Im Kontext der Prozessmodellierung kann dies den Vergleich von Prozessmodellen (strukturelles Benchmarking) oder den Vergleich von Prozesskenzahlen umfassen»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle)}
• Wissensmanagement mit dem «Ziel, die Transparenz über die Unternehmensressource Wissen zu erhöhen, um auf dieser Basis den Prozess des Identifizierens, Akquirierens, Nutzens, Weiterentwickelns und Verteilens von Wissen zu verbessern»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle)}
• Auswahl von ERP-Software, die ihre Funktionalität «oft in Form von (softwarespezifischen) Referenzmodellen dokumentiert, so dass es sich anbietet, zur Softwareauswahl auch einen Abgleich der unternehmensindividuellen Prozessmodelle mit diesen softwarespezifischen Modellen heranzuziehen»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle), [1] (Kapitel 2.5.4 Einsatzbereiche der Prozessmodellierung in der Praxis)}
• Modellbasiertes Customizing, also «die Konfiguration von Standardsoftware» häufig mittels «Parametrisierung der Software durch Konfiguration von Referenzmodellen»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle), [1] (Kapitel 2.5.4 Einsatzbereiche der Prozessmodellierung in der Praxis)}
• Softwareentwicklung, unter Nutzung der Prozesse für «die auf konzeptioneller Ebene im Rahmen des sog. Requirement Engineerings erfolgende Beschreibung der Anforderungen an die zu entwickelnde Software»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle), [10] (Kapitel 3 Der Weg zur prozessorientierten Applikationslandschaft), [1] (Kapitel 2.5.4 Einsatzbereiche der Prozessmodellierung in der Praxis)}
• Workflowmanagement, für das die Prozessmodelle «die Grundlage für die Erstellung von instanziierbaren Workflowmodellen»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle)} sind
• Simulation mit dem Ziel «der Untersuchung des Systemverhaltens im Zeitablauf» und der «Identifikation von Schwachstellen, die sich bei einer reinen Modellbetrachtung nicht offenbaren würden»^{[4] (Kapitel 3.2.1 Relevante Perspektiven auf Prozessmodelle)}

Innerhalb eines 1984 initiierten umfangreichen Forschungsprogramms unter dem Titel „Management in the 1990s“ am MIT entstand Anfang der 1990er Jahre der Ansatz des Prozess Re-Engineering. Das Forschungsprogramm hatte die Aufgabe, den Einfluss der Informationstechnologie auf die Art und Weise zu erforschen, wie Organisationen in der Lage sein werden, im Wettbewerbsumfeld der 1990er Jahre und darüber hinaus zu überleben und zu gedeihen. Im Abschlussbericht fasst N. Venkat Venkatraman^[11] das Ergebnis wie folgt zusammen: Die größten Produktivitätssteigerungen lassen sich erreichen, wenn neue Prozesse parallel zu Informationstechnologien geplant werden.

Diesen Ansatz griffen Thomas H. Davenport^{[12] (Part I: A Framework For Process Innovation, Chapter: Introduction)} sowie Michael M. Hammer und James A. Champy^[13] auf und entwickelten ihn zum Business Process Reengineering (BPR) nach heutigem Verständnis weiter, wonach Geschäftsprozesse fundamental neu strukturiert werden, um eine Verbesserung messbarer Leistungsgrößen wie Kosten, Qualität, Service und Zeit zu erreichen.

Business Process Reengineering wurde teils darin kritisiert, dass es von einer „grünen Wiese“ ausginge und daher für gewachsene Unternehmen nicht direkt umsetzbar sei. Hermann J. Schmelzer und Wolfgang Sesselmann beurteilen das so: «Die Kritik an BPR hat in vielen Punkten akademischen Character. … Einige der vorgebrachten Kritikpunkte sind aus Praxissicht berechtigt. Dazu zählt der Hinweis, dass ein zu radikales Vorgehen Risiken des Scheiterns in sich birgt. Besonders problematisch ist, wenn Organisation und Mitarbeiter nicht ausreichend auf BPR vorbereitet werden.»^{[3] (Kapitel 6.2.1 Ziele und Konzept)}

Die High-Level Vorgehensweise zum BPR nach Thomas H. Davenport besteht aus:

1. Identifying Process for Innovation (Identifizierung von Innovationsprozessen)
2. Identifying Change Levers (Identifizierung von Veränderungshebeln)
3. Developing Process Visions (Entwickeln von Prozessvisionen)
4. Understanding Existing Processes (Verstehen bestehender Prozesse)
5. Designing and Prototyping the New Process (Entwerfen und Prototypenerstellung des neuen Prozesses)

Mit der ISO/IEC 27001:2022 sind die Normforderungen an Managementsysteme nun für alle wesentlichen ISO Normen vereinheitlicht und tragen Prozess-Character.

In den Normen ISO/IEC 9001, ISO/IEC 14001, ISO/IEC 27001 ist dies jeweils in Kapitel 4.4 verankert:

In der Bestimmung der Normforderungen an die erforderlichen Prozesse und ihrer Wechselwirkungen wird die ISO/IEC 9001 in Kapitel 4.4.1 so konkret wie keine andere ISO-Norm für Managementsysteme und definiert «Die Organisation muss die Prozesse bestimmen, die für das Qualitätsmanagementsystem benötigt werden, sowie deren Anwendung innerhalb der Organisation festlegen, und muss»^{[14] (Clause 4.4 Quality management system and its processes) ← automatische Übersetzung der Englischen Originalfassung} gefolgt von einer Auflistung detaillierter Normforderungen:

• die erforderlichen Eingaben und die erwarteten Ergebnisse dieser Prozesse bestimmen
• die Abfolge und die Wechselwirkung dieser Prozesse bestimmen
• die Kriterien und Verfahren (einschließlich Überwachung, Messungen und die damit verbundenen Leistungsindikatoren), die benötigt werden, um das wirksame Durchführen und Steuern dieser Prozesse sicherzustellen, bestimmen und anwenden
• die für diese Prozesse benötigten Ressourcen bestimmen und deren Verfügbarkeit sicherstellen
• die Verantwortlichkeiten und Befugnisse für diese Prozesse zuweisen
• die in Übereinstimmung mit den Anforderungen nach Kapitel 6.1 bestimmten Risiken und Chancen behandeln
• diese Prozesse bewerten und jegliche Änderungen umsetzen, die notwendig sind, um sicherzustellen, dass diese Prozesse ihre beabsichtigten Ergebnisse erzielen
• die Prozesse und das Qualitätsmanagementsystem verbessern

Kapitel 4.4.2 geht darüber hinaus und definiert weiter: «Die Organisation muss in erforderlichem Umfang»^{[14] (Clause 4.4 Quality management system and its processes) ← automatische Übersetzung der Englischen Originalfassung} gefolgt von:

• dokumentierte Informationen aufrechterhalten, um die Durchführung ihrer Prozesse zu unterstützen
• dokumentierte Informationen aufbewahren, so dass darauf vertraut werden kann, dass die Prozesse wie geplant durchgeführt werden

Die Umsetzung der Normforderungen an die erforderlichen Prozesse und ihrer Wechselwirkungen und insbesondere der Nachweis für die Umsetzung der Normforderungen mit einer adäquaten Dokumentation (Geschäftsprozessmodellierung) ist gängige Praxis. Das bedeutet dann auch, dass auch die Normforderungen an dokumentierten Informationen relevant für eine Geschäftsprozessmodellierung im Rahmen eines Managementsystems nach ISO sind.

In den Normen ISO/IEC 9001, ISO/IEC 14001, ISO/IEC 27001 ist dies jeweils in Kapitel 7.5 (in jeder Norm dann jeweils mit den Unterkapiteln „7.5.1. Allgemeines“, „7.5.2. Erstellen und Aktualisieren“ sowie „7.5.3. Lenkung dokumentierter Information“) verankert. Die hier beispielhaft herangezogenen Normforderungen der ISO/IEC 9001 beinhalten:

In Unterkapitel „7.5.1 Allgemeines“ wird gefordert, dass das Managementsystem der Organisation

• «die von dieser Internationalen Norm geforderte dokumentierte Information und
• dokumentierte Information, welche die Organisation als notwendig für die Wirksamkeit des Qualitätsmanagementsystems bestimmt hat,»^{[14] (Clause 7.5.1 General) ← automatische Übersetzung der Englischen Originalfassung}

beinhalten muss.

In Unterkapitel „7.5.2 Erstellen und Aktualisieren“ wird gefordert, dass die Organisation beim Erstellen und Aktualisieren dokumentierter Information

• «angemessene Kennzeichnung und Beschreibung (z. B. Titel, Datum, Autor oder Referenznummer),
• angemessenes Format (z. B. Sprache, Softwareversion, Graphiken) und Medium (z. B. Papier, elektronisch) und
• angemessene Überprüfung und Genehmigung im Hinblick auf Eignung und Angemessenheit»^{[14] (Clause 7.5.2 Creating and updating) ← automatische Übersetzung der Englischen Originalfassung}

sicherstellen muss.

In Unterkapitel „7.5.3 Lenkung dokumentierter Information“ wird gefordert, dass die dokumentierten Information gelenkt werden, um

• «verfügbar und für die Verwendung an dem Ort und zu der Zeit geeignet ist, an dem bzw. zu der sie benötigt wird und
• angemessen geschützt wird (z. B. vor Verlust der Vertraulichkeit, unsachgemäßem Gebrauch oder Verlust der Integrität)»^{[14] (Clause 7.5.3 Control of documented information) ← automatische Übersetzung der Englischen Originalfassung}

sicherzustellen sowie folgende Tätigkeiten

• «Verteilung, Zugriff, Auffindung und Verwendung;
• Ablage/Speicherung und Erhaltung, einschließlich Erhaltung der Lesbarkeit,
• Überwachung von Änderungen (z. B. Versionskontrolle) und
• Aufbewahrung und Verfügung über den weiteren Verbleib»^{[14] (Clause 7.5.3 Control of documented information) ← automatische Übersetzung der Englischen Originalfassung}

zu berücksichtigen sind.

Aufgrund der Normforderungen,

1. die erforderlichen Prozesse und ihrer Wechselwirkungen zu bestimmen und kontinuierlich zu verbessern,
2. die als notwendig erachteten Inhalte der dokumentierten Informationen zu bestimmen und zu pflegen sowie
3. einen sicheren Umgang mit dokumentierten Informationen (Schutz, Zugriff, Überwachung und Aufbewahrung) zu gewährleisten

ist eine Vorbereitung auf die ISO-Zertifizierung eines Managementsystems eine sehr gute Gelegenheit, Geschäftsprozessmodellierung in der Organisation zu etablieren oder voranzutreiben.

Hermann J. Schmelzer und Wolfgang Sesselmann stellen heraus, dass das Verbesserungsfeld der von ihnen als Beispiele für die Prozessoptimierung genannten drei Methoden (Kontrolle und Reduktion der Total Cycle Time (TCT), Kaizen, Six Sigma) jeweils Prozesse sind: Bei der Total Cycle Time (TCT) sind es die Geschäftsprozesse (End-To-End-Prozesse) und Teilprozesse, bei Kaizen sind es die Prozess-Schritte und Tätigkeit und bei Six Sigma sind es die Teilprozesse, Prozess-Schritte und Tätigkeit.^{[3] (Kapitel 6.3.1 Total Cycle Time (TCT), Kaizen und Six Sigma im Vergleich)}

Für die Total Cycle Time (TCT) listen Hermann J. Schmelzer und Wolfgang Sesselmann folgende wesentliche Merkmale auf:^{[3] (Kapitel 6.3.2 Total Cycle Time (TCT))}

• Ermitteln von Barrieren, die den Prozessablauf behindern
• Beseitigen von Barrieren und Ersatzprozessen
• Messen der Wirkungen der Barrierebeseitigung
• Vergleich der Messgrößen mit den Zielvorgaben

Folglich muss die Geschäftsprozessmodellierung für die TCT eine adäquate Dokumentation der Barrieren, Barrierenbehandlung und Messung unterstützen.

Betrachtet man die Werkzeuge von Kaizen, ist zunächst kein direkter Zusammenhang zu Geschäftsprozessen oder zur Geschäftsprozessmodellierung erkennbar. Dennoch können Kaizen und Geschäftsprozessmanagement voneinander profitieren. «Im Rahmen des Geschäftsprozessmanagements werden die KAIZEN-Ziele unmittelbar aus den Zielen für Geschäftsprozesse und Teilprozesse abgeleitet. Über diese Verbindung wird gewährleistet, dass Kaizen-Maßnahmen die Geschäftsziele unterstützen.»^{[3] (Kapitel 6.3.3 KAIZEN)}

Six Sigma ist auf die Vermeidung von Fehlern und Verbesserung der Prozessfähigkeit ausgelegt, so dass der Anteil der Prozessergebnisse, der die Anforderungen erfüllt, 6σ beträgt – oder anders ausgedrückt, bei einer Million Prozessergebnissen nur 3,4 Fehler auftreten. Hermann J. Schmelzer und Wolfgang Sesselmann führen hierzu aus: «Häufig stoßen Unternehmen bei einem Niveau von 4σ auf erhebliche Widerstände, die eine Neukonzeption der Geschäftsprozesse im Sinne von Business Process Reengineering (Design for Six Sigma) erforderlich machen.»^{[3] (Kapitel 6.3.4 Six Sigma)} Für eine reproduzierbare Messung der Prozessfähigkeit ist die genaue Kenntnis der Geschäftsprozesse erforderlich und für ein Design for Six Sigma bietet sich die Geschäftsprozessmodellierung an. Daher nutzt Six Sigma die Geschäftsprozessmodellierung nach SIPOC als wesentlichen Teil der Methodik und die Geschäftsprozessmodellierung mittels SIPOC hat sich als Standard-Werkzeug für Six Sigma etabliert.

Bei der überbetrieblichen Geschäftsprozessmodellierung geht es darum, die Einflüsse externer Stakeholder in die Betrachtung einzubeziehen oder eine überbetriebliche Vergleichbarkeit der Geschäftsprozesse zu erreichen, um z. B. Benchmarking zu ermöglichen.

Martin Kugler listet in diesem Zusammenhang folgende Anforderungen an die Geschäftsprozessmodellierung auf:^{[17] (Kapitel 14.2.1 Anforderungen an die überbetriebliche Geschäftsprozessmodellierung)}

• Mitarbeiter aus unterschiedlichen Unternehmen müssen die Geschäftsprozessmodelle verstehen, weshalb er Bekanntheitsgrad der Darstellungstechniken (Darstellung) besonders wichtig ist.
• Die Akzeptanz der Geschäftsprozessmodellierung steigt mit der Einfachheit der Darstellung, sie muss übersichtlich, leicht verständlich und möglichst selbsterklärend sein.
• Die Darstellung der überbetrieblichen Geschäftsprozessmodelle muss in den verschiedenen Unternehmen einheitlich erfolgen, um eine durchgängige Verständlichkeit und Akzeptanz zu erreichen, gerade denn in den verschiedenen Unternehmen innerbetrieblich unterschiedliche Darstellungen verwendet werden.
• Es muss eine branchenneutrale Darstellungstechnik verwendet werden, da die verschiedenen Unternehmen entlang der Wertschöpfungskette (Lieferant, Hersteller, Händler, Kunde) typischerweise aus unterschiedlichen Branchen stammen.

Die folgenden Abschnitte dieses Artikels werden einzelne Aspekte der Vorgehensweise für die Geschäftsprozessmodellierung näher betrachten:

1. Definition der fachlichen Anforderungen an die Geschäftsprozessmodellierung
2. Analyse der Geschäftstätigkeit
3. Definition der Geschäftsprozesse
4. Weitere Strukturierung der Geschäftsprozesse
5. Zuweisung der Prozessverantwortung
6. Modellierung von Geschäftsprozessen
7. Modellkonsolidierung
8. Prozessverkettung und Prozess-Schnittstellen
9. Prozessmanagement.

Je nach beabsichtigtem Zweck der Geschäftsprozessmodellierung und Zielgruppe muss im Vorfeld festgelegt werden, welche Anforderungen von der Geschäftsprozessmodellierung zwingend umgesetzt werden müssen und welche Anforderungen optional umgesetzt werden können.

Einige Einsatzzwecke wie die überbetriebliche Geschäftsprozessmodellierung, die Prozesskostenrechnung oder die Simulation stellen weitergehende Anforderungen an die Geschäftsprozessmodellierung.

Einige der Anforderungen sind auf spezielle Einsatzzwecke wie Prozesskostenrechnung oder Simulation ausgerichtet und nicht von allgemeinem Charakter. Ist aber Vorbereitung / Durchführung einer Geschäftsprozessoptimierung das Ziel der Geschäftsprozessmodellierung, kann deren Erfassung erforderlich sein.

Aus einigen der bisher formulierten Anforderungen (z. B. Anf.-04: Eingaben und Ergebnisse, Anf.-06: Richtlinien und Vorgaben, Anf.-08: Ressourcen, Anf.-09: Verantwortliche und deren Befugnisse, Anf.-10: Risiken und Chancen) lassen sich weitere oder allgemeiner gefasste Prozessmerkmale^{[2] (Kapitel 3.1.2 Prozessmerkmale und Eigenschaften), [1] (Kapitel 2.5.2 Begriffssystem)} für die Geschäftsprozessmodellierung identifizieren oder ableiten – z. B.:

• Eingaben (Inputs) und Ergebnisse (Outputs) repräsentieren Geschäftsobjekte oder Daten nach dem EVA-Prinzip, Vorleistungsgüter oder Produkten bzw. Leistungen
• Prüfungen / Kontrollen / Tests (zur Einhaltung der Vorgaben)
• Materialien, Anlagen, Anwendungssysteme und weitere Beteiligte wie Ausführende, Unterstützer, Berater, Informierte (als Ressourcen)
• Rollenbeschreibungen und/oder Berechtigungskonzepte (zur Beschreibung der Pflichten und Befugnisse der Aufgabenträger)
• Maßnahmen (zur Reduktion von Risiken)

Die Analyse der Geschäftstätigkeit ermittelt und definiert die Rahmenbedingungen für eine erfolgreiche Geschäftsprozessmodellierung. Hier sollte das Unternehmen damit beginnen,

• auf Basis des Geschäftsmodells und wo es in der Wertschöpfungskette positioniert ist die für sich relevanten Einsatzzwecke der Geschäftsprozessmodellierung zu definieren,
• aus der Unternehmensstrategie die Strategie für den dauerhaften Erfolg der Geschäftsprozessmodellierung abzuleiten und daraus einen Ansatz für die Strukturierung der Geschäftsprozessmodelle zu entwickeln. Sowohl die relevanten Einsatzzwecke als auch die Strategie beeinflussen direkt die Prozesslandkarte.

Diese Strategie für den dauerhaften Erfolg der Geschäftsprozessmodellierung kann durch die marktorientierte Sicht und/oder die ressourcenbasierte Sicht geprägt sein. Jörg Becker und Volker Meise führen hierzu aus: «Während bei der Marktsicht die Branche und das Verhalten der Wettbewerber die Strategie eines Unternehmens unmittelbar bestimmen, geht der ressourcenorientierte Ansatz von einer inneren Sicht aus, indem er die Stärken und Schwächen des Unternehmens analysiert und daraus die Entwicklungsrichtung der Strategie ableitet.»^{[7] (Kapitel 4.6 Die ressourcenbasierte Sicht - Resource-based View)} Und weiter: «Der anfangs in der Literatur formulierte Alternativcharacter zwischen Market- und Resource-based View ist mittlerweile einer differenzierten Sichtweise gewichen. Der Kernkompetenzansatz wird als ein wichtiger Beitrag zur Erklärung von Erfolgspotentialen eingeschätzt, der neben den bestehenden, marktorientierten Ansätzen genutzt wird.»^{[7] (Kapitel 4.7 Kombination der Sichten)} Abhängig von der Strategie des Unternehmens wird die Prozesslandkarte die Geschäftsprozessmodelle also eher mit Blick auf die Marktbearbeitung, mit Blick auf die Ressourcenoptimierung oder in ausgewogener Weise.

Anschließend werden durch die Analyse der Geschäftstätigkeit (siehe auch Geschäftsprozessanalyse) die Geschäftsprozesse eines Unternehmens identifiziert und voneinander abgegrenzt. Ein Geschäftsprozess ist eine Sammlung von zusammenhängenden, strukturierten Tätigkeiten (Aktivitäten), die eine bestimmte Dienstleistung oder ein bestimmtes Produkt (zur Erfüllung eines bestimmten Ziels) für einen bestimmten Kunden oder eine bestimmte Kundengruppe hervorbringen.

Die European Association of Business Process Management EABPM formuliert: «In einem ersten Schritt der Prozessgestaltung oder -umgestaltung sollte ein gemeinsames Verständnis des Ist-Prozesses und seiner Ausrichtung auf die Ziele hergestellt werden.»^{[2] (Kapitel 4 Prozessanalyse)}

Der bei der Analyse der Ist-Prozesse entstehende Aufwand wird in der Literatur immer wieder mal kritisiert, besonders von Befürwortern des Business Process Reengineering (BPR), und es wird vorgeschlagen, gleich mit der Definition des Soll-Zustandes zu beginnen.

Hermann J. Schmelzer und Wolfgang Sesselmann diskutieren und bewerten andererseits die in der Literatur vorgebrachte Kritik am radikalen Vorgehen des Business Process Reengineering (BPR) und «empfehlen, Ist-Analysen durchzuführen. Eine Neugestaltung muss die gegenwärtigen Schwachstellen kennen, um diese ausmerzen zu können. Die Analyseergebnisse liefern zudem Argumente, warum eine Prozesserneuerung notwendig ist. Auch für den Übergang vom Ist- in den Soll-Zustand ist es wichtig, die Ausgangssituation zu kennen. Der Analyseaufwand sollte sich jedoch in engen Grenzen halten. Auch sollten die Analyseergebnisse nicht zu stark die Neugestaltung beeinflussen».^{[3] (Kapitel 6.2.2 Kritische Beurteilung des BPR)}

Timo Füermann führt dazu aus: «Nachdem die Geschäftsprozesse identifiziert und benannt wurden, werden sie nun in einer Übersicht zusammengestellt. Solche Übersichten werden im Englischen als Process Map bezeichnet.»^{[18] (Kapitel 2.4 Die Process Map erstellen)}

Bei Jörg Becker und Volker Meise findet sich folgende Aufzählung von Aktivitäten, um Geschäftsprozesse zu strukturieren:

• «Enumeration der Hauptprozesse,
• Festlegung der Prozessgrenzen,
• Bestimmung der strategischen Relevanz eines jeden Prozesses,
• Analyse des Verbesserungsbedarfs eines Prozesses und
• Bestimmung der politischen und kulturellen Bedeutung des Prozesses»^{[7] (Kapitel 4.10 Prozess-Struktur festlegen)}

Die Strukturierung der Geschäftsprozesse beginnt in aller Regel mit der Unterscheidung in Management-, Kern- und Supportprozesse.

• Managementprozesse steuern den Betrieb eines Unternehmens. Typische Managementprozesse sind die Corporate Governance und das Strategische Management. Sie legen Unternehmensziele fest und überwachen die Zielerreichung.
• Kernprozesse erzeugen bilden das Kerngeschäft und schaffen den primären Wertstrom. Typische operative Prozesse sind Einkauf, Fertigung, Marketing und Vertrieb. Sie erzeugen einen sichtbaren, unmittelbaren Kundennutzen.
• Supportprozesse stellen betriebliche Ressourcen bereit und verwalten diese. Sie unterstützen die Kern- und Managementprozesse, indem sie den reibungslosen Ablauf des Geschäftslebens sichern. Beispiele sind Buchhaltung, Personalbeschaffung und Technischer Support.

Da die Kerngeschäftsprozesse klar die Mehrheit der identifizierten Geschäftsprozesse eines Unternehmens ausmachen, hat es sich durchgesetzt, die Kernprozesse noch einmal zu unterteilen. Dafür gibt es je nach Unternehmenstyp und Geschäftstätigkeit verschiedene Ansätze. Diese Ansätze werden wesentlich von den definierten Einsatzzwecken der Geschäftsprozessmodellierung und der Strategie für den dauerhaften Erfolg der Geschäftsprozessmodellierung beeinflusst.

Bei einer schwerpunktmäßig marktbasierten Strategie werden oft vom Kunden oder Lieferanten zum Händler oder Kunden durchgängige Kerngeschäftsprozesse definiert (z. B. „Vom Angebot zum Auftrag“, „Vom Auftrag zur Rechnung“, „Von der Bestellung zur Lieferung“, „Von der Idee zum Produkt“ usw.). Bei einer schwerpunktmäßig ressourcenbasierten Strategie werden die Kerngeschäftsprozesse oft in Anlehnung an die zentralen Unternehmensfunktionen definiert („Aufträge gewinnen“, „Material beschaffen und bereitstellen“, „Produkte entwickeln“, „Dienste bereitstellen“ usw.).

Bei einer differenzierten Sichtweise ohne klarem Schwerpunkt auf der Marktsicht oder der Ressourcensicht werden die Kerngeschäftsprozesse typischerweise in CRM, PLM und SCM unterschieden.

• CRM (Customer-Relationship-Management) beschreibt die Geschäftsprozesse zur Kundengewinnung, Angebots- und Auftragserstellung sowie Betreuung und Wartung
• PLM (Product-Lifecycle-Management) beschreibt die Geschäftsprozesse von der Produktportfolioplanung über Produktplanung, Produktentwicklung und Produktpflege bis zum Produktauslauf sowie Individualentwicklungen
• SCM (Supply-Chain-Management) beschreibt die Geschäftsprozesse vom Lieferantenmanagement über Einkauf und alle Fertigungsstufen bis zur Lieferung an den Kunden, ggf. mit Installation und Inbetriebnahme

Aber auch andere Herangehensweisen zur Strukturierung der Kerngeschäftsprozesse sind gebräuchlich, zum Beispiel aus Sicht der Kunden, Produkte oder, Vertriebswege.

• „Kunden“ beschreibt die Geschäftsprozesse, die spezifischen Kundengruppen (zum Beispiel Privatkunde, Geschäftskunde, Anleger, Institutioneller Kunde) zuzuordnen sind
• „Produkte“ beschreibt die Geschäftsprozesse, die produktspezifisch ablaufen (zum Beispiel Girokonto, Wertpapierdepot, Kredit, Emission)
• „Vertriebswege“ beschreibt die Geschäftsprozesse, die für die Art der Kundengewinnung und -betreuung typisch sind (zum Beispiel Direktvertrieb, Partnervertrieb, Online).

Das Ergebnis der Strukturierung der Geschäftsprozesse eines Unternehmens ist die Prozesslandkarte (zum Beispiel dargestellt als Wertschöpfungskettendiagramm). Hermann J. Schmelzer und Wolfgang Sesselmann ergänzen noch: «Zwischen den Geschäftsprozessen bestehen Verbindungen und Abhängigkeiten. Sie beruhen auf dem Transfer von Leistungen und Informationen. Diese Wechselbeziehungen zu kennen ist wichtig, um die Geschäftsprozesse zu verstehen, zu leiten und zu lenken.»^{[3] (Kapitel 2.4.3 Prozess-Landkarte)}

Die Definition der Geschäftsprozesse beginnt häufig mit den Kernprozessen des Unternehmens, weil sie dadurch, dass sie

• eigene Marktaufgaben erfüllen,
• weitgehend autonom/eigenständig sowie unabhängig von anderen Geschäftsfeldern agieren und
• einen Beitrag zum Geschäftserfolg des Unternehmens liefern,

für das Unternehmen

• eine starke Außenwirkung entfalten,
• gut von anderen Geschäftsprozessen abgegrenzt werden können und
• das größte Potential für eine Geschäftsprozessoptimierung bieten, sowohl durch Verbesserung der Prozessleistung oder der Produktivität als auch durch Verringerung der Kosten.

Der Umfang eines Geschäftsprozesses sollte so gewählt werden, dass er eine überschaubare Zahl an Teilprozessen beinhaltet, gleichzeitig soll aber auch die Gesamtzahl der Geschäftsprozesse im Rahmen bleiben. Fünf bis acht Geschäftsprozesse pro betriebliche Einheit decken meist die Leistungsspanne eines Unternehmens ab.

Jeder Geschäftsprozess sollte für sich selbstständig sein – allerdings sind die Prozesse untereinander vernetzt.

Zur Definition eines Geschäftsprozesses gehört: Welches Ergebnis soll bei Beendigung vorliegen? Welche Aktivitäten sind dazu notwendig? Welche Objekte sollen bearbeitet werden (Aufträge, Rohstoffe, Einkäufe, Produkte, …)? Anfangs- und Endpunkt festlegen. Festlegung operationaler Ziele.

Abhängig von der Unternehmenskultur (eher offen für Veränderungen oder eher besitzstandwahrend) und der Kommunikation kann die Definition der Geschäftsprozesse eine leichte oder schwere Aufgabe sein - je nachdem ob die fachverantwortlichen Organisationsmitglieder (z. B. Abteilungsleiter) gern unterstützen. Dabei kommt der Kommunikation erhebliche Bedeutung zu und Jörg Becker und Volker Meise führen dazu aus: «Das Ziel der Kommunikationsstrategie bei einer Organisationsgestaltungsmaßnahme» … (und üblicherweise folgt auf die Geschäftsprozessmodellierung die Geschäftsprozessoptimierung, also eine Änderung in der Prozessorganisation - das wissen die Beteiligten) … «muss es sein, die Organisationsmitglieder zu einer Unterstützung der geplanten Struktur zu bewegen.»^{[7] (Kapitel 4.15 Einflussmöglichkeiten des Designs des Ordnungsrahmens)} Bei erheblichen Widerständen kann aber auch externes Wissen für die Definition der Geschäftsprozesse genutzt werden.

Jörg Becker und Volker Meise nennen dazu zwei Ansätze (Allgemeine Prozessidentifikation und Individuelle Prozessidentifikation) und führen zur allgemeinen Prozessidentifikation aus: «Bei der allgemeinen Prozessdefinition wird davon ausgegangen, dass grundlegende, allgemein gültige Prozesse existieren, die in allen Unternehmen gleich sind.» Weiter heißt es dazu: «Für die allgemeine Prozessidentifikation lassen sich ebenso detaillierte Referenzmodelle einsetzen. Sie beschreiben branchen- oder anwendungssystemspezifisch Prozesse einer Organisation, die noch an den Einzelfall angepasst werden müssen, in ihrer Struktur aber bereits aufeinander abgestimmt sind.»^{[7] (Kapitel 4.11 Allgemeine Prozessidentifikation)}

Jörg Becker und Volker Meise führen zur individuellen Prozessidentifikation aus: «Bei der individuellen oder singulären Prozessidentifikation wird davon ausgegangen, dass entsprechend der Kundenbedürfnisse und der Wettbewerbssituation die Prozesse in jedem Unternehmen unterschiedlich sind und anhand der individuellen Problemlage induktiv identifiziert werden können.»^{[7] (Kapitel 4.12 Individuelle Prozessidentifikation)}

Das Ergebnis der Definition der Geschäftsprozesse ist in der Regel eine grobe Struktur der Geschäftsprozesse als Wertschöpfungskettendiagramm.

Die bisher entstandene grobe Struktur der Geschäftsprozesse wird nun verfeinert - durch Zerlegung in Teilprozesse, die ihre eigenen Attribute haben, aber auch zur Erreichung des Ziels des Geschäftsprozesses beitragen. Diese Zerlegung sollte durch die Einsatzzwecke und Strategie für den dauerhaften Erfolg der Geschäftsprozessmodellierung wesentlich beeinflusst werden und so lange fortgesetzt werden, wie der Zuschnitt der dabei definierten Teilprozesse zur Umsetzung der Einsatzzwecke und Strategie beiträgt.

Ein so entstandener Teilprozess beschreibt mittels eines Modells die Art und Weise, in der Vorgänge ausgeführt werden, um die beabsichtigten wirtschaftlichen Ziele des Unternehmens zu erreichen. Das Modell ist eine Abstraktion der Wirklichkeit (oder eines Soll-Zustandes) und hängt in seiner konkreten Ausprägung von der beabsichtigten Verwendung (Einsatzzweck) ab.

Eine weitere Zerlegung der Teilprozesse kann dann bei Notwendigkeit während der Modellierung von Geschäftsprozessen erfolgen. Sofern sich der Geschäftsprozess als eine Abfolge von Phasen, abgetrennt mit Meilensteinen, darstellen lässt, ist die Zerlegung in Phasen üblich. Sofern es möglich ist, trägt dabei die Übernahme der Meilensteine in die nächste Ebene der Zerlegung zum allgemeinen Verständnis bei.

Das Ergebnis der weiteren Strukturierung der Geschäftsprozesse ist in der Regel eine Hierarchie von Teilprozessen, dargestellt in Wertschöpfungskettendiagrammen. Es ist üblich, dass nicht alle Geschäftsprozesse die gleiche Tiefe der Zerlegung aufweisen. Insbesondere Geschäftsprozesse, die weder sicherheitsrelevant, kostenintensiv oder zu den wirtschaftlichen Zielen beisteuernd sind, werden deutlich weniger tief zerlegt. Ebenso kann als Vorstufe einer für (viel) später geplanten Zerlegung eines Prozesses zunächst ein gemeinsames Verständnis mit einfacheren / weniger aufwändigen Mitteln als Wertschöpfungskettendiagrammen erarbeitet werden - z. B. mit einer textuellen Beschreibung oder mit einem Turtle-Diagramm^{[18] (Kapitel 3.1 Prozessdetails festlegen)} (nicht zu verwechseln mit Turtle-Grafik!).

Komplette, in sich abgeschlossene Abläufe werden zusammengefasst und einem Verantwortlichen oder einem Team übergeben. Der Prozesseigner ist für den Erfolg verantwortlich, schafft die Rahmenbedingungen und koordiniert seine Vorgehensweise mit der der anderen Prozesseigner (siehe auch Accountable in RACI). Des Weiteren kümmert er sich um den Informationsaustausch zwischen den Geschäftsprozessen. Diese Abstimmung ist notwendig, um die gesamte Zielorientierung zu erreichen.

Erfolgt die Dokumentation von Geschäftsprozessen unter Nutzung einer bestimmten Systematik und Darstellung, z. B. graphisch, so spricht man gemeinhin von Modellierung. Das Ergebnis der Dokumentation ist das Geschäftsprozessmodell.

Istmodellierung und Sollmodellierung

Die Frage, ob das Geschäftsprozessmodell durch Istmodellierung oder Sollmodellierung entstehen soll, ist durch die definierten Einsatzzwecke und die Strategie für den dauerhaften Erfolg der Geschäftsprozessmodellierung wesentlich beeinflusst. Das bisherige Vorgehen mit Analyse der Geschäftstätigkeit, Definition der Geschäftsprozesse und weiterer Strukturierung der Geschäftsprozesse ist in jedem Fall ratsam.

Istmodellierung

Ansgar Schwegmann und Michael Laske führen dazu aus: «Die Ermittlung des Istzustandes ist die Basis für die Ermittlung von Schwachstellen und die Lokalisierung von Verbesserungspotentialen. Beispielsweise können Schwachstellen wie organisatorische Brüche oder eine unzureichende DV-Durchdringung erkannt werden.»^{[19] (Kapitel 5.1 Intention der Istmodellierung)}

Gegen eine Istmodellierung sprechen folgende Nachteile:

• die Kreativität der Projektbeteiligten, optimale Sollprozesse zu entwickeln, wird gehämmt, da bei einer nachgelagerten Sollmodellierung eventuell alte Strukturen und Abläufe unreflektiert übernommen werden und
• die Erstellung detaillierter Istmodelle stellt einen erheblichen Aufwand dar, auch beeinflusst dadurch, welche Mühen es macht an Schnittstellen und Verantwortungsübergängen einen Konsens zwischen den Projektbeteiligten zu erzielen

Diese Argumente wiegen besonders schwer, wenn ohnehin ein Business Process Reengineering geplant ist.

Ansgar Schwegmann und Michael Laske listen aber auch eine Reihe von Vorteilen der Istmodellierung auf:^{[19] (Kapitel 5.1 Intention der Istmodellierung)}

• die Modellierung des Istzustandes ist die Basis, um Schwachstellen und Verbesserungspotentiale identifizieren zu können
• die Kenntnis des Istzustandes ist Voraussetzung, um Migrationsstrategien zum Sollzustand zu entwickeln
• die Istmodellierung schafft einen Überblick über die bestehende Situation, der insbesondere für neu involvierte und externe Projektbeteiligte wertvoll sein kann
• die Istmodellierung kann Aufhänger für die Schulung und Heranführung der Projektbeteiligten an die Tools und Methoden sein
• das Istmodell kann als Checkliste für eine spätere Sollmodellierung dienen, damit keine relevanten Sachverhalte übersehen werden
• die Istmodelle können als Ausgangsmodelle für die Sollmodellierung genutzt werden, wenn der Sollzustand zumindest in Teilbereichen stark dem Istzustand ähnelt

Darüber hinaus lassen sich weitere Vorteile finden wie:

• das Istmodell ist geeignet, um eine Zertifizierung des Managementsystems zu unterstützen
• das Istmodell kann als Basis für die Organisationsdokumentation dienen (schriftlich fixierte Ordnung, Vorgaben und Regelungen der Organisation, …)
• auf Basis des Istmodells können die Voraussetzungen für Workflowmanagement geprüft werden (Definiertheit der Prozesse, Wiederholrate, ...)
• auf Basis des Istmodells können Kennzahlen erhoben werden, um nach einer Reorganisation gegen die dann erreichten Kennzahlen verglichen zu werden und den Erfolg der Maßnahmen zu messen

Sollmodellierung

Mario Speck und Norbert Schnetgöke definieren die Zielsetzung der Sollmodellierung wie folgt: «Die Sollprozesse orientieren sich an den strategischen Zielen der Unternehmung. Somit müssen alle Teilprozesse und Einzelaktivitäten eines Unternehmens auf ihren Zielbeitrag hin untersucht werden. Teilprozesse bzw. Aktivitäten, die als nicht wertschöpfend identifiziert werden können und nicht mindestens einem nichtmonetären Unternehmensziel dienlich sind, müssen somit aus den Geschäftsprozessen eliminiert werden.»^{[8] (Kapitel 6.2.3 Erhebung und Dokumentation der Sollmodelle)}

Sie listen auch fünf Grundprinzipien auf, die sich bei der Erstellung von Sollmodellen bewährt haben:

• Eine parallele Verarbeitung der Teilprozesse und Einzelaktivitäten ist einer sequentiellen Verarbeitung vorzuziehen - sie beinhaltet das größere Optimierungspotential.
• Die Erarbeitung eines Teilprozesses sollte möglichst durchgängig von einer Person oder Gruppe erfolgen - dadurch kann die beste Modellqualität erreicht werden.
• Für einzelne Teilprozesse und Einzelaktivitäten sollte in der Verarbeitung eine Selbstkontrolle ermöglicht werden - das senkt die Qualitätssicherungskosten.
• Für jeden Prozess sollte ein, wenn nicht anders möglich zumindest ein interner, Kunde/Abnehmer definiert werden - das stärkt das Kundenbewusstsein und verbessert die Bewertbarkeit der Prozessleistung.
• Lerneffekte, die bei Einführung der Sollprozesse entstehen, sollten mit bedacht werden - das stärkt das Wertschöpfungsbewusstsein der Mitarbeiter.

Das durch Istmodellierung oder Sollmodellierung entstehende Geschäftsprozessmodell besteht aus:

Abgrenzung

August W. Scheer soll in seinen Vorlesungen gesagt haben: Ein Prozess ist ein Prozess ist ein Prozess. Ausgedrückt werden soll damit die Rekursivität des Begriffes, weil sich fast jeder Prozess in kleinere Prozesse (Teilprozesse) zerlegen lässt. Insofern sind Begriffe wie Geschäftsprozess, Hauptprozess, Teilprozess oder Elemantarprozess nur der verzweifelte Versuch, die Ebene der Prozesszerlegung zu benennen. Da es keine allgemeingültige Vereinbarung darüber gibt, welche Granularität ein Geschäftsprozess, Hauptprozess, Teilprozess oder Elementarprozess abbildet, sind die Begriffe nicht universell definiert, sondern immer nur im Kontext des jeweiligen Geschäftsprozessmodells verständlich.

Darüber hinaus verwenden einige deutschsprachigen Schulen der Wirtschaftsinformatik die Begriffe Prozess (im Sinne der Darstellung des Ablaufs von Tätigkeiten (Aktivitäten)) und Funktion (im Sinne einer Unternehmensfunktion / eines abgegrenzten Aufgabenbereichs, der einem Aufgabenträger zugeordnet ist) nicht trennscharf.

So ist es beispielsweise bei August W. Scheer im ARIS möglich, Funktionen aus der Funktionssicht als Prozesse in der Steuerungssicht zu verwenden und umgekehrt. Dies hat zwar den Vorteil, dass bereits definierte Prozesse oder Funktionen übergreifend wiederverwendet werden können, führt aber auch dazu, dass die eigentliche Aufgabe der Funktionssicht verwässert und der ARIS Anwender nicht mehr in der Lage ist, Prozesse und Funktionen voneinander zu trennen.

Das erste Bild zeigt als Wertschöpfungskettendiagramm, wie der Geschäftsprozess Sales-Pipeline bearbeiten anhand seiner Phasen zu Teilprozessen (im Sinne der Darstellung des Ablaufs von Tätigkeiten (Aktivitäten)) zerlegt wurde.

Das zweite Bild zeigt als Funktionsbaum einen Ausschnitt typischer Funktionen (im Sinne einer Unternehmensfunktion / eines abgegrenzten Aufgabenbereichs, der einem Aufgabenträger zugeordnet ist), die anhand der Kompetenzbereiche und Verantwortungshierarchie strukturiert sind. Im Funktionsbaum sind diejenigen Unternehmensfunktionen markiert, die den Geschäftsprozess Sales-Pipeline bearbeiten unterstützen.

Verwendung

Ein Geschäftsprozess kann so lange in Teilprozesse zerlegt werden, bis eine weitere Aufspaltung nicht mehr sinnvoll/möglich ist (kleinster sinnvoller Teilprozess = Elementarprozess). Üblicherweise werden alle Ebenen der Zerlegung eines Geschäftsprozesses in derselben Methodik dokumentiert: Prozess-Symbole. Die bei der Modellierung einer Ebene der Zerlegung verwendeten Prozess-Symbole verweisen dann gewöhnlich auf die Teilprozesse der nächsten Ebene, bis die Ebene der Elementarprozesse erreicht ist. Für die Darstellung von Geschäftsprozessen, Hauptprozessen, Teilprozessen und Elementarprozessen werden häufig Wertschöpfungskettendiagramme verwendet.

Workflow

Ein Arbeitsablauf ist die Darstellung einer Abfolge von Aufgaben, die als Arbeit einer Person, eines einfachen oder komplexen Mechanismus, einer Gruppe von Personen,^[20] einer Organisation von Mitarbeitern oder von Maschinen (einschließlich IT-Systemen) deklariert wird. Ein Arbeitsablauf ist also immer auf der Ebene der Elementarprozesse angesiedelt. Der Arbeitsablauf kann als eine beliebige Abstraktion der realen Arbeit betrachtet werden, die in Arbeitsteilung, Arbeitsteilung oder andere Arten der Ordnung unterteilt ist. Zu Kontrollzwecken kann der Arbeitsablauf eine Ansicht der realen Arbeit unter einem bestimmten Aspekt sein.

Abgrenzung

Oft wird er Begriff Funktionen gleichermaßen für eine Unternehmensfunktion / einen abgegrenzten Aufgabenbereich, der einem Aufgabenträger zugeordnet ist, und die atomaren Tätigkeiten (Aktivitäten) auf Ebene der Elementarprozesse verwendet. Um die doppelte Bedeutung des Begriffs Funktion zu vermeiden, bietet sich in Anlehnung an die Benennung in der BPMN die Verwendung des Begriffes Task für die atomaren Tätigkeiten auf Ebene der Elementarprozesse an. Moderne Tools bieten auch die automatische Konvertierung eines Tasks in einen Prozess an, so dass es jederzeit möglich ist, eine weitere Ebene der Prozesszerlegung zu erstellen, bei der dann ein Task zu einem Elementarprozess hochgestuft werden muss.

Verwendung

Die auf Ebene der Elementarprozesse verwendeten grafischen Elemente beschreiben dann den (zeitlich-logischen) Ablauf mit Hilfe von Funktionen (Tasks). Die Reihenfolge der Funktionen (Tasks) innerhalb der Elementarprozesse wird durch deren logische Verknüpfung miteinander (durch Operatoren oder Gateways) festgelegt, sofern sie nicht schon durch Input-/Output-Beziehungen oder Meilensteine vorgegeben ist. Es ist üblich, zur besseren Verdeutlichung des Ablaufes weitere grafische Elemente zu verwenden, um Schnittstellen, Zustände (Ereignisse), Bedingungen (Regeln), Meilensteine usw. darzustellen. Je nach verwendetem Modellierungswerkzeug kommen hierfür sehr unterschiedliche grafische Darstellungsarten (Modelle) zur Anwendung.

Weiterhin können die Funktionen (Tasks) um grafische Elemente zur Beschreibung von Inputs, Outputs, Systemen, Rollen usw. ergänzt werden mit dem Ziel, die Genauigkeit der Beschreibung zu verbessern und/oder die Anzahl der Details zu erhöhen. Diese Ergänzungen machen das Modell aber schnell unüberschaubar. Um den Widerspruch zwischen Genauigkeit der Beschreibung und Übersichtlichkeit aufzulösen, bieten sich vor allem zwei Lösungen an: Auslagerung der zusätzlichen grafischen Elemente zur Beschreibung von Inputs, Outputs, Systemen, Rollen usw. in ein Funktionszuordnungsdiagramm oder selektives einblenden/ausblenden dieser Elemente je nach Fragestellung/Anwendungsfall. Das im Bild dargestellte Funktionszuordnungsdiagramm veranschaulicht die Ergänzung der Funktionen (Tasks) um grafische Elemente zur Beschreibung von Inputs, Outputs, Systemen, Rollen usw. sehr gut.

Der Begriff Stammdaten ist weder durch eine der fünf relevanten deutschsprachigen Schulen der Wirtschaftsinformatik: 1) August W. Scheer, 2) Hubert Österle, 3) Otto K. Ferstl und Elmar J. Sinz, 4) Hermann Gehring und 5) Andreas Gadatsch noch durch The Open Group (TOGAF = The Open Group Architecture Framework) oder J. A. Zachman (Zachman Framework) eingeführt und wird umgangssprachlich in Ermangelung eines passenden Begriffs in der Literatur verwendet. Er lehnt sich an die allgemeine Bezeichnung für Daten an, die Grundinformationen über betrieblich relevante Objekte repräsentieren und meint die Grundinformationen, die keine originären Informationen des Geschäftsprozesses sind.

Bei August W. Scheer im ARIS wären das die Grundinformationen der Organisationssicht, Datensicht, Funktionssicht und Leistungssicht.^{[21] (Kapitel 1 Die Vision: Eine gemeinsame Sprache für IT und Management)} (siehe auch Unternehmensabbildung)

Bei Andreas Gadatsch im GPM (Ganzheitliche Prozessmodellierung) wären das die Grundinformationen der Organisationsstruktursicht, Aktivitätsstruktursicht, Datenstruktursicht und Applikationsstruktursicht.^{[1] (Kapitel 3.2 GPM - Ganzheitliche Prozessmodellierung)} (siehe auch Unternehmensabbildung)

Bei Otto K. Ferstl und Elmar J. Sinz im SOM (Semantisches Objektmodell) wären das die Grundinformationen der Ebenen Unternehmensplan und Ressourcen (siehe auch Unternehmensabbildung).

Stammdaten können z. B. sein (siehe auch Abschnitt Definition der fachlichen Anforderungen an die Geschäftsprozessmodellierung):

• die Organisationseinheit, in deren Verantwortungsbereich ein Prozess abläuft
• das Geschäftsobjekt, dessen Informationen zur Ausführung des Prozesses benötigt wird
• das Produkt, das durch den Prozess hergestellt wird
• die Richtlinie, die bei der Ausführung des Prozesses zu beachten ist
• das Risiko, das an einem Prozess auftritt
• die Maßnahme, die durchgeführt wird um die Prozessfähigkeit zu erhöhen
• die Kontrolle, die durchgeführt wird um die Governance des Prozesses sicherzustellen
• das Anwendungssystem, das die Ausführung des Geschäftsprozesses unterstützt
• der Meilenstein, der Prozesse in Prozessphasen gliedert
• usw.

Durch eine Ergänzung der Geschäftsprozessmodellierung um Stammdaten kann die gemeinsame Nutzung desselben Geschäftsprozessmodells für unterschiedliche Einsatzzwecke und mit der entstehenden Synergie schneller ein Return on Investment für die Geschäftsprozessmodellierung erreicht werden.

Abhängig davon, auf wie viele Stammdaten bei der Geschäftsprozessmodellierung Wert gelegt wird, ist es noch möglich, die Stammdaten in das Prozessmodell einzubetten ohne die Lesbarkeit des Modells zu negativ zu beeinflussen oder die Stammdaten sollten in eine eigene Sicht, z. B. Funktionszuordnungsdiagramme, ausgelagert werden.

Wird die Ergänzung der Geschäftsprozessmodellierung durch Stammdaten systematisch betrieben, führt das zum Artefakt-zentrierten Geschäftsprozess Modell.

Artefakt-zentrierter Geschäftsprozess

Das artefaktzentrierte Geschäftsprozessmodell hat sich als ganzheitlicher Ansatz zur Modellierung von Geschäftsprozessen herauskristallisiert, da es eine hochflexible Lösung zur Erfassung der operativen Spezifikationen von Geschäftsprozessen bietet. Es konzentriert sich insbesondere auf die Beschreibung der Daten von Geschäftsprozessen, den so genannten "Artefakten", indem es geschäftsrelevante Datenobjekte, deren Lebenszyklen und zugehörige Dienste charakterisiert. Der artefaktzentrierte Prozessmodellierungsansatz fördert die Automatisierung der Geschäftsabläufe und unterstützt die Flexibilität der Workflow-Erstellung und -Entwicklung.^[22]

Die Einbindung externer Dokumente und Systeme kann den Mehrwert eines Geschäftsprozessmodells wesentlich erhöhen.

Z. B. kann der direkte Zugriff auf Objekte einer Wissensdatenbank oder Dokumente eines Regelwerks den Nutzen des Geschäftsprozessmodells im Alltag und damit die Akzeptanz von Geschäftsprozessmodellierung erheblich steigern. Dabei können alle beteiligten Systeme ihre spezifischen Vorteile ausspielen und einander befruchten (z. B. sich wechselseitig verlinken oder die Ablagestruktur vereinheitlichen):

• kurze Reaktionszeiten der Wissensdatenbank; gekennzeichnet durch eine relativ hohe Anzahl Auditoren, sehr schnelle Anpassung der Inhalte und geringe Anforderungen an die Veröffentlichung der Inhalte - z. B. mit einem Wiki realisiert
• rechtssichere Dokumente des Regelwerks; gekennzeichnet durch eine sehr geringe Anzahl speziell geschulter Auditoren, validierte Anpassung von Inhalten und hohe Anforderungen an die Freigabe der Inhalte - z. B. mit einem Dokumentenmanagementsystem realisiert
• integrierende grafische Darstellung von Prozessen durch ein BPM-System; gekennzeichnet durch eine mittlere Anzahl Auditoren, moderat schnelle Anpassung der Inhalte und mäßige Anforderungen an die Freigabe der Inhalte

Sind alle relevanten Objekte der Wissensdatenbank und / oder Dokumente des Regelwerks an die Prozesse angebunden, haben die Endanwender einen kontextbezogenen Zugang zu diesen Informationen und brauchen sich in der jeweiligen Ablagestruktur der angebundenen Systeme nicht auszukennen.

Die direkte Anbindung externer Systeme kann auch genutzt werden, um aktuelle Messergebnisse oder Systemzustände in die Prozesse zu integrieren (und beispielsweise den aktuellen Betriebszustand der Prozesse anzuzeigen), Widgets einzublenden und darin Ausgaben externer Systeme anzuzeigen oder in externe Systeme abzuspringen und dort mit einem vorkonfigurierten Dialog eine Transaktion zu initiieren.

Weitere Anbindungen externer Systeme können z. B. für den Elektronischen Datenaustausch (EDI) genutzt werden.

Es wird überprüft, ob Redundanzen vorhanden sind. Falls ja, werden die betreffenden Teilprozesse zusammengefasst. Oder es werden mehrfach verwendete Teilprozesse in Unterstützungsprozesse ausgelagert. Ggfs. ist es für eine gelungene Modellkonsolidierung erforderlich, die ursprüngliche Zerlegung der Teilprozesse zu überarbeiten.

Ansgar Schwegmann und Michael Laske führen dazu aus: «Eine Konsolidierung der Modelle verschiedener Modellierungskomplexe ist erforderlich, um ein integriertes […]modell zu erhalten.»^{[19] (Kapitel 5.2.4. Modellkonsolidierung)} Sie zählen auch eine Reihe von Aspekten auf, für die die Modellkonsolidierung von Bedeutung ist:

• «Die Modellierungsteams müssen bereits während der Modellerstellung eine Harmonisierung der Modelle vorantreiben, um die spätere Konsolidierung zu erleichtern.»
• «Wenn eine objektorientierte Zerlegung der Problemdomäne vorgenommen wird, ist frühzeitig zu analysieren, ob gleichartige Strukturen und Prozesse unterschiedlicher Objekte existieren.»
• «Wird eine funktionsorientierte Zerlegung der Problemdomäne vorgenommen, sind vor allem die Schnittstellen zwischen den modellierten Bereichen zu harmonisieren.»
• «Generell ist bei der Modellierung ein einheitlicher Detaillierungsgrad der Modelle» (in jeder Zerlegungsebene) «anzustreben, um die Vergleichbarkeit der Teilmodelle und die präzise Definition von Schnittstellen zu erleichtern.»
• «Nach Abschluss der Modellierungsaktivitäten in den Teams der einzelnen Modellierungskomplexe, sind [die] erstellten Teilmodelle zu einem Gesamtmodell zu integrieren.»
• «Um die Nachvollziehbarkeit der abgebildeten Abläufe zu erleichtern, ist es sinnvoll, ausgewählte Geschäftsvorfälle, die für das Unternehmen eine besonders hohe Bedeutung haben, explizit zu modellieren und auf der Top-Level-Ebene abzubilden. […] Eine farbliche Kennzeichnung kann beispielsweise zusätzlich der Unterscheidung zugehöriger organisatorischer Einheiten dienen.»^{[19] (Kapitel 5.2.4. Modellkonsolidierung)}

Die Verkettung der Teilprozesse untereinander und die Verkettung der Funktionen (Tasks) in den Teilprozessen wird mittels Kontrollfluss-Muster modelliert.

Materielle Details der Verkettung (Was liefert der Vorgänger an den Nachfolger?) werden, sofern vorgesehen, in den Prozess-Schnittstellen spezifiziert.

Prozess-Schnittstellen werden definiert, um

• die Zusammenhänge der Teilprozesse nach der Zerlegung der Geschäftsprozesse aufzuzeigen oder
• festzulegen, was die Geschäftsprozesse bzw. deren Teilprozesse untereinander 'weitergeben' müssen.

In der Regel wird dieses was und seine Struktur von den Erfordernissen im nachfolgenden Prozess bestimmt.

Prozess-Schnittstellen stehen für den Absprung aus dem aktuellen Geschäftsprozess/Teilprozess und den Einsprung in den nachfolgenden Geschäftsprozess/Teilprozess.

Prozess-Schnittstellen sind also Beschreibungselemente für die abschnittsweise Verkettung von Prozessen. Eine Prozess-Schnittstelle kann

• ein Geschäftsprozessmodell/Teilprozessmodell repräsentieren, ohne dass das durch sie referenzierte Geschäftsprozessmodell bereits bestimmt ist,
• ein Geschäftsprozessmodell/Teilprozessmodell repräsentieren, das aus zwei/mehreren übergeordneten oder benachbarten Geschäftsprozessmodellen referenziert wird und
• zwei/mehrere Varianten desselben Geschäftsprozessmodelles/Teilprozessmodells repräsentieren.

Prozess-Schnittstellen werden zwischen den Beteiligten von übergeordneten/untergeordneten oder benachbarten Geschäftsprozessmodellen vereinbart. Sie werden einmalig definiert und verlinkt und beliebig häufig in Prozessmodellen verwendet.

Schnittstellen können definiert werden durch:

• Übergabe der Verantwortung von einer Organisationseinheit an eine Andere,
• Übergabe von Daten aus einem Anwendungssystem an ein Anderes,
• Originärern Input (Informationen / Materialien am Beginn des Geschäftsprozesses),
• Übergabe von Zwischenergebnissen zwischen Teilprozessen (Output beim Vorgänger und Input beim Nachfolger sind i. d. R. identisch) oder
• Finalen Output (das eigentliche Ergebnis / Ziel des Geschäftsprozesses).

Real sind die übergebenen Inputs/Outputs häufig Daten oder Informationen, doch sind auch beliebige andere Geschäftsobjekte denkbar (Materialien, Produkte im End- oder Halbfertigzustand, Dokumente wie ein Lieferschein). Sie werden über jeweils geeignete Transportmedien (bei Daten z. B. durch Datenspeicherung) bereitgestellt.

Siehe Artikel Prozessmanagement.

Um verbesserte Geschäftsprozesse in die Praxis umzusetzen, sind in der Regel Change Management-Programme erforderlich. Mit den Fortschritten im Softwaredesign rückt die Vision, dass GPM-Modelle vollständig ausführbar sind (und Simulationen und Round-Trip-Engineering ermöglichen), immer näher an die Realität.

Im Prozessmanagement werden Prozessabläufe regelmäßig überprüft und gegebenenfalls optimiert (angepasst). Egal ob diese Anpassung der Prozessabläufe durch kontinuierliche Prozessverbesserung oder durch Prozessreorganisation (Business Process Reengineering) ausgelöst wird, zieht sie eine Aktualisierung einzelner Teilprozesse oder eines gesamten Geschäftsprozesses nach sich.

In der Praxis sind Kombinationen informaler, semiformaler und formaler Modelle verbreitet: informale textuelle Beschreibungen zur Erläuterung, semiformale graphische Darstellung zur Visualisierung und formalsprachliche Darstellung zur Unterstützung von Simulation und Übertragung in ausführbaren Code.

Es gibt verschiedene Standards für Notationen, verbreitet sind:

• Business Process Model and Notation (BPMN), vorgeschlagen 2002 von Stephen A. White, veröffentlicht von der Business Process Management Initiative - fusionierte im Juni 2005 mit der Object Management Group
• Ereignisgesteuerte Prozesskette (EPK), vorgeschlagen 1992 von einer Arbeitsgruppe unter Leitung von August-Wilhelm Scheer
• Wertschöpfungskettendiagramm (WKD), zur Darstellung von Prozessen hauptsächlich auf hohem Abstraktionsniveau
• Petri-Netz, entwickelt von Carl Adam Petri im Jahre 1962
• Folgeplan (z. B. in der konkreten Ausprägung als Programmablaufplan), vorgeschlagen 1997 von Fischermanns und Liebelt
• HIPO-Diagramm, um 1970 als Design-Hilfe und Dokumentationstechnik für Software von IBM entwickelt (in einer nicht-technischen, sondern betriebswirtschaftlich orientierten Form)
• Semantisches Objektmodell (SOM), vorgeschlagen 1990 von Otto K. Ferstl und Elmar J. Sinz und seither als laufendes Forschungsprojekt gemeinsam von deren Lehrstühlen durchgeführt; dem sogenannten „SOM“ entspringen wesentliche Grundlagen für das Methodenkonzept der „Bamberger Wirtschaftsinformatik“
• Unified Modeling Language (UML), vorgeschlagen 1996 von Grady Booch, Ivar Jacobson, und James Rumbaugh, laufend überarbeitet unter Ägide der OMG (bietet Erweiterungen für Geschäftsprozesse)
• SIPOC-Diagramm, in den 1980er Jahren im Rahmen der Total-Quality-Management-Bewegung erfunden und dann von Lean-Management- und Six-Sigma-Praktikern übernommen
• ICAM DEFinition (IDEF0), Anfang der 1980er Jahre für die US-Luftwaffe entwickelt
• WS-Business Process Execution Language (BPEL), eine 2002 von OASIS entwickelte, XML-basierte Sprache zur Beschreibung und Automatisierung von Geschäftsprozessen
• Turtle-Diagramm (auch Turtle Methode, Turtle Modell, 8W Methode), eine einfache, übersichtliche und leicht verständliche grafische Darstellung von Fakten zum Prozess
• PICTURE-Methode für die Dokumentation und Modellierung von Geschäftsprozessen in der öffentlichen Verwaltung

Des Weiteren:

• Kommunikationsstrukturanalyse, vorgeschlagen 1989 am Bereich Systemanalyse der TU Berlin von Hermann Krallmann
• Extended Business Modelling Language (xBML)^[23] (scheint veraltet zu sein, da das Gründerunternehmen nicht mehr online ist^[24])
• Notation aus OMEGA (Objektorientierte Methode zur Geschäftsprozessmodellierung und -analyse), vorgestellt von Uta Fahrwinkel 1995^[25]
• Lifecycle Modeling Language (LML), ursprünglich vom LML-Lenkungsausschuss entworfen und 2013 veröffentlicht
• Subjektorientiertes Geschäftsprozessmanagement (S-BPM)
• Kognitionsgestützte Methode zur Analyse natürlichsprachlicher Informationen (CogNIAM)
• Formalized Administrative Notation (FAN), entwickelt von Pablo Iacub und Leonardo Mayo in den 1990er Jahren
• Harbarian process modeling (HPM)
• Datenflussdiagramm, eine Methode zur Darstellung eines Datenflusses durch einen Prozess oder ein System
• Swimlane-Technik, hauptsächlich bekannt durch die BPMN, aber auch SIPOC, das Vorgangskettendiagramm und andere Methoden nutzen diese Technik
• ProMet, ein Methodenset für das Business Engineering
• Zustandsübergangsdiagramm, um das Verhalten von Systemen zu beschreiben

Darüber hinaus können aber auch Darstellungsarten aus der Softwarearchitektur verwendet werden:

• Programmablaufplan, genormt in der DIN 66001 vom September 1966 und zuletzt überarbeitet im Dezember 1983 bzw. genormt in der ISO 5807 aus 1985
• Nassi-Shneiderman-Diagramm oder Struktogramm, vorgeschlagen 1972/73 von Isaac Nassi und Ben Shneiderman, genormt in der DIN 66261.

Computerbasierte Werkzeuge, also Business-Process-Management-Systeme (BPM-Systeme), bieten heute eine weitgehende Unterstützung, vor allem bei der semiformalen Geschäftsprozessmodellierung. Es gibt Werkzeuge zur Visualisierung, Modellierung, Simulation und CASE-Tools. Auch integrierte Lösungen, die die genannten Funktionen um die Aspekte Workflow und EAI erweitern, firmieren häufig unter der Bezeichnung BPM-Systeme. Eine Aufzählung der computerbasierten Werkzeuge wäre so vielfältig und umfangreich, dass sie niemals vollständig sein kann. Stattdessen wird im Folgenden mit einer Kategorisierung und der Nennung typischer Vertreter versucht, einen Überblick zu geben.

Bei der Erstellung von Sollmodellen finden besonders im Umfeld des Customizing Referenzprozessmodelle Verwendung, die prototypische, generische Prozessstrukturen vorgeben und durch Modifikation an die konkrete Situation angepasst werden.

Geschäftsprozesse sind grundsätzlich unabhängig von der Umsetzung zu beschreiben, werden aber häufig mit dem Ziel formuliert, Software-gestützte Abläufe zu gestalten.

Als Unterscheidungskriterium dient die Datenhaltung in einer Datei, einer Datenbank oder einer Mischform.

Dateibasierte BPM-Systeme speichern die Geschäftsprozesse (typischerweise modellweise, selten mehrere Modelle gleichzeitig) in Dateien. Das wesentliche Kennzeichen dateibasierter BPM-Systeme ist, dass die Informationen des gesamten Geschäftsprozessmodells über mehrere Dateien verteilt und nicht miteinander verknüpft sind.

Auch wenn dateibasierte BPM-Systeme für eigenständige Geschäftsprozessmodelle mehrere Geschäftsprozessmodelle in einer Datei speichern können, ist jedes einzelne Geschäftsprozessmodell eigenständig/unabhängig. So hat z. B. die Umbenennung eines Stammdaten-Objektes in einem Geschäftsprozessmodell keine Auswirkung auf andere Geschäftsprozessmodelle, in denen dieses Stammdaten-Objekt ebenfalls vorkommt. Typische Vertreter sind:

• Präsentationsprogramme in Office Suits wie Microsoft PowerPoint, LibreOffice Impress oder SoftMaker Presentations
• Universelle Diagramm-Software wie Microsoft Visio, Diagrams.net (früher draw.io) oder Dia^[26] (vom GNOME-Projekt)

Diese dateibasierten BPM-Systeme speichern ebenfalls ein oder mehrere Geschäftsprozessmodelle in einer Datei, aber die einzelnen Geschäftsprozessmodelle und Stammdaten-Objekte sind miteinander verknüpft. So kann man aus Prozessen per Klick in Teilprozesse navigieren, die als eigenes Modell abgebildet sind. Oder die Umbenennung eines Stammdaten-Objektes hat Auswirkung auf andere Geschäftsprozessmodelle, in denen dieses Stammdaten-Objekt ebenfalls vorkommt. Um das zu realisieren, führen sie eine Trennung von Definition und Ausprägung ein, die es bei BPM-Systeme für eigenständige Geschäftsprozessmodelle nicht gibt. Die Eigenschaften eines Modell-Elements werden zentral an genau einer Stelle in der Datei gespeichert (Definition) während beliebig viele Referenzen darauf (Ausprägungen) in beliebig vielen Geschäftsprozessmodellen der Datei erstellt werden können. Typische Vertreter sind:

• BPMN-basierte Werkzeuge (da die BPMN eine Trennung von Definition und Ausprägung für Data Object in ihrer Spezifikation verankert hat) wie bpmn.io^[27], Visual Paradigm oder Camunda (oder auch Signavio vor dem Kauf durch die SAP)

Sie nutzen die bei dateibasierten BPM-Systemen für verknüpfte Geschäftsprozessmodelle eingeführte Trennung von Definition und Ausprägung und speichern die Geschäftsprozessmodelle und Stammdaten-Objekte ebenfalls an genau einer Stelle - aber in einer Datenbank. Ein großer Vorteil dieser Systeme ist, dass damit die Datenbarrieren zwischen Dateien aufgehoben sind und vollständig separate Modell-Elemente gespeichert werden, die beliebig häufig wieder benutzt werden können. Das heißt, es können in jedem Modell beliebig viele Referenzen auf ein Modell-Element, ist dieses einmal definiert, erstellt werden. Ein weiterer große Vorteil dieser Systeme ist, dass die Definition von jeder Ausprägung gleichermaßen erreichbar ist und eine Abfrage aller Ausprägung, die eine Definition besitzt, eine neue Dimension der inneren Zusammenhänge des Gesamt-Modells offenbart.

Prinzipbedingt ist die Bereitstellung datenbankbasierter BPM-Systeme aufwändiger als die Bereitstellung dateibasierten BPM-Systemen, ihre Bedienung komplexer und ihr Betrieb kostenintensiver. Dafür ist die Datenhaltung über alle Modelle konsistent und eine freie Suche möglich (Suche über alle Datenbank-Inhalte anhand des Namens oder anderer beliebiger Kriterien wie Typ des Modell-Elements, Textfragmente der Beschreibung oder einer beliebigen Eigenschaft). Typische Vertreter sind:

• Professionelle BPM-Systeme wie ARIS, ADONIS oder Symbio Process Designer^[28]

Diese Systeme wollen den großen Vorteil der datenbankbasierten BPM-Systeme, dass die Datenbarrieren zwischen Dateien aufgehoben sind, ebenfalls nutzen - ohne die damit einhergehenden Nachteile vollumfänglich in Kauf zu nehmen. Sie sind deshalb nicht konsequent auf eine Datenhaltung vollständig separater Modell-Elemente in einer Datenbank ausgerichtet. Das kann in der eingesetzten Technik, in der Produktreife oder in dem Bemühen, Aufwand, Komplexität und Kosten zu begrenzen, begründet liegen. Typische Vertreter sind:

• Semiprofessionelle BPM-Systeme wie ViFlow, SAP Signavio und Modelio

Als Unterscheidungskriterium dient die Integration möglichst vieler Prozessmerkmale und Darstellungsformen in die Geschäftsprozessmodelle.

Diese Systeme konzentrieren sich auf die Darstellung von Geschäftsprozessen und bieten nur eingeschränkte Möglichkeiten zur Darstellung einer Prozesslandkarte oder zur Ergänzung der Geschäftsprozesse durch Stammdaten-Objekte. Typische Vertreter sind:

• Universelle Diagramm-Software mit speziellen Schablonen wie Microsoft Visio, Diagrams.net (früher draw.io) oder Dia^[26] (vom GNOME-Projekt)
• BPMN-basierte Werkzeuge (da die BPMN nur eine sehr eingeschränkte Ergänzung der Geschäftsprozesse durch Stammdaten-Objekte in ihrer Spezifikation verankert hat) wie bpmn.io^[27], Visual Paradigm oder Camunda (oder auch Signavio vor dem Kauf durch die SAP)

Universelle Diagramm-Software bietet oft die Möglichkeit, auf Geschäftsprozessmodellierung spezialisierte Schablonen in das System zu importieren oder auch dort zu definieren (wenn keine Importmöglichkeiten bestehen), um die grafische Notation der Geschäftsprozessmodelle standardisiert gestalten zu können.

Diese Systeme bieten neben der Darstellung von Geschäftsprozessen umfangreiche Möglichkeiten zur Darstellung einer Prozesslandkarte oder zur Ergänzung der Geschäftsprozesse durch Stammdaten-Objekte. Oft sind auch mehrere methodische Ansätze zur Abbildung von Geschäftsprozessen wie Ereignisgesteuerte Prozesskette und BPMN verfügbar. In der Regel sind diese Systeme geeignet, eine ganzheitliche Unternehmensabbildung zu realisieren.

• Professionelle BPM-Systeme wie ARIS, Bonapart, Aeneis

Diese Systeme bieten neben der Darstellung von Geschäftsprozessen weitere Möglichkeiten, z. B.:

• Prozesse zu simulieren oder als Workflow ablaufen zu lassen. Die fertigen Prozessdefinitionen können teils direkt von einer integrierten Business Process Engine verarbeitet werden oder lassen sich in einer Form exportieren, die dann von einer Integrationsplattform bzw. der dort integrierten Process Engine ausgeführt werden kann.
• Prozesse mit unmittelbar aktuellen Unternehmens-Kennzahlen (Life-Daten) anzureichern (oder diese einzublenden) oder aus den Geschäftsprozessen direkt in aktuell ausgeführte Unternehmens-Prozesse zu wechseln

Typische Vertreter sind:

• Professionelle Workflow-Management-Systeme

Generell kann man sagen, dass die Kosten beim Übergang von dateibasierten BPM-Systemen (teilweise kostenlos) über die Mischformen zu den datenbankbasierten BPM-Systemen (oft nur noch zeitbegrenzte Testversionen kostenlos) ansteigen. Sbenso steigen die Kosten beim Übergang von prozessfokussierten BPM-Systemen zu integrierten BPM-Systemen und auch mit dem Funktionsumfang.

Eine libeare Gliederung von, bezogen auf den Funktionsumfang, rudimentären BPM-Systemen zu vollständigen BPM-Systemen anzugeben ist sehr schwierig, weil einerseits der Anspruch an ein vollständiges BPM-System ganz wesentlich durch das Einsatz-Szenarion bestimmt wird (in dem eigentlich nie alle Funktionen gleichzeitig benötigt werden) und andererseits selbst teuere BPM-Systeme nie alle höherwertigen Funktionen gleichzeitig anbieten (oder einen Fokus auf bestimmte höherwertigen Funktionen legen). Die folgende Auflistung von Funktionsgruppen soll aber zumindest einen Eindruck vermitteln, welche Funktionen von einem BPM-System in bestimmten Einsatz-Szenarien erwartet werden.

Beim schnellen Modellieren bietet ein BPM-System Benutzerinteraktionen an, die darauf ausgerichtet sind das Geschäftsprozessmodell effizient zu erstellen. Dazu zählen:

Automatische Vorschläge für Modell-Elemente

Die Erfassung neuer Geschäftsprozessmodelle geht in BPM-Systemen besonders schnell von der Hand, wenn sie automatische Vorschläge der methodisch zulässigen Nachfolger (und ggfs. Vorgänger) eines Modell-Elements anbieten.

Das Bild zeigt, wie automatische Vorschläge der methodisch zulässigen Nachfolger in bpmn.io^[27], Symbio Process Designer^[28] und ARIS angeboten werden. In allen drei Fällen wird eine Werkzeugleiste eingeblendet, die die Grundformen der methodisch zulässigen Modell-Elemente anbietet. Soll z. B. statt einem Event ein Message Event eingefügt werden, muss zunächst die Grundform Event ausgewählt und anschließend in einen Message Event umgewandelt werden.

Einfügen zwischen bestehenden Modell-Elementen

Die Änderung/Erweiterung bestehender Geschäftsprozessmodelle geht in BPM-Systemen besonders schnell von der Hand, wenn sie das Einfügen von Zwischenraum für neue Modell-Elemente zwischen bereits bestehenden Modell-Elementen unterstützen. Teilweise wird dies als eigenständige Funktion angeboten, teilweise wird das von einem automatisierten Layout oder vollautomatisch generiertem Layout übernommen, so dass keine eigenständige Funktion angeboten werden muss.

Das erste Bild zeigt, wie das Einfügen von Zwischenraum für neue Modell-Elemente zwischen bereits bestehenden Modell-Elementen in iGrafx, ARIS und Enterprise Architect unterstützt wird. In allen drei Fällen ist die Ansicht nach dem horizontalen Mouse-Drag und vor dem Drop dargestellt. Alle drei BPM-Systeme bieten diese Funktion auch in vertikaler Richtung an.

Das zweite Bild zeigt, wie das direkte Einfügen eines methodisch zulässigen Nachfolgers mit anschließendem Layout in Symbio Process Designer^[28] und Adonis angeboten wird. Das Einfügen erfolgt identisch wie bei den automatischen Vorschlägen für Modell-Elemente. Bevor das eingefügte Modell-Element sichtbar wird, schafft ein automatisiertes Layout oder vollautomatisch generiertes Layout Zwischenraum in ähnlicher Weise, wie das im ersten Bild erläutert wurde - aber eben mit insgesamt deutlich weniger Klicks für den gesamten Vorgang denn zusätzlich wird beim Einfügen des neuen Modell-Elements auch noch die bestehende Kante gegen zwei neue Kanten ersetzt.

Von einem einfacheren automatisierten Layout wird der Zwischenraum im gesamten Modell eingefügt – also auch in parallelen Pfaden, die nicht durch das Einfügen betroffen sind. Von einem komplexeren automatisierten Layout wird der Zwischenraum nur im betroffenen Pfad eingefügt. Die Grenzen solcher automatisierten Layouts zeigen sich bei der gegenteiligen Operation: Dem Löschen eines Modell-Elements. Automatisierte Layouts löschen das jeweilige Modell-Element und ersetzen dessen bestehende Kanten gegen eine neue Kante, lassen aber den entstehenden Zwischenraum bestehen. Vollautomatisch generierte Layouts erkennen auch den entstandenen Zwischenraum und führen diesen wieder zurück (siehe auch Automatisiertes Layout oder vollautomatisch generiertes Layout).

In-Place-Editing

Beim In-Place-Editing können zusätzliche Informationen (in fast allen BPM-Systemen nur der Name des jeweiligen Modell-Elements) in einem Textfeld direkt an der Stelle erfasst werden, an der das Modell-Element im Geschäftsprozessmodell steht – also ohne dass ein Pop-up oder Dialog geöffnet wird.

Das Bild zeigt, wie In-Place Editing in bpmn.io^[27], Diagrams.net und ARIS angeboten wird. Manche BPM-Systeme bieten beim Namen nur unformatierten Text an, andere BPM-Systeme lassen Textformatierungen zu.

Der Vorteil von unformatiertem Text ist, dass er leichter für ein vollautomatisch generiertes Layout optimiert werden kann (das betrifft z. B. automatische Umbrüche beim Wechsel zwischen horizontalem und vertikalem Layout oder Schriftgrößen und Schrifttypen beim Wechsel zwischen gerichteten Graphen, wie BPMN oder EPK, Turtle-Diagrammen und tabellarischer Darstellung). Viele BPM-Systeme gleichen diesen vermeintlichen Nachteil dann damit aus, dass sie die Erfassung weiterer Texte ermöglichen, die dann formatierbar sind.

Automatische Vorschläge für anzubindende Stammdaten-Objekte

Um die Aussagekraft von Geschäftsprozessmodellen zu erhöhen oder Geschäftsprozessmodelle simultan für verschiedene Einsatzzwecke verwenden zu können, werden oft Stammdaten-Objekte an die Modell-Elemente angebunden. Das Anbinden von Stammdaten-Objekte erfolgt mit automatischen Vorschlägen besonders effizient.

Automatisiertes Layout oder vollautomatisch generiertes Layout

Ein automatisiertes Layout oder ein vollautomatisch generiertes Layout wird durch die verschiedenen BPM-Systemen sehr unterschiedlich bereitgestellt. Das kann von der manuell initiierten Ausrichtung (einzelner Modell-Elemente zueinander), über einen manuell gestarteten automatisiertes Layout (typischerweise über das gesamte Modell) bis zum Wechsel zwischen verschiedenen vollautomatisch generierten Layouts reichen (siehe auch Einfügen zwischen bestehenden Modell-Elementen).

Das Bild zeigt, wie der manuelle Start einer Ausrichtung von Modell-Elementen zueinander und eines Layout in ARIS bzw. der Wechsel zwischen verschiedenen vollautomatisch generierten Layouts in Microsoft PowerPoint und in Symbio Process Designer^[28] angeboten werden.

Kennzeichnend für Varianten ist die Darstellung ein und desselben Sachverhalts für verschiedene Rahmenbedingungen. Das kann z. B. derselbe Prozess für verschiedene Standorte eines Unternehmens sein - wie der Prozess „Arbeitsvertrag aushandeln und abschließen“, der in wesentlichen Punkten durch die jeweils lokal geltenden Gesetzte und Gepflogenheiten bestimmt wird.

Für die Bereitstellung von Varianten gibt es zwei grundsätzlich verschiedene Ansätze:

1. Aufbau der verschiedenen Varianten in jeweils einem eigenen Modell und Zusammenfassung der Varianten-Modelle über einen gemeinsamen Einstieg - so dass bei der Navigation zwischen verschiedenen Geschäftsprozessmodellen jeweils eine Variante angezeigt, aber alle Varianten auswählbar sind. Dieser Ansatz zwingt zur mehrfachen Erstellung der Modell-Elemente, die in mehreren Varianten vorkommen. Der dadurch entstehende Aufwand kann durch Kopieren und Einfügen reduziert werden - aber in der Datenhaltung entstehen dadurch Kopien, die eine spätere Konsolidierung oder Datenpflege erschweren.
2. Aufbau eines einzigen Modells, Vergabe von Kriterien für die Modell-Elemente (in welchen Varianten sie relevant sind) und Filterung des Modells über die vergebenen Kriterien. Dieser Ansatz zwingt zur Pflege zusätzlicher Informationen (den Filterkriterien) an den Modell-Elementen, die es auch ermöglichen müssen, einem Modell-Element mehrere Kriterien zuzuordnen. Die Komplexität dieser Zuordnung von Kriterien kann durch Limitierung auf die für ein Modell relevanten Kriterien reduziert werden - und es entstehen in der Datenhaltung keine Kopien, die eine spätere Konsolidierung oder Datenpflege erschweren würden.

Kennzeichnend für Versionen ist die Weiterentwicklung ein und desselben Geschäftsprozessmodells in einer Arbeits-Version für die Projektbeteiligten, während die letzte freigegebene Version für alle Leser zugänglich und gültig bleibt. Oft ist auch der Zugriff auf abgelaufene Versionen desselben Geschäftsprozessmodells möglich.

Bei einer intensiven Nutzung von Varianten und Versionen kann die entstehende Komplexität oft nur noch durch einen vom BPM-System bereitgestellten Modell-Vergleich beherrscht werden.

Kennzeichnend für eine Lebenszyklus-Unterstützung ist einerseits die gleichzeitige Datenhaltung und der simultane Zugriff auf die Arbeits-Version, die letzte freigegebene Version und alle abgelaufenen Versionen sowie die Möglichkeit, im BPM-System einen Statuswechsel ein und desselben Geschäftsprozessmodells durchzuführen, z. B. von in Bearbeitung über in Qualitätsprüfung und in Freigabe zu freigegeben und schließlich zu abgelaufen.

Die Interoperabilität hat vor allem zwei Aspekte:

• Daten Im- und Export
• Anbieten und Nutzen von Automatisierungs-Schnittstellen

Beim Reporting bieten die BPM-System die Möglichkeit, im System Berichte zu definieren oder externe Report-Generatoren anzubinden.

Bei der Analyse bieten die BPM-System die Möglichkeit, (statisch) Kennzahlen zu errechnen oder Varianten zu vergleichen.

Bei der Simulation lassen BPM-System die Geschäftsprozessmodelle virtuell ablaufen und protokollieren die dabei entstehenden (dynamischen) Daten Modellierung und Simulation, z. B. wie Häufigkeit (des Durchlaufens) Ressourcen-Bindung oder Durchlauf-Zeiten.

• Hammer, M., & Champy, J.: Business Reengineering. Die Radikalkur für das Unternehmen. 7. Auflage. Campus Verlag, 2003, ISBN 3-593-35017-3 (Zusammenfassung aus Campus Management). 
• August-Wilhelm Scheer: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse, 7. Aufl., Berlin/Heidelberg 1997, ISBN 3-540-62967-X
• Andreas Gadatsch: Grundkurs Geschäftsprozess-Management. Analyse, Modellierung, Optimierung und Controlling von Prozessen, 9. Aufl., Springer Vieweg, Wiesbaden 2020, ISBN 978-3-658-27811-3
• Anna Nagl, Karlheinz Bozem: Geschäftsmodelle 4.0: Business Model Building mit Checklisten und Fallbeispielen, Springer Gabler, Wiesbaden [2018], ISBN 978-3-658-18841-2.
• Business Process Management Group, Towers, Steve und Peter Fingar: In Search Of Bpm Excellence: Straight From The Thought Leaders, Meghan-Keffer Press, Tampa, Florida, 2005, ISBN 978-0-929-65240-5
• Brett Champlin: Managing business process transformation, Association of Business Process Management Professionals (BPMP), 31 Slides, 2007
• Brett Champlin: Dimensions of Business Process Change, Association of Business Process Management Professionals (BPMP), 36 Slides, 2000

1. ↑ ^{a b c d e f g h i j} Andreas Gadatsch: Management von Geschäftsprozessen / Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker, 2. überarbeitete und erweiterte Auflage, Vieweg, Braunschweig/Wiesbaden 2002, ISBN 978-3-528-15759-3
2. ↑ ^{a b c d e f g h i j k l m n o p} European Association of Business Process Management EABPM (Herausgeber): Business Process Management Common Body of Knowledge - BPM CBOK®, Version 2, Verlag Dr. Götz Schmidt, Gießen 2009, ISBN 978-3-921313-80-0; übersetzte und bearbeitete deutschsprachige Ausgabe von → Association of Business Process Management Professionals ABPMP (Herausgeber): Guide to the Business Process Management common body of knowledge - BPM CBOK®
3. ↑ ^{a b c d e f g h i} Hermann J. Schmelzer und Wolfgang Sesselmann: Geschäftsprozessmanagement in der Praxis, 9. Auflage, Hanser, München 2020, ISBN 978-3-446-44625-0
4. ↑ ^{a b c d e f g h i j k} Michael Rosemann, Ansgar Schwegmann und Patrick Delfmann: Vorbereitung der Prozessmodellierung in Jörg Becker, Martin Kugler und Michael Rosemamm (Hrsg.): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 2. korrigierte und erweiterte Auflage, Springer, Berlin/Heidelberg/New York 2002, ISBN 978-3-540-00107-2
5. ↑ Wissensdatenbank: In 6 einfachen Schritten zur Prozesslandkarte, DER PROZESSMANAGER GmbH (zuletzt abgerufen: 25. Januar 2024)
6. ↑ Jörg Becker und Dieter Kahn: Der Prozess im Fokus in Jörg Becker, Martin Kugler und Michael Rosemamm (Hrsg.): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 2. korrigierte und erweiterte Auflage, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7
7. ↑ ^{a b c d e f g} Jörg Becker und Volker Meise: Strategie und Organisationsrahmen in Jörg Becker, Martin Kugler und Michael Rosemamm (Hrsg.): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 2. korrigierte und erweiterte Auflage, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7
8. ↑ ^{a b} Mario Speck und Norbert Schnetgöke: Sollmodellierung und Prozessoptimierung in Jörg Becker, Martin Kugler und Michael Rosemamm (Hrsg.): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 2. korrigierte und erweiterte Auflage, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7
9. ↑ John Miltenburg, David Sparling: Managing and reducing total cycle time: models and analysis in Elsevier International Journal of Production Economics, Dezember 1996, S. 89–108
10. ↑ Michael Molter: Die Prozessorientierte Applikationslandschaft in August-W. Scheer, Wolfram Jost und Karl Wagner (Hrsg.): Von Prozessmodellen zu lauffähigen Anwendungen, Springer Berlin, Heidelberg, New York 2005, ISBN 3-540-23457-8
11. ↑ N. Venkat Venkatraman: IT-Induced Business Reconfiguration in M. S. Scott Morton (Hrsg.): The Corporation of the 1990s: Information Technology and Organizational Transformation, 1. Auflage, Oxford University Press 1991, ISBN 978-0-19-506358-5
12. ↑ Thomas H. Davenport: Process Innovation: Reengineering Work through Information Technology, Harvard Business Press, Boston 1993, ISBN 978-0-87584-366-7
13. ↑ Michael Hammer, James A. Champy: Reengineering the Corporation: A Manifesto for Business Revolution, Harper Business, New York 1993, ISBN 978-0-88730-640-2
14. ↑ ^{a b c d e f g} ISO 9001:2015: Quality management systems - Requirements, Fifth edition 2015-09, ISO, the International Organization for Standardization 2015
15. ↑ ISO 14001:2015: Environmental management systems - Requirements with guidance for use, Third edition 2015-09, ISO, the International Organization for Standardization 2015
16. ↑ ISO 27001:2022: Information security, cybersecurity and privacy protection Information security management systems - Requirements, Third edition 2022-10, ISO, the International Organization for Standardization 2022
17. ↑ ^{a b c d e} Martin Kugler: Supply Chain Management und Customer Relationship Management - Prozessmodellierung für Extended Enterprises in Jörg Becker, Martin Kugler und Michael Rosemamm (Hrsg.): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 2. korrigierte und erweiterte Auflage, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7
18. ↑ ^{a b} Timo Füermann: Prozessmanagement: Kompaktes Wissen, Konkrete Umsetzung, Praktische Arbeitshilfen, Hanser, München 2014, ISBN 978-3-446-43858-3
19. ↑ ^{a b c d} Ansgar Schwegmann und Michael Laske: Istmodellierung und Istanalyse in Jörg Becker, Martin Kugler und Michael Rosemamm (Hrsg.): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 2. korrigierte und erweiterte Auflage, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7
20. ↑ Siehe z. B. ISO 12052:2006
21. ↑ August-W. Scheer: ARIS: Von der Vision zur praktischen Geschäftsprozesssteuerung in August-W. Scheer und Wolfram Jost (Hrsg.): ARIS in der Praxis: Gestaltung, Implementierung und Optimierung von Geschäftsprozessen, Springer, Berlin, Heidelberg, New York 2002, ISBN 3-540-43029-6
22. ↑ Sira Yongchareon, Chengfei Liu, Jian Yu und Xiaohui Zhao: A View Framework for Modelling and Change Validation of Artifact-Centric Inter-Organizational Business Processes im Journal Information Systems, Jahrgang 2015, Ausgabe 47, Seiten 51–81 (zuletzt abgerufen: 16. Februar 2024)
23. ↑ Cedric G. Tyler und Stephen R. Baker: Business Genetics: Understanding 21st Century Corporations using xBML, John Wiley & Sons Ltd, 2007, ISBN 978-0-470-06654-6
24. ↑ "Business Genetics - The DNA of Business" (Memento vom 9. Januar 2014 im Internet Archive), auf www.xbmlinnovations.com, zuletzt abgerufen: 19. Februar 2024
25. ↑ R. Mayr:OMEGA+ Beschreibungsmethode (Memento vom 22. Oktober 2013 im Internet Archive), auf prof-mayr.de, zuletzt abgerufen: 5. Februar 2024; PDF "VL4030_OMEGA+-Beschreibungsmethode.pdf" nicht mehr verfügbar
26. ↑ ^{a b} Homepage Dia Dia Diagram Editor (zuletzt abgerufen: 15. Februar 2024)
27. ↑ ^{a b c d} Homepage bpmn.io Web-based tooling for BPMN, DMN and Forms. (zuletzt abgerufen: 15. Februar 2024)
28. ↑ ^{a b c d} Homepage Symbio Process Designer Companies in Flow – grow (zuletzt abgerufen: 15. Februar 2024)

• XML-basierte Geschäftsprozessmodellierung (PDF, 82 kB)