Vajaa vuosi sitten kirjoitin siitä, kuinka asiakkaat ovat kiinnostuneita Master Datan hallinnasta, mutta tuskailevat että se tuntuu olevan niin massiivinen harjoitus ettei oikein aika tai resurssit riitä siihen. Sen jälkeen tilanne ei ole suuresti muuttunut. Samaa kuulee edelleen.

Itse törmään aiheseen yleensä jonkun toisen projektin kautta. Asiakas on harkitsemassa uutta ERP-järjestelmää, järjestelmäintegraatioita uudistetaan tai suunnitellaan lisää, liiketoiminta-aluetta tai prosessia kehitetään tai niihin suunnitellaan uusia mittareita, jne. Silloin Master Data Management ei ole ainoastaan pieni lisä, joka tehdään pääprojektin rinnalla, vaan siitä tulee yhtäkkiä niin iso kakku että se siirtää varsinaisen hankkeen aikataulua kunnolla eteenpäin.

Mieti siinä sitten kuinka sanat laitetaan johtoryhmälle. Toisaalta on projektin tuomat aikataulupaineet – vuoden päästä pitäisi olla uusi ratkaisu käytössä. Toisaalta tiedät ettei siitä tule hyvää jos ei ensin ratkaista master dataan liittyvät puutteet.

Tällaisissa tilanteissa allekirjoitan Tietoviikossa olevan huolen siitä, miten MDM argumentoidaan businessjohdolle. Meneillään oleva hanke on ”myyty” sillä että saadaan tietyt hyödyt jollain kustannuksilla tietyssä ajassa. Nyt pitäisi sitten kertoa että, jotta ne hyödyt saadaan, niin tarvitaan vuosi lisäaikaa ja iso kasa lisää rahaa. Yleisesti ottaen kyseenalaistan väittämää, että Master Dataan liittyvää työtä olisi vaikea perustella liiketoimintalähtöisesti. Jos ei pysty löytämään vakuuttavat argumentit sille miksi pitäisi investoida aikaa ja rahaa, niin olisi kai järkevä kysyä ensin itseltään toisen kerran miksi tähän ollaan ryhtymässä.

Jos hanke on lähtenyt liikkeelle jostain operatiivisesta tarpeesta, niin nämä argumentit kyllä löytyvät. Jos ei löydy, niin vaarana on että projekti epäonnistuu joka tapauksessa. Tällöin johto toimii viisaasti kun hylkää investointiehdotuksen. Jotenkin tässä on sama ilmiö kun CRM-hankkeissa. Jotkut projektit onnistuvat sen takia, että tiedetään tarkalleen mitä halutaan saavuttaa. Toiset taas epäonnistuvat siksi, että ne lähtevät liikkeelle ”yleishyödyllisinä hankkeina” missä korostetaan CRM:n yleisiä etuja.

Vertailkaa huviksenne CRM:n ja MDM:n yleisiä etuja. Niissä on aika paljon samankaltaisuutta.

Kovin paljon ehdotuksia tehokkaasta MDM-lähestymistavasta ei ole näkynyt. Tiedän, että aihe on ajankohtainen monessakin yrityksessä, joten kerron, mikä meillä on toiminut.

Kuten kaikissa hankkeissa, ensin pitää tietää mitä haluaa korjata, jotta voi valita oikean korjaussarjan. Joitakin caseja ajaa raportointitarve: nykyjärjestelmä ei salli yhdistää lukuja eri järjestelmistä koska referenssidata on epäyhtenäistä. Toisissa hankkeissa tarve on enemmän operatiivisten tietovirtojen hallinnassa.

Koska eCraftin toiminta on paljolti operatiivisen toiminnan tehostamista, on itselleni tullut vastaan lähinnä jälkimmäisiä. Siinä on meillä toiminut seuraava lähestymistapa:

Operatiivisen MDM:n voi saada hyvin pitkälle kuntoon vaikka sitä lähestyy otsikolla Integraatiostrategia, joka on useimmille tutumpi aihe. Operatiivisella tasolla MDM-ongelma syntyy (karrikoiden) siitä, että integrointeja tehdään eri kehitysprojekteissa ristiin rastiin ja jokainen projekti keksii omat tavat toteuttaa niitä. Tai sitten siitä ettei niitä tehdä ollenkaan.

Ota homma haltuun keskitetysti, tuo peliin kunnollinen integraatio-alusta ja minimoi liikkuvat osat, niin saat tietovirrat hallintaan.

Minimoi liikkuvat osat:

• Yksi mahdollisimman kattava ja vakaa rajapinta (sisään ja ulos) per sovellus.
• Yksi integraatiokokonaisuus per tietotyyppi (entity), eli käytännössä niin että esim. asiakastietoa voivat ’tilata’ monet järjestelmät, mutta tieto kulkeutuu kaikille yhtä aikaa saman integraation kautta, kun jotain muuttuu lähdejärjestelmässä.
• Yksi ylläpito- ja jatkokehitysvastuu sekä keskitetty valvonta koko hommalle.

Lisää sivumausteeksi hanketyypistä riippuen vaihtelevat määrät datan puhdistusta, koodaus-systematiikkaa, hallintamallien rakentamista ynnä muuta. Tarvitset ne joka tapauksessa, jos aiot käyttää hienoa termiä MDM. Mutta saavutat 80 % arvosta jo sillä, että saat aikaiseksi hyvän integraatioiden suunnittelun, toteutuksen ja ylläpidon.

Yleisteemamme on vähemmän softaa. Siis vähemmän päällekkäisiä, vaikeaselkoisia tai mammuttimaisia ohjelmistoja.

Useimpien käyttäjien työruudulla on kymmenen eri ohjelmaa, usein enemmänkin. Näitä hän joutuu käyttämään saadakseen viikottaiset työnsä tehtyä. Käyttämisen ilo on tästä järjestelmäviidakosta kaukana.

Kerromme, kuinka järkeistät ja ratkot liiketoimintahaasteitasi vähemmällä softalla.

Aiomme kirjoittaa mm. seuraavista aiheista:

• Käytettävyys – helppokäyttöisyys ja turhan karsinta.
• Keskeisten prosessien tehostaminen:
  -   Myynti on tuotantoprosessi (1, 2, 3) – lean-näkökulman tuoma muutos ja työkalut.
  -   Palveluprosessi lean-näkökulmasta – mitä uutta lean-ajattelu tuo.
  -   After-sales ja elinkaaren hallinta – mistä on fiksut ratkaisut rakennettu.
  -   Hankintaprosessi – mitä olemme oppineet tehokkaasta hankinnasta.
• Master data management (1) – vähemmän mutta fiksummin.
• Simplicity! – yksinkertaistaminen ja sujuvoittaminen.
• Sosiaaliset mediat – ohjelmistoja nekin, joten tarkastelemme niitä tuottavuuden ja yksinkertaistamisen näkökulmasta.

Jaamme niitä kokemuksia ja ajatuksia, joita meillä on tehokkuuden lisäämiseksi.
Vähemmän softaa, enemmän tuottavuutta.

Uusi mantramme on, että haluamme vähentää softan määrää.

Päällekkäisten ohjelmistojen ja informaation määrä aiheuttaa tehottomuutta – vaikka vuosikymmeniä on sanottu, että IT nostaa tuottavuutta. Blogissa on paljon muita kirjoituksia siitä, miten tämä tehottomuus ilmenee, mutta nostanpa esiin vielä uuden aiheen tähän liittyen.

Mitä suurempi organisaatio, sitä tavallisempi on tilanne missä muuttuva tieto – esimerkiksi asiakastieto – ei päivity kaikille sitä tarvitseville. Ihmiset toimivat erillisten järjestelmien ja ristiriitaisen tiedon varassa. Tähän apua tarjoaa Master Data Management (MDM). Näin olemme saaneet kuulla analyytikoilta.

Yksinkertaistettuna master data management on aika selvä: Yksi järjestelmä on master jollekin tiedolle, mikä tarkoittaa, että tietoa luodaan ja ylläpidetään siinä. Muissa järjestelmissä tämän tiedon muokkaaminen ei ole sallittu. Kun muutoksia tehdään master-järjestelmässä, ne kulkeutuvat edelleen muihin järjestelmiin, missä samaa tietoa käsitellään ja täydennetään. Tarkempia määritelmiä ja materiaalia on Internetissä paljon, joten ei sen enempää itse aiheesta.

Asiakkaamme puhuvat MDM-haasteesta nyt paljon. Se on selvästikin kuuma aihe.

Ongelma on, että käytännössä tämän yksinkertaiselta kuulostavan asian toteuttaminen on varsin haastavaa. Amerikkalaiset konsulttikirjoitukset puhuvat asioista, jotka ovat kaukana omien asiakkaidemme tarpeista.

Itse näen ison riskin, että jos lähdetään tekemään Master Data Management hanketta by the book, niin se karkaa käsistä ja irtautuu reaalimaailmasta. Perustamalla lisää komiteoita ja tuottamalla valtava määrä dokumentteja, joissa on paljon nuolia sinne tänne, kenenkään työ ei vielä helpotu! Tarvitaan konkreettisempaa lähestymistapaa joka tuottaa parannusta jo kuukausien kuluessa, ei vuosien.

Kirjoitan aiheesta jatkossa lisää. Onko kenelläkään blogin lukijoista omia kokemuksia tehokkaasta MDM-lähestymistavasta?