Einen Prozess vor der Automatisierung sauber beschreiben
Vom Änderungsauftrag bis zur geprüften Veröffentlichung: ein fiktiver Redaktionsablauf mit klaren Zuständen, Zuständigkeiten und begrenzten Nachweisen.
Ein Prozess wird nicht verständlich, nur weil seine Schritte mit Pfeilen verbunden sind. Vor einer Automatisierung müssen Auslöser, Daten, Zuständigkeiten, Entscheidungen und Fehlerwege zusammenpassen. Sonst beschleunigt die Technik möglicherweise genau die Unklarheiten, die bisher durch Rückfragen aufgefangen wurden. Dieser Beitrag zeigt an einer fiktiven Produktredaktion, wie ein Arbeitsablauf so beschrieben wird, dass daraus eine belastbare Umsetzungsentscheidung entstehen kann.
Mit dem Ergebnis statt mit einem Werkzeug beginnen
Die Ausgangsidee lautet: Produktänderungen sollen automatisch auf der Webseite erscheinen. Darin stecken mehrere ungeklärte Entscheidungen. Welche Änderungen sind gemeint? Woher stammen sie? Wer entscheidet über ihre Richtigkeit? Wann gilt die Aktualisierung tatsächlich als abgeschlossen? Die Auswahl einer Schnittstelle beantwortet diese Fragen nicht.
Für unser Beispiel wird das Ziel enger formuliert: Eine fachlich freigegebene Änderung technischer Produktinformationen wird einer vorhandenen Produktseite zugeordnet, redaktionell vorbereitet und nach Prüfung veröffentlicht. Am Ende ist die richtige Fassung auf der richtigen Seite sichtbar und nachvollziehbar dokumentiert. Eine eingegangene Nachricht allein ist noch kein Auftrag zur sofortigen Veröffentlichung.
Halten Sie auch fest, was nicht zum betrachteten Vorgang gehört. Die Erstellung neuer Produkte, Preisverhandlungen und das Versenden einer Kundeninformation können eigene Prozesse sein. Diese Grenzen verhindern, dass eine anfangs kleine Beschreibung nebenbei die vollständige Organisation abbilden soll.
Den heutigen Ablauf tatsächlich aufnehmen
Fragen Sie die Beteiligten, wie der Vorgang heute funktioniert. Lassen Sie sich einen geeigneten abgeschlossenen Fall zeigen, soweit das im jeweiligen Rahmen zulässig ist. Interessant sind auch Übergaben, Notizen und Rückfragen, die in keiner offiziellen Arbeitsanweisung stehen. Dort steckt häufig Wissen darüber, warum ein scheinbar unnötiger Schritt existiert.
Trennen Sie die heutige Arbeitsweise von der gewünschten Verbesserung. Wenn die Redaktion derzeit eine Rückfrage per Telefon klärt, gehört dies zunächst in die Beschreibung. Erst danach wird beurteilt, ob die Rückfrage vermieden oder anders organisiert werden kann. Ein Sollbild, das solche Tätigkeiten einfach auslässt, beweist noch keine Einsparung.
Digital.gov erläutert Journey Maps und Service Blueprints als unterschiedliche Perspektiven auf Nutzererfahrung und unterstützende Abläufe. Für unsere Untersuchung hilft die Trennung zwischen sichtbarer Aufgabe und internen Übergaben. Das Beispiel übernimmt daraus keinen vorgeschriebenen Zeitbedarf und keine Behauptung über tatsächlich befragte Personen.
Auslöser und Endpunkt eindeutig benennen
Ein Auslöser sollte ein beobachtbares Ereignis sein. „Produktinformation muss besser werden“ ist dafür zu unbestimmt. „Eine freigegebene technische Änderungsfassung liegt vor“ ist präziser. Ergänzen Sie, woran diese Freigabe erkennbar ist und wer sie erteilt. Eine Nachricht mit dem Betreff „Bitte aktualisieren“ ist nicht automatisch derselbe Nachweis.
Der Endpunkt braucht ebenfalls ein überprüfbares Kriterium. Im Beispiel endet der Vorgang nicht beim Speichern eines Entwurfs. Er endet, wenn die vorgesehene Produktseite die geprüfte neue Fassung zeigt und die Zuordnung dokumentiert wurde. Ein technischer Erfolg beim Übertragen der Daten kann vorher liegen.
Benennen Sie weitere mögliche Abschlüsse: Eine unzulässige Änderung kann abgelehnt werden. Eine doppelt eingegangene Meldung kann mit Verweis auf den bestehenden Vorgang geschlossen werden. Ein ungeklärter Fehler bleibt dagegen offen. Diese Zustände dürfen nicht alle unter „erledigt“ verschwinden.
Einen kompakten Prozesssteckbrief anlegen
| Feld | Beschreibung im Beispiel |
|---|---|
| Zweck | Geprüfte technische Produktinformationen auf der passenden Seite aktualisieren |
| Auslöser | Fachlich freigegebene Änderungsfassung liegt vor |
| Eingaben | Produktkennung, Quellfassung, Änderungsumfang und Freigabenachweis |
| Verantwortung | Fachbereich für Daten, Redaktion für Darstellung, zuständige Stelle für Veröffentlichung |
| Ergebnis | Richtige Seite zeigt geprüfte Fassung mit nachvollziehbarer Zuordnung |
| Ausnahmen | Fehlende Zuordnung, widersprüchliche Daten, Ablehnung oder technischer Fehler |
Dieser Steckbrief schafft eine gemeinsame Grundlage. Er ersetzt nicht die anschließende Untersuchung der einzelnen Schritte. Sein Nutzen liegt darin, dass sich ein Streit über das Ziel nicht erst nach der technischen Umsetzung zeigt. Zwei Beteiligte sollten anhand desselben Beispiels erkennen können, ob sie denselben Prozess meinen.
Rollen und tatsächliche Befugnisse unterscheiden
Eine Rolle beschreibt eine Verantwortung im Ablauf. Sie muss nicht mit einer einzelnen Person oder einer Abteilungsbezeichnung identisch sein. Der Fachbereich bestätigt die technische Aussage. Die Redaktion prüft die verständliche Darstellung. Die Veröffentlichung erfolgt durch eine dafür zuständige Stelle. In einem kleinen Team kann eine Person mehrere Rollen übernehmen, die Entscheidungen bleiben trotzdem unterscheidbar.
Die technische Berechtigung ist eine zusätzliche Frage. Ein Konto kann möglicherweise veröffentlichen, obwohl seine vorgesehene Aufgabe nur die Vorbereitung eines Entwurfs ist. Für die Automatisierung müssen Rolle, erlaubte Aktion und tatsächlicher Zugang zusammenpassen. Ein allgemein verwendeter Administrationszugang ist keine sinnvolle Beschreibung fachlicher Zuständigkeit.
Der GOV.UK-Leitfaden zur Zusammenarbeit über Organisationsgrenzen behandelt die Abstimmung entlang übergreifender Aufgaben. Übertragen auf unser Beispiel ist nicht nur der einzelne Redaktionsschritt wichtig, sondern auch die Verlässlichkeit seiner Übergabe aus dem Fachbereich und in die Veröffentlichung.
Übergaben als Vereinbarungen beschreiben
Bei jeder Übergabe werden Eingabe, erwartete Qualität und nächster Verantwortlicher festgehalten. Für die Redaktion genügt nicht „Produktdaten erhalten“. Sie benötigt eine eindeutige Produktkennung und eine nachvollziehbare Quellfassung. Wenn eine dieser Angaben fehlt, muss der weitere Weg feststehen. Andernfalls wird die Unklarheit nur schneller zwischen Systemen verschoben.
Notieren Sie außerdem, woran die abgebende Stelle erkennt, dass der Vorgang übernommen wurde. Eine versendete Nachricht beweist nicht, dass jemand mit der Arbeit begonnen hat. Für manche Abläufe reicht eine gemeinsame Aufgabenliste mit einem klaren Status. Andere benötigen einen verbindlicheren Übergabemechanismus. Die Lösung folgt der Aufgabe.
Beschreiben Sie Wartezustände ausdrücklich. „Wartet auf fachliche Klärung“ unterscheidet sich von „kann veröffentlicht werden“. Wenn diese Zustände vermischt werden, lässt sich später kaum feststellen, ob die Technik oder eine fehlende Entscheidung den Vorgang aufhält.
Datenquellen und Fassungen festlegen
Für jede fachliche Information wird eine maßgebliche Quelle benannt. Im Beispiel stammt eine technische Eigenschaft aus einem freigegebenen Datenblatt. Eine ältere Webseite oder eine beiläufige Chatantwort ersetzt diese Quelle nicht. Wenn mehrere Unterlagen einander widersprechen, benötigt der Prozess einen Klärungsweg und keine zufällige Auswahl.
Eine Freigabe muss sich auf eine bestimmte Fassung beziehen. Wird der Entwurf danach verändert, ist zu entscheiden, ob die Prüfung weiterhin gilt. Ohne diese Zuordnung kann ein System formal den Status „freigegeben“ tragen und trotzdem einen anderen Inhalt veröffentlichen. Die Fassung ist deshalb Teil der Prozessbeschreibung und nicht nur ein späteres Datenbankdetail.
{
"case_id": "AENDERUNG-017",
"product_ref": "PRODUKT-004",
"source_version": "datenblatt-fassung-3",
"draft_version": "entwurf-2",
"reviewed_draft_version": null,
"status": "wartet_auf_pruefung"
}Der Datensatz ist erfunden und dokumentiert bewusst eine noch offene Prüfung. Er ist kein Beleg einer tatsächlich erteilten Freigabe. Seine Aufgabe besteht darin, die notwendige Beziehung zwischen Quelle, Entwurf und geprüftem Stand sichtbar zu machen.
Entscheidungen in beobachtbare Bedingungen übersetzen
„Wenn alles passt“ ist keine ausreichend genaue Entscheidungsregel. Welche Angaben müssen vorhanden sein? Wer beurteilt einen Widerspruch? Welche Entwurfsfassung wurde geprüft? Formulieren Sie Bedingungen, die eine zuständige Person anhand konkreter Informationen entscheiden kann. Nicht jede Bedingung muss bereits automatisch ausgewertet werden.
Für das Beispiel gibt es zunächst drei Wege: Unvollständige Unterlagen gehen zur Klärung zurück. Vollständige Unterlagen werden redaktionell vorbereitet. Eine geprüfte Entwurfsfassung kann an die Veröffentlichung übergeben werden, wenn die dafür festgelegte Verantwortung tatsächlich wahrgenommen wurde. Eine maschinelle Vollständigkeitsprüfung erteilt diese fachliche Freigabe nicht selbst.
Wenn eine Entscheidung mehrere zulässige Ergebnisse hat, muss jeder Weg beschrieben sein. Das gilt auch für ein ausdrückliches Nein. Eine Ablehnung ist kein technischer Fehler und sollte nicht durch endlose automatische Wiederholung behandelt werden.
Eine lesbare Notation auswählen
Für ein kleines Team kann zunächst eine nummerierte Schrittfolge mit Rollen und Entscheidungstabelle genügen. Wenn mehrere Organisationen und parallele Abläufe beteiligt sind, kann eine etablierte Modellierungssprache helfen. Die OMG-Spezifikation BPMN 2.0.2 stellt dafür eine formale Grundlage bereit. Eine frei gezeichnete Skizze ist dadurch nicht automatisch ein gültiges BPMN-Modell.
Verwenden Sie Symbole nur mit ihrer tatsächlichen Bedeutung. Eine Raute sollte nicht beliebig „wichtiger Schritt“ bedeuten. In einem ausführbaren Modell müssen Entscheidung und folgende Wege zur verwendeten Notation passen. Für den fachlichen Einstieg ist eine einfache eindeutig beschriftete Darstellung oft besser als ein dekoratives Diagramm mit unklaren Symbolen.
Prüfen Sie die Lesbarkeit mit einem konkreten Vorgang. Eine beteiligte Person sollte zeigen können, wo ihr Arbeitsanteil beginnt, welche Information sie benötigt und was nach einem negativen Prüfergebnis geschieht. Wenn dies nicht gelingt, ist die Darstellung noch nicht ausreichend verständlich.
Menschliche Arbeit und technische Ausführung trennen
Eine redaktionelle Bewertung ist eine andere Art von Aufgabe als das Übertragen eines Datensatzes. Camundas Dokumentation zu User Tasks und Service Tasks zeigt diese Unterscheidung in einer konkreten Prozessumgebung. Daraus folgt keine Empfehlung, für unser Beispiel zwingend dieses Produkt einzusetzen.
Die fachliche Beschreibung sollte diese Trennung unabhängig vom Werkzeug enthalten. Eine technische Übertragung kann erfolgreich sein, während die inhaltliche Entscheidung noch aussteht. Umgekehrt kann eine Freigabe vorliegen, obwohl die Veröffentlichung wegen eines technischen Problems nicht stattgefunden hat. Beide Fälle benötigen unterschiedliche Zustände und Zuständigkeiten.
Auch ein KI-erstellter Entwurf bleibt in unserem Beispiel ein Entwurf. Wenn ein späterer Arbeitsschritt tatsächlich automatisiert wird, wird dafür festgelegt, welche Eingaben er erhalten und welche Ergebnisse er verbindlich erzeugen darf. Ein allgemeiner Werkzeugname ersetzt diesen Vertrag nicht.
Ausnahmen zuerst an konkreten Fällen prüfen
| Fall | Erwarteter Weg | Zu klärende Verantwortung |
|---|---|---|
| Produktkennung fehlt | Unterlagen zur Klärung zurückgeben | Fachbereich ergänzt eindeutige Zuordnung |
| Zwei Quellen widersprechen sich | Vorbereitung unterbrechen | Fachlich zuständige Stelle entscheidet über Quelle |
| Prüfung lehnt Entwurf ab | Begründet überarbeiten oder Vorgang beenden | Redaktion und fachliche Prüfung |
| Veröffentlichung schlägt fehl | Technischen Zustand prüfen, nicht sofort Erfolg melden | Verantwortliche Stelle für Veröffentlichung und Betrieb |
| Dieselbe Meldung kommt erneut | Bestehenden Vorgang erkennen | Prozessverantwortung definiert Zuordnung |
Diese Fälle sind erfundene Prüfszenarien. Sie zeigen, welche Entscheidungen in der Beschreibung fehlen könnten. Sie sind keine Statistik über tatsächliche Störungen. Für einen realen Prozess ergänzen die Beteiligten ihre beobachteten wichtigen Ausnahmearten.
Wiederholung nicht mit erfolgreicher Reparatur verwechseln
Technische Übertragungen können scheitern oder mit unklarem Ergebnis enden. Eine automatische Wiederholung muss berücksichtigen, ob der erste Versuch bereits eine Änderung ausgelöst hat. Sonst entstehen doppelte Vorgänge oder mehrfach versendete Mitteilungen. Die Beschreibung sollte deshalb festlegen, woran eine wiederholte Bearbeitung desselben fachlichen Vorgangs erkannt wird.
Ein wiederholbarer technischer Schritt ist nicht dasselbe wie eine erneut erforderliche menschliche Entscheidung. Eine abgelehnte Entwurfsfassung wird durch erneutes Absenden nicht freigegeben. Eine korrigierte Fassung benötigt wiederum die für sie vorgesehene Beurteilung. Diese Unterscheidung verhindert, dass eine allgemeine Wiederholungsfunktion fachliche Grenzen überspringt.
In Camundas Beschreibung exklusiver Gateways ist auch der Fall ohne passende Bedingung oder Standardweg dokumentiert. Für unsere Planung ist daran wichtig, dass ein nicht abgedeckter Zustand eine ausdrückliche Behandlung braucht. Er darf nicht zufällig den bequemsten Erfolgspfad erhalten.
Durchlaufzeit und Bearbeitungszeit getrennt erfassen
Eine Redaktion kann einen Entwurf in kurzer konzentrierter Arbeit vorbereiten und anschließend lange auf eine fachliche Antwort warten. Beide Zeiten gehören zum Vorgang, beschreiben aber unterschiedliche Ursachen. Eine schnellere Textübernahme beseitigt die Wartezeit nicht automatisch. Die Messfrage muss deshalb zum vermuteten Problem passen.
Die GOV.UK-Anleitung zu Leistungskennzahlen verbindet Ziel, Hypothese und geeignete Beobachtung. Für unser Beispiel könnten Beginn, Übergaben, Rückfragen und nachgewiesener Abschluss getrennt erfasst werden. Daraus werden hier keine tatsächlichen Laufzeiten oder pauschalen Einsparungsquoten erfunden.
Halten Sie bei einer eigenen Auswertung fest, welche Fälle einbezogen sind. Eine einfache Textkorrektur und eine fachlich umstrittene Produktänderung dürfen nicht ohne Erklärung als identische Arbeit behandelt werden. Der Kontext entscheidet, welche Vergleiche eine Aussage tragen können.
Den beschriebenen Prozess gemeinsam durchspielen
Nehmen Sie zuerst einen vollständigen fiktiven Änderungsauftrag. Jede Rolle beschreibt, welche Information sie erhält, welche Entscheidung sie trifft und was sie weitergibt. Danach wird eine wichtige Eingabe entfernt. Zuletzt wird ein technischer Fehler nach einer bereits erteilten Freigabe angenommen. Diese Durchgänge testen unterschiedliche Eigenschaften der Beschreibung.
Notieren Sie offene Fragen als Ergebnis. Wenn niemand sagen kann, wer eine widersprüchliche Quellfassung klärt, ist das eine relevante Erkenntnis. Die Lücke sollte nicht durch eine erfundene automatische Entscheidung geschlossen werden. Erst die geklärte Zuständigkeit macht den nächsten Umsetzungsschritt belastbar.
Ein solches Durchspielen ist keine echte Veröffentlichung und kein Beweis für den Betrieb unter Last. Es kann jedoch zeigen, ob Ziel, Übergaben und Ausnahmewege in sich verständlich sind. Dokumentieren Sie genau diesen begrenzten Nachweis statt die gesamte Automatisierung als bereits erfolgreich umgesetzt zu beschreiben.
Erst jetzt geeignete Automatisierungsschritte auswählen
Nach der Klärung lassen sich einzelne Arbeiten gezielt beurteilen. Das Prüfen vorhandener Pflichtangaben kann gut regelbasiert sein. Die Zuordnung zu einem bestehenden Produkt kann einen eindeutigen Schlüssel benötigen. Die fachliche Bewertung einer unklaren technischen Behauptung bleibt eine andere Aufgabe. Diese Unterschiede bestimmen, welcher Schritt wie unterstützt werden kann.
Beginnen Sie mit einem abgegrenzten Teil, dessen Eingaben und Ergebnis gut beschrieben sind. Planen Sie seine Beobachtung und den Rückweg. Die bestehende Arbeit muss während der Umstellung nachvollziehbar bleiben. Zwei gleichzeitig gepflegte widersprüchliche Vorgangsstände können mehr Schwierigkeiten schaffen als die ursprüngliche manuelle Übergabe.
Die wichtigste Leistung der Prozessbeschreibung ist damit eine bessere Entscheidung. Sie zeigt, was automatisiert werden kann, was vorher verändert werden sollte und welche Verantwortung bewusst bei Menschen bleibt. Eine technisch aufwendige Lösung ist kein Ersatz für diese Klarheit.
Änderungen am Ablauf selbst kontrollieren
Auch die Prozessbeschreibung besitzt eine Fassung und eine verantwortliche Stelle. Wenn sich die fachliche Quelle oder die Veröffentlichungsregel ändert, sollte diese Änderung nachvollziehbar in den Ablauf übernommen werden. Ein altes Diagramm im Projektordner und eine neue Regel im Gespräch sind keine verlässliche gemeinsame Grundlage. Benennen Sie, welche Beschreibung für den nächsten Umsetzungsstand maßgeblich ist.
Prüfen Sie bei jeder wichtigen Änderung die betroffenen Übergaben erneut. Eine zusätzliche Pflichtangabe kann die Eingangskontrolle verändern. Eine neue Freigaberolle kann Wartezustände und Vertretung betreffen. Ein anderes Veröffentlichungssystem kann den Nachweis des erfolgreichen Abschlusses verändern. Diese Auswirkungen sind konkreter als die pauschale Aussage, der Prozess sei „weiterhin gleich“.
Halten Sie außerdem fest, wie bereits laufende Vorgänge behandelt werden. Eine neue Regel darf nicht stillschweigend einen alten Prüfnachweis auf eine andere Fassung übertragen. Für eine kleine Redaktion kann eine bewusste Einzelfallklärung ausreichen. Für viele gleichzeitige Vorgänge wird eine systematischere Übergangsregel nötig. In beiden Fällen beginnt die Lösung mit einer ausdrücklich beschriebenen Entscheidung. Eine Automatisierung muss wissen, welcher Regelstand für den jeweiligen Vorgang gilt und was bei einem nicht auflösbaren Widerspruch geschehen soll.
Auch den Fall ohne notwendige Änderung beschreiben
Eine eingegangene Meldung muss nicht immer eine neue Veröffentlichung auslösen. Vielleicht enthält die vorhandene Produktseite bereits genau die freigegebene Information. Dann ist zunächst zu prüfen, ob Quelle, Produktzuordnung und Inhalt tatsächlich übereinstimmen. Ein bloß ähnlicher Wortlaut genügt dafür nicht. Ist die fachliche Aufgabe bereits erfüllt, kann der Vorgang mit einem passenden dokumentierten Ergebnis beendet werden.
Dieser Weg unterscheidet sich von einer Ablehnung und von einem technischen Fehler. Er verhindert unnötige Änderungen und macht nachvollziehbar, warum keine neue Fassung entstanden ist. Beschreiben Sie, wer diese Feststellung treffen darf und welcher Bezug zum vorhandenen Inhalt festgehalten wird. Ein System sollte nicht allein deshalb etwas umschreiben, weil ein neuer Vorgang angelegt wurde. Die Prozesslogik folgt dem fachlichen Ergebnis und nicht der Erwartung, bei jedem Durchlauf eine sichtbare Änderung erzeugen zu müssen.
Checkliste vor der technischen Umsetzung
- Zweck und fachliches Ergebnis sind konkret beschrieben.
- Auslöser und mögliche Abschlüsse sind beobachtbar.
- Der heutige Ablauf ist vom gewünschten Soll getrennt.
- Rollen, Befugnisse und Zugänge passen zusammen.
- Jede Übergabe nennt notwendige Eingaben und den nächsten Verantwortlichen.
- Quellen und freigegebene Fassungen sind eindeutig zugeordnet.
- Entscheidungen besitzen auch negative und ungeklärte Wege.
- Wichtige Ausnahmen wurden an konkreten Fällen durchgespielt.
- Wiederholung und doppelte Bearbeitung sind berücksichtigt.
- Messung, Betrieb und Rückweg gehören zum Umsetzungsplan.
Häufige Fragen zur Prozessaufnahme
Muss jeder Prozess zuerst vollständig in BPMN modelliert werden? Die notwendige Tiefe folgt der Aufgabe und der geplanten Ausführung. Eine verständliche Schrittfolge kann für die erste Abstimmung genügen. Ein ausführbares Modell benötigt zusätzliche präzise Regeln und Prüfung.
Kann die Beschreibung schon einen Nutzen bringen? Sie kann fehlende Informationen, unnötige Übergaben und unklare Zuständigkeiten sichtbar machen. Ob daraus eine tatsächliche Verbesserung entsteht, wird durch die folgende Umsetzung und passende Beobachtung beurteilt.
Wann ist genug beschrieben? Wenn die Beteiligten normale und wesentliche abweichende Fälle nachvollziehbar bearbeiten können und die offene Umsetzungsfrage klar benannt ist. Der nächste Schritt sollte eine konkrete Unsicherheit verringern, statt nur ein größeres Diagramm zu erzeugen.
