Fattori critici di ... insuccesso  

[ Abstract da pagg. 16-20 di  “ICT Professional”  (Gennaio/Febbraio 2004): notiziario della Federazione delle Associazioni di Information Management ]

Fatti e misfatti nei progetti IT alcuni dei quali non hanno centrato l'obiettivo che le aziende-utenti si aspettavano. 
Ma non sempre le cause sono di natura tecnologica.

A un recente seminario ho trovato molto interessanti le relazioni di Franco Guazzoni (Partner, Coreconsulting) e di Lorenzo Bellini (Account Manager, Altea) sulle cause dei fallimenti di alcuni progetti IT. Questo articolo trae spunti dai loro interventi.

Il quadro di riferimento
Fino all'inizio degli anni 90 il focus in azienda è stato sulla "qualità totale" e sulla necessità di rivedere continuamente processi, modalità di lavoro, attività: questa scuola di pensiero aveva introdotto i circoli della qualità e portato le aziende verso la "lean production". Questa metodologia, importata negli anni '80 dal Giappone e dagli USA, aveva introdotto una mentalità di miglioramento continuo a piccoli step. Poi, sulla base degli enormi sviluppi della tecnologia, in USA si è affermato il concetto dei "salti quantici": non è più conveniente procedere a piccoli passi se si ha a disposizione una tecnologia che permette di fare salti notevoli e sostanziosi, cioè dei cambiamenti drastici. Era il clima e le premesse che hanno portato ad un'altra moda, quella del Business Process Re-engineering (BPR).

Il BPR coinvolge 3 aree: 
a) la tecnologia, che è un "enabler", cioè è molto più di un semplice supporto, è quello che rende possibile …; 
b) i processi, cioè ripensare il modo di lavorare; 
c) infine le Risorse Umane (RU), cioè gli attori che devono essere coinvolti (cioè motivati, addestrati) perché cambia il modo di lavorare. La motivazione delle RU è di solito la parte più difficile da realizzare, perché il BPR comporta sempre una delle seguenti tre possibilità: cambio del modo di lavorare, cambio di attività, e in qualche caso uscita dall'azienda.

Queste 3 aree del BPR difficilmente coesistono, anche perché le Soc. di consulenza hanno le proprie capacità concentrate prevalentemente in una di queste aree e difficilmente spalmate in tutte e tre. Spesso sono brave nelle tecnologie, ma si avventurano anche nel change management (processi) e nell'area delle RU: alla fine tutto è guidato e condizionato dall'IT. In qualche altro caso partono dai processi e poi dopo vanno a cercare del software a supporto. Altre di stampo socio-tecnico, partono soprattutto dalle risorse umane (ruoli, gioco delle persone, competenze) e poi costruiscono il cambiamento. Questa diatriba, mai ben evidenziata e risolta, è stata messa da parte quando sono apparsi i primi ERP. 

Secondo Guazzoni, forse esasperando un po' la realtà, con gli ERP il ragionamento è diventato: abbiamo un software gestionale completo, che copre tutte le aree dell'azienda; ha alcuni lati negativi ed è costoso, ma non importa; è difficile da implementare, ma non importa; dateci credito vedrete che alla fine vi troverete bene. Ciò ha comportato che il BPR passasse di moda e che tutti i progetti BPR in atto fossero sospesi. Questo approccio è rimasto in auge fino all'anno 2000 quando è stato, se non totalmente superato, alquanto soppiantato dall'eBusiness. Alla fine eBusiness ed ERP si sono integrati. E' bene precisare che lo scenario dell'inizio del terzo millennio, depurato dalle troppe aspettative irrealizzabili, non è poi così negativo e molti progetti validi sono stati realizzati. Certamente, con il senno di poi è possibile rendersi conto che sono stati fatti anche degli errori.

I sintomi che analizzeremo sono due. 

• Il primo è intrinseco al progetto: non è andato come ci si aspettava, i risultati sono stati deludenti. In questo caso, i problemi possono essere 
  - all'interno del progetto stesso, nella sua impostazione (come è stato concepito, disegnato), nell'esecuzione (come è sviluppato, realizzato), nel project management 
  - all'intorno del progetto, nell'ambiente dove si trovano gli stakeholder (clienti, fornitori, dipendenti) che hanno a che fare con il progetto stesso e che hanno certamente qualcosa da dire circa l'usabilità e l'utilità del progetto 
  - nelle aspettative troppo elevate.

• Il secondo sintomo è esterno al progetto e correlato al committente (azienda-utente): più lungo è il progetto più aumenta la probabilità che cambino totalmente le condizioni al contorno (cioè l'Amministratore Delegato, le priorità, il budget, ecc.) e, quindi, l'interesse nel progetto..

Il progetto
Analizziamo di seguito i misfatti del primo sintomo, cioè vediamo come ciascuno dei problemi intrinsechi al progetto abbia le sue cause.

L'impostazione del progetto
I problemi nell'impostazione del progetto hanno le loro radici in tre aree diverse: a) processi, b) persone e ruoli, c) soluzione IT. Il problema è quello di fare convivere queste tre aree e capire quale deve avere la leadership affinché le cose accadano e ci sia la spinta propulsiva.

QLa radice dell'IT si suddivide a sua volta in quattro sezioni: Hardware (HW), Software (SW), Architettura, Interfaccia. Qualche volta non viene scelto l'HW più adatto e, per questioni di budget, ne viene adottato uno sottodimensionato: quando dal progetto pilota, o dalle prime applicazioni, si cerca di andare a regime, con un numero di utenti elevato e con i volumi reali, il sistema si siede. Quindi l'HW, ma anche l'architettura (sistema delle reti, sistema delle sicurezze, ecc.): la loro scelta richiede ragionamenti molto raffinati e contestualizzati rispetto ai veri obiettivi del progetto. Poi, evidentemente, vi è anche un discorso di SW: della sua scelta, delle sue personalizzazioni ed integrazione con i sistemi legacy preesistenti che in parte rimangono in funzione. Problemi spesso banali ma che richiedono molta attenzione, impegno e capacità: spesso sono delle bucce di banana su cui è facile scivolare e finire con il vanificare lo sforzo fatto.

Vi è anche il problema dei processi e di chi li studia. I dipendenti dell'azienda sono indispensabili ma non sempre hanno la spinta innovativa necessaria, è normale che siano portatori di valori del passato: abbiamo sempre fatto così, non vogliamo spostarci. L'errore che potrebbe scaturire da queste posizioni è quello di far fare alle nuove tecnologie (ERP, CRM, ecc.), a caro prezzo, quello che si è sempre fatto in azienda senza cambiare nulla nei processi e nel modo di lavorare. Quindi nella revisione dei processi è necessario coinvolgere le persone dell'azienda-utente, ma occorre immetterci anche molta spinta innovativa. La spinta innovativa è data dai consulenti: purtroppo può capitare che si innamorino facilmente di una soluzione in teoria molto valida ma che non funziona in quel particolare contesto (troppo avanzata, impatto troppo elevato sulle persone, ecc.).

L'errore che molto spesso si fa nei progetti IT è quello di non partire dalla conoscenza dell'azienda-utente. Un consulente esterno deve cercare innanzitutto di capire cosa fa l'azienda, cosa sa fare bene, che capacità e possibilità di crescita ha, che volontà di crescere ha, quali dipendenti (dirigenti, quadri, ecc.) hanno le capacità e la volontà di partecipare in modo "collaborativo" ad un progetto innovativo, quali devono cambiare funzione e/o azienda, quali nuovi "talenti" sono da ricercare sul mercato, ecc. Questo approccio che dovrebbe essere prioritario e propedeutico a tutto il progetto, nella realtà viene spesso gestito in maniera marginale o residuale: siccome ho installato questo ERP, siccome in qualche modo sono riuscito a spiegare come dovrebbero funzionare i processi, allora vediamo di assegnare le attività alle persone, spesso aumentando anche il carico di lavoro. Il problema non è solo ed unicamente di addestramento all'uso dei nuovi tools, ma soprattutto di ruoli professionali e di un nuovo modo di lavorare. Purtroppo, quasi tutti sono particolarmente affezionati al proprio "vecchio" ruolo ed alle proprie abitudini. Qui si sono commessi gli errori maggiori, perché non progettando a priori e non gestendo in modo proattivo il cambiamento si creano i presupposti per le vendette a posteriori che finiscono per compromettere il progetto.

L'esecuzione
Ci sono, poi, i problemi nella fase di esecuzione e nel progetto di cambiamento. Spesso anche aziende importanti hanno comprato le licenze e solo successivamente si sono posti il problema di come ottenere i risultati. Il rischio è quello di fare interventi approssimativi con una squadra composta da risorse (esperti interni e consulenti esterni) non sufficientemente adeguate in termini di numero, know-how, ecc. In altri casi si tende a comprimere troppo i tempi nella speranza di ottenere risultati in tempi brevi e dimostrare così la propria capacità. 

Ci possono essere errori anche nel Project Management: un P-Manager troppo permissivo e flessibile o troppo rigido non va bene. Se è troppo rigido rischia di ingessare il progetto, ma se è troppo flessibile non potrà utilizzare l'energia necessaria per ottenere i risultati che ci si aspetta. Il P-Manager non è solo una persona dotata di buon senso, deve essere anche una persona dotata di skill tecnici e deve saper scegliere ed usare le metodologie adeguate al caso (né troppo complesse, né troppo semplici).

Il contorno e le aspettative
I problemi esaminati finora rappresentano solo circa il 50% dei "fatti e misfatti" relativi ai progetti IT di insuccesso. Esaminiamo ora altri due misfatti del primo sintomo. 

Il controno del progetto
I problemi relativi al contorno del progetto riguardano sensibilizzazione, coinvolgimento, formazione delle RU coinvolte. La comunicazione non è un rimedio che risolve tutti i problemi, però aiuta ad informare preventivamente gli attori (dipendenti, clienti, fornitori), a rimuovere i loro timori e a renderli collaborativi. Purtroppo, capita spesso che costosi investimenti in comunicazione siano effettuati solo alla fine del progetto per annunciare il cambiamento già avvenuto, quando invece sarebbe stato più opportuno spalmare questo investimento anche prima e durante lo svolgimento del progetto.

Un progetto IT non è altro che un progetto di trasformazione e, quindi, è sempre importante esaminare in anticipo il cambiamento indotto in azienda (cosa si va ad incidere, perché è necessario evolvere da uno stadio attuale ad uno futuro, a vantaggio di chi, ecc.) e tenerlo presente nel pianificare il progetto. Inoltre, per il successo di un qualsiasi progetto di cambiamento è fondamentale studiare anche un nuova strategia di incentivazione che tenga conto dei nuovi obiettivi. Se lasciamo inalterato il vecchio piano retributivo, sicuramente gli uomini continueranno ad operare come nel passato. Non dobbiamo mai dimenticare che un progetto IT (ERP, CRM, BI, SCM, ecc.) cambia il modo di lavorare delle persone e come minimo crea disagio e resistenze. 

La nuova organizzazione è sicuramente disegnata in modo opportuno sulla carta, ma non sempre le nuove persone che presidieranno i processi sono individuate in anticipo con nome e cognome, scegliendole opportunamente perché sono le più adatte e non perché le uniche a disposizione. Inoltre, non sempre è previsto in anticipo un opportuno piano individuale di formazione per aiutarli ad affrontare il cambiamento Purtroppo, intorno al progetto ruotano molti interessi diversi che non sempre sono allineati e non sempre perseguono il bene reale dell'azienda-utente.

Le aspettative
I problemi nelle aspettative sono relativi all'ambito del progetto: quanto ampio è, che obiettivo ha e che cosa vuole andare a toccare. Un esempio sono i famosi "big bang" molto rischiosi: tutta l'azienda, tutto va messo sotto sopra, per una certa data tutto deve cambiare. In alcuni casi sono stati il minore dei mali, perché se non si fosse proceduto in questo modo l'azienda-utente sarebbe rimasta ferma ed immobile vista la mentalità esistente. In questi casi sono utili, ma è necessario discutere preventivamente con il Top Management, chiusi in una sala riunione isolata, le linee del progetto e chiarire che ci sarà un cambiamento con lacrime e sangue: alla fine alcune cose andranno bene, ma altre non saranno ancora perfette e richiederanno ulteriore tempo per l'andata a regime. In maniera più esplicita è bene spiegare anticipatamente che questi progetti non sono il toccasana. Infatti, 
- gli ERP non possono far diventare proattivi e propositivi dei dirigenti che sono a stento reattivi; 
- le soluzioni CRM non possono conquistare all'improvviso nuove quote di mercato; 
- un ottimo ERM non può automaticamente aumentare la retention del personale e gestire i talenti.

E' bene ricordare sempre che sono solo degli strumenti mentre il vantaggio competitivo è costituito dalle idee, cioè a fare la differenza sono ancora sempre e solo le persone, cioè il management. Quindi, è bene comprendere che questi progetti sono stati spesso messi alla gogna per delle colpe che avevano solo in minima parte e che erano invece dovute ad eccesso di ambizioni nelle aspettative: obiettivi troppo ampi o vaghi.

Altro misfatto è quello relativo ai KPI sia dell'azienda-utente dopo l'implementazione del progetto sia del progetto (rispetto dei tempi, costi, interfacce, ecc.): non sempre sono definiti ex-ante correttamente o lo sono solo superficialmente, non sempre sono controllati durante lo svolgimento, non sempre vengono stabilite le procedure e costituiti i comitati ad hoc per decidere in merito. Spesso si procede correttamente all'inizio nella fase di kick-off sotto la spinta dell'entusiasmo iniziale, ma poi il controllo viene allentato in corso d'opera e si perde il momentum strada facendo.

Il committente
Il secondo sintomo, menzionato all'inizio, è collegato al committente e non al progetto stesso. Più lunga è la durata del progetto, maggiori sono le probabilità che accadano misfatti che non hanno nulla a che fare con il progetto stesso. Ad esempio viene meno l'interesse, la spinta propulsiva si affievolisce, la priorità cambia perché l'azienda-utente cambia azionista di riferimento e/o management, strategie e tattiche. In questo caso anche un progetto che sta procedendo bene e sta dando i risultati attesi può venire accantonato e rimosso. 

Altro misfatto collegato a questo sintomo si ha quando l'ambito del progetto è troppo ampio e/o i suoi confini sono stati definiti in maniera confusa: meno è definito il progetto, più è simile ad un buco nero capace di attirare inconvenienti originati da altri progetti aziendali.

In conclusione
Secondo Bellini, l'errore dei partner esterni (consulenti, SI, ecc.) è stato spesso quello di aver ridisegnato i processi e le architetture applicative in modo asetticamente "perfetto" non tenendo nella dovuta considerazione l'impatto "reale" che tools e processi avrebbero avuto sul personale dell'azienda-utente. In pratica, si prendeva a modello l'azienda media del settore in cui operava l'azienda-utente e meccanicamente si introducevano le soluzioni-tipo. Peccato che l'azienda-media usciva dall'analisi di poche realtà di tale settore.

Alcune di queste aziende-utenti si sono trovate, di fatto, ad avere dei sistemi "perfetti sulla carta", ma che non tenevano conto della realtà e che sono stati sistematicamente rifiutati dalle persone che avrebbero dovuto utilizzarli e/o diffonderli sia in azienda sia presso i Business Partner (fornitori, canali di vendita, clienti finali). Questi problemi non erano tanto dovuti ai sistemi (ERP, CRM, ecc.) in quanto tali, ma a fattori psicologici (timore di essere sostituiti dalla tecnologia) o al fatto che i tool, se non sono alimentati con i dati necessari, non possono fornire output utili per una corretta gestione dell'azienda.

Il nuovo approccio agli investimenti che seguiranno le aziende, è diverso rispetto al passato: gli investimenti saranno sempre più mirati, i progetti contenuti nei tempi e nell'impatto economico. Tale approccio faciliterà anche l'impatto sulla "cultura aziendale". I settori di investimento più probabile sono quelli legati allo sviluppo e al monitoraggio del business, agli indicatori di performance, al miglioramento della conoscenza del mercato, all'ingegnerizzazione della ricerca e sviluppo. In pratica: integrazione tra piattaforme applicative (EAI), Business Intelligence, Datawarehousing, CRM, Product Lifecycle Management (PLM). 

Inoltre, le aziende chiederanno sempre più soluzioni complete ed onnicomprensive che tengano conto della globalità dei fattori critici che entrano nel progetto: non sarà più sufficiente avere una profonda conoscenza delle soluzioni applicative/tecnologiche, ma sarà indispensabile "costruire" con il cliente le "nuove soluzioni" avendo una significativa competenza del suo business.

Da quanto esposto emerge che il processo di cambiamento e di adozione delle tecnologie IT avanzate non è semplice e va costruito intorno a vari fattori: 
- Approccio non solo tecnologico 
- Comprensione da parte dei partner (vendor, consulenti, SI) delle logiche e delle problematiche di gestione tipiche di ciascuna singola Impresa, 
- Aspetti Culturali e Formativi 
- Coordinamento tra vendor, consulenti di management ed utente 
- Investimento visto dall'impresa come fattore di sviluppo e non come semplice costo 
- Ricerca del partner giusto che possa dare adeguata attenzione alle esigenze dell'utente oltre che qualità e continuità del servizio.

Estrapolando le considerazioni oltre l'area IT, il sistema delle imprese italiane avrà la possibilità di superare la sua crisi (prevalentemente strutturale e non solo congiunturale) e competere con successo solo affrontando la sfida su più fronti: 
1) l'impresa utente dovrà cambiare ed accrescere la cultura aziendale; 
2) l'offerta di innovazione (metodologie, tecnologie, formazione, ecc.) dovrà agire come "vero" business partner per il cambiamento; 
3) tutti gli attori (vendor, consulenti, utenti, ecc.) dovranno collaborare insieme in maniera costruttiva.

Oscar Pallme 

*   www.pallme.com