Ajatusjohtajat

Tekoälyvalmius alkaa luotettavasta tuotetiedosta

mm
Lisää Unite.AI suosikkilähteisiisi Google-palvelussa

Valmistajat investoivat voimakkaasti tekoälyyn, digitaalisen säikeen hankkeisiin, automaatioon ja yritysten modernisointiin parantaakseen tuottavuutta ja päätöksentekoa. Keskusteluissa keskitytään suurelta osin tekoälymalleihin, infrastruktuuriin ja järjestelmien integrointiin. Monet organisaatiot kuitenkin sivuuttavat näiden toimien perustavanlaatuisen edellytyksen: luottamuksen taustalla olevaan tuotetietoon ja liiketoimintasääntöihin, jotka ohjaavat operatiivisia päätöksiä.

Haasteena ei ole pelkästään järjestelmien yhdistäminen, vaan sen varmistaminen, että niiden välillä kulkevat tuotemäärittelyt, konfigurointilogiikka ja liiketoimintasäännöt pysyvät paikkansapitävinä. Tekoälyvalmius alkaa luottamuksesta yrityksen tuotetietoon. Digitaalisessa muutoksessa ei ole kyse vain järjestelmien yhdistämisestä, vaan niiden välillä liikkuvan tiedon merkityksen ja paikkansapitävyyden säilyttämisestä.

Kun yritykset uudistavat yritysjärjestelmiään ja yhdistävät tuotteen elinkaaren hallinnan (PLM), toiminnanohjauksen (ERP), konfigurointi-, hinnoittelu- ja tarjousprosessit (CPQ) sekä palvelualustat, konfigurointilogiikan epäjohdonmukaisuudet voivat huomaamatta heikentää jatkoprosessien tarkkuutta ja tekoälypohjaisten suositusten tehokkuutta. Ilman luotettavaa konfigurointilogiikkaa tekoäly nopeuttaa virheiden tekemistä sen sijaan, että se parantaisi päätöksentekoa.

Miksi tuotekonfigurointi on näkymätön perusta

Nykypäivän valmistajat turvautuvat yhä enemmän toisiinsa kytkeytyvään ekosysteemiin, joka kattaa PLM:n, ERP:n, CPQ:n, valmistuksen ja palvelut. Tuotekonfigurointi toimii yhdistävänä tekijänä, joka muuntaa suunnittelun tavoitteet valmistuksen, myynnin, hinnoittelun ja palveluiden vaatimuksiksi.

Kukin järjestelmä tarkastelee tuotetta eri näkökulmasta: PLM tarvitsee tekniset tiedot ja suunnittelutiedot, valmistuksen on tiedettävä, mitä voidaan valmistaa, ja CPQ tarvitsee myyntiä ja markkinoita koskevat säännöt. Konfigurointi yhdistää nämä näkökulmat. Kun taustalla oleva logiikka muuttuu tai muuttuu epäjohdonmukaiseksi, digitaalinen säie katkeaa riippumatta siitä, kuinka hyvin järjestelmät on integroitu.

Vanhat säännöt aiheuttavat näkymättömiä riskejä

Tuotekonfigurointimallit sisältävät usein vuosikymmenten aikana kertynyttä tietoa, jota on lisätty kerroksittain: sääntelyvaatimuksia, valmistuksen reunaehtoja, markkinakohtaisia poikkeuksia ja hinnoittelulogiikkaa. Mallien alkuperäiset kehittäjät ovat usein jo lähteneet yrityksestä, jolloin organisaatioille jää sääntöjä, joita kukaan ei enää täysin ymmärrä.

Yritysten modernisointihankkeissa, kuten SAP S/4HANA -siirtymissä, keskitytään tyypillisesti sovelluksiin, infrastruktuuriin ja räätälöityyn koodiin, kun taas konfigurointilogiikka jää toissijaiseksi. Näin syntyy huomaamatta riski: järjestelmät voidaan siirtää onnistuneesti, vaikka konfiguroinnin toiminta muuttuisi hienovaraisesti tavoilla, joita on vaikea havaita perinteisillä testausmenetelmillä.

S/4HANA-siirtymät havainnollistavat ongelmaa hyvin, sillä uusi konfigurointimoottori voi tulkita pitkään käytössä olleita sääntöjä eri tavalla, vaikka niiden syntaksi olisi sama. Oletusarvojen soveltamistavan, reunaehtojen arviointijärjestyksen ja sääntöjen välisten ristiriitojen ratkaisun erot voivat kaikki muuttaa sitä, mitkä yhdistelmät malli hyväksyy, vaikka itse sääntöihin ei kirjoitettaisi uudelleen riviäkään.

Kyse ei ole vain hämmennyksestä: virheellisestä konfigurointilogiikasta tulee liiketoimintaongelma. Virheitä syntyy kahdella tavalla, ja molemmat tulevat kalliiksi:

  • Konfigurointi sallii yrityksen myydä tuotteen, jota se ei todellisuudessa pysty valmistamaan. Seurauksena on uudelleentyötä, lupausten pettämistä ja asiakassuhteiden vahingoittumista.
  • Konfigurointi estää virheellisesti yritystä myymästä tuotetta, jonka se pystyisi valmistamaan. Seurauksena on liikevaihdon menetystä ja mahdollisesti kilpailuedun heikkenemistä.

Ensimmäinen virhetyyppi tulee lopulta ilmi tehtaalla. Toinen jää piiloon: tilauskirjaan ei kirjaudu myyntiä, jota konfiguraattori ei koskaan sallinut.

Varmennuksesta on tulossa strateginen kyvykkyys

Perinteisessä siirtojen validoinnissa turvaudutaan vahvasti manuaaliseen testaukseen ja pistokokeisiin, joilla ei voida realistisesti arvioida tuotteiden valtavaa mahdollisten yhdistelmien määrää. Konfiguroinnin varmentamisessa huomio siirretään siihen, siirtyikö data onnistuneesti, siihen, säilyikö liiketoiminnan tarkoitus ennallaan.

Olen nähnyt valmistajien palkkaavan tiimejä, joiden ainoana tehtävänä on varmistaa, että siirretty malli tuottaa edelleen samat kelvolliset konfiguraatiot ja hylkää edelleen samat virheelliset konfiguraatiot, koska muuta tapaa asian selvittämiseen ei ole. Työ on yksityiskohtaista, kallista ja aikaa vievää, ja siitä huolimatta siinä tarkastellaan vain osaa ongelmasta.

Mittakaava kannattaa hahmottaa tarkasti. Malli, jossa on 30 muuttujaa ja kullekin viisi vaihtoehtoa, sallii noin 10²¹ yhdistelmää — huomattavasti enemmän kuin maapallon hiekanjyvien arvioitu määrä — ja todelliset teollisuusmallit ovat huomattavasti suurempia. Kuinka moni tahansa ihminen ei voi käyttöliittymässä klikkailemalla käydä läpi kaikkia yhdistelmiä: laskutoimitus osoittaa sen mahdottomaksi.

Siksi muodollisilla menetelmillä on merkitystä. Yhdistelmien otannan sijaan konfigurointimalli voidaan muuntaa kanoniseen loogiseen muotoon: tiiviiksi matemaattiseksi esitykseksi kaikista yhdistelmistä, jotka sen säännöt sallivat. Tällä tavoin muunnettuja malleja voidaan verrata suoraan. Joko ne kuvaavat täsmälleen samaa kelvollisten tuotteiden joukkoa, tai vertailu osoittaa täsmällisesti, missä ne eroavat toisistaan, ja antaa konkreettisia esimerkkejä yhdistelmistä, jotka toinen malli hyväksyy ja toinen hylkää. Sama esitysmuoto muuttaa ajonaikaisen toiminnan etsinnästä suoraksi hauksi. Näin konfiguraattori voi näyttää vain kelvollisia vaihtoehtoja eikä koskaan johdattaa käyttäjää umpikujaan. Osoittautuu, että verifiointi ja oikeellisuuden varmistaminen ajonaikana ovat sama kyvykkyys kahdesta eri näkökulmasta tarkasteltuna.

Organisaatiot tarvitsevat yhä useammin tällaisen muodollisen vertailun ennen kuin ne ottavat tekoälyä tai automaatiota käyttöön tuotetta koskevien sääntöjensä pohjalta. Tavoitteena ei ole vain vähentää siirtymiseen liittyviä riskejä, vaan myös varmistaa toiminnan jatkuvuus tuotekehityksessä, valmistuksessa, myynnissä ja huollossa sekä mahdollistaa konfigurointimallien testaaminen, virheiden jäljittäminen ja oikeellisuuden varmistaminen ennen julkaisua eikä vasta sen jälkeen.

Tekoälyn paikka on deterministisen moottorin päällä, ei sen tilalla

Mikään tästä ei edellytä, että tekoäly korvaisi konfigurointimoottorin. Kestävämpi toimintamalli on päinvastainen: tekoäly toimii käyttäjän ja tarkkoihin sääntöihin perustuvan konfigurointimoottorin välissä ja tarjoaa luontevamman opastetun myynnin tai suositusten käyttökokemuksen, samalla kun taustalla olevat säännöt pysyvät deterministisinä. Kielimalli tulkitsee, mitä asiakas pyytää; moottori ratkaisee, mitä voidaan todella rakentaa. Tämä työnjako pitää prosessin sen osan, jonka oikeellisuus on voitava todistaa, poissa sellaisen järjestelmän käsistä, joka on luonteeltaan todennäköisyyksiin perustuva.

Luotettava tieto on tekoälyhankkeiden onnistumisen edellytys

Tekoäly voi tuottaa suosituksia vain niin luotettavasti kuin sen saama tuotetieto. Varmistamattomat konfigurointitiedot saavat tekoälyn levittämään virheitä koko yrityksen mittakaavassa ja heikentävät myynnin ohjausta, valmistuspäätöksiä ja asiakaslupausten pitävyyttä.

Valmistajien tulisi pitää tietojen oikeellisuuden varmistamista tekoälyn käyttöönoton edellytyksenä, aivan kuten ohjelmistojen testauksesta tuli sovelluskehityksen edellytys. Digitaalisen muutoksen jatkuessa kilpailuetua tuo yhä enemmän se, ettei tekoälyä oteta käyttöön ensimmäisenä, vaan että se otetaan käyttöön luotettavan tuotetiedon varassa.

Jesper Blak Møller on järjestelmäarkkitehtuurin johtaja sekä Configitn toinen perustaja. Configitin tuotejohtoryhmän jäsenenä hänellä on laaja asiantuntemus sääntöpohjaisista järjestelmistä, SAP-varianttikonfiguroinnista ja SAP-hinnoittelusta. Tietojenkäsittelytieteen tohtorin tutkinnon lisäksi hänen taustaansa kuuluu työskentely ratkaisuarkkitehtina Configitin asiantuntijapalveluosastolla, jossa hän toimitti SAP-järjestelmään integroituja ohjelmistoratkaisuja.