← Blog

Vom Kandidaten zum prüfbaren Workflow: sieben Fragen vor dem Bau

4. September 2026Maurice7 min

Das Prozessinventar zeigt, welche Abläufe Automatisierungspotenzial haben. Der Pilot-Check hilft, daraus einen geeigneten ersten Kandidaten auszuwählen. Danach fehlt oft noch etwas: eine belastbare Arbeitsdefinition für genau diesen Workflow.

Ohne diese Definition diskutiert das Team zu früh über Plattformen, Modelle und Anbieter. Ein wiederkehrender Ablauf allein ist noch kein baubarer Workflow. Auslöser, Output, Eingaben, Ausnahmen und Verantwortung müssen so konkret sein, dass sich ein vollständiger Testdurchlauf beschreiben lässt.

Die folgenden sieben Fragen machen aus einem Kandidaten einen begrenzten Prüfauftrag. Am Ende steht keine Business-Case-Prognose und keine Punktzahl, sondern eine von drei Entscheidungen: bereit für einen begrenzten Test, zuerst klären oder vorerst nicht bauen.

1. Was löst den Workflow aus?

Ein Workflow beginnt mit einem beobachtbaren Ereignis. Beispiele sind ein neuer Datensatz, ein festes Monatsdatum, eine eingegangene Anfrage oder eine definierte Abweichung.

«Wenn jemand merkt, dass etwas gemacht werden muss» ist kein stabiler Auslöser. Das Team sollte erklären können:

  • welches Ereignis den Ablauf startet;
  • wie häufig es eintritt;
  • wo es erfasst wird;
  • was nicht zu diesem Workflow gehört.

Ohne diese Grenze wird aus einem kleinen Vorhaben schnell eine Sammlung ähnlicher, aber unterschiedlich behandelter Fälle.

2. Welches konkrete Ergebnis soll entstehen?

«Zeit sparen» beschreibt keinen Output. Benennen Sie das Arbeitsergebnis, das am Ende vorliegen soll: eine Prüfliste, ein vorbereiteter Bericht, ein kategorisierter Vorgang oder ein Entwurf zur Freigabe.

Ein brauchbares Ergebnis lässt sich anschauen und beurteilen. Fragen Sie:

  • Wer verwendet es?
  • Welche Entscheidung unterstützt es?
  • Woran erkennt diese Person, ob es vollständig und brauchbar ist?

Für einen ersten Schritt bleibt Vorbereitung statt Entscheidung die robusteste Grenze. Der Workflow kann Fälle sammeln, Veränderungen markieren und einen Entwurf erzeugen. Eine benannte Person prüft das Ergebnis und entscheidet, was danach geschieht.

3. Liegen die nötigen Eingaben verlässlich vor?

Viele Automatisierungsideen scheitern nicht am Modell, sondern an den Eingaben. Eine Zahl steht im ERP, eine Ausnahme in einer E-Mail und die aktuelle Regel nur im Kopf einer erfahrenen Mitarbeiterin.

Notieren Sie für jede Eingabe:

  • Quelle und verantwortliche Person;
  • Format und Aktualisierungsrhythmus;
  • häufige Lücken oder Widersprüche;
  • erlaubte Verwendung und Zugriffsrechte.

Wenn das Team bei jedem Durchlauf zuerst mehrere Systeme durchsuchen und Bedeutungen aushandeln muss, ist die Datenarbeit noch Teil des Problems. Das kann lösbar sein, gehört aber in den Umfang und die Messung.

4. Welche Regeln sind stabil — und wo braucht es Urteil?

Nicht jeder Arbeitsschritt muss regelbasiert sein. Entscheidend ist, dass die Grenze sichtbar wird.

Teilen Sie den Ablauf in drei Gruppen:

  1. klar regelbar: feste Prüfungen, Berechnungen oder Zuordnungen;
  2. vorbereitbar: Zusammenfassungen, Vergleiche oder Vorschläge, die kontrolliert werden;
  3. menschliche Entscheidung: Abwägungen mit kommerziellen, rechtlichen oder persönlichen Folgen.

Wenn zwei Fachpersonen denselben normalen Fall unterschiedlich behandeln und beide Antworten vertretbar sind, braucht der Workflow entweder klarere Leitplanken oder eine bewusste menschliche Entscheidung. Ein Modell verdeckt diese Uneinigkeit, löst sie aber nicht.

5. Welche Ausnahmen treten tatsächlich auf?

Der Normalfall wirkt in einer Demo sauber. Im Betrieb zählen fehlende Angaben, verspätete Daten, Sondervereinbarungen und widersprüchliche Quellen.

Prüfen Sie als pragmatischen Startpunkt zehn bis zwanzig Fälle aus mehreren vollständigen Durchläufen; die Zahl ist kein Nachweis vollständiger oder statistisch repräsentativer Abdeckung. Verwenden Sie reale Fälle nur, wenn dies für diesen Zweck freigegeben ist und die geltenden Datenschutz- und internen Vorgaben eingehalten werden; arbeiten Sie andernfalls mit synthetischen Fällen. Markieren Sie:

  • wiederkehrende Ausnahmearten;
  • Fälle, die eskaliert werden müssen;
  • Fälle, die ausdrücklich ausserhalb des Workflows bleiben;
  • die Person, die jede Ausnahme übernimmt.

Gehen die meisten Fälle einen anderen Weg, ist nicht die Automatisierung zu klein. Dann ist der angebliche Standardablauf noch nicht stabil genug.

6. Wer trägt Verantwortung für Ergebnis und Änderungen?

Ein Workflow braucht mehr als eine Projektleitung. Eine Person muss im späteren Betrieb verantwortlich sein für:

  • die fachliche Qualität;
  • Freigaben und Eskalationen;
  • Änderungen an Regeln und Quellen;
  • den Umgang mit Fehlern;
  • die Entscheidung, ob der Ablauf pausiert wird.

«Das Operations-Team» ist dafür zu ungenau. Akzeptiert niemand diese Rolle, ist der Workflow noch nicht betriebsbereit.

7. Wie prüfen, messen und stoppen wir?

Definieren Sie vor dem Bau, was bei jedem Testdurchlauf protokolliert wird: Fall oder Referenz, erzeugtes Ergebnis und Korrekturen, Zeit für Prüfung und Ausnahmebehandlung sowie verantwortliche Person und Fachentscheid.

Formulieren Sie daraus überprüfbare Bedingungen mit offenen Feldern:

  • Von __ Testfällen müssen mindestens __ vollständig verarbeitet werden.
  • Jede verwendete Information muss auf ihre freigegebene Quelle zurückgeführt werden können.
  • Ohne menschliche Freigabe darf keine externe oder schwer umkehrbare Aktion erfolgen.
  • Prüfung und Ausnahmebehandlung dürfen zusammen höchstens __ Minuten pro Fall beanspruchen.

Halten Sie daneben die Ausgangslage fest: heutige Bearbeitungs- und Wartezeiten, Fallzahl, häufigste Korrekturen und Anteil der Fälle mit Fachentscheid. Pausieren Sie den Test, sobald Daten nicht wie vereinbart verwendet werden, Ergebnisse vor ihrer Wirkung nicht geprüft werden können oder niemand eine Ausnahme übernimmt.

Drei Grenzen, die weiterhin gelten

Die drei Ausschlusskriterien aus der Pilotwahl gelten auch hier. Sie lassen sich nicht mit einer guten Antwort an anderer Stelle verrechnen:

  1. Niemand verantwortet Qualität, Freigaben und Änderungen.
  2. Zweck, Zugriff, Verarbeitung oder Aufbewahrung der Daten sind ungeklärt.
  3. Ein fehlerhaftes Ergebnis würde sofort eine schwer umkehrbare Aktion auslösen.

Trifft einer dieser Punkte zu, geht der Kandidat zurück in die Klärung. Er wird noch nicht gebaut.

Beispiel: Eine monatliche Lieferantenprüfung

Nehmen wir ein Schweizer KMU, das monatlich Konditionen und Lieferleistung seiner wichtigsten Lieferanten prüft. Das Beispiel ist illustrativ; es beschreibt keinen Kundenfall.

Der heutige Ablauf könnte so aussehen: Eine Mitarbeiterin exportiert Bestelldaten, ergänzt Liefertermine aus E-Mails, vergleicht Konditionen und erstellt eine Liste für die Einkaufsleitung.

Die sieben Fragen zeigen zwei unterschiedliche Vorhaben:

  • Zu breit: Das System bewertet Lieferanten und ändert Bestellmengen selbständig.
  • Begrenzt prüfbar: Das System führt freigegebene Eingaben zusammen, markiert fehlende oder veränderte Werte und erstellt eine Prüfliste. Die Einkaufsleitung bewertet die Abweichungen und entscheidet.

Die zweite Variante hat einen definierten Auslöser, einen sichtbaren Output und eine menschliche Freigabe. Datenqualität und Ausnahmen können in einem kontrollierten Test geprüft werden. Zweck, Zugriffsrechte, Verarbeitung und Aufbewahrung müssen vor der Nutzung realer Daten geklärt sein.

Ein Erstdurchgang auf einer Seite

Bearbeiten Sie das Blatt mit der fachlich verantwortlichen Person und mindestens einer Person, die den Ablauf tatsächlich ausführt. Nehmen Sie einen echten Fall als Grundlage, sofern seine Nutzung freigegeben ist; verwenden Sie sonst einen synthetischen Fall. Schreiben Sie zu jedem Feld einen Satz und markieren Sie jede unbelegte Annahme als «offen»:

FrageIhre Antwort
AuslöserWas startet den Ablauf, wie oft und in welchem System?
ErgebnisWelcher prüfbare Output soll entstehen, und wer nutzt ihn?
EingabenWelche Quellen werden benötigt, und wer verantwortet sie?
Regeln und UrteilWas ist fest regelbar, was wird vorbereitet, was entscheidet ein Mensch?
AusnahmenWelche Fälle weichen ab, wer übernimmt sie, was bleibt ausserhalb?
VerantwortungWer verantwortet Qualität, Freigaben und Änderungen, und wer kann den Ablauf pausieren?
Messung und StoppWelche Ausgangslage, Korrekturen und Stoppsignale werden erfasst?

Addieren Sie keine Punktzahl. Wählen Sie stattdessen eine von drei Aussagen:

  • Bereit für eine begrenzte Prüfung: Alle sieben Antworten sind konkret; kein Ausschlusskriterium greift.
  • Zuerst klären: Der Workflow ist relevant, aber einzelne Eingaben, Regeln, Ausnahmen oder Messpunkte sind offen.
  • Vorerst nicht automatisieren: Eine verantwortliche Person, kontrollierbare Datennutzung oder eine prüfbare beziehungsweise umkehrbare Wirkung fehlt.

Der nächste Schritt ist ein einseitiger Testauftrag

Wenn der Workflow die Prüfung besteht, wählen Sie noch keine Plattform. Übertragen Sie die Antworten zuerst in einen einseitigen Testauftrag: Auslöser, zugelassene Eingaben, erwarteter Output, menschliche Freigabe, Ausnahmeweg, Messbedingungen und Stoppsignale.

Damit kann das Team entscheiden, ob es diesen einen Workflow kontrolliert betreiben kann. Erst danach stellt sich die Infrastrukturfrage.

Wenn Ihr Kandidat grundsätzlich bereit ist, bringen Sie ihn in ein kurzes Arbeitsgespräch. Gemeinsam schneiden wir daraus einen ersten betreibbaren Workflow mit klaren Eingaben, Prüfausgabe, menschlicher Freigabe und Stoppsignalen. Erst danach wählen wir die passende Infrastruktur.

Vom Kandidaten zum prüfbaren Workflow: sieben Fragen vor dem Bau — opsautomation.ch