Itilin virheet

Juttuni itil-managereiden potkuista on herättänyt poikkeuksellisen paljon huomiota ja jopa keskustelua Pohjoisviitan sivuilla, joka on melko harvinaista. Viime perjantaista tuli uusi ennätyspäivä WordPressin liikennetilastojen mukaan. Huomautan, että minä en suositellut itil-managereiden erottamista, ainoastaan referoin mitä Charles Betz sanoi esityksessä, eikä hänkään suositellut sitä, hän vain kertoi mitä eräs pankki oli tehnyt.

Lupasin eräälle kommentoijalle tehdä yhteenvedon itilin virheistä. Ehkä voisin aloittaa sittenkin luettelemalla itilin hyötyjä. Itil on parempi kuin ei mitään, jokin kehikko on hyvä olla, sillä sen avulla on helpompi keskustella aiheesta ja on hyvä joutua pohtimaan it-palvelujen tuottamista. Prosesseilla voidaan saada asioita haltuun, on tärkeää priorisoida asioita ja muutoksia pitää hallita. Itil voi toimia, jos sen soveltamisessa käytetään paljon järkeä ja arvostelukykyä, osataan tehdä itsenäisiä ratkaisuja eikä jäädä väittelemään siitä mitä itil sanoo. Itil tarjoaa terminologian ja vaikka se on vähän horjuva, on se parempi kuin ei mitään.

No sitten luettelo itilin virheistä. En takaa, että tämä on kattava mutta yritän listata tärkeimmät.

  • Turhat prosessit. Itil kuvaa liikaa päällekkäisiä prosesseja. Lukuisten prosessien pyörittäminen johtaa helposti siiloutumiseen, jossa jokainen prosessi keskittyy oman alueensa hoitamiseen ja kokonaisuus kärsii. Turhat prosessit tuottavat taas turhaa työtä ja luovat keinotekoisia raja-aitoja.
  • Integraation puute. Kuten Jarkko Hedman kommentoi tätä, ”ITIL-kirjoja lukiessa kysyy itseltään, onkohan näitä tarkastettu koskaan ristiin.”
  • Toiminnot prosesseina. Itil kuvaa suuren joukon asioita prosesseina, vaikka ne eivät mitenkään omaa prosessin ominaisuuksia. Esimerkiksi saatavuuden ja jatkuvuuden varmistaminen ovat suunnittelua, joka vaatii osaamista. Prosessien kuvaaminen ja keinotekoisten tapahtumien kirjaaminen on turhaa työtä ja tuottaa turhia raportteja.
  • Sertifioidut asiantuntijat. Itil sertifikaatit hankitaan vastaamalla monivalintakysymyksiin, joissa oikean vaihtoehdon tietäminen perustuu muistiin. Kuulopuheiden mukaan osa kouluttajista antaa kysymykset etukäteen ja kertoo niiden oikeat vastaukset. Joka tapauksessa sertifikaatti ei kerro mitään omistajansa kyvyistä palveluhallinnan alueelta. Pahimmillaan sertifioitu asiantuntija ajaa järjettömiä ratkaisuja vedoten siihen, että itil sanoo näin, vaikka kyseessä on k.o. ”asiantuntijan” itse keksimä ja täysin virheellinen tulkinta siitä mitä itil ehdottaa.
  • Virheellinen palvelukäsite. Tämä on aika laaja aihe. Lue keskusteluni Akin kanssa.
  • Häiriöhallinta. Itilin suositus syöttää event managementin eli automaattisen valvonnan kautta tulleita häiriöilmoituksia asiakastuen kirjausten sekaan on järjettömyyden huippu. Asiakastuki on aivan eri asia kuin tekninen valvonta.
  • Ongelmanhallinta on rinnakkainen prosessi häiriönhallinnan kanssa. Saman asian tekeminen kahdessa eri vaiheessa on turhaa. Uusiutuva häiriö on liian aikaisin suljettu häiriö. Sotku johtuu siitä, että asiakastuki ja häiriönhallinta on nivottu yhteen.
  • Jatkuvan palvelunkehittämisen (CSI) mittaripainotteisuus on virhe. Painopiste on toiminnan tuloksellisuuden kehittämisessä, ei prosessien tehostamisessa.
  • En viitsi edes repostella turhien prosessien vikoja, sillä enemmistö itilin prosesseista on turhia.

Mielestäni tässä on aivan riittävästi syitä hylätä suurin osa itilistä.  Mitä sitten tilalle? Se on vaikea kysymys. Olen nähnyt lukuisia vaihtoehto-tarjokkaita, mutta mikään niistä ei ole vakuuttanut. Olen myös osallistunut useampaan yritykseen luoda jotain vaihtoehtoista, mutta kaikki hankkeet ovat luovuttaneet.

Parempi laatu, pienemmät kustannukset

Turhan työn poistaminen on avain laadun kehittämiseen kustannuksia vähentämällä. Olen koonnut tähän joukon ideoita, mistä voit löytää hyviä kohteita turhan työn vähentämiselle. Nämä ovat ideoita ja niiden soveltaminen pitää tehdä harkiten. Organisaatiosta varmaan löytyy henkilöitä, jotka vastustavat näitä ehdotuksia. Pyydä vastustajia esittämään saavutetut hyödyt ja tarkista kaikkien osapuolten näkemys. Hyvin toimivia käytäntöjä ei tietenkään kannata purkaa, jos ne toimivat hyvin kaikkien osapuolten mielestä. Asiakkaan mielipide on aina tärkeä.

  1. Unohda palveluluettelo, jos se ei tunnu toimivan. Olen nähnyt lähinnä vain huonoja ja hyödyttömiä palveluluetteloja, joita puolustavat vain niiden kehittäjät. Kaikkea IT-toimintaa ei tarvitse kuvata palveluna. Monissa tapauksissa liiketoiminta ja asiakkaat tekevät yhdessä asioita, ja IT-väen tehtävänä on tarjota asiantuntemusta, osaamista ja tekemistä yhteisten tavoitteiden eteen. Yhteistyö ja palvelu ovat eri asioita.
  2. Unohda SLAt. Keinotekoiset palvelutasot eivät takaa laadukasta palvelua, mutta työllistävät paljon. Kaikkea ei voi mitata hyvin ja huonot mittarit ovat turhia.
  3. Unohda CMDB. Sen rakentaminen ja ylläpitäminen on työlästä. Oletko varma, että siitä saadaan todellista hyötyä. On mahdollista, että CMDB:tä ylläpidetään, koska johto on niin määrännyt mutta kaikki tietävät, ettei sen tietoihin voi luottaa.
  4. Poista turhat tiketit. Automaattivalvonnan hälytyksistä on turha avata tikettejä. Asiat pitää hoitaa mahdollisimman vähillä vaiheilla. Tiketin avaaminen ja sulkeminen ovat turhia työvaiheita.
  5. Poista turhat kentät tiketeistä. Keskity olennaiseen. Palveluluettelon ja CMDB:n poistaminen auttaa, mutta vaikka et poistaisi niitä, on silti turhaa kytkeä kaikkia ongelmia johonkin tiettyyn palveluun tai konfiguraation osaan. Usein niiden määrittely on vaikeaa tai mahdotonta. Pakolliset luokittelut tuottavat roskatietoa.
  6. Unohda turhat prosessit. Prosessi on hyvä apuväline toistuvien rutiinien pyörittämiseen, mutta se ei sovellu kaikkeen tekemiseen.
  7. Unohda turhat mittarit. Prosessiajattelu luo helposti paljon prosessimittareita, joilla ei ole oikeasti mitään järjellistä käyttöä. Älä mittaa aktiviteetteja ja älä ainakaan aseta niille tavoitteita. Keskity tuloksiin, ei puuhasteluun.
  8. Rakenna asiakkaille palvelupisteitä, joissa heitä autetaan tietotekniikan kanssa. Yksi vierailu voi ratkaista monta ongelmaa ja säästää aikaa sekä asiakkailta, että asiakastuelta.
  9. Ole mukana sosiaalisessa mediassa, jos asiakkaasi ovat siellä. Yritä luoda keskusteluforumeita, joissa asiakkaat voivat keskustella palveluihin liittyvistä asioista. Yksi hyvä keskustelu voi ratkaista monen asiakkaan pulman.
  10. Kuuntele asiakkaiden mielipiteitä, mutta älä kiusaa heitä turhilla ja huonoilla kyselyillä.

Tarvitsetko palveluluettelon?

Kirjoitin service desk-järjestelmän turhasta monimutkaisuudesta  ja olen käynyt siitä keskustelua eri kollegoiden kanssa. Aluksi ajattelin, että itilin CMDB-palvelu-SLA malli (eli malli joka kytkee palvelusopimukset palveluluettelon kautta konfiguraatiotietoihin) aiheuttaa vain tarpeetonta monimutkaisuutta service desk-järjestelmiin. Keskustelujen perusteella olen päätynyt siihen johtopäätökseen, että palveluluettelon ja palvelusopimusten laatiminen itilin oppien mukaan voi olla turhaa ja jopa haitallista. Alleviivasin sanan ”voi”, koska itilin malli toimii joissakin tapauksissa. Parhaiten se toimii silloin kun sekä ostaja että myyjä ovat it-ammattilaisia. Valitettavasti it-palveluja tarvitsevat henkilöt eivät yleensä ole alan ammattilaisia. Valaisen asiaa esimerkillä.

Matkustajalaiva on monimutkainen palvelujärjestelmä. Se on suuri hotelli, jossa on useita ravintoloita, baareja, kauppoja jne. Lisäksi se on kulkuväline. Laivaa pyörittää organisaatio, jolla on kolme päätehtävää:

  1. kapteeni vastaa laivan kuljettamisesta ja turvallisuudesta
  2. purseri johtaa hotelli- ja ravintolapalveluja
  3. konemestari vastaa laivan tekniikan ylläpidosta ja valvonnasta

Lisäksi maissa on varustamon johto, myynti ja markkinointi. Strategiset päätökset tehdään siellä.

Kaikki laivan toiminnot ovat riippuvaisia tekniikan toimivuudesta, mutta niiden kriittisyys vaihtelee ajankohdasta riippuen.

Kuvittele nyt, että laivan konemestari saa itil-herätyksen ja alkaa rakentaa palveluluetteloa. Hänellä toki on varmasti olemassa hyvä kuvaus laivan konfiguraatiosta, mutta mieti miten ja kenen kanssa hän voisi neuvotella palveluluettelosta ja vaikka ilmastointilaitteiden SLA tavoitteista! Ei purseri tai edes kapteeni osaa ottaa kantaa joidenkin teknisten viritysten vaikutuksiin. Laivan palvelujen elinkaari ei ole mitenkään kytköksissä laivan tekniikan elinkaareen. Laitteita huolletaan ja korjataan tarpeen mukaan, mutta laivan palvelut kehittyvät niistä riippumatta. 

Jos laivan konemestari kuitenkin on luja uskossaan ja painostaa purserin tekemään palvelutasosopimukset, tilanne todennäköisesti vain kärjistää suhteita laivalla. Jos purseri esimerkiksi valittaa että keittiön liesituuletus on puutteellista ja sen johdosta ravintolaan tulee ajoittain käryä, niin konemestari voi mitä suurimmalla todennäköisyydellä vakuuttaa tuuletuksen täyttävän palvelutasovaatimukset.

Mitä siis pitää tehdä, jos palveluluettelon laatiminen tuntuu vaikealta ja/tai liiketoiminnan kanssa on vaikea löytää yhteistä säveltä? Mielestäni kannattaa unohtaa itilin opit. Palveluluetteloa ei vain voi laatia niin, että se kytkeytyisi liiketoiminnan palveluihin. Kyse on pitkälti ammattitaidosta. Tekniikasta vastaavan henkilöstön pitää osata huolehtia vastuullaan olevista järjestelmistä ja heidän pitää ymmärtää niiden merkitys.  SLA on oikeastaan vain yritys vyöryttää vastuu asiakkaan harteille ja niin ei pidä tehdä, ellei asiakas sitä halua.

 

Miten sitten tekniikan toimivuutta pitää mitata? Mieti laivaa. Tärkeintä on varmasti se, että tekniikan ongelmat eivät haittaa liiketoimintaa. Hyötyjä voi syntyä myös erilaisista säästöistä, vaikka energian kulutuksessa. Oleellista on, että toimintaa mitataan liiketoiminnan mittareilla, ei sisäisillä SLA-mittareilla. Lopuksi pitää vielä kerran korostaa, että on myös tilanteita, joissa asiakas haluaa ja tarvitsee palvelulettelon ja SLA:n.

Jos et ole lukenut aiempaa kirjoitustani palvelukäsitteen selkeyttämisestä, käy lukemassa myös se.

PS Kun testasin linkkejä, sain turvavaroituksen siitä, että linkki johtaa wordpress.com palvelimme, vaikka linkissä on osoitteena pohjoisviitta.fi. Olen siirtänyt pohjoisviitta.fi domainin wordpressille jo useita vuosia sitten, joten varoitus on aiheeton.

Turhan monimutkaista

Kaksi vuotta sitten Rik Maes piti loistavan esityksen itSMF Finlandin konferenssissa Kalastajatorpalla. Hän näytti mm. hollantilaisen potilastietojärjestelmän kaaviota. Hän antoi meidän katsella sitä hetken. Se oli hyvin monimutkainen, paljon laatikoita ja viivoja, eikä kukaan ymmärtänyt siitä mitään. Sitten hän näytti yhtä laatikkoa alanurkassa, siinä oli potilas. Potilaasta oli tullut sivuseikka.

Sain hiukan samanlaisen tunteen kun katsoin hyvämaineisen konsultin laatimaa kaaviota it-palvelunhallintajärjestelmästä service deskin perustamista varten. Ainoa ero oli, että tästä kaaviosta ei löydy sitä potilasta eli asiakasta edes alanurkasta. On varmaankin helppoa arvata että keskiössä on konfiguraationhallinnan tietokanta CMDB, jonka ympärillä järjestelmä pyörii. Järjestelmä on tehty itilin mukaisesti ja tulos on varsin monimutkainen.

Service deskin keskeinen tehtävä on asiakaspalvelu, hyvä service desk lisää asiakkaitten tuottavuutta poistamalla heidän työtään haittaavia esteitä. Esteet voivat olla monenlaisia, myös henkisiä. Asiakas voi esimerkiksi pelätä tai inhota tietotekniikkaa ja niiden esteiden voittaminen on aivan yhtä tärkeätä kuin jonkin viallisen nippelin korjaaminen. Siksi Service Desk järjestelmän pitää rakentua asiakkaan ja tämän pulman tai tarpeen ympärille. Toki konfiguraationhallinta on tarpeellista, mutta sillä ei ole mitään osaa asiakaspalvelussa. Service deskin tarpeet ovat erilaiset kuin järjestelmäasiantuntijoiden tarpeet.

Toinen vastaava monimutkaistaja on palveluluettelo. Kuten hyvin tiedämme, asiakkaiden näkemys palveluista on varsin erilainen kuin niitä tuottavan it-organisaation näkemys. Asiakas niputtaa asiat yhteen omien kokemustensa kautta, palvelun tuottaja taas katsoo samaa asiaa omien vastuittensa kautta. Asiaa mutkistaa vielä se, että koko palvelukäsite on hyvin hankala, esimerkiksi itilin määritelmä on puuta heinää, ei sisäinen it poista emo-organisaation kustannuksia ja riskejä, kuten itil väittää. Olen kirjoittanut tästä aiemmin katso: Selkeyttä palveluun.

Kun asiakaspalvelujärjestelmä kytketään palveluluetteloon ja CMDB:een tuloksena on monimutkainen ja vaikeasti hallittava kokonaisuus. Mitään lisäarvoa kytkennästä ei saada. Tai siis toki järjestelmän rakentavat konsultit saavat.

Unohda siis CMDB ja palveluluettelot, kun rakennat service deskin järjestelmää. Keskity asiakkaaseen ja tämän asiaan. Muista, että asiakkaan ongelman ratkaiseminen ei ole sama asia kuin jonkin vian korjaaminen, ne ovat kaksi ihan eri asiaa. Unohda itil, käytä järkeä.

Selkeyttä palveluun

Palvelu on vaikea käsite, joka on aiheuttanut päänvaivaa monille it-palvelunhallinnan harjoittajille. Asia on ikään kuin itsestään selvä, mutta se luiskahtaa otteesta kuin märkä saippuanpala. Yritykset määritellä palvelu  ovat vaikeita, ja on aina helppo keksiä esimerkkejä palveluista, jotka eivät sovi palvelun määritelmään. Esimerkiksi Itil määrittelee palvelun näin: ”Keino tuottaa arvoa asiakkaalle auttamalla asiakasta saavuttamaan tuloksia ilman, että asiakas investoi tiettyjä kustannuksia ja riskejä.”  Määritelmä rajaa pois kaiken sisäisen it-palvelun, joka on suorastaan aika huvittavaa, kun ajattelee millä innolla itiliä on opiskeltu ja sovellettu juuri sisäisen it:n tarpeisiin.

Nyt olen kohdannut viimeinkin määritelmän tai lähestymistavan, joka vaikuttaa järkevältä ja toimivalta. Lyhyesti tiivistettynä palvelu voidaan kuvat kaavalla:

Tarjooma + Järjestelmä(t) + Tapahtuma(t) => Tulos.

Palvelun komponentit ovat: palvelutarjooma, palvelujärjestelmä ja palvelutapahtuma. Näin saadaan aikaan palvelutulos.

Palvelutarjooma on lupaus palvelusta tietyin ehdoin. Tarjooma voi sisältää yhden tai useita vaihtoehtoja. Tarjooma voi olla asiakaskohtaista tai standardoitua.

Palvelujärjestelmä sisältää kaikki ne elementit, resurssit, välineet, menetelmät, prosessit ja ihmiset, joiden avulla palvelu saadaan aikaan.

Palvelutapahtuma on sitten se hetki, jolloin palvelu tapahtuu ja asiakas vastaanottaa tai kokee palvelun tuloksen.

Esimerkiksi Parturi-Kampaamolla on hinnastossaan erilaisia tuotteita. Sen palvelujärjestelmään kuuluvat tilat, sisustus, työkalut, prosessit, infrastruktuuri ja henkilökunta. Tukanleikkuu on palvelutapahtuma ja sen lopputulos on palvelutulos.

Tämä ajattelu selkeyttää monia itilin vaikeita käsitteitä. Esimerkiksi palvelukatalogi on siis kuvaus palvelutarjoomasta eikä mikään kattava kuvaus kaikesta, mitä it tekee. It- yksikön henkilökunta vastaa sekä palvelujärjestelmistä että palvelutapahtumista. Palvelujärjestelmän ylläpito ja kehittäminen eivät siis ole palvelua, vaan ylläpitoa ja kehittämistä. Palvelujärjestelmiä ei kuvata palvelukatalogissa. Asiakkaat eivät yleensä ole kiinnostuneita palvelujärjestelmistä.

Palvelun elinkaaresta ei voi puhua, se on liian epämääräinen käsite, sensijaan palvelujärjestelmillä ja palvelutarjoomalla on omat elinkaarensa. Palvelutarjooman muutokset eivät välttämättä liity mitenkään palvelujärjestelmien muutoksiin ja päinvastoin.  Palvelumuotoilulla kehitetään palvelutapahtumia, mutta palvelumuotoilu ei vaadi välttämättä muutoksia palvelutarjoomaan tai palvelujärjestelmään, kyse voi olla vain siitä, kuinka palvelu toimitetaan asiakkaalle.

Yhteistyömalli

Nykyään puhutaan it-palvelunhallinnasta ikään kuin se olisi ainoa mahdollinen toimintamalli. Palvelutoimittajan rooli ei kuitenkaan ole ainoa tapa. Tietotekniikalla voi olla erilaisia rooleja liiketoiminnan suhteen. Roolit riippuvat tietotekniikan ja liiketoiminnan yhteydestä. Yhteys voi olla läheinen tai etäinen. Tässä esimerkkejä:

  1. Teknologian ylläpitäjä. It toimii kuin ydinvoimalaitos, se toimittaa palveluja usealle asiakkaalle, mutta sen toiminnassa ei ole mitään asiakaslähtöisyyttä. Toimintaa ohjaa vahva turvallisuusajattelu ja korkea käyttöaste on tärkein tavoite. Iso tietokonekeskus voi toima samalla tavalla.
  2. Palvelutoimittaja. It tuottaa tarkkaan määriteltyjä palveluja asiakkailleen. Palvelut on sovittu asiakkaan vaatimusten mukaiseksi. Palvelutoimittaja pyrkii tuottamaan sovitut palvelut mahdollisimman tehokkaasti SLA-sopimusten puitteissa. Palvelutoimittaja on lähempänä asiakasta kuin teknologian ylläpitäjä, mutta palvelu luo selkeän rajapinnan asiakkaan ja palvelutoimittajan väliin.
  3. Yhteistyökumppani. It:llä on samat tavoitteet kuin liiketoiminnalla ja niiden eteen tehdään töitä yhdessä. Rajapinta on joustava ja työnjako määräytyy tilanteen mukaan. Tämä on luontevaa eteenkin pienissä yrityksissä, joiden liiketoiminta rakentuu it:n varaan.

ITIL kuvaa palvelutoimittajan roolia ja nykyään tavoitteena on saada kaikki it-organisaatiot toimimaan tämän mallin mukaisesti. Tämä on osin perusteltua, sillä joissakin tilanteissa it voi yrittää vetäytyä teknologian ylläpitäjän rooliin, vaikka sen pitäisi olla lähempänä asiakasta.

Epämääräisesti määritelty yhteistyö voi olla sekavaa ja pahimmassa tapauksessa rakentuu täysin yksilöiden varaan. Ilman tehokkaita prosesseja ja vakaata teknologiaa, ei saada aikaan toimivaa yhteistyötä. Luottamuksen puutetta voidaan yrittää paikata sopimuksilla, mutta kokemukset opettavat etteivät SLA-sopimukset aina toimi halutulla tavalla.

Väitän, että yhteistyökumppani-malli on tavoiteltava ja mahdollinen. Se on mielestäni seuraava kehitysaskel palvelutoimittajamallista. Tämä voi tuntua utopistisella, mutta tässä yksi esimerkki sen suuntaisesta toiminnasta.

Case MetLife

MetLife on suuri vakuutusyhtiö, työntekijöitä on 64.000, vertailun vuoksi esimerkiksi OP-Pohjolassa on 13.000. Aiemmin tänä vuonna MetLife otti käyttöön FaceBookin kaltaisen sovelluksen, jonka rakentaminen vei 90 päivää. Uusi sovellus The Wall antaa asiakaspalvelun työntekijöille kokonaisnäkemyksen asiakkaasta, se näyttää kaikki vakuutukset ja kaikki tapahtumat. Aiemmin tiedot piti hakea 70 erillisestä sovelluksesta tai tietokannasta.

MetLife pyrkii leikkaamaan kulujaan palkkaamalla 1.000 teknologia-asiantuntijaa, joiden tehtävänä on kehittää uusia tapoja parempaan asiakaspalveluun. Teknologia-asiantuntijoita kannustetaan tuottamaan liikevaihtoa kasvattavia ehdotuksia. ”Teknologia ei ole vain mahdollistaja, se on tämän yrityksen kudos ja tulevaisuus” sanoo MetLifen CIO Gary Hoberman. http://money.cnn.com/2013/10/31/news/companies/metlife-wall-app.pr.fortune/

Vaatimusten haitallisuus

Palvelutoimittajamalli lähtee asiakkaan vaatimusten tunnistamisesta. Capgeminin CTO Ron Tolido kirjoittaa, että vaatimusmäärittely voi olla haitallista. Vaatimukset perustuvat usein siihen tuttuun entiseen ratkaisuun, käyttäjät eivät osaa kuvitella mikä olisi mahdollista. Tarkat vaatimukset vaativat räätälöintiä ja se on kallista. Tuloksena on kallis ja huonosti toimiva ratkaisu.

On parempi lähteä liikkeelle valmiista komponenteista ja tehdä nopeasti prototyyppejä, sen sijaan että mietittäisiin yksityiskohtaisia tarpeita. Tietotekniikan pitää tarjota mahdollisuuksia, joita voi kokeilla. http://www.capgemini.com/blog/cto-blog/2013/11/technovision-2014-no-requirements

Yhteistyömallin periaatteet

PartnershipYhteistyö rakentuu yhteisten tavoitteiden varaan ja niiden muodostamat tiimit ovat mallin ydin. Tiimin muodostavat kaikki siihen osallistuvat toimijat ja tiimin täytyy toimia kaikilla tasoilla: strategisella, taktisella ja operationaalisella. Keskinäinen luottamus on tärkeää, jokaisen osapuolen on otettava vastuu omasta panoksestaan yhteisen tavoitteen hyväksi. Toimivat tiimit vaativat jatkuvaa ylläpitoa ja huolehtimista.

Yhteistyö ei rakennu etukäteen sovittujen SLA-tavoitteiden varaan, siksi palvelujen määrittely ei ole olennaista ja palveluluettelot eivät ole välttämättömiä. On toki mahdollista, että joillakin osa-alueilla voidaan sopia hyväksi havaittua palvelumallia. Yhteistyöhön osallistuu usein monia osapuolia ja näiden toiminnan integrointi on tärkeä osa yhteistyön hallintaa.

Yhteistyömalli ei sulje pois toimivaa asiakaspalvelua ja -tukea. Sitä tarvitaan rutiinitoimeksiantojen tehokkaaseen käsittelyyn. Aiemmin kuvaamani Service Desk 2.0 kuvaa tähän soveltuvaa asiakaspalvelua. Painopiste on mahdollisuuksien ja kyvykkyyksien tarjonnassa ”insidenttien” sijaan.

Kokonaisvaltainen muutoksenhallinta on tärkeää, koska toiminta voi koostua monista yhteistyökumppanuuksista, jotka jakavat yhteisiä elementtejä. On kuitenkin suositeltavaa, että muutoksenhallinta kykenee käsittelemään suuria muutosvolyymejä nopeasti.

Operatiivinen tuotanto kattaa alustat, laitteet, sovellukset ja verkot. Siihen voi osallistua sisäisiä yksiköitä, palvelun tarjoajia ja vaikka julkisia pilvipalveluja. Tuotanto valvoo eri komponenttien toimintaa ja korjaa viat.

Riskienhallinta on myös tarpeellinen osa toimivaa yhteistyötä. Luottamus on keskeinen elementti ja siksi riskit pitää hallita hyvin. Riskienhallinta ei ole erillinen toiminto vaan tärkeä elementti kaikessa päätöksenteossa.

Yhteistyömallissa tietotekniikan ja asiakkaan roolit muuttuvat pois perinteisestä palvelumallista, jossa asiakas määrittelee haluamansa palvelut ja it toteuttaa ne. It-palvelunhallinta on ollut liian kauan vanhan vesiputousmallin lumossa. Ajatellaan että liiketoiminta määrittelee tulevat tarpeensa vuosiksi eteenpäin ja tietotekniikka sitten toteuttaa ne. Unohdetaan että näin varmistetaan, että ratkaisut ovat varmasti vanhentuneita, jos ne joskus toteutetaan. Aikaa tuhlataan suunnitteluun ja valmisteluun.

Mielestäni keskeinen oivallus tässä on siirtyminen kohti liiketoiminnan tavoitteita. It:n pitää unohtaa omat tavoitteensa ja lähteä liiketoiminnan kanssa yhteistyössä hakemaan ratkaisuja, jotka tuottavat todellista hyötyä.

Yhteistyömalli ei ole käsitteellisesti monimutkainen eikä sen oivaltamiseen tarvita useiden päivien koulutuksia. Se ei sisällä valtavaa määrää toimintoja tai prosesseja. Sen toteuttaminen käytännössä vaatii kypsyyttä, kyvykkyyttä ja molemminpuolista luottamusta.

Tavoitteet, mittarit ja hyöty

Päätin jatkaa vielä edellisen kyselyni herättämää pohdintaa. Kyse on oikeastaan aika isosta asiasta, ei pelkästään mittaamisesta vaan siitä miten tietotekniikkaa ohjataan.

Kommentit kyselyyn

Sain muutaman mielenkiintoisen kommentin tavoitteita ja mittareita koskevasta tutkimuksesta. Pekka Sipola kertoo samanlaisista havainnoista täällä:

https://pohjoisviitta.fi/2013/11/08/mittarit-ja-tavoitteet/#comments

Referoin tutkimusta myös englanniksi ja sain siihen pari hyvää kommenttia, aika arvovaltaislta tahoilta!

Jeffrey Brooks (Research Director, Gartner) Very cool. We have very similar data results…unfortunately!

 Robert Stroud (VP Strategy & Innovation, CA) Doesn’t matter how many time we talk about it, the business is the critical factor, not IT

Lisäksi pari henkilöä kommentoi yksityisesti, ja koska niiden sisältö on mielenkiintoinen, niin julkaisen ne tässä anonyymisti.

Kiitoksia tästä raportista! Minä sain tästä itselleni aika paljon uskonvahvistusta.

 En osannut itse vastata tähän kyselyyn, koska tässä nykyisessä tehtävässäni mittarointia vasta käynnistetään. Olen itse siinä vahvasti mukana ja juurikin puhumassa näistä asioista, mitä sinä tuot tässä esiin. Eli tavoitteet pitää määritellä lähtökohtaisesti yksikkörajojen yli ja toisaalta tätä vasten meillä tulee olla hyvin tarkka käsitys asioiden syy-seuraussuhteista. Pitää ymmärtää, mikä minkäkin asian todellinen vaikutus on.

Mielestäni tavoitteiden määrittely yli yksikkörajojen on loistava periaate. Se ei vielä takaa asiakkaan saaman hyödyn mittaamista, mutta on varmasti askel oikeaan suuntaan.

Muutama havainto tähän omien kokemuksieni pohjalta. Erityyppisten mittausten parissa on nyt vierähtänyt kuutisen vuotta ja tutkimuksesi tulokset tukevat täysin kokemuksiani.

 Tyypillisesti mittarin ovat ns. ”output” mittareita, eikä niiden perusteella voi sanoa mikä prosessissa/palvelussa menee pieleen. Output mittarin avulla ei pysty juurikaan korjaamaan/parantamaan mitään vaan tarvitaan mittaussysteemi, jolla pystytään selittämään prosessin toiminnan vaiheita ja tulosta (outputtia), prosessin ”input” mittareista puhumatta (vertaa autoteollisuus; jos moottorin koontilinjalle tulevat osat ovat kaikki vähän liian suuria, niin viimeiset ei luultavasti mahdu paikalleen J)

 Tärkein mainitsemasi asia lienee juuri tuo palvelun/prosessin arvon tuotto. Se ymmärtäminen näyttää jäävän yleensä lähes kokonaan huomiotta. On vaikea parantaa suorituskykyä tai palvelukokemuksia ymmärtämättä hyödyn määrää.

 Lopuksi; Availability lienee lähtöisin ITIListä ja henkilökohtainen mielipiteeni on, että kehittäjän näkökulmasta availability se vasta on huono mittari onkin, vaikkakin se on yleisesti helppo ymmärtää. Se sisältää määrittelemättömän määrän katkoja, eikä niiden ajasta ole mitään tietoa ja johtopäätökset ovat usein väärin. Asiakas on usein tyytymätön palveluun vaikka availability mittari näyttää 99,9%. 

Yleinen käsitys on, että availability on kokonaisvaltainen mittari ja oletan sen johtuvan siitä, että availabilityä on hoettu yli kymmenen vuotta.

Olen samaa mieltä tuosta saatavuudesta (availability). Eräs palveluntarjoaja harmitteli minulle, että jotkut konsultit usuttavat asiakkaat vaatimaan 100 % saatavuutta, jonka tuottaminen on mahdollista mutta kallista. Miksi esimerkiksi sähköpostin pitäisi toimia keskeytymättä. Kuka huomaa jos palvelussa on muutaman minuutin katkoja päivittäin? Saatavuus on ongelma, jos se on huono, mutta 100 % saatavuus on harvoin tarpeellinen. Kaikki riippuu katkojen vaikutuksista suhteessa korkean saatavuuden lisähintaan. Viimeisen promillen pusertaminen voi nostaa reippaasti palvelun hintaa, saavutetaanko sillä vähintäänkin vastaava tulosparannus?

Paremmat tavoitteet

Mistä sitten löytyvät ne paremmat tavoitteet. Se on vaikea kysymys. On toki helppoa sanoa miten pitäisi toimia. Pitää vain keskustella liiketoiminnan kanssa ja valita yhdessä ne yhteiset tavoitteet. Käytännössä tämä voi olla vaikeaa. Tarvitaan luottamusta, sillä yhteisten tavoitteiden taakse voi piiloutua.  Toisaalta palvelusopimusten taakse on myös erittäin helppo piiloutua. Sovitut tavoitteet saavutetaan, mutta asiakas ei ole tyytyväinen.

Andrea Kis ( Service Management and Integration Consultant at Tata Consultancy Services) twiittasi näin eilen: Managed sow the seed again: convinced client to think of aligning their IT objs to the objectives of the business to understand them. Suositukseni on tämä, alkakaa keskustella asiakkaittenne kanssa siitä, voisiko tavoitteita muuttaa. Se ei ole mahdotonta. 

%d bloggers like this: