Kā organizēt integratora, programmatūras izstrādes uzņēmuma un tehniskās apkopes nodaļas sadarbību vienā projektā?

Kāpēc šī tēma šodien ir svarīga

Integratora, programmatūras izstrādes uzņēmuma un ekspluatācijas uzturēšanas dienesta sadarbība vairs nav tikai organizatoriskas ērtības jautājums. Praksē tieši no tās šodien ir atkarīgs, vai projektu varēs ieviest bez strīdiem par darbu apjomu, vai programmatūras izmaiņas neapturēs tehnisko pieņemšanu un vai uzņēmums pēc ieviešanas spēs risinājumu droši uzturēt. Jo vairāk procesa loģikas tiek pārcelts uz programmatūras slāni un jo mazāk paliek gatavajās kontrolieru un iekārtu funkcijās, jo svarīgākas kļūst atbildības robežas. Ja tās netiek noteiktas jau sākumā, projekta izmaksas parasti nepieaug lineāri, bet gan korekciju dēļ, kas tiek veiktas nepareizajā vietā: integrators labo saskarnes, programmatūras izstrādes uzņēmums pārveido biznesa loģiku, bet ekspluatācijas uzturēšanas dienests tikai beigās atklāj ekspluatācijas prasības, kuras iepriekš neviens nebija fiksējis.

Tas ir arī budžeta, ne tikai tehnisks jautājums. Daudzos projektos jautājums par sadarbību starp iesaistītajām pusēm ļoti ātri pāraug jautājumā par to, kas īsti ir rūpniecībai paredzēta pielāgota programmatūra investīciju budžetā: investīciju elements, uzturēšanas izmaksas vai abu šo kategoriju kombinācija. Ja risinājuma arhitektūra paredz, ka galvenās procesa, atskaišu, recepšu, partiju izsekošanas vai integrācijas ar uzņēmuma sistēmām funkcijas tiks izveidotas ārpus automatizācijas standarta apjoma, tas ir jāatpazīst pirms pasūtījuma veikšanas, nevis pēc pirmā prototipa. Praktiskais kritērijs ir vienkāršs: ja viena lēmumu īpašnieka trūkums uz robežas starp automatizāciju, lietotni un ekspluatāciju nozīmē, ka prasības, testi un izmaiņu izmaksas nav iespējams nepārprotami sadalīt, tad projekts jau ir nonācis paaugstināta riska zonā un sadarbības modelis ir jākoriģē.

Visvieglāk to redzēt līnijas modernizācijas piemērā, kur integrators atbild par vadību un palaišanu, programmatūras izstrādes uzņēmums — par lietojumslāni un datu apmaiņu, bet ekspluatācijas uzturēšanas dienestam vēlāk sistēma jāpārņem nepārtrauktai darbībai. Ja ekspluatācijas uzturēšanas dienests tiek iesaistīts tikai pieņemšanas posmā, parasti atklājas problēmas, kas nav “defekti”, bet gan lēmumu trūkuma sekas: nav atjaunošanas procedūras pēc avārijas, nav prasību servisa kontiem, nav noteikti atjauninājumu logi, nav paredzēta atkarība no ārēja piegādātāja vai arī kļūdu novērojamība ir nepietiekama. Tad strīds vairs nav par koda kvalitāti vai vadības skapja pareizību, bet gan par to, kam jāsedz sistēmas pielāgošanas izmaksas uzņēmuma reālajiem apstākļiem. Šajā brīdī tēma dabiski sasaucas ar projekta un atbilstības slēptajām izmaksām, jo pieņemšanas kavēšanās vai vēlas izmaiņas drošības funkcijās, tehniskajā dokumentācijā vai validācijā bieži vien ir tieši slikti organizētas sadarbības, nevis atsevišķas izpildes kļūdas sekas.

Atbilstības aspekts parādās tad, kad darbu sadalījums ietekmē izstrādājuma īpašības, ar drošību saistītās funkcijas, dokumentāciju vai risinājuma nodošanas ekspluatācijā veidu. Ne katra lietotnes integrācija ar iekārtu rada vienādus pienākumus, taču jau pati neskaidrība par to, kurš atbild par funkciju aprakstu, izmaiņu pārvaldību un dokumentācijas pilnīgumu, ir brīdinājuma signāls. Tas īpaši attiecas uz projektiem, kas tiek īstenoti savā uzņēmumā, modernizācijām, kuras tiek veiktas pa posmiem, un risinājumiem, kas tiek būvēti pašu vajadzībām, kur robeža starp “uzturēšanas darbu” un izgatavošanu vai būtisku pārbūvi var būt juridiski nozīmīga. Tāpēc lēmums par sadarbības modeli jāpieņem nevis tad, kad parādās pirmais konflikts, bet gan tad, kad tiek definēts apjoms: kurš apraksta ekspluatācijas prasības, kurš apstiprina arhitektūru, kurš atbild par starpslāņu testiem un kurš pēc palaišanas pārņem sistēmu kopā ar reālu spēju to uzturēt.

Kur visbiežāk pieaug izmaksas vai risks

Projektos, kurus kopīgi īsteno integrators, programmatūras izstrādes uzņēmums un ekspluatācijas uzturēšanas dienests, izmaksas reti pieaug vienas lielas kļūdas dēļ. Parasti tās uzkrājas atbildības saskares punktos, proti, tur, kur nevienam nav pilna pienākuma lietu novest līdz galam. Visdārgākās nav pašas tehniskās kļūdas, bet gan atlikti vai bez skaidra īpašnieka pieņemti lēmumi: nav saskaņotas komunikācijas arhitektūras, nav aprakstītas robežas starp vadības loģiku un lietojumslāni, nav noteikta testēšanas kārtība pēc izmaiņām un sistēma tiek nodota ekspluatācijā bez reālas spējas to uzturēt. Praksē tas nozīmē labojumus jau pēc palaišanas, strīdus par līguma apjomu un atbildības par dīkstāvēm pārbīdi uz posmu, kurā jebkuras izmaiņas ir visdārgākās. Vienkāršs situācijas novērtēšanas kritērijs ir jautājums, vai katrai kritiskajai funkcijai var norādīt vienu pusi, kas atbild par prasību, vienu — par izpildi, un vienu — par pieņemšanu. Ja atbilde ir “tas ir atkarīgs”, projekts jau ir pakļauts organizatoriskam riskam.

Otrs zaudējumu avots parādās tad, kad projektēšanas lēmumi tiek pieņemti bez uzturēšanas dienesta iesaistes vai arī pretēji — kad uzturēšanas dienests uzspiež servisam ērtus risinājumus, kas nav saskaņoti ar sistēmas arhitektūru. Integrators parasti raugās no palaišanas un sadarbības ar iekārtām skatpunkta, programmatūras izstrādes uzņēmums — no biznesa loģikas un saskarņu skatpunkta, bet uzturēšanas dienests — no pieejamības, diagnostikas un darbības atjaunošanas laika skatpunkta. Ja šīs perspektīvas nesatiekas prasību definēšanas posmā, tās vēlāk atgriežas kā izmaiņu izmaksas: papildu signāli, piekļuves tiesību pārbūve, diagnostikai nepieciešamo notikumu nereģistrēšana, nespēja droši veikt atjauninājumus vai avārijas apiešanas procedūras trūkums. Tas ir brīdis, kad tēma dabiski pāriet uz inženiertehniskā projekta vadītāja lomu, jo problēma vairs nav atsevišķs tehnisks lēmums, bet gan atkarību, saskaņošanas termiņu un atbildības par eskalāciju pārvaldība.

Tipisks praktisks piemērs ir ieviešana, kurā virsuzraudzības lietotnei jāvada uzdevumi, receptūra un atskaites, bet integrators atbild par kontrolieri, piedziņām un mašīnas secību. Ja atbildības robeža tiek aprakstīta tikai funkcionāli, nenorādot starpstāvokļus, kļūdu nosacījumus un uzvedību sakaru zuduma gadījumā, katra puse izveidos savus “drošos” pieņēmumus. Programmatūras izstrādes uzņēmums pieņems, ka apstiprinājuma trūkums nozīmē komandas atkārtošanu, integrators pieņems, ka komanda ir vienreizēja, bet uzturēšanas dienests saņems sistēmu, kuru dīkstāves laikā nav iespējams diagnosticēt. Sekas ir paredzamas: ilga palaišana, neviennozīmīgas kļūdas, saskarņu labojumi un spriedze ap jautājumu, kurš atbild par neplānotu apstāšanos. Šādas situācijas izvērtēšanā ir vērts mērīt ne tikai nodošanas termiņu, bet arī saskarņu izmaiņu skaitu pēc projekta apstiprināšanas, defektu skaitu, kas atklāti tikai objektā, un laiku, kas nepieciešams avārijas cēloņa noteikšanai. Ja šie rādītāji pieaug, neraugoties uz darbu progresu, problēma parasti ir sadarbības organizācijā, nevis atsevišķa piegādātāja sniegumā.

Atsevišķs riska avots ir testu un dokumentācijas uztveršana kā palaišanas blakusproduktu. Tur, kur sistēma ietekmē mašīnas darbību, operatora piekļuvi, diagnostiku, procesa parametrus vai ar drošību saistītās funkcijas, vēlīna izmaiņa nav parasts programmēšanas labojums. Tā var prasīt atkārtotu projektēšanas pieņēmumu izvērtēšanu, tehniskās dokumentācijas atjaunināšanu, daļas pārbaužu atkārtošanu, bet noteiktos faktiskajos apstākļos arī atkārtotu pienākumu analīzi lietotāja vai izmaiņu ieviesēja pusē. To nevar abstrakti izlemt vienādi visiem projektiem, taču praktiskais princips ir vienkāršs: jo vairāk izmaiņa ietekmē sistēmas uzvedību normālos un nenormālos stāvokļos, jo mazāk pieļaujams to virzīt “darba kārtībā”. Šeit sākas arī tipisko kļūdu zona, kas sastopama mašīnu būvē un modernizācijā: nav bloķēšanas pret kļūdainu konfigurāciju, nav darbību secības piespiedu nodrošināšanas un nav mehānismu, kas novērš operatora vai servisa kļūdu. Ja šādi aizsardzības pasākumi netiek iekļauti tvērumā jau no paša sākuma, vēlāk tie atgriežas kā izmaksas, dīkstāve vai strīds par atbildību.

Kā šim jautājumam pieiet praksē

Praksē integratora, programmatūras izstrādes uzņēmuma un uzturēšanas dienesta sadarbību nevajadzētu organizēt ap uzņēmumiem, bet gan ap atbildības robežām par konkrētiem tehniskajiem lēmumiem. Tas nosaka, kurš atbild par vadības loģiku, kurš par lietojumprogrammas slāni un komunikāciju, kurš par servisa nosacījumiem, rezerves kopijām, atjaunošanu pēc avārijas un drošu izmaiņu ieviešanu objektā. Ja šīs robežas paliek aprakstītas vispārīgi, projekts sāk balstīties uz minējumiem: integrators pieņem, ka ekspluatācijas prasības nodrošinās uzņēmums, programmatūras izstrādes uzņēmums pieņem, ka procesa loģika jau ir noslēgta, bet uzturēšanas dienests saņem sistēmu, kuru nav iespējams efektīvi uzturēt bez koda autora. Sekas nav tikai organizatoriskas. Pieaug palaišanas izmaksas, paildzinās defektu novēršana, un strīda gadījumā kļūst grūtāk noteikt, vai problēma izriet no ieviešanas kļūdas, nepilnīgiem pieņēmumiem vai nekontrolētas izmaiņas pēc pieņemšanas.

Tāpēc pirmajam lēmumam nevajadzētu būt ne rīka izvēlei, ne darbnīcu grafikam, bet gan kopīga atbildības modeļa pieņemšanai visam risinājuma dzīves ciklam. Vadītājam praktiskais kritērijs ir vienkāršs: katrai funkcijai, kas ietekmē mašīnas vai līnijas darbību, jābūt noteiktam īpašniekam četros projekta stāvokļos — projektēšana, palaišana, pieņemšana un uzturēšana. Ja par konkrētu funkciju nav iespējams viennozīmīgi atbildēt, kurš apstiprina prasību, kurš veic izmaiņu, kurš testē sekas un kurš uzņemas atbildību par darbības atjaunošanu pēc avārijas, tad tvērums nav gatavs īstenošanai. Šajā vietā dabiski parādās inženiertehniskā projekta vadītāja loma: nevis kā cilvēkam “par termiņiem”, bet kā lēmumu kārtības īpašniekam starp disciplīnām un piegādātājiem.

Visvairāk problēmu rodas vadības sistēmas un pielāgotās programmatūras saskares punktā. Tipisks piemērs ir lietotne, kas maina recepšu izvēles veidu, parametrizē darba secību vai ietekmē operatora tiesības. Programmatūras izstrādes uzņēmumam rūpniecībai tas var izskatīties kā parasta funkcionalitātes izmaiņa, taču integratoram un tehniskajai uzturēšanai tā ir iejaukšanās sistēmas darbībā, diagnostikā un pārregulēšanas procedūrās. Ja pirms ieviešanas nav noteikts, kur beidzas atbildība par saskarni un kur sākas atbildība par procesa loģiku, korekcija, kas veikta “ražošanā”, var prasīt atkārtotus izmēģinājumus, instrukciju atjaunināšanu un dažkārt arī servisa procedūru pārveidi. Tieši šeit jautājums pāriet arī budžeta jomā: pielāgotas programmatūras izmaksas rūpniecībai neizriet tikai no koda uzrakstīšanas, bet arī no tā, cik lielu atbildības daļu projekts pārnes uz validācijas, dokumentācijas un turpmākās uzturēšanas posmu.

Lai to novērstu, projekta stāvokli ir vērts vērtēt nevis pēc piegādātāju deklarācijām, bet pēc artefaktiem, kurus iespējams pārbaudīt. Minimālais komplekts ir saskaņots saskarņu saraksts, versiju pārvaldības apraksts, izmaiņu pieteikšanas un autorizācijas procedūra, pieņemšanas testu scenāriji un uzturēšanas plāns pēc palaišanas. Šeit labi darbojas viens īss lēmumu filtrs:

• vai izmaiņas ietekmē procesa loģiku, darba parametrus vai operatora rīcību,
• vai tās var atjaunot, pārbaudīt un atsaukt bez risinājuma autora iesaistes,
• vai dokumentācija pēc ieviešanas ļauj uzņēmumam uzturēt sistēmu bez zināšanām, kas paslēptas izpildītāja e-pasta sarakstē.

Ja uz kādu no šiem jautājumiem atbilde ir “nē”, projektam ir jāprecizē tvērums, nevis jāpaātrina darbi. Tikai šajā posmā parādās jēgpilna atsauce uz formālajām prasībām: nevis tādēļ, lai līgumā pievienotu vispārīgas atrunas, bet lai pārbaudītu, vai izmaiņu raksturs jau neietekmē dokumentācijas, pieņemšanas vai atbildības izvērtēšanas pienākumus lietotāja pusē. Tam ir īpaša nozīme tur, kur uzņēmums pats līdzdarbojas risinājuma izstrādē, attīsta to saviem spēkiem vai veido sistēmas elementus iekšējai lietošanai. Tad trīs pušu sadarbība vairs nav tikai projekta organizācijas jautājums un nonāk arī uzņēmuma juridisko pienākumu jomā.

Kam pievērst uzmanību ieviešanas laikā

Visvairāk problēmu rodas nevis tad, kad komandai trūkst kompetences, bet tad, kad projekta puses korekti strādā savās robežās, taču neviens nepārvalda saskares vietu starp tām. Projektā, kur integrators atbild par izpildes slāni un savienojumiem ar automatizāciju, programmatūras izstrādes uzņēmums — par lietojumprogrammas loģiku, bet tehniskā uzturēšana — par nepārtrauktu uzņēmuma darbību, kļūdaina ieviešanas organizācija gandrīz vienmēr nozīmē riska pārcelšanu uz palaišanas posmu. Tieši tur kļūst redzams, vai projekta lēmumi pieņemti, domājot par visu risinājuma dzīves ciklu, vai tikai par to, lai atsevišķi izpildītāji noslēgtu savu darbu apjomu. Projektam tas parasti nozīmē vienu no trim lietām: dārgus labojumus pēc palaišanas, strīdu par atbildību avāriju gadījumā vai pieņemšanas kavēšanos, jo sistēma darbojas tikai laboratorijas apstākļos, nevis reālā procesā.

Galvenais slazds ir tas, ka ieviešanu mēdz uztvert kā tehnisku posmu, lai gan praksē tas ir organizatorisko lēmumu pārbaudes brīdis. Ja integrators var veikt izmaiņas vadībā bez pilnīgas izpratnes par sekām lietojumprogrammas pusē, programmatūras izstrādes uzņēmums attīsta funkcijas bez apstiprinājuma par iekārtu un industriālā tīkla ierobežojumiem, bet tehniskā uzturēšana tiek iesaistīta tikai pieņemšanas brīdī, tad problēma nav komunikācijā, bet kļūdainā atbildības sadalījumā. Praktisks vērtēšanas kritērijs ir vienkāršs: pirms došanās uz objektu katrai pusei jāspēj norādīt, kuras izmaiņas tā var veikt patstāvīgi, kurām nepieciešama kopīga autorizācija un kurš pieņem lēmumu par darbu apturēšanu, ja rodas risks procesam, drošībai vai konfigurācijas atjaunojamībai. Ja atbilde ir atkarīga no “vienošanās darba gaitā”, ieviešana vēl nav sagatavota, pat ja grafiks formāli atbilst.

Tipisks piemērs ir šķietami neliela modifikācija: darba vietas secības maiņa, kas no programmatūras izstrādes uzņēmuma skatpunkta ir loģikas korekcija, integratoram nozīmē citus iekārtu reakcijas laikus, bet tehniskajai uzturēšanai ietekmē diagnostiku un procedūras pēc avārijas. Ja šāda izmaiņa nonāk objektā bez kopīgas seku pārskatīšanas, pēc palaišanas ir grūti noteikt, vai problēmas avots ir kods, kontroliera konfigurācija, piedziņas parametri vai operatora darba veids. Tad izmaksas pieaug ne tikai pašas korekcijas dēļ, bet arī dīkstāves laika, papildu testu un to cilvēku iesaistes dēļ, kuriem iepriekš analīzē nebija jāpiedalās. Tāpēc ir vērts mērīt ne tikai palaišanas termiņu, bet arī to ieviešanas izmaiņu skaitu, kurām nav pilnas apstiprināšanas ķēdes, iepriekšējās versijas atjaunošanas laiku un to defektu īpatsvaru, kas atklāti tikai pēc sistēmas nodošanas ekspluatācijā. Tas sniedz reālu priekšstatu par to, vai trīs pušu sadarbība tiek vadīta, vai tikai uzturēta situatīvi.

Šajā posmā dabiski parādās arī robeža starp parastu ieviešanu un situāciju, kurā uzņēmums sāk līdzveidot risinājumu tādā mērā, kas ietekmē tā formālos pienākumus. Ja tehniskās uzturēšanas nodaļa ne tikai sniedz atzinumu, bet pati maina loģiku, izvēlas sistēmas elementus vai pārņem daļu konstrukcijas lēmumu, tad jautājums vairs neattiecas tikai uz sadarbības organizēšanu un nonāk arī pašu vajadzībām izgatavotu mašīnu jomā. To nevar noteikt pēc viena noteikuma, kas derētu visiem projektiem; nozīme ir iejaukšanās apjomam, uzņēmuma patstāvības pakāpei un tam, kurš faktiski nosaka risinājuma īpašības. Līdzīgi ir ar riska analīzi: ja izmaiņas ietekmē procesa funkciju, operatora rīcību, servisa iejaukšanās apstākļus vai avārijas stāvokļu secību, tad tas vairs nav tikai jautājums par to, „vai ieviest”, bet arī par to, „vai atkārtoti novērtēt risku un atjaunināt pieņemšanas kritērijus”. Praksē tieši šeit vislabāk redzama projekta vadītāja loma: nevis kā starpniekam, kas apkopo statusus, bet kā atbildīgajam par lēmumu, kurā brīdī beidzas ērts vienkāršojums un sākas tehniskā un juridiskā atbildība.