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

Kipupisteet

Pink Elephantin vetäjä David Ratcliffe esitti viime viikolla hyvän kysymyksen twitterissä ja päätin kopioida sen helmikuun pikakyselyksi:  What has been your first big ITSM pain point so far in 2013? Suomeksi kysymykseni on siis vapaasti käännettynä. Mikä asia on harmittanut eniten it-palveluhallinnassa alkaneen vuoden aikana?

Valitsin tämän kysymyksen, koska minun oli itse helppo vastata tähän. Ilmeisesti kaikilla ei ollut vastaavia kokemuksia, koska vastauksia tuli aika vähän, 28 kpl.

Yleisin aihe oli huono palvelun laatu, niitä oli melkein kolmasosa. Esimerkkejä olivat palvelun hitaus, toimimattomuus ja epämääräisyys.

Ulkoisen palveluntuottajan heikko laatu toiminnassaan; suunnattomasti virheitä, viesteihin ei vastata,  ei tehdä mitä sovitaan vaan tehdään ihan jotain muuta,….

Kakkosena tuli johto, eli johdon kyvyttömyys päättää asioista tai ohjata toimintaa.

Minua on harmittanut ylemmän johdon ymmärryksen niukkuus yhä siitä miten olennainen heidän rooli on muutoksen jalkauttamisessa.

Seuraavat aiheet olivat prosessit

Palveluprosesseja ei ole saatu kaikilta osin lanseerattua päivittäiseen toimintaan ja prosessien kehittäminen on jatkuvaa – muutokset samoin.

ja työkalut, jotka eivät toimi halutulla tavalla.

Käytössä olevan ITSM -työkalun sopimattomuus meidän prosesseihin.

Vastaukset olisi toki voinut luokitella toisinkin, työkalut, johto, palvelun laatu liittyvät monessa mielessä prosesseihin ja niiden soveltamisen vaikeuteen.

Omat vastaukseni oli tämä:

Yritän tehdä yhteistyötä muualla asuvan asiakkaan kanssa. Kokemusteni mukaan yhdistelmä Google Hangout ja Google Docs on loistava. Siinä joukko ihmisiä voi työstää samaa dokumenttia ja keskustella videoneuvottelussa yhtä aikaa. Valitettavasti yhteistyö kaatui sisäisen IT.n luomiin esteisiin. Tilalle tarjottiin työkalu, joka ei toiminut. Tietoturvan perusteella estetään tuottavuuden nostaminen. Ehkä tämäkin on palvelun laatua.

Hyvä kysymys on sitten se, mikä ei noussut esiin?

 

ISM menetelmä

ism

ISM Method on TSO:n julkaisema uusi kirja it-palvelunhallinnasta Kirjoittajien, Wim Hoving & Jan van Bon mukaan ISM Method on tarpeen, koska monet organisaatiot ovat turhaan yrittäneet soveltaa ITILiä huonolla menestyksellä. Vuosien yrittämisen jälkeen käyttöön on saatu kaksi tai kolme prosessia. Käyttöönottohankkeita on tehty ja prosessikuvauksia löytyy, mutta henkilökunta ei niitä käytä. Tilanne vaikuttaa tutulta myös Suomessa, puheiden ja todellisuuden välissä on kuilu. Prosessikehittämiseen on uhrattu aikaa ja resursseja, mutta todellisuudessa tulokset ovat vähissä.

 

Sisältö

Kirjan ensimmäinen luku käsittelee it-palveluhallinnan historiaa. Se on ehkä vähän akateeminen, mutta auttaa ymmärtämään kokonaisuutta. Siinä esitellään itil ja sen edeltäjiä, MOF, Cobit, PRINCE, standardit ja ehkä tärkeimpänä SAME, Strategic Alignment Model Enhanced.

SAME jakaa kentän yhdeksään ruutuun toiminnan ja tason mukaisesti. Tasot ovat tutut strategia, taktinen ja operationaalinen.

SAME

Toiminnat ovat liiketoiminta, informaatio ja teknologia. Yksinkertainen esimerkki voisi olla palkanlaskenta. Toiminta määrittelee organisaation tarpeet strategiassa, valitsee ihmiset ja määrittelee maksettavan palkan. Henkilöstöhallinto määrittelee henkilöstöhallinnon tietotarpeet, valitsee järjestelmän ja syöttää tarvittavat tiedot järjestelmään. It-palvelunhallinta huolehtii järjestelmän toimivuudesta ja pyörittää sitä.

ISM menetelmä lisää tähän vielä kolmannen ulottuvuuden: ihmiset – työkalut – prosessit. ITSM:n toimialue on kansikuvan mukaisesti oikean reunan kaksi alinta laatikkoa, eli teknologia taktisella ja operationaalisella tasolla. Mielestäni rajaus on tärkeä ja oikea. Itil antaa väärän kuvan it-palvelunhallinnan toimialasta, ikään kuin it-palvelun tuottaja vastaisi koko toiminnan kehittämisestä. Strategista ajattelua toki tarvitaan it-palvelunhallinnassa, mutta ei prosessia.

Kirjan toinen luku kuvaa ITSM-ajattelun nykypäivää. Se on täsmällinen ja selkeä katsaus niistä käsitteistä ja periaatteista, joilla it-palveluhallintaa ohjataan. Käsitteet määritellään täsmällisesti ja loogisesti. Kirjassa kuvataan selkeästi taktisen ja operationaalisen toiminnan erot, esimerkiksi itil ongelmanhallinta sotkee taktisen ja operationaalisen toiminnan samaan prosessiin. Tämä on suuri kehitysaskel verrattuna sekavaan ITIL-käsitteistöön. It-palvelu määritellään näin: toimivien it-toiminnallisuuksien (eli automaattisen tietojenkäsittelyn) tarjoaminen. Toisin sanoen palvelu sisältää joitakin toiminnallisuuksia eli ominaisuuksia jotka myös toimivat.

Kolmas luku esittelee ISM mallin. Tavoitteena on kuvata it-palvelunhallinnan aidot ydinprosessit, ei toimintoja. Pyrkimyksenä on selkeys ja yleisyys. Jokaisella organisaatiolla on samat prosessit, erot näkyvät proseduurien ja työohjeiden tasolla. Malli on standardoitu ja minimalistinen, mukana on vain tärkeimmät osat.

Menetelmään kuuluu viitekehys, (framework) käyttöönottomenetelmä ja tuki. Kirjoittajien mukaan tämä on merkittävä ero, ISM on tarkoitettu käyttöönotettavaksi toisin kuin itil.

Neljäs luku esittelee sitten itse menetelmän. It-palvelun pyörittämiseen tarvitaan kuusi toisiinsa liittyvää prosessia ja ne otetaan käyttöön vaiheittain, sillä mikään organisaatio ei kykene käsittelemään kovin montaa muutosta yhdellä kertaa. Prosesseille on anettu itilin mukaiset nimet, mutta niitä kuvataan myös verbeillä, jotka olen kääntänyt suomeksi. Viestinä on että prosessit eivät ole mitään epämääräistä hallinnointia vaan asioiden tekemistä.

ismISM pros

Viides luku kuvaa itse prosessit. Näistä mielenkiintoisin on Operations Management eli toimitusprosessi. Se sisältää kaksi aliprosessia: toteutus ja valvonta. Toteutus huolehtii päivittäisistä rutiineista ja tekee hyväksytyt muutokset. Valvonta taas valvoo kaikkia järjestelmiä ja tarvittaessa raportoi häiriöistä.

Arvio

ISM menetelmä on houkuttelevan selkeä ja minimalistinen. Kirjan lukeminen voi saada monet ymmärtämään, miksi nykyiset prosessit eivät toimi. Kirjasta löytyy paljon täsmällisiä ja selkeitä määritelmiä asioille.

Menetelmän heikkous voi olla siinä, että se ei kuvaa informaatio-tasoa lainkaan. Esimerkiksi service deskin toiminnot ovat enemmän sillä tasolla. Olen väitellyt Jan van Bonin kanssa monet kerrat asiakastuen merkityksestä, mutta Janilla on mielestäni aika suppea näkemys siitä. ISM ei siis tarjoa mitään uutta ja innovatiivista palvelun kehittämiseen.

Menetelmä on kaupallinen siinä mielessä että Jan tarjoaa sekä koulutusta että konsultointia menetelmään ja veloittaa menetelmän käytöstä. Toisaalta mikään ei tietenkään estä soveltamasta kirjan oppeja omaan toimintaan.

Jos organisaatiosi on tunnistanut tarpeen saada it-tuotanto toimimaan tehokkaammin ja luotettavammin, ISM menetelmä on vastaus. Jos tarvitset selkeän viitekehyksen ip-palvelutuotannolle, unohda itil ja tartu tähän kirjaan.

Kypsyydestä

It-organisaation tilaa voi kuvata sen kypsyystasolla. Kypsyystasot ovat usein suhteellisen helppo tunnistaa ja niistä on olemassa lukuisia malleja. Lähtökohtana on yleensä yksilöllinen toiminta, johon tulee ensin valvontaa, sitten hallintaa, ohjausta ja optimointia. On tavallista ajatella että kypsyydessä pitää pyrkiä aina korkeimmalle tasolle, mutta se ei ole välttämättä totta. Olen käyttänyt renkaiden vaihtoa esimerkkinä erilaisista kypsyystasoista.

 0-taso Sakkokuski ei vaihda renkaita kuin pakon edessä.
1-taso Yksityisautoilija tarkistaa renkaiden kunnon kesä/talvi-renkaiden vaihdon yhteydessä ja hankkii uudet kun kulutuspinta alkaa olla vähissä.
2-taso Taksiyritys uusii renkaat 50.000 km välein.
3-taso Bussiyhtiön ajomestari seuraa renkaiden kulumista ja määrää vaihtohetken puoli vuotta aikaisemmin.
4-taso Rekkayhtiö seuraa renkaiden kulumista ja maksaa kuljettajille bonuksia jos renkaat kestävät keskimääräistä paremmin.
5-taso Formula 1 talli arvioi renkaiden keston kierroksen tarkkuudella, mutta muuttaa suunnitelmia, jos olosuhteet vaihtuvat. Renkaan vaihtohetkeen vaikuttavat rata, kierrosajat, sää ja muiden kilpailijoiden toiminta. Tavoiteaika vaihtoon on 4 sek.

 Edellä kuvattu malli korostaa sitä, että tavoiteltava kypsyystaso riippuu tarpeesta, mutta toki jokainen voi toimia tarvittavaa matalammalla kypsyystasolla.

Elokuun kyselyn teemana oli KPMG:n jo vuonna 2000 julkaisema malli IT yksikön kypsyydestä. Mielestäni malli on edelleen osuva.

Mallin kypsyystasot

  1. Teknologialähtöinen. IT taistelee tekniikan kanssa, juuri mitään prosesseja ei ole käytössä. Asiakas saa sitä mitä kyetään tarjoamaan. Toiminta voi sinänsä olla melko asiakaslähtöistä, mutta sen laadun ja luotettavuuden kanssa on ongelmia.
  2. Prosessikeskeinen. Prosessit on saatu toimimaan ja IT kykenee mittaamaan toimintaansa. Prosessit ovat keskeisessä roolissa ja asiakkaan tulee mukautua niihin, muuten palvelu ei toimi.
  3. Palvelukeskeinen. IT on määritellyt palvelunsa ja kykenee tuottamaan niitä ohjaamalla prosessejaan. Palvelut ovat standardoituja. Asiakas voi tilata palveluja, mutta ei voi muokata niitä.
  4. Asiakaskeskeinen. Nyt asiakas pääsee päättämään palveluista ja IT toimii lähellä asiakasta tiiviissä yhteistyössä. Taustalla ovat toimivat prosessit ja standardoidut peruspalvelut. Niitä osataan käyttää hyvin joustavasti.
  5. Liiketoimintakeskeinen. Liiketoiminta ohjaa IT:tä täysin ja IT:n tavoitteet ovat liiketoimintatavoitteita.

Tässä mallissa palvelukeskeisyyden ja asiakaskeskeisyyden välillä on merkittävä kynnys. Alemmilla tasoilla IT päättää ja asiakas saa mitä IT toimittaa, ylemmillä tasoilla vastuu on siirtynyt asiakkaille. Kyse ei ole siis pelkästään IT:n kypsyydestä, vaan myös asiakkaan on kypsyttävä tähän rooliin.

Tämän pohjalta yritin kuvata tilanteita, joissa kukin taso olisi saavutettu.

 
a) Teknologia on hallussa. IT laitteet ja järjestelmät toimivat ja mahdolliset vikatilanteet kyetään korjaamaan.
b) Prosessit toimivat tehokkaasti. Kaikki häiriöt, ongelmat, muutokset jne. kirjataan. Häiriöiden ratkaisuajat tiedetään ja muutosten riskit osataan arvioida.
c) Palvelut pelaavat. Osataan tuottaa pitkälle standardoituja IT palveluja asiakkaan tilausten mukaan. Muutosten vaikutukset tunnetaan ja palvelujen laatu on hallinnassa.
d) Asiakas määrää. Asiakas ohjaa toimintaa ja päättää mitä IT palveluja tuotetaan. IT-organisaatio kykenee mukautumaan joustavasti muuttuviin tarpeisiin.
e) Liiketoiminta ohjaa.  IT on sulautunut liiketoimintaan ja sitä johdetaan liiketoiminnan näkökulmasta. IT pystyy luomaan uusia mahdollisuuksia liiketoiminnalle. 

Pyysin kertomaan miten hyvin vastaajan organisaation nykyinen tila vastaa näitä kuvauksia asteikolla: 1 -5. 1 ei lainkaan, 2 vain vähäisesti, 3 osittain, 4 aika hyvin ja 5 täydellisesti.

Lisäksi pyysin vielä kertomaan mikä näistä kuvauksista vastaa nykyistä tilaa ja mikä on tavoitteena. Tämä kysymys oli ilmeisesti vaikeasti muotoiltu, sillä n. kolmasosa jätti vastaamatta siihen tai vastasi väärin. Oikea vastaus olisi siis ollut jokin kirjain, esim. nyt A ja tavoitteena B. Näin muuten ei yksikään vastannut, vaikka se olisi oikea vaihtoehto aika monelle.

Valtaosassa vastauksissa oltiin tasoilla 4 tai 3 eli aika hyvin tai osittain. Ainoastaan teknologia -tasolla löytyi merkittävä määrä täydellisesti -vastauksia.

Kynnys palvelu- ja asiakastasojen välillä näkyy selvästi, vain alle 20 % arvioi olevansa niillä tasoilla.

Oman tason ja tavoitetason välillä on mielenkiintoinen korrelaatio. Jos omaksi tasoksi arvioitiin teknologia, tavoittetasona oli yleensä palvelu. Jos taas oma taso oli jokin muu, tavoitteeksi tuli asiakas- tai liiketoimintakeskeisyys.

Tein oman tulkinnan kypsyystasoista vastausten perusteella.

Jos vastaaja oli jonkun kypsyystason kuvaavan täydellisesti, hyväksyin sen. Jos vastaaja ei sanonut yhdenkään tason toteutuvan täydellisesti, mutta sanoi useamman toteutuvan aika hyvin, valitsin näistä toiseksi ylimmän. Näin laskin jokaiselle vastaajalle tämän hetken kypsyystason. Periaatteena oli, että alempien kypsyystasojen täytyy toteutua eli kypsyystasoarvioiden piti pysyä samana tai pudota.

Oman tulkintani mukaan vajaa puolet jäi tasolle nolla, eli teknologia ei ole täysin hallussa. Vajaa neljännes on saavuttanut sen tason. Joka viidennes on saavuttanut prosessitason ja yksi kymmenestä palvelutason. Yksi henkilö vastasi 5 joka tasolle.

Johtopäätökset

Tulos on mielenkiintoinen monella tavalla. Tämän mukaan noin puolet it-yksiköistä ei ole päässyt yli teknologiakeskeisyydestä. Mielestäni monet havainnot tukevat tätä tulkintaa.

Teknologian hallinnan tasolle on päässyt joka neljäs ja heillä on edellytykset saada prosessit toimimaan. Joka viides on prosessitasolla ja joka kymmenes päässyt yli seuraavan kynnyksen. ITIL termein 20 % on V2-tasolla ja 10 % V3-tasolla ja lähes 70 % ei ole vielä saavuttanut ITIL V2 -tasoa.

Näyttää siltä että tasoeroja ei tunnisteta. Prosessikeskeisyys ei ole sama asia kuin palvelukeskeisyys. Tämä on mielestäni ITILin kolmosversion ongelma, siitä ei käy ilmi että se kuvaa kaksi kypsyystasoa ikään kuin yhdessä. Asiakaskeskeisyyden haaste sen sijaan tunnistetaan ja valtaosa vastaajista näkee että sinne on vielä matkaa.

Tavoitteiden asetanta on vielä optimistista. Realistinen tavoite on seuraava kypsyystaso. Liiketoimintakeskeisyys tuntuu houkuttelevalta, mutta silloin tosiaankin it:n toimivuutta mitataan samalla tavalla kuin itse liiketoimintaa, siis myyntinä, kannattavuutena jne.

Jokaisen it-yksikön pitäisi tunnistaa oma kypsyystasonsa ja ulkopuolinen tarkkailija voi olla avuksi tässä. Sitten on arvioitava mikä on tarvittava kypsyys ja sen määrää asiakkaan tila. Ei ole lainkaan selvää, että liiketoimintakeskeinen kypsyystaso on oikea tavoite kaikille. Se edellyttää että it:llä on aidosti merkittävä rooli liiketoiminnassa ja näin ei ole läheskään kaikilla aloilla.

Asiakaskeskeisyys edellyttää että asiakas on halukas ottamaan merkittävän roolin it:n ohjaamisessa. Näin ei suinkaan ole aina. Palvelukeskeisyys luo myös raja-aidan asiakkaan ja palveluorganisaation välille, kuten jokainen palvelun ulkoistanut on varmasti havainnut. Voi myös pohtia riittääkö teknologian hyvä hallinta joissakin tapauksissa eli tarvitsevatko kaikki prosesseja?

Oma kypsyystaso määrittää sen, mitä pitää kehittää ja miten palvelua voi mitata. Esimerkiksi prosessien käyttöönotto takeltelee, jos ollaan edelleen vaikeuksissa teknologian kanssa. Palvelujen tason mittaaminen on vaikeaa, jos prosessit eivät toimi jne. Johtamisen täytyy myös olla vastaavalla kypsyystasolla. Kaikki tämä on helpompi sanoa kuin tehdä.

20 miljonaa käyttäjää, 50.000 tukipyyntöä kuukaudessa ja 10 henkeä tuessa.

Vanhassa maailmassa yritys osti tietokoneen ja palkkasi ihmisiä hoitamaan ja ohjelmoimaan sitä. Kun koneiden ja niitä hoitavien ihmisten määrä kasvoi, tarvittiin prosessimalli palvelujen tuottamiseen. Syntyi ITIL,  parhaat käytännöt. Vanha maailma on toki muuttunut, enää ei käytetä reikäkortteja mutta samat vanhat periaatteet pätevät.Lähde Flickr

Uudessa maailmassa yritykset tuottavat palveluja verkossa. Yritykset ostavat toisten yritysten palveluja ja jalostavat niitä edelleen asiakkailleen. Olen yrittänyt selvittää, miten nämä uuden maailman yritykset tuottavat ja tukevat palvelujaan. Olen haastatellut kahta yritystä huhtikuussa 2012. Toinen on Automattic , jonka palvelua sinäkin käytät juuri nyt lukiessasi tätä tekstiä. Nämä sivut on tuotettu WordPress.com:in avulla, joka on Automatticin palvelu. Toinen on Flowdock, suomalainen startup, joka on juuri saanut ensimmäisen kansainvälisen rahoituksen.

Automattic on hauska yritys, sillä on 108 työntekijää 24 maassa ja 26 USAn osavaltiossa, mukana yksi suomalainenkin, Systems Wrangler Pyry Hakulinen. Toimitusjohtajan titteli on Band Manager, perustajan titteli taas on CBBQT, Chief BBQ Taste Tester.  Asiakastuen henkilöstön tittelinä on samaan tyyliin Happiness Engineer. Haastateltavana oli Happiness Engineer Andrew Spittle, joka toimii tiimin vetäjänä. WordPress on heidän suurin palvelunsa, jolla on yli 20 miljoonaa käyttäjää maailmassa.

Automattic perustettiin 2005, aloin itse käyttää WP:tä 2008. Palvelu on laaja ja monipuolinen, eikä maksa paljoa, vuosimaksu mainosten poistamisesta on 30 $. WP:n tuki on erinomainen, minulla on ollut pari pulmaa ja niihin on tullut vastaus hämmästyttävän nopeasti. Olen myös saanut läpi yhden pienen muutoksen, ehdotin että teksti : ”ei kommenteja” vaihdettaisiin tekstiksi ”jätä kommentti”. En tosin tiedä tehtiinkö muutos juuri minun pyyntöni seurauksena, mutta joka tapauksessa se tehtiin pian sen jälkeen kun olin pyynnön esittänyt.  Haastatteluni sain myös esittämällä pyynnön tukipyyntölomakkeen kautta. Alustava kielteinen vastaus tuli aika nopeasti, mutta sitten se pienen harkinnan jälkeen vaihtui myönteiseksi. Aiemmin kotisivuni tuotti Nodeta Oy, jonka vetäjä on poikani Mikael Roos. Flowdock syntyi Nodetan suojissa, linkin takana yrityksen tarinaa. Löysin WordPressin itse asiassa poikani neuvoilla, kun hän kyllästyi kotisivujeni väkertämiseen.

Seuraavassa joitakin havaintoja molemmista haastatteluista.

Molemmissa tapauksissa yhteydenotto tapahtuu suoraan itse tuotteen kautta. WP:n tuen lähestyminen on helppoa ja siksi tukipyyntöjä tulee lähes 50.000 kuukaudessa. Puolet näistä hoitavat WP:n julkiset foorumit, joissa tukea tarjoavat toiset käyttäjät. Tässä pyynnöllä tarkoitetaan uuden keskustelun avausta. Vanhoista keskusteluista myös varmasti löytyy apu suurelle joukolle, mutta sitä ei rekisteröidä. Varsinaisia tukipyyntöjä tulee 24.000 kuukaudessa ja niitä käsittelee 10 henkeä ympäri maailmaa. Lisäksi tukiryhmä seuraa foorumien keskusteluja ja puuttuu niihin tarvittaessa. Flowdock ei halua julkaista volyymejään ollessaan herkässä kasvuvaiheessa, mutta tuhansia yhteydenottoja alkoi tulla kun tuote löysi markkinansa ja niitä tulee jatkuvasti.

Kirjausvälinettä ei käytetä, vaan tiketit kirjautuvat omaan tuotteeseen. Osaa Flowdockin ”tiketeistä” voi seurata Twitterissä. WordPressillä on taas useita blogeja, joissa käsitellään pulmia ja ehdotuksia.

Molemmat päivittävät tuotettaan huimaa tahtia. WordPressillä on menossa n. 40.000 versio ja päivässä julkaistaan n. 16 uutta päivitystä. Flowdock tekee samoin useita päivityksiä joka päivä. Käyttäjien todelliset pulmat ratkotaan minuuteissa. Flowdockin muutoksista keskustellaan chatissa, WordPressin taas blogeissa. WordPressin henkilöstö toimii hyvin itsenäisesti, jos joku haluaa tehdä jotain niin saa tehdä, omaan harkintakykyyn luotetaan.

Kumpikaan ei sovella ITILiä. Kommentit ovat tiukkoja: ”Emme halua käyttää jäykkiä frameworkkeja.” ”Meillä ei ole prosesseihin prosessin vuoksi”. ”Emme käytä prosessia, koska se on prosessi”. ”Meillä ei ole hierarkiaa tai eskalointia.” Tässä tulee mieleen TietoTapiolan Timo Hyvösen kommentti ITILin käyttöönotosta: ”Koko organisaatio ei varmasti ole koskaan samaa mieltä muutosten tarpeellisuudesta, mutta siksi organisaatiot ovat hierarkisia. ”

Niin, kummassa haluaisit olla töissä tai asiakkaana. Tiukassa, kurinalaisessa prosessiorganisaatiossa, jossa marssitaan johdon komentamana ITILin tahdissa, vai nopeassa, joustavassa organisaatiossa, joka luottaa yksilöihin?

Pohjoismainen malli ja parhaat käytännöt

Helsingin Sanomat kertoi aamun lehdessä että ruotsalaiset demarit ovat rekisteröineet pohjoismaisen mallin. Kirjoittaja kritisoi toimenpidettä: Pohjoismainen malli on aina muuttunut ja muuttuu koko ajan. Sen sisältö saa eri muotoja ajankohdan ja maan mukaan. Mielestäni tämä osuu myös ITILin ytimeen. It-palvelunhallinta muuttuu ja kehittyy koko ajan. ITIL-kirjat esittävät yhden näkemyksen yhdestä vaiheesta.

Merkkisuojahanke todistaa, että puolue elää liiaksi menneisyydessä eikä pysty tarjoamaan yhteiskuntapoliittista ohjelmaa tulevasta. Historiasta voi oppia, mutta sitä ei kannata patentoida eikä siinä ole syytä elää. Sama sopii hyvin ITILiin. ITIL on historiaa, siihen ei pidä takertua.

It-palvelunhallinnalla on edessä joukko suuria haasteita, tässä joitakin:

1) Teknologia kypsyy kovaa vauhtia, kuluttajille suunnatut laitteet ovat vaivattomia ja helppoja käyttää.

2) Pilvipalvelut laskevat palvelutuotannon hinnan sietämättömän halvaksi.

3) Asiakkaat pystyvät tekemään itse asioita, joihin ennen tarvittiin ammattilainen.

Perinteinen it-yksikkö toimi kuin sosialistinen diktatuuri. Viisivuotissuunnitelmat ohjasivat toimintaa ja ylhäältä kerrottiin massoille, minkä harmaan sävyisellä laatikolla tehdään töitä seuraavat kolme vuotta. Nyt rautaesirippu on murtunut ja vapaus voittaa. Keskitetty ohjaus romahtaa ja asiakkaat saavat valita itse mitä tekevät. Vapaudella on toki kääntöpuolensa ja ongelmia tulee. Niiden liioittelu ei kuitenkaan estä muutosta.

Nyt pitää olla ketterä ja aktiivinen. On autettava asiakkaita löytämään uusia mahdollisuuksia, on mentävä lähemmäs liiketoimintaa ja kyettävä luomaan todellista hyötyä. Mikään it:ssä ei omaa itsearvoa, mutta tähän harhaan on helppoa erehtyä, jos elää suljetussa konesalissa. Voi toki perustella järjestelmän viilaamista asiakkaan hyödyllä, mutta entä jos asiakkaan kannalta olisikin parempi romuttaa koko järjestelmä. Tätä ei voi nähdä, jos elää järjestelmän sisällä ja katselee asiakkaita etäältä.

Tämä ei ole sanahelinää. Tämä on tekemistä. Et varmaan voi tehdä kaikkia näitä asioita, mutta voit varmasti tehdä jonkun näistä:

  • Opiskele uusia laitteita ja palveluja, anna niitä asiakkaille, ideoi heidän kanssaan käyttökohteita vaikka iPadille.
  • Onhan sinulla jo ilmainen serveri pilvessä?
  • Jos asiakkailla on kotona heidän mielestään paremmat laitteet, kytke ne firman verkkoon ja junaile tuki.
  • Tutustu verkon palveluihin, jos CRM on jäykkä kokeile verkkovaihtoehtoa http://www.webcrm.com/fi/. Ontuuko dokumentinhallinta, voisiko http://www.sopima.fi/ pitää edes sopimukset järjestyksessä, jne.
  • Muista että tehtäväsi ei ole pyörittää nykyisiä järjestelmiä tehokkaasti, vaan auttaa liiketoimintaa parempaan tulokseen. Miten voit tehdä sen, jos et ymmärrä mitä he tekevät. Älä haaveile tulevasi paremmaksi Active Directory -asiantuntijaksi, vaan haaveile miten tulet paremmaksi toimialasi asiantuntijaksi. Miten voisit oppia tänään jotain uutta asiakkaistasi?
  • Osaathan Facebookin, Twitterin Google+, LinkedIn’in jne. Kai tiedät miten FaceBookia käytetään vaikka Service Deskin tukisivuina.

Monet ovat jo varmasti tehneet näitä asioita, nyt pitäisi alkaa kerätä kokemuksia ja vertailla käytäntöjä. Sillä tavalla syntyy uusia parhaita käytäntöjä. Niitä vain ei sitten opeteta sertifiointikursseilla.

Yhteydenhallinta

Tässä pikatutkimuksessa selvitin yhteydenhallinnan välineitä. Lomake lähetettiin ensin koko jakelulistalle, sitten muistutus Service Desk -listalle.

Tämä kysely koskee asiakastuen, service deskin tai yhteyskeskuksen työkaluja. Olen kiinnostunut kaikista asiakkaiden kommunikointiin liittyvistä työkaluista, kuten puhelimen jonotus, esivalinnat, sähköpostien hallinta ja muut yhteydenhallinnan välineet.  Jokaisen työkalun kohdalla haluaisin tietää onko teillä sellainen työkalu, minkä niminen se on ja miten se toimii asteikolla: 3 suosittelen, 2 suosittelen varauksella, 1 en suosittele.  Jos teillä ei ole kyseistä välinettä, merkitse vain ”ei” riville. Jos teillä on, kirjoita työkalun (tuotteen) nimi ja arvosana 3-1 edellä mainitun asteikon mukaisesti.  Kaikki vastaukset ovat luottamuksellisia, enkä mainitse vastaajien tai heidän edustamiensa yritysten nimiä missään. Vastaa tähän sähköpostiin. Kaikki vastaajat saavat raportin tuloksista.

 1 Puheentunnistus koneellisesti (puheohjaus)

2 Valikko-ohjaus (valitse yksi jos asiasi koskee…)

3 Jonotus (ACD)

4 Sähköpostien hallinta

5 Integroitu jonotus, jossa eri kanavat kuten puhelu, sähköposti näkyvät samassa jonossa.

6 Pikaviesti (chat tms)

7 Asiakkailla mahdollista avata tikettejä itse

8 Muu yhteydenhallinnan työkalu

Kysymykset 1 ja 3 aiheuttivat jonkin verran hämmenystä. Puheohjaus oli vieras termi ja jonotus taas ehkä liian arkipäiväistä. Siksi vastaajia pyydettiin vielä tarkistamaan ja täydentämään vastaukset epäselvyyksien välttämiseksi.

Yleisin yhteydenhallinnan työkalu on asiakkaiden mahdollisuus avata tikettejä itse. Seuraava on jonotusjärjestelmä(Automatic Call Distributor ACD). Myös pikaviestit ovat käytössä yli 50% vastaajista. Koneellinen puheentunnistus on harvinaista, samoin integroitu jonotus.

Kaikkein tyytyväisimpiä ollaan ryhmään muu, siellä on erilaisia omia ratkaisuja. Valikko-ohjaus ja sähköpostien hallinta ovat myös suositeltuja ratkaisuja. Vähiten suositteluja saavat asiakkaan mahdollisuus avata itse tikettejä, integroitu jonotus ja puheohjaus.

 

 

Tämän enempää en julkaise tuloksia. Tutkimukseen 25.11. mennessä vastanneet saavat täyden raportin, jossa kerrotaan myös käytetyt tuotteet.

 

%d bloggers like this: