ERP Project 101: Organizational Fit Gap

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: 

Org Gap Analysis

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: 

Information   Source Comments
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:

Organizational Gap Analysis for ERP

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. 

Why Do We Need a Formal Organizational Fit/Gap?

Conducting a formal organizational fit/gap enables you to quantify the level of change.  Instead of taking a broad stroke at managing change you can provide a focused effort to accomplishing your objective. Remember that people are the most important component of a business solution.  Given the importance I believe that formalizing this activity is worth the investment.

Summary

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!

Autonomous ERP

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.

Key Points

  • If an ERP vendor cannot handle the basics (e.g., accounting close), why trust the vendor with higher level capabilities (AI/ML)?  Services trump software in a cloud delivery model.
  • 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. 

Sources

  1. An Autonomous Supply Chain: Is it Possible (Redwood)
  2. The Internet of Things How the Next Evolution of the Internet (Cisco)
  3. IoT Is Changing Everything (Cisco)
  4. 5 Key Challenges for Blockchain Adoption (Blockchain Council)
  5. Industry 4.0: the fourth industrial revolution (i-scoop)
  6. From Human Resources to People Enablement – HCM in the 21st century (InflectionHR)
  7. Time changes & the impact on ERP, accounting and business practices (diginomica)

ERP Value Hypothesis

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?
  • User adoption does not equate to effective user engagement with new ERP cloud service.
  • 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.

ERP and KPIs

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. 

Integration Trumps Functionality for Enterprise ERP

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:

PhaseDescription
Initial CostEven with ERP vendors providing SOAP/REST wrappers or web services, effort is required for configuration, testing and validation. 
Configuration CostThe 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 CostAssuming 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 CostThis 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!

Using AI/ML to Build Customer-specific ERP Roadmaps

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:

  1. In a majority of cases, there is a difference between potential ERP utilization and actual ERP utilization experienced by customers.
  2. In order to promote repeatability, there should be a logical progression that enables customers to maximize ERP utilization (i.e., roadmap).
  3. 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. 

  1. 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.
  2. 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.
  3. 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!

ERP Utilization Series: Measuring User Adoption and Engagement

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. 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).
  3. 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.
  4. 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

Increasing User Involement
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.
  • SI Partners have an incremental user involvement during the ERP solution implementation. 

Challenge to Customer Leaders

  • 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!

ERP Utilization Series: Business Value Realization

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? 

  1. Cloud ERP software could not deliver on the business benefits promised.
  2. Customers could not adapt to the delivered public Cloud ERP delivery model.
  3. 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!

Disrupting the ERP Cloud market with Business Value Realization

“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:

“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 Utilization Series: Minimize Stabilization Phase

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.

What is Stabilization?

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.
  • Testing.
  • Support.
  • Infrastructure.

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 transition period.

How to Minimize the Stabilization Period

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 practice). 
  • I recommend that key business milestones (ex. month-end, quarter-end processing) are part of the implementation testing plan. 

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.
    • Customer infrastructure-related.
    • Training/Education-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.
  • “Maintain the project team for at least 1 month after the go-live date.” Consider, Select & Implement an ERP system, O’Sullivan, Rico, Goldensohn.

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 period. 
  • 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 Prolonged Stabilization

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. 

Summary

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!

Using AI/ML to create a Customer-specific ERP Business Process Maturity Model

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.

Legend:

  • 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:

  1. 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.
  2. 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!

Value Proposition

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.

Summary

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!