La messa in produzione di una nuova applicazione o di nuove funzionalità è un momento di grande criticità per l’azienda e la mancata o inadeguata considerazione di alcuni parametri nello sviluppo del software o la non perfetta aderenza alle esigenze funzionali del business possono causare non pochi problemi ai team It, quando non addirittura avere impatti talmente gravi sul sistema informativo da inibire l’attività stessa dell’azienda.
Nata proprio dall’esigenza di comprendere meglio il grado di consapevolezza nelle aziende italiane dell’importanza del tema della qualità dello sviluppo applicativo, della misurazione delle performance delle applicazioni e in ultima analisi della qualità complessiva dei sistemi informativi, l’indagine online Quality & Performance Management condotta da zerouno nei mesi di marzo e aprile 2008, ha permesso, oltre che di indagare questi specifici aspetti, di effettuare una fotografia della modalità di approccio allo sviluppo e implementazione delle applicazioni e dell’evoluzione delle relazioni tra It e business che, proprio negli ambiti applicativi, manifestano tutta la loro importanza e criticità.
L’indagine di cui illustriamo in queste pagine le principali evidenze, si inserisce nell’osservatorio Quality & Performance Management di zerouno, un progetto realizzato con la collaborazione di Hp, che vuole essere un punto di osservazione e analisi continua sulle problematiche della misurazione della qualità e delle prestazioni dei sistemi informativi e si realizza attraverso una serie di iniziative: un’area del sito www.zerounoweb.it ricca di articoli, white paper, documentazione sul tema; tre indagini (oltre a questa, di cui riportiamo i risultati, altre due che verranno effettuate a partire da luglio e in autunno) per capire come le aziende si stanno muovendo per gestire qualità e performance dei sistemi informativi; un “Incontro a Cena con gli Utenti”, svoltosi lo scorso giugno e che illustriamo nell’articolo seguente, per confrontarsi direttamente sulle principali problematicità del tema.
Le caratteristiche del campione
Trattandosi di un questionario online aperto a tutti, l’indagine non può avere valore statistico ma l’analisi a posteriori del campione ci consente di dire che esso ben rappresenta la realtà italiana. Per garantire una maggiore attendibilità dei risultati, l’analisi dei dati è stata effettuata su quegli 80 rispondenti che hanno indicato i propri riferimenti.
La suddivisione per settore di attività evidenzia un campione che rappresenta per il 48% i comparti Industria, servizi, distribuzione e commercio, per il 38% Fornitori di prodotti e servizi Ict, per l’11% la Pubblica Amministrazione, con un restante 3% a coprire altri settori.
In termini dimensionali, il campione è polarizzato sulle due dimensioni Pmi (1-249 dipendenti) e grandi aziende (oltre 1000 dipendenti) con una decisa maggiore incidenza delle prime (50% del campione) sulle seconde (31%), mentre risultano decisamente meno presenti le medie imprese (19%). L’analisi dei rispondenti per ruolo professionale evidenzia un buon mix dei partecipanti tra esperti Ict (36% responsabili e 8% addetti del team It) e non (8% di amministratori delegati e direttori generali e 18% di manager non Ict); l’ago della bilancia è costituito dal 10% dei liberi professionisti che possiamo presupporre essere nel campo Ict.
Un aspetto che abbiamo ritenuto importante prendere in considerazione nella definizione del campione è rappresentato da alcune essenziali caratteristiche del team It e la relazione gerarchica del suo responsabile con il management aziendale. Per quanto riguarda il numero dei componenti del team It, la risposta è perfettamente coerente con le caratteristiche dimensionali delle aziende rappresentate: in più della metà del campione il team It è composto al massimo da 15 persone (30% team di 1-5 addetti; 26% da 6 a 15); nel 24% si compone di 16-50 addetti mentre le classi 51-100 e oltre 100 rappresentano ciascuna il 10%.
Dialogo it-management
Particolarmente interessante è il dato relativo alla relazione gerarchica del responsabile It con il management aziendale. Si era chiesto ai partecipanti di indicare il diretto riporto del responsabile It: nel 52% è stato indicato l’amministratore delegato o il presidente; nel 48% altro dirigente. Questo risultato è coerente con quelli di altre ricerche che testimoniano l’evoluzione del ruolo del responsabile It: nella maggior parte dei casi egli riporta direttamente a posizioni di vertice aziendale per poter avere la corretta visione dei problemi strategici e poterli affrontare con l’impiego dell’It in una reale prospettiva aziendale (e non funzionale).
Passando ad analizzare la modalità di gestione del sistema informativo, il messaggio forte che emerge è chiaro: come è tipico in Italia, quasi tutto è “fatto in casa”. Infatti l’87% dei rispondenti dichiara di gestire sia l’infrastruttura hardware sia il parco applicativo in casa e solo il 13% si affida a qualche forma di outsourcing. Al fine di avere una fotografia più precisa potrebbe essere interessante approfondire questi risultati indagando la collocazione fisica e la proprietà dell’infrastruttura hardware e del parco applicativo. La conoscenza derivante da altre analisi ci dice che i casi più frequenti sono: infrastruttura e parco di proprietà dell’azienda, collocati in casa ma gestiti da un outsourcer; entrambi collocati all’esterno presso un outsourcer che ne fa anche la gestione operativa, ma con proprietà del parco applicativo dell’azienda e proprietà dell’hardware dell’outsourcer (hosting).
Figura 1
Attività, relative al parco applicativo, svolte dal team IT interno all’azienda
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
Cliccare sull’ immagine per visualizzarla correttamente
La figura 1 ci mostra quali attività, relative al parco applicativo, vengono svolte dal team IT interno all’azienda; ne emergono alcune interessanti evidenze. L’Analisi e la progettazione di nuove soluzioni applicative è un’attività critica e di alto valore aggiunto ed è correttamente svolta più internamente (64%). È invece “il problema” il comportamento relativo alla Manutenzione ordinaria (il 61% la svolge internamente) che è molto routinaria e che sarebbe più logico affidare all’esterno rispetto alla Manutenzione evolutiva, più difficile da prevedere e spesso più vicina ai progetti applicativi, e che compare in ultima posizione con il 49% dei casi che la svolge in casa. È la chiara indicazione di come oggi i sistemi informatici delle imprese siano ancora “invischiati” nella complessa gestione del day by day, dedicandoci risorse economiche e professionali che potrebbero invece essere orientate a progetti di innovazione (Attività applicativa evolutiva). L’Helpdesk applicativo è relativamente più erogato in casa probabilmente perché è difficile avere gli stessi livelli di servizio quando sono esternalizzati (è diverso per l’Helpdesk tecnico che invece viene più spesso esternalizzato). Lo Sviluppo e implementazione di nuove soluzioni solitamente si configurano come veri progetti applicativi e il campione è polarizzato su due comportamenti: metà gestiti in casa e metà affidati all’esterno.
Un ultimo aspetto che ci è servito a inquadrare il nostro campione di riferimento è quello relativo all’impatto sul sistema informativo, sempre con particolare riferimento agli ambiti applicativi, della strategia e delle soluzioni di sicurezza implementate. Si era chiesto di dare una valutazione di questo impatto sia intermini di efficienza sia in termini di performance dei sistemi; ne è risultato che le percezioni d’impatto, concentrate sui valori medio e alto, sono abbastanza equilibrate sui due aspetti, ma possiamo affermare che c’è ampio spazio di miglioramento in quanto la misurazione dell’impatto, benché difficile, potrebbe dare un contributo serio alla comprensione del ruolo delle soluzioni di sicurezza. Infatti con buoni sistemi di misurazione dovrebbe essere verificabile l’impatto delle soluzioni per la sicurezza sia sull’efficienza del sistema informativo (per esempio riduzione costi di gestione dei malfunzionamenti o degli incidenti), sia sulle performance (per esempio continuità di servizio).
Allineamento it-business
L’indagine prevedeva una serie di domande indirizzate a comprendere il livello di allineamento tra funzione It ed esigenze di business. La figura 2 mostra, in relazione al settore di appartenenza, in quali fasi dello sviluppo di nuovi prodotti/servizi da proporre al mercato è coinvolta la funzione It.
Figura 2 – Fasi dello sviluppo di nuovi prodotti/servizi da proporre al mercato nelle quali è coinvolta la funzione IT (risposte in relazione al settore di appartenenza)
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
Cliccare sull’ immagine per visualizzarla correttamente
Il ruolo della funzione It appare sempre elevato nelle tre fasi tipiche del processo di innovazione aziendale (Ideazione, Sviluppo e Lancio di nuovi prodotti/servizi basati sull’It), con valori sempre oltre al 50% dei casi. Fa eccezione la fase di Lancio sul mercato nel settore delle aziende Ict dove si presume che la fase sia prevalentemente seguita dalla funzione marketing e commerciale, costituendo il nuovo prodotto/servizio un oggetto core business per l’azienda Ict (cioè generatore di ricavi), aspetto che non possiamo dare per scontato negli altri settori indagati. Un sensibile maggior ruolo creativo della funzione It sembra presentarsi nella Pa, sanità e utility (78% nella fase di ideazione), rispetto al resto dei settori dell’industria e dei servizi dove sembra avere un ruolo sensibilmente maggiore nella fase di sviluppo (72%), rispetto alla ideazione o al lancio dell’innovazione.
Figura 3
Valutazione capacità di risposta (in termini temporali) della funzione IT alle esigenze manifestate dal business
Cliccare sull’ immagine per visualizzarla correttamente
Figura 4
Come viene valutata la capacità di risorse (in termini qualitativi della funzione IT alle esigenze manifestate dal business)
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
Le figure 3 e 4 evidenziano il gap di percezione classico tra il mondo It e il management aziendale sulle capacità di risposta sia in termini temporali sia in termini qualitativi della funzione It alle esigenze manifestate dal business e questo nonostante, come abbiamo visto, i responsabili It siano sempre più vicini al top management e gli interventi volti a modificare l’assetto organizzativo che si continuano a fare. In questo quadro generale ci sempre inoltre importante sottolineare che nell’analisi qualitativa (figura 4) il gap maggiore si ha nella valutazione “buona-ottima” a testimonianza del fatto che è sulle prestazioni di eccellenza che si creano le divergenze, e non su quelle ordinarie, ma che è anche sempre difficile misurare in modo oggettivo il rispetto dei Business requirement nei progetti applicativi o nell’application management.
La figura 5 mostra l’esistenza, in relazione alla dimensione aziendale, di figure predisposte alla gestione delle relazioni con i diversi utenti aziendali all’interno del team It dell’azienda.
Figura 5
Figure predisposte alla gestione delle relazioni con i diversi utenti aziendali all’interno del team IT dell’azienda (risposte in relazione alla dimensione aziendale)
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
I l grafico presenta un messaggio forte: dove esistono complessità e rilevanti popolazioni di user, le figure di account manager, client manager o demand manager sono una realtà affermata (84%). Sono in fase di diffusione invece nelle medie e nelle piccole, dove probabilmente non si pensa a persone dedicate, ma a persone che dedicano quota parte del loro tempo alle relazioni con l’utenza. L’evoluzione di queste figure è molto importante e negli ultimi anni queste professionalità di “relationship management” sono diventate molto critiche nelle funzioni It al fine di garantire un miglior coordinamento tra domanda e offerta di servizi It e quindi un miglior allineamento tra It e business. Siamo inoltre in presenza di un’ulteriore evoluzione che riguarda la collocazione stessa di queste figure nel senso che si stanno sviluppano figure di “collegamento” all’interno delle funzioni di business; cosa diversa dai tipici key user si tratta infatti di utenti con una competenza tecnica più elevata; e oggi si discute proprio se è meglio collocare queste figure all’interno della funzione It o all’interno della funzione utente.
Figura 6
Tecniche usate per la definizione dei requisiti informativi e funzionali (risposte in relazione alla dimensione aziendale)
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
Se poi andiamo sulle tecniche usate per la definizione dei requisiti informativi e funzionali (figura 6), in generale si evidenzia che l’intervista strutturata è ancora la tecnica più impiegata nella definizione dei Business Requirement, con percentuali molto elevate in tutti i segmenti dimensionali. Segue la prototipazione, sensibilmente più impiegata nelle grandi imprese (56%), mentre l’uso di software template non è molto diffuso: le medie imprese sembrano essere quelle più sensibili al fatto che buoni software template possano essere efficaci “veicoli” di idee e di specifiche di ausilio nella fase di rilevazione dei requisiti. Lo studio di fattibilità, visto sia come strumento decisionale per il “go – no go” di un progetto It sia in fase di definizione dei macro-requisiti, ha una diffusione media, in quasi un terzo dei casi del campione: troppo poco, soprattutto vista la sua importanza per valutare progetti It di innovazione o che sperimentano nuove tecnologie Ict.
Figura 7
Figure/ruoli coinvolti nel processo di definizione dei requisiti informativi e funzionali
e loro grado di coinvolgimento
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
La figura 7 evidenzia una forte internalizzazione del processo di analisi dei requisiti: analizzando le risposte relative alle figure e ai ruoli coinvolti nel processo di definizione dei requisiti informativi e funzionali e il loro grado di coinvolgimento risulta che i consulenti sono poco coinvolti (“mai o qualche volta” nel 70% dei casi circa); le prime tre figure (process owner, keyuser, application specialist) sono i veri “perni” del processo di definizione dei Business Requirement. Una riflessione a parte merita il fatto che dovrebbe essere più presente il Business Analyst (orientato più ai processi aziendali) rispetto all’Application Specialist (orientato più alla conoscenza delle specifiche applicazioni informatiche): probabilmente questa figura professionale è meno diffusa, rintracciabile e identificabile nelle imprese ed è spesso confusa con lo stesso specialista di un’area applicativa.
Per chiudere l’analisi dell’allineamento It-business abbiamo chiesto se vengono utilizzati specifici strumenti di gestione dei requisiti: la risposta del campione (negativa nel 67% dei casi) è coerente con il fatto che in questo ambito si usano spesso strumenti semplici di Office per formalizzare e documentare i requisiti (e purtroppo si tratta di una modalità poco usabile da chi deve poi progettare le applicazioni); in generale c’è scarsa attenzione aziendale agli strumenti di gestione dei requisiti, a parte chi fa dell’It il proprio oggetto di business (software house, system integrator, ecc.).
Le performance del sistema informativo
Una delle evidenze maggiori dell’indagine è che la misurazione delle Performance It, in particolare quelle applicative, è ancora una delle sfide maggiori che le imprese hanno di fronte per allineare il parco applicativo alle esigenze informative sempre più dinamiche; al riguardo esiste ancora un forte gap tra ciò che si ritiene importante misurare e ciò che viene realmente misurato (figura 8).
Figura 8
Confronto tra fattori che si ritiene più importante misurare per valutare le performance del sistema informativo e fattori effettivamente misurati in azienda
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
Dalla richiesta di assegnazione di un punteggio da 1 a 5 (dove 5 è il più importante) ai fattori che si ritiene più importante misurare per valutare le performance del sistema informativo emerge che la Continuità e disponibilità del servizio è al top come grado di importanza, come del resto sempre avviene in tutte le ricerche sui temi degli indicatori di performance It. Il confronto con il posizionamento di questo fattore nell’ambito di quelli “effettivamente misurati” ne conferma la pole position. E qui vorremmo fare una piccola provocazione: il sospetto ormai è che questa sia la vera criticità dei sistemi informativi nelle aziende e che garantire continuità e disponibilità sia ancora un problema irrisolto, da non dare per scontato, nonostante lo sviluppo tecnologico, la disponibilità attuale di risorse ridondanti e la robustezza delle tecnologie infrastrutturali di base.
Il secondo messaggio riguarda il cluster dal 2° al 4° fattore (l’ordine dei fattori è dato, in figura 8, da ciò che si ritiene importante misurare a partire, in alto, dal più importante) molto simili come risposte: progetti It, processi It e soddisfazione degli utenti sono alla ribalta dell’attenzione negli ultimi anni e generalmente costituiscono una buona componente dei cruscotti direzionali per il Cio.
Il cluster fatto dai successivi tre fattori molto simili come risposte, mostra che prestazioni tecniche, supporto e sicurezza sono in fase di maturazione nella misurazione, ne emergono le seguenti evidenze: le prestazioni tecniche dei sistemi in realtà sono molto difficili da misurare e non danno informazioni rilevanti ai fini decisionali manageriali; la minore importanza assegnata al fattore supporto è strana perché è tra i fenomeni più facilmente misurabili e utili (soprattutto perché esprimono un’altra faccia della customer satisfaction); lo stesso vale per la sicurezza perché è tra i fenomeni più facilmente misurabili con gli strumenti oggi disponibili sul mercato (forse la vera barriera è rappresentata dal loro costo).
Infine Qualità dei servizi interni It e Costi e budget It chiudono la serie: il posizionamento del fattore Qualità dei servizi interni It è comprensibile perché è difficile da declinare nei fattori determinanti, ma la collocazione del fattore Costi e budget It all’ultimo posto come grado di importanza è molto strana: viene dichiarata poco importante quasi fosse un aspetto di misurazione “culturalmente” negativo. Ma, quando si vanno a guardare i fattori effettivamente misurati risulta invece essere al secondo posto: in realtà l’attenzione ai costi è ancora alta, la loro misurazione è relativamente facile (almeno extra-contabilmente); tutti i sistemi di Kpi dell’It sono molto ricchi di misure economiche, quindi la relativa bassa importanza assegnata può essere molto influenzata oltre che da aspetti “culturali” prima accennati anche dai liberi professionisti e dalle aziende Ict che hanno risposto.
Altri gap relativi di un certo rilievo sono quelli riguardanti il controllo dei progetti, le prestazioni dei sistemi e la gestione della sicurezza. In generale, ad eccezione della misurazione della customer satisfaction (sostanzialmente allineate), la percentuale dei casi di chi misura effettivamente il fattore e chi lo reputa importante da misurare, è sempre a favore della misurazione reale: anche se le percentuali riguardano sempre meno del 50% dei casi (ad eccezione dei prime tre fattori già citati), si misura più di quanto si vorrebbe “trascinati” da qualche motivo esogeno; o si misurano i fattori sbagliati?
Stato del portafoglio applicativo
Per indagare l’ambito della qualità del software e della misurazione delle performance applicative abbiamo dovuto fotografare lo stato del portafoglio applicativo presente nelle aziende dei rispondenti.
Figura 9
Confronto tra applicazioni implementate in azienda e applicazioni considerate strategiche(risposte in relazione alla dimensione aziendale)
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
La figura 9 mette a confronto le applicazioni realmente implementate in azienda con quelle che vengono considerate strategiche sulla base delle classi dimensionali delle aziende. Per quanto riguarda le applicazioni effettivamente implementate, la prima evidenza è che, a parte la Business Intelligence e le applicazioni verticalizzate, tutte le altre aree decrescono come presenza al descrescere delle dimensioni aziendali, alcune in modo molto forte (per esempio Scm). Le applicazioni verticalizzate sono sempre presenti in alta percentuale perché esprimono il forte orientamento delle nostre imprese alla soluzione custom o comunque fortemente adattata alle proprie esigenze, considerate sempre uniche e specifiche (e qui sarebbe importante chiedersi se si tratta di un reale fattore differenziante sul mercato o se comporta solamente complessità e costi inutili).
La valutazione del grado di rilevanza strategica delle applicazioni è sempre superiore nelle imprese più piccole (con punte del 100% nei sistemi di produzione e di Scm che sono anche le aree relativamente meno implementate in queste imprese) rispetto alle medie e alle grandi: la percezione di importanza del software applicativo a supporto dei processi operativi e di management è sempre maggiore ove le complessità organizzative sono minori e dove se ne possono valutare più facilmente gli impatti sui processi di lavoro. Le imprese medie manifestano una percezione opposta, esplicitando un grado di rilevanza strategica generalmente inferiore rispetto all’installato effettivo (gap molto evidente nel caso della Business Intelligence), a eccezione dei sistemi di Scm, percepiti invece più importanti di quanto non siano realmente presenti in queste imprese (unica aspettativa di sviluppo del portafoglio). Le imprese grandi presentano percezioni di importanza più “vicine” in generale ai valori dell’installato reale: Business Intelligence e applicazioni verticali manifestano un grado di importanza strategica superiore rispetto al parco effettivamente implementato e possono rappresentare i “desiderata” nello sviluppo del loro portafoglio applicativo.
Figura 10
Livello di personalizzazione sviluppato per ciascuna applicazione
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
La figura 10 evidenzia il livello di personalizzazione sviluppato per ciascuna applicazione: giustamente le percentuali di personalizzazione del software sono relativamente maggiori nelle applicazioni verticalizzate (39% +25%), testimoniando il fatto che una quota rilevante di queste potrebbero essere state realizzate con sviluppo custom (in house o all’esterno) e non come personalizzazione di pacchetti applicativi di mercato. A seguire, gli Erp sono l’area applicativa relativamente più personalizzata, fenomeno conosciuto e tipico del nostro paese. Infine, come era prevedibile, le aree dove si personalizzano di meno i package standard di mercato sono i sistemi di Scm, i sistemi di produzione e i sistemi di Business Intelligence, che evidentemente presentano pratiche meglio adattabili (parametrizzabili) alle esigenze delle imprese italiane.
Alla domanda su chi ha sviluppato le personalizzazioni, i rispondenti dichiarano che solo il 20% delle personalizzazioni viene effettuato da software house esterne o system integrator, il 39% dal team interno It con un supporto esterno mentre addirittura il 41% viene realizzato esclusivamente dal team It interno: questi dati evidenziano ancora una volta una forte “internalizzazione” delle competenze di sviluppo applicativo, con un forte e abituale impiego del body rental esterno, e meno di risorse professionali di livello (per esempio Project manager).
Figura 11
Tasso di rinnovamento del parco applicativo previsto in azienda nei prossimi 12 mesi
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
La figura 11 ci dice invece qual è il tasso di rinnovamento del parco applicativo previsto in azienda nei prossimi 12 mesi. Emergono aspettative di buona staticità applicativa per i prossimi 12 mesi oppure le aziende pensano soprattutto a valorizzare gli investimenti applicativi realizzati negli anni scorsi. Cercando una corrispondenza tra la dimensione del tasso di rinnovamento e il tipo di attività prevista (all’aumentare del tasso di rinnovamento si può intuire che aumenti la complessità e la strategicità dei processi coinvolti), sembra che le imprese pensino prevalentemente a processi di manutenzione ordinaria e correttiva (21%), e di manutenzione evolutiva (51%): sicuramente pochi sono i progetti applicativi strategici, di innovazione o di rifondazione del portafoglio applicativo e del sistema informativo (23%+5%).
Abbiamo poi chiesto di rispondere a una domanda specifica sull’ipotesi di implementazione di applicazioni basate sull’architettura Soa. Il 32% ha risposto “Non so” e il 24% “No”; a fronte di questi dati negativi imputabili anche sicuramente alla ancora scarsa conoscenza del fenomeno Soa, abbiamo però un terzo del campione che prevede di implementare soluzioni di questo tipo entro i prossimi sei mesi (20%) o entro un anno (11%); questi possono essere considerati come un cluster di pionieri o di sperimentatori dei risultati reali delle Soa. Il restante 13% ne prevede l’implementazione entro due anni.
L’oggettiva difficoltà attuale nel definire in quali circostanze un progetto di sviluppo applicativo possa essere considerato Soa-based o no rende difficile apprezzare questo risultato che per certi versi è positivo, per altri può rappresentare un’inerzia o un onda lunga italiana, poiché di Soa si parla dal 2004 e qualcuno sostiene anche che di Soa se ne è sempre parlato dagli anni ’90.
Misurazione della qualità e delle performance del parco applicativo
Nell’indagare questo ambito, il “cuore” dell’inchiesta, abbiamo chiesto al nostro campione di esprimersi sull’importanza attribuita all’introduzione di meccanismi di quality management e di performance management nello sviluppo applicativo. Dalle risposte emerge che la maggioranza del campione (46% molto importante e 16% indispensabile) manifesta un’elevata importanza percepita dell’impiego di meccanismi di quality management: ovviamente poiché l’execution di questi meccanismi richiede buoni investimenti economici e di competenza, il gap rispetto all’“attuato” o all’ “attuabile” sarà sicuramente elevato. Altrettanto elevata (55% molto importante e 10% indispensabile) è l’importanza di impiegare sistemi di Performance Management: l’orientamento è chiaro ed è supportato anche dalle nuove versioni delle principali metodologie internazionali quali il Cobit (v. 4 e succ.) e l’Itil (v. 3). Anche in questo caso, la fatica risiede nella progettazione e nell’implementazione di questi sistemi: è evidente che è necessario aiutare le imprese nella concretizzazione di questo interesse con metodologie di misurazione per prototipi, “rapide”, “significative”, “auto-certificate” (cioè che non impiegano necessariamente dati ufficiali e certificati).
Figura 12
Importanza delle motivazioni indicate nell’introduzione di meccanismi di application quality management
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
Andando a indagare le motivazioni considerate più importanti nell’introduzione di questi meccanismi vediamo che per l’application quality management (figura 12) il messaggio più rilevante che emerge è sicuramente la relazione percepita tra Application Quality Management e “time to market” (45% dei casi la reputa molto importante e il 44% mediamente importante): ciò può essere letto in due modi, non mutuo-escludentisi: la qualità delle applicazioni si misura anche e soprattutto con la velocità di realizzazione e di messa in esercizio; la qualità si traduce in una riduzione del tempo dedicato alla correzione degli errori applicativi (per esempio non rispetto dei requirement, bug logici, ecc.) e quindi in una riduzione del tempo complessivo di rilascio delle applicazioni stesse. Relazioni mediamente importanti vengono espresse tra l’ Application Quality Management e gli altri fattori indagati, come la vulnerabilità e la complessità delle applicazioni, e rispetto al liberare risorse da dedicare ad altri progetti applicativi.
Figura13
Importanza delle motivazioni indicate nell’introduzione di meccanismi di performance management
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
Sul fronte dell’Application Performance Management (figura 13) l’importanza è determinata soprattutto dalla conseguente capacità di valutare gli impatti delle applicazioni sul business aziendale (il 45% attribuisce alta importanza a questo elemento): implicitamente questo significa che gli indicatori e le misure a cui si sta pensando sono indicatori di risultato e di prestazione aziendale, non tecnici, e questo, è noto, accresce il grado di difficoltà sia della progettazione che della misurazione reale di questi indicatori. La riduzione del rischio operativo e la valutazione della user satisfaction seguono nella scala delle motivazioni espresse, circa la necessità di un sistema di Application Performance Management.
Figura 14
Quali sono i processi e gli strumenti ritenuti più utili per garantire una gestione delle performance applicative in una logica ent to end
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
La figura 14 ci dice quali sono i processi e gli strumenti ritenuti più utili per garantire una gestione delle performance applicative in una logica end to end. Sommando le percentuali relative alle risposte Indispensabili e Molto utili, sul fronte della gestione delle performance applicative (non della misurazione), i processi ritenuti più efficaci sono nell’ordine (nel grafico sono ordinati sulla base della sola opzione Molto utili):Application management (83%), Project management (80%), Service management (74%), System e Network management (72%), End user monitoring (69%), Project Portfolio management (57%).
Le forti relazioni esistenti tra questi sistemi e processi rendono ovviamente difficile giungere a conclusioni chiare e univoche, ma in generale sembra di poter dire che l’attenzione è più verso lo sviluppo delle applicazioni e la conduzione dei progetti applicativi che non verso il controllo delle attività degli utenti o la gestione manageriale del portafoglio applicativo (quindi più sul fare che non sul controllare e decidere).
Relativamente alla presenza in azienda di procedure automatizzate per alcune delle principali attività relative allo sviluppo applicativo (Gestione dei requisiti, Gestione della configurazione e release del software e Gestione della qualità del software) emerge che gli investimenti maggiori in informatizzazione sono stati fatti sugli aspetti più tecnici della configurazione e del release management (64% dei casi) che non nella gestione degli aspetti più soft, delicati e critici dei requisiti (46%) o della qualità del software (20%).
Fase di testing? Molto trascurata
Da notare una leggera distonia rispetto ai dati relativi all’utilizzo di strumenti di gestione dei requisiti (descritti a pag. 34), dove solo il 33% delle aziende aveva dichiarato di utilizzare strumenti di gestione dei requisiti, informatizzati e non (quindi è strano che ora si dichiari di avere in funzione procedure automatizzate per la gestione dei requisiti stessi).
Si è poi chiesto al campione quali test per il collaudo di una nuova applicazione (o di nuove funzionalità di applicazioni esistenti) prima della messa in produzione vengono effettuati con procedure automatizzate. I messaggi forti sono che un terzo del campione non fa test e un terzo si focalizza su test di performance tecnica end-end. Per gli altri test si dimostra una scarsa attenzione probabilmente dovuta alla mancanza di tempo, ai costi impliciti o alla bassa di cultura di test delle applicazioni nel nostro paese: non è detto che si debba sempre stressare in modo eccessivo la fase di testing, soprattutto quando bisogna essere molto veloci e time-to-market, ma è un’area in cui bisogna fare di più, in modo selettivo, e quindi con l’impiego di criteri decisionali condivisi col management aziendale, oppure con strumenti il più possibile automatizzati di testing. È necessario fare riflessioni diverse per le applicazioni pacchettizzate e parametrizzate rispetto a quelle sviluppate in modo custom: la criticità è probabilmente maggiore per queste ultime, anche se è difficile generalizzare, considerando il grado di personalizzazione anche delle suite applicative pacchettizzate che è stato fatto e si fa in Italia (come si è visto precedentemente).
Figura 15
Parametri sui quali è capitato di riscontrare problemi nelle applicazioni in produzione
Cliccare sull’ immagine per visualizzarla correttamente
Fonte: Indagine Quality & Performance Management, ZeroUno, giugno 2008
La figura 15 evidenzia i parametri sui quali è capitato di riscontrare problemi nelle applicazioni in produzione. La documentazione è da sempre un punto dolente (il 66% lo dichiara come causa di problemi nelle applicazioni in esercizio): è time-consuming, è impegnativa, soprattutto se non basata su strumentazione automatica di supporto alla rilevazione dei requisiti, al design e allo sviluppo/test delle applicazioni. Implicitamente la scarsa documentazione esistente diventa fonte di ritardi/inefficienza o di scarsa efficacia degli interventi sulle applicazioni live, quando si rileva la necessità di azioni di manutenzione correttiva o evolutiva. Le performance sono un elemento da misurare e controllare più attentamente e con maggiore frequenza (il 38% le dichiara come fonte di problemi nelle applicazioni in esercizio), come visto anche prima. La correttezza funzionale delle applicazioni, dichiarata dal 30% dei casi come fonte di problemi nelle applicazioni in esercizio, è probabilmente generata dalla scarsa attenzione alla fase di test, come visto precedentemente, e genera le necessarie azioni di manutenzione correttiva ed evolutiva, che non debitamente supportate dalla documentazione applicativa (vedi sopra), rischia di generare un pericoloso “loop degenerativo” nella qualità delle applicazioni aziendali. Sicurezza, scalabilità e affidabilità delle applicazioni sembrano essere problemi sensibilmente meno presenti e diffusi (o percepiti, se non sono misurati effettivamente!).
Infine un’analisi più approfondita delle precedenti cause di problemi riguardo le applicazioni aziendali, fatta in funzione degli attori (team interno-41%, software house-20%, mix dei due-39%) che sviluppano le applicazioni stesse, porta alle seguenti evidenze: la mancanza della documentazione è lamentata da tutti indistintamente, e ciò è sicuramente più grave quando il problema è generato da parte di operatori professionali che fanno dello sviluppo applicativo il proprio core business (in alcuni può esistere una reale trascuratezza da parte della software house, in altri casi essa non riesce a farsi riconoscere dal cliente le giornate da spendere per realizzare la documentazione necessaria); viceversa la scalabilità e la sicurezza come causa di problemi applicativi viene citata più dai team It interni, che evidentemente “vivono” più da vicino questi aspetti nel day-by-day dell’esercizio e dell’utilizzo effettivo delle applicazioni aziendali; il tema delle performance richiede una sensibilità e un’attenzione particolari (sia nella fase di misurazione sia nella fase di interpretazione/analisi degli indicatori e delle misure) che possono avere più i team IT interni, coinvolti “profondamente” nella gestione reale dell’IT in azienda, più che attori esterni.
Considerazioni finali
Concludiamo questo articolo riassumendo brevemente le principali evidenze dell’indagine.
1. La gestione in house del sistema informativo, sia della componente ordinaria, sia di innovazione, è ancora prevalente.
2. Nonostante il posizionamento dell’it manager sia sempre più vicino a figure di vertice aziendale, i gap di percezione sui risultati del sistema informativo sono ancora significativi.
3. La misurazione delle Performance It, in particolare quelle applicative, è ancora una delle sfide maggiori che le imprese hanno di fronte per allineare il parco applicativo alle esigenze informative sempre più dinamiche; è ancora forte il gap tra ciò che si ritiene importante misurare e ciò che viene realmente misurato.
4. La strumentazione di supporto alla qualità e alle misurazioni delle applicazioni aziendali resta uno dei maggiori problemi, per questioni di sensibilità, di costo e di impegno concettuale.
5. Il processo di Application Management si presenta generalmente poco supportato da strumenti informatizzati, soprattutto nelle fasi di rilevazione dei Business Requirement, di testing e di documentazione.
6. Nei portafogli applicativi i sistemi Erp, di BI e i verticali specifici sono considerati gli investimenti applicativi più strategici e per i quali sarebbe necessario intervenire primariamente nel processo di Application & Performance Management.
7. L’Application Quality management è percepito come maggiormente collegato alla “velocità” di implementazione delle applicazioni, mentre l’Application Performance management alla misurazione dei risultati e degli impatti di business.
Leggi anche Qualità del software, qualità e aumento del business
Il servizio si inserisce nell’iniziativa Osservatorio Quality & Performance management nell’ambito della quale ZeroUno promuove una seconda inchiesta sul tema Qualità del software: la tua azienda è matura?
Partecipa e avrai in esclusiva il report dettagliato dei risultati
