Fondamenta dei dati prima dell'IA: gli interventi che si ripagano entro due trimestri

La maggior parte dei piani sull'IA presuppone che i dati aziendali siano pronti e che il lavoro consista nello scegliere un modello. Nelle imprese consolidate i dati si trovano di solito nei sistemi giusti ma nella forma sbagliata: lo stesso cliente registrato in tre modi diversi, codici prodotto che hanno significati diversi nel negozio online e in magazzino, ricavi che non coincidono tra la proprietà di analytics e la contabilità generale.

Il modo più rapido per capire che cosa correggere è seguire dati reali. Si prende un campione di ordini, fatture e movimenti di magazzino e si traccia ciascuno attraverso ogni sistema che lo tocca, dal negozio online o dallo strumento di preventivazione al fornitore dei pagamenti, al CRM e al magazzino, fino al software di contabilità e al livello di reporting. Si annota dove il dato viene reinserito a mano, dove un foglio di calcolo lo copia, dove cambia il suo identificativo e dove scompare. Quei punti costituiscono l'elenco degli interventi.

Gli interventi descritti di seguito sono quelli che prevediamo si ripaghino entro due trimestri. Ciascuno elimina lavoro manuale o un errore di reporting che già costa denaro, e ciascuno è un prerequisito per qualsiasi funzionalità di IA che in seguito leggerà gli stessi dati.

Ogni utilizzo a valle dipende dai collegamenti tra dati. I ricavi per cliente richiedono che il sistema ordini e la contabilità generale condividano una chiave cliente. Il margine per prodotto richiede che negozio online, magazzino e contabilità fornitori concordino sul significato di un codice prodotto. Un assistente di IA che risponde a domande su ordini o prodotti eredita qualsiasi ambiguità contenuta nelle chiavi.

La verifica è rapida. Per ogni identificativo si controlla che sia compilato e che sia univoco sull'intera popolazione, in modo che un codice corrisponda a un solo prodotto. Si tratta di due verifiche distinte. Un campo codice prodotto può essere compilato su ogni record ed essere comunque condiviso da due articoli diversi, il che basta perché un assistente descriva con assoluta sicurezza il prodotto sbagliato, o perché un catalogo inviato a un partner commerciale indichi l'articolo sbagliato sotto il codice giusto.

Il ritorno deriva dal lavoro che l'intervento elimina: note di credito per spedizioni errate, ore spese a riconciliare gli estratti conto dei clienti e report ricostruiti a mano ogni mese perché due sistemi non concordano.

Le proprietà standard di Google Analytics 4 conservano i dati a livello di utente e di evento per 2 mesi per impostazione predefinita e per un massimo di 14 mesi; una conservazione più lunga dei dati sugli eventi è disponibile solo con la versione a pagamento 360. I report standard si basano su tabelle aggregate e continuano a mostrare i totali meno recenti, per cui la perdita resta invisibile finché qualcuno non costruisce un'esplorazione o un funnel anno su anno e trova vuoto il periodo precedente. Aumentare l'impostazione di conservazione protegge solo i dati non ancora cancellati.

La soluzione duratura è l'esportazione verso BigQuery, che copia gli eventi grezzi in un data warehouse di proprietà dell'impresa. Le proprietà standard possono inviare fino a 1 milione di eventi al giorno tramite l'esportazione giornaliera. L'esportazione in streaming non ha limiti di volume e costa $0,05 per gigabyte, che secondo Google corrispondono a circa 600.000 eventi. A queste tariffe il costo di archiviazione per un'impresa di medie dimensioni è modesto rispetto al costo di pianificare un'alta stagione senza i dati comportamentali dell'anno precedente.

Questo intervento ha una scadenza incorporata. Ogni mese di attesa è un mese di storico degli eventi che non si può più recuperare, e il ciclo di pianificazione 2027 avrà bisogno dell'alta stagione 2026 per intero.

La fatturazione elettronica fa dell'anagrafica clienti un presupposto di conformità. In Germania, le imprese con un fatturato dell'anno precedente superiore a €800.000 devono emettere le fatture nazionali business-to-business in formato elettronico strutturato dal 1° gennaio 2027, e tutte le altre imprese seguiranno dal 1° gennaio 2028; la ricezione è obbligatoria dal 1° gennaio 2025. Nel Regno Unito il governo ha annunciato che tutte le fatture IVA dovranno essere elettroniche da aprile 2029, ha confermato Peppol come rete di scambio e ha indicato che una tabella di marcia dettagliata per l'attuazione sarebbe arrivata con il Budget 2026, previsto per il 28 ottobre.

Il lavoro che si ripaga è lo stesso in entrambi i paesi e inizia ben prima di qualsiasi scadenza. Completare e validare partite IVA, codici fiscali e indirizzi di instradamento elettronico nell'anagrafica clienti. Uniformare i codici prodotto e i codici IVA sulle righe delle fatture. Eliminare i passaggi manuali tra il sistema ordini e la fattura. Una fattura respinta ritarda l'incasso, quindi anagrafiche pulite accorciano i tempi di riscossione oltre a garantire il rispetto della norma, e un modello di dati costruito questo trimestre per un'entità tedesca può essere riutilizzato in seguito per il Regno Unito.

L'ultimo intervento è una disciplina più che un sistema. I report direzionali prendono i ricavi dal negozio online o dal CRM, i costi dalla contabilità generale e i risultati di marketing dalle piattaforme pubblicitarie, e le tre fonti concordano di rado. Quando il fascicolo per il consiglio e il bilancio differiscono di un importo che nessuno sa spiegare, ogni dato del fascicolo perde autorevolezza e le decisioni rallentano mentre si discute su quale numero sia quello giusto.

Un raccordo mensile chiude la questione. Dopo la chiusura, ogni dato principale del reporting direzionale mensile viene riconciliato con la contabilità generale, scomponendo la differenza in voci ricorrenti e denominate: competenza temporale, rimborsi, imposte, rapporti infragruppo, ordini di prova. Il raccordo viene generato dai sistemi anziché assemblato a mano, e ogni residuo non spiegato superiore a una soglia concordata viene analizzato prima della diffusione del reporting. Una volta dato un nome alle voci ricorrenti, ciò che resta è di solito un breve elenco di processi che nessuno aveva documentato.

È anche la base di cui avrà bisogno qualsiasi assistente di IA per il reporting. Un modello a cui si chiede perché il margine sia sceso in una regione può rispondere correttamente solo se i dati che legge sono già stati riconciliati. Costruiamo questi raccordi partendo dalla contabilità generale per la stessa ragione per cui iniziamo ogni incarico da ordini, scritture contabili e log: una dashboard vale quanto i dati che la alimentano.

A novembre 2026, tracciare un campione di ordini, fatture e movimenti di magazzino reali attraverso tutti i sistemi ed elencare ogni punto in cui un dato viene reinserito, copiato o riceve un nuovo identificativo.

Prima della fine di novembre, impostare a 14 mesi la conservazione degli eventi GA4 su ogni proprietà e collegare ciascuna proprietà a BigQuery, in modo da conservare per intero l'alta stagione 2026.

Entro la fine di dicembre, eseguire controlli di univocità e completezza sugli identificativi di clienti, prodotti e ordini in tutti i sistemi, e correggere i codici prodotto duplicati prima che qualsiasi funzionalità di IA o catalogo commerciale vi faccia affidamento.

Per ogni entità tedesca, verificare prima del 1° gennaio 2027 se supera la soglia di €800.000 e se fatturazione e anagrafica clienti sono pronte, e pianificare l'obbligo britannico sullo stesso modello di dati non appena sarà pubblicata la tabella di marcia.

A partire dalla chiusura di gennaio 2027, pubblicare un raccordo mensile tra reporting direzionale mensile e contabilità generale, con voci di riconciliazione denominate e una soglia per il residuo.

Entro giugno 2027, scegliere il primo caso d'uso dell'IA sulla base dei dati riconciliati e misurarne la situazione di partenza sugli stessi dati.