IT4IT – Palveluiden selkäranka käytännössä (osa 1)

IT4IT:n mukaan “palvelun selkäranka” (Service Model Backbone) kuvaa palvelun eri muodot ja vaiheet palvelukonseptista käyttöönotetuksi palveluksi. Selkäranka sisältää seitsemän eri näkökulmaa palvelun sisältöön, mutta ne oikein tarkoittavat ja miksi niitä ylipäätään on niin monta?

Tässä artikkelissa käsitellään kolmea ensimmäistä näkökulmaa (data objektia) ja niiden paikkaa käytännön palvelusuunnittelussa. Nämä kolme vapaasti suomennettuna ovat Palvelukonsepti (Conceptual service), Konseptuaalinen palvelumalli (Conceptual service blueprint) ja Looginen palvelumalli (Logical service blueprint).

Palvelukonsepti ja konseptuaalinen palvelumalli

Minua ainakin hämäävät nämä englanninkieliset sekä niistä suomennetut termit, jotka toisinaan saavat asiat kuulostamaan niin hienoilta ja monimutkaisilta. Palvelukonsepti voidaan kuitenkin ymmärtää hyvin yksinkertaisesti lyhyeksi ylätason kuvaukseksi tulevasta tai jo olemassa olevasta IT palvelusta liiketoiminnan näkökulmasta. Kuvauksen tarkkuustaso ja sisältö pitäisi kohdistaa liiketoiminnan kyvykkyyksiin ja lisäarvon tuottamiseen, tarvittaviin tai jo tehtyihin ja tuleviin investointeihin sekä tulevaisuuden näkymiin. Kuvauksen EI tule sisältää teknisiä yksityiskohtia ja se tulisi olla ymmärrettävää henkilöille, jotka viime kädessä päättävät palveluun allokoidusta budjetista ja muista resurseista.

On tietysti hyvä, jos taloudelliset seikat pystytään huomioimaan alusta alkaen (kuten IT4IT tietomallissa tässä kohtaa esitetään), mutta alkuun pääsee ilmankin. Mielestäni tärkeintä on listata palvelut sekä tunnistaa niiden omistajat ja tämän hetkinen tila. Tämän jälkeen voidaan tarkentaa kuvauksia. Ja kaikki muut lisätiedot riippuvat sitten mm. IT-palveluita tuottavan organisaation koosta, kypsyysasteesta, palvelun tilasta ja palveluiden määrästä. Asettamalla palvelukonseptin kuvaamiselle liian tarkat vaatimukset, voi homma kaatua jo alkuunsa. On siis parempi aloittaa kevyesti ja lähteä muokkaamaan ja täydentämään kuvauksia tarpeiden mukaan.

On huomattavasti helpompi muokata jotain olemassa olevaa kuin synnyttää tyhjästä tarkkoja kuvauksia monille hieman epämääräisistä asioista.

On tärkeää miettiä palveluportfolion hallinta siten, että jatkuva muokkaaminen ja mukautuminen on mahdollista. Tällöin saavutetaan usein parempia tuloksia, kun kuvaukset tarkentuvat todellisten tarpeiden mukaan sen jälkeen, kun jokin versio kuvauksista on otettu käyttöön ja tietoa sekä ymmärrystä alkaa kertyä. Tähän auttaa myös se, että palvelun eri vaiheita (konseptuaalinen, looginen ja fyysinen) kuvaavat elementit ovat erotettu toisistaan. Palvelukonseptin tulisi siis keskittyä kuvaamaan mitä palvelu tuottaa ja miksi (ja kenelle). Miten palvelua tuotetaan, kuvataan sitten osana tarkempaa palvelun suunnittelua.

Yksi aloittamista helpottava tekijä on myös pilotointi tai ensimmäisen vaiheen laajuuden rajaaminen tarpeeksi pieneksi. Näin voidaan hieman pienemmällä porukalla ensin valmistella ehdotus, jota kokeillaan käytännössä. Ja sitten käytännön kokemusten avulla Palvelukonseptin sisältöä tai Palveluportfolion mallia voidaan muokata vielä ennen laajempaa käyttöönottoa. Tämä toki vaatii joustavuutta myös järjestelmältä, jossa palveluportfoliota on tarkoitus hallita.

Konseptuaalinen palvelumalli

IT4IT:n mukaan Konseptuaalinen palvelumalli lisää palvelukonseptiin tarkemman kuvauksen toimitusmallista. Tämän tulisi olla jo kattava malli eri sidosryhmistä ja kosketuspisteistä niin tietojärjestelmien kuin eri prosessienkin välillä. Malli on kuitenkin hyvää pitää vielä ylätasolla. Esimerkiksi yhdelle Powerpoint kalvolle piirretty kaaviokuva on hyvä lisäys Palvelukonseptin kuvaukseen.

Tietomallin kannalta konseptuaalinen palvelumalli siis tarkentaa palvelukonseptin kuvauksia. Mutta mitä tuo kuvaus sitten voisi sisältää? Kuvauksen kohderyhmänä ovat palveluomistajat, tärkeimmät sidosryhmät sekä arkkitehdit. Tässä muutamia esimerkkejä siitä, mitä konseptuaalinen palvelumalli voi sisältää:

• Rajapinnat muihin palveluihin/järjestelmiin
• Rajapinnat eri liiketoiminta- ja tukiprosesseihin
• Sidosryhmät: palvelun tuottajat, ostajat, toimittajat, asiakkaat jne.
• Inputs / outputs: resurssit ja tuotokset

Periaatteessa palvelukonsepti voi sisältää useita eri konseptuaalisia palvelumalleja. Tämä on järkevää esim. silloin, jos samaa ylätason palvelua tuotetaan eri asiakasryhmille eri tavoilla tai palvelusta on muuten tarjolla erilaisia variaatioita, jotka konseptimielessä kuitenkin sopivat yhden kokonaisuuden alle.

Konseptista loogiseksi palvelumalliksi

Tarkemman palvelusuunnittelun tuloksena pitäisi syntyä Looginen palvelumalli, mikä IT4IT:n mukaan on Palvelusuunnittelukomponentin hallinnoima loogisen tason kuvaus palveluportfoliossa määritellystä palvelukonseptista yhdistettynä palvelulle asetettuihin vaatimuksiin. Eräs suora lainaus IT4IT referenssiarkkitehtuurista luonnehtii loogista palvelumallia “järjestelmäkuvaukseksi” (system design). Toisaalla tätä loogista palvelumallia kutsutaan myös palvelun määrittelydokumentiksi, joka kuvaa mm. palvelun sisältämät komponentit sekä niiden väliset suhteet sekä käyttäytymisen suhteessa toisaansa ja muihin palveluihin. Kokonaisuutena loogisen palvelumallin on tarkoitus vastata kysymykseen “miten”.

IT4IT mallissa kun on monta eri tasoista palvelua kuvaavaa elementtiä, niin näistä seitsemästä juuri tämä looginen palvelumalli yhdistettynä palvelukonseptin tietoihin on mielestäni lähimpänä “palvelukuvausta”, joka riittävällä tarkkuustasolla kertoo kaiken olennaisen tuotettavasta palvelusta. Tässä nyt muutamia esimerkkejä siitä, miltä osin loogisen palvelumallin tulisi täydentää palvelukonseptia:

• Toimitusmalli (ulkoistettu, sisäistetty, jne)
• Tukimalli
• Palvelukanavat
• Tietomalli ja tietovirrat
• Palvelukomponentit ja niiden väliset riippuvuudet
• Linkitys vaatimuksiin, joihin tällä palvelulla vastataan
• Vastuutaulukko / RACI-matriisi
• Toimittajat

Tämän lisäksi palvelusuunnitelman tulisi noudattaa vallitsevaa kokonaisarkkitehtuuria, valittuja stardardeja ja politiikkoja sekä tietoturvavaatimuksia. Palvelukuvausten tekemiseen on monenlaisia malleja ja tapoja, joista Justinin palvelutuottajat kertovat mielellään lisää.

Miksi nähdä vaivaa?

Jälleen kerran voisi todeta, että palveluiden kuvaaminen voi olla vaikeaa. Ja onhan se, ainakin jos tavoitellaan täydellisiä kuvauksia ja täydellistä kattavuutta. Miksi siis kannattaa nähdä se vaiva, että IT palvelut saadaan kuvattua (edes jollain tasolla)?

Yksi ja ehkä merkittävin syy liittyy nykypäivän moni-asiakas/moni-toimittaja ympäristöihin, joissa yhden asiakasyrityksen palveluita hoitaa useampi eri toimittaja talon oman väen lisäksi. Ja luonnollisesti palvelun toimittajilla on usein samoille palveluille useita eri asiakkaita. Itsekin olen vuosien varrella ollut mukana useammassa palvelun ulkoistusprojektissa, jotka alkavat sillä, että aletaan selvittämään, että mitäs tässä nyt oikein ulkoistettiinkaan. Vanha viisaus kuitenkin sanoo, että “et voi ulkoistaa, jos et tiedä mitä sinulla on”. Ja tästä laajempi versio lisää, että “et voi ulkoistaa, jos et tiedä miten palveluita tällä hetkellä tuotetaan”.

Toisaalta, jos päätetään “sisäistää” aiemmin ulkoistettuja palveluita, on myöskin tärkeää tietää, mitä nämä ulkoistetut palvelut sisältävät ja miten niitä tuotetaan. Asiakkaat saattavat toisinaan vähän liikaakin luottaa siihen, että hommat ovat hyvin kuvattu ja hallittu siellä ulkoistuskumppanin puolella, kun sitten haluttaisiin ottaa palvelut haltuun tai siirtää ne toiselle toimittajalle.

No eivät kaikki ole ulkoistamassa palveluitaan tai jatkuvasti vaihtamassa toimittajia, joten mitä muuta hyötyä palvelukonseptien ja loogisten mallien kuvaamisesta voi olla? Nimensä mukaisesti nämä “palveluiden selkärangan” elementit muodostavat pohjan muualle toiminnalle. Miten yritys tekee investointeja, mihin kokonaisuuteen tuotetut IT-palvelut liittävät, miten yksittäiset IT-komponentit liittyvät liiketoimintaprosesseihin tai yrityksen asiakkaisiin jne? Yritykset kuitenkin ensisijaisesti haluavat kehittää omia palveluitaan, joten jos IT palveluita ei pystytä kuvaamaan tai yhdistämään liiketoiminnan palveluihin, voi olla vaikea perustella niiden ylläpitämiseen ja kehittämiseen tarvittavia resursseja.

Palvelukuvausten jälkeen

Kun palveluista on konseptuaaliset ja loogiset kuvaukset kunnossa, ne pitäisi vielä saada käyttöön sekä pystyttävä seuraamaan mitä palveluiden tuottamiseen tarvitaan ja mitä niiden kuluttamisesta syntyy. Näihin pureudetaan tarkemmin tämän artikkelisarjan seuraavissa osissa.

Yhteenveto artikkelin aiheesta on luvassa myös tämän vuotisilla Prosessipäivillä, joiden ohjelmassa puhutaan myös siitä, miten IT4IT voi auttaa palveluiden kuvaamiseen liittyvissä haasteissa.

Julkaistu 17.04.2017