MES Lastenheft und Pflichtenheft: Aufbau und Checkliste

Was sind Lastenheft und Pflichtenheft im MES-Projekt?

Das Lastenheft dokumentiert, was der Kunde braucht: Ziele, Anforderungen, Prioritäten und Abnahmekriterien. Es beschreibt das "Was" und das "Warum" aus Sicht des produzierenden Unternehmens. Das Pflichtenheft dokumentiert, wie der Anbieter liefert: Architektur, Datenflüsse, Schnittstellen, Umsetzung und Betriebskonzept. Es beschreibt das "Wie" und das "Womit" aus Sicht des MES-Anbieters.

Die Verwechslung der beiden Dokumente ist die häufigste Ursache für gescheiterte MES-Projekte. Wenn der Kunde ein Lastenheft schreibt, das bereits Lösungen vorgibt, schränkt er die Anbieterauswahl unnötig ein. Wenn der Anbieter ein Pflichtenheft schreibt, das die Anforderungen des Kunden nicht vollständig abdeckt, entstehen Scope-Creep, Nachtragsangebote und Projektverzögerungen.

Der Merksatz: Das Lastenheft macht Anbieter vergleichbar. Das Pflichtenheft macht die Lieferung prüfbar.

Lastenheft vs. Pflichtenheft: Die Unterschiede

Aufbau eines MES-Lastenhefts: Die 9 Bereiche

Ein vollständiges Lastenheft für ein MES-Projekt umfasst neun Bereiche. Jeder Bereich muss so formuliert sein, dass zwei verschiedene Anbieter daraus vergleichbare Angebote erstellen können.

Die 6 Bereiche, die hart spezifiziert werden müssen

Aus der Erfahrung mit hunderten MES-Projekten: Die folgenden 6 Bereiche sind die häufigsten Ursachen für Projektverzögerungen und Nachtragsangebote, wenn sie im Lastenheft oder Pflichtenheft nicht präzise genug definiert sind.

Lastenheft vs. Proof of Concept: Ein alternativer Ansatz

Das klassische Lastenheft/Pflichtenheft-Vorgehen folgt einem Wasserfall-Modell: Erst alle Anforderungen spezifizieren, dann Anbieter auswählen, dann umsetzen, dann abnahmen. In der Praxis dauert allein das Schreiben des Lastenhefts oft 3-6 Monate. Änderungen im Pflichtenheft kommen on top.

Ein alternativer Ansatz, der sich besonders bei Cloud-MES-Systemen mit modularem Baukasten bewährt hat: Der Proof of Concept (PoC) ersetzt nicht das Lastenheft, aber er verkürzt es radikal.

SYMESTIC unterstützt beide Ansätze. Kunden wie Neoperl sind mit einem 4-wöchigen PoC an einer Anlage gestartet, haben die Ergebnisse validiert und dann schrittweise skaliert. Kunden wie Carcoustics haben einen strukturierten Evaluierungsprozess durchlaufen, dann einen PoC im Werk Haldensleben gemacht und anschließend auf 500+ Anlagen in allen Werken skaliert. Der modulare Baukasten ermöglicht eigenständige Skalierung durch den Kunden, ohne dass für jede Erweiterung ein neues Pflichtenheft geschrieben werden muss.

OEE-Definition im Lastenheft: Warum das der kritischste Punkt ist

Die OEE-Definition ist der Bereich, der in Lastenheften am häufigsten unterschätzt wird. "OEE soll berechnet werden" steht in fast jedem MES-Lastenheft. Aber was genau berechnet werden soll, ist fast nie definiert. Die Folge: Nach Go-Live stimmen die OEE-Werte des MES nicht mit den bisherigen Excel-Werten überein, und das gesamte Projekt verliert Glaubwürdigkeit.

Die folgenden Punkte müssen im Lastenheft definiert sein:

Schnittstellenspezifikation: Was im Lastenheft stehen muss

Schnittstellen sind der teuerste und am häufigsten unterschätzte Teil eines MES-Projekts. Im Lastenheft müssen Schnittstellen fachlich beschrieben werden, nicht technisch. Die technische Umsetzung gehört ins Pflichtenheft.

SYMESTIC bietet für jede dieser Schnittstellen dokumentierte Standardlösungen: Bidirektionale ERP-Anbindung an SAP (über ABAP IDoc bei Meleghy und Carcoustics), Navision (über Dateischnittstelle bei Klocke) und InforCOM (bei Schmiedetechnik Plettenberg). OPC-UA Cloud Connector für moderne Steuerungen. Digitale I/O-Gateways für Bestandsanlagen ohne digitale Schnittstelle. REST-API für Drittsysteme und BI. Bidirektionale QA-Anbindung (z. B. CASQ-it bei Meleghy).

Typische Fehler bei Lastenheft und Pflichtenheft

Fehler 1: Das Lastenheft beschreibt Lösungen statt Probleme. "Das System muss SAP über IDoc anbinden" ist kein Anforderung, sondern eine Lösungsvorgabe. Die Anforderung ist: "Fertigungsaufträge aus dem ERP müssen automatisch im MES verfügbar sein." Wie das technisch umgesetzt wird (IDoc, REST, Dateischnittstelle), gehört ins Pflichtenheft.

Fehler 2: OEE wird nicht definiert. "OEE soll berechnet werden" steht in jedem Lastenheft. Aber ohne Definition von Planned Production Time, Stillstandslogik, Mikrostopps-Schwelle und Störgrundkatalog ist die OEE-Berechnung nicht reproduzierbar. Nach Go-Live stimmen die Werte nicht mit den bisherigen Excel-Werten überein, und das Projekt verliert Glaubwürdigkeit.

Fehler 3: Schnittstellen werden unterschätzt. "ERP-Schnittstelle ist enthalten" steht im Angebot. Aber niemand hat definiert, welche Daten in welche Richtung fließen, wie Fehlerfälle behandelt werden und wer die Schnittstelle testet. Die Schnittstellenkosten sind in MES-Projekten regelmäßig der größte Nachtrag.

Fehler 4: Das Lastenheft wird dem Anbieter überlassen. Wenn der MES-Anbieter das Lastenheft schreibt, schreibt er seine eigene Lösung als Anforderung. Das Ergebnis: Nur dieser Anbieter kann liefern. Die Vergleichsbasis geht verloren. Das Lastenheft ist die Stimme des Kunden, nicht die des Anbieters.

Fehler 5: Kein Change-Control-Verfahren. Anforderungen ändern sich im Projektverlauf. Das ist normal. Aber ohne formales Verfahren, das Änderungen dokumentiert, bewertet und freigibt, driften Lastenheft und Pflichtenheft auseinander. Das Ergebnis: Scope-Creep, Nachtragsangebote und die Frage "War das in der Anforderung?" bei jeder Abnahme.

Häufige Fragen zum MES-Lastenheft

Wer schreibt das Lastenheft?

Das Lastenheft liegt in der Verantwortung des Kunden. Es dokumentiert die eigenen Anforderungen und Ziele. In der Praxis unterstützen erfahrene MES-Anbieter bei der Strukturierung, aber der Inhalt muss vom Kunden kommen. Wer das Lastenheft komplett dem Anbieter überlässt, verliert die Vergleichsbasis zwischen mehreren Anbietern.

Wie detailliert muss ein MES-Lastenheft sein?

Detailliert genug, dass zwei verschiedene Anbieter daraus vergleichbare Angebote erstellen können. Und detailliert genug, dass Abnahmetests daraus abgeleitet werden können. Use-Cases als Szenarien sind oft hilfreicher als Feature-Listen. Überspezifikation kostet Zeit ohne Mehrwert. Unterspezifikation kostet Geld nach Vertragsschluss.

Muss ein Pflichtenheft vor Vertragsschluss vorliegen?

Nicht zwingend vollständig, aber die kritischen Bereiche (Schnittstellendesign, Datenmodell, OEE-Definitionen) sollten vor Vertragsschluss zumindest skizziert sein. Was nach Vertragsschluss ungeklärt ist, wird teuer. Eine Minimalanforderung: Die 6 "harten" Bereiche (Schnittstellen, Datenmodell, OEE, Traceability, Rollen, Reporting) sollten als Anlage zum Vertrag definiert sein.

Kann ein PoC das Lastenheft ersetzen?

Nicht vollständig, aber er kann es radikal verkürzen. Ein PoC validiert die Kernfunktionalität an einer realen Linie: Maschinenanbindung, Datenerfassung, OEE-Berechnung, Stillstandsklassifizierung. Die Erkenntnisse aus dem PoC fließen in ein deutlich präziseres und kürzeres Lastenheft ein. Statt 100 Seiten theoretischer Anforderungen entstehen 20 Seiten validierter Anforderungen.

Was passiert, wenn Lastenheft und Pflichtenheft im Projekt auseinanderdriften?

Das ist die häufigste Ursache für Scope-Creep, Nachtragsangebote und Projektverzögerungen. Ein formales Change-Control-Verfahren, das Anforderungsänderungen dokumentiert, bewertet (Aufwand, Kosten, Zeitplan) und freigibt, schützt beide Seiten. Ohne Change-Control endet jede Diskussion mit "War das in der Anforderung?"

Über den Autor:

Christian Fieg

Head of Sales bei SYMESTIC. Zuvor iTAC, Dürr, Visteon, Johnson Controls. Six Sigma Black Belt. Autor von "OEE: Eine Zahl, viele Lügen".
LinkedIn