Palvelut ja yhteystiedot

Olen kokenut asiantuntija ja vuoden 2012 ITSM-henkilö. Erityisalueitani ovat IT palvelunhallinta, ISO 20000, service ja help deskit, asiakastyytyväisyyden ja prosessien mittaaminen. Tarjoan konsultointia, koulutusta ja tutkimuspalveluja.

Esiintymisiä
2011: PINK 11, Las Vegas, itSMF Finland  Espoo
2012 itSMF Russia, Moscow, itSMF UK, Lontoo, itSMF Estonia, Tallinn
2013 LeadIT (itSMF Australia), Canberra, itSMF Finland, Helsinki, itSM(F) Belarus, Minsk, itSMF Estonia, Tallinn, itSMF Sweden, video panel
2014: Service Desk Forum , Stockholm,  FUSION14 (itSMF USA), Washington DC  

Tässä erään kuulijan kommentti: I have attended itSMF Estonia conferences 2012, 2013 and you’re presentations really impressed and motivated me.

aale.roos@pohjoisviitta.fi

Pohjoisviitta Oy, Alankotie 29, 00750 Helsinki
GSM +358 (o)5o-5544733
Twitter: @aalem

Sosiaalinen media asiakastuessa

Eräs lukija kommentoi Pohjoisviitan sivujen taustalla näkyvää lumisadetta. Olin itsekin ihmetellyt mistä se sinne oli tullut ja miksei se mene pois. Yritin ensin katsella asetuksia, mutta niitä on niin paljon. Seuraavaksi siirryin tukisivuille ja sieltä keskustelufoorumille. Ei mennyt montaa sekuntia kunnes löysin aihetta käsittelevän keskustelun ja ohjeen lumisateen poistoon.

Keskusteluja käyvät alan harrastajat, eli vastauksen antoi henkilö, joka ei ole töissä Automattic:illa. Toimi hyvin eikä aiheuttanut työtä tuelle.

What did I get from itSMFest?

Well, I didn’t leave empty handed as I got a nasty flu which has kept me pretty low for almost a week, but was there something else too? I think there was a vision about the future; it was not clear but it sure was not this beautiful Soviet era ad that was lying on tables there :)  RTIE-300

The Estonian Conference was again good. Kaimar Karu had invited an interesting crowd of speakers and the one day, one stream concept is powerful but it has grown too popular for the venue. As I came in a bit late, I had to sit in the back where sound quality was bad and slides invisible, especially those with small text.

Adrian Cockcroft was for me one of the most interesting speakers. He spoke about his experiences with Netflix and I picked a few points from him:

-  “Don’t do undifferentiated heavy lifting” i.e. don’t do anything heavy standard stuff. There are specialized companies for that.

- “Organizations build slow, complex scar tissue processes” when they should be lean and fast.

We were saved from ITIL sessions, the only session which could have been one was done by my favorite ITIL skeptic, Stuart Rance. (Now I can see Stuart reaching for his quill and ink, or more likely his iPhone as he does not consider himself as a skeptic but actually he is). Stuart started his presentation by asking who of us think that CSI is a stage in the service lifecycle or a process or a model. Then he explained that it is about attitudes, behavior and culture.  So, bye bye 7-step process.

Many speakers had as their key message to concentrate on what brings value and forget the processes. Patrick Bolger smashed the ITIL tool certifications to pieces, and both he and Bartosz made fun of the full ITIL process chart. Bartosz Gorczynski gaves us a presentation about how to guarantee failure in an ITSM project. It was really funny and so real. I was attending a tools workshop in last September, where the consultants were trying to follow almost all Bartosz’ advice to the letter.

Tobias Nyberg spoke about problems and he also had a fresh, non-process approach. Paul Wilkinson did his ABC sermon and it became clear how the same message came up in many presentations.

I told Paul that I had a lovely real life example of the ABC problem which happened last week. A customer of mine had a minor catastrophe, which might have been much worse. After it had been worked out she said that finding the root cause is not the point. “We know exactly the root cause and we have described the solution before but it just happens again.”

I had a surprise visit to the stage, Kaimar asked me to join a group of people to answer audience’s questions. People had been asked to write their questions so I was able to have peek at them before the start. Some of them were quite hard. I wrote down some of my answers beforehand:

How to start?

  • talk with the customers

What is your best advice?

  • listen to customers

How to influence management

  • use customers voice/message

Stephen Mann talked about commercialization of services which is a good insight. The internal IT competes with web services and it is not an easy race. Kaimar himself ended the conference and left me a tiny bit disappointed. We heard nothing about the future of ITIL.

So what was the vision and message. I´d say it is this: New technology happens fast and IT needs to be prepared to help business with it. There are no easy solutions or simple models, you need to know what creates value and how it is done. You are in a race and the people are the problem and the solution. But you cannot win without good technology.

The full set of presentations are available here http://konverents2014.itsmf.ee/program

Service Deskin ulkoistaminen

Organisaation kannattaa ulkoistaa tehtäviä niihin erikoistuneille yrityksille, mutta on tärkeää, että ulkoistettu tehtävä ymmärretään hyvin ja tiedetään miten se liittyy omaan toimintaan. Ulkoistetun tehtävän tulee olla selkeä kokonaisuus, joka voidaan helposti erottaa organisaation muusta toiminnasta. Tietotekniikassa esimerkiksi konesalin ja palvelimien pyörittäminen on yleensä tällainen tehtävä. Palvelimet tarvitsevat sähköä, jäähdytystä, valvontaa ja turvaa. Suunnilleen samalla kustannuksella hoitaa 1000 tai 2000 palvelinta ja tämän takia harvat organisaatiot tuottavat itse omat konesalipalvelut, useimmille riittää ostettu kapasiteetti. Isompi konesali toki vaatii enemmän sähköä ja jäähdytystä, mutta suurempi keskus voi kehittää parempia menetelmiä esimerkiksi lämmön talteenottoon jne.

Service desk voidaan nähdä samanlaisena helposti ulkoistettavana palvelukokonaisuutena. Mielestäni tämä on virhe ja se johtuu siitä, että päättäjällä on virheellinen käsitys service deskin toiminnasta. Service deskin tehtävänä on olla käyttäjien kontaktipiste erilaisissa asioissa. Näitä ovat tilaukset, muutokset, ongelmat ja viat. Kaikki nämä asiat kytkeytyvät tiiviisti organisaation toimintaan. Tilausten tehokas käsittely voi edellyttää muutoksia organisaation toiminnassa. Vikojen ja ongelmien aiheuttajiin pitää puuttua. Ulkoistuskumppanin on vaikea ryhtyä kehittämään asiakkaansa toimintaa. Ulkoistaminen ei aina tuota toivottua tehokkuutta ja selkeyttä. Pahimmillaan sotkun ulkoistamisesta tulee ulkoistettu sotku.

Service desk -palvelun tuottaja tuottaa luonnollisesti palvelua monelle asiakkaalle ja palvelutuottajan intresseissä on palvelun tehostaminen ja standardointi. Asiakkaan kannalta tämä on harvoin toivottava kehitys. Palvelun hinnoittelulla ja palvelusopimuksilla on toki ohjaava vaikutus palvelun tuottajaan, mutta kokemusten mukaan ne eivät läheskään aina toimi kovin hyvin. Palvelun tuottajalla ei ole minkäänlaista mielenkiintoa turhien häiriöiden poistamiseen jos palvelusta maksetaan yhteydenottojen perusteella. Kiinteähintaisen palvelun tuottajan intresseissä on yhteydenottojen vähentäminen, mutta tämä sujuu parhaiten rajaamalla tiukasti käsiteltävät asiat ja työntämällä mahdollisimman paljon asioita asiakaan käsiteltäväksi. Huono palvelu myös vähentää yhteydenottoja tehokkaasti.

Service deskin ulkoistaminen onnistunee parhaiten silloin, kun palvelun tuottaja vastaa myös kaikista tietotekniikkapalveluista. Silloin palvelun tuottajan intresseissä on palvelun kehittäminen ja turhien häiriöiden poistaminen. Tämä toimii parhaiten silloin, kun asiakkaan liiketoiminta ei ole kovin tietotekniikakeskeistä. Silloin tietotekniikkaa käytetään standardivälineillä ja varsinaisen liiketoiminnan kehittämiseen ei liity tietotekniikan hyödyntäminen. Kokemusteni mukaan tällainen toiminta on harvinaista. Monien organisaatioiden toiminnan kehittäminen nivoutuu tiiviisti yhteen tietoteknisten ratkaisujen kehittämisen kanssa.

Valtionhallinnossa on käynnistymässä laaja ulkoistus. Valtori ryhtyy tuottamaan toimialariippumattomia it-palveluja valtion eri organisaatioille. Tämä sisältää myös Service desk -palvelut. Oma käsitykseni on, että tämä on virhe. Tuki on todellisuudessa toimialariippuvaa, joten eri yksiköiden on hoidettava oma tukensa itse, mutta lisäksi ne joutuvat maksamaan keskitetyn organisaation palveluista. Jos Valtori olisi kaupallinen palvelu, se tekisi pian konkurssin, mutta valtiollisena sillä on monopoli, joten se voi tuottaa kalliita ja huonoja palveluja.

Onnistumiset kehittämisessä

Tästä kyselystä tuli selvästi vähemmän onnistunut.

Tällä kertaa olen kiinnostunut onnistumisista toiminnan kehittämisessä vuonna 2014. Olisi hauska päästä jakamaan hyviä vinkkejä onnistumisista.
Onnistumisella tarkoitan hanketta, joka on parantanut asiakkaiden saamaa palvelua jollain todistettavalla tavalla. Todistettavalla tarkoitan, että sinulla on jokin keino, joka mielestäsi riittää osoittamaan saavutetun hyödyn.  Voit kertoa onnistumisesta myös asiakkaan tai yhteistyökumppanin roolista katsottuna.
Kehittäminen voi olla mitä vain, monivuotinen iso hanke tai pieni muutos toimintatavoissa.  Hanke voi olla kesken tai päättynyt, kunhan sen tuloksista on saatu näyttöä tämän vuoden aikana.
Kerro lyhyesti jos olet nähnyt, ollut mukana tai vetänyt jonkin onnistuneen kehittämisen. Voit toki kuvata useita onnistumisia.
1) Mitä tehtiin?
2) Miten tiedät että hanke onnistui?
 3) Mikä oli roolisi?

Vain neljä henkilö vastasi samana päivänä, joka on kaikkein heikoin tulos mitä mikään kysely on saavuttanut. Kuvittelin että kysymys olisi ollut helppo, että vastaajien olisi ollut helppo poimia yksi onnistunut hanke, mutta siinä erehdyin. Tarkoitin toiminnan kehittämisellä oman toiminnan kehittämistä, eli siis jonkinlaista it-palvelunhallinnan hanketta, mutta vastaajat tulkitsivat sen tarkoittavat kaikenlaisia kehittämishankkeita. Kysymys oli tarkoituksella hieman epämääräinen, koska en halunnut johdatella vastaajia. Tavoitteenani oli selvittää minkälaisia hankkeita mainittaisiin onnistuneiden joukossa ja yrittää vetää siitä johtopäätöksiä.

Koska vastauksia tuli niin vähän, tein jatkokysymyksen, jolla halusin selvittää johtuiko vastaamattomuus siitä, että kehityshankkeita ei ole käynnissä. Epäilin myös että kohderyhmä on saattanut väsyä kyselyihin ja lisäsin viestiin myös ohjeet postituslistalta poistumiseen. Sen seurauksena sainkin ennätysmäärän poistopyyntöjä. Jatkokysely tuotti kuitenkin myös lisää vastauksia.

Eilinen onnistumisia koskeva kysely sai vähemmän vastauksia kuin yksikään aikaisempi kyselyni.  Ilmeisesti esitin väärän kysymyksen.  Tässä on vaihtoehtoinen kysymys onnistumisista toiminnan kehittämisessä.
 
Oletko havainnut onnistuneita kehittämistoimenpiteitä tai hankkeita? 
a) meillä ei ole tehty mitään kehittämishankkeita tai toimenpiteitä
b) niitä on tehty, mutta en tiedä ovatko ne onnistuneet
c) niitä on tehty, mutta ne eivät ole onnistuneet
d) niitä on tehty ja ne ovat onnistuneet
e) en halua vastata
 
Jos vastaat c) tai d) niin olisi tietysti hauskaa jos ehtisit myös vastata eiliseen kyselyyn. Jos haluat pois postituslistalta, vastaa tähän postiin ja laita aiheeksi: ei postia
 

Tässä tulokset.

Vastauksia tuli kaikkiaan 55 kpl.

 

Slide1

Valtaosalla on onnistuneita kehittämishankkeita, eli vastaamattomuus ei johtunut niiden puutteesta.

Vastauksista löytyi tietoa 27 kehittämishankkeesta.

Slide2

Reilu kolmannes oli jonkin ohjelmiston asennuksia, olen tulkinnut ne työkaluiksi tässä. Seuraavaksi yleisintä oli liiketoiminnan kehittäminen tavalla tai toisella. Tähän kuului mm. kannattavuuden parantamista ja kohtaamiskyselyn kehittäminen. Menetelmäkehittäminen liittyi useimmiten sovelluskehittämiseen, joskin mukana oli muutama prosessikehittäminen. Harvinaisimpia olivat ns. varsinaiset ITSM hankkeet. Palveluportfolio mainittiin muutaman kerran, muuten kohteet olivat yksittäisiä.

 

Slide3

Kysyin myös miten onnistuminen arvioitiin. Reilu kolmannes ei mitannut hankkeitaan, saman suuruinen osuus mittasi joko asiakkaiden tai liiketoiminnan kautta ja neljännes käytti sisäisiä mittareita.

Tuloksista on vaikea vetää johtopäätöksiä. Onnistuneita ITSM hankkeita ei tullut esiin, mutta se ei tarkoita etteikö niitä tehtäisi. Mitään erityisen suosittua kehittämistä ei tullut esiin, ei myöskään yhtään hyvää yleistettävissä olevaa kehittämisvinkkiä. Yksi johtopäätös lienee, että vastaajat alkavat olla väsyneitä kyselyihin.

Tyhjän päällä

Kirjoitin pyynnöstä blogin englanniksi näkemyksistäni FUSION-konferenssin jälkeen. Siinä esitän että it-palvelunhallinta on kuin Kelju K. Kojootti, joka juoksee kielekkeeltä, mutta ei huomaa heti olevansa tyhjän päällä. Juttu löytyy täältä: http://www.hdiconnect.com/blogs/servicemanagement/2014/10/fusion-creating-value-not-managing-processes.aspx

Fusion14

Fusion on itSFM USA:n ja HDIn yhteinen konferenssi, joka järjestettiin tänä vuonna Wasington DC:ssä. Paikkana on Gaylord National, joka sijaitseen itseasiassa Marylandissa, joen toisella puolella. Minulle näiden konferenssien suurin anti on kavereiden tapaaminen. Tällä kertaa tapasin monta henkilöä, joiden kanssa olen ollut tähän asti tekemisissä vain sosiaalisen median kautta, mutta toki myös monta vanhaa kaveria.

Välillä oli melkein julkkisfiilis. Tämä oli kyllä ehdottomasti huikein tervehdys:Fusion3

En ollut tavannut kaveria aikaisemin muuten kuin sosiaalisesssa mediassa. Olimme jollain VIP vastaanotolla ja hän näkee nimikylttini ja alkaa tosiaan hokea Aale Roos, olet jumala…

Konferenssissa ei ainakaan minulle noussut esiin mitään selkeää teemaa. Ehkä jonkinlainen hämmennys voisi kuvata parhaiten mielentilaa. Internetin ja mobiliteetin tulevasta vallankumouksesta on puhuttu paljon ja hartaasti, mutta nyt kun se lopulta on lähtenyt käyntiin suuressa mittakaavassa niin kaikki ovat ymmällään.

ITIL ja muut vanhat mallit ovat menettäneet viehätysvoimaansa, mutta vakavia kilpailijoita ei ole vielä ilmestynyt tilalle.

Oma esitykseni oli ehkä paras, mitä olen koskaan pitänyt. Sain hyviä kommentteja ja kritiikkiä järjestäviltä. Fusion14 conference photos.

Lisäksi sain puhua täpötäydelle salille, joka on aina innostavaa. Joitakin ihmisiä istui lattialla ja seisoi salin takaosassa.

Fusion14 conference photos.

Olin etukäteen hiukan huolestunut oman esitykseni ajankohtaisuudesta. Tiedän että Service Desk 2.0 on täällä Suomessa etäistä tulevaisuutta monille, mutta en ollut varma siitä missä USAssa mennään. Huoli osoittautui turhaksi, USAssa ei olla meitä edellä tässä suhteessa, mutta oli positiivista huomata, että moni kuulija näytti tajuavan viestini. Monet tulivat kiittelemään jälkeen päin ja kertoivat esityksen herättäneen ajatuksia.

 

 

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ä.

Seuraa

Get every new post delivered to your Inbox.

Liity 73 muun seuraajan joukkoon

%d bloggers like this: