Don’t box your thinking

I have seen several examples where people are locked to old thinking in ITSM. That happens to all of us and not just in ITSM. Old thinking habits and beliefs are hard to change.

One important source for artificial limits in thinking can be a framework like ITIL. I have commented on this in a few discussions on Back2ITSM and LinkedIn but I want to discuss this a bit more seriously as Bart van Brabant asked.

It seems that many practitioners are hampered by ITIL models and concepts and waste their time in trying to fit reality in an ITIL box. These barriers are completely artificial and should be removed.

Here are some examples:

ITIL does not handle feedback well. It is clear that customers will give feedback via various channels and it is valuable information which should be collected. Do not waste time in trying to fit it in ITIL processes, feedback is not incidents or requests.

ITIL does not describe production. It is the nature of production to change things. Production can be a bit messy, especially if humans are involved. Do not use change management in normal production work, David Nottingham.

Incident-Problem model is very primitive. When a customer has a problem, he wants to have a solution to the problem. This is not the same as restoration of service. You need to fix the customer and you need to fix the service and these are two different things.  When you fix the service, you need to do it well, not just hash it and leave it to Problem management for proper fixing.

The whole idea of Problem Management as a process is wrong. The activity is risk management and problem solving is a capability.

ITIL service definition describes leasing or renting. Leasing is a simple service which can easily be described in a service catalog. IT services are much more complex. You need to manage service proposals, service systems and service acts. ITIL won’t guide you there.

If your IT service has huge amounts of incidents and most of your energy goes to restoring service it is clear that the root cause is incompetence. The best solution is not implementing ITIL but to fire the staff and outsource the service. Contact James Finister. (I won’t say no to finders fees, James 😉

ITIL was a great idea and it has helped many of us to understand ITSM and see some basic structures in the field. Now you must move forward. There are no simple solutions in a box or book. Do not look for a new ITIL.

Mitä vikaa ongelmanhallinnassa

Aloitan pian eli 18.6. klo 15 webcast esityksen aiheesta linkki on tässä

Muistoja menneisyydestä

Olin maanantain ja tiistain itSMF UK:n 21. konferenssissa. Oli todella upeata nähdä miten hienosti sosiaalinen media toimii. Sosiaalisen median kautta tutustuu erittäin helposti ihmisiin ja kun on keskustellut verkossa, on luonteva jatkaa keskustelua livenä.

Konferenssissa oli muutama erinomainen esitys, joista vaikuttavin oli Simon Wardleyn keynote. Hän kuvasi hienosti luovan tuhon kierrettä. Luova tuho hävittää vanhan ja tilalle tulee jotain uutta ja parempaa. Muutos ei ole pehmeä ja mukava asianomaisille, vaan tuho on todellista tuhoa, sotaa. Sitä edeltää mukava tasaisen elämän vaihe, jolloin kasvu on tasaista ja elämä näyttää varmalta sekä turvalliselta. Näin suomalaisittain Nokia on loistava esimerkki.

Tuhon käynnistää yleensä jokin teknologinen oivallus, joka mahdollistaa uuden tavan toimia. On helppo havaita että printtimedia eli lehdet ovat juuri tässä vaiheessa. Sama koskee myös meitä jotka painimme IT-palvelunhallinnan parissa. Maailma muuttuu vaikka kuinka pyristelisimme vastaan.

Tätä avausta vasten oli piinallista nähdä, miten konferenssissa jauhettiin iänikuisia vanhoja asioita. Valtaosa esityksistä oli ITIL prosesseista, pelkästään incident-problem  -pulmaa käsiteltiin useassa esityksessä. (Incident-problem -pulma ratkeaa heti, kun päätät unohtaa ITILin opetukset). Tuntui kuin ajattelu oli jäänyt junnaamaan menneisyyteen. Tunnelmaa vahvisti se, kuinka esitysten välissä näytettiin videota konkareiden muisteluista.

***

Pidin itse Unlearning ITIL -esityksen ja vastaanotto oli mahtava. Kaikki ITIL ”heavyweights” tulivat etuosaan, joten painetta riitti. Esitys oli pitkälti sama, jonka pidin Suomen itSMF-konferensissa vuosi sitten, ja ne jotka olivat kuuntelemassa muistanevat, että pöllytin ITILiä aika lailla. Se oli helpompaa, kun salissa ei istunut ITILin kirjoittajia 😉

Esitys sai aikaan vipinää Twitterissä ja kannatusta löytyi.  Minut pyydettiin saman tien pitämään esitys Viron itSMF-konferenssissa ja lisäksi tiedusteltiin, voisinko lähteä myös Australiaan pitämään saman esityksen.

***

Konferenssin aikana puhuin riskienhallinnan liian pienestä osuudesta it-palvelunhallinnassa. Asiantuntijat olivat samaa mieltä. Riskienhallinta on tärkeää ja se on jäänyt liian vähälle huomiolle. Tähän mennessä 28.11. pidettävään Riskienhallinnan työpajaan on myös ilmoittautunut liian vähän osallistujia ja todellakin haluaisin pitää sen. Työpaja ei tarkoita pelkästään että tulet opiskelemaan jotain vaan työpaja luo uutta ymmärrystä. Korjaa tilanne ja ilmoittaudu nyt.

60 vuotta

Tänään tuli 60 mittariin, jotenkin tuntuu kuin sisällä asuisi vielä se parikymppinen, joka on sitä mieltä että vanheneminen on jotain sellaita mikä tapahtuu muille.

En aio juhlia mitenkään erityisesti, normaali työpäivä siis. Ajattelin kuitenkin muistella vähän menneitä tämän it-maailman näkövinkkelistä.

Oma urani tietotekniikan parissa alkoi tietojenkäsittelyn opiskelulla. Se oli reikäkorttien ja teletypen aikaa. Varsinainen työnteko alkoi kun olin kesätöissä Wärtsilällä analysoimassa jäänmurtamiskokeiden tuloksia. Valitsin laboratorioomme ensimmäisen pöytätietokoneen ja plotterin ja aloin vääntää koodia Basicilla. Graafista tietojenkäsittelyä 70-luvun alkupuolella siis. It-palvelutoimintaan tutustuin sitten Jyväskylän yliopiston laskentakeskuksessa, kun autoin tutkijoita ja opiskelijoita tietokoneen käytössä. Sieltä siirryin VTT:lle jossa vastasin tilastollisesta tietojenkäsittelystä. Tämän jälkeen lähdin Tietotehtaalle, jossa minut nimitettiin muutaman vuoden jälkeen asiakaspalvelun päälliköksi ja perustin ensimmäisen help deskini 80-luvun puolivälissä. Silloin olimme jo siirtyneet näyttöpäätteiden aikaan ja meillä oli myös ensimmäinen PC käytössä.

Help deskin perustaminen ei mennyt kovin mallikkaasti, keskityin liikaa tekniikkaan ja liian vähän ihmisiin. Puhelinjärjestelmän käyttöönotto meni kompuroinniksi ja ostamani help desk ohjelmisto taisi olla virhehankinta, mutta perustamani help desk toki toimii edelleen. Itse en jäänyt sitä katselemaan, vaan loikkasin konsultiksi. Konsultointi DPM Consulting Oy:ssä keskittyi heti alusta vain it-palvelunhallintaan. Olimme silloin uranuurtajia alalla Suomessa. Pari vuotta myöhemmin perustimme myös Help Desk Institute Nordicin ja keskityin konsultoimaan ja kouluttamaan help deskejä.

90-luvun aikana yhteydenpito asiakkaitten kanssa muuttui. Aluksi lähetimme kirjeitä, palkkasin yleensä koululaisia kirjeiden postituksiin, mutta tuli sitä tehtyä itsekin. Jossain välissä faxaaminen tuli muotiin ja opettelin lähettämään faxeja suoraan PC:ltä. Sähköposti ja internet yleistyivät 90-luvun loppupuolella. Pystyin olemaan tässä edelläkävijä, koska asiakaskuntani oli myös edellä muita. Fax menetti pian merkityksensä ja samoin kirjeet. Tiedottaminen ja markkinointi siirtyi verkkoon.

Jotenkin tuntuu siltä, kuin kehityksen vauhti olisi hiipunut vuosituhannen vaihteen jälkeen. Jos vertaa vuosia 1990, 2000 ja 2010 niin kyllä harppaus 1990-2000 on paljon suurempi kuin sitä seurannut kehitys. Olemme toki saaneet älypuhelimet, sosiaalisen median ja tabletit, mutta työni kannalta niillä ei ole ollut samanlaista vaikutusta kuin siirtymisellä paperista nettiin. Vuonna 1990 viestintä tehtiin lankapuhelimella ja kirjeillä.

It-palvelunhallinnassa nämä vuodet ovat olleet tosiaan ymmärryksen hidasta kehitystä, kuten viimeisin kyselyni positiivisesta kehityksestä kertoo. Ensiksi toin help desk -toimintamallia Suomeen. Se rantautui hyvin, käytännöllisesti katsoen kaikki hankkeet onnistuivat. Vaikka helppareita on kritisoitu paljon, niin ne olivat kuitenkin merkittävä kehitysaskel parempaan palveluun. Seuraava isompi kehitysaskel oli itil. Se kolahti lopulta 2000-luvun alkupuolella, mutta sen tulokset ovat olleet paljon vaatimattomampia. Itilin todellinen soveltaminen on osoittautunut vaikeaksi ja työ on vielä kesken.

Tästä eteenpäin jatkan konsultointia, koulutusta ja tutkimusten tekemistä mutta haen uusia näkökulmia. Olisi esimerkiksi mielenkiintoista kehitellä parempia asiakastyytyväisyystutkimuksia tai menetelmiä potentiaalisten ongelmien löytämiseen. Ota yhteyttä jos tällainen asia kiinnostaa.

 

Ongelmanhallintaa

Pidän ensi tiistaina 20.9. klo 15 webinaarin ongelmanhallinnasta Brightalkilla. Siihen on ilmoittautunut jo 75 kuulijaa. Tervetuloa kuuntelemaan, webinaari on maksuton ja englanninkielinen.

Olen pitänyt yhden webinaarin Brighttalkilla aiemmin. Kokemus on vähän outo, kun yleisöä ei näe. Auttaa ymmärtämään paremmin miksi tv-ohjelmissa käytetään studioyleisöä.

 

 

Yleisin hakusana on insidentti

Olen tämän vuoden aikana alkanut kiinnittää huomiota siihen, että sivuilleni päädytään hakusanalla insidentti, se on yleisin koko historian ajalta että myös viimeisen 30 päivän aikana. Ihmiset ilmeisesti hakevat jatkuvasti sanan määrittelyä. Voisi tietysti ajatella että käsitteen pitäisi jo olla selvä, onhan insidenttienhallinta ollut suosituin itil-prosessi jo vuosien ajan. Miksi sitten sitä etsitään? Yksi selitys voi olla se, että käsite on epämääräinen. Itil-kirjoista löytyy kolme erilaista määrittelyä ja lisäksi määritelmät menevät sekaisin eventin ja palvelupyynnön kanssa.

Itse olen oikeastaan luopunut koko termistä, se on sekä epämääräinen että sisäänlämpiävä. Asiaskaspalvelun näkövinkkelistä keskeinen käsite on asiakkaan yhteydenotto, jonka sisältö voi olla joku palvelutilaus, pulma tai palaute. Asiakkaan kokema pulma johtuu usein asiakkaan tekemästä virheestä tai tiedonpuutteesta. Joskus kyseessä on tunnetun vian aiheuttama tai sellaiseksi epäilty häiriö. Näitä kai voisi kutsua insidenteiksi, jos sitä termiä haluaa käyttää. Viat ovat selviä vikoja jotka pitää korjata. Asiakaspalvelun tehtävänä on ratkoa asiakkaan pulmat. Käytännössä siis itilin insidentinhallinta on oikein ymmärrettynä asiakkaan yhteydenoton hallintaa.

Toinen epämääräinen ja turha termi on itilin ongelma eli yhden tai useamman insidentin aiheuttaja. On turha käynnistää ongelmanhallintaa jos jokin on selvästi rikki, viat pitää korjata jos mahdollista. On kokonaan eri asia miettiä jatkossa miten vastaavat tilanteet voidaan tulevaisuudessa estää.  Tätä varten on olemassa saatavuudenhallinta, jonka yksi tehtävä on miettiä komponettien huollot ja ennakoivat vaihdot. Tunnettujen vikojen hallinta ja korjauspäätösten arviointi on taas osa riskienhallintaa. Jos kuitenkin haluat/joudut pyörittämään ongelmanhallintaa niin pilko se kahteen osaan, ongelmien ratkomiseen ja riskienhallintaan. Ne ovat ihan eri prosesseja. Vikojen korjaaminen on taas oma prosessinsa jossa on samantekevää, onko vika havaittu itse vai asiakkaan aloitteesta. Huomaa että ne saattavat mennä samaan työjonoon muutosten ja muiden palvelutilausten kanssa.

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.

%d bloggers like this: