• Resources
• Blog

What Are the Benefits of a Proof-Of-Concept?

The proof-of-concept (POC) is an essential part of the process when acquiring new technologies for an enterprise. However, it is a step that is frequently by-passed or greatly reduced in scope, which limits the full benefits that can be realized by the process.

One of the reasons for the omission is that traditional, established frameworks are frequently followed for modern use cases. For example, the proof of concept phase does not feature strongly within the seven-step strategic sourcing framework, even though its importance has grown in recent times, rather than diminished, due to the meteoric rise of software purchases. This is coupled with the issue that software companies themselves are more than willing to by-pass this important step, as it adds time and resources to the process and the commitment required on their side.

Instead, therefore, there is an over-reliance on ‘demos.’ This is convenient for the software vendor and is often the result of an overabundance of good faith on the part of the buyer but leads to problems later.

This article summarizes the benefits of not omitting the proof of concept step. It covers conducting a proof of concept, how the process works and how the outcomes can be evaluated.

Benefits of a proof of concept

The proof-of-concept allows the buyer to conduct a full test of the actual software capabilities of a solution and the outcomes it will be able to deliver to the enterprise. There are additional advantages in the context of complex solutions:

• Enterprises enjoy more access to vendor resources
• It provides an understanding of how the two organizations will work together in practice
• The overall cultural fit, in addition to features and capabilities, can be evaluated

Types of proof of concept

There are a number of types of proof of concept, but to qualify as a POC, there should be defined use cases that are subject to proof of concept testing and that are specific to the organization. It must go further, therefore, than a general demo and will likely be one of the following options:

• A technical-level POC: the system is configured by the vendor to specific use cases, which are shown to the client
• A sandbox-level POC: the system is configured by the vendor to specific use cases and the client is provided access to try the system for themselves

How the proof of concept process works

The proof of concept should be implemented for vendors who are at short-listed stage. In the case of evaluating supplier information management, the following use cases might be considered:

• Data migration and consolidation. Evaluate the vendor’s ability to migrate data from the ERP or ERPs, at scale, into a single master data model.
• Data integration. Evaluate the vendor’s ability to integrate supplier data with key systems, in particular ERP and P2P, for both an initial load and to manage on-going changes.​
• Supplier onboarding. Evaluate the vendor’s ability to manage on-boarding for any supplier type while meeting requirements for all data to be gathered, including tax, compliance and payment data. Assess this from an ease-of-use perspective for three main user types: business requestor, supplier and approver.
• Supplier extension. Evaluate the vendor’s ability to fully support data capture, workflow and update of master data for key events in the supplier lifecycle while maintaining compliance, complete and accurate master data and integration to the systems that need it.
• Other workflows, including those that require variation, such as at local level

How to create a proof of concept

Once the use cases have been determined, these can be discussed with the vendor. The next steps are:

• Set up a scoping call with the vendor to fully define all use cases and necessary information required
• Consider all stakeholders who should be involved in the process
• Commit to undertaking a full proof of concept
• Allow for a modest build and preparation period
• Define clear success criteria against which short-listed vendors can be compared

Many POCs focus too heavily on feature and functionality alone – which is why the temptation to rely on a demo alone arises. The features and functionality requirements are important, but as part of the evaluation criteria, it is advisable to determine those that are critical, those that are ‘nice-to-haves,’ and those that are not critical. The features and functionality test then forms one area of the overall assessment.

To undertake a comparison, the same proof of concept should be rolled out for all vendors involved at this stage of the process.

Measuring proof of concept outcomes

The approach outlined here allows for a scorecard to be established for each of the short-listed vendors.

Beyond a feature/function comparison – and as a result of collaborating more with the vendor – the scorecard can now cover a vendor’s capabilities in a wider range of areas such as: overall system flexibility; level of domain knowledge and expertise; methodologies for data migration and consolidation; and ability to support other requirements such as governance, risk or compliance.

There will also be red flags that will become apparent during the proof of concept phase based on how a vendor intends to approach certain areas. Here are three common examples:

• If data migration involves having to complete custom templates provided by the vendor, then this is a warning sign of delays to come in an actual implementation
• For data integration, all mandatory fields in the ERP must be covered and the solution should integrate directly, not via CSV or XML outputs
• For supplier onboarding, rules for handling tax ID and banking information should already exist in the system

Spend time now to gain dividends later

The extra thought given to this part of the sales process – and carrying it out properly – pays large dividends later. Many have fallen victim to the divergence that exists between what can be shown at a generalized level in a demo environment, versus the experience of a live solution. They, therefore, must contend with the consequences of this discrepancy.

A successful proof of concept, on the other hand, enables the enterprise to make much a better assessment of the likely outcomes of a project and consequently enables project leaders to communicate expectations far more accurately, with confidence in the results to be achieved.

To find out more, read a full whitepaper on The benefits of a proof of concept report.