I dati esistono.
Il lavoro è renderli leggibili.
Un archivio unico, normalizzato, vostro.
Anagrafiche nel gestionale, ore nell'HR, ordini nell'e-commerce, il resto in fogli di calcolo. Ogni sistema tiene i suoi dati nel formato che serve a lui: per leggerli insieme serve ogni volta un lavoro tecnico. Normalizzare vuol dire smettere di rifarlo.
Un archivio unico, che si legge senza istruzioni.
Un gestionale scrive i dati per sé: le informazioni di un singolo prodotto finiscono su più tabelle, con nomi di campo pensati per la macchina che li riempie. Non è un difetto - è fatto per registrare, non per farsi interrogare.
quante ore abbiamo speso sul cliente Acme nel 2025?
[1/4]esportare le ore dal gestionale HR
[2/4]esportare gli ordini dal gestionale
[3/4]incrociare i due file a mano, sperando che i nomi cliente coincidano
[4/4]un numero che nessuno ha voglia di ricontrollare
due giorni · una persona · nessuna traccia di come è stato calcolato
→412,5 ore · 38 attività · 4 persone
fonti: gestionale (ordini), HR (timesheet), e-commerce (contatti)
permessi: visibile al reparto Operations
una domanda · 1,2 s · le fonti sono nella risposta
La differenza fra le due risposte non è la velocità di nessuno: è come sono scritti i dati di partenza.
CLI_ANA.RGSOC1ACME SRL
CLI_ANA.PIVA0841…968
ORD_TES.DTORD20250914
ART_MAG.QTA_DISP12,000
ts.hours7.5
ts.project_refACM-25
dept.codeOPS
customer.emailordini@acme…
order.created_at2025-09-14
order.total1240.00
Normalizzare vuol dire rimettere quelle informazioni in una struttura leggibile: nomi espliciti, un'unità di misura sola, le relazioni al posto giusto - anche quando le fonti sono cinque e non si sono mai parlate. Stessa domanda, stessa risposta: che a farla sia una persona o un agente.
Il layer dati
Un database relazionale che importa da ERP, HR, e-commerce, fogli di calcolo. Ogni fonte tiene la sua origine, ma parla una lingua sola.
→ una fonte sola
Il middleware
Il motore che tiene i dati aggiornati e li espone all'esterno via API controllate. Nessun sistema tocca più il gestionale in diretta.
→ accesso tracciato
Il server MCP
Lo strato che rende i dati leggibili da un LLM: qualsiasi modello, qualsiasi tool, sempre nei limiti dei permessi di chi chiede.
→ quando serve, non prima
Non è un data lake e non è una piattaforma enterprise. È un layer della dimensione del problema, costruito su misura e ospitato dove decidete voi. Alla maggior parte delle aziende non serve un'infrastruttura da grande gruppo: servono poche tabelle, fatte bene.
Il codice è vostro. E anche i dati. Qualunque cosa deciderete dopo.
Quattro dipendenze in meno. E nessuna nuova.
Non è un dettaglio tecnico: è la differenza fra decidere la vostra strategia sui dati e aspettare che la decida qualcun altro.
- 01
Dalla roadmap del vostro ERP
Non dovete aspettare che il fornitore sviluppi la funzione che vi serve, né sperare che la metta in programma. Il layer evolve al vostro ritmo, non al suo.
- 02
Dal fornitore dell'ERP
Il patrimonio dati non dipende più da una trattativa. Se un domani cambiate gestionale, lo storico resta dov'è: cambia una fonte in ingresso, non si ricomincia da zero.
- 03
Dal modello che userete
Nessun LLM è cablato dentro. Oggi uno, domani un altro, o uno on-premise se i dati non possono uscire: cambia il consumatore, non l'infrastruttura.
- 04
Dal singolo strumento
Con un server MCP i dati sono disponibili a qualsiasi tool che li chieda, in modo sicuro e tracciato. Non si costruisce un'integrazione per volta, per sempre.
Serve anche se l'AI non arriva mai.
Questo lavoro ha senso da solo. Se fra due anni deciderete che l'AI in azienda non vi serve, i problemi che avevate già oggi restano risolti lo stesso.
Dati incrociati senza chiedere a nessuno
ERP e HR nella stessa domanda: persone, costi e attività in un colpo solo. Prima serviva un intervento tecnico ogni volta.
Numeri senza passare dall'IT
Chi ha bisogno di un dato se lo prende, senza aprire un ticket e senza conoscere la struttura del gestionale.
Integrazioni che smettono di moltiplicarsi
I sistemi pescano da una fonte sola e aggiornata. Meno esportazioni, meno copia-incolla, meno versioni diverse dello stesso numero.
Quattro fasi. A ogni passo una consegna.
- $ 01 · map
Mappatura
Si guarda cosa c'è: applicativi, tabelle, fogli di calcolo, chi usa cosa e perché. Ne esce un documento leggibile che dice dove sono i dati e quanto costa metterli insieme. È il primo passo - e da qui si può anche decidere di fermarsi.
- $ 02 · model
Modello dati
Si progetta la struttura normalizzata: entità, relazioni, granularità. È la fase in cui si fanno le scelte che poi durano anni, quindi è quella in cui si discute di più.
- $ 03 · pipe
Importazione e API
Si costruisce il motore che porta i dati dentro e li espone fuori, con i permessi al posto giusto dal primo giorno.
- $ 04 · mcp
Accesso AI
Si aggiunge lo strato MCP: i dati diventano interrogabili in linguaggio naturale e disponibili agli agenti che lavorano per voi. Quando serve: è l'ultima fase, non la prima.
Le fasi si comprano una alla volta. Non serve firmare tutto per iniziare: la mappatura è già un lavoro finito, anche se il progetto non prosegue.
Non è un lavoro per tutti. Con un applicativo solo e pochi utenti, un buon export e una query scritta bene risolvono lo stesso problema con meno risorse. E se i dati di oggi sono pochi e sporchi, il layer non li aggiusta: li rende solo più visibili. Sono cose che si vedono già in mappatura, prima che diventino un progetto.