KPIs der ERP-Einführung: 30 Kennzahlen, die wirklich zählen

Auf diese KPIs kommt es bei einer ERP-Einführung an: eine kleine Auswahl, in der Umsetzung wöchentlich und im Hypercare täglich geprüft, mit jeweils einem benannten Verantwortlichen. Termintreue, Kostenabweichung, Scope-Änderungen, Testerfolgsquote, Genauigkeit der Datenmigration und vor allem die Nutzungsquote. Unten stehen die 30, die ich verwende, aufgeteilt in Umsetzung und Zeit nach dem Go-live, mit Formeln und den Schwellenwerten, bei denen gehandelt werden sollte.

Das ist für Programmverantwortliche, PMO-Leiter und Sponsoren gedacht, die ein Berichtspaket für den Lenkungsausschuss brauchen, das Probleme in Woche 8 aufdeckt und nicht erst in Monat 18.

Ein Kunde nahm in einem SAP-Projekt einmal 73 „kleine“ Änderungen auf. Keine wirkte für sich genommen bedeutend. Zusammen verursachten sie eine Verzögerung von fünf Monaten. Niemand hatte das Volumen der Scope-Änderungen verfolgt. (Wenn Ihnen das bekannt vorkommt: Mein Leitfaden zum Vermeiden von Scope Creep in SAP-Projekten behandelt die Kontrollen.)

Ein anderer Kunde ignorierte frühe Terminwarnungen, und aus einem einjährigen Projekt wurden achtzehn Monate. Ein Handelskunde schlug frühe Budgetwarnungen in den Wind und musste am Ende wichtige Funktionen streichen, nur um fertig zu werden.

Das sind keine ungewöhnlichen Pannen. So geht es, wenn Teams das Falsche verfolgen oder gar nichts.

#	KPI	Was gemessen wird	Warum es zählt
1	Termintreue	Tatsächlicher vs. geplanter Abschluss von Aufgaben	Erstes Signal für Verzögerungen, die sich aufschaukeln
2	Kostenabweichung	Tatsächliche Ausgaben vs. Budget je Phase	Erkennt Überschreitungen, bevor sie sich aufsummieren
3	Volumen der Scope-Änderungen	Anzahl und Auswirkung genehmigter Änderungen	Unkontrollierte Änderungen sind die häufigste Ursache für Überschreitungen
4	Ressourcenauslastung	Geleistete vs. geplante Stunden; Verteilung der Arbeitslast	Überlastete Mitarbeitende brennen aus oder gehen mitten im Projekt
5	Nutzungsquote	Anteil der Zielanwender, die das System aktiv nutzen	Die einzige Kennzahl, die zeigt, dass das System für das Geschäft funktioniert
6	Schulungswirksamkeit	Testergebnisse; Anteil geschulter Anwender	Sagt ein Scheitern der Nutzung schon vor dem Go-live voraus
7	Genauigkeit der Datenmigration	Anteil sauber migrierter Datensätze; Fehlerquote	Schlechte Daten in einem neuen System zu bereinigen dauert Monate
8	Ausfallzeit der Testumgebung	Stunden ungeplanter Ausfallzeit in Testsystemen	Instabilität im Test kündigt Instabilität im Go-live an
9	Engagement-Wert	Umfrageergebnisse; Teilnahme an Schlüsselterminen	Frühwarnung vor Widerstand, bevor er offen sichtbar wird
10	Risikoabbauquote	Anteil offener Risiken, die planmäßig geschlossen werden	Gemessen werden sollte das Schließen, nicht nur das Erkennen
11	Partnerleistung	Qualität der Liefergegenstände; Erreichen von Meilensteinen	Partner, die frühe Liefergegenstände verfehlen, verfehlen fast immer auch spätere
12	Testerfolgsquote	Anteil der Testfälle, die beim ersten Mal bestehen	Unter 85 % im SIT deutet meist auf systemische Probleme hin, nicht auf zufällige Fehler
13	Durchlaufzeit von Änderungsanträgen	Tage vom Antrag bis zur Entscheidung	Lange Warteschlangen sind ein Zeichen für Governance-Versagen
14	Budgetverbrauchsrate	Ausgaben vs. Gesamtbudget, gemessen am erledigten Arbeitsumfang	Zeigt, ob Geld und Fortschritt im Gleichklang laufen
15	Konfigurationsfortschritt	Anteil der geplanten Konfigurationspunkte, die erledigt sind	Verzug hier schiebt Tests und Schulungen nach hinten

#	KPI	Was gemessen wird	Schwellenwert oder Hinweis
16	Systemverfügbarkeit	Verfügbarkeit nach dem Go-live	Über 99,9 % ist gut; unter 99 % wird zum Vertrauensproblem bei den Anwendern
17	Geschwindigkeit von Berichten und Dashboards	Ladezeiten; Aktualisierungsraten	Wenn Manager nach Excel exportieren, liefert das System nicht
18	Mitarbeiterproduktivität	Aufgabendauer vs. Ausgangswert vor dem Go-live	Ein Distributionskunde, der Freigaben automatisierte, verarbeitete nach dem Go-live täglich 25 % mehr Transaktionen
19	Lösungsquote beim Erstkontakt	Tickets, die beim ersten Kontakt gelöst werden	Misst die Wirksamkeit des Hypercare
20	Anzahl der Support-Tickets	Offene Tickets; durchschnittliche Lösungszeit	Ein Anstieg um Tag 30 deutet meist auf Schulungslücken hin, nicht auf Systemfehler
21	Prozessdurchlaufzeiten	Auftragsbearbeitung, Rechnungsfreigabe, Abschlusszyklus	Das Ergebnis, das die Geschäftsleitung wirklich interessiert
22	Bestandsgenauigkeit	Physische Bestände vs. Systembestände	Der sichtbarste Indikator für die Datenqualität nach dem Go-live
23	Auftragserfüllungsquote	Im neuen System pünktlich erfüllte Aufträge	Direkte Auswirkung auf den Betrieb
24	Umsatzzuordnung	Umsatzveränderungen, die neuen Fähigkeiten zugeordnet werden	Langfristiger Beleg für den Business Case
25	Compliance-Einhaltung	Prüfungsfeststellungen; regulatorische Beanstandungen	Am wichtigsten im Finanzwesen, in der Pharmabranche und in regulierten Branchen
26	Prognosegenauigkeit	Prognose vs. tatsächliche Nachfrage	Zeigt, ob die Planung genutzt wird und ob man ihr vertraut
27	Anwenderzufriedenheit	Usability-Umfrage; NPS der Key-User	Anwender, die das System hassen, bauen Umgehungslösungen
28	Prozesseffizienz	Zeit und Kosten je Prozess vs. Ausgangswert	Rechtfertigt die Investition gegenüber dem Vorstand
29	Erzielte Einsparungen	Tatsächliche Einsparungen vs. Business Case	Der CFO wird nach 6 und 12 Monaten fragen
30	Return on Investment	Nettonutzen geteilt durch Gesamtkosten	Wird in der Regel nach 12 und 24 Monaten gemessen

Nach diesen wird am häufigsten gefragt.

1. Schedule Performance Index (SPI) = Earned Value ÷ Planned Value. Über 1,0 liegt das Projekt vor dem Plan, bei 1,0 im Plan, unter 1,0 im Verzug.
2. Cost Performance Index (CPI) = Earned Value ÷ Istkosten. Über 1,0 arbeitet das Projekt effizient, unter 1,0 liegt es über dem Budget.
3. Anteil der Scope-Änderungen = (genehmigte Änderungen ÷ ursprüngliche Scope-Positionen) × 100. Unter 10 % ist die Auswirkung gering, über 20 % ist sie hoch.
4. Nutzungsquote = (aktive Anwender ÷ Zielanwender) × 100. Über 80 % in den ersten 90 Tagen ist stark; unter 60 % braucht ein Eingreifen.
5. Genauigkeit der Datenmigration = (sauber migrierte Datensätze ÷ versuchte Datensätze) × 100. Vor dem Go-live über 98 %; unter 95 % sollte den Cutover verschieben.

SPI und CPI stammen aus dem Earned-Value-Management. Sie funktionieren nur, wenn der „Earned Value“ ehrlich gemessen wird: Eine Aufgabe, die seit drei Wochen zu 90 % erledigt ist, ist nicht zu 90 % ihres Wertes erbracht.

Ein KPI ohne Review-Rhythmus ist Dekoration. Diesen Takt sollten Sie einrichten.

1. UmsetzungWöchentliches Programm-BoardTermintreue, Kosten, Risiko, Testerfolgsquote, Scope-Änderungen. Gate-KPIs gehen an den Lenkungsausschuss
2. Tag 1-30Tägliches Hypercare-ReviewVerfügbarkeit, Ticketvolumen, Nutzung nach Abteilung
3. Bis Tag 90Wöchentliche Prüfung der NutzungNutzung, Prozessdurchlaufzeiten, Ticketkategorien
4. Monat 6 und 12Review mit Sponsor und CFOProduktivität, erzielte Einsparungen, ROI

Wann	KPIs	Geprüft von	Entscheidung, die daraus folgt
Wöchentlich in der Umsetzung	Termintreue, Kostenabweichung, Risikoabbau, Testerfolgsquote, Volumen der Scope-Änderungen	Programm-Board	Neu planen, eskalieren oder Scope halten
An jedem Phasen-Gate	Konfigurationsfortschritt, Schulungswirksamkeit, Genauigkeit der Datenmigration, Partnerleistung	Lenkungsausschuss	Freigabe, bedingte Freigabe oder Stopp
Täglich in den ersten 30 Tagen nach dem Go-live	Verfügbarkeit, Ticketvolumen und -trend, Nutzung nach Abteilung	Hypercare-Leiter	Wohin Support vor Ort und Korrekturen gehen
Wöchentlich bis Tag 90	Nutzung, Prozessdurchlaufzeiten, Ticketkategorien	Programm-Board	Auffrischungsschulungen, Korrekturen an der Konfiguration
Nach 6 und 12 Monaten	Produktivität, erzielte Einsparungen, ROI, Zufriedenheit	Sponsor und CFO	Freigabe des Business Case, Scope von Phase 2

Einer meiner Pharmakunden benannte für jeden Meilenstein einen konkreten Verantwortlichen und eine Vertretung. Die Termintreue verbesserte sich im Vergleich zum früheren SAP-Anlauf deutlich. Wenn eine monatliche Prüfung einen Verzug sichtbar macht, ist er bereits strukturell.

Gate-Entscheidungen sollten sich auf Belege stützen, nicht auf den Kalender. Und im dritten Monat nach dem Go-live sind Umgehungslösungen zur Gewohnheit geworden, das Zeitfenster für die Nutzung schließt sich also schneller, als die meisten Teams erwarten. Wenn Ihr Lenkungsausschuss einen Neustart braucht, beschreibe ich in Aufbau eines wirksamen SAP-Lenkungsausschusses, wie Sie dabei vorgehen.

Programme mit RISE with SAP und SAP GROW werfen Governance-Fragen auf, die die klassische Liste nicht abdeckt. Drei zusätzliche Kennzahlen helfen.

Verteilung der Clean-Core-Level

SAP bewertet Erweiterungen inzwischen nach vier Clean-Core-Leveln, A bis D. Level A nutzt ausschließlich freigegebene APIs; Level D ist nicht clean. Verfolgen Sie den Anteil der Erweiterungen je Level, mit den ABAP-Test-Cockpit-Prüfungen, die SAP empfiehlt.

In der Public Edition ist per Design alles Level A. In der Private Edition und On-Premise ist jede Erweiterung auf Level C oder D technische Schuld, die beim nächsten Upgrade auf den Tisch kommt. Prüfen Sie neue Erweiterungsanforderungen in der Realize-Phase wöchentlich gegen diese Level, und machen Sie jemanden für jede Freigabe auf Level C oder D verantwortlich.

Entscheidung über den Ort der Erweiterung

Formel: (Erweiterungen mit vereinbartem Level und Ort ÷ Erweiterungen im Backlog insgesamt) × 100. Ziel ist 100 % bis zum Ende von Explore. Eine Erweiterung, die noch niemand verortet hat, endet unter Termindruck als klassische Modifikation.

Zustand der Beziehung zu SAP

Eine qualitative Quartalsprüfung bei RISE-Programmen, in denen SAP Infrastruktur und Betrieb übernimmt und Teil der Umsetzung ist. Werden Plattform-Eskalationen innerhalb der vereinbarten Service Levels gelöst? Sind die Success Reviews von SAP substanziell oder reine Zeremonie? Ein schwacher Wert geht meist einer Eskalation mitten im Programm voraus, auf die das Team nicht vorbereitet ist.

KI hilft bei der Reporting-Arbeit rund um die Kennzahlen. Das Review ersetzt sie nicht.

1. Joule mit SAP Cloud ALM. SAP hat Joule in Cloud ALM integriert, sodass Teams Projekt- und Betriebsdaten in natürlicher Sprache abfragen können, statt jeden Status-Auszug von Hand zu bauen.
2. Copilot in Power BI. Entwirft die textliche Zusammenfassung für das Berichtspaket des Lenkungsausschusses aus dem darunterliegenden Dashboard. Funktioniert am besten, wenn das Datenmodell sauber ist.
3. Anomalieerkennung. Power BI, Tableau und SAP Analytics Cloud können KPIs markieren, die von ihrem üblichen Muster abweichen. Lohnt sich bei Ressourcenauslastung, Ticketvolumen und der Rate der Scope-Änderungen. Lohnt sich nicht bei Kennzahlen mit hoher natürlicher Schwankung, etwa den täglichen Auftragszahlen.

Die politische Arbeit löst KI nicht. Ein Dashboard kann sechs Wochen lang Terminverzug in Rot zeigen. Wenn der Lenkungsausschuss nicht handelt, geht der Verzug weiter.

Der KPI mit der größten Wirkung ist die Nutzung durch die Anwender, und die messen die meisten Teams zuletzt.

Ich hatte einen Fertigungskunden, dessen Führungskräfte alles nach Excel exportierten. Ein riesiges Warnsignal. Die Daten waren da, nur die Dashboards, die sie brauchten, nicht. Wir haben die Dashboards repariert und die Entscheidungszeit halbiert.

Ein System, das technisch funktioniert, in der Praxis aber umgangen wird, hat nichts geliefert. Die Forschung zum Change Management stützt das: Die langjährigen Studien von Prosci kommen zu dem Ergebnis, dass Projekte mit exzellentem Change Management etwa siebenmal so häufig ihre Ziele erreichen wie Projekte mit schwachem Change Management.

Das beste KPI-Dashboard ist nicht das vollständigste. Es ist die kleinste Auswahl, die sich der Lenkungsausschuss tatsächlich ansieht, mit einem Verantwortlichen für jede Zeile und einer Konsequenz, wenn Rot über zwei Zyklen bestehen bleibt. Die meisten KPI-Programme scheitern daran, dass die richtigen Dinge erfasst und dann ignoriert werden. Was zu tun ist, wenn die Zahlen schon rot sind, steht in SAP-Projekte wieder auf Kurs bringen.

Welche Kennzahl ist bei einer ERP-Einführung die wichtigste?

Die Nutzungsquote. Eine technisch gelungene Einführung, die niemand nutzt, bringt dem Unternehmen keinen Nutzen. Die übrigen KPIs (Termine, Budget, Tests) schützen die Voraussetzungen für die Nutzung. Die Nutzungsquote zeigt Ihnen, ob sie tatsächlich eingetreten ist.

Verfolgen Sie sie ab der ersten Woche nach dem Go-live, aufgeschlüsselt nach Abteilung. Eine niedrige Nutzung in einem Team deutet meist auf eine Schulungslücke oder ein Problem im Prozessdesign hin, das Sie im Hypercare noch beheben können.

Wie oft sollten die KPIs einer ERP-Einführung geprüft werden?

Termine, Kosten und Risiken wöchentlich in der Umsetzung, nicht monatlich im Lenkungsausschuss. Phasen-Gate-KPIs an jedem Gate. Operative KPIs in den ersten 30 Tagen nach dem Go-live täglich, danach wöchentlich bis Tag 90.

Welche Testerfolgsquote gilt im SAP-UAT als gesund?

Über 85 % Bestehen beim ersten Durchlauf im Systemintegrationstest gelten als gesund. Darunter liegen meist Lücken im Prozessdesign oder Konfigurationsfehler vor, keine vereinzelten Bugs.

Gehen Sie mit weniger als 85 % in den UAT, halten Sie an und beheben Sie die Ursache. Der UAT bereinigt fast nie, was der SIT übersehen hat.

Was bedeutet ein Anteil an Scope-Änderungen über 20 % für ein ERP-Projekt?

Das Projekt wird mitten im Flug neu entworfen. Überschreitungen und Verzögerungen werden wahrscheinlich.

Der Trend zählt mehr als die Zahl. Nehmen die Änderungen mit zunehmender Projektreife zu, statt sich zu beruhigen, versagt die Governance. Jede genehmigte Änderung braucht eine Aussage zu den Auswirkungen auf Kosten und Termine. Fehlt sie, ist der Scope außer Kontrolle.

Welche KPIs gelten speziell für Programme mit RISE with SAP?

Drei zusätzlich zu den üblichen 30: die Verteilung Ihrer Erweiterungen auf die Clean-Core-Level (A bis D), der Anteil der Erweiterungen mit vereinbartem Level und Ort sowie eine Quartalsprüfung des Zustands der Beziehung zu SAP (Eskalationen, Service Levels, Qualität der Success Reviews von SAP).

Wie berechnet man den ROI einer ERP-Einführung?

ROI = (Nettonutzen ÷ Gesamtinvestition) × 100. Der Nettonutzen sind messbare Einsparungen und Umsatzzuwächse, die sich dem System zuordnen lassen, abzüglich der laufenden Kosten der neuen Umgebung. Die Gesamtinvestition umfasst Software, Einführung, interne Arbeitszeit, Schulung, Datenmigration und laufenden Support.

Rechnen Sie vorsichtig. Der volle Nutzen kommt selten im ersten Jahr. Bauen Sie ein Hochlaufmodell: 50 % des Nutzens im eingeschwungenen Zustand im ersten Jahr, 80 % im zweiten, 100 % ab dem dritten Jahr.

Was sind die Hauptursachen für Budgetüberschreitungen bei ERP-Einführungen?

Nicht verfolgte Scope-Änderungen, eine Datenmigration, die weit über den Plan hinausläuft, weil Qualitätsprobleme spät auftauchen, im Test entdeckte Integrationsfehler und ein Change Management, das zu spät beginnt und den Support nach dem Go-live in die Höhe treibt.

Wöchentliche Verfolgung der Kostenabweichung und formale Scope-Kontrolle beherrschen das erste Problem. Eine frühe Bewertung der Datenqualität das zweite. Frühe Integrationstests mit realistischen Mengen das dritte. Change Management von Anfang an das vierte.