CAPITOLO 6
La valutazione dei fattori di rischio nel progetto di
implementazione di Oracle alla Power-One Italy S.p.A.
6.1 Introduzione
Nel paragrafo 4.4 abbiamo visto una proposta di classificazione dei rischi connessi ai progetti di implementazione dei sistemi ERP, classificando le categorie di fallimento, elencando dieci effetti principali dei rischi ed esplorando 19 fattori di rischio da tenere in considerazione.
Quello che ci proponiamo di fare in questo capitolo è di riprendere lo schema proposto dagli autori di questa classificazione cercando di valutare quali fattori di rischio siano stati preponderanti nel progetto oggetto di questo lavoro, con l’obiettivo di individuare una metodologia che sia uno strumento di supporto ai progetti di implementazione. Nel caso della Power-One ovviamente possiamo solo fare un’analisi consuntiva, partendo dal risultato del progetto (lo slittamento del Go Live al 28 gennaio 2008) e cercando di valutare quali fattori di rischio hanno avuto un impatto primario su tale esito.
6.2 Il progetto di implementazione di Oracle alla Power-One Italy S.p.A.: valutazione dei fattori di rischio
Riprendendo l’articolo citato dobbiamo per prima cosa vedere come classificare l’esito del progetto. Il problema nasce dal fatto che questo lavoro viene scritto mentre il progetto non è ancora giunto a termine, per cui è difficile dare una valutazione oggettiva completa dell’esito.
Sicuramente, visto che il Go Live è slittato di 90 giorni, si può parlare di Fallimento di
processo, categoria che comprende i casi in cui un progetto di implementazione termina
fuori tempo previsto o fuori budget; da questo risaliamo all’effetto principale dei rischi, che è stato il mancato rispetto della timeline di progetto pianificata.
Come prima osservazione possiamo sicuramente dire che si è scelto di rimandare il Go Live, e quindi di andare incontro ad un Fallimento di processo, piuttosto che
implementare un sistema ERP che rischiava di non supportare il business e di avere un impatto prevalentemente negativo sui processi dello stabilimento italiano.
Come secondo punto si è tentato di risalire a quali fattori di rischio tra i 19 proposti nella metodologia esaminata avessero avuto un impatto negativo sul progetto, cercando anche di valutarne l’importanza con una scala di valutazione.
Oltre all’esperienza diretta dello scrivente come membro del team di progetto per ampliare l’analisi si è fatto ricorso anche alle opinioni di altri membri del team con un’esperienza precedente in materia di gestione di progetti di implementazione, mediante interviste individuali in cui il modello teorico è stato sottoposto al soggetto e sono state registrate le opinioni sui singoli fattori di rischio; dalle interviste sono stati esclusi i consulenti esterni in quanto il loro ruolo non si presta ad esprimere un giudizio obiettivo sulla gestione del progetto.
L’obiettivo principale dell’analisi svolta era quello di individuare degli indicatori che permettessero di esprimere in modo preciso l’impatto di ciascun fattore di rischio sull’esito finale del progetto. Tale obiettivo è stato discusso con il responsabile IT che ha evidenziato come tali fattori fossero così intrinsecamente legati l’uno con l’altro da rendere praticamente impossibile individuare il singolo contributo di ciascun fattore. Abbiamo perciò optato per un diverso approccio: per ogni fattore di rischio abbiamo valutato se era applicabile o meno al progetto in questione ( in caso di non applicabilità abbiamo assegnato il valore NA = non applicabile). Il secondo passo è stato di analizzare se il fattore poteva essere pienamente valutato e classificato dato che il progetto non è ancora terminato e non si è giunti al Go Live: per alcuni fattori non è stato possibile fornire una valutazione (si pensi al fattore legato alla manutenibilità), mentre per gli altri abbiamo assegnato al fattore un valore di incidenza (0 = nessuna incidenza, ● = bassa incidenza, ●● = incidenza media, ●●● = alta incidenza).
1. Processo di scelta dell’ERP inadeguato (NA). Visto che la scelta di quale ERP
implementare è stata “obbligata” questo fattore di rischio non è applicabile al progetto.
2. Basse abilità del team di progetto (0). Abbiamo visto che il team di
implementazione è misto, formato in parte da consulenti esterni ed in parte da consulenti e specialisti Power-One; sul ruolo dei consulenti torneremo in seguito. Da un punto di vista delle “skills” dei membri del team non ci sembra di poter muovere alcuna obiezione, oltre alle indiscusse capacità tecniche dobbiamo rilevare che molti
di essi avevano avuto anche esperienza diretta con le altre implementazioni Oracle fatte nel gruppo Power-One. Riformulando però questo punto possiamo dire invece che il Dimensionamento del team di progetto ha avuto un incidenza media (●●). Si deve infatti tenere conto che vi sono dei fattori che hanno reso particolarmente complesso questo progetto di implementazione, quali ad esempio:
o Le dimensioni dello stabilimento (500 dipendenti); o Le peculiarità dei processi di business;
o La decisione di introdurre la logica FIFO;
o I problemi di comunicazione tra il team, nel quale erano presenti un misto di nazionalità (statunitense, indiana, italiana, cinese, slovacca);
o La distribuzione geografica dei membri del team, sparsi tra Stati Uniti, Italia, India e Cina. Anche volendo fare una riunione telefonica tra tutti i membri era praticamente impossibile date le differenze di fuso orario (16 ore tra Cina e Stati Uniti!);
Per affrontare un progetto così complesso il team ha potuto contare su tre soli analisti, di cui due esterni ed uno interno; inoltre per problemi di visti sui passaporti vi è stato anche un avvicendamento tra analisti esterni, che ha comportato un ulteriore aggravamento della situazione. Purtroppo questa situazione è stata dettata da una riduzione del budget del progetto decisa a Gennaio 2007, per cui non è stato possibile dimensionare il team sulle reali esigenze del progetto.
3. Basso coinvolgimento del top management (0). Per questo fattore dobbiamo
distinguere tra il top management del gruppo e quello dello stabilimento italiano. Per quanto riguarda il top management Power-One, rappresentato dallo Steering Committee, si può dire che il supporto al team è stato adeguato come supporto fornito al responsabile di progetto, quello che forse è mancato a causa della lontananza fisica è stato il far sentire la presenza e l’appoggio ai restanti membri del team, soprattutto agli utenti chiave. Per quanto riguarda il top management italiano si deve considerare che nelle fasi iniziali del progetto è stato relegato ad un ruolo secondario, di supporto al team, mentre il coinvolgimento principale è avvenuto con l’emergere delle problematiche più rilevanti. È stato infatti su intervento del top management italiano, preoccupato per le possibili ripercussioni negative derivanti da un sistema che non supportava pienamente il business aziendale, che lo Steering Committee ha accordato un rinvio del Go Live al fine di risolvere i principali problemi incontrati durante il progetto.
4. Sistema di comunicazione inefficiente (●). Per questo fattore si è registrato una mancanza di comunicazione che ha portato ad un basso coordinamento degli sforzi fatti dai membri del team. I membri del team sono divisi per area funzionale di competenza, e questo vale sia per gli analisti che per gli utenti chiave; in alcuni casi è sembrato che le singole aree si muovessero in modo indipendente dalle altre, senza cercare di coordinare le azioni. Vediamo di fare un esempio: per valutare la validità del supporto fornito dal sistema ai processi vi è il bisogno nella fase di testing di provare tutte le casistiche possibili, in modo da evitare brutte sorprese dopo il Go Live. Questo è sicuramente un obiettivo difficile da raggiungere, ma diventa quasi impossibile se non vi è comunicazione tra i membri del team: ogni casistica infatti richiede l’intervento di più di un’area funzionale affinché lo scenario possa essere testato. Se ad esempio vogliamo vedere cosa succede nel caso in cui un cliente richiede una spedizione parziale dobbiamo coinvolgere il Customer Service per inserire l’ordine, il magazzino spedizioni per fare la spedizione parziale ed il Finance per preparare la fattura e controllarne la correttezza. Questo è un esempio molto semplificato, ma rende bene l’idea di come la comunicazione sia fondamentale; in alcuni casi, come quello dei Test Script, è sembrato che ogni area funzionale procedesse nella propria direzione in modo indipendente dagli altri. Riassumendo quindi possiamo citare tra gli aspetti critici:
o Mancanza di coordinamento degli sforzi tra i singoli moduli; o Gestione dei moduli “a paratie stagne”;
o Fase di testing gestita in modo slegato per ciascun area funzionale.
5. Basso coinvolgimento degli utenti chiave (0). Gli utenti chiave ricoprono un ruolo
fondamentale, senza il loro apporto il progetto difficilmente potrebbe essere portato a compimento in modo positivo. Questo fattore aveva sulla carta tutte le caratteristiche per essere potenzialmente negativo: basti pensare che il progetto ha preso il via meno di 6 mesi dopo l’acquisizione dell’azienda da parte del gruppo Power-One, e che erano in atto dei cambiamenti notevoli anche a livello organizzativo (vedi chiusura dello stabilimento di Chatsworth). Gli utenti chiave hanno mostrato inizialmente un certo scetticismo ed una preoccupazione legati soprattutto al timore delle possibili conseguenze negative del progetto, ma hanno saputo trasformare questa apprensione utilizzando le proprie energie in modo costruttivo, facendosi pienamente carico della responsabilità del loro ruolo. Anche quegli utenti che avevano un’opinione negativa del nuovo sistema e che avevano un atteggiamento
critico verso il progetto non hanno lesinato il proprio impegno ed hanno profuso le proprie energie cercando di risolvere i problemi emersi.
6. Addestramento inadeguato (●). Per valutare questo fattore dobbiamo distinguere tra il numero di ore dedicate all’addestramento e la metodologia. Se da un punto di vista qualitativo non possono essere mosse obiezioni, forse qualche miglioramento è possibile da un punto di vista metodologico. Durante la prima fase di addestramento ad esempio sono state impiegate le Desktop Procedure, che ricordiamo essere delle istruzioni operativo sull’utilizzo delle funzioni di Oracle, create sui processi utilizzati negli altri stabilimenti Power-One: anche se queste istruzioni sono servite per rompere il ghiaccio, già dopo la sessione del CRP1 erano divenute obsolete, in quanto non corrispondenti alle soluzioni da implementare nello stabilimento del Valdarno. Analogamente l’addestramento iniziale svolto da utenti chiave di altri stabilimenti Power-One è servito per dare un’idea della metodologia di lavoro con Oracle ma, viste le diverse soluzioni utilizzate, non è servito a preparare gli utenti italiani a svolgere il proprio lavoro con il nuovo sistema. Riassumiamo quindi i punti critici relativi a questo fattore:
o Impiego di manuali scritti per gli altri stabilimenti del gruppo, utili nella fase iniziale ma inutili nelle fasi avanzate del progetto;
o Analogo discorso vale per il supporto da parte degli utenti chiave di altri stabilimenti Power-One (ad esempio nessun altro stabilimento, ad eccezione di quello dominicano, impiega la logica FIFO).
7. Architettura complessa ed alto numero di moduli implementati (●●●). Abbiamo detto che con il crescere del numero dei moduli implementati cresce anche la complessità del progetto. Nel caso dell’implementazione alla Power-One Italy S.p.A. la complessità del progetto è stata massima: si parla di una sostituzione a taglio netto del sistema Legacy con Oracle, quindi sono stati implementati praticamente tutti i moduli (Manufacturing, Finance, Distribution, HR, ecc.); la complessità è stata notevolmente aumentata inoltre dalla decisione di implementare la gestione FIFO del materiale. Riassumendo quindi gli aspetti più critici:
o Sostituzione a taglio netto del sistema Legacy;
o Implementazione contemporanea di tutti i moduli di Oracle; o Decisione di implementare la logica FIFO.
8. BPR inadeguato (●●). Quando abbiamo visto la metodologia utilizzata nel progetto abbiamo evidenziato come la parte di analisi dei requisiti sia stata svolta in modo
forse un po’ sbrigativo e con l’utilizzo di strumenti non adeguati, quali erano i questionari sottoposti agli utenti chiave. Un’analisi più completa svolta con strumenti di mappatura dei processi adeguati avrebbe permesso sin da subito di evidenziare le peculiarità dei processi dello stabilimento italiano, mostrando i GAP esistenti tra i processi AS IS e quelli TO BE come supportati da Oracle. La mappatura completa dei processi è stata invece intrapresa con iniziativa autonoma dal responsabile IT dell’impianto del Valdarno in una fase avanzata del progetto (Settembre 2007), con il fine di mostrare al top management la portata della riorganizzazione dei processi che il nuovo sistema avrebbe comportato. Riportiamo quindi i punti salienti legati a questo fattore:
o Mappatura dei processi AS IS svolta in modo sbrigativo;
o Metodologia di analisi inadeguata (i questionari sottoposti agli utenti chiave); o Mancato impiego di tecniche più complete di mappatura dei processi.
9. Cattiva gestione del progetto (●●). Abbiamo detto che questo fattore è legato ad una chiara visione del business che porti a stabilire obiettivi ben definiti che guidino l’intero progetto; nel caso oggetto di questo lavoro l’obiettivo dell’implementazione di Oracle è stato quello di portare i nuovi impianti acquistati dentro il gruppo Power-One, utilizzando il progetto per operare una standardizzazione dei processi in modo da uniformarli e renderli simili in tutti gli stabilimenti del gruppo. Il top management ha bisogno di uno strumento efficace che permetta di gestire un gruppo aziendale complesso quale è il gruppo Power-One guidandolo nella direzione stabilita dalla strategia aziendale, un po’ come il cervello che deve coordinare e guidare le singole parti del nostro corpo. Che l’obiettivo principe sia stata la standardizzazione si può evidenziare ad esempio dalla tecnica utilizzata per la gestione delle customizzazioni: abbiamo visto che la decisione di implementare qualsiasi personalizzazione che non fosse banale prevedeva l’intervento dello Steering Committee, ed anche in questo caso si poteva comunque ottenere un rifiuto a meno che la personalizzazione fosse strettamente necessaria. La critica che può essere mossa a questo approccio è che nel caso dell’impianto del Valdarno non si poteva perseguire in modo rigido l’obiettivo della standardizzazione senza danneggiare contemporaneamente i processi e quindi l’intero business aziendale. Abbiamo ad esempio visto come nel caso del processo di ingresso del materiale il processo TO BE fosse ampiamente inefficiente rispetto a quello AS IS comportando una triplicazione delle operazioni necessarie a svolgere la stessa operazione: in questo caso standardizzare il processo significa dover
aumentare il personale preposto e quindi avere un impatto negativo sui costi della manodopera. Nella definizione degli obiettivi di questo progetto si doveva forse tener conto sia della elevata complessità dei processi dello stabilimento italiano, sia delle caratteristiche del business in cui la Power-One Italy S.p.A. opera (prodotti custom invece dei prodotti standard realizzati dagli altri stabilimenti del gruppo), sia di altri fattori (ad esempio il costo della manodopera che rende impensabile la soluzione dell’aumento del personale preposto a certe operazioni). Riassumendo possiamo citare tra i punti critici:
o Perseguimento troppo rigido dell’obiettivo di standardizzazione dei processi; o Rischio di peggioramento nel passaggio dei processi AS IS a quelli TO BE; o L’aumento del numero di operazioni da eseguire comporta un aumento del
fabbisogno di manodopera insostenibile per lo stabilimento del Valdarno date le sue caratteristiche peculiari;
10.Tecniche di gestione del progetto inefficienti (●●). La tecnica di gestione utilizzata è stata ampiamente discussa nel Capitolo 5, dove abbiamo dato un ampio resoconto delle fasi del progetto di implementazione previste dalla metodologia. Per quanto riguarda la valutazione della metodologia nel suo complesso non si possono muovere delle critiche particolari, se non quanto già detto in merito al punto 8 sulla fase di AS IS Analysis. Quello che possiamo evidenziare è forse l’eccessiva rilevanza della metodologia che è diventata da uno strumento per il raggiungimento di un obiettivo (l’implementazione di Oracle) ad obiettivo essa stessa: è sembrato che il fine dell’intero progetto fosse di completare nei tempi e nei modi pianificati i passi previsti dalla metodologia, piuttosto che di implementare un nuovo sistema gestionale a supporto dei processi di business. Una causa probabile di questo approccio va anche ricercato nel ruolo svolto dai consulenti (si veda il punto 13), per i quali chiaramente l’obiettivo è quello di concludere il progetto nei tempi previsti: per un’azienda di consulenza ha un’importanza minore che il sistema necessiti di aggiustamenti post Go Live, anzi, poiché il prezzo che essa fa pagare per tali consulenze è sicuramente maggiore tali problemi rappresentano una fonte di guadagno. Sarebbe stato più opportuno puntare su di una maggiore sinergia dei membri del team, pianificare la tempistica in modo adeguato (ad esempio CRP2 e CRP3 erano troppo ravvicinati, tanto che è sembrato di eseguire un’unica ininterrotta sessione di test di 1 mese), ed utilizzare adeguati indicatori di avanzamento del progetto. I punti critici possono quindi essere così riassunti:
o La GAP Analysis è stata svolta in modo un po’ frettoloso e con strumenti inadeguati;
o La metodologia ha assunto rilevanza eccessiva, diventando essa stessa un obiettivo e non uno strumento per raggiungere un obiettivo;
o Tempistica del progetto passibile di miglioramenti (ad esempio CRP2 e CRP3 troppo ravvicinati).
11.Inadeguata gestione del cambiamento (0). Come abbiamo detto per il punto 5 questo
progetto, data la peculiarità della situazione in cui aveva preso il via, era particolarmente soggetto ai rischi legati alla gestione del cambiamento. Da questo punto di vista sono stati compiuti sforzi continui per aiutare gli utenti, principalmente i Super Users che hanno operato in tutte le fasi del progetto, a superare le difficoltà anche psicologiche legate all’adozione del nuovo sistema. Sia il top management sia i consulenti hanno continuamente rassicurato gli utenti fugando i loro dubbi, mettendo soprattutto in luce i potenziali benefici derivanti dall’utilizzo di Oracle e portando a prova di ciò le esperienze degli utenti degli altri stabilimenti Power-One.
12.Inadeguata gestione del sistema Legacy (NA). Visto che il progetto comporterà la
sostituzione a taglio netto del sistema Legacy questo fattore non è ritenuto applicabile.
13.Servizi di consulenza inefficienti (0). Per quanto riguarda le capacità dei consulenti
impiegati in questo progetto non possono essere mosse critiche di rilievo: le persone impiegate avevano le skills necessarie e, in molti casi, l’esperienza derivante da altre analoghe implementazioni. Quello che poteva essere meglio definito è il Ruolo dei
consulenti (●): sarebbe stato forse più adeguato affiancare al consulente che ha
svolto il ruolo di responsabile funzionale IT (il Solution Manager & Coordinator – vedi figura 25 di pagina 67) un responsabile Power-One che fungesse da coordinatore del progetto, verificando il lavoro svolto dal team e operando al fine di garantire gli obiettivi prefissati. Riassumendo:
o Necessità di definire in modo più approfondito i compiti e le responsabilità di ciascun membro del team;
o Ridimensionamento dell’importanza dei consulenti;
o Individuazione di una figura di coordinatore generale del progetto da affidare ad un dipendente Power-One.
14.Scarsa leadership (0). Anche in questo caso vogliamo procedere ad una
riformulazione del fattore di rischio, perché se da un punto di vista del ruolo svolto dal top management e dal responsabile di progetto non vi sono appunti da fare si poteva però stabilire un responsabile di progetto per lo stabilimento italiano: come riportato nel punto precedente sarebbe stato utile avere una figura di coordinatore di progetto anche per l’impianto del Valdarno.
15.Caratteristiche del sistema IT inadeguate (NYV). Abbiamo detto che le
caratteristiche tecniche e funzionali del software (funzionalità, user – friendliness, portabilità, scalabilità, modularità) devono essere analizzate prima dell’implementazione, e valutate post implementazione rispetto alle esigenze di business: nel caso di questo progetto riteniamo questo punto non ancora valutabile. 16.Manutenibilità del sistema IT inadeguata (NYV). Questo fattore non è ancora
valutabile per due motivi: il primo che Oracle non è ancora attivo nello stabilimento italiano e non è possibile quindi valutarne i costi di manutenzione, il secondo è che il sistema è comunque attualmente utilizzato con successo nei restanti stabilimenti del gruppo e non si sono registrati problemi particolari nella manutenibilità.
17.Stabilità e performance del fornitore IT insufficienti (NYV). Per quanto riguarda
questo fattore di rischio riteniamo che Oracle come fornitore dia sufficienti garanzie per quanto riguarda il supporto e l’aggiornamento del sistema. Questo ragionamento vale principalmente per gli altri stabilimenti del gruppo, dove tale fattore è stato ampiamente valutato; tuttavia per lo stabilimento del Valdarno dobbiamo sospendere il giudizio e considerare quindi questo fattore con non ancora valutabile.
18.Pianificazione strategica insufficiente (0). La strategia della IT, come tutte le
strategie attuate, deve essere allineata con la più generale strategia aziendale, puntando a raggiungere obiettivi in linea con essa. In questo caso la strategia di implementazione di Oracle può essere inquadrata nella strategia di espansione della Power-One che punta a ridurre la distanza dai due principali competitors. Il gruppo ha infatti deciso di investire nell’acquisto del ramo PEG della MagneTek operando poi una riorganizzazione delle attività per sfruttare le sinergie e le opportunità nate da questa acquisizione; per portare i nuovi stabilimenti dentro al gruppo è stata deciso l’avvio del progetto di implementazione di Oracle. Tale progetto porta principalmente due benefici: da un lato permette a tutti gli stabilimenti di scambiare dati e informazioni in modo uniforme, dall’altro l’utilizzo delle Power-One Best
Practise porta da una standardizzazione ed uniformità dei processi di tutti gli stabilimenti del gruppo.
19.Gestione finanziaria del progetto inadeguata (0). Dal punto di vista della gestione
finanziaria del progetto non sono emerse problematiche che abbiano influenzato l’esito del progetto.
Per un quadro riassuntivo dell’impatto dei fattori di rischio, e per i collegamenti esistenti tra i vari fattori si veda la figura 55 di pagina seguente.
6.3 Nota conclusiva
Come abbiamo detto alla fine del Capitolo 5 il rinvio del Go Live è stato concesso allo stabilimento italiano, mentre lo stabilimento di Baoan ha seguito i tempi prefissati passando ad Oracle il 1 novembre 2007.
Naturalmente i primi giorni di utilizzo del nuovo sistema sono stati decisamente convulsi e caotici, ma questo tipo di effetto era largamente prevedibile data la rivoluzione rappresentata dall’introduzione di Oracle e della logica FIFO.
Dopo questo primo periodo di caos la situazione è decisamente migliorata anche grazie al supporto attivo fornito dagli utenti chiave provenienti dallo stabilimento dominicano, accorsi numerosi in aiuto dei colleghi cinesi per supportarli nei primi difficili momenti. Questo tipo di effetto è stato registrato in tutte le implementazioni avviate dalla Power-One, anche lo stabilimento slovacco ha avuto un periodo di assestamento di circa 1 anno per assorbire l’impatto del cambiamento. Ad oggi gli utenti slovacchi sono comunque ampiamente soddisfatti dalle funzioni offerte da Oracle rispetto al loro vecchio sistema, ed il business ne ha beneficiato.
Questi tipi di esperienze, compresa quella recente dello stabilimento di Baoan, fanno comunque ben sperare per la Power-One Italy S.p.A., per la quale è previsto un periodo difficile in cui dovranno essere assimilati i numerosi cambiamenti introdotti, ma che potrà poi sfruttare le enormi potenzialità offerte dal nuovo sistema.
- 1
2
6
-●●● = Impatto elevato, ●● = Impatto medio, ● = Impatto basso, Nessun segno = Nessun impatto, NA = Non Applicabile, NYV = Non ancora valutabile, = Effetto riscontrato
● ● ●●● ●● ●● ●● (Team dimension) ●● (Consultant role) ● NA NYV NYV NYV NA F ig u ra 5 5 – A p p lic az io n e d el m o d el lo t eo ric o d i cl as si fic az io n e d ei r is ch i al p ro g et to P o w O n e – O ra cl e. .
