ERP – Toiminnan kehittämistä vai vallan väline?

Kumma juttu, mutta vieläkin jatkuvasti törmää yrityksissä globaaleihin ERP – hankkeisiin, jotka eivät ole menneet niin sanotusti putkeen. Yksi yhdistävä piirre on se, että niitä ajetaan pelkästään talousraportoinnin ohjaamana. Sanomattakin on selvää, että mitä suurempi yritys, sitä enemmän kassavirtaa liikkuu ja sitä suuremmat riskit, jos tähän ei ole läpinäkyvyyttä. Toimitusjohtaja sekä talousjohtaja, jotka istuvat yrityksen rahakasan päällä, nostavat luonnollisesti prioriteettilistalla ylimmiksi suoraan taloushallintoon liittyvät IT-investoinnit.

Sivuraide

Sivuraiteille ajellaan siinä vaiheessa, kun ajatellaan, että konsolidoituja talousraportteja tehokkaasti tuottavan järjestelmän pitäisi ohjata kaikkea toimintaa yrityksissä: tuotesuunnittelua, toimitusprojektien hallintaa, valmistuksenohjausta, resurssointia, kunnossapitoa tai logistiikka. Lopputulos on yleensä se, että talousraportointi ja pörssitiedotteet saadaan kyllä nopeasti ulos, mutta luvut niissä raporteissa eivät näytä hyviltä!

Operatiivisesta toiminnasta onkin yhtäkkiä tullut kankeaa ja tehotonta. Organisaatioon on syntynyt satoja uusia exceleitä, joilla toiminnan kyvykkyyttä yritetään ylläpitää. Tuotannon ja johdon väliin syntyy välikerros, joka purkaa exceleitä ERP-dataksi, jotta saadaan kulmahuone myhäilemään. Nämä excel–gurut työskentelevät kroonisessa ylikuormassa, koska virallisen organisaation ja toimintamallien mukaan heitä ei ole edes olemassa.

Herää kysymys, ovatko nämä kaiken kattavat ERP-järjestelmät enemmänkin vallan välineitä kuin oikeasti yrityksen toiminnan tehostamis-instrumentteja. Jos onnistuu rollaamaan ”oman” järjestelmän globaaliin käyttöön, niin silloin on yrityksessä korvaamaton ja palkkaneuvottelut ovat helppoja. Ja jos saadaan samalla tapettua muutama vanha järjestelmä ja niiden pääkäyttäjät ulkokehälle, niin kyllähän siitä tulee kingi olo.

Mistä suorituskyvyn parantaminen

Joskus pitäisi pysähtyä miettimään, kannattaisiko mieluiten satsata järjestelmiin, jotka optimoivat nimenomaan operatiivista toimintaa, josta ne luvut syntyvät. Raportoidaan vaikka kärjistetysti hieman huonommin, mutta parempia lukuja; luulisin, että loppupelissä omistajat kiittävät enemmän.

No globaalien standardoitujen järjestelmien etuna on tottakai se, että toimintatapojen kopiointi eri yksiköihin on ”helppoa” (koska vaihtoehtoja ei ole), ja onnistuessaan se johtaa selkeään ja läpinäkyvään johtamiseen. Resursseja on helppo siirrellä lokaatiosta toiseen tarpeen mukaan, koska toimintamallit ovat kaikkialla samat ja näin saadaan globaali synergia käyttöön. Mutta saavuttaako yritys suhteellista liiketoimintaetua kilpailijoihinsa onkin sitten eri kysymys.

Peruskysymys

Edelleen ollaan sen peruskysymyksen äärellä, voiko yksi järjestelmä hoitaa kaiken? Tai onko taloushallinto yrityksen strateginen funktio? Pankkimaailmassa varmaankin kyllä, mutta valmistavassa yrityksessä – tuskin. Lähes todistettua faktaa on myös se, että ERP sellaisena kun se tänä päivänä käsitetään on yrityksille MUST, mutta ei tuo niille kilpailuetua – varsinkin jos kaikilla on sama ERP. Kilpailuetu ja erinomainen tehokkuus luodaan ns. kakkostason järjestelmillä, joilla tehostetaan tuotesuunnittelua, tuote- ja tarjoomanhallintaa, tuotannonsuunnittelua ja –ohjausta, laadunvalvontaa sekä sisälogistiikan optimointia. Näiden lisäksi kun varmistetaan, että operatiivisissa järjestelmissä käytettävä data on hyvässä kunnossa, niin jo alkaa firmalla mennä lujaa; henkilöstö on tyytyväistä, asiakkaat antavat referenssitarinoita ja pörssikurssi nousee … ja mikään edellämainituista ei tyypillisesti kuulu ERP-implementointi scopeen. Siksi PLM, PIM, MES, MOM, WMS, MDM Rules!

PDM Preacher

Minun Datani!

Saimme vieraaksemme erään maailman arvostetuimmista dataguruista, tohtori Peter Aikenin, joka esitteli teesejään Betonia vai vaahtokarkkia – seminaarissa. Sehän ei ole tällä foorumilla uutinen, että betoninen perusta liiketoiminnalle ja varsinkin sähköiselle liiketoiminnalle on hyvälaatuinen data. Ehkä enemmän ajatuksia herätti datan omistajuus, se että omistajuutta on harvoin määritelty. Ja jos onkin, omistaja ylisuojelee dataa niin, että sen hyödyntäminen käy omistajan oman siilon ulkopuolisessa liiketoiminnassa mahdottomaksi.

Aikenin tunnetuimpia teesejä on Monetizing Data Management – eli miten kuvaat dataan liittyvät haasteet ja mahdollisuudet niin, että kulmahuonekin ne ymmärtää.

Tietosiilojen purkaminen – elämän ja kuoleman kysymys

Pysäyttävimmän esimerkin Aiken kertoi kuitenkin kategoriassa ”not yet quantified”. Hän oli saanut joitakin vuosia sitten toimieksiannon USA:n puolustusministeriöltä (DoD = Department of Defence). He halusivat selvittää, miten voidaan tunnistaa itsemurhiin taipuvat sotilaat mahdollisimman ajoissa.

Amerikassa oli noteerattu, että Vietnamin sodassa kuoli 50.000 sotilasta, mutta sotaretken jälkeen 120.000 ex-sotilasta kuoli oman käden kautta.

Nyt Irakin sodan jälkeen haluttiin oppia ja vaikuttaa riskitekijöihin etukäteen. Sotilaita lähdettiin ”nimikkeellistämään” erilaisten tietojen perusteella: fyysinen kunto, psyykkinen kunto, koulutus, rikosrekisteri, ym. ennen armeijaan tuloa, miten nuo parametrit muuttuivat armeijan aikana ja sen jälkeen. Ongelmana oli, että tietoja oli talletettu useaan eri tietovarastoon, jotka olivat eri osastojen vastuulla.Never let you Buddy fight alone

Kaikki suojelivat omaa tietoaan eikä kukaan uskaltanut julkistaa niitä yhteisen analyysin aikaansaamiseksi. Koko projekti oli jäädä paikoilleen, kunnes Aiken marssi puolustusministerin puheille ja selitti asian. Puolustusministeri kutsui kenraalikunnan palaveriin ja jyrähti: ”Tämä on minun dataani – kuka on sitä mieltä, että tätä dataa ei saa käyttää itsemurhien estämiseen?” Yhtään kättä ei noussut.

Kuka dataa huoltaa?

Hieman kevyempi esimerkki datan huonosta käytettävyydestä oli mielenkiintoinen havainto siitä, mitä IT-alan opiskelijoille opetetaan. Missään koulussa tai kursseilla ei opeteta olemassa olevan datan huoltoa. Yleensä ensimmäiseksi opetetaan, miten perustan uuden tietokannan. No tästä seuraa tietysti se, että kaikki perustavat omia tietokantojaan kun pääsevät yrityselämään ja siitähän se tiedon siiloutuminen alkaa.

create new data baseData ja yrityksen strategia

Risto Silvola Konecranesilta on väitöskirjaansa varten tutkinut suomalaisten yritysten Master Data Management -käytäntöjä ja strategiaa. Hän havaitsi, että joka kymmenes suuri suomalainen yritys on ottanut datan osaksi yritysstrategiaa samalle tasolle kuin asiakkuuden hallinta, tuotehallinta, tilaus-toimitusprosessi tms. perinteinen avainprosessi. Peter Aiken säesti, että jenkeissä tilanne on sama. Valistustyötä vielä riittää, koska tosiasia on se, että jos yritysjohto julistaa yrityksensä strategiaksi IoT:n tms. digitalisaatio-aiheisen viestin, on se todella pahasti ristiriidassa käytännön kanssa, ellei dataa nähdä strategisena asiana ja siihen kuuluvana resurssointina. Ilmeisesti nykyisen johtajasukupolven pitää vaihtua ennenkuin data ymmärretään samanlaisena tase-eränä kuin kiinteä omaisuus. Vai pitäisikö itseasiassa kirjanpitolaki muuttaa?

– koska datalle ei ole määritelty taseessa omaa tiliä – sitä ei siis ole oikeasti olemassa!

Harvasta yrityksestä löytyy johtajia, jotka nousisivat framille ja julistaisivat: Tämä on minun dataani. Vastaan siitä, että se on niin hyvässä kunnossa, että koko yrityksen ja verkoston toiminta on laadukasta ja kannattavaa.

Tässä hieman pohdittavaa kesälaitumille.

  • PDM Preacher

 

Vaaleanpunaisia omenia

Peter Benson heitti ECCMA:n kesäkuun uutiskirjeessä mielenkiintoisen esimerkin hierarkisten luokittelujen ongelmista. Vaikka yritykset orjallisesti noudattaisivat UNSPSC – luokittelua tai jotain muuta standardia, joka pohjautuu hierarkisuuteen, törmätään vääjäämättä jossain vaiheessa hankaluuksiin. Sama nimike näyttäisi yksiselitteisesti kuuluvan useampaan luokkaan.

Peterin esimerkki oli omenat – ei se puhelimiakin valmistava IT-yritys, vaan tämä ihmiskunnan historiassa merkittävää roolia näytellyt hedelmä, jota Aatami ja Eeva maistelivat ja joka Newtonin päähän pudotessaan mullisti käsityksen maailmankaikkeudesta.  Siis ruokakaupan hyllyiltä löytyvä tuote ”Pink Lady® apple”, joka on UNSPSC luokittelussa määritelty kahdeksaan (8) eri luokkaan:

Pink lady apple UNSPSC luokat

Pink lady apple UNSPSC luokat

Tuon omena-esimerkin voi käydä lukemassa originaalina täältä, hyvä tarina: ECCMA June Newsletter

Esimerkki on loistava siinä mielessä, että siinä esiintyy lähes kaikki tyypilliset nimikeluokittelussa tehtävät virheet. Ensinnäkin Pink Lady® on rekisteröity tavaramerkki – siis brandi. Sitä ei kannata sotkea esimerkiksi termiin, joista muodostuu yrityksen sanasto.

Viime aikoina olemme tehneet useampia sanastoprojekteja, joissa brandi-nimien ohella on tullut vastaan erilaisia apusanoja, kuten ylä, ala, taka, sivu, oikea, vasen. Pahimmillaan sanastossa on termejä tyyliin: ”1. vasen tukivarsi”, ”2. vasen tukivarsi”, ”3. oikea tukivarsi” … Tämä generoi tietysti kielenkääntäjälle töitä, kun kaikki variaatiot käännetään jopa kymmenille kielille.

Loputon suo

Omena-esimerkissä luokittelutekijöihin on lisäksi sotkettu viljelysmenetelmä sekä jälkiprosessointi, joka johtaa siis jäädytettyihin orgaanisesti viljeltyihin omeniin sekä jäädytettyihin muuten vaan viljeltyihin omenoihin. Koska ryhmä ei vielä kerro, onko omenat jäädytetty kokonaisina, viipaloituina vai murskattuina tarvitsemme todennäköisesti vielä lisää ryhmiä. Tällä mallilla suo on loputon. Konepajamaailmassa tyypillisin luokittelusynti on sekoittaa nimikkeen käyttökohde ja funktio – siis esim. KIINNITYSLAIPPA vs. MOOTTORIN KIINNITYSLAIPPA, KYTKIMEN KIINNTYSLAIPPA, NOSTURIN NH15 KIINNITYSLAIPPA jne

Hierarkisuus sinänsä on erittäin ymmärrettävää, koska ihmiset ja varsinkin me insinöörit olemme tottuneet jäsentämään asioita hierarkisesti. Tietojärjestelmät eivät hierarkisuutta tarvitse, joten näin tietointensiivisenä aikana olisi hyvä yhdistää nämä molemmat asiat. Tietomallin luonnissa siis pyritään välttämään kiinteitä hierarkioita, jottei synny duplikaatteja, mutta käyttäjälle pitäisi pystyä asiat tuomaan tarpeen mukaan erilaisten näkymien ja polkujen kautta.

ISO 8000 mukainen kuvaus

ISO 8000 mukainen kuvaus

Tässä hypätään nyt hieman idealistiselle puolelle. Koko nimikkeistön attributisointi kyseiseen tasoon on monelle yritykselle tekemätön paikka. Tietotekniset työkalut ja algoritmit kyllä työssä auttavat mutta puhutaan joka tapauksessa megalomaanisesta työmäärästä, jos nimikemäärä on satoja tuhansia.

Suunta kyllä kannattaa pitää mielessä ja aloittaa esimerkiksi myytävistä omista tuotteista, toimittajat nimittäin vastaavat ostokomponenttien jalostamisesta, mikäli haluavat niitä myydä 😉

PS: En siis mitenkään halua kyseenalaistaa UNSPCS-luokittelun käyttämistä – päinvastoin, mutta sitä kannattaa käyttää omiin tarpeisiin järkevästi soveltaen.

Tässä kesäkuun saarna. Eiköhän lähdetä nauttimaan kotimaisista, UNSPSC-vapaista, kirkkaan punaisista mansikoista.

-PDM Preacher

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 –

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ä.