Mistä tuote alkaa?

Törmäsin taannoin erääseen konsulttiin, joka oli tekemässä asiakkaalleen määritystä, miten tuotteen elinkaaren aikaiset kustannukset ja tuotot pitäisi laskea. Tämähän on asia, joka kaikkia tietysti kiinnostaisi – mikä on tuotteen kannattavuus koko sen elinkaaren aikana?

Yllättäen ja pyytämättä

Siinä sparratessa törmättiin aika nopeasti kysymykseen, tiedämmekö me milloin tuotteen elinkaari alkaa. Väittäisin, että erittäin harvoin tehdään yksiselitteistä päätöstä, että nyt aloitetaan uuden tuotteen suunnittelu ja tästä alkaa tuotekehityskustannukset juosta. Useimmiten tuote-/tuotteistuspäätös syntyy vähitellen ja asiakkaiden kanssa tehty protoilu tai todellinen toimitusprojekti ”liukuu” tuotteeksi yllättäen ja pyytämättä. Varsinkin nykyään vallalla oleva kokeilukulttuuri vie tällaista perinteistä tuotekannattavuuslaskentakulttuuria hieman eri polulle.

Nokian kulta-aikana siellä toimittiin näin: Perustettiin tuoteprojekti, joka hoiti uuden tuotteen suunnittelun, valmistuksen ramp-upin, markkinoinnin jne. alusta loppuun. Näin pystyttiin yksiselitteisesti raportoimaan tuotekohtainen kannattavuus. Se, että tuoteprojektit saivat itsenäisesti päättää tuotteesta,  käytettävästä teknologiasta ja komponenteista, palveli hyvin tuotteen elinkaarenhallintaan liittyvää raportointia. Mutta: syntyikö yritykselle hyvä tuoteportfolio, joka reagoi nopeasti ja joustavasti markkinoiden vaatimuksiin? Tähän kysymykseen on nyt vuosien jälkeen saatu vastaus.

Tuote vs. tuotealusta

Nykyään puhutaan paljon tuotealustoista, tuotearkkitehtuurista ja tuoteportfolioista. Tässä yhteydessä käytetään aina esimerkkinä VAG-konsernia (hyvä esimerkki edelleen, riippumatta luovasta päästömittausteknologiasta). Scoda Octavian tietyn mallin elinkaari pystytään todennäköisesti määrittämään tarkasti, mutta pitääkö kannattavuutta tarkasteltaessa ottaa huomioon itse tuotealustaan tehdyt investoinnit? Mikä on oikea taso kertoa Yhtiön omistajille, oliko ko. tuote meille kannattava vai ei? No, ehkä tämä on hieman epärelevantti asia meille Suomessa, koska tällä tasolla tuotteita tekeviä yrityksiä on meillä vain kourallinen.

Auto vai pyörillä kulkeva ajoneuvo

Ketterien menetelmien kautta tullut käsite MVP – Minimum Viable Product – tuo vielä uuden haasteen koko tuote-käsitteelle. Kuvan esimerkissä tehdään perinteisesti auto, joka on helposti ymmärrettävä tuote, jonka aikaansaamiseksi on projektisuunnitelma ja -budjetti. Elinkaari on helppo määrittää. Toisessa esimerkissä tehdään pyörillä kulkevaa kulkuneuvoa. Jos halutaan takaisinpäin selvittää tuotekustannukset, niin seurataanko skeitti-laudan vai auton kustannuksia, ja ketä se oikeastaan kiinnostaa, jos heti rullalaudasta saakka tekeminen on ollut kannattavaa.

mvp

PLM Rules

Meillä suurin osa tuotteista syntyy siis liukumalla yhden tai useamman asiakasprojektin tuotoksena. Koska kukaan ei välttämättä tiedä – lähtiessään tarjoamaan asiakkaan ongelmaan ratkaisua – tuleeko tästä tuote vai ei, kannattaa jo ensimmäisetkin projektit toteuttaa tuotemaisesti niin, että osat nimikkeellistetään, otetaan revisiohallinta käyttöön, jolloin huomoidaan mahdollinen uudelleenkäyttö… kerroinko jo, että toimitusprojektitkin kannattaa dokumentoida PLM-järjestelmään….

-PDM Preacher

 

Digitalisoinnin pullonkaulat

Olen viime aikoina päässyt tutustumaan syvällisemmin tuotetiedonhallintaan kaupallisissa – sekä inbound että outbound – prosesseissa. (Tuotteellahan on tyypillisesti kolme toisistaan riippumatonta elinkaarta – tuotteen synnyttämiseen liittyvä elikaari, jota tyypillisesti PDM/PLM-järjestelmillä ratkaistaan, sitten on tämä kaupallinen elinkaari, jossa tuotetta ostetaan ja myydään, sekä viimeisenä tuotteen käytönaikainen elinkaari, johon kohdistuu huolto ja palvelutapahtumia). No nyt siis keskitytään kaupalliseen vaiheeseen. Markkinatalouden kannalta tämä on tietysti kaikkein kiinnostavin vaihe – siinähän syntyy kaupallista transaktiota, jolla koko kansantalous pyörii. E-business käsitteenä syntyi vuosituhannen vaihteessa, ja siitä lähtien näitä kaupallisia transaktioita ollaan paremmalla ja huonommalla menestyksellä automatisoitu, sähköistetty tai digitalisoitu, miksi sitä nyt milloinkin on haluttu kutsua. Raha liikkuu sähköisesti ja jopa enenevässä määrin virtuaalisesti. Laskujen lähetys ja hyväksyntä on digitalisoitu jo kattavasti. Ostolaskut tulevat ostajien ja tilausehdotusten tekijöille ennalta määritellyn workflown mukaisesti ja kiertonopeus paranee. Prosessissa vaan on yksi mutta; laskujen sisällön validointi.

Mitä löytyy laskuriviltä?

Mitä niillä laskuriveillä yleensä on? No yllätys, yllätys, pääsääntöisesti tuotteita ja nimikkeitä. Ne ovat kuitenkin laskuilla pelkästään tekstirivejä, joiden validointiin ei ole mitään automatiikkaa. Pahimmillaan (tai parhaimmillaan) kuvaus on 40 merkkiä pitkä, joka on satunnaisesti lyhennetty toimittajan järjestelmästä – ole nyt sitten varma, että laskulla on juuri ne tuotteet, joita olit aikonut ostaa.

Excel rules…

Tätä ongelmaa on yritetty parantaa kehittämällä katalogipohjaista ostoa, jossa myyjä ja ostaja sopivat, millä tarjoomalla kauppaa käydään ja millä hinnoilla. Kun set-up saadaan kuntoon myyjän ja ostajan välillä, homma rokkaa ihan mukavasti. Ongelmakohta siirtyy nyt myyjien eli toimittajen puolelle. Sähköisiä ostojärjestelmiä on markkinoilla useita ja kaikki haluavat tuotetiedot tietysti oman mallinsa mukaisesti. Pieni toimittaja joutuu mahdollisesti tuottamaan omasta tarjoomastaan kymmeniä erilaisia Excel-tiedostoja, joiden ylläpitäminen hintapäivitysten osalta on helposti tekemätön paikka. Kun ostajayritys vaihtaa ostojärjestelmänsä, joutuu koko toimittajaketju päivittämään Excel-kataloginsa uuteen formaattiin. Lopputulos on tietysti se, että niitä sähköisiä katalogeja ei ole saatavilla ja osto tapahtuu kuten ennenkin – ainahan ne ostolaskut voidaan skannata ja hyväksyä sähköisesti.

Rikkaat tuotetiedot framille

Koska markkina pitää huolen siitä, että erilaisia ERP- ja sähköisen kaupankäynnin järjestelmiä tulee olemaan, on tähän väliin syntynyt palveluntarjoajia, integraattoreita, jotka konvertoivat transaktiotiedot järjestelmien välillä. Ongelma tässä on se, että nämä ovat tyypillisesti point-to-point -ratkaisuja. Tämän päivän tarve kuitenkin on, että ostajalle on tarjolla ”kaikki maailman tuotteet”, joita hän voi vertailla ominaisuuksien ja hintojen perusteella. Kun jokin tuote, tuoteryhmä tai toimittajan tarjooma kiinnostaa, ostaja voi käynnistää sopimusneuvottelut ja lopputuloksena syntyy sopimus määritellystä katalogista hintoineen omaan ostojärjestelmään. Jotta eri toimittajat voisivat päästä mukaan ekosysteemiin, pitää tuotetiedon julkaisukynnyksen olla erittäin matala. Tämän jälkeen alkaa normaali markkinatalous purra. Toimittajan on pakko rikastaa tuotetietoaan, jotta se päätyy ostajien näkyville ja lopputuloksena kaikki hyötyvät – ostaja tietää mitä ostaa, kuluttaja tietää mitä saa ja myyjä myy sitä mitä ostetaan.
Tällä saarnalla 2015 käyntiin.

-PDM Preacher