Wann lohnt sich eine Zustandsmaschine – und wann reichen einfache Zustände?

Ein Feld wie status = "ausstehend" scheint auszureichen, bis sich in einem Prozess Genehmigungen, Ausnahmen und Aktionen ansammeln, die davon abhängen, wie ein Vorgang seinen aktuellen Punkt erreicht hat. Dann tauchen praktische Fragen auf: Kann ein Vorgang nach der Genehmigung noch storniert werden? Wer darf einen Fall wieder öffnen? Was geschieht, wenn dieselbe Anfrage zweimal eingeht? Eine Zustandsmaschine hilft, solche Fragen zu beantworten. Sie beschreibt nicht nur den aktuellen Zustand, sondern auch die erlaubten Änderungen und deren Auswirkungen.

Nicht jeder Ablauf braucht dieses Modell. Bei einem kurzen, linearen Prozess sind eine Statuskennzeichnung und einfache Regeln womöglich leichter zu implementieren und zu pflegen. Entscheidend ist, die tatsächliche Komplexität des Ablaufs gegen den Aufwand abzuwägen, seine Regeln explizit festzuhalten – und nicht vorsorglich ein bestimmtes Muster einzuführen.

Statuskennzeichnung oder Zustandsmaschine: Was ist der Unterschied?

Ein Statusfeld bildet eine aktuelle Situation ab: Eine Aufgabe kann beispielsweise als „ausstehend“ oder „abgeschlossen“ gekennzeichnet sein. Das Feld allein erklärt jedoch nicht, welche Änderungen zulässig sind, welches Ereignis sie auslöst oder welche Aktionen damit verbunden sein müssen. Diese Logik verteilt sich häufig auf die Benutzeroberfläche, den Server und verschiedene Bedingungen im Code.

Eine Zustandsmaschine beschreibt den Prozess als festgelegte Menge von Zuständen und Übergängen. Ein Übergang legt fest, welches Ereignis einen Wechsel von einem Zustand in einen anderen erlaubt und – falls erforderlich – welche Bedingungen erfüllt sein müssen oder welche Aktionen ausgeführt werden. Der aktuelle Zustand begrenzt damit, welche Entwicklungen möglich sind.

Der Unterschied liegt nicht darin, wie viele Statuswerte in einer Datenbank gespeichert werden. Ein Statusfeld kann Teil einer expliziten Zustandsmaschine sein, wenn das System die Übergänge überprüft. Umgekehrt ist eine umfangreiche Liste von Zuständen noch kein gutes Modell, wenn niemand erklären kann, wie der Wechsel zwischen ihnen funktioniert.

Hinweise darauf, dass explizite Übergänge sinnvoll sind

Ein Modell bringt dann einen Mehrwert, wenn die Regeln vom jeweiligen Punkt im Prozess abhängen und fehlerhafte Übergänge Folgen haben. Achten Sie auf diese Anzeichen:

• Unterschiedliche erlaubte Aktionen: Nicht jede Person darf in jeder Phase genehmigen, bearbeiten oder stornieren. Oder eine Aktion ist erst nach einer Prüfung verfügbar.
• Alternative Abläufe: Eine Anfrage kann genehmigt, abgelehnt, zur Ergänzung von Informationen zurückgegeben oder storniert werden.
• Verteilte Regeln: Verschiedene Anwendungsteile prüfen unabhängig voneinander, ob ein Vorgang gültig ist. Dadurch können widersprüchliche Entscheidungen entstehen.
• Folgen eines Übergangs: Ein Wechsel muss eine Entscheidung dokumentieren, jemanden benachrichtigen oder eine weitere Aufgabe auslösen. Diese Wirkung sollte von der bloßen Änderung einer Statuskennzeichnung unterschieden werden.
• Wiederholungen und gleichzeitige Änderungen: Zwei Personen oder Prozesse könnten versuchen, denselben Fall zu ändern. Auch könnte eine Integration dasselbe Ereignis wiederholt übermitteln.

Ein guter Hinweis ist, wenn das Team häufig darüber diskutiert, ob eine Änderung in einer bestimmten Phase „zulässig sein sollte“. Hängt die Antwort vom vorherigen Zustand, von der handelnden Person oder von einem Geschäftsergebnis ab, sollte die Regel ausdrücklich und zentral festgehalten werden.

Wann einfache Zustände ausreichen

Ein einfaches Modell reicht oft aus, wenn der Prozess linear ist, nur wenige Übergänge hat und Ausnahmen selten oder leicht zu handhaben sind. Eine interne Aufgabe, die von „ausstehend“ zu „abgeschlossen“ wechselt, braucht beispielsweise womöglich nur ein Feld und eine klare Prüfung – insbesondere, wenn es weder Genehmigungen noch Wiederholungsversuche oder externe Folgen gibt.

Auch der Betriebsaufwand zählt. Eine Zustandsmaschine bringt zusätzliche Konzepte, Tests und Pflege mit sich. Ist der Ablauf eindeutig, kann dieser Aufwand den Nutzen übersteigen. Machen Sie nicht jede Änderung einer Bildschirmansicht, jeden Schritt in der Benutzeroberfläche oder jede kleine Abweichung zu einem Geschäftszustand: Ein visuelles Erlebnis entspricht nicht zwangsläufig einer Prozessphase.

Als praktische Faustregel gilt: Beginnen Sie mit der einfachsten Darstellung, mit der sich die wichtigen Regeln durchsetzen lassen. Treten wiederholt dieselben Bedingungen, implizite Übergänge oder Probleme durch unzulässige Änderungen auf, sollten Sie das Design überdenken. Die Weiterentwicklung kann schrittweise erfolgen: Sie müssen nicht den gesamten Prozess neu gestalten, um zunächst die riskantesten Übergänge zu formalisieren.

Kriterien für die Entscheidung

Es gibt keine allgemeingültige Anzahl von Zuständen oder Übergängen, ab der eine Zustandsmaschine erforderlich ist. Bewerten Sie das Verhalten und die Folgen von Fehlern anhand konkreter Fragen:

1. Wie viele tatsächliche Abläufe gibt es? Zählen Sie die geschäftlichen Pfade und ihre Verzweigungen, nicht nur die Statusbezeichnungen. Mehrere Pfade mit unterschiedlichen Berechtigungen oder Ergebnissen sprechen oft für ein explizites Modell.
2. Was passiert, wenn jemand einen unzulässigen Übergang versucht? Ist die Folge leicht und ohne großen Aufwand rückgängig zu machen, kann eine einfache Prüfung genügen. Könnten dadurch eine falsche Entscheidung, doppelte Arbeit oder eine schwer umkehrbare Aktion entstehen, sind klarere Kontrollen sinnvoll.
3. Sind gleichzeitige Änderungen oder wiederholte Ereignisse möglich? Falls ja, legen Sie fest, wie geprüft wird, ob sich der Zustand seit Beginn des Vorgangs geändert hat, und wie verhindert wird, dass die erneute Verarbeitung desselben Ereignisses Wirkungen doppelt auslöst.
4. Muss sich der Ablauf nachvollziehen lassen? Wenn Support, Revision oder Betrieb wissen müssen, wer was wann und warum getan hat, lässt sich die Entwicklung leichter rekonstruieren, wenn der aktuelle Zustand getrennt vom Ereignisverlauf gespeichert wird.
5. Passen die Regeln an einen verständlichen Ort? Sind miteinander verknüpfte Ausnahmen über mehrere Komponenten verteilt, geht es nicht mehr nur um die Zahl der Zustände. Es ist ein Hinweis darauf, dass dem Ablauf eine eindeutige Definition fehlt.

Zustände, Ereignisse und Ausnahmen benennen

Verwenden Sie Begriffe, die Geschäftsbeteiligte als Prozessphasen wiedererkennen. Ein Zustand beantwortet die Frage „In welcher Situation befindet sich der Fall?“, ein Ereignis die Frage „Was ist geschehen, sodass sich der Zustand geändert hat?“. „In Prüfung“ kann beispielsweise ein Zustand und „Prüfung genehmigt“ ein Ereignis sein. Verwenden Sie die beiden Begriffe nicht, als wären sie austauschbar.

Trennen Sie außerdem die Phase vom Ergebnis, wenn es sich um unterschiedliche Dimensionen handelt. „Abgeschlossen“ beschreibt eine Endphase, während „genehmigt“ oder „abgelehnt“ ein Ergebnis bezeichnet. Werden beide vermischt, können kombinierte Zustände wie „abgeschlossen und abgelehnt“ entstehen. Das vervielfacht die Varianten und erschwert es, die Regeln nachzuvollziehen.

Kennzeichnen Sie, welche Zustände terminal sind, in denen der Prozess also regulär endet. Legen Sie gesondert fest, ob eine Stornierung oder Wiedereröffnung möglich ist und wer sie vornehmen darf. Ein terminaler Zustand muss nicht jede administrative Aktion ausschließen. Die Ausnahme sollte jedoch klar begrenzt sein und darf nicht zu einem Hintereingang werden, über den sich die Regeln umgehen lassen.

Erzeugen Sie bei Wiederholungsversuchen nicht für jeden Versuch einen neuen Zustand, wenn der Fall in derselben Phase bleibt. Behalten Sie den passenden Zustand bei und speichern Sie den Versuch im Verlauf oder als separates Datum. Gehen Sie bei Fehlern und Ausnahmen ebenso vor: Führen Sie nur dann einen eigenen Zustand ein, wenn sich dadurch wesentlich ändert, was im weiteren Prozess möglich ist.

Hypothetisches Beispiel: Eine Anfrage mit Prüfung

Stellen Sie sich eine Anfrage vor, die eingeht, geprüft und schließlich genehmigt oder abgelehnt wird. In der einfachsten Variante könnte es die Zustände „eingegangen“, „in Prüfung“ und „bearbeitet“ geben, ergänzt um ein Ergebnis. Muss das Team zusätzliche Informationen anfordern, muss der Ablauf diese Unterbrechung abbilden und festlegen, welches Ereignis nach Eingang der Antwort die erneute Prüfung ermöglicht.

Ein Übergang kann festlegen, dass nur eine befugte Person eine Anfrage im Zustand „in Prüfung“ genehmigen oder ablehnen darf. Bei einer Ablehnung wird der Fall mit dem Ergebnis „abgelehnt“ abgeschlossen; fehlen Informationen, wechselt er in den Zustand „Informationen ausstehend“. Dafür ist keine spezielle Plattform erforderlich: Es genügt, wenn das System diese Änderungen zuverlässig prüft und die erforderlichen Daten erfasst.

Dieses Beispiel ist hypothetisch; die Bezeichnungen und Regeln müssen an den tatsächlichen Prozess angepasst werden. Wenn eine Informationsanfrage weder die verfügbaren Aktionen verändert noch nachverfolgt werden muss, kann ein Vermerk ausreichen. Das Modell sollte operative Unterschiede abbilden und nicht jede denkbare Möglichkeit vorwegnehmen.

Häufige Fehler und Checkliste

Ein Modell kann komplizierter werden als der Prozess selbst, wenn es für jedes Detail einen Zustand anlegt, Berechtigungen mit Prozessphasen vermischt oder offenlässt, was mit bestehenden Fällen geschieht, wenn sich die Regeln ändern. Ebenfalls problematisch ist es, Übergänge in einem Diagramm zu modellieren und den Code dann davon abweichen zu lassen: Die Regel muss dort durchgesetzt werden, wo die Änderung angenommen wird.

Prüfen Sie vor der Entscheidung oder Überarbeitung des Ansatzes die folgenden Punkte:

• Steht jeder Zustand für eine Situation, die das Geschäft erklären kann?
• Beschreiben Ereignisse tatsächliche Vorkommnisse, und legen Übergänge fest, welche Änderungen sie erlauben?
• Sind alternative Abläufe, Stornierungen und Wiedereröffnungen klar definiert?
• Werden unzulässige Vorgänge abgelehnt und wiederholte Ereignisse sowie gleichzeitige Änderungen kontrolliert?
• Wird der Verlauf erfasst, wenn Entscheidungen später nachvollzogen werden müssen?
• Gibt es Zustände, die sich zusammenfassen lassen, ohne wichtige Regeln oder Informationen zu verlieren?

Wählen Sie eine Zustandsmaschine, wenn sie Regeln sichtbar und durchsetzbar macht, die sonst verteilt blieben, und wenn die Kosten eines fehlerhaften Übergangs diese Kontrolle rechtfertigen. Ist der Prozess linear und vorhersehbar, beginnen Sie mit einfachen Zuständen. Überprüfen Sie die Entscheidung, wenn sich Abläufe, Ausnahmen oder Folgen ändern: Das beste Modell ist das einfachste, das die Entwicklung der Arbeit zuverlässig abbildet.