BPM - VL 05

Die iterative Informationserhebung über einen Prozess und die Organisation dieser Information

1) Rahmen definieren -> Team das an Prozess arbeiten wird

2) Informationen erheben -> Prozessverständnis wird entwickelt; versch. Erhebungsmethoden

3) Modellierungsarbeit durchführen -> Mit Modellierungsmethode in Prozessmodell

4) Prozessmodellqualität sicherstellen -> Qualität anhand versch. Kriterien sicherstellen

Prozessanalyst:

• Informationserhebung und -organisation

• Koordination des Modellierungsvorgangs (unter Leitung des Prozessverantwortlichen)

• kennen nicht alle Details eines Prozesses

Fachexperte:

• Genaues Wissen über Prozess

• Interne Sicht auf alle Beteiligten

• Externe Sicht auf alle Lieferanten, Kunden, Partner

• Oft keine Modellierungskenntnisse

Dass beide an der Festlegung des Rahmens der Prozesserhebung beteiligen

1. Fragmentiertes Prozesswissen

-> Aktivitäten nicht von ein und derselben Ressource durchgeführt; Prozessanalyst muss mit Fachexperten sprechen um Information zu gewinnen; Konfliktpotential durch versch. Sichten

1. Fallbasiertes Denken

-> Fachexperte betrachtet unter Einzelfallperspektive, nicht generalistisch; Fachexperte geben Auskunft über spezifische Aspekte damit Analyst ein systematisches Prozessmodell erstellt

1. Mangelnde Modellierungskenntnisse

-> Fachexperten kennen Modellierungssprache nicht, was Kommunikation und Feedback erschwert; umgangssprachliche Erlärung des Modells

1. Dokumentenanalyse

-> Infos sammeln ohne Kontakt zu Fachexperten

-> Nutzung bereits bestehender Dokumente zu Geschäftsprozessen

-> Dokumente verweisen auf Rollen, Aktivitäten, Geschäftsobjekte

1. Beobachtung

-> Fokus auf Bearbeitung einzelner Fälle um Funktionsweise zu verstehen

-> Entweder:

• aktiv (Kunde) -> Prozess in Gang setzen und Schritte/ Möglichkeiten aufzeichnen

• passiv (Beobachter) -> Prozess in Gesamtheit verstehen

1. Automatische Prozessmodellgenerierung

-> Ereignisprotokolldaten zur automatischen Erstellung von Prozessmodellen

-> Nutzung realer Daten

-> Vielzahl prozessbezogener Informationen werdn erfasst

-> multiple Systemdaten werden genutzt

Fachexperten werden über Funktionsweise eines Prozesses befragt:

-> Vorwärts gerichtet (ausgelöst durch vorrausgehendes Ereignis)

-> Rückwärts gerichtet (ausgehend von Prozessergebnis)

Bei jedem Interview wird geklärt:

• welche Eingabe von vorgelagerten Aktivitäten erwartet wird

• welche Entscheidung getroffen wird

• welche Ergebnisse aus Aktivitäten hervorgehen

• welche Ressource weitergereicht wird

• Gute Organisation

• Offene Atmosphäre

• Gleichwertige Berücksichtigung aller Beteiligungen

• Alle Stakeholdergruppen werden eingebunden

• Infos ggf. bereits in der Dokumentation der Prozessarchitektur enthalten

• Prozessgrenzen varrieren je nach Perspektive der Stakeholder

• Auslösende und Beendende Ereignisse identifizieren durch:

  • Betrachtung der Geschäftsobjekte

  • Ermittlung potentieller Ergebnisse

  • Negative Ergebnisse werden als Abbruch-Ereigniss identifiziert

• Erhebung von Aktivitäten und Zwischenereignissen in Workshops/ Interviews

• Menge von Aktivitäten/ Ereignissen ist überarbeit- und anpassbar

• Je komplexer der Prozess, desto eher Fokus auf Hauptaktivitäten und Zwischenereignisse

• Aktivitätsreihenfolge ist noch nicht festgelegt

• Explizite Identifizierung der Prozesspunkte/ Schnittstellen bei denen Arbeit von einer Ressource an andere übergeben wird

• Externe Parteien sowie stattfindende, zugehörige Nachrichtenflüsse und Übergaben werden mithilfe von Pools modelliert

• wann und warum Aktivitäten und Ereignisse ausgeführt werden

• festhalten von Reihenfolge, Entscheidungspunkten, nebenläufigen Ausführungen, Aktivitäten, Ereignissen und Wiederholungen

  • BPMN -> XOR und ODER-Gateways

    -> Sequenzflusskanten, Schleifenmodellierung, Nebenläufige Aktivitäten mit UND-Gateways

• relevante Geschäftsobjekte und Ausnahmen ermitteln

• Datenverknüpfungen (Bzh zw. Objekten, Speichern, Beziehung, Aktivitäten, Ereignissen)

• Angeheftete Ereignisse, Ausnahmeflüsse, Kompensationen zur Modellierung von Ausnahmen

• fallspezifischer Umfang der Ergänzungen von Datenelementen und Ausnahmen

Syntaktische Regel:

-> stukturell korrekte Anwendung aller Regeln auf Element- und Modellebene

Syntaktische Regel :

-> verhaltenstechnisch korrekt, wenn alle Verhaltensanomalien vermieden werden

Verklemmung: laufende Instanz kann nicht weiter ausgeführt werden, sobald bestimmter Zustand erreicht ist

Endlosschleife: Instanz läuft endlos weiter

Semantische Qualität: Übereinstimmung zw. Modell und realen Prozess

-> Validität: Alle Modellaussagen auch richtig für realen Prozess

-> Vollständigkeit: Modell enthält alle relevanten Aussagen über den Geschäftsprozess

Validierung: Verfahren, um semantische Qualität zu prüfen

-> keine formalen Regeln, feststellbar durch Gespräche, Interviews, Workshops

Einschätzung der tatsächlichen Verwendbarkeit des Modells

-> Verständlichkeit: Wie einfach les- und verwendbar

-> Wartbarkeit: Wie einfach veränderbar

-> Erlernbarkeit: Wie gut bildet es Realität ab

Zertifizierung: Verfahren, um pragmatische Qualität zu prüfen

-> schwer vorher einzuschätzen, durch Arbeit der Mitarbeiter beurteilbar

-> Beteiligte erlangen umfassendes Verständnis, unterstützt durch Interviews und Experimente

Wichtiges Hilfsmittel, um pragmatische Qualität zu verbessern:

1. Vokabular - vermeiden best. Elemente

2. Struktur - eingrenzen der Modellstruktur

3. Semantik - best. Elemente nicht überall verwendbar

4. Aussehen - Erscheinungsbild in Bezug auf Bezeichnung, Layout, Notation eingeschränkt und vereinheitlicht