Das Cloud Data Warehouse löste das Speicherproblem. Die meisten Unternehmen, die ein solches System erwarben, erhielten genau das, wofür sie bezahlt hatten: zentralisierte Daten, bessere Abfrageleistung und eine moderne Grundlage für Analysen. Was damit nicht gelöst wurde, war das Workflow-Problem. Die Berichte, die für das Unternehmen am wichtigsten sind, werden immer noch manuell von derselben Analystin im selben Zyklus zusammengestellt, wobei dasselbe Flickwerk aus Exporten und Tabellenkalkulationen wie zuvor verwendet wird.
Diese Lücke ist der Engpass, um den es in diesem Beitrag geht. Eine 2024 von Informatica unter 300 IT- und Datenfachleuten durchgeführte Umfrage ergab, dass der Aufbau einer einzigen Daten-Pipeline bis zu 12 Wochen dauert, und 78 % der Teams berichten von anhaltenden Herausforderungen bei Datenorchestrierung und Tool-Komplexität. Das Data Warehouse ist voll. Die Pipeline, die die Berichte speist, auf die das Unternehmen wartet, arbeitet immer noch in menschlicher Geschwindigkeit.
In diesem Beitrag wird erklärt, was Augmented Analytics ist und was es konkret löst, warum der Engpass selbst mit guten Tools bestehen bleibt, wie Daten Schicht für Schicht durch einen Augmented Analytics Stack fließen und wie ein auf Geschwindigkeit ausgelegter Workflow in der Praxis aussieht.
Was ist Augmented Analytics?
Augmented Analytics ist die Anwendung von KI und Machine Learning zur Automatisierung des Analyse-Workflows – von der Datenvorbereitung bis zur Bereitstellung von Erkenntnissen –, sodass Erkenntnisse automatisch erfasst werden, anstatt darauf zu warten, dass ein Analyst sie zusammenstellt. Der Begriff stammt aus einer Studie von Gartner aus dem Jahr 2017 und hat sich seitdem zu einer Kernkompetenzkategorie für Analyseplattformen entwickelt.
Was genau damit gelöst wird, ist weniger bekannt als das, was es ist. Ziel ist die Beseitigung struktureller Ineffizienzen vor jedem Diagramm: die manuelle, von Data Analysts abhängige Pipeline, die jede Erkenntnis durchläuft, bevor ein/e Benutzer:in im Unternehmen darauf reagieren kann. Eine Gartner-Umfrage aus dem Jahr 2024 unter 403 Analyse- und KI-Verantwortlichen ergab, dass mehr als die Hälfte bereits KI-Tools für automatisierte Erkenntnisse und Abfragen in natürlicher Sprache verwendet. Die Infrastruktur ist vorhanden. Das Problem liegt im Engpass, den diese Daten überwinden müssen.
Warum Reporting-Workflows so langsam sind – selbst mit den richtigen Tools
Den meisten Analyseteams mangelt es nicht an Tools. Sie haben eine BI-Plattform, Cloud-Datenspeicher und möglicherweise ein Data Warehouse, dessen Aufbau achtstellige Beträge gekostet hat. Trotzdem ist das Reporting schleppend, und der Grund dafür ist struktureller Natur: Der Engpass liegt vor den Dashboards, in einer Ebene, die von diesen Tools nicht berührt wird.
Drei Fehlerquellen verursachen den größten Teil der Verzögerung:
- Fragmentierte Quelldaten, die in jedem Zyklus manuell neu zusammengestellt werden müssen. Ein wöchentlicher Umsatzbericht, der Daten aus einem CRM-System, einem ERP-System und einer regionalen Excel-Datei bezieht, erfordert, dass diese drei Quellen jedes Mal manuell verknüpft werden. Die Verknüpfungslogik ist nicht wiederholbar gespeichert. Sie befindet sich im Prozess des Analysten, wird aus dem Gedächtnis oder anhand der Datei der Vorwoche neu erstellt und funktioniert nicht mehr, sobald ein Quellsystem einen Feldnamen ändert oder ein Exportformat anpasst.
- Geschäftslogik, die nur in den Köpfen der Mitarbeiter:innen existiert. Die meisten Reporting-Workflows beinhalten eine Interpretationsebene, die nur dem Analysten bekannt ist: beispielsweise die für den CFO anders gerundeten Schwellenwerte, die Regionszuordnung, die nicht mit den CRM-Feldnamen übereinstimmt, oder die nach einem schlechten Quartal hinzugefügte Ausnahmeregel, die nie dokumentiert wurde. Wenn dieser Analyst nicht anwesend ist, wird der Bericht nicht ausgeführt. Mit seinem Ausscheiden geht auch die entsprechende Logik verloren.
- Das Problem der Aufbereitung im letzten Schritt. Selbst nachdem die Daten vorbereitet und analysiert wurden, muss noch jemand die Ergebnisse formatieren, die Zusammenfassung verfassen, die Präsentationsfolie erstellen und die E-Mail versenden. Bei fünf Berichtstypen kann ein Analyst das noch bewältigen. Bei 40 Berichtstypen für 12 Stakeholder ist die Belastungsgrenze schnell erreicht.
Ein Prozess, der bei geringem Volumen funktioniert, bricht unter der Last des operativen Geschäfts zusammen. Der Bedarf des Unternehmens an häufiger Berichterstattung – von wöchentlichen zu täglichen Berichten, von Ad-hoc-Anfragen, die sich für ein festes Team häufen – verstärkt all diese Schwachstellen gleichzeitig.
Fragen Sie sich, wie viel Zeit Ihr Team für die Erstellung des Berichts aufwendet und wie viel Zeit es tatsächlich für die Umsetzung der Ergebnisse benötigt. Genau hier setzt die Wertschöpfung durch Augmented Analytics an.
Warum Ihre bestehenden BI-Investitionen den Engpass nicht beheben
Naheliegend ist zunächst, eine bessere Visualisierungsebene hinzuzufügen: ein ausgefeilteres Dashboard oder ein Self-Service-Portal für Stakeholder. Diese Verbesserungen machen Erkenntnisse anschaulicher. Sie reduzieren jedoch nicht den manuellen Aufwand für die Erstellung der zugrunde liegenden Daten.
BI-Tools befinden sich am Ende der Analyse-Pipeline. Sie stellen aufbereitete Daten als Diagramme und Zusammenfassungen dar. Die vorgelagerte Pipeline – Datenabruf, Verknüpfung, Qualitätsprüfung, Anwendung von Geschäftsregeln – findet weiterhin außerhalb des BI-Tools statt, in Tabellenkalkulationen oder von Data Analysts gepflegten Skripten, ohne Automatisierung und ohne Prüfpfad.
Das Governance-Problem entsteht, wenn dies zu einem Geschäftsrisiko und nicht nur zu einem Effizienzproblem wird. Wenn sich die Berichtslogik in einem persönlichen Tabellenkalkulationsprozess befindet, hat die IT keinen Einblick, welche Daten welches System verlassen haben, wie sie transformiert wurden oder ob die Entscheidung des CFO im letzten Quartal auf derselben Berechnungsmethode wie in diesem Quartal basierte. Wenn der Analyst, der den Prozess entwickelt hat, an dem Tag kündigt, an dem der Vorstandsbericht fällig ist, gibt es keine dokumentierte, wiederholbare Alternative.
Was benötigt wird, ist eine Workflow-Ebene: ein Ort, an dem die Berichtslogik einmal codiert, verwaltet, versioniert und automatisch ausgeführt wird. Workflow-Automatisierung ist der Mechanismus. Analytics Automation ist die Architektur. Das BI-Tool bleibt unverändert. Was sich ändert, ist der anfällige, undokumentierte Prozess, der es speist.
Um genauer zu verstehen, wo BI-Engpässe strukturell ihren Ursprung haben, zeigt diese Aufschlüsselung die Muster auf, die branchenübergreifend und unabhängig von der verwendeten BI-Plattform konsistent auftreten.
Wie Daten durch eine Augmented-Analytics-Stack fließen
Jeder manuelle Berichts-Workflow durchläuft vier Phasen zwischen Quellsystem und Geschäftsentscheidung. Der Unterschied zwischen langsam und schnell besteht darin, ob jede Phase automatisiert und gesteuert oder manuell und fragil ist.
Ebene 1: Konnektivität – Daten vom Speicherort zum Verarbeitungsort bringen
Die Daten eines typischen Berichts-Workflows befinden sich gleichzeitig in mehreren Systemen: einem CRM-System zur Erfassung von Kundenaktivitäten, einem ERP-System zur Erfassung von Finanztransaktionen, einem Cloud Data Warehouse zur Speicherung transformierter Daten und üblicherweise einer Sammlung von Excel-Dateien auf Abteilungsebene, die nicht vollständig aktualisiert wurden. Bevor eine Analyse erfolgen kann, müssen die Daten aus diesen Quellen in einem nutzbaren Format in derselben Umgebung vorliegen.
In einem manuellen Workflow umfasst dieser Schritt geplante Exporte, Dateidownloads und die Übergabe per E-Mail. Er ist zeitaufwendig und für die IT nicht sichtbar. Ein Update des Quellsystems unterbricht den Export unbemerkt. Die Analystin bemerkt den Fehler erst am Montagmorgen.
In einem Augmented-Analytics-Stack rufen native Konnektoren Daten nach einem definierten Zeitplan oder durch einen Trigger direkt aus Quellsystemen ab. Die Verbindungslogik wird einmal konfiguriert. Wenn ein Quellsystem sein Schema ändert, signalisiert die Plattform eine Schemaabweichung, anstatt eine fehlerhafte Ausgabe zu erzeugen. Die Analystin korrigiert die Zuordnung an einer zentralen Stelle.
Die entscheidende Frage lautet: Verbindet sich die Plattform nativ mit den spezifischen Systemen, die Ihre Workflows nutzen – nicht nur mit Cloud-nativen Data Warehouses, sondern auch mit CRM-, ERP- und SaaS-Anwendungen, aus denen die Geschäftsdaten stammen? Plattformen, die für gängige Unternehmensanwendungen individuell entwickelte Konnektoren benötigen, führen bereits im ersten Schritt zu einer Abhängigkeit von der Softwareentwicklung.
Ebene 2: Vorbereitung und Transformation – o die meiste manuelle Zeit verbracht wird
Auf dieser Ebene finden die Datenvorbereitung und -transformation statt: Daten aus verschiedenen Quellen werden zusammengeführt, Feldformate standardisiert, Geschäftsregeln angewendet, abgeleitete Metriken berechnet und die Qualität vor der Analyse validiert. Hierauf entfällt auch der Großteil der 12-wöchigen Pipeline-Aufbauzeit aus der Informatica-Umfrage – nicht auf die Datenübertragung selbst, sondern auf die Kodierung der Logik, die die Daten formt.
Diese Logik ist größtenteils unkompliziert, sobald man den Geschäftskontext versteht. Das Problem ist die fehlende Dokumentation. Geschäftsregeln existieren als implizites Wissen: Der Analyst weiß, dass das Feld „Region“ in Salesforce Abkürzungen verwendet, die nicht mit denen in Oracle übereinstimmen, und wendet die Zuordnung wöchentlich manuell an. Die Logik ist korrekt, aber unsichtbar und nicht übertragbar.
In einem Augmented-Analytics-Stack wird die Transformationslogik visuell als wiederverwendbarer Workflow erstellt. Die Verknüpfungen, die Feldzuordnungen, die Ausnahmeregeln und die Qualitätsprüfungen werden einmalig definiert und bei jedem Durchlauf konsistent angewendet. Wenn sich die Geschäftslogik ändert – beispielsweise durch Hinzufügen einer neuen Region oder Aktualisieren einer Metrikdefinition –, wird die Änderung im Workflow vorgenommen und versioniert. Jeder vorherige Durchlauf ist nachvollziehbar.
Die zentrale Frage für diese Ebene lautet: Können die Data Analyts, die die Geschäftslogik verstehen, die Transformations-Workflows selbst erstellen und pflegen? Plattformen, die SQL oder Python zur Datenvorereitung benötigen, führen den technischen Engpass an einer anderen Stelle erneut ein.
Ebene 3: Erkenntnisgenerierung – relevante Informationen automatisch aufdecken
Aufbereitete Daten in einem Data Warehouse liefern noch keine Erkenntnis. Sie müssen weiterhin abgefragt, visualisiert und interpretiert werden. In einem manuellen Workflow entstehen so Erkenntnisse, die die Fragen der Analystin beantworten und so formuliert sind, wie sie sie formuliert hat.
Augmented Analytics verändert diese Beziehung grundlegend. Anstatt dass ein Analyst die Daten abfragt, scannt die Plattform kontinuierlich aufbereitete Daten nach Mustern, die Aufmerksamkeit erfordern: eine Kennzahl, die ihren historischen Bereich verlässt, ein Segment, das sich anders als vergleichbare Segmente entwickelt, ein Trend, der sich über drei Wochen aufgebaut hat, aber noch keinen manuell festgelegten Schwellenwert überschritten hat. Diese Muster werden automatisch in natürlicher Sprache angezeigt und nach statistischer Signifikanz geordnet.
Gartner beschreibt dies als automatisierte Erkenntnisse – eine Funktionalität, die über die Hälfte der Ende 2024 befragten Führungskräfte im Bereich Analytics und KI bereits nutzen oder implementieren. Das Ergebnis ist eine direkte Antwort: Was ist passiert, warum ist es passiert und welche Segmente sind dafür verantwortlich?
Die entscheidende Frage auf dieser Ebene lautet: Generiert die Plattform proaktiv Erkenntnisse oder wartet sie auf Nutzeranfragen? Self-Service-Analytics, mit dem Geschäftsanwender:innen Daten selbstständig erkunden können, ist hilfreich. Die automatisierte Bereitstellung von Erkenntnissen, die keine spezifischen Suchkriterien voraussetzt, überwindet den letzten Engpass.
Ebene 4: Bereitstellung – Erkenntnisse zu den Menschen bringen, die damit handeln
Fragen Sie sich, ob die Erkenntnisse Ihrer aktuellen Technologie die Stakeholder ohne Beteiligung von Data Analysts erreichen. In den meisten Organisationen lautet die Antwort: Nein. Ein Data Analyst formatiert einen Bericht, verfasst eine Managementzusammenfassung, hängt ihn an eine E-Mail an und sendet diese an einen Verteiler. Der Zeitpunkt hängt davon ab, wann der Analyst seine Arbeit beendet. Fällt der Analyst aus, entfällt dieser Schritt.
In einem Augmented-Analytics-Stack erfolgt die Bereitstellung automatisiert und gesteuert. Berichte werden planmäßig ausgeführt. Narrative Zusammenfassungen werden automatisch erstellt und versendet. Stakeholder erhalten Erkenntnisse, auf die sie reagieren können – direkt in ihrem Posteingang oder in einer gemeinsamen Umgebung, ohne auf die Aufbereitung durch einen Analysten warten zu müssen.
Wie dies als vernetzter Stack aussieht
Vier Ebenen. Eine geregelte Umgebung. Das ist die Anforderung, auf die die obige Diagnose hinweist. Die Aufteilung des Stacks auf separate Tools – eines für die Vernetzung, eines für die Transformation und eines für die Bereitstellung – führt zu den Audit-Lücken und manuellen Übergaben, die die Architektur eigentlich beseitigen soll. Jede Integration zwischen Tools birgt die Gefahr von Datenlücken, die das Eingreifen eines Data Analyst erfordern.
Alteryx One ist genau dafür konzipiert: Eine Snowflake- oder Databricks-Umgebung liefert die Daten in großem Umfang und Alteryx One übernimmt die Transformationslogik, die nicht von der Datenplattform abgedeckt wird – Geschäftsregeln, Feldzuordnungen und Ausnahmebehandlung – sowie die automatisierte Generierung von Erkenntnissen und die termingerechte Bereitstellung an die Stakeholder. Die bereits eingesetzten BI-Tools Tableau, Power BI und Oracle bleiben für die Datenexploration und -visualisierung erhalten. Augmented Analytics schließt die Lücke zwischen Data Warehouse und Dashboard sowie die Lücke zwischen Dashboard und Entscheidungsfindung.
Die vier Ebenen in einem realen Workflow: Vorher und Nachher
Eine Analystin im Bereich Revenue Cycle Management eines regionalen Gesundheitssystems erstellt wöchentlich einen Bericht über die Bearbeitungsdauer von Leistungsanträgen: wie lange die einzelnen Kostenträgerkategorien für die Bearbeitung eingereichter Anträge benötigen und wo sich die Rückstände aufbauen. Die Eingaben sind ein Epic-Export, eine Datei des Clearinghouse (der Abrechungsstelle) und eine vom Vertragsteam gepflegte Tabelle mit Kostenträgerverträgen. eden Montag lädt die Analystin alle drei Daten herunter, normalisiert die Kostenträgercodes manuell (das Clearinghouse verwendet für bestimmte Leistungsarten eine andere Taxonomie als Epic – eine Diskrepanz, die bisher nicht dokumentiert wurde), führt sie in Excel zusammen, berechnet die Kennzahlen zur Bearbeitungsdauer und sendet eine formatierte Zusammenfassung per E-Mail an vier Abteilungsleiter:innen. Insgesamt braucht sie dafür fünf bis sechs Stunden. Der Bericht kommt etwa jeden vierten Montag verspätet an, meist weil die Datei des Clearinghouse in einem anderen Format als erwartet vorliegt.
Im Rahmen eines Compliance-Audits benötigt das Gesundheitssystem diesen Bericht 90 Tage lang täglich. Die Analystin kann dies nur erreichen, wenn sie den Rest ihrer Arbeitswoche dafür opfert.
Der Workflow wurde in Alteryx One neu erstellt: Die Verbindungen zu Epic, Abrechnungsstelle und Vertrag werden einmalig konfiguriert. Die Logik zur Normalisierung der Kostenträgercodes – einschließlich der abrechnungstypspezifischen Ausnahmen, die zuvor nur im Gedächtnis der Analystin existierten – ist als dokumentierter, versionierter Transformationsschritt kodiert. Der Bericht wird jeden Morgen automatisch erstellt, markiert alle Kostenträger, deren Verzögerung sich im Wochenvergleich um mehr als 15 % verändert hat, und liefert den vier Abteilungsleiter:innen vor 8 Uhr eine zusammenfassende Beschreibung. Die Analystin überprüft die Ausgabe und untersucht die gekennzeichneten Elemente. Aktive Bearbeitungszeit: unter 45 Minuten. Die Änderung des Clearinghouse-Formats, die zuvor den Montagsbericht beeinträchtigte, löst nun eine Schema-Warnung anstelle eines unbemerkten Datenfehlers aus.
Diese Governance-Umstellung ermöglicht die Durchführung des 90-tägigen Compliance-Laufs. Die IT-Abteilung kann ein Prüfprotokoll erstellen, das genau zeigt, welche Daten in den Tagesbericht eingespeist wurden, welche Transformationslogik angewendet wurde und wann sie ausgeführt wurde. Die Zuordnung der Kostenträgercodes, die zuvor nur im Gedächtnis einer Analystin existierte, ist nun ein dokumentierter Workflow-Schritt, den jedes Teammitglied einsehen und pflegen kann.
Für Teams, bei denen die vorgelagerte Datenvorbereitung die Hauptursache für Verzögerungen ist, beschreibt dieser Beitrag zur Nutzung von KI zur Beschleunigung der Datenvorbereitung, wie speziell diese Ebene automatisiert werden kann.
Die interne Argumentation für einen Plattformwechsel ist oft der schwierigere Teil der Evaluierung. ie IT-Abteilung benötigt vor der Genehmigung einer neuen Datenumgebung die SOC-2-Dokumentation, die Architektur des Audit-Logs sowie Details zur Datenverschlüsselung und Identitätsföderation. Alteryx veröffentlicht all dies auf seiner Seite Trust and Security, einschließlich der Zertifikate ISO 27001 und SOC 2 Typ II. Für das Gespräch mit der Finanzabteilung über den Business Case bietet das Alteryx ROI-Datenblatt Informationen zu Zeitersparnis, Fehlerreduzierung und Geschäftsauswirkungen in einer Form, die bei Finanzteams typischerweise auf Resonanz stößt.
Um vor diesen Gesprächen festzustellen, wo Ihr Team aktuell steht, erstellt das Alteryx Analytics Maturity Assessment einen bewerteten Bericht im Vergleich zu ähnlichen Organisationen – ein nützlicher Kontext, bevor Sie in eine Budgetdiskussion gehen.
Wo dasselbe Muster funktionsübergreifend auftritt
Der oben beschriebene Workflow zur Bearbeitung von Schadensfällen ist ein Beispiel für ein Muster, das überall dort auftritt, wo manuelle Berichterstellung nicht die erforderliche Häufigkeit oder Spezifität für das Unternehmen erreichen kann:
- Vertriebsprognosen: Vertriebsteams verbringen ein bis zwei Analystentage pro Woche damit, CRM-Daten in einem Prognosebericht zu konsolidieren, der Fragen beantwortet, die der VP of Sales bereits gestellt hat. Automatisierte Erkenntnisse decken Pipeline-Anomalien auf – beispielsweise bei Deals mit rückläufigem Engagement oder veränderten Abschlussquoten je nach Segment –, bevor die Prognosebesprechung stattfindet. Dieser Use Case beschreibt die Pipeline im Detail.
- Ausnahmeberichterstattung in der Lieferkette: Sinkt die Pünktlichkeitsrate eines Lieferanten innerhalb von sechs Wochen von 94 % auf 78 %, wird dies oft erst zwei Wochen nach Beginn des Trends in einem manuellen Ausnahmebericht deutlich. Kontinuierliche automatisierte Scans erkennen die Anomalie, sobald sie statistisch signifikant wird, bevor sie die Produktion beeinträchtigt. Dieser Beitrag beschreibt die operativen Details.
- FP&A-Boardpakete: Monatliche Konsolidierungen aus fünf bis acht Quellsystemen beanspruchen drei bis vier Analyst:innen für fast eine Woche. Eine einzige Änderung im Excel-Modell einer Abteilungsleiterin löst einen vollständigen Neuaufbau aus. Durch die Automatisierung der Konsolidierungslogik auf der Transformationsebene entfällt dieser Neuaufbau. Dieses Beispiel veranschaulicht den FP&A-Workflow.
Worauf Sie bei der Bewertung von Augmented-Analytics-Plattformen achten sollten
Die meisten Plattformen werben mit Augmented-Analytics-Funktionen. Folgende Fragen helfen Ihnen, die richtige Plattform zu finden: Sie decken den gesamten Prozess ab, während andere lediglich eine intelligentere Benutzeroberfläche für manuelle Prozesse bieten.
- Werden alle vier Ebenen abgedeckt oder nur einige? Eine Plattform, die die Erkenntnisgewinnung automatisiert, aber ein separates Tool für die Datenvorbereitung erfordert, führt zu einer Integrationsabhängigkeit und einer Audit-Lücke zwischen den Ebenen. Suchen Sie nach einer Plattform, bei der Konnektivität, Transformation, Gewinnung von Erkenntnissen und Bereitstellung in derselben Umgebung geregelt werden.
- Können Data Analysts die Transformationslogik ohne technische Unterstützung pflegen? Wenn die Aktualisierung einer Geschäftsregel eine/n SQL-Developer oder einen Entwicklungssprint erfordert, verschiebt sich das Problem des Data Analyst als Engpass, verschwindet aber nicht. Die Plattform sollte die visuelle, codefreie Erstellung von Workflows unterstützen, damit Personen, die die Geschäftslogik verstehen, diese direkt pflegen können.
- Liefert die Plattform Erkenntnisse proaktiv oder wartet sie auf Abfragen? Self-Service-Exploration ist zwar nützlich, löst aber nicht das Problem der letzten Meile. Dieses Problem ist gelöst, wenn Stakeholder planmäßig aufbereitete, narrative Erkenntnisse erhalten, ohne dass ein/e Data Analyst diese manuell aufbereiten und versenden muss.
- Wie wird die Governance über alle vier Ebenen hinweg gehandhabt? Prüfprotokolle, die nur eine Phase abdecken – beispielsweise Auslieferungsprotokolle ohne Transformationshistorie – genügen den Anforderungen von Compliance-Prüfungen nicht. Jede Ebene sollte nachvollziehbar sein – welche Daten eingegangen sind, welche Logik angewendet wurde, was ausgegeben wurde und wann.
Ein Hinweis zu Alternativen: Python-basierte Pipelines und punktuelle Automatisierungstools sind die richtige Lösung, wenn die Logik einfach, gut dokumentiert und von einem technischen Team mit entsprechenden Wartungskapazitäten betreut wird. Augmented-Analytics-Plattformen sind die richtige Wahl, wenn die Logik komplex und über verschiedene Geschäftsbereiche verteilt ist und von Data Analysts gewartet werden muss, die den Geschäftskontext verstehen – und nicht von Engineers, die an der Festlegung der Regeln nicht beteiligt waren.
Was sich ändert, wenn dies im großen Maßstab funktioniert
Die Verbesserung einzelner Workflows ist deutlich spürbar. Der kumulative Effekt zeigt sich, wenn Dutzende von Workflows gleichzeitig und teamübergreifend automatisch ausgeführt werden.
Die unmittelbarste Verbesserung besteht darin, dass die ständige Fehlerbehebung entfällt. Wenn Reporting-Workflows automatisiert und kontrolliert werden, entfällt die durch Änderungen in vorgelagerten Systemen ausgelöste Notfallwiederherstellung, die die Arbeitswoche von Data Analysts in Anspruch nimmt. Eine umbenannte Spalte verursacht nicht länger unbemerkt zwei Wochen lang fehlerhafte Ergebnisse. Der Workflow meldet die Schemaabweichung bei der nächsten Ausführung. Der Data Analyst korrigiert die Zuordnung einmal im Workflow, und sie bleibt bestehen.
Ein wichtiger Aspekt ist jedoch: Transformations-Workflows, die 12 bis 18 Monate lang nicht überprüft werden, neigen dazu, unbemerkte Workarounds anzusammeln – beispielsweise eine Feldkonvertierung in den falschen Datentyp, die zufällig korrekte Ergebnisse für die aktuellen Daten liefert, oder eine Ausnahmeregel, die aufgrund einer Anomalie in einem Quartal hinzugefügt und nie wieder entfernt wurde. Die Governance-Infrastruktur, die die Automatisierung vertrauenswürdig macht, funktioniert nur, wenn die Logik regelmäßig überprüft wird. Automatisierung reduziert den Aufwand für die Wiederherstellung, beseitigt aber nicht die Notwendigkeit der Wartung.
Institutionelles Wissen wird übertragbar. Regionale Ausnahmen, Rundungskonventionen, die Datenquelle, der das Team nach der letzten Migration nicht mehr vertraute – all das ist im Workflow kodiert und wird automatisch versioniert. Wenn der Analyst, der ihn erstellt hat, in ein anderes Team wechselt, wird der Workflow genauso ausgeführt wie zuvor. Die nächste Person, die ihn pflegt, hat einen dokumentierten Ausgangspunkt, anstatt die Person kontaktieren zu müssen, die zuvor zuständig war.
Und die Einrichtung eines neuen Berichtstyps ist kein Projekt mehr. Mit der vorhandenen Infrastruktur – verwalteten Konnektoren, einer Transformationsebene und automatisierter Bereitstellung – dauert das Hinzufügen eines neuen Berichtstyps nur noch Stunden statt eines Sprints. Eine Geschäftsanfrage, für die zuvor ein Ticket und eine Wartezeit im Backlog erforderlich waren, kann von der Analystin bearbeitet werden, die für die Frage zuständig ist. Die Kapazitätserweiterung im großen Maßstab besteht nicht in schnelleren Einzelberichten, sondern darin, dass weniger Personen notwendig sind, um mehr Berichte zu bearbeiten.
Mehr als die Hälfte der Global-2000-Unternehmen vertrauen Alteryx One, darunter Organisationen aus den Bereichen Finanzdienstleistungen, Gesundheitswesen und öffentliche Verwaltung, wo ein fehlerhafter oder nicht nachvollziehbarer Bericht nicht nur operative, sondern auch regulatorische Konsequenzen hat. Dieser Funktionsumfang spiegelt die Governance-Anforderungen der Umgebungen wider, in denen die Plattform operiert.
Wo anfangen?
Der ideale Einstiegspunkt ist ein bestimmter Bericht, den Ihr Team regelmäßig neu erstellt – ein Bericht, bei dem die manuelle Arbeit nachvollziehbar ist, die Geschäftsfrage klar definiert ist und die Datenquellen bereits im Unternehmen verfügbar sind. Ein Workflow, der alle vier Ebenen durchläuft.
Zwei Bedingungen sprechen für einen geeigneten Bericht: Die Geschäftsfrage, die der Bericht beantwortet, ist klar definiert, und mindestens ein Stakeholder ist bereits unzufrieden mit der langen Wartezeit auf die Antwort. Die Daten müssen nicht perfekt sein. Sie müssen lediglich zugänglich sein.
Beginnen Sie mit einem Bericht. Erstellen Sie ihn einmalig Alteryx One. Testen Sie ihn kostenlos und erleben Sie die automatische Ausführung. Keine umfassende Umstellung erforderlich.