Help us get better with your feedback!

Explore to Run

Prospecta strongly recommends following the Explore to Run methodology for project implementations. 


The Explore to Run methodology for enterprise MDO deployment maps out the key activities to understand customer requirements, configure and build solutions, followed by verification and deployment. The methodology ensures that the project is well planned and successfully completed in order to achieve rapid value realisation of MDO.  

 The Explore to Run methodology consists of the following three stages:  

  • Explore – Examine customer’s business processes to translate into Solution Design (Functional and Technical)  
  • Build – Configuration and verification of MDO’s customer-specific requirements, followed by User acceptance testing by business and Go-Live activities.  
  • Run – Hypercare treatment for post-go-live, followed by transition to support. 

Pre-Cursor Activities 

These details will enable people who are involved in the implementation of MDO. In this section, the delivery team will get the associated structure, approach, source documents and materials, and implementation steps to help them extend the current Industry Solutions for SAP.  

The information will be essential for consultants involved in implementing MDO Extended Industry Solutions, as it provides all the necessary activities to onboard a customer successfully. This section will provide the guidelines for completing and tracking a detailed project plan, from activities to responsibilities, deliverables, and commercials.  

These are the key pre-requisites: 

  • Understanding the key concepts of Master Data Management;  
  • In-depth understanding of SAP 
  • Detailed Understanding of the SAP Master Data Area, e.g., Materials. Plant Maintenance; 
  • Certified or gone through various MDO Platform Courses; and  
  • Good knowledge of testing end-to-end – including integration testing into SAP environments. 

Key terms 

Term Details 
MDO MDO is a multi-tenant and full SaaS Enterprise Data Platform with solution accelerators that help to implement MDM policies for Active and Passive Governance. MDO allows users to implement processes that need governance and data controls in a low-code environment. 

ConnektHub is a Prospecta solution which helps in 3 key areas: 

  • All Prospecta Industry Solutions including MDO are published in ConnektHub 

o    Future state – Partners will be able to implement their own solutions. 

  • ConnektHub is also a content library for our Manufacturer Parts and industry classification content for assets. 
  • Package Management – Between Customer Org Tenants (Sandbox / Production). 
MDO MDO is an MDM solution across domain and systems, MDO Solutions have covered key domains such as Spares, Assets, Products, Customer, Suppliers and even Finance related Master Data areas. The Solutions use all the relevant MDO Platform Features to help customers meet their MDM objectives. 
MDO for SAP MDO for SAP is a set of SAP Specific solutions for their datasets and data models, including integration.  This includes MDO for SAP Supply Chain, MDO for SAP Plant Maintenance, MDO for Business Partners, MDO for Finance and MDO for IS Retail. 
MDO Spares MDO for Spares is a generic Industry solution that can integrate with any other ERP / Application System. 
MDO Assets MDO for Assets is a generic Industry solution that can integrate with any other ERP / Application System. 
FAP MDO Accelerator Packages are pre-configured process driven solutions that help to manage critical functions and processes within an organization, e.g., Safety, Risk etc. 
SOW A Statement of Work is an agreement document which outlines the deliverables and project goals. It is created to have alignment on deadlines, project scope, commercials and roles and expectations. 
Design Document A design document outlines the software’s functionality (specs) and the team’s plans to build and implement it (timeline, goals, etc.). 
SAP BTP SAP Business Technology Platform is the platform by SAP to extend SAP solutions and used by Partners to leverage BTP to integrate with SAP 
SAP BTP CPI SAP BTP CPI is the integration layer that SAP provides which MDO uses to integrate into SAP ECC and S/4 HANA environments, All SAP specific Integration mapping and handling is done in CPI. 

Tenant Preparation 

Once a customer is onboarded on MDO, they are provided with two default tenants namely Sandbox Tenant and Production Tenant. Each region has only 2 clusters. However, the customer can have multiple Non-Prod Tenants like Dev and QA. The Platform version in both environments is only for a limited period as new features and fixes get deployed in these environments. 

Tenant Onboarding 

The first part of the tenant onboarding process is setting up a new tenant. 

Tenant Set-up 

Tenant Setup is done by Prospecta Customer Success & Support Team. After onboarding customers, the teams need to do the following. 

  • Support in creating the new Tenant for both Production and Non-Production 
  • Create the BTP-CPI Tenant for the Customer for both Production and Non-Production Tenants 

o   Import the required CPI Interfaces for the IS Solution 

  • Support in setting up the Cloud Connector Connection. At this point, doing the connection test is a crucial part. 

o   Test a Payload for one of the interfaces in the customer Dev/Test Environment 

  • Import the SAP IS Dev Packages in the Customer SAP Environment. 
  • Support in Setting up SSO if applicable. 
  • Provide the standard roles and permission required for an SAP System User and explain how to invite other users to the team. 

Tip- It Is important to test the privileges of the user as early in the project as possible. 

Once done, each customer gets an admin privilege account of MDO. An Administrator can further invite users and get the solution onboarding started. 

Next, the Project Delivery Team connects with the respective customer admin and follows these steps: 

Tenant Readiness 

Next, the Prospecta Customer Success & Support Team will get the tenant ready by following the steps mentioned below. 

Tip – Tenant Readiness is a Pre-Requisite before the start of the detailed design phase as the solution is used during the workshop sessions. 

Step 1 – Team – Invite project users. 

The first step is to invite the project users. The Administrator needs to invite all the people involved during the project phase. This will include their own team and the project team. It is important to use the customer email account for Project Teams if SSO is enabled. This will also include Test users, for approving requests. 

Note – Project team users should use customer email. For example – 

Step 2 – Import MDO in packages  

The MDO IS Packages are Industry Solution Packages that can be imported to get the standard solutions. The solution includes. 

  • Datasets – These are the Data models for the core and related datasets. 
  • Interface Mapping – All the Interface Mappings for the datasets. 
  • Test Flow – A test flow for testing integration. 

Once the Package is deployed, the solution is ready for the design phase. 

Step 3 – Test integration 

It is important to also do an Integration Test from MDO for both Sending and Receiving data. 

  • Sending Data can be tested via the Test Flow.  
  • Receiving Data can be tested via the Data Management Sync Feature  

Tip – This should be done here as much as possible, as to avoid any surprises. 

The Project Plan 

The Project Plan is always an important document any consultant needs to understand in terms of milestones and signoffs.  

Below is a sample project plan. This can change based on projects, but some of the key milestones remain the same. 

Key Milestones/Documents and Signoffs 

Milestone / Docs Detail Responsible Sign offs 
Tenant Set up 

These are all the steps required to set up the Tenant. 

  • Includes Connectivity Test 
  • Import of SAP  
Tenant Readiness Package Import and Test Integration Delivery Project Manager 
Design Sign off 

Sign off 3 key areas. 

  • Detailed Design Document 
  • DSAL List 
  • Test Scenarios 
Delivery Customer, Solution Architect and Project Manager 
Walkthrough 1 Feedback The Walkthrough 1 Feedback will be the first level of feedback provided by the customer – It is important to document that and get a sign off. Delivery Customer 
Walkthrough 2 Feedback This can be sometimes link to the Unit Test Milestone Payments as post this , we do want to make any major changes Delivery Customer 
Preparation of all Detailed Test Cases All Detailed Test cases (positive and negative) should be documented and signed off by the customer – This will be the basis on which SIT and UAT will be done Delivery Customer / Project Manager 
Implementation Paper Implementation Paper is a living document that documents everything that has been implemented in the solution. Delivery Customer /Project Manager 
SIT Sign off Client will be testing and providing the sign off on the system.   
UAT Sign off End users will be testing and providing the sign off on the system; Go-Live preparation is based on this UAT sign off .   
Cutover Sign off    
Hyper Care Sign off    


  • Simple changes can be incorporated during these walkthroughs. 
  • Any major changes should require a change request process. Examples are 

o   A complete change in the flow process 

o   Introduce new fields and validation at the integration level 

o   Introduce New Roles 

o   Any major complex Business Rule 


Explore Phase 

Explore stage is the first stage of our Explore-to-run methodology. The Explore stage explains how to deep dive into customers’ business processes and proceed with design solutions with an understanding of their As-Is processes and To-Be Processes. 

The explore phase consists of the following phases:  

  • Detailed Design  
  • Design Workshops  


Explore Phase – Detailed Design 

The Detailed Design Phase is where certain configurations are done during the detailed design. Our detailed design approach includes. 

  • Design approach overview session 
  • Sending requirement templates to customer 
  • Design template execution for all data sets 
  • Base MDO Configurations- Datasets, Forms and flows 


Below are a few Pre-requisites items which are expected to be completed before the explore phase is executed. 

  • Customer Onboarding 
  • MDO tenant setup completion 
  • Connectivity test 

Expected Outcome 

  • Complete the list of fields required for the project. 
  • Form layouts for each role involved in the governance process. 

1. Design Approach – Overview

In this session, the Prospecta team/Partner team will take customers through the Design Requirement templates. These templates contain Prospecta standard out-of-the-box industry solution field list for all standard datasets i.e., Material, Functional location, equipment etc. 

2. Sending design Requirement Templates 

Once the design overview session is complete and the customer has a good understanding of the requirement templates, we will send the requirement templates to the customer to fill in the details. 

3. Design Templates execution 

This step will be executed by the customer team. The customer will fill and specify all the fields required for each data set and all roles. Customers can also provide field-level defaults and field-level business rules in the same template.  

4. Base MDO Configuration – Datasets, Forms and Flows 

Once step 3 is completed, the MDO team will set up all forms and flows in the customer tenant to execute Design workshops. 

Explore Phase – Design Workshops 

In the Design workshop we will have very specific and focused sessions for each and every business area. Below is the list of sessions which would be required for design workshops. 

  • Roles and privileges 
  • Field attributes and metadata 
  • Flows- Active Governance 
  • Forms definition & assignments 
  • Business rules & assignments 
  • Passive governance using DIW Schema 
  • Data quality score framework 
  • Dashboards 
  • Finalize cutover approach 
  • Technical session 


Below are a few Prerequisite items which are expected to be completed before the explore phase is executed. 

  • Customers have completed the requirement templates.  
  • MDO consultants have finished the base configurations for forms and flows.  

Expected Outcome 

  • We should have a clear understanding of process flows. 
  • Base-level configurations have been verified and signed off by the customer. 
  • We should have a complete understanding and list of all the business rules required for the project. 
  • We should be able to finish the DSAL list for build estimations 
  • Base-level test scenarios should be defined 

Workshop Sessions

1. Roles & Privileges

In this session we will finalize the privileges which need to be assigned to each role I.e. what data sets they can access, what areas they can control in the application, if there are any restrictions on Plants or company codes, what transactions they can perform I.e. create change.

2. Field Attributes & metadata

In this session, different field attributes will be finalized I.e. if there are any custom fields in the customer SAP system then processes around those fields will be finalized. Also, if a customer wants some information fields to be maintained in MDO to support the processes then these can also be discussed in this session.

3. Flows – Active governance

In this session, all Active governance to-be flows will be discussed and finalized. All the processes will be documented and added to the design document. If there are different data sets then a few more sessions might be required to complete the requirements.

4. Forms definition & Assignments

In this session, the MDO team will take the customer through the forms and flows that we have configured based on the requirement template and get confirmation from the customer if anything needs to be changed in the forms or flows.

5. Business Rules & Assignments

In this session, all the business rules will be discussed and will be mapped against each process. There are different kinds of business rules in MDO to manage validation and background processes as mentioned below:

Default values: These are the form-specific rules to default on any field value on the form.
Dependency rules: These are also form-specific rules to derive target field values based on parent field values.
Cross data sets rules: These are process-specific rules which run in the background I.e. Automatic HERS creation in the background while creating a spare part.
Validation rules: These are process-specific rules and are applied on screen to validate data. These rules can utilise different business rule components I.e. UDRs, Transformation rules, lookup rules or DAXE rules depending on the requirements.
UDR (user-defined rules): these are process-specific rules which are applied on screen to validate data. These rules can also act as input or trigger conditions for cross-data set rules.

6. Passive governance using DIW

In this session Data quality rules will be covered; these rules can be the same as active governance rules or different rules set altogether.

7. Data quality score framework

8. Dashboards

In this session, all the key dashboards will be defined for different roles. All reporting requirements will also be discussed in this session.

9. Finalize cutover approach

In This session cutover planning will be done I.e. what’s the current data load in production, how many data records will be required for UAT and SIT etc.

10. Technical session

This session is required if there is integration required with any third-party system or any new interface required which is not part of the standard MDO package. The main goal of this session is to define key responsibilities for the development of these interfaces.

DSAL List 

The solution architect prepares the DSAL Activities list and defines all the essential tasks that need to be carried out to build the solution based on the design document and test scenarios. The DSAL Activities also specifies the Business Rule Type that must be implemented for each validation and business rule. 

A DSAL Activity equates to a Task in the Project Jira Dashboard with a specified time to complete. 

Test Scenarios 

The test Scenarios are all the core scenarios that are documented based on the “Happy Path” on what is expected. This is further detailed in Test Cases which will be included before SIT which will consist of all positive and negative test cases. This is a critical success factor for projects to be successful and remain within the scope. 

Change Requests 

Change Requests are anything that adds to the scope and requires additional DSAL Tasks. Project Managers should keep track of these requests irrespective of commercial agreements. 


Build – Introduction 

Build- Configuration and Customization of Solution  

Once the explore phase is completed, the next step is to configure the system according to the signed Gap analysis/BBP document. The unit testing of the functionalities is done using relevant customer data and test scripts to ensure they work as per requirements.  The team also works on configuring and testing the identified solution gaps.  

Additionally, a walkthrough with the customers is done, and test scripts are prepared and signed off. The GDC team also prepares the Baseline Test Scripts & submits them to the customer after which the customer will extend the baseline test scripts as per the business scenarios and data.  

Verification of Systems Integration and User Acceptance  

During verification of system integration, a systems Integration Test (SIT) is performed to make sure all the modules work in an integrated environment. GDC team also trains the users to use and become familiar with the system. In this stage, the Test Scripts are updated, and Systems Integration Testing (SIT) and Product Verification Testing (PVT) are done.  

During the User Acceptance Test (UAT) MDM business users are involved in validating end-to-end business flows and scenarios and obtaining their sign-off. The clients provide enhanced Test scripts with their data scenarios to be used as a reference by the UAT business users.   

Go-Live Preparation  

This is the last step of the deployment phase. The GDC team ensure Go-Live readiness in this step through cutover planning and preparation (Production Data Download & Data Reconciliation Report). The GDC team executes Go-Live activities and makes an announcement for Production system readiness. Apart from this, Admin training to Customers (Power Users) is provided and the system is handed over to the customer with Go-Live signoff.   

Supportive documents like the Go-live checklist and Help Portal are provided to the customer for seamless navigation of MDO. 



Data steward activity list (DSAL) build activities 

Standard Data set load from MDO Gold Server 
Forms, Flows, Configuration as per requirement 
Roles Configuration 
Drop downloading from SAP 
Email Configuration 
Walkthrough 0.5: Build in-progress 
Custom Business Rules Configuration 
Unit Testing 
Walkthrough 1: MM create process 
Scenario Configuration 
Field to Field Mapping 
Creation of test scripts 
Test scripts preparation (Baseline) 
Test scripts enhancement by client 
Test Script Review 
Test scripts Sign-Off 
Walkthrough 2.0 MM change and extend process 
Identify of sample data 
Data Download activity and validation 
Walkthrough 3: Final Walkthrough 
SIT (MDO Team) [Complete end to end System Integration Testing] 
Training- Train the trainer 
Toll Gate 3- Complete solution 
UAT Readiness & UAT 
UAT User creation 
User Provisioning (FOR UAT) 
Manual creation of all users in MDO 
UAT defect and resolution 
UAT Sign-Off 
Go live decision 

Below are the key steps that should be ideally followed 

Step-1 Configuration and Reference Value Data 

Reference Value and Configuration Data can either be synced or manually maintained. This will be important to define any conditional rules or data that will be required for decisions during Flows. 


  • It is recommended that, where possible configuration and reference data are synced from Source Systems 
  • Dependency Data at the Meta Data levels should be maintained. 
  • Additional dependency can be maintained as business rules. 


  • Data set repair activity should not be performed during business. 


Tips- There are limited fields that are supported in IS for dropdown sync. Ensure we have proper customer alignment in terms of what will be synced and what will require manual maintenance in the MDO Platform. 

The Estimated Time for this activity is 1-2 Days. 

Step 2- Confirm roles, datasets and forms 


  • A process mapping with the defined roles and personas that will use the system. 
  • Make sure that the permissions are mapped to the role for each persona. 
  • Get some additional users set up for testing if SSO is there. Currently, if SSO is enabled in MDO, you cannot create manual users. 
  • Tests with customer domain & related workspaces.  


  • Avoid changing field length or data type attribute of IS datasets. Note that IS packages are templates and any changes may create issues in integration. 
  • Forms 


  • Workspaces need to be mapped to the person. 
  • Always show customers and ensure that the access point is Workspaces. 

Step 3- Define business rules 

The DSAL List will specify the type of business rules that will need to be configured. The two complex rules are UDR – User Defined Rules and DAXE – scripting-based rules. It is important to understand the features and limitations of these rule types. It is recommended to always configure a rule, before looking at DAXE as an option for rules. 

There are some standard business rules based on the Industry Solution. 

Below are the rule types and how they can be used based on the business requirement: 

The Business Rules are executed in 3 different levels in MDO. 

Active Governance (Flows) – The most common use of rules getting executed is at the Active Governance level where Data Requestors or Maintainers are requesting new Master Data or Changes in Existing Master Data 

Passive Governance (DIW) – The rules are also executed in DIW Schema for helping both in Data Remediation and finding data issues in source systems. 

Data Quality Scoring – The rules are also executed for calculating the Data Quality Score based on the Rule Matrix Defined. For Active Governance, it is run after the record is saved and for passive governance, it is run based on schema run (road map). 

Below are the rule types and how can they be used based on the business requirement: 

Rule type Rule scenarios Recommendations 
Missing rule  Missing Rules are used to track missing data which are normally not defined mandatory in Active Governance Make sure all Mandatory and any other attribute that you need to track as missing data is defined in this rule. 
Look up rule Look Up rules are used to check data from reference data sets within MDO datasets.  
Look Up and Transformation This is in addition to Look up rules where we can transform data.  
Cross Dataset Cross Dataset are rules where you create or change data for a different related datasets e.g Materia to Info records. Avoid using DAXE for cross dataset and use the rule instead. 
UDR – User Defined Rule Logical rules that are defined in UDR rules where we need to specify based on conditions. It is recommended always to try UDR before applying a DAXE rule to lower the maintenance. 
External Service 

External Service (RM) will allow to call services for external system. 


External Service will also be able to call SAP BRF rules. 

Where possible, apply this rule to NOT replicate data from source. 
DAXE DAXE rules are used for complex rules. There are pre-defined functions for DAXE rules that it can apply. It is highly recommended to not assume that DAXE can do any rule. 


  • It is recommended that, where possible configuration and reference data are synced from Source Systems 
  • Dependency Data at the Meta Data levels should be maintained. 
  • Additional dependency can be maintained as business rules. 
  • Technical Specifications should be defined for UDR and DAXE rules as they can get complex with proper Unit Test Scenarios 


  • Write multiple rules in one DAXE Rule. Split those rules into different DAXE’s as that will help both to support and maintain the rules. 


Step-1- Classification system 

Classification System Set Up is only required when you need classes and characteristics defined. The key use cases are: 

  • Spare Part Description Generation – Based on Noun and Modifier 
  • Sending data to SAP Classification System – This can be for any dataset. 
  • The customer has chosen Industry Classification which we will need to support. 
  • Refer to the Classification System Set-Up 


  • Class and Characteristics can be updated or maintained via the classification system. 
  • It will be important to be aligned with the cleansing team for classification – the description generation needs to be the same 
  • There is no sync/integration currently for the classification master. This is in the roadmap for Industry solutions. 
  • There are certain data types not supported for characteristics, which are supported in SAP. 

Step-2- Data quality score (DQS) 

Data Quality Score is a Matrix that allows the provision of an overall data score on a record. This is based on the standard quality dimensions of Data Quality. You can support most of the business rules in a DQ Matrix and provide a score based on each rule. This helps the customers to gradually implement rules and not assign them at a Flow level. DQS is available once the record is saved. Refer to Configuring DQS Scoring 


  • DQS will not calculate if there are Error Validations on Saving. 
  • DQS will not calculate for cutover /delta sync loads. There is a roadmap to calculate the DQ Score during DIW execution without the need to remediate data. 
  • DQS matrix requirements should be defined separately, all business rules should not automatically qualify for DQS – For Example Transformation and Cross Dataset Rules should not automatically qualify for DQS. 
  • There is also additional work involved in configuring a DQ Dashboard 

Step-1- Flows – Active governance 

The Flow Builder in MDO is based on BPMN (Business Process Model and Notation). One of the core prerequisites with Flow Builder is to have a good knowledge of BPMN. 

Understanding flow builder 

The Flow Builder will be opening a different UI. One of the important parts to understand from the training materials – there are only certain parts of Flow Builder that can be used in the BPMN Process modelling. In future Road Map – certain areas of Flow Builder will be deactivated or hidden. 

Some of the important points on using the Flow Builder are: 

  • Keep the Process Flow simple. 
  • Multiple Rejection Scenarios can make the configuration of Flow very complex. 
  • One Project is equal to One Flow. 
  • For Every Change, ensure you change the version number and then publish. 

To learn more about MDO Flow Builder please enroll on the academy course.  

Task types 

Task Types more commonly called handlers are built specifically for the MDO platform. These handlers provide various operations at the Task Level for both automation and validation. 

Task type Usage Process variables Additional comments 
Human tasks The Usage is where we have Form based interaction   
Service based    
Cross dataset    

Send for Correction – Rejection Scenarios 

Send for Correction is the rejection scenarios. Below are the key points for Send for Correction that we need to consider. 

System Errors 

Task Reassignment 

Step-1-Define Workspaces 

The following types of data sources are supported today to define workspaces. 

Data sources Usage Key metrics 
Process logs   
Data quality logs   

MDO launch pad 

The MDO Launch Pad is for the personas defined for the project. Currently, we configure them as dashboards, the plan is to call them Pages in the near future. 

One of the important Widgets to configure in this persona is the list as all the Data Requestors should not have access to the Data, DIW, Flows and Dashboards. They should all access through the My Workspace Area. IS Solutions will have some pre-defined workspaces for key categories of Roles. 

SLA dashboards 

 SLA Dashboards are derived from the Process Logs Datasets 

SLA Dashboards will also be available in CH IS Solutions pre-defined, additional SLA dashboards can be defined. Some of the key metrics for SLA Dashboards are: 

  • No of Requests are created and processed based on various filters. 
  • No of Requests sitting in progress and are beyond the SLA. 
  • Requests that are not meeting SLA. 
  • Roles that are not meeting SLA. 
  • Trend of Requests – based on an expected baseline SLA. 

Change Logs – Audit Trail 

Part of the Process Logs Datasets, these reports can provide you with all the change logs and Audit Trail of data changed by users and date. 

These reports are mainly accessed by auditors when they need to review data audit changes. 

Data quality score 

The Data Quality Score Dashboard is derived from the Data Quality Logs.  


Access and Type of Access are defined based on Collaborators. 

Download/Send by email.  

Customers often ask for sending or downloading reports. The following options are available: 

  • Send via email -CSV 
  • Send via Email – Xls (Non Editable) 

Step-2- Integration Set Up for SAP 

The integration setup is more of an extension to the existing interfaces, in terms of custom fields. 

The Types of Interfaces available are: 

  • Create and Update – These Interfaces send data to SAP for both creation and update. 
  • Reference Data/Dropdown 
  • Sync – The Sync interfaces can be used both for initial cutover and delta syncs that happen in SAP. The CSV-based cutover can take a lot less time for large amounts of data. 
  • Look Up – These are Interfaces that look up reference data in external systems. 

The IS Solutions come with 

  • Standard /PROS Namespace packages – Click here to refer to all the IS Packages 
  • Standard CPI Packages in BTP -These packages come with mapping between MDO services of standard datasets and mapping to SAP /PROS Functions 
  • Custom Fields are available for each of the interfaces. 
  • Delta Sync will be required to be set up for delta changes in the source system. 
  • Look Up Interfaces for specific fields. 

List of all interfaces available by dataset  

S.No  Component  Inbound   Outbound   
 Material Classification     /PROS/MDO_CLASSIFICATN_DATA_V1  
 Business Partner  /PROS/MDO_GET_BP_DATA     
10  Bank Master        
12  Alternate Label     /PROS/MDO_FLOC_RELABELING_V1  
14  FLOC/ EQ Classification     /PROS/MDO_CLASSIFICATN_DATA_V1  
19  Mplan Settlement Rule     /PROS/MDO_MPLAN_SETTLEMENT_V3  
20  Mplan Object List     /PROS/MDO_MPLAN_OBJ_LIST_V1  
21  Maintenance Strategy  /PROS/MDO_GET_STRATEGY_DATA     
26  Internal Order         
27  Profit Center   /PROS/MDO_GET_PROFIT_CT_DATA     
28  Cost Center  /PROS/MDO_GET_COST_CT_DATA     
29  G/L        
30  Fixed Assets  /PROS/MDO_GET_FIXED_ASSET_DATA     

SAP Custom ABAP Development 

The need for SAP Custom Development only arises in cases wherein: 

  • Completely a new interface or data domain where we do not have an interface. 
  • Extending the current data model to accommodate custom fields in SAP – In most cases, we do need any CPI Developments 

Custom BTP package development 

Step-3- Schemas DIW – Passive Governance 

Additional activities 

Unit test 

The Unit Test should be done with all the Test Cases defined in AI/IO. General Platform Scenarios, like search or administration, should be expected to run. The Implementation team should focus on test cases that have been signed off during the design phase. 

Test Preparation for SIT & UAT 

Importing packages 

Items That Can be Transferred by Package Movement: 

  • Dataset 
  • Interfaces 
  • Flows 
  • Roles 
  • Forms 
  • Dependency – Only Name, Source and Target fields 

Items Requiring Manual Movement/Configuration: 

  • Dependency conditions 
  • Classification Rule 
  • DAXE Rule 
  • Dropdown Sync/upload (English / Multilingual) 
  • Taxonomy Sync/upload (English / Multilingual) 
  • Privileges setting for each Role 
  • Email Templates 

Please note: All other business rules other than those mentioned in manual activities are transferred by package movement. 

Activities to be done post package movement to UAT tenant: 

  • Verify the successful import of configurations, including DAXE, roles, permissions, and other settings. 
  • Check the Admin area in the UAT environment to ensure that all configurations have been imported correctly. 
  • Remove Roles from human tasks and re-assign the roles, because after movement new Role Id is generated. 
  • Update Tenant name and Role ID / Name in flow decision tables and human task 
  • To update the endpoint to connect with the UAT SAP system, upload the UAT system WSDL in the UAT environment. 
  • Update the flow version in the UAT environment 
  • Publish the flow in the UAT environment. 
  • Update Number setting 
  • If using any system table, Upload data again in the UAT system 

If Multiple Languages are implemented 

  • Metadata, forms, flow and UDR Validation translation upload 

Cutover and Go Live Preparation 

Cutover Checklist 

  • Configuration/Package Movement from UAT to the production system.  
  • MDO- SSO Configuration                    
  • Get User List from Client for Production with roles                  
  • User Creation                          
  • TR Movement to Prod Environment               
  • SAP User creation / T-Code Access for Prod                 
  • Get SAP Production details for HCI                  
  • HCI endpoint Configuration for SAP Production                        
  • Legacy Data Download from 3rd Party system to MDO. 
  • Data Reconciliation – Count matches all tables      

Go live                 

  • Admin training                                   
  • Hypercare/Support   


Run Phase 


The last stage called Run, encompasses activities related to system support once MDO has gone live in a customer environment. The main steps consist of:  

  • Provision of hyper care  
  • Transition to support mode  

Provision of hyper care  

In this step, the Delivery team provides support post-go-live to ensure stability and smooth running of the new system. They make use of the Handover checklist to accomplish this task:  

  • Deliver Level 1 Support for 2 weeks of the injection period  

Transition to support mode  

The last step consists of project closure and obtaining agreement from the customer to move to support mode. This involves the transition from Prospecta’s GDC team to the Support team to take over the Support environment. The associated tasks are:  

  • Ensure ongoing support and smooth handover to the Support team  
  • Project closure  

Congratulations! You have successfully completed the Explore to Run methodology details.