Vastine edelliseen! Onko Big data enää isoa?

Joko tuo ”Big” etuliite voidaan poistaa? Datamassat paisuvat jatkuvasti, se on selvää. Siksi tuo ”Big” viittaa tänä vuonna eri suuruusluokan datamassaan kuin esimerkiksi viime vuonna. Puhutaan vaikka datatulvasta tai keksitään joku muu kuvaavampi termi.

Mietin datateemojen marssijärjestystä: Kumpi tulee ensin Big vai Master? Koska fuusioidaan tästä Big Master Data? No tulin siihen tulokseen, että Master Data on fokus numero yksi, jonka jälkeen katseet voidaan kääntää Big Dataan. Master Data ongelmia on kaikilla yrityksillä ja niiden rooli turhina kustannuserinä nousee taas tänä vuonna esille, kun monessa paikassa etsitään optimointikohteita. Suuria, jäsentymättömiä datamassoja ei vielä kovin moni organisaatio kaivele muutenkaan. Master Datan hallinta myös pakottaa miettimään datanhallintaprosessit ja vastuut valmiiksi, mikä helpottaa kaikenlaisten tulevien datahankkeiden onnistumista.

”Big Poppa Mastah Datanator”

Big Master Data –heittoni tuolla alussa ei ollut täysin tuulesta temmattu vitsi. Viime marraskuun Asiakaspäivässämme vieraillut ja tässä blogissakin aikaisemmin mainittu Peter R. Benson ennusti, että tulevaisuudessa ihmisen antama datasyöteDatan validointi nousee avainasemaan vähenee, ja järjestelmät synnyttävät ja vaihtavat dataa keskenään. Kuinka paljon esim. asiakasdatasta, siis siitä metadatasta, on oikeastaan kenenkään omistuksessa?

Vuodet vierii, tietomassat kasvaa. Joka vuosi massan kasvaessa sen oman asiakastiedon ja nimikemassan järkevöittäminen hankaloituu. Ehkä vuosi 2013 on hyvä vuosi nostaa data puheista tekoihin?

The data is already out there!

– Kalle –

Missä se kura syntyy ja kuka siitä on vastuussa?

Kallekin jo aiemmassa kirjoituksessa viittasi otsikossa mainittuun aiheeseen, joka oli tänä vuonna Talentum Eventsin järjestämän Master Data Management 2012 -seminaarin esitekstinä. Seminaarissa moni puhuja korosti ihmisen merkitystä hyvälaatuisen tiedon hallinnassa, eikä varmasti turhaan. Yksittäisen tiedon laatuhan syntyy sitä syötettäessä.

Seminaarissa nähtiin esimerkkejä hyvistä käytännöistä. Niissä kaikissa oli jotain yhteistä. Master datan vastuu oli nimetyllä tiimillä, joka myös hallitsi dataa. Globaalin tason tiimi ylläpitää nimikedataa, ja tiimiltä pyydetään uutta nimikettä sitä tarvittaessa. Koska tiedon laatu on tiimin vastuulla, perustettava nimike tulee syötettyä tarkasti: oikeassa muodossa ja oikeat tiedot oikeissa kentissä, mahdollisen datastandardin mukaisesti. Luonnollisesti tiimi huolehtii myös siitä, ettei duplikaatteja pääse syntymään. Eräs toimija kertoi heidän sisäisen SLA:nsa uuden nimikkeen luonnille olevan 48 tuntia. Äkkiseltään ajateltuna tuon kuvittelisi aiheuttavan käyttäjäkunnassa nurinaa, mutta kokemukset ovatkin päinvastaisia. Ehkä suuri osa aiemmin nimikkeitä luoneista käyttäjistä on omakohtaisesti kokenut tuskaa miettiessään, mitä mihinkin kenttään pitää syöttää, missä muodossa syöte on, mitä yksiköitä käytetään missäkin, onkohan nimike jo olemassa –  tarvittavista kieliversioista puhumattakaan. Nimiketiimin palvelu ei siis ainoastaan paranna nimikedatan laatua, vaan poistaa myös peruskäyttäjiltä työtä, josta he eivät välttämättä pidä.

Vaikka nimiketiimin sisäinen prosessi on yksinkertainen, huolehtii se systemaattisesti ja jatkuvasti tiedon laadusta.

Ihmistyön tärkeyden ohella pitää työkalujen olla kunnossa siten, että ne tukevat mahdollisimman hyvin laadukkaan nimiketiedon tuottamista, ja että laadukas tieto saadaan luotettavasti yrityksen muihin järjestelmiin.

Sponsori

Toinen seminaarin esityksissä esiin tullut yhteinen piirre hyvissä ja huonoissa käytännöissä oli sponsori. Hyvissä käytännöissä master datan käytännöillä oli korkean tason, usein ylimmän johdon, ”tukija” yrityksessä. Huonoissa käytännöissä tuo niin sanottu sponsori puuttui. Ilman korkeimman johdon ymmärrystä ja sitä kautta tukea ei hommaan satsata tarpeeksi resursseja. Tai se joutuu jopa säästötoimien alle, vaikka jotain hyvää olisi saatu aluilleen. Viimeksi eilen kuulin asiakkaamme kertovan, että resursseista on joutunut alkuvaiheessa hieman tappelemaan. Onkohan kyse ollut juurikin riittävän korkean tason sponsorin puutteesta?

Mistä alkuun?

Yrityksissä on huomattava määrä tietoa, johon olisi hyödyllistä soveltaa MDM-käytäntöjä. Nimiketieto on asiakastietojen ohella tyypillisesti eniten ongelmia aiheuttava osa-alue, kun mietitään millaisiin raportteihin asiakastiedoilla tai nimiketiedoilla on vaikutusta. Puhumattakaan raporteista, joissa molemmat ovat vaikuttavia tekijöitä. Ja vielä kun mietitään, mitä esimerkiksi ryvettynyt nimikedata tarkoittaa raporttien luotettavuudelle, voi vain arvailla miten hyviä päätöksiä raporttien perusteella tehdään. Nimiketieto ei ole siis lainkaan hullumpi kohde aloittaa Master Data -käytäntöjen hyödyntäminen. Toki tuon ”aloittamisen” usein kuvitellaan olevan helppo ja kokonaisuutenakin kohtuullisen pieni juttu. Järjestelmän suhteen kyseessä ei ole järisyttävän valtava hanke, mutta toimintamallien muuttaminen keskitettyyn datan hallintaan on usein se, mikä vaikuttaa läpi organisaation enemmän tai vähemmän. Toki jos MDM-käytännöt otetaan käyttöön esimerkiksi ERP-hankkeen yhteydessä, on se tietysti osa massiivista kokonaisuutta. Tärkeää on luonnollisesti miettiä hyvin tarkkaan kunkin organisaation tavoiteltu prosessimalli, mahdollinen tiedon standardointi, välineet ja integraatiot, sekä tietysti tarvittava harmonisointityö olemassa olevan datan laadun saattamiseksi oikealle tasolle. Ja menestykseen tarvitaan vielä se sponsori.

Kura syntyy loppukäyttäjän ja päätten välilläAlkuperäiseen kysymykseen: Missä se paljon puhuttu kura syntyy ja kuka viime kädessä on vastuussa? Suurin osa kurasta syntyy suuren porukan näppäimistön ja selkänojan välissä. Vastuuseen siitä ei oikein tahdo saada ketään.

Kannattaisiko keskittää nimikedatan luomisen ja ylläpitämisen vastuu rajatulle porukalle, jolla on käytössä hyvät työkalut, yksinkertainen mutta kuvattu prosessi, ja se sponsori. Kuraa ei enää synnykään ja tarpeet massiivisille datan harmonisoinneille poistuvat tulevaisuudessa.

– Jani –

Mestarillista Datan Hallintaa

MDMää sarvista

Tämäkin artikkeli ratsastaa suositulla terminologialla.

Master Data Management on ollut trendikäs aihe jo useamman vuoden, joskin sen kovin hypehuippu taitaa olla jo takanapäin.  Hypetysvuodet ovat karsineet isoimmat kuonat ja trendillä ratsastajat pois kyydistä. Nykyään Master Data Management ymmärretään liiketoiminnan kehityshankkeeksi, eikä pelkäksi konsulttihypeksi. Hanke on sinällään harhaan johtava sana, sillä kyse on jatkuvasta toimintatavasta. Keskustelu on herättänyt yritykset kiinnittämään enemmän huomiota informaation laadukkuuteen jatkuvan teknologiapalvonnan sijasta.

Talentum Events järjestää aiheesta seminaarin nyt toista kertaa 18.- 19.9.2012. Tapahtuman esiteksti esittää hyvän kysymyksen:

” Missä se paljon puhuttu kura syntyy ja kuka siitä on viime kädessä vastuussa?”

Etenkin tuo vastuukysymys on mielenkiintoinen. Kuraa syntyy yleensä jo tiedon alkulähteellä, eli loppukäyttäjän päässä. Onko vastuu laadukkaasta tiedosta meillä kaikilla? Itse en valitettavasti pääse osallistumaan tuohon seminaariin, mutta meiltä on oma delegaatio tulossa paikalle. Vaikka emme laske itseämme varsinaiseksi master data -toimijaksi, on nimikedata – meidän leipälajimme – yksi merkittävä osa master dataa.

Puheista tekoihin

 MDM:n jalkauttamisesta käytäntöön löytyy nopeallakin googlauksella liuta erilaisia malleja ja toimintakehyksiä. Jotkin varmasti toimivampia kuin toiset. Omaan organisaatioon soveltuvaa mallia ei välttämättä suoraan löydy, mutta hyödyntämällä erilaisia toimintakehyksiä soveltuvilta osin päästään varmasti hyvään alkuun.

Tarve master datan hallinnalle on monessa yrityksessä jo tunnistettu ja tietoa, asiantuntijoita sekä ymmärrystä on enemmän kuin aikaisemmin, niin miksi kovin moni velloo silti nykytilassa? Onko kyse uskalluksen puutteesta vai johtamisongelmasta, viitaten Stephen Porterin kiteytykseen johtamisen merkityksestä PLM-artikkelissaan:

” Effective Management is putting first things first. While leadership decides what first things are, it is management that puts these first, day by day, moment by moment. Management is discipline, carrying it out.”

– Kalle –

Onpas sinusta kasvanut jo iso järjestelmä!

*DM-järjestelmien kanssa painiessa otsikon mukainen lausahdus tulee usein mieleen. Erilaista tietoa on runsaasti, tieto on syvästi rakenteellista ja monimutkaista. Kukaan ei liene täysin selvillä siitä mitä kaikkea yksittäinen tuoterivi saattaa sisältää. On siirtotietoa, suuretietoa, lajittelutietoa, kuvauksia jne. Tästä tuskasta kertoo myös järjestelmien tietorakenteet; Esimerkiksi SAP:n tietokanta (RDBMS) sisältää tuhansia tai kymmeniä tuhansia tietokantatauluja. ECC ja R/3 koostuu yli kolmestakymmenestä tuhannesta taulusta kun taas CRM saattaa jäädä alle kymmenen tuhannen. Vertailun vuoksi jotkin PDM-järjestelmät sisältävät tauluja vain noin 100-200. Rakenteellisuus on olennainen osa järjestelmiä, mutta samalla rakenteellisuus ainakin tietoalkiotasolla tuo mukanaan melkoisia ongelmia mitä tulee itse järjestelmien toimintaan. Viitteiden ylläpidon, tiedon reaaliaikaisuuden ja tiedon esittämisen haasteet lisääntyvät eksponentiaalisesti, mitä suuremmaksi objektien rakenne kasvaa. Tiedonhaku vaikeutuu ja järjestelmän koko ”pullistuu”.

Järjestelmädieetti

Ratkaisuna monimutkaisiin rakenteisiin ehdotan  NOSQL-tyyppisiä järjestelmiä, tuettuna relaatiokannalla metadatan tallentamista varten. Poistetaan turhat rakenteelliset attribuutit ja tuodaan rekursion sijaan peliin leveät tietueet, kuten esim. BigTable, HBase, Amazon SimpleDB, Cassandra, Lucene jne. Mitä laveampi data tarkoittaa käyttäjälle? Tietokanta-/kyselymielessä jokaiseen liitokseen voidaan liittää aikakustannus. Kustannus ei ehkä ole suuri (tyypillisesti millisekunteja keskikokoisessa järjestelmässä), mutta kun näitä kustannuksia on paljon, puhutaan helposti sekunneista tai jopa kymmenistä sekunneista.

Kuinka merkittäviä sekunnit ovat? Jos haet tietoa vaikkapa 500 kertaa päivän aikana, löydökset ovat 70% tarkkoja (lue: haet tietoa todella hyvin ja tarkasti) sekunnin kustannus on jo kohtuullisen merkittävä. Kustannus (hakutulokset ja niiden kahlaaminen huomioonottaen) kuluttaa työpäivästäsi n. 20 %. Merkittävä määrä aikaa siis menee tiedon hakemiseen. Laveassa tietomallissa liitokset ovat jo soveltuvin osin kiinni itse alkuperäisessä objektissa ja tästä suora seuraus on hakuaikojen lyheneminen, tiedonsaannin tehostuminen sekä myös hakuominaisuuksien suoraviivaistuminen.

Muistithan bonukset?

Mitä muuta etua saavutetaan? Kun mukana ei enää kuljeteta merkityksetöntä sisäistä tietoa, tilantarve palvelimella pienenee, riippuen tietorakenteesta. Lisäksi tehokkaammat ja nopeammat järjestelmät voidaan ottaa esimerkiksi data mining-käyttöön (duplikaattien poisto, tiedon eheyden tarkistus, samankaltaisuuksien poiminta, puuttuvien tietojen etsintä jne.).  Voidaan hyödyntää ”uudenlaisia” ja tehokkaampia hakutapoja, ja mikä tärkeintä, voidaan esitellä semantiikkaa, mikä taasen tarjoaa aivan uusia ja mullistavia tapoja ”* Data Managementtiin”. Semantiikasta jatkakaamme myöhemmin, tämänkertainen ajatusvirta olkoon tässä.

– Juha –

Järjestelmähankkeiden sietämätön keveys

Suuret IT-hankkeet ovat tunnetusti melkoisia rahareikiä, sillä riippumatta siitä mitä tutkimusta tarkastelee, niin reippaasti yli puolet niistä epäonnistuu. Suurimmat syyt epäonnistumiseen ovat sitoutumisen puute käyttäjien ja johdon osalta sekä epärealistiset odotukset projektin etenemisestä. Kuinka monta järjestelmähanketta tiedät, jotka olisivat onnistuneet alittaen alustavan projektiaikataulun?

Hei, ei täs mitään. Onhan moni muukin epäonnistunut.

Voehan rähmä!Miksi järjestelmähanke eroaa niin paljon muista ”rakennushankkeista”? Miettikääpä vaikka talonrakennusta; kuinka monta järjestelmäprojektia oikeasti seurataan yhtä tarkalla pieteetillä kuin talonrakentamista? Jos järjestelmäprojektille tehtäisiin yhtä tarkat suunnitelmat, arvioinnit ja edellytykset kuin ns. konkreettisille rakennusprojekteille, niin saataisiinko tuota läpimenoprosenttia kasvatettua?

Niksipirkka

Yksi vinkki järjestelmäprojektin kanssa painiville: Palkatkaa teknisesti pätevä kaveri projektin vetäjäksi. Sellainen, joka on joskus aikaisemmin tehnyt vastaavanlaisen, onnistuneen järjestelmäprojektin. Aivan kuten osaava rakennusmestari säästää aikaa ja omaa mielenterveyttä, kokeneesta projektipäälliköstä ei kannata isommissa järjestelmäprojekteissa tinkiä. Vaikeahan näitä on löytää, sillä hyvin harva joutuu painimaan samankaltaisten, suurten järjestelmäprojektien parissa useammin kuin kerran.

Lisäksi kannattaa tunnistaa järjestelmähankkeeseen sisältyvät aliprojektit ja hallita myös niiden resursointi. Eräs aliprojekti, joka saa usein liian vähän huomiota, on dataharmonisointi (datamigraatio, yhdenmukaistaminen, konvertointi… Miksi sitä nyt haluaakin kutsua). Erääsääkin tapauksessa dataharmonisoinnille oli varattu aikaa kuukausi, vaikka datamassaa oli reippaanlaisesti. Kuulostaako realistiselta? Halpa hinta harvoin korreloi laadun kanssa ja nopeus kasvattaa usein riskiä.

Data on kuitenkin se järjestelmän ydin. Ei se hieno järjestelmä palvele ketään, jos sisältö on silppua. Se mitä hyötyä järjestelmällä halutaan saavuttaa vaikuttaa suoraan siihen, mitä ja kuinka paljon datalle tehdään muutoksia. Järjestelmä itsessään kaikkine palvelinrautoineen on vain kehikko; ”olet mitä syöt”.  Itse asiassa koko asetelma pitäisi kääntää toisin päin, eli varsinainen datan järkeistämisprojekti olisi se ylätason projekti, jonka aliprojektina olisi ”uusi ERPpi”? Silloin taidetaan puhua siitä MDM:stä.

Datan kanssa päästään perimmäisten kysymysten äärelle, kuten kuka vastaa datan laadusta, kuka omistaa datan, millainen hallintomalli, miten olemassa oleva data valjastetaan tehokäyttöön yms. Tullaan sen verran isoon asiakokonaisuuteen, että sitä ei ihan tässä yhdessä blogiartikkelissa pystytä kuvaamaan. MDM asioista tarinoi Maijasen Janne jo viime vuoden puolella. Myös Mikko Jokela vei aihetta eteenpäin omassa blogissaan nostaen datan rinnalle prosessinäkökulman. Lisää datahallinnosta voi lukea esim www.dataversity.net sivuilta.

Mitäs muuta? Johtoportaan tulee sitoutua projektiin, pitäkää visio kirkkaana ja käyttäjät mukaan. Täähän on niin simppeliä, että ihmetyttää toi epäonnistumisten suuri määrä.

Jos aihe muuten kiinnostaa enemmänkin, niin kannattaa ilmoittautua tähän, samaan teemaan pureutuvaan webinaariin.

– Kalle –

2011 Top 3 artikkelit

Blogimme elinkaaren ensimmäinen neljännes alkaa olla pikkuhiljaa lopuillaan. Tänä aikana blogiin on kirjoitettu hyvinkin erilaisia artikkeleita, joita yhdistää yhteinen teema: Tuotetieto. Kuluneen neljänneksen aikana on myös vietetty kesälomat, joka näkyi selvästi heinäkuun ja elokuun alun lukijamäärissä.

Ajattelin jakaa teillekin kolme suosituinta artikkelia kuluneen kolmen  kuukauden ajalta, joten tässä tulee:

1. Tuotteistamisesta tehoa vai tuhoa? (17.6.2011)

Palvelukuvaus armeijan tyyliinTuotteistamisen nimeen on vannottu pitkään. Sen avulla saadaan tekeminen jämäkäksi ja sähläystä vähennettyä, ja onhan se tuotetiedon parissa työskenteleville elinehto. Tämän päivän käsityksen mukaan melkein mitä tahansa voidaan tuotteistaa, terveydenhuoltopalveluista paperikoneiden huoltoon […]

2. MDM – Back to Basics – 1/2 (23.8.2011)

Kun tietomalli ei ole oikein...MDM eli Master Data Management on kuin kuuma peruna, joka polttelee monien suussa ja nousee esille useissa eri yhteyksissä. Mitä MDM sitten oikeasti on? Sitä heräsin itsekin tässä miettimään, kun minua pyydettiin erään julkaisun yhteydessä lyhyesti kertomaan, miten itse määrittelen MDM-järjestelmän […]

3. Onko nimikkeestä hyötyä juuri minulle? Pragmaattinen nimikelaadun näkökulma (21.6.2011)

Nimikkeen laatuvaatimukset

Perinteisten tiedon laatunäkökulmien syntaktisen ja semanttisen rinnalle on noussut, mielestäni varsin oikeutetusti, pragmaattinen tiedon laatunäkökulma. Pähkinänkuoressa pragmaattinen näkökulma  vastaa kysymykseen ”Onko siitä tiedosta mitään hyötyä juuri minulle?”[…]

Kiitoksia kaikille lukijoille! Urhea kirjoitustiimimme jatkaa edelleen tuotetiedon maailman monipuolista penkomista ja tutkimista. Jos sinulla on ideoita tai toiveita artikkelien aiheiksi, niin voit nyt laittaa toimitustiimillemme palautetta (risuja & ruusuja) blogista täältä.

MDM – Back to Basics – 2/2

Laadun parantaminen MDM:n tukena

MDM-prosessia ja laadun parantamista voisi verrata autolla ajamisen prosessiin

Viime artikkelissa esille nostamani Wikipedian määritelmän mukaan MDM-käsitteeseen yhdistetään usein informaation laatu ja laadun parantaminen. MDM muodostaa loogisesti paikan laadun valvonnalle ja parantamiselle, koska sieltä informaatio jaellaan muille järjestelmille. MDM-järjestelmän vaatimuksena voidaan siis pitää kykyä mitata informaation laatua, kuten kuvasin aiemmin data governance osiossa.

Kun ajatellaan MDM:n ydintä ja sen tarkoitusta, niin laadun parantaminen on MDM-prosessia tukeva prosessi. Vaikka laadukas master data onkin tärkeä asia yrityksen toiminnalle, ei se sinänsä ole MDM-prosessin edellytys.

MDM-prosessia ja laadun parantamista voidaan verrata autolla ajamisen prosessiin. Ajamisen päätavoite on kuljettaa ihminen paikasta A paikkaan B. Autoon istuminen, itse ajaminen ja perille saapuminen muodostavat ydinprosessit, jotka täyttävät tämän tavoitteen. Auton huolto taas on verrattavissa informaation laadun parantamiseen. Huolto on tukiprosessi, joka parantaa auton käytettävyyttä ja varmistaa perille pääsyn, mutta se ei ole välttämättömyys autoiluprosessin käynnistämiseen. Master datan laadun parantaminen on  huoltoprosessi, joka on syytä suorittaa esimerkiksi silloin, kun otetaan haltuun uutta dataa uudesta lähteestä.  Tieto rämettyy ajan myötä ja vaatimukset informaation laadun suhteen kasvavat, joten aika ajoin on tehtävä laadun parantamistoimenpiteitä. Laadun parantaminen on siis toimenpide, jonka avulla saadaan master-tiedosta kaikki hyöty irti.

Yhteenveto

Mielestäni MDM on loogisen kasvupolun tulos. Yrityksissä on aina ollut lukuisia erillisiä järjestelmiä, jotka käsittelevät samaa informaatiota – liiketoimintalinjoittain, yritysostojen tuloksena ja monista muista syistä.

Järjestelmänäkökulmasta ongelman ratkaisu on ollut integroida järjestelmiä keskenään ja siirtää tietoa ristiin näiden välillä.  Tämä on johtanut integrointiviidakkoon. Vuosituhannen taitteessa kuumaksi aiheeksi muodostui EAI (Enterprise Application Integration), jonka oli määrä raivata viidakkoa. EAI:n ympärille tuotiin erilaisia massiivisia tuoteratkaisuja. Integraatioiden näkökulmasta tavoitteena oli muodostaa yksi ainoa välityskerros kaikkien järjestelmien välille.Inofmaatiohallinnan keskittäminen

Toisena kehityslinjana EAI:n rinnalla suurissa yrityksissä tehtiin tietovarastoratkaisuja (data warehouse), joilla tuetaan esimerkiksi raportointia. Raportointidatan keruu useista erillisistä järjestelmistä muodostaa merkittävän ongelman, kun järjestelmät sisältävät samaa informaatiota, eikä tiedon oikeasta omistajasta tai oikeellisuudesta voida olla varmoja.

MDM tuo loogisen kehitysaskeleen sekä informaation hallinnan että raportoinnin suhteen. MDM tarjoaa informaation osalta yhden yhteisen totuuden, johon kaikki järjestelmät, kuten myös DW voi tukeutua.

MDM nostaa esille monia kysymyksiä niin prosessien, organisaation kuin myös tietojärjestelmien suhteen. Samaan aikaan MDM-käsitteen ympärille kasataan paljon eri asioita, kuten tiedon laatu ja tiedon omistajuus. MDM-käsitettä  voi kuitenkin lähestyä hyvin maanläheisesti ja ajatella asiaa informaation hallinnan keskittämisenä. Kun perusta on kunnossa, on paljon helpompi lähestyä informaation hallintaa  laajemmin ja hyödyntää sen täyden potentiaalin.

Eihän norsuakaan kannata syödä yhdeltä istumalta.

– Janne Maijanen –