Let’s go over what a change request is within SAP MDG. It is a core concept within the SAP MDG central governance module and is used within each domain customer, vendor, business partner, material & finance. For an overview of SAP MDG, its key features and modules check out this article below:
https://techconsultinghub.com/2022/03/01/sap-s4-hana-mdg-overview-part-1/
In this article we will explore the following topics:
- Master Data Management CRUD create, read, update, delete
- What is a change request in SAP MDG & how it relates to MDM CRUD Process
- What impacts does a change request have in the MDG system
Master Data Management CRUD Process (create, read, update, delete)
One of the key concepts of master data management which has a lot of focus is the CRUD process which is an acronym that stands for create, read, update & delete. This refers broadly to data records in a system. There should be processes & procedures for each of the CRUD processes with answers to the following questions, for example
- Create
- Who has access to create new data records
- What is the process to create a new data record
- Is there any approvals or documentation required to create a new data record
- Read
- Who should have access to display data
- Are there any sensitive fields that need to be further restricted
- Update
- Who has access to update existing data records
- What is the process to update an existing data
- Is there any approvals or documentation required to update an existing data records
- Delete
- Who has access to delete records from the system
- What is the process to delete an existing record
- Are there special approvals required or documentation to delete an existing record
As you can see above there are a lot of questions that need to be answered and the management of this process can be daunting without the right tools. There are also additional processes when we discuss master data in SAP which has the following
- Create
- Update
- Extend
- Flag for Deletion
- Block
- Mass Creation
- Mass Update
- Mass Deletion
In order to properly manage this process SAP MDG is the primary tool. The interesting point to note here is that despite the name master data governance, SAP MDG is actually an MDM tool. It performs master data management which has one of its key focus areas around the CRUD process. Data governance is the overall organization structure, roles and policies that govern data. Think of data governance like a government organization. It sets the rules and how items will be enforced. Master data management would be a part of the data governance rules & structures that are set up. A true data governance tool for example is Collibra. Let’s discuss how SAP MDG manages the CRUD process since it is a master data management tool.
What is a change request in SAP MDG & how it relates to MDM CRUD Process
A change request in SAP MDG is one of the fundamental structures of the system. Let’s first start to clarify what change request means in SAP lingo. A change request is ANY request to create/update/delete/extend etc. data. A change request is not only to change an existing record. It is a bit of confusing language for native English speakers but the concept is that any change at all in the system even if it’s a creation is considered a change request. As shown below a change request can be many things
A change request in MDG is the object that tracks the following processes, there are different change request types in MDG in order to track these processes:
- Create Change Request – Creation of a new data object such as a customer/vendor/material/financial object
- Update/Extend Change Request – Changes to existing data objects such as editing a single field or extending to a new organization structure such as a sales area
- Flag for Deletion Change Request – This is to include the deletion flag on an existing data object
- Block/Unblock Change Request – This is to set the blocking indicators on a data object
- Mass Change Change Request – This is to change multiple records in a single change request
- Multi Processing Change Request – This is a unique way of updating a smaller number of records for a specific area such as sales or purchasing where each record can have different values assigned with a unique UI
Let’s go over the key fields that are available within a change request and then take a look in the MDG system. The key fields are listed below
- Change Request ID – This is the unique number that is auto assigned to identify each unique change
- Change Request Description – This is a mandatory field that describes why a change request is being raised
- Change Request Type – This is a mandatory field that is determined either automatically or as the very first step in the change request creation process depending on how many change request types are available for the user and their action
- Change Request Status – The status of the change request let’s the users know where in the approval process the change request is. Additionally, the status can determine what actions can be taken
- Change Request Priority – This is a flexible field where users can determine the priorities they want to assign to change requests
- Change Request Due Date – Users can select the date in which they need to have the change request activated in the system
- Change Request Reason – This is a configurable field that can provide high level categories for why change requests are being created primarily for analysis purpose or to modify the workflow approval based on reason
- Change Request Notes – This is a description field that allows users to provide a free text input to include additional information. This field becomes mandatory when a user rejects a change request so they can add a note about the detailed reason for rejection
- Change Request Rejection Reason – When a change request is rejected it becomes mandatory to provide a high level reason for rejection when the reason for rejection field has been configured. The reasons for rejection are created during the system configuration process
- Change Request Attachments – This is where additional documents that are only specific to the change request itself can be attached
Now that we have an overview of the fields available let’s take a quick look at what it looks like when you create a new change request in SAP MDG
If you want to see an end to end example of a change request in SAP MDG check out this blog post below. Within the overview you can find an end to end example of a customer creation request that follows the change request process:
Now that we have a good background on what a change request is within SAP MDG let’s take a look at how it impacts the system overall
What impacts does a change request have in the MDG system
When initially configuring an MDG system, determining the change request type structure is a key decision process. There can be a number of different use cases for why to create different change request types, I will not go through an exhaustive list but give a number of the key functionalities that can be configured by change request type to give an idea how they should be used in the system
- Change Request Types Allow for the following features
- Workflow Template – This determines what workflow will be used and how configurable that workflow will be
- Workflow – You can use the same workflow template but have different workflows based on the change request type
- Data Model Used – Change request types are different based on each object such as material, customer, vendor
- CRUD Process – Determines whether the change request can be a create, update, delete etc.
- Single or Multiple Objects – Determines if there can be more than one object being processed in a change request
- UI Functionality – Based on change request types you can have different UI assigned to show different aspects of the master data object. You can also determine if fields are read only or editable based on the change request type
- Data Business Rules – You can differentiate which data business rules are triggered based on the change request type
- Reason, Rejection Reasons, Change Request Steps, Due Date per Priority (SLA) – Many of the configuration options available will vary based on change request type. For example, you can have different reasons for rejection based on the type of change request
- Security Role Access – Change request types can be restricted by security role so users can only access certain change request types
- Custom Enhancements – Often when SAP MDG is extended with custom enhancements there are flexible filters in the code based on change request type
As you can see there are a lot of different aspects of the SAP MDG system that are dependent on how change request types are set up. This is a fundamental process and should not be taken lightly as deciding to change this structure later will take a lot of added re work. The recommended approach is to first determine all the business requirements related the CRUD process as mentioned above. In this case you would know the approval process required & you would know who should be creating/change master data. Once you have all the end to end master data management processes it is a functional/technical team that will evaluate what is the best method to translate this into change request types.
Keep in mind there are multiple ways to achieve the same outcome in SAP MDG. For example, if you don’t want to have different change request types you can utilize enhancements with your own development to achieve the same outcome. Let’s go over a quick example below. This will show how to have a different approver by region within SAP MDG. This will teach you how to set up change request types to match a business workflow.
MDG Change Request Type Example Based on Business Requirement
Example: The company has a global presence and wants to have an approver for the general global data based on each high level region Americas, Europe, & Asia Pacific. The standard workflow available for materials only has the ability to have a single global approver role. This would mean regardless who and where a new material request is created you can only have a global approver role. In this case let’s explore the potential solutions
- Solution Option 1 – Create a change request type for each high level region and allow the approver role to be for that region. Restrict the requestors per region to only have the appropriate change request type for their region
- This solution appropriately address the requirement but let’s think through the implications. In this scenario imagine we want a standardized process despite the three regions. What if there is a change in solution, now we not only need to change a single change request type, we will need to do it for all three regions increasing the effort of implementing changes. Additionally, what if the regions start expanding more and more. Having a change request type per country would be too much maintenance for the system
- Solution Option 2 – Utilize the standard field change request reason to include Americas, Europe & Asia. Additionally use configuration to make that field a required field
- This solution achieves a similar outcome, however it’s not very intuitive as a user to have their change request reasons be based on their region. It also would restrict the ability to use the reason field for other analysis.
- Solution option 3 – Utilize a custom enhancement that determines the users country & based on that country assign an approver by region
- This is now moving into the more custom aspects of the solution and even this could be done a number of different ways. An example would be adding to the workflow a user’s country option & then determining the appropriate approver based on that country. This also has the assumption that every user in SAP has their country stored in their user profile and would fail in the case this didn’t occur
As you can see with the above example there are even more solution options that can be proposed and each one we would need to weigh the pro’s and con’s of that solution proposal against the requirements and the organization that will use that solution. Also keep in mind there is a lot of additional cost and upkeep required on completely custom solutions so sticking to standard SAP where possible is usually preferred.
I hope this gave an overview of what a change request is within SAP MDG & how it helps the MDM CRUD process. If you liked this post consider subscribing or asking questions below!