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.

Advertisements

BPR, BPM and ERP

I had a customer ask me about the relationship between BPM and ERP.  Does ERP implement BPM or do you need to have BPM before ERP?  Is an ERP implementation a BPR project?  Who’s on first?  As the ERP industry evolves it has become evident that additional disciplines like Business Process Management (BPM) and Business Process Reengineering (BPR) must be employed for a successful ERP experience.  In the following blog posting I plan to define and demonstrate the roles that BPM/BPR play in the ERP lifecycle.

BPR, BPM, and ERP Revisited

Allow me to establish some basic definitions for our discussion:

  • Business Process Management (BPM) consists of methods, techniques and tools to design, deploy, control, and analyze operational business processes involving humans, organizations, applications, documents and other sources of information.
  • Business Process Reengineering (BPR) is the redesign of business processes – and the systems, policies, and organizational structures that support them – to optimize the work flows and productivity in an organization.
  • Enterprise Resource Planning (ERP) is integrated business software that supports multiple business functions across an enterprise.  ERP implies the use of Commercial Off-The-Shelf (COTS) packaged software rather than proprietary software written by or for one customer.

There are a couple of key concepts we should review to compare/contrast BPR and BPM.

Compare BPM and BPR

Compare & Contrast BPM & BPR

BPM focuses on the business process model to monitor, identify, and implement incremental improvements.  These improvements or eliminations fall within the fundamental rules, parameters, and culture established by the existing business model.  However, there comes a point in time where the law of diminishing returns applies and a transformation to the underlying business model is required.  A more aggressive approach like BPR must be utilized to evolve to the next level of business process maturity.  Consider the following illustration to demonstrate how BPM and BPR interact along the Capability Maturity Model Integration (CMMI):

 

BPR, BPM within CMMI

BPR, BPM within CMMI

Allow me to provide an example.  Company A performed a CMMI assessment of their purchasing process.  Results from the assessment showed that the purchasing process was defined for certain business sales (revenue stream) but not for all purchasing events (direct & indirect).  Another key finding was that there was no formal integration between demand planning, supply planning and purchasing which resulted in reactive purchasing. From the above CMMI reference, it was determined that Company A’s purchasing process is at the Managed level.  Company A implemented several incremental initiatives (BPM) to improve process execution including documenting purchasing tasks for all purchasing events and conducting periodic purchasing planning meetings with operations. 

Company A realized process improvement yet the value was limited by following model constraints: (1) each revenue stream (business line) had its own unique purchasing process & rules and (2) Purchasing had limited visibility across the entire supply chain.  Two fundamental mindsets have to change:

  1. Move from unique purchasing processes to a common enterprise purchasing model that is flexible enough to address the competitive requirements for each business line
  2. Enable Purchasing to have visibility across the entire supply chain to support a process-oriented management model versus a function-oriented management model.

Implementing these changes will require a formal, projectized (BPM) effort that will redefine existing business rules, culture, and business process activities.   As Company A continues to evolve their purchasing process they will conduct both BPM within the CMMI maturity level and BPR as they move to the next CMMI maturity level. 

How Do BPR, BPM, and ERP Relate?

ERP provides the automation of business activities.   There are two fundamental value propositions that ERP provide to customers looking to move up the CMMI maturity model

  1. ERP reduces the effort required to perform tactical business activities so customers can focus on strategic activities. Expanding on our purchasing example, this would include basic functionality like automating the creation of purchase orders, approving purchase orders, and matching purchase orders with receipts & supplier invoices.
  2. ERP provides the opportunity for visibility across business functions to support business process management.  That said, there are several factors that determine the level of visibility. 
ERP Business Process Visibility

Factors Impacting ERP Business Process Visibility

A competent ERP solution should provide robust, closed-loop integration between the functional modules provided out-of-the-box.  As a practical note, there is always a need to integrate ERP to legacy systems and this requirement should be not overlooked.  A business solution is only as good as its weakest integration.  Process consistency will enable a relevant comparison of results and management of business processes.

A mature ERP solution should provide automation and integration support for both tactical and strategic business activities across the CMMI model.   

ERP Evolution within CMMI

Interaction of BPR, BPM, and ERP within CMMI

I am a firm believer that business should lead and technology supports.  Therefore, as the business model evolves it is important to identify the corresponding ERP functionality to support the business activities.   This model also communicates that the best approach to implement ERP is to follow a logical maturity path for business processes.

Common ERP Misconception and Mistakes Related to BPR & BPM

Allow me to address some common misconceptions and mistakes made during ERP implementations related to BPR and BPM.

BPR is part of the ERP implementation.

While I agree that the initial ERP implementation will result in major changes with existing business functions, BPR will not happen unless there is a concerted effort to redefine the holistic business model and organizational structure to be successful with the ERP software.

Implementing ERP will give us BPM.

The direct answer is no.  ERP does provide an information foundation that can support BPM.  BPM is more about a discipline for managing processes and less about software. 

Do I need ERP to mature my business processes?

Technically speaking, ERP is not a hard requirement for BPM.   However, manual routine tasks and limited visibility hinder strategic activities.  ERP can play a key support role in automating business tasks and provide visibility through integration.

Should I implement ERP features that support business activities at different maturity levels?

Business realities will necessitate that customers implement ERP features supporting different CMMI maturity levels.    The problem lies in two areas:

  1. Customer expectations are not appropriate set regarding the limited value realized from mature ERP functionality due to less mature business activities supporting strategic activities.  Example:  A procurement process scorecard measuring standard Key Performance Indicators (KPIs) will have limited value if there is not a standard, enterprise procurement process.
  2. Implementation partners and business solution advisors should provide a short-term strategy and roadmap to evolve the supporting business activities to same level of maturity.   This approach provides a “quick-win” opportunity for customers to drive additional value from the existing ERP investment.

Summary

Understanding how BPR, BPM, and ERP should relate to one another can be a challenge.  Some believe that it is an “either or” proposition.  I do not subscribe to this school of thought but rather believe that BPR and BPM are disciplines that should be interweaved as part of your ERP application strategy.  Knowing and appreciating these interdependencies will put you in a better position for ERP success. 

%d bloggers like this: