Oma suunnittelutoimisto vai ulkoistaminen – kumpi on kannattavampaa koneenrakennuksessa?

Päätös siitä, kehitetäänkö omaa suunnitteluorganisaatiota vai perustuuko koneiden rakentaminen ulkoistukseen, ei enää ole pelkästään kysymys henkilöstökustannuksista tai toimittajan veloituksesta. Nykyisin se vaikuttaa suoraan käyttöönoton aikatauluun, kykyyn tehdä rakenteellisia muutoksia, valmistajan riskitasoon sekä todelliseen vaatimustenmukaisuuden hallintaan. Hankkeissa, joissa mekaniikan, automaation, ohjelmiston, toiminnallisen turvallisuuden ja teknisen dokumentaation on kohdattava samassa hyväksyntäpisteessä, väärä toimintamalli kostautuu yleensä vasta projektin loppuvaiheessa: vastaanotoissa, laajuusmuutoksissa, validoinnissa tai käyttäjälle ja huollolle laadittavan dokumentaation valmistelussa. Käytännössä kysymys ei siis ole siitä, mikä on ”halvempi”, vaan siitä, mikä malli mahdollistaa vastuun, suunnittelutiedon ja päätöksenteon nopeuden pitämisen koneen monimutkaisuutta vastaavalla tasolla.

Tämän valinnan merkitys kasvaa myös siksi, että nykyaikainen kone on harvoin enää pelkkä mekaaninen järjestelmä yksinkertaisella ohjauksella. Yhä useammin siihen kuuluu ohjelmistokerros, yhteydet tehtaan järjestelmiin, tapahtumien rekisteröinti, tuotteen ja prosessin jäljitettävyysketju sekä lisäksi kunnossapidon vaatimukset diagnostiikalle ja huollettavuudelle. Siksi raja ”koneprojektin” ja usean osaamisalueen yhteistyön organisoinnin välillä hämärtyy hyvin nopeasti. Jos jo alussa tiedetään, että projektiin osallistuvat integraattori, ohjelmistotoimittaja ja asiakkaan kunnossapitotiimi, päätös oman toteutuksen ja ulkoisen toimittajan välillä muuttuu luontevasti kysymykseksi roolijaosta, rajapintojen vastuista ja teknisten päätösten omistajuudesta. Samalla tavoin aihe laajenee silloin, kun koneen on tuotettava tuotantodataa tai tuettava jäljitettävyyttä: ilman sopimusta siitä, kuka vastaa tietoarkkitehtuurista, logiikan validoinnista ja muutosten ylläpidosta, on helppo rakentaa ratkaisu, joka toimii esittelyssä mutta on kallis käyttää.

Käytännössä hyödyllisin päätöskriteeri ei ole pelkkä toteutusbudjettien vertailu, vaan se, missä koneen elinkaaren kannalta kriittinen tieto syntyy ja minne sen on tarkoitus jäädä. Jos yrityksen etuna on ainutlaatuinen prosessi, tuotteen toistuvat muutokset, tarve nopeisiin uudelleenasetuksiin tai saman alustan seuraavien versioiden kehittäminen, oman suunnitteluosaamisen puute nostaa jokaisen seuraavan muutoksen kustannusta. Toisaalta silloin, kun projektin laajuus on selkeästi määritelty, toistuvia muutoksia on vähän eikä hanke muodosta yrityksen kilpailuedun ydintä, ulkoinen toimittaja voi olla järkevä ratkaisu, kunhan tilaaja säilyttää hallinnan vaatimuksista, vastaanotoista ja dokumentaatiosta. Hyvä testi on vastata kolmeen kysymykseen: kuka tekee päätöksen laajuuden muuttuessa, kuka ymmärtää muutoksen vaikutukset koneen turvallisuuteen ja toimintoihin sekä kuka pystyy ylläpitämään ratkaisua käyttöönoton jälkeen ilman riippuvuutta yhdestä henkilöstä tai yhdestä toimittajasta. Nämä ovat organisatorisia mittareita, jotka ennustavat kannattavuutta yleensä paremmin kuin pelkkä projektin hintalappu.

Tyypillinen esimerkki toistuu monessa tuotantolaitoksessa. Yritys ulkoistaa koneen suunnittelun ja toteutuksen, koska se haluaa nopeuttaa investoinnin käynnistämistä. Alussa se saa nopeutta, mutta muutaman kuukauden kuluttua ilmenee muutoksia, jotka johtuvat teknologiakokeista, tuotannon tarpeista ja laatuvaatimuksista. Jos yrityksellä ei ole omalla puolellaan tiimiä, joka kykenee arvioimaan näiden muutosten vaikutuksia rakenteeseen, ohjaukseen, diagnostiikkaan ja dokumentaatioon, jokaisesta korjauksesta tulee erillinen tilaus ja aikataulu alkaa riippua toimittajan saatavuudesta. Tällöin ulkoistaminen ei enää ole osaamisen hankintaa, vaan pullonkaulan siirtämistä organisaation ulkopuolelle. Juuri tässä kohdassa aihe liittyy integraattorin, ohjelmistotoimittajan ja kunnossapidon yhteistyön organisointiin sekä jäljitettävyyden suunnitteluun: jos näillä alueilla ei ole yhteistä vaatimusten omistajaa, projekti menettää operatiivisen yhtenäisyytensä jo ennen vastaanottoa.

Lopulta esiin nousee joka tapauksessa vastuun kysymys. Toteutusmallista riippumatta valmistaja, maahantuoja tai muu taho, joka saattaa koneen markkinoille tai ottaa sen käyttöön, vastaa soveltuvin osin tuotteen vaatimustenmukaisuudesta, dokumentaation täydellisyydestä ja riskien arvioinnin asianmukaisesta toteuttamisesta. Siksi valintaa oman suunnitteluorganisaation ja ulkoistuksen välillä on arvioitava myös siitä näkökulmasta, kuka pystyy osoittamaan suunnittelupäätösten perusteet, jäljittämään muutosten historian ja kokoamaan aineiston, jota tarvitaan projektista sertifiointiin sekä CE-merkintään, jos kyseinen tapaus sitä edellyttää. Jos organisaatio ei pysty tätä varmistamaan, näennäinen säästö projektin alkuvaiheessa muuttuu hyvin helposti viivästyskustannukseksi, riidaksi toimittajan kanssa tai ongelmaksi teknisessä vastaanotossa ja käytön aikana.

Missä kustannukset tai riskit kasvavat useimmiten

Oman suunnittelutoimiston ja ulkoistamisen välisessä vertailussa kustannukset kasvavat harvoin siellä, mihin alussa yleensä katsotaan eli suunnittelijan tuntihinnassa tai työpaketin tarjoushinnassa. Useimmiten ongelma alkaa jo aiemmin: koneen rajauksia, rajapintoja, lähtöoletuksista vastaamista ja muutosten hyväksymistapaa ei ole määritelty riittävän tarkasti. Jos näitä asioita ei lukita alussa, sisäinen tiimi käyttää aikaa yhteensovittamiseen ja korjauksiin, kun taas ulkoinen toimittaja suunnittelee omien oletustensa varassa, joita joudutaan myöhemmin purkamaan. Käytännössä tämä tarkoittaa paitsi lisätyötunteja myös komponenttihankintojen viivästymistä, asennusvaiheen yhteentörmäyksiä ja kiistaa siitä, johtuuko virhe puutteellisesta suunnittelusta vai epätarkasta tilauksesta. Siksi ensimmäinen päätöskriteeri ei saisi olla se, kuka ”tekee halvemmalla”, vaan se, kuka pystyy kyseisessä toteutusmallissa pitämään tekniset vaatimukset, turvallisuuden ja käytettävyyden yhtenäisenä kokonaisuutena konseptista vastaanottoon asti.

Toinen kohta, jossa riski kasvaa, on osaamisen jakaminen ilman vastuunjakoa. Oma suunnittelutoimisto voi näyttää turvalliselta ratkaisulta, koska tieto jää organisaatioon, mutta jos projektia vetävät henkilöt, joilla on samanaikaisesti vastuullaan tuotannon tuki, kunnossapito ja jatkuvat muutokset, projektia alkaa ohjata ihmisten saatavuus eikä tekninen logiikka. Insinöörien ulkoistaminen puolestaan tuo resurssit nopeammin käyttöön, mutta ilman tilaajan puolella olevaa kypsää ohjausta se johtaa helposti tilanteeseen, jossa toimittaja toimittaa dokumentaation, joka riittää vaiheen laskutukseen, mutta ei huoltoon, modernisointiin tai suunnittelupäätösten perusteiden osoittamiseen. Tällaisen puutteen kustannukset näkyvät myöhemmin: vikatilanteessa, toimittajaa vaihdettaessa, linjaa laajennettaessa tai silloin, kun on varmistettava, onko kone turvallinen ei vain väitteen tasolla vaan todellisten ratkaisujen ja päätöspolun perusteella.

Kalleimmat virheet ovat yleensä kasautuvia. Tyypillinen esimerkki on projekti, jossa mekaniikka, ohjaus ja riskin pienentämistoimenpiteet syntyvät organisaation eri osissa tai eri toimittajilla. Mekaniikkasuunnittelija olettaa tietyn tavan päästä työalueelle, automaatiosuunnittelija valitsee pysäytyslogiikan puutteellisten tietojen perusteella, ja hankinta tilaa osat toimitusajan eikä turvallisuus- ja kunnossapito-oletusten mukaan. Käyttöönotossa käy ilmi, että suojus vaikeuttaa asetusten vaihtoa, anturilla ei ole vakaata käyttöympäristöä ja käsikäytön menettelyä ei ole kuvattu lainkaan. Tällöin projekti palaa uudelleensuunnitteluun, dokumentaatiomuutosten määrä kasvaa ja laajuus on sovittava toimittajan kanssa uudelleen. Käytännöllinen arviointikriteeri on tässä yksinkertainen: jos organisaatio ei pysty yhden katselmuksen aikana osoittamaan vaatimusten omistajaa, riskien arvioinnin omistajaa ja muutospäätöksen omistajaa, sillä on toteutusmallista riippumatta edellytykset kustannusten ja vastuiden kasvulle.

Tästä päästään prosessiriskien käsittelyyn aiemmin kuin moni yritys olettaa. Jos projekti koskee järjestelmää, jossa prosessin vaikutukset, toimintasekvenssit ja työn organisoinnista riippuvat vaaratilanteet ovat olennaisia, pelkkä ”suojausten lisääminen suunnitteluun” tulee liian myöhään. Tällöin merkitystä ei ole vain suunnittelijan kokemuksella, vaan myös sillä, osaako tiimi tehdä järjestelmällistä vaarojen ja poikkeamien analyysiä, eli onko sillä HAZOP-koulutuksessa kehitettävän osaamisen kaltaista pätevyyttä. Kyse ei ole muodollisuuksista muodollisuuksien vuoksi, vaan kyvystä tunnistaa kohdat, joissa teknologinen, käytöllinen ja turvallisuuteen liittyvä päätös vaikuttavat toisiinsa. Jos tätä kykyä ei ole yrityksen sisällä, ulkoistaminen voi olla perusteltua; jos sitä ei ole myöskään toimittajalla, riski vain siirtyy organisaation ulkopuolelle.

Vasta lopussa näkyy vaatimustenmukaisuuden ulottuvuus. Kun projekti etenee vastaanottoon, modernisointiin tai käyttöönottoon, esiin nousee kysymys ei siitä, kuka teki 3D-mallin tai kirjoitti ohjelman, vaan siitä, voidaanko osoittaa, että valitut ratkaisut olivat perusteltuja, riskit arvioitu ja dokumentaatio vastaa toteutettua kokonaisuutta. Tässä kohdassa valinta oman toimiston ja ulkoisen toimijan välillä liittyy jo suoraan koneen valmisteluun suunnittelusta sertifiointiin ja CE-merkintään ja vaatimustenmukaisuuden arviointiin, jos kyseinen tapaus sitä edellyttää. Jos näyttöaineisto on puutteellinen, kustannus lakkaa olemasta suunnittelukustannus ja muuttuu vastuukustannukseksi: viivästyneeksi käyttöönotoksi, lisämuutostöiksi, vaikeaksi vastaanotoksi tai käytön rajoituksiksi. Siksi toteutusmallien järkevä vertailu kannattaa perustaa mitattaviin tunnuslukuihin: lähtöoletusten jäädyttämisen jälkeen tehtyjen muutosten määrään, eri alojen välisten päätösten hyväksyntäaikaan, toteumadokumentaation kattavuuteen ja kykyyn jäljittää, miksi tietty ratkaisu katsottiin hyväksyttäväksi.

Kuinka lähestyä aihetta käytännössä

Käytännössä kysymystä omasta suunnittelutoimistosta tai ulkoistamisesta ei pitäisi tarkastella tuntihintojen tasolla, vaan sen kautta, kuka ohjaa teknisiä päätöksiä ja kuka vastaa niiden seurauksista. Kannattavin on se toimintamalli, joka mahdollistaa perusteltujen suunnittelupäätösten tekemisen nopeammin, säilyttää yhtenäisyyden mekaniikan, automaation ja turvallisuuden välillä sekä vie hankkeen ilman turhia menetyksiä konseptista käyttöönottoon. Jos sisäinen tiimi tuntee hyvin prosessin, laitoksen rajoitteet ja vastaavien toteutusten historian, se yleensä voittaa aikaa ja parantaa yhteensovittamisen laatua. Jos taas resursseja projektin johtamiseen, lähtöoletusten varmistamiseen ja dokumentaation hyväksyntään ei ole, kaiken pitäminen omissa käsissä on usein vain näennäistä säästöä. Silloin kustannus ilmestyy myöhemmin: asennuksen jälkeisinä muutoksina, kiistoina vastuunjaosta tai dokumentaationa, josta ei voida osoittaa, miksi tietty ratkaisu katsottiin hyväksyttäväksi.

Siksi päätös kannattaa perustaa yhteen käytännölliseen kriteeriin: missä organisaatiossa on kyky tehdä ja perustella rajatapauksia koskevat päätökset. Kyse on tilanteista, joissa on ratkaistava, toteutetaanko tietty toiminto laitteistolla vai ohjelmallisesti, vaikuttaako muutos jo turvallisuuteen, voidaanko poikkeama alkuperäisistä oletuksista hyväksyä sekä kuka hyväksyy käytettävyyteen ja kunnossapitoon vaikuttavan muutoksen. Jos yrityksellä on sisäisesti osaaminen tällaisten ratkaisujen johtamiseen, insinöörien ulkoistaminen voi koskea vain osaa töistä ilman, että projektin hallinta menetetään. Jos tätä osaamista ei ole, ulkoisen toimittajan on otettava vastuulleen paitsi suunnittelu myös päätöksenteon rakenne, ja tämä edellyttää selkeästi määriteltyjä hyväksyntäpisteitä, lähtötietojen laajuutta ja muutosten hyväksymisperiaatteita. Ilman tätä ulkoistaminen ei lyhennä prosessia, vaan luo vain ylimääräisen yhteensovituskerroksen.

Tyypillinen esimerkki on koneen modernisointi, jossa tilaaja antaa mekaniikan ja ohjauksen ulkopuoliselle toimittajalle ja jättää itselleen vain kunnossapidon sekä lopullisen vastaanoton. Aluksi tämä näyttää järkevältä, koska toimittaja ilmoittaa toteuttavansa kokonaisuuden. Ongelmat alkavat silloin, kun työn aikana käy ilmi, että uusi syöttöjärjestelmä muuttaa pääsyä vaaravyöhykkeelle ja samalla ohjausohjelman on kompensoitava rakenteesta johtuvia rajoitteita. Jos kukaan tilaajan puolella ei pysty arvioimaan tällaisen muutoksen vaikutuksia koko koneeseen, päätöksiä tehdään reaktiivisesti ja aikataulupaineessa. Lopputuloksena voi olla laite, joka toimii teknologisesti, mutta vaatii myöhemmin muutoksia suojuksiin, lukituksiin, ohjauslogiikkaan tai dokumentaatioon. Juuri tässä kohdassa kustannuskysymys siirtyy käytännön arviointiin siitä, onko kone turvallinen, ja edelleen — jos projektin laajuus sitä edellyttää — aineiston valmisteluun vaatimustenmukaisuuden osoittamista varten.

Johtamisen näkökulmasta tämä tarkoittaa, että on mitattava paitsi toimittajan tehokkuutta myös projektin toteutuksen laatua. Jos lähtöoletusten lukitsemisen jälkeen lisääntyy turvallisuuteen vaikuttavien muutosten määrä, jos eri tekniikka-alojen välisten päätösten hyväksyntä kestää pitkään tai jos toteumadokumentaatio ei pysy todellisen toteutuksen mukana, se on merkki siitä, että toteutusmalli on asetettu väärin. Oma suunnittelutoimisto tuo etua siellä, missä tuotetta koskevan tiedon jatkuvuus ja nopea reagointi muutoksiin ovat ratkaisevia. Ulkoistaminen on järkevää siellä, missä laajuus on määritelty hyvin, rajapinnat on suljettu ja vastuu lopputuloksesta on jaettu ilman aukkoja. Kun projektiin osallistuu lisäksi integraattori, ohjelmistotoimittaja ja kunnossapito, pelkkä päätös ”tehdäänkö sisäisesti vai annetaanko ulkopuolelle” ei enää riitä; yhtä tärkeää on järjestää näiden osapuolten yhteistyö selkeäksi, sillä vasta se ratkaisee käyttöönoton aikataulun, muutosten kustannukset ja mahdollisuuden luotettavaan vastaanottoon.

Normatiivinen ja muodollinen ulottuvuus ei tule esiin vasta lopussa, vaan juuri siinä kohdassa, jossa suunnittelupäätös vaikuttaa turvallisuustoimintoon, käyttötapaan tai koneen muutoksen laajuuteen. Tämä ei aina johda organisaation kannalta samaan velvoitteeseen, koska merkitystä on projektin luonteella ja kyseisen osapuolen roolilla. Yksi yksinkertainen periaate on kuitenkin syytä omaksua: jos teknisten päätösten perusteita, riskien arviointia ja työn aikana tehtyjä muutoksia ei pystytä jälkikäteen osoittamaan, in-house-mallin tai ulkoistamisen valinta ei ole enää tehokkuuskysymys vaan vastuukysymys. Tällöin keskustelu siirtyy luontevasti kahteen seuraavaan alueeseen: miten varmistetaan, että kone on turvallinen todellisessa toteutuksessaan, sekä milloin projekti edellyttää jo polun jäsentämistä suunnittelusta vaatimustenmukaisuuden arviointiin ja CE-merkintään.

Mitä käyttöönotossa on syytä huomioida

Käyttöönotossa ero oman suunnittelutoimiston ja ulkoistamisen välillä ei enää ole kiista työtunnin hinnasta. Kannattavuuden ratkaisee se, kuka käytännössä hallitsee muutoksia, kuka ymmärtää prosessin rajoitteet ja kuka pystyy perustelemaan valitut ratkaisut, kun ongelma ilmenee käyttöönotossa tai vastaanotossa. Kalleimpia eivät ole itse suunnitteluvirheet vaan liian myöhään paljastuvat virheet: ristiriidat mekaniikan ja ohjauksen välillä, puutteellisesti määritellyt rajapinnat, loppukäyttäjältä puuttuvat lähtötiedot, epäselvä vastuunjako turvallisuudesta. Jos organisaatio valitsee ulkoistamisen ilman omaa kykyä tekniseen valvontaan, se ostaa yleensä paitsi projektin myös riippuvuuden toimittajasta jokaisessa muutoksessa. Jos taas kaikki pidetään sisällä, mutta tiimillä ei ole aikaa päätösten dokumentointiin ja eri tekniikka-alojen yhteisiin katselmointeihin, kustannus palaa korjausten, vastaanottojen ja huollon vaiheessa.

Yleisin ansa on se, että toteutusmalli valitaan käytettävissä olevien resurssien eikä projektin riskityypin perusteella. Toistuvaa konetta, jota kehitetään oman standardin pohjalta, arvioidaan eri tavalla kuin uutta työasemaa, jossa on poikkeava kinematiikka, suuri vaikutus prosessiin tai merkittävä osuus turvatoimintoja. Käytännöllinen arviointiperuste on yksinkertainen: on varmistettava, onko tilaajan puolella osaamista hyväksyä tekniset lähtöoletukset, rakenteelliset muutokset ja ohjausarkkitehtuuri eikä pelkästään vastaanottaa valmista lopputulosta. Jos tällaista osaamista ei ole, täysi insinöörien ulkoistaminen voi näyttää edullisemmalta, mutta se lisää riskiä kiistoihin työn laajuudesta, pidentää yhteensovittamista ja vaikeuttaa sen arviointia, johtuuko viivästys toimittajan virheestä vai puutteellisista lähtövaatimuksista. Siksi kannattaa mitata budjetin ja aikataulun lisäksi myös muutosten määrää konseptin jäädyttämisen jälkeen, dokumentaation hyväksyntään kuluvaa aikaa, käyttöönoton jälkeen avoinna olevien poikkeamien määrää sekä niiden sulkemiseen tarvittavaa aikaa.

Käytännössä tämä näkyy hyvin olemassa olevan koneen modernisoinnissa tai linjan rakentamisessa, jossa on mukana useita osapuolia. Oma suunnitteluosasto ymmärtää usein paremmin tehtaan rajoitteet, huollettavuuden, kunnossapidon standardit ja laitteen todellisen käyttötavan. Ulkopuolinen toimittaja on puolestaan usein nopeampi projektin valmistelussa ja tehokkaampi erikoisosaamista vaativissa kysymyksissä, mutta häneltä voi puuttua kokonaiskuva käyttöympäristöstä. Jos käyttöönoton vaiheessa käy ilmi, että suojarakenteiden järjestelyä, työsekvenssiä tai pysäytyksen jälkeistä kuittaustapaa on muutettava, kysymys ei enää ole siitä, kuka tekee piirustuksen tai korjaa ohjelman. Kysymys on siitä, kuka arvioi muutoksen vaikutuksen turvallisuuteen, koneen toimintaan ja dokumentaation kattavuuteen. Tässä kohtaa kannattavuuden tarkastelu siirtyy luontevasti käytännön arvioon siitä, miten varmistetaan, että kone on turvallinen todellisessa toteutuksessa eikä vain suunnitteluoletuksissa.

Vasta tätä taustaa vasten muodollinen ulottuvuus tulee näkyviin. Kaikki projektimuutokset eivät johda samoihin velvoitteisiin, mutta jokainen olennainen puuttuminen toimintaan, käyttötapaan tai turvallisuuteen liittyviin ratkaisuihin edellyttää vastuiden ja päätösjäljen selkeää järjestämistä. Jos ei tiedetä, kuka muutoksen hyväksyi, millä perusteella riski arvioitiin ja vastaako dokumentaatio todellista tilannetta, in-house-malli tai ulkoistus menettää taloudellisen merkityksensä, koska esiin nousee vaatimustenmukaisuusvastuun ongelma. Tällöin aihe siirtyy jo koneen valmisteluun suunnittelusta vaatimustenmukaisuuden osoittamiseen ja CE-merkintään. Projektinhallinnan näkökulmasta tämä tarkoittaa yhtä asiaa: käyttöönotto on suunniteltava niin, että koneen mukana vastaanotetaan myös kaikki tekniset päätökset, varmennustulokset ja asiakirjat, joita tarvitaan myöhempään käyttöön, modernisointiin ja tarvittaessa perusteluksi vastaanotossa tai riitatilanteessa.