Freelance MDM Semarchy xDM consultant: a practical guide

People often mix up Semarchy's two products. xDI moves and transforms data from one system to another; xDM decides which version of that data is authoritative. A freelance MDM Semarchy xDM consultant works on the second front, the more political of the two: the one where you decide, among fifteen near-identical customer records, which becomes the reference for the entire company. It's a less visible topic than integration, but it's the one that determines whether your campaigns, invoices and stock levels rest on accurate data or on a pile of approximations. Here's what this engagement really involves.

xDM is not xDI — and that changes everything

Semarchy xDM is a Master Data Management platform. Its purpose fits in one sentence: to produce a golden record — a single, reliable reference record for each business entity: a customer, a product, a supplier, a store. Where an integration tool merely lets data pass through, xDM confronts it, cleans it, reconciles it and keeps its history. The difference is one of nature, not of degree.

In practice, I see plenty of companies that first equipped their flows — with Semarchy xDI or another ETL — only to realize, two years later, that the real problem wasn't moving data but knowing which data to trust. Three customer repositories that don't talk to each other, the same supplier entered under four different spellings, product codes that change from one country to the next. That's when an MDM project takes off, and when an xDM consultant becomes useful.

What an xDM consultant actually does

Modeling the reference data

It all starts with modeling. Before writing a single rule, you have to decide which entities are "master," which attributes make them up, and where each attribute draws its value from. This work looks more like an investigation than development: you have to question the business, understand why two departments disagree on what an "active customer" is, and arbitrate. xDM is flexible here — its model is built within the application itself — but that flexibility becomes a trap if no one holds the line. A model that grows without direction ends up as unreadable as the mess it was meant to replace.

Writing the matching and survivorship rules

This is the technical heart of the job. Matching brings together records that refer to the same real-world entity despite their differences: "Dupont SARL," "Dupont S.A.R.L." and "DUPONT sarl" should merge. Survivorship then decides which value wins, attribute by attribute — the most recent address, the VAT number from the most reliable source, the most complete label. These rules look simple on paper. In production, they expose every awkward case: namesakes that must never be merged, sources that contradict each other, partial records. A good configuration is judged by how it handles the exceptions, not by how it behaves on the easy cases.

Equipping quality and governance

A golden record stays accurate only if it's monitored. xDM lets you define data quality controls, dashboards and validation workflows where a human steward approves or corrects the cases the machine couldn't resolve. Setting up these loops — who gets alerted, who fixes things, at what cadence — is an integral part of the engagement. Without them, an MDM project produces a fine initial state and then quietly degrades, until the day no one trusts the repository anymore.

Feeding the master data back into the IS

A golden record is only valuable if it flows back into the systems that need it: the ERP, the CRM, e-commerce, the marketplace. This is where xDM and xDI meet. The data consolidated in xDM has to be published, and it's often integration — through xDI or an ESB — that redistributes it. Having both skills in the same head avoids a classic MDM-project failure: an immaculate repository that nobody consumes, because no one thought through distribution. My background as a freelance Semarchy xDI consultant lets me handle the full chain, from reconciliation to publishing.

When to bring in an MDM consultant?

A few signals that almost always come up before an xDM project:

• Several applications each hold "the" customer or product repository, and none is authoritative.
• Marketing or logistics teams spend an enormous amount of time deduplicating by hand before every operation.
• A merger, an acquisition or an IS overhaul forces previously separate repositories to be reconciled.
• A marketplace or data project finally demands a single source of truth on products and suppliers.

In these situations, the challenge isn't to buy yet another tool but to set rules everyone agrees on. The consultant brings as much method as technique: they get the departments talking, translate their disagreements into configurable rules, and deliver a repository the business takes ownership of rather than merely endures.

Freelancer or consultancy for an xDM project?

Semarchy xDM remains a niche technology. The people who genuinely master it — not just in theory, but with golden records that have gone live in production — are rare, including within consultancies. Bringing in a specialist freelancer gives you direct access to the person doing the configuration, with no middleman to dilute the expertise. For a well-scoped perimeter — a data domain to clean up, a repository to take over, matching rules to revise — it's often the most effective format and the quickest to get started.

A consultancy still makes sense for a multi-year, multi-domain MDM program, with a framework contract and a team to mobilize. The downside is well known: project-based billing, turnover among the people assigned, and genuine xDM expertise that depends on who's allocated. On a technology this specialized, always insist on the precise track record of the person who'll actually do the work — not the company's.

How to assess an xDM profile

A few questions that quickly separate real experience from a thin veneer:

• Across how many domains (customer, product, supplier and so on) have you already modeled master data in xDM?
• How do you handle matching false positives and merges that need to be undone?
• What survivorship strategy do you recommend when two reliable sources contradict each other?
• How do you publish the golden record to the consuming systems, and with which tool?

Concrete answers speak of lived cases: a banking merger with namesakes that must not be grouped together, a retail product repository with thousands of partial duplicates, a handover where the history had to be replayed. Vague answers give away a profile that knows the interface without ever having lived through production.

Retail, MDM's natural home

Commerce and retail are among the earliest adopters of MDM, and for good reason: enormous product catalogs, multiple suppliers, stores, omnichannel customers. A single reference exists in ten different forms across the PIM, the ERP, the point of sale and the marketplace. My experience with data integration projects for retail and with Semarchy xDI / Stambia connectors gives me a concrete grasp of these ecosystems — which helps in modeling a repository that fits the business rather than a textbook model.

Remote work and availability

An xDM project runs perfectly well remotely: modeling workshops over video, configuration on shared environments, business sign-off through the tool's workflows. I work remotely for retailers and software vendors across France, and on-site in the Hauts-de-France (Lille, Valenciennes, Douai, Lens) depending on the project's needs.

In summary

A freelance MDM Semarchy xDM consultant doesn't move data — they decide which data is authoritative, and they make sure that decision holds over time. Modeling the master entities, matching and survivorship rules, quality, governance, then publishing back to the IS: the value rests as much on method as on technique. On a niche technology like xDM, the right profile shows in concrete cases and in a clear vision of how the golden record gets distributed. If you have a repository to make trustworthy or an MDM project getting underway, let's talk before the first rules are set in stone.