Lastenheft versus Pflichtenheft – was ist der Unterschied?

ERP- Publikationen By: Dr. Harald Dreher - Feb 16, 2022

Profitieren Sie von 3 Jahrzehnten Erfahrung in IT-Strategie, Digitalisierung, ERP-Beratung und Prozessoptimierung.

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 Rollen. In diesem Artikel werden die Bedeutungen und Unterschiede in einem „Lastenheft versus Pflichtenheft“ beschrieben und verständlich dargestellt. 

Lastenheft versus Pflichtenheft

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 Rollen. In diesem Artikel werden die Bedeutungen und Unterschiede in einem „Lastenheft versus Pflichtenheft“ beschrieben und verständlich dargestellt. 

 

Inhaltsverzeichnis

  1. Lastenheft – Wann wird ein Lastenheft benötigt?
  2. Was muss ein Lastenheft beinhalten?
  3. Das agile Lastenheft – was ist darunter zu verstehen ?
  4. Aufbau eines Lastenhefts
  5. Auf das Lastenheft folgt normalerweise das Pflichtenheft
  6. Lastenheft versus Pflichtenheft

 

Lastenheft – Wann wird ein Lastenheft benötigt?

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

In einem Lastenheft sollen die Anforderung 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 daher 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 LastenheftDie Sicht des Auftraggebers:Ein Lastenheft wird im Unterschied zu einem Konzept immer durch einen Auftraggeber (zum Beispiel die Geschäftsleitung, das Management oder ein 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) sein.

Tipp: Die Experten von Dreher Consulting haben vor einigen Jahren begonnen, bereits im Lastenheft Prozesskennzahlen (sog. Key Performance Indikators KPIs) zu definieren und einzubauen. Diese helfen unseren Kunden, die Anforderungen an Prozessqualität und Prozesseffizienz an den Softwarelieferanten klar 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. Zum Thema agiles Lastenheft wird ein eigener Artikel erscheinen.

 

Aufbau eines Lastenhefts

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

  • Einführung
  • Ziele des Projektes und der Dokumentation
  • Produktbeschreibung (Prozessmanagement)
    • Beschreibung des Ist-Zustandes
    • Beschreibung des Ziels bzw. Soll-Zustandes
  • Beschreibung der Schnittstellen
  • Produktdetails
  • Funktionale Anforderungen
    • Anforderungen an Leistungen und Datenqualität (Prozesskennzahlen KPIs)
    • Technische Grundlagen und technisches Umfeld, in denen die ERP-Software eingebunden werden soll
    • Anforderungen an die Qualität der Lösung und der Dokumentation
  • Die Beschreibung des Betriebes der Lösung
  • Projektorganisation, Projektmethodik
  • Zeitliche Vorgaben, Meilensteine und Termine für den Echtbetrieb
  • Ergänzende Beschreibungen

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 zu Software-Selection. 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 noch nicht abbilden.

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 werden.

 

lastenheft versus pflichtenheft bild cta

 

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

lastenheft zum pflichtenheft

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 ist 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 alle 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.

 

 

Buchen Sie ein 30-minütiges Beratungsgespräch – kostenlos & unverbindlich.
Mehr erfahren
Wir hoffen, diese Publikation ist nützlich für Sie. Wenn Sie weitere Fragen zu diesem Thema haben, freuen wir uns, von Ihnen zu hören." - Dr Harold Dreher