Kako organizirati suradnju integratora, softverske tvrtke i odjela održavanja u jednom projektu?

Zašto je ova tema danas važna

Suradnja integratora, softverske kuće za industriju i odjela održavanja više nije pitanje organizacijske praktičnosti. U praksi danas odlučuje o tome može li se projekt pustiti u rad bez sporova oko opsega, hoće li promjena u softveru zaustaviti tehničko preuzimanje i hoće li pogon nakon implementacije moći sigurno održavati rješenje. Što se više procesne logike prenosi u softverski sloj, a manje ostaje u gotovim funkcijama upravljača i uređaja, to su granice odgovornosti važnije. Ako se ne odrede na početku, trošak projekta obično ne raste linearno, nego kroz dorade koje se rade na pogrešnom mjestu: integrator ispravlja sučelja, softverska kuća preoblikuje poslovnu logiku, a održavanje tek na kraju otkriva eksploatacijske zahtjeve koje nitko ranije nije zapisao.

To je i budžetsko, a ne samo tehničko pitanje. U mnogim projektima pitanje suradnje među stranama vrlo brzo prelazi u pitanje što je zapravo namjenski softver za industriju u investicijskom budžetu: dio investicije, trošak održavanja ili kombinacija oboje. Ako arhitektura rješenja predviđa da će ključne funkcije procesa, izvještavanja, receptura, sljedivosti serija ili integracije sa sustavima u pogonu nastati izvan standardnog opsega automatike, to treba prepoznati prije narudžbe, a ne nakon prvog prototipa. Praktičan kriterij je jednostavan: ako zbog nepostojanja jednog vlasnika odluka za granicu između automatike, aplikacije i eksploatacije nije moguće jednoznačno dodijeliti zahtjeve, testove i troškove promjena, projekt je već ušao u zonu povišenog rizika i zahtijeva korekciju modela suradnje.

To se najlakše vidi na primjeru modernizacije linije u kojoj integrator odgovara za upravljanje i puštanje u rad, softverska kuća za aplikacijski sloj i razmjenu podataka, a održavanje kasnije treba preuzeti sustav za neprekidan rad. Ako se odjel održavanja uključi tek pri preuzimanju, obično se otkrivaju problemi koji nisu „kvarovi”, nego nedostaci u odlučivanju: nepostojanje postupka oporavka nakon kvara, nepostojanje zahtjeva za servisne račune, neodređeni prozori za ažuriranja, nepredviđena ovisnost o vanjskom dobavljaču ili nedovoljna mogućnost praćenja pogrešaka. Tada se spor više ne vodi o kvaliteti koda ili ispravnosti upravljačkog ormara, nego o tome tko treba snositi trošak prilagodbe sustava stvarnim uvjetima u pogonu. U tom se trenutku tema prirodno povezuje sa skrivenim troškovima projekta i usklađenosti, jer kašnjenje preuzimanja ili kasna promjena sigurnosnih funkcija, tehničke dokumentacije ili validacije često proizlazi upravo iz loše organizirane suradnje, a ne iz pojedinačne izvedbene pogreške.

Aspekt usklađenosti pojavljuje se kada podjela poslova utječe na svojstva proizvoda, funkcije povezane sa sigurnošću, dokumentaciju ili način stavljanja rješenja u uporabu. Ne aktivira svaka integracija aplikacije sa strojem iste obveze, ali već sama nejasnoća oko toga tko je odgovoran za opis funkcija, upravljanje promjenama i cjelovitost dokumentacije signal je upozorenja. To se posebno odnosi na projekte koji se provode u vlastitom pogonu, modernizacije koje se izvode fazno te rješenja izrađena za vlastite potrebe, gdje granica između „radova održavanja” i izrade ili bitne preinake može biti pravno važna. Zato odluku o modelu suradnje treba donijeti ne onda kada se pojavi prvi sukob, nego onda kada se definira opseg: tko opisuje operativne zahtjeve, tko odobrava arhitekturu, tko je odgovoran za međuslojna ispitivanja i tko preuzima sustav nakon puštanja u rad zajedno sa stvarnom sposobnošću njegova održavanja.

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

U projektima koje zajednički vode integrator, softverska kuća i odjel održavanja, trošak rijetko raste zbog jedne velike pogreške. Obično se povećava na dodiru odgovornosti, dakle ondje gdje nitko nema punu obvezu dovesti stvar do kraja. Najskuplje nisu tehničke pogreške same po sebi, nego odluke odgođene ili donesene bez jasno određenog vlasnika: nepostojanje usuglašene komunikacijske arhitekture, neopisane granice između upravljačke logike i aplikacijskog sloja, neodređen način ispitivanja nakon promjene te preuzimanje sustava u eksploataciju bez stvarne sposobnosti održavanja. U praksi to znači dorade koje se rade tek nakon puštanja u rad, sporove oko ugovornog opsega i prebacivanje odgovornosti za zastoje u fazu u kojoj je svaka promjena najskuplja. Jednostavan kriterij za procjenu situacije jest pitanje može li se za svaku kritičnu funkciju odrediti jedna strana odgovorna za zahtjev, jedna za izvedbu i jedna za preuzimanje. Ako odgovor glasi „to ovisi”, projekt je već opterećen organizacijskim rizikom.

Drugo područje gubitaka pojavljuje se kada se projektne odluke donose bez sudjelovanja održavanja ili obratno: kada održavanje nameće rješenja pogodna za servis, ali neusklađena s arhitekturom sustava. Integrator obično gleda kroz prizmu puštanja u rad i suradnje s uređajima, softverska kuća za industriju kroz prizmu poslovne logike i sučelja, a održavanje kroz prizmu raspoloživosti, dijagnostike i vremena potrebnog za povrat rada. Ako se te perspektive ne usklade u fazi definiranja zahtjeva, kasnije se vraćaju kao troškovi izmjena: dodatni signali, preinake ovlasti, izostanak bilježenja događaja potrebnih za dijagnostiku, nemogućnost sigurnog provođenja ažuriranja ili nepostojanje postupka za zaobilaženje kvara. To je trenutak u kojem se tema prirodno prebacuje na ulogu voditelja inženjerskog projekta, jer problem više nije pojedinačna tehnička odluka, nego upravljanje međuovisnostima, rokovima usuglašavanja i odgovornošću za eskalaciju.

Tipičan praktični primjer je implementacija u kojoj nadređena aplikacija treba upravljati nalozima, recepturom i izvještavanjem, a integrator je odgovoran za upravljač, pogone i sekvencu stroja. Ako je granica odgovornosti opisana isključivo funkcionalno, bez navođenja prijelaznih stanja, uvjeta pogreške i ponašanja nakon gubitka komunikacije, svaka će strana izgraditi vlastite „sigurne” pretpostavke. Softverska kuća pretpostavit će da izostanak potvrde znači ponovno slanje naredbe, integrator će polaziti od toga da je naredba jednokratna, a održavanje će dobiti sustav koji se ne može dijagnosticirati tijekom zastoja. Posljedica je predvidljiva: dugo puštanje u rad, nejednoznačne pogreške, dorade sučelja i napetost oko pitanja tko je odgovoran za neplanirano zaustavljanje. Pri ocjeni takve situacije vrijedi mjeriti ne samo rok predaje, nego i broj izmjena sučelja nakon prihvaćanja projekta, broj nedostataka otkrivenih tek na lokaciji te vrijeme potrebno za utvrđivanje uzroka kvara. Ako ti pokazatelji rastu unatoč napretku radova, problem je obično u organizaciji suradnje, a ne u učinkovitosti pojedinog dobavljača.

Zaseban izvor rizika jest tretiranje testiranja i dokumentacije kao usputnog proizvoda puštanja u rad. Tamo gdje sustav utječe na rad stroja, pristup operatera, dijagnostiku, parametre procesa ili funkcije povezane sa sigurnošću, kasna promjena nije običan programski ispravak. Može zahtijevati ponovnu ocjenu projektnih pretpostavki, ažuriranje tehničke dokumentacije, ponavljanje dijela ispitivanja, a u određenim činjeničnim okolnostima i ponovno razmatranje obveza na strani korisnika ili subjekta koji uvodi promjenu. To se ne može rješavati apstraktno i jednako za svaki projekt, ali praktično pravilo je jednostavno: što promjena više utječe na ponašanje sustava u normalnim i nenormalnim stanjima, to se manje smije voditi „radnim dogovorima”. Tu počinje i područje tipičnih pogrešaka koje se susreću pri izgradnji i modernizaciji strojeva: nepostojanje blokada protiv pogrešne konfiguracije, nepostojanje prisilnog redoslijeda radnji i nepostojanje mehanizama koji sprječavaju pogrešku operatera ili servisa. Ako takve zaštite nisu uključene u opseg od samog početka, kasnije se vraćaju kao trošak, zastoj ili spor oko odgovornosti.

Kako temi pristupiti u praksi

U praksi se suradnja integratora, softverske kuće i odjela održavanja ne bi trebala organizirati oko tvrtki, nego oko granica odgovornosti za konkretne tehničke odluke. To određuje tko je odgovoran za logiku upravljanja, tko za aplikacijski sloj i komunikaciju, a tko za uvjete servisiranja, sigurnosne kopije, oporavak nakon kvara i sigurno uvođenje promjena na lokaciji. Ako te granice ostanu opisane općenito, projekt počinje funkcionirati na pretpostavkama: integrator pretpostavlja da će pogon dostaviti eksploatacijske zahtjeve, softverska kuća polazi od toga da je logika procesa već zaključena, a održavanje dobiva sustav koji se ne može učinkovito održavati bez autora koda. Posljedica nije samo organizacijska. Raste trošak puštanja u rad, produljuje se otklanjanje kvarova, a u slučaju spora teže je utvrditi proizlazi li problem iz pogreške u implementaciji, nepotpunih pretpostavki ili nekontrolirane promjene nakon preuzimanja.

Zato prva odluka ne bi trebala biti izbor alata ni raspored radionica, nego prihvaćanje zajedničkog modela odgovornosti za cijeli životni ciklus rješenja. Za menadžera je praktični kriterij jednostavan: svaka funkcija koja utječe na rad stroja ili linije mora imati jasno određenog vlasnika u četiri stanja projekta — projektiranje, puštanje u rad, preuzimanje i održavanje. Ako se za određenu funkciju ne može jednoznačno odgovoriti tko odobrava zahtjev, tko provodi promjenu, tko ispituje posljedice i tko snosi odgovornost za obnovu rada nakon kvara, tada opseg nije spreman za provedbu. Tu se prirodno pojavljuje i uloga voditelja inženjerskog projekta: ne kao osobe „za rokove”, nego kao vlasnika reda u odlučivanju između struka i dobavljača.

Najviše problema nastaje na dodiru upravljanja i namjenskog softvera. Tipičan primjer je aplikacija koja mijenja način odabira receptura, parametrizira radni slijed ili utječe na ovlasti operatera. Za softversku kuću za industriju to može izgledati kao obična funkcionalna izmjena, ali za integratora i održavanje pogona to je zahvat u ponašanje sustava, dijagnostiku i postupke prekonfiguracije. Ako prije implementacije nije jasno utvrđeno gdje završava odgovornost za sučelje, a gdje počinje odgovornost za logiku procesa, korekcija provedena „u proizvodnji” može zahtijevati ponovna ispitivanja, ažuriranje uputa, a ponekad i preoblikovanje servisnih procedura. Upravo se ovdje tema prelijeva i na područje budžeta: trošak namjenskog softvera za industriju ne proizlazi samo iz pisanja koda, nego i iz toga koliki dio odgovornosti projekt prenosi na fazu validacije, dokumentacije i kasnijeg održavanja.

Kako bi se to spriječilo, stanje projekta vrijedi procjenjivati ne prema izjavama dobavljača, nego prema artefaktima koji se mogu provjeriti. Minimalni skup čine usuglašen popis sučelja, opis verzioniranja, postupak prijave i odobravanja izmjena, scenariji prihvatnih ispitivanja te plan održavanja nakon puštanja u rad. Ovdje dobro funkcionira jedan kratak filtar za donošenje odluke:

• utječe li izmjena na logiku procesa, radne parametre ili ponašanje operatera,
• može li se reproducirati, ispitati i povući bez sudjelovanja autora rješenja,
• omogućuje li dokumentacija nakon implementacije postrojenju održavanje sustava bez znanja skrivenog u e-mail sandučiću izvođača.

Ako je na bilo koje od tih pitanja odgovor „ne”, projekt zahtijeva preciznije definiranje opsega, a ne ubrzavanje radova. Tek se u toj fazi pojavljuje smisleno uporište u formalnim zahtjevima: ne zato da bi se u ugovor dodale općenite ograde, nego da bi se provjerilo utječe li priroda izmjena već na obveze u pogledu dokumentacije, prihvata ili procjene odgovornosti na strani korisnika. To je osobito važno ondje gdje postrojenje samo sudjeluje u izradi rješenja, razvija ga vlastitim snagama ili gradi elemente sustava za internu uporabu. Tada suradnja triju strana prestaje biti isključivo pitanje organizacije projekta i ulazi i u područje pravnih obveza postrojenja.

Na što paziti pri implementaciji

Najviše problema ne pojavljuje se onda kada timu nedostaju kompetencije, nego kada strane u projektu rade ispravno unutar vlastitih granica, ali nitko ne upravlja točkom njihova dodira. U projektu u kojem integrator odgovara za izvedbeni sloj i povezivanje s industrijskom automatikom, softverska kuća za aplikacijsku logiku, a održavanje pogona za kontinuitet rada postrojenja, loša organizacija implementacije gotovo uvijek završava prijenosom rizika na fazu puštanja u rad. Upravo se tada pokazuje jesu li projektne odluke donesene s obzirom na cijeli životni ciklus rješenja ili samo radi zatvaranja opsega pojedinih izvođača. Za projekt to obično znači jedno od troje: skupe dorade nakon puštanja u rad, spor oko odgovornosti za kvarove ili odgodu prihvata jer sustav radi samo u laboratorijskim uvjetima, a ne u stvarnom procesu.

Ključna zamka leži u tome što se implementacija često tretira kao tehnička faza, iako je u praksi to trenutak provjere organizacijskih odluka. Ako integrator može uvoditi promjene u upravljanju bez potpune svijesti o posljedicama na strani aplikacije, softverska kuća razvija funkcije bez potvrde ograničenja uređaja i industrijske mreže, a održavanje pogona uključuje se tek pri prihvatu, tada problem nije u komunikaciji, nego u pogrešno podijeljenoj odgovornosti. Praktični kriterij procjene je jednostavan: prije izlaska na lokaciju svaka strana treba moći navesti koje promjene može provesti samostalno, koje zahtijevaju zajedničko odobrenje i tko donosi odluku o zaustavljanju radova ako se pojavi rizik za proces, sigurnost ili mogućnost ponovnog uspostavljanja konfiguracije. Ako odgovor ovisi o „dogovorima u hodu”, implementacija još nije pripremljena, čak i ako je raspored formalno usklađen.

Tipičan primjer odnosi se na naizgled malu izmjenu: promjenu radnog slijeda stanice, koja je iz perspektive softverske kuće korekcija logike, za integratora znači drukčija vremena odziva uređaja, a za održavanje pogona utječe na dijagnostiku i postupke nakon kvara. Ako takva izmjena dođe na lokaciju bez zajedničkog pregleda posljedica, nakon puštanja u rad teško je utvrditi je li izvor problema kod, konfiguracija upravljača, parametri pogona ili način rukovanja od strane operatera. Tada trošak ne raste samo zbog same korekcije, nego i zbog vremena zastoja, dodatnih ispitivanja i angažmana osoba koje ranije nisu morale sudjelovati u analizi. Zato vrijedi mjeriti ne samo rok puštanja u rad, nego i broj implementacijskih izmjena bez pune putanje odobravanja, vrijeme vraćanja prethodne verzije te udio nedostataka otkrivenih tek nakon predaje sustava u eksploataciju. To daje stvarnu sliku je li suradnja triju strana vođena sustavno ili se samo privremeno održava.

U ovoj se fazi prirodno pojavljuje i granica između obične implementacije i situacije u kojoj pogon počinje suoblikovati rješenje na način koji utječe na njegove formalne obveze. Ako odjel održavanja ne daje samo mišljenje, nego sam mijenja logiku, odabire elemente sustava ili preuzima dio konstrukcijskih odluka, tada se tema više ne odnosi isključivo na organizaciju suradnje, nego ulazi i u područje strojeva izrađenih za vlastite potrebe. To se ne može riješiti jednim pravilom za sve projekte; važni su opseg zahvata, stupanj samostalnosti pogona i to tko stvarno oblikuje značajke rješenja. Slično je i s analizom rizika: ako promjena utječe na funkciju procesa, ponašanje operatera, uvjete servisne intervencije ili slijed izvanrednih stanja, tada to više nije samo pitanje „treba li uvesti promjenu”, nego i „treba li ponovno procijeniti rizik i ažurirati pretpostavke za tehnički prihvat”. U praksi se upravo ovdje najjasnije vidi uloga osobe koja vodi projekt: ne kao posrednika za statuse, nego kao nositelja odluke o tome kada završava praktično pojednostavnjenje, a počinje tehnička i pravna odgovornost.