Una road map per la “Business Technology”

Possiamo chiamare business technology (BT) uno stadio di evoluzione dell’It di supporto delle finalità, delle attività e del profitto di una qualsiasi organizzazione in grado di fondere le strategie di business con le tecnologie digitali associate. Con l’aiuto di uno studio che Forrester Research ha effettuato sul tema, proponiamo una ‘road map’ per introdurre e far crescere le pratiche della BT in azienda.

Pubblicato il 14 Feb 2014

Le attività che definiscono un percorso di Business Technology (Bt) non si svolgono linearmente, ma sono correlate in modo tale per cui ogni decisione viene influenzata dalle decisioni precedenti e ogni mutamento comporta una revisione di piani già definiti. Occorre quindi un modello di pianificazione che, tramite circuiti di feedback e ottimizzazione permetta di apportare modifiche e correzioni di rotta ‘in corsa’ tali da mantenere le operazioni di Bt allineate a strategie e obiettivi di business in continuo cambiamento (figura 1). Di queste attività e del modello che le raccoglie tratteremo nei punti a seguire.

Figura 1. Road Map per l'implementazione di una corretta strategia di Business Technology

Fonte: Forrester Research

Rivalutare gli assunti e le metriche. Le considerazioni iniziali in base alle quali sono stati proposti i business-case e si è deciso il finanziamento dei progetti vanno riviste sulla realtà e sui limiti delle risorse e delle tecnologie presenti. Ciò può cambiare gli scenari previsti per la realizzazione dei progetti stessi: per esempio, la mancanza di risorse interne può portare alla ricerca e assunzione di consulenti esterni, ritardando la programmazione e posticipando i benefici previsti. Per questo, prima di decidere sulla scelta delle risorse, sui tempi e sul personale, bisogna controllare che gli obiettivi di business e i valori sui quali questi vanno misurati non siano influenzati da iniziative dovute ad altri progetti in corso, con un’operazione che va ripetuta ogni volta che si giunge a uno dei punti-chiave per la verifica dell’avanzamento del progetto e ogni volta che interviene uno dei seguenti fattori:
– un mutamento del mercato o dell’organizzazione del business che porti a cambiarne gli obiettivi, comprese decisioni interne all’azienda da parte degli stakeholder;
– una modifica dei tempi d’implementazione che comporti un cambiamento degli assunti economici sui quali si è approvato e finanziato il progetto;
– un cambiamento significativo degli obiettivi del progetto stesso, come l’aggiunta di nuove prestazioni, che vada a incidere il rapporto tra costi e benefici e a modificare il Roi stimato. In tal caso va rivista anche l’analisi finanziaria del business-case e la sua posizione nei piani d’investimento dell’azienda.
Gli strumenti di project management sul mercato forniscono supporto tecnologico a queste operazioni di monitoring tramite mappe concettuali, diagrammi di Pert (percorsi di attività), diagrammi Ishikawa (analisi catena causa-effetto) e altre tecniche di controllo. Per usare efficacemente tali strumenti occorre però che il project manager istituisca un meccanismo di comunicazione-condivisione delle informazioni che lo mantenga in contatto con tutti gli stakeholder del progetto, sia nell’ambito It che in quello del business.

Trasformare le strategie in programmi. Un progetto è raramente associato a un singolo impegno, ma comporta molte attività simultanee che avvengono entro un ecosistema di progetti individuali che vanno tutti allineati a uno stesso piano strategico. Bisogna capire come e dove questi progetti entrino nel quadro generale per migliorarne le possibilità di successo e il reciproco allineamento, in modo da potenziare le prestazioni di business. Per questo, è utile che gli obiettivi progettuali e le strategie per raggiungerli siano chiaramente esposti agli stakeholder. Program manager e responsabili delle relazioni con il business devono quindi:
– controllare che le attività relative a nuovi progetti non entrino in conflitto con decisioni precedenti. Un esempio banale: se si è deciso di abbandonare una certa area di business, bisogna verificare che non sia stato precedentemente deciso di potenziare i sistemi che supportano le attività in quest’area;
– evitare, come spesso accade, di classificare i progetti secondo due distinte visioni di sviluppo del business e di condotta delle operazioni (con quest’ultima di solito messa in secondo piano). Occorre invece una vista generale che leghi le strategie ai programmi che ne derivano, altrimenti si rischia che le priorità ai progetti siano date su basi più “politiche” che business-focused, ritardando, per esempio, progetti di taglio operativo che potrebbero però sviluppare il business.

Figura 2.Percorso per trasformare le strategie in programmi.

Fonte: Forrester Research

Orchestrare le strategie per ridurne i conflitti. Spesso, una volta steso un programma generale si passa subito alla sua esecuzione senza considerare le relazioni tra le singole strategie coinvolte né il loro impatto sulle applicazioni e sulle operazioni in atto. Conoscere questi aspetti può prevenire conflitti e colli di bottiglia nello svolgimento delle operazioni ed evitare, o ridurre al minimo, l’esecuzione di progetti che puntano ai medesimi obiettivi di business, rafforzando così l’efficienza dell’impresa. Un programma esecutivo che consideri le strategie e le tattiche d’implementazione coinvolte (figura 2) permette di:
– evitare che progetti non allineati al programma generale consumino le risorse disponibili;
– restare focalizzati sui risultati seguendo i cambiamenti delle attività di business e dei processi operativi attraverso la collaborazione fra i program manager e gli stakeholder del business. Ad esempio, dando ai business manager le tempistiche per cambiare i loro processi. Le tecnologie raramente creano direttamente valore, ma abilitano i processi in grado di farlo. Focalizzarsi sui risultati è più efficace nel sincronizzare business e It che non il rigido rispetto delle scadenze interne dei progetti tecnologici.

Definire piani esecutivi per la strategia di business. Ogni cambiamento nei risultati attesi dal progetto (per esempio, passando dal taglio dei costi all’aumento del fatturato o dalla riduzione dei rischi all’avvio di nuovi business) può e deve influire sulle decisioni relative a dove e come trovare la soluzione. Bisogna però verificare che i criteri di scelta della soluzione si basino su finalità e metriche definite nella strategia e convalidate dai business-case. Il project management deve quindi:
– identificare i problemi esistenti nella gestione dell’infrastruttura e delle operazioni e considerarli in vista delle nuove iniziative. Assegnare le priorità in base ai risultati attesi porta a spostare il costo del lavoro da attività di basso valore, come la manutenzione, a quelle abilitanti il business, con un confine tra le due che nelle organizzazioni più avanzate è sempre meno evidente;
– coinvolgere da subito l’It nel progetto strategico generale, prima che questo sia definito. Se no, si rischia che i responsabili It, non avendo una chiara comprensione di quanto i cambiamenti di loro competenza contino nell’allineamento al business, siano restii a cambiare i propri piani;
– creare un sistema di reporting che dia visibilità ai progressi del progetto e del suo allineamento al business a tutti gli interessati, un compito che, senza un sistema di reporting (preferibilmente fruibile in autonomia dagli interessati), sarebbe time-consuming per il project manager e quindi non sostenibile.

Figura 3. Definire con chiarezza obiettivi che influiscono sulle scelte delle risorse.

Fonte: Forrester Research

Stabilire gli investimenti sul miglior uso delle risorse. Una strategia di Bt di solito copre più progetti It e con il crescere in numero e complessità dei progetti, coordinare le attività coinvolte affinché convergano sul business e sincronizzare l’evoluzione di persone, processi e tecnologie diventa difficile. Una mappa delle ‘business capability’, ossia dei punti del progetto che indirizzano gli obiettivi e le risorse aziendali, permette di unificare le diverse iniziative evidenziando le sinergie e le sovrapposizioni con progetti mirati agli stessi obiettivi, e di decidere la scelta migliore, in termini di ‘build or buy’, per dotarsi delle risorse necessarie. A questo riguardo, si tratta in pratica di:
– chiarire quali sono gli obiettivi che influiscono sulla scelta delle risorse. Un progetto critico per il business dovrà ridurre il rischio, mentre uno orientato a nuove iniziative darà più peso alla flessibilità. Analogamente, per avere un differenziale competitivo definito si potrà investire in una soluzione custom, mentre per abilitare un tipo di business non ancora verificato converrà ridurre la spesa, ricorrendo a soluzioni cloud-based (figura 3);
– sviluppare metriche di valutazione correlate al business. Ciò vale soprattutto per i service provider, dove queste metriche devono sostituire quelle basate sulle operazioni. In tutte le trattative bisogna infine che il focus resti sempre sui veri obiettivi aziendali, non su quelli che, anche con le migliori intenzioni, sono recepiti da outsourcer, consulenti e fornitori.

Comunicare la road map ai business stakeholder. Informare chiunque sia interessato al successo dell’impresa sullo stato di avanzamento dei progetti minimizza lo scollamento tra It e business e aumenta le probabilità di successo di entrambe le parti. Le informative devono essere regolari, aggiornate e calibrate sulle varie esigenze dei destinatari. Questo tipo di comunicazione permette di:
– pianificare per tempo i cambiamenti ai processi di business necessari a trarre profitto da nuove tecnologie;
– coordinare con la funzione It quelle attività di tipo tecnologico, sempre più frequenti nel campo, per esempio, della business intelligence, che il business può svolgere in proprio;
– allineare le risorse business agli avanzamenti dell’It, organizzando le relative attività. Per esempio, se una certa soluzione di sales support non sarà disponibile prima di sei mesi un direttore vendite deciderà se assumere personale temporaneo o se prepararsi a formare i suoi venditori. Come, sapendo su quale piattaforma mobile l’It si va orientando, spingerà i dipendenti a dotarsi di dispositivi compatibili.

Figura 4. La road map di una corretta Bt è un processo continuo che prevede costanti feedback e revisioni, essendo i processi strettamente interdipendenti

Fonte: Forrester Research

Maturare via feedback il modello della BT
Per finire, vogliamo ricordare che la road map non è che un passaggio intermedio di un processo continuo che si basa su cicli di feedback, revisioni e modifiche costantemente e mutuamente legate (figura 4). Una volta che il modello operativo della business technology sia maturo, l’organizzazione It si troverà ad agire come un gestore finanziario, decidendo, al fine di raggiungere gli obiettivi dell’impresa, come comprare, vendere o accantonare ogni tipo di asset disponibile: persone, tecnologie, risorse economiche. I progetti saranno scelti sulla capacità di creare valore, lasciando in secondo piano e in pura funzione dei benefici ottenibili le scelte di prodotto, di tecnologie e di fornitori. L’intero portafoglio della Bt sarà infine valutato a scadenze trimestrali sulla capacità di sviluppare il business in base al feedback del project management e alle metriche definite, creando un processo dinamico, reattivo agli stimoli interni ed esterni all’impresa, capace di influenzare il comportamento dell’intera organizzazione.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati

Articolo 1 di 2