Should I judge a system based on requirements or outcomes?

When a company thinks about selecting a new finance and accounting system, there are many key criteria to consider, including vendor reputation, security, cost, technical architecture and functional fit. All of those are equally important and need to be taken into account.

When companies evaluate functional fit, they typically start by listing a set of requirements that the system must do. But that approach could be a trap. Here are three pitfalls you should avoid when determining functional fit to ensure that you don’t eliminate possible solutions that can work for your business.

1. Creating requirements based on how you work today.

When organizations start creating lists of requirements, they will start with how their process works today. For example, one customer described how they approved vendor bills for service providers today. They talked about the need for the system to be able to route invoices to department owners and to different levels in the organization based on spending category and dollar amount. They built their requirements based on how they work today. When evaluating the new solutions, if a vendor could not demonstrate that it met the requirements based on current processes, that vendor would be downgraded and possibly de-selected.

2. Creating requirements based on existing system limitations.

We were working with a professional services firm. They needed to measure what revenue they could have generated based on their standard rates and what revenue they actually generated based on the discounted rates. Their lead accountant stated that the requirement was to track revenue in the general ledger at standard rates and to provide a mechanism to write off revenue to drive the revenue down to the discounted rate. In the current system, this was the only way they could create the reports to measure their recovery rate of their fees. Was the requirement to track revenue at standard rate in the ledger, or was the requirement something else?

3. Creating requirements based on the loud voice in the room or the squeaky wheel.

Selecting a new accounting system is a team sport. Each functional area has needs that are critical to its business function. It’s important for each business unit to be heard and state its current and future needs. Often, there is a certain group or area that may dominate the conversation and put extra weight on features that are important to it but may or may not be important in the final selection. One of our customers insisted that the solution be able to automatically update VAT tax rates because that was his function. When evaluating solutions, he would immediately say that a solution was not a fit if it could not meet his need out of the box. His needs were legitimate, but were they a true knockout?

Alternatives

The three problematic approaches listed above are very common and actually hard to overcome because evaluators naturally will evaluate solutions through their own individual prisms — and those prisms may be based on current processes, limitations of the current system, or their own personal needs. You can overcome each of those flawed approaches by challenging evaluators to think about outcomes rather than requirements. For example:

• In the first scenario, the desired outcome was that services-related spending was controlled and approved. If the company stated this as the outcome, the vendor could come up with alternate and potentially better solutions to this desired outcome, such as service requisitions and time sheet approval that allowed managers to control spending at the source rather than via an in-arrears invoicing process.
• In the second scenario, the desired outcome was the ability to track recovery rates for their projects compared to standard rates. The vendor could describe how its solution could track accounting data in the general ledger at actual rates while also tracking operational data, such as standard rate. The vendor could then show how it can build dashboards that calculated the recovery rate without having to book overstated revenue entries and process faux write-offs in the GL.
• In the third scenario, the desired outcome was automation of VAT tax rates. If the solution could not do this out of the box, could a third-party product provide these rates and meet the outcome even if the baseline software could not?

If organizations evaluate based on outcomes or desired results and not on requirements rooted on their current processes, systems and teams, they will be less likely to eliminate suitable solutions and open themselves up to a better way to achieve the desired end results.