Mantenere la Continuità del Reporting Durante una Migrazione ERP

Una migrazione ERP è raramente un evento singolo. C’è una fase di selezione che può durare da sei a dodici mesi prima che qualcuno firmi qualcosa, seguita da un’implementazione che tipicamente si estende da dodici a ventiquattro mesi, dal kickoff a un sistema che fa effettivamente girare l’azienda giorno per giorno. Finance non può mettere in pausa il reporting per nulla di tutto questo. Il board pack resta dovuto ogni mese, i revisori si presentano comunque secondo il calendario, e da qualche parte nel mezzo di una migrazione, metà dei dati rilevanti per la finanza risiede nel vecchio sistema, un’altra parte nel nuovo, e nessuno dei due è pienamente affidabile da solo.

Quel divario, tra “abbiamo iniziato a migrare” e “il nuovo ERP è completamente operativo e pulito”, è dove il reporting si rompe silenziosamente. Non perché qualcuno abbia sbagliato qualcosa, ma perché la maggior parte degli strumenti di reporting è costruita per collegarsi a un solo sistema, e una migrazione significa non avere un solo sistema per buona parte di due anni.

Perché la fase intermedia di una migrazione è la parte pericolosa

Il fallimento di solito non avviene al go-live. Il go-live viene pianificato, testato e presidiato con il personale adeguato. Il tratto pericoloso sono i mesi prima e dopo: il vecchio ERP viene progressivamente dismesso e nessuno vuole più investire lavoro di integrazione su di esso, il nuovo non è ancora pienamente configurato, e finance resta bloccata a riconciliare manualmente due quadri parziali. Se il tuo reporting dipende da un connettore live a un unico ERP, una migrazione impone una scelta tra fare reporting da un sistema che sai essere in via di dismissione oppure da uno che non è ancora pronto.

C’è anche una dimensione di costo che vale la pena nominare. Gli ERP legacy, sistemi in uso da più di dieci-dodici anni, pesantemente personalizzati, senza API moderne e senza roadmap cloud, sono costosi da integrare correttamente, e quando più di questi segnali d’allarme si sommano, un progetto di connettore diretto sistema-a-sistema può smettere di avere senso dal punto di vista economico. È esattamente la situazione che una migrazione è pensata per risolvere, ma è anche esattamente la situazione attraverso cui stai facendo reporting mentre la soluzione è in corso.

Disaccoppiare il reporting dalla decisione ERP

La risposta pratica è smettere di far dipendere il reporting mensile dall’avere un unico ERP finito e pienamente connesso in funzione. Il percorso di ingestione di Rexfin lavora a partire da esportazioni di file, un bilancio di verifica o un estratto contabile in un foglio di calcolo, il che aggira la dipendenza dalle API che blocca gli strumenti di reporting costruiti solo per connettori diretti. Un’esportazione pulita da un sistema legacy è un input utilizzabile anche mentre quel sistema è in via di dismissione, e lo stesso vale per un’esportazione da un nuovo ERP ancora in fase di configurazione. Il livello di reporting non ha bisogno che nessuno dei due sistemi sia completato; ha bisogno di un file che possa mappare, ogni mese, nello stesso modello riconciliato.

Questo conta in particolare durante una migrazione perché significa che il passaggio dal vecchio sistema al nuovo non deve essere anche un cambiamento nel modo in cui finance fa reporting. La mappatura del piano dei conti che collega le tue cifre alle linee consolidate resta compito del modello, non qualcosa da ricostruire il giorno in cui il nuovo ERP va live. Una volta che il nuovo sistema si stabilizza e un connettore nativo diventa sensato, quella diventa una decisione separata, a minore pressione, non qualcosa a cui sei costretto a metà migrazione solo per mantenere in funzione la chiusura mensile.

Cosa non cambia

Una migrazione ERP è anche di solito il momento in cui si apre l’appetito per gli strumenti che ruotano attorno al sistema centrale, tesoreria, automazione AP, fatturazione elettronica, reporting, perché quelle decisioni vengono riconsiderate insieme alla scelta della piattaforma principale. Se la tua azienda sta anche attraversando la readiness per la fatturazione elettronica ZATCA nello stesso periodo, non è una coincidenza; le migrazioni e le scadenze normative tendono a raggrupparsi, e vale la pena sequenziarle piuttosto che trattare ciascuna come un progetto a sé stante.

Vale la pena essere diretti sul limite: l’ingestione basata su file rimuove la dipendenza da un connettore finito, ma non rimuove la necessità che qualcuno verifichi che l’esportazione sia completa e correttamente delimitata a ogni periodo. Un’esportazione fatta male resta un’esportazione fatta male. Ciò che rimuove è la falsa scelta tra fare reporting da un sistema in via di dismissione e aspettare che il nuovo sia pronto.

A chi serve

Ai team finance a metà migrazione che hanno bisogno dei numeri di questo trimestre indipendentemente da quale ERP sia autorevole quella settimana. Ai controller che gestiscono una nuova filiale che parte su un sistema diverso da quello della capogruppo mentre è in corso anche una migrazione a livello di gruppo. A chiunque si stia avvicinando alla chiusura di fine anno con una tempistica di migrazione che non rispetta il calendario fiscale.

Se sei a metà migrazione e vuoi vedere il reporting proseguire su esportazioni di file mentre l’ERP si stabilizza, prenota una demo, oppure guarda il resto della serie casi d’uso per team finance.