Das Wichtigste für Ihren Betrieb
Ein ERP-Projekt braucht Entscheidungen aus dem Betrieb.
ERP-Projekte scheitern selten an einer einzelnen Softwarefunktion. Häufiger fehlen vor Projektstart ein gemeinsames Prozessbild, klare Entscheidungen, belastbare Datenverantwortung und ausreichend interne Kapazität.
ERP-Projekte werden stabil, wenn Ziel, Prozesse, Datenverantwortung, Systementscheidung und Umsetzung als zusammenhängende Ebenen vorbereitet sind.
Vor Vertragsfreigabe sind reale Vorgänge, Entscheider, Datenobjekte und Restlücken dokumentiert.
Software, Partner und Unternehmen tragen jeweils Verantwortung; pauschale Schuldzuweisung verhindert Lernen.
Für ERP-Projekte kursieren seit Jahren hohe Scheiternsquoten. Belastbar vergleichbar sind diese Zahlen jedoch selten, weil Budgetüberschreitung, Terminabweichung, Nutzenverfehlung und Projektabbruch unterschiedlich als „Scheitern“ gewertet werden. Für die Entscheidung ist deshalb die pauschale Quote weniger nützlich als die Frage, welche Risikonachweise vor dem Start fehlen.
In meiner Projektarbeit begegnen mir dabei wiederkehrend dieselben Muster: Excel-Dateien, die offiziell nicht existieren, Workarounds, die nur eine Person kennt, und Prozesse, die niemand mehr wirklich erklären kann – „das war schon immer so“. Wenn dann ein neues ERP kommt, wird diese Unklarheit häufig mitmigriert statt gelöst.
Projektfreigabe beginnt vor Vertrag und Termin
Ein unterschriebener Vertrag, ein gesetzter Go-live und eine überzeugende Demo sind noch keine belastbare Projektfreigabe. Entscheidend ist, ob Prozessfit, Verantwortlichkeiten, Daten und interne Entscheidungskapazität mit konkreten Nachweisen hinterlegt sind. Werden ungeprüfte Annahmen vertraglich festgeschrieben, erscheinen sie später als Change Request, Sonderentwicklung oder Projektverzug. Ebenso wichtig ist die Steuerungsfähigkeit auf Kundenseite: Ein Implementierungspartner kann fehlende interne Entscheider, Prozessverantwortung und verfügbare Fachkapazität nicht dauerhaft ersetzen.
Ein Fertigungsprojekt zeigte das deutlich: Eine geschäftskritische Planungsflexibilität galt zunächst als „im Standard nicht abbildbar“ und sollte sechsstellig erweitert werden. Erst der gemeinsame Nachweis am realen Vorgang zeigte, dass der Standard die Anforderung tragen konnte. Der dokumentierte Fall belegt deshalb nicht nur Systemfit, sondern die Notwendigkeit einer Freigabe auf Basis von Evidenz.
Vier Risikofelder – und die richtige Vertiefung
Die Aufgabe dieser Seite ist nicht, jede Methode vollständig zu erklären. Sie zeigt, welches fehlende Fundament ein Projekt gefährdet und wo die vertiefende Arbeit beginnt.
1 · Der Wechselgrund ist nicht belegt
Allgemeine Unzufriedenheit, alte Oberflächen oder viele Workarounds beweisen noch keine Systemgrenze. Die Grundsatzfrage wird im Beitrag ERP wechseln oder optimieren? in Behalten, Verbessern und Ersetzen getrennt.
2 · Prozess und Anforderungen gehören niemandem
Wenn reale Abläufe nur in Köpfen und Nebenlisten existieren, wird ein System für den vermuteten statt für den tatsächlichen Betrieb ausgewählt. Die Prozessaufnahme liegt bei der IT-Prozessanalyse; die kundenseitige Anforderungslogik im Beitrag zum unabhängigen Lastenheft.
3 · Systemfit wird behauptet statt nachgewiesen
Feature-Listen und unterschiedliche Vertriebsdemos erzeugen keine Vergleichbarkeit. Der Gesamtprozess steht in der ERP-Auswahl; der konkrete Nachweis im Artikel zur ERP-Demo mit echten Prozessen.
4 · Daten und interne Kapazität beginnen zu spät
Migration, Datenverantwortung, Fachbereichszeit und Entscheidungswege werden häufig erst nach Vertrag konkret. Die fachliche Datenfreigabe wird in der Datenmigration vertieft; die verfügbare Entscheidungskapazität bleibt Bestandteil der Projektfreigabe auf dieser Seite.
Fünf Nachweise vor der Projektfreigabe
- Wechselgrund: Ist belegt, warum Behalten oder Optimieren nicht wirtschaftlich ausreichen?
- Geschäftsvorfälle: Sind kritische Normal-, Sonder- und Fehlerfälle Ende-zu-Ende beschrieben?
- Anforderungen: Gehören Muss-Kriterien, Prioritäten und Freigaben nachweislich dem Unternehmen?
- Systemfit: Haben alle Anbieter dieselben Vorgänge mit dokumentiertem Standard, Restlücke und Bedingung gezeigt?
- Daten und Kapazität: Sind Data Owner, Migrationsrahmen, Fachbereichszeit und Entscheidungswege vor Vertrag benannt?
Ein offener Nachweis ist kein automatischer Projektabbruch. Er ist ein konkreter Arbeitsauftrag, der vor Vertrags- oder Go-live-Freigabe geschlossen oder als bewusstes Risiko akzeptiert werden muss.
Vom Risikobefund zur richtigen Vertiefung
Nach dem Risikocheck wird nicht alles in einem Sammelworkshop gelöst. Jeder offene Punkt erhält den passenden nächsten Arbeitsweg:
- Grundsatzfrage offen: Wechsel oder Optimierung belastbar entscheiden.
- Auswahlauftrag bestätigt: ERP-Auswahl als durchgängiges Verfahren strukturieren.
- Anforderungen unscharf: kundenseitiges Lastenheft aufbauen.
- Systemfit unbelegt: vergleichbare Demo-Arbeitsproben definieren.
- Datenrisiko unklar: Migration fachlich vorbereiten und freigeben.
Damit bleibt dieser Artikel das Freigabe- und Risikogate. Die verlinkten Seiten liefern die jeweilige Methode in der notwendigen Tiefe.
Projektfreigabe: vier Voraussetzungen
Prüfen Sie Ihre Projektfreigabe: Sind Fachzeit, Entscheidungsrechte und Datenverantwortung verbindlich zugesagt?
| Prüffeld | Leitfrage | Belastbarer Nachweis | Konsequenz |
|---|---|---|---|
| Zielbild | Welche betriebliche Veränderung soll erreicht werden? | Freigegebenes Ziel mit messbarer Wirkung. | Kein Projekt ohne gemeinsames Warum. |
| Entscheidungen | Wer entscheidet bei Prozess-, Scope- und Standardkonflikten? | Governance und Eskalationsweg. | Offene Konflikte nicht ins Projekt verschieben. |
| Daten | Wer bereinigt und genehmigt welche Daten? | Migrationsrahmen und Data Owner. | Datenarbeit vor Go-live beginnen. |
| Kapazität | Welche Fachzeit steht verbindlich zur Verfügung? | Rollen und Zeitfenster. | Scope an reale Kapazität anpassen. |
Wer trägt welches Projektrisiko?
Prioritäten schützen und Konflikte entscheiden.
Prozess und Akzeptanz verantworten.
Technik, Integration und Betrieb nachweisen.
Warnsignale
- Go-live-Datum steht, bevor Umfang und Daten geprüft sind.
- Fachbereiche sind nur „für Tests“ eingeplant.
- Jede Abweichung wird sofort zur Sonderentwicklung.
- Risiken verschwinden aus Statusberichten statt bearbeitet zu werden.
Projektfreigabe heißt: Annahmen in Nachweise übersetzen
- EntscheidungERP-Projekte werden stabil, wenn Ziel, Prozesse, Datenverantwortung, Systementscheidung und Umsetzung als zusammenhängende Ebenen vorbereitet sind.
- NachweisVor Vertragsfreigabe sind reale Vorgänge, Entscheider, Datenobjekte und Restlücken dokumentiert.
- GrenzeSoftware, Partner und Unternehmen tragen jeweils Verantwortung; pauschale Schuldzuweisung verhindert Lernen.
ERP-Projektrisiko eingrenzen.
Nennen Sie die offene Voraussetzung, die Ihren Projektplan aktuell am stärksten gefährdet.
ERP-Projektrisiko eingrenzen →