Thoughts on the perceived value gap with moving to your "next gen" ERP

I was recently in a meeting with a partner - Accenture - and we were discussing the challenges customers face in moving to this next generation of ERP (i.e. SAP S/4 HANA). More specifically, the challenges of overall strategy, approach and justification. Some are "lucky" enough to have some form of catalyst - be it an acquisition or a burning platform - that helps drive the process. Most, however, do not. They have done a solid enough job to have a stable ERP environment and are now faced with a question - "if it ain't broke, why fix it."

However, that adage does not account for the fact that prior ERPs - whether they are SAP ECC or other - are actually decaying in some sense. Yes, they do the job - but doing nothing creates other problems. First and foremost, there is a definitive shelf life to these ERPs in terms of supportability. SAP ECC goes off of mainstream maintenance in 2027. While there may be options beyond that date, it is really just a not-so-positive walk down a path with ever increasing costs and decreasing options. Secondly, the technology is older...and we all know how great technology ages. I won't go on a rant about digital core, in-memory or cloud - but suffice it to say that an old core (ERP) sub-optimizes everything around it. As time goes by, organizations are going to spend ever increasing dollars to maintain, fix or develop work-arounds - which is no-value-add.

So, the question is more of a dilemma - "I will have to change...but I am not sure I really want change." It feels to me like a furnace or roof replacement decision. The contractor can prattle on about energy efficiency but that does not really come close to making me feel good about writing the check. Hmm, maybe the furnace replacement analogy is better if we include - replacing all of your ductwork, taking over a year, eating up all of your budget, wreaking havoc over your entire house, and making your family miserable. That seems to be consistent with most organizations feelings about ERP implementations. This brings us the real root of the issue - the perceived a gap (chasm) between the expected cost/pain and the resulting value/benefit.

To make matters more complicated, I see two dynamics playing out pretty consistently.

• Organizations are not aligned on their need to change
• Organizations do not fully understand the cost to change

I will take a few minutes to dive into each of these independently. Obviously, the combination of the two (or the intersection of the two) determines if there is a value gap and how large it might be. We have created a simple "Perception Model" to illustrate this gap or perceived gap

We can use this model to also illustrate how organizations might move curves or change their place on the curves to eliminate or avoid the value gap altogether.

Organizations are not aligned on their need to change

It is appropriate to start with an acknowledgement of the many ERP project sins of the past. In particular, the scores of business cases written (some by yours truly) in support of major business change to be driven by ERP implementations. Major change in line with major value to support major projects. The results of these projects rarely if ever delivered on their huge promises. The results have been very sobering for leaders. Subsequently, current ERP projects and their business cases are looked at with a HIGH degree of skepticism.

Discernment is good - disbelief is bad. The intersting dynamic is that I cannot remember the last earnings call or investor report that did not have the word "transformation" in it. So, lots of talk about change but a not uncommon disconnect between the boardroom's desire for change and rest of the organization's belief in the need for change.

So, it is probably a good idea to hit this disconnect head on. Let us start at ground zero - the fundamental axiom that there is no value without change. If the business has no real need or desire to change - any benefit case is fiction. However, if there is opportunity for change and benefit - it is a good idea to level set on how much. Our model has four simple stages as it relates to change: maintain, optimize, transform and reinvent. I will openly admit that I "borrowed" at least the last three stage from a recent workshop with Accenture. The stages are pretty straightforward:

1. Maintain - belief that the business and its systems are pretty good as is and focus should be on keeping things humming.
2. Optimize - belief that the business and or systems are ok but there are some opportunities to improve
3. Transform - belief that the business and its systems need to change substantive
4. Reinvent - belief that the business and its system to change holistically

If an organization really just needs to optimize, then framing a project as transformational or building a business case on transformational change is path to problems.

Now sometimes this happens for some very honest and honorable reasons. One of the common issues is that desire or intent begin to muddy the messaging. For example, I have worked with many CIOs that recognize the inherent risk of not doing anything - they feel it in their bones. However, there is no Income Statement or Balance Sheet account for doing the right thing. So, they look for ways justify it. Again, intentions are good. Maybe more common is that organization are not aligned across different stakeholders. Like the boardroom transformation example from before, I see a lot of organizations that even within leadership teams there are misalignments on the state of things and the need for change.

The good news - is that most of these issues can be addressed with diligent analysis, communication and honesty.

Organizations do not fully understand the cost to change

Similar to the historical miss as it relates to benefits of past projects, there are even more horror stories of programs that took twice as long or cost twice as much as originally budgeted. The cost side is the bugaboo less talked about. What has made matters worse is that in most instances, the timeline/cost overruns were not a function of anything reasonable or "positive" (like increased scope). Rather most organizations have experience with poor program management, issues with the technology, difficulties in change management and the like. These somewhat avoidable or self-inflicted wounds are rarely talked about above a whisper - but still give understandable reticence for going another round with an ERP deployment.

However, by not really talking about it organizations fall into the trap of undervaluing the lessons learned by previous deployments. These lessons were learned not just by the organizations deploying the solutions but the entire ecosystem including Systems Integrators and Solution Providers.

The fact of the matter is - the technology is different. Furthermore the methods and tools used to deploy are different. Major advancements have been made to address the challenges previously faced and the result is a much lower cost expectation.

I am certain there are more well written, detailed pieces on this modern deployment topic. So, I will just hit some highlights that I have gleaned - mostly from discussions with a trusted services colleague at SAP - Satya Deshkulkarni.

The Technology is Different

Much of the change in ERP technology can be traced back to the development - and success of pure-play SaaS solutions. One such change is that ERP solutions today are - by design - more modular. The success of line of business SaaS solutions (procurement, etc.) and how they have been delivered - has has required modern ERPs to be able to interoperate and thus can be delivered in a "chunkier" fashion.

Another lesson learned from the SaaS market is in the area of usability or user experience. The solutions were easy to adopt and therefore easy to deploy - a mighty change from the historic ERP experience. New versions have made great strides in this are which has reduced costs for training, adoption and change management.

My last tip-o-the cap to SaaS is in the way solutions are delivered...as a service. The ability to deliver via the cloud has removed a ton of time, money and effort associated with architecting, sizing and procuring the infrastructure needs for an ERP project. This value point only references the savings in delivering the program. As most organizations have come to realize the real benefit is in the simpler, more agile on-going support model of cloud.

The last point on technology is a somewhat uniquely ERP solve. That is the advent of in-memory computing. This has changed the core of how ERPs operate. It has radically simplified/reduced the need for data transformation and replication. It has also enabled embedded analytics and access for business users to real time data in the context of their business transactions. ?Managing data and developing reports has been an incredibly expensive (and never-ending) part of ERP programs.

The Methods and Tools are Different

The traditional waterfall method of delivering programs - with limited user engagement until the end - was painful. New programs - in whatever methodology - typically employ many of the positives of a more agile approach. Specifically, users are engaged much earlier and more frequently in the program. The development and usage of proven implementation templates allow companies to start with a working system - complete with fully integrated configurations, sample master data and test scripts, localization content, etc. This completely changes the way as-is/to-be analysis used to be done - shortening that cycle but more importantly reducing rework and customizations.

In addition to the use of pre-configured templates, the painstaking work of customizing solutions has been addressed in a variety of other ways. The improvement of technology platforms (i.e. SAP BTP) not only simplify and improve custom integrations (via standard APIs), they they also enable low code/ no code development environments which radically reduce development time and complexity.

There has been a tremendous amount of solutions developed to support automation in the delivery process itself. Process analysis (again the as-is/to-be) was a manual, painful exercise - think flow charts or sticky notes. Business process management or mining (BPM) solutions (i.e. Signavio) enable quick, easy visualizations of current business process as well as illustration of the path toward the newly enabled process.

Another time consuming, low value phase of deployments was in testing the new solution. Automated testing tools have become much more sophisticated and intelligent. Newer tools (i.e. Tricentis) allow business users to quickly hone in on exceptions (versus rote testing) - radically cutting down testing cycles.

One of the areas that tripped up many programs was an lack of appreciation for the needs around data clean up and management. This caused delays as well as pain in the matter of extended business user effort. Modern data conversion tooling (i.e. Syniti) that will map, transform and load data automates this process and removes a tremendous amount of manual effort.

We have already made reference to cloud as a key technological change, but it is worth repeating that delivering in the cloud is faster and cheaper than the traditional "on-premise" model that required infrastructure to be part of the equation. Virtual environments are by definition more flexible than physical environments.

Conclusion

Good news! All of the advancements in understanding, technology and methodology means that organizations can approach this next phase of ERP with confidence. Furthermore they can work at identifying and reducing the perceived gap in their cost to benefit model. In summary, here are some good practices to consider:

• Take Stock of Where You Are - We use the term "Perception Model" because much of this will be about actively recognizing lessons learned from the past and addressing perceptions - correct and incorrect.
• Align Around What Level of Change - yes, this is easier written than executed but getting on the same page on where the organization needs to go will avoid disconnects or pitfalls like bloated business cases. Allow for different parts of the organization to have different expectations and therefore different targets. Words matter so...maybe not everyone is "transforming."
• Reduce The Gap By Minimizing Costs - A good portion of this piece outlined the various ways organizations are taking advantages of methods and tools to deliver more efficiently and effectively. Accenture uses the term "Compressed Transformation" which resonates as the need is not just reduced cost, but reduced timelines.

• Deliver In A Measured Manner - All of the advancements also provide customers more optionality as it relates to what and how they deploy. Attacking the overall journey in a measured manner will not only better map cost to benefit, but it will reduce risk and fatigue.

In whatever respective situation an organization finds itself, there are ways to work through perceptions and options. Support partners (solution providers, systems integrators, consultants, etc.) are also getting better and better in helping companies create a solid plan and an accurate message track for their program. Best of all, other companies are "making the leap" to their next generation ERPs - they are doing it successfully and realizing benefits with compressed timelines and cost models. It is just a matter of building one's own bridge.