Mitä olen oppinut. Osa 2. Yksinkertaista

Yksinkertaisuus on äärimmäinen hienostuneisuus” – Leonardo Da Vinci.

Kirjoitin ensimmäisessä osassa asioiden ymmärtämisen tärkeydestä. Epäselvien käsitteiden lisäksi ymmärrystä vähentää tarpeeton monimutkaisuus. Monimutkainen näyttää hienommalta, paksu dokumentti vaikuttaa arvokkaammalta kuin ohut jne. Usein yritetään tehdä liian hienoa, varaudutaan kaikkiin mahdollisiin poikkeustapauksiin ja tuloksena on liikaa detaljeja. Yksinkertaistaminen ei ole helppoa, on kyettävä näkemään olennainen ja uskallettava karsia turhat elementit pois.

Kuka lukee 50-sivuista prosessikuvausta? Prosessikuvaus on todennäköisesti laadittu leikkaa-liimaa -tekniikalla, se on täydentynyt vuosien varrella. Konsultti on muokannut sitä asiakkaiden toivomusten mukaan, mutta ei ole poistanut mitään. Kukaan ei lue sitä ja kukaan ei toimi sen mukaan, mikä on oikeastaan hyvä, koska paksu prosessikuvaus on melko varmasti epälooginen ja sisäisesti ristiriitainen.

Hyvä prosessikuvaus on lyhyt, korkeintaan muutaman sivun mittainen ja sen kuvista näkee nopeasti, miten prosessi toimii. Käytetyt termit on määritelty selkeästi. Prosessikaaviot näyttävät olennaiset vaiheet, kuvaus ei takerru yksittäisten poikkeustapausten käsittelyyn.

Sama koskee raportteja. Hyvä raportti on lyhyt ja selkeä ja se nostaa esille tärkeimmät havainnot. Huono raportti on uuvuttavan pitkä, eikä siitä jää mitään selkeää kuvaa asioiden tilasta ja kehityksestä.

On monta asiaa, jotka vaikeuttavat yksinkertaistamista. Ryhmätyöskentelyssä on helpointa hyväksyä kaikkien ehdotukset, kuin noudattaa tiukkaa linjaa. Monimutkaisuus tuo töitä konsulteille ja kouluttajille. Tulosten laajuus luo mielikuvan tehokkuudesta ja tuottavuudesta.

Mitä olen oppinut. Osa1. Selkeät käsitteet

Mitä olen oppinut.

Olen jäämässä eläkkeelle ja päätin kirjoittaa lyhyen sarjan niistä asioista, joita olen oppinut it-palvelutoiminnasta näiden vuosien aikana. Oma urani alkoi jo 70-luvulla. Olen koodannut vähän, auttanut muita tietokoneen käyttämisessä, vetänyt asiakaspalveluyksikköä, mutta ennen kaikkea olen konsultoinut it-päättäjiä toiminnan kehittämisessä. Matkan varrelle mahtuu paljon onnistumisia, mutta toki myös epäonnistuneita hankkeita.

Osa 1.  Selkeät käsitteet

Asioiden ymmärtäminen on tärkeää ja sitä varten pitää olla selkeät käsitteet, joiden avulla asioista voi puhua ymmärrettävästi. Tämä ei ole aina kaikkien tavoite, sillä epäselvyyden avulla voi häivyttää monia asioita. Vaikeaselkoisuus luo mielikuvan osaamisesta, asiantuntija vaikuttaa pätevältä, kun hänen esitystään on vaikea ymmärtää. Joskus vaikeaselkoisuudella peitellään omia tarkoitusperiä, esimerkiksi monimutkaisten sijoitustuotteiden perimmäinen tarkoitus on tehdä rahaa niiden myyjille. Ostaja luulee hankkivansa voittoja nerokkaalla tavalla, ymmärtämättä tuotteiden riskejä.

It-palveluhallinta on vaikea ala. Se on monimutkaista ja siitä on vaikea saada otetta. On aito tarve saada selkeä kuva toiminnasta, jotta sitä voi ohjata ja kehittää. Toiminnan kuvaamiseen on kehitetty erilaisia malleja, joiden tulisi auttaa ja joiden avulla voisi kuvata hyviä käytäntöjä. Valitettavasti malleilla on taipumuksena kasvaa ja monimutkaistua. Monimutkaiset mallit tekevät hallinnan vain entistä vaikeammaksi.

Hyvä esimerkki epäselvästä termistä on palvelun käsite. Palvelu on vaikeasti määriteltävä asia ja puhe palvelusta jää helposti epämääräiseksi. ITIL määrittelee palvelun lähinnä vuokraamisena tai liisaamisena. Asiakas saa haluamansa hyödyn ilman omistamiseen liittyviä erityisiä kustannuksia ja riskejä. Määritelmä on huono, se ei sovi it-palveluihin kuin aika harvinaisissa tapauksissa.

Palvelusta on helpompi puhua, jos sen jakaa keskeisiin komponentteihin: palvelulupaus, palvelujärjestelmä ja palvelutapahtuma.

  • Palvelulupaus on palvelutuote. Se kuvaa palvelun toiminnan pääpiirteissään ja korostaa asiakkaan saama hyötyä. Palvelulupaukset voivat olla asiakaskohtaisia tai tuotteistettuja.
  • Palvelujärjestelmä on tietotekniikasta, ihmisistä, prosesseista, ohjeista jne. koostuva toiminto, joka tuottaa palvelulupauksen edellyttämiä asioita.
  • Palvelutapahtuma on asiakkaan transaktio palvelujärjestelmän kanssa.

Tämä kolmijako on hyvin keskeinen asia palveluhallinnassa, jo jos sitä ei ymmärrä, on pihalla.

Huvipuisto on palvelu, joka tuottaa nimensä mukaisesti huvia asiakkailleen. Huvipuistossa on runsaasti palvelujärjestelmiä, kuten siivous, ylläpito, vartiointi, vesi- ja viemäröinti, laitehankinnat jne. Lisäksi siellä on tietysti paljon laiteita. Asiakkaan näkökulma palveluihin on aika erilainen kuin huvipuistoa pyörittävän organisaation. Asiakas näkee pinnan ja hänelle tärkeät asiat. Henkilökunta työskentelee pinnan alla.

On hämmentävää puhua vaikkapa palveluluettelosta, jos ei täsmennä puhuuko lupauksista, järjestelmistä vaiko tapahtumista. Esimerkiksi it-palvelutoimittaja voi myydä it-järjestelmiä palveluna asiakkaille, jotka ovat itsekin it-ammattilaisia. Liiketoiminta taas on vähemmän kiinnostunut teknisistä it-järjestelmistä, vaan puhuu mieluummin palvelutapahtumista.

Toinen vastaava esimerkki epäselvistä käsitteistä ovat insidentti ja ongelma. Insidentin- ja ongelmanhallinta ovat pohjimmiltaan samoja asioita ja niiden käsittely erillään luo turhaa hämmennystä. Insidentti on häiriö ja ongelma sen aiheuttaja. Joskus näitä voi käsitellä erillään, mutta usein insidentin ratkaiseminen vaatii sen syyn tunnistamista. Jos sulake laukeaa, kannattaa selvittää laukeamisen syy, ennen kuin kytkee virran uudestaan päälle.

Kun laitan leivänpaahtimen päälle, se välähtää ja keittiön valot sammuvat. Valot sammuvat koska sulake on lauennut ja syyllinen on leivänpaahdin, joka haisee palaneelta. Onko sulakkeen laukeaminen insidentti ja onko leivänpaahdin ongelma? Laitanko vain sulakkeen takaisin päälle? Viisainta olisi vain laittaa leivänpaahdin kierrätykseen ja hankkia uusi.

On parempi lähteä liikkeelle asiakkaasta ja kuvata asiakkaan palvelutapahtumia. Asiakas voi tarvita neuvoa, haluta tilata jotain täydennystä tai sitten asiakkaalla on ongelma. Toinen näkökulma on palvelujärjestelmän kannalta järjestelmän viat ja häiriöt, joita pitää korjata. Epäselvien käsitteiden ansiosta nämä asiat menevät helposti solmuun.

Monet konsultit rakastavat vaikeita termejä, he pyrkivät luomaan mielikuvaa ylivertaisesta osaamisestaan. Olen nähnyt liian usein, kuinka konsultit puhuvat asioista, joita he eivät itse kunnolla ymmärrä (olen tietysti syyllistynyt siihen itsekin). Tämän hetken muotisanoja ovat esim. SIAM ja DevOps.  Kannattaa kysyä ns. tyhmiä kysymyksiä. Esimerkiksi:

  • Mitä tuo sana oikeastaan tarkoittaa, voisitko avata sen lyhyesti?
  • Milloin olet itse soveltanut tätä menetelmää?
  • Mitä se merkitsee meille?

Asiansa osaava kykenee avaamaan termit, kertomaan omista kokemuksistaan ja osaa soveltaa niitä asiakkaan tilanteeseen.

%d bloggers like this: