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

Ein neues Business-Intelligence-System ist eingeführt, die Daten werden automatisch aktualisiert und das Management erhält übersichtliche Dashboards. Trotzdem bleiben wichtige Entscheidungen von manuellen Excel-Auswertungen und Diskussionen über widersprüchliche Zahlen abhängig. Das Problem liegt häufig nicht in der Software, sondern in den fehlenden Vereinbarungen darüber, was Kennzahlen bedeuten und welche Entscheidungen sie unterstützen sollen.

Bereits eine einzige unterschiedlich definierte Kennzahl kann das Vertrauen in ein BI-System beeinträchtigen. Wenn Finance und Vertrieb beispielsweise unter Umsatz verschiedene Werte verstehen, wird eine Geschäftsleitungssitzung zur Diskussion über Berechnungen statt über Massnahmen.

Für Unternehmen in der Schweiz bedeutet eine wirksame BI-Einführung deshalb mehr als technische Integration: Entscheidungsfragen müssen geklärt, KPI-Definitionen verbindlich festgelegt, Verantwortlichkeiten zugewiesen und die tatsächliche Nutzung überprüft werden. Eine überschaubare erste Anwendung kann dabei wertvoller sein als ein umfassendes Reporting-Projekt, dessen geschäftlicher Nutzen unklar bleibt.

Warum ein BI-System keine Entscheidungen verbessert, wenn Fragen unklar bleiben

Ein BI-System verbessert Entscheidungen nicht automatisch, indem es Daten schneller und übersichtlicher bereitstellt. Entscheidend ist, ob vor der Entwicklung geklärt wurde, welche geschäftliche Frage beantwortet werden soll, wer auf Grundlage der Antwort handelt und welche Handlungsmöglichkeiten bestehen. Ohne diese Verbindung entsteht Reporting, aber keine verlässliche Entscheidungsunterstützung.

Ein Vertriebsdashboard kann beispielsweise Umsatz, Auftragseingang und Conversion Rate anzeigen. Fehlt jedoch die Frage, ob bei rückläufiger Nachfrage der Personaleinsatz angepasst oder eine Vertriebsaktion gestartet werden soll, bleibt die Anzeige informativ, ohne unmittelbar handlungsleitend zu sein.

Die Microsoft-Dokumentation zur geschäftlichen Ausrichtung von BI betont die Abstimmung von analytischen Lösungen auf Unternehmensziele, Informationsbedürfnisse und konkrete Geschäftsprozesse. Sie empfiehlt strukturierte Anforderungserhebung und regelmässige Einbindung der Fachbereiche. Dabei handelt es sich um eine Herstellerempfehlung, nicht um eine unabhängige Studie zu Ausfallquoten von BI-Projekten.

Für die praktische Umsetzung eignet sich eine einfache Frage-Protokoll-Methode. Vor dem Bau eines Dashboards beantwortet der zuständige Entscheider schriftlich vier Fragen:

1. Welche konkrete Entscheidung steht an?
2. Wann und wie häufig muss diese Entscheidung getroffen werden?
3. Welche Kennzahl oder Information wird dafür benötigt?
4. Was wird anders gemacht, wenn der Wert einen definierten Bereich verlässt?

Kann die letzte Frage nicht sinnvoll beantwortet werden, sollte der Informationsbedarf nochmals geprüft werden. Nicht jede gewünschte Visualisierung rechtfertigt ein dauerhaft betriebenes Dashboard.

Besonders deutlich wird der Unterschied beim Ersatz bestehender Excel-Berichte. Wer Tabellen lediglich digital nachbaut, übernimmt möglicherweise auch deren unklare Definitionen, veraltete Informationsbedürfnisse und fehlende Verantwortlichkeiten.

Ein zweites Problem entsteht, wenn zwei Abteilungen dieselbe Kennzahl unterschiedlich interpretieren. Selbst technisch korrekte Berechnungen führen dann zu widersprüchlichen Ergebnissen. Die Diskussion verschiebt sich von der Entscheidung zur Frage, welcher Datenstand überhaupt gilt.

Erst wenn die Fragen feststehen, lässt sich bestimmen, welche Kennzahlen eine gemeinsame Definition benötigen und welche Informationen tatsächlich auf die Managementoberfläche gehören.

Wie definieren Sie 12 Kern-KPIs so, dass jeder sie gleich berechnet?

Definieren Sie jeden der zwölf Kern-KPIs in einem zentralen Verzeichnis mit vier Pflichtangaben: exakte Berechnungsformel, eindeutig identifizierbare Datenquelle, verantwortlicher Owner und festgelegter Berechnungszeitraum. Lassen Sie die Definitionen gemeinsam von Finance, Vertrieb und betroffenen Fachbereichen prüfen. Ohne vollständige Dokumentation und fachliche Freigabe sollte keine Kennzahl als verbindlich gelten.

Die Zahl zwölf ist dabei eine mögliche Arbeitsgrösse und keine wissenschaftlich begründete Norm. Entscheidend ist, wie viele Kennzahlen das Management benötigt, um seine wiederkehrenden Entscheidungen treffen und relevante Zielkonflikte erkennen zu können.

Eine praktische Definitionsvorlage kann folgendermassen aussehen:

Eine häufig unterschätzte Aufgabe besteht darin, Randfälle zu verhandeln. Bei einer Umsatzkennzahl muss beispielsweise ausdrücklich geklärt werden, wie Retouren, stornierte Aufträge, Gutschriften und nachträgliche Buchungen behandelt werden. Solche Festlegungen hängen vom konkreten Steuerungszweck und den Unternehmensprozessen ab.

Der KPI-Owner ist nicht zwangsläufig der BI-Entwickler oder die Person, die das Dashboard erstellt. Sinnvoll ist eine fachliche Verantwortung bei der Stelle, die Abweichungen beurteilen und Massnahmen veranlassen kann. Die technische Pflege des Datenmodells kann separat organisiert werden.

In einem gemeinsamen Definitionsworkshop sollten die Beteiligten deshalb nicht nur Formeln bestätigen, sondern konkrete Beispieldatensätze durchgehen. Stimmen die Ergebnisse auch bei Grenzfällen überein, ist die Wahrscheinlichkeit konkurrierender Interpretationen geringer.

Die zwölf Kennzahlen sollten schliesslich anhand ihrer tatsächlichen Entscheidungsrelevanz ausgewählt werden. Ein Datenfeld gehört nicht allein deshalb zu den Kern-KPIs, weil es leicht verfügbar ist.

Mit diesem gemeinsamen Begriffsverständnis können Abteilungen eigene Analysen erstellen, ohne bei jeder Auswertung erneut über die Bedeutung grundlegender Kennzahlen verhandeln zu müssen.

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

Bei fünf Abteilungen ist häufig ein hybrider BI-Ansatz prüfenswert: Eine zentrale Funktion verwaltet gemeinsame Datenmodelle, KPI-Definitionen und Zugriffsregeln, während die Fachbereiche eigene Analysen und Berichte entwickeln. Ob dieses Modell passt, hängt von Datenkompetenz, Kritikalität der Berichte, Datenvolumen und Änderungsfrequenz ab. Die Abteilungszahl allein entscheidet nicht.

Ein vollständig zentralisiertes Reporting kann bei geschäftskritischen Kennzahlen sinnvoll sein. Wenn aber jede zusätzliche Ansicht vom zentralen BI-Team entwickelt werden muss, entstehen Abhängigkeiten. Im reinen Self-Service entstehen andere Risiken: voneinander abweichende Formeln, parallele Datenaufbereitung und uneinheitliche Qualitätskontrollen.

Die Microsoft-Dokumentation zu Verantwortungsmodellen für BI-Inhalte unterscheidet Business-led Self-Service, Managed Self-Service und Enterprise BI. Sie beschreibt ausdrücklich, dass Unternehmen mehrere Modelle parallel einsetzen können.

Eine Entscheidungsmatrix hilft, den geeigneten Verantwortungsgrad festzulegen.

Ein gemeinsamer semantischer Layer verbindet diese Arbeitsweisen. Er stellt freigegebene Kennzahlen und Beziehungen bereit, sodass beispielsweise Vertrieb und Controlling dieselbe Umsatzdefinition verwenden können, obwohl sie unterschiedliche Berichte erstellen.

Zentral bedeutet in diesem Modell nicht, dass ein einziges Team jede Grafik bauen muss. Zentralisiert werden vor allem die Verantwortung für die gemeinsamen Datenstrukturen, die Berechtigungen und die fachliche Freigabe verbindlicher Kennzahlen.

Damit Self-Service funktioniert, benötigen Fachanwender geeignete Schulungen, verständliche Dokumentation und klare Ansprechpartner. Ohne diese Voraussetzungen wird Analysearbeit lediglich von der BI-Abteilung auf andere Mitarbeitende verlagert.

Auch mit einer passenden Governance bleibt der Nutzen allerdings begrenzt, wenn die fertigen Dashboards den Arbeitsalltag ihrer vorgesehenen Nutzer nicht unterstützen.

Der Dashboard-Fehler, der Management nach 2 Wochen wieder zu Excel zurücktreibt

Der entscheidende Dashboard-Fehler besteht darin, die Oberfläche nach verfügbaren Datenquellen statt nach tatsächlichen Entscheidungsfragen aufzubauen. Führungskräfte sehen zahlreiche Diagramme, finden aber keine Antwort auf ihre konkrete Frage. Sobald sie zusätzliche Filter, Vergleiche oder Sonderauswertungen benötigen, greifen sie wieder zu Excel. Entscheidend ist deshalb nicht die Zahl der Visualisierungen, sondern ihre praktische Nutzbarkeit.

Die im Titel genannten zwei Wochen sind kein empirisch gesicherter Zeitraum. Sie beschreiben ein mögliches frühes Nutzungsmuster: Auf die anfängliche Neugier folgt Ernüchterung, sobald eine wichtige Frage nicht beantwortet werden kann.

Ein Dashboard, das nach Datenquellen entwickelt wurde, könnte beispielsweise separate Seiten für ERP, CRM und Zeiterfassung enthalten. Die Geschäftsleitung möchte jedoch wissen, warum die operative Marge trotz steigender Auslastung sinkt. Liegen die benötigten Informationen auf mehreren unverbundenen Seiten, muss die Analyse manuell zusammengesetzt werden.

Die bessere Struktur orientiert sich an Entscheidungen: zuerst der relevante KPI und seine Entwicklung, anschliessend erklärende Einflussgrössen und schliesslich die Möglichkeit, auffällige Bereiche zu untersuchen.

Die ersten Wochen nach dem Go-live sollten deshalb als gezielte Lernphase behandelt werden. Dokumentieren Sie insbesondere:

• Welche Fragen Nutzer im Dashboard nicht beantworten konnten.
• Welche Informationen sie weiterhin nach Excel exportieren.
• Welche Filter und Dimensionen regelmässig fehlen.
• Welche Berichtsseiten tatsächlich in Besprechungen verwendet werden.

Diese Rückmeldungen bilden die Grundlage für priorisierte Anpassungen. Eine Änderung sollte vor allem dann umgesetzt werden, wenn sie einen wiederkehrenden Entscheidungsbedarf unterstützt, nicht bloss einen einmaligen Darstellungswunsch.

Excel bleibt dabei ein legitimes Werkzeug für flexible Sonderanalysen. Das Ziel einer BI-Einführung muss nicht sein, jede Tabellenkalkulation abzuschaffen. Standardisierte Dashboards und explorative Ad-hoc-Auswertungen erfüllen unterschiedliche Aufgaben.

Die Erkenntnisse aus solchen Tests sprechen dafür, die Einführung zunächst an einem begrenzten, aber relevanten Anwendungsfall zu überprüfen.

Wann sollten Sie erst 1 Use Case live bringen und erst dann skalieren?

Bringen Sie zuerst einen einzelnen Use Case live, wenn dessen Entscheidungsfrage klar, der geschäftliche Nutzen relevant, die benötigte Datenintegration überschaubar und ein verantwortlicher Entscheider verfügbar ist. Skalieren Sie nicht nach einem festen Kalendertermin, sondern erst dann, wenn das Ergebnis regelmässig verwendet wird, die KPI-Definitionen stabil sind und ein wiederholbarer Betriebsprozess funktioniert.

Der erste Use Case ist mehr als ein technischer Funktionstest. Er prüft gleichzeitig, ob die Daten zuverlässig bereitstehen, die Beteiligten dieselben Begriffe verwenden und das Management die Informationen tatsächlich in seinen Entscheidungen berücksichtigt.

Ein geeigneter Kandidat könnte beispielsweise eine regelmässige Entscheidung über Kapazitätsplanung sein. Er ist dann sinnvoll, wenn eine verantwortliche Führungskraft den vorhandenen Handlungsspielraum benennen kann und die relevanten Daten ohne unverhältnismässigen Integrationsaufwand verfügbar sind.

Der technisch einfachste Bericht ist nicht automatisch der geeignetste Pilot. Eine übersichtliche Auswertung ohne relevante Entscheidungsfolgen zeigt zwar, dass die Software funktioniert, beweist jedoch wenig über ihren geschäftlichen Nutzen.

Ein breit angelegter Parallelstart in sämtlichen Abteilungen erschwert dagegen die Ursachenanalyse. Werden gleichzeitig Datenmodelle, Verantwortlichkeiten und Berichtsoberflächen aufgebaut, lässt sich nur schwer erkennen, welche organisatorischen Probleme zuerst gelöst werden müssen.

Für die Freigabe der nächsten Einführungsphase bietet sich ein überprüfbares Set von Kriterien an:

• Der zuständige Entscheider verwendet den Bericht im vorgesehenen Entscheidungsrhythmus.
• Die verbindlichen KPI-Definitionen sind dokumentiert und fachlich akzeptiert.
• Datenqualitätsprobleme werden erkannt, zugewiesen und bearbeitet.
• Änderungen lassen sich nach einem dokumentierten Verfahren prüfen und umsetzen.
• Die Erfahrungen des Piloten können auf weitere Fachbereiche übertragen werden.

Eine einzelne erfolgreiche Präsentation reicht als Nutzungsnachweis nicht aus. Massgeblich ist, ob die Auswertung in wiederkehrenden Arbeitsabläufen Bestand hat.

Nach einem erfolgreichen Piloten lässt sich die Vorgehensweise systematisch auf weitere Nutzergruppen übertragen. Dabei sollten deren Fragen weiterhin den Ausgangspunkt bilden, nicht die bereits vorhandenen Datenquellen.

Wie entwerfen Sie ein Dashboard nach 15 Nutzerfragen statt nach Datenquellen?

Entwerfen Sie ein Dashboard, indem Sie zunächst fünfzehn echte Nutzerfragen sammeln und nach wiederkehrenden Entscheidungsmustern gruppieren. Übersetzen Sie jede relevante Frage in Kennzahl, Dimension, Zeitraum und mögliche Handlung. Priorisieren Sie anschliessend nach Nutzungshäufigkeit und Entscheidungswirkung. Erst danach bestimmen Sie die Datenquellen und entwickeln die passende Darstellung.

Ein strukturiertes Nutzerinterview sollte nicht mit der Frage beginnen, welche Diagramme gewünscht werden. Hilfreicher sind Gespräche über konkrete Entscheidungen, Unsicherheiten und bisherige Auswertungen.

Die Microsoft-Anleitung zur Erhebung von Power BI-Anforderungen empfiehlt, Zweck, Zielgruppe, Geschäftsprozess und erwartete Handlung eines Berichts zu dokumentieren. Sie beschreibt zudem die Untersuchung bestehender Berichte und ihrer tatsächlichen Nutzung. Diese Grundsätze sind auch bei Neueinführungen praktisch anwendbar.

Ein mögliches Interview umfasst Fragen wie: Welche Entscheidung treffen Sie jede Woche? Welche Information fehlt Ihnen dabei? Bei welchem Wert würden Sie reagieren? Welche Vergleiche benötigen Sie, um Ursachen zu verstehen?

Anschliessend wird jede gesammelte Frage in ihre analytischen Bestandteile zerlegt.

Die fünfzehn Rohfragen können sich beispielsweise auf drei wiederkehrende Entscheidungsfelder reduzieren: wirtschaftliche Leistung, operative Engpässe und Kundenentwicklung. Diese Gruppierung ist ein mögliches Arbeitsergebnis, keine feste Regel.

Für die Startseite sind Fragen besonders wichtig, die regelmässig bearbeitet werden und spürbare Entscheidungen beeinflussen. Seltene Jahresauswertungen können dagegen in einem gesonderten Bericht besser aufgehoben sein.

Bei Nutzerwünschen lohnt sich eine zusätzliche Rückfrage. «Ich brauche ein weiteres Balkendiagramm» beschreibt zunächst eine Darstellungspräferenz. Erst die Antwort auf «Welche Entscheidung können Sie damit besser treffen?» macht daraus eine überprüfbare Anforderung.

Aus diesen Fragen entsteht ein fokussiertes Dashboard. Für die eigentliche Steuerung muss anschliessend feststehen, wann eine KPI-Abweichung relevant ist und wer darauf reagiert.

Wie definieren Sie 7 Kern-KPIs mit klarer Formel, Owner und Zielkorridor?

Wählen Sie sieben entscheidungsrelevante Kern-KPIs aus und dokumentieren Sie für jeden eine eindeutige Formel, den fachlichen Owner sowie einen begründeten Zielkorridor. Ergänzen Sie Datenquelle, Zeitraum und Versionsstand. Prüfen Sie ausserdem, welche Zielkonflikte zwischen den Kennzahlen entstehen können. So dienen KPIs nicht nur der Beobachtung, sondern der abgestimmten Steuerung.

Die Zahl sieben ist eine mögliche Begrenzung für ein kompaktes Management-Cockpit, keine allgemeingültige Obergrenze. Wichtig ist, dass die Geschäftsleitung die Kennzahlen in ihrem regulären Entscheidungsrhythmus tatsächlich prüfen und bei Bedarf handeln kann.

Ein Zielkorridor unterscheidet sich von einem einzelnen Zielwert. Innerhalb eines definierten Bereichs kann eine Kennzahl schwanken, ohne dass automatisch eine Eskalation ausgelöst wird. Ausserhalb des Bereichs muss geprüft werden, ob Massnahmen nötig sind.

Ein rein hypothetisches Beispiel: Ein Unternehmen legt für eine bestimmte Prozesskennzahl einen Zielwert von 95 Prozent und einen intern begründeten Beobachtungsbereich von 93 bis 97 Prozent fest. Diese Grenzen sind weder Branchenstandard noch allgemeine Empfehlung. Sie müssen anhand des jeweiligen Geschäftsprozesses, der normalen Schwankung und der wirtschaftlichen Konsequenzen bestimmt werden.

Wichtig ist die Abstimmung der Zielkorridore zwischen zusammenhängenden Kennzahlen. Ein ambitionierter Umsatzzielwert kann beispielsweise mit einer Mindestanforderung an die Deckungsbeitragsmarge kollidieren. Wer ausschliesslich Umsatz optimiert, könnte wirtschaftlich unvorteilhafte Aufträge fördern.

Ein praxistauglicher KPI-Eintrag enthält deshalb auch die Beziehungen zu anderen Steuerungsgrössen. Für jede Kombination sollte geprüft werden, ob die Verbesserung einer Kennzahl eine Verschlechterung einer anderen begünstigen kann.

Eine weitere Voraussetzung ist die Versionierung. Wird die Formel einer Kennzahl geändert, müssen Gültigkeitsdatum, Änderungsgrund, Freigabe und Auswirkungen auf historische Vergleiche dokumentiert werden. Auch der Zielkorridor ist auf seine weitere Eignung zu prüfen.

Für bestehende Zeitreihen muss zudem entschieden werden, ob alte Werte nach der neuen Definition neu berechnet werden können oder ob ein sichtbarer Definitionsbruch bestehen bleibt.

Eine solche Struktur erleichtert die Steuerung einzelner Kennzahlen. Schwieriger wird es, wenn mehrere Zielkorridore gleichzeitig verletzt werden und die Massnahmen verschiedener Abteilungen einander widersprechen.

Welche Leistungskennzahlen helfen wirklich, wenn 12 KPIs gegeneinander arbeiten?

Wenn zwölf KPIs widersprüchliche Anreize setzen, helfen vor allem Kennzahlen mit direktem Bezug zur Unternehmensstrategie, klarer Managementverantwortung und nachvollziehbaren Entscheidungen. Ergänzen Sie diese um Gegenkennzahlen, die mögliche Nebenwirkungen sichtbar machen. Untergeordnete Messgrössen sollten zur Diagnose dienen, statt als gleichrangige Ziele miteinander zu konkurrieren.

Ein klassischer Konflikt besteht zwischen Absatzmenge und Marge. Eine Vertriebsabteilung kann die Absatzmenge durch hohe Rabatte steigern, während sich die Profitabilität verschlechtert. Beide Kennzahlen entwickeln sich dann in unterschiedliche Richtungen, obwohl die Massnahme aus Sicht der einzelnen Abteilung zunächst erfolgreich erscheint.

Ähnliche Zielkonflikte ergeben sich zwischen kurzen Lieferzeiten und niedrigen Lagerbeständen oder zwischen hoher Produktivität und ausreichender Qualitätskontrolle.

Für eine systematische Diagnose bietet sich eine paarweise Prüfung an. Bei zwölf Kennzahlen ergeben sich rechnerisch 66 unterschiedliche KPI-Paarungen. Diese Anzahl beschreibt lediglich die möglichen ungeordneten Paare, nicht die Zahl tatsächlich vorhandener Konflikte.

Für jedes Paar wird geprüft, ob eine Verbesserung der ersten Kennzahl unter bestimmten Bedingungen die Verschlechterung der zweiten wirtschaftlich attraktiv machen könnte. Die tatsächlich kritischen Beziehungen werden dokumentiert und hinsichtlich ihrer Entscheidungswirkung priorisiert.

Damit eine Kennzahl im Management-Cockpit verbleibt, sollte sie drei Anforderungen möglichst klar erfüllen:

• Strategische Relevanz: Sie unterstützt ein wesentliches Unternehmensziel und nicht nur ein isoliertes Abteilungsinteresse.
• Verantwortlichkeit: Eine bestimmte Führungsebene kann Abweichungen bewerten und geeignete Massnahmen veranlassen.
• Entscheidungsnähe: Der Wert beeinflusst regelmässig konkrete Entscheidungen.

Andere Kennzahlen bleiben verfügbar, werden aber als Diagnosegrössen eingeordnet. Sie helfen zu verstehen, warum ein Steuerungs-KPI vom Zielbereich abweicht.

Bei systemischen Zielkonflikten sollten Gegenkennzahlen bewusst mitgeführt werden. So kann eine Produktivitätskennzahl gemeinsam mit einer Qualitätskennzahl verhindern, dass kurzfristige Effizienzsteigerungen unbemerkt zu unerwünschten Nebenwirkungen führen.

Wenn mehrere Zielkorridore gleichzeitig verlassen werden, braucht es ausserdem einen definierten Eskalationsweg. Die operative Ebene kann nicht jeden Konflikt zwischen Rentabilität, Servicequalität und Wachstum eigenständig entscheiden.

Die Microsoft-Dokumentation zur BI-Governance beschreibt Verantwortlichkeiten auf verschiedenen organisatorischen Ebenen und die Bedeutung einer übergeordneten Konfliktlösung. Sie empfiehlt ausserdem, Governance schrittweise und mit klaren Prioritäten aufzubauen.

Ein sinnvoller Eskalationsprozess hält deshalb fest, welche Zielabweichungen innerhalb einer Abteilung bearbeitet werden dürfen, welche bereichsübergreifend abgestimmt werden müssen und wann die Geschäftsleitung die Prioritäten festlegt.

Wählen Sie als nächsten Schritt eine wiederkehrende Managemententscheidung, prüfen Sie die dafür verwendeten Kennzahlen auf Definitionen und Zielkonflikte und dokumentieren Sie die Zuständigkeiten. Ein fokussierter Test in einer realen Entscheidungssituation zeigt besser als eine zusätzliche Dashboard-Seite, ob Ihre BI-Steuerung bereits funktioniert.