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.
Erkennen Sie das?
Wenn Ihre Excel-Modelle und Ihr ERP unterschiedliche Zahlen zeigen, schauen wir im kostenlosen Erstgespräch, wie beide Welten zusammenfinden — ohne Ihr bewährtes Modell abzuschaffen.
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.