Grady Brett Beaubouefhttps://gbeaubouef.wordpress.comFor the past twenty-five years Brett has helped customers select, implement, and manage ERP solutions across five industries. Multiple ERP pillar experience across HCM, Financials, PPM and EPM. Business process knowledge and experience Software selection experience includes evaluation of both ERP software and proposed implementation services. Brett has recently authored a book on leading ERP/COTS implementation strategies.
Dr. Jack G. Nestell and I discuss some key influences on ERP organizational change success including the definition of success, ERP success rates, critical keys to project management, ERP expectations, the role of corporate culture, common challenges and pitfalls, Learning and Development (L&D), ERP organizational change conflict, Leadership styles, critical success factors and more!
Suppose you are leading a kickoff meeting for an organization that is just starting an ERP implementation. How would you describe for them “success” in terms of an ERP organizational change?
Why do you think many ERP projects fail to deliver on expectations? There have obviously been countless papers written highlighting all sorts of reasons for ERP failure.
What about training and learning & development (L&D) in the organization? To what extent do you suggest and encourage opportunities for training and learning? Before implementation? During? Post?
What leadership styles, or attributes, would you say were most prevalent during the best of your ERP implementation experiences?
You stated in a LinkedIn post that “An ERP project manager is a necessary evil. An ERP project leader is an influencer and success generator.”. Tell our listeners more.
“I have a go-live coming up soon and the customer executive asked me how I felt about our readiness for go-live. I said “Technically, I am not concerned. Functionally, I’m a little concerned and emotionally I am “$%#****!””. 7 functions (modules) across 13 countries. God help me for being an empathic project manager.”
If you were going to give advice to an organization preparing for an ERP implementation what little golden nugget would you like to leave our listeners?
Recently I created a poll on LinkedIn asking the following question:
Yes, I am disappointed with the # of responses, yet I have high respect for the respondents. Thanks to all for the feedback! First, I will start with the textbook answer that stakeholder management is the first step in requirements management. Good job my friend, Lauren! I’ve never used a stakeholder context diagram (learning opportunity).
It’s messy. Requirements management (i.e., setting expectations and scope) starts in presales and sales. Greg & Chris are insightful regarding internalizing the need for a new ERP solution. Typically, sales teams utilize tools like “influence maps” and “decision maps” as a rudimentary point for stakeholder management.
Yet, stakeholder management is not a one-time document, but an iterative approach must be taken to fully develop a competent stakeholder management document. Many ERP SI partners wrongly think stakeholder management is a one and done activity. Sam, discovery is a vital part of requirements management and will identify and/or reinforce the key stakeholders (sources) for business requirements. Greg, I never had a true appreciation of ERP software selection until I worked for an ERP software selection provider. ERP software selection instills a discipline that is missing today where most ERP selection decisions are based on human perceptions.
On last note, prototyping is an excellent approach to utilize in situations where business requirements are evolving. Examples include implementing a new ERP module or business activity where the customer is not sure what are their requirements and they do not have a complete appreciation of all the stakeholders.
Sorry folks, I could not find a competent, viable diagram to define a process for defining emerging requirements for COTs/ERP solutions (future blog post).
In summary, effective requirements management cannot be executed with a simple checkbox mentality. Experienced SI partners should always assess the heath & quality of document business requirements and take the necessary actions to fill the gaps via additional discovery, stakeholder management, scoping, prototyping and/or validation.
My Humble Opinion, Brett
Noted Sources: I prefer not to reinvent the wheel but to bring different concepts into the right context.
Imagine an ERP solution that drastically reduces manual entry by 90%! The remaining exception transactions can be created via Natural Language Processing (NLP) or user confirmation of AI/Machine Language (AI/ML) recommendations. All supplier invoices are electronic. Moreover, bank reconciliations are performed near real-time via blockchain. Supply chains have the ability and capacity to process an order request, gather the commodity from the location, and deliver the unit to the desired delivery point without human intervention1. Further, sub-ledger reconciliations are eliminated because there is no more need for sub-ledgers. Reports become an obsolete way to communicate information. ERP Cloud updates, testing and feature deployments occur without heavy reliance on third-party consultants. If interested, please allow me to share my vision of autonomous ERP.
What is Autonomous ERP?
While there is no agreed-upon standard definition, following is my characterization of autonomous ERP is based on research and my ERP delivery experience.
Key Points
Reducing and/or eliminating data entry is strategic for autonomous ERP. Robotic process automation (RPA) is a short-term fix to automate data entry, but the goal is to eliminate the need for data entry altogether! IoTs must expand and interconnect, facilitating machine-to-machine communications. Sensors become self-sustaining 2.
It is a reality that ERP Cloud is the delivery model of the future, since its economic and technology-scalable advantages surpass those of any other ERP delivery models. However, if you do not trust your ERP Cloud service, you will not be able to evolve with it. The trustworthiness of ERP Cloud services is only proven through repeatability, reliability, and capability in achieving desired business results. Merely having “leading” features and technologies does not an autonomous ERP solution make.
Just as OLAP and HTAP/In-Memory DBMSs are a necessity for EPM performance today, these are in fact not a requirement in a solution whose performance is exponential compared to today’s standards.
Many existing constructs and ERP designs are still based on the current limitations of manual effort and technology. As Brian Sommer stated:
“Businesses have to be ready to move away from monthly, aggregated data to more precise data, costs and insights.”7
Trust and the ability to rollback AI/ML-initiated transactions will be the key drivers in ERP autonomy adoption.
Five Levels of ERP Autonomy
Since there is no standard definition for ERP autonomy, there is no clear definition for its different maturity levels either. I submit the following model for your consideration:
Key Points
This model is based upon the Department of Transportation (DoT) definition model for autonomous driving.
Level 1 represents siloed feature ML capabilities that represent a “proof of concept” approach from ERP Cloud vendors.
Business results are created through business processes, not individual functional activities or features. Given this reality, a vendor who can provide autonomy across a business process is considered a maturity improvement. (Level 2)
Quick adoption is possible only with a rollback feature. This capability will enhance user adoption and reliance. At this point, over 80% of transactions are digital (invoices, payments, customer interaction) (Level 3)
As the ERP solution learns (digital experience) and business users trust the ERP AI/ML recommendations and results, customers will have their organizations focus less on transaction processing and more on decision-making activities on a trial basis. (Level 4)
At level 5, Business users “think outside the box” to ensure customer value and the ERP Cloud service performs the necessary tasks. The human brain, with its superior neural network, is fully leveraged.
Why do we need Autonomous ERP?
Given Moore’s law on technology innovation, I anticipate that autonomous ERP will happen within my lifetime. Autonomous ERP frees the human mind from the tedious and mundane. As millennials and Gen Z-ers expand their numbers and influence in the global workforce, there will be a greater demand for human creativity within every job role. Today, human creativity is limited by technology performance barriers which require humans to support business transaction processing. However, small strides are being made. Consider the following advancements:
Although separate data models (e.g., OLAP) are a requirement for EPM performance, they are not a requirement in a solution whose performance is exponential according to today’s standards. Making ERP data and analytic structures “in memory” is a step in the right direction. However, the effort required for autonomous ERP will require more than shrinking the von Neumann model.
Just as compiled code was a necessity for application performance, so is the sub-ledger to the accounting model. The sub-ledger is a necessary construct based upon established constraints and limitations.
From my perspective, I see technology as finally catching up with business and not technology changing business. Technology greatly enables the human brain to think and express thoughts outside physical boundaries whereas AI/ML and Deep Learning are limited by the data captured. In fact, human thought is not bound by such a constraint and is, in my humble opinion, the most under-utilized resource with the greatest potential for creating business value. Consider the following illustration below regarding a specific use case for autonomous ERP.
Let’s look at the example of a day in the autonomous ERP world. Jill is the controller for a mid-sized company. As Jill prepares for work, she gets the “morning report” with the following:
Tasks to perform that day as well as tasks that are past due.
Overall performance of her organization versus the plan.
Business exceptions that must be addressed manually.
Recommendations to address current business activities and exceptions.
The “morning report” is available via all interaction channels (UI, Voice, UI plus Voice, etc.)
Subsequently, Jill provides verbal commands based upon the morning report. The autonomous ERP Cloud service executes transactions based upon Jill’s decisions. Next, Jill focuses on the continuous accounting business process to review scheduled activities and provide guidance as needed. The third step of Jill’s day is to review recommendations and approve the exceptions to the standard business process. Now with the basics addressed, Jill can focus on improving the existing business process and prepare for emerging demands. Scenario analysis with business impact scoring and Jill’s input (most important) enables autonomous ERP to make better decisions. Finally, the autonomous ERP solution increases Jill’s productivity by implementing “quick win” capabilities and guides Jill and her team through the deployment.
Customer Recommendations
Autonomous ERP, Intelligence ERP or “plug-in-your-name-here” ERP sounds tempting. However, there are four areas that you should investigate and evaluate for an ERP vendor’s strategy regarding autonomous ERP.
Technologies, like business functional activities, can be siloed and experience the same limitations without having deep integrations between technologies.
Without global standardization for blockchains, IoT, and business process models, the most practical approach would be a single vendor solution.
Constantly worrying, watching, or fixing basic business transactions within your ERP cloud service will have a negative impact on the future adoption of higher-level ERP functionality.
Now, allow me to switch gears to discuss deployment considerations for autonomous ERP.
In addition to the above considerations, a strategic step to prepare for autonomous ERP is to promote and, dare I say, even demand automation across your value network (customers, suppliers, and employees). The best way to ensure that all business transactions are electronic is to do it at the source! Optical Character Recognition (OCR), like RPA, is a gap technology used to bridge the manual and electronic worlds. Additionally, this automation can reduce operational costs. However, scanning still requires manual effort on your part, is slower, and more error-prone than having a fully automated flow. Any manual efforts supporting business transactions are not flexible and are typically costly to adapt and scale. Further, removing manual steps will improve data quality, which is a core requirement for any dependable AI/ML capabilities.
A misconception within the ERP industry concerns the role that AI/ML plays in generating revenue. AI/ML identifies possible opportunities, but it will be your people who execute to realize the wins. After all, technology is simply an enabler! Admittedly, people have the greater capacity for creative thinking and generating additional revenue, but you need to give your people the time and information for creative expression by delegating the basic business tasks to autonomous ERP.
Summary
Dream with me a little. ERP user access is natural and consistent across all channels. There is no longer a need for sub-ledger reconciliations since journal entries are calculated and booked in real time. Accounting closure is done at the transaction level, supporting instantaneous pro forma financial reporting. Employees manage their own career paths and job scenarios. In addition, customers see your company as a trusted advisor and not a vendor. Business users spend most of their efforts on processing exceptions, making decisions based on recommendations and performing what-if scenarios with an impact analysis on shareholder value, customer experience, and regulatory compliance. Is it possible? Yes. Will it require discipline across multiple domains? Yes. Will we have to think outside of our current work experiences? Yes. Is it easy? No. Consider the following:
Until there is global standardization regarding emerging technologies (e.g., Blockchain) and business process models, your best bet is to find a single vendor that can fulfill as much autonomous ERP vision as possible, and provides repeatable, reliable cloud services to support an enterprise solution.
In short, compared with AI/ML, the human brain is still superior and cost-effective when it comes to creative thinking. Today, your company’s “brainpower” is limited to organizational silos and dedicated jobs. Autonomous ERP has the potential of harnessing this vast, untapped resource across all business processes via trusted, automated tactical business decisions.
The latest ERP cloud marketing trend is telling value stories and creating a value hypothesis. Everyone likes a good story and creating a value hypothesis sounds more like a “scientific/evidence based” approach. However, new labels do not automatically improve the ERP sales & selection process.
Consider the definition of a hypothesis within the context of the scientific method.
“a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.”
Wikipedia
Given that an ERP value hypothesis is based upon limited information, it is important to know the level of accuracy and assumptions made to derive the ERP vendor’s value assessment.
The key question you need to ask is “Is the ERP value hypothesis based on reasonable/realistic evidence and assumptions?” Consider the following:
Are there any project assumptions that are problematic?
In the sales cycle, there is an “information gap” between the vendor and the customer which can only be addressed during the implementation. A best practice is to have the ERP vendor generate multiple value estimates based on multiple scenarios (best case, most likely, worst case).
Validate your expectations with the ERP vendor by providing specific value statements. Collaborate with the ERP vendor to determine the corresponding KPIs for the agreed upon value statements.
Do not have unrealistic expectations. For example, reducing headcount by combining and standardizing business activities is more of a function of a shared service model and not the ERP service.
Summary
Value stories and value hypothesis are the latest marketing trend that ERP vendors are using to persuade customers. These tactics are not inherently wrong, however the customer needs to use the same discipline in selecting the right ERP vendor. With an ERP cloud service, repeatability can not be assumed as given with the additional updates applied by the ERP vendor. Remember that transitioning to ERP cloud results in outsourcing your ERP IT services to the lowest bidder. Quantifying how well the ERP cloud vendor supports their customers is an important consideration which have a direct impact on realized business value.
When asked, just about every ERP vendor will say they provide Key Performance Indicator (KPI) reporting. Yet there still remains confusion between metrics reporting and KPI reporting. Unfortunately, using terms like KPI and metrics interchangeably does not help. In the following blog cast and posting I will provide practical guidance regarding KPIs and the role ERP play in supporting KPI management.
Let’s expand upon the above blog cast. Another method to identify KPIs is to take a bottom-up approach. Consider the following illustration:
In this scenario, we have a defined scope (i.e. business process) where we desire to improve business process performance from a Capability Maturity Level Integrated (CMMI) level 3 to level 4. Allow me to simply summarize the key characteristic of CMMI levels 3 and 4:
Level 3: The specific business process has “best practices (i.e. common) deployed.
Level 4: The management of the business process is data-driven. Decisions are based on facts.
First, KPIs should be our focus at the end of the performance gap requirements analysis. The first area should be understanding the organizational change required to mature to a CMMI Level 4. Becoming a data-driven organization does not happen at a “flip of a switch”. ERP users and business leaders must trust the ERP solution and building that trust requires time and ERP reliability.
Second, request the ERP vendor to provide the ERP feature set (i.e. features, reports) that will enable our business process to mature from a CMMI Level 3 to Level 4. If the ERP vendor cannot provide us with this information then I would question how “invested” is the ERP vendor in assisting us in being successful. There is a vast difference between an ERP vendor and an ERP partner. A true ERP partner should be able to easily provide this information (sorry for the tough love).
Third, identify all the relevant operational metrics that we can leverage in monitoring business process performance. Again, the ERP vendor should be able to provide the metrics and Out-Of-The-Box (OOTB) reporting.
Finally, identify the subset of operational metrics that we will actively manage as KPIs. Practical guidance I give to my customers is that you should have no more than 3 KPIs per business process. KPIs are metrics that we actively manage. KPIs should ONLY be forward looking, in my humble opinion. Now please do not misunderstand me that I suggest we disregard lagging and trending indicators. I typically use a car analogy with my customers regarding KPIs and lagging metrics. My dashboard window represents my KPIs. KPIs are forward looking. KPIs should be tied to an incentive compensation plan. KPIs should be a stretch goal and not “status quo” maintenance. Just with the rear-view mirror and side mirrors in a car, operational metrics are artifacts we need to view on an “exception” basis. It is important that we have an ERP solution that can establish an acceptable range for operational metrics and provide OOTB reporting on performance exceptions. This is a reasonable expectation of any competent ERP vendor.
Key Capabilities ERP can provide to identify KPI performance gaps
Recall the question I asked in the blog cast “What if ERP could automatically identify the gaps?”. Having done this activity using traditional methods (i.e. manual), following is what I would consider as the foundational requirements that will enable ERP to provide a preliminary KPI gap assessment:
This is by no means a comprehensive list but it does highlight some of the “critical path” requirements that we can use to evaluate how committed are ERP vendors to customers’ operational success.
Summary
I download an app on my iPhone called “36,000 KPIs”.
Now, the appropriate name should be “36K Metrics” but I digress. It is a neat little (free) application that provide a definition of the metric. I cannot speak to the complete accuracy but it is a good reference that I have utilized as a metrics dictionary. The point to make here is that competent ERP solutions must provide a comprehensive set of operational metrics that can be utilized for exception and KPI reporting. Without metrics, one will have a hard time defining performance baselines. The greater the OOTB ERP metrics provided to your business, the more flexibility one has in business process management and strategies.
By design, ERPs are created to act as the “source of truth”. This design becomes a challenge when the customer has multiple ERP solutions. Each ERP wants to be the master. Most ERP vendors provide an integration to most popular ERP systems but these integrations are point integrations at best. “Best of Breed” may be a viable option. However, many ERP integration cost analyses only focus on a small area and do not calculate the true cost of ownership. The purpose of this article is to elaborate on the Total Cost of Ownership (TCO) for integrating multiple ERP systems to ensure informed decisions are made by customers.
Clearing up the Myth of Seamless Integration
Seamless integration is more of a marketing label and is not a technically accurate statement that defines Out-Of-The-Box (OOTB) integrations between multiple ERPs. This is based on my hands-on experience and scars earned from ERP implementations across on-premise and cloud deployment models. For our discussion, I will focus on the two extremes of ERP integration maturity. Consider the following illustration.
To create a seamless integration between different ERP solutions with different propriety data models requires each ERP solution to “think” they are the source of truth. This requires synchronization across setup (i.e. configuration, workflow, security) and transactions (originating in source ERP system and confirmation/completion transactions in target ERP system).
Deep integration enables the ability to synchronize and transfer data at multiple layers required for an enterprise ERP solution. Point integration only provides the basics to send and receive business transaction data. In general, point integration has limited support across the entire enterprise level. Therefore, additional efforts (manual) are required to keep configuration, workflow and security data synchronized between the multiple ERPs.
ERP configuration is an integration level that is typically understated in terms of importance. Many point integration designs leave configuration synchronization as a manual task that the customer performs. Consider the following illustration:
Given the cost of developing a deep integration between separate ERP systems, a majority of implementations go with the manual route to keep configurations in sync. This tactical decision will have an impact to business users moving forward.
Calculating Total Cost of Ownership for Integration between Multiple ERPs
Another area that is typically underestimated is the true cost of integrating multiple ERP systems. Most estimates focus on only one phase of the TCO for ERP integration:
Phase
Description
Initial Cost
Even with ERP vendors providing SOAP/REST wrappers or web services, effort is required for configuration, testing and validation.
Configuration Cost
The majority of OOTB ERP integration does not include Master Data Management (MDM) features required to keep multiple ERP systems in sync. This requirement is typically addressed manually. Manual updates involve time in data entry and coordination. Manual updates provide an opportunity for data error.
Technical Maintenance Cost
Assuming a Cloud delivery model, ERP updates are more frequent then traditional on-premise delivery models. On average, a competent Cloud ERP vendor will provide two updates per year. In general Cloud ERP vendors will provide an update that has been tested on a “general” configuration and transaction profile. Thus, a “mature” customer will perform some level of testing with each release.
Functional Maintenance Cost
This can be an area with a potential of wild speculation. Taking a pragmatic approach, I will only consider the additional manual effort required to coordinate key enterprise functionality including: data analysis, workflow administration, security administration, and data integrity. I understand that there are additional software solutions (i.e. cogs) that you can add to address the gap(s). However, I consider the additional costs as a missed opportunity to invest in innovation. Besides, just as with a physical machine, the more technical cogs you add to a solution the greater number of potential failures you create.
Given the above elaboration, consider the following TCO analysis:
Consider what other ERP industry experts have stated:
“Integration costs, which include both year zero installation and continued operational expenses, can be as much as 40x each application’s initial cost.” IDC
“Corporate developers spend approximately 65 percent of their effort building bridges between applications.” Gartner
“Mixed-vendor environments can cost 4x as much as a single-vendor.” IDC
“In a survey of 100 CIOs and IT managers from 84 companies by software vendor intersystem, 67 percent answered “yes” to whether strategic integration project have been held back due to excessive software and services cost.” ComputerWorld
Far too often, ERP business cases only capture the initial cost(s) of multiple ERP integration, which is a disservice to key decision makers. Yet, I want to be transparent to you the reader in stating that my above analysis is a broad, general estimate at best. I have attached the cost model I used for this analysis. Feel free to prove it out for your environment.
Limited ERP Integration Results in Limited ERP Functionality and Added Complexity
Implementation services are by far one of the largest costs of an ERP solution. As such, customers will inherently look to keep implementation costs as low as possible. Corners will be cut and scope will be kept to a minimum. The tragedy here is that decisions are made without all the facts and limitations fully elaborated.
Let’s frame our discussion around a frequent ERP deployment scenario. Let’s say that we have a customer selecting two separate ERP systems for a best-of-breed approach. We also assume that the customer is not interested in building a deep integration between the ERP systems and will only utilize the OOTB point-integration services. The customer has a vague understanding that they are required to perform some manual synchronization of configuration setups across both ERPs. Both ERPs go live and functional business tasks are handled competently by both ERPs. The constraints reveal themselves when business activities and decisions cross multiple business processes. In general, these constraints make themselves evident in the following functional categories:
Granted, there are plenty of technical solutions out in the market to address these functionality gaps. However, consider the IT technology complexity considerations:
Just because there is a technical fix to solve the gap does not validate the need. Not convinced? Consider the following customer comments regarding the limitations that ERP integrations can impose:
“We purchased about 3 best-of-breed solutions in the areas of Asset management, Financials and Human Resource management. We have spent over ~N25M, over 12 months to implement, N2M+/yr for support/upgrades per solution, a whooping N35M for integration and it still does not do what we want.
This is the second time we have gone through the integration cycle yet our systems cannot deliver the real-time, asset-driven, consolidated information that narrows the horizon of data into seconds/minutes, not batched hours/days or a week’s worth of data whose latency effectively negates the ability to react with any effectiveness.
The CEO has asked that we look for a single source ERP that is highly flexible and extensible. He is seriously searching for a LONG TERM solution. At this point, he does not care if it is the ‘best’ in a specific area; he wants a robust, single source ERP that can meet all the needs of the company without the headache of integration.” Source: Infoware.
The bottom-line question you need to ask yourself is “Are the additional complexity and dependencies worth the effort?” This is a question that should be answered at the enterprise level, not the business functional (siloed) level.
Recommendations for Customers
Customers should challenge their ERP vendors and System Implementation (SI) partners on their 3rd party integrations. Following are key points for consideration:
Understand exactly what is provided and not provided with OOTB ERP integrations.
Quantify the effort required on the customer to address the gaps in OOTB integrations.
Reducing technology complexity is the greatest enabler for reducing business costs and maximizing business agility.
Warning! Short-term thinking usually results in siloed thinking, which typically results in business limitations and lack of flexibility.
Challenge to ERP Vendors and SI Partners
I can appreciate that providing additional information and guidance may potentially slow down the ERP selection cycle. However, I believe that we (including myself) are duty bound to provide complete guidance to ensure a customer makes an informed decision. Following are key points for consideration:
Identify the functional limitations within your solution for a multiple ERP environment.
Explicitly define the levels of support for multiple ERPs across all levels (configuration, security, workflow, originating transactions, closing transactions).
Explicitly quantify the level of effort for customers to support OOTB point integrations for ERP systems.
Quantify the TCO for ERP point integrations versus ERP deep integrations.
Summary
In general, enterprise ERP solutions inherently support deep integration between their modules based on their design on a common data model. Regarding whether to pursue a multiple ERP versus a single ERP approach, I take a results-oriented approach – whichever strategy adds the greater impact (%) to the Income Statement is the right choice.
On a practical note, when ERP vendors state their solutions integrate with competitor’s ERP products/solutions, it is important to understand to what level of integration is provided OOTB. Put yourself in the shoes of ERP vendor. How easy would you make your ERP system integrate with a competitor’s offering? Due diligence is required on every party (ERP vendor, SI Partner, Customer) to ensure that a complete set of information is provided to make an informed decision.
Join the community! 10k followers across 100 countries!
How much does it cost to create a customer-specific ERP roadmap? $50k, $200k, $1m+? This effort typically requires the higher end consultative guidance and advisory role(s). It also requires a significant amount of customer leaders’ effort/time to support this activity. What if I can show you an approach where one can automatically generate a custom ERP roadmap? If interested then allow me to elaborate.
Are you a Believer?
Before we start, I will ask you to make an investment. I have a habit of repeating myself therefore I will ask you to review the following blog postings before I begin:
Now, if you are still interested then I will ask you to stretch a little further.
Model versus Reality
I consider myself more of a pragmatist than a theorist. Models are great to elaborate upon concept(s) for discussion and argument. However, conceptual models are limited in the value they provide to customers if there is no method to align reality (i.e., “as is”) with the optimal path. Consider the following illustration:
Key Points and Observations:
In a majority of cases, there is a difference between potential ERP utilization and actual ERP utilization experienced by customers.
In order to promote repeatability, there should be a logical progression that enables customers to maximize ERP utilization (i.e., roadmap).
To minimize ERP Total Cost of Ownership (TCO) and eliminate cost constraints, ERP cloud vendors should provide customers with the ability to increase ERP utilization without heavy reliance on consulting services ($$).
The goal is to define an ERP utilization approach that is repeatable and reliable. Far too often, customers spend thousands of dollars on a “point in time” ERP strategy that requires additional funds to revise the strategy as technology changes. The ERP utilization strategy must start with “where the customer is at” and provide a series of ERP features and prerequisite enablement activities in order to increase utilization.
ERP Utilization Roadmap Model
Based on my experience, I recommend that long-term ERP utilization should be a series of incremental quick-wins (i.e., Business Process Management) and minimal paradigm shifts (i.e., Business Process Re-engineering). Consider the following illustration:
Key points and observations:
Any deployment of ERP features that require a significant organization change is not a quick win. People do not change overnight.
An incremental approach like Business Process Management (BPM) is required when deploying new ERP features at the same CMMI level for a given business process.
Set A includes the BPM enablement activities and ERP feature deployments required to align with the logical maturity path. Note that only incremental change is required to implement targeted ERP features (thus, a quick-win).
Set B includes the Business Process Re-engineering (BPR) enablement activities and ERP feature(s) deployment required to align with the logical maturity path. Set Y is not a quick win.
The practical aspects of this model are (1) the roadmap must start where the customer is at in their business process maturity, (2) utilize an increment (agile) approach to build organization momentum, and (3) realize that organizational momentum will carry a customer through the radical changes required for maximizing ERP utilization.
Automating Implementation Guidance & ERP Roadmap
I will utilize the following illustration to put the previous concepts into view.
There are 3 key automation players in the mix.
ERP Configuration Manager: This is a feature of the ERP software that provides an ordered list of data and functional configurations required to implement a feature set within the ERP solution (aka table loading sequence). A competent ERP vendor should provide this capability out of the box. Unfortunately, most ERP vendors only provide ERP configuration manager functionality that only provides the “technical” guidance for configuration.
Implementation Advisor: The implementation advisor compliments the existing ERP configuration manager by providing functional and organizational guidance to the customer during the implementation. The guidance is harvested utilizing AI/ML recommendations based upon findings and trends identified across the ERP vendor’s customer base. The implementation advisor would utilize both structured and unstructured learning to provide the most relevant guidance.
Solution Advisor: The solution advisor focuses on providing the iterative and progressive ERP product feature set(s) required to attain the targeted CMMI level for a business process. The solution advisor must have access to current ERP features implemented but also how effectively business users are utilizing ERP features.
The key strategy of the ERP Utilization model and the solution advisor is to provide an incremental, progressive maturity path that is risk adverse and minimizes huge organizational change.
What’s Missing? Challenge to ERP Vendors
As stated earlier, the majority of ERP vendors provide business process models that highlight how ERP vendors define business processes within their software. The gaps I’ve observed with most ERP business models are there are no relationships defined between the business activity and the corresponding CMMI maturity level and ERP product feature(s). Adding this metadata to the model will enable an automated approach to implementation and roadmap guidance.
Summary
Implementation costs remain the largest part of an ERP TCO analysis. The cloud delivery model has greatly reduced the hardware/software/infrastructure costs. Unfortunately, the ERP market places more focus on vendor capabilities and emerging technologies versus ease of implementation and customer self-sufficiency with ERP services. No technology adds any business value until its in production. Second, an automated ERP solution advisor provides real-time guidance to customers versus periodic, manual feedback that generally results in “leap-frog” implementations that have greater risk(s) and cost(s). Stay safe!
P.S. – Despite my sincere attempt, I did repeat myself.
Join the community! 10k followers across 100 countries!
It is generally accepted that user adoption and user engagement are key critical success factors for ERP business value realization. However, a majority of ERP implementations take a cursory approach where a qualitative method was utilized for measuring user adoption and user engagement. A qualitative approach focuses on data that is subjective, interpretive and exploratory. Let’s see how successful this soft approach has been in the past.
According to a 2014
survey from Panorama Consulting Solutions of 192 businesses, 66 percent of
respondents reported receiving 50 percent or less measurable benefits from
their ERP implementation, and less than 40 percent were satisfied with the rate
of user adoption. In the US, a recent study
estimates that over half of all Accounting, ERP, and CRM
implementations fail to meet their objectives. In Europe, the corresponding
statistic is 70%–80 %! An oldie but goodie
is what was learned
from the 1999 Hershey’s ERP failure (user adoption). A recurring theme from the ERP failures
listed above is a lack of actively tracking and managing user adoption and user
engagement. Traditional approaches of
End User Testing (EUT), Just-In-Time (JIT) training and user surveys are
insufficient for a reliable, effective user adoption and engagement process. In the following sections, we will discuss
practical steps that you can take to better quantify user adoption and user
engagement.
User Adoption vs.
User Engagement
The first step to take in implementing a measured and
repeatable approach is to understand the difference between user adoption and
user engagement. User adoption is
when users adopt a system that works to fill a specific need. User engagement measures how effectively a
system is utilized. A user can adopt an
ERP solution but yet the user is not making the most of the ERP functionality
available. In my humble opinion, I
believe that we in the ERP industry too often try to broadly address these
specific areas with qualitative surveys which are translated into quantitative
data with some level of bias.
Don’t get me wrong, using surveys and statistics as a tool to provide some level of quantification of qualified user feedback is an established approach. The problem occurs when user surveys are the ONLY method we use to manage user adoption and user engagement. Surveys were necessary in what I call the 1st generation of ERP given that the technology and availability of user data was not a primary objective for ERP vendors. However, now that we are in the 2nd generation of ERP, user data is more available for consumption. We in the ERP industry have to leverage this new capability in addition to conventional means.
What data should we go after to highlight user adoption and user engagement? Consider the following illustration as a starting point.
Quantifying ERP User Adoption & User Engagement
Starting with user adoption metrics:
Test cases executed: Quantify how many end-user test cases are executed by ERP users. There is no better method for training and fostering user adoption than “hands-on” experience. Automating testing may not always be the best option for all scenarios.
Number of users: Quantify how many users are provisioned for the ERP solution. An increase in ERP users could be an indicator that organizations see the ERP solution as an enabler. Conversely, a decrease in ERP users may highlight a risk.
Consumed training: There are three attributes to capture in the area of training: (1) Total # of hours consumed, (2) Total $ spent on training and (3) Average training hours per user. An “intuitive” user interface is not a substitute for user education and training.
Number of ERP sessions by connection type: Another perspective of measuring ERP user adoption includes (1) number of user sessions by connection type (online, mobile). Mobility can be a huge enabler for greater data visibility and accelerating approvals. Capturing this data will provide customers deeper insight regarding how their users consume their ERP service.
Continuing with user engagement metrics:
Number of manual transactions: “A major overhead in operating ERP systems is entering transactions. Transactions take time, cost money and introduce the possibility of errors.” Making ERP Work, Sam Graham. If you are interested in process efficiency and ERP business value realization then the customer should take a hard look at these scenarios and have a plan to minimize these activities.
Number of correcting transactions: Correcting transactions are rework of existing transactions. If you are a student of Lean Six Sigma like I am, then customers want to do everything they can to minimize rework. This type of rework may seem insignificant at the individual user level, yet the customer will be surprised when (1) the rework summarized across the organization and (2) the customer quantifies the impact(s) to business process cycle time(s).
Number of exception transactions: Any competent ERP solution allows some level of exception transactions. Example: At month end, the user makes an Accounts Payable journal entry in the General Ledger and then the ERP solution automatically accounts for the journal entry in the Accounts Payable sub ledger. Another example of an exception transaction is when a transaction is rejected (Expense Report). Exception transactions are a necessary evil. However, it is important to note that exception transactions generally require (1) additional user effort (costs) and (2) slows down the business process cycle. Tracking this type of data will provide insight regarding the root cause for cycle time exceptions.
Decision support transactions: A common value proposition that all ERP vendors are making today is enabling users to have more time to focus on making business decisions by automating tactical business transactions and consolidating data into meaningful information. Therefore, we should be able to measure this effect by categorizing and capturing this information via the ERP solution. For example, if we observer that the number of manual transactions are decreasing and the number of decision support transactions increasing then we can feel confident that the organization is effective in utilizing the ERP solution.
Following is an example of an ERP solution user engagement model.
Measuring User Engagement with ERP
Let’s elaborate on a couple of points. First, user adoption does not equate to effective user engagement. The majority of ERP solutions provide the customer the ability to perform transactions efficiently (automated) and inefficiently (manual, exception, corrections). As a customer, part of your responsibility is to identify inefficient use of the ERP solution and create an improvement plan. From the above profile, we can identify the following:
There is an unhealthy volume of manual transactions. As the volume of manual transactions increase, it is reasonable to conclude that there will be a greater increase in exception and correction transactions (resulting in additional cost/cycle time).
It is possible that the increase in manual transactions is due to a limited configuration of the ERP solution and the user’s knowledge of the ERP’s features. Configuration issues can be identified by the customer’s support team and the ERP vendor’s support resolutions.
As the customer performs user enablement analysis, it is
important to note that a visible pain may be a consequential result of an
underlying issue.
Practice Makes Perfect
User efficiency with an ERP service is not a Just-In-Time event but an incremental process. Given that people are the most important component of a business solution, it is negligent not to involve users thought out the ERP service implementation. Sorry for the tough love but this is a gap that no one wants to address head-on. It has been identified as a critical success factor but is typically handled as a “negotiation play” during the sales process. If a customer is smart, then they can use data like user adoption and user engagement as leverage with the ERP vendor and SI partner.
Incremental User Involvement with ERP Implementations
Incremental user involvement during the ERP solution implementation requires greater project management coordination and guidance. Second only to the ERP vendor, end users directly impact business value realization for a customer.
Rising to the Challenge of Creating Reliable User Adoption and Enablement
Referring back to my previous article, effectively business value realization will require an investment from the following stakeholders.
Challenge to SI Partners
User Adoption and User Engagement should be generally accepted as key project management metrics (On-time, On-budget, In-Scope).
SI Partners should deliver and execute a knowledge transfer plan for each ERP implementation.
Customer should make an investment of at a least 20% investment in user training and user enablement. Consider the following guidance:
IDC Learning Services Research shows that organizations, on average, spent 15% of their total ERP budgets on training, while indicating that a 17-20% investment yields better results.
Gartner Group research shows similar averages and an interesting fact: organizations that spent less than 13% of their total ERP cost on training were three times more likely to see their ERP projects exceed deadlines and run over budget when compared to organizations that spent 17% or more.
Aberdeen Group says that ERP is not a “set it and forget it” tool. Implementing a continuous learning strategy will help users complete their tasks successfully pre- and post-launch.
Challenge to ERP Vendor
ERP vendors should deliver out of the box user adoption reporting and user engagement reporting as described above to enable customers in actively managing ERP service utilization.
ERP vendors should provide support service analyses that are a result of incorrect configuration or lack of training.
Challenge to Business Users
Business users must be open to change and innovation. Sticking to the legacy process and keeping things the way they are at all costs reduces the chance of real optimization with the new ERP solution.
Users must broaden their horizon from a functional job focus to business process focus. This requirement is not just for super users. Every individual ERP user should have an understanding of how their input impacts the overall business result(s).
Summary
“Without data, you’re just another person with
an opinion.” E.
W. Edwards Deming.
For far too long, ERP user adoption and engagement
management has been strictly a qualitative exercise given that there has been
limited services provided to easily quantify user metrics. One type of data is objective, to-the-point,
and conclusive. The other type of data is subjective, interpretive, and
exploratory. Given how important user
adoption and engagement are to ERP solution success, there should be a
comprehensive approach including both qualitative and quantitative data for ERP
user involvement.
Join the community! 10k followers across 100 countries!
Implementing
a Cloud ERP solution does not guarantee business value, regardless of the Cloud
ERP provider (vendor). There are
countless examples of customers that have not experienced the expected business
value articulated in the sales cycle.
Why is this?
Cloud ERP software could not deliver on the business benefits promised.
Customers could not adapt to the delivered public Cloud ERP delivery model.
System Implementation (SI) partner could not implement Cloud ERP correctly or SI partner could not enable the customer to support their Cloud ERP solution.
Naturally,
when things go wrong every stakeholder will point the finger at each
other. As each stakeholder has a share
in the success of a Cloud ERP implementation, so is there a share of
responsibility in the failure of realizing business value from a Cloud ERP
implementation.
A common theme I’ve observed in my ERP implementation experience is the lack of defining business value goals to be managed during the ERP implementation cycle. The majority of time, business value goals are assumed as a “natural” result from the project. Many consider business value an area that is managed after the initial implementation. The inherent flaw in this approach is that the cost to manage business value is greater when the Cloud ERP solution is live. This statement is a corollary to the rule that fixing bugs in design is 15x less than the cost of fixing bugs in production.
For example, let’s say you want to consolidate individual functions into a shared service model to leverage economies of scale and promote greater process efficiency (business value). However, this transition is not easy given that the implemented enterprise configuration only considered a “point-in-time” structure. Addressing the functional configuration limitation in production requires greater effort/discipline in a public Cloud ERP model versus an on-premise model (no more direct SQL updates in a public Cloud production environment).
I recommend that business value is front and center throughout the implementation and that business value is the ultimate indicator of Cloud ERP implementation success. Unfortunately, the majority of Cloud ERP implementation methodologies are based on “traditional” approaches of on-time, on-budget and in-scope.
What is Business
Value Realization?
Do
you know how many definitions there are for business value realization? The number is far more than I can count! I pride myself at being a pragmatist versus a
theorist. Therefore, the definition must
support a repeatable and realistic process given the reality of resource
constraints. I am not arrogant enough to
say that I have it all figured out, but the following is my working theory as I
interact with ERP customers:
Business
value realization is the observed evidence that the customer
experiences either as a positive or a negative impact on business process
execution. Consider the following
points:
Business value is in the eye of the customer. I humbly believe that the vendor and the SI Partner are responsible in assisting the customer to see the business value created. Simple cost reduction does not equate to business value.
From the customer perspective, business value unnoticed is business value unrealized. Education is a key requirement in business value realization.
Without a baseline, how can one quantify the business value realized? As the Cloud ERP market continues to become more competitive, realized business value will become a competitive differentiation for Cloud ERP vendors.
Now that we have defined the problem, let’s spend some time discussing how to best address business value realization during the implementation.
Business Value Realization
Framework during the ERP Implementation
I have done an exhausted search of business value realization frameworks. The majority of the frameworks do not address the implementation phase of an ERP solution. I contend that these approaches should be updated given the apparent level of dependencies that business process execution has with technology today’s environment. I’ve only found one framework that addressed business value realization during the implementation.
This is a great framework from an IT perspective from the academic world. I would recommend the above framework to any IT leader looking to create more of an advisory service versus being a traditional service provider (IT should move up the value chain). In general, I agree with the Lean Six Sigma approach to focus first on process efficiency then process effectiveness for most revenue-supporting and compliance processes. However, for revenue generating processes, it may be best to focus on process effectiveness first to create market share/disruptance before focusing on process efficiency.
Now, allow me to provide a more detailed framework for business value realization during an ERP implementation.
Performance metrics including KPIs are the definitive “evidence” that the ERP implementation added business value. Therefore, it is very important that you take a baseline or “snapshot” of your business KPIs before and after the ERP implementation to measure the business value. My recommendation is to capture the baseline business KPIs during the sales cycle. Hint: Leverage the ERP vendor to assist you in defining the specific business value you will experience with the purchase of their ERP software.
As you progress thru the Cloud ERP implementation, broad vision and objective(s) becomes specific siloed tasks. It is important that you reassess your project progress to the agreed upon vision and objective(s). An iterative approach is best to ensure that you have to opportunity to perform course corrections during the implementations versus more costly corrections after the implementation.
Capturing the post KPIs should be done after stabilization. The duration of the stabilization phase depends on several factors that I addressed in a previous blog. Once you have captured the performance metrics and KPIs, you should be able to provide an accurate picture of success and improvement gaps.
Summary
Going live is only the beginning to business value realization. Second, traditional ERP implementation project metrics (On-time, In-Scope, and On-budget) only have an indirect relationship on business value. Generating business value is the primary objective of an ERP implementation, not just moving to the cloud or replacing an outdated system. Business value must be an iterative and recurring theme in your Cloud ERP implementation approach.
Business value must be a continuous focus for all key stakeholders. Failure to do so will result in a longer period to business value realization.
Join the community! 10k followers across 100 countries!
“In a survey of 1,322 global organizations who had implemented ERP in the previous three years, only 21% of respondents said that they had realized 50% or more of the expected benefits.” (Source: Lumenia).
Total Cost of Ownership (TCO) and Return On Investment (ROI) are the outdated, traditional indicators of ERP success. These metrics have been turned on their heads with the new Cloud ERP subscription based model. Even with cost reduction, the subscription model does not solve the issue of unrealized business value.
It begs the question when will Vendors and the System Implementation (SI) Partners provide a more equitable risk/reward agreement via a business value based pricing model? In the current Vendor-SI-Customer model, the customer assumes the majority of the business risk(s) & cost(s). Given that the Cloud ERP market is still open for domination, customers should consider a business value based agreement where all parties share in the rewards and risks associated with a transition to an ERP cloud subscription service.
Paradigm Shift from Vendor
SLA Compliance to Business Value Realization
The traditional “On-Time, On-Budget” KPIs have no direct impact on Business Value Realization (BVR). The previous mentioned measures are more of a Vendor-Service Provider metric to demonstrate that the Vendor-SI Partner completed the delivery of services. This approach assumes that the Vendor-SI Partner knows “exactly” what the customer needs for BVR. Also consider that the “On-Time, On-Budget” metrics is more aligned with a commodity-based service. As a customer, do you want a commodity-based implementation approach or a custom customer-based approach for your Cloud ERP transition?
With current subscription and professional services contracts,
there are no financial incentives to ensure all stakeholders focus on the true
objective of value realization.
Building a Business
Value Based Agreement
The first and most important step in aligning partner(s)
focus on BVR is developing a Statement Of Work (SOW), Service Delivery Agreement
(SDA) that focuses on attaining business value.
Consider the following example:
Business Value Realization (BVR) is a mutual responsibility between the Customer, the Vendor, and the SI Partner. This agreement does not infer that the Customer will get the cheapest price for an ERP transition to the Cloud. In fact, this agreement will cost the Customer more than a “commodity-approach” ERP transition to the Cloud. “You get what you pay for.” Contrary to marketing hype, there is nothing inherently “intuitive” about the Cloud model. The implementation effort is the same to the SI Partner.
Smart Transition to a
Business Value Realization Agreement Model
Every ERP Cloud Vendor and SI Partner will say that their #1 priority is your company’s business success. Yet, this is not always true “in the heat of the battle”. Customers also need to step up their investment and capacity for change with this agreement approach.
I cannot count the number of times where customers did not
know what they purchased or they did not purchase every individual product to
support their business process(es).
Keep the focus on business results, not product(s) and feature(s).
Second, ERP service training must be available and easily accessible across multiple
delivery platforms. Vendors should also
make formal training as cheap as possible.
Consider the following quote:
“Untrained (or under trained) users may end up needing three to six times as much support as end-users who have been trained.” ERP: Tools, Techniques, and Applications, Carol Ptak, Eli Schragenheim.
ERP Vendors, it is as simple as this. Either you take a smaller profit hit now by providing
free formal training or you will pay in buckets of operational support costs
down the road. In the next illustration,
we will discuss key responsibilities and maturity activities for SI Partners.
In my humble opinion, SI Partners have two key
responsibilities for competent delivery of ERP implementation services: (a)
maximize the value of the Cloud ERP service purchased and (b) complete
knowledge transfer for Customer enablement.
It is also important that the Customer defines an accurate KPI baseline
on existing business activities in order to compare against business results
experienced in new Cloud ERP service. SI
Partners should be able to assist and guide Customers in this exercise.
Now, let’s have a practical discussion regarding the
customer’s responsibilities:
Customers have to align their expectations to their
executive’s decision to move to an ERP Public Cloud service. There are non-competitive business activities
and reporting that should be eliminated.
ERP software changes will accelerate
by a factor of 5 in an ERP Public Cloud delivery model. Either you can make an investment in
Organizational Change Management (I recommend Prosci (ADKAR) or your company can expect to
maintain/grow their IT budgets given all the ERP extensions they have to test
and maintain with every service update.
Money Talks –
Consider Retentions to Promote Shared Success
The traditional approach of using go-live as the key event
for ERP service delivery is not an effective indicator for business value
realization. Is the event a
prerequisite? – Absolutely! In a
previous post I discussed how true business
value realization is not possible until you are past the stabilization phase. I
would recommend that you create retention of 25% for both professional services
fees and vendor subscriptions to promote focus and delivery from every provider
until business value is realized.
Summary
Gartner estimates that companies are achieving only 43% of their technology investments’ full potential value.
In my humble opinion, an overriding driver for this gap is the traditional approaches Vendors, SI Partners, and Customers are clinging to in driving business value from technology. ROIs and TCOs are extremely high level estimates based on a huge number of assumptions and constraints that are not fully defined in the sales cycle. ERP Cloud vendors and SI Partners are more concerned with transaction efficiency and commodity repetitiveness versus unique customer business success. A Business Value Realization agreement is not easier, or cheaper and will require a greater investment from all three players.
Don’t expect any ERP Cloud Vendors or SI Partners adopt this
approach any time soon given where we are at in the Cloud ERP market cycle:
As the market reaches its apex and competition continues to grow, disruptive agreements based on BVR will become a strategic competitive advantage. Customer will make a decision on whether they want a Vendor or a Partner. ERP Cloud Vendors are transactional and replaceable. ERP Cloud Partners are long-term relationships critical to your success.
Join the community! 10k followers across 100 countries!
ERP the Right Way! 