Kako v enem projektu organizirati sodelovanje integratorja, podjetja za razvoj programske opreme in oddelka vzdrževanja?

Zakaj je ta tema danes pomembna

Sodelovanje med integratorjem, software houseom in oddelkom vzdrževanja ni več vprašanje organizacijskega udobja. V praksi danes odloča o tem, ali je projekt mogoče zagnati brez sporov glede obsega, ali sprememba v programski opremi ne bo ustavila tehničnega prevzema in ali bo obrat po uvedbi rešitev lahko varno vzdrževal. Čim več procesne logike prehaja v programski sloj, manj pa je ostaja v že pripravljenih funkcijah krmilnikov in naprav, tem pomembnejše postajajo meje odgovornosti. Če niso določene na začetku, strošek projekta praviloma ne narašča linearno, temveč zaradi popravkov, izvedenih na napačnem mestu: integrator popravlja vmesnike, software house na novo gradi poslovno logiko, vzdrževanje pa šele na koncu razkrije obratovalne zahteve, ki jih prej nihče ni zapisal.

To je tudi proračunska tema, ne zgolj tehnična. V številnih projektih se vprašanje sodelovanja med stranmi zelo hitro spremeni v vprašanje, kaj pravzaprav pomeni namenska programska oprema za industrijo v investicijskem proračunu: element investicije, strošek vzdrževanja ali mešanica obojega. Če arhitektura rešitve predvideva, da bodo ključne funkcije procesa, poročanja, receptur, sledljivosti serij ali integracije s tovarniškimi sistemi nastale zunaj standardnega obsega avtomatizacije, je treba to prepoznati pred naročilom, ne pa po prvem prototipu. Praktično merilo je preprosto: če zaradi odsotnosti enega nosilca odločanja za mejo med avtomatiko, aplikacijo in obratovanjem ni mogoče jasno pripisati zahtev, testov in stroškov sprememb, je projekt že vstopil v območje povečanega tveganja in zahteva popravek modela sodelovanja.

To je najlažje videti na primeru modernizacije linije, pri kateri integrator odgovarja za krmiljenje in zagon, software house za aplikacijski sloj in izmenjavo podatkov, oddelek vzdrževanja pa mora sistem pozneje prevzeti za neprekinjeno obratovanje. Če je vzdrževanje vključeno šele ob prevzemih, se običajno pokažejo težave, ki niso »napake«, temveč manjkajoče odločitve: ni postopka za obnovitev po okvari, ni zahtev za servisne račune, niso določena okna za posodobitve, obstaja nepredvidena odvisnost od zunanjega dobavitelja ali pa je opazljivost napak nezadostna. Takrat spor ni več o kakovosti kode ali pravilnosti krmilne omare, temveč o tem, kdo bo nosil strošek prilagoditve sistema dejanskim razmeram v obratu. Na tej točki se tema naravno poveže s skritimi stroški projekta in skladnosti, saj sta zamuda pri prevzemu ali pozna sprememba varnostnih funkcij, tehnične dokumentacije ali validacije pogosto posledica slabo organiziranega sodelovanja, ne pa posamezne izvedbene napake.

Vidik skladnosti se pojavi takrat, ko delitev del vpliva na lastnosti izdelka, funkcije, povezane z varnostjo, dokumentacijo ali način uvedbe rešitve v uporabo. Vsaka integracija aplikacije s strojem ne sproži enakih obveznosti, vendar je že sama nejasnost glede tega, kdo odgovarja za opis funkcij, upravljanje sprememb in popolnost dokumentacije, opozorilni znak. To še posebej velja za projekte, izvedene v lastnem obratu, za modernizacije, ki potekajo po fazah, ter za rešitve, zgrajene za lastno uporabo, kjer je meja med »vzdrževalnim delom« in izdelavo ali bistveno predelavo lahko pravno pomembna. Zato je treba odločitev o modelu sodelovanja sprejeti ne takrat, ko se pojavi prvi konflikt, temveč takrat, ko se opredeljuje obseg: kdo opisuje operativne zahteve, kdo potrjuje arhitekturo, kdo odgovarja za medplastne teste in kdo po zagonu prevzame sistem skupaj z dejansko sposobnostjo njegovega vzdrževanja.

Kje najpogosteje naraščata strošek ali tveganje

V projektih, ki jih skupaj vodijo integrator, software house in oddelek vzdrževanja, stroški redko narastejo zaradi ene velike napake. Običajno se kopičijo na stiku odgovornosti, torej tam, kjer nihče nima celotne obveznosti, da zadevo pripelje do konca. Najdražje niso tehnične napake same po sebi, temveč odložene odločitve ali odločitve brez jasno določenega nosilca: pomanjkanje usklajene komunikacijske arhitekture, neopisane meje med logiko krmiljenja in aplikacijskim slojem, nedoločen način testiranja po spremembi ter prevzem sistema v obratovanje brez dejanske sposobnosti vzdrževanja. V praksi to pomeni popravke, izvedene šele po zagonu, spore glede pogodbenega obsega in prenos odgovornosti za zastoje v fazo, v kateri je vsaka sprememba najdražja. Preprosto merilo za oceno položaja je vprašanje, ali je za vsako kritično funkcijo mogoče določiti eno stran, odgovorno za zahtevo, eno za izvedbo in eno za prevzem. Če je odgovor »odvisno«, je projekt že obremenjen z organizacijskim tveganjem.

Drugo področje izgub se pojavi takrat, ko se projektne odločitve sprejemajo brez sodelovanja vzdrževanja, ali pa obratno: ko vzdrževanje vsiljuje rešitve, ki so sicer priročne za servisiranje, vendar niso usklajene z arhitekturo sistema. Integrator praviloma gleda predvsem na zagon in sodelovanje z napravami, software house na poslovno logiko in vmesnike, vzdrževanje pa na razpoložljivost, diagnostiko in čas ponovne vzpostavitve delovanja. Če se ti pogledi ne uskladijo že v fazi opredelitve zahtev, se pozneje vrnejo v obliki stroškov sprememb: dodatni signali, predelava pravic dostopa, manjkajoče beleženje dogodkov, potrebnih za diagnostiko, nezmožnost varne izvedbe posodobitev ali odsotnost postopka za obvod ob okvari. To je trenutek, ko tema naravno preide v vlogo vodje inženirskega projekta, saj problem ni več posamezna tehnična odločitev, temveč upravljanje odvisnosti, rokov za uskladitve in odgovornosti za eskalacijo.

Tipičen praktičen primer je uvedba, pri kateri nadrejena aplikacija upravlja delovne naloge, recepturo in poročanje, integrator pa je odgovoren za krmilnik, pogone in zaporedje delovanja stroja. Če je meja odgovornosti opisana zgolj funkcionalno, brez navedbe vmesnih stanj, pogojev napake in obnašanja ob izgubi komunikacije, bo vsaka stran po svoje oblikovala »varne« predpostavke. Software house bo predpostavil, da odsotnost potrditve pomeni ponovno pošiljanje ukaza, integrator bo izhajal iz tega, da je ukaz enkraten, vzdrževanje pa bo dobilo sistem, ki ga med zastojem ni mogoče diagnosticirati. Posledica je predvidljiva: dolgotrajen zagon, nejasne napake, popravki vmesnikov in napetosti glede vprašanja, kdo je odgovoren za nenačrtovano zaustavitev. Pri presoji takšne situacije je smiselno meriti ne le rok predaje, temveč tudi število sprememb vmesnikov po potrditvi projekta, število napak, odkritih šele na lokaciji, ter čas, potreben za ugotovitev vzroka okvare. Če ti kazalniki rastejo kljub napredovanju del, je težava praviloma v organizaciji sodelovanja, ne pa v učinkovitosti posameznega dobavitelja.

Poseben vir tveganja je obravnavanje testiranja in dokumentacije kot stranskega produkta zagona. Kjer sistem vpliva na delovanje stroja, dostop operaterja, diagnostiko, procesne parametre ali varnostne funkcije, pozna sprememba ni navaden programski popravek. Lahko zahteva ponovno presojo projektnih predpostavk, posodobitev tehnične dokumentacije, ponovitev dela preizkusov, v določenih dejanskih okoliščinah pa tudi ponovno analizo obveznosti na strani uporabnika ali subjekta, ki uvaja spremembo. Tega ni mogoče abstraktno in enako presojati za vsak projekt, vendar je praktično pravilo preprosto: čim bolj sprememba vpliva na obnašanje sistema v normalnih in nenormalnih stanjih, tem manj dopustno jo je voditi zgolj na podlagi »delovnih uskladitev«. Tu se začne tudi področje tipičnih napak pri gradnji in posodobitvi strojev: manjkajoče blokade pred napačno konfiguracijo, nevsiljeno zaporedje dejanj ter odsotnost mehanizmov, ki preprečujejo napako operaterja ali servisa. Če takšni zaščitni ukrepi niso vključeni v obseg že od začetka, se pozneje vrnejo kot strošek, zastoj ali spor glede odgovornosti.

Kako se teme lotiti v praksi

V praksi sodelovanje integratorja, software house’a in oddelka vzdrževanja ne bi smelo biti organizirano okoli podjetij, temveč okoli meja odgovornosti za konkretne tehnične odločitve. To določa, kdo je odgovoren za logiko krmiljenja, kdo za aplikacijski sloj in komunikacijo, kdo za pogoje servisiranja, varnostne kopije, obnovitev po okvari in varno uvedbo sprememb na lokaciji. Če te meje ostanejo opisane le na splošno, projekt začne temeljiti na domnevah: integrator predpostavlja, da bo obrat zagotovil obratovalne zahteve, software house meni, da je procesna logika že zaključena, vzdrževanje pa dobi sistem, ki ga brez avtorja kode ni mogoče učinkovito vzdrževati. Posledica ni zgolj organizacijska. Stroški zagona narastejo, odpravljanje napak se podaljša, ob sporu pa je težje ugotoviti, ali težava izhaja iz napake pri implementaciji, nepopolnih predpostavk ali nenadzorovane spremembe po prevzemu.

Zato prva odločitev ne bi smela biti izbira orodja ali časovnica delavnic, temveč sprejetje skupnega modela odgovornosti za celoten življenjski cikel rešitve. Za managerja je praktično merilo preprosto: vsaka funkcija, ki vpliva na delovanje stroja ali linije, mora imeti določenega lastnika v štirih stanjih projekta — načrtovanje, zagon, prevzem in vzdrževanje. Če za posamezno funkcijo ni mogoče nedvoumno odgovoriti, kdo potrdi zahtevo, kdo izvede spremembo, kdo preizkusi posledice in kdo nosi odgovornost za obnovitev delovanja po okvari, potem obseg še ni pripravljen za izvedbo. Tu se naravno pojavi vloga vodje inženirskega projekta: ne kot osebe »za roke«, temveč kot lastnika reda pri odločanju med strokami in dobavitelji.

Največ težav nastane na stiku med krmiljenjem in namensko programsko opremo. Tipičen primer je aplikacija, ki spremeni način izbire receptur, parametrizira delovno zaporedje ali vpliva na pravice operaterja. Za software house je to lahko videti kot običajna funkcionalna sprememba, za integratorja in vzdrževanje pa pomeni poseg v obnašanje sistema, diagnostiko in postopke preureditve. Če pred uvedbo ni bilo jasno določeno, kje se konča odgovornost za vmesnik in kje se začne odgovornost za logiko procesa, lahko popravek, izveden »v proizvodnji«, zahteva ponovne preizkuse, posodobitev navodil, včasih pa tudi prenovo servisnih postopkov. Prav tu se tema prenese tudi na področje proračuna: strošek namenske programske opreme za industrijo ne izhaja le iz pisanja kode, temveč tudi iz tega, koliko odgovornosti projekt prenese v fazo validacije, dokumentacije in poznejšega vzdrževanja.

Da bi to preprečili, je smiselno stanje projekta presojati ne po izjavah dobaviteljev, temveč po artefaktih, ki jih je mogoče preveriti. Najmanjši nabor vključuje usklajen seznam vmesnikov, opis verzioniranja, postopek prijave in odobritve sprememb, scenarije prevzemnih preskusov ter načrt vzdrževanja po zagonu. Dobro se obnese naslednje kratko odločitveno sito:

• ali sprememba vpliva na logiko procesa, delovne parametre ali ravnanje operaterja,
• ali jo je mogoče reproducirati, preizkusiti in umakniti brez sodelovanja avtorja rešitve,
• ali dokumentacija po uvedbi obratu omogoča vzdrževanje sistema brez znanja, skritega v e-poštnem predalu izvajalca.

Če je na katero od teh vprašanj odgovor »ne«, je treba natančneje opredeliti obseg projekta, ne pa pospeševati del. Šele na tej stopnji je smiselno sklicevanje na formalne zahteve: ne zato, da bi se v pogodbo dodali splošni pridržki, temveč da se preveri, ali narava sprememb že vpliva na obveznosti glede dokumentacije, prevzema ali presoje odgovornosti na strani uporabnika. To je še posebej pomembno tam, kjer obrat sam soustvarja rešitev, jo razvija z lastnimi viri ali izdeluje elemente sistema za interno uporabo. Takrat sodelovanje treh strani ni več zgolj vprašanje organizacije projekta, temveč posega tudi na področje pravnih obveznosti obrata.

Na kaj paziti pri uvedbi

Največ težav se ne pojavi takrat, ko ekipa nima ustreznih kompetenc, temveč takrat, ko posamezne strani projekta delujejo pravilno znotraj svojih meja, nihče pa ne upravlja stične točke med njimi. V projektu, kjer integrator odgovarja za izvedbeni sloj in povezave z industrijsko avtomatizacijo, software house za aplikacijsko logiko, vzdrževanje pa za neprekinjeno delovanje obrata, se napačna organizacija uvedbe skoraj vedno konča s prenosom tveganja v fazo zagona. Prav tam se pokaže, ali so bile projektne odločitve sprejete z mislijo na celoten življenjski cikel rešitve ali zgolj na zaprtje obsega posameznih izvajalcev. Za projekt to običajno pomeni eno od treh stvari: drage popravke po zagonu, spor glede odgovornosti za okvare ali zamudo pri prevzemu, ker sistem deluje le v laboratorijskih pogojih, ne pa tudi v realnem procesu.

Ključna past je v tem, da se uvedba pogosto obravnava kot tehnična faza, čeprav je v praksi to trenutek preverjanja organizacijskih odločitev. Če lahko integrator uvaja spremembe v krmiljenju brez popolnega poznavanja posledic na strani aplikacije, software house razvija funkcije brez potrditve omejitev naprav in industrijskega omrežja, vzdrževanje pa je vključeno šele ob prevzemu, potem težava ni v komunikaciji, temveč v napačno razdeljeni odgovornosti. Praktično merilo presoje je preprosto: pred vstopom na objekt mora vsaka stran znati povedati, katere spremembe lahko izvede samostojno, katere zahtevajo skupno odobritev in kdo sprejme odločitev o ustavitvi del, če se pojavi tveganje za proces, varnost ali ponovljivost konfiguracije. Če je odgovor odvisen od »sprotnih dogovorov«, uvedba še ni pripravljena, tudi če je časovni načrt formalno usklajen.

Tipičen primer se nanaša na navidez majhno spremembo: spremembo delovnega zaporedja postaje, ki je z vidika software house’a popravek logike, za integratorja pomeni drugačne odzivne čase naprav, za vzdrževanje pa vpliva na diagnostiko in postopke po okvari. Če takšna sprememba pride na objekt brez skupnega pregleda posledic, je po zagonu težko ugotoviti, ali je vir težave koda, konfiguracija krmilnika, parametri pogona ali način upravljanja s strani operaterja. Takrat strošek ne naraste le zaradi samega popravka, temveč tudi zaradi časa zastoja, dodatnih preskusov in vključitve oseb, ki jim prej v analizi ne bi bilo treba sodelovati. Zato je smiselno meriti ne le rok zagona, temveč tudi število sprememb med uvedbo brez celotne poti odobritve, čas za povrnitev prejšnje različice ter delež napak, odkritih šele po predaji sistema v uporabo. To daje realno sliko, ali je sodelovanje treh strani vodeno sistematično ali pa se zgolj sproti ohranja.

Na tej stopnji se naravno pokaže tudi meja med običajno uvedbo in položajem, ko obrat začne sooblikovati rešitev na način, ki vpliva na njegove formalne obveznosti. Če oddelek vzdrževanja ne daje le mnenj, temveč sam spreminja logiko, izbira elemente sistema ali prevzema del konstrukcijskih odločitev, potem vprašanje ne zadeva več zgolj organizacije sodelovanja, ampak prehaja tudi na področje strojev, izdelanih za lastno uporabo. Tega ni mogoče presoditi z enim pravilom za vse projekte; pomembni so obseg posega, stopnja samostojnosti obrata in to, kdo dejansko oblikuje lastnosti rešitve. Podobno velja za analizo tveganja: če sprememba vpliva na funkcijo procesa, ravnanje operaterja, pogoje servisnega posega ali zaporedje izrednih stanj, potem ne gre več samo za vprašanje »ali uvesti«, temveč tudi »ali je treba ponovno oceniti tveganje in posodobiti prevzemna izhodišča«. V praksi se prav tu najjasneje pokaže vloga osebe, ki vodi projekt: ne kot posrednika za statuse, temveč kot nosilca odločitve o tem, kdaj se konča udobna poenostavitev in začne tehnična ter pravna odgovornost.