ERP-Projektstrukturplan: Aufbau, Methodik und Best Practices

Ein Projektstrukturplan – kurz PSP – ist die hierarchische Zerlegung eines Projekts in seine Bestandteile. Er beantwortet die grundlegendste Frage jedes Projekts: Was muss alles getan werden? Nicht wann, nicht von wem, nicht in welcher Reihenfolge – sondern ausschließlich: Was ist der vollständige Umfang der Arbeit?

Diese scheinbar einfache Frage ist in ERP-Projekten überraschend schwer zu beantworten. ERP-Einführungen sind komplex, abteilungsübergreifend und berühren nahezu jeden Geschäftsprozess. Ohne eine systematische Zerlegung dieser Komplexität verliert das Projektteam den Überblick – und mit ihm die Kontrolle über Umfang, Ressourcen und Fortschritt. Ein PSP ist dabei bewusst kein Projektplan. Er enthält keine Termine, keine Abhängigkeiten und keine Ressourcenzuordnungen. Er ist die strukturelle Grundlage, auf der all das aufgebaut wird. Wer ohne PSP plant, plant auf Sand: Der Zeitplan mag detailliert aussehen, aber niemand kann mit Sicherheit sagen, ob er vollständig ist.

In kleineren Projekten kann man auf einen formalen PSP verzichten. Ein erfahrener Projektleiter hat den Überblick, die Arbeitspakete sind überschaubar, die Beteiligten kennen ihre Aufgaben. In ERP-Projekten funktioniert das nicht.

Der Grund liegt in der Natur dieser Projekte: Sie umfassen technische, organisatorische und menschliche Dimensionen gleichzeitig. Softwarekonfiguration, Datenmigration, Schnittstellenentwicklung, Testmanagement, Schulung, Change Management, Rollout-Planung – all das muss koordiniert und aufeinander abgestimmt werden. Ohne eine Struktur, die diese Dimensionen sichtbar macht, entstehen die typischen Probleme: Arbeitspakete werden vergessen, Abhängigkeiten nicht erkannt, Verantwortlichkeiten unklar. Der PSP schafft ein gemeinsames Verständnis zwischen allen Projektbeteiligten darüber, was zum Projekt gehört – und was nicht. Er ist das zentrale Dokument zur Scope-Definition und damit das wichtigste Instrument gegen Scope Creep.

Für die Gliederung eines ERP-Projektstrukturplans gibt es drei grundlegende Ansätze. Jeder hat seine Berechtigung, und die Wahl hängt von der Projektcharakteristik und der Organisation ab. In der Praxis kombinieren viele Projekte Elemente aus mehreren Ansätzen.

Der dritte Ansatz ist die objektorientierte Gliederung, die sich an den Ergebnissen oder Lieferobjekten des Projekts orientiert: System-Konfiguration, Migrationsdatensätze, Schulungsunterlagen, Schnittstellenspezifikationen. Dieser Ansatz eignet sich besonders, wenn das Projekt stark ergebnisorientiert gesteuert wird und klare Deliverables definiert sind. In der Praxis hat sich für mittelständische ERP-Projekte eine Kombination aus phasen- und funktionsorientierter Gliederung bewährt: Die oberste Ebene folgt den Projektphasen, die zweite Ebene gliedert nach Fachbereichen oder Modulen, und die dritte Ebene bricht die Arbeit in konkrete Arbeitspakete herunter.

Ein gut strukturierter PSP für ein mittelständisches ERP-Projekt umfasst in der Regel drei bis vier Hierarchieebenen. Weniger Ebenen schaffen zu wenig Transparenz, mehr Ebenen erzeugen unnötige Komplexität.

Die oberste Ebene repräsentiert das ERP-Projekt als Ganzes. Sie dient als Klammer und liefert den Bezugspunkt für alle untergeordneten Elemente. In der Darstellung ist sie der Wurzelknoten des PSP-Baums.

Die zweite Ebene zerlegt das Projekt in seine wesentlichen Teilbereiche. Bei einem phasenorientierten Ansatz könnten das sein: Projektinitialisierung, Analyse und Konzeption, Systemkonfiguration, Datenmigration, Test und Abnahme, Schulung und Change Management, Go-Live und Hypercare. Bei einem funktionalen Ansatz wären es die Fachbereiche: Vertrieb, Einkauf, Lager und Logistik, Finanzen, IT-Infrastruktur.

Die dritte Ebene enthält die Arbeitspakete – die kleinsten Einheiten im PSP, die einer Person oder einem Team zugeordnet und hinsichtlich Aufwand und Ergebnis definiert werden können. Beispiele: Ist-Prozessaufnahme Einkauf, Konfiguration Artikelstamm, Migration Kundenstammdaten, Erstellung Testfälle Vertrieb, Schulung Key User Lager. Arbeitspakete sind die Grundlage für die Aufwandsschätzung, die Ressourcenplanung und die Fortschrittskontrolle. Sie sollten so geschnitten sein, dass sie in einem überschaubaren Zeitraum abschließbar sind – in der Regel nicht länger als zwei bis vier Wochen. Arbeitspakete, die länger dauern, sollten weiter zerlegt werden.

Eine vierte Ebene kann sinnvoll sein, wenn Arbeitspakete aus mehreren definierbaren Aktivitäten bestehen. Beispiel: Das Arbeitspaket Migration Kundenstammdaten könnte die Aktivitäten Datenextraktion aus Altsystem, Datentransformation und Mapping, Bereinigung der Dublettenprüfung, Testimport in die Zielumgebung und Abnahme der migrierten Daten umfassen. Diese vierte Ebene gehört allerdings eher in den detaillierten Projektplan als in den PSP selbst.

Bevor Sie mit der Strukturierung beginnen, brauchen Sie Klarheit über den Projektumfang. Was gehört zum Projekt und was nicht? Welche Standorte sind betroffen? Welche Module werden eingeführt? Welche Schnittstellen müssen realisiert werden? Und mindestens genauso wichtig: Was wird bewusst ausgeklammert? Diese Scope-Definition sollte schriftlich festgehalten und von allen relevanten Stakeholdern bestätigt werden. Sie ist die Grundlage für den PSP und gleichzeitig das Referenzdokument, gegen das spätere Änderungswünsche bewertet werden.

Entscheiden Sie, nach welchem Prinzip Sie den PSP aufbauen. Für die meisten mittelständischen ERP-Projekte empfehlen wir die Kombination aus Phasen- und Funktionsorientierung: Die oberste Ebene bildet die Projektphasen ab, die darunterliegende Ebene gliedert nach Fachbereichen oder Modulen. Wichtig ist, dass der gewählte Ansatz für alle Beteiligten nachvollziehbar ist. Ein PSP, den nur der Projektleiter versteht, verfehlt seinen Zweck.

Die zweite Ebene ist das Grundgerüst des PSP. Sie sollte gemeinsam mit den Projektverantwortlichen erarbeitet werden – nicht im stillen Kämmerlein durch den Projektleiter allein. Die Frage an dieser Stelle lautet: In welche großen Bereiche lässt sich das Projekt sinnvoll zerlegen? Und sind diese Bereiche vollständig – oder fehlt etwas? Ein häufiger Fehler an dieser Stelle: Querschnittsthemen wie Datenmigration, Schnittstellenentwicklung oder Change Management werden vergessen oder unter andere Teilprojekte subsumiert. Sie verdienen eigene Teilprojekte auf Ebene 2, weil sie eigene Ressourcen, eigene Verantwortlichkeiten und eigene Risiken haben.

Die dritte Ebene erfordert die Mitarbeit der Fachbereiche. Jedes Arbeitspaket sollte ein klar definiertes Ergebnis haben, einer verantwortlichen Person zugeordnet werden können und in einem überschaubaren Zeitraum abschließbar sein. Die Granularität sollte so gewählt werden, dass der Fortschritt messbar ist, ohne dass der PSP unübersichtlich wird. Eine bewährte Faustregel: Wenn ein Arbeitspaket mehr als vier Wochen Aufwand erfordert, sollte es weiter zerlegt werden. Wenn es weniger als einen Tag dauert, ist es zu fein für den PSP und gehört in den detaillierten Projektplan.

Der fertige PSP muss auf Vollständigkeit geprüft werden. Die zentrale Frage: Ist alles enthalten, was getan werden muss, um das Projekt erfolgreich abzuschließen? Diese Prüfung sollte nicht nur durch den Projektleiter erfolgen, sondern durch das Steering Committee und die Fachbereichsverantwortlichen. Nach der Freigabe wird der PSP zur Baseline: dem verbindlichen Referenzdokument für den Projektumfang. Änderungen am PSP sind möglich, müssen aber über einen formalen Change-Request-Prozess laufen. Diese Verbindlichkeit ist entscheidend – sie macht den PSP zu dem Instrument, das er sein soll: eine verlässliche Grundlage für Planung, Steuerung und Kommunikation.

In unserer Beratungspraxis sehen wir wiederkehrende Muster, die die Qualität und Wirksamkeit eines Projektstrukturplans untergraben. Die folgenden sechs Fehler kommen besonders häufig vor.

In der Theorie gibt es spezialisierte Werkzeuge für die Erstellung von Projektstrukturplänen. In der Praxis mittelständischer ERP-Projekte sehen wir drei Formate, die sich bewährt haben – abhängig von der Projektgröße und den Präferenzen des Teams.

Die Baumdarstellung ist die klassische Form: Das Gesamtprojekt als Wurzelknoten, darunter die Teilprojekte, darunter die Arbeitspakete. Werkzeuge wie Microsoft Visio, Miro oder sogar PowerPoint eignen sich dafür. Der Vorteil ist die visuelle Klarheit. Der Nachteil: Bei großen Projekten wird die Darstellung schnell unübersichtlich. Die tabellarische Darstellung ordnet die PSP-Elemente in einer nummerierten Liste mit Einrückungen. Eine einfache Excel-Tabelle reicht dafür aus. Dieser Ansatz skaliert besser als die Baumdarstellung und eignet sich gut als Grundlage für den anschließenden Projektplan.

Die Mind-Map-Darstellung eignet sich besonders für die Erarbeitungsphase: In einem Workshop kann der PSP als Mind Map entwickelt und anschließend in eine tabellarische oder Baumstruktur überführt werden. Der Vorteil: Mind Maps fördern kreatives, vollständiges Denken – die Frage, ob etwas fehlt, lässt sich in einer Mind Map oft leichter beantworten als in einer Liste.

Ein oft übersehener Aspekt: Der PSP ist nicht nur ein Planungsinstrument – er ist auch ein Kommunikationsinstrument. Er zeigt allen Beteiligten auf einen Blick, was zum Projekt gehört und wie es strukturiert ist. Für die Geschäftsleitung liefert er den Überblick über die Teilprojekte. Für die Fachbereiche macht er sichtbar, welche Arbeitspakete sie betreffen. Für das Systemhaus definiert er den Lieferumfang. Diese Transparenz ist besonders in der Zusammenarbeit mit externen Partnern wertvoll. Ein klarer PSP verhindert Missverständnisse über den Leistungsumfang und schafft eine gemeinsame Sprache für die Projektsteuerung. Wenn alle Beteiligten von denselben Arbeitspaketen sprechen, sinkt die Wahrscheinlichkeit von Fehlinterpretationen erheblich.

Ein mittelständisches Handelsunternehmen mit rund 150 Mitarbeitenden führt ein neues ERP-System ein. Die Einführung umfasst die Module Einkauf, Vertrieb, Lager, Finanzen und eine Webshop-Anbindung. Der PSP könnte auf Ebene 2 folgende Teilprojekte umfassen: Projektinitialisierung und Governance, Anforderungsanalyse und Konzeption, Systemkonfiguration nach Modulen (Einkauf, Vertrieb, Lager, Finanzen), Schnittstellenentwicklung (Webshop, EDI, Banking), Datenmigration, Testmanagement, Schulung und Change Management, Go-Live und Hypercare, sowie Projektmanagement als durchlaufendes Arbeitspaket.

Jedes dieser Teilprojekte enthält auf Ebene 3 zwischen drei und acht Arbeitspakete. Das Teilprojekt Datenmigration beispielsweise umfasst: Datenanalyse und Qualitätsbewertung, Mapping-Definition zwischen Alt- und Neusystem, Bereinigung der Stammdaten, Entwicklung der Migrationsskripte, Testmigration, finale Migration zum Go-Live und Abnahme der migrierten Daten. Dieser Detailgrad reicht aus, um Aufwand zu schätzen, Verantwortliche zuzuordnen und den Fortschritt zu messen.

Ein Projektstrukturplan ist kein bürokratisches Dokument, das in einer Projektakte verstaubt. Er ist das Fundament, auf dem alle weiteren Planungsschritte aufbauen: Zeitplanung, Ressourcenplanung, Kostenplanung, Risikomanagement. Ohne dieses Fundament bauen Sie auf unsicherem Grund.

Die Investition in einen sauberen PSP zahlt sich über die gesamte Projektlaufzeit aus. Er verhindert, dass Arbeitspakete vergessen werden. Er macht den Projektumfang für alle Beteiligten transparent. Er schafft die Grundlage für realistische Aufwandsschätzungen. Und er ist das zentrale Instrument gegen Scope Creep – die häufigste Ursache für Budgetüberschreitungen in ERP-Projekten. Nehmen Sie sich die Zeit für eine sorgfältige PSP-Erstellung. Beziehen Sie die Fachbereiche ein. Wählen Sie einen Strukturierungsansatz, der zu Ihrem Projekt passt. Und machen Sie den PSP zum lebenden Dokument, das den Projektfortschritt begleitet – nicht zum einmaligen Pflichtdokument, das nach dem Kick-off in der Schublade verschwindet.

In einem kostenlosen 30-minütigen Erstgespräch besprechen wir gemeinsam, ob Ihre Projektstruktur als Grundlage für eine erfolgreiche ERP-Einführung tragfähig ist – und welche Schritte jetzt den größten Hebel haben.

Der Projektstrukturplan beantwortet die Frage: Was muss getan werden? Er zeigt den vollständigen Projektumfang in einer hierarchischen Struktur – ohne Termine, Abhängigkeiten oder Ressourcen. Der Projektplan beantwortet die Fragen: Wann wird es getan, von wem und in welcher Reihenfolge? Er baut auf dem PSP auf und ergänzt die zeitliche, ressourcenbezogene und ablauflogische Dimension. Ohne PSP fehlt dem Projektplan das Fundament: Man plant Aktivitäten, ohne sicher zu sein, ob der Umfang vollständig ist.

Für mittelständische ERP-Projekte empfehlen wir drei Hierarchieebenen: Gesamtprojekt, Teilprojekte und Arbeitspakete. Die Arbeitspakete sollten einen Aufwand von ein bis vier Wochen haben – groß genug, um als Steuerungseinheit zu dienen, und klein genug, um den Fortschritt messbar zu machen. Eine vierte Ebene mit detaillierten Aktivitäten ist optional und gehört eher in den Projektplan als in den PSP selbst. Zu wenig Detail führt zu fehlender Transparenz, zu viel Detail zu Pflegeaufwand ohne Mehrwert.

Für die Erarbeitungsphase empfehlen wir eine Mind Map oder ein Whiteboard – physisch oder digital. Das fördert vollständiges Denken und die Einbindung der Fachbereiche. Für die anschließende Dokumentation und Pflege hat sich eine tabellarische Darstellung in Excel oder einem Projektmanagement-Tool bewährt. Spezialisierte PSP-Software ist für die meisten mittelständischen Projekte nicht erforderlich. Wichtiger als das Werkzeug ist der Prozess: gemeinsam erarbeiten, validieren und als verbindliches Referenzdokument behandeln.

Quellen: DIN 69901-5, Projektmanagement – Begriffe; PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide); GPM, ICB 4.0; eigene Projekterfahrung aus ERP-Begleitungen im Handel und Großhandel