Fragen Sie eine Analystin in der Kreditorenbuchhaltung, wie sicher sie sich ist, dass der Rechnungsgesamtbetrag dieses Monats mit den tatsächlichen Buchungen im ERP übereinstimmt, und beobachten Sie die Pause vor der Antwort. Die ehrliche Antwort lautet in den meisten Monaten, dass sie sich keineswegs ganz sicher ist. Der Beweis ist der Fehlermodus selbst: das erneute Öffnen der Tabelle des Vormonats und das Scrollen, bis etwas fehlerhaft aussieht – was kein Vergleichsprozess ist, sondern nur die Gewohnheit, Unsicherheit zu tolerieren.
Das Muster wiederholt sich überall dort, wo zwei Datasets übereinstimmen sollten. Ein Anbieter-Rechnungsauszug und ein ERP-Nebenbuch, ein Point-of-Sale-Export und ein Warehouse-System, eine Legacy-Plattform und das Cloud-System, das sie ersetzt. Sie stimmen selten sauber überein, und herauszufinden, warum, dauert jedes Mal länger, wenn die Zeilenanzahl steigt.
Dieser Beitrag erläutert die eigentliche Funktionsweise eines Vergleichs, der so aufgebaut ist, dass er beim zehnten Durchlauf dieselbe Antwort liefert wie beim ersten, unabhängig davon, wer ihn ausführt oder wie müde die jeweilige Person an diesem Tag ist.
Ein zuverlässiger Vergleich liefert jedes Mal dasselbe Ergebnis – eine einmalige Überprüfung nicht
Das Ergebnis, auf das es sich hinzuarbeiten lohnt, ist ein Vergleich, der beim zehnten Durchlauf dasselbe Ergebnis liefert wie beim ersten. Ein Vergleich, der lediglich einmal korrekt abgeschlossen wurde, ist nicht das Ziel; jeder kann einmal Glück haben.
„Zuverlässig“ hat hier eine spezifische, eng gefasste Bedeutung: identische Abgleichsschlüssel, identische Standardisierungsregeln und identische Abgleichslogik, die in jedem Zyklus auf dieselbe Weise angewendet werden. Nichts davon wird bei jeder Ausführung erneut aus der Erinnerung einer Person abgeleitet. Eine manuelle Überprüfung in einer Tabellenkalkulation beantwortet die Frage „stimmten diese heute überein?“, was sich von der Frage „werden diese weiterhin übereinstimmen?“ unterscheidet, und die beiden werden ständig verwechselt.
Es steht real etwas auf dem Spiel, nicht nur hypothetisch. Laut Gartner-Studien belaufen sich die durchschnittlichen Kosten für schlechte Datenqualität bei den betroffenen Unternehmen auf 12,9 Millionen US-Dollar pro Jahr. Ein Abgleichprozess, der nur funktioniert, wenn dieselbe Person ihn jeden Monat auf dieselbe Weise aus dem Gedächtnis heraus erstellt, trägt im Stillen zu dieser Zahl bei.
Drei Bausteine machen einen Vergleich zuverlässig statt zu einer einmaligen Sache: ein Match-Schlüssel, der in beiden Systemen dasselbe bedeutet, standardisierte Formate auf beiden Seiten, bevor überhaupt etwas verglichen wird, und ein Gesamtabgleich mit Ausnahmen, die einen Eigentümer haben. In den nächsten drei Abschnitten wird jeder einzelne der Reihe nach erläutert.
„Automatisch“ bedeutet in diesem Kontext, dass die Logik auf dieselbe Weise abläuft, ohne dass eine Person sie in jedem Zyklus von Grund auf neu aufbauen muss, und nicht, dass menschliches Urteilsvermögen entfällt. Es entscheidet nach wie vor jemand, was als echte Diskrepanz gilt. Der Vergleich selbst hängt einfach nicht mehr davon ab, dass sich diese Person in der Abschlusswoche um 23:00 Uhr korrekt an jede Regel erinnert.
Bevor Sie etwas automatisieren, lohnt es sich, genau aufzuschreiben, was der aktuelle Vergleichsprozess heute tatsächlich prüft. Diese Liste ist fast immer kürzer als angenommen.
Schritt 1 – Ein Match-Schlüssel funktioniert nur, wenn er in beiden Systemen dasselbe bedeutet
Die meisten Vergleiche, die „fehlschlagen“, sind eigentlich nicht beim Abgleich gescheitert. Sie sind bereits früher gescheitert, bei der Schlüsseldefinition, weil sich die beiden Systeme von vornherein nie darauf geeinigt haben, wie derselbe Datensatz identifiziert werden soll.
Ein verwendbarer Match-Schlüssel benötigt drei Dinge: Eindeutigkeit, Stabilität über beide Systeme hinweg und eine konsistente Darstellung. Zwei Spalten mit demselben Header-Namen sind nicht automatisch derselbe Schlüssel; bei dieser Annahme beginnen die meisten dieser Probleme.
Wenn beide Datasets eine echte eindeutige Kennung gemeinsam nutzen, wie etwa eine Rechnungsnummer, eine Transaktions-ID oder eine Kontonummer, reicht ein direkter Join über diesen Schlüssel aus. Es ist nichts Aufwändigeres erforderlich, und zusätzliche Komplexität schafft hier meist nur neue Stellen, an denen der Prozess scheitern kann.
Wenn Kennungen sich über Systeme hinweg unterscheiden oder nicht vorhanden sind, wie etwa Namens- und Adressvarianten oder unabhängig generierte IDs, funktioniert ein exakter Join nicht. Stattdessen muss der ähnlichkeitsbasierte Abgleich, allgemein bekannt als Datensatzverknüpfung oder Fuzzy Matching, diese Lücke schließen. Dabei wird verglichen, wie nah sich zwei Werte sind, anstatt ob sie identisch sind.
Zusammengesetzte Schlüssel erfordern besondere Skepsis. Ein Schlüssel, der aus Anbieter plus Rechnungsnummer plus Datum zusammengesetzt ist, sieht so lange eindeutig aus, bis bei einem dieser Felder Formatierungsabweichungen auftreten; an diesem Punkt ist der „eindeutige“ Schlüssel stillschweigend nicht mehr eindeutig, und niemand bemerkt es, bis die Abstimmungszahlen keinen Sinn mehr ergeben. Die Werte müssen außerdem in beiden Systemen auf die gleiche Weise formatiert sein, damit selbst ein korrekt ausgewählter Schlüssel fehlerfrei übereinstimmt – ein Problem, das als Nächstes behandelt wird.
Wenn ein genauer Schlüssel vorhanden ist
Verwenden Sie die gemeinsame eindeutige Kennung direkt, anstatt eine aus mehreren Feldern zu rekonstruieren. Überprüfen Sie, ob es in beiden Quellsystemen tatsächlich eindeutig ist, bevor Sie sich darauf verlassen; ein Feld kann in einem System eindeutig sein und nach einer Migration oder einer Zusammenführung im anderen nicht mehr eindeutig sein. Prüfen Sie, ob der Schlüssel den Weg über Systemgrenzen hinweg unverändert übersteht, da einige ERP-Systeme Kennungen beim Export abschneiden oder neu codieren.
Wenn es das nicht tut
Ermitteln Sie die am besten passenden verfügbaren Felder zur Verwendung als Ähnlichkeitsbasis – in der Regel Name, Adresse oder Beschreibung. Legen Sie den Ähnlichkeitsschwellenwert im Voraus fest, bevor Sie sich die Ergebnisse ansehen; Schwellenwerte, die erst nach Ansicht der Ausgabe ausgewählt werden, werden oft unbemerkt so angepasst, dass sie das gewünschte Ergebnis liefern. Ein auf Ähnlichkeit basierendes Matching-Setup wendet diese Art von Schwellenwert konsistent auf eine gesamte Datei an, anstatt dies einer visuellen Prüfung Zeile für Zeile zu überlassen. Dokumentieren Sie den Schwellenwert und die Begründung dahinter; ein nicht dokumentierter Schwellenwert ist genau die Art von institutionellem Wissen, die das Unternehmen mit der Person verlässt, die ihn festgelegt hat.
Schritt 2 – Typ- und Formatabweichungen erzeugen die meisten Unterschiede, die echt wirken
Je mehr der markierten „Abweichungen“ sich als Formatierungsunterschiede statt als echte Diskrepanzen herausstellen, desto weniger vertraut man dem Vergleich. Die Standardisierung vor der Ausführung des Joins statt einer nachträglichen Filterung sorgt dafür, dass der gesamte Prozess glaubwürdig bleibt.
Die typischen Fehlerquellen sind vorhersehbar: führende Nullen, die von einem System entfernt und von einem anderen beibehalten werden, nachgestellte Leerzeichen, uneinheitliche Groß-/Kleinschreibung, Null versus Leerzeichen versus „N/A“, abweichende Datumsformate und uneinheitliche Dezimalstellen bei Währungen. Keiner dieser Punkte stellt eine tatsächliche Abweichung zwischen den Datasets dar.
Dies vor dem Abgleich auf Feldebene zu korrigieren, ist besser, als falsch-positive Ergebnisse im Nachhinein herauszufiltern. Eine nachträgliche Filterung erfasst nie alles und muss in jedem einzelnen Zyklus manuell wiederholt werden. Eine direkt in die Pipeline integrierte Standardisierung ist dagegen ein einmaliger Einrichtungsaufwand pro Datenquelle und keine wiederkehrende manuelle Routineaufgabe.
Diese Art von Arbeit hat einen Namen: Datenbereinigung, also das Standardisieren von Nullwerten, Satzzeichen und Groß-/Kleinschreibung vor dem Vergleichen. Sie gehört als eigenständiger Schritt in den Prozess, nicht als Ad-hoc-Bereinigungslauf, den jemand durchführt, wenn die Zahlen falsch aussehen.
Sobald Schlüssel definiert und Formate auf beiden Seiten standardisiert sind, ist die Umwandlung zweier bereinigter Datasets in einen tatsächlichen Abgleich vergleichsweise mechanisch, was genau der nächste Schritt ist.
Schritt 3 – Der Abgleich zweier Datasets bedeutet, drei Ausgaben zu erzeugen, nicht nur eine Bestanden/Nicht-bestanden-Antwort
Ein nützlicher Vergleich erzeugt drei Gruppen: übereinstimmende Datensätze, Datensätze nur in Dataset A und Datensätze nur in Dataset B. Ein einfaches Pass/Fail-Urteil ist weniger nützlich und der Grund dafür, dass Ausnahmen überhaupt erst verloren gehen.
In der Praxis bedeutet dies, die beiden Datasets anhand des validierten Schlüssels zu verknüpfen und das Ergebnis anschließend in übereinstimmende Datensätze und die beiden Gruppen nicht übereinstimmender Datensätze aufzuteilen. Eine Verknüpfungsmechanik, die drei separate Ausgaben erzeugt – übereinstimmend, nur links, nur rechts –, ist genau die Struktur, die dieser Schritt benötigt, und ein Zusammenführen-Schritt, der diese Ausgaben wieder zusammenführt, erstellt die vollständige Abstimmungsansicht.
Bei wirklich großen Extrakten, Tabellen mit mehreren Millionen Zeilen oder ganzjährigen Transaktionshistorien vermeidet die Ausführung des Vergleichs innerhalb der Datenbank oder Verarbeitungs-Engine, in der sich die Daten bereits befinden, die Speicherobergrenze, an die eine Tabellenkalkulation oder ein naives Skript letztlich stößt.
Jede Nur-in-A- und Nur-in-B-Zeile benötigt einen zugewiesenen Eigentümer und einen vorab vereinbarten Wesentlichkeitsschwellenwert, der festgelegt wird, bevor die Abschlusswoche beginnt, anstatt erst im Verlauf dieser festgestellt zu werden. Ohne einen dokumentierten Schwellenwert jagen Teams entweder jeder Rundungsdifferenz von zwei Cent hinterher oder winken alles durch, und beide Ergebnisse verfehlen den eigentlichen Zweck eines Abgleichs.
Die manuelle Pflege einer Drei-Wege-Logik für Ergebnisse und Zuständigkeiten lässt sich nur bis zu einigen tausend Zeilen skalieren. An diesem Punkt gehen ein wiederholbarer Prozess und eine Prüfung in einer Tabellenkalkulation deutlich auseinander, und ein Team beginnt üblicherweise, nach etwas anderem zu suchen, das diesen Prozess ausführt.
Drei Wege, wie Teams dies tatsächlich umsetzen – und wo jeder Ansatz an seine Grenzen stößt
Teams erstellen diesen Vergleich in der Praxis auf eine von drei Arten: eine manuelle Tabelle, benutzerdefinierte SQL- oder Python-Skripte oder eine dedizierte Datenvorbereitungs- und Automatisierungsplattform. Welche Option die richtige ist, hängt vom Datenvolumen, der Häufigkeit und davon ab, wer sie warten muss – nicht davon, welches Tool zufällig bereits installiert ist.
Eine Tabellenkalkulation ist für eine kleine Datei und einen echten einmaligen Vergleich ohne Wiederholung vollkommen ausreichend. Nichts an diesem Auftrag erfordert mehr Maschinerie. Benutzerdefiniertes SQL oder Python eignet sich für Teams mit dedizierter Data-Engineering-Unterstützung, stabilen Anforderungen und bereits vorhandener Scheduling-Infrastruktur; die Entwicklung benutzerdefinierter Logik zahlt sich nur aus, wenn sie auch von jemandem gepflegt wird.
| Dimension | Manuelle Tabellenkalkulation (SVERWEIS / Formeln) | Benutzerdefinierte SQL- oder Python-Skripte | Dedizierte Datenvorbereitungs- und Automatisierungsplattform (z. B. Alteryx One) |
|---|---|---|---|
| Entwickelt für | Einmalige oder gelegentliche Überprüfungen von kleinen bis mittelgroßen Dateien | Teams mit Engineering-Ressourcen, die die volle Kontrolle über die Logik möchten | Analysten und technische Benutzer, die denselben Vergleich wiederholt ausführen müssen, ohne benutzerdefinierten Code pflegen zu müssen |
| Konfigurationsaufwand | Zu Beginn minimal, wächst jedoch jedes Mal, wenn die Zeilenanzahl oder die Quellenanzahl zunimmt | Hoher Vorabaufwand – jemand muss die Verknüpfungs-/Abgleichlogik schreiben und testen | Moderat – unterstützt das Verknüpfen und Abgleichen von Datensätzen über zwei Datasets hinweg, ohne benutzerdefinierte Skripts schreiben zu müssen |
| Verarbeiten großer Datasets | Bricht ab etwa einigen Hunderttausend Zeilen zusammen; Formeln werden langsam oder schlagen fehl | Lässt sich gut skalieren, wenn es so geschrieben ist, dass es auf der Datenbank selbst ausgeführt wird; hängt ganz von der Implementierung ab | Ist dafür konzipiert, große Datasets In-DB auf einer spezifischen, benannten Liste unterstützter Plattformen zu verarbeiten, und trägt dazu bei, das Laden aller Daten in den Arbeitsspeicher zu vermeiden |
| Nicht exakte Übereinstimmungen (Fuzzy/Ähnlichkeit) | Manuelle Sichtprüfung; keine systematische Möglichkeit, einen Schwellenwert konsistent anzuwenden | Möglich mit zusätzlichen Bibliotheken, erfordert jedoch zusätzliche Einrichtung und Feinabstimmung | Kann dabei helfen, nahezu identische Duplikate oder nicht identische Übereinstimmungen zu identifizieren, wenn Schlüssel nicht genau übereinstimmen, mit angegebenen Zeichensatzbeschränkungen für Lateinisch/Japanisch |
| Wiederholbarkeit/Zeitplanung | Standardmäßig keine – Logik befindet sich in einer Datei, verstanden von einer Person | Kann geplant werden (z. B. Cron, ein Orchestrator), benötigt jedoch einen Eigentümer, um den Code langfristig zu pflegen | Unterstützt die Planung von Workflows zur automatischen Ausführung in einem wiederkehrenden Rhythmus (stündlich/täglich/wöchentlich/monatlich/benutzerdefiniert) |
| Ehrliche Grenzen | Anfällig für Schemaänderungen; keine Nachvollziehbarkeit; institutionelles Wissen befindet sich in einer einzigen Tabellenkalkulation | Leistungsstark, aber anfällig für Personalfluktuation; oft unzureichend dokumentiert | Einrichtung und Wartung erfordern weiterhin jemanden, der den Workflow versteht; In-DB-Leistungsgewinne gelten nicht außerhalb der Liste der unterstützten Datenbanken |
| Beste Eignung | Ein wirklich einmaliger Vergleich unter rund 50.000 Zeilen | Teams mit dedizierter Unterstützung durch Data Engineering und stabilen, gut verstandenen Anforderungen | Wiederkehrende, umfangreiche oder auf mehreren Quellen basierende Vergleiche, bei denen die Logik auch bei Mitarbeiterwechsel Bestand haben muss |
Die Entscheidungsregel ist einfach: passen Sie den Ansatz daran an, wie oft der Vergleich ausgeführt werden muss und wie groß die Datasets sind, nicht daran, was sich bereits auf dem Desktop von jemandem befindet.
Hier scheitert dies in der Praxis – und so sieht die Behebung aus
Ein mittelgroßer Industriehändler war gerade dabei, seine Anbieter- und Rechnungsdatensätze von einem fünfzehn Jahre alten On-Premises-ERP auf ein neues Cloud-ERP zu migrieren. Anbieterrechnungen mussten jeden Monat und insbesondere während des Live-Umstellungszeitraums zwischen den beiden Systemen abgeglichen werden.
Drei Personen waren für unterschiedliche Teile davon verantwortlich. Dana, Analyst für den Kreditorenabgleich, war für die monatliche Prüfung zuständig. Marcus, Leiter der IT-Migration, war während der Umstellung für die Datenintegrität verantwortlich. Der Controller war für die Abschlussfrist verantwortlich, zusammen mit einer Reihe ungeschriebener Regeln dafür, was tatsächlich als nachverfolgenswerte Abweichung galt.
Noch bevor eine Migration überhaupt ins Spiel kam, war die Ausgangsbasis bereits manuell: ein Export von Anbieterrechnungen mit rund 35.000 Zeilen, der in Excel per SVERWEIS mit dem AP-Nebenbuch des ERP-Systems abgeglichen wurde und Dana an jedem Monatsende zwei volle Arbeitstage kostete.
Dann kam der Monat der Umstellung. Rechnungsnummern, die im Altsystem als Text mit führenden Nullen wie „0003347“ gespeichert waren, wurden im neuen ERP als numerische Felder übernommen, wobei diese Nullen entfernt wurden. Ein exakter Abgleich anhand der Rechnungsnummer schlug bei jedem Anbieter, dessen Rechnungsnummern zufällig mit einer Null begannen, unbemerkt fehl, und in keinem der beiden Systeme wurde dies gekennzeichnet.
Ein zweites Problem verschärfte das erste. Eine Wesentlichkeitsschwelle von 250,00 $, unterhalb derer Diskrepanzen routinemäßig durchgewunken wurden, existierte nur im Gedächtnis des Controllers. Sie war in keiner Abgleich-Checkliste dokumentiert, sodass niemand, der die markierten Zeilen überprüfte, schnell erkennen konnte, welche tatsächlich von Bedeutung waren und welche nur Rauschen darstellten.
Die Zahlen machten die Kosten greifbar. Rund 1.200 der 35.000 Zeilen wurden allein aufgrund des Formatierungsartefakts mit führenden Nullen als falsche „nicht übereinstimmende“ Ergebnisse zurückgegeben. Benchmarks von Ventana Research beziffern einen typischen Abschluss für Unternehmen, die dieses Ziel erreichen, auf etwa sechs Arbeitstage; dieser hier dauerte vier zusätzliche Tage, während Dana und Marcus Tausende gekennzeichnete Zeilen manuell überprüften, um tatsächliche Abweichungen von Formatierungsrauschen zu unterscheiden.
Die Behebung verwendete dieselbe oben erstellte Methode. Normalisieren Sie das Rechnungsnummernfeld vor dem Abgleich auf beiden Seiten auf dieselbe Textdarstellung, führen Sie eine Verknüpfung über den korrigierten Schlüssel durch, unterteilen Sie das Ergebnis in übereinstimmend, nur im Altsystem und nur im neuen ERP und leiten Sie nur die dokumentierten Ausnahmen oberhalb des Schwellenwerts an einen Eigentümer weiter.
Der Schlusskurs kehrte im folgenden Zyklus zu seiner normalen Länge zurück. Der Schwellenwert von 250 $ wurde zu einer schriftlich festgehaltenen und durchgesetzten Regel, statt nur im Kopf einer Person zu existieren, und jede Ausnahmeentscheidung hinterließ einen Datensatz darüber, wer sie gelöst hat und warum.
Wenn Zuständigkeiten für Ausnahmen und Wesentlichkeitsgrenzen der Teil sind, der derzeit nur im Gedächtnis von jemandem existiert, ist das Starter-Kit zur Klärung von Abstimmungsdifferenzen ein kostenloser, sofort anpassbarer Workflow, der genau für diesen Schritt entwickelt wurde.
Wie das aussieht, sobald es operationalisiert ist
Nach der Erstellung läuft der Vergleich nach einem eigenen Zeitplan und gibt nur das zurück, was sich eine Person tatsächlich ansehen muss, nicht jedes Mal die vollständige Zeilenanzahl. Diese Umstellung, von der Prüfung aller Daten hin zur Prüfung von Ausnahmen, ist der eigentliche Sinn dieses Aufbaus.
Wiederkehrende Ausführungen erfolgen täglich, wöchentlich, monatlich oder gebunden an einen Finanzkalender, anstatt nur dann, wenn jemand daran denkt, die Prüfung manuell auszulösen. Die Ausnahmewarteschlange wird zum einzigen echten manuellen Berührungspunkt: Analysten prüfen eine kurze Liste über dem Schwellenwert liegender, ungelöster Elemente, anstatt eine Datei mit 35.000 Zeilen Zeile für Zeile zu durchsuchen.
Bei wirklich großen Tabellen verhindert die Verarbeitung des Vergleichs innerhalb der Datenbank, in der sich beide Tabellen bereits befinden, dass alles in den Arbeitsspeicher der Anwendung geladen wird. Derselbe Workflow wird weiterhin selbstständig nach einem wiederkehrenden Zeitplan ausgeführt und verwandelt eine einmalige Prüfung in einen dauerhaften Prozess.
Für Analytics-Verantwortliche, die interne Argumente aufbauen, ist ein Workflow, der jedes Mal auf die gleiche Weise ausgeführt wird, auch einfacher zu prüfen als die individuellen Tabellenkalkulationsgewohnheiten einer einzelnen Person. Es trägt dazu bei, den manuellen Abstimmungsaufwand zu reduzieren, anstatt Ermessensentscheidungen gänzlich zu eliminieren, und hinterlässt einen Datensatz darüber, was wann ausgeführt wurde. IT-Stakeholder, die eine Plattform hierfür evaluieren, möchten in der Regel deren Sicherheits- und Compliance-Dokumentation einsehen, bevor sie ihre Freigabe erteilen.
Ein zukunftsorientierter Hinweis, klar eingeschränkt: KI-gestützte Vorschläge zur Schemaanpassung und Datenaufbereitung können helfen, den ersten Einrichtungsschritt zu beschleunigen, insbesondere die mühsame Arbeit, Felder über zwei Systeme hinweg zuzuordnen. Das ist Unterstützung bei der Einrichtung, keine Behauptung, dass KI die Datasets von allein vergleicht.
Beginnen Sie mit einem Vergleich, nicht mit dem gesamten Abgleichsprogramm
Der schnellste Weg zu beweisen, dass dies funktioniert, besteht darin, einen bestehenden manuellen Vergleich vollständig neu aufzubauen, und nicht darin, ein gesamtes Abgleichsprogramm zu planen, bevor überhaupt jemand gesehen hat, dass es einmal funktioniert.
Wählen Sie einen Vergleich, der bereits wiederkehrende Probleme verursacht, einen monatlichen Abgleich anstelle eines jährlichen, sodass der Nutzen innerhalb von ein oder zwei Zyklen statt erst nach einem Jahr sichtbar wird. Dokumentieren Sie den Abgleichschlüssel, die Regeln zur Formatstandardisierung und die Wesentlichkeitsgrenze bereits während der Erstellung explizit, anstatt Teile davon undokumentiert zu lassen, wie es beim Schwellenwert des Controllers von 250 $ im obigen Szenario der Fall war.
Lassen Sie den neuen Prozess einen vollen Zyklus lang parallel zum bestehenden manuellen Prozess laufen, bevor Sie die manuelle Version einstellen. Diese Überschneidung schafft Vertrauen in die Ergebnisse, bevor sich jemand vollständig darauf verlassen muss, und gibt Dana oder der für die Prüfung zuständigen Person die Möglichkeit, alles abzufangen, was in der neuen Version übersehen wurde.
Für Analytics-Führungskräfte ist diese Version der Geschichte – ein Vergleich und ein messbarer Vorher-Nachher-Vergleich – auch am einfachsten an IT- und Finanz-Stakeholder heranzutragen, wenn intern ein Business Case aufgebaut werden soll. Sie ist konkret und klar abgegrenzt und verlangt von niemandem, einer Plattform zu vertrauen, bevor man sie in Aktion gesehen hat.
Analysten, die dies ohne die Pflege benutzerdefinierter Skripte erstellen möchten, können eine kostenlose Testversion von Alteryx One starten und denselben oben beschriebenen Match-and-Reconcile-Workflow einrichten.