Monissa organisaatioissa välitön reaktio ongelman ilmetessä on ratkaisun etsiminen. Ongelmanasettelua käsitellään toissijaisena, melkein hallinnollisena vaiheena. Kokoukset seuraavat toisiaan, hypoteesit kiertävät ja toimintasuunnitelmia rakennetaan nopeasti.
Silti tämä hätiköinti tuottaa usein pettymyksen tuottavia tuloksia. Toteutetuilla toimenpiteillä on vain rajallinen vaikutus, vaikeudet ilmaantuvat uudelleen, joskus eri muodossa. Tunne toimimisesta peittää usein todellisen edistymisen puutteen.
Toistuva syy näihin epäonnistumisiin on ennen ratkaisuja, itse tavassa, jolla ongelma kehystetään. Epämääräinen tai vääristynyt ongelmanasettelu johtaa mekaanisesti riittämättömiin vastauksiin. Ennen toimimista on edelleen nimettävä täsmälleen se, mitä on ratkaistava.
Miksi tämä vaihe hätiköidään niin usein
DMAIC-logiikassa ensimmäinen vaihe — Define — on ongelman määrittelyn vaihe. Paperilla se avaa koko lähestymistavan. Käytännössä se hoidetaan säännöllisesti kiirehtien.
Tiimien huomio kääntyy spontaanisti analysointi- ja parannusvaiheisiin (Analyze ja Improve), jotka koetaan aktiivisemmiksi. Määrittelyvaihe (Define) näyttäytyy tällöin hallinnollisena esivaatimuksena, joka on ylitettävä nopeasti päästäkseen vakaviin asioihin.
Tällä hätiköinnillä on hintansa. Huonosti määritelty parannusprojekti kuluttaa aikaa, mobilisoi resursseja ja johtaa hauraisiin johtopäätöksiin. Alkuperäinen kurinalaisuus määrittää kaiken muun päättelyn.
Oireen kuvaileminen ei ole ongelman ilmaisemista
Aivan ensimmäisistä keskusteluista lähtien syntyy usein sekaannusta. Havaittavissa olevaa oiretta pidetään itse ongelmana.
Pidentyvä läpimenoaika, nouseva virheprosentti, toistuva asiakasvalitus: nämä ovat signaaleja, eivät ongelmia. Ne viestivät siitä, että prosessissa on jossakin toimintahäiriö. Ne eivät kerro mitään sen luonteesta, laajuudesta tai täsmällisestä sijainnista.
Oireen sekoittaminen ongelmaan johtaa näkyvän asian käsittelemiseen koskematta siihen, mikä ilmiön tuottaa. Tulos tunnetaan: vaikutus palaa heti, kun valppaus herpaantuu.
Syyn nimeäminen ei myöskään ole ongelmanasettelu
Toinen poikkeama koostuu oletetun syyn sisällyttämisestä itse ongelman muotoiluun. Ongelmanasettelusta tulee tällöin verhoiltu selitys.
"Toimitusajat pidentyvät, koska tiimeiltä puuttuu henkilökuntaa" ei ole ongelmanasettelu. Se on syyhypoteesi, joka esitetään tosiasiana. Diagnoosi on jo tehty, analyysi on oikosuljettu ja muut mahdolliset syyt tulevat näkymättömiksi.
Tämä sekaannus sulkee analyysin ennen kuin se on edes alkanut. Seuraavat toimenpiteet kohdistuvat oletettuun syyseen, joka ei välttämättä ole oikea.
Hyödyllisen ongelmanasettelun komponentit
Hyvä ongelmanasettelu pysyy neutraalina, kuvailevana ja mitattavana. Se kuvaa havaittua poikkeamaa ennakkoluulottomasti ilman sen alkuperän tai ratkaisun ennakointia. Se koostuu useista täsmällisistä elementeistä:
- mitä konkreettisesti tapahtuu, havaittavin meiningein
- missä ilmiö esiintyy, missä prosessissa tai millä linjalla
- milloin se ilmestyi ja kuinka usein sitä ilmenee
- mikä sen mittakaava on mittarilla ilmaistuna
- mitä poikkeamaa tämä tila heijastaa verrattuna odotettuun tilanteeseen
- mitä mitattavia seurauksia siitä aiheutuu organisaatiolle tai asiakkaalle
Yhdessä nämä elementit muuttavat epämääräisen valituksen toimintakelpoiseksi väitteeksi. Tiimi tietää tällöin, mitä se etsii, mistä etsiä ja miten tarkistaa, että se on löydetty.
Poikkeama odotetusta, minkä tahansa ongelmanasettelun kiintopiste
Käsitys poikkeamasta on keskeinen. Ilman viittausta odotettuun tasoon ei ole ongelmaa, on vain havainto.
Odotettu taso voi olla normi, sisäinen standardi, asiakassitoumus, suorituskykytavoite tai historiallinen taso. Olipa sen luonne mikä tahansa, se tekee ongelmasta ymmärrettävän. Se muuttaa raakaluvun mielekkääksi tiedoksi.
Ongelman määrittäminen tarkoittaa ennen kaikkea tämän kuilun nimeämistä. Niin kauan kuin odotettua tasoa ei tehdä näkyväksi, analyysi pyörii tyhjän päällä.
Johdon rooli ongelmanmäärittelyn laadussa
Tapa, jolla vaikeus kehystetään, riippuu pitkälti sitä ympäröivästä johtamisasenteesta.
Kun johto odottaa välittömiä vastauksia ja arvostaa toiminnan nopeutta, tiimit oppivat lyhentämään määrittelyvaihetta. Ongelma esitetään muutamalla sanalla, usein oletettuna syynä, ja keskustelu siirtyy välittömästi toimintasuunnitelmaan. Ongelmanmäärittelystä tulee muodollinen vaihe ilman todellista analyysin tarvetta.
Päinvastoin, kun johto ottaa aikaa kyseenalaistaa alkuperäisen muotoilun, pyytää dataa ja teettää uudelleenmuotoiluja, määrittelyn laatu nousee. Tiimi ymmärtää, että huonosti kehystetty ongelma on riski eikä yksityiskohta. Se investoi tarvittavan ajan sen hyvään kehystämiseen.
Tämä asenne vaatii tietynlaista kärsivällisyyttä, joka ei ole luontaista paineistetuissa konteksteissa. Mutta se vaikuttaa suoraan seuraavien ratkaisujen osuvuuteen. Johto, joka vaatii tiukkaa ongelmanmäärittelyä, säästää itsensä tarpeettomilta toistoilta.
Virheellisen ongelmanmäärittelyn merkit
Useat vihjeet paljastavat hauraan määrittelyn. Muotoilu sisältää ongelmaksi naamioidun toimintaverbin, kuten "viestinnän puute" tai "koulutustarve". Se esittää tuomion tosiasian sijaan. Se käyttää epämääräisiä termejä ilman niihin liittyvää mittakaavaa, kuten "liian usein" tai "paljon".
Se voi myös olla liian laaja käsittäen useita erilaisia ilmiöitä, tai päinvastoin liian kapea eristäen yksittäistapauksen ilman yleistä laajuutta. Kaikissa näissä tapauksissa lähestymistavan jatko kärsii.
Uudelleenmuotoilu ei ole ajanhukkaa. Se on olennainen vaihe.
Hätäisestä muotoilusta kestävään ongelmanmäärittelyyn
Vahvan ongelmanmäärittelyn rakentaminen ei ole kertaluonteinen harjoitus. Se on kurinalaisuutta, joka vakiintuu vähitellen organisaation käytäntöihin.
Tämä vaatii yksinkertaisia, tiimien jakamia kehyksiä, jotka palauttavat mieleen määrittelyn odotetut osat. Se vaatii myös määrittelylle omistettua aikaa, joka on erillään analyysi- ja ratkaisuajasta. Ja se vaatii johtoa, joka arvostaa tätä täsmällisyyttä yhtä paljon kuin toteutusnopeutta.
Kun nämä ehdot täyttyvät, parannusprojektien laatu edistyy näkyvästi. Analyysit voittavat osuvuudessa, ratkaisut kestävät aikaa ja rekyylit vähenevät. Ongelmanmäärittelystä tulee todellinen kestävän suorituskyvyn vipu, eikä pelkkä alustava Muodollisuus.
Tärkeimmät opit
- Huono ongelmanmäärittely johtaa mekaanisesti huonoon ratkaisuun
- DMAIC-mallin Define-vaihe hätiköidään usein suotta
- Oire ei ole ongelma
- Oletettu syy ei ole ongelma
- Ongelmanmäärittely kuvaa kuilua odotettuun tasoon
- Hyvä määrittely on neutraali, kuvaileva ja mitattavissa oleva
- Johto määrittää vaadittavan täsmällisyyden tason
- Alkuvaiheen täsmällisyys säästää aikaa koko projektissa
