"The first round of testing of your new system is complete and it passed with flying colors. You must be excited!" the consultant said proudly.
"Yes, we're pleased, but why isn't there a data-transformation-function*?" asks the customer. "We've always relied on that critical function to run our business."
[*arbitrary example… insert your missing requirement here.]
"That function wasn't mentioned during our blueprinting workshops, so it wasn't included within the requirements document. All the stakeholders agreed and signed-off on the documents before we began building the system, " defends the consultant.
"As the 'expert' shouldn't you have asked us if we needed it? Didn't you notice that we use it now?" the customer asked.
"We were following the project guidelines. That includes concentrating on a new future-state which leverages best practices and utilizes standards, as well as not dredging history regarding old ways of doing things. Because the standards do not include that function as an option and since we didn’t conduct a review of your previous system to discover it, the function was not included in the new system. "
"Standards and best practices are good starting points, but exceptions should be anticipated in order to support some of our competitive differentiators… that's why we hired you and why we didn't implement the new system ourselves. I understand that this is a joint process and you can't feasibly ask us every question possible during our workshops. Likewise, we can't be expected to remember every need and requirement ourselves… particularly ones we naturally take for granted.
So, how could this have been avoided? "
- - - - - - - -
Does this story sound familiar or at least resonate? This situation applies towards many types of system implementations. However, it particularly applies to Enterprise Performance Management (EPM) implementations which includes SAP Business Planning and Consolidation (BPC) and SAP Integrated Business Planning (IBP) systems where the SAP ASAP or SAP Activate methodology is employed.
Over the past ten years on multiple occasions I've been tasked to rescue 'at risk' SAP EPM implementations much after the blueprint or design was complete. While there are often multiple root causes contributing to the risky situations, one basic cause in particular was systemic across all of them: not conducting a proper current state analysis – the failure to adequately consider and understand the customers' existing system and how they are using it.
Blueprinting ERP Configurations vs. Designing EPM Custom Solutions
The SAP ASAP and SAP Activate methodologies were created primarily to guide Enterprise Resource Planning (ERP), ECC, S/4HANA implementations, in tactical and transactional areas such as production planning, purchasing, sales, distribution, inventory management, etc. An underlying assumption of these methodologies is that on an industry-by-industry basis, these systems should be relatively similar to each other and can adopt a standard – recreating the wheel at each customer is not necessary. As such, a 'best practices' approach is pursued, where a default system is used as a base, certain choices are agreed upon with the customer during a blueprinting, then the system is configured by populating templates, selecting various options and activating settings to fit the customer's needs. Since the major difference between individual customers should mostly be their data and master data, those are the only real areas where a current state analysis is performed – the 'how' or 'why' regarding the current system is mostly disregarded in favor of the standardized solution's processes.
EPM systems cover strategic and analytical areas that differ from ERP, such as strategic planning, annual budgeting, quarterly forecasts, analysis, reporting and consolidations. While two competing companies in the same industry perform their ERP functions similarly, the ways they analyze their performance and plan for the future vary significantly and change over time more frequently than in an ERP system. Correspondingly, the EPM systems are typically very flexible with many tools, utilities and simplified scripting functions, that often do not require programming, to satisfy these different needs by allowing for the creation of a custom solution. SAP does make available default standard 'business content' and Rapid Deployment Solutions (RDS) for EPM, however, in practice they are more typically used as sales demonstrations, learning examples, prototyping aids and for baseline testing. They are rarely used as a base from which to build, because making modifications usually takes more time than building from scratch given the wide variances between customers. Since those differences lie in the 'how' and 'why' customers conduct their strategic and analytical activities, the consultants' best opportunity to understand that is through a current state analysis which in turn informs the design. As such, this is one of the more important exceptions to the SAP implementation methodologies that must be made for EPM.
Benefits of the Current State Analysis
Reviewing the current system and/or methods being replaced ensures the consulting team adequately understands how it is used, or not used. This analysis helps define what does/does not work for the customer and explains the pros/cons and likes/dislikes about the existing system to ensure prior benefits are carried forward and limitations are avoided. More importantly, it establishes a baseline of understanding and communication between the consulting team and the customer. When new ideas and approaches are discussed, both parties share the same frame of reference. When users require the new system to be as fast as the current one, but easier to use, their request will be better understood and the consultants’ follow-up questions will be more insightful.
These benefits cross both functional and technical lines. Some consultants lead with their business, industry and functional experience. They can leverage what they learn from why and how the current system operates, to recommend designs that will improve business outcomes and streamline the everyday decision making process. Other consultants with a more technical approach are able to leverage their current state understanding to improve system efficiency and reduce manual steps. Consultants with both functional and technical experience are able to push both the functional and technical envelopes even further in designing a solution that is guided by business benefits while still being technically feasible. In all cases, having this common starting point perspective allows the consulting team to better anticipate needs, make better recommendations, ask more relevant and pertinent questions, and conduct more productive and smoother workshops, which ultimately will result in a better design with fewer errors and omissions.
Breaking against the SAP methodologies has its detractors. Some believe that while learning the current system, the consulting team will become indoctrinated into the old ways of doing things and will not be able to think outside the box or consider a better process. However, to a consulting team with a few engagements under their belt, the current system will be considered just one of the many they've already experienced. Others cite time and costs. Why pay consultants to analyze a system which the customer is already familiar and will be going away? Based upon the above benefits, it is hard to argue you can afford not to. In addition, the time and costs can be mitigated when there is useful preexisting system documentation available to give the consultants a jump start – as long as it is not relied upon exclusively. Most detractors come from the ERP perspective, but once they understand the differences of EPM, they are typically swayed.
As described, there are many differences between ERP and EPM systems, the problems they solve and the solutions they provide. The methodologies that guide how they are implemented must adequately reflect these differences. Including a full current state analysis that addresses the 'how' and 'why' in EPM implementations is the first accommodation to the SAP methodologies necessary in order to implement EPM systems correctly the first time.
Please share your comments below... rate this post and share with others to spread the understanding.
