VERSIOHISTORIA
<Hankkeen tunnus ja nimi >
Palvelutasosopimus
Versio <nro>
<pp.kk.vvvv>
VERSIOHISTORIA
Päivä |
Versio |
Kuvaus |
Tekijä |
<pvm> |
0.1 |
Dokumentin perustaminen |
<etumini, sukunimi> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sisällysluettelo
2.5 Palvelun kriittisyyden/merkittävyyden arviointi 9
3.1 Palvelupiste (service desk) 11
3.1.1 Reagointiaika (response time) 11
3.2 Palveluaika (service hours) 12
3.3 Palvelun saatavuus (availability) 13
3.4 Ratkaisuajat häiriöille (incident) 14
3.5 Ratkaisuajat palvelupyynnöille (service requests) 15
3.6 Häiriöiden ja palvelupyyntöjen ratkaisukyky 16
3.7 Häiriöiden ja palvelupyyntöjen palveluvaste 16
3.9 Jatkuvuudenhallinta (continuity management) 17
4 Palveluun liittyvät käytännöt 19
4.1 Häiriönhallinta (incident management) 19
4.2 Ongelmanhallinta (problem management) 19
4.3 Muutoksenhallinta (change management) 20
4.3.1 Muutospyyntöjen (request for change) käsittely 20
4.4.1 Palvelun/sovelluksen versiopäivitykset 20
4.4.2 Sovelluspalvelinten versiopäivitykset 20
5.1 Palveluntuottajan organisaatio 23
5.3.1 Palveluun liittyvät roolit 23
5.3.2 Palvelupyynnön vastaanottaminen ja siihen liittyvät toiminnot 24
5.4 Osaamisen ylläpito ja varahenkilöjärjestelyt 25
6.1 Reagointiaika (response time) 26
6.2 Palvelun saatavuus (availability) 26
6.3 Häiriöiden ja palvelupyyntöjen ratkaisukyky 27
6.4 Häiriöiden ja palvelupyyntöjen palveluvaste 27
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.
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.
|
|
|
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. |
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®) |
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 |
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) |
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®) |
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.
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
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?
Vastuunjako: mikä palveluntuottajan, mikä asiakkaan, mikä muiden toimijoiden vastuulla?
Luettele, mitä dokumentaatiota palveluntuottaja ylläpitää ja mistä se löytyy.
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 |
☐ |
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.
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.
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.
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 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
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
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ö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 %
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 %
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) 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 voidaan kuvata myös jossain muussa dokumentissa (esim. erillisessä palvelukuvauksessa) johon tässä dokumentissa kannattaa viitata, jos sellainen on erikseen tehtynä.
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.
Kuvaa tähän palvelun ja rakenneosien mahdollinen monitorointi.
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.
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.
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 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.
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.
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ä.
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
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.
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ä.
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)
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)
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.
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ä. |
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 |
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ä.
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.
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.
Saatavuuden poikkeamat sanktioidaan seuraavasti:
Saatavuustavoitteen alitus |
= |
Hyvitys
% kyseisen kohteen |
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 |
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ä.
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 |
= |
10 % |
Ratkaisukykytavoite
alittuu |
= |
20 % |
Ratkaisukykytavoite
alittuu |
= |
30 % |
Ratkaisukykytavoite
alittuu |
= |
40 % |
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 |
= |
10 % |
Palveluvastetavoite
alittuu |
= |
20 % |
Palveluvastetavoite
alittuu |
= |
30 % |
Palveluvastetavoite
alittuu |
= |
40 % |
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 % |
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.