Come sviluppare un sistema di Business Intelligence con l’Intelligenza Artificiale

In quasi tutte le aziende esiste una domanda che nessuno riesce a rispondere in meno di tre giorni. Non è una domanda difficile: “quanto abbiamo marginato sul prodotto X nell’ultimo trimestre, per canale di vendita?”. I dati per rispondere ci sono tutti, sparsi fra il gestionale, l’e-commerce, il CRM e tre fogli di calcolo che una persona aggiorna a mano il lunedì mattina. Quello che manca non è l’informazione: manca l’infrastruttura che la rende interrogabile.

Costruire quell’infrastruttura — un sistema di Business Intelligence — è storicamente stato un progetto da sei mesi e da un consulente specializzato. Oggi una buona parte di quel lavoro può essere delegata a un modello di intelligenza artificiale, ed è esattamente questo il punto interessante: non l’AI che analizza i dati al posto vostro, ma l’AI che vi costruisce il sistema con cui analizzarli. Sono due cose molto diverse, e confonderle è il primo modo per sprecare tre mesi.

Questa guida percorre i tre passi che portano da “abbiamo i dati sparsi ovunque” a “abbiamo un sistema di BI funzionante”: la scelta dell’AI, la definizione del data warehouse e la costruzione del modello di BI. Per ogni passo vedremo cosa chiedere al modello, come chiederglielo, cosa non delegargli mai e come verificare che quello che ha prodotto sia corretto.

Cosa significa davvero sviluppare la BI con l’Intelligenza Artificiale

Conviene sgombrare subito il campo da un equivoco che circola parecchio. Quando si dice “AI per la Business Intelligence” si intendono, nella pratica, tre cose completamente diverse:

1. L’AI come analista: caricate un file, il modello vi dice cosa vede. Utile per un’esplorazione una tantum, inutile come sistema, perché non lascia nulla dietro di sé e va rifatto ogni volta.
2. L’AI come interfaccia: l’utente scrive una domanda in italiano e il sistema genera la query. È la parte più appariscente e, come vedremo, quella che funziona solo se i due passi precedenti sono stati fatti bene.
3. L’AI come sviluppatore: il modello progetta lo schema, scrive le trasformazioni SQL, definisce le metriche, genera i test e documenta il tutto. È qui che si concentra il risparmio reale, ed è il senso di questa guida.

La terza è la più noiosa da raccontare e la più redditizia da fare. Un progetto di BI è per l’80% lavoro artigianale ripetitivo: leggere lo schema di un gestionale, capire come si chiamano davvero le colonne, scrivere duecento righe di SQL per pulire le anagrafiche duplicate, costruire una tabella delle date, mettere insieme una star schema, documentare cosa significa “cliente attivo”. Nessuna di queste attività richiede genio; tutte richiedono tempo. Ed è esattamente il tipo di lavoro in cui un modello linguistico moderno è bravo, purché gli si dia il contesto giusto.

La parte restante — decidere quali domande il sistema deve saper rispondere e cosa significano i termini aziendali — non è delegabile, e per un motivo strutturale: quelle informazioni non stanno nei dati, stanno nella testa delle persone che lavorano in azienda. Un modello che non le ha inventerà definizioni plausibili, e una definizione plausibile ma sbagliata di “fatturato” è il modo più efficace per far perdere credibilità a un sistema di BI nel giro di due settimane.

Passo 1 — La scelta dell’AI

La scelta non riguarda solo “quale modello”, ma tre decisioni distinte che vengono spesso confuse fra loro: quale modello, con quale strumento lo si fa lavorare, e su quali dati lo si lascia lavorare.

Quale modello: i criteri che contano davvero

Per lo sviluppo di un sistema di BI i criteri di valutazione sono diversi da quelli di un uso generalista. Ne contano quattro.

La qualità del SQL su schemi complessi. Non “sa scrivere una SELECT” — lo fanno tutti — ma: regge un join a sette tabelle con due granularità diverse senza gonfiare gli importi? Gestisce correttamente le finestre temporali, gli anni fiscali sfalsati, i valori nulli nelle chiavi esterne? È qui che si separano i modelli, ed è verificabile in mezz’ora con tre query di prova sul vostro schema reale.

La finestra di contesto. Uno schema di gestionale medio ha centinaia di tabelle. Poter passare al modello l’intero DDL, più la documentazione, più un campione di dati, cambia radicalmente la qualità dell’output rispetto a lavorare per frammenti. Le finestre da 200.000 token in su rendono possibile un approccio che con 8.000 token era semplicemente impraticabile.

La capacità agentica. Un modello che può eseguire query di esplorazione, leggere i risultati e correggersi vale molto più di un modello che scrive codice alla cieca. La differenza operativa è enorme: nel primo caso il modello scopre da solo che la colonna data_doc contiene anche date del 1900 usate come segnaposto; nel secondo ve ne accorgete voi tre settimane dopo, guardando un grafico con una barra impossibile.

Il regime di trattamento dei dati. Se l’azienda ha vincoli su dove possono transitare i dati, questo criterio precede tutti gli altri e va risolto per primo, non a progetto avviato.

Con quale strumento farlo lavorare

Cambia molto più di quanto si creda. Tre configurazioni tipiche, in ordine crescente di efficacia:

Il consiglio pratico è di partire dalla prima per la fase di progettazione — dove serve ragionare, non eseguire — e passare alla terza per la fase di costruzione. La combinazione più produttiva, oggi, è un agente che ha accesso in sola lettura a una replica del database sorgente e in scrittura alla cartella del progetto. In questa configurazione il modello può fare, da solo, il ciclo completo: guardo com’è fatta la tabella, scrivo la trasformazione, la eseguo, controllo il risultato, correggo.

Su quali dati lasciarlo lavorare

Regola generale: al modello serve lo schema, non i dati. Per progettare un data warehouse bastano i nomi delle tabelle e delle colonne, i tipi, le chiavi, i vincoli e — questo sì è prezioso — la distribuzione dei valori delle colonne categoriche. Non serve inviare le anagrafiche clienti, e non conviene farlo.

Una tecnica che funziona bene è generare un “profilo” del database e passare quello al modello: per ogni tabella, il numero di righe, le colonne con tipo e percentuale di valori nulli, i valori distinti per le colonne a bassa cardinalità e tre righe di esempio con i campi sensibili offuscati. Sono venti righe di script e trasformano radicalmente la qualità delle risposte, perché il modello smette di indovinare cosa contiene flg_tipo_2 e lo vede.

-- Profilo minimo di una tabella sorgente, da passare al modello
SELECT
    column_name,
    data_type,
    is_nullable,
    character_maximum_length
FROM information_schema.columns
WHERE table_schema = 'gestionale'
  AND table_name  = 'documenti_testata'
ORDER BY ordinal_position;

-- Distribuzione dei valori di una colonna categorica: dice al modello
-- cosa significa davvero il campo, meglio di qualsiasi documentazione
SELECT tipo_documento, COUNT(*) AS righe
FROM gestionale.documenti_testata
GROUP BY tipo_documento
ORDER BY righe DESC;

Cosa non delegare mai

Tre cose restano vostre, indipendentemente da quanto sia bravo il modello.

Le definizioni aziendali. Cosa conta come ricavo: l’ordine, la spedizione o la fattura? I resi si sottraggono nel mese dell’acquisto o in quello del reso? Un cliente che compra da due ragioni sociali diverse è un cliente o due? Il modello proporrà una risposta ragionevole per ognuna di queste, e la risposta ragionevole è quasi sempre diversa da quella in uso in azienda.

La validazione contro la fonte di verità. Ogni numero prodotto dal nuovo sistema va riconciliato con il numero che l’azienda già usa — il bilancio, il report del gestionale, il foglio del direttore commerciale. Se non tornano, il vostro sistema non ha ragione: ha un bug, oppure una definizione diversa che va esplicitata.

Le decisioni di riservatezza. Quali dati escono dal perimetro aziendale, verso quale fornitore, con quali garanzie contrattuali. Non è una domanda tecnica ed è l’unica che, se sbagliata, non si può correggere a posteriori.

Passo 2 — La definizione del data warehouse

Il data warehouse è il luogo dove i dati, provenienti da sistemi diversi, diventano coerenti fra loro. Non è un backup del gestionale e non è un database più grande: è una ricostruzione dei dati aziendali secondo una logica pensata per l’analisi anziché per la transazione.

La ricognizione delle sorgenti

Il primo lavoro concreto è l’inventario. Per ogni sorgente servono cinque informazioni: come si accede, con quale frequenza si aggiorna, qual è la chiave che identifica un record, come si riconosce un record modificato, e chi è il referente umano che sa spiegare le stranezze. L’ultima è la più importante e la più dimenticata.

Questo è un ottimo primo compito da dare al modello, perché il risultato è verificabile subito:

Ti allego il DDL completo dello schema gestionale (142 tabelle) e il profilo con conteggi righe e cardinalità. Analizzalo e restituiscimi: (1) le tabelle che sembrano contenere fatti transazionali e quelle che sembrano anagrafiche; (2) le relazioni che deduci, indicando se sono dichiarate come chiavi esterne o solo ipotizzate dal nome; (3) le tabelle che sospetti siano obsolete o non popolate; (4) le ambiguità che non riesci a sciogliere e su cui devo chiedere a una persona. Per ogni punto indica su cosa ti stai basando.

L’ultimo punto è quello che rende utile l’esercizio. Un modello ben istruito vi restituirà una lista di domande del tipo “esistono due tabelle clienti, anagrafica_clienti e clienti_new, entrambe popolate: quale è quella corrente?”. Sono esattamente le domande che un consulente farebbe nella prima riunione, arrivate in dieci minuti anziché in una settimana.

L’architettura a tre livelli

Qualunque sia la tecnologia, la struttura che funziona è sempre la stessa e si articola in tre livelli. È la scelta architetturale più importante del passo 2, e va imposta al modello esplicitamente, perché lasciato libero tenderà a scrivere una singola query gigantesca che fa tutto.

• Livello grezzo (raw / staging). Copia fedele della sorgente, senza trasformazioni, con l’aggiunta della data di caricamento. Non si tocca mai. Serve a poter ricostruire tutto il resto da zero quando — e succederà — scoprirete che una regola di pulizia era sbagliata.
• Livello intermedio (core). Qui avviene la pulizia: tipi normalizzati, date valide, deduplica delle anagrafiche, unione delle stesse entità provenienti da sistemi diversi, applicazione delle regole aziendali. È il livello dove si concentra il 70% del codice e il 100% delle decisioni difficili.
• Livello di presentazione (mart). Le tabelle che il sistema di BI interroga davvero: dimensioni e fatti, modellati per essere veloci e comprensibili. Devono essere leggibili da un utente esperto senza documentazione: fatti_vendite, dim_cliente, dim_prodotto, non tb_mv_003.

La separazione ha un valore pratico immediato quando lavorate con l’AI: ogni livello è un compito separato, con input e output definiti, che il modello può eseguire e voi verificare in isolamento. Un errore nel livello intermedio si scopre confrontando due tabelle, non leggendo mille righe di SQL.

La modellazione: perché lo star schema, ancora

Nel livello di presentazione la struttura da usare è lo star schema: una tabella dei fatti al centro, contenente eventi misurabili (una riga = una riga d’ordine, una riga = un movimento di magazzino), circondata da tabelle dimensionali che descrivono il contesto (chi, cosa, quando, dove).

Non è una scelta nostalgica. Ha tre motivi molto attuali. Primo: gli strumenti di BI sono costruiti attorno a questo modello e ci vanno molto più veloci. Secondo: è comprensibile da un essere umano non tecnico, e un modello dati che il direttore commerciale non capisce è un modello dati che nessuno userà. Terzo, ed è il motivo nuovo: è la struttura su cui i modelli linguistici sbagliano meno. Chiedere a un’AI di generare una query su uno star schema pulito ha un tasso di successo molto più alto che chiederle la stessa cosa su uno schema transazionale normalizzato in terza forma, dove per arrivare al nome del prodotto servono quattro join e la conoscenza di quale delle tre colonne “prezzo” è quella giusta.

Detto in altri termini: il lavoro fatto nel passo 2 è quello che rende possibile il passo 3. Chi salta la modellazione sperando che l’AI “capisca comunque” il database originale ottiene un sistema che funziona nelle demo e sbaglia i numeri in produzione.

Le tre decisioni tecniche che il modello vi farà

Ci sono tre punti su cui conviene decidere voi e istruire il modello, perché sono la fonte più comune di errori silenziosi.

La granularità della tabella dei fatti. Va dichiarata in una frase, prima di scrivere una riga di SQL: “una riga per ogni riga di ordine di vendita”. Se la granularità non è esplicita, prima o poi qualcuno farà un join che duplica le righe e il fatturato risulterà più alto del vero. È l’errore più frequente e il più difficile da individuare, perché il numero sbagliato è comunque plausibile.

La gestione della storicità delle dimensioni. Se un cliente cambia agente di zona, le vendite dell’anno scorso vanno attribuite al vecchio agente o al nuovo? Entrambe le risposte sono legittime, ma vanno scelte, non subite. Tecnicamente è la differenza fra una dimensione che si sovrascrive e una che conserva le versioni con date di validità.

La tabella delle date. Sembra un dettaglio burocratico ed è invece il pezzo che abilita metà delle analisi: anno fiscale, trimestre, settimana ISO, giorno lavorativo, festività, flag “stesso periodo anno precedente”. Va generata una volta e riusata ovunque. È anche il compito perfetto da delegare integralmente all’AI, perché è ripetitivo, verificabile e le festività italiane mobili sono noiose da calcolare a mano.

-- Tabella dei fatti: granularità dichiarata in testa, sempre.
-- GRANULARITÀ: una riga per ogni riga di documento di vendita.
CREATE TABLE mart.fatti_vendite (
    riga_documento_key   BIGINT       PRIMARY KEY,   -- chiave surrogata
    data_key             INT          NOT NULL,      -- -> dim_data
    cliente_key          INT          NOT NULL,      -- -> dim_cliente
    prodotto_key         INT          NOT NULL,      -- -> dim_prodotto
    canale_key           INT          NOT NULL,      -- -> dim_canale
    agente_key           INT          NULL,          -- -> dim_agente
    quantita             NUMERIC(14,3) NOT NULL,
    ricavo_netto         NUMERIC(14,2) NOT NULL,     -- al netto di sconti, IVA esclusa
    costo_standard       NUMERIC(14,2) NULL,
    margine_lordo        NUMERIC(14,2) NULL,         -- ricavo_netto - costo_standard
    numero_documento     TEXT         NOT NULL,      -- degenerate dimension
    caricato_il          TIMESTAMPTZ  NOT NULL DEFAULT now()
);

Le trasformazioni: farle scrivere all’AI, farle verificare al codice

La scrittura delle trasformazioni è la parte in cui il risparmio di tempo è più evidente. Ed è anche quella in cui serve la disciplina maggiore, perché il SQL generato da un modello è quasi sempre sintatticamente corretto e non sempre semanticamente corretto.

La soluzione non è rileggere tutto a mano: è pretendere che ogni trasformazione arrivi accompagnata dai suoi test. Uno strumento come dbt rende questa richiesta banale da soddisfare, perché i test sono dichiarativi e stanno in un file YAML accanto al modello.

version: 2

models:
  - name: fatti_vendite
    description: >
      Una riga per ogni riga di documento di vendita.
      Esclusi i documenti annullati e i tipi documento non fiscali.
    columns:
      - name: riga_documento_key
        tests: [unique, not_null]
      - name: cliente_key
        tests:
          - not_null
          - relationships:
              to: ref('dim_cliente')
              field: cliente_key
      - name: ricavo_netto
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: -100000
              max_value: 1000000

    tests:
      # Riconciliazione con la fonte di verità: il totale annuo del mart
      # deve coincidere con il totale annuo del gestionale entro 1 euro.
      - dbt_utils.equality:
          compare_model: ref('verifica_totali_gestionale')
          compare_columns: [anno, ricavo_netto]

L’ultimo test è il più importante di tutti e va scritto per primo. Un sistema di BI che non si riconcilia con il numero che l’azienda già conosce non verrà usato, per quanto elegante sia il modello dati sottostante. La fiducia in un sistema di BI si guadagna una sola volta e si perde a ogni scostamento inspiegato.

Quale tecnologia

La domanda arriva sempre presto e merita una risposta rapida, perché è meno decisiva di quanto sembri. Il criterio è il volume:

• Fino a qualche decina di milioni di righe — cioè la stragrande maggioranza delle PMI italiane — un PostgreSQL ben indicizzato basta e avanza. Se già lo avete, usatelo: metà dei progetti di BI naufragano sull’introduzione simultanea di cinque tecnologie nuove.
• Analisi locali, prototipi, dataset fino a qualche miliardo di righe su una sola macchina — DuckDB è oggi la risposta più efficiente, e ha il vantaggio non trascurabile di stare in un file.
• Volumi grandi, molti utenti concorrenti, necessità di scalare in orizzontale — ClickHouse in autogestione, oppure BigQuery, Snowflake o Databricks se preferite non gestire nulla e potete sostenerne il modello di costo.

Per le trasformazioni, dbt è lo standard di fatto e ha una caratteristica che lo rende particolarmente adatto al lavoro con l’AI: il progetto è fatto di file di testo — SQL e YAML — versionati in Git. È il formato che i modelli maneggiano meglio, ed è anche il formato che consente a voi di leggere un diff e capire in trenta secondi cosa è cambiato.

Passo 3 — La costruzione del modello di BI

Il data warehouse contiene dati corretti. Il modello di BI è ciò che li trasforma in risposte. È il passo che viene più spesso trascurato, con il risultato classico: un warehouse impeccabile su cui ognuno costruisce le proprie query e ottiene numeri diversi dal collega.

Il livello semantico: definire le metriche una volta sola

Il cuore del modello di BI è il livello semantico (semantic layer): un file in cui ogni metrica aziendale è definita una volta, in modo formale, e da cui tutti gli strumenti attingono. Non è un vezzo architetturale, è la soluzione a un problema organizzativo preciso: senza di esso “fatturato” è definito in diciassette posti diversi — in una dashboard, in un foglio di calcolo, nella testa di tre persone — e nessuna delle diciassette definizioni è documentata.

Con il livello semantico, la domanda “come calcoliamo il margine?” ha una risposta che si può aprire, leggere e discutere:

metriche:
  - nome: ricavo_netto
    etichetta: "Ricavo netto"
    descrizione: >
      Somma degli imponibili delle righe di vendita, al netto di sconti
      e resi, IVA esclusa. Esclude i documenti di tipo campionatura e
      i movimenti infragruppo.
    tipo: somma
    colonna: ricavo_netto
    tabella: mart.fatti_vendite
    formato: valuta_eur

  - nome: margine_lordo_pct
    etichetta: "Margine lordo %"
    descrizione: >
      (Ricavo netto - Costo standard) / Ricavo netto.
      Il costo è quello standard di listino alla data del documento,
      NON il costo medio ponderato di magazzino.
    tipo: derivata
    formula: "(ricavo_netto - costo_standard) / nullif(ricavo_netto, 0)"
    formato: percentuale

  - nome: clienti_attivi
    etichetta: "Clienti attivi"
    descrizione: >
      Clienti distinti con almeno un documento di vendita nel periodo.
      Attenzione: NON è additiva nel tempo — la somma dei clienti attivi
      mensili non dà i clienti attivi annuali.
    tipo: conteggio_distinto
    colonna: cliente_key
    non_additiva_su: [dim_data]

Notate le tre righe in maiuscolo. Sono le note che distinguono una definizione utile da un’etichetta: dicono cosa la metrica non è. Sono anche, non a caso, le informazioni che un modello linguistico non può dedurre e che dovete fornirgli voi — ma una volta fornite, il modello le userà coerentemente in ogni query che genera, cosa che un team di cinque analisti umani statisticamente non fa.

Dalle domande alle metriche, non il contrario

Il metodo che funziona per costruire il modello è partire dalle domande, non dai dati. In pratica: si raccolgono da chi lavora in azienda venti-trenta domande reali, formulate come le formulerebbero loro, e si verifica che il modello sappia rispondere a ognuna.

Le domande di partenza suonano tipicamente così: “chi sono i dieci clienti che sono calati di più rispetto all’anno scorso?”, “quali prodotti hanno margine sotto il 15%?”, “quanto pesa il canale online sul totale, mese per mese?”, “quali clienti non ordinano da più di novanta giorni?”. Sono domande banali, e proprio per questo utili: se il sistema non risponde a queste, non risponderà a niente.

È anche un compito che si delega bene all’AI, con un prompt di questo tipo:

Ti allego lo schema del livello mart e il file delle metriche. Per ciascuna delle 24 domande in fondo, scrivi la query SQL che vi risponde. Se una domanda non è rispondibile con il modello attuale, non inventare: dimmi quale dimensione, attributo o metrica manca. Alla fine dammi l’elenco dei pezzi mancanti ordinato per numero di domande che sbloccherebbero.

L’output di questo esercizio è la lista di lavoro del passo 2 — perché regolarmente scoprirete che manca la dimensione “zona commerciale” o il flag “cliente in prova” — e insieme il primo nucleo di query verificate.

Le dashboard: poche, e con una domanda per grafico

Sulla parte visibile del sistema il consiglio è di resistere alla tentazione dell’abbondanza. Una dashboard con ventotto grafici non viene letta da nessuno; tre dashboard con sei grafici ciascuna, ognuno dei quali risponde a una domanda che qualcuno si è posto davvero, vengono aperte tutti i lunedì.

Vale la pena distinguere tre tipi di superficie, perché hanno pubblici e regole diverse:

Sul fronte degli strumenti, Metabase è il più rapido da mettere in mano a utenti non tecnici, Apache Superset il più flessibile fra gli open source, Power BI la scelta naturale dove esiste già l’ecosistema Microsoft. Tutti e tre leggono senza problemi uno star schema ben fatto — che è, di nuovo, il motivo per cui il passo 2 conta più della scelta dello strumento.

La domanda in linguaggio naturale: quando funziona davvero

Arriviamo alla funzionalità che tutti chiedono per prima: scrivere una domanda in italiano e ottenere il numero. Oggi funziona, ma a una condizione precisa che è utile enunciare senza giri di parole.

Il text-to-SQL puntato direttamente sul database gestionale ha un tasso di errore inaccettabile per l’uso aziendale. Il text-to-SQL puntato su uno star schema documentato con un livello semantico esplicito ha un tasso di errore molto basso. La differenza non sta nel modello, sta in quanto contesto trova.

Il motivo è intuitivo se ci si mette nei panni del modello. Nel primo caso deve indovinare quale delle tre colonne chiamate importo è quella giusta, capire che i documenti con tipo = 'CM' sono note di credito e vanno sottratte, e sapere che le righe con flg_omaggio = 1 non fanno fatturato. Nel secondo caso trova una tabella fatti_vendite con una colonna ricavo_netto la cui descrizione dice esattamente cosa contiene e cosa esclude.

Due accorgimenti aggiuntivi rendono la funzionalità sicura da mettere in mano agli utenti. Il primo: l’accesso deve essere in sola lettura, con un timeout e un limite di righe, su una replica. Il secondo, meno ovvio ma decisivo per la fiducia: mostrare sempre la query generata accanto al risultato. Un numero senza la sua query è un atto di fede; un numero con la sua query è verificabile da chiunque in azienda sappia leggere una SELECT — e sono più persone di quante si pensi.

Un esempio completo, dall’inizio alla fine

Vediamo il percorso su un caso concreto: un’azienda che vende componenti, con un gestionale su SQL Server, un e-commerce su MySQL, un CRM in cloud e il solito foglio di calcolo con i budget per agente.

Giorno 1 — Ricognizione. Si estrae il DDL delle due basi dati e si genera il profilo delle tabelle. Il modello analizza 142 + 38 tabelle e restituisce la mappa delle entità, ventitré relazioni dedotte e nove domande. Fra queste: “esistono due tabelle di listino, una aggiornata l’ultima volta nel 2019: confermi che listini_v2 è quella corrente?”. Risposta: sì. Tempo risparmiato rispetto alla ricognizione manuale: circa tre giorni.

Giorni 2-3 — Definizioni. Questa è la parte umana. Due riunioni da un’ora con amministrazione e direzione commerciale producono le definizioni che nessuna AI poteva conoscere: il ricavo si conta alla fattura, i resi si attribuiscono al mese del reso, un cliente è identificato dalla partita IVA e non dal codice gestionale (perché tre clienti hanno due codici a testa), l’anno fiscale coincide con quello solare, il costo da usare per il margine è quello standard di listino e non il medio ponderato. Cinque righe scritte su un documento condiviso, che diventeranno il contesto di tutto il resto.

Giorni 4-6 — Livello grezzo e intermedio. Il modello genera lo script di caricamento incrementale, i modelli di staging per ogni tabella sorgente e i modelli intermedi con la deduplica delle anagrafiche per partita IVA. Un test rivela subito che l’unione produce 4.812 clienti a fronte dei 5.104 codici gestionali: la deduplica funziona. Un secondo test rivela 47 righe con partita IVA nulla, che si scoprono essere clienti privati esteri; si aggiunge una regola per gestirli.

Giorni 7-9 — Livello mart. Star schema con una tabella dei fatti a livello riga d’ordine, cinque dimensioni e la tabella delle date con il calendario delle festività italiane. Il test di riconciliazione fallisce al primo tentativo: il fatturato 2025 risulta inferiore di 38.400 euro rispetto al bilancio. L’indagine, condotta insieme al modello sul dato reale, individua un tipo documento — le fatture di sola spesa di trasporto — che era stato escluso. Corretto: differenza a zero. Questa giornata, presa da sola, giustifica l’intero metodo: senza il test di riconciliazione l’errore sarebbe entrato in produzione.

Giorni 10-12 — Modello di BI. Diciotto metriche definite nel livello semantico, ognuna con la sua descrizione e le sue esclusioni. Le 24 domande raccolte all’inizio vengono passate al modello: 21 hanno risposta, 3 no perché manca la dimensione “zona commerciale”, che sta solo nel foglio di calcolo dei budget. Si aggiunge come sorgente, e diventano 24 su 24.

Giorni 13-15 — Dashboard e consegna. Tre cruscotti: direzionale, commerciale, prodotti. Interrogazione in linguaggio naturale attivata sul livello semantico, con visualizzazione della query. Documentazione generata dai file del progetto.

Tre settimane, con una persona sola. Il paragone onesto non è con “sei mesi di consulenza”, perché una parte di quel tempo serviva comunque alle riunioni e alle decisioni; è con le tre settimane di lavoro artigianale — scrivere SQL, documentare, testare — che nel progetto tradizionale si sommavano a quelle riunioni. Quella parte è ciò che l’AI ha assorbito.

Il documento di contesto: il vero moltiplicatore

Se c’è una singola pratica che separa un progetto riuscito da uno frustrante, è questa: mantenere un documento di contesto che viene passato al modello all’inizio di ogni sessione di lavoro. Nei progetti gestiti con un agente da terminale è letteralmente un file nel repository, che l’agente legge da solo.

Deve contenere, in una pagina o poco più: l’obiettivo del progetto e le domande a cui deve rispondere; le definizioni aziendali decise (quelle di cui sopra); l’architettura a tre livelli e le convenzioni di denominazione; la regola che ogni modello nasce con i suoi test; le stranezze note delle sorgenti — le date segnaposto al 1900, il tipo documento che non fa fatturato, i due codici dello stesso cliente; e il divieto esplicito di inventare: se un’informazione manca, il modello deve chiederla, non dedurla.

Il ritorno di questa pagina è sproporzionato rispetto al tempo che costa scriverla. Senza, ogni sessione ricomincia da zero e il modello reintroduce allegramente gli errori che avevate corretto la settimana prima. Con, l’output è coerente per settimane e il sistema di BI mantiene una sua logica riconoscibile invece di essere la somma di quaranta decisioni scollegate.

Sei errori che fanno fallire questi progetti

1. Saltare il data warehouse e puntare l’AI direttamente sul gestionale. Funziona nella demo e produce numeri sbagliati in produzione, per il motivo detto sopra: il modello non ha modo di sapere quali righe vanno escluse. È la scorciatoia più costosa del settore.
2. Non riconciliare con la fonte di verità. Se il fatturato del nuovo sistema non coincide con quello del bilancio, il progetto è fermo finché non si capisce perché. Andare avanti “tanto è una differenza piccola” significa costruire su una crepa.
3. Lasciare che sia il modello a definire i termini aziendali. Proporrà definizioni ragionevoli e coerenti, che non sono quelle in uso in azienda. Il risultato è un sistema tecnicamente corretto che nessuno riconosce come proprio.
4. Accettare SQL senza test. Il codice generato è sintatticamente valido quasi sempre e semanticamente corretto spesso: è il divario fra “quasi sempre” e “spesso” a rovinare i numeri, e solo i test lo intercettano.
5. Costruire cinquanta dashboard prima di avere cinque utenti. Le dashboard che nessuno apre generano manutenzione senza generare valore. Meglio tre cruscotti usati davvero e la possibilità di farne altri in un pomeriggio.
6. Trattarlo come un progetto che finisce. Le sorgenti cambiano, le definizioni evolvono, i modelli migliorano. Senza qualcuno che presidia i test e aggiorna il documento di contesto, il sistema degrada in silenzio e ci si accorge del problema quando un numero sbagliato arriva in una riunione.

Checklist prima di dire che il sistema è pronto

• Le definizioni aziendali sono scritte in un documento e approvate da chi le usa.
• L’architettura è a tre livelli e il livello grezzo è ricostruibile da zero.
• Ogni tabella dei fatti dichiara la propria granularità in una frase.
• Esiste una tabella delle date completa di anno fiscale, settimane e festività.
• Ogni modello ha almeno un test di unicità e uno di integrità referenziale.
• Esiste un test di riconciliazione con la fonte di verità aziendale, e passa.
• Le metriche sono definite in un livello semantico, con le esclusioni esplicitate.
• Le venti-trenta domande di partenza hanno tutte una risposta verificata.
• Il caricamento è incrementale, schedulato e notifica i fallimenti.
• L’accesso in linguaggio naturale, se attivo, è in sola lettura e mostra la query generata.
• Il documento di contesto è aggiornato e sta nel repository.
• Qualcuno, con nome e cognome, è responsabile della manutenzione.

Conclusioni

Farsi sviluppare un sistema di Business Intelligence dall’intelligenza artificiale non significa delegare il pensiero: significa delegare la parte del lavoro che non ne richiedeva. La ricognizione delle sorgenti, la scrittura delle trasformazioni, la generazione dei test, la documentazione, la tabella delle date — è l’80% delle ore di un progetto di BI, ed è la parte che oggi si comprime da mesi a giorni.

Il 20% che resta è però quello che decide se il sistema verrà usato o abbandonato: sapere quali domande contano, sapere cosa significano le parole che l’azienda usa, e pretendere che ogni numero prodotto si riconcili con un numero già noto. Sono attività umane, non perché l’AI non sia capace, ma perché l’informazione necessaria non è nei dati — è nelle persone.

Il consiglio operativo per partire è di restringere il campo: una sola area aziendale, una sola tabella dei fatti, cinque metriche, dieci domande. Un sistema piccolo che risponde correttamente a dieci domande vale infinitamente di più di un data warehouse completo su cui nessuno si fida dei numeri — e da lì l’estensione è una questione di aggiungere sorgenti, non di rifare l’architettura.