Lastenheft
Ein Lastenheft ist die vom Auftraggeber erstellte Dokumentation aller Anforderungen an ein System – bei ERP-Projekten beschreibt es aus Sicht des Unternehmens, was das ERP-System leisten soll, ohne technische Lösungswege vorzugeben.
Ein Lastenheft ist das vom Auftraggeber erstellte Dokument, das sämtliche Anforderungen an ein zu beschaffendes oder zu entwickelndes System vollständig und nachvollziehbar beschreibt. Es beantwortet die Frage „Was soll gemacht werden und wofür?" – bei einem ERP-Projekt also, welche Prozesse, Funktionen und Rahmenbedingungen das künftige ERP-System abdecken muss. Bewusst legt das Lastenheft nur die Ziele und Anforderungen fest, nicht den konkreten technischen Lösungsweg. Wie diese Anforderungen umgesetzt werden, beschreibt später der Auftragnehmer im Pflichtenheft.
Nach DIN 69901-5 ist das Lastenheft die „Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers". Es ist damit die zentrale, verbindliche Grundlage jeder Ausschreibung: Anbieter können nur dann vergleichbare Angebote abgeben, wenn sie auf demselben, klar formulierten Anforderungskatalog aufsetzen. In der ERP-Auswahl ist das Lastenheft deshalb kein bürokratisches Beiwerk, sondern das Werkzeug, das eine faire, kriteriengestützte Entscheidung überhaupt erst möglich macht und das Risiko einer teuren Fehlentscheidung senkt.
Auf einen Blick
- Vom Auftraggeber erstellt: beschreibt das „Was" und „Wofür", nicht das „Wie"
- Definiert nach DIN 69901-5 als Gesamtheit der Anforderungen des Auftraggebers
- Gegenstück ist das Pflichtenheft – die Anbieterantwort mit dem Lösungsweg
- Anforderungen werden nach Muss, Soll und Kann priorisiert
- Schafft die vergleichbare Basis für Ausschreibung und ERP-Auswahl
Was gehört in ein Lastenheft?
Ein gutes Lastenheft ist vollständig, widerspruchsfrei und für alle Beteiligten verständlich – vom Fachbereich bis zum Anbieter. Es trennt sauber zwischen der Beschreibung des Ist-Zustands, den Zielen und den eigentlichen Anforderungen. Jede Anforderung sollte eindeutig, prüfbar und möglichst lösungsneutral formuliert sein, damit Anbieter ihren eigenen Weg zur Erfüllung vorschlagen können.
Typische Bestandteile
Zum Standardaufbau eines ERP-Lastenhefts gehören: eine Einführung mit Unternehmens- und Projektkontext, die Ist-Analyse der aktuellen Prozesse und Systemlandschaft, die Projektziele, der funktionale Anforderungskatalog (etwa Auftragsabwicklung, Warenwirtschaft, Einkauf, Finanzbuchhaltung, Reporting), die nicht-funktionalen Anforderungen (Performance, Verfügbarkeit, Bedienbarkeit, Datenschutz), benötigte Schnittstellen und Datenmigration sowie organisatorische und rechtliche Rahmenbedingungen. Ergänzend werden oft Mengengerüste genannt – etwa Zahl der Nutzer, Belege pro Tag oder Artikel im Sortiment.
Priorisierung nach Muss, Soll und Kann
Damit Anbieter erkennen, worauf es wirklich ankommt, werden Anforderungen priorisiert. Muss-Anforderungen sind zwingend und wirken als K.-o.-Kriterien: Erfüllt ein System sie nicht, scheidet es aus. Soll-Anforderungen sind wichtig, aber nicht existenziell; Kann-Anforderungen sind wünschenswerte Extras. Diese Priorisierung ist die Grundlage der späteren gewichteten Bewertungsmatrix und verhindert, dass viele kleine Vorteile eine fehlende Kernfunktion überdecken.
Lastenheft vs. Pflichtenheft: die Abgrenzung
Lastenheft und Pflichtenheft werden häufig verwechselt, bezeichnen aber zwei aufeinanderfolgende Dokumente mit klar getrennter Rolle. Das Lastenheft stammt vom Auftraggeber und beschreibt die Anforderungen – das „Was". Das Pflichtenheft stammt vom Auftragnehmer und beschreibt als Antwort darauf die konkrete Umsetzung – das „Wie". Bildlich gesprochen: Der Auftraggeber formuliert im Lastenheft seine Wünsche, der Anbieter erklärt im Pflichtenheft, wie er sie mit seinem System realisiert.
Zeitlich entsteht das Lastenheft zuerst, meist in der ERP-Auswahl vor der Ausschreibung. Das Pflichtenheft folgt nach der Anbieterentscheidung zu Projektbeginn und wird häufig Vertragsbestandteil. Erst wenn der Auftraggeber das Pflichtenheft abnimmt, ist verbindlich geklärt, dass Anforderung und geplante Lösung zusammenpassen. Diese Zweistufigkeit schützt beide Seiten: Der Auftraggeber muss keine technischen Lösungen vorschreiben, der Anbieter bekommt eine prüfbare Anforderungsbasis und dokumentiert seine Zusagen nachvollziehbar.
Das Lastenheft im ERP-Auswahlprozess
Im Ablauf einer ERP-Auswahl steht das Lastenheft am Übergang von der internen Anforderungsanalyse zur Marktansprache. Aus den aufgenommenen Ist-Prozessen und Soll-Zielen der Fachbereiche entsteht der Anforderungskatalog, der anschließend an die Anbieter der Shortlist geht. Es ist damit das wichtigste Bindeglied zwischen dem, was das Unternehmen braucht, und dem, was der Markt anbietet.
Der praktische Nutzen ist doppelt. Erstens macht das Lastenheft Angebote vergleichbar, weil alle Anbieter denselben Katalog beantworten – ohne diese gemeinsame Basis vergleicht man Äpfel mit Birnen. Zweitens zwingt die Erstellung das Unternehmen, seine Prozesse und Prioritäten selbst zu klären; oft ist dieser interne Klärungsprozess mindestens so wertvoll wie das fertige Dokument. Ein präzises Lastenheft reduziert später Change Requests, Nachträge und Budgetüberschreitungen, weil Missverständnisse früh sichtbar werden. Umgekehrt ist ein vages oder fehlendes Lastenheft eine der häufigsten Ursachen für gescheiterte oder verteuerte ERP-Einführungen.
Typische Fehler beim Lastenheft
Der häufigste Fehler ist, den Lösungsweg vorzuschreiben statt die Anforderung zu beschreiben – etwa „Das System muss eine bestimmte Datenbank nutzen" statt „Bestände müssen in Echtzeit über alle Kanäle konsistent sein". Solche Vorgaben schränken den Anbieter unnötig ein und verschenken bessere Standardlösungen. Ebenso problematisch sind vage, nicht prüfbare Formulierungen wie „soll benutzerfreundlich sein", die sich im Nachhinein nicht objektiv bewerten lassen.
Weitere Klassiker sind eine fehlende Priorisierung, bei der jede Anforderung gleich wichtig erscheint, sowie das Vergessen nicht-funktionaler Anforderungen wie Schnittstellen, Datenmigration, Rollen- und Rechtekonzept oder gesetzlicher Vorgaben. Ein überladenes „Wunschkonzert" ohne Bezug zum tatsächlichen Bedarf treibt die Kosten, während ein zu knappes Lastenheft Interpretationsspielraum lässt, der später teuer nachverhandelt wird. Sinnvoll ist ein mittlerer Detailgrad: präzise bei den geschäftskritischen Prozessen, offen genug bei allem, wo der Anbieter seine Stärken einbringen soll.
DACH-Besonderheiten und Normbezug
Im deutschsprachigen Raum sind Lasten- und Pflichtenheft durch die DIN 69901-5 (Projektmanagement) und historisch die VDI-Richtlinie 2519 begrifflich klar definiert – eine Trennung, die im internationalen Umfeld oft nicht existiert, wo beides unter „Requirements Specification" zusammenfällt. Diese normierte Zweiteilung prägt DACH-Ausschreibungen bis heute und ist besonders im öffentlichen Vergaberecht relevant, wo ein vollständiges, diskriminierungsfreies Lastenheft Voraussetzung für ein rechtssicheres Verfahren ist.
Für ERP-Projekte im DACH-Mittelstand kommen inhaltliche Besonderheiten hinzu, die ins Lastenheft gehören: GoBD-Konformität, eine DATEV- oder BMD-Schnittstelle für die Buchhaltung, Anforderungen an die E-Rechnung sowie – bei mehreren Gesellschaften – Mandantenfähigkeit. Wer diese Punkte früh als Muss-Anforderungen dokumentiert, filtert ungeeignete Systeme sofort aus und vermeidet, dass regulatorische Lücken erst in der Einführung auffallen.
Praxisbeispiel
Beispiel: E-Commerce-Händler erstellt ein Lastenheft
Ein Onlinehändler mit 25 Mitarbeitern verkauft über den eigenen Shop und drei Marktplätze und stößt mit seiner bisherigen Insellösung an Grenzen. Vor der Anbietersuche nimmt ein kleines Projektteam die Kernprozesse auf und gießt sie in ein Lastenheft. Als Muss-Anforderungen definiert es unter anderem die Echtzeit-Synchronisation der Bestände über alle Kanäle, eine GoBD-konforme Belegablage, eine DATEV-Schnittstelle und die automatische Verbuchung von Zahlungseingängen.
Soll-Anforderungen sind ein integriertes Retourenmanagement und ein Dashboard für Kanal-Deckungsbeiträge; als Kann-Wunsch notiert das Team eine spätere Anbindung eines Warehouse-Systems. Dieses priorisierte Lastenheft geht an vier Anbieter. Weil alle denselben Katalog beantworten, kann das Team die Rückläufe direkt in eine Bewertungsmatrix übertragen – zwei Systeme scheitern an einem Muss-Kriterium, die übrigen zwei gehen mit klaren Stärkenprofilen in die Demo-Phase.
Häufige Fragen
Passende ERP-Systeme
Passende Leistungen
Quellen
Fragen zu Lastenheft in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.