Eine misslungene ERP-Einführung zeigt sich nicht am Go-live-Tag. Sie zeigt sich sechs Monate später, wenn das Team parallel eine Tabelle pflegt, weil das System “für unseren Fall nichts taugt”. Zu diesem Zeitpunkt sind Lizenz, Beratung und Migration längst bezahlt, und ein Rückzug kostet mehr als das Weitermachen.
Fast alle Projekte, die entgleisen, entgleisen aus denselben Gründen — und keiner davon ist technisch. Das sind die zehn häufigsten Fehler und die Anzeichen, an denen Sie sie rechtzeitig erkennen.
Kurz gesagt: ERP-Einführungen scheitern selten an der Software. Sie scheitern an unscharfem Scope, unsauberen Quelldaten, zu vielen Anpassungen, einem fehlenden internen Verantwortlichen mit Entscheidungsbefugnis und an Schulungen, die ans Ende geschoben werden. Das sind Managementprobleme — und alle vermeidbar.
1. Starten, bevor die Prozesse erfasst sind
Aus diesem Ursprungsfehler entstehen fast alle anderen. Zuerst wird das ERP gekauft, und erst danach stellt sich heraus, wie das Unternehmen tatsächlich arbeitet — meist mitten in der Konfiguration.
Dokumentierter und gelebter Prozess decken sich fast nie. In der Verwaltung wendet jemand seit acht Jahren eine Ausnahme an, die nirgends festgehalten ist und die sich am Ende auf 30 % der Aufträge bezieht.
So vermeiden Sie ihn: Nutzen Sie die ersten Wochen, um den realen Ablauf zu dokumentieren — nicht den aus dem Handbuch — von der Bestellung bis zum Zahlungseingang und vom Einkauf bis zur Zahlung. Setzen Sie sich mit den Menschen zusammen, die ihn täglich ausführen, nicht nur mit denen, die ihn verantworten. Genau diese Karte erlaubt später eine fundierte Entscheidung darüber, was standardisiert und was beibehalten wird.
2. Den Scope als Wunschliste definieren
Wenn jede Abteilung gefragt wird, was sie braucht, kommen zweihundert Anforderungen zusammen — und alle sind “unverzichtbar”. Das Ergebnis ist ein Projekt, das nicht ins Budget passt und auf halber Strecke gekürzt wird, fast immer an der schmerzhaftesten Stelle.
So vermeiden Sie ihn: Sortieren Sie jede Anforderung in drei Schubladen: blockiert den Betrieb, spart messbar Zeit und wäre schön. Die erste Schublade kommt in Phase 1, die zweite wird nach eingesparten Stunden pro Monat priorisiert, die dritte sechs Monate nach dem Go-live erneut geprüft. Viele dieser Anforderungen erledigen sich von selbst, sobald das System läuft.
3. Unsaubere Daten migrieren
Das ist die häufigste Ursache für Verzögerungen und zugleich die am meisten unterschätzte. Niemand gibt gern zu, dass die Kundenstammdaten Dubletten enthalten, veraltete Nummern und Felder, die je nach Jahr nach unterschiedlichen Kriterien von Hand befüllt wurden.
Ein ERP repariert das nicht. Es erbt den Zustand und verstärkt ihn, denn nun speist derselbe Datensatz Buchhaltung, Lager und Fakturierung gleichzeitig.
So vermeiden Sie ihn: Prüfen Sie die Datenqualität, bevor Sie den Terminplan unterschreiben. Zählen Sie Dubletten, Lücken und Werte außerhalb des zulässigen Bereichs bei Kunden, Artikeln und Lieferanten. Bereinigen Sie an der Quelle und archivieren Sie bei der Gelegenheit, was ohnehin niemand mehr braucht: Fünfzehn Jahre Historie zu migrieren, die keiner je aufruft, verteuert das Projekt, ohne etwas beizutragen. Unser Leitfaden zum Thema von Excel auf ein ERP migrieren geht auf diese Phase im Detail ein.
4. Vom ersten Tag an alles anpassen
Anpassungen machen süchtig, weil sie in der Besprechung immer vernünftig klingen. Das Problem taucht beim ersten Produkt-Update auf, wenn jede Individualentwicklung einzeln überprüft werden muss.
Jede Anpassung zahlen Sie dreimal: beim Bauen, beim Warten und bei jedem Update.
So vermeiden Sie ihn: Gehen Sie grundsätzlich davon aus, den Prozess an den Standard anzupassen, und individualisieren Sie nur dort, wo dieser Prozess ein echter Wettbewerbsvorteil ist. Wenn Ihre Art der Stücklistenkalkulation Sie von anderen unterscheidet, passen Sie sie an. Geht es um das Layout des Lieferscheins, fügen Sie sich dem Standard. Eine brauchbare Probe: Fragen Sie sich, was passieren würde, wenn dieser Prozess so liefe wie im Rest der Branche. Lautet die Antwort “nichts Schlimmes”, lassen Sie die Anpassung.
5. Keinen internen Verantwortlichen mit Entscheidungsbefugnis benennen
Das Projekt braucht jemanden aus dem eigenen Haus, der entscheidet, wenn zwei Abteilungen sich über den Ablauf eines Prozesses uneinig sind. Fehlt diese Rolle, wandert jede Entscheidung zur Geschäftsführung, und der Zeitplan füllt sich mit Wartezeiten.
Genauso häufig ist der Folgefehler: Man benennt diese Person, entlastet sie aber nicht. Ein ERP-Projekt kostet echte Arbeitszeit, und wer es mit bereits vollem Kalender führt, erledigt am Ende das Dringende und verschiebt das Wichtige.
So vermeiden Sie ihn: Benennen Sie einen Verantwortlichen mit Entscheidungsbefugnis über Prozesse und weisen Sie ihm einen ausdrücklichen Anteil seiner Arbeitszeit zu. Schriftlich, nicht stillschweigend.
6. Schulungen ans Projektende schieben
Das ist die einfache Kürzung, wenn das Budget knapp wird: Aus der Schulung wird eine Zwei-Stunden-Sitzung in der Woche vor dem Go-live. Danach lernt das Team im laufenden Betrieb, jeder auf seine Weise, und es verfestigen sich falsche Arbeitsweisen, die sich später nur mühsam korrigieren lassen.
So vermeiden Sie ihn: Schulen Sie nach Rolle statt nach Modul — jede Person lernt das, was sie tatsächlich nutzt —, arbeiten Sie dabei mit echten Unternehmensdaten und planen Sie eine zweite Sitzung zwei bis drei Wochen nach dem Go-live ein. Dann kommen die eigentlichen Fragen. Reservieren Sie dieses Budget von Anfang an und schützen Sie es.
7. Ohne Not den Big-Bang-Start wählen
Alle Module und alle Standorte am selben Tag zu starten ist verlockend, weil es sauberer wirkt. Es bedeutet aber auch, dass jedes Problem gleichzeitig an allen Fronten auftritt — und das gesamte Unternehmen schaut zu.
So vermeiden Sie ihn: In kleinen Organisationen mit einheitlichen Prozessen ist ein Big Bang vertretbar. Bei Mehrmandanten-, Mehrländer- oder Fertigungsstrukturen starten Sie stufenweise: erst ein Modul oder ein Standort, dann stabilisieren, dann das Gelernte auf den Rest übertragen. Das verlängert den Zeitplan und senkt das Risiko erheblich.
8. Den Go-live mit dem Projektende verwechseln
Am Starttag funktioniert das System, die Organisation aber noch nicht. In den ersten Wochen ballen sich Störungen, Rückfragen und Nachjustierungen — und genau dann zieht sich das Einführungsteam meist zurück.
So vermeiden Sie ihn: Planen Sie eine Stabilisierungsphase mit verstärktem Support und einem einzigen Kanal, über den das Team ohne Umwege fragen kann. Messen Sie die Störungen pro Woche: Sinken sie nicht, passt etwas am Konzept nicht zum realen Betrieb. Prüfen Sie das, bevor sich Umgehungslösungen einbürgern.
9. Das ERP nicht mit dem verbinden, was bereits läuft
Ein ERP, das nicht mit dem Onlineshop, dem CRM oder dem Kassensystem spricht, macht jemanden im Team zur menschlichen Brücke, die Daten von einem System ins andere überträgt. Diese Arbeit steht in keinem Angebot und wird trotzdem jeden Monat bezahlt.
So vermeiden Sie ihn: Identifizieren Sie die Berührungspunkte zwischen den Systemen von Anfang an und behandeln Sie sie als Teil des Scopes, nicht als Zusatz. Prüfen Sie, ob das ERP eine dokumentierte API hat, und lassen Sie sich zeigen, dass die versprochenen Integrationen bereits bei einem realen Kunden laufen. Wir haben diese Arbeit sowohl auf Standardprodukten gemacht — etwa bei der Odoo-Integration — als auch, indem wir die Schicht selbst gebaut haben, wenn der Standard nicht ausreichte.
10. Erfolg an der Termintreue messen
Ein System pünktlich zu liefern, das niemand nutzt, ist kein Erfolg. Trotzdem ist der Terminplan das Einzige, was viele Lenkungsausschüsse messen — schlicht, weil er am leichtesten zu betrachten ist.
So vermeiden Sie ihn: Definieren Sie vor dem Start zwei oder drei betriebswirtschaftliche Kennzahlen und messen Sie sie nach drei und nach sechs Monaten. Zum Beispiel: Tage bis zum Monatsabschluss, Zeit von der Bestellung bis zum Lieferschein, Anteil der Aufträge mit Störung. Wenn das ERP wirkt, bewegen sich diese Zahlen. Bewegen sie sich nicht, haben Sie ein Problem — auch wenn das Projekt pünktlich übergeben wurde.
Warnsignale während des Projekts
Vier Symptome, die Probleme Wochen im Voraus ankündigen:
| Signal | Was es meist bedeutet |
|---|---|
| Die Statusmeetings leeren sich | Die Organisation empfindet das Projekt nicht mehr als ihres |
| Im Test tauchen parallele Tabellen auf | Das System deckt einen realen Ablauf nicht ab, und niemand sagt es |
| Jede Entscheidung geht an die Geschäftsführung | Es fehlt ein Verantwortlicher mit echter Befugnis |
| Die Liste der Anpassungen wächst jede Woche | Der Scope wurde nie wirklich geschlossen |
Wie wir das angehen
Bei Soamee beginnen wir immer mit der Prozesslandkarte und dem Daten-Audit, bevor über Module gesprochen wird. Und wir sagen ab, wenn der Kunde eigentlich ein gut konfiguriertes Standardprodukt braucht und keine Eigenentwicklung: Wenn Ihr Betrieb in das passt, was der Markt bereits bietet, ist der Vergleich von Odoo, SAP und Sage für KMU der bessere Ausgangspunkt als jedes Angebot von uns.
Eine Individualentwicklung lohnt sich, wenn der Prozess, der Sie unterscheidet, nicht in das Standardprodukt passt. Das Signal dafür ist konkret: Personalstunden, die jeden Monat dafür draufgehen, von Hand auszugleichen, was das System nicht kann. Sobald diese Kosten höher sind als eine saubere Eigenentwicklung, ist die Entscheidung bereits gefallen.
Läuft bei Ihnen eine Einführung, die nicht in Gang kommt, oder steht eine bevor? Schildern Sie uns den Fall, und Sie bekommen von uns eine ehrliche Einschätzung, wo es gerade schiefläuft.