How ERP addresses business requirements

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.


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.


21 responses to “Best approach for gathering ERP requirements”

  1. Kevin Brunk Avatar
    Kevin Brunk


    I could see a third opening option: “What problem are you trying to solve or address?” That should lead to a much more interesting problem that suggests you want to know more about the customer’s environment and issues rather than jumping into solutions. It also opens up the possibility that the solution may not involve a change to software or the implementation of ERP software. In fact, the customer’s problem may be arising from inefficient business processes improvements of which could come from a process re-design. If anything, though, this opening question give you, the IS business partner, a better idea of which requirement definition path you should follow to best meet the customer’s needs. IMHO.

    1. Brett Beaubouef Avatar

      Hi Kevin – thank you for your response. I can see this approach working – especially for an existing ERP solution. I must admit that most of my experience is in ERP implementation and not ERP maintenance. However, I just took a job as an IT Director for ERP development. I suspect that I will learn a lot from this experinece. Thank you for the insight!

  2. Javier Urbano Avatar
    Javier Urbano

    Interesting post, I will send to my former Deloitte colleagues. From time to time I had the sensation that in most of the implementations we were losing some pieces of information. This is a simple approach to put all of them together, and what is most important, a good point to reflect on how we work.

  3. Imtiaz Ahmed Avatar

    Regarding Kevin Brunk’s comment, it seems logical that a much more diagnotic phase is required, prior to jumping in with any formal requirement sessions. In fact, if we re-align our focus we can see that this is more than a diagnostic or “discovery” phase, but rather a Due-Deligence process. Something, which i am sure your all agree is sorely lacking in the industry.

  4. Ramaswamy Avatar

    When we are talking about an ERP implementation, one of the key intangible requirement is for the custlomer to develop a trust in the consultant. The trust should include the trust on the consultant’s knowledge and more importantly a confidence that the consultant is working to help the user. Otherwise, even a simple question like (this is my experience), “what is your normal leadtime for you to receive the raw material once you place a purchase order?” could get you a highly subjective number which could throw your MRP calculations thru the window. (“Normally we get it in 5 days, but once it took about 15 days, so keep the lead time as 15”).
    Once you establish trust, then the approach to be decided will depend on many other technical and business factors. However, I prefer a combination of solution driven and requirements driven approaches. For example, in case of processes which are standardized (Statutory requirements, Financials etc) I go for a solution driven approach, while in case of other areas where the same requirement can be met with multiple options, I go for requirement driven appoach so that I can suggest the best option for the requirement.
    One key challenge to the requirements driven approach is to understand the root cause. For a humorous take on this, pl. read my blog “”
    Rgds, Ram

  5. Shailendra Keshri Avatar

    The approach covered all aspects.
    Thanks for sharing knowledge.

  6. MVC Avatar

    great article, thanks for sharing your experience

  7. James Avatar

    Imaging developing a new website for a vegetarian restaurant chain called veggie land there are currently three restaurant locations all on the north side of Seattle the restaurant chain wants to expand into the other areas of Seattle including downtown and the suburbs. What is the best requirement s gathering method to reach the targeted users near the existing restaurant locations? What about the targeted users near potential restaurant locations. Are there any community-based organizations that might be helpful with requirements gathering?

  8. […] IT spends more time performing support activities (indirect business value) versus building new enhancements (direct business […]

  9. […] given long implementation cycles.  Business needs and business wants get blurred together during requirements gathering which make it harder to differentiate and validate.  Finally, more analysis and effort is spent […]

  10. […] gathering:  Requirements gathering and business analysis is a gap that most ERP Cloud providers have not addressed effectively.  Onsite, face-to-face […]

  11. Bob Palmer, CPA.CITP Avatar

    Good process. I think I’ve been doing it this way for 20+ years; I assumed everyone did. I would also add two: business strategy based analysis and process based analysis.

  12. […] Bron : ERP the Right Way! Lees meer… […]

  13. Mendel Koerts Avatar

    Option #2 to gather requirements: ‘[Saying] Here is the delivered functionality.’ Only one issue: this requires the vendor to have been selected and the deal negotiation to have been completed…

  14. Nitin Avatar

    A very interesting article that brings in the required discipline in ERP implementations/engagements.

  15. […] 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 […]

  16. Yogi B Avatar
    Yogi B

    Nice Article .. thanks for sharing your knowledge

  17. Mike Gagas Avatar

    We are all experiencing a transformation in Implementing SaaS, Implementers. Customers and SaaS providers”. Do I support the Solution Driven approach? Absolutely. There is alignment with the SaaS model and the Solution Driven approach. One should be adopting SaaS if they want to fit their business into the solution instead of the other way around. One of my colleagues, an Implementer put it this way – “For an on-premise deployment you start with the solution and “Create” to fill the gap between the solution and the As-Is or To-be business processes”. He says, “In the SaaS deployment model, one would “Critique” the solution and ask Why not, or why can I not run my business according to the way the solution works.” I am paraphrasing, but I’ve always found this insightful. You’ll only achieve one of the promises of SaaS, a faster, lower cost implementation, if you critique and not create.

    Opinions are my own.

  18. […] Providers are not providing a robust set of tools and services for incremental user enablement.  Test cases should be business process focused and not just business function […]

  19. Vikram Avatar

    Nice Article. Though I agree with Ramaswamy , understanding the root cause is important as anything else here.

Leave a Reply

%d bloggers like this: