Johannesburg, 13 Apr 2023
A proof-of-concept (POC) determines whether a solution will work in the internet of things (IOT) space. On the other hand, a proof of value (POV) determines whether a particular solution will work for the use case in time and on budget. Notably, a POV establishes whether the solution will add material value to a business in cost-savings, data utilisation or automated compliance, to name a few outcomes.
Most solutions are possible, but determining whether a problem is worth solving is tricky. Distinguishing between these two methods of approach is critical. If we look at the IOT sector and the rapid technological advancements it's producing, a POC is a helpful tool to determine whether a solution is technically possible. The catch is that with enough time, investment and brainpower, you can solve most problems in IOT.
There are many examples of POCs in the field. A typical example is electricity monitoring, where data from energy meters is extracted and sent to visualisation platforms. The client can now see all the endpoints, like voltage and amperage. One could term this an intelligent meter solution, but is it? This use case, alone, carries no value. Getting the data is critical and is a necessary and often complicated step to solve, but how do we make the data useful to lead the customer to the desired outcome? For example, a result as simple as cutting the grid and switching to the battery when a given Kilowatt/h is reached adds value. Naturally, the desired outcomes can be much more complex and might require AI or specialist interpretation to make suggestions. Either way, we have moved from a POC to a POV.
For a POV to succeed, you must do the necessary groundwork. You need to understand your client's business and its processes. Good tech can't fix a broken business process. One must conduct a root cause analysis to establish whether the solution solves the most critical problem. Notably, you need to establish the time in the field and cut-off dates before the POV is deployed, with the next steps in place when the project achieves certain milestones. You want to avoid POVs running for months at your expense.
As an example, we can look at a Smart Fridge solution we were recently involved in. At the time of writing, the project is in a POV phase at our client. The solution can monitor door status, give a GPS location, and measure current and temperature. Nothing extraordinary, but the magic is in how we utilise the data we gather. After some initial consultation with the client, we understood that they have a massive overhead due to technicians needing to be adequately equipped with the correct spares when they go in-field to repair fridge breakdowns. When technicians are blind, they must first travel to the fridge to assess the issue and then collect the parts, leading to a longer turnaround time and unnecessary costs.
To solve this issue and to add value to our client's process, we tailored our solution to measure two crucial temperature points on the fridges, amongst two other variables, which we then used to help determine the problem. We then communicate this data in an automated fashion to the service managers, who, in turn, can better manage their technicians since they have a much better idea of what the breakdown could be. Using the same temperature data, we can apply machine learning and predict MTTR – mean time to repair, or MTTF – mean time to failure of the assets to improve further predictions of breakdowns and recommend efficient processes, leading to a direct cost saving.
There are cases where a POC might be relevant. We see this usually when a system that works well in one industry needs to be retrofitted to work in a different industry. In this case, it sometimes makes sense to run a POC to establish whether what worked in one sector still holds and is valid when jumping to other market verticals. In these cases, a POC makes sense and can add value to a project.
Share