Automaatiointegraattorin valinta: 5 kriteeriä, jotka todella ratkaisevat turvallisuuden ja projektin kokonaiskustannukset

Automaatiointegraattorin valinta ratkeaa harvoin pelkästään teknisin perustein. Käytännössä kyse on siitä, missä vaiheessa projekti paljastaa riskit: jo konsepti- ja määrittelyvaiheessa vai vasta asennuksen jälkeen, kun linjan pitäisi palata tuotantoon. Tehtaan näkökulmasta kalleimpia eivät yleensä ole yksittäiset ohjelmointivirheet, vaan virheelliset lähtöoletukset: muutosten rajaus on määritelty epäselvästi, rajapinnat olemassa olevaan järjestelmään on jätetty huomioimatta, testejä ei ole sovittu, dokumentaatio on puutteellinen ja vastuu on siirretty loppukäyttäjälle.

Siksi tarjouksen hinta pitäisi olla vain yksi arviointitekijä. Projektin todelliset kustannukset määräytyvät yleensä sen perusteella, mitä kysymyksiä integraattori esittää ennen tilausta, miten käyttöönotto viedään läpi ja millainen projektijälki työn päätyttyä jää. Juuri tässä kohdassa turvallisuus ja kustannukset lakkaavat olemasta erillisiä asioita.

Integroinnin hinta ei ole sama asia kuin projektin kustannus

Tarjouksen arvoa on helpointa vertailla, mutta se on yleensä heikoin valintaperuste. Palvelun hankintahinta on vain osa koko projektipäätöksen kustannuksesta. Investoinnin lopputuloksen ratkaisevat useammin ongelmat, jotka tulevat esiin vasta käyttöönoton jälkeen: suojausten muutostyöt, turvalogiikan muutokset, ristiriita vaaditun suorituskyvyn ja turvallisen käytön todellisten edellytysten välillä, vastaanottoon tarvittavan dokumentaation puutteet sekä viivästykset, jotka liittyvät järjestelmän uudelleenkäynnistämiseen. Siksi halvin tarjous osoittautuu harvoin edullisimmaksi ratkaisun koko elinkaaren aikana.

Modernisointiprojekteissa ero toteuttajan ja projektikumppanin välillä näkyy hyvin varhain. Toteuttaja tekee sen, mitä spesifikaatioon on kirjattu. Projektikumppani taas varmistaa ensin, ettei itse spesifikaatio sisällä oletuksia, joista myöhemmin syntyy kustannuksia tai vastuuta tehtaan puolelle. Hän osaa tunnistaa projektin rajat, rajapinnat olemassa olevaan linjaan, mekaniikan, ohjauksen ja turvallisuuden väliset riippuvuudet sekä muutosten vaikutuksen koneen statukseen modernisoinnin jälkeen ja vaatimustenmukaisuuden arviointiin. Kyse ei ole työskentelytyylistä vaan kyvystä hallita riskiä projektin alusta lähtien.

Suurin osa kalliista kiertoratkaisuista syntyy yleensä jo konseptivaiheessa. Tyypillinen tilanne etenee näin: projekti perustuu yksinkertaiseen ohjauksen vaihtoon, mutta vaikutusta työsekvenssiin, huollettavuuteen ja turvatoimintoihin ei analysoida. Käyttöönoton jälkeen käy ilmi, että käyttäjän on tehtävä ylimääräisiä manuaalisia toimenpiteitä, kunnossapito tarvitsee heikkoa suunnittelua paikkaavia menettelyjä ja suorituskyky laskee, koska turvallista pääsyä työalueille ei ole ratkaistu kunnolla. Tällöin alkavat tarjouksen ulkopuolelle jääneet korjaukset: mekaaniset muutokset, suojausten täydentäminen, turvapiirien uudelleenrakentaminen, dokumentaation päivittäminen ja uudet vastaanotot. Itse ohjaimen ohjelma on silloin usein ongelman pienin osa.

Siksi integraattorin tarjousta kannattaa lukea paitsi investointikustannusten myös käyttöönoton jälkeisten kulujen ja alussa esitettyjen kysymysten näkökulmasta. Hyvä merkki on lähtöoletusten tarkka kuvaus, olemassa olevaan järjestelmään liittyvien rajapintariskien osoittaminen, huomautukset lähtötietojen puutteista sekä valmius kyseenalaistaa tilaajan virheelliset odotukset. Huono merkki on lupaus nopeasta toteutuksesta ilman rajapintojen analysointia, viittausten puuttuminen olemassa olevan koneen dokumentaatioon, vastaanottoehtojen sivuuttaminen ja vaikeneminen siitä, kuka vastaa turvallisuudesta muutosten jälkeen. Tästä näkyy, että turvallisuus ja projektin ja CE-sertifioinnin piilokustannukset eivät ole lopussa lisättäviä asioita, vaan koko modernisoinnin reunaehto.

Viisi kriteeriä, jotka karsivat näennäiset säästöt

Kalleimpia eivät useinkaan ole ne projektit, joissa integraattorin lähtöhinta oli korkeampi, vaan ne, joissa ostettiin näennäistä yksinkertaisuutta. Siksi toteuttajan valinta kannattaa perustaa viiteen kriteeriin, jotka voidaan tarkistaa jo ennen sopimuksen allekirjoittamista. Ne toimivat yhtä hyvin teknisessä keskustelussa kuin tarjouspyynnössä tai tarjousten arviointimatriisissa.

Ensimmäinen kriteeri on projektikypsyys turvallisuuden alueella. Luotettava integraattori osaa kuvata ohjausarkkitehtuurin lisäksi myös vaarojen tunnistamisen tavan, lähtöoletukset, osapuolten välisen vastuunjaon sekä suojatoimenpiteiden valintalogiikan. Jos keskustelu päättyy ohjaimen, valoverhon tai lukon valintaan eikä johda kysymykseen siitä, kuka vastaa riskien arvioinnista muutosten jälkeen, mitä käyttötiloja on ja mitkä poikkeamat normaalista käytöstä on otettava huomioon, projektia johdetaan liian pinnallisesti.

Toinen kriteeri koskee kykyä toimia eri tekniikanalojen rajapinnoissa. Todelliset turvallisuusongelmat johtuvat harvoin yksittäisestä sähkövirheestä. Ne syntyvät rajapinnoissa: mekaanisen liikkeen ja suojauksen välillä, ohjaussekvenssin ja pneumatiikan välillä, järjestelmän resetoinnin ja vaaravyöhykkeen näkyvyyden välillä sekä käytön ergonomian ja asetusten vaihdon organisoinnin välillä. Integraattori, joka ei tunnista näitä riippuvuuksia, siirtää niiden kustannukset yleensä käyttöönoton vaiheeseen.

Kolmas kriteeri on dokumentaation laatu ja päätöksenteon jäljitettävyys. Tarjousvaiheessa pitäisi olla selvää, sisältyvätkö toimittajan toimitukseen turvallisuuskonsepti, kaaviot, tulo- ja lähtöluettelo, toimintakuvaus, testisuunnitelma, muutosloki ja vastaanoton ehdot. Dokumentaation puute tarkoittaa lähes aina sitä, että kustannukset siirtyvät laitokselle: kunnossapito käyttää aikaa toimintalogiikan selvittämiseen, seuraavia muutoksia tehdään ilman varmuutta niiden vaikutuksista, ja vaatimustenmukaisuuden arviointi modernisoinnin jälkeen vaikeutuu, koska ei tiedetä, mitä lähtöoletuksia on käytetty ja mitä todella on muutettu. Hyvä dokumentaatio ei ole hallinnollinen lisä, vaan teknisen riskin hallinnan väline.

Neljäs kriteeri on käyttöönoton ja vastaanoton toteutustapa. Laitokselle ei ole olennaista vain se, käynnistyykö kone, vaan myös se, onko käyttöönotto suunniteltu niin, että toiminnallisten ja turvallisuusvaatimusten täyttyminen voidaan todentaa objektiivisesti. Integraattorin tulisi määrittää etukäteen testiskenaariot, hyväksymiskriteerit, käyttöön luovutuksen ehdot ja menettely poikkeamien käsittelyyn. Jos vastaanotto perustuu pelkästään tuotannon käynnistämiseen ja vikojen korjaamiseen lennossa, tilaaja ottaa kantaakseen riskin laajuutta koskevista kiistoista, viivästyksistä ja kalliista korjauksista seisokin jälkeen.

Viides kriteeri on ratkaisun huollettavuus ja kestävyys. Ohjelma voi toimia käyttöönoton päivänä oikein ja silti olla kirjoitettu epäselvästi, ilman järkevää diagnostiikkaa, ilman versionhallintaa ja ilman valmiutta tuleviin muutoksiin. Tällöin jokaisesta viasta, laajennuksesta tai komponentin vaihdosta tulee tavanomaista riskialttiimpi toimenpide. Hyvin valmisteltu ratkaisu mahdollistaa ohjelmaversion palauttamisen, pysähdyksen syyn selvittämisen, turvallisuusparametrien varmistamisen ja muutosten tekemisen niin, ettei suojaustaso heikkene.

Nämä kriteerit voidaan tarkistaa nopeasti muutamalla kysymyksellä:

• Miten vaarojen tunnistaminen, muutosten laajuus ja vastuunjako integraattorin sekä käyttäjän välillä kuvataan?
• Mitkä asiakirjat ovat vastaanoton edellytys: kaaviot, toimintakuvaus, testisuunnitelma, pöytäkirjat, muutosloki, ohjelmakopiot ja turvallisuusversiot?
• Miten toiminnalliset testit ja turvallisuuteen liittyvät testit suoritetaan, ja kuka hyväksyy poikkeamat ja poikkeusratkaisut?
• Miten ratkaisua huolletaan vuoden kuluttua ja seuraavan modernisoinnin jälkeen: diagnostiikka, varaosien saatavuus, ohjelman selkeys, versioiden palautus?

Jos vastaukset ovat ympäripyöreitä, ongelma ei liity viestintätyyliin vaan prosessin kypsyyteen. Kustannusten ja vaatimustenmukaisuuden näkökulmasta juuri silloin kasvaa riski, että laitos joutuu ottamaan vastuulleen tehtäviä, joita ei ole huomioitu budjetissa eikä aikataulussa.

Missä integraattori synnyttää kustannuksia tai poistaa niitä

Integraattorin työn kustannuksia arvioi parhaiten sen perusteella, missä projektin vaiheessa ongelmat tulevat esiin. Jos vaikeat päätökset nousevat esille vasta käyttöönoton aikana, kustannukset siirtyvät lähes aina laitokselle: ylimääräisenä seisokkina, tuotannon paineessa tehtävinä muutoksina ja epäselvänä vastuuna siitä, mitä todella muutettiin. Hyvin johdetussa projektissa nämä kustannukset poistetaan jo aiemmin. Vaaditun tahdin, operaattorin pääsyn, huoltopääsyn ja suojaustoimenpiteiden välinen ristiriita pitäisi tunnistaa konseptivaiheessa, ei vasta hallissa asennuksen jälkeen.

Tässä kohtaa on helpointa erottaa toisistaan toimittaja, joka vain ”vaihtaa ohjauksen”, ja integraattori, joka vastaa ratkaisun kokonaisuuden johdonmukaisuudesta. Olemassa olevan koneen tai linjan osan modernisointi harvoin tarkoittaa pelkkää ohjaimen ja muutaman käyttölaitteen vaihtoa. Työlogiikan muutos vaikuttaa yleensä koko riippuvuuksien järjestelmään: liikesekvenssi etenee eri tavalla, reaktioajat muuttuvat ja esiin tulee tarve toisenlaiselle pääsylle asetusten vaihdon, puhdistuksen tai jumitilanteiden purkamisen aikana. Jos integraattori ei analysoi tätä ennen projektin lukitsemista, ohjaus voi toimia oikein, mutta kokonaisuus ei silti ole valmis turvalliseen käyttöön.

Tyypillinen esimerkki on yksinkertainen. Laitos suunnittelee pakkausaseman modernisointia lyhyessä huoltoikkunassa. Alkuoletus vaikuttaa järkevältä: vanhentuneen ohjauksen vaihto, käyttölaitteiden selkeyttäminen, muutama korjaus sekvenssiin ilman mekaanisia muutoksia. Käynnistyksen jälkeen kuitenkin käy ilmi, että uusi logiikka edellyttää operaattorin aiempaa tiheämpää pääsyä materiaalin syöttöalueelle, ja nykyiset suojukset sekä suojauslaitteiden sijoittelu pidentävät jokaista toimenpidettä tuotannon kannalta kestämättömästi. Kunnossapito alkaa etsiä kiertoteitä, työturvallisuudesta vastaavat kyseenalaistavat pääsytavan, tuotanto painostaa palauttamaan tahdin, ja integraattori toteaa ohjelman toimivan sovitun toiminnon mukaisesti. Seuraavassa vaiheessa on muutettava suojuksia, rakennettava uudelleen toimenpiteiden kuittaus, tarkennettava asetusten vaihtomenettelyä ja täydennettävä käyttö- ja huolto-ohjeita.

Jokainen näistä muutoksista voi erikseen näyttää vähäiseltä, mutta yhdessä ne muodostavat kustannuskaskadin: lisää päiviä, jolloin asema ei ole käytettävissä, uusia poikkeamia vastaanotossa, uusia toimenpiteitä tuotannon käynnistymisen jälkeen ja kiistan siitä, oliko havaittu ongelma laajuuden muutos vai virheellisen konseptin seuraus. Sama tapaus näyttää aivan toisenlaiselta, kun se hoidetaan huolellisesti jo muutamaa viikkoa aiemmin. Integraattori osoittaa, että vaadittu tahti ja odotettu käyttötapa ovat ristiriidassa nykyisen suojaratkaisun ja huoltopääsyn kanssa. Hän ei peitä ongelmaa toteamalla, että ”se selviää käyttöönotossa”, vaan esittää vaihtoehdot ja niiden seuraukset prosessille, turvallisuudelle sekä myöhemmälle vastaanotolle.

Juuri tässä vaiheessa tehdas voi tehdä tietoisen päätöksen: toteutetaanko täysi modernisointi vai vaiheistetaanko työ, vaikka vaatimuksia ei olisi määritelty täydellisesti, kunhan käyttöönoton aikana esiin tuleville muutoksille on selkeästi kuvattu vastuunraja. Käytännössä kannattaa siis kysyä paitsi lupauksista myös aiempien toteutusten kulusta: kuinka paljon muutoksia tehtiin projektin jäädyttämisen jälkeen, kuinka monta poikkeamaa ilmeni vastaanotossa, kuinka monta toimenpidettä tarvittiin käynnistyksen jälkeen ja mikä oli työaseman todellinen käyttökatkon kesto. Tällaiset kysymykset paljastavat nopeasti, onko kyse tavanomaisesta käyttöönotto-ongelmasta vai suunnitteluvirheestä.

Vasta tätä taustaa vasten dokumentaation, testauksen ja vaatimustenmukaisuuden arvioinnin rooli modernisoinnin jälkeen näkyy selvästi. Ne eivät ole valmiiseen koneeseen liitetty byrokraattinen lisä. Ne ovat seurausta hyvästä suunnitteluprosessista, jossa ohjauslogiikka yhdistyy turvallisuuteen, käytön ergonomiaan ja kunnossapidon tarpeisiin. Jos näitä osa-alueita ei kehitetä rinnakkain, tehdas ottaa riskin kannettavakseen kaikkein huonoimmalla hetkellä: asennuksen jälkeen, tuotannon uudelleenkäynnistyksen paineessa ja ilman varmuutta siitä, synnyttääkö muutosten laajuus loppukäyttäjälle lisävelvoitteita.

Miten ostaa vastuullisesti ennen kuin ongelmia ilmenee

Hyvä hankintapäätös automaatiossa ei ala hintojen vertailusta vaan siitä, kuinka laadukasta lähtötietoa integraattorille annetaan. Jos tarjouspyyntö kuvaa vain tavoitellun tuotannollisen lopputuloksen, toimittaja määrittelee itse projektin rajat, käyttöperiaatteet, huoltoehdot ja olemassa olevaa linjaa koskevat oletukset. Käytännössä tämä tarkoittaa yleensä sitä, että halvin tarjous on halvin vain siksi, että siitä puuttuvat kustannuksia aiheuttavat osat, jotka tulevat esiin vasta käyttöönotossa.

Siksi tehtaan tulisi kuvata koneen tai modernisoinnin toiminnon lisäksi myös prosessin rajoitteet, käyttövaatimukset, rajapinnat jo käytössä oleviin järjestelmiin ja laitteisiin, odotettu huoltotila, seisokin ehdot sekä kunnossapitoa, koulutusta ja myöhempiä muutoksia varten tarvittavan dokumentaation laajuus. Tässä vaiheessa on myös ratkaistava, toteutetaanko mekaniikan ja automaation osuudet yhdessä vai erikseen ja kuka vastaa eri tekniikka-alojen rajapinnoista. Mitä täsmällisemmät lähtötiedot ovat, sitä pienempi on riski, että tarjous kätkee kustannuksia, jotka siirtyvät myöhempään vaiheeseen.

Tarjousten arvioinnissa ei pitäisi palkita lupausta ”teemme kaiken kokonaisvaltaisesti”, vaan sitä, mikä voidaan varmistaa ennen tilausta. Hyvä tarjous sisältää työsuunnitelman, hinnoittelun perusteena käytettyjen oletusten luettelon, tunnistetut riskit, tehtaan puolelta tarvittavat lähtötiedot, vastuunjaon sekä testauksen toteutustavan ennen toimitusta ja käyttöönoton yhteydessä. Siinä tulisi myös kuvata selkeästi vastaanoton ehdot: mikä on hyväksynnän välttämätön edellytys ja mikä voidaan siirtää avoimien kohtien listalle suljettavaksi käynnistyksen jälkeen. Jos integraattori ei osaa nimetä riskejä, määritellä hyväksymiskriteerejä tai osoittaa puuttuvia tietoja, ongelma ei katoa tilauksen allekirjoittamisen jälkeen. Se siirtyy vain seisokkiaikatauluun ja muutosten budjettiin.

Eniten väärinkäsityksiä syntyy myöhemmin yleensä ei itse tekniikasta vaan epätarkasta sopimuksesta. Kaupallisen asiakirjan tulisi jäsentää paitsi aikataulu ja hinta myös muutostenhallinnan menettely, oikeudet lähdekoodiin, suunnitelmaan ja dokumentaatioon, osapuolten velvollisuudet käyttöönotossa, hyväksymiskriteerit sekä täydellinen luettelo vastaanotossa luovutettavista aineistoista. Tähän kuuluvat ohjainten ja paneelien ohjelmat, varmuuskopiot, kaaviot, signaaliluettelot, asetukset, ohjeet, testitulokset sekä asiakirjat, joita tarvitaan jatkokäyttöön ja mahdolliseen vaatimustenmukaisuuden arviointiprosessiin. Hyvä käytäntö on sitoa lopullinen vastaanotto ja viimeinen maksu dokumentaation täydellisyyteen sekä sovittujen testien suorittamiseen, koska juuri silloin integraattorin todellinen valmiustaso tulee näkyviin.

• tarjouspyynnössä: toiminto, prosessin rajoitteet, rajapinnat, huoltotila, odotettu dokumentaatio, projektin rajat
• tarjouksessa: oletukset, riskit, testisuunnitelma, osapuolten vastuut, vastaanoton ehdot
• sopimuksessa ja vastaanotossa: muutossäännöt, oikeudet koodiin ja asiakirjoihin, luovutuksen täydellinen sisältö, hyväksymiskriteerit

Viittauksen muodollisiin vaatimuksiin tulisi täydentää päätöstä, ei korvata sitä. Pelkät viittaukset koneturvallisuuteen, vaatimustenmukaisuuden arviointiin, tekniseen dokumentaatioon, ohjeisiin tai turvallisuustoimintojen verifiointiin eivät korjaa huonosti määriteltyä laajuutta tai epäselvää vastuunjakoa. Jos hanke koskee uutta konetta tai modernisointia, jota voidaan pitää olennaisena muutoksena, tämä on tunnistettava riittävän varhain, jo ennen tilausta ja ennen toteutustavan hyväksymistä. Muussa tapauksessa loppukäyttäjälle voi jäädä velvoitteita, joita ei ole huomioitu tarjouksessa eikä aikataulussa.

Käytännön johtopäätös on yksinkertainen: on edullisempaa käyttää enemmän aikaa tarjouspyynnön valmisteluun, integraattorin arviointiin ja linjan turvallisuuden tarkastukseen ennen tuotannon käynnistämistä kuin rahoittaa korjauksia siinä vaiheessa, kun linja on jo pysähdyksissä ja osapuolten vastuut ovat edelleen epäselvät. Turvallisuus ei ole automaatiointegraattorin valinnassa sivukulu. Se on nopein tapa rajoittaa kustannuksia, jotka syntyvät silloin, kun projekti on määritelty väärin jo aivan alussa. Käytännössä tässä auttaa myös hyvin organisoitu integraattorin ja kunnossapidon välinen yhteistyö sekä tehtaan asianmukainen valmistelu tuotannon automatisointiin.