ERP-Risikomanagement: 5 Methoden die wirklich funktionieren

Fast jedes ERP-Projekt beginnt mit einer Risikoanalyse. Meistens entsteht dabei eine Excel-Liste mit 15 bis 30 Risiken, die ordentlich kategorisiert und mit Eintrittswahrscheinlichkeiten versehen werden. Diese Liste wird im Kick-off präsentiert, alle nicken, und dann verschwindet sie im Projektordner. Erst wenn ein Risiko tatsächlich eintritt – Scope Creep, Datenmigrationsprobleme, fehlende Testkapazität – erinnert sich jemand daran, dass man es eigentlich kommen sehen hätte können.

Das Problem ist nicht die Risikoidentifikation. Die meisten Projektbeteiligten wissen intuitiv, wo die Gefahren lauern. Das Problem ist das Fehlen eines lebendigen Prozesses, der Risiken kontinuierlich bewertet, Gegenmaßnahmen nachverfolgt und Frühwarnsignale systematisch erfasst. Im Folgenden beschreiben wir fünf Methoden, die sich in unserer Beratungspraxis bei mittelständischen [ERP-Governance-Projekten](/erp-governance) bewährt haben.

Die Risiko-Heatmap kombiniert zwei Dimensionen: Eintrittswahrscheinlichkeit und Auswirkung auf das Gesamtprojekt. Jedes identifizierte Risiko wird in einer Matrix positioniert, die typischerweise je fünf Stufen pro Achse umfasst. Das Ergebnis ist eine visuelle Priorisierung, die auf einen Blick zeigt, welche Risiken sofortige Aufmerksamkeit erfordern und welche beobachtet werden können.

Der Mehrwert liegt nicht in der Matrix selbst – die ist trivial. Der Mehrwert liegt in der Diskussion, die bei der Einordnung entsteht. Wenn Projektleitung und Fachbereiche gemeinsam bewerten, ob ein Risiko eine mittlere oder hohe Auswirkung hat, entsteht ein gemeinsames Verständnis der Bedrohungslage. Diese Diskussion ist wertvoller als jede Zahl in der Matrix.

In der Praxis empfehlen wir, die Heatmap in jeder Steering-Committee-Sitzung zu aktualisieren. Risiken wandern auf der Matrix: Was vor vier Wochen gering war, kann sich durch veränderte Rahmenbedingungen verschärft haben. Diese Dynamik sichtbar zu machen, ist der Kern wirksamen [Risikomanagements](/erp-governance/risikomanagement).

Jedes Risiko braucht einen Eigentümer – eine konkrete Person, die für die Überwachung und die Umsetzung der Gegenmaßnahmen verantwortlich ist. In der Praxis scheitert Risikomanagement häufig daran, dass Risiken zwar identifiziert werden, aber niemand sich persönlich verantwortlich fühlt.

Das Risiko-Owner-Prinzip funktioniert so: Für jedes Risiko in der Top-10-Liste wird ein Owner benannt. Diese Person muss nicht die Gegenmaßnahme selbst umsetzen – aber sie muss den Status kennen, Fortschritte berichten und eskalieren, wenn Maßnahmen nicht greifen. Der Owner ist im Steering Committee rechenschaftspflichtig.

Wichtig: Der Risiko-Owner sollte nicht automatisch die Projektleitung sein. Wenn ein Risiko im Bereich Datenqualität liegt, ist der Fachbereichsverantwortliche für Stammdaten der richtige Owner. Wenn es um Kapazitätsengpässe geht, ist es die Ressourcenplanung. Verantwortung dorthin verteilen, wo die Handlungskompetenz liegt.

Die Pre-Mortem-Analyse ist eine der wirkungsvollsten und gleichzeitig am wenigsten genutzten Methoden im Risikomanagement. Das Prinzip: Stellen Sie sich vor, Ihr ERP-Projekt ist gescheitert. Das Go-Live wurde um ein Jahr verschoben, das Budget verdoppelt, die Organisation frustriert. Jetzt fragen Sie: Was ist passiert?

Diese Umkehrung des Blickwinkels hat einen psychologischen Vorteil: Es fällt Menschen leichter, Gründe für ein (hypothetisches) Scheitern zu benennen als Risiken abstrakt zu identifizieren. In einem Pre-Mortem-Workshop kommen Bedenken auf den Tisch, die in einer klassischen Risikoanalyse unter den Teppich gekehrt würden – politische Risiken, persönliche Bedenken, Zweifel an der Machbarkeit bestimmter Zeitpläne.

Wir empfehlen, eine Pre-Mortem-Analyse zu zwei Zeitpunkten durchzuführen: einmal vor dem Projektstart und einmal vor dem Go-Live. Die Ergebnisse fließen direkt in das Risikoregister ein und liefern oft die wertvollsten Einträge.

Qualitative Bewertungen (hoch/mittel/niedrig) sind ein guter Einstieg, reichen aber für kritische Entscheidungen nicht aus. Wenn das Steering Committee entscheiden muss, ob ein zusätzliches Budget für Risikominimierung gerechtfertigt ist, braucht es belastbare Zahlen.

Die quantitative Risikobewertung ordnet jedem Risiko einen monetären Erwartungswert zu: Eintrittswahrscheinlichkeit multipliziert mit geschätztem Schaden. Ein Risiko mit 30 % Eintrittswahrscheinlichkeit und einem potenziellen Schaden von 200.000 EUR hat einen Erwartungswert von 60.000 EUR. Die Summe aller Risikoerwartungswerte ergibt die Risikoexposition des Projekts – eine Zahl, die das Management versteht und gegen die Kosten von Gegenmaßnahmen abwägen kann.

Natürlich sind diese Schätzungen mit Unsicherheit behaftet. Aber eine fundierte Schätzung ist immer besser als gar keine Bewertung. Und die Diskussion über die Schätzung – Was könnte ein Datenmigrationsproblem wirklich kosten? Was ist der Schaden eines verschobenen Go-Live? – schafft ein realistisches Bewusstsein für die finanziellen Dimensionen der Projektrisiken.

Die meisten Risiken in ERP-Projekten treten nicht über Nacht ein. Sie kündigen sich an – durch Signale, die man erkennen kann, wenn man weiß, worauf man achten muss. Ein Frühwarnsystem definiert für jedes Top-Risiko konkrete Trigger-Indikatoren: messbare oder beobachtbare Signale, die darauf hindeuten, dass ein Risiko sich materialisiert.

Das Frühwarnsystem funktioniert nur, wenn die Trigger-Indikatoren regelmäßig geprüft werden. Idealerweise ist das Teil des zweiwöchigen Projektreportings: Die Projektleitung prüft die definierten Indikatoren und meldet Auffälligkeiten im Steering Committee. So werden Risiken adressiert, wenn sie noch beherrschbar sind – nicht erst, wenn sie das Projekt dominieren.

Keine dieser Methoden funktioniert isoliert. Ihre Stärke entfalten sie im Zusammenspiel: Die Pre-Mortem-Analyse liefert die Risiken, die Heatmap priorisiert sie, das Owner-Prinzip verteilt Verantwortung, die quantitative Bewertung liefert Entscheidungsgrundlagen, und das Frühwarnsystem stellt sicher, dass nichts übersehen wird.

In einem typischen mittelständischen ERP-Projekt empfehlen wir folgenden Ablauf: Pre-Mortem vor Projektstart, Heatmap und Owner-Zuweisung im Kick-off, quantitative Bewertung der Top-10-Risiken in der zweiten Steering-Sitzung, und Frühwarnindikatoren ab der Implementierungsphase. Der laufende Aufwand: etwa 2 Stunden pro Steering-Sitzung für die Risikopflege. Das ist ein Bruchteil dessen, was ein einziges nicht erkanntes Risiko kosten kann.

Die fünf beschriebenen Methoden sind nicht neu oder revolutionär. Sie sind bewährt, praxiserprobt und in der Umsetzung überschaubar. Was sie von der typischen Risikoliste unterscheidet, ist die Konsequenz: Sie erfordern regelmäßige Pflege, klare Verantwortlichkeiten und den Mut, unbequeme Wahrheiten auszusprechen.

ERP-Projekte, die diese Methoden konsequent einsetzen, scheitern nicht an Überraschungen – denn Überraschungen gibt es in einem gut gemanagten Projekt kaum. Sie scheitern höchstens an der Frage, ob die Organisation bereit ist, die identifizierten Risiken auch tatsächlich zu adressieren. Und selbst das ist ein Risiko, das man managen kann.

In einem kostenlosen 30-minütigen Erstgespräch bewerten wir gemeinsam, ob Ihr Risikomanagement-Ansatz tragfähig ist – und welche der fünf Methoden den größten Hebel für Ihr Projekt hätte.