1. ERP Transformation: premessa

I progetti di ERP^[1] Transformation rappresentano per le aziende non solo un’opportunità strategica per aggiornare i propri sistemi informativi ma anche un’occasione irrinunciabile per evolvere i processi business da questi supportati.

La sostituzione di un ERP richiede importanti investimenti di risorse (non solo economiche) e uno sforzo collettivo di tutta l’organizzazione. Questa si deve infatti impegnare per mesi in un percorso di cambiamento che corre parallelo all’attività ordinaria, coinvolge molti attori di ogni funzione e mette in discussione processi codificati e abitudini consolidate ormai da anni.

[1] L’ERP, Enterprise Resource Planning (o cosiddetto “gestionale”), è il sistema che supporta l’automazione delle transazioni e dei processi core di un’azienda, garantisce l’integrità delle informazioni scambiate tra le funzioni aziendali (vendite, acquisti, magazzino, contabilità, ecc.) e ne permette il controllo delle attività.

2. I rischi in un progetto di ERP Transformation

I rischi in cui è possibile incorrere durante un progetto di trasformazione dell’ERP sono numerosi. Si possono classificare in 4 ambiti, ciascuno legato ad una fase di progetto:

• Fasi preparatorie di progetto:
  • Non allocare risorse adeguate alle ambizioni del progetto
  • Non identificare correttamente i needs che dovrebbero guidare la trasformazione
  • Non selezionare la tecnologia più idonea a coprire le esigenze e il partner più robusto cui affidarne l’implementazione

• Fasi di disegno e implementazione della nuova soluzione:
  • Non condurre un’analisi esaustiva per il ridisegno dei processi, valutando tutti gli impatti sul business e limitando quindi change request successive
  • Non cogliere l’occasione per innovare i processi, limitandosi invece a replicare configurazioni e modus operandi esistenti
  • Non verificare la completa corrispondenza tra quanto implementato e i requisiti definiti

• Gestione del go-live:
  • Non prevedere un percorso di formazione adeguato a rendere gli utenti confidenti con il nuovo sistema e con i nuovi processi operativi
  • Non garantire la continuità del business in fase di go-live
  • Sottovalutare la coda di attività post go-live (fatta di attività di supporto e fine-tuning)

• Organizzazione di progetto:
  • Non gestire il coordinamento tra le risorse, i tempi e le responsabilità di progetto
  • Non preparare in anticipo l’organizzazione al cambiamento, accompagnando il percorso di trasformazione di sistemi, processi e modalità di lavoro

3. Ridurre i rischi progettuali

Per le aziende che approcciano un progetto di evoluzione dell’ERP (sostituzione o upgrade tecnologico della stessa soluzione a versioni successive), è opportuno valutare quali interventi sia possibile mettere in atto per minimizzare i rischi di progetto. Per essere efficaci, tali interventi devono interessare quattro diversi ambiti – strategia aziendale, processi, tecnologia e persone –e assicurare tra questi il pieno allineamento. Per tutti i progetti di trasformazione, maggiore è l’integrazione tra queste quattro aree e maggiore sarà la probabilità di successo.

In particolare, l’obiettivo della strategia è traslare il business nell’IT, sfruttando le tecnologie per abilitare nuovi processi. La strategia deve quindi indicare i macro-obiettivi della trasformazione, definire il modello target, delineare i contorni dell’evoluzione dei sistemi e del business in una visione pluriennale.

I processi devono evolvere tendendo all’innovazione, anziché alla duplicazione, e all’adozione delle best practice già consolidate negli standard ERP, verso cui massimizzare la convergenza.

Nella tecnologia, il fattore chiave è rappresentato dalla scelta di soluzioni mature in grado di coprire perfettamente i processi core distintivi.

Per quanto riguarda le persone (ovvero l’insieme di organizzazione, competenze e comportamenti), il fattore determinante è rappresentato dalla gestione del cambiamento e dalla stimolazione all’adozione di nuove tecnologie, processi, modalità di lavoro.

Gli interventi a riduzione dei rischi progettuali devono essere previsti lungo l’intera durata del processo di trasformazione, ed interessare ciascuna fase di progetto.

Possiamo identificare 7 macro-fasi di progetto, cui corrispondono altrettante aree di intervento, ognuna collegata agli ambiti sopracitati – strategia, processi, tecnologia e persone – e contraddistinta da uno specifico output.

1. Strategia. Predisposizione di un piano di integrazione business/IT. L’attività preliminaread ogni progetto ERP deve coincidere con la definizione e validazione dei nuovi obiettivi business (abilitazione di nuovi processi, capabilities, modelli di business), del nuovo piano IT a supporto (nuova architettura sistemi, nuovo portafoglio progetti, nuova allocazione delle risorse necessarie), nonché la valutazione del ritorno sugli investimenti previsti. L’output di questa fase è un documento noto come Target Operating Model (TOM), che descrive gli obiettivi e le linee guida del programma di trasformazione e serve ad indirizzare senza incertezze le successive fasi di progetto.

2. Processi. Analisi preliminare focalizzata sui processi core. L’analisi degli attuali processi, delle criticità e della loro integrazione nei sistemi è la base per la definizione dei business requirements che devono guidare la software selection. È opportuno concentrare quest’analisi sui processi core distintivi del business, su cui saranno principalmente valutate le capacità di copertura funzionale delle soluzioni vagliate. L’output di questa fase è un documento noto come Request for Proposal (RFP), che viene condiviso con i software vendor e descrive i requisiti minimi ricercati nella nuova soluzione ERP.

3. Tecnologia. Software selection e System Integrator selection. Questa fase deve condurre alla selezione della soluzione tecnologica e del System Integrator, alla definizione del programma di implementazione e di organizzazione del progetto e alla negoziazione dei termini contrattuali. Per supportare il raffronto tra le soluzioni e i partner proposti, e motivare l’oggettività della scelta, è opportuno utilizzare una Matrice di Valutazione con cui assegnare dei punteggi ai parametri valutati (es. grado di copertura funzionale sui processi core, tecnologia, capacità evolutiva, TCO, referenze del software, referenze del System Integrator, ecc.).

4. Processi. Definizione del modello da implementare e ridisegno dei processi (BPR). Questa fase deve condurre alla revisione del modello dati e dei processi business as-is alla luce delle funzionalità standard proposte dalla soluzione ERP scelta. Richiede una profonda analisi di dettaglio dei processi attuali ed il loro ridisegno in ottica di innovazione, adozione di best practice e convergenza allo standard ERP. La nuova organizzazione del modello dati e i nuovi processi sono descritti in un documento noto come Business Blueprint (BBP), che rappresenta per il System Integrator la validazione della configurazione da dare alla soluzione ERP, e per l’azienda una garanzia del risultato atteso.

5. Tecnologia. Implementazione della soluzione. Questa fase conduce all’implementazione tecnico-funzionale dell’ERP e include le attività di migrazione dati e di validazione da parte degli utenti della configurazione così come descritta in BBP. Quest’ultima attività, nota come User Acceptance Test (UAT), è di fondamentale rilevanzaper certificare la validità del comportamento del sistema e l’allineamento tra quanto implementato e i requisiti definiti. È quindi opportuno che sia preparata con attenzione disegnando in anticipo dei test case completi.

6. Persone. Project Management. In contesti complessi come quelli di ERP Transformation, le attività di Project Management sono fondamentali per assicurare il controllo sull’avanzamento di progetto, il coordinamento delle attività e delle risorse a disposizione, l’allineamento tra obiettivi attesi ed implementazione del sistema. Quella del Project Management è un’attività ininterrotta ma che trova la sua massima espressione nell’organizzazione degli Steering di progetto, momenti in cui poter elevare all’attenzione dei comitati direzionali eventuali criticità, la necessità di decisioni strategiche o di interventi straordinari.

7. Persone. Piano di comunicazione e di change. Infine, l’ultimo fattore critico di successo del progetto è rappresentato dall’attività di comunicazione e di accompagnamento al cambiamento. Questa include l’onboarding del management e degli utenti, la comunicazione di obiettivi, progressi, responsabilità e rischi di progetto, l’analisi e l’anticipazione degli impatti (su processi, organizzazione, ruoli, competenze) derivanti da nuove attività e responsabilità, la conseguente identificazione di mitigation actions, l’organizzazione della formazione e la review degli impatti e delle soluzioni nel post go live.

4. Conclusioni

I progetti di ERP Transformation si possono accompagnare ad elevati rischi di insuccesso se non correttamente governati. In fase di start up di progetto, è bene considerare quali interventi poter introdurre per disinnescare tali rischi. Tali interventi richiedono però risorse (disponibilità di tempo e persone) e competenze (precedenti esperienze su progetti analoghi) che spesso non sono disponibili all’interno dell’azienda.

In questi casi, la figura cui l’azienda può rivolgersi è quella del Business Integrator, ovvero di un consulente in grado di supportare i processi di trasformazione con un forte contributo specialistico business, affiancando il management nelle attività di coordinamento delle fasi e risorse di progetto, impegnandosi in una verifica continua dell’allineamento tra obiettivi strategici e implementazione del nuovo sistema, e contribuendo con metodologia e programmazione al conseguimento dei risultati attesi nei tempi previsti.