Wenn eine Prognose nicht standhält, ist der erste Reflex, das Modell anzupassen. Es geht schnell, fühlt sich nach Problemlösung an und funktioniert meist eine Weile.
Es ist auch der Weg, auf dem ein Planungssystem leise aufhört, vertrauenswürdig zu sein. Adaptive-Planning-Modelle anzupassen, um Probleme in den Quelldaten auszugleichen, behebt diese Probleme nicht. Es zementiert sie und beseitigt zugleich die Belege dafür, dass sie je existierten.
Das war jahrelang ein beherrschbares Risiko. Es hört auf, beherrschbar zu sein, sobald Sie KI darauflegen - und zwar aus einem Grund, den die meisten Teams nicht kommen sehen.
Warum Teams das tun
Niemand macht sich vor, ein Planungsmodell auf unzuverlässigen Daten aufzubauen. Die Entscheidung fällt meist unter Druck, spät in einem Deployment, und aus Gründen, die im Moment vollkommen nachvollziehbar sind.
Daten im Quellsystem zu korrigieren bedeutet Untersuchung, Ursachenanalyse und oft erneute Erfassung. Wochen vor dem Go-live fühlt sich das wie ein Projektneustart an. Das Modell anzupassen dauert einen Nachmittag.
Hinzu kommt ein Zuständigkeitsproblem. Wenn das Problem im Quellsystem liegt, gehört es jemand anderem. Umgeht man es in Adaptive, verschwimmt die Zuständigkeit - kurzfristig für alle bequemer.
Und Modellanpassungen sind auf eine Weise unsichtbar, wie es Datenkorrekturen nicht sind. Niemand auf der Fachseite sieht den Workaround. Man sieht Prognosen, die sich abstimmen lassen.
Also kommt der Workaround rein. Er funktioniert. Das Projekt geht live. Was danach passiert, ist der Teil, den man verstehen sollte.
Was tatsächlich kaputtgeht
Prognosen entfernen sich von der Realität. Wenn ein Modell ein Datenproblem ausgleicht, verbessert sich die Prognose relativ zu den eigenen Annahmen des Modells und weicht vom Geschäft ab. Die tatsächlichen Ausgaben folgen weiter den realen Daten. Die Prognose folgt weiter der Anpassung. Die Lücke wird größer, und weil die Anpassung nicht sichtbar ist, wird sie mit jedem Zyklus schwerer zu erklären.
Die Abweichungsanalyse verliert ihren Nutzen. Planung ist iterativ: prognostizieren, mit Ist-Werten vergleichen, Abweichung finden, anpassen. Ruht die Prognose auf einem Workaround statt auf verlässlichen Daten, lässt sich nicht mehr erkennen, ob Sie den Plan verfehlt haben, weil eine Annahme falsch war oder weil das Modell etwas in den Daten ausgeglichen hat. Jeder Zyklus beginnt mit einer Unsicherheit, die niemand quantifiziert hat.
Das Wissen verlässt mit der Person das Haus. Das ist der Punkt, der Teams kalt erwischt.
Nach einem Workday-Financials-Deployment und der Bitte, Adaptive zu aktualisieren, stießen wir auf ein Problem im Kostenstellen-Mapping. Die Struktur in Financials war ursprünglich falsch, also wurde während der Integration eine Korrektur in SQL angewendet. Financials wurde anschließend ordnungsgemäß korrigiert und umstrukturiert. Das SQL folgte weiter der alten Logik.
Nichts schlug fehl. Kein Fehler wurde ausgelöst. Das Mapping war nie dokumentiert worden, und die Abweichung fiel erst sechs Monate später auf, während eines Systemreviews und einer tiefgehenden Abstimmung der Workday- mit den Adaptive-Daten.
Sechs Monate an Prognosen waren daraus entstanden. Sie sahen einwandfrei aus.
Dieser konkrete Korrekturweg war spezifisch dafür, wie die Integration gebaut worden war. Das Muster ist es nicht. Ein Workaround wird angewendet, weil er der schnellste Weg ist, er wird nicht dokumentiert, weil er provisorisch sein soll, und die Person, die ihn verstand, zieht weiter.
Wie das innerhalb von Adaptive aussieht
Warum diese Probleme Monate statt Tage überdauern, lohnt sich zu verstehen, denn es hängt spezifisch damit zusammen, wie Adaptive mit Daten umgeht, die es nicht erkennt.
Adaptive weist Werte, die es nicht einordnen kann, nicht zurück. Je nach Hierarchie landen unbekannte Werte in einem nicht kategorisierten Sammelposten. Das ist das entscheidende Detail: Eine unvollständige Hierarchie erzeugt keinen offensichtlichen Fehler, sie erzeugt eine plausible Zahl. Die Summen stimmen an der Spitze weiterhin. Reporting und Analyse sind je nach Systemeinstellungen betroffen, aber nichts macht sich bemerkbar.
Die Workarounds verhalten sich genauso. Nicht identifizierte Kostenstellen auf andere Ebenen zu mappen löst ein kurzfristiges Abstimmungsproblem zwischen Financials-Ist-Werten und Adaptive. Bleibt es bestehen, verzerrt es weiter unten die Abweichungen, während die Zusammenfassung weiterhin korrekt aussieht. Fest codierte Werte und Dimensionen, die in Formeln stecken, wo sie an klar definierte Annahmen gebunden sein sollten, sind nicht anders. Sie funktionieren - und dann werden sie unsichtbar.
Die Abstimmung ist die Kontrolle, und in der Praxis ist sie schwächer, als die meisten Teams annehmen. In einem idealen Deployment bräuchte man sie nicht. Weil es Workarounds an Kostenstellenstrukturen gibt, ist die realistische Lage, dass die Adaptive-Ausgabe jeden Monat gegen einen Workday-Financials-Report abgestimmt wird. Das kostet Zeit, und die Ebene, auf der Sie es tun, entscheidet, ob es überhaupt lohnt. Stimmen Sie zu weit oben ab, wird es aufgehen, was Ihnen nichts sagt. Falsch gemappte Dimensionen zeigen sich nicht in einer Summe. Sie zeigen sich darunter.
Warum KI daraus ein Risiko macht
Hier ist, was sich ändert.
Ein Mensch, der einen Abweichungsbericht liest, arbeitet von oben nach unten. Zuerst die Summen, dann die Zeilen, die sich bewegt haben. Eine Zusammenfassung, die aufgeht, sieht wie ein funktionierendes System aus.
KI liest das nicht so. Bitten Sie sie zu prognostizieren oder eine Abweichungsanalyse durchzuführen, und sie arbeitet auf der granularsten verfügbaren Ebene. Ist eine Dimension nicht kategorisiert oder eine Kostenstelle dem falschen Ort zugeordnet, enthält die erzeugte Prognose nicht alle Daten. Sie liest nicht die Zusammenfassung, die aufgeht. Sie liest das Detail, das es nicht tut.
So kehrt sich das Problem um. Bei einem traditionellen Modell tauchen Datenprobleme irgendwann in der Abweichungsanalyse auf, weil ein Mensch nach ihnen sucht. Bei einem KI-Modell liegen dieselben Probleme vor einem Prozess, der keinen Grund hat, sie zu melden, und die Ausgabe wirkt eher raffinierter als weniger.
Das ist deshalb wichtig, weil es darauf ankommt, wer es am Ende verteidigen muss. Das Modell erzeugt eine Prognose. Finance präsentiert sie. Ein Quartal später ist sie falsch, der Vorstand fragt warum, und die ehrliche Antwort lautet, dass niemand sicher weiß, woraus das Modell gelernt hat. Die KI hat nicht versagt. Die Daten haben es. Finance trägt so oder so das Glaubwürdigkeitsproblem.
Der Unterschied zwischen einer KI-Prognose, die ein CFO präsentieren kann, und einer, die er nicht präsentieren kann, ist nicht das Modell. Es ist, ob die Antwort auf "Woher kommt das?" ein Satz oder ein Schulterzucken ist.
"Es hat aus drei Jahren geprüfter Transaktionsdaten gelernt, analysiert nach Kostenstelle und Ausgabenkategorie, und es folgt den Ist-Werten innerhalb der vereinbarten Toleranz." Das ist belastbar.
"Es hat aus Daten gelernt, von denen wir wussten, dass sie Lücken hatten, einige davon haben wir in der Planungsschicht korrigiert, und wir sind uns nicht sicher, was es aufgenommen hat." Dasselbe Modell. Es lässt sich nicht verteidigen.
Datenintegrität zuerst
Adaptive Planning beruht auf drei Schichten, in dieser Reihenfolge: verlässliche Quelldaten, klare Data Governance und Modelle, die auf diesen Daten aufbauen, statt sie auszugleichen. Überspringen Sie die ersten beiden, wird die dritte irgendwann scheitern.
In der Praxis bedeutet das ein paar Dinge.
Prüfen Sie das Quellsystem, bevor Sie irgendetwas konfigurieren. Sind die Hierarchien vollständig? Sind die Kostenstellenzuordnungen konsistent? Stimmen die Salden auf jeder Ebene, nicht nur an der Spitze? Dokumentieren Sie die Ausgangslage, damit Sie später erkennen können, ob die Qualität sich verbessert oder abdriftet.
Legen Sie Zuständigkeiten fest, solange sie noch günstig sind. Wer pflegt den Kontenplan. Wann werden Kostenstellen angelegt. Was validiert eine neue Dimension. Diese Fragen sind vor dem Go-live trivial und danach teuer.
Entscheiden Sie, was eine akzeptable Abweichung tatsächlich ist. Es gibt hier keinen Branchenwert, und wer Ihnen einen anbietet, rät. Was als vertretbare Lücke zwischen Ist-Werten und Prognose gilt, ist eine Ermessensfrage des Systemverantwortlichen und hängt vom Geschäft ab. Treffen Sie sie ausdrücklich, halten Sie sie schriftlich fest und stimmen Sie dagegen ab.
Stimmen Sie auf einer Ebene ab, die niedrig genug ist, um etwas zu finden. Monatlich, Modellausgabe gegen Quelldaten, und wenn es eine Abweichung gibt, untersuchen Sie sie, statt sie zu absorbieren. Beheben Sie Datenprobleme zuerst im Quellsystem, passen Sie dann das Modell an, falls es weiterhin einer Anpassung bedarf.
Wenn Sie KI hinzufügen, führen Sie diese Prüfung durch, bevor Sie starten, nicht nachdem die erste Prognose enttäuscht. KI verstärkt Datendrift, deshalb muss die Validierung fortlaufend sein statt eine einmalige Übung zu Beginn. Und wenn Sie mitten in einer KI-Initiative Qualitätsprobleme finden, stoppen Sie und beheben Sie die Daten. Es gibt keine Konfiguration, die ein Modell darum herumarbeiten lässt.
Zwei Fragen, die Sie Ihrem Team stellen sollten
Können Sie jede Annahme in Ihrem Adaptive-Planning-Modell erklären, indem Sie auf verlässliche Daten im Quellsystem verweisen? Wenn die Antwort "nicht ganz" lautet, ist das ein Datenproblem und kein Planungsproblem, und keine Modellanpassung wird es lösen.
Und wenn Sie heute eine KI-Prognose auf Ihren aktuellen Daten aufbauen würden, könnten Sie sie vor dem Vorstand verteidigen, indem Sie sie bis zur Quelle zurückverfolgen? Wenn die Antwort "wir würden die Daten erst bereinigen wollen" lautet, ist das die richtige Antwort. Es ist auch ein deutlich günstigeres Gespräch, es jetzt zu führen als nach der Investition.
Michael Trussell ist Workday Adaptive Planning Architect bei VirtualResource, wo wir mit Finance- und HR-Teams an Workday-Deployments, laufender Adaptive-Planning-Optimierung und KI-Enablement arbeiten. Wenn Sie eines von beiden abwägen, beginnt das Gespräch meist mit einem Blick darauf, wo die Daten tatsächlich stehen.