I think we can all agree that organizational fit is a key consideration for successful ERP selections and implementations. However, mention the phase “fit/gap” or “gap analysis” and most people will fixate on the ERP software. There are several examples of functional/software fit-gap templates/activities but very few organizational fit-gap templates/guides. The goal of this blog is to shed some light on this very important activity.
What is an Organizational Fit/Gap?
An organizational fit/gap analysis is a comparison of the customer’s existing organizational model that supports the business to the defined organizational model supported (or assumed) by the ERP system. Consider the following illustration:
Organizational Fit Gap Analysis
If you do not know what is changing in the organization then how can you manage organizational change? Too often I see ERP projects only focus on the “To Be” model and expect business users to figure out how to transition. I have also observed that customers see organizational change activities as an opportunity to reduce implementation costs by performing the activity themselves – regardless of their capabilities.
In order to effectively conduct an organizational fit/gap analysis there are two key sources of information that are required:
Customer’s Organizational Structure and Business Processes
A majority of peers and customers believe that this exercise is a non-value-add activity given the imminent organizational change that will occur as part of the ERP implementation.
ERP Business Process Maps
Consider ERP business process maps as a demonstration by the ERP vendor to show how their ERP software supports business processes.
Just as you perform a formal Fit/Gap analysis on ERP functionality you should also consider performing a formal organization Fit/Gap analysis as illustrated below:
Template to identify possible organizational changes based upon predefined ERP roles/responsibilities
An organizational fit/gap analysis should be performed during the ERP selection stage and refined during the early design stages of the ERP implementation. Do not limit yourself to performing this exercise only once. The analysis performed during an organizational Fit/Gap will drive future decisions and implementation activities.
What Activities should an Organizational Fit/Gap Influence?
The organization fit/gap analysis will have a direct impact on your organization change management plan and communication plan. In addition, this analysis will provide insight into user security requirements. Utilizing this approach will highlight how well the predefined ERP user security profile(s) align to the organization’s existing users. As a general rule, the majority of predefined ERP workflows are based upon predefined user security roles; therefore keep in mind that ERP user security profile changes may require additional testing for related ERP workflows.
Predefined ERP implementation tools, templates, roles can provide limited value to an implementation. Too often the ERP market wrongly perceives that these predefined components result in faster implementations. This misconception is most pronounced in the ERP SaaS/Cloud arena. At the end of the day, an ERP implementation should only move as fast as the customer can handle the change. Conducting a formal organizational fit/gap can enable the customer to adapt faster by focusing on the specific changes required for success.
Join the community! 10k followers across 100 countries!
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.
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:
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.
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.
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.
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.”
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.
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.
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:
Even with ERP vendors providing SOAP/REST wrappers or web services, effort is required for configuration, testing and validation.
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.
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.
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
User Adoption vs.
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.
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.
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
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 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).
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).
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
Join the community! 10k followers across 100 countries!
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.
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
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
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:
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
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.
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 KPIs 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:
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
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.
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!
Transitioning from an on-premise ERP system to a new cloud ERP service will result in a short-term reduction in ERP user efficiency. This is less of a theoretical discussion but a practical reality that we need to manage. There is never enough hands-on training or testing because we live in a reality of resource constraints. Moving to an ERP cloud service model is a business risk and no ERP cloud service provider will ever eliminate that risk! The purpose of this blog is to provide recommendations to minimize the business risks associated with your transition to the cloud.
I would like to define stabilization (i.e. “shake out”) with the following illustration:
Stabilization is the period of time required for ERP users to acquire the same level of efficiency in supporting business transactions. It is more than just having the new cloud ERP service support the existing business transactions but also that the user can process the business transactions with at least the same level of efficiency and reliability.
In general, following are some of the key factors that
directly influence the stabilization duration:
End User Training.
Any competent Systems Implementation (SI) Partner must realize
and plan for stabilization activities.
In the next section, we will briefly discuss how to manage this
How to Minimize the Stabilization
I’ve been fortunate to have been involved in over 100+ on-premise ERP customer transitions to an ERP Cloud service. I have also reviewed twice as many SI Partners’ implementation approaches to opine on their approach. Based on this hands-on experience, I have summarized the following recommendations:
Recommendation #1: Increase User Involvement
Hands-on experience is the best trainer. A single week for user involvement is simply not enough time to ensure the same level of ERP user efficiency. Users should be involved in prototyping activities before User Acceptance Testing (UAT). Just In Time training is just plain wrong for cloud ERP.
“Although consultants may participate in testing to some extent, employees should drive the majority of testing. Doing so maximizes knowledge transfer and readies them for real life under the new system.” Why New Systems Fail. Phil Simon.
Recommendation #2: Comprehensive Testing
To reduce testing resources and time
commitments, some ERP cloud implementations may reduce testing scope to only
focus on business activities that will occur in the first week of go-live (bad
I recommend that key business milestones (ex.
month-end, quarter-end processing) are part of the implementation testing
Recommendation #3: High Volume/Frequency (Load) testing
Loading testing is the most accurate method to
determine if the new cloud ERP model can handle the daily activities required
to support the customer’s business. If
the cloud ERP provider is truly invested in the customer’s success, then this
service should be a standard offering and not an additional cost.
Test scenario priority should be based upon two
factors: (a) frequency and (b) business impact.
This recommendation is based upon the fact that there is typically no
appetite to conduct a complete parallel financials test with the current
production ERP environment.
Recommendation #4: Accelerate Root Cause Analysis
A cloud ERP go-live best practice is to have a dedicated help desk to support. The main purpose of the help desk is to perform a high level assessment of the root cause of the user issue (3 broad categories):
Cloud ERP service-related.
One of the unforeseen challenges with an ERP cloud service is that there are more complexities (dependencies) with identifying root cause.
The first step to issue resolution is to identify the primary area that is causing the problem. Without this initial assessment, additional cycles will be spent to identify the root cause. Following are key tools and resources that cloud ERP projects must have available for rapid root cause analysis:
Copy of Production environment: A copy of the production ERP Cloud environment to replicate and perform additional analysis on issues. This copy environment should be updated from the customer’s production environment at least on a quarterly basis.
Diagnostic and Logging Tools: Customers should have access and hands-on experience with the vendor’s ERP Cloud diagnostic and logging tools. Granted that the majority of the ERP Cloud diagnostic and logging tools are executed by the ERP Cloud service provider, there is a subset of client-level tools that is also required for root cause analysis.
Customer Specific Extensions & Configurations: In order to keep ERP Cloud services cost low, Cloud ERP providers will employ a shared support model where support resources are allocated to multiple customers. The conclusion here is that customers may have to work with ERP Cloud provider support personnel that only have a cursory understanding of their unique configurations and extensions. Therefore, it is in the best interest of customers to develop a high-level customer profile that highlights the key configurations, transactions, and extensions deployed by the customer.
Do not assume that every cloud ERP providers’ support personnel
have this detailed level of understanding.
Without this summary information, support personnel will ask additional
questions which will increase the issue resolution time. A best practice is to provide this
profile information every time a critical support ticket is created with the
ERP service provider.
Recommendation #5: Continue to engage the SI Partner until the end of the stabilization period
Having access to a competent SI Partner is strategic for customer enablement during the go-live event and transition period. Consulting resources can be available to augment the customer’s help desk resources, address user training gaps, assist with issue resolution and complete knowledge transfer.
Recommendation #6: Dedicated Go-Live ERP service provide support
Cloud ERP service providers should provide an
additional level of support during the go-live event thru the stabilization
Cloud ERP service providers should provide a dedicated
support team versus utilizing a shared pool of support resources during
this critical transition.
Customers should validate what “24 x 7” support
means. Do not assume that same cloud ERP
support resources will continually work on your product issue(s). “24 x 7” support may also require that the
customer’s users have to be available “24 x 7” to collaborate with cloud ERP support.
Recommendation #7: Go live during Business Down Time
By timing cutover during slow business periods,
a company can use slack time to iron out systems kinks. It also gives
employees more time to learn the new business processes and systems.
Recommendation #8: Over Estimate Production Sizing
Capacity planning is an estimate. How dynamic is the sizing of the customer’s production
environment? Is this real-time or batch?
(i.e. if the customer has to create a service request for resizing then the resizing
service is not real-time). If batch then
the best practice is to oversize at least 125% of recommended sizing. This will ensure that you have extra capacity
to spare to complete your first accounting close.
Warning Signs for
The stabilization phase has a huge impact on user experience
throughout the entire cloud ERP service lifecycle. It is self-evident that we have one chance
to make a first impression. While it is
possible to recover from a bad experience, it will take double the effort to
recover. Given this potential impact, I
will provide some “rules of thumb” that customers can leverage to highlight
concerns during stabilization.
The above flags may be categorized as tactical challenges or “shake down” issues after the go-live event but do not underestimate the impact to the user experience. Please remember that users will have the greatest impact on cloud ERP utilization. If the above are not addressed in an aggressive manner, then the following utilization path will become more probable:
The longer the stabilization phase the less trust is created
between the ERP cloud service provider and the customer. As trust declines so will ERP cloud service
adoption and utilization decline.
I’m a firm believer that the cloud model can bring out the best of ERP. However, there is no guarantee that the above will happen. It requires a cloud ERP service provider and SI Partner that proactively address the challenges as part of the transition process. Stabilization is a key phase as part of this cloud journey.
In my humble opinion, the stabilization phase not only is a technical assessment of the ERP cloud service availability and reliability; it must also include an assessment of the usability of the ERP cloud service to efficiently process business transitions.
Join the community! 10k followers across 100 countries!
In this post, I will define a case study where my utilization model is applied for a customer. A key point to be made here is that the health and effectiveness of the business process is directly related to the performance and utilization of ERP features that support the business process.
Case Study – Procurement Business Process
For our discussion, we will focus on the procurement business process. Following is a generic definition of the procurement business process.
To continue this illustration, I will define the key business activities associated with the procurement functions highlighted. I will also define how business activities are likely executed based upon the business process Capability Maturity Model Integrated (CMMI) level.
Manual: The business activity is performed manually. We can assume that since the process is manual that the organizational capacity (resources) is lower for adopting mature business activities.
Partially Automated: The business activity is partially automated. Manual effort is still required to complete the business activity. Integration is performed manually.
Automated: The business activity is completely automated. However, the inputs and/or outputs for the business activity are point integrations at best. Example of this scenario is when a customer utilizes an isolated point solution for a specific activity.
Integrated: The business activity is automated with limited integration. Integrations are limited to the immediate input and output business activities.
Closed Loop: The business activity is both automated and integrated across the entire business process. The customer has visibility to data and metrics across all business activities.
Disclaimer: Now, you may not completely agree with all the information presented in the above illustration, but please do not let that derail you from our discussion.
A key premise of the above model is that mature business activities will provide very limited to no business value until the underlying business process maturity levels are implemented. There are two key factors that directly influence business process maturity levels: technology and people. Practically speaking, we can agree that reaching a CMMI Level 4 or Level 5 requires an integrated and closed loop technical infrastructure that supports the entire business process.
To complete the model we need to answer the following question: “How does this relate to ERP product features?” There are two aspects to consider. First, what appropriate ERP feature(s) support the business activity. Second, to what level of functionality should the feature be deployed. For example, a standard feature in the accounts payable function is matching. Matching is an audit performed for goods and services through the entire process.
Continuing the discussion, if I am working with a customer with a procurement CMMI Level 1 then my focus (scope) will be on implementing either 2-way or possibly 3-way matching in accounts payable. For many of my seasoned colleagues in ERP consulting, this conclusion would appear self-evident. However, to an emerging customer or a new millennial in ERP consulting or sales, this automated guidance would be insightful.
Application in the Real World
Let’s say I am a customer performing research of ERP vendors for a procurement solution. Today, I have two options:
I can gather information via the ERP vendors’ websites. Generally speaking, there are at least 4 ERP products (purchasing, inventory, account payables, and supplier management) that support the procurement business process. For argument stake, let’s assume that each ERP product has 20 features and most ERP vendors provide a feature list for each of their product offerings. If my math is right, that means that I would have to wade through 80 features to determine if the ERP product(s) are a possible fit.
I contact a sales representative or presales assistant to gather information. Next is a series of business need assessment questions I have to answer before I can get the information I need. Most likely, I would also have to involve business users in the ERP vendor’s information harvesting to get any value from the activity.
I would prefer a self-service option that would ask me two key questions:
To expand on this scenario, I provide the following information to the above questions:
Procurement CMMI Level: 2
Organizational Capacity for Change (OCC): Low
We can leverage the above information to quickly refine our ERP product focus to the area highlighted
The power in this approach is to quickly focus on the business activities and corresponding ERP product features that can mature the customer’s procurement business process. Instead of asking a battery of questions that add little value, we can focus on the “low hanging fruit” that can generate quick wins for the customer. However, keep in mind that the customer responded that they have a low OCC. This indicates that we should implement ERP product features that aligns to the customer’s current business activities/maturity. Technology alone does not mature a business process. Keep it simple! Keep it fast!
Customers are looking for a specific, cost-effective ERP adoption roadmap that will enable them to mature their business model in a rational manner. Today, this guidance is created by outside consultants costing thousands of dollars and time commitments from business executives. Using the above model gives us a solid foundation that we can enhance versus rebuilding the wheel for every customer. Automating this model and improving guidance via machine learning enables ERP vendors and consultants to accelerate guidance delivery to customers.
Even with the cloud, ERP implementation services and guidance are still the largest costs that make up Total Cost of Ownership (TCO) for customers. As the cloud delivery model continues to squeeze TCO, ERP vendors and consultants have to find most cost effective methods to deliver specific value and guidance to customers. Machine Learning, CMMI Business Models and ERP Utilization Models can be key enablers to automate business solution guidance.
Join the community! 10k followers across 100 countries!