VERSIOHISTORIA

Tässä dokumentissa määritellään yhden kaupungin käytössä olevan ICT-palvelun palvelutasot. Palvelulla voidaan tarkoittaa kokonaispalvelua, joka sisältää kaikki palvelun tarjoamiseen tarvittavat komponentit eli palvelimet, järjestelmät, ohjelmistot, yhteydet, lisenssit jne. tai sitten jotain pienempää osaa palvelusta. Palvelu on siis tässä yhteydessä yleistermi, joka voi tarkoittaa myös yksittäistä järjestelmää, tuotetta tai ohjelmistoa.

Palvelutasojen määrityksessä on käytetty pohjana JUHTAn suositusta JHS 174 ICT-palvelujen palvelutasoluokitus ja monet esimerkeistä tulevat sieltä. Lisäksi dokumentissa on huomioitu niin ITIL^® v3 kuin ISO/IEC 20000 standardi. Näistä ITIL^®käsittelee palvelunhallinnan (service management) parhaita käytäntöjä, kun taas ISO/IEC 20000 on palvelunhallinnan kansainvälinen standardi, jota myös ITIL^®osaltaan noudattaa.

Terminologia on yhdistelmä ITIL^®, JHS 174:n ja ISO/IEC 20000 määritelmiä. Näissä on jonkun verran eroavaisuuksia, joten niistä on tehty erillinen kooste, josta voi tarkistaa mitä mikäkin termi tarkoittaa eri yhteydessä. Tässä dokumentissa käytetään termien ohessa myös englanninkielistä määritelmää, koska ne ovat johdonmukaisempia keskenään verrattuna ITIL^®in suomenkielisiin termeihin ja JHS 174:ään. Määritelmissä suositaan pääasiassa ITIL^®iä, koska JHS 174:ssä on tiedossa olevia ongelmia eikä se ole niin yleisessä käytössä kuin ITIL^®. Kaikkia JHS:n termejä ei löydy ITIL^®istä ja niistä osa on kuitenkin otettu tähän mukaan.

Dokumentin on tarkoitus olla mahdollisimman yleisluontoinen, että se sopisi eri palveluille mahdollisimman laajasti. Palvelujen toimittaminen voi tapahtua monilla eri tavoille, esim. SaaS-palveluna, pilvipalveluna tai sitten se voi olla asennettuna kaupungin omassa palvelinsalissa olevaan ympäristöön. Riippumatta toimittamisen tavasta tulee neuvottelut palvelutasoista käydä palveluntuottajan kanssa kohta kohdalta ja löytää sieltä molempia osapuolia tyydyttävät tasot.

Täyttöohjeet

Kussakin kappaleessa on tekstiä merkittynä kolmella eri tavalla:

Mustan tekstin voi jättää paikalleen sellaisenaan
Keltaisella merkitty teksti pitää korvata vastaamaan kohteena olevan palvelun tarpeita ja palvelutasotavoitteita ja ohjetekstin voi poistaa
Harmaalla merkitty teksti on taustatietoja ja yleisiä periaatteita, jotka voi halutessaan poistaa lopullisesta versiosta

Lähtökohtana kuitenkin on, että mikään tässä dokumentissa oleva palvelutasotavoite tai muu vaatimus ei ole pakollinen ja se voidaan poistaa lopullisesta SLA:sta. Tyypillisesti keskeisiä ovat ainakin palveluaika, palvelun saatavuus, ratkaisuajat, palveluvaste sekä niihin liittyvät sanktiot.

Määritelmät


Termi suomeksi	Termi englanniksi	Selitys
asiakas	customer	Palvelun tilaaja, palvelujen kohteiden hallinnoija, jolla on oikeus määrittää palvelun kohteet ja näiden palvelutasotavoitteet palveluntuottajan tarjoamien palvelutasoluokkien puitteissa. (JHS 174)
häiriö, insidentti	incident	Suunnittelematon IT-palvelun keskeytys tai IT-palvelun laadun laskeminen. Konfiguraation rakenneosan toimintahäiriö, joka ei ole vielä vaikuttanut palveluun, on myös häiriö; esimerkkinä yhden peilatun levyn toimintahäiriö. (ITIL^®)
häiriön kriittisyysluokka	incident priority	Häiriötilanteen vakavuuden luokitteluun tarkoitettu luokitteluasteikko. Kriittisyysluokittelu muodostaa järjestysasteikon matalimman tason häiriöstä korkeimman tason häiriöön. (JHS 174)
konfiguraatioyksikkö, konfiguraation rakenneosa, CI	configuration item, CI	Mikä tahansa komponentti tai muu palveluomaisuus, jota täytyy hallita IT-palvelun toimittamisessa. Informaatio jokaisesta konfiguraation rakenneosasta (CI) kirjataan konfiguraatiotietueena konfiguraationhallintajärjestelmään, ja sitä ylläpidetään koko sen elinkaaren ajan konfiguraationhallintaprosessilla. CI:t ovat muutoksenhallinnan valvonnassa. CI:t ovat tyypillisesti IT-palveluja, laitteistoja, ohjelmistoja, rakennuksia, ihmisiä ja virallisia asiakirjoja, kuten prosessidokumentaatio ja palvelutasosopimukset. (ITIL^®)
käytettävyys	availability	(JHS 174) ks. palvelun saatavuus
käyttäjä	user	Xxxxxxx, joka käyttää IT-palvelua päivittäin. Käyttäjät ovat eri asia kuin asiakkaat, koska jotkut asiakkaat eivät suoranaisesti käytä IT-palvelua. (ITIL^®)
käyttökatko	downtime	Aika, jolloin IT-palvelu tai konfiguraation rakenneosa ei ole saatavilla sovittuna palveluaikana. IT-palvelun saatavuus lasketaan usein sovitusta palveluajasta ja käyttökatkosta.
maksimikatko	maximum downtime	Pisin yksittäinen yhtämittainen palvelukatko, joka sallitaan palvelun palvelutasotavoitteiden puitteissa palveluaikana sovitulla tarkasteluvälillä. Esim. 2 tuntia yhden kalenterikuukauden aikana. Huom. tämä yksittäisen katkon enimmäispituus on määritelty tässä suosituksessa aina pienemmäksi kuin kaikkien palvelukatkojen kumulatiivinen kesto. (JHS 174)
muutospyyntö, RFC	request for change, change request	Muodollinen ehdotus muutoksen tekemiseksi. RFC sisältää ehdotetun muutoksen tiedot, ja se voidaan kirjata paperille tai sähköisesti. Termiä käytetään usein virheellisesti tarkoittamaan muutostietuetta tai muutosta itsessään. (ITIL^®)
ongelma	problem	Yhden tai useamman häiriön syy. Syytä ei yleensä tiedetä sillä hetkellä, kun ongelmatietue luodaan, ja ongelmanhallintaprosessi vastaa lisätutkinnasta. (ITIL^®)
palvelu	service	Keino tuottaa arvoa asiakkaille auttamalla asiakkaita saavuttamaan haluamansa tulokset ilman, että asiakas omistaa tietyt kustannukset ja riskit. Termiä ’palvelu’ käytetään joskus synonyyminä ydinpalvelulle, IT-palvelulle tai palvelupaketille. (ITIL^®)
palveluaika	service hours	Sovittu ajanjakso, jolloin tietyn IT-palvelun tulisi olla käytettävissä, esimerkiksi maanantaista perjantaihin klo 8:0017:00 pois lukien arkipyhät. Palveluaika tulee määritellä palvelutasosopimuksessa. (ITIL^®)
palvelun saatavuus, saatavuus	service availability	Konfiguraation rakenneosan tai IT-palvelun kyky suorittaa sovittu toiminto vaadittuna aikana. Saatavuus koostuu luotettavuudesta, ylläpidettävyydestä, huoltovarmuudesta, suorituskyvystä ja turvallisuudesta. Saatavuus lasketaan yleensä prosentteina. Laskenta perustuu yleensä sovittuun palveluaikaan ja käyttökatkoon. Paras käytäntö on laskea IT-palvelun saatavuus käyttäen mittarina tuottoa liiketoiminnalle. (ITIL^®) Tästä käytetään joskus myös termiä käytettävyys mutta sitä tulisi välttää, koska se sekoitetaan liian helposti englanninkieliseen termiin usability
palveluntuottaja	service provider	Organisaatio, joka tuottaa palveluja yhdelle tai usealla sisäiselle tai ulkoiselle asiakkaalle. Palvelutuottaja termiä käytetään usein IT-palvelutuottajan lyhenteenä. (ITIL^®)
palvelupiste	service desk	Keskitetty yhteydenottopiste palvelutuottajan ja käyttäjien välillä. Tyypillinen service desk hallinnoi häiriöitä ja palvelupyyntöjä, ja hoitaa myös viestinnän käyttäjien kanssa. (ITIL^®)
palvelupyyntö	service request	Käyttäjän muodollinen pyyntö jonkin toimittamiseksi - esimerkiksi pyyntö saada tietoa tai neuvontaa, salasanan resetointi tai uuden käyttäjän työasema-asennus. Palvelupyyntöjä hallitsee palvelupyyntöprosessi tavallisesti yhdessä palvelupisteen (service desk) kanssa. Palvelupyynnöt voidaan linkittää muutospyyntöön osana palvelupyynnön toteuttamista. (ITIL^®)
palvelutasosopimus, SLA	service level agreement, SLA	Sopimus IT-palvelutuottajan ja asiakkaan välillä. SLA kuvaa IT-palvelun, dokumentoi palvelutasotavoitteet ja yksilöi IT-palvelutuottajan ja asiakkaan vastuut. Yksittäinen SLA voi kattaa useita IT-palveluja tai useita asiakkaita. (ITIL^®)
palvelutasotavoite	service level target	Sitoumus, joka on dokumentoitu palvelutasosopimuksessa. Palvelutasotavoitteet pohjautuvat palvelutasovaatimuksiin, ja niitä tarvitaan varmistamaan, että IT-palvelu voi saavuttaa liiketoiminnan tavoitteet. Niiden pitäisi olla yleisesti kattavia, ja ne perustuvat tavallisesti keskeisiin suorituskykymittareihin. (ITIL^®)
palveluvaste		Palveluvasteen mittaamisen perustana on palvelun palvelupyyntöjen, häiriöilmoituksien, palvelupyynnön toteuttamisen, häiriöiden käsittelyn sekä näiden tapahtuma-aikojen kirjaaminen/tallentuminen palveluntuottajan käyttämään palvelupyyntöjen hallintajärjestelmään (tiketöintijärjestelmä). (JHS 174)
ratkaisuaika		Aika häiriön tai ongelman havaitsemisesta, jonka aikana toimittajan tulee saada poistettua häiriö tai ongelma tai muuten normalisoida palvelu. (JHS 174)
ratkaisukyky		Ratkaisukyvyllä tarkoitetaan palvelupisteen (Service desk, help desk) tai muun asiakkaan palvelupyynnön vastaanottavan tahon kykyä ratkaista ko. palvelupyyntö siirtämättä / ohjaamatta palvelupyyntöä eteenpäin muille tukitasoille / palvelujonoille. (JHS 174)
reagointiaika	response time	Aika, jonka kuluessa tapahtuman tai häiriön havaitsemisesta tulee häiriön korjaaminen tai tapahtuman käsittely aloittaa. Reagointiaika riippuu yleensä häiriön kriittisyysluokasta. Häiriö voidaan havaita joko asiakkaan häiriöilmoituksesta (tapahtuma) tai toimittajan itsenäisen valvontahälytyksen tai muun havainnon (event management) pohjalta Huom. ITIL^®-termistössä tästä käytetään myös nimitystä vasteaika. Koska ITIL^®-suomennoksessa samaa vasteaikatermiä käytetään myös kuvaamaan ratkaisun suorituskykyä, väärinymmärryksen välttämiseksi suositellaan käytettäväksi palvelutasojen yhteydessä termiä reagointiaika. (JHS 174) ks. vasteaika
reagointikyky	responsiveness	Mittari mittaamaan johonkin reagoimiseen kuluvaa aikaa. Tämä voi olla transaktion vasteaika tai IT-palvelutuottajan nopeus reagoida häiriöön tai muutospyyntöön jne. (ITIL^®)
suunniteltu käyttökatko	planned downtime	Sovittu aika, jolloin IT-palvelu ei ole saatavilla. Suunniteltua käyttökatkoa käytetään usein ylläpitoon, päivityksiin ja testaukseen
tavoitettavuus		Tavoitettavuudella tarkoitetaan palveluntuottajan palvelupisteen (Service desk, help desk) kykyä vastata sovitussa ajassa sinne tuleviin palvelupyyntöihin. Tyypillisesti tavoitettavuus koskee puhelinpalvelua ja määritetään keskimääräisenä tavoitettavuutena. (JHS 174)
tietue, kirjaus, tallenne	record	Dokumentti, joka sisältää prosessin tai aktiviteetin tuloksen tai muun tuotoksen. Tietueet ovat todisteita siitä, että toimenpide tapahtui. Se voi olla paperinen tai sähköinen; esimerkiksi auditointiraportti, häiriötietue tai kokouspöytäkirja. (ITIL^®)
tunnettu virhe	known error	Ongelma, jolla on dokumentoitu perussyy ja väliaikaisratkaisu. Tunnetut virheet kirjataan, ja niiden koko elinkaarta hallitaan ongelmanhallintaprosessissa. Myös kehittäjät tai toimittajat voivat havaita tunnettuja virheitä. (ITIL^®)
valvonta, monitorointi, seuranta	monitoring	Konfiguraation rakenneosan, IT-palvelun tai prosessin toistuva havainnoiminen herätteiden havaitsemiseksi ja sen varmistamiseksi, että vallitseva tila on tiedossa. (ITIL^®)
vasteaika	response time	Toimenpiteen tai transaktion loppuunsaattamiseen kuluva aika. Käytetään kapasiteetinhallinnassa mittaamaan IT-infrastruktuurin suorituskykyä ja häiriönhallinnassa mittaamaan puhelimeen vastaamiseen tai diagnosoinnin aloittamiseen kuluvaa aikaa. (ITIL^®) JHS:ssä käytetään myös termiä reagointiaika

Palvelun kohde

Kirjoita tähän, mitä palvelua, järjestelmää, tuotetta tai sovellusta palvelutasosopimus koskee.

Jos tätä dokumenttia käytetään kilpailutuksen pohjana, on tärkeää varmistaa, että seuraavien kappaleiden vastuunjako-kohdat vastaavat sitä mitä ollaan hankkimassa ja sisältö vastaa hankinnan kohdetta. Erityisesti lisenssien osalta voi tulla yllättäviä lisäkuluja, jos niiden vastuita ei ole mietitty tarkasti etukäteen.

Tuotantoympäristö

Kuvaa ja luettele tässä ympäristöt, ohjelmistoalustat, palvelimet. Voit myös lisätä linkin kuvaukseen, jota säilytetään jossain muualla.

Vastuunjako: mikä palveluntuottajan, mikä asiakkaan, mikä muiden toimijoiden vastuulla?

Lisää myös arkkitehtuurikuva, josta näkyy palveluun kuuluvat palvelimet yms. komponentit

Testiympäristö

Kuvaa ja luettele tässä testiympäristöt, ohjelmistoalustat, palvelimet. Voit myös lisätä linkin kuvaukseen, jota säilytetään jossain muualla.

Vastuunjako: mikä palveluntuottajan, mikä asiakkaan, mikä muiden toimijoiden vastuulla?

Lisenssit

Vastuunjako: mikä palveluntuottajan, mikä asiakkaan, mikä muiden toimijoiden vastuulla?

Dokumentaatio

Luettele, mitä dokumentaatiota palveluntuottaja ylläpitää ja mistä se löytyy.

Palvelun kriittisyyden/merkittävyyden arviointi

Palvelutasojen määrittelyssä on olennaista tietää mikä on kyseessä olevan palvelun kriittisyys. Kriittisyyden arvioinnista on tärkeää miettiä sitä koko organisaation toiminnan kannalta, eikä vain välttämättä oman organisaatioyksikön kannalta. Muutoin turhan monet palvelut saavat korkeimman mahdollisen kriittisyysluokituksen ja sen mukaiset palvelutasot taas maksavat enemmän kuin alhaisemman kriittisyysasteen palvelut.

Palveluiden ja tietojärjestelmien kriittisyys on lisättävä myös kaupungin tietojärjestelmäsalkkuun. JHS 179:n mukaisessa tietojärjestelmäsalkussa on seuraavat tasot: kriittinen, tärkeä, hyödyllinen ja vähäinen.

Kriittisyyden arvioinnin tulee perustua kaupungin omaan kulloinkin voimassa olevaan ohjeeseen.

PALVELUN KRIITTISYYS

Valitse alla olevasta taulukosta palvelun kriittisyys. Palvelun kriittisuus vaikuttaa myöhemmin tässä dokumentissa esitettyihin palvelutasoihin. Muut vaihtoehdot voi jättää taulukkoon tai poistaa ylimääräiset rivit. Dokumentissa pitää kuitenkin olla näkyvissä se mikä on juuri tämän palvelun kriittisyys.

Palvelun kriittisyys
kriittinen	☐
tärkeä	☐
hyödyllinen	☐
vähäinen	☐

Palvelutasot
1. Palvelupiste (service desk)

Palvelulla on tavallisesti jonkinlainen palvelupiste (service desk). Se voi olla kaupungin yhteinen, palvelukohtainen (esim. pääkäyttäjä tai vastaava vastuuhenkilö) tai palveluntuottajan tarjoama palvelupiste. Riippumatta siitä millainen palvelupiste on tai kuka sen tarjoaa, täytyy palvelun käyttäjän tietää mihin hän on yhteydessä niin häiriöiden kuin palvelupyyntöjen osalta. Näin ollen palvelulle täytyy määritellä, miten palvelupisteeseen ollaan yhteydessä. Yhteydenottotapa voi olla verkkolomake, sähköposti, puhelinnumero tai näiden yhdistelmä. ITIL^®issä suositellaan, että olisi ns. keskitetty yhteydenottopiste (single point of contact, SPOC), jonne käyttäjät olisivat aina yhteydessä mutta tämä ei aina ole mahdollista ja monesti tarjotaan useampaa eri mahdollisuutta.

Täytä alla olevaan taulukkoon palvelussa sovitut yhteydenottotavat ja voit halutessasi poistaa ylimääräiset.

Yhteydenottotapa	Osoite/puhelinnumero
Puhelin	+358 XXX XXX XXXX
Verkkolomake	xxxxx://xxxxxx.xxxxxx.xx
Sähköposti	n.n.@xxxxxx.xx

Palvelupisteen käytössä tulisi olla järjestelmä, jonne niin häiriöt kuin palvelupyynnöt kirjataan. Kirjaamisen jälkeen järjestelmän tulisi lähettää tietoa häiriön tai palvelupyynnön käsittelyn etenemisestä häiriöstä ilmoittaneelle tai palvelunpyynnön tehneelle taholle.

Reagointiaika (response time)

Palvelupisteelle voidaan määritellä myös reagointiaika (response time). Samasta asiasta käytetään myös nimitystä vasteaika ja hieman eri merkityksessä reagointikyky (responsiveness) mutta sekaannusten välttämiseksi niitä ei käytetä tässä yhteydessä. Reagointiajalla tarkoitetaan IT-palvelutuottajan nopeutta reagoida häiriöön, tapahtumaan, palvelupyyntöön tai muutospyyntöön. Reagointiaika määritellään, jos koetaan että häiriötilanteessa täytyy saada mahdollisimman nopeasti palveluntuottaja aloittamaan toimenpiteet. Reagointiajan määrittely ei kaikissa palveluissa ole välttämättä ole tarpeellista, sillä se ei vaikuta häiriön korjauksen tai palvelupyynnön suorittamisen ratkaisuaikojen tavoitteisiin mutta vaikuttaa toki epäsuorasti kokonaisratkaisuaikaan, jos palveluntuottaja ei aloita analysointia välittömästi. Reagointiaika päättyy, kun toimittajan asiantuntija on kuitannut vian vastaanotetuksi. Reagointiaika ei pääty toimittajan tiketöintijärjestelmän lähettämään automaattiseen vastaanottokuittaukseen.

Täytä alla olevaan taulukkoon palvelussa sovitut yhteydenottotavat ja voit halutessasi poistaa ylimääräiset.

Yhteydenottotapa	Reagointiaika
Puhelin	30 min
Verkkolomake	30 min
Sähköposti	30 min

Siinä tapauksessa, jos palvelupiste on organisaatiossa ensisijainen ensimmäinen tason tukipalvelu, johon kaikki käyttäjät ottavat yhteyttä erinäisissä ongelmissa, voidaan etenkin puhelinpalvelun reagointiaika määritellä tarkemmin. JHS 174 käyttää tässä yhteydessä termiä tavoitettavuus. Jos tämä koskee tässä dokumentissa määriteltyä palvelua niin ks. JHS 174:n liite 1 kpl 5.1.4.

Pääkäyttäjät

Joissakin tapauksissa voidaan palvelupisteen lisäksi tai sijasta tarjota pääkäyttäjätukea, jolloin palvelulla on nimetty pääkäyttäjiä, joihin käyttäjät ovat ensisijaisesti yhteydessä niin häiriöissä kuin palvelupyynnöissä. Pääkäyttäjät voivat itse toimia myös palvelupisteenä ja kun he eivät pysty itse korjaamaan häiriötä, ilmoittavat he tilanteesta palvelupisteeseen tai suoraan toisen tason tukeen.

Kirjaa tähän palvelun käytännöt liittyen pääkäyttäjien tarjoamaan tukeen.

Palveluaika (service hours)

Palvelun kriittisyys määrittelee tarvittavan palveluajan. Palveluntuottaja on velvollinen vastaamaan palvelupyyntöihin sekä häiriöihin palveluaikana.

Kirjaa tähän palvelun palveluaika. Huomioi myös aikavyöhyke, jos palveluntuottaja toimittaa palveluaan ulkomailta.

Palvelu	palveluaika
Palvelun/järjestelmän nimi	24/7

Palveluaikoja voi palvelulle olla käytössä useita. Esim. yo. palveluajalla tarkoitetaan palvelun kokonaispalveluaikaa mutta se voidaan määritellä erikseen eri rakenneosalle (CI). Esim. saman palvelun palvelupisteellä voi palveluaika olla vain virka-aikana (esim. 8/5 välillä 8-16) mutta palveluun liittyvien palvelinten palveluaika taas voi olla esim. 24/7 tai 24/5. Näissä tapauksessa konesalipalveluiden palveluntuottajalla voi olla myös oma palvelupiste, joka tarjoaa palvelua virka-ajan ulkopuolella.

Kirjaa ao. taulukkoon eri rakenneosien ylläolevasta poikkeavat palveluajat.

Rakenneosa (CI)	palveluaika
Rakenneosan nimi (esim. sovellus-/tietokantapalvelimet)	24/7

ESIMERKKEJÄ

Palveluaika sovitaan erikseen palveluntuottajan kanssa, joten alla olevat ajat ovat vain esimerkkejä.

Palvelun kriittisyys	palveluaika
kriittinen	24/7
tärkeä	esim. 12/5 (7:00-19:00)
hyödyllinen	esim. 7/5 (8:00-16:00)
vähäinen	esim. 7/5 (8:00-16:00)

Palvelun saatavuus (availability)

Palvelun saatavuudella tarkoitetaan palvelun kykyä suorittaa sovittu toiminto vaadittuna aikana. Saatavuus esitetään yleensä prosenttiosuutena ajasta, jonka palvelu on tosiasiallisesti käytettävissä, verrattuna sovittuun aikaan (ks. 3.2). Määrittele alla olevaan taulukkoon palvelun tai rakenneosan saatavuus ja maksimikatko. Maksimikatkoa ei ole pakko määritellä vaan sen voi jättää pois.

Palvelu/rakenneosa	saatavuus	maksimikatko palveluaikana
Palvelun/järjestelmän nimi	99,95%	30 min
Rakenneosan 1 nimi (esim. sovelluspalvelimet)	99,95%	30 min
Rakenneosan 2 nimi (esim. tietokannat)	99,95%	30 min

Saatavuuteen liittyen voidaan määritellä myös muita suorituskykymittareita, jos ne palvelun näkökulmasta katsotaan tarpeellisiksi.

Lisää alla olevaan taulukkoon haluamasi suorituskykymittarit tai poista ylimääräiset.

Suorituskykymittari	tavoite
Katkojen max. lukumäärä / kk	4 kpl
Sovittujen huoltokatkojen lukumäärä / kk	1 kpl

ESIMERKKEJÄ:

Alla olevan taulukon saatavuusprosentit ja maksimikatkot ovat esimerkkejä JHS 174:stä mutta ne sovitaan palvelukohtaisesti tarkemmin palveluntuottajan kanssa.

Palvelun kriittisyys	saatavuus	maksimikatko palveluaikana
kriittinen	99,95%	30 min
tärkeä	99,9%	1 tuntia
hyödyllinen	99,5%	2 tuntia
vähäinen	97,0%	24 tuntia

Ratkaisuajat häiriöille (incident)

Tässä kappaleessa kuvataan palvelutasovaatimukset häiriöille (incident). Sovittujen palvelutasojen mukainen ratkaisuaika koskee sovitulla tavalla tulleita yhteydenottoja (ks. 3.1). Ratkaisuajan laskenta käynnistyy, kun tukipyyntö on otettu vastaan ja päättyy, kun palvelun saatavuus on palautunut normaalille tasolle, tai häiriölle on keksitty väliaikaisratkaisu (workaround). Väliaikaisratkaisut tulee kirjata tunnettujen virheiden tietokantaan (KEDB), joka voi olla osa konfiguraation hallintajärjestelmää (CMS).

Palvelutasot ovat voimassa palveluajan puitteissa.

Kullekin häiriölle tulee määritellä sen prioriteetti, joka tavallisesti tulee seuraavan matriisin mukaisesti:

		vaikuttavuus (impact)
		korkea	keskitaso	alhainen
kiireellisyys (urgency)	korkea	1	2	3
	keskitaso	2	3	4
	alhainen	3	4	5

Esim. jos vaikuttavuus on korkea (koskee laajaa joukkoa ihmisiä) ja kiireellisyys samoin on korkea, tulee prioriteetiksi 1. Jos taas häiriö on vaikuttavuudeltaan alhainen (koskee esim. vain paria ihmistä) mutta näiden ihmisten osalta kiireellisyys on korkea, tulee prioriteetiksi 3.

Prioriteetti	Kuvaus	Ratkaisuaika (h)
1	Koko palvelu jumiutunut, erittäin hidas tai käyttäjät eivät pääse kirjautumaan käyttö täysin estynyt). Normaaleja operaatioita ei voida suorittaa. Häiriö koskee laajaa käyttäjäjoukkoa tai kokonaista organisaation toimintoa.	1 h
2	Häiriö haittaa merkittävästi palvelun saatavuutta, sen laitteistoa, sovelluksen osaa tai alustaa, jotka ovat toistuvasti epävakaita tai eivät vastaa normaalisti palvelupyyntöihin. TAI Häiriö estää palvelun käyttöä joltain osin (käyttö merkittävältä osalta estynyt).	4 h
3	Häiriö haittaa jonkin verran palvelun saatavuutta tai ei vastaa normaalisti palvelupyyntöihin. TAI Häiriö estää palvelun käyttöä osittain osin (käyttö estynyt osittain).	8 h
4	Häiriöt, jotka eivät estä käyttöä. Häiriö on satunnainen, koskee harvoin käytettäviä erityispalveluja ja/tai voidaan kiertää. Muu tilanne, joka ei vaaranna organisaation toimintaa.	12 h
5	Häiriöt, jotka eivät estä käyttöä tai koskee vain yksittäistä henkilöä.	24 h

Ratkaisuajat palvelupyynnöille (service requests)

Tässä kappaleessa kuvataan palvelutasovaatimukset palvelupyynnöille (service request). Toisin kuin häiriöille ei palvelupyynnöillä määritellä kriittisyyttä, vaan vasteajat riippuvat täysin palvelusta ja itse pyynnöstä. Yksi esimerkki palvelupyynnöstä käyttöoikeuden myöntäminen palveluun, jonka ratkaisuaika voi olla mitä tahansa muutamasta tunnista muutamaan päivään, riippuen täysin palvelun kohteesta. Palvelupyyntö voi olla myös pyyntö saada tietoa tai neuvontaa, salasanan resetointi tai uuden käyttäjän työasema-asennus.

Sovittujen palvelutasojen mukainen ratkaisuaika koskee sovittua kanavaa pitkin tulleita yhteydenottoja. Ratkaisuajan laskenta käynnistyy, kun pyyntö on otettu vastaan ja loppuu kun käyttäjä kuittaa palvelupyynnön suoritetuksi.

Palvelupyyntöjen palvelutasot ovat voimassa palveluajan puitteissa.

Palvelupyyntö	Kuvaus	Ratkaisuaika (h)
Xxxxxxxxx resetointi	Palvelupyyntö edellyttää nopeita toimenpiteitä tai pyydetty tieto on oleellinen asiakkaan töiden etenemisen kannalta.	8 h
Käyttäjäoikeuksien lisäys	Palvelupyyntö edellyttää kohtalaisen nopeita toimenpiteitä tai pyydetty tieto on jossain määrin oleellinen asiakkaan töiden etenemisen kannalta.	16 h
Työasema-asennus	Palvelupyyntö ei edellytä nopeita toimenpiteitä tai pyydetty tieto ei ole oleellista asiakkaan töiden etenemisen kannalta.	40 h

Häiriöiden ja palvelupyyntöjen ratkaisukyky

Häiriöille ja palvelupyynnöille määritellään tavallisesti myös erilaisia pyyntöjen ratkaisukykyyn liittyviä keskeisiä suorituskykymittareita (KPI), joille voi myös määritellä palvelutason. Suorituskykymittareiden laskentakaavat löytyvät JHS 174:n liitteestä 1 ja niitä ovat mm.:

Ensimmäisen kontaktin ratkaisukyky (first contact resolution, FCR) eli kyky ratkaista ongelma ensimmäisen tason tuessa ilman, että sitä on tarvetta eskaloida seuraavalle tasolle. Tällä mitataan tavallisesti palvelupisteen kykyä suoriutua pyynnöistä eskaloimatta sitä seuraavalle tasolle.
Ensimmäisen kerran ratkaisukyky (first pass resolution, FPR), eli kyky ratkaista pyyntö ensimmäisellä kerralla ilman, että pyyntöä tarvitsee asiakkaan pyynnöstä avata myöhemmin uudelleen. Palveluntuottajat yleensä kiertävät tätä kirjaamalla uuden palvelupyyntö- tai häiriötietuen, vaikka kyseessä olisi sama häiriö.

Kirjaa alla olevaan taulukkoon haluamasi KPI:t ja niiden palvelutasotavoitteet

Suorituskykymittari	Tavoite
Ensimmäisen kontaktin ratkaisukyky	95 %
Ensimmäisen kerran ratkaisukyky	95 %

Häiriöiden ja palvelupyyntöjen palveluvaste

Palveluvasteen mittaamisen perustana on palvelun palvelupyyntöjen ja häiriöilmoituksien ratkaisu SLA-tavoiteajassa. Laskentakaava löytyy JHS 174:n liitteestä 1. Palveluvasteesta puhutaan myös termillä on-time delivery, OTD ja JHS 174:ssä palveluvaste).

Kirjaa alla olevaan taulukkoon palveluvasteen palvelutasotavoite

Suorituskykymittari	Tavoite
Palveluvaste = Palvelupyyntöjen/häiriöiden ratkaisu SLA-tavoiteajassa	95 %

Suorituskyky

Palvelulta voidaan vaatia myös riittävän hyvää suorituskykyä eli palvelun/järjestelmään tulee vastata toimintoihin sovitussa ajassa ilman tarpeettomia viiveitä. Tässä tapauksessa SLA:han on hyvä merkitä mitkä ovat vasteaikojen tavoitteet. Vasteaikatavoitteet pitää huomioida jo palvelua/järjestelmää hankittaessa, että se voidaan rakentaa käyttäjämäärät huomioiden ja että vasteajat ovat ylipäätään mahdollisia.

Kirjaa alla olevaan taulukkoon halutut vasteajat.

Palvelun/ järjestelmän toiminto	Vasteaika
Aloitussivun lataaminen	x ms
Sisäänkirjautuminen	x ms
Tietojen tallennus	x ms

Jatkuvuudenhallinta (continuity management)

Jatkuvuudenhallinta (continuity management) on osa IT-palvelutuotantoa ja se olisi hyvä huomioida myös SLAssa. Jatkuvuudenhallinnassa kiinnitetään erityisesti huomiota niiden riskien hallintaan, mitkä vaikuttavat ydintoimintoihin ja siihen miten vaaditut minimipalvelutasot voidaan varmistaa myös laajamittaisissa häiriötilanteissa (major incident). Jatkuvuudenhallintaan liittyvässä jatkuvuussuunnitelmassa voidaan määritellä se, miten palvelun ympäristö pitää rakentaa (kahdennetut järjestelmät), miten varmennuksia tehdään ja miten laajamittaisissa häiriötilanteissa viestitetään. Jatkuvuudenhallintaan liittyen määritellään tavallisesti kaksi eri palvelutasomittaria, jotka ovat toipumisaikatavoite (recovery time objective) eli RTO ja maksimi tiedonmenetysjakso (recovery point objective) eli RPO. Näillä kahdella määreellä määritellään miten nopeasti häiriötilanteesta pitää palautua normaalitilaan (=toipuminen) ja miten paljon tietoa voidaan toiminnan näkökulmasta maksimissaan menettää. Erittäin kriittisissä järjestelmissä tehdään usein ennalta myös laajamittaisen häiriötilanteen menettelytapa (major incident procedure, MIP), jossa kerrotaan miten ko. tilanteissa toimitaan, kenelle viestitään, ketkä osallistuu jne.

Mittari	Tavoite
toipumisaikatavoite (RTO)	8h
maksimi tiedonmenetysjakso (RPO)	1 vrk

Varmuuskopiot

Yllä olevien tavoitteiden saavuttamiseen liittyy erityisesti varmuuskopiot, sillä maksimi tiedonmenetysjaksosta riippuu, miten usein varmuuskopioita on vähintään otettava.

Palveluntuottajan on testattava varmuuskopioiden palautusta säännöllisesti.

TOIPUMISSUUNNITELMA

Erityisesti kriittisten palvelujen osalta palvelutuottajan täytyy luoda toipumissuunnitelma (disaster recovery plan). Toipumissuunnitelmassa kerrotaan se, miten palvelu voidaan palauttaa lähtötilanteeseen mahdollisessa katastrofitilanteessa. Toipumissuunnitelma on osa jatkuvuussuunnitelmaa (ks. yllä).

Joissakin tapauksissa voidaan haluta sanktioida niin jatkuvuussuunnitelman kuin toipumissuunnitelman puuttumisesta.

Kirjaa tähän palvelun jatkuvuudenhallintaan liittyvät käytännöt.

Palveluun liittyvät käytännöt

Palveluun liittyvät käytännöt voidaan kuvata myös jossain muussa dokumentissa (esim. erillisessä palvelukuvauksessa) johon tässä dokumentissa kannattaa viitata, jos sellainen on erikseen tehtynä.

Häiriönhallinta (incident management)

Häiriöilmoitukset kirjataan aina palvelunhallintajärjestelmään. Palvelupiste käsittelee pyynnöt (priorisoi ja kohdistaa oikeaan rakenneosaan) eteenpäin häiriönselvityksen palvelujonoon. Palvelupisteellä on asiakasta varten päivystysvuorossa oleva henkilö, joka selvittää häiriöt palvelutasotavoitteiden puitteissa.

Häiriöselvitys voi käynnistyä joko siten, että palveluntuottaja havaitsee häiriötilanteen tai käyttäjä ilmoittaa häiriöstä palvelupisteeseen. Kummassakin tapauksessa kirjataan häiriöilmoitus palvelunhallintajärjestelmään. Tämän jälkeen häiriö siirretään häiriönselvityksen palvelujonoon.

Palveluntuottaja määrittelee häiriön kriittisyyden häiriön palvelutasoluokittelun mukaisesti. Tämän jälkeen palveluntuottaja käynnistää häiriön selvitys- ja ratkaisutoimenpiteet sovittujen palvelutasotavoitteiden puitteissa. Palveluntuottaja toimii tarpeen mukaan yhteistyössä muiden asiakkaan palveluntuottajien ja asiakkaan kanssa siten, että häiriö saadaan mahdollisimman nopeasti selvitettyä ja korjattua. Häiriöselvityksessä pyritään palauttamaan mahdollisimman nopeasti järjestelmän normaali toiminta mahdollisesti kiertämällä häiriön aiheuttaja tai tekemällä nopeita toimenpiteitä, jotka poistavat häiriön tilapäisesti. Tämän jälkeen häiriölle pyritään löytämään pysyvämpi korjaus ongelmanhallinnan avulla.

Palveluntuottaja tiedottaa asiakasta häiriön korjauksen edistymisestä. Ellei toisin sovita, yhteyshenkilöiden ja pääkäyttäjien tulee ottaa ensisijaisesti yhteyttä palveluntuottajan palvelupisteeseen, josta häiriönselvitystä koordinoidaan.

Monitorointi

Kuvaa tähän palvelun ja rakenneosien mahdollinen monitorointi.

Ongelmanhallinta (problem management)

Ongelmanhallinnan prosessi voi käynnistyä seuraavilla tavoilla:

Palvelupisteeseen saapuu tukipyyntö, joka vaatii ongelmanhallintaa
Häiriönhallinnassa havaitaan häiriö, jonka pysyvä ratkaiseminen vaatii laajempia ongelmanhallinnan toimenpiteitä
Ongelma havaitaan herätteidenhallinnan (event management) tai muun monitoroinnin kautta

Ongelmanhallinnan tavoitteena on löytää ongelman juurisyy (root cause) ja suunnitella tarvittavat toimenpiteet sen korjaamiseksi.

Juurisyyn löytämisen ja korjaavien toimenpiteiden suunnittelun jälkeen voidaan ongelman korjaamisesta laatia työmäärä- ja kustannusarvio. Korjaamisesta tehdään muutospyyntö (request for change), joka kirjataan palvelun työjonoon. Tämän jälkeen asiakkaan tuoteomistaja päättää korjauksen toteuttamisesta ja toimenpiteiden priorisoinnista.

Muutoksenhallinta (change management)
1. Muutospyyntöjen (request for change) käsittely

Palveluntuottaja arvioi sovellusta koskevia muutospyyntöjä ja antaa muutossuosituksia sekä laatii erityisesti alustaa koskevia muutossuunnitelmia tarpeen mukaan. Kaikkien muutosten mahdollinen vaikutus aikatauluun, kustannusvaikutus ja vaikutukset muihin sopimusehtoihin sovitaan kirjallisesti etukäteen.

Muutospyynnöt kirjataan sovelluksen palvelunhallintajärjestelmään. Hyväksytyt muutokset siirretään tuotteen kehitysjonoon.

Versiopäivitykset
1. Palvelun/sovelluksen versiopäivitykset

Palveluun voidaan tehdä kahdenlaisia päivityksiä: asiakkaan toiveesta tehtäviä jatkokehitystöitä sekä pienempiä virheenkorjauksia.

Suurempi jatkokehityshanke koskee seuraavia tapauksia: palveluun kehitetään useita selkeästi toiminnallisuutta muuttavia/lisääviä ominaisuuksia.

Pikakorjauksia (hotfix) voidaan toimittaa tuotantoon nopeammalla aikataululla.

Sovelluspalvelinten versiopäivitykset

Sovelluspalvelinten versiopäivitykset tulee tehdä ainoastaan asiakkaan ja palveluntuottajan yhteisellä päätöksellä hyvin perustelluista syistä. Ennen päivitystä tulee selvittää päivityksen vaikutukset sovellukseen tai alustaan ja mahdollisten vaikutusten aiheuttama lisätyö- ja kustannusvaikutus.

Voit kuvata versiointipolitiikkaa tarkemmin tai lisätä linkin kuvaukseen asiasta.

Palvelun raportointi

Palveluntuottaja raportoi asiakkaalle merkittävistä palvelutasojen häiriöistä, merkittävistä palvelua koskevista muutoksista ja kehittämistarpeista sekä saatavilla olevista päivityksistä. Palveluntuottaja viestittää asiakkaalle myös ilman aiheetonta viivästystä, jos sen tietoon tulee tietoturva-aukkoja sovelluksessa tai sen osissa.

Palveluntuottaja raportoi asiakkaalle palvelutasossa pysymisestä kuukausittain/kvartaaleittain.

Säännöllisesti raportoitavia asioita voivat olla mm.:

Toteutunut saatavuus % (taulukko)
- Raportointijaksolla
- Edellisen 11kk:n saatavuudet
Listaus raportointikuukauden käyttökatkoista: kesto + selite
Vikojen kappalemäärät prioriteeteittain (taulukko)
- Raportointijaksolla
- Edelliset 11kk
Listaus avoimista vioista raportointihetkellä
- ID
- Prioriteetti
- Otsikko
- Tila
Listaus raportointijakson aikana suljetuista häiriöistä
- ID
- Prioriteetti
- Otsikko
- Reagointiaika
- Ratkaisuaika

Mikäli toimittaja muuttaa tilaajan määrittelemää vikailmoituksen prioriteettia, tulee raportista löytyä alkuperäinen prioriteetti ja perustelu muutokselle.

Mikäli toimittaja toteaa tilaajan vikailmoituksen perusteettomaksi, tulee vikailmoituksen löytyä tästäkin huolimatta raportilta – esimerkiksi tilassa peruttu.

Viestintä

Asiakkaan täytyy viestiä palveluntuottajalle olennaisista toimintaympäristönsä muutoksista ja erityistilanteista. Asiakkaan tulee myös ilmoittaa palveluntuottajalle hyvissä ajoin yhteyshenkilöidensä ja/tai toimintaansa koskevan lainsäädännön muutoksista. Ilmoitukset tehdään palveluntuottajan nimeämälle henkilölle. Samoin palveluntuottaja viestii huoltokatkoista etukäteen asiakkaan nimetylle henkilölle.

Kirjaa tähän tarkemmin tämän palvelun viestintään liittyvistä käytännöistä.

Ylläpitopalaverit

Palveluntuottaja ja asiakas tapaavat säännöllisesti pidettävissä ylläpitopalavereissa. Palveluntuottajalta ja asiakkaalta palaveriin osallistuu nimetty tai nimetyt henkilö(t) (ks. kpl 5).

Tapaamisessa käsitellään myös seuraavia asioita:

korjaavien ylläpitotehtävien tilannekatsaus ja raportit
tulevien ylläpitotehtävien läpikäynti
resurssivaraukset ja varamiesjärjestelyt
uusien versioiden hyväksyminen
laskutusasiat
muut palveluun liittyvät ajankohtaiset asiat

Asiakastyytyväisyys

Myös asiakastyytyväisyys voidaan mitata säännöllisesti ja siten voidaan määritellä SLAssa. Jos asiakastyytyväisyyttä halutaan mitata, täytyy määritellä miten palautetta kerätä, miten usein, keneltä, mikä on arviointiasteikko ja missä yhteydessä ja miten ne käsitellään. Asiakastyytyväisyys voidaan myös sanktioida.

Kirjaa tähän asiakastyytyväisyyteen liittyvät käytännöt.

Organisaatio

Palveluorganisaatio voidaan kirjata tähän dokumenttiin mutta siinä on riskinä, että tieto ei pysy ajan tasalla palvelun elinkaaren aikana. Näin ollen rooleihin nimetyt henkilöt pitäisi kirjata erilliseen paikkaan, jota ylläpidetään jatkuvasti, kuten esim. Tietojärjestelmäsalkkuun. Organisaatio voidaan kuvata myös jossain muussa dokumentissa (esim. erillisessä palvelukuvauksessa) johon tässä dokumentissa kannattaa viitata, jos sellainen on erikseen tehtynä.

Palveluntuottajan organisaatio

Kirjaa alle palveluntuottajan yhteyshenkilöiden tiedot. Roolien nimitykset voivat vaihdella tai kaikkia alla olevia ei ole välttämättä nimetty.

Palvelusta/järjestelmästä vastaa palvelupäällikkö xxx.

Järjestelmän/palvelun teknisenä asiantuntijana toimii xxx.

Järjestelmän/palvelun tuoteomistajana toimii xxx.

Palvelupisteen yhteystiedot (ks. 3.1)

Asiakkaan organisaatio

Kirjaa alle asiakkaan yhteyshenkilöiden tiedot. Roolien nimitykset voivat vaihdella tai kaikkia alla olevia ei ole välttämättä nimetty.

Järjestelmän/palvelun (liiketoiminta)omistaja: xxx. (vrt. Hel järjestelmäsalkku)

Asiakkaan palvelupäällikkö: xxx.

Asiakkaan tekninen vastuuhenkilö / pääkäyttäjä: xxx. (vrt. Hel järjestelmäsalkku)

Vastuunjako

Jos tätä dokumenttia käytetään kilpailutuksen pohjana, on tärkeää varmistaa, että seuraavat kohdat vastaavat sitä mitä ollaan hankkimassa ja sisältö vastaa hankinnan kohdetta.

Palveluun liittyvät roolit

Tarkista, että roolit sopivat ko. palveluun.

Asiakas

Rooli	Tehtävät ja vastuut
Tuoteomistaja	Hyväksyy suunnitelmat ja tuotantoon vietävät kokonaisuudet. Huolehtii ylläpidolle ja kehitykselle annettujen tavoitteiden toteutumisesta asiakkaan näkökulmasta. Toimii yhteyshenkilönä asiakkaan puolella.
Kehityksessä mukana olevat henkilöt	Henkilöt, jotka ovat mukana määrittelemässä ja testaamassa kehityksessä olevia asioita ja ovat palveluntuottajan kanssa palavereissa tarpeen mukaan.
Asiakkaan ensimmäisen tason tuki	Xxxxxx tuotantojärjestelmän toimivuudesta, häiriötilanteiden hallinnasta ja tekee tukipyynnöt vioista palveluportaaliin ja ottaa yhteyttä palveluntuottajaan tarvittaessa.

Palveluntuottaja

Rooli	Tehtävät ja vastuut
Palvelupäällikkö	Xxxxxxxxx palveluntuottajan jatkuvia palveluita asiakkaan järjestelmän osalta. Valvoo ja koordinoi ylläpitotiimin toimintaa. Huolehtii laskutusasioista sekä palvelun tuen ja henkilöresurssien tarpeesta. Huolehtii asiakkaan vuosikellon toteutumisesta ja tukee asiakasta toiminnassaan. Toimii yhteyshenkilönä sopimus- ja kehitysasioissa.
Pääarkkitehti	Xxxxxx sovelluksen laadusta ja jatkuvasta kehittämisestä teknisestä näkökulmasta. Vastaa arkkitehtuurisuunnittelusta ja teknisistä ratkaisuista. Toimii ylläpitotiimin tukena.
Palvelupiste	Xxxxx vastaan tukipyynnöt ja seuraa ja koordinoi niihin vastaamista ja sitä kautta ylläpitotiimin toimintaa. Huolehtii palvelun raportoinnista.
Palvelun/järjestelmän ylläpitotiimi	Huolehtii ylläpidosta ja kehityksestä. Valmistelee tuotantoon vietävät kokonaisuudet (ohjeet, ohjelmiston, datansiirrot, yms.). Huolehtii dokumentoinnin päivittämisestä. Antaa opastusta ja neuvontaa asiakkaalle. Xxxxxxxxx lisäksi muista tehtäväerittelyssä mainituista tehtävistä.

Palvelupyynnön vastaanottaminen ja siihen liittyvät toiminnot

Tarkista, että RACI sopii ko. palveluun

R= Responsible, vastuullinen (osallistuu tehtävän suorittamiseen)
A= Accountable, vastuussa oleva (vastaa, että tehtävä tulee suoritetuksi)
C= Consulted, konsultointi
I= Informed, informointi

Palvelupyyntö	Asiakas	Palvelupiste	Tekninen asiantuntija	Palvelupäällikkö
Havainto	R	R	R/I	A
Vastaanotto	I	A	I	I
Luokittelu	C	A	I	I
Kirjaaminen, jos tulee puhelimella	I	A	I	I
Tutkinta ja diagnosointi	C	R	R	A
Ratkaisu	I	R	R	A
Testaus ja sulkeminen	R, C	A	I	R
Seuranta, jäljittäminen ja kommunikointi	I	A	I, R	I, R
Asiakkaan opastaminen palvelun käytäntöihin	I	R	I	A
Kuukausiraportointi	I	A	C	R
Käytäntöjen parantaminen	I, C	I, C	I, C	A

Osaamisen ylläpito ja varahenkilöjärjestelyt

Palveluntuottaja ylläpitää henkilöstössään palvelun tukeen ja ylläpitoon tarvittavaa osaamista ja resursseja. Tämä tapahtuu henkilökunnan koulutuksella sekä velvoittamalla ylläpitoon osallistuvat asiantuntijat seuraamaan palvelun piirissä olevien varus-, tuki- ja valmis-ohjelmistojen ohjelmistopäivityksiä sekä teknologiauudistuksia.

Palveluntuottaja huolehtii riittävistä varahenkilöjärjestelyistä ylläpidon ja jatkokehityksen aikana. Ennen ylläpidon alkua nimetään ylläpitäjät ja heidän varamiehensä sekä tuotetaan varamiesjärjestelysuunnitelma.

Uuden henkilön siirtyessä palveluntuottajan ylläpitoprojektiin hänen kanssaan käydään läpi mm. palvelun visio, tarkoitus ja erityispiirteet, palvelun nykytila ja seuraavat tapahtumat, käytössä oleva arkkitehtuuri ja teknologiat, dokumentaatio sekä prosessimalli. Koulutuksessa hyödynnetään mestari-oppipoika-tekniikkaa, jossa uusi henkilö seuraa aluksi palveluntuottajan kokeneemman tekijän työtä.

Sanktiot

Vaaditusta palvelutasosta poikkeaminen voi johtaa sanktioihin, joten ne täytyy myös määritellä palvelutasosopimuksessa. Alla olevat sanktiot ovat JHS 174:n liitteestä 1 mukailtuja esimerkkejä ja niistä pitää erikseen sopia palveluntuottajan kanssa. Sanktioiden osalta täytyy huomioida se, että samasta virheestä johtuvat sanktiot voivat kumuloitua, jos näin sovitaan ja jos sanktiot kumuloituvat voi sanktioiden yhteenlaskettu määrä nousta yli 100% palvelun kuukausimaksusta. Riippuen palvelusta sekä kumuloitavuus ja kokonaissanktion nousu yli 100% voivat olla mahdollisia tai tätä voidaan rajoittaa palveluntuottajan kanssa siten, että maksimisanktio on 100% ja jos sama virhe johtaisi sanktioihin useassa eri kategoriassa, niin ainoastaan suurin huomioidaan.

Muuta alla oleviin taulukoihin palvelutuottajan kanssa sovitut sanktiot. Huomioi eri rakenneosien mahdolliset erilaiset palveluajat ja palvelutasotavoitteet.

Reagointiaika (response time)

Mikäli palveluntuottaja ei aloita häiriön korjaustoimenpiteitä tai tapahtuman käsittelyä sovitun reagointiajan puitteissa, asiakas on oikeutettu seuraaviin hyvityksiin:

Reagointiajan täyttyminen	Hyvitys % ko. kohteen kuukausimaksusta
Vähintään 95 % häiriöistä reagoitu tavoiteajassa	0 %
Vähintään 85 %, mutta alle 95 % häiriöistä reagoitu tavoiteajassa	10 %
Vähintään 75 %, mutta alle 85 % häiriöistä reagoitu tavoiteajassa	20 %
Vähintään 65 %, mutta alle 75 % häiriöistä reagoitu tavoiteajassa	30 %
Alle 65 % häiriöistä reagoitu tavoiteajassa	40 %

Reagointiajan täyttymisen laskentakaava on seuraava (JHS 174 liite 1, kappale 5.2.3 palveluvaste):

V = (Tvm) / Vm * 100 %

Tvm, Tavoiteajassa (reagointi) palveluaikana käsiteltyjen häiriötilanteiden määrä tarkastelujaksolla.

Vm, Häiriötilanteiden kokonaismäärä palveluaikana tarkastelujaksolla.

Palvelun saatavuus (availability)

Saatavuuden poikkeamat sanktioidaan seuraavasti:

Saatavuustavoitteen alitus	=	Hyvitys % kyseisen kohteen kuukausimaksusta
Yli 0,01 %, mutta enintään 0,24 %-yksikköä	=	10 %
Yli 0,24 %, mutta enintään 0,5 %-yksikköä	=	20 %
Yli 0,5 %, mutta enintään 1 %-yksikköä	=	30 %
Yli 1 %, mutta enintään 2 %-yksikköä	=	40 %
Yli 2 %-yksikköä (saatavuus kuitenkin vähintään 90%)	=	50 %

Jos saatavuus laskee alle 90%, ei kyseisen palvelun kuukausimaksua peritä lainkaan (hyvitys on 100%).

Maksimikatkon ylitys % tavoitetasosta	=	Hyvitys % kyseisen kohteen kuukausimaksusta
Yli 0,1 %, mutta enintään 20%	=	10 %
Yli 20 %, mutta enintään 50 %	=	20 %
Yli 50 %, mutta enintään 100 %	=	30 %
Yli 100 %	=	40 %

Etukäteen sovitut huoltokatkot täytyy myös suorittaa sovitussa ajassa. Jos tämä aika joudutaan palveluntuottajasta johtuvasta syystä ylittämään, on asiakas oikeutettu x% hyvitykseen kuukausimaksusta.

Jos suorituskykymittarina käytetään katkojen max. lukumäärää, voidaan myös se sanktioida. Kirjaa tähän sanktio katkojen maksimimäärän ylittyessä.

Häiriöiden ja palvelupyyntöjen ratkaisukyky

Tässä on määritelty kappaleen 3.6 kuvattujen tavoitteiden (ensimmäisen kontaktin ja ensimmäisen kerran ratkaisukyvyt) poikkeamat ja niistä seuraavat sanktiot.

Ratkaisukykytavoitteen alitus	=	Hyvitys % ko. kohteen kuukausimaksusta
Ratkaisukykytavoite alittuu yli 0,1, mutta enintään 10%-yksikköä	=	10 %
Ratkaisukykytavoite alittuu yli 10, mutta enintään 20%-yksikköä	=	20 %
Ratkaisukykytavoite alittuu yli 20, mutta enintään 30 %-yksikköä	=	30 %
Ratkaisukykytavoite alittuu yli 30 %-yksikköä	=	40 %

Häiriöiden ja palvelupyyntöjen palveluvaste

Tässä on määritelty kappaleen 3.7 kuvattujen palveluvastetavoitteiden (=palvelupyyntöjen/häiriöiden ratkaisu SLA-tavoiteajassa) poikkeamat ja niistä seuraavat sanktiot.

Palveluvastetavoitteen alitus	=	Hyvitys % ko. kohteen kuukausimaksusta
Palveluvastetavoite alittuu yli 0,1, mutta enintään 10 %-yksikköä	=	10 %
Palveluvastetavoite alittuu yli 10, mutta enintään 20 %-yksikköä	=	20 %
Palveluvastetavoite alittuu yli 20, mutta enintään 30 %-yksikköä	=	30 %
Palveluvastetavoite alittuu yli 30 %-yksikköä	=	40 %

Varmuuskopiointi

Varmuuskopiointia (ks. 3.9) voidaan sanktioida määrittelemällä hyvitys epäonnistuneista varmuuskopioista. Mittarina on varmuuskopioiden lukumäärä ajanjaksolla vs. epäonnistuneiden varmuuskopioiden määrä.

Sanktiorajat määräytyvät esim. seuraavasti:

Epäonnistuneiden varmistusten lukumäärä kuukaudessa	hyvitys kuukausimaksusta
5-7 varmistusta /kk	50 %
8 tai useampi varmistus /kk	100 %
2-3 peräkkäistä varmistusta	50 %
4 peräkkäistä varmistusta	100 %

Asiakastyytyväisyys

Myös asiakastyytyväisyys voidaan sanktioida. Asiakastyytyväisyys määritellään kappaleessa 4.8 ja alla olevan täytyy olla linjassa sen kanssa erityisesti arvosana-asteikon osalta. Alla olevan sanktiointi on esimerkki JHS 174:stä.

Mikäli tätä asiakastyytyväisyyden sanktiointia käytetään, asiakas ja toimittaja sopivat erikseen koko palveluyhteistyön kokonaisarvoon perustuvan maksimisumman (€) erikseen sekä asiakastyytyväisyyden että käyttäjätyytyväisyyden maksimisanktiolle.

Mikäli palveluntuottaja ei saavuta asiakkaan määrittämää asiakas- tai käyttäjätyytyväisyystavoitetta, asiakas on oikeutettu seuraaviin hyvityksiin sekä asiakastyytyväisyydestä että käyttäjätyytyväisyydestä erikseen:

Toteutunut tyytyväisyys – tavoitetaso	Hyvitys % tyytyväisyyden maksimisanktiosta
> 0,5 (tavoitetaso ylittynyt)	Bonus: 50 %
-1 – 0	Sanktio: 50 %
-1 – 2	Sanktio: 75 %
< -2	Sanktio: 100 %

Mikäli tavoitetaso saavutetaan tai ylitetään alle 0,5 yksikköä kouluarvosana-asteikolla (4-10), tällöin ei makseta bonuksia eikä sanktioita.

Document Metadata

Table of Contents

VERSIOHISTORIA

Muutospyyntöjen (request for change) käsittely

Palvelun/sovelluksen versiopäivitykset

Document Metadata