Big Data

Tänä vuonna useampikin suomalainen yritys on joko aloittamassa Big Data -hankkeita tai suunnittelemassa niitä muodossa tai toisessa. Myöskin eri järjestelmätoimittajat – etunenässä Oracle, IMB, SAS sekä aivan äskettäin Google – ovat aktivoituneet asian suhteen. Siitä mitä big data on ja miten sitä hallitaan on kirjoitettu jo kohtalaisen paljon, meidänkin toimestamme. Ajankohta vaikuttaakin kuitenkin hyvältä jakaa joitain ajatuksia siitä, miten tämän kaltaisia massiivisia datahankkeita kannattaa johtaa ja suunnitella. Parhaimmillaan datan hyödyntäminen voi tehostaa liiketoimintaa merkittävästi – mutta sen tekeminen vaatii tervettä järkeä, pitkäjänteisyyttä ja suunnitelmallisuutta.

Big Data -hankkeiden haaste on se, että ne ovat, no, valtavia. Tuskin on montakaan muuta kehityshanketta joka voi potentiaalisesti vaikuttaa yrityksen toimintaan niinkin laajalti. Loppuun asti sovellettuna Big Data vaikuttaa nimittäin koko organisaatioon, alkaen tietenkin johtamisesta ja tietojärjestelmien ja liiketoiminnan kehityksestä, mutta päättyen periaatteessa aivan kaikkeen mitä yritys tekee, ja miten. Koko kenttä on erittäin hankala kenenkään yksittäisen ihmisen edes hahmottaa, ja ehkä juuri siksi hankkeissa mennään usein metsään jo alkuvaiheessa. Pääasiallisia tapoja torpedoida hanke jo alussa on oikeastaan kuitenkin vain kaksi.

Kaksi reittiä hakoteille

Ensimmäinen tapa mennä pahasti pieleen on se, että aloitetaan hankkimalla järjestelmä. Järjestelmätoimittajathan käyvät mielellään esittelemässä tuotteitaan halukkaille ostajille – varsinkin, mikäli on nähtävissä että tuotteelle on tilausta yrityksen johdossa asti. Tyypillisesti tällöin erilaiset mahdollisuudet, ominaisuudet ja tarpeet kerätään järjestelmätoimittajilta, ja koska niitä luetellaan usein hyvinkin auliisti, syntyy lopputuloksena valtava tarvelista jonka priorisoinnista tulee mahdotonta. Mikäli hankinta etenee ostoon asti – useimmiten siksi, että asiaa pidetään yleisellä tasolla tärkeänä, ja hankintaan on kuitenkin uhrattu aikaa – voi olla kohtalaisen varma, että tulos on sekametelisoppa jonka käyttöönottoa kukaan ei hallitse.

Toinen tapa mennä pahasti pieleen on taas se, että mietitään liiankin perinpohjaisesti mitä oikein tarvitaan – eli aloitetaan massiivinen määrittelyprojekti. Tällöin tehdään tyypillisesti ensin laaja kartoitustyö käytössä olevista tietokannoista, datalähteistä, raportointijärjestelmistä, ja tietoskeemoista ja lukuisista muista asioista ja sitten mietitään, miten tämän kaiken saisi yhdistettyä keskenään. Viimeistään tässä vaiheessa suunnitteluun astuu politiikka mukaan: kenen tietojärjestelmästä luovutaan, ja kuka siis joutuu oppimaan työtänsä osin uusiksi? Minkä tahon näkemys pärjää kun keskustellaan siitä, miten tietoa kerätään, ja minkälaisia raportointijärjestelmiä otetaan käyttöön? Kuka tietoa hallitsee, ja miten sitä jaetaan? Kohta huomataan, että määrittelyprojektissa kestää vuosikausia – ja kun se joskus valmistuu, alkuperäiset tarpeet ovat jo vanhentuneita.

Perimmäinen ongelma molemmissa lähestymistavoissa on se, että hankkeet nähdään lähinnä tietojärjestelmähankeina. Sitä ne eivät ole. Big Datan käyttöönotto on valtaosin liiketoiminnan kehityshanke – ja vieläpä sellainen, jossa tietojärjestelmät näyttelevät kohtalaisen pientä, vaikkakin kriittisen tärkeää, roolia.

Pienin askelin eteenpäin

Miten hankkeet sitten pitäisi toteuttaa? Ensin täytyy miettiä muutama konkreettinen asia, mitä halutaan saavuttaa. Ainakin seuraavat kysymykset kannattaa käydä lävitse sekä kulmahuoneen että keskijohdon kanssa:

  1. Mitä hyötyjä halutaan isosta datasta – mitä yrityksen toimintoja se koskettaa? Vaikka vaikuttaisi siltä, että vastaus on ‘no kaikkia tietenkin’, kannattaa asia tässä vaiheessa purkaa auki. Mitä toimenpiteitä sen perusteella halutaan tehdä, ja mitä tietoja tämän tueksi tarvitaan?
  2. Mitkä toiminnot tietoa tarvitsevat? Vähintäänkin kannattaa käydä lävitse tarpeet iiketoiminnan johdon, tuotekehityksen, myynnin, markkinoinnin ja asiakaspalvelun kannalta.
  3. Kuka vastaa näistä toiminnoista? Mitä johtopäätöksiä halutaan tehdä? Laadi näiden ihmisten kanssa esimerkkejä siitä, miten tämä tieto vaikuttaa jokapäiväiseen työhön.
  4. Minkälaisia raportteja ja analyysejä halutaan, ja kuinka usein? Miten varmistetaan, että data on riittävän laadukasta, ja että sen prosessointi on riittävän joustavaa?
  5. Miten raportointi järjestään ottaen huomioon muokkaamisen helppous, käyttäjäoikeudet, tietoturva ja jaettavuus?
  6. Miten toimenpiteiden toteutumista ja saatuja hyötyjä seurataan?

Tämä pohdinta kannattaa tehdä ensin siellä, missä asiat on helpointa saada toimimaan – eli niissä osissa organisaatiota missä resursseja on riittävästi ja intoa toteuttamiseen ja käyttöönottoon on jo valmiiksi. Kuitenkaan ei pidä unohtaa sitä, että järjestelmän täytyy myös myöhemmin skaalautua ja tietojen yhdistämisen sekä uuden tiedon lisäämisen täytyy olla vaivatonta.

Itse järjestelmää valitessa kannattaakin erityisesti kiinnittää huomiota siihen, miten dataa käsitellään. Käytännössä tämä tarkoittaa seuraavia asioita:

  • Prosessoinnin täytyy olla riittävän tehokasta. Jos yksittäisen raportin prosessointi kestää tuntikausia, on käytännön analyysityö usein joko hyvin hankalaa ellei mahdotonta. Yksittäisessä tietohaussa ei saisi mennä muutamaa minuuttia pidempään. Hyvänä testinä kannattaa selvittää esimerkiksi se, kuinka kauan sadan miljoonan rivin raakadatan prosessointi kestää.
  • Data on hyödytöntä ellei sitä saada joustavasti analysoitua ja käyttöön. Raportointi ja analyysimahdollisuuksien laajuus ja käytettävyys on siksi erittäin tärkeää, ja siksi esimerkiksi valmiiden analyysityökalujen laajuus ja yksittäisen raportin tekemiseen tarvittava aika kannattaa selvittää jo etukäteen.
  • Kelvollisia johtopäätöksiä voi saada vain jos data on kelvollista. Siksi on tärkeää selvittää, miten tietojen yhdistäminen toimii, ja kuinka joustavasti uutta tietoa voi lisätä olemassaolevaan. Käytännössä tämä tarkoittaa useimmiten sitä, kuinka helppoa on lisätä uusia yhteisiä nimittäjiä eri tietosarjoihin.

Viisaus seuraa tässäkin tuttua kaavaa: ensin kannattaa miettiä liiketoimintaa, ja tämän jälkeen ihmisiä rooleineen ja vastuineen. Näistä saadaan osviittaa prosessien laatimiselle, ja vasta tämän jälkeen kannattaa tehdä päätöksiä teknologian suhteen. Jos lähdetään suunnittelemaan teknologia tai prosessit edellä, on vaarana mennä metsään niin että raikaa. Ja kuten aina, KPI-mittaristot kannattaa suunnitella kunnolla jo ensi vaiheessa myös muualla kuin verkkopalvelussasi.

Ja tämän jälkeenhän vasta aloitetaan sitten varsinainen analytiikan hyödyntäminen organisaatiossa.