Abschlussprojekt vom Geschäftsprozess zum produktionsfähigen Workflow

Abschlussprojekt vom Prozess zum Betrieb

0:00 Wir sind am Ende angekommen, und das Abschlussprojekt bringt alles zusammen. Ein Satz vorweg, der zugleich der Bewertungsmaßstab ist: Bewertet wird nicht, wie viele Bausteine im Bild sind. Bewertet wird, ob jemand anders den Prozess übernehmen könnte. Das ist eine hohe Messlatte, und sie ist Absicht. Ein Workflow, den nur seine Erbauerin betreiben kann, ist kein Betriebsmittel, sondern ein Risiko mit Oberfläche.

0:25 Die nächsten Stunden handeln davon, wie man aus etwas Funktionierendem etwas Übergebbares macht.

Abschlussprojekt vom Geschäftsprozess zum produktionsfähigen Workflow

0:32 Das letzte Modul. Wir gehen den Weg noch einmal in der richtigen Reihenfolge: erst die Abgrenzung und das Datenmodell, dann der Schnitt in Hauptworkflow und Bausteine, dann Robustheit und Wiederholbarkeit, dann die KI-Komponente mit ihrer Freigabe — und zum Schluss die Abnahme und die Übergabe an den Betrieb. Fünf Kapitel, die zugleich eine Checkliste sind, die Sie mitnehmen können.

Prozessabgrenzung und Datenmodell

0:53 Fangen wir am Anfang an — und zwar wirklich am Anfang. Zuerst die Grenze, dann der erste Baustein. Diese Reihenfolge ist der häufigste Unterschied zwischen einem Projekt, das trägt, und einem, das gewachsen ist. Die Prozessabgrenzung legt fest, wo der automatisierte Vorgang beginnt, wo er endet und was ausdrücklich nicht dazugehört.

1:14 Dieser dritte Teil ist der wichtigste und wird fast immer weggelassen. Die Akzeptanzkriterien beschreiben, woran sich ein gelungener Durchlauf erkennen lässt — fachlich, nicht technisch; der Begriff aus Modul neun. Der Vergleich: Das ist der Bauantrag vor dem Bauen. Er sagt, was entsteht und was nicht, und er ist die Grundlage dafür, am Ende festzustellen, ob es das geworden ist.

1:37 Vier Festlegungen. Der Auslöser und die Bedingung, unter der er gilt. Das Ergebnis, an dem der Erfolg gemessen wird. Die Fälle, die bewusst nicht automatisiert werden — das ist die Rückkehr zum Nein aus Modul eins, und es schließt sich hier ein Bogen über sechs Tage. Und: Wer entscheidet, wenn der Prozess auf einen Menschen wartet?

1:57 Diese vierte Frage klingt organisatorisch und ist technisch relevant, denn sie bestimmt, wohin die Freigabeanfrage geht und was bei Zeitüberschreitung passiert. Fünf Schritte. Benennen Sie den Vorgang und geben Sie ihm eine eindeutige Kennung. Legen Sie die Felder fest, die ihn von Anfang bis Ende begleiten. Beschreiben Sie je Fremdsystem, was hineingeht und was zurückkommt. Legen Sie fest, welches System die Wahrheit über welches Feld hält — diese Frage klärt später jeden Konflikt.

2:26 Und ziehen Sie die Korrelationskennung durch alle Schritte durch. Die Fußzeile sagt, warum: Ohne durchgängige Kennung lässt sich im Fehlerfall nicht sagen, was zusammengehört. Das ist die Erfahrung aus Modul sechs und neun, hier als Bauvorschrift. Der erste Punkt ist der Reihenfolgefehler von eben: Der Prozess wird gebaut und die Grenze danach beschrieben.

2:48 Der zweite ist ein Datenkonflikt mit Ansage: Zwei Systeme halten dieselbe Angabe, und keines ist die Wahrheit — dann gewinnt irgendwann der letzte Schreibzugriff. Der dritte macht die Abnahme unmöglich: Die Akzeptanzkriterien lauten „läuft durch". Und der vierte ist ein technischer Fehler mit Folgen für die Nachverfolgung: Die Kennung entsteht erst in der Mitte des Ablaufs — dann fehlt sie genau dort, wo die ersten Fehler passieren.

Hauptworkflow, Sub-Workflows und Credentials

3:13 Jetzt der Schnitt. Und das Ziel ist klar formuliert: ein Hauptworkflow, der nur noch koordiniert. Alles, was tatsächlich mit fremden Systemen spricht, liegt daneben. Vier Regeln, und sie fassen Modul sechs zusammen. Der Hauptworkflow nimmt an, steuert und schließt ab — mehr nicht. Jeder Fremdsystemzugriff wird zu einem eigenen Sub-Workflow; das ist der klarste Schnitt, den es gibt, und er hat einen angenehmen Nebeneffekt: Diese Bausteine sind fast immer wiederverwendbar.

3:43 Jeder Baustein hat einen beschriebenen Ein- und Ausgangsvertrag. Und was zweimal vorkommt, wird einmal gebaut und zweimal aufgerufen. Wenn Sie diese vier einhalten, ist Ihr Hauptworkflow am Ende erstaunlich klein — und das ist ein gutes Zeichen. Fünf Schritte, und es ist eine Tabelle, kein Dokument. Tragen Sie je Fremdsystem ein, welcher Zugang gebraucht wird.

4:05 Trennen Sie lesende und schreibende Zugänge — die Trennung, die bei den Agenten die Freigabe erst möglich gemacht hat. Legen Sie die kleinstmöglichen Scopes fest und begründen Sie sie. Ordnen Sie zu, in welchem Projekt die Credentials liegen. Und benennen Sie Rotationszeitpunkt und zuständige Person. Die Fußzeile ist die Erfahrung dahinter: Ein Zugang ohne benannte zuständige Person wird nie rotiert — er läuft, bis er auffällt.

4:32 Der erste Punkt ist der halbe Schnitt: Der Hauptworkflow enthält weiterhin die Fremdsystemaufrufe — dann haben Sie ausgelagert, was einfach war, und behalten, was riskant ist. Der zweite ist eine Lücke in der Dokumentation: Die Bausteine sind geschnitten, aber ihre Verträge stehen nirgends. Der dritte ist der Scope-Klassiker: Ein Credential dient lesend und schreibend, weil es nur eines gab.

4:54 Und der vierte ist die vergessene Einstellung aus Modul sechs: Die Sub-Workflows dürfen von jedem aufgerufen werden.

Robustheit und Wiederholbarkeit

5:01 Jetzt die Robustheit. Und die Frage lautet hier nicht, ob etwas schiefgeht, sondern was dann geschieht — Schritt für Schritt, ausdrücklich festgelegt. Vier Festlegungen, und zwar je Schritt, nicht je Workflow. Ist der Schritt gefahrlos wiederholbar, und wenn nicht, was gleicht ihn aus? Was geschieht bei technischem, was bei fachlichem Fehler — die Unterscheidung aus Modul neun. Wohin wandert ein endgültig gescheiterter Vorgang?

5:28 Und woran erkennt der Betrieb, dass etwas liegen geblieben ist? Diese vierte Frage ist die, die man am liebsten überspringt, weil sie unangenehm ist: Sie unterstellt, dass es passieren wird. Genau das tut es. Fünf Schritte, und die Reihenfolge der ersten drei entscheidet. Bestimmen Sie einen fachlichen Schlüssel des Vorgangs.

5:48 Prüfen Sie vor der wirksamen Aktion, ob sie bereits erfolgt ist — vor, nicht nach; das war der Stolperstein aus Modul sieben. Halten Sie das Ergebnis der Aktion mit dem Schlüssel fest. Erproben Sie den Doppellauf mit denselben Daten. Und räumen Sie den Marker zusammen mit dem Vorgang auf. Die Fußzeile nennt die häufigste Falle: Der Schlüssel muss aus den Daten stammen, nicht aus Zeitpunkt oder Zufallswert — sonst ist er nie zweimal gleich und schützt vor gar nichts.

6:16 Der erste Punkt ist der Reihenfolgefehler von eben: Der Schutz gegen Doppelläufe steht hinter der wirksamen Aktion. Der zweite ist zu grob gedacht: Wiederholt wird der ganze Vorgang, nicht der gescheiterte Schritt — dann wirkt alles mehrfach, was schon gewirkt hat. Der dritte ist Papier statt Praxis: Der Ausgleichsschritt ist beschrieben, aber nicht gebaut.

6:36 Und der vierte ist der blinde Fleck aus Modul neun: Liegen gebliebene Vorgänge sammeln sich, ohne dass jemand sie sieht.

KI-Komponente und Human-in-the-Loop

6:43 Jetzt die KI-Komponente. Und die Regel, die durch den gesamten vierten Tag ging, gilt hier als Bauvorschrift: Der Vorschlag darf vom Modell kommen, die Wirkung nicht. Vier Stellen, und die vierte ist eine Abgrenzung. Am Eingang, wo Freitext in Struktur überführt wird — das Extraktionsmuster aus Modul zwölf. Bei der Einordnung, wo eine Auswahl aus fester Liste zu treffen ist. Beim Vorschlag, den ein Mensch annimmt oder verwirft.

7:10 Und ausdrücklich nicht dort, wo eine Regel dasselbe verlässlicher leistet. Wenn Sie Ihren Prozess durchgehen und an einer Stelle KI einsetzen wollen, prüfen Sie zuerst gegen diese vierte Zeile. Sie spart oft Geld und immer Ärger. Vier Fälle, und der letzte ist eine Warnung vor dem Übereifer. Jede wirksame Aktion nach außen — senden, buchen, löschen.

7:33 Jede Änderung an Daten, die andere Systeme als Wahrheit nehmen. Jeder Fall, in dem das Modell selbst unsicher ist. Und dann: nicht jeder Schritt — sonst wird die Prüfung zum Wegklicken. Das ist dieselbe Abwägung wie in Modul vierzehn. Eine Freigabe, die zwanzigmal am Tag kommt, ist nach einer Woche keine Prüfung mehr, sondern eine Handbewegung. Wählen Sie also aus, und begründen Sie die Auswahl.

7:59 Fünf Schritte, die Modul fünfzehn in Ihr Projekt holen. Legen Sie einen Testdatensatz mit Referenzergebnissen an. Legen Sie zwei Metriken fest und begründen Sie je Metrik eine Schwelle. Legen Sie die Messung hinter eine Prüfung, damit sie nicht produktiv mitläuft und Geld kostet. Hängen Sie die Freigabe an die wirksamen Werkzeuge, nicht an den Agenten. Und erproben Sie Ablehnung und Zeitüberschreitung.

8:23 Die Fußzeile verbindet das mit dem ersten Kapitel: Die Schwelle ist eine fachliche Festlegung — sie gehört zu den Akzeptanzkriterien und damit ins Abnahmedokument. Der erste Punkt ist eine Entwicklung, die man früh bremsen sollte: Die Autonomie wird am Anfang großzügig gesetzt und nie wieder geprüft. Besser andersherum: eng anfangen und öffnen, wenn die Zahlen es tragen.

8:46 Der zweite ist der Kontextmangel aus Modul vierzehn: Die Freigabe zeigt das Werkzeug, aber nicht die betroffenen Daten. Der dritte macht Qualität zur Meinung: Es gibt keinen Testdatensatz. Und der vierte ist der bequeme Weg, vor dem der ganze vierte Tag gewarnt hat: Das Modell darf entscheiden, weil die Regel dafür mühsam wäre.

Abnahme und Betriebsübergabe

9:06 Zum Abschluss die Übergabe. Und hier ist die Definition von fertig, mit der dieses Modul begonnen hat: Fertig ist der Prozess, wenn ihn jemand anders betreiben kann. Sieben Kriterien, und jedes hat eine Spalte, die sagt, woran man es prüft — das ist der wichtige Teil. Fachliche Korrektheit an den Akzeptanzkriterien. Nachvollziehbarkeit an der Korrelationskennung über alle Schritte. Fehler- und Grenzfälle an den dokumentierten Testfällen. Die Verträge an den Sub-Workflows.

9:36 Der Schutz von Zugängen am Credential-Konzept. Die begrenzte KI-Autonomie an den Freigabepunkten. Und die Betriebsfähigkeit an Runbook und Übergabe. Sie sehen: Jede Zeile verweist auf etwas, das Sie in diesem Seminar gebaut haben. Das ist Ihre Abnahmeliste. Fünf Schritte. Führen Sie das Security- und Datenschutzreview durch und arbeiten Sie die Befunde ab — die Übung aus Modul siebzehn.

10:01 Listen Sie die Abhängigkeiten auf und spielen Sie sie auf einer zweiten Instanz ein; das ist der ehrlichste Test, den es gibt. Fahren Sie die Testfälle durch und halten Sie das Ergebnis fest. Benennen Sie Runbook, Zuständigkeit und Vertretung. Und veröffentlichen Sie über Review und benennen Sie die Version. Die Fußzeile ist die Erfahrung aus Modul elf: Die Betriebsübergabe endet bei einer Person, nicht bei einem Verteiler.

10:27 Der erste Punkt ist die Übergabe ins Leere: Übergeben wird an ein Team, und niemand fühlt sich zuständig. Der zweite ist eine verbreitete Form nutzloser Dokumentation: Sie beschreibt die Bausteine statt den Prozess — wer wissen will, was ein Baustein tut, kann ihn anklicken; was der Prozess soll, steht nirgends. Der dritte ist die Lücke aus Modul zehn: Der Review wird als vollständige Prüfung genommen.

10:50 Und der vierte ist die Reihenfolge, die man umdrehen sollte: Das Runbook entsteht nach dem ersten Vorfall.

Übung

10:57 Jetzt bauen Sie den Prozess, auf den dieses Seminar von Anfang an zugelaufen ist — den vollständigen Serviceprozess von Kesselwerk, von der Anfrage bis zur Betriebsübergabe. Eine Kunden- oder Serviceanfrage kommt über Formular, E-Mail oder Webhook, wird validiert, eingeordnet und mit Daten aus Kundenkreis und Teilehandel angereichert.

11:17 Ein Modell erstellt einen strukturierten Vorschlag; kritische Änderungen und Nachrichten nach außen brauchen eine Freigabe über Kurzdraht. Danach entstehen Einsätze in Einsatzplan, Statusdaten werden gespeichert, Ereignisse protokolliert. Lesen Sie diese Beschreibung noch einmal: Jeder Teilsatz ist ein Modul dieses Seminars. Sie haben alle Bestandteile einzeln gebaut — jetzt geht es darum, dass sie zusammen tragen.

11:42 Das Lernziel: die Mittel des Seminars in einem durchgängigen Prozess so zusammenführen, dass er ohne die erbauende Person betrieben werden kann. Erfolgreich sind Sie, wenn alle sieben Abnahmekriterien belegt sind, ein Doppellauf keinen zweiten Vorgang erzeugt, eine abgelehnte Freigabe wirkungslos bleibt und die Übergabe an eine Person ging.

12:00 Wer früh fertig ist — und das ist die schönste Zusatzaufgabe dieses Seminars — lässt eine andere Gruppe den Prozess anhand der Übergabe allein in Betrieb nehmen. Ehrlicher kann man eine Dokumentation nicht prüfen. Fünf Blöcke, und sie folgen den Kapiteln dieses Moduls. Legen Sie Abgrenzung, Akzeptanzkriterien und Datenmodell fest.

12:20 Bauen Sie Hauptworkflow und Sub-Workflows mit ihren Verträgen. Ergänzen Sie Fehlerpfade, Idempotenz und die Ablage für endgültig Gescheitertes. Sichern Sie die KI-Komponente mit Testdatensatz und Freigabe ab. Und schließen Sie mit Review, Security-Prüfung, Übergabe und kontrollierter Veröffentlichung. Halten Sie sich an die Reihenfolge — jeder Block setzt den vorherigen voraus, und wer beim zweiten anfängt, baut den ersten später nach.

12:47 Vier Fallen zum Schluss. Erstens: Gebaut wird zuerst, abgegrenzt zuletzt — der Fehler, mit dem dieses Modul begonnen hat. Zweitens: Die Freigabe wird eingebaut, aber nur der Zustimmungsfall erprobt. Drittens: Die Übergabe besteht aus dem Satz „liegt in n8n". Und viertens, und das ist die ehrlichste Beobachtung aus Projekten: Am Ende fehlt die Zeit für genau die Schritte, die den Prozess betriebsfähig machen.

13:14 Planen Sie sie ein, bevor Sie anfangen — sie sind nicht der Abschluss der Arbeit, sie sind ein Teil davon.