The Folly of a One-Size-Fits-All Change Management Process
One of the side effects of the cost and complexity of an SAP implementation is the proliferation of Change Management (CM) tools and processes available today. Financial regulations, internal policies and sheer common sense require that a vigorous and detailed CM process be put into place to govern changes to an SAP implementation. Coupled with SOx (Sarbanes-Oxley) requirements, CM processes – especially around ECC-side financials – are detailed, rigid and designed to protect the system from changes that can disrupt or even halt day-to-day processes.
As such, CM is necessary…vital even. However, one size does not always fit all, be it shoes or CM. This is especially true with Business Intelligence (BI).
Most companies that I have worked with have some form of a team to work with the CM process they have. This team is generally very well versed in how to align proposed changes to a transaction system, and also in working with those functional or even technical resources responsible for executing those changes. While there is sometimes friction, this tends to work.
With BI, however, this leads to serious issues, especially with companies that have only one ECC-centric CM team.
A CM process designed to protect and govern a transactional system of record is usually inadequate for a BI system. A BI system is inherently much more agile and flexible than a transactional system. Indeed, agility is often where the value of a BI system lies. This flexibility will also put BI squarely at odds with most traditional CM processes.
The issue exists on several fronts. For starters, few people in internal audit positions are as familiar with BI as they are with ECC. They therefore see BI as an extension of ECC – almost as a module like SD or FI – when in fact it is something completely different. On another side, few BI developers are familiar with CM systems, or the need for them in a BI space at all. Finally, most third-party tools are designed around ECC, with BI put in as an afterthought, if at all.
These issues can lead to massive problems with BI. For one example, some companies perfunctorily restrict access to higher systems (Q or Prd) to developers, with the theory that an ABAPer (the ‘developer’ of the ECC space) would have no need for access to those systems on anything other than an ad-hoc basis (i.e. ‘Firefighter’). With BI, that is COMPLETELY wrong. If the changes being moved include any infoproviders, the developer in question usually has to load those providers in other systems for testing or even cutover. Most CM systems address this need with ad-hoc or one-off processes, which end up becoming standards for BI and causing audit headaches down the road.
Worse still, most CM processes have steps that in no way relate to BI. How, for example, in BI does one complete a step in a CM process that demands T-Code references, and checks the system to make sure those T-Codes exist? One doesn’t, because reporting and analytics doesn’t use T-Codes. So the solution is often to force a CM system to ignore that requirement in certain cases, which obviates the need for the CM process in the first place.
Change Management is as vital to BI as it is to ECC, but it is a fundamentally different version of CM that is needed, one that is designed philosophically and technically to what BI fundamentally is. Don’t force a round peg into a square hole, and don’t kill your BI program with a CM process designed around ECC. Aim for agility.
Contact GROM to discuss our Business Performance and Analytics Maturity Model and Assessment and to understand how we can help you with all of your Analytics, Business Intelligence and reporting strategies.
About the Author – David Knudson, Director of Analytics/Analytics Architect
David is a twenty-two year IT professional with over 17 years of experience as an expert in all aspects of technical development and reporting from large corporate ERP systems. His special emphasis throughout his career has been to help customers turn data into information, and to understand the actual business behind “Business Requirements” to help business users articulate and structure their own reporting needs. Dave can be reached at email@example.com.