MDM To-Be Process Design v5

To-Be Process Design:
MDM-005 Generic MDM

Governance process
Table of Contents Page i Document1

19-Mar-18
Document Control Information
Document Review/Approval History

Date Name Organization/Title Comments
19/01/2016 Alberic Moens MDM Team Initial draft
20/01/2016 Jelle Stuyver MDM Team Review initial draft
22/01/2016 Alberic Moens MDM Team Integration of comments
12/02/2016 Jelle Stuyver MDM Team Update
03/03/2016 Dennis Lemmens MDM Team Update
10/03/2016 Véronique Basteleus Process owner Review (prevalidation session 1)

governance financial
master data
10/03/2016 David Crabbe BPA BP&S Review (prevalidation session 1)
10/03/2016 Koen De Pelsemaeker Integration Team Review (prevalidation session 1)
10/03/2016 Luc Timmerman Integration Team Review (prevalidation session 1)
11/03/2016 Véronique Basteleus, - Prevalidation session 1

David Crabbe, Koen De
Pelsemaeker, Luc
Timmerman, Jelle
Stuyver, Peter Van den
Spiegel, Dennis
Lemmens
09/05/2016 Jelle Stuyver, Dennis MDM Team Finalize for prevalidation session 2
Lemmens
12/05/2016 Véronique Basteleus Process owner Review (prevalidation session 2)
governance financial
master data
12/05/2016 Koen De Pelsemaeker Integration Team Review (prevalidation session 2)
12/05/2016 Luc Timmerman Integration Team Review (prevalidation session 2)
13/05/2016 Véronique Basteleus, - Prevalidation session 2

David Crabbe, Koen De
Pelsemaeker, Luc
Timmerman, Jelle
Stuyver, Dennis
Lemmens
10/08/2016 Jelle Stuyver MDM Team Update based summary session &
review VeBas
Distribution of Final Document

The following people are designated recipients of the final version of this document:
Table of Contents Page ii Document1

19-Mar-18
Name Organization/Title
Véronique Basteleus Process owner governance financial master data
David Crabbe BPA BP&S
Koen De Pelsemaeker Responsible MDM within Colibris 2.0 integration team
Johan Borghys Information domain responsable in Colruyt Group (Citta)
Stream Leads and MDM SPOCs
Reference to external files (SharePoint)

Filename Link SharePoint
MD BPD Controlling https://extranet-
sp.colruytgroup.com/projects/2013/doc360570/Te
mplate/Content%20Deliverables/CON-BPD-DS-005-
Manage%20Managerial%20Master%20Data%20Post
Validation%202.docx
MD BPD Invest to Divest – Perform https://extranet-
Asset Accounting (no separate MD sp.colruytgroup.com/projects/2013/doc360570/Te
BPD exists) mplate/Content%20Deliverables/BPD%20ITD%20P
erform%20asset%20accounting.docx
MD BPD Invest to Divest – https://extranet-
Investment order (no separate MD sp.colruytgroup.com/projects/2013/doc360570/Te
BPD exists) mplate/Content%20Deliverables/To-
Be%20Process%20Design%20-
%20Investment%20Order.docx
MD BPD Order to Cash https://extranet-
mplate/Content%20Deliverables/BPD_IP_Level%20
2_Create%20and%20maintain%20customer%20ma
ster%20data_Validated.docx
MD BPD Purchase to Pay https://extranet-
mplate/Content%20Deliverables/BPD_MDM030_Cre
ate%20and%20maintain%20vendor%20master%20
data.docx
MD BPD Record to Report https://extranet-
mplate/Content%20Deliverables/BPD_IP%20Level
%202%20-
%20MDM070%20GL%20Master%20Data.docx
MDM Requirement Traceability https://extranet-
Matrix sp.colruytgroup.com/projects/2013/doc360570/Te
mplate/Working%20Documents/MDM/RTM_Require
mentsTraceMatrix-MDM.xlsm
Enterprise model CLM https://extranet-
sp.colruytgroup.com/projects/2013/doc360570/SAP
%20EM%20en%20MD/Final%20Documents/freeze
%20Colruyt_Enterprise_Model_Finance%20CLM%20
V1.0.docx?Web=1
MDM Object Dependency Overview https://extranet-
mplate/Working%20Documents/MDM/Data_object_
Table of Contents Page iii Document1

19-Mar-18
Filename Link SharePoint
overview/MDM%20Object%20Dependency%20v0.4.
xlsx
MDM Data Object Overview https://extranet-
mplate/Working%20Documents/MDM/Data_object_
overview/Colibris_Data%20Object%20Overview_MD
M.xlsm
Table of Contents Page iv Document1

19-Mar-18
Table of Contents
1 INTRODUCTION ..................................................................................................................................... 7
DOCUMENT OBJECTIVE .................................................................................................................................. 7
DOCUMENT PROCESS SCOPE ........................................................................................................................ 7
1.2.1 Description ............................................................................................................................................ 7
1.2.2 Project Scope ....................................................................................................................................... 7
1.2.3 Mapping to Industry Print .................................................................................................................. 11
PROCESS VARIANTS ..................................................................................................................................... 12
2 PROCESS BLUEPRINT ........................................................................................................................ 13
PROCESS DIAGRAM ...................................................................................................................................... 13
2.1.1 Process Overview .............................................................................................................................. 13
PROCESS ACTIVITY DESCRIPTION: GENERIC PROCESS ............................................................................. 15
2.2.1 MDM-005-010 Create Master Data request ................................................................................... 15
2.2.2 MDM-005-020 Analyse Master Data request................................................................................. 19
2.2.3 MDM-005-030 Approve Master Data request ................................................................................ 24
2.2.4 MDM-005-040 Prepare implementation.......................................................................................... 26
2.2.5 MDM-005-050 Implement configuration solution........................................................................... 29
2.2.6 MDM-005-060 Perform User acceptance testing (UAT) ............................................................. 30
2.2.7 MDM-005-070 Release according to release schedule .............................................................. 31
2.2.8 MDM-005-080 Implement master data solution ............................................................................ 31
2.2.9 MDM-005-090 Perform 4 eyes review ............................................................................................ 32
2.2.10 MDM-005-100 Mapping update ...................................................................................................... 33
2.2.11 Mapping master data : ??? ............................................................................................................... 34
2.2.12 MDM-005-120 Provide End User training and documentation.................................................... 34
PROCESS ACTIVITY DESCRIPTION: MONITORING & REPORTING ................................................................ 36
2.3.1 MDM-006-140 Monitoring & Reporting ........................................................................................... 36
OVERVIEW OF TRANSACTIONS ..................................................................................................................... 38
3 BUSINESS REQUIREMENTS .............................................................................................................. 39
PROCESS ...................................................................................................................................................... 39
DATA STANDARDS & QUALITY....................................................................................................................... 41
SYSTEM & TOOLING ...................................................................................................................................... 42
METRICS / REPORTING ................................................................................................................................. 44
MAPPINGS ..................................................................................................................................................... 44
CHANGE IMPACT ........................................................................................................................................... 46
FUNCTIONAL INTEGRATION TOPICS ............................................................................................................. 48
3.7.1 Functional integration ........................................................................................................................ 48
4 SAP FUNCTIONALITY GAPS .............................................................................................................. 49
DEVELOPMENT REQUIREMENTS (WRICEF) : TBD..................................................................................... 49
4.1.1 Workflow .............................................................................................................................................. 49
4.1.2 Reports ................................................................................................................................................ 49
4.1.3 Interfaces ............................................................................................................................................. 49
4.1.4 Conversion .......................................................................................................................................... 49
4.1.5 Enhancements .................................................................................................................................... 49
4.1.6 Forms ................................................................................................................................................... 49
5 ROLES & AUTHORIZATIONS .............................................................................................................. 49
ROLES ........................................................................................................................................................... 49
Table of Contents Page v Document1

19-Mar-18
5.1.1 Role 1 : Process Owner .................................................................................................................... 49
5.1.2 Role 2 : Information owner .............................................................................................................. 50
5.1.3 Role 3 : Information responsible ...................................................................................................... 50
5.1.4 Role 4 : Data responsible.................................................................................................................. 50
5.1.5 Role 5 : Financial information Key-user (FIKU) ............................................................................. 51
5.1.6 Role 6 : Information Key-User (IKU)................................................................................................ 51
5.1.7 Role 7 : SPOC .................................................................................................................................... 51
5.1.8 Role 8: End User ................................................................................................................................ 51
5.1.9 Role 9: Administrator ......................................................................................................................... 52
5.1.10 Role 10: Information steward ........................................................................................................... 52
5.1.11 Role 11: Data steward ....................................................................................................................... 52
RACI MATRIX ............................................................................................................................................... 53
5.3. AUTHORIZATIONS : TBD ................................................................................................................................... 56
6 ANNEX .................................................................................................................................................. 56
7 ABBREVIATIONS ................................................................................................................................. 56
8 GLOSSARY ........................................................................................................................................... 56
9 OBJECTS IN SCOPE ............................................................................................................................ 57
Table of Contents Page vi Document1

19-Mar-18
1 INTRODUCTION
Document Objective
This Business Process Design aims to provide a high-level overview of the generic master data
governance process, the roles & responsibilities to execute the process and the related business
requirements for finance.
Document Process Scope

1.2.1 Description
Master data are the raw materials for our Finance processes. Good master data quality will allow for
qualitative output. In case our master data are below standard this will immediately impact the efficiency
and effectiveness of our processes as well as our reporting capabilities. Theref ore master data
governance processes should be defined and implemented to ensure a sufficient level of quality.
Master data management (MDM) is an orchestration of roles, responsibilities, processes, policies /

standards and systems/tools enabling an organisation to manage its information objects as a strategic
asset. By designing policies and implementing role-based processes to manage the lifecycle of master
data, we will maintain highly accurate and reliable master data for use, registration, processing, exporting
and analysis in operations, reporting, analysis and consolidation.
This document and all masterdata roles, process steps & requirements aim to be in line with the CITTA
guidelines and other applicable Group policies. Justification will be provided in case of deviations. Note
that at the time of writing this document, CITTA guidelines were not yet finalised and validated.
1.2.2 Project Scope

This document describes the generic governance process applicable to all master data objects used
within the financial processes of Colruyt group.
The list of these objects is available in the Data Object Overview which is attached below and can also be Commented [VB1]: Kopie in bijlage steken – lijst bevat nu
retrieved here. The list is also included in Annex 9 for reference purposes. meer dan 100 objecten? Check op volledigheid van deze
objecten die volledig moeten zijn
 ADAPTED
Colibris_Data Object
Overview_MDM.xlsm
The listed objects are classified according to several dimensions: Commented [VB2]: Toe te voegen: SAP masterdata type
en citta masterdata type + korte uitleg van citta indeling
 SAP Definition ADAPTED (see footnote)
 Use of the object at Colruyt Group
 SAP Primary Module
 Master Data Type (see below)
 Stream Owner
 …
Page 7 of 59 Document1
19-Mar-18
The master data objects are divided into 5 Master Data Types1:
 SAP Enterprise Model Data: The SAP enterprise model describes how Colruyt Group is
structured and organized within the SAP system. The model is a basic building block in a SAP
system and consists of a set of SAP enterprise elements that are linked one to another. These
connections ensure the integration between different processes and areas processed in the SAP
application. Note that SAP enterprise model data is a subset of SAP configuration data (see
below)
 SAP Master Data: business objects within SAP which are agreed on and shared across the
enterprise. Master data is generally known by the following characteristics:
 It remains unchanged over a long period of time.
 It contains information that is needed again and again in the same way
 It contains information that is used by multiple applications across an
organization more or less simultaneously
 SAP Configuration Data: data that defines the set of permissible values to be used by other data
fields. SAP treats reference data (e.g. country codes, units of measure) as configuration data.
Unlike SAP Master Data, SAP Configuration Data first needs to be set up in a development
environment before it can be transferred to the production environment.
 Legacy Master Data: business objects within legacy systems which are agreed on and shared Commented [VB3]: In de overzichtslijst is hier niets
across the enterprise. Master data is generally known by the following characteristics: aangeduid, nodig?
Staat in de tweede tab van de excel file apart opgelijst
 It remains unchanged over a long period of time.
 It contains information that is needed again and again in the same way
 It contains information that is used by multiple applications across an
organization more or less simultaneously
Note: Legacy master data are those data objects that are not known as such in
the SAP system
 Mapping Master Data: Mappings will be used within the assembly as well as the integration layer. Commented [VB4]: Moet hier ook niet SAP voor –ifv
A distinction needs to be made between two mapping types: eenduidigheid-?
 Mappings worden niet beheerd in SAP
o Business operational mappings: These mappings are required by the business in order to
transform their operational data into business operational data. The required mappings
will be stored and maintained by the business within their systems.
Example: Mapping between products & Fin. Product code (e.g. new type of fuel)
o Business financial mappings: These mappings are required by finance in order to
transform business operational data into business financial data. The required mappings
will be stored and maintained by Finance within their systems
Example: Mapping between legal entity legacy & company code (K5  BEK5)
Several objects exist in multiple systems. Whenever these objects are not linked by a one to one
relationship without additional logic, the objects will be mentioned separately in the Data Object Overview
(e.g. Vendor in FinRel application is linked to Business Partner in SAP via mapping rules). Commented [VB5]: Business of trading partner?
Business partner (trading partner heeft te maken met IC)
The linked objects do not necessarily have the same Master Data Type. Which objects are linked is made
visible in the Data Flow Overview. Data flow overview Commented [VB6]: Waar beschikbaar?
ADDED
1
The CITTA classificiation of objects is highly related to the dimensions mentioned in this BPD. However,
the configuration data in this document can be divided in process and reference data. Furthermore, SAP
and legacy masterdata can be seen as one group.
19-Mar-18
Microsoft Excel
Worksheet
The end-to-end governance for SAP Enterprise Model Data, SAP Configuration Data and SAP Master
Data objects is in scope of this document.
The scope for legacy master data in non-finance systems is limited to the:
 Definition of data requirements to ensure a correct, complete and accurate data transfer to the
relevant system; and alignment of these requirements with the business.
 Provision of value lists to ensure the correct business operational mappings can be defined.
Thus the creation or modification of master data in systems outside finance is out of scope. The generic
governance will, however, be applicable to the creation or modification of master data objects in finance
legacy systems.
Maintenance of business financial mappings in the sustainable interface are in scope. Functions in the Commented [VB7]: Voorbeeld geven zodat duidelijk is
sustainable interface (SAP data generators based on multiple values , e.g. : product type, country, & waarover dit gaat
currency define VAT percentage) are out of scope. After detection, these functions must be escalated and ADAPTED
taken up further as part of the operational process.
The scope for maintaining business operational mappings in the assembly layer is limited to providing
value lists and aligning these with the business. Commented [VB8]: Waar te vinden?
Not yet defined
Is ook iets anders de mapping zelf
Below figure illustrates the scoping of master data objects throughout the generic system landscape:
19-Mar-18
An MDM object dependency overview is attached below and can be retrieved here. This document
describes the high level dependencies between all objects. Note that at the time of writing this document,
this dependency overview was not yet finalised and validated.
MDM Object
Dependency v0.4.xlsx
A generic governance process means that this process will be applicable to all master data objects.
During the rollout project, this process will be further applied to each specific object. At that moment,
different levels of approval, analysis, etc. will be distinguished depending on the defined scenario. The
specificities for each individual SAP master data object will be further elaborated in the BPP,(SAP
configuration data will be elaborated in a configuration document, mapping data will be documented in
Functional and Technical Specication Documents) and are thus out of scope of this document.
The generic process covers the correct creation, modification (including changing and blocking) &
deletion of master data objects in all impacted finance systems, starting from a business need until the
objects are released or created and proper training & documentation is provided. The use of these
objects and all corresponding transactional data is not in scope of this document. Archiving is also not in
scope and should be part of a dedicated process related to archiving. For the implementation of the
specific master data objects, this document will refer to the individual Business Process Designs (BPD),
Functional & Technical Specification Documents, Enterprise Model Documents & Configuration
Documents. All relevant MD BPDs are listed in the table “reference to external files” (page 3).
Master data migration is not in scope of this document and will be further defined by the data migration
team.
For configuration & enterprise model master data changes it will be required to launch a project. In this
case the standard Colruyt project management practices and methodology apply. Process steps
concerning project handling are highlighted in grey. At this moment, the project handling of information Commented [VB9]: Other
objects is not yet defined. ??
Furthermore, this document defines which steps will be executed by BP&S. These steps are aligned with
the BP&S Service Model. How these steps will be achieved is not in scope of this document. Below some Commented [VB10]: misschien algemeen principe
highlights of the BP&S Service Model are summarized. weergeven gezien dit grote change is: request en functional
assessment is accountability of finance, the technical
assessment and administration for EM, Config is
Finance accountability BP&S accountability aacountability Bp&S. only if there is no technical impact eg for
standard SAP Master Data no interference of BP&S is
Analysis Functional & impact assessment Technical & system impact assessment needed.
Evt . rubriek roles & responsabilities toevoegen?
Administration Administration of masterdata objects Administration of enterprise model Hieronder dan ook vermelden welke rollen
objects & configuration objects functioneel/business zijn, en welke technisch/bp&s – en dat
meerdere rollen door 1 persoon kunnen opgenomen worden
Key roles Information administrator & information key- Data administrator & data responsible maw het is niet zo om een cc aan te vragen dat dit door 20
user / responsible paar handen gaat.
The roles are described in detail under section “5. Roles & responsibilities”. ADAPTED
Note that a role is assigned to each of the described processsteps in the generic process. However, it is
possible that one person fulfils multiple roles (e.g. within a smaller organization, one person can take on
the role of SPOC & information key-user).
19-Mar-18
1.2.3 Mapping to Industry Print
19-Mar-18
Process Variants
 Monitoring & reporting
o A key successfactor for good Master Data maintenance is installing and embedding
rigorous Monitoring & Reporting to allow for sufficient control over the master data.
o Monitoring & Reporting will be executed periodically and will be discussed as a variant in
a separate process flow.
A separate BPP will be created for Monitoring & Reporting
19-Mar-18
2 Process Blueprint
Process Diagram
2.1.1 Process Overview
Note: The process diagram is split in two separate images for better readability Commented [VB11]: Blokje 005-020: hierin al opdeling
maken Confi/mapping/EM tov MD en legacy
 Note made in “2.2.2.3 MDM-005-020-030” that type of
Master Data Request is known already in “MDM-005-020.
Figure 1 Colruyt Process MDM-010 Generic Flow
19-Mar-18
The process MDM-005 Generic Flow includes the following activities:
 MDM-005-010 Create Master Data request

 MDM-005-020 Analyse Master Data request
 MDM-005-030 Approve Master Data request
 MDM-005-040 Prepare implementation
 MDM-005-050 Implement configuration solution
 MDM-005-060 Perform UAT
 MDM-005-070 Release according to release schedule
 MDM-005-080 Implement MD solution
 MDM-005-090 Perform 4-eyes-review
 MDM-005-100 Mapping update
 MDM-005-120 Provide End User training and documentation
19-Mar-18
Process Activity Description: Generic Process
2.2.1 MDM-005-010 Create Master Data request
This process can be triggerd in several ways:

 Business need of an information End User
 Anomaly detected during exception reporting, data quality reviews, …
2.2.1.1 MDM-005-010-010 Define business need & priority

The first step in the process is the definition of the business need. The business need is comprised of
several elements:
 business problem that the end user wants to solve,
 business objective that indicates the desired outcome / result the end user wants to achieve,
 priority which denotes the urgency and impact of the problem to the end user, and
 acceptance criteria which determine when all requirements are met / the solution is well
implemented. (e.g.: for creation of a new GL CAPL account, check that a corresponding
CACL/CALL account exists or has been created.)
All elements of the business need will be described in a request template.
The priority determines the speed by which the consecutive steps of the process will be executed.
A Master Data request will have one out of two priorities:
1. High – emergency Master Data request
 Business problem that is blocking the operational processes and will follow the Master
Data Goverance (MDG) process at an accelerated pace. A problem is blocking when the
End User cannot deliver his/her task within the expected time and quality level. The
blocking nature of a problem is assessed by the SPOC and IKU
 Request that needs to be implemented faster than the standard service level
engagement (SLE).
2. Medium – standard Master Data request
19-Mar-18
 Business problem that is not blocking and can follow the MDG process at a normal pace.
 Request that can be implemented following the standard SLE.
Note: The standard SLE will be split up for different groups of objects (e.g. a standard MD
change will normally have a faster SLE than the configuration of an enterprise object).
The justification for a certain priority should always be provided in the request form. In case of an
emergency request, additionally corrective actions must be initiated to avoid similar emergency requests
in the future. All steps of the MDG process have to be executed in case of an emergency request.
Examples:
1 – High: Company that last minute needs to be set up before year end closing
2 – Medium: Creation of cost center for a store that will be opened in a few months time.
SLEs about the delivery date (timing) will be defined per priority (as mentioned above) and per Master
Data Type (i.e. SAP & Legacy Master Data, SAP Configuration Data, SAP Enterprise Model Data, and
Mapping Master Data). SLEs for SAP Configuration & Enterprise Model Data will be determined by the
service model. SAP & Legacy Master Data will be subject by an SLE defined within Finance for the
delivery. When SLEs are defined, they will take into account the lead time of all related activities including
those resulting from changes in legacy systems. The parties to agree the SLEs for mapping master data
still have to be identified. (to be determined in a later stage).
The required implementation date of a master data request should be defined by the End User. The End
User will define the priority by matching the required implementation date with the SLE. Later on in the
process, this priority will be confirmed.
Process step has been assigned to role: End User
2.2.1.2 MDM-005-010-020 Fill in Master Data request form

Specific Master Data request forms will exist for the creation, modification and deletion of master data
objects.The correct Master Data request form needs to be filled in with all relevant fields for further
analysis. Where necessary, documents supporting the request have to be attached or referred to.
The Master Data request form contains all the necessary information for the request to be easily reviewed
& approved, and subsequently released & verified in the system. All mandatory fields of the request must
be filled in.
It might be the case that some non-mandatory fields will not be completed in this step. These fields will be
completed in a later stage (e.g. in the analysis phase). The list of non-mandatory fields in this stage will
be listed per object. In case of a SAP/legacy master data request, all fields will be mandatory, this means
that all information must be available for implementation before requesting the master data change.
Reasons for not filling in certain (non-mandatory) fields are:
- the information is not available at this moment
(e.g. bank account number does not exist yet at the moment of a business need for a new
company)
- the requestor does not posses the knowledge to complete the field
All fields must be completed in compliance with their description and objective. Each form should also be
completed in line with the defined Master Data business & quality rules and guidelines (to be determined
in a later stage).
The same (business & quality) rules, guidelines and procedures also apply to mass Master Data
requests, and changes where multiple objects are impacted. A mass Master Data request means that
multiple, similar changes are demanded at once. Criteria that determine a mass Master Data request still
19-Mar-18
have to be defined. An example of a mass Master Data request is: name change of all bioplanet cost
centers incase bioplanet changes from name.
A Master Data request can impact more than one object. Related objects required to execute the change
must therefore be identified and requested by adding the correct information in the request form.
Example 1: for creation of a CAPL account, request a CACL account if it cannot be mapped to an existing
account.
Example 2: A new cost center needs one profit center and , at least, one cost center group.
After the request template is filled in, it is sent to the SPOC to check its relevance, completeness and
priority.
Process step has been assigned to role: End User
2.2.1.3 MDM-005-010-030 Check relevance, completeness and priority

The relevance, completeness and priority of the Master Data request will be evaluated. Addititionally the
alignment between all master data requests within the same domain will be ensured.
If the Master Data request is not relevant, it will be rejected. If not all mandatory information is correctly
filled in, the Master Data request will be sent back to the End User to complete the missing information.
Additionally, the priority of the request, as defined by the End User, will be verified.
Process step has been assigned to role: Single point of contact (SPOC)
2.2.1.4 MDM-005-010-040 Motivate and communicate rejection

If the Master Data request is invalid, it will be rejected. An invalid request means that the demand is not
relevant. A clear motivation and alternative solution or correct work method, if applicable, must be
provided. The rejection must be communicated to the End User and be available to retrieve for all
stakeholders.
Process step has been assigned to role: SPOC
2.2.1.5 MDM-005-010-050 Perform preliminary impact assessment & determine impacted Master
Data types
The impact assessment includes the analysis of the potential impact on other master data objects and
processes, on the organization as well as on systems & tools. Every impact must be considered. The
impact assessement is performed in two steps:
 A preliminary impact assessment performed by the SPOC
 A full impact assessment performed by the IKU (see 2.2.2.3)
A two step approach is chosen to limit the workload of the IKU.
Each data object will have a specific impact assessment, in which different criteria are taken into account.
Depending on these criteria, a more extensive impact assessment will be done for certain objects. (to be
determined which in a later stage).
Mandatory fields are filled in by the SPOC as part of the preliminary impact assessment. Which fields will
be mandatory still has to be determined (in a later stage). The remaining fields of the impact assessment
will be completed during the full impact assessment and extended analysis by the IKU.
The list of criteria and possible impacts will be further assessed, but could consist of the following:
 General:
19-Mar-18
o Timing of the execution of the change
o Dependencies (ex. Projects, legal requirements, etc.)
 Objects & processes:
o The position in the hierarchy or structure of the object
o Other objects that are required to execute the change (and not yet detected by the End
User)
o Other impacted processes to be initiated
Example: for creation of a new company, request a house bank account. (A house bank
account must be requested to an external institution, therefore this is a separate
process.)
Analysis and list of mappings in assembly and sustainable interface
Note: a detected need for an update of a function must be escalated towards the process
owner. A function will not be updated within this process because it refers to business
logic
 Systems & tools:

o Impact on systems (e.g. SAP, Corporate Performance Management, mainframe
modules, “as-of” date for validty periods ,etc.)
o Impact on reports
 Organization:
o Stakeholders to be informed
o Impact on teams or staff
The objects required to execute the change identified during the (preliminary & full) impact assessment
and their related Master Data Types will in a later step (2.2.3.7) determine which Master Data
implementation flows will be followed.
2.2.1.6 MDM-005-010-060 Finalize Master Data request form

Fields that are mandatory before submitting the master data request, but that the End User was unable to
fill in or cannot be completed by the EU, are completed by the SPOC. In this respect, the workload of the
SPOC must be limited to the bare minimum.
2.2.1.7 MDM-005-010-070 Submit Master Data request form

Once the template is completed, the Master Data request will be submitted for analysis. Submitting the
form implies that the request is complete and accurate.
19-Mar-18
2.2.2 MDM-005-020 Analyse Master Data request Commented [VB12]: Cfr zie aparte tekening
1.1.1.1ADAPTED in MDM-005-020-030 Complete impact
assessment

19-Mar-18
This process can be triggered in one way:
 A Master Data request is created and submitted.
2.2.2.1 MDM-005-020-010 Check correctness of request

The submitted Master Data request will be analysed based on the guidelines and Master Data quality
rules. The Master Data quality rules will be established in the Business Process Procedures.
An evaluation will be performed to identify:

- if the provided information is correct
- if the business need is confirmed and relevancy is checked
In case the Master Data request is invalid, it will be rejected or sent back to the SPOC. An invalid request
means that the demand is not relevant or that the provided information is not or only partially correct.
Process step has been assigned to role: Information Key User (IKU)
2.2.2.2 MDM-005-020-020 Motivate and communicate rejection

When a Master Data request is rejected, a clear motivation and alternative solution, if applicable, will be
provided. The rejection must be communicated to all relevant stakeholders.
Process step has been assigned to role: IKU
2.2.2.3 MDM-005-020-030 Complete impact assessment

The mandatory fields that were filled in during the preliminary impact assessment (see 2.2.1.5) will be
reviewed to ensure that all impact of the change is considered. In case the impact is incorrect or
incomplete, the impact assessment will be modified or further detailed. The optional fields of the impact
assessment that were not yet completed will also be filled in at this stage. This can be done by the IKU or Commented [VB13]: In de tobe moet de IKU de expert zijn
the IKU can decide that assistance of the financial information key-user (FIKU) and/or data responsible is zodat FIKU en IKU één kunnen zijn
required. The two steps below (MDM-005-020-040 & MDM-005-020-060) describe which components of Moet ik hier iets voor aanpassen?
Opsplitising IKU & FIKU komt verschillende keren terug
the impact assessment can be analysed by the FIKU and data responsible respectively. During the in dit document.
impact assessment, the type of Master Data request is be determined.
An extended analysis (assistance of FIKU and data responsible) is always needed in case of an
enterprise model object request. Furthermore, the IKU determines the need of extended analysis based Commented [VB14]: En config
on the identified business scenario. A standard scenario (e.g. creation of a cost center for a new division) Lijkt mij inderdaad meestal het geval, maar een config
requires only a standard analysis, a non-standard scenario will require the extended analysis. The criteria wijziging kan ook gaan over een GL account group dat
moet aangepast worden op basis van een GL account
to define the scenario will depend on the number of impacted systems, the existence of previous request request. Mogelijks is de complexiteit hiervan beperkt en kan
with a similar solution, number of impacted processes and reports, etc. The precise criteria will be defined dit ook gestandardiseerd worden?
in a later stage (TODO).
In this stage, it must be clear which objects (& mappings) will be impacted by the request and as a
consequence, which implementation flows must be triggered.
19-Mar-18
2.2.2.4 MDM-005-020-040 Perform detailed analysis of functional and organizational impact
An in-depth analysis of the functional impact will be performed in order to avoid issues due to collateral
impacts. This analysis is part of the impact assessment that was initiated by the SPOC and completed by
the IKU. All impact areas that were not assessed earlier will be considered at this point:
 Functional impacts (e.g. impact on other objects, processes, projects, reporting, etc.) and the
actions that need to be taken. (This analysis can also assist in determining the depth, number
and type of functional test cases/scenarios.)
 Impact on projects and programs
 Impact on data model and finance processes
 Adjustment of reporting
 Required mappings (& functions) in sustainable interface and assembly
The impact will be documented in a central knowledge base so it can be reused for future requests.
Process step has been assigned to role: FIKU
2.2.2.5 MDM-005-020-060 Perform detailed analysis of system impact

An in-depth analysis of the impact on the systems will be performed in order to avoid issues due to
collateral impacts. This step is part of the impact assessment that was initiated by the SPOC and
completed by the IKU. All elements that were not assessed earlier will be considered at this point:
 Impacted systems
 Required mappings (& functions) in sustainable interface and assembly
The impact will be documented in a central knowledge base so it can be reused for future requests.
Process step has been assigned to role: Data Responsible
Note: Determination of the required mappings is a joint responsibility between the Data Responsible and
the FIKU. The FIKU will be responsible for the functional identification of the required mappings whereas
the Data Responsible will cover how these mappings will be established between the different systems.
2.2.2.6 MDM-005-020-070 Create high level workload estimate

The amount of work to implement the solution will be estimated based on the system impact analysis ,
configuration, required testing and training and possible other activities. A detailed workload estimate will
be performed after the Master Data request is approved (MDM-005-030-010) and the system
configuration is analysed.
Process step has been assigned to role: Data Responsible
2.2.2.7 MDM-005-020-080 Define target implementation date Commented [VB15]: Moet dit niet voor vorige stap komen
zodat vanuit functionele kant volledig is?
Based on a release calendar and the performed analysis a target implementation date2 will be determined Volgens mij niet , BP&S moet eerst de workload
for all objects. inschatten alvorens er een datum kan voorgesteld worden,
This target implementation date is not a firm commitment when the requested change will be available in dit zal afhangen van de complexiteit etc. cfr company à la
okay compact overnemen of ZEB volledig opzetten in SAP.
the system. The target implementation date will be used as a guideline for the scheduling of the Master
2
See glossary (chapter 8) for ‘implementation date’ definition
19-Mar-18
Data request. In a later step (MDM-005-040-060), the implementation date on which the change will be
available in production will be confirmed.
The target implementation date will be compared with the applicable SLE (based on the given priority and
object type). In case the target implementation date deviates from the SLE, the date is aligned with the
end user and revised if needed according to feasibility.
2.2.2.8 MDM-005-020-090 Align implementation date with End User

As mentioned above, the target implementation date must be aligned with the End User if the date
deviates from the SLE. There are several reasons why the target implementation can deviate from the
SLE:
 The master data request is more sizable or complex than foreseen – this will mostly be relevant
for changes that will be handled via a project (i.e. primarily SAP enterprise model objects)
 The master data request is exeptionally more urgent than the SLE defined for high priority
requests
 A technical or resource problem causes a delay in the performed services.
The target implementation date can therefore be revised according to feasibility of all parties. This new
target implementation date will be communicated to all relevant stakeholders.
2.2.2.9 MDM-005-020-100 Finalise request form

The request form must be completed with the performed impact assessment and the agreed
implementation date.
2.2.2.10 MDM-005-020-110 Determine need for project

A project must be initiated for SAP configuration data and enterprise model data requests; other criteria
and project templates will be listed in a later stage.
If a project is required, a project form must be completed. Other steps are part of the finance project &
portfolio process. These steps are not part of the master data governance process, are only correct at the
time of writing this document and are highlighted in grey. Please refer to portfolio management Commented [VB16]: Deze stappen weglaten om te
documentation for the complete and most recent overview portfolio management process steps. vermijden dat dit hier ook moet aangepast worden indien er
op vlak van portfoliowerking iets wijzigt; er wel naar verwijzen.
Melding gemaakt dat de stappen uit de portfoliowerking
enkel correct zijn wanneer dit document werd geschreven, en
dat de portfoliomanagement documentatie dient te worden
2.2.2.11 MDM-005-020-120 Prepare project form geraadpleegd voor volledige en meest recente process.
If the Master Data request will be handled as a project, a project form must be created. This project form (Indien we de stappen verwijderen verandert de nummering
van alle procestappen.)
is aligned with the standard colruyt group project form. This project form will be submitted to the
“portfolioraad” (PFR) after the validation by the Information responsible.
19-Mar-18
2.2.2.12 MDM-005-020-130 Provide recommendation to approver
Based on the global analysis of the request, a recommendation will be provided to assist the approval
process.
19-Mar-18
2.2.3 MDM-005-030 Approve Master Data request
19-Mar-18
2.2.3.1 MDM-005-030-010 Review and approve Master Data request
Approval of the Master Data request is given based on the content of the request and the output of the
analysis. Approval contains following actions:
 review of the completeness, correctness & relevance of the request;
 review of the impact assessment, which includes:
o Review of detailed analysis of functional and organizational impact (e.g. data model
impact, mappings)
o Review of detailed analysis of system impact (e.g. technical impact)
 review that the request is in line with the group strategy and policies
The approval should be formally added to the request template. The decision is then communicated to all
relevant parties.
Process step has been assigned to role: Information Responsible
2.2.3.2 MDM-005-030-020 Communicate and document rejection

In case the Master Data request is incomplete, it will be sent back to the SPOC for updating.
If the Master Data request is rejected due to incorrectness or irrelevance, the rejection of the request
must be communicated to all relevant stakeholders. This communication should have a rationale of the
decision to reject. An alternative solution should be suggested (if applicable). Based on the rejection,
procedures and rules may have to be updated in order to avoid similar situations in the future.
Process step has been assigned to role: Information key-user Information Responsible Commented [VB17]: Communiceren en valideren ->
(F)IKU; information responsible is escalatielijn maar zal zelf de
documentering niet doen..
ADAPTED
2.2.3.3 MDM-005-030-030 Submit project form to PFR
Before starting with the preparation of the implementation, the PFR must validate the project form.
Therefore, the project form must be submitted to the PFR.
Process step has been assigned to role: Information Responsible
2.2.3.4 MDM-005-030-040 Approve project form

The PFR evaluates the project form and descides if the project can be executed and can start at the
suggested date. The PFR can reject the request. Hereby, decision must be communicated to all relevant
stakeholders. Furthermore, the PFR can delay the project and can enforce rework (e.g. further
analysis,etc.)
Process step has been assigned to role: Portfolioraad (PFR)
2.2.3.5 MDM-005-030-050 Communicate rejection

If the Master Data requestmaster data request is rejected, the rejection of the request must be
communicated to all stakeholders.
This communication should have a rationale for the decision to reject. An alternative solution should be
suggested if applicable.
Process step has been assigned to role: Portfolioraad (PFR)
19-Mar-18
2.2.3.6 MDM-005-030-060 Request project code
The project code should be requested after approval of the Master Data requestmaster data request.
Other steps to initiate the project should also be performed in this phase.
The definition of a service and project and how the different requests should be classified, will be defined
in a later stage. However, enterprise model data will certainly be handled as a project.
2.2.3.7 MDM-005-030-070 Initiate required implementation flow(s)

From the detailed impact analysis it will have become clear which other objects are in scope of the
request. These objects and their related Master Data Types determine which implementation flows will be
triggered (e.g. a SAP master data update can be accompagnied by an update of mapping data).
Three different implementation flows can be distinguished: Commented [VB18]: So one request can cause till…
 Mapping Data ADAPTED
 SAP & Legacy Master Data

 SAP Configuration & Enterprise Model data
All 3 implementation flows can be triggered by one request.
Each implementation flow contains several steps:

 Implementation flow SAP Configuration (& EM) Data
o 2.2.4 MDM-005-040 Prepare implementation
o 2.2.5 MDM-005-050 Implement configuration solution
o 2.2.6 MDM-005-060 Perform User acceptance testing (UAT
o 2.2.7 MDM-005-070 Release according to release schedule
 Implementation flow SAP & Legacy Master Data
o 2.2.8 MDM-005-080 Implement master data
o 2.2.9 MDM-005-090 Perform 4 eyes review
 Implementation flow Mapping Data
o 2.2.10 MDM-005-100 Mapping update
o ??3
The individual implementation flows and their steps are discussed consecutively in what follows .
2.2.4 MDM-005-040 Prepare implementation

This is the first step in the SAP Configuration & EM data implementation flow. This flow will always be
taken up as a project. Depending on the need, different project templates will be created e.g. for
frequently recurring requests. The templates will be created within the Service Model for Finance.
3
Ambiguity exists on how mapping updates will be performed and how the mapping changes will be
accepted by the business. (to be determined in a later stage)
19-Mar-18
Prepare implementation diagram:
2.2.4.1 MDM-005-040-010 Initiate other processes

Other impacted processes to be initiated will have been identified during the impact assessment. The
other processes can be initiated after approval of the Master Data request. Some of these processes are
required to generate the correct information during the next step.
Example: for creation of a new company, request a house bank account. (A house bank account must be
requested to an external institution, therefore this is a separate process)
2.2.4.2 MDM-005-040-020 Collect additional information

Once the project is started, more parties could be involved. Missing information will be added to the
Master Data request by all relevant parties, in order to complete it before implementation. All relevant
parties will be requested to deliver their specific information within the agreed timing, based on the
initiated processes or their specific knowledge area.
Missing information that was not yet filled in earlier because it was not yet available or was not blocking
the analysis and validation of the request will have to be completed at this point. After all, this information
will be critical for the correct implementation of the master data object (e.g. a VAT registration number
must be foreseen for a new company but is not immediately available)
2.2.4.3 MDM-005-040-030 Analyse required system change

The system configuration and impact will be verified to see if the implementation can be performed
without additional actions. Additionally the actions necessary to execute the change will be done.
Process step has been assigned to role: Data responsible
19-Mar-18
2.2.4.4 MDM-005-040-040 Create detailed workload estimate & planning
The amount of work to be performed to implement the solution will be defined in detail based on the
analysis of the required system change and a previous estimate. This estimation and corresponding
planning will be used to schedule the Master Data request.
2.2.4.5 MDM-005-040-050 Create detailed project sheet

If the Master Data request is handled as a project, a detailed project sheet must be created and sent to
the PFR for information.
2.2.4.6 MDM-005-040-060 Schedule release4

The Master Data request of a configuration object will be added in a waiting list for implementation. This
will be done based on the targed implementation date, after alignment with the SLE and, if needed, the
End User. Once a request is added in the waiting list, the final implementation date is set.
Master data objects (non-configuration) will be scheduled based on the agreed implementation calendar.
2.2.4.7 MDM-005-040-070 Inform about delivery date

Based on the release calendar, communicate the confirmed implementation date to all related parties.
4
These steps must be in line with the service model
19-Mar-18
2.2.5 MDM-005-050 Implement configuration solution
Note: The orange color of several process steps indicates that the content of these steps will be further
defined in another document (e.g. SAP configuration data in the configuration document , SAP
masterdata in the MD BPP)
2.2.5.1 MDM-005-050-010 Configure and test implementation

Configuration of the implementation will be described in specific Configuration Documents. Additionally,
for each change testing will be performed and documented. Depending on nature and complexity of the
change, this could include unit, integration, and/or other types of testing.
Process step has been assigned to role: Administrator
2.2.5.2 MDM-005-050-020 Update functional & technical documentation

After the implementation, the functional & technical information documentation will be updated according
to the implemented changes.
2.2.5.3 MDM-005-050-030 Update other systems

Update slave systems in and outside finance that are impacted by this change. These updates of slave
systems can be done manual or automatically (interface). By preference, an automatic synchronization
between master and slave is set-up. Creations/Updates are then automatically replicated (pushed)
towards slave-systems. A finance system that is manually updated will follow the generic governance
process.
2.2.5.4 MDM-005-050-040 Prepare UAT session in Test environment

After implementation, the user acceptance testing needs to be prepared. Test data needs to be available
in the test system (SYST) and the business scenarios in which the changes will be shown need to be
tested. The acceptance criteria should be clearly defined during the preparation.
Note: IT related tests are created and executed as part of the subprocess MDM-005-050-010 Configure
and test implementation (MDM-005-050-010 Configure and test implementation 2.2.5.1).
Process step has been assigned to role: Administrator (In collaboration with the SPOC)
19-Mar-18
2.2.6 MDM-005-060 Perform User acceptance testing (UAT)
2.2.6.1 MDM-005-060-010 Request UAT testing

Before a change can be moved to the production environment, the solution must be tested. The SPOC
will be asked to perform UAT in the test environment.
2.2.6.2 MDM-005-060-020 Execute UAT

User acceptance testing should be performed for all create, update or delete of configuration objects via
the configuration menu of SAP. These testing will be performed in the test environment. In this UAT
session, the implemented solution will be presented to the involved parties, in order to confirm that the
acceptance criteria are met. Test evidence will be provided in a UAT report. A change will always be
tested for regression to ensure that no other system functions were impacted by the implemented
change.
Note: IT related tests are created and executed as part of the subprocess MDM-005-050-010 Configure
and test implementation (MDM-005-050-010 Configure and test implementation 2.2.5.1).
2.2.6.3 MDM-005-060-030 Rework implementation

If the acceptance criteria were not met, the configuration will require rework . If rework is needed, the
implementation steps need to be executed again and a second UAT run must be organized.
2.2.6.4 MDM-005-060-040 Approve UAT report (sign-off)

Once the (re)work is completed and the acceptance criteria have been met with this implementation, the
UAT report must be signed-off.
The signed-off UAT report with testing evidence (including any pending defects) must be sent to all
involved parties, hereby the move to production environment can be requested.
19-Mar-18
2.2.7 MDM-005-070 Release according to release schedule
For configuration changes a release schedule will be followed. This schedule will determine when the
implemented changes can be release to the production environment.
If applicable, activities that can only be performed after the release are also performed at this stage (e.g.
checks in production environment)
2.2.8 MDM-005-080 Implement master data solution
2.2.8.1 MDM-005-080-010 Execute change in master system

The master data create/update/delete will be performed based on the input from the Master Data request.
This will be implemented directly in production environment and executed by an Administrator. This will
be described in the specific master data BPDs & BPPs.
2.2.8.2 MDM-005-080-020 Update other systems

Other (slave) systems in and outside finance that are impacted by this change and require an update
were identified during the impact assessment. The update of these systems can be either occur
mannualy or automatically. By preference, an automatic synchronization between the master and slave
systems is set-up. Creations/Updates are then replicated (pushed) towards slave-systems. A finance
system that is manually updated will be subjected to the generic governance process.
19-Mar-18
2.2.9 MDM-005-090 Perform 4 eyes review
2.2.9.1 MDM-005-090-010 Check implementation

When a SAP transaction is executed in the production environment to create or change master data, this
data becomes immediately available. The creation, update or deletion of a master data object will
therefore be double-checked in the production environment of SAP & all relevant legacy systems (4-eyes-
review). The reviewer will check if all critical fields are correctly implemented. Relevant legacy systems
are those systems in which a manual update is executed.
Additionally, because the master data change becomes immediately available to all users, the 4-eyes-
review will be performed as soon as possible. For this reason, a strict calender will be put in place and
arrangements will be made with all involved parties (in a later stage).
2.2.9.2 MDM-005-090-020 Rework implementation

If the modification is not according to the requirements, rework will be performed. The steps from the
‘Implement Master Data Solution’ subprocess (see 2.2.8), and afterwards the ‘Perform 4 eyes review’
(see 2.2.9) will have to be reperformed one after another.
Again, because the master data change becomes immediately available to all users, these steps have to
be executed in an expedited manner.
19-Mar-18
2.2.10 MDM-005-100 Mapping update
Mappings will be used within the assembly as well as the integration layer. The following mappings are
concerned:
 Mappings in the assembly
 Mappings in the sustainable interface
A distinction needs to be made between the following mapping types:

 Business operational mappings used within the assembly layer under responsibility of the
business (e.g. a mapping between new fuel and financial product code)
 Business financial mappings used within the integration layer under responsibility of Finance (e.g.
the mapping between company codes)
Business operational mappings are required by the business in order to transform their operational data
into business operational data. The required mappings will be stored and mainta ined by the business
within their systems. These mappings are executed in the assembly layer. The scope for maintaining
business operational mappings in the assembly layer is limited to providing value lists (see 1.2.2) and
aligning these with the business. Therefore agreements will be made between the business and finance
with respect to these business operational mappings in terms of create, update and delete of ma pping
(values) during the roll-out project
Business financial mappings are required by Finance in order to transform business operational data into
business financial data. The required mappings will be stored and maintained by Finance within their
systems. Creation, updates and/or deletes of mapping(s) and/or mapping tables will only be performed
after appropriate approval via execution of this governance processes. These mappings are executed in
the sustainable interface. Moreover, an update in the functions can be required. This need must always
be escalated towards the process owner of the corresponding operational process and will, as a
consequence and as discussed earlier (see 1.2.2), not be in scope of the master data governance
process .
As part of business financial mappings, key and value mapping tables between S/4 HANA and
surrounding systems need to be stored and maintained. This is needed in order to be able to interface the
data form SAP S/4 HANA to the surrounding systems.
19-Mar-18
An update of mappings can be a stand-alone request or it can be a consequence of a master data
change.
2.2.10.1 MDM-005-100-020 Update mappings in sustainable interface

Update of the mappings of the sustainable interface will be described outside this document.
2.2.10.2 MDM-005-100-030 Update mappings in assembly

Update of the mapping in assembly will be described outside this document.
2.2.11 Mapping master data : ???
How mappings will be processed after the changes have been executed is still unclear, this will further be
clarified. (to be determined in a later stage)
2.2.12 MDM-005-120 Provide End User training and documentation
2.2.12.1 MDM-005-120-010 Update documentation

All guidelines and rules will be kept easily available and up-to-date. Therefore, all documents that are
related to the implementation of a financial MD object will be updated after each request. A non-
exhaustive list of documents that will need to be updated is:
 User documentation
 Functional updates
 Procedures
 Business rules
19-Mar-18
A central repository will be available to store governance and object-specific MDM documentation. This is
also easily accessible to stakeholders. Versioning will be ensured in the repository.
Furthermore, all requests & decisions will be archived and properly documented so to fall back on the
central repository and history of previous requests.
2.2.12.2 MDM-005-120-020 Prepare project close and communicate to PFR

The project close will be prepared in accordance to standard project management processes, and
reported to the PFR.
2.2.12.3 MDM-005-120-030 Communicate to all stakeholders

All involved parties will be informed of the executed changes.
All involved parties include:

 The requestor
 All users of the MD object
 All other parties impacted by the change
These parties can be situated in- or outside the finance organisation.
2.2.12.4 MDM-005-120-040 Provide End User training

If required, users are trained to correctly consider and execute the change in their day to day activities.
19-Mar-18
Process Activity Description: Monitoring & Reporting
Monitoring and reporting of master data activities help to identify and resolve process deficiencies & data
quality issues, and are a key input for contiuous process improvement.
This section describes a set of generic reporting requirements. The priority and appropriateness of these
requirements must be evaluated for each master data object with the corresponding information
responsible. Specific reporting requirements per object will be covered in the specific MD BPDs.
This section also outlines the steps of the monitoring & reporting process.
2.3.1 MDM-006-140 Monitoring & Reporting
Reporting requirements can be classified into three different types:

 Master Data Process
 Master Data Delivery
 Master Data Quality
Data quality tolerances and thresholds have to be defined for key reports. Depending on the report a time
dimension can be required as well. (e.g. Master Data Requests between <start date> and <end date>)
The three requirement types are one by one elaborated below:
Master Data Process

Master data governance reporting must cover the end-to-end master data process flow. End-to-end
coverage allows for reporting with respect to providing the “right data” to the “right person” at the “right
time” in the “right format”. These reports will therefore help to identify issues such as data rendundancy &
business inefficiency.
Process reporting will be under responsibility of the Information Steward. Process improvements and
corrective actions can be launched in collaboration with the IKU.
Topic Priority
Number and overview of master data requests per object and per priority Should have
Master data maintenance workload per role Should have
Number and overview of standard / not-standard master data requests Should have
Number and overview of master data requests per implementation status (open, pending,
Must have
closed, …)
Number and overview of master data requests per approval status (approved, rejected, …) Must have
Number and overview of master data requests initiated per department/service/team Should have
Number and overview of master data changes requested per data object field Should have
Number and overview of mass master data changes requested per data object Should have
Number and overview of master data requests in a month that have been sent back to the
Should have
requestor for more information
Average and median throughput time of a master data request Must have
19-Mar-18
Master Data Delivery & Quality
These reports will help the Information & Data Stewards to identify issues like data redundancy & data
inconsistency, and will help in the execution of business change and error handling. The reports may also
want to be used for audit purposes.
Moreover, the End Users of the corresponding information object will use these reports to analyze the
consistency of the master data elements and/or to initiate mass changes.
Information will be extracted from SAP tables or delivered by standard or customized reports.
Topic Priority
Master data dimensions display : Master data objects and their possible
values/dimensions. A drill through functionality per element can give more information on Must have
the initial screen with all parameters and the history per element.
Changes to master data dimensions: Master data changes executed per data object field
Should have
(with the current status and history of changes)
Mass master data changes executed per data object Should have
Mapping table for each legacy system to SAP : Generate a report that visualizes the
Must have
mappings between the dimensions of the operational system and other legacy systems
Master Data group: displays per master data dimension the grouping of the elements. Should have
Missing values within mappings Must have
History of master data object changes (i.e. creations, modifications, blocked, deleted,…),
Must have
change date and person that made the changes (incl. previous and current values)
Check transactional data for Master Data dimensions : List of unused masterdata
objects. This will be determined per object and per time dimension (e.g. no bookings on Should have
G/L account since x years).
Overview of conflicting or missing interface logic (ref. functions) Must have
The list of AS-IS related MDM reports is available from: https://extranet-

sp.colruytgroup.com/projects/2013/doc360570/Template/Working%20Documents/All/Overview%20As-
Is%20reports.xlsx
Below diagram shows the high level generic Monitoring & Reporting process. The process is initiated by
an identified reporting need. Each of the process activities is discussed further down.
19-Mar-18
2.3.1.1 MDM-005-140-010 Analyse reporting needs
Dashboards and KPIs for monitoring the quality of the information are defined by the information steward
in collaboration with the information responsible. These dashboards and KPIs must per mit the information
responsible to manage the information objects under their responsibility.
Process step has been assigned to role: Information Steward
2.3.1.2 MDM-005-140-020 Create data quality reports

The information steward is supported by quality and risk reports relating to the information for which he /
she assumes a stewardship role. These reports are delivered by the data steward.
Process step has been assigned to role: Information & data Steward
2.3.1.3 MDM-005-140-030 Check data quality

Existing data must be explored to discover potential data quality issues. The Data steward provides
technical support for ensuring this data quality. The stewards assess the compliance of data
quality rules with their information business rules.
Process step has been assigned to role: Information & data Steward
2.3.1.4 MDM-005-140-040 Monitor process

The process is monitored to ensure that it is running correctly, based on the executed reporting and the
overview of requests in the respository. When necessary, corrective actions should be undertaken to
improve the process and to solve issues. The information steward initiates improvements that lead to
reliable information.
2.3.1.5 MDM-005-140-050 Reports KPIs & dashboards

Periodicaly, the agreed KPIs and dashboards must be reported to the information responsible and other
stakeholders.
Overview of Transactions
Where applicable transactions will be listed in the specific master data BPDs of the corresponding
streams.
19-Mar-18
3 Business Requirements
This chapter covers all MDM related business requirements. The requirements are categorized according
to 5 types of requirements:
 Process
 Data standards & quality
 Systems & tooling
 Metrics / reporting
 Mappings
The complete list of requirements can also be retrieved from the MDM Requirements Traceability
Matrix.
The impact of the Master Data Governance stream on the organization and functional integration towards
other teams are also discussed at the end of this chapter.
Process
Process requirements describe the methodologies that must be followed, and the constraints the
organization must obey to install the required Master Data Governance.
Req. ID Requirement description Requirement elaboration Priority

- we can benefit from existing rules, processes & roles
All financial MD requirements to within the organisation
MD-001- be in line with the CITTA - we ensure consistency of the information across the Must have
001 guidelines and other applicable group
Group policies - Group strategy and vision is implemented & rolled out
appropriately within Finance
A clear relationship between all Must have
- we can understand customer, supplier, legal entity,
MD used in the financial
MD-001- location,… in a complete and holistic manner
processes. CRUD (create,
002 - we ensure consistency and quality of the business
read, update, delete) processes
information
must be documented.
- we can have a clear information strategy for all objects Must have
MD-001- Ownership is assigned to all - we know who to contact in case of requirements
003 finance MD objects - finance representatives are accountable for MD
quality
All MD-related needs Must have
(creations, updates,…) to be - as much standardization as possible is enforced in the
registered and formalized in a request process
MD-001- dedicated request - business and quality rules can be pushed as early as
004 form/template. Where possible in the MDM process
necessary, documents - a central repository of all requests can be created
supporting the requests are - we ensure transparency, consistency, audit
attached/referred to.
All financial MD request - all financial MD requests contain all the necessary Must have
forms/templates to be information to be easily reviewed and subsequently
MD-001-
completely, correctly and created in the system
005
accurately filled in (in line with - MD quality is ensured
defined MD quality rules) - corrective requests and rework is minimized
All requests to be performed in Must have
MD-001- - so that manual effort can be minimized
a uniformed, effective and
006 - so that all requests are evaluated on the same basis
efficient way
19-Mar-18
Clear guidelines and rules to be - A clear analyse & impact assessment can be Must have
MD-001- made easily available and kept performed
007 up-to-date by the information - MD quality is continuously looked at and maintained
responsible as high as possible
- Alternative solutions in order to fulfil a given Must have
information or reporting need are assessed
that all financial MD requests
- A qualitative implementation in the system can be
are reviewed and analysed in a
MD-001- ensured
consistent way on
008 - Accuracy in the financial (internal or external)
completeness, accuracy &
reporting & processes are increased
relevancy of the request
- Consistency is ensured across the Colruyt Group and
its operating units.
- The impact of modications is appropriately assessed Must have
an appropriate impact prior to any update in the systems and that they are
MD-001-
assessment to be performed for managed in an efficient, effective and controlled way
009
all financial MD requests - Consistency is ensured across the Colruyt Group and
its operating units.
- all MD creations/updates are in line with the business Must have
Each request form is approved
MD-001- strategy of the information object owner
prior to processing in the
010 - only authorized personnel can trigger MD
system(s)
creations/updates
Processing (administration) of Must have
all approved requests can take
place in bulk, instead of having - errors and rework are minimized
MD-001-
to create/update the objects - all financial MD is available on time
011
one by one. - limited manual administration efforts are needed
- the financial MD is created and changed according to Must have

each financial MD creation or the structural requirements, including maintenance of
MD-001-
change must be executed by hierarchies
012
the authorized roles - only authorized and qualified personnel are authorized
to create/update MD in the system(s)
- the change registered in the systems is in line with the Must have
A four-eyes review check
MD-001- requirements
before the release of financial
013 - we ensure qualitative/accurate and trusted information
MD object
content
Role-based access rights are Must have
MD-001- appropriately granted to users - only authorized users take part in the governance and
014 across the governance and MDM process
MDM processes
A central repository is made Must have
available to store governance
and object-specific MDM
documentation (policies, - supporting documentation is easily and efficiently
MD-001- procedures, process accessible
015 descriptions, definitions, rules, - up-to-date documentation is constantly available
etc.). This is also easily - maintenance of MDM documentation is centralized
accessible to stakeholders.
Versioning is ensured in the
repository
MDM Governance processes Must have
are supported by a workflow to
ensure automated execution, - the MDM (governance) processes are efficient, well-
MD-001- according to pre-defined structured and uniform
016 sequence (request, review, - increased consistency and standardization is ensured
approve, implement, monitor) - manual rework is reduced
and process requirements (icl.
Access restrictions)
19-Mar-18
- More efficient MDM processes in line with SLE's Must have
The MDM process progress
- Process performance can be measured and
and compliance with
MD-001- improvement areas indented (or followed-up)
standards/service levels is
017 - Benchmarking can be done across information
monitored in a consistent and
domains and leverage across domains becomes
automated way
possible
Access to data and Must have
maintenance of master data in - Access to master data is controlled
MD-001-
source systems, target systems - Risk of incorrect or fraudulent use of MD is reduced as
018
and interfaces is restricted to much as possible
MDM roles
the "single source of truth" or Must have
"single version of truth" is
clearly defined and identified
MD-001- and a single view of master - Data inconsistencies and miss-interpretations are
019 data can be captured (i.e. all limited
relevant data from different
source systems are gathered in
a single view)
All financial data are classified Must have
and the definition of each
MD-001- - the scope of Financial MDM / Governance is
category is validated (i.e. what
020 transparent and clear to every stakeholder
is Master Data, what is
Reference Data, …)
A process is in place for data Must have
quality issue identification, - immediate resolution of data quality issue can be
MD-001- tracking & resolution. It is launched and acted upon depending on issue criticality
021 integrated with existing incident - the impact of data quality issue(s) is limited and
& problem management controlled
process.
Segregation of duties is Must have
ensured between:
- MD Requestor and approver; - Incorrect/Inaccurate/Fraudulent MD creations are
MD-001-
- MD approver and prevented
022
administrator; - MD is maintained in a controlled manner
- Information Steward and
Administrator
That emergency requests are Must have
treated accordingly. The - A controlled process is in place to manage emergency
MD-001- necessary activities on control requests and ensure qualitative MD;
023 and detailed analysis may be - Dependent processes are not impacted or blocked by
performed after implementation pending MD requests
/ execution of the changes.
Data standards & quality

Data standards and data quality requirements describe the expectations towards the condition of the
data. They represent characteristics about the data content needed to meet other business requirements.

MD-002- No customization in the MD - MD to-be will reuse the standard objects and fields in Must have
001 SAP FICO SAP as much as possible.
Business Rules and Data - The potential impact of incorrect/inaccurate data is Must have
Quality rules are documented prevented at the source
MD-002- on the field and entity level for - Reduced rework or manual corrections across
002 all financial master data. The financial processes
information responsible ensures - Increase rate of "first-time right"
19-Mar-18
that these rules are maintained
and kept up-to-date centrally.
a clear definition of all financial - it is clear what every information object refers to and Must have
master data is available and is how it is (supposed to be) used
validated by information - fosters a common understanding of business terms
MD-002-
responsible accountable. The Commented [VB19]: Owner?
003
way it is described in line with Adapted to responsible
the group requirements defined
by CiTTA.
For each financial master data - Clear and common understanding on information Must have
object, a validated (business) objects in scope can be reached across the Group;
definition is documented in a - Insight can be gained in where data is located and
business glossary. Besides, how it can be related to other objects
MD-002- information on the
004 implementation/location of this
MD object is available (e.g. in
which tables and fields from
which system(s) is the object
implemented?).
System & tooling

Must have
Validity dates as well as historical - Historical reporting is not impacted and can be
MD-004-
values are maintained for master reconstructed when necessary.
001
data
This is needed in order to be able to interface the data Must have

form SAP S/4 HANA to the surrounding systems.
Key and value mapping tables
'Example of key mapping: SAP Customer 123 is identified
MD-004- between SAP S/4 HANA and
in FINREL as ABC.
002 surrounding systems needs to be
Example of value mapping: Code 00 in SAP means
stored and maintained.
Customer Blocked, in FINREL code XX means Customer
blocked.
- it is clear which system is the master source Must have
- efficiency gains & time savings are realized (one single
All approved MD-related requests
MD-004- entry point)
to be centrally implemented in an
003 - Master Data is maintained at one single location, which
efficient and effective manner
supports the objective of having one single version/source
of the truth
An automatic synchronization Must have
- Efficiency gains & time savings are realized as only one
between master and slave
system is maintained (instead of as many system as the
Master Data is maintained
MD-004- number of sources within MD can be maintained);
centrally within a master source
004 - Consistency is reached across the landscape by having
system. Creations/Updates are
only one single version of the master record ("Golden
replicated (pushed) towards
Record");
slave-systems.
- the process can easily be monitored Must have
all requests & decisions to be
MD-004- - we create transparency
archived and properly
005 - we can fall back on a central repository and history of
documented
previous requests and leverage on previous instances
19-Mar-18
That it becomes possible to Must have
prepare and approve the entry or - Master Data creations/changes can be performed pro-
update of MD in the system in actively and carefully thought through prior to
MD-004-
advance and release it when implementation.
006
needed. MD is only available after - Recurrent actions can be prepared in bulk in order to
it has been released into ensure maximal consistency
production.
Every MD creation or change to - Traceability can be used to support audit purposes as Must have
MD-004-
be traceable (who, what, when, well as root cause analysis
007
where). - Changes can be reversed in an easier way
To have the possibility to reverse Must have
the changes done (individual or
MD-004-
mass changes) after the release - Easier data (quality) issue resolution
008
in production if the change is
proven to be wrong.
Automated validation checks Must have
should be performed on MD - The potential impact of incorrect/inaccurate data is
based on the business and quality prevented at the source
MD-004-
rules. These checks take place as - Reduced rework or manual corrections across financial
009
near as possible of the source (at processes
data entry) in order to ensure 'first - Increase rate of "first-time right"
time right'.
to have master data enriched by Must have
external data sources when
necessary/required in order to
MD-004- - Increased MD quality
enhance the value of MD held
010 - Increased reliance can be done on MD
internally (e.g. up-to-date
customer addresses, currency
exchange rates, etc.).
That the integrity of data flowing Must have
across system interfaces across
the to-be landscape are monitored
- Transparency across the data lineage / data integration
(volume, issues, throughput time,
MD-004- process (no black-box on what happens)
etc.).
011 - this is to minimize the support and maintenance
Data consistency/integrity
workload after go-live.
between the SAP S/4 HANA and
sending/receiving systems needs
to be monitored in Phase 1.
Creations or changes to MD are Must have
performed within the master
- The master system which is defined remains leading and
MD-004- system. There are no users
central for MD creations/updates
012 authorized to performed
- Consistency of MD is not jeopardized
updates/creations of MD in slave
systems.
Mass creations or changes can be Must have
performed in a controlled and
- Requests which follow a similar pattern to be applied on
efficient manner. The same
MD-004- a number of MD object instances are processed in one
(business & quality) rules,
013 time, leading to increased efficiency and reduced risk of
guidelines and procedures are
manual errors
applicable to these types of
changes.
- In order to enforce that the workflow is respected at any Must have
Workflow functionality should be
MD-004- time and In order to enforce the business rules.
integrated in the data-entry
014 - In order to make sure that the data is available in the
application.
system only after the approval and not before
19-Mar-18
It should be possible to view old Must have
MD-004- - This is useful for problem solving when one needs to
and new values performed in a
015 investigate root causes for specific problems.
specific Master Data request.
- This can be useful knowing that the mobile applications Nice to have
are becoming more and more used and the approver is
MD-004- It should be possible to approve
not necessarily at his/her desk.
016 through a mobile application.
- In particular integration iPad's already used by Chefs
and staff members /Afdelingschefs/DivisieManagers Commented [VB20]: and staff members
It needs to be decided whether to Must have -> ADAPTED
use a SAP single instance (SAP - This decision will have impact on the license of MDG
MD-004-
MDG on top of SAP S/4 HANA) or and also on the available functionality and performance of
017
a separate instance for SAP the tool.
MDG.
Metrics / Reporting
to report on consistency as well - cross-system integrity/consistency and exception Should
as timely alignment on cross reporting have
MD-005- platform master data in a - in order to reduce the after go-live support and
001 efficient manner maintenance, for Wave I the exception reporting needs
to be available for all incoming and outgoing interfaces
(i.e. FINREL, BPC, mainframe)
The MDM process performance - Performance and compliance of the MDM process Should
and compliance needs to be can be monitored, benchmarked and acted upon have
MD-005-
measured and monitored by - Continuous improvement of the MDM process can be
002
means of KPI's with a drill-down made tangible
possibility. - Corrective actions can be performed when necessary
Periodic data quality monitoring - Clear insights are obtained in data quality Must have
process needs to be in place - Results / Benefits of the MD
MD-005- and supported by the Governance/Management processes for data quality
003 appropriate reports and metrics. are quantified and highlighted
Results of these metrics are
clear and directly actionable.
data quality metrics and - Clear insights are obtained in data quality thanks to Must have
MD-005- thresholds/objectives are well-defined objectives
004 defined for every master object - this will be used to measure the data cleansing
activities and also to sign-off the result of the cleansing
Please refer to 2.3.1 for a more detailed overview of generic reporting requirements.
Mappings
All functional mapping table
MD- requests are appropriately
documented, reviewed and
006- approved by the business
Must have
001 (finance or business) before
execution
MD- Approved changes are tested
and validated before
006- application within production
Must have
002 environment
MD- Access to create, change, This refers to both database and UI.
block and/or delete data is
006- restricted to a limited number of
Must have
003 authorized employees.
19-Mar-18
All actions performed on the This refers to the need for logging all modifications,
mapping tables are logged and directly on the database or indirectly via a UI, and
MD- available for review in an automatically or manually. Logging is expected for all
006- exception report / log file. Log modifications. A proposal could be to create exception Must have
004 files are retained in line with reports only for manual changes directly on the
legal retention requirements for database.
Finance
Mapping table changes can
MD-006- Should
easily traced back to approved
005 have
/ validated requests
Allow for mass update or
upload of mapping table
records. Mass creations or
changes can be performed in a
MD-006-
controlled and efficient manner. Must have
006
The same (business & quality)
rules, guidelines and
procedures are applicable to
these types of changes.
Allow for simulation with This refers to the need to simulate the impact of
MD-006- proposed mapping table values changes to mappings. (e.g. impact on change in cost
Must have
007 center structure to reporting) The need will have to be
assessed per individual object.
Mapping data history (version)
is maintained to allow for
MD-006- analysis as well as like-for-like Should
008 reporting. This is expected to have
be in line with legal retention
requirements for Finance
Automatic interfaces are
MD-006-
monitored. Abends are Must have
009
resolved in a timely manner
Automatic validity check within It does not matter if the validity check is performed at
SAP for existence as well as creation/update of a table or when the values are
MD-006- correctness of reference data actually used as long as existence and correctness of
Must have
010 used within mappings (i.e. does data is ensured.
the entered value exist and is
this value valid)
Automatic check on duplicates
MD-006- upon registration or
Must have
011 modification of mapping
records
Synchronization of mapping
data over all environments is
MD-006-
maintained and ensured. Must have
012
Exceptions are identified and
tracked through to resolution
MD-006- Automatic check on missing
values in mapping tables Must have
013
19-Mar-18
Change impact
Change impact identified for this process is summarised in below table.
Solution &
Process
System
Overall
People
Rating
Rating
Rating
Rating
Master Data
Org &
Impacted Change Implications (from As Is
Governanc Key Benefits Risks
Stakeholder Group to To Be)
e Role
FIN Alle users * All MD needs must be requested * Logging of all requested * Initial time needed to request
Financiën by filling in a template; all changes changes will increase
(geïmpacteerde mw) templates must be completely, * Higher efficiency * Troughput time will increase
correctly and accurately filled in, (information is delivered at * Insufficient knowledge and/or
End-users based on the rules and guidelines. once) ownership by impacted group
finance & * A more proactive handling of Medium Medium Medium Medium * Reduced complexity for Commented [VB21]: & SPOCs
SPOCS information needs will be required end-users to request ADAPTED
in order to obtain the required master data changes
solution at the right time
FIN Kerngebruikers * Are charged with new roles and * Consistency will be * It’s highly important that they
(KG) corresponding responsibilities obtained between all understand and are 100%
* Detailled knowledge of process, requests supportive to all changes.
rules & guidelines will be required * Higher quality of requests * Insufficient knowledge and/or Commented [VB22]: Overall insight in SAP master data
(Financial) * Overall insight in functional SAP is obtained ownership by impacted group set-up
Information Masterdata set-up will be required Medium Medium High Low ADAPTED
key-users * They will have to support & guide
users to handle with the new rules,
process & guidelines.
BP&S C&S * Takes part in the analysis of the * BP&S impact will properly * All knowledge needed must be
Financiën (team) Master Data requests in case of be evaluated gathered
BP&S C&S an extended analysis: performs * All system impacts will be
Data
Financiën 2 (team) evaluation of the impact on Low Medium Low Low assessed
responsible
systems,etc. * BP&S will be informed on
* Responsible for the scheduling of time
the implementation
FIN Afdelingschefs * They will receive new * Accurate and trusted * When finance is no owner of an
FIN responsibilities and will have to information content will be object, the ownership( and
Procesverantwoorde take an active role in the new insured information responsible) will be
Information
lijken (PV) process. Low Low Medium Low * All changes are in line situated outside finance
responsible
* Staff members will be charged with the business strategy
with new responsibilities. of the information object
owner
19-Mar-18
Solution &
Process
System
Overall
People
Master Data
Rating
Rating
Rating
Rating
Org &
Impacted Change Implications (from As Is
Governanc Key Benefits Risks
Stakeholder Group to To Be)
e Role
FIN Adfin * Administratorship of MD objects * Repetitive work is * Assignement of right tasks to

BP&S C&S will be reconsiderd (tasks will be minimized and results in a right people
Financiën (team) rescheduled, etc.) lower workload.
Administrat BP&S C&S * The introduction of a new system * Errors & rework will be
High Medium Medium High
ors Financiën 2 (team) * Analyzed & validated requests minimized
with complete and correct data
* More objects under his/her

responsibility
Information
* More reporting & monitoring will Low Low Low Low
steward
be expected, but this can be done
with relatively less effort
* Corp Business * An increasing number of objects * Learning opportunity
* Need for more support, advice
Analytics & Insights and processes must be in line with
CITTA Low Low Low Low and clear communication (ex. :
(BA&I) - Citta / the group rules and governance
group descissions)
Cockpit
End-users Other operating * Synchronization of procedures * Accurate and trusted * Not all stakeholders are
& other units can be needed information content will be detected and sufficient informed
information BP&S chefs C&S * More strict processes and rules insured (or not sufficient monitored)
Low Medium Medium Low
stakeholder Finance will be applied
s outside * Proactive handling of information
finance needs
19-Mar-18
Functional Integration Topics Commented [VB23]: Zijn er nog topics?
Ik kan niet meteen aan iets denken , wel nog enkele
technische thema’s waar op vandaag geen document voor
3.7.1 Functional integration is (mappings, configuratie, etc.)
Below are listed the specific MD BPDs for the different streams. This document and those BPDs will be
aligned.
Leading Integrating
IP-Code Activity Name Integration Topic Description
stream stream
MDM-070 GL Masterdata R2R MDM
Create & Maintain
MDM-030 P2P MDM
P2P Master Data
Create & Maintain
MDM-010 Business Partner & O2C MDM
Contract Account
Manage managerial
DS-005 Controlling MDM
master data
xxxxx Investment order I2D MDM
xxxxx Asset accounting I2D MDM
19-Mar-18
4 SAP Functionality Gaps
Development Requirements (WRICEF) : TBD
No WRICEFs are identified for this BPD. Please refer to the specific MD BPD’s where WRICEF’s for
specific objects are listed.
Note however that the way of managing the master data management process and itsenablement by a
workflow management software is still under consideration.
4.1.1 Workflow
N/A
4.1.2 Reports
N/A
4.1.3 Interfaces
N/A
4.1.4 Conversion
N/A
4.1.5 Enhancements
N/A
4.1.6 Forms
N/A
5 Roles & Authorizations

Roles
The different roles involved in the Master Data Governance process are described below. For each role
the key responsibilities of the role throughout the process are mentioned along with the deliverables the
role will provide.
It is possible that several roles will be performed by the same person. The roles also have responsibilities
to ensure adequate data security, and compliance with regulatory requirements. These responsibilities
are not further detailed per individual role as part of this document.
The listed roles, responsibilities and deliverables are in line with the centrally defined roles by CITTA (“9-
vlak”). This does not mean that the descriptions are literally adopted from CITTA. It does, however, mean
that the roles and descriptions are as close as possible to those defined by CITTA, and that
modifications are agreed upon with CITTA. The two key differences between CITTA roles and Colibris
MDG roles are that:
 The information key-user role is subdivided into 3 separate roles: SPOC / IKU / FIKU. Commented [VB24]: Is dit niet als vertegenwoordiger EG?
 Hoe ik dit nu begrijp is dit de kerngebruiker (<->
 CITTA roles that are not relevant for the process have been omitted. Information key-user) , dit is de rol buiten het centraal team
dat de eindgebruiker ondersteunt. De IKU en FIKU zullen in
o Roles that do not have an active participation in the execution of the process, but are key het centraal team zitten
in the process (i.e. Process Owner & Information Owner) are nonetheless described.
5.1.1 Role 1 : Process Owner

 Summary :
o Overall responsible for the governance of process performance and process change
19-Mar-18
 Key Responsibilities:
o Takes ownership of the process and establish accountability
o Ensures that the process and goverance structures are fit for purpose
o Ensures appropriate process designs and correct business requirements
o Monitors and reports process performance against KPIs
 Participation in process :
o On a needed basis
5.1.2 Role 2 : Information owner 5

 Summary :
o The owner of and end accountable for the information
o (S)he ensures that the information under his responsibility is strategically aligned,
accurate and reliable for the group and its stakeholders
 Deliverables :
o Clear and precise definitions of business concepts under his/her area of responsibility
o Clear and precise policies and business rules concerning the structure and use of
information for which he/she is accountable
 Participation in process : On a needed basis
5.1.3 Role 3 : Information responsible

 Summary :
o The Information Owner’s delegate
 Key responsibilities :
o Provides input to the MDG team, validates and enforces tactical business and quality
requirements/rules/procedures in collaboration with the Key User
o Ensures that the policy framework is applied and the information is managed accordingly
o Responsible for the definition of terms and business rules
o Approves the request forms related to the maintenance of the information objects under
his/her responsibility
o Depending on certain criteria (e.g. the complexity , type and impact of the request,etc.)
the Inf. Responsible can assign the responsibility for approval to the IKU
5.1.4 Role 4 : Data responsible

 Summary :
o Reponsible for the data in his/her domain
o The data counterpart of the Information Responsible
 Deliverables :
o Implementation of the data strategy
o Clear and precise policies and rules as regards the structure and use of data for which
he/she is accountable
o Determination of the best data placement approach (which data elements in which
applications) with the data architect & how data is best exchanged
5
Data : description of a fact or an event without a relationship towards other variables or context
Information: data within a context, so that a meaning becomes clear
19-Mar-18
o Takes part in the analysis of the master data requests in case of an extended analysis:
performs evaluation of the impact on systems,etc.
o Responsible for the scheduling of the implementation
5.1.5 Role 5 : Financial information Key-user (FIKU)

 Summary :
o Has an overarching understanding of all objects and their alignment
 Key responsibilities:
o Safeguards the information landscape and monitors the consistency of all information
objects & processes.
o Suggests solutions to more complex requests to support the IKU
o Supports the IKU in the completion of activities concerning analysis and performing
impact assessment
5.1.6 Role 6 : Information Key-User (IKU)

 Summary :
o Safeguards the information object according to the strategy defined by the Information
Responsible for his or her object
o Coordinates and validates business needs and requests linked to his/her information
domain
o Ensures consistency of information usage across an information domain
o Assesses process impacts related to information changes
o Communicates decisions on reporting and analysis requirements to end users
o Supports the information responsible in the completion of activities concerning analysis
and performing impact assessment
5.1.7 Role 7 : SPOC

 Summary :
o The single points of contact
o Acting as the first line of control to safeguard the quality of information objects
o Identify, document and further improve rules and impact assessment activities
o Filter requests from Information End Users
o Complete and submit completed request forms related to (financial) information needs
o Filters requests and challenges the requestor on relevancy, emergency of the request,
etc. Performs 4-eyes-review & UAT (in collaboration with the End User )
5.1.8 Role 8: End User

 Summary :
o Formulates and transfers his/her information, reporting and analytical needs to the Key
User or SPOC
o All users of an information object within finance.
o Follows the business rules and policies and is up to date with related trainings
19-Mar-18
o Raises requests and/or incidents regarding information issues / new business information
requirements to the Information Key User
o Fills in the request template
5.1.9 Role 9: Administrator

 Summary :
o Inputs information into relevant systems
o Process approved request in the applicable systems and raises issues with regard to the
creation in the systems towards the IKU or Data Responsible.
o Respects and adheres to business information rules, standards and regulatory
requirements regarding information entry and updates
o Creates and updates information according to the received request forms
o Solves issues detected during the 4 eyes review or UAT
o Implements SAP configuration and enterprise model data in the system(s)
5.1.10 Role 10: Information steward

 Summary :
o Administrates, monitors and enforces information policies, standards and procedures with
regards to information structure and content
o Supports the process responsible, Information Responsible and Key User regarding
quality, monitoring and analysis of the information & process
o Ensures information decisions are communicated and all parties understand the impact
of the decision to their line of business/ domain
o Works with the business to define appropriate gathering, use and business rules, and
also to define an acceptable level of data quality for all information elements
o Initiates improvements to obtain reliable information
o Defines DQ Dashboards for monitoring the quality
o Manages DQ reports, KPI’s related to data quality and process monitoring
o Initiates improvements to obtain reliable information
5.1.11 Role 11: Data steward

 Summary :
o The custodian of data assets
o Technical counterpart of the Information Steward
o Responsible for information /data quality reports and enhanced/cleansed data.
o Provide technical support for ensuring data quality.
o Set-up the quality part of the data warehouse.
o Explore existing data to discover potential data quality issues
o Supports the information steward by delivering data quality reports
19-Mar-18
RACI Matrix Commented [VB25]: Nog te bekijken
Nu niets voor aanpassen?
A RACI matrix describes the participation by various roles in completing tasks for a business process
 Responsible:
o Those who do the work to achieve the task. There is at least one role with a participation
type of responsible, although others can be delegated to assist in the work required
 Accountable :
o The one ultimately answerable for the correct and thorough completion of the deliverable
or task, and the one who delegates the work to those responsible] In other words, an
accountable must sign off (approve) work that responsible provides. There must be only
one accountable specified for each task or deliverable
 Consulted :
o Those whose opinions are sought; and with whom there is two-way communication.
 Informed :
o Those who are kept up-to-date on progress, often only on completion of the task or
deliverable; and with whom there is just one-way communication.
The RACI matrix below includes all roles that are actively involved in the process. Other roles are
excluded of this overview.
Information
Responsible
Responsible
End User
Admin.
SPOC
Data
FIKU
IKU
Create master data request

Define business need and priority R/A
Fill in request form for creation/update of an account A R
Check relevancy, completeness and priority A R
Motivate and communicate rejection A R I
Perform preliminary impact assessment and determine impacted
A R
MD type
Finalise request form R/A
Submit request form I R/A I
Analyse master data request
Check correctness of request A R
Communicate rejection to SPOC and End User A R I I
Complete impact assessment A C C R
Perform detailed analysis of functional and organisational impact R/A C
Perform detailed analysis of system impact R/A I I
Create high level workload estimate R/A I I I
Define target implementation date A C C R I
Align target implementation date with End User A R C I
Finalise request form R/A
19-Mar-18
Information
Responsible
Responsible
End User
Admin.
SPOC
Data
FIKU
IKU
Determine need for project R/A
Prepare project form R/A
Provide recommendation to approver I C C R/A I I
Approve master data request
Review and approve change request R/A C C R/C
Communicate and document rejection A I I R I I
Submit project form to PFR R/A
Approve project form
Communicate rejection
Request project code R/A
Initiate required implementation flow(s) A C C R I
Prepare implementation
Initiate other processes A R I I
Collect additional information A R R
Analyse required system change R/A I
Created detailed workload estimate and planning I R/A I I
Create detailed project sheet R/A
Schedule release R/A
Inform about delivery date I R/A I I I I I
Implement configuration solution
Configure and test implementation A R
Update technical documentation A R
Update other systems A R
Prepare UAT session in test environment A R
Perform UAT
Request UAT testing A I I R
Execute UAT A R
Approve UAT report (sign-off) I A R I I
Rework configuration solution A I C R
Release according to release schedule
Release according to release schedule A I I I R
Implement master data solution
Execute change in master system A I I R
Update other systems A I I R
Perform 4-eyes review
19-Mar-18
Information
Responsible
Responsible
End User
Admin.
SPOC
Data
FIKU
IKU
Check implementation A R I
Rework master data change A C R
Mapping update
Update mappings assembly A C C R
Update mappings sustainable interface A C C R
??
?? A R
Provide end user training and documentation
Update documentation A R R R
Prepare project close and communicate to PFR R
Communicate to all stakeholders A I R I I
Provide End User training A I R I I
19-Mar-18
5.3. Authorizations : TBD
To be defined by authorization team. (in a later stage)
6 Annex
7 Abbreviations
Abbreviations Description
TIC Tactical information council: The tactical information council (Platform uniting the
FIKU, information responsibles & data steward) validates rules, take descions and
gives guidance
MD Masterdata
EM Enterprise model
SLE Service level engagement
IKU Information key-user
FIKU Finane Information Key-User
EU End User
8 Glossary
Abbreviations Description
Implementation The implementation date identified in a CR is the date by which all changes should
date be applied which are detailed in the business requirements, unless otherwise
specified. It is the date when all necessary updates to infrastructure, business
processes and/or supporting technology changes shall be completed and
operational in order to execute new/modified policy and procedure. Also used for
release date or go-live date.
Target Implementation date in the release calendar that should be targeted according to the
implementation business needs described in the Master Data requestmaster data request. This date
date is indicative and should be used for the scheduling of the Master Data
requestmaster data requests into a release.
Create By “creation” of an object, we encompass its registration in SAP along with its
reproduction in other systems.
Change By “change” of an object, we refer to any modification to its content, along with the
blocking of an object (=deletion).
Data description of a fact or an event without a relationship towards other variables or
context
Information data within a context, so that a meaning becomes clear
19-Mar-18
9 Objects in scope
Below table lists all objects in scope for Master Data by the name they will be known for in SAP.
Object Name Finance is Lead SAP Citta Data SAP Inf. Resp. (Role) Inf. Resp (Name)
owner? stream Master Type primary
Data Type module
Asset class Yes ITD EM EM FI-AA Process Responsible Fixed Assets Stefaan Van Cauwelaert
Bank key Yes Treasury MD MD FI-Banking Process Responsible Treasury Tom Mahieu
Business Partner No O2C MD MD General Process Responsible AP & AR Pieter Van Dyck
Cash management group Yes Treasury CON RD FI-TR Process Responsible Treasury Tom Mahieu
Cash position grouping Yes Treasury CON RD FI-TR Process Responsible Treasury Tom Mahieu
Chart of Account Yes R2R EM EM FI-General Process Responsible Group Accounting Hilde Sonck
Chart of depreciation Yes ITD EM EM FI-AA Process Responsible Fixed Assets Stefaan Van Cauwelaert
Company Yes R2R EM EM FI Process Responsible Group Accounting Hilde Sonck
Company code Yes R2R EM EM FI Process Responsible Group Accounting Hilde Sonck
Controlling area Yes Controlling EM EM CO Process Responsible Financial Controlling Stefaan Van Damme
Cost Center Yes Controlling MD MD CO-OM Process Responsible Financial Controlling Stefaan Van Damme
Cost Center Group Yes Controlling MD RD CO-OM Process Responsible Financial Controlling Stefaan Van Damme
Cost center standard Hierarchy Yes Controlling MD RD CO-OM Process Responsible Financial Controlling Stefaan Van Damme
Cost element group Yes Controlling MD MD CO Process Responsible Financial Controlling Stefaan Van Damme
Country No R2R EM EM General Process Responsible Group Accounting Hilde Sonck
Currency Yes R2R EM EM General Process Responsible Treasury Pieter Van Dyck
Depreciation area Yes ITD EM EM Process Responsible Fixed Assets Stefaan Van Cauwelaert
Distribution Cycle Yes Controlling MD Process Responsible Financial Controlling Stefaan Van Damme
Document types Yes R2R CON PD General Process Responsible Group Accounting Hilde Sonck
Evaluation Group Yes ITD CON RD FI-AA Process Responsible Fixed Assets Stefaan Van Cauwelaert
Exchange rate type Yes Treasury CON MD General Process Responsible Treasury Tom Mahieu
19-Mar-18
Data Type module
External Business Transaction Type Yes Treasury CON RD FI-TR Process Responsible Treasury Tom Mahieu
Fiscal year variant Yes R2R EM EM FI Process Responsible Group Accounting Hilde Sonck
Fixed Asset No ITD MD MD Fi-AA Process Responsible Fixed Assets Stefaan Van Cauwelaert
Functional area Yes Controlling EM EM FI-GL Process Responsible Financial Controlling Stefaan Van Damme
G/L account Yes R2R MD MD FI-GL Process Responsible Group Accounting Hilde Sonck
G/L Account Group Yes R2R CON RD FI-GL Process Responsible Group Accounting Hilde Sonck
House bank Yes Treasury MD MD FI-Banking Process Responsible Treasury Tom Mahieu
House bank account Yes Treasury MD MD FI-Banking Process Responsible Treasury Tom Mahieu
Interest Rate Type Yes Treasury MD MD FI-TR Process Responsible Treasury Tom Mahieu
Internal order Yes Controlling MD MD CO-OM Process Responsible Financial Controlling Stefaan Van Damme
Internal order group Yes Controlling MD MD Process Responsible Financial Controlling Stefaan Van Damme
Language No R2R EM EM General Process Responsible Group Accounting Hilde Sonck
Ledger Yes R2R EM EM FI-GL Process Responsible Group Accounting Hilde Sonck
Ledger group Yes R2R CON RD FI-GL Process Responsible Group Accounting Hilde Sonck
Number ranges Yes R2R CON RD FI Process Responsible Group Accounting Hilde Sonck
Payment method Yes P2P CON PD FI-AP Process Responsible AP & AR Pieter Van Dyck
Payment term No P2P CON RD General Process Responsible AP & AR Pieter Van Dyck
Payment Tolerance Group Yes O2C CON RD FI-AR Process Responsible AP & AR Pieter Van Dyck
Planning group Yes Treasury CON RD FI-TR Process Responsible Treasury Tom Mahieu
Planning level Yes Treasury CON RD Fi-TR Process Responsible Treasury Tom Mahieu
Posting period Yes R2R CON MD FI Process Responsible Group Accounting Hilde Sonck
Profit center Yes Controlling EM EM CO Process Responsible Financial Controlling Stefaan Van Damme
Profit Center Group Yes Controlling MD RD CO Process Responsible Financial Controlling Stefaan Van Damme
Profit Center standard Hierarchy Yes Controlling MD RD CO Process Responsible Financial Controlling Stefaan Van Damme
Segment Yes Conso EM EM FI Process Responsible Financial Controlling Stefaan Van Damme
19-Mar-18
Data Type module
Statistical key figure Yes Controlling MD RD CO-OM Process Responsible Financial Controlling Stefaan Van Damme
Trading partner Yes R2R CON PD FI Process Responsible Group Accounting Hilde Sonck
Transaction type (AA) Yes ITD CON RD FI-AA Process Responsible Fixed Assets Stefaan Van Cauwelaert
Transaction type (conso) Yes R2R CON RD FI Process Responsible Group Accounting Hilde Sonck
VAT code (formerly known as Tax Yes R2R CON MD FI Process Responsible Tax Bart Vander Elst
code)
Vendor Account Group No P2P CON RD FI-AP Process Responsible AP & AR Pieter Van Dyck
Withholding tax code Yes P2P CON MD FI Process Responsible Tax Bart Vander Elst
19-Mar-18

MDM To-Be Process Design v5

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MDM To-Be Process Design v5

Uploaded by

Copyright:

Available Formats

To-Be Process Design:

MDM-005 Generic MDM

Table of Contents Page i Document1

Document Review/Approval History

20/01/2016 Jelle Stuyver MDM Team Review initial draft

22/01/2016 Alberic Moens MDM Team Integration of comments

12/02/2016 Jelle Stuyver MDM Team Update

03/03/2016 Dennis Lemmens MDM Team Update

09/03/2016 Jelle Stuyver MDM Team Update

10/03/2016 Véronique Basteleus Process owner Review (prevalidation session 1)

10/03/2016 Koen De Pelsemaeker Integration Team Review (prevalidation session 1)

10/03/2016 Luc Timmerman Integration Team Review (prevalidation session 1)

11/03/2016 Véronique Basteleus, - Prevalidation session 1

03/05/2016 Jelle Stuyver MDM Team Update

12/05/2016 Luc Timmerman Integration Team Review (prevalidation session 2)

13/05/2016 Véronique Basteleus, - Prevalidation session 2

Distribution of Final Document

Table of Contents Page ii Document1

Reference to external files (SharePoint)

Table of Contents Page iii Document1

Table of Contents Page iv Document1

Table of Contents Page v Document1

Table of Contents Page vi Document1

Document Process Scope

Master data management (MDM) is an orchestration of roles, responsibilities, processes, policies /

1.2.2 Project Scope

A separate BPP will be created for Monitoring & Reporting

Figure 1 Colruyt Process MDM-010 Generic Flow

 MDM-005-010 Create Master Data request

This process can be triggerd in several ways:

2.2.1.1 MDM-005-010-010 Define business need & priority

2. Medium – standard Master Data request

Process step has been assigned to role: End User

2.2.1.2 MDM-005-010-020 Fill in Master Data request form

2.2.1.3 MDM-005-010-030 Check relevance, completeness and priority

2.2.1.4 MDM-005-010-040 Motivate and communicate rejection

 Systems & tools:

Process step has been assigned to role: SPOC

2.2.1.6 MDM-005-010-060 Finalize Master Data request form

2.2.1.7 MDM-005-010-070 Submit Master Data request form

2.2.2.1 MDM-005-020-010 Check correctness of request

An evaluation will be performed to identify:

2.2.2.2 MDM-005-020-020 Motivate and communicate rejection

2.2.2.3 MDM-005-020-030 Complete impact assessment

Process step has been assigned to role: IKU

Process step has been assigned to role: FIKU

2.2.2.5 MDM-005-020-060 Perform detailed analysis of system impact

Process step has been assigned to role: Data Responsible

2.2.2.6 MDM-005-020-070 Create high level workload estimate

Process step has been assigned to role: IKU

2.2.2.8 MDM-005-020-090 Align implementation date with End User

Process step has been assigned to role: IKU

2.2.2.9 MDM-005-020-100 Finalise request form

2.2.2.10 MDM-005-020-110 Determine need for project

Process step has been assigned to role: IKU

Process step has been assigned to role: Information Responsible

2.2.3.2 MDM-005-030-020 Communicate and document rejection

2.2.3.4 MDM-005-030-040 Approve project form

2.2.3.5 MDM-005-030-050 Communicate rejection

Process step has been assigned to role: Portfolioraad (PFR)

2.2.3.7 MDM-005-030-070 Initiate required implementation flow(s)

 SAP & Legacy Master Data

All 3 implementation flows can be triggered by one request.