Master Data Management brings order to an organisation's master data: customers, suppliers, materials, products, employees and financial accounts. We design a master data layer independent of ERP and CRM, together with quality rules, deduplication, approval workflow and an audit trail. We start with one domain and a measurable outcome, not with a programme spanning several quarters.
Ask four systems who a customer is and you get four answers: the ERP has the registered name, the CRM an abbreviation, procurement has no tax identification number on file, and the warehouse still holds an address from two moves ago. Each entry is locally correct; none of them describes the whole picture. What this costs almost never shows up as a budget line, because it hides inside manual reconciliation, invoice corrections and reports nobody can quite stand behind.
Master Data Management introduces one master record - the golden record - created by rules rather than by agreement in a meeting. Source systems keep their operational role, while the master version of the data is single, with a named owner, change history and an audit trail. The MDM layer stays independent of ERP and CRM, so replacing the ERP or the CRM does not undo the order in the data.
The MDM market usually sells programmes measured in quarters. The longer a phase runs without a visible result, the harder it becomes to keep the business engaged and to defend the budget - and that is usually where a programme loses momentum. Our answer is methodological: one domain, a clear success criterion, a result visible in weeks, and only then a wider scope. We deliver implementations on SNOK MDM, our own platform, and also run advisory projects in SAP environments.
Management reporting no longer requires manual reconciliation, because the definition of the master record is the same for every company and system. This matters in particular for groups built through acquisitions, where each acquired company brings its own catalogues and dictionaries.
Deduplication of material indexes reduces situations in which an organisation buys a part that is already on the shelf under a different name. Well-organised customer data reduces the number of corrections and clarifications in invoice processing.
An agent or a language model answers on the basis of the data it is given. Without a master data layer, automation propagates existing inconsistencies faster instead of removing them. Gartner predicts that through 2026 organisations will abandon 60% of AI projects unsupported by AI-ready data (Gartner press release, 26 February 2025).
Article 5(1)(d) of the GDPR requires personal data to be accurate and, where necessary, kept up to date. KSeF, the mandatory Polish e-invoicing scheme, requires a structured, machine-validated invoice: schema errors, an invalid tax identification number format or missing mandatory fields mean a rejected document and manual work. An audit trail, historisation and field-level access control are a requirement here, not an add-on.
We check where discrepancies arise, how many real duplicates exist in the selected domain, who is accountable for the data and which processes suffer most. The outcome is a map of the problem with priorities, not a general recommendation.
We design the master record schema for the selected domain, together with validation and normalisation rules, conflict resolution between sources and versioning principles.
We combine deterministic rules with language models that recognise different ways of writing the same company, person or material. Every merge proposal reaches a data steward with a justification - the decision is made by a human.
We implement data ownership, approval workflow for changes, history, access control with masking of sensitive fields, and data quality reporting. We define the scope of governance per domain: who owns the data, who approves a change, which fields are subject to access control and how quality is measured. The rules are written down in a document that stays with the client. Our practice draws on the DAMA-DMBOK body of knowledge and on ISO 8000, the data quality standard - as a methodological reference, not a certification; what is certified at SNOK are management systems compliant with ISO 27001:2022 and ISO 9001:2015.
The master layer feeds the ERP, CRM, warehouse and operational systems. We deliver integrations with SAP S/4HANA and ECC, Microsoft Dynamics 365, Salesforce, Oracle Cloud ERP, Workday and non-standard sources.
We advise on SAP Master Data Governance and on preparing data before the conversion to S/4HANA, including cleaning up customers ahead of the Business Partner conversion. We stay vendor-neutral: we recommend the solution that fits the scale and the ecosystem, not one chosen in advance.
We start with a discovery workshop, where we select one data domain and one success criterion. We then assess that domain against the organisation's live data, design the master record model and its quality rules, and launch a pilot.
A single-domain pilot usually takes 4-8 weeks and ends with a specific set of deliverables: a working master data layer for the selected domain, a documented master record model with quality rules, live feeds to target systems, a governance document naming the data owners, and a data quality report from before and after the pilot. The success criterion is agreed at the start and expressed in measurable terms - for example the share of duplicates in the customer domain, or the number of records missing mandatory fields.
Only after a confirmed result do we extend the scope to further domains, developing governance, the data accountability model and quality monitoring in parallel. Two scales are worth separating: a single-domain pilot takes 4-8 weeks, while a full programme covering every domain and organisation-wide governance is still measured in quarters. The difference is when the first result becomes visible, not the total scope of work.
We also run advisory projects without deploying the platform, where the right answer is to bring order to data in the client's existing ecosystem. We price each phase as a fixed price, with a defined scope and deliverable.
Technology stack
SNOK holds ISO 27001:2022 and ISO 9001:2015 certificates. SNOK MDM can run in the client's infrastructure, and the source code can be placed in escrow where business continuity policy requires it.
| Approach | What it solves | What it does not solve |
|---|---|---|
| One-off data clean-up before a project | The state of the data file on migration day | Re-contamination a few months later, because there are no rules at the point of data entry |
| Warehouse or lakehouse (Snowflake, Microsoft Fabric, Databricks) | Collecting, modelling and analysing data | Deciding which customer record is the correct one and who is accountable for it |
| SAP Master Data Governance | Master data governance inside the SAP ecosystem | Data from non-SAP systems, and cases where the layer has to stay independent of the ERP |
| An MDM platform independent of the ERP (SNOK MDM) | A golden record across many systems, quality rules, an audit trail | Operational processes, which continue to live in the source systems |
Article 5(1)(d) of the GDPR requires personal data to be accurate, and the data of people representing business partners is personal data. KSeF, the mandatory Polish e-invoicing scheme, introduces a structured, machine-validated invoice in which incomplete or inconsistent customer data increases the risk of a rejected document and of exceptions handled manually. DORA requires financial entities to demonstrate where critical data sits and who has access to it, which without a master data layer comes down to a manual inventory at every audit.
It is for organisations that
It is not for organisations that
The anti-patterns we see most often
Chemicals group after five acquisitions
Brought master data from five companies in three countries into order without rebuilding the source systems: a shared model of materials, suppliers, products and financial accounts as the basis for group-level reporting.
Medicover
SNOK MDM deployed across an environment spanning 18 countries and 45,000 employees: master data with validation, approval workflow and full change history, handling around 100,000 employee data record events per year. The client acts as a reference for employee master data.
Capital group with a fragmented system landscape
Advisory project: a model of a master data layer independent of ERP and CRM, together with the split between master data and reference data and the sequence for rolling out domains.
A golden record is one master record describing a real object: a specific customer, material, product or employee. It is created by combining data from multiple systems according to defined quality and conflict resolution rules. Source systems continue to operate, while the master version is single, has an owner, a change history and an audit trail.
We usually close a single-domain pilot in 4-8 weeks, ending with a working master data layer and data quality measures. Classic MDM programmes on the market are planned over a horizon of several quarters to several years. Our method reverses the order: first a confirmed result on one domain, then a wider scope.
MDM answers the question of who and what, identifying customers, materials, products and employees. RDM provides the shared language: dictionaries, codes, classifications and organisational units. Without RDM, master records are described differently in every system and reports still diverge.
Yes, and it is a good moment for this work. In S/4HANA the Business Partner model is mandatory, and customer and vendor master records are moved onto that model by Customer Vendor Integration. CVI exists to carry data into the new model, not to improve its quality: duplicates and gaps in mandatory fields do not disappear during the conversion - they either pass through to the target system or hold the conversion up on an exception list. How long that exception list turns out to be depends on configuration and mapping, which is why the scale of the problem is established by measurement rather than assumption.
A warehouse and a lakehouse handle collecting, modelling and analysing data, but they do not decide which customer record is the correct one or who is accountable for its quality. Snowflake Horizon and Microsoft Fabric provide cataloguing and governance rather than a complete master data layer - the golden record, record matching and data steward work have to be brought in separately, through your own solution or a partner integration. Without that layer, analytics consolidates inconsistencies instead of removing them.
The number of domains in scope, the number of systems that have to be read and fed, the condition of the incoming data, and the requirements for governance and the audit trail. We bill per phase with a defined scope and deliverable, not for open-ended time. Scope and pricing are agreed after the discovery workshop, because before the state of the data is measured, any figure would be guesswork.
An extract from one domain of a source system is enough - a customer file or material indexes, for example - together with a description of the fields. We do not need production access to begin the measurement, and personal data can be pseudonymised at this stage.
Yes. SNOK MDM runs in the client's environment where security policy or IT architecture require it, and the source code can be placed in escrow for business continuity purposes.
Against data quality measures agreed before the start: the number of duplicate records in the domain, the share of records with gaps in critical fields, the number of discrepancies between systems, and the time it takes to process a change to master data. We compare the result with the baseline measurement from the discovery stage.
We agree the place of processing before the project starts. Models can run in the client's infrastructure or in a cloud environment within the European Union - the choice depends on the security policy and the data categories involved. The model proposes record merges, while the decision is approved by a data steward, so a human stays in the loop. The scope and legal basis for processing personal data are set out in a data processing agreement, and access to sensitive fields is controlled and masked.
KSeF requires a structured, machine-validated invoice. Schema errors, an invalid tax identification number format or missing mandatory fields cause the document to be rejected. Inconsistent and outdated customer data in source systems increases the risk of rejections, corrections and manual work in accounting - including cases where a formally valid but substantively wrong tax identification number passes technical validation. Bringing the customer domain into order before the KSeF process goes live reduces such situations.
We advise vendor-neutrally. In the SAP ecosystem we work with SAP Master Data Governance, and solutions from global vendors make sense at the right scale and budget. SNOK MDM addresses mid-sized companies and capital groups in Poland, where what matters is a short path to a result, a fixed price per phase and the option to run inside the client's own infrastructure.
We start with a duplicate measurement on one data domain. Using a sample from your system we show how many records describe the same entity, how many entries have gaps in critical fields, and where the discrepancies between systems arise. You receive the result within five working days.
Page last updated: 2026-07-26
Entry point
Send us a sample from one domain and within five working days you receive a short summary with figures: how many records describe the same entity, how many entries have gaps in critical fields, and which systems diverge the most.
Deliberately limited scope
What happens next
Duplicate measurement, then a discovery workshop, then a single-domain pilot. Three steps, each with its own deliverable.
We will write back with what sample format we need and how we will handle it. Confirmation goes to the address you provided.
