Useimmat teollisuuden IT-investoinnit eivät epäonnistu käyttöönotossa. Ne epäonnistuvat jo kuukausia aiemmin. Tyypillinen hetki on scoping-palaveri, jossa toimittaja esittelee 14 viikon käyttöönottoprojektin, eikä kukaan tuotannon, automaation tai integraatioiden asiantuntija pysäytä keskustelua kysymällä, mihin oletukset oikeasti perustuvat, kirjoittaa JBF Consultingin perustaja Brad Forester.
Kun projekti on puoli vuotta myöhemmin pahasti myöhässä, tuotanto kärsii, integraatiot eivät valmistu ja budjetti repeää. Silloin vahinko on jo tapahtunut.
Kyse ei ole yksittäisistä epäonnistumisista. Gartnerin tutkimuksen mukaan 76 prosenttia logistiikan ja teollisuuden teknologiatransformaatioista ei saavuta tärkeimpiä tavoitteitaan. McKinseyn mukaan jopa “onnistuneet” projektit menettävät keskimäärin viidenneksen odotetusta liiketoimintahyödystään käyttöönoton jälkeen.
Silti teollisuus jatkaa uusien järjestelmien hankkimista kiihtyvällä tahdilla. ERP-laajennukset, TMS- ja WMS-järjestelmät, MES-ratkaisut ja automaatioalustat lupaavat lisää tehokkuutta ja parempaa näkyvyyttä tuotantoon. Käytännössä moni projekti ajautuu kuitenkin samaan ansaan.
Ongelmat eivät yleensä synny toteutusvaiheessa. Ne syntyvät paljon aikaisemmin. Suunnittelussa, vaatimusmäärittelyssä ja siinä, miten projektin onnistuminen ylipäätään määritellään.
Ensimmäinen ongelma on odotusten ja todellisuuden välinen kuilu.
Toimittajan demo näyttää vakuuttavalta. Käyttöliittymä toimii hienosti ja integraatiot näyttävät helpoilta. Sopimus tehdään ominaisuuksista, joista suurta osaa ei koskaan käytetä. Samalla aliarvioidaan integraatioiden ja tuotantoympäristön todellinen monimutkaisuus.
Kun järjestelmä kohtaa oikean tehtaan, ongelmat alkavat. Tuotantoprosessit eivät sovi oletuskonfiguraatioihin. ERP- ja MES-liitynnät vaativat räätälöintiä. Koneiden rajapinnat eivät käyttäydy kuten powerpoint-esityksissä. Lopulta projektin määrittäväksi tekijäksi muodostuu ero demon ja todellisen tuotantoympäristön välillä.
Toinen ongelma on optimistinen suunnittelu.
Toimittajien tavoite on voittaa tarjouskilpailu. Se näkyy lähes väistämättä aikatauluissa. Teollisuudessa tunnetaan hyvin “14 viikon illuusio”: projekti myydään muutaman kuukauden käyttöönottona, vaikka todellisuudessa kyse on vuoden tai jopa puolentoista vuoden integraatiohankkeesta.
Kustannuksia ja työmäärää aliarvioidaan systemaattisesti. Samalla liiketoimintalaskelmat rakennetaan liian kevyesti. Moni business case näyttää hyvältä powerpointissa, mutta ei kestä todellisen tuotantoympäristön kompleksisuutta.
Kolmas ongelma liittyy suunnittelun ja tuotannon väliseen kommunikaatioon.
Vaikka teknologia olisi oikea ja projekti realistinen, moni hanke pysähtyy suunnitteluvaiheeseen. Tuotannon asiantuntijat eivät pysty kuvaamaan prosessejaan tavalla, jonka ohjelmistotoimittaja voisi muuttaa teknisiksi määrittelyiksi.
Tuloksena on loputon vaatimusmäärittelyjen uusintakierros. Samoja asioita käydään läpi yhä uudelleen ilman päätöksiä. Aikataulu venyy kuukausilla, mutta todellista edistystä ei synny.
Monessa projektissa järjestelmä saadaan lopulta teknisesti käyttöön. Ohjelmisto toimii, dashboardit pyörivät ja integraatiot ovat olemassa. Silti tuotanto ei saavuta tavoitteitaan, koska operaattorit eivät osaa käyttää järjestelmää todellisessa vuorotyössä eikä toimintaa ole koskaan oikeasti operationalisoitu.
Neljäs ongelma on orkestroinnin puute.
Tyypillinen teollisuuden IT-projekti koskee samaan aikaan tuotantoa, logistiikkaa, ERP- ja MES-järjestelmiä, automaatiota, asiakaspalvelua ja IT:tä. Mukana on ohjelmistotaloja, integraattoreita, automaatiotoimittajia ja laitetoimittajia.
Jos kukaan ei johda kokonaisuutta aidolla mandaatilla, projekti hajoaa organisaatiorajojen mukaan. Jokainen optimoi omaa osaansa. Yksi haluaa säästää kustannuksissa, toinen pitää kiinni aikataulusta ja kolmas yrittää minimoida integraatioriskejä.
Lopputulos on tuttu. Automaatio-ominaisuuksia karsitaan, integraatioita siirretään myöhempään vaiheeseen ja alkuperäinen ROI katoaa kompromissi kompromissilta.
Tämä keskustelu muuttuu vielä tärkeämmäksi agenttisen tekoälyn aikakaudella.
AI nopeuttaa ohjelmistokehitystä rajusti. Koodia voidaan tuottaa lähes reaaliajassa, ja monet toimittajat lupaavat jo kymmen- tai jopa satakertaisia kehitysnopeuksia. Mutta tehtaan ongelmat eivät katoa samalla vauhdilla.
Fyysinen maailma ei skaalaudu kuten ohjelmisto. ERP-riippuvuudet, tuotannon sekvensointi, OT-järjestelmät, koneiden rajapinnat ja turvallisuusvaatimukset pysyvät monimutkaisina, vaikka koodin kirjoittaminen automatisoituisi lähes kokonaan.
Siksi teollisuuden digitalisaation suurin pullonkaula ei ehkä enää ole ohjelmistokehitys. Se voi olla integraatioiden, prosessien ja organisaatioiden välinen koordinointi.
Ja juuri siksi moni projekti epäonnistuu jo ennen ensimmäistä koodiriviä.
Brad Forester on logistiikka- ja integraatiohankkeisiin erikoistuneen JBF Consultingin perustaja ja toimitusjohtaja. Hänellä on yli 25 vuoden kokemus kuljetusstrategioista, logistiikkateknologioista ja toimitusketjujen transformaatioista.
Tekoälypalvelinten kasvava tehotiheys tekee datakeskusten varmistamisesta aiempaa monimutkaisempaa. Ylimääräiset teholähteet voivat parantaa käyttövarmuutta, mutta samalla ne lisäävät lämpökuormaa ja häiritsevät ilmavirtoja. Siksi tehonsyöttö, varmennus ja jäähdytys on suunniteltava yhtenä kokonaisuutena.