ERP-Lastenheft – Anforderungsdokument für ERP-Projekte
Definition: Ein ERP-Lastenheft ist ein vom Auftraggeber erstelltes Dokument, das die fachlichen, technischen und organisatorischen Anforderungen an ein neues ERP-System strukturiert beschreibt. Es bildet die Grundlage für die Anbieterauswahl, das spätere Pflichtenheft des Lieferanten und die vertragliche Leistungsbeschreibung.
Ein gut gemachtes Lastenheft entscheidet maßgeblich über Erfolg oder Misserfolg eines ERP-Projekts. Es zwingt das Unternehmen, sich mit Soll-Prozessen, Schwachstellen und strategischen Zielen auseinanderzusetzen, bevor Anbieter angesprochen werden – und schafft so Vergleichbarkeit und Verbindlichkeit.
Abgrenzung Lastenheft vs. Pflichtenheft
Die DIN 69901-5 trennt klar: Das Lastenheft beschreibt das „Was“ aus Sicht des Auftraggebers – welche Anforderungen erfüllt werden sollen. Das Pflichtenheft hingegen beschreibt das „Wie“ aus Sicht des Auftragnehmers – mit welchen Mitteln, in welcher Architektur und mit welchen Konfigurationen das Lastenheft erfüllt wird. Pflichtenhefte folgen typischerweise auf das Lastenheft.
Aufbau eines ERP-Lastenhefts
Bewährter Aufbau: 1. Unternehmensbeschreibung und Geschäftsmodell. 2. Ziele und Rahmenbedingungen des Projekts. 3. Ist-Analyse der bestehenden Systemlandschaft. 4. Soll-Prozesse mit funktionalen Anforderungen je Modul (Einkauf, Verkauf, Produktion, Lager, Finanzen, Personal). 5. Nicht-funktionale Anforderungen: Performance, Sicherheit, Verfügbarkeit, Compliance (DSGVO, GoBD), Mehrsprachigkeit, Mandantenfähigkeit.
6. Schnittstellen und Integrationen (DATEV, EDI, BI, Webshops). 7. Mengengerüst (Anwender, Belege, Datenvolumen). 8. Technische Anforderungen (Cloud/On-Premises, Mobilfähigkeit, Browserunterstützung). 9. Anforderungen an Anbieter (Branchenkenntnis, Referenzen, Support). 10. Bewertungsmodell und Auswahlprozess.
Anforderungskatalog und Bewertung
Funktionale Anforderungen werden meist als strukturierter Katalog – häufig als Excel- oder Datenbank-basierter Fragebogen – formuliert. Üblich ist eine Klassifikation: Muss (K.O.-Kriterium), Soll (gewünscht, gewichtet) und Kann (optional). Anbieter beantworten je Anforderung mit Standard, Konfiguration, Anpassung oder „nicht möglich“.
Daraus entsteht eine Bewertungsmatrix mit gewichteten Punktzahlen, ergänzt um Workshops, Use-Case-Demos und Referenzkundenbesuche. Wichtig: Anforderungen müssen testbar formuliert sein – statt „Das System soll schnell sein“ besser „Auftragsanlage in unter zwei Sekunden bei 200 parallelen Nutzern“.
Erfolgsfaktoren und typische Fehler
Erfolgsfaktoren: enge Einbindung der Fachbereiche, klare Priorisierung, realistischer Detaillierungsgrad, Trennung von Standard- und Sonderanforderungen, valider Ist-Aufnahme. Häufige Fehler: Wunschlisten ohne Priorisierung, kopierte Standardkataloge ohne Bezug zum Unternehmen, fehlende nicht-funktionale Anforderungen, unklare Mengengerüste.
Empfehlenswert ist eine externe Begleitung durch ERP-Beratung, die Erfahrung aus mehreren Projekten einbringt und blinde Flecken reduziert. Das Lastenheft sollte vor der Anbietersuche fertig sein – nicht erst während laufender Demos entstehen.
Vom Lastenheft zum RfP-Prozess
Das Lastenheft bildet die inhaltliche Grundlage des RfP-Prozesses (Request for Proposal). Üblicherweise wird zunächst eine Long List möglicher Anbieter erstellt, anschließend per RfI (Request for Information) auf eine Short List von 3 bis 5 Kandidaten reduziert. Diese erhalten das vollständige Lastenheft inklusive Anforderungskatalog und Bewertungsmodell.
Im weiteren Verlauf folgen Bieterworkshops, Use-Case-Demos mit konkreten Geschäftsszenarien, Referenzkundenbesuche und kommerzielle Verhandlungen. Erst nach dieser strukturierten Auswahl entsteht das Pflichtenheft des gewählten Anbieters – als Antwort auf das Lastenheft und Grundlage für die vertragliche Leistungsbeschreibung.
Tools und Templates
Reine Word-Dokumente stoßen bei größeren Lastenheften an Grenzen. Bewährt sind dedizierte Anforderungsmanagement-Tools (Jama, Polarion, Jira), strukturierte Excel-Vorlagen mit Pivots und Bewertungsformeln oder spezialisierte ERP-Auswahlplattformen, die Anbieterprofile, Anforderungskataloge und Bewertungslogiken bündeln.
Wichtig ist eine eindeutige Numerierung der Anforderungen (z. B. F-EK-0123 für eine funktionale Einkaufsanforderung), versionierte Ablage, klare Owner pro Modul und ein nachvollziehbares Änderungsmanagement, sobald das Lastenheft erstmals an Anbieter übermittelt wurde.
Im Mittelstand sind 50 bis 150 Seiten plus Anforderungskatalog typisch. Größere Konzerne kommen oft auf mehrere hundert Seiten. Wichtiger als der Umfang ist allerdings die inhaltliche Schärfe: Lieber ein präzises 80-Seiten-Dokument als ein aufgeblähter Katalog ohne Priorisierung.
Brauche ich ein Lastenheft, wenn ich Cloud-Standardsoftware will?
Auch bei standardnahen SaaS-Lösungen lohnt ein Lastenheft – mit Fokus auf Geschäftsanforderungen, Schnittstellen und nicht-funktionalen Themen statt auf detaillierte Funktionsfelder. Es hilft, den richtigen Standard auszuwählen, statt teure Anpassungen zu fordern.
Lizenzgebühren machen typisch nur 25-35 % der Gesamtprojektkosten aus, die restlichen 65-75 % entstehen für Implementation, Customizing, Schulung und Datenmigration.
Wer schreibt das Lastenheft – IT oder Fachbereich?
Beides. Die fachlichen Anforderungen kommen aus den Fachbereichen, die technischen und integrativen Aspekte aus der IT. Ein Projektleiter konsolidiert beides, ergänzt durch externe Beratung. Reines IT- oder reines Fachbereichs-Lastenheft führt regelmäßig zu Lücken.
