Ongelmat

Löysin twitter-arkistosta vanhan twiittini syyskuulta 2009: It was fun to explain the concepts of incident, problem, error KE to a class who had not heard the terms before. They have power! Eli olin selittänyt insidentin, ongelman, virheen ja tunnetun virheen käsitteitä kurssilla ja saanut innostuneen vastaanoton. Nuo käsitteet selkeyttivät monia asioita ja ihmiset tajusivat havaitsemiaan ilmiöitä käsitteiden avulla. Ne auttoivat jäsentämään omaa työtä ja olivat siinä mielessä hyödyllisiä.

Jos määritelmät ovat unohtuneet, niin kertaan niitä tässä nopeasti. Itilin määritelmän mukaan ongelma (problem) on yhden tai useamman häiriön (insidentin) tuntematon perussyy (root cause) ja error tai known error on sitten tunnistettu virhe, joka aiheuttaa insidentin.

Kun itiliä kirjoitettiin, havaittiin että usein häiriöiden korjaaminen vei niin paljon aikaa, ettei niiden syihin ehditty puuttua. (Kun itse olin asiakaspalvelun päällikkö, huomasin että usein syynä ei ollut mikään kiire, vaan ennemmin laiskuus.) Tämän takia päätettiin luoda erillinen ongelmanhallinnan prosessi eli Problem Management. Prosessi osoittautua vaikeaksi ja se sai monta erilaista ja väärää tulkintaa. Ongelmanhallinnasta tuli usein vain tapa käsitellä vaikeita häiriöitä. Versio 3:n kirjoittajat kirjoittivatkin prosessin uusiksi havaitsemiensa käytäntöjen pohjalta eli kirjasivat väärinkäsitykset uudeksi parhaaksi käytännöksi. Tämä sitten korjattiin vuoden 2011 versiossa, mutta lopputulos ei onnistunut vieläkään.

Itilin ongelmanhallinta on epämääräinen käsite. Pohjimmiltaan ongelmanhallinta ja häiriönhallinta ovat samoja prosesseja ja tekevät samoja asioita. Tämä on resurssien tuhlausta ja sotkee toimintaa. On aivan selvää että yksi prosessi riittää häiriöiden ratkomiseen.

Olen aiemmin tässä kirjoitussarjassa erottanut asiakkaan ongelman ja häiriön toisistaan. Asiakkaan ongelma on tilanne, jossa asiakas tarvitsee apua jonkin tavoitteen saavuttamiseen. Häiriö on tilanne, jossa joku asia ei toimi halutulla tavalla. Häiriö voi aiheuttaa asiakkaan ongelman, mutta ongelmia voi olla ilman häiriöitä. Häiriön korjaamisen pitää ulottua myös häiriön aiheuttajien käsittelyyn. Emme missään nimessä tarvitse erillistä prosessia vaikeiden häiriöiden korjaamiseen, on vastuutonta toimintaa palauttaa vain palvelu takaisin selvittämättä miksi se häiriintyi.

On selvää, että palveluja pitää kehittää. Tunnetut viat (Known Error) ovat jokapäiväinen ilmiö. Kaikkia vikoja ei kannata korjata. Asiakkaiden ongelmia voi myös ilmetä ilman minkäänlaisia häiriöitä eli asiakas joutuu ongelmiin vaikka palvelut toimivat aivan oikein. Häiriöt voivat toistua vaikka niiden aiheuttajat on korjattu.

Itil tarjoaa liudan ”prosesseja” palvelun kehittämiseen ongelmanhallinnan lisäksi, löytyy jatkuvuuden hallinta, kapasiteetin hallinta tietoturvanhallinta ja tietysti jatkuva palvelun kehittäminen. Jos siis äkilliset tilantarpeet aiheuttavat palvelukatkoja ja tietoturvariskejä niin mikä ”prosessi” ottaa vastuun?

Ehdotan, että nämä kaikki korvataan yhdellä prosessilla. Riskienhallinta on tarpeellinen, suorastaan välttämätön toiminta, joka tunnistaa riskit ja valitsee niiden käsittelytavan. Lisäksi kaikilla organisaatioyksiköillä ja jopa henkilöillä pitää olla vastuu palvelun kehittämisestä. Jokaisen pitää tarttua havaitsemiinsa mahdollisuuksiin parantaa palvelua.

Mielestäni siis ongelmanhallintaa ei tarvita. Se voidaan korvata riskienhallinnalla. Service Deskin vetäjällä ja kaikilla prosessipäälliköillä on vastuu olla aktiivisesti mukana palvelun laadun kehittämisessä.

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s

%d bloggers like this: