Revista si suplimente
MarketWatch
Inapoi Inainte

Cum să gândim un SLA?

15 Martie 2010



Domeniul outsourcingului este unul destul de standardizat la nivel de procese. Procesul central este cel de management al serviciilor care se reflectă în contractul de servicii cu clientul sub forma unui SLA (Service Level Agreement).

Dar SLA-ul nu este un contract ca oricare altul. Şi nici nu poate fi generat dacă celelalte procese necesare serviciilor nu sunt puse la punct. Avem de a face cu o metodologie foarte cunoscută, ITIL, care a devenit între timp şi un standard ISO – ISO 20.000. Standardul ITIL descrie o serie de procese deosebit de importante atât la nivelul beneficiarului de servicii de outsourcing, cât şi la nivel de client.


SLA-ul este un contract de servicii între două părţi care vorbesc aceeaşi limbă, care folosesc un set similar de cunoştiinţe şi procese aferente. Fiecare proces dintr-o organizaţie trebuie să-şi găsească replica în cealaltă organizaţie. Pot să fie şi diferenţe majore, dar în faza de implementare a contractului trebuie găsite soluţiile de acoperire a diferenţelor, găsirea soluţiilor alternative. Neglijarea unui aspect poate crea ulterior probleme care se vor afla într-o zonă gri, neacoperită de la început.


SLA-ul va preciza iniţial ce Servicii se doresc, ca tipuri/descriere, care este timpul de rezolvare a serviciului şi care este modul de finalizare şi închidere a solicitării. Vorbind de o solicitare vorbim practic de un process conex, unul dintre cele mai importante procese ITIL, cel de management al incidentelor.


Nu ajunge ca un SLA să prevadă doar în cât timp se rezolvă un incident dacă nu se specifică ce este incidentul, cum este comunicat între părţi, care este momentul de demarare a contorizării perioadei de responsabilitate a furnizorului. Un incident poate fi complex, de aceea contractual, vor trebui să prevadă fazele tratării unui incident. Nu ajunge a trece în SLA că incidentul se rezolvă în 4 ore, dacă el necesită piese de schimb şi piesele de schimb sunt furnizate de client. Practic, furnizorul va aştepta piesa, conform contractului, până o va primi, poate şi peste 3 zile, şi apoi va finaliza intervenţia, conform contractului. Deci cele 4 ore s-au transformat în 3 zile şi 4 ore. Un SLA prost făcut implică costuri mari la nivel de client. Dacă furnizorului i se cere rezolvarea în 4 ore, el va propune un cost al intervenţiei aferent unei perioade scurte de timp, deci un cost mai mare. Dacă s-ar fi cerut 3 zile, costul cerut ar fi fost mult mai mic. Uneori se cer SLA-uri strânse care apoi se constată că nu sunt necesare sau că nu se pot aplica din perspectiva clientului. Această cerinţă, justificată iniţial ca o cerinţă de calitate înaltă, şi pe care furnizorul poate să o îndeplinească, se transformă într-o cerinţă cu un cost prea mare, având în vedere că nu poate fi executată datorită unor procese interne ale clientului sau unor factori externi necorelaţi corespunzător.


Un contract de servicii trebuie să prevadă pe lângă serviciile respective şi modul lor de derulare. Altfel mii de interpretări şi situaţii speciale vor apărea şi vor genera discuţii neproductive. Un plan de escaladare şi reconciliere este oricum foarte important şi trebuie să facă parte din SLA.


SLA-urile se referă la derularea unor servicii asupra unei componente a infrastructurii clientului. Acea componentă trebuie să fie bine identificată şi, de obicei, trebuie să se regăsească într-o bază de date de configuraţii (CMDB- Configurations Management Database). Componenta de infrastructură – CI (Configuration Item) -, de exemplu un PC, trebuie să fie clar identificată şi ambele părţi ale contractului trebuie să o poată identifica corect. Acel CI este conectat cu alte CI-uri (de exemplu soft-ul de pe PC). Pentru a putea rezolva incidentul trebui să ai acces la toate informaţiile şi să faci o constatare corectă. Dacă clientul cere repararea hardware a PC-ului, dar problema este la software, practic o nouă cerinţă trebuie înregistrată. Deci al doilea process ITIL important este cel al managementului configuraţiilor.


Am vorbit în acest articol de două procese importante corelate cu procesul de Service Level Management (SLM), care se concretizează în cadrul unui SLA. Dar nu sunt singurele.




Dr. Călin Rangu
CEO IIRUC service



Tags: SLA, outsourcing

Parerea ta conteaza:

(0/5, 0 voturi)

Lasa un comentariu



trimite
Cristian Stanca
Este un teren nou pentru multe firme din Romania si am constatat ca exista multe "bune practici" care nu au fost intelese corect sau care nu se pot aplica in cazul specific al unui serviciu. Tuturor le place ideea de calitate si organizare, insa uita cea mai importanta nota din aceste "bune practici": un SLA trebuie sa corespunda tipului de serviciu, competentelor oamenilor si bugetului alocat. Altfel, este doar un vis frumos care va genera asteptari si in final, dejamagiri. Furnizorii si beneficiarii confunda foarte mult notiunile invatate pe de rost. Cel mai importante aspecte fiind: 1. nivelul serviciului - se refera la disponibilitatea produsului livrat (cat de bun este produsul pentru care ai platit) 2. nivelul suportului tehnic - se refera la disponibilitatea personalului furnizorului (in cat timp se implica furnizorul sa intervina si sa rezolve un incident). Astfel, furnizorul nu stie ce a vandut, beneficiarul nu intelege ce a cumparat. Un exemplu: ca si furnizor, poti asigura o disponibilitate a serviciului de 99% (maxim 87 ore pe an, nefunctionare a serviciului) si sa nu fi obligat sa raspunzi intr-o ora sau sa repari in 4 ore. NU AU LEGATURA UNA CU ALTA.
09 Februarie 2011, 12:19:16