The internet of things offers such exciting possibilities that it’s difficult for organizations to resist the urge to chase the latest shiny object without thinking through the business case.
Return on investment is what decides if (or when) an IoT deployment moves beyond concept to prototype to production. Without a clear ROI, IoT — or, for that matter, any initiative — may never make an impact. So, how can ROI be calculated for IoT initiatives?
Here are five questions to ask when determining the business case for an IoT initiative:
1. What problem are we trying to solve?
Having a real business problem to solve is the first step to creating business justification. A problem is either a current loss or risk — operational efficiency gaps, manual errors or safety risks, for example. Or, it is potentially untapped revenue — using contextual content to target better, for example. One may argue that technologies can open hitherto unknown opportunities, and while true, such unknown opportunity must be projected to translate to reality soon.
Once a problem has been identified, the next step is to validate this with experts. Such validation will result in either strengthening the case or it may reveal that the problem actually isn’t critical or significant. Recently, my organization was asked to propose an IoT technology to track asset location in a factory. A quick check with the shop floor revealed that most key assets were fixed, and the actual need was to do a periodic audit of whether or not these fixed assets were where they were supposed to be. Our solution subsequently changed to automate these audits instead.
2. How is it dealt with today?
Determining where operational inefficiencies are with current processes is especially important. This will provide a way to calculate the notional value of such losses.
As an example, for a factory, we noted that certain machines were stopped multiple times to reactively fix point problems. We noted that any time the machines had to be stopped and started, waste was generated. This allowed us to calculate the cost of loss. In the earlier factory asset tracking situation, the current method was to have a person do a pen-and-paper audit. The question is whether it’s worth it to fix this problem.
For the cases of revenue uplift, the equivalent is to identify what the competition is doing, if anything.
3. What are the costs of not using IoT?
There are two aspects of “cost” here. One is notional cost — “What could we have saved if we had automated this process?” The second is the actual cost of the process — “It costs us one person’s salary to take readings manually.” Additionally, there is a cost of risk — “If this valve blows, it would cost us $x in productivity loss, and $y in damages.”
The case for predictive maintenance, which is one of the key use cases for industrial IoT, hinges on these costs; by predicting a failure before it occurs, the cost of that failure is alleviated. Note that costs of risks are weighted with probability, so a very low probability risk with high value is not necessarily critical for a business case.
For new business opportunities, the cost is that of lost opportunity — “If we had data monetization, we could have an additional revenue of $x”.
4. What will I gain?
It may be straightforward to take the costs and equate those to gains to be had. However, one of the most challenging aspects is attribution — can I attribute all of these gains to this specific IoT initiative? This is most difficult for cases where the scenario is revenue uplift. As an example, we advised a hospitality customer that, by targeting contextual content based on location and profile, could result in an x% increased purchase likelihood. Unfortunately, purchase likelihood is influenced by many other things as well — an ad campaign, competition activity and so on. This is why IoT use cases of operational efficiency are easiest to justify, while those that are consumer related are far more difficult. In the above example, we couldn’t go beyond the concept phase.
5. What will this cost?
IoT deployments have two cost components. One is upfront: solution build, procurement — both hardware and software — and underlying infrastructure. Additionally, there is a recurring cost of running the deployment — infrastructure, software and hardware maintenance, and communication. Cloud-based infrastructure helps reduce capital expense for server hardware, but costs of establishing local networks and so forth would still be incurred. The total costs including both components when compared with gains over, say, a two-year period, then indicate if there is indeed a business case.
The upfront cost of deployments, combined with IoT adoption being nascent in various sectors, increases the perceived cost of failure and reduces the possible gain. One of our customers was looking to monitor coolers remotely. The cost of the cooler was less than $500 — the depreciated value would be even less — and the cost of the hardware to monitor was about $50, or 10% of the cost, which was unacceptable in this scenario.
Customers are looking for a fully managed, operational expense-led model. In this model, the vendor takes the onus of the upfront investment and recovers it over time. This is possibly more expensive in the longer run since the vendor may bake in the cost of taking up risk, interest on capital and so on. However, the risks for customers are mitigated. Subsequently, the risks for the vendor are increased.
From proof of concept to production
While ideally a business case should be established first, customers sometimes look to start by doing a proof of concept or a pilot. While that’s okay, at a minimum you should do at least a back-of-the-envelope calculation to make a quick go/no-go decision first.
Given their urge to adopt IoT, enterprises must exercise caution to ensure that there is adequate reason and justification for its adoption. Or else it will remain nothing more than a nice demo showpiece.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.