Namjenski softver za industriju – kada gotov MES/ERP sustav prestane biti razuman izbor

Gotov sustav za upravljanje proizvodnjom ili ERP može biti razuman izbor, ali samo ako se stvarni tijek proizvodnje može vjerno prikazati bez bitnih pojednostavnjenja. U suprotnom, sustav uređuje evidenciju nauštrb upravljivosti procesa. To je trenutak u kojem pitanje kataloga funkcija prestaje biti važno. Treba procijeniti hoće li pogon i dalje upravljati vlastitom proizvodnjom, kvalitetom i održavanjem, ili će rad početi prilagođavati ograničenjima alata. Ako se ključne odluke, iznimke i blokade uglavnom odvijaju izvan sustava, namjenski softver za industriju nije hir. On postaje način da se ponovno uspostave dosljednost podataka, odgovornost i operativna kontrola.

Ne može se svaka proizvodnja vjerodostojno uklopiti u gotov sustav

Gotov sustav za upravljanje proizvodnjom ili ERP dobro funkcionira ondje gdje je proces doista ponovljiv, odgovornosti su jasno određene, a model podataka ne iskrivljuje sliku pogona. U takvim uvjetima standardizacija uređuje tok informacija, smanjuje broj lokalnih tumačenja i omogućuje donošenje odluka na temelju dosljednog zapisa događaja. Problem se pojavljuje prije nego što dođemo do razine funkcija koje nedostaju. Počinje ondje gdje se stvarni tijek proizvodnje, kvalitete, održavanja i planiranja više ne može uklopiti u logiku sustava bez gubitaka za proces.

To je granica između razumne standardizacije i gubitka operativne kontrole. Ako organizacija počne zaobilaziti vlastiti proces kako bi se podaci „poklapali u sustavu”, informacijska arhitektura prestaje služiti proizvodnji. Počinje je deformirati. Dio pravila može se sigurno ujednačiti konfiguracijom ili procedurom, ali postoje i tehnološke ovisnosti, kontrolne točke i putovi odgovornosti koji se ne smiju razvodniti bez štete za kvalitetu proizvoda, sigurnost procesa ili sljedivost odluka. Zato je rasprava „gotovo ili vlastito” obično pogrešno postavljena. Točnije pitanje glasi: koji su elementi procesa zajednički standard, a koji čine bit prednosti pogona, izvor rizika ili područje obveza usklađenosti te moraju biti vjerno prikazani.

U praksi najskuplji nisu moduli koji nedostaju, nego zaobilazna rješenja koja potiho postaju svakodnevni način rada. Tablice koje se vode uz sustav, ručno prepisivanje podataka između smjene i ureda, bilješke operatera, neformalno usuglašavanje iznimaka i paralelni tokovi informacija nisu sitna neugodnost. To je signal da model upravljanja procesom puca. Tada vrijedi mjeriti ne broj funkcija, nego broj ručnih točaka prepisivanja podataka između proizvodnje, kvalitete, održavanja i planiranja, broj kritičnih iznimaka koje se obrađuju izvan sustava te udio operativnih odluka donesenih na temelju podataka koji ne potječu izravno iz izvornog registra. Ako ti pokazatelji rastu, problem obično nije posljedica loše konfiguracije, nego pogrešne pretpostavke da se proces može bez troška prilagoditi alatu.

To se jasno vidi u pogonima u kojima tijek naloga ne ovisi samo o tehnološkoj ruti, nego i o stvarnom stanju stroja, rezultatima međufazne kontrole, odobrenjima materijala, šarži ulaznog materijala, parametrima podešavanja i odlukama koje pod vremenskim pritiskom istodobno donosi nekoliko organizacijskih jedinica. Ako gotov sustav ne može održati te ovisnosti u jednom vjerodostojnom lancu podataka, istina o procesu raspada se na nekoliko mjesta. Jedan dio ostaje u sustavu, jedan uz stroj, jedan u dokumentaciji kvalitete, a jedan u znanju ljudi. Takvo stanje otežava mapiranje proizvodnog procesa, komplicira odgovornost izvršitelja provedbe i povećava rizik projekta pri integraciji s automatizacijom te sustavima koji utječu na sigurnost strojeva. Namjenski softver ima smisla ne onda kada pogon želi „nešto svoje”, nego onda kada treba očuvati jedinstvo procesa, izvornih podataka i odluka ondje gdje bi pojednostavnjenje značilo stvarni gubitak kontrole.

Iz perspektive usklađenosti i operativnog nadzora ta je razlika od presudne važnosti. Ako ključna pravila i kontrolne točke postoje isključivo u praksi tima, a sustav ih ne nameće ili ih barem ne prikazuje jednoznačno, odgovornost i mogućnost naknadne provjere postaju uvjetne. U nekim industrijama to će prije svega biti problem kvalitete i mogućnosti rekonstrukcije tijeka šarže, a u drugima i pitanje sektorskih zahtjeva, sljedivosti, upravljanja promjenama ili granica odgovornosti između korisnika pogona, integratora i dobavljača softvera. Zato odluku o tome treba li proces podrediti sustavu ili sustav procesu ne treba temeljiti na prezentaciji funkcija, nego na poštenoj analizi iznimaka. Tek tada postaje jasno koje su od njih organizacijski kaos, a koje odražavaju stvarne tehnološke, informacijske i sigurnosne zahtjeve.

Trošak raste ondje gdje sustav ne vidi stvarni rizik

Neusklađenost sustava najviše košta ne u jednostavnom tijeku radnih naloga ni u dnevnim izvještajima, nego na spoju proizvodnje, kvalitete, održavanja i sigurnosti procesa. Upravo se ondje odluka mora donijeti brzo, dokumentirati i temeljiti na punom kontekstu: trenutačnom stanju stroja, parametrima serije, povijesti intervencija, statusu odobrenja kvalitete i važećim blokadama. Ako gotovi MES ili ERP vidi samo dio te slike, trošak se ne svodi na neugodnost za korisnika. Pojavljuje se operativna varijabilnost. Različite smjene donose slične odluke na temelju različitih podataka, iznimke se rješavaju diskrecijski, a odgovornost se razvodnjava između sustava, procedure i prakse u pogonu.

Najvažniji problem počinje onda kada sustav ne odražava stvarni slijed radnji, uvjete blokade, verzioniranje tehnoloških parametara ili odgovornost za odobrenje odstupanja. U evidenciji sve može izgledati ispravno, dok se izvršenje odvijalo drukčije. Nastaje jaz između događaja i njegova digitalnog traga. To nameće vrlo konkretne projektne odluke: trebaju li kritične blokade procesa djelovati sustavno ili samo proceduralno; jesu li podaci sa strojeva operativni dokaz ili pomoćni materijal; te trebaju li se iznimke obrađivati kroz projektirani tijek odlučivanja ili prepustiti diskrecijskoj procjeni. Ako se pogon oslanja na ručne dopise, dodatne tablice ili sučelja koja zahtijevaju stalnu intervenciju čovjeka, vjerodostojnost podataka ne treba procjenjivati prema tome može li se generirati završni izvještaj, nego prema tome može li se bez spora rekonstruirati tijek jedne nesukladnosti, reklamacije ili zastoja linije.

Poseban rizik otkriva se u pogonima s razvijenim strojnim parkom, gdje sustav mora surađivati s automatikom, operaterskim radnim mjestima i kontrolno-mjernim uređajima. Ako je integracija s automatikom i uređajima djelomična, prikupljanje procesnih podataka nedosljedno, a povijest promjena raspršena između upravljača, panela, proizvodne baze i servisnih bilješki, sljedivost serije i genealogija proizvoda postaju uvjetne. Slično izgleda i upravljanje tehnološkom promjenom. Promjena recepture, praga tolerancije ili logike prebacivanja može biti formalno odobrena, ali bez dosljednog verzioniranja i arhiviranja kasnije se ne može dokazati koja je konfiguracija stvarno bila na snazi u trenutku događaja. To nije pitanje estetike arhitekture sustava, nego ponovljivosti, utvrđivanja korijenskih uzroka i granica odgovornosti između proizvodnje, održavanja, kvalitete i dobavljača integracije.

Trošak takve neusklađenosti rijetko je vidljiv u proračunu implementacije. Otkriva se kasnije kao dijagnostički zastoji, porast ručnog rada, reklamacije, sporovi o uzroku događaja i gubitak mogućnosti jednoznačne rekonstrukcije tijeka procesa. Zato pri ocjeni rješenja nije dovoljno pitati podržava li sustav „proizvodnju”. Treba provjeriti koliko sučelja zahtijeva ručnu korekciju, koliko se kritičnih parametara ne verzionira automatski ili ne arhivira dosljedno te koliko vremena traje rekonstrukcija pojedinačnog operativnog incidenta. Ako odgovor glasi: dugo, nedosljedno i uz sudjelovanje nekoliko neovisnih izvora, problem se ne tiče udobnosti korisnika, nego upravljivosti rizika. Upravo je ovdje vlastito rješenje ili barem namjenski sloj nad gotovim sustavom često opravdan: ne zato da bi se bolje izvještavalo o prošlosti, nego da bi se poduprle sigurne operativne odluke u trenutku kada pogon radi pod pritiskom vremena i odgovornosti.

Iz perspektive usklađenosti to znači još jedno. Ondje gdje softver utječe na tijek odluka važnih za kvalitetu, sljedivost ili sigurnost procesa, opseg kritičnih funkcija trebao bi proizlaziti iz stvarne analize rizika, a ne iz kataloga standardnih modula. To se posebno odnosi na integraciju sa strojevima, obradu izvanrednih stanja te mjesta na kojima sustav treba nametnuti određeni redoslijed radnji ili blokirati prijelaz u sljedeću fazu. U takvim područjima vrijedi odvojiti evidencijske funkcije od onih koje postaju element operativne kontrole i zahtijevaju čvršće projektno opravdanje, također i u kontekstu sigurnosti strojeva i odgovornosti integratora.

Najprije projekt odluke, zatim kod

Razumna odluka o razvoju sustava u pogonu ne počinje popisom funkcija, nego mapom operativnih odluka koje softver treba podupirati ili nametati. Treba utvrditi tko donosi odluku, na temelju kojih podataka, u kojem roku i s kakvim učinkom na proizvodnju, kvalitetu, sljedivost ili sigurnost procesa. Tek se na toj podlozi vidi obuhvaća li gotovi MES ili ERP srž problema ili samo naknadno uređuje evidenciju. Ako nije kritična sama registracija događaja, nego blokada pokretanja sljedeće operacije, uvjet za odobrenje serije, potvrda usklađenosti postavki stroja ili obrada odstupanja, pitanje ne glasi „ima li sustav to”, nego „može li nametnuti ispravnu odluku u pravom trenutku”.

Takav način razmišljanja unosi red i u projektiranje arhitekture. U praksi se najčešće pokazuje najboljim hibridni pristup. Standardni ERP ili sustav za upravljanje proizvodnjom treba ostati ondje gdje je proces zajednički, ponovljiv i dobro opisan zrelim modelom podataka: u planiranju, obračunu proizvodnje, skladišnom poslovanju te osnovnoj evidenciji naloga i serija. Namjenski sloj ima smisla kada preuzima logiku koja je kritična za konkretan pogon: integraciju sa strojevima, validaciju događaja iz više izvora, obradu iznimki, putove odobravanja, revizijski trag te povezivanje odluka s konkretnom serijom, strojem i odgovornom osobom. No preduvjet uspjeha jest prethodno jasno odrediti granice odgovornosti. Tim mora razlučiti što pripada tehnološkom procesu i ostaje na strani automatike ili upravljanja, što je domena ERP-a ili sustava za upravljanje proizvodnjom, što provodi integracijski sloj, a što i dalje mora ostati u organizacijskim procedurama.

Bez takve podjele nastaje skupa improvizacija. Isti uvjet zna biti zapisan na nekoliko mjesta, iznimke se rješavaju ručno, a nakon nekoliko mjeseci više nitko ne može jednoznačno reći koji je sustav odgovoran za odluku koja blokira ili pušta proces dalje. Dobar namjenski projekt zato se ne svodi na preslikavanje gotovog rješenja u manjem opsegu. Njegova je zadaća zatvoriti konkretnu prazninu u odlučivanju. Zato već u fazi projekta vrijedi sastaviti popis kritičnih odluka koje danas nemaju sustavnu podršku ili prisilu, a zatim ga usporediti s brojem procesnih iznimki koje rješenje mora obraditi od prvog puštanja u rad. To je važnije od opsežne specifikacije ekrana.

Praktičan primjer je jednostavan. Gotov sustav može ispravno obračunavati proizvodnju, potrošnju materijala i skladišne primitke, a da pritom ne obuhvaća specifične blokade kvalitete povezane s uvjetnim puštanjem serije. Serija može biti formalno proizvedena i knjižena, ali unatoč tome ne bi smjela prijeći u sljedeću fazu bez potvrde određenih rezultata ispitivanja, stanja preinake linije ili uklanjanja odstupanja iz prethodne operacije. Ako se takav uvjet danas nadzire telefonom, tablicom ili potpisom na ispisu, to nije pitanje estetike procesa, nego praznina u upravljanju odgovornošću. U takvoj situaciji pregradnja cijelog ERP-a ili sustava za upravljanje proizvodnjom obično nema opravdanja. Dovoljan je namjenski sloj koji preuzima podatke sa strojeva i iz izvornih sustava, provjerava potpunost događaja, pokreće odgovarajući put odobravanja i nadređenom sustavu prosljeđuje jednoznačan status serije. Standard ostaje standard, a kritična logika zapisuje se ondje gdje se njome može stvarno upravljati i održavati.

Ako pogon još nema troškovne podatke, ne treba ih nagađati. Dovoljno je početi mjeriti koliko vremena mjesečno odlazi na ručna zaobilaženja, dodatna usklađivanja, korekcije serija i provjeru odstupanja između sustava i stvarnog stanja procesa. Takav materijal omogućuje razlikovati opravdan namjenski sloj od projekta koji se radi za svaki slučaj. Također olakšava ispravnu podjelu uloga na poslovnoj strani. O opsegu logike zapisane u sustavu ne bi smjeli odlučivati isključivo IT odjel ni sam integrator, nego zajednički proizvodnja, kvaliteta, održavanje, osobe odgovorne za digitalizaciju te, gdje je to važno, suradnja integratora, software housea i odjela održavanja te sigurnost strojeva i operativna usklađenost.

S gledišta projektne odgovornosti to ima još jednu posljedicu. Što softver dublje ulazi u uvjete prijelaza procesa, blokade operacija, ispravnost slijeda radnji ili podatke koji dolaze izravno sa stroja, to ga je manje moguće promatrati kao neutralan informatički dodatak. U tom su opsegu potrebne jasno definirane projektne pretpostavke, opis granica djelovanja i održavanja, pravila upravljanja promjenama te provjerljiv trag o tome tko je i na temelju čega odobrio kritičnu logiku. Zato prije pisanja prve linije koda vrijedi odobriti ne samo funkcionalne zahtjeve, nego prije svega nacrt odluka: što sustav mora nametnuti, što ne smije dopustiti učiniti i u kojoj točki čovjek ostaje posljednja instanca odgovornosti.

Usklađenost je posljedica dobrog projekta, a ne ukras nakon implementacije

U industrijskom pogonu softver nije neutralan dodatak procesu, nego dio načina na koji se proces provodi. Može određivati redoslijed radnji, blokirati prijelaz u sljedeću fazu, nametati potpunost podataka, usmjeravati put odobravanja i odlučivati o tome može li se nakon nekog događaja rekonstruirati tijek odluka i odgovornost. Zbog toga usklađenost ne počinje dopisivanjem formalnih zahtjeva na kraju implementacije. Počinje projektom u kojem se svjesno određuje koje odluke sustav donosi sam, koje samo podržava, koje podatke smatra obvezujućima i tko je vlasnik pravila, iznimki i promjena.

Ako se takav red ne uspostavi već u fazi arhitekture rješenja, kasnije pozivanje na zahtjeve kvalitete, sigurnosti procesa ili obveze dokumentiranja postaje tek prividna aktivnost. To je osobito važno kada sustav utječe na odluke bitne za kvalitetu proizvoda, sigurnost procesa ili suradnju sa strojevima i opremom. U tom opsegu zahtjeve usklađenosti treba razumjeti operativno: kao potrebu za dosljednim radom, sljedivošću odgovornosti, kontrolom promjena i primjerenošću rješenja stvarnoj primjeni. Nije riječ samo o tome da je funkcija dostupna, nego da se može dokazati zašto radi upravo tako, tko je odobrio njezinu logiku i kako se procjenjuju učinci njezinih izmjena.

Najviše problema obično se ne otkriva pri puštanju u rad, nego nakon nekoliko mjeseci eksploatacije. Tvornica uvodi novu varijantu proizvodnje, mijenja kriterije prihvaćanja, povezuje dodatno radno mjesto ili dio odgovornosti prenosi s operatera na sustav. Ako prethodno nije utvrđeno koje klase odluka i zapisa moraju ostavljati revizijski trag, brzo dolazi do spora oko toga čija je promjena utjecala na kvalitetu, zastoj ili neispravnu reakciju sustava. Tek tada postaje vidljiva razlika između rješenja koje radi i rješenja kojim se može upravljati. U ovom drugom unaprijed je jasno koji elementi logike zahtijevaju formalni postupak odobravanja, tko nadzire referentne podatke, tko održava integraciju s automatizacijom i je li projektna dokumentacija dovoljna za reviziju, održavanje te sigurno preuzimanje sustava od strane drugog izvođača.

• koje odluke sustav donosi ili suoblikuje u području kvalitete, sigurnosti i suradnje sa strojem,
• koji događaji, promjene i odobrenja moraju ostavljati obnovljiv trag,
• tko je vlasnik poslovnih pravila, podataka i iznimaka te tko odobrava njihove promjene.

Tek nakon takvog uređenja ima smisla projekt povezati s pravnim i normativnim zahtjevima koji vrijede za konkretan pogon, proizvod, industrijsku granu i način integracije sa strojevima ili uređajima. U poljskim i europskim okolnostima pitanje ne glasi samo radi li rješenje, nego može li organizacija dokazati zašto radi na taj način, na temelju čega su pravila odobrena i kako se upravlja promjenom bez slabljenja sljedivosti odgovornosti. Opseg te analize uvijek ovisi o primjeni: drukčije se procjenjuje izvještajni sustav, drukčije logika koja utječe na tijek procesa, a drukčije integracija koja zadire u rad stroja, procjenu rizika ili opseg odgovornosti integratora.

Zaključak je jednostavan. Namjenski softver za industriju opravdan je kada uređuje odgovornosti i smanjuje rizik upravo ondje gdje bi gotov sustav za upravljanje proizvodnjom ili ERP zahtijevao skupe kompromise u logici procesa, nadzoru nad promjenama ili sljedivosti aktivnosti. Dakle, nije riječ o tome da se sve gradi od nule, nego o takvom razdvajanju standarda i kritične logike da sustav podupire stvarni proces u pogonu umjesto da ga pojednostavljuje nauštrb kvalitete, sigurnosti i sljedivosti odgovornosti.