Ongelmanhallinta

Mitä oikein ongelmanhallinta tarkoittaa ja miksi se on vaikeaa? Itil määrittelee ongelman yhden tai useamman insidentin tuntemattomaksi aiheuttajaksi. Määritelmä on hankala, eikä vastaa normaalia tulkintaa. Lisäksi yhden aiheuttajan etsiminen on harhaanjohtavaa ja johtaa suppeaan ajattelumalliin. On tavallista että ongelmilla on useita aiheuttajia. Luontevampi määritelmä on: Ongelma on epätyydyttävä tila, jonka muuttaminen ei ole helppoa. Siis ongelma on kokonaisuus eikä vain sen tuntematon aiheuttaja.

Ongelmiahan on kaikkialla ja niitä on opittu ratkomaan paljon ennen kun ensimmäiset tietokoneet olivat keksitty. Lisäksi ongelmien merkitys esimerkiksi terveydenhuollossa on paljon suurempi kuin tietotekniikassa. Vastaavasti prosessiteollisuudella on paljon enemmän resursseja käytettävissään, kun se haluaa estää tuotannon keskeyttävien ongelmien esiintymisen. Siksi ongelmanhallinta pitää opiskella muualta.

Ensimmäinen havainto on, että koko termiä ei juuri käytetä Itilin ulkopuolella. Ongelmanhallintaprosessien sijaan muilla aloilla puhutaan ongelman ratkaisuprosessista. Toinen asiaan liittyvä yleinen toiminto on riskienhallinta. Itilin ongelmanhallinta näyttää siis sisältävän elementtejä ongelmanratkaisusta ja riskienhallinnasta.

Itilin kakkosversiossa erotettiin toisistaan ongelman ratkaisu (ongelmakontrolli) ja riskienhallinta (virhekontrolli). Kolmosversio hävitti tämän eron. Kakkosessa määriteltiin myös proaktiivinen ongelmahallinta, joka taas unohtui kolmosversiossa.

Ongelmien ratkominen on pitkälti it:n sisäistä puuhaa ja usein varsin teknistä. Riskienhallinta on taas ylemmän johdon ja/tai asiakkaiden tehtävä. It-yksikön ja erityisesti tuotannon tehtävä on tunnistaa riskejä ja pyrkiä estämään niitä, mutta riskien arvioiminen ja varsinaiset päätökset ovat asiakkaiden vastuulla.  Nämä prosessit ovat varsin erilaisia.

Ongelmanratkaisuprosessi

Prosessin vaiheet ovat seuraavat:

1 Tunnista ja määrittele ongelma

Oikean ongelman tunnistaminen on ehkä tärkein vaihe. Jos vaikka asiakkaat valittavat järjestelmän hitaudesta ja hitauden syyksi paljastuu tietoliikenteen vaatima aika, voi olla virhe ryhtyä nopeuttamaan tiedonsiirtoa. Ongelma ei siis ole tietoliikenteen hitaus vaan asiakkaan kokema odotusaika. Ehkä kannattaisi tutkia, miksi pitää siirtää niin paljon tietoa.

2 Ongelman analysointi.

Tässä vaiheessa analysoidaan vaikutuksia. Ytimenä on ongelmanaiheuttajien etsiminen. Ongelmilla on tavallisesti useita aiheuttajia, joiden välillä on riippuvuuksia. Aiheuttajan etsimiseen on olemassa paljon menetelmiä, jotka ovat lähtöisin eri aloilta.  Näistä lisää myöhemmin.

3 Ratkaisujen luominen

Ongelmalle voi olla useita eri ratkaisuja. Ensimmäiseksi kannattaa pohtia, onko koko ongelma edes tarpeellinen, ts. tarvitaanko ongelmallista vaihetta lainkaan. Ratkaisun mahdollisia sivuvaikutuksia pitää myös tutkia. Esimerkkitapauksessa tiedonsiirron nopeuttaminen kuormittaisi palvelimia enemmän.

4 Ratkaisun valinta ja suunnittelu

Vaiheet 4-6 ovat itse asiassa muutoksenhallintaa mutta esitän ne tässä täydellisyyden vuoksi. On tärkeää että asiakkaan edustaja osallistuu muutoksenhallintaan.

Valitaan se ratkaisu tai ratkaisut, jotka toteutetaan. Suunnitellaan toteutus huolella. Suhteellisuustaju on tärkeää. Pienen ongelman ratkaisu ei saa aiheuttaa suurta haittaa.

5 Ratkaisun toteutus

Toteutetaan ratkaisu suunnitelman mukaisesti.

6 Ratkaisun arviointi

Arvioidaan miten hyvin ratkaisu toimi ja onko se aiheuttanut mahdollisesti uusia häiriöitä.

Ongelman analysointi (Root Cause Analysis)

RCA on ongelman ratkaisun varsinainen ydin. Se vaatii tietoa ja taitoa. Systemaattisuus on tärkeä elementti. Nopea RCA saattaa paljastaa yhden aiheuttajan ja siten ratkaista havaitun insidentin mutta se voi jättää todelliset aiheuttajat piiloon. Seuraavassa muutama menetelmä:

5X miksi

Kysy viisi kertaa miksi, niin löydät todellisen aiheuttajan. Tämä on nopea ja helppo ajatusharjoitus.

Ongelmapuu (kalanruoto)

Piirretään puu kaikista vaikuttavista tekijöistä. Tämä on laajennus viidestä kysymyksestä.

Muutosanalyysi

Verrataan ongelmaa ja tilannetta ilman ongelmaa. Kirjataan kaikki erot. Tapahtumat kuvataan aikajanalla, joka on ratkaiseva ero edelliseen.

Tarinan kertominen

Ongelma kuvataan tarinana, jonka avulla löydetään aiheuttaja. Tämä ei ole kovin systemaattinen menetelmä mutta kirjoittaminen ja dokumentointi auttavat.

Suoja-aita-analyysi

Control barrier on suojamekanismi, jonka tehtävänä on estää vahingon tapahtuminen, esim. salasana, palomuuri, lukko, varmistus jne. Jos vahinko on kuitenkin tapahtunut, on syytä tutkia, mikseivät suojamekanismit toimineet.

Ongelmakartoitus

Kartoitetaan kaikki asiaan vaikuttavat tekijät. Jokaiseen tekijään vaikuttavat tekijät käydään läpi, kunnes saadaan aikaan täydellinen kartta vaikutuksista ja niiden riippuvuuksista. Tulos esitetään karttana. Tähän on olemassa erilaisia kaupallisia työkaluja.

Riskienhallinta

Riskienhallinta on tärkeä osa normaalia johtamista. COSO määrittelee sen seuraavasti:

Enterprise risk management is a process, effected by an entity’s board of directors, management and other personnel, applied in strategy setting and across the enterprise, designed to identify potential events that may affect the entity, and manage risk to be within its risk appetite, to provide reasonable assurance regarding the achievement of entity objectives.

Riskienhallinta on siis yrityksen hallituksen hallussa oleva prosessi. Lainaan tähän esimerkiksi Stockmannin kuvauksen konsernin riskienhallinnasta:

Riskienhallinta

Tavoitteena on turvata konsernin tuloskehitys ja varmistaa liiketoiminnan häiriöttömyys toteuttamalla riskienhallintaa kustannustehokkaasti ja systemaattisesti eri liiketoimintayksiköissä. Tavoitteiden saavuttamiseksi riskienhallinta on Stockmann-konsernissa järjestetty siten, että

  • se on osa normaalia liiketoimintaa ja johtamista.
  • se on prosessi, jossa tunnistetaan, arvioidaan ja hallitaan niitä liiketoimintariskejä, jotka voivat estää tai vaarantaa liiketoiminnan tavoitteiden saavuttamisen.
  • sitä tukevat sisäiset kontrollijärjestelmät (ohjeet, rutiinit ja menettelytavat). Riskienhallintaohjeistusta on erikseen laadittu mm. seuraaville osa-alueille: IT ja tietoturva, rahoitustoiminto, ympäristöasiat, väärinkäytökset, turvallisuus ja vakuutukset.

Stockmannilla it-johto ei kuulu riskienhallinnan johtoryhmään.  Riskienhallinta ei siis ole it-yksikön toimivaltaan kuuluva asia, joskin it-yksikkö toki vastaa oman alueensa riskienhallinnasta. Riskienhallinnan vaiheet ovat:

  1. uhkien tunnistaminen, luokittelu ja arviointi
  2. kriittisten järjestelmien haavoittuvuuden arviointi
  3. mahdollisen vahingon arviointi
  4. riskien välttämiskeinojen etsiminen
  5. riskien vähentämisen priorisointi strategian pohjalta

On tärkeää, että asiakkaat osallistuvat sekä riskien vaikutusten arviointiin, että korjaavien toimenpiteitten priorisointiin.

Tunnistettu ongelma on siis myös tunnistettu riski.

Asiakkaan ongelmasta riskiin

Kun asiakas kohtaa ongelman, hän yleensä yrittää ratkoa sitä monin tavoin ennen kuin pyytää apua tukipalvelusta. Onnellisessa tapauksessa tukipalvelu tunnistaa pulman ja osaa ratkaista sen. Kyseessä voi olla esimerkiksi asiakkaan tekemä tavallinen virhe, joidenkin järjestelmien yhteensopimattomuus tai tunnettu vika johon on olemassa toimiva kiertotie.

Mikäli tukipalvelu ei tunnista ongelmaa, sen pitää ryhtyä ratkomaan sitä. Tässä vaiheessa käynnistetään ongelmanratkaisuprosessi, mutta sen on tapahduttava insidentinhallinnan alaisuudessa, koska insidentti on edelleen auki. Insidentti voidaan sulkea kun ratkaisu on löytynyt ja asiakas on tyytyväinen.

Löydetty ratkaisu ei ole aina kovin hyvä, se voi esim. edellyttää manuaalisia toimenpiteitä. On myös mahdollista, ettei ongelman syitä ymmärretä täysin vaikka se kyettiinkin poistamaan. Tällöin on selvästi riski ongelman uusimiselle. Näissä tapauksissa ongelman ratkomista pitää jatkaa.

Kyky ratkoa ongelmia on rajallinen. On mietittävä mitkä ongelmat kannattaa ratkaista. Tämä on osa riskienhallintaa, jokainen avoin ongelma on myös riski. Pieni it-ongelma voi olla iso riski organisaatiolle. Esimerkiksi Stockmannin Hullujen Päivien avaus vaarantui kun tietoliikenneyhteydet eivät toimineet.

Visa ja Mastercardien toimimattomuus johtui Stockmannin Hullujen Päivien aiheuttamasta tietoliikenteen ylikuormittumisesta. Ylikuormitus jumitti tietoliikennelinjan, joka välittää korttivarmennuksia luottokuntaan. Stockmannin tietoliikennettä hoitaa Fujitsu.  Maksuliikenne Luottokunnan ja Stockmannin välillä keskeytyi keskiviikkoaamuna reiluksi tunniksi.

”Positiivinen ongelma sinänsä, että myynti vetää niin hyvin. Selvitämme asiaa kovasti Fujitsun kanssa ja teemme yölläkin muutostöitä varmennusyhteyksiin, jotta saamme linjat varmasti toimimaan loppuviikoksi”, luottokunnan kauppiaspalveluiden johtaja Björn Ulander sanoo. http://www.kaleva.fi/uutiset/nordean-kortit-eivat-toimi/872691

Vaikka vika korjattiin pian, se saattoi vähentää myyntiä ja konsernin tulosta ja kuuluu edellä kuvatun konsernitasoisen riskienhallinnan alaisuuteen.

Mikä on sitten tukipalvelun ja riskinhallinnan välinen yhteys ja mikä on ongelmanhallinnan rooli siinä. Pitää hallita ongelmanratkaisuprosessi, mutta sitä tarvitaan monessa paikassa. Ongelmanratkaisuprosessi on siis alaprosessi, jota monet funktiot käyttävät päivittäisessä työssään.

Malli toimii siis näin. Tukipalvelu ratkoo asiakkaan ongelmia ja saattaa havaita mahdollisia riskejä. Riskit raportoidaan riskienhallinnalle, joka tarvittaessa ratkoo ja hallitsee niitä. Ongelmanratkaisuprosessi toimii sekä tukipalvelun sisällä, 2-tai 3-tasolla että riskienhallinnan sisällä. Ongelmanhallinta ja erityisesti  proaktiivinen ongelmanhallinta on osa riskienhallintaa. Riskienhallinta on laaja prosessi, kapasiteetin-, käytettävyyden, jatkuvuuden ja tietoturvanhallinta ovat myös osa sitä. Organisaation koosta riippuen voi olla järkevää joko jakaa riskienhallinta osaprosesseihin itilin tapaan tai sitten pitää se yhtenä prosessina.

PS Kannattaa lukea Marko Jäntin erinomainen komentti tähän artikkeliin.

3 vastausta

  1. Kiitos mielenkiintoisesta artikkelista…Perinteisessä ohjelmistotuotannossa puhutaan ongelmanhallinnan sijaan usein virheidenhallinnasta [1] eli Defect Management tai bugien raportoinnista ja ratkaisemisesta. SEI:n raportista löytyy määritelmät sekä virheille että ongelmille [2]:

    ”We will define a software defect to be any flaw or imperfection in a software work product
    or software process.

    ”A software problem is a human encounter with software that causes difficulty, doubt, or
    uncertainty in the use or examination of the software.”

    Lisäksi SEI:n raportissa todetaan villi nimeämiskäytäntö ongelmille:

    ”Many terms are used for problem reports throughout the software community: incident report, customer service request, trouble report, inspection report,
    error report, defect report, failure report, test incident, etc.” [2]

    ITIL:n jaotteluun katoaa joskus itseltäkin usko yön pimeinä tunteina ja pohdin onko tikettiviidakossa mitään mieltä (incident, service request, problem,known error, RFC, change, release package). Problemin ja known errorin sekä RFCn ja Changen voi onneksi vetää samoilla tiketeillä.

    Itse peilaisin virhekontrollia enemmänkin Defect Managementiin kuin riskienhallintaan eli siinä voitaisiin keskittyä pitempää tutkimista vaativien ohjelmistovirheiden tai muiden tunnettujen virheiden käsittelyyn. ITIL toteaa error controlin keskittyvän tunnettujen virheiden käsittelyyn muutoksenhallinnan kautta.

    Havaintojeni mukaan suuri haaste on saada yrityksessä ihmiset tajuamaan tapahtuman ja ongelman välinen ero eli, että asiakkaan raportoima ”potentiaalinen vika”
    kirjataan ensin TAPAHTUMANA eikä ONGELMANA. ONGELMA voi olla kyseessä, jos
    1)TAPAHTUMAAN ei saada ratkaisua SD:ssä eikä taustatuessakaan (back office)
    2) SD tai BO epäilee tapahtuman toistuvan
    3) Havaitaan selvästi toistuva tapahtuma missä tahansa päin asiakastukea
    4) IT-infran valvonta (esim. valvomo) havaitsee ongelman, joka voi johtaa tapahtumien syntymiseen
    5) Proaktiivisten menetelmien käytön (Trendianalyysi, korjaavien toimenpiteiden määrittely, laajavaikutteisten ongelmien katselmoinnit) aikana havaitaan potentiaalinen ongelma.

    Huom! Kaikkea roskaa ei tarvitse kierrättää ITIL:n mukaan tapahtumanhallinnan kautta, vaan sovelluskehitykseltä, testaukselta ja 3. osapuolilta tulleet virheet voitaisiin suoraan ongelmana tai tunnettuna virheenä. Yleensä vaan kaverit yrityksissä ensin pakotetaan tallentamaan kaikki tapahtumina ja sittenpä on hauska kertoa heille PM-prosessin kehitysvaiheessa, että ongelmia saa kirjata myös suoraan. Allekirjoittanut totesi v-kirjasssaan näin: ”The third challenge arises from poorly defined connection between problem management
    and software testing and defect management.”[3]

    Ongelmanhallintaa voivat toteuttaa esim. taustatuen (2-taso) kaverit sovittuina viikonpäivinä, jolloin ei vastata puhelimeen sekä sovelluskehitys (3-taso), joka selvittää ohjelmistovirheen ratkaisua ja arvioi ratkaisun vaikutuksia. Riskienhallinnan pitäisin itse visusti jatkuvuudenhallinnan puolella.

    Hankalat käsitteet on todella eräs suurimmista haasteista ITIL-hankkeissa [3]: ”Service management
    frameworks use concepts (incidents, known errors, service level agreements) that have
    not been used in traditional software development models.”

    On myös haaste saada sovelluskehittäjät luopumaan omista bugienhallintasoftista ja excel-taulukoista ja kirjaamaan asiat suoraan IT-palvelunhallintatuotteeseen. Tässäpä oli vuodatusta ongelmanhallinnasta ja virheidenhallinnasta. Menisiköhän ITIL-asia paremmin perille sovelluskehittäjille, jos puhuttaisiin Problem and Defect management -prosessista?

    Lähteet:

    1. Quality Assurance Institute: Establishing a Software Defect Management Process. QAI Research Report 8, 1995.

    2. Florac W.: Software Quality Measurement: A Framework for Counting Problems and Defects. Technical Report, 1992

    3. Jäntti M.: Difficulties in Managing Software Problems and Defects. PhD Thesis. University of Kuopio, 2008.
    http://www.uku.fi/vaitokset/2008/isbn978-951-781-990-9.pdf

    • Hyvä näkökulma. Minä keskityin tässä IT:n ulkopuolisiin menetelmiin mutta tosiaan softakehitys tuo mukaan vielä yhden näkökulman.

      Tietysti voi väittää että softa-bugitkin ovat laajasti katsottuna riskejä mutta olet oikeassa että palvelunhallinnan ja sovelluskehityksen linkit on määritelty heikosti.

  2. […] Ongelmanhallinta […]

Kommentointi on suljettu.

%d bloggers like this: