Considerazioni sulla Governance dell'Area IT

Questa è la bozza di uno studiodi prossima pubblicazione

Versione del 15 Maggio 2004

A cosa serve il Direttore dei Sistemi Informativi?

Serve il Direttore dei Sistemi Informativi ?

Avendo ricoperto questo ruolo, la domanda mi interessa; la risposta che mi do', provocatoriamente, è no.

Affrontiamo il problema della Governance delle tecnologie informatiche in azienda, ed in particolare alcune riflessioni sui modelli organizzativi che possono consentire ad un'azienda di gestirla con una certa agilità.

La figura tradizionale del manager dell'IS è stata distrutta dalla caduta delle barriere che separavano la sfera “tecnica” da quella del business. Sono in carriera da molti anni, e, da buon “vecchietto” del mestiere, tendo a rispolverare i “caratteri” più pittoreschi che ho conosciuto all'inizio della mia carriera. Per il manager di una volta, l'informatica era il computer, ed il computer era quella cosa dove infilavo le schede, premevo un bottone, ed uscivano le fatture (affermazione spesso condita da aggettivi ed interiezioni proprie della vibrante lingua del volgo).

La diffusione del PC ha aperto la prima seria breccia: i manager IT più avveduti hanno semplicemente ignorato il fenomeno, col felice risultato di avere l'azienda piena di PC su cui giravano giochi, barzellette ed amenità varie, report Excel che “graficizzavano” i dati aziendali in un'allegra anarchia per cui la quadratura con i dati residenti sull'Host era un'orpello desueto. Diavolo, se l'informatica è personale, perchè non lo dovrebbero essere anche i report?

La breccia di allora è oggi una frana generalizzata: tutti capiscono di tecnologia, spesso più dei “tecnici”, le frontiere fra software, applicazioni gestite in service, telecomunicazioni, mobile computing, spostano in continuazione la frontiera, e la rendono indefinibile. Torno sempre agli aneddoti, ma mi ricordo sempre un'utente che mi chiedeva una modifica su una maschera 3270 e, cercando di darmi un consiglio “tecnico”, senza farlo notare troppo, mi diceva: “E' facile vede, basta spostare un po' il margine destro e si crea lo spazio per il nuovo campo. Probabilmente è lo stesso comando che si da per allargare il margine su Word...”.

Torniamo però ad argomenti più seri, e cerchiamo di dare un primo elenco dei compiti che devono competere, secondo me, ad una generica “area informatico/tecnologica” in azienda:

In questi termini sono stato estremamente generico, volutamente, per sviluppare il discorso in modo quanto più possibile top-down.

Un'altra chiave di lettura è poi quella dell'innovazione. Leggendo i compiti di prima secondo quest'altra dimensione, troviamo:

Un'ultima chiave di lettura è infine quella relazionale, secondo cui l'area IT deve:

Quest'ultima dimensione l'ho trovata spesso, recentemente, fra gli skill desiderabili per un manager dell'IT, ma raramente l'ho vista declinata nella mission della Direzione Informatica, quasi che la capacità relazionale debba essere una caratteristica che il manager deve avere per supplire alle difficoltà ambientali, e non invece essere presente organicamente nelle sue attività.

Un'altro aspetto che è venuto meno negli ultimi anni è l'opacità dell'azione dell'IT management. La (vera o presunta) complessità dei sistemi informatici ha sempre permesso all'IT di non fornire troppi chiarimenti su cosa faceva, e soprattutto sul come. Ora non si può più, ed il management dell'IT deve addirittura spiegare quanto l'azienda guadagnerà grazie al nuovo server acquistato, oppure perchè un certo programma è stato scritto in Java e non in Visual Basic.

Abbiamo visto affacciarsi, nelle liste precedenti, diverse entità o categorie con cui l'IT si deve confrontare: questo è forse il tratto determinante dell'IT moderna, ovvero dover interporsi fra pressioni contrastanti, ed offrire un livello molto alto di trasparenza sul proprio operato. L'altro tratto determinante (a mio avviso) è poi l'interdisciplinarietà delle risorse nel reparto IT; se infatti il numero delle tecnologie tende a proliferare, e quindi a richiedere figure sempre più specialistiche, è anche vero che “la Soluzione”, quella calibrata, con la esse maiuscola, richiede qualcuno con una visuale sufficientemente ampia da permettergli di considerare tutti i fattori coinvolti. Interdisciplinarietà non significa conoscere “in linea di massima” tutto, ma conoscerlo abbastanza bene: è quindi una dote che si conquista studiando, molto e continuamente, senza scorciatoie.

Vediamo ora come mettere insieme, in un primo quadro abbozzato, le idee finora esposte. Chi va avanti nella lettura, si accorgerà che andremo a progettare l'organizzazione IT (ed anche qualcosa di più) dell'Azienda, questo perchè sono convinto che le moderne sfide richiedano un approccio “partendo da zero”, senza tentare di rimescolare in qualche modo l'organizzazione attuale, magari dando qualche mansione con i nomi in inglese (P.S.: io uso i nomi in inglese, quando mi vengono più immediatamente alla mente).

Innanzi tutto occorre una struttura per la Gestione dei livelli di servizio. Si tratta di una struttura, prevalentemente sistemistica, che deve conoscere tutti i servizi che l'IT eroga o riceve dall'esterno, abbia gli strumenti per misurarli, ed interagisca direttamente con il fornitore del servizio per assicurare il rispetto dei livelli standard. Infine deve fornire un resoconto sui livelli di servizio riscontrati, sul grado di utilizzo dei servizi, e sull'adeguatezza degli strumenti di misura a disposizione.

Soffermiamoci su alcuni aspetti. Fondamentale è la capacità di misurare. Per misurare un servizio si devono preliminarmente definire le sue caratteristiche, quindi dotarsi di strumenti per misurare il servizio effettivamente prestato.

Facciamo un esempio banale: acquisto da un fornitore di TLC dieci linee telefoniche, e le attacco al mio centralino. Questo mi lascia supporre che la mia azienda sia in grado di ricevere o fare dieci telefonate contemporaneamente. E' vero? Qualcuno è in grado di dirvi quante telefonate state facendo in questo istante? Se vi accorgete che il numero massimo di telefonate contemporanee è stato di 8 nell'ultimo anno, nel momento in cui una squadra famosa ha perso la finale di Champions League, probabilmente state regalando dei soldi al vostro fornitore di TLC ed avete dei dipendenti molto appassionati di calcio; se il numero delle linee impegnate contemporanemente oscilla continuamente fra sei e dieci, probabilmente i vostri Clienti non riescono a telefonarvi e “perdete business” (questa scritta immaginatela in lettere gotiche grondanti sangue – un imprenditore di mia conoscenza, con lungo pelo sullo stomaco – avrebbe detto “quei mona potria riciamàr!”).

Torniamo al serio: si deve poter misurare il servizio, ma allora – prima di firmare un contratto o di accendere un server – devo definire qual'è lo standard che voglio ottenere, quindi devo progettare il mio servizio, anche se è banale. Gli standard poi non sono validi in assoluto (ovvero non chiedo al Mago Sigismondo di dirmi quante linee telefoniche mi servono), ma legati ad un preciso contesto.

Potrei quindi dire: ho 30 dipendenti, 10 dei quali sono addetti alle vendite. I miei Clienti sono 300, i quali fanno in media due ordini al mese, ed ogni ordine richiede 3 telefonate, ecc. ecc. per stabilire che potrei smaltire picchi di 60 telefonate l'ora e quindi avere bisogno delle fatidiche 10 linee. Stabilito questo, il mio servizio IT deve informare il management dicendo che (“I venditori sono passati da 10 a 12, e nell'anno raggiungeranno i 15, per cui sarà necessario portare il numero di linee da 10 a 13 entro la fine dell'anno”).

Non solo, quando definisco un contratto con il fornitore non mi basta chiedere le 10 linee, ma devo anche formalizzare che “tolleranza” accetto su questo numero ed entro quanto tempo il fornitore si impegna a ripristinarmi il servizio in caso di guasto. Questo tempo non va definito con il nostro Mago Sigismondo, ma valutato in funzione delle esigenze reali dell'azienda: allora devo stimare il “costo del disservizio” e poi, nell'esercizio quotidiano, misurare il numero di disservizi rilevati ed i costi reali (o comunque i danni) che l'Azienda ha subito in conseguenza di tali eventi. Vi troverete tra l'altro, qualcosa di estremamente utile anche per quella specie di incubo (solo per i cattivelli...) che si chiama Basilea II.

Poiché, nella maggioranza dei casi, il ciclo operativo dei sistemi e dei servizi è molto più ampio del normale orario lavorativo, ci si deve porre anche il problema del presidio a copertura di tutto il ciclo operativo (sia esso 24 x 7 o inferiore).

Abbiamo detto che questa struttura interviene quando i livelli di servizio misurati vanno fuori standard. Questo evento si chiama “incidente” o “guasto”, e le procedure per gestirlo si chiamano Incident Management. Entriamo ora in'un'area importantissima, in quanto vi confluiscono sia gli incidenti per disservizio che gli incidenti per dolo (dagli hacker ai dipendenti infedeli). L'Incidente Management va al di la' dei contenuti di questo documento, ma per quanto ci interessa l'Azienda deve prendere una decisione: devo dotarmi di una struttura di Incident Management o no? Se la risposta è no, ci si mette (consapevolmente) l'anima in pace, ci si affida alle misure di prevenzione, e si gestiscono gli inconvenienti in modo semplice (prendo un virus? riformatto il server; il telefono non funziona? tampino il fornitore).

Se la risposta è si, si progetterà un team di Incident Management, che risulterà abbastanza trasversale sia alle varie competenze IT che ad altri settori aziendali (ad esempio l'Internal Auditing, il Legale, ecc.), ma deve avere una direzione ben distinta da quella IT, o almeno dai responsabili intermedi dell'IT.

Parlando di misure, non dimentichiamo che le segnalazioni più tempestive degli inconvenienti arrivano dagli utenti, e dobbiamo quindi fornire un canale di contatto diretto ed efficace per le loro segnalazioni. Entriamo quindi nel tema dell'Help Desk e delle procedure a supporto. Anche qui le scelte variano molto in funzione della tipologia aziendale e della dimensione, ma sono sostanzialmente orientato ad un Help Desk strutturato in due canali:

Alla prima area ci si deve rivolgere per le problematiche infrastrutturali (telefoni, linee dati, fotocopiatrici e stampanti, PC) e per i problemi legati alla postazione di lavoro (virus, Office, ecc.).

Alla seconda ci si rivolge per problemi inerenti le applicazioni “aziendali” (ho registrato una fattura in contabilità, non la vedo sull'IVA, non riesco a generare un messaggio di rifiuto per un RID arrivato da RNI, ecc.).

Non ritengo utile concentrare su un unico canale queste due problematiche: il supporto applicativo richiede infatti competenze più specialistiche ed ha requisiti (anche temporali) diversi, per cui l'Help Desk unico finirebbe solo per rimandare i problemi a qualcun'altro, con l'effetto di appesantire il processo senza dare valore.

E' importante invece affiancare un canale telematico a quello telefonico tradizionale. Disporre di un'applicazione (preferibilmente Web based) per caricare segnalazioni e monitorarne l'esito è raramente percepito come utile dagli utenti, ma consente di avere una traccia di come si risponde alle richieste, prevenire i solleciti, è insomma un'efficace base per “misurare” il livello di servizio dell'Help Desk.

Abbiamo parlato di applicazioni, e quindi introdurrò la struttura dedicata all'Application Management. I compiti di questa struttura sono molteplici, ed è difficile definirne esattamente i confini. Gestire le applicazioni significa infatti acquisirle o svilupparle (o integrarle nella maggior parte dei casi concreti), in stretta cooperazione con le strutture aziendali. I punti più importanti sono: