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 80% 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 Defined

Just 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 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 a 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:

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

ERP Uilization Roadmap

ERP Utilization Roadmap

 

Key points and observations:

  • Any deployment of ERP features that require a significant organization change is not a quick win. People do not change overnight.
  • An incremental approach like Business Process Management (BPM) is required when deploying new ERP features at the same CMMI level for a given business process.
  • Set X includes the BPM enablement activities and ERP feature deployments required to align with the logical maturity path. Note that only incremental change is required to implement targeted ERP features (thus, a quick-win).
  • 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 Y includes the BPR 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 Utilization

Key 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 Characteristics

I 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 maximum ERP utilization.  I have cast the first stone – let’s see what evolves from the ripples in the pond.

 

Advertisements

ERP SaaS 101: Services Trump Software

How many ERP SaaS offerings are in the market today?  The number depends on who you ask but it is a fair statement to say that all Tier I and the majority of Tier II ERP vendors have a SaaS offering.  A majority of the market and many ERP analysts still take an on-premise approach to evaluating ERP SaaS offerings.  Services, not software, will have the greatest impact on ERP SaaS success.  The purpose of this article is to examine the impact services will have in a SaaS model.

Installation Is Not an Implementation

Ah, the battle cry of ERP SaaS “You can be up and running in a matter of minutes!”  Now, it is a fair statement you will have a running system but it is a far cry from a configured business solution.  Consider the key activities required for this transformation:

SaaS Implementation Services

SaaS Technical Services

Even though ERP software and infrastructure can be provided in an accelerated fashion, the business value realization of an ERP SaaS model can only be achieved through the effective delivery of technology services.   SaaS ERP is not a push-button solution.  I submit that technology services should have an equal or greater emphasis on ERP SaaS selection than ERP SaaS software. 

Great Services Can Cover a Multitude of Software Gaps

ERP SaaS software installation is a very small step in ERP SaaS experience.  Consider the following illustration:

ERP SaaS Solution Lifecycle

ERP SaaS Lifecycle

Following are a few points I would like to elaborate.  First, installed ERP software does not provide any business value own its own.  Business value is only realized when software is configured and implemented in a production environment.   Second, let’s not forget that an ERP SaaS model is outsourcing technical services to the ERP vendor.   Third, ERP SaaS software release cycles will be at least three times faster than traditional on-premise ERP software.  That means that a SaaS software model will address gaps in a shorter term.  As more customers look at SaaS ERP I believe that services not software will be the emerging competitive differentiator. 

Majority of ERP SaaS Offerings are Non-Competitive Differentiators

For purposes of this discussion please allow me to broadly categorize business processes into three areas:

ERP supporting business models

ERP supporting key business process groups

There are some key concepts that should factor in the ERP SaaS selection process.  First, competitive advantage only comes from revenue-generating business processes.  For example, would having the best of breed solution for SOX compliance enable you to gain market share?  Also consider if you would highlight your Payroll system as a competitive advantage to your customers. A best practice is not a competitive practice.  Organizations, just like individuals, cannot be the best in everything but it makes sense to be the best in your revenue generating activities.  A best-of-breed SaaS solution is of little value if the ERP SaaS provider does not provide competent technical services for reliable integration across multiple environments.

Summary

Too often we focus on the cart before the horse.  I believe that we are experiencing this misalignment with the emerging ERP SaaS market.  The best ERP software is of little value if you cannot implement a viable, manageable solution.  Technical services provided by the ERP vendor’s SaaS operations will have the greatest, long-term impact for business success.  Pick an ERP vendor that will focus on improving both their ERP software and SaaS technical services.

ERP Project 101: Deployment vs Requirements Gathering

Customers, System implementers and ERP vendors are always looking for ways to accelerate ERP implementations.  One popular approach is to take a phased deployment approach based upon criteria such as location, ERP module or feature set.   Requirements are gathered, validated, and tested based upon a limited scope.  Unfortunately, many ERP projects utilizing this approach result in failure given requirements conflict and misaligned expectations.  In the following blog posting we will discuss how to minimize challenges associated with phased ERP deployments.

Reality Check!  There will be ERP requirements conflicts

A reality with any cross-functional or multi-site deployment is that there will be requirement conflicts as part of an ERP implementation.  In our focus for rapid results and simplifying ERP deployments we forget the fundamental result – an ERP implementation is the implementation of a business solution.  Consider the following illustration:

ERP REquirements Conflict

Example of Requirements Conflict for ERP

Let’s assume that we want to accelerate an ERP HR implementation by deploying ERP solution by region.   To further streamline our efforts the project only gather requirements from the North America HR stakeholders (Phase I). The above approach appears to work for the initial ERP deployment; however; these short-sighted decisions can have a negative impact to future deployments.   Remember that correcting problems and limitations are more costly once an ERP system is deployed in a production environment. 

With the above said, I appreciate that ERP vendors are evolving their ERP software to provide additional flexibility in configurations to allow variances based upon industry, line of business, country and even user preferences.  However, we should understand that all ERP solutions leverage a common data model with specific data dependencies.  We can address this constraint in one of two methods.  Either we take a risky approach of gathering requirements in silos hoping that we clearly define all ERP configuration dependencies or take the practical approach of gathering requirements across all HR operational areas. In the next section we discuss several practical steps to ensure requirements conflicts are minimize.

Practical Steps to Minimize ERP Requirements Conflict

Let’s brief speak to some common-sense approaches to deal with the reality of ERP requirements conflicts.

How to address ERP requirements conflicts

Practical approaches to address requirements conflicts

The first step of requirements management is to perform a stakeholder analysis to identify the appropriate business owners and subject matter experts in include in requirements gathering.  It is important to note that we always implement to a business process not simply to the software (ex. module, feature). Utilize solution modeling to analyze business requirements from multiple perspectives.  Too often I observe ERP projects spend more time on defining exceptions to standard business scenarios versus defining a common requirements set that can be leverage to isolate and manage unique requirement criteria.  Consider the following illustration:

 

Logical Business Requirements Model

Logical progression of gathering ERP requirements

There should be a logical progression of business requirements from the global level to the specific user level.  Isolate requirement exceptions to effectively quantify frequency, impact, and cost.  Utilizing this approach will provide the customer with greater insight for an informed decision.   Finally, let’s not forget the Lean principle that states process efficiency is gained when variability (exceptions) is minimized.

Summary & Conclusion

The ERP industry is hyper-competitive where every ERP vendor and System Implementer is looking for an edge to accelerate and reduce the costs associated with ERP implementations.  This desire is intensified by the entrance of ERP SaaS offerings with lower entry costs for a growing target market.  The challenge is to identify competent options for accelerating ERP implementations without putting long-term customer success at significant risk.  Requirements management (gathering, validating, and testing) is the critical discipline that impacts all downstream implementation activities.  Taking a technology-oriented approach results in (a) unclear requirements, (b) requirements conflicts, and (c) additional rework to support future deployments.  Making the right investments in requirements management will be the best chance to accelerate downstream activities including deployments.                    

ERP Cloud: Finding the Right Provider

I recently attended Oracle’s OpenWorld Conference in San Francisco this October.  There was a huge volume of information on the Cloud.  As I walked through the Exhibitor’s halls at the Moscone Center, I observed that every SI partner had ERP in the Cloud or could get customers to the Cloud seamlessly.  What I did not see is any offering or advisory service to guide ERP customers through the storm clouds to find the right provider.  In the next sections we will discuss the key competencies to consider as part of making an ERP Cloud provider selection.

Capabilities for ERP Cloud Providers

ERP Cloud Provider Key Competencies

Hardware Competence

Typically, this is the first area that customers think of when evaluating Cloud providers.  For this discussion, hardware includes servers, processors, network, processors, and storage.  Now, I may be chastised by my technology peers but I take a very practical approach to hardware.  Business users are more concerned about technology results (reliability, response, availability, scalability) versus what hardware configuration is being used.  I’m all for engineered solutions if they provide a material impact to technology results.  I would not consider millisecond improvement on response time as a material impact on response time nor would I pay an additional $100 per hr /month for special hardware.  Remember to keep the end in mind – you are moving an ERP solution to the Cloud.  Review and identify Cloud providers that offer hardware configurations that best aligns to the hardware specifications and recommendations made by ERP software vendors.

Software Competence

For this discussion, software competence focuses on software and standards that enable a viable Cloud solution.

Selecting Cloud Providers - Software Considerations

Selecting Cloud Providers – Software Considerations

For brevity sake, we will focus on a few of the key software enablers for the Cloud.

Software Area Considerations
Open Standards & Technology Open Standards promotes interoperability and data exchange among different products or services and are intended for widespread adoption.  This area will be a key enabler (and indicator) of portability.
Integration A viable ERP Cloud solution must provide a robust toolset for integration back to the customer’s on-premise supporting systems.  Integrations can be a potential point of failure that must be addressed with a cost-effective solution.  Cloud + Poor Integration = Failure. 
Load Balancing Load Balancing is vital for effective distribution of work across a multi-tenant hardware environment.   Optimal resource utilization, maximize throughput, minimize response time, and avoiding overloads are not possible without a robust load balancing capability.  Be leery of simple load balancing algorithms like random choice or round robin.
Virus Protection Viruses can live in the Cloud.  Malware known as Crisis can infect VMware virtual machines.  Moving to the Cloud does not end the need for antivirus protection.
Virtualization Virtualization is a key enabler for Cloud computing.    In order to realize the technology benefits associated with virtualization, Cloud providers must be able to provide a robust solution for the following capabilities: Elasticity – dynamic scalability is an integral feature (enabler) for agility and fundamental IT cost savings. Logical isolation for data protection. Hypervisor management for VMs.VMs replications.
ERP Software Not all ERPs are created the same for the Cloud.  Following are areas to review in determining how “Cloud-Friendly” is your ERP solution.     Single-Tenant vs. Multi-Tenant – Single-Tenant provides a more formal logical isolation for customer data.  Multi-Tenant reduces duplicate upgrade efforts and technology resources. SOA Compliance – How well does your ERP solution expose methods and related data components to external solutions via SOA services? Network Latency – High data volume transfer between Cloud server and the on-premise client. ERP Experience – Also ask if the Cloud provider has “hands-on” experience with supporting your ERP solution. A leading Cloud provider will have a competent level of technical support knowledge for your ERP software.

 Security Competence

Security is a key selection criterion for Cloud providers.  A realistic expectation is that Cloud providers should have a greater level of security than your current on-premise IT environment. Following is an illustration of the key security areas you should consider as part of your ERP Cloud provider. 

Cloud Provider Selection - Security Considerations

Cloud Provider Selection – Security Competence

 There are three key areas that I would like to further discuss.

  1. Identify Relevant Security Standards:  Viable Cloud providers should be able to assist their customers in identifying and applying relevant security standards for their specific industry.  
  2. Security Validations:  Leading Cloud providers are able to demonstrate their security competence via (a) audit and evidence gathering, (b) providing security audit findings for customer review, and (c) enabling customers to perform independent security audits if desired.
  3. Data Encryption:  Encryption of customer data either in transit or at rest should be a non-negotiable requirement for Cloud providers.

 Value-Add Partner Network Competence

 Every ERP solution has a portfolio of edge products/3rd-party integrations to external solutions.  It stands to reason that customers should consider the portfolio of ERP edge products that a Cloud provider can host as part of the selection process.

Cloud Providers - Value Add Partnerships

Cloud Providers – Value Add Partnerships

Selecting a Cloud provider is not a short-term relationship so ensure that you can grow and generate greater value from your ERP investment within the Cloud.

Services Competence

A strategic competency that I feel is being overlooked in the Cloud market is the service portfolio that a Cloud provider should deliver.   Consider the following reality check: 

Reality Check for ERP Cloud

Reality Check for ERP Cloud. Used by permission.

Technology is only part of the solution.  What is the value of providing new ERP features if end users are not formally trained?  Who will perform regression testing for both technical and functional upgrades?  In my mind, a leading ERP Cloud vendor should provide both an automated testing solution and on-demand training solution to facilitate rapid deployments.   Cloud providers should have a services framework such as ITIL or ITSM.  This is a validation that your Cloud provider is committed to delivering reliable professional services.

Summary

Overall, I am very excited about the opportunities that Cloud can offer to existing ERP customers and potential customers who could not afford a Tier 1 ERP solution.  Yet, we must not forget that there are advantages and challenges that we must address in order to provide a reliable solution for ERP customers.  It is also important that we keep realistic expectations for the Cloud.  Cloud is more about a new way of delivering computing resources versus being a new technology.

P.S.  If you are interested then the blog author will conduct a webinar: Best Practices for Selecting the Right ERP Cloud Provider.  Overview – Next stop: The Cloud! Everyone is talking about it but there is a fog of disjointed information out there regarding moving to the Cloud. In this webinar we will demystify the cloud and discuss one of the key activities customers should carefully consider in moving to the cloud – selecting the right cloud provider. We will also discuss some of the key factors to consider as part of your cloud deployment strategy. Register at http://www.oracle.com/go/?&Src=7604459&Act=251&pcode=WWPN12035291MPP257 .

 

SI Partner for PeopleSoft/Fusion ERP

Blog Sponsor – Cardinal Point Solutions, LLC.

%d bloggers like this: