Die meisten wiederkehrenden Analyst-Workflows haben die gleiche Grundstruktur: Daten aus einer Quelle abrufen, bereinigen, mit etwas anderem verknüpfen, Geschäftslogik anwenden und eine Ausgabe erzeugen. Die Ausgabe landet irgendwo – in einem Bericht, einer Snowflake-Tabelle, einer E-Mail – und das Ganze wird nächsten Montag erneut ausgeführt. Oder auch nicht, weil die Person, die den Prozess erstellt hat, nicht da ist.
Die meisten Unternehmen gehen davon aus, dass die Automatisierung dieser Art von Arbeit Python oder SQL erfordere – es sich also um ein technisches Problem handelt. Das ist es nicht. Das Problem ist, dass die Logik, die in der Tabellenkalkulation und im Kopf der oder des Data Analyst steckt, der sie erstellt hat, nie ein dauerhaftes Zuhause gefunden hat. Dieser Beitrag wie genau das gelöst wird. Ohne Code schreiben zu müssen.
Wenn Ihr Team über einen Bericht verfügt, der jede Woche dieselben manuellen Schritte ausführt – dieselben Quellen, dieselbe Logik, dieselbe Ausgabe –, ist dies der Workflow, den Sie beim Lesen im Hinterkopf behalten sollten.
Warum manuelle Daten-Workflows immer wieder ausfallen – und warum mehr Tools das Problem nicht lösen
Es gibt eine nützliche Unterscheidung, die es wert ist, vor der Problemdiagnose getroffen zu werden. Geschäftslogik existiert an vielen Stellen: in ERP-Konfigurationsregeln, CRM-Workflow-Triggern, BI-berechneten Feldern. Unternehmen kodieren eine enorme Menge an Logik in ihre Systeme. Was selten kodiert wird, ist die darüber liegende Ebene: die analystenspezifische Interpretation, die die Daten erst für einen bestimmten Bericht oder eine bestimmte Entscheidung nutzbar macht.
Diese Ebene umfasst Dinge wie: die Abgleichsregel, die eine Abweichung von 3 % als akzeptabel behandelt, es sei denn, das Konto befindet sich in einer bestimmten Region; die Ausnahmeliste für Kund:innen, deren IDs systemübergreifend unterschiedlich formatiert sind; welche Umsatzrealisierungsmethode angewendet wird, wenn ein Geschäft in der letzten Woche eines Quartals abgeschlossen wird. Dies ist keine Geschäftslogik im Sinne einer Systemkonfiguration. Es handelt sich um institutionelles Wissen – die Anhäufung von Entscheidungen, die über Monate oder Jahre hinweg von Data Analysts getroffen wurden, die das Geschäft gut genug verstanden haben, um zu wissen, was die Rohdaten allein nicht sagen könnten.
Dieses Wissen steckt in Tabellenkalkulationsformeln, in AC-Spalten-Nachschlagetabellen und in den Köpfen derjenigen, die den Prozess entwickelt haben. Es wird nie systematisch dokumentiert – was bedeutet, dass es nie systematisch gepflegt wird. Jede vorgelagerte Änderung – ein umbenanntes Salesforce-Feld, eine neue Kostenstelle, eine Gebietsumstrukturierung – muss manuell an jeder Stelle aufgespürt werden, an der diese Logik von Hand angewendet wurde.
Die häufigsten Fehlermuster
Das Problem des Wissenstransfers. Wenn die Person, die für einen kritischen Workflow verantwortlich ist, das Unternehmen verlässt oder die Rolle wechselt, wird der Prozess entweder nicht mehr ausgeführt oder von Grund auf neu erstellt. Der Neuaufbau dauert in der Regel Wochen, und die neu erstellte Version weist subtile Fehler auf, die niemandem auffallen, bis die Zahlen in einer Vorstandssitzung auftauchen. Das ist kein Problem, das am Menschen liegt. Das passiert, wenn institutionelles Wissen nur im Gedächtnis einer Person zu Hause ist.
Das Problem des unbemerkten Fehlers. Ein vorgelagertes System fügt eine Spalte hinzu, ändert einen Feldnamen oder passt ein ID-Format an. Der SVERWEIS verweist auf die falsche Spalte. Die Ausgabe sieht weiterhin richtig aus. Über zwei Berichtszyklen hinweg bemerkt niemand den Fehler. Bis der Fehler ans Licht kommt, sind Daten aus zwei Monaten betroffen, und die Korrektur erfordert die Rückverfolgung durch einen undokumentierten Prozess, um zu verstehen, was schiefgelaufen ist. Die Anfälligkeit wurde nicht durch die neue vorgelagerte Änderung eingeführt – sie war bereits da.
Die Skalierungsgrenze. Der Prozess funktioniert für das aktuelle Datenvolumen und den aktuellen Berichtssatz. Dann wächst das Unternehmen, fügt neue Produktlinien hinzu oder erwirbt eine Einheit. Manuelle Workflows sind nicht skalierbar – sie fragmentieren in leicht unterschiedliche Versionen, die von verschiedenen Personen verwaltet werden, was zu leicht unterschiedlichen Zahlen führt, die im ungünstigsten Moment entdeckt werden.
BI-Tools benötigen saubere, strukturierte Daten als Eingabe – sie produzieren sie nicht. ETL-Pipelines arbeiten auf Schemaebene und sind für Data Engineers konzipiert, nicht für die Anwendung der oben beschriebenen, entscheidungsintensiven Geschäftslogik. Python und dbt füllen diese Lücke für Engineering-Teams, übertragen aber die Verantwortung für die Logik von Data Analysts, die sie verstehen, auf Data Engineers, die das Skript verwalten. Das fehlende Stück ist eine Ebene, auf der geschäftsspezifische Logik einmal codiert, von den Personen, die dafür zuständig sind, gepflegt und zuverlässig ohne Eingriffe ausgeführt werden kann. Genau dafür wurde die Automatisierung von Daten-Workflows entwickelt.
Python, Power Automate oder No-Code-Automatisierung: ein ehrlicher Vergleich
Welches Tool das richtige ist, hängt davon ab, wer für die Logik verantwortlich sein muss und wie oft sie sich ändert.
Python + dbt ist die richtige Wahl, wenn die Umwandlungslogik komplex genug für versioniertes Engineering ist und das Team über die nötige Kapazität verfügt, um sie zu pflegen.
Power Automate bewältigt das App-zu-App-Routing innerhalb des Microsoft-Ökosystems gut, ist jedoch nicht für eine mehrstufige analytische Datenvorbereitung über Systeme hinweg mit nicht übereinstimmenden Schemata konzipiert.
Eine von Engineering gepflegte Pipeline ist sinnvoll, wenn der Prozess großvolumig und schemastabil ist und es unwahrscheinlich ist, dass Änderungen an den Geschäftsregeln erforderlich sind.
No-Code-Workflow-Automatisierung ist die richtige Lösung, wenn die Logik in den Händen von Data Analysts liegt, wenn der Workflow von den Personen, die das Geschäft kennen, verstanden und geändert werden muss und wenn die Iterationsgeschwindigkeit wichtig ist.
Die entscheidende Frage: Wer muss bei einer Änderung der Geschäftsregel involviert sein? Lautet die Antwort, ein Data Analyst, sollte der Workflow in einem Tool abgebildet werden, das der Analyst selbst warten kann.
So automatisieren Sie einen Daten-Workflow, ohne Code schreiben zu müssen: eine Schritt-für-Schritt-Anleitung
Die folgenden Schritte funktionieren mit jeder No-Code-Plattform zur Workflow-Automatisierung. Sie richten sich an leitende Data Analysts, die die Daten und das Geschäftsproblem verstehen und einen ersten automatisierten Workflow ohne Engineering ausführen möchten.
Schritt 1: Wählen Sie zunächst den richtigen Workflow aus
Nicht jeder Workflow ist es gleichermaßen wert, zuerst automatisiert zu werden. Der beste Kandidat für den Einstieg hat drei Eigenschaften: Er wird nach einem festen Zeitplan oder regelmäßigen Auslöser ausgeführt, er erzeugt jedes Mal die gleiche Art von Ausgabe, und die Person, die ihn verantwortet, ist dieselbe Person, die die Geschäftslogik dahinter versteht.
Eine praktische Diagnose: Rufen Sie die letzten drei Monate Ihres Kalenders auf. Suchen Sie nach einem Block mit der Bezeichnung „Bericht aktualisieren“, „ Zahlen ziehen“ oder „Wochenbericht ausführen“. Das ist Ihr erster Kandidat – insbesondere der, bei dem Sie sich gedacht haben: „Das habe ich schon Tausende Mal gemacht.“
Beginnen Sie nicht mit Ihrem komplexesten Workflow. Beginnen Sie mit etwas Vorhersehbarem. Das Ziel der ersten Automatisierung besteht darin, eine funktionierende Vorlage zu erstellen, die Sie durchgängig verstehen, und nicht darin, Ihr schwierigstes Problem zu lösen.
Schritt 2: Notieren Sie sich jeden Schritt, bevor Sie ein Tool verwenden
Dies ist der Schritt, den die meisten Data Analysts überspringen. Und genau deshalb scheitern erste Automatisierungsversuche. Bevor Sie irgendeine Plattform öffnen, schreiben Sie den Prozess von der ersten Datenquelle bis zur endgültigen Ausgabe auf – und zwar nicht nur grob umrissen, sondern Schritt für Schritt.
Ein bewährtes Format hierfür ist: Quelle, Aktion, Ausgabe. Schreiben Sie für jeden Schritt auf, aus welchem System oder welcher Datei die Daten stammen, was Sie mit ihnen machen (Filtern, Verknüpfen, Berechnen, Bereinigen, Neuformatieren) und was das Ergebnis ist. Wenn Sie zwei Tabellen verknüpfen, notieren Sie den Verknüpfungsschlüssel ebenso wie alle bekannten Abweichungen. Wenn Sie eine Formel anwenden, schreiben Sie die Formel aus. Wenn es Ausnahmen gibt – Konten, die unterschiedlich behandelt werden, Datumsbereiche, die eine andere Logik verwenden, alles, was Sie in einer Nachschlagetabelle pflegen – dokumentieren Sie diese explizit.
Die meisten Data Analysts werden feststellen, dass dieser Vorgang 45 bis 90 Minuten in Anspruch nimmt und ein umfangreicheres Dokument erzeugt als erwartet. Ein Prozess, der jede Woche 90 Minuten für die Dokumentation und zwei Stunden für die Ausführung benötigt, ist ein starker Kandidat für die Automatisierung. Ist ein Prozess hingegen schwer zu dokumentieren, weil die Vorgehensweise „von verschiedenen Faktoren abhängt“, deutet dies darauf hin, dass die zugrundeliegende Logik noch nicht stabil genug ist.
Schritt 3: Unterscheiden Sie zwischen regelbasierter und urteilsbasierter Logik
Genau diese Unterscheidung bestimmt, was automatisiert werden kann und wo ein Mensch in den Prozess eingebunden bleiben muss.
Regelbasierte Logik liefert unabhängig vom Kontext stets das gleiche, reproduzierbare Ergebnis: Verknüpfung über einen bestimmten Schlüssel, Markierung von Zeilen bei Abweichungen von mehr als 5 %, Filterung auf den Status „erfolgreicher Abschluss“ oder Anwendung einer bestimmten Währungsumrechnung. All dies lässt sich direkt in einen Workflow-Schritt integrieren.
Logik, die auf Urteilsvermögen beruht, umfasst alles, bei dem die richtige Antwort eher in Ihrem Kopf als in einer fest definierten Bedingung liegt. Typische Beispiele hierfür sind: „Diese drei Konten müssen immer manuell geprüft werden, da sich ihre IDs nie eindeutig zuordnen lassen“, „Dieses Umsatzfeld hat im vierten Quartal eine andere Bedeutung“ oder „Der Schwellenwert liegt bei 5 %, außer bei Enterprise-Konten, für die wir 8 % ansetzen.“ Die Prozessdokumentation aus Schritt 2 macht diese Fälle sichtbar – meist handelt es sich um Schritte, die Sie als „manuell prüfen“ notiert haben oder die sich ohne Einschränkungen wie „es kommt darauf an“ nicht beschreiben ließen.
Das Ziel besteht nicht darin, das menschliche Urteilsvermögen zu eliminieren, sondern es explizit zu machen. Fragen Sie sich für jeden urteilsabhängigen Schritt: Welche Regel wende ich tatsächlich an, auch wenn ich sie nie aufgeschrieben habe? Meist lässt sich diese Regel formulieren. Sobald sie definiert ist, wird sie zu einem konfigurierbaren Parameter oder einer Nachschlagetabelle, auf die der Workflow zugreift, anstatt eine Entscheidung zu sein, die Sie in jedem Durchlauf manuell treffen müssen. Eine Liste von Ausnahmekonten, die sich in Spalte AC Ihrer Tabelle befindet, wird zu einer eigenständigen Referenzdatei, die der Workflow liest. Ein Schwellenwert, der bisher nur in Ihrem Kopf existiert, wird zu einem benannten Parameter am Anfang des Workflows mit einem Hinweis, der seinen Ursprung erläutert.
Schritt 4: Erfassen Sie Ihre Datenverbindungen und die aktuelle Art des Datenabrufs
Bevor Sie sich für eine Plattform entscheiden, sollten Sie alle Systeme auflisten, die in Ihren Workflow eingebunden sind, und – ganz wichtig – halten Sie fest, wie Sie die Daten derzeit aus den jeweiligen Systemen beziehen. Ordnen Sie jede Quelle einer von drei Kategorien zu: Sie erstellen einen Bericht im System und laden eine Datei herunter, Sie erhalten einen Export per E-Mail von einer anderen Person oder Sie fragen das System direkt mittels SQL oder API ab.
Diese Klassifizierung ist wichtig, da sie zeigt, was die Konnektoren einer Plattform tatsächlich ersetzen müssen. Eine Quelle der Kategorie 1 oder 2 bedeutet, dass Sie derzeit einen manuellen Abrufschritt haben. Eine Plattform, die sich selbst als „Salesforce-verbunden“ bezeichnet, aber dennoch erfordert, dass Sie einen Salesforce-Bericht planen und die Datei abrufen, hat diesen Schritt nicht überflüssig gemacht, sondern nur verlagert. Was Sie für diese Quellen benötigen, ist eine Live-Verbindung, die bei jeder Ausführung aktuelle Daten ohne Zwischenexport abruft. Prüfen Sie dies, bevor Sie mit der Implementierung beginnen.
In diesem Schritt werden zudem Fragen zum Datenzugriff aufgeworfen – etwa zu Zugangsdaten, Berechtigungen oder Firewall-Regeln –, die sich vor Beginn der Implementierung weitaus einfacher klären lassen als im Nachhinein.
Schritt 5: Erstellen Sie die erste Version schrittweise, nicht alles auf einmal
Sobald die Dokumentation vorliegt, die Logik klassifiziert und die Verbindungen definiert sind, können Sie mit der Umsetzung beginnen. Das Prinzip: Erzielen Sie in jeder Phase eine nachweislich korrekte Ausgabe, bevor Sie den nächsten Schritt hinzufügen.
Stufe 1 ist nur Ihre erste Quelle und Ihr erster Filter- oder Reinigungsschritt. Stellen Sie eine Verbindung zur Quelle her, wenden Sie nur die Logik an, die Sie zuerst in Ihrem manuellen Prozess anwenden würden, und geben Sie sie als Vorschau oder Flatfile aus. Vergleichen Sie die Zeilenanzahl und eine Stichprobe des Datensatzes mit Ihrer manuellen Prozessausgabe für denselben Zeitraum. Sie sollten übereinstimmen. Wenn dies nicht der Fall ist, liegt ein Verbindungs- oder Filterproblem vor. Beheben Sie das Problem, bevor Sie fortfahren.
Fügen Sie dann den nächsten Schritt hinzu. Wenn es sich um eine Verknüpfung handelt, sollten Sie hierfür die meiste Zeit einplanen. Überprüfen Sie die Übereinstimmungsrate. Wenn Ihr manueller Prozess eine Übereinstimmungsrate von 94 % erzielt, sollte dies auch bei der automatisierten Version der Fall sein. Weichen die Werte ab, ist die Verknüpfungslogik noch nicht äquivalent. Häufige Ursachen hierfür sind Probleme mit führenden Nullen bei IDs, unterschiedliche Datumsformate oder eine uneinheitliche Groß-/Kleinschreibung. Lösen Sie zuerst die ID-Normalisierung, überprüfen Sie die Übereinstimmungsrate und bauen Sie dann die nachgelagerten Prozesse auf.
Arbeiten Sie die einzelnen Schritte nacheinander ab. Diese Vorgehensweise wirkt zwar langsamer, als den gesamten Workflow auf einmal zu erstellen, macht die Fehlersuche jedoch wesentlich überschaubarer: Wenn das Ergebnis nicht übereinstimmt, wissen Sie genau, welcher Schritt die Abweichung verursacht hat.
Schritt 6: Führen Sie den Prozess dreimal manuell aus, bevor Sie ihn planen
Bevor Sie einen Workflow planen, führen Sie ihn manuell anhand von drei verschiedenen Datasets aus: den Daten der letzten Woche, der Woche von vor zwei Monaten und einer Woche, in der etwas Ungewöhnliches passiert ist – ein Quartalsende, eine Gebietsänderung, ein Akquisitionsabschluss. Vergleichen Sie jeweils die automatisierte Ausgabe mit Ihrer manuellen Ausgabe.
Dadurch werden Annahmen aufgedeckt, die Sie zwar im Kopf korrekt, im Workflow jedoch fehlerhaft umgesetzt haben. Zu den häufigsten Fehlern gehören: Datumsfilter, die für die aktuelle Woche funktionieren, aber beim Monatswechsel versagen; Verknüpfungslogik, die die meisten Datensätze korrekt verarbeitet, aber eine bestimmte Ausnahmekategorie falsch behandelt; und Ausgabeformatierung, die bei Nullwerten oder unerwarteten Feldlängen zu Problemen führt.
Sobald der Workflow über alle drei Testläufe hinweg eine übereinstimmende Ausgabe erzeugt, wird die Logik validiert. Legen Sie nun den Zeitplan fest. An diesem Punkt ist die erste Automatisierung abgeschlossen – und damit auch der manuelle Prozess, den sie ersetzt hat.
Drei Kriterien, die evaluierungswürdige Plattformen von solchen unterscheiden, die es nicht sind
Der Markt für No-Code- und Low-Code-Daten-Tools ist so weit gewachsen, dass es viele Optionen gibt, die in Demos ähnlich aussehen. Die folgenden Kriterien offenbaren jedoch oft die tatsächlichen Unterschiede, sobald es an die praktische Anwendung geht.
Ob die Datenverbindungen live oder exportabhängig sind
Die häufigste Frustrationsquelle bei ersten Automatisierungsversuchen ist die Erkenntnis, dass der „Salesforce-Konnektor“ einer Plattform einen geplanten Export von Salesforce-Berichten und das anschließende Abrufen der Datei erfordert. Das bedeutet, dass Sie die Datenverarbeitung automatisiert haben, aber nicht den Datenabruf. Der manuelle Schritt, der am meisten Zeit in Anspruch nimmt, bleibt damit oft manuell.
Fragen Sie konkret: Stellt die Plattform eine direkte Verbindung zum Quellsystem her und ruft sie bei jeder Workflow-Ausführung aktuelle Daten ab? Kann sie Abfragen direkt in der Datenbank eines Cloud-Data-Warehouse wie Snowflake oder Databricks ausführen, ohne die Daten vorab in die Plattform übertragen zu müssen? Die Antworten auf diese Fragen bestimmen, ob Sie den Exportschritt tatsächlich eliminieren können oder lediglich verlagern.
Ob die Logik von jemand anderem als der Person, die sie erstellt hat, überprüft werden kann
Eines der Hauptprobleme bei manuellen Workflows besteht darin, dass die zugrundeliegende Logik nur der Person bekannt ist, die sie erstellt hat. Eine Plattform, die eine Tabellenkalkulation durch einen ebenso undurchsichtigen Workflow ersetzt, hat das Problem nicht gelöst, sondern nur verlagert.
Was Sie brauchen, ist ein Workflow, bei dem jeder Transformationsschritt für jede Person mit Zugriff sichtbar, gekennzeichnet und lesbar ist. Audit-Protokolle, die erfassen, welcher Datensatz wann und mit welchen Eingaben ausgeführt wurde. Eine Versionshistorie, die zeigt, was sich zwischen den Ausführungen geändert hat. Das sind keine „ Nice-to-haves “, sondern der Unterschied zwischen einem Workflow, der Ihrem Unternehmen gehört, und einem Workflow, der von einem/einer Data Analyst abhängig ist.
Wer die Logik aktualisieren kann, wenn sich das Geschäft ändert
Dies ist das Kriterium, an dem die meisten Plattformen scheitern. Ein Workflow, der in einem Tool erstellt wurde und für dessen Parameteraktualisierung ein Support-Ticket erforderlich ist, ist nicht von Analysten wartbar – er automatisiert nur die Abhängigkeit, anstatt sie zu eliminieren.
Der Test: Wählen Sie eine Geschäftsregel, die sich in Ihrer Arbeit regelmäßig ändert. Ein Schwellenwert, eine Gebietszuordnung, eine Liste von Ausnahmekonten. Wie würden Sie diese Regel sechs Monate nach Erstellung des Workflows auf einer bestimmten Plattform aktualisieren, wenn die Person, die ihn erstellt hat, das Team verlassen hätte? Wenn die Antwort das Öffnen einer Codedatei oder das Einreichen eines Support-Tickets erfordert, ist das Governance-Modell für die von Analysten verwaltete Logik ungeeignet.
Ein automatisierter Umsatzabgleich: Die sechs Schritte in der Praxis
Der folgende Umsatzabgleich ist in Alteryx One erstellt, aber jede Plattform, die die drei Kriterien im vorherigen Abschnitt erfüllt, würde sie auf die gleiche Weise ausführen.
Wie die manuelle Version aussieht
Jeden Montag exportiert ein Revenue Operations Analyst die abgeschlossenen Opportunitys der Vorwoche als CSV aus Salesforce und erhält per E-Mail einen Oracle-ERP-Rechnungsauszug von der Finanzabteilung. Beide Dateien fließen in eine Master-Abgleichstabelle ein, die im Laufe von zwei Jahren von drei verschiedenen Data Analysts bearbeitet wurde. Die aktuelle Version ist eine Mischung aus der ursprünglichen Struktur und zwei nachträglich eingefügten Anpassungen, die jeweils von der Person vorgenommen wurden, die gerade eine Korrektur durchführen musste.
Ein SVERWEIS gleicht die Datensätze nach Opportunity-ID ab. Die Übereinstimmungsrate liegt in einer guten Woche bei etwa 94 %. Die verbleibenden 6 % landen in einer Spalte für die manuelle Überprüfung, meist deshalb, weil Salesforce Opportunity-IDs mit einer führenden Null speichert, die beim Export in Oracle wegfällt. Die oder der Data Analyst pflegt in Spalte AC eine Referenztabelle, in der die bekannten Abweichungen erfasst sind; neue Fälle werden hinzugefügt, sobald sie entdeckt werden.
Der Schwellenwert von 5 % für die Kennzeichnung von Unstimmigkeiten wurde von jenem -Data Analyst festgelegt, der die ursprüngliche Version erstellt hat. Der aktuelle Analyst kennt die Zahl, aber nicht die Gründe. Sie sind nirgendwo dokumentiert.
Gesamtaufwand in einer Woche ohne Probleme: zweieinhalb bis drei Stunden. Wenn ein Export fehlschlägt oder eine neue Spalte im Salesforce-Bericht angezeigt wird, kommt eine weitere Stunde fürs Debugging hinzu.
Wo das System versagt
Im Zuge einer Umstrukturierung zur Jahresmitte werden 40 Kundenkonten von einem Vertriebsgebiet in ein anderes verlagert. Das Gebietsfeld in Salesforce enthält jetzt Werte, die nicht mit den entsprechenden GL-Segmentcodes in Oracle übereinstimmen. Der SVERWEIS funktioniert zwar weiterhin, gleicht die Daten für diese 40 Konten jedoch auf der falschen Grundlage ab. Die Ausgabe sieht korrekt aus. Die Umsätze der betroffenen Konten werden zwei Berichtszyklen lang dem falschen Segment zugeordnet, bis jemand aus FP&A bemerkt, dass die regionalen Zahlen nicht aufgehen.
Wenn die Untersuchung durchgeführt wird, muss der Analyst, der für den Bericht verantwortlich ist, die Logik mündlich rekonstruieren, um zu erklären, was schiefgelaufen ist. Das Problem ist nicht, dass er einen Fehler gemacht hat, sondern dass die Abgleichslogik auf einer strukturellen Annahme über die Zuordnung von Gebieten zu Segmenten aufgebaut war, die nie als Regel niedergeschrieben wurde. Es gab schlicht keine Möglichkeit, diese festzuhalten.
Wie derselbe Workflow nach Automatisierung ausgeführt wird
Schritt 1 hat diesen Workflow als idealen ersten Kandidaten identifiziert: eine feste wöchentliche Kadenz, ein konsistentes Ausgabeformat, eine einzelne verantwortliche Person, die auch die Geschäftslogik steuert. In Schritt 2 wurde die Prozessdokumentation erstellt, einschließlich des ID-Konfliktproblems und der Ausnahme-Referenztabelle. In Schritt 3 wurden der Schwellenwert für Abweichungen sowie die Zuordnung von Gebieten zu Segmenten als Logik eingestuft, die auf menschlicher Einschätzung beruht und explizit definiert werden musste. Beide wurden als benannte Parameter angelegt. Schritt 4 hat bestätigt, dass Alteryx Designer über Live-Konnektoren zu Salesforce und Oracle verfügt, die aktuelle Daten abrufen, ohne dass Exportdateien erforderlich sind.
Der erstellte Workflow stellt über native Konnektoren eine direkte Verbindung zu Salesforce und Oracle her. Der Schritt zur ID-Normalisierung behandelt die Problematik führender Nullen als konfigurierte Transformation. Die Region-zu-Segment-Zuordnung befindet sich in einer Referenztabelle, die innerhalb des Workflows verwaltet wird und bei jeder Änderung versioniert wird. Der Schwellenwert für Abweichungen von 5 % ist als benannter Parameter am Anfang des Workflows hinterlegt – sichtbar, mit einem Hinweis dokumentiert, der seinen Ursprung erklärt, und der von jeder/jedem Data Analyst mit Zugriff geändert werden kann. Die Ausgabe geht an Snowflake und löst eine E-Mail an die Verteilerliste aus. Zeitplan: montags, 7:00 Uhr.
Bei einer Umstrukturierung aktualisiert die/der Data Analyst die Zuordnungstabelle für Gebiete und Segmente. Zeitaufwand: Fünfzehn Minuten. Der Workflow wird am Montag ordnungsgemäß ausgeführt. Wenn FP&A fragt, warum sich die Segmentzuweisungen verschoben haben, ist die Antwort ein mit einem Zeitstempel versehenes Änderungsprotokoll im Workflow, keine mündliche Rekonstruktion.
Schritt 6 (drei Testläufe vor der Planung) hat ein Problem aufgedeckt: Der Datumsfilter verwendete eine „Letzte 7 Tage“-Logik, die am Montag und am Dienstag unterschiedliche Ergebnisse lieferte, da Salesforce für Abschlüsse, die am Sonntagabend getätigt werden, spezifische Zeitstempel vergibt. Der Fehler wurde bereits in der Testphase behoben, anstatt erst im Live-Betrieb entdeckt zu werden.
Der oben beschriebene Workflow ist ein typisches Beispiel dafür, wie eine erste Automatisierung in der Praxis aussieht. Wenn Sie diesen Ansatz mit Ihrem eigenen Prozess testen möchten, können Sie Alteryx One kostenlos testen – ganz ohne Einrichtungsaufwand.
Der richtige Ausgangspunkt: ein Workflow, von dem Sie bereits wissen, dass er optimiert werden muss
Die sechs oben genannten Schritte funktionieren am besten, wenn sie auf einen Prozess angewendet werden, den Sie bereits als fehlerhaft oder ineffizient identifiziert haben. Dabei geht es nicht um die komplexeste Aufgabe Ihres Teams, sondern um die mühsamste. Jener Prozess, bei dem die Antwort auf die Frage „Was würde passieren, wenn Sie zwei Wochen ausfallen?“ lautet: „Jemand müsste ihn von Grund auf neu erstellen, und das Ergebnis wäre wahrscheinlich nicht ganz korrekt.“
Drei Fragen, um Ihren ersten Workflow zu finden: Welcher Prozess erfordert den größten Aufwand für eine Neuerstellung, wenn sich vorgelagerte Schritte ändern? Welcher hängt am stärksten vom Wissen einer einzelnen Person ab? Bei welchem wurde ein falscher Wert erzeugt, ohne dass es jemand bemerkte, bis es für eine saubere Korrektur bereits zu spät war? Der Workflow, der in all diesen Punkten am schlechtesten abschneidet, sollte als erstes automatisiert werden.
Arbeiten Sie den Schritt der Dokumentation ab, bevor Sie irgendein Tool öffnen. Allein dieser Schritt – das schriftliche Festhalten jedes einzelnen Arbeitsschritts von der ursprünglichen Datenquelle bis zum Endergebnis – offenbart meist, dass der Prozess entweder schneller zu automatisieren ist als erwartet oder aber anfälliger ist, als zunächst angenommen. Beides ist gut zu wissen.
Wenn Sie überlegen, ob Alteryx One die richtige Plattform für diese Arbeit ist, ist die kostenlose Testversion die direkteste Möglichkeit, sie anhand Ihrer eigenen Daten und Ihres eigenen Prozesses zu testen. Für die Testversion benötigen Sie keine Unterstützung der IT-Abteilung, und der Workflow, den Sie in Schritt 2 dokumentiert haben, dient bereits als fertige Spezifikation für Ihre erste Umsetzung.
Sollte es aktuell wichtiger sein, intern einen Konsens zu erzielen, anstatt eine Testphase zu durchlaufen, empfiehlt sich das Analytics Maturity Assessment von Alteryx. Es liefert Ihnen einen Bericht mit Bewertung und Vergleichswerten zu ähnlichen Unternehmen – eine wertvolle Grundlage für Gespräche über den Business Case und die Frage, wo Investitionen in Automatisierung am ehesten messbare Returns versprechen.