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.

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.

Five key areas to consider when selecting ERP software

There are five key areas to consider when selecting ERP software:

(1) Functional Fit

How well does the ERP software fit with (a) current business requirements and (b) future business requirements?  Too often I see vendor responses and demonstrations spend too much time on “core” functionality and not enough time on the unique and strategic requirements of customers.  These are the requirements that generate a competitive advantage to customers.

(2) Technical Fit

Two key activities need to be performed: (1) internal technical assessment and (2) external technical assessment with each vendor.  The internal technical assessment consists of identifying the current state of the customer’s IT environment: in terms of hardware, software, FTEs, and skills.  The external technical assessment consists of identifying the technology requirements of the vendor’s ERP software in terms of hardware, software, FTEs, and skills.  You then perform a comparison (fit/gap) to identify the technical requirements for the customers to move to the vendor’s ERP solution.   Quantifying the technical gap is very important in calculating the financial fit.

(3) Organizational Fit

This area is typically overlooked and underestimated.  It is important to understand how the customer’s organization must change to effective support the new ERP solution.  Many customers know that they must change, however few understand how and the amount of change that is required. 

(4) Implementation Partner

This is by far the area that will have the greatest impact on your success with any ERP software.  You can select the ERP software with the best fit but if you cannot implement the ERP software then what is the point!  This area is so important you should have a separate selection process for the implementation partner (separate RFIs, RFP, Evaluation).   Following are the key questions you should address with potential implementation partners:

  • Strengths
  • Weaknesses
  • Revenue, # of consultants dedicated to ERP software vendor
  • Locations
  • Industry Focus
  • Target Customer Focus (Up-market, SMB)
  • Software Product Knowledge
  • Certifications (Software, Industry)
  • Type of Consulting Services (implementation, upgrade, training, process improvement, installation, technical services) – how well can they support the entire ERP lifecycle
  • Implementation References similar to you
  • Recent News
  • Thought Leadership (publications, presentations)
  • Partnership status with Vendor (# of years, level)
  • Vendor recommendation

  (5) Financial Fit

 What is the total cost of ownership across the expected lifecycle of the ERP solution – including installation, training, implementation, maintenance, upgrades, hardware, ERP software, 3rd part software, process improvements?  It’s important to set the expectation that the proposed gains will not be realized in the initial implementation but over the expected life of the ERP solution.   The end result of the financial fit is the business case.  As with any business case there will be assumptions, constraints, and estimation accuracy (ex. Order of Magnitude) so please ensure that you clearly specify this information along with the value proposition. 

ERP software selection is an important step in your goal of implementation a new business solution.  I hope that the information will assist you in being successful.

Follow

Get every new post delivered to your Inbox.

Join 4,406 other followers

%d bloggers like this: