Blogi

Tarinoita ja oppia palvelujohtamisen ja projektijohtamisen asiantuntijoille

IT-palvelujohtaminen

Palveluiden määrittämisen vaikeudesta

Miksi IT-palveluiden kuluttajaorganisaatioiden IT epäonnistuu palveluidensa järkevässä määrittämisessä?

Palvelun käsitteen määrittäminen on organisaation IT-palvelunhallinnan onnistumisen kannalta tärkein yksittäinen tekijä. IT-palvelunhallinnan kaikki tekeminen kohdistuu palveluun. Jos palvelu on määritelty epämääräisesti, sen tuottaminenkin on vaikeaa. Tämän blogin pääidea on auttaa IT-palvelujen kuluttajaorganisaatioiden sisäistä IT:tä määrittämään liiketoiminnalle tarjoamansa palvelut paremmin.

Aloitetaanpa itse sanasta palvelu

Palvelu on suomessa substantiivi eli olevassa oleva määritelty tekijä. Englanniksi sana Service on sekä substantiivi että verbi. Palvelun tuottaminen on tekemistä, mutta palvelu tuottaa lopputuloksen, jonka asiakas saa. Mielestäni oikea näkökulma (ja ITILinkin) on keskittyä siihen mitä asiakas saa eikä siihen liittyvään tekemiseen, josta oma äiti on ylpeä.

Keskity siihen mitä asiakas saa, älä siihen, mistä oma äiti olisi ylpeä.

ITILissä palvelu on määritelty olemaan ”Arvon tuottamista asiakkaille tuottamalla (/auttamalla asiakkaita saavuttamaan) lopputuloksia ilman niihin liittyviä (suoria) kustannuksia ja riskejä.” Fokus on siis asiakkaan saamassa lopputuloksessa ja sen hyödyllisyydessä, ei sen tuottamiseen tarvittavissa toimenpiteissä.

ITILissä puhutaan palvelumallista (Service Model), joka määrittää minkälaisia ominaisuuksia ja hallittavia osia palvelulla organisaation määritelmän mukaan on ja miten ne liittyvät toisiinsa. Tärkein kysymys on mikä organisaation näkemyksen mukaan erottaa kaksi palvelua toisistaan omiksi palveluikseen. 95% tuotettavasta kokonaisuudesta löytyy yleensä helppo vastaus. Viimeisen 5% osalta pitää tehdä hallinnollinen päätös ja siinä päätöksessä hyvä ohjenuora on miettiä elinkaarta ja loppukäyttäjän näkökulmaa. Koska vaikeita tapauksia ei ole kuin muutama, päätös kannattaa nuijia kasaan joko valistuneella diktatuurilla tai viime kädessä arvalla. Tärkeintä on saada palveluportfolio sovittua, jotta ei jäädä pyörimään arvoa tuottamattomasti paikalleen.  

Oman näkemykseni mukaan jokaisella palvelulla on noin seuraavat ominaisuudet:

  • Elinkaari: Hallittavalla kokonaisuudella on oma käyttöönottamisaikansa ja toisaalta se voidaan poistaa käytöstä itsenäisenä kokonaisuutena. Tässä määritelmä voi olla hallinnollinen, toiminnallinen tai jopa tekninen.
  • Käyttäjät: joku määritelty käyttäjäjoukko käyttää palvelua.
  • Hallintamalli ja organisaatio: Palvelulle on rooleilla määritelty sen hallinnan kannalta olennaiset roolit ja niihin henkilöt/funktiot: Omistaja, päällikkö, pääkäyttäjät/käyttäjien opastus, tekniikan osaaja/ylläpitäjä, muutoksenhallinnan pyörittäjä, muutoksien rakentaja, jne
  • Oma infrastruktuuri: Tämä voi olla jossain määrin hallinnallista jakoa aiheuttava tekijä. Tästä näkökulmasta voi myös lähteä katsomaan mitä organisaatiossa tuotetaan. Infrastruktuurin mallintamisen taso riippuu palveluntuottajan tarpeista.
  • Hinnoittelu/lasku: Palvelun käytöstä voidaan laskuttaa. Asiakokonaisuudet joista asiakasta laskutetaan voi olla palvelua määrittävä tekijä.

Eri tyyppisillä palveluntuottajilla on erilainen näkökulma mitä palvelu on. IT-palvelujen kuluttaja-organisaatioissa (joissa business on muuta kuin IT-palveluja) liiketoiminta tarvitsee liiketoimintasovelluksia ohjaamaan liiketoiminnan prosessejaan ja resurssejaan. Loppukäyttäjät tarvitsevat henkilökohtaiset IT-palvelut kuten työaseman, sähköpostin, AD-tunnuksen ja kännykän puhelinliittymineen liiketoimintaprosessien suorittamiseksi ja liiketoimintasovellusten käyttämiseksi. Nämä kaikki ovat kokonaisuuksia, jotka tuottavat liiketoimintaa mahdollistavan lopputuloksen sellaisina kokonaisuuksina, joina käyttäjät ja liiketoiminta näkevät ja toisaalta minkälaisina kokonaisuuksina niitä tuottavat haluavat niitä hallinnoida. Lisäksi IT:n pitää tuottaa ja hallita joitakin edellä mainittujen palveluiden tuottamista mahdollistavia teknisiä IT-palveluita kuten lähiverkkoa, WAN-yhteyksiä, palvelinkapasiteettia jne.

Maailma on erilainen ulkopuolisen palveluntuottajan silmin

Kaupalliset IT-palvelun tuottajat ovat palveluinensa kauempana asiakkaan liiketoiminnasta. Koska IT-palveluiden kuluttajan roolissa oleva, jotain muuta tarkoituksenaan tekevä liiketoiminta tarvitsee prosesseihinsa liittyviä kokonaisuutena toimivia ratkaisuja, IT-palveluntuottajien palvelut ovat asiakkaalle joko osaratkaisuja tai pelkkää työtä eri muodoissa. Tiedän, että tässä kohtaa useampi palveluntuottajan edustaja nikottelee ja kokee ylpeyttään loukatun, mutta pidättäydyn tässä blogissa asiakkaan organisaation näkökulmassa: toimiva palvelu tarvitsee toimiakseen muutakin kuin sen mitä jonkun ulkopuolisen toimittajan kanssa palvelun toimittamisesta on sovittu.

Palveluntuottajat myyvät parhaimmillaan melko suuria palvelukokonaisuuksia, kuten matkapuhelinliittymien toimittamista ja hallintaa. Usein toimitettu palvelu heillä on työtä eri muodoissa: Service Deskin työtä, muutoksenhallintatyötä, sovelluskehitystä. Nämä ovat palvelua, mutta eivät sitä palvelua, jota IT-palveluita kuluttavan organisaation liiketoiminta saa. Ne ovat palvelun muodossa olevaa työtä sisäiselle IT:lle sen omalle liiketoiminnalleen tuottamien palveluiden mahdollistamiseksi. 

Mikä palveluiden määrittämisessä sitten on ongelmana?

Kun sisäinen IT laatii palveluportfolion, jossa on palveluita tekemistä/prosesseja niin sen fokus on usein omassa työsuorituksessa eikä siinä, mitä liiketoiminta saa. Palvelut sekoitetaan palvelukategorioihin, jotka ovat palveluiden ryhmittelyä ilman omia aiemmin luetteloiminani palvelun määrittäviä ominaisuuksia. Prosessit ovat tapa hallita ja tuottaa palvelua, eivät palvelu itsessään.

Funktiot (organisaation osat, jotka ovat keskittyneet tekemään tietyntyyppistä työtä) ovat tapa organisoida osaamista ja sen kehittymistä, eivät palvelua itsessään. Palveluiden tulisi olla organisaatiorakenneriippumattomia: Organisaation muuttuessa liiketoiminnan saamien palveluiden ei pitäisi muuttua organisaatiomuutoksen takia. 

Kun palvelun määritelmä jätetään määrittämättä, seuraa eri luonteisten ja tasojen asioiden rinnastamisesta toisiinsa. Tästä seuraa puolestaan on palveluiden ei-niin-iloinen sekamelska, jonka päälle harmonisoidun palvelumallin (mistä palvelu koostuu) ja palvelutuotantomallin (ITILin Service Provision Model, miten palvelua tuotetaan organisaatiossa) luominen on mahdotonta. IT-palvelunhallinnan arkkitehtuuri lähtee hakoteille heti alusta asti ja lopputulokseen ovat tyytymättömiä sekä liiketoiminta että IT itse.

Palvelumallin voi luoda fiksusti ja palveluarkkitehtuurin luoda toimivaksi. Tästä meillä on asiakasreferenssejäkin. Tervetuloa kuulemaan lisää näkemyksiä palveluihin ja palvelunhallintaan liittyen:

WEBINAARI: Service Asset and Configuration Management – Experiences from implementation 13.10.2017 klo 10-11.

Suomeksi jälkitallenteena: Palveluomaisuuden- ja konfiguraationhallinta – Toteuttamisen kokemuksia 

 CMDB® Foundation -koulutus 23. – 25.10.2017 Helsingissä. 

aaeaaqaaaaaaaal8aaaajdjimgq0nzmxltewn2utngi1yi05ndm2lwu0ngixmzm2mdyyna

Lari Peltoniemi


Kirjoittaja on työskennellyt prosessien ja toiminnan kehittämisen ja arvioinnin alueella yli 10 vuotta. Päätoimisesti IT-palveluiden prosessien määrittelyn, kehittämisen ja johtamisen alueella hän on toiminut vuodesta 2005. Hän on konsultoinut ja valmentanut useita suomalaisia ja kansainvälisiä yrityksiä ja organisaatioita ITIL/ITSM prosessien määrittelyihin, käyttöönottoon ja kehittämiseen liittyen. Lari on myös Suomen ensimmäinen sertifioitu ITIL Practitioner -kouluttaja. 

 

Comments are Closed