Data-intensiivisissä (esim. tietovarastot, analytiikka, koneoppiminen) projekteissa datan käsittelyyn menee usein 80%:ia työpanoksesta. Loppu 20%:ia on säästetty kaikelle muulle, kuten esimerkiksi raporttien tai ennustemallien toteutukselle – eli alueille, jonka tulisi tuoda varsinainen business hyöty hankkeesta. 

Datan jalostaminen käyttökelpoiseksi ei ole lähtökohtaisestikaan helppoa, sillä se vaatii tekijöiltään laaja-alaista ymmärrystä mm. datan liiketoimintakontekstista, datan laadusta ja rakenteesta eri järjestelmissä, tarvittavista käsittelysäännöistä, halutusta lopputuloksesta ja käytettävistä työkaluista. Ei ihme, että tämän osa-alueen senioritason tekijät ovat haluttua väkeä työmarkkinoilla.


Turhia iteraatioita?

Olen ollut mukana lukuisissa data-projekteissa, joissa on ns. iteroitu edes takaisin. Tyypillisesti niin, että ensiksi rakennellaan dataputket semivalmiiksi, jonka jälkeen luodaan raportteja tai vaikka koneoppimismalleja… ja huomataan että “datassa on jotain vikaa”, ja palataan etsimään syitä ja tekemään korjauksia. Tämä jatkuu kunnes lopputuotokset ovat hyväksyttäviä.

Turhia iteraatioita syntyy kevyellä valmistautumisella.

Itse uskon, että merkittävä osa iteraatioista vältettäisiin mikäli projekteihin lähdettäisiin paremmin valmistautuneena. En ole sotatieteiden asiantuntija, mutta veikkaan ettei armeijakaan lähde hyökkäykseen ilman insentiivistä ja tarkkaa tiedustelutoimintaa. Tässä kontekstissa tiedustelutoiminta tarkoittaa mm. datan laadun, määrän, saatavuuden ja yhdisteltävyyden selvittämistä ennen projektin aloittamista. Tämä vähentäisi selvästi projektien aikana tulevia “data-yllätyksiä” ja siten iteraatioita. 

Itse asiassa, noita em. asioita kyllä usein mietitään ennen projektien aloitusta, mutta varsin yleisellä tasolla. Ajatus ehkä on, että projektissahan ne selviää, joka tietysti pitääkin paikkaansa, mutta se on vain maksajalle epäedullinen tapa toteuttaa projekti. Muistetaan myös, että projektien budjetit ja tavoitteet usein lyödään lukkoon ennen kuin tiedetään mitä Pandorran datalippaasta hyppää esille. 


Data-projektiin valmistautuminen

Olen koostanut tähän erilaisia vaiheita, joiden on tarkoituksena valmistella data-projektin käynnistystä tai käynnistämättä jättämistä – riippuen tuloksista.

1) Liiketoiminnan tavoitteiden kuvaus

Tässä vaihessa syntyy scope tarvittavalle datalle ja ymmärrys mihin liiketoimintatavoitteisiin se kytkeytyy. Iso aihe, josta voisi kirjoittaa enemmänkin.  

2) Datan saatavuuden ja määrän selvitys  

Selvitetään konkreettisesti miten ja mistä data saadaan sekä missä muodossa. Tasona ei riitä, että se saadaan esim. SAP:ista. Tulee tietää mistä sieltä, kuka SAP-expertti auttaa datan saamisessa, tarvitaanko uusia lisenssejä, millaisen rajapinnan yli data kulkee, palomuurit, käyttöoikeudet, jne. Lisäksi on hyvä ymmärtää, että miten paljon sitä dataa on. Ei ole yhdentekevää tuleeko sieltä mega, giga vai tera.

Yksi jos toinenkin data-projekti on viivästynyt, kun nämä selvitykset alkavat projektin jo käynnistyttyä ja niiden on oletettu olevan nopea ja helppo juttu. Oikeasti tässä voi vierähtää viikoista kuukausiin. 

3) Alustava datan laatuselvitys

Tämä on ehkä tärkein vaihe iteraatioiden vähentämisen kannalta. Seuraavassa kuvassa datan laatu on jaettu (mielivaltaisesti) kolmeen eri kategoriaan:

a) Datan tekninen laatu kuvaa datan mitattavaa hyvyyttä, esim. puuttuuko tietoja tai onko päivämäärät samassa formaatissa.

Jo varhaisessa vaiheessa pitäisi olla mahdollista toteuttaa pienillä otoksilla data-analyysiä ja esim. testata datan yhdisteltävyyttä tietojärjestelmien välillä. Tässä vaiheessa kertynyt tieto auttaa varsinaisen data-projektin suunnittelua (kustannukset, riskit, aikataulu, jne.).

Eräässä projektissa ilmeni, että tietojen luotettava yhdisteltävyys järjestelmien välillä oli niin heikkoa, että asiakas viivästytti tietovarastoprojektin aloitusta vuosilla (kunnes ongelma oli korjattu). Tämä onkin hyvä vaihe testata organisaatiossa yleisesti olevia uskomuksia datan hyvyydestä tai huonoudesta. 

Aina toisinaan aloitetaan POC-projekteja, joiden scope on hyvin lähellä tätä vaihetta. Testataan rajatussa kontektissa datan käyttöä, joka on järkevää.

b) Datan sisällöllinen laatu, kuvaako data järjestelmässä sitä mitä on oletettu? Esimerkiksi onko kustannuspaikkatietoa käytetty yhteismitallisesti eri yksiköissä (eräässä projektissa ei oltu). Useammassakin projektissa on ilmennyt, että tiettyihin kenttiin tallennettu tieto ei ole yhteismitallista eri vuosien välillä, johtuen vaikkapa lainsäädännön muutoksista. 

Tässä vaiheessa tulee myös esille erilaiset “säännöt”, joilla liiketoiminnan ihmiset ovat muokanneet dataa itselleen käyttökelpoiseksi. 

Kokonaisuutena tämän vaihe auttaa ymmärtämään, että mikä data on käyttökelpoista tulevan projektin tavoitteiden kannalta ja millaisia käsittelysääntöjä voidaan tarvita.

c) Yhteisten käsitteiden ja termien ymmärtäminen. Tämä on erityisen tärkeää projekteissa, joissa dataa yhdistellään yli organisaatioyksiköiden. Jos ei puhuta samaa kieltä, niin se ei ainakaan vähennä väärinkäsitysten ja iteraatioiden määrää.

Itse asiassa muutama viikko sitten olin palaverissa, jossa puhuttiin tietomalleista. Minulle ne tarkoittavat Data Vaultia, tähtimallia, yms., mutta ko. palaverissa niillä tarkoitettiin aivan jotain muuta. 

Kannattaa myös huomata, että isommissa projekteissa on lähes aina toimittajien konsultteja mukana. Heillä ei välttämättä ole käsitystä siitä, että samat termit voivat tarkoittaa eri asiaa – riippuen kenen kanssa keskustelee. 

4) Palaset yhteen

Edellisissä vaiheissa on kerätty runsaasti data-informaatiota ja monesta eri näkökulmasta. Todennäköisesti matkan varrella on tehty havaintoja, joista on hyöytyä muidenkin prosessien tai järjestelmien kehityksessä. Tämän vaiheen tarkoituksena onkin vetää asiat yhteen ja tulkita tuloksia.

Ote tuloksista voisi kuulua vaikka näin.

“Tuotetason myyntiraportoinnin toteutukselle ei ole esteitä ja data on tässä kontekstissa luotettavaa. Sen sijaan tuotetasolla ei voida tehdä ennusteita, koska tuotteilla on liian lyhyt myyntihistoria ja osalla tuotteita liian vähän myyntitapahtumia. Ennustemalleja voi toteuttaa tuoteryhmä tasolla. CRM:n asiakastietoja ei voida luotettavasti yhdistää myyntitapahtumiin, johtuen puutteellista avaintiedoista ja CRM:ssä olevista dublikaateista. Vuonna 2016 tapahtuneen yrityskaupan jälkeen myyntidata ei ole vertailukelpoista aiempiin vuosiin nähden.”

5) Data-projektin suunnittelu

Rohkenen väittää, että edellisten vaiheiden jälkeen onnistuneen data-projektin suunnittelu paljon todennäköisempää, koska selvitettyä tietoa on aiempaa enemmän käytettävissä. 

Tämä auttaisi myös realistisempien kustannus-, aikataulu- ja työmääräarvioiden tekemistä. Eikä haittaa olisi myöskään ns. odotusten hallinnassa. Tämä vain siksi, että päätettiin kurkata Pandorran datalippaaseen hieman etukäteen.

Toki on huomioitava, että tämä prosessi ei välttämättä sovellu pieniin data-projekteihin. Jos kuitenkin estimoidut työmäärät ovat kolminumeroisia, niin valmistautumisen hyödyt ovat jo merkittävät.