ERP Utilization Series: Minimize Stabilization Phase

Topic:  ERP Utilization Series: Minimize Stabilization

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. 

Advertisements

ERP Utilization Series: Automating ERP Utilization Guidance

In the previous post, I discussed a new repeatable method for calculating ERP utilization. In this post, I will define a case study where the 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.Slide1

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.

Slide2

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.

Slide3

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:

Slide4

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

Slide5

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.

Slide6

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.

The Science of Cloud ERP Utilization

There are not many public theories 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 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.

Before we jump into the model there is a fundamental assumption that must be addressed.  First and foremost, services trump software in an ERP cloud delivery model.  If the customer does not have any reliance or trust on the available ERP services, the window for greater ERP utilization is exponentially reduced.  Given the assumption that the ERP Cloud vendor provides a competent level of cloud ERP services (prerequisite), I will explain my theory on ERP utilization.

ERP Utilization Is More about Enablement and Less about Automation

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

Business Solution DefinedJust as technology has the smallest part to play in ERP implementation success, ERP software has a smaller role to play in ERP utilization.   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).

The reasons why I selected CMMI as the business process maturity model are (1) general adoption and acceptance, and (2) business process maturity characteristics can be observed.  I appreciate the fact that CMMI primarily focuses on software development activities and unfortunately ignores business process re-engineering.  However, I believe that the CMMI model as effective model to elaborate on my themes on ERP utilization.

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.  Organizations change one person at a time and if every person has the capacity to be a change agent, then naturally the organization will adopt and manage change faster.  OCC is an emerging model, thus there is limited content regarding how to assess and measure OCC for an organization.

If an organization has to wait on an ERP Cloud vendor or a Systems Implementation (SI) consultant to provide guidance on ERP utilization strategies then there is a high probability that the organization will never reach their ultimate goal of effective ERP utilization.  The organization’s ERP experience will be more reactive than proactive.

With all that said, consider the following conceptual model:Model for ERP Utilization

Linear Regressive Model for ERP UtilizationI 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 greater influence than CMMI 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:

Actual Versus Model

Actual Versus Model

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 business process maturity and organizational capacity change values.  Consider the following:

ERP Utilization Model Value Set

Potential Values for CMMI & OCC for ERP Utilization prediction

Key Points and Observations:

  • Big areas in red 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.

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 the ERP 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

I propose that long-term ERP utilization should be a series of incremental quick-wins (i.e., Business Process Management) and paradigm shifts (i.e., Business Process Re-engineering).  Consider the following illustration:

Linear Relationships with ERP Factors - revised

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 (i.e., Set X).
  • 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 (i.e., Set Y).
  • Set Y includes the BPR 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).
  • A radical approach like Business Process Re-engineering (BPR) is required when deploying new features across multiple CMMI levels for a given business process.
  • Set X includes the BPM enablement activities and ERP feature(s) deployment required to align with the logical maturity path.

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.

Leveraging the CMMI model as an example of business process maturity, there are incremental organizational change required to process from one maturity level to the next level.  However, based upon my experience, there are two key paradigm shifts that must happen in the collective mind of the organization.  Consider the following illustration:Paradigm Shifts for ERP Utilization

Paradigm Shifts for ERP UtilizationKey Points and Observations:

  • Z represents the paradigm shift from a functional business function focus to a business process focus for organizational optimization.
  • Z’ represents the paradigm shift that competitive advantage only comes from revenue-generating business processes.  Organizations have a limited amount of resources and should prioritize business process maturity priorities accordingly.
  • By definition, organizational paradigm shifts required a Business Process Re-engineering (radical) effort.

Next, I will elaborate on why these paradigm shifts must happen within the CMMI maturity model.  Let us refer back to the specific level definitions within the CMMI model:CMMI Level Characteristics

CMMI Level CharacteristicsI conclude that a prerequisite for a business process to mature to a CMMI level 3 (Defined) requires the organization to acknowledge and manage across multiple functional areas (Z).  The ability to be more proactive requires a robust communication and coordination of business activities across multiple functional departments.  It signifies the first step of an organization to evolve from the traditional management philosophy of “division of labor”.

The next paradigm shift (Z’) requires the customer to understand that (1) some business process (es) are more important than others (i.e., revenue-generating vs revenue-supporting), and (2) an organization has only so many resources (constraint).  As we move forward in a hyper-competitive market environment, additional pressures will continue to minimize costs.  The model states that all business processes can mature to a CMMI level 5 but the cost realities suggests a greater focus on the competitive, revenue-generating business process (es).

Speaking from practical “hands-on” experience, if customers never breaks through these paradigms then the customer’s Cloud ERP experience will be frustrating rather than enabling.  There is no such thing as a “steady state” for Cloud ERP.  Either the customer is moving forward with deploying new ERP Cloud features or fixated on the limitations of their ERP Cloud services.

Summary

Even with a cloud delivery model, the key cost associated with ERP has 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 a 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 have cast the first stone – let’s see what evolves from the ripples in the pond.

%d bloggers like this: