ERP and KPIs

When asked, just about every ERP vendor will say they provide Key Performance Indicator (KPI) reporting.  Yet there still remains confusion between metrics reporting and KPI reporting.  Unfortunately, using terms like KPI and metrics interchangeably does not help.   In the following blog cast and posting I will provide practical guidance regarding KPIs and the role ERP play in supporting KPI management.

Let’s expand upon the above blog cast.  Another method to identify KPIs is to take a bottom-up approach.  Consider the following illustration:

In this scenario, we have a defined scope (i.e. business process) where we desire to improve business process performance from a Capability Maturity Level Integrated (CMMI) level 3 to level 4.  Allow me to simply summarize the key characteristic of CMMI levels 3 and 4:

  • Level 3: The specific business process has “best practices (i.e. common) deployed.
  • Level 4: The management of the business process is data-driven.  Decisions are based on facts.

First, KPIs should be our focus at the end of the performance gap requirements analysis.  The first area should be understanding the organizational change required to mature to a CMMI Level 4.  Becoming a data-driven organization does not happen at a “flip of a switch”.  ERP users and business leaders must trust the ERP solution and building that trust requires time and ERP reliability. 

Second, request the ERP vendor to provide the ERP feature set (i.e. features, reports) that will enable our business process to mature from a CMMI Level 3 to Level 4.  If the ERP vendor cannot provide us with this information then I would question how “invested” is the ERP vendor in assisting us in being successful.  There is a vast difference between an ERP vendor and an ERP partner.  A true ERP partner should be able to easily provide this information (sorry for the tough love).

Third, identify all the relevant operational metrics that we can leverage in monitoring business process performance.  Again, the ERP vendor should be able to provide the metrics and Out-Of-The-Box (OOTB) reporting.

Finally, identify the subset of operational metrics that we will actively manage as KPIs.  Practical guidance I give to my customers is that you should have no more than 3 KPIs per business process.  KPIs are metrics that we actively manage.  KPIs should ONLY be forward looking, in my humble opinion.  Now please do not misunderstand me that I suggest we disregard lagging and trending indicators.  I typically use a car analogy with my customers regarding KPIs and lagging metrics.  My dashboard window represents my KPIs.  KPIs are forward looking.  KPIs should be tied to an incentive compensation plan.  KPIs should be a stretch goal and not “status quo” maintenance.  Just with the rear-view mirror and side mirrors in a car, operational metrics are artifacts we need to view on an “exception” basis.  It is important that we have an ERP solution that can establish an acceptable range for operational metrics and provide OOTB reporting on performance exceptions.  This is a reasonable expectation of any competent ERP vendor.

Key Capabilities ERP can provide to identify KPI performance gaps

Recall the question I asked in the blog cast “What if ERP could automatically identify the gaps?”.  Having done this activity using traditional methods (i.e. manual), following is what I would consider as the foundational requirements that will enable ERP to provide a preliminary KPI gap assessment:

This is by no means a comprehensive list but it does highlight some of the “critical path” requirements that we can use to evaluate how committed are ERP vendors to customers’ operational success.

Summary

I download an app on my iPhone called “36,000 KPIs”. 

Now, the appropriate name should be “36K Metrics” but I digress.  It is a neat little (free) application that provide a definition of the metric.  I cannot speak to the complete accuracy but it is a good reference that I have utilized as a metrics dictionary.  The point to make here is that competent ERP solutions must provide a comprehensive set of operational metrics that can be utilized for exception and KPI reporting. Without metrics, one will have a hard time defining performance baselines. The greater the OOTB ERP metrics provided to your business, the more flexibility one has in business process management and strategies. 

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. 

Join the community! 10k followers across 100 countries!