Lastenheft versus Pflichtenheft – was ist der Unterschied?

Die Begriffe Lastenheft und Pflichtenheft werden im Alltag und in ERP-Projekten gerne synonym verwendet.

Die Begriffe Lastenheft und Pflichtenheft werden im Alltag und in ERP-Projekten gerne synonym verwendet.

Beide Dokumente stehen grundsätzlich für Anforderungen oder für Beschreibungen eines oder mehrerer Zustände, Produkte oder einer zu erwartenden Dienstleistung. Dennoch haben das Lastenheft und das Pflichtenheft im Vertragsmanagement eine wichtige unterschiedliche Rolle. In diesem Artikel werden die Bedeutungen und Unterschiede in einem „Lastenheft versus Pflichtenheft" beschrieben und verständlich dargestellt.

Lastenheft – Wann wird ein Lastenheft benötigt?

Ein Lastenheft ist im weitesten Sinne eine Spezifikation der Leistungen, die gefordert werden (Sollkonzeption oder Anforderungskatalog). Es definiert zum Teil sehr detailliert die Anforderungen des Managements im Rahmen des Reportings, der betroffenen Mitarbeiterinnen und Mitarbeiter und Prozessinhaber in Bezug auf Transaktionen und die Unterstützung der Prozesse durch ein ERP-System sowie die der technischen Rahmenbedingungen.

In einem Lastenheft sollen die Anforderungen an eine Lösung oder die Anforderungen für ein Softwaresystem beschrieben werden, das zur Steuerung des Unternehmens dienen soll (zum Beispiel eine ERP-Software).

Im Rahmen der Anforderungen (Requirements) des Managements, der Unternehmensstrategie und der daraus abzuleitenden IT-Strategie wird die große Linie und die Ziele für die nächsten Jahre festgelegt. Für die Konzeption der Anforderungen an eine neue Software (z. B. eine neue ERP-Lösung) ist es zwingend notwendig, die Anforderungen aus der Unternehmensstrategie abzuleiten und zu dokumentieren. Alle Requirements haben im Hintergrund immer die zu unterstützenden Geschäftsprozesse zum Kunden und den Kundenservice und beschreiben damit das Organisationsmodell.

Gerade für das Management (als Auftraggeber für die IT) ist dieses Dokument für die Überprüfung des Umsetzungsgrades der Unternehmensstrategie durch die Fachabteilung wichtig. Das erstellte Lastenheft dient als entscheidendes Anforderungsdokument, sozusagen als Quality Gate für die Freigabe der Anforderungen. Damit kann die Suche nach einem Umsetzungspartner (Softwarehaus) begonnen werden. Das Lastenheft ist ein Dokument, welches eine Idee (Geschäftsprozess) und Rahmenbedingungen formuliert, dabei aber nicht zwangsläufig detailgenau eine Lösung festschreibt.

Dennoch enthält das Lastenheft selbstverständlich technische und inhaltliche Vorgaben (die gesamten Dokumentationen aus dem Requirement-Engineering), die beschreiben, welche Geschäftsprozesse unterstützt und welche Ziele mit einer neuen Software erreicht werden sollen. Das können Vorgaben für ERP-Software, CRM, Master-Data-Management-Systeme oder ganze Prozessketten wie die Definition einer (kundenspezifischen) Supply Chain sein.

Idealerweise ist das Lastenheft so aufgebaut, dass es dem Auftragnehmer (das Softwarehaus bzw. der Softwaredienstleister) die Möglichkeit gibt, auf die Anforderungen passende Lösungsansätze aus seinem Fundus auszuwählen.

Wer erstellt das Lastenheft – die Sicht des Auftraggebers: Ein Lastenheft wird im Unterschied zu einem Konzept immer durch einen Auftraggeber (zum Beispiel die Geschäftsleitung, das Management oder eine Projektsponsorin bzw. einen Projektsponsor aus dem Businessbereich) funktional definiert und durch den Auftraggeber erstellt. Es definiert konkret die Anforderungen an das Organisationsmodell (den Geschäftsprozess) und die Requirements für die Technik.

In Ausnahmefällen werden Lastenhefte auch durch Softwarelieferanten erstellt. Dies ist aber kritisch zu hinterfragen und zu prüfen. Kann der Auftraggeber sicher sein, dass er die beste Lösung bekommt — oder wurde das Lastenheft so erstellt, dass es dem Leistungsangebot des Softwarelieferanten am besten entspricht?

Was muss ein Lastenheft beinhalten?

In der Regel werden die Anforderungen in einem ERP-Lastenheft durch Textbeschreibungen der Anforderungen und durch Prozessbeschreibungen (Bilder) dargestellt. Das können

• Zeichnungen,
• Tabellen oder
• Ablaufdiagramme (Flow-Charts oder Swimlane-Darstellungen)

Tipp: Die Expertinnen und Experten von Dreher Consulting haben vor einigen Jahren begonnen, bereits im Lastenheft Prozesskennzahlen (sogenannte Key Performance Indicators, KPIs) zu definieren und einzubauen. Heute sind diese KPIs ein integraler Bestandteil eines SCOReX®-gestützten Lastenhefts und helfen unseren Kundinnen und Kunden, die Anforderungen an Prozessqualität und Prozesseffizienz an den Softwarelieferanten messbar zu adressieren.

Das agile Lastenheft – was ist darunter zu verstehen?

Diese Form des Lastenheftes wird zunehmend in Unternehmen eingesetzt. Dabei ist zu berücksichtigen, dass eine Definition von Anforderungen durch agile Vorgehensweise heute noch manche Organisation an die Grenzen ihrer Leistungsfähigkeit bringen kann. Die Organisation, das Requirement Engineering, die Sprints, die Zusammenarbeit der Teams, die Fehlerkultur und das Change Management müssen dazu ausgelegt sein. Das Thema agiles Lastenheft vertiefen wir in einem eigenen Artikel.

Aufbau eines Lastenhefts

In der Regel wird das (klassische) Lastenheft nach folgendem Schema aufgebaut (Vorschlag zu einem Inhaltsverzeichnis):

Die 10 Bausteine eines klassischen Lastenhefts

Beim Erstellen des ERP-Lastenheftes ist es wichtig, dem Softwareanbieter die Möglichkeit zu geben, später seine Expertise in das IT-Projekt einzubringen. Daher macht es in der Regel keinen Sinn, sich auf eine Auswahlmethode mit Funktionsbeschreibungen zu versteifen, wie sie meist durch Auswahltools aus dem Internet oder durch unendliche Excel-Listen definiert werden. Dies gilt im gleichen Kontext für Auswahlplattformen zur Software-Selection.

Unsere Einordnung: Eine Ist-Aufnahme von Anforderungen mit Excel-Listen ist ein Überbleibsel aus dem letzten Jahrtausend. Der Schlüssel für einen erfolgreichen ROI und damit für ein erfolgreiches Projekt liegt in der Unterstützung der Geschäftsprozesse. Dies lässt sich durch Tools oder Auswahlalgorithmen allein nicht abbilden — und schon gar nicht durch generelle KI-Modelle, die jeden Prompt isoliert betrachten.

Unternehmen, die sich nachhaltig und in einem digitalen Umfeld behaupten wollen, sind erfolgreicher, wenn sie sich auf die Prozessauswahl fokussieren und dafür messbare Kennzahlen definieren.

Schon mit Beginn der Identifikation von Softwarelieferanten, mit denen ein ERP-Projekt oder eine andere Softwarelösung eingeführt werden soll, wird ein systematisches Auswahlverfahren angestoßen. Dies führt zur qualitativ anspruchsvollen Identifikation eines Software-Anbieters. In weiteren Schritten wird ein immer enger werdender Qualifikationsprozess durchgeführt. Dies führt am Ende dieses neutralen ERP-Auswahlverfahrens zur Beauftragung eines Lieferanten. Dieser Stufenprozess oder das Vorgehensmodell wird in diesem Artikel, bei dem es um den Vergleich Lastenheft versus Pflichtenheft geht, nicht behandelt.

Auf das Lastenheft folgt normalerweise das Pflichtenheft

Nachdem das Lastenheft erstellt wurde, wird es in ein Pflichtenheft überführt. Die Zielgrößen stehen fest: Sie wurden in der Unternehmens- und in der IT-Strategie auf hohem Niveau definiert und in der Dokumentation auf die Arbeitsebene heruntergebrochen. Zusätzlich werden KPIs (Prozesskennzahlen) festgelegt, um die Prozessqualität zu messen.

Gemeinsam mit dem Softwareanbieter wird der Leistungsumfang der Softwarelösung (beim Kauf einer Standardsoftware) mit dem Lastenheft abgeglichen und danach mit den Erfahrungen aus Best-Practice-Ansätzen des Auftragnehmers (Softwarelieferanten) angereichert. Das ist der wesentliche Unterschied zwischen Lastenheft und Pflichtenheft. In der Abbildung „Vom Lastenheft zum Pflichtenheft" ist der Prozess gut erkennbar. Der Unterschied wird durch die Anreicherung des Inhaltes definiert, hier dargestellt durch die Größe der Fläche.

Vom Lastenheft zum Pflichtenheft

Vom Lastenheft zum Pflichtenheft — die Anreicherung wird durch die Größe der Fläche dargestellt.  

Dabei wird genau festgelegt, wo Standards eingesetzt und wo individuelle Programmierung notwendig sein wird. Im Fall einer ausschließlichen Individualprogrammierung sollte der Leistungsumfang der Programmierergebnisse genau definiert werden, da nicht auf Ergebnisse einer bestehenden Software zurückgegriffen werden kann. Hier sind Genauigkeit und Präzision der zu erwartenden Ergebnisbeschreibung ein wichtiger Punkt, um ein Projekt erfolgreich abzuschließen.

Wichtig dabei ist auch die Definition der Integration der neuen Software in das bisherige IT-System und damit der Informationsaustausch der Systeme über Schnittstellen in die bestehende Software oder verknüpfte Datenbanken. Auch die notwendigen Arbeiten im Rahmen von Datenbereinigungen, Erweiterungen von Stammdaten und Stammdatenstrukturen sollten in einem Pflichtenheft beschrieben werden, ebenso wie Anforderungen an die Hardware, das Netzwerk (Leistungsfähigkeit und Sicherheit) sowie die Datenhaltung (Datenbank). Nicht zu unterschätzen sind die Anforderungen an Stammdaten in den bisherigen Systemen, deren Qualität und die Überführung in ein neues System.

Projektabschluss: Unsere Erfahrung hat gezeigt, dass es sinnvoll und hilfreich ist, das Abnahmeprozedere und das Qualitätsmanagement ebenfalls im Pflichtenheft zu definieren. Das ist nicht immer ganz einfach, aber es lohnt sich auf jeden Fall, da dann Käufer und Lieferant genau wissen, ab wann eine Leistung abgenommen werden kann.

Auf Basis des Pflichtenheftes wird dann durch den Softwareanbieter ein Angebot und danach ein Vertragsdokument erstellt. Das Pflichtenheft wird idealerweise Bestandteil des Kaufvertrages.

Lastenheft versus Pflichtenheft

Im Lastenheft werden unternehmerische Ziele, technische und Prozessanforderungen, Grafiken, Tabellen und, wo möglich, Prozessabläufe beschrieben und spezifiziert. Das Lastenheft wird durch den Softwareanbieter um seine Informationen zu den Fähigkeiten seiner Lösung, seiner Methodik, der Schnittstellen und der Projektmethodik angereichert und als gemeinsames Dokument zwischen Auftraggeber und Auftragnehmer (Softwarehaus) festgelegt.

Damit wird aus einem Lastenheft (Anforderungskatalog) ein Pflichtenheft mit genauen Spezifikationen.

Auf dieser Basis kann ein Angebot und später ein Vertrag erstellt werden, der das Pflichtenheft als wichtigen Bestandteil beinhaltet.

In der Infografik „Lastenheft versus Pflichtenheft" in unserem kostenlosen, downloadbaren Whitepaper ist in aller Kürze dargestellt, wo die Unterschiede liegen und wer für das Lastenheft und wer für das Pflichtenheft die Verantwortung trägt. Ebenso ist klar erkennbar, was die Ziele des Lastenhefts versus Pflichtenheftes sind.

Trends 2026: Was sich beim Lastenheft gerade verschiebt

Wer 2026 ein Lastenheft schreibt wie 2018, schreibt ein Dokument, das schon bei Vertragsabschluss veraltet ist. Vier Verschiebungen prägen den DACH-Mittelstand in diesem Jahr. Keine davon ist eine Frage der Mode, alle vier sind eine Frage der Verhandlungsmacht.

Vier Verschiebungen 2026 — Überblick

1. Anforderungen werden zu User Stories — nicht zu Funktionslisten

Die ältere Disziplin der ERP-Auswahl bestand darin, hunderte Funktionen in eine Excel-Tabelle zu kippen und Anbieter sie abhaken zu lassen. Dieser Ansatz schützt heute vor allem den Anbieter: Wer eine Funktion abhakt, hat kein Versprechen über deren Zusammenspiel im Prozess gegeben. Moderne Lastenhefte arbeiten mit User Stories — also mit der Beschreibung, wie ein Geschäftsprozess für die handelnde Person konkret abläuft. Das verschiebt die Diskussion mit dem Softwareanbieter weg von der Funktion und hin zur Prozess-Wirkung.

2. Die E-Rechnungs-Pflicht zwingt Lastenhefte in die Schnittstellen-Tiefe

Seit dem 1. Januar 2025 müssen Unternehmen im B2B-Bereich elektronische Rechnungen empfangen können; die Übergangsfristen für den Versand laufen bis Ende 2026 aus. Das klingt nach einem IT-Detail — in der ERP-Auswahl ist es ein strategisches Lastenheft-Kapitel. Wer XRechnung, ZUGFeRD und PEPPOL nicht als Pflichtkriterium aufnimmt, verschiebt Aufwand in die Implementierung und in den Betrieb. Aus unserer Erfahrung sind das die Anforderungen, die in 2022 noch ein „nice to have" waren und 2026 die ersten Anbieter aus der Shortlist nehmen.

3. KI-Mustererkennung in Anforderungsdokumenten. Aber bitte mit Beleg

KI-gestützte Tools können Lastenhefte heute auf Widersprüche, Redundanzen und Lücken prüfen. Die Versuchung ist groß, die KI auch direkt formulieren zu lassen. Hier ist Vorsicht geboten. Ein generelles Sprachmodell — gleich ob ChatGPT, Claude oder ein anderes — sieht Ihre Eingabe und seine Trainingsdaten. Es sieht nicht Ihre bisherigen Systeme, nicht Ihre Pain Points, nicht die Dynamik Ihres Marktes. Wer das ignoriert, bekommt ein Lastenheft, das gut klingt. Und im Vertrag nichts trägt. Wir kommen darauf weiter unten zurück.

4. Aus Funktionslisten werden Modul-Roadmaps

Drei von zehn ERP-Projekten scheitern laut ERP Barometer 2024 an unklaren Anforderungen. Der häufigste Auslöser: Das Lastenheft beschreibt, was die Software kann, statt was das Unternehmen in den nächsten drei Jahren tun wird. Lastenhefte 2026 gliedern sich deshalb zunehmend nach Modulen und Wertströmen. Und beschreiben pro Modul den Soll-Prozess samt KPI. Das macht aus dem Lastenheft eine Modul-Roadmap, die in der Vertragsverhandlung schwerer zu zerreden ist als jede Funktionsliste.

Lastenheft in Ihrer Branche: Was wir gelöst haben

Ein Lastenheft ist niemals branchenneutral, auch wenn das Inhaltsverzeichnis es so aussehen lässt. Drei Branchen, in denen wir besonders viele Auswahlprojekte begleitet haben, illustrieren, woran ein Dokument im Mittelstand wirklich scheitert. Und woran es trägt.

Handel & Konsumgüter

Outdoor-Hersteller, Sportartikelmarken und Functional-Food-Unternehmen stehen unter saisonalem Druck und gleichzeitig unter Lieferketten-Stress. Das verändert die Anforderungen an ein ERP-Lastenheft grundlegend.

Schmerzpunkt: Lastenhefte mit hunderten SKU-Anforderungen. Aber ohne Supply-Chain-Logik. Das Dokument zählt Artikelvarianten, Saisonalitäten und Größenraster auf, vergisst aber den Sourcing-Lead-Time, die Mindestbestellmengen der Vorlieferanten und die Returns-Logik der Endkund:innen. Anbieter offerieren dann eine ERP-Standardlösung, die zwar SKUs abbildet, aber den eigentlichen Engpass nicht löst.

Lösung aus unserer Praxis: Wir haben in einem Projekt mit einem deutschen Outdoor-Spezialisten — mit dem wir seit 15 Jahren zusammenarbeiten — das Lastenheft entlang der Wertkette neu gegliedert: Sourcing, Bestand, Saisonplanung, Omni-Channel-Auslieferung, Retouren. Jedes Modul mit Soll-Prozess, KPI und Schnittstellen-Anforderung. Vergleichbare Strukturen haben wir bei einem internationalen Sportartikel-Hersteller und einer Functional-Food-Marke aus dem deutschsprachigen Raum eingesetzt.

Lektion: Im Handel führt ein Lastenheft entlang der Wertkette zu kürzeren Verhandlungen mit Anbietern und zu Verträgen, die die Saison überleben. Funktionslisten gewinnen Sie kein Weihnachtsgeschäft — Modul-Roadmaps schon.

Lastenheft im Handel prüfen lassen →

Anlagen- & Maschinenbau

Der DACH-Maschinenbau lebt vom Spannungsfeld zwischen Serie und Projekt. Jeder Auftrag ist potenziell ein Werkvertrag nach BGB § 631. Und genau diese Logik muss im Lastenheft sichtbar sein, sonst überträgt sie sich auch nicht in den ERP-Vertrag mit dem Softwarehaus.

Schmerzpunkt: Lastenhefte vermischen Serien- und Projektgeschäft. Anbieter merken das im Workshop und positionieren ihre Standardmodule für das eine, ihre Customizing-Stunden für das andere. Am Ende stehen Projektkosten in der Implementierung, die sich beim Lastenheft hätten vermeiden lassen.

Lösung aus unserer Praxis: Wir trennen im Lastenheft konsequent zwischen Stücklistenführung, Variantenkonfiguration und Engineering-Change-Management. Pro Modul wird beschrieben, wie sich ein Engineering-Change durch Stückliste, Beschaffung, Fertigung und Service zieht — inklusive der Schnittstellen zu PLM und CAD-Systemen. Damit bekommt der Anbieter eine klare Vorlage, gegen die er Standardmodule und Erweiterungen sauber kalibrieren kann.

Lektion: Im Maschinenbau ist die Trennung von Serie und Projekt im Lastenheft kein Detail. Sie ist die Grundlage dafür, dass das Pflichtenheft später als Werkvertrag tragbar ist.

Lastenheft im Maschinenbau prüfen lassen →

Professionelle Dienstleistungen

Akademien, Bildungsträger, IT-Dienstleisterinnen und Beratungen verkaufen kein Produkt. Sie verkaufen Kapazität, Qualifikation und Termintreue. Genau das übersetzen klassische Lastenhefte am schlechtesten.

Schmerzpunkt: Das Dokument fokussiert auf Stammdaten und Finanzbuchhaltung und vernachlässigt das Ressourcen-Modell. Ein Trainer ist keine Maschine, eine Beraterin kein Lagerartikel. Wenn das Lastenheft Skill-Profile, Verfügbarkeits-Logik und Auslastungs-KPIs nicht beschreibt, bekommt das Unternehmen eine ERP-Lösung, die es zur Excel-Schattenrechnung zwingt. Und der Mehrwert verschwindet.

Lösung aus unserer Praxis: In einem Projekt mit einer multiregionalen Sprachakademie haben wir das Lastenheft so umgebaut, dass Kursmanagement, Trainerverfügbarkeit, Standort-Splits und Finanzkonsolidierung ein durchgängiges Modul ergeben. Bei einem Anbieter eines Passagierinformationssystems haben wir denselben Ansatz auf grenzüberschreitende Beschaffungs- und Service-Prozesse übertragen. Das Resultat in beiden Fällen: signifikant weniger Excel-Schattenarbeit nach Go-Live.

Lektion: In der Dienstleistung gewinnt das Lastenheft, das das Skill- und Auslastungsmodell so präzise beschreibt wie ein Industrie-Lastenheft die Stückliste.

Lastenheft im Dienstleistungssektor prüfen lassen →

Wo das Lastenheft die Verhandlung gewinnt — und wo SCOReX® das Lastenheft gewinnt

Die meisten Lastenhefte schützen den Anbieter, nicht den Auftraggeber. Das liegt selten an böser Absicht. Es liegt daran, dass das Dokument in der falschen Auflösung geschrieben ist: zu fein in den Funktionen, zu grob in den Prozessen, zu kurzsichtig in der Zeitachse.

Genau diese Auflösung ist die Stelle, an der unsere Beraterinnen und Berater mit SCOReX® arbeiten. SCOReX® ist unser firmeneigenes KI-gestütztes Entscheidungsmodell. Es ist nicht der Autor des Lastenhefts. Der Autor bleibt der Berater oder die Beraterin, die Sie kennen und mit der Sie verhandeln. SCOReX® ist das Instrument, mit dem wir jede Anforderung gegen drei Dimensionen prüfen, bevor sie ins Dokument geht: gegen Ihre eigenen Prozesse, gegen die Pain Points und Systeme aus über 400 begleiteten Auswahlprojekten und gegen die voraussichtliche Entwicklung der Anforderung in den nächsten drei Jahren.

Was unsere Beraterinnen und Berater mit SCOReX® anders machen

In einem klassischen Workshop hängt die Qualität jeder einzelnen Anforderung an der Tagesform der Teilnehmenden. Mit SCOReX® liegt jede formulierte Anforderung sofort neben vergleichbaren Anforderungen aus früheren Projekten und neben den existierenden Systemen, mit denen die neue Lösung sprechen muss. Wir sehen während des Workshops, wo Anforderungen miteinander in Konflikt stehen, wo sie redundant sind und wo Lücken entstehen, die ein Anbieter später für Customizing nutzen würde. Das Modell strukturiert und beschleunigt das Urteilsvermögen unserer Beraterinnen und Berater, es ersetzt es nicht.

Warum nicht einfach ein generelles KI-Modell?

Eine berechtigte Frage — gerade weil ChatGPT, Claude und vergleichbare Sprachmodelle inzwischen sehr ordentlich klingende Lastenheft-Entwürfe liefern können. Die saubere Antwort hat vier Zeilen und eine Konsequenz.

Unsere Einordnung: Ein generelles Sprachmodell sieht Ihre Anfrage. SCOReX® sieht Ihr Unternehmen. Und jedes vergleichbare ERP-Projekt, das wir bisher begleitet haben. Das ist kein Werkzeug-Wettstreit. Das ist die Frage, ob Ihr Lastenheft am Verhandlungstisch hält oder nicht.

Was am Ende im Dokument steht

Ein Lastenheft, das mit SCOReX®-Unterstützung entstanden ist, sieht auf den ersten Blick aus wie jedes andere — Inhaltsverzeichnis, Prozesse, Schnittstellen, KPIs. Auf den zweiten Blick fehlen drei Dinge, die andere Lastenhefte enthalten: redundante Funktionsabfragen, in sich widersprüchliche Anforderungen und Module, die in Ihrer Branche nachweislich keinen ROI tragen. Stattdessen sehen Sie eine Modul-Roadmap, die ein Anbieter eindeutig kalibrieren kann. Und die unser Beraterteam vor Ihnen verteidigt, falls der Anbieter sie zerreden will.

• Nächster Schritt: 30 Min. mit Dr. Dreher

  Wenn Sie aktuell vor einer ERP-Auswahl stehen oder ein bestehendes Lastenheft prüfen lassen möchten, ist der schnellste Weg ein 30-minütiger Web-Termin. Sie bekommen drei konkrete Punkte:
  
  

• Eine Einordnung Ihres aktuellen Lastenhefts oder Ihrer Auswahlsituation entlang der Modul-Roadmap-Logik,

• Eine ehrliche Einschätzung, wo das Dokument den Anbieter heute schützt und nicht Ihr Unternehmen,

• Einen klaren nächsten Schritt — mit oder ohne weitere Zusammenarbeit mit Dreher Consulting.

Über 400 begleitete ERP-Auswahlverfahren aus dem DACH-Mittelstand stehen hinter dieser Einschätzung — und damit eine Erfahrung, die ein Sprachmodell nicht haben kann.

Weitere Lesehinweise: ERP-Pflichtenheft — wirklich notwendig zur Softwareauswahl? · ERP-Beratung und Lastenheft · begleitete Auswahlprojekte.