Razvoj tvornice i IT/OT arhitektura – zašto se privremene integracije obiju o glavu nakon nekoliko godina?

Zašto je ova tema danas važna

Razvoj tvornice sve se rjeđe svodi na dodavanje jednog stroja ili puštanje u rad još jedne linije kao zasebnog rješenja. Najčešće znači proširenje okruženja u kojem proizvodni sustavi, održavanje, kvaliteta, planiranje, skladište i upravljačko izvještavanje moraju razmjenjivati podatke te međusobno utječu na raspoloživost procesa. U takvom postavu arhitektura IT/OT prestaje biti tehničko pitanje „za kasnije”, a postaje projektna odluka s financijskim i organizacijskim posljedicama. Privremene integracije funkcioniraju u fazi puštanja u rad jer rješavaju trenutačni problem: brzo povezuju novi stroj, izvoze nekoliko signala u izvještaj, zaobilaze ograničenja starijeg upravljača. Posljedice dolaze nakon nekoliko godina, kada pogon pokušava povećati učinkovitost, ispuniti nove zahtjeve usklađenosti ili sigurno promijeniti način rada instalacije. Tada se pokaže da problem nije pojedini kabel ili skripta, nego izostanak dosljednih pravila komunikacije, odgovornosti i razdvajanja funkcija.

Najveća je pogreška takva rješenja promatrati kao troškovno neutralna. Ona samo odgađaju trošak i to obično u najgorem mogućem trenutku: pri proširenju, auditu, incidentu ili promjeni dobavljača. Iz perspektive projekta posljedica nije samo skuplja provedba sljedeće faze, nego i gubitak predvidljivosti. Tim više ne zna koje su ovisnosti kritične za kontinuitet proizvodnje, gdje završava odgovornost integratora, a gdje počinje odgovornost vlasnika pogona, niti koje promjene zahtijevaju ponovnu procjenu rizika. U praksi upravo ovdje počinje područje skrivenih troškova pogrešnih projektnih odluka: dodatni zastoji, ad hoc servisni radovi, ponovna preuzimanja, poteškoće u dokumentiranju promjena i sporovi oko opsega jamstva. Ako arhitektura nije opisana kao svjestan model razvoja tvornice, svaka će sljedeća faza biti opterećena tehničkim i organizacijskim dugom.

Dobar praktični test nije pitanje radi li integracija, nego može li se sigurno i predvidljivo promijeniti nakon još dvije ili tri investicijske faze. Ako nova linija zahtijeva ručno mapiranje signala na više mjesta, ako je znanje o povezivanjima raspršeno među dobavljačima, a rekonstrukcija cjelovite putanje podataka traži analizu koda upravljača, posredničkih baza i nedokumentiranih usluga, projekt je već ušao u zonu povišenog rizika. Vrijedi procjenjivati stanje prema tri mjerljiva kriterija: vremenu potrebnom za uvođenje kontrolirane promjene, mogućnosti da se nedvosmisleno odredi vlasnik svake razmjene podataka te sposobnosti da se rekonstruira utjecaj kvara ili izmjene na proizvodnju i sigurnost. Ako te tri stvari nisu jasno uhvatljive, problem se ne odnosi na komfor tima, nego na upravljivost cijelog pothvata.

Primjer iz prakse stalno se ponavlja: pogon pokreće novo proizvodno područje i radi brzog starta povezuje procesne podatke s poslovnim sustavima preko posrednih rješenja, izrađenih izvan ciljane arhitekture. Neko vrijeme sve izgleda ispravno jer je tok podataka dovoljan za izvještavanje i tekući nadzor. Problem se pojavljuje pri daljnjoj automatizaciji, integraciji s održavanjem ili pri promjeni logike rada stroja. Tada jedna izmjena u operativnom sloju utječe na izvještaje, alarme, recepte ili udaljeni pristup, a ovisnosti više nisu očite. Ako rješenje dodatno zadire u funkcije povezane sa zaustavljanjem, isključenjem energije ili blokadom ponovnog pokretanja, tema prestaje biti isključivo informatičko pitanje. Ulazi u područje funkcionalne sigurnosti i zahtijeva zasebnu analizu, uključujući provjeru jesu li narušene pretpostavke u vezi sa zaštitom od neočekivanog pokretanja. U toj se točki arhitektura IT/OT izravno dotiče analize rizika u projektu razvoja tvornice te odluka koje kasnije utječu i na opseg ocjene sukladnosti i tehničke dokumentacije.

Zato ova tema zahtijeva odluku sada, a ne nakon završetka puštanja u rad. Ne zato što svaka integracija od početka mora biti razrađena, nego zato što već na početku treba razlikovati privremeno rješenje od rješenja koje treba postati dio trajne arhitekture pogona. To razlikovanje mora imati projektne posljedice: zasebnog vlasnika odluke, uvjete za povlačenje zaobilaznog rješenja, zahtjeve za dokumentaciju i kriterije za ponovnu procjenu pri proširenju. Ako pogon planira sljedeće investicijske faze, modernizaciju strojeva ili pripremu za ocjenu sukladnosti, izostanak takvog razlikovanja gotovo uvijek povećava trošak promjene i proširuje opseg odgovornosti na strani investitora. Upravo zato arhitektura IT/OT danas nije dodatak projektu, nego jedan od uvjeta za zadržavanje kontrole nad troškom, rokovima i rizikom.

Gdje trošak ili rizik najčešće rastu

Najskuplji dio razvoja tvornice obično nisu sama sučelja između IT-a i OT-a, nego posljedice odluka donesenih „privremeno”, koje nakon nekoliko godina počnu funkcionirati kao trajna arhitektura. Takva privremena integracija kasnije se obije o glavu ne zato što je tehnički bila nesavršena, nego zato što joj nitko nije jasno odredio granice: tko je odgovoran za promjenu, koji su podaci izvorni, kako nakon kvara obnoviti konfiguraciju i u kojem trenutku privremeno rješenje treba ukloniti. U praksi trošak raste ondje gdje privremeno rješenje uđe u održavanje, proizvodnju, kvalitetu ili upravljačko izvještavanje bez formalne odluke da od tog trenutka postaje kritičan element. Za projekt to znači kasnije sporove oko budžeta i opsega, a za organizaciju i razvodnjavanje odgovornosti: kvar izgleda kao tehnički problem, iako mu je uzrok zapravo arhitektonska odluka koja nikada nije zatvorena. Koristan kriterij procjene ovdje je jednostavno pitanje: može li se nakon proširenja pogona jasno odrediti vlasnik procesa, vlasnik podataka i postupak sigurne promjene bez uključivanja „jedine osobe koja zna kako to radi”. Ako ne može, rizik je već ugrađen u projekt.

Drugo područje u kojem troškovi rastu jest izostanak razdvajanja upravljačkog sloja od sloja za razmjenu poslovnih podataka. U prvoj fazi investicije takav prečac često djeluje primamljivo: isti poslužitelj posreduje u komunikaciji sa strojem, arhivira podatke, napaja izvještaj i omogućuje udaljeni servisni pristup. Na jednoj proizvodnoj liniji to naizgled radi ispravno, ali u sljedećim fazama proširenja svaka promjena jednog cilja utječe i na ostale. Nadogradnja koju nameće poslovni sustav može narušiti kontinuitet proizvodnje, a potreba za bržim izvještavanjem može dovesti do zahvata u konfiguraciju uređaja koji su dotad radili stabilno. Tada skriveni troškovi pogrešnih projektnih odluka ne znače samo dodatnu nabavu opreme ili usluga integratora. Mnogo su bolniji troškovi zastoja, ponovnih ispitivanja, noćnog rada tijekom implementacije te potrebe za ponovnim prikupljanjem znanja koje nigdje nije zapisano. Iz perspektive upravljanja projektom razumno minimum je procijeniti može li kvar ili promjena u informatičkom dijelu zaustaviti operativnu funkciju stroja ili linije. Ako je odgovor potvrdan, arhitekturu treba korigirati bez obzira na to što „zasad radi”.

Tipičan primjer pojavljuje se pri povezivanju novih strojeva na postojeću infrastrukturu pogona. Dobavljač brzo pušta uređaj u rad jer su potrebni preuzimanje i početak proizvodnje, pa komunikaciju sa sustavima pogona rješava preko dodatnog računala, skripte za izvoz datoteka ili ručno mijenjane mape signala. Nakon godinu dana dolazi još jedan stroj, nakon dvije godine mijenja se nadređeni sustav, a nakon tri godine pokaže se da nitko ne može jednoznačno opisati koje su poruke kritične za proces, koje služe samo za izvještavanje, a koje su važne za dijagnostiku ili sljedivost serije. U tom trenutku tema djelomično prelazi i u područje izrade uputa za uporabu strojeva, jer ako operater, održavanje ili servis nemaju dokumentirana pravila postupanja u slučaju prekida komunikacije, ručnog zaobilaženja ili obnove parametara nakon zamjene komponente, problem više nije isključivo informatički. On postaje dio organizacije sigurne uporabe i kasnije odgovornosti za način korištenja i provedene izmjene.

Tek se u toj fazi vidi zašto se to pitanje vraća i kod ocjene sukladnosti, tehničke dokumentacije i planiranja budžeta za promjene. Ako integracija utječe na funkcije stroja, logiku blokada, način potvrđivanja stanja ili informacije koje se prenose korisniku, može biti potrebna ponovna analiza rizika i provjera odgovara li dokumentacija i dalje stvarnom rješenju. Opseg te procjene ovisi o prirodi promjene, pa se to ne može pošteno presuditi jednom univerzalnom rečenicom, ali upravo su zato privremena rješenja tako skupa: otežavaju utvrđivanje što je stvarno promijenjeno i kakve su pravne i eksploatacijske posljedice. Za tim koji donosi odluke praktičan kriterij glasi ovako: ako se promjena u integraciji ne može opisati u dokumentaciji konfiguracije, postupku ispitivanja i pravilima uporabe bez pozivanja na neformalno znanje, projekt je već ušao u zonu u kojoj ne raste samo tehnički trošak, nego i odgovornost investitora, voditelja projekta i osoba koje rješenje puštaju u rad.

Kako temi pristupiti u praksi

U praksi pitanje nije treba li brže integrirati IT i OT, nego gdje povući granicu između privremenog rješenja i arhitektonskog duga koji će za nekoliko godina blokirati razvoj tvornice. Privremena povezivanja najčešće nastaju pod pritiskom puštanja u rad: treba brzo izvući podatke iz stroja, dodati novu liniju, povezati sustav kvalitete s proizvodnim zapisima ili osigurati udaljeni servisni pristup. Problem počinje onda kada rješenje uvedeno „privremeno” postane temelj za sljedeće projektne odluke. Tim gubi jasan raspored odgovornosti, a svako proširenje zahtijeva ponovno rekonstruiranje znanja iz korespondencije, lokalnih postavki i prakse operatera. To više nije sitna tehnička neugodnost, nego čimbenik koji utječe na raspored, trošak promjene i sposobnost da se dokaže tko je i na temelju čega dopustio da se određeno rješenje pusti u rad.

Zato ispravan pristup počinje arhitektonskom odlukom, a ne odabirom alata. Menadžer ili vlasnik područja trebao bi zahtijevati da svaka nova integracija ima definiran operativni cilj, odgovornu osobu s obje strane granice IT/OT te uvjete održavanja nakon puštanja u rad. Ako nije jasno tko je odgovoran za izvor podataka, tko odobrava promjenu konfiguracije, tko testira učinke na proces i tko odlučuje o izvanrednom načinu rada, projekt zapravo prenosi rizik na fazu eksploatacije. Upravo tu prirodno počinje uloga voditelja projekta u IT/OT odlukama: ne kao koordinatora rokova, nego kao osobe koja nameće razrješenje odgovornosti prije nego što se improvizacija unese u proračun i raspored kao „brzo zaobilazno rješenje”. Praktičan kriterij procjene je jednostavan: ako se planirana integracija ne može održavati nakon promjene dobavljača, zamjene upravljača ili proširenja linije bez sudjelovanja autora izvornog zaobilaznog rješenja, onda to nije privremeno rješenje, nego budući trošak projekta.

Dobar test je situacija proširenja postojeće linije dodatnom radnom stanicom, koja treba slati podatke nadređenom sustavu i istodobno reagirati na stanja iz dijela koji već radi. Ako tim odluči izravno povezati signale i neformalno prevoditi podatke „jer će tako biti brže”, u početku sve može raditi ispravno. No s vremenom se pojavljuju nuspojave: teže je utvrditi proizlazi li pogreška iz logike stroja, komunikacijskog sloja ili aplikacije za izvještavanje; prihvatna ispitivanja obuhvaćaju samo standardne scenarije; modernizacija jednog elementa nameće korekcije na nekoliko mjesta istodobno. Tada izlaze na vidjelo i skriveni troškovi pogrešnih projektnih odluka: dodatni zastoji zbog dijagnostike, skupa prisutnost integratora pri svakoj promjeni, sporovi oko opsega jamstva i kašnjenja u sljedećim fazama investicije. Zato vrijedi mjeriti ne samo vrijeme puštanja u rad, nego i broj integracijskih točaka koje zahtijevaju ručnu konfiguraciju, vrijeme potrebno za analizu incidenta nakon promjene te broj promjena koje treba testirati cjelovito umjesto lokalno.

Tek u tom kontekstu ima smisla pozvati se na zahtjeve sigurnosti i usklađenosti. Ako integracija utječe na radna stanja stroja, blokade, potvrde signala, slijed pokretanja ili zaustavljanja, ona prestaje biti neutralan informatički dodatak. Ovisno o prirodi promjene, to može pokrenuti potrebu za ponovnom procjenom rizika, ažuriranjem tehničke dokumentacije te provjerom odgovara li način eksploatacije i dalje pretpostavkama usvojenima za taj stroj ili liniju. To je posebno jasno ondje gdje integracijski sloj počinje posredno utjecati na uvjete sigurnog pristupa, isključenja energije ili sprječavanja neočekivanog pokretanja. U takvom slučaju arhitektonska odluka prelazi iz područja provedbene praktičnosti u područje pravne i tehničke odgovornosti. Ako tim ne može pokazati koje veze imaju isključivo informativni karakter, a koje utječu na ponašanje stroja, to je signal da temu treba izvući iz razine „integracije sustava” i tretirati je kao promjenu bitnu za sigurnost, proračun i odgovornost osoba koje odobravaju rješenje.

Na što paziti pri provedbi

Najviše problema ne proizlazi iz same IT/OT integracije, nego iz toga što se u projektu ona tretira kao brzo sredstvo za pokretanje nove funkcije, a ne kao trajan element arhitekture IT/OT tvornice. Upravo tada se privremene veze osvete nakon nekoliko godina: pri proširenju linije, zamjeni upravljača, promjeni dobavljača nadređenog sustava ili tijekom revizije sigurnosti strojeva i proizvodnih linija pokaže se da nitko ne može jednoznačno navesti vlasnika sučelja, pravila njegova rada ni posljedice kvara. Za projekt to ne znači samo trošak tehničkog duga, nego i organizacijski trošak: više usklađivanja, dulja cjelovita testiranja, složenija preuzimanja i veći rizik da će se kašnjenje pojaviti tek na kraju, kada je raspored već najmanje fleksibilan. Tu tema prirodno prelazi u područje skrivenih troškova pogrešnih projektnih odluka, jer izvor problema nije pojedinačna izvedbena pogreška, nego odluka da se kvalitetna arhitektura odgodi za kasnije.

Pri provedbi zato vrijedi procjenjivati rješenje ne prema tome hoće li „raditi sada”, nego može li se održavati i sigurno mijenjati na predvidljiv način. Praktičan kriterij je jednostavan: ako planirana integracija nema opisan opseg odgovornosti, način rada u slučaju kvara, pravila verzioniranja te postupak testiranja nakon promjene, onda još nije spremna za proizvodnu primjenu, čak i ako radi na ispitnom mjestu. To je osobito važno ondje gdje isto sučelje treba podržati sadašnju fazu investicije i buduće proširenje. Razvoj tvornice gotovo uvijek povećava broj ovisnosti među sustavima, a improvizirana rješenja najlošije funkcioniraju upravo tada kada raste broj iznimaka, zaobilaznih rješenja i lokalnih dogovora. Iz perspektive voditelja projekta to znači potrebu za ranim razrješenjem tko odobrava granične odluke između automatike, održavanja, informatike i usklađenosti, jer se bez toga odgovornost razvodnjava upravo ondje gdje kasnije nastaje najveći spor oko troška i roka.

Tipičan praktičan primjer je dodavanje razmjene podataka između linije i sustava za izvještavanje preko posredničke skripte ili nedokumentirane usluge pokrenute na poslužitelju koji „već postoji u pogonu”. U fazi puštanja u rad takvo se rješenje čini razumnim: ne zahtijeva promjene na strani dobavljača stroja, skraćuje implementaciju i omogućuje brzo pokazivanje poslovnog učinka. Problem se pojavljuje kasnije. Nakon ažuriranja operacijskog sustava, promjene adresiranja, vraćanja sigurnosne kopije ili zamjene uređaja nitko više nije siguran odgovara li logika mapiranja signala i dalje stvarnom procesu. Ako taj mehanizam sudjeluje u potvrdama, blokadama, redoslijedu naloga ili uvjetima pokretanja, kvar više nije samo informatički incident, nego počinje utjecati na raspoloživost linije, kvalitetu proizvodnje i odgovornost za puštanje rješenja u rad. Tada se tema prirodno pretvara u analizu rizika i utjecaj promjena na sigurnost u projektu razvoja tvornice, jer treba procijeniti ne samo vjerojatnost kvara, nego i posljedice pogrešne informacije, pogrešnog slijeda i pogrešne reakcije operatera.

Tek u tom kontekstu ima smisla pozivati se na formalne zahtjeve. Ako integracijski sloj ostaje isključivo informativan i to se može tehnički dokazati, opseg obveza bit će drukčiji nego u situaciji kada on utječe na ponašanje stroja ili linije. Ako, međutim, utječe na logiku rada, uvjete pokretanja, zaustavljanja, potvrde ili zaobilaženja, tada implementaciju treba tretirati kao promjenu s tehničkim, a potencijalno i sigurnosnim značenjem, a ne kao obično proširenje sustava. To može značiti potrebu za ponovnom provjerom pretpostavki procjene rizika, tehničke dokumentacije i uvjeta sukladnosti prihvaćenih za to rješenje. U praksi sigurna odluka ne glasi „može li se to povezati”, nego „hoćemo li nakon implementacije moći dokazati što to sučelje radi, tko je za njega odgovoran i kako upravljamo promjenom”. Ako odgovor nije jednoznačan, trošak odgođene arhitektonske odluke obično će se vratiti pri sljedećoj modernizaciji, certifikaciji ili incidentu, a tada to više neće biti samo tehnički, nego i upravljački problem.