La gestione di un progetto ERP è spesso paragonata alla costruzione di una nave in alto mare: bisogna mantenere la rotta strategica regolando al contempo le vele di fronte ai venti mutevoli delle esigenze aziendali. In questo contesto, la gestione del budget non può più limitarsi a una semplice sorveglianza contabile a posteriori. Deve diventare uno strumento di navigazione predittivo.
Tradizionalmente, i progetti ERP seguivano un approccio lineare, detto a "cascata". Si definiva un budget globale, si realizzava una lunga fase di analisi, poi di configurazione, per consegnare infine il prodotto finito. Questo modello ha mostrato i suoi limiti: le derive di budget venivano riscontrate solo a fine percorso, spesso troppo tardi per essere corrette. Oggi l'agilità si impone, trasformando il monitoraggio del budget in una struttura tridimensionale in cui si incrociano i domini funzionali, i cicli di produzione e, ormai, la temporalità degli sprint.
Ecco la metodologia che utilizzo per strutturare, inserire e pilotare il budget dei miei progetti, basandomi su un'architettura di dati rigorosa e strumenti di pilotaggio visivo semplici.
I. La fondazione strategica: La segmentazione per domini funzionali
Tutto inizia con una decostruzione analitica del perimetro. Un progetto ERP non è un'entità monolitica, ma una collezione di moduli interdipendenti. La prima fase consiste quindi nell'effettuare una suddivisione "top-down" basata sui domini funzionali.
Questa segmentazione permette di attribuire un budget "a grandi linee" fin dalla firma del contratto o dell'ordine iniziale. Infatti, la quantità globale di giorni da distribuire è un dato contrattuale. Il ruolo del project manager è quello di ventilare questo pacchetto globale per dare una realtà operativa al contratto.
Si definiscono così i codici dei domini:
- A00 – Contabilità Generale: Il pilastro finanziario.
- B00 – Contabilità Clienti (O2C): I flussi di ricavi.
- C00 – Contabilità Fornitori (P2P): I flussi di spesa.
- D00 – Contabilità Bancaria e Tesoreria: La gestione dei flussi di liquidità.
- E00 – Gestione Scorte e Logistica: La catena operativa.
- Ecc …
A ogni dominio viene assegnata una quota del budget totale. Questa ripartizione iniziale, utile, serve unicamente a stabilire una stima del carico di lavoro, ed è inoltre cruciale per responsabilizzare i consulenti esperti sul proprio perimetro.
Se la Contabilità Generale dispone di 40 giorni, il consulente sa di dover orchestrare i propri interventi entro tale limite, pena la necessità di richiedere un arbitraggio di budget al comitato di progetto.
II. La Dimensione temporale: L'integrazione degli sprint
Contrariamente al vecchio metodo sequenziale, il progetto ERP contemporaneo adotta il ritmo degli Sprint. Uno sprint è un'iterazione breve, generalmente da due a quattro settimane, volta a consegnare una porzione funzionale dell'ERP pronta per essere testata.
L'introduzione dello sprint nel budget cambia radicalmente il modo in cui si considera il consumo dei giorni. Non si alloca più solo il budget al dominio funzionale (es: alla "Contabilità Generale") in modo astratto per tutta la durata del progetto, ma si alloca il budget allo Sprint 1 del dominio Contabilità Generale.
Questo approccio permette di frammentare il rischio. Se un dominio si rivela più complesso del previsto, la deriva sarà identificata alla fine del primo sprint, e non sei mesi dopo. Il budget diventa così dinamico: viene consumato a ondate successive, permettendo una riallocazione tra gli sprint se alcune funzionalità si rivelano più semplici o più complesse di quanto inizialmente previsto. È questa nozione di sprint che definisce ormai la struttura stessa della codifica del budget, poiché impone una visione temporale dell'avanzamento.
Non bisogna tuttavia confondere la preventivazione (in termini di giorni di lavoro) di un dominio funzionale con la pianificazione del progetto, né tantomeno con la pianificazione degli sprint del dominio funzionale. Uno sprint può coinvolgere un numero variabile di risorse che consumeranno un numero variabile di giorni di lavoro.
III. Il ciclo di produzione: Dall’analisi all'avvio
All’interno di ogni dominio funzionale e per ogni sprint, la metodologia impone il rispetto di un ciclo di produzione standardizzato. Questo ciclo è il garante della qualità tecnica e funzionale. A seconda della complessità, questo ciclo può essere breve (implementazione con configurazione standard) o lungo (implementazione di funzionalità specifiche da sviluppare).
Per ogni dominio, si scompone il lavoro in fasi codificate, creando così il terzo livello della nostra struttura di budget.
Sprint con ciclo di produzione lungo:
- 100 – Analisi: Comprensione delle esigenze e redazione dei processi target.
- 200 – Presentazione Mockup: Validazione intermedia con gli utenti chiave.
- 300 – Configurazione: Configurazione delle funzionalità standard dell'ERP.
- 400 – Sviluppo: Creazione di funzionalità specifiche o interfacce (i "personalizzati").
- 500 – Test e Collaudo: Verifica della conformità della soluzione.
- 600 – Formazione: Trasferimento di competenze agli utenti finali.
- 700 – Assistenza all'avvio: Supporto critico durante la messa in produzione.
Sprint con ciclo di produzione breve:
- 100 – Analisi: Comprensione delle esigenze e redazione dei processi target.
- 200 – Presentazione Mockup: Validazione intermedia con gli utenti chiave.
- 300 – Configurazione: Configurazione delle funzionalità standard dell'ERP.
- 500 – Test e Collaudo: Verifica della conformità della soluzione.
- 600 – Formazione: Trasferimento di competenze agli utenti finali.
- 700 – Assistenza all'avvio: Supporto critico durante la messa in produzione.
💡La migrazione dei dati non è una fase di uno sprint per un dominio funzionale, va considerata come un progetto nel progetto. Vanno definiti un budget secondario con i propri domini funzionali, i propri sprint e le proprie fasi.
Esempio di fasi del sottoprogetto di migrazione dati:
- Analisi dei dati sorgente
- Progettazione dell'estrazione dati
- Migrazione dei dati
- Test e controlli
Assegnando un budget in giorni a ogni fase di ogni dominio e a ogni sprint, si ottiene una precisione chirurgica. Si può quindi dire: "Il dominio A00 dispone di 3 sprint da 5 giorni ciascuno".
Il fatto di numerare ogni fase con 3 caratteri permette di definire maggiori dettagli nei cicli, se necessario. Ad esempio, la fase di analisi potrebbe essere suddivisa in:
- 110, Workshop di raccolta requisiti,
- 120, Redazione dei documenti di analisi,
- 130, Revisione e restituzione al cliente
Questo dettaglio complica l’assegnazione e la riallocazione del budget, ma anche l’inserimento dei tempi da parte del team di progetto.
IV. La codifica analitica: Il linguaggio comune del progetto
Affinché questo sistema funzioni, occorre un identificativo unico in grado di legare il budget e i tempi spesi per calcolare l'avanzamento. È il ruolo del “Codice budget concatenato”.
Il codice è formato dall’unione del codice dominio, del codice sprint e del codice fase. Ad esempio: A00-S1-100.
- A00: Contabilità Generale.
- S1: Sprint numero 1.
- 100: Fase di analisi.
Questa chiave unica è il perno di tutto il sistema. Permette di imputare ogni ora di lavoro a una precisa cella di budget. Più il progetto è complesso, più i codici possono essere precisi, in particolare per gli sviluppi specifici dove possono essere creati sottocodici per isolare ogni richiesta di modifica software.
V. Metodologia di inserimento del budget: Il riferimento "Scritture Contabili Budget"
È importante notare che, nonostante l’assenza di un software di gestione progetto specializzato o di uno strumento di monitoraggio budget, è possibile effettuare il monitoraggio su Excel.
Excel: “i pro”:
La flessibilità di Excel permette di costruire un sistema su misura, spesso più agile e meglio adattato alle realtà di un'implementazione ERP. Questa infrastruttura sostitutiva poggia su tre pilastri documentali fondamentali:
- Un foglio dedicato all'inserimento iniziale del budget che valorizza i codici budget,
- Un foglio di raccolta dei tempi spesi per catturare la realtà sul campo,
- Un foglio dashboard di monitoraggio dell'avanzamento che garantisce la riconciliazione automatica e visiva dei dati.
Questa architettura trasforma un semplice foglio di calcolo in un vero centro di pilotaggio decisionale.
Excel: “i contro”:
Per i grandi progetti che comportano molti giorni di implementazione, risorse, sprint e domini funzionali, un semplice foglio di calcolo può diventare presto pesante da manipolare e la perdita di dati può essere irreparabile.
La mia esperienza personale mi permette di dire che progetti da 1000 giorni di implementazione, suddivisi sul lavoro di 10 persone, articolati in 10 domini funzionali e 3 sprint ciascuno, sono il limite da non superare con un semplice file Excel.
La fase di inserimento iniziale del budget è il momento in cui si definiscono le regole del gioco. Questa operazione viene eseguita in un foglio Excel denominato "Scritture Contabili Budget".
Il funzionamento tecnico di SOMMA.PIÙ.SE
La sfida qui non è semplicemente digitare numeri nelle caselle, ma costruire un database di budget. Ogni allocazione di budget è una registrazione con una data, un dominio, uno sprint, una fase e una quantità di giorni.
Per consolidare questi dati in una dashboard, si utilizza la potenza della funzione Excel SOMMA.PIÙ.SE (o SUMIFS). Questa funzione permette di sommare i giorni che costituiscono il budget in base a diversi criteri simultanei.
- Formula tipo: =SOMMA.PIÙ.SE(Colonna_Giorni; Colonna_Dominio; "A00"; Colonna_Sprint; "S1"; Colonna_Fase; "100").
- Formula tipo: =SOMMA.PIÙ.SE(Colonna_Giorni; Colonna_Dominio; "A00"; Colonna_Sprint; "S1"; Colonna_Fase; "100").
Questo metodo presenta un vantaggio maggiore: la tracciabilità. Se il budget di un dominio aumenta a seguito di un addendum, così come se fosse necessaria una riallocazione di una parte del budget a un altro codice budget, non si modifica la cifra esistente. Si aggiunge una nuova riga di scrittura budget con la data del giorno e la quantità di giorni (in aumento o in diminuzione). La funzione SOMMA.PIÙ.SE cumulerà automaticamente il vecchio e il nuovo budget, permettendo così di mantenere uno storico completo delle decisioni finanziarie del progetto. Si può così sapere in quale data un budget è stato aumentato o ridotto.
VI. La realtà sul campo: Inserimento dei tempi e imputazioni
Una volta definito e inserito il budget, il progetto entra nella sua fase di esecuzione. L'affidabilità del monitoraggio riposa quindi sulla qualità dell'inserimento dei tempi da parte dei collaboratori (consulenti, sviluppatori, project manager). Questo dato viene raccolto nel foglio "Tempi Reali".
L'imputazione sul Codice Budget
Il collaboratore non scrive "Ho lavorato sulla contabilità". Seleziona, idealmente tramite un elenco a discesa, il “Codice Budget Concatenato” (es: B00-S2-200 per la configurazione della contabilità clienti nello Sprint 2).
L'imputazione avviene generalmente in ore, che vengono poi convertite in giorni dal sistema (es: 7h = 1 giorno). La precisione di questa fase è fondamentale. Se un consulente dedica 4 ore a un'analisi e 3 ore alla configurazione, deve suddividere il suo tempo sui due codici corrispondenti. L'esperienza insegna che le risorse più esperte sono anche quelle che passano da un progetto all'altro durante la stessa giornata lavorativa; è quindi cruciale poter tracciare le ore trascorse sul progetto.
È questo rigore nell'imputazione che permette di confrontare il "consumato" con il "preventivato". Senza un codice budget rigoroso, il monitoraggio si perde in approssimazioni semantiche che rendono impossibile l'analisi degli scostamenti. Questo foglio dei tempi reali diventa il diario di bordo quotidiano dello stato di salute del progetto.
VII. Il Dashboard visivo: Pilotare l'avanzamento attraverso le immagini
La fase finale della metodologia è la restituzione delle informazioni. Il foglio "Avanzamento per Dominio e Fase" centralizza i calcoli, ma è il Dashboard Visivo che permette la presa di decisioni. L'obiettivo è trasformare colonne di numeri in indicatori di prestazione (KPI) immediatamente comprensibili.
1. Il termometro di consumo per dominio
Utilizzo barre di avanzamento verticali per illustrare il rimanente da consumare attraverso la differenza visiva tra l'altezza totale di un blocco (budget allocato) e la sua parte colorata (consumato reale), permettendo di identificare immediatamente i margini residui. Osservando la profondità dell'asse Z, si individua se il budget di un dominio si esaurisce troppo presto nella sequenza degli sprint rispetto alle fasi ancora da compiere.
Functional domain on phase
2. La matrice "Fase vs Sprint" (Heatmap)
Questa tabella permette di vedere dove si concentra lo sforzo. Vi si visualizza il rapporto Consumato / Budget per fase. Se si nota che la fase "Analisi" (100) è già al 95% di consumo a metà dello Sprint 1, la dashboard avvisa visivamente del rischio di superamento per le successive fasi di configurazione.
Phases on one Functional domain
3. L'Analisi del rimanente da fare (RAF)
È l'indicatore più prezioso. La dashboard calcola la differenza tra il budget allocato e il consumato reale. Ma integra anche un inserimento manuale da parte del consulente: il "Rimanente da Fare stimato".
- Se Budget - Consumato > RAF: Il progetto è in attivo, stiamo generando margine.
- Se Budget - Consommé < RAF: Siamo in una situazione di perdita latente.
Visivamente, ciò si traduce in un grafico di atterraggio (Forecast) che mostra la probabile traiettoria del budget alla fine del progetto. Se la curva di atterraggio supera il tetto del budget, il project manager dispone di una prova fattuale per avviare discussioni sul perimetro o sulle risorse.
Per concludere questo articolo, vorrei precisare che questa metodologia, sebbene robusta poiché la utilizzo da diversi anni, non è fine a se stessa. Costituisce la base fondamentale che permette di misurare l'avanzamento in modo affidabile, ma rimane ampiamente perfezionabile ed evolutiva.
Questo modello può essere affinato per adattarsi ai profili dei partecipanti. Ad esempio, alcune risorse specializzate sono contrattualmente o tecnicamente associate a un'unica fase (come i programmatori puri o i formatori). Per questi profili, si può immaginare una semplificazione dell'inserimento dei tempi: un'interfaccia in cui il codice budget è precompilato, limitando così il rischio di errore e aumentando l'adesione dei team allo strumento di rilevazione.
Per motivi di chiarezza, ho descritto solo la struttura di base. In una gestione di progetto industriale, la scomposizione degli sviluppi specifici guadagna dall'essere collegata direttamente alle User Stories (US) e ai Task presenti nello strumento di gestione ticket del progetto (come Azure DevOps o Jira). Il passo successivo consisterebbe nel creare un ponte tra il file Excel e il backlog tecnico per garantire una perfetta coerenza tra l'avanzamento funzionale e il consumo del budget.
Infine, un tema importante è stato solo accennato: la fatturazione. È tuttavia l'ago della bilancia della redditività. Confrontare l'avanzamento reale (ciò che è stato prodotto) con la fatturazione (ciò che è stato riconosciuto dal cliente) è l'esercizio finale del project manager. Questo confronto permette di anticipare situazioni critiche, come un "lavoro non ancora fatturato" (WIP) troppo elevato o, al contrario, anticipi sulla fatturazione che mascherano un ritardo di produzione.
Tratterò questi argomenti avanzati (integrazione DevOps, automazione dell'inserimento e riconciliazione fatturazione/avanzamento) nei miei prossimi articoli.
In breve, in un mondo in cui i progetti ERP sono noti per la loro complessità e le loro derive, è necessario trovare un approccio di pilotaggio affidabile. Questo pilotaggio garantisce che ogni ora trascorsa dai consulenti sia una pietra aggiunta in modo ordinato all'edificio, nel rispetto della redditività dell'azienda e della soddisfazione del cliente finale. Il controllo del budget non è più quindi un vincolo, ma il motore stesso del successo dell'implementazione.
File Excel di esempio