Master Data Management (MDM) for companies

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.

Yes. SNOK MDM works as a master data layer above the ERP and CRM. Source systems such as SAP S/4HANA, SAP ECC, Microsoft Dynamics 365 or Salesforce keep their operational role, while the master version of each customer or material is held once, with an owner, a change history and an audit trail. Replacing the ERP later does not undo the order in the data.

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 cost depends on 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.

Yes. SNOK MDM runs at Medicover in an environment spanning 18 countries and 45,000 employees, in the employee master data domain. For a chemicals group we brought the data of five companies in three countries into one model of materials, suppliers, products and financial accounts, without rebuilding the source systems.

SAP Master Data Governance is the natural choice when the whole landscape is SAP and the priority is the change process inside SAP; there we advise on selection and architecture. SNOK MDM covers six domains on one platform (employees, customers, materials, suppliers, products and financial accounts), takes SAP and non-SAP sources alike, runs on-premise, in the client's environment or as a service, and is priced at a fixed price per phase. The first domain goes live in 4-8 weeks: that is the time to a first result, not a limit on scope.