Fragt man einen Data Analyst, warum die monatliche Abweichungsanalyse so lange dauert, nennen die meisten denselben Grund: Niemand im Team kann programmieren. Die Lösung scheint auf der Hand zu liegen: Man lernt Python, eignet sich SQL-Kenntnisse an oder wartet darauf, dass ein Data Engineer Zeit hat. Doch diese Ansätze beheben das eigentliche Problem meist nicht. Die Erstellung des Berichts dauert Tage, weil die Schritte zur Umwandlung eines Hauptbuch-Exports in den fertigen Bericht nirgendwo dokumentiert sind. Sie existieren lediglich im Gedächtnis eines Data Analysts, in einem Ordner voller Tabellen und in SVERWEIS-Formeln, die in jedem Zyklus neu erstellt werden müssen. Der Prozess wurde nie so festgehalten, dass eine Maschine ihn wiederholen könnte – und das hat nichts mit Programmieren zu tun.
Genau hier liegt die Falle, in die viele erfahrene Data Analysts tappen. Sie beherrschen SQL gut genug, um die benötigten Daten abzurufen. Sie kennen sich mit Excel gut genug aus, um sie vorzubereiten. Was jedoch fehlt, ist eine Möglichkeit, diese Arbeit als wiederkehrenden Prozess statt als einmalige Aufgabe zu speichern. Die Folge: Man baut alles jeden Monat, bei jedem Monatsabschluss und in jedem Berichtszyklus neu auf – und der Zeit- und Kostenaufwand summiert sich immer weiter.
Code definiert keine Pipeline
Eine Daten-Pipeline ist eine wiederholbare Abfolge von Schritten: Daten abrufen, bereinigen, aufbereiten und an einen nützlichen Ort senden. Was sie zu einer Pipeline macht, ist, dass diese Schritte jedes Mal auf die gleiche Weise ausgeführt werden, ohne dass jemand jeden Schritt manuell von Hand wiederholen muss. Code ist eine Möglichkeit, diese Logik zu erfassen. Ein visueller No-Code-Arbeitsbereich ist eine weitere. Ob dabei ein Skript zum Einsatz kommt, spielt keine Rolle. Es kommt darauf an, ob die Logik einmalig in einer Form erfasst wird, die das Team erneut ausführen, prüfen und weitergeben kann. Sowohl eine dreitägige manuelle Aufbereitung in Excel als auch ein zweiminütiger automatisierter Durchlauf können exakt dieselben Daten durch exakt dieselben Transformationsschritte führen. Der einzige Unterschied besteht darin, wo die Logik verankert ist.
Die Methode: Erstellen einer Pipeline, ohne ein Skript zu schreiben
Die folgenden Schritte beschreiben einen beispielhaften Prozess, der unabhängig von einem bestimmten Tool ist. Es handelt sich dabei um dieselben fünf Schritte, ganz gleich, ob die Pipeline letztlich als Skript oder auf einem visuellen Arbeitsbereich erstellt wird.
Schritt 1: Stellen Sie eine direkte Verbindung zum Speicherort der Daten her
Anstatt jemanden aus der Buchhaltung zu bitten, das Hauptbuch in eine CSV-Datei zu exportieren und per E-Mail zu versenden, stellen Sie eine direkte Verbindung zur Quelle her (Datenbank, gemeinsam genutztes Laufwerk oder Cloud-Speicherort), sodass dieselbe Verbindung bei jedem Durchlauf ohne manuelles Eingreifen ausgeführt wird. Mit einem Eingabedaten-Tool können Sie beispielsweise einmalig einen Dateityp, eine Datenbank oder ein Platzhaltermuster festlegen – etwa „alle Dateien, die der Namenskonvention des aktuellen Monats entsprechen“ – und diese Verbindung dauerhaft nutzen.
Schritt 2: Erfassen Sie die Bereinigungslogik einmalig
Data Analysts verbringen den Großteil ihrer Zeit damit, Leerzeichen aus Kontocodes zu entfernen, Währungsformate zu standardisieren, und zu entscheiden, was mit einer leeren Zelle im Vergleich zu einem echten Nullwert zu tun ist – und das alles manuell. Ein Datenbereinigungsschritt wandelt diese Entscheidungen in eine Konfiguration um, die einmalig festgelegt wird, um Nullwerte zu behandeln, die Groß-/Kleinschreibung zu vereinheitlichen und mehr. So muss niemand diese Schritte bei jedem Monatsabschluss aus dem Gedächtnis heraus neu durchführen.
Schritt 3: Standardisieren Sie die Struktur, bevor sie weitergegeben wird
Quellsysteme ändern Feldnamen, fügen Spalten hinzu oder verschieben einen Datentyp ohne Vorwarnung. Anstatt davon auszugehen, dass die eingehende Datei immer gleich aufgebaut ist, sollten Sie die Spaltenauswahl und Datentypen explizit steuern und die Feldgrößen automatisch an die Daten anpassen lassen. Diese Maßnahmen verhindern, dass die Datenpipeline nach einigen Monaten ausfällt.
Schritt 4: Planen Sie die Ausführung, damit sich niemand daran erinnern muss, sie zu starten
Eine Pipeline, bei der jeden Monat jemand eingreifen muss, um sie zu öffnen und auf „Ausführen“ zu klicken, ist zwar organisiert, aber nicht automatisiert. Durch Planung wird der Prozess zu einem Ablauf, der eigenständig und in einem von Ihnen festgelegten Rhythmus funktioniert.
Schritt 5: Versionieren und überwachen Sie sie wie eine Infrastruktur, nicht wie eine persönliche Datei
Sobald die Pipeline eigenständig läuft, darf sie nicht mehr nur die Datei einer einzelnen Person sein. Das bedeutet, sie muss an einem für das Team zugänglichen Ort liegen, über eine nachvollziehbare Änderungshistorie verfügen und so gestaltet sein, dass auch andere Personen – nicht nur der/die ursprüngliche Ersteller:in – sie öffnen und die einzelnen Schritte verstehen können. Genau so wird aus dem Workflow einer Einzelperson ein Prozess, auf den sich das Team verlassen kann, unabhängig davon, wer gerade nicht im Büro ist.
Häufige Fehlerquellen im laufenden Betrieb
Der häufigste Fehler liegt in der Annahme, „No-Code“ bedeute, dass man nicht mehr nachdenken müsse. Ein Beispiel hierfür ist der so genannte Schema-Drift: Wenn eine vorgelagerte Stelle eine Spalte umbenennt, schlägt eine Pipeline, die auf den alten Namen ausgelegt ist, entweder fehl oder verwirft das Feld. Auch beim Abgleich von Dateinamen mittels Platzhaltern kann die falsche Datei erfasst werden, wenn Exporte aus verschiedenen Monaten demselben Namensschema folgen. Zudem kann eine einmal eingerichtete und danach nie wieder überprüfte Pipeline unbemerkt auf Dauer mit fehlerhafter Logik weiterlaufen, da keine erneute Überprüfung durchgesetzt wird, anders als bei einem manuellen Prozess, bei dem jemand bemerken muss, dass etwas nicht stimmt.
Eine weitere Art von Fehler, die leicht übersehen wird, ist der stille Erfolg. Eine geplante Pipeline, die pünktlich läuft, aber eine leere oder unvollständige Datei verarbeitet, meldet den Auftrag als erfolgreich abgeschlossen, ohne Fehlermeldung. Und niemand schaut bei einem grünen Häkchen zweimal hin. Eine einfache Überprüfung der Zeilenanzahl oder eine Nullwert-Prüfung direkt in die Pipeline zu integrieren, sodass bei ungewöhnlich geringem Output ein Hinweis erfolgt, anstatt den Vorgang einfach stillschweigend abzuschließen, ist eine kostengünstige Absicherung. Bei manuellen Prozessen ist dies quasi automatisch gegeben, da einem Menschen bei der Bearbeitung meist auffällt, wenn eine Datei fehlerhaft wirkt, noch bevor die Arbeit abgeschlossen ist.
Dies spiegelt einen umfassenderen Wandel wider, den Branchenanalyst:innen beobachten: Da Pipeline-Architekturen zunehmend statische, einmalige ETL-Jobs ablösen, verlagert sich der Fokus bei der Datenqualität weg von einem einzelnen Bereinigungsschritt hin zu einem kontinuierlichen, anpassungsfähigen Prozess. Die Pipeline funktioniert auch dann weiter, wenn sich die Quelldaten selbst fortlaufend ändern.
Eine fertige Pipeline vs. einem Prozess, der jeden Monat neu erstellt werden muss
Nehmen wir den oben erwähnten Abweichungsbericht: Bei einer manuellen Neuerstellung hängt der Prozess davon ab, dass sich ein Analyst daran erinnert, dass eine Shared-Services-Einheit ihren konzerninternen Eliminierungsposten aufgrund eines Zeitunterschieds zum Regionalbüro, über das sie berichtet, stets einen Tag später bucht – ein Workaround, der nur im Kopf dieses Analysten existiert. Wird der Prozess hingegen als Pipeline abgebildet, so wird diese Anpassung zu einem dokumentierten Schritt, den jedes Teammitglied einsehen, hinterfragen und optimieren kann. Die Erstellung des Berichts, die früher Tage in Anspruch nahm, dauert nun nur noch Minuten. Der nachhaltigere Vorteil besteht darin, dass die Geschäftslogik auch dann erhalten bleibt, wenn der/die ursprüngliche Ersteller:in nicht mehr zur Verfügung steht. Genau das gibt einem/einer Controller:in die nötige Sicherheit, Zahlen abzuzeichnen, die teilweise durch Automatisierung zustande gekommen sind.
Stellt man beide Ansätze gegenüber, zeigt sich, dass der Unterschied weit über den Geschwindigkeitsvorteil hinausgeht. Es geht vielmehr darum, ob der Prozess auch dann Bestand hat, wenn jemand krankheitsbedingt ausfällt, die Rolle wechselt oder schlichtweg einen Arbeitsschritt vergisst, der erst in einigen Zyklen wieder ansteht:
| Dimension | Jeden Monat neu erstellt | Als Pipeline erfasst |
|---|---|---|
| Zeit pro Zyklus | Stunden bis Tage, jedes Mal komplett neu erstellt | Minuten, wird nach einem Zeitplan ausgeführt |
| Konsistenz | Hängt davon ab, wer ihn neu erstellt und was dabei berücksichtigt wird | Dieselben Schritte, dieselbe Reihenfolge, bei jedem Durchlauf |
| Überprüfbarkeit | Die Logik steckt im Kopf einer Person und in Vielzahl von Formeln | Logik ist eine sichtbare, dokumentierte Sequenz, die jeder öffnen kann |
| Übergabe | Mühsam; ein neuer Analyst beginnt mit einem leeren Tabellenblatt von vorn | Unkompliziert; jede Person im Team kann die Schritte lesen |
Code ist in einigen speziellen Fällen weiterhin die bessere Wahl
Nichts davon macht eine codebasierte Pipeline zur falschen Wahl – es kommt lediglich darauf an, was die Pipeline leisten muss. Ein visueller No-Code-Ansatz eignet sich gut für die Art von Prozessen, mit denen die meisten Data Analysts zu tun haben, wie z. B. Verknüpfungen, Filter, Bereinigung, Aggregation und geplante Ausführungen für eine überschaubare Anzahl von Quellen. Python, dbt oder eine von Data Engineers gepflegte Pipeline ist die bessere Wahl, wenn die Logik komplexe rekursive Berechnungen oder eine sehr groß angelegte verteilte Verarbeitung erfordert oder wenn das Team dieselben Git-basierten Verfahren zur Versionskontrolle und Code-Überprüfung nutzen möchte, die auch in der übrigen Engineering-Organisation üblich sind. Die entscheidende Frage ist meist, wie komplex die Transformation ist und wer sie im Team künftig noch pflegen muss, nicht eine grundsätzliche Präferenz für den einen oder anderen Ansatz.
Interne Argumentation für eine kontrollierte Pipeline
Antizipieren Sie die Erwartungen und Bedenken der IT und bereiten Sie sich entsprechend vor. Die Berichterstattung über „Citizen Development“ zeigt, dass Fachanwender:innen eigene Workflows schneller erstellen und skalieren, als die IT Governance- und Integrationskontrollen implementieren kann. Ein Ansatz, bei dem die IT diese Entwicklung weitgehend sich selbst überlässt, birgt reale Risiken, sobald diese Workflows skaliert oder mit anderen Systemen verbunden werden müssen. Genau deshalb sind die Fragen zu Versionierung und Zugriff im fünften Schritt so entscheidend, wenn sich eine Pipeline von einer persönlichen Arbeitserleichterung zu einem geschäftskritischen Prozess entwickelt.
Um eine Pipeline genehmigen zu lassen, müssen mehrere Stakeholder überzeugt werden. Die IT möchte wissen, wer auf die Verbindungs-Anmeldedaten zugreifen kann, ob ein Versionsverlauf vorhanden ist und wie der Workflow überprüft wird, bevor er auf Produktionsdaten zugreift – dieselben Fragen, die sie bei jedem Prozess stellen würden, der planmäßig Daten aus einem Produktionssystem liest. Führungskräfte im Finanz- oder Betriebsbereich legen mehr Wert auf Konsistenz. Sie möchten wissen, ob diese Pipeline jeden Monat auf die gleiche Weise das gleiche Ergebnis liefern kann und ob jemand anderes als der/die Ersteller:in erklären kann, wie sie funktioniert. Argumentieren Sie bei Ihrem Pitch mit Prüfbarkeit und Konsistenz, nicht nur mit der Zeitersparnis, um beide Zielgruppen zu überzeugen. Ein/e Controller:in, der/die automatisierte Zahlen abzeichnet, möchte wissen, ob der Prozess vertrauenswürdig ist, bevor er/sie sich dafür interessiert, wie viele Stunden dadurch eingespart wurden.
Beginnen Sie mit einer einzelnen Pipeline, nicht mit einem Programm
Der Fehler, den Teams machen, besteht darin, zu versuchen, alles auf einmal zu automatisieren, was normalerweise ins Stocken gerät, bevor überhaupt etwas bereitgestellt wird. Wählen Sie den einen wiederkehrenden Bericht aus, dessen manuelle Neuerstellung in jedem Zyklus den größten Zeitaufwand verursacht. Sorgen Sie dafür, dass er zuverlässig läuft, zeigen Sie dem Team, was sich geändert hat, und lassen Sie dieses erste Ergebnis für sich sprechen, um die Argumente für den nächsten Schritt zu liefern. Eine Pipeline, die einen Bericht zuverlässig verarbeitet, ist mehr wert als eine Roadmap für die Automatisierung von zehn Berichten.
Wenn Sie den Ansatz mit Ihrem eigenen wiederkehrenden Bericht testen möchten, können Sie eine kostenlose Testversion von Alteryx One beginnen und ihn anhand Ihrer eigenen Daten erstellen.