Un SLA (Service Level Agreement) în mentenanța IT este anexa care transformă promisiuni vagi precum „suport rapid” în cifre verificabile: în cât timp se răspunde la o sesizare, în cât timp se rezolvă, în ce interval orar și ce penalități se aplică dacă acești timpi nu sunt respectați. Ce să ceri concret: timpi de răspuns și de rezolvare separați, pe minimum trei niveluri de prioritate (P1/P2/P3), un mecanism de credite de serviciu și un raport lunar care îți permite să verifici totul singur. Mai jos găsești timpi realiști și capcanele de evitat.
Ce este de fapt un SLA și ce nu este
SLA-ul nu este contractul de mentenanță în sine — este anexa tehnică din care reiese, în cifre, ce nivel de serviciu cumperi. Un contract bun de mentenanță IT are întotdeauna un SLA atașat; dacă lipsește, nu ai cumpărat un nivel de serviciu, ci o intenție.
Greșeala frecventă este să te uiți doar la prețul abonamentului. Două oferte la 1.500 lei/lună pot fi radical diferite: una îți garantează răspuns în 30 de minute la incidente critice cu penalități scrise, cealaltă spune „ne ocupăm cât putem de repede”. La prima problemă serioasă, diferența dintre ele costă mai mult decât toată economia pe abonament.
Un SLA serios definește, la minimum: nivelurile de prioritate și cum se clasifică un incident, timpii de răspuns și de rezolvare pentru fiecare nivel, fereastra de suport, excluderile (ce NU intră în SLA), modul de raportare și penalitățile.
Timp de răspuns vs. timp de rezolvare — nu le confunda
Aici se ascund cele mai multe neînțelegeri. Cei doi indicatori măsoară lucruri diferite și trebuie scriși separat în contract.
- Timpul de răspuns (response time) — intervalul de la deschiderea tichetului până când un tehnician confirmă că a preluat problema și lucrează la ea. Este ușor de garantat și de respectat.
- Timpul de rezolvare (resolution time) — intervalul până când serviciul revine efectiv la normal. Este mai greu de garantat, fiindcă depinde și de cauză: o parolă resetată durează 5 minute, un hard disk ars într-un server fără redundanță poate dura o zi.
Capcana clasică: un furnizor îți promite „răspuns în 15 minute” și tu crezi că problema se rezolvă în 15 minute. În realitate, te sună cineva în 15 minute, îți spune „ne uităm”, și abia peste 6 ore lucrurile merg din nou. De aceea ceri întotdeauna și un timp de rezolvare-țintă, chiar dacă pentru incidentele complexe acesta e formulat ca „obiectiv rezonabil”, nu garanție absolută.
Niveluri de prioritate P1/P2/P3 cu timpi realiști
Standardul în industrie este clasificarea pe niveluri de prioritate în funcție de impact. Cu cât e mai mare numărul de utilizatori afectați și mai critic serviciul, cu atât prioritatea e mai mare. Iată un model concret și realist pentru o firmă mică/medie, cu suport în orele de program (L-V, 9-18):
| Prioritate | Exemplu de incident | Timp de răspuns | Timp de rezolvare-țintă |
|---|---|---|---|
| P1 — Critic | Server principal căzut, internet picat la toată firma, centrala telefonică nefuncțională, ransomware suspectat | 30-60 min | 4 ore |
| P2 — Major | Un departament afectat, o aplicație importantă inaccesibilă, o imprimantă de rețea esențială picată | 2-4 ore | 1 zi lucrătoare |
| P3 — Minor | Un singur utilizator, cerere de cont nou, întrebare de configurare, problemă cosmetică | 1 zi lucrătoare | 2-3 zile lucrătoare |
| P4 — Planificat | Solicitări de modificări, instalări programate, mentenanță preventivă | 2 zile lucrătoare | convenit de comun acord |
Câteva observații care fac diferența între un SLA realist și unul de fațadă:
- Cine stabilește prioritatea? În SLA trebuie scris explicit. Ideal: clientul propune, furnizorul confirmă, iar dacă există dezacord se discută. Un furnizor care își rezervă dreptul de a reclasifica orice P1 în P3 ca să nu plătească penalități a golit SLA-ul de conținut.
- Atenție la fereastra orară. Un răspuns „în 1 oră” care se aplică doar L-V 9-18 înseamnă că un incident apărut vineri la 17:50 poate fi tratat luni dimineață. Dacă firma ta lucrează și în weekend sau în ture, ai nevoie de o fereastră extinsă sau de un abonament cu garanție extinsă.
- Serverele merită SLA separat. Infrastructura critică (servere, virtualizare, baze de date) are de regulă timpi mai stricți și monitorizare proactivă, parte din mentenanța și administrarea serverelor. Nu trata serverul la fel ca un laptop.
Penalități și credite de serviciu — partea care dă dinți SLA-ului
Un SLA fără consecințe este o listă de bune intenții. Mecanismul standard se numește credite de serviciu (service credits): dacă furnizorul depășește timpii agreați, primești înapoi un procent din abonamentul lunar.
Un model rezonabil arată cam așa:
- Depășire la un incident P1 — credit de 10-15% din abonamentul lunar per incident.
- Depășire la un incident P2 — credit de 5-10%.
- Sub un anumit prag de respectare (ex. mai puțin de 90% din tichetele lunare în SLA) — credit suplimentar sau drept de reziliere fără penalități.
Două principii de bun-simț: pune un plafon (de obicei creditul lunar total nu depășește 25-50% din abonament — niciun furnizor sănătos nu acceptă să lucreze pe pierdere) și definește clar excluderile. Nu poți penaliza furnizorul pentru o pană de curent la sediul tău, o defecțiune a furnizorului de internet sau o problemă cauzată de o modificare făcută de tine fără să-l anunți. Scrie aceste excluderi explicit, ca să nu devină mai târziu sursă de conflict.
Cum verifici lunar că SLA-ul e respectat
Aici se vede dacă furnizorul tău chiar măsoară sau doar promite. Cere un raport lunar de SLA generat din sistemul lui de ticketing. Un raport util conține:
- Lista tuturor tichetelor din lună, cu ID, prioritate și o descriere scurtă.
- Pentru fiecare tichet: data/ora deschiderii, data/ora primului răspuns, data/ora rezolvării.
- Indicarea clară a tichetelor care au respectat SLA-ul și a celor care l-au depășit.
- Procentul global de conformitate (ex. „96% din tichete în SLA”).
- Eventualele credite de serviciu datorate în luna respectivă.
Dacă furnizorul nu poate genera acest raport, înseamnă că nu folosește un sistem de ticketing sau nu măsoară nimic — în ambele cazuri, SLA-ul din contract e decorativ. Un partener serios îți oferă raportul proactiv, nu numai la cerere, și e dispus să discute lunar tendințele: tipuri de incidente recurente, probleme care ar merita rezolvate la rădăcină. Această conversație periodică este mai valoroasă decât orice cifră izolată și face parte dintr-o relație de externalizare IT matură.
Întrebări frecvente
Ce este un SLA în mentenanța IT?
SLA (Service Level Agreement) este anexa contractuală care definește în cifre ce nivel de serviciu primești: în cât timp se răspunde la o sesizare, în cât timp se rezolvă, în ce interval orar și ce se întâmplă dacă furnizorul nu respectă acești timpi. Fără SLA scris, „suport rapid” nu înseamnă nimic. Cu SLA, ai un standard măsurabil și penalități clare.
Care e diferența dintre timp de răspuns și timp de rezolvare?
Timpul de răspuns este intervalul de la deschiderea tichetului până când un tehnician confirmă că lucrează la problemă. Timpul de rezolvare este intervalul până când problema este efectiv reparată și serviciul revine la normal. Un furnizor poate răspunde în 15 minute dar rezolva în 6 ore — sunt doi indicatori complet diferiți și ambii trebuie scriși separat în contract.
Ce timpi de răspuns sunt realiști pentru o firmă mică sau medie?
Pentru un incident critic (P1 — toată firma blocată) un răspuns în 30-60 de minute în orele de program este realist și corect. Pentru P2 (un departament afectat) 2-4 ore, iar pentru P3 (cerere minoră) până la finalul zilei lucrătoare sau a doua zi. Timpii sub 15 minute pentru P1 există, dar presupun monitorizare 24/7 și costă semnificativ mai mult.
Ce sunt creditele de serviciu (service credits)?
Sunt penalități financiare predefinite: dacă furnizorul depășește SLA-ul, primești un procent din abonamentul lunar înapoi, de obicei 5-25% în funcție de gravitate. Scopul nu este să te îmbogățești, ci să creezi un stimulent real pentru respectarea timpilor. Un contract fără niciun mecanism de penalizare lasă SLA-ul fără dinți.
Cum verific lunar că SLA-ul este respectat?
Cere un raport lunar care să listeze toate tichetele, momentul deschiderii, momentul primului răspuns, momentul rezolvării și prioritatea fiecăruia. Calculezi procentul de tichete care s-au încadrat în SLA. Dacă furnizorul nu poate genera acest raport din sistemul lui de ticketing, înseamnă că nu măsoară nimic — un semnal de alarmă în sine.
Trebuie să cer SLA de 99,9% uptime pentru serverele mele?
Depinde de cât te costă o oră de nefuncționare. 99,9% înseamnă ~8,8 ore de indisponibilitate pe an, iar 99,99% înseamnă ~52 de minute, dar al doilea nivel presupune redundanță, monitorizare 24/7 și costuri mult mai mari. Stabilește mai întâi pierderea pe oră, apoi alege nivelul de uptime care se justifică economic, nu cifra cea mai impresionantă.
Pe scurt
Un SLA bun nu este despre cifrele cele mai mici cu putință, ci despre timpi realiști, scriși clar, cu penalități proporționale și un raport lunar care îți permite să verifici totul singur. Cere niveluri de prioritate explicite, separă răspunsul de rezolvare și asigură-te că ai cum să măsori. Vrei un contract de mentenanță cu SLA scris pe cifre, nu pe promisiuni? Contactează-ne și construim un nivel de serviciu pe măsura firmei tale.