Implementazione ERP: una sfida (im)possibile?
Implementazione ERP. Quando ci riflettete nella vostra mente compare Enterprise Resource Planning, o una voce in lontananza inizia a sussurrare “Attenzione: Esaurimento Risorse Possibile”?
Non preoccupatevi, se almeno una volta ci avete pensato non è solo la classica e tanto familiare paura del cambiamento, ma siete semplicemente consapevoli della complessità dell’operazione e di tutti i suoi rischi.
D’altronde, con tutti i casi di implementazioni fallite che si sentono, non c’è da prenderla alla leggera.
Iniziamo valutando il contesto. “A forza di tirare, la corda si spezza”.
Ecco, nelle implementazioni ERP non siete solo in due, ma in tre e ciascuno tira dalla sua parte:
- Lo sponsor del progetto propende, giustamente, verso il rispetto del budget e desidera un sistema di alta qualità che rispecchi il più possibile gli standard e le Best Practice proposte dal System Integrator;
- Il System Integrator, in base alla tipologia di contratto stipulato, cerca o di massimizzare il guadagno, offrendo il maggior numero di personalizzazioni possibili o di minimizzare l’effort delle proprie risorse proponendo, nella maggior parte dei casi, soluzioni standard che rischiano però di non soddisfare appieno i requisiti del Cliente.
- Infine la popolazione aziendale – la voce meno ascoltata fra le tre – che teme, più o meno inconsciamente, il cambiamento ed è, quindi, frenata rispetto a nuove abitudini lavorative.
Con tutte queste forze in gioco non stupisce che alcuni progetti di implementazione ERP finiscano per somigliare a romanzi di Stephen King e si guadagnino il titolo di casi horror. Fanno paura, ma ci aiutano a capire quali sono i problemi a cui si va incontro; prendiamone quattro fra i più famosi, uno per ogni problema.
4 problemi di implementazione: 4 casi di fallimenti
LIDL e lo sforamento del budget
La nota catena tedesca di supermercati low-cost nel 2011 ha intrapreso un percorso di implementazione ERP. Il risultato? Sette anni di lavoro tra continui extra budget che hanno toccato i 500 mln di euro, progetto abbandonato e ritorno al vecchio sistema gestionale.
Hershey Company: risultati attesi vs. realtà
Immaginate di acquistare una nuova automobile, più affidabile e veloce e, una volta alla guida, rendervi conto che non vi porta i miglioramenti attesi: questa è la situazione in cui si è trovata la Hershey Company.
La società produttrice americana di cioccolato si aspettava di ottenere diversi vantaggi grazie all’implementazione ERP, e invece, proprio a causa del nuovo sistema gestionale, nell’anno successivo il suo fatturato è diminuito del 19%.
Worth & Company: go live, ritardi e rinunce
Per la Worth & Company, azienda manifatturiera della Pennsylvania, la data del go-live è diventata un miraggio: era stata inizialmente programmata per novembre 2015, poi spostata a febbraio 2016, rinviata ancora al 2017, finché…basta! L’impresa ha preferito rinunciare al progetto.
Vodafone e il blocco del servizio per il cliente finale
Vodafone UK è stata multata dalle autorità britanniche per 4,6 mln di sterline perché, a causa della cattiva implementazione della nuova struttura informatica, a buona parte degli utenti non venivano accreditati i pagamenti effettuati.
È facile parlare dei problemi che si manifestano alla fine di un processo difettoso o non ben realizzato, più difficile è invece analizzarli per comprenderne le cause radice. Naturalmente, in progetti complessi come quelli che stiamo descrivendo, non esiste una corrispondenza biunivoca problema-causa, ma spesso ci si trova davanti a differenti combinazioni di variabili non controllate.
9 cause che possono portare un’implementazione ERP al fallimento
1. Soluzione tecnica über alles
Quando in un progetto di implementazione ERP l’azienda cliente si fa trainare troppo dalla soluzione tecnica, nasce un problema. Senza un’analisi degli impatti organizzativi e sociali delle soluzioni proposte, senza una valutazione approfondita degli effetti positivi e negativi sui processi e dell’influenza sulla struttura organizzativa, determinata dalla ridefinizione del sistema di ruoli e responsabilità, il progetto rischia di fallire.
I key user vanno accompagnati nella collaborazione con il system integrator; è necessario tracciare fin da subito il sottile confine che divide gli elementi tecnici nice to have da quelli must to have, poiché queste risorse, soggette a una forte resistenza al cambiamento, tenderanno a classificare tutto il possibile come must to have. Questa dinamica si concretizza nella continua richiesta di processi ad hoc per i requisiti particolari della propria realtà, fino a far diventare il nuovo sistema ERP una copia disfunzionale del sistema precedente.
La ricerca di un equilibrio tra standardizzazione e personalizzazione è da tenere presente sin da subito in quanto forza latente ma trainante dell’intero progetto.
2. Comunicazione, questa sconosciuta
All’interno di un progetto di implementazione ERP vengono coinvolte, giustamente, solo un certo numero di persone. Il gruppo lavora al progetto per diversi mesi, mentre il resto della popolazione aziendale – a volte, ed erroneamente – scopre dell’esistenza del nuovo sistema solo un mese prima del lancio – il cosiddetto live.
È naturale che le persone non coinvolte fin dall’inizio siano meno informate, ma è inaccettabile la totale mancanza di comunicazione su cosa stia avvenendo in azienda.
Senza un momento di “aggiornamento” che faccia sentire anche i non Key User parte di un cambiamento in atto, il progetto rischia di cadere. Ricordiamoci che in un processo di cambiamento siamo soliti evidenziare gli aspetti negativi piuttosto che quelli positivi, soprattutto quando il cambiamento ci viene imposto. Per questo motivo è necessario creare un flusso comunicativo ben strutturato, ma soprattutto adatto al target che si vuole raggiungere.
3. Le persone non sono a energia infinita
Come ogni risorsa presente sulla Terra, anche le persone (i nostri KU) non sono ad energia infinita. Affidare il progetto a un gruppo ristretto può diventare una criticità se il carico di lavoro è eccessivo, soprattutto nelle fasi iniziali di Business Blueprint e Project Realization.
Facciamo un passo oltre, provate ad immaginare di essere un KU impegnato per sei ore al giorno in riunioni finalizzate a definire la struttura del nuovo sistema ERP. Finite queste sei ore avrete da svolgere tutte le attività che non siete riusciti a svolgere durante la giornata.
A questo punto, come sarebbe la vostra motivazione? Vi sentireste coinvolti o travolti dal progetto?La risposta è semplice.
È proprio per evitare questa dinamica che è necessario eseguire preventive analisi di saturazioni, monitorare e variare il carico di lavoro delle risorse.
I KU sono i nostri migliori ambasciatori e più prestiamo attenzione alla loro motivazione e al loro carico di lavoro, più si sentiranno parte attiva del progetto. Non basta definire a tavolino i carichi di lavoro, è necessario (a fine motivazionale) domandar loro quali siano le loro esigenze, impostare un sistema di interviste cadenzato che permetta alla risorsa di comunicarci le sue difficoltà, e a noi di captare tutto l’insieme di rischi e malcontenti che si stanno sviluppando.
4. Pensare che il progetto sia tecnico
Pensare che il progetto di trasformazione digitale sia un progetto IT e non un progetto di business è un enorme rischio, purtroppo molto comune. Non vogliamo dire che il progetto debba per forza essere in capo al Business ma sicuramente deve essere considerato come impattante a tutto tondo la realtà aziendale. A fine progetto non avremo solo un nuovo gestionale ma risorse che, molto probabilmente, dovranno andare incontro ad un nuovo modus operandi che li porterà ad agire processi e comportamenti differenti.
5. System integrator al comando
Nella maggior parte dei casi le competenze tecniche sul nuovo sistema ERP non risiedono all’interno dell’azienda, ma sono appannaggio del system integrator.
Possiamo tranquillamente affermare che, nel gioco delle parti, il system integrator si ritrova in una posizione di forza dalla quale detta il governo del progetto, i tempi, le specifiche tecniche e può influenzare il budget definito.
L’impresa cliente, che non conosce la soluzione tecnica, si espone così al rischio di tempi lunghissimi, soluzioni software non strettamente necessarie e budget fuori controllo.
6. Non gestione dei rischi
L’impatto del progetto di implementazione ERP non è da sottostimare. I rischi che presenta non sono solo tecnici, ma anche legati all’organizzazione e al processo.
Il sistema di responsabilità, per esempio, è spesso considerato un elemento a sé stante, ma viene a modificarsi e delinearsi in conseguenza della nuova struttura informatica. Frequentemente le attività svolte dalle risorse cambiano, le anagrafiche potranno essere gestite dall’ufficio vendite invece che dall’amministrazione e l’accountable del processo di richiesta ferie potrebbe diventare ogni singolo responsabile e non l’ufficio Risorse Umane.
7. I "Sabotatori"
In aziende che utilizzano sistemi gestionali datati, i capi funzione generalmente hanno avuto modo di costruirsi nel tempo un insieme di strumenti che rappresentano il loro knowledge management. Ora, nel momento in cui l’azienda decide di adottare un sistema gestionale integrato, l’intero patrimonio di informazioni dei capi funzione viene migrato all’interno del sistema. Per alcune persone questo significa “perdere potere” all’interno dell’organizzazione e potrebbero trovarsi a pensare “Adesso che i dati sono tutti disponibili nel nuovo sistema gestionale, perderò visibilità”. Da qui origina quella che viene definita la dinamica dei sabotatori, ossia quelle figure che non si spendono al 100% sul progetto perché vedono l’arrivo della nuova infrastruttura informatica come una perdita per la loro essenzialità.
8. Siamo sicuri di aver scelto le persone giuste?
L’azienda cliente normalmente sceglie le figure per il progetto basandosi sulla loro competenza tecnica e sulla disponibilità/grado di saturazione. Usare solo questi criteri di selezione può essere un problema; non bisogna dimenticare, infatti, che tra le risorse che formano il team di progetto, dovranno anche essere individuati i change agent.
La difficoltà, spesso sottovalutata nella selezione di queste risorse, è che non tutti possono essere dei buoni change agent: non devono essere solo abili tecnicamente ma altrettanto eccellenti sul piano sociale, poiché saranno i primi “ambasciatori” del progetto.
Saranno chiamati ad accompagnare nel cambiamento buona parte della popolazione aziendale, a motivare il team di progetto, a essere i primi comunicatori dei low hanging fruits, ossia i primi benefici ottenuti grazie al nuovo sistema, a comunicare correttamente gli step progettuali, ma soprattutto a scoraggiare, attraverso il loro atteggiamento, la fisiologica paura del cambiamento.
9. Processo non significa funzione
Succede di frequente che durante la mappatura dei processi si ragioni per singola funzione. Per esempio, se la mappatura riguarda la funzione vendite, il system integrator coinvolge solo le persone dell’ufficio sales, quando in realtà molti aspetti del processo possono avere un impatto anche sull’amministrazione e sul controllo di gestione.
Per definizione stessa, si sta implementando un sistema integrato e integrata deve anche essere la fase di analisi.
Non basta coinvolgere solo le risorse che sono parte attiva di una determinata funzione, ma anche tutte quelle che vengono toccate o sono in qualche modo influenzate da essa.
I 5 pilastri per condurre una implementazione di successo
Per evitare di incorrere in uno dei 9 problemi, o di doverli risolvere nel momento in cui si presentano, è consigliabile per l’azienda cliente affidarsi a un terzo attore, come Lenovys, che sia in grado di supportare l’implementazione verso il raggiungimento degli obiettivi attesi in termini di costi, tempi, qualità e gestire l’intero processo di cambiamento.
Questo si traduce in un piano di Change Management che, per essere efficace, dovrà concentrarsi sui 5 pilastri che formano l’acronimo G.I.O.I.A.
1. Governance
Strutturare la governance di progetto risulta di fondamentale importanza per mantenere saldi 3 pilastri: tempi, costi e qualità. Allo stesso tempo, sarà necessario tenere dritto il timone nei confronti di 3 soggetti:
- il system integrator
- l’azienda cliente
- gli utenti
Governance significa il rispetto delle scadenze, quindi la definizione di Gantt di dettaglio.
Governance significa mappatura del rischio, che deve essere fatta all’inizio del progetto, durante, e persino oltre il lancio del sistema.
Governance significa Project Management Office (PMO), quindi l’organizzazione degli incontri, creando tavoli cross-funzionali con l’obiettivo di ragionare in ottica di processo e non di funzione.
La vera Governance è saper gestire in anticipo i cambiamenti organizzativi e sociali che il progetto può portare e soprattutto le conseguenze che potranno avere.
2. Integration
Come già detto in precedenza il sistema ERP è un sistema integrato, quindi non va implementato per funzione o per dipartimento. L’integrazione va realizzata nel modo più funzionale in relazione alla struttura e ai processi del cliente.
È necessario, fin dalle prime fasi di progetto, lavorare avendo ben presente che la nuova struttura informatica comunicherà a 360 gradi con le altre funzioni e che quindi ogni codifica, ogni processo deve essere funzionale non solo a me, ma anche al mio collega.
Meno le nostre risorse capiscono questa dinamica e più avremo lavoro a compartimenti stagni e un sistema ERP non funzionale.
3. Opportunità
Il cambiamento deve essere fatto sempre percepire come una opportunità di miglioramento, non come un disastro incombente!
La bravura dello sponsor del progetto e della terza parte è far percepire che il cambiamento è opportunità, tanto per l’azienda quanto per la singola risorsa: una opportunità di crescita e di miglioramento che consente di ampliare e aggiornare le competenze acquisite così come di apprenderne di nuove.
Fondamentale è l’atteggiamento che mostrano le persone di alto livello gerarchico e sponsor del progetto. Per la tanto cara regola del “dare l’esempio”, più i key user vedono i loro superiori come agenti attivi del cambiamento, più saranno motivati ed entusiasti.
È fondamentale fin da subito strutturare strumenti e momenti finalizzati a far prendere coscienza alle risorse dei vantaggi che già si stanno ottenendo dal progetto, in modo che siano consapevoli dei benefici di tutte le ore spese in prima persona per il progetto ERP.
4. Identità
Ogni realtà ha una sua identità. È importate per questo motivo non fare copia/incolla tout court di soluzioni e, per la terza parte, capire a fondo l’identità dell’azienda.
L’identità non è solo di processo (processi altamente personalizzati) ma anche culturale. Questo significa che gli stessi temi possono essere affrontati in modi diversi in contesti diversi. Ad esempio, a seconda della realtà, possono cambiare i criteri di selezione dei gruppi di lavoro per alcune fasi.
Per le realtà con una struttura fortemente cristallizzata risulterà funzionale creare i gruppi di lavoro selezionando persone che già lavorano a stretto contatto, mentre per realtà maggiormente “fluide” si possono strutturare gruppi interdisciplinari.
Se non si capisce a fondo la cultura aziendale vi è il rischio di un rigetto del sistema: la soluzione a livello tecnico è stata implementata ma a livello sociale e culturale non è stata accettata dalle persone, che continuano a utilizzare il vecchio sistema.
Comprendere l’identità dell’azienda significa evitare che l’implementazione sia un successo progettuale ma un fallimento aziendale.
Lavorare sui comportamenti è una chiave sicura che porta al successo.
Come ci insegna l’Habit Management, è fondamentale creare i giusti segnali e le giuste conseguenze affinché il progetto diventi un’abitudine piacevole e funzionale.
Quali possono essere i segnali? Un logo personalizzato per indicare il nome del progetto, un video motivazionale da lanciare prima di ogni workshop…
Più un segnale è potente, ossia fa sentire le persone che lavorano sul progetto parte di un gruppo, più l’accordo sociale che li lega e il loro commitment sarà forte.
5. Alleanza
L’implementazione non deve essere condotta da uno sparuto gruppo di risorse.
È un cambiamento che colpisce tutta l’azienda. Grazie alla comunicazione si crea engagement costante e quindi alleanza tra tutta la popolazione aziendale.
Più i benefici e gli obiettivi sono chiari, condivisi e apprezzati dal gruppo, più il team di progetto si muoverà unito, come una alleanza, verso una unica strada da percorrere insieme. Se sarà così, allora il successo sarà a portata di mano.
“In passato, l’istruzione costruiva identità solide come case di pietra. Oggi è necessario costruirle come tende da campeggio, da piegare e spostare”. – Yuval Harari
Come esplicita Harari, nel mondo di oggi, l’unico modo per fronteggiare in maniera funzionale i cambiamenti è quello di creare una struttura solida che sappia piegarsi alle difficoltà e non crollare.
Come fare questo in un progetto di implementazione di un nuovo gestionale?
Usate l’approccio Lenovys: costruite le fondamenta di questa struttura con G.I.O.I.A e convertite la vostra implementazione ERP da Esaurimento Risorse Possibile a Efficienza attraverso Risultati Pianificati.
Articolo a cura di:
Gianluca Ferrari
Partner e Executive Director Lenovys
Laureato in economia e psicologia clinica, ha maturato più di 20 anni di esperienza nel mondo della consulenza strategica e in particolare in progetti nazionali e internazionali di cambiamento organizzativo, talent acquisition, sviluppo della leadership, valorizzazione del potenziale. In qualità di Change Manager ha diretto progetti di definizione di modelli organizzativi funzionali al raggiungimento della strategia aziendale, di analisi degli impatti culturali dettati da ristrutturazioni societarie e passaggi generazionali. Ha lavorato nei settori del retail e dell’automotive, per aziende del lusso e della moda, per industrie meccaniche, siderurgiche, chimiche, di servizi e per banche e assicurazioni. Da Dicembre 2021 è partner Lenovys.
Profilo Linkedin dell'autore
Federico Visca
Senior Consultant Lenovys
Laureato in Psicologia del lavoro e delle organizzazioni, inizia la sua carriera professionale collaborando con l’università di Torino a diversi progetti organizzativi. In particolare, la creazione e l’implementazione di un sistema di Smart Working in Ferrero.
In Lenovys ha lavorato presso diversi clienti, di settori diversi, per il raggiungimento dell’eccellenza tecnica e operativa, coniugando la metodologia dell’Habit Management al framework Lean Lifestyle®.
Profilo Linkedin dell'autore