Trasformazione digitale, quei due “debiti” killer del valore

Il concetto di “debito tecnico” è stato introdotto da Ward Cunningham per indicare il costo (debito) dell’accumularsi di complessità non necessaria nel software. Ma esiste anche un “CX Debt” – debito della customer experience – da considerare. Analizziamone la portata e i passaggi per raggiungere soluzioni ad alto valore nei processi di digital transformation.

Software: complessità non necessarie

Ogni sistema software (e non solo) ha una complessità minima che non può essere eliminata (e che viene raggiunta solo nel caso di programmazione ottimale) e una complessità non necessaria che ne aumenta l’entropia senza portare benefici. Il concetto può essere generalizzato dal software ai progetti digitali.

Fowler ha rappresentato il debito tecnico in questi termini:

(Cruft può essere tradotto con “fuffa, ciarpame” o codice ridondante)

Il concetto di “debito” non è di per sé negativo. Il mutuo che accendo per comprare casa è un debito che mi permette di entrare nella nuova casa ora e non tra 20 anni. Ovviamente il debito va tenuto sotto controllo, perché se non sono più in grado di far fronte alla restituzione (con gli interessi) del capitale, questo diventa un problema. Però il debito è tipicamente utile per anticipare i benefici, quindi potenzialmente un concetto positivo.

Lo stesso accade negli sviluppi software e più in generale nei progetti digitali. Non è pensabile sviluppare un sistema tecnologico perfetto (ossia a debito zero). L’approccio “a debito zero” ha due controindicazioni: la prima è che sposta troppo nel futuro il momento in cui cominceremo a sperimentare i benefici di quanto realizzato, la seconda è che allo stesso modo sposta nel futuro il momento in cui riceveremo i primi feedback dagli utenti, aumentando esponenzialmente i rischi.

Per questo il concetto stesso (molto in voga e molto abusato) di MVP, o Minimum Viable Product, è di fatto il riconoscimento della necessità di realizzare e mettere in produzione il prodotto il prima possibile, quindi con un elevato debito, che verrà poi raffinato successivamente.

Questo va bene, a patto che il debito venga tenuto sotto controllo e che, come ricorda un simpatico meme che gira in rete, ci si ricordi che il debito prima o poi va ripagato.

Il debito di Customer Experience (CX Debt)

Il caso dell’MPV (Minimum Viable Product) è interessante perché chiarisce il concetto di CX Debt[1]. Evidentemente il prodotto nelle prime iterazioni ha, oltre ad un debito tecnico, anche un debito di tipo diverso. Il debito è funzionale (mancata ottimizzazione delle funzionalità rispetto a quelle che saranno presenti nella versione finale), ma anche di usabilità (l’interfaccia utente è probabilmente ancora grezza e “poco pulita”) e di processo (i processi sottesi forse non sono ancora stati rivisti completamente).

Tutte queste cose messe insieme generano un’esperienza utente non ottimale: per questo ho chiamato questo debito “CX Debt”, ossia debito della customer experience. Per comprendere bene il CX Debt dobbiamo però sottolineare che, come per il debito tecnico, anche il CX Debt si genera per eccesso e non per difetto. Infatti il problema non è tanto nelle funzionalità mancanti (queste non generano debito perché non sono ancora state sviluppate), quanto nel fatto che ci sono troppe funzionalità non essenziali, troppi passi di processo, troppi elementi ridondanti nell’interfaccia grafica.

Insomma, se abito in una capanna e vorrei essere in una bella villa, questo è certamente un gap nella mia customer experience, ma non è un debito. Se invece prendo dei soldi in prestito e costruisco la villa, questo diventa un debito in senso finanziario. Se invece mi arrangio da me e con i pochi soldi che ho costruisco una villa con il tetto bucato e le fondamenta traballanti, questo è un altro tipo di debito (non finanziario), ma che certamente impatta sia gli aspetti tecnici (debito tecnico) che la mia customer experience (debito di customer experience).

Sempre rifacendoci a Fowler, il Tech Debt può essere classificato in 4 macro categorie. Lo stesso può essere fatto per il debito di customer experience:

Per riassumere, possiamo parafrasare il contenuto dell’immagine di Fowler sul debito tecnico:

Il concetto di debito è potente. Per questo ci sono state diverse estensioni: qualcuno ad esempio ha introdotto un terzo tipo di debito che ha impatti importanti nella trasformazione digitale, il “Debito Organizzativo”. Il tema organizzativo però è troppo vasto per essere affrontato qui e merita un approfondimento specifico.

I paradossi del valore

Il valore è un concetto spesso paradossale. L’auto nella foto è sicuramente costata molto. Che dire rispetto al valore generato dall’investimento? Certamente guardandola nasce qualche perplessità. In realtà non possiamo dire se realizzarla sia stato un investimento di valore o meno senza definire quali sono gli obiettivi (detti anche risultati o outcome) che ci si prefiggeva e soprattutto senza definire il valore.

Partiamo dalla definizione del valore che Porter applica al contesto sanitario, ma che può essere generalizzata:

Questa definizione ci porta a ragionare su alcuni paradossi che vediamo spesso nell’ambito della trasformazione/evoluzione digitale (e non solo):

• I grandi investimenti e i progetti faraonici hanno più probabilità di distruggere valore che di generarlo. Infatti, certamente aumentano in modo importante il denominatore (costi), mentre gli outcome attesi spesso non sono ben definiti e comunque proiettati in un futuro incerto e non vicinissimo (dato che i tempi di esecuzione sono necessariamente non brevi).
• Utilizzare strumenti costosi (ad esempio grandi piattaforme, costruzione di infrastrutture non necessarie) per ottenere gli stessi outcome che si potrebbero raggiungere con soluzioni meno costose distrugge valore. Infatti, il maggior valore, a parità di outcome, è dato dalla soluzione meno costosa.
• Definire e raggiungere gli outcome, tenendo sotto controllo i costi, non necessariamente porta valore reale. Il sottotitolo “Outcomes that matter” è potente ma anche ambiguo. Per chi importano? Nel caso della sanità, Porter identifica il paziente come il punto di vista da cui inquadrare gli outcome. Negli altri ambiti… dipende, ma in generale è quello del “cliente finale”. Il caso della super automobile nella foto a inizio paragrafo è emblematico. Qual era il risultato atteso e per chi era importante? Solo rispondendo a questa domanda potremo dire se l’investimento ha generato valore oppure no. Gli esempi potrebbero essere infiniti, ognuno ci può aggiungere i suoi.

Guardando l’equazione del valore dal punto di vista del Tech Debt e del CX Debt, possiamo fare due considerazioni:

• il Tech Debt ha un impatto negativo diretto sui costi e uno indiretto sugli outcome. L’impatto sui costi è facilmente comprensibile, dato che ad esempio un codice con un elevato debito tecnico ha maggiori costi di manutenzione e di evoluzione. L’impatto sugli outcome è indiretto, perché la minore “evolvibilità” rende più difficile seguire le esigenze dei clienti e problemi tecnologici possono impattare negativamente sull’esperienza utente.
• Il CX Debt ha un impatto negativo diretto sugli outcome. Infatti un’applicazione con un debito di customer experience elevato raggiungerà con più difficoltà gli outcome desiderati. In modo indiretto però anche i costi aumentano, perché un’applicazione con un CX Debt elevato è complessa e ridondante in modo non necessario, quindi più costosa da manutenere.

I sistemi digitali possono essere classificati a seconda del peso del debito (Tech o CX) in 4 quadranti:

ALTO <- Debito di Customer Exp. (CX Debt) -> BASSO

ALTO <- Debito Tecnico (Tech Debt) -> BASSO

Le soluzioni con CX e Tech Debt bassi sono quelle che generano il maggior valore (HIGH VALUE SOLUTIONS). Per quello che si è detto, questo non significa che siano soluzioni complete o che indirizzino tutti i requisiti. Una soluzione molto semplice e con poche funzionalità può essere tecnologicamente top e dare una customer experience eccellente, quindi generare valore. Le soluzioni con entrambi i debiti alti sono quelle che tipicamente distruggono valore (EVERYBODY LOSE SOLUTIONS). Negli altri due quadranti ci sono le soluzioni che privilegiano l’esperienza utente (Customer First Solutions) o che privilegiano la solidità tecnologica (Technology First solutions). In entrambi i casi c’è un debito importante che va colmato.

A questo punto parrebbe scontato che, come nelle migliori tradizioni, il quadrante “buono” sia quello in alto a destra. In realtà non è così semplice. Infatti se è chiaro che tutti dovrebbero stare lontani dalle soluzioni “EVERYBODY LOSE” e puntare alle “HIGH VALUE SOLUTIONS”, ognuno potrebbe avere un percorso diverso.

Nella vita bisogno spesso scendere a compromessi con la realtà ed è improbabile che si parta subito dal paradiso di una soluzione con Tech e CX Debt entrambi bassi. Se sia meglio passare da un approccio “CUSTOMER FIRST” o da un approccio “TECHNOLOGY FIRST” prima di arrivare all’agognata “HIGH VALUE SOLUTION” dipende dal contesto. In alcuni casi il cliente finale è più tollerante ed è fondamentale avere una tecnologia robusta e con poco debito (si pensi a molte applicazioni mission critical). Questa è una situazione in cui una customer experience non ottimale è tollerabile, mentre un fault tecnologico sarebbe disastroso.

Viceversa vi sono situazioni in cui l’esperienza dell’utente è l’obiettivo principale, anche dovendo mascherare la complessità e fragilità tecnologica sottostante. Si consideri inoltre che in molti casi non si arriverà mai ad una soluzione con Tech e CX debt bassi: bisognerò allora valutare, rispetto al contesto e agli “outcomes that matter”, quali trade off fare.

Einstein, il cavolo e G.and.A.L.F.

Allora come compiere il percorso verso le “HIGH VALUE SOLUTIONS”, considerando i paradossi del valore di cui abbiamo parlato? Se non basta (anzi è rischioso) mettere in campo grandi investimenti, se gli outcome (e quindi il valore) sono un concetto così elusivo, se non è sufficiente utilizzare piattaforme e strumenti digitali costosi, come si potrà camminare verso le soluzioni ad alto valore?

Il tema è complesso ma anche semplice. In sintesi: è una questione di metodo. Le componenti sono già tutte note e sperimentate dai top performers. Lean, gestione continuativa dei feedback, coinvolgimento di tutti gli stakeholder, semplificazione dei processi, agile governance. Sono temi che non svilupperò qui perché ne ho già parlato in un altro articolo a cui vi rimando per approfondimenti.

Concludo con una foto di Einstein e di un cavolo romanesco, due grandi maestri di vita. Ascoltandoli e guardandoli ho imparato molto!

Bisognerebbe rendere tutto il più semplice possibile, ma non troppo semplice (frase attribuita a Albert Einstein)

1. Per il concetto di “CX Debt” sono “debitore” al collega Stefano Vincini, che dopo un assessment per misurare il debito tecnico degli applicativi osservò che oltre al debito tecnico vi era un “debito funzionale” importante e non catturato dall’assessment