Raportti: Lean-menetelmät Suomessa 2018

 

Lean-menetelmillä kehitetään organisaation toimintaa suuntaan, jossa työ tuottaa enemmän arvoa sekä asiakkaille että liiketoiminnalle. Niiden avulla keskitytään liiketoiminnan kannalta oleelliseen ja karsitaan turha työ. Leaniin kuuluu olennaisesti myös toiminnan jatkuva parantaminen. Soveltaakseen leania menestyksekkäästi organisaatiolla on oltava ymmärrys siitä, miten arvo sen toimintaympäristössä syntyy.

Tätä taustaa vasten selvitimme kolmatta kertaa suomalaisten organisaatioiden lean- ja ketterien menetelmien käytäntöjä. Saimme vastaukset yli 150 julkisen ja yksityisen organisaation edustajalta.

Esiin nousi monia kiinnostavia löydöksiä ja huomioita siitä, miten lean-ajattelu näkyy tietotyössä ja johtamisessa. Alla tiivistelmä tuloksista.

Lataa koko raportti täältä.

Lean-selvityksen tulostiivistelmä

Kanban nousi suosikiksi ohi Scrumin

Suosituin lean-menetelmä oli Kanban, jota käytti 48 % vastaajaorganisaatioista. Kakkospaikalla on viime vuoden ykkönen Scrum.

“Kanbanin suosion nousu saattaa tietty signaloida ketterien menetelmien voimakkaasta leviämisestä myös it:n ulkopuolelle. Se saattaa myös indikoida devopsin käytön lisääntymistä ja myös Scrum-tiimien maturoitumista ja pärjäämisestä keveämmällä rakenteella.”  

Käyttökohteiden kärjessä ohjelmistoprojektit, rinnalle kirivät muutosprojektit  

Päivittäin leaneja ja ketteriä menetelmiä käyttävien organisaatioiden määrä oli pysynyt ennallaan (41 %). Suosituimmat käyttökohteet olivat ohjelmistoprojektit 47 %, mutta sen rinnalle nousivat lähes yhtä vahvoina tuote- ja palvelukehitys 45 % sekä muut muutos- tai kehitysprojektit 45 %.

“Ohjelmistoprojektien rinnalle nousevat vahvasti myös organisaatioiden transformaatioprojektit, joissa fokus on ihmisissä, osaamisen kehittämisessä, uusissa menetelmissä ja prosesseissa. Teknologia tukee muutosta sivusta.”

Talouskehitys leanisteilla muita parempaa

Leanin/ketteryyden soveltaminen näyttää korreloivan positiivisen talouskehityksen. Selvityksessä 80 % organisaatioista, joiden tiimeistä yli 60 % käytti leanejä menetelmiä, oli paremmassa talouskunnossa kuin verrokkinsa.

“Lean-/transformaatioponnistelut tuovat hiljalleen tulosta viivankin alle. Eikä sinänsä yllätä, koska talouden piristyessä ketterin menetelmin toimivat pystyvät reagoimaan muutokseen nopeasti.”  

Arvoketju-, arvovirta- sekä asiakasymmärrys oli parempaa laajemmin leania käyttävissä organisaatioissa

Leanien ja ketterien menetelmien aktiivinen päivittäiskäyttö paransi arvoketju-, arvovirta- ja asiakasymmärystä ja lisäsi organisaation sisäisten kehityshankkeiden onnistumista. Arvoketjun ymmärrys tarkoittaa paitsi mahdollisuutta optimoida kuluja, myös sitä että myös asiakasta on huomattavan paljon helpompi ymmärtää. Arvoketjujen ymmärtämisestä seuraa suoraan myös kyky havaita toimintaympäristön muutokset nopeasti – ja jopa ennustaa niitä. Tämä tarkoittaa mm. sitä että voidaan luoda asiakkaille arvoa kilpailijoita nopeammin. Mistä seuraa parempaa kilpailukykyä.

Tehoja ja tyytyväisyyttä

Kokemukset leaneistä ja ketteristä menetelmistä olivat positiivisia. Organisaatiotasolla 40 % koki järjestelmällisyyden lisääntyneen ja 36 % havainnoi henkilöstön tyytyväisyyden sekä tehokkuuden kasvua. Henkilökohtaisella tasolla yleisimmin vastauksissa nousi esiin oman toiminnan kehittyminen sekä paremman  priorisoinnin teemat. Kolmannes koki työtyytyväisyyden nousseen uusien menetelmien myötä.

Vastaajan asema/rooli ja koetut haasteet  

Leanin ja ketterien menetelmien kanssa työskentelevät, eri rooleissa toimivat vastaajat, kokivat leanin eri tavoin. Kokemus työmäärän kasvusta oli vahvasti työntekijöiden ja asiantuntijoiden kokema haaste, ja johtavassa asemassa olevat kokivat enemmän osittaisen muutoksen aiheuttamaa kitkaa. Eniten haasteita aiheutti osittainen muutos: esiin nousi tarve saada enemmän tukea muutokseen sekä tiedotuksen ja viestinnän puutteet.

Lataa koko raportti täältä.

Mikäli haluat keskustella lean-teemoista, voit olla yhteydessä lean-valmentajiimme Karoliinaan ja Miikaan.

Karoliina Luoto
+358 40 765 8504
karoliina.luoto@codento.com

 

Miika Kuha
+358 40 552 4552
miika.kuha@codento.com

 

Tuoteomistaja, ahdistaako ketterä kehitys?

Ketterät kehitysmenetelmät ratkovat tehokkaasti kehitystiimin pulmia, mutta eivät juuri auta tuoteomistajan haasteissa. Sen sijaan ne ovat monien tuoteomistajan kohtaamien ongelmien juurisyy. Ongelmien ratkaisu vaatii muita menetelmiä.

Ketterällä mallilla lähdettiin ratkomaan kolmea pulmaa:

  1. Kehittäjien työ on tehokkaampaa, kun työtä ei koko ajan häiritä.
  2. Liiallinen dokumentaatio ei itse asiassa olekaan välttämätöntä.
  3. Softaprojekti, joka on luovittavissa oikeaan suuntaan, on parempi kuin vuoksiksi raiteille tiukasti sidottu etenemistapa.

Ketterä kehitys, ketteryys, on ollut kuluneen vuosikymmenen megatrendi ohjelmistokehityksessä ja se on korvannut monessa hankkeessa totutun toimintatavan, vesiputousmallin. Uudelle tavalle toimia keksittiin iteratiivista kehitystä hienompi konteksti ja termit – ja sanastoomme ilmestyivät ketteryys, ketterä ja agile. Ketterä kehitys löi läpi koko ICT-alan ja nykyisin ketterää ohjelmistokehitystä tehdään Suomessa valtavirtana pelifirmoista pankkisoftaan saakka.

Miten tuoteomistaja hyötyy ketterästä?

Valitettavasti ketterä kehitys jätti softahanketta vetävän johtajan tai tuoteomistajan leikin, riemun ja uusien ratkaisujen ulkokehälle. Ennen vastuuroolissa oli kuukausia aikaa miettiä mitä tarvitaan ja miten saadaan kaikkien hyväksyntä jokaisen vaiheen sisällölle. Nyt vastuunkantaja joutuu kahden viikon välein yksin taistelemaan projektin puolesta tuulimyllyjä vastaan. Se ei useinkaan ole se voittava arpa.

Kun päätettäviä asioita on käsillä kahden viikon välein, vaatii malli tuekseen selkeän päätöksentekotavan. Näin usein ei ole aikaa miettiä kaikkea alusta asti vaan tarvitaan roteva selkäranka, jonka varassa saa nopeasti tehtyä hyviä päätöksiä.

Selkärankana ei toimi pelkkä hähmäinen visio eikä sellaista ehdi jokaista hanketta varten tyhjästä rakentaakaan. Parempaa tekemistä löytyy aina. Post-ketteryys edellyttää valmismallia, joka soveltuu organisaation tulevaisuuden kannalta kriittisimpään päätöksentekoon.

Post-ketteryys = lean + ketterä

Olen käyttänyt lean-maailmasta tuttuja lähestymistapoja ketterien kehityshankkeiden tukemiseen nyt parisen vuotta ja kokemukseni on, että lähestymistapa on lähes kaikissa tapauksissa nappivalinta.

Lean-maailman Toyotat ja Four Seasons -hotellit ovat lähteneet ratkomaan samaa pulmaa kuin ketterä tuoteomistaja: “miten palveluamme tai tuotettamme kannattaisi parantaa, jotta kauppa kävisi paremmin?”

Hyvä tuoteomistaja tai liiketoiminnan kehittäjä: et varmaankaan ole ensimmäistä kertaa tämän kimurantin pulman edessä – valmiita ratkaisuja löytyy, samoin kirjallisuutta, konsultteja ja parhaita käytäntöjä. Älä jää yksin kääntelemään backlogia talikolla, vaan etsi avuksesi lean-maailman voittavia ratkaisuja. Post-ketteryys on täällä.

Lukusuositus: kollegani Karoliina Luodon laatima Tuoteomistajan Scrum-pikaopas.

Petri Aukia
Twitter @aukia

#tuoteomistaja #ketterä #ketteryys #postketterä #postagile #lean #scrum #ithanke

***

Kuva: Flickr CC / Stewart Black 

Projektin ei tarvitse olla painajainen

Lähes jokainen voi hyvällä omallatunnolla sanoa olleensa mukana projektissa tavalla tai toisella. Ja ihan liian iso osa on kokenut myös projektityöhön liittyvää epäselvyyttä, aikataulupaineita ja projektiriippuvuuksien tuskaa, mistä syystä pahimmillaan projektista on tullut sallittu synonyymi painajaiselle. Projektin onnistumisen kannalta on tärkeää, että tavoite ja sen tekemiseksi tarvittavat resurssit ja aikataulu on ymmärretty oikein. Ketterien menetelmien käyttö puolestaan lyhentää palautesykliä ja mahdollistaa dynaamiset muutokset aikataulussa, tavoitteissa ja resursseissa.

Ohjelmistoprojektien monimutkaisuudesta

Neutraalisti katsottuna projekti on kokonaisuus, jolle on määritelty ajallinen alku, loppu ja selkeä päämäärä sekä tekijät, joilla päämäärä on saavutettavissa. Varsinkin isomman kokoluokan projekteissa kompleksisuutta lisäävät erilaiset riippuvuudet.

Ohjelmistopuolella kompleksisuus johtuu usein myös systeemien monimutkaisuudesta, olemassa olevan ympäristön perintönä saadusta vanhentuneesta koodista tai pysyvästi sementoiduista taaksepäin yhteensopivuus -vaatimuksista. Tai kun on otettu teknistä velkaa jättämällä koodin siivous kiireessä sivuun.

Ohjelmistoprojektien haasteet harvoin tekijöiden syytä

Harvoin ohjelmistoprojektien ongelmat liittyvät kuitenkaan tekijäporukkaan, joka yleensä koostuu asiantuntijoista ja alansa ammattilaisista. Heillä on tarvittava osaaminen ja halu oppia, joilla taklataan kiukkuisimmatkin riippuvuudet tai tekniset haasteet. He osaavat myös määrittää järkevät etenemisvaihtoehdot, kun törmätään isompaan siirtokivilohkareeseen.

Mikä ohjelmistoprojekteissa sitten mättää?

Mikä ohjelmistoprojekteista sitten tekee niin kiharaisia? Ja miksi asiakkaat saavat eteensä järjestelmiä tai käyttöliittymiä ymmärryksen tuolta puolen? Vastauksia lienee yhtä monta kuin on tuuliajolle menneitä projektejakin. Usein taustalla kuitenkin kytee tekemisen jäykkyys tai joku seuraavista perustavaa laatua olevista projektihelmasynneistä – perinteisen projektikolmion kautta katseltuna:

Puhun mielelläni ohjelmistokehityksessä ihmisistä resurssien sijaan ihan vaan siksi, että ihmiset ne käytännössä toteuttavat ohjelmistojen toiminnallisuudet. Muu resursointi tulee yleensä laiteinvestointien, jne. puolesta ja näillä katetaan pidemmän aikavälin tarpeita.

1. Epäselvä tai epärealistinen tavoite

Selkeys siitä, mitä on tarkoitus saada aikaiseksi näyttelee isoa roolia projektin onnistumisessa. Harmittavan usein (sisäinen/ulkoinen) asiakas tai arkkitehti lähtee harhailemaan tontiltaan ja päätyy kuvaamaan sitä, miten hänen haluamansa asia toteutetaan, kun se mitä oikeasti tarvittaisiin, olisi selkeä tarpeen kuvaus. Kehittäjät kyllä keksivät järkevimmän toteutustavan, kunhan heille kerrotaan mitä halutaan ja miksi. Speksailu vailla vastuuta kokonaisjärjestelmän toimivuudesta on tietysti jännää, mutta useimmiten se hidastaa ja hankaloittaa kehitystiimien työtä –  heille kun olennaisinta olisi saada ymmärrys siitä, mitä halutaan. Näennäisen valmiin ratkaisun ojentaminen kehittäjille alentaa heidät samalla puhtaiksi koodikirjureiksi, mikä myös syö tekijöiden motivaatiota.

Ajan käyttäminen siihen, että pystyy kertomaan selkeästi mikä on ratkaistava ongelma, missä asiayhteydessä ongelma esiintyy ja millainen vaikutus sillä on asiakkaan elämään on tärkein panostus, jonka tilaajapuoli voi kehitystyölle antaa. Lopusta huolehtivat asiansa osaavat ja systeemiä ylpeydellä ylläpitävät koodarit.

2. Riittämättömät resurssit tavoitteen saavuttamiseksi

Eli keksitään se Hillittömän Hieno Juttu, joka tarttis tehdä ja mielellään heti. Sitten ei kuitenkaan olla valmiita valitsemaan niitä asioita, mitä sitten jätetään tekemättä tai miettimään, mikä oikeasti on paras taho toteuttamaan haluttu toiminnallisuus ja mitä nämä tiimit parhaillaan tekevät. Tai kieltäydytään kuulemasta toteuttajien arviota siitä, millaisella työpanoksella toiminnallisuus on tehtävissä.

Taas kerran tullaan siis takaisin siihen, että pitäisi olla kyky ja halu miettiä, mikä nyt olikaan tekemisen tärkeysjärjestys ja mihin rahkeet riittävät. Tai pohtia, mitä se tarkoittaa, kun järjestelmään lähdetään lisäämään toiminnallisuutta ns. sankaritöinä. Valmis toiminnallisuus pitäisi kuitenkin nähdä myös ylläpidon, skaalautuvuuden, suorituskyvyn ja jatkokehityksen, jne. vinkkelistä. Puoliksi tai sinnepäin tehdyt toiminnallisuudet ja järjestelmät ovat ne kalleimmat toteutuksen puolesta, oli tekijä sitten omasta talosta haalittu iskujoukko tai ulkoinen konsultti.

Ohjelmistoprojektit harvoin onnistuvat sillä, että liiketoimintapuolen Excel saadaan näyttämään rivit nätisti. Ihmisten osaamisen taso, oppimiskäyrä tai vaikkapa koodaamisen nopeus eivät ole vakioita ja riippuvat paljolti esim. käytettävien teknologioiden tai kielten tuttuudesta. Kehittäjätkin ovat ihmisiä, joilla on oma työn ulkopuolinen elämä (vaikka legenda toisin väittääkin). Heillä on yhtä lailla perheitä, koiria, lomia ja tarpeita hoitaa ne samat pankkiasiat kuin tilaajillakin. Tällaiset pitää huomioida, kun mietitään missä ajassa lopputulos voi realistisesti valmistua.

3. Epärealistinen aikataulu

Yllämainittujen lisäksi projektin onnistumiseen voi helposti vaikuttaa asettamalla aikataulun, jossa on mahdotonta pysyä ottaen huomioon asetetut (epäselvät/ristiriitaiset) tavoitteet ja (puuttuvat) kehittäjät.

Epäonnistumista voi pedata sillä, että ei kysytä asiantuntijoilta, mitä toiminnallisuuden toteuttaminen aidosti vaatii ja neuvotella sen jälkeen riittävästä toteutuksen tasosta – aikataulu, haluttu laatutaso ja tekijöiden saatavuus huomioiden. Kun luullaan, että yhden valintaruudun toteutus hoituu yhtä sukkelaan kuin designerin  flash-animaationa toteuttama näkymä, vaikka taustajärjestelmiin saman toteuttaminen myös niiden ei-toivottujen käyttäjätarinoiden (ns. rainy day -skenaariot) ja lokituksen & auditoinnin kanssa on huomattavasti työläämpää. Ja näitähän tehdään, jotta käyttäjiä voidaan jatkossa myös tukea. Tästähän ei se flash-animaatio kerro mitään.

Lue lisää Pimeän agilen välttämisestä.

Ketterä toteutus kokonaisuudessaan edullisempi

Valittu tapa tehdä ohjelmistoprojekti on kunkin organisaation päätettävissä. Itse olen paketoinut projekteja sekä vesiputousmallilla että ketterillä menetelmillä, eikä menetelmä itsessään ole kynnyskysymys.

Jos valita saan, hoidan projektini ketterästi. En siksi, että se olisi jollain tapaa viileämpää jutella ketterästi Scrumia tai Kanbania, vaan siksi, että ketterä toteutustapa mahdollistaa käyttäjää paremmin palvelevan ja kokonaiskuvassa edullisemmaksi tulevan toteutuksen.

Nopeat muutokset, joita väistämättä tulee, ovat mahdollisia niin tavoitteissa, budjetoinnissa kuin aikataulussa – maailma harvoin pysähtyy odottamaan, että juuri minun edellisenä vuonna kerran määrittelemäni projekti valmistuu seuraavaksi jouluksi muuttumattomana.

Kullankallis käyttäjäpalaute

Mitä nopeammin aidot käyttäjät pääsevät testaamaan ominaisuuksia, sitä nopeammin saadaan palautetta kehitystyöhön sekä korjauksia takaisin ominaisuuksiin. Pienilläkin muutoksilla on toisinaan ratkaiseva merkitys käyttäjän kannalta – ketterässä kehityksessä nopea palautesykli ja jatkuva parantaminen kuuluvat tekemisen luonteeseen.

Minusta projekteja on aina ollut hauskaa tehdä, kiitos ässien kehitystiimien ja arvokkaan asiakaspalautteen. Projektit rullaavat varsinkin, jos ne on valmisteltu huomioiden kolme kulmakiveä:

  1. tavoite
  2. ihmiset + mahdolliset muut resurssit
  3. aikataulu.

Kaikki muu on sen jälkeen pienempää ratkottavaa.

 

Portfolio visualizer: projekti opiskelijan näkökulmasta

Portfolio visualizer -projektiryhmäläisiä työssään. Etualalla Miili, Kaarlo ja Castor, takana Niklas.

Tausta: Aalto-yliopiston Scrum-projektikurssi

Aalto-yliopiston tutkintorakenteeseen kuuluu lähes koko vuoden kestävä projektikurssi, jonka aikana opiskelijaryhmät toteuttavat yritykselle asiakasprojektin. Projektiaiheille ei ole tarkkoja rajoituksia, mutta projektien on oltava haastavuudeltaan sekä laajuudeltaan opiskelijatyöksi sopivia ja kehitykseen tulee käyttää Scrumia. Tiimien ja asiakkaiden yhdistäminen tapahtuu yritysten kirjoittamien kuvausten perusteella, joiden pohjalta tiimit hakevat mielenkiintoisia projekteja. Yritykset tekevät hakemusten ja lyhyen tapaamisen perusteella lopullisen päätöksen siitä, mikä tiimi heidän projektiaan lähtee toteuttamaan. Koulun puolesta koostettu projektitiimimme koostui kahdeksasta ohjelmistokehittäjästä sekä Scrum-masterista.

Aiheena datan visualisointi

Codenton tarjoama projektiaihe kiinnitti ryhmämme huomion, koska datan visualisointi kiinnosti useampaakin ryhmäläistä. Lisäksi monesta muusta projektiaiheesta poiketen se ei sisältänyt tiukkoja teknisiä esitietovaatimuksia ja jätti enemmän liikkumatilaa kuin monet muut tarjotut aiheet. Vaikka ryhmä koostui pääasiassa toisilleen ennakkoon tuntemattomista ihmisistä, olimme yllättävän yksimielisiä siitä, että tämä olisi projektiaiheista meidän ykkösvaihtoehtomme. Projektien lopullisessa valintatilaisuudessa vahvistui tunne siitä, että Codenton Portfolio visualizer-projekti olisi meille hyvä vaihtoehto. Olimme erittäin iloisia siitä, että valinta kohdistui hakijoiden joukosta meihin.

Codentolta tilat ja asiantuntijoiden apua

Codento tarjosi meille tilat ja monipuolisesti eri osaamisalueiden asiantuntijoita käyttöön projektin ajaksi. Käytännössä työmme rytmittyi viikottaisten, Codenton toimistolla pidettävien yhteiskokoontumisten sekä niiden välillä koululla omaan tahtiin etenevän varsinaiseen koodaamisen vuorotteluksi. Useimmiten saavuimme Codentolle alkuiltapäivästä, pidimme Scrumiin liittyvät tapaamiset ja virallinen tuoteomistaja sekä muut projektin kanssa tiiviisti yhteydessä olevat asiantuntijat olivat käytössämme muutaman tunnin. Monesti työstimme ryhmän kanssa yhteisiä asioita virallisten kokoontumisten päättymisestä siihen asti, että Codentolaiset alkoivat itsekin lopetella työpäiväänsä.

Haasteena uusien työkalujen omaksuminen

Heti alussa kävi ilmi, että projekti on aika monelta aspektilta erilainen kuin kuvauksen perusteella olimme kuvitelleet. Suoria esitietovaatimuksia käytetyistä teknologioista ei osaamisen osalta ollut, mutta niiden valinnasta oli kuitenkin olemassa selkeät linjaukset. Lähtötilanne, jossa käytännössä kukaan ryhmästämme ei ollut tehnyt juurikaan mitään valituilla työkaluilla toi omat haasteensa etenkin projektin ensimmäisille sprinteille.

Projektiryhmältä kehitysehdotukset tuoteomistajalle

Toinen, mutta enemmän etukäteen tiedossa ollut haaste liittyi projektin varsinaiseen aiheeseen ja ohjelmiston kehityssuuntaan liittyviin päätöksiin. Codentolla ei ollut erityisen  yksityiskohtaista visiota Portfolio visualizerin ominaisuuksista, enemmänkin ainoastaan idea siitä, että konseptia voisi toteuttaa paremminkin. Saimme alusta alkaen ohjelman aiotun käyttötarkoituksen raameissa vapaat kädet tehdä ehdotuksia, joista tuoteomistaja valitsi kehitykseen lähtevät ominaisuudet. Haastavaa tässä oli se, että meillä ei tuoreena tiiminä ollut kovin selkeää käsitystä omasta osaamisprofiilistamme sekä se, että projektinhallinta yrityskontekstissa oli meille aiheena melko vieras.

Lopputuloksena onnistunut projekti

Tekemämme projekti oli huomattavasti suurempi ja moniulotteisempi kokonaisuus, kuin olimme esittelytekstin perusteella kuvitelleet. Tämän huomioiden on suuri onnistuminen, että projektin loppuessa olimme saaneet valmiiksi kaiken, mitä työn alle oli otettu. Vahvana tekijänä onnistumisen takana oli Codenton ymmärrys siitä, että kyseessä oli opiskelijaprojekti. Codento myös panosti tarvitsemaamme tukeen läpi koko hankkeen.

Codento pysyi asiakkaan roolissa

Jälkikäteen ajatellen erityisesti ohjelmistopuolen osaajia olisi voinut hyödyntää rohkeammin, mutta luontevaa kysymistä asioista vaikeutti se, että varsinainen koodaaminen tapahtui muualla kuin Codentolla ja usein virallisten työaikojen ulkopuolella. Toisaalta tuoteomistaja sekä kaksi muuta asiantuntijaa olivat ennakkoon luvattua enemmän mukana projektin toteutuksessa ja valmiita vastaamaan kysymyksiin sekä selvittämään projektiin liittyviä ongelmia myös viikoittaisten tapaamisten ulkopuolella. Codento pysyi myös asiakkaan roolissa hienosti. Koko ryhmämme oli yllättynyt loppuarviotapaamisen aikana tulleesta huomattavan positiivisesta palautteesta, sillä itse kurssin aikana kehuja oli jaettu maltillisemmin. Oikeissakaan ohjelmistoprojekteissa asiakas tuskin olisi viikoittaisissa tapaamisissa ylitsevuotavan innoissaan siitä, että pyydetyt ominaisuudet on toteutettu niin kuin pitääkin.

…ja antoi mahdollisuuden oppia uutta

Kaiken kaikkiaan  Codento antoi asiakkaana ryhmällemme mahdollisuuden oppia paljon leanistä ohjelmistokehityksestä, siihen liittyvistä haasteista ja sen tarjoamista mahdollisuuksista. Käyttöön tarjotut tilat ja resurssit tukivat ryhmämme hioutumista tiimiksi, jolla oli realistiset mahdollisuudet saavuttaa selkeä yhteinen päämäärä. Koko projektiryhmälle jäi projektista käteen uuden, konkreettisen ohjelmointiosaamisen lisäksi vahvempi luottamus omaan kykyyn omaksua uusia teknologioita, alustoja sekä kieliä.

Selvitys: Lean-menetelmillä parempaa kilpailukykyä muutoksessa

Codento selvitti lean-menetelmien käyttöä suomalaisissa organisaatioissa vuonna 2016. Tänä vuonna teimme saman selvityksen uudestaan nähdäksemme, miten lean-maailma nyt makaa ja miten tilanne on muuttunut sitten viime kevään. Lataa Lean-menetelmät Suomessa 2017 -raportti maksutta!

Lähes puolet vastaajaorganisaatioista kertoi toiminnan tehostuneen lean-menetelmien avulla: 47 % koki priorisoinnin parantuneen ja 48 % tehokkuuden lisääntyneen. Lähes puolet vastaajaorganisaatioista oli onnistunut parantamaan myös asiakastyytyväisyyttä. Selvityksen kiinnostava löydös oli se, että laajalti lean-menetelmiä käyttävillä organisaatioilla asiakkaan ja arvoketjun ymmärrys lisääntyi. Tämä toi lisää kilpailukykyä.

Arvoketjujen ymmärrys on avain tulevien asiakkaiden nopeassa onnellistamisessa

Lean-organisaatiot ilmoittivat ymmärtävänsä arvoketjut ja toimintaympäristönsä verrokkeja paremmin. Arvoketjun ymmärrys tarkoittaa paitsi mahdollisuutta optimoida kuluja, myös sitä että asiakas on huomattavasti helpompi ymmärtää. Arvoketjujen ymmärtämisestä seuraa suoraan myös kyky havaita toimintaympäristön muutokset nopeasti – ja jopa ennustaa niitä. Tämä tarkoittaa mm. sitä että organisaatiot pystyvät luomaan asiakkailleen arvoa kilpailijoita nopeammin.

Johtajuutta kaivattiin lisää – ja aiheesta

Jos lean nähdään suppeana yhden alueen optimointityökaluna, saadaan toki tehoja kyseisestä alueesta, mutta voidaan olla auttamattomasti myöhässä, kun toimintaympäristö muuttuu. Johtajuuden rooli on paitsi voimaannuttaa organisaatio itsenäiseen lean-menetelmien käyttämiseen jatkuvasti ja organisaation laajuisesti, varmistaa myös että kokonaiskuva säilyy ja toimintaympäristön ymmärtäminen kääntyy visioksi ja tavoitetilaksi asiakkaalle tehokkaasti tuotettavalle lisäarvolle.

Lean oli voittaja talouskasvun saralla

Yli puolet vastaajista kertoi talouskunnon olevan parempi kuin 5 vuotta sitten: tässä oli kasvua 6 prosenttiyksikköä viime vuodesta. Häviäjissä vallitsevana olivat leaniä käyttämättömät organisaatiot. Lean-organisaatioiden osuus parempaa tuloskuntoa raportoineista kasvoi suhteessa viime vuoteen nopeammin kuin verrokkien. Tämä ei ole yllättävää, sillä talouden piristyessäkin lean-menetelmin toimivat pystyvät reagoimaan muutokseen nopeasti.

Kokemukset leanistä pääosin myönteisiä

Kaikista annetuista vastauksista sekä tänä että viime vuonna noin 80 % oli positiivisia. Positiiviset kokemukset leanistä lisääntyivät pidemmässä käytössä; mitä pidempään lean-menetelmiä oli käytetty, sitä enemmän positiivisia vaikutuksia havaittiin.

Käyttökohteiden kärjessä ohjelmisto- ja kehitysprojektit

Lean-menetelmiä käytetään laajimmin erilaisiin ohjelmistoprojekteihin:

  • ohjelmistoprojektin suunnitteluvaihe (47 %)
  • ohjelmistoprojektin toteutusvaihe (57 %)
  • ohjelmistoprojektin jatkokehitys ja ylläopito (53 %)

Leanien menetelmien käyttö organisaatioissa on lisääntynyt hienoisesti: tänä vuonna organisaatioilla oli käytössään keskimäärin 3,9 menetelmää, kun taas viime vuoden vastaava luku on 3,4.

Suosikkina edelleen Scrum

Suosituin lean-menetelmä oli tänäkin vuonna Scrum, jota käytti 58 % vastaajaorganisaatioista. Kakkossijalla komeilee Kanban 54 % osuudella. Molemmat suosikkimenetelmät olivat käytössä 40 % organisaatioista.

Kyselyyn vastaajat

Lean-selvitykseen osallistui yli 90 vastaajaa eri kokoisista organisaatioista sekä julkiselta että yksityiseltä sektorilta. Selvityksen vastaajista ylivoimaisesti suurin osa oli johtavassa asemassa tai erilaisia asiantuntijoita. IT-ala oli tänäkin vuonna vahvasti edustettuna; kolmasosa vastaajista työskenteli tietotekniikan parissa. Saimme kuitenkin vastauksia myös mm. terveydenhoitoalan työntekijöiltä sekä yrittäjiltä.

Lisätietoja antaa

Petri Aukia
toimitusjohtaja, Codento Oy
petri.aukia@codento.com
+358 400 438610
Twitter @aukia

Voit myös ottaa yhteyttä minuun:

Miika Kuha
lean-konsultti ja yksi selvityksen tekijöistä, Codento Oy
miika.kuha@codento.com
+358 40 552 4552
Twitter @kuha