12 E-Commerce-Expert*innen zeigen, wie Wachstum gelingt. → Hol dir unser ERP-Playbook.
12 E-Commerce-Expert*innen zeigen, wie Wachstum gelingt. → Hol dir unser ERP-Playbook.
ERP-Projekt erfolgreich starten: 9 Entscheidungen, die vor der Implementierung sitzen müssen
ERP-Projekt erfolgreich starten: 9 Entscheidungen, die vor der Implementierung sitzen müssen
In wachsenden Unternehmen kommt irgendwann der Punkt, an dem Prozesse nicht mehr mitwachsen: Informationen liegen in verschiedenen Tools, Entscheidungen hängen an einzelnen Personen, Zahlen müssen manuell zusammengesucht werden und vieles funktioniert nur noch über Excel, Workarounds oder Erfahrungswissen.
Meist beginnt dann die ERP-Reise: Anforderungen werden gesammelt, Systeme verglichen, Demos vereinbart. Odoo, Business Central, NetSuite, SAP oder etwas anderes. Irgendwann steht die Frage im Raum: Welches System passt am besten zu uns?
Doch genau hier liegt oft das größte ERP-Missverständnis. Die wichtigste Frage ist selten, welches System gewählt wird. Die wichtigere Frage lautet: Wie soll das ERP später Verantwortung, Prozesse, Daten und Entscheidungen im Unternehmen abbilden?
Denn ein ERP schafft nicht von allein Klarheit. Es macht sichtbar, wie klar ein Unternehmen wirklich organisiert ist. Solange der Standardfall läuft, wirkt vieles stabil: Auftrag rein, Ware raus, Rechnung erstellt. Die Wahrheit zeigt sich bei Abweichungen: geänderte Mengen, geteilte Bestellungen, fehlende Produkte, Retouren, Sonderpreise oder Rechnungen, die nicht dem Idealprozess folgen.
Genau dann zeigt sich, ob ein ERP nur eine Demo abbildet oder den Arbeitsalltag eines Unternehmens.
Dieser Artikel zeigt die 9 Entscheidungen, die vor und während einer ERP-Implementierung sitzen müssen, damit aus dem Projekt kein Dauerzustand aus Workarounds, Tickets und Nachbesserungen wird.
TL;DR
Die meisten ERP-Projekte scheitern nicht an der Software. Sie scheitern an fehlenden, unklaren oder falschen Entscheidungen.
Wenn Zielbild, Prozesse, Ownership, Datenqualität, Scope und Betriebsmodell nicht sauber geklärt sind, wird aus einem ERP-Projekt schnell ein System, das technisch vorhanden ist, aber im Alltag nicht wirklich führt.
Die wichtigste Frage lautet deshalb nicht: „Welches ERP nehmen wir?“ Sondern: Sind wir als Unternehmen entscheidungsfähig genug, um ein ERP sauber einzuführen, zu nutzen und weiterzuentwickeln?
Der eigentliche Fehler passiert oft vor der Implementierung
Ein ERP-Projekt scheitert selten an einem einzigen großen Fehler. Meistens entsteht das Problem schleichend.
Das Zielbild ist nicht klar genug, Prozesse werden nur auf Workshop-Ebene verstanden, Phase 1 wird zu groß, niemand weiß wirklich, wer intern verbindlich entscheidet. Customizing wird diskutiert, bevor der eigentliche Prozess verstanden ist, Datenqualität bleibt ein Nebenprojekt, Testing prüft Funktionen, aber keine echten Abläufe, nach dem Go-Live gibt es keinen Rhythmus für Weiterentwicklung.
Für sich genommen wirkt jeder dieser Punkte lösbar. Zusammen ergeben sie ein Setup, das später kaum noch stabil zu führen ist. Dann wird aus einem ERP-Projekt ein Dauerzustand: offene Tickets, unsaubere Daten, Excel-Listen neben dem System, Diskussionen über Zahlen, Workarounds in Fachbereichen und sinkendes Vertrauen im Team.
Das Gemeine daran: Am Anfang sieht es oft noch nach Fortschritt aus: Es gibt Workshops, gibt Aufgaben, ein System, eine Roadmap. Aber irgendwann merkt das Unternehmen, dass zwar viel gebaut wurde, aber zu wenig geklärt war.
Ein ERP-Projekt braucht deshalb nicht nur Implementierung. Es braucht vorher Entscheidungsfähigkeit.
Ein ERP-Projekt hat drei Ebenen
Bevor wir in die 9 Entscheidungen gehen, hilft ein einfaches Modell. Ein ERP-Projekt besteht nicht aus einer Entscheidung, sondern aus drei Ebenen:
1. Business Design
Was soll operativ besser werden? Welche Prozesse sind kritisch? Welche Kennzahlen müssen stimmen? Welche Probleme dürfen nicht länger mit Workarounds überdeckt werden?
2. Delivery Design
Wie wird das Projekt umgesetzt? Was gehört in Phase 1? Was wird bewusst später gemacht? Wie wird getestet? Wie wird verhindert, dass der erste Go-Live unter seinem eigenen Scope zusammenbricht?
3. Operating Design
Wer führt das System nach dem Go-Live? Wer priorisiert Änderungen? Wer verantwortet Datenqualität? Wie wird Wissen dokumentiert? Wie wird aus Support echte Weiterentwicklung?
Viele Unternehmen investieren zu viel Energie in die Software-Auswahl und zu wenig in diese drei Ebenen. Genau dort entsteht später der Unterschied zwischen einem System, das eingeführt wurde, und einem System, das im Unternehmen wirklich arbeitet.
1. Zielsetzung: Was soll durch das ERP konkret besser werden?
„Wir brauchen ein ERP“ ist kein Ziel. Auch „wir wollen digitaler werden“ ist kein Ziel. Und „wir brauchen mehr Transparenz“ ist zumindest noch zu ungenau.
Ein gutes ERP-Projekt beginnt mit einer anderen Art von Frage:
“Welche Arbeit soll danach einfacher, schneller oder zuverlässiger laufen?”
Das klingt banal, ist aber entscheidend. Denn ohne klares Zielbild wird das Projekt schnell zu einer Sammlung von Anforderungen.
Der Vertrieb möchte bessere Angebote, Logistik sauberere Bestände, Finance konsistentere Zahlen, die Geschäftsführung Transparenz. Der Einkauf will bessere Planung, der Customer Service weniger Nachfragen. Alle diese Wünsche können berechtigt sein, aber nicht alles ist gleich wichtig und nicht alles gehört in Phase 1.
Ein gutes Zielbild zwingt zu Entscheidungen:
Welche Prozesse müssen zuerst stabil laufen?
Welche Kennzahlen entscheiden wirklich über Erfolg?
Welche Probleme kosten heute Zeit, Geld oder Vertrauen?
Welche Workarounds dürfen nicht einfach digital nachgebaut werden?
Was ist nur unangenehm, aber nicht kritisch?
Was klingt wichtig, kann aber warten?
In einem wachsenden Unternehmen sieht man oft einen diffusen Schmerz: „Es wird alles zu unübersichtlich.“ Das reicht für den Start einer Diskussion, aber nicht für den Start einer Implementierung.
Besser ist ein Zielbild wie: „Wir wollen den Order-to-Cash-Prozess vom Angebot bis zur Rechnung so stabil abbilden, dass Vertrieb, Lager und Buchhaltung auf denselben Datenstand schauen, Aufträge ohne manuelle Nachpflege durchlaufen und Monatsabschlüsse nicht mehr auf Excel-Korrekturen angewiesen sind.“
Oder: „Wir wollen Bestände, Einkaufsbedarfe und Lieferfähigkeit so steuern, dass operative Entscheidungen nicht mehr auf Bauchgefühl und manuell gepflegten Listen basieren.“
Solche Zielbilder sind brauchbarer. Sie sagen, welche Arbeit besser werden soll und woran man später erkennt, ob das ERP-Projekt tatsächlich Wert geschaffen hat.
Ohne dieses Zielbild muss das ERP später alles gleichzeitig lösen. Und genau daran scheitern viele Projekte.
2. Versteht ihr eure Prozesse wirklich oder nur die Idealversion?
“Viele Unternehmen glauben, sie kennen ihre Prozesse. Bis man sie wirklich anschaut.”
Dann zeigt sich: Der offizielle Ablauf ist nur ein Teil der Wahrheit. Der eigentliche Prozess lebt in Ausnahmen, Nebenwegen, Übergaben, individuellen Routinen und stillen Absprachen.
Ein Auftrag läuft eben nicht einfach von Angebot zu Lieferung zu Rechnung. Zwischendurch gibt es diverse Sonderfälle:
Ein Kunde ändert die Menge, ein Artikel ist nicht verfügbar, eine Lieferadresse stimmt nicht, eine Bestellung muss geteilt werden, ein Sonderpreis gilt nur in einem bestimmten Fall, die Buchhaltung braucht eine Information, die im Vertrieb niemand sauber gepflegt hat, das Lager bucht etwas anders, weil es physisch sinnvoll ist, aber systemisch nie richtig abgebildet wurde. Genau an diesen Stellen entscheidet sich, ob ein ERP im Alltag funktioniert.
Aus der Praxis
In einem unserer Projekte sah der Grundprozess zunächst plausibel aus: Einkauf, Verkauf, Lager und Buchhaltung waren im System angelegt. Solange alles geradeaus lief, wirkte das Setup okay. Das Problem kam bei kleinen Änderungen. Sobald ein Kunde in einem Auftrag eine Menge änderte oder etwas herausgenommen werden musste, entstanden falsche Buchungen, Unsicherheit und manuelle Nacharbeit. Das System war nicht belastbar.
Ein ERP-Projekt darf nicht nur den Schönwetterprozess verstehen, es muss die wirkliche operative Realität kennen. Deshalb reicht es nicht, Prozesse abstrakt im Workshop zu besprechen. Man muss sehen, wie Arbeit tatsächlich passiert:
Welche Informationen werden wann gebraucht?
Wo wechselt Verantwortung?
Welche Ausnahmen kommen regelmäßig vor?
Welche Listen werden neben dem System gepflegt?
Welche manuellen Schritte funktionieren nur, weil erfahrene Mitarbeitende sie im Kopf haben?
Welche Entscheidungen werden nicht dokumentiert, aber ständig getroffen?
Wo entstehen Fehler, wenn jemand krank ist oder neu ins Team kommt?
Gerade hier liegt einer der größten Unterschiede zwischen einer oberflächlichen Anforderungssammlung und echter Discovery:
“Wer nur fragt „Was soll das System können?“, bekommt meistens Feature-Wünsche. Wer zuschaut, wie Arbeit wirklich passiert, erkennt Prozesslogik, Abhängigkeiten und Risiken.”
Ein ERP darf nicht die Wunschvorstellung eines Prozesses abbilden. Es muss mit der Arbeitsrealität klarkommen. Wenn diese Realität vorher nicht verstanden wurde, entsteht ein System, das in der Demo gut aussieht und im Alltag nicht genügend Wirkung entfalten kann.
3. Wie groß darf die erste Phase wirklich sein?
Eine der gefährlichsten Ideen in ERP-Projekten lautet: „Wenn wir schon dabei sind, können wir das auch gleich mitmachen.“
So wächst der Scope von Phase 1: Ein bisschen CRM, Lager, Buchhaltung. Dann noch Einkauf, Reporting, ein Sonderprozess, eine Schnittstelle, Zeiterfassung, ein Portal und noch ein Wunsch aus einem Fachbereich, der sonst nicht mitzieht.
Am Ende soll die erste Phase so viel leisten, dass sie kaum noch führbar ist. Jeder zusätzliche Prozess bringt nicht nur ein weiteres Modul mit. Er bringt Entscheidungen, Daten, Rollen, Tests, Schulung, Ausnahmen und Abhängigkeiten mit.
Besonders gefährlich sind Themen, die klein klingen. „Zeiterfassung machen wir auch noch mit“ klingt harmlos. Bis klar wird, dass daran HR-Stammdaten, Abwesenheiten, Lohnabrechnung, Schichtplanung, Produktionsplanung, Rechte, Genehmigungen und Auswertungen hängen. Plötzlich ist ein scheinbar kleines Zusatzthema kein kleines Zusatzthema mehr, sondern ein eigener Projektstrang.
Das gilt für viele ERP-Bereiche: Ein Portal ist nicht nur ein Portal, eine Schnittstelle ist nicht nur eine Schnittstelle, ein neues Modul ist nicht nur ein neues Modul. Es verändert, wer wie arbeitet und wo Verantwortung liegt.
Ein gutes ERP-Projekt braucht deshalb eine erste Implementierungswelle, die groß genug ist, um echten Wert zu schaffen, aber klein genug, um sauber umgesetzt, getestet und verstanden zu werden. Sie muss nicht das ganze Unternehmen perfektionieren, sondern einen stabilen Kern schaffen, auf dem weitergebaut werden kann. Das klingt weniger beeindruckend als ein großer Big Bang, funktioniert aber deutlich häufiger.
Später darf das ERP ein großes Orchester werden. Aber in Phase 1 muss erstmal Musik entstehen. Wenn zu viele Instrumente gleichzeitig einsetzen, entsteht selten Harmonie. Meist entsteht Lärm.
Die bessere Frage lautet deshalb nicht: „Was könnten wir alles in Phase 1 machen?“ Sondern: „Was muss in Phase 1 funktionieren, damit das Unternehmen danach stabiler arbeitet als vorher?“
Alles andere gehört nicht automatisch raus. Es gehört in einen Backlog, der später priorisiert wird.
In wachsenden Unternehmen kommt irgendwann der Punkt, an dem Prozesse nicht mehr mitwachsen: Informationen liegen in verschiedenen Tools, Entscheidungen hängen an einzelnen Personen, Zahlen müssen manuell zusammengesucht werden und vieles funktioniert nur noch über Excel, Workarounds oder Erfahrungswissen.
Meist beginnt dann die ERP-Reise: Anforderungen werden gesammelt, Systeme verglichen, Demos vereinbart. Odoo, Business Central, NetSuite, SAP oder etwas anderes. Irgendwann steht die Frage im Raum: Welches System passt am besten zu uns?
Doch genau hier liegt oft das größte ERP-Missverständnis. Die wichtigste Frage ist selten, welches System gewählt wird. Die wichtigere Frage lautet: Wie soll das ERP später Verantwortung, Prozesse, Daten und Entscheidungen im Unternehmen abbilden?
Denn ein ERP schafft nicht von allein Klarheit. Es macht sichtbar, wie klar ein Unternehmen wirklich organisiert ist. Solange der Standardfall läuft, wirkt vieles stabil: Auftrag rein, Ware raus, Rechnung erstellt. Die Wahrheit zeigt sich bei Abweichungen: geänderte Mengen, geteilte Bestellungen, fehlende Produkte, Retouren, Sonderpreise oder Rechnungen, die nicht dem Idealprozess folgen.
Genau dann zeigt sich, ob ein ERP nur eine Demo abbildet oder den Arbeitsalltag eines Unternehmens.
Dieser Artikel zeigt die 9 Entscheidungen, die vor und während einer ERP-Implementierung sitzen müssen, damit aus dem Projekt kein Dauerzustand aus Workarounds, Tickets und Nachbesserungen wird.
TL;DR
Die meisten ERP-Projekte scheitern nicht an der Software. Sie scheitern an fehlenden, unklaren oder falschen Entscheidungen.
Wenn Zielbild, Prozesse, Ownership, Datenqualität, Scope und Betriebsmodell nicht sauber geklärt sind, wird aus einem ERP-Projekt schnell ein System, das technisch vorhanden ist, aber im Alltag nicht wirklich führt.
Die wichtigste Frage lautet deshalb nicht: „Welches ERP nehmen wir?“ Sondern: Sind wir als Unternehmen entscheidungsfähig genug, um ein ERP sauber einzuführen, zu nutzen und weiterzuentwickeln?
Der eigentliche Fehler passiert oft vor der Implementierung
Ein ERP-Projekt scheitert selten an einem einzigen großen Fehler. Meistens entsteht das Problem schleichend.
Das Zielbild ist nicht klar genug, Prozesse werden nur auf Workshop-Ebene verstanden, Phase 1 wird zu groß, niemand weiß wirklich, wer intern verbindlich entscheidet. Customizing wird diskutiert, bevor der eigentliche Prozess verstanden ist, Datenqualität bleibt ein Nebenprojekt, Testing prüft Funktionen, aber keine echten Abläufe, nach dem Go-Live gibt es keinen Rhythmus für Weiterentwicklung.
Für sich genommen wirkt jeder dieser Punkte lösbar. Zusammen ergeben sie ein Setup, das später kaum noch stabil zu führen ist. Dann wird aus einem ERP-Projekt ein Dauerzustand: offene Tickets, unsaubere Daten, Excel-Listen neben dem System, Diskussionen über Zahlen, Workarounds in Fachbereichen und sinkendes Vertrauen im Team.
Das Gemeine daran: Am Anfang sieht es oft noch nach Fortschritt aus: Es gibt Workshops, gibt Aufgaben, ein System, eine Roadmap. Aber irgendwann merkt das Unternehmen, dass zwar viel gebaut wurde, aber zu wenig geklärt war.
Ein ERP-Projekt braucht deshalb nicht nur Implementierung. Es braucht vorher Entscheidungsfähigkeit.
Ein ERP-Projekt hat drei Ebenen
Bevor wir in die 9 Entscheidungen gehen, hilft ein einfaches Modell. Ein ERP-Projekt besteht nicht aus einer Entscheidung, sondern aus drei Ebenen:
1. Business Design
Was soll operativ besser werden? Welche Prozesse sind kritisch? Welche Kennzahlen müssen stimmen? Welche Probleme dürfen nicht länger mit Workarounds überdeckt werden?
2. Delivery Design
Wie wird das Projekt umgesetzt? Was gehört in Phase 1? Was wird bewusst später gemacht? Wie wird getestet? Wie wird verhindert, dass der erste Go-Live unter seinem eigenen Scope zusammenbricht?
3. Operating Design
Wer führt das System nach dem Go-Live? Wer priorisiert Änderungen? Wer verantwortet Datenqualität? Wie wird Wissen dokumentiert? Wie wird aus Support echte Weiterentwicklung?
Viele Unternehmen investieren zu viel Energie in die Software-Auswahl und zu wenig in diese drei Ebenen. Genau dort entsteht später der Unterschied zwischen einem System, das eingeführt wurde, und einem System, das im Unternehmen wirklich arbeitet.
1. Zielsetzung: Was soll durch das ERP konkret besser werden?
„Wir brauchen ein ERP“ ist kein Ziel. Auch „wir wollen digitaler werden“ ist kein Ziel. Und „wir brauchen mehr Transparenz“ ist zumindest noch zu ungenau.
Ein gutes ERP-Projekt beginnt mit einer anderen Art von Frage:
“Welche Arbeit soll danach einfacher, schneller oder zuverlässiger laufen?”
Das klingt banal, ist aber entscheidend. Denn ohne klares Zielbild wird das Projekt schnell zu einer Sammlung von Anforderungen.
Der Vertrieb möchte bessere Angebote, Logistik sauberere Bestände, Finance konsistentere Zahlen, die Geschäftsführung Transparenz. Der Einkauf will bessere Planung, der Customer Service weniger Nachfragen. Alle diese Wünsche können berechtigt sein, aber nicht alles ist gleich wichtig und nicht alles gehört in Phase 1.
Ein gutes Zielbild zwingt zu Entscheidungen:
Welche Prozesse müssen zuerst stabil laufen?
Welche Kennzahlen entscheiden wirklich über Erfolg?
Welche Probleme kosten heute Zeit, Geld oder Vertrauen?
Welche Workarounds dürfen nicht einfach digital nachgebaut werden?
Was ist nur unangenehm, aber nicht kritisch?
Was klingt wichtig, kann aber warten?
In einem wachsenden Unternehmen sieht man oft einen diffusen Schmerz: „Es wird alles zu unübersichtlich.“ Das reicht für den Start einer Diskussion, aber nicht für den Start einer Implementierung.
Besser ist ein Zielbild wie: „Wir wollen den Order-to-Cash-Prozess vom Angebot bis zur Rechnung so stabil abbilden, dass Vertrieb, Lager und Buchhaltung auf denselben Datenstand schauen, Aufträge ohne manuelle Nachpflege durchlaufen und Monatsabschlüsse nicht mehr auf Excel-Korrekturen angewiesen sind.“
Oder: „Wir wollen Bestände, Einkaufsbedarfe und Lieferfähigkeit so steuern, dass operative Entscheidungen nicht mehr auf Bauchgefühl und manuell gepflegten Listen basieren.“
Solche Zielbilder sind brauchbarer. Sie sagen, welche Arbeit besser werden soll und woran man später erkennt, ob das ERP-Projekt tatsächlich Wert geschaffen hat.
Ohne dieses Zielbild muss das ERP später alles gleichzeitig lösen. Und genau daran scheitern viele Projekte.
2. Versteht ihr eure Prozesse wirklich oder nur die Idealversion?
“Viele Unternehmen glauben, sie kennen ihre Prozesse. Bis man sie wirklich anschaut.”
Dann zeigt sich: Der offizielle Ablauf ist nur ein Teil der Wahrheit. Der eigentliche Prozess lebt in Ausnahmen, Nebenwegen, Übergaben, individuellen Routinen und stillen Absprachen.
Ein Auftrag läuft eben nicht einfach von Angebot zu Lieferung zu Rechnung. Zwischendurch gibt es diverse Sonderfälle:
Ein Kunde ändert die Menge, ein Artikel ist nicht verfügbar, eine Lieferadresse stimmt nicht, eine Bestellung muss geteilt werden, ein Sonderpreis gilt nur in einem bestimmten Fall, die Buchhaltung braucht eine Information, die im Vertrieb niemand sauber gepflegt hat, das Lager bucht etwas anders, weil es physisch sinnvoll ist, aber systemisch nie richtig abgebildet wurde. Genau an diesen Stellen entscheidet sich, ob ein ERP im Alltag funktioniert.
Aus der Praxis
In einem unserer Projekte sah der Grundprozess zunächst plausibel aus: Einkauf, Verkauf, Lager und Buchhaltung waren im System angelegt. Solange alles geradeaus lief, wirkte das Setup okay. Das Problem kam bei kleinen Änderungen. Sobald ein Kunde in einem Auftrag eine Menge änderte oder etwas herausgenommen werden musste, entstanden falsche Buchungen, Unsicherheit und manuelle Nacharbeit. Das System war nicht belastbar.
Ein ERP-Projekt darf nicht nur den Schönwetterprozess verstehen, es muss die wirkliche operative Realität kennen. Deshalb reicht es nicht, Prozesse abstrakt im Workshop zu besprechen. Man muss sehen, wie Arbeit tatsächlich passiert:
Welche Informationen werden wann gebraucht?
Wo wechselt Verantwortung?
Welche Ausnahmen kommen regelmäßig vor?
Welche Listen werden neben dem System gepflegt?
Welche manuellen Schritte funktionieren nur, weil erfahrene Mitarbeitende sie im Kopf haben?
Welche Entscheidungen werden nicht dokumentiert, aber ständig getroffen?
Wo entstehen Fehler, wenn jemand krank ist oder neu ins Team kommt?
Gerade hier liegt einer der größten Unterschiede zwischen einer oberflächlichen Anforderungssammlung und echter Discovery:
“Wer nur fragt „Was soll das System können?“, bekommt meistens Feature-Wünsche. Wer zuschaut, wie Arbeit wirklich passiert, erkennt Prozesslogik, Abhängigkeiten und Risiken.”
Ein ERP darf nicht die Wunschvorstellung eines Prozesses abbilden. Es muss mit der Arbeitsrealität klarkommen. Wenn diese Realität vorher nicht verstanden wurde, entsteht ein System, das in der Demo gut aussieht und im Alltag nicht genügend Wirkung entfalten kann.
3. Wie groß darf die erste Phase wirklich sein?
Eine der gefährlichsten Ideen in ERP-Projekten lautet: „Wenn wir schon dabei sind, können wir das auch gleich mitmachen.“
So wächst der Scope von Phase 1: Ein bisschen CRM, Lager, Buchhaltung. Dann noch Einkauf, Reporting, ein Sonderprozess, eine Schnittstelle, Zeiterfassung, ein Portal und noch ein Wunsch aus einem Fachbereich, der sonst nicht mitzieht.
Am Ende soll die erste Phase so viel leisten, dass sie kaum noch führbar ist. Jeder zusätzliche Prozess bringt nicht nur ein weiteres Modul mit. Er bringt Entscheidungen, Daten, Rollen, Tests, Schulung, Ausnahmen und Abhängigkeiten mit.
Besonders gefährlich sind Themen, die klein klingen. „Zeiterfassung machen wir auch noch mit“ klingt harmlos. Bis klar wird, dass daran HR-Stammdaten, Abwesenheiten, Lohnabrechnung, Schichtplanung, Produktionsplanung, Rechte, Genehmigungen und Auswertungen hängen. Plötzlich ist ein scheinbar kleines Zusatzthema kein kleines Zusatzthema mehr, sondern ein eigener Projektstrang.
Das gilt für viele ERP-Bereiche: Ein Portal ist nicht nur ein Portal, eine Schnittstelle ist nicht nur eine Schnittstelle, ein neues Modul ist nicht nur ein neues Modul. Es verändert, wer wie arbeitet und wo Verantwortung liegt.
Ein gutes ERP-Projekt braucht deshalb eine erste Implementierungswelle, die groß genug ist, um echten Wert zu schaffen, aber klein genug, um sauber umgesetzt, getestet und verstanden zu werden. Sie muss nicht das ganze Unternehmen perfektionieren, sondern einen stabilen Kern schaffen, auf dem weitergebaut werden kann. Das klingt weniger beeindruckend als ein großer Big Bang, funktioniert aber deutlich häufiger.
Später darf das ERP ein großes Orchester werden. Aber in Phase 1 muss erstmal Musik entstehen. Wenn zu viele Instrumente gleichzeitig einsetzen, entsteht selten Harmonie. Meist entsteht Lärm.
Die bessere Frage lautet deshalb nicht: „Was könnten wir alles in Phase 1 machen?“ Sondern: „Was muss in Phase 1 funktionieren, damit das Unternehmen danach stabiler arbeitet als vorher?“
Alles andere gehört nicht automatisch raus. Es gehört in einen Backlog, der später priorisiert wird.
Ist dein ERP Projekt in Gefahr?
Ist dein ERP Projekt in Gefahr?
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
12 Fragen. Direktes Ergebnis. Für Teams, die vor dem Projektstart Klarheit schaffen wollen.
Ist dein ERP Projekt in Gefahr?
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
12 Fragen. Direktes Ergebnis. Für Teams, die vor dem Projektstart Klarheit schaffen wollen.
4. Wer trägt intern wirklich Verantwortung?
ERP-Projekte brauchen häufig externe Expertise, aber sie dürfen nicht komplett extern verantwortet werden. Ein Implementierungspartner kann strukturieren, beraten, bauen, herausfordern und beschleunigen. Was er nicht ersetzen kann: interne Verantwortung.
Denn die wichtigsten Entscheidungen kann nur das Unternehmen selbst treffen.
Welche Prozesse sind kritisch?
Welche Kompromisse sind akzeptabel?
Welche Sonderfälle sind wirklich relevant?
Welche Teams müssen ihre Arbeitsweise ändern?
Welche Daten sind verbindlich?
Welche Entscheidung darf nicht länger vertagt werden?
Wenn intern niemand diese Verantwortung trägt, entsteht eine gefährliche Dynamik.
Der Partner fragt, das Unternehmen antwortet halb, der Partner baut, das Unternehmen prüft spät, Entscheidungen werden vertagt, Anforderungen ändern sich, Prioritäten verschwimmen. Am Ende ist „das System“ schuld, aber in Wahrheit fehlt Ownership.
Ein typisches Muster: Ein fähiger Mitarbeiter bekommt das ERP-Projekt nebenbei. Er recherchiert Systeme, spricht mit Partnern, bereitet Daten vor und versucht, das Projekt intern zusammenzuhalten. Am Anfang wirkt das pragmatisch, später zeigt sich: Das Projekt ist zu groß für eine Einzelperson ohne echte Entscheidungsmacht. Dann merkt die Geschäftsführung zu spät, dass sie enger hätte führen müssen. Das System ist vielleicht schon live, aber die eigentliche Arbeit beginnt erst danach: Nachbessern, erklären, korrigieren, beruhigen.
ERP braucht jemanden, der das System nicht nur benutzt, sondern führt. Diese Rolle muss nicht die technischste Person im Unternehmen sein. Oft ist sogar das Gegenteil besser. Sie muss Prozesse verstehen, Entscheidungen moderieren, Prioritäten setzen und zwischen Geschäftsführung, Fachbereichen und Umsetzung übersetzen können.
Wichtig ist: Diese Person braucht Zeit, Mandat und Rückendeckung. „Mach das mal nebenbei“ ist eine Einladung zum Chaos.
5. Was gehört intern und was sollte extern ergänzt werden?
Viele Unternehmen denken hier zu binär: Entweder wollen sie ihr ERP komplett intern aufbauen, oder sie geben zu viel an externe Partner ab. Beides kann schiefgehen.
Rein intern fehlt oft die Breite: ERP-Architektur, Integrationen, Finance-Logik, Datenmodell, Testing, Releases, Change Management, Prozessdesign, Schulung und saubere Weiterentwicklung sind selten in einer Person vereint. Gute Profile sind schwer zu finden, Einarbeitung dauert, und aus einer strategischen Rolle wird schnell die Ablagefläche für alles, was im System unklar ist.
Rein extern entstehen andere Probleme: Es baut sich kein internes Verständnis auf, Entscheidungen, Logiken und Zusammenhänge liegen primär beim Dienstleister, das Unternehmen kann Anforderungen weitergeben, aber nicht mehr wirklich durchdringen, Änderungen dauern länger, weil intern niemand sauber priorisieren oder beurteilen kann, was wichtig ist, Probleme werden weitergereicht, statt selbst eingeordnet. Dann bleibt das ERP ein Fremdkörper im Alltag. Der bessere Weg liegt meistens dazwischen.
Intern muss Verantwortung sitzen:
Zielbild
Priorisierung
Prozessentscheidungen
Datenqualität
Abnahme
Veränderung im Team
Betriebsrhythmus nach Go-Live
Extern kann Hebelwirkung entstehen:
Methodik
Architektur
Spezialwissen
Schnittstellen
QA
Enablement
technische Umsetzung
saubere Weiterentwicklung
Gute ERP-Projekte entstehen dadurch, dass intern Verantwortung vorhanden ist und extern bessere Optionen, Struktur und Umsetzungskraft dazukommen.
Die wichtigste Frage lautet also: “Was müssen wir selbst verantworten und wo brauchen wir bessere Hebel?”
6. Wie wird verhindert, dass Customizing zum Standard wird?
Customizing ist nicht schlecht. Manchmal ist es genau richtig. Gerade Unternehmen mit komplexen Abläufen, besonderen Produktlogiken, hybriden Geschäftsmodellen oder spezifischen Integrationen brauchen mehr als Standard.
Das Problem entsteht, wenn Customizing zu früh kommt. Dann wird angepasst, bevor verstanden wurde. Gebaut, bevor entschieden wurde. Individualisiert, bevor der Standard ernsthaft geprüft wurde.
Das fühlt sich am Anfang pragmatisch an. Später wird es teuer.
Denn jede Anpassung erhöht Komplexität. Sie muss verstanden, getestet, dokumentiert, gewartet und bei Updates berücksichtigt werden. Wenn sie auf einem klaren Business Case basiert, kann das sinnvoll sein. Wenn sie nur einen ungeklärten Prozess kaschiert, wird sie zur technischen Hypothek.
Ein einfaches Beispiel aus der Praxis:
Ein Fachbereich sagt, er brauche ein bestimmtes Feld, eine Sonderlogik oder einen eigenen Status. Vielleicht stimmt das, vielleicht ist es aber nur der digitale Nachbau eines Workarounds, der entstanden ist, weil Verantwortung, Daten oder Übergaben bisher nicht sauber geregelt waren.
Dann löst Customizing nicht das Problem. Es konserviert es. Eine gute ERP-Implementierung stellt deshalb vor jedem Customizing die Frage:
“Lösen wir hier wirklich ein Systemproblem oder umgehen wir eine schlechte Entscheidung im Prozess?”
Zum Beispiel:
Wird etwas gebaut, weil der Ablauf unklar ist?
Weil Verantwortlichkeiten nicht geklärt sind?
Weil man bestehende Workarounds einfach digital nachbauen will?
Weil ein Sonderfall größer wirkt, als er wirklich ist?
Weil der Standard nicht reicht oder weil man ihn noch nicht verstanden hat?
Der Satz „Das bauen wir kurz“ klingt in ERP-Projekten fast immer zu harmlos. Selten ist etwas nur kurz gebaut. Meist ist es danach dauerhaft zu verstehen, zu pflegen und zu verteidigen.
7. Wer verantwortet Datenqualität?
Datenqualität klingt nach Detailarbeit, ist aber Führungsarbeit.
Wenn Produktdaten unsauber sind, Bestände nicht stimmen, Kundendaten doppelt gepflegt werden, Buchungslogiken nicht eindeutig sind oder Reports unterschiedlich interpretiert werden, verliert das System seine Autorität. Dann glauben Menschen dem ERP nicht mehr.
Sie exportieren Listen, bauen eigene Tabellen, fragen Kolleginnen und Kollegen, pflegen Schattenlogiken. Und je mehr das passiert, desto weniger ist das ERP die gemeinsame Wahrheit des Unternehmens.
Das ist einer der gefährlichsten Momente in einem ERP-Projekt, weil Vertrauen in das System verloren geht. Ein ERP kann nur zum Rückrat der Organisation werden, wenn die Menschen den Daten vertrauen.
Datenqualität braucht Verantwortung, Regeln und Routinen:
Wer darf Produktdaten ändern?
Welche Felder sind Pflicht?
Welche Daten sind führend?
Wo werden Dubletten bereinigt?
Welche Reports sind verbindlich?
Wer entscheidet, wenn Fachbereiche unterschiedliche Definitionen nutzen?
Wie wird verhindert, dass alte Datenprobleme einfach migriert werden?
Viele Unternehmen unterschätzen diesen Punkt, weil Datenmigration technisch klingt. Aber die technische Migration ist nur ein Teil. Der schwierigere Teil ist die Entscheidung, welche Daten künftig verbindlich sind.
Wenn ein Unternehmen vorher kein gemeinsames Verständnis von Artikelstammdaten, Kundendaten, Bestandslogik oder Reporting hat, wird das ERP dieses Verständnis nicht magisch erzeugen.
8. Wie wird getestet: mit echten Abläufen oder nur mit Funktionen?
Viele ERP-Projekte testen zu technisch: in Modul funktioniert, ein Button tut, was er soll, eine Rechnung kann erstellt werden, ein Lagerbestand verändert sich, eine E-Mail geht raus. Das ist wichtig, aber nicht genug.
Entscheidend ist, ob der Prozess als Ganzes funktioniert:
Kann ein echter Auftrag mit echten Sonderfällen sauber durchlaufen?
Sind die Übergaben zwischen Vertrieb, Lager und Buchhaltung klar?
Versteht das Team, was wann zu tun ist?
Fallen Lücken auf, bevor echte Kunden betroffen sind?
Funktioniert der Ablauf auch dann, wenn nicht alles ideal läuft?
Wissen Mitarbeitende, was sie tun sollen, wenn der Standardfall bricht?
Gutes Testing fühlt sich deshalb weniger wie Softwareprüfung an und mehr wie Probehandeln. Man spielt reale Szenarien durch, mit den Menschen, die später damit arbeiten. So nah wie möglich an der wirklichen Arbeit.
In breiteren End-to-End-Projekten arbeiten wir deshalb mit Dry Runs:
Ein Auftrag wird als simulierte Arbeitsrealität von vorne bis hinten durchgespielt: vom Vertrieb über Einkauf, Lager, Produktion oder Leistungserbringung bis zur Abrechnung.
Dabei passieren oft die wichtigsten Erkenntnisse: Eine Rolle versteht nicht, wann sie übernehmen muss, ein Datenfeld fehlt, ein Sonderfall wurde nicht bedacht, eine Übergabe klingt logisch, funktioniert aber im Tagesgeschäft nicht, eine Entscheidung, die im Workshop eindeutig wirkte, wird plötzlich praktisch unklar.
Genau dafür sind diese Dry Runs da. Sie validieren das System und schulen das Team im Kontext. Und sie zeigen früh, wo das Setup noch nicht belastbar ist.
Ein ERP-Projekt ist erst dann stabil, wenn es nicht nur logisch konfiguriert ist, sondern im Arbeitsalltag verstanden und genutzt wird.
9. Was passiert nach dem Go-Live?
Der Go-Live ist nicht das Ende des ERP-Projekts. Eher der Moment, in dem die Qualität des Projekts wirklich sichtbar wird.
Erst dann zeigt sich, welche Prozesse wirklich funktionieren, welche Daten fehlen, welche Sonderfälle häufiger vorkommen als gedacht, welche Teams das System annehmen und wo Schulungen nicht gereicht haben.
Deshalb braucht ein gutes ERP-Setup nach Go-Live einen klaren Betriebsrhythmus:
Welcher Input gesammelt?
Wie wird priorisiert?
Wer entscheidet?
Wann wird released?
Wie wird getestet?
Wie werden Mitarbeitende nachgeschult?
Wie wird Wissen dokumentiert?
Wie wird verhindert, dass aus jeder kleinen Reibung ein neues Ticket ohne Richtung wird?
Viele ERP-Initiativen scheitern, weil nach dem Go-Live kein System für Entscheidungen existiert.
Dann passiert das Übliche: Jeder meldet Themen. Manche sind Bugs, manche sind Schulungslücken, andere echte Verbesserungen, manche sind Sonderwünsche, andere Symptome eines Prozesses, der noch nicht sauber entschieden wurde.
Wenn diese Themen nicht sauber sortiert werden, entsteht kein kontinuierlicher Verbesserungsprozess.
Alles, was in Phase 1 bewusst nicht gebaut wurde, darf nach Go-Live nicht als loses „machen wir später“ verschwinden. Es braucht einen Backlog, einen festen Priorisierungsrhythmus und regelmäßige Entscheidungen mit den relevanten Stakeholdern. Sonst wird aus Weiterentwicklung wieder nur Support.
Genauso wichtig ist Kontext. ERP-Projekte verlieren Zeit durch verlorenes Wissen: Warum wurde etwas so entschieden? Welche Ausnahme wurde bewusst vertagt? Welche Regel gilt künftig? Was wurde einem Fachbereich erklärt? Welche Logik steckt hinter einer Anpassung?
Wenn dieser Kontext in Calls, Chats und Köpfen verschwindet, wird jede spätere Änderung schwerer.
4. Wer trägt intern wirklich Verantwortung?
ERP-Projekte brauchen häufig externe Expertise, aber sie dürfen nicht komplett extern verantwortet werden. Ein Implementierungspartner kann strukturieren, beraten, bauen, herausfordern und beschleunigen. Was er nicht ersetzen kann: interne Verantwortung.
Denn die wichtigsten Entscheidungen kann nur das Unternehmen selbst treffen.
Welche Prozesse sind kritisch?
Welche Kompromisse sind akzeptabel?
Welche Sonderfälle sind wirklich relevant?
Welche Teams müssen ihre Arbeitsweise ändern?
Welche Daten sind verbindlich?
Welche Entscheidung darf nicht länger vertagt werden?
Wenn intern niemand diese Verantwortung trägt, entsteht eine gefährliche Dynamik.
Der Partner fragt, das Unternehmen antwortet halb, der Partner baut, das Unternehmen prüft spät, Entscheidungen werden vertagt, Anforderungen ändern sich, Prioritäten verschwimmen. Am Ende ist „das System“ schuld, aber in Wahrheit fehlt Ownership.
Ein typisches Muster: Ein fähiger Mitarbeiter bekommt das ERP-Projekt nebenbei. Er recherchiert Systeme, spricht mit Partnern, bereitet Daten vor und versucht, das Projekt intern zusammenzuhalten. Am Anfang wirkt das pragmatisch, später zeigt sich: Das Projekt ist zu groß für eine Einzelperson ohne echte Entscheidungsmacht. Dann merkt die Geschäftsführung zu spät, dass sie enger hätte führen müssen. Das System ist vielleicht schon live, aber die eigentliche Arbeit beginnt erst danach: Nachbessern, erklären, korrigieren, beruhigen.
ERP braucht jemanden, der das System nicht nur benutzt, sondern führt. Diese Rolle muss nicht die technischste Person im Unternehmen sein. Oft ist sogar das Gegenteil besser. Sie muss Prozesse verstehen, Entscheidungen moderieren, Prioritäten setzen und zwischen Geschäftsführung, Fachbereichen und Umsetzung übersetzen können.
Wichtig ist: Diese Person braucht Zeit, Mandat und Rückendeckung. „Mach das mal nebenbei“ ist eine Einladung zum Chaos.
5. Was gehört intern und was sollte extern ergänzt werden?
Viele Unternehmen denken hier zu binär: Entweder wollen sie ihr ERP komplett intern aufbauen, oder sie geben zu viel an externe Partner ab. Beides kann schiefgehen.
Rein intern fehlt oft die Breite: ERP-Architektur, Integrationen, Finance-Logik, Datenmodell, Testing, Releases, Change Management, Prozessdesign, Schulung und saubere Weiterentwicklung sind selten in einer Person vereint. Gute Profile sind schwer zu finden, Einarbeitung dauert, und aus einer strategischen Rolle wird schnell die Ablagefläche für alles, was im System unklar ist.
Rein extern entstehen andere Probleme: Es baut sich kein internes Verständnis auf, Entscheidungen, Logiken und Zusammenhänge liegen primär beim Dienstleister, das Unternehmen kann Anforderungen weitergeben, aber nicht mehr wirklich durchdringen, Änderungen dauern länger, weil intern niemand sauber priorisieren oder beurteilen kann, was wichtig ist, Probleme werden weitergereicht, statt selbst eingeordnet. Dann bleibt das ERP ein Fremdkörper im Alltag. Der bessere Weg liegt meistens dazwischen.
Intern muss Verantwortung sitzen:
Zielbild
Priorisierung
Prozessentscheidungen
Datenqualität
Abnahme
Veränderung im Team
Betriebsrhythmus nach Go-Live
Extern kann Hebelwirkung entstehen:
Methodik
Architektur
Spezialwissen
Schnittstellen
QA
Enablement
technische Umsetzung
saubere Weiterentwicklung
Gute ERP-Projekte entstehen dadurch, dass intern Verantwortung vorhanden ist und extern bessere Optionen, Struktur und Umsetzungskraft dazukommen.
Die wichtigste Frage lautet also: “Was müssen wir selbst verantworten und wo brauchen wir bessere Hebel?”
6. Wie wird verhindert, dass Customizing zum Standard wird?
Customizing ist nicht schlecht. Manchmal ist es genau richtig. Gerade Unternehmen mit komplexen Abläufen, besonderen Produktlogiken, hybriden Geschäftsmodellen oder spezifischen Integrationen brauchen mehr als Standard.
Das Problem entsteht, wenn Customizing zu früh kommt. Dann wird angepasst, bevor verstanden wurde. Gebaut, bevor entschieden wurde. Individualisiert, bevor der Standard ernsthaft geprüft wurde.
Das fühlt sich am Anfang pragmatisch an. Später wird es teuer.
Denn jede Anpassung erhöht Komplexität. Sie muss verstanden, getestet, dokumentiert, gewartet und bei Updates berücksichtigt werden. Wenn sie auf einem klaren Business Case basiert, kann das sinnvoll sein. Wenn sie nur einen ungeklärten Prozess kaschiert, wird sie zur technischen Hypothek.
Ein einfaches Beispiel aus der Praxis:
Ein Fachbereich sagt, er brauche ein bestimmtes Feld, eine Sonderlogik oder einen eigenen Status. Vielleicht stimmt das, vielleicht ist es aber nur der digitale Nachbau eines Workarounds, der entstanden ist, weil Verantwortung, Daten oder Übergaben bisher nicht sauber geregelt waren.
Dann löst Customizing nicht das Problem. Es konserviert es. Eine gute ERP-Implementierung stellt deshalb vor jedem Customizing die Frage:
“Lösen wir hier wirklich ein Systemproblem oder umgehen wir eine schlechte Entscheidung im Prozess?”
Zum Beispiel:
Wird etwas gebaut, weil der Ablauf unklar ist?
Weil Verantwortlichkeiten nicht geklärt sind?
Weil man bestehende Workarounds einfach digital nachbauen will?
Weil ein Sonderfall größer wirkt, als er wirklich ist?
Weil der Standard nicht reicht oder weil man ihn noch nicht verstanden hat?
Der Satz „Das bauen wir kurz“ klingt in ERP-Projekten fast immer zu harmlos. Selten ist etwas nur kurz gebaut. Meist ist es danach dauerhaft zu verstehen, zu pflegen und zu verteidigen.
7. Wer verantwortet Datenqualität?
Datenqualität klingt nach Detailarbeit, ist aber Führungsarbeit.
Wenn Produktdaten unsauber sind, Bestände nicht stimmen, Kundendaten doppelt gepflegt werden, Buchungslogiken nicht eindeutig sind oder Reports unterschiedlich interpretiert werden, verliert das System seine Autorität. Dann glauben Menschen dem ERP nicht mehr.
Sie exportieren Listen, bauen eigene Tabellen, fragen Kolleginnen und Kollegen, pflegen Schattenlogiken. Und je mehr das passiert, desto weniger ist das ERP die gemeinsame Wahrheit des Unternehmens.
Das ist einer der gefährlichsten Momente in einem ERP-Projekt, weil Vertrauen in das System verloren geht. Ein ERP kann nur zum Rückrat der Organisation werden, wenn die Menschen den Daten vertrauen.
Datenqualität braucht Verantwortung, Regeln und Routinen:
Wer darf Produktdaten ändern?
Welche Felder sind Pflicht?
Welche Daten sind führend?
Wo werden Dubletten bereinigt?
Welche Reports sind verbindlich?
Wer entscheidet, wenn Fachbereiche unterschiedliche Definitionen nutzen?
Wie wird verhindert, dass alte Datenprobleme einfach migriert werden?
Viele Unternehmen unterschätzen diesen Punkt, weil Datenmigration technisch klingt. Aber die technische Migration ist nur ein Teil. Der schwierigere Teil ist die Entscheidung, welche Daten künftig verbindlich sind.
Wenn ein Unternehmen vorher kein gemeinsames Verständnis von Artikelstammdaten, Kundendaten, Bestandslogik oder Reporting hat, wird das ERP dieses Verständnis nicht magisch erzeugen.
8. Wie wird getestet: mit echten Abläufen oder nur mit Funktionen?
Viele ERP-Projekte testen zu technisch: in Modul funktioniert, ein Button tut, was er soll, eine Rechnung kann erstellt werden, ein Lagerbestand verändert sich, eine E-Mail geht raus. Das ist wichtig, aber nicht genug.
Entscheidend ist, ob der Prozess als Ganzes funktioniert:
Kann ein echter Auftrag mit echten Sonderfällen sauber durchlaufen?
Sind die Übergaben zwischen Vertrieb, Lager und Buchhaltung klar?
Versteht das Team, was wann zu tun ist?
Fallen Lücken auf, bevor echte Kunden betroffen sind?
Funktioniert der Ablauf auch dann, wenn nicht alles ideal läuft?
Wissen Mitarbeitende, was sie tun sollen, wenn der Standardfall bricht?
Gutes Testing fühlt sich deshalb weniger wie Softwareprüfung an und mehr wie Probehandeln. Man spielt reale Szenarien durch, mit den Menschen, die später damit arbeiten. So nah wie möglich an der wirklichen Arbeit.
In breiteren End-to-End-Projekten arbeiten wir deshalb mit Dry Runs:
Ein Auftrag wird als simulierte Arbeitsrealität von vorne bis hinten durchgespielt: vom Vertrieb über Einkauf, Lager, Produktion oder Leistungserbringung bis zur Abrechnung.
Dabei passieren oft die wichtigsten Erkenntnisse: Eine Rolle versteht nicht, wann sie übernehmen muss, ein Datenfeld fehlt, ein Sonderfall wurde nicht bedacht, eine Übergabe klingt logisch, funktioniert aber im Tagesgeschäft nicht, eine Entscheidung, die im Workshop eindeutig wirkte, wird plötzlich praktisch unklar.
Genau dafür sind diese Dry Runs da. Sie validieren das System und schulen das Team im Kontext. Und sie zeigen früh, wo das Setup noch nicht belastbar ist.
Ein ERP-Projekt ist erst dann stabil, wenn es nicht nur logisch konfiguriert ist, sondern im Arbeitsalltag verstanden und genutzt wird.
9. Was passiert nach dem Go-Live?
Der Go-Live ist nicht das Ende des ERP-Projekts. Eher der Moment, in dem die Qualität des Projekts wirklich sichtbar wird.
Erst dann zeigt sich, welche Prozesse wirklich funktionieren, welche Daten fehlen, welche Sonderfälle häufiger vorkommen als gedacht, welche Teams das System annehmen und wo Schulungen nicht gereicht haben.
Deshalb braucht ein gutes ERP-Setup nach Go-Live einen klaren Betriebsrhythmus:
Welcher Input gesammelt?
Wie wird priorisiert?
Wer entscheidet?
Wann wird released?
Wie wird getestet?
Wie werden Mitarbeitende nachgeschult?
Wie wird Wissen dokumentiert?
Wie wird verhindert, dass aus jeder kleinen Reibung ein neues Ticket ohne Richtung wird?
Viele ERP-Initiativen scheitern, weil nach dem Go-Live kein System für Entscheidungen existiert.
Dann passiert das Übliche: Jeder meldet Themen. Manche sind Bugs, manche sind Schulungslücken, andere echte Verbesserungen, manche sind Sonderwünsche, andere Symptome eines Prozesses, der noch nicht sauber entschieden wurde.
Wenn diese Themen nicht sauber sortiert werden, entsteht kein kontinuierlicher Verbesserungsprozess.
Alles, was in Phase 1 bewusst nicht gebaut wurde, darf nach Go-Live nicht als loses „machen wir später“ verschwinden. Es braucht einen Backlog, einen festen Priorisierungsrhythmus und regelmäßige Entscheidungen mit den relevanten Stakeholdern. Sonst wird aus Weiterentwicklung wieder nur Support.
Genauso wichtig ist Kontext. ERP-Projekte verlieren Zeit durch verlorenes Wissen: Warum wurde etwas so entschieden? Welche Ausnahme wurde bewusst vertagt? Welche Regel gilt künftig? Was wurde einem Fachbereich erklärt? Welche Logik steckt hinter einer Anpassung?
Wenn dieser Kontext in Calls, Chats und Köpfen verschwindet, wird jede spätere Änderung schwerer.
Ist dein ERP Projekt in Gefahr?
Finde in 3 Minuten heraus, ob euer ERP-Projekt sauber vorbereitet ist oder ob fehlende Ownership, unklare Prozesse und falscher Scope schon vor der Implementierung zum Risiko werden.
12 Fragen. Direktes Ergebnis. Für Teams, die vor dem Projektstart Klarheit schaffen wollen.
Warum ERP-Kosten oft falsch verstanden werden
In ERP-Diskussionen wird viel über Lizenzen gesprochen. Das ist verständlich, denn sie sind sichtbar, vergleichbar und gut in Tabellen darstellbar.
Der größere Teil der Kosten entsteht aber woanders: in Konzeption, Prozessarbeit, Umsetzung, Testing, Schulung, Betrieb, Weiterentwicklung und Nachbesserung.
Noch teurer wird es, wenn diese Arbeit unsauber passiert: Unklare Anforderungen, schlechte Priorisierung, fehlende Ownership, zu großer Scope, falsches Customizing oder Nacharbeiten ohne Richtung können ein ERP-Projekt zur Kostenfalle werden lassen.
Die teuersten ERP-Kosten stehen selten im Angebot: Sie entstehen, wenn Fachbereiche nach Go-Live dem System nicht vertrauen. Wenn Workarounds zurückkehren, Reports diskutiert werden müssen, jede kleine Änderung wieder externe Klärung braucht, niemand mehr genau weiß, warum etwas so gebaut wurde und wenn Teams zwar ein neues System haben, aber keinen besseren Arbeitsalltag.
Deshalb ist die eigentliche Kostenfrage Was kostet es uns, wenn wir das falsche Setup bauen?
Woran ihr erkennt, dass ihr noch nicht startklar seid
Ein ERP-Projekt muss nicht perfekt vorbereitet sein, aber es muss entscheidungsfähig vorbereitet sein. Die entscheidende Frage lautet: Können wir saubere Entscheidungen treffen?
Geht die folgenden Punkte ehrlich durch:
Zielklarheit
Könnt ihr in 1–2 Sätzen sagen, welches Problem das ERP konkret lösen soll und woran ihr Erfolg messt? Oder klingt das Ziel eher nach „mehr Transparenz“, „bessere Prozesse“ und „alles integrieren“?
Scope und Phase 1
Ist klar, was bewusst nicht Teil von Phase 1 ist? Oder wächst der Scope bei jedem Gespräch?
Prozessverständnis
Beschreiben eure Fachbereiche dieselben Abläufe ähnlich? Oder widersprechen sich Vertrieb, Lager, Einkauf, Finance und Geschäftsführung schon bei der Frage, wie der Prozess heute eigentlich läuft? Habt ihr euch die Prozesse konkret angeschaut?
Sonderfälle
Kennt ihr die 20 Prozent der Fälle, die 80 Prozent der Komplexität ausmachen? Oder tauchen kritische Ausnahmen erst spät im Projekt auf?
Priorisierung
Gibt es eine Person, die verbindlich entscheiden kann? Oder wird alles nochmal diskutiert?
Interne Verantwortung
Hat euer ERP Owner wirklich Zeit, Mandat und Rückendeckung? Oder läuft das Projekt neben dem Tagesgeschäft mit?
Customizing-Verständnis
Sprecht ihr früh über Lösungen, bevor klar ist, ob ihr das Problem überhaupt so lösen solltet? Oder prüft ihr zuerst, ob Prozess, Standard und Business Case zusammenpassen?
Datenverantwortung
Gibt es klare Owner für Datenqualität? Oder ist Datenmigration ein technisches Nebenprojekt, um das sich „irgendwer“ kümmert?
Testing
Testet ihr echte Abläufe mit echten Rollen und Sonderfällen? Oder prüft ihr nur, ob einzelne Funktionen grundsätzlich funktionieren?
Betrieb nach Go-Live
Wisst ihr, wie das System danach geführt und weiterentwickelt wird? Oder endet die Planung beim Go-Live?
Interpretation
Wenn ihr bei mehreren Punkten unsicher seid oder „kommt drauf an“ antwortet, fehlt wahrscheinlich nicht nur Vorbereitung. Dann fehlt Entscheidungsfähigkeit im Setup.
Und genau hier scheitern die meisten Projekte, weil sie neben dem normalen Geschäft laufen. Alle sind ausgelastet und wollen Fortschritt. Aber kaum jemand hat Zeit, die nötigen Entscheidungen wirklich zu treffen.
Typische Trade-offs, die ihr früh klären müsst
ERP-Projekte werden nicht stabiler, weil man jeden Zielkonflikt auflöst. Sie werden stabiler, weil man Zielkonflikte bewusst entscheidet.
Tempo vs. Stabilität
Ein schneller Go-Live klingt gut, aber viel Scope macht ihn wertlos. Fragt lieber: Was können wir schnell live bringen, ohne die Organisation zu überfordern?
Intern vs. extern
Internes Wissen ist wichtig, externe Breite ist oft effizienter. Fragt daher lieber: Welche Verantwortung muss intern bleiben, und welche Expertise kaufen wir sinnvoll dazu?
Standard vs. Customizing
Standard reduziert Komplexität, Customizing kann Wert schaffen. Fragt euch daher: Wo entsteht echter Business Impact, und wo bauen wir nur alte Workarounds nach?
Big Bang vs. Phasenmodell
Big Bang wirkt entschlossen, aber Phasenmodelle gewinnen in der Realität häufiger. Schaut daher unbedingt: Welche erste Welle schafft genug Wert, ohne das Projekt zu überladen?
Feature-Wunsch vs. Prozessentscheidung
Ein Feature-Wunsch klingt konkret während eine Prozessentscheidung oft unangenehmer ist.
Fragt: Brauchen wir wirklich diese Funktion oder müssen wir zuerst entscheiden, wie wir künftig arbeiten wollen?
Ein einfaches Decision Framework
Wenn ihr noch kein klares Zielbild habt:
Macht keine Implementierung, macht Discovery.
Wenn Phase 1 alles enthalten soll:
Reduziert den Scope.
Wenn ihr keine interne Owner-Rolle habt:
Klärt das Projektsetup, bevor ein Partner loslegt.
Wenn Prozesse nur auf Workshop-Level bekannt sind:
Schaut euch die Arbeit dort an, wo sie passiert.
Wenn Sonderfälle erst spät auftauchen:
Testet nicht nur Funktionen, sondern reale Abläufe.
Wenn Customizing früh zur Standardantwort wird:
Prüft zuerst Prozess, Standard und Business Case.
Wenn Datenqualität niemandem gehört:
Definiert Owner, Regeln und verbindliche Datenquellen.
Wenn nach Go-Live niemand zuständig ist:
Baut ein Operating Model mit Backlog, Priorisierung, Release-Rhythmus und Nachschulung.
Fazit: Die wichtigste ERP-Entscheidung ist nicht das Tool
Natürlich ist die Systemwahl wichtig, aber sie ist nicht der Punkt, an dem ERP-Projekte gewonnen werden.
Ein gutes ERP-Projekt entsteht durch die Entscheidungen davor und danach: Zielbild, Prozessverständnis, Scope, Ownership, Kompetenzaufbau, Datenqualität, Testing und kontinuierliche Weiterentwicklung.
Das klingt weniger spektakulär als große Softwareversprechen. Aber genau dort entsteht der Unterschied zwischen einem System, das eingeführt wurde, und einem System, das wirklich zur Wirbelsäule des Unternehmens wird.
FAQ: ERP-Projekt erfolgreich starten
Wann ist ein Unternehmen bereit für ein ERP-Projekt?
Ein Unternehmen ist bereit für ein ERP-Projekt, wenn es nicht nur ein neues System sucht, sondern entscheidungsfähig ist. Das bedeutet: Zielbild, zentrale Prozesse, interne Verantwortung, Datenqualität, Phase-1-Scope und Betriebsmodell nach Go-Live sind zumindest so weit geklärt, dass sinnvolle Entscheidungen getroffen werden können. Perfekt muss das Setup nicht sein. Aber es darf nicht komplett offen sein.
Was sollte vor einer ERP-Implementierung geklärt werden?
Vor einer ERP-Implementierung sollten mindestens diese Punkte geklärt sein: Was soll operativ besser werden? Welche Prozesse sind kritisch? Wer entscheidet intern? Was gehört in Phase 1? Welche Daten sind verbindlich? Wie wird getestet? Und wer führt das System nach dem Go-Live weiter? Ohne diese Klärung wird aus der Implementierung schnell eine Sammlung von Anforderungen ohne klare Richtung.
Warum scheitern ERP-Projekte so häufig?
ERP-Projekte scheitern selten nur an der Software. Häufiger scheitern sie an unklaren Prozessen, zu großem Scope, fehlender interner Verantwortung, schlechter Datenqualität, zu frühem Customizing, unrealistischem Testing oder einem fehlenden Betriebsmodell nach Go-Live. Das System wird dann eingeführt, aber nicht wirklich im Unternehmen verankert.
Wie groß sollte Phase 1 einer ERP-Implementierung sein?
Phase 1 sollte groß genug sein, um echten operativen Wert zu schaffen, aber klein genug, um sauber umgesetzt, getestet und verstanden zu werden. Eine gute erste Welle bildet einen stabilen Kern ab. Sie muss nicht das ganze Unternehmen perfektionieren. Themen, die wichtig sind, aber nicht kritisch für den ersten Go-Live, gehören in einen priorisierten Backlog.
Sollte ein ERP-Projekt intern oder extern umgesetzt werden?
Meistens funktioniert ein hybrides Setup am besten. Intern müssen Zielbild, Priorisierung, Prozessentscheidungen, Datenqualität und Abnahme verantwortet werden. Extern können Methodik, Architektur, Spezialwissen, Integrationen, QA, technische Umsetzung und Enablement ergänzt werden. Rein extern entsteht oft Abhängigkeit. Rein intern fehlt häufig die notwendige Breite.
Welche Rolle braucht ein Unternehmen intern für ein ERP-Projekt?
Ein Unternehmen braucht eine interne Owner-Rolle, die Prozesse versteht, Entscheidungen moderieren kann und zwischen Geschäftsführung, Fachbereichen und Umsetzung übersetzt. Diese Person muss nicht die technischste Person sein. Wichtiger sind Mandat, Zeit, Priorisierungsfähigkeit und Rückendeckung durch die Geschäftsführung.
Warum ist Datenqualität bei ERP-Projekten so wichtig?
Datenqualität entscheidet darüber, ob Menschen dem ERP vertrauen. Wenn Produktdaten, Bestände, Kundendaten oder Buchungslogiken nicht stimmen, entstehen Schattenlisten, manuelle Kontrollen und Misstrauen gegenüber dem System. Datenqualität ist deshalb keine technische Nebenaufgabe, sondern Führungsarbeit.
Wie sollte ein ERP-Projekt getestet werden?
Ein ERP-Projekt sollte nicht nur über Funktionen getestet werden, sondern über echte Abläufe. Gute Tests spielen reale Szenarien mit echten Rollen, Übergaben und Sonderfällen durch. Dabei zeigt sich, ob das System im Arbeitsalltag funktioniert und ob Mitarbeitende verstehen, was sie wann tun müssen.
Was passiert nach dem ERP-Go-Live?
Nach dem Go-Live beginnt die eigentliche Betriebsphase. Dann braucht es Nachschulungen, einen priorisierten Backlog, klare Verantwortlichkeiten, regelmäßige Entscheidungsrunden und einen sauberen Release-Rhythmus. Ohne dieses Operating Model wird aus Weiterentwicklung schnell ein unstrukturierter Supportprozess.
Ist Customizing in ERP-Projekten schlecht?
Nein. Customizing kann sinnvoll sein, wenn es einen klaren Business Case hat und einen echten Prozess- oder Wettbewerbsvorteil unterstützt. Problematisch wird Customizing, wenn es zu früh kommt und nur unklare Prozesse oder alte Workarounds digital nachbaut. Vor jeder Anpassung sollte geprüft werden, ob wirklich ein Systemproblem gelöst wird oder nur eine schlechte Prozessentscheidung kaschiert wird.
Warum ERP-Kosten oft falsch verstanden werden
In ERP-Diskussionen wird viel über Lizenzen gesprochen. Das ist verständlich, denn sie sind sichtbar, vergleichbar und gut in Tabellen darstellbar.
Der größere Teil der Kosten entsteht aber woanders: in Konzeption, Prozessarbeit, Umsetzung, Testing, Schulung, Betrieb, Weiterentwicklung und Nachbesserung.
Noch teurer wird es, wenn diese Arbeit unsauber passiert: Unklare Anforderungen, schlechte Priorisierung, fehlende Ownership, zu großer Scope, falsches Customizing oder Nacharbeiten ohne Richtung können ein ERP-Projekt zur Kostenfalle werden lassen.
Die teuersten ERP-Kosten stehen selten im Angebot: Sie entstehen, wenn Fachbereiche nach Go-Live dem System nicht vertrauen. Wenn Workarounds zurückkehren, Reports diskutiert werden müssen, jede kleine Änderung wieder externe Klärung braucht, niemand mehr genau weiß, warum etwas so gebaut wurde und wenn Teams zwar ein neues System haben, aber keinen besseren Arbeitsalltag.
Deshalb ist die eigentliche Kostenfrage Was kostet es uns, wenn wir das falsche Setup bauen?
Woran ihr erkennt, dass ihr noch nicht startklar seid
Ein ERP-Projekt muss nicht perfekt vorbereitet sein, aber es muss entscheidungsfähig vorbereitet sein. Die entscheidende Frage lautet: Können wir saubere Entscheidungen treffen?
Geht die folgenden Punkte ehrlich durch:
Zielklarheit
Könnt ihr in 1–2 Sätzen sagen, welches Problem das ERP konkret lösen soll und woran ihr Erfolg messt? Oder klingt das Ziel eher nach „mehr Transparenz“, „bessere Prozesse“ und „alles integrieren“?
Scope und Phase 1
Ist klar, was bewusst nicht Teil von Phase 1 ist? Oder wächst der Scope bei jedem Gespräch?
Prozessverständnis
Beschreiben eure Fachbereiche dieselben Abläufe ähnlich? Oder widersprechen sich Vertrieb, Lager, Einkauf, Finance und Geschäftsführung schon bei der Frage, wie der Prozess heute eigentlich läuft? Habt ihr euch die Prozesse konkret angeschaut?
Sonderfälle
Kennt ihr die 20 Prozent der Fälle, die 80 Prozent der Komplexität ausmachen? Oder tauchen kritische Ausnahmen erst spät im Projekt auf?
Priorisierung
Gibt es eine Person, die verbindlich entscheiden kann? Oder wird alles nochmal diskutiert?
Interne Verantwortung
Hat euer ERP Owner wirklich Zeit, Mandat und Rückendeckung? Oder läuft das Projekt neben dem Tagesgeschäft mit?
Customizing-Verständnis
Sprecht ihr früh über Lösungen, bevor klar ist, ob ihr das Problem überhaupt so lösen solltet? Oder prüft ihr zuerst, ob Prozess, Standard und Business Case zusammenpassen?
Datenverantwortung
Gibt es klare Owner für Datenqualität? Oder ist Datenmigration ein technisches Nebenprojekt, um das sich „irgendwer“ kümmert?
Testing
Testet ihr echte Abläufe mit echten Rollen und Sonderfällen? Oder prüft ihr nur, ob einzelne Funktionen grundsätzlich funktionieren?
Betrieb nach Go-Live
Wisst ihr, wie das System danach geführt und weiterentwickelt wird? Oder endet die Planung beim Go-Live?
Interpretation
Wenn ihr bei mehreren Punkten unsicher seid oder „kommt drauf an“ antwortet, fehlt wahrscheinlich nicht nur Vorbereitung. Dann fehlt Entscheidungsfähigkeit im Setup.
Und genau hier scheitern die meisten Projekte, weil sie neben dem normalen Geschäft laufen. Alle sind ausgelastet und wollen Fortschritt. Aber kaum jemand hat Zeit, die nötigen Entscheidungen wirklich zu treffen.
Typische Trade-offs, die ihr früh klären müsst
ERP-Projekte werden nicht stabiler, weil man jeden Zielkonflikt auflöst. Sie werden stabiler, weil man Zielkonflikte bewusst entscheidet.
Tempo vs. Stabilität
Ein schneller Go-Live klingt gut, aber viel Scope macht ihn wertlos. Fragt lieber: Was können wir schnell live bringen, ohne die Organisation zu überfordern?
Intern vs. extern
Internes Wissen ist wichtig, externe Breite ist oft effizienter. Fragt daher lieber: Welche Verantwortung muss intern bleiben, und welche Expertise kaufen wir sinnvoll dazu?
Standard vs. Customizing
Standard reduziert Komplexität, Customizing kann Wert schaffen. Fragt euch daher: Wo entsteht echter Business Impact, und wo bauen wir nur alte Workarounds nach?
Big Bang vs. Phasenmodell
Big Bang wirkt entschlossen, aber Phasenmodelle gewinnen in der Realität häufiger. Schaut daher unbedingt: Welche erste Welle schafft genug Wert, ohne das Projekt zu überladen?
Feature-Wunsch vs. Prozessentscheidung
Ein Feature-Wunsch klingt konkret während eine Prozessentscheidung oft unangenehmer ist.
Fragt: Brauchen wir wirklich diese Funktion oder müssen wir zuerst entscheiden, wie wir künftig arbeiten wollen?
Ein einfaches Decision Framework
Wenn ihr noch kein klares Zielbild habt:
Macht keine Implementierung, macht Discovery.
Wenn Phase 1 alles enthalten soll:
Reduziert den Scope.
Wenn ihr keine interne Owner-Rolle habt:
Klärt das Projektsetup, bevor ein Partner loslegt.
Wenn Prozesse nur auf Workshop-Level bekannt sind:
Schaut euch die Arbeit dort an, wo sie passiert.
Wenn Sonderfälle erst spät auftauchen:
Testet nicht nur Funktionen, sondern reale Abläufe.
Wenn Customizing früh zur Standardantwort wird:
Prüft zuerst Prozess, Standard und Business Case.
Wenn Datenqualität niemandem gehört:
Definiert Owner, Regeln und verbindliche Datenquellen.
Wenn nach Go-Live niemand zuständig ist:
Baut ein Operating Model mit Backlog, Priorisierung, Release-Rhythmus und Nachschulung.
Fazit: Die wichtigste ERP-Entscheidung ist nicht das Tool
Natürlich ist die Systemwahl wichtig, aber sie ist nicht der Punkt, an dem ERP-Projekte gewonnen werden.
Ein gutes ERP-Projekt entsteht durch die Entscheidungen davor und danach: Zielbild, Prozessverständnis, Scope, Ownership, Kompetenzaufbau, Datenqualität, Testing und kontinuierliche Weiterentwicklung.
Das klingt weniger spektakulär als große Softwareversprechen. Aber genau dort entsteht der Unterschied zwischen einem System, das eingeführt wurde, und einem System, das wirklich zur Wirbelsäule des Unternehmens wird.
FAQ: ERP-Projekt erfolgreich starten
Wann ist ein Unternehmen bereit für ein ERP-Projekt?
Ein Unternehmen ist bereit für ein ERP-Projekt, wenn es nicht nur ein neues System sucht, sondern entscheidungsfähig ist. Das bedeutet: Zielbild, zentrale Prozesse, interne Verantwortung, Datenqualität, Phase-1-Scope und Betriebsmodell nach Go-Live sind zumindest so weit geklärt, dass sinnvolle Entscheidungen getroffen werden können. Perfekt muss das Setup nicht sein. Aber es darf nicht komplett offen sein.
Was sollte vor einer ERP-Implementierung geklärt werden?
Vor einer ERP-Implementierung sollten mindestens diese Punkte geklärt sein: Was soll operativ besser werden? Welche Prozesse sind kritisch? Wer entscheidet intern? Was gehört in Phase 1? Welche Daten sind verbindlich? Wie wird getestet? Und wer führt das System nach dem Go-Live weiter? Ohne diese Klärung wird aus der Implementierung schnell eine Sammlung von Anforderungen ohne klare Richtung.
Warum scheitern ERP-Projekte so häufig?
ERP-Projekte scheitern selten nur an der Software. Häufiger scheitern sie an unklaren Prozessen, zu großem Scope, fehlender interner Verantwortung, schlechter Datenqualität, zu frühem Customizing, unrealistischem Testing oder einem fehlenden Betriebsmodell nach Go-Live. Das System wird dann eingeführt, aber nicht wirklich im Unternehmen verankert.
Wie groß sollte Phase 1 einer ERP-Implementierung sein?
Phase 1 sollte groß genug sein, um echten operativen Wert zu schaffen, aber klein genug, um sauber umgesetzt, getestet und verstanden zu werden. Eine gute erste Welle bildet einen stabilen Kern ab. Sie muss nicht das ganze Unternehmen perfektionieren. Themen, die wichtig sind, aber nicht kritisch für den ersten Go-Live, gehören in einen priorisierten Backlog.
Sollte ein ERP-Projekt intern oder extern umgesetzt werden?
Meistens funktioniert ein hybrides Setup am besten. Intern müssen Zielbild, Priorisierung, Prozessentscheidungen, Datenqualität und Abnahme verantwortet werden. Extern können Methodik, Architektur, Spezialwissen, Integrationen, QA, technische Umsetzung und Enablement ergänzt werden. Rein extern entsteht oft Abhängigkeit. Rein intern fehlt häufig die notwendige Breite.
Welche Rolle braucht ein Unternehmen intern für ein ERP-Projekt?
Ein Unternehmen braucht eine interne Owner-Rolle, die Prozesse versteht, Entscheidungen moderieren kann und zwischen Geschäftsführung, Fachbereichen und Umsetzung übersetzt. Diese Person muss nicht die technischste Person sein. Wichtiger sind Mandat, Zeit, Priorisierungsfähigkeit und Rückendeckung durch die Geschäftsführung.
Warum ist Datenqualität bei ERP-Projekten so wichtig?
Datenqualität entscheidet darüber, ob Menschen dem ERP vertrauen. Wenn Produktdaten, Bestände, Kundendaten oder Buchungslogiken nicht stimmen, entstehen Schattenlisten, manuelle Kontrollen und Misstrauen gegenüber dem System. Datenqualität ist deshalb keine technische Nebenaufgabe, sondern Führungsarbeit.
Wie sollte ein ERP-Projekt getestet werden?
Ein ERP-Projekt sollte nicht nur über Funktionen getestet werden, sondern über echte Abläufe. Gute Tests spielen reale Szenarien mit echten Rollen, Übergaben und Sonderfällen durch. Dabei zeigt sich, ob das System im Arbeitsalltag funktioniert und ob Mitarbeitende verstehen, was sie wann tun müssen.
Was passiert nach dem ERP-Go-Live?
Nach dem Go-Live beginnt die eigentliche Betriebsphase. Dann braucht es Nachschulungen, einen priorisierten Backlog, klare Verantwortlichkeiten, regelmäßige Entscheidungsrunden und einen sauberen Release-Rhythmus. Ohne dieses Operating Model wird aus Weiterentwicklung schnell ein unstrukturierter Supportprozess.
Ist Customizing in ERP-Projekten schlecht?
Nein. Customizing kann sinnvoll sein, wenn es einen klaren Business Case hat und einen echten Prozess- oder Wettbewerbsvorteil unterstützt. Problematisch wird Customizing, wenn es zu früh kommt und nur unklare Prozesse oder alte Workarounds digital nachbaut. Vor jeder Anpassung sollte geprüft werden, ob wirklich ein Systemproblem gelöst wird oder nur eine schlechte Prozessentscheidung kaschiert wird.
Weitere Artikel
ERP-Systemwechsel von WeClapp, Xentral oder JTL zu Odoo: Wie Unternehmen sauber migrieren (Ablauf, Risiken und typische Fehler)
ERP-Implementierung: 7 Risiken, die Projekte scheitern lassen (und wie du sie früh erkennst)
Best-of-Breed vs. Best-of-Suite im Mittelstand: HubSpot vs. Odoo im Realitätscheck
Controlling ERP E-Commerce: So skaliert ihr mit belastbaren Finanzdaten
Customer Service ERP: So integrierst du Service, ERP und Logistik richtig
E-Commerce Buchhaltung im ERP: Wenn 60.000 Buchungen im Monat dein System sprengen
E-Commerce Logistik & ERP: Warum Fulfillment ab 5–10 Mio. Umsatz strukturell wird
Bestandsplanung im E-Commerce: Warum Spreadsheets ab 20 Mio. Umsatz scheitern
Made with🫀in Berlin © 2026 bobco GmbH
Made with🫀in Berlin © 2026 bobco GmbH
Made with🫀in Berlin © 2026 bobco GmbH