Räätälöity ohjelmisto teollisuudelle – milloin valmis FEM-/ERP-järjestelmä ei ole enää järkevä valinta

Valmis tuotannonohjaus- tai ERP-järjestelmä voi olla järkevä valinta, mutta vain silloin, kun tuotannon todellinen kulku voidaan mallintaa ilman olennaisia yksinkertaistuksia. Muussa tapauksessa järjestelmä kyllä jäsentää kirjaamista, mutta prosessin ohjattavuuden kustannuksella. Siinä vaiheessa toimintoluettelolla ei enää ole ratkaisevaa merkitystä. On arvioitava, hallitseeko tehdas edelleen omaa tuotantoaan, laatuaan ja kunnossapitoaan vai alkaako se mukauttaa toimintaansa työkalun rajoituksiin. Jos kriittiset päätökset, poikkeukset ja estot toimivat pääosin järjestelmän ulkopuolella, räätälöity ohjelmisto teollisuudelle ei ole päähänpisto. Siitä tulee keino palauttaa tiedon eheys, vastuut ja operatiivinen hallinta.

Kaikkea tuotantoa ei voi kuvata rehellisesti valmiissa järjestelmässä

Valmis tuotannonohjaus- tai ERP-järjestelmä toimii hyvin siellä, missä prosessi on aidosti toistettava, vastuut ovat yksiselitteiset eikä tietomalli vääristä kuvaa laitoksesta. Tällaisissa olosuhteissa standardointi selkeyttää tiedonkulkua, vähentää paikallisten tulkintojen määrää ja mahdollistaa päätöksenteon yhtenäisen tapahtumatiedon perusteella. Ongelma ilmenee jo ennen puuttuvia toimintoja. Se alkaa siinä, missä tuotannon, laadun, kunnossapidon ja suunnittelun todellinen kulku ei enää mahdu järjestelmän logiikkaan ilman menetyksiä prosessille.

Tässä kulkee raja järkevän standardoinnin ja operatiivisen hallinnan menettämisen välillä. Jos organisaatio alkaa kiertää omaa prosessiaan vain siksi, että tiedot ”täsmäisivät järjestelmässä”, tietoarkkitehtuuri lakkaa palvelemasta tuotantoa. Se alkaa vääristää sitä. Osa säännöistä voidaan turvallisesti yhdenmukaistaa konfiguraatiolla tai menettelyllä, mutta mukana on myös teknologisia riippuvuuksia, valvontapisteitä ja vastuunkulkuja, joita ei saa hämärtää vaarantamatta tuotteen laatua, prosessin turvallisuutta tai päätösten jäljitettävyyttä. Siksi vastakkainasettelu ”valmis vai oma” on yleensä asetettu väärin. Osuvampi kysymys kuuluu: mitkä prosessin osat ovat yhteistä standardia ja mitkä taas muodostavat laitoksen kilpailuedun ytimen, riskin lähteen tai vaatimustenmukaisuuteen liittyvien velvoitteiden alueen ja on siksi kuvattava täsmällisesti.

Käytännössä kalleimpia eivät ole puuttuvat moduulit vaan kiertotavat, joista tulee huomaamatta arjen normaali toimintamalli. Järjestelmän rinnalla ylläpidetyt taulukot, tietojen käsin siirtäminen vuoron ja toimiston välillä, operaattorien lisämerkinnät, poikkeusten epävirallinen yhteensovittaminen ja rinnakkaiset tiedonkulut eivät ole pieniä hankaluuksia. Ne kertovat siitä, että prosessin ohjausmalli alkaa murtua. Silloin kannattaa mitata toimintojen määrän sijaan käsin tehtävien tiedonsiirtopisteiden määrää tuotannon, laadun, kunnossapidon ja suunnittelun välillä, järjestelmän ulkopuolella käsiteltävien kriittisten poikkeusten määrää sekä niiden operatiivisten päätösten osuutta, jotka tehdään muun kuin suoraan lähderekisteristä tulevan tiedon perusteella. Jos nämä mittarit kasvavat, ongelma ei yleensä johdu heikosta konfiguroinnista vaan virheellisestä oletuksesta, että prosessi voidaan ilman kustannuksia taivuttaa työkalun mukaan.

Tämä näkyy selvästi laitoksissa, joissa työmääräyksen eteneminen ei riipu vain teknologisesta reitityksestä vaan myös koneen todellisesta tilasta, välitarkastusten tuloksista, materiaalihyväksynnöistä, syöttöerästä, asetusparametreista ja usean yksikön samanaikaisesti aikapaineessa tekemistä päätöksistä. Jos valmis järjestelmä ei pysty pitämään näitä riippuvuuksia yhdessä luotettavassa tietoketjussa, totuus prosessista hajoaa useaan paikkaan. Osa jää järjestelmään, osa koneen äärelle, osa laatudokumentteihin ja osa ihmisten tietoon. Tällainen tilanne vaikeuttaa tuotantoprosessin kartoitusta, monimutkaistaa käyttöönoton toteuttajien vastuita ja lisää projektiriskiä integraatiossa automaation sekä järjestelmien kanssa, joilla on vaikutusta koneiden turvallisuuteen. Räätälöity ohjelmisto on perusteltu ei silloin, kun laitos haluaa ”jotain omaa”, vaan silloin, kun on säilytettävä prosessin, lähdetiedon ja päätösten yhtenäisyys siellä, missä yksinkertaistaminen merkitsisi todellista hallinnan menetystä.

Vaatimustenmukaisuuden ja operatiivisen valvonnan näkökulmasta tällä erottelulla on perustavanlaatuinen merkitys. Jos keskeiset säännöt ja valvontapisteet ovat olemassa vain tiimin käytännöissä eikä niitä pakoteta tai ainakaan yksiselitteisesti kuvata järjestelmässä, vastuun jäljitettävyydestä tulee ehdollista. Joillakin toimialoilla kyse on ennen kaikkea laadusta ja erän kulun rekonstruoitavuudesta, toisilla myös toimialakohtaisista vaatimuksista, jäljitettävyydestä, muutoksenhallinnasta tai vastuurajojen määrittelystä laitoksen käyttäjän, integraattorin ja ohjelmistotoimittajan välillä. Siksi päätöstä siitä, alistetaanko prosessi järjestelmälle vai järjestelmä prosessille, ei pidä edeltää toimintoesittelyllä vaan rehellisellä poikkeamien analyysillä. Vasta silloin näkyy, mitkä niistä ovat organisatorista sekavuutta ja mitkä heijastavat todellisia teknologisia, tiedollisia ja turvallisuuteen liittyviä vaatimuksia.

Kustannukset kasvavat siellä, missä järjestelmä ei näe todellista riskiä

Järjestelmän huono yhteensopivuus tulee kalleimmaksi ei yksinkertaisessa työmääräysten kierrossa eikä päivittäisraporteissa, vaan tuotannon, laadun, kunnossapidon ja prosessiturvallisuuden rajapinnassa. Juuri siellä päätös on tehtävä nopeasti, dokumentoitava ja perustettava koko asiayhteyteen: koneen senhetkiseen tilaan, erän parametreihin, toimenpidehistoriaan, laadullisen vapautuksen tilaan ja voimassa oleviin estoihin. Jos valmis tuotannonohjaus- tai ERP-järjestelmä näkee tästä kokonaisuudesta vain osan, kustannus ei rajoitu käyttäjän kokemaan hankaluuteen. Seurauksena on toiminnan vaihtelu. Eri vuorot tekevät samankaltaisia päätöksiä eri tietojen perusteella, poikkeamia käsitellään tapauskohtaisesti ja vastuu hämärtyy järjestelmän, menettelyn ja tuotantotilan käytännön välillä.

Keskeinen ongelma alkaa silloin, kun järjestelmä ei vastaa todellista toimintojen järjestystä, estoehtoja, teknologisten parametrien versiohallintaa tai vastuuta poikkeaman hyväksymisestä. Kirjauksissa kaikki voi näyttää oikealta, vaikka toteutus on edennyt toisin. Tapahtuman ja sen digitaalisen jäljen väliin syntyy kuilu. Tämä pakottaa hyvin konkreettisiin suunnitteluratkaisuihin: toteutetaanko kriittiset prosessin estot järjestelmätasolla vai vain menettelytapana; ovatko koneilta tulevat tiedot operatiivista näyttöä vai ainoastaan tukimateriaalia; ja käsitelläänkö poikkeukset suunnitellun päätöksentekoprosessin kautta vai jätetäänkö ne harkinnan varaan. Jos laitos nojaa käsin tehtyihin lisämerkintöihin, erillisiin taulukoihin tai käyttöliittymiin, jotka vaativat jatkuvaa ihmisen puuttumista, tiedon luotettavuutta ei pidä arvioida sen perusteella, saadaanko loppuraportti muodostettua, vaan sen perusteella, voidaanko yhden poikkeaman, reklamaation tai linjaseisokin kulku jäljittää kiistattomasti.

Erityinen riski tulee esiin laitoksissa, joissa konekanta on laaja ja järjestelmän on toimittava yhdessä automaation, operaattoriasemien ja mittaus- sekä tarkastuslaitteiden kanssa. Jos laiteintegraatio on osittainen, prosessidatan keruu epäyhtenäistä ja muutoshistoria hajallaan ohjaimen, paneelin, tuotantotietokannan ja huoltomuistiinpanojen välillä, eräseurannasta ja tuotteen genealogiasta tulee ehdollista. Sama koskee teknologisten muutosten hallintaa. Reseptin, toleranssirajan tai vaihtoasetusten logiikan muutos voi olla muodollisesti hyväksytty, mutta ilman yhtenäistä versiohallintaa ja arkistointia ei myöhemmin voida osoittaa, mikä kokoonpano oli tapahtumahetkellä tosiasiallisesti voimassa. Tämä ei ole järjestelmäarkkitehtuurin esteettinen kysymys, vaan toistettavuuden, juurisyiden selvittämisen ja vastuurajojen määrittämisen ongelma tuotannon, kunnossapidon, laadun ja integraatiotoimittajien välillä.

Tällaisen yhteensopimattomuuden kustannus näkyy harvoin käyttöönottobudjetissa. Se paljastuu myöhemmin diagnostiikkaseisokkeina, manuaalisen työn lisääntymisenä, reklamaatioina, kiistoina tapahtuman syystä ja kykynä menettää prosessin kulun yksiselitteinen rekonstruointi. Siksi ratkaisua arvioitaessa ei riitä kysyä, ”tukeeko järjestelmä tuotantoa”. On selvitettävä, kuinka moni rajapinta vaatii manuaalista korjausta, kuinka montaa kriittistä parametria ei versioida automaattisesti tai arkistoida yhtenäisesti sekä kuinka paljon aikaa yhden operatiivisen poikkeaman rekonstruointi vie. Jos vastaus on: kauan, epäyhtenäisesti ja useiden toisistaan riippumattomien lähteiden avulla, ongelma ei koske käyttäjän mukavuutta vaan riskin hallittavuutta. Juuri tässä oma ratkaisu tai ainakin valmiin järjestelmän päälle rakennettu erillinen kerros voi olla perusteltu: ei siksi, että menneisyyttä raportoitaisiin paremmin, vaan jotta voidaan tukea turvallisia operatiivisia päätöksiä silloin, kun laitos toimii ajan ja vastuun paineessa.

Vaatimustenmukaisuuden näkökulmasta tämä merkitsee vielä yhtä asiaa. Siellä, missä ohjelmisto vaikuttaa sellaisten päätösten kulkuun, joilla on merkitystä laadun, jäljitettävyyden tai prosessiturvallisuuden kannalta, kriittisten toimintojen laajuuden tulisi perustua todelliseen riskianalyysiin, ei vakiomoduulien luetteloon. Tämä koskee erityisesti koneintegraatioita, poikkeustilanteiden käsittelyä sekä kohtia, joissa järjestelmän on pakotettava tietty työvaiheiden järjestys tai estettävä siirtyminen seuraavaan vaiheeseen. Tällaisilla alueilla on syytä erottaa kirjaavat toiminnot niistä, joista tulee osa operatiivista ohjausta ja jotka vaativat vahvempia suunnitteluperusteita myös koneturvallisuuden ja integraattorin vastuun näkökulmasta.

Ensin päätöksenteon suunnittelu, sitten koodi

Järkevä päätös järjestelmän kehittämisestä laitoksessa ei ala toimintoluettelosta, vaan niiden operatiivisten päätösten kartoituksesta, joita ohjelmiston on tuettava tai pakotettava. On määriteltävä, kuka tekee päätöksen, mihin tietoihin se perustuu, missä ajassa se on tehtävä ja mitä vaikutuksia sillä on tuotantoon, laatuun, jäljitettävyyteen tai prosessiturvallisuuteen. Vasta tätä taustaa vasten nähdään, kattaako valmis tuotannonohjaus- tai ERP-järjestelmä ongelman ytimen vai ainoastaan järjestääkö se kirjaamisen jälkikäteen. Jos kriittistä ei ole pelkkä tapahtuman rekisteröinti vaan seuraavan työvaiheen käynnistyksen esto, erän vapautuksen ehto, koneen asetusten vaatimustenmukaisuuden vahvistus tai poikkeaman käsittely, kysymys ei ole ”onko järjestelmässä tämä toiminto”, vaan ”pystyykö se pakottamaan oikean päätöksen oikealla hetkellä”.

Tällainen ajattelutapa jäsentää myös arkkitehtuurin suunnittelua. Käytännössä hybridimalli toimii useimmiten parhaiten. Vakio-ERP:n tai tuotannonohjausjärjestelmän tulisi jäädä niihin kohtiin, joissa prosessi on yhteinen, toistuva ja kypsän tietomallin hyvin kuvaama: suunnitteluun, tuotannon kirjaamiseen, varastonhallintaan sekä tilausten ja erien perusseurantaan. Erillinen räätälöity kerros on perusteltu silloin, kun se ottaa vastuulleen juuri kyseiselle tehtaalle kriittisen logiikan: koneintegraatiot, useista lähteistä tulevien tapahtumien validoinnin, poikkeusten käsittelyn, hyväksyntäpolut, audit trailin sekä päätösten kytkemisen tiettyyn erään, koneeseen ja vastuuhenkilöön. Onnistumisen edellytyksenä on kuitenkin vastuurajojen määrittely etukäteen. Tiimin on ratkaistava, mikä kuuluu teknologiseen prosessiin ja jää automaation tai ohjauksen puolelle, mikä on ERP:n tai tuotannonohjausjärjestelmän aluetta, mitä integraatiokerros toteuttaa ja mitä on edelleen pidettävä organisaation menettelyissä.

Ilman tällaista jakoa seurauksena on kallis improvisaatio. Sama ehto kirjataan helposti useaan paikkaan, poikkeuksia ratkaistaan käsin, ja muutaman kuukauden kuluttua kukaan ei enää pysty yksiselitteisesti osoittamaan, mikä järjestelmä vastaa prosessin estävästä tai vapauttavasta päätöksestä. Hyvä räätälöity ratkaisu ei siis tarkoita valmiin järjestelmän kopioimista pienemmässä mittakaavassa. Sen tehtävänä on sulkea tietty päätöksenteon aukko. Siksi jo suunnitteluvaiheessa kannattaa laatia luettelo kriittisistä päätöksistä, joille ei tällä hetkellä ole järjestelmätukea tai pakottavaa ohjausta, ja verrata sitä niiden prosessipoikkeusten määrään, jotka ratkaisun on hallittava ensimmäisestä käyttöönotosta lähtien. Tämä on tärkeämpää kuin laaja näyttökuvien spesifikaatio.

Käytännön esimerkki on yksinkertainen. Valmis järjestelmä voi hoitaa oikein tuotannon kirjaamisen, materiaalikulutuksen ja varastoon vastaanoton, mutta se ei välttämättä kata ehdolliseen erän vapautukseen liittyviä erityisiä laatuestolukituksia. Erä voi olla muodollisesti valmistettu ja kirjattu järjestelmään, mutta siitä huolimatta sen ei pitäisi siirtyä seuraavaan vaiheeseen ilman tiettyjen testitulosten vahvistusta, linjan asetusten vaihdon tilan varmistusta tai edellisessä operaatiossa syntyneen poikkeaman poistamista. Jos tällaista ehtoa valvotaan nyt puhelimitse, taulukolla tai allekirjoituksella tulosteessa, kyse ei ole prosessin estetiikasta vaan vastuun ohjauksen aukosta. Tällaisessa tilanteessa koko ERP:n tai tuotannonohjausjärjestelmän uudistaminen on yleensä perusteetonta. Riittää, että käytössä on räätälöity kerros, joka hakee tiedot koneilta ja lähdejärjestelmistä, tarkistaa tapahtumien täydellisyyden, käynnistää oikean hyväksyntäpolun ja välittää ylemmälle järjestelmälle yksiselitteisen erästatuksen. Standardi pysyy standardina, ja kriittinen logiikka kirjataan sinne, missä sitä voidaan aidosti hallita ja ylläpitää.

Jos tehtaalla ei vielä ole kustannustietoja, niitä ei tarvitse arvailla. Riittää, että aletaan mitata, kuinka paljon aikaa kuukaudessa kuluu manuaalisiin kiertotapoihin, lisäselvityksiin, eräkorjauksiin ja järjestelmän sekä prosessin todellisen tilan välisten poikkeamien tarkistamiseen. Tällainen aineisto auttaa erottamaan perustellun räätälöidyn kerroksen varmuuden vuoksi käynnistetystä hankkeesta. Se helpottaa myös roolien oikeaa jakoa liiketoiminnan puolella. Järjestelmään kirjattavan logiikan laajuudesta ei pitäisi päättää yksin IT-osasto eikä pelkkä integraattori, vaan yhdessä tuotannon, laadun, kunnossapidon, digitalisaatiosta vastaavien henkilöiden sekä tarvittaessa integraattorin, ohjelmistotalon ja kunnossapidon yhteistyön sekä koneturvallisuuden ja operatiivisen vaatimustenmukaisuuden näkökulmasta.

Projektivastuun näkökulmasta tällä on vielä yksi seuraus. Mitä lähemmäs ohjelmisto menee prosessin siirtymäehtoja, operaatioiden estolukituksia, toimintasarjojen oikeellisuutta tai suoraan koneelta tulevaa dataa, sitä vähemmän sitä voidaan pitää neutraalina IT-lisänä. Tällaisessa laajuudessa tarvitaan selkeät suunnitteluoletukset, kuvaus toiminnan ja ylläpidon rajoista, muutoksenhallinnan periaatteet sekä todennettava jälki siitä, kuka on hyväksynyt kriittisen logiikan ja millä perusteella. Siksi ennen ensimmäisenkään koodirivin kirjoittamista kannattaa hyväksyä paitsi toiminnalliset vaatimukset ennen kaikkea päätösmalli: mitä järjestelmän on pakotettava, mitä sen ei pidä sallia tehdä ja missä kohdassa ihminen jää viimeiseksi vastuutahoksi.

Vaatimustenmukaisuus on hyvän suunnittelun seuraus, ei käyttöönoton jälkeinen koriste

Teollisuuslaitoksessa ohjelmisto ei ole prosessin neutraali lisä, vaan osa sen toteutustapaa. Se voi määrittää työvaiheiden järjestyksen, estää siirtymisen seuraavaan vaiheeseen, pakottaa tietojen täydellisyyden, ohjata hyväksyntäpolkua ja ratkaista sen, voidaanko tapahtuman jälkeen päätösten kulku ja vastuut jäljittää. Siksi vaatimustenmukaisuus ei ala muodollisten vaatimusten lisäämisestä käyttöönoton lopussa. Se alkaa suunnittelusta, jossa määritellään tietoisesti, mitkä päätökset järjestelmä tekee itse, mitä se vain tukee, mitä tietoja se pitää sitovina ja kuka omistaa säännöt, poikkeukset sekä muutokset.

Jos tätä järjestystä ei luoda jo ratkaisun arkkitehtuurivaiheessa, myöhempi vetoaminen laatuvaatimuksiin, prosessiturvallisuuteen tai dokumentointivelvoitteisiin jää helposti näennäiseksi. Tämä korostuu erityisesti silloin, kun järjestelmä vaikuttaa päätöksiin, joilla on merkitystä tuotteen laadun, prosessin turvallisuuden tai koneiden ja laitteiden kanssa tehtävän yhteistyön kannalta. Tällaisessa laajuudessa vaatimustenmukaisuusvaatimukset on ymmärrettävä operatiivisesti: tarpeena toiminnan johdonmukaisuudelle, jäljitettävyydelle, muutosten hallinnalle ja ratkaisun soveltuvuudelle todelliseen käyttötarkoitukseen. Kyse ei ole vain siitä, että toiminto on käytettävissä, vaan siitä, että voidaan osoittaa, miksi se toimii juuri näin, kuka on hyväksynyt sen logiikan ja miten sen muutosten vaikutuksia arvioidaan.

Useimmat ongelmat tulevat yleensä esiin vasta eivätkä käyttöönotossa, vaan muutaman kuukauden käytön jälkeen. Laitos lisää uuden tuotantovariantin, muuttaa hyväksymiskriteerejä, liittää mukaan uuden työaseman tai siirtää osan vastuusta operaattorilta järjestelmälle. Jos aiemmin ei ole määritelty, mitkä päätös- ja kirjausluokat edellyttävät auditointijälkeä, syntyy nopeasti kiista siitä, kenen muutos vaikutti laatuun, seisokkiin tai järjestelmän virheelliseen reagointiin. Vasta silloin näkyy ero toimivan ratkaisun ja hallittavan ratkaisun välillä. Jälkimmäisessä tiedetään etukäteen, mitkä logiikan osat edellyttävät muodollista hyväksymismenettelyä, kuka valvoo viitetietoja, kuka ylläpitää integraatiota automaatioon ja riittääkö projektidokumentaatio auditointiin, ylläpitoon sekä järjestelmän turvalliseen siirtämiseen toiselle toimittajalle.

• mitä päätöksiä järjestelmä tekee tai on mukana muovaamassa laadun, turvallisuuden ja koneen kanssa tehtävän yhteistyön alueella,
• mitkä tapahtumat, muutokset ja hyväksynnät on tallennettava niin, että niistä jää todennettava jälki,
• kuka omistaa liiketoimintasäännöt, tiedot ja poikkeukset sekä kuka hyväksyy niiden muutokset.

Vasta tällaisen jäsentämisen jälkeen on mielekästä suhteuttaa projekti kyseiselle laitokselle, tuotteelle, toimialalle ja koneisiin tai laitteisiin integroitumisen tapaan soveltuviin oikeudellisiin ja normatiivisiin vaatimuksiin. Suomen ja EU:n toimintaympäristössä kysymys ei ole vain siitä, toimiiko ratkaisu, vaan siitä, pystyykö organisaatio osoittamaan, miksi se toimii tällä tavalla, millä perusteella säännöt on hyväksytty ja miten muutoksia hallitaan heikentämättä jäljitettävyyttä. Tämän analyysin laajuus riippuu aina käyttökohteesta: raportointijärjestelmää arvioidaan eri tavoin kuin prosessin kulkuun vaikuttavaa logiikkaa, ja taas eri tavoin integraatiota, joka liittyy koneen toimintaan, riskinarviointiin tai integraattorin vastuun laajuuteen.

Johtopäätös on yksinkertainen. Räätälöity ohjelmisto on perusteltu silloin, kun se selkeyttää vastuita ja vähentää riskiä juuri siellä, missä valmis tuotannonohjaus- tai toiminnanohjausjärjestelmä edellyttäisi kalliita kompromisseja prosessilogiikassa, muutosten valvonnassa tai toimintojen jäljitettävyydessä. Kyse ei siis ole kaiken rakentamisesta alusta alkaen, vaan standardiratkaisun ja kriittisen logiikan erottamisesta toisistaan niin, että järjestelmä tukee laitoksen todellista prosessia sen sijaan, että se yksinkertaistaisi sitä laadun, turvallisuuden ja jäljitettävyyden kustannuksella.