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.

Advertisements

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.

Business pain can be good for ERP

Instinctively, we all try to avoid or minimize pain.  This is true for individuals as well as business organizations.  However, in our attempts to reduce pain, we too often focus on eliminating the symptoms without addressing the underlying root cause.  We may feel temporary relieve but our short-term decisions only lead us to a point were the pain resurfaces and the available options to address the pain become more limited and costly.   In the next sections, we will discuss how to address business pain by effectively utilizing your existing ERP investment.

Step #1 – Take an appropriate problem solving approach

Following is a standard problem-solving approach as defined in the Project Management Institute’s Body of Knowledge (PMBOK).

Root cause analysis

Root Cause Analysis

Seems easy enough!  The challenge I’ve observed is that many organizations do not execute the problem-solving process effectively.  To compound this challenge many customers believe that having an ERP system somehow accelerates or simplifies the problem-solving process.  Following are some of the common misconceptions that cause ERP customers to miss the mark in solving problems.

Missing the Mark

Missing the Mark

The misperceptions and inappropriate expectations surrounding ERP can cloud your view of the real problem.  However, the greater hindrances to effective problem solving are the views that (a) pain is bad, and (b) quick-fixes are more desirable (demanded) than permanent solutions to business problems. For an ERP perspective, the typical end-result to quick fixes will be more customizations.  Greater customizations result in less flexibility and more costs. If unchecked, your organization can build band aid fixes on top of one another,which may ultimately result in a catastrophic event.  The key to eliminating this quick-fix mentality is to change the perspective of how pain is viewed.

Step #2 – See business pain as an opportunity

My daughter loves to play volleyball.  Recently, she has experienced some pain with her ankles as well as experienced some falls that caused my wife and me to have concerns.  I suspect that I’m a little over-sensitive given that our daughter has Type-1 diabetes.  We took our daughter to see a sports physician specialist to identify the problem.  “Your daughter has a good problem to have.,” said the specialist, “she is still growing!  Your daughter is still figuring out how to coordinate her changing limbs.”  Whew!  What at relief yet what a good life lesson.  Too often, organizations can’t see past the present pain. We focus only on the symptoms (negatives) without looking for the opportunities (positives).

Many times, IT organizations are motivated by addressing problems by taking a “triage” or ‘fire-fighting” mentality.  IT performance metrics can support this mentality if the focus is only on cycle-time and response-time metrics.  Don’t get me wrong, if a production system goes offline unexpectedly, you can bet that a quick response is warranted.  A red flag to look for is when ERP support problems are seen as an inconvenience rather than an opportunity.  This can be especially frustrating to IT when the problem is a recurring issue.  When viewed as a hindrance there is the natural human tendency to deal with the issue as quickly as possible to move on to the next problem. To get out of the above support rut  first we need to eliminate or minimize reoccurring problems through effective problem solving.  Once performed the IT organization can spend the time to evaluate viable options for greater ERP value generation.

Step #3 – Use business pain as a driver to increase ERP value generation

During my career as an ERP consultant, one of the key challenges I faced with every one of my customers was how to drive additional value from their ERP investment.  As I did additional analysis, a common theme across my customers was that they did not realize the rapid deployment of new ERP functionality.  Based upon my experience, I have identified the top three strategies that support long-term, rapid delivery from ERP.

Strategies for Rapid Delivery via ERP

Rapid Deployment Strategies for ERP

As seen from the illustration above the single largest driver for long-term, rapid delivery of addition value from a customer’s ERP investment is frequent upgrades. However, in the effort to address tactical business pain quickly IT organizations built customizations as quick fixes instead of allowing these opportunities to drive the value proposition for an ERP upgrade.  It is important that the internal IT organization resist the temptation for a quick win and illuminate the IT roadmap that will provide the opportunity for greater value from their ERP investment.  In the next section, we will briefly discuss the price to be paid if one uses ERP as a means to a quick fix.

 The price of ERP quick fixes

There is a price associated with every decision made.  In the case of ERP, the short-term gains will eventually result in limiting your ERP strategy.  ERP quick fixes are typically implemented as customizations.  Customizations require a greater level of support from the customer’s IT organization (because ERP vendors do not support customizations).  IT spends more time performing support activities (indirect business value) versus building new enhancements (direct business value).

Second, customizations add to the upgrade effort.  Third – and most important – performing quick fixes send a signal to customers that counters the basic value proposition of ERP (packaged) software.  The price of ERP quick fixes may be small at first but they will have a compounding effect on the Total Cost of Ownership (TCO).

 Summary

Pain is the way our bodies (and organizations) communicate that something is wrong.  It defines the gap between where we are and where we want to be.  Effective root-cause analysis is the first step to correctly diagnoses the pain and identify viable solutions.  ERP can play a positive or sometimes negative role in addressing business pains.  The key to understand how to correctly apply ERP technology to transform business pains into opportunities for greater business value.

%d bloggers like this: