BI & Controlling-Apps für die Geschäftsführung

Ausgangslage

Wer eine Unternehmensgruppe führt, kennt das Ritual: Zum Monatsende kommen die Zahlen — als starrer Bericht oder als Excel mit fünf Wahrheiten, je nachdem, wen man fragt. Bis alles beisammen war, war der Monat alt und die Entscheidung überfällig.

Diese Referenz ist aus der eigenen Praxis entstanden: gebaut von jemandem, der zwanzig Jahre selbst Geschäftsführer und Eigentümer war — und die Zahlen nicht für die IT wollte, sondern für Montagfrüh.

Vorhanden war das Übliche: ein ERP mit sauberer Buchhaltung, ein alter Berichtsserver mit einer Handvoll funktionierender Auswertungen, und daneben gewachsene Excel-Dateien. Nichts davon war falsch. Es war nur nirgends zusammengeführt, und niemand konnte sagen, welcher Stand der richtige ist.

Das Schwierige daran

Die Schwierigkeit lag nicht in der Technik, sondern darin, was eine Zahl überhaupt bedeutet. Vier Dinge mussten stimmen, bevor irgendein Diagramm nützlich war.

Erstens: Das Wirtschaftsjahr ist nicht das Kalenderjahr. Das ERP bucht auf Kalendermonate, ausgewertet wird von April bis März — und der Jahresschlüssel unterscheidet sich je Gesellschaft. Eine erste Fassung rechnete auf Kalenderjahre und lieferte ein Betriebsergebnis, das gleich doppelt falsch war.

Zweitens: „Ergebnis“ ist kein Feld, sondern eine Definition. Grobe Kostenblöcke ziehen Abschlussbuchungen und das Finanzergebnis mit in die Zahl. Erst eine Klassifizierung auf Kontenebene nach dem Einheitskontenrahmen trennt Betriebsergebnis, Finanzergebnis und Steuern sauber voneinander.

Drittens — und das ist die unangenehmste Einsicht: Ein vollständiges Geschäftsjahr ist kein abgeschlossenes. Zwölf Monate können gebucht sein, während Abschreibungen, Steuern und Rückstellungen noch fehlen. Das Ergebnis sieht dann deutlich besser aus, als es ist. Wer das nicht kennzeichnet, baut ein Cockpit, das im günstigsten Moment lügt.

Viertens: Innenumsätze zwischen den Gesellschaften müssen raus, sonst zählt die Gruppe dasselbe Geschäft zweimal. Und ob ein Kunde konzernintern ist, entscheidet sein heutiger Status — nicht der zum Rechnungszeitpunkt.

Lösung

Entstanden ist ein Controlling-Cockpit mit über einem Dutzend Sichten: Konzern-Konsolidierung über die Gesellschaften der Gruppe, GuV, Auftragseingang, Bestand, offene Posten, Quartalsvergleich, Prognose und ein monatlicher Markt-Radar, der Branchentrends per Sprachmodell zusammenfasst.

Die Daten kommen automatisch: tägliches ETL vor Bürobeginn aus ERP und Finanzbuchhaltung, die Liquidität zusätzlich sechsmal täglich direkt von der Bank. Daneben Self-Service-BI mit über 20 Dashboards und rund 800 gespeicherten Abfragen über 9 Datenquellen — vom ERP bis zum Ticketsystem.

Die alten Berichtsserver-Reports ersetzt ein schlanker Reporting-Layer: sechs Berichtstypen, auf Knopfdruck als HTML, PDF oder Excel.

Ein Bestandsteil prüft die Lagerbewertung statistisch gegen den eigenen Zwölfmonatsverlauf und meldet Ausreißer als Ampel — mit Absprung auf den einzelnen Artikel, der den Ausschlag verursacht hat.

Die Prognose rechnet konservativ: bisher gebuchtes laufendes Jahr plus Restjahr aus dem Vorjahr. Kein Modell, keine Glättung — eine Zahl, deren Zustandekommen man in einem Satz erklären kann.

Wie es gebaut ist

Das Cockpit liest nur. Es schreibt in kein Quellsystem zurück, und diese eine Entwurfsentscheidung trägt alles Übrige: Sie macht den Betrieb risikoarm, jeden Fehler rückbaubar und die Einführung zu etwas, das man an einem laufenden ERP vorbeiziehen kann, ohne dass in der Buchhaltung jemand nervös wird.

Ein nächtliches ETL holt die Daten aus ERP und Finanzbuchhaltung in eine eigene PostgreSQL-Datenbank, sauber getrennt in Rohdaten und ausgewertete Sichten. Die gesamte Fachlogik steckt in SQL-Sichten statt in Anwendungscode: Wirtschaftsjahr, Kontenklassifizierung, Konzernkonsolidierung, Kennzahlen. Das hat einen unscheinbaren, aber entscheidenden Vorteil. Wer eine Zahl anzweifelt, verfolgt sie bis auf die einzelne Buchungszeile zurück, ohne dafür eine Zeile Programmcode lesen zu müssen.

Die Oberfläche ist dünn gehalten. Eine Django-Anwendung fragt die Sichten ab und zeichnet sie; jede Grafik lässt sich auf die Tabelle dahinter umschalten. Der Zugang läuft über den Konzern-SSO, Konzernzahlen zusätzlich beschränkt auf einen benannten Personenkreis.

Das Importfenster umfasst die letzten vollständigen Geschäftsjahre plus das laufende und rollt von selbst weiter. Niemand muss je ein Jahr nachtragen.

Im Betrieb

Das ETL läuft nachts, die Datenbank wird täglich gesichert. Ein Wert im Cockpit ist aber erst dann eine Aussage, wenn man weiß, wie alt er ist. Deshalb steht der Datenstand auf jeder Seite.

Ein vorläufiges Geschäftsjahr trägt einen Warnhinweis, der von selbst verschwindet, sobald der Jahresabschluss gebucht ist. Erkannt wird das an einer einzigen Eigenschaft: In einem abgeschlossenen Jahr summieren sich alle Erfolgskonten auf null, und solange diese Summe nicht aufgeht, bleibt die Zahl vorläufig, gleichgültig wie vollständig und abschlussreif sie auf den ersten Blick aussehen mag.

Richtigkeit wird hier nicht behauptet. Eine Prüfstrecke rechnet jede Kennzahl gegen die seit Jahren genutzten Auswertungen des alten Berichtsservers nach, und weicht auch nur eine davon ab, wird der Stand gar nicht erst ausgeliefert.

Ergebnis

Der Monatsblick braucht Minuten statt Tage — und es gibt genau einen Datenstand, nicht fünf Excel-Versionen.

Konsolidierte Konzernzahlen, tagesaktuelle Liquidität und ein automatisch erstellter Markt-Trendbericht: Führung mit Zahlen von heute statt von vorletzter Woche.

Die Konsolidierung stimmt auf den Cent mit der bestehenden offiziellen Auswertung überein — geprüft über sechs Geschäftsjahre. Das war die Bedingung dafür, dass das Cockpit überhaupt ernst genommen wird: Eine neue Zahl, die von der alten abweicht, wird nicht geglaubt, sondern ignoriert.

Was wir daraus gelernt haben

Der Bestandsprüfer hat uns eine Buchung vor die Füße gelegt, die jahrelang niemand gesehen hatte: eine Eröffnungsbuchung über einen zweistelligen Millionenbetrag, ohne Menge, jedes Jahr am 1. April erneut gebucht, ohne Gegenbuchung. Sie hat den Lagerwert dieser Gesellschaft um etwa das 180-Fache aufgebläht. Der Fehler lag nicht in der Auswertung. Er lag im Quellsystem. Genau dafür baut man eine Plausibilitätsprüfung: nicht um schöne Ampeln zu haben, sondern um zu erfahren, dass man einer Zahl nie hätte trauen dürfen.

Die Prognose hat sich einmal um die Richtung geirrt, nicht um die Höhe. Wir hatten den angebrochenen laufenden Monat als vollwertigen mitgezählt, zwei gebuchte Tage galten damit als vier Wochen, und aus einem Plus von acht Prozent wurde auf dem Papier ein Rückgang. Aufgefallen ist es nicht uns. Aufgefallen ist es jemandem, der die Zahl gegen sein Bauchgefühl gehalten hat. Seither endet die Auswertung am letzten abgeschlossenen Monat.

Beide Fehler haben dasselbe gemeinsam. Kein Codereview hätte sie gefunden; gefunden hat sie das Nachrechnen gegen eine unabhängige, bereits vertraute Quelle. Bei Zahlen, auf die jemand eine Entscheidung stützt, ist das keine Kür.