One of the first major milestones in any ERP implementation is the receipt of the ERP software proposal. This typically outlines anticipated scope, cost, timeline and other critical components of procuring software. It may also include potential integration efforts, customization services, hosting services and other items involved in ERP implementation.
Below are a few tips to help you better understand proposal terminology:
1. Understand the exact scope of the proposed software solution.
Getting to the bottom of what exact software is being proposed can be more challenging than it sounds. Constant updates to software versions, multiple variations of available modules and disconnects between the demo and proposal cycle can create ambiguities. For example, sales teams will often demo one version of a product, while the proposal team assumes a different version of the software – all without explaining the difference. We’ve seen a number of ERP expert witness engagements boil down to this issue.
2. Define and understand key proposal assumptions, such as your roles and responsibilities in the project.
Keep in mind that software vendors are trying to sell you on their solution, which includes outlining the ways that costs, timelines and risks will be minimized if you select their solution. It is not necessarily in their best short-term interest to be realistic in the sales cycle, so it is your job to ensure you understand what is driving their assumptions. For example, how much work are they planning to shift to your team versus taking on themselves? Understanding these assumptions will ensure you are fully aware of what is driving the details of the proposal.
3. Compare apples to apples.
Comparing one proposal to another can be a nightmare – even for our team, who does this for a living every day. Each proposal has different assumptions, different scopes of functionality and other variables that vary from vendor to vendor. It is vital to decipher and normalize so you are comparing apples to apples. For example, one vendor might include their advanced demand planning and budgeting modules, while others may have excluded these modules but included others. Others may assume you are going to do all the data conversion work yourself, while others may assume you’re not. Each discrepancy has the potential to create a huge amount of “noise” in your evaluation process.
4. Trace the proposal back to you business requirements.
At the end of the day, nothing in the ERP software proposal matters if it doesn’t meet your business requirements and objectives. The last thing you may want to do is review your business requirements after reading a 100-200+ page proposal, but it is a critical step in the process. It is the only way to ensure that your proposals and corresponding expectations will meet the business needs that you and your team have set forth early in the process. This discipline and focus is something that should start when reviewing proposals and continue all the way through implementation.
5. Look for items missing from the proposal.
Most ERP vendors are good at one thing: installing, configuring and customizing software. They aren’t typically good at the people and process side of the equation, which is ultimately what will make your project succeed. When reviewing ERP proposals, look for these critical success factors, which you will need to address in some fashion in order to be successful. For example, business process reengineering and organizational change management are among the success factors most commonly missing from ERP sales proposals.
Evaluating a series of ERP vendor proposals is never going to be easy. However, understanding the nuances will ensure you not only find the right software but you implement it in a way that meets your needs and expectations.