Traceability programėlių projektavimas – kaip kurti produkto ir proceso atsekamumo grandinę?

Traceability programėlių projektavimas nebėra tik gamybos sistemos priedas – tai sprendimas, darantis įtaką operacinei atsakomybei, pakeitimų kaštams ir įmonės gebėjimui pagrįsti savo sprendimus. Produkto ir proceso atsekamumo grandinė šiandien turi atsakyti ne tik į klausimą „kas buvo pagaminta“, bet ir „iš ko, pagal kurią receptūros versiją, kokiais parametrais, naudojant kokį išteklių ir su kokiu kontrolės rezultatu“. Jei šis modelis neapibrėžiamas pačioje pradžioje, projektas labai greitai praranda nuoseklumą: duomenys renkami, tačiau nesudaro proceso eigos įrodymo, o vėlesnis spragų taisymas reiškia brangų integracijų, operatorių sąsajų ir ataskaitų teikimo pertvarkymą. Praktikoje esmė yra ne vien įvykių kaupimas, bet tokios ryšių grandinės suprojektavimas, kuri leistų atkurti produkto vieneto istoriją ir pagrįsti proceso sprendimus.

Daugiausia klaidų atsiranda tada, kai pasirenkamas pernelyg bendras verslo tikslas, pavyzdžiui, „norime turėti visišką atsekamumą“, nenurodant, koks yra minimalus sekimo vienetas ir kokio įrodomumo lygio reikia pasiekti. Projektavimo komandai tai esminis skirtumas. Kitaip projektuojama programėlė, kuri turi identifikuoti žaliavos partiją ir jos sunaudojimo momentą, ir kitaip – sistema, kuri konkrečiam gaminiui turi priskirti operatorių, mašinos programą, bandymo rezultatą, įrankio numerį ir proceso nuokrypį. Tai tiesiogiai veikia duomenų architektūrą, saugojimo trukmę, žymėjimo būdą, integracijos su pramonės automatika apkrovą ir validavimo apimtį. Praktinis sprendimo kriterijus paprastas: jei komanda pagal trumpą skundo ar audito scenarijų negali atkurti vieno produkto vieneto istorijos nesiremdama neformaliais šaltiniais, vadinasi, traceability projektas buvo apibrėžtas per silpnai arba netinkamu detalumo lygiu.

Geras pavyzdys – gamybos linija, kurioje tas pats gaminys gali pereiti per kelis proceso variantus, o dalis operacijų atliekama automatiškai, dalis – rankiniu būdu. Jei programėlė registruoja tik užsakymo užbaigimą ir partijos numerį, atsiradus kokybės nuokrypiui nebeįmanoma atskirti medžiagos problemos nuo vykdymo klaidos, neteisingos darbo vietos konfigūracijos ar pasenusios instrukcijos naudojimo. Tuomet kaštai kyla ne vien dėl reklamacijų. Didėja ir priežasčių analizės sąnaudos, atšaukimo mastas, prastovos trukmė bei neteisingo korekcinio sprendimo rizika. Dėl tos pačios priežasties traceability negali būti projektuojamas atskirai nuo prieigos taisyklių. Jei keli vaidmenys gali keisti būsenas, patvirtinimus ar etaloninius duomenis be aiškiai priskirtų teisių ir operacijų registro, atsekamumo grandinė tampa pažeidžiama ginčų atveju: sistema rodo rezultatą, bet nesuteikia tikrumo, kas ir kokiu pagrindu jį sukūrė arba pakeitė. Šioje vietoje tema natūraliai pereina į mažiausių teisių principo ir prieigos segmentavimo pramoninėse programėlėse sritį.

Panaši riba atsiranda ir tada, kai duomenys gaunami tiesiogiai iš mašinų ir vykdomųjų įrenginių. Kol programėlė tik fiksuoja proceso eigą, kalbame apie atsekamumo sluoksnį. Tačiau jei remiantis tomis pačiomis būsenomis turi būti sukurta blokavimo logika, energijos atjungimas, saugaus sustabdymo patvirtinimas arba leidimas paleisti iš naujo, klausimas jau pereina į apsaugos nuo netikėto paleidimo sritį ir negali būti sprendžiamas vien programėlės lygmeniu. Analogiškai, kai pėdsako patikimumas priklauso nuo teisingo signalų, jutiklių, žymų ir prijungimo taškų priskyrimo, sprendimai krypsta link mašinų elektros instaliacijos ir kabelių pynių projektavimo. Tai svarbus skirtumas: traceability programėlė gali tvarkyti įrodymus, tačiau ji nepakeičia nei funkcinės saugos sprendimų, nei tinkamai suprojektuoto aparatinio sluoksnio. Ši riba ypač svarbi vertinant mašinų ir gamybos linijų saugą.

Remtis norminiais reikalavimais prasminga tik taip atskyrus atsakomybes. Priklausomai nuo šakos, gaminio ir sistemos vaidmens, reikia atskirti reikalavimus, susijusius su atsekamumu, kokybės įrašais, duomenų vientisumu, kibernetiniu saugumu ir mašinos sauga. Ne kiekvienam projektui bus taikomas tas pats režimas, tačiau kiekvienas jau pradžioje turėtų atsakyti į tris klausimus: kokį objektą sekame, kokį įrodymą turime gebėti atkurti ir kas gali į šią grandinę įsikišti. Tik tada galima pagrįstai nustatyti integracijos apimtį, teisių modelį ir rodiklių rinkinį, kurį verta matuoti, pavyzdžiui, įvykių pilnumą, gaminio istorijos atkūrimo laiką, įrašų, kuriuos reikia taisyti, skaičių ir operacijų be vienareikšmio vykdytojo priskyrimo dalį. Tai rodikliai, kurie greitai parodo, ar programėlė iš tiesų kuria atsekamumą, ar tik generuoja duomenis.

Kur dažniausiai didėja kaštai arba rizika

Traceability taikomųjų sprendimų projektuose sąnaudos retai didėja todėl, kad „reikia rinkti daug duomenų“. Dažniausiai problema prasideda tada, kai atsekamumo grandinė projektuojama nuo ekranų ir ataskaitų pusės, o ne nuo įvykių, kurie vėliau turi būti proceso eigos įrodymas. Jei komanda pradžioje nenusistato, kurios operacijos formuoja gaminio būseną, kurios ją tik aprašo, o kurios yra korekcija po fakto, sistema greitai pradeda maišyti operacinius duomenis su įrodomaisiais duomenimis. Pasekmės yra labai praktinės: daugėja išimčių, rankinių įrašų papildymų ir ginčų, kuri istorijos versija yra galiojanti. Tai didina ne tik diegimo ir priežiūros sąnaudas, bet ir atsakomybę nagrinėjant reklamaciją, atkuriant partiją, atliekant auditą ar tyrimą. Geras projekto vertinimo kriterijus yra paprastas klausimas: ar kiekvienai kritinei operacijai galima vienareikšmiškai nurodyti įrašo momentą, autorių, duomenų šaltinį ir poveikį produkto būsenai, nesiremiant žodinėmis operatorių ar programuotojų žiniomis.

Antras tipiškas rizikos šaltinis – per vėlai atskirta riba tarp atsekamumo ir klaidų prevencijos. Jei taikomoji sistema turi patvirtinti, kad tinkamas komponentas pateko į tinkamą gaminį, vien kodo nuskaitymo paprastai nepakanka, jei fiziškai vis dar įmanoma sumontuoti neteisingą detalę arba apeiti etapą dėl netinkamo darbo vietos prijungimo. Čia tema natūraliai pereina į sprendimų, skirtų montavimo klaidų prevencijai ir proceso teisingumui užtikrinti, sritį, nes klaidingo sprendimo kaina jau slypi ne duomenų bazėje, o neteisingo veiksmo leidime gamybos linijoje. Jei neįmanoma parodyti, kad įrašas sistemoje atitinka faktiškai atliktą operaciją, taikomoji sistema tik sukuria kontrolės regimybę. Sprendimo kriterijus čia griežtas: jei klaidą galima padaryti nepaisant teisingo įrašo sistemoje, reikia projektuoti ir proceso arba darbo vietos apsaugą, o ne vien skaitmeninio pėdsako logiką.

Panašus mechanizmas matomas sąsajoje su aparatine įranga. Projektuose, apimančiuose mašinas, testerius, įtaisus ir prijungimo taškus, sąnaudos didėja tada, kai taikomoji sistema turi kompensuoti signalų projekto, laidų identifikavimo, įėjimų ir išėjimų būsenų arba jungčių numeravimo trūkumus. Praktinis pavyzdys paprastas: sistema įrašo, kad bandymas atliktas, tačiau nėra tikrumo, kuris egzempliorius iš tikrųjų buvo prijungtas, kuris adapteris dalyvavo operacijoje ir ar rezultatas buvo priskirtas tinkamam serijos numeriui. Tokiu atveju vėlesni pataisymai neapsiriboja vienos formos pakeitimu – tenka perprojektuoti sąsajas, blokavimo logiką ir dažnai pačią elektros instaliaciją arba mašinos kabelių pynes. Tai brangūs pakeitimai, nes jie paliečia validavimą, techninę dokumentaciją ir darbo vietų prastovas. Praktinis kriterijus toks: jei taikomoji sistema reikalauja, kad operatorius rankiniu būdu patvirtintų faktus, kuriuos galima vienareikšmiškai nustatyti signalu, jutikliu arba fiziniu prijungimo raktu, projektavimo klaidos rizika yra didelė.

Atskira sąnaudų kategorija yra korekcijos ir išimtys. Daugelyje diegimų daroma prielaida, kad galimybė redaguoti įrašą „dėl visa ko“ palengvins darbą. Praktikoje tai atveria brangiausią sritį: vėliau tenka spręsti, kas yra pirminis įvykis, kas – korekcija, kas turėjo pagrindą ją atlikti ir ar pakeitimas nepažeidė įrodymų tęstinumo. Jei taikomoji sistema neskiria panaikinimo, pakartotinio operacijos atlikimo ir administracinio aprašomųjų duomenų pataisymo, komanda praranda galimybę apginti įrašo kokybę. Todėl verta matuoti ne tik įvykių pilnumą, bet ir įrašų, kuriems reikėjo korekcijos, dalį, operacijų be vienareikšmio vykdytojo priskyrimo skaičių bei laiką, per kurį po neatitikties atkuriama visa gaminio istorija. Kai šie rodikliai blogėja nepaisant sistemos plėtros, problema paprastai slypi atsakomybių modelyje ir proceso architektūroje, o ne pačioje naudotojo sąsajoje.

Tik šiame etape prasmingai sugrįžta klausimas apie norminius reikalavimus ir rizikos vertinimą. Ne todėl, kad kiekviena traceability taikomoji sistema iš karto tampa saugos sistema, bet todėl, kad klaidinga identifikacija, neteisingas rezultato priskyrimas arba galimybė apeiti kontrolę gali turėti skirtingą pasekmių svorį priklausomai nuo gaminio ir jo paskirties. Jei neteisingas įrašas sukelia tik administracinių nepatogumų, projektavimo sprendimai bus kitokie nei tada, kai jis gali lemti neatitinkančio gaminio leidimą į tolesnį procesą arba apsunkinti reikalavimų įvykdymo įrodymą. Tokiais atvejais rizikos vertinimas negali būti priedas po diegimo. Jis turi atsakyti, kurios taikomosios sistemos klaidos yra tik nepatogios, o kurios keičia gamintojo, integratoriaus ar mašinos naudotojo atsakomybės profilį. Šis atskyrimas taip pat padeda aiškiai nustatyti ribą tarp paties atsekamumo, klaidų prevencijos sprendimų ir elektrinės bei signalų dalies projekto.

Kaip prie to prieiti praktiškai

Praktikoje traceability taikomųjų programų projektavimą reikia pradėti ne nuo operatoriaus ekrano ir ne nuo ženklinimo technologijos pasirinkimo, o nuo sprendimo, kokią istoriją vėliau turi būti įmanoma atkurti be spėlionių. Toks, atrodytų, nedidelis akcento perkėlimas dažniausiai lemia projekto kainą. Jei komanda registruoja „viską, ką tik įmanoma“, greitai auga duomenų apimtis, išimčių skaičius ir priežiūros apimtis, tačiau reklamacijos ar audito metu vis tiek pritrūksta atsakymo į esminį klausimą: kas, kada, kokiu pagrindu ir kurio gaminio vieneto atžvilgiu pakeitė jo būseną. Jei modelis per skurdus, atsakomybė už proceso eigos atkūrimą perkeliama žmonėms, pagalbinėms lentelėms ir pamainos vadovo atminčiai. Praktinis kriterijus čia paprastas: kiekvienam proceso etapui turi būti įmanoma nurodyti minimalų duomenų rinkinį, be kurio neįmanoma patikimai patvirtinti medžiagos kilmės, operacijos rezultato ir sprendimo perduoti gaminį į kitą etapą. Tai ir yra tinkamas atspirties taškas kalbant apie taikomosios programos apimtį ir integracijos ribas.

Iš to kyla antras sprendimas: ar taikomoji programa turi tik registruoti įvykius, ar ir priverstinai užtikrinti operacijų seką bei jų sąlygas. Šis skirtumas keičia projektavimo atsakomybę. Registravimo sistemą galima įdiegti greičiau, tačiau ji palieka daugiau erdvės proceso apėjimui ir vėlesniems ginčams dėl duomenų kokybės. Sistema, kuri neleidžia pereiti toliau, kol neįvykdytos sąlygos, stipriau palaiko atitiktį, tačiau reikalauja tiksliai aprašyti būsenas, išimtis ir vaidmenis. Tai tiesiogiai veikia grafiką, bandymus ir priėmimą. Todėl geras sprendimas nėra „didesnė automatizacija“, o sąmoningas trijų sluoksnių atskyrimas: objekto identifikavimo, operacijos atlikimo patvirtinimo ir leidimo pereiti į kitą žingsnį. Jei šie sluoksniai susilieja į vieną mygtuką, projektas bus pigesnis tik iš pažiūros, nes išlaidos sugrįš validavimo, reklamacijų ar proceso pakeitimų metu. Vertinant situaciją verta taikyti vieną kriterijų: ar viena naudotojo klaida arba ryšio klaida gali pakeisti gaminio būseną nepalikdama vienareikšmio pėdsako ir nesuteikdama galimybės nustatyti priežasties.

Geras pavyzdys – gamyba, kurioje atsekamumas apima ne tik galutinį gaminį, bet ir darbo vietos konfigūraciją. Tam tikru momentu tema natūraliai pereina į elektros instaliacijų ir mašinų kabelių pynių projektavimo sritį, nes taikomoji programa nustoja būti vien IT antstatu. Jei rezultato priskyrimo teisingumas priklauso nuo konkretaus jutiklio signalo, valdiklio pasirinkto recepto arba nuo to, ar atpažįstama, kad tinkamas įrankis prijungtas prie tinkamo lizdo, atsekamumo grandinė turi apimti ir signalo šaltinį, jo vienareikšmiškumą bei susiejimo su proceso įrašu būdą. Panašiai būna ir su suvirinimo įranga: kai įrangos numeris, jos versija, nustatymai ar tvirtinimo patvirtinimas turi įtakos operacijos teisingumo vertinimui, traceability jau apima ne tik detalę ir operatorių, bet ir įrangą kaip kontroliuojamą objektą. Tuomet projektinis sprendimas skamba ne „ar pridėti dar vieną lauką formoje“, o „ar ši priklausomybė turi būti deklaruojama rankiniu būdu, ar patvirtinama techniškai“. Tai riba, ties kuria klaidingas taupymas signalų sluoksnyje arba blokavimo logikoje labai greitai virsta neatitikties priežasčių aiškinimosi sąnaudomis. Tokiose pramoninės automatikos integracijose ypač svarbu, kad ryšys tarp fizinio signalo ir proceso įrašo būtų aiškus bei patikrinamas.

Tik šiame etape verta grįžti prie formaliųjų reikalavimų. Ne kiekvienai traceability taikomajai programai taikomas tas pats režimas, tačiau jei įrašai turi būti naudojami atitikčiai įrodyti, partijai išleisti, kritiniams parametrams apskaityti arba istorijai atkurti reguliuojamoje aplinkoje, reikalavimai jau apima ne tik funkcionalumą, bet ir duomenų vientisumą, pakeitimų valdymą, teises bei audito pėdsako patikimumą. Šakose, kuriose taikoma griežtesnė priežiūra, įskaitant tas, kur svarbus mašinų projektavimas farmacijos pramonei ir reikalavimai, kylantys iš geros gamybos praktikos principų, svarbu ne pats duomenų kaupimo faktas, o galimybė įrodyti, kad įrašas yra išsamus, priskirtas tinkamam veiksmui ir atsparus nedokumentuotiems pakeitimams. Todėl praktinis sprendimas vadovui ir produkto savininkui turėtų būti aiškiai dokumentuotas: kurie įvykiai turi įrodomąją reikšmę, kurie – tik operacinę, kas atsako už jų patikimumą ir kurioje sistemos architektūros vietoje būtinas techninis sprendimas, valdymo logika arba proceso validavimas. Be to traceability lieka naudinga funkcija, tačiau netampa priemone, kuria būtų galima saugiai grįsti organizacijos atsakomybę.

Į ką atkreipti dėmesį diegiant

Diegiant traceability programą daugiausia problemų kyla ne dėl funkcijų trūkumo, o dėl neteisingai apibrėžtos sistemos atsakomybės ribos. Jei atsekamumo grandinė turi apimti ir gaminį, ir procesą, iš anksto reikia nuspręsti, ar programa tik registruoja įvykius, ar taip pat patvirtina, kad operacijos atliktos teisingai. Tai nėra vien semantinis skirtumas. Pirmuoju atveju operatoriaus klaida gali būti tiksliai užfiksuota, tačiau ji nebus sustabdyta. Antruoju atveju sistema pradeda veikti gamybos eigą, todėl paliečia blokavimo logiką, operacijų seką ir gaminio išleidimo sąlygas. Projektui tai reiškia kitokią bandymų apimtį, didesnę atsakomybę už netinkamo veikimo pasekmes ir paprastai didesnę pakeitimų kainą vėlyvame etape. Praktinis kriterijus paprastas: jei dėl įrašo nebuvimo arba klaidingos identifikacijos gali būti panaudotas netinkamas komponentas, neteisinga konfigūracija ar neįformintas nukrypimas, vien „sekimo“ nebeužtenka ir tema natūraliai pereina į apsaugos nuo klaidų darbo vietoje sritį, taip pat į ribą tarp atsekamumo ir gamybos linijos saugos.

Antra dažna klaida – duomenų modelį projektuoti tik pagal galutinę ataskaitą, nepatikrinus, kaip įvykis iš tikrųjų atsiranda ceche ar technologiniame procese. Atsekamumas yra toks geras, kaip silpniausia priskyrimo vieta: ranka įvestas partijos numeris, nuskaitymas po fakto, neatskirtas planuotas ir faktiškai atliktas surinkimas. Praktikoje reikia įvertinti, ar duomenų šaltinis yra pakankamai vienareikšmis ir ar registravimo momentas atitinka realų veiksmą. Jei operatorius gali uždaryti operaciją fiziškai nepatvirtinęs detalės, įrankio ar pynės buvimo, programa tik sukuria kontrolės regimybę. Būtent čia traceability projektas pradeda liestis su pramonės automatika ir mašinų elektros instaliacijos bei kabelių pynių projektavimu, nes nuo laidų, jungčių ir prijungimo taškų žymėjimo būdo priklauso, ar įrašą bus galima priskirti konkrečiai konfigūracijai, ar tik bendram surinkimo etapui.

Geras pavyzdys – darbo vieta, kurioje registruojamas mazgo surinkimas ir technologinės operacijos rezultatas. Jei programa įrašo tik užsakymo numerį, operatoriaus identifikatorių ir operacijos laiką, ji atkurs istoriją partijos lygmeniu, bet nepaaiškins, kuri konkreti detalė buvo sumontuota, kokiu variantu ir kokio patvirtinimo pagrindu. Kai vėliau atsiranda reklamacija arba reikia atskirti gaminius iš rizikingos serijos, sąnaudos auga ne tiesiškai, o šuoliu: tenka išplėsti tyrimo apimtį, taikyti karantiną didesniam gaminių kiekiui ir įtraukti daugiau žmonių rankiniam įvykių atkūrimui. Todėl prieš diegimą verta priimti vieną vertinimo kriterijų: ar kiekvienam kritiniam įvykiui galima neginčijamai nurodyti penkis elementus – kas buvo atlikta, su kuo, iš ko, kas tai atliko ir kokio patvirtinančio signalo pagrindu. Jei kurio nors iš šių elementų neįmanoma patikimai gauti, reikia keisti ne tik programą, bet dažnai ir įrangą, ženklinimo būdą arba darbo seką; panaši priklausomybė pasireiškia ir projektuojant suvirinimo įtaisus, kur pozicionavimas ir pakartojamumas tiesiogiai lemia vėlesnio įrašo kokybę.

Tik šiame etape verta pereiti prie formaliųjų reikalavimų. Jei įrašas turi turėti įrodomąją reikšmę, būti naudojamas atitikčiai pagrįsti arba sudaryti kokybės sprendimo pagrindą, reikia įvertinti ne tik duomenų išsamumą, bet ir jų vientisumą, pakeitimų atsekamumą bei atsparumą procedūros apeidinėjimui. Aplinkose, kuriose priežiūros reikalavimai yra aukštesni, tai reiškia poreikį nuosekliai valdyti teises, receptūrų versijas, įrenginių būsenas ir audito pėdsaką, tačiau šių pareigų apimtis visada priklauso nuo sistemos paskirties ir įrašo vaidmens sprendimų priėmimo procese. Vadovo požiūriu svarbiausias klausimas todėl yra ne tai, ar programa „turi traceability“, o tai, ar remdamasi jos duomenimis organizacija yra pasirengusi prisiimti atsakomybę už gaminio išleidimą, neatitikties analizę ar incidento pasekmių apribojimą. Šis sprendimas turi būti priimtas dar prieš diegimo pradžią, nes paleidus sistemą brangiausiai kainuoja ne trūkstami ekranai, o neteisingai nustatyta riba tarp registro, proceso kontrolės ir atsakomybės už sprendimą.