GAP analysis: un progetto ERP si decide nelle prime conversazioni

In Italia, secondo stime ricorrenti nel settore, il 67% delle PMI non riesce a implementare con successo un sistema ERP e circa un progetto su due fallisce integralmente al primo tentativo. Numeri pesanti, che raccontano budget bruciati, team demotivati e gestionali abbandonati dopo pochi mesi. Eppure, quando si va a vedere dove nasce il problema, raramente la colpa è del software.

La quasi totalità di questi fallimenti si origina prima, nella gap analysis: il momento in cui si confronta lo stato attuale dell'azienda con quello desiderato. Le funzionalità si possono aggiungere, i moduli si possono configurare. Un requisito frainteso al primo incontro, invece, si trascina fino al go-live e lì costa caro.

Cosa si intende davvero per gap analysis

Semplificando, la gap analysis confronta due fotografie. La prima è lo stato attuale, l'As-Is: come l'azienda gestisce oggi ordini, magazzino, acquisti, fatturazione, persone. La seconda è lo stato desiderato, il To-Be: come quei processi dovrebbero funzionare con il nuovo sistema. Il gap è la distanza tra le due.

Se vogliamo un paragone, la gap analysis è il business plan del nuovo ERP. Stabilisce da dove si parte, dove si vuole arrivare, quanto costa colmare la distanza e cosa si ottiene in cambio. È qui che si decide se il progetto avrà un ROI positivo o diventerà uno spreco di budget.

Nei progetti ERP questa distanza si misura rispetto a uno strumento concreto. Parliamo allora di fit-gap analysis: per ogni esigenza si verifica se il gestionale la copre già (fit) o se serve un intervento (gap). Con Odoo, ad esempio, ogni requisito finisce in una di queste categorie:

• Standard: la funzionalità esiste ed è sufficiente usarla.
• Configurazione: si ottiene con impostazioni, regole, automazioni o campi personalizzati, senza scrivere codice.
• Sviluppo custom: serve un modulo o un'estensione dedicata.
• Integrazione: il dato vive in un altro sistema (un eCommerce, un software paghe, un portale fornitori) e va collegato.
• Cambio di processo: l'esigenza si risolve modificando il modo di lavorare, non il software.

L'ultima voce è quella che si dimentica più spesso. Ed è anche quella che fa risparmiare di più.

Perché il primo contatto pesa così tanto

Il primo approccio con il lead è il momento in cui si stabilisce come verrà raccolta la conoscenza dell'azienda. E qui si annida uno dei fattori di fallimento più frequenti: lo scollegamento tra fase commerciale e fase tecnica.

Succede così. La prima call diventa una demo, il cliente vede funzionalità che gli piacciono, i moduli vengono scelti sulla base di quella promessa. Nessuno però ha ancora confrontato i manuali operativi dell'azienda con le reali specifiche del sistema. Il gap strutturale emerge dopo, magari durante l'analisi di un flusso B2B con listini e condizioni particolari, quando il contratto è già firmato e le aspettative sono già fissate.

Se invece la prima conversazione serve ad ascoltare, il cliente comincia a raccontare i propri processi, con i loro punti deboli. Per noi questo significa portare competenze di analisi già al primo incontro, senza delegare tutto a una fase successiva.

C'è poi un aspetto di fiducia. Un'azienda che sta valutando un nuovo gestionale spesso arriva da un'esperienza negativa, o da anni di fogli Excel che nessuno ha il coraggio di toccare. Sentirsi fare le domande giuste, fin dall'inizio, è ciò che distingue un fornitore da un partner.

Cosa chiedere nella prima conversazione

La prima call non deve esaurire l'analisi. Deve però far emergere abbastanza informazioni per capire la dimensione del progetto e chi va coinvolto. Nella nostra esperienza le domande che aprono di più sono anche le più semplici:

1. Perché adesso? Cosa è successo che ha reso urgente cambiare sistema: una crescita, un'acquisizione, un fornitore software che dismette il prodotto, un obbligo normativo.
2. Cosa non funziona oggi, e quanto costa? Meglio chiedere numeri che giudizi. "Ci mettiamo due giorni a chiudere il mese" dice molto più di "il gestionale è lento".
3. Quali strumenti usate? Gestionale attuale, file condivisi, software verticali, app di reparto. Ogni strumento è un potenziale punto di migrazione o integrazione.
4. Chi usa i dati e chi li produce? Spesso chi decide l'acquisto non è chi inserisce gli ordini. Servono entrambi.
5. Cosa deve assolutamente continuare a funzionare dal primo giorno? È la domanda che fa emergere i processi critici, quelli su cui non si può sbagliare.

Da queste risposte si capisce già se il progetto è principalmente di configurazione o se ci sono aree in cui servirà sviluppo o integrazione. Ma si capisce soprattutto con chi parlare dopo.

I primi processi che si mettono in atto

Dopo il contatto iniziale, la gap analysis diventa un lavoro strutturato. Procediamo per gradi.

Kick-off e raccolta dei dati

Si parte da un incontro con i referenti dell'azienda in cui si concordano perimetro, tempi e persone da coinvolgere. Nello stesso momento si chiede il materiale esistente: procedure scritte (se ci sono), export dal gestionale attuale, modelli di documenti, report usati dalla direzione.

Ma non solo: servono dati di partenza misurabili. Fatturato per canale, tempi medi di evasione di un ordine, giorni necessari per la chiusura contabile, numero di errori in fatturazione, rotazione del magazzino. Senza questi numeri è impossibile calcolare il gap reale, e sarà altrettanto impossibile dimostrare a fine progetto che l'investimento ha reso.

Interviste e workshop, dall'alto e dal basso

Qui il Business Analyst incontra i singoli reparti: vendite, acquisti, magazzino, produzione, amministrazione, HR. I progetti che funzionano lavorano su due livelli contemporaneamente. Il top-down, con la leadership, definisce vision, obiettivi e budget. Il bottom-up, con gli esperti operativi, cioè chi inserisce fisicamente i dati ogni giorno, restituisce i flussi di lavoro reali e non quelli teorici scritti nelle procedure.

Il formato migliore è misto. Le interviste individuali fanno emergere le abitudini e i "trucchi" quotidiani; i workshop con più reparti mostrano dove i processi si passano la palla, ed è lì che si nascondono gli errori. Una regola pratica: chiedere di mostrare, non solo di raccontare. Vedere un operatore evadere un ordine sullo schermo vale più di mezz'ora di descrizione.

Mappatura As-Is con dati e analisi delle cause

Le informazioni raccolte diventano una mappa dei processi attuali, con attori, passaggi, documenti e sistemi coinvolti. La mappa deve reggersi sui numeri raccolti nel kick-off. Un As-Is costruito sulle sensazioni dei manager ("siamo lenti a fatturare") non permette di misurare nulla e porta a soluzioni sbagliate.

C'è poi un secondo livello, quello che distingue un'analisi utile da un semplice elenco di lamentele: la root-cause analysis. Rilevare che "il magazzino è inefficiente" è un sintomo. Capire perché lo è richiede metodo. Strumenti come i 5 perché o il diagramma di Ishikawa aiutano a stabilire se la causa è il software vecchio, il personale non formato o un processo logistico impostato male. Sono tre problemi diversi, e solo il primo si risolve davvero cambiando gestionale.

Definizione del To-Be con obiettivi SMART

Si disegna il processo futuro, sfruttando il più possibile quello che il gestionale offre in modo nativo. È il passaggio più delicato, perché richiede di separare i requisiti dalle abitudini. "Abbiamo sempre stampato il DDT prima di preparare il collo" può essere un vincolo reale oppure un residuo di come funzionava il vecchio software.

Il To-Be va poi tradotto in traguardi SMART: specifici, misurabili, raggiungibili, rilevanti e definiti nel tempo. "Migliorare le vendite" non è un obiettivo. "Aumentare il tasso di chiusura dal 15% al 20% entro dodici mesi integrando un sistema di lead scoring nel CRM" lo è, perché dice cosa cambia, di quanto e con quale strumento.

Matrice fit-gap e prioritizzazione

Ogni requisito viene classificato secondo le categorie viste sopra e ordinato per priorità. Un metodo semplice e diffuso è il MoSCoW: must have, should have, could have, won't have (per ora).

Qui serve una prioritizzazione spietata. I risultati migliori arrivano quando il piano d'azione affronta per primi i gap critici con il maggiore impatto su margini ed efficienza, rimandando il resto. La matrice diventa così leggibile anche dalla direzione: mostra cosa è coperto dallo standard, cosa richiede configurazione, dove si concentra l'effort di sviluppo e quale ritorno ci si aspetta da ogni intervento.

Il documento finale e il piano per fasi

La gap analysis si chiude con un documento condiviso che diventa la base del progetto: processi To-Be, elenco dei gap con la soluzione proposta, integrazioni necessarie, rischi, KPI di riferimento, stima di tempi e costi.

Da qui si costruisce un rilascio per fasi. L'approccio big bang, cioè colmare tutte le lacune individuate contemporaneamente, mette sotto pressione l'intera organizzazione e genera rigetto nel team. Partire dalle aree a maggior impatto, consolidarle e poi estendere il sistema permette alle persone di adattarsi e al progetto di dimostrare risultati concreti fin dai primi mesi.

Dove si perde il budget

Mettendo insieme la nostra esperienza sui progetti e il confronto con altri professionisti del settore, i pattern di fallimento sono sorprendentemente ricorrenti. Alcuni li abbiamo già visti: la distanza tra promessa commerciale e verifica tecnica, un As-Is fatto di opinioni, l'assenza di analisi delle cause, il big bang. Altri sono più sottili.

Il primo è saltare la gap analysis per fare prima. Il risparmio è apparente: il tempo non investito all'inizio si recupera con gli interessi durante i test, quando ogni correzione coinvolge configurazioni già fatte e persone già formate.

Poi c'è la tentazione di replicare il vecchio sistema dentro quello nuovo. Un ERP moderno come Odoo ha una logica propria, costruita su processi standard che funzionano per migliaia di aziende. Personalizzare tutto per riprodurre le schermate di prima significa pagare di più per ottenere meno, e rendere più complessi gli aggiornamenti futuri.

L'ultimo errore è considerare la gap analysis un documento chiuso. I requisiti evolvono, soprattutto nei progetti lunghi. La matrice fit-gap va tenuta viva e aggiornata, perché è anche lo strumento con cui si governano le richieste di modifica.

La gap analysis come strumento di adozione

Un gestionale può essere configurato alla perfezione e fallire comunque, se le persone non lo usano. Per questo conviene trattare la gap analysis quasi come una campagna di comunicazione interna. Deve convincere gli stakeholder che il cambiamento vale la fatica, deve risolvere i pain point che le persone vivono davvero ogni giorno, deve avere KPI chiari su cui misurare i progressi.

Quando un magazziniere vede che il problema di cui si lamenta da anni è finito in cima alla lista delle priorità, diventa il primo sostenitore del progetto. Quando la direzione vede i numeri di partenza accanto agli obiettivi SMART, sa esattamente cosa sta comprando.

Dove entra l'intelligenza artificiale

Negli ultimi progetti una domanda ricorre sempre più spesso già al primo contatto: "possiamo usare l'AI?". La gap analysis è il posto giusto per rispondere, perché permette di individuare i passaggi ripetitivi e ad alto volume (classificazione di documenti in ingresso, estrazione di dati da ordini e fatture, supporto al servizio clienti) dove l'automazione ha un ritorno misurabile. Partire dai processi, e non dallo strumento, evita di introdurre l'AI dove non serve.

Un progetto ERP ben avviato si riconosce da una cosa: alla fine della gap analysis il cliente conosce la propria azienda meglio di prima. Se vuoi capire da dove partire con i tuoi processi, e dove Odoo e l'AI possono fare davvero la differenza, prenota un appuntamento gratuito con il nostro team.