Andon-System: Störungen sichtbar machen und gezielt bearbeiten

Eine rote Anzeige hilft wenig, wenn niemand weiß, wer reagieren soll. Umgekehrt muss eine Meldung nicht erst dramatisch aussehen, um wichtig zu sein: Fehlendes Material, eine unklare Arbeitsanweisung oder ein auffälliges Prüfergebnis können den nächsten Arbeitsschritt bereits blockieren. Hier geht es um die Organisation solcher Abweichungen, nicht um eine von mir aufgebaute Andon-Anlage.

Was Andon mit dem Toyota-Produktionssystem verbindet

Toyota beschreibt Andon im Zusammenhang mit Jidoka: Abweichungen werden erkennbar gemacht, damit Unterstützung unmittelbar am betroffenen Prozess ansetzen kann. In der historischen Darstellung werden manuell und automatisch ausgelöste Anzeigen genannt, die für die Verantwortlichen sichtbar sind. Der aktuelle Überblick zum Produktionssystem verknüpft die Meldung mit dem Beheben der Ursache, bevor die Arbeit geordnet fortgesetzt wird.

Daraus sollte man keine einheitliche technische Architektur ableiten. Eine manuelle Meldung, ein Maschinenereignis und ein Prüfsignal können unterschiedliche Auslöser sein. Ebenso ist ein Andon-System nicht automatisch eine Not-Halt-Einrichtung oder eine sicherheitsgerichtete Steuerung. Welche Maschinenreaktion erfolgt, muss separat festgelegt und technisch passend umgesetzt sein.

Bestätigung ist noch keine Problemlösung

Das Beispiel trennt drei Kennzahlen: Zeit bis zur Bestätigung, Zeit bis zur Unterstützung und Zeit bis zum Wiederanlauf. Würde eine Auswertung schon beim Quittieren enden, sähe sie eine Reaktion nach einer Minute. Die weitere Bearbeitung bliebe unsichtbar. Würde sie dagegen alle neun Minuten als reine Reparaturzeit bezeichnen, wären mögliche Warte- und Prüfanteile unzulässig mitgerechnet.

Auch Maschinenstillstand lässt sich nicht allein aus der Meldedauer bestimmen. Vielleicht lief der Prozess noch eine Zeit weiter; vielleicht war er schon vor dem Signal unterbrochen. Ich würde deshalb Beginn und Ende eines Stillstands als eigene Ereignisse führen, sofern diese Kennzahl gebraucht wird. Die Definition gehört neben den Zahlen auf die Auswertung.

Ein kleines, verständliches Meldeschema entwerfen

Ich würde mit wenigen verständlichen Anlässen starten und sie anhand tatsächlich auftretender Fälle überprüfen. Zwanzig nahezu gleich benannte Störungsklassen erzeugen leicht uneinheitliche Einträge. Ein freies Notizfeld kann die ersten Beobachtungen aufnehmen; später lassen sich wiederkehrende Muster sinnvoll zusammenfassen.

Farben dürfen dabei unterstützen, sollten aber nicht die einzige Information tragen. Eine Anzeige mit Arbeitsplatz, verständlichem Statuswort und zuständiger Rolle bleibt auch dann auswertbar, wenn jemand Farben schlecht unterscheidet oder ein Ausdruck nur schwarzweiß vorliegt. Ein hier erfundenes Farbschema wäre keine allgemeingültige Normvorgabe für industrielle Signalleuchten.

Eskalation braucht eine konkrete Aufgabe

Wenn die erste zuständige Person nicht reagieren kann, muss klar sein, wer als Nächstes übernimmt. Eine Eskalation sollte deshalb nicht nur eine weitere Meldung verteilen, sondern einen Verantwortungswechsel oder zusätzliche Unterstützung auslösen. Welche Frist dafür sinnvoll ist, hängt vom Prozess ab; aus unserer Zeitreihe lässt sich keine allgemeine Minutenvorgabe ableiten.

Für einen CNC-Arbeitsplatz würde ich zunächst drei eigene Fragen stellen: Darf der nächste Bearbeitungsschritt noch beginnen? Welche Teile sind gegebenenfalls zurückzuhalten? Welche Information braucht die unterstützende Person, bevor sie eingreifen kann? Die Antwort auf diese Fragen ist hilfreicher als eine pauschale Aufforderung, „die Lampe schnell wieder grün zu machen“.

Mit Qualitätssicherung verknüpfen, ohne Daten doppelt zu führen

Ein CAQ-System kann Prüfergebnisse und qualitätsbezogene Maßnahmen verwalten. Ein Andon-Ereignis kann darauf verweisen, muss aber nicht jedes Dokument in einer zweiten Datenbank kopieren. Wichtig sind eindeutige Zuordnung und nachvollziehbare Übergabe: Welcher Auftrag, welches Teil und welche Prüfung gehören zu der Meldung?

Wiederkehrende Fehler können Anlass für Poka Yoke oder eine Überprüfung der FMEA sein. Das sind nachgelagerte Verbesserungsaufgaben. Ein quittierter Alarm beweist weder, dass die Fehlerursache dauerhaft beseitigt ist, noch dass bereits entstandener Ausschuss korrekt erfasst wurde.

Erfolg am Ablauf beurteilen

Ich würde die Einführung an wenigen konkreten Fragen messen: Kommen Meldungen beim richtigen Ansprechpartner an? Sind unklare Zustände seltener? Werden offene Ursachen nachverfolgt? Eine sinkende Zahl an Meldungen kann eine Verbesserung anzeigen, aber auch bedeuten, dass Mitarbeitende Probleme nicht mehr melden. Die Zahl allein beantwortet das nicht.

Für eine kleine Werkstatt kann zunächst eine einfache Ereignisliste genügen. Ein großes Dashboard ist erst dann hilfreich, wenn es verlässliche Zustände zeigt und die Arbeit unterstützt. Der sinnvollste Ausgangspunkt ist ein klarer Ablauf vom erkannten Problem bis zum nachvollziehbaren Abschluss.