Andon / Line-Stop Triage als Workflow: schnell reagieren, sauber eskalieren, nachvollziehbar dokumentieren

In der Fertigung zählt bei Störungen jede Minute. Gleichzeitig ist genau diese Phase oft chaotisch: Viele Beteiligte, wenige gesicherte Informationen, parallele Maßnahmen – und später ist schwer zu rekonstruieren, was wann entschieden wurde.

Cumulus setzt deshalb auf ein bewusstes Prinzip: Agentische Planung (aus Signalen wird ein sinnvoller Plan) – kontrollierte Ausführung (kleine Steps, Regeln, begrenzte Fehlerpfade). Das macht Triage schnell, aber auch belastbar.

Kurzstory

Eine Station steht. Der Bediener meldet „Teil klemmt“, Instandhaltung vermutet Sensorik, Qualität fragt nach Ausschuss, die Schichtführung will eine ETA für „läuft wieder“. Während parallel Handgriffe passieren, gehen Informationen in Chat-Threads verloren.

Ein Andon-Triage-Workflow sorgt dafür, dass die ersten Schritte standardisiert sind: Event wird sauber erfasst, Severity ist klar, Erstchecks sind gezielt, Routing/Eskalation folgen Regeln – und am Ende ist dokumentiert, was wirklich passiert ist.

1) Warum Andon-Triage mehr als „Alarm weiterleiten“ ist

Ein Andon-Event ist nicht nur ein Signal, sondern der Start eines Prozesses:

• Was ist die wahrscheinlichste Fehlerklasse (Material, Maschine, Prozess, Bedienung)?
• Welche Checks sind sofort sinnvoll – ohne Zeit zu verlieren?
• Wer muss wann ran (Schichtführer, Instandhaltung, Qualität, Prozessingenieur)?
• Wann eskalieren wir (SLA/MTTR, Sicherheitsimpact, Kundenrelevanz)?
• Welche Maßnahmen sind erlaubt, welche brauchen Freigabe?

Die Herausforderung: Man braucht Geschwindigkeit und Wiederholbarkeit.

2) Agentische Herkunft: Der Agent als Plan-Autor (nicht als Autopilot)

Agenten sind stark bei:

• knapper Zusammenfassung („Was wissen wir?“)
• Ableiten von sinnvollen Erstchecks je Fehlerklasse
• Formulieren von klaren Tasks und Rückfragen
• Strukturieren von Informationen für Schichtübergaben

Der Agent schlägt also einen Plan vor. Entscheidend ist, dass die Umsetzung in kleinen, klaren Schritten passiert – und nicht als ein großer, unkontrollierter „Mach mal“.

3) Steps: Standardisieren, ohne zu versteinern

Andon-Triage ist ideal für Steps:

• Jeder Step ist klein und eindeutig.
• Jeder Step ist überprüfbar (hat er das geliefert, was er soll?).
• Steps lassen sich pro Linie/Produkt variieren, ohne das Grundprinzip zu verlieren.

So entsteht „standard work“ – ohne starre Checklisten, die in der Praxis oft umgangen werden.

4) Agentic vs. Logic: Text/Heuristik vs. operative Aktionen

• Agentische Steps: Klassifikation, Hypothesen, Task-Formulierungen, Zusammenfassungen.
• Deterministische Steps: Routing, Eskalation, Status-Updates, saubere Zeitstempel/Ereignislog.

Das ist ein wichtiger Unterschied: In der Störung darf man denken – aber operative Änderungen müssen konsistent passieren.

5) Beispiel-Blueprint: Andon-Triage in 6–8 Schritten

1. Event normalisieren (Linie/Station/Fehlercode/Zeit) und kurz zusammenfassen
2. Kritikalität einschätzen (Sicherheit, Qualitätsrisiko, Lieferimpact)
3. Erstchecks vorschlagen (z. B. Materialwechsel? letzte Umrüstung? häufige Störung?)
4. Routing entscheiden (Wer übernimmt?) und Tasks anlegen
5. Informationslücken identifizieren → gezielte Rückfragen/Datenerhebung
6. Eskalationslogik anwenden (Zeit, Wiederholung, Severity)
7. Abschluss: Störgrund + Maßnahmen dokumentieren
8. Übergabe/Lessons Learned (für Wiederholstörungen)

Der Schlüssel ist die Trennung von „schnell handeln“ und „sauber dokumentieren“ – beides muss passieren, ohne dass es sich gegenseitig ausbremst.

6) Regelwerk statt „im Moment entscheiden“

Störungen werden besser, wenn man Entscheiden standardisiert:

• Eskalationsregeln sind explizit (Zeit/Severity/Wiederholung)
• erlaubte Sofortmaßnahmen sind klar
• Stop/Restart-Freigaben sind eindeutig geregelt
• Rückfragen sind gezielt (statt „schick mal alles“)

Das reduziert nicht nur MTTR, sondern auch die Varianz zwischen Schichten.

7) Repair & Human-in-the-loop: Wenn die Realität unklar ist

In Störungen sind Inputs oft unvollständig. Cumulus kann robust damit umgehen:

• Repair-then-Retry: Wenn Klassifikation/Tasks unpräzise sind, wird gezielt nachgeschärft.
• Human-in-the-loop: Bei riskanten Entscheidungen (Sicherheit, Qualität) wird ein Mensch gezielt eingebunden.

Wichtig: keine Endlosschleifen – die Fehlerpfade sind begrenzt.

Kurzablauf als Diagramm (high level)

Für Ops/Leitung: Was sich messbar verbessert

• MTTR sinkt: Erstchecks, Routing und Eskalation laufen konsistenter ab.
• Weniger Stillstand-Minuten: Der Prozess startet schneller und verliert weniger Zeit durch Unklarheit.
• Bessere Schichtübergaben: Informationen sind strukturiert, nicht nur “in Köpfen”.
• Weniger Varianz zwischen Teams: Regeln ersetzen situatives Improvisieren.
• Nachvollziehbarkeit: Störgründe, Entscheidungen und Maßnahmen sind sauber dokumentiert.

KPI-Kasten: Woran Sie Erfolg messen

• MTTA / Time-to-First-Action (vom Andon-Event bis zur ersten wirksamen Maßnahme)
• MTTR (Mean Time To Repair/Recover)
• Downtime-Minuten je Linie/Schicht (und Anteil Wiederholstörungen)
• Eskalationen innerhalb SLA (rechtzeitig, nicht “zu spät, wenn’s brennt”)
• Störgrund-Qualität (vollständige, konsistente Abschlussdokumentation)

Fazit

Andon-Triage braucht Geschwindigkeit, aber auch Disziplin. Cumulus verbindet:

• agentische Planung für die ersten sinnvollen Schritte
• kontrollierte Ausführung, Regeln und begrenzte Fehlerpfade
• nachvollziehbare Ereignisse und saubere Übergaben

So wird aus “Alarm & Chaos” ein wiederholbarer Ablauf – ohne die Teams zu überregulieren.

Nächster Schritt

Wenn Sie möchten, erarbeiten wir daraus ein wiederverwendbares Andon-Playbook:

• 60–90 Minuten: Rollen, Eskalationsstufen, erlaubte Sofortmaßnahmen, Stop/Restart-Gates
• Ergebnis: ein Triage-Blueprint (Steps + Regeln) als Template pro Linie/Produktfamilie
• Optional: 3 häufigste Störungsklassen als Varianten (z. B. Material, Sensorik, Umrüstung)