Navigating the ERP Sales Process: Pre-Sale Requirements Review

In our last ERP implementation post, we discussed the importance of selecting a VAR that best meets your company’s needs. Selecting the right VAR, is key to a successful implementation. Once the VAR has been selected, the actual pre-sale process begins. Before you “sign on the bottom line” you need to be sure that the VAR understands and responds to your ERP requirements.

ERP general accounting functionality is reasonably consistent. To get the “biggest bang for your buck” focus on critical revenue support areas. These areas set ERP’s apart, and the associated functionalities are critical to the company’s profitability.

Remember, requirements include not only system functionality, but reporting as well.

ERP implementations are controlled using a specific methodology. An example implementation methodology appears below. Note how the pre-sale activities are a part of the “Planning and Kick-off” phase.

Best Practices

This post discusses some best practices that help ensure an informed ERP purchase decision and that the VAR understands and addresses important ERP requirements.

The post also identifies some “pit-falls” which often result in a less than optimal result.

In my experience, three top best practices have emerged that can have a positive impact on a successful software purchase:

• Let the salesperson know what you need
• Have the salesperson tell you how the ERP can meet your requirements
• Build a method to hold the VAR to their promises

Let the salesperson know what you need

This is the most important part of the pre-sales process. Companies can communicate their requirements to the VAR salesperson in a variety of ways. Communicating requirements can be as simple as holding a few meetings, sitting through a general product demo and making notes, or as complicated as engaging a consulting firm to do a complete system needs analysis, a detailed RFP and developing a very detailed product demo plan.

I’ve seen companies with basic functionality needs go through the sales process with only a few meetings and a brief demo, and they make out just fine. I’ve also seen companies spend a lot of money on needs analyses, RFP’s and very detailed demos. Sometimes those projects go well, sometimes not.

What I’m trying to say, is that there is no right answer that applies in all situations. Use an approach that makes sense for your company and one with which you’re comfortable and capable of executing.

Rank your requirements and focus on key functionality. Accounting, Account Payable, Accounts Receivable and Cash ERP functionality is a structured and very controlled process. There is little room for creativity in these processes, and most ERP’s adequately handle basic needs out of the box. Unless your company has some very unique accounting requirements such as complicated corporate and GL account structures, inter-company activity or multiple currencies, I wouldn’t spend a lot of time in the accounting areas.

Instead, focus on critical revenue areas such as manufacturing, sales order processing or project accounting. These are the areas that set ERP’s apart, and the associated functionalities are critical to the company’s profitability.

Remember, requirements include not only system functionality, but reporting as well. In some companies robust, easy to use reporting tools may be more important than system functionality itself. Show your current reporting package to the VAR and resolve potential issues. If you need the VAR to assist in report building, be sure to get an estimate included in the sales document.

At a minimum, be sure to document your company’s critical processes, functionality and reporting requirements and provide them to the salesperson. There are plenty of applicable tools to use.  An internet “ERP requirements” search will yield several good resources.

Have the salesperson tell you how the ERP can meet your requirements

When you provide the salesperson with your requirements, be sure they understand that you’re expecting a written response of how the ERP will meet those requirements. Build your requirements documentation with that goal in mind.

Be sure that any requirements document(s) include a section for a VAR response.

The table below illustrates some suggested requirements topic values:

In terms of the VAR response quality, a simple statement such as Out of the Box (OOB) is sufficient for basic requirements. OOB functionality can be reviewed during the product demo.

For work-arounds, ISV’s or customizations, be sure that the salesperson provides an overview of how the requirements will be met in the response section.

If a workaround is required, have the workaround demonstrated, as it should be based on OOB functionality with only minor modification. Sometimes, all that’s needed with a work-around, is to make a change to the actual business process itself. When considering this option, have the process change demonstrated and be sure that you don’t negatively affect productivity or control.

For example, a company can have a transaction or process currently completed via a single step. However, the proposed work-around now involves 2 steps to achieve the same result. While the change may be a non-issue for an infrequent transaction or process, it may not be suitable for higher volume processes.

If an ISV application is needed, schedule a demo as required.

In the case of a customization, the salesperson should provide a general description of the customization required. The customization needs to be explained clearly enough, to support the decision to move forward. It should also include a “ball park” cost estimate.

Be sure to keep customization requirements consistent with their value. For example, some companies make extensive modifications just to keep legacy processes in place before really understanding how the new system works. Unless the issue is “Critical”, out of the box functionality should be used for at least 6 months before considering major modifications. Once system users become familiar with the ERP, modifications are rarely requested.

In addition to actual customization costs, be sure you understand associated on-going costs. For example, custom code development can require a re-do of the coding each time the system is upgraded. These costs can be significant.

Also remember, when interfacing data between systems, additional system maintenance and reconciliation is usually required, resulting in additional labor requirements.

A note to small and medium sized businesses: Remember that the size of the project dictates the level of response that the salesperson will be willing to provide. For example, if the project is one or two users consisting of basic financial modules, don’t expect the salesperson to provide the same level of requirements documentation as would be expected in a larger implementation.

Build a method to hold the VAR to their promises

Controlled requirements documentation serves several important purposes:

• Adequate documentation gives the salesperson an idea of your needs and provides a tool to be used to document responses.
• Requirements documents should be shared with the VAR’s implementation team during the Sales to Consulting knowledge transfer which reduces the consulting learning curve.
• Requirements documentation assists in project budget and project scope development.
• Requirement responses can be used to help ensure that the functionality promised is delivered.

Prior to the closing the ERP sale, communicate to the VAR that requirements document responses will serve as the basis of user acceptance testing (UAT), and that a successful UAT will be appended to the statement of work as a milestone.

Set up a retainage percentage (e.g. 10%) which will be payable upon the successful conclusion of the implementation.

The VAR may or may not agree to this.

Preferably, negotiating retainage should be a part of the VAR selection process. If you have more than one finalist, play one against the other and see what happens. Negotiate the best deal you can get, and do not let the VAR commence the project without some sort of protection.

During testing, refer to the documentation as needed. If the salesperson response is at odds with the test results, hold the retainage or short pay invoices until the issues are resolved. Remember, the customer wields enormous power over the VAR. If unhappy, customers can elect not to pay or can contest each project billing, placing the VAR in a position of having to negotiate settlement for each payment due. This is the last thing any VAR wants to be involved in.

Conclusion

Proper planning, preparation and documentation assist in the pre-sale process. Leveraging best practices and avoiding common pitfalls, are key to a successful ERP purchase.

One final tip. Pay attention during the pre-sales process and document salesperson responses to your questions. Be sure that you’re clear on what’s being promised. This is a great reason to use a requirements document.

Remember, requirements gathering doesn’t need to be a major undertaking, but at least be sure to build a requirements document addressing major issues and concerns.