Value of the Current State Analysis
The consultant bounds into the room and proudly announces to the customer, “The first round of testing of your new planning system just passed with flying colors. What do you think?”
“Great news! I like where things are headed. When will you be adding the special calculations our analysts rely upon* ?” asks the customer.
[* arbitrary example… insert your missing requirement here.]
After thumbing through the design specifications, the consultant replies, “It appears those calculations aren’t listed as a requirement in the sign-off document… and I don’t recall them from our workshops either.”
“As the ‘expert’ shouldn’t you have asked us if we needed them? Didn’t you notice that we rely upon them now?” the customer asked.
“Well, we agreed from the start that we were going to utilized standards and best practices to arrive at a better future-looking solution, instead of dwelling on how things were done in the past. The standards don’t include those calculations,” defended the consultant.
“Standards and best practices are good starting points, but you should have anticipated some exceptions because we’re not just like our competition. That’s why we hired you, versus trying to do this in-house. Now, I understand that this is a joint process and you can’t possibly cover every detailed scenario during our workshops. Likewise, we can’t be expected to remember every little function that is important to us… particularly the everyday 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/Corporate Performance Management (EPM or CPM) implementations, such as SAP Business Planning and Consolidation (SAP BPC), Anaplan, Adaptive Insights, Host Analytics, OneStream, Jedox, Board International, Vena, Oracle Hyperion, IBM Cognos TM1, and others, particularly when they integrate with an Enterprise Resource Planning (ERP) system, such as SAP ECC, SAP S/4 HANA, Microsoft Dynamics Great Plains, Infor, NetSuite, Oracle, JD Edwards, PeopleSoft, and others.
For well over the past ten years, I’ve been asked to rescue ‘at-risk’ EPM/CPM implementations while they were well underway. Although there are often multiple root causes, one was systemic: not conducting a proper current state analysis – the failure to adequately consider and understand the customers’ existing system, and how and why it is being used.
Blueprinting Configurations vs. Designing Customizations
Blueprinting Configurations
ERP and packaged implementation methodologies (such as SAP ASAP and SAP Activate) were created primarily to guide the configuration of those types of tactical and transactional systems such as production planning, purchasing, distribution, inventory management, etc. An underlying assumption of these implementation 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 and the customer chooses among different configuration functions during the blueprint creation. The system is then configured by populating templates, selecting various options, and activating settings to fit the customer’s needs. Since the major difference between individual customers for ERP implementations should mostly be their data (including master data and metadata), only those areas receive a current state analysis – the ‘how’ or ‘why’ regarding the current system is mostly disregarded in favor of using the standardized solution’s processes.
Designing Customizations
Conversely, EPM/CPM systems cover strategic and analytical areas that differ from ERP and packaged systems. EPM/CPM systems cover 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 much more frequently than in an ERP system. As such, the EPM/CPM platforms require more flexibility and variability from any standard. EPM/CPM software is intended to be customized, grown and evolved over time. Instead of creating a configuration blueprint of options, EPM/CPM solutions need to have their customizations designed to support the unique customer needs.
While predesigned templates can give customers ideas and suggestions, they aren’t necessarily a complete end solution (See PART 2). It is still vital to understand ‘how’ and ‘why’ customers conduct their strategic and analytical activities, so all their needs can be defined. At the very least, a predesigned solution will need some level of adjustment that is best supported through a current state analysis. So, while ERP systems can start with a base from which to configure, EPM/CPM systems undergo significantly more variations from a starting point or standard.
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. As a result, it helps 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’ suggestions for improvements will be more insightful.
These benefits cross both functional business and technical lines. Business leaning consultants can leverage their prior experience and understanding of how the current system operates to support design recommendations that would improve business outcomes while also streamlining everyday decision-making processes. Technical leaning consultants can leverage their current state understanding to improve system efficiency and reduce manual steps. When these consultants work together, or if a single consultant has both functional business and technical experience, they are able to create a more elegant solution; one which provides the greatest business benefit with the simplest feasible technical structure possible. In all cases, having this common baseline 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.
Why Argue Against a Current State Analysis?
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 better alternatives. However, to a consulting team with enough experience, the current system will be considered just one of the many to which they’ve already been exposed.
Many customers are fascinated by the sales demos, thinking that the new system is so far ahead of what they are doing now, that their old ways are not relevant. While there may be some truth to that, the designers of the preconfigured solution don’t know the customers’ business as well as the customers themselves, so the solution is not complete out of the box.
Others cite time and costs. Why pay consultants to analyze a system with which the customer is already familiar and one that will ultimately be going away? Based on some of the benefits and costs previously discussed, particularly missing requirements, it is hard to argue one can afford not. However, the cost of the current state analysis can be reduced by providing process and system documentation to the consultants in advance to jump start the analysis.
Many detractors come from the ERP perspective, but once they understand the differences to EPM/CPM, they are typically swayed in favor of performing a current state analysis on the people, processes and technology.
Conclusion
Implementing EPM/CPM systems differs from implementing other systems, such as ERP, because they provide a different solution for a different type of challenge. As such, the implementation methodology for EPM/CPM must reflect the strategic versus tactical nature of analytic versus transactional systems by including a current state analysis. Understanding ‘how’ and ‘why’ behind a customer’s needs and incorporating them into the design is the first step to implementing EPM/CPM systems correctly the first time.
Glenn Chamuel is a EPM/CPM engagement director and system architect with over 20 years of business/finance transformation, accounting, technology implementation, and EPM/CPM experience.