Poka-yoke za znanje: zakaj vaš FMEA ostane prazen

FMEA ni prazen, ker bi bili ljudje leni. Prazen je, ker zapisovanje znanja nekaj stane tistega, ki zapiše.

Excelov FMEA list s štirimi izpolnjenimi vrsticami ob gosti povezani mreži znanja.

Pred leti je inženir zavrnil vpis svojega znanja v FMEA.

Razlog je povedal na glas, na sestanku. S tem bi razvrednotil svojo vrednost v podjetju.

Njegov odgovor je bil bolj pošten od obrazca, ki sem ga držal v roki.

Spodbuda, ki je nihče ne načrtuje

V skoraj vsaki tovarni je nekdo, ki ga pokličejo, ko se ustavi točno tisti stroj. Njegovo znanje ni v nobenem dokumentu. Vsi to vedo in nihče tega ne popravi.

Podjetje ga nagradi za to, da zna tisto, česar drugi ne znajo. Potem od njega zahteva, da to zapiše. Prosi ga, naj zmanjša razlog, zaradi katerega ga kdo pokliče.

Eliyahu Goldratt je mehanizem spravil v en stavek: povej mi, kako me meriš, in povem ti, kako se bom obnašal. Tega inženirja merijo po tem, kar zna rešiti samo on. Obnaša se točno tako, kot ga merijo.

Običajen odgovor je opomnik, predloga ali usposabljanje. Vsi trije predpostavljajo, da je problem pozornost. Ni.

Kaj je Shingo v resnici povedal

Shigeo Shingo je potegnil ločnico, ki jo večina oddelkov kakovosti še vedno zabriše. Ločil je napako od defekta. Ljudje delajo napake. Napaka postane defekt šele, kadar je vmes nič ne ustavi.

Njegov sklep ni bil, naj bodo ljudje bolj pazljivi. Pazljivost ni kontrola. Korak je zasnoval tako, da napačnega dejanja ni mogoče dokončati: vpetje, ki kos sprejme samo v eni legi, in orodje, ki se čez manjkajočo podložko ne zapre.

Bistvo poka-yoke je, da odstrani odvisnost od človeške pozornosti prav v trenutku, ko pozornost najverjetneje popusti.

Preberite isto misel ob svojem FMEA. Če se dokument polni samo takrat, ko se nekdo spomni, je velikodušen in ima uro časa, sistem sloni na pozornosti. Kontrole ni.

Zakaj Excelov FMEA umre dvakrat

FMEA v preglednici odpove na dveh ločenih mestih, in drugo je razlog, da jih toliko izgleda zaposlenih in vseeno nikomur ne pomaga.

Odpove pri zajemu. Vpis je ločeno dejanje, po tem, ko je pravo delo končano. Tekmuje z naslednjo reklamacijo. Nima roka, ki bi ga kdo preganjal. Zato se polni neenakomerno, večinoma z ljudmi, ki imajo najmanj izgubiti.

Odpove pri iskanju. Tudi vrstice, ki so bile zapisane, so pol leta pozneje težko dosegljive. Inženir, ki jih potrebuje, ne ve, da datoteka obstaja, ne more iskati po dvanajstih različicah na SharePointu in ne ve, katera je bila zadnja. Znanje je torej tehnično zapisano in praktično izgubljeno.

Ta druga odpoved je razlog, da sta v isti tovarni hkrati resnična stavka “mi vse dokumentiramo” in “isti problem rešujemo dvakrat na leto”.

Kaj mora varovalo za znanje znati

Če pozornost ni kontrola, morajo držati štiri lastnosti. Nobena od njih ni o programski opremi.

Zajem mora biti stranski učinek dela. Znanje se zapiše zato, ker je bil primer zaključen, ne zato, ker je nekdo pozneje prosil. Če obstaja ločen korak, bodo izjeme, in izjeme postanejo pravilo.

Zapis mora nositi svoj vir. Vzrok brez dokumenta, šarže ali meritve za sabo je mnenje z oblikovanjem. Naslednji inženir mora imeti možnost preveriti, ne zaupati.

Iskanje se mora zgoditi v trenutku potrebe. Ne na zahtevo in ne po iskanju. Ko nekdo opiše podoben problem, mora tisto, kar je bilo že naučeno, priti skupaj z njim.

Tisti, ki zapiše, za to ne sme plačati. Ta lastnost odloči, ali bodo ostale tri sploh kdaj tekle. Če prispevek znanja stane položaj, bo sistem obšel vsak, ne glede na to, kako dober je.

Kaj to prinese

To je tisto, kar gradimo v Galileonu. Ne kraj za shranjevanje dokumentov in ne še en obrazec. Sistem, v katerem vsak zaključen primer nahrani naslednjega.

Kaj to prinese inženirju, merjeno na našem pilotnem vzorcu 10 reklamacij pri slovenskih proizvajalcih, januar do marec 2026:

  • Korak korektivnih ukrepov gre s treh dni sestankov na približno trideset sekund do prvega predloga, ker predlogi izhajajo iz ukrepov, ki so na potrjenih vzrokih že delovali.
  • Korak opisa problema da približno trikrat več uporabnih predlogov kot prazna predloga, ker začne pri podobnih primerih in ne pri prazni strani.
  • Popolna sledljivost od reklamacije kupca do preventivnega ukrepa, tako da ima presojevalčevo vprašanje “pokažite mi, kako ste prišli do tega” odgovor, ki že obstaja.

Česa inženir ne dela: ne polni baze znanja. Zapis nastane, ker je bil primer zaključen.

Kaj ostane inženirju

Agenti bodo podatke pobirali tako, kot jih danes pobirajo ljudje, in podatkov bo veliko več, kot jih je danes. Na zadnjem koraku bo vedno človek.

Presoja, ki se ne premakne, je analitično in kritično razmišljanje, in pokaže se pri štirih odločitvah:

  • kaj ne sodi k problemu
  • kaj je šum in kaj je indikator
  • kje je interpretacija napačna
  • katere podatke je treba zajeti še enkrat, na večjem vzorcu

Več podatkov dvigne vrednost presoje, kateri od njih sploh govorijo o problemu.

Ločnica, ki jo je vredno potegniti

Obstaja različica, v kateri vsako podjetje zgradi svojega. Koda je zdaj poceni, zato se stvarem, ki bi jim morali reči ne, ne reče ne, in rezultat je izdelek z veliko funkcijami in brez ljubezni do razvoja za katerokoli od njih.

Vprašanje, ki ga je vredno postaviti, preden se to začne, je, kateri del je res vaša domena in kateri del je bolje prepustiti tistim, ki na njem delajo vsak dan, imajo veliko več podatkov in bodo dostavili boljšo rešitev, kot jo doma zgradite kot MVP.

Odgovor je vaš. Vreden je tega, da ga daste zavestno in ne po naključju.

Več na galileon.si

Viri

  • Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System, Productivity Press, 1986. Stran založnika
  • Eliyahu M. Goldratt, o meritvi in vedenju. Goldratt Consulting
Vsi prispevki