tiistai 13. lokakuuta 2009

Create problem!

Niin, tuollainen nappula löytyi (* aikanaan Remedyn ITSM-suiten Service Desk -työkalusta. Vaikka sanamuoto on hassu, se on oikeasti hyvä nappula. SD:n pitää tietenkin vain tietää ensin, mikä on insidentin ja ongelman ero. Jääköön se nyt vielä jännitettäväksi.

Olen monesti kannustanut yrityksiä aloittamaan ongelmanhallinnan, jos sitä ei vielä tehdä (useinkaan sitä ei kyllä tehdä kun on niin kiire sammuttaa tulipaloja..). Esimerkkinä käytän mm. erästä suomalaista suuryritystä, jonka CIO käynnisti toiminteen yksinkertaisesti perkaamalla alkuun itse niitä tikettitrendejä - "Hei Jaska, tossa on 20 samannäköistä insidenttiä, tsekkaatko löytyykö taustalta jokin perussyy?". Ken Goff kertoi itSMF-konferenssissa mainion esimerkin, miten pienellä vaivalla vähennettiin 50 major insidenttiä / kk viiteen - resursoimalla ongelmanhallintaan.

Olen myös usein viitannut ITIL-kirjojen työkaluihin - niin, sieltä löytyy monta hyvää, yksinkertaista tapaa tehdä järjestelmällistä ongelmanhallintaa. Eivät ne mitään uusia ole vaan jo vakiintuneita malleja. Hyvä puoli tässä on se, että ne työkalut löytyvät nyt siitä samasta pakista niiden prosessimallien kanssa.

Kokosin nyt tähän niitä työkaluja esimerkeiksi vapaasti kääntäen ITIL Service Operation -kirjasta.

Kronologinen analyysi

Kun työskentelee vaikean ongelman parissa, löytyy usein ristiriitaisia kirjauksia tai raportteja siitä, mitä tapahtui ja milloin. Silloin on hyvin hyödyllistä listata tapahtumat aikajärjestyksessä niin, että saa selkeän aikajanan tapahtumista. Tämän avulla on mahdollista nähdä, mitkä tapahtumat ovat johtaneet mihinkin ja mitkä eivät selvästikään kuulu joukkoon.

Kipuarvoanalyysi

Onpas suomennos. Pain value analysis on siis kyseessä.

Tässä tarkastellaan insidenttien tai ongelmien (tai ongelmatyyppien) vaikutusta laajemmin. Pelkän tiettynä aikana tapahtuneiden asioiden lukumäärän tarkastelun sijaan tutkitaan tarkemmin sitä, miten paljon organisaatio tai liiketoiminta kärsii näistä insidenteistä/ongelmista. Kipuarvon laskemiseen voidaan muodostaa kaava esimerkiksi ottaen huomioon seuraavioa asioita:
- ihmismäärä, johon asia vaikuttaa
- häiriön kestoaika
- kustannus liiketoiminnalle (jos mahdollista määrittää)

Näiden tekijöiden summana saadaan yksityiskohtaisempi kuva vaikutuksesta ja päästään keskittymään merkittävimpiin asioihin. Siis priorisoidaan.

Kepner ja Tregoe

Charles ja Benjamin kehittivät aikanaan hyvän tavan analysoida ongelmia ja saivat nimensä kirjoihin. Malliin kuuluvat seuraavat vaiheet:
- määritä ongelma
- kuvaa ongelman yksityiskohdat - sijainti, aika, koko...
- arvioi mahdolliset syyt
- kokeile todennäköisimpien syiden ratkaisua
- todenna todellinen syy.

Brainstorming

Tämäkin on hyvä tapa ongelmanratkaisuun. Kootaan oikeati ihmiset palaveriin ja pyöritellään ongelmaa ideoiden mahdollisia syitä ja niiden ratkaisuja. Brainstorming voi olla hyvin tehokas ja innovatiivinen tilaisuus mutta jonkun pitää dokumentoida tuotokset ja ylläpitää etenemistä - ongelmapäällikölle hyvä tehtävä!

Ishikawa-kaaviot

Japanilainen laatuguru Kaoru Ishikava kehitti kalanruotometodin mahdollisten vikatilanteiden syiden ja seurausten dokumentoimiseen. Mallin avulla voidaan myös ohjata kehitystyötä. Kaavio voi olla tuotos brainstorming-sessiostakin. Päätavoite esitetään selkäruotona ja sen päätekijät haaroina, joihin piirretään ruotoja lisätekijöille. Monimutkaisetkin ongelmat voidaan saada näin avattua yksityiskohtia myöten.


Tältä se siis näyttää (Wikipedia)

Pareto-analyysi

Tällä tekniikalla voidaan erottaa ne suurimmat ongelmien lähteet yksinkertaisemmista asioista. Teorian mukaan 80% ongelmista aiheutuu 20% syistä.

Analyysin askeleet ovat seuraavat:

- tee lista ongelmalähteistä ja niiden aiheuttamien ongelmien prosentuaalisesta osuudesta
- sorttaa lista niin, että todennäköisimmät syyt ovat ensin
- lisää sarake kumulatiivista prosenttiosuutta varten
- tee palkkidiagrammi jossa ongelmalähteet ovat vaikutusjärjestyksessä
- lisää viivadiagrammi kumulatiivisesta vaikutuksesta
- erota 80% aiheuttavat ongelmalähteet ja lähde ratkaisemaan

Siis näin:


Lähde: http://erc.msh.org/quality/pstools/pspareto.cfm

Yksinkertaisempiakin työvälineitä löytyy - vikapuuanalyysi (Fault Tree Analysis FTA) jossa piirretään infra puun muotoon lähtien palvelusta. Komponenttien vika-analyysi (Component Failure Impact Analysis CFIA) auttaa varautumaan ja varmistamaan tärkeimpien infrakomponenttien toiminnan.

Nämä työkalut kuvauksineen löytyvät siis ITIL Service Operation -kirjasta sivulta 62 ja liitteistä C ja D. Hyvä alku - kokeile!

(* on siellä kai vieläkin joku tuollainen nappula, taitaa jopa olla samalla tekstillä.

1 kommenttia:

Anonyymi kirjoitti...

Coach Kimotto tässä
Esitelet näppäriä ongelman ratkaisuja. Mieleeni nousi ajatuksia luovan ongelman ratkaisun välineistä ja psyyken käytöstä eityisesti ei-tietoisesti. Työkaluna toimii "Terästetty rentous", jolle on ominaista alitajuinen prosessointi syvärennossa tilassa.
Alan kirjoittajista lisää toiste.

Template by - Abdul Munir | Daya Earth Blogger Template