Proizvodna analitika: spremljanje podatkov v realnem času

Kaj je proizvodna analitika v realnem času?#

Proizvodna analitika v realnem času je sistem, ki neprekinjeno zajema podatke iz proizvodnega procesa – izkoristek strojev, zastoje, kakovost izdelkov, porabo materiala – in jih takoj prikaže v obliki, ki jo lahko vodja izmene, vodja proizvodnje ali direktor razume in uporabi za odločitev. Razlika v primerjavi s klasičnim poročanjem je v tem, da se stanje ne čaka do konca izmene ali meseca, temveč je vidno, medtem ko proces še teče.

Proizvodna analitika ni le nadzorna plošča na zaslonu, temveč veriga korakov: zajem podatkov iz strojev in senzorjev, njihova obdelava in povezovanje z obstoječimi poslovnimi sistemi, shranjevanje ter šele nato prikaz. Del tega je tudi avtomatizacija poročanja in obvestil, tako da opozorilo o zastoju ali odstopanju kakovosti pride do prave osebe brez ročnega pregledovanja podatkov. Brez urejenega ozadja je nadzorna plošča le lepa slika, ne pa orodje za odločanje.

Realni čas je pomemben, ker odločitve v proizvodnji pogosto ne prenesejo čakanja do naslednjega poročila. Zastoj stroja, odstopanje v kakovosti ali pomanjkanje materiala je treba zaznati, medtem ko izmena še teče, ne šele naslednji dan. Ker podatki zanimajo več oddelkov hkrati – proizvodnjo, kakovost, vzdrževanje in vodstvo – mora biti sistem zasnovan tako, da vsak vidi tisto, kar potrebuje za svojo odločitev, ne celotne surove podatkovne baze.

Katere podatke je smiselno spremljati v proizvodnji?#

Katere podatke je smiselno spremljati, je odvisno od procesa, vendar se v praksi ponavljajo podobne skupine: podatki o delovanju strojev, kakovosti, porabi materiala, energiji in zasedenosti izmen. Izbor ni tehnično vprašanje, temveč najprej organizacijsko – določiti je treba, katera odločitev naj bo podprta s podatkom, preden se odloči, kako ga zajeti in prikazati. Šele ko je jasno, kdo podatek potrebuje in za kaj, ima smisel govoriti o tehnični izvedbi zajema.

Izbira, katere od teh podatkov povezati v en sistem, neposredno vpliva na obseg integracije. Vsak dodaten vir podatkov pomeni dodatno povezavo, dodaten API in dodatno preverjanje, ali so podatki dovolj zanesljivi za prikaz v realnem času. Zato je smiselno začeti z manjšim, jasno omejenim naborom podatkov, ki rešuje konkretno odločitev, in šele nato razširiti obseg na druge oddelke ali procese.

Ni nujno, da so vsi podatki enako nujni v realnem času. Podatki o zastojih ali kakovosti med izmeno so pogosto kritični in morajo biti vidni takoj, medtem ko je za nekatere analize, na primer mesečno porabo energije, dovolj periodično osveževanje. Določitev, kateri podatki zahtevajo resnično sprotno spremljanje in kateri ne, je del zgodnje faze projekta in vpliva na to, kako zahtevna bo tehnična rešitev.

• podatki o izkoristku in zastojih strojev
• podatki o kakovosti izdelkov in izmetu
• podatki o porabi materiala in stanju zalog
• podatki o energiji in obratovalnih stroških
• podatki o izmenah in zasedenosti delovne sile
• podatki iz vzdrževanja, načrtovanega in nenačrtovanega

Kako povezati proizvodne linije z obstoječimi sistemi#

Proizvodne linije se z obstoječimi poslovnimi sistemi povežejo prek API-jev, ki podatke iz strojev, senzorjev in industrijske opreme prenesejo v skupno okolje, kjer se obdelajo in prikažejo. Gre za sistemsko integracijo, pri kateri je treba za vsak vir podatkov preveriti, kakšen dostop omogoča – ali gre za odprt API, izvoz datotek ali zaprt sistem, ki ga je treba dodatno odpreti.

V praksi imajo srednja in velika podjetja podatke razpršene med proizvodnimi napravami, dokumentnimi sistemi in poslovnimi aplikacijami za načrtovanje in evidenco. Povezava teh virov v proizvodno analitiko ni enkraten poseg, temveč projekt, ki zahteva pregled, kateri sistemi obstajajo, kateri podatki so v njih zanesljivi in kateri postopki morajo ostati nespremenjeni, da se ne prekine tekoča proizvodnja med uvedbo.

Kadar podjetje že ima delno zgrajen sistem za spremljanje proizvodnje ali nedokončan projekt, je mogoče prevzeti obstoječo rešitev po pregledu izvorne kode, arhitekture, infrastrukture in podatkov. To je pogosto hitrejša pot kot gradnja od začetka, saj se ohrani, kar že deluje, popravi pa se le tisto, kar povzroča napačne ali manjkajoče podatke v prikazu.

Zakaj je arhitektura podatkov pomembnejša od nadzorne plošče#

Nadzorna plošča je zadnji, viden del sistema, arhitektura podatkov pa določa, ali so številke na njej sploh pravilne in pravočasne. Če zajem, obdelava ali shranjevanje podatkov niso urejeni, nadzorna plošča prikaže lepo oblikovane, a napačne ali zakasnele podatke, kar je v proizvodnji lahko slabše kot brez podatkov, saj napačna odločitev deluje kot potrjena. Zato se projekt proizvodne analitike začne z ozadjem, ne z izgledom zaslona.

Del zanesljive arhitekture je ločevanje razvojnega, testnega in produkcijskega okolja, tako da se spremembe pred objavo preizkusijo, ne da bi vplivale na podatke, ki jih proizvodnja dejansko uporablja. V testnem okolju se ne uporabljajo pravi proizvodni podatki, kar zmanjšuje tveganje, da bi napaka v razvoju povzročila napačen prikaz na produkcijski nadzorni plošči, ki jo spremlja vodstvo ali izmena.

Vsaka sprememba v sistemu proizvodne analitike – nov vir podatkov, spremenjen izračun ali nov prikaz – gre skozi pregled in testiranje, preden pride v produkcijo. To velja tudi za manjše popravke, saj se napaka v izračunu kazalnika lahko nezaznano prenaša več tednov, če ni preverjena pred objavo. Discipliniran proces sprememb je zato del zanesljivosti, ne administrativna ovira.

Varnost in dostopnost podatkov v proizvodnem okolju#

Podatki o proizvodnji so last naročnika, enako velja za izvorno kodo sistema, ki jih zajema in prikazuje, zato mora biti od začetka jasno, kdo ima do njih dostop in pod kakšnimi pogoji. V proizvodnem okolju to poleg tehničnih podatkov o strojih pogosto vključuje tudi podatke, povezane z zaposlenimi, na primer o izmenah, zato je vprašanje dostopa organizacijsko enako pomembno kot tehnično.

Smiselno je, da dostop do podatkov sledi vlogam: vodja izmene vidi stanje svoje linije, vodja proizvodnje pregled čez vse linije, vodstvo pa agregirane kazalnike za odločanje na ravni podjetja. Tako razporejen dostop zmanjša tveganje, da bi kdorkoli videl več, kot potrebuje za svoje delo, hkrati pa ne ovira dnevnega odločanja na terenu. Določitev teh vlog je del zgodnje faze projekta, ne nekaj, kar se doda naknadno.

Ob zaključku projekta so dokumentacija, dostopi in gesla del primopredaje, tako da podjetje po uvedbi samo nadzoruje, kdo lahko spreminja sistem ali dostopa do podatkov. To je pomembno tudi, če se podjetje kasneje odloči zamenjati izvajalca ali prevzeti nadaljnji razvoj sistema proizvodne analitike v lastno ekipo, saj so vsi dostopi in gradiva na voljo brez odvisnosti od enega izvajalca.

Vpliv na zaposlene in organizacijo dela#

Uvedba proizvodne analitike spremeni delo vodij izmen in operaterjev, saj se odločitve, ki so prej temeljile na izkušnji in ustnem poročanju, začnejo opirati na podatke, vidne na zaslonu. To ni le tehnična sprememba, temveč zahteva usposabljanje in čas, da zaposleni novemu viru podatkov zaupajo in ga uporabljajo namesto starih postopkov ali papirnatih evidenc. Brez tega koraka sistem sicer deluje, a ostane neizkoriščen.

Pri večjih projektih je zato smiselno določiti projektnega vodjo, jasne odgovornosti posameznih ekip, roke in način komunikacije med izvajalcem in naročnikom. Enako velja znotraj podjetja: kdo potrjuje spremembe v prikazu podatkov, kdo skrbi za usklajenost s proizvodnjo in kdo je odgovoren za odziv, ko sistem opozori na odstopanje. Brez teh dogovorov se odgovornost med oddelki hitro razprši.

Ločena testna okolja omogočajo, da zaposleni preizkusijo nov način spremljanja podatkov, preden ta zamenja obstoječe poročanje, kar zmanjša tveganje motenj med uvedbo. Postopna uvedba, pri kateri se najprej pokrije en oddelek ali linija, nato pa se izkušnje prenesejo na druge, je pogosto lažje sprejeta kot enkratna zamenjava celotnega načina dela čez noč. Tak pristop tudi razkrije morebitne napake v podatkih, preden se sistem razširi na celotno proizvodnjo.

Kako izbrati izvajalca za proizvodno analitiko?#

Pri izbiri izvajalca za proizvodno analitiko je ključno, ali lahko prevzame projekt v celoti ali le posamezen sklop, na primer samo integracijo podatkov ali samo prikaz, glede na to, kaj podjetje že ima urejeno. Enako pomembno je, ali ima izkušnje s povezovanjem obstoječih proizvodnih in poslovnih sistemov prek API-jev, saj je to običajno najzahtevnejši del projekta.

Kadar podjetje že ima delno zgrajen sistem ali nedokončan projekt proizvodne analitike, je pomembno, da izvajalec zna pregledati obstoječo izvorno kodo, arhitekturo in podatke, preden predlaga nadaljevanje, namesto da avtomatično predlaga gradnjo od začetka. Tak pregled pokaže, kaj je smiselno obdržati in kaj je treba zamenjati, kar vpliva na obseg in potek nadaljnjega dela.

Ker projekt proizvodne analitike običajno zadeva proizvodnjo, IT, kakovost in vodstvo hkrati, je pomembno, da izvajalec zna uskladiti zahteve različnih oddelkov, ne le tehnično izvesti povezav. Sposobnost voditi projekt, ki presega en oddelek, je pogosto enako pomembna kot tehnično znanje, saj se prav na stičiščih med oddelki najpogosteje pojavijo nesporazumi o tem, kateri podatek je pravi.

• sposobnost prevzema celotnega projekta ali le posameznega sklopa
• izkušnje s povezovanjem obstoječih sistemov prek API-jev
• jasno določen projektni vodja in odgovornosti ekip
• ločena razvojna, testna in produkcijska okolja
• opredeljen način podpore in odprave napak po uvedbi
• dokumentacija ter predaja dostopov in gesel ob zaključku

Vzdrževanje in podpora po uvedbi#

Po uvedbi sistema proizvodne analitike je smiselno dogovoriti, kdo nadzoruje njegovo delovanje, odpravlja napake, skrbi za tehnične in varnostne posodobitve ter nadaljuje razvoj, ko se pojavijo nove potrebe. Ta odgovornost lahko prevzame izvajalec, notranja IT ekipa ali kombinacija obeh, pomembno pa je, da je dogovor jasen, preden se sistem prične uporabljati za dnevno odločanje. Nejasna razdelitev odgovornosti po uvedbi je pogost vzrok, da sistem sčasoma ostane brez vzdrževanja.

Vsak od teh razredov ima drugačno prednost obravnave, dogovorjeno v pogodbi o podpori, univerzalnih odzivnih časov v urah pa ni smiselno določati vnaprej, saj so odvisni od kritičnosti posameznega sistema za konkretno podjetje. Za proizvodno okolje je pomembno predvsem, da je izpad ali motnja v sistemu proizvodne analitike obravnavana hitro, saj med tem časom vodstvo in izmena nimata zanesljivega vpogleda v stanje proizvodnje.

Podpora po uvedbi ni le odprava napak, temveč tudi nadaljnji razvoj: dodajanje novih virov podatkov, novih prikazov ali povezav z dodatnimi oddelki, ko se izkaže, da je prvi obseg projekta koristen. Tako se sistem proizvodne analitike širi postopno, skladno s tem, kako se v podjetju spreminjajo potrebe po podatkih, namesto da se vnaprej gradi za scenarije, ki jih morda nikoli ne bo.

• 1 – izpad: sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• 2 – motnja: sistem deluje, posamezna funkcija pa ne
• 3 – napaka: manjša napaka brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• 4 – zahteva: sprememba ali nadgradnja, obseg in termin se uskladita posebej

Koliko stane uvedba proizvodne analitike?#

Cene uvedbe proizvodne analitike ne objavljamo, saj je odvisna od obsega projekta, ne od splošnega povprečja na trgu, ki za konkretno podjetje pogosto ne pove veliko. Namesto številke je smiselno najprej razjasniti, kaj vse mora sistem pokriti, koliko obstoječih sistemov je treba povezati in kako zahtevne so zahteve glede varnosti, preden se lahko govori o obsegu dela in ceni.

Pred oceno obsega dela je pogosto smiselna krajša analiza, ki projekt razčleni na sklope – na primer ločeno zajem podatkov iz strojev, povezavo s poslovnimi sistemi in izdelavo prikazov – tako da je vsak sklop mogoče oceniti in izvesti ločeno. To omogoča tudi, da se projekt začne z manjšim, obvladljivim delom, namesto da se v celoti naroči, preden je jasno, kaj vse vključuje.

Za podjetje to pomeni, da je pred pogovorom o ceni bolj koristno pripraviti pregled obstoječih sistemov, virov podatkov in oddelkov, ki naj bi sistem uporabljali, kot iskati približno številko. Jasno opredeljen obseg je tudi osnova za kasnejše dogovore o podpori in nadaljnjem razvoju, saj se cena in obseg dela ves čas projekta merita ob istih, vnaprej dogovorjenih merilih.

• obseg funkcionalnosti in število uporabniških vlog
• koliko obstoječih sistemov je treba povezati in kakšni so njihovi API-ji
• ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega
• zahteve glede varnosti, revizijske sledi in skladnosti
• obseg testiranja in ali je potreben neodvisen QA
• raven podpore po uvedbi in dogovorjeni odzivni časi