Foto di mjtmail rilasciata sotto licenza cc - https://www.flickr.com/photos/25947554@N07/3615960069

Slocovich (Cisq): “Perché dobbiamo utilizzare metriche di qualità nei contratti ict”

di Michele Slocovich, Director of Outreach Italy, CISQ – Cantiere Procurement pubblico

Partecipando agli incontri del Cantiere Procurement 2017 è risultato evidente come – da parte delle stazioni appaltanti e da parte del demand interno alle amministrazioni – sia necessario convergere immediatamente su un linguaggio comune e non ambiguo per la definizione delle caratteristiche, non solo dei prodotti e dei servizi, ma anche e soprattutto di quegli aspetti qualitativi ovvero anche conosciuti in campo ICT come non funzionali, che sono stati tante volte al centro di interessanti discussioni all’interno del cantiere.

Un altro aspetto emerso nell’avvicinare gli ambiti trattati durante i preziosi confronti con i colleghi delle amministrazioni è quello riguardante il costo della misurazione degli ambiti non funzionali, quand’anche infatti esistano dei riferimenti condivisi, questi dovranno avere un costo di verifica commisurato (ossia di ordini di grandezza inferiori) al danno potenziale derivante dalla carenza delle stesse caratteristiche.

Il contributo che voglio portare prende quindi spunto da questi aspetti e si indirizza all’ambito del procurement di servizi di ADM (application development and maintenance). In qualità di membro del CISQ, mi sento di potere condividere dei punti di riferimento indispensabili per ancorare le forniture a misure oggettive, ragionevoli e ripetibili.

I livelli di servizio sono parte integrante del processo di ADM sin dai primi contratti di outsourcing. Ciononostante i contratti più recenti non si allontanano dai tipici SLA temporali. Sono molto comuni SLA relativi al tempo di risposta in base alla severità, o ai tempi di completamento per richieste di manutenzione. Ma data la connessione tra costi di supporto e sviluppo e la qualità del codice ed i potenziali rischi operativi connessi è improrogabile la necessità di introdurre SLA che trattino la qualità del codice realizzato (o “preso in carico”).

Considerate che i costi di supporto sono normalmente il 20% del costo di realizzazione per anno. Aumentare la qualità dell’applicazione da “media” a “buona” può ridurre questa quota al 12%, addirittura scendendo al 3-5% del costo originale di sviluppo per codice qualificato come eccellente. I risparmi ottenibili nel termine di un 8%-17% annuo giustificano abbondantemente l’implementazione di processi per ottenere codice di qualità elevata sin dall’inizio del processo di sviluppo. La riduzione dei costi e dei rischi derivanti da codice di scarsa qualità può essere ottenuta attraverso l’inserimento nei contratti di ADM di SLA relativi alla qualità del software, così da incrementare il ROI degli investimenti applicativi.

Dobbiamo iniziare a considerare l’adozione del concetto di livello di servizio come una contrattualizzazione dell’incentivo per il fornitore, da performare secondo un determinato obiettivo e su una misura standard; basta pensare ai comuni e poco oggettivi SLA come strumento di leva sui fornitori, che li penalizzi per generare ricadute positive sulla spesa delle Amministrazioni. In una guerra al ribasso, i fornitori incrementano i prezzi sapendo di non potere onorare tutti gli SLA, senza più considerarli come incentivi al miglioramento, ma parte della scontistica.

>Leggi le linee guida del Cisq “Metriche di qualità del software per SLA efficaci nei contratti ADM”

L’approccio sul quale ci si sta muovendo è quello di strutturare gli SLA attraverso metriche di qualità eque, oggettive e derivabili da dati facilmente disponibili. Tali metriche devono essere basate su standards riconosciuti internazionalmente in modo che entrambe le parti, cliente e fornitore, abbiano intendimento condiviso e non ambiguo dei risultati da ottenere; per i contratti ADM, CISQ raccomanda gli standard OMG come misure automatiche del codice sorgente per Security, Reliability, Performance Efficiency e Maintainability; queste misure sono state sviluppate dai rappresentanti di 24 membri del CISQ tra cui vi sono organizzazioni IT globali, fornitori di servizi ADM, e produttori di software e sono nate da una lista di pratiche di scrittura del codice e disegno delle architetture rinomate per generare problemi. Possono essere normalizzate sulla dimensione delle applicazioni o delle evolutive, usando altri standards di OMG: gli Automated Function Point o gli Automated Enhancement Function Point, in modo da ottenere misure di SLA espresse come densità per Function Point, evitando il riscorso a misure deprecate quali le linee di codice e derivati vari.

È essenziale prevedere processi di misurazione automatica, quelli manuali sono suscettibili ad interpretazione, errore umano o manipolazioni intenzionali. La quantificazione automatica produce risultati deterministici, replicabili e congruenti: infatti la misurazione automatica, oltre a produrre lo stesso risultato ogni volta e non essere influenzata da fattori esterni, rimane coerente e comparabile tra diversi linguaggi e diverse piattaforme.

Considerate che la maggioranza dei contratti ADM prevede un massimale detto at risk, usualmente una percentuale del valore mensile del contratto, accompagnato da un peso per ciascuno SLA inteso come la porzione del valore del massimale at risk da considerare penale allo sforamento dello specifico SLA. Storicamente nella gestione degli SLA la somma dei pesi dava 100%. Questa limitazione significava che il fornitore doveva violare tutti gli SLA per dovere scontare l’intero ammontare at risk: un’eventualità abbastanza rara. In realtà I clienti si aspettavano che la violazione di plurimi SLA dovesse attivare l’intero ammontare at risk.

Più recentemente il fattore di pesatura per i contratti viene sovrappesato al 200%, per permettere ai clienti di dare peso maggiore alle metriche più rilevanti.  Attribuire per una somma superiore al 100% configura situazioni in cui un fornitore potrebbe dovere pagare penali pari all’intero ammontare “at risk” per avere sforato 2-3 SLA, su un totale di 10.

Un’altra recente innovazione contrattuale è quella di inserire una percentuale di bonus che può essere utilizzata per recuperare penali dovute a recenti sforature o per incentivare aree per cui il miglioramento è strategico per il cliente. Normalmente viene indicato per l’intero contratto, può essere differenziato per ciascuno SLA, viene calcolato al termine di un ciclo di budgetting e si limita in genere al 5% del valore del contratto.

Questo è un esempio di tabella di SLA contrattuali che utilizza le metriche di qualità del CISQ su un contratto del valore di €2M, con un at risk 10/250%:

tabella di SLA contrattuali con metriche di qualità del CISQ (clicca sull’immagine per ingrandire)

Concludo affermando che l’inserimento in un contratto ADM di questi SLA e della clausola sulle violazioni inaccettabili, farà diminuire il costo totale della conduzione di un determinato asset software (TCO), liberando risorse economiche per iniziative di innovazione. Il ritorno di investimento, come sancito da recenti studi, indica che i costi di misurazione e dei relativi strumenti, vengono recuperati prima che l’applicazione arrivi alla fase di accettazione dell’utente (UAT): questo è evidente anche dal fatto che il 52% di tutti i difetti vengono individuati, non durante il testing, ma dagli utenti direttamente in produzione: una situazione non più tollerabile.
Se vogliamo rendere l’ADM un processo a continuo miglioramento, i risultati devono essere misurabili ed allineati ai processi di business. Cambiamento rapido, alta resilienza e costi in diminuzione sono obiettivi non alternativi tra loro: bisogna che i processi di ADM siano responsabilizzati ai risultati di business. La misurazione è indispensabile per dare indicazioni sui risultati operativi e supportare le scelte direzionali.

 

Foto di mjtmail rilasciata sotto licenza cc – https://www.flickr.com/photos/25947554@N07/3615960069