Service Level Agreements, si tratta di accordi definiti tra le parti, nel caso specifico IT (Information Technology), solitamente nell'erogazione di servizi.

Non solo tra fornitori esterni, ma anche per servizi interni. Ad esempio, tra direzione IT e gli altri dipartimenti. Quali sono i punti da tenere presente e perché possono essere importanti (anche in ottica di miglioramento dei servizi)

Cosa sono?

Gli SLA (Service Level Agreements) sono degli accordi contrattuali, che regolano le modalità di erogazione di un determinato servizio. Nel nostro caso parleremo di un servizio di sicurezza dei sistemi SAP.

Vedendo quali di questi servizi possono ricadere e quali punti importanti tenere presente durante la loro identificazione e definizione.

Possono esistere anche degli ulteriori metodi di controllo chiamati OLA Operation level agreements, solitamente interni, che sostanzialmente fanno in modo di supportare gli SLA. Ad esempio, definendo degli accordi, molto operativi di relazione tra i dipartimenti per far sì che gli SLA siano poi rispettati.

Perché sono importanti?

Perché ti permettono di capire come sta andando un determinato servizio. In maniera oggettiva. Pensa ad esempio in un servizio di outsourcing della gestione Security SAP. 

Approfondisci qui cosa significa AMS Security SAP. Oppure anche in questo video:

Puoi assegnare alle varie richieste in base ad una matrice di priorità quelli che potranno essere i livelli di servizio. Verificando, ad esempio, mese per mese se sono rispettati o meno.

I livelli di servizio non sono solo utili per applicare delle eventuali penali. Ma anche per capire se ci sono difficoltà anche interne nell'erogazione del servizio. Quelle che nello schema di certificazione ISO 20000 fanno riferimento ai "problem" ovvero quelle situazioni dove per molte volte vengono generate chiamate che possono essere tutte ricondotte alla stessa casistica. 

Quindi risolvendo a monte il problema, si può di fatto semplificare a valle la gestione del servizio. Attenzione, non è così semplice come sembra. Spesso la "messa a punto" di questo genere di servizi può richiedere del tempo. In quanto non è solo il fornitore che deve "metterci del suo" ma anche la società può dover modificare procedure o processi. E, come sappiamo, le abitudini, non sono così facili da modificare.

Perché può non essere semplice usarli?

Partendo da un passo indietro, ovvero la definizione degli SLA, questa può essere tutto sommato semplice. Anzi spesso ci si fa prendere la mano e si tende a definirne troppi. Quindi in generale, soprattutto nella partenza, meglio pochi e chiari.

Ma la difficoltà non è nella definizione. Ma nel controllo vero e proprio. In quanto servono degli strumenti e bisogna tenere in considerazione diversi aspetti. Che spesso sulla carta in fase di progettazione non sono così evidenti. 

Devi avere uno strumento, nella maggior parte dei casi uno strumento di ticket management, che permetta di misurare i livelli di servizio. Facciamo un esempio.

Se la creazione di un nuovo utente (ipotizzando che avvenga in modo manuale) pensi possa richiedere un giorno. Significa che tutte le procedure definite ed i team di lavorano che eventualmente concorrono alla definizione di una certa utenza, devono essere coordinati in modo tale che, dalla creazione dell'utenza, al suo utilizzo da parte del richiedente o beneficiario sia trascorso al più un giorno (ipotizzando di rientrare nello SLA definito).

L'esempio sopra è piuttosto comune. Tuttavia, il controllo di questo processo potrebbe non esserlo. Infatti, pur avendo uno strumento di gestione delle richieste, può capitare che:

• non tutte le tipologie di richieste siano tracciate in questo modo
• non ci siano dei ticket "a cascata" o correlati tra loro. Ad esempio se devono definire una utenza su SAP, ho bisogno che prima sia stata definita l'utenza in Active Directory ad esempio (quindi finché non è stata completata quella parte, il team SAP non può procedere)
• non venga considerata la mancanza di informazioni aggiuntive. Ad esempio, potrebbe capitare di dover chiedere ulteriori informazioni a team o persone. In questo caso il contatore dovrebbe "fermarsi" in attesa di ricevere le informazioni mancanti, "riattivandolo" a seguito

7 Suggerimenti su come impostare gli SLA?

Ecco qualche suggerimento se stai pensando ad introdurre realmente questi strumenti. Può infatti capitare che siano riportati nei contratti queste forme di controllo ma che poi nella realtà per motivi tecnici non siano applicate. 

1. Utilizza uno strumento di ticketing (non mail/chat o telefono). O meglio, questi ultimi strumenti mail chat telefono possono essere a supporto. Ma non possono essere usati per controllare bene questi aspetti
   
   
2. Prima di definire gli SLA fai in modo di conoscere tecnicamente il tuo sistema di ticketing. A volte sono progettati SLA che non possono essere presidiati poi nella realtà, se non facendo elaborazioni manuali, spesso molto dispendiose. 
   
   
3. Fai in modo che queste numeriche siano estratte dal sistema in maniera automatica. Qual è il senso, avendo uno strumento che dovrebbe fare questa parte autonomamente, di doverlo fare a mano ogni fine mese. Può essere che serva presentare i dati in alcuni modi, ma doverlo fare sempre oppure ogni volta a mano, forse, non è il modo migliore
   
   
4. Tieni presente che gli SLA servono a chi riceve il servizio. Se lo strumento di ticketing che viene usato fosse quello del fornitore (con tutta la buona fiducia che possa esserci) potrebbe non essere del tutto "affidabile" o comunque poco trasparente. Importante, se possibile, che chi chiede il servizio, qualsiasi esso sia, possa con mezzi propri controllare come viene erogato, in termini di SLA
   
   
5. Se hai un tuo strumento può essere utile mettere a disposizione del fornitore la possibilità di vedere costantemente gli SLA tramite una reportistica specifica
   
   
6. Valuta servizio per servizio che tipologie di SLA introdurre, non tutti i servizi, ovviamente, sono identici. Quindi è corretto avere un template da usare, ma spesso deve essere calato caso per caso
   
   
7. Meglio partire con pochi SLA soprattutto se all'avvio di un servizio rispetto ad usarne molti (a maggior ragione se ci sono difficoltà poi nel misurarli)