Tööstusele mõeldud kohandatud tarkvara – millal valmis FEM/ERP-süsteem ei ole enam mõistlik valik

Valmis tootmise juhtimissüsteem või ERP võib olla mõistlik valik, kuid ainult siis, kui tootmise tegelikku kulgu on võimalik kirjeldada ilma oluliste lihtsustusteta. Vastasel juhul korrastab süsteem arvestust protsessi juhitavuse arvelt. See on hetk, mil funktsioonide loetelu lakkab olemast määrav. Tuleb hinnata, kas tehas juhib endiselt ise oma tootmist, kvaliteeti ja hooldust või hakkab töökorraldust kohandama tööriista piirangute järgi. Kui kriitilised otsused, erandid ja blokeeringud toimivad peamiselt süsteemiväliselt, ei ole tööstusele mõeldud kohandatud tarkvara kapriis. Sellest saab viis taastada andmete terviklikkus, vastutus ja operatiivne kontroll.

Kõiki tootmisprotsesse ei saa ausalt valmis süsteemi sisse suruda

Valmis tootmise juhtimissüsteem või ERP toimib hästi seal, kus protsess on tegelikult korratav, vastutus on üheselt määratletud ja andmemudel ei moonuta tehase tegelikku pilti. Sellistes tingimustes korrastab standardiseerimine infoliikumist, vähendab kohalike tõlgenduste hulka ja võimaldab teha otsuseid sündmuste ühtse kirjeldamise alusel. Probleem tekib varem kui puuduolevate funktsioonide tasandil. See algab seal, kus tootmise, kvaliteedi, hoolduse ja planeerimise tegelik kulg ei mahu enam süsteemi loogikasse ilma protsessi kahjustamata.

See on piir mõistliku standardiseerimise ja operatiivse kontrolli kaotuse vahel. Kui organisatsioon hakkab omaenda protsessist mööda minema selleks, et andmed „süsteemis klapiksid”, ei teeni infoarhitektuur enam tootmist. See hakkab seda moonutama. Osa reegleid saab ohutult ühtlustada seadistuse või protseduuriga, kuid on ka tehnoloogilisi seoseid, kontrollpunkte ja vastutusahelaid, mida ei tohi hägustada ilma kahjuta toote kvaliteedile, protsessi ohutusele või otsuste jälgitavusele. Seetõttu on vaidlus „valmis või oma lahendus” tavaliselt valesti püstitatud. Täpsem küsimus on: millised protsessi elemendid on ühine standard ja millised moodustavad tehase eelise tuuma, riski allika või vastavuskohustuste valdkonna ning peavad olema täpselt kajastatud.

Praktikas ei ole kõige kallimad mitte puuduvad moodulid, vaid ümbersõidud, mis muutuvad vaikselt igapäevaseks tööviisiks. Süsteemi kõrval peetavad tabelid, andmete käsitsi ümberkirjutamine vahetuse ja kontori vahel, operaatorite märkused, erandite mitteametlik kooskõlastamine ja paralleelsed infovood ei ole väike ebamugavus. See on märk sellest, et protsessi juhtimismudel hakkab lagunema. Sellisel juhul tasub mõõta mitte funktsioonide arvu, vaid käsitsi andmete ümberkirjutamise punktide arvu tootmise, kvaliteedi, hoolduse ja planeerimise vahel, süsteemiväliselt käsitletavate kriitiliste erandite arvu ning nende operatiivsete otsuste osakaalu, mis tehakse andmete põhjal, mis ei pärine otse algregistrist. Kui need näitajad kasvavad, ei tulene probleem tavaliselt nõrgast seadistusest, vaid ekslikust eeldusest, et protsessi saab tööriistale kuludeta allutada.

See paistab hästi välja tehastes, kus töökorralduse kulg ei sõltu ainult tehnoloogilisest marsruudist, vaid ka masina tegelikust seisukorrast, vahekontrolli tulemustest, materjalide lubatavusest, sisendpartiist, seadistusparameetritest ja otsustest, mida mitu üksust teevad samaaegselt ajasurve all. Kui valmis süsteem ei suuda neid seoseid hoida ühes usaldusväärses andmeahelas, laguneb tõde protsessi kohta mitmesse kohta. Osa jääb süsteemi, osa masina juurde, osa kvaliteedidokumentidesse ja osa inimeste teadmistesse. Selline olukord raskendab tootmisprotsessi kaardistamist, muudab juurutuse teostajate vastutuse keerulisemaks ja suurendab projekti riski automaatika ning süsteemidega integreerimisel, millel on mõju masinate ohutusele. Kohandatud tarkvaral on mõte mitte siis, kui tehas tahab „midagi oma”, vaid siis, kui on vaja säilitada protsessi, lähteandmete ja otsuste ühtsus seal, kus lihtsustamine tähendaks tegelikku kontrolli kaotust.

Vastavuse ja operatiivse järelevalve vaates on sellel eristusel põhimõtteline tähtsus. Kui võtmetähtsusega reeglid ja kontrollpunktid eksisteerivad ainult meeskonna praktikas ega ole süsteemis kas sunnitult rakendatud või vähemalt üheselt kajastatud, muutub vastutuse jälgitavus tingimuslikuks. Mõnes valdkonnas on see eelkõige kvaliteedi ja partii kulgemise taastatavuse probleem, teistes ka sektorinõuete, jälgitavuse, muudatuste juhtimise või vastutuspiiride küsimus tehase kasutaja, integraatori ja tarkvaratarnija vahel. Seetõttu peab otsusele, kas allutada protsess süsteemile või süsteem protsessile, eelnema mitte funktsioonide esitlus, vaid aus erandite analüüs. Alles siis saab selgeks, millised neist on organisatsiooniline kaos ja millised peegeldavad tegelikke tehnoloogilisi, infoga seotud ja ohutusnõudeid.

Kulu kasvab seal, kus süsteem ei näe tegelikku riski

Süsteemi sobimatus läheb kõige kallimaks maksma mitte lihtsas töökorralduses ega päevaaruannetes, vaid tootmise, kvaliteedi, hoolduse ja protsessiohutuse kokkupuutepunktis. Just seal tuleb otsus teha kiiresti, see dokumenteerida ja tugineda täielikule kontekstile: masina hetkeolekule, partii parameetritele, sekkumiste ajaloole, kvaliteedivabastuse staatusele ja kehtivatele blokeeringutele. Kui valmis tootmise juhtimissüsteem või ERP näeb sellest pildist ainult osa, ei piirdu kulu kasutaja ebamugavusega. Tekib operatiivne varieeruvus. Erinevad vahetused teevad sarnaseid otsuseid erinevate andmete põhjal, erandeid käsitletakse kaalutlusõiguse alusel ning vastutus hajub süsteemi, protseduuri ja tootmishalli tegeliku praktika vahel.

Kõige olulisem probleem algab siis, kui süsteem ei peegelda tegelikku tegevuste järjestust, blokeerimistingimusi, tehnoloogiliste parameetrite versioonihaldust või vastutust kõrvalekalde heakskiitmise eest. Kirjetes võib kõik näida korrektne, kuigi tegelik teostus kulges teisiti. Tekib lõhe sündmuse ja selle digitaalse jälje vahele. See sunnib tegema väga konkreetseid projekteerimisotsuseid: kas kriitilised protsessiblokeeringud peavad toimima süsteemselt või ainult protseduuriliselt; kas masinatelt tulevad andmed on operatiivne tõendusmaterjal või abimaterjal; ning kas erandeid tuleb käsitleda kavandatud otsustusvoo kaudu või jätta need kaalutlusõiguse alla. Kui tehas tugineb käsitsi lisatud märkustele, täiendavatele tabelitele või liidestele, mis nõuavad pidevat inimese sekkumist, tuleb andmete usaldusväärsust hinnata mitte selle järgi, kas lõpparuannet on võimalik genereerida, vaid selle järgi, kas ühe mittevastavuse, reklamatsiooni või liiniseiskumise kulgu on võimalik vaidlusteta taastada.

Eriline risk ilmneb ulatusliku masinapargiga tehastes, kus süsteem peab töötama koos automaatika, operaatoritöökohtade ning kontrolli- ja mõõteseadmetega. Kui seadmete integratsioon on osaline, protsessiandmete kogumine ebaühtlane ja muudatuste ajalugu hajutatud kontrolleri, paneeli, tootmisandmebaasi ja hooldusmärkmete vahel, muutuvad partii jälgitavus ja toote genealoogia tingimuslikuks. Samamoodi on lugu tehnoloogiliste muudatuste juhtimisega. Retsepti, tolerantsipiiri või ümberseadistamise loogika muudatus võib olla formaalselt heaks kiidetud, kuid ilma ühtse versioonihalduse ja arhiveerimiseta ei ole hiljem võimalik tõendada, milline konfiguratsioon sündmuse hetkel tegelikult kehtis. See ei ole süsteemiarhitektuuri esteetika küsimus, vaid taastatavuse, algpõhjuste kindlakstegemise ja vastutuspiiride teema tootmise, hoolduse, kvaliteedi ning integratsioonitarnijate vahel.

Sellise sobimatuse kulu on juurutuse eelarves harva näha. See avaldub hiljem diagnostiliste seisakute, käsitsitöö kasvu, reklamatsioonide, vaidlustena sündmuse põhjuse üle ja võime kaotusena protsessi kulgu üheselt taastada. Seetõttu ei piisa lahenduse hindamisel küsimusest, kas süsteem „toetab tootmist”. Tuleb kontrollida, kui palju liideseid vajab käsitsi parandamist, kui paljusid kriitilisi parameetreid ei versioonihaldata ega arhiveerita automaatselt ühtsel viisil ning kui kaua võtab aega ühe operatiivse intsidendi rekonstrueerimine. Kui vastus on: kaua, ebaühtlaselt ja mitme sõltumatu allika abil, siis ei puuduta probleem kasutusmugavust, vaid riski juhitavust. Just siin võib protsessile kohandatud süsteemilahendus või vähemalt valmis süsteemi peale ehitatud spetsiaalne kiht olla põhjendatud: mitte selleks, et minevikku paremini raporteerida, vaid selleks, et toetada ohutuid operatiivseid otsuseid hetkel, kui tehas töötab ajasurve ja vastutuse all.

Vastavuse vaatenurgast tähendab see veel üht. Seal, kus tarkvara mõjutab selliste otsuste kulgu, millel on tähtsus kvaliteedi, jälgitavuse või protsessiohutuse jaoks, peaks kriitiliste funktsioonide ulatus tulenema tegelikust riskianalüüsist, mitte standardmoodulite kataloogist. See puudutab eelkõige integratsiooni masinatega, erandolukordade käsitlemist ning kohti, kus süsteem peab sundima kindlat tegevuste järjekorda või blokeerima ülemineku järgmisse etappi. Sellistes valdkondades tasub eristada arvestusfunktsioone neist, mis muutuvad operatiivse kontrolli osaks ja vajavad tugevamat projekteerimisalast põhjendust, ka masinaohutuse ja integraatori vastutuse kontekstis.

Kõigepealt otsustusloogika, siis kood

Mõistlik otsus tehase süsteemi arendamise kohta ei alga funktsioonide loetelust, vaid nende operatiivsete otsuste kaardistamisest, mida tarkvara peab toetama või jõustama. Tuleb kindlaks teha, kes otsuse teeb, milliste andmete põhjal, millise aja jooksul ja millise mõjuga tootmisele, kvaliteedile, jälgitavusele või protsessiohutusele. Alles selle taustal on näha, kas valmis tootmise juhtimissüsteem või ERP hõlmab probleemi tuuma või korrastab üksnes tagantjärele arvestust. Kui kriitiline ei ole mitte sündmuse enda registreerimine, vaid järgmise operatsiooni käivitamise blokeerimine, partii vabastamise tingimus, masina seadistuste vastavuse kinnitamine või kõrvalekalde käsitlemine, siis ei ole küsimus „kas süsteemil on see olemas”, vaid „kas see suudab sundida õige otsuse õigel hetkel”.

Selline mõtteviis aitab korrastada ka arhitektuuri kavandamist. Praktikas toimib kõige sagedamini hübriidlahendus. Standardne ERP või tootmise täitmise süsteem peaks jääma sinna, kus protsess on ühine, korduv ja hästi kirjeldatav küpse andmemudeliga: planeerimisse, tootmise arvestusse, laohaldusse ning tellimuste ja partiide põhikirjeldusse. Eraldi kohandatud kiht on põhjendatud siis, kui see võtab üle konkreetse tehase jaoks kriitilise loogika: integratsiooni masinatega, mitmest allikast tulevate sündmuste valideerimise, erandite käsitlemise, kooskõlastusteekonnad, auditeerimisjälje ning otsuste sidumise konkreetse partii, masina ja vastutava isikuga. Edu eelduseks on aga vastutuspiiride varajane määratlemine. Meeskond peab otsustama, mis kuulub tehnoloogilise protsessi juurde ja jääb automaatika või juhtimise poolele, mis on ERP või tootmise täitmise süsteemi pädevuses, mida teostab integratsioonikiht ning mis peab endiselt jääma organisatsiooniliste protseduuride raamidesse.

Ilma sellise jaotuseta tekib kulukas improviseerimine. Sama tingimus pannakse kirja mitmesse kohta, erandeid lahendatakse käsitsi ning mõne kuu pärast ei oska enam keegi üheselt öelda, milline süsteem vastutab protsessi blokeeriva või vabastava otsuse eest. Hea kohandatud projekt ei tähenda seega valmislahenduse väiksemas mahus kopeerimist. Selle ülesanne on sulgeda konkreetne otsustuslünk. Seetõttu tasub juba projekti etapis kirja panna kriitiliste otsuste loetelu, millel täna puudub süsteemne tugi või jõustamine, ning seejärel võrrelda seda protsessierandite arvuga, mida lahendus peab alates esimesest käivitamisest käsitlema. See on olulisem kui mahukas ekraanispetsifikatsioon.

Praktiline näide on lihtne. Valmislahendus võib korrektselt arvestada tootmist, materjalikulu ja lattu vastuvõtte, kuid mitte hõlmata tingimusliku partii vabastamisega seotud spetsiifilisi kvaliteediblokeeringuid. Partii võib olla formaalselt toodetud ja süsteemis kajastatud, kuid sellest hoolimata ei tohiks see liikuda järgmisse etappi enne, kui on kinnitatud kindlad katsetulemused, liini ümberseadistuse seisund või eelmise operatsiooni kõrvalekalde kõrvaldamine. Kui sellist tingimust jälgitakse täna telefoni, tabeli või väljatrükil oleva allkirjaga, ei ole tegemist protsessi esteetikaprobleemiga, vaid vastutuse juhtimise lüngaga. Sellises olukorras ei ole kogu ERP-i või tootmise täitmise süsteemi ümberehitamine tavaliselt põhjendatud. Piisab kohandatud kihist, mis võtab andmed masinatest ja lähtesüsteemidest, kontrollib sündmuste täielikkust, käivitab õige kooskõlastusteekonna ja edastab ülemisele süsteemile üheselt mõistetava partii staatuse. Standard jääb standardiks ning kriitiline loogika talletatakse sinna, kus seda on võimalik tegelikult hallata ja hooldada.

Kui tehases ei ole veel kuluandmeid, ei ole vaja neid oletada. Piisab sellest, kui hakata mõõtma, kui palju aega kulub kuus käsitsi ümbersõitudele, lisakooskõlastustele, partii parandustele ja süsteemi ning protsessi tegeliku seisu vaheliste lahknevuste kontrollimisele. Selline materjal aitab eristada põhjendatud kohandatud kihti igaks juhuks kirjutatud projektist. See lihtsustab ka rollide õiget jaotust äripoolel. Süsteemi kirjutatava loogika ulatust ei tohiks määrata ainult IT-osakond ega üksnes integraator, vaid ühiselt tootmine, kvaliteet, hooldus, digitaliseerimise eest vastutavad inimesed ning seal, kus see on oluline, integraatori, tarkvaramaja ja hooldusosakonna koostöö ning masinaohutus ja töökorralduslik vastavus.

Projektivastutuse vaatenurgast on sellel veel üks tagajärg. Mida lähemale tarkvara läheb protsessi üleminekutingimustele, operatsioonide blokeeringutele, tegevuste järjestuse korrektsusele või otse masinast pärinevatele andmetele, seda vähem saab seda käsitleda neutraalse IT-lisana. Sellises ulatuses on vaja selgeid projekteerimiseeldusi, tegevus- ja hoolduspiiride kirjeldust, muudatuste juhtimise põhimõtteid ning kontrollitavat jälge selle kohta, kes ja mille alusel kriitilise loogika heaks kiitis. Seetõttu tasub enne esimese koodirea kirjutamist kinnitada mitte ainult funktsionaalsed nõuded, vaid eelkõige otsuste projekt: mida süsteem peab jõustama, mida see ei tohi lubada teha ja millises punktis jääb inimene viimaseks vastutuse kandjaks.

Vastavus on hea projekti tulemus, mitte juurutusjärgne dekoratsioon

Tööstusettevõttes ei ole tarkvara protsessi neutraalne lisand, vaid osa selle teostamise viisist. See võib määrata toimingute järjekorra, blokeerida järgmisse etappi liikumise, nõuda andmete täielikkust, suunata kooskõlastusteekonda ja otsustada, kas pärast sündmust on võimalik taastada otsuste käik ning vastutus. Seetõttu ei alga vastavus formaalsete nõuete lisamisest juurutuse lõpus. See algab projektist, milles määratletakse teadlikult, milliseid otsuseid süsteem teeb ise, milliseid see üksnes toetab, milliseid andmeid peab siduvaks ning kes vastutab reeglite, erandite ja muudatuste eest.

Kui seda korda ei looda lahenduse arhitektuuri etapis, muutub hilisem viitamine kvaliteedinõuetele, protsessiohutusele või dokumenteerimiskohustustele sisutühjaks tegevuseks. See on eriti oluline siis, kui süsteem mõjutab toote kvaliteedi, protsessiohutuse või masinate ja seadmetega koostöö seisukohalt olulisi otsuseid. Sellises ulatuses tuleb vastavusnõudeid mõista operatiivselt: kui vajadust tagada toimimise järjepidevus, jälgitavus, muudatuste kontroll ja lahenduse sobivus tegelikuks kasutuseks. Küsimus ei ole üksnes selles, et funktsioon oleks olemas, vaid selles, et oleks võimalik näidata, miks see toimib just nii, kes selle loogika heaks kiitis ja kuidas hinnatakse selle muutmise mõju.

Kõige rohkem probleeme ilmneb tavaliselt mitte käivitamisel, vaid mõne kuu möödudes kasutuse käigus. Tehas lisab uue tootmisvariandi, muudab vastuvõtukriteeriume, ühendab järgmise töökoha või viib osa vastutusest operaatorilt süsteemile. Kui varem ei ole kokku lepitud, millised otsuste ja kirjete klassid peavad jätma auditeeritava jälje, tekib kiiresti vaidlus selle üle, kelle muudatus mõjutas kvaliteeti, seisakut või süsteemi vale reaktsiooni. Siis saabki selgeks vahe toimiva ja hallatava lahenduse vahel. Viimase puhul on ette teada, millised loogikaelemendid nõuavad formaalset heakskiiduteed, kes haldab lähteandmeid, kes hoiab töös integratsiooni automaatikaga ning kas projektdokumentatsioonist piisab auditi, hoolduse ja süsteemi ohutuks ülevõtmiseks teise töövõtja poolt.

• milliseid otsuseid süsteem teeb või kujundab kaasa kvaliteedi, ohutuse ja masinaga koostöö valdkonnas,
• millised sündmused, muudatused ja kinnitused peavad jätma taastatava jälje,
• kes vastutab ärireeglite, andmete ja erandite eest ning kes kiidab nende muutmise heaks.

Alles pärast sellist korrastamist on mõistlik siduda projekt konkreetse tehase, toote, tegevusharu ja masinate või seadmetega integreerimise viisiga seotud õiguslike ja normatiivsete nõuetega. Poola ja Euroopa Liidu kontekstis ei ole küsimus ainult selles, kas lahendus töötab, vaid ka selles, kas organisatsioon suudab näidata, miks see töötab just sellisel viisil, mille alusel reeglid heaks kiideti ja kuidas muudatusi juhitakse nii, et jälgitavus ei nõrgeneks. Selle analüüsi ulatus sõltub alati kasutusotstarbest: ühtmoodi ei hinnata aruandlussüsteemi, teistmoodi protsessi kulgu mõjutavat loogikat ja veel teisiti integratsiooni, mis puutub kokku masina toimimise, riskihindamisega või integraatori vastutusulatusega.

Järeldus on lihtne. Dedikeeritud tarkvara tööstusele on põhjendatud siis, kui see korrastab vastutuse ja vähendab riski täpselt seal, kus valmis tootmise täitmise süsteem või ERP nõuaks kulukaid kompromisse protsessiloogikas, muudatuste järelevalves või tegevuste jälgitavuses. Seega ei ole eesmärk ehitada kõike nullist, vaid eraldada standardlahendus ja kriitiline loogika nii, et süsteem toetaks tehase tegelikku protsessi, mitte ei lihtsustaks seda kvaliteedi, ohutuse ja jälgitavuse arvelt.