Raportointi >> Perusraportti Palautepyyntö: IT palveluiden palvelutasoluokitus

Transkriptio

1 21761c39 (Valtiovarainministeriö), olet kirjautuneena sisään. 17. marraskuuta :24:00 Your boss is {0} Kirjaudu ulos Etusivu Kyselyt Raportointi Asetukset Käyttäjätiedot Ota yhteyttä Oppaat Help Päällä P Raportointi >> Perusraportti Palautepyyntö: IT palveluiden palvelutasoluokitus Vastaajien listaus Kopio e raporttiin Vie tulokset Exceliin Luo suodatus Kyselyn nimi Palautepyyntö IT palveluiden palvelutasoluokitus Kyselyn tekijä 21761c39 Kysely luotu :35:07 Vastaajien kokonaismäärä 19 Vastausajankohta :15:47 Kokonaisraportti 1. Organisaatio 1. Kiimingin kunta ( ) 2. Laihian kunta ( ) 3. Enonkosken kunta ( ) 4. JamIT Tieto Oy ( ) 5. Helsingin kaupunki ( ) 6. Oulun kaupunki, tietohallinto ( ) 7. Työ ja elinkeinoministeriö ( ) 8. Väestörekisterikeskus ( ) 9. Yksityishenkilö ( ) 10. Fujitsu Services Oy ( ) 11. Valtion IT palvelukeskus (Valtiokonttori) ( ) 12. Tampereen kaupunki ( ) 13. FiSMA ry ( ) 14. Kouvolan kaupunki ( ) 15. TeliaSonera Finland Oyj ( ) 16. Logica Suomi oy ( ) 17. Elisa Oyj ( ) 18. TDC Oy Finland ( ) 19. Ykstityishenkilö ( ) 2. Yleiskommentit 1. Oikein hyvä. Merkittäviä muutostarpeita ei esiintynyt. ( ) 2. Hyvä yleiskokonaisuus, joka otetaan ilolla vastaan Erittäin selkeä ja ymmärrettä. Pystytään hyödyntämään Muistettava, että palvelutasot ovat kompromisseja liiketoiminnan tarpeen ja palvelun hinta/laatusuhteen kesken. Kriittiset asiat aina arvioita / riskit. ( ) 3. Erittäin tarpeellinen dokumentti. Kiitokset työryhmälle. ( ) 4. Suositusluonnos on hyvä, selkeä ja hyvin laadittu kokonaisuus liitteineen. ( ) 5. SLA:t on määritelty pitkälti erilaisilla prosenttimäärillä, joiden yhteyttä tosielämään on vaikea hahmottaa. Tärkeintä tietysti on miten palvelu tai sen toimimattomuus näkyy käyttäjälle. SLA:t ja sanktiot voi usein esittää myös ihan yksinkertaisesti, esim. normaalina työaikana kalenterikuukaudessa jokaisesta tapahtuneesta yli tunnin katkoksesta hyvitetän 20 % kuukauden palvelumaksusta ja jos yli 10 minuutin katkoksia on viitenä päivänä kuukaudessa hyvitetään 100 % ja sopimus voidaan purkaa, jos käyttäjän havaitsemia katkoksia on peräkkiäisinä kuukausina yhteensä 10 kappaletta. Työasemapalveluiden osalta tärkeää on myös ServiceDesk palvelu ja siihen liittyvät odotusajat puhelinpalvelun osalta. En äkkiseltään huomannut tälle mittareita. Mittari voisi olla tyylliin, että 90 % puheluista pitää vastata alle 30 sekunnin kuluessa ja jokaisesta tuon 10 % yli menevästä puhelusta maksetaan sankiota 10 euroa. Eriytisesti kannattaa korostaa, että jos jotain sovitaan, sitä pitää myös pystyä mittaamaan ja sitää pitää mitata. ( ) 6. Varsinainen palautteemme toimitetaan sähköpostitse mennessä. Viitaten s postiin Kari Kyttälä/Pekka Niemi en täytä sähköistä palautetta tämän pidemmälle. ( ) 7. Suositus on tarpeellinen ja hyvin laadittu. Vahvistettu JHS suositus palvelutasoista vahvistaa julkishallinnon organisaatioiden asemaa sekä palveluja kilpailutettaessa että sopimuksista neuvoteltaessa, kuin myös vähentää työmäärää näissä työvaiheissa. Laajasti käytettynä suositus myös pidemmällä aikavälillä parantaa tietojärjestelmien ja palvelujen yhteentoimivuutta. ( ) 8. + Esimerkit ovat hyviä + Teksti on kirjoitettu mukavan käyttäjälähtöisesti + Ottaa kantaa kilpailuttamiseen + Kuvaa joissain tapauksissa eri toimijoiden (esim. tietohallinto) tehtäviä Ei ota kantaa SaaS/ASP palveluihin (pitäisi ehdottomasti olla mukana) Korkeasta käytettävyydestä voisi olla enemmänkin asiaa, vaikka oma kappaleensa Viittauksia liitteeseen voisi tekstissä lisätä Termejä ja määritelmiä voi olla enemmänki avattu omassa kappaleessaan Avoimen lähdekoodin mahdollisuuksia ei ole huomioitu ( ) 9. FiSMA ry:n yhtenä päätehtävänä on osallistua Suomen puolesta ISO/IEC JTC1 SC7 toimintaan. Sen puitteissa ei ole vielä käynnissä vastaavaa työtä kuin nyt lausunnolla oleva JHS suositus. Voidaan siis todeta, että Suomen julkishallinto on edelläkävijä tässä suhteessa, ja haluammekin välittää kiitoksemme sekä aihepiirissä tehdystä työstä että lausunnolla olevan standardin korkeasta laatutasosta. SC7 piirissä on käynnissä kaksi lausuntoa sivuavaa työkokonaisuutta: ISO/IEC standardin uudistustyö ja WG1A:ssa käynnisteillä oleva uusi standardoinnin työkohde SLA mittareista. ISO:n piiriss tehtävän SLA työn voi odottaa kestävän vielä ainakin kolme vuotta, ja vasta sitten voidaan todeta JHS suosituksen ja mahdollisen ISO standardin vastaavuus ja mahdolliset

2 keskinäiset ristiriitaisuudet. JTC1 tasolla on käynnissä ns Governance of IT standardointityö, ja siellä saattaa olla tulevaisuudessa muita SLA läheisiä työkohteita. Juuri tällä hetkellä niitä ei ole. Esitämme toivomuksen, että JHS suositus voitaisiin kääntää myös englanniksi ja se toimisi siten yhtenä lähtötietona ISO standardille. FiSMAn edustajat voivat toimia välikätenä ja osallistua tältä osin WG1A työryhmän toimintaan. Vielä parempi olisi, jos Suomi voisi nimetä siihen edustajaksi jonkin JHS standardia tuntevan henkilön. FiSMAssa toimii ISO/IEC standardin kansallinen ryhmä. Sen seuraava kokous on vasta Esittelemme suosituksen siellä ja mahdollisesti saamme jäseniltä lisää yksilöityjä kommentteja. Pyydämme tältä osin lisäaikaa asti lausunnon antamiseen. Korkeat käytettävyysvaatimukset edellyttävät korkean käytettävyyden ympäristöjä. Maininta tästä olisi hyvä, ts. korkeaa käytettävyyttä ei voi vaatia, mikäli asiakkaan ympäristö ei sitä tue. Ratkaisukyvyn sanktiointi käytännössä hankala asia toimittajille, lopputulos on asiakkaan manipuloitavissa. Palvelukokonaisuudella käytännössä erityisesti julkishallinnolla useita eri toimittajia. Yksittäisen toimittajan palvelutason mittaaminen / erottaminen kokonaispalvelutasosta haaste. Palveluaika kytketty palvelutasoon siten, että jos palveluaika on arkisin 8 16, niin korkein mahdollinen käytettävyys on 97% ja vasteaika 4h. Tästä seuraa, että 8 16 käytössä olevalle palvelimelle on käytännössä aina valittava esim. 24/7 palveluaika jotta saadaan tyydyttävä käytettävyys ja se vaikuttaa palvelun hintaan. Pitäisi paremmin erotella palvelun sisältö (mitä), palveluaika ja palvelun laatukriteerit. Termit ja määritelmät: Häiriö: Vikatilanne, negatiivinen sovitusta poikkeava teknologisen ratkaisun tai palvelun käyttäytyminen, joka haittaa olennaisesti sopimuksen mukaista käyttöä. Käytettävyys saatavuus: Saatavuutta ei ole määritelty käytettävyyden kanssa samassa kohdassa. Nämä voivat myös olla täysin eri asioita. Reagointiaika: Ratkaisun edellyttäminen ei kuulu reagointiajan määritelmään. Kaksi viimeistä lausetta määritelmästä tulisi poistaa ( ) 10. Tarpeellinen suositus, rakenne hyvä (suositus ja sille liite). Pohdittavaksi tarvitaanko termit, määritelmät osuudet molemmissa dokumenteissa. ( ) 11. Liitteen 1 Rakenne on aivan liian monimutkainen ja seuranta tulisi olemaan hankalaa. "Yksinkertainen on kaunista" eli liian monimutkaisen mallin rakentaminen ei palvelu kumpaakaan osapuolta. Ei toimittajaa, mutta ei myöskään tilaajaa, jonka vastuulle toteuman seuranta osin jää. Mielestäni ei kannattaisi väkisin yrittää täysin eriluonteisten palveluiden palvelutasoja yrittää yhdistää väksin. Jos/kun halutaan seurata kokonaispalvelutasoa, kannattaa ennemmin koittaa löytää muutama yhteinen KPI,joita seuraamalla saa hyvän käsityksen kokonaisuuden toiminnasta. Asia ja kirjoitusvirheitä on aika paljon. ( ) 12. Suositusdokumentin laatiminen on erittäin hyvä ajatus. On kuitenkin huomattava, että itse palvelusisällöistä ja palvelutasoista tulee sopia aina tapauskohtaisesti palvelutoimittajan kanssa, sillä yhdessä tapauksessa hyvin palveleva sopimuskokonaisuus ei välttämättä tee sitä muissa tapauksissa. ( ) 13. Mielestämme on erittäin hyvä, että on ryhdytty laatimaan suositusta, joka kuvaa julkisessa hallinnossa tehtävien ICTpalvelusopimuksien palvelutasojen ja laatukriteerien (SLA, Service level agreement) määrittelyä. Kiitämme mahdollisuudesta vastata palautepyyntöönne: IT palveluiden palvelutasot. Suositus on selvästi kirjoitettu ohjeeksi julkishallinnon organisaatioille ICT palvelujen hankkimiseen. Samalla se kuitenkin sisältää tarkkoja vaatimuksia, joita on mitä ilmeisimmin tarkoitus käyttää tarjouspyyntöjen osana. Näiden eri käyttötarkoitusten erottaminen on syytä tehdä siten, että ohjeet ja vaatimukset jaetaan eri dokumentteihin. Suositus on tarpeellinen ja hyödyllinen ohje ICT palveluiden hankkimiseen. Suosituksesta näkee, että sen koostamiseen on nähty paljon vaivaa ja siinä on haluttu ottaa huomioon useita ICT palveluiden osa alueita. Monipuolisuus tuottaa myös haasteen, koska suosituksessa on käsitelty hyvin eri tasoisia asioita. Viankorjauksen nopeuden, käyttäjätuen vastauskyvyn ja tietoliikenneyhteyden viiveiden sijoittaminen samaan tarkasteluun tuo haasteita ja voi rajata ostajalle tarjottavia palveluita siten, että ostajalle tarjotaan tarpeettoman kallista ratkaisua. Olemme Elisassa pitkäjänteisesti kehittäneet Elisan tarjoamien ja tuottamien palvelujen osalta SLA (palvelutaso) määrittelyjä sekä soveltaneet niitä asiakkaiden kanssa tehdyissä sopimuksissa. Elisa on jatkossa miellään mukana yhteistyössä, jossa nyt käsiteltävää suositusta kehitetään eteenpäin siten, että se on kaikkien toimittajien ja asiakkaiden hyväksyttävissä. Tässä yhteydessä on myös mahdollista asettaa tavoitteet kohtuulliselle tasolle ja tarkastella mitkä mitattavat asiat ovat ole olennaisia. Mielestämme on tärkeää, että määrittelyt perustuvat olemassa oleviin, laajasti kehitettyihin ja toimittajien vakioimiin toimintamalleihin. Tärkeää tässä Julkishallinnon SLA suosituksessa on huolehtia etenkin siitä, että palvelut ovat asiakkaiden käytettävissä ja katsoa asiaa asiakastarpeiden ja siihen sopivan käytetettävyyden näkökulmasta mutta ei määritetä toimittajan sisäisiä prosesseja uudelleen, vaan käytetään hyväksi toimittajan normaaleja prosesseja. Pidämme hyvänä suosituksen näkemystä bonuksien osalta. Toteamme, että vastaavasti myös sanktioiden osalta on tärkeää, että palvelutasotavoitteen asettaminen perustuu todelliseen tarpeeseen. Sanktioihin myöntyminen on toimittajan osalta osoitus siitä, että se sitoutuu tuottamaan asiakkaalle laadukasta palvelua. Sanktion tarkoitus on myös hyvittää asiakasta alentuneesta palvelutasosta. Sanktioiden tarkoitus ei missään tilanteessa ole tarkoitus olla ansaintakeino asiakkaalle tai keino saada palvelu merkittävästi pienemmällä hinnalla. Liitteen 1 kappaleessa 6 kuvattu sanktioiden laskentamalli on tarpeettoman monimutkainen sekä asiakkaalle että toimittajalle. Yhteenlaskettujen sanktioiden osuus ei saa olla liian suuri palvelun laskutuksesta koska tällöin sanktion merkitys loppukäyttäjän kokeman palvelun toimivuudesta poistuu ja nostavat palvelun hintaa. Ehdotamme, että sanktioinnin periaatteet ja käytännöt käydään erikseen läpi yhdessä suosituksen tekijöiden ja Elisan kesken. Kilpailutukset on tehtävä asiakkaan tarpeiden pohjalta. Yksityiskohtaisemmat palvelutasojen määrittelyt kilpailutuksen jälkeisessä sopimusneuvottelussa tehdään käyttäen hyväksi valitun toimittajan prosesseja ja palvelutasomäärittelyjä. Suositus nykyisessä muodossaan on varsin monimutkainen johtuen eri tasojen ja niiden yhdistelmien suuresta määrästä. Palvelutasoluokituksen luonne on itsessään monimutkainen ja siksi luokittelu on pidettävä mahdollismman yksinkertaisena. Monimutkainen malli lisää työtä sekä asiakkaalla että toimittajalla ja kasvattaa kustannuksia. Elisa ei ole ollut mukana valmistelemassa nyt lausuttavana olevaa luonnosta. Mielestämme jo ensimmäinen luonnos olisi pitänyt valmistella valtionhallinnon mahdollisten ICT toimittajien ja heidän käytössään olevien, valtionhallinnolle jo mahdollisesti tuotettavissa palveluissa käytettävien prosessi ja toimintamallien mukaisesti, eikä määritellä alalle kokonaan uusia malleja. Ehdotamme että antamiemme kommenttien ja muiden toimijoiden mahdollisten kommenttien pohjalta tehdään uusi luonnos ja se laitetaan uudelle kommentointikierrokselle. ( ) 3. Anna arviosi seuraavista suositusluonnokseen liittyvistä väitteistä asteikolla 1 5 (5 = samaa mieltä, 1 = eri mieltä) Kysymykseen vastanneet: 18 Suositus on tarpeellinen (ka: 4,611; yht: 18) Suositus on otettavissa käyttöön ilman tukea ja koulutusta (ka: 2,889; yht: 18) Suosituksen luettavuus ja ymmärrettävyys ovat hyvällä tasolla (ka: 3,5; yht: 18) ka: 3,667; yht: ,2% 13 11,1% 2 22,2% 4 35,2% 19 16,7% 3 22,2% 4 33,3% 6 24,1% 13 11,1% 2 27,8% 5 22,2% 4 20,4% 11 0% 0 22,2% 4 16,7% 3 13% 7 0% 0 16,7% 3 5,6% 1 7,4% 4

3 4. Suositusluonnoksen hyväksyminen Kysymykseen vastanneet: 19 (ka: 2,3) (4.1) Hyväksytään ilman muutosehdotuksia 5,3% 1 (4.2) Hyväksytään, oheisilla muutosehdotuksilla 68,4% 13 (4.3) Ei kantaa 21,1% 4 (4.4) Vastustetaan (perusteltava) 5,3% 1 5. Vastustusperusteet 1. Dokumentissa "JHS XXX IT palveluiden palvelutasoluokitus" kohdassa "Tietoliikenteen peruspalvelut" ovat käytetyt palvelutasoluokat (P1K1V1) lähes suoraan Elisa Oyj:n palvelukuvauksesta, ainoastaan käytetyt tunnit palveluajoissa, käytettävyydessä jne. ovat erilaisia kuin tämän hetken palvelukuvauksissa. Tämä tarkoittaa että heidän on helpointa ja kustannustehokkainta siirtyä käyttämään määriteltyjä palvelutasoluokkia verrattuna muihin tietoliikennepalvelujen tarjoajiin. ( ) 6. Yleiset muutosehdotukset 1. SAAS tulisi näkyä selvemmin. Julkishallinnossa on selvästi SAAS nostanut päätänsä viime vuosina. Suosituksesta voisi ymmärtää, että se on tukipalvelu+käyttöpalvelu. Onko suositus liiaksi hardware/perustietotekniikka painottunut? ( ) 2. Oikolukuohjelman käyttö suositeltavaa. :) Palvelukuvausten lisäksi sopimukseen kannattaa ottaa mukaan liite, joka määrittelee, miten/millä tavalla/millä välineillä laatumittareita mitataan. ( ) 3. SaaS/ASP palvelut pitäisi olla ehdottomasti mukana. Sovellusten käyttöpalvelujen hankinta pitäisi myös sisällyttää, tämä siis riippumaton siitä toimiiko palvelimet. Palvelin pystyssö on eri asia kuin sovellus pystyssä. Jos näitä tullaan käyttämään käyttämään yleisinä tarjouspyyntöjen liitteinä, yleiset palvelutasovaateet vaikuttavat olevan toimittajan näkökulmasta liian edullisia (esim. työaseman toimitusaika) Ei haukuta avointa lähdekoodia vaan paremminkin korostettaisiin sen kautta saatavia mahdollisuuksia (esim. että ennen hankintaa kannattaa selvittää voisiko tarjouksia olla mahdollista saada näistä rataksuista hankintalain puitteissa tietenkin) Tulisi korostaa sitä, että asiakkaan velvollisuus on määritellä tarpeensa (esim. palveluluokat). Muuten vaikkapa tarjousten vertailu tasapuolisesti voi käydä mahdottomaksi. ( ) 4. ermit ja määritelmät: Häiriö: Vikatilanne, negatiivinen sovitusta poikkeava teknologisen ratkaisun tai palvelun käyttäytyminen, joka haittaa olennaisesti sopimuksen mukaista käyttöä. Käytettävyys saatavuus: Saatavuutta ei ole määritelty käytettävyyden kanssa samassa kohdassa. Nämä voivat myös olla täysin eri asioita. Reagointiaika: Ratkaisun edellyttäminen ei kuulu reagointiajan määritelmään. Kaksi viimeistä lausetta määritelmästä tulisi poistaa ( ) 5. Ehdotamme suosituksen jakamista kahteen erilliseen dokumenttiin koska dokumentti sisältää sekä yleisempää ohjeistusta ICTpalvelujen hankintaan sekä selviä hankintavaatimuksia. Ohjeistuksen ja vaatimusten eriyttäminen eri dokumentteihin selkeyttää suosituksen käyttöä ja helpottaa tarjouspyyntöjen tekoa sekä niihin vastaamista. Elisa on mielellään mukana dokumentin kehittämisessä tavoitteena että se vastaa sekä asiakkaiden että toimittajien tarpeisiin. ( ) 6. On vähintäänkin kyseenalaista käyttää tällaisten määritysten / palvelutasojen määrittelyihin sellaista ulkopuolista jäsentä, joka työskentelee yrityksessä joka tekee juuri tämänkaltaisia kilpailutuksia julkishallinnolle. Ainoastaan siinä tapauksessa se on hyväksyttävää että kyseinen henkilö, ja yritys jossa hän työskentelee, eivät osallistu tulevina vuosina kyseisenlaisiin julkishallinon kilpailutuksiin laisinkaan. Eli heidän tulee jäävätä itsensä mainitunlaisista kilpailutuksista. Muuten kyseinen yritys ja henkilö voidaan katsoa mahdollisesti saavan suositummuus aseman tulevissa kilpailutukissa. ( ) 7. Muutosehdotukset kappaleeseen 1. Johdanto 2. Koko dokumentissa on mielestämme perusteltua käyttää IT lyhenteen sijasta lyhennettä ICT palvelut, joka on alalla yleisesti käytössä oleva lyhenne ja kuvaa paremmin sitä aluetta, johon dokumenttia on ajateltu sovellettavan. Yhdenmukainen terminologia on erityisen tärkeä dokumentissa jota käytetään osana hankintavaatimuksia. ( )

4 8. Muutosehdotukset kappaleeseen 2. Soveltamisala 1. myös SAAS huomioitava meillä on ollut vasteaika käsite, mutta reagointiaika on parempi ja kuvaavampi ratkaisuaikoihin liittyy tyypillisesti % eli toimittajat tuskin haluavat 100% kaikista itse olemme ajatelleet 80% aluksi. ratkaisuaika alkaa juoksemaan vasta kun reagoitu? Voisi tarkentaa: reagointiaika + ratkaisuaika=jotain vasteajan puitteissa luki jossain vasteajan määrite puuttuu? ( ) 2. Ei muutostarpeita ( ) 3. Lause "Perusajatuksena on se,..." ei aukea. Koko selvitys bonuskäytännöstä on hiukan vaikeasti ymmärrettävä. ( ) 9. Muutosehdotukset kappaleeseen 3. Termit ja määritelmät 2. Palvelutasotavoite: parempi termi voisi olla esimerkiksi sovittu palvelutaso. Tavoite ei vaikuta niin sitovalta, kuin sovitun palvelutason tulee olla. Reagointiaika: Kappaleen kaksi viimeistä virkettä sekoittavat termin määritelmän, ne on paras poistaa. Ratkaisuaika/palveluvaste on määritelty ylempänä. Poistettavassa virkkeessä puhutaan vasteajasta, joka sanana ei välttämättä ole sama kuin palveluvaste. Molemmilla voidaan tosin tarkoittaa reagointiajan ja ratkaisuajan summaa. Nämä tulee aina määritellä erikseen. ( ) 3. Kohdan 2 termit pitäisi olla selvitetty tässä ja esim. jatkuva palvelu, asiantuntijaplavelu, SaaS jne. Ratkaisuajan, reagointiajan ja toimitusajan sisältöä tulisi täsmentää ja niiden keskinäistä riippuvuutta selventää. ( ) 4. Termit ja määritelmät suositusluonnokseen ja liitteessä viittaus suositukseen. ( ) 5. Häiriö termi on muutettava termiksi Vika. Häiriö mielletään hetkelliseksi ja se korjautuu itsestään. Vika vaatii aktiiviisia korjaustoimenpiteitä jotta vika korjautuu. Häiriön kriittisyysluokka muutettava termiksi Vian kriittisyysluokka. Palveluaika kohtaan tarkennusta. Palveluaika termiä voidaan soveltaa moniin erilaisiin kohteisiin. Yleiskäsitteenä määritelmä on hyvä mutta tyypillisesti tietoliikennepalveluissa itse palvelua tuotetaan 24/7 vuoden jokaisena päivänä. Suppeampaa palveluaikaa tyypillisesti sovelletaan esim. helpdesk tyyppiseen toimintaan ja viankorjaukseen. Reagointiaika termin määritelmä seuraavaksi: 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. Synonyymi: vasteaika. Lisäksi täytyy määritellä termi Korjausaika: Aika, jonka kuluessa häiriö on korjattu ja on palauduttu normaaliin tilaan. Yksi määritelmä on kohdassa 5.1. taulukossa mainittu Ratkaisuaika. SLR kohtaan: IT palvelutasot sovitetaan palvelutasotarpeisiin siten että palvelutasovaatimukset tai tarpeet täytetään, ei niin että IT palvelutasot muokattaisiin palvelutastotarpeiden mukaiseksi. ( ) 6. Yleisesti Ratkaisukyvyn mittaamisesta: Palvelupisteen edellytykset palvelupyynnön ratkaisemiseksi ovat riippuvaisia paitsi palvelupisteen resurssien laadullisesta ja määrällisestä allokoinnista, mutta myös asiakkaalta saatavien lähtötietojen selkeýdestä ja laadusta. Ratkaisukyvyn mittaaminen esitetyllä mallilla voi johtaa tilanteeseen, jossa toimittajat edellyttävät laadullisesti ja määrällisesti tarkempaa informaatiota suoritettavasta palvelupyynnöstä ennen kuin hyväksyvät palvelupyynnön ns. kirjattavaksi järjestelmiin. Ratkaisukyvyn mittaaminen esitetyllä mallilla voi johtaa tilanteeseen, jossa palvelupyyntöjen tekeminen edellyttää loppukäyttäjältä aikaisempaa yksityiskohtaisempia lähtötietoja, ja tällä tavalla hankaloittaa ns. tavallisen loppukäyttäjän mahdollisuuksia saada palvelupyyntöjään toteutetuksi. TDC:n näkemyksen mukaan, ratkaisukyky ohjeituksen mukaisena mittarina toimii loppukäyttäjille rakennettuun helpdesk palveluihin. Tietoliikennettä koskevien vikatilanteiden, esim laitteiden hajoaminen tai linjakatkojen korjaaminen ei pystytä vertaamaan samalla mittaristolla. ( ) 10. Muutosehdotukset kappaleeseen 4.Palvelutasoluokituksen taustalla olevat viitekehykset 11. Muutosehdotukset kappaleeseen 4.1 Palvelutasonhallinta yleisesti 2. ITIL, ISO/IEC ja Cobit sinänsä ovat epäilemättä laadukkaita käytäntöjä ja standardeja, mutta niiden implementointi osaksi palveluita ja tarjouksia voi (hankinnan laajuudesta ja toimitettavasta kokonaisuudesta riippuen) aiheuttaa huomattaviakin kustannuksia. Ko. käytännöt voivat olla vieraita myös ainakin osalle pienimpiä julkisia hankintayksiköitä. Em. standardien ja käytäntöjen vaatiminen voivat ns. muodostaa markkinoille pääsyn esteen ja käytännössä rajoittaa esimerkiksi paikallisten toimijoiden mahdollisuuksia osallistua hankintamenettelyihin. ( )

5 12. Muutosehdotukset kappaleeseen 4.2 ITIL 2. Miksi toinen kuva on suomeksi ja toinen englanniksi? Molemmat suomeksi kiitos. ( ) 3. ITIL versio 3 on osittain epäonnistunut ja siitä on tullut tarpeettoman monimutkainen. Tästä syystä viittaukset ITIL versioon 3 on syytä poistaa dokumentista. Palvelutasoluokituksen periaatteita ohjaavat prosessit on poistettava dokumentista tai viitattava ITIL mallin versioon 2. ( ) 13. Muutosehdotukset kappaleeseen 4.2 ISO/IEC Lause "Koska standardi pitää sisällään..." lauseen lopussa jonkinlainen ajatuksen sekaannus? ( ) 3. On suositeltavaa ottaa Palveluhallinnan viitekehysmalliksi ISO/IEC standardi, jossa on kaikki ITIL versio 2 prosessit mukana, ja joka ottaa kantaa nimenomaan laadun mittaukseen ja sen jatkuvaan parantamiseen. ( ) 14. Muutosehdotukset kappaleeseen 4.4 Cobit 2. Dokumentissa ei mitenkään erikseen korosteta, että mahdollisesti sertifioitavan palvelun tulee olla kaikilta osiltaan toimittajan hallinnoima ts. tilaajan pitäessä jotain osia vaikkapa muutoksenhallinnasta itsellään, sertfiointia ei voida tehdä. Tämä tulisi nimenomaan julkisen palvelun yhteydessä näkyä. ( ) 3. Cobitia olisi voinut avata enemmän, koska Cobit tukee tilaajan prosesseja ja tietyissä tapauksissa kokonaisvastuu palvelutuotannosta voi jäädä tilaajalle (usean tahon tuottamat palvelut). ( ) 4. Cobit mallia tulisi hyödyntää soveltuvin osin, esim. prosessien kypsyyden mittauksessa ja IT Governance määrittämisessä. Cobit tulisi sisällyttää soveltuvin osin suosituksiin. Cobit analyysiä (liiketoiminnan asettamien vaatimusten edellyttämien tavoitteiden liittämistä ICT tavoitteisiin) ei voida edellyttää toimittajalta, vaan se voidaan tehdä erillisenä, tilattuna työnä. ( ) 15. Muutosehdotukset kappaleeseen 5. Laatumääreiden ja palvelutasojen yleisjäsennys 2. Käytettävyys saatavuus Maksimireagointiaika => tavoitereagointiaika Ratkaisukyky: Tämä on varsin ongelmallinen termi. Palvelupyyntöjä vastaanottava taho ei välttämättä ole sama kuin se, joka on vastuussa palvelusta. Aina ongelma ei ole ratkaistavissa neuvonnan välityksellä, jolloin tämä alentaisi ratkaisuprosenttia. Asiantuntijoiden sitouttaminen ja sopimussakko 5000 /nimetty henkilö on kohtuuton. Toimittaja vastaa ja huolehtii keskeisten roolien osalta riittävästä osaamisen kasvattamisesta ja ylläpidosta varahenkilöjärjestelyineen. ITIL:n mukaiset prosessit ovat yksittäisistä henkilöistä riippumattomia. ( )

6 16. Muutosehdotukset kappaleeseen 5.1 IT palvelujen laatu: laatumääreet, prosessimittarit 1. Palveluaika: Ei saa jäädä väärinkäsitystä, että palveluaikana vastaukseksi riittää autamaatti vastaussähköposti. Palveluaikaan myös reagoidaan. Miten tavoitettavuus kytketään tähän? ( ) 2. Ei muutostarpeita ( ) 3. Maksimikatkon määritelmässä on suluissa (tyypillisesti yksi kuukausi). Lauseesta voi syntyä virheellinen käsitys, että tyypillisesti pisin yhtäjaksoinen sallittu käyttökatko on yksi kuukausi, kun tekstissä tarkoitetaan, että tarkasteluväli on tyypillisesti kuukausi. Virheellisen mielikuvan välttämiseksi lauseen voisi muotoilla toisin. Katkojen maksimimäärä on määritelty katkojen lukumääräksi. Yhtä hyvin sillä voidaan tarkoittaa katkojen ajallisen kestojen summaa. ( ) 4. Lause "Puhtaasti subjektiivinen..." on epäselvä sisällöltään. ( ) 5. IT palvelujen laatu ei sinänsä ole hankalasti määriteltävä asia. Hankalaa on ainoastaan löytää yhdessä Asiakkaan ja IT toimittajan kesken mittarit, jotka ovat laadun arvioinnin kannalta keskeisiä. Käyttäjätyytyväisyys luonnollisesti on tunneohjautuva mittari, mutta palvelujen kehittämisen kannalta tyypillisesti tärkeä. IT järjestelmien end to end tyyppinen käytettävyyslaatu, sekä muut vastaavat absoluuttisesti laskettavissa olevat laatumittarit ovat palvelutason arvioinnin kannalta tärkeimmät. On kuitenkin tärkeää ymmärtää, että mittaamisen ilosta ei mitään kannata mitata, vaan aidosti merkittävät mittarit on tunnistettava. ( ) 6. Lisättävä määritelmä tiedon laadusta. ICT palvelujen toimittajan toimittaman palvelun laatu on hyvin suuresti riippuvainen asiakkaalta saatujen lähtötietojen laadusta ja oikeellisuudesta. Asiakkaan toimittamien tietojen osalta on vastuu oikeellisuudesta on selkeästi asiakkaalla. Laatumääreisiin on lisättävä myös asiakkaan odotukset laadun suhteen. Kuvan 3 sivulla 8 rooli jää epäselväksi, sitä on syytä selventää tai mainita selkeästi että se on esimerkki. Asiakkaalle on kustannustehokkaampaa hyödyntää mahdollisimaan paljon toimittajan olemassaolevia prosesseja ICT palvelujen hankinnassa. Asiakaskohtaisten prosessien rakentaminen on toimittajalle ja siten myös asiakkaalle kallista. Palveluyhteistyö on kuvattu tarpeettoman yksityiskohtaisesti. Nämä asiat on luontevaa sopia tarkemmin sopimusneuvotteluissa eikä niitä ole tarpeen kirjata näin tarkasti suositusdokumenttiin. Suosituksessa voi hyvin olla esimerkki, mutta esimerkistä ei ole syytä tehdä ainakaan pakollista suositusta. ( ) 17. Muutosehdotukset kappaleeseen 5.2 Palvelutasoluokkien muodostaminen laatumääreistä 2. Lause "It palvelutuottajan on kuitenkin..." on epäselvä. Suositus siitä että asiakkaan tulisi ottaa jokin toimittajan tarjoama palveluaika vastaan on huono. Lähtökohtaisesti jo tarjousten tasapuolisuuden vuoksi asiakkaan tulisi määritellä tarvitsemansa taso. Laajennuttuun palveluaikaan ei välttämättä tarvitse sisällyttää viikonloppua. Viikonloppu voisi olla oma pakettinsa. ( ) 18. Muutosehdotukset kappaleeseen 6. Määritettyjen palvelujen palvelutasoluokitus 1. Palvelimien käyttöpaklvelut: A ja B väliin vielä yksi luokka? ( ) 2. Ei muutostarpeita ( ) 3. Palvelinten käyttöpalvelut Lyhenteiden (A E, P1 P4, K1 K4 ja V1 V4) käyttöä palvelutasojen luokitteluissa voi olla vaikeakäyttöistä. Selväkieliset (Perustaso, arkisin 8 16, 97%, reagointiaika 4h) kertovat heti, mistä puhutaan, kun koodeissa pitää olla selitystaulukko vieressä kun niitä lukee. Lisäksi voi olla vaikeaa saada toimittajaa hyväksymään sopimukseen ennakolta määriteltyä ratkaisuaikaa (esim. 2 htp). Käyttäjätukipalvelut Tukipalveluissa tulisi olla hieman tiukempia vaatimuksia erityisesti korkeammilla tasoilla, esimerkiksi: T3 90% 40 s kuluessa ja T4 90% 20 s kuluessa. Jopa 95%:n vastausaikavaatimusta voisi ajatella. Samoin jo T2:n kohdalla voisi ajatella joko prosenttiosuuden nostamista tai aikarajan kiristämistä. Tietoliikenteen peruspalvelut Reagointiaikoja tulisi lyhentää: V2 1h, V3 15 min ja V4 10 min. Käytettävyys: K5 käytettävyysvaatimus 99.95% voi olla sallittavissa, kunhan tarkastelujako on riittävän lyhyt ja/tai maksimikatko on rajattu tiukasti (esim. 30 min). On hyvä muistaa, että vuositasolla tarkasteltuna 99%:n takuu tarkoittaa, että järjestelmä ei ole toimintakunnossa n. 3,6 vrk:n aikana (n. 87 t). Ja 99,9% sallii 8,7 tunnin katkoksen. ( ) 4. Tekstistä ei käy ilmi että kaikki esimerkkien palveluvasteet sekä reagointi ja ratkaisuajat on otettu "krittisen" häiriön mukaisesti. Huoltoikkuna esimerkki voisi olla vähän toimittajaystävällisempi, taloudelliset näkökulmat huomioiden. Dokumentoinnista voisi yleisestikin linjata, että toimittajan tulisi ilman eri korvausta toimittaa sovittuun palveluun kuuluva dokumentaatio. Käyttäjätukipalvelut sivu 12 viimeinen lause on väärä (kopiovirhe). ( ) 5. Palveluvasteiden käytännön merkitys olisi hyvä määritellä tarkemmin. Mitä 2 h tai 1 tp tarkoittaa, kun palveluaika on esim. 8 16? Onko työpäivä aina kokonainen, eli seuraavan työpäivän klo 16 mennessä vai samaan aikaan seuraavana päivänä? Yleensä on käytetty jälkimmäistä, mutta se olisi hyvä kirjoittaa auki. ( ) 6. Kappale on ohjaavana informaationa sisällöllisesti hyvä, mutta lopulliset palvelutasoluokitukset tulee määritellä tapauskohtaisesti. ( ) 7. Näitä on kommentoitu liitteen 1 kommentoinnin yhteydessä. Pyydämme huomioimaan ne kommentit myös tämän dokumentin yhteydessä. ( ) 8. Palvelutasojen tulee olla huomattavasti yksinkertaisempia, koska jo tällä hetkellä eivät kunnat / kaupungit kykene suoriutumaan läheskään aina IT kilpailutuksista niiden teknisyyden vuoksi. Esim. jos yhdellä kunnalla on yli 100 tietoliikenneliittymään ja kaikkiin tulee määritellä eri kriittisyysluokka (=palvelutaso) ja kilpailutuksen jälkeen tulisi laskea helposti kustannustaso ja vertailla keskenään saattaa sekin osoittautua ylivoimaiseksi tehtäväksi. Esitetyssä tavassa on myös se heikko puoli että jos vertaa sanktiointiin, niin lopputulemana pahimmillaan kunta / kaupunki saa hyvityksenä esim. hammashoitolan tietoliikenneyhteyden ollessa poikki 3 päivää on hyvitys joitain kymmeniä euroja, mutta menetys hammasterveydenhuollossa jotain ihan muuta. Em. vain sen vuoksi että kunta / kaupunki ei ole esim. osannut laskea etukäteen mitä se saa / menettää jos yksi tietoliikenneliittymä on alhaalla tai se ei ole osannut etukäteen laittaa kaikkea tarpeeksi kriittiseksi. ( )

7 19. Muutosehdotukset kappaleeseen 7. Kokonaislaadun määrittämisen periaatteet 1. SAASille tasot toimittajilla on omat sopimukset. Siksi tärkeä, että kuntapuoli saisi omat standardit, jolloin voisivat hyväksyä ne kunta asiakkaiden kanssa vrt. JIT. Tässä heikkous eli miten toimittajat ajavat omia mallejaan. ( ) 2. Ei muutostarpeita ( ) 3. Erityisesti kriittisissä järjestelmissä on aina taattava järjestelmäkokonaisuuden korkea kokonaiskäytettävyys (esim. 99.9%). Tällöin käytettävyysvaatimusta ei ole syytä mittaroida osakomponenttien mukaan, vaan laatuvaatimus annetaan esim. käyttäjän kokemalle käytettävyydelle tai palvelun ulkoisen rajapinnan käytettävyydelle. Asiakas toki maksaa järjestelmän edellyttämät kahdennukset ja varautumisratkaisut, mutta mittari on sen jälkeen sovitettava koko kokonaisuudelle, josta toimittaja ottaa kokonaisvastuun, vaikka ei itse vastaisi kaikista palvelukomponenteista. Väestötietojärjestelmän käyttöpalveluiden osalta toimittaja tuottaa ns. integraattoripalvelua, johon kuuluu kolmansien osapuolten yhteistyön hallinta koko järjestelmän elinkaaren ajan (sopimuskaudella), jotta kokonaiskäytettävyys voidaan taata. Toivomme, että korkean kokonaiskäytettävyyden vaatimusta käsiteltäisiin suosituksessa riittävästi, koska monella viranomaisella on tämä sama haaste kuin meilläkin. ( ) 4. Haukutaan ja mainitaan erityisesti avoimen koodin ongelmat, kun pienessä alaviitteessä kuitenkin mainitaan samojen ongelmien koskevan myös kaupallisia järjestelmiä. Otetaan pois kokonaan viite avoimiin ja todetaan vain, että dokumentaation saaminen suorityskyvystä ja mitoituksesta voi olla yleensäkin ongelmallista. Voisi huomauttaa, että kannattaa varautua toimittajan vaatimukseen kahdentaa järjestelmä, jos oikein korkeita käytettävyyksiä halutaan (kustannusvaikutus). Korkean käytettävyyden ratkaisujen piirteitä voisi enemmänkin korostaa, vaikkapa omalla kappaleella. Emme löytäneet mainintaa sähköisen sopimuksen teon mahdollisuudesta. Web services arkkitehtuurilla toteutettujen palveluiden palvelutasosopimusten määrittelyyn ja monitorointiin on olemassa valmiita kieliä ja kehyksiä, joista suurin osa on XML pohjaisia. Kehykset mahdollistavat myös palvelun monitoroinnin ulkoistamisen kolmannelle osapuolelle. Palvelutasosopimukset voidaan määritellä XML Schemaan pohjautuvalla kielellä. Ajonaikainen arkkitehtuuri pystyy tulkitsemaan määrittelykielellä määritellyn sopimuksen. Monitorointiympäristö osaa muuntaa SLA:n automaattisesti konfiguraatioparametreikseen. Kehyksellä voidaan mitata ja valvoa Web service palvelun laatumittareiden parametreja ja raportoida rikkomukset sopimuksen osapuolille. Kehys mahdollistaa myös automaattiset toimenpiteet palvelutasosopimuksen mukaisen palvelutason alittuessa. SLA sopimusten määrittelykielillä voidaan kuvata a) sopimusten osapuolet, heidän roolinsa ja sopimuksen muille osapuolelle tarjoamat toimintarajapinnat b) itse palvelu ja sen palvelutasoparametrit, mitattavat metriikat sekä algoritmit laskutoimituksiin c) sopimuksen osapuolten velvoitteet sekä toimet, jotka seuraavat palvelutasolle asetettujen raja arvojen rikkomista. ( ) 20. Muutosehdotukset kappaleeseen 8. Palvelutasojen hyödyntämisen pääprosessi 2. Lause (s18) "Tyypillisesti tämä..." antaa taas toimittajalle kaiken vallan. Asiakkaan nimenomaan pitää tarjouspyynnössä määritellä nämä asiat. Myös liite1 tulee ymmärtää vain suosituksena. sivu18 Varsinaiset vaatimukset voisi lisätä esimerkin omaisesti "Asiakas voi halutessaan oman tai kolmannen osapuolen toimesta valvoa, testata, auditoida...". Tai esim. toimittaja siirtää järjestelmästänsä dataa asiakkaan käyttöön (jotenkin pitäisi tietysti varmistaa tietojen muuttumattomuus). Tärkeä olisi jollain lailla korostaa sitä, ettei valvonta seuranta olisi pelkästään toimittajan itsensä tuottamien raporttien varassa valvoo itse itseänsä tilanne. ( ) 3. Asiakas Toimittaja mallilla tuotetuissa IT palveluissa ei tule olla henkilösidonnaisuutta asiantuntijatasolla. Palveluyhteistyöhön tulee olla nimetyt edustajat osapuolilta sekä dokumentoitu käytäntö tilanteisiin, joissa edustaja vaihtuu. Mutta asiantuntijatehtävien osalta Asiakkaan tulee luottaa Toimittajan kykyyn tuottaa palvelukomponentteja asiantuntevasti, sekä sovittujen laatutavoitteiden puitteissa. Jokainen vakavastiotettava IT palvelutoimittaja kykenee tähän, lisäksi se, ettei tiettyyn tehtävään ole nimetty tiettyä henkilöä, mahdollistaa Toimittajan joustavamman ja tehokkaamman palvelutuotannon. ( ) 4. Kappale Palvelutason kuvaaminen palvelusopimukseen : Kaikkien osapuolten kannalta on edullista pyrkiä käyttämään toimittajan jo valmiiksi tuotteistamia palvelutasoja. Niistä poikkeaminen aiheuttaa lisäkustannuksia toimittajalle ja asiakkaalle. ( ) 21. Muutosehdotukset kappaleeseen 9. Määritettyjen palvelutasojen käyttö 22. Muutosehdotukset kappaleeseen 9.1 Esimerkkejä tyypillisistä palvelutasotavoitteista eri tilanteissa 2. Esimerkit ovat hyviä ajatusten herättäjinä, mutta käytännön palvelutasovalinta tulee tehdä tapauskohtaisesti kaikki vaikuttavat tekijät huomioiden. ( )

8 1. Kohta Käytettävyys: Millä palveluajalla kyseiset maksimikäyttökatkot on laskettu, ts. onko max.katko siis määritelty pienemmäksi kuin käytettävyysprosentti? (Esim. 24/7 palveluajalla, kuukauden tarkastelujaksolla ja 99,9% käytettävyydellä yhtäjaksoinen katko voi olla n. 43 min (ilman huoltokatkoja)). Tämän kohdan maksimikäyttökatkon laskentaperusteet voisi tarkentaa epäselvyyden välttämiseksi. Kohta 5.4 Työasemapalveluiden palvelutasoluokat: Viimeinen kappale näyttää hieman erilliseltä. "Mittaukset suoritetaan Toimittajan määrittämien Espoon hyväksymien menetelmien mukaisesti." voisi korvata esimerkiksi "Mittaukset suoritetaan toimittajan määrittämien ja tilaajan hyväksymien menetelmien mukaisesti." ( ) 2. SAAS: Onko käyttöpalvelut P+K+V ja tukipalvelut P+T+R eli siitä kehittelemällä SAAS SLA asiakas ja käyttäjätyytyväisyys erikseen on hyvä kirjaus. Pitäisikö tehdä enemmän valmista myös kyselyyn nythän monilla on jo vakiintuneet käytännöt näihin. Sanktiot: Nyt liikutaan heikoilla jäillä. Vaike, mutta hyvä asia ja miten seuranta? Kpl 6.1 %:t ovat makuasioita eikä taloudellisia arvoja voi arvioida noilla tiedoilla ja %:t vaikuttvat suurilta. Yleensäkin näihin tarvitaan ns. tilaaja asiantuntija näille töin ja pelkäämpä, että monessa kunnassa ei ole mahdollisuutta > mikä ajaa ulkoistuksissa kohti suurempia ostoyksiköitä ( ) Laatumäärekohtaiset palvelutasot ja niiden mittaaminen Tekstin muotoilu on sopiva tarjouspyyntöön, mutta ei sopimuksen liitteeseen. Liitteessä voidaan kuvat missä palvelutasojen muutosprosessi on kuvattu Palveluvaste Ratkaisuajat taulukon jälkeisessä toisessa tekstikappaleessa maininta palvelimen käynnistämisestä ei sovellu asiakokonaisuuteen. Vikojen tekniset korjaamisohjeet pois liitteestä. 5.4 Työasemapalveluiden palvelutasoluokat Kaksi viimeistä kappaletta: Viittauksen loppukäyttäjien kokemaan laatuun ja Espoon hyväksymiin menetelmiin. 5.5 Asiakas ja käyttäjätyytyväisyys Kuvaa enemmän vastausajankohdan tilannetta. Jollakin yksittäisellä lähiajan kokemuksella voi olla suuri vaikutus arviointiin. Lisäksi voidaan esittää myös kysymys palveluiden kehittymistä edellisestä mittauksesta tai vuoden takaisesta tilanteesta (asteikko esim: 2, 1, 0, 1, 2). Kysymys ohjaa vastaajaa miettimään pidemmällä aikavälillä tapahtunutta kehitystä. Muutosta mittaavan kysymyksen mukaan ottaminen aiheuttaa muutostarpeen kokonaistyytyväisyyden laskentakaavaan. 6. Sanktiointi Toistuvien poikkeaminen sanktioinnin laskentakaavoissa viitataan tarkastelukuukauden poikkeamaluokkaan. Kohtien taulukoissa ei esiinny poikkeamaluokkien numerointia. Palvelinten käyttöpalvelut hankitaan palvelinkohtaisesti. Sanktiointi vaikuttaa tällöin vain ko palvelimen osalta. Sanktiointi tulisi kohdistaa koko palveluryhmän (palvelimien käyttöpalvelut) veloituksiin, kun sanktiointi on saavuttanut yhden palvelimen osalta maksimiarvonsa. Esimerkiksi 5% lisää kuukaudessa jokaisesta taulukon ylittyvästä tasosta. ( ) 4. Palveluiden sanktioinnista: hyvitys % ko. kohteen kuukausimaksusta. Etenkin kriittisten järjestelmien kokonaiskäytettävyyden sanktioinnissa on arvioitava, lasketaanko sanktio ko kohteen (vikaantunut kohde tai palvelukokonaisuus) vai koko palvelusopimuksen kuukausimaksusta, jotta sanktion vaikutus on riittävä sopimuksen kokonaishintaan verrattuna. Tämä on varmasti asia, mikä askarruttaa muitakin viranomaisia sanktiotasoja määriteltäessä. ( ) 5. Kommentit koottu vastaukseen 19. ( ) 6. Kappale onko logiikka varmasti kohdallaan kun puhutaan käyttökatkosta palveluaikana. Onko palveluaika oikea termi tässä? Käytettävyys lasketaan yleensä ajasta, ei pelkästään palveluajasta. Kappale Virhe esimerkissä, K3 käytettävyyslukema on 99,5%, jolloin alhaallaoloaika siis 0,5% Kappale sähköpostivasteen ja puhelinvasteen ero on huikea. Varsinkin kun toimittajat ilmeisesti ohjaavat mielellään yhteydenottoja sähköpostin kautta tapahtuvaksi. Sähköposti voisi olla hitaimmillaan korkeintaan 1 tunti. Kapplele Huomioita milloin eskaloitava tiketti suljetaan. Suljetaan vasta kun se tulee takaisin. Kappale 5.2 Jatkuva tuki rivi tavoitettavuus 40min kuluessa?! Onko virhe? Kappale 6 Onko hyvä aloittaa sanktio välittömästi kun palvelutasoa ei ole saavutettu ja asetettaisiin raja tiukemmaksi. Sopimuksen purun ehtoja voisi vielä tarkentaa (esim. sovittu 100 kpl plavelimista, joista yksi jatkuvasti menee rajojen yli, voidaanko sopimus purkaa) Kappale 6.5 Jotain suuntaviivaa siitä, mikä voisi olla sopiva sanktio/bonus. ( ) 7. 2 Soveltamisala Mikä tulee olemaan JIT ehtojen rooli laatuliitteen alla tarjottavissa palveluissa? Laatuliite on toimittajan kannalta huomattavasti järkevämpi tapa tarjota palveluita, sillä käytännössä harvat JITin yleiset ehdot soveltuvat jatkuvapalveluiden käyttöön. 4 Laatumäärekohtaiset palvelutasot ja niiden mittaaminen ja Ei tule käyttää termiä toiminnanohjausjärjestelmä, koska se yhdistetään laajemmin ottaen yleensä ERP järjestelmiin. Sanastossa tulisi käyttää palvelunohjausjärjestelmää ja selittää se auki palvelupyyntöjenhallinta /työajanseuranta /tiketointi etc. järjestelmänä. Kappaleessa mainitaan määre toimitusaika, mutta sitä ei ole muutoin avattu liitteessä missään mittarissa. Tarpeiden muuttuessa osapuolten tulee noudattaa yhdessä sovittua muutosprosessia Ratkaisuksi tulee tietyissä tilanteissa katsoa myös ongelman reitittäminen/ohjaaminen eteenpäin. Aina kyseinen ongelma ei välttämättä ole toimittajan vastuulla tai ratkaisumahdollisuuksien piirissä. Ratkaisuun voivat vaikuttaa myös toimittajasta riippumattomat tekijät tai esimerkiksi asiakkaan valinnat. Ratkaisuaikaan tulisi laskea ainoastaan kokonaan toimittajan vastuulla olevat asiat. Tavoitettavuuden vaatimus sähköpostilla tai muilla sähköisillä viesteillä lähetettyjen palvelupyyntöjen osalta on hieman ongelmallinen. Palvelupyyntöjen automaattinen siirto työjonoon on kielletty. Tämä voi olla erittäin epäkäytännöllistä toimittajan prosessien kannalta tuomatta yhtään lisäarvoa. 4.2 tarkastelujaksoksi olisi hyvä tarkentaa kalenterikuukausi. Toteutunutta käytettävyystasoa laskettaessa ei tule huomioida muuta kuin toimittajan vastuulla olevat seikat. Tpm, Tavoiteajassa palveluaikana vastattujen. Pm, Puheluiden määrä / sähköisten palvelupyyntöjen määrä palveluaikana tarkastelujaksolla Toteutuneessa tavoitettavuudessa ei huomioida Puheluita, joissa asiakas on katkaissut puhelun alle tavoiteajan Kuinka ratkaisukykyä on tarkoitus mitata sähköisille palvelupyynnöille? Käytännössä siis muille kuin puhelimella soitetuille palvelupyynnöille? on pitkälti toistoa aikaisemmasta. Mistä ratkaisukyky lasketaan? Miten ratkaisukyvyn mittaaminen on suhteessa tavoitettavuuteen? 5 Palvelukohtaiset palvelutasoluokat Erityisesti sovellusten ylläpitopalvelut vaativat usein pyyntöjen reitittämistä ja tämä on huomioitava myös laatuliitteessä. Palvelutasoluokat lieneekin aika hankalaa taata sovelluspalveluissa ja niitä ei tule vaatia suosituksessa oletuksenomaisesti. 5.5 Asiakas ja käyttäjätyytyväisyys on suosituksessa kuvattu lähtökohtaisesti siten, että tilaaja asettaisi myös kysymykset ja sanelisi asteikot. 6 Sanktiot Sanktioiden yhteydessä seuraava lause tulisi poistaa: Näiden lisäksi asiakkaalla on oikeus hyvitykseen, mikäli palvelun sisältö ei vastaa sovittua tai palvelua ei saada sovittuna palveluaikana. Tämä johtaa toimittajan tuplasanktiointiin, mitä ei voida pitää palvelun kannalta perusteltuna. Tämä nostaa huomattavasti toimittajien riskitasoa ja näin ollen näkyy myös hinnassa. Sanktioiden tehtävä on rangaista juuri yllä kuvattuja häiriöitä. Toistuvien poikkeamien kiristyvä sanktiointi johtaa myös osaltaan jo yllä mainittuun tuplasanktiointiin samankaltaisin seurauksin. Tämä tekee toimittajan riskien hallinnasta haasteellista, mikä voi kostautua asiakkaalle korkeampana hintana tai alempina tavoitteina. Mikäli käytettävyydessä on toistuvasti (vähintään 4 kuukautta kuuden kuukauden liukuvalla tarkastelujaksolla) yli 0,51% poikkeamia, asiakkaalla on oikeus purkaa sopimus. Tämä lause ei sovellu jatkuvien palveluiden tarjoamiseen. Palvelut ovat luonteeltaan palautuskelvottomia siinä mielessä, ettei suorituksia ole mahdollista palauttaa. Tukipalveluiden sanktiointi kohtuuton, mikäli sovelletaan sovellustukipalveluissa palvelutasoluokkia Asiakas ja käyttäjätyytyväisyyteen subjektiivisina mittareina bonus/sanktiot sopivat huonosti. ( ) 8. Dokumentissa on paljon copy/paste virheitä (esim. palveluvasteesta puhuttaessa kerrotaan, että käytettävyyden tarkasteltava ajanjakso on 1 kk jne), mutta nämä ovat varmaan draft vaiheen ongelmia. Isompana ongelmana näkisin dokumentin suunnattoman 23. Muutosehdotukset kappaleeseen 9.2 Palvelutasoista sopiminen ja palvelutasojen dokumentointi 2. Olennaista sopimuskokonaisuuksissa on selkeys ja päällekkäisyyksien välttäminen. Usein voi olla perusteltua, että on useampi palvelunkuvaus ja palvelun laadut ovat myös kuvattu erikseen Katso ylempi kommentti liittyen palvelutasotavoitteiden muutoksiin. Nämä tulee hoitaa yhteisellä sopimuksella muutosprosessin kautta, jolloin on mahdollisuus myös muuttaa hintoja. ( ) 24. Muutosehdotukset liitteeseen 1 Palvelutasoluokat

9 sekavuuden ja hankalan tulkittavuuden, osin varmaan siitä johtuen, että valtavasti asiaa on koitettu niputtaa yhteen. Osittain vielä niin, että käsiteltävien alueiden osalta (esim. tietoliikenne vs, työasemahallinta) määreet, tekemisten erilaisuudesta johtuvat toimintatapaerot on väkisin yritetty kasata samaan muottiin ja osin ovat hiukan menneet asiat sekaisin. On päällekkäisiä samaa tai lähes samaa tarkoittavia termejä, on termejä, joilla ei jollain osa alueella ole oikeasti mitään relevanssia jne. Koitan avata huomioitani alla lähinnä tietoliikenteen hallinnan näkökulmasta. termit ja määritelmät ratkaisuaika/palveluvaste vs. maksimikatko ovat näkemykseni mukaan sama asia. Toisaalta dokumentissa on termejä joita ei ole määritelty Esim. laskennallinen sanktioluokka palvelutasoluokat käytettävyystaso, siinä määritelty maksimikäyttökatko ja palveluvasteessa määritelty ratkaisuaika eivät ole sykronissa, mikäli olen tulkinnut dokumenttia oikein. ESIM. palvelutaso 2 (normaali), palveluaika P2 (7 18), käytettävyys K3 (99,5%) palveluvaste V2 (reag. 2 h ratk. 1 tp). => palveluaikatunteja 242 h/kk(11h x 22 arkipäivää) => kun palvelussa on ollut 1.21 tuntia kumulatiivista katkoa on käytettävyysprosentti 99,5% kuitenkin käytettävyysmäärityksen kohdalla kerrotaan, että K2:ssa on maksimikäyttökatko palveluaikana 2 h ja palveluvasteen kohdalla kerrotaan, että vika tulisi olla ratkaistu yhden työpäivän aikana. Eli vika keissiin saadaan kolme toisistaan poikkeavaa palvelun palautusaikaa ennen kuin mennään sanktiolle :Käytettävyyden kautta tarkasteltuna katkoa saa olla 1,21 h, maksimi katkojen kautta tarkasteltuna 2 tuntia ja palveluvasteen kautta 1 työpäivä ja reagointiaikakin on 2 tuntia(eli vikaa pitää ruveta korjaamaan kahden tunnin kuluessa sen havaitsemisesta) vaikka yksi mittari on punaisella jo 1,21 tunnin kohdalla. Tästä seuraa hämmennys ja ihmetys sanktioiden käsittelyn kohdalla. Käytettävyys ja maksimikatkot ovat rinnakkaisia mittareita, mutta palveluvaste on oma mittarinsa. Palveluvasteessa on kaksi teknistä mittaria, joista hyvityksiä tarkastellessa tutkitaankin vain reagointiaikaa, ei ratkaisuaikaa. Missään ei ole määritelty sisältyykö reagointiaika ratkaisuaikaan vai ei, mutta siitä huolimatta mielestäni on aivan merkillinen vaatimus, että toistuva reagointiajan ylitys oikeuttaa sopimuspurkuun, muiden mittareiden (omasta mielestäni huomattavasti tärkeämpien) osalta tuollaista vaatimusta ei ole. Jätin edellisestä esimerkistä tarkoituksella pois teknisen laatutason, joka on mittarina hiukan toisenlainen, mutta yhtälailla sekin mittari on tietysti "rikki" mikäli liittymä on vialla eli sanktiota tulisi taas. Tekniselle laatutasolle pitäisi vähintäänkin asettaa määritykset, milloin sitä ei tarkastella: vian yhteydessä, silloin kun asiakas on omilla toimillaan aiheuttanut viiveiden kasvun (liittymän kapasiteetin/liikenneluokkakohtainen ylikuormitus) Teknisen laatutason tavoitearvot: Kohdassa taulukon viive ja jitter arvot eivät ole realistisia kun otetaan huomioon, että tässä puhutaan WAN palveluista eli maantieteellisten välimatkojen takia arvojen pitäisi olla yli kymmenkertaisia. Mielestäni vaaditut arvot saavuttaakseen operaattorilta edellytetään fysiikan lakien rikkomista, vaikka dokumentissa olikin kerrottu, ettei kyse ole yhden yksittäisen mittauksen tuloksesta vaan kaikkien mittausten keskiarvosta. Mittaustopologia tulisi kuvata tarkasti, samoin jokainen mittauksiin liittyvä määre (ei tyyliin "lasketaan useita arvoja pidemmän aikavälin sisällä"). Tavoitearvot kannattaisi kiinnittää edestakaisiin mittauksiin, silloin ei eri laitteiden ajan epäsynkroni aiheuttaisi ongelmia vaan aikaleimat olisivat aika saman laitteen antamia, jolloin mittaustulokset olisivat luotettavia. VoIP on selvästi herkin sovellus viiveelle ja etenkin viiveen vaihtelulle, jolloin mittaukset kannattaisi suorittaa sille paremmin sopivalla pakettikoolla. VoIP on tyypillisesti (hiukan codekista riippuen) 100 tavun molemmilla puolilla. Nyt on määritetty, että mittaukset tehdään 1500 tavun paketilla eli karkeasti 10 kertaa VoIP paketin kokoisella paketilla tavun pakettikoko sopii suurikapasiteettisten liittymien läpäisykykymittauksiin, mutta ei kerro verkon kyvystä välittää puhepaketteja oikeastaan yhtään mitään. Lisäksi en kiinnittäisi teknistä laatutasoa johonkin yhteen palvelutasoon(=liittymään), koska mikäli VoIp otetaan laajamittaisesti käyttöön, kulkee kaikissa liittymissä reaaliaikaliikennettä ja toisaalta missään ei kulje vain sitä. Teknisesti kun noiden eri tasojen (L1 L4) erot saadaan aikaan ja pystytään varmistamaan reaaliaikaliikenteen vaatima taso nimenomaan liittymässä tehtävällä laatuluokituksella, jossa kerrotaan jonotusmekanismit eri liikennetyypeille. Jitterin laskentakaava kannattanee vielä tarkastaa. Mielestäni Jitter tarkoittaa peräkkäisten ip pakettien välistä viiveen eroa, ei jonkun tietyn (tässä epämääräisen ajan) maksimi ja minimi viiveen eroa. Läpäisykyky on mahdollista suorittaa vain silloin kun liittymän tuotantoliikenne ei "häiritse" mittausta eli ei liene järkevää tehdä kuin ihan poikkeustapauksissa. Pyydän anteeksi sekavaa palautetta, mutta olen käsitellyt SLA asioita operaattorilla jo lähes 10 vuotta, mutta tähän dokumenttiin en voi väittää päässeeni kunnolla sisälle, palautteeni alussa mainitsemieni asioiden takia. Lisäksi tämä palautteenantomuoto ei oikein tue jäsenneltyä palautetta. Olisi ollut hyvä rakentaa myös liite 1:lle samantyyppinen aukipurettu kommentointiosio kuin itse päädokumentilla oli. ( ) 9. Liitteessä 1 Palvelutasoluokat on johtoajatuksena se, että pienempi numero tai kirjain tarkoittaa kriteeristöltään höllempää vaihtoehtoa, esimerkkikis "Tavoitettavuus" T1 on "hitainta reagointia edellyttävä vaihtoehto. Mielestäni voisi harkita asian kääntämistä, eli numero 1 tai kirjain A tarkoittaisi kriittisintä reagointia/toimintaa/vastetta edellyttävää luokitusta. ( ) 10. Kohta Palveluvaste: Palveluvasteluokka V4:n Kriittisen rivin ratkaisuaika 2 h ei sovellu pitkien etäisyyksien ja routaisten talvien Suomeen. Kahdessa tunnissa korjaajan saaminen kaukana sijaitsevaa kohteeseen on käytännössä hyvin haasteellista. Muutoksena ehdotamme että palveluvasteluokat V3 ja V4 yhdistetään ja ratkaisuaika on molemmissa 3 h. Kolmiportainen häiriöluokitus (kriittinen, vakava, matala) on hyvä ja ITIL mallin mukainen. Kohta Ratkaisukyky: Johtuen eri ICT palvelujen hyvin laajasta kirjosta on ratkaisukyky hyvin riippuvainen vian luonteesta. ITIL:n mukaan vika on ratkaistu kun palvelutaso on palautettu ennalleen eli kun vika on korjattu. Usein kuitenkin vakavan vian korjaaminen kestää niin pitkään, että käyttäjän yhteydenoton aikana vikaa ei ITIL:n määrittelyn mukaisesti voida ratkaista. Jos ratkaisuksi katsotaan se että käyttäjälle kerrotaan että vikaa korjataan on ratkaisukysy huomattavasti parempi. Ratkaisun määritelmä on kirjattava suositukseen tarkemmin. Kohta Tietoliikenteen peruspalveluiden tekninen laatutaso: Laatuluokituksen osalta esitetty taulukko sisältää lukuarvoja joiden toteutuminen ei teknisesti ole mahdollista tunnetulla tekniikalla. Elisa suosittelee että asiakas luokittelisi nykyiset sovelluksensa sovellusten luonteen mukaisesti eri luokkiin. sekä arvioi kuinka paljon ko. luokkiin sisältyisi liikennettä. Eri sovelluksille löytyy ohjeelliset laatuparametrit ITU T G.1010:n määrittelyistä. Luokittelun on perustuttava alan yleisiin käytäntöihin. Ehdotamme ITU T:n dokumenttien G.1010 End user multimedia QoS categories sekä Y.1541 Network performance objectives for IP based services mukaisiten määrittelyden käyttöä. Taulukon sisällöksi ehdotamme seuraavaa (jos taulukko ei ole tässä riittävän luettava, lähetän sen pyynnöstä esim. pdf muodossa): L1 L2 L3 L4 IPTD/Viive 60 ms 60 ms 45 ms 30 ms IPTDmax/Maksimiviive 100 ms 100 ms 75 ms 50 ms IPDV/Viiveen vaihtelu ei määritelty ei määritelty 40 ms 25 ms Pakettihävikki alle 0,5% alle 0,01% alle 0,01% alle 0,01% Mitattujen datapakettien kehyskoko on 100 tavua. Mittausjakso 15min keskiarvo IPTD: Tyypillinen viive yhteen suuntaan asiakasliittymästä liittymään CE CE. IPTDmax: maksimi viive yhteen suuntaan CE CE. Tämä arvo on voimassa silloin kun asiakasyhteys päästä päähän ei ole ruuhkautuneena. Mittauksessa käytetään 100 lähetetyn paketin keskiarvoa. Liittymän läpäisykyky on mitoitettava liittymän käyttötarpeen mukaan. Tässä on otettava huomioon käytettävät sovellukset ja käyttäjämäärät. Kohta Käytettävyys: Käytettävyysmittauksen osalta kuukausi on lyhyt ajanjakso. Yksi vika voi alentaa kuukausikohtaista käytettävyyttä merkittävästi vaikka häiriö olisikin eliminoitu palveluvasteen puitteissa. Ehdotamme tähän kohtaan käytettävyysmittauksen ajanjaksoksi 3 kuukautta. Yksittäisten häiriöiden vaikutuksen minimointi on ratkaistavissa oikein valitulla Palveluajalla ja Palveluvasteella. Kohta 5.3 Tietoliikenteen peruspalvelujen palvelutasoluokat: Taulukossa palvelutasoluokan Perustaso palveluvaste on tarpeettoman tiukka koska normaalitasoon ei ole mitään eroa. Palveluvasteen tulisi olla V1, reagointi 1 tp, ratkaisu 3 tp. ( ) 11. Kohta Ratkaisukyky (R): Yleisesti Ratkaisukyvyn mittaamisesta: Palvelupisteen edellytykset palvelupyynnön ratkaisemiseksi ovat riippuvaisia paitsi palvelupisteen resurssien laadullisesta ja määrällisestä allokoinnista, mutta myös asiakkaalta saatavien lähtötietojen selkeýdestä ja laadusta. Ratkaisukyvyn mittaaminen esitetyllä mallilla voi johtaa tilanteeseen, jossa toimittajat edellyttävät laadullisesti ja määrällisesti tarkempaa informaatiota suoritettavasta palvelupyynnöstä ennen kuin hyväksyvät palvelupyynnön ns. kirjattavaksi järjestelmiin. Ratkaisukyvyn mittaaminen esitetyllä mallilla voi johtaa tilanteeseen, jossa palvelupyyntöjen tekeminen edellyttää loppukäyttäjältä aikaisempaa yksityiskohtaisempia lähtötietoja, ja tällä tavalla hankaloittaa ns. tavallisen loppukäyttäjän mahdollisuuksia saada palvelupyyntöjään toteutetuksi. TDC:n näkemyksen mukaan, ratkaisukyky ohjeituksen mukaisena mittarina toimii loppukäyttäjille rakennettuun helpdesk palveluihin. Tietoliikennettä koskevien vikatilanteiden, esim laitteiden hajoaminen tai linjakatkojen korjaaminen ei pystytä vertaamaan samalla mittaristolla Kohta Tietoliikenteen peruspalveluiden tekninen laatutaso (L): Kohdassa esitetty taulukko sisältää esimerkiksi IPTD/viiveen osalta raja arvoja, jotka ainakin ensinäkemältä vaikuttavat fysikaalisesti mahdottomilta. Teknisen laatutason (L) ja ITU T standardien keskinäistä suhdetta ja kohdan sisältöä on syytä olennaisesti selventää ja selkeyttää. Ehdotamme, että laatuluokituksen taulukko poistetaan tarjouspyynnön vaatimuksista ja vaatimuksena viitataan ainoastaan ITU T standardeihin Y.1540/Y Perustelu: Laatuluokituksen vaatimustaulukko vastaa ITU T suosituksia ainoastaan runkoverkon osalta. Esimerkiki palvelun kokonaisviivettä lisäävät runkoverkon laitteden jonotuksesta ja prosessoinista johtuvan viiveen lisäksi etäisyys ja liityntäverkkojen osuudet. Valon nopeus valokuidussa on n. 1ms / 209km ja liityntäverkon aiheuttama viive on tyypillisesti 15 20ms, joten esimerkiksi yhteydellä Helsingistä Ouluun on tyypillinen viive 35 40ms. Liityntäverkoilla on myös merkittävä vaikutus palvelun viiveen vaihteluun, virhesuhteeseen ja läpäisykykyyn. Kohta 6 Sanktiot: Palveluiden laatupoikkeamat on sanktioitu lukuisin tavoin. Tarkasteltavat kriteerit esimerkiksi tietoliikenteen peruspalveluiden osalta ovat (1) käytettävyys, (2) palveluvaste ja (3) tekniset laatutasot. Tämän lisäksi on sanktioitu tukipalvelut tarkastelukriteereinä (4) tavoitettavuus ja (5) ratkaisukyky. Näiden lisäksi sanktioidaan (6) asiakastyytyväisyys ja (7) käyttäjätyytyväisyys. Sanktioiden