L der unterschied zwischen lastenheft und pflichtenheft

Lastenheft und Pflichtenheft sind zwei Begriffe, die bei ERP-Entscheidern oft Verwirrung auslösen. Sie gelten als Synonyme, obwohl es sich in der Praxis um Dokumente mit unterschiedlicher Zielsetzung handelt.

Lastenheft und Pflichtenheft sind nicht identisch. Beide Begriffe synonym zu verwenden, führt schnell zu Missverständnissen – gerade in der Kommunikation mit Partnern oder Dienstleistern. Um diese Probleme zu vermeiden, sollten sich angehende ERP-Entscheider rechtzeitig mit der Bedeutung beider Dokumente vertraut machen.

Lastenheft

Das ERP-Lastenheft wird vom Kunden verfasst und enthält alle Informationen, die für die Auswahl eines ERP-Systems relevant sind. Dazu zählen:

Kontextinformationen (z. B. Unternehmensgröße, Standorte oder aktuelle IT-Infrastruktur)
Funktionale Anforderungen (z. B. Feinplanung oder Lagerverwaltung)
Nicht-funktionale Anforderungen (z. B. mobile Anwendbarkeit oder Schnittstellen)

Die Fertigstellung des Lastenhefts ist der Startschuss für die ERP-Auswahl. Die Anforderungsanalyse ist abgeschlossen und das Unternehmen hat definiert, was das neue ERP-System können muss. Von da an geht es darum, einen geeigneten Anbieter zu finden, der diese Anforderungen erfüllt.

Aus Sicht des Auftraggebers bildet das Lastenheft einen Rahmen für die ERP-Auswahl. In dem Dokument sind alle Überlegungen und Entscheidungen festgehalten. Bei Fragen oder Unklarheiten wird in der Regel das Lastenheft zurate gezogen.

Aus Sicht des Auftragnehmers erklärt das Lastenheft im Detail, was der Auftraggeber von ihm erwartet. Das Dokument enthält alle Anforderungen und Spezifikationen des Kunden. Falls ein Fit vorliegt, kann der ERP-Anbieter das Lastenheft als Input verwenden, um Informationsmaterial und Workshops vorzubereiten.

Vereinfacht gesagt: Das Lastenheft dokumentiert, welche Anforderungen der Kunde an ein ERP-System stellt.

Pflichtenheft

Das Pflichtenheft entsteht nach Abschluss der ERP-Auswahl. Es wird vom ERP-Anbieter verfasst und dokumentiert, wie er die Anforderungen im Lastenheft technisch umsetzen will.

Genau wie das Lastenheft bildet das Pflichtenheft ein Framework für den weiteren Projektverlauf. Es enthält zum einen Soll-Zustände auf Prozessebene, die als Ziele vereinbart wurden. Zum anderen beschreibt es detailliert, mit welchen technischen Möglichkeiten, Funktionen und Konfigurationen des ERP-Systems diese Soll-Zustände realisiert werden.

Abseits der Rahmenbedingungen dient das Pflichtenheft als Abnahmekriterium für die implementierte ERP-Lösung. Am Ende des Projekts überprüfen beide Seiten, ob die Software wie im Pflichtenheft vereinbart umgesetzt wurde und alle funktionalen und nicht-funktionalen Anforderungen erfüllt.

Das Pflichtenheft ist für beide Seiten rechtlich bindend. Der Auftraggeber bestätigt mit der Unterzeichnung, dass der dokumentierte Soll-Zustand seinen Wünschen entspricht. Der Auftragnehmer erklärt sich einverstanden, die festgehaltenen Leistungen zu erbringen. Spätere Änderungen am Dokument, egal von welcher Seite, sind ohne Vertragsanpassung nicht mehr möglich.

Vereinfacht gesagt: Das Pflichtenheft beschreibt, wie der ERP-Anbieter die Anforderungen des Kunden umsetzen wird.

Was ist der Unterschied?

Oberflächlich betrachtet haben Lasten- und Pflichtenheft durchaus Gemeinsamkeiten. Beide enthalten Problembeschreibungen, Anforderungen und Erwartungen an die neue ERP-Lösung. Das ist auch nicht verwunderlich, denn beide Dokumente bauen aufeinander auf. Das Pflichtenheft ist quasi die Antwort des Auftragnehmers auf die Fragen, die der Auftraggeber im Lastenheft gestellt hat.

ERP-Lastenheft und -Pflichtenheft sind nicht identisch! Sie synonym zu betrachten führt zu Missverständnissen.

Der Unterschied zwischen den zwei Dokumenten liegt in ihrer Funktion. Das Lastenheft wird zu Beginn des Projekts erstellt und hat keinen konzeptionellen Fokus. Es enthält hauptsächlich Wünsche und Anforderungen des Kunden, ohne auf die Umsetzung einzugehen. Für den Kunden ist das Lastenheft eine Zieldefinition, für den ERP-Anbieter ein Briefing-Dokument.

Das Pflichtenheft wird zu Beginn der Implementierungsphase erstellt. Es enthält eine detaillierte Lösungsbeschreibung und fest definierte Soll-Zustände, auf die sich beide Seiten geeinigt haben. Es hat einen praxisorientierteren Fokus als das Lastenheft. Aus Sicht des Kunden dokumentiert das Pflichtenheft, welche Funktionen und Eigenschaften das fertige Produkt mitbringen muss. Für den Anbieter beschreibt das Lastenheft dagegen die Leistungen, die er im Rahmen des abgeschlossenen Vertrags erbringen muss.

Lastenheft	Pflichtenheft
Wird vom Kunden erstellt Beschreibt Wünsche und Anforderungen des Auftraggebers Lösungsneutral Hauptsächlich für die Systemauswahl relevant Rechtlich nicht bindend	Wird vom Anbieter erstellt Enthält Ziele und Lösungsbeschreibungen Nur für Implementierung und Abnahme relevant Rechtlich bindend

Es ist wichtig, die Unterschiede zwischen beiden Dokumenten zu kennen. Aus rechtlicher Sicht macht es zum Beispiel einen großen Unterschied, ob etwas im Lastenheft oder im Pflichtenheft festgehalten wurde. Daher sollten Sie darauf achten, die Begriffe nicht synonym zu verwenden. Sonst provozieren Sie nur Missverständnisse.

Wenn Sie mehr über das Lastenheft und seinen Aufbau erfahren möchten, empfehlen wir Ihnen unser Whitepaper „Der richtige Weg zum ERP-Lastenheft“. Es erklärt genau, worauf Sie bei der Erstellung des Dokuments achten sollten.

Ein Lastenheft erstellen ist keine Hexerei. wir haben hier für Dich alles Wichtige zusammengetragen und wie folgt gegliedert:

1. Was ist ein Lastenheft?

Das Lastenheft (Leistungsverzeichnis, Statement of Work, Anforderungen) ist ein wichtiges Dokument im klassischen Projektmanagement. Es beschreibt die Anforderungen des Auftraggebers an die im Rahmen eines Projekts zu erbringenden Leistungen. Das Lastenheft erstellen ist üblicherweise Aufgabe des Auftraggebers. Es dient als Spezifikation und Grundlage für Angebotsanfragen und Ausschreibungen.

Nach Erhalt des Lastenhefts setzt ein potentieller Auftragnehmer die zu erbringenden Ergebnisse (Lasten) in erforderliche Tätigkeiten (Pflichten) um und erstellt das sogenannte Pflichtenheft. Dieses ist Teil des Angebots an den Auftraggeber. Im einfachsten Fall besteht das Pflichtenheft aus einem Verweis auf das Lastenheft sowie einem Termin und einem Preis.

Lasten- und Pflichtenheft sollten Bestandteil des Vertrags zwischen Auftraggeber und Auftragnehmer sein. Sie sollten vor Projektbeginn erstellt werden, wozu bei größeren Vorhaben ein eigenes Projekt erforderlich sein kann.

2. Wie ist ein Lastenheft aufgebaut?

In Anlehnung an das V-Modell XT sollte ein Lastenheft wie folgt strukturiert sein:

Im folgenden gehen wir der Reihenfolge nach die einzelnen Abschnitte durch. Für den schnellen Start haben wir eine Lastenheft-Vorlage erstellt.

Einleitung

In der Einleitung beschreiben wir übersichtsmäßig die Motivation für das Projekt und geben eine knappe Übersicht über den erwarteten Nutzen.

Ausgangssituation und Zielsetzung

Im zweiten Abschnitt werden beim Lastenheft erstellen die Ausgangssituation und der Anlass zur Durchführung des Projektes anschaulich dargestellt. Der Nutzen bzw. Mehrwert gegenüber existierenden Lösungen und damit die Motivation für die Durchführung des Projekts wird hier allgemein verständlich beschrieben.

Es werden zusätzlich alle relevanten Stakeholder des Projektes benannt und die technische und fachliche Einbettung des zu entwickelnden Systems in seine Umgebung skizziert. Damit wird auch die Systemgrenze definiert und die Schnittstellen zu anderen Systemen werden aufgezeigt. Für die Entwicklung werden erste Rahmenbedingungen identifiziert und beschrieben wie z. B. technische Vorgaben oder Vorgaben zur Sicherheit.

Funktionale Anforderungen

Die funktionalen Anforderungen beschreiben die Fähigkeiten des Systems, mit deren Hilfe ein Anwender ein fachliches Problem lösen kann. Die Anforderungen werden beim Lastenheft erstellen aus den zu unterstützenden Geschäftsprozessen und den Ablaufbeschreibungen zur Nutzung des Systems abgeleitet.

Es gibt viele Methoden zur Darstellung funktionaler Anforderungen. Beispiele sind

Anwendungsfälle (Use Cases). Diese sind für sich alleine oft zu grob, um daraus konkretes Verhalten ableiten zu können und werden deshalb gerne mit anderen Modellierungsformen kombiniert.
Goal-Scenario mit Betonung auf Scenario. Das gewünschte Verhalten wird in Szenarien beschrieben. Diese Methode eignet sich besonders für Systeme, die einen großen Teil ihrer Funktionalität an der Bedienschnittstelle exponieren.
Blockschaltbilder eignen sich gut für technische Systeme und Steuerungen.
Datenmodelle sind hilfreich bei datenzentrierten Systemen. Ein Datenmodell dient als Grundlage für den späteren Datenbankentwurf.

Die funktionalen Anforderungen sind die zentralen Vorgaben für die Systementwicklung. Sie werden in das Pflichtenheft übernommen und bei Bedarf konkretisiert.

Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen sind Anforderungen an das System, die zwar zur Anwendbarkeit des Systems beitragen, aber nicht-fachlicher Natur sind. Dazu gehören z.B. Anforderungen an die Benutzbarkeit, die Performance oder die Skalierbarkeit des Systems.

Die durch nicht-funktionale Anforderungen definierten Eigenschaften eines Systems müssen schon in der Entwurfsphase berücksichtigt werden und tragen häufig zu den Entwicklungskosten bei. Anforderungen, die nicht eindeutig zu den funktionalen Anforderungen gehören, werden den nicht-funktionalen Anforderungen zugeordnet.

Gesamtsystem-Architektur

Es ist praktisch unmöglich, Anwenderanforderungen allein im . Problemraum ohne Betrachtung des Lösungsraums zu definieren. Es ist deshalb sinnvoll, schon mit der Erstellung des Lastenhefts eine Gesamtsystemarchitektur aus Anwendersicht zu skizzieren. Diese funktionale Systemarchitektur legt auch die Schnittstellen zu eventuellen benachbarten Systemen fest.

Ist der Einsatz von Fertigprodukten geplant, sollten diese in der in der Gesamtsystemarchitektur identifiziert und festgeschrieben werden. Zur Systemarchitektur gehört im weiteren eine Beschreibung der Einsatzumgebung und ggfs. die Festlegung von Sicherheitsanforderungen.

Anforderungen an die Funktionssicherheit

Geht es im Lastenheft um sicherheitskritische Systeme, werden in diesem Abschnitt Vorgaben für die Behandlung der Funktionssicherheit definiert. Die im Rahmen des Systembetriebs bestehenden Risiken werden aufgezeigt, nach Schadenshöhe klassifiziert sowie mit einer geschätzten Eintrittswahrscheinlichkeit versehen. Für jeden identifizierten Schadensfall ist z.B. in einer Form einer Risiko-Akzeptanzmatrix anzugeben, für welche Schadensklasse und welche Eintrittswahrscheinlichkeit welche Risikoklasse toleriert wird.

Lieferumfang

In diesem Abschnitt sind beim Lastenheft erstellen alle Gegenstände und Dienstleistungen aufzulisten, die im Projektverlauf oder zum Abschluss durch den Auftragnehmer zu liefern sind. Der Lieferumfang kann ein ganzes System, Teile davon, Dokumente und Dienstleistungen enthalten.

Abnahmekriterien und Vorgehen zur Abnahmeprüfung

Durch Abnahmekriterien wird festgelegt, welche Eigenschaften und welches Verhalten eine Lieferung erfüllen muss, damit sie den Anforderungen genügt. Die Kriterien sollten messbar dargestellt werden und können nach Ausgangssituation, Aktion(en) und erwartetem Ergebnis strukturiert werden. Abnahmekriterien können sich sowohl auf einzelne Anforderungen („Unter welchen Bedingungen gilt die Anforderung als erfüllt?“) als auch auf den Lieferumfang („Welche Bedingungen müssen erfüllt sein, damit eine konkrete Lieferung abgenommen wird?“) beziehen. Die Abnahmekriterien sind Basis der Abnahmeprüfung.

Es bietet sich an, Abnahmekriterien in Form von konkreten Abnahmeszenarien zu beschreiben, die das System bei der Lieferung durchlaufen muss.

Die Abnahmekriterien können nach der Auftragsvergabe weiter detailliert werden; dadurch können auch die Anforderungen präzisiert werden. Die erwarteten Ergebnisse der Abnahme und das Vorgehen bei der Abnahmeprüfung für jede Lieferung sollte auf jeden Fall schon vor der Abnahme detailliert festgelegt und zwischen Auftraggeber und Auftragnehmer abgestimmt werden.

3. Worauf ist beim Erstellen eines Lastenhefts zu achten?

Detaillierungsgrad

Den „richtigen“ Detaillierungsgrad gibt es leider nicht. Ist das Dokument oberflächlich und vage, ist die Gefahr groß, dass das gelieferte Produkt nicht den Vorstellungen des Auftraggebers entspricht und es kommt nicht selten zu Nachforderungen oder Rechtsstreitigkeiten. Eine sehr detaillierte Spezifikation auf der anderen Seite kann den Lösungsraum unnötig einschränken und damit innovationshemmend sein. Es kostet u.U auch sehr viel Zeit, ein belastbares Lastenheft auszuarbeiten.

Ein gutes Rezept für die Erarbeitung der „essentiellen“ Anforderungen für ein Lastenheft ist und bleibt die Systemanalyse, die auch im agilen Zeitalter nichts von ihrer Wirksamkeit verloren hat. Und es sind die essentiellen Anforderungen, um die es im Lastenheft vor allem geht.

Struktur und Inhalt

1	Kennzeichne die Anforderungen im Lastenheft eindeutig als solche und trenne sie von Kontextinformation.
2	Gib jeder Anforderung eine eindeutige Identifikation.
3	Formuliere verbindliche Anforderungen mit „muss“ .
4	Verwende im Lastenheft durchgängig dieselbe Benennung für dieselbe Sache, auch wenn sich die Bezeichnung häufig wiederholt.
5	Definiere von Beginn zu jeder Anforderung ein Abnahmekriterium bzw. eine Verifikationsmethode.
6	Bevorzuge Tabellen und grafische Darstellungen gegenüber Textbeschreibungen.
7	Formuliere in einem (Ab-)Satz genau eine Anforderung, nie mehrere.
8	Dokumentiere die Quelle einer Anforderung soweit sie bekannt ist bzw. verweise darauf.
9	Definiere potentiell mehrdeutige Begriffe und Benennungen in einem Glossar.
10	Verwende kein „/“ Zeichen oder „bzw.“, ohne eindeutig zu kennzeichnen, ob Du mit dem Schrägstrich „und“ oder „oder“ oder beides „und/oder“ meinst.

Lastenheft mit Stil

1	Verwende bewährte Satzbaumuster wie in den Beispielen weiter unten gezeigt.
2	Formuliere die Anforderungen in ganzen Sätzen und nicht stichwortartig.
3	Verwende Aktivsätze und vermeide Passivsätze
4	Bilde kurze Sätze und vermeide Verschachtelungen
5	Vermeide „Weak Words“ (aber, allzu, absolut, andere, äußerst, auch, entsprechend, siehe ausführlichere Liste unten)
6	Vermeide qualitative Adjektive wie z.B. langsam, schnell, schön, heiß, kalt, zyklisch, etc..

Satzbaumuster

Verwende bewährte Satzbaumuster wie z.B. dieses:

[Bedingung] „Wenn der Druck 1 Bar überschreitet,“
[Anforderungswort] „muss“
[Subjekt] „die Steuerung“
[Objekt] „das Entlastungsventil“
[Aktion] „öffnen“

Für die Formulierung im agilen Umfeld wird gerne das folgende Satzbaumuster verwendet:

[Als {Rolle}] Als administrativer Benutzer
[möchte ich {etwas tun}] möchte ich eine Spalte einer Excel-Tabelle importieren
[um zu {Ziel}] um damit eine Auswahlliste zu füllen

Vermeide „Weak Words“

Die Verwendung von Wörtern aus der folgenden Liste deutet auf unscharfe Vorstellungen hinsichtlich der Anforderungen hin. Wenn Du ein Lastenheft erstellst, dürfen diese Ausdrücke nicht in einem fertigen Teil von Anforderungstexten auftreten (nach Dreher, Marion).

A	ab, aber, absolut, ähnlich, aktuell, allenfalls, allerdings, allzu, als ob, andere, andernfalls, anders, anhaltend, annähernd, anscheinend, ansonsten, auf keinen Fall, augenscheinlich, ausführlich, ausnahms- weise, außerordentlich, äußerst
B	bald, bedienbar, bedingt, bei, beinahe, besonders, besser, beste, bestimmt, bestmöglich, bisweilen
C	ca.
D	damals, daneben, dann, demnächst, denkbar, denn, dereinst, deutlich, dicht, doch, durchaus
E	eben, ehedem, ehemals, eher, eigentlich, eilends, ein bisschen, ein paar, ein wenig, eindeutig, eine Weile, einfach, einige, einigerma- ßen, einmal, einst, einstmals, einzeln, elementar, eng, enorm, ent- sprechend, erstaunlich, etliche, etwa, etwa wie, etwas, etwelche, eventuell
F	fabelhaft, fast, fortschrittlich, für den Fall, furchtbar
G	gängig, ganz, gar, gebräuchlich, gegebenenfalls, gegen, genau, genug, gerade so, gering, gesamt, gewaltig, gewisse gewohnt, gleich- zeitig, groß, größtenteils, gründlich, gut
H	halbwegs, halbwegs, halt, häufig, hauptsächlich, hin und wieder, höchst, höchstens, höchstwahrscheinlich, hoffentlich
I	intuitiv, inzwischen, irgend, irgendetwas, irgendwelche, irgendwer, irgendwie, irgendwo, irgendwoher, irgendwohin
J	ja, je nachdem, jemand
K	kaum, klassisch, klein, knapp, kolossal, kurz, kürzlich
L	landläufig, lang, langsam, längst, laut, leicht, leise, letztens
M	mal, man, manche, manchmal, mäßig, mehr, mehr oder minder, mehrere, mehrfach, mehrmals, meist, meistens, minder, mitunter, modern, möglich, möglicherweise, möglichst
N	nach Möglichkeit, nahezu, nebenbei, neuartig, neulich, niemals, nur, offensichtlich, oft, öfter, öfters, optimal
P	pauschal, phantastisch, plausibel, prinzipiell
Q	quasi
R	regelmäßig, reichlich, riesig, rund (abschätzend, wie ca.)
S	schätzungsweise, scheinbar, schlecht, schnell, schon, schön, schrecklich, schwer, schwerlich, sehr, selbsterklärend, selten, sicher, sicherlich, so, sogar, solche, soll, sollte, somit, sonstige, sorgfältig, sozusagen, speziell, stark
T	teils, teilweise, u. a.
U	u. U., überaus, überhaupt, üblich, übrige, umgehend, unbedingt, unbeträchtlich, und, und wann, ungefähr, ungemein, ungewöhnlich, ungezählt, unlängst, unmerklich, unter Umständen, unterdessen, etc.
V	verblüffend, vereinzelt, vermutlich, verschieden, verständlich, viel, vielfach, vielleicht, vielmal, vollendet, vollkommen, vorerst, vorhin
W	wahnsinnig, wahrscheinlich, weit, weitaus, weitem, weitere, wenig, wesentlich, wie wenn, winzig, wirklich, wohl, womöglich, Wunders wie
Z	z. T., zahllos, zahlreich, zeitgemäß, zeitweise, ziemlich, zirka, zu, zu meist, zudem, zugleich, zunächst, zuweilen, zyklisch

4. Lastenheft und PM-Standards

Die DIN 69901-5:2009-1 „Projektmanagement – Projektmanagementsysteme – Teil 5: Begriffe“ definiert den Begriff Lastenheft im obigen Sinne. Der PMBOK(R) Guide 2008 fasst das Statement Of Work (SOW) etwas enger. Das SOW ist dort als Beschreibung der zu erbringenden Dienstleistungen oder Werke definiert. Dies umfasst lediglich die Spezifikation des Produkts oder der Dienstleistung.

Die ICB 3.0 verzichtet auf die explizite Benennung eines Lastenhefts. Statt dessen spricht sie lediglich von „project scope“ und „deliverables“. In der deutschen Competence Baseline NCB 3.0 wird ergänzend zumindest das Begriffspaar „Lastenheft/Pflichtenheft bei der technischen Kompetenz „Leistungsumfang und Lieferobjekte“ benannt.

PRINCE2 verzichtet völlig auf die Systematik von Lastenheft und Pflichtenheft, da es die Beschaffungsprozesse nicht beschreibt. Inhaltlich treten stattdessen bei PRINCE2 für das Gesamtprojekt das Projektmandat und die Beschreibung des Projektprodukts ein. Anstelle von Lastenheften, die im Rahmen des Projekts zu erstellen sind, treten bei PRINCE2 der Produktstrukturplan und die Produktbeschreibungen sowie die Managementstrategien.

5. Lastenheft Beispiel

Das Lastenheft erstellen kannst Du stark beschleunigen. Hier kannst du eine Lastenheft-Vorlage herunterladen. Die Vorlagen gibt es im Microsoft Word-Format sowie für die Allegra Projektmanagement-Software.