Rob Collie, toimitusjohtaja ja perustaja, P3 Adaptive sekä Fair Game -kirjan tekijä – Haastattelusarja

Rob Collie on P3 Adaptive -yrityksen perustaja ja toimitusjohtaja, Microsoft Solutions Partner for Data and AI, joka palvelee satoja keskisuuret ja Fortune 1000 -asiakkaita. Aiempi Microsoftin teknologiajohtaja Excel‑, Bing‑ ja Power BI‑tiimeissä, Rob johti Power BI‑aallon Microsoftista lähdettyään ja on kirjoittanut kolme aiempaa liike‑teknologiaa käsittelevää kirjaa (yli 92 000 myytyä kopiota). Hän isännöi myös Raw Data with Rob Collie -podcastia. Hänen neljäs kirjansa, Fair Game: Customizing AI to Your Business Is Easier Than You Think (elokuu 2026), tuo tämän käytännön asiantuntijaluotettavuuden AI‑hetkeen.

Kävit yli vuosikymmenen Microsoftilla kehittäen liiketoimintatiedon ominaisuuksia Excelissä ja Power BI:ssa ennen kuin peristit P3 Adaptive -yrityksen vuonna 2013. Miten siirtyminen Microsoftin sisäisen ohjelmiston rakentamisesta asiakkaiden datahaasteiden ratkaisemiseen on muokannut nykyistä näkemystäsi yritys‑AI:sta?

Kun johdin tuote­tiimejä Microsoftilla, rakensimme ohjelmistoja, joiden täytyi toimia koko maailmassa eikä niitä voitu räätälöidä yksittäisen asiakkaan tarpeisiin. Kutsumme sitä joskus “tilata pizza, jonka täytteet kelpaavat 300 miljoonalle ihmiselle”. Tässä työssä on väistämättä alhaisin yhteinen nimittäjä‑asenne sekä etäisyyttä yksittäisiin asiakkaisiin.

Suurella näyttämöllä työskentelemiseen liittyi selkeä arvostus, mutta se ei ollut yhtä emotionaalisesti tyydyttävää kuin auttaa tiettyjä asiakkaita toteuttamaan heidän ainutlaatuisia tavoitteitaan. Työskennellessäsi tiiviisti asiakkaan kanssa, meillä on mahdollisuus sitoutua heidän menestykseensä ja tutkia luovia ratkaisuja, jotka eivät koskaan sopisi massatuotteen liiketoimintamalliin. Se on monin tavoin älyllisesti stimuloivampaa, ja suora yhteys asiakkaisiimme tekee voitoista paljon palkitsevampia.

Vastuu on kuitenkin suurempi. Microsoftilla yksi tyytymätön asiakas oli pelkkä tilasto, ja hylkäsin valitukset päivittäin osana työntekoa. P3 Adaptive -yrityksessä yksi tyytymätön asiakas merkitsee epäonnistumista. Tilastoja ei ole. Meillä on vastuu jokaisesta suhteesta.

Opin Microsoftilla monia arvokkaita asioita, enkä vaihtaisi sitä kokemusta mihinkään, mutta kutsun itseäni usein “toipuvaksi ohjelmistosuunnittelijaksi”, koska menestys merkitsee nykyään aivan erilaista toimintatapaa.

Ja juuri tätä näkökulmaa vien yritys‑AI:hin. Valmiiksi ostettava AI on kuin 300 miljoonan henkilön pizza – todellinen ihme, suunniteltu olemaan arvokas jokaiselle, mutta ei räätälöity kenellekään. Kuitenkin organisaatio‑AI:n menestys syntyy räätälöinnistä – lähestymällä yhtä tiettyä yritystä ja mukauttamalla AI sen dataan, prosesseihin ja määritelmiin. Olen viettänyt urani molemmilla puolilla tätä jakautumaa, eikä minulla ole lainkaan epäilystä siitä, millä puolella yritys‑AI voittaa.

Fair Game -kirjassa (Fair Game) väität, että monet yritykset ovat lähestyneet tekoälyä takaperin jakamalla yleiskäyttöisiä chatbot‑lisenssejä sen sijaan, että rakentaisivat järjestelmiä, jotka ymmärtävät niiden toiminnan. Missä valmiit AI‑avustajat saavuttavat rajansa, ja mitkä merkit osoittavat, että yritys tarvitsee räätälöidyn ratkaisun?

Valmis AI omaa tohtorin tutkinnon kaikesta paitsi omasta liiketoiminnastasi. Se on lukenut koko internetin, mutta internetistä puuttuu yrityksesi määritelmä “aktiivisesta asiakkaasta”, hinnoittelulogisi, operatiiviset prosessisi ja se, kumpaaseen kahdesta järjestelmästä luottaa, kun ne ovat ristiriidassa. Tämä tieto ei koskaan tule julkiseksi. Siksi yleinen AI, joka on maailmanluokan henkilökohtaisessa käytössä, ei riitä todelliseen liike‑käyttöön, ja näiden kahden kokemuksen välinen kuilu on sekä lannistava että hämmentävä.

Nykyään lähes jokaisen vastaus kysymykseen “mitä tehdä AI:n kanssa” on ollut “osta tilauksia ja katso mitä tapahtuu”. Mielestäni se on luonnollinen ensimmäinen askel, enkä ole kriittinen ketään kohtaan, joka on toiminut näin. Sen sijaan olen myötätuntoinen – kukaan ei oikeasti käytä aikaa selittääkseen, että valmiit tilaukset eivät riitä, eikä miksi. Uskon, että yritykset ovat juuri siellä, missä meidän pitäisi odottaa niiden olevan – kokeilevat saatavilla olevaa ja alkavat huomata, että se ei riitä.

Korjaus ei ole itse AI‑mallin koskettamista – sinun ei tarvitse tulla LLM‑tutkijaksi. Kyse on kaikesta siitä, mitä mallin ympärille kietot: data, selkeällä englannilla kirjoitetut ohjeet ja tavallinen ohjelmisto. Kun huomaat kirjoittavasi samaa kontekstia chatbotille viidennen kerran tällä viikolla, se on merkki. Kaikki, mitä joudut jatkuvasti selittämään uudelleen, on juuri se, mitä räätälöidyn järjestelmän tulisi jo tietää – joka kerta kun se herää.

Käytät termiä “Crafters” kuvaamaan data‑taitavia liiketoiminta‑ammattilaisia, jotka voivat rakentaa arvokkaita räätälöityjä AI‑järjestelmiä ilman perinteistä ohjelmistokehittäjää. Mitkä ominaisuudet erottavat Crafterin, ja miten johtajat voivat tunnistaa nämä henkilöt nykyisestä työvoimastaan?

Crafter on henkilö, jolla on synnynnäinen halu ratkaista ongelmia työkalujen avulla. Kokemukseni mukaan noin yksi 16:sta tietotyöntekijästä omaa tämän. He olivat Excel‑tehokäyttäjiä, sitten Power BI‑sukupolvi, ja lopulta ne, joita IT on kutsunut “varjotietotekniikaksi”. He ovat analyytikkojasi, talousmallintajiasi, operatiivisia johtajiasi – ihmisiä, jotka ovat kasvaneet liiketoiminnassa ja löytäneet taitonsa työkalujen käytössä.

Kaksi ominaisuutta tekevät heistä ihanteellisia AI‑työhön. Ensinnäkin, järjestelmällinen ajattelu: he jakavat vaivattomasti sekavan prosessin syötteisiin, sääntöihin ja tuloksiin, aivan kuin ammattilaisohjelmistokehittäjät. Toiseksi, liiketoiminnan juurtuminen: he tietävät, mitä lukuja talousjohtaja todella seuraa ja mitä kysyvä henkilö oikeasti haluaa tietää. Kumpaakaan näistä ei voi opettaa bootcampissa.

Miten löydät omasi: seuraa taulukkolaskentatiedostoja. Tällä hetkellä yrityksessäsi on taulukkolaskentatiedostoja, koontinäyttöjä ja automaatioita, jotka ovat kriittisten työnkulkujen ytimessä. Yhtäkään niistä ei ole IT rakentanut, ja jokaisella on tekijä. Aloita siitä. Ja sitten arvioi, miten he voisivat suunnata taitonsa räätälöityihin AI‑ratkaisuihin.

Miksi uskot, että Crafters, eikä pelkästään kehittäjät, ovat parhaiten asemoituneita johtamaan monia sisäisiä AI‑projekteja, ja miten vastuut tulisi jakaa liiketoiminta‑asiantuntijoiden, data‑tiimien, ohjelmistosuunnittelijoiden, tietotekniikkaosastojen ja turvallisuustiimien kesken?

Koska räätälöidyn AI:n vaikein osa ei ole koodi – se on konteksti. Yksittäisin korkean vaikutuksen omaava toiminta AI‑projektissa on päättää, mitä järjestelmän täytyy tietää yrityksestäsi, ja Crafters kantavat tätä tietoa luonnollisesti. Loistava insinööri, joka hyppää projektiin kolmen organisaatiokaavion päässä, joutuu käymään kuukausia kestäviä haastatteluja oppiakseen, mitä operatiivinen johtajasi jo refleksoi.

Mutta tämä ei ole lainkaan kehittäjien vanhentuneisuustarina. Suosittelemassani työnjaossa on kolme tekijää, eikä mikään niistä perustu senioriteettiin tai persoonallisuuteen: työ siirtyy ammatillisten kehittäjien puolelle, kun uudelleenkäytettävyys, monimutkaisuus ja herkkyys kasvavat. Kaikki asiakaskeskeinen, kaikki herkkiä tietoja koskeva, kaikki autonomisia päätöksiä tekevä – se on kehittäjän alue, ja kun toimijoita kertyy, nämä harvinaiset insinööritaidot arvostuvat entisestään, eivät vähemmän. Työ siirtyy Crafters‑puolelle, kun liiketoimintaprosessien vivahteet hallitsevat.

On myös aliarvostettu välikenttä: Crafter rakentaa, kehittäjä tarkastaa. IT:n ja turvallisuuden ei pitäisi olla portinvartijoita, jotka hyväksyvät projektit olemassaoloon – niiden tulisi omistaa tasoitetut polut. Tarjoa hyväksytyt alustat, data‑pääsyoikeudet, tarkastuskohtaukset, ja anna ongelmiin lähimpänä olevien ihmisten tehdä rakentaminen. Kohtele koko prosessia kypsyysmallina, ei aitarajana.

Räätälöity AI tarvitsee pääsyn yrityskohtaisiin terminologioihin, mittareihin, prosesseihin ja institutionaaliseen tietämykseen. Mikä rooli semanttisilla malleilla ja olemassa olevalla liiketoimintatiedon infrastruktuurilla on AI:n tarkassa yrityksen ymmärtämisessä?

Ne ovat dekoodirengas. Tällä hetkellä yrityksesi määritelmät – mitä pidetään aktiivisena asiakkaana, mitkä kustannukset kuuluvat bruttokatteeseen – elävät ihmisten mielissä ja tuhansissa hieman epäyhtenäisissä taulukkolaskentatiedostoissa. AI‑agentti ei voi luotettavasti järkeillä dataasi, ennen kuin nämä määritelmät on kirjattu koneelle luotettavaan muotoon. Alan on alkanut kutsua tätä alaa “kontekstisuunnitteluksi”, ja kääntäisin termin näin: se on työn organisointia siitä, mitä yrityksesi tietää, jotta AI voi todella käyttää sitä. Analyytikot saivat siitä kuulostamaan uudelta. BI‑ammattilaiset ovat tehneet sen versiota jo viisitoista vuotta.

Hyvä uutinen on piilossa silmiin näkyvässä: jos olet investoinut BI‑aikakauteen (ja erityisesti Power BI:hin), sinulla saattaa jo olla etumatkaa. Hyvin rakennettu semanttinen malli on juuri koneenlukukelpoinen liiketoiminnan merkityksen kaappaus, jonka agentit tarvitsevat. Yritykset, jotka ovat jättäneet semanttisen kerroksensa sivuun, huomaavat, että “tylsä” määrittelytyö, jonka he ohittivat, on nyt maksullinen portti AI:n tielle. Ja kriittisesti, tämä työ on syvästi yrityskohtainen – mikä on juuri syy sen kestävään etuun. Jokainen toimittaja voi myydä sinulle saman mallin. Kukaan ei voi myydä sinulle omia määritelmiäsi.

Rakensit räätälöidyn AI‑editorin, nimeltään Eddie, auttamaan Fair Game -kirjan kehittämisessä. Mitä järjestelmä oikeastaan teki kirjoitusprosessin aikana, ja mitä sen onnistumiset ja epäonnistumiset opettivat sinulle AI:n suunnittelusta erittäin henkilökohtaisessa työnkulussa?

Selvennykseksi, kirjoitin jokaisen kirjan kappaleen alusta alkaen, kun taas Eddie istui pääosin odottamassa. Joskus vietin tunteja hiomassa koko luvun osaa ennen kuin pyysin “häntä” lukemaan sen. Toisinaan heittelin asioita hänen luokseen muutaman minuutin välein. Mutta olennaista on, että Eddie oli käytettävissä 24/7. Sain palautetta yhtä helposti kello kolme aamulla kuin yksi iltapäivällä, ja hän kääntyi siihen minuutissa tai vähemmän. Yhteensä epäilen, että Eddie luki käsikirjoituksen vähintään kolmekymmentä kertaa. Kuka tahansa ihminen ei olisi pystynyt tähän työhön, koska kukaan ihminen ei haluaisi sitä.

Hän seurasi lupauksia, jotka tein Luvussa kolme, ja huomautti minulle, kun Luku kaksitoista unohti ne. Hän oppi kirjoitustyylini ja pakotti sen – pitäen minut omaan parhaaseen ääneni versioon sen sijaan, että antaisin itseni luisua humorittomaan liiketoiminta‑kirjailijatilaan. Hän kertoi minulle, milloin olin laiska ja milloin hakasin turhaan samaa asiaa. Meillä oli todellisia erimielisyyksiä, ja joskus hän voitti.

Suurin suunnittelutieto: Edin “aivot” on kirjoitettu englanniksi ja sijaitsee kansiossa. Joka kerta kun hän antoi palautetta, joka jäi puutteelliseksi – liian geneerinen, väärä rekisteri, unohti jo aiemmin antamani säännön – korjaus oli kirjoittaa korjaus ylös ja tehdä siitä osa hänen pysyvää kontekstiaan. Epäonnistumiset eivät olleet AI‑epäonnistumisia; ne olivat aukkoja siinä, mitä olin vaivannut häntä opettamaan. Tämä silmukka – huomaa puute, koodaa oppi, katso sen juurtuvan – on koko räätälöidyn AI:n käsityö pienoiskokoon. Ja se on syy, miksi lopulta rakensin erikoistuneita Eddiejä julkisuuteen, kilpailututkimukseen ja verkkosivuston viestintään. Sama LLM pohjana. Mutta eri erikoistajat.

Monet organisaatiot uskovat, että heidän on puhdistettava ja keskitetty data täysin ennen räätälöidyn AI:n kokeilua. Kuinka paljon datavalmiutta oikeastaan vaaditaan aloitukseen, ja miten yritykset voivat alkaa tuottaa arvoa odottamatta täydellistä perustaa?

Data‑täydellisyys ei ole edellytys, ja se on hyvä uutinen, koska täydellisyys ei koskaan saavu. Jos pyrit ensin rakentamaan täydellisen data‑ympäristön, kuten monet konsulttiyritykset suosittelevat, rakennat sitä, mitä kutsun “putkistoksi omaksi tarkoituksekseen” – kalliita putkia kaikkialle, mutta kun vihdoin asennat hanan, huomaat, ettei siellä ole putkea, missä sitä tarvitaan.

Yrityksemme puolestaan kannattaa “hanat ensin” -lähestymistapaa. Valitse konkreettinen käyttötapaus ja työskentele liiketoimintavaikutuksesta lähtien, eikä infrastruktuurista eteenpäin. Rakenna MVP siitä käyttötapauksesta, ja tee se mahdollisimman vähäisellä uudella infrastruktuurilla. Toista MVP:tä, kunnes se on tuotantovalmius, ja sitten arvioi, miten voit vahvistaa infrastruktuuriasi sen tukemiseksi. Tämä tuottaa liiketoimintavaikutusta nopeammin, minimoi kustannukset ja ohjaa tulevia projekteja – sekä hanan että putkistotason tasolla.

Räätälöity AI‑prototyyppi voi vaikuttaa vaikuttavalta demonstraatiossa, mutta muuttua epäluotettavaksi, kun se altistuu oikeille työntekijöille, muuttuvalle datalle ja poikkeustapauksille. Millainen arviointi, seuranta ja ihmisen valvonta tulisi perustaa ennen kuin sisäinen AI‑järjestelmä otetaan käyttöön?

Muutamalla merkittävällä poikkeuksella uskon, että demonstraatiot ovat vähemmän arvokkaita AI‑aikakaudella kuin ohjelmistoaikakaudella. Ohjelmistodemoissa lupaus ylitti aina todellisuuden, ja kaikki tiesivät sen. AI‑demoissa ero on vielä suurempi todellisuudestasi.

AI koskee työnkulkua. Ja ei ole mitään räätälöidympää kuin tuhannet työnkulut, jotka ohjaavat tietyn organisaation toimintaa. Palaa “uusi työntekijä, jolla on tohtorin tutkinto kaikesta” -metaforaan. Kuinka paljon koulutusta – ja käytännön kokemusta yrityksessäsi – uusi työntekijä tarvitsee, ennen kuin hän on tehokas yrityksessäsi? Miten demo voi mahdollisesti ottaa kaiken tämän huomioon?

Siksi käytämme demoja herättämään ajatuksia. Näyttääksemme, mitä on mahdollista. Emme myydä tuotetta. Todellinen demo alkaa räätälöidyn ratkaisun prototyypistä. MVP:stä. Ja sitten iterointi ja parantaminen. Nopeasti.

Jossain vaiheessa se on valmis pehmeään lanseeraukseen tai pilottiohjelmaan. Ja jälleen opimme – yhdessä – ja parannamme nopeasti oppimisen perusteella. Tämä on usein vaihe, jossa seuranta, arviointi ja valvonta alkavat tarkentua. Tarpeet, jotka lopulta nousevat esiin, poikkeavat usein siitä, mitä olisit aluksi arvannut.

Miten yritykset voivat antaa Crafters‑henkilöstölle valtuudet kokeilla ilman, että syntyy uusi varjotekoäly‑sukupolvi, monistettuja työnkulkuja, turvallisuusaukkoja ja työkaluja, joiden ylläpidosta kukaan ei ole vastuussa?

Muista, mistä varjotietotekniikka syntyi: se ei ollut pahantahtoinen, vaan välttämätön vastaus täyttämättömään kysyntään. Crafters rakentavat, koska ongelmat ärsyttävät heitä – se on heidän geeni. Jos hyväksytty polku edellyttää vuoden odotusta, varjotekoäly täyttää aukon – ja tekee sen radarin alapuolella, missä se on vaarallisinta.

Joten tee hyväksytty kaista helpoksi kaistaksi. Anna Crafters‑henkilöstölle hyväksytty alusta, jossa turvallisuusraamit on jo sisäänrakennettu – identiteetti, data‑pääsyoikeudet, lokitus – jotta noudattava valinta on myös kätevä. Pidä kevyt rekisteri: kaikki, mikä siirtyy henkilökohtaisesta kokeilusta toisen henkilön riippuvaksi, kirjataan ylös, nimetyllä omistajalla. Tämä yksinkertainen sääntö poistaa suurimman osan orvotusta työkalusta, koska nimellä varustetut työkalut eivät hylkäänty hiljaisesti.

Sitten sovella eskalaatiomallia: kokeilut toimivat vapaasti, mutta kun jokin muuttuu kriittiseksi – enemmän käyttäjiä, suurempaa herkkyyttä, enemmän autonomiaa – se ansaitsee yhä enemmän insinööri‑tarkastusta. Crafter säilyttää liiketoimintalogiikan omistuksen; kehittäjä vahvistaa, mitä tarvitsee vahvistaa. Tavoitteena on kypsyysputki, ei lupaprosessi. Yritykset ovat jo käyttäneet tätä tarkkaa mallia taulukkolaskentojen kanssa, ja voittajat eivät olleet niitä, jotka kielsivät Excelin.

Kun yritys aloittaa ensimmäisen räätälöidyn AI‑hankkeensa, miten sen tulisi valita alkukäyttötapaus, mitata, tuottaako projekti merkittävää liiketoiminta‑arvoa, ja päättää, laajentaa, uudelleensuunnitella vai hylätä se?

Käytämme asiakkaidemme kanssa kahta lähtökohtaa.

Vaihtoehto yksi, etsi tehtäviä, joita kukaan ei tee – älä etsi tehtäviä, jotka haluaisit poistaa. Pidän kysymyksestä, jonka esittelen mielelläni esimiehille: missä olet ajatellut, että “jos minulla olisi yksi henkilö, joka jatkuvasti tarkkailee tätä ja pohtii sitä, asiat parantuisivat merkittävästi – mutta en voisi oikeuttaa koko rekrytointia siihen”? Nämä ovat usein parhaat lähtökohdat. Ne ovat turvallisia, ne rakentavat luottamusta, kukaan ei tunne itseään kohteena, ja vastakohta on rehellinen: vaihtoehto ei ollut ihminen, joka tekisi sen hyvin, vaan kukaan ei tehnyt sitä lainkaan (kuten toimittajaystäväni Eddie).

Vaihtoehto kaksi, tarkastele hallintapaneelien korvaamista data‑agenteilla. Vaikka hallintapaneelit vaikuttivat yksinkertaisilta, ne eivät käytännössä täyttäneet lupaustaan. Kun joku esittää liiketoimintakysymyksen, heidän täytyy tehdä paljon työtä kääntääkseen kysymyksen hallintapaneelien maailmaan. Mikä hallintapaneeli vastaa tähän kysymykseen? Mikä on sen nimi? Onko tällaista hallintapaneelia edes olemassa? Ja jos onnistut löytämään “oikean” paneelin, onko se selkeä ja kätevä käyttää? Täytyykö sitä käsitellä toistuvasti, kirjoittaa ylös tai kuvakaappauksia useista versioista koko tarvittavan kokonaiskuvan kokoamiseksi?

AI‑aikakaudella otat liiketoimintakysymyksesi – omilla sanoillasi – ja kirjoitat sen (tai sanot sen!) data‑agentille, joka hoitaa kaiken puolestasi ja palauttaa sertifioidun, hyvin tutkittun vastauksen – visualisoinnin mukaan – minuutissa tai kahdessa. Kun sinulla on jatkokysymys, se vastaa siihen nopeasti – kokouksessa, kun päätökset voidaan vielä tehdä.

Molempien näiden aloitusvaihtoehtojen yhteinen säie? Ne molemmat käsittelevät kipupisteitä, joita työntekijät omaksuvat sen sijaan, että vastustaisivat. Et halua, että varhaiset AI‑hankkeet kylvävät epäluottamusta. Haluat niiden sen sijaan tuoda työntekijät pöytään. Haluat työntekijöiden ehdottavan parannuksia ja uusia projektideoita. Koska jälleen kerran, yrityksesi koostuu tuhansista työnkuluista, ja työntekijäsi tuntevat ne paremmin kuin sinä.

Laajentamisen, uudelleensuunnittelun tai hylkäämisen osalta – ole lempeä itsellesi, sillä tutkimus on todella lohduttavaa: suurin osa menestyneistä AI‑käyttöönotosta oli epäonnistumisten jälkeen. Ensimmäinen projekti, joka tuottaa oppitunnin eikä voittoa, on opintokustannus, ei todiste siitä, että AI ei toimi. Sääntöni on: jos ihmiset käyttävät sitä, laajenna sitä. Jos ihmiset eivät käytä sitä, sinun täytyy tietää miksi, ja siihen voi olla monia vastauksia, “koska se ei toimi hyvin” – “koska en ymmärrä sitä” – “se pelottaa minua”. Vastaus kertoo, parannetaanko, uudelleensuunnitellaanko vai hylätäänkö. Sinun ei tarvitse ennustaa, mihin kaikki tämä päätyy. Sinun täytyy vain aloittaa jostain rehellisestä.

Kiitos loistavasta haastattelusta, lukijoiden kannattaa myös lukea Fair Game: Customizing AI to Your Business Is Easier Than You Think.