Tervetuloa tuotetiedon koottuihin selityksiin!

Ohessa kokoelma matkan varrelta mukaan tarttuneista tarinoista ja ajatuksista tuotetiedon ja tuotealustan hallintaan, modulaarisuuteen, verkostoihin, geneerisiin tuoterakenteisiin ja tiedonhallinnalla johtamiseen liittyen massaräätälöinti ja lean filosifioita hyödyntäen.

Tietoyhteiskunnassa eläessämme ymmärtämällä luomme innovaatiomme.

Asiakas on meille tärkeä...vai onko

Olemmeko tottuneet ajattelemaan markkinoita tai asiakkaita oikeasti tarpeeksi kurinalaisella tavalla? Tiedämme joidenkin tuotekehitysprojektien onnistuvan ja toisten epäonnistuvan, mutta todellisten syiden kaivaminen esille tuntuu olevan liian monimutkaista ​​ja syyt meille arvaamattomia. Tyydymme helposti tilaan, jossa meidän mukamas tarvitsee vain tuottaa tuoteet ja asiakkaat tulevat niitä ostamaan. Ja jos eivät osta, niin sehän on vaan asiakkaiden ymmärräksen puutetta...
Yritykset keskittyvät tyydyttämään omia tavoitteitaan ennemmin kuin asiakkaidensa todellisia näkökulmia.
Asiakaskohtaisuus. Asiakkaan huomioiminen. Asiakaslähtöiset varioivat tuotteet. - Tuttuja sanoja, jotka on helppo lisätä esityksiin ja osavuosikatsauksiin, mutta joiden toteuttaminen "aikuisten oikeasti" ei aina olekaan niin helppoa kuin pensselillä maalattu ylätason tavoite. Mitä siis asiakaslähtöisellä kehityksellä tarkoitetaan? Mitä sen toteuttamiselta vaaditaan? Mitä asiakaslähtöinen kehittäminen onkaan syönyt sisäänsä?

Ennen kuin päästään itse teeman saloihin, pitää ottaa askel taaksepäin ja heittää kehiin päivän haaste:
Perinteinen vesiputousmallinen tuoteperhelähtökohtainen tuotekehitysprosessi on pahinta työntöohjausta, jossa alussa hetkellisten asiakastarpeiden perusteella pyritään ennustamaan projektien tuotosten istuvuutta muuttuviin markkinoihin.
Toisin sanoan tehdään pitkiä, isoja tuotekehitysprojekteja, joissa projektien alussa määriteltyjä, sen hetken asiakaskyselyiden vastauksia, pyritään viemään ja viestimään osajoukolta toiselle kuin rikkinäisessä puhelimessa konsanaan. Ei hyvä.

Nykypäivän asiakas- ja tehokkuusvaatimuksiin päästäkseen varioivia tuotteita valmistavien yritysten onkin pyrittävä suoraviivaisesti siirtymään kohti tuotteen tietomalliin pohjautuvaa tiedon hallintaa ja Lean / massaräätälöinti filosofiaan pohjautuvaa tuotekehitystä (Lean Product Development (LPD)). Yksi osa kyseiseen tasoon pääsemiseksi onkin todellisen asiakaslähtöisen kehittämisen liittäminen osaksi kokonaisvaltaista tuotekehitysprosessia.

Tutkimusten mukaan todennäköisempi syy tuotekehitysprojektien epäonnistumiselle on tuotteiden kohdistuksessa tapahtuvat virheet kuin tuotteen tekniset epäonnistumiset. Tähän liittyen onkin kummallista, miten jokaiselta yritykselta löytyy kyllä tuotteen teknisen suunnittelun prosessit kuvattuna, mutta vain harvalta tuotteen tarvevaatimusten hallintaan suunnatut prosessit.

Täytyy kuitenkin muistaa, että uuteen tähdättäessä motivaattorina voi toimia:
  • teknologia-lähtöinen uudistaminen,
  • asiakaslähtöinen uudistaminen tai
  • tilaisuuteen tarttuminen.
Kuinkakohan monta noista voidaan nykypäivän nopeusvaatimusten mukaisesti tunnistaa ja toteuttaa ilman asikaslähtöisen kehityksen hallintaa?

Lopettakaa myyminen, aloittakaa kuunteleminen.

Myykää ominaisuuksia, ei teknisiä ratkaisuja.
Mitä asiakaslähtöiseen kehitysprosessiin sitten sisältyy? Mitä minun tulee huomioida? Ohessa neljä seikkaa, jotka itse nostaisin esille ja joiden huomioiminen jokapäiväisenä prosessina on erittäin tärkeää, jotta asiakas saadaan oikeasti osaksi tuotekehitysprosessia.

1. Mene ulos
a) Asiakastarpeet löytyvät vain ymmärtämällä asiakasta, ei firman seinien sisältä. Lähesty asiakasta, keskustele, haista ja ymmärrä.
b) Muista, että asiakastarpeet voidaan jakaa kahteen ryhmään: subjektiivisiin ja objektiivisiin. Näistä subjektiiviset vaatimukset ovat asiakkaiden esittämiä toiveita, kun taas objektiivisia voidaan pitää asiakkaiden todellisina tarpeina. Pelkkä kuunteleminen ja kysyminen ei siis riitä.
c) Vältä "rikkinäistä puhelinta". Mitä hyötyä on, jos projektipäällikkö kuuntelee asiakasta, mutta itse toteuttaja ei moista ole koskaan nähnyt? Pyri lähentämään suunnittelijaa ja asiakasta lähemmäksi toisiaan ymmärryksen kasvattamiseksi.

2. Määrässä ei ole voimaa
Asiakaslähtöisen kehityksen tavoitteena ei ole tuottaa suurta määrää valintoja, vaan modulaarisuuden kautta oikeat asiat oikealle kohderyhmälle. Luokittele, ryhmittele, kohdista. Tätä kutsuttaneen tuoteportfolion hallinaksi.

3. Reagoi oikeisiin asioihin
Asiakaslähtöinen kehitys vaatii koko organisaation osaamisen tuomista esille. Kyse ei ole myynnin prosesseista tai tuotekehityksen konseptointivaiheesta. Onnistuneeseen asiakaslähtöiseen kehittämiseen pitää eri tahojen pystyä tuomaan esille oman osaamisalueensa tiedot. Näiden kautta asiakaslähtöisen kehitysprosessin tehtävänä onkin nostaa yrityksessä oleva informaatio ymmärrykseksi, oikeiksi valinnoiksi. Osaamiseksi. Reagoinniksi oikeaan aikaan, oikeaan asiaan.

4. Opi jatkuvasti
Asiakastarpeiden hallinta on jatkuva prosessi siinä missä tuotteen tekninen jatkuva parantaminenkin. Oma JP / ECM prossessi tulee olla olemassa.

Näin tällä kertaa. Itse keinoihin ja tekoihin tuonnempana, mutta sitä ennen...
Asiakaslähtöisellä kehittämiselle, ja ennen kaikkea sen osaamiselle, on tilaisuus päällä. Mielestäni sen hallinta voi oikeasti nostaa yrityksen edelläkävijäksi. Toisaalta asia ei ole niin helppoa kuin kuvitellaan. Pelkkä asiakaslähtöisyyden maininta tai satunnainen myynnin palaute ei vielä tuo asiakasta todelliseen prosessiin. Asiakaslähtöinen kehittäminen vaatii omistautumisen ja ammattilaisensa, mutta se voi palkita paremmin kuin arvaattekaan.

Toiseksi. Olen merkinnöissäni tullut korostaneeksi, ettei tärkeintä ole liike, vaan ymmärrys suunnasta. Niin nytkin. Pahempaa kuin olla huomioimatta asiakasta on kuvitella ymmärtävänsä sitä.

Kärpäsestä härkänen

En ymmärrä. Taas meni pieni pää ihan sekaisin... Olen tämän viikkoista bloggausta varten yrittänyt selvittää mitä tarkoittaa Master Data Management? Paljon puhutaan, mutta miten olla tai päästä MDM:n edelläkävijäksi? Mitä itseasiassa termillä tarkoitetaan? Mitä pitää tehdä, jotta kolmikirjaiminen lyhenne tuottaa oikeasti menestystä? Ja ennen kaikkea mikä ei ole Master Data Managementia? Jouduin suohon...

Jo lyhyt googlauksen hakutulosten tarkastelu todisti, että Master Data Managementilla voidaan tarkoittaa ihan mitä tahansa tiedon hallintaan liittyvää perusasiaa, kuhan siihen vaan lisätään mukaan sana "laadukas". "Yrityksemme tarjoaa teille laadukkaaseen master datan hallintaan tähtääviä palvelua" löytyy aika monelta sivulta. Tällöin puhutaan: datan haltuunotosta, jalostamisesta, muokkaamisesta tai laadun varmistuksesta. Data voi olla myyntidataa, tuotantodataa, asiakasdataa, sisäistä dataa, ulkoista dataa, sitä dataa tai tätä dataa. Mutta tämän jälkeen se on laadukasta ja sillä saavuttaa merkittäviä liiketoiminnallisia hyötyjä. Tiesittehän, että nykypäivänä tiedolla on suuri merkitys yrityksenne tehokkuuteen... Ai jaa, ihan tosissaanko!!!

Ja sitten löytyy artikkeleita ja blogikirjoituksia, joissa kaikissa kerrotaan asiantuntevasti, mitä Master Data Management on. Ja paljon näyttää löytyvänkin. Ongelma vaan tuntuu olevan samaa sarjaa kuin modulaarisuuden ja Lean määritysten kanssa. Asiasta on niin monta ympäripyöreää kirjoitusta, että on mahdoton tietää / löytää kirjoitusta, joka oikeasti haaastaisi miettimään ja toisi esille ne tekijät, joiden avulla MDM:llä saavutettaisiin todellista kilpailuetua. Vai mitä mieltä olette? Ymmärrän sen, että jos yrityksessä on tiedon hallinta täysin retuperällä, on perusteista lähdettävä liikkeelle, jotta päästään mukaan keskinkertaisuuden massaan, mutta miten sieltä nousta muiden yläpuolelle? Voiko MDM:ssä edes olla muita parempi? Miten MDM istuu muiden kolmikirjaimisten tiedon hallinnan lyhenteiden soppaan? Tarvitseeko se oman järjestelmänsä voi voiko se olla osa esimerkiksi PDM:ää? Pitääkö sen olla osa PDM:ää?


Eipä siis tullut vastauksia lyhyen tutkimisen pohjalta, joten käännyin tutun tahon puoleen ja aloin selailemaan Modultekin blogin kirjoituksia. Itseasiassa juuri Modultekin kautta olen ensimmäistä kertaa törmännyt Master Data Management -käsitteeseen, joskus 2006-2007.

Päädyin lueskelemaan Maijasen Jannen MDM-blogikirjoituksia. Janne listaa kolme MDM-järjestelmän perusvaatimusta, joihin on helppo yhtyä:

Integrointi. Ilman muuta. On kai järjetöntä kuvitella, että olisi yksi paikka, jota kaikki käyttäisivät tiedon lukemiseen ja käsittelyyn. MDM-järjestelmän täytyy olla integroitu käyttäjien "työpöydälle". Sen pitää olla käyttäjän taustalla oleva musta möykky, joka omii ja jakaa kaiken tiedon, silloinhan se on datan master paikka. Tätä varten tarvitaan myös standardien hyödyntämistä ja ymmärrästy, jotta data saadaan integraatioissa kulkemaan työkalujen ja käyttöliittymien välillä.

Laadunvarmistus. Ilman muuta. Huonolla tiedolla ei tee yhtään mitään. Tiedon pitää olla laadukasta. Pitää tietää kuka sen omistaa, millä prosessilla sitä käsitellään ja mitä siltä vaaditaan. mistä data tulee ja mihin se menee. Prosessit pitää olla kunnossa (ja tiedossa). Niiden avulla datasta luodaan informaatiota.



Tähän väliin välikommentti: Yksi asia, jota en ole Master Data Managementistä ikinä on ymmärtänyt on puheet omista, erillisistä MDM-organisaatioista, joiden tehtävä on vahtia, valvoa ja käsitellä dataa, jotta siitä saataisiin master dataa. Sallitaan siis organisaation muuten tuottaa roskaa, jota sitten erikseen muokataan kuntoon. Kyllä nykypäivänä master datan laatuvaatimukset pitää pystyä leipomaan prosessien sisään esimerkiksi SixSigman avulla. ja takaisin...



Informaatiomalli. Jee! Ilman muuta. Jotta master data voidaan pitää master data kokonaisuutena, pitää olla kattava yhteinen näkemys, rakenne, tietomalli siitä mitä data itseasiassa on. Mitä dataa haluamme koota. Mitä dataa tarvitsemme, jotta siitä voimme prosessien kautta tuottaa informaatiota. Informaatiota, jonka avulla voimme tuottaa tulosta, palvella asiakkaitamme.

Vielä kun lisätään, ettei Master Data Management itseasiassa taidakaan olla ytimeltään datan laadun parannusta, vaan informaation tehokasta hyödyntämistä ja tuottamista tiedon hallinta prosessien kautta, alan ehkä päästä kärryille. Tuota omaa MDM-järjestelmän viittausta nyt en heti osta. Maailmassa, jossa pilvien kautta ollaan menossa ja pyrkimässä kevyempiin ratkaisuihin, pitäisikin nyt olla oma MDM-järjestelmänsä PDM:n päälle, koska PDM ei kykene MDM:ää hoitamaan. Master Data Management ei siis kuitenkaan ole Product Data Managementia...kö?

Jaa...

Mitä mieltä siis itse olen... Yksinkertainen on kaunista. Datasta on luotava yritykselle informaatiota. Informaatiota tulee hallita. Pitää tietää mitä tarvitaan. Pitää olla prosessi mitä tehdään. Ja sen mitä tehdään pitää olla laadukasta. Ei kai se sen vaikeampaa ole. Se onko tämä nyt sitten sitä Master Data Managementia, johon tarvitaan omat järjestelmät, tiimit, projektit ja konsultit... en tiedä. Ehkä kärpäsestä ollaan tekemässä härkästä ja unohtamassa mitä oikeasti pitikään tehdä.
__________________________________________________________________________________

Asiasta toiseen... Onkohan Modultek tuotteistamassa tuotteen tietomallia? Pragmaattinen nimikelaatu... Tietomalliajattelua... Nimikeinformaation kokonaislaatuajattelu ja nimikeinformaation subjektiivinen laadun hallinta... Kuulostaapa tutulta... Joku tosin voisi olla sitä mieltä, että viisas tiedon hallinta, jossa tiedetään kuka tarvitsee ja mitä, olisi ihan perusolettamus yleiselle tiedon hallinnalle ja ehkäpä myös Master Data Managementille...

pragmaattinen = perehtynyt, viisas, kokenut

Mistä on pienet moduulit tehty (osa 2)

Pahoittelut. Viimeisestä kirjoituksesta on ehtinyt vierähtää tovi, mutta taas mennään...

Palataan takaisin lupaamaani modulaarisuuden maailmaan. Edellisellä kerralla (Mistä on pienet moduulit tehty) heitin kehiin haasteen väittämällä että:
Tehokkaan tuotetiedon hallinnan saavuttamisen suurin este on yritysten moduulikäsitteen ymmärtämättömyys.
Itse moduulaarisuudesta ja moduuleista päästiin perkaamaan tilanteeseen, jossa moduulin pitäisi siis olla:
Standardi rajapinnallinen osakokonaisuus, joka toteuttaa niin teknisesti kuin ominaisuuslähtöisesti yhden erilaisen toiminnon.
Tähän väliin ennen itse asiaa välikommentti. Keskustelin nimittäin muutama viikko sitten eräässä konferenssissa Vaasassa arvostamani konsultin ja PLM ammattilaisen Uutun Ollin kanssa modulaarisuudesta. Olli puhisi samaan ääneen kanssani siitä miten vaikeaa tuntuu olevan ymmärtää, että moduuli voi ja pitää olla muutakin kuin pelkkä tekninen käikäle. Muistakaa ne ominaisuudet...

Ja sitten takaisin. Eli koska mielestäni modulaarisuuden ja moduulin käsitteet antavat liian suuren tulkinnanvaran eivätkä haasta käyttäjäänsä tarpeeksi, olen itse modulaarisuudesta puhuessani korostanut seuraavaa kolmea lisäsääntöä:

1. Moduulin on pyrittävä olemaan mahdollisimman pieni kokonaisuus
Tämä on sinällään helppo ja yksinkertainen sääntö ja tulee jo aikaisemmasta moduulin määrittelystä. Jos ja kun moduulin on toteutettava yksi toiminnallisuus, ei se hirveän iso kokonaisuus tuotteessa voikkaan olla. Pari kommenttia kuitenkin:

Ainakin niissä keskusteluissa, jotka omalle kohdalleni ovat osuneet, tuntuu olevan yllättävän vaikeaa hahmottaa, mikä on yksi toiminnallisuus tuotteessa. Olen enemmän kuin yhden kerran joutunut keskusteluun, jossa joku on aivan tosissaan väittänyt, että traktorin koottu hytti on moduuli ja toteuttaa yhden toiminnallisuuden olemalla hytti. Itse taasen uskaltaisin väittää, että hytti, jossa on kiinni useampi erilainen lisävaruste sekä x määrä erilaisia ohjauslaitteita eri tarkoituksiin + muuta sälää, voi ja toteuttaa asiakkaalle useammankin ominaisuuden...

Ja toiseksi. Väite, että isompia moduuleita on tehtävä helpottaakseen yrityksen tiedonhallintaa, on yksinkertaisesti täyttä puppua. Viittasin tähän lyhyesti aikaisemmassa tarinassa, Liikaa tiedostoja, mutta jos jollain on eriävä mielipide niin mielelläni kuuntelen...

2. Moduulin alla ei voi olla toista moduulia

Tähän tuntuu moni tarttuvan. Miksi ei? Kaksi perustelua:

a) Jos moduuli toteuttaa yhden toiminnallisuuden niin miten moduuleista koostuva moduuli voi tehdä saman? Miksi moduulin yläpuolella pitäisi edes olla toista moduulia?

b) Teoriassa yritys voisi määritellä, että sen moduulien A ja B yläpuolelle "kokonaisuuden helpottamiseksi" tehtäisiin moduuli AB, jolloin moduulin alla olisi toisia moduuleja. Ongelmaksi kuitenkin muodostuu, että yrityksessä tietoa hallitaan määrätyllä tasolla. Useampi tasoinen hallinta (kuten tässä) vaatii tuplamäärän ymmärrystä organisaatiolta. Pitää tietää, että tässä tapauksessa tämän käsiteltävän tason alla onkin lisää moduuleita, lisää rajapintoja, lisää sääntöä, joihin yksittäisessä suunnittelutapauksessa ei modulaarisuuden nimissä saa koskea. Lisäksi moduulipalikka AB on jo todennäköisesti sen verran iso, ettei se suoraan istu toiseen tuotteeseen. Vaaditaan uusi kopio, uusi variantti, johon moduulit A ja B hautautuvat ja alkavat elää omaa elämää. Teoriassa voitaisiin käyttää samoja moduuleita, mutta käytännössä meillä on "same same but different" -moduuleja varasto pullollaan. Tuttuako?

3. Moduulia suuremmat kokonaisuudet pitää pystyä kuvaamaan ”yhdellä nimikkeellä”

Tämä on ensisijaisesti haaste tuotetiedonhallinnan parissa toimiville. Luoda työkalut ja järjestälmä, jotta tämä on mahdollista. Ennen sitä ei kannata liikaa geneerisestä tuoterakenteesta mainostaa. Sinällään yksinkertaista, jos moduulit ja rajapinnat ovat kunnossa, on moduulia suuremmat kokonaisuudet kokoonpanoja. Riittää siis kun on kokoonpano-ohje ja konfiguraattori, joka sylkäisee tiedon, mikä palikka milläkin kertaa kohtaan A laitetaan, jotta asiakas saa mitä haluaa. Uskallankin väittää, ettei tämä itse asiassa vaadi edes suuria investointeja. Palikat teillä jo on, kuhan niitä uskaltaa katsoa vain uusin silmin.

Itse asiassa tässä kohtaa piilee myös modulaarisuuden business case. Vai miltä kuulostaisi, jos jatkossa 200 kokoonpanon sijaan riittäisi tehdä vaikkapa kaksi, tai jos tuotteeseen tulevan muutoksen tekemiseksi riittäisi pelkän moduulin muuttaminen, tai jos moduulit olisivat organisaatiolle oikeasti läpinäkyviä ja uudelleen käytettävissä...


Loppuun vielä. Miten sitten saavutamme modulaarisuuden? Koska tuoteperhettä voidaan sen suhteen sanoa valmiiksi? Ei koskaan. Modulaarisuus on tapa toteuttaa asiakastarpeita. Asiakastarpeet muuttuvat koko ajan. Modulaarisuuden eli kyvyn sekoittaa ja yhdistää tuotteen itsenäisiä ja vaihdettavia osakokonaisuuksia on kyettävä muuttumaan koko ajan. Älä keskity tämän päivän tuotteeseen, huomenna se on jo vanhentunut.

Ai niin, unohdin.
Tuoteperhekohtainen modulaarisuus on yritystä haittaava tekijä.
Tästä tuonnempana...

LinkedIn Facebook Twitter Email Favorites More