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

Tuotetieto on nyt Roimasti tärkeämpää!

Kesälomien alla pääsin mukaan mielenkiintoiseen järjestelyyn, jossa tuotetiedonhallintaa vietiin mukaan isompaan kokonaisuuteen. Jo kesän aikana on lamppuja syttynyt monessa paikassa, kun on ymmärretty, mitä hyvä tuotetieto merkitsee varastonhallinnassa,valmistuksenohjauksessa ja IoT:ssä – myyntitoiminnoista puhumattakaan.

Sisälogistiikkaongelmia kymmeniä vuosia ratkaisseet kaverit heräsivät siihen tosiasiaan, että he paikkailevat tuotetietoja logistiikkaprosesseissa (milloin milläkin työkalulla SQL:stä jeesusteippiin), ja olisi mieletön etu, jos niihin ongelmiin puututtaisiin jo yläjuoksulla, kun tieto lähtee liikkeelle.

ERP ratkaisee kaiken?

Toisaalta surullista todeta, kuinka paljon edelleen eri järjestelmät toimivat omissa siiloissaan, omalla datallaan. Isot ERP-toimittajat eivät tätä asiaa ratkaise yhtään paremmin –  ehkä jopa huonommin. Transaktiohin ja konsernin konsolidointiraportointiin kehitetyt järjestelmät käsittelevät liiketoimintaobjekteja ainoastaan em. draivereiden pohjalta. Ne jättävät aukon syvällisempään asiakastiedon käsittelyyn, lattiatason työnohjaukseen tai tällä foorumilla erityisen kiinnostuksen kohteena olevaan tuoteinformaatioon. Jos isot nimeltä mainitsemattomat ERP-toimittajat samalla tekevät täydentävien järjestelmien integroinnin hankalaksi teknisesti tai lisenssipoliittisesti, ei tästä hyödy kukaan – ei ainakaan asiakas.

siilot

Omakin ymmärrys on jo lyhyellä matkalla laajentunut Roimasti ja uusia kolmikirjaimisia lyhenteitä, joita aiemmin en ollut kuullutkaan, on noussut kahvipöytäkeskusteluihin. Yllättäen ERP-scopen ulkopuolelta löytyy paljon erillistoimintoja, joihin tarvitaan omia järjestelmiä – on mommia (MOM), messiä (MES), vemssiä (WMS), ym. mutta yllättäen ja pyytämättä kaikissa järjestelmissä käsitellään tuotetietoa ja se tulee ”jostain” milloin missäkin muodossa, tai jos ei tule, niin naputellaan itse.

Varastopaikka vs. varastointiperuste

Todella mielenkiintoinen havainto on se, että nimikkeen varastopaikka on tyypillinen ERP- attribuutti – tämän kaikki ymmärtävät. Mutta mikään olemassaoleva järjestelmä ei tallenna esimerkiksi varastointiperustetta – eli onko tuote räjähdysherkkä tai helposti syttyvä, mitkä ovat varastointidimensiot, ABC-luokka tai esim myyntiaika. Näitä tietoja tarvitaan, jotta varastologistiikkaa päästään optimoimaan! Varastopaikkaa joudutaan, tai sitä kannattaa, vaihtaa monistakin syistä. Jos esimerkiksi jonkun tuotteen myyntiaika on päättymässä, kannattaa tuote sijoittaa toimituskeskuksessa lähelle lähtöporttia. Joten jos nimikkeestä tiedetään vain varastopaikka, joku joutuu tekemään paljon turhaa työtä uuden varastopaikan määrittelemiseksi.

tuotetietomaster

Olen saarnannut tuotetiedon roolista liimana eri prosessien ja järjestelmien välillä pitkään. On mahtavaa huomata, mikä potentiaali sillä todellisuudessa on! ICT Standard Forumin julkaisema informaatioarkkitehtuurimalli alkaa purra myös käytännössä. Viime aikoina olen jo kuullut julistuksia, että yritysintegraatioon tai järjestelmähankkeeseen mennään data edellä, mikä kuulostaa aika vallankumoukselliselta tietohallintojohtajien suusta kuultuna.

Ja lopuksi Mattia ja Teppoa siteeraten: Kaiken takana on nai… eikun siis…  nimike!

-PDM Preacher

Miksi tuotteet eivät käy kaupaksi?

Suomen valmistavan teollisuuden piirissä ainoastaan 6%:ssa yrityksiä tuotehallinnasta vastaa myynti-/ markkinointiosasto, kun taas 72% yrityksistä hoitaa tuotehallinnan suunnittelu- tai tuotanto-organisaatiossa (loput eivät hallitse tuotteita käytännössä mitenkään).

Luvut selvisivät Modultekin teettämässä tutkimuksessa, jossa selvitettiin suomalaisen valmistavan pk-teollisuuden nimike-tietoisuutta.

tuotehallinna vastuut

Olisiko tässä yksi syy Suomessa jo kuudetta vuotta kestäneeseen taantumaan? Asiakastarve ja  tuotetarjooma eivät kohtaa. Tämä ei ollut itselleni valitettavasti mikään uutinen. Asiaa on tullut seurattua sen verran läheltä jo pitkään. Suomalainen insinööriosaaminen kohdistetaan helposti valmistusprosesseihin ja sinänsä ihan kiitettävästi nykyään myös tuotesuunnitteluun ja erilaisiin tuotealustoihin, mutta leimaavaa koko kulttuurille on se, että lähestyminen on aina tekniikka/teknologia-lähtöistä – intohimona ei ole asiakasarvon lisääminen.

Digitalisaatioon vielä matkaa

43% yrityksistä hallitsee koko tuotetiedon ERP:ssä. Kun tiedetään ERP-järjestelmien kyvykkyys tuotetiedon kuvaamiseen (siis pahimmillaan 40 merkkiä) niin voidaan todeta, että tuotetiedon välittäminen asiakkaille sähköisesti suoraan järjestelmistä ei ole mitenkään innostavaa. Tuotetiedon digitalisaatioon on meillä vielä pitkä matka.

th_järjestelmät

Sinänsä positiivista oli havaita, että nimikkeitä hyödynnetään yrityksen sisäisissä toiminnoissa kattavasti myynnistä elinkaaripalveluihin ja jopa 69% yrityksistä on ymmärtänyt nimike- ja tuotetiedon laadun merkityksen tärkeäksi.

Tuote vs. Strategia?

Kaikkein hälyttävin huomio tutkimuksessa oli se, että yritysten toimitusjohtajat eivät pääsääntöisesti halunneet keskustella tuoteasioista ollenkaan, heille koko tuote-domain tuntuu vastenmieliseltä ja haastattelut delegoitiin aina suunnitteluosastolle. Tässä todennäköisesti päästään koko kansantaloudellisen ongelman ytimeen – johto ei ymmärrä mikä merkitys tuotetarjoomalla on yrityksen kilpailutekijänä, ja/tai miten tuotehallinta liittyy yrityksen strategiaan, ja että tuotehallinta on jotain muutakin kuin tuotekehitystä.

Myynti myy asiakkaille – se on selvää ja tuotekehitys kehittää tuotteita, sekin on ymmärrettävää: Mutta jostain syystä se, että myynnin pitäisi myydä juuri niitä samoja tuotteita, joita tuotekehitys kehittää, ei hahmoteta. Näin kirjoitettuna tuntuu aika naiivilta kommentilta, mutta miten sitten on selitettävissä se, että tyypillisessä yrityksen sovellusarkkitehtuurissa tuotekehityksen järjestelmistä (PDM/PLM) ei ole mitään kytkentää myyntijärjestelmiin !!

Täällä saarnalla kohti kesää.

– PDM Preacher

PS. Jos tämä nimiketutkimus kiinnostaa niin ota yhteyttä, tulen mielelläni yritykseesi kertomaan asiasta syvällisemmin.

PLM to Everyone (?)

PLM-markkinaa pitkään seurannut, alan auktoriteetin asemassa oleva CIMdata julkaisi vuosittaisen markkinakatsauksensa. Positiivista on tietenkin se, että markkina on kasvanut kaikilla osa-alueilla. Vaikka kokonaismarkkina 33,8 miljardia dollaria on kaukana ERP-markkinakoosta, on se kuitenkin jo sen verran merkittävä, että todistaa tuotehallinnan tärkeyden yrityksissä.

Itse olen muutamassa blogissani jo kritisoinut PLM-termin raiskausta. CIMdata reagoi aiheeseen joskus vuosituhannen vaihteessa määrittelemällä CAD-markkinavoimien varastaman PLM-termin rinnalle käsitteen cPDm – Collaborative Product Definition Management, joka siis kuvaa varsinaista tuotetiedonhallintaosuutta PLM-markkinassa. cPDm ei ole mitenkään yleisesti asettunut käyttöön, mutta määritelmä on ok. Eli jos minä väitän, että tuotetiedon ytimessä on nimike, CIMdata väittää, että PLM:n ytimessä on cPDm – aineettoman omaisuuden hallinta (Managing Intellectual Assets), joka koostuu seuraavista alueista:

  • Tuoteinformaation ja prosessien hallinta (Management of Product Information and Processes):   Workflow, Vaulting, Content, Document Management
  • Visualisointi ja yhteistyön tukeminen (Visualization and Collaboration)
  • Tuoterakenteet (Product Structure)
  • Konfiguraation ja muutosten hallinta (Configuration and Change Management)
  • Tuotestrategian suunnittelu (Strategic Product Planning)
  • Projektisalkun hallinta (Project and Program Management)
  • Vaatimustenmukaisuus ja ostotoiminnan tukeminen (Compliance and Sourcing)

cPDm:n osuus koko markkinasta on 21.6% ja suurimman osan markkinakakusta vievät edelleen erilaiset CAD-työkalulisenssit sekä systeemi-integrointityö.

Pieni pettymys itselle oli havainto, että perinteiset sovellusalueet jylläävät edelleen: auto- ja lentokoneteollisuus sekä elektroniika- ja muu mekaniikkavalmistus muodostavat suurimman osan sekä volyymistä että kasvusta.

Uudet haastajat kuten prosessi-, lääke- tai elintarviketeollisuus eivät ole kasvaneet lainkaan viimeisen 3 vuoden aikana – noilla alueilla jäljitettävyys ja vaatimuksenmukaisuus ovat kuitenkin todella merkittävässä roolissa ja laitosinvestointiprojekteissa ostot eli tuotetiedon keruu toimittajilta.

Tämä tietysti herättää pohdintaa, onko mainituilla teollisuudenaloilla jo niin vakiintuneet manuaaliset käytännöt, vai onko siellä asiakaskohtaisia räätälöityjä ratkaisuja, vai miten asiat tyyppillisesti hoidetaan? Tai onko toisaalta autoteollisuuden tarpeisiin perinteisesti kehitettyjen PLM/PDM/cPDm-ratkaisujen tuotteistettu toiminnallisuusvalikoima niin kaukana esimerkiksi elintarvikeyritysten todellisista tarpeista, että niitä ei ole nähty järkeväksi lähteä sovittamaan, vaan järjestelmäkehitys on aloitettu valkoiselta paperilta?

Tulevaisuudessa uusiksi PLM-konseptin hyödyntäjiksi CIMdata nostaa rahoitus- ja vakuutusmarkkinat. Tähän on helppo yhtyä, ainakin jenkkinäkökulmasta. Siellähän herättiin kohtuullisen kylmään todellisuuteen loppusyksystä 2008, kun havaittiin, että asuntolainojen jäljitettävyys ei ollut kenelläkään hallinnassa.

No tästä on hyvä herättää aktiivinen keskustelu, miten lukijat näkevät PLM-sovellusten laajentumisen uusille toimialoille ja mikä toisaalta estää?

– PDM Preacher

Nopeampia hevosia?

Kaikki ovat varmaan kuulleet tarinan Henry Fordista liittyen tuotekehitysfilosofiaan. Ford aikoinaan totesi, että jos hän olisi lähtenyt kyselemään asiakkailtaan mitä he tuotteiltaan toivoisivat, niin vastaus olisi ollut: ”nopeampia hevosia”.

Tämä nousi taas mieleen, kun lueskelin suomalaisten metalliteollisuusyritysten vuosikertomuksia. Niissä järjestään – oli sitten kyse pörssiyhtiöstä tai yksityisestä yrityksestä – toimitusjohtajat julistavat, että ”tuotekehityksemme toimii täysin asiakastarpeiden pohjalta”. En ajatellut ottaa tähän vertailevaksi esimerkiksi jo kliseistä Applea iPadeineen, iPhoneineen tai iPodeineen vaan ryhdyin tuumimaan asiaa toiselta puolelta.

Tuotteita vai tuotoksia

Olen aikaisemminkin kirjoittanut asiasta ja todennut, että suomalaiset yritykset ovat kasvaneet maailmalla ja erottautuneet kansainvälisistä mega-brändeistä nimenomaan siinä, että ne ovat tehneet joustavasti asiakaskohtaisia tuotteita. Nyt voidaan alkaa filosofoimaan sillä, ovatko toimitukset asiakkaille oikeasti tuotteita vai asiakasprojektien tuotoksia.

Yli 25 vuotta suomalaista engineering-toimintaa läheltä seuranneena uskallan väittää, että Suomessa on kohtalaisen vähän puhtaita tuotekehitysorganisaatioita tai yleensä tuotepohjaista teollisuutta. Jos otetaan viitekehykseksi Porterin arvonluontistrategian kolme vaihtoehtoa, joista voi valita vain yhden: Tuote- ja teknologiajohtajuus, Operatiivinen etevyys, Asiakkuuden hallinta, niin aika harva yritys voi vakaalla rintaäänellä sanoa olevansa tuotejohtaja – meillä on kyllä jonkin verran teknologiajohtajuusyrityksiä esim. paperi- ja kaivosteollisuuden alueella, mutta niissä liiketoiminnoissa ollaan vielä entistä kauempana tuotteista. Porterin valinnoista ylivoimaisesti suurimmalle osalle menestyviä suomalaisia yrityksiä istuu Asiakkuuden hallinta strategisena fokuksena.

Asiakkuuden hallinnassa ei ole mitään väärää – päinvastoin, se on globaalisti pienelle toimijalle ainoa järkevä malli. IT-miehet alkavat nyt heti pohtia, että pitäisikö sitten CRM-järjestelmän olla arkkitehtuurin keskiössä – no periaatteessa kyllä.

Siirretäänpä katse markkinoilla oleviin CRM-järjestelmiin. En aio tehdä mitään nelikenttää järjestelmistä (sorry), mutta kyllähän valmiit järjestelmät on tehty puhelinmyyntiyrityksille, joilla potentiaalisia asiakkaita on kymmeniä tuhansia ja myyjiä melkein saman verran. Funnel management hoituu ja raportteja saadaan prospektiseurantaa varten ja jos joulukortteja sattuu menemään samalle asiakkaalle useimpiakin, niin sehän ei ole niin suuri ongelma.

Mistä asiakasratkaisunhallinnan järjestelmä

Mutta onko tämä nyt se ympäristö, mikä tukee suomalaisen, asiakaslähtöisiä vaativia ratkaisuja toimittavan yrityksen toimintaa  globaaleilla markkinoilla? Tuskinpa on.  Jos taas toisaalla PLM-järjestelmät on kehitetty standardituotteita toimittavan yrityksen tuotekehitystarpeisiin, niin suomalaisella teollisuudella on ongelma – sopivia IT-järjestelmiä ei löydy.

Asiakkuuden hallintastrategiassa kilpailutekijänä on ”parhaat ratkaisut”. Asiakasratkaisuun sisältyy paitsi tuotekonfiguraatio, myös palvelut ennen ja jälkeen toimituksen sekä tietysti yhteys itse asiakkaaseen. Tämän päivän IT-järjestelmien ratkaisupankista (PLM, CRM, ERP) löytyy huonosti asiakasratkaisubusinesta tukevia ratkaisuja ja kokonaisuus joudutaan yhä edelleen rakentamaan useasta erillisestä sovelluksesta. (No onneksi löytyy myös asiakastarpeita kuuntelevia IT-palveluyrityksiä.)

PLM, CRM, ERP ?

Pieni on kaunista

Jos ja kun kuitenkin halutaan kehittää nopeampia hevosia, kannattaa oikeasti miettiä myös kokonaisarkkitehtuuria näistä tarpeista. Yksi järjestämä ei ratkaise ongelmia, mutta toisaalta mitä useampia järjestelmiä, sitä monimutkaisempi ja kalliimmin ylläpidettävä kokonaisuus. Mutta kun hoidetaan tärkeimmät asiat eli tarjooma ja asiakkaat fiksusti ja muistetaan, että talousraportointi pitää saada nopeasti aikaan, niin kyllä siitä hyvä tulee, eikä välttämättä maksa paljon.

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 –

Mitä nimike maksaa?

Ensin tulee tietenkin tarkentava kysymys: ”Mitä nimikettä tarkoitat?”.  Sen jälkeen kysymykseen vastataan 100% varmuudella joko kertomalla myyntihinta tai ostokustannukset. Jos puhutaan omavalmisteisesta nimikkeestä, ollaan jo askeleen tarkempia ja lasketaan materiaali- ja työkustannukset – voipa joku jyvittää työkalukustannuksiakin nimikkeelle.

Nimikekustannus nähdään perinteisesti vain suorina kustannuksina. Tietojärjestelmien aikakaudella pitäisi ymmärtää myös se, että jos nimikettä yleensä voidaan hyödyntää suunnittelussa, valmistuksessa, logistiikassa tai "Nimikenääri"palveluliiketoiminnassa, merkittävä painoarvo prosessin tukemiseen tulee nimikkeen tiedoista – informaatiosta eli siis viimekädessä datasta, jolla se on eri järjestelmiin kuvattu.

Vanha kunnon Metalliteollisuuden keskusliitto MET (rest-in-peace) sivusi varovasti aihetta jo aivan 80- ja 90-lukujen taitteessa. Erilaisten tutkimusten pohjalta päätyivät siihen, että nimike maksaa 1500 mk vuodessa. Siis siksi, että se on järjestelmissä; sillä on varastopaikka, jonka vuoksi se pitää inventoida jne.

Ja hinta nousee…

Hieman pidemmälle menivät jenkeissä Zenger ja Cafone tutkimuksessaan ”Economic Justification for Part Number Reduction During Product Design”. Siinä lähtökohtana oli DFMA –suunnittelu (Design for Manufacturability and Assembly) ja se, kannattaako mieluummin käyttää kalliimpia  monikäyttöisiä komponentteja, jotka toiminnallisuudellaan korvaavat esimerkiksi viisi halvempaa komponenttia.

He lähtivät suunnittelemaan kustannusrakennetta, joissa perinteisten materiaali-, työvoima- ja työkalukustannusten oheen määriteltiin kuusi kustannuskategoriaa:

  1. Tuote- ja prosessisuunnittelu
  2. Tuotanto
  3. Kuljetus ja varastointi
  4. Laatu
  5. Tiedonkäsittely
  6. Yleiskustannukset

Jokainen osasto siis arvioi omista lähtökohdistaan kustannukset uudelle nimikkeelle . Lopputuloksena päästiin eräässä keskisuuressa konepajassa nimikkeen yleiskustannukseen $9437.

No, totuus on varmaan jossain tuossa välissä ja riippuu erittäin paljon yrityksen toimintamallista ja käytettävistä järjestelmistä – jotkut ERP-järjestelmät vaativat nimikkeelle 500 attribuuttia, jotkut selviävät vähemmällä.

Puhutaan kuitenkin sen verran merkittävästä kustannuksesta, että on ihme, ettei sen hallintaan ole löytynyt kiinnostusta. Vai olisiko kyse työkalujen tai menetelmien puutteesta.

Tieto on tuote

Paras tapa lähestyä asiaa on mielestäni hyväksyä se, että jokaiseen yrityksen nimikkeeseen liittyy toinen nimike – informaationimike. Sitä voidaan käsitellä aivan samoin menetelmin kuin fyysistä nimikettä eli perinteisin tuotehallinnan keinoin.  Myös tiedolla on elinkaari, hankinta- ja ylläpitokustannukset sekä erilaisia laatuvaatimuksia. Kustannukset elävät elinkaaren mukana, ja kun tieto käsitellään tuotteena, voidaan myös helpommin asettaa tavoitteita tiedon kustannusten pienentämiseksi tai vastaavasti lisäämällä investointia tiedon laatuun saadaan fyysisen nimikkeen kustannuksia pienennettyä.

Miltä kuulostaa, onko Teidän yrityksessänne mietitty tietoa tuotteena? Vai onko nimikeinformaation kustannuksia yleensä noteerattu?

Jukka

PS. Jos edellinen blogi Keisarin uusista raporteista tuntui pelkältä tsoukilta, voi saman asian  lukea tieteellisemmässä kontekstissa esim. Peter Aikenin esityksistä .