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 (a.k.a. prototyping) 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.

Best Practice: There should be no more than 3 prototyping iterations for an ERP implementation.  If you need a 4th iteration then some thing is not right and a project analysis should be performed.

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. 


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.





17 responses to “Embrace Changing Requirements for ERP Implementations”

  1. Bill Wood Avatar

    Great post… On my site I frequently advocate for the customer perspective. From an SAP ERP application perspective the software is generally pretty broad AND deep as for functionality. Even though SAP offers “best practices” all of those processes are nearly infinitely tailorable without much or any custom coding. Sometimes it is required though and that is when I advocate for the value approach, “software engineering” is appropriate when it is focused on a KEY business competitive requirement.

    SAP Implementation Focus, Software Engineering or Business Process Engineering?

    My big frustration is with so many of the stupid implementation practices where technicians rather than experts do the systems work.

    CRM, ERP, BI, and IT Investment — Where Do You Find the Business Benefit?

  2. Bob Overstreet Avatar

    Excellent post. Too often I run into teams where the focus is on “implementing best practices”, rather than looking beyond that to implementing what a company needes to meet its business processes.

  3. […] Unique Processes in ERP for Competitive Advantage In a recent post, Embrace Changing Requirements for ERP Implementations, Brett Beaubouef explored the concept of Differentiated Business Requirements. These are processes […]

  4. […] This post was mentioned on Twitter by Maria Frangieh, Brett Beaubouef. Brett Beaubouef said: ERP the Right Way! New Blog Entry "Embrace Changing Requirements for #ERP" http://lnkd.in/uc_6qB […]

  5. ojiugo123 Avatar

    Meeting clients needs to key to successful implementations,great post!
    Checkout my blog @www.ritetracpm.blogspot.com

  6. Frode Vatne Avatar
    Frode Vatne

    good article, I will put the focus of why the requirements change during the project to that the project are functional requirement driven not the end customer driven. A change on the focus when the requirements process were done, may create a totally different outcome.

  7. Brett Beaubouef Avatar

    Excellent point Frode! Thank you for the astute insight. Sometimes the internal customer’s desires do not align with the external customer’s needs. I believe that the first step of requirements management is performing a stakeholder’s analysis to determine who are the “real” customers.

  8. […] should conform their business activities to the ERP software.  ERP implementations should include software enhancements to address the unique value-add requirements of a […]

  9. […] industry-specific functionality provided.  This advantage is especially important for generating competitive advantage.   It is vital that an organization’s revenue-generating business processes are competitive.  […]

  10. […] are two areas of consideration for the Cloud ERP deployment model: customizations and integrations.  These two areas are impacted based upon the cloud model.  Following is a […]

  11. […] and confusion.  On one hand, customization(s) can result in an expensive ERP solution.  However, ERP software enhancements can provide a competitive advantage or cost reduction that is customer-specific.  The challenge is […]

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

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

  14. […] should factor in the ERP SaaS selection process.  First, competitive advantage only comes from revenue-generating business processes.  For example, would having the best of breed solution for SOX compliance enable you to gain […]

  15. […] a post, Embrace Changing Requirements for ERP Implementations, by Brett Beaubouef explored the concept of Differentiated Business Requirements. These are […]

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

  17. […] differentiated business requirements, even late in the implementation cycle.  Rapid, iterative processes take advantage of change for […]

Leave a Reply

%d bloggers like this: