Passa ai contenuti principali

Il controller costruisce il dato invece di analizzarlo: cosa può (davvero) fare l'ERP


È il 6 del mese. L'amministratore delegato passa dalla scrivania e chiede il conto economico gestionale di aprile. Il controller apre tre estrazioni diverse dal gestionale, recupera il file Excel dell'anno — dodici fogli tenuti insieme da formule stratificate stagione dopo stagione — riprende la struttura del mese precedente, incolla, verifica che le somme quadrino, sistema le due righe che non tornano. Quando il report è finalmente pronto è il 10, e il 10 l'azienda sta già parlando d'altro.

Questa scena si ripete pressoché identica in migliaia di PMI italiane, e ha una conseguenza che raramente viene detta ad alta voce: il controller, cioè la persona pagata per interpretare i numeri e orientare le decisioni, finisce per passare la gran parte del proprio tempo a costruire il dato e solo una frazione a leggerlo. Il rapporto dovrebbe essere l'esatto contrario. E il punto di questo articolo è che quel ribaltamento non si ottiene comprando l'ennesimo strumento di reporting, ma intervenendo lì dove il problema nasce davvero: nel gestionale.

Perché l'ERP, così com'è, non basta al controller

Conviene partire da una distinzione che spiega quasi tutto. L'ERP nasce, viene configurato e viene manutenuto attorno a un obiettivo primario: produrre la contabilità civilistica e fiscale. Bilancio in schema CEE, saldi di conto, liquidazioni IVA, dichiarativi. È il suo mestiere ed è giusto che lo faccia bene, perché è ciò che l'azienda deve per legge.

Il conto economico che serve al controller, però, è un oggetto diverso. Non gli interessa lo schema di bilancio: gli serve un conto economico riclassificato — a margine di contribuzione, a EBITDA — letto per dimensioni, cioè per centro di costo, commessa, linea di prodotto, canale, area. Il fisco ragiona per natura del costo (materie prime, servizi, personale); il controllo ragiona per destinazione (quanto margina questo prodotto, questo cliente, questa filiale). Sono due letture legittime dello stesso fatto economico, ma l'ERP fuori dalla scatola risponde solo alla prima.

Quando manca il lato gestionale — anagrafiche e dimensioni assenti o sporche, nessuna riclassifica configurata, costi indiretti mai ribaltati — il sistema semplicemente non è in grado di rispondere alle domande del controllo. E allora il controller fa l'unica cosa che può fare: esporta i saldi grezzi e ricostruisce a mano, ogni mese, in Excel, la struttura analitica che il gestionale avrebbe potuto tenere in piedi da solo. Excel, in questa storia, non è il colpevole: è il cerotto applicato su un modello dati incompleto.

La tentazione che non risolve: comprare la business intelligence per prima

C'è una scorciatoia che sembra ovvia e che quasi tutti imboccano: "il reporting è lento e brutto, prendiamo Power BI". Si investono tempo e budget in dashboard, le si collega alle stesse estrazioni di prima e per qualche settimana i grafici sembrano la soluzione. Non lo sono. Una piattaforma di BI appoggiata a un dato sporco non fa altro che produrre grafici sbagliati più in fretta: eredita ogni difetto della sorgente e lo rende soltanto più convincente da guardare, perché un numero falso dentro un cruscotto curato ispira più fiducia dello stesso numero in una cella di Excel.

La business intelligence è l'ultimo anello della catena, non il primo. Serve davvero, ma solo quando il dato alla fonte è sano. Il lavoro che conta — quello che nessun fornitore di dashboard ti proporrà mai, perché non è il suo mestiere — è a monte, nel modello dati del gestionale. Ed è lì, per fortuna, che l'ERP moderno ha parecchie leve da offrire. Vale la pena vederle una per una.

Tutto comincia dal dato che entra

La prima leva, e la meno appariscente, è la qualità del dato nel momento in cui viene registrato. Un ERP ben impostato non lascia che una fattura di acquisto, un movimento di magazzino o una nota spese entrino privi delle coordinate analitiche che serviranno poi. Significa configurare una contabilità analitica multidimensionale — dove ogni scrittura porta con sé, oltre al conto, anche il centro di costo, l'eventuale commessa, il prodotto o il canale — e renderla parte del gesto quotidiano di chi registra, non un'operazione separata da fare "dopo".

Il modo per ottenerlo è ridurre al minimo la digitazione manuale. Le causali contabili possono essere costruite in modo da proporre o imporre automaticamente la dimensione corretta; i controlli bloccanti impediscono di chiudere una registrazione senza centro di costo dove è obbligatorio; e soprattutto l'integrazione fra i moduli fa arrivare il costo già dimensionato dalla sua origine. Se il magazzino movimenta un prelievo su commessa, se l'ordine a fornitore nasce già con la sua causale gestionale, se le ore del personale arrivano dai rapportini con una tariffa oraria sensata, allora il dato analitico non va ricostruito a valle: è già lì, corretto, prodotto dal processo stesso. Insieme a questo viaggia la disciplina anagrafica — clienti, fornitori, articoli senza duplicati e con gli attributi analitici valorizzati — perché è la fondazione su cui poggia tutto il resto, ed è anche la parte che nessuno strumento a valle potrà mai sanare da sola.

La riclassifica come vista permanente, non come lavoro mensile

La seconda leva è probabilmente quella che, da sola, elimina la fetta più grande di copia-incolla. Lo schema di conto economico riclassificato — a margine di contribuzione o a EBITDA — non dovrebbe vivere in un foglio Excel ricostruito ogni mese, ma essere configurato dentro il gestionale come vista permanente. Una volta mappato una volta per tutte il legame fra i conti del piano dei conti e le voci di riclassifica, il conto economico gestionale si genera da sé a ogni chiusura, coerente e senza intervento manuale.

Gli ERP evoluti permettono di tenere più schemi di riclassifica in parallelo — uno per la direzione, uno per le banche, uno per il reporting di gruppo — tutti alimentati dagli stessi saldi ma presentati in forme diverse. È il passaggio che trasforma la riclassifica da attività ricorrente del controller a proprietà stabile del sistema: la si progetta bene una volta e poi lavora da sola.

I ribaltamenti che si fanno da soli

Terza leva: i costi indiretti. Affitti, utenze, struttura, personale non direttamente imputabile a un oggetto vanno comunque distribuiti sui centri e sulle destinazioni di costo, altrimenti il margine per prodotto o per commessa resta monco. Fatto a mano, questo ribaltamento è la prima cosa che salta quando il controller è di corsa, ed è anche la più soggetta a incoerenze da un mese all'altro.

Il motore di allocazione di un ERP serve esattamente a questo: si definiscono i driver di ribaltamento — metri quadri, ore, teste, fatturato — e il sistema applica le regole a ogni chiusura, in modo documentato e ripetibile. La differenza non è solo di tempo risparmiato: è che le regole diventano esplicite e verificabili, invece di rimanere nella testa di chi le applicava a mano. Quando qualcuno chiederà perché quel costo di struttura pesa così tanto su una linea, la risposta è nel driver configurato, non in una formula Excel di cui si è perso l'autore.

Chiudere la gestione prima del fisco

C'è poi un tema di tempi, ed è dove si gioca la differenza fra un controllo utile e uno inutile. Il controllo di gestione non può aspettare la chiusura civilistica: quando quella è pronta, le decisioni che contavano sono già state prese o mancate. La risposta, lato software, è separare la chiusura gestionale da quella fiscale e renderla rapida.

In pratica significa poter registrare direttamente in analitica le scritture di competenza — ratei, risconti, accantonamenti gestionali — anche in via provvisoria, per avere numeri attendibili al giorno 3 o 4 senza attendere il perfezionamento contabile. Un ERP che consente scritture gestionali extracontabili, o un periodo di chiusura "soft" dedicato al controllo, permette di produrre un conto economico sufficientemente accurato quando serve davvero. Una chiusura veloce e ragionevolmente precisa batte sempre una chiusura perfetta ma tardiva, perché la prima serve a decidere e la seconda solo a dichiarare. È anche il punto in cui la doppia competenza fiscale e gestionale fa la differenza, perché bisogna sapere quali rettifiche hanno senso gestionale pur non essendo ancora scritture civilistiche definitive.

Il budget dentro il sistema, non accanto

Un consuntivo senza un preventivo a fianco è un numero privo di contesto: dice quanto è successo, non se è andata bene. Per questo il budget va caricato nel gestionale con la stessa struttura dimensionale del consuntivo — stessi centri, stesse commesse, stesse voci di riclassifica — così che il confronto actual-vs-budget si aggiorni da solo a ogni chiusura e gli scostamenti emergano quando c'è ancora margine per reagire.

Gli ERP con un modulo di budgeting integrato consentono anche di gestire revisioni e forecast progressivi nel corso dell'anno, mantenendo la tracciabilità delle versioni. Il valore, di nuovo, è che il confronto non è un esercizio da rifare ogni mese incrociando due file diversi, ma una vista viva del sistema, sempre allineata alla stessa base dati del consuntivo.

E allora, la business intelligence

Solo a questo punto la BI trova il suo posto giusto. Quando il dato è pulito alla fonte, la riclassifica è automatica, i ribaltamenti sono stabili e il budget è collegato, molti ERP mettono a disposizione un datamart gestionale — un'area dati già strutturata per l'analisi — su cui la business intelligence si appoggia senza dover reinventare nulla. A quel punto le dashboard diventano ciò che avrebbero sempre dovuto essere: un layer di visualizzazione e distribuzione sopra un dato già sano, veloce da costruire e, finalmente, affidabile da leggere. La BI non crea la verità gestionale: la mostra. E può mostrarla bene solo se qualcuno, a monte, l'ha costruita nel modello dati.

Il punto

Il controller non è lento perché usa Excel, e non diventerà veloce comprando un cruscotto in più. È intrappolato in un lavoro di ricostruzione manuale che esiste solo perché il gestionale non è stato configurato per rispondere alle domande del controllo. La buona notizia è che quasi tutte le leve per uscirne stanno dentro l'ERP che l'azienda già possiede: contabilità analitica multidimensionale, dato dimensionato all'origine, riclassifica come vista permanente, ribaltamenti automatici, chiusura gestionale anticipata, budget integrato. Attivate nell'ordine giusto, restituiscono al controller la cosa di cui ha più bisogno: il tempo per fare il suo mestiere, che non è costruire il numero ma capirlo e usarlo per far prendere all'azienda decisioni migliori, mentre contano ancora.


Ti occupi di controllo di gestione e riconosci questa scena? Il collo di bottiglia è quasi sempre nel modello dati del gestionale, non nello strumento di reporting. Se vuoi confrontarti su come impostare il layer analitico del tuo ERP, scrivimi.

Commenti

Post Popolari

La scelta tra "EL" e "GR" per indicare la Grecia nelle fatture elettroniche

Nel processo di emissione delle fatture elettroniche, una delle questioni che può suscitare dubbi riguarda la corretta sigla da utilizzare per indicare il paese Grecia. Questo può derivare dalla varietà delle lingue utilizzate in Europa, dalla differenza tra il nome del paese nella lingua locale e in inglese, e dalle diverse normative fiscali e standard internazionali. In effetti, la Grecia è conosciuta come "Ελλάδα" (Elláda) nella sua lingua nativa, mentre in inglese è denominata "Greece". Tuttavia, quando si tratta di codificare il paese per scopi fiscali e amministrativi, è importante fare riferimento agli standard internazionali. In questo contesto, viene utilizzato il codice ISO 3166-1 alpha-2 , che assegna a ciascun paese un codice di due lettere univoco. Secondo lo standard ISO 3166-1 alpha-2, il codice assegnato alla Grecia è " GR ", che corrisponde alla forma abbreviata di "Ελλάδα" e "Greece". Questo codice è universalmente ric...

TD24 e TD25: La guida definitiva alla fattura differita

  Nella giungla della fatturazione elettronica, la fattura differita è uno degli strumenti più utili per semplificare i processi amministrativi, ma è anche un terreno minato per chi non padroneggia i codici tipo documento ( TD ). Sbagliare tra un TD24 e un TD25 non è un semplice errore veniale: significa inviare allo SDI un documento che non rispecchia la natura dell'operazione, con il rischio di sanzioni per omessa o errata fatturazione. In questo articolo analizziamo la normativa vigente e le specifiche tecniche per non commettere errori. Il quadro normativo: l'Articolo 21 del DPR 633/72 La possibilità di emettere una fattura in un momento successivo rispetto all'effettuazione dell'operazione non è una concessione del software, ma un diritto stabilito dall' Art. 21, comma 4, lett. a) del DPR 633/72 . La norma stabilisce che per le cessioni di beni la cui consegna risulti da documento di trasporto ( DDT ) o altro documento analogo, la fattura può essere emessa e...

Fattura elettronica e CUP: come inserire o modificare il Codice Unico di Progetto con il nuovo servizio dell’Agenzia delle Entrate

  L’Agenzia delle Entrate introduce una novità rilevante in materia di fatturazione elettronica e incentivi pubblici : è in arrivo un servizio online che consente di inserire o modificare il CUP (Codice Unico di Progetto) nelle fatture elettroniche già trasmesse allo SdI. Si tratta di un intervento atteso, che punta a semplificare gli adempimenti e ridurre gli errori formali che, fino a oggi, potevano comportare criticità fiscali e amministrative per imprese e professionisti. Cos’è il CUP e quando è obbligatorio in fattura Il CUP – Codice Unico di Progetto è un codice alfanumerico che identifica in modo univoco ogni progetto finanziato, anche parzialmente, con risorse pubbliche. La sua funzione principale è garantire la tracciabilità dei flussi finanziari e permettere alle amministrazioni di monitorare correttamente l’utilizzo dei fondi. L’obbligo di indicare il CUP nelle fatture elettroniche è entrato in vigore dal 1° giugno 2023 , in base alle disposizioni del DL n. 13/2023 ....