Issue

Managing master data is vital from a business perspective because it ensures accuracy, enhances efficiency, supports compliance, improves customer experience, and drives financial performance. By implementing effective master data management practices, organizations can achieve reliable data, streamlined operations, and better decision-making, all of which contribute to long-term success of ERP Implementation.

As a part of ERP Rebuild program, there is an opportunity to implement a master data solution, and this document is to evaluate the options for the same.

Recommendation

Background & Context

Managing master data is critically important from a business perspective for several reasons, all of which contribute to the efficiency, effectiveness, and success of organizational operations. Here’s why effective master data management (MDM) is crucial:

• Ensures Data Accuracy and Consistency by enabling single source of truth and reducing any errors
• Enhances Operational Efficiency by enabling streamlined processes and automation
• Improves Decision-Making by providing reliable insights and a unified view of data
• Supports Regulatory Compliance by enabling audit trails and implementing data privacy and security
• Facilitates Integration and Interoperability
• Drives Financial Performance by cost reduction due to data errors, redundancies, and inefficiencies
• Mitigates Risks by reducing the likelihood of errors that can lead to financial losses, legal issues, or operational failures.
• Supports Scalability and Growth by providing the framework to scale data management practices efficiently and supporting the integration of new systems and data sources while maintaining data quality.
• Enhances Competitive Advantage by enabling strategic insights and agility to respond quickly to market changes, customer demands, and emerging opportunities.

Syensqo currently utilizes various disjointed systems for creating, maintaining, and governing master data. This fragmented approach poses significant challenges to data quality, consistency, and governance. Following are some of the key systems that are used for master data maintenance. Apart from the below, there are multiple other homegrown and 3rd party applications where some of the master data is maintained and governed. 

Note that the below list of systems and the governance process is only for a subset of master data objects and there are many master data objects where there is no central system nor governance implemented.

Approach

To fulfill Syensqo’s master data governance requirements, it is proposed to divide the master data into three tiers:

Tier 1: Critical Master Data Objects
This tier includes master data objects that are essential to Syensqo’s key processes and must be managed centrally to ensure consistency and reliability. These data objects are crucial for the smooth operation of critical business functions and require strict governance and oversight. Any master data object shared across regions also falls into this tier to maintain data integrity and uniformity across all areas of the organization.

Tier 2: Important Master Data Objects
This tier encompasses master data objects that, while important to Syensqo, are not as critical as Tier 1 objects. These objects require centralized governance to ensure adherence to company-wide standards and policies, but their maintenance can be performed locally. This allows for flexibility in data management while ensuring alignment with the organization’s overall data governance framework.

Tier 3: Localized Master Data Objects
This tier consists of master data objects that are specific to individual regions, countries, or plants and are tailored to meet the unique needs of each location. These objects are not critical to the key processes of Syensqo and therefore do not require centralized governance. They will be managed and governed locally, providing flexibility and customization based on regional requirements with minimal central oversight.

A list of all the tiers based on the current data objects is here

Assumptions

Clearly describe the underlying assumptions which informed or limited the choices available, or impacted the decision: cost, schedule, regulatory requirements, business drivers, country footprint, technology, etc. Include links as necessary. This section is important because a future change in circumstances might invalidate some key assumptions, which then prompts a decision to be revisited. 

Constraints

Capture any constraints or limitations inherent to the recommended option. This could be aspects which, if changed or removed in future, could cause the decision to be revisited or invalidated. For example, a constraint might be that a new product has significant gaps in important functionality, which caused an older alternative to be recommended. If those gaps are closed in future, this might cause the decision to be invalidated.

Impacts

Describe the impact of the decision on other aspects such as other processes, infrastructure, other SAP modules or systems, data cleansing and migration, developments, automations, interfaces, in-flight projects, etc.

Business Rules

The decision may translate into business rules which enforce the decision and will require configuration. List these business rules here. For example, "An Outline Agreement cannot be created via the RFQ process. An awarded RFQ can only result in a Purchase Order". 

Options considered

Following are the Options considered for implementing a master data system

Option A: Single / central SAP master data governance system (MDG)

This option involves utilizing SAP Master Data Governance (MDG) as the primary system for managing master data across the organization. SAP MDG is an integrated solution within the SAP environment, designed to centralize master data management and governance, ensuring consistency, accuracy, and compliance. SAP MDG helps streamline the processes for creating, updating, and maintaining master data, providing a robust platform for data governance that aligns with SAP standards and best practices.

MDG has 2 flavours classic and cloud ready. Both of these can co-exist and doesn't need any additional licences than the MDG licenses.

Classic MDG: As part of the classic MDG the following objects are supported. Note that EAM and Retail are supported by partner extension (Utopia).

Cloud Ready MDG:  This is an attempt from SAP to harmonise MDG, MDG for S/4 HANA public cloud and MDG in BTP. Supports Fiori UI and uses BTP as the workflow layer. Uses BRF+ for master data rules configuration. It is a very recent product and supports only some roles of Business partner at the moment. Material support is planned in the next release in 2025, and no roadmap confirmed beyond that. 

For the sake of evaluation this option considers adopting the master data objects available as part of the cloud ready MDG and the rest via Classic MDG.

Option B: Single / Central master data governance system 

This option involves using an external, non-SAP system as the centralized master data governance solution. The chosen system could be a specialized master data management (MDM) platform or another enterprise solution that is capable of integrating with various systems across the organization. The external system would serve as the single source of truth for all master data, centralizing governance and ensuring data consistency, quality, and accessibility across multiple platforms and applications within the organization.

Option C: Separate master data governance process and system for specific master data objects

This option proposes the use of separate master data governance systems tailored to specific master data objects or business needs. Instead of a single, centralized system, different master data objects would be managed by dedicated systems that are best suited to their unique requirements. Critical data objects may have their own centralized governance system, while less critical or more localized data could be managed by different systems that cater specifically to regional or departmental needs. This decentralized approach allows for greater flexibility and customization, enabling each system to be optimized for its particular data governance requirements while ensuring that the organization can effectively manage diverse data needs across various areas.

Evaluation

Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.

	Option A: Single / central SAP master data governance system (MDG)	Option B: Single / Central master data governance system	Option C: Separate master data governance process and system for specific master data objects
Fit for Purpose
Integration and Compatibility	Pro Con	Pro Pro	Pro Con
Flexibility	Pro Con	Con	Pro Pro
Complexity and Maintenance	Pro	Con	Con
Data Quality and Consistency
Implementation and Cost
Responsiveness and Agility
Scalability
Suitability for Critical vs. Non-Critical Data

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log

Workflow history