Alcuni mesi fa, nell’ambito delle attività condotte per l’Osservatorio Quality & Performance Management di ZeroUno, è stata svolta un’indagine tesa ad analizzare il livello con il quale, nelle imprese italiane, viene percepita l’importanza della qualità dello sviluppo applicativo e della misura delle prestazioni delle applicazioni aziendali, andando di conseguenza ad indagare la qualità stessa dei sistemi informativi sui quali si fonda il loro business. Sebbene non fosse stata deliberatamente costruita in modo da avere valore statistico, l’analisi ‘a posteriori’ delle 80 imprese italiane che hanno partecipato all’indagine (per la quale, come per gli altri riferimenti che seguiranno, rimandiamo al servizio Sistemi informativi: Quality & Performance) ha disegnato un campione che si può definire sufficientemente rappresentativo della realtà del nostro Paese, sia dal punto di vista delle dimensioni e dei campi di attività delle imprese rappresentate, sia dal punto di vista della struttura e della organizzazione della funzione Sistemi Informativi. Di conseguenza, riteniamo di poterci avvalere di quanto emerso come base di analisi per esaminare più in profondità alcuni aspetti fondamentali del processo di application delivery, con particolare riguardo al suo allineamento agli obiettivi di business dell’impresa.
Un compito sempre più difficile
Sarà banale, ma cominciamo con il dire che il quadro nel quale si trova a dover operare il Cio e la funzione Sistemi Informativi di una qualsiasi impresa nei riguardi dell’application delivery è quello di una crescente complessità. Nuovi network e nuovi sistemi che devono convivere con (e spesso sopra) applicazioni legacy decennali; servizi web che vanno più o meno integrati con architetture client-server nelle diverse ‘declinazioni’ che ogni singola funzione SI dà ai modelli proposti dalla Soa; nuovi dispositivi che la crescente richiesta di mobilità impone di associare alle applicazioni business; piattaforme di sviluppo applicativo (.Net, J2EE, multi-tier web application) per le quali non è facile trovare risorse di adeguata esperienza. Tutta questa complessità porta, come è intuibile, a una crescita del rischio, per l’It, di non rispondere adeguatamente alla funzione di supporto e propulsione del business che le viene sempre più richiesta. E in una fase di recessione economica come quella cui si sta andando incontro (con un Pil che nel 2009 è previsto, per la prima volta a nostra memoria, di segno negativo), è una cosa che nessun Cio si può permettere.
In questo quadro, già di per sé tremendamente complicato per la funzione It, s’inseriscono ulteriori fattori di complessità, sia di fonte esterna, sia interna all’impresa.
Il primo problema, inutile dirlo, è il costo. Era primario già quattro anni fa, figuriamoci oggi. La tendenza, come viene evidenziata anche dalla nostra indagine, è, correttamente, quella di acquisire un maggior controllo sull’intero processo di delivery delle soluzioni It attraverso il consolidamento e la centralizzazione delle risorse. Con questo intendiamo sia i sistemi e gli strumenti tecnologici sia i fornitori It, che vediamo, anche tramite continue fusioni e acquisizioni, diminuire nel numero e crescere nell’estensione e completezza della propria offerta. Il progresso tecnologico che ha continuamente portato ad abbassare il costo iniziale dell’hardware e, in parte, anche del software (specie se pacchettizzato) ha portato a quello che potremmo definire uno ‘spreco nascosto’ delle risorse It. Questo trend, al quale negli anni delle ‘vacche grasse’ non sono state certamente estranee le scelte commerciali di molti fornitori, con il restringersi dei budget è ovviamente rallentato, fino a mostrare da un paio di anni a questa parte una inversione di tendenza. I vendor più lungimiranti hanno cominciato a proporre soluzioni per ottimizzare le risorse disponibili e oggi l’It tende ad avere un maggior controllo delle tecnologie e delle metodologie presenti in azienda al fine di integrarle in un insieme di risorse da destinare a processi per quanto possibile ripetibili e riconfigurabili in funzione del business.
Figura 1: 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 ingrandirla)
Un impegno comune
Ma per arrivare a produrre applicazioni di qualità, la funzione It ha bisogno di qualcosa di più che ottimi analisti e capaci sviluppatori. Occorre la partecipazione, la collaborazione e l’impegno di tutte le figure professionali che sono interessate alla qualità delle applicazioni business e, in generale, dei processi aziendali. In primo luogo gli utenti (siano essi figure manageriali od operative), la cui esperienza di lavoro è un capitale che va sfruttato; poi quelle figure, anche esterne all’organizzazione, come partner o fornitori, che siano coinvolti nei processi che il software è chiamato a gestire. Secondo Gartner, il 40% dei problemi di un pacchetto software viene evidenziato dagli utenti finali, ed è noto, oltre che ovvio, che sistemare un ‘baco’ quando il software è in produzione costa molto di più (da 5 a 7 volte di più, secondo uno studio Carnegie Mellon) che in fase di sviluppo e testing.
L’indagine di ZeroUno (figura 1) mostra come, in Italia, strutture delegate alla gestione di una relazione coordinata e continuativa tra la funzione It e quelli che, in generale, potremmo chiamare gli ‘stakeholder’ delle applicazioni aziendali siano già diffuse nelle grandi realtà (oltre mille utenti), che nell’84% dei casi prevedono figure di demand (o client, o account) manager. Nelle altre, se comprendiamo anche il 10-20% di chi si rende conto del problema di garantire l’allineamento tra It e business e “ci sta pensando”, siamo sulla buona strada. Resta però circa un terzo dei casi dove la soluzione è estemporanea, lasciata all’iniziativa individuale del Cio e dei responsabili business con cui volta a volta si rapporta.
Questo stato di cose deve cambiare, anche in vista di un ‘attore’ determinante nel processo di sviluppo delle applicazioni business e la cui importanza è drammaticamente cresciuta negli ultimi tre anni: intendiamo il rispetto delle norme e regole cui l’attività aziendale deve sottostare. La compliance a direttive imposte da enti esterni all’impresa (dalla legge sulla privacy a Basilea II, per non parlare delle normative di settore) impone frequenti modifiche al software, con la pressione sulla funzione It che si può immaginare.
Oltre ad avere quindi una struttura, o almeno una figura, di demand management, dedicata alla gestione dei cambiamenti, occorre modificare l’approccio stesso allo sviluppo delle applicazioni business, che deve essere orientato a processi per quanto possibile ripetibili e strutturati. Ciò non significa che una metodologia di change management possa e debba funzionare per tutte le situazioni, ma che i suoi elementi costitutivi, dagli obiettivi di compliance (o, perché no, di business) che ci si prefigge di raggiungere alle strutture e risorse che sono delegate allo scopo, siano identificate e messe a fattor comune tra tutti coloro che sono interessati al processo di cambiamento, dagli analisti di business agli sviluppatori (siano interni o in outsourcing), senza escludere partner, fornitori e utenti finali.
Figura 2: Figure/ruoli coinvolti nel processo di definizione dei requisiti informativi e funzionali e loro grado di coinvolgimento.
(Cliccare sull’ immagine per ingrandirla)
Dalle ‘isole’ all’ecosistema
La nostra indagine mostra come l’analisi dei requisiti che portano alla creazione o alla modifica di un’applicazione sia vista, in Italia, essenzialmente come un processo interno alla funzione It, alla quale sono associati dei ‘key user’ ben identificati (figura 2). L’intervento di uno specialista del business è previsto in meno della metà dei casi, e ancora meno frequente è il ricorso a consulenze esterne, siano esse di tipo tecnico siano inerenti l’attività aziendale. Inoltre, e questo non vale solo per l’Italia ma è una situazione generalizzata, all’interno della stessa funzione It il processo di application delivery avviene per stadi separati: dalla requirement generation alla codifica, quindi al testing funzionale, quindi al performance tuning e così via. Ogni stadio è competenza di un gruppo di specialisti che fa il suo lavoro e lo passa al gruppo successivo, e supponendo che ciascuno faccia bene il suo compito, la somma di lavori fatti bene non potrà portare che a un prodotto di qualità, rispondente alle necessità del business e degli utenti.
Purtroppo però le cose in pratica non vanno esattamente così. Il sistema presenta infatti almeno quattro difetti di base.
In primo luogo, con team focalizzati su compiti specifici c’è il rischio che nel passaggio da un gruppo di lavoro al successivo i requisiti di business identificati all’inizio del progetto si perdano per strada. Tanto più che gli stessi requirement possono anche cambiare in corso d’opera (specie nel caso di progetti di compliance) e non è prevista una figura che ne tenga traccia.
In secondo luogo, con la separazione dei compiti una buona parte della conoscenza ed esperienza delle persone (che se si tratta di persone valide è sempre interdisciplinare) va sprecata. In mancanza di meccanismi definiti la comunicazione e il confronto tra i vari specialisti è lasciata all’iniziativa e buona volontà degli stessi, sulla quale non si può sempre contare.
Terzo, la focalizzazione su un compito specifico porta alla mancanza di condivisione dei dati e dei processi inerenti qualità e risultati del compito svolto. In altre parole: misurazioni, indicatori di performance e altre informazioni che sarebbero utili in tutto il ciclo di sviluppo dell’applicazione o della modifica non sono condivisi, con il risultato di allungare tempi e costi del lavoro. Infine, ed è un classico di ogni processo frazionato, quando qualcosa va storto le responsabilità vengono rimbalzate da un gruppo di lavoro all’altro. Arrivare alla radice del problema diventa un compito lungo e costoso e non è detto che si riesca sempre a risolverlo.
Per superare questi problemi occorre un diverso approccio all’application delivery, che porti la gente dell’It e del business a lavorare secondo un’ottica top-down. In altri termini, il processo di sviluppo o di modifica di un’applicazione va gestito e controllato end-to-end in una prospettiva costantemente guidata dai valori, dagli obiettivi e dai processi di business. La realizzazione pratica di questo concetto si poggia sull’adozione e diffusione delle metodologie (Itil e Cobit) e degli strumenti tecnologici che i fornitori di soluzioni di testing e di performance management del software rendono disponibili in modo da poter tenere sotto controllo l’intero processo di sviluppo e modifica delle applicazioni nel suo stesso corso, senza quindi dover intervenire a cose fatte. L’adozione di questi stessi metodi e strumenti, la cui utilità ai fini del consolidamento e della centralizzazione delle risorse dei team di sviluppo risulta dalla nostra indagine già acquisita (ancorché non sempre attuata) nella maggioranza delle imprese, permette di fondere il patrimonio di conoscenze sparso ‘ad isole’ nell’impresa in un ecosistema di competenze ed attività interdipendenti dal valore molto superiore alla somma delle sue parti.
Per approfondire queste tematiche, oltre all’articolo Sistemi informativi: Quality & Performance
consigliamo anche la lettura del servizio Qualità del software, qualità e aumento del business
