Methdoe Gbis

Der Prozesslebenszyklus besteht aus den folgenden sechs Phasen:

1. 1. Process Identification: Identifiziert die Prozessarchitektur (Ordnungsrahmen).

2. Process Discovery: Erstellt aus der Prozessarchitektur ein Ist-Prozessmodell (As-is process model).

3. Process Analysis: Gewinnt aus dem Ist-Modell Einblicke in Schwachstellen und deren Auswirkungen.

4. Process Redesign: Entwickelt auf Basis der Analyseerkenntnisse ein Soll-Prozessmodell (To-be process model).

5. Process Implementation: Setzt das Soll-Modell in ein ausführbares Prozessmodell (Executable process model) um.

6. Process Monitoring and Controlling: Überwacht den implementierten Prozess und liefert Konformitäts- und Leistungserkenntnisse, die wieder in die Phasen der "Process Discovery" und des "Process Redesign" einfließen können.

Die Unternehmensstrategie gibt die Richtung für die Prozessgestaltung vor. Man unterscheidet drei Hauptansätze:

• Market-based view (Marktorientierte Strategie): Wettbewerbsvorteile entstehen durch eine optimale Positionierung am Absatzmarkt (z.B. Kostenführerschaft, Differenzierung). Die Branchenstruktur und das Verhalten der Wettbewerber bestimmen die Unternehmensstrategie.

  
  

• Resource-based view (Ressourcenorientierte Strategie): Die Strategie leitet sich aus den internen Stärken und Schwächen des Unternehmens ab (Fokus auf Kernkompetenzen). Der Wettbewerbsvorteil wird durch einzigartige Ressourcen und Fähigkeiten gesichert.

  
  

• Hybrider Strategieansatz: Dieser Ansatz kombiniert beide Sichten. Marktorientierte Strategien richten die Ziele auf Kundenbedürfnisse aus, während ressourcenorientierte Strategien helfen, die verfügbaren Mittel dafür optimal einzusetzen.

Ein Informationsmodell ist die Repräsentation der Informationen eines betrieblichen Systems für die Gestalter von Anwendungssystemen und Organisationen. Es ist das Ergebnis einer subjektiven Konstruktion durch einen Modellierer, der relevante Systemelemente mithilfe einer Modellierungssprache darstellt.

Informationsmodelle dienen einem doppelten Zweck:

1. 1. Abbildung (Mapping): Sie beschreiben und analysieren ein existierendes Realwelt-System (z.B. Ist-Prozesse).

2. Konstruktion (Construction): Sie dienen als Bauplan für die Entwicklung neuer oder verbesserter Systeme (z.B. Soll-Prozesse oder Software).

Modelle besitzen laut Stachowiak drei grundlegende Merkmale:

1. Abbildungsmerkmal: Ein Modell ist immer ein Abbild eines Originals. Dieses Original kann ein reales Objekt oder auch nur ein gedankliches Konstrukt sein.

   
   

2. Verkürzungsmerkmal: Ein Modell erfasst nie alle Attribute des Originals, sondern nur die für den Zweck relevanten. Dabei können Aspekte weggelassen (Präterition), stärker betont (Kontrastierung) oder sogar hinzugefügt werden (Abundanz).

   
   

3. Pragmatisches Merkmal: Ein Modell wird immer für einen bestimmten Zweck und für bestimmte Nutzer erstellt. Es dient dazu, ein konkretes Ziel zu erreichen und ist nur in diesem Kontext gültig.

Das Geschäftsprozessmanagement wird in drei Abstraktionsebenen unterteilt:

1. Enterprise Level (Unternehmensebene): Dies ist die strategische Ebene. Hier geht es um die Prozessarchitektur, die Ausrichtung der Prozesse an der Unternehmensstrategie, die Festlegung von BPM-Prioritäten und die Planung.

   
   

2. Business Process Level (Geschäftsprozessebene): Auf dieser Ebene finden die eigentlichen Prozessverbesserungsprojekte statt. Dazu gehören Prozessneugestaltung (Redesign), Six Sigma- oder Lean-Projekte sowie die Prozessdokumentation.

   
   

3. Implementation Level (Implementierungsebene): Diese Ebene befasst sich mit der konkreten Umsetzung der Prozesse durch die Entwicklung von Ressourcen. Dazu gehören IT-Projekte (z.B. ERP-Installation, Anwendungsentwicklung) und die Personalentwicklung (z.B. Job Design, Training).

Ein Ordnungsrahmen ist ein Modell mit hohem Abstraktionsgrad, das den Gesamtzusammenhang der Prozesslandschaft eines Unternehmens grafisch darstellt. Er dient als Navigationsrahmen und schafft auch in komplexen Projekten Ordnung.

Zentrale Funktionen:

• Strategische Komponente: Dient als Struktur für die Organisationsgestaltung, basierend auf strategischen Zielen.

• Grafische Komponente: Vermittelt einen schnellen Überblick und dient als "Logo" oder Kommunikationsplattform für die Prozesslandschaft.

  
  

  Ein bekanntes Beispiel für die Strukturierung eines Ordnungsrahmens ist das Handels-H Referenzmodell

Ein Referenzmodell ist ein allgemeingültiges, etabliertes Modell, das als Vorlage oder "Best Practice"-Beispiel für die Gestaltung spezifischer Unternehmensmodelle dient. Es bietet eine bewährte Struktur und Begrifflichkeit, die an die eigenen Bedürfnisse angepasst werden kann. Referenzmodelle helfen dabei, das Rad nicht neu erfinden zu müssen.

Bekannte Referenzmodelle sind:

• Das Handels-H Referenzmodell: Strukturiert die Prozesse und Funktionsbereiche eines Handelsunternehmens.

• Das Y-CIM Modell: Ein Referenzmodell für die Produktionsplanung und -steuerung in Industrieunternehmen.

• ITIL (IT Infrastructure Library): Ein De-facto-Standard für das IT-Service-Management, der Kernprozesse für den Betrieb von IT-Infrastrukturen beschreibt.

• Das SCOR-Modell (Supply Chain Operations Reference): Beschreibt Supply-Chain-Prozesse in den fünf Kategorien Plan, Source, Make, Deliver und Return

Die Auswahl eines Prozesses sollte anhand strategischer und praktischer Leitfragen erfolgen:

1. Ist es ein Geschäftsprozess? Welches betriebswirtschaftliche Objekt wird transformiert (z.B. vom Kundenauftrag zur bezahlten Rechnung)?

2. Ist der Prozess steuerbar? Kann der Prozess beeinflusst und verändert werden? Handelt es sich um wiederholbare Instanzen einer Prozessklasse?

3. Ist der Prozess strategisch bedeutsam?

   • Ist er kundenorientiert und wertschöpfend?

     
     

   • Wird er häufig genug ausgeführt, um einen Einfluss zu haben?

     
     

   • Gibt es rechtliche Vorgaben, die eine genaue Dokumentation erfordern?

     
     

4. Ist der Abstraktionsgrad sinnvoll? Ist der Prozess komplex genug, um Verbesserungspotenzial zu bieten, aber nicht so spezifisch, dass jede Instanz völlig anders ist?

BPMN ist eine formale, grafische Modellierungssprache zur Spezifikation, Abbildung und anschließenden digitalen Implementierung von Geschäftsprozessen. Wie jede Modellierungssprache besteht BPMN aus vier Aspekten:

• Konzepte: Die Menge der verfügbaren Modellelemente, z.B. Ereignisse, Aktivitäten, Gateways.

• Syntax: Die Regeln, wie die Konzepte zu korrekten Modellen verbunden werden dürfen.

• Semantik: Die Bedeutung der einzelnen Elemente und des Gesamtmodells im jeweiligen Kontext.

• Notation: Die grafische Darstellung und formale Festlegung der Symbole.

Der Kontrollfluss in BPMN wird durch drei Haupttypen von Flussobjekten abgebildet:

1. Ereignisse (Events): Repräsentieren etwas, das passiert. Sie lösen oder beenden einen Prozess. Man unterscheidet hauptsächlich Start-, Zwischen- und Endereignisse.

   
   

2. Aktivitäten (Activities): Stellen Arbeit dar, die ausgeführt wird. Dies können einzelne Aufgaben (Tasks) oder zusammengefasste Teilprozesse (Sub-Processes) sein.

   
   

3. Gateways: Steuern die Verzweigung und Zusammenführung des Prozessflusses. Sie basieren auf logischen Bedingungen

• Pool: Repräsentiert einen Prozessteilnehmer, typischerweise eine eigenständige Organisation oder ein Unternehmen (z.B. "Kunde", "Lieferant"). Ein Pool kann als "White Box" (interne Details sichtbar) oder "Black Box" (nur Interaktionen sichtbar) dargestellt werden.

  
  

• 
  

  Lane: Ist eine Unterteilung innerhalb eines Pools. Sie dient der Strukturierung und weist Aktivitäten bestimmten Rollen, Abteilungen oder Systemen zu (z.B. "Verkauf", "Lager", "ERP-System").

  
  

Die Interaktion zwischen zwei verschiedenen Pools wird durch einen

Nachrichtenfluss (Message Flow), eine gestrichelte Linie, dargestellt.

Das exklusive Gateway, dargestellt durch ein

X, wird für "Entweder-Oder"-Entscheidungen verwendet.

• XOR-Split (Verzweigung): Leitet den Kontrollfluss auf genau einen der ausgehenden Pfade weiter. Die Entscheidung basiert auf definierten Bedingungen, die sich gegenseitig ausschließen.

• XOR-Join (Zusammenführung): Führt mehrere eingehende Pfade zusammen. Es leitet den Kontrollfluss sofort weiter, sobald ein eingehender Pfad das Gateway erreicht. Es wartet nicht auf andere Pfade.

Das parallele Gateway, dargestellt durch ein

+, wird für die gleichzeitige Ausführung von Prozesszweigen verwendet.

• AND-Split (Verzweigung): Teilt den Kontrollfluss auf alle ausgehenden Pfade auf. Alle Zweige werden parallel und unabhängig voneinander aktiviert.

  
  

• AND-Join (Zusammenführung): Führt parallele Pfade wieder zusammen. Es wartet, bis

  alle eingehenden Pfade das Gateway erreicht haben (Synchronisation), bevor es den Kontrollfluss auf den ausgehenden Pfad weiterleitet.

Das inklusive Gateway, dargestellt durch einen Kreis in einer Raute, wird für "Ein oder mehrere"-Entscheidungen verwendet (OR-Logik).

• OR-Split (Verzweigung): Aktiviert einen oder mehrere ausgehende Pfade, basierend auf Bedingungen, die nicht exklusiv sein müssen. Mindestens ein Pfad muss verfolgt werden.

  
  

• OR-Join (Zusammenführung): Synchronisiert die durch einen OR-Split aktivierten Pfade. Es wartet auf den Abschluss

  aller zuvor aktivierten eingehenden Pfade, bevor es den Prozess fortsetzt.

Datenobjekte und Datenspeicher visualisieren, welche Informationen in einem Prozess benötigt, erzeugt oder verändert werden.

• Datenobjekt (Data Object): Repräsentiert Dokumente oder Daten, die in einem Prozess gelesen oder geschrieben werden (z.B. eine "Bestellung"). Es existiert nur im Kontext der Prozessinstanz. Ein Status kann vermerkt werden (z.B. [bestätigt]).

• Datenspeicher (Data Store): Repräsentiert eine persistente Datenquelle, auf die lesend und schreibend zugegriffen werden kann (z.B. eine "Lagerplatz DB"). Er existiert unabhängig vom Prozess.

  
  

Sie werden mit Aktivitäten durch eine

Assoziation (gepunktete Linie) verbunden, um den Lese- oder Schreibzugriff darzustellen.

Ein Sub-Prozess ist ein Prozessabschnitt, der selbst aus einer Sequenz von Aktivitäten, Ereignissen und Gateways besteht. Er wird verwendet, um komplexe Prozessmodelle zu vereinfachen und die Übersichtlichkeit zu erhöhen, indem Details gekapselt werden.

Vorteile:

• Komplexitätsreduktion: Das Hauptdiagramm wird übersichtlicher.

• Wiederverwendbarkeit: Ein globaler Sub-Prozess (Call Activity) kann in verschiedenen übergeordneten Prozessen wiederverwendet werden.

• Strukturierung: Logisch zusammengehörige Prozessschritte werden gruppiert.

Wiederholungen werden typischerweise durch einen

Wiederholungsblock (Repetition Block) modelliert. Dieser Block wird durch einen Rücksprung im Sequenzfluss realisiert, der von einem Gateway ausgeht.

Am Ende des zu wiederholenden Abschnitts steht ein exklusives Gateway (XOR-Split). Basierend auf einer Bedingung wird entschieden, ob der Abschnitt erneut durchlaufen wird (z.B. "Antwort nicht genehmigt") oder ob der Prozess regulär fortgesetzt wird (z.B. "Antwort genehmigt").

BPMN bietet spezielle Markierungen für Aktivitäten, um Schleifen und Parallelität kompakter darzustellen:

1. Schleifenaktivität (Loop Activity): Eine Aktivität oder ein Sub-Prozess kann mit einem Schleifensymbol (Ω) markiert werden. Dies stellt eine Kurzschreibweise für einen strukturierten Zyklus dar.

   • Vorteile: Kompakt, flexibel (Anzahl der Durchläufe variabel) und modular (Sub-Prozess kann unabhängig angepasst werden).

1. Parallele Mehrfachinstanz-Aktivität (Multi-Instance Activity): Eine Aktivität kann mit drei vertikalen Strichen (|||) markiert werden, um anzuzeigen, dass mehrere Instanzen dieser Aktivität parallel ausgeführt werden.

   • Vorteile: Kompakt, anpassbar (Anzahl der Instanzen ist variabel) und modular, insbesondere bei Anwendung auf Sub-Prozesse.

Ausnahmen sind Ereignisse, die einen Prozess von seinem normalen Verlauf abweichen lassen. Sie werden in BPMN durch

Boundary Events modelliert. Das sind Zwischenereignisse, die an den Rand einer Aktivität oder eines Sub-Prozesses "geheftet" werden.

Man unterscheidet zwei Arten:

• Unterbrechendes (Interrupting) Boundary Event: Wird mit einem durchgezogenen Rahmen dargestellt. Wenn dieses Ereignis eintritt, wird die Aktivität, an die es geheftet ist, sofort abgebrochen, und der Prozess folgt dem Ausnahmepfad.

  
  

• Nicht-unterbrechendes (Non-Interrupting) Boundary Event: Wird mit einem gestrichelten Rahmendargestellt. Wenn dieses Ereignis eintritt, wird die ursprüngliche Aktivität

  nicht abgebrochen; stattdessen wird ein paralleler Prozesspfad gestartet.

Ein Ad-Hoc Sub-Prozess ist ein spezieller Teilprozess, dessen Aktivitäten in einer beliebigen Reihenfolge und beliebig oft ausgeführt werden können, bis eine definierte Endbedingung erfüllt ist. Er wird für unstrukturierte, unkontrollierte Sequenzflüsse verwendet, bei denen die exakte Abfolge der Aufgaben nicht im Voraus festgelegt ist oder von Fall zu Fall variiert.

Er wird durch eine

Tilde (~) am unteren Rand des Sub-Prozess-Rechtecks gekennzeichnet.

Eine Kompensation dient dazu, bereits erfolgreich abgeschlossene Aktivitäten gezielt rückgängig zu machen, um die Auswirkungen einer Ausnahme zu behandeln. Wenn zum Beispiel eine Bestellung nach dem Versand storniert wird, startet ein Kompensationsereignis Aktivitäten wie "Bearbeite Rücksendung" oder "Erstatte Zahlung zurück an den Kunden".

Sie wird durch ein

Kompensations-Ereignis (Symbol mit zwei nach links zeigenden Dreiecken) ausgelöst.

Die GoM sind ein Set von Richtlinien, um die Qualität von Informationsmodellen sicherzustellen:

1. 
   

   Grundsatz der Richtigkeit: Das Modell muss den abgebildeten Sachverhalt semantisch korrekt wiedergeben.

2. Grundsatz der Relevanz: Das Modell soll nur die für den Zweck wesentlichen Aspekte des Sachverhalts abbilden.

3. Grundsatz der Wirtschaftlichkeit: Der Nutzen der Modellerstellung sollte die Kosten rechtfertigen.

4. Grundsatz der Klarheit: Das Modell muss für den Adressaten verständlich und intuitiv lesbar sein.

5. Grundsatz der Vergleichbarkeit: Innerhalb eines Projekts sollten einheitliche Modellierungskonventionen verwendet werden, um die Modelle vergleichbar zu machen.

6. Grundsatz des systematischen Aufbaus: Es muss eine klare und konsistente Beziehung zwischen den verschiedenen Modellen unterschiedlicher Sichten (z.B. Prozess- und Datensicht) geben.

Ein Modellkonflikt ist eine semantische oder syntaktische Abweichung zwischen Modellen, die dasselbe Realweltphänomen abbilden.

Hauptgründe:

• Unterschiedliches mentales Modell: Die Modellierer nehmen das Problem unterschiedlich wahr oder strukturieren es anders.

• Unterschiedliche Erklärungsweisen: Das gleiche mentale Modell wird mit unterschiedlichen, aber syntaktisch korrekten Konstrukten der Modellierungssprache ausgedrückt.

  
  

Arten semantischer Konflikte:

• Namenskonflikt: Verwendung von Synonymen (gleiche Bedeutung, anderer Name) oder Homonymen (gleicher Name, andere Bedeutung).

• Typenkonflikt: Ein Sachverhalt wird in einem Modell als Aktivität, im anderen als Ereignis dargestellt.

• Abstraktionskonflikt: Ein Sachverhalt wird in den Modellen mit unterschiedlichem Detaillierungsgrad dargestellt.

• Konflikt durch andere Reihenfolge: Die logische Abfolge von Aktivitäten ist in den Modellen unterschiedlich.

1. Generische Prozessmodellierungssprachen:

   • 
     

     Beschreibung: Bieten einen hohen Freiheitsgrad und sind universell anwendbar.

   • Vorteil: Hohe Flexibilität und universelle Einsetzbarkeit.

   • Nachteil: Modelle sind oft schlecht vergleichbar und erfordern hohe Expertise, da es keine strengen semantischen Vorgaben gibt.

   • Beispiel: BPMN, UML-Aktivitätsdiagramme, EPK.

     
     

2. Bausteinbasierte (semantisch-standardisierte) Sprachen:

   • 
     

     Beschreibung: Nutzen semantisch vordefinierte Bausteine (oft aus einem rigide verwalteten Glossar), um die Vergleichbarkeit und Analysierbarkeit von Modellen zu erhöhen. Oft wird die Benennung in "Geschäftsobjekt" und "Tätigkeit" zerlegt.

   • Vorteil: Hohe Konsistenz, Vergleichbarkeit und Wiederverwendbarkeit der Modelle.

   • Nachteil: Geringere Flexibilität und oft auf spezifische Domänen beschränkt.

   • Beispiel: PICTURE, icebricks.

Ein Metamodell ist ein Modell, das eine Modellierungssprache selbst beschreibt. Es definiert die Bausteine (Konzepte), aus denen Modelle dieser Sprache aufgebaut werden dürfen, und die Regeln (Syntax), wie diese Bausteine miteinander verbunden werden können.

Die Hierarchie sieht wie folgt aus:

• Ebene 0: Das Modell (z.B. ein konkretes BPMN-Diagramm) beschreibt die reale Miniwelt.

• Ebene 1: Das Metamodell (z.B. die Definition von BPMN in Form eines ER-Modells) beschreibt die Sprache des Modells auf Ebene 0.

• Ebene 2: Das Metametamodell beschreibt die Sprache, in der Metamodelle erstellt werden.

Metamodellierung ist also das Instrument, um Modellierungssprachen formal zu definieren und zu vereinheitlichen.

Prozessanalysemethoden werden in qualitative und quantitative Ansätze unterteilt.

• Qualitative Prozessanalyse konzentriert sich auf das Verständnis von Problemen und die Identifizierung potenzieller Verbesserungen, ohne sich auf numerische Daten zu stützen. Zu den Methoden gehören:

  • Wertanalyse

  • Ursache-Wirkungs-Diagramme

  • Why-Why-Diagramme

  • Referenzmodelle

  • Heuristiken

    
    

• Quantitative Prozessanalyse verwendet numerische Daten und Metriken zur Bewertung der Prozessleistung. Zu den Methoden gehören:

  • Zyklusanalyse

  • Prozesskostenrechnung

  • Simulation und Animation

  • Process Mining

  • Benchmarking

Das Ziel einer Wertanalyse ist die Identifizierung und Beseitigung von Aktivitäten, die aus Kunden- oder Unternehmenssicht keinen Wert schaffen. Aktivitäten werden in drei Kategorien eingeteilt:

• Wertstiftend (VA): Eine Aktivität, die einen Wert oder Zufriedenheit für einen Kunden erzeugt.

• Unternehmenswertstiftend (BVA): Eine notwendige oder nützliche Aktivität für das Unternehmen, um einen reibungslosen Ablauf zu ermöglichen oder regulatorische Vorgaben einzuhalten.

• Nicht wertstiftend (NVA): Aktivitäten, die weder wertstiftend noch unternehmenswertstiftend sind und eliminiert oder minimiert werden sollten.

Zwei gebräuchliche Methoden zur Ursachenanalyse sind:

• Ursache-Wirkungs-Diagramm (Ishikawa-Diagramm): Diese Methode stellt die Beziehung zwischen einem Problem (der „Wirkung“) und seinen potenziellen Ursachen grafisch dar. Die Ursachen werden typischerweise in Kategorien wie Maschine, Methode, Material, Mensch, Messung und Milieu (die 6 M) eingeteilt, um die Wurzel des Problems systematisch zu identifizieren.

• Why-Why-Diagramm (5 Whys): Bei dieser Technik wird wiederholt die Frage „Warum?“ gestellt (typischerweise fünfmal), um von einem bekannten Problem zu seiner eigentlichen Ursache vorzudringen. Jede Antwort bildet die Grundlage für die nächste „Warum?“-Frage.

Key Performance Indicators (KPIs) sind Kennzahlen, die zur Operationalisierung und Messung von strategischen Zielen dienen. Ihr Ziel ist es, einen schnellen und umfassenden Überblick über komplexe Strukturen und Prozesse zu erhalten.

Die vier grundlegenden Dimensionen der Prozessmessung sind:

• Zeit: Umfasst Kennzahlen wie Durchlaufzeit, Wartezeit und Bearbeitungszeit.

• Kosten: Umfasst fixe, variable und Betriebskosten.

• Qualität: Kann aus interner (z.B. Fehlerraten) oder externer Sicht (z.B. Kundenzufriedenheit) gemessen werden.

• Flexibilität: Bezieht sich auf die Fähigkeit eines Prozesses, mit Variationen in der Arbeitslast, den Aufgaben oder den Ressourcen umzugehen.

Das „magische Viereck des Re-Designs“ ist ein Modell, das die Zielkonflikte zwischen den vier Hauptdimensionen der Bewertung von Prozess-Performance veranschaulicht. Die vier Dimensionen sind:

• Zeit: Das Vorhaben reduziert die Durchlaufzeit des Prozesses.

• Kosten: Das Vorhaben reduziert die Kosten der Prozessausführung.

• Qualität: Das Vorhaben erhöht die Prozessqualität.

• Flexibilität: Das Vorhaben erhöht die Anzahl möglicher Prozess-Varianten.

Das Modell verdeutlicht, dass sich die Dimensionen mitunter entgegenstehen (z.B. kann eine Qualitätssteigerung die Kosten und die Zeit erhöhen). Daher muss die Gewichtung der einzelnen Kriterien in jedem Vorhaben neu bewertet werden.

Die Zyklusanalyse berechnet die durchschnittliche Zeit vom Beginn bis zum Ende eines Prozesses.

• a) Einfache Sequenz: Die gesamte Durchlaufzeit ist die Summe der Durchlaufzeiten aller Aktivitäten in der Sequenz.

• b) Exklusiver (XOR) Split: Die Durchlaufzeit entspricht dem gewichteten Durchschnitt der Durchlaufzeiten der alternativen Pfade. Sie wird berechnet, indem die Durchlaufzeit jedes Pfades mit seiner Eintrittswahrscheinlichkeit multipliziert wird und die Ergebnisse anschließend addiert werden.

• c) Paralleler (AND) Split: Die Durchlaufzeit des parallelen Blocks wird durch den Pfad bestimmt, der am längsten dauert. Die gesamte Prozessdurchlaufzeit ist die Summe der Aktivitäten vor dem Split plus die maximale Zeit der parallelen Pfade.

  
  

Das Ziel der Prozesskostenrechnung ist es, Kosten, insbesondere Gemeinkosten, den Produkten oder Dienstleistungen genauer zuzuordnen, indem sie auf Basis der für ihre Erstellung erforderlichen Prozesse verteilt werden. Sie unterteilt Geschäftsprozesse in Haupt- und Teilprozesse, um die Kosten jeder Aktivität zu ermitteln. Dies ermöglicht eine genauere Berechnung der Kosten pro Prozessausführung, beispielsweise die Kosten für die Abwicklung eines Kundenauftrags.

Re-Design-Heuristiken sind Faustregeln oder Best Practices, die zur schrittweisen Verbesserung bestehender Prozesse verwendet werden. Sie liefern konkrete Vorschläge zur Behebung gängiger Prozessschwächen. Die Hauptkategorien sind:

• Kunden-Heuristiken: Verbessern die Interaktion mit Kunden.

• Business Procezz Heuristiken: Konzentrieren sich auf die Verbesserung einzelner Prozesselemente.

• Business Process Behavior-Heuristiken: Regulieren die (Ablauf-)Logik des Prozesses.

• Organisations-Heuristiken: Konzentrieren sich auf die Organisationsstruktur, Mitarbeiter und Ressourcen.

• Informations-Heuristiken: Konzentrieren sich auf die mögliche Erstellung und Nutzung von Informationen.

• Technologie-Heuristiken: Konzentrieren sich auf die mögliche Nutzung von Technologien im Prozess.

Heuristiken aus der Kategorie „Business Process Operation“ konzentrieren sich auf die Verbesserung der Prozesselemente. Drei Beispiele sind:

1. 
   

   Fall-Behandlung (Case Types): Hierbei wird ein komplexer Prozess in überschaubarere, spezialisierte Prozesse oder Varianten aufgeteilt. Dies verbessert die Effizienz, da verschiedene Falltypen getrennt behandelt werden.

2. Eliminierung von Aktivitäten (Activity Elimination): Diese Heuristik zielt darauf ab, überflüssige (nicht wertschöpfende) Aktivitäten aus dem Prozess zu entfernen, um Zeit und Kosten zu reduzieren.

3. Komposition von Aktivitäten (Activity Composition): Hierbei werden mehrere kleine Aufgaben zu größeren Aktivitäten zusammengefasst, um die Anzahl der Übergaben zu reduzieren und den Arbeitsfluss zu verbessern.

Heuristiken aus der Kategorie „Business Process Behavior“ regulieren die (Ablauf-)Logik des Prozesses. Zwei Beispiele sind:

1. 
   

   (Re-)Sequenzierung / Parallelisierung (Resequencing / Parallelism): Hierbei werden Aktivitäten innerhalb des Prozesses verschoben oder, falls sie voneinander unabhängig sind, parallel bearbeitet, um die Durchlaufzeit zu verkürzen.

   
   

2. 
   

   Abbruchkriterien (Knock-out): Diese Heuristik beinhaltet die effiziente Anordnung von Abbruch-Kriterien, sodass die wahrscheinlichsten und aufwandsärmsten Kriterien zuerst geprüft werden, um unnötige Arbeit zu vermeiden.

1. Workflow: Ein Workflow ist ein zumindest teilweise durch ein Informationssystem automatisierter Geschäftsprozess. Er umfasst vordefinierte Regeln zur automatischen Bereitstellung, Verarbeitung und Zuordnung von Dokumenten, Informationen oder Aufgaben an Bearbeiter.

   
   

2. 
   

   Business Process Management System (BPMS): BPMS sind Softwaresysteme, deren Kernaufgabe die Unterstützung betrieblicher Prozessabläufe durch die Koordination von Aktivitäten, Anwendungen, Daten und prozessbeteiligten Personen ist.

Eine typische BPMS-Architektur besteht aus den folgenden Komponenten:

1. 
   

   Execution Engine: Das zentrale Element, das einzelne Prozessinstanzen ausführt und deren Ablauf koordiniert.

   
   

2. Prozessmodellierungswerkzeug: Dient der Erstellung und Bearbeitung ausführbarer Prozessmodelle, die im Prozessmodell-Archiv gespeichert werden.

3. Worklist Handler: Koordiniert die Zuordnung von Aufgaben an menschliche Akteure und verwaltet deren Arbeitslisten.

4. Verwaltungs- und Monitoring-Werkzeuge: Dienen der Überwachung laufender Prozesse und der Analyse abgeschlossener Instanzen (z.B. zur Identifikation von Engpässen).

5. Externe Dienste: Schnittstellen, über die die Execution Engine Funktionalitäten anderer Systeme aufrufen kann, um Aufgaben automatisiert auszuführen.

Workflow-Systeme lassen sich wie folgt kategorisieren:

• 
  

  Produktions-Workflowsysteme: Nutzen normative, explizit strukturierte Prozessmodelle, die einen strikten Ablauf vorgeben, um repetitive Tätigkeiten effizient auszuführen.

  
  

  Fallmanagement-Systeme: Verarbeiten implizit strukturierte (unterspezifizierte) Prozessmodelle, die bei der Ausführung Flexibilität für die individuelle Fallbehandlung ermöglichen.

  
  

  Ad-hoc-Workflowsysteme: Erlauben die Anpassung von Prozessmodellen während der Laufzeit einer Instanz, um auf unvorhergesehene, einfache Situationen schnell reagieren zu können.

  
  

  Groupware-Systeme: Unterstützen unstrukturierte, kollaborative Arbeit durch Dokumentenverbreitung und Kommunikation, sind aber eher daten- als prozessgetrieben.

Vier zentrale Vorteile und Ziele eines BPMS sind:

1. 
   

   Arbeitsentlastung / Automatisierung: Das BPMS übernimmt die Koordination von Aktivitäten und die Bereitstellung von Informationen, was die manuelle Arbeit reduziert.

2. Transparenz: BPMS ermöglichen die Überwachung und Nachverfolgung aller laufenden und abgeschlossenen Prozessinstanzen, was hilft, Engpässe und Fehler zu identifizieren.

3. Durchsetzung von Regeln: Das System stellt sicher, dass Prozesse genau so ausgeführt werden, wie sie im Soll-Modell definiert wurden, was Abweichungen verringert.

4. Flexible Systemintegration: BPMS können verschiedene, bereits existierende Informationssysteme (z.B. ERP, CRM) integrieren und deren Funktionen im Prozessablauf orchestrieren.

Bei der Einführung eines BPMS gibt es zwei Arten von Herausforderungen:

• 
  

  Technische Herausforderungen: Die Anbindung von proprietären Altsystemen, die nicht prozess- oder serviceorientiert sind, ist oft schwierig und aufwändig. Systeme, die neueren Paradigmen wie der Service-Oriented-Architecture (SOA) folgen, lassen sich leichter integrieren.

  
  

  Organisationale Herausforderungen: Organisationen sind dynamische, sozio-technische Systeme, die sich ständig ändern. Es ist eine große Herausforderung, die Mitarbeiter von den Vorteilen des BPMS zu überzeugen und ihre Akzeptanz für die Nutzung des neuen Systems zu gewinnen.

Die Herausforderung besteht darin, dass die in der Standardsoftware abgebildeten Prozesse selten exakt mit den aktuellen Prozessen im Unternehmen übereinstimmen. Dies erzeugt eine Lücke zwischen der Systemfunktionalität und der Organisation.

Um diese Lücke zu schließen, ist Customizing notwendig. Customizing bezeichnet die Anpassung der Standardsoftware an die unternehmensspezifischen Anforderungen. Dies umfasst sowohl die Konfiguration von Parametern im System (z.B. Definition von Buchungskreisen, Werken) als auch potenziell die Anpassung der Unternehmensprozesse an die Vorgaben der Software.

Die fünf Schritte zur Erstellung eines ausführbaren Prozessmodells sind:

1. 
   

   Identifikation der Automatisierungsgrenzen: Klassifizierung jeder Aktivität als automatisch, manuell oder benutzergesteuert.

2. Begutachtung manueller Aufgaben: Manuelle Aktivitäten werden geprüft, ob sie doch durch das BPMS unterstützt oder automatisiert werden können. Nicht unterstützbare manuelle Schritte sollten isoliert werden.

3. Vervollständigung des Prozessmodells: Das Modell wird mit allen für die Ausführung notwendigen Details angereichert, insbesondere mit Datenobjekten (Input/Output) und der Behandlung aller möglichen Ausnahmen.

4. Überführung auf eine adäquate Granularitätsstufe: Aktivitäten werden bei Bedarf zusammengefasst (Aggregation) oder aufgeteilt, um unnötige Übergaben zu vermeiden oder Verantwortlichkeiten klar zuzuordnen.

5. Spezifikation der Ausführungseigenschaften: Technische Details wie Schnittstellen, Prozessvariablen, Zuweisungsregeln und Quellcode für Skripte werden definiert und im BPMS hinterlegt.

Die Aktivitäten werden in drei Hauptkategorien unterteilt:

• 
  

  Automatisierte Aktivitäten: Werden vom BPMS oder einem externen Dienst ohne menschliches Zutun ausgeführt. Sie werden weiter unterteilt in:

  
  

  • Senden (Send): Sendet eine Nachricht an einen externen Dienst.

  • Empfangen (Receive): Empfängt eine Nachricht von einem externen Dienst.

  • Service: Ruft einen externen Dienst auf, der die Aktivität ausführt.

  • Skript (Script): Führt ein im BPMS hinterlegtes Skript aus.

  
  

  Nutzer-Aktivitäten (User Tasks): Werden von einem Menschen durchgeführt, aber durch das BPMS unterstützt (z.B. über eine Eingabemaske).

• Manuelle Aktivitäten (Manual Tasks): Werden von einem Menschen ohne jegliche Softwareunterstützung des BPMS durchgeführt.

Ein Petri-Netz ist eine formale, grafische Modellierungssprache, die zur Modellierung, Analyse und Simulation von Prozessen dient. Es handelt sich um einen bipartiten Graphen.

Die vier grafischen Elemente sind:

• 
  

  Stelle (Place): Wird als Kreis dargestellt und repräsentiert einen Zustand im Prozess.

  
  

• Transition: Wird als Rechteck dargestellt und repräsentiert eine Aktivität oder Bedingung, die zu einer Zustandsänderung führt.

• Markierung (Token): Wird als schwarzer Punkt innerhalb einer Stelle dargestellt und zeigt den aktuellen Zustand des Prozesses an.

• Kante (Arc): Ein Pfeil, der ausschließlich Stellen mit Transitionen (und umgekehrt) verbindet.

Der Prozessablauf wird durch das "Feuern" (firing) von Transitionen dargestellt, wodurch sich die Verteilung der Marken (Tokens) im Netz ändert.

Die Schaltregel besagt: Eine Transition kann genau dann feuern, wenn

alle ihre Eingangssstellen (die Stellen, von denen ein Pfeil zur Transition führt) mit mindestens einer Marke belegt sind. Wenn eine Transition feuert, wird aus

jeder ihrer Eingangssstellen eine Marke entfernt und in jede ihrer Ausgangsstellen eine neue Marke gelegt

Process Mining ist ein datengetriebenes Verfahren zur Analyse von Geschäftsprozessen. Es nutzt Daten aus Informationssystemen, um zu verstehen, wie Prozesse tatsächlich ausgeführt werden.

Die Grundlage für Process Mining sind Event-Logs. Ein Event-Log ist eine Sammlung von Ereignisdaten (Events), die bei der Ausführung von Prozessen in IT-Systemen entstehen.

Ein Event-Log muss für die Analyse mindestens drei Informationen pro Ereignis enthalten:

1. 
   

   Fallnummer (Case ID): Ordnet das Ereignis einer bestimmten Prozessinstanz zu.

2. Aktivität (Activity): Beschreibt, welche Aufgabe ausgeführt wurde.

3. Zeitpunkt & Datum (Timestamp): Gibt an, wann das Ereignis stattfand.

Die drei Haupttypen des Process Mining sind:

1. 
   

   Discovery (Erkennung): Bei dieser Technik wird ein Prozessmodell ausschließlich auf Basis der Daten aus einem Event-Log erstellt. Es ist keine vorherige Kenntnis des Prozesses erforderlich. Der Alpha-Algorithmus ist ein Beispiel hierfür.

2. Conformance Checking (Übereinstimmungsprüfung): Hierbei wird ein bereits existierendes Soll-Prozessmodell mit der Realität (abgebildet im Event-Log) verglichen. Ziel ist es, Abweichungen zu erkennen und deren Stärke zu messen.

3. Enhancement (Erweiterung): Diese Technik nutzt die Informationen aus dem Event-Log, um ein bestehendes Prozessmodell zu verbessern oder zu erweitern. Dies kann eine Reparatur des Modells (Repair) oder das Hinzufügen neuer Perspektiven wie Zeit- oder Ressourceninformationen (Extension) umfassen.

Beim Process Discovery müssen vier konkurrierende Qualitätsdimensionen ausbalanciert werden:

• 
  

  Eignung (Fitness): Das Modell sollte in der Lage sein, jeden im Event-Log beobachteten Prozesspfad "nachzuspielen".

• Einfachheit (Simplicity): Das Modell sollte so einfach wie möglich sein (z.B. wenige Knoten und Kanten), um verständlich zu bleiben.

• Generalisierbarkeit (Generalization): Das Modell sollte nicht nur die beobachteten Pfade abbilden, sondern auch theoretisch mögliche, aber nicht aufgetretene Pfade zulassen, um nicht zu spezifisch zu sein.

• Genauigkeit (Precision): Das Modell sollte nicht zu viele Verhaltensweisen erlauben, die in der Realität nie vorkommen (Gegenpol zur Generalisierung).

  
  

Das übergeordnete Ziel ist es, eine gute

Balance zwischen Über- und Unterspezifizierung des Modells zu finden.

Der Zweck des Alpha-Algorithmus ist es, aus einem einfachen Event-Log automatisch ein Prozessmodell in Form eines Petri-Netzes zu erstellen (Discovery).

Er identifiziert dabei vier grundlegende Relationen zwischen zwei Aktivitäten x und y:

1. 
   

   Direkte Nachfolge (x>y): y folgt in mindestens einer Prozessinstanz direkt auf x.

2. Kausalität (x→y): y folgt auf x, aber x folgt niemals auf y (x>y und nicht y>x).

3. Parallelität (x∥y): x und y folgen aufeinander in beliebiger Reihenfolge (x>y und y>x).

4. Unabhängigkeit (x#y): x und y folgen niemals aufeinander (weder x>y noch y>x).

Der Algorithmus nutzt die Relationen, um Kontrollflusskonstrukte zu erstellen:

• XOR-Split (Auswahl): Wenn auf eine Aktivität x die Aktivitäten y und z folgen können, diese aber nie parallel auftreten (x→y, x→z und y#z), dann modelliert der Algorithmus einen XOR-Split. Von x geht eine Kante zu einer Stelle, von der aus separate Pfade zu y und z führen.

• AND-Split (Parallelität): Wenn auf eine Aktivität x die Aktivitäten y und z folgen können und diese auch parallel zueinander auftreten (x→y, x→z und y∥z), dann modelliert der Algorithmus einen AND-Split. Von x gehen Kanten zu zwei verschiedenen Stellen, die dann zu y bzw. z führen.

Zwei wesentliche Schwächen des Alpha-Algorithmus sind:

1. Umgang mit Schleifen (Loops): Der Algorithmus hat Probleme mit kurzen Schleifen. Insbesondere "length one"-Loops (eine Aktivität, die sich selbst wiederholt) und "length two"-Loops (zwei Aktivitäten, die sich gegenseitig aufrufen) können nicht korrekt erkannt werden.

2. Unvollständigkeit der Daten: Der Algorithmus kann nur Prozesspfade erzeugen, die er im Event-Log "beobachtet" hat. Wenn das Log unvollständig ist oder nur "Sunny Day"-Szenarien enthält, wird das resultierende Modell ebenfalls unvollständig sein und wichtige Ausnahmepfade nicht enthalten.

Das klassische Process Mining geht typischerweise von folgenden Annahmen aus:

• Prozessstruktur: Die Prozesse sind standardisiert, wiederholen sich häufig und sind digitalisiert. Flexible, seltene oder analoge Prozesse sind eine Herausforderung.

• Datenstruktur: Es liegen saubere Event-Logs mit eindeutiger Case-ID, Aktivitäten und Zeitstempeln vor.

• Analysefokus: Der Fokus liegt auf internen Kennzahlen wie Kontrollfluss, Kosten und Zeit.

• Analyseeinheit: Analysiert wird der gesamte Prozess auf aggregierter Ebene, nicht einzelne Instanzen.

• Ziel: Das primäre Ziel ist oft das Re-Design des Soll-Prozesses.

Die Wissenspyramide beschreibt die hierarchische Beziehung zwischen Daten, Informationen und Wissen:

• 
  

  Daten: Sind reine Zeichen oder Signale ohne Kontext (Syntax-Ebene).

• Informationen: Entstehen, wenn Daten von einer Person eine subjektive Bedeutung zugewiesen bekommen.

• Wissen: Ist die Gesamtheit der Kenntnisse und Fähigkeiten einer Person zur Problemlösung. Es repräsentiert den Kontext und Zusammenhänge (Semantik-Ebene).

  
  

Man unterscheidet zwei Arten von Wissen:

• Explizites Wissen: Ist formulier- und kodifizierbar (z.B. in Handbüchern, Prozess-Dokus), leicht übertragbar und personenunabhängig.

• Implizites (tazites) Wissen: Ist personengebunden, schwer zu artikulieren und zu transferieren. Es umfasst kognitive Elemente (mentale Modelle) und technische Fähigkeiten (Know-how).

Definition: Wissensintensive Prozesse (Knowledge-intensive Processes, KiPs) sind Prozesse, deren Durchführung und Ergebnis stark von Wissensarbeitern abhängen, die miteinander verknüpfte, wissensintensive Entscheidungsaufgaben durchführen.

Vier wesentliche Merkmale:

1. 
   

   Hohe Komplexität und Flexibilität: Die Abfolge der Aufgaben entwickelt sich oft erst während der Prozessausführung.

2. Abhängigkeit von implizitem Wissen: Sie erfordern Mitarbeiter mit erfahrungsbasiertem, implizitem Wissen.

3. Hohe Unsicherheit: Der genaue Input und Output des Prozesses sind oft unsicher.

4. Menschenzentriert: Sie können weder vollständig automatisiert noch standardisiert werden.

Die Merkmale von KIPs und die Anforderungen des Process Mining wirken gegenläufig:

• 
  

  Flexibilität vs. Standardisierung: KIPs sind flexibel und erfordern Entscheidungsautonomie , während Process Mining am besten mit standardisierten Prozessen funktioniert.

• Implizites vs. Explizites Wissen: KIPs stützen sich auf schwer fassbares, implizites Wissen , während Process Mining strukturierte, explizite Daten aus Event-Logs benötigt.

• Menschenzentriert vs. Digitalisiert: KIPs sind oft menschenzentriert , Process Mining erfordert jedoch einen hohen Grad an Digitalisierung und Automatisierung, um Daten zu erzeugen.

• Externe vs. Interne Ziele: KIPs zielen oft auf externe Variablen wie Kundenzufriedenheit , während klassisches Process Mining interne Variablen wie die Durchlaufzeit analysiert

Workarounds können zu drei Arten von Datenproblemen führen, die die Analyse verzerren:

1. 
   

   Phantom Workarounds (Menge 2): Umfassen Event-Daten, die keine Entsprechung in der Realwelt haben. Sie beschreiben erfasste, aber nicht ausgeführte Vorgänge.

   
   

   • 
     

     Beispiel: Testdaten aus der Softwareentwicklung, die im produktiven Event-Log verbleiben.

     
     

2. 
   

   Transparente Workarounds (Menge 7): Hinterlassen ausreichend getreue Datenspuren, die eine datengetriebene Analyse erlauben. Hier stimmen erfasste Daten und reale Ausführung überein, weichen aber vom Soll-Modell ab.

   
   

   • 
     

     Beispiel: Das Vorziehen von Aktivitäten oder das bewusste Auslassen von Pflichtaktivitäten, was im System erfasst wird.

     
     

3. 
   

   Offline Workarounds (Menge 6): Hinterlassen keine direkt auswertbaren Datenspuren im System. Sie beschreiben reale Ausführungen, die nicht erfasst und nicht modelliert wurden.

   
   

   • 
     

     Beispiel: Die Produktion von Teilen ohne Anweisung im ERP-System oder die Nutzung von physischen Hilfsmitteln (z.B. Notizzettel) anstelle des Systems.

Daten aus wissensintensiven Prozessen führen oft zu unübersichtlichen

„Spaghetti-Modellen“, weil diese Prozesse eine hohe Flexibilität und Varianz aufweisen. Jeder Fall kann leicht unterschiedlich ablaufen, was zu einer Explosion von Pfaden im Prozessgraphen führt.

Um die Komplexität zu reduzieren, gibt es drei Ansätze zum Filtern:

1. 
   

   Task-based (Aktivitäten-basiert): Es wird nur ein Subset der Aktivitäten für die Visualisierung verwendet, z.B. basierend auf deren Häufigkeit.

2. Arc-based (Kanten-basiert): Nur die häufigsten Verbindungen (Kanten) zwischen Aktivitäten werden beibehalten, um seltene Pfade auszublenden.

3. Variant-based (Varianten-basiert): Es werden nur ausgewählte Prozessvarianten betrachtet, z.B. nur die häufigste oder die seltenste Variante.

   
   

Das SECI-Modell beschreibt, wie Wissen in einer Organisation in einer Spirale geschaffen und verteilt wird. Es gibt vier Modi des Wissenstransfers:

1. 
   

   Sozialisation (implizit → implizit): Implizites Wissen wird durch direkte Interaktion und gemeinsame Erfahrungen weitergegeben, z.B. bei der Zusammenarbeit oder im Mentoring.

2. Externalisierung (implizit → explizit): Implizites Wissen wird artikuliert und in eine explizite Form gebracht, z.B. durch das Erstellen von Berichten, Modellen oder Checklisten.

3. Kombination (explizit → explizit): Bestehendes explizites Wissen wird neu geordnet und verknüpft, um neues explizites Wissen zu schaffen, z.B. durch die Zusammenführung verschiedener Datenbanken oder Dokumente.

4. Internalisierung (explizit → implizit): Mitarbeiter nehmen explizites Wissen auf und verinnerlichen es durch Anwendung ("Learning by doing"), sodass es zu ihrem eigenen impliziten Wissen wird.

Die fünf Design-Prinzipien wenden die Logik des SECI-Modells auf Process Mining für KIPs an:

• 
  

  DP1: Externalisiere tazites prozessbezogenes Wissen: Prozessteilnehmer sollen die Möglichkeit bekommen, ihr implizites Wissen (z.B. über Notizen, Dokumente) zu externalisieren und an Prozessinstanzen anzuheften.

• DP2: Erweitere das Event-Log mit kategorisierten Informationen: Die zusätzlich erfassten unstrukturierten Informationen müssen verarbeitet und als neue Attribute in das Event-Log integriert werden.

• DP3: Beziehe Informationen aus dem Event-Log mit Hilfe von Process Mining: Das angereicherte Event-Log wird mittels Process Mining analysiert, um relevante Informationen (z.B. ähnliche Fälle) zu extrahieren.

• DP4: Internalisiere Informationen, um neues prozessbezogenes Wissen zu erzeugen: Die aufbereiteten Informationen werden den Prozessteilnehmern zur Verfügung gestellt (z.B. durch den Vergleich mit ähnlichen Instanzen), damit sie diese mit ihrem bestehenden Wissen kombinieren können.

• DP5: Identifiziere und vernetze Wissensträger: Das System soll es ermöglichen, die Verantwortlichen für ähnliche Prozessinstanzen zu identifizieren und zu kontaktieren, um den direkten Austausch von implizitem Wissen (Sozialisation) zu fördern.

Mit steigender Komplexität und neuen Anforderungen (z.B. durch Wachstum, neue Produkte, Regulatorik) entsteht ein Risiko, das nicht mehr allein durch einzelne Experten kompensiert werden kann. Um dieses Risiko zu beherrschen, muss die

Prozessreife systematisch erhöht werden, also die Fähigkeit der Organisation, ihre Prozesse beherrscht, standardisiert und zielorientiert zu gestalten und zu leben.

"Process Basics" sind dabei grundlegende, einfache Regeln und Abläufe (z.B. "Keine Warenentnahme ohne Buchung"), die eine Organisation mindestens beherrschen sollte. Sie zu etablieren ist eine wichtige Voraussetzung, da eine Organisation, die diese Grundlagen nicht beherrscht, nicht für größere Prozessveränderungen bereit ist.

Eine Prozesslandkarte gliedert die Prozesse eines Unternehmens üblicherweise in drei Hauptkategorien, um die strategische Ausrichtung und Wertschöpfung darzustellen:

1. 
   

   Managementprozesse: Steuern die Organisation und planen die Strategie (z.B. "Unternehmensstrategie planen").

2. Kernprozesse: Repräsentieren die direkte, wertschöpfende Leistungserbringung für den externen Kunden (z.B. "Produkt entwickeln", "Artikel produzieren").

3. Unterstützungsprozesse: Stellen die für die Kernprozesse notwendigen Ressourcen und Dienstleistungen bereit (z.B. "Personalwesen", "Betriebsmittel instand halten").

   
   

Die zentralen Rollen im Prozessmanagement sind:

• - Prozesssponsor: Trägt die strategische Gesamtverantwortung.

• Prozessarchitekt: Gestaltet und optimiert prozessübergreifende Schnittstellen.

• Prozessverantwortlicher (-owner): Verantwortet einen End-to-End-Geschäftsprozess.

• Prozessexperte: Gestaltet den Prozess inhaltlich mit.

• Prozessmitarbeiter: Führt die Aktivitäten im Prozess aus.

Ein Prozessverbesserungsprojekt folgt einem strukturierten, phasenweisen Vorgehen:

1. 
   

   Definition & Vorbereitung: Festlegung der Projektziele und Priorisierung der zu betrachtenden Prozesse.

2. Impulse, Aufnahme & Analyse: Analyse des Ist-Zustands, um Schwachstellen und Verbesserungspotenziale abzuleiten.

3. Soll-Konzeption: Erarbeitung der zukünftigen Ablauforganisation und Definition der neuen Prozessziele.

4. Pilotierung und Rollout: Die neuen Prozesse werden zunächst in einem begrenzten Bereich getestet (Pilotierung) und nach erfolgreicher Freigabe schrittweise im Unternehmen ausgerollt (Rollout). In beiden Phasen sind die Qualifizierung der Mitarbeiter und die Prozessimplementierung entscheidend.

5. Controlling: Nach der Einführung werden die Prozessziele und Kennzahlen kontinuierlich überwacht, um die Wirksamkeit sicherzustellen und neue Verbesserungsbedarfe zu identifizieren.

Das grundlegende Prinzip ist die Orchestrierung eines grafisch modellierten Prozesses (z.B. in BPMN) durch eine zentrale Prozessengine. Die Engine steuert den Ablauf, verteilt aber die Ausführung der einzelnen Aufgaben an dezentrale Komponenten.

Ihre Rolle ist die einer Dirigentin:

• Sie sorgt dafür, dass die im Prozessmodell definierte Reihenfolge und Logik eingehalten wird.

• Sie ruft externe, unabhängige Business Functions (Services) auf, die die eigentliche Geschäftslogik implementieren.

• Sie weist Aufgaben, die menschliches Handeln erfordern, den Usern zu (z.B. über eine Tasklist).

Dieses Vorgehen trennt die reine Prozesssteuerung (Orchestrierung) von der fachlichen Implementierung (Geschäftslogik).

Die Architektur von Camunda 8 besteht aus mehreren entkoppelten Komponenten, die auf Skalierbarkeit und Cloud-Fähigkeit ausgelegt sind:

• Zeebe: Die eigentliche Prozessengine. Sie ist als replizierter Cluster konzipiert, um hochverfügbar zu sein und speichert den Prozesszustand in einem eigenen Event Log.

• Clients & Job Workers: Dies sind externe Anwendungen, die die Geschäftslogik ausführen. Sie verbinden sich über eine Schnittstelle (z.B. gRPC) mit der Zeebe Engine, holen sich Aufgaben ab und melden deren Erledigung zurück.

• Operate, Tasklist, Optimize: Webanwendungen für das Monitoring von Prozessinstanzen (Operate), die Bearbeitung von Benutzeraufgaben (Tasklist) und die Analyse der Prozess-Performance (Optimize).

• Elasticsearch: Dient als Datensenke. Die Zeebe Engine exportiert ihre Event-Daten dorthin, sodass sie für Analysen und die Anzeige in Operate und Optimize zur Verfügung stehen.

Zwei nützliche Techniken aus der Praxis sind:

1. Element Templates: Dies sind standardisierte Vorlagen im Camunda Modeler. Sie definieren für BPMN-Elemente (z.B. einen Service Task) vordefinierte Eigenschaften und Eingabefelder. Dadurch wird sichergestellt, dass Entwickler alle notwendigen technischen Attribute (z.B. Connector-Informationen, Prozessvariablen) konsistent und korrekt ausfüllen. Dies reduziert Fehler, erhöht die Standardisierung und vereinfacht die Modellierung.

2. Event Sub-Process: Dies ist ein fortgeschrittenes BPMN-Konstrukt, um auf Ereignisse zu reagieren, die jederzeit und unerwartet während des Hauptprozesses auftreten können (z.B. eine Stornierungsnachricht). Er wird als eigener, eingebetteter Prozess modelliert, der nicht im regulären Sequenzfluss liegt, sondern durch ein definiertes Startereignis (z.B. "Message Start Event") ausgelöst wird, um eine Ausnahmebehandlung zu starten.

Ein

Workaround ist eine zielgerichtete Anpassung oder Improvisation durch Mitarbeitende, um ein Hindernis, eine Ausnahme oder eine Ineffizienz im bestehenden, standardisierten Soll-Prozess zu überwinden. Er entsteht oft aus einem empfundenen "Misfit" zwischen der Arbeitsrealität und dem formalen Prozess.

Workarounds haben eine duale Natur:

• 
  

  Positiv: Sie können eine Quelle für Bottom-Up-Prozessinnovation sein, die Effizienz steigern (z.B. durch Zeitersparnis) und die Flexibilität im Arbeitsalltag gewährleisten.

• Negativ: Sie können zu Kontrollverlust, neuen Ineffizienzen, Datenqualitätsproblemen und unkalkulierbaren Risiken führen.

(Quelle: Gastvorlesung UPB 2025- Latente Workarounds als Prozessinnovation.pdf, Folien 6, 11; Gastvorlesung_BPM_Workarounds_AAssbrock.pdf, Folien 6, 7, 8, 16)

Workarounds sind oft keine isolierten Einzelaktionen, sondern können sich im Unternehmen verbreiten ("Workaround Diffusion") und so die Organisation von unten nach oben ("bottom-up") transformieren. Sie beeinflussen nicht nur IT-Systeme, sondern auch etablierte Prozesse und die Art der Zusammenarbeit zwischen Kollegen.

Der Lebenszyklus eines Workarounds entwickelt sich dabei oft über Monate bis Jahre in drei Phasen:

1. 
   

   Temporärer Workaround: Eine spontane Improvisation, um ein akutes Problem zu lösen.

2. Routinisierter Workaround: Die Improvisation wird zur wiederholten, etablierten Gewohnheit.

3. Neuer Normalzustand: Der ehemals inoffizielle Workaround wird als neue, systematisierte Methode in den offiziellen Prozess überführt und wird zum neuen Standard.

4. 
   

Anstatt Workarounds pauschal zu verbieten, können Unternehmen einen strukturierten Prozess etablieren, um deren Potenzial als Innovation zu nutzen. Der

"Workaround-to-Innovation"-Prozess umfasst vier Phasen:

1. Identify & Share (Identifizieren & Teilen): Workarounds müssen zunächst erkannt und kommuniziert werden. Dies kann durch Beobachtung, Befragung oder spezielle Tools (z.B. ein digitaler "KVP-Briefkasten") geschehen.

   
   

2. 
   

   Categorize & Analyze (Kategorisieren & Analysieren): Der identifizierte Workaround wird analysiert, um seine Ursachen, seinen Kontext und seine Auswirkungen zu verstehen.

   
   

3. Evaluate & Decide (Bewerten & Entscheiden): Der Nutzen und die Risiken des Workarounds werden bewertet. Darauf basierend entscheidet das Management, ob der Workaround übernommen, verhindert, ignoriert oder als Anstoß für ein Redesign genutzt werden soll.

4. Implement & Transform (Implementieren & Transformieren): Ein als positiv bewerteter Workaround wird formalisiert und als Prozessinnovation in den neuen Standardprozess implementiert.

Unter der Prozessidentifikation versteht man den Vorgang des Sammelns von Informationen über einen bestehenden Prozess und dessen Organisation in Form eines Ist-Prozessmodells.

1. Untersuchungsbereich definieren: Team, Verantwortlichkeiten und Prozess bestimmen.

   
   

2. Informationsbeschaffung: Prozess „end-to-end" abbilden bzw. konstruieren.

   
   

3. Prozessmodellierung: Erstellung des Prozessmodells in der ausgewählten Sprache.

   
   

4. Qualitätssicherung des Prozessmodells: Einhaltung von Modellierungsregeln und Modellkonventionen.

1. Fachexperte: Führt Teile des Prozesses im Arbeitsalltag durch , versteht den Prozess und seine eigene Rolle in der Tiefe und kennt verdeckte Abhängigkeiten.

   
   

2. Prozessanalystin: Sammelt und organisiert Wissen über den gesamten „end-to-end“ Prozess und ist für die Modellierung von Prozessen zuständig.

   
   

3. Prozessverantwortlicher: Ist für die Ausführung und Weiterentwicklung des Prozesses zuständig und sorgt für Verbindlichkeit und Austausch zwischen den Beteiligten.

1. Fragmentiertes Prozesswissen: Viele Prozessbeteiligte haben unterschiedliches Wissen, was zu gegensätzlichen Aussagen und Inkonsistenzen führt.

   
   

2. Fokussierung auf konkrete Prozessinstanzen: Beteiligte denken oft an konkrete Fälle (das sog. "Sunny-Day-Szenario") statt an den allgemeinen Prozesstyp, was zu fehlender Klarheit über Entscheidungen führt.

   
   

3. Mangelnde Vertrautheit mit Prozessmodellierungssprachen: Wenn Beteiligte die Modellierungssprache (z.B. BPMN) nicht verstehen, können die Modelle ihre Funktion als Kommunikationsinstrument nicht erfüllen.

1. Evidenzbasierte Identifikation:

   • Dokumentenanalyse: Nutzung bestehender Dokumente wie Organigramme, Prozessbeschreibungen oder Arbeitsanweisungen.

     
     

   • Beobachtung: Aktive oder passive Beobachtung des Prozesses, um die aktuelle Realität zu erfassen.

     
     

   • Automatisierte Prozesserkennung (Process Mining): Objektive Darstellung des Prozesses basierend auf Systemdaten.

     
     

2. Interviews: Detaillierte Einblicke in die ausgeführten Prozesse durch Befragung von Fachexperten.

   
   

3. Workshops: Gemeinsame Erarbeitung des Prozesses, um Übergabepunkte und Widersprüche schnell aufzudecken.

1. Identifiziere die Prozessgrenzen.

2. Identifiziere Aktivitäten und Ereignisse.

3. Identifiziere Prozessbeteiligte und Übergabepunkte.

4. Identifiziere den Kontrollfluss.

5. Identifiziere zusätzliche Elemente (z.B. Datenobjekte).

1. Syntaktische Qualität: Bezieht sich auf die korrekte Anwendung der Modellierungssprache und verhindert Mehrdeutigkeit.

   
   

2. Semantische Qualität: Drückt aus, wie gut die fachliche Realität abgebildet wird (Validität und Vollständigkeit).

   
   

3. Pragmatische Qualität: Bezieht sich auf die Verständlichkeit und Nutzbarkeit des Prozessmodells.

1. Verwende so wenige Modellelemente wie möglich.

2. Minimiere die Verbindungen zwischen den Elementen.

3. Verwende ein Startereignis für jeden Auslöser und ein Endereignis für jedes Ergebnis.

4. Modelliere so strukturiert wie möglich.

5. Vermeide OR-Gateways, wenn möglich.

6. Verwende Verb-Objekt-Bezeichnungen.

7. Zerlege Modelle mit mehr als 50 Elementen in Unterprozesse.

Eine RACI-Matrix ist ein Hilfsmittel zur Analyse und Darstellung von Verantwortlichkeiten.

• R - Responsible (Durchführungsverantwortung): Wer erledigt diese Aufgabe?

  
  

• A - Accountable (Rechenschaftspflicht): Wer gibt die Aufgabe frei oder ist dafür zuständig?

  
  

• C - Consulted (Konsultation): Wer verfügt über die notwendigen Informationen?

  
  

• I - Informed (Informationspflicht): Wer muss über den Status und die Ergebnisse informiert werden?