Implementation · SAP MDG and other MDM platforms

MDM implementation, end to end

We design the master data model, configure MDM, cleanse the master data and connect your business systems. Methodology, architecture and development sit in one team: the people who design the solution also implement it.

  • SAP MDG and other MDM platforms
  • Years of MDM experience
  • Go-live in waves
  • Master data cleansing within the project
  • Any consuming systems
  • SAP PO or your own integration middleware

Requests

  • Procurement
  • Warehouse
  • Production
  • Sales
MDMgolden record
  • checks and duplicates
  • approval
  • publication

Consuming systems

  • ERP
  • Finance
  • SAP
  • WMS
  • EAM
  • DWH

What you get after implementation

  • One master data source for all business systems

  • Fewer duplicates and conflicts between databases

  • Clear roles and workflows for create and change requests

  • Reconciliation of one object across systems

  • Controlled publication of golden records to ERP, business systems and document management

Our clients include

  • Nornickel
  • Transneft
  • X5 Group
  • Weatherford
  • Vale
  • Shell
  • Statoil
  • Nordgold
  • Highland Gold
  • Binnopharm
  • EKF
  • Trident Energy
  • Greenatom
  • Klyuchavto
  • Tiger Realm Coal
  • RANEPA

Definition

What MDM implementation means: one item, one record in every system

MDM implementation is a project after which the company has one source of master data: materials, products, vendors and customers, organisational structure. Each item is created once, goes through checks and approval, and then reaches every system in the same form.

Without MDM

One bolt, three records

  • ERPBolt M12x60 galv.
  • WarehouseBOLT M12*60 ISO 4014
  • ProcurementBolt zinc plated 12 by 60

Stock, purchasing and reporting count three different items. They can only be matched by hand.

With MDM

One golden record

Fasteners › Bolts

Bolt, hex head: M12×60, ISO 4014, zinc plated

Thread
M12
Length
60 mm
Standard
ISO 4014
Coating
zinc
ApprovedERPWarehouseProcurement

The record is created once from the class template and reaches every system with one code.

This is an illustration. In a project, naming templates and attribute sets are built from your master data.

When you need it

When it is time to implement MDM

MDM is needed where the same master data lives in several systems, departments and subsidiaries, and errors in it hit procurement, the warehouse, production and reporting.

  • Different master data rules across departments and sites

  • Duplicates and mismatches of the same domain between systems

  • Data is updated late and this causes errors in operations

  • A lot of manual work on master data maintenance

  • Integrations break because there is no common data model

  • Moving to a group model a group ERP or a new ERP

  • A complex distributed landscape dozens of databases, several platforms

  • No single source of data for ERP, the data warehouse and reporting

A large catalogue but no master data team? You can start not with a full MDM but with checks at entry to the catalogue. That is new material requests with checks, and it also works on top of an MDM you already have.

Stages

Stages of MDM implementation

Five stages, and for each one you know in advance what we do and which documents you get. We configure MDM and cleanse master data in parallel, so clean data is loaded at go-live.

  1. Stage 01

    Assessment and design

    What we do

    • We set up the steering committee and working groups and fix the project goals
    • We assess the master data, the data and the integration flows
    • We review the current master data rules and business requirements
    • We design the target data model and request processes

    What you get

    • Project charter
    • Target data model and master data register: where the master system is, where the consuming systems are
    • Integration diagram
    • Design decisions for MDM configuration
  2. Stage 02

    MDM configuration

    What we do

    • Master data domains and attribute sets
    • Workflows for create and change requests
    • Roles and access rights
    • Data quality rules and control reports

    What you get

    • Working MDM in a test environment
    • Request and approval processes by the role model
    • Quality controls and reports
  3. Stage 03

    Master data cleansing

    What we do

    • Quality audit and search for typical errors
    • Search for duplicates and attribute conflicts
    • Reconciliation of the same object across databases
    • Agreeing disputed records with your experts

    What you get

    • Data quality report
    • Register of duplicates, conflicts and disputed records
    • Golden data ready to load into MDM
  4. Stage 04

    Integrations

    What we do

    • Publication of data from MDM to business systems
    • Exchange through the corporate integration middleware or directly
    • Message format, acknowledgements, error handling and resends

    What you get

    • Exchanges work in the test environment
    • Clear statuses and mismatch control
    • Data migration concept
  5. Stage 05

    Testing, training and go-live

    What we do

    • Test programme and methodology, end-to-end checks
    • Cutover plan and go-live checklist
    • Training for key users and end users
    • Go-live in waves, stabilisation and warranty support

    What you get

    • Test reports
    • User and administrator guides
    • Pilot operation and handover to support

Master data cleansing

Within the implementation or as a separate project

Cleansing does not have to be part of an MDM implementation. It can be done separately, before you choose a platform or in a system that already runs. Read more on the page about master data cleansing.

  • Within a turnkey implementation

    We run it in parallel with MDM configuration, so golden data is loaded at go-live.

  • As a separate project

    We clean up the existing catalogue before MDM or without it.

  • By your own team

    We hand over the Synopps methodology and tools and support you on disputed cases.

Project management

Who is responsible for what

Every project document has an owner. Weekly status, a risk and issue log, working meetings on master data domains, and separate architecture decisions on disputed points.

Project documents

Results of an MDM implementation project

MDM implementation is more than a configured system. It is a data model, rules and workflows by which master data is maintained after go-live. These are the key project documents.

Master data registerStage 1
DomainMaster systemConsuming systemsOwner
MaterialsMDMERP, WMS, EAMMaster data team
Vendors and customersMDMERP, DMSFinance
Units of measureMDMall systemsMaster data team
Organisational structureHR systemMDM, ERPHR
For each domain it is decided where it is maintained, where it goes and who owns it.
Class naming templateStages 2 and 3

Class: Bolts

TypeThread×LengthStandard,Coating

  • Threadmandatory
  • Length, mmmandatory
  • Standardmandatory
  • Coatingoptional

Bolt, hex head: M12×60, ISO 4014, zinc plated

The description is built from attributes, so identical items do not differ in spelling.
Workflow for a new item requestStage 2
  1. RequestRequester
  2. Automatic checkstemplate, mandatory attributes, duplicate search
  3. Class and attribute checkMaster data lead
  4. ApprovalData owner
  5. Publicationto consuming systems

Duplicate found: the request goes back to the requester with a link to the existing item

Role model and workflows: who creates, who checks, who approves.
Publication matrixStage 4
ERPWMSEAMDWH
Materials
Vendors and customers
Equipment
Units of measure

publishednot published

Which domain goes to which system. Exchange statuses and mismatches are visible in control reports.

We also hand over:

  • Project charter
  • Integration diagram
  • Data quality report
  • Test programme and methodology
  • User and administrator guides
  • Master data maintenance SOP

The documents are shown as examples. In a project they are built from your master data and systems.

Request scenarios

Where users create requests: three MDM scenarios

One of the main choices in the project. It drives user convenience, integration complexity, timeline and cost. We choose together with you at the design stage.

  • Recommended to start

    A

    Working directly in MDM

    The whole process of creating and processing requests runs in MDM. One point of control for the process and the data. Rules, duplicate checks and approvals in one place. Minimal changes to business systems, a fast start, simple support.

    ComplexityLow

    Users need to get used to working in a separate system.

  • B

    Starting from the business system

    The user starts in their own system and opens MDM with a button. A familiar entry point. Logic, checks and approvals stay in MDM. Lower risk than a full single window.

    ComplexityMedium

    You need to plan authentication and the parameters passed, and adapt the source systems.

  • C

    Single window in business systems

    The user works in their own system, MDM processes the request and returns the result. Maximum comfort: no switching between systems.

    ComplexityHigh

    Changes in every system, complex returns and comments, risk of status mismatches, longer timeline and higher cost.

What we recommend. For a reliable, controlled go-live, start with scenario A. Scenario B is a sensible balance between convenience and control. Scenario C is possible, but it is better left for a later stage, once the process is stable.

Timeline and cost

How long MDM implementation takes and what it costs

We give the exact timeline and cost after a kick-off meeting and a short assessment. Below are guidelines and what they depend on.

Timeline guidelines

We go live in waves. We start the next wave only when the first works steadily and the architecture, integrations and data governance model are proven.

What the cost depends on

We price the project by stage: the scope and result of each stage are clear before work starts.

  • How many master data domains move to MDM
  • Volume and condition of the data, how much cleansing is already done
  • How many systems and databases are in the integration landscape
  • Number of roles, approval workflows and reports
  • Request scenario: in MDM or in your business systems
  • Whether historical data needs migration

Risks

MDM implementation risks and how we manage them

The same causes delay MDM projects again and again. We record them at the start, track them in the risk log and close them with decisions at the design stage.

  • The integration flows are only clarified at the end of the project

    The integration diagram and master data register are ready at stage 1, before MDM is configured

  • Duplicates and incomplete records are loaded into MDM

    We cleanse in parallel with configuration, so golden data is loaded at go-live

  • Consuming systems bypass MDM and items are created locally

    Publication matrix and mismatch control show where a record appeared outside MDM

  • Approvals on the client side take too long

    Steering committee at milestones, an issue log, an owner for every document

  • A domain has no owner, and maintenance rules conflict

    Data owners and the role model are fixed in the project charter

  • Users do not accept the new system

    We choose the request scenario around users and train key and end users before go-live

MDM practice

Extending a standard MDM where it falls short

In large groups a standard MDM runs into the specifics of distributed production. Here are two extensions we build in projects.

  • Extension

    Different accounting roles for one record

    The same item is accounted for differently at different plants and in different databases: as finished goods in one, as semi-finished goods in another. The accounting group is set in the request for each database. The result: one record, no duplicates and no manual fixes on site.

  • Extension

    Publication without programming

    Rules on which records go to which systems are set in the user interface: domain, selection condition, list of consuming systems. Fewer manual export errors, new domains connect faster, and the rules are the same for all consuming systems.

Which platforms we implement

For companies on SAP we implement SAP MDG. We also work with other MDM platforms and help choose the solution and edition for the scale of your master data and integration landscape.

  • SAP MDG
  • Other MDM platforms

Our own tools

We speed up master data cleansing with our own AI modules

Synopps modules take over routine work: duplicate search, classification, splitting descriptions into attributes. The decision on every disputed case stays with an expert.

  • Synopps Data Health

    For the catalogue you already have

    Duplicate and equivalent search, classification, descriptions by template.

    Learn more
  • Synopps New Record

    Creating new items

    Checks at entry: class, attributes, duplicates, confirmation from external sources.

    Learn more
  • Synopps Core

    Inside your MDM

    The same request checks inside your SAP, ERP or MDM, without a separate interface.

    Learn more

Experience

MDM implementation projects

We have implemented, developed and supported MDM in metals, pharmaceuticals, automotive retail, pipeline transport, manufacturing and the public sector. Several projects are described in detail.

96,000requests processed in 12 months in a master data outsourcing project in SAP MDG for a pipeline operator
6 industriesmetals, pharmaceuticals, automotive retail, pipeline transport, manufacturing, public sector
Full cyclemethodology, architecture, implementation, cleansing and support in one team
  • Pharmaceuticals

    MDM implementation and data cleansing for a pharmaceutical manufacturer

    Master data centralised, MDM integrated with consuming systems through the corporate middleware, corporate master data cleansed.

    • MDM
    • ERP
    • WMS
    Case study
  • Automotive retail

    Master data centralised for a network of car dealers

    A combined MDM and group ERP solution, methodology and cleansing of the material and vendor master data.

    • MDM
    • ERP
    Case study
  • Metals

    MDM roll-out to several assets

    Redesigned maintenance processes for materials, services and vendors, master data cleansed during the roll-out.

    • SAP MDM
    Case study
  • Public sector

    MDM and related systems adapted for a university

    MDM, group ERP and public sector accounting systems adapted, integrations developed and supported.

    • MDM
    • ERP
    Case study

More projects in completed projects.

FAQ

MDM implementation: common questions

What is MDM and why does a business need it?

MDM is a system and a way of managing master data: materials, products, vendors and customers, organisational structure and other domains. It gives the company one source of reliable data for ERP, warehouse and business systems, analytics and reporting. Each item is created once, goes through checks and reaches every system in the same form.

What does an MDM implementation project include?

Assessment of data and processes, design of the target data model, MDM platform configuration, master data cleansing, integrations with business systems, testing, user training and go-live in waves. At the end the company has a working MDM and a master data maintenance SOP.

How long does MDM implementation take?

A pilot on one domain can go live in 2 to 3 months. A production implementation usually takes 4 to 9 months and depends on the number of domains, the volume and condition of the data, the number of systems in the integration landscape and the migration requirements.

How much does MDM implementation cost?

The cost depends on the number of domains, the volume and quality of the data, how much cleansing is already done, the number of connected systems and the request scenario. We price the project by stage after a kick-off meeting and a short assessment, so you see what you pay for at each step.

Does master data need cleansing before MDM?

Yes, before or during the implementation. If you load duplicates, incomplete records and inconsistent naming into MDM, the system simply centralises the existing mess. Cleansing can be a separate project, done by your team with our methodology, or part of a turnkey implementation. In a turnkey project we run it in parallel with MDM configuration, so golden data is loaded at go-live.

Can MDM be implemented in stages?

Yes, and we recommend it. The first wave usually covers materials and vendors. Later waves add financial dimensions, organisational structure and other domains only after the architecture, integrations and data governance model are proven.

Which systems can be connected to MDM?

ERP, HR and finance systems, document management, SAP, warehouse systems, procurement and maintenance systems, data warehouses and analytics. We build the exchange through the corporate integration middleware or directly if there is none.

How do you choose an MDM platform?

The choice depends on the IT landscape, the number of domains, data volume, integration requirements, the complexity of approval workflows and the budget. For companies on SAP we implement SAP MDG. We help choose the solution and edition for your task before the implementation starts.

How is MDM different from a catalogue in ERP?

A catalogue in ERP serves one system. MDM manages master data for all systems at once: it checks an item at creation, looks for duplicates, runs approval and publishes the golden record to every database. With more than one system, data drifts apart over time without MDM.

What if MDM is already in place but the data is still poor?

The problem is usually at entry: new items are created without checks, and the catalogue gets cluttered again. We audit quality, clean the existing records and add checks on new items. The checks can be built into the MDM you already run.

Next step

Let's discuss your landscape and master data

Tell us which systems and master data domains you have. At the first meeting we will go through the task and propose a scenario and the order of waves.

  1. 1
    Kick-off meeting

    Current systems, master data domains and key issues

  2. 2
    Short assessment

    We look at the data and master data processes

  3. 3
    Plan by stage

    Scenario, waves, timeline and cost estimate

0
200000
We use your details to respond to your request. See our Privacy Policy.