Die größte unausgesprochene Frustration in mittelständischen Geschäftsführungen betrifft selten die Software selbst. Sie betrifft das, was beim Blick auf die eigenen Zahlen fehlt.
Gemeint ist das Muster, bei dem die Monats- oder Quartalsauswertung zur Projektarbeit wird. Daten aus drei Systemen exportieren, in Excel zusammenführen, händisch abgleichen, ins Reporting-Template übertragen, Diskrepanzen klären. Am Ende steht ein PDF, das im guten Fall zwei bis drei Wochen nach dem Betrachtungszeitraum vorliegt.
Bis dahin hat sich die Lage im Unternehmen weiterentwickelt.
Ein Maßstab dafür, wo ihr steht: APQC erhebt bei rund 2.300 Organisationen, wie lange der Monatsabschluss dauert. Der Median liegt bei 6,4 Kalendertagen, das langsamste Viertel braucht zehn Tage und mehr. Gemessen wird dort der Abschluss selbst, von der Rohbilanz bis zum fertigen Zahlenwerk. Die Auswertung, um die es hier geht, kommt danach.
Warum Standardsoftware selten saubere Zahlen liefert
Standardsoftware ist hier nicht der Schuldige. Interessant ist, warum Reporting aus einem Standardsystem an Grenzen stößt, sobald jemand spezifische Geschäftsfragen stellt. Das hat drei Ursachen, und keine davon lässt sich durch besseres Reporting-Tooling beheben.
Das Datenmodell passt nicht zu eurer Geschäftslogik
Ein Standardsystem bildet Geschäftsvorfälle generisch ab: ein Auftrag, eine Position, ein Kunde, ein Zahlungsvorgang. Für die klassischen Kennzahlen reicht das gut aus, also Umsatz, offene Posten, Auftragseingang.
Die Fragen, die wirklich interessant sind, sehen anders aus:
Deckungsbeitrag
Auf Kundensegment-Ebene, gewichtet nach strategischer Bedeutung.
Margenentwicklung
In einem neu eröffneten Produktbereich, differenziert nach Vertriebskanal.
Projekt-Profitabilität
Pro Projekttyp, unter Einbeziehung interner Aufwände, die nicht fakturiert werden.
Time-to-Cash
Abgeleitet aus Projektbeginn bis tatsächlichem Zahlungseingang.
Solche Fragen setzen ein Datenmodell voraus, das euer Geschäft kennt statt das einer beliebigen Branche. Standardsoftware löst das über Custom-Felder oder externe Auswertungen. Beides erzeugt genau die Brüche, die das Reporting mühsam machen.
Die Auswertungsschicht ist der Engpass
Selbst wenn das Datenmodell tragen würde: Die Reporting-Funktionen sind in Standardsoftware oft der älteste Teil des Systems. Starre Report-Definitionen, begrenzte Filter, keine brauchbare Verknüpfung mehrerer Quellen, Exportformate, aus denen sich keine Pivot-Tabelle bauen lässt.
Viele behelfen sich mit Excel als Reporting-Schicht. Für eine Momentaufnahme reicht das. Auf Dauer wird die Person, die das Master-Template pflegt, zum Single Point of Failure, Versionen verzweigen sich, und jede Datenänderung muss von Hand nachgezogen werden.
Wie fehleranfällig solche gewachsenen Tabellen sind, ist gut untersucht. Ray Panko hat Prüfberichte zu 85 Tabellen aus dem laufenden Betrieb zusammengetragen, jede über mehrere Tage von Auditoren durchgesehen. In 94 Prozent fand sich mindestens ein Fehler. Das heißt weder, dass jede dieser Tabellen falsche Ergebnisse lieferte, noch dass eure fehlerhaft ist. Es heißt, dass eine Tabelle, die niemand systematisch prüft, statistisch gesehen Fehler enthält, und dass ihre Qualität an der Sorgfalt einer einzigen Person hängt.
Daten leben in mehreren Systemen
Die Daten, die eine Geschäftsführung braucht, liegen fast nie in einem einzigen System. Umsätze im ERP, Pipeline im CRM, Kosten in der Buchhaltung, Projektzeiten in der Zeiterfassung, Marketingkosten in HubSpot, Hosting auf einer Lieferantenrechnung. Jede Quelle bringt eigene Definitionen mit, eigene Stammdatenschlüssel, eigene Zeitstempel.
Die Zusammenführung ist der eigentliche Aufwand. Und sie ist selten einmalig - jeden Monat neu.
Ausgangslage
Typische Systemlandschaft im Mittelstand: Jedes System ist für sich gut - das Gesamtbild entsteht nur über manuelle Zusammenführung.
Der Ansatz: Kernlogik individuell, Auswertung mit erprobten Open-Source-Bausteinen
In mehreren Projekten haben wir zwei Bausteine kombiniert, die meist getrennt gedacht werden:
Baustein 1 - eine individuelle Kernanwendung, die genau die Geschäftsprozesse abbildet, die das Unternehmen ausmachen. Das Datenmodell ist auf die spezifischen Fragen des Hauses zugeschnitten, nicht generisch. Die Anwendung wird zur einzigen Quelle der Wahrheit für ihren Scope.
Baustein 2 - Metabase als Reporting-Layer. Metabase ist eine Open-Source-Plattform für Business Intelligence. Sie setzt direkt auf der Datenbank auf und liefert sowohl fertige Dashboards als auch Self-Service-Auswertungen. Wer mit Daten umgehen kann, kommt ohne SQL aus. Wer SQL kann, geht so tief wie nötig.
Die Kombination wirkt aus einem einfachen Grund: Ist das Datenmodell sauber, weil ihr es selbst auf euer Geschäft zugeschnitten habt, wird Reporting zur Nebensache. Der Aufwand, der in klassischen BI-Projekten in die Datenaufbereitung fließt, fällt hier weg. Metabase liefert dann in Stunden, wofür solche Projekte sonst Monate brauchen.
Vorher
Zahlen aus jedem System einzeln
Jeden Monat neu. Fehleranfällig. Verzögert.
Mit RocketBase
Eine Quelle, ein Dashboard
Individuelle Kernanwendung
Datenmodell auf euer Geschäft zugeschnitten
Metabase-Dashboards
Live-Auswertung statt Monatsprojekt
Einmal sauber modelliert. Danach dauerhaft tragfähig.
Was das in der Praxis heißt
Ein Beispiel aus einem echten Projekt. Ein mittelständisches Unternehmen im Professional-Services-Umfeld fuhr Projektabrechnung und Kapazitätsplanung über Jahre mit einer Standardlösung plus Excel. Die zentralen Fragen steckten irgendwo in den Daten: welche Projekte profitabel sind, welche Kundensegmente das Geschäft tragen, wo wie viel Auslastung liegt. Herausholen ließ sich das nur über mehrtägige manuelle Auswertungen.
Der Umbau lief in drei Schritten:
Schritt 1 - Datenmodell neu entworfen. Mit der Geschäftsführung und den Projektverantwortlichen haben wir das Modell so geschnitten, dass die interessanten Dimensionen direkt darin stecken: Kundensegment, Projekttyp, Leistungsart, interne und externe Aufwände. Als tragende Struktur, nicht als Custom-Feld. Dazu kamen Oberflächen und Arbeitsabläufe, in denen diese Struktur nebenbei entsteht, statt vom Team gepflegt werden zu müssen.
Schritt 2 - Altdaten migriert. Die Historie aus der bisherigen Standardlösung kam mit. Das war eine bewusste Entscheidung: Nur so sind vom ersten Tag an Trendauswertungen über mehrere Jahre möglich. Ohne Historie bleibt ein neues System ein Jahr lang blind.
Schritt 3 - Metabase angebunden. Die Geschäftsführung bekam Dashboards für Deckungsbeitrag pro Kundensegment, Projekt-Profitabilität im Zeitverlauf, Auslastung pro Team und eine Cashflow-Prognose auf Basis der Pipeline. Jederzeit live abrufbar, statt einmal im Monat als Foliensatz.
Der dritte Schritt war der kleinste. Steht das Datenmodell sauber und tragen die Arbeitsabläufe es mit, kommt Reporting fast geschenkt. Eine neue Reporting-Frage kostet dann Stunden statt Wochen.
Die monatliche Auswertung, an der vorher mehrere Leute saßen, gibt es heute nicht mehr. Sie ist dauerhaft live verfügbar, und damit braucht niemand mehr eine punktuelle Zusammenstellung.
Geblieben ist etwas, das über das ursprüngliche Problem hinausgeht: eine Basis, auf der sich neue Fragen ausprobieren lassen, ohne dass daraus jedes Mal ein IT-Projekt wird.
Vorher
4–8 Stunden
Einmal im Monat Zahlen aus dem System exportieren, ins Excel-Modell kippen, Abweichungen klären, versenden.
Nachher
Live.
Dashboard jederzeit abrufbar. Kein manueller Aufwand. Entscheidungen auf Basis aktueller Zahlen.
Warum wir uns nicht mit Tooling aufhalten
Dasselbe Projekt wäre mit einem proprietären BI-Tool ebenfalls machbar gewesen. Die kommerziellen Lösungen sind ausgereift und haben ihre Berechtigung. Trotzdem fällt unsere Wahl fast immer auf Metabase oder eine vergleichbare Open-Source-Alternative. Drei Gründe:
01
Fokus auf das eigentliche Problem
Der Engpass ist das Datenmodell, nicht die Tool-Auswahl. Ein gutes Open-Source-Tool steht in zwei Tagen. Wer Monate in BI-Lizenzvergleiche steckt, arbeitet am falschen Hebel.
02
Keine Lizenzfalle
Unsere Kunden sollen nach dem Projekt nicht an uns oder einen BI-Hersteller gebunden sein. Metabase können sie selbst betreiben, erweitern, anpassen. Wenn sie uns irgendwann nicht mehr brauchen, ist das in Ordnung.
03
Transparenz im Datenfluss
Bei Open-Source-Bausteinen können wir bis auf die Ebene der Abfragelogik zeigen, was passiert. Das hilft in Entwicklung und Betrieb - und es hilft den Kunden, die Verantwortung für ihre Zahlen wirklich zu übernehmen.
Das ist keine ideologische Präferenz. Wir setzen kommerzielle Software ein, wo sie eindeutig das bessere Werkzeug ist. Aber im Bereich Reporting ist die Open-Source-Landschaft heute so reif, dass es schwierig ist, gute Gründe für die teureren Alternativen zu finden.
Wirtschaftlich: was kostet das, was spart es
Die Kostenrechnung, die unsere Kunden typischerweise aufmachen, sieht ungefähr so aus:
Was entfällt
- Lizenzkosten für Reporting-Module der Bestandssysteme, die nie wirklich genutzt wurden.
- Interne Arbeitszeit für monatliche und quartalsweise Zusammenstellungen - je nach Unternehmensgröße grob 3–5 Personentage pro Monat.
- Externe Dienstleister, die diese Aufbereitung teilweise übernommen haben.
- Opportunitätskosten verspäteter Entscheidungen, weil Zahlen erst mit Verzug vorliegen.
Was entsteht
- Projekt-Investition in die individuelle Kernanwendung (Größenordnung je nach Scope).
- Serverkosten für die individuelle Anwendung und Metabase - in der Regel 50 bis 100 EUR im Monat auf einem deutschen Rechenzentrums-Setup (mehr dazu im Hosting-Artikel). Betreuung und Weiterentwicklung kommen hinzu.
- Einmalige Einarbeitung der Nutzer in das Dashboard-Konzept.
Das Projekt-Investment ist real und nicht klein. Aber es ist eine einmalige Investition, die eine laufende, teurer werdende Aufwandslinie ersetzt. Die Amortisationsrechnung entscheidet sich in der Regel nicht an Lizenzen, sondern an der eingesparten Arbeitszeit plus an Entscheidungen, die schneller und auf besserer Grundlage getroffen werden.
Ein ehrlicher Einwand
Nicht jedes Unternehmen braucht eine individuelle Anwendung für saubere Zahlen. Manchmal reicht es, ein gutes BI-Tool auf eine bestehende Standardsoftware aufzusetzen, die Datenqualität an den Rändern zu verbessern und damit zu leben, dass bestimmte Auswertungen Näherungen bleiben.
Wir empfehlen diesen Weg aktiv, wenn das Kerngeschäft nicht von den Reporting-Fragen abhängt und wenn die bestehenden Systeme grundsätzlich sauber sind. Die volle Kombination - individuelle Kernanwendung plus Reporting-Layer - lohnt sich dort, wo die Geschäftsfragen spezifisch sind, wo die Daten heute über mehrere Systeme verteilt sind und wo die Geschäftsführung das Reporting als echtes Steuerungsinstrument nutzen will.
Quellen
Perry D. Wiggins, Metric of the Month: Cycle Time for Monthly Close
, CFO.com, 5. März 2018. Benchmarking von APQC unter 2.300 Organisationen. Median 6,4 Kalendertage von der Rohbilanz bis zum fertigen Abschluss, das langsamste Viertel braucht zehn Tage und mehr.
Raymond R. Panko, What We Don’t Know About Spreadsheet Errors Today
, EuSpRIG 2015. Zusammenfassung mehrerer Prüfstudien zu 85 Tabellen aus dem laufenden Betrieb. In 94 Prozent wurde mindestens ein Fehler gefunden.
