Antwort.

Historisch haben Systemanalytiker manuelle Methoden verwendet — Beobachtung, Interviews, Analyse vorhandener Dokumente. Mit der Entwicklung von IT entstanden Standards (z.B. BPMN, IDEF0, EPC), die den Ansatz zur Modellierung der aktuellen und zukünftigen Prozesse strukturierten.

Problem: Die Wahl des Ansatzes wird oft durch unvollständige Informationen, Zeitdruck, die Komplexität des Fachgebiets und das unterschiedliche Reifegrad der Geschäftsprozesse erschwert. Fehler in diesem Stadium führen zu falschen Anforderungen, erheblichen Nacharbeiten und einem Vertrauensverlust in die Rolle des Analytikers.

Lösung: Der optimale Ansatz ist die Kombination quantitativer und qualitativer Methoden:

Dokumentation und tatsächliches Verhalten durch Beobachtungen analysieren.
Prozesse je nach Aufgabe mit BPMN- oder IDEF0-Notation formalisieren.
Für 'as-is' Feedback von den Ausführenden einholen, Workshops organisieren.
Für 'to-be' Modellierung mit dem Auftraggeber durchführen, erwartete Ergebnisse und Erfolgskriterien im Voraus festhalten.
Gap-Analyse durchführen, Lücken und Risiken identifizieren.

Wesentliche Merkmale:

Einsatz mehrerer Techniken parallel.
Dokumentation von Ereignissen und alternativen Szenarien.
Ständige Verifizierung der Daten durch Demonstrationen und kurze Iterationen.

Trickfragen.

Kann man BPMN immer zur Beschreibung aller Prozesse, einschließlich technischer und komplexer Integrationen, verwenden?

BPMN eignet sich nur für Geschäftsprozesse oder Verfahren mit klarer Logik. Technisch aufwändige oder tief integrierte Szenarien sollten besser durch Sequenzdiagramme (UML), Architekturschemata oder spezialisierte Notationen beschrieben werden.

Reicht es aus, ein Interview mit einem Vertreter der Geschäftseinheit zu führen, um ein korrektes Bild des aktuellen Prozesses zu erhalten?

Nein, eine einzige Quelle spiegelt nie die gesamte Realität wider. Es ist notwendig, Rückmeldungen von verschiedenen Rollen zu sammeln: Ausführenden, Nutzern, IT-Diensten, Managern. Dies minimiert das Risiko von Fehlern und deckt versteckte Enden des Prozesses auf.

Muss der zukünftige 'to-be'-Prozess bis ins kleinste Detail erarbeitet werden, bevor die IT-Lösung entworfen wird?

Nicht immer. Eine zu detaillierte Ausarbeitung führt zu Bürokratie und Flexibilitätsverlust. Es reicht aus, die Hauptszenarien, Automatisierungspunkte, notwendige Rollenänderungen und Integrationen abzustimmen; die Details sollten iterativ während der Umsetzung erarbeitet werden.

Typische Fehler und Anti-Patterns

Prozessbeschreibung nur auf Basis der Theorie, ohne Analyse tatsächlicher Geschäftsszenarien.
Ignorieren der Schatten- oder impliziten Ausführungswege des Prozesses.
Übermäßige Detaillierung oder umgekehrt, übermäßige Verallgemeinerung von Diagrammen.

Praxisbeispiel

Negativer Fall: Der Analyst hat die Prozesskarte nur basierend auf den Regulierungen erstellt, ohne die routinemäßigen Umgehungen und "Umgehungsschemata" der Ausführenden zu analysieren.

Vorteile:

Schnelle Abstimmung der Dokumentation

Nachteile:

Fehlende tatsächliche Nützlichkeit und Verständnis der realen Probleme
IT-Lösung funktioniert schlecht in der Praxis, Nachbesserungen erforderlich

Positiver Fall: Der Analyst hat Workshops durchgeführt, Interviews geführt, den Ist- und Soll-Zustand formalisiert und die Unterschiede aufgezeigt. Er hat Beispiele aus realen Szenarien und deren Probleme einbezogen und das Feedback von Stakeholdern berücksichtigt.