ZeroUno: Nel percorso verso la nuova relazione dell’Ict con il Business che definiamo Business Technology, qual è il fattore cruciale nel Change management delle persone Ict in generale?
Peters: Il tempo. Non attendiamoci risultati immediati. Non si può accelerare oltre un certo livello la velocità con cui le persone migrano. Il problema non è solo l’alta complessità, ma la nuova competenza in aree che sono del tutto nuove per molte persone del dipartimento It. Faciliterà il cambiamento il ricambio generazionale che porterà nuovo know-how. Lo potranno favorire una forte governance e sponsorizzazione del senior management e l’omogeneità culturale, anche in caso di M&a.
Tancini: In Zurich la difficoltà più rilevante è stata quella culturale. Partivamo infatti da culture country-centriche ed è stato difficile da accettare il passaggio dallo sviluppo, e utilizzo, di servizi interni (sviluppati nella singola country e ad essa destinati) alla fruizione di servizi che arrivano dall’esterno (dal centro o da un’altra country che ha sviluppato uno specifico set di servizi). All’inizio questo cambiamento è stato percepito come perdita di potere. Si è creato un processo di trasformazione a “stop and go”: vado verso il centro, mi fermo per le resistenze, riparto. È importante un “readiness assessment” per Paese, per comprendere bene quando un Paese è pronto all’implementazione del servizio, e, di conseguenza, dare la priorità a roll-out nei paesi considerati “pronti”.
Stefani: Chiesi Farmaceutici è una piccola multinazionale italiana, poco meno di 1 miliardo di euro di fatturato, metà fuori dall’Italia, una ventina di filiali in giro per il mondo, frutto di piccole acquisizioni, ogni Country Manager con il massimo di autonomia e potere. Ora alcuni processi, dalla R&d alla distribuzione, stanno diventando globali; è iniziato il percorso verso un’organizzazione più strutturata. Non ci sono ancora le condizioni per consolidare i centri, ma abbiamo standardizzato tutte le componenti dell’infrastruttura (domini, posta, sicurezza), stiamo lavorando su applicazioni e processi globali. Anziché un gruppo che struttura la domanda, uno che sviluppa magari in outsourcing e uno che gestisce le operazioni, mi ritrovo con poche persone costrette a tutte e tre le attività: nella R&d non esiste l’Erp, ma tante applicazioni specialistiche per fase (dalla discovery con Db di molecole, alla fase preclinica con analisi in vitro, alle fasi cliniche); ne deriva un’estrema specializzazione delle persone in grado di gestire il Demand Mangement, che inesorabilmente devono poi fare il Project e l’Application Management, gestione e manutenzione compresa. Insomma le dimensioni medio piccole costringono ad affrontare la complessità con numeri insufficienti per una struttura efficace del Demand-Supply.
Peters: Lo stesso problema di applicazioni specializzate c’è nell’automotive, che ha tecnologia tipo Cad molto dispersa e costosa. Il modo migliore è comunicare chiaramente al business dove sono annidati i costi: queste tecnologie costose nel tempo si commoditizzano e se si costruisce un portafoglio che risponde al Demand Mangement come un mix di servizi dedicati e di servizi condivisi, anche in queste condizioni “disperse” si possono forzare sinergie (ad esempio requirement storage gestiti con un San o muovendo verso Servizi esternalizzati, con Storage as a service). Con servizi condivisi si può contenere e ridurre l’universo di servizi simili forniti dall’insieme di applicazioni di un portafoglio applicativo molto variegato.
Bonfanti: Una considerazione (dalla mia passata esperienza lavorativa) sul consolidamento e il Demand Mangement in un contesto di multinazionale, in modo pervasivo sul gruppo. La complessità è stata affrontata definendo a livello di gruppo tre tipologie di processi: globali (processi e interfacce centralizzate dal gruppo, stile Zurich), glocali (governo corporate ma specificità locali che fanno la differenza nel Paese, cioè processi centralizzati e interfacce locali) e locali (responsabilità del Country Manager nell’ambito del suo conto economico, cioè processi e interfacce locali). La governance a livello di gruppo è stata così affrontata per i glocali con un budget Ict misurato non sulla performance (efficienza) come per i globali, ma sulla produttività (efficacia), cioè con qualche tolleranza in più in termini di Kpi. Il che comunque non affranca da dipendenze da skill specifici per Paese e richiede capacità comunicative col business e relazionali coi clienti nello specifico.
Peters: Al di là del problema di down-scaling del modello di Demand Mangement, nelle realtà più piccole, che è stato qui testimoniato, le aziende italiane con sussidiarie in giro per il mondo hanno nella centralizzazione del Demand Mangement un’opportunità per essere protagoniste nella globalizzazione con l’affermarsi della Business Technology che integra Business e Ict. Serve il modello di una strategia chiara, articolata e ben comunicata e una solida esecuzione in termini di governance, cruciale nel supportare il cambiamento culturale che segue alla centralizzazione del Demand Mangement.
I ruoli necessari per supportare il Cio
ZeroUno: In questa transizione in cui emergono i processi del modello di Demand Mangement integrato fra business e It, quali ruoli sono importanti per supportare il Cio?
Peters: Un Project Portfolio Manager, responsabile di sviluppare un Project Portfolio mettendo a disposizione strumenti e metodologie necessari e definendo i business case su come raccogliere, misurare e aggiornare i dati. Un Enterprise Architect con alto livello di comprensione della tecnologia, capace di strutturarla in “building block” identificabili fra le deliverable del Project Portfolio. Serve anche un Finance Controller, che capisce e controlla il progredire degli investimenti fatti nel Project Portfolio a fronte del budget approvato per conto delle Linee di business, e ne percepisce il valore sul mercato. C’è anche il ruolo di Account Manager che capisce e rappresenta le esigenze del cliente, senza che l’It debba sviluppare una struttura di vendita. Non ultimo il Service Manager che gestisce operativamente l’interfaccia fra Demand e Supply. Al di sopra di questi ruoli c’è una forte governance che, ad evitare l’instaurarsi di una cultura di silos, è condotta dal Cio per conto del business che ne è naturalmente owner” di ultima istanza.
Gusmeroli: Nella mia esperienza, il Demand Manager, che con competenza di processi rappresenta la comunità di utenti presso la comunità degli applicativi, è una figura di intermediazione fra It e Business davvero giustificata solo in presenza di forti cambiamenti. Finita l’onda, non corre il rischio di non essere più così funzionale e di essere un po’ “né carne né pesce” in una gestione day by day? E’ insomma una figura di transizione o c’è un futuro stabile per questo mestiere?
Peters: In una situazione come l’attuale in cui l’azienda è spinta ad una innovazione continua per estrarre valore di business dall’It, diventa inevitabile la presenza di figure di interpretazione della domanda come il Demand Manager e gli altri ruoli abilitanti il processo Demand-Supply fra Business e It. Ma la domanda non è solo di progetti di innovazione, è anche domanda day by day e gestione dell’ordinario, e anche questa va esaminata col nuovo modello collaborativo di Demand Management. Comunque, lo spirito con cui si devono creare in azienda ruoli come il Demand Manager non deve essere dogmatico per cui se in un It department di cinque persone si individuano venti processi di Demand-Supply si devono mettere venti Manager di processo, ma serve aggregare più ruoli sui candidati adatti in modo pragmatico.
Dambruoso: Come Bmw Italia Group ci troviamo in un contesto internazionale e stiamo vivendo adesso un processo di integrazione business It, con centralizzazione del Demand Management. Come si può declinare al meglio nell’ambito di una struttura che si internazionalizza il processo decisionale stesso? Mentre una struttura decentrata riesce a reagire con un basso time to market al proprio business locale, andando verso un sistema di servizi condivisi i tempi di decisione inesorabilmente si allungano. Un secondo problema è che uno shared service si appoggia ad un team centrale, sia pure arricchito da competenze locali, mentre competenze inserite direttamente a contatto col business sono più efficaci nel seguirlo.
Peters: Ho visto la transizione di servizi condivisi da un’organizzazione di Paese (Germania) a centralizzata globale. Serve un modello contabile (Accounting model) per identificare e quantificare i servizi che si mettono in comune; si parte col consolidamento e si gestisce in modo matriciale un Virtual Management System. E’ però vero che varie organizzazioni sono alle prese con un pesante braccio di ferro sui numeri da ottimizzare, da cui dipende come si distribuiscono i budget, sulla base dei business case. Si ottimizzano quelli in Germania o quelli in Francia o in Italia o in Spagna? In non pochi casi si è finito col non riuscire a realizzare una vera organizzazione di servizi condivisi (ad esempio ho visto opporsi i legali di Paesi fruitori interessati). Alla fine è questo il vero processo decisionale. Non sorprenda che serve il supporto del business e non del solo It. Comunque, prerequisito per servizi condivisi sono proposizioni strategiche forti e chiare. La forte leadership del management di business e una chiara strategia sono gli elementi decisivi. E allora il ruolo chiave del Cio diventa qui educare il business: portare la comprensione pezzo per pezzo al business in modo da abilitarlo alla scelta corretta.
Menegon: Nel passaggio da locale a globale e quando il Demand sfuma al venir meno del progetto innovativo e resta solo la manutenzione evolutiva, cosa cambia per gli strumenti pratici condivisi a supporto del Demand Mangement (sia strumenti informatici che documentazione associata, dai requirement all’analisi di fattibilità al controllo progettuale)? Questi strumenti vanno tarati a seconda dello specifico progetto, pena il fatto che un eccesso amministrativo diventi freno all’agilità del progetto.
Tancini: Per gli strumenti di amministrazione progettuale abbiamo stabilito una soglia di investimento, sopra la quale si è forzata la produzione di business case e controllo amministrativo dell’avanzamento progettuale, sotto la quale si è lasciato in pratica invariato il controllo amministrativo. Al di sopra della soglia è emerso l’obbligo per i costi previsti ed esposti nel business case di un dato progetto di apparire nel budget per la sua gestione. In questo modo si sono impediti giochi “promozionali” di progetti.
