6.4

Palveluiden suunnittelu ja kehittäminen

Palveluiden kehittäminen käsittää uusien palveluiden ja kehitystoimenpiteiden esittämisen, suunnittelun ja toteuttamisen. Se saa kehitysaloitteita liiketoiminnan tarpeista, konseptien kehittämisen tuloksena, pääkäyttäjiltä tai loppukäyttäjäpalautteena. Palvelupäälliköt vastaavat palvelusuunnittelusta. Kehitys tapahtuu projekteina, koostettuina julkaisuina (versiot) tai yksittäisinä muutoksina.

Nopea reagointi liiketoiminnan kehitystarpeisiin sekä uusien digitaalisten liiketoimintamahdollisuuksien kehittäminen ovat oleellinen osa palveluiden suunnittelua. Palvelun omistajat ja palvelupäälliköt ovat tärkeä osa proaktiivista palveluiden kehittämistä.

Palveluiden suunnittelu kytkee tärkeimmät sidosryhmät (esimerkiksi palvelun nykyiset tai tulevat käyttäjät, liiketoiminnan ja palveluntuotannon edustajat) mukaan palvelun suunnittelutyöhön. Palveluiden suunnittelun tarkoituksena on rakentaa kokonaisvaltainen ymmärrys eri sidosryhmien näkökannoista ja sen jälkeen käyttää tätä tietoa palvelun suunnittelussa ja kehittämisessä. Palveluiden suunnittelun avulla parannetaan loppukäyttäjien tyytyväisyyttä palveluun. Lisäksi se auttaa hallitsemaan ja tuottamaan palvelut tehokkaimmalla mahdollisella tavalla.

Palvelun suunnitteluvaihe identifioi ongelmia ja tarpeita, asettaa liiketoimintatavoitteita, profiloi käyttäjäryhmiä sekä kehittää, arvioi, testaa ja parantaa ratkaisuideoita. Tämän lisäksi tietyt palvelun kehittämisen työtavat auttavat mittaamaan ja jatkuvasti parantamaan käyttöönotettua palvelua. Palveluiden suunnitteluvaiheessa luodaan täysin uusia tai parannetaan olemassa olevia palveluita.

Palveluiden suunnittelu tukeutuu palveluarkkitehtuuriin, joka muodostuu neljästä elementistä:

  • Palveluluettelo
  • Palvelun kehityssuunnitelma (Service Roadmap)
  • Palvelutuotantomalli (Service Delivery Model)
  • Palvelurakenne (Service Structure)

SM_Service_Architecture_FI

Kuvio 6.4.1 Palveluarkkitehtuuri.

 

 

Palveluarkkitehtuurin avulla voidaan rakentaa optimaalinen palvelurakenne yhdessä ammattimaisen palveluhankinnan palvelun liiketoiminta-arvoon perustuvan kehityssuunnitelman kanssa. Palveluarkkitehtuuri on hyvä pitää niin selvänä ja yksinkertaisena kuin mahdollista.

Palveluarkkitehtuuri on suunnitelma palveluiden toteuttamisesta ja kehittämisestä yrityksen vallitsevassa ja/tai tulevassa operatiivisessa toimintaympäristössä. Palveluarkkitehtuuri ja sen yhteinen suunnittelu ovat hyvä tapa sitouttaa palveluiden tuottajat yhteistyöhön ja palveluiden jatkuvaan kehittämiseen.

Palveluarkkitehtuuria johtavat palvelun omistajat. Jokainen palvelun omistaja on vastuussa palvelualueesta tai tietystä palvelusta. Tyypillisesti organisaatioilla on 5-10 palvelualuetta, kuten esimerkiksi:

  •    Myynnin ja markkinoinnin ratkaisut
  •    Tuotannon ja toimitusketjun ratkaisut
  •    Tuotekehityksen ja suunnittelun ratkaisut
  •    Liiketoiminnan tukitoimintojen ratkaisut
  •    Loppukäyttäjäpalvelut, kuten esim. työasema- ja viestintäpalvelut ja
  •    Infrastruktuuripalvelut, kuten esim. kapasiteetti- ja yhteyspalvelut.

 

Palveluluettelo eli palvelukatalogi määrittää yrityksen tietohallinnon toimittamat palvelut. Katalogi tekee IT-palveluista konkreettisempia ja helpompia ymmärtää. Katalogia käytetään IT-johtamisen kehittämisen, organisoimisen, IT-palveluiden tuottamisen ja hankinnan viitekehyksenä. Se luo linkin liiketoiminnan ja tietohallinnon välille kuvaamalla, mitkä palvelut ovat saatavilla. Palvelukatalogi auttaa havainnollistamaan tietohallinnon palvelun painopisteitä ja liiketoiminnalle tuotettua arvoa.

Palvelukatalogi koostuu IT-palveluiden yleiskuvauksesta, palveluesitteistä, ja tilaus- ja palvelupyyntökatalogista. Palvelukatalogi hallitaan Palvelun hallinta-alustan avulla.

Palvelun kehityssuunnitelma on suunnitelma, jonka mukaan palvelua tai palvelualuetta kehitetään ja se kuvaa jokaisen aloitteen sisällön, aikataulun, kulut ja liiketoimintaedut. Jokainen kehityshanke on projekti, palvelujulkaisu tai muutos.

Palvelutuotantomalli määritellään yhdessä hankintatoimen kanssa. Mahdolliset toimitusmallit jatkuville palveluille sisältävät lähi- tai kaukoulkoistuksen sekä pilvipalvelut. Palvelutuotantomallissa päätetään, mitkä palvelut ostetaan, ja mitä toimittajia suositaan. Mallin pitäisi myös määrittää, ostetaanko palvelut kokonaispalveluna (end-to-end full service), erillisinä palvelukomponentteina vai yhdistämällä palveluja niin kutsutuiksi palvelutorneiksi (Service Towers), joihin valitaan kuhunkin palvelualueeseen parhaiten sopivat toimittajat. Yrityksen koko ja toimintamalli määrittävät suurelta osin parhaan palvelutuotantomallin.

Palvelurakenne sisältää määritelmät palvelun loogisesta rakenteesta, palveluiden välisistä suhteista ja vastuista. Palvelurakenne tarkentuu palvelutuotannon aikana konfiguraatiohallinnan tietokantaan (Configuration Management Database, CMDB).

Muutoksen- ja julkaisunhallinta

Muutoksenhallinta (Change Management) on hallinnollinen prosessi, joka hyödyntää standardisoituja menettelytapoja, joilla verrataan muutosten tarvetta suhteessa muutosten vaikutuksiin. Näin toimittaessa voidaan välttää tahattomat negatiiviset vaikutukset palvelun laatuun.

Julkaisunhallinta (Release Management) on toimeenpanoprosessi, jota käytetään muutosten toteuttamisessa ja käyttöönotossa. Tietyt muutokset voidaan myös toteuttaa yksittäin (esim. esihyväksytty standardimuutos tai hätätilanteessa tapahtuva muutos). Muutoksenhallinnasta voi tehdä ennakoivan ja ennustettavan aikatauluttamalla muutokset julkaisukalenteriin.

Palvelun elinkaaressa muutosten luokittelu ja toteuttaminen alkavat kehitysjonosta (Development Backlog), joka sisältää kehitystarpeet, pienet korjausvaateet ja selkeät muutospyynnöt (Change Requests) (kuva 6.4.2). Nämä muutokset on ensin kategorisoitava ja priorisoitava, jonka jälkeen ne pitää suunnitella, toteuttaa ja ottaa käyttöön.  Käyttöönoton jälkeen uusi toiminnallisuus arvioidaan ja luovutetaan palvelutuotannolle.

Muutoksia ovat normaalit muutokset, standardimuutokset sekä hätämuutokset. Normaalit muutokset ovat satunnaisia muutoksia palveluun tai infrastruktuuriin ja joista edellytetään muutoskomitean (Change Advisory Board, CAB) riskiarvio. Tämän kaltaisia muutoksia voidaan kerätä ja julkaista esimerkiksi neljä kertaa vuodessa. Normaalit muutokset jaetaan edelleen kolmeen alakategoriaan:

  • Pieni muutos: muutos on suhteellisen yksinkertainen ja sen riski aiheuttaa ongelmia palvelussa on hyvin pieni. Pieni muutos ei edellytä muutoskomitean hyväksyntää. Pienet muutokset voidaan mahdollisuuksien puitteissa vakioida standardimuutoksiksi.
  • Keskikokoinen muutos: muutos vaatii panostusta ja sillä saattaa olla merkittävä vaikutus palveluun. Tämän tyyppinen muutos vaatii muutoskomitean hyväksynnän.
  • Suuri muutos: Muutos saattaa vaikuttaa organisaation toiminnan kannalta kriittisiin palveluihin. Tämän tyyppiset muutokset vaativat hyväksynnän tietohallinnon johdolta muutoskomitean lisäksi.

 

Standardimuutos on etukäteen hyväksytty rutiininomaisesti suoritettava tehtävä. Standardimuutos kattaa ennakkoon määritellyn muutostarpeen aiheuttajan, dokumentoidut tehtävät sekä varauksen budjetista. Standardimuutoksen aiheuttama riski on pieni ja hyvin ymmärretty. Standardimuutokset voidaan toteuttaa palvelupyynnöillä. Hyvä esimerkki standardimuutoksesta on tietokoneen hankkiminen uudelle työtekijälle. Standardimuutokset voidaan toteuttaa pyyntöjen pohjalta, päivittäin, viikoittain tai kuukausittain joko yksittäin tai jakeluversiona.

Hätämuutokset on vietävä käyttöön niin pian kuin mahdollista, sillä niillä korjataan usein palvelutuotannossa olevia vakavia virheitä. Näihin muutoksiin sisältyy kuitenkin merkittäviä riskejä ja siksi hätämuutoksen toimeenpanolle vaaditaan vain ennalta määritelty muutoskomitean osakokoonpanon (Emergency CAB) hyväksyntä. Hätämuutokselle on oltava oma nopea eskalointiprosessi haitallisten vaikutusten ehkäisemiseksi tai vähentämiseksi. Hätämuutokset voidaan ottaa käyttöön yksittäin tai julkaisuprosessin kautta.

ea_change_cassification_fi

Kuvio 6.4.2 Muutosten luokittelu ja toimeenpano.

Ota yhteyttä Tietohallintomalli PDF

Haluatko tietää lisää Tietohallintomallista ja sen soveltamisesta käytännössä? Ota yhteyttä.