Anforderungen

Mit der Ist-Analyse, den Projektzielen, der Wirtschaftlichkeitsbetrachtung, dem Zielbild und den Einführungsstufen ist die fachliche Grundlage geschaffen. Jetzt muss daraus ein Dokument entstehen, mit dem geeignete MES-Anbieter vergleichbar angefragt, Lösungen bewertet und Leistungen später verbindlich beauftragt werden können.

Genau an diesem Punkt entscheidet sich die Qualität der späteren Softwareauswahl. Unklare Anforderungen führen zu Rückfragen, unterschiedlichen Interpretationen und Angeboten, die nur scheinbar vergleichbar sind. Zu detaillierte technische Vorgaben können dagegen sinnvolle Lösungswege ausschließen und den Wettbewerb unnötig einschränken.

Was eine Anforderung leisten muss

Eine Anforderung beschreibt einen benötigten Zustand, eine Funktion, eine Leistung oder eine Rahmenbedingung. Sie muss so formuliert sein, dass drei Beteiligte dasselbe darunter verstehen:

• der Fachbereich, der den Bedarf hat,
• der Anbieter, der eine Lösung anbietet,
• das Projektteam, das die Erfüllung später bewertet und abnimmt.

Eine gute Anforderung ist deshalb:

• eindeutig: Sie lässt möglichst wenig Interpretationsspielraum.
• vollständig: Die wesentlichen Bedingungen und Ergebnisse sind beschrieben.
• lösungsneutral: Sie beschreibt den Bedarf, nicht vorschnell eine konkrete technische Umsetzung.
• prüfbar: Es ist erkennbar, wie die Erfüllung nachgewiesen werden kann.
• nachvollziehbar: Der Bezug zu Prozess, Ziel oder Problem ist erkennbar.
• abgrenzbar: Sie enthält möglichst nur einen klaren Sachverhalt.
• priorisierbar: Bedeutung und Einführungsstufe können zugeordnet werden.

Anforderungen aus dem bisherigen Projektverlauf ableiten

Anforderungen dürfen nicht losgelöst in einem Workshop gesammelt werden. Ihre Quellen liegen bereits in den vorherigen Arbeitsschritten. Jede Anforderung sollte sich mindestens einer fachlichen Grundlage zuordnen lassen.

Diese Rückverfolgbarkeit verhindert Wunschlisten ohne Projektbezug. Sie hilft außerdem, Anforderungen zu streichen, die keinen Beitrag zu den Zielen leisten oder nur persönliche Vorlieben einzelner Beteiligter abbilden.

Funktionale und nicht-funktionale Anforderungen unterscheiden

Funktionale Anforderungen beschreiben, was das System fachlich tun muss. Nicht-funktionale Anforderungen beschreiben, wie gut, unter welchen Bedingungen und in welcher Umgebung es diese Aufgaben erfüllen muss.

Ein Lastenheft, das nur Funktionslisten enthält, bleibt unvollständig. Eine Software kann fachlich alle Häkchen erfüllen und dennoch ungeeignet sein, weil Bedienbarkeit, Antwortzeiten, Rollenmodell, Verfügbarkeit oder Integrationsfähigkeit nicht passen.

Die passende Struktur einer einzelnen Anforderung

Für jede Anforderung sollte eine einheitliche Struktur verwendet werden. Dadurch können Fachbereiche, Anbieter und Bewertungsteam effizienter arbeiten.

Nicht jede einfache Standardanforderung benötigt einen langen Beschreibungstext. Die Struktur muss jedoch immer so vollständig sein, dass die Anforderung verstanden, beantwortet und geprüft werden kann.

Ein praxistaugliches Formulierungsmuster

Ein bewährter Aufbau lautet:

Beispiel:

Der Werker muss an einem stationären oder mobilen Terminal einen begonnenen Arbeitsgang unterbrechen und einen vorgegebenen Unterbrechungsgrund auswählen können. Beginn, Ende, Dauer, Auftrag, Arbeitsgang, Arbeitsplatz und angemeldete Person müssen gespeichert werden. Die Unterbrechung muss spätestens fünf Sekunden nach Bestätigung im Leitstand sichtbar sein.

Diese Formulierung beschreibt Rolle, Situation, Funktion, Datenumfang und Reaktionszeit. Sie bleibt dennoch lösungsneutral, weil weder Bildschirmaufbau noch Programmiersprache oder Datenbank vorgegeben werden.

User Stories sinnvoll einsetzen

User Stories können helfen, Anforderungen aus Sicht einer Rolle zu formulieren:

Beispiel: „Als Fertigungssteuerer möchte ich den aktuellen Fortschritt aller freigegebenen Aufträge sehen, damit ich Terminrisiken frühzeitig erkenne.“

Die User Story allein reicht für ein Lastenheft jedoch meist nicht aus. Begriffe wie „aktuell“, „Fortschritt“ oder „frühzeitig“ müssen konkretisiert werden. Ergänzende Akzeptanz- oder Prüfkriterien sind deshalb erforderlich.

• Welche Aufträge und Status werden angezeigt?
• Welche Mengen und Zeiten fließen in den Fortschritt ein?
• Wie häufig werden die Daten aktualisiert?
• Wie werden Terminrisiken gekennzeichnet?
• Welche Filter und Sichten benötigt die Rolle?

Lösungsneutral formulieren

Lösungsneutralität bedeutet nicht, Anforderungen ungenau zu formulieren. Sie bedeutet, das benötigte Ergebnis festzulegen, ohne einen unnötig engen technischen Weg vorzuschreiben.

Technische Vorgaben sind dann sinnvoll, wenn sie aus der Zielarchitektur, aus Sicherheitsanforderungen, vorhandenen Standards oder verbindlichen Rahmenbedingungen entstehen. Sie sollten nicht aus Gewohnheit oder persönlicher Präferenz übernommen werden.

Standardfunktionen und unternehmensspezifische Anforderungen trennen

Viele MES-Funktionen sind in ähnlicher Form bei zahlreichen Unternehmen erforderlich. Dazu gehören beispielsweise Auftragsanmeldung, Mengenrückmeldung, Störgrundauswahl, Maschinenzustände oder Prüfwerterfassung. Diese Standardfunktionen können mit bewährten Textbausteinen beschrieben werden.

Unternehmensspezifisch sind dagegen insbesondere:

• besondere Prozessvarianten und Ausnahmen,
• produktspezifische Rückverfolgbarkeit,
• individuelle Freigaben und Eskalationen,
• bestehende Maschinenprotokolle und Schnittstellen,
• unternehmensinterne Begriffe, Status und Rollen,
• regulatorische oder kundenspezifische Nachweise,
• Auswertungen, die konkrete Entscheidungen unterstützen.

Textbausteine beschleunigen die Erstellung, dürfen aber nicht ungeprüft übernommen werden. Jeder Baustein muss zum tatsächlichen Prozess, zum Zielbild und zur Einführungsstufe passen.

Anforderungen nach MES-Modulen gliedern

Eine modulbezogene Gliederung erleichtert die Bearbeitung und Anbieterantwort. Sie sollte der zuvor festgelegten Zielstruktur entsprechen.

Bereich Produktion

• BDE
• MDE
• Auftragsfeinplanung
• DNC / Einstelldaten
• Werkzeug- und Ressourcenmanagement
• Material- und Produktionslogistik / Intralogistik
• Energiemanagement
• Tracking & Tracing

Bereich Qualität / CAQ

• SPC / Fertigungsbegleitende Prüfung
• Wareneingangsprüfung
• Warenausgangsprüfung
• Reklamationsmanagement
• Prüfmittelverwaltung
• PDV / Prozessdatenprüfung

Bereich Personal

• PZE
• PZW
• PEP
• Leistungslohn
• Zutrittskontrolle

Querschnittsthemen wie Benutzerverwaltung, Rollen, mobile Nutzung, Reporting, Archivierung, Schnittstellen, Betrieb und Informationssicherheit sollten nicht in einzelnen Modulen versteckt werden. Sie benötigen eigene Kapitel, weil sie mehrere oder alle Funktionsbereiche betreffen.

Prozessvarianten und Ausnahmen berücksichtigen

Eine Anforderung darf nicht nur den idealen Standardablauf beschreiben. In der Fertigung treten regelmäßig Ausnahmen auf. Gerade diese Fälle entscheiden darüber, ob ein System im Alltag funktioniert.

Typische Varianten sind:

• Auftrag wird unterbrochen und später fortgesetzt,
• mehrere Personen arbeiten gleichzeitig an einem Arbeitsgang,
• eine Person bedient mehrere Maschinen,
• Material wird ersetzt oder nachträglich umgebucht,
• Teilmenge wird gesperrt, nachgearbeitet oder verschrottet,
• Maschine fällt während eines laufenden Auftrags aus,
• Auftrag wird auf einen anderen Arbeitsplatz verlagert,
• Netzwerk oder Schnittstelle ist vorübergehend nicht verfügbar.

Für wichtige Prozessschritte sollte das Team deshalb systematisch fragen: Was passiert, wenn der Normalfall nicht eintritt? Wer entscheidet? Welche Daten müssen erhalten bleiben? Wie wird der Vorgang später nachvollzogen?

Datenanforderungen konkret beschreiben

MES-Projekte sind Datenprojekte. Anforderungen müssen deshalb nicht nur Funktionen, sondern auch die benötigten Datenobjekte und deren Qualität beschreiben.

Für jedes wesentliche Datenobjekt sind zu klären:

• welches System führend ist,
• welche Attribute benötigt werden,
• wie Identitäten und Schlüssel gebildet werden,
• wann und in welcher Richtung Daten übertragen werden,
• wie Änderungen und Löschungen behandelt werden,
• wie Fehler erkannt und nachbearbeitet werden,
• wie lange Daten aufbewahrt werden,
• wer für Inhalt und Qualität verantwortlich ist.

Schnittstellenanforderungen vollständig formulieren

Die Aussage „Schnittstelle zum ERP vorhanden“ genügt nicht. Eine Schnittstelle ist erst beschrieben, wenn Inhalt, Richtung, Zeitpunkt und Fehlerbehandlung geklärt sind.

Auch vorhandene Standardschnittstellen des Anbieters müssen inhaltlich geprüft werden. Eine technische Verbindung ist nicht automatisch eine fachlich vollständige Integration.

Nicht-funktionale Anforderungen konkretisieren

Nicht-funktionale Anforderungen sind häufig ausschlaggebend für Eignung, Kosten und Betrieb. Sie sollten mindestens folgende Bereiche abdecken:

Auch hier gilt: „Das System muss benutzerfreundlich sein“ ist keine prüfbare Anforderung. Besser ist beispielsweise: „Ein angelernter Werker muss nach höchstens 30 Minuten Einweisung Auftrag starten, Mengen melden, Unterbrechung buchen und Auftrag beenden können.“

Prüfkriterien direkt mitformulieren

Eine Anforderung ist erst belastbar, wenn erkennbar ist, wie ihre Erfüllung geprüft werden kann. Prüfkriterien helfen bereits bei der Anbieterpräsentation und werden später Grundlage für Test und Abnahme.

Prüfkriterien müssen realistisch sein. Sie sollten das benötigte Ergebnis absichern, ohne den späteren Test unnötig zu überfrachten.

Priorität und Einführungsstufe getrennt bewerten

Eine hohe fachliche Bedeutung bedeutet nicht automatisch, dass die Anforderung in der ersten Stufe umgesetzt werden muss. Priorität und Einführungszeitpunkt sind zwei unterschiedliche Merkmale.

Eine gesetzlich notwendige Archivierungsfunktion kann höchste Priorität besitzen, aber erst in einer späteren Stufe benötigt werden. Umgekehrt kann eine einfachere Funktion für den Start zwingend sein, obwohl sie strategisch weniger bedeutend ist.

Dublettten und Widersprüche vermeiden

Bei der Arbeit mit mehreren Fachbereichen entstehen schnell ähnliche oder widersprüchliche Anforderungen. Ein zentrales Redaktionsteam sollte deshalb alle Einträge konsolidieren.

Zu prüfen sind insbesondere:

• gleiche Funktion mit unterschiedlichen Begriffen,
• identische Anforderung in mehreren Modulen,
• widersprüchliche Zuständigkeit führender Systeme,
• unterschiedliche Zeit- oder Statusdefinitionen,
• lokale Sonderwünsche gegen vereinbarte Standards,
• technische Vorgaben, die dem Zielbild widersprechen.

Anforderungen fachlich freigeben

Jede Anforderung benötigt einen fachlich Verantwortlichen. Dieser bestätigt, dass die Beschreibung den tatsächlichen Bedarf abbildet und nicht nur eine unverbindliche Idee ist.

Ein sinnvoller Freigabeprozess umfasst:

1. Erstellung oder Übernahme eines Textbausteins,
2. fachliche Prüfung durch Prozesseigner und Key-User,
3. Prüfung auf Lösungsneutralität und Testbarkeit,
4. Abgleich mit Zielarchitektur und Einführungsstufe,
5. Konsolidierung von Dubletten und Widersprüchen,
6. Priorisierung und formale Freigabe.

Die Geschäftsführung muss nicht jede einzelne Detailanforderung prüfen. Sie sollte jedoch Umfang, Priorisierungslogik, Muss-Kriterien und wirtschaftliche Auswirkungen freigeben.

Was nicht in eine einzelne Anforderung gehört

Eine Anforderung sollte nicht mit langen Prozessbeschreibungen, Begründungen und technischen Konzepten überladen werden. Diese Inhalte sind wichtig, gehören aber in passende Dokumentteile.

Beispiel einer vollständig formulierten Anforderung

Das Musterwerk erstellt seine Anforderungen

Ergebnis dieses Arbeitsschrittes

Am Ende der Anforderungserstellung sollten mindestens folgende Ergebnisse vorliegen:

• eine einheitliche Anforderungsstruktur mit eindeutigen IDs,
• fachlich vollständige und lösungsneutrale Funktionsanforderungen,
• konkrete nicht-funktionale Anforderungen,
• beschriebene Datenobjekte und Schnittstellen,
• berücksichtigte Prozessvarianten und Ausnahmefälle,
• Prüfkriterien für wesentliche Anforderungen,
• fachliche Verantwortliche und freigegebene Formulierungen,
• Zuordnung zu Priorität und Einführungsstufe,
• ein abgestimmtes Glossar,
• eine konsolidierte und widerspruchsfreie Anforderungsliste.

Arbeitshilfe: Anforderungen prüfen

Übergang zum nächsten Kapitel

Die Anforderungen beschreiben, was die MES-Lösung leisten muss. Für eine belastbare Ausschreibung fehlen nun noch die quantitativen Rahmenbedingungen und eine nachvollziehbare Bewertungslogik. Das nächste Kapitel behandelt deshalb Mengengerüst und Gewichtung.