Kaip viename projekte organizuoti integratoriaus, programinės įrangos kūrimo įmonės ir techninės priežiūros skyriaus bendradarbiavimą?

Kodėl ši tema šiandien svarbi

Integratoriaus, programinės įrangos kūrėjo ir techninės priežiūros skyriaus bendradarbiavimas nebėra vien organizacinio patogumo klausimas. Praktikoje nuo to šiandien priklauso, ar projektą bus galima paleisti be ginčų dėl apimties, ar programinės įrangos pakeitimas nesustabdys techninio priėmimo ir ar įmonė po įdiegimo galės saugiai eksploatuoti sprendimą. Kuo daugiau proceso logikos perkeliama į programinį sluoksnį, o kuo mažiau jos lieka standartinėse valdiklių ir įrenginių funkcijose, tuo svarbesnės tampa atsakomybės ribos. Jei jos nenustatomos pradžioje, projekto kaina paprastai auga ne tiesiškai, o dėl pataisymų, atliekamų netinkamoje vietoje: integratorius taiso sąsajas, programinės įrangos kūrėjas perkuria verslo logiką, o techninės priežiūros skyrius tik pačioje pabaigoje atskleidžia eksploatacinius reikalavimus, kurių anksčiau niekas nebuvo užfiksavęs.

Tai taip pat yra biudžeto, o ne vien techninis klausimas. Daugelyje projektų klausimas apie šalių bendradarbiavimą labai greitai virsta klausimu, kas iš tiesų yra individualiai pramonei kuriama programinė įranga investicijų biudžete: investicijos dalis, priežiūros sąnaudos ar šių dviejų kategorijų derinys. Jeigu sprendimo architektūra numato, kad esminės proceso, ataskaitų teikimo, receptūrų, partijų atsekamumo ar integracijos su gamyklos sistemomis funkcijos bus kuriamos už standartinės automatikos apimties ribų, tai reikia nustatyti prieš užsakymą, o ne po pirmojo prototipo. Praktinis kriterijus paprastas: jeigu dėl to, kad nėra vieno sprendimų savininko ties riba tarp automatikos, taikomosios programos ir eksploatacijos, neįmanoma vienareikšmiškai priskirti reikalavimų, bandymų ir pakeitimų kaštų, projektas jau pateko į padidintos rizikos zoną ir reikia koreguoti bendradarbiavimo modelį.

Lengviausia tai pamatyti modernizuojant liniją, kurioje integratorius atsako už valdymą ir paleidimą, programinės įrangos kūrėjas – už taikomąjį sluoksnį ir duomenų mainus, o techninės priežiūros skyrius vėliau turi perimti sistemą nepertraukiamam darbui. Jeigu techninės priežiūros skyrius įtraukiamas tik priėmimo etape, paprastai išryškėja problemos, kurios nėra „gedimai“, o sprendimų spragos: nėra atkūrimo po avarijos procedūros, nėra reikalavimų aptarnavimo paskyroms, nesuderinti atnaujinimų langai, neįvertinta priklausomybė nuo išorinio tiekėjo arba nepakankamas klaidų stebimumas. Tuomet ginčas jau kyla ne dėl kodo kokybės ar valdymo spintos teisingumo, o dėl to, kas turi padengti sistemos pritaikymo prie realių įmonės sąlygų išlaidas. Šioje vietoje tema natūraliai susijungia su paslėptais projekto ir atitikties kaštais, nes priėmimo vėlavimas arba vėlyvas saugos funkcijų, techninės dokumentacijos ar validavimo pakeitimas dažnai būna būtent prastai organizuoto bendradarbiavimo, o ne pavienės vykdymo klaidos pasekmė.

Atitikties aspektas iškyla tada, kai darbų pasidalijimas daro įtaką gaminio savybėms, su sauga susijusioms funkcijoms, dokumentacijai arba sprendimo pateikimo naudoti būdui. Ne kiekviena taikomosios programos integracija su mašina sukelia tas pačias pareigas, tačiau jau vien neaiškumas, kas atsako už funkcijų aprašymą, pakeitimų valdymą ir dokumentacijos pilnumą, yra įspėjamasis signalas. Tai ypač aktualu projektams, įgyvendinamiems savo įmonėje, etapais vykdomoms modernizacijoms ir savo reikmėms kuriamiems sprendimams, kai riba tarp „priežiūros darbų“ ir pagaminimo ar esminio pertvarkymo gali būti teisiškai reikšminga. Todėl sprendimą dėl bendradarbiavimo modelio reikia priimti ne tada, kai kyla pirmasis konfliktas, o tada, kai apibrėžiama apimtis: kas aprašo eksploatacinius reikalavimus, kas tvirtina architektūrą, kas atsako už tarpsluoksninius bandymus ir kas po paleidimo perima sistemą kartu su realiu pajėgumu ją prižiūrėti.

Kur dažniausiai auga kaštai arba rizika

Projektuose, kuriuos kartu vykdo integratorius, programinės įrangos kūrėjas ir techninės priežiūros skyrius, kaštai retai išauga dėl vienos didelės klaidos. Dažniausiai jie didėja atsakomybių sandūroje, t. y. ten, kur niekas neturi visos pareigos užbaigti klausimo iki galo. Brangiausios yra ne pačios techninės klaidos, o atidėti sprendimai arba sprendimai be aiškaus savininko: nesuderinta komunikacijos architektūra, neaprašytos ribos tarp valdymo logikos ir taikomojo sluoksnio, nenustatyta bandymų po pakeitimo tvarka ir sistemos perdavimas eksploatacijai neturint realių galimybių ją prižiūrėti. Praktikoje tai reiškia pataisymus jau po paleidimo, ginčus dėl sutarties apimties ir atsakomybės už prastovas perkėlimą į etapą, kuriame kiekvienas pakeitimas kainuoja daugiausia. Paprastas situacijos vertinimo kriterijus – klausimas, ar kiekvienai kritinei funkcijai galima nurodyti vieną šalį, atsakingą už reikalavimą, vieną – už įgyvendinimą ir vieną – už priėmimą. Jeigu atsakymas yra „tai priklauso“, projektui jau būdinga organizacinė rizika.

Antra nuostolių sritis atsiranda tada, kai projektiniai sprendimai priimami nedalyvaujant techninės priežiūros padaliniui arba atvirkščiai – kai techninė priežiūra primeta sprendimus, patogius aptarnavimui, bet nesuderintus su sistemos architektūra. Integratorius paprastai žiūri per paleidimo ir sąveikos su įrenginiais prizmę, software house – per verslo logikos ir sąsajų prizmę, o techninė priežiūra – per prieinamumo, diagnostikos ir darbo atkūrimo laiko prizmę. Jei šios perspektyvos nesusitinka reikalavimų apibrėžimo etape, vėliau jos sugrįžta kaip pakeitimų sąnaudos: papildomi signalai, teisių pertvarkymas, diagnostikai reikalingų įvykių neregistravimas, neįmanomumas saugiai atlikti atnaujinimų arba avarijos apėjimo procedūros nebuvimas. Būtent čia tema natūraliai pereina prie inžinerinio projekto vadovo vaidmens, nes problema nustoja būti pavieniu techniniu sprendimu ir tampa priklausomybių, derinimo terminų bei atsakomybės už eskalavimą valdymu.

Tipinis praktinis pavyzdys – diegimas, kuriame aukštesnio lygio programa turi valdyti užsakymus, receptūrą ir ataskaitų teikimą, o integratorius atsako už valdiklį, pavaras ir mašinos seką. Jei atsakomybės riba aprašoma tik funkciniu požiūriu, nenurodant tarpinių būsenų, klaidų sąlygų ir elgsenos praradus ryšį, kiekviena šalis savaip susikurs „saugias“ prielaidas. Software house nuspręs, kad patvirtinimo nebuvimas reiškia komandos pakartojimą, integratorius laikys, kad komanda yra vienkartinė, o techninė priežiūra gaus sistemą, kurios neįmanoma diagnozuoti prastovos metu. Pasekmė nuspėjama: ilgas paleidimas, dviprasmiškos klaidos, sąsajų taisymai ir įtampa dėl klausimo, kas atsako už neplanuotą sustojimą. Vertinant tokią situaciją verta matuoti ne tik perdavimo terminą, bet ir sąsajų pakeitimų skaičių po projekto patvirtinimo, gedimų, aptiktų tik objekte, skaičių bei laiką, reikalingą avarijos priežasčiai atkurti. Jei šie rodikliai auga nepaisant darbų pažangos, problema paprastai slypi bendradarbiavimo organizavime, o ne atskiro tiekėjo našume.

Atskiras rizikos šaltinis yra testų ir dokumentacijos laikymas šalutiniu paleidimo produktu. Ten, kur sistema daro įtaką mašinos veikimui, operatoriaus prieigai, diagnostikai, proceso parametrams arba su sauga susijusioms funkcijoms, vėlyvas pakeitimas nėra paprastas programavimo pataisymas. Jis gali pareikalauti pakartotinai įvertinti projektines prielaidas, atnaujinti techninę dokumentaciją, pakartoti dalį bandymų, o tam tikromis faktinėmis aplinkybėmis – taip pat iš naujo išanalizuoti naudotojo arba pakeitimą įgyvendinančio subjekto pareigas. To neįmanoma abstrakčiai išspręsti visiems projektams vienodai, tačiau praktinė taisyklė paprasta: kuo labiau pakeitimas veikia sistemos elgseną normaliomis ir nenormaliomis būsenomis, tuo mažiau galima jį vykdyti „darbiniais susitarimais“. Čia taip pat prasideda tipinių klaidų, pasitaikančių statant ir modernizuojant mašinas, sritis: nėra blokavimų nuo klaidingos konfigūracijos, nėra veiksmų sekos privalomo užtikrinimo ir nėra mechanizmų, užkertančių kelią operatoriaus ar serviso klaidai. Jei tokios apsaugos priemonės nuo pat pradžių neįtraukiamos į apimtį, vėliau jos sugrįžta kaip sąnaudos, prastova arba ginčas dėl atsakomybės.

Kaip prie to prieiti praktiškai

Praktikoje integratoriaus, software house ir techninės priežiūros skyriaus bendradarbiavimas turėtų būti organizuojamas ne pagal įmones, o pagal atsakomybės ribas už konkrečius techninius sprendimus. Tai lemia, kas atsako už valdymo logiką, kas – už taikomąjį sluoksnį ir komunikaciją, kas – už aptarnavimo sąlygas, atsargines kopijas, atkūrimą po avarijos ir saugų pakeitimų diegimą objekte. Jei šios ribos lieka aprašytos bendrais bruožais, projektas pradedamas vykdyti remiantis spėlionėmis: integratorius daro prielaidą, kad eksploatacinius reikalavimus pateiks gamykla, software house priima, kad proceso logika jau yra galutinai apibrėžta, o techninė priežiūra gauna sistemą, kurios neįmanoma veiksmingai prižiūrėti be kodo autoriaus. Pasekmė nėra vien organizacinė. Didėja paleidimo sąnaudos, ilgėja gedimų šalinimas, o kilus ginčui tampa sunkiau nustatyti, ar problema kyla dėl įgyvendinimo klaidos, neišsamių prielaidų ar nekontroliuojamo pakeitimo po priėmimo.

Todėl pirmasis sprendimas turėtų būti ne įrankio pasirinkimas ar dirbtuvių grafikas, o bendro atsakomybės modelio priėmimas visam sprendimo gyvavimo ciklui. Vadovui praktinis kriterijus paprastas: kiekviena funkcija, daranti įtaką mašinos ar linijos darbui, turi turėti aiškiai nurodytą savininką keturiose projekto būsenose – projektavimo, paleidimo, priėmimo ir priežiūros. Jei dėl konkrečios funkcijos neįmanoma vienareikšmiškai atsakyti, kas tvirtina reikalavimą, kas atlieka pakeitimą, kas testuoja pasekmes ir kas prisiima atsakomybę už veikimo atkūrimą po avarijos, vadinasi, apimtis dar nėra parengta įgyvendinimui. Šioje vietoje natūraliai išryškėja inžinerinio projekto vadovo vaidmuo: ne kaip žmogaus, kuris „atsakingas už terminus“, o kaip sprendimų tvarkos tarp sričių ir tiekėjų savininko.

Daugiausia problemų kyla ten, kur susikerta valdymo sistema ir individualiai kuriama programinė įranga. Tipinis pavyzdys – taikomoji programa, kuri pakeičia receptūrų parinkimo būdą, nustato darbo sekos parametrus arba daro įtaką operatoriaus teisėms. Programinės įrangos kūrimo įmonei tai gali atrodyti kaip įprastas funkcionalumo pakeitimas, tačiau integratoriui ir techninės priežiūros padaliniui tai jau yra įsikišimas į sistemos veikimą, diagnostiką ir perreguliavimo procedūras. Jei prieš diegimą nebuvo aiškiai sutarta, kur baigiasi atsakomybė už sąsają ir kur prasideda atsakomybė už proceso logiką, pataisa, atlikta „gamyboje“, gali pareikalauti pakartotinių bandymų, instrukcijų atnaujinimo, o kartais ir serviso procedūrų pertvarkymo. Būtent čia klausimas pereina ir į biudžeto sritį: individualios programinės įrangos kaina pramonei priklauso ne vien nuo kodo parašymo, bet ir nuo to, kiek atsakomybės projektas perkelia į validavimo, dokumentavimo ir vėlesnės priežiūros etapą.

Norint to išvengti, projekto būklę verta vertinti ne pagal tiekėjų deklaracijas, o pagal artefaktus, kuriuos galima patikrinti. Minimalų rinkinį sudaro suderintas sąsajų sąrašas, versijavimo aprašas, pakeitimų registravimo ir tvirtinimo procedūra, priėmimo bandymų scenarijai ir priežiūros planas po paleidimo. Čia gerai veikia vienas trumpas sprendimų filtras:

• ar pakeitimas daro įtaką proceso logikai, darbo parametrams arba operatoriaus veiksmams,
• ar jį galima atkurti, išbandyti ir atšaukti be sprendimo autoriaus dalyvavimo,
• ar dokumentacija po diegimo leidžia įmonei palaikyti sistemą be žinių, paslėptų rangovo el. pašto dėžutėje.

Jei į bent vieną iš šių klausimų atsakymas yra „ne“, projektui reikia tiksliau apibrėžti apimtį, o ne spartinti darbus. Tik šiame etape atsiranda prasminga nuoroda į formaliuosius reikalavimus: ne tam, kad į sutartį būtų įrašytos bendro pobūdžio išlygos, o tam, kad būtų patikrinta, ar pakeitimų pobūdis jau nedaro įtakos dokumentavimo, priėmimo pareigoms arba atsakomybės vertinimui naudotojo pusėje. Tai ypač svarbu ten, kur įmonė pati kartu kuria sprendimą, plėtoja jį savo jėgomis arba kuria sistemos elementus vidaus reikmėms. Tuomet trijų šalių bendradarbiavimas nustoja būti vien projekto organizavimo klausimu ir pereina ir į įmonės teisinių pareigų sritį.

Į ką atkreipti dėmesį diegimo metu

Daugiausia problemų atsiranda ne tada, kai komandai trūksta kompetencijos, o tada, kai projekto šalys savo ribose dirba tinkamai, tačiau niekas nevaldo jų sąlyčio taško. Projekte, kuriame integratorius atsako už vykdomąjį lygmenį ir jungtis su pramonės automatika, programinės įrangos kūrimo įmonė – už taikomosios logikos sluoksnį, o techninės priežiūros padalinys – už nepertraukiamą įmonės darbą, netinkamai suorganizuotas diegimas beveik visada baigiasi tuo, kad rizika perkeliama į paleidimo etapą. Būtent tada paaiškėja, ar projektiniai sprendimai buvo priimami galvojant apie visą sprendimo gyvavimo ciklą, ar tik apie tai, kad atskiri vykdytojai uždarytų savo darbų apimtį. Projektui tai paprastai reiškia vieną iš trijų dalykų: brangiai kainuojančias pataisas po paleidimo, ginčą dėl atsakomybės už gedimus arba priėmimo vėlavimą, nes sistema veikia tik laboratorinėmis sąlygomis, o ne realiame procese.

Pagrindiniai spąstai yra tai, kad diegimas neretai traktuojamas kaip techninis etapas, nors praktikoje tai yra organizacinių sprendimų patikrinimo momentas. Jei integratorius gali atlikti valdymo pakeitimus neturėdamas visos informacijos apie pasekmes taikomosios programos pusėje, programinės įrangos kūrimo įmonė plėtoja funkcijas nepatvirtinusi įrenginių ir pramoninio tinklo apribojimų, o techninės priežiūros padalinys įtraukiamas tik priėmimo metu, problema slypi ne komunikacijoje, o netinkamame atsakomybių paskirstyme. Praktinis vertinimo kriterijus paprastas: prieš atvykstant į objektą kiekviena šalis turi gebėti nurodyti, kokius pakeitimus ji gali atlikti savarankiškai, kuriems reikia bendro patvirtinimo ir kas priima sprendimą stabdyti darbus, jei atsiranda rizika procesui, saugai ar konfigūracijos atkuriamumui. Jei atsakymas priklauso nuo „einamųjų susitarimų“, diegimas dar nėra parengtas, net jei grafikas formaliai sutampa.

Tipinis pavyzdys susijęs su iš pažiūros nedideliu pakeitimu: darbo vietos veikimo sekos pakeitimu, kuris programinės įrangos kūrimo įmonės požiūriu yra logikos korekcija, integratoriui reiškia kitokius įrenginių reakcijos laikus, o techninės priežiūros padaliniui daro įtaką diagnostikai ir procedūroms po gedimo. Jei toks pakeitimas objekte atliekamas be bendros pasekmių peržiūros, po paleidimo tampa sunku nustatyti, ar problemos šaltinis yra kodas, valdiklio konfigūracija, pavaros parametrai ar operatoriaus darbo būdas. Tuomet kaštai auga ne tik dėl pačios pataisos, bet ir dėl prastovos laiko, papildomų bandymų bei žmonių, kurių anksčiau nereikėjo įtraukti į analizę, dalyvavimo. Todėl verta matuoti ne tik paleidimo terminą, bet ir diegimo pakeitimų be pilnos tvirtinimo grandinės skaičių, ankstesnės versijos atkūrimo laiką bei gedimų, nustatytų tik perdavus sistemą eksploatuoti, dalį. Tai leidžia realiai įvertinti, ar trijų šalių bendradarbiavimas yra valdomas, ar tik palaikomas situaciškai.

Šiame etape natūraliai išryškėja ir riba tarp įprasto diegimo bei situacijos, kai įmonė pati pradeda bendrai kurti sprendimą taip, kad tai jau turi įtakos jos formalioms pareigoms. Jeigu techninės priežiūros padalinys ne tik teikia pastabas, bet ir pats keičia logiką, parenka sistemos elementus ar perima dalį konstrukcinių sprendimų, klausimas nebeapsiriboja vien bendradarbiavimo organizavimu ir pereina ir į savo reikmėms gaminamų mašinų sritį. To neįmanoma nuspręsti pagal vieną taisyklę, tinkančią visiems projektams; svarbus yra įsikišimo mastas, įmonės savarankiškumo lygis ir tai, kas iš tikrųjų formuoja sprendimo savybes. Panašiai ir su rizikos analize: jeigu pakeitimas daro įtaką proceso funkcijai, operatoriaus elgsenai, techninės priežiūros intervencijos sąlygoms arba avarinių būsenų sekai, tai jau nėra vien klausimas „ar diegti“, bet ir „ar reikia iš naujo įvertinti riziką ir atnaujinti priėmimo prielaidas“. Praktikoje būtent čia aiškiausiai matomas už projektą atsakingo asmens vaidmuo: ne kaip tarpininko, kuris tik perduoda statusus, bet kaip sprendimų savininko, nusprendžiančio, kada baigiasi patogus supaprastinimas, o prasideda techninė ir teisinė atsakomybė.