The data exists.
The work is making it readable.
One archive, normalised, yours.
Customer records in the management system, hours in HR, orders in the e-commerce, the rest in spreadsheets. Every system keeps its data in the format that suits itself: reading them together takes a technical job every single time. Normalising means stopping doing that job again.
One archive, readable without instructions.
A management system writes data for itself: the information about a single product ends up across several tables, with field names designed for the machine that fills them in. That isn't a flaw - it's built to record, not to be questioned.
how many hours did we spend on the Acme account in 2025?
[1/4]export the hours from the HR system
[2/4]export the orders from the management system
[3/4]cross-reference the two files by hand, hoping the customer names match
[4/4]a number nobody feels like double-checking
two days · one person · no record of how it was calculated
→412.5 hours · 38 activities · 4 people
sources: management system (orders), HR (timesheets), e-commerce (contacts)
permissions: visible to the Operations department
one question · 1.2 s · the sources are in the answer
The difference between the two answers isn't anyone's speed: it's how the underlying data is written.
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
Normalising means putting that information back into a readable structure: explicit names, a single unit of measure, the relations in the right place - even when there are five sources that have never spoken to each other. Same question, same answer: whether it's asked by a person or by an agent.
The data layer
A relational database that imports from ERP, HR, e-commerce, spreadsheets. Every source keeps its origin, but speaks a single language.
→ one source only
The middleware
The engine that keeps the data current and exposes it outward through controlled APIs. No system touches the management software directly any more.
→ traceable access
The MCP server
The layer that makes the data readable by an LLM: any model, any tool, always within the permissions of whoever is asking.
→ when needed, not before
It isn't a data lake and it isn't an enterprise platform. It's a layer the size of the problem, built to measure and hosted wherever you decide. Most companies don't need large-group infrastructure: they need a handful of tables, done well.
The code is yours. And so is the data. Whatever you decide next.
Four dependencies fewer. And no new ones.
It isn't a technical detail: it's the difference between deciding your own data strategy and waiting for someone else to decide it.
- 01
From your ERP's roadmap
You don't have to wait for the vendor to build the feature you need, or hope they put it on the schedule. The layer evolves at your pace, not theirs.
- 02
From the ERP vendor
Your data no longer hangs on a negotiation. If you switch management systems one day, the history stays where it is: one input source changes, you don't start over.
- 03
From the model you'll use
No LLM is wired in. One today, another tomorrow, or one on-premise if the data can't leave: the consumer changes, the infrastructure doesn't.
- 04
From the single tool
With an MCP server the data is available to any tool that asks for it, securely and traceably. You don't build one integration at a time, forever.
Worth it even if AI never arrives.
This work makes sense on its own. If in two years you decide AI isn't for your company, the problems you already had today stay solved anyway.
Cross-referenced data without asking anyone
ERP and HR in the same question: people, costs and activity in one go. Before, that took a technical job every time.
Numbers without going through IT
Whoever needs a figure takes it, without opening a ticket and without knowing the structure of the management system.
Integrations that stop multiplying
Systems draw from a single, current source. Fewer exports, less copy-pasting, fewer different versions of the same number.
Four phases. A deliverable at every step.
- $ 01 · map
Mapping
We look at what's there: applications, tables, spreadsheets, who uses what and why. Out comes a readable document saying where the data is and what it costs to bring it together. It's the first step - and from here you can also decide to stop.
- $ 02 · model
Data model
We design the normalised structure: entities, relations, granularity. This is the phase where the choices that last for years get made, so it's the one we discuss the most.
- $ 03 · pipe
Ingestion and APIs
We build the engine that brings the data in and exposes it out, with permissions in the right place from day one.
- $ 04 · mcp
AI access
We add the MCP layer: the data becomes queryable in natural language and available to the agents working for you. When it's needed: it's the last phase, not the first.
The phases are bought one at a time. You don't need to sign for all of it to start: the mapping is already a finished piece of work, even if the project goes no further.
It isn't a job for everyone. With a single application and few users, a good export and a well-written query solve the same problem with fewer resources. And if today's data is thin and dirty, the layer doesn't fix it: it only makes it more visible. These are things you see during mapping, before they become a project.