Il problema che tutti hanno e nessuno ha ancora risolto
Negli ultimi tre articoli di questa serie abbiamo parlato di cosa sia la Generative BI, di come il Vibe Coding stia trasformando lo sviluppo, e di quanto la governance rimanga centrale anche nell’era dell’AI. Oggi arriviamo al nodo che rende tutto questo possibile.
Un LLM sa scrivere qualsiasi linguaggio. Sa costruire misure complesse, gestire relazioni tra tabelle, produrre query SQL ottimizzate. Sa lavorare con PowerBI, con SAP BO, con QlikSense, con Looker. La competenza tecnica non è il problema.
Il problema è il contesto. Il tuo contesto.
Immagina di assumere uno sviluppatore eccellente, con anni di esperienza su tutte le tecnologie che usi. Il primo giorno gli mostri l’elenco delle tabelle del tuo datawarehouse e gli chiedi di costruire un KPI sul margine commerciale. Cosa succede? Probabilmente ti chiederà: qual è la logica del margine nella tua organizzazione? Quali esclusioni si applicano? Da dove viene il dato dei resi? Come si gestiscono i centri di costo condivisi?
Non perché non sappia lavorare, ma perché non ha ancora capito il tuo business, il tuo dominio, il tuo patrimonio informativo. Conoscere le tabelle non basta. Serve la formazione sul contesto.
Un LLM agentico si trova nella stessa situazione. Puoi dargli accesso alle tue piattaforme di BI, ma se non ha una rappresentazione strutturata e comprensibile del tuo patrimonio informativo, lavorerà al buio. Produrrà qualcosa, ma non necessariamente quello che serve al tuo business.
E il problema si complica ulteriormente quando consideri la realtà di un’organizzazione enterprise: non hai una piattaforma, ne hai più di una. PowerBI per alcuni dipartimenti, QlikSense per altri, SAP BO per il finance, magari Looker per i prodotti digitali. Ogni piattaforma ha la propria struttura, i propri oggetti, la propria logica, il proprio linguaggio. Ogni tentativo di dare contesto all’LLM deve fare i conti con questa eterogeneità.
Come si fa a dare a un agente AI una visione unitaria del proprio patrimonio di BI, che attraversa piattaforme diverse, formati diversi, logiche diverse, senza dover parlare di PowerBI o di SAP BO, ma semplicemente di Business Intelligence?
Da questa domanda nasce Open Business Intelligence (OpenBI).
La storia della tecnologia insegna che quando i sistemi diventano troppo eterogenei, la soluzione non è diventare più bravi a gestire la complessità. La soluzione è creare un livello di astrazione comune.
TCP/IP ha unificato reti fisicamente diverse. HTML ha reso il web accessibile indipendentemente dal server sottostante. SQL ha permesso di interrogare database con un linguaggio unico. Ogni volta che la complessità è esplosa, è emerso uno standard.
Per la Business Intelligence, quello standard non esisteva ancora.
OpenBI: un linguaggio, qualsiasi piattaforma
OpenBI è un modello standard aperto progettato per rappresentare qualsiasi asset di Business Intelligence in un formato unico, indipendente dalla piattaforma.
Report, dashboard, modelli semantici, dataflow, tabelle di database, report paginati, applicazioni analitiche: qualunque oggetto tu stia lavorando, OpenBI lo descrive con una struttura comune, chiara e leggibile, sia dagli esseri umani che dai modelli di linguaggio.
La conseguenza è semplice ma profonda: invece di avere tanti formati quante sono le piattaforme, hai un formato unico. E chi deve lavorare con questi oggetti, un LLM, uno strumento di governance, un sistema di migrazione, impara a lavorare con un solo standard tecnologico.
Un LLM che conosce OpenBI può costruire oggetti per PowerBI, QlikSense, SAP BO e Looker sapendo esattamente come farlo: DAX, SQL, LookML, le espressioni di QlikSense, tutto. Ma è l’MCP Server a dirgli come usarli, dove applicarli e in quale contesto, oggetto per oggetto. Il modello non indovina: segue istruzioni precise, costruite attorno alla struttura OpenBI.
Questo cambia radicalmente il punto di partenza. Non parti più chiedendoti “come si fa questo in PowerBI?” Parti chiedendoti “di che analisi ho bisogno?” e la piattaforma diventa un dettaglio implementativo, non un vincolo progettuale.
Il costo nascosto della specializzazione
Lavorare nella Business Intelligence enterprise oggi significa costruire team di specialisti per ogni piattaforma adottata. L’esperto di PowerBI che padroneggia DAX e Power Query. L’esperto ETL con anni di esperienza sulle logiche di Qlik. Il data engineer che conosce i modelli semantici di SAP BO. Il developer Tableau che sa esattamente come costruire calculated fields complessi.
Questa specializzazione ha un costo doppio. Il primo è ovvio: trovare, formare e mantenere profili tecnici verticali su tecnologie proprietarie è costoso e lento. Il secondo è meno visibile ma forse più pesante: anche per task relativamente semplici, devi sempre passare per chi conosce quella specifica piattaforma.
Chi lavora in BI lo sa bene. Hai un report che non aggrega correttamente un dato, o una misura DAX che si comporta in modo strano su certi filtri. Non è un problema complesso, ma per risolverlo hai bisogno di qualcuno con la conoscenza giusta. E quella persona ha il calendario pieno.
È come avere un collega brillante che conosce perfettamente quella tecnologia. Lo cerchi quando hai un problema. A volte risponde subito, a volte aspetti ore. Dipende da quando lui ha dieci minuti liberi per ascoltarti.
Con OpenBI e un LLM guidato dall’MCP Server, quello specialista è sempre disponibile. Non hai bisogno di cercarlo in agenda: puoi descrivere il problema in linguaggio naturale e ricevere una soluzione concreta, una misura DAX corretta, una trasformazione rivista, un modello semantico aggiornato in tempo reale. Mentre magari stai già lavorando ad altro.
Non è la fine della specializzazione. Gli esperti di piattaforma restano preziosi per le architetture complesse, per le scelte strategiche, per la governance tecnica. Ma per il lavoro quotidiano, quel continuo flusso di piccole e medie richieste che rallentano la produttività, avere un agente specialista sempre disponibile cambia completamente i ritmi.
E cambia anche chi può fare cosa. Un analista di business con buona conoscenza del dominio può oggi costruire e modificare asset di BI che prima richiedevano il coinvolgimento obbligatorio di un tecnico. Il lavoro torna al centro del business, non si ferma ad aspettare la coda tecnica.
OpenBI MCP Server: il ponte tra l’AI e le tue piattaforme
Lo standard da solo non basta. Serve uno strumento che permetta agli LLM di usarlo concretamente per lavorare con i sistemi reali che hai in azienda.
OpenBI MCP Server è un server MCP (Model Context Protocol) open source che fa esattamente questo. Fornisce all’LLM le istruzioni su come compilare oggetti in formato OpenBI e si occupa di tradurli verso la piattaforma di destinazione, pubblicandoli direttamente.
Come funziona nella pratica
Immagina di chiedere al tuo assistente AI: “Crea un report sulle vendite per regione e per categoria prodotto, con i dati dell’ultimo trimestre, filtrato per i mercati europei.”
Con OpenBI MCP Server, l’LLM sa scrivere DAX, SQL, le espressioni di QlikSense, il LookML di Looker. La differenza è che non deve indovinare come applicarli: è il server a fornirgli le istruzioni specifiche per ogni oggetto: come compilarlo, quali campi richiede, dove pubblicarlo, come validarlo. L’LLM ragiona sulla logica di business; l’MCP Server traduce quella logica nelle operazioni concrete sulla piattaforma.
Lo stesso identico prompt, su QlikSense, produce un’app QlikSense. Su Looker, un report Looker. La logica di business rimane al centro; la piattaforma è intercambiabile.
Cosa puoi fare oggi con OpenBI MCP Server
- Costruire report e dashboard su PowerBI, QlikSense, SAP BO, Looker tramite linguaggio naturale
- Creare modelli semantici e strutture dati descrivendo le esigenze del business
- Modificare asset esistenti senza aprire l’interfaccia grafica della piattaforma
- Pubblicare direttamente sulle piattaforme target senza passaggi manuali
- Lavorare su più piattaforme con un unico strumento e un unico linguaggio
La governance che finalmente abbraccia tutto il parco BI
Uno degli effetti più potenti di avere un linguaggio comune non riguarda la creazione, ma la comprensione di quello che già esiste.
La maggior parte delle aziende ha decine, a volte centinaia di report distribuiti su più piattaforme. Nessuno sa con certezza cosa fa ciascuno, chi lo usa, da quali dati dipende, se è ancora aggiornato.
Ogni piattaforma ha il suo catalogo, la sua documentazione, la sua logica e non si parlano.
Con OpenBI, tutti questi oggetti diventano confrontabili. Un report Webi di SAP BO e un report di PowerBI sono entrambi, in OpenBI, un “report”. Hanno gli stessi attributi, la stessa struttura descrittiva, lo stesso posto nel catalogo. Puoi finalmente trattarli come quello che sono: due implementazioni diverse dello stesso concetto.
Cosa diventa possibile con un linguaggio unico:
- Audit dell’intero parco BI con una sola interrogazione
- Lineage tra asset su piattaforme diverse (questo report dipende da questa tabella che alimenta quella dashboard su un’altra piattaforma)
- Documentazione automatica e coerente su tutto l’ecosistema
- Confronto tra oggetti analoghi su piattaforme diverse per identificare duplicati e incoerenze
- Migrazione guidata da una piattaforma all’altra con comprensione del contesto
Puoi chiedere in linguaggio naturale: “Quali report usano la metrica ‘Margine Lordo’?” e ottenere una risposta che copre PowerBI, QlikSense e SAP BO insieme. Non piattaforma per piattaforma, ma tutto insieme.
La vera Generative BI: non risposte veloci, ma lavoro certificato
C’è un malinteso diffuso su cosa significhi Generative BI. Molti la immaginano come un chatbot più sofisticato: fai una domanda, ricevi una risposta elaborata, magari con un grafico allegato.
Questa visione è limitante e in un contesto aziendale, potenzialmente pericolosa. Le decisioni di business non si prendono su risposte generate al volo da un modello che non conosce il contesto, che non ha tracciabilità, che non è stato validato.
La Generative BI che abilita OpenBI è qualcosa di diverso.
Non è: “faccio una domanda e ottengo una risposta”
È: “lavoro come prima, con gli stessi standard di qualità e governance, semplicemente molto più veloce”
Un report costruito con OpenBI MCP Server è un report reale, pubblicato sulla tua piattaforma, con la tua struttura dati, le tue metriche certificate, i tuoi processi di validazione. Non è un output temporaneo di una conversazione. È un asset aziendale, versionato, tracciato, governato.
Prima, sviluppare un report complesso richiedeva giorni o settimane tra analisi dei requisiti, sviluppo, testing e rilascio. Con OpenBI e un LLM, la prima versione può essere pronta in minuti. Ma quella versione segue gli stessi percorsi di approvazione, rispetta gli stessi standard semantici, vive nello stesso catalogo degli asset sviluppati tradizionalmente.
La velocità è reale. La solidità è reale. Non si escludono a vicenda, anzi, per la prima volta è possibile averle insieme.
Open source: perché uno standard deve essere aperto
OpenBI non è un prodotto chiuso. È un modello aperto, e questa scelta non è casuale.
Uno standard che funziona deve essere adottabile da chiunque, estendibile dalla community, verificabile da tutti. Un formato proprietario non è uno standard: è un lock-in con un altro nome.
OpenBI MCP Server sarà rilasciato come progetto open source il 21 maggio 2025. Chiunque potrà esaminarlo, contribuire, costruirci sopra. Le aziende che lo adottano non dipendono da un vendor: dipendono da uno standard aperto, come dipendono da SQL o da HTTP.
È questo che rende OpenBI un’infrastruttura, non un prodotto.
Conclusione — Il punto di partenza, non il punto d’arrivo
In questa serie abbiamo percorso un cammino: dalla promessa della Generative BI, ai rischi del vibe coding senza controllo, alla necessità della governance, fino ad arrivare qui, allo standard che rende tutto questo realizzabile in modo solido.
OpenBI non è la risposta definitiva. È il punto di partenza. È lo strato fondativo senza il quale la Generative BI rimane un esperimento costoso, interessante, ma non industrializzabile.
Con uno standard aperto, con un MCP Server che porta l’AI dentro le piattaforme reali, con un catalogo che unifica asset eterogenei in un linguaggio comune, la BI smette di essere un problema tecnico da risolvere piattaforma per piattaforma e diventa finalmente quello che dovrebbe essere sempre stato: uno strumento di business, al servizio di chi prende decisioni.
📌 Prossimi passi
Questo è il quarto articolo di una serie di quattro, in cui abbiamo approfondito la Generative BI, analizzando rischi, opportunità e le migliori soluzioni per integrare l’IA nella Business Intelligence.