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.

Advertisements

Best approach for gathering ERP requirements

How You Gather Requirements Sends a Message!

Let’s us go through an analogy together.  You are the customer and I am the consultant working with you to develop some software changes for your packaged software.  As the consultant I can take two approaches for gathering requirements:

Option #1:  “What would you like?” An open-ended question that will generate a lot of feedback from you the customer.  Yet it communicates several underlying messages:

  • You as the customer will get a turn-key, custom solution.  Software changes require a minimal effort.
  • I as the consultant may not have sufficient knowledge of your business – or not enough to lead with a recommendation.
  • You as the customer know exactly what you want.
  • I as the consultant appear to be more customer-focused.

Option #2:  “Here is the delivered functionality. Please explain why this is not sufficient?” A question that will generate less feedback from you the customer.  Yet it communicates several underlying messages:

  • You as the customer may not get what you want.  Software changes should not be required.
  • I as the consultant may not have sufficient knowledge of your business – especially if I did not know of the gaps beforehand.
  • You as the customer may feel to be put on the defensive and not treated appropriately as the key stakeholder.
  • I as the consultant appear to be less customer-focused.

Both options are valid approaches for gathering ERP requirements.  However, the challenges I see today are due to how project teams apply requirements gathering strategies to their ERP implementations.  Project teams typically confine themselves to only one approach and do not account for the challenges associated with the selected requirements gathering method.

Multiple Methods for Requirements Gathering

Based upon my experience there are three main strategies for gathering ERP business requirements:

Requirements-Driven Strategy

A pure requirements-driven strategy focuses on defining all business requirements independent of organizational and technology constraints.  This approach is the most widely used method today.  This is also the slowest approach to gathering requirements and will require the most time from business users to articulate requirements.  We can anticipate gathering non-value-added business requirements that must be filtered through the requirements section process.  With additional gaps business stakeholders will have to spend more during Fit/Gap to make decisions.

Solution-Driven Strategy

On the other end of the spectrum, a pure solution-driven strategy focuses on the gap business requirements (requirements that cannot be met with delivered functionality).  This approach is highly popular in for rapid ERP implementations.  This approach requires the least amount of time from business users; however, business activities must conform to the packaged business software.  This could have a significant impact on organizational acceptance and impact because ERP software designs are based upon a market-driven set of requirements and not the specific requirements of an individual customer.

Configuration-Driven Strategy

The configuration-driven strategy is based upon the premise “The new system needs to do what the existing system does today”.  It may be a situation where a customer simply needs a replacement system because the existing system is nearing the end of its license and may become decommissioned software.  Starting with what the customer knows helps to expedite requirements gathering.  Business user time is minimized because IT can provide insight into the existing business system capabilities and configuration.    However, this approach will surface requirements based upon existing system limitations as well as legacy non-value-add business requirements.

Each requirements gathering approach has its strengths and challenges.   This fact does not invalidate the approaches described.  What is required is the right application of these methods to encourage – not force – customers to maximize their ERP investment.

Best Practice: Use Multiple Methods for Requirements Gathering

What if there was a way to take the best from all the approaches mentioned above and produce a strategy that took full advantage of ERP software?  What if we could bring in different approaches in such way as to complement and progressively elaborate (iterate) business requirements?   This is the aim of the blended approach – to leverage different techniques in the process where they can generate the most value.  The project team gathers business requirements from different perspectives which enable the team to create a holistic requirements definition set. Finally, the approach will naturally filter out non-value add business requirements.  Let’s review how we would execute on a blended approach for requirements gathering.

Gathering ERP requirements

Gathering Requirements for ERP

Iteration #1 – Listen to your customer

In the first iteration we will utilize the requirements-driven approach to gather high-level requirements.  The difference in applying this approach is the level or degree that we execute in this iteration.  The objective is to gather enough business requirements that will enable the project team to develop a competent system for business solution modeling.  A key concept here is that your customer needs to feel that they are being listened to and engaged, yet not being promised a custom solution.  The project team wants to be able to develop a system that will convincethe customer that the packaged software will support their business.  Focus on gathering the main business scenarios and relevant data that will enable the project team to produce a realistic solution to utilize during business solution modeling.

Iteration #2 – Lead your customer

Here in this iteration the project team transitions from listening to leading with a business solution.  During business solution modeling the project team will demonstrate the ability of the packaged software to support the main business scenarios to your customers.  During business solution modeling the project team also focuses on gathering exceptions to the standard business process scenarios defined.  You will also note that this activity will provide the project team with the opportunity to validate business requirements and software configuration during the requirements gathering process.

Iteration #3 – Negotiate with your customer

This final iteration is a confirmation that all value-add business requirements are defined and all business exceptions and scenarios have been addressed.  Looking at the configuration of your customer’s legacy system(s) not only is another source of validation but also can be the first iteration of defining legacy data migration requirements.

Summary

One of the key techniques the project team can use to detect and resolve business requirements conflict is to gather requirements from different perspectives.

Gathering ERP Requirements from different prespectives

Different Views of Requirements

Driving to define your business requirements from different perspectives will naturally identify potential conflicts.  Starting off with a requirements-driven approach lays the foundation for effective requirements gathering as well as promotes collaboration.  Next, taking a solution-driven approach enables the project team to quickly identify the boundaries of the packaged business software.  Third, utilizing the configuration-driven approach provides a validation of results from both the requirements-driven and solution-driven activities.  And finally taking a results-driven approach ensures that the business results support the desired business results.

Source:  This hybrid approach is further defined in my book Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations.

%d bloggers like this: