Eine der konsistentesten Beobachtungen aus unseren Projekten: Die größte unausgesprochene Frustration in mittelständischen Geschäftsführungen ist nicht die Software selbst, sondern das, was sie beim Blick auf die eigenen Zahlen nicht liefert.
Konkret meinen wir das Muster, bei dem die monatliche oder quartalsweise Auswertung zur Projektarbeit wird: Daten aus drei Systemen werden exportiert, in Excel zusammengeführt, händisch abgeglichen, in ein Reporting-Template übertragen, Diskrepanzen geklärt, und am Ende steht ein PDF, das - wenn es gut läuft - zwei bis drei Wochen nach dem eigentlichen Betrachtungszeitraum verfügbar ist. Bis dahin hat sich die Lage im Unternehmen längst weiterentwickelt.
Dieser Artikel beschreibt, warum das strukturell passiert, wie eine Kombination aus individueller Kernanwendung und Open-Source-Reporting das Problem löst und warum das wirtschaftlich sinnvoller ist, als es auf den ersten Blick wirkt.
Warum Standardsoftware selten saubere Zahlen liefert
Es geht in diesem Abschnitt nicht darum, Standardsoftware schlechtzureden. Es geht darum zu verstehen, warum Reporting aus einem Standardsystem strukturell an Grenzen stößt, sobald ein Unternehmen spezifische Geschäftsfragen beantworten will.
Das Datenmodell passt nicht zu Ihrer Geschäftslogik
Ein Standardsystem bildet Geschäftsvorfälle in einer generischen Struktur ab. Ein Auftrag, eine Position, ein Kunde, ein Zahlungsvorgang. Auf dieser Basis lassen sich die klassischen Kennzahlen sauber ausweisen - 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.
Diese Fragen setzen ein Datenmodell voraus, das Ihr spezifisches Geschäft kennt - nicht das generische Geschäft einer beliebigen Branche. Standardsoftware kann das nur über Custom-Felder oder externe Auswertungen abbilden. Beides erzeugt genau die Brüche, die das Reporting so mühsam machen.
Die Auswertungsschicht ist der Engpass
Selbst wenn das Datenmodell grundsätzlich tragen würde: Die Reporting-Funktionen in Standardsoftware sind oft der älteste Teil des Systems. Starre Report-Definitionen, begrenzte Filter, keine sinnvolle Verknüpfung mehrerer Datenquellen, Export-Formate, die keine Pivotierung erlauben.
Viele Unternehmen behelfen sich mit Excel als Auswertungsschicht. Das funktioniert für Momentaufnahmen, skaliert aber nicht. Die Person, die das Master-Template pflegt, wird zum Single Point of Failure. Versionen verzweigen sich. Bei Datenänderungen muss alles manuell nachgezogen werden.
Daten leben in mehreren Systemen
In der Realität liegen die Daten, die eine Geschäftsführung braucht, fast nie in einem System allein. Umsätze im ERP, Pipeline im CRM, Kosten in der Buchhaltung, Projektzeiten in einem Zeiterfassungstool, Marketingkosten in HubSpot, Hosting in einer Lieferantenrechnung. Jede dieser Datenquellen hat eigene Definitionen, 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
Der Weg, den wir in mehreren Projekten gegangen sind, kombiniert zwei Bausteine, die oft 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, die direkt auf eine Datenbank aufsetzt und sowohl Self-Service-Auswertungen als auch fertig konfigurierte Dashboards ermöglicht. Nutzer mit einem mittleren Verständnis für Daten kommen ohne SQL aus, technisch versierte Nutzer können beliebig tief gehen.
Die Kombination ist aus einem einfachen Grund stark: Wenn das Datenmodell sauber ist - weil Sie es selbst auf Ihr Geschäft zugeschnitten haben - wird Reporting trivial. Die Zeit, die in einem typischen Reporting-Projekt auf Datenaufbereitung entfällt, entfällt in dieser Konstellation komplett. Metabase macht aus einem guten Datenmodell in Stunden das, wofür klassische BI-Projekte 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 Ihr 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 realen Projekt: Ein mittelständisches Unternehmen im Professional-Services-Umfeld hatte seine Projektabrechnung und Kapazitätsplanung über Jahre in einer Standardlösung plus Excel gefahren. Die zentralen Fragen - welche Projekte sind profitabel, welche Kundensegmente tragen das Geschäft, welche Auslastung läuft wo - waren zwar irgendwo in den Daten enthalten, aber nur über mehrtägige manuelle Auswertungen zugänglich.
Der Umbau lief in drei Schritten:
Schritt 1 - Datenmodell neu entworfen. Gemeinsam mit der Geschäftsführung und den Projektverantwortlichen haben wir das Datenmodell so geschnitten, dass die eigentlich interessanten Dimensionen - Kundensegment, Projekttyp, Leistungsart, interne vs. externe Aufwände - nativ abgebildet sind. Nicht als Custom-Feld, sondern als tragende Struktur. Parallel dazu: neue Oberflächen und Arbeitsabläufe, die das Datenmodell im Alltag tragen - damit das Team die saubere Struktur nicht pflegen muss, sondern sie nebenbei entsteht.
Schritt 2 - Altdaten migriert. Die historischen Daten aus der bisherigen Standardlösung wurden mit aufgenommen. Das war bewusst - nicht um das alte System zu konservieren, sondern damit vom ersten Tag an Trendauswertungen über mehrere Jahre möglich sind. Ohne Historie wäre ein neues System ein Jahr lang blind.
Schritt 3 - Metabase angebunden. Die Geschäftsführung bekam einen Satz von Dashboards: Deckungsbeitrag pro Kundensegment, Projekt-Profitabilität im Zeitverlauf, Auslastung pro Team, Cashflow-Prognose auf Basis der Pipeline. Keine Folienpräsentation mit aufbereiteten Zahlen - ein Dashboard, das sich jederzeit live abfragen lässt.
Was bemerkenswert ist an diesem dritten Schritt: Er war der kleinste. Wenn das Datenmodell einmal sauber steht und die Arbeitsabläufe es mit tragen, kommt Reporting praktisch geschenkt. Neue Fragen, die morgen auftauchen, sind eine Abfrage von Stunden - nicht ein Projekt von Wochen.
Das Ergebnis: Die monatliche Auswertung, die vorher mehrere Personen zusammengezogen hat, wird nicht mehr gemacht. Nicht weil sie weggefallen ist - sondern weil sie dauerhaft live verfügbar ist und niemand mehr eine punktuelle Zusammenstellung braucht. Und die Organisation hat damit etwas, das über das ursprüngliche Problem hinausgeht: eine Basis, auf der sich neue Fragestellungen, Experimente und Perspektiven ausprobieren lassen, ohne dass jedes Mal ein neues IT-Projekt nötig 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
Wir hätten das gleiche Projekt auch mit einem proprietären BI-Tool machen können. Es gibt ausgereifte kommerzielle Lösungen in diesem Bereich, und sie haben ihre Berechtigung. In fast allen Projekten entscheiden wir uns trotzdem für Metabase oder vergleichbare Open-Source-Alternativen. Drei Gründe:
01
Fokus auf das eigentliche Problem
Die Tool-Auswahl ist nicht der Engpass - das Datenmodell ist es. Ein gutes Open-Source-Tool ist in zwei Tagen aufgesetzt. Wer Monate in BI-Lizenzvergleiche steckt, hat den falschen Hebel gedrückt.
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).
- Betriebskosten für die individuelle Anwendung und Metabase - in der Regel unter 50 EUR im Monat auf einem deutschen Rechenzentrums-Setup (mehr dazu im Hosting-Artikel).
- 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.
