Antwort.

Geschichte der Frage:

Die Automatisierung nicht standardisierter oder sich erst entwickelnder Geschäftsprozesse galt lange Zeit als schwierige Aufgabe aufgrund des Fehlens klar definierter Szenarien und der hohen Veränderlichkeit. Traditionelle Ansätze der Systemanalyse sind nicht immer geeignet, und es wird eine flexiblere Methodik benötigt.

Problem:

Das Hauptproblem bei der Arbeit mit solchen Prozessen ist ihre Dynamik: Die Beschreibung zu Beginn spiegelt oft nicht die Kernpunkte einiger Operationen wider, und die Anforderungen der Kunden können sich während der Arbeit schnell ändern oder präzisiert werden.

Lösung:

Um Anforderungen korrekt zu ermitteln und zu beschreiben, werden iterative Ansätze (Agile, Lean) angewendet, Daten durch Beobachtung und schnelle Prototypen gesammelt, Benutzer aktiv einbezogen (zum Beispiel durch Workshops) und Anforderungen in Form von User Stories festgehalten, ergänzt durch lebendige Dokumentation in Confluence, Miro, Figma usw. Die wichtigsten Merkmale des Ansatzes:

Kontinuierliches Feedback vom Benutzer und vom Geschäftsteam
Verwendung von Prototyping und schnellen MVPs zur Konkretisierung von vagen Szenarien
Inkrementelle Klärung der Anforderungen: Wir halten nur das fest, was lebensfähig und wiederholbar ist

Fragen mit Hintergedanken.

Sind die Anforderungen zu Beginn und am Ende der Analyse eines instabilen Prozesses identisch?

Nein, am Ende der Analyse ändern sich die Anforderungen: Ein Teil wird obsolet, während ein anderer Teil erst nach der Anwendung von Prototypen in der praktischen Anwendung formalisiert wird.

Muss der gesamte Geschäftsprozess sofort festgehalten werden, wenn er sich ändert?

Nein, es sollten nur die überprüften und funktionierenden Fragmente festgehalten werden, das andere sollte als Hypothese belassen oder im Verlauf der Entwicklung präzisiert werden.

Sollte man sich nur auf ein Mittel zur Festhaltung von Anforderungen beschränken?

Nein, es ist wichtig, mehrere Kanäle zu nutzen: Stand-up-Boards, elektronische Entwürfe, Prototypen - für verschiedene Zielgruppen und Phasen.

Typische Fehler und Anti-Pattern

Versuch, alle Aspekte im Voraus zu detaillieren (Wasserfall)
Ignorieren von Feedback vom Benutzer
Arbeit ausschließlich mit bereits genehmigter Dokumentation oder nur mündlichen Anforderungen, ohne lebendige Beispiele

Beispiel aus dem Leben

Negativer Fall:

Das Unternehmen entschloss sich, einen Prozess zu automatisieren, der noch nicht vollständig etabliert war. Der Analyst beschrieb den Prozess strikt nach Schema und hielt alles fest, was die Mitarbeiter erzählten. Nach dem Start änderte sich der Prozess schnell, und das System entsprach nicht den neuen Realitäten.

Vorteile:

Schnelle Integration bestehender Schemata

Nachteile:

Der Prozess wurde nur teilweise automatisiert, die meisten Änderungen wurden nicht berücksichtigt, teure Nachbesserungen

Positiver Fall:

Der Analyst nahm nur einen Teil der stabilen Phasen auf, baute ein MVP mit minimalem Funktionsumfang, sammelte Feedback, überarbeitete die Anforderungen zusammen mit dem Geschäft und ließ Raum für Änderungen.