Poka-Yoke für Wissen: warum Ihre FMEA leer bleibt

Vor Jahren weigerte sich ein Ingenieur, sein Wissen in die FMEA einzutragen.

Er sagte den Grund offen, in der Besprechung. Das Aufschreiben würde seinen eigenen Wert im Unternehmen mindern.

Seine Antwort war ehrlicher als das Formular in meiner Hand.

Der Anreiz, den niemand einplant

In fast jedem Werk gibt es einen Menschen, den man ruft, wenn genau diese Maschine stehen bleibt. Sein Wissen steht in keinem Dokument. Alle wissen das, und niemand ändert es.

Das Unternehmen belohnt ihn dafür, dass er weiß, was andere nicht wissen. Dann verlangt es, dass er es aufschreibt. Es bittet ihn, den Grund zu verkleinern, aus dem er gerufen wird.

Eliyahu Goldratt hat den Mechanismus in einen Satz gefasst: sag mir, wie du mich misst, und ich sage dir, wie ich mich verhalten werde. Dieser Ingenieur wird daran gemessen, was nur er lösen kann. Er verhält sich genau so, wie er gemessen wird.

Die übliche Antwort ist eine Erinnerung, eine Vorlage oder eine Schulung. Alle drei setzen voraus, dass das Problem Aufmerksamkeit heißt. Das tut es nicht.

Was Shingo tatsächlich gesagt hat

Shigeo Shingo hat eine Grenze gezogen, die viele Qualitätsabteilungen bis heute verwischen. Er trennte den Fehler vom Defekt. Menschen machen Fehler. Ein Fehler wird erst dann zum Defekt, wenn ihn dazwischen nichts aufhält.

Sein Schluss war nicht, dass Menschen sorgfältiger sein sollen. Sorgfalt ist keine Kontrolle. Er gestaltete den Schritt so, dass die falsche Handlung nicht zu Ende geführt werden kann: eine Vorrichtung, die das Teil nur in einer Lage aufnimmt, und ein Werkzeug, das über einer fehlenden Scheibe nicht schließt.

Der Kern von Poka-Yoke ist, dass es die Abhängigkeit von menschlicher Aufmerksamkeit genau dort entfernt, wo die Aufmerksamkeit am ehesten nachlässt.

Lesen Sie denselben Gedanken gegen Ihre FMEA. Wenn sich das Dokument nur füllt, wenn jemand daran denkt, großzügig ist und eine Stunde Zeit hat, beruht das System auf Aufmerksamkeit. Es gibt keine Kontrolle.

Warum die Excel FMEA zweimal stirbt

Eine FMEA in der Tabelle versagt an zwei getrennten Stellen, und die zweite erklärt, warum so viele davon beschäftigt aussehen und trotzdem niemandem helfen.

Sie versagt bei der Erfassung. Der Eintrag ist eine gesonderte Handlung, nach der eigentlichen Arbeit. Er konkurriert mit der nächsten Reklamation. Er hat keine Frist, die jemand durchsetzt. Also füllt er sich ungleichmäßig, überwiegend durch die Menschen mit dem geringsten Verlustrisiko.

Sie versagt beim Wiederfinden. Selbst die Zeilen, die geschrieben wurden, sind ein halbes Jahr später schwer erreichbar. Der Ingenieur, der sie braucht, weiß nicht, dass die Datei existiert, kann nicht über zwölf Versionen auf SharePoint suchen und weiß nicht, welche die aktuelle war. Das Wissen ist also technisch geschrieben und praktisch verloren.

Dieses zweite Versagen ist der Grund, warum im selben Werk beide Sätze zutreffen: “wir dokumentieren alles” und “dasselbe Problem lösen wir zweimal im Jahr”.

Was eine Absicherung für Wissen leisten muss

Wenn Aufmerksamkeit keine Kontrolle ist, müssen vier Eigenschaften gelten. Keine davon betrifft Software.

Die Erfassung muss ein Nebenprodukt der Arbeit sein. Das Wissen wird festgehalten, weil der Fall abgeschlossen wurde, nicht weil jemand hinterher darum gebeten hat. Gibt es einen gesonderten Schritt, gibt es Ausnahmen, und Ausnahmen werden zur Regel.

Der Eintrag muss seine Quelle mitführen. Eine Ursache ohne Dokument, Charge oder Messung dahinter ist eine Meinung mit Formatierung. Der nächste Ingenieur muss prüfen können, nicht vertrauen müssen.

Das Wiederfinden muss im Moment des Bedarfs geschehen. Nicht auf Anfrage und nicht nach einer Suche. Wenn jemand ein ähnliches Problem beschreibt, muss das bereits Gelernte mitkommen.

Wer schreibt, darf dafür nicht bezahlen. Diese Eigenschaft entscheidet, ob die anderen drei je laufen. Kostet der Beitrag an Wissen Status, wird das System umgangen, so gut es auch sein mag.

Was dabei herauskommt

Das bauen wir bei Galileon. Keinen Ablageort für Dokumente und kein weiteres Formular. Ein System, in dem jeder abgeschlossene Fall den nächsten speist.

Was das dem Ingenieur bringt, gemessen an unserer eigenen Pilotstichprobe von 10 Kundenreklamationen bei slowenischen Herstellern, Januar bis März 2026:

• Der Schritt der Korrekturmaßnahmen geht von drei Tagen Besprechungen auf etwa dreißig Sekunden bis zum ersten Vorschlag, weil die Vorschläge aus Maßnahmen stammen, die an bestätigten Ursachen bereits gewirkt haben.
• Der Schritt der Problembeschreibung liefert rund dreimal mehr brauchbare Vorschläge als eine leere Vorlage, weil er bei ähnlichen Fällen beginnt und nicht bei einer leeren Seite.
• Vollständige Rückverfolgbarkeit von der Kundenreklamation bis zur Vorbeugemaßnahme, sodass die Auditfrage “zeigen Sie mir, wie Sie hierher gekommen sind” eine Antwort hat, die bereits vorliegt.

Was der Ingenieur nicht tut: eine Wissensdatenbank füllen. Der Eintrag entsteht, weil der Fall abgeschlossen wurde.

Was beim Ingenieur bleibt

Agenten werden Daten so erheben, wie Menschen sie heute erheben, und es wird weit mehr Daten geben als heute. Der letzte Schritt gehört weiterhin einem Menschen.

Das Urteil, das sich nicht verschiebt, ist analytisches und kritisches Denken, und es zeigt sich in vier Entscheidungen:

• was nicht zu diesem Problem gehört
• was Rauschen ist und was ein Signal
• wo die Interpretation falsch ist
• welche Daten erneut erhoben werden müssen, an einer größeren Stichprobe

Mehr Daten erhöhen den Wert der Entscheidung, welche davon überhaupt vom Problem sprechen.

Die Grenze, die sich zu ziehen lohnt

Es gibt eine Variante davon, in der jedes Unternehmen sein eigenes baut. Code ist heute billig, also wird zu Dingen, zu denen man Nein sagen müsste, kein Nein gesagt, und das Ergebnis ist ein Produkt mit vielen Funktionen und ohne Zuneigung zu einer davon.

Die Frage, die sich davor lohnt, lautet, welcher Teil wirklich Ihre Domäne ist und welchen Teil man besser denen überlässt, die jeden Tag daran arbeiten, weit mehr Daten haben und etwas Besseres liefern werden als ein hausgemachtes MVP.

Die Antwort gehört Ihnen. Sie ist es wert, bewusst gegeben zu werden und nicht nebenbei.

Mehr auf galileon.si

• Zwei Jahre für die Beschreibung eines Fehlers: was Toyotas Rückruf über Problembeschreibung lehrt - was davor passiert, wenn das Problem nie gut genug beschrieben wird, damit die Analyse greifen kann.
• Wie SolveR funktioniert
• Datensicherheit

Quellen

• Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System, Productivity Press, 1986. Verlagsseite
• Eliyahu M. Goldratt, über Messung und Verhalten. Goldratt Consulting