ERP-Projektplan erstellen: Praxistemplate für den Mittelstand

Ein ERP-Projekt ohne belastbaren Projektplan ist wie eine Baustelle ohne Bauzeichnung: Es wird gebaut, aber niemand weiß genau, was am Ende dabei herauskommt. Im Mittelstand wird dieser Plan häufig unterschätzt – man vertraut auf Erfahrung, auf den ERP-Anbieter oder auf das Projektteam, das es schon richten wird. Doch genau diese Haltung führt dazu, dass ERP-Projekte aus dem Ruder laufen.

Ein guter ERP-Projektplan ist kein statisches Dokument, das einmal erstellt und dann abgeheftet wird. Er ist ein lebendes Steuerungsinstrument, das Phasen, Meilensteine, Ressourcen, Abhängigkeiten und Puffer in ein realistisches Gesamtbild bringt. Er beantwortet die entscheidenden Fragen: Was passiert wann? Wer ist verantwortlich? Welche Voraussetzungen müssen erfüllt sein, bevor der nächste Schritt beginnt? In der Praxis scheitern Projektpläne selten an der Methodik. Sie scheitern daran, dass sie unrealistisch sind, dass sie keine Puffer enthalten, dass Abhängigkeiten ignoriert werden oder dass sie die interne Ressourcensituation des Mittelständlers nicht berücksichtigen. Genau diese Praxislücke wollen wir hier schließen.

Ein ERP-Projektplan für den Mittelstand muss drei Anforderungen gleichzeitig erfüllen: Er muss detailliert genug sein, um als Steuerungsinstrument zu funktionieren. Er muss flexibel genug sein, um auf Veränderungen reagieren zu können. Und er muss verständlich genug sein, damit alle Beteiligten – von der Geschäftsführung bis zum Fachbereich – ihn nachvollziehen können. In der Praxis sehen wir häufig zwei Extreme: Entweder wird ein Projektplan mit hunderten von Arbeitspaketen auf Stundenebene erstellt, der nach zwei Wochen veraltet ist. Oder es gibt nur eine grobe Phasenübersicht ohne konkrete Arbeitspakete, Verantwortlichkeiten und Abhängigkeiten. Beides funktioniert nicht.

Ein ERP-Projekt im Mittelstand durchläuft typischerweise sieben Phasen. Die Grenzen zwischen den Phasen sind nicht immer trennscharf – manche Aktivitäten laufen parallel –, aber die grundlegende Reihenfolge ist in den meisten Projekten gleich. Jede Phase hat spezifische Ergebnisse, die erreicht sein müssen, bevor die nächste beginnt.

Die erste Phase – die Vorbereitung – wird oft als reine Formalität betrachtet, dabei legt sie das Fundament für alles, was folgt. Wer gehört zum Projektteam? Welche Ziele verfolgt das Projekt? Welche Bereiche sind im Scope und welche nicht? Ein häufiger Fehler: Der Scope wird zu vage definiert. Wenn nicht klar ist, welche Prozesse und Standorte umgestellt werden, fehlt die Grundlage für alle weiteren Planungsschritte. Investieren Sie ausreichend Zeit in ein klares Scope-Dokument – es spart Ihnen später Monate.

Die Analysephase ist das Herzstück der Planung. Hier werden die bestehenden Prozesse aufgenommen und die Soll-Prozesse für das neue System definiert. Im Mittelstand bedeutet das: Workshops mit den Fachabteilungen, in denen die tatsächlichen Arbeitsabläufe dokumentiert werden – nicht die, die im Handbuch stehen, sondern die, die tatsächlich gelebt werden. Auf Basis der Ist-Analyse wird das Soll-Konzept erstellt und die Fit-Gap-Analyse durchgeführt, die über den Umfang der Anpassungen und damit über Dauer und Kosten der Realisierungsphase entscheidet.

In der Realisierungsphase wird das System konfiguriert und angepasst. Hier zeigt sich, ob die Konzeption belastbar war: Wenn die Anforderungen klar dokumentiert sind, kann die Umsetzung strukturiert erfolgen. Wenn nicht, beginnt ein Kreislauf aus Rückfragen, Änderungswünschen und Nacharbeiten, der den Zeitplan sprengt. Für den Mittelstand ist entscheidend, dass die internen Ansprechpartner ausreichend verfügbar sind. Der ERP-Anbieter kann das System konfigurieren – aber er braucht dafür fachliche Rückmeldung. Wenn Key User im Tagesgeschäft gebunden sind, verzögert sich die Realisierung unweigerlich.

Die Testphase wird im Mittelstand regelmäßig zu kurz geplant. Dabei ist sie der letzte Moment, um Fehler zu finden, bevor sie im Produktivbetrieb auftreten. Ein guter Testplan umfasst nicht nur technische Tests, sondern vor allem Prozesstests: Die Key User arbeiten ihre realen Geschäftsprozesse im neuen System durch – von der Angebotserstellung über die Bestellung bis zur Rechnungsstellung. Planen Sie für die Testphase ausreichend Zeit ein und berücksichtigen Sie, dass Key User nicht parallel zum Tagesgeschäft ausführlich testen können.

Die Datenmigration läuft in der Regel parallel zu anderen Phasen, ist aber ein eigener Workstream mit eigener Komplexität. Unterschätzen Sie nicht den Aufwand für die Datenbereinigung: In vielen Mittelständlern sind über Jahre Datenaltlasten entstanden – doppelte Kundenstammsätze, inkonsistente Artikelbezeichnungen, veraltete Lieferanteneinträge. Diese Altlasten mitzumigrieren bedeutet, das neue System von Anfang an mit schlechten Daten zu belasten.

Der Cutover selbst ist die operativ intensivste Phase: In wenigen Tagen wird das alte System abgeschaltet und das neue in Betrieb genommen. Ein detaillierter Cutover-Plan mit klaren Verantwortlichkeiten und einer Fallback-Strategie ist unverzichtbar. Nach dem Go-Live beginnt die Hypercare-Phase, in der das Projektteam für schnelle Problemlösung bereitsteht. Tägliche Stand-ups helfen, Probleme früh zu erkennen. Diese Phase wird im Projektplan oft vergessen – ein Fehler, denn sie bindet erhebliche Ressourcen.

Wie sollte ein ERP-Projektplan konkret strukturiert sein? Die folgende Struktur hat sich in unserer Beratungspraxis als Template bewährt. Sie bildet die wesentlichen Planungsebenen ab und lässt sich auf die Gegebenheiten des jeweiligen Unternehmens anpassen.

Wie lange dauert ein ERP-Projekt im Mittelstand? Die ehrliche Antwort: länger als die meisten denken. Ein typisches ERP-Projekt in einem Unternehmen mit 50 bis 500 Mitarbeitern dauert von der Projektvorbereitung bis zum stabilen Produktivbetrieb zwischen 9 und 18 Monaten. Projekte, die in sechs Monaten geplant werden, sind selten realistisch – es sei denn, der Scope ist sehr eng begrenzt.

Der häufigste Planungsfehler: Die verfügbare Arbeitszeit der internen Mitarbeiter wird überschätzt. Key User stehen nicht zu 100 Prozent für das Projekt zur Verfügung – sie haben ein Tagesgeschäft, das weiterläuft. Erfahrungsgemäß können Mitarbeiter im Mittelstand 30 bis 50 Prozent ihrer Arbeitszeit für das ERP-Projekt aufwenden. Der Projektplan muss diese Realität abbilden. Planen Sie außerdem Puffer ein – ein Puffer von 15 bis 20 Prozent der Gesamtlaufzeit ist keine Luxusreserve, sondern eine realistische Absicherung gegen unvorhergesehene Ereignisse wie Personalwechsel, Krankheitsfälle, neue Anforderungen oder technische Probleme.

Ein ERP-Projektplan ohne Ressourcenplanung ist unvollständig. Es reicht nicht zu wissen, welche Arbeitspakete in welcher Reihenfolge abgearbeitet werden. Sie müssen auch wissen, wer diese Arbeitspakete bearbeitet und ob diese Personen in dem geplanten Zeitraum tatsächlich verfügbar sind. Im Mittelstand ist die Ressourcenfrage besonders kritisch: Die gleichen Mitarbeiter, die das ERP-Projekt vorantreiben sollen, tragen auch die Verantwortung für das Tagesgeschäft.

Wenn der Vertriebsleiter gleichzeitig Key User für den Vertriebsprozess im neuen System ist, aber im vierten Quartal seine Umsatzziele erreichen muss, wird das Projekt in dieser Phase stocken. Ein guter Ressourcenplan macht diese Konflikte sichtbar – bevor sie auftreten. Er zeigt auf Monatsebene, welche Mitarbeiter in welchem Umfang für das Projekt benötigt werden, und ermöglicht es der Geschäftsführung, frühzeitig Entlastung oder Vertretung zu organisieren.

Meilensteine sind die Kontrollpunkte des Projektplans. Sie markieren den Abschluss einer Phase oder eines kritischen Arbeitspakets. Quality Gates gehen einen Schritt weiter: Sie definieren Kriterien, die erfüllt sein müssen, bevor die nächste Phase beginnen darf. In der Praxis sehen wir häufig, dass Meilensteine zwar definiert werden, aber keine echten Quality Gates sind. Die Konzeptionsphase wird als abgeschlossen erklärt, obwohl wichtige Anforderungen noch offen sind. Die Testphase wird verkürzt, weil der Go-Live-Termin feststeht. Diese Kompromisse rächen sich später – oft in Form von Nacharbeit, Verzögerungen und Zusatzkosten.

“Ein Meilenstein ohne definierte Akzeptanzkriterien ist kein Meilenstein – er ist ein Datum im Kalender.”

Definieren Sie für jeden Phasenübergang klare Kriterien: Welche Dokumente müssen vorliegen? Welche Ergebnisse müssen abgenommen sein? Wer entscheidet über das Bestehen des Quality Gates? Diese Kriterien schaffen Transparenz und verhindern, dass Probleme in die nächste Phase verschleppt werden.

In unserer Beratungspraxis begegnen uns bestimmte Planungsfehler immer wieder. Sie sind nicht Ausdruck mangelnder Kompetenz, sondern Folge typischer Rahmenbedingungen im Mittelstand: Zeitdruck, knappe Ressourcen und der Wunsch, schnell Ergebnisse zu sehen.

In vielen Projekten wird der Go-Live-Termin von der Geschäftsführung vorgegeben, bevor ein detaillierter Projektplan existiert. Das Ergebnis: Der Plan wird so zusammengebaut, dass er zum Termin passt – nicht umgekehrt. Puffer werden gestrichen, Phasen werden komprimiert, und am Ende reicht die Zeit für die Testphase nicht aus.

Wenn der Projektplan davon ausgeht, dass Key User fünf Tage pro Woche für das Projekt verfügbar sind, ist er von Anfang an unrealistisch. Im Mittelstand haben alle Projektbeteiligten operative Aufgaben, die weiterlaufen. Ein realistischer Plan berücksichtigt eine Verfügbarkeit von 30 bis 50 Prozent und passt die Zeitschienen entsprechend an.

Projekte verlaufen nie exakt nach Plan. Wenn der Projektplan keinen Puffer enthält, wird jede Verzögerung automatisch zum Krisenmodus. Ebenso wichtig: Wer entscheidet, wenn der Plan nicht mehr hält? Ohne definierten Eskalationsweg bleiben Entscheidungen liegen, und Verzögerungen kumulieren sich.

Ein Projektplan, der nach der Erstellung nicht mehr angepasst wird, verliert innerhalb weniger Wochen seine Relevanz. Regelmäßige Plan-Ist-Abgleiche – mindestens alle zwei Wochen – sind kein Overhead, sondern die Grundlage für eine funktionierende Projektsteuerung. Nur so können Abweichungen früh erkannt und Gegenmaßnahmen eingeleitet werden.

Puffer sind in der Projektplanung kein Eingeständnis von Unsicherheit – sie sind das Ergebnis von Erfahrung. Kein ERP-Projekt verläuft exakt nach Plan. Es gibt immer unvorhergesehene Anforderungen, technische Probleme, Personalengpässe oder externe Faktoren, die den Zeitplan beeinflussen. Erfahrungsgemäß empfehlen wir einen Gesamtpuffer von 15 bis 20 Prozent der geplanten Projektlaufzeit. Dieser Puffer sollte nicht gleichmäßig verteilt werden, sondern dort konzentriert, wo die Unsicherheit am größten ist: zwischen Konzeption und Realisierung sowie vor dem Go-Live.

Puffer sind kein Freibrief für Verzögerungen. Sie sind ein professionelles Instrument, um mit der inhärenten Unsicherheit komplexer Projekte umzugehen. Wer auf Puffer verzichtet, plant nicht ambitioniert – er plant unrealistisch.

Ein ERP-Projektplan dient nicht nur der internen Steuerung. Er ist auch ein Kommunikationsinstrument, das unterschiedliche Zielgruppen bedienen muss. Die Geschäftsführung braucht einen Überblick über Phasen, Meilensteine und Kosten. Das Projektteam braucht detaillierte Arbeitspakete und Abhängigkeiten. Die Fachabteilungen müssen wissen, wann sie in welchem Umfang gebraucht werden. Das bedeutet in der Praxis: Ein guter Projektplan hat verschiedene Detaillierungsebenen – eine Management-Übersicht auf einer Seite, darunter ein detaillierter Plan mit Arbeitspaketen und Ressourcen, und ganz unten die operative Ebene mit konkreten Aufgaben und Terminen.

Welches Tool Sie für Ihren ERP-Projektplan verwenden, ist weniger wichtig als die Frage, ob der Plan gepflegt und genutzt wird. Microsoft Project ist ein mächtiges Werkzeug, aber nur dann sinnvoll, wenn jemand im Team damit umgehen kann. Für viele Mittelständler ist eine gut strukturierte Excel-Datei oder ein Tool wie Asana, Monday oder Smartsheet praxistauglicher. Entscheidend ist, dass der Plan für alle Beteiligten zugänglich ist und regelmäßig aktualisiert wird. Ein perfekter Plan in einem Tool, das niemand öffnet, ist wertlos.

Die Zeit, die Sie in einen sorgfältigen ERP-Projektplan investieren, zahlt sich mehrfach aus. Ein realistischer Plan verhindert böse Überraschungen, macht Konflikte frühzeitig sichtbar und gibt allen Beteiligten Orientierung. Er ersetzt nicht die Erfahrung und das Urteilsvermögen der Projektleitung – aber er schafft die Grundlage dafür, dass Erfahrung und Urteilsvermögen wirksam werden können.

Die wichtigsten Erkenntnisse: Planen Sie realistisch, nicht optimistisch. Berücksichtigen Sie die tatsächliche Verfügbarkeit Ihrer Mitarbeiter. Bauen Sie Puffer ein. Definieren Sie Quality Gates mit echten Akzeptanzkriterien. Und pflegen Sie den Plan regelmäßig – er ist kein statisches Dokument, sondern ein lebendes Steuerungsinstrument. Wenn Sie einen ERP-Projektplan erstellen möchten, der in der Praxis funktioniert, sprechen Sie mit uns. Wir bringen die Erfahrung aus über zwei Jahrzehnten ERP-Beratung im Mittelstand mit und helfen Ihnen, einen Plan zu entwickeln, der Ihr Projekt zum Erfolg führt.

Der richtige Detaillierungsgrad hängt von der Phase ab. Für die Gesamtübersicht reichen Phasen und Meilensteine auf Wochenebene. Für die operative Steuerung brauchen Sie Arbeitspakete mit Verantwortlichen, Aufwänden und Abhängigkeiten. Vermeiden Sie eine Planung auf Stundenebene – sie suggeriert eine Genauigkeit, die in der Realität nicht haltbar ist, und erzeugt einen Pflegeaufwand, der den Nutzen übersteigt. Als Faustregel: Ein Arbeitspaket sollte zwischen einer und vier Wochen dauern.

Für ein Unternehmen mit 50 bis 500 Mitarbeitern sollten Sie mit einer Gesamtdauer von 9 bis 18 Monaten rechnen – von der Projektvorbereitung bis zum stabilen Produktivbetrieb. Die reine Implementierung (Konzeption bis Go-Live) dauert dabei typischerweise 6 bis 12 Monate. Entscheidend für die Dauer sind der Scope, die Komplexität der Prozesse, die Anzahl der Schnittstellen und die Verfügbarkeit des internen Projektteams.

Zunächst: Abweichungen vom Plan sind normal und kein Zeichen des Scheiterns. Entscheidend ist, wie Sie damit umgehen. Analysieren Sie die Ursache der Abweichung: Liegt es an der Ressourcenverfügbarkeit, an veränderten Anforderungen oder an technischen Problemen? Auf Basis der Analyse können Sie den Plan anpassen – etwa durch Verschiebung des Go-Live-Termins, Reduzierung des Scopes oder Aufstockung der Ressourcen. Wichtig ist, dass die Anpassung bewusst und transparent erfolgt, nicht durch stillschweigendes Weitermachen.