Dataoperaatiot murroksessa: mikä on seuraava askel?

🇬🇧 Tämä haastattelu on saatavilla myös englanniksi (käännös). Löydät sen oikeassa yläkulmassa olevasta kielipainikkeesta.

Haastattelussa Mikko Sulonen

Mikko Sulonen, Recordlyn CTO ja data-arkkitehti, on työskennellyt vuosien ajan käytännönläheisesti modernien dataplatformien ja laajojen muutoshankkeiden parissa eri toimialoilla. Tässä haastattelussa hän avaa, mitä agenttinen datakehitys tarkoittaa käytännössä ja miten se tulee muuttamaan tapaa, jolla datatiimit työskentelevät ja tekevät yhteistyötä liiketoimintajohdon kanssa.

Mitä ongelmia agenttinen datakehitys ratkaisee organisaatioissa tällä hetkellä?

– Se ratkaisee ennen kaikkea datatekemisen skaalaamista monesta eri näkökulmasta. Yhtäältä se tuo käytännössä lisäkäsiä datatiimeille, mutta ennen kaikkea se mahdollistaa fokuksen siirtämisen arvokkaampiin asioihin.

Esimerkiksi support- ja tikettityyppisiä kysymyksiä voidaan tietyssä määrin siirtää agenteille: “Mistä tämä luku löytyy?”, “Miten tämä on laskettu?” ja tiettyyn pisteeseen asti jopa “Tämä luku on väärin” -tyyppistä selvittelyä ja joissain tapauksissa korjausehdotuksia. Kun tällainen selvitystyö vähenee, ihmiset voivat keskittyä arvokkaampiin ja uusiin ongelmiin.

Jos selittäisit agenttinen datakehitys ei-tekniselle liiketoimintajohtajalle yhdellä lauseella, miten kuvailisit sitä?

– Datakehitys tarkoittaa oikean tiedon saamista oikeaan paikkaan, oikeaan aikaan ja oikeassa muodossa. Datakehitystä ei tee aina ihminen, vaan soveltuvissa tehtävissä sen voi tehdä agentti, eli kone. Ei ole kyse ihmisten korvaamisesta, vaan siitä, että osassa tehtäviä tekijä voi olla agentti eikä ihminen.

Kun keskustelet liiketoimintajohdon kanssa, miten he tyypillisesti kuvaavat turhautumistaan data- ja analytiikkatiimeihin?

– Kolme asiaa nousee usein esiin: nopeus, luottamus ja avoimuus.

• Nopeus: reagointi- ja toimitusnopeus. Kun pyydetään jotain tiettyä dataa, milloin se oikeasti saadaan toimitettua?
  
  
• Luottamus: onko data oikein, pysyykö se oikein, toimiko se tänään ja toimiiko se huomenna? Entä kuunvaihteessa, kvartaalivaihteessa, vuodenvaihteessa? Monessa organisaatiossa on edelleen vahvaa mututuntumaa ja epäluottamusta lukuihin.
  
  
• Avoimuus (tai näkyvyys): datatekeminen on liian usein “musta laatikko” erillisessä datatiimissä. Pyydetään jotain, sitten ei kuulu mitään viikkoihin ja lopulta jotain tulee ulos, pahimmillaan tämä tapahtuu tikettien kautta. Johto ja liiketoiminta haluaisivat nähdä, mitä tapahtuu ja miksi.

Lisäksi tarvitaan puolin ja toisin keskustelua siitä, miten liiketoiminnan tarve kääntyy dataksi: “Tarvitset vastauksen tähän; miten se näkyy meillä datassa ja mistä se saadaan sinulle?”

Kuvassa Mikko Sulonen, Recordlyn CTO ja data-arkkitehti

Miten agenttinen datakehitys eroaa siitä, että tekoälyä käytetään vain datatyön nopeuttamiseen tai halventamiseen?

– “Pelkkä nopeuttaminen tai halventaminen” on vähän kapea tapa katsoa tätä. Toki niitäkin voi mitata, mutta olennaisempi on se, että abstraktiotaso nousee.

Vastaava muutos on nähty aiemminkin: esimerkiksi pilvidatavarastojen myötä osa aiemmin käsityönä tehdystä ylläpidosta abstraktoitui pois. Se ei tehnyt data-ammattilaisista tarpeettomia, vaan mahdollisti keskittymisen arvokkaampiin ja vaikeammin määriteltäviin ongelmiin.

Agenttien kanssa olemme saman äärellä: pois automatisoitavat tehtävät ovat nyt vain “pykälää korkeammalla”. Esimerkiksi kysymys “Mistä tämä luku tulee?” voi viedä ihmiseltä puoli päivää selvittää, mutta agentti voi hoitaa sen tehokkaasti ja myös kertoa vastauksen käyttäjälle. Jos keskittyy vain nopeuteen ja kustannuksiin, paljon hyötyjä jää lunastamatta. Ihmiset pääsevät keskittymään siihen työhön, jossa heidän kannattaa olla.

Ja työ ei lopu: en ole vielä nähnyt yhtään valmista dataplatformia. Kun perustarpeet saadaan kuntoon, syntyy lisää kysymyksiä, kuten ennustaminen, kilpailija-analyysi, tai “mitä jos” -skenaariot.

Millaista vaikutusta olet jo nähnyt käytännössä, kun agenttisia työnkulkuja otetaan käyttöön?

– Konkreettinen esimerkki on migraatiotilanne, jossa on vanhalla tavalla tuotettuja tauluja, näkymiä ja laskentoja sekä uudella tavalla tehtyjä versioita. Raaka vertailu ei tuota mitään arvoa, vaan arvo syntyy vasta siitä, että löydetään erot ja korjataan ne niin, että lopputulos on identtinen.

Agentille “raaka vertailu” on triviaalia: sille annetaan kaava, miten vertailu tehdään, mistä vanha ja uusi löytyvät, miten tulokset tallennetaan ja mitä raportoidaan. Satojen tai tuhansien taulujen vertailu on agentille luontevaa, kun taas ihmiselle se olisi työlästä käsin tehtyä skriptityötä.

Seuraava askel, miksi erot syntyvät ja miten ne kannattaa korjata, vaatii edelleen ihmistä. Agentti voi auttaa, mutta ihminen tekee päätöksiä: onko ero ok, mistä se johtuu, onko siellä yleistettäviä korjauskaavoja. Tässä päästään keskittymään siihen arvoa tuottavaan tavoitteeseen, eli siihen, että migraation lopputulos oikeasti täsmää.

Mitkä tehtävät tyypillisesti vähenevät tai katoavat, ja mitkä asiat nousevat niiden tilalle tärkeämmiksi?

– En ajattele, että työ katoaa. Sen sijaan fokus siirtyy! Kun agentit voivat hoitaa paljon päivittäistä pientä tekemistä ja selvittelyä, ihmisille vapautuu aikaa suunnitteluun, arviointiin ja pidemmän aikavälin tekemiseen.

Tämä on taas sitä abstraktiotason nostoa: kun kaikkea ei tarvitse itse käsin sammuttaa tulipaloa, katse nousee varpaista pidemmälle.

Onko joitakin rooleja, joiden sisältö muuttuu merkittävästi tämän kehityksen myötä?

– Sellainen rooli, joka on vain ja ainoastaan teknologiaan orientoitunut – oli se sitten data engineer, BI-analyytikko tai muu – voi menettää suhteellista painoarvoa.

Aina tarvitaan huippuguruja, se ei poistu. Mutta korostuu entistä enemmän kyky nähdä siilojen yli, kommunikoida ja hahmottaa kokonaisuus: mistä tässä oikeasti on kyse ja mitä pitäisi tehdä. Pieni tekninen detalji ei katoa, mutta sen suhteellinen merkitys voi hälventyä.

Mitkä taidot tai ajattelutavat ovat kaikkein tärkeimpiä tiimeille, jotka työskentelevät tällaisessa toimintamallissa?

– Liiketoimintaymmärrys ja ymmärrys organisaatiosta, kulttuuri mukaan lukien. Kielimallit “ymmärtävät” SQL:ää ja teknisiä määrityksiä, mutta ne eivät ymmärrä organisaatiokulttuuria, päätöksentekoprosesseja tai liiketoimintaongelmia samalla tavalla.

Yksinkertaistaen: siellä missä on paljon ihmisiä, siellä on paljon tilaa ihmisille. Siellä missä on koodia ja koneita, niin siellä on tilaa agenteille.

Lisäksi ajattelutapana on tärkeää, ettei tätä nähdä lyhytnäköisesti “töiden viemisenä”. Työ ei tekemällä lopu. Oikea näkökulma on, että tämän avulla voidaan nostaa tiimin ambitiotasoa: mitä kaikkea voidaan tehdä ja millä aikataululla.

Mistä agenttisen datakehityksen kanssa kannattaa lähteä liikkeelle ja missä organisaatioiden on syytä olla varovaisia?

– Hyvä lähtökohta on aloittaa asioista, jotka voi tehdä pelkillä lukuoikeuksilla. Silloin ei rikota mitään, ja silti saadaan paljon aikaiseksi.

Esimerkiksi kustannusoptimoinnissa voi päästä pitkälle jo lukuoikeuksilla: mitkä kyselyt maksavat eniten, kuinka usein niitä ajetaan ja olisiko niille halvempi vaihtoehto. Myös datakatalogin rakentaminen onnistuu pitkälti lukuoikeuksilla.

Varovaisuutta tarvitaan siinä vaiheessa, kun agenttien annetaan suorittaa ja kirjoittaa: silloin korostuvat oikeuksien hallinta, testiympäristöt ja se, kuka tekee mitä, missä ja millä oikeuksilla.

Jos voisit antaa yhden neuvon liiketoimintajohtajalle: mihin hänen kannattaisi alkaa keskittyä eri tavalla vuonna 2026?

– Korostaisin entistä enemmän avoimuutta, integraatioita ja rajapintoja. Agenttinen tekeminen ja kielimallit kehittyvät todella nopeasti. Jos data ja järjestelmät ovat mustia laatikoita tai esimerkiksi tieto on vain käyttöliittymien takana tavalla, jota agentit eivät pysty lukemaan, mahdollisuudet jäävät nopeasti hyödyntämättä.

Nämä kehityssuunnat kasvattavat painoarvoa sille, että ratkaisut ovat avoimia, integroitavia ja yleisten toimintatapojen mukaisia.

Kun katsotaan muutama vuosi eteenpäin: miltä dataoperaatiot näyttävät organisaatioissa, jotka omaksuvat tämän lähestymistavan varhain?

– Se, mitä “Self Service BI” aikanaan lupasi, alkaa näyttää vaatimattomalta. Sen lupaus oli pitkälti raporttien pyörittelyä. Tulevaisuudessa, kun data ja prosessit ovat aidosti käden ulottuvilla (oikeudet huomioiden), voidaan pyytää sitä mitä tarvitaan siinä hetkessä, kun sitä tarvitaan.

En usko, että arki pyörii samalla tavalla dashboardeissa viiden vuoden päästä, ehkä ei edes parin vuoden päästä. Data tulee saataville juuri siinä kohdassa prosessia, kun sitä tarvitaan, ihmiselle tai prosessille. Ehkä nyt aletaan oikeasti lunastaa niitä lupauksia, joita aiemmat lähestymistavat tavoittelivat, mutta jotka vaativat valtavasti käsityötä.