Recupero ERP in un gruppo FMCG: reporting unificato con SAP Analytics Cloud

Questo caso di studio è per i CFO e i responsabili IT che gestiscono più di un ERP e non riescono a ottenere un'unica serie di numeri. In breve: un progetto di reporting transfrontaliero fermo, tra Oracle a Singapore e SAP nel Regno Unito, è stato recuperato in sei mesi. Cinque cose hanno fatto la differenza. Uno steering group più snello e con vera autorità. Un perimetro ridotto ai report che guidano le decisioni. Definizioni concordate tra i due sistemi. SAP Analytics Cloud come unico livello di reporting. E referenti locali al posto della formazione in aula. Se si trova nella stessa situazione, parta da governance e definizioni, non dal dibattito sullo strumento.

La storia comincia con un progetto di analytics ERP fermo in un noto gruppo FMCG con sede a Singapore. Il gruppo deteneva una quota del 26% in un'azienda britannica di energy drink. Nonostante la quota di minoranza, il controllo gestionale era a Singapore, quindi la strategia definita in Asia nelle sale del consiglio determinava il reporting e la pianificazione di ogni giorno in Europa.

La tecnologia rendeva tutto più difficile. Singapore usava Oracle ERP. Il Regno Unito usava SAP ERP. Ciascuno funzionava per conto proprio e insieme creavano un problema di reporting che aveva già assorbito mesi di lavoro.

I numeri raramente coincidevano. Le riconciliazioni si trascinavano per giorni. Anche il semplice reporting dei ricavi dava risultati diversi a seconda del sistema consultato.

Entro sei mesi dall'incarico di recupero, quella che sembrava un'iniziativa fallita è diventata un modello di reporting transfrontaliero di cui finanza e operations si fidavano.

Prima del recuperoAl rilancio

GovernancePrima del recuperoSteering group numeroso, decisioni rinviateAl rilancioSolo veri decisori, che decidono durante la riunione

PerimetroPrima del recuperoUna lavagna piena di richiesteAl rilancioReport che guidano le decisioni

DefinizioniPrima del recuperoStessa etichetta, significato diverso in ogni ERPAl rilancioRicavi, costi e margine concordati

ReportingPrima del recuperoRiconciliazione in Excel che richiedeva giorniAl rilancioDati Oracle e SAP in un unico modello in SAP Analytics Cloud

AdozionePrima del recuperoFormazione in aula, poi di nuovo ExcelAl rilancioReferenti locali, un team alla volta

La tabella riassume la posizione di partenza e come è stato risolto ciascun problema.

Sfida	Impatto	Soluzione con SAP Analytics Cloud
Due ERP: Oracle a Singapore, SAP nel Regno Unito	I numeri non coincidevano; la riconciliazione richiedeva giorni	Entrambi alimentavano un unico modello di reporting
Responsabilità del reporting poco chiare tra i paesi	La strategia in Asia entrava in conflitto con i dati operativi in Europa	Con KPI standard, entrambe le entità riportavano le stesse metriche
Reporting dei ricavi lento	Le cifre differivano per sistema di origine, ritardando le decisioni	Pianificazione e reporting unificati hanno accorciato il ciclo
Pianificazione disallineata	Singapore definiva la strategia; il Regno Unito eseguiva su ipotesi diverse	Modelli di pianificazione condivisi hanno allineato le due aziende

Reporting su due ERP

Con Oracle a Singapore e SAP nel Regno Unito, fare reporting sembrava gestire due aziende separate. La finanza estraeva la stessa metrica da ciascun sistema e otteneva risposte diverse. In una revisione mensile, Singapore ha presentato una cifra di ricavi e il Regno Unito l'ha contestata subito con un'altra. La discussione è durata più della revisione.

Le persone ripiegavano su Excel perché sembrava più sicuro: ore di esportazioni, riconciliazioni e costruzione della propria versione della verità. Funzionava nel breve periodo e creava ritardi cronici nel reporting di gruppo. Il mio articolo su perché i CFO ricorrono ancora a Excel tratta questo schema in modo più ampio.

Consolidamento di fine mese

La chiusura mensile era la parte più difficile. Un costo che in un ERP stava sotto «operativi» finiva a volte sotto «amministrativi» nell'altro. Una volta ho visto una bozza di consolidamento in cui la stessa spesa compariva due volte con voci diverse. Questo ha ucciso la fiducia nei numeri. I risultati in ritardo erano diventati la norma e, quando il gruppo pubblicava, di solito seguivano revisioni.

Reporting operativo

I problemi andavano oltre la finanza. Oracle tracciava le spedizioni, SAP tracciava le scorte e non esisteva una fonte unica. Un responsabile di magazzino mi ha detto di aver ricevuto tre diversi report di giacenza in una sola settimana, tutti con saldi diversi. Rideva mentre lo diceva, ma stava rallentando decisioni vere. Il riassortimento restava indietro e i ritardi di spedizione erano più difficili da spiegare perché le operations non si fidavano delle dashboard.

Il dibattito sullo strumento

Scegliere uno strumento di reporting è diventato un progetto a sé. Alcuni manager apprezzavano il profilo di costo di Power BI; altri spingevano per SAP per la sua roadmap più lunga. Ho assistito a un workshop in cui metà del tempo è andata a «perché SAC e non Power BI» invece che alle esigenze di reporting. Il dibattito è durato mesi e ha prosciugato lo slancio.

Resistenza degli utenti

Anche dopo il rilascio delle prime dashboard, l'adozione è rimasta bassa. Ricordo di aver visto qualcuno, in una riunione di finanza, aprire una dashboard, darle un'occhiata, chiuderla e tornare al proprio foglio Excel. Nessuno ha obiettato. Le persone si fidavano di ciò che conoscevano e le dashboard non si erano ancora guadagnate quella fiducia.

Reimpostare la governance. Le riunioni sembravano infinite e le persone uscivano senza sapere chi avesse deciso. La direzione ha ridotto lo steering group ai veri decisori. Le sessioni sono diventate più brevi e più decisive, e le escalation arrivavano rapidamente alle persone giuste. Non era perfetto, ma le cose hanno iniziato a muoversi. La mia guida a come condurre uno steering committee SAP espone gli stessi principi.

Tenere sotto controllo il perimetro. Le persone discutevano di continuo su quali numeri appartenessero alla vista di gruppo e l'elenco dei requisiti era diventato ingestibile. Ricordo la lavagna di un workshop coperta da un capo all'altro di richieste, metà delle quali slegate da qualsiasi decisione reale. L'impostazione che ha funzionato: il reporting deve coprire solo ciò che guida le decisioni. Una volta concordato questo, la consegna ha preso velocità.

Una comunicazione che risultasse rilevante. I primi aggiornamenti erano generici, quindi finanza, operations e IT ne traevano ciascuna un'interpretazione diversa. Siamo passati ad aggiornamenti su misura: tempistiche del reporting per la finanza, modifiche ai processi logistici per le operations, una roadmap tecnica per l'IT. Le persone hanno cominciato a fare domande migliori perché gli aggiornamenti parlavano la loro lingua.

Referenti locali. La sola formazione non aveva funzionato: le persone seguivano le sessioni e la mattina dopo tornavano a Excel. Il cambiamento è arrivato dai referenti locali, colleghi che avevano già credibilità nei propri team, che spiegavano le dashboard in modo informale con parole loro. Ho assistito a una di quelle sessioni e la differenza era netta. Le persone facevano domande che non avrebbero mai fatto in aula. L'adozione è migliorata un team alla volta.

La tabella riassume che cosa è cambiato e perché ha funzionato.

Area di intervento	Che cosa è cambiato	Impatto
Reset della governance	Steering group ridotto ai veri decisori; sessioni più brevi e mirate	Decisioni prese in riunione; escalation più rapide
Controllo del perimetro	Requisiti ridotti al reporting che guida le decisioni	Meno dibattito, modelli di dati più chiari, meno bersagli mobili
Comunicazione su misura	Aggiornamenti separati per finanza, operations e IT	Ogni team ha capito che cosa contava per sé; la fiducia è tornata
Referenti locali	Affiancamento tra pari in piccoli gruppi invece di corsi formali	L'adozione è migliorata team per team; la dipendenza da Excel è calata

Quando la selezione dello strumento si è finalmente conclusa, ha vinto SAC, in parte perché poteva portare i dati Oracle e SAP in un unico modello senza personalizzazioni pesanti. Questo ha tolto un po' di tensione dalla discussione. I report riflettevano le modifiche molto più in fretta del vecchio ciclo di esportazione. Una financial controller ha detto che era la prima volta che non doveva aspettare un aggiornamento dati notturno per iniziare la giornata.

La prima volta che il finance manager ha visto i dati Oracle e SAP affiancati in un'unica dashboard, si è tolto un peso. Quel momento ha chiuso il dibattito.

SAC copriva anche più della finanza. Le operations volevano una vista su logistica e magazzino e le risorse umane la pianificazione della forza lavoro. Avere pianificazione, reporting e visualizzazione su un'unica piattaforma ha fatto la differenza tra un rimedio tattico e una base di lungo periodo. I template predefiniti hanno dato al team un vantaggio iniziale, anche se alcuni li trovavano generici, e la rapidità di quella prima consegna ha restituito fiducia dopo mesi di ritardo.

Un punto tecnico, se intende replicare questo disegno. Le connessioni live di SAC sono limitate a sorgenti SAP come SAP HANA, BW, S/4HANA, BPC embedded, universi BusinessObjects e SAP Datasphere. I dati non SAP, come un Oracle ERP, di solito arrivano tramite una connessione di importazione, un universo o un livello dati intermedio. Si decida presto questa architettura, perché stabilisce quanto possano essere aggiornati i numeri di ciascun lato.

La prima tappa è stata il modello dati. Oracle e SAP dovevano alimentare un'unica struttura, e si è rivelato più difficile del previsto. I campi avevano la stessa etichetta ma significavano cose diverse nei due sistemi. Ci sono volute settimane di mappatura delle definizioni prima che la finanza concordasse che cosa fossero davvero ricavi, costi e margine.

Le dashboard sono state rilasciate per fasi. Prima la finanza, poi vendite e operations, ciascuna con report costruiti attorno al lavoro reale. Le prime versioni erano troppo rigide. Gli utenti lo dicevano, e avevano ragione. Le dashboard sono migliorate e i KPI concordati hanno sostituito quelle che erano state discussioni mensili continue.

Il rilancio si è completato entro sei mesi. Per la prima volta i dati Oracle e SAP stavano in un unico modello dentro SAC. Le discussioni sulla riconciliazione sono calate e i dirigenti esaminavano i numeri senza aspettare la circolazione dei file Excel.

I cicli di pianificazione che richiedevano settimane ne richiedevano giorni. I pianificatori potevano modellare scenari e confrontarli con il consuntivo. Alcuni manager volevano più dettaglio di quello offerto dalle dashboard, ma il fatto che si fidassero dei numeri era già significativo.

Un responsabile di magazzino ha detto che, per la prima volta, i livelli di giacenza nel suo report coincidevano con quelli mostrati dalla finanza. Quell'allineamento silenzioso tra i reparti era l'indicatore vero. Nessuno ha chiesto di tornare al vecchio processo.

La tabella elenca gli errori che hanno bloccato il progetto e la lezione di ciascuno.

Errore	Che cosa ha causato	Lezione
Governance poco chiara	Riunioni infinite, nessuna decisione, ritardi crescenti	Ridefinire presto ruoli e diritti decisionali
Deriva del perimetro	Gli obiettivi di reporting continuavano a cambiare	Tenere il perimetro stretto e legato alle decisioni
Ignorare gli utenti	Gli utenti hanno perso fiducia e l'adozione è rallentata	Coinvolgere presto gli utenti e dar loro il contesto
Eccesso di personalizzazione	Tempo sprecato a ricostruire report	Partire da template e connettori standard; personalizzare dopo
Change management debole	La formazione ha mancato il bersaglio; le vecchie abitudini sono rimaste	Coinvolgere presto referenti locali e affiancamento tra pari

Tre lezioni valgono più delle altre. La governance conta più dello strumento: senza una responsabilità chiara in un contesto multi-ERP, il reporting si sfalda qualunque sia la piattaforma. Allineare le definizioni dei dati prima della scelta dello strumento: il dibattito Power BI contro SAC mancava il punto, perché nessuno strumento corregge definizioni che non coincidono. E il change management decide l'adozione: senza referenti e comunicazione mirata, le dashboard sarebbero rimaste inutilizzate.

Se lo stesso lavoro partisse oggi, cambierebbero tre cose.

Un livello dati si collocherebbe tra SAC e le sorgenti. SAP Datasphere, oggi parte di SAP Business Data Cloud, offre accesso federato a sorgenti SAP e non SAP con un modello semantico sopra. In un caso a due ERP come questo, armonizzare i dati Oracle e SAP in quel livello è più pulito che farlo dentro ogni story di SAC. Dà inoltre a SAC una connessione live al modello armonizzato.

Le domande in linguaggio naturale sostituirebbero alcune costruzioni di dashboard. La query in linguaggio naturale di SAC e Joule permettono alla finanza di chiedere, per esempio, i ricavi per regione del trimestre, Singapore contro Regno Unito. Non serve costruire prima alcuna story. Accelera il lavoro una volta armonizzati i dati. Non colma una lacuna di definizioni.

La conversazione commerciale partirebbe dal contratto ERP. Si verifichi quali funzioni di analytics includa già il contratto ERP cloud prima di negoziare SAC. La pianificazione completa di SAC è concessa in licenza separatamente e gli ambienti ibridi, con un'entità su ERP cloud e un'altra no, richiedono comunque un'attenta gestione delle licenze.

Il reset della governance, la disciplina sul perimetro, i referenti locali e la comunicazione su misura non cambierebbero. Questi schemi valgono qualunque sia la tecnologia. Il lavoro umano di far riportare gli stessi numeri a due ERP non si automatizza. Per saperne di più su SAC, si veda la mia guida a SAP Analytics Cloud.

Perché il progetto di reporting ERP di questo gruppo FMCG si è fermato?

Singapore usava Oracle e il Regno Unito SAP, e ogni mese la finanza cuciva i numeri a mano. Ci volevano giorni e nessuno si fidava davvero del risultato. Le revisioni si bloccavano quando Singapore presentava una cifra e il Regno Unito la contestava con un'altra. Anche lo steering group era troppo numeroso, quindi nessuno prendeva decisioni. I costi salivano, la fiducia calava e il progetto andava alla deriva.

Che cosa ha cambiato la direzione del recupero?

La direzione ha ammesso che il progetto era fermo e ha concordato un piano di recupero. Lo steering group è stato ridotto a un piccolo gruppo di veri decisori, sono state fissate le priorità, SAP Analytics Cloud è stato scelto come unico strumento di reporting e la comunicazione è diventata specifica per ciascun pubblico. Le riunioni sono passate dalle colpe a ciò che veniva dopo e le persone hanno cominciato a credere che il progetto potesse arrivare in fondo.

Come ha gestito SAP Analytics Cloud sia Oracle sia SAP?

SAC ha portato i dati Oracle e SAP in un unico modello di reporting, così entrambi comparivano affiancati in una sola dashboard senza file di riconciliazione manuali. Vedere i due sistemi in un'unica vista è stato il momento che ha chiuso il dibattito sullo strumento. Va notato che le connessioni live di SAC supportano solo sorgenti SAP; i dati Oracle di solito arrivano tramite una connessione di importazione, un universo BusinessObjects o un livello dati come SAP Datasphere.

Perché all'inizio gli utenti hanno resistito alle dashboard?

Le dashboard sono partite senza abbastanza contesto di business. Agli utenti era stato detto di usare SAC, ma nessuno aveva mostrato come si applicasse al loro lavoro quotidiano, e la formazione era generica. Le persone si fidano di ciò che conoscono e le dashboard non si erano ancora guadagnate quella fiducia. I referenti locali, che spiegavano le dashboard con parole proprie, hanno cambiato le cose.

Che aspetto ha un recupero riuscito del reporting ERP?

Raramente è una cosa sola. Qui sono stati un reset della governance, la riduzione del perimetro, definizioni concordate, comunicazione su misura e referenti tra pari che lavoravano insieme. SAC ha aiutato perché ha portato entrambi gli ERP in un unico modello senza personalizzazioni pesanti, ma la tecnologia da sola non avrebbe salvato il progetto. Sei mesi dopo, chi aspettava che crollasse presentava dashboard costruite da sé.