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 high level of quantification of qualified user feedback.  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!

Using AI/ML to predict ERP Utilization

There are not many methods on how to maximize ERP utilization. There are approaches that do a commendable effort in identifying some of the factors that influence ERP utilization.  What is lacking are predictability, repeatability and harmony across the key components of a business solution.  In my 25 years of ERP consulting experience, I have never encountered a single customer that utilized over 60% of the ERP software.  Given the lack of utilization and the money needed for cloud ERP implementations, I am convinced this is a problem that finally must be solved!   We are in the second generation of ERP software and the only advancement that we in the ERP implementation arena have made is to retract our initial recommendation of customizing ERP for greater customer value.

The purpose of this article is to provide an overview of my theory on predicting ERP utilization.  The scope of this article will focus on the cloud ERP deployment model.  I have yet to complete the rigors of the scientific method to verify my theory.  However, I would like to share my concepts with you and partner with you in growing the collective knowledge.

ERP Utilization requires all components of a business solution

ERP Business Solution

First we need to revisit the concept of a business solution, the key components, their relationship, and influence on ERP utilization.

Just as technology has a part to play in ERP implementation success, business process maturity and the organization’s ability to change have a greater impact on ERP utilization.  To elaborate on this thesis I will make use of two models:

  1. Capability Maturity Model Integrated (CMMI).
  2. Organization Capacity for Change (OCC).

CMMI Level Characteristics

I find that Organizational Change Management (OCM) is more of a project-based effort to enable an organization to meet a specific event.  This approach works very well with an on-premise ERP solution where upgrades are measured in years.  However, in the more dynamic Cloud ERP solution model, change is more rapid.  ERP cloud updates and upgrades happen in months, not years.  What I really like about OCC is the greater focus of providing the organization with the skills and flexibility to handle known and unknown changes. 

OCC is an emerging model, thus there is limited content regarding how to assess and measure OCC for an organization. There for 4 key attributes for defining OCC levels (Saylor Academy, 2012):

  1. Organizational Trust
    • It refers to how much front-line workers trust middle managers and senior executives to watch out for their interests.
  2. Lateral Leadership
    • Focuses on getting things done across organizational units and functional areas of expertise. Fisher and Sharp (2004).
  3. Systemic Knowledge
    • Systemic knowledge is the degree to which members of an organization understand and are focused on the overall organizational system.
  4. Cultural Ambidexterity
    • Change-capable organizations balance accountability with innovation. If the organization overemphasizes accountability, innovation suffers. And if innovation is the sole focus, accountability is ignored.

Given the above definitions, I have created a level definition to support my ERP utilization prediction model.

ERP Utilization Model

With all that said, consider the following conceptual model:

Model for ERP Utilization

I propose a multivariate linear regression relationship between business process maturity, organizational capacity model for change with potential ERP utilization. This simplified model is based on the following assumptions:

  1. A set of ERP features require a certain level of organizational and business process maturity for a successful experience.  For additional information, see my article on Business Leads and Technology Supports.
  2. Based upon the CMMI level and OCC for the customer, we can infer the ERP features required for maximum ERP effectiveness.
  3. OCC has a direct influence on effective ERP utilization.
  4. Software changes will happen more rapidly in an ERP Cloud delivery model versus a tradition ERP On-Premise model.  Therefore, OCC must become an ongoing competency (versus a one-time effort) for long-term ERP success.
  5. “It is generally not fruitful to impose a very sophisticated process on an organization whose maturity is low.  The maturity of an organization not only depends on the skill sets of the individuals, but also on the chemistry of the team.” (Alexia Leon, 2012)

Based on the above model, I conclude that customer enablement must be an ongoing exercise that runs in parallel or even precedes ERP automation.

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 heavily relying on consulting services.

As we continue with the model elaboration, we find that there are regions that are not practical for a given CMMI and OCC values.  Consider the following:

Key Points and Observations:

  • Circles represent a subset of possible values given that the scenario occurrence is highly improbable. For example, an organization with a CMMI level 1 maturity cannot expect to utilize 100% of the features available for a Cloud ERP service.
  • The permutations of CMMI and OCC levels indicate a linear relationship for targeted ERP utilization.

What Role can Machine Learning Play?

If we can define a logical model with reliable predictive results, then we can begin the journey of providing free consultative guidance to ERP customers and prospects. Let’s start simple with a prediction formula and a structured learning test set.

Following are the assumptions that I used for building the formula and training set:

  1. Business process maturity (CMMI) and organizational maturity (OCC) have a linear relationship with potential ERP utilization.
  2. Certain permutations of CMMI and OCC does not reflect reality (ex. Business process cannot be at a high level of maturity and a low level of organizational maturity).
  3. The minimal boundary of ERP utilization is 20% and the maximum boundary is 80%.

Next, I performed individual regression analysis for each variable separate and together in order to determine if the predicting equation should use one or both variables.

Based upon the above analysis, it appears that the prediction formula utilizing both business process maturity and organizational maturity best aligns with the training set. Next step is to calculate the coefficients for both variables.

In an act of transparancy, I am sharing my data model. Feel free to review and provide feedback/correction.

So what is the application or value add this model can provide?

Summary

Even with a cloud delivery model, the implementation costs associated with ERP have not dramatically decreased.  The ratio of ERP software cost to ERP implementation cost has increased from 3:1 to 6:1.  It is only a matter of time before the ERP market forces ERP vendors to drastically reduce implementation costs while maintaining a sufficient level of customer enablement.  Given the rise and general adoption for cloud ERP services, ERP utilization is becoming more strategic competitive advantage for cloud ERP vendors.  What I see as an emerging demand from the ERP market is a reliable, repeatable method for maximizing ERP utilization.  I hope that my efforts move the discussion forward.

Join the community! 10k followers across 100 countries!

ERP Project 101: Challenging ERP Requirements

I am not arrogant enough to believe that ERP software vendors are the guardians of best practices.  Nor do I blindly subscribe to the notion that the customer is always right.  What I do know and believe is that a good implementation partner will balance customer needs and wants with the fundamental value proposition of the ERP software to ensure customers have relevant information to make informed decisions.  The following blog posting will discuss some practical guidance that implementation partners can utilize to vet business requirements.

You must be given permission to challenge customer requirements

Regardless of your previous experience or how smart you think you are in order to be effective as an ERP implementation partner, you must be given permission by the customer to challenge their ERP requirements.  It is rare to receive this permission automatically but rather it must be earned by the implementation partner.  Following are core principles I use to earn that permission:

Vetting ERP Requirements

Earning the Right to Challenge Requirements

 

Knowing ERP functionality is simply not good enough.  A competent implementation partner is able to advise and influence their customers to draw the right conclusions and make informed decisions.  Next we will discuss how a good consultant guides the customer towards making an informed decision.

Lead by asking informed questions

In my early days of ERP consulting, I was taught to ask open-ended questions to prompt the customer to provide as much information as possible.  I agree with this approach as long as the information is value-add and guides the customer down the right path.  Too often I see ERP consultants mindlessly ask the customer 100+ ERP functional questions that focus more on “how” than “what” and “why”.  The following illustration provides key concepts that questions should drive customers to consider: 

Asking the Right Questions

Asking Informed Questions

 

Use questions to educate.  Use questions to persuade.  Questions should lead your customer to challenge assumptions and perceptions in their current environment.  A perceived requirement may be a limitation of the current system or organizational structure.  Just remember that asking the right questions is just the beginning to changing minds.

The best pressure is peer pressure

As a third-party external resource with limited knowledge of the customer’s business model, there are limitations implementation partners will have on generating customer ownership and adoption.  What consultants should do is facilitate and promote a process where relevant information is presented and evaluated.    Do not evaluate business requirements in functional silos but as part of the larger business process across all business stakeholders.  Visibility across the business process creates accountability – especially with peers within the customer’s organization.

Results of Business Requirements

Understanding the Impact of Business Requirements

 

The basic value proposition of ERP systems is providing the automation of best practices – that is common business practices – across a broad market/industry.  A direct contradiction against this key benefit is when a business requirement has to be addressed via a software customization.    Additional scrutiny listed above should be undertaken to validate the additional investment required.

Not challenging business requirements is a disservice to customers

A fundamental expectation that customers have for ERP solutions is to have a flexible and cost-effective business solution.  A key assumption required for cost-effectiveness is that ERP “out of the box” functionality addresses the majority of the customer’s business model.  Customizations have both a short-term and long-term impact on cost effectiveness.   I am not arrogant enough to state that ERP software addresses all the best practices a customer may be utilizing.  However, I have observed too many ERP implementation partners take the easy option of catering to user requests without leading the customer through a critical analysis to determine both the short-term and long-term implications of a specific customization. There are legitimate needs for customizations.  It is not an ERP implementation partner to prevent customizations but rather to ensure that customers have appropriate expectations and conclusions as a result of their implementation decisions.

Summary

In my humble opinion, good ERP implementation partners educate their customers in how to best utilize ERP software to support their business.  This not only requires ERP software knowledge and but more importantly requires the business acumen to understand current requirements and advise on future requirements.  Customers, if you are looking for an implementation partner that can act as a leader then you will have to pay a higher rate versus a staff augmentation partner.   ERP vendors play a very important role during an implementation – especially where it comes to best practices that are not delivered out of the box by the ERP software.  ERP vendors should provide multiple processes and examples of working with customers to influence software roadmaps and/or co-develop automated solutions.  Action speaks louder than words!  True partnership requires an investment from every player.

Join the community! 10k followers across 100 countries!

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!

SaaS ERP is not a push button solution

SaaS ERP is the latest effort in the ERP industry to provide a rapid, cost-effective solution for customers who want an enterprise solution.  A SaaS deployment model does provide the potential for greater value realization; however, the value proposition is dependent upon appropriate expectations and implementation approach.  The purpose of the following article is to provide insight to ensure customers make realistic and informed decisions.

General Expectations for SaaS ERP

I firmly believe that one of the key reasons for failed ERP implementations is that expectations were not correctly established and managed throughout the implementation.   Consider the following:

Common Expectations of SaaS ERP

Common Expectations of SaaS ERP

 

  1. Cheap:  The customer does not need to make a huge expenditure to implement and utilize.
  2. Fast: Answer a few questions and have an up and running software in weeks.
  3. Flexible:  Business users can make changes.  Minimize IT involvement.
  4. Intuitive:  Quick to learn and easy to navigate.

We can all agree that the above targets are worthy goals of any ERP solution.  However, this is only part of the story.   The next section discusses the efforts required to achieve the goals listed.

Desired Results of SaaS ERP

To better understand ERP SaaS expectations we need to elaborate on the desired results that should be realized by customers. 

Elaborating on SaaS ERP Expectations

Elaborating on SaaS ERP Expectations

 

Some of the desired results are directly addressed by the SaaS model but the majority of results are addressed either by (a) the ERP software architecture or (b) the delivery model.   Example:  SaaS ERP does not require an initial outlay of funding for capital expenditures for hardware and related infrastructure.  SaaS ERP eliminates the need for a separate effort for ERP software installation and certification.  Yet, it is important to remember that ERP software installation represents at most 5% of the total time required to implement an ERP solution.  Therefore the SaaS model by itself does not have a dramatic impact on accelerating ERP implementations.

SaaS ERP Realities

Allow me to share some observations I have regarding the ERP SaaS model that may not appear to be readily evident:

SaaS ERP Realities

Let’s take one of the above desired results to elaborate on the above diagram.  A goal for SaaS ERP is to reduce the Total Cost of Ownership (TCO).  One of the key ERP design strategies is to enable business users to tailor the functionality to meet requirements without having IT to make a costly customization.  However, it is important to understand the shift of effort from IT to functional users.  There may be a reduction in the effort or a change in the nature of the work but the effort is still required.  There is no “push button” to eliminate this work. 

For another example let’s take the ERP value stream.  ERP vendors can create additional value to customers by providing new and enhanced functionality.   The leading SaaS ERP delivery model should provide a 3:1 ratio increase in the software release cycle.   Yet, it is important to realize that more frequent ERP software releases require additional testing and deployment (organizational change) work.  It is interesting to note that many of the leading SaaS ERP vendors do provide an out-of-the-box testing automation solution.  Again, the customer will experience a shift from technical to functional effort.

 Summary

Sorry if I burst your bubble, but I rather have an informed customer that will have reasonable expectations versus a customer with unrealistic expectations.  SaaS ERP is one of many delivery models that ERP vendors offer to customers.  While it is true that SaaS ERP provide customers with new options not available previously, it is not a slam dunk for all customers.  Developing the customer’s use case and understanding all technical and organizational impacts will better ensure an informed decision is reached.

Join the community! 10k followers across 100 countries!

Cloud ERP Strategy: Goodbye IaaS, Hello IaaS

One of the first deployment models for cloud computing was Infrastructure as a Service (IaaS).  Currently, there is a price war between the major IaaS providers like AWS and Rackspace to provide the cheapest infrastructure. However, enterprise customers looking to move their ERP solutions to the cloud should focus more on Integration as a Service (IaaS).  Integration, not infrastructure, will have a greater impact to TCO and ERP success.    In the next sections we will briefly compare the influences that infrastructure and integration have on an enterprise solution like ERP.

Cloud Infrastructure versus Integration

In a previous blog I reviewed the key competencies to consider as part of selecting an ERP cloud provider (ERP Cloud: Finding the Right Provider).  Both infrastructure and integration are key considerations yet I view enterprise integration the greater challenge.  Consider the following:

Cloud Infrastructure & Integration

Key Cloud Consideration Factors

Cost

The cloud storage war appears to be getting the most press in cloud computing but consider two factors driving this type of pricing strategy

  1. Vendors cannot provide a material differentiation or competitive advantage.
  2. Technology improvements continue to drive down disk storage costs rapidly.  Combine this trend with the economy of scale that cloud providers generate to continue driving costs down by another 40% in the next 3 to 5 years.

Moore’s Law highlights the computing hardware trend resulting in greater technology capabilities and driving down MIPS costs.  However, the same cannot be said for integration.  As discussed in one of my earlier blogs (Best of Breed vs. Integrated ERP), integration costs can be up to 8 times the cost of the ERP software. 

ERP Integration Considerations

ERP Integration Considerations

We have all heard the proverb “A chain is only as strong as its weakest link.” Applying this concept to business software, we would conclude that a business solution is only as strong as its weakest integration.

Business Value Realization

Allow me to make the general statement that outsourcing IT infrastructure to a cloud provider should result in a cost savings to customers.  However, I believe that IT organizations will quickly learn that providing this cost savings is a short-term value proposition to their business owners.  Ultimately, IT-driven innovation will drive business value realization.  Gartner identifies Integrated Ecosystems and Hybrid IT & Cloud Computing as two of the top 10 strategic technologies for 2013.     Every ERP solution has a portfolio of edge products/3rd-party integrations to external solutions to provide holistic support of business processes.  The only true method of creating business value is through business processes.

Socialization & Collaboration

The ERP software industry is realizing that people have the greatest impact on business results.  It is refreshing to see the increase in socialization and collaboration capabilities.  Infrastructure is necessary but integration is the critical path to success.

Market Trends

In my opinion, I expect to see the market changing for IaaS providers.  Given how important integration is to a viable cloud solution either existing IaaS will grow into a Platform as a Service (PaaS) or will be acquired by PaaS vendors looking to provide global support.   Just take a look at AWS and Rackspace’s transition from an IaaS to a PaaS:

Summary

History always has a way of repeating itself.  Recalling the Y2K problem, storage (infrastructure) was seen as a strategic/limited resource.  This view resulted in the programming practice of representing the year with two digits and we all know how that came back to haunt IT organizations.   Infrastructure is a cheap commodity when compared to a collaborative, enterprise integration framework.  Infrastructure is a key enabler for cloud computing but integration will ultimately determine your success of ERP in the cloud.   

Join the community! 10k followers across 100 countries!