CAPITOLO 4 L’implementazione dei sistemi ERP: procedure, fattori critici di successo e risk management

CAPITOLO 4

L’implementazione dei sistemi ERP: procedure, fattori critici

di successo e risk management

4.1 Introduzione

Oggi le aziende che operano sul mercato si trovano ad affrontare una situazione turbolenta, in continua evoluzione, e sono soggette a pressioni competitive sia da parte delle aziende concorrenti che da parte dei clienti, la cui consapevolezza e peso contrattuale sta crescendo continuamente; i sistemi ERP, date le caratteristiche che abbiamo già esplorato nel capitolo precedente, sembrano essere un sogno divenuto realtà, una nave sicura ed affidabile con cui attraversare un mare perennemente in tempesta.

I benefici, teorici e risultanti da applicazioni pratiche, di un ERP sono molteplici; citiamo qui i risultati effettivi riscontrati dalle aziende che li hanno implementati:

o Riduzione dei costi operativi.

o Generazione di previsioni della domanda più accurate. o Aumento della velocità dei cicli produttivi.

o Aumento del livello di servizio al cliente. o Riduzione delle scorte di magazzino. o Riduzione nel fabbisogno di manodopera.

o Riduzione generale dei costi in Information Technology (dovuto alla diminuzione di sistemi ed informazioni ridondanti).

Analizzando la lista di vantaggi che si possono ottenere con gli ERP non sorprende il fatto che il mercato di questi sistemi ha conosciuto una crescita annua percentuale a due cifre pressoché costante, arrivata fino ad un +30% nell’anno 2003.

Attenzione però a non sottovalutare il classico rovescio della medaglia: l’implementazione di un sistema ERP è un processo lungo, costoso, estremamente impegnativo e con una non trascurabile probabilità di fallire.

Da varie ricerche di settore (Meta Group, Standish Group) risulta che il processo di implementazione medio di un ERP dura 23 mesi, ha un costo medio di 10,6 milioni di dollari; a questo va inoltre aggiunto un costo medio di manutenzione per i primi due anni di 2,1 milioni di dollari. Le ricerche hanno evidenziato inoltre che il PayBack Time dei

progetti ERP varia tipicamente tra 1 e 3 anni, e che le aziende monitorate hanno lamentato una perdita media del ROI di circa 1,5 milioni di dollari in un periodo di 6 anni; inoltre è risultato che il 90% dei progetti di implementazione di ERP termina fuori tempo previsto o con budget superiori a quanto preventivato.

Ricordiamo comunque che le tecniche standard per la valutazione degli investimenti trovano difficile applicazione nel caso di investimenti in Information Technology, e che vi sono vari esempi in letteratura di tecniche adattate al contesto IT o di tecniche innovative che tengono conto delle caratteristiche peculiari di tali progetti.

Nel caso degli ERP l’analisi è resa ancora più complessa e difficoltosa dallo scopo e dalle conseguenze dell’impiego di tali sistemi in azienda, per cui sembra sicuramente più corretto parlare, più che di progetti IT, di veri e propri progetti organizzativi.

È chiaro che per limitare i rischi di investimenti così complessi servono degli strumenti adeguati: una metodologia di implementazione, l’individuazione dei fattori critici di successo e l’analisi dei possibili rischi.

Se si dispone di strumenti adeguati si può quindi cercare di gestire la complessità, di anticipare le problematiche che possono presentarsi avendo ben chiaro quali sono i fattori chiave per il successo del progetto.

In questo capitolo parleremo di tali strumenti con riferimento a quanto attualmente si può trovare nella letteratura specialistica: i testi di riferimento utilizzati sono stati l’articolo “Enterprise Resource Planning: Implementation procedures and critical success factors” (E.J. Humble, R.R. Haft, M.M. Humble – European Journal of Operational Research, 2003) [3] e l’articolo “Risk Management in ERP project introduction: Review of the literature” (D. Aloini, R. Dulmin, V. Mininno – Information & Management, 2007) [4].

4.2 Fattori critici di successo per l’implementazione di un sistema ERP

I progetti di implementazione di un sistema ERP sono progetti di grandi dimensioni, con un elevato consumo di tempo e di risorse e che, se correttamente gestiti, possono avere un impatto notevole su tutti i processi dell’azienda, con i risultati che abbiamo già elencato.

Prima di parlare di metodologia di implementazione dobbiamo aver chiaro quali sono i fattori critici per il successo di questi progetti; un aiuto ci viene dai numerosi contributi presenti in letteratura, dei quali riassumeremo di seguito i risultati (vedi figura 16).

4.2.1 Comprensione degli obiettivi strategici

Come tutti i progetti anche per l’implementazione di un ERP si deve aver ben chiaro il perché si avvia tale progetto. Questo significa non solo individuare i confini del progetto in termini applicativi, temporali e di risorse, ma anche definire una visione chiara di come l’azienda dovrà operare nei successivi 3 – 5 anni per soddisfare i clienti, aumentare il grado di delega (empowerment) del personale e facilitare i fornitori.

Se si pensa all’enorme impatto che tali sistemi hanno sull’azienda è facile comprendere come la pianificazione strategica dell’implementazione rappresenti un punto chiave nell’intero progetto.

Vista l’importanza del progetto è quindi compito quindi del vertice aziendale stabilirne scopo, campo di applicazione (a quali aree funzionali o processi si intende applicarlo), obiettivi (temporizzati) da raggiungere e metodi di rilevazione dei risultati.

È fondamentale inoltre che di questi obiettivi venga data chiara comunicazione a tutte le persone coinvolte, soprattutto ai soggetti che faranno parte del team di progetto: poiché a queste persone verrà richiesto un impegno notevole e dovranno superare numerosi ostacoli, non ultima la resistenza al cambiamento propria e dei propri colleghi, avere degli obiettivi chiari, ben definiti quantitativamente e temporalmente può aiutare a concentrare i propri sforzi evitando la navigazione “a vista”.

4.2.2 Impegno del top management

I progetti di implementazione dei sistemi ERP non sono dei semplici progetti di IT, come ad esempio può essere l’acquisizione di nuovo software.

Essi richiedono che vengano ripensati tutti i processi aziendali, quindi parallelamente all’introduzione del nuovo sistema deve essere portata avanti una vera e propria reingegnerizzazione dei processi.

Questo è sicuramente uno dei punti chiave del progetto: il BPR può diventare un vero e proprio terremoto che mina le fondamenta, fino ad allora ritenute solide ed inamovibili, dell’azienda, ma è anche vero che le enormi potenzialità degli ERP si realizzano solo se si applica una revisione attenta e completa dei processi interessati; in caso contrario il notevole investimento in questi sistemi è a ritorno pressoché nullo.

Applicare un BPR di tutti i processi vuol dire ripensare, in gran parte, il funzionamento dell’azienda; decisioni di questo tipo devono essere prese a livello di top management. Sarebbe opportuno avere un comitato a livello di alta direzione che segua i risultati del processo di implementazione, in modo da supportare il lavoro del team di progetto valutando e quantificando il budget da investire, definendo i payback time del progetto e supervisionando in generale il suo andamento.

È preferibile anche che il Project Champion, ovvero il responsabile globale del processo di implementazione, sia una persona altamente rispettata, con notevoli capacità di leadership, e che sia a livello gerarchico di alto management.

4.2.3 Elevate capacità di Project Management

Come più volte detto i progetti di implementazione degli ERP sono di grande impatto per ampiezza degli scopi, numero di attori coinvolti, consumo di risorse e durata temporale.

Per raggiungere gli obiettivi prefissati servono delle elevate capacità di Project Management: gli obiettivi stabiliti devono essere chiari, si deve individuare un piano di progetto ed un piano di utilizzo delle risorse, ed il raggiungimento dei traguardi intermedi prefissati deve essere attentamente monitorato.

In particolare la timeline del progetto deve stabilire un piano “aggressivo”, facendo attenzione che gli obiettivi intermedi non siano impossibili da raggiungere ma comunicando comunque un senso di urgenza del progetto in modo che il personale impegnato nel progetto non si rilassi e non si abbiamo quindi ritardi ed inutili complicazioni.

Il primo punto da definire è sicuramente lo scopo e l’ampiezza del progetto, perché è da questo che si può capire anche il grado di complessità, difficoltà e rischio del progetto stesso.

Un progetto che mira all’implementazione di pochi moduli standardizzati sarà sicuramente meno rischioso di un progetto che mira all’introduzione di numerosi moduli e che preveda la possibilità di personalizzazioni.

4.2.4 Abilità nel Change Management

Questo punto è sicuramente uno dei fattori chiave di maggior rilevanza, e questo per un motivo molto semplice: in molte aziende la struttura organizzativa ed i processi esistenti sono incompatibili con il business model contenuto nel sistema ERP, per cui l’implementazione comporta non solo un cambio di software, ma un ripensamento quasi totale dei processi, della cultura, dell’organizzazione e del sistema sociale dell’azienda. L’azienda pre-implementazione ha una propria struttura organizzativa formale che è soggetta a profonda rivisitazione in seguito all’introduzione dell’ERP: cambiano i processi, cambiano i compiti delle persone, ci sono spostamenti di personale tra reparti. Volendo riassumere questi cambiamenti possiamo dire che gli ERP hanno un impatto notevole sulla vita lavorativa del personale aziendale, e tale impatto va oltre al cambiamento delle mansioni.

Con l’introduzione di tali sistemi viene a cambiare anche l’organizzazione informale ed il sistema sociale dell’azienda, per cui vedere i sistemi ERP come semplice software a supporto del business è riduttivo e miope.

Il vertice aziendale deve avere ben chiaro che l’obiettivo del progetto di introduzione del sistema non è semplicemente l’implementare del software, ma bensì migliorare il business: se si perde di vista questo punto lo strumento (il progetto di implementazione) da usare per raggiungere il fine (miglioramento del business) cessa di essere un mezzo e diventa fine egli stesso, e tutte le energie vengono spese per portare a compimento il progetto senza pensare alle conseguenze post-implementazione.

Dobbiamo ricordare anche che le aziende sono fatte da persone e che, oltre alla struttura organizzativa, a procedure, istruzioni e mansioni, è fondamentale il grado di partecipazione e condivisione dei fini dell’azienda; in estrema sintesi è necessario l’apporto di ogni singolo partecipante. Mentre è pero difficile riuscire a coinvolgere le persone motivandole e rendendole attori partecipi di un progetto è purtroppo semplice, ignorando la portata del cambiamento insito nel sistema e non utilizzando le tecniche di Change Management, renderle ostili, creando danni notevoli.

Per un progetto di questa portata vi è il bisogno di una partecipazione consapevole delle persone, se invece le persone sono ostili e non vogliono cooperare per arrecare un danno sostanziale non vi è bisogno di comportamenti distruttivi o di ostacolo, è sufficiente che i soggetti coinvolti siano passivi, facendosi trascinare come un peso dal resto del team di sviluppo, per ottenere questo fine.

In ogni ambiente in cui sono radicate strutture sociali e vi sono usanze ed abitudini consolidate è difficile portare un cambiamento, specie se ai soggetti che devono subire tali cambiamenti non vengono coinvolti facendo loro capire quali benefici possono trarne, per cui un l’implementazione di un ERP che venga percepito come un qualcosa di imposto e calato dall’altro sarà di difficile esecuzione.

4.2.5 Un team di implementazione eccellente

Oltre alle caratteristiche eccellenti del top management e del responsabile di progetto serve ovviamente un team di implementazione formato da persone capaci, di riconosciuta capacità, con un’alta reputazione, in grado di essere flessibili e di gestire un progetto così complesso.

Il team è spesso formato da un misto di soggetti, tipicamente vi sono appartenenti alla funzione IT, rappresentanti delle funzioni aziendali con un’elevata esperienza e conoscenza dei processi e, in alcuni casi, consulenti esterni, che possono ad esempio appartenere alla software house proprietaria del sistema o ad aziende di consulenza. Del team devono fare parte persone con abilità non solo dal punto di vista prettamente professionale ma anche con spiccate capacità organizzative e di gestione dei rapporti interpersonali, con notevoli attitudini per il lavoro di gruppo.

Il team sarà in continuo contatto con il top management al quale riporterà per tutte le decisioni strategiche, mentre per le decisioni non critiche il team deve essere in grado di operare autonomamente; importante è quindi il grado di delega e l’ampiezza dell’ambito decisionale che viene lasciato al team.

È compito del team inoltre lo stabilire il piano generale del progetto, assegnare le responsabilità per le varie attività ed individuare le date dei traguardi intermedi del progetto; il team si deve inoltre assicurare che tutte le risorse necessarie saranno disponibili secondo le necessitò stabilite.

4.2.6 Accuratezza dei dati

Quello dell’accuratezza dei dati è un fattore che deriva dalla struttura degli ERP. Come abbiamo infatti visto in precedenza questi sistemi si fondano su una base di dati condivisa, per cui ogni dato presente nel sistema è unico e condiviso da tutti gli utenti interessati.

Proprio per questa caratteristica l’accuratezza dei dati diviene indispensabile: ogni errore nell’inserimento dei dati si ripercuote con un effetto negativo a catena su tutti i processi aziendali.

Per quanto sopra esposto si deve quindi procedere ad educare tutti gli utenti su questo punto, rendendoli consapevoli dell’importanza dell’accuratezza dei dati e dalla necessità di un data entry corretto.

I sistemi ERP, per funzionare in modo proprio e per offrire tutte i loro potenziali vantaggi, richiedono che le persone lavorino nel sistema, non cercando di aggirarlo. L’azienda deve convincere gli utenti che l’obiettivo è quello di utilizzare solo tale sistema, che non saranno tollerate eccezioni e che non sarà assolutamente permesso l’uso di vecchi sistemi. Per sottolineare questo punto tutti i vecchi sistemi, compresi quelli informali elaborati dai singoli utenti, dovranno essere eliminati.

4.2.7 Training esteso ed intensivo

L’importanza del training (addestramento) come fattore di successo è universalmente riconosciuta: i benefici che un ERP può fornire non si realizzano fino a quando gli utenti finali non utilizzano correttamente il sistema.

Se gli utenti non capiscono appieno il funzionamento del sistema e quindi non accettano il nuovo processo che esso in un certo senso impone troveranno delle scappatoie e delle alternative, adoperando solo quelle parti (ad esempio solo determinate funzioni o transazioni) del sistema che essi sono in grado di comprendere ed utilizzare correttamente.

Un altro motivo che rende critico l’addestramento riguarda il grado di comprensione del nuovo sistema e come questo influisce sull’individuazione, e sulla risoluzione, delle problematiche di implementazione. Nell’eseguire una reingegnerizzazione dei processi si deve valutare quali sono i processi correnti (AS IS) supportati dal sistema informativo attualmente in uso, confrontando quanto emerso con i nuovi processi (TO BE) supportati dalle funzioni del sistema ERP, cercando di colmare eventuali gap esistenti.

In questa fase, chiamata in letteratura Gap Analysis, è necessario l’apporto di alcuni utenti chiave, ad elevata conoscenza dei processi correnti, per individuare e risolvere questi gap. In questo caso l’addestramento degli utenti chiave permette una prima familiarizzazione con il nuovo sistema, la conoscenza dei meccanismi e delle funzioni in esso presenti e, se correttamente eseguito, anche un primo superamento di eventuali barriere psicologiche al cambiamento.

Un errore che viene comunemente commesso è quello di sottovalutare il livello di addestramento necessario per implementare con successo un ERP, con conseguente stima insufficiente delle risorse (budget e tempi) da riservare ad esso. L’addestramento deve iniziare con congruo anticipo rispetto alla data di effettivo utilizzo del nuovo sistema; anche se inizialmente la preparazione degli utenti avverrà con un sistema in forma non definitiva, soggetto ad ulteriori modifiche nel corso del progetto, la familiarizzazione con il nuovo sistema potrà essere utile anche ai fini di un migliore Change Management. In letteratura è stato suggerito che riservare all’addestramento un 10 -15 % del budget totale del progetto permette di avere un probabilità di successo dell’implementazione pari all’80%.

Riguardo all’addestramento va segnalato anche che anche un training esteso e completo in fase di implementazione non è sufficiente a rendere l’utente finale pienamente capace di gestire tutte le situazioni operative; la piena conoscenza del sistema si raggiunge solo con il suo utilizzo giornaliero affrontando le normali problematiche quotidiane che possono presentarsi.

Per questo è necessario che l’addestramento prosegua anche dopo l’implementazione, e che vengano previste delle riunioni periodiche con gli utenti del sistema in modo da individuare eventuali problematiche e favorire lo scambio orizzontale e verticale di informazioni tra gli utenti stessi.

4.2.8 Adeguate misure di performance del sistema

Con questo fattore si intende che devono essere costruiti appositi indicatori che misurino la performance del sistema non solo, come è ovvio, da un punto di vista delle prestazioni classiche del sistema (come ad esempio il numero di transazioni gestite o il tempo di risposta), ma anche in termini di raggiungimento degli obiettivi.

Abbiamo detto in precedenza che i progetti di implementazione degli ERP sono molto complessi e devono quindi essere attentamente pianificati, avendo ben chiaro innanzitutto quali sono gli obiettivi del progetto.

Il macro obiettivo del progetto sarà sicuramente il miglioramento del business aziendale attraverso l’utilizzo del sistema ERP, ma tale traguardo deve essere tradotto in obiettivi quantificati e temporizzati: ad esempio si possono usare come indicatori il risultato operativo, la percentuale delle consegne effettuate nei tempi previsti, il tempo di attraversamento dell’ordine, l’indice di rotazione delle scorte in magazzino, ecc.

Il fine del top management nello stabilire queste milestones è fondamentalmente quello di indirizzare l’implementazione e l’utilizzo del sistema ERP allineandolo con le strategie aziendali.

Questi traguardi devono essere stabiliti nella fase di pianificazione del progetto, devono essere comunicati a tutto il personale coinvolto ed è su di essi che devono essere valutate le performance degli attori interessati, motivandoli al raggiungimento degli obiettivi prefissati con il budget ed i tempi stabiliti: questo si ottiene ad esempio legando i bonus e gli aumenti ai manager coinvolti proprio al conseguimento di tali mete.

Tutto il processo di implementazione deve essere attentamente valutato attraverso opportuni indicatori di performance, ma il monitoraggio non si deve fermare con il raggiungimento del Go Live: la misurazione e il controllo delle performance di sistema deve continuare per tutta la durata della vita del sistema.

Un punto cruciale relativo alle prestazioni ma che è collegato anche al Change Management riguarda le prestazioni attese al momento del Go Live: deve essere chiaramente comunicato a tutto il personale che, data la complessità di gestione e di utilizzo del nuovo sistema, è probabile che le performance nel breve periodo (da 6 mesi fino ad 1 anno dopo il Go Live) subiscano un iniziale declino.

Quando la familiarità degli utenti e la loro conoscenza del sistema aumenteranno inizieranno a manifestarsi dei miglioramenti delle performance; è opportuno che quanto summenzionato venga comunicato a tutte le persone coinvolte per evitare facili allarmismi o scoramento.

4.2.9 Problemi legati all’implementazione multi – sito

Vista la struttura internazionale di molti gruppi industriali, anche di medie dimensioni, questo fattore assume una sempre maggiore rilevanza.

In questo caso si scontrano due esigenze totalmente opposte:

o L’implementazione, attraverso l’ERP, di una standardizzazione dei processi in modo da aumentare il controllo centralizzato dei singoli impianti.

o La necessità di sfruttare le peculiarità di ogni singolo sito puntando ad un’ottimizzazione locale.

La standardizzazione comporta interfacce semplificate tra le diverse parti dell’organizzazione, la possibilità di muovere le persone ed i prodotti tra i vari impianti con un impatto ridotto ed una facilitazione generale nel consolidamento dei dati di tutta l’organizzazione.

L’ottimizzazione locale di contro può portare ad un aumento di efficacia ed efficienza dei processi operativi con conseguente riduzione dei costi.

Si tratta quindi di ottenere un trade-off tra queste due esigenze contrapposte, con il fine di ottimizzare il funzionamento della totalità dei siti. Avevamo già parlato indirettamente di questo fattore quando avevamo parlato di personalizzazione del sistema: in una implementazione multi-sito il sistema ha un nucleo comune a tutti i siti pari all’85-90% della totalità, mentre la restante percentuale è costituta da soluzioni utilizzate localmente per soddisfare le necessità del singolo sito.

Questa scelta deve essere attentamente pianificata e devono esserne valutate le conseguenze; l’orientamento di questo tipo di decisione dovrebbe seguire quanto stabilito a livello di strategia generale del gruppo, ovvero se puntare ad un controllo centralizzato a investire sull’ottimizzazione locale.

Un caso particolare di implementazione multi – sito è quello in cui l’introduzione del sistema ERP deve essere eseguita su più siti. Anche qui la scelta è tra impostare una

Implementazione

multi - sito

oInterfacce semplificate

oPossibilità di muovere personale e prodotti tra gli impianti

oConsolidamento dei dati

o Aumento efficacia o Aumento efficienza o Riduzione costi

Trade Off

Figura 17 – Il Trade Off nelle implementazioni multi-sito tra standardizzazione dei processi e ottimizzazione locale.

introduzione contemporanea del sistema su tutti i siti interessati oppure eseguire una introduzione graduale a fasi, ovvero eseguendo l’implementazione per modulo, per impianto o per linea di prodotto.

Se si punta ad un recupero veloce del notevole investimento nel sistema allora si promuoverà un’implementazione contemporanea; se si vogliono minimizzare i rischi, aumentando però i tempi, si sceglierà un’implementazione a fasi, in cui da un progetto pilota si acquisiscono delle conoscenze utili per i successivi progetti.

4.3 L’implementazione di un sistema ERP: metodologia in 12 passi

Abbiamo più volte ribadito come con progetti di così grandi dimensioni come quello di implementazione di un sistema ERP serva un approccio strutturato e disciplinato, una metodologia che permetta di gestire la e notevoli complessità legate a tali progetti. Nel capitolo successivo vedremo una metodologia “sul campo”, ovvero nel caso concreto oggetto di questo lavoro; quello che preme qui fare è presentare una metodologia suggerita da vari autori per proporre un confronto tra quanto teoricamente suggerito in letteratura e quanto praticamente eseguito in un caso reale.

La metodologia, ripresa da [3] ed originariamente nata come combinazione dei lavori di vari autori, è composta da 12 passi suggeriti e viene riportata in figura 18.

1. Processo di selezione dell’ERP. Questo primo passo è estremamente importante, in quanto si tratta di scegliere tra le varie soluzioni che il mercato offre quella più adatta ai requisiti dell’azienda. Vi sono varie software house che realizzano software di tipo ERP (tra i principali citiamo SAP, Oracle e SQL), ciascuno con i propri punti di forza e di debolezza rispetto ai concorrenti. Come già detto ogni ERP si basa su di un business model preciso che in un certo senso impone all’azienda un adattamento forzato dei propri processi su quelli modellati dal sistema; anche se vi è sempre la possibilità di una personalizzazione, è anche vero che questa scelta comporta un incremento notevole nei costi. La scelta finale dovrebbe ricadere sull’ERP il cui business model sia strategicamente più utile all’azienda, ovvero che aiuti ad esaltare i suoi punti di forza cercando di migliorare i punti di debolezza. In letteratura si può trovare un metodo, che qui non tratteremo, di scelta di un sistema ERP in 13 passi. 2. Gap Analysis. Come precedentemente illustrato in questa fase viene dapprima

svolto un’analisi dei processi correnti (AS IS) individuando anche il tipo di supporto fornito dall’attuale sistema informativo, dopodichè si studiano i processi futuri (TO BE) sulla base del business model e delle funzionalità offerte dal sistema ERP. Le differenze (gap) così individuati dovranno essere risolti nelle fasi successive: una possibile soluzione può essere una personalizzazione del sistema, una soluzione di segno contrario può invece essere una reingegnerizzazione del processo per allinearlo al modello del sistema.

3. Installare e testare nuovo Hardware. Prima di procedere all’installazione del software si deve eseguire l’installazione dell’Hardware necessario e si deve testare il suo corretto funzionamento.

4. Installare e testare il Software. Solitamente questa operazione viene svolta da una tecnico del fornitore del software che provvede ad installare il software e ad eseguire alcuni test preliminare per garantire l’esito positivo dell’installazione.

5. Training. Si può vedere come l’addestramento incominci nelle fasi iniziali del progetto; lo scopo è di insegnare agli utenti i rudimenti del nuovo sistema.

6. Training tramite CRP. Il CRP (Conference Room Pilot) serve da un lato per testare il funzionamento del sistema, dall’altro per verificare il grado di comprensione e di addestramento degli utenti. Il team di progetto crea un insieme di casi di test da sottoporre agli utenti durante il CRP, ciascuno afferente una diversa area funzionale ed un singolo sottoprocesso: si simula, passo dopo passo, l’intero processo dalla ricezione dell’ordine del cliente alla spedizione del prodotto finito.

7. Stabilire setup e responsabilità utente. Questa fase avviene alla fine della fase di training tramite CRP, ed ha lo scopo di iniziare ad individuare i profili degli utenti finali in modo che ogni utente abbia l’accesso alle informazioni di cui necessita. 8. Assicurare la corretta migrazione dei dati. Questo punto non riguarda solo il

trasferimento finale dei dati per il Go Live, ma anche il popolare il nuovo sistema con i dati attuali dell’azienda durante i CRP in modo che gli utenti possano prendere confidenza con l’ERP ed utilizzando informazioni conosciute: se si fanno dei test con i dati “reali” (duplicati dal Legacy sulla sessione di test, per cui sono dati attuali ma la cui modifica non tocca il business quotidiano) gli utenti incominceranno ad avere fiducia nel nuovo sistema. La migrazione dei dati è facile dal punto di vista di un mero spostamento dei dati tra i due sistemi, è invece estremamente difficile mantenere i legami logici, assicurare la correttezza dei dati ed effettuare, come solitamente accade in queste occasioni, una ripulitura dei database per eliminare i dati ridondanti o obsoleti.

9. Documentare le politiche e le procedure. Le politiche del progetto devono essere documentate, e questo deve comprendere anche una chiara descrizione del policy statement dell’intero progetto; i passi per raggiungere lo statement possono essere dettagliati in un flowchart.

10.Portare l’intera organizzazione online. Questo passo varia sensibilmente a seconda che si opti per una implementazione contemporanea e completa del sistema o se si opta per la soluzione parziale a fasi. Nel primo caso si porta prepara l’organizzazione alla data di cutoff, preferibilmente quando lo stabilimento osserva una o due settimane di chiusura (ad esempio durante la chiusura estiva). Nel secondo caso invece si sceglie quale modulo / prodotto / impianto portare online per primo, quindi si procede in sequenza. Questo approccio multifase permette degli aggiustamenti in corso d’opera, utilizzando quanto appreso nelle prime implementazioni per migliorare le successive.

11.Celebrare. Questo passo può senza ombra di dubbio divenire il passo più importante: il top management deve dare chiara dimostrazione di quanto realizzato festeggiando la conclusione di un progetto così impegnativo, dimostrandone anche l’importanza per l’organizzazione.

12.Miglioramento continuo. Un’organizzazione può assorbire un quantitativo finito di cambiamenti in uno stabilito periodo di tempo. Rendersi conto di questo fatto vuol

dire puntare sulla spinta al miglioramento continuo, incoraggiando gli utenti ad avere un approccio critico al sistema per individuare aree di incremento delle prestazioni.

4.4 La gestione del rischio nell’implementazione dei sistemi ERP

Che i progetti di implementazione dei sistemi ERP, a causa delle loro caratteristiche (grandi dimensioni, elevato uso di risorse, alta percentuale di fallimento), dei progetti particolarmente rischiosi è facilmente intuibile.

È anche vero che i benefici potenzialmente ottenibili con il loro impiego sono tali da rendere accettabile il correre dei rischi.

Attenzione però a due fattori fondamentali:

1. I benefici non derivano semplicemente dal fatto di aver adottato un sistema ERP, ma si raggiungono solo portando a positivo compimento il progetto di implementazione in tutti i suoi passi. Come abbiamo già riferito, se si adotta un ERP senza aver fatto una reingegnerizzazione dei processi i benefici che si possono ottenere sono sicuramente limitati, dovuti solo all’impiego di tecnologie più moderne e non alle caratteristiche di tali sistemi. Inoltre la fase di analisi insita nell’intero processo di implementazione può portare dei vantaggi inattesi (ad esempio una più approfondita conoscenza dei processi aziendali attuali, con la possibilità di individuare aree di miglioramento).

2. Dover affrontare un progetto ad elevato rischio non significa incrociare le dita sperando che tutto vada bene, oppure affrontare con un certo fatalismo la probabilità di fallimento del progetto. Negli ultimi anni sono state sviluppate delle metodologie di gestione del rischio che mirano a prevenire e a ridurre i rischi; se è pur vero che tali metodologie sono troppo generalizzate per essere utilizzate allo stato originale nei progetti di implementazione degli ERP, è anche vero che i concetti fondamentali ivi contenuti possono essere proficuamente impiegati. Resta comunque valida, come metodologia principe di gestione del rischio in un progetto complesso, una attenta e ponderata pianificazione e gestione del progetto stesso.

Quali sono i rischi di un progetto ERP? Possiamo rispondere facendo riferimento all’articolo [4] dove gli autori hanno compiuto un lavoro di catalogazione della letteratura di settore proprio per individuare i rischi di un progetto ERP.

Esporremo brevemente i risultati di tale lavoro con il fine di confrontarli con quanto osservato nel progetto oggetto di questo lavoro, in modo da avere chiaro quali siano le

differenze tra i metodi sperimentali suggeriti dalla letteratura specialistica ed i metodi applicati sul campo; per un approfondimento rimandiamo alla lettura integrale dell’articolo citato.

Come prima cosa si possono raggruppare i fallimenti di un progetto ERP in quattro macro categorie:

a. Fallimento di processo, quando il progetto viene completato oltre il tempo previsto e fuori budget.

b. Fallimento delle aspettative, quando il sistema IT non rispetta le aspettative degli utenti.

c. Fallimento dell’interazione, quando l’atteggiamento degli utenti verso il sistema IT è negativo.

d. Fallimento della corrispondenza, quando non c’è corrispondenza tra il sistema IT e gli obiettivi pianificati.

Vi sono poi dieci effetti principali dei rischi, ciascuno riconducibile ad una o più delle sopraelencate categorie: budget sforato, timeline non rispettata, progetto arrestato, business performance inadeguate, scarsa stabilità ed affidabilità del sistema, bassa applicabilità ai processi dell’organizzazione, sistema non user-friendly, basso grado di integrazione e flessibilità, bassa corrispondenza con gli obiettivi strategici pianificati, bassa performance finanziaria ed economica dell’organizzazione.

Gli autori hanno poi individuato 19 fattori di rischio che andiamo di seguito ad elencare dandone una sommaria descrizione:

1. Processo di scelta dell’ERP inadeguato. Anche se l’implementazione può venir eseguita con successo, se si è scelto un sistema ERP inadeguato ai requisiti dell’organizzazione si avrà con elevata probabilità un peggioramento delle performance.

2. Basse abilità del team di progetto. Le competenze del team di progetto, sia sul business che tecnologiche, hanno un impatto di primaria importanza sul successo o sul fallimento dell’intero progetto, soprattutto nella fase pre-installazione.

3. Basso coinvolgimento del top management. Abbiamo già visto come il diretto e continuo supporto del top management sia necessario alla riuscita del progetto. 4. Sistema di comunicazione inefficiente. La comunicazione, in progetti di questa

complessità, deve essere particolarmente curata.

5. Basso coinvolgimento degli utenti chiave. Gli utenti chiave, che posseggono particolari qualità personali e conoscenza approfondita dei processi, devono essere

coinvolti sia per convincerli dell’utilità del sistema che per sollecitare il loro apporto al progetto.

6. Addestramento inadeguato. Abbiamo già abbondantemente parlato dell’importanza dell’addestramento, durante tutto il progetto e anche dopo l’installazione.

7. Architettura complessa ed alto numero di moduli implementati. Ovviamente con il crescere del numero dei moduli implementati cresce anche la complessità del progetto; attenzione inoltre a come si gestiscono le personalizzazioni del sistema. 8. BPR inadeguato. Questo punto è stato più volte ribadito, con l’introduzione, e anche

in seguito, dei sistemi ERP si deve eseguire una attenta reingegnerizzazione dei processi.

9. Cattiva gestione del progetto. Per una implementazione di successo è necessaria una chiara visione del business, in modo da stabilire obiettivi ben definiti che guidino l’intero progetto.

10.Tecniche di gestione del progetto inefficienti. Se non si utilizzano delle tecniche di gestione adeguate il rischio di fallimento aumenta in modo considerevole. Tra le tecniche di gestione ricordiamo anche l’importanza, già citata, delle tecniche di gestione del rischio. Alcuni produttori (SAP, Baan, Oracle) offrono delle metodologie che aiutino nell’implementazione le aziende che adottano i loro sistemi; altre più generiche si trovano in letteratura.

11.Inadeguata gestione del cambiamento. Di questo punto abbiamo già abbondantemente parlato nei paragrafi precedenti.

12.Inadeguata gestione del sistema Legacy. Con questo punto si intende sia il fatto che, come precedentemente illustrato, i vecchi sistemi non devono essere più disponibili perché altrimenti ci sarà sempre qualcuno che li userà, sia la criticità della fase di vera e propria transizione dal Legacy all’ERP.

13.Servizi di consulenza inefficienti. L’uso di consulenti nelle implementazioni è abbastanza comune, ovviamente i consulenti devono possedere adeguate conoscenze sia tecnologiche del sistema, ma anche di gestione di progetti così complessi, per dare un contributo positivo all’intero progetto.

14.Scarsa leadership. Con questo fattore si vuole mettere in rilievo che senza una partecipazione continua e senza un ruolo attivo sia del top management sia del responsabile di progetto, la probabilità di portare positivamente a termine il progetto diminuiscono.

15.Caratteristiche del sistema IT inadeguate. Le caratteristiche tecniche e funzionali del software devono essere analizzate prima dell’implementazione; tra le caratteristiche ricordiamo la funzionalità, la user – friendliness, la portabilità, la scalabilità, la modularità, ecc.

16.Manutenibilità del sistema IT inadeguata. Poiché i costi di manutenzione annui si attestano circa sul 25% del costo iniziale di un ERP la caratteristica di manutenibilità, ovvero di raggiungere gli obiettivi operativi con un minimo sforzo manutentivo nelle normali condizioni operative, è di primaria importanza.

17.Stabilità e performance del fornitore IT insufficienti. Poiché questi sistemi hanno bisogno di un supporto continuo e di un adeguamento costante (ad esempio l’introduzione di nuovi moduli aggiornati) il grado di supporto del fornitore del sistema è rilevante.

18.Pianificazione strategica insufficiente. La strategia della IT deve essere allineata con la più generale strategia aziendale, puntando a raggiungere obiettivi in linea con essa. 19.Gestione finanziaria del progetto inadeguata. Questo rischio è importante dato

l’elevato investimento che questi sistemi rappresentano.

I collegamenti tra categorie di fallimenti, rischi principali ed i 19 fattori di rischio sono mostrati in figura 19 (ripresa da [4]).