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 & 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

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. 

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.   

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. 

ERP Makes for an Expensive Custom Solution

The Allure of Technology

Think of the possibilities!  Rapid delivery of new functionality!  Reduce development cost by quickly deploying prebuilt solutions!  If the software does not meet your needs then use the delivered, user-friendly development tools to customize the ERP software.  We have the technology to make your business more flexible and adaptable.  Most customers do think about the possibilities quickly but have a hard time taking that vision and incorporating it into the realities that are involved with using ERP.

The Challenge: Customer Expectations Not Aligning with ERP Strengths

A key area that causes conflicts during an ERP implementation is the misalignment between the customer’s expectation of business software and key ERP value drivers.  Consider the following illustration.

ERP Advantages and Challenges

 

It is important to understand the customer’s business owner/user expectations of enterprise business software. If customers expect ERP to adapt to current business activities then there is an increase risk of developing a custom solution that cannot support the fundamental value drivers for ERP. When an organization makes the decision to implement ERP they are making the decision (consciously or unconsciously) to realign business processes with delivered ERP functionality. This is a significant mind shift for key business owners and end users! It’s not a “light switch” that you can turn on and customers think differently. There must be an evolutionary process to better align customer expectations with ERP strategy and direction. Let me provide a real life example to further elaborate.

The No Win Situation

I was a functional consultant for an ERP implementation to replace a customer’s legacy time reporting system. The customer’s process consisted of Microsoft Excel spreadsheets coupled together with a data load process to a custom staging table for time approval and payroll processing. When I started working with the customer to define their business requirements it was apparent that there was a difference between executive and business stakeholder expectations. The payroll manager insisted on having the exact functionality that they current have in their systems today. I knew that no matter how good our developers were we would not be able to cost-effectively build Microsoft Excel flexibility into the ERP software. It would totally invalidate the justification for going with an ERP software solution in the first place. The payroll manager was used to getting exactly what they wanted from software to the point where software replaced the need for training (ex. dummy-proofing). I did an initial gap analysis and identified over twenty (20) gaps that required changes to the ERP software.  Addressing the gaps via software would require additional resources (costs) to design, develop, test, and implement software changes.  In addition the customer would have to allocate resources to re-analyze their software changes against new ERP software updates.  These activities will reduce the ability of rapid delivery and increase Total Cost of Ownership (TCO).

I came to the realization that if I proceeded with a traditional approach to gathering requirements that (a) I would spend a lot of wasted effort gathering non-value-add business requirements and (b) the fit/gap session would be much longer than planned, (c) and I was in a non-win situation unless I changed the game. If I provided a custom software solution then I would have a happy payroll manager but I would have disappointed executives because the ERP solution increases costs. On the other hand, if I ruled out customizations and only used delivered functionality then I would get happy executives and an upset payroll manager! The only way I could be successful was to move from a traditional requirements and implementation approach to a new approach that addresses the realities of using ERP.

Source: SEI Evolutionary Process for Integrating COTS-based Systems

 

The approach I took was to reset software expectations. I met with the payroll manager to discuss the reasons for selecting ERP software and the inherent advantages and disadvantages with ERP software. This was not a one-time discussion and required several additional discussions with the entire project team. In the end the payroll manager’s expectations were adapted which enabled us to accelerate our fit/gap session. We still identified a few gaps. Of the three gaps we negotiated to have only one addressed via a software change and the other gap was handled via training. Our negotiations resulted in a significant reduction of effort and were only made possible by establishing the right environment for effective negotiating. If either party has unrealistic expectations then effective negotiations will be extremely difficult.

Summary

The fundamental design of ERP is to provide a common software solution across a broad customer base. ERP is maturing to enable more custom capabilities via configuration, but the fact remains that ERP can make for an expensive custom solution. The marketplace has realized that ERP requires a different implementation approach (ex. Software Engineering Institute’s EPIC methodology). Consider the drivers for purchasing an ERP software package. What was the business justification for purchasing packaged software? Remember that ERP targets customers across multiple geographic locations and industries. Two key implied statements that executives make when they select an ERP software solution are (1) having a custom software solution is not strategic to the organization, and (2) we expect our organization to adapt to the ERP software – specifically non-competitive, non-strategic areas. Strong words I know, however, I have seen a lot of grief and anxiety created during packaged implementations because this message was not clearly articulated to the project team and the organization.

The software vendor, implementation partner (consultants) and the customer’s IT department have the opportunity to play an important advisory role to the business user community by defining the best approach to leverage technology in creating a business solution. This advisory role can be a challenge given the high technology expectations of ERP software; however it is in the best interest to our customers!

Embrace Changing Requirements for ERP Implementations

Business is Changing!  Don’t Fight it – Embrace It!

A key challenge with any ERP implementation is changing business requirements.  Yet many project teams are surprised when business requirements change.  Think about it, the scope of an ERP implementation is based upon a “point in time” solution.  Competitive business models are constantly evolving to meet customer demands.  Today, the majority of ERP implementation approaches discourage changing requirements by having laborious scope change control procedures that tends to be more of a roadblock than an enabler.   What is required is a more proactive approach to identify differentiated requirements that can provide a competitive advantage to ERP customers.

What Are Differentiated Requirements?

Differentiated requirements are business requirements that will support a business solution that is uniquely different from another business solution.  They allude to a significant, comparative difference.  Differentiated business requirements are very useful in ERP software selections because they focus on the unique differences between the ERP software packages.   In the context of an ERP implementation differentiated business requirements refer to unique business requirements that are different from company’s peers or competitors.  Consider the following illustration:

How ERPs address Business Requirements

Allow me expand on a couple of thoughts:

• Differentiated requirements are not best practices.  Best practices are common and generally accepted business practices across a specific industry and/or country.  Best practices are generally available in the market and therefore are not competitive (or no longer competitive).
• Differentiated requirements should focus on competitive business requirements that uniquely position a customer’s offerings in the market.  Practically speaking, a customer should be more concerned about being competitive in revenue-generating business processes (i.e. Order to Cash) rather than revenue-supporting business processes (i.e. Expense Reporting).
• Competent ERP software is designed to address generally accepted best practices.  ERP software will not address the unique competitive business requirements of an individual customer.

 

Handling Differentiated Business Requirements Late in the Game

Now comes the challenge of handling differentiated business requirements late in the implementation.   If you notice I did not say we should address all requirements.  There are risks associated with addressing business requirements at the end of an implementation cycle.  The question you need to ask is whether the business requirement will create more business value than the implementation risk generated.  There are four steps you can take to address differentiated business requirements:

• Reduce the possibility for late competitive business requirements by proactively searching for these requirements during earlier stages of the implementation.  This will require a competent understanding of business processes, their key results, and how they can be competitive.
• Maintain a business solution modeling environment to quickly determine how the differentiated requirement can be addressed.  Business solution modeling will enable simulations on how the three components of a business solution could support the competitive requirement.  The simulation may take several iterations.

Business Solution Modeling

• Plan for this scenario to happen.  Let me restate that the scope for an ERP implementation is based upon a point in time solution.  This scenario should be formally listed as a risk and managed as such.  This scenario is almost a certainty for a revenue-generating business process (ex. Order to Cash) given the external competitive forces at work.
• Develop a roadmap during the implementation to articulate how new or advanced business requirements will be handled in the future.  Too often a customer may believe that they have only a single opportunity to get both their needs and wants addressed in the ERP software. 

Summary

Just as we expect a customer’s organization to adopt change with an ERP implementation, project teams need to expect and embrace change for differentiated requirements.  The key challenge is identifying which requirements are competitive and strategic.   Too often we narrowly focus on functional areas and not the entire business process.

  

Silo Functional Focus vs. Business Process Focus

 

This is a challenge that all three key players of an ERP implementation (software providers, implementation partners, customers) must address.   Please do not underestimate this under-appreciated challenge.  It can be a huge mindset change for business owners that focus more on functional optimization rather than strategic customer advantage.  The best strategy for addressing late requirements is to plan for this scenario and have the appropriate iterative processes in place to quickly define, assess, and implement requirements that have competitive value to the customer.