Specializuota programinė įranga pramonei – kada paruošta FEM/ERP sistema nustoja būti racionaliu pasirinkimu

Paruošta gamybos vykdymo ar ERP sistema gali būti racionalus pasirinkimas, bet tik tada, kai realią gamybos eigą galima atvaizduoti be esminių supaprastinimų. Priešingu atveju sistema sutvarko apskaitą proceso valdomumo sąskaita. Būtent tada klausimas apie funkcijų katalogą praranda prasmę. Reikia įvertinti, ar įmonė ir toliau valdys savo gamybą, kokybę ir techninę priežiūrą, ar pradės darbą taikyti prie įrankio ribojimų. Jei kritiniai sprendimai, išimtys ir blokavimai daugiausia veikia už sistemos ribų, pramonei skirta individuali programinė įranga nėra užgaida. Ji tampa būdu susigrąžinti duomenų nuoseklumą, atsakomybės aiškumą ir operatyvinę kontrolę.

Ne kiekvieną gamybą galima korektiškai sutalpinti į paruoštą sistemą

Paruošta gamybos vykdymo ar ERP sistema gerai pasiteisina ten, kur procesas iš tiesų yra pasikartojantis, atsakomybės aiškiai apibrėžtos, o duomenų modelis neiškraipo įmonės veiklos vaizdo. Tokiomis sąlygomis standartizavimas sutvarko informacijos srautus, sumažina vietinių interpretacijų skaičių ir leidžia priimti sprendimus remiantis nuosekliu įvykių registru. Problema atsiranda anksčiau nei trūkstamų funkcijų lygmenyje. Ji prasideda ten, kur reali gamybos, kokybės, techninės priežiūros ir planavimo eiga nebetelpa į sistemos logiką nepatiriant proceso nuostolių.

Tai riba tarp pagrįsto standartizavimo ir operatyvinės kontrolės praradimo. Jei organizacija pradeda apeiti savo pačios procesą vien tam, kad duomenys „sutaptų sistemoje“, informacijos architektūra nustoja tarnauti gamybai. Ji pradeda ją deformuoti. Dalį taisyklių galima saugiai suvienodinti konfigūracija arba procedūra, tačiau yra ir technologinių priklausomybių, kontrolės taškų bei atsakomybės grandžių, kurių negalima išplauti nepakenkiant gaminio kokybei, proceso saugai ar sprendimų atsekamumui. Todėl ginčas „paruošta ar nuosava“ dažniausiai formuluojamas neteisingai. Tikslesnis klausimas būtų toks: kurie proceso elementai yra bendras standartas, o kurie sudaro įmonės pranašumo esmę, rizikos šaltinį arba atitikties pareigų sritį ir turi būti atvaizduoti tiksliai.

Praktikoje brangiausiai kainuoja ne trūkstami moduliai, o apeinamosios priemonės, kurios tyliai tampa kasdieniu darbo būdu. Lentelės, pildomos greta sistemos, rankinis duomenų perrašymas tarp pamainos ir biuro, operatorių pastabos, neformalus išimčių derinimas ir lygiagretūs informacijos srautai nėra smulkus nepatogumas. Tai signalas, kad proceso valdymo modelis pradeda byrėti. Tokiu atveju verta matuoti ne funkcijų skaičių, o rankinių duomenų perrašymo taškų skaičių tarp gamybos, kokybės, techninės priežiūros ir planavimo, kritinių išimčių, tvarkomų už sistemos ribų, skaičių bei operatyvinių sprendimų, priimamų remiantis duomenimis ne tiesiogiai iš pirminio registro, dalį. Jei šie rodikliai auga, problema paprastai kyla ne dėl prastos konfigūracijos, o dėl klaidingos prielaidos, kad procesą galima be sąnaudų pritaikyti prie įrankio.

Tai ypač aiškiai matyti įmonėse, kur užsakymo eiga priklauso ne tik nuo technologinio maršruto, bet ir nuo faktinės įrenginio būklės, tarpoperacinės kontrolės rezultatų, medžiagų patvirtinimų, žaliavos partijos, nustatymo parametrų ir sprendimų, kuriuos laiko spaudimo sąlygomis vienu metu priima keli padaliniai. Jei paruošta sistema nepajėgia išlaikyti šių priklausomybių vienoje patikimoje duomenų grandinėje, tiesa apie procesą išsiskaido į kelias vietas. Dalis lieka sistemoje, dalis – prie įrenginio, dalis – kokybės dokumentuose, o dalis – žmonių žiniose. Tokia būsena apsunkina gamybos proceso žemėlapio sudarymą, komplikuoja diegimo vykdytojų atsakomybę ir didina projekto riziką integruojant su pramonės automatika bei sistemomis, turinčiomis įtakos mašinų saugai. Individuali programinė įranga yra prasminga ne tada, kai įmonė nori „kažko savo“, o tada, kai būtina išlaikyti proceso, pirminių duomenų ir sprendimų vienovę ten, kur supaprastinimas reikštų realų kontrolės praradimą.

Atitikties ir operatyvinės priežiūros požiūriu šis skirtumas yra esminis. Jei pagrindinės taisyklės ir kontrolės taškai egzistuoja tik komandos praktikoje, o sistemoje nėra priverstinai taikomi arba bent jau vienareikšmiškai atvaizduoti, atskaitomybė tampa sąlyginė. Vienose šakose tai pirmiausia bus kokybės ir partijos eigos atkuriamumo problema, kitose – taip pat sektorinių reikalavimų, atsekamumo, pakeitimų valdymo ar atsakomybės ribų tarp įmonės naudotojo, integratoriaus ir programinės įrangos tiekėjo klausimas. Todėl sprendimą, ar procesą pajungti sistemai, ar sistemą procesui, reikia grįsti ne funkcijų pristatymu, o sąžininga išimčių analize. Tik tada paaiškėja, kurios iš jų yra organizacinio chaoso požymis, o kurios atspindi realius technologinius, informacinius ir saugos reikalavimus.

Sąnaudos auga ten, kur sistema nemato realios rizikos

Didžiausią kainą sistemos neatitikimas sukelia ne paprastoje užsakymų apyvartoje ar kasdienėse ataskaitose, o ten, kur susikerta gamyba, kokybė, techninė priežiūra ir proceso sauga. Būtent čia sprendimą reikia priimti greitai, jį dokumentuoti ir pagrįsti visu kontekstu: esama mašinos būkle, partijos parametrais, intervencijų istorija, kokybės patvirtinimo būsena ir galiojančiais blokavimais. Jei parengtas gamybos vykdymo ar ERP sprendimas mato tik dalį šio vaizdo, sąnaudos neapsiriboja naudotojo nepatogumu. Atsiranda veiklos kintamumas. Skirtingos pamainos panašius sprendimus priima remdamosi skirtingais duomenimis, išimtys tvarkomos savo nuožiūra, o atsakomybė išsiskaido tarp sistemos, procedūros ir cecho praktikos.

Svarbiausia problema prasideda tada, kai sistema neatspindi tikrosios veiksmų sekos, blokavimo sąlygų, technologinių parametrų versijavimo ar atsakomybės už nuokrypio patvirtinimą. Įrašuose viskas gali atrodyti teisinga, nors realus vykdymas vyko kitaip. Taip atsiranda spraga tarp įvykio ir jo skaitmeninio pėdsako. Tai verčia priimti labai konkrečius projektinius sprendimus: ar kritiniai proceso blokavimai turi veikti sistemos lygmeniu, ar tik procedūriškai; ar duomenys iš mašinų yra veiklos įrodymas, ar tik pagalbinė medžiaga; ir ar išimtys turi būti valdomos pagal suprojektuotą sprendimų eigą, ar paliekamos subjektyviam vertinimui. Jei įmonė remiasi rankiniais prierašais, papildomomis lentelėmis ar sąsajomis, kurioms nuolat reikia žmogaus įsikišimo, duomenų patikimumą reikia vertinti ne pagal tai, ar galima sugeneruoti galutinę ataskaitą, o pagal tai, ar galima be ginčo atkurti vieno neatitikimo, skundo ar linijos sustabdymo eigą.

Ypatinga rizika išryškėja įmonėse, turinčiose išplėtotą mašinų parką, kur sistema turi veikti kartu su pramonės automatika, operatorių darbo vietomis ir kontrolės bei matavimo įranga. Jei integracija su įrenginiais yra dalinė, procesinių duomenų surinkimas nenuoseklus, o pakeitimų istorija išskaidyta tarp valdiklio, pulto, gamybos duomenų bazės ir techninės priežiūros pastabų, partijos atsekamumas ir gaminio genealogija tampa sąlyginiai. Panašiai atrodo ir technologinių pakeitimų valdymas. Receptūros, tolerancijos ribos ar perstatymo logikos pakeitimas gali būti formaliai patvirtintas, tačiau be nuoseklaus versijavimo ir archyvavimo vėliau neįmanoma įrodyti, kokia konfigūracija iš tikrųjų galiojo įvykio momentu. Tai nėra sistemos architektūros estetikos klausimas, o atkuriamumo, pirminių priežasčių nustatymo ir atsakomybės ribų tarp gamybos, techninės priežiūros, kokybės bei integracijos tiekėjų klausimas.

Tokio neatitikimo kaina retai matoma diegimo biudžete. Ji išryškėja vėliau kaip diagnostinės prastovos, išaugęs rankinis darbas, skundai, ginčai dėl įvykio priežasties ir prarasta galimybė vienareikšmiškai atkurti proceso eigą. Todėl vertinant sprendimą nepakanka klausti, ar sistema „aptarnauja gamybą“. Reikia patikrinti, kiek sąsajų reikia taisyti rankiniu būdu, kiek kritinių parametrų nėra automatiškai versijuojami ar nuosekliai archyvuojami ir kiek laiko užtrunka vieno veiklos incidento rekonstrukcija. Jei atsakymas yra: ilgai, nenuosekliai ir pasitelkiant kelis nepriklausomus šaltinius, problema susijusi ne su naudotojo patogumu, o su rizikos valdomumu. Būtent čia nuosavas sprendimas arba bent jau dedikuotas sluoksnis virš parengtos sistemos dažnai yra pagrįstas: ne tam, kad būtų geriau raportuojama praeitis, o tam, kad būtų palaikomi saugūs operaciniai sprendimai tuo metu, kai įmonė veikia laiko ir atsakomybės spaudimo sąlygomis.

Atitikties požiūriu tai reiškia dar vieną dalyką. Ten, kur programinė įranga daro įtaką sprendimų eigai, svarbiai kokybei, atsekamumui ar proceso saugai, kritinių funkcijų apimtis turėtų būti nustatoma pagal realią rizikos analizę, o ne pagal standartinių modulių katalogą. Tai ypač taikoma integracijai su mašinomis, išskirtinių būsenų valdymui ir toms vietoms, kur sistema turi priverstinai užtikrinti tam tikrą veiksmų seką arba blokuoti perėjimą į kitą etapą. Tokiose srityse verta atskirti apskaitines funkcijas nuo tų, kurios tampa operacinės kontrolės dalimi ir reikalauja tvirtesnio projektinio pagrindimo, taip pat ir mašinų saugos bei integratoriaus atsakomybės kontekste.

Pirmiausia sprendimų projektas, tik po to kodas

Pagrįstas sprendimas dėl sistemos plėtros įmonėje prasideda ne nuo funkcijų sąrašo, o nuo operacinių sprendimų, kuriuos programinė įranga turi palaikyti arba priverstinai užtikrinti, žemėlapio. Reikia nustatyti, kas priima sprendimą, kokių duomenų pagrindu, per kiek laiko ir su kokiomis pasekmėmis gamybai, kokybei, atsekamumui ar proceso saugai. Tik šiame kontekste matyti, ar parengtas gamybos vykdymo ar ERP sprendimas apima problemos esmę, ar tik sutvarko apskaitą po fakto. Jei kritinis yra ne pats įvykio registravimas, o kitos operacijos paleidimo blokavimas, partijos patvirtinimo sąlyga, mašinos nustatymų atitikties patvirtinimas ar nuokrypio valdymas, klausimas turi būti ne „ar sistema tai turi“, o „ar ji gali priverstinai užtikrinti teisingą sprendimą tinkamu momentu“.

Toks mąstymo būdas taip pat padeda aiškiau suprojektuoti architektūrą. Praktikoje dažniausiai pasiteisina hibridinis modelis. Standartinė ERP arba gamybos vykdymo sistema turėtų likti ten, kur procesas yra bendras, pasikartojantis ir gerai aprašomas brandžiu duomenų modeliu: planavime, gamybos apskaitoje, sandėlio valdyme bei bazinėje užsakymų ir partijų apskaitoje. Dedikuotas sluoksnis turi prasmę tada, kai perima konkrečiai gamyklai kritinę logiką: integraciją su įrenginiais, įvykių iš kelių šaltinių validavimą, išimčių valdymą, tvirtinimo eigas, audito pėdsaką ir sprendimų susiejimą su konkrečia partija, įrenginiu bei atsakingu asmeniu. Tačiau sėkmės sąlyga yra iš anksto aiškiai nustatytos atsakomybės ribos. Komanda turi nuspręsti, kas priklauso technologiniam procesui ir lieka automatikos ar valdymo pusėje, kas yra ERP arba gamybos vykdymo sistemos sritis, ką įgyvendina integracinis sluoksnis, o kas vis dar turi likti organizacinėse procedūrose.

Be tokio pasidalijimo atsiranda brangiai kainuojanti improvizacija. Ta pati sąlyga kartais būna aprašyta keliose vietose, išimtys sprendžiamos rankiniu būdu, o po kelių mėnesių niekas nebegali vienareikšmiškai pasakyti, kuri sistema atsako už sprendimą, blokuojantį arba leidžiantį tęsti procesą. Todėl geras dedikuotas projektas nėra paruošto sprendimo dubliavimas mažesniu mastu. Jo paskirtis – užpildyti konkrečią sprendimų priėmimo spragą. Dėl to jau projektavimo etape verta sudaryti kritinių sprendimų, kuriems šiandien trūksta sisteminio palaikymo arba priverstinio vykdymo, sąrašą, o tada jį palyginti su procesinių išimčių, kurias sprendimas turės aptarnauti nuo pat pirmojo paleidimo, skaičiumi. Tai svarbiau nei išplėstinė ekranų specifikacija.

Praktinis pavyzdys paprastas. Paruošta sistema gali tinkamai apskaityti gamybą, medžiagų sunaudojimą ir priėmimą į sandėlį, tačiau neapimti specifinių kokybės blokadų, susijusių su sąlyginiu partijos išleidimu. Partija gali būti formaliai pagaminta ir užregistruota, bet vis tiek neturėtų pereiti į kitą etapą, kol nepatvirtinti konkretūs tyrimų rezultatai, linijos perstatymo būsena arba nepašalintas nuokrypis iš ankstesnės operacijos. Jeigu tokia sąlyga šiandien kontroliuojama telefonu, lentele ar parašu ant atspausdinto dokumento, tai nėra proceso estetikos klausimas, o atsakomybės valdymo spraga. Tokiu atveju visos ERP arba gamybos vykdymo sistemos perprojektavimas paprastai nėra pagrįstas. Pakanka dedikuoto sluoksnio, kuris surenka duomenis iš mašinų ir šaltinių sistemų, tikrina įvykių pilnumą, paleidžia tinkamą tvirtinimo eigą ir perduoda aukštesnio lygmens sistemai vienareikšmį partijos statusą. Standartas lieka standartu, o kritinė logika įrašoma ten, kur ją galima realiai valdyti ir prižiūrėti.

Jeigu gamykla dar neturi sąnaudų duomenų, jų nereikia spėlioti. Pakanka pradėti matuoti, kiek laiko per mėnesį sunaudoja rankiniai apėjimai, papildomi derinimai, partijų korekcijos ir neatitikimų tarp sistemos bei realios proceso būsenos tikrinimas. Tokia medžiaga leidžia atskirti pagrįstą dedikuotą sluoksnį nuo projekto, rašomo „dėl visa ko“. Ji taip pat padeda tinkamai pasidalyti vaidmenimis verslo pusėje. Dėl sistemoje įrašomos logikos apimties neturėtų spręsti vien IT skyrius ar vien integratorius – tai turi būti bendras gamybos, kokybės, techninės priežiūros, už skaitmeninimą atsakingų asmenų bei, kur tai svarbu, integratoriaus, programinės įrangos kūrėjo ir techninės priežiūros padalinio bendradarbiavimas, taip pat mašinų sauga ir eksploatacinė atitiktis.

Projektinės atsakomybės požiūriu tai turi dar vieną pasekmę. Kuo arčiau programinė įranga priartėja prie proceso perėjimo sąlygų, operacijų blokadų, veiksmų sekos teisingumo ar duomenų, gaunamų tiesiogiai iš įrenginio, tuo mažiau ją galima laikyti neutraliu IT priedu. Tokioje srityje būtinos aiškiai apibrėžtos projektinės prielaidos, veikimo ir priežiūros ribų aprašymas, pakeitimų valdymo taisyklės bei patikrinamas pėdsakas, kas ir kuo remdamasis patvirtino kritinę logiką. Todėl prieš parašant pirmąją kodo eilutę verta patvirtinti ne tik funkcinius reikalavimus, bet pirmiausia sprendimų projektą: ką sistema turi priverstinai užtikrinti, ko ji neturi leisti padaryti ir kuriame taške žmogus lieka paskutine atsakomybės instancija.

Atitiktis yra gero projekto pasekmė, o ne puošmena po diegimo

Pramonės įmonėje programinė įranga nėra neutralus proceso priedas – ji yra dalis to, kaip procesas vykdomas. Ji gali nustatyti veiksmų eiliškumą, blokuoti perėjimą į kitą etapą, priverstinai užtikrinti duomenų pilnumą, nukreipti tvirtinimo eigą ir nulemti, ar po įvykio bus įmanoma atkurti sprendimų eigą bei atsakomybę. Dėl šios priežasties atitiktis neprasideda nuo formalių reikalavimų prirašymo diegimo pabaigoje. Ji prasideda nuo projekto, kuriame sąmoningai apibrėžiama, kokius sprendimus sistema priima pati, kokius tik palaiko, kokius duomenis laiko privalomais ir kas yra taisyklių, išimčių bei pakeitimų savininkas.

Jei ši tvarka nesukuriama sprendimo architektūros etape, vėlesnis rėmimasis kokybės reikalavimais, proceso sauga ar dokumentavimo pareigomis tampa tik formaliu veiksmu. Tai ypač svarbu tada, kai sistema daro įtaką sprendimams, reikšmingiems gaminio kokybei, proceso saugai arba sąveikai su mašinomis ir įrenginiais. Tokiu atveju atitikties reikalavimus reikia suprasti praktiškai: kaip veikimo nuoseklumo, atsekamumo, pakeitimų kontrolės ir sprendimo tinkamumo realiam taikymui poreikį. Svarbu ne vien tai, kad funkcija būtų prieinama, bet ir tai, kad būtų galima parodyti, kodėl ji veikia būtent taip, kas patvirtino jos logiką ir kaip vertinamas jos pakeitimų poveikis.

Daugiausia problemų paprastai išryškėja ne paleidimo metu, o po kelių eksploatacijos mėnesių. Įmonė įveda naują gamybos variantą, pakeičia priėmimo kriterijus, prijungia dar vieną darbo vietą arba dalį atsakomybės perkelia nuo operatoriaus sistemai. Jei iš anksto nebuvo nustatyta, kurios sprendimų ir įrašų klasės turi palikti audito pėdsaką, greitai kyla ginčas, kieno pakeitimas paveikė kokybę, prastovą ar neteisingą sistemos reakciją. Būtent tada išryškėja skirtumas tarp veikiančio ir valdomo sprendimo. Antruoju atveju iš anksto aišku, kuriems logikos elementams būtina formali patvirtinimo eiga, kas prižiūri etaloninius duomenis, kas palaiko integraciją su pramonės automatika ir ar projekto dokumentacijos pakanka auditui, priežiūrai bei saugiam sistemos perėmimui kito rangovo.

• kokius sprendimus sistema priima arba padeda formuoti kokybės, saugos ir sąveikos su mašina srityje,
• kokie įvykiai, pakeitimai ir patvirtinimai turi palikti atkuriamą pėdsaką,
• kas yra verslo taisyklių, duomenų ir išimčių savininkas ir kas tvirtina jų pakeitimus.

Tik po tokio sutvarkymo prasminga projektą sieti su teisiniais ir norminiais reikalavimais, taikomais konkrečiai įmonei, gaminiui, pramonės šakai ir integravimo su mašinomis ar įrenginiais būdui. Lenkijos ir Europos Sąjungos sąlygomis klausimas skamba ne tik taip, ar sprendimas veikia, bet ir ar organizacija gali parodyti, kodėl jis veikia būtent taip, kuo remiantis buvo patvirtintos taisyklės ir kaip valdomi pakeitimai nesusilpninant atsekamumo. Šios analizės apimtis visada priklauso nuo taikymo srities: kitaip vertinama ataskaitų teikimo sistema, kitaip – logika, daranti įtaką proceso eigai, o dar kitaip – integracija, susijusi su mašinos veikimu, rizikos vertinimu arba integratoriaus atsakomybės apimtimi.

Išvada paprasta. Individualiai kuriama programinė įranga yra pagrįstas pasirinkimas tada, kai ji aiškiai paskirsto atsakomybę ir mažina riziką būtent ten, kur parengtas gamybos vykdymo sistemos arba ERP sprendimas pareikalautų brangių kompromisų proceso logikoje, pakeitimų priežiūroje ar veiksmų atsekamume. Taigi esmė nėra viską kurti nuo nulio, o taip atskirti standartines ir kritines logikos dalis, kad sistema palaikytų realų įmonės procesą, užuot jį supaprastinusi kokybės, saugos ir atsekamumo sąskaita.