Autor: Stephan Schmitz, Koch und Lebensmitteltechnologe im KI-Management
Wie Food-KMU mit klaren Rollen, Entscheidungsrechten und gezielter Mitwirkung aus einem OEE-Problem ein belastbares KI-, Robotik- oder Automatisierungsprojekt machen. Eine entscheidende Frage, welche immer wieder in Erstgesprächen klar beantwortet wird, bevor Prozess-Struktur-Analysen starten und mögliche Pilotprojekte eingeordnet werden können.
Montagmorgen, 6:47 Uhr. Die Linie für TK-Fertiggerichte läuft. Also: theoretisch.
Der Traysealer meldet wieder Kurzstopps. Produktion vermutet schwankende Zuführung. Technik hat eine andere Theorie. QM verweist auf Ausschleusungen. Im Schichtbericht stehen drei Störgründe, im MES vier – und in der Excel-Datei des Produktionsleiters noch ein fünfter.
Die Geschäftsführung stellt schließlich die naheliegende Frage: „Was müssen wir tun, damit die OEE endlich steigt?“
Jetzt könnte man einen Sensoranbieter anrufen. Oder eine KI-Demo buchen. Vielleicht auf der nächsten Messe einen Roboter fotografieren, der Gurkengläser stapelt?! Kann man machen. Nur beginnt digitale Transformation damit oft am falschen Ende. Unsere Vorgehensweise setzt deshalb bewusst früher an. Ja, im Agile Role Mapping gilt auch unser Statement:
Erst Prozess verstehen. Dann Technologie entscheiden.
Die Prozess-Struktur-Matrix macht Engpässe und Optimierungshebel sichtbar. Die Pilot-Roadmap übersetzt einen priorisierten Use Case anschließend in Zielbild, KPIs, Rollen, Technologieoptionen, Wirtschaftlichkeit und einen konkreten Pilotstart. Dazwischen fehlt jedoch häufig eine entscheidende Frage:
Wer muss auf Kundenseite eigentlich was beitragen, damit aus Analyse tatsächlich Umsetzung wird?
Jetzt kommt Agile Role Mapping ins Spiel.
Ein Projekt mit vielen Beteiligten ist noch lange kein gut geführtes Projekt
Das Konzept Agile Role Mapping ist keine neue Stellenbeschreibung und kein Organigramm in hübscher Farbe.
Es ist eine steuerungsorientierte Rollenlandkarte. Für jedes relevante Arbeitspaket wird geklärt:
- Wer schuldet das Ergebnis?
- Wer entscheidet final?
- Wer liefert belastbaren Fachinput?
- Wer darf aus fachlichen Gründen stoppen?
- Und was passiert, wenn Daten, Freigaben oder Entscheidungen ausbleiben?
Damit geht das Modell über eine reine Zuordnung von „Responsible“, „Accountable“, „Consulted“ oder „Informed“ hinaus. Im FoodTechFuture-Leitfaden werden zusätzlich Gates, Termine, Entscheidungs- und Stopprechte sowie Eskalationen sichtbar gemacht.
Das klingt zunächst nach Projektmanagement. Ist aber in Wirklichkeit etwas viel Praktischeres:
Es verhindert, dass fünf Menschen über dieselbe Maschine diskutieren, obwohl eigentlich fünf unterschiedliche Entscheidungen getroffen werden müssen.
Projektziel: OEE von 62 auf mindestens 70 Prozent
Nehmen wir einen mittelständischen Convenience-Food-Hersteller mit einer Linie für tiefgekühlte Fertiggerichte, einer unserer Case Studies Anfang 2026. Betrachtet wurde der kritische Prozess vom Portionieren und Tray-Sealing über den Froster bis zur Sekundärverpackung.
Die vereinfachte Baseline lautete:
- Verfügbarkeit: 78 %
- Leistung: 85 %
- Qualitätsrate: 94 %
- daraus resultierende OEE*: rund 62 %
Das Projektziel: Die OEE der betrachteten Linie soll nachhaltig von rund 62 auf mindestens 70 % steigen – ohne Abstriche bei Produktsicherheit, Qualität und Arbeitssicherheit. Ein mögliches Zielbild könnte beispielsweise bei 83 % Verfügbarkeit, 90 % Leistung und 94,5 % Qualitätsrate liegen. Rechnerisch ergäbe das rund 70,6 % OEE. Diese Werte waren zunächst bewusst fiktive Projektannahmen, wie oft in Fachmagazinen von Tech-Anbietern angegeben. Solche Angaben sind oft vermeintliches Branchenbenchmark, aber nicht in jedem Fall im ersten Step ein Erfolg. Der entscheidende Punkt ist ohnehin ein anderer:
OEE* verbessert sich nicht, weil irgendwo ein Dashboard leuchtet.
* Gesamtanlageneffektivität (GAE) genannt – ist eine wichtige Kennzahl zur Messung der tatsächlichen Produktivität und Effizienz von Maschinen und Produktionsanlagen. Sie zeigt, wie nah eine Anlage am theoretischen Idealzustand (laufend 24/7 ohne Verluste) arbeitet. Formel: OEE=Verfügbarkeit×Leistung×Qualität
Die Prozess-Struktur-Matrix findet zuerst den echten Hebel
Bevor über KI, Robotik oder Automatisierung gesprochen wird, musste geklärt werden, wo der Verlust überhaupt entsteht.
Genau dafür nutzte FoodTechFuture die Prozess-Struktur-Matrix. Sie führt anhand von Interwiews und Fragebögen unterschiedliche Perspektiven aus Management, Produktion, Technik und Qualität zusammen und prüft diese gegen die tatsächliche Prozess- und Datenlage. Vielleicht zeigt sich dabei, dass die größten OEE-Verluste gar nicht im Traysealer entstehen.
- Verliert die Linie möglicherweise ihre Leistung durch Mikrostopps an der Zuführung?
- Vielleicht verlängern Produktwechsel die geplanten Stillstände, oder es werden Störungen unterschiedlich codiert?
- Hoppla, möglicherweise wartet die Linie regelmäßig auf Material – während das OEE-Meeting seit drei Monaten über Predictive Maintenance spricht?!
Unsere Vorgehensweise der Prozess-Struktur-Matrix beantwortet zunächst:
Wo lohnt es sich überhaupt, tiefer einzusteigen?
An dieser Stelle beginnt die Mitwirkung des Auftraggebers, ohne wenn und aber. Kein externer Berater kann wissen, warum Schicht B bei Produktwechseln anders arbeitet als Schicht A. Zudem kennt er nicht die historisch gewachsenen Workarounds, die nirgendwo dokumentiert sind, woher auch?
Dafür braucht es Menschen aus dem Betrieb!
Keine interne Projektarmee. Aber eben auch kein:„Hier sind unsere Hallenschlüssel. Ruft uns an, wenn die Transformation fertig ist.“
Agile Role Mapping klärt: Wer liefert – wer entscheidet – wer darf stoppen?
Für unser OEE-Projekt könnte die Rollenlogik so definiert worden sein.
Sponsor / Decision Owner – Geschäftsführung oder Werkleitung
Diese Rolle gibt Projektauftrag, Budget oder Pilot frei und entscheidet bei Zielkonflikten. Sie muss nicht selbst Stillstandsursachen analysieren. Aber sie muss kurzfristig erreichbar sein, wenn eine Entscheidung fällig ist.
Mitwirkung des KMU: Mandat, Budgetentscheidung und Eskalationsweg sicherstellen.
Process Owner – Produktionsleitung
Sie liefert Prozessgrenzen, Baseline, Sollzustand und Prozesswissen. Gerade bei OEE ist das entscheidend: Wer nicht dieselbe Prozessgrenze und dieselbe Zeitbasis verwendet, kann mit drei Dashboards zu vier unterschiedlichen Wahrheiten kommen.
Mitwirkung des KMU: Prozessdaten bereitstellen, Zielzustand definieren und Ergebnisse fachlich validieren.
Gatekeeper – QM, Arbeitssicherheit, Technik oder IT/OT
Gatekeeper besitzen für ihren definierten Prüfbereich ein echtes Stopprecht. QM kann beispielsweise einen Pilot stoppen, wenn Hygiene oder Produktsicherheit nicht ausreichend nachgewiesen sind. IT/OT kann eine Architektur ablehnen, die Sicherheits- oder Integrationsanforderungen verletzt. Arbeitssicherheit darf einschreiten, bevor eine wirtschaftlich attraktive Lösung zum sehr teuren Experiment wird.
Der Agile-Role-Mapping-Leitfaden beschreibt genau solche fachlich begrenzten Stopprechte.
Mitwirkung des KMU: Hard Gates und Stopkriterien vor dem Pilot festlegen.
Key User – Schichtleitung und Bedienpersonal
Sie testen, ob die Lösung unter realen Bedingungen funktioniert. Denn auf PowerPoint hat noch jede Benutzeroberfläche Frühschicht. Der Shopfloor zeigt dir dagegen sehr schnell, ob Meldungen verständlich sind, Bedienwege funktionieren und ein neuer Ablauf auch beim Produktwechsel um 7:30 Uhr morgens praktikabel bleibt.
Mitwirkung des KMU: Praxisfeedback geben, Nutzbarkeit prüfen und Abweichungen dokumentieren.
Pilot Owner – interne Projektverantwortung
Und hier wird es besonders wichtig. Während FoodTechFuture in der Analyse Methodik, Vergleichbarkeit und Entscheidungslogik führen kann, muss die operative Führung im Pilot auf Kundenseite liegen. Der Kundenleitfaden sieht ausdrücklich vor, dass die Verantwortung vor dem Pilot vom Analyse-Team an den Pilot Owner übergeht. Das ist keine Formalie. Bleibt der externe Berater auch im Pilot der einzige Mensch, der Daten hinterhertelefoniert, Termine organisiert und Entscheidungen anschiebt, hat das Unternehmen Beratung eingekauft – aber noch keine eigene Projektfähigkeit aufgebaut.
Gatekeeper – QM, Arbeitssicherheit, Technik oder IT/OT
Gatekeeper besitzen für ihren definierten Prüfbereich ein echtes Stopprecht. QM kann beispielsweise einen Pilot stoppen, wenn Hygiene oder Produktsicherheit nicht ausreichend nachgewiesen sind. IT/OT kann eine Architektur ablehnen, die Sicherheits- oder Integrationsanforderungen verletzt. Arbeitssicherheit darf einschreiten, bevor eine wirtschaftlich attraktive Lösung zum sehr teuren Experiment wird.
Der Agile-Role-Mapping-Leitfaden beschreibt genau solche fachlich begrenzten Stopprechte.
Mitwirkung des KMU: Hard Gates und Stopkriterien vor dem Pilot festlegen.
Die Pilot-Roadmap macht aus Rollen einen steuerbaren Versuch
Ist der Use Case priorisiert und grundsätzlich pilotfähig, beginnt die Pilot-Roadmap.
Sie verbindet:
- Zielbild
- KPIs
- Rollen und Verantwortlichkeiten
- Technologieoptionen
- Anbieterbewertung
- Budgetrahmen
- Risiken
- Meilensteine
- Go/No-Go-Kriterien
Für unser OEE-Projekt wird definiert:
Ziel: OEE ≥ 70 %
Baseline: rund 62 %
Messlogik: einheitliche Definitionen für Verfügbarkeit, Leistung und Qualität
Pilotbereich: klar abgegrenzter Linienabschnitt
Gate: keine Verschlechterung bei Produktsicherheit oder Qualitätsrate
Pilot Owner: benannt und zeitlich verfügbar
Go/No-Go: festgelegter Entscheidungstermin mit dokumentierten Kriterien
Damit entsteht eine saubere Kette:
Prozess-Struktur-Matrix: Wo liegt der Hebel?
Agile Role Mapping: Wer muss welchen Beitrag liefern und wer entscheidet?
Pilot-Roadmap: Wie testen wir die Lösung messbar und entscheidungsfähig?
Erst danach wird die Frage nach Technologie wirklich interessant.
Was KMU in Pilotprojekten tatsächlich mittragen
Erfolgreiche digitale Transformation verlangt nicht, dass dein halbes Unternehmen plötzlich Projektmanager spielt.
Aber einige Beiträge lassen sich nicht outsourcen.
1. Prozesswissen bereitstellen
Nur dein Team kennt die reale Linien- und Schichtwirklichkeit.
Der Prozess auf Papier und der Prozess um 5:12 Uhr am Freitagmorgen sind manchmal entfernte Verwandte.
2. Daten zugänglich machen
Stillstände, Ausschuss, Mengen, Personalaufwand, Qualitätsabweichungen und Störgründe müssen belastbar verfügbar sein.
„Wir glauben, dass …“ ist ein guter Gesprächseinstieg.
Für einen Business Case ist es etwas dünn.
3. Fachliche Gates besetzen
QM, Technik, Arbeitssicherheit und IT/OT müssen dort eingebunden werden, wo echte Ausschlusskriterien bestehen.
Nicht zwei Tage vor dem Pilotstart.
4. Entscheidungen treffen
Sach- und Budgetentscheidungen brauchen einen Owner.
Und idealerweise auch einen Termin.
Denn eine offene Entscheidung besitzt die interessante Eigenschaft, sich selten selbst zu schließen.
5. Shopfloor einbeziehen
Key User müssen Lösungen unter realen Bedingungen testen.
Wer die Menschen ausblendet, die später täglich mit der Technologie arbeiten, optimiert möglicherweise sehr erfolgreich am Problem vorbei.
6. Pilotverantwortung übernehmen
Spätestens im Pilot braucht es einen internen Owner mit Mandat, Zeitbudget und Eskalationsweg.
Der externe Partner kann begleiten.
Er sollte aber nicht dauerhaft der menschliche Projektdefibrillator bleiben.
Was passiert, wenn diese Mitwirkung fehlt?
Dann entstehen die Klassiker.
Keine belastbare Baseline:
Alle sprechen über OEE – nur leider über unterschiedliche Zahlen.
QM kommt zu spät:
Die favorisierte Lösung scheitert kurz vor dem Pilot am Hygiene-Gate.
Kein Decision Owner:
Produktion wartet auf Technik. Technik auf IT. IT auf Geschäftsführung. Das Projekt entwickelt währenddessen eine bemerkenswerte Kernkompetenz, d.h. Stillstand.
Keine Key User:
Die Technologie funktioniert technisch hervorragend. Nur leider nicht im Alltag.
Kein Pilot Owner:
Der Berater organisiert alles weiter und das KMU wundert sich später, warum intern niemand weiß, wie das Projekt im Regelbetrieb weitergeführt werden soll.
Agile Role Mapping betrachtet nicht nur Beteiligte, sondern Ergebnisverantwortung, Entscheidungen, Stopprechte und Eskalationen.
Digitale Transformation ist kein Bringdienst
Vielleicht ist das die wichtigste Botschaft für KMU. Du kannst externe Expertise einkaufen.
- Methodik.
- Marktkenntnis.
- Technologiebewertung.
- Moderation.
- Business-Case-Struktur.
- Pilotplanung.
Aber als Betriebsleiter:in kannst du nicht deine gesamte Projekt-Verantwortung an der Werkspforte abgeben. Digitale Transformation funktioniert im Prinzip ähnlich wie die Inbetriebnahme einer neuen Produktionslinie:
Der Anlagenbauer bringt Know-how.
- Technik integriert.
- QM prüft.
- Produktion definiert den Zielprozess.
- Bediener testen.
- Management entscheidet.
Alle arbeiten am selben Ergebnis – aber mit unterschiedlichen Rechten und Aufgaben. Genau diese Unterschiede macht Agile Role Mapping sichtbar.
Fazit: Transformation braucht Teamarbeit – aber bitte mit Spielpositionen
Ein gutes Digitalisierungsprojekt braucht nicht möglichst viele Beteiligte.
Es braucht die richtigen Menschen zur richtigen Zeit mit den Kompetenzen
- Fachwissen liefern,
- Daten bereitstellen,
- Entscheidungen treffen,
- Risiken bewerten,
- Lösungen testen
- und Verantwortung für den Pilot übernehmen.
„Wir müssten mal etwas mit KI machen“ entwickelt sich dadurch zu einem steuerbares Projekt. Und aus einem OEE-Wert von 62 % tatsächlich ein messbar besserer Produktionsprozess. Die Technik kann stark sein. Die KI kann beeindruckend sein. Der Roboter kann auf der Messe sogar sehr sympathisch winken. Aber damit daraus in deinem Betrieb Wirkung entsteht, müssen Menschen Verantwortung übernehmen.
Digitale Transformation kann begleitet werden. Verantwortung bleibt Teamarbeit.
Dein nächster Schritt
Du planst ein Robotik-, KI- oder Automatisierungsprojekt in der Lebensmittelproduktion?
Dann lade dir den Leitfaden „Robotik- und KI-Projekte“ herunter.
Er hilft dir, vor dem Pilot die Fragen zu klären, die später gern teuer werden:
- Welche Prozesse müssen vorher verstanden werden?
- Welche Daten brauchen wir?
- Welche Rollen müssen intern besetzt sein?
- Welche Fachbereiche besitzen ein Gate- oder Stopprecht?
- Welche Entscheidungen dürfen nicht an Anbieter oder Berater delegiert werden?
- Und woran erkennen wir überhaupt, ob der Pilot erfolgreich war?
Denn ein Pilot braucht nicht möglichst viele Beteiligte.
Er braucht die richtigen Menschen – mit klaren Beiträgen, klaren Rechten und einem gemeinsamen Ziel.
