Onnistuneet teollisen internetin kehitysprojektit nojaavat pyhään kolminaisuuteen: palvelumuotoilun, teknologian ja analytiikan tasapainoon. Näistä haastavin on analytiikka, jota edes ammattiprojektipäällikön on mahdotonta aikapaineistaa ilman mieletöntä riskiä tulosten laadun suhteen.
Ainakaan itse en ole vielä keksinyt Graalin maljaa, jolla analytiikan kehitys aikapaineistettaisiin siten, että tyhjältä pöydältä voitaisiin luvata neljässä kuukaudessa vikaantumista ennustava algoritmi valmiina kaupallistamista varten. Algoritmit luovat palvelun älyn eivätkä ne synny pakottamalla. Ei vaikka tiimissäsi olisi 5 tekniikan tohtoria.
“Algoritmit luovat palvelun älyn eivätkä ne synny pakottamalla.”
Ohessa kokemuksen kautta kertyneitä oppeja, jotka auttavat projektipäällikköä oikeaan suuntaan analytiikan kehittämisen fasilitoimisessa.
Projektissa on aina varmistettava, että jokaisella suunitellulla algoritmilla on merkityksensä. Yksinkertainen esimerkki: algoritmin merkitys voisi olla vaikkapa tiedottaa teollisuushyödykkeen omistajaa silloin, kun laitteessa alkaa ilmetä normaalin toiminnan sormenjäljestä poikkeavaa epätavallista värinää. Reagointi ennen vikaantumista on loppuasiakkalle tärkeää, jotta prosessin pysähtyminen ja pahimmassa tapauksessa tuotannon keskeytyminen voidaan estää. Kokonaiskuvaa voi helposti jäsentää vaikka kuvan kaltaisella pelikaani turbiiniin -analogialla, jolla IoT-palvelun kehittäjä voi kätevästi selvittää omien asiakkaidensa painajaisia.
IoT-sovellusarkkitehtuuriin upotettua algoritmikandidaattia voidaan koeponnistaa esimerkiksi IoT-palvelun kehittävän yrityksen omissa testilaboratorioissa. Näissä laboratorioissa voidaan suorittaa kenttäolosuhteita simuloivia kuormituksia ja tehdä kiihdytettyjä testejä. Esimerkiksi GE on tehnyt lentokoneen suihkuturbiinimoottorin kuormitustestejä tykittämällä suihkuturbiiniin jokaisesta maailmankolkasta kerättyjä hiekkanäytteitä. Näin voidaan simuloida, että suihkuturbiini sietää altistumista erilaiselle hiekkamateriaalille tositoimissa eli ollessaan kiinni ympäri maailmaa lentävän matkustajakoneen voimanlähteenä.
Jokaiseen IoT-palvelukehitysprojektiin ei ole budjettia rakentaa GE:n kaltaista laboratoriota. Hyvä vaihtoehto on varmistaa, että jo projektin kehitystaipaleen alkuvaiheessa pilottiasiakkaalta saadaan raakadataa suoraan kentältä – ja jo pidemmän aikaa käytössä olleesta teollisuushyödykkeestä, jolla on tunnetusti ongelmallinen historia. Tällainen hyödyke voi olla vaikkapa se pilottiasiakkaan murheenkryyninä tunnettu, mutta valmistusprosessille kriittinen kivenmurskain.
Kokonaisuutta tulee fasilitoida suuntaan, jossa pilotoinnin kohteena keskitytään ongelmapotilaisiin. Jos ongelmapotilaiden sijaan keskitytään mallioppilaisiin – niihin kivenmurskaimiin jotka ovat vuosikausia toimineet ilman ongelmia kuin sveitsiläinen kello – projektille on luvassa hiljainen ja tylsä pilotointivaihe. Mikä pahinta, tällöin algoritmikandidaattia ei saada riittävästi validoitua kentällä. Jos pilotoinnin aikana epätavallista värinää ei tapahdu, ei algoritmikaan herää. Rajatun ajanjakson pilotointi mallioppilaan kaltaisesti työskentelevällä teollisuushyödykkeellä on järkyttävää riskinottoa – aivan kuin virvelin heittoa tyhjässä uima-altaassa saaliin toivossa.
“Rajatun ajanjakson pilotointi mallioppilaan kaltaisesti työskentelevällä teollisuushyödykkeellä on kuin virvelin heittoa tyhjässä uima-altaassa saaliin toivossa.”
On projektin edun mukaista jopa toivoa, että pelikaani lentää kunnolla turbiiniin pilotointijakson aikana. Hyvässä lykyssä pilotointijakso vahvistaa, että jatkossa IoT-palvelun sisään leivottu algoritmi herää salamannopeasti jo ennen oikuttelua ja varoittaa loppuasiakasta ennen ongelmien syntymistä, minkä jälkeen käyttäjä voi toimillaan estää ongelman eskaloitumisen.
Hankejohdolta tämänkaltaiseen toimintamalliin hakeutuminen etukenossa jo kehitysprojektin alussa johtaa siihen, että lopulta kaupallistettavan IoT-palvelun analytiikka on kentällä validoitua. Se, jos jokin luo uskoa ja ehkä julkisia referenssejäkin myynnin vauhdittamiseksi.
Jos IoT-palvelun on tarkoitus palvella laajempaakin joukkoa eri ikäisiä tuoteperheitä, on syytä ymmärtää vaihtelua fyysisen tuotteen lähettämän raakadatan formaatissa. Se auttaa virittämään IoT-sovellusarkkitehtuurin algoritmikerroksen oikeaan kellotaajuuteen.
Muuttujia voi olla lukuisia. Tässä esimerkkejä:
Kaikki ylläoleva tarkoittaa, että IoT-sovellusarkkitehtuurin algoritmikerrokseen on tyypillisesti lisättävä ylimääräinen logiikkakerros, jonka ansiosta algoritmi skaalautuu näppärästi eri-ikäisille, eri ohjelmiston sisältäville ja erilaista dataa lähettäville tuotteille.
Analytiikan kehitystyössä ei parane ajatella, että “viiden kuukauden kuluttua on oltava valmis algoritmi, joka kertoo kun lentokoneen moottori tarvitsee huoltaa”. Tällöin syntyy riski, että mutkia oiotaan ja lanseerataan jotain mitä, ei ole huolellisesti kentällä testattu. Niin ikään koko analytiikan kehitystä ei kannata pitää yhden kortin varassa. “Meidän sisäinen tuotekehitys varmasti keksii parissa viikossa takuukorjausdataa tutkimalla matemaattisen tavan ennustaa vikaantuminen hyvissä ajoin” on huono ajatus.
Jotta palveluun saadaan riittävästi älyä, tarvitaan monia lähtöjä: Hyödynnetään yrityksen sisälle kertynyttä hiljaista tietoa. Hankkiudutaan vaikkapa yhteistyöhön yliopiston kanssa ja tilataan aiheesta diplomityö, johon sisältyy kenttäsimulaatiota yliopiston koelaboratoriossa. Otetaan mukaan Big Data -yrityskin, joka voi näyttää voimansa koneoppimisen saralla, kun isosta laitedatamäärästä löydetään säännönmukaisia muodostelmia (keskiarvo, maksimi, minimi, poikkeama, muutosnopeus etc.) jotka kertovat lähestyvästä vikaantumisesta.
“Jotta palveluun saadaan riittävästi älyä, tarvitaan monia lähtöjä”
Jotta algoritmeja saadaan kaupallistettua kehitysprojektin siivellä, riittävä minimitaso per palvelu, IoT-palveluita kaupallistavilla yrityksillä pitäisi olla jatkuvia algoritmityöpolkuja menossa myös kehitysprojektien ulkopuolella. Näissä työpoluissa luodaan pohjia, joiden siivittämänä firman tulevat IoT-projektit pääsevät vaivatta lentoon.
IoT-sovellusarkkitehtuuria voisi yksinkertaistettuna ajatella polttomoottorina, jonka polttoaineena raakadata toimii. Konnektorikerros toimii polttoainepumppuna, joka pitää huolen siitä, että moottori saa oikean määrän ja oikeanrakenteista polttoainetta optimaalisen palamisilmiön varmistamiseksi. Optimaalisella käynnillä varmistetaan paras mahdollinen hyötysuhde, jossa algoritmi kanavoi herätteitä loppukäyttäjälle (älypuhelimen herätteet, email-notifikaatiot, portaalin liikennevalot jne.) polttamansa polttoaineen perusteella.
IoT-palvelun konnektorikerros säätelee polttoaineen rikkautta.
On aina hyvä ymmärtää, millaista polttoainetta algoritmikerros odottaa ja millaisella volyymilla. Aivan kuten auton moottorille on tärkeätä vastaanottaa oikeanlaatuista polttoainetta, myös IoT-sovelluksen algoritmikerrokselle on tärkeää, ettei sille syötetä fyysiseltä tuotteelta läpi konnektorin bensaa silloin kun se on alunperin viritetty prosessoimaan dieseliä. Siinä sivussa kannattaa testata myös itse konnektorin suorituskykyä ja varmistaa, että se selviää tehtävästään pitkiä aikoja luotettavasti. Mitä enemmän polttoainetta pumpataan, sitä enemmän se aiheuttaa stressiä polttoainepumpulle. Kannattaa siis pitää huolta, mitä eväitä IoT-palvelun algoritmeille pumpataan ja millä volyymilla.
“Aivan kuin auton moottorille, myös IoT-sovelluksen algoritmikerrokselle on tärkeää, ettei sille syötetä fyysiseltä tuotteelta läpi konnektorin bensaa silloin kun se on alunperin viritetty prosessoimaan dieseliä.”
Algoritmeihin liittyvä työ on palkitsevaa. Yksi omia teollisen internetin projektipäällikön työni huippuhetkiä oli, kun saimme IoT-sovellusarkkitehtuurin viritettyä havainnoimaan erästä tietyn teollisuushyödykkeen kuormittamisesta riippuvaa fyysisen maailman ilmiötä. Tuo ilmiö oli harvakseltaan toistuva ja kerrallaan vain hetken kestävä. Loppuasiakkaalle siitä aiheutuvan vikaantumisriskin välttäminen oli erittäin merkittävää.
Haluatko tietää lisää Bisnesteknologiamallista ja sen soveltamisesta käytännössä? Ota yhteyttä.