itSM.lt

Manyčiau irgi svarbus procesas, galėtumėt apie jį ka nors?

Galėčiau, ale jau mėnuo laiko, kaip vis pritrūksta laiko rimčiau prisėsti parašinėti

Jei neparašys kitas specialistas, pvz., Robertas, tai matyt, teks man... Tik vat nežinau, kiek dar tai užtruks...

Paslaugų lygio susitarimas (SLA) - Paslaugų teikimo sąlygos, išreikštos matuojamais rodikliais, tarp kliento ir IT paslaugas teikiančio partnerio.
Salygos nustatomos sutartyje, kurios tikslas yra leisti abiems pusėms suprasti, ko yra tikimasi iš serviso ir kokios yra atsakomybės ribos.
Ko tikimasi iš serviso - apibrėžiama aptarnavimo valandos, pvz.: 8x5 arba 24x7 servisai, išimtys, sutarties apimtys, galiojimo sąlygos, apmokestinimo tvarka ir kt. veiksniai.
Atsakomybės ribos nustatomos įvairiais rodikliais, tokiais kaip reagavimo laikas, sprendimo laikas, aptarnavimo lygis ir kt.

Robertas labai tiksliai ir glaustai išdėstė visą reikalą. Norėčiau tik pridėti ir papildyti šį tą:

Paslaugų teikimo lygio valdymas (Service Level management) - tai esminis, visą IT veiklą reguliuojantis procesas, kuris gali gerai veikti tik įgyvendinus kitus procesus, bet, kita vertus, visi kiti procesai yra išties prasmingi, tik esant paslaugų teikimo valdymui: bet kurio IT proceso tikslas - įgyvendinti kliento reikalavimus taip, kaip to nori klientas. Būtent kliento norus formalizuoja ir leidžia kontroliuoti SLM valdomos paslaugų teikimo sutartys.

Esminis tikslas, ruošiant paslaugų teikimo sutartis - viską aprašyti nedideliu (minimaliu) skaičių rinkiniu, kiekvieną įsipareigojimą apibrėžiant tam tikru išmatuojamu dydžiu, pvz., gedimų skaičiumi per mėnesį, neveikimo laiku per mėnesį, kartu griežtai apibrėžiant, kas yra paslaugos veikimas, o kas - ne. Veikimą galima apibrėžti, kaip serverio operacijų per minutę skaičiumi, Interneto ryšio kanalo pralaidumu, paketų praradimo procentu, etc.

Tipiškais atvejais SLA būna numatyti šie dalykai:


* Paslaugos gavėjo įsipareigojimai (Service level requirements), kurie nusako būtinas sąlygas SLA įgyvendinimui iš paslaugos gavėjo pusės (pvz., galimybė prieiti prie įrangos gedimų ar profilaktinių darbų atveju, el. energijos tiekimas, etc.).
* Formalus paslaugos veikimo apibrėžimas, leidžiantis vienareikšmiškai nustatyti, kada paslauga veikia, o kada - neveikia.
* Paslaugų teikimo laikas (pvz., nuo 8 iki 18 val., išskyrus savaitgalius ir švenčių dienas).
* Paslaugų pateikiamumas (Availability), dažniausiai nurodomas, kaip procentinis įsipareigojimas (pvz., kad paslauga veiks 99,9 proc. patikimumu per mėnesį).
* Paslaugos patikimumas (Reliability), dažniausiai nurodomas, kaip maksimalus gedimų skaičius per mėnesį.
* Reakcijos laikas (laikas, per kurį pradedamas šalinti gedimas).
* Paslaugos atstatymo laikas (laikas, per kurį, gedimo atveju, paslauga privalo vėl imti veikti).
* Apmokėjimai ir baudos.



Paslaugų lygio valdymo (Service Level management) procesas giliai susijęs su keliais kitais procesais, ypač - pateikiamumo valdymu (Availability management), kuris nustato, kiek paslauga atitiko įsipareigojimus bei Incident management, kuris veikia priklausomai nuo nustatytų SLA.

Kazkaip labai pavirsutiniskai apzvelgtas procesas. Galima susidaryti vaizda, kad jei SLA's pasirasai procesas yra. Taip ir gimsta anekdotai. Pas mus yra idiegtas SLM procesas

Jei jau gilintis - šis procesas pradinėje stadijoje tikrai nėra labai sudėtingas ir jo tikslas - tiesiog teisingų (įgyvendinamų ir tinkamai formalizuotų) sutarčių pasirašymas. O vat visai kitas reikalas - kokie tų sutarčių tikslai ir kiek tą teisingų sutarčių kūrimą ir naudojimą sunku palaikyti praktikoje

Išties, diegiant SLM, pirmuose etapuose tikslas būna vienas - paslaugų teikimo sutarčių formalizavimas, bet vėliau, atsirandant paslaugų teikimo statistikai ir galimybėms sulyginti realias paslaugų charakteristikas su įsipareigotomis, viskas ima gerokai keistis. Štai tada ir atsiranda papildomi ryšiai su visais procesais, kurie tik ITIL yra numatyti, o SLM iš IT skyriaus proceso išauga į procesą, sujungiantį IT su pagrindine įmonės veikla. Gal truputį paradoksaliai čia skambėtų tai, kad bet kuris ITIL procesas idealiu atveju irgi turėtų būti vykdomas pagal tam tikrą SLA, turintį formalizuotų parametrų rinkinį, o procesų vykdymo kokybei kontroliuoti turėtų būti naudojamas Availability management procesas

Kiek tenka susidurti, dauguma ITIL pradedančių diegti įmonių SLM suvokia tiek miglotai, kad tiesiog iš principo neįstengia sudaryti ar valdyti gerai formalizuotų SLA sutarčių (tipiški anekdotiniai atvejai, kai sutartyse numatoma, kad "gedimų negali būti", nenumatomos baudos, gedimo šalinimo laikai apibrėžiami, kaip "maksimaliai greitai", nenumatomi paslaugų apibrėžimai (SLO), kliento įsipareigojimai (SLR)), itin dažnai tokiose įmonėse visiškai nesuprantama įsipareigojimų svarba (vėlgi anekdotas, besikartojantis bene pusėje įmonių: SLA įsipareigojimai darbo vietų priežiūrai parenkami pagal darbuotojų pareigas, aukščiausi įsipareigojimai tenka gen. direktoriui, mažiausi - sekretorei ir buhalteriams).

Kita vertus, gana įdomiais tampa atvejai, kai įmonė užsiima komerciniu IT paslaugų teikimu - tokiu atveju SLM ima integruotis į pardavimų procesą, o pats SLM, netgi jo nekuriant, kartais atsiranda savaime (kaip buhalterijos bei vadybininkų reikalavimų pasekmė) ir greitai įgyja didelę, įmonės vadovų gerai suvokiamą svarbą.

Taigi, kaip kartą pasakė vienas mano kolega - "Service Level Management - tai tikras ITIL procesų perlas"

Truputis dėstymo, kad mažiau anekdotų gimtų

Kaip Ričardas įvardino pirmajame etape yra svarbiausia "paslaugų teikimo sutarčių formalizavimas", taigi paslaugos sutarties sąlygų proceso pirmasis žingsnis turetų apimti paslaugų katalogą, kuriame būtų apibrėžta kokios paslaugos teikiamos, kas jas teikia ir trumpas apibūdinimas.
Atroje vietoje įvardinčiau SLA nustatymus.Tikriausiai niekas nenenigsite, kad čia ir praseideda ryšiai su kitais procesais.
O paskutinijį žingsnį SLA naudojimas, kuris susideda iš matavimo parametrų nustatymo ir stebėjimo; ataskaitų teikimo; SLA peržiūros.

Gal galėtumėm panagrineti konkretų tipinį lietuvišką pvz.:

Įmonė teikia IT paslaugas ir nori pradėti vykdyti SLM. Tipinė paslauga: kliento IT ūkio priežiūra (sutartis pasirašyta senai).
Paslaugą sudaro profilaktiniai ir ekstra vizitai.
Sutartyje yra numatyta:
- profilaktinių valandų kiekis
- reagavimo laikas

Mano supratimu aš (busiu kaip SL manager) turėčiau vykdyti tokius veiksmus:
1. kaupti informaciją ar atliekame profilaktiką numatytą valandą skaičių
2. kaupti informaciją ar regauojame pagal numatytą laiką

Ar teisingai?
Ar to užtenka?
Galbūt reiktu keisti sutartį ir paslaugas pasmulkinti, apibrėžti tiksliau?
Kaip jūs vykdote SLM?

Šiaip tai svarbiausias darbas praktikoje (kadangi esate komercinis paslaugų teikėjas) bus kontroliuoti, kad visi SLA būtų sąmoningi. Nors šiaip tai, galiu pasakyti, kad čia ta sritis, kuri jūsų įmonėje greičiausiai jau bus pakankamai sutvarkyta - be tam tikro SLM komercinės įmonės tiesiog negali egzistuoti

Esminė sritis, kur labai gali gautis kraštutinai daug vargo - tai SLA standartizavimas: kai visi SLA skirtingi, tai juose numatytų įsipareigojimų kontrolė yra labai kebli. Dar vienas momentas - paslaugų lygio vadovas turi šefuoti visus įmonės padalinius bei procesus, siekdamas, kad visi SLA būtų užtikrintai vykdomi.

Dabar apie tuos du punktus:
* Profilaktinių valandų skaičius - kiek suprantu, čia gali būti SLR (klientas garantuoja jums priėjimą prie kompiuterių tiek ir tiek valandų per mėnesį), o ne SLO, ar ne? Nes jei tai yra darbo vietų priežiūra, tai tos profilaktinės valandos reikalingos tam, kad užtikrinti tų darbo vietų veikimą. Na, nebent klientas tiesiog nori kad technariai kas mėnesį pabendrautų su jo darbuotojomis...
* Reakcijos laikas - vienas iš svarbių parametrų, nors brangiems klientams galima garantuoti ir pataisymo laiką. Dar vienas parametras gali būti registruotų gedimų skaičius per mėnesį.

Kai jau pasirasyta sutartis, viskas labai paprasta
ziuri ar tavo imone vykdo kas isipareigota sutarytje, kas bebutu isipareigota, reakcijos laikas, availability, ar specialistai atvykstantys su kostiumu ir roziu bukietu :)
aisku priedo galima ziureti ar klientas vykdo ka isipareigojo, tik netikiu kad realiai klientas uzsakes prieziuros darbus ka nors isipareigojo apart moketi babkes

beja tas SLManageris nelygu manageriui, priklauso nuo imones dydzio, ar ji gali sau leisti tureti manageri kuris butu tik proceso owneris, kurtu, atnaujintu procesus, proceduras ir priziuretu kad kiti daro ka reikia, ar yra tas darytojas, ar kas labiausiai tiketina, abu viename plius helpdeskas :)

SLManageris yra greiciau role o ne pareigos

_________________
Win first, then go to war