Wann lohnt sich eine gemeinsame Datenplattform, wenn 3 Abteilungen eigene Daten haben?

Eine gemeinsame Datenplattform lohnt sich, wenn mehrere Abteilungen dieselben Geschäftsobjekte und Kennzahlen verwenden, ihre Daten aber unterschiedlich definieren, aufbereiten oder auswerten. Entscheidend ist nicht die Anzahl der vorhandenen Systeme, sondern der Aufwand, der durch widersprüchliche Datenbestände, manuelle Abstimmungen und parallele Reports entsteht. Eine Plattform kann diese Probleme reduzieren, sofern sie auf gemeinsamen fachlichen Definitionen und klarer Verantwortung aufbaut.

Für ein Schweizer KMU mit drei Abteilungen bedeutet das nicht, sämtliche Systeme gleichzeitig abzulösen. Ein schrittweiser Aufbau ist häufig realistischer: Zuerst werden zentrale Datenbegriffe und Verantwortlichkeiten geklärt, danach eine geeignete Architektur gewählt und anschliessend ausgewählte Datenquellen parallel zur bestehenden Reporting-Landschaft integriert. So bleibt das operative Reporting verfügbar, während die neue Umgebung überprüft wird.

Die eigentliche Herausforderung liegt in der Verbindung von Datenarchitektur und organisatorischer Governance. Ohne diese Grundlage kann eine neue Plattform bestehende Silos lediglich technisch zentralisieren, statt sie fachlich aufzulösen.

Warum Silos bleiben, obwohl alle im selben ERP arbeiten?

Datensilos bleiben auch bei einem gemeinsamen ERP bestehen, weil einheitliche Transaktionsprozesse nicht automatisch einheitliche fachliche Definitionen schaffen. Vertrieb, Finance und Service können dieselben Kunden- und Produktdaten verwenden, ihnen aber unterschiedliche Attribute, Bedeutungen und Auswertungsregeln zuweisen. Das Problem entsteht somit häufig nicht durch fehlende technische Integration, sondern durch fehlende semantische Abstimmung.

Ein ERP-System vereinheitlicht beispielsweise die Erfassung von Aufträgen, Rechnungen und Kundendaten. Es entscheidet jedoch nicht zwangsläufig, welche Kennzahl eine Abteilung unter dem Begriff Umsatz versteht. Der Vertrieb kann den Umsatz anhand des Auftragseingangs auswerten, Finance anhand der Rechnungsstellung und Service anhand der wirtschaftlichen Leistung eines Mandats. Alle drei Auswertungen können intern nachvollziehbar sein, obwohl sie unterschiedliche Ergebnisse liefern.

Hinzu kommen lokale Arbeitsweisen. In Schweizer KMU mit historisch gewachsenen SAP- oder Abacus-Umgebungen entstehen zusätzliche Datenbestände beispielsweise durch Excel-Exporte, manuelle Ergänzungen und abteilungsspezifische Auswertungen. Ein Systemwechsel allein beseitigt diese Strukturen nicht, wenn die bisherigen Arbeitsweisen unverändert weitergeführt werden.

Ein einfacher Diagnosetest macht das Problem sichtbar: Fragen Sie drei Abteilungen nach der Anzahl aktiver Kunden. Erhalten Sie drei unterschiedliche Zahlen, sollte zunächst geklärt werden, ob beispielsweise inaktive Kunden, offene Verträge oder bestimmte Zeiträume unterschiedlich behandelt werden.

Die Diagnose sollte deshalb drei Ebenen unterscheiden:

• Technische Integration: Können die Systeme Daten austauschen?
• Fachliche Semantik: Werden Kunden, Produkte und Kennzahlen gleich definiert?
• Verantwortlichkeit: Wer entscheidet bei widersprüchlichen Definitionen?

Eine gemeinsame Plattform adressiert vor allem die zweite und dritte Ebene. Sie kann Daten aus unterschiedlichen Quellen zusammenführen, aber nicht eigenständig entscheiden, welche fachliche Interpretation verbindlich sein soll.

Genau deshalb beginnt die Konsolidierung mit der Frage, welche Geschäftsobjekte gemeinsam verantwortet werden müssen. Eine solche Zuordnung verhindert, dass die neue Plattform lediglich drei bestehende Datenwelten in einer technischen Umgebung zusammenführt.

Wenn mehrere Abteilungen dieselben Objekte unterschiedlich interpretieren, braucht es keine pauschale Vereinheitlichung sämtlicher Daten. Benötigt werden stabile fachliche Domänen, in denen Definitionen und Qualitätsregeln verbindlich festgelegt werden.

Wie schneiden Sie Daten in 6 Domänen, damit Ownership klar wird?

Eine praktikable Domänenstruktur orientiert sich an stabilen Geschäftsobjekten und nicht an den vorhandenen Abteilungen oder IT-Systemen. Für ein Unternehmen mit drei Abteilungen können sechs Ausgangsdomänen sinnvoll sein: Kunde, Produkt, Finanzbuchung, Personal, Vorgang und Referenzdaten. Diese Einteilung ist ein Architekturvorschlag, keine universell gültige Vorgabe.

Der Vorteil dieses Ansatzes liegt in der abteilungsübergreifenden Verantwortung. Kundendaten werden beispielsweise von Vertrieb, Finance und Service benötigt. Werden sie ausschliesslich dem Vertrieb zugeordnet, entstehen möglicherweise erneut unterschiedliche Kundenstammdaten und parallele Qualitätsregeln. Eine eigenständige Kundendomäne schafft dagegen einen gemeinsamen fachlichen Bezugspunkt.

Eine mögliche Ausgangsstruktur sieht so aus:

Die endgültige Abgrenzung hängt von den Geschäftsprozessen ab. Eine Domäne kann mehrere Systeme umfassen; umgekehrt kann ein ERP-System Daten aus verschiedenen Domänen enthalten.

Wichtig ist die Unterscheidung zwischen fachlicher und technischer Verantwortung. Ein Data Owner entscheidet über die fachliche Bedeutung, Qualität und Nutzung eines Datenbestands. Ein Data Steward unterstützt die Umsetzung von Standards, Glossaren und Qualitätskontrollen. Ein Data Custodian verantwortet die technische Erfassung, Speicherung und Verarbeitung. Für die Plattform selbst kann zusätzlich eine Product- oder Service-Owner-Rolle sinnvoll sein.

Dieses Rollenverständnis entspricht dem institutionellen Data ownership model des Government Digital Service. Das Modell stammt aus dem britischen öffentlichen Sektor und ist keine Schweizer Rechtsvorschrift. Es bietet jedoch eine nachvollziehbare Grundlage, um fachliche und technische Verantwortlichkeiten auseinanderzuhalten.

Für die praktische Umsetzung kann ein halbtägiger Workshop mit Vertretern der drei Abteilungen als Startpunkt dienen. Dabei werden die sechs Domänen diskutiert, zentrale Geschäftsbegriffe festgehalten und die wichtigsten Kennzahlen zugeordnet. Das Format ist ein pragmatischer Organisationsvorschlag, keine wissenschaftlich validierte Standardmethode.

Ein häufiger Fehler ist die Orientierung an der aktuellen Projektorganisation. Marketing erhält beispielsweise eine eigene Datendomäne, obwohl die zugrunde liegenden Kundengrunddaten mit Vertrieb und Service identisch sind. Dadurch entstehen zusätzliche Datenflüsse und spätere Zusammenführungsprobleme.

Die Domänenstruktur sollte deshalb danach bewertet werden, ob sie langfristig stabile Geschäftsobjekte abbildet und gemeinsame Datenmodelle ermöglicht. Erst mit dieser Grundlage lässt sich sinnvoll entscheiden, welche Plattformarchitektur erforderlich ist.

Für die Plattformauswahl ist anschliessend entscheidend, welche Datenarten verarbeitet werden und welche Analysen tatsächlich benötigt werden. Eine möglichst komplexe Architektur ist nicht automatisch die zukunftssicherste Lösung.

Data Warehouse oder Data Lakehouse: Was passt bei 20 Quellen und 5 KPI-Reports?

Bei 20 Datenquellen und fünf überwiegend strukturierten KPI-Reports kann ein Data Warehouse ein angemessener Ausgangspunkt sein. Ausschlaggebend ist nicht die Zahl der Quellen, sondern der Analysebedarf: Wenn relationale Daten, definierte Kennzahlen und verlässliches Reporting im Vordergrund stehen, bietet ein Warehouse eine gut strukturierbare Grundlage. Ein Lakehouse wird interessanter, wenn zusätzlich unstrukturierte Daten oder Spark-basierte Analyseverfahren konkret vorgesehen sind.

Ein Data Warehouse organisiert Daten für strukturierte Analysen und standardisierte Berichte. Daten werden typischerweise modelliert, fachlich zugeordnet und für wiederkehrende Auswertungen bereitgestellt. Das passt insbesondere zu Finanzkennzahlen, Umsatzberichten, Kundenanalysen und Management-Dashboards.

Ein Data Lakehouse verbindet dagegen die Verarbeitung strukturierter und unstrukturierter Daten mit flexibleren Analyse- und Entwicklungsverfahren. Dazu gehören beispielsweise Textdaten, Sensordaten oder geplante Machine-Learning-Anwendungen. Die Architektur kann damit unterschiedliche Datenverarbeitungsanforderungen abdecken.

Die technische Entscheidungshilfe von Microsoft beschreibt diese Unterschiede in der Dokumentation Microsoft Fabric decision guide für Warehouse und Lakehouse. Sie bezieht sich ausdrücklich auf Microsoft Fabric und ist deshalb kein neutraler Kostenvergleich aller verfügbaren Plattformtechnologien.

Die Auswahl sollte zusätzlich die organisatorische Betriebsfähigkeit berücksichtigen. Ein Warehouse benötigt klare Datenmodelle und gepflegte Definitionen. Ein Lakehouse erfordert ebenfalls Qualitätskontrollen, Katalogisierung und nachvollziehbare Datenverarbeitung. Welche Lösung wirtschaftlicher ist, lässt sich nicht allein aus der Anzahl der Quellen ableiten.

Für Schweizer Unternehmen gehört ausserdem die datenschutzrechtliche Prüfung in die Architekturentscheidung. Das revidierte Datenschutzgesetz (revDSG) regelt unter anderem die Bekanntgabe von Personendaten ins Ausland. Nach Artikel 16 DSG ist eine solche Übermittlung grundsätzlich zulässig, wenn im Empfängerland ein angemessenes Datenschutzniveau besteht oder geeignete Schutzgarantien vorliegen.

Der EDÖB informiert über die Bekanntgabe von Personendaten ins Ausland. Daraus folgt keine allgemeine Pflicht, sämtliche Unternehmensdaten ausschliesslich in der Schweiz zu speichern. Entscheidend sind die konkreten Empfängerländer, Übermittlungsbedingungen und Schutzgarantien. Datenlokalisierung kann eine Beschaffungsanforderung sein, sollte aber nicht mit einer pauschalen gesetzlichen Pflicht gleichgesetzt werden.

Auch ein Vendor-Lock-in verdient Aufmerksamkeit. Vor der Auswahl sollten deshalb Datenexportmöglichkeiten, Schnittstellen, dokumentierte Datenmodelle und die Übertragbarkeit zentraler Geschäftsdefinitionen geprüft werden. Die Plattform sollte nicht zum einzigen Ort werden, an dem fachliche Regeln überhaupt nachvollziehbar sind.

Steht die Architektur fest, rückt ein anderer Risikofaktor in den Vordergrund: die Datenqualität. Sie lässt sich nicht durch möglichst viele Bereinigungsprozesse verbessern, wenn die fachlichen Regeln dahinter ungeklärt bleiben.

Der Plattform-Fehler, der 80% der Zeit in Datenbereinigung verschiebt

Die im Titel genannte Zahl von 80 Prozent ist kein belegter allgemeiner Projektbenchmark. Das entscheidende Fehlermuster besteht darin, Daten vor der Klärung ihrer fachlichen Bedeutung technisch zu bereinigen. Ohne verbindliche Definitionen und Verantwortlichkeiten wird jede neue Datenquelle erneut manuell korrigiert. Die Bereinigung bleibt dadurch ein wiederkehrender Vorlauf statt eines kontrollierten Qualitätsprozesses.

Ein typisches Beispiel sind unterschiedliche Kundenschlüssel. Das ERP führt eine Kundenidentität, der Service verwendet eine eigene Referenz und ein Excel-Export enthält zusätzliche manuelle Zuordnungen. Werden diese Bestände ohne gemeinsame Identifikationsregeln zusammengeführt, muss das Data-Team die Beziehungen für jede neue Quelle erneut rekonstruieren.

Das Problem liegt dann nicht nur in unvollständigen oder fehlerhaften Datensätzen. Es fehlt eine gemeinsame Regel, welche Identität als gültig gilt, welche Attribute verbindlich sind und wie widersprüchliche Werte behandelt werden.

Die Gegenmassnahme beginnt mit den wichtigsten Geschäftsbegriffen. Für zwei bis drei zentrale Berichte, beispielsweise Umsatz und aktive Kunden, sollten zunächst die fachlichen Definitionen verbindlich festgelegt werden. Anschliessend lassen sich technische Bereinigungsregeln daraus ableiten.

Eine Qualitätsregel muss messbar sein. Beispielsweise kann festgelegt werden, dass eine Kundenidentität eindeutig sein muss oder dass bestimmte Pflichtfelder nicht leer bleiben dürfen. Die konkrete Regel hängt vom Verwendungszweck der Daten ab.

Das Data quality issues framework des Government Digital Service empfiehlt, Qualitätsanforderungen anhand des Datenzwecks festzulegen, messbare Zielwerte zu definieren und Probleme nach ihren geschäftlichen Auswirkungen zu priorisieren. Das Framework stammt aus dem britischen öffentlichen Sektor und liefert keinen Schweizer Branchenbenchmark für Bereinigungsaufwände.

Für die operative Plattformarbeit ergibt sich daraus ein wiederverwendbarer Ablauf:

1. Geschäftliche Bedeutung und Verwendungszweck der Daten festlegen.
2. Qualitätsdimensionen wie Vollständigkeit und Genauigkeit definieren.
3. Messbare Qualitätsregeln und Zielwerte dokumentieren.
4. Probleme nach ihren Auswirkungen auf Geschäftsprozesse und Berichte priorisieren.
5. Ursachen analysieren und Verbesserungen kontrolliert umsetzen.

Ein wichtiges Warnsignal ist ein Data-Team, das mehr Zeit mit Rückfragen zu Begriffen verbringt als mit der Umsetzung und Überwachung seiner Datenpipelines. Dann fehlt meist eine verbindliche fachliche Entscheidungsstruktur.

Wenn Geschäftsdefinitionen und Qualitätsregeln feststehen, kann die technische Migration schrittweise erfolgen. Entscheidend ist dabei, die bestehende Reporting-Versorgung während des Übergangs nicht zu unterbrechen.

In welcher Reihenfolge migrieren Sie 4 Datenquellen, ohne Reporting-Ausfall?

Vier Datenquellen sollten in einer Reihenfolge migriert werden, die sich an ihrer geschäftlichen Bedeutung und ihren Abhängigkeiten orientiert. Beginnen Sie nicht automatisch mit der technisch einfachsten Quelle. Priorisieren Sie jene Datenbasis, die wichtige KPI-Berichte speist und deren erfolgreiche Integration den grössten überprüfbaren Nutzen für die neue Plattform liefert.

Ein risikoarmer Ansatz ist die parallele Migration. Die bestehende Reporting-Umgebung bleibt zunächst aktiv, während die neue Plattform aufgebaut und mit ausgewählten Datenquellen verbunden wird. Beide Umgebungen liefern während einer definierten Übergangsphase vergleichbare Ergebnisse. Erst nach fachlicher Validierung und vollständigem Abgleich wird die alte Verarbeitung für den jeweiligen Anwendungsfall stillgelegt.

Für vier Quellen lässt sich die Migration beispielsweise in folgende Phasen aufteilen:

Diese Reihenfolge ist ein Planungsbeispiel, keine universell gültige Migrationsvorgabe. Sind bestimmte Quellen voneinander abhängig, muss die Reihenfolge entsprechend angepasst werden. Eine Quelle, die beispielsweise einen notwendigen Kundenschlüssel liefert, kann vor einer umsatzbezogenen Quelle benötigt werden.

Besonders kritisch sind individuelle Erweiterungen im Legacy-System. Kundenindividuelle Feldlogik im ERP, historische Zuordnungen oder spezielle Filter können erst bei der Datenübernahme sichtbar werden. Deshalb sollte jede Quelle eine Probe-Migration mit vollständigem Abgleich durchlaufen.

Eine reine Stichprobe reicht nicht aus, um alle relevanten Abweichungen auszuschliessen. Der Abgleich sollte je nach Datenbestand beispielsweise Datensatzanzahl, Schlüsselzuordnungen, Summenwerte, Zeiträume und relevante Ausnahmefälle berücksichtigen. Die fachlichen Prüfkriterien sind vor Beginn der Migration festzulegen.

Die Rollen müssen dabei getrennt bleiben: IT beziehungsweise Data Engineering verantwortet Pipelines, technische Verarbeitung und Überwachung. Die Data Owner validieren fachliche Ergebnisse und entscheiden, ob die Daten für ihre Geschäftsprozesse korrekt sind. Eine unabhängige fachliche Freigabe verhindert, dass technische Funktionstests mit einer inhaltlichen Abnahme verwechselt werden.

Ein paralleler Betrieb darf allerdings nicht unbegrenzt weiterlaufen. Vor der Migration braucht es deshalb einen definierten Termin und nachvollziehbare Bedingungen für die Abschaltung der bisherigen Datenverarbeitung. Andernfalls entstehen doppelte Betriebskosten und neue Unsicherheiten über die jeweils gültige Datenversion.

Auch nach einer erfolgreichen technischen Migration können Kennzahlen voneinander abweichen. Deshalb muss die fachliche Vergleichbarkeit der Reports als eigener Arbeitsschritt behandelt werden.

Warum zwei Reports 2 verschiedene Umsätze zeigen und keiner recht hat?

Zwei Umsatzberichte können unterschiedliche Ergebnisse liefern, obwohl beide technisch korrekt sind. Häufig unterscheiden sie sich im zeitlichen Bezug, etwa durch Auftragseingang, Rechnungsdatum oder Buchungsdatum. Auch Stornos, Rabatte und Skonti beeinflussen die Berechnung. Solange die zugrunde liegenden Definitionen nicht identisch sind, ist eine unterschiedliche Zahl nicht automatisch ein Datenfehler.

Ein Beispiel verdeutlicht den Unterschied: Der Vertriebsbericht weist den Wert eingegangener Aufträge aus. Finance betrachtet dagegen die tatsächlich gestellten Rechnungen. Der Servicebericht berücksichtigt möglicherweise die im Berichtszeitraum erfasste Leistung. Diese drei Kennzahlen beziehen sich auf unterschiedliche wirtschaftliche Ereignisse und sollten deshalb nicht ohne Weiteres unter derselben Bezeichnung verglichen werden.

Die Lösung besteht darin, Umsatz als Familie klar benannter Kennzahlen zu definieren. Dazu können gehören:

• Auftragsumsatz: Wert der eingegangenen Aufträge nach vereinbarter Definition.
• Rechnungsumsatz: Wert der ausgestellten Rechnungen im definierten Zeitraum.
• Erfasster Umsatz: Umsatz gemäss der festgelegten buchhalterischen oder leistungsbezogenen Abgrenzung.

Für jede Kennzahl müssen Bezugszeitraum, Berechnungsgrundlage und Behandlung von Sonderfällen dokumentiert sein. Dazu zählen insbesondere Stornierungen, Gutschriften, Skonti und Rabatte. Ohne diese Angaben bleibt selbst ein zentral bereitgestelltes Datenmodell mehrdeutig.

Eine praktische Differenzanalyse beginnt mit dem Vergleich zweier Reports. Zunächst wird der Unterschied in absoluten Zahlen und, sofern sinnvoll, relativ zur jeweiligen Basis quantifiziert. Anschliessend werden die Abweichungen systematisch nach drei möglichen Ursachen untersucht:

1. Unterschiedliche Zeitpunkte wie Rechnungsdatum und Buchungsdatum.
2. Abweichende Behandlung von Stornos und Gutschriften.
3. Unterschiedliche Berücksichtigung von Skonti und Rabatten.

Wenn sich die Differenz überwiegend durch eine dieser Kategorien erklären lässt, ist eine fachliche Definitionsentscheidung erforderlich. Eine technische Korrektur wäre erst dann angebracht, wenn eine Berechnung von der freigegebenen Definition abweicht.

Die gemeinsame Plattform sollte diese unterschiedlichen Kennzahlen nicht künstlich auf einen einzigen Wert reduzieren. Ihre Aufgabe besteht darin, die fachlich freigegebenen Berechnungen transparent und reproduzierbar bereitzustellen. Ein Datenkatalog mit eindeutigen Namen und Definitionen hilft, Missverständnisse zwischen den Abteilungen zu vermeiden.

Nach der Migration ist die Differenzanalyse eine wichtige Bewährungsprobe: Wenn zwei Reports weiterhin voneinander abweichen, muss geprüft werden, ob die Unterschiede fachlich beabsichtigt sind oder ob die technische Umsetzung die vereinbarte Definition verletzt.

Mit einem abgestimmten KPI-Modell kann anschliessend entschieden werden, welche Auswertungen zentral bereitgestellt und welche Analysen den Fachabteilungen selbst überlassen werden.

Self-Service-BI oder zentraler BI-Ansatz: Was passt bei 5 Abteilungen?

Bei fünf Abteilungen ist ein hybrider BI-Ansatz häufig die praktikabelste Lösung. Zentrale Teams stellen geprüfte Datendomänen, einheitliche Kennzahlen und standardisierte Management-Reports bereit. Die Fachabteilungen können darauf aufbauend eigene Ansichten und explorative Auswertungen erstellen. So bleibt die fachliche Grundlage konsistent, ohne jede individuelle Analyse zentral entwickeln zu müssen.

Ein vollständig zentralisiertes BI-Modell bietet hohe Kontrolle über Datenmodelle und Kennzahlen. Es kann jedoch zum Engpass werden, wenn jede neue Fragestellung über das zentrale Data-Team laufen muss. Fachabteilungen müssen dann auf Berichte warten, obwohl die benötigten Daten bereits vorhanden und freigegeben sind.

Ein vollständig dezentrales Self-Service-Modell hat das gegenteilige Risiko. Jede Abteilung baut eigene Datenmodelle, Filter und Kennzahlen. Werden neue Definitionen ohne zentrale Abstimmung eingeführt, entstehen genau jene Semantik-Silos, die durch die gemeinsame Plattform eigentlich beseitigt werden sollten.

Das hybride Modell trennt deshalb die Bereitstellung verlässlicher Daten von ihrer individuellen Nutzung:

Die zentrale Data-Funktion verantwortet somit Datenpipelines, freigegebene Datenmodelle und technische Qualitätssicherung. Die Fachabteilungen verantworten ihre fachlichen Anforderungen und erstellen darauf aufbauend eigene Auswertungen. Neue Kennzahlen oder Datenquellen müssen dagegen einen zentral abgestimmten Definitions- und Freigabeprozess durchlaufen.

Für Schweizer Unternehmen ist die Zugriffskontrolle besonders relevant, wenn Personaldaten oder andere personenbezogene Informationen über Self-Service-Berichte verfügbar gemacht werden. Das revDSG verlangt eine sorgfältige Behandlung personenbezogener Daten. Zugriffsrechte, Berechtigungsgruppen und dokumentierte Freigaben sollten deshalb bereits im Datenmodell und nicht erst in einzelnen Reports berücksichtigt werden.

Ein konkretes Entscheidungskriterium lautet: Self-Service eignet sich für Fragestellungen, die sich aus bereits definierten Kennzahlen und freigegebenen Datensätzen ableiten lassen. Sobald neue Datenquellen, fachliche Definitionen oder sensible Zugriffsrechte betroffen sind, sollte die zentrale Governance eingebunden werden.

So kann beispielsweise die Vertriebsabteilung eine zusätzliche regionale Umsatzansicht erstellen, ohne die zentrale Definition des Rechnungsumsatzes zu verändern. Eine neue Definition von aktivem Kunden wäre dagegen zunächst fachlich zu klären und anschliessend zentral zu dokumentieren.

Damit diese Aufgabenteilung dauerhaft funktioniert, müssen die wichtigsten Kennzahlen verbindlich definiert werden. Ohne einen solchen gemeinsamen Bezugspunkt verliert auch eine technisch gut organisierte Plattform schnell das Vertrauen ihrer Nutzer.

Warum BI-Systeme scheitern, wenn niemand 1 KPI eindeutig definiert

Ein BI-System verliert Vertrauen, wenn eine zentrale Kennzahl von verschiedenen Abteilungen unterschiedlich interpretiert wird. Bereits eine einzige ungeklärte KPI kann dazu führen, dass Fachbereiche eigene Berechnungen entwickeln und lokale Excel-Berichte als verlässlichere Alternative verwenden. Die technische Qualität der Plattform schützt nicht vor diesem Problem, wenn die fachliche Bedeutung der Zahlen offenbleibt.

Der Mechanismus ist einfach: Ein Management-Bericht zeigt einen Umsatzwert, während Finance und Vertrieb ihre eigenen Berechnungen kennen. Entsteht ein Widerspruch, wird zunächst manuell nachgerechnet. Die daraus entstehenden Excel-Dateien werden weitergegeben, ergänzt und bei späteren Entscheidungen erneut verwendet. Mit der Zeit entsteht eine Parallelwelt, in der niemand mehr sicher weiss, welche Berechnung verbindlich ist.

Deshalb sollte jede zentrale KPI vor ihrer technischen Implementierung schriftlich definiert werden. Eine belastbare Definition enthält mindestens fünf Bestandteile:

Die Definition muss von den betroffenen Fachbereichen bestätigt werden. Für den Rechnungsumsatz bedeutet das beispielsweise, dass Finance die buchhalterische Logik prüft, während Vertrieb sicherstellt, dass die Kennzahl nicht irrtümlich mit dem Auftragseingang gleichgesetzt wird.

Ein zentraler KPI-Katalog sollte diese Informationen dauerhaft dokumentieren. Er kann Bestandteil des Datenkatalogs sein und mit den freigegebenen Datenmodellen verknüpft werden. Änderungen an einer Berechnung sollten nachvollziehbar dokumentiert und von den zuständigen Verantwortlichen freigegeben werden.

Für die Einführung einer gemeinsamen Datenplattform ergibt sich daraus eine klare Reihenfolge: Zuerst die wichtigsten Geschäftsfragen identifizieren, dann die zugehörigen Kennzahlen definieren, fachlich freigeben und erst danach in Datenmodelle und Reports übertragen.

Die Plattform sollte zudem erkennen lassen, welche Datenquellen eine Kennzahl speisen und welche Verarbeitungsschritte zwischen Quelle und Bericht liegen. Diese Nachvollziehbarkeit erleichtert spätere Fehleranalysen und verhindert, dass unterschiedliche Ergebnisse allein aufgrund fehlender Transparenz diskutiert werden.

Ein sinnvoller Startpunkt sind zwei bis drei geschäftlich besonders wichtige Kennzahlen. Sie sollten gemeinsam mit den drei beteiligten Abteilungen abgestimmt werden. Erst wenn die Definitionen funktionieren und in den Reports nachvollziehbar umgesetzt sind, lohnt sich eine Ausweitung auf weitere Kennzahlen und Abteilungen.

Der nächste konkrete Schritt ist daher kein weiterer Technologieentscheid, sondern eine moderierte Abstimmung zwischen den Fachbereichen: Wählen Sie eine zentrale KPI, dokumentieren Sie ihre Berechnung und lassen Sie die Definition von allen betroffenen Verantwortlichen freigeben. Auf dieser Grundlage kann die Plattform schrittweise wachsen, ohne dass ein Big-Bang-Projekt erforderlich wird.