Ongelmista ja niiden ratkaisemisesta

Mikä on ongelma, mikä on juurisyy? Onko ongelmanratkaisu ja parantaminen sama asia? Tässä artikkelissa pyrin tuomaan ainakin yhden näkökulman näihin kysymyksiin.

Yritykset ovat investoineet huomattavia rahasummia ja aikaa ongelmien ratkaisemiseen. Tästä huolimatta samat ongelmat toistuvat uudestaan ja uudestaan. Ongelmien vaikutukset asiakkaille, loppukäyttäjille, työntekijöille, tuottavuuteen ja kilpailukykyyn ovat huomattavia.

Laadunhallintajärjestelmiä koskeva standardi ISO 9001 edellyttää tarvittaessa selvittämään poikkeamien syyt, mutta ei kerro miten tämä pitäisi tehdä, onneksi ongelmanratkaisumenetelmistä ei ole puutetta. Esimerkkeinä mainittakoon lean-menetelmänä tutuksi tullut A3 ja autoteollisuudessa käytetty 8D.

Yhteistä useimmille menetelmille on tarve löytää ongelman aiheuttaja ns. juurisyy, ongelma lähde tai perimmäinen syy syyketjussa. Juurisyyn poistaminen estää (tai merkittävästi vähentää todennäköisyyttä) ongelman uudelleenilmaantumisen. Tässä yhteydessä juurisyyn määritelmään on lisättävä ehto siitä, että sen on oltava tavalla tai toisella yrityksen johdon hallittavissa. Eli Suomessa liukastumisen juurisyy ei ole se, että talvella on liukasta, vaan pitää tutkia toista haaraa: miksi liukkauden torjuntaa ei oltu suoritettu asianmukaisesti tai miksi ei käytetty oikeita varusteita liukastumisen estämiseksi. Tavoitteena täytyy aina olla ongelman uudelleenilmaantumisen estäminen ja jos syy on oman vaikutuspiirimme (systeemimme) ulkopuolella ovat vaikutusmahdollisuutemme vähintäänkin rajallisia tai pahimmassa tapauksessa olemattomia.

Valitettavan usein juurisyyn etsintä kuitenkin unohtuu ongelmanratkaisua tehtäessä kokonaan, on kiire hypätä ongelmasta suoraan ratkaisuun. Tyypillisesti toiminta menee jotensakin näin: meillä on ongelma ➔ ideoidaan toimenpiteitä ➔ taulukoidaan toimenpiteet ➔ nimetään vastuulliset ➔ siirrytään ”ratkaisemaan” seuraavaa ongelmaa.

Juurisyyn löytäminen on harvoin triviaalia, vaikka haluaisimme uskoa näin olevan. Oleellisia asioita ovat tarkka ongelman ymmärtäminen ja kuvaaminen, prosessin tuntemus ja monesti erilaiset graafiset ja tilastolliset data-analyysimenetelmät, joiden avulla juurisyy tai juurisyyt saadaan esiin. Verta, hikeä ja kyyneleitä joudutaan siis tämänkin asian tiimoilta kuvainnollisesti vuodattamaan.

Kaikkia ongelmia ei ole järkevää, eikä taloudellisesti kannattavaa, alkaa näin syvällisesti perkaamaan, kriittistä on erottaa ne ongelmat, jotka ovat tri. Juranin termein sporadisia (palataan tähän myöhemmin) ja estää niiden uudelleenesiintyminen. Juurisyiden selvittämiseen on olemassa omat tekniikkansa (RCA, Root Cause Analysis) ja prosessinsa, jotka pitää tuntea ja osata, jotta haluttuun lopputulokseen voidaan päästä. Pitää tehdä oikeita asioita ja pitää tehdä asiat oikein.

Tässä kohdin kannattaa kerrata Antin artikkeli Neljä ongelmaa, neljä lähestymistä, käytän samaa 4-portaista luokittelua. Lyhyenä kertauksena; tyypin 1 ja 2 ongelmat liittyvät tilanteeseen, jossa prosessimme tuotos ei ole sitä mitä sen suunnitelman mukaan pitäisi olla. Esimerkiksi virheiden määrä on kasvanut aikaisemmasta, toimitusvarmuus on romahtanut, linja on pysähtynyt, vaikka sen pitäisi liikkua jne. Hieman yksinkertaistaen voisi sanoa, että on tapahtunut jokin yksittäinen muutos. Tyypin 3 ja 4 ongelmat taas kuvaavat tilannetta, jossa ei niinkään puhuta ongelmista vaan enemmänkin tarpeesta parantaa. Esimerkiksi toimitusvarmuutemme on tällä hetkellä 90 % mutta haluaisimme, että se on 95 % tai haluamme parantaa linjamme käytettävyyttä tietyn määrän jne.

Ongelmanratkaisu ei siis ole sama asia kuin parantaminen, ongelmanratkaisua tarvitaan, jos emme pääse ns. normaalille suoritustasolle, parantamista taas, jos haluamme nostaa suorituskyvyn uudelle tasolle (kuva 1). Tehdään siis selkeä ero ongelmanratkaisun (tyypit 1 ja 2) ja parantamisen (tyypit 3 ja 4) välillä, tämä artikkeli keskittyy ongelmanratkaisuun.

Ongelmanratkaisu on reaktiivinen (toimitaan tapahtuman jälkeen) prosessi, jonka avulla toiminta pyritään palauttamaan ennalta suunnitellulle tasolle. Cynefin viitekehyksen kautta ajateltuna ongelmanratkaisu kuuluu järjestyksen alueeseen (selkeä tai monimutkainen), jossa syy-seuraussuhteet ovat löydettävissä ja toiminta tapahtuu prosesseissa.

Ongelmanratkaisu kuuluu oleellisena osana Tri. Joseph M. Juranin laadun trilogiaan (kuva 2), ongelmanratkaisua tarvitaan ns. sporadisten piikkien taklaamiseen. Sporadinen tarkoittaa harvinaista tai yksittäistä, mutta mistä sitten tiedetään mikä on harvinaista tai yksittäistä? Mihin pitää reagoida ja mihin ei?

Menetelmä on ollut olemassa jo lähes 100 vuotta. Vuonna 1924 Tri. Walter A. Shewhart esitteli tilastollisena prosessinohjauksena (SPC, Statistical Process Control) tunnetuksi tulleen menetelmän, jonka avulla pystymme selvittämään, milloin reagointi on taloudellisesti kannattavaa ja toisaalta, milloin yksittäiseen tapahtumaan reagoinnista on enemmän haittaa kuin hyötyä, eli miten erityisyyt ja satunnaissyyt erotellaan toisistaan. Tohtori Shewhartin keksintöä pidetään modernin laatuteorian lähtölaukauksena ja perustana laadun parantamiselle.

Tohtorit Hoerl ja Snee tiivistivät eri toimintavaihtoehdot vuoden 2013 artikkelissaan kuvan 3 mukaisesti. Ongelmanratkaisu kuuluu tilanteeseen (2), jossa

1. Ratkaisu ei ole vielä tiedossa
2. Kompleksisuuden aste on matala (Cynefin)
3. Ongelma on erityissyyn aiheuttama (SPC)

Ongelmanratkaisu ei ole mikään ihmelääke kaikkiin vaivoihin, vaan täsmäase tiettyihin tilanteisiin ja väärin käytettynä joko hyödytön tai haitallinen.

Lähteet:

1. Root Cause Analysis – Simplified Tools and Techniques 2nd edition, Andersen, Bjorn & Fagerhaus, Tom, ASQ Quality Press, 2006
2. Root Cause Analysis – The Core of Problem Solving and Corrective Action 2nd edition, Okes, Duke, ASQ Quality Press, 2019
3. Four types of problems, Smalley, Art, Lean Enterprise Institute, 2010
4. Juran’s Quality Handbook 7th edition, De Feo, J. A. & Juran, J. M., McGraw-Hill, 2017
5. SFS-EN ISO 9001:2015, Suomen Standardisoimisliitto SFS ry, 2015
6. One Size Does Not Fit All, Hoerl, Roger W. & Snee, Ronald D., Quality Progress, 5/2013