Jokainen digipalveluiden ylläpitoa ostanut tai tuottanut on törmännyt termiin sla (service level agreement) eli palvelutasosopimus.
Sla on sopimuksellinen työkalu, jolla kuvataan vaadittu ylläpitopalvelun (minimi)taso. Kaikkea olisi kiva saada, mutta koska palvelu maksaa ja hyvä palvelu vielä enemmän, kompromisseja täytyy tehdä.
Toisaalta, mitä kriittisempi palvelu, sitä enemmän kuvetta ollaan valmiita kaivamaan vastineeksi hyvälle palvelulle.
Sla:t ovat usein numeraalisia määritelmiä reagointi- ja ratkaisuajoille sekä palveluajoille. Monikossa, koska eri tarpeille ja vakavuusasteille on eri tasonsa.
Jos kriittinen asiakastietojärjestelmä menee nurin juhannusaattona kello 21.00, joku hälytetään töihin vartissa ja tunnissa mylly laitetaan takaisin pystyyn. Mutta jos joku kehittäjä pyytää tunnuksia, niin riittää kun ne saa viikossa. Palvelutasosopimuksiin liittyvät usein myös sanktiot. Kun sovitussa ei pysytä, toimittaja antaa alennusta.
So far so good. Kätevää, että on joku määrämittainen tapa kertoa, mitä halutaan ja jolla sitouttaa palveluntarjoaja siihen sopimuksin ja sanktioin. Mikä voisi mennä pieleen?
1. Sanktiot eivät ole hyvää bisnestä kenellekään. Sopimukset ja sanktiot mahdollistavat töpeksivän toimittajan vastuuseen saattamisen, mutta alennukset kuukausimaksuista tai oven näyttäminen ovat laiha lohtu, kun upouusi verkkokauppa on ollut lanseerauksen jälkeen kuusi viikkoa pimeänä.
Sanktiot ovat molemmille osapuolille huonoa bisnestä, joten on aina edullisempaa saada hyvää palvelua kuin alennusta huonosta palvelusta.
2. Sitä saa, mitä mittaa. Kun mitataan reagointi- ja ratkaisuaikoja ja niiden rikkomisesta seuraa sanktio, toimittaja seisoo vaikka päällään täyttääkseen vaatimukset.
Tämä ei ole kannattavaa, sillä se automaattisesti ohjaa tekemistä tiettyyn suuntaan, joka ei ole aina järkevintä. Jos kriittinen ongelma pitää korjata vartissa, mutta kehittäjän tunnusten luonnissa saa kestää viikko, niissä kestää viikko silloinkin, kun kallis kehittäjätiimi istuu peukkujensa päällä odottaen tunnuksia. Saati sitten, että proaktiivisesti rakennettaisiin itsepalvelua tunnusten luonnille.
Kun tikettien suorittamisesta maksetaan, tikettejä kannattaa suorittaa eikä miettiä, miten tikettejä saataisiin vähemmän. Sitä saa, mitä mittaa.
palvelusta ei tee hyvää se, että se on pystyssä.
3. Piparikakkumuotilla leikatut palvelut. Digipalveluiden ylläpitoa hankkiessa olisi kiva, jos palvelut olisivat täysin erillisiä kaikista riippuvaisuuksista toisiin palveluihin, kumppaneihin ja liiketoimintayksiköihin. Harvoin näin on. Tästä huolimatta ylläpitoa usein ulkoistetaan kuin tuo olisi totuus.
Monimutkaisesta vyyhdistä kuin piparkakkumuotilla leikataan tarkkareunainen palvelu, jolle määritetään palvelukohtaiset ylläpitotarpeet. Inhimillistä! Onhan helpompi ulkoistaa joku selkeä kokonaisuus kuin hirveä himmeli.
Mutta kun verkkokaupan käyttäjä ostohousut jalassa yrittää ostaa aromipesää ja osto epäonnistuu, häntä ei kiinnosta, oliko vika SAP:ssa vai rajapinnoissa ja mikä on crm:n sla.
Ostajaa kiinnostaa vain se, onnistuuko asiointi jouhevasti vai ei. Liian harvoin ylläpitosopimuksissa tätä näkee ollenkaan huomioitavan. Palvelukohtaiset sla:t ohjaavat tuijottamaan nippeleitä ja kokonaisuus unohtuu.
Mikä avuksi? Usein kun ylläpitoa ostetaan, fokus on siinä, että ”pysyyhän tämä pystyssä”. Fokuksen pitäisi olla: ”miten tämä parhaiten palvelisi sisäisiä ja ulkoisia asiakkaita ja miten maksimoida arvontuotto?”
Jos keskeinen järjestelmä on nurin, se on huonoa palvelua. Mutta se ei tee palvelusta hyvää, että se on pystyssä. Reagoivasta vikakeskeisyydestä proaktiiviseen palvelukeskeisyyteen siirtyminen mullistaisi ylläpidon.
Tämä mullistus ei lähde vain toimittajista, vaan vaatii myös tilaajalta rohkeutta tilata ylläpitoa eri tavalla. Kustannusten minimoinnista hyötyjen maksimointiin siirtymällä viivankin alle jäisi enemmän.
Miten päästä alkuun? Slo eli service level objective on konsepti, johon kannattaa tutustua. Se vie fokusta yksittäisen palvelun vikakeskeisyydestä kokonaishyötyyn ja palvelukeskeisyyteen.