Luet nyt: Aalto Leaders' Insight: LSS DMAIC: Define – tunnista kehittämistarve ja aseta projekti huolella (osa 2)
Lean-ajattelu

LSS DMAIC: Define – tunnista kehittämistarve ja aseta projekti huolella (osa 2)

Ratkaiseva vaihe yrityksen prosessien tuloksellisessa kehittämisessä on kehittämistarpeiden tunnistaminen ja valinta!

Risto Lintula, 23.05.2022

|

Artikkelit

Jos kehittämisresurssit ja energia suunnataan epäolennaisiin kohteisiin, eivät parhaatkaan osaajat tai tehokkaimmat työkalut tuota merkittäviä parannuksia avainlukuihin.

Johdon valitsemilla ja hyvin rajatuilla (pilot-) projekteilla on suurempi mahdollisuus onnistua ja tuoda mitattavia taloudellisia tuloksia ja näin kannustaa jatkamaan ja laajentamaan kehittämisponnisteluita. Valitettavan useissa organisaatioissa kehittämisprojektien tunnistaminen ja asettaminen tehdään irti normaalista johtamisprosessista ja Lean ja Six Sigma -aktiviteeteiltä viedään pohja pois jo alkuunsa.

Ilman tunnistettua mahdollisuutta tai ongelmaa ei ole projektia

Käytännössä projektimaista kehittämistä vaativia kehittämiskohteita voidaan tunnistaa kahta eri reittiä:

  • Organisaatioissa, joissa on tehokas suunnitteluprosessi, tunnistetaan projektiaihioita osana strategian jalkautusta ja vuosisuunnitelman tekemistä. Kun asetetut tavoitteet ja niitä kuvaavat mittarit jalkautetaan alaspäin organisaatiossa, tunnistetaan samalla parannusta vaativia kohteita. Ajureita projektien käynnistämiselle ovat joko halu nostaa prosessin suorituskykyä tunnistetun liiketoimintamahdollisuuden saavuttamiseksi – tai yksinkertaisesti prosessissa olevat kyvykkyysongelmat ja tavoitteista jälkeen jääminen.
  • Yleisemmin käytetty menetelmä on suoraan kytköksissä organisaation päivittäisjohtamiseen ja seurantakäytäntöihin. Tällöin ajureina projekteille ovat arkea kiusaavat aika-, laatu- ja kustannusongelmat sekä prosessissa tunnistettu haitallinen vaihtelu. Nämä tulevat ilmi asiakkaiden valittaessa, budjettien ylittyessä ja aikataulujen paukkuessa tai yksinkertaisesti, koska toiminnan ennustaminen ja johtaminen on vaihtelun takia hallitsematonta. Jatkuvan parantamisen hengessä ongelmat ja kehittäminen pitäisi tietysti tehdä mahdollisimman etulinjassa, mutta jos ongelma vaatii enemmän resurssia kuin mitä linjassa sille voidaan vapauttaa, tai jos ongelman laajuus ylittää yksikön vastuualueen, pitää kehittämistarve projektoida.

Havaitaan tarve kehittämisprojektille sitten osana suunnitteluprosessia ja tavoitteiden jalkauttamista tai osana arkista tekemistä pitää projektiaihiot vielä huolella priorisoida ja asettaa tulosvastuussa olevan johdon toimesta. Vasta sen jälkeen ne ovat valmiita annettavaksi resursoitujen projektiryhmien ratkaistavaksi.

Mahdollista tehokas kehittämien – aseta kehittämisprojekti huolella

Projektien huolellinen asettaminen on LSS Define / Määritä -vaiheen keskeinen asia. Vahva näkemykseni on, että johdon roolin pitää olla vielä projektin tässä vaiheessa erittäin suuri, ja että projektien määrittämistä ei saisi jättää yksin asiantuntijoiden tehtäväksi.

Kun kehittämistarve tai ongelma on valittu, pitää sen kohdennus ja rajaus tehdä tarkasti. Käytäntö ja kokemus ovat osoittaneet kerta toisensa jälkeen, että liian yleisesti ja laajasti asetetun projektin riski jäädä tavoitteistaan tai epäonnistua kokonaan on merkittävän suuri. Tämä ei tarkoita sitä, ettei tavoitteellisia ”kehittämisohjelmia” tai ”läpimurtohankkeita” saisi käynnistää. On vain tehokkaampaa osittaa ja jakaa laajat ja moniulotteiset kehittämistarpeet rajallisen kokoisiksi osiksi, jotka voidaan sitten toteuttaa hallittuina projekteina. Pienemmistä osa-projekteista on mahdollisuus kerätä kokemuksia ja oppeja sekä saavuttaa mitattavia tuloksiakin nopeammin. Onnistumisista pääsee myös palkitsemaan tekijöitä nopeammin. Pitkittyneet projektit taas haudataan hiljaisuudessa, eikä jatkossa ole yhtään helpompaa innostaa porukoita uusiin hankkeisiin. Tunnettu sanonta – valas pitää syödä pieninä paloina, ettei siihen tukehdu – pitää ehdottomasti paikkaansa!

Laadi projektin business case – hyödyt esiin!

Olennaisin asia, joka Define-vaiheessa tehdään, on projektin Business Case.  Se on tiivis yhteenveto projektista ja sen avaintavoitteista pitäen sisällään seuraavat asiat:

  • Nykytilanteen ytimekäs kuvaus, mikä on ongelmana ja miksi nyt pitää toimia
  • Mikä mittari kuvaa nykytilannetta ja osoittaa aikanaan tehtyjen toimenpiteiden tuloksellisuutta (miten asiakkaan ääni kuuluu ja näkyy)
  • Mikä on projektin tavoitteena, kuinka paljon pitää parantaa
  • Mitä hyötyjä, mieluiten selkeästi todennettavia säästöjä ja etuja, projektilla haetaan
  • Miten projekti linkkautuu organisaation avaintavoitteisiin ja mittareihin

Tärkeää tässä yhteydessä on myös nimetä projekti mahdollisimman täsmällisesti, sopia aikataulusta ja käytössä olevista resursseista, sekä tunnistaa onnistuneen muutoshankkeen avainasiat. Esimerkiksi halutun muutoksen toteuttamisen kannalta tärkeiden sidosryhmien tunnistaminen ja osallistaminen heti alkuvaiheessa on erittäin tärkeää.

Projektin rajaamisessa käytetään usein karkean tason prosessikuvauksia sekä mittaristopuita, joiden keskeinen tehtävä on auttaa johtoa ja projektiryhmää ymmärtämään ongelmatilanne ja fokusoimaan tekeminen kriittisimpiin kohteisiin. Mikäli jo ylätason arvovirran kuvauksissa havaitaan, että ongelman taustalla olevat juurisyyt tulevat useista kohteista, kannattaa tekeminen jakaa osiin ja vaiheistaa.  

Jotta ongelman kuvaamisessa ja analysoimisessa päästään riittävän syvälle, on järkevää myös rajata fokus ensin kaikkien kiinnostavimpaan tuoteryhmään, palveluun, asiakkuuteen tai vaikkapa alueeseen. Hyvin tehdyn ”pilot”- projektin tuloksia voi sitten helpommin levittää ja mukauttaa laajemmin ja moninkertaistaa näin pilot-projektin hyödyt.

Kun projektin asettaja (kehityshankkeen omistaja) ja projektiryhmä ymmärtävät kirkkaasti, mitä ongelmaa projektilla ratkaistaan, mikä sen tavoite on ja miten tutkimus rajataan, on aika lähettää ongelmanratkaisijat kentälle DMAIC:in seuraaviin vaiheisiin! Johdon rooli siirtyy aktiiviseen projektin katselmointiin, havaittujen esteiden poistamiseen ja tuen järjestämiseen projektiryhmälle.

LSS-artikkelisarjassa käydään läpi DMAIC-suunnitelma vaihe vaiheelta.

Artikkelin kirjoittaja Black Belt Risto Lintula toimii kouluttajana Aalto PRO:n LSS-valmennuksissa. Hänen erityisosaamisalueitaan ovat mm. strategialähtöinen kehittäminen, kehittämistoiminnan johtaminen ja tuloksellinen toimeenpano, Lean- ja Six Sigma -menetelmien soveltaminen, analyyttiset ongelmanratkaisumenetelmät sekä prosessit ja johtamisjärjestelmät. Risto toimii osakkaana Nordic Process Improvement Oy:ssä.


Palaa Aalto Leaders' Insight -pääsivulle

Löydä lisää luettavaa ja kuunneltavaa