CMMS proti napovednemu vzdrževanju: kaj mora sistem za vzdrževanje dejansko znati

Vodja vzdrževanja prosi za „CMMS“. Dobavitelj odgovori s senzorji, strojnim učenjem in nadzorno ploščo, ki napove okvare tri tedne vnaprej. Nekje v tem pogovoru se izgubi pravo vprašanje — kaj se zgodi, ko se stroj naslednjič pokvari ob dveh zjutraj. CMMS in napovedno vzdrževanje nista konkurenčna nakupa, nista pa tudi isti nakup. Eno je hrbtenica evidence; drugo je strategija, ki teče na njej. Kupiti drugo brez prvega je pogostejša in dražja napaka.

Čemu CMMS dejansko služi

Sistem za vzdrževanje (CMMS) je po zasnovi nebleščeč: delovni nalogi, preventivni razporedi, zaloga nadomestnih delov in zgodovina strojev, vse na enem mestu namesto na beli tabli, v preglednici in v spominu kateregakoli tehnika, ki se še spomni, kaj se je zgodilo zadnjič. Časovno in izrabno pogojeni načrti — mesečno, letno ali vsakih N obratovalnih ur ali izdelanih kosov — se ustvarjajo in spremljajo samodejno, namesto da bi bilo odvisno od tega, ali si nekdo zapomni rok.

Ta hrbtenica šteje več kot katera koli strategija, ki teče na njej, ker je vsaka strategija odvisna od istega zapisa. Napoved, da bo ležaj odpovedal, je brez vrednosti, če ni delovnega naloga, na podlagi katerega bi kdo ukrepal, ni dodeljenega tehnika in ni zgodovine, kaj se je z ležajem dejansko zgodilo ob zadnjem servisu. Tovarne, ki preskočijo naravnost na napovedno vzdrževanje, ne da bi prej uredile disciplino delovnih nalogov, navadno ugotovijo, da je bil model najlažji del.

Kje se napovedno vzdrževanje začne in kje CMMS neha

Preventivno vzdrževanje teče po koledarju ali števcu: ta menjalnik servisirajte vsakih 90 dni ali vsakih 50.000 ciklov, kar nastopi prej, ne glede na to, kakšno je dejansko stanje menjalnika. Poceni je za začetek — dovolj je CMMS z načrti, ki temeljijo na strategiji, senzorji niso potrebni — a zdravo opremo servisira prepogosto, opremo pod nenavadno obremenitvijo pa premalo, ker sta čas in število ciklov nadomestek za obrabo, ne njena meritev.

Napovedno vzdrževanje ta nadomestek zamenja z meritvijo. Podatki o vibracijah, temperaturi in toku iz senzorjev IoT ali obstoječega PLC hranijo model, ki opozori na poslabšanje stanja, preden postane okvara — ležaj, ki teče topleje od svojega lastnega izhodišča, motor, ki za isto opravilo porabi več toka kot pred mesecem dni. Izid je še vedno delovni nalog v istem CMMS; spremenil se je le sprožilec, iz datuma v resničen signal.

Poštena omejitev: napovedni model je toliko dober, kolikor dobra je zgodovina okvar, na kateri se je učil. Stroj brez zabeleženih okvar in brez zgodovine senzorjev za zadnje leto modelu ne da ničesar, na kar bi se umeril. To je praktičen razlog, zakaj je napovedno vzdrževanje običajno druga stvar, ki jo tovarna uvede, ne prva — CMMS mora najprej beležiti resnične okvare in resnične popravke, preden „napovej naslednjo“ sploh kaj pomeni.

Dve številki, ki povesta, ali karkoli od tega deluje

MTBF (povprečni čas med okvarami) in MTTR (povprečni čas do popravila) nista kozmetični meri; sta edini dve številki, ki ločita „vzdrževanje izvajamo“ od „vzdrževanje deluje“. Rast MTBF pomeni, da katera koli strategija je v uporabi — preventivna, napovedna ali obe — dejansko preprečuje okvare, ne le beleži naknadno. Padec MTTR pomeni, da ko se nekaj vendarle pokvari, delovni nalog, dodeljeni tehnik in nadomestni del prispejo dovolj hitro, da je zastoj mehanska težava in ne administrativna.

Zgodovina vzdrževanja, ki zgolj šteje okvare brez časovnih žigov za „prijavljeno“, „začeto“ in „zaključeno“, nobene od teh dveh številk ne more pošteno izračunati. To je konkreten razlog, zakaj mora biti zgodovina strojev strukturiran podatek znotraj CMMS — MTBF, MTTR, delež zastojev, stopnja nujnih klicev in strošek po stroju, liniji in obratu, izračunani iz istih zapisov, ki jih je tehnik že izpolnil, ne rekonstruirani pozneje iz spomina.

Zakaj si vzdrževanje in proizvodnja brez integracije lastita iste ure

Plan vzdrževanja in proizvodni terminski načrt oba merita na iste strojne ure, in če nastajata v dveh sistemih, ki med seboj ne govorita, ena stran za drugo izve presenečena. Vzdrževanje za torkovo popoldne razpiše menjavo ležaja; proizvodnja ima za isto popoldne na isti liniji nujno naročilo. Nekdo izgubi, in odloči navadno tisti, ki tisto jutro najglasneje kriči, ne pa izbira, ki dejansko stane manj.

Če se okna za vzdrževanje vnesejo v proizvodni terminski načrt — namesto da tečejo proti njemu — ta spor postane omejitev pri razvrščanju in ne spopad. APS pri gradnji načrta vzdrževalno okno vidi kot nerazpoložljiv termin, vzdrževanje pa pri predlaganju okna vidi potrjena naročila. Nobena stran ni presenečena, ker nobena ne dela po načrtu, ki ga druga ne vidi.

Kje MES neha in kje se začne CMMS

Isto mejno vprašanje, ki loči MES od ERP in SCADA, velja tudi tu, in vredno je biti prav tako natančen. MES drži trenutek, ko se stroj ustavi: v realnem času, na terenu, zajame vzrok zastoja — kategorijo, časovni žig, katero operacijo — ker je zastoj tam prvič viden. CMMS drži, kaj se zgodi naprej: prijavo vzdrževanja, samodejno ustvarjeno iz tega vzroka zastoja, poslanega tehnika, rezerviran del, zabeležen popravek, ves dogodek pa se ob zaključku všteje v MTBF tega stroja.

Če ju obravnavate kot nadomestka, nekaj poči v obe smeri. Zahtevajte od MES, naj vodi popravilo, in nima pojma o zalogi nadomestnih delov, usposobljenosti tehnikov ali preventivnem koledarju — za to ni namenjen. Zahtevajte od CMMS, naj sploh zazna zastoj, brez vira podatkov iz obrata, in vsaka prijava je odvisna od tega, ali se nekdo spomni, da jo ročno vnese — natanko tisti problem discipline, zaradi katerega je bil CMMS sploh kupljen. Integracija, ki dejansko deluje, je ozka in konkretna: vzrok zastoja, zabeležen v MES, samodejno ustvari prijavo vzdrževanja, z že izpolnjenim strojem, časom in kodo napake. Nihče ničesar ne prepisuje znova in nič ne čaka, da bi nekdo opazil.

Nadomestni deli: korak, ki ga vsaka uvedba CMMS podceni

Delovni nalog, ki tehniku pove, kaj naj popravi, ne pove pa, ali je del na polici, je pol sistema, in prav tu presenetljivo veliko uvedb CMMS v prvem letu tiho odpove. Preverjanje zaloge se zgodi vseeno — le da se zgodi kot telefonski klic v skladišče namesto znotraj programske opreme, kar zamudo vrne natanko tja, od koder naj bi jo CMMS odstranil.

Neposredna povezava vzdrževalnih nalogov z zalogo nadomestnih delov to vrzel zapre: delovni nalog rezervira potrebni del, medskladiščni prenos s potrditvijo črtne kode ga premakne, če je na drugi liniji ali drugi lokaciji, naročilo pri dobavitelju pa se samodejno sproži, če je polica dejansko prazna. Tehnik še vedno hodi do police, a programska oprema je vprašanje, ali bo del tam, že odgovorila — kar je razlika med desetminutno hojo in dvodnevnim čakanjem na isti popravek.

Kaj se dejansko spremeni, ko preventivno postane napovedno

Pri uvedbah vzdrževanja Meta Smart Factory tipičen premik iz izključno reaktivne ali ohlapno preventivne ureditve v CMMS z napovednim vzdrževanjem zraven prinese približno 45 % manj okvar, 20 % daljšo življenjsko dobo strojev in 30 % nižje stroške vzdrževanja, delovni nalogi pa postanejo v celoti digitalni, ne glede na to, kakšna mešanica papirja in spomina jim je botrovala prej. Nobena od teh štirih številk ne izhaja zgolj iz senzorjev — izhajajo iz kombinacije: CMMS, ki zanesljivo beleži vsako okvaro in vsak popravek, preventivnih načrtov, ki nehajo ugibati intervale, napovednih opozoril tam, kjer jih zgodovina okvar upravičuje, in nadomestnih delov, ki so rezervirani, preden je tehnik poslan, ne pa odkriti kot manjkajoči šele potem.

Praktično vprašanje zaporedja ni „CMMS ali napovedno vzdrževanje“ — je, kaj pride prej, odgovor pa je vedno CMMS. Napovedno vzdrževanje je strategija, ki jo usmerite na sistem vzdrževanja, ki že beleži resnico o tem, kaj se pokvari in koliko to stane. Usmerite jo na karkoli manj od tega, in model nima ničesar resničnega, iz česar bi se učil.