Proof of Concept - PoC


A proof of concept can sometimes be part of a larger evaluation. For most of our customers, however, it is the next step after the evaluation. It should ensure that the evaluated software works not only on paper, but also in "real life".

There are several objectives that can be validated with a PoC. Some examples are

  • Achieving a breakthrough for a specific integration scenario
  • Demonstrate basic technical feasibility
  • Mapping a complexe data model
  • Verify non-functional requirements such as performance
  • Use a demo/show case for internal persuasion
  • or to get a hands-on feel for the software, e.g. with your own data

The following process is not about the last mentioned show cases, but about a PoC, in which real proofs are to be provided.


The classic PoC according to our understanding is divided into the following steps

  1. Definition of key requirements and proof type
  2. Delivery of the proof
  3. Conclusion and further procedure

1. Definition of key requirements and proof type

The first step in the PoC is to define the key requirements for which a proof is to be provided.

This requires some experience to set the right focus within the PoC budget.

For each key requirement, it is also necessary to determine the type of evidence to be provided

  • Type 1 - Technical (realized / implemented) proof
  • Type 2 - Conceptual proof
  • Type 3 - Proof based on reference project

Note: Preferably, you would have type 1 everywhere - that the whole thing is already implemented. But this is also the most time-consuming proof. Depending on the budget of the PoC, we often recommend using type 2 or 3 for things that are important for a complete breakthrough, but don't really need any more proof that they can be done with modern software.

2. Delivery of the proof

The 2nd step is the provision of the defined proof type per key requirements.

As an example of a PoC for a PIM system, the implementation (proof type 1) could be approached as follows:




Prerequisite - Initialization & Basic Setup

Setup, initial basic configuration incl. accesses

System set up with access for all PoC participants

ANF-12-Typ1 - Data modelling

Analysis of product data export ERP, analysis of channel requirements (with focus on e.g. eCommerce), configuration of data model

Data model for PoC configured

ANF-14-Typ1 - ERP integration

Implementation of automated import

Assumption: ERP export as file

Data from ERP available in PIM

ANF-17-Typ1 - Integration of eCommerce focus channel

Implementation of automated export

Assumption: Standard Connector

Data is provided according to requirements eCommerce

ANF-21-Typ1 - Configuration input masks

Configuration input masks for product manager

Configuration for meeting PoC targets (e.g. demonstration maintenance)

3. Conclusion and further procedure

The third step is to draw conclusions from the PoC and discuss how to proceed.

Based on the PoC, a transparent decision must be made as to whether the software is suitable for the company.

If the answer is yes or no, the next steps are defined together.

Professional PoC management

It should also be noted that PoCs across the 3 phases must also be professionally managed in terms of project management and planning in order to efficiently achieve the desired result. 

This can also be offered by diselva, regardless of which parties carry out the PoC.

Jörg Brunschwiler - Chief Consulting Officer

Looking for a meaningful proof of concept?

Whether with defined software products from diselva or for the professional management of meaningful PoCs in cooperation with other parties - we look forward to your inquiry!

Jörg Brunschwiler, CCO & Partner