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.

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

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.
Modeling ERP against business scenarios

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.

  

Project team focus during ERP implementations

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.

Reverse Engineer to Business Requirements

A critical activity for any ERP implementation is gathering business requirements.  The purpose of business requirements is to define the needs that will enable business activities to generate business results.   The traditional school of thought is that if we capture all the requirements then we assume that we will develop a solution that will produce the desirable results.  I believe that experience has taught us that the above assumption is not correct. 

Business modeling associating business activities with business results

Results-Oriented View of Business Activities

 

Let’s use the above illustration to elaborate on a few observations based upon my experience: 

  • Customer’s existing business models will have both value-add and non-value-add business activities.
  • Customer’s existing business models may produce undesirable business results.

 A concern with traditional requirements gathering techniques is that non-value-add requirements are carried throughout the requirements management process.   This results in wasted effort, loss of focus on the critical requirements, and informally creates the expectation that the new ERP system will replicate existing functionality.   A majority of non-value-add requirements are a result of current technology or organization limitation.  This is not a criticism but rather a reality we all (Customers, IT, Implementation Partner) must address as part of an ERP implementation.

START WITH THE END IN MIND

Let’s consider something unconventional and trace desirable business results back to business activities and the individual needs (requirements) for each business activity.

Business requirements support business activities which support business results

Results-Oriented View of Business Requirements

 

Starting with the desired business results ensures that we drive to only those requirements that directly support true business value.  First, it is an exercise that really puts into perspective the purpose of a business model (results).  This exercise is not only useful to the project team but also the business stakeholders.  Second, it is an approach that can help you justify why certain existing business activities are not being carried forward in the new business solution.  Third, taking a business results oriented approach enables your project team to be more successful at focusing on the right business requirements and not wasting time on capturing requirements for non-value-add activities. 

SUMMARY

Often we spend too much time and effort focusing on gathering requirements that do not support key business results and then gloss over the key business activities because of implementation time constraints.  Prioritizing business results is an activity that we need to initiate before gather requirements, not during fit/gap when expectations are harder to manage and negotiate.

Follow

Get every new post delivered to your Inbox.

Join 4,406 other followers

%d bloggers like this: