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.

Four dependencies fewer. And no new ones.

The code is yours. And so is the data. Whatever you decide next.

One archive, readable without instructions.

A management system writes data for itself: 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. Normalising means putting it back into a readable structure - explicit names, a single unit of measure, the relations in the right place - for whoever needs to find it: a person or an agent.

diff --statcustomer #481211 fields · 3 origins → 8 fields · 1 table
− before · three systems
management system · ERP

CLI_ANA.RGSOC1ACME SRL

CLI_ANA.PIVA0841…968

ORD_TES.DTORD20250914

ART_MAG.QTA_DISP12,000

human resources

ts.hours7.5

ts.project_refACM-25

dept.codeOPS

e-commerce

customer.emailordini@acme…

order.created_at2025-09-14

order.total1240.00

+ after · one table
the same company, written into two tables of the management system under two different keys.the same company, written into two tables of the management system under two different keys.the e-commerce is the only system holding the contact: without the layer it never makes it into a report.two systems, two date formats. Here it's a single field.an amount with an explicit currency, not a number without a unit.quantity in units, not "12,000" to be interpreted.the HR hours attached to the right customer through the relation, not by hand.code replaced by the name: readable by a person and by an agent.

The data layer

A relational database that imports from ERP, HR, e‑commerce and spreadsheets. Every source keeps its origin, but speaks a single language.

The middleware

The engine that keeps the data current and exposes it through controlled APIs. No system touches the management software directly any more.

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.

Worth it even if AI never arrives.

Cross-referenced data without asking anyone

ERP and HR in the same question: people, costs and activity in one go.

Numbers without going through IT

Whoever needs a figure takes it, without opening a ticket.

Integrations that stop multiplying

Systems draw from a single, current source. Fewer exports, less copy-pasting.

Four phases. A deliverable at every step.

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. And with a single application and few users, a good export and a well-written query solve the same problem with fewer resources: these are things you see during mapping.

Data warehouse + AI · Fashion & luxury eventsCompany DWH with middleware and MCPSee how we did it

Is your data ready? Let's start with a mapping.

merge@beecreative.it copied to clipboard