Formaalit viitekehykset ja Lean
Teksti on julkaistu alun perin Digioivan sivuilla. Digioiva yhdistyi Kumuran ja Pasaatin kanssa kesällä 2020.
Puhuttaessa prosessien ja laadun viitekehyksistä monella saattaa nousta niskakarvat pystyyn. Eivätkö nämä ole aikansa eläneitä, jämähtäneitä mammuttihäkkyröitä, joita erilaiset organisaatioiden laatuihmiset norsunluutornistaan ajavat keksiäkseen itselleen jotain tekemistä? Sanalla sanoen Leanin täydellisiä vastakohtia?
Kieltämättä monen IT-alalla työskentelevän kehittäjän kokemus esimerkiksi ISO-auditoinnista on se, että siellä katsellaan prosessikuvia, joilla on vähän tekemistä käytännön arkipäivän kanssa. Näin oli myös oma ensikosketukseni ISO-laatustandardiin vuosia sitten eräässä isossa ohjelmistotalossa. Eräänä päivänä vaan sähköposteihin tuli juhlallinen tiedote, että yrityksemme on saanut ISO-laatusertifioinnin.
Toisaalta työni Leanin parissa on pakottanut minut perehtymään myös näihin prosessiviitekehyksiin, ja huomaamaan, että niillä on pitkälti samat juuret kuin Leanilla. Deming on tunnustettu guru niin Leanissa kuin laatu- ja prosessijohtamisessa, ja jatkuva parantaminen sekä kokemuksista oppiminen muodostavat näiden kaikkien ytimen.
Olen ajan myötä vakuuttunut siitä, että nämä erilaiset näkökulmat eivät ole toisiaan poissulkevia, vaan pikemminkin saman kolikon kaksi eri puolta, jotka eri lähestymistapaa käyttäen pyrkivät pitkälti samoihin päämääriin. Ennen kun käymme läpi miten nämä näkökulmat täydentävät toisiaan, on syytä ehkä hieman kerrata sekä top-down- että bottom-up-lähestymistapojen ominaispiirteitä ja haasteita.
Haasteet top-down-lähestymistavassa
Nämä ovat useimmille isossa organisaatiossa työskentelevälle tuttuja: kehitystyötä ajavat – useimmiten erillisessä prosessi- tai laatuyksikössä – eivät välttämättä tunne riittävällä tasolla käytännön työtä, asiakasta tai projektissa vaikuttavia tekijöitä. Hyvää lähestymistavassa on se, että toiminnan kehittämiseen on käytettävissä aikaa ja resursseja, mutta samaan aikaan muu henkilöstö harvoin kokee tätä motivoivaksi eikä usein tiedä mikä tässä työssä koskettaa heitä.
Koska muutosprojekteissakin aikataulut painavat, implementointi jää usein pinnalliseksi ja viitekehyksistä otetaan peruspiirteet sellaisenaan, mutta varsinainen ajatustyö jää tekemättä: mitä tämä tarkoittaa missäkin ympäristössä, tai onko tietty piirre edes validi. Pitemmän päälle tämä kasvattaa kahtiajakoa organisaation sisällä: on olemassa kuvatut prosessit, ja sitten on todellinen työ, jotka elävät kokonaan eri maailmoissa. Pahimmillaan johto kokee tämän laatufunktion turhana toimintana, josta voidaan karsia kun talous on kireällä.
Haasteet bottom-up-lähestymistavassa
Bottom-up-lähestymistapa on edellisen vastakohta: usein erilaiset coachit vetävät itseohjautuvissa tiimeissä hyvin käytännönläheistä kehitystä, fasilitoivat työpajoja ja istuttavat jatkuvan parantamisen käytäntöjä arkipäivään. Yleensä henkilöstö on tällaisessa ruohonjuuritason työssä mukana aivan toisella asenteella kuin top-down-prosessikehityksessä.
Tehtyäni paljon tiimitasoista Lean-coachausta ja työpajoja olen huomannut, että kovin moni organisaatio ei oikeasti ole valmis muuttamaan toimintamalliaan. Tämän ikävä vaikutus on se, että monet tiimitason oikeat ja toimivat parannukset jossain vaiheessa vesittyvät tai suorastaan ajetaan alas perinteisellä resurssiutilisaatioon perustuvalla johtamisella ja mittaroinnilla. Siksi, vaikka puhummekin pienistä käytännön muutoksista arkipäiväisessä työssä, on aivan välttämättömän tärkeää että organisaation kaikilla tasoilla on yhteinen ymmärrys tavoitteista ja haasteista.
Mitä lisäarvoa prosessikehys tuo ruohonjuuritason implementointiin?
Kun ongelma on, että bottom-up-lähestymistavassa ei tapahdu pysyvää muutosta, ja toisaalta top-down ei myöskään johda käytännön muutoksiin, mikä on ratkaisu? Molemmat yhdessä! Lean-maailmassa termi, jota usein käytetään on Hoshin Kanri: pohjantähti eli yhteinen suuntapiste, jonka mukaisesti koko organisaatio orientoituu.
Viitekehykset antavat puitteet ja tavoitteet (“What”), kun taas tiimi- ja projektitasolle jää miten nämä tavoitetaan (“How”). Esimerkiksi COBIT ja ITIL antavat perusajattelumallin siitä, miten liiketoiminnan, IT:n ja prosessien tavoitteiden tulee nivoutua yhteen. Niitä tulee soveltaa harkiten ja aina miettiä, ovatko annetut tavoitteet ja prosessijaottelu mielekkäitä kussakin kohdeympäristössä.
Ehkä suurin tragedia suomalaisten organisaatioiden “liinauksessa” on se, että se nähdään lähinnä operatiivisen toiminnan hukan poistamisena, eikä ymmärretä, että suurin hukka syntyy keskenään ristiriitaisista tavoitteista organisaation sisällä.
Lean-ajattelun peruskivi on itse asiassa arvon tuotto ja juuri arvon tuoton tulisi ohjata toimintaa kaikilla tasoilla, jatkuvan parantamisen nivoessa tämän kaiken yhteen. Tässä voidaan hyödyntää prosessiviitekehyksiä järkevästi soveltaen, ja samalla hyödyntää tiimityön käytännön tasolla coachausta, fasilitointia ja muita osallistavia työtapoja ilman että ne olisivat keskenään ristiriidassa.
Tom Isaksson
Kuulumisia
Kokemuksia tekoälystä projektipäällikön työkaluna
Millaisia käyttötapoja projektipäällikkömme Päivi on löytänyt tekoälylle projektityössä? Missä tekoäly on erityinen valttikortti? Lue Päivin ajatukset tästä kirjoituksesta.
Helpotusta muutoskylläisyyteen muutosportfolion johtamisella
Milloin muutosta on liikaa? Silloin, kun ämpäri valuu yli. Muutosjohtamistakin valmentaja ja siinä konsultoiva Virpi Elers kertoo, kuinka muutosportfolio parantaa muutoksessa onnistumista muutoskylläisyyttä ehkäisemällä.
Yksilön muutosmatka osana laajaa muutosohjelmaa
Niin pienen kuin isonkin muutoksen onnistuminen on loppujen lopuksi kiinni ihmisistä. Muutoksen johtaminen myös yksilön tasolla auttaa sitouttamaan ihmiset tavoiteltuun muutokseen ja saamaan aikaan pysyvän toiminnan muuttamisen.
