Nimikkeistä käsitteisiin ja kirahvin kautta takasin

Tällä foorumilla on varsin usein pohdiskeltu sitä, mikä on nimike ja mitä tarkoittaa nimikkeellistäminen. Samojen ajatuskulkujen syövereihin ajauduin eräänä päivänä PDM-saarnamiehemme  ja toisaalta omien lasten ajatuskulkuja seuratessa. Omalla tavallaan molemmat aiheuttivat innostusta, joskin toisessa tapauksessa oli myös twisti harmaiden hiusten ja vatsahaavan pariin. Lukija voi itse päätellä kummassa tapauksessa näin kävi.

Aiemmin on todettu, että nimike on asia, jolle voidaan antaa yksilöivä tunnus, nimi, kuvaus ja erilaisia attribuutteja kuvaamaan nimikkeen ominaisuuksia.

Nimikkeellistettäessä sovitaan ja määritellään tavat ja käytännöt koodituksille, nimien ja kuvausten muodostamiselle ja määritellään eri nimikkeiden tarvitsemat attribuutit.

Kapasitanssi on tarpeeton tieto mutterille, mutta kondensaattorille varsin keskeinen. Toisaalta myös perspektiivi nimikkeeseen vaikuttaa nimikkeen mallinnukseen. Oston ja myynnin tiedot saattavat hyvinkin erota siitä tietotarpeesta, mikä suunnittelulle ja valmistukselle on olennaista tietoa. Nimikkeellistettäessä yrityksen tuotteet (myymät, ostamat, valmistamat, suunnittelemat) mallinnetaan liiketoimintaprosesseja varten.

Onko nimikkeellistämisellä ja käsitteellistämisellä ja käsitemalleilla sitten jotain eroa toisiinsa nähden? Sovelluskehityksen piirissä tehdään käsitemalleja ja kuvauksia käsitteistä, joita ratkaistavassa ongelmakentässä esiintyy. Selvitetään käsitteiden suhteita toisiinsa, käsitteisiin liittyviä ominaisuuksia ja attribuutteja. Tätä analogiaa seuraten voidaan väittää, että minkä tahansa asian voi nimikkeellistää. Kun määrittelytyötä tehdään, on tietysti olennaista ymmärtää mikä on se entiteetti, jota ollaan kuvaamassa.

Nuoremman tyttären kanssa usein automatkoilla tms. pelataan eläinarvoituksia. Siinä toinen antaa vinkkejä ja toinen koittaa arvata mikä eläin on kyseessä. Mikä on sellainen, jolla on pitkä kaula, pilkkuja ja neljä jalkaa? No kirahvihan se.

Kirahvikysymys

Mallintamisessa tehdään samaan tyyliin. Tunnistamme entiteetin ominaisuuksia ja attribuuttien tyypillisiä arvoja ja sen perusteella voidaan päätellä mistä oikein on kysymys. Tämä toimii varsinkin silloin, kun mallinnetaan asioita, joille on tosiolevainen vastine reaalimaailmasta. Joskus ongelmakenttää mallinnettaessa ratkaisun aikaan saamiseksi täytyykin käsitemalliin lisätä entiteetti, jolla ei olekaan konkreettista vastinetta reaalimaailmassa tai reaalimaailman vastine on hyvin abstrakti. Esimerkkinä näistä ovat tyypillisesti sovelluksissa käytetyt, koosteita esittävät käsitteet, kuten tuoteryhmä, hintaryhmä tai projektiryhmä. Ilman tietoa kontekstista ei voi päätellä, tarkoittaako projektiryhmä jollain kriteerillä ryhmiteltyä projektien joukkoa, vai projektiin osallistuvien henkilöiden muodostamaa ryhmää. Se millaisia attribuutteja tässä projektiryhmälle tarvitaan riippuukin siitä, kumpi käsitys projektiryhmästä on kyseessä.

Laajoja kokonaisuuksia mallinettaessa syntyy paljon näitä abstrakteja käsitteitä, jotka ovat alttiita virheellisille tai ainakin erilaisille tulkinnoille. Tätä ongelmaa ratkaistaan usein terminologisella sanastotyöllä, luodaan sanakirja ko. ongelma-alueen käsitteistä ja termeistä ja näin saadaan yhteinen ymmärrys nämä projetiryhmän kaltaiset abstraktiot tässä tilanteessa tarkoittavat. Suora analogia nimikkeiden maailmassa löytyy yrityksen sanakirjasta, corporate dictionary. Tämä sanakirja identifioi ja selittää yrityksen nimikkeistössä käytetyt termit ja mahdollisesti tarjoaa yrityksen käyttämät käännökset eri kielille. Toisaalta ostajan ja myyjän välillä olisi syytä olla yhteinen käsitys termistöstä tai tilaajan ja alihankkijan välillä. Yhtenäiset käännökset helpottavat tai jopa mahdollistavat nmikkeistön harmonisoinnin eri kielialueiden välillä.

PDM Preacher Jukka S mainitsi eräässä blogi-kirjoituksessaan vaatimusten nimikkeellistämisestä. Vaatimushan on myös abstraktio, joka täytyy mallintaa kontekstin mukaan. Kun vaatimus mallinnetaan tai nimikkeellistetään, luodaan vaatimustenhallinnan perusteita.  Vaatimus voi esiintyä käsitteenä kun asiaa tarkastellaan tuotekehityksen, muutoshallinan tai laadun varmistuksen silmin. Toisaalta vaatimusten hallinta voi olla myös näkökulmansa edellämainituihin. Kaikki kuitenkin liittyvät toisiinsa ja ehkä tässäkin kannattaa nousta helikopterin kyytiin ja katsoa tarkemmin missä kaikissa prosesseissa vaatimus oikeastaan esiintyy ja missä prosesseissa tieto vaatimuksista olisi hyödyllinen.

Nämä kaikki innoittavat ajatukset saivat kuitenkin täysin aivan uuden ulottuvuuden kun samana päivänä tulin töistä kotiin ja kohtasin aivan uudenlaiset vaatimusten maailman varhaisteini-ikäisen tyttäreni taholta. Vastassa oli vaatimusten big dataa, joiden luokittelutekijät olivat täysin portaattomia n-uloitteisessa avaruudessa. Huusin avukseni sumean logiikan ratkaisuja ja kvanttikoneita. Onneksi lopulta ratkaisu oli kuitenkin varsin yksinkertainen, Spagetti Bolognese. Maslovin tarvehierarkiaa kannattaakin vaatimustenhallissa kunnioittaa.

– Software Samurai –

Mainokset

The job that has to be done!

Tuotekehitys-viitekehyksessä usein korostetaan asiakkaiden merkitystä tuotteen vaatimusmäärittelyssä. Kysy asiakkaalta, miten he haluavat tuotettasi parantaa, on yleisin teesi B-to-B maailmassa. Asian toinen puoli, johon olen aikaisemminkin viitannut, on tämä Henry Fordin kuolematon ajatus: ”Jos olisin kysynyt asiakkailta mitä he haluavat, vastaus olisi ollut: nopeampia hevosia.”

Istuin juuri kaksi päivää Ice Live 2014 tapahtumassa, jossa tätä – nimenomaan Henry Fordin lähestymistapaa – rummutettiin voimakkaasti.

New Church of Finance

Maailman Top Thinkers -listan kärkipäähän jo pitkään rankattu Harvardin professori Clayton Christensen maalaili yhteiskunnallisesti synkkää visiota tämän hetken trendeistä, joissa yritykset keskittyvät tuottavuusinvestointeihin. Eli parannetaan nykytuotetta helpommin valmistettavaksi, edullisemmaksi ja näin kilpailukykyisemmäksi. Nykyisen ”Uuden Talouden Kirkon” oppien mukaan tunnusluvut pysyvät hyvinä ja yrityksen omistajien kukkaroon kilahtaa enemmän rahaa ja johtajia palkitaan hyvistä päätöksistä.

Fired

Yhteiskunnallisesti tilanne alkaa kuitenkin olla kestämätön. Tuottavuusinvestoinnit vähentävät aina työpaikkoja ja toisaalta tehokkuudesta saatavaa voittoa ei suunnata täysin uusiin tuotteisiin tai markkinoihin, jotka generoisivat uusia työpaikkoja, vaan rahat makaavat laiskoina omistajien kukkaroissa. Yritystasolla, lyhyellä tähtäimellä, kaikki näyttää hyvältä, mutta koska yhteiskunta on kuitenkin olemassa huolehtiakseen kaikkien ihmisten perusturvasta, pois potkittujen työttömien eläminen pitää jotenkin hoitaa. Se taas näkyy kasvavina veroina ja muina sivukuluina, jotka puolestaan tulevat heikentämään yrityksen tulosta, josta syystä pitää taas potkia lisää porukkaa ulos jne. 

No nythän alan kuulostaa jo Karl Marxilta – mikä ei kyllä ole tarkoitus – eli siis mennäänpä asiaan.

Ymmärrä mitä asiakkaan pitäisi saada aikaan

Clayton Christensenin pointti ja ohje on se, että täysin uusiin markkinoihin, tuotteisiin ja teknologiaan käytetään ainakin jenkeissä huomattavasti paljon vähemmän rahaa, kuin vielä 90-luvulla, josta johtuen lamasta nousu kestää aina pidempään ja pidempään. Helppo lääke syöksykierteestä ulos on yksinkertainen:

Ei jäädä junnaamaan nykytuotteen inkrementaaliseen parantamiseen, vaan pyritään ymmärtämään mikä on se juttu, mitä asiakas on meidän tuotteella tekemässä ja pyritään tuomaan konkreettista lisäarvoa asiakkaalle – ei parantamalla omaa tuotettamme, vaan tekemällä asiakkaan työ helpommaksi ja tuottavammaksi.

Okei, lopputulos on parhaimmillaan sama, eli tarjoamamme tuote paranee asiakkaan silmissä ja kauppa alkaa käydä paremmin, mutta lähestymiskulma on erilainen ja saattaa synnyttää aivan uusia innovaatioita – kuten auton liikkumavälineenä –  jotka taas synnyttävät uusia markkinoita, joita varten syntyy uusia työpaikkoja, josta syystä maailman talous alkaa nousta ja kaikilla on hyvä olla.

Vaatimukset nimikkeiksi

No miten tämä saarna liittyy nimikkeeseen? Tässähän on painotettu asiakkaan toiminnan ymmärtämistä, jonka jäsentämistä voidaan kutsua vaatimusten hallinnaksi. Vaatimusten hallintaa ei vielä kovin yleisesti mielletä osana tuotetiedon hallintaa, mutta yllätys yllätys: vaatimukset voidaan myös nimikkeellistää!

Asiakas vs. fani

Loppukevennyksenä todettakoon, että tämän ”Asiakas on kuningas” -tabun ampui seminaarissa alas näyttävästi Bruce Dickinson, Iron Maiden yhtyeen ja brandin keulakuva, joka totesi: ”I HATE CUSTOMERS, because they have a choice.” Brucen tavoite on luoda faneja, koska ne pysyvät ikuisesti ja ostavat kaikkea mahdollista mitä yritys keksii tuottaa.

-PDM Preacher