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.                    

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. 

ERP Project 101: What + Why = How

One of the reasons why I am a consultant is that I enjoy solving business problems with technology. ERP provides a technical foundation that I can utilize to solve problems.  However, during my career I came to the realization that simply throwing technology at a business need is not in the best interest of the customer.  This is especially true when you do not completely understand the requirement.   There is a difference between an evolving requirement and an evolving understanding of the requirement.  In the next sections we will briefly review a practical approach for ERP requirements management.

 

Gathering Business Requirements is Just the Beginning

I think we all can agree that gathering business requirements is a key activity that will have a significant impact on ERP implementation success.  However, it is as equally important to focus on requirements validation before proceeding to implementing a solution for addressing requirements. Too often we jump from gather to design before we have a full appreciation of the business need.  When it comes to formal requirements management, I keep the following simple equation in mind:

Requirements Mgmt 101

Basic ERP Requirements Management

  

Defining What

Sounds simple enough but how you gather requirements sends a message.  Also, it is important to understand if the requirement is the result of a new opportunity or addressing an existing business pain.  The source should play a factor in your approach to gathering information.  Consider the following commonly accepted approaches utilized for gathering ERP business requirements:

 

Defining Requirements

Generally Accepted Requirements Gathering Methods

 

Please allow me to state that the above methods are valid and have their inherent advantages and disadvantages.  The challenge I find is not gathering the requirement but rather the limited effort spent on understanding how the requirement supports business process results. 

 

Determining Why

It is hard to provide a solution when you do not understand the business.  Asking why is less about challenging business requirements and more about gaining a better perspective of the requirement.  What are the desired result(s)?  How do the result(s) add value to the overall business process?   Odds are that you will have only a superficial understanding of the requirement if you do not understand the context (environment) of the business need.  Also note that asking why is the first step to validating your understanding of the business need.  Following is a list of the common validation activities for business requirements:

Confirming Requirements

Requirements validation techniques

 

I firmly believe that all four validation methods should be employed as part of defining business requirements.  Unfortunately, not all of these validation steps occur during the deployment.  The advantage with ERP is that you have working software that you can easily demonstrate and confirm how business requirements would be handled.  Do not guess – prove what is possible!

 

Constructing How

This process is typically an area that is not executed well when it comes to ERP.  In the rush for faster results many assume that the solution must be implemented via technology.   Technology is good for many activities (repeatable, logical) but it can also be a costly option for conflicting requirements across a business process.  As a rule of thumb, I typically consider 4 options for addressing business needs:

 

Addressing requirements

Options to address ERP requirements

 

  1. Automation: Developing a technical solution to address need.
  2. Business Process: Creating business process to address need.
  3. Acceptance:  Do nothing and handle as the need arises.
  4. Avoidance: Eliminating the source of the business need.

 

Understanding both the What and Why will provide you the right insight to select the most viable approach for implementation of the requirement.  It provides you with the perspective and context for effective decision-making.

 

Summary

An enterprise technology platform like ERP is an empowering toolset for addressing business needs across an organization.  Yet, soft skills like requirements management have a greater impact on business solution success.  It seems like every couple of years there is a “new” ERP methodology that will address the challenge of gathering ERP requirements.   Often I observed too much focus on the methodology and not enough effort focused on the end result.  I’m sure that I may receive some criticism from my peers in regards to my attempt to “dumb down” requirements management.  However, I have found that the best approach is a simple approach that every stakeholder can understand and recall instantly versus having to go to a methodology book.  

Decisions – Not Documents – Move ERP Implementations Forward

Information Alone Does Not Generate Value 

I grew up in a time when information was hard to obtain.  Generating information was seen as a valuable exercise because information was a scarce resource.  The first software development life cycle (SDLC) I learned was Waterfall.  One of the key focus areas for the Waterfall SDLC was documentation (i.e. information).  However, there is a limit regarding what value information can provide.  In our enthusiasm to create information we sometimes go to an extreme and generate so much information that it becomes a roadblock.  What we often forget is that the key purpose of gathering information is to make decisions!

There is a direct relationship between the speed of customer decisions and the speed of ERP implementations.   The faster a customer can make a decision results in a faster implementation cycle.  Naturally, customers want to make right decisions therefore the project team must gather the right information.  To gather the right information we first need to understand the key decisions that must be made as part of the ERP implementation.

Decision-Oriented Information Gathering

Before the project team begins gathering information they first should consider what key decisions the project must make.  The ERP implementation scope will determine both the information gathering scope and key decisions to be made.  Consider the following illustration:

Gathering information to support decisions

Decision-Oriented Information Gathering

Simply stated, the scope for an ERP implementation consists of the software features that will be deployed (product scope) and the project activities and audience for the deployment (project scope).  Once the implementation scope has been defined, the project team can better identify the information requirements.   Gathering the required information and presenting that information in the appropriate context will enable the customer to make both software configuration and fit/gap decisions.  

Utilize Best Practices to Drive Decisions

A best practice is a process, method, or approach that is considered the most effective at delivering a desired outcome.   A best practice is repeatable and has proven itself over a period of time.   For ERP implementations there are two areas of best practices that should be considered:

  1. Industry best practices
  2. Configuration best practices

Once the implementation scope has been clearly defined, the project team should leverage industry best practices to assist the customer in making decisions.  Providing these best practices up-front to the customer will streamline the information gathering process.  As the project team moves from gathering information to driving decisions on ERP configurations and Fit/Gap, configuration and gap decision best practices can be referenced to provide proven knowledge to key decision makers.   Having the right Implementation Partner can have a significant impact on effective information gathering and decision support.  An Implementation Partner may not know every single decision that the customer must make as part of their ERP implementation but they should be able to identify up-front the key decisions required based upon the scope. 

Consequences of Not Driving to Decisions

The ability to make informed decisions is fundamental to ERP implementation success.  I would like to encourage the two key players that impact the decision-making process for ERP projects:

Customers

We live in a society where we like to keep our options open.  Many say that keeping your options open will make one flexible to future opportunities.  Many customers have applied this concept to technology and business systems.  I have seen this philosophy trickle down into a customer’s decision-making approach for ERP implementations.  Customers desire to have a business solution that is both adaptable and flexible.  It is an understandable and legitimate requirement.  However, customers need to keep two things in mind:

  • Keeping your options open (i.e. not making decisions) will slow down the implementation project and increase your risk for failure.   
  • People, not technology, is the most flexible and adaptable component of a business solution.
Strengths of Business Solution

Business Solution Strengths

Implementation Partners

Implementation Partners should be able to provide industry and ERP configuration best practices to their customers.  These best practices should be formally documented and provided early in the implementation where they have the greatest benefit.  These documents will provide evidence that the Implementation Partner can provide a repeatable and reliable service.

Summary

As a project manager, I’ve observed where project team members focused more on producing information and focused less on producing decisions.     Producing information (i.e. documents) is far easier than driving decision(s).    There is a false perception that generating more information will result in more knowledge and enable customers to make better decisions.  Nothing is further from the truth.  Only when the right information is communicated in the right context then knowledge is created for making informed decisions.

Business Leads and Technology Supports

There is a misconception in the ERP market that says technology is the key enabler to business maturity.  In a previous blog (ERP is Only Part of a Business Solution) I discussed the supporting role ERP plays in a business solution.  Business processes and people have a far greater influence on business process maturity and business results.  Let’s clear up this misconception by examining two areas that have driven its general adoption.

 

Is Technology changing Business?

I do not believe that technology is changing business but rather technology is finally catching up with leading business practices.  For example, back in the early nineties I read a book on the e-business revolution.  The major premise of the book was that technology was transforming existing business models into an e-business model.  The book provided an example where inventory stocks could now be checked in retailer stores and inventory orders could be generated to maintain a desired stock level.  The book explained that this is an emerging requirement due to new e-business technology.

I have to humbly disagree with this analysis.  The above requirement had always been a desire of business.  I remember back in the early fifties when my father would make the rounds as a salesman to his retailer customers to see their inventory and manually created orders to maintain the retailer’s inventory levels.  Many businesses did not perform this process because (a) it was manually intensive work, and (b) it reduced focus on higher priority business activities.   Technology is now providing a cost-effective vehicle to accomplish this business requirement.

Build It and They will Come

Everyone has heard the phrase “build it and they will come”.  Several internal IT and external Implementation Partners & ERP vendors have used new technology as the value proposition for ERP implementations.  This philosophy may have worked in the era of “green screens” and emerging client/server technologies but it does not work in today’s world.  Technology driving Business is like putting the cart before the horse.  I recently talked with a customer where the IT organization and ERP vendor took the above approach for implementing new Business Intelligence (BI) software.  The business users felt limited and constrained by the technology.  Results – user adoption was low and now business users are looking at implementing their own BI solution(s).  Needless to say that the ERP vendor, the Implementation Partner, and their own internal IT organization are no longer considered trusted advisors.

What Drives Business Results?

Technology is a great enabler that can play a role in supporting the generation of business value.  However, technology is not always the best approach to address problems that may be inherent in the business model.  Example: automating non-value-add business activities will not generate business value for the customer.  Also consider that most business value is generated outside the ERP software.    “Making decisions and implementing them is where business value is created in an organization.” (Dawson, Ross. Developing Knowledge-Based Client Relationships. Butterworth Heinemann, 2000).   ERP does not have the capacity to make decisions having considered a diverse range of issues, and will not have the capacity to do so in the near future (maybe in our lifetime we should have artificial intelligence capabilities embedded within ERP).  Knowledge is only an attribute of people.  Technology stores information.    So how should we leverage ERP to support greater business results and business maturity?   Consider the follow illustration:

Key Drivers for Business Results

Key Drivers for Business Results

 

It is important to note that business processes and people have a far greater impact on business results than technology.  Technology can be a cost-effective solution in automating consistent rules and activities.  However, technology like ERP can only utilize information that has been codified.  There will always be tribal business-related knowledge and experience that exists outside technology.  Some of this tribal knowledge is leading or emerging business activities/rules.  In this situation where business rules and activities are radically evolving then technology is not a cost-effective solution for automation. 

Summary

It is important to understand and appreciate what technology can and cannot do for a customer.  Often the true problem lies not with the ERP software itself (granted there always software bugs and fixes to apply) but rather the demand for quick fixes and rapid cures to business challenges.  If the ERP software did not improve the performance of the underlying business model then executive management would conclude that the ERP implementation was a failure. 

Technology like ERP can be an enabler and a limitation for customers.  To ensure enablement over limitation you must first understand the right relationship between business and technology.  Once you understand the key strengths and weaknesses of both areas then you will have a greater insight to the right application of technology to support the customer in driving valued business results.

ERP is Only Part of a Business Solution

Back in the 80s Enterprise Resource Planning (ERP) was deemed the panacea for business pains caused by operational inefficiencies and disjointed applications.  Then came the realization that ERP was not the final solution but just one piece of the puzzle.  In addition we learned that change was not just a software issue, that implementation is not the same as installation, and that the cost of ERP is not a one-time expense.    Above all we learned that ERP is only part of a business solution.

 Business Solution Defined 

 I like to view a business solution as three components:

  1. People
  2. Processes (business processes)
  3. Technology (software & technical infrastructure)
ERP Business Solution

Business Solution Defined

What is the most important component of a business solution? 

Now here is something interesting to consider, “Do we need all three components to have a solution for business?”  Let me rephrase it this way “Do we need software in order to conduct business?”  I am persuaded to say that the answer is no.    Business was being conducted before the invention of the computer.  However, I am quite aware that not having software a part of your business is impractical given today’s competitive marketplace.  I do want to demonstrate that software only supports and therefore can only have a certain level of benefit to a business. ERP software does not have the capability to make key business decisions.  It is key business decisions that drive business results.  Business software like ERP can provide information and data to assist people in making business key decisions.  Seen in this light we can conclude that people are the most important component of a business solution and people have the greatest impact on the success of a business solution.  Funny how it is interesting to note that the majority of ERP implementations mostly focus on products and technology.  Let’s dig a little deeper and spend some time speaking about each business solution component.

Business Solution Component: People 

People are the single most important factor that will determine whether a business solution is a success or a failure.  People can also be the most challenging component to deal with in a business solution.  Let’s be honest, you can hardcode software to do exactly what you want that product to perform, people are a different story.  The upside to keep in mind is that people have the potential of generating the greatest value in the context of a business solution. 

 Business Solution Component: Business Processes 

What is a business process?  I have seen many definitions but I like the definition provided by Howard Smith and Peter Fingar in their book Business Process Management – The Third Wave (Meghan-Kiffer Press – 2002)

 A business process is the complete and dynamically coordinated set of collaborated and transactional activities that deliver value to customers.

Let us look at the some of the characteristics of business processes that is highlighted in the above definition:

  • Complete: there is a beginning and end to a business process.
  • Dynamic: responding to changing customer demands and market conditions.
  • Result-Oriented: value is generated to your external customer.

 These basic characteristics must be addressed during business solution implementations in terms of needs assessment, requirements management, and validation (testing) of a business solution.   We should not be surprised when business requirements change during an ERP implementation and we should plan for it accordingly.

Business Solution Component: Software and Technology 

Software and technology encompasses the technical infrastructure, networking resources, and ERP software that will support the business solution.  With ERP software there are inherent advantages and disadvantages as listed below. 

ERP Pros and Cons

ERP Advantages and Challenges

 An effective ERP implementation strategy will maximize the inherent advantages of ERP while addressing or minimizing the inherent challenges. 

Summary

ERP is only one component of a holistic business solution.  ERP can be a great platform for addressing business challenges as long as the technology is correctly applied.  At the end of the day it is People, Business Processes, and Technology working together in unison to generate business results.  Only when these components are judiciously utilized are business results maximized. 

Follow

Get every new post delivered to your Inbox.

Join 4,410 other followers

%d bloggers like this: