Digitalisierung vor dem Toolkauf: Welcher Prozess überhaupt automatisiert werden sollte

Ein Fachbereich möchte einen Freigabeprozess digitalisieren. Die Anforderungen klingen zunächst eindeutig: ein Formular, drei Genehmigungsstufen, automatische Erinnerungen und eine Ablage. Mehrere Anbieter können das technisch abbilden. Trotzdem ist noch nicht klar, warum die zweite und dritte Freigabe existieren, nach welchen Kriterien sie entscheiden oder weshalb dieselben Angaben an zwei Stellen erneut erfasst werden.

Wer jetzt ein Werkzeug auswählt, trifft unbemerkt Prozessentscheidungen in der Konfiguration. Historische Übergaben werden zu Pflichtfeldern, ungeklärte Zuständigkeiten zu Berechtigungsgruppen und Ausnahmen zu Sonderworkflows. Das Ergebnis ist digital – aber weder einfacher noch besser steuerbar.

Die Alternative ist kein monatelanges Modellierungsprojekt. Vor dem Toolkauf müssen nicht alle Details eines Prozesses endgültig feststehen. Es müssen jedoch die Entscheidungen geklärt sein, von denen Anforderungen, Verantwortung und erwartete Wirkung abhängen.

Meine Leitfrage dafür lautet: Ist der Prozess klar genug, damit die Technik eine bewusste Arbeitsweise unterstützt – oder soll das Tool erst entscheiden, wie die Organisation künftig arbeitet?

Digitalisierung beginnt mit dem gewünschten Ergebnis

Ein Prozess ist mehr als eine Folge von Arbeitsschritten. Die ISO-Erläuterung zum Prozessansatz beschreibt Prozesse über zusammenwirkende Tätigkeiten, die Eingaben in ein beabsichtigtes Ergebnis überführen. Sie bezieht außerdem Wechselwirkungen, Verantwortung, Risiken und Messung ein.

Für ein Digitalisierungsprojekt ist vor allem das beabsichtigte Ergebnis entscheidend. Ohne dieses Ziel lässt sich zwar ein bestehender Ablauf nachbauen, aber nicht beurteilen, welche Schritte notwendig sind.

Beim Onboarding eines Mitarbeiters könnte das Ergebnis beispielsweise lauten:

Die neue Person besitzt am ersten Arbeitstag die für ihre bestätigte Rolle notwendigen Arbeitsmittel, Zugänge und Informationen.

Diese Formulierung ist hilfreicher als „Onboarding-Formular digitalisieren“. Sie macht sichtbar, dass ein abgeschicktes Formular noch kein abgeschlossenes Onboarding ist. Hardwarebereitstellung, Rollendefinition, Berechtigungsentscheidung, technische Umsetzung und Rückmeldung gehören zu einem gemeinsamen Ergebnis, auch wenn mehrere Abteilungen beteiligt sind.

Der GOV.UK Service Standard formuliert für digitale Verwaltungsservices denselben Grundgedanken: Der Service soll ein vollständiges Problem für Nutzer lösen und nicht um eine vorgewählte Technologie oder interne Organisationsgrenze herum gestaltet werden. Der Kontext öffentlicher Services ist nicht mit jedem Unternehmensprozess identisch. Die End-to-End-Perspektive ist dennoch übertragbar.

Den tatsächlichen Ablauf aufnehmen – nicht den vorgesehenen

Prozessbeschreibungen zeigen häufig, wie die Arbeit laut Richtlinie stattfinden soll. Die spätere Automatisierung trifft jedoch auf die tatsächliche Praxis:

• Mitarbeitende ergänzen fehlende Angaben telefonisch.
• Eine Freigabe wird formal eingeholt, obwohl sie faktisch nie ablehnt.
• Daten werden aus einer Tabelle in eine andere übertragen.
• Ein Sonderfall wird zum Normalweg, weil der vorgesehene Ablauf zu langsam ist.
• Eine Person hält mehrere Übergaben durch Erfahrungswissen zusammen.

Diese Abweichungen sind kein Grund, Beteiligte als undiszipliniert zu behandeln. Sie sind Informationen über das wirkliche System. Manche Umgehungslösung ist unnötig, eine andere kompensiert eine reale Lücke.

Das Prozessmapping des DigitalService des Bundes beginnt deshalb mit Problem und Kontext, visualisiert Schritte und Abhängigkeiten und ergänzt die Perspektive der tatsächlich Beteiligten. Die notwendige Detailtiefe richtet sich nach dem zu lösenden Problem.

Für den Einstieg genügt oft eine einfache Darstellung:

Element	Leitfrage
Auslöser	Welches Ereignis startet den Prozess tatsächlich?
Eingaben	Welche Informationen und Nachweise werden benötigt?
Tätigkeiten	Was geschieht in welcher Reihenfolge?
Entscheidungen	Wer entscheidet nach welchen Kriterien?
Übergaben	Wo wechseln Person, Abteilung, Medium oder System?
Ausnahmen	Welche Fälle verlassen den Standardweg und warum?
Ergebnis	Woran erkennt der Empfänger, dass der Prozess abgeschlossen ist?

Ein detailliertes BPMN-Modell ist dafür nicht zwingend erforderlich. Haftnotizen, ein Whiteboard oder eine gemeinsam gepflegte Tabelle können ausreichen, solange Ablauf, Entscheidungen und Abweichungen verständlich werden.

Das sichtbare Beispiel: Ein digitaler Urlaubsantrag

Stellen Sie sich folgenden Ablauf vor:

Ein Urlaubsantrag wird von der Führungskraft genehmigt. Danach prüft HR erneut dieselben Voraussetzungen und überträgt die Angaben anschließend manuell in ein weiteres System. Ein digitales Formular verkürzt zunächst nur die Eingabe. Erst die Klärung, welche Stelle tatsächlich entscheidet und welche Voraussetzungen automatisch aus verlässlichen Daten geprüft werden können, beseitigt die doppelten Übergaben.

Dieses Beispiel ist konstruiert. Es behauptet weder ein bestimmtes Kundenerlebnis noch eine gemessene Zeitersparnis.

Es zeigt drei unterschiedliche Arten von Arbeit:

1. Fachliche Entscheidung: Kann der Urlaub im konkreten Zeitraum genehmigt werden?
2. Regelprüfung: Sind formale Voraussetzungen erfüllt und Daten plausibel?
3. Übertragung: Müssen bereits bekannte Angaben noch einmal in ein anderes System geschrieben werden?

Wer diese Tätigkeiten nicht trennt, automatisiert möglicherweise alle drei als aufeinanderfolgende „Freigaben“. Dabei könnte die erste Entscheidung bei der Führungskraft bleiben, die zweite Prüfung datenbasiert unterstützt und die dritte Tätigkeit durch eine Schnittstelle entfallen.

Die Digitalisierung spart dann nicht deshalb Arbeit, weil Papier zu einem Formular wurde. Sie verändert, welche Tätigkeit überhaupt noch notwendig ist.

Sieben Felder entscheiden über die Automatisierungsreife

Ein Prozess benötigt vor der ersten Erkundung keine perfekte Dokumentation. Vor einer verbindlichen Toolauswahl oder Produktivkonfiguration sollten jedoch sieben Felder ausreichend klar sein.

1. Gewünschtes Ergebnis

Beschreiben Sie, welcher Zustand für den Empfänger des Prozesses erreicht werden soll. „Antrag bearbeitet“ ist meist zu intern. „Bestellte Ware ist geprüft verfügbar und korrekt verbucht“ beschreibt ein Ergebnis, das über Abteilungsgrenzen hinausreicht.

Warnsignal: Projekt und Fachbereich sprechen hauptsächlich über Formulare, Masken oder Funktionen, aber nicht über das Ergebnis.

2. Auslöser und Ende

Legen Sie fest, welches Ereignis den Prozess startet und welches überprüfbare Ereignis ihn beendet. Dazwischen darf es unterschiedliche Wege geben.

Warnsignal: Das Projekt beginnt dort, wo das künftige Tool Daten entgegennimmt, obwohl wesentliche Entscheidungen bereits davor fallen – oder es endet beim Systemstatus, obwohl der Empfänger noch auf eine Leistung wartet.

3. Prozess- und Entscheidungsverantwortung

Benennen Sie eine Rolle, die das Endergebnis und die Weiterentwicklung des Ablaufs verantwortet. Ordnen Sie außerdem die wenigen verbindlichen Entscheidungen zu. Eine technische Berechtigung ist dabei nicht automatisch ein fachliches Entscheidungsrecht.

Der Beitrag zu Verantwortung, Entscheidungsrecht und technischer Berechtigung vertieft diese Trennung.

Warnsignal: Für jeden einzelnen Schritt gibt es einen Bearbeiter, aber niemand darf widersprüchliche Anforderungen über Abteilungsgrenzen hinweg entscheiden.

4. Notwendige Daten und verlässliche Quelle

Klären Sie für jede relevante Information:

• Wofür wird sie benötigt?
• Wo entsteht sie?
• Welches System oder welche Rolle ist führend?
• Wie wird ihre Qualität geprüft?
• Darf sie für diesen Zweck verwendet werden?
• Muss der Nutzer sie wirklich erneut eingeben?

Automatisierung benötigt nicht nur Datenfelder, sondern eine Aussage darüber, welcher Quelle vertraut wird. Zwei technisch erreichbare Datenbestände können fachlich widersprüchlich sein.

Warnsignal: Das Soll-Konzept plant Synchronisation, bevor geklärt ist, welche Information im Konfliktfall gilt.

5. Standardablauf

Beschreiben Sie den häufigsten fachlich sinnvollen Weg. Der Standardablauf ist nicht automatisch der heutige Weg. Unnötige Kontrollen, doppelte Eingaben und Übergaben ohne Wertbeitrag werden vor der Automatisierung hinterfragt.

Eine Tätigkeit bleibt sinnvoll, wenn sie beispielsweise:

• eine echte Entscheidung vorbereitet oder trifft,
• ein relevantes Risiko kontrolliert,
• benötigte Information erzeugt oder prüft,
• eine gesetzliche oder vertragliche Anforderung erfüllt,
• das Ergebnis für den nächsten Empfänger nutzbar macht.

„Das haben wir immer so gemacht“ ist dagegen kein Prozesszweck.

Warnsignal: Jeder heutige Schritt wird unverändert zum Muss-Kriterium des neuen Werkzeugs.

6. Begründete Ausnahmen und Abbruchfälle

Nicht jede Abweichung ist ein Fehler. Bestimmte Fälle benötigen bewusst eine fachliche Einzelfallentscheidung. Deshalb werden mindestens die bekannten Ausnahmen, ihre Auslöser und der zuständige Entscheidungsweg benannt.

Es ist nicht erforderlich, vor dem Start jede theoretisch denkbare Ausnahme zu modellieren. Die Organisation braucht aber eine Regel dafür, was geschieht, wenn der Standardweg nicht trägt:

• Wer übernimmt den Fall?
• Welche Information muss sichtbar sein?
• Darf der Vorgang fortgesetzt werden?
• Wie fließt die Erkenntnis in die Prozessverbesserung ein?

Warnsignal: Das Konzept kennt nur „erfolgreich“ und „technischer Fehler“, obwohl fachlich unklare Fälle regelmäßig auftreten.

7. Messbare Wirkung

Definieren Sie vor der Umsetzung, woran eine Verbesserung erkannt wird. Je nach Prozess können geeignet sein:

• gesamte Durchlaufzeit,
• aktive Bearbeitungszeit,
• Wartezeit zwischen Schritten,
• Zahl der Rückfragen,
• Anteil fehlerhafter oder nachbearbeiteter Vorgänge,
• Übergaben und Medienbrüche,
• erreichte Service- oder Qualitätsziele.

Die Zahl digital bearbeiteter Vorgänge ist allein kein Wirkungsnachweis. Ein schlechter Prozess kann vollständig digital und trotzdem langsam, fehleranfällig oder teuer sein.

Warnsignal: Der Business Case misst die Einführung des Tools, nicht die Veränderung des Prozessergebnisses.

Automatisieren, unterstützen oder zuerst klären?

Der Reifecheck endet nicht mit einem Punktwert. Eine scheinbar exakte Bewertung würde unterschiedliche Risiken und fehlende Grundentscheidungen miteinander verrechnen. Sinnvoller sind drei handlungsfähige Ergebnisse.

Ergebnis	Geeignete Situation	Nächster Schritt
Automatisieren	Ergebnis, Verantwortung, Daten, Standardweg und Abnahme sind ausreichend geklärt	Anforderungen ableiten, Werkzeug bewerten und kontrolliert umsetzen
Unterstützen und erproben	Grundproblem ist verstanden, aber einzelne Annahmen oder Ausnahmen sind noch unsicher	begrenzten Prototyp bauen, riskante Annahme testen und Erkenntnisse dokumentieren
Zuerst klären	Ziel, Entscheidungsrecht, Datenhoheit oder Prozessgrenze sind strittig	fachliche Entscheidung herbeiführen, bevor Konfiguration Fakten schafft

Ein variabler Prozess ist nicht automatisch ungeeignet für Digitalisierung. Wenn Fachwissen und Einzelfallabwägung Wert erzeugen, kann Technik Informationen zusammenführen, Vorschläge erzeugen, Fristen überwachen und Entscheidungen dokumentieren. Sie muss nicht jede Entscheidung selbst treffen.

Umgekehrt ist ein stabiler Ablauf nicht automatisch ein guter Automatisierungskandidat. Ein seltener Vorgang mit geringem Aufwand kann technisch leicht automatisierbar sein, ohne dass Entwicklung, Betrieb und Pflege wirtschaftlich sinnvoll wären. Der Beitrag zu steuerbaren IT-Kosten zeigt, warum Aufwand und Leistung gemeinsam betrachtet werden müssen.

Ein früher Prototyp ist kein Widerspruch zur Prozessklärung

Die Forderung „erst Prozess, dann Tool“ kann zu weit getrieben werden. Wenn sie bedeutet, dass jeder Sonderfall vor dem ersten Versuch vollständig modelliert werden muss, blockiert sie Lernen und erzeugt Scheingenauigkeit.

Der GOV.UK-Leitfaden zur Alpha-Phase empfiehlt Prototypen gerade dazu, unterschiedliche Lösungen und die riskantesten Annahmen früh zu testen. Ein Prototyp kann beispielsweise klären:

• Verstehen Nutzer die benötigten Angaben?
• Kann eine Schnittstelle die erforderlichen Daten in ausreichender Qualität liefern?
• Unterstützt ein vereinfachter Freigabeweg die tatsächliche Entscheidung?
• Welche Ausnahmen treten in einer begrenzten Erprobung auf?

Entscheidend ist die Kennzeichnung. Ein Prototyp ist ein Lerninstrument, kein still eingeführter Produktivprozess. Er darf offene Fragen sichtbar machen. Er darf sie nicht durch dauerhaft gewordene Workarounds verdecken.

Vor einer Produktiveinführung müssen deshalb andere Nachweise vorliegen als vor einem Experiment:

Prototyp	Produktiver Prozess
prüft eine klar benannte Annahme	erbringt ein verbindliches Ergebnis
darf bewusst unvollständig sein	benötigt geregelte Ausnahmen und Betrieb
arbeitet mit begrenztem Umfang und geeigneten Testdaten	benötigt geklärte Daten-, Schutz- und Berechtigungskonzepte
kann manuell begleitet werden	braucht verantwortete Unterstützung und Eskalation
endet mit einer Lernentscheidung	endet mit fachlicher Leistung und messbarer Wirkung

Aus dem Prozess entstehen belastbare Toolanforderungen

Nach dem Reifecheck verändert sich die Toolauswahl. Statt eine lange Wunschliste zu sammeln, kann das Projekt Anforderungen aus den geklärten Prozessentscheidungen ableiten.

Beispiele:

Prozessentscheidung	Daraus abgeleitete Anforderung
Führungskraft entscheidet anhand von Rolle, Zeitraum und Vertretung	relevante Daten müssen zum Entscheidungszeitpunkt vollständig sichtbar sein
HR verantwortet die führenden Personaldaten	Stammdaten werden aus der vereinbarten Quelle übernommen statt erneut erfasst
unvollständige Anträge gehen an den Antragsteller zurück	Status, Rückgabegrund und erneute Einreichung müssen nachvollziehbar sein
Sonderfälle entscheidet eine benannte Rolle	das System benötigt einen sichtbaren Ausnahme- und Eskalationsweg
Wirkung wird an Durchlauf- und Wartezeit gemessen	Zeitpunkte und Statuswechsel müssen auswertbar sein
eine Freigabe ist ab einer definierten Grenze erforderlich	Regel und Entscheidung müssen versionierbar und prüfbar abgebildet werden

Damit wird auch ein möglicher Ausschlussgrund sichtbar: Wenn ein Werkzeug eine fachlich notwendige Entscheidung, Integration, Berechtigungsgrenze oder Nachvollziehbarkeit grundsätzlich nicht unterstützen kann, ist nicht der Prozess an das Produkt anzupassen. Dann passt das Produkt nicht zum geklärten Bedarf.

Der bereits veröffentlichte Beitrag Ein Ticketsystem löst keine organisatorischen Probleme beschreibt dasselbe Muster für IT Service Management. Die Prozessprüfung überträgt es auf Digitalisierungs- und Automatisierungsvorhaben allgemein.

Das Ein-Seiten-Briefing vor der Toolauswahl

Für einen überschaubaren Prozess sollte das Ergebnis der Vorarbeit auf eine Seite passen:

Feld	Festzuhaltende Aussage
Problem	Welche konkrete Reibung oder welches Risiko soll verändert werden?
Ergebnis	Welcher Zustand muss für den Empfänger erreicht sein?
Grenze	Wo beginnen und enden Prozess und Projektumfang?
Verantwortung	Wer verantwortet Ergebnis, Entscheidungen und Betrieb?
Daten	Welche Informationen werden benötigt und welche Quelle ist führend?
Standardweg	Welche Tätigkeiten und Entscheidungen bleiben notwendig?
Ausnahmen	Welche bekannten Fälle benötigen einen anderen Weg?
Wirkung	Welche Ausgangsgröße und welches Ziel werden verglichen?
Ausschlusskriterien	Was muss ein Werkzeug zwingend leisten oder vermeiden?
Lernfragen	Welche Unsicherheiten werden vorab prototypisch geprüft?

Dieses Briefing ersetzt weder Datenschutzprüfung noch technische Architektur, Sicherheitskonzept oder Einführungsvorbereitung. Es sorgt dafür, dass diese Arbeiten ein gemeinsames fachliches Ziel besitzen.

Der erste sinnvolle Schritt

Nehmen Sie einen Prozess, für den bereits ein neues Werkzeug diskutiert wird. Schreiben Sie zunächst nicht die gewünschten Funktionen auf, sondern drei andere Sätze:

1. Der Prozess ist erfolgreich, wenn …
2. Verbindlich entscheiden darf …
3. Wir erkennen die Verbesserung an …

Wenn diese Sätze strittig bleiben, liegt die nächste Aufgabe nicht in einer Produktdemo. Wenn sie belastbar beantwortet sind, lässt sich der tatsächliche Ablauf aufnehmen, vereinfachen und in prüfbare Anforderungen übersetzen.

Digitalisierung beginnt damit nicht später. Sie beginnt an der richtigen Stelle: bei dem Ergebnis, das Technik und Organisation gemeinsam verlässlich erzeugen sollen.