Proof of Concept (PoC) on soveltuvuusselvitys, jonka tarkoituksena on selvittää, miten testauksessa oleva työkalu käytännössä toimii ja vastaako se organisaation tarpeisiin. PoC:n tavoitteena ei ole rakentaa valmista ja kaiken kattavaa ympäristöä, vaan tarkastella kuinka työkalu vastaa sille asetettuihin vaatimuksin. Jo asteikko "toimii/ei toimi" voi olla riittävä. PoC eroaa perinteisestä demosta, jossa työkalua esitellään kohdeyleisölle, sillä asiakkaat pääsevät halutessaan itse testaamaan työkalua käytännössä. Käytännönläheisyys on vahvasti läsnä PoC:ia tehdessä.
Datakatalogityökalun testaaminen PoC:n avulla ei hyvin suunniteltuna vaadi organisaatiolta mahdottomia. Suunnittelun lisäksi työtä voi joutua tekemään jonkin verran etupainotteisesti. Olin itse vastikään mukana eräässä datakatalogityökalun PoC:ssa ja sen innoittamana ajattelin kirjoittaa havaintojani.
Asiakasorganisaatiolla, johon teimme PoC:ia, oli tarve saada parempi kokonaiskuva omasta datastaan. Organisaatiossa oli lukuisia erillisiä PowerPoint-, Excel- ja Visio-dokumentteja, mutta datan virtaus ja datalle tehtävät toimenpiteet eivät olleet läpinäkyviä. Yksittäisiä, omat järjestelmänsä läpikotaisin tuntevia asiantuntijoita oli paljon. Lisäksi organisaatiossa oli todella paljon hiljaista tietoa dataan liittyen. Edellä mainituista tekijöistä johtuen datahaasteiden selvittäminen hankaloitui huomattavasti.
Saimme vietyä PoC:n maaliin tehokkaasti ja asiakas näki nopeasti tuloksia. Työkalun testaaminen omalla tutulla liiketoiminnan datalla teki työstä heti ymmärrettävämpää ja konkreettisempaa. Työkalu toi paljon apua läpinäkyvyyden puuttumiseen liittyviin ongelmiin, mutta kaikkiin tavoitteisiin testatulla työkalulla emme toistaiseksi pystyneet vastaamaan.
Edellytykset sujuvan datakatalogi PoC:n läpiviennille
Datakatalogi kannattaa mielestäni ottaa käyttöön vaiheittain ja on järkevää jakaa tekeminen pienempiin osiin. PoC:n toteutus ei tee tähän sääntöön poikkeusta. Datakatalogin PoC edellyttää tiettyjä asioita, jotta sen voi viedä tehokkaasti maaliin. Alle olen listannut huomioitavia asioita, joiden järjestys voi vaihdella organisaatio- ja tapauskohtaisesti.
1. Kick-off ja tavoitetilan määrittely
Polkaisimme tekemisen käyntiin tiimin yhteisessä kick-offissa. Mielestäni on erittäin tärkeää määritellä yhdessä tavoitteet PoC:lle. Tällöin onnistumista on helpompi mitata ja kaikki tietävät, mitä kohti työssä ollaan menossa. Odotustenhallintaa ei myöskään pidä unohtaa: on olennaista sopia, mitä PoC:n aikana tehdään ja mitä ei, sillä PoC:ssa ei tosiaan ole tarkoituksena tehdä kaikkea. Näin vältytään epätietoisuudelta ja yhteisymmärryksen puuttumisesta johtuvilta pettymyksiltä.
2. Asiakkaan liiketoiminnan ja kontekstin ymmärtäminen
Työpajat, haastattelut ja olemassa olevan dokumentaation läpikäyminen on mielestäni erityisen tärkeää, jotta ymmärretään asiakasorganisaation liiketoimintaa ja kontekstia. Tätä taustatyövaihetta ei voi sivuuttaa ja tähän kannattaa varata aikaa. Toimeksiannossamme asiakas hyötyi tästä vaiheesta, kun konsultit kyselivät lukuisia kysymyksiään ja saivat miettimään asioita eri näkökulmista. Tietämys oman organisaation asioista lisääntyi tahtomattakin, kun asiantuntijat eri puolilta organisaatiota pohtivat asioita yhdessä.
3. Sanasto
Liiketoiminnan sanasto (eng. business glossary) on mielestäni elintärkeä osa datakatalogia. Sanasto kertoo organisaation yhteisen kielen ja linkittyy kaikkeen datakatalogissa. On olennaista listata yhdessä sovitut termit määritelmineen siinä muodossa kuin liiketoiminta asioista puhuu. Mielestäni datakatalogin rakentaminen kannattaa aloittaa sanaston tuomisella, sillä se on selkeä oma kokonaisuutensa. Mikäli organisaatiossa ei ole valmiina sanastoa, pitää sen rakentamiselle PoC:n aikana varata aikaa. Tekemässämme toimeksiannossa päädyimme keräämään sanastoa työpajojen, haastattelujen ja dokumentaation pohjalta. Täydellistä sanastoa ei PoC:n aikana ollut tavoitteena tuottaa, vaan riittävä otos, jonka avulla saimme esitettyä työkalussa muun muassa eri termien synonyymejä sekä linkityksiä vastaaviin termeihin.
4. Tietomallit
Eritasoiset tietomallit auttavat datakatalogin rakentamisessa. Esimerkiksi käsitteet määritelmineen sekä niiden väliset yhteydet ja käsitteitä tarkentavat tiedot havainnollistavat hyvin liiketoimintaa ja helpottavat itse katalogisointityössä. Käsitemalli ja liiketoiminnan sanasto kulkevat mielestäni käsi kädessä. Toimeksiannossa emme hyödyntäneet tietomalleja, mutta koska PoC:n rajaus oli hyvin selkeä, ei niiden puuttuminen aiheuttanut haasteita.
5. Datan omistajuus
Datakatalogi auttaa data governancen toimeenpanemisessa, ja sen avulla voidaan konkretisoida ja tuoda datan omistajuus sekä vastuut osaksi kuvauksia. Viimeistään PoC:ia tehdessä näihin tulee mielestäni ottaa kantaa. Toimeksiannossamme asiakas määritteli myös henkilöt vastuurooleihin osana sanaston katselmointia, jotta ne saatiin vietyä datakatalogityökaluun. Tämä synnytti myös keskustelua omistajuudesta laajemminkin.
6. Työkalun valinta
Organisaation tulee tehdä melko varhaisessa vaiheessa päätös testattavasta työkalusta, jotta PoC voidaan toteuttaa. Työkalun valinta voi vaatia lisäselvittelyjä päätöksenteon tueksi ja se ottaa oman aikansa. Toimeksiannossamme työkalun valintaan vaikutti muuan muassa organisaation käyttämä IT-ekosysteemi, joka rajasi ison osan työkaluista pois. Mikäli valinnanvaikeus uhkaa iskeä, voi apuna käyttää myös Loihteen asiantuntijoita.
7. Datalähteet
PoC:n onnistumiseksi sovitun ajan ja budjetin puitteissa tulee datalähteiden määrä rajata huolella. Lisäksi on hyvä etukäteen selvittää, kuka on oikeutettu kytkeytymään lähdejärjestelmiin ja suorittamaan esimerkiksi skannauksen datakatalogityökalun sisällä. IT-osasto on otettava tässä kohtaa viimeistään mukaan keskusteluihin. Tekemässämme toimeksiannossa kohtasimme haasteita lähdejärjestelmiin kytkeytymisessä, mutta pääsimme eteenpäin varasuunnitelman avulla. Koska emme päässeet kiinni haluttuun lähteeseen, käytimme apuna tietokantaa, joka sisälsi lähes samat tiedot.
8. Tarvittavat oikeudet
Kannattaa pyytää IT:ltä hyvissä ajoin oikeudet tarvittaviin ympäristöihin sekä itse testattavaan datakatalogityökaluun. Oikeuksien ja roolien lisääminen ottaa toisinaan oman aikansa. Toteuttamassamme PoC:ssa pistimme oikeusasiat vireille hyvin varhaisessa vaiheessa, ja asiat etenivät tämän osalta jouhevasti.
Mitä PoC:n jälkeen?
Aiemmin jo totesinkin PoC:n olevan nopeahko kokeilu, jonka tarkoituksena on selvittää, soveltuuko valittu työkalu organisaatiolle. Käytännönläheisen tekemisen aikana on tärkeää varmistaa, että organisaatio saa kokeilusta kaipaamansa vastaukset ja tarvitsemansa opit. Kannattaa siis miettiä, mitkä organisaation roolit ovat avainasemassa PoC:n onnistumisen kannalta.
Kuten kaikessa tekemisessä, ei tässäkään sovi unohtaa dokumentaation tärkeyttä. Eri työvaiheiden ja tekemisten dokumentoinnilla mahdollistetaan tietojen jakaminen ja hyödyntäminen jatkossa. Dokumentoinnin lisäksi PoC:n aktiivisen toteutusvaiheen jälkeen voi olla tarpeen esitellä lopputuloksia organisaatiossa eri toimijoille ja jakaa kerättyjä oppeja sekä kokemuksia.
PoC:n jälkeen arvioidaan tavoitetilaan kirjattujen asioiden toteutumista. Tarjoaako koeistettu työkalu helpotusta organisaation haasteisiin? Toimiko työkalu odotetulla tavalla? Jäikö jotain vastauksia saamatta? Näihin ja muihin PoC:iin liittyviin pohdintoihin vastattuaan organisaatio voi päättää datan katalogisoimisen jatkosta – joko testatun tai jonkin vaihtoehtoisen työkalun avulla.
Kirjoituksen on kirjoittanut asiantuntijamme Kati Hiltunen.
