Gli errori che commettono i CIO nell’ottimizzazione

Buona parte del lavoro del CIO consiste nel progettare cose, supervisionare altre persone che progettano cose e assicurarsi che ci sia coerenza tra le cose che vengano progettate.

Ci sono alcuni criteri universali che governano un buon design, indipendentemente da ciò che viene progettato. Il più famoso è probabilmente il detto del grande architetto Louis Sullivan, secondo cui “la forma segue la funzione”. Meno noto, ma altrettanto importante (almeno per il nostro contesto) è quello introdotto da W. Edwards Deming: “per ottimizzare il tutto dobbiamo subottimizzare le parti”.

Questa regola è importante indipendentemente da ciò che viene progettato, che si tratti di un gadget, di un software, di un’organizzazione o di un processo. Ed è la chiave per capire perché così tanti CIO sbagliano l’ottimizzazione.

Da coda a coda: il collo di bottiglia nascosto nel processo

Se i CIO potessero svolgere il loro lavoro con un solo asso nella manica, probabilmente sarebbe l’ottimizzazione dei processi. È fondamentale che l’IT svolga bene il proprio ruolo, che comprende aiutare i manager aziendali a ottimizzare i propri processi.

Per ottimizzare processi interni ed esterni all’IT è disponibile una vasta gamma di framework e metodologie. Tra le più diffuse c’è la Lean, quindi usiamola per illustrare il punto.

Forse il contributo più importante, ma meno riconosciuto, che l’approccio Lean ha dato al mondo dell’ottimizzazione dei processi è che i processi non sono raccolte di attività che scorrono da una casella all’altra. Sono invece attività che scorrono da una coda all’altra. La differenza può sembrare sottile, ma è uno dei motivi per cui l’ottimizzazione di un “tutto” offre risultati diversi rispetto all’ottimizzazione delle “parti” di un tutto. Può sembrare una questione da manuale accademico, ma comprendere questa differenza è la chiave per padroneggiare l’ottimizzazione dei processi.

Immaginate di gestire un progetto che necessita di un nuovo server per procedere, supponendo che non sia stato fatto un passaggio completo al cloud e che l’azienda possieda ancora server e data center. Seguendo la procedura, viene inviata una richiesta che va in coda alle richieste IT.

Semplificando un po’, la figura seguente rappresenta questa situazione, che definiamo “box-to-box”:

È un flusso diretto. I team responsabili di ogni fase hanno ottimizzato molto tempo fa le procedure per affrontare le proprie responsabilità. Lo sforzo totale e il tempo del ciclo di processo sono gli stessi: per questo ipotetico esempio, calcolate circa otto ore o un giorno nella pianificazione del progetto.

Ma la visione box-to-box del processo è sbagliata. Il processo effettivo è più simile alla figura seguente:

Ogni fase del processo viene gestita come una coda FIFO (first in, first out). I team lavorano sulle richieste solo quando la richiesta è passata attraverso la coda ed è uscita per l’elaborazione. Lo sforzo totale è lo stesso stimato nella visualizzazione box-to-box. Ma il tempo di ciclo include sia il tempo di lavoro che il tempo in coda: per questo processo, calcoliamo cinque giorni, più o meno.

L’analisi vera e propria è più complicata di questa. Di solito, un passo finisce per essere un collo di bottiglia; il lavoro si accumula nella sua coda mentre le altre code si esauriscono, controbilanciato da tutte le code che ricevono richieste da più di una fonte. Questo non cambia il principio, ma solo la complessità della simulazione.

Questa è realtà, non solo teoria. Non molti anni fa un cliente, le cui dimensioni della coda erano un po’ più lunghe di quelle illustrate sopra, ha subito ritardi di diversi mesi nel progetto mentre i team aspettavano l’installazione dei server approvati da cui dipendevano, anche se un server tipico non richiedeva altro sforzo per acquisire, configurare e installare rispetto a quanto illustrato sopra.

La causa principale? I manager responsabili di approvvigionamento, amministrazione della rete, installazione del software, garanzia della qualità e implementazione avevano tutti organizzato il lavoro dei loro dipartimenti per massimizzare l’utilizzo e la produttività del personale.

Loro, le parti, si erano ottimizzati a scapito dell’intero progetto.

Eliminare le attività esterne

La soluzione, che i fan del DevOps riconosceranno e adotteranno immediatamente, era includere analisti dell’infrastruttura IT nel team di progetto principale e, cosa ancora più importante, includere nel piano di lavoro di ciascun progetto attività dell’infrastruttura come la configurazione dei server, l’assegnazione di date di inizio e scadenza basate su quando sarebbero stati necessari i loro prodotti di lavoro.

Con questa modifica, le build del server sono diventate parte della pianificazione del progetto, anziché essere attività esterne sulle quali il project manager non aveva alcun controllo.

In cambio, il CIO ha dovuto accettare che, se i progetti avessero dato i risultati nei tempi stabiliti e nei limiti del budget, il resto dell’organizzazione IT avrebbe dovuto rallentare nella gestione del lavoro. Gli obiettivi di utilizzo del personale non dovrebbero nemmeno avvicinarsi al 100% (per chi volesse una comprensione più approfondita di questo punto, suggerisco di dedicare un po’ di tempo alla ricerca della metodologia di gestione del progetto Critical Chain di Eliyahu Goldratt).

Il tracollo del Management by Objectives (MBO)

La portata dell’ottimizzazione/subottimizzazione va ben oltre la progettazione del processo. Consideriamo, per esempio, la retribuzione del management.

In passato, il Management by Objectives (MBO) era una teoria popolare su come ottenere il massimo dall’organizzazione ottenendo il massimo da ogni manager dell’organizzazione. Il suo difetto fatale era il mancato riconoscimento delle inevitabili, ma non intenzionali, conseguenze dell’ottimizzazione delle parti a scapito dell’insieme.

Il modo in cui funzionava (o, meglio, non funzionava) era che, come suggerisce il nome, i dirigenti dell’azienda assegnavano a ciascun manager uno o più obiettivi. I manager, data la maggiore chiarezza su ciò che avrebbero dovuto realizzare, si dedicavano esclusivamente a quegli obiettivi, senza preoccuparsi di ciò di cui qualsiasi altro manager aveva bisogno per raggiungere i propri obiettivi.

Le aziende che oggi soffrono di ciò che viene considerato “pensiero in silos” e dell’incapacità di collaborare pagano il prezzo dell’era MBO.

Aiutare in modo inefficace l’help desk

In nessuna azienda ci sono organigrammi perfetti. Il principio di ottimizzazione/subottimizzazione di Deming contribuisce in modo determinante alle imperfezioni dell’organigramma.

Consideriamo il classico help desk e la sua posizione all’interno del design organizzativo dell’IT. Tra i suoi obiettivi ci sono ridurre al minimo il tempo tra il primo contatto con l’utente finale e la risposta iniziale dell’help desk, il tempo necessario a risolvere il problema dell’utente finale e il costo per incidente.

Supponiamo che la gestione di ogni incidente segnalato includa il tempo impiegato per registrarlo e il tempo dedicato a risolverlo, o il tempo impiegato per eliminarlo assegnandolo a un altro team IT.

Il modo più semplice per l’help desk di raggiungere il livello di servizio di risposta iniziale è fare il meno possibile durante la risposta iniziale, eliminando ogni incidente il più velocemente possibile. Ciò permette agli analisti dell’help desk di rispondere velocemente alla chiamata successiva, evitando di impantanarsi nel tentativo di risolvere problemi che non sono attrezzati a gestire. Meglio ancora, indirizzando i problemi ai reparti con maggiore esperienza, gli incidenti verranno risolti più velocemente che se gli analisti dell’help desk tentassero di risolverli da soli.

Purtroppo, questo approccio garantisce anche che gli analisti dell’help desk non imparino mai come gestire problemi simili. E tenere bassi i costi dell’help desk va a scapito di distrarre i talenti più costosi dalle loro attuali priorità, che, dal punto di vista del valore complessivo, sono probabilmente più importanti.

L’ottimizzazione dell’help desk si traduce in un esercizio di trasferimento illimitato di costi e responsabilità. Il costo totale della gestione degli incidenti aumenta in proporzione alla diminuzione dei costi veri e propri dell’help desk.

Per ottimizzare il tutto, bisogna ottimizzare le parti. Questa indicazione potrebbe sembrare più filosofica che concreta e pragmatica, ma non lasciatevi scoraggiare dalle sue sfumature. Se desiderate i migliori risultati, assicuratevi che tutti coloro che sono coinvolti nel raggiungimento di tali risultati sappiano cosa ci si aspetta da loro..

E che nessuno sarà penalizzato se collaborerà per realizzarli.