Gli SLA fanno promesse ai clienti - gli OLA assicurano che i vostri team interni possano mantenerle. Con Trupeer, puoi risparmiare ore nella stesura degli OLA partendo da un modello gratuito di accordo sul livello operativo, personalizzandolo con le tue linee guida del brand e trasformando l'OLA in una presentazione video che allinea ogni team interno dietro standard di servizio condivisi.

Che cos'è un modello di accordo sul livello operativo (OLA)?

Un accordo sul livello operativo, o OLA (Operational Level Agreement), è un accordo interno tra team della stessa organizzazione che sostiene un impegno preso nei confronti di qualcuno all'esterno di essa. Il service desk promette all'azienda una risoluzione in quattro ore per gli incidenti principali. Tale promessa è valida solo se il team di rete, il team delle applicazioni e chiunque altro si trovi nella catena svolgono la propria parte entro un tempo prestabilito.

L'OLA è il documento in cui vengono messe per iscritto queste parti interne. Non si tratta di un contratto, nessuno paga nessuno e l'applicazione è interamente a livello manageriale, il che costituisce sia il suo punto debole sia il motivo per cui può essere onesto in modi che un contratto non può consentire.

Un modello di accordo sul livello operativo è la struttura riutilizzabile: le parti, i servizi coperti, gli impegni, le misure e le modalità di revisione. I modelli per questo scopo sono facili da trovare. La maggior parte di essi vi permetterà di scrivere un OLA pienamente rispettato ma che comunque fallisce, ed è proprio di questo che parla il resto di questa pagina.

OLA vs SLA: a cosa si impegna concretamente ciascuno

Tre documenti fanno parte di questa famiglia e confonderli causa problemi reali.

Un accordo sul livello di servizio (SLA) è l'impegno nei confronti del cliente o dell'azienda. È scritto nei termini del cliente, solitamente end-to-end, ed è ciò che viene riferito alle persone esterne alla catena di erogazione.

Un accordo sul livello operativo (OLA) è interno, tra team che fanno entrambi capo alla stessa organizzazione. Esiste al solo scopo di rendere realizzabile lo SLA e non dovrebbe mai contenere un impegno non richiesto dallo SLA.

Un contratto di supporto (underpinning contract) è l'accordo commerciale con una terza parte, un fornitore o un provider in outsourcing, che supporta la stessa catena. Ha forza legale, a differenza dell'OLA, e solitamente presenta la minore flessibilità tra i tre, per cui dovrebbe essere concordato prima dello SLA anziché dopo.

La conseguenza pratica è una regola di sequenziamento. Concordate i contratti di supporto, poi lo SLA in base a ciò che tali contratti consentono, e infine gli OLA che coprono la parte restante. Le organizzazioni che procedono nell'ordine inverso promettono regolarmente all'azienda qualcosa che nessun fornitore ha accettato di erogare.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dalla navigazione principale.

Passaggio 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passaggio 3: Espandi la visualizzazione del modello

Se necessario, espandi la visualizzazione del modello per vedere chiaramente il layout completo e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare il modello selezionato.

All'interno dell'editor puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le relative impostazioni

Passaggio 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passaggio 6: Visualizza l'anteprima e perfeziona il modello

Quando vuoi vedere come appare il tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello di accordo sul livello operativo puoi:

• Risparmiare ore di scrittura: Evita la pagina bianca grazie a una struttura creata appositamente per gli OLA.

• Allineare i team interni: I campi integrati assicurano che ogni team conosca la propria responsabilità.

• Rimanere in linea con il brand: Applica il tuo logo, font e colori utilizzando il brand kit di Trupeer.

• Proteggere gli SLA dei clienti: OLA solidi evitano che i passaggi di consegne interni compromettano le promesse esterne.

• Standardizzare tra i servizi: Usa lo stesso modello di OLA per ogni accordo interno.

• Raggiungere team globali: Traduci gli OLA in oltre 65 lingue con un solo clic.

Perché ogni team rispetta il proprio OLA eppure lo SLA viene violato

Questo è il pattern più comune nella gestione dei servizi e sembra una contraddizione.

Ogni team segnala uno stato verde. La rete risponde entro la sua ora. Le applicazioni risolvono entro le loro due ore. Il service desk esegue il triage entro trenta minuti. Il report mensile di conformità OLA è rassicurante. Eppure lo SLA del cliente viene violato in un terzo degli incidenti principali.

La spiegazione è che gli OLA misurano il tempo all'interno dei team, mentre lo SLA misura il tempo end-to-end. La differenza tra questi due numeri è il tempo di transito: il ticket fermo in coda dopo una riassegnazione, in attesa di essere preso in carico, o rimandato indietro per richiedere maggiori informazioni.

Quel tempo non appartiene a nessuno. Non è presente nell'OLA di nessuno, non viene registrato da nessuna parte e spesso è superiore a tutto il tempo di lavoro combinato.

Il che significa che il fallimento è strutturale piuttosto che un problema di performance. Aumentare la pressione sui team affinché raggiungano i loro numeri attuali non aiuterà, perché li stanno già raggiungendo.

L'OLA disciplina il passaggio di consegne, non il lavoro

Il cambio di prospettiva che risolve questo problema è piccolo ma cambia lo scopo del documento.

Un OLA scritto nel modo consueto impegna un team sulla durata del proprio lavoro. Quella è la parte che il team controlla, quindi è la parte che è disposto a firmare, ed è la cosa meno utile da concordare perché non è mai stata la variabile critica.

Un OLA scritto bene impegna i team sull'interfaccia tra di loro. Cosa deve esserci in un ticket prima che venga passato. Quanto tempo ha il team ricevente per prenderlo in carico. Cosa succede quando il ticket è incompleto. Chi possiede il ticket durante questa fase di transizione.

Una volta che il passaggio di consegne diventa l'oggetto dell'accordo, i due campi mancanti diventano evidenti. I criteri di ingresso, ovvero cosa deve essere vero prima che l'orologio del team ricevente inizi a scorrere. E un'allocazione esplicita del tempo di transito stesso, in modo che il divario tra i team sia associato al numero di qualcuno anziché di nessuno.

Tutto il resto in un modello di OLA è amministrazione. Questi due elementi costituiscono l'essenza del documento.

Criteri di ingresso: cosa deve essere vero prima che l'orologio parta

Il comportamento in assoluto più distruttivo in una catena multi-team è il rimpallo (bouncing): un ticket arriva senza informazioni sufficienti, il team ricevente lo restituisce e il loro orologio si azzera.

Il rimpallo è del tutto razionale dal punto di vista del team ricevente. Non possono lavorare sul ticket e la loro conformità viene misurata sul proprio tempo di risoluzione, quindi restituirlo protegge entrambi gli aspetti. È anche il punto in cui svanisce gran parte del tempo trascorso, ed è invisibile in ogni report che misura i team separatamente.

I criteri di ingresso risolvono questo problema spostando l'obbligo a monte. Ogni riga dell'OLA elenca i campi specifici che devono essere compilati affinché quel team accetti il lavoro. Per un passaggio di consegne di rete, questi potrebbero essere il nome del dispositivo, il codice del sito, il testo esatto dell'errore, l'ora in cui è stato osservato per la prima volta e se altri utenti sono interessati. Per un passaggio di consegne applicativo, potrebbero essere l'utente, il riferimento della transazione, i passaggi per riprodurre l'errore e uno screenshot.

In questo modo cambia la formulazione dell'impegno del team mittente. Non più "triage entro trenta minuti" ma "passare un ticket che soddisfi i criteri di ingresso entro trenta minuti". Stesso orologio, obbligo diverso, e l'incentivo ora spetta al team che può effettivamente raccogliere le informazioni.

Il team ricevente mantiene il diritto di rifiutare, che dovrebbe essere un diritto limitato: il rifiuto è valido solo laddove un criterio di ingresso specificato sia realmente mancante, e ogni rifiuto viene registrato con la relativa motivazione. La registrazione è ciò che trasforma il rimpallo da un'abitudine invisibile a un numero che qualcuno deve spiegare.

Modello di accordo sul livello operativo gratuito: la struttura da copiare

Copia da qui. I campi contrassegnati con un asterisco sono quelli che i modelli standard omettono.

Intestazione. Riferimento e versione dell'OLA. Parti, ovvero i due team indicati per nome. Lo SLA o il servizio supportato. Data di entrata in vigore, data di revisione e il referente designato per ciascuna parte.

Ambito. Quali servizi, sistemi o tipi di richiesta copre, ed esplicitamente cosa esclude.

Orari di servizio. Copertura per ciascuna parte, comprese le modalità fuori orario e le relative differenze. Gli orari non corrispondenti tra due team nella stessa catena rappresentano un divario comune e silenziosamente fatale.

Tabella degli impegni. Una riga per tipo di richiesta o priorità, con: il trigger, i criteri di ingresso, il tempo di risposta, il tempo di risoluzione o di riconsegna, il tempo di transito allocato e il punto di escalation.

Escalation. Chi viene contattato in ciascuna fase, attraverso quale canale e dopo quanto tempo. Includere il percorso fuori orario.

Dipendenze. Ciò di cui questo team ha bisogno da altri, compreso qualsiasi contratto di supporto con una terza parte, con i relativi tempi annotati per poter verificare i calcoli aritmetici.

Misurazione. Cosa viene misurato, da quale sistema, da chi e con quale frequenza viene segnalato. Includere il tasso di rimpallo insieme a risposta e risoluzione, poiché è la metrica che rivela se i criteri di ingresso stanno funzionando.

Eccezioni. Circostanze concordate in cui gli impegni non si applicano, come ad esempio durante un incidente grave dichiarato o un blocco delle modifiche (change freeze).

Revisione. Date e cosa attiva una revisione straordinaria.

Copia fino a qui. Limita il documento a due o tre pagine. Un OLA abbastanza lungo da richiedere una doppia lettura non verrà consultato durante un incidente, ed è proprio durante un incidente che conta.

Come verificare che gli OLA corrispondano effettivamente allo SLA

Prima di firmare qualsiasi cosa, fate i calcoli. Richiede quindici minuti e viene quasi universalmente saltato, perché gli OLA vengono negoziati uno alla volta con team diversi in giorni diversi.

Due regole rendono utile questo controllo. Il tempo di transito deve apparire come una riga a sé stante, perché questo è il punto fondamentale. E ogni catena ha bisogno di un margine di tolleranza (headroom), perché una catena la cui somma equivale esattamente allo SLA subirà una violazione non appena qualcosa andrà minimamente storto. Una percentuale compresa tra il dieci e il quindici percento rappresenta un margine ragionevole.

Se la somma supera lo SLA, avete tre opzioni oneste: rinegoziare lo SLA, ridurre il tempo di un team fornendogli strumenti che lo rendano possibile, oppure eliminare un passaggio di consegne. Quello che non potete fare è firmare OLA che garantiscono una violazione per poi gestire le performance in base a essi, che è la situazione in cui si trova un numero sorprendente di service desk.

Il retailer il cui tempo di transito era più lungo del tempo di lavoro

Rendlesham Group gestisce diversi marchi di vendita al dettaglio con circa seimila dipendenti e un service desk IT interno che supporta i negozi e la sede centrale.

Il suo SLA per gli incidenti P2 verso il business era di quattro ore per la risoluzione. Il tasso di violazione sui P2 si era attestato intorno al trentotto percento per due anni. La conformità OLA di ogni team veniva segnalata mensilmente e ogni team era contrassegnato in verde.

Qualcuno ha finalmente registrato i timestamp di ogni cambio di stato su centoventi incidenti P2 violati.

Il tempo totale trascorso mediano era di sei ore e cinquantuno minuti. Di questo, tre ore e dodici minuti rappresentavano il tempo all'interno di un team che lavorava attivamente sul ticket. Tre ore e trentanove minuti erano transito: ticket fermi in coda dopo una riassegnazione, in attesa di presa in carico o rimpallati.

Più della metà del tempo trascorso su un incidente violato non apparteneva a nessuno e non veniva registrato da nessuna parte.

Il fattore che contribuiva maggiormente era il rimpallo. Quarantuno dei centoventi ticket erano stati restituiti almeno una volta da un team ricevente per informazioni insufficienti, e ogni rimpallo aggiungeva una mediana di un'ora e venti minuti, oltre ad azzerare l'orologio di quel team.

Le modifiche apportate sono state mirate. I criteri di ingresso sono stati scritti in ogni riga dell'OLA. L'impegno del service desk è stato riformulato da triage entro trenta minuti a passaggio di un ticket conforme ai criteri di ingresso entro trenta minuti. Sono stati allocati quindici minuti di transito per ogni passaggio di consegne, conteggiati a carico del team ricevente una volta soddisfatti i criteri di ingresso. E ogni rimpallo è stato registrato con una motivazione.

Nei due trimestri successivi, il tasso di rimpallo è sceso dal trentaquattro percento dei P2 al nove. Il tempo medio di transito è sceso da tre ore e trentanove minuti a un'ora e sei minuti. Il tasso di violazione dei P2 è sceso dal trentotto percento all'undici percento.

Il tempo di risoluzione interno di nessun team è cambiato in modo significativo. Nessuno ha lavorato più velocemente. Il tempo che non era appartenuto a nessuno è stato semplicemente assegnato a qualcuno.

Come redigere un accordo sul livello operativo, passo dopo passo

Inizia dallo SLA, non da un modello. Scrivi ciò che è stato promesso al cliente, end-to-end, con la definizione del relativo calcolo del tempo.

Mappa la catena. Ogni team che tocca una richiesta di quel tipo, in ordine, inclusa qualsiasi terza parte. Disegna i passaggi di consegne come fasi a sé stanti piuttosto che come semplici frecce.

Per ogni passaggio, poni al team ricevente una domanda: di cosa avete bisogno nel ticket per iniziare a lavorare senza doverci ricontattare? Quella risposta, messa per iscritto, costituisce i tuoi criteri di ingresso. I team rispondono a questo in modo rapido e preciso, e alla maggior parte di essi non è mai stato chiesto.

Ora concordate i tempi, lavorando all'interno dei calcoli aritmetici sopra descritti anziché team per team. Farlo in un'unica conversazione con tutti i presenti richiede un'ora ed evita del tutto il problema della somma.

Alloca il transito in modo esplicito e stabilisci chi ne è responsabile. Quindici minuti per passaggio di consegne sono un punto di partenza ragionevole e dovrebbero essere conteggiati a carico del team ricevente.

Concorda la misurazione, incluso il tasso di rimpallo, e da dove proviene. Se i tuoi strumenti non possono produrla, è bene saperlo prima di firmare piuttosto che alla prima revisione.

Quindi avvialo per un trimestre prima di formalizzarlo. Le prime versioni sono solitamente errate in uno o due punti ed è più facile correggerle prima che vi siano le firme.

Errori comuni relativi agli OLA e cosa costa ciascuno di essi

Misurare i team e non la catena. Tutti sono in regola (verdi) e lo SLA viene violato. Il fallimento più comune e l'argomento di questa pagina.

Nessun criterio di ingresso. Il rimpallo diventa la difesa razionale del team ricevente e il tempo trascorso si dilata in modo invisibile.

Tempi che non si sommano correttamente. Il set di OLA garantisce una violazione e nessuno ha mai fatto la somma.

Orari di servizio non corrispondenti. Un team copre fino alle sei, il successivo fino alle cinque. Tutto ciò che arriva dopo le cinque rimane fermo tutta la notte, cosa che nessun report mostra perché entrambi i team rispettano i propri orari.

Copiare il linguaggio dello SLA in un OLA. Penali, crediti e linguaggio legale non appartengono a questo documento, e importarli spinge i team a negoziare in modo difensivo anziché onesto.

Scrivere un OLA con una terza parte. Se c'è un passaggio di denaro, si tratta di un contratto di supporto e richiede il coinvolgimento dell'ufficio acquisti e dell'ufficio legale, non di un modello. Il nostro modello di policy per gli acquisti IT copre il percorso di approvazione.

Firmare e archiviare. Un OLA che nessuno revisione descrive una catena di servizi che cessa di esistere nel giro di circa un anno.

Come gestire e verificare gli OLA una volta creati

Analizza la catena, non i singoli componenti. Un solo numero conta, ovvero la performance end-to-end rispetto allo SLA, e le metriche OLA esistono per spiegarlo anziché per essere considerate singolarmente.

Effettua una revisione trimestrale, con tutte le parti presenti nella stessa stanza. Le revisioni bilaterali riproducono il problema originale, perché i divari vivono tra parti che non partecipano mai alla stessa conversazione.

Tieni d'occhio tre elementi. Il tasso di rimpallo per passaggio di consegne, che indica dove i criteri di ingresso richiedono lavoro. Il tempo di transito per passaggio, che indica dove si stanno formando le code. E la percentuale di incidenti che ha seguito un percorso non descritto dall'OLA, che indica che il documento si è allontanato dalla realtà.

Attiva una revisione straordinaria quando un team si riorganizza, quando un sistema passa da un team all'altro, quando una nuova terza parte entra nella catena o quando lo SLA cambia. Tutti e quattro gli eventi si verificano più spesso di quanto presupponga il ciclo di revisione annuale.

OLA, SLA o contratto di supporto: di quale hai bisogno?

Se l'impegno è rivolto a qualcuno esterno alla tua organizzazione di erogazione, che si tratti di un cliente esterno o di una business unit interna servita, si tratta di uno SLA.

Se avviene tra due team all'interno della stessa organizzazione senza passaggi di denaro, si tratta di un OLA.

Se è con un fornitore nell'ambito di un accordo commerciale, si tratta di un contratto di supporto (underpinning contract) e richiede l'intervento dell'ufficio legale e degli acquisti, anziché di questo modello.

Il caso più complesso è quello del centro di servizi condivisi o di un team interno con un modello di chargeback, che si colloca tra un OLA e uno SLA. La risposta pratica è scriverlo come un OLA ed eliminare qualsiasi linguaggio relativo alle penali, poiché i regimi di penali interne producono sistematicamente comportamenti difensivi e un servizio peggiore.

Per le definizioni rivolte al cliente e la formulazione delle risposte che stanno al di sopra di tutto questo, il nostro modello di risposta dell'help desk e il modello di ticket e risoluzione coprono il livello che l'utente finale effettivamente vede.

Posso ottenere un modello di OLA in Word o Excel?

Word per l'accordo, poiché le sezioni relative ad ambito, eccezioni e revisione sono in formato testuale e il documento viene diffuso per l'approvazione.

Excel specificamente per due parti. La tabella degli impegni, in cui si desidera che i criteri di ingresso, i tempi e l'allocazione del transito siano organizzati in colonne ordinabili e verificabili. E il foglio dei calcoli aritmetici, in cui ogni catena viene sommata rispetto allo SLA e segnala qualsiasi elemento privo di margine di tolleranza. Questo secondo foglio è quello che vale la pena costruire per primo, poiché spesso cambia ciò che si stava per concordare.

PDF per la versione firmata, esportata dalla sorgente. Mantieni modificabile la versione di lavoro, perché i criteri di ingresso dovranno essere modificati dopo il primo trimestre di rimpalli reali.

Come mantenere l'OLA in linea con la realtà

Un OLA descrive una catena di lavoro che cambia costantemente. I team si riorganizzano, i sistemi si spostano, gli strumenti cambiano e il documento è l'ultima cosa che qualcuno si preoccupa di aggiornare.

La parte che diventa obsoleta più rapidamente sono i criteri di ingresso, perché descrivono ciò che un ticket deve contenere, e ciò che un ticket deve contenere dipende da come funzionano effettivamente gli strumenti e i processi correnti.

Trupeer AI aiuta rendendo economico mantenere aggiornate le procedure sottostanti. Registra il processo di triage o di passaggio di consegne una sola volta e otterrai una procedura scritta con i passaggi e le schermate catturati, che il service desk può seguire e che mostra chiaramente quali informazioni vengono raccolte. Quando gli strumenti cambiano, registra nuovamente invece di riscrivere.

Registralo. Personalizzalo con il brand. Traducilo. Gestiscilo con Trupeer.

Lo strumento di creazione di SOP copre le procedure da cui dipende l'OLA, e il nostro modello di SOP IT illustra come decidere quali di esse valga la pena mantenere. La documentazione tiene uniti gli accordi e le procedure, e le istruzioni di configurazione si trovano nella guida alla configurazione del modello di documento.

Domande frequenti

Esiste un modello gratuito di accordo sul livello operativo in Word?

La struttura sopra riportata può essere incollata direttamente in Word o Google Docs, compresi i criteri di ingresso e i campi di allocazione del transito che i modelli standard omettono. Non ci sono download protetti o moduli da compilare. Mantieni la tabella degli impegni in un foglio di calcolo e inserisci un riferimento ad essa, perché quella parte richiede di essere ordinata e sommata.

Esiste un modello gratuito di accordo sul livello operativo in PDF?

Esporta la versione firmata in PDF una volta che le parti l'hanno concordata, e mantieni modificabile la copia di lavoro. I criteri di ingresso richiedono quasi sempre modifiche dopo il primo trimestre, una volta che è possibile vedere per quali motivi i ticket vengono effettivamente rimpallati.

Esiste un modello gratuito di accordo sul livello operativo in Excel?

Excel è lo strumento ideale per la tabella degli impegni e per la verifica aritmetica. Un foglio con una riga per ogni passaggio di consegne e un totale progressivo rispetto allo SLA, che evidenzi qualsiasi catena con meno del dieci percento di margine. Costruire quel foglio prima di negoziare tende a cambiare l'oggetto della negoziazione stessa.

Dove posso trovare un esempio di PDF di accordo sul livello operativo?

Diversi fornitori di ITSM ed enti governativi pubblicano modelli di OLA e SLA sotto forma di documenti, che sono validi per comprenderne la struttura. Leggeteli per analizzarne le sezioni piuttosto che il contenuto, poiché gli impegni in qualsiasi esempio pubblicato fanno parte della catena di qualcun altro e i tempi non hanno significato al di fuori dello SLA che sono stati progettati per supportare.

Chi firma un accordo sul livello operativo?

Il referente designato su ciascun lato, che dovrebbe essere il responsabile delegato per l'erogazione di quel team piuttosto che una funzione di service management. Un OLA firmato solo dal service management è solo un'aspirazione, perché la persona che deve allocare le risorse non era presente nella stanza.

Di quanti OLA ha bisogno un service desk?

Meno di quanti la maggior parte dei team si aspetti. Uno per coppia di team che si scambiano regolarmente il lavoro, coprendo tutti i tipi di richiesta in un'unica tabella degli impegni, piuttosto che uno per ogni singolo servizio. Oltre la dozzina, la manutenzione diventa un limite e i documenti diventano obsoleti più velocemente di quanto vengano revisionati.

Un accordo sul livello operativo dovrebbe prevedere delle penali?

No. Non esiste una relazione legale da far valere e i regimi di penali interne producono sistematicamente comportamenti difensivi: i team rifiutano il lavoro, discutono sull'avvio degli orologi e ottimizzano le performance per il proprio numero piuttosto che per il risultato finale. Monitorate invece la catena end-to-end, il che rende visibile la conseguenza condivisa senza che nessuno venga sanzionato.

Con quale frequenza dovrebbero essere verificati gli OLA?

Trimestralmente con tutte le parti presenti, oltre a una revisione straordinaria ogni volta che un team si riorganizza, un sistema passa da un team all'altro, una terza parte entra nella catena o lo SLA sottostante cambia. La cadenza trimestrale intercetta gli scostamenti e i trigger colgono i cambiamenti che renderebbero il documento errato dall'oggi al domani.