Käsitemalli ei ole dokumentti vaan työväline, myös AI-agentille

Tämä on kahden kirjoituksen sarjan ensimmäinen osa, ja se kuvaa, miten käsitemalli rakennetaan niin, että se ohjaa toteutusta. Toinen osa käsittelee master datan periaatteita ja pääsynhallintaa. 

Moni organisaatio tunnistaa tilanteen: sama asiakas löytyy kolmesta järjestelmästä kolmella eri tunnuksella. Keskeisillä liiketoimintakohteilla ei ole yhteistä tai hallitusti linkitettyä tunnistetta, ja kokonaiskuvan kokoaminen vaatii käsityötä sekä tulkintaa. AI-agentit ovat tuoneet tämän vanhan ongelman esiin uudella tavalla. Kun agentti hakee ja yhdistelee tietoa itsenäisesti eri lähteistä, sen luotettavuus riippuu siitä, miten laadukasta data on ja kuinka hyvin organisaation keskeiset käsitteet on määritelty ja yhdistetty.

Kun organisaatiot rakentavat nyt data- ja tekoälykyvykkyyksiään, keskustelu kääntyy nopeasti alustoihin, työkaluihin ja malleihin. Kokemukseni mukaan tärkein perusinvestointi on kuitenkin vaatimattomamman kuuloinen: yhteinen käsitemalli ja selkeät master datan hallinnan periaatteet. Niillä on kaksi eri tehtävää. Käsitemalli määrittää, mitä asiakas, hanke tai tuote organisaatiossa tarkoittaa. Master datan hallinta puolestaan määrittää miten samaa asiakasta koskevat tietueet tunnistetaan, täsmäytetään ja hallitaan, ja mistä virallinen tieto muodostuu. 

Mallin arvo mitataan vuosien päästä 

Lähtökohta on, että käsitemalli ei ole dokumentti vaan työväline. Sen arvo mitataan siinä, ohjaako se järjestelmien, rajapintojen ja tekoälyratkaisujen toteutusta vielä vuosien päästä. Siksi tärkein yksittäinen valinta on se, missä muodossa malli elää. Parhaimmillaan se elää ylläpidettävänä, versioitavana ja koneluettavana mallina. Esitysgrafiikka tai tekstidokumentti vanhenee heti valmistuttuaan. 

Tästä seuraa käytännön ohje: mallin auktoritatiivinen versio ylläpidetään rakenteisessa ja versioitavassa välineessä, ja esitykset ja dokumentit tuotetaan siitä, ei toisin päin. Rakenne kannattaa pitää kevyenä. Luodaan yhteinen ydinkäsitemalli, jota toimialuekohtaiset mallit täydentävät. Välinevalinta tehdään inventaarion edetessä, kun laajuus, ympäristö ja ylläpitomalli ovat riittävän hyvin tiedossa. Olennaisia kriteerejä ovat versioitavuus, koneluettavuus, kytkentä toteutukseen sekä se, että malli on liiketoiminnan luettavissa ilman erikoisosaamista. 

Liiketoiminnan tarpeet edellä, datainventaario rinnalla 

Käsitteellinen malli lähtee liiketoiminnasta ja on riippumaton nykyisestä teknisestä toteutuksesta; muuten vanha järjestelmäarkkitehtuuri alkaa määrittää tavoitemallia. Entiteettien priorisoinnissa yhdistetään siksi kaksi asiaa: liiketoiminnan tarpeet ja tieto siitä, missä ja millaisena käsitteet nykyisin toteutuvat. Jälkimmäisen tuottaa datainventaario, joka tehdään kolmesta suunnasta rinnakkain: 

• Avainhenkilöiden haastattelut ja liiketoiminta-alueittaiset työpajat, joissa tunnistetaan, mitä tietoa työssä käytetään ja mitä puuttuu. 

• Järjestelmien tekninen läpikäynti eli tietokantaskeemat, rajapinnat ja integraatiot. Näin inventaario perustuu todelliseen dataan eikä muistikuviin. 

• Olemassa olevan dokumentaation ja aiemmin tehtyjen kartoitusten hyödyntäminen. 

 
Tuotoksena syntyy inventaario, joka listaa entiteetit järjestelmittäin tunnisteineen, kirjaa datan omistajan tai oletetun omistajan (jos se tunnetaan), ja tekee näkyviksi päällekkäisyydet, ristiriidat ja puuttuvat tiedot. Hyvä jäsennys on jakaa löydökset olemassa oleviin, puuttuviin ja tuleviin entiteetteihin: se pakottaa katsomaan myös eteenpäin, ei vain nykytilaan. 

Liiketoiminta omistaa käsitteet

Käsitemalli rakennetaan työpajavetoisesti niin, että liiketoiminta omistaa käsitteet ja asiantuntija fasilitoi ja mallintaa. IT- ja data-asiantuntijat vastaavat mallin teknisestä toteutettavuudesta, vaikka liiketoiminta omistaa merkityksen. Kullekin ydinkäsitteelle määritellään yksiselitteinen määritelmä, suhteet muihin entiteetteihin sekä elinkaari: missä entiteetti syntyy, missä sitä muutetaan ja milloin se poistuu. 

Jos esimerkiksi asiakas tarkoittaa yhdessä järjestelmässä laskutettavaa organisaatiota ja toisessa yksittäistä käyttäjää, tekninen integraatio ei ratkaise ristiriitaa. Ensin on päätettävä, ovatko nämä sama käsite vai kaksi eri käsitettä, ja mikä niiden välinen suhde on. 

Mallinnus kannattaa tehdä iteratiivisesti. Koko organisaation käsitteistöä ei tarvitse kattaa kerralla, vaan ensin mallinnetaan ne entiteetit, joihin muut kehityshankkeet nojaavat. Tyypillisesti näitä ovat esimerkiksi asiakas, tuote ja keskeiset liiketoimintakohteet. Käsitemalli toimii lähtökohtana loogisille malleille ja järjestelmäkohtaisille fyysisille toteutuksille. Mahdollisuuksien mukaan hyödynnetään mallinnusautomaatiota: mallista voidaan tuottaa loogisia ja fyysisiä rakenteita automaattisesti, mikä vähentää käsitteellisen, loogisen ja fyysisen mallin eriytymistä ja tukee mallien ajantasaisuutta toteutusten edetessä. 

Omistajuus koskee myös mallia itseään. Käsitemallilla on nimetty omistaja, muutokset katselmoidaan ja versioidaan ja muutoksista viestitään toteutuksille. Ilman tätä malli alkaa vanhentua ensimmäisestä julkaisupäivästä alkaen.

Mitä AI-agentti tarvitsee käsitemallilta

Miksi tämä on ajankohtaista juuri nyt? Myös AI-agentit tarvitsevat selkeästi määritellyt käsitteet, suhteet ja käyttöoikeussäännöt toimiakseen luotettavasti. Ilman yhteisiä käsitteitä agentti yhdistelee tietoa arvaamalla, ja arvauksen laatu paljastuu vasta vastauksissa. Kysy agentilta, montako asiakasta meillä on: jos asiakas tarkoittaa yhdessä järjestelmässä laskutettavaa organisaatiota ja toisessa yksittäistä käyttäjää, saat monta eri vastausta, jotka kaikki ovat oikein, mutta silti käyttökelvottomia. 

Koneluettava käsitemalli on agentin perehdytyksen ensimmäinen askel: lisäksi tarvitaan metatiedot, tietolähteiden linkitykset ja rajapinnat, joiden kautta agentti käyttää dataa oikein. Käytännössä koneluettavuus tarkoittaa esimerkiksi sitä, että mallista voidaan generoida tietokanta- ja rajapintakuvauksia ja malli voidaan antaa agentille kontekstiksi, jolloin agentti tietää, että asiakas ja tilaaja ovat sama käsite. 

Käsitemalli kertoo, mitä tieto tarkoittaa. Seuraavaksi pitää ratkaista, kuka sitä hallitsee ja mistä sen auktoritatiivinen versio muodostuu. Siitä kertoo tämän sarjan toinen osa: master datan periaatteet, pääsynhallinta ja se, miksi työkaluhankinta ei ole ensimmäinen askel. Pysy kuulolla!