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.
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 spreads the mess faster rather than removing it. 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.
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 the state of the data in that domain using the organisation's real data, design the master record model and 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.
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.
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 this is the best moment. In S/4HANA the Business Partner model is mandatory, and customer and vendor master records are converted through Customer Vendor Integration. CVI maps and synchronises data but does not replace a data quality project: gaps can block synchronisation, and duplicates pass through to the target system as separate records. Cleaning up and deduplicating customers before the conversion reduces migration errors and manual work after go-live.
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.
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 a short time to result, a fixed price per phase and the option to run in the client's infrastructure are what count.
During an initial conversation we discuss which master data domains cause the most manual work today, which systems need to be fed with master data, and what the scope of the discovery workshop and the single-domain pilot looks like.
