We are delighted to showcase the views of Moiz Madraswala, international SAP Data Governance & Transformation expert in our latest SAP blog. Moiz writes about the key considerations, success factors and processes required to deliver a best in class SAP MDG solution:
Deconstructing MDG…The Art of SAP Data Governance
By Moiz Madraswala
It is well known that high quality data, often hailed as “the new oil”, (if, drilled and refined properly), is a powerful asset and disruptor, capable of reversing the fortunes of even the most shipwrecked companies. Inversely however, bad data is just as capable of sending executive management to prison as well as expose organisations to millions of Euro’s worth of fines in regulatory breaches! However, fear not. As organisations look to fortify their “Data Governance Defences” SAP’s MDG offering offers definite value and a solution that has finally matured into a robust option. But, as we all know too well, it’s not just about how the solution offers a quick fix, but rather, how well you “wield the governance sword” for considerably greater ROI. However, doing that requires a certain level of governance and business process knowledge.
As we enter 2020, an increasing number of organisations running on SAP will finally embark on the transition toward S/4HANA. While it is true to say that general HANA adoption has been slower than many would have liked, this cautionary approach has, in fact yielded several benefits. The time taken by SME’s to the larger Multinationals to actually (i) assess the need for HANA and (ii) their level organisational readiness for the switch has resulted in a more clinical assessment, in many cases taking years. We all know, the shift to HANA, an in memory database can have a profound effect on the speed of data access & processing, however, less attention is often given to the implication on business processes, on which SAP pride themselves as being “best-in-class” and in particular DATA GOVERNANCE! Being forced to assess the impact on these two pillars of business architecture has really thrown a spotlight on each discipline. The integration or relationship between them has never been more profound. Governing, protecting and controlling this relationship and keeping data consistent is, however, where the real value lies.
The Need for An Integrated “Holistic” Approach
The above should serve as a pretext for this article, which I hope will serve to benefit everyone from the CEO, their VPs’ through to line management, business process & data analysts and finally power users, data owners, and stewards. Whilst the strapline and subject are obvious, I would ask the target audience to take a few steps back as we aim to take a holistic or end-to-end approach when dealing with the topic of master data and enterprise data governance in general. A critical point one must make at the outset is that automated data governance solutions, such as SAP’s MDG offering should be part of a wider “Data Governance Roadmap” based on a clear framework. Solutions should be driven by enterprise strategy, governance policy, and procedure, not the other way around, in the hope that implementing a best-in-class solution will somehow all eliminate risk, ensure compliance and keep data clean.
SAP or enterprise-level data takes on many forms, however, for the purposes of the topic, we will be dealing primarily with (i) Master Data and (ii) the Transactional data that it serves to house. Furthermore, we will be using the domain of Corporate Finance to exemplify the approach in question.
It must be stated that data management is no longer ONLY dominated by the theme of control and quality, as it relates to BI, analytics and reporting accuracy. As the opening sentences indicate, the introduction of GDPR, and/or other regional or industry legislation has now given birth to a completely new theme, which is the legal or external regulatory dimension. From a risk management perspective, financial data needs to be accurate for a host of reasons, i.e. ensuring published quarterly data is correct and submitted on time to the relevant stock exchange/authorities. The implications of failing to meet that “post-to-close” deadline cannot be overstated as well as the accountability for CFO’s. But throw GDPR into the mix and suddenly, the Legal VP and CIO or CDO are now accountable to ensure data, or records, to use a more legal term are being adequately protected via sound retention policies and /or procedures. The takeaway, to reiterate is that automated data governance solutions such as SAP’s MDG offering should be part of a wider “Integrated Data Governance Roadmap” based on a clear strategy and framework. In addition, where possible the business process architecture must be considered to ensure any master data changes, also trigger a change in the subsequent and/or dependant objects with communication channels to all affected parties.
MDG Success Factors
Now drilling down into MDG (Master Data Governance), there must be clear distinction between the (i) the discipline of “Master Data Management and Data Governance”, which is essentially system agnostic, and (ii) an enterprise-level solution, such as SAP’s MDG. Many transformation roadmaps when drafted, are typically littered with a large bucket list of solutions that must or should be implemented, for example, SAP HCM to Cloud-based Success Factors, or SAP ECC based FI/CO to S/4HANA Finance with FIORI UI & Mobility etc. Historically MDG was given little or no importance, however, the importance of data and its potential is now on the forefront of most CIO minds, and as a result MDG is establishing its presence on many future roadmaps. The argument usually put forward by external or internal stakeholders is one of (i) master data quality, which by default improves business processes and transactional data, and (ii) the mitigation of high-level risks, for the reasons listed above. However, it is critical to again take a step back and understand how, why and who is best suited to govern this data. Forget systems, reports, UI, and speed of workflows. If you don’t know who should be governing your data, you have serious problems. This an issue of accountability, SoD (segregation of duties), data object and business processes ownership. Why business processes? Because the link between your master data and business processes is inseparable.
“By a country mile, Master Data is the most important type of ERP data in terms of its ability to impact or break end-to-end business processes. But if this maxim holds true, why do so many organisations fail to prioritise governing master data?”
Indeed, the business case for strong data governance is generally accepted and is a maturing science. However, the business case for a licensed solution to govern master data must be subject to a few factors, namely (i) the size and scale of your user base, (ii) the efficiency at which your authorizations/roles are managed and cleansed, (iii) the level of maturity (data management) your organization is at (1-5 being a standard scale) and (iv) the integration methods/tools of your future solution landscape. Other factors no doubt play a part, but we will focus on these and then breakdown a simple and effective implementation approach.
If MDG has been selected based on criteria such as the above, the first task is to understand and map the master data and business processes within the given domain. In the following example, the SAP MDG Finance Data Model will be explored but before moving further, we must deconstruct the FI/CO and ECCS/Consolidation Modules. By this we refer to the master data objects that belong to each module; (i) FI or Financial Accounting (also known as Legal/external), including; Chart of Accounts, GL Accounts, Primary Cost Elements, and their respective groups and Hierarchies, (ii) in CO or Controlling (also known as management/internal) including; Cost Centres, Profit Centres, Secondary Cost Elements and their respective groups and hierarchies. Finally, (iii) ECCS and more recently BPC to manage your Consolidation Processes (Consolidation Units, group, FSI’s and hierarchies).
Most of the objects above, under each module, have been listed and these are what we will touch upon on in MDG, but we need to bear in mind that there is very often a direct and indirect relationship between these modules. This is understood but sometimes overlooked considering that often, different teams manage the three modules with a degree of autonomy despite all belonging to a Global or Corporate Finance Function. Why is this a problem, because real governance and data management requires an end-to-end perspective of how data flows and what are “data equivalents” in SAP. Meaning, if you update a Cost Element or Cost Center in one hierarchy, does that mean another equivalent object must be updated to maintain “synchronization” across another Finance module or hierarchy? Furthermore, are the relevant teams who must be informed of a change request (CR type) actually informed, if so when and how?
“The importance of governing your hierarchies cannot be overstated enough. Fail here and your most critical reports will start to degrade and quickly!”
Once an end to end view has been adopted, the subsequent workshops will allow a more integrated approach which again is critical. Of course, not all projects will take this approach due to the additional time and effort that is required to “fully align” all finance streams and the potential resistance but the effort will reap immediate dividends, primarily in the form of (i) synchronised master data across all sub-modules (ii) reduced/no interruption to business processes & (ii) stable hierarchies and therefore accurate data sets used for BI reports. It need not be a re-org of corporate finance, especially if data owners and stewards have been established. That said, an MDG implementation provides a fantastic opportunity to review and re-orchestrate the desired approval workflow, based on what each team can create, change, extend and or delete based on the CRUD process and data flow logic. Again, the stress is on maintaining equivalent objects and hierarchies. It is imperative that senior management understand and support this as a key design principle.
“It is a project failure to simply copy and paste the exact approval workflows from your SAP or non SAP systems into MDG if they do not align to how the data should travel and ultimately be reflected within a set of hierarchies or chart of accounts.”
The core project tasks are then to decide on who within the financial accounting/controlling, management accounting and Consolidation teams will act as the (i) requestors for any given change request within MDG and the (ii) Approvers. As already stated, an MDG implementation provides a fantastic opportunity to review and re-orchestrate the desired approval workflow. The rule-based workflows in MDG are very useful at creating intelligent workflows, that depending on who and what object is being maintained, a specific set of additional or parallel workflows and/or approvals will then be triggered. All of this must be captured within the “Role Matrix”, which is arguably the most critical project design deliverable.
The importance of Organisational Change Management (OCM) cannot be emphasized enough when embarking on any type of governance project, regardless of the solution. The initiative must be supported by senior management. Not just in terms of the typical ASAP or Activate OCM activities, but more so the harder decisions and potential re-wiring of change request workflows. The Internal Controls team should also be aligned where possible to ensure there are no SoD conflicts in the current or future state. A strong understanding of the Finance Data Flow and its main processes must be the leading authority on the final design decisions as only this bottom up knowledge will be able to convince process owners and data stewards of why changes may be required for greater returns not just in terms of object, hierarchy & reporting accuracy (reports), but also instilling an accepted governance framework for all future transformation endeavours.
“Leadership teams must be fully aligned to guiding governance design principles, and ensure resistance is navigated with a consistent message that delivers robust business and technical justifications, as to why changes may need to be made”
The last business-relevant item to mention is, of course, building rules in MDG. Depending on whether you have existing rules, perhaps existing within SAP Information Steward, you will need to replicate them in MDG or create from scratch. Again, business field logic should dictate what is required for your initial iteration. Most rules can easily be replicated within MDG, such as the most simple, (optional/mandatory) fields, to derivation or validation logic, limited suggestions, duplication check logic, and automatic notifications, generated upon the trigger or final approval of a change request or CR (change request) Type in MDG. There are a number of ways to build rules such as via BRF+ (Business Rule Framework) but bear in mind that it is not a requirement to build or add dozens of rules, given the process of “building business rules” is a continuous journey. Do not let it delay the build and go-live. There will always be time to add or even remove or enhance existing. Data object and process owners must work to co-author any rules to ensure, (i) a business and (ii) technical justification. What are the data quality dimensions most in need of addressing, e.g. completeness, accuracy, timeliness, etc? What finance processes are deemed weakest in terms of data accuracy, integration and reporting (Record to Report, Acquire to Retire, Plan to inventory, Period Closing, etc). Where and how do master data changes typically cause pain points?
Whilst this article is not intended to act as a technical guide, an attempt to summarize the most important management and solution architecture decisions has been provided. We have referenced the MDG Finance Data Model, however, MDG can replicate data into multiple SAP systems, both on-premise or cloud, from Ariba, PLM, SLM, SRM, CRM, and Hybris, deploying several different integration options. Critical here is whether the MDG system will act as the lead system, i.e. the CR (change request) being triggered from MDG first and then communicating with the relevant intermediary and before replication of the master data in the target system.
Once you have decided whether MDG or a secondary system such as Ariba, will act as the lead system, the subsequent integration and communication methods must be selected. The standard methods come into play here, SAP Process Orchestration (PO), web services (SOA based) etc. It is worth mentioning that the standard API’s for MDG are also very powerful when used. What method is used should be a decision for the technical and solution architects as well as your integration, ABAP and BASIS teams. Don’t necessarily use the most convenient and cost-effective method. Again, your future state, and its integration should be understood, and a decision taken looking at multiple systems that will need to be communicated with.
Other Critical Approach Considerations
At the heart of the approach is whether to adopt a (i) Hub or (ii) Co-deployment set up. There are pros and cons of each but the drivers in simple terms should be whether master data is being replicated to a central target system, or multiple target systems within a landscape and how much future integration flexibility is required. A few other factors also play a part but, SAP and your SI will be able to assess the best fit according to your technical and solution landscape and of course, your desired update and migration strategy of which there are several options. Cleansing will also require a strategy and decision, however meaningful cleansing prior to the migration/data loads into MDG is not to be underestimated. Cleansing itself can result in a project and delays depending on the extent of cleansing requirements, for which objects and their volume.
Another early important decision to make is which flavour of MDG to select. MDG for HANA Vs MDG for ECC. One must note here that MDG on HANA comes with superior reports and analytics as well as FIORI Mobility functionality as standard. A key selling point for MDG is the ability for data owners and stewards to check and or approve master data requests on the fly. This will be dependent on how mature your enterprise mobility capabilities are and the adoption of FIORI to date but should be considered. Governance is often seen as a bottleneck, especially at times of financial closing when the ability to create or modify objects is business critical. Mobility offers an almost immediate response time and therefore a solution to the objection of longer workflows
In conclusion, Enterprise data management, it’s governance component and other constituent parts all represent critical pillars. Whether you start from a system based perspective, or purely from governance /regularity dimension, thought must also be given to the wider EIM (Enterprise Information Management) picture as well as references to global data management bodies such as DAMA & DMBOK and data standards such as ISO 8000.
Implementing a solution should not be the end goal, rather the goal should be to ensure an embedded framework based on a long term vision is in place for managing, governing, defining and enriching master data across the organisation, in an integrated and synchronised manner. This represents the real barometer for “Organisational Data Maturity”.