Es gibt eine Datei, die in diesem Unternehmen jeder kennt. Mehrere hundert Megabyte groß. Wenn man sie öffnet, geht man erstmal Kaffee holen. Wenn man sie nicht vollständig durchrechnen lässt, stehen falsche Zahlen drin – und niemand merkt es.
Diese Datei ist das Forecast-Modell. Sie steuert ein Infrastrukturprojekt im dreistelligen Millionenbereich.
Daneben existiert eine zweite Welt: das ERP. MS Dynamics, Hauptbuch, Kostenstellen, gepflegt von der Buchhaltung. Die beiden Welten haben sich nie kennengelernt. Wenn die Projektsteuerung 4,2 Mio. € Kosten ausweist und die Buchhaltung 4,6 Mio. €, beginnt die Detektivarbeit: Wer hat recht? Warum? Und wie erklärt man die Differenz dem Management?
So sah die Ausgangslage aus, als wir das Projekt übernommen haben.
Die unbequeme Vorgabe
Der naheliegende Beraterreflex wäre: Excel weg, neues EPM-Tool rein, alle Prozesse umstellen. Genau das war hier nicht gewünscht – aus gutem Grund. Die Forecast-Modelle waren das eingespielte Werkzeug der Projektsteuerung, fachlich durchdacht, im Team verankert. Ein Werkzeugwechsel mitten in einem laufenden Großprojekt? Zu riskant, zu teuer, zu viel Reibung.
Die Excel-Modelle bleiben. Aber sie müssen aufhören zu lügen.
Das ist die deutlich schwierigere Aufgabe. Und die deutlich bessere.
Erst verstehen, dann bauen
Wir haben nicht mit einem Pflichtenheft angefangen, sondern mit einem Prototypen. Den kompletten Transformationsworkflow der Excel-Modelle nachvollzogen, Zelle für Zelle, Logik für Logik. Parallel das Datenmodell von MS Dynamics seziert – welche Tabellen tragen welche Information, wo hängen Hauptbuch, Nebenbücher und Zahlläufe zusammen.
Erst als beide Welten verstanden waren, haben wir final gebaut: ein Multi-Layer Data Warehouse auf Snowflake. Rohdaten rein, Transformationen im Silver Layer, auswertungsfertige Modelle im Gold Layer, darauf Tableau als Reporting-Frontend. Stammdaten in einem separaten, wiederverwendbaren Schema. Alles versioniert über GitHub – Database as Code, jede Änderung rückrollbar.
Die Excel-Modelle? Werden weiterhin eingelesen. Aber nur noch als Input. Eine Versionierungslogik in der Datenbank historisiert jeden Forecast-Stand sauber – das Versionsprinzip, das man aus teuren Cube-Systemen kennt, nur ohne teures Cube-System.
Die Stelle, an der solche Projekte normalerweise scheitern
Dann kam der harte Teil. Die Projektsteuerung denkt in Cashflow: Was wurde tatsächlich gezahlt, wann, für welches Gewerk? Die Kostenstellen, die diese Frage beantworten könnten, existieren aber nur in der Buchhaltung – nicht in den Zahlungsdaten. Zwei Sichten auf dasselbe Geld, ohne gemeinsamen Schlüssel.
Die Lösung lag in der Multi-Ledger-Struktur von Dynamics: Wir haben eine Matching-Logik entwickelt, die Hauptbuch-Buchungen, Nebenbücher, Zahlläufe und Bankbewegungen miteinander verknüpft und robust erkennt, welche Buchung tatsächlich zahlungswirksam ist. Damit konnten wir die Kostenstellen aus der Buchhaltung auf die Zahlungsflüsse mappen – und das Ergebnis direkt zurück ins Projektcontrolling spielen.
Klingt selbstverständlich. Ist es nicht. In einem komplexen ERP mit teilweise inkonsistent gepflegter Buchhaltung ist genau diese Verknüpfung der Punkt, an dem die meisten Integrationsprojekte still aufgeben und mit „ungefähr stimmt's“ leben. Wir wollten kein Ungefähr.
Der Moment, in dem es klick macht
Heute hat jede Zeile im Forecast ein Pendant im Hauptbuch. Eins zu eins.
Was das praktisch bedeutet: Die Finanzabteilung reißt GuV und Bilanz per Knopfdruck nach jeder Kostenstelle und jedem Projektbestandteil auf. Drilldown bis auf den Einzelbeleg, aus jeder Sicht. Buchhaltungssicht und Cashflow-Sicht lassen sich übereinanderlegen – Abweichungen erklären sich als automatisierte Bridge, nicht mehr in nächtlicher Detektivarbeit. Sogar das ewige Datums-Problem ist gelöst: umschaltbar zwischen Buchungsdatum und Transaction Date, kein Mismatch mehr.
Und weil das Datenmodell semantisch sauber dokumentiert ist, können KI-Agenten direkt mit den Daten sprechen und Auswertungen vollautomatisiert erzeugen. Auf Basis eines ERPs, das vorher als „schlecht angebunden“ galt.
Das Ganze läuft für rund 400 € Infrastrukturkosten im Monat, usage-based. Zum Vergleich: Klassische EPM-Suiten wie Workday Adaptive oder Lucanet kosten ein Vielfaches – und hätten die eigentliche Verknüpfungsarbeit trotzdem nicht erledigt.
Was bleibt, wenn wir gehen
Ein System, das nicht heimlich kaputtgeht: Ändert sich das ERP-Schema, bricht die Pipeline kontrolliert und sichtbar – statt stillschweigend falsche Zahlen zu liefern. Regelmäßige Security-Reviews halten das Warehouse auf Stand. Und weil alles als Code in GitHub liegt, ist jede Änderung nachvollziehbar und reversibel.
Drei Dinge, die Sie mitnehmen können
- Ihre Datenbasis muss nicht perfekt sein. Inkonsistente Buchhaltung und ein altes ERP sind kein K.-o.-Kriterium – sie sind der Normalfall. Entscheidend ist, das Maximum daraus zu holen.
- Bewährte Werkzeuge erhalten statt ersetzen. Das Excel-Modell lebt weiter – aber entmachtet, als reiner Input. Die Logik liegt heute robust und versioniert in der Datenbank.
- Prototyp vor Pflichtenheft. Gerade in Unternehmen, deren Prozesse sich noch entwickeln, schafft ein Prototyp Erkenntnis, wo ein Konzept nur Papier schafft.
There's one file everyone at this company knows. Several hundred megabytes in size. When you open it, you go and fetch a coffee while it loads. And if you don't let it fully recalculate, it quietly shows the wrong numbers – and nobody notices.
That file is the forecast model. It steers an infrastructure project worth hundreds of millions of euros.
Alongside it lives a second world: the ERP. MS Dynamics, general ledger, cost centres, maintained by the accounting team. The two worlds had never been introduced. When project controlling reports €4.2M in costs and accounting reports €4.6M, the detective work begins: Who is right? Why? And how do you explain the difference to management?
That was the situation when we took the project on.
The uncomfortable requirement
The obvious consultant reflex would be: rip out Excel, drop in a new EPM tool, re-engineer every process. That was precisely what was not wanted here – for good reason. The forecast models were the well-rehearsed instrument of project controlling: thoughtfully designed, deeply embedded in the team. Switching tools in the middle of a running mega-project? Too risky, too expensive, too much friction.
The Excel models stay. But they have to stop lying.
That is the much harder task. And the much better one.
Understand first, then build
We didn't start with a requirements document, but with a prototype. We retraced the complete transformation workflow of the Excel models, cell by cell, logic by logic. In parallel, we dissected the MS Dynamics data model – which tables carry which information, and where the general ledger, sub-ledgers and payment runs connect.
Only once both worlds were understood did we build for real: a multi-layer data warehouse on Snowflake. Raw data in, transformations in the silver layer, analysis-ready models in the gold layer, with Tableau as the reporting front end. Master data in a separate, reusable schema. Everything versioned via GitHub – database as code, every change reversible.
The Excel models? They're still read in. But only as input. A versioning logic in the database cleanly historises every forecast state – the versioning principle you know from expensive cube systems, just without the expensive cube system.
Where projects like this usually fail
Then came the hard part. Project controlling thinks in cash flow: what was actually paid, when, and for which trade? But the cost centres that could answer that question exist only in accounting – not in the payment data. Two views of the same money, with no shared key.
The solution lay in the multi-ledger structure of Dynamics: we developed a matching logic that links general-ledger postings, sub-ledgers, payment runs and bank movements, and robustly identifies which posting is actually cash-effective. This let us map the cost centres from accounting onto the payment flows – and feed the result straight back into project controlling.
Sounds self-evident. It isn't. In a complex ERP with partially inconsistent bookkeeping, this exact linkage is the point where most integration projects quietly give up and settle for “roughly right”. We didn't want roughly.
The moment it clicks
Today every line in the forecast has a counterpart in the general ledger. One to one.
What that means in practice: the finance team breaks down P&L and balance sheet at the push of a button, by any cost centre and any project component. Drill-down to the individual document, from every angle. The accounting view and the cash-flow view can be laid over one another – discrepancies explain themselves as an automated bridge, no longer through nightly detective work. Even the eternal date problem is solved: switchable between posting date and transaction date, no more mismatch.
And because the data model is documented in a semantically clean way, AI agents can talk to the data directly and generate analyses fully automatically. On top of an ERP that was previously written off as “poorly connected”.
The whole thing runs for around €400 in infrastructure cost per month, usage-based. For comparison: classic EPM suites like Workday Adaptive or Lucanet cost a multiple of that – and still wouldn't have done the actual linkage work.
What remains when we leave
A system that doesn't break in secret: if the ERP schema changes, the pipeline breaks in a controlled, visible way – instead of silently delivering wrong numbers. Regular security reviews keep the warehouse current. And because everything lives as code in GitHub, every change is traceable and reversible.
Three things you can take away
- Your data foundation doesn't have to be perfect. Inconsistent bookkeeping and an old ERP aren't a knock-out criterion – they're the norm. What matters is extracting the maximum from them.
- Preserve proven tools instead of replacing them. The Excel model lives on – but disempowered, as pure input. The logic now sits robustly and versioned in the database.
- Prototype before specification. Especially in companies whose processes are still evolving, a prototype creates insight where a concept only creates paper.