Strategioiden vääntäminen tympäisee

Kauppalehden mukaan : Suomalainen yritysjohto on kyllästynyt tuottamaan paksuja strategianivaskoita, jotka laahaavat jäljessä ja jäävät liian usein toteutusta vaille.

Prosessia halutaan yksinkertaistaa, jotta nopeat liikkeet muuttuvilla markkinoilla olisivat mahdollisia. Tämä käy ilmi liikkeenjohdon konsulttiyhtiön MPS Executive Searchista tuoreesta johtajuustutkimuksesta. Kolme neljästä vastaajasta on sitä mieltä, että aikaavievät, yksityiskohtaiset ja joustamattomat strategiat koetaan työyhteisöissä painolastiksi. Kaksi kolmesta vastaajasta on sitä mieltä, että suunta on yksityiskohtaista suunnitelmaa tärkeämpi.

Olen samaa mieltä. Tulevaisuuden suunnitteleminen sisältää riskinsä. Palvelun elinkaarimallia ei pidä tulkita liian kirjaimellisesti erityisesti lukemattomat suunitelmat kannattaa unohtaa. En kertakaikkiaan usko, että mistään löytyy sellaista it-organisaatiota, joka osaisi suunnitella tulevaisuuden asiakaslähtöisesti. IT yksikkö toki voi suunnitella tulevaisuuden ja toteuttaa sen suunnitelman mukaisesti, mutta silloin organisaatio alistuu elämään IT:n ehdoilla. Niitäkin on varmaan paljon.

Tulevaisuudessa voi käydä niin että yhä useimmin tietotekniikkapalvelut ostetaan verkosta ja it-yksikön rooli supistuu. Siinä on paljon riskejä, mutta ei se ole täysin mahdotonta. Itse olen aika lähellä sitä mallia. Ainoa paikallinen sovellus on Office. Varmistukset, sähköposti, kotisivut, palkanlaskenta, pankki ja ilmoittautumislomakkeet pyörivät verkossa. Tämä tarkoittaa että monet asiat voi unohtaa. Minun ei tarvitse miettiä vaikka sähköpostiserverin varmistamista tai sen kapasiteetin riittävyyttä. Palveluntarjoajani huolehtii siitä, minun täytyy vain luottaa siihen että he tekevät työnsä kunnolla.

Ketterä strategia on uusi termi, joka kuvaa toimintaa nopeasti muuttuvassa ympäristössä. Jukka Ala-Mutka kuvaa ketterää strategiaa näin: Vertauskuvallisesti ketterä strategia on kuin iso kalaparvi, joka muuttaa yhtäaikaa suuntaa saavuttaakseen (liikkuvan) päämääränsä tai välietappinsa. Löydämme vastaavan analogian purjeduksesta, jossa päämäärä on selkeä, mutta reitti vaihtelee olosuhteiden mukaan jatkuvasti navigoiden – lähietäisyys ja pitkätähtäin on kokoajan mukana navigoinnissa. Ketteryys on myös loogisesti päinvastaista kuin jäykkyys ja rajoitteet. Jäykkyyttä aiheuttavat pinttyneet ja ehdottomat ajatusmallit kuten ”yrityskaupat eivät koskaan onnistu”, jäykistävät sopimukset asiakkaiden ja toimittajien kanssa, monotonisesti toistettavat toimintoketjut ja tiukat kontrollijärjestelmät mm. budjetoinnissa.

Tietotekniikkapalveluille strateginen ketteryys aiheuttaa haasteita. Palvelujen pitäisi kyetä mukautumaan nopeasti uusiin tarpeisiin. Tehokkuus ja turvallisuus eivät taida asua samassa talossa ketteryyden kanssa. Prosessista voi helposti tulla jäykkä, monotonisesti toistettava toimintoketju.

Palautteen käsittely

Edellisessä artikkelissa esittelin 3P-mallin. Siinä asiakkaiden yhteydenotot jaetaan kolmeen pääryhmään: palvelu, pulma ja palaute. Itilistä voi halutessaan löytää prosessit palavelun ja pulman hallintaan, mutta palautteen käsittelylle itil ei tarjoa mallia. Toisaalta ISO 20000 vaatii että palutteen ksäittelylle pitää olla prosessi.

Tein pikakyselyn 12.11.2010 jolla selvitin palautteen käsittelyn käytäntöjä. Normaalista käytännöstä poiketen, tämä kysely lähetettiin vain niille, joiden arvelin olevan kiinnostuneita asiakastuesta.

Pikakyselyn aiheena on tällä kertaa service/help deskiin tuleva palaute ja sen käsittely. Tarkoitan palautteella asiakkaiden ilmaisemia mielipiteitä palvelusta ja sen elementeistä: ohjelmistoista työkaluista, henkilöistä jne.

1) Miten palaute käsitellään?

a) ei mitenkään, asiakasta voidaan pyytää ottamaan yhteys muualle

b) palautteita kuunnellaan mutta ei kirjata

c) palautteet kirjataan mutta ei käsitellä erikseen

d) kaikki palaute kirjataan ja sisältö raportoidaan edelleen palvelusta vastaaville

e) muuten, miten

2) Kuinka paljon palautetta tulee

a) en tiedä

b) hyvin vähän

c) aika paljon

d)  ___% yhteydenotoista

3) Toimiiko palautteen käsittely mielestäsi teillä hyvin?

a) ei

b) kyllä

Vastauksia tuli 33 kpl eli näyttää siltä, että kyselyn kohdentaminen pudotti vastausten määrää suunnilleen samassa suhteessa. Toisin sanoen vastaajien luokittelu ei näytä kannattavan.

Kyselyn tulokset.

Huom! klikkaa kuvaa niin näet sen suurempana, en näytä osaavan valita tarpeeksi suurta fonttia teksteille!

Kaksi kolmesta kertoo kirjaavansa palautteen ja toimittavansa sen käsiteltäväksi. Eräs vastaaja kysyi, miksei vastausvaihtoehtona ollut että palveluyksikkö vastaa käsittelystä itse. Käsittääkseni se ei ole normaalisti mahdollista, koska palaute voi koskea mitä vain.

Reilu puolet sanoi palautetta tulevan hyvin vähän ja 15% aika paljon. Vain 12 % ilmoitti tarkan määrän ja 21 % oli rehellisiä 😉 ja kertoi ettei tiedä määrää. Tämän kysymyksen vastaukset horjuttivat hiukan edellisen kysymyksen vastausten uskottavuutta. Jos kerran palautteet kirjataan, niin kaipa niiden määrät olisi helppo tarkistaa. Ilmoitetut määrät vaihtelivat reilusti välillä 0,2 % – 15%.

Palautteen käsittelyä piti toimivana kaksi kolmesta.

Sain paljon pyytämiäni vapaamuotoisia vastauksia. Niiden perusteella tulkitsin oliko käytössä palautteen käsittelylle prosessi vai ei. Niiden mukaan reilulla kahdella kolmasosalla on prosessi. Muutamat tulkitsivat palautteeksi vain vastaukset palautekyselyyn. Toki sekin on palautetta mutta ei sitä palautetta, jota tarkoitin.

Prosessin olemassaololla ja palautteen määrällä on selvä yhteys. Kaikilla niillä, jotka kertovat saavansa paljon palautetta, on prosessi sen käsittelyyn.

On myös mielenkiintoista, että sisäinen yksikkö saa selvästi enemmän palautetta kuin ulkoinen palveluorganisaatio.

Kommentit

Alla on muutama poiminta avoimista vastauksista.

EI PROSESSIA

•      Ainakaan tietoa palautteen käsittelystä ja tehtävistä muutoksista ei tule tukihenkilöstön tietoon.

•      Palaute ei ole määritelty incidentiksi tai service requestiksi, joten sitä ei kirjata, se ei aiheuta toimenpiteitä eikä sitä seurata

•      kytkentä Jatkuvaan kehitykseen ja esim. asiakkuudenhallintaan on liian epämuodollinen

•      mielestäni palautteet tulisi kirjata ja käsitellä. Ne pitäisi myös viedä järjestelmään josta ne saataisiin helposti raportoitua. Nyt palautteita tulee eri kanavista ja kokonaiskuvan saaminen on mahdotonta.

PROSESSI

•      Palautteen käsittely on tarkkaan ohjeistettua

•      Toimii hyvin niiden yksiköiden helppari-hlöillä, joiden yksikössä Reklamaatio -prosessi on käytössä.

•      Aktiiviset käyttäjät antavat enemmän palautetta. Palautteen saaminen on myös yksi keino kehittää toimintaa

•      Systemaattisempi toimintamalli ollut käytössä vasta muutaman kuukauden. Kokemukset kuitenkin rohkaisevia

•      Saadut palautteet ja reklamaatiot kirjataan toiminnanohjausjärjestelmään ja käsitellään sovitun prosessin mukaisesti.

•      Palautteen käsittelyssä on parannettavaa ja palautteen määrää pitäisi saada suuremmaksi.

•      Palaute kirjataan meillä eri järjestelmään kuin mitä käytetään ServiceDeskissä. Menettely on huono ja prosessi asiakaspalautteen käsittelyssä epäselvä.

Johtopäätökset

Vastaajat ovat fiksumpia kuin itilin kirjoittajat, sillä selvä enemmistö oli ottanut käyttöön palautteen käsittelylle jonkin prosessin ja monet tajusivat että service desk on kanava, jonka kautta palautetta voi tulla. Vain yksi vastaaja kertoi, että palautetta ei käsitellä, koska se ei ole insidentti tai palvelupyyntö. Olen saanut saman vastauksen usein, kun olen kysynyt miten niitä käsitellään. Epäilen, että käytäntö on yleisempi mutta vain yksi kehtasi tunnustaa sen. Tuloksia ei pidä yrittää yleistää sillä tällaisessa kyselyssä on niin monta suodatinta, ettei niiden vaikutusta voi arvioida luotettavasti. Kysely varmasti kiinnostaa enemmän niitä, jotka ovat heränneet pohtimaan palautteen käsittelyä.

Kaikkein mielenkiintoisin tulos on se, että havaitun palautteen määrä riippuu kahdesta seikasta:

1) Palautetta saadaan vain, jos sille on määritelty prosessi

2) Sisäiset yksiköt saavat useammin palautetta kuin ulkoiset palveluyksiköt.

Olen sitä mieltä, että spontaani palaute on arvokasta tietoa palvelun kehittämiselle ja sitä pitää kerätä. Tulosten mukaan sitä ei pysty keräämään, ellei siihen ole määritelty prosessia. Luulen, että palautetta tulee, jos sitä halutaan vastaanottaa. Useampi vastaaja raportoi siitä, että prosessin käynnistäminen kasvatti palautteen määrää. Toki on tärkeää että prosessi toimii kunnolla, epäilen että osalla vastaajista on käytössä huonosti toimiva prosessi.

Sisäisen ja ulkoisen yksikön eroa saattaa selittää se, että palveluorganisaatio on määritellyt toisen palautekanavan. Palaute pyydetään ohjaamaan palvelupäällikölle. Sisäisessä yksikössä ei olla näin muodollisia.

Menetelmä

Tämäkin kysely on tehty kolmen kysymyksen menetelmällä. Kuten huomaat, siitä saa aika paljon irti kun tutkii eri asioiden kytkentöjä. Mielestäni tällä kertaa mielenkiintoisin tulos oli se, että paljon palautetta tulle ainoastaan jos palautteen käsittelylle on prosessi. Tulos ei ole itsestään selvä.

Palvelu, pulma ja palaute

Onko Service Deskin tärkein prosessi häiriönhallinta? Se riippuu mistä päin asiaa katsoo. Palvelun tuottajan näkökulmasta on tietysti tärkeää, että häiriöt hoidetaan. Asiakkaan näkökulmasta taas on tärkeintä että palvelu toimii, häiriöt ovat vain yksi elementti kokonaisuudessa. Asiakkaan näkökulmasta huonot ohjeet voivat olla paljon pahempi haitta kuin 30 minuutin katko lounasaikaan.

Asiakaspalvelun tehtävänä on palvella asiakkaita. Asiakkat haluavat palvelua, mutta joskus heillä on pulmia ja joskus he antavat palautetta. Asiakaspalvelun muistisääntö on siis 3P. Palvelu, Pulma ja Palaute.

Palvelu on se syy, miksi palveluorganisaatio on olemassa.  Organisaatio tarjoaa palveluja asiakkailleen ja voidakseen tuottaa niitä, se tarvitsee tilauksia. Asiakas voi tilata peruspalveluja, erikoispalveluja ja muutoksia olemassaoleviin palveluihin.

Pulma syntyy kun asiakas ei saa palvelua toimimaan haluamallaan tavalla. Pulma voi johtua siitä että asiakas ei osaa käyttää palvelua tai on tehnyt jonkin virheen ja tarvitsee apua. Palvelussa voi myös esiintyä häiriöitä ja palvelu voi olla jokin vika.

Palaute on erittäin tärkeä asia palveluorganisaatiolle. Sen pitää kuunnella asiakkaitaan ja jokainen kommentti, toive, parannusehdotus ja valitus pitää kirjata.

Oman käsitykseni mukaan asiakastuen pitäisi kyetä hoitamaan näitä kaikkia lajeja, sillä kaikkia kolmea voi esiintyä yhden puhelun aikana.

Asiakas ei saa haluamaansa palvelua toimimaan ja käy ilmi, ettei hän ole tilannut sitä versiota, joka sisältää hänen haluamansa option. Asiakkaan mielestä ohjeet ovat olleet epäselvät.  Luontevinta olisi, että tukipalvelu hoitaisi tilauksen ja kirjaisi valituksen. Valitettavan tavallinen vaihtoehto on, että asiakkaalle annetaan toinen puhelinnumero palvelutilausta varten ja ohjataan täyttämään palautelomake .

Palvelutilausten (miksi ihmeessä itilistit kutsuvat niitä pyynnöiksi) rutiininomainenvastaanottaminen tuessa ei ole kaikissa tapauksissa järkevää. Palvelutilauksien määrät voivat olla suuria, eikä niiden vastaanottamiseen tarvita samanlaista ammattitaitoa kuin asiakkaiden pulmien ratkomiseen. Tässä ei ole siis olemassa yhtä selkeää parasta käytäntöä, vaan toimintamalli pitää valita tilanteen mukaan. Tärkeintä on kuitenkin katsoa asiaa asiakkaan näkökulmasta, eikä keskittyä vain optimoimaan omaa tehokkuutta. On parempi olla joustava kuin huipputehokas, koska asiakaspalvelun tehokkuus on näennäistä, jos se luo pulmia muualle tai vähentää asiakkaita..

Pulmat voidaan jakaa kolmeen ryhmään:

  1. asiakkaasta johtuvat
  2. epäselvät
  3. viat

Toki pulmat voidaan jakaa muillakin tavoilla, mutta tämä määrää jatkokäsittelyn. Asiakkaasta johtuvat pulmat ratkeavat neuvonnalla. Häiriöt kyetään ohittamaan ja viat pitää korjata. Tämä on juuri häiriön ja vian ero, häiriö haittaa palvelua ja vika estää sen. Jotta häiriö voidaan ohittaa tai vika korjata, meidän on selvitettävä sen aiheuttaja. Tämä ei tarkoita että vika on muuttunut ongelmaksi. Asiakastuen ensisijainen tehtävä on palauttaa palvelu ja joskus edellyttää vian aiheuttajan ratkaisemista. En nyt käsittele ongelmanhallintaa tässä, kirjoitin siitä äskettäin, katso https://pohjoisviitta.wordpress.com/2010/10/21/ongelmanhallinta/

Palautteiden käsittely on tärkeää. Niille pitää olla kanava ja viestien pitää päätyä oikeaan paikkaan. Negatiivinen palaute on herkkä asia ja sitä pitää käsitellä taidolla. Yksittäisiin tulikiven katkuisiin valituksiin ei saa kiinnittää liikaa huomiota, konflikteissa on kaksi osapuolta. Toistuvat valitukset ovat tärkeitä ja erityisen tärkeitä ovat kehitysehdotukset.

Hyvä vierailija

Tutkin vierailutilastoja ja huomasin, että aktiivisten kävijöiden joukossa näytti olevan jonkun verran minulle vieraita organisaatioita palvelinten nimien perusteella.

Voit liittyä jakelulistalleni oikealla olevalla Tilaan tiedotteen-linkillä. Toinen vaihtoehto on vasemmalla oleva WordPressin sähköpostipalvelu, joka lähettää viestin aina kun tänne ilmestyy uusi juttu. Kolmas vaihtoehto on RSS-tilaus tuossa yläpuolella, joka myös ilmoittaa uusista artikkeleista. Tilauksen voi aina lopettaa enkä luovuta mitään tietoja edelleen.

Postia toki lähetän. Kerran kuukaudessa tulee Reittisuunnittelu-tiedote ja teen pikakyselyjä ajoittain, tänä vuonna 5 kpl. Lähetän raportin tuloksista yleensä kaikille. Yhteensä olen lähettänyt tänä vuonna 20 viestiä eli jos se ei tunnu liialliselta niin tilaa tiedote.

Lukijaennätys

Perjantaina tuli uusi yhden päivän kävijäennätys. Ilmeisesti Service Desk -mallin kehitys kiinnostaa monia.  On hauska että tutkimuksia luetaan, sillä niiden tekeminen on melko työlästä. Juttu saisi varmaan lukijoita ITSM portalissa kunhan vain saisin siitä väännettyä englanninkielisen version.

%d bloggers like this: