Questo articolo fa parte di una serie di mie riflessioni sull’innovazione technology-driven, cominciata qui.
Gli ultimi post sono stati dedicati al tema del technology scouting, all’interno del quale ho affrontato le tecnologie del cloud computing, dei big data e dell’enterprise mobility.
Il technology scouting è una delle attività – quella più proattiva – che consentono alla funzione IT di un’azienda di leggere il piano strategico aziendale e tradurlo in un piano di progetti IT, all’interno di un framework metodologico che ho descritto qui e che vi ripropongo in forma grafica semplificata.
Nei post successivi ho descritto alcuni strumenti utili per avere la conoscenza esatta della situazione di partenza, in termini di infrastruttura, sistemi e processi già operativi e progetti in corso, con l’obiettivo di verificare se tutti i progetti in corso sono ancora coerenti con le strategie di business e se esistono degli interventi di natura infrastrutturale, propedeutici allo sviluppo di progetti strategici, che vanno messi in cantiere.
Con in mano gli orientamenti strategici ed una percezione chiara della situazione attuale e delle opportunità si può procedere con la definizione degli scenari prospettici e dei progetti da inserire nel piano di innovazione, che possono interessare 4 aree
- L’Infrastruttura tecnologica, a fronte di obsolescenza tecnica o di maggiore agilità operativa necessaria.
- Le Applicazioni, per obsolescenza tecnologica.
- Le Applicazioni e i Processi di Business, per obsolescenza funzionale o nuove opportunità.
- L’Infrastruttura, le Applicazioni e i Processi per adeguamento normativo.
L’aspetto più complesso, nella costruzione del piano di innovazione complessivo, non è – tuttavia – quello di identificare i potenziali progetti. E’ quello di conciliare tutte le richieste di innovazione con i vincoli di risorse organizzative ed economico / finanziarie messe a disposizione dall’azienda, in altri termini verificare la sostenibilità di tutti gli interventi richiesti.
Non è solo un tema di natura economica, poiché:
- La gestione progettuale richiede, innanzitutto, una struttura di governo e gestione del progetto, che tipicamente non viene esternalizzata
- Una buona prassi dell’IT management consiglia di assegnare a risorse interne anche lo sviluppo dei contenuti chiave del progetto (eventualmente in affiancamento a risorse esterne) per garantire un adeguato know how di gestione quando il progetto è terminato
- Un’altra regola di gestione dei sistemi complessi suggerisce di non intervenire con cambiamenti su diverse componenti critiche in contemporanea, per non minacciare la stabilità complessiva
- Quando anche si riuscisse a massimizzare il parallelo delle attività di sviluppo, ci sono una serie di inevitabili colli di bottiglia sulle strutture di test e collaudo
- Infine, il terminale dei progetti di innovazione sono spesso gli utenti di business, ad esempio per noi gli operatori di sportello, sui quali va considerata adeguatamente la mole di formazione e cambiamenti che sono in grado di recepire nel tempo.
Nei prossimi post percorreremo un processo di stesura del piano di innovazione che indirizza questi aspetti in 5 passi.
luigiatauro.com 