Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Portafoglio applicativo: quando e come va gestito

pittogramma Zerouno

Portafoglio applicativo: quando e come va gestito

22 Giu 2011

di Giampiero Carli Ballola

Le cause che stanno all’origine del sempre maggiore interesse che i responsabili It hanno per l’Application Portfolio Management sono tanto semplici quanto pressanti e ineludibili. Da un lato continua l’imperativo del “do more with less”, ossia fare di più per rispondere ai bisogni del business con risorse umane ed economiche che restano ridotte; dall’altro il lavoro richiesto dalla gestione del portafoglio applicativo continua ad essere tra gli impegni maggiori, se non il maggiore in assoluto, della gestione operativa della funzione It

Per avere un’analisi più dettagliata del problema legato alla gestione del portafoglio applicativo e degli strumenti organizzativi e tecnologici per poterlo fronteggiare e risolvere, Forrester Research ha svolto pochi mesi fa (aprile-maggio 2011) un’indagine in profondità presso più di trenta organizzazioni. Queste comprendono sia strutture It di società utenti di diversi settori (servizi bancari e finanziari, manifatture, società farmaceutiche ed enti pubblici), sia i principali fornitori It in area APM. Su questa indagine e su quanto ne è emerso ci siamo basati per questa serie di articoli.

Perché agire e perché subito
Le motivazioni all’APM che abbiamo più sopra sintetizzato diventano urgenti nella fase di recupero economico che oggi finalmente sembra si stia concretizzando. Le business unit chiedono infatti al Cio di realizzare e rendere disponibili nel più breve tempo possibile le applicazioni e i servizi che ritengono necessari al sostegno e alla crescita della produttività e della competitività. E a questo punto ci si scontra con una realtà che presenta almeno quattro aspetti critici capaci ciascuno di vanificare l’impegno dell’It manager e del suo staff.
Il primo problema è quello economico: non si può, semplicemente, “far di più con meno” se la gestione ordinaria (quella che negli Usa, con un’immagine efficace, si chiama “tenere la luce accesa”) assorbe il grosso della spesa. Secondo la ricerca Forrester il costo medio di queste operazioni supera il 65% dl budget It. È già un guadagno rispetto a quel 75% che viene spesso assunto per questo dato, ma come è ovvio, essendo una media, molte imprese spendono di più. Prima di avviare un piano di APM una grande banca inglese spendeva nel day-by-day addirittura il 90% del budget. Oggi dichiara d’aver dimezzato questa spesa, spostando la maggior parte delle risorse a sostegno dello sviluppo.
Per di più, ed è il secondo punto, l’assorbimento di risorse da parte delle attività correnti non è per niente trasparente, ed è anche per questo che riesce così difficile ridurlo. Ciò vale soprattutto per le risorse umane, spesso impiegate in attività gestite da gruppi di lavoro diversi che fanno cose analoghe ma non comunicano e collaborano tra loro. In questi casi la situazione va avanti finché non succede qualcosa che la rende evidente. Forrester cita il caso d’una società che aveva diversi applicativi Erp che facevano quasi le stesse cose, ma che vennero consolidati solo quando il Cfo lamentò la mancanza di dati necessari per l’auditing. Terzo punto: un portafoglio applicativo inutilmente gonfiato è un freno al time-to market. Introdurre tempestivamente modifiche e cambiamenti è già una sfida in un portafoglio snello; con l’aumentare del numero e della stratificazione delle applicazioni le modifiche, i test e il re-deployment crescono in modo esponenziale. E si tratta di un lavoro che assorbe danaro e persone senza dare vantaggi al business.
Infine, bisogna considerare il fatto che una funzione It che manca alla delivery dei servizi, cioè al suo compito primario, finisce per essere emarginata alla “sala macchine”, che è anche l’anticamera dell’outsourcing. Gli approcci tradizionali allo sviluppo applicativo sono reattivi, centrati sulla tecnologia e in ultima analisi troppo lenti. Bisogna cambiar strada e adottare metodi capaci di cambiare le applicazioni alla velocità con cui cambia il business.

Il controllo del portafoglio applicativo
Un piano di Application Portfolio Management comprende, come vedremo negli articoli a seguire, attività diverse per diverse persone e anche la sua realizzazione può seguire diversi percorsi. Le analisi che Forrester ha precedentemente svolto sul tema le hanno permesso di tracciare uno schema (vedi figura 1) che aiuta sia a sistematizzare queste attività sia a riferirvisi adottando una terminologia comune.


Figura 1 – The Application Management Continuum puts APM Terminology in Context
(cliccare sull'immagine per visualizzarla correttamente)

In ogni caso, quale che sia la strada intrapresa per l’APM, tutte implicano passi a grandi linee simili, che si possono riassumere nelle quattro fasi seguenti.

– Fare un inventario delle applicazioni in portfolio. In parole povere, bisogna sapere cosa esattamente si ha in casa. Alcune organizzazioni si focalizzano soltanto sulle applicazioni ritenute ‘core’, altre invece, per avere il quadro completo dei costi che gravano sull’It, si preoccupano che l’inventario comprenda tutto il parco applicativo. Occorre quindi in primo luogo decidere cosa sia, per la vostra impresa, un’applicazione; che non è una cosa così banale come sembra. Per esempio: bisogna considerare solo gli applicativi che riguardano i processi di business o anche quelli per la comunicazione o la produttività personale? E le applicazioni desktop vanno comprese oppure no? È però un lavoro da fare, e subito.

– Raccogliere le metriche che descrivono le applicazioni. Alcune di queste metriche sono intuitive, come i costi, l’ownership e la finalità per il business. Altre variano a seconda degli obiettivi che si intende trarre dall’APM e quindi del percorso di attuazione. Per alcuni lo scopo è aumentare la produttività dell’It; per altri l’aggiornamento/razionalizzazione di un gruppo di applicazioni correlate; per altri ancora la trasformazione/ammodernamento di tutto il parco applicativo. Quindi: decidere quali indicatori si possono raccogliere e come se ne può far uso in modo da concentrarsi su quei valori che sono allo stesso tempo utili e disponibili.

– Aggiornare periodicamente le metriche raccolte. Una metrica inizia a diventare vecchia già dal momento in cui viene raccolta, ma l’invecchiamento segue tempi diversi: alcune cambiano poche volte in un anno, altre ogni settimana o ogni giorno. Spesso sono proprio quelle che cambiano più spesso le più utili da tracciare e analizzare, ma sono anche le più difficili da raccogliere. Occorre quindi capire come ci si può accorgere del cambiamento di valore di una metrica per decidere la frequenza di aggiornamento e se tale aggiornamento conviene venga fatto per tutte le metriche contemporaneamente o per ciascuna di esse mano a mano che il suo valore cambia.

– Guidare i cambiamenti del portfolio tramite la conoscenza data dalle metriche. Lo scopo finale dell’APM è realizzare una trasparenza dello stato e della dinamica del portafoglio applicativo che aiuti a guidarne le attività strategiche di modernizzazione e trasformazione. Bisogna quindi saper rispondere anche a domande come: Chi avrà il potere decisivo sulle applicazioni e sugli investimenti? Chi altri potrà usare le informazioni raccolte e come? Quale sarà l’aspetto o la prospettiva ritenuta indispensabile? Essere trasparenti riguardo al consumo di risorse, al valore per il business, al costo e allo “stato di salute” (solidità, affidabilità, efficienza e così via) delle applicazioni farà capire quanto bene o quanto male il lavoro dell’It sia allineato agli obiettivi del business e dell’impresa.

Giampiero Carli Ballola
Giornalista

Giampiero Carli-Ballola, nato nel 1942 e giornalista specialista in tecnologia, collabora con ZeroUno dal 1988. Segue i processi di digitalizzazione del business con particolare attenzione ai data center e alle architetture infrastrutturali, alle applicazioni big data e analitiche, alle soluzioni per l’automazione delle industrie e ai sistemi di sicurezza.

LinkedIn

Twitter

Whatsapp

Facebook

Link

Articolo 1 di 2