SLA-urile sunt promisiuni făcute clienților - OLA-urile se asigură că echipele tale interne le pot respecta. Cu Trupeer, poți economisi ore la redactarea OLA-urilor pornind de la un șablon gratuit de acord de nivel operațional, personalizându-l cu ghidurile de brand și transformând OLA-ul într-un tur video care aliniază fiecare echipă internă în spatele unor standarde comune de servicii.

Ce este un șablon de acord de nivel operațional?

Un acord de nivel operațional, sau OLA, este un acord intern între echipe din aceeași organizație care susține o angajare făcută cuiva din afara ei. Service desk-ul promite business-ului o rezoluție în patru ore pentru incidentele majore. Promisiunea aceasta ține doar dacă echipa de rețea, echipa de aplicații și oricine altcineva se află în lanț își joacă rolul în intervalul de timp cunoscut.

OLA-ul este locul unde aceste componente interne sunt consemnate. Nu este un contract, nimeni nu plătește pe nimeni, iar aplicarea este în întregime managerială—și acesta este atât punctul său slab, cât și motivul pentru care poate fi sincer în moduri pe care un contract nu le poate.

Un șablon de acord de nivel operațional este structura reutilizabilă: părțile, serviciile acoperite, angajamentele, măsurile și aranjamentele de revizuire. Șabloanele de acest tip sunt ușor de găsit. Majoritatea îți vor permite să scrii un OLA pe deplin conform, dar care totuși eșuează—iar despre asta este restul paginii.

OLA vs SLA: la ce se angajează fiecare, de fapt

Trei documente stau în aceeași familie, iar amestecarea lor creează probleme reale.

Un service level agreement este angajamentul față de client sau față de business. Este scris în termenii clientului, de obicei cap-coadă, și este ceea ce se raportează persoanelor din afara lanțului de livrare.

Un operational level agreement este intern, între echipe care raportează ambele către aceeași organizație. Există exclusiv ca să facă SLA-ul realizabil și nu ar trebui să includă niciodată un angajament de care SLA-ul nu are nevoie.

Un underpinning contract este acordul comercial cu o terță parte, un furnizor sau un provider externalizat, care susține același lanț. Are forță juridică, spre deosebire de OLA, și de obicei are cea mai mică flexibilitate dintre cele trei, așa că ar trebui convenit înainte de SLA, nu după.

Consecința practică este o regulă de secvențiere. Conveniți underpinning contractele, apoi SLA-ul în raport cu ce permit acele contracte, apoi OLA-urile care completează restul. Organizațiile care fac în ordine inversă promit în mod obișnuit business-ului ceva pe care niciun furnizor nu a fost de acord să livreze.

Cum să personalizezi acest șablon în Trupeer

Pasul 1: Deschide secțiunea Șabloane

Accesează secțiunea Șabloane din meniul principal.

Pasul 2: Selectează și deschide un șablon

Dă click pe orice șablon cu care vrei să lucrezi pentru a-l deschide.

Pasul 3: Extinde vizualizarea șablonului

Dacă este necesar, extinde vizualizarea șablonului pentru a vedea clar layoutul complet și detaliile.

Pasul 4: Editează șablonul

Dă click pe Edit pentru a începe să modifici șablonul selectat.

În editor, poți:

• Adaugă secțiuni noi

• Definește sau actualizează reguli de formatare

• Adaugă un logo și ajustează poziția acestuia și setările aferente

Pasul 5: Salvează șablonul personalizat

După ce faci toate modificările necesare, dă click pe Save pentru a salva șablonul actualizat ca al tău.

Pasul 6: Previzionează și ajustează fin șablonul

Când vrei să vezi cum arată șablonul tău personalizat, deschide Preview.

Din ecranul de previzualizare, poți continua să faci ajustări direct, dacă este nevoie, asigurându-te că șablonul apare exact așa cum îl dorești.

Cu un șablon de acord de nivel operațional poți:

• Economisești ore la redactare: Sari peste pagina goală, cu o structură construită pentru OLA-uri.

• Aliniezi echipele interne: Câmpurile integrate se asigură că fiecare echipă își cunoaște responsabilitatea.

• Rămâi în ton cu brandul: Aplică logo-ul, fonturile și culorile folosind brand kit-ul Trupeer.

• Protejezi SLA-urile clienților: OLA-urile solide previn ca predările interne să strice promisiunile externe.

• Standardizezi între servicii: Folosește același șablon de OLA pentru fiecare acord intern.

• Ajungi la echipe globale: Tradu OLA-urile în 65+ limbi cu un singur click.

De ce fiecare echipă își respectă OLA-ul, iar SLA-ul totuși este încălcat

Acesta este cel mai comun tipar în managementul serviciilor și pare o contradicție.

Fiecare echipă raportează verde. Rețeaua răspunde în interiorul orei sale. Aplicațiile rezolvă în interiorul celor două ore. Service desk-ul triagează în treizeci de minute. Raportul lunar de conformitate OLA este ușor de citit. Iar SLA-ul clientului este încălcat la o treime din incidentele majore.

Explicația este că OLA-urile măsoară timpul în interiorul echipelor, iar SLA-ul măsoară timpul cap-coadă. Diferența dintre cele două numere este timpul de tranzit: tichetul care stă într-o coadă după realocare, așteptând să fie preluat sau returnat pentru informații suplimentare.

Timpul acesta nu aparține nimănui. Nu este în OLA-ul nimănui, nu este raportat nicăieri și, de multe ori, este mai mare decât tot timpul de lucru cumulat.

Asta înseamnă că problema este structurală, nu una de performanță. Adăugarea de presiune ca echipele să-și atingă numerele existente nu va ajuta, pentru că ele le ating deja.

OLA-ul guvernează predarea, nu munca

Reîncadrarea care rezolvă problema este mică și schimbă scopul documentului.

Un OLA scris în mod obișnuit angajează o echipă cu privire la cât durează munca ei proprie. Aceasta este partea pe care echipa o controlează, deci este partea pe care e dispusă să o semneze și este și cea mai puțin utilă ca să fie convenită, fiindcă nu a fost niciodată variabila.

Un OLA scris bine angajează echipele cu privire la interfața dintre ele. Ce trebuie să fie într-un tichet înainte să fie predat. Cât timp are echipa care îl primește să îl preia. Ce se întâmplă când tichetul este incomplet. Cine deține tichetul în perioada de gol.

Odată ce predarea devine subiectul, cele două câmpuri lipsă devin evidente. Criteriile de intrare, adică ce trebuie să fie adevărat înainte să înceapă ceasul echipei care primește. Și o alocare explicită a timpului de tranzit în sine, astfel încât golul dintre echipe să fie numărul cuiva, nu al nimănui.

Restul dintr-un șablon de OLA este administrație. Aceste două sunt documentul.

Criterii de intrare: ce trebuie să fie adevărat înainte să înceapă ceasul

Cel mai distructiv comportament într-un lanț cu mai multe echipe este „bouncing”: un tichet ajunge fără suficiente informații, echipa care îl primește îl returnează, iar ceasul ei se resetează.

„Bouncing”-ul este complet rațional din perspectiva echipei care primește. Nu pot lucra tichetul, iar conformitatea lor este măsurată în funcție de timpul lor de rezoluție, deci returnarea îl protejează pe amândoi. Este și locul în care se duce o mare parte din timpul scurs și este invizibil în orice raport care măsoară echipele separat.

Criteriile de intrare îl rezolvă mutând obligația în amonte. Fiecare rând din OLA listează câmpurile specifice care trebuie completate pentru ca acea echipă să accepte munca. Pentru o predare de rețea, ar putea fi numele dispozitivului, codul de locație, textul exact al erorii, momentul primei observări și dacă sunt afectați alți utilizatori. Pentru o predare de aplicații, ar putea fi utilizatorul, referința tranzacției, pașii pentru reproducere și o captură de ecran.

Apoi, angajamentul echipei care trimite își schimbă formularea. Nu „triage în treizeci de minute”, ci „predă un tichet care îndeplinește criteriile de intrare în treizeci de minute”. Același ceas, altă obligație, iar stimulentul se mută acum la echipa care poate colecta efectiv informațiile.

Echipa care primește păstrează dreptul de a respinge, iar acesta ar trebui să fie unul îngust: respingerea este valabilă doar atunci când un criteriu de intrare numit lipsește cu adevărat, iar fiecare respingere este înregistrată cu motivul. Înregistrarea este ceea ce transformă „bouncing”-ul dintr-un obicei invizibil într-un număr pe care cineva trebuie să-l explice.

Șablon gratuit de acord de nivel operațional: structura de copiat

Copiază de aici. Câmpurile marcate cu un asterisc sunt cele pe care șabloanele standard le omit.

Header. Referință și versiune OLA. Părțile, adică cele două echipe, numite. SLA-ul sau serviciul pe care îl susține. Data efectivă, data revizuirii și proprietarul numit de fiecare parte.

Scope. Ce servicii, sisteme sau tipuri de solicitări acoperă și, explicit, ce nu acoperă.

Service hours. Acoperire pentru fiecare parte, inclusiv aranjamentele pentru în afara programului și modul în care diferă. Ore nealiniate între două echipe din același lanț este un decalaj comun și, în tăcere, fatal.

Tabel de angajamente. Un rând pentru fiecare tip de solicitare sau prioritate, cu: declanșatorul, criteriile de intrare, timpul de răspuns, timpul de rezoluție sau de predare înapoi, timpul de tranzit alocat și punctul de escaladare.

Escalation. Cine este contactat în fiecare etapă, pe ce traseu și după cât timp. Include calea pentru în afara programului.

Dependencies. De ce are nevoie această echipă de la alții, inclusiv orice underpinning contract cu o terță parte, cu propriile intervale de timp notate, astfel încât calculele să poată fi verificate.

Measurement. Ce se măsoară, din ce sistem, de către cine și cât de des este raportat. Include bounce rate alături de răspuns și rezoluție, deoarece este indicatorul care arată dacă criteriile de intrare funcționează.

Exceptions. Circumstanțe convenite în care angajamentele nu se aplică, precum în timpul unui incident major declarat sau în timpul unei perioade de înghețare a schimbărilor.

Review. Datele și ce declanșează o revizuire în afara ciclului.

Copiază până aici. Păstrează-l la două sau trei pagini. Un OLA suficient de lung încât să necesite citire de două ori nu va fi consultat în timpul unui incident, iar în timpul unui incident contează.

Cum să verifici dacă OLA-urile se adună cu adevărat la SLA

Înainte să semnezi orice, fă calculele. Durează cincisprezece minute și este omis aproape universal, deoarece OLA-urile sunt negociate câte unul, cu echipe diferite, în zile diferite.

Două reguli fac acest lucru util. Timpul de tranzit trebuie să apară ca o linie separată, pentru că acesta este întregul scop. Iar fiecare lanț are nevoie de marjă, deoarece un lanț care se adună exact la SLA va încălca SLA-ul ori de câte ori ceva, oricât de mic, merge ușor prost. Zece până la cincisprezece la sută este o marjă rezonabilă.

Dacă suma depășește SLA-ul, ai trei opțiuni oneste: renegociază SLA-ul, reduce timpul unei echipe cu ceva care face posibil acest lucru sau elimină o predare. Ceea ce nu poți face este să semnezi OLA-uri care garantează o încălcare și apoi să gestionezi performanța în raport cu ele—aceasta este poziția surprinzător de multor service desk-uri.

Retailerul al cărui timp de tranzit a fost mai lung decât munca

Rendlesham Group operează mai multe branduri de retail, cu aproximativ șase mii de angajați și un service desk IT intern care susține magazinele și sediul central.

SLA-ul incidentelor P2 față de business era de patru ore până la rezoluție. Rata de încălcare pe P2 se menținuse în jur de treizeci și opt la sută timp de doi ani. Conformitatea OLA a fiecărei echipe era raportată lunar și fiecare echipă era verde.

Cineva a pus în sfârșit timestamp-uri pentru fiecare schimbare de stare la o sută douăzeci de incidente P2 încălcate.

Timpul total median scurs a fost de șase ore cincizeci și unu de minute. Din acesta, trei ore douăsprezece minute au fost timp în interiorul unei echipe care lucra activ tichetul. Trei ore treizeci și nouă minute au fost tranzitul: stat în coadă după realocare, așteptând să fie preluat sau returnat.

Mai mult de jumătate din timpul scurs la un incident încălcat era deținut de nimeni și raportat nicăieri.

Cel mai mare contributor a fost „bouncing”-ul. Patruzeci și unu din cele o sută douăzeci de tichete fuseseră returnate cel puțin o dată de către o echipă care primește din cauza informațiilor insuficiente, iar fiecare „bounce” a adăugat o mediană de o oră douăzeci de minute, plus resetarea ceasului acelei echipe. Cele mai comune două motive au fost lipsa textului de eroare sau a unei capturi de ecran atașate și lipsa confirmării despre ce magazin era afectat incidentul.

Schimbările au fost înguste. Criteriile de intrare au fost scrise în fiecare rând din OLA. Angajamentul service desk-ului a fost rescris din „triage în treizeci de minute” în „predă un tichet care îndeplinește criteriile de intrare în treizeci de minute”. Au fost alocate cincisprezece minute de tranzit pentru fiecare predare și au fost contorizate împotriva echipei care primește odată ce criteriile de intrare au fost îndeplinite. Iar fiecare „bounce” a fost înregistrat cu un motiv.

În următoarele două trimestre, rata de „bounce” a scăzut de la treizeci și patru la sută din P2-uri la nouă. Timpul median de tranzit a scăzut de la trei ore treizeci și nouă de minute la o oră șase. Rata de încălcare P2 a scăzut de la treizeci și opt la sută la unsprezece.

Timpul intern de rezoluție al niciunei echipe nu s-a schimbat semnificativ. Nimeni nu a lucrat mai repede. Timpul care aparținuse nimănui a fost pur și simplu dat cuiva.

Cum să redactezi un acord de nivel operațional, pas cu pas

Pornește de la SLA, nu de la un șablon. Notează ce i s-a promis clientului, cap-coadă, cu definiția ceasului.

Cartografiază lanțul. Fiecare echipă care atinge o solicitare de acest tip, în ordine, inclusiv orice terță parte. Desenează predările ca pași separați, nu ca săgeți.

Pentru fiecare predare, pune o singură întrebare echipei care primește: de ce ai nevoie în tichet ca să începi munca fără să ne mai trimiți înapoi. Răspunsul, notat, sunt criteriile de intrare. Echipele răspund ușor și precis, iar majoritatea nu au fost niciodată întrebate.

Acum conveniți timpii, lucrând în interiorul calculelor de mai sus, nu echipă cu echipă. Făcând asta ca o singură discuție cu toți cei prezenți durează o oră și previne complet problema sumei.

Alocă explicit timpul de tranzit și decide cine îl deține. Cincisprezece minute per predare este un punct de plecare rezonabil și ar trebui contorizat împotriva echipei care primește.

Conveniți măsurarea, inclusiv bounce rate, și de unde provine. Dacă instrumentele tale nu îl pot produce, merită să știi asta înainte să semnezi, nu la prima revizuire.

Apoi rulează-l timp de un trimestru înainte să îl formalizezi. Primele versiuni sunt de obicei greșite în una sau două locuri și este mai ușor să le corectezi înainte să existe semnături.

Greșeli comune la OLA și ce costă fiecare

Măsurarea echipelor și nu a lanțului. Toată lumea e verde și SLA-ul se încalcă. Cea mai frecventă problemă și subiectul acestei pagini.

Fără criterii de intrare. „Bouncing”-ul devine apărarea rațională a echipei care primește, iar timpul scurs crește invizibil.

Timpi care nu se adună. Setul de OLA garantează o încălcare și nimeni nu l-a adunat vreodată.

Ore de service nealiniate. O echipă acoperă până la șase, următoarea până la cinci. Tot ce ajunge după cinci stă peste noapte, iar niciun raport nu arată asta, fiindcă ambele echipe sunt în interiorul orelor lor.

Copierea limbajului din SLA în OLA. Penalitățile, creditele și formulările juridice nu au ce căuta aici, iar importarea lor face echipele să negocieze defensiv în loc să negocieze sincer.

Scrierea unui OLA cu o terță parte. Dacă se schimbă bani, este un underpinning contract și are nevoie de implicarea procurement și juridic, nu de un șablon. Șablonul nostru de politică de procurement IT acoperă traseul de aprobare.

Semnare și arhivare. Un OLA pe care nimeni nu îl revizuiește descrie un lanț de servicii care nu mai există în aproximativ un an.

Cum să gestionezi și să revizuiești OLA-urile odată ce există

Raportează lanțul, nu componentele. Contează un singur număr: performanța cap-coadă față de SLA, iar metricile OLA există ca să o explice, nu ca să stea singure.

Revizuiește trimestrial, cu toate părțile în aceeași încăpere. Revizuirile bilaterale reproduc problema inițială, deoarece golurile trăiesc între părțile care nu sunt niciodată în aceeași conversație.

Urmărește trei lucruri. Bounce rate pe predare, care îți spune unde trebuie lucrat la criteriile de intrare. Timpul de tranzit pe predare, care îți spune unde se formează cozile. Și proporția incidentelor care au urmat un traseu pe care OLA-ul nu îl descrie, ceea ce îți arată că documentul s-a îndepărtat de realitate.

Declanșează o revizuire în afara ciclului când o echipă se reorganizează, când un sistem se mută între echipe, când intră o terță parte în lanț sau când se schimbă SLA-ul. Toate cele patru se întâmplă mai des decât presupune ciclul anual de revizuire.

OLA, SLA sau underpinning contract: de care ai nevoie?

Dacă angajamentul este față de cineva din afara organizației tale de livrare—fie un client extern, fie o unitate de business internă deservită—atunci este un SLA.

Dacă este între două echipe din aceeași organizație, fără ca banii să se schimbe între ele, atunci este un OLA.

Dacă este cu un furnizor în baza unui aranjament comercial, atunci este un underpinning contract și are nevoie de juridic și procurement, nu de acest șablon.

Cazul incomod este centrul de servicii partajate sau o echipă internă cu model de chargeback, care se află între un OLA și un SLA. Răspunsul practic este să îl scrii ca un OLA și să renunți la orice limbaj despre penalități, deoarece regimurile interne de penalități produc în mod fiabil comportament defensiv și servicii mai slabe.

Pentru definițiile orientate către client și formulările de răspuns care stau deasupra tuturor acestora, șablonul nostru de răspuns pentru help desk și șablonul de tichet și rezoluție acoperă stratul pe care utilizatorul final îl vede efectiv.

Pot primi un șablon de OLA în Word sau Excel?

Word pentru acord, deoarece scope-ul, excepțiile și secțiunile de revizuire sunt redactate în text, iar documentul este distribuit pentru semnare.

Excel pentru două părți, în mod specific. Tabelul de angajamente, unde vrei criteriile de intrare, timpii și alocarea tranzitului în coloane pe care le poți sorta și verifica. Și foaia de calcule, unde fiecare lanț se adună la SLA-ul său și marchează orice fără marjă. A doua foaie este cea care merită construită prima, deoarece adesea schimbă ceea ce urma să negociezi.

PDF pentru versiunea semnată, exportată din sursă. Păstrează versiunea de lucru editabilă, deoarece criteriile de intrare vor trebui ajustate după primul trimestru de „bouncing” real.

Cum să ții OLA-ul și realitatea în pas

Un OLA descrie un lanț de lucru care se schimbă constant. Echipele se reorganizează, sistemele se mută, instrumentele se schimbă, iar documentul este ultimul lucru pe care îl actualizează cineva.

Partea care se învechește cel mai repede sunt criteriile de intrare, deoarece descriu ce trebuie să conțină un tichet, iar ce trebuie să conțină un tichet depinde de cum funcționează efectiv instrumentele curente și procesul curent.

Trupeer AI ajută făcând procedurile de bază ieftine de menținut la zi. Înregistrează o singură dată procesul de triere sau predare și obții o procedură scrisă cu pașii și ecranele capturate, pe care service desk-ul o poate urma și care arată clar ce informații se colectează. Când se schimbă instrumentele, reînregistrează, nu rescrie.

Înregistrează-l. Pune-i brandul. Tradu-l. Trupeer-l.

SOP creator acoperă procedurile de care depinde OLA-ul, iar șablonul nostru IT SOP acoperă cum să decizi care dintre ele merită menținute. Documentation păstrează acordurile și procedurile împreună, iar instrucțiunile de configurare sunt în document template setup guide.

Întrebări frecvente

Există un șablon gratuit de acord de nivel operațional în Word?

Structura de mai sus se lipește direct în Word sau Google Docs, inclusiv câmpurile criteriilor de intrare și alocării tranzitului pe care șabloanele standard le omit. Nu există descărcare cu acces restricționat și niciun formular. Păstrează tabelul de angajamente într-o foaie de calcul și fă-i referință, deoarece partea aceea trebuie sortată și însumată.

Există un șablon gratuit de acord de nivel operațional în PDF?

Exportă versiunea semnată în PDF o dată ce părțile au convenit asupra ei și păstrează copia de lucru editabilă. Criteriile de intrare au nevoie aproape întotdeauna de ajustări după primul trimestru, odată ce poți vedea pentru ce tichete sunt returnate efectiv.

Există un șablon gratuit de acord de nivel operațional în Excel?

Excel este locul potrivit pentru tabelul de angajamente și pentru verificarea calculelor. O foaie cu un rând pentru fiecare predare și un total în derulare față de SLA, care marchează orice lanț cu mai puțin de zece la sută marjă. Construirea acelei foi înainte să negociezi tinde să schimbe ceea ce ajunge să fie negociat.

Unde pot găsi un exemplu PDF de acord de nivel operațional?

Mai mulți furnizori ITSM și instituții guvernamentale publică șabloane de OLA și SLA ca documente și sunt rezonabile ca structură. Citește-le pentru secțiuni, nu pentru conținut, deoarece angajamentele din orice exemplu publicat sunt lanțul altcuiva, iar timpii nu au sens în afara SLA-ului pentru care au fost construite.

Cine semnează un acord de nivel operațional?

Proprietarul numit de fiecare parte, care ar trebui să fie managerul responsabil pentru livrarea acelei echipe, nu o funcție de service management. Un OLA semnat doar de service management este o aspirație, deoarece persoana care trebuie să aloce resursele nu a fost în încăpere.

De câte OLA-uri are nevoie un service desk?

Mai puține decât se așteaptă majoritatea echipelor. Unul pentru fiecare pereche de echipe care schimbă în mod regulat lucru, acoperind toate tipurile de solicitări într-un singur tabel de angajamente, nu unul pentru fiecare service. După aproximativ o duzină, mentenanța devine constrângerea și documentele se învechesc mai repede decât sunt revizuite.

Un acord de nivel operațional ar trebui să aibă penalități?

Nu. Nu există o relație juridică de impus și regimurile interne de penalități produc în mod fiabil comportament defensiv: echipele resping munca, discută despre când începe ceasul și optimizează pentru propriul lor număr, nu pentru rezultat. Raportează lanțul cap-coadă în schimb, ceea ce face consecința comună vizibilă fără ca cineva să fie amendat.

Cât de des ar trebui revizuite OLA-urile?

Trimestrial, cu toate părțile prezente, plus o revizuire în afara ciclului ori de câte ori o echipă se reorganizează, un sistem se mută între echipe, intră o terță parte în lanț sau se schimbă SLA-ul subiacent. Ritmul trimestrial prinde deriva, iar declanșatoarele prind schimbările care fac documentul greșit peste noapte.