Miten onnistua mittaamisessa?

Ilman nappiin osuvaa mittaamista et voi varmistua siitä, parannettiinko jotakin vai ei. Mittaamista pohdittaessa nousevat pintaan keskeiset mitä, miksi, miten -kysymykset. Valitettavasti turhan usein unohtuu tärkeä kysymys: mitä ei tarvitse tai kannata mitata.

Älä mittaa mittaamisen vuoksi

Mittaamisen tärkein funktio on tuottaa tietoa päätöksenteon tueksi (tai perustutkimuksessa maailman ymmärtämisen tueksi). Jos mittaamisen tuloksena syntyvä tieto ei tue tai mahdollista päätöksentekoa tai ei vaikuta päätökseen mitenkään, ei mittausta kannata tehdä.

Muista myös, että mittareihin käytetty panostus, ilman mekanismia päättää tulosten pohjalta, ei hukkaa vain panostusta vaan myös kaikkien mittaamiseen ja tulosten analysointiin osallistuvien aikaa. Se on harmillisesti pois asiakkaalle tehtävästä työstä.

Mitä sitten kannattaa mitata?

Kaikki mittaaminen kiteytyy enemmän tai vähemmän päätöksenteon ympärille. Kannattaa mitata asioita, jotka auttavat päätöksenteossa – asioita, joiden mittaaminen mahdollistaa päätöksenteon ylipäätänsä.

Kaikkia asioita voidaan mitata ja mittaamisen pääasiallinen tarkoitus on pienentää johonkin asiaan liittyvää epävarmuutta. Esimerkiksi terassia rakennettaessa voidaan mitata koolaus-kakkosnelospätkää ja todeta, että tasan metrinen on sopiva, epävarmuus silmämääräisesti arvioituna 90 cm-120 cm pätkästä poistuu, eihän se 90 cm pätkä olisi ollut riittävä. Ja siten voidaan tehdä päätös, että tämä pätkä riittää ja puutavaraliikkeessä käynti vältetään. Tai siellä mistä olen kotoisin, sahalla käynti.

Lähempänä alaamme oleva esimerkki voisi olla web-sivulla kävijät aikayksikössä. Kävijöiden määrän perusteella hyväksytään muutokset tai palautetaan vanha layout.

Miksi kannattaa mitata?

Mittaamista kannattaa tehdä, jotta epävarmuus asioista poistuisi tai pienenisi. Kun epävarmuus saadaan pienemmäksi, voidaan tehdä informoidumpia päätöksiä aiheesta kuin aiheesta – jos mittaaminen on osunut oikeaan asiaan.

Esimerkkinä voisi olla vaikkapa Scrum-tiimin koodaamisen nopeus (mitä mitataan, tästä löytyy verkossa vaikka kuinka paljon väittelyitä…). Mutta oletetaan perinteinen story-pointteihin perustuva mittaus. Tällöin voidaan sprintistä toiseen, ainakin jollain tarkkuudella sanoa, kuinka paljon tiimi saa aikaan yhdessä sprintissä. Jälleen voidaan tehdä päätös, riittääkö nykyinen tiimi tekemään halutussa ajassa valmista vai pitääkö ottaa tiimiin lisää koodareita. Vai voidaanko tiimistä vähentää koodareita.

Edellisen esimerkin mittari voi ensin vaikuttaa hyvältä mittarilta, mutta se on itse asiassa huono mittauksen kohde, koska siinä oikeasti mitataan kahta eri asiaa, joilla voi olla yhteys tai sitten ei. Eli esimerkissä mitataan tiimin “suorituskykyä” ja tiimin kykyä arvioida storyihin liittyvä työmäärä.

Miten kannattaa mitata?

Edellä todettiin, että mitattiin huonosti, koska yhdellä mittauksella mitattiin kahta eri asiaa. Toimivampi mittaus onkin se, joka mittaa vain yhtä asiaa. Mittauksen pitää siis keskittyä yhteen asiaan kerrallaan, huomioiden mahdolliset taustalla vaikuttavat asiat.

Edellisessä esimerkissä voisi olla parempi mitata suoraan toteutettujen storyjen määrää, ilman story-pointteja. Tällöin saadaan mitattua epätarkempi arvio (koska storyjen koko vaihtelee), mutta arvio kohdistuu enemmän ”suorituskykyyn”.

Mittauksen kannattaa olla tarpeeksi pitkä/laaja, että mittaukseen liittyvä virhe, eli ”heilunta”, pienenee. Fyysikot käyttävät vanhaa nyrkkisääntöä: mittauksen virhe on mittauspisteiden lukumäärän neliöjuureen verrannollinen suure. Eli kun halutaan puolittaa virhe, pitää mitata neljä kertaa enemmän.

Mittauksen virheeseen tuijottaminen ei kuitenkaan saa varastaa huomiota varsinaiselta mittaukselta ja kannattaa aina muistaa, että mittaamisen tarkoitus on päätöksenteon parantaminen ja helpottaminen.

Douglas W. Hubbard käsittelee kirjassaan How to Measure Anything erinomaisesti kaikkia edellä käsiteltyjä kysymyksiä huomattavasti paremmin ja perusteellisemmin kuin tässä lyhyessä blogahduksessa on mahdollista. Toki Codenton konsultitkin voivat tulla avuksi mainittuja ongelmia pohtimaan.

Kaj Mustikkamäki

 

Ohjelmiston korjataan/korvataan -analyysi – miksi se kannattaa?

Suurissa yrityksissä ja julkishallinnossa on paljon tietojärjestelmiä  ja niihin liittyviä prosesseja, joihin liittyy paljon tyytymättömyyttä. On vaikea päätellä, mitkä järjestelmät muodostavat tukevan pohjan organisaation kehitykselle ja mistä niistä on muodostunut kehityksen esteitä, sillä useimpiin laajalti käytettyihin järjestelmiin liittyy aina monenlaista kritiikkiä. Vaikka ohjelmiston hankinnan aikaan se olisi täyttänyt hyvin tehtävänsä, muuttuu toimintaympäristö kiihtyvään tahtiin, ja ohjelmisto ja sen tukemat prosessit jäävät auttamattomasti ajastaan jälkeen muodostaen liiketoiminnan pullonkaulan.

Korjataan/korvataan -analyysi selvittää ohjelmiston ja prosessien tilan

Kehittämämme ohjelmiston ja siihen liittyvien prosessien korjataan/korvataan -analyysi auttaa selvittämään ohjelmiston nykytilan, ohjelmiston käytön ja siihen liittyvien toimintatapojen tarkoituksenmukaisuuden sekä ohjelmiston tulevaisuudennäkymät. Analyysin lopputuloksena saat konkreettiset suositukset jatkotoimista ja samalla ohjelmisto ja siihen liittyvät prosessit kategorisoidaan seuraavasti:

  1. Kunnossa. Ohjelmisto vastaa tarkoitustaan, sen tulevaisuudennäkymät ovat hyvät ja sen käyttö on tarkoituksenmukaista. Ohjelmiston tuki ja jatkokehitys on hyvissä käsissä niin organisaatiossa kuin sen mahdollisilla alihankkijoillakin.
  2. Korjataan. Joko ohjelmisto, sen käyttötapa, jatkokehitys tai ylläpitomalli on selvästi ristiriidassa organisaation tarpeiden kanssa. Järjestelmä vaatii ylimääräistä huomiota sekä budjetin, johdon huomiota tai molemmat, jotta organisaation sujuva toiminta ei vaarannu.
  3. Korvataan. Ohjelmiston toiminnassa, siihen liittyvissä prosesseissa tai sen ylläpitomallissa on jotain fundamentaalisesti ristiriidassa nykytilan ja tulevien tarpeiden kanssa. Aika on ajanut ohjelmiston ohi, ruokahalu on kasvanut syödessä tai sen toimittaja toimii tavalla, joka vaarantaa organisaation. Tulee halvemmaksi tai jopa välttämättömäksi korvata ohjelmisto sen sijaan, että hyvää rahaa kaadetaan huonon päälle.

Epätietoisuus ohjelman kunnosta luultua suurempi ongelma

Epäselvässä kunnossa oleva ohjelmisto on suurempi ongelma kuin ensi hätään voisi kuvitella. Kun järjestelmän elinkaari ei ole selkeä, ei järjestelmän ylläpitoon eikä jatkokehitykseen haluta investoida riittävästi. Keskinkertainen ohjelmisto, jota ei ajanmukaisteta tarpeiden kasvaessa, jää auttamatta pieneksi eikä siihen sijoitetulle rahalle saada vastinetta.

Ohjelmiston ja prosessien analysointi on monesti vaikeaa ilman ulkopuolista apua. Tilanne politisoituu helposti, sillä järjestelmän korvauksen vaatimat ponnistukset ovat vääjäämättä pois jostain muusta.

Pelkkä kooditarkistus ei riitä

Ohjelmiston analyysissä on tarkastettava itse järjestelmä, sen jatkokehitysnäkymät, sen toimittaja sekä ne prosessit, joilla järjestelmää käytetään. Pelkän järjestelmän kooditarkastuksen tai muun teknisen tarkastuksen kautta löytyy vain murto-osa ongelmista. Yhtä tyypillistä kuin vanhentunut tai vika-altis ohjelmisto, on löytää yksiköitä, joissa sinänsä kelvollinen ohjelmisto ei pääse oikeuksiinsa, koska prosesseja ei ole osattu muokata sellaisiksi, joilla investoinnista saataisiin kaikki irti.

Korjataan/korvataan -analyysi voidaan suorittaa myös sovelluksille, joiden lähdekoodiin organisaatiolla ei ole pääsyä.

Toimi heti – vältä hätiköidyt ja huonot päätökset

Epäselvä tilanne ohjelmiston kanssa on hyvä löytää hyvin aikaisessa vaiheessa. Sekä korjaukset että uuden sovelluksen hankinta korvaamaan edellinen, vaativat kuukausia tai jopa vuosia. Jotta tämä olisi edes mahdollista, on pitänyt arvioida kustannukset ja saada hankkeelle budjetti.

PK-sektorilla uusia sovelluksia voidaan ottaa käyttöön jopa viikoissa. Suurissa organisaatioissa tarpeen kiistattomasti todistamisesta voi helposti mennä vuosi tai parikin, ennen kuin korvaava ratkaisu on tuotannossa.

Jos ohjelmiston elinkaaren vaiheesta on epäselvyyttä, kannattaa tilanteesta ottaa selko ennen kuin joudutaan kiireessä tekemään kalliita, huonoja ja hätiköityjä päätöksiä.

Kysyttävää?

Toimistusjohtajamme Petri Aukia keskustelee aiheesta kanssasi mielellään. Petrin saat kiinni puhelimitse numerosta 0400 438 610, sähköpostitse petri.aukia@codento.com tai täyttämällä alla olevan lomakeen.

Ohjelmiston korjataan/korvataan -analyysi: kysy lisää!

Vesiputousbudjetointi lamauttaa kokeilukulttuurin

Suhdannebarometrit ja tutkimukset nostavat esiin lukuisia syitä suomalaisen kilpailukyvyn puutteeseen ja innovaatiotoiminnan hitauteen. Haluan lisätä keskusteluun yritysten aivan arkisen toiminnon: budjetoinnin.

Perinteiset budjetointitapamme leikkaavat tehokkaasti siivet kokeilukulttuurilta ja sen myötä uudistumiselta. Budjetoinnista on tullut monessa organisaatiossa vääränlainen vallankäytön väline.

Moni saattaa luulla, että kokeilukulttuurin vastustamisessa ja hidastamisessa on kyse koko vuoden kestävästä vanhoillisten ajattelijoiden voimasta. Mikään ei voisi olla kauempana todellisuudesta. Todellisuudessa seuraavan vuoden kokeilukulttuurin laimentaminen ja jopa estäminen tapahtuu juuri näinä alkusyksyn viikkoina. Suurten yritysten, julkishallinnon ja pk-yritysten ensi vuoden kehittämistyö, toimintatavat ja odotukset lyödään pitkälti lukkoon syksyn budjetointikaudella.

Vesiputousmallinen vuosibudjetointi on voimakkain yksittäinen kokeilevan toiminnan este.

Pitkälle suunnitellut kokeilut ovat kuin pakkopaita

Paradoksaalisesti mitä tiukemmin johtaja vaatii määrättyjä tuloksia kokeiluhankkeesta, sitä todennäköisemmin hanke epäonnistuu uuden oppimisessa. Jos ensimmäisestä epäonnistumisesta ei uskalleta oppia, kun on luvattu vuoden verran etukäteen suunniteltua, oppimisesta on tehty mahdotonta.

Kokeilukulttuurissa pääpaino on uuden ymmärtämisessä. Tämä onnistuu parhaiten, kun vuoden aikana tehdään paljon tuote-, palvelu-, toimintatapa- tai teknologiakokeiluja.  Tärkeää on, että jokaisessa kokeilussa otetaan edellisistä oppia. Kaikkein hyödyllisimpiä kokeiluja ovat ne, joissa tuloksia ei etukäteen voida tietää, eli on mahdollisuus valtavaan oppimiseen.

Jos hankkeiden on käytännössä oltava vuoden mittaisia, niiden tulokset on ennustettava etukäteen ja yllättävät tulokset ovat henkilökohtainen tappio, kokeiluja eivät uskalla tehdä muut kuin rämäpäät ja ne, jotka eivät vielä ole oppineet talon tavoille.

Siirry lean-budjetointiin

Edelläkävijäorganisaatiot osaavat varjella kokeilukulttuuriaan ennustettavien projektien vaatimuksilta, mutta suurimmassa osassa suomalaisia organisaatioita juuri tähän aikaan vuodesta lyödään lukkoon kokeilujen tavoitteet ja koko vuoden tarkka suunnitelma. Tämä lamauttaa uudistumisen.

Jokasyksyisen budjetointikierroksen tekeminen uudella liinillä tavalla avaa yhden kehittämisen pullonkaulan. Lean-budjetointi antaa liikkumavaraa ja tekee kokeiluista arkea.

Hyödyllisiä malleja budjetointiin

Codento on kehittänyt budjetoinnin työkaluja, jotka varmistavat kokeiluiden ja niitä tukevien toimintatapojen mahtumisen kehitysprojektien sekaan. Helppo ensimmäinen askel kohti lean-budjetointia on työkalu, jota kutsumme leaniksi projektikartaksi.

Uskomme, että lean-budjetoinnista tulee johtava tapa tehdä kokeiluja ja sen käyttö yleistyy myös ennustettavan työn budjetoinnin puolella.

Tunnustaudun myös intohimoiseksi Cynefin-mallin faniksi. Brittiläinen David Snowden on luonut pitkän kokemuksensa sekä erilaisten kompleksisten projektien pohjalta tämän todella silmiä avaavan, arvokkaan mallin. Cynefin-malli korostaa nykyosaamisen ja projektimallin suhdetta. Todella uutta ei voi luoda samalla tavalla kuin organisaation jo osaamaa.

Kerromme mielellämme lisää. Jos uteliaisuutesi aihetta kohtaan on koholla, ota ihmeessä yhteys:

petri@aukia.com, puhelin 0400 438 610
karoliina.luoto@codento.com, puhelin 040 765 8504
miika.kuha@codento.com, puhelin 040 552 4552

#lean #budjetointi #kokeilukulttuuri #cynefin