Ihre Zahlen stecken in Systemen, die nicht zum Auswerten gebaut sind.
Abrechnung, Bestandsführung, Kernbank, IS-U: Systeme, die den Betrieb tragen — und deren Datenmodell für Fachfragen ungeeignet ist. Wir holen die Daten heraus, bringen sie in eine Form, der man trauen kann, und bauen darauf Auswertungen, Dashboards und Prognosemodelle.
Warum die Zahl im Bericht nie stimmt
Operative Systeme sind darauf ausgelegt, Vorgänge korrekt zu verarbeiten, nicht darauf, Fragen zu beantworten. Ein Vertrag wird nicht als Zeile gespeichert, sondern als Kette von Zuständen. Eine Abrechnung besteht aus Belegen, Stornos und Nachberechnungen, die sich gegenseitig aufheben. Ein Kunde kann in fünf Tabellen mit drei Nummern auftauchen.
Deshalb ist die häufigste Diagnose in unseren Projekten nicht „Sie haben zu wenig Daten“, sondern: Drei Abteilungen rechnen dieselbe Kennzahl auf drei Wegen aus und bekommen drei Ergebnisse. Alle drei sind fachlich vertretbar. Das ist kein Werkzeugproblem und wird auch von einem neuen Dashboard nicht behoben.
Ein Dashboard auf ungeklärter Fachlichkeit macht den Streit nur schneller sichtbar.
Der Weg der Daten
Kräftige Umrisse: Stellen, an denen Fachbereiche mitarbeiten und an denen die Verbindlichkeit hängt.
Anbindung der Quellsysteme
Jedes operative System hat seine Eigenheiten, und wer sie nicht kennt, baut Auswertungen, die im Detail falsch sind, ohne dass es jemand merkt. Ein paar Beispiele aus unserer Arbeit:
| System | Worauf es ankommt |
|---|---|
| SAP IS-U | Verträge, Anlagen und Geräte hängen über zeitabhängige Zuordnungen zusammen. Wer die Historie nicht mitzieht, ordnet Verbrauch dem falschen Kunden zu. Abrechnungsbelege müssen mit Stornos und Nachberechnungen zusammen betrachtet werden, sonst zählt man Umsätze doppelt. |
| SAP ERP und BW | Vorhandene Extraktoren und Modelle sind oft die schnellere Quelle als die Basistabellen — aber nicht immer die richtige. Wir prüfen beides, statt aus Gewohnheit zu entscheiden. |
| Kernbanken- und Bestandssysteme | Stichtagslogik und Buchungsschnitt bestimmen, was ein Bestand überhaupt ist. Dieselbe Zahl an zwei Tagen erhoben ergibt zwei Wahrheiten, wenn der Schnitt nicht sauber definiert ist. |
| Abrechnungssysteme | Hohe Änderungsraten, viele Korrekturen im Nachhinein. Eine Beladung, die nur neue Sätze holt, verpasst genau die Korrekturen, die den Unterschied ausmachen. |
| Alles andere | Messwerte, Dateiablagen, Zulieferungen, historisch gewachsene Auswertungen in Access oder Excel. Die gehören mit erfasst, weil dort meistens die eigentliche Fachlogik steckt. |
Grundsatz: keine Last auf dem Wirksystem. Wir extrahieren zeitgesteuert und in Änderungsschritten, nicht durch Dauerabfragen auf produktiven Tabellen. Was in der Rohschicht landet, bleibt unverändert liegen — damit man Monate später noch nachweisen kann, was das Quellsystem tatsächlich geliefert hat.
Von der Zahl zum Bericht
Ob Power BI oder Tableau, ist die kleinste der Entscheidungen — und oft ohnehin durch die Hauslandschaft vorgegeben. Beide sind gut, wenn darunter ein Modell liegt, dem man trauen kann, und beide werden zum Ärgernis, wenn jeder Bericht seine eigene Rechenlogik mitbringt.
Wir bauen deshalb zuerst die Kennzahlenschicht und erst dann die Berichte. Jede Kennzahl bekommt genau eine Definition, eine fachlich verantwortliche Person und eine nachvollziehbare Herleitung. Danach kann der Fachbereich selbst zusammenstellen, ohne dass die Zahlen auseinanderlaufen.
Ein Nebeneffekt, den viele Unternehmen unterschätzen: Erst diese Schicht macht Selbstbedienung überhaupt verantwortbar. Ohne sie ist jedes Self-Service-Werkzeug eine Maschine zur Erzeugung widersprüchlicher Berichte.
Migration bestehender Berichtslandschaften
Häufiger Fall in unseren Projekten: Es existieren hunderte gewachsener Berichte, oft in einem Werkzeug, das abgelöst werden soll. Wir empfehlen, sie nicht eins zu eins zu übertragen. Erfahrungsgemäß wird ein erheblicher Teil gar nicht mehr benutzt, und ein weiterer Teil ist die dritte Variante desselben Berichts. Am Anfang steht deshalb eine Nutzungsanalyse, nicht eine Umbauliste.
Data Science auf dieser Grundlage
Sobald Historie und Fachlogik sauber vorliegen, wird Modellierung fast zur Fleißarbeit — der schwierige Teil lag davor. Typische Anwendungen, die auf dieser Grundlage entstehen:
- Prognosen für Absatz, Last, Zahlungseingänge oder Fallzahlen, inklusive Saisonalität und Sondereffekten.
- Risiko- und Ausfallwahrscheinlichkeiten auf Basis der eigenen Historie statt zugekaufter Standardmodelle.
- Abwanderung und Kundenwert, verbunden mit der Frage, welche Maßnahme sich bei wem tatsächlich rechnet.
- Auffälligkeiten in Abrechnung, Verbrauch oder Zahlungsverhalten — inklusive der unangenehmen Fälle, die eine reine Regelprüfung übersieht.
- Preis- und Tarifanalysen, auch im Vergleich zu Marktdaten.
Wir bauen solche Modelle so, dass sie erklärbar bleiben. In Ihren Branchen ist ein Modell, dessen Entscheidung niemand begründen kann, im Zweifel nicht einsetzbar — unabhängig davon, wie gut es misst.
Und der Übergang zur KI: Der Assistent aus unserem anderen Angebot fragt genau diese Kennzahlenschicht ab, wenn jemand nach Zahlen fragt. Deshalb ist die Reihenfolge nicht beliebig — wer zuerst den Assistenten baut und die Fachlogik danach klärt, bekommt eine Anwendung, die überzeugend formuliert und trotzdem falsch antwortet.
Wie ein solches Vorhaben beginnt
Mit einer Bestandsaufnahme: welche Quellsysteme, welche bestehenden Auswertungen, welche Kennzahlen sind strittig, wo tut es aktuell am meisten weh. Am Ende steht ein Schnitt für einen ersten Ausbauschritt, der für sich genommen Nutzen bringt — und nicht ein Programm, das erst nach vielen Monaten etwas liefert.