Data Strategy Portfolio Management

Il modello troppo rigido Plan-Do porta inevitabilmente ad allungare la fase di analisi, ma nel frattempo i requisiti tecnici o funzionali del business case da risolvere spesso cambiano. Per garantire la velocità di consegna richiesta, a progetto in corso i team di sviluppo sono costretti a implementare soluzioni rapide e poco ingegnerizzate, tagliando i tempi della fase di progettazione. Spesso vengono replicate soluzioni di integrazione o strutture dati già esistenti, per mancanza di strumenti e processi di condivisione della conoscenza sugli asset dati disponibili o per impossibilità di attendere la messa a fattor comune di una funzionalità condivisa o un asset dati riutilizzabile. Questo crea ridondanza e potenziali inconsistenze nelle versioni multiple di uno stesso data asset, con evidenti problemi di maintenance e di governance.

In mancanza di una visione strategica, di continua evoluzione e sperimentazione sia in ambito tecnologico sia nella ricerca e selezione di dati utili per determinati business case alcune funzioni aziendali sono portate a prendere iniziative di proprio conto, che finiscono con realizzare soluzioni tampone non conosciute dal resto dell’azienda, non allineate agli standard condivisi, che generano costi operativi addizionali e abituano parte dello staff a lavorare con tecnologie e processi che poi risulta difficile ricongiungere in futuro.

In mancanza di una fase di adattamento iterativo di una soluzione per raffinamenti successivi, si corrono i forti rischi di sbagliare il dimensionamento dell’infrastruttura o la scelta dei prodotti tecnologici su cui basare la piattaforma, anticipando troppo la scelta definitiva. Spesso si è costretti a definire un dimensionamento upfront dell’intera infrastruttura, basato su un ipotetico stato a regime di cui si hanno pochi elementi di valutazione in fase di sizing. Il risultato che è, a posteriori, molte volte la stima ipotizzata inizialmente su volumi dati, traffico di rete e carico computazionale risulta errata: con buona probabilità questa stima, sui cui si è basato il provisioning dell’infrastruttura o l’acquisto di una licenza (o un agreement con un cloud provider), ha portato ad uno spreco di fondi in risorse sottoutilizzate o, viceversa, alla perdita di opportunità di scontistiche applicate a determinate scale di utilizzo. Allo stesso modo, la selezione dei tool più adatti, se non confermata da evidenze implementative su workload prototipali, rischia di non essere quella più ottimale per l’experience attesa.

Un approccio che imposta le attività per progetti dati isolati e non governati da un filo conduttore continuo non favorisce il consolidamento continuo delle conoscenze funzionali dello staff interno dell’IT e dei consulenti esterni sulle logiche di business, in quanto questi ultimi sono coinvolti in attività di analisi e di rafforzamento delle conoscenze solo quando si presenta la necessità di risolvere un problema di business specifico (situazione che, in certi casi, può verificarsi in modo sporadico), invece che essere continuamente ingaggiati in un percorso di evoluzione progressiva dei servizi offerti al business.

La delivery di progettualità in ambito dati che non risultano veramente efficaci a migliorare l’esperienza utente e di cui non è percepito il valore dalle altre funzioni di business contribuiscono a creare incomprensioni interne e perdita di fiducia nel valore dei dati. 

Le aziende operano in un contesto di mercato molto più incerto e imprevedibile rispetto al passato: in questo scenario di mutamenti rapidi, il fattore tempo diventa fondamentale nel prendere o rivedere scelte strategiche. La probabilità di predeterminare gli imprevisti è notevolmente bassa: concentrarsi troppo sulla fase di analisi rischia di rallentare i tempi e portare ad una situazione di stallo. Nell’organizzazione delle attività, è più importante avere un metodo che permette di adattare la pianificazione in corsa piuttosto che concentrarsi su una fase eccessivamente lunga di definizione di un piano complessivo up-front.

Un deliverable non può più essere considerato come un artefatto statico che viene prodotto una tantum con un determinato costo ed entro una scadenza ed eventualmente modificato in seguito se si presenta una richiesta. Al contrario, un deliverable è un oggetto dinamico, che può nascere in una versione minimale (Minimum Viable Product) ed evolvere continuamente come frutto di una roadmap finalizzata ad aumentarne il valore nel tempo per l’azienda.

Per sostenere la crescita, l’evoluzione dei deliverable e stare al passo con la direzione di cambiamento del business, è necessario rivedere anche le modalità tradizionali di budgeting e funding. Valutare il costo delle singole soluzioni senza guardare in prospettiva pone un limite alla capacità di garantire un miglioramento continuo del servizio. È necessario allineare l’impiego del budget agli obiettivi strategici e ai programmi che li realizzano, ripartendo il budget complessivo disponibile in modo proporzionale al grado di importanza degli obiettivi strategici a cui sono associati e al valore percepito dagli stakeholder. Questo approccio aiuta a garantire che tutti i programmi in portfolio vengono adeguatamente implementati, seppur a velocità e con priorità differenti tra loro.