Per anni, chi lavorava con i dati ha seguito un principio non scritto ma universalmente condiviso: prima la visualizzazione, poi — forse — la documentazione. Prima la dashboard, poi il readme. Prima il KPI sul grafico, poi la spiegazione di come è calcolato. La documentazione era sempre l'ultimo passo, quello che si rimandava, quello che spesso non arrivava mai.
Con l'intelligenza artificiale applicata ai dati, quel principio si è rovesciato. E le organizzazioni che non se ne accorgono stanno costruendo su fondamenta instabili proprio nel momento in cui investono di più.
Dal "visualization first" al "documentation first"
Nel paradigma tradizionale della business intelligence, l'obiettivo era arrivare il prima possibile a qualcosa di visibile: una dashboard, un report, un numero su uno schermo. La documentazione — le definizioni delle metriche, le regole di calcolo, le eccezioni — era un'aggiunta successiva, spesso delegata a chi aveva tempo, che di solito non era nessuno.
Il risultato è quello che chiunque abbia lavorato in un'azienda strutturata conosce bene: la stessa voce di fatturato calcolata in modo diverso nel report del commerciale, in quello del controller e in quello della direzione. Ognuno ha le sue ragioni storiche. Nessuno ha torto. Ma nessuno ha scritto da nessuna parte qual è la versione ufficiale e perché. Finché a leggere quei dati era un essere umano con anni di esperienza aziendale, queste ambiguità venivano gestite in modo informale. Con l'intelligenza artificiale, questo non funziona più.
Nel nuovo paradigma — quello che l'AI impone — l'ordine si inverte: prima si documenta come funziona il business, poi si chiede all'AI di ragionarci sopra. Prima le definizioni condivise, poi le visualizzazioni. Prima le regole scritte, poi gli agenti. È un cambiamento che sembra sottile ma ha implicazioni profonde su come le organizzazioni devono strutturare il proprio patrimonio di dati.
Gli agenti AI non tollerano l'ambiguità
Un agente AI non ha memoria storica, non ha colleghi da interpellare, non sa distinguere tra la versione "ufficiale" di una metrica e quella "ufficiosa". Lavora con quello che trova — e se trova definizioni inconsistenti, produce risposte inconsistenti. Non lo fa per negligenza: semplicemente non ha gli strumenti per risolvere in autonomia le ambiguità che un essere umano esperto gestirebbe con una telefonata.
Per funzionare in modo affidabile, un sistema AI ha bisogno di trovare documentate in modo esplicito le regole di business, le definizioni condivise delle metriche, le eccezioni e i casi limite, i confini operativi entro cui può agire autonomamente. Questa struttura di conoscenza — che in ambito tecnico si chiama semantic layer o ontologia aziendale — non è un lusso: è la precondizione per qualsiasi progetto AI sui dati che voglia produrre risultati affidabili.
Il problema: la business logic è nel posto sbagliato
Nelle aziende con anni di BI alle spalle, quella conoscenza in realtà esiste — ma è nel posto sbagliato. È incorporata in formule calcolate dentro i workbook, in campi rinominati, in soglie visive, in filtri contestuali costruiti nel tempo da persone che non lavorano più lì. È conoscenza reale, ma è dispersa, non governata e spesso contraddittoria: il tipico risultato di anni di paradigma "visualization first", dove ognuno costruiva la propria dashboard nel modo che riteneva più corretto.
La soluzione non è tecnologica in senso stretto. È prima di tutto organizzativa: portare quella conoscenza fuori dai workbook, metterla in un posto solo, darle un nome ufficiale e una definizione condivisa. Da lì, la tecnologia giusta può fare il resto.
Tre strade per arrivarci
In Deimos affrontiamo questo problema con tre approcci, a seconda del contesto tecnologico e degli obiettivi del cliente.
La strada dello stack moderno aperto: Snowflake e dbt
Per le organizzazioni che vogliono costruire un'architettura dati flessibile e indipendente dal singolo vendor, il percorso che abbiamo adottato con diversi clienti parte dall'introduzione di Snowflake come data warehouse centralizzato e di dbt come strumento di trasformazione e documentazione dei dati.
Il lavoro si articola in tre livelli — il cosiddetto modello a medaglione. Nel primo livello, quello bronze, i dati vengono caricati così come arrivano dalle sorgenti aziendali: gestionali, CRM, fogli Excel, sistemi legacy. Nel secondo livello, quello silver, i dati vengono puliti, normalizzati e messi in relazione tra loro. È qui che si inizia a costruire un linguaggio comune: i campi vengono rinominati in modo coerente, le duplicazioni vengono eliminate, le incongruenze storiche vengono gestite in modo esplicito e tracciabile.
Il terzo livello, quello gold, è dove vive la business logic vera e propria. In dbt ogni metrica — il fatturato netto, il margine per linea di prodotto, il tasso di riacquisto, qualunque KPI rilevante per il business — viene definita in un modello SQL con un nome preciso, una descrizione in linguaggio naturale, i test automatici che ne verificano la correttezza e la documentazione accessibile a tutti. Quella definizione è la versione ufficiale, approvata, versionata nel codice. Non esiste un'altra.
Da quel layer gold attingono sia Tableau per le visualizzazioni sia gli agenti AI per le analisi autonome. In questo contesto Tableau smette di essere il posto dove vive la logica di business e torna a fare quello che sa fare meglio: esplorare, visualizzare e comunicare conoscenza già strutturata a monte. Il risultato è un ecosistema in cui ogni strumento fa il suo mestiere, e nessuno deve compensare le lacune degli altri.
La strada tutta in casa Salesforce: Tableau Next
Con l'arrivo di Tableau Next, chi è già nell'ecosistema Salesforce ha oggi una seconda strada — più integrata e con meno componenti da gestire. Non serve introdurre un data warehouse esterno né un nuovo strumento di trasformazione: la governance della business logic avviene direttamente dentro la piattaforma.
Il cuore di questa strada è il modello semantico di Tableau Next. Si tratta di uno strato di definizione centralizzato in cui è possibile creare metriche certificate — con nome, formula di calcolo, dimensioni di analisi, filtri di contesto e documentazione allegata — che diventano disponibili in tutta la piattaforma. Una metrica definita una volta nel modello semantico è la stessa metrica che appare in una dashboard, in un'analisi ad hoc, in un alert automatico e nelle risposte di un agente AI.
Il lavoro da fare in questa strada è in parte diverso rispetto alla prima: invece di costruire pipeline di trasformazione in SQL, si lavora direttamente sui dataset pubblicati in Tableau e sulle sorgenti dati connesse a Salesforce Data Cloud. Si mappano le metriche esistenti — spesso disperse nei vecchi workbook — le si ripulisce, le si porta a una definizione condivisa e le si formalizza nel modello semantico. Da quel momento in poi, qualunque strumento della piattaforma — Tableau Classic, Tableau Next, gli agenti Agentforce — lavora sulla stessa fonte di verità.
Per le aziende che hanno già investito in Salesforce e Tableau, questa strada riduce la complessità architetturale, elimina la necessità di gestire infrastrutture aggiuntive e accelera i tempi di adozione. È la scelta naturale quando l'obiettivo è portare l'AI dentro un ecosistema Salesforce già consolidato, senza aprire un cantiere tecnologico parallelo.
La terza strada: Snowflake e Tableau Next insieme
C'è un terzo scenario che nella pratica è spesso il più realistico, soprattutto per le organizzazioni di medie e grandi dimensioni: usare Snowflake e Tableau Next non come alternative, ma come strati complementari di una stessa architettura.
Il motivo è semplice: i due strumenti risolvono problemi diversi e non si sovrappongono. Snowflake — con dbt — è un motore di ingestion, trasformazione e storage. Gestisce volumi elevati, sorgenti eterogenee, logiche di pulizia complesse. Il modello semantico di Tableau Next è invece uno strato di definizione business: nomi condivisi, metriche certificate, governance degli accessi, integrazione nativa con gli agenti AI. Messi in sequenza, ciascuno fa il suo mestiere senza invadere il territorio dell'altro.
L'architettura concreta funziona così: le sorgenti aziendali alimentano Snowflake, dove dbt costruisce i tre livelli bronze, silver e gold. Tableau Next si connette al layer gold come fonte dati e ci costruisce sopra il modello semantico — aggiungendo le definizioni di business, la certificazione delle metriche e l'accesso strutturato per gli agenti Agentforce. Tableau Classic, Tableau Next e l'AI consumano tutti da quella stessa fonte di verità.
Questa architettura mista ha senso in particolare in questi casi:
- I dati rilevanti arrivano da fuori Salesforce. ERP, sistemi logistici, database legacy, fonti IoT: Snowflake e dbt sono molto più attrezzati per ingestion e armonizzazione rispetto a Data Cloud da solo. Una volta strutturati nel layer gold, Tableau Next li aggancia e aggiunge la governance semantica sopra.
- L'azienda ha già Snowflake attivo. Non ha senso dismettere un'infrastruttura consolidata. Si connette Tableau Next direttamente al layer gold esistente e si costruisce il semantic layer sopra, senza rifare l'architettura dati da zero.
- Coesistono dati Salesforce e dati operativi. Data Cloud gestisce ottimamente i dati CRM, Service Cloud e Marketing Cloud. Per i dati operativi — fatture, magazzino, produzione, logistica — Snowflake è più adatto. La strada mista permette di unire i due mondi e presentarli in modo coerente nel semantic layer di Tableau Next.
- Altri strumenti consumano gli stessi dati. Se nell'organizzazione esistono anche Power BI, applicazioni custom o API che leggono i dati, il layer gold in Snowflake rimane accessibile a tutti. Il semantic layer di Tableau Next serve l'ecosistema Salesforce; Snowflake serve il resto dell'organizzazione.
Vale la pena sottolineare che questa non è un'architettura improvvisata: Salesforce e Snowflake supportano ufficialmente questo scenario attraverso la funzionalità di Zero Copy tra Snowflake e Data Cloud. I dati presenti in Snowflake possono essere resi disponibili a Data Cloud — e quindi a Tableau Next e ad Agentforce — senza duplicarli né spostarli fisicamente. È la connessione certificata tra i due ecosistemi, e riduce in modo significativo sia i costi di storage sia la complessità operativa.
Come scegliere
Le tre strade non sono gerarchiche — nessuna è intrinsecamente migliore delle altre. La scelta dipende dallo stack tecnologico esistente, dal grado di investimento nell'ecosistema Salesforce, dalla provenienza e complessità dei dati da governare, e dalla velocità con cui si vuole arrivare a risultati concreti.
Il nostro lavoro inizia sempre dalla stessa domanda: dove vive oggi la tua business logic, da dove arrivano i tuoi dati, e chi ha il mandato per renderla ufficiale? Da lì, costruiamo il percorso più adatto — che passi per Snowflake e dbt, per Tableau Next, o per una combinazione strutturata dei due.
Da dove si comincia
Prima di qualsiasi agente, prima di qualsiasi modello AI, prima di qualsiasi nuova piattaforma, vale la pena rispondere a tre domande:
- Le metriche chiave del business hanno una definizione scritta, condivisa e approvata?
- Se due reparti producono lo stesso indicatore, il risultato coincide?
- Un nuovo collaboratore può capire come funzionano i dati senza dover chiedere a qualcuno?
Se la risposta è no — o anche solo "dipende" — il lavoro da fare è quello. E il momento giusto per farlo è adesso, prima che l'AI amplifichi le incoerenze invece di eliminarle.
Affianchiamo le aziende in questo percorso: dalla mappatura della logica di business esistente alla scelta e implementazione dell'architettura più adatta, fino all'introduzione di AI su fondamenta solide e verificabili. Contattaci per un primo confronto.