Lastenheft und Pflichtenheft beschreiben zwei unterschiedliche Dokumente im MES-Projekt – sie werden oft verwechselt, erfüllen aber grundverschiedene Funktionen.
Das Lastenheft dokumentiert, was gebraucht wird: Ziele, Anforderungen, Prioritäten und Abnahmekriterien aus Kundensicht. Das Pflichtenheft dokumentiert, wie der Anbieter liefert: Architektur, Datenflüsse, Schnittstellen, Umsetzung und Betriebskonzept.
Der Merksatz: Das Lastenheft macht Anbieter vergleichbar. Das Pflichtenheft macht die Lieferung prüfbar.
Struktur: MES-Lastenheft
Ein vollständiges Lastenheft für ein MES-Projekt umfasst neun Bereiche.
Ziele und Scope klärt: Warum MES, welche Werke und Linien sind betroffen, was ist explizit nicht im Scope.
Prozesse als Use-Cases beschreibt kurze Szenarien statt Feature-Listen: Auftrag starten, Rüsten, Produktion, Störung, Qualität, Schichtabschluss.
Anforderungen werden in Muss, Soll und Kann gegliedert – mit testbar formulierten Akzeptanzkriterien.
Daten und Stammdaten definiert grob welche Objekte existieren müssen: Auftrag, Linie, Maschine, Artikel, Material, Charge, Prüfungen – und welche Beziehungen zwingend sind.
Schnittstellen beschreibt fachlich welche Daten zwischen ERP, QA, LIMS, SCADA, PLC und BI fließen – mit Frequenz und Verantwortlichkeit.
Rollen und Nachvollziehbarkeit legt Rollenmatrix, Freigaben, Änderungsgründe und Audit-Trail-Bedarf fest.
Reporting und KPIs definiert OEE-Definitionen, Standardreports, Drilldowns und BI-Anbindung.
Nichtfunktionales und Betrieb umfasst Performance, Verfügbarkeit, Offline-Fähigkeit, Security, Backup und Update-Prozess.
Projekt und Abnahme enthält Pilot- und Rollout-Plan, Schulung, Abnahmetests und Dokumentationsumfang.
Struktur: MES-Pflichtenheft
Das Pflichtenheft ist die Antwort des Anbieters auf das Lastenheft. Es enthält Zielarchitektur mit Komponenten, Deployments, Datenflüssen und Source-of-Truth-Definition, Umsetzung je Use-Case mit Screens, Workflows, Regeln und Fehlerfällen, detailliertes Datenmodell mit IDs, Versionen, Historie und Zeitlogik, Schnittstellendesign mit Mapping, Trigger, Error-Handling und Monitoring, Rollen- und Rechtekonzept, KPI-Logik und Reporting sowie Test-, Abnahme- und Betriebskonzept.
Die 6 Bereiche die hart spezifiziert werden müssen
Schnittstellen werden je Datendomäne definiert: Quelle, Ziel, Richtung, Timing und Fehlerfälle. ERP zu MES für Artikel, Aufträge und Rückmeldungen. PLC/SCADA zu MES für Zustände, Zähler und Alarme. QA/LIMS zu MES für Prüfpläne, Ergebnisse und Freigaben. Und BI für Export, Historisierung und Rechte.
Datenmodell und Stammdaten – hier sterben Projekte wenn es schwammig bleibt. Pflichtobjekte, eindeutige IDs, Versionierung für Rezepte und Arbeitspläne, Einheiten und Zeitlogik müssen früh entschieden sein.
OEE-Definitionen müssen schriftlich fixiert sein: Formel, Planned Time, Stillstandlogik, Mikrostopps, geplante Stillstände und Störgrundkatalog mit Pflichtlogik. Wer OEE nicht definiert, diskutiert Monate über Zahlen statt Ursachen.
Traceability klärt Granularität – Auftrag, Los, Batch oder Seriennummer – und welche Ereignisse rückwärts und vorwärts verfolgbar sein müssen: Materialcharge, Auftrag, Produkt, Prüfungen.
Rollen, Freigaben und Nachvollziehbarkeit definiert wer was darf, in welcher Reihenfolge und mit welchen Sperrregeln – und wie Änderungen an Stammdaten, Kategorien und Rezepten dokumentiert werden.
Reporting ist nicht „Dashboard hübsch", sondern Definition plus Drilldown: Standard-KPIs mit einheitlicher Definition, Drilldown-Pfade von Werk über Linie bis Ereignis, Export-Datenmodell und Historisierung.
FAQ
Wer schreibt das Lastenheft – Kunde oder Anbieter? 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.
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.
Wie detailliert muss ein MES-Lastenheft sein? Detailliert genug dass zwei verschiedene Anbieter daraus vergleichbare Angebote erstellen können – und dass Abnahmetests daraus abgeleitet werden können. Use-Cases als Szenarien sind oft hilfreicher als reine Feature-Listen. Überspezifikation kostet Zeit ohne Mehrwert.
Was passiert wenn Lastenheft und Pflichtenheft im Projekt auseinanderdriften? Genau das ist die häufigste Ursache für Scope-Creep, Nachtragsangebote und Projektverzögerungen. Ein formales Change-Control-Verfahren das Anforderungsänderungen dokumentiert und bewertet schützt beide Seiten.
