Jedes Analytics-Team hat einen Workflow wie diesen: er wird jeden Monat zuverlässig nach Zeitplan ausgeführt, und Schritt vier gibt demjenigen, der aktuell dafür zuständig ist, immer noch Rätsel auf. Niemand erinnert sich mehr daran, warum der Filter zweimal ausgeführt wird oder warum die Währungsumrechnung vor dem Join statt danach erfolgt.
Der Workflow funktioniert, bis zu dem Monat, in dem er es nicht mehr tut. Die Person, die Schritt vier hätte erklären können, hat das Team vor achtzehn Monaten verlassen.
Das ist kein Personalproblem. Es ist ein Designproblem. Der Workflow wurde geplant, nicht orchestriert, und niemand hat die Logik an einer Stelle hinterlegt, an der die nächste Person sie finden konnte.
Bevor Sie davon ausgehen, dass die Version dieses Workflows in Ihrem Team in Ordnung ist, erfassen Sie über einen kompletten Zyklus hinweg eine Sache: jeden manuellen erneuten Durchlauf, jeden Patch, jede Nachricht, die nötig ist, um einen einzelnen wiederkehrenden Workflow erfolgreich abzuschließen. Diese Zahl, nicht die Version des Prozesses, die man auf Nachfrage verteidigen würde, ist die eigentliche Ausgangsbasis.
„Geplant“ und „orchestriert“ führen zu zwei unterschiedlichen Ergebnissen
Ein geplanter Auftrag startet automatisch. Ein orchestrierter Workflow weiß außerdem, was zu tun ist, wenn eine Abhängigkeit verspätet ist, eine Datei fehlt oder ein Schritt fehlschlägt – im Gegensatz zu einem geplanten Auftrag. Diese Unterscheidung trennt mehr als jedes spezifische Tool einen Workflow, dem Analysten vertrauen können, von einem, den sie ständig überwachen müssen.
Das Problem hinter dieser Unterscheidung ist gut dokumentiert und nicht anekdotisch. In einer Umfrage unter 10.000 Büroangestellten in 11 Ländern gaben 63 % an, dass Menschen keine wiederkehrenden administrativen digitalen Aufgaben erledigen sollten, die automatisiert werden könnten – ein Ergebnis aus dem Jahr 2020 aus einer von einem Anbieter in Auftrag gegebenen Umfrage, das sich nach wie vor damit deckt, wie Analysten ihre eigene Arbeitswoche beschreiben. Die Workflow-Orchestrierung hat sich zudem zu einer eigenen, von Analysten beobachteten Kategorie entwickelt: Gartner veröffentlichte im August 2025 einen Magic Quadrant for Service Orchestration and Automation Platforms – ein Beleg dafür, dass dies ein anerkannter Markt für Unternehmenstechnologie ist und keine Marketingsprache, die für einen Blogbeitrag entlehnt wurde.
Sich mit „lediglich geplant“ zufriedenzugeben, birgt Kosten, die so lange unsichtbar bleiben, bis es teuer wird. Fehler treten unbemerkt auf, da im Auftrag nichts darauf ausgelegt ist, sie zu erkennen oder zu melden. Veraltete Ausgaben werden als aktuell dargestellt, weil niemand eine Aktualitätsprüfung in den Workflow selbst integriert hat und das Erfahrungswissen, das das Verhalten des Auftrags erklären würde, im Kopf eines Analysten oder auf einem Haftnotizzettel existiert, anstatt im Workflow.
Zuverlässig von selbst zu laufen, hat eine konkrete Definition. Das bedeutet, dass der Workflow weiterhin ordnungsgemäß läuft, wenn eine Person ausfällt, eine Datei verspätet eintrifft oder ein System kurzzeitig hakt, und niemand es bemerkt, bis man auf einer Statusseite nachsieht, anstatt weil etwas ausgefallen ist. Das ist das Ergebnis, auf das es sich hinzuarbeiten lohnt, und um dorthin zu gelangen, bedarf es mehr als nur einer geplanten Aufgabe.
Diese Workflows werden selten absichtlich so erstellt. Ein Zeitplan wird unter Termindruck eingerichtet, läuft einige Durchläufe lang problemlos, und niemand befasst sich mehr damit, bis ein Fehler so kostspielig wird, dass er nachverfolgt werden muss. Bis ein Team die Lücke bemerkt, ist der Workflow bereits monatelang unbeaufsichtigt gelaufen und hat im Stillen Vertrauen aufgebaut, das er eigentlich gar nicht verdient hat.
Die Methode: 4 Anforderungen, die ein Workflow erfüllen muss, bevor er sich selbst ausführt
Vier Anforderungen müssen gemeinsam erfüllt sein, bevor ein Workflow von selbst ausgeführt wird: definierte Trigger, Abhängigkeits- und Fehlerbehandlung, echtes Monitoring und weitergeleitete Übergaben. Wenn nur drei von vier Anforderungen erfüllt sind, benötigt ein Workflow weiterhin ein menschliches Sicherheitsnetz, da die vierte Lücke zum neuen manuellen Schritt wird.
Ein Workflow mit zuverlässigen Auslösern und Abhängigkeitsmanagement, aber ohne echte Überwachung, erfordert beispielsweise immer noch, dass jemand manuell prüft, ob er funktioniert hat. Die Anforderungen sind kein Menü, aus dem man einfach auswählen kann. Sie funktionieren wie eine Kette, und ein Workflow ist nur so autark wie sein schwächstes Glied.
Auslöser definieren
Ein Workflow benötigt eine definierte Startbedingung. Das kann ein Zeitplan sein, der für eine einmalige Ausführung oder nach einem wiederkehrenden oder benutzerdefinierten Zeitplan wie einem Geschäftskalender eingerichtet ist, oder es kann ein Ereignis sein: das Eintreffen oder Ändern einer Datei oder Tabelle in einer verbundenen Quelle. Analysten können für bestimmte Verbindungstypen bei einer Datei- oder Tabellenänderung auslösen, wie etwa beim Eintreffen einer neuen Datei im Cloud-Speicher, obwohl dies eingeschränkter ist als das Auslösen bei beliebigen geschäftlichen Ereignissen an jeder beliebigen Stelle im Stack.
Ein Rhythmus nach Geschäftskalender ist hier besonders wichtig, da Finanz- und Abschluss-Workflows oft nicht nach einem festen wöchentlichen oder monatlichen Takt ablaufen. Sie basieren auf einem Kalender mit integrierten Verschiebungen durch Quartalsenden, Geschäftsjahresenden und Feiertage, und ein Trigger, der dies nicht berücksichtigen kann, erfordert letztendlich ohnehin manuelle Anpassungen.
Umgang mit Abhängigkeiten und Fehlern
Eine Abhängigkeit bedeutet, dass Schritt B erst starten kann, wenn Schritt A den Erfolg bestätigt, und nicht erst, wenn Schritt A wahrscheinlich abgeschlossen ist. Ein Workflow benötigt definierte Workflow-Abhängigkeiten und bedingte Logik dafür, was passiert, wenn ein vorgelagerter Schritt verspätet ist, fehlt oder fehlschlägt, anstatt dass eine Person dies manuell überprüft und von Hand erneut ausführt. Der entscheidende Unterschied besteht zwischen einem Workflow, der sicher stoppt, wenn seine Eingabe nicht bereit ist, und einem, der trotzdem mit veralteten oder unvollständigen Daten ausgeführt wird.
Stellen Sie sich einen Bericht vor, der davon abhängt, dass drei vorgelagerte Extrakte erfolgreich bereitgestellt werden. Wenn ein Extrakt noch ausgeführt wird, wenn der Bericht gestartet wird, erstellt ein rein zeitgesteuerter Auftrag den Bericht dennoch – wobei ein Drittel der Daten fehlt und es keinerlei Hinweis darauf gibt, dass etwas nicht stimmt.
Monitoring integrieren
Man benötigt einen zentralen Ort, um zu sehen, was wann ausgeführt wurde, ob es erfolgreich war und wer dafür zuständig ist. Das unterscheidet sich von einer verstreuten Mischung aus E-Mail-Bestätigungen und „Hat das geklappt?“-Nachrichten in einem Team-Kanal. Echtes Monitoring ist ein Status, den man in Sekundenschnelle überprüfen kann, und nicht eine Reihe von Hinweisen, die man manuell zusammentragen muss.
Eine nützliche Monitoring-Ansicht zeigt den Status der letzten Ausführung, die dafür verantwortliche Person und wo die Ausgabe gelandet ist – alles auf einem einzigen Bildschirm, den eine Führungskraft in der Zeit erfassen kann, die das Öffnen eines Browser-Tabs dauert.
Gestaltung von Übergaben
Wenn die Ausgabe eines Workflows eine menschliche Entscheidung erfordert, wie z. B. die Genehmigung einer Abweichung oder die Überprüfung eines markierten Datensatzes, muss diese Übergabe an eine bestimmte Person weitergeleitet werden und im Nachhinein nachvollziehbar sein. Das Ablegen in einem allgemeinen Posteingang macht eine Ausnahme zu etwas, das darauf wartet, dass jemand sie bemerkt.
Ein gutes Routing bedeutet, dass der Workflow bereits weiß, dass Abweichungsposten über einem Schwellenwert an den Controller der Entität gehen, der für dieses Konto zuständig ist, und nicht an die Person, die in dieser Woche zufällig den Posteingang überwacht.
Was diese vier Anforderungen gemeinsam haben, ist, dass jede einzelne erfordert, dass die zugrunde liegende Logik an einem dauerhaften und überprüfbaren Ort erfasst wird, nicht in einem Skript, das nur von einer Person gepflegt wird, und nicht im Gedächtnis einer Person.
Wo jede dieser vier Anforderungen in der Praxis an ihre Grenzen stößt
Jede der oben genannten Anforderungen schlägt tendenziell auf eine spezifische, erkennbare Weise fehl, und die Fehler spiegeln die vier Anforderungen exakt wider. Trigger versagen, wenn „geplant“ insgeheim „auf einem einzelnen Laptop geplant“ bedeutet: Der Auftrag wird nicht ausgeführt, wenn dieser Rechner ausgeschaltet ist, sich im Ruhezustand befindet oder sein Eigentümer abwesend ist, und nichts weist auf das Ausbleiben hin. Niemand bemerkt es, bis jemand im weiteren Verlauf fragt, warum die Zahlen des Vormonats immer noch im Bericht dieses Monats angezeigt werden.
Die Handhabung von Abhängigkeiten schlägt fehl, wenn die Abhängigkeit auf einer Schätzung des Zeitpunkts beruht, etwa „Führen Sie es nach dem Mittagessen aus, das ist normalerweise spät genug“, anstatt auf einer geprüften Bedingung. Der Workflow wird trotzdem pünktlich ausgeführt. Er wird lediglich mit Daten ausgeführt, die noch nicht vollständig geladen wurden, und wenn jemand das Quellsystem überprüft, wurde der Bericht bereits an alle versendet, die darauf gewartet haben.
Das Monitoring schlägt fehl, wenn „Prüfen, ob es gelaufen ist“ bedeutet, dass jemand die Ausgabedatei öffnet, um zu sehen, ob die Zahlen plausibel aussehen, anstatt einen Status zu überprüfen. Die Monitoring-Variante eines Teams entpuppte sich als ein gemeinsam genutztes Tabellenblatt, in das derjenige, der es zuerst bemerkte, „lief gut“ oder „bitte prüfen“ eintrug – ein manuelles Statusprotokoll, das einem automatisierten Auftrag aufgepfropft wurde und den eigentlichen Zweck der ursprünglichen Automatisierung still und heimlich zunichtemacht. Dieses Tabellenblatt funktioniert einwandfrei, bis an jenem einen Tag zufällig niemand nachschaut und die Kluft zwischen „ausgeführt“ und „ordnungsgemäß ausgeführt“ unerfasst bleibt.
Übergaben scheitern, wenn eine Ausnahme in einem geteilten Posteingang oder Kanal landet, anstatt an den zuständigen Eigentümer zu gehen, sodass sie ungelöst bleibt, bis zufällig jemand daran vorbeiscrollt. Bis sie jemand an die richtige Person weiterleitet, ist der Bericht, den sie korrigieren sollte, oft bereits versendet worden.
Hinter den meisten dieser Ausfälle steckt ein einfacheres Problem: Ein beträchtlicher Teil dessen, was wie manuelle Arbeit aussieht, ist in Wirklichkeit manuelle Datenbewegung – jemand, der sich bei einem Portal anmeldet oder eine CSV-Datei von Hand exportiert. Ein Zeitplan, der automatisch abläuft, nützt nicht viel, wenn sich jeden Monat immer noch jemand bei fünf verschiedenen Portalen anmelden muss, um die Eingaben manuell zusammenzutragen. Eine Orchestrierung löst dieses Problem nur dann, wenn das Tool auch eine Verbindung dorthin herstellen kann, wo sich die Daten bereits befinden – über eine umfassende Bibliothek vorgefertigter Konnektoren anstelle eines einmaligen Skripts pro System.
Wie eine vollständig orchestrierte Version dieses Prozesses aussieht
Schnelle, verlässliche Abschlüsse entstehen ebenso durch Prozessdesign wie durch Tools. Leistungsstarke Finanzteams setzen auf gemeinsame strukturelle Ansätze für Abschluss, Konsolidierung und Berichterstattung – und nicht nur auf ein schnelleres Tool, das auf dieselben undokumentierten Schritte aufgesetzt wird.
Zusammengenommen bedeuten diese vier Anforderungen, dass die Trigger-Bedingung, die Abhängigkeitsprüfung und die Überwachungsansicht alle im Workflow selbst verankert sein müssen – und nicht im Gedächtnis eines Analysten, auf einem Notizzettel oder in einem Slack-Thread. Genau dafür sind Plattformen wie Alteryx One ausgelegt: ein einmal erstellter Workflow, dessen Logik im Workflow selbst erfasst ist und der dann eigenständig ausgeführt und überwacht werden kann, anstatt in jedem Zyklus neu erklärt werden zu müssen. Um ein umfassenderes Bild davon zu erhalten, wie die Orchestrierung von Anfang bis Ende funktioniert, ist es hilfreich zu sehen, wie die vier Anforderungen von Anfang bis Ende auf einen echten Prozess angewendet werden.
Der manuelle Prozess, wie er heute tatsächlich abläuft
Der Monatsabschluss eines mittelständischen Unternehmens durchläuft einen Varianzanalysten, einen Controller und sechs über Regionen verteilte Entitäts-Controller. Saldenbilanzen werden für jede der sechs Entitäten aus NetSuite exportiert und in eine separate Excel-Arbeitsmappe für Intercompany-Eliminierungen eingefügt. Die Zusammenstellung des gesamten Zyklus nimmt für den Varianzanalysten in der Regel vier bis fünf Arbeitstage in Anspruch, bevor der Controller überhaupt mit der Überprüfung beginnt.
Währungsumrechnungen und Eliminierungsbuchungen laufen in dieser Arbeitsmappe ab, und alles mit einer Abweichung von über 5 % wird gekennzeichnet und per E-Mail oder Direktnachricht an den zuständigen Entitäts-Controller nachverfolgt. Concur-Ausgabendaten und eine separate BI-Ebene speisen den endgültigen Abweichungsbericht, der auf dem Schreibtisch des CFO landet.
Ein Detail macht diesen Prozess auf eine Weise anfällig, die niemand aufgeschrieben hat: Die Eliminierungs-Arbeitsmappe ist nur dann korrekt ausgeglichen, wenn sie aktualisiert wird, nachdem die Entität in Singapur am Ende ihres lokalen Arbeitstages ihre konzerninternen Journalbuchungen verbucht hat. Diese zeitliche Abhängigkeit existierte nur als etwas, das der vorherige Analyst einmal beiläufig erwähnte.
Der Moment, in dem alles schiefgeht
Ein neuer Analyst übernimmt den Prozess und ruft den Export um 9:00 Uhr ab Ostküstenzeit, Stunden bevor das lokale Buchungsfenster in Singapur schließt. Die konzerninterne APAC-Position weicht um 4.200 $ ab, und das geschieht bei drei Abschlüssen in Folge, bevor jemand die Ursache auf das Timing statt auf einen Datenfehler zurückführt.
Der Controller muss ein Berichterstattungspaket wieder öffnen, das sich bereits mitten in der Überprüfung befand. Jeder dieser drei Abschlüsse kostete den Controller einen zusätzlichen Tag für die Überarbeitung der unternehmensinternen Aufstellung – zusätzlich zum normalen Abschlusskalender – und im Nachhinein kann niemand sauber beantworten, wer die Korrektur genehmigt hat oder wann die Diskrepanz erstmals aufgetreten ist.
Die automatisierte Alternative
Der Eliminierungsschritt wird mit einer Abhängigkeitsbedingung definiert: Er beginnt erst, wenn das Vorhandensein der Summen- und Saldenlisten aller sechs Entitäten bestätigt wurde, und nicht zu einer geschätzten Tageszeit. Der Trigger ist ereignisbasiert, sofern die Quelle dies unterstützt, und wird ausgelöst, wenn eine Datei am verbundenen Speicherort eingeht, anstatt davon abzuhängen, dass eine Person daran denkt, ihn zu starten.
Ausführungsstatus, Eigentümer und Abschlusszeit sind an einem zentralen Ort einsehbar, da der Workflow in der Cloud ausgeführt wird, anstatt davon abzuhängen, ob der Laptop einer Person zufällig eingeschaltet ist. Saldenabstimmung, Eliminierung und Abweichungsweiterleitung erfolgen jetzt in einem Workflow, den der Abweichungsanalyst durchgängig einsehen kann, anstatt eine Arbeitsmappe, einen Concur-Export und einen BI-Bericht manuell zusammenzufügen. Abweichungen über dem Schwellenwert werden automatisch an den jeweiligen Entitäts-Controller weitergeleitet, der für diese Position zuständig ist – mit dem gekennzeichneten Datensatz im Anhang, anstatt als allgemeine E-Mail versendet zu werden.
Finanzteams, die dasselbe Muster für ihren eigenen Abschluss aufbauen, können sich den Use Case zur Automatisierung des Monatsabschlusses für die finanzspezifische Version dieses Ansatzes ansehen.
Das Ergebnis
Die zeitliche Abhängigkeit für Singapur wird nun durch die eigene Logik des Workflows durchgesetzt und nicht mehr nur im Gedächtnis eines Analysten bewahrt. Der Abschluss, der sich aufgrund dieses zeitlichen Problems einst um einen Tag oder mehr verzögerte, wird nun nach dem ursprünglichen Zeitplan abgeschlossen, da die Abhängigkeitsprüfung des Workflows – und keine Person – die Reihenfolge durchsetzt, in der die Aktualisierungen der Entitäten bestätigt werden.
Abweichungserklärungen sind dem Bericht bereits beigefügt, bevor er den CFO erreicht, anstatt dass man ihnen im Nachhinein hinterherjagen muss. Ein Ausführungsverlauf beantwortet die Frage, „wer was wann ausgeführt hat“, ohne dass jemand dies aus dem Gedächtnis oder anhand von E-Mails rekonstruieren muss – was beim nächsten Mal entscheidend ist, wenn ein Wirtschaftsprüfer oder ein neuer Analyst fragt, wie eine Zahl zustande gekommen ist.
Klein anfangen, ohne auf ein perfektes Rollout zu warten
Wählen Sie einen wiederkehrenden Workflow aus, der bereits spürbare Probleme bereitet, idealerweise einen mit einer bekannten Fehlerhistorie, anstatt zu versuchen, alles auf einmal zu orchestrieren. Ein einzelnes, gut gewähltes Pilotprojekt beweist das Modell schneller als ein breiter Rollout und gibt dem Team etwas Konkretes an die Hand, auf das es sich bei der Anfrage nach dem nächsten beziehen kann.
Definieren Sie den Erfolg für dieses Pilotprojekt eng: Der Workflow sollte einen vollständigen Zyklus lang laufen und überprüfbar sein, ohne dass ihn jemand manuell erneut ausführt. Wenn diese Messlatte nicht erreicht wird, ist das Pilotprojekt noch nicht abgeschlossen, ganz gleich, wie gut der Workflow auf dem Papier aussieht.
Die IT wird fragen, wie sich das Tool mit bestehenden Systemen verbindet und wer Workflows sehen, ausführen oder bearbeiten kann, sobald sie live sind. Für Teams, die möchten, dass sich die Orchestrierung in einen umfassenderen Automatisierungs-Stack einfügt, beantwortet eine dokumentierte REST-API den ersten Teil dieser Frage direkt und ermöglicht es anderen Systemen, Aufträge programmgesteuert auszulösen oder Zeitpläne zu überprüfen. Das ist vor allem für Teams wichtig, die bereits über einen internen Planer, ein Ticketsystem oder einen Datenkatalog verfügen, den sie nicht einfach aufgeben möchten, nur um eine Orchestrierung einzuführen; die API sorgt dafür, dass sich der neue Workflow in das Vorhandene einfügen kann, anstatt es zu ersetzen.
Eine Führungskraft aus dem Finanz- oder operativen Bereich wird eine andere Frage stellen: Was geschieht mit Transparenz und Prüfpfaden, sobald dies über einen einzelnen Workflow hinaus skaliert wird. Die ehrliche Antwort bleibt ergebnisorientiert, anstatt zu einer Compliance-Checkliste zu werden: ein Ausführungsverlauf, der zeigt, wer was wann ausgeführt hat, und Verantwortlichkeiten, die sichtbar sind, ohne dass erst herumgefragt werden muss. Das ist eine niedrigere Hürde, als gleich am ersten Tag beweisen zu müssen, dass jeder Workflow unfehlbar ist, und zudem eine ehrlichere: Das Team kann grundlegende Fragen zur eigenen Automatisierung beantworten, ohne dafür eine gesonderte Untersuchung einleiten zu müssen.
Dieser Ansatz ist nicht für jedes Team die passende Lösung. Gruppen, deren Workflows hauptsächlich in Code abgebildet sind und bereits von Data Engineers gepflegt werden, sind mit einem im Repository verwalteten Code-First-Orchestrierungs-Framework womöglich besser beraten, als eine neue Plattform auf das aufzusetzen, was sie bereits aufgebaut haben. Ein fünfköpfiges Engineering-Team, das bereits sein eigenes Orchestrierungs-Framework für Daten-Pipelines verwaltet, benötigt wahrscheinlich keine zweite Ebene, die zusätzlich auf die erste aufgesetzt wird.
Weniger manuelle Schritte waren nie das eigentliche Ziel. Das eigentliche Ziel ist ein Workflow, dessen Logik erhalten bleibt, wenn die Person, die ihn erstellt hat, das Unternehmen verlässt. Wie auch immer der erste Workflow aussieht, das Ziel der Automatisierung ist dasselbe: sicherzustellen, dass die nächste Person, die ihn übernimmt, Schritt vier nicht von Grund auf rekonstruieren muss. Teams, die bereit sind, dies bei ihrem eigenen wiederkehrenden Abschluss-, Abstimmungs- oder Berichterstattungsprozess zu testen, können eine kostenlose Testversion von Alteryx One starten und noch diesen Monat den ersten Pilot-Workflow orchestrieren.