Alcune guideline per i responsabili dei sistemi informativi

Linee guida che possono essere utili nell’approccio di gestione progettuale:

• Dotare l’It di una struttura di Ppm (Project & portfolio management) “trasversale” per permettere di gestire i progetti e le iniziative globalmente e non individualmente. Ciò consente di definire un unico piano di sviluppo e monitorare l’avanzamento complessivo delle iniziative. Ne consegue l’esigenza di condurre dei Sal (stato avanzameto lavori) a livello di programma, gestire le criticità a livello complessivo e così via;

• Adottare una metodologia univoca per tutti i progetti It. Se le iniziative seguono spesso piani specifici e rispondono a obiettivi limitati, in molti casi vengono utilizzate metodologie di analisi, sviluppo, test differenziate. Questo impedisce a chi governa l’It di avere una visione di insieme non tanto nell’andamento dei progetti, quanto sul grado di efficacia delle iniziative una volta realizzate. Un unico set di strumenti, procedure e meccanismi operativi condivisi permette, infatti, di capire più rapidamente dove si manifestano problemi e di intervenire prima di scoprire le magagne in produzione;

• Effettuare un’accurata attività di analisi degli impatti e studio di fattibilità. Molti fallimenti e ritardi nei progetti It dipendono dall’attenzione posta prima delle attività di implementazione nel valutare attentamente quali sistemi, interfacce e funzionalità sono impattate dall’iniziativa. Eguale importanza deve rivestire la fase in cui tutte le aree impattate, sotto la guida del Ppm “trasversale” valutano il modo più efficiente per implementare i requisiti. Tali attività devono essere inserite a piano ed essere documentate e tracciate; in caso contrario, si rischia di perdere molto tempo in fase di sviluppo per stabilire chi aveva capito male cosa, con ricorso a e-mail e altre forme di comunicazione informali;

• Avere sempre un piano B per gestire le criticità di progetto e i ritardi nell’implementazione. È buona norma prevedere le attività che potrebbero presentare delle criticità quanto a complessità di realizzazione (ad esempio alcune interfacce tra sistemi realizzati con tecnologie differenti, oppure attività che implicano la definizione di protocolli di comunicazione con società/enti esterni) e al tipo di impatto che potrebbero avere sul “cammino critico” dell’It, definendo, quindi, un piano di mitigation adeguato;

• Definire chiaramente e comunicare a tutti gli enti coinvolti i benefici attesi dall’iniziativa. Un fronte sul quale l’It è, in genere, carente è rappresentato dalla comunicazione It nei confronti del resto dell’organizzazione. Nel caso di iniziative nate in ambito mercato infatti, i benefici possono essere visti più o meno direttamente a seguito della realizzazione dell’intervento: sulle vendite, sul miglioramento dei processi, sul customer care, sulla fatturazione e altro ancora. Se, invece, l’iniziativa nasce in ambito It, un modo per far capire ai non tecnici i vantaggi che ne deriveranno è sicuramente quello di minimizzare gli impatti “indesiderati” nei confronti degli utenti, cioè quelli che aggravano le attività di questi ultimi, o le moltiplicano. Questo criterio andrebbe seguito anche se può far aumentare, entro certi limiti, lo sforzo di implementazione. Un altro sistema è quello di documentare puntualmente i benefici percepibili che discendono dall’intervento: riduzione dei tempi di esecuzione di alcuni task, maggiore efficacia nelle risposte date ai clienti finali, miglioramento delle prestazioni dei sistemi e così via;

• Condurre degli assessment periodici sulla soddisfazione degli utenti. La tendenza a trascurare l’elemento “soddisfazione” non può essere addebitata solo all’It. Condurre indagini di questi tipo è, infatti, utile per l’intera organizzazione; valutazioni formali dovrebbero essere condotte pertanto dall’organizzazione e non dall’It, sia su singoli sistemi, raccogliendo magari spunti e idee da parte degli utilizzatori, sia sull’It in generale, sulla qualità e sul rispetto dei tempi di delivery.