Kuolema koodiavaimille!

Peter Benson, ECCMA:n puheenjohtaja, kirjoittaa juuri ilmestyneen uutiskirjeen pääkirjoituksessa jotain tähän suuntaan:

”Katalogien manuaalinen tuottaminen on tulossa nopeasti tiensä päähän. Katalogit korvautuvat ymmärryksellä, että tuotteiden toimittajat ovat vastuussa oikean ja riittävän informaation toimittamisesta asiakkailleen. Katalogisteista (en lähtenyt kääntämään) on tulossa data quality managereita, jotka auttavat käyttäjiä määrittelemään tarpeensa ja hoitavat prosessia, jolla tietoa pyydetään toimittajilta ja valmistajilta.”


Mystinen koodiavainOlen asiasta aivan samaa mieltä. Tyyppikoodiavaimet, joiden tulkinta on ollut tuotepäälliköiden, tarjousinsinöörien, komponentti-insinöörien ym. teknisten asiantuntijoiden vastuulla, ja joiden avulla on pystytty visualisoimaan erittäinkin laaja tuotetarjooma yhdellä A4-sivulla, on toimitusketjun automaation kannalta mahdoton malli. On ihan mielenkiintoista, että lähes kaikissa ERP-järjestelmissä on nykyään MYYNTI-konfiguraattori mutta prosessin vastinparia ei ole – eli siis mikään järjestelmä ei osaa OSTAA konfiguroitavia tuotteita. Ennen kuin tämä toiminnallisuus kehittyy ja standardoituu (mikä voi olla toimivaa 2020-luvulla) on pakko palata takaisin yksiselitteisiin nimikkeisiin.

Kuva on napattu Agilentin komponenttikatalogista

ATK:ta

Hankintatoimelle alkaa olla paljonkin tarjontaa ostoprosessin automatisointiin katalogien pohjalta, mutta se edellyttää, että yksi kataloginimike on yksiselitteinen ja sillä on hinta. Tämä palauttaa ongelman taas ytimeen – miten ostaja tai pidemmälle vietynä järjestelmä osaa tunnistaa oikean nimikkeen. IT-järjestelmät osaavat hoitaa jo sen, että kun toimittaja lähettää laskun, voidaan todentaa automaattisesti onko hinta sitä mitä on sovittu. Kun toimittaja lähettää tuotteen, vastaanottavassa päässä osataan tunnistaa erilaisilla tekniikoilla, että kyseessä on juuri tilattu tuote. Mutta onko tuote OIKEA? Se voidaan päätellä vain, mikäli siitä on osattu kysyä oikeat ja riittävät tiedot ja toimittaja on ne toimittanut.

Jotta nimikkeet perustettaisiin järjestelmiin oikein, on aika monessa yrityksissä siirrytty keskittämään nimikkeiden perustaminen erityiselle asiantuntijatiimille. Loppukäyttäjille annetaan lomake, jossa he kertovat mitä nimikettä tarvitaan ja workflow ohjaa pyynnön asiantuntijoille, jotka lähtevät selvittämään lisätietoa nimikkeestä. Koska toiminta globaaleissa yrityksissä on hektistä ja kaikki toimii IT-järjestelmien varassa, ovat nimiketiimit yleensä jatkuvassa back logien puristuksissa, nimikkeitä ei saada perustettua niin nopeasti kuin liiketoiminta odottaa.

Nimikehallintatiimi eturiviin

Minun mielestäni nämä kaikki esitetyt ongelmat voidaan poistaa kun katsotaan koko kokonaisuutta hieman eri lailla. Nimikehallintatiimi voisi pro-aktiivisesti luoda tarjoomaa niin ostoon (mikäli tavarantoimittajat eivät sitä tee jo valmiiksi) kuin myyntiinkin esivalmistelemalla nimikeinformaatiota ja tallentamalla niitä virtuaalisiin nimikevarastoihin. Toisin sanoen puretaan niitä toimittajien koodiavaimeen pohjautuvia katalogeja portfolioiksi ja kehitetään tiedonkeruulogiikkaa. Osto / ja myynti voisivat käydä nimikevarastosta tutkimassa mitä nimikkeitä olisi tarjolla helposti ja pyytää niitä operatiivisiin järjestelmiin tarvittaessa. Nimikehallintatiimin rooli nousisi huimasti pelkästä reaktiivisesta käsikassarasta tarjooman kehittäjäksi ja konsultiksi, ostotoiminta voidaan automatisoida, tarjoussuunnittelu nopeutuu, tehokkuus nousee ja kaikki voittavat.

Tässä taas kuukauden saarna.

Jukka

PS. insinöörit jäivät varmaan miettimään mikä tuo koodisarja oli – no se on ihan oikea pneumatiikkaventtiili (ASCO).

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 –

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 –

MDM – Back to Basics – 1/2

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.

Wikipedia kuvaa MDM -termiä kattavasti ja antaa hyvän kuvan asioista, joita MDM-termiin liitetään. Kuitenkin MDM-asian ydin voidaan kiteyttää hyvin lyhyesti: yrityksen yhteisen totuuden hallinta jonkin informaatiokäsitteen osalta. MDM käsitteenä sisältää tällöin kaikki ne yrityksen prosessit, mallit ja järjestelmät, joita vaaditaan tämän tavoitteen saavuttamiseksi. Tavoite jakautuu nähdäkseni keskeisesti kahteen pääalueeseen; yrityksen yhteisen informaation hallintaan ja sen jakamiseen muille järjestelmille. Järjestelmänäkökulmasta näihin kahteen alueeseen kiteytyy myös MDM-prosessia ylläpitävien järjestelmien tekniset ja toiminnalliset vaatimukset.

Masters of Data Management

Kokonaisuudessaan kyseessä on silti laaja asia, joka vaatii erityisesti yrityksen informaation käsittelyprosessien määrittelyä, sekä yrityksen informaatiomallien ja niitä tukevan järjestelmäarkkitehtuurin määrittelyä.  Keskityn tässä artikkelissa järjestelmänäkökulmaan ja sen vaatimuksiin.

Ytimessä

MDM:ssä ei ole kyse massiivisesta uudesta IT-hankkeesta. Yksinkertaisimmillaan MDM-järjestelmän roolin voi ottaa jokin yrityksessä jo olemassa olevista järjestelmistä, kun samaan aikaan määritellään prosessit ja toimintatavat, miten informaatiota yrityksessä tullaan hallitsemaan. Prosessimuutoksella informaation hallinta keskitetään yhden järjestelmän ympärille, ja sillä varmistetaan yhteisen totuuden säilyminen. Tyypillisesti tämä on mahdollista vain hyvin yksinkertaisissa tapauksissa.

Todellisessa tilanteessa yrityksessä on käytössä monia samaa informaatiota käsitteleviä järjestelmiä, jotka on integroitu keskenään. Yhdelläkään järjestelmistä ei välttämättä ole selkeää master-järjestelmän roolia, vaan informaatiota käsitellään ja uusia informaatioelementtejä perustetaan kaikissa eri järjestelmissä. Mark Allen kuvaa tilannetta ja siirtymistä MDM-toimintatapaan varsin havainnollisesti omassa blogikirjoituksessaan. MDM:n ydin, kuten aikaisemmin kuvasin, on ajatuksena monille varmasti hyvin selkeä ja helposti ymmärrettävä, mutta tällaiseen malliin siirtyminen junan liikkuessa täyttä vauhtia ei ole kovin yksinkertaista, kuten myös Mark blogissaan kuvaa.

Kun tietomalli ei ole oikein...

"...mikään nykyisistä, tiettyyn tarkkaan tarpeeseen tarkoitetuista järjestelmistä ei sovellu ottamaan haltuun määritellyn kaltaista informaatiomallia."

Vaikka periaatteessa MDM-järjestelmän roolin voi ottaa jokin yrityksen olemassa olevista järjestelmistä, on se käytännössä harvoin mahdollista. Tästä syystä haluan nostaa esille MDM-järjestelmän tiettyjä keskeisiä vaatimuksia, jotka yleisesti ohjaavat keskitetyn, erillisen MDM-järjestelmän perustamiseen.

Informaatiomalli. Kun pyritään yhteen yhteiseen totuuteen yrityksessä, sinne halutaan nostaa mahdollisimman kattava yhteinen kuva, jota voitaisiin sitten ylläpitää yhdessä paikassa. Sitä varten määritellään se yhteinen informaatiomalli, jota halutaan vaalia. Se suurin yhteinen nimittäjä. Tähän halutaan nostaa mahdollisesti monia eri näkökulmia. Tyypillisesti se johtaa siihen, että mikään nykyisistä, tiettyyn tarkkaan tarpeeseen tarkoitetuista järjestelmistä ei sovellu ottamaan haltuun määritellyn kaltaista informaatiomallia. Tällöin MDM-järjestelmän yhdeksi tärkeäksi vaatimukseksi nousee dynaaminen informaatiomalli, johon voidaan määritellä juuri sellainen tietorakenne, kuin yrityksen vaatimukset edellyttävät.

Integrointi. Koska MDM-järjestelmä on kaiken keskiössä, sen pitää integroitua kaikkiin muihin järjestelmiin, joissa master-informaatiota tarvitaan. MDM-järjestelmän pitää kyetä vastaanottamaan dataa muista järjestelmistä ainakin järjestelmän rakentamisvaiheessa, sekä myös välittämään tietoa muihin järjestelmiin järjestelmän käytön aikana. Tästä syystä monet tuotteet, jotka on aiemmin tunnettu integroitavuudestaan, on nyt nostettu esille MDM-tuotteina. Integroinnin ohella on syytä tarkastella erityisesti datan hallintaan ja rikastamiseen vaadittuja ominaisuuksia.

Data Governance. Aihe on mielestäni syytä nostaa MDM-järjestelmän keskeisten vaatimusten joukkoon. Informaation laadun varmistaminen vaatii informaation hallinnan osalta käsittelyprosessien, omistavan organisaation ja hallintaoikeuksien määrittelyä, sekä toisaalta informaation laatua valvovien sääntöjen määrittelyä. Näiden avulla voidaan varmistua siitä, että informaation käsittely tapahtuu aina tietyllä tavalla, tiettyjen siihen valtuutettujen henkilöiden toimesta, ja että muutokset dataan ovat sääntöjen valossa oikeellisia.

Nämä kolme muodostavat keskeisimmät vaatimukset MDM-järjestelmälle, jonka avulla voidaan tukea yrityksen MDM-hanketta.

Jatketaan tästä ensi viikolla…

– Janne Maijanen –