Palvelua käyttäjille eikä tekniikkaa tietohallinnolle

IT-markkina on kulkenut vääjäämättömästi kohti palveluliiketoimintaa, käyttäjälähtöisyyttä ja kokonaisvastuullista toimittajuutta, vaikka kehitys on usein ollut toivomaani hitaampaa. Olemme päässeet sentään jo tilanteeseen, jossa harva yritys haluaa esimerkiksi omistaa omat palvelimensa ja verkkolaitteensa. Enkä muista pitkään aikaan nähneeni asiakasta, jonka tavoitteena ei olisi kokonaisten ostamiensa palveluiden mittaaminen järjestelmäkomponenttien valvonnan sijaan.

Ehkä haastavinta kehitys on kuitenkin ollut loppukäyttäjille tarjottavissa palveluissa. He kun eivät itse istu neuvottelupöydässä ja koska heidän käyttämiensä palveluiden toimivuus ei näy kokonaisten liiketoimintaprosessien mittareissa suoraan ja välittömästi. Niinpä onkin vaikeampaa havaita liiketoimintahyöty, jonka hyvin toimiva loppukäyttäjäpalvelu luo. Hyvin toimivien työvälineiden taloudellisen vaikutuksen pitäisi kuitenkin olla itsestään selvää. Ensinnäkin varsinaista työtä pitää voida tehdä koko työaika ja toisekseen työn pitää edetä tehokkaasti.

Kurkkupastilliaskin kanteen laskettuna esimerkiksi 1 000 hengen organisaatiossa voidaan saavuttaa seuraavasti yli 100 000 € kuukausittaiset säästöt.

Taulukko

Laskelmassa oletetaan helppari-puhelulla ratkeavan ongelman hukkaavan 15 minuuttia ja laajempaa selvitystä vaativan ongelman 4 tuntia työaikaa, sekä keskimääräisen henkilöstökulun olevan noin 7 000 € kuukaudessa. Lähtötilassa organisaatiossa on korkea 1,4 tikettiä käyttäjää kohti kuukaudessa ja vain 50 % ongelmista ratkeaa ensimmäisellä helppari-puhelun aikana. Tavoitetilassa taas häiriöiden määrä on puolitettu ja ensimmäisen kontaktin ratkaisuaste nostettu 30 %-yksiköllä hyvälle tasolle.

Vastaavat laskelmat on mahdollista tehdä myös yleisesti henkilöstön vaihtuvuudesta syntyvistä kustannuksista, kun huomioidaan paljonko esimiehet, HR ja pääkäyttäjät tekevät tunnuksien avauksia ja sulkemisia, sekä kuinka pitkään näitä joudutaan pahimmillaan odottamaan. Pääsevätkö esimerkiksi konsultit heti ensimmäisestä tunnista varsinaiseen työhön kiinni? Vähän tapauskohtaisemmin taas voidaan laskea työn mobiliteetin lisääntymisestä sekä muusta työtapojen ja –menetelmien uudelleen järjestelystä syntyvät edut.

Palvelun arvon hahmottaminen ei kuitenkaan vielä kerro, millaista palvelua tarvitaan. Nämäkin laskelmat keskittyivät lähinnä tukeen, eivätkä siihen, millaista ympäristöä ollaan tukemassa. On olemassa kuitenkin muutama lähestymistapa, jolla asiassa päästään eteenpäin.

Ensinnäkin loppukäyttäjäpalveluita määriteltäessä pitää lähteä ylhäältä alaspäin – miettiä mitä työtehtäviä käyttäjien pitää suorittaa ja mitä sovelluksia näiden tehtävien suorittaminen vaatii. Samalla voidaan listata myös miten kutakin sovellusta halutaan käyttää eli onko käyttö täysin mobiilia vai riittääkö joidenkin kohdalla toimivuus konttoriympäristössä. Tämän jälkeen voidaan loikata miettimään fyysisten laitteiden tasoa eli puhelin, tabletti ja tietokonevalikoimaa, joiden halutaan olevan käyttäjien valittavissa.

Entä sitten palvelimet ja verkko? Optimitilanteessa asiakkaan ei tarvitse näitä edes miettiä, sillä hänhän on juuri määritellyt kokonaisuudessaan miltä halutun varsinaisen palvelun tulee näyttää. Toimittajan tehtäväksi jää tämän jälkeen rakentaa ehdotus, jossa hyödynnetään oikeaa infraa blade-kehikoista pilveen ja palomuurista työpöytävirtualisointiin, sekä esittää tämä asiakkaalle kattavina palvelukuvauksina ja hinnoittelumallina, joka sisältää kaiken tarvittavan. Onko olemassa yhtään todellista syytä, ettei loppukäyttäjälle saisi kaikkea palvelua yksinkertaisella €/kk –hinnalla?

Näin hankittu toimiva palvelu tuottaa lisäksi myös selvän edun toimittaja-asiakas-suhteen rajapintaan asiakkaan puolelle oli kyse sitten hankinta- tai ict-organisaatiosta. Toimittaja- ja palvelumäärää on mahdollista pienentää ja jäljelle jäävien toimittajienkin kanssa tehtävä työ on yksinkertaisempaa ja helpompaa kun liikkuvia osia on vähemmän.

Jaa tämä artikkeli:

Jaa Facebookissa Jaa Twitterissä Jaa Google+:ssa Jaa Pintrestissä Jaa LinkedIn:issä
Julkaistu kohteessa IT-ammattilaiset, IT-päättäjät, Palvelut, Työn tuottavuus, Visio, Yleinen Merkitty: , , , ,
2 comments on “Palvelua käyttäjille eikä tekniikkaa tietohallinnolle
  1. 18.12.2014 klo 10:16 . sanoi:

    Ei näin!

    ”Ensinnäkin loppukäyttäjäpalveluita määriteltäessä pitää lähteä ylhäältä alaspäin ”
    Tämä on täysin paskapuhetta, käykää kysymässä joskus ”alhaalla” että ”Kuinka voisitte tuottaa meille enemmän rahaa?”
    Suurin osa työntekijöistä voisi tehdä paljon enemmän kuin kategorisoitte heidän pystyvän. ”Ylhäältä alas” -johtaminen on täysin tehotonta ja voimavaroja haaskaavaa, se haaskaa ihmisten intohimoja ja oikeita kykyjä.
    Työntekijät eivät ole kuluja vaan voimavaroja. Säästämällä koneissa, puhelimissa ym. työvälineissä, saatte kasan vihaisia työntekijöitä jotka turhautuvat ja viimekädessä vaihtavat firmaa.
    Työvälineet ovat edullinen investointi firmalle, laskekaa mielummin paljonko ihmiset voisivat tuottaa.
    Se että käytetään esim. 5 vuotta vanhaa rautaromua työntekoon ei palvele ketään.

    • Topias Uotila
      18.12.2014 klo 10:58 Topias Uotila sanoi:

      Terve!

      Nyt on tainnut valitettavasti käydä siten, että olen ollut epäselvä ja on sattunut väärinymmärrys!

      En missään nimessä tarkoita ”ylhäältä alaspäin lähtemisellä” johtamismallia, vaan sitä, missä järjestyksessä teknologiakerroksia tulee tarkastella. Eli ensin pitää esimerkiksi juuri käyttäjien kanssa miettiä, mitä he tarvitsevat työnsä tekemiseen mahdollisimman sujuvasti. Näin saadaan vaatimuksia sovelluksille ja niiden käyttötavalle. Näiden perusteella voidaan sitten määrittää millaista teknologiaa tarvitaan vaatimusten täyttämiseen ja edelleen esimerkiksi millaisilla palvelimilla ja verkoilla tämä toteutetaan.

      Juurikin toisin päin eteneminen johtaa helposti siihen, että hankitaan kustannustehokkaan oloinen infrapalvelu, joka ei kuitenkaan vastaa työntekijöiden tarpeisiin.

      Topias

Kommentoi

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

*

Time limit is exhausted. Please reload CAPTCHA.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>