Using technology to improve the way you do business

Performing a gap analysis

By Michael Burns

In October, we talked about using the company responsible for your ERP implementation – often called the value added reseller or VAR – to help build your “to be” business process (see www.camagazine.com/tobe). The rationale was, “Why reinvent the wheel, when your VAR already has a solution or can easily leverage processes already embedded in its system?” You could go to a different VAR or solution provider but it’s a huge job to convert to a new system. It should be a last resort based not just on requirements but also on the VAR’s vision, the software developer’s R&D investment, and support capabilities.

You need to be careful. There may be too great a gap between what you need and what your VAR can provide at a reasonable cost. Fortunately, there are ways to estimate that gap. The first is to treat your documented business processes as a script. With this method, you gather documentation of your processes, including problems and sample forms and reports. For some processes, you will need multiple forms or reports because of the number of scenarios associated with them. For example, if you have many billing methods, you should include just as many invoice samples. 

Once you have ensured employees responsible for the business processes agree with the script, you can release it to the VAR and ask for a quote to improve the processes. The VAR should describe its solution for each process and problem, and specify the costs. If the costs and solution are reasonable, you should schedule a demonstration to validate the solution. At that stage, more questions will probably need to be answered and more analysis done before the VAR can give a firm quote.

The next step (sometimes called a needs analysis or discovery) is typically chargeable. Here, the VAR analyses the business process and requirements in more detail. The deliverables from the needs analysis include design documents for any customizations, a detailed work plan, a firm quotation and a detailed write-up describing the VAR’s solution to each of the business processes and problems identified in the script.

Another way to perform a gap analysis is to compare specific requirements to system capabilities. You should do a requirements analysis at the same time as you document your business process. You must be precise in defining requirements, and this can lead to a lot of detail. Still, you should not get bogged down in unnecessary minutia. You don’t need to include basic requirements that would be found in all systems, such as an aged trial balance with 30-, 60- and 90-day buckets. You can also avoid detail if you can generalize. For example, there could be many additional fields that are required on multiple screens. Rather than describe the specific fields, you could just include requirements for adding user-defined fields along with other capabilities, including validation and being able to use these fields in report ordering and selection. Don’t expect users to define requirements. They can tell you how the system works now and what the problems are, but they are usually unable to transform this insight into requirements. You will need someone who can add value based on requirements analyses of similar companies.

You need to confirm each requirement and specify its priority. For example, 5 = critical; 4 = very high, 3 = high, 2 = medium and 1 = low. If all the requirements are critical, something is wrong. Requirements are not critical unless they can help you achieve your critical success factors, or CSFs (what you must do well in order to be successful). These were discussed in the May issue: www.camagazine.com/bpi. Confirmation and prioritization are best done by the core team responsible for the business process improvement project. To expedite the process, let one person be the spokesperson for each business process. Then everyone in the room is free to attack the spokesperson’s priority.

You can now issue your requirements to your VAR and let it tell you how well its system meets each one. A “yes” is not enough, as it could mean many things, including out-of-the-box, customization, third party or future enhancement. A good approach is to assign a number for each response to a requirement. The higher the number, the better the fit. For example: 7 = out of the box functionality; 6 = in next 6 months; 5 = third party; 4 = workaround; 3 = minor modification; 2 = in next year; 1 = major modification; 0 = not available. You can now calculate percentage fit calculations for each business process or module in the system (priority x response) / perfect score (priority x 7) x 100. That would be the VAR’s score. You should also ask the VAR to provide estimates and respond to other questions, including infrastructure requirements, so that a total cost of ownership can be computed. If additional analysis of the VAR’s system is justified, you would ask the VAR for a demonstration based on a script as already discussed. But this time requirements would be linked to each business process.

The requirements analysis is an extra step and provides additional due diligence. As well, you have all the key elements that should be included in a request for proposal that could be issued to other VARs or solution providers, if you determine that the existing VAR’s solution does not fit the bill or is too expensive. And if, once you have done your gap analysis, you decide there is no way around buying a new system, you will have an entirely new process to contend with. We’ll look at software selection next month.

Michael Burns, MBA, CA, is president of 180 Systems (www.180systems.com/), which provides independent consulting services, including business process review, system selection and IT audit. Contact: 416-485-2200 or mburns@180systems.com.