Tutti parlano di SLA e pochissimi di assumption

“Vendere” uno SLA è facile, rispettarlo senza intaccare la redditività del servizio è un’altra storia.

Negli accordi di servizio l’attenzione si concentra quasi sempre sui livelli di servizio: tempi di presa in carico, risoluzione, disponibilità, penali. Sono numeri immediati, facili da mettere in una tabella e da confrontare. Il problema è che uno SLA dice cosa deve accadere, ma non dice chiaramente da cosa dipende quel risultato.

È qui che entrano in gioco le assunzioni. Non sono note a margine: sono l’architettura stessa del servizio. Io le divido in due categorie ben distinte.

Le assunzioni contrattuali (il patto con il cliente)

Definiscono il contesto entro cui il canone è valido e la promessa sostenibile.

• Se si promette un tempo di risoluzione, bisogna chiarire cosa succede durante le attese del cliente, i tempi dei fornitori terzi, le approvazioni o le finestre di manutenzione.
• Se nei livelli di servizio non è specificato che un incident può considerarsi risolto anche con un workaround che ripristini il servizio dopo un degrado, il rischio è che il cliente intenda per ‘risoluzione’ la RCA completa. Risultato: SLA bucati e penali, anche se il servizio era già stato ripristinato.
• Se si garantisce un livello di disponibilità, bisogna chiarire quali componenti sono nel perimetro, come viene misurato il downtime, quali eventi sono imputabili al servizio e quali dipendono da infrastrutture, applicazioni o soggetti non governati direttamente dal provider.

Senza queste precisazioni, uno SLA può diventare un regalo fatto al cliente. E può diventare un regalo costoso. In fase commerciale possono rendere l’offerta più competitiva; in fase di delivery diventano una fonte continua di eccezioni, discussioni e perdita di margine.

Un’assunzione non scritta diventa facilmente un’aspettativa implicita del cliente o un costo assorbito dal fornitore. Una dipendenza non esplicitata può essere attribuita al provider anche quando è fuori dal suo controllo; una modalità di misura non definita apre a letture diverse degli stessi dati.

Scrivere buone assunzioni richiede più lavoro che compilare una tabella SLA, perché obbliga a progettare davvero il servizio: capire cosa è sotto controllo, cosa non lo è, quali dati sono necessari, quali attività sono incluse, quali condizioni giustificano un extra canone, quali eventi sospendono il conteggio dei tempi e quali responsabilità restano in capo al cliente. È qui che il solutioning deve collegare parte tecnica, parte economica e parte contrattuale.

Uno SLA corretto tutela il cliente sulla qualità attesa; assunzioni corrette tutelano entrambe le parti sulla fattibilità di quella promessa. Senza assunzioni, lo SLA rischia di diventare una dichiarazione di intenti o, peggio, una garanzia assoluta mascherata da metrica di servizio. Con assunzioni chiare, invece, il contratto diventa governabile: il cliente sa cosa deve abilitare, la delivery sa quali condizioni può pretendere e il fornitore può presidiare la redditività senza rinunciare alla qualità.

Nelle gare e nelle RFP le assunzioni servono anche a colmare le zone non specificate dal cliente. Quando un requisito è incompleto, ambiguo o lasciato aperto, dichiarare un’assunzione significa rendere esplicita l’interpretazione su cui si fondano soluzione, prezzo e responsabilità.

Fin qui le assunzioni servono a rendere governabile il patto con il cliente: chiariscono condizioni, responsabilità, dipendenze e limiti entro cui lo SLA può essere misurato e rispettato. Ma questo è solo un lato del problema.

Anche quando il perimetro contrattuale è ben delimitato, resta da dimostrare che il servizio sia economicamente sostenibile per chi lo eroga. È qui che le assunzioni cambiano funzione: non servono più solo a proteggere il contratto, ma a costruire e verificare il cost model.

Le assunzioni industriali alla base del cost model

Le assunzioni industriali sono le ipotesi operative ed economiche che trasformano il perimetro tecnico in effort, l’effort in costo e il costo in canone. Non descrivono ciò che il cliente deve accettare, ma ciò che il provider deve considerare per capire se la promessa fatta al cliente è sostenibile.

A differenza delle assunzioni contrattuali, non vengono necessariamente esplicitate nel documento commerciale, perché appartengono soprattutto al cost case interno e al modello industriale del provider. Alcune sono ricorrenti e standardizzabili, altre devono essere adattate alle caratteristiche della singola offerta, ma tutte hanno lo stesso obiettivo: rendere tracciabile il modo in cui una promessa di servizio si traduce in capacità operativa, costo industriale e margine atteso.

Quanto tempo richiede mediamente gestire un asset? Quante richieste genera? Quale livello di competenza è necessario? Quale quota di attività ricade sui diversi team e quali costi indiretti devono essere assorbiti dal servizio?

Queste assunzioni nascono da fonti diverse: dati storici di anni di supporto, statistiche sui ticket, esperienza dei responsabili di delivery, memoria operativa dei team, accordi contrattuali di lavoro, modelli di costo del personale, abitudini aziendali e livelli di automazione disponibili. Possono sembrare dettagli tecnici, ma in realtà incidono direttamente sul costo industriale e quindi sul margine.

Se la durata media di un incident è sottostimata, se il numero di richieste ricorrenti è considerato troppo basso, se non vengono valorizzati turni, reperibilità, assenze, formazione, coordinamento o escalation, il prezzo finale sarà solo apparentemente corretto. Il problema emergerà più avanti, quando il servizio inizierà ad assorbire più capacità di quella prevista e il margine verrà eroso dall’effort reale.

Un esempio pratico è il costo annuo di gestione di un server. Il valore non dovrebbe derivare da una tariffa forfettaria applicata meccanicamente, ma dalla combinazione di alcuni driver operativi ed economici che devono essere coerenti tra loro:

• costo delle risorse, includendo RAL, oneri, costi diretti, costi indiretti e seniority effettivamente necessaria;
• capacità effettivamente allocabile al servizio, calcolata al netto di ferie, assenze, formazione, coordinamento interno e attività non direttamente erogate sul contratto del cliente;
• volumi e durata delle attività, considerando incident, service request, attività ricorrenti, escalation e differenze tra lavorazioni standard e specialistiche;
• modello di copertura del servizio, includendo orari, turni, reperibilità, presidio, governance, strumenti e livelli di automazione disponibili;
• variabilità operativa, cioè la contingency necessaria ad assorbire picchi, turnover, complessità non lineare o scostamenti fisiologici rispetto alle ipotesi iniziali.

In questo modo il costo non è più una media astratta, ma il risultato leggibile di ipotesi operative verificabili. Ed è proprio questa leggibilità che permette di distinguere dove il modello può essere ottimizzato senza compromettere la delivery e dove, invece, uno sconto rischia semplicemente di scaricare rischio ed effort non finanziato sulla fase di esercizio.

Più i volumi aumentano, più il rischio cresce. Se devi quotare il deploy di 5.000 postazioni di lavoro e sbagli di 10 euro a postazione, hai già sbagliato il conto di 50.000 euro. Dieci euro sembrano pochi, moltiplicati per 5.000 non lo sono più.

Rendere esplicite, almeno internamente, queste assunzioni evita che il cost model diventi una scatola nera: un buon modello di costo non deve limitarsi a calcolare un prezzo, ma deve rendere comprensibile il rapporto tra perimetro, effort, costo industriale e margine. Ma attenzione: un’assunzione non è necessariamente una limitazione o una clausola con cui proteggersi: è una condizione su cui si basa il modello.

Uno SLA senza assunzioni non è un accordo di servizio. È una scommessa. E chi la perde, di solito, è il fornitore.