IT PASLAUGŲ VALDYMAS

Kaip parašyti SLA su IT tiekėju: ką būtina įtraukti

Dauguma SLA nesuveikia ne todėl, kad tiekėjas blogas, o todėl, kad dokumente neparašyta, kas ir kaip matuojama. Kai kyla ginčas, paaiškėja, kad abi pusės skaičiavo skirtingai — ir abi teisios pagal savo skaitymą.

Abstrakti schema: dvi skirtingo ilgio atkarpos — reakcijos ir sprendimo laikas

Reakcijos laikas nėra sprendimo laikas

Dažniausia spraga. SLA įrašomas „reakcija per 4 valandas”, o užsakovas supranta, kad per keturias valandas problema bus išspręsta. Tiekėjas supranta, kad per keturias valandas kažkas atsakys į laišką.

Abu terminai turi būti dokumente atskirai ir apibrėžti: reakcijos laikas — nuo užklausos gavimo iki patvirtinimo, kad ja užsiimama; sprendimo laikas — iki paslaugos atkūrimo. Ir būtina pasakyti, ar laikinas apėjimas laikomas sprendimu. Dažniausiai turėtų būti laikomas, bet tai reikia užrašyti.

Prioritetai turi turėti apibrėžimą

Jei SLA sako „kritiniai incidentai — 2 valandos”, turi būti parašyta, kas yra kritinis incidentas. Kitaip prioritetą nustato tas, kas garsiau kalba.

Veikiantis būdas — apibrėžti prioritetą per du matmenis: kiek naudotojų paveikta ir ar yra apėjimas. Tai duoda lentelę, kurią gali pritaikyti bet kuris komandos narys be vadovo sprendimo:

Visa organizacija sustojusi, apėjimo nėra — aukščiausias prioritetas.
Padalinys ar procesas sustojęs, apėjimas yra — aukštas.
Pavieniai naudotojai, darbas įmanomas — vidutinis.
Prašymas ar klausimas be gedimo — žemas, atskiras terminas.

Laikas, kuris skaičiuojamas

Ar SLA laikrodis sukasi naktį? Savaitgalį? Kai laukiama užsakovo atsakymo? Šie trys klausimai išsprendžia daugumą būsimų ginčų.

Priimta praktika — laikrodis sustoja, kol laukiama informacijos iš užsakovo, ir vėl pasileidžia gavus atsakymą. Bet tai turi būti dokumente, o įrankyje — techniškai įmanoma. Jei sistema to nemoka, matavimas bus rankinis, vadinasi ginčytinas.

Kas matuoja ir iš kur imami duomenys

Jei ataskaitą teikia tiekėjas iš savo sistemos, užsakovas neturi būdo jos patikrinti. Tai nebūtinai problema, jei abi pusės tuo sutaria — bet sutarti reikia iš anksto, ne po pirmo nesutarimo.

Minimalus reikalavimas: užsakovas turi matyti neapdorotą incidentų sąrašą su laiko žymomis, ne tik suvestinį procentą. Vienas skaičius „98 % SLA įvykdyta” nieko nepasako apie tai, kurie 2 % nepavyko ir kodėl.

Ką daryti, kai SLA nevykdomas

Dauguma SLA aprašo baudas ir nieko daugiau. Bauda retai išsprendžia problemą: ji kompensuoja, bet nekeičia priežasties.

Naudingiau įrašyti eskalavimo tvarką ir peržiūros ritmą — kas vyksta po antro nesėkmingo mėnesio, kas dalyvauja peržiūroje, per kiek laiko turi būti pateiktas priežasčių paaiškinimas. Tai veikia geriau, nes veda prie pokyčio, o ne prie sąskaitos sumažinimo.

KĄ VERTA ATSIMINTI

Reakcijos ir sprendimo laikas — du skirtingi dalykai, abu turi būti dokumente.
Prioritetas be apibrėžimo reiškia, kad jį nustato garsiausias balsas.
Susitarkite, kada SLA laikrodis sustoja, dar prieš pirmą ginčą.
Eskalavimo tvarka keičia elgesį labiau nei baudos.

Dažniausi klausimai

Ar SLA reikalingas, jei IT tiekėjas dirba gerai?

Taip. SLA reikalingas ne tam, kad nubaustų, o tam, kad abi pusės vienodai suprastų lūkesčius. Su gerai dirbančiu tiekėju jį parašyti daug lengviau.

Koks reakcijos laikas yra realus?

Priklauso nuo aptarnavimo modelio. Darbo valandomis dvi keturios valandos kritiniams incidentams yra įprasta. Ne darbo valandomis tai reikalauja budėjimo, kuris kainuoja atskirai — todėl svarbu nurodyti, kada laikrodis sukasi.

Ar verta SLA įtraukti pasiekiamumo procentą?

Verta, jei galite jį išmatuoti nepriklausomai. Priešingu atveju geriau apsiriboti incidentų terminais, kuriuos matote abi pusės.

SUSIJUSIOS PASLAUGOS