Geeignete Prozesse für Automatisierung identifizieren
Vom konkreten Problem zum begrenzten Pilotversuch: So beurteilen Sie, welche Aufgaben technisch und organisatorisch gut vorbereitet sind.
Viele Automatisierungsideen beginnen mit einem verständlichen Wunsch: weniger Kopieren, weniger Rückfragen und weniger Wartezeit. Daraus entsteht jedoch noch kein geeigneter Prozess. Wenn unklar bleibt, wann eine Aufgabe beginnt, welche Informationen fehlen oder wer im Ausnahmefall entscheidet, wird die technische Umsetzung diese Unklarheit mit übernehmen.
Dieser Leitfaden zeigt eine strukturierte Auswahlmethode für kleine und mittlere Unternehmen. Als Beispiel dient ein fiktiver Technikservice, der eingehende Wartungsanfragen vorbereitet. Alle beschriebenen Fälle, Bewertungstabellen und Regeln sind redaktionelle Beispiele. Sie enthalten keine erfundenen Einsparungsnachweise und keine Empfehlung für ein bestimmtes kostenpflichtiges Werkzeug.
1. Ein Problem formulieren, bevor ein Werkzeug gewählt wird
„Wir möchten einen KI-Agenten“ beschreibt eine denkbare Lösung. Die eigentliche Aufgabe könnte lauten: „Unser Team muss bei vielen Anfragen erst nach Standort und Anlagenart fragen, bevor es die Zuständigkeit klären kann.“ Mit dieser Formulierung werden auch einfache Lösungen sichtbar, etwa ein besseres Formular oder eine verständliche Anfrageseite.
Der GOV.UK-Leitfaden zur Erkundungsphase stellt das Verständnis des Problems vor die Entwicklung einer Lösung. Für die Auswahl im Unternehmen ist dieser Grundgedanke hilfreich. Die dort beschriebenen britischen Verwaltungsabläufe sind jedoch keine verbindliche Projektvorgabe für deutsche Betriebe.
Schreiben Sie deshalb zunächst auf, wer eine Aufgabe erledigen möchte, welche Hürde entsteht und woran eine Verbesserung erkennbar wäre. „Die Anfrage soll schneller bearbeitet werden“ bleibt zu allgemein. „Der zuständige Bereich erhält Standort und Anlagenart ohne zusätzliche Rückfrage“ lässt sich dagegen prüfen.
Eine gute Problemformulierung hält außerdem fest, was erhalten bleiben muss. Im Technikservice soll die fachliche Einschätzung einer ungewöhnlichen Anlage weiterhin durch eine qualifizierte Person erfolgen. Die Vorbereitung kann unterstützt werden, ohne diese Entscheidung ungeprüft zu automatisieren.
Prüfen Sie bei der Auswahl auch die Folgen einer fälschlichen Zuordnung. Im Technikservice kann ein unpassender interner Vorschlag möglicherweise noch vor der Terminplanung korrigiert werden. Eine automatisch versandte verbindliche Zusage hätte eine andere Wirkung. Beide Vorgänge dürfen deshalb trotz ähnlicher Eingangsdaten nicht als derselbe Automatisierungskandidat bewertet werden.
Halten Sie fest, an welcher Stelle ein Fehler noch erkannt und behoben werden kann. Dazu gehört eine tatsächlich zuständige Person mit Zugriff auf den ursprünglichen Vorgang. Ein allgemeiner Hinweis auf menschliche Kontrolle genügt nicht, wenn niemand den Vorschlag rechtzeitig prüft oder die betroffene Information wiederfindet.
Diese Betrachtung kann den ersten Umfang verändern. Statt die gesamte Anfragebearbeitung zu automatisieren, wird zunächst nur eine interne Zusammenstellung vorgeschlagen. Die technische Lösung darf dabei keinen stärkeren fachlichen Abschluss anzeigen, als tatsächlich erreicht wurde. Ein vorbereiteter Datensatz ist noch keine angenommene Wartungsanfrage und keine bestätigte Beauftragung.
2. Einen Prozess als Anfang, Schritte und Ergebnis beschreiben
Ein Prozess braucht eine Grenze. Für den Technikservice beginnt die betrachtete Aufgabe mit einer eingegangenen Anfrage und endet mit einer vollständigen internen Übergabe. Die spätere Terminvereinbarung und die eigentliche Wartung gehören zunächst nicht dazu. Eine solche Eingrenzung macht einen ersten Versuch überschaubar.
Erfassen Sie den tatsächlichen Ablauf, einschließlich Rückfragen und Wartezuständen. Die schönste Sollbeschreibung hilft wenig, wenn die Arbeit regelmäßig anders durchgeführt wird. Fragen Sie deshalb die Personen, die die Aufgabe täglich bearbeiten. Sie kennen häufig die Ausnahmen, die in einer formalen Darstellung fehlen.
Für größere Zusammenhänge kann eine gemeinsame Notation nützlich sein. Die BPMN-Spezifikation der Object Management Group bietet dafür ein standardisiertes Modell. Für eine erste Bestandsaufnahme reicht oft eine verständliche Tabelle, solange Auslöser, Zuständigkeiten und Entscheidungen eindeutig bleiben.
Anfrage eingegangen
→ Pflichtinformationen prüfen
→ Angaben zum vorhandenen Anliegen zuordnen
→ Unklare oder widersprüchliche Fälle markieren
→ Zuständigen Bereich vorschlagen
→ Interne Übergabe prüfen
→ Übergabe freigeben oder manuell bearbeitenDie Pfeilfolge ist ein vereinfachtes redaktionelles Ablaufmodell und keine vollständige BPMN-Zeichnung. Sie beschreibt auch keine bereits laufende Anwendung. Ihr Nutzen liegt darin, die Grenze zwischen automatischer Vorbereitung und fachlicher Entscheidung sichtbar zu machen.
3. Wiederholung und Stabilität getrennt prüfen
Eine Aufgabe kann häufig vorkommen und dennoch bei jedem Durchlauf andere Entscheidungen verlangen. Wiederholung macht sie interessant, aber noch nicht technisch gut beherrschbar. Untersuchen Sie deshalb zusätzlich, ob Eingaben und Regeln ausreichend stabil sind.
Der Technikservice erhält möglicherweise viele Wartungsanfragen mit demselben Informationsbedarf. Die Zuordnung eines Postleitzahlgebiets zu einem internen Team lässt sich bei gepflegten Daten klar beschreiben. Die Beurteilung eines unklaren Schadensbildes aus einem kurzen Freitext kann dagegen erheblich mehr fachlichen Kontext verlangen.
Stabilität bedeutet nicht, dass sich nie etwas ändert. Die Änderungen sollten jedoch nachvollziehbar geregelt sein. Wer aktualisiert die Gebietstabelle? Ab wann gilt eine neue Zuständigkeit? Was geschieht mit Anfragen, die bereits in Bearbeitung sind? Diese Fragen gehören zur Auswahl und nicht erst zur späteren Fehlerbehebung.
Eine Aufgabe mit seltenen, aber folgenreichen Sonderfällen braucht besondere Aufmerksamkeit. Wenn diese Fälle zuverlässig erkannt und übergeben werden können, ist eine begrenzte Automatisierung möglicherweise sinnvoll. Können sie unbemerkt in den Standardweg geraten, muss die Lösung enger gefasst werden.
4. Die Eingaben auf ihre tatsächliche Qualität untersuchen
Automatisierung verarbeitet die verfügbaren Daten. Fehlen Informationen, entsteht daraus kein vollständiger Datensatz. Bei einer Wartungsanfrage ohne Standort muss der Prozess den fehlenden Wert erkennen. Eine plausible Vermutung aus der E-Mail-Domain wäre keine verlässliche Ersatzinformation.
Prüfen Sie deshalb Formate, Pflichtangaben und eindeutige Kennungen. Werden Kunden oder Anlagen durch eine feste ID identifiziert? Können unterschiedliche Schreibweisen zugeordnet werden? Sind Zeitangaben und Maßeinheiten eindeutig? Oft verbessert eine kleine Bereinigung der Eingabe den gesamten Ablauf stärker als zusätzliche technische Komplexität.
| Eingabefrage | Problem im Beispiel | Vorbereitung |
|---|---|---|
| Ist der Datensatz identifizierbar? | Ähnliche Anlagenbezeichnungen | Vorhandene Anlagenkennung verwenden |
| Sind Pflichtangaben vorhanden? | Standort fehlt | Fehlenden Wert gezielt kennzeichnen |
| Ist die Quelle maßgeblich? | Veraltete Zuständigkeitsliste | Gültige Fassung und Eigentümer benennen |
| Sind Formate einheitlich? | Mehrdeutige Datumsangabe | Eindeutiges Austauschformat festlegen |
Die Datenprüfung sollte reale Vielfalt abbilden. Verwenden Sie für die technische Entwicklung geeignete synthetische oder ausdrücklich freigegebene Beispiele. Die Sammlung darf nicht ungeprüft vertrauliche Inhalte in zusätzliche Dienste übertragen. Zugriffsrechte und Verarbeitungszweck werden vorab geklärt.
5. Regeln, KI-Unterstützung und menschliche Entscheidung zuordnen
Eine einfache feste Regel kann oft direkt programmiert werden. Enthält eine freigegebene Gebietstabelle eine eindeutige Zuständigkeit, braucht die Zuordnung keinen generierten Text. Eine KI kann dagegen beim Strukturieren unterschiedlich formulierter Anliegen unterstützen, sofern ihre Ergebnisse sinnvoll geprüft werden können.
Die Abgrenzung folgt der Aufgabe. „Hier ist ein Freitext“ bedeutet nicht automatisch, dass jede Verarbeitung ein großes Sprachmodell benötigt. Auch feste Formulare, Wörterlisten oder vorhandene Schnittstellen können geeignet sein. Umgekehrt können rein starre Regeln bei vielfältigen Formulierungen schnell schwer wartbar werden.
| Teilaufgabe | Möglicher Ansatz | Wichtige Prüfung |
|---|---|---|
| Pflichtfeld vorhanden? | Deterministische Validierung | Klare Definition des Pflichtfelds |
| Gebiet zuordnen | Abfrage einer freigegebenen Tabelle | Gültigkeit der Zuständigkeiten |
| Freitext zusammenfassen | KI-gestützter Entwurf | Vollständigkeit und sachliche Treue |
| Ungewöhnlichen Defekt beurteilen | Fachliche Entscheidung | Qualifikation und ausreichende Informationen |
Diese Aufteilung verhindert, dass eine einzige Komponente für alles zuständig werden soll. Ein unterstützender Entwurf kann in einen verlässlichen Gesamtprozess eingebettet werden. Entscheidend ist, dass der Übergang zwischen den Komponenten klar definiert ist.
6. Fehlerfolgen vor dem Nutzen bewerten
Ein falsch sortierter interner Entwurf hat andere Folgen als eine unzutreffende verbindliche Zusage an einen Kunden. Die Auswahl muss diese Unterschiede berücksichtigen. Fragen Sie für jeden Schritt, wer einen Fehler bemerkt und ob die Folge noch rechtzeitig korrigiert werden kann.
Im Technikservice kann eine vorgeschlagene Zuständigkeit vor der Übergabe sichtbar bestätigt werden. Ein automatischer Versand eines verbindlichen Wartungstermins würde zusätzliche Anforderungen erzeugen: tatsächliche Verfügbarkeit, zuständige Person und korrekte Kundendaten müssten zuverlässig zusammenpassen.
Dokumentieren Sie außerdem den Rückweg. Kann ein falsch bearbeiteter Vorgang zurückgenommen werden? Ist er eindeutig identifizierbar? Bleibt er bei einem Abbruch in einer verständlichen Bearbeitungswarteschlange? Ohne diese Eigenschaften wird ein schneller Ablauf im Fehlerfall womöglich schwerer beherrschbar als die bisherige Arbeit.
Ein sinnvoller Startkandidat besitzt einen kleinen, überprüfbaren Wirkungsbereich. Er kann den nächsten Schritt vorbereiten, bevor er selbst eine folgenschwere Aktion ausführt. Das ist eine praktische Auswahlentscheidung und kein allgemeines Verbot automatischer Ausführung.
7. Ausnahmen als Bestandteil der Aufgabe behandeln
Ausnahmen sind nicht nur Störungen eines idealen Prozesses. Sie gehören zum tatsächlichen Arbeitsgebiet. Eine Anfrage kann mehrere Anlagen betreffen, widersprüchliche Standortangaben enthalten oder an die falsche Organisation gerichtet sein. Solche Fälle sollten im Auswahlgespräch ausdrücklich vorkommen.
Für jede erkennbare Ausnahme werden ein Signal und eine Reaktion festgelegt. „Standort fehlt“ kann eine gezielte Rückfrage vorbereiten. „Mehrere widersprüchliche Kennungen“ sollte möglicherweise eine interne Klärung auslösen. Die Reaktion hängt davon ab, ob die fehlende Information vom Kunden oder aus internen Unterlagen beschafft werden muss.
Ein Prozess braucht außerdem einen Zustand für unbekannte Situationen. Wenn die Verarbeitung keinen passenden Fall findet, darf das Ergebnis nicht stillschweigend als Standardfall weiterlaufen. Eine ausdrücklich markierte manuelle Prüfung ist oft die bessere Übergabe.
Die Bearbeitung muss organisatorisch abgesichert sein. Wer liest die Ausnahmeliste? Wie werden doppelt eingegangene Anfragen erkannt? Was geschieht während einer Abwesenheit? Eine technische Markierung ohne zuständige Bearbeitung löst die Aufgabe noch nicht.
8. Kandidaten mit nachvollziehbaren Kriterien vergleichen
Die folgende Matrix ist eine redaktionelle Entscheidungshilfe. Sie ist kein zertifiziertes Reifegradmodell und keine statistisch validierte Skala. Für jedes Kriterium werden konkrete Beobachtungen dokumentiert. Eine hübsche Gesamtnote soll kritische Lücken nicht verdecken.
| Kriterium | Gut vorbereitet | Noch zu klären |
|---|---|---|
| Prozessgrenze | Auslöser und Ergebnis benannt | Aufgabe wächst bei jeder Besprechung |
| Daten | Verfügbar und prüfbar | Quellen und Kennungen uneindeutig |
| Regeln | Fachlich beschrieben | Entscheidung nur als Bauchgefühl bekannt |
| Ausnahmen | Erkennbar und zuständig bearbeitet | Kein geregelter Rückweg |
| Betrieb | Verantwortung und Beobachtung festgelegt | Niemand pflegt die Lösung |
Vergleichen Sie zunächst wenige konkrete Kandidaten. Die Anfragevorbereitung, eine interne Dateiumbenennung und die Erstellung eines verbindlichen Angebots unterscheiden sich deutlich. Eine gemeinsame abstrakte Einschätzung „hohes Automatisierungspotenzial“ wäre für die Umsetzungsentscheidung zu wenig.
Halten Sie die wichtigsten Annahmen sichtbar. Wenn ein Kandidat nur funktioniert, falls eine bisher unzugängliche Schnittstelle verfügbar wird, ist diese Schnittstelle eine Voraussetzung und kein bereits gelöster Punkt. Der nächste sinnvolle Schritt ist dann ihre Prüfung.
9. Eine Freigaberegel maschinenlesbar ausdrücken
Klare Auswahlkriterien lassen sich teilweise als prüfbare Regel abbilden. Das folgende Python-Beispiel bewertet keine Wirtschaftlichkeit. Es prüft lediglich, ob die für einen kleinen Pilotversuch festgelegten organisatorischen Voraussetzungen bestätigt wurden. Die Kriterien sind frei gewählte Regeln des fiktiven Beispiels.
def pilot_gate(candidate):
required = (
"process_owner_confirmed",
"input_source_approved",
"success_condition_defined",
"exception_path_defined",
"test_data_approved",
)
missing = [key for key in required if candidate.get(key) is not True]
return {"ready_for_pilot": not missing, "missing": missing}
candidate = {
"process_owner_confirmed": True,
"input_source_approved": True,
"success_condition_defined": True,
"exception_path_defined": False,
"test_data_approved": True,
}
print(pilot_gate(candidate))
# Der Pilot bleibt gesperrt, weil der Ausnahmeweg noch fehlt.Die Regel ersetzt keine fachliche Bewertung. Sie macht aber einen häufigen Fehler sichtbar: Eine fehlende Voraussetzung darf nicht durch einen hohen vermeintlichen Nutzen ausgeglichen werden. In einer tatsächlichen Anwendung sollten die Bestätigungen mit verantwortlichen Personen und geeigneten Nachweisen verbunden werden.
Auch der Ausdruck „freigegeben“ braucht einen konkreten Bezug. Die Freigabe von Testdaten ist keine Freigabe für öffentliche Veröffentlichung. Die Freigabe eines Pilotversuchs erlaubt nicht automatisch einen unbegrenzten Schreibzugriff auf produktive Systeme. Halten Sie den jeweiligen Umfang eindeutig fest.
10. Erfolg vor dem Pilotversuch definieren
Der Pilot braucht ein überprüfbares Ziel. Für die Anfragevorbereitung könnte es darum gehen, ob die interne Übergabe vollständig und korrekt beim vorgesehenen Bereich ankommt. Die reine Zahl automatisch verarbeiteter Vorgänge beschreibt diese Qualität noch nicht.
Die GOV.UK-Anleitung zu Leistungskennzahlen verbindet Messung mit dem Zweck einer Dienstleistung. Übertragen auf unser Beispiel sollten Kennzahlen deshalb eine fachliche Frage beantworten: Werden Rückfragen tatsächlich reduziert und entstehen dabei neue Fehler oder zusätzliche Kontrollaufgaben?
Erfassen Sie den bisherigen Ablauf als Ausgangspunkt. Dazu gehören Bearbeitungszeit, Rückfragen, Wartezeiten und typische Fehler, soweit diese Angaben sinnvoll und zulässig erhoben werden können. Für einen fairen Vergleich müssen die Fälle vergleichbar sein. Eine ruhige Woche darf nicht ohne Einordnung mit einer außergewöhnlichen Belastungssituation verglichen werden.
Auch der zusätzliche Prüfaufwand gehört zur Bewertung. Wenn die automatische Vorbereitung regelmäßig vollständig nachgearbeitet werden muss, kann ein scheinbar schneller Zwischenschritt den Gesamtprozess verlängern. Beobachten Sie deshalb das Ergebnis der ganzen abgegrenzten Aufgabe und nicht nur eine einzelne technische Laufzeit.
11. Mit einem begrenzten Versuch beginnen
Ein erster Versuch sollte einen überschaubaren Ausschnitt bearbeiten. Der Technikservice kann beispielsweise freigegebene synthetische Anfragen strukturieren und interne Übergabeentwürfe erzeugen. Daraus ergibt sich noch kein Auftrag, echte Kunden anzuschreiben oder Termine verbindlich zu vergeben.
Testfälle sollten gewöhnliche Anfragen, fehlende Angaben und widersprüchliche Daten enthalten. Prüfen Sie jeweils, ob der erwartete Weg gewählt wurde. Ein positiver Normalfall allein zeigt nicht, ob die Ausnahmebehandlung funktioniert. Gefundene Probleme werden als konkrete Fälle dokumentiert und nach einer Änderung erneut geprüft.
Das Ergebnis des Versuchs kann eine Umsetzung, eine engere Eingrenzung oder die Entscheidung für eine einfachere Lösung sein. Wenn ein besseres Formular das Ausgangsproblem bereits löst, ist das ein brauchbares Projektergebnis. Der Erfolg besteht in der verbesserten Aufgabe und nicht in einer möglichst großen Zahl automatisierter Schritte.
Vor dem Betrieb werden Zuständigkeit, Überwachung und Rückweg festgelegt. Wer erkennt ausgefallene Vorgänge? Wer aktualisiert geänderte Regeln? Wer entscheidet über eine Erweiterung? Diese Punkte sollten zum Pilotabschluss gehören und nicht erst nach dem ersten unbehandelten Fehler auffallen.
12. Eine kurze Entscheidungsvorlage erstellen
Am Ende der Auswahl genügt häufig eine übersichtliche Entscheidungsvorlage. Sie beschreibt Problem, Prozessgrenze, erwarteten Nutzen und wesentliche Voraussetzungen. Hinzu kommen die ungeklärten Fragen und der nächste begrenzte Prüfschritt. So kann die Geschäftsführung entscheiden, ohne zuerst eine vollständige technische Architektur lesen zu müssen.
Für den fiktiven Technikservice könnte die Entscheidung lauten: „Anfragevorbereitung im Pilot prüfen. Standort und Anlagenart werden aus freigegebenen Beispielen strukturiert. Unklare Fälle gehen an die interne Bearbeitung. Keine automatische Terminbestätigung.“ Das ist konkreter als ein allgemeiner Auftrag zur Einführung von KI.
Die Vorlage sollte zwischen festgestellten Tatsachen und Erwartungen unterscheiden. „Die Gebietstabelle ist zugänglich“ kann ein geprüfter Befund sein. „Wir erwarten weniger Rückfragen“ ist zunächst eine Hypothese. Erst die beobachteten Ergebnisse erlauben eine belastbarere Bewertung.
Bei Änderungen wird die Vorlage aktualisiert. Eine neue Datenquelle oder eine zusätzliche Außenwirkung kann den ursprünglich freigegebenen Umfang verändern. Die Entscheidung bleibt dann nachvollziehbar und die technische Lösung wächst nicht unbemerkt über ihre geprüften Grenzen hinaus.
Für eine erste Aufwandsschätzung sollten mehrere Bestandteile sichtbar bleiben: Vorbereitung, Umsetzung, Prüfung, laufende Betreuung und die Bearbeitung von Ausnahmen. Auf der Nutzenseite stehen vermiedene Arbeitsschritte oder besser erledigte Aufgaben. Eine Rechnung ausschließlich mit eingesparten Minuten pro Normalfall lässt den zusätzlichen Betrieb leicht verschwinden. Verwenden Sie für die ersten Zahlen ausdrücklich gekennzeichnete Annahmen und ersetzen Sie diese nach dem Versuch durch Beobachtungen. So entsteht eine nachvollziehbare Entscheidung statt eines scheinbar präzisen Versprechens.
Checkliste zur Auswahl eines Automatisierungsprozesses
- Das Ausgangsproblem ist unabhängig von einem Werkzeug beschrieben.
- Auslöser, Eingaben und gewünschtes Ergebnis sind abgegrenzt.
- Der tatsächliche Ablauf einschließlich Ausnahmen ist bekannt.
- Maßgebliche Datenquellen sind verfügbar und zur Nutzung geeignet.
- Regeln und fachliche Entscheidungen sind unterschieden.
- Fehlerfolgen und Rückweg wurden konkret betrachtet.
- Eine zuständige Person übernimmt ungeklärte Fälle.
- Ein Erfolgskriterium und eine geeignete Ausgangsbeobachtung stehen fest.
- Der Pilot verwendet freigegebene Daten und begrenzte Rechte.
- Betrieb, Regelpflege und spätere Erweiterungen haben einen Verantwortlichen.
Häufige Fragen zur Prozessauswahl
Muss ein Prozess häufig vorkommen?
Häufigkeit kann den Nutzen erhöhen. Auch seltene Aufgaben können interessant sein, wenn sie klar beschreibbar und aufwendig sind. Die Eignung hängt zusätzlich von Daten, Regeln und Fehlerfolgen ab.
Wann wird KI gebraucht?
KI kann bei variablen sprachlichen Eingaben und Entwürfen helfen. Feste Regeln und eindeutige Datenabfragen lassen sich häufig direkter umsetzen. Die Auswahl sollte anhand der tatsächlichen Aufgabe geprüft werden.
Ist eine manuelle Freigabe immer erforderlich?
Das hängt von der Aufgabe und den Folgen ab. Ein klar geprüfter interner Formatwechsel benötigt andere Kontrollen als eine verbindliche Entscheidung gegenüber Kunden.
Quellen und weiterer Zusammenhang
Quellen geprüft am 9. November 2026: die verlinkten GOV.UK-Leitfäden zur Problemklärung und Messung sowie die OMG-Veröffentlichung zu BPMN. Die Auswahlmethode, der Technikservice und die Python-Regel sind eigene redaktionelle Beispiele. Sie bilden keinen allgemeingültigen Zertifizierungsstandard.
Weitere Praxiseinblicke bietet KI für Content und Webseitenpflege im Mittelstand. Den Rahmen für digitale Angebote erklärt Was eine professionelle Unternehmenswebseite leisten muss.
