Choice of software: is a Proof Of Concept (POC) necessary?

Some publishers and integrators offer you a POC (Proof-Of-Concept) to validate the feasibility of a project. More often than not, this is requested by the customer. Is this a comfort phase to reassure the customer, or is it a compulsory operation to reduce risk?

See all software Operations Management

Advantages and disadvantages of a POC for the customer

There are a number of advantages of a proof of concept (POC) for the customer:

• Synchronisation of expectations with the supplier;
• Better ownership of the implementation process;
• Identification of functional deficiencies or over-estimation;
• A better understanding of the investment required. A more precise framework provides a better understanding of the investment required to complete the implementation;
• Evaluation of the implementation partner. The inherent POC process allows the customer to evaluate the software and the implementation partner.

There are also POC limitations that should be noted. These are:

• Commercial flexibility. The flexibility built into some POC arrangements that allow the customer to opt out without buying the software is rarely considered in reality, as a significant investment of money and time has been made. Furthermore, the customer often makes the decision to embark on a POC without fully evaluating all the solutions because of the low risk of this option.
• The sales exercise. Depending on the commercial agreements in place, the POC may be integrated into the sales cycle, so the supplier's ability to disclose all of this information is restricted. In addition, the documentation produced in the POC may have marketing content that adds no value to the project.

This article is the second part of a two-part tutorial. The first part was devoted to analysing the structure of a POC and how it corresponds to the selection process.

Advantages and disadvantages of a POC for the vendor

Here are the advantages for the vendor:

• Having a competitive advantage in the sales process. The POC is another tool in the sales toolbox. The POC can be used to take the potential customer to the next stage of the sales process without the customer having to make a full commitment.
• Better implementation and satisfied customers. A key success factor for any VAR or software vendor is to have customers who are ready to serve as a reference. Any tool that improves customer satisfaction should be considered.

Here are the disadvantages for the vendor:

• Sales timeline. The POC can prolong the sales process. In addition, the timeline (important for listed companies) becomes more uncertain, which can lead to a further price reduction.
• Requests for resource advice. Due to the nature of the POC, requests for advice can be significant and resource-intensive. As a general rule, more experienced consultants are required to ensure that the POC results in a purchase order.

See all software Operations Management

When should a POC be carried out?

A POC should be carried out as part of the selection process when the risk of project failure is relatively high. The risk can be measured using two key variables. These variables are the complexity of the requirements and the level of expertise within the selection and implementation team (MOE). The more complex the system requirements, the greater the benefits obtained from a POC. Complexity can be measured by the number and nature of the modules implemented, the degree of customisation, the number of interfaces and the quantity and quality of the data to be converted.
The number of modules to be implemented (for example, a purely financial implementation versus a financial + distribution + storage implementation) increases the scope of the implementation, and therefore the risk. In addition, the nature of the modules to be employed also influences risk. Modules such as sales force automation (SFA) in a customer relationship management (CRM) suite tend to have a higher risk profile than financial modules such as accounts receivable.
The level of expertise within the selection/implementation team is also an important indicator. Factors to consider include

• Knowledge of the sector
• Knowledge of existing business processes
• Understanding of the high-value software selection process
• Knowledge of software vendor management
• Knowledge of ERP/CRM systems

These factors should be used to measure the skills of your team. A highly skilled team reduces the risk factor for the project.
The table below represents these factors and how to determine if a POC is required for the selection process:

About the author

Robert Rudd is an expert ERP consultant with over nine years' experience in implementing ERP systems. His experience also includes IT supporting clients in the financial and banking sector. He has implemented ERP systems in a number of industries, but specialises in supply chain management. Rudd works for Scalable Data Systems based in Australia. Scalable Data Systems has been delivering enterprise solutions to the mid-market for over twenty years.