IoT Field Notes: Building a Business Case

An important component of any IoT initiative is going to be the Business Case. Getting past the “strategic imperative” and the “cool technology”, how are we going to build a reasoned case based on ROI?

At my our company, we are still building a template for our business cases; as I have noted in my last few posts, there is a lot of commonality and patterns in these projects, and an IoT Business Case fits nicely into the template approach we use elsewhere. Our template is not ready for prime time yet, but the general structure (and a lot of interesting bullet points) have already been identified.

Benefits: Revenue and “Soft Stuff”

First and foremost, we assume / expect these efforts will generate organic growth – top-line revenue for the Business Unit. As discussed in the previous Size of the Prize post, that revenue can be generated in a few different ways:

• New Product Revenue: One-time purchases of new and/or updated products. If this is a line extension or add-on module, we will call out only the incremental revenue generated.
• Retrofit Revenue: One-time purchases; can existing customers purchase add-ons to their existing devices to enable data collection?
• Data / Service Subscription Revenue: Recurring purchases of data access, reports, and analytics; proactive product maintenance delivered as part of a monthly fee.
• Analytics Services Revenue: Recurring purchases of analytics and consulting services based on the data collected.

Other potential benefits have been identified in our discovery sessions. These are generally one-time impacts – not trivial, important to add, but not necessarily game changers. Or, these could be the classic “soft benefits” – hard to quantify and subject to a certain amount of risk. Nevertheless – all very important to add, since IoT as a growth / innovation strategy is a risky proposition in these still-early stages.

• Reduce Warranty Reserve: Gathering operational data for your devices in the field? What if you could show, with hard numbers, that your devices truly outlast current warranty estimates or expected end-of-life projections? With enough data, you can get the number crunchers to reduce the funds held in reserve against future warranty claims. This can be a one-time impact – or you could phase in the reduction over time – but each change in the Reserve figure has an impact on cash flow.
• Demand Visibility for Parts and Service: Supply chain planners, purchasing, and your operations team would love to get better visibility into future demand for material and people resources. Advanced information leads to more accurate plans – reserve stocks can be lowered if demand is falling, or raised (to prevent customer delivery problems) when the signal says demand is coming. And workforce planning can benefit as well – a better view of the future will make scheduling easier.
• Customer Lock-In: Make it easier for the customer to do business with you, and you make it harder for them to switch to the competition. A simple truth – and something that IoT features and functionality should be able to deliver. Can you automate transactions – calls / messages into service, proactive scheduling of maintenance? Can you provide timely information on system performance, and predict when maintenance will be required – eliminating surprises? Can you facilitate customer feedback, developing a better picture of their needs (and hopefully making it easier to aggressively deliver on those needs)?

Costs: to Build and to Run

Of course, none of this comes for free; there will have to be incremental investment that will offset some of that revenue.

• Cost to Build: Covers labor and equipment required to design and build these “smart devices”, as well as the cloud databases, mobile / smartphone apps, and analytical tools. If the work is done in-house, follow the costing convention used at your business for all other engineering and development work; if the build process is outsourced, add it all here; you may want to spread things out over a few years by capitalizing the costs (check with your finance department regarding the proper accounting treatment).

Note: Do not fall into the mental trap of assuming these are strictly one-time costs. If you subscribe to a Minimum Viable Product philosophy, your products and services will evolve after launch. When you actively court feedback and listen to your customers (you are planning on doing that, right?), you will soon have a healthy backlog of feature requests. Clearly, you will be continuously developing the product for many months after initial release; it’s a pattern seen with consumer grade offerings, and your customers will likely expect ongoing innovation.

Since speed is of the essence in the short term, it may be wise to outsource the build, slashing the learning curve with your Engineering and Programming teams while getting something to market quickly. However, there may come a time when you will choose to insource ongoing development work; if you see that as a possibility, account for it in the Business Case up front.

• Cost to Maintain: There will be ongoing technology costs – you’ll probably host these databases and apps with some form of cloud provider for reasonably high availability, since your Things are collecting data 24x7x365. These services are typically priced based on consumption; we should expect low costs in the beginning. Since we aspire for roaring success and fast growth, however, it makes sense to model the ramp-up costs for compute, storage, and services as your user base and volume ramp up. There may be tech maintenance costs as well – depending on how completely you adopt a PaaS architecture vs. IaaS, you may be paying licensing and maintenance costs for foundation software.

But the tech costs will probably be smaller than the incremental people costs you will have to plan for. Who will take the support calls from your users when they have troubles with their smart phones? How will the structure of the orders and payments change your Customer Service, Collections, and Cash Application processes? How will you handle Returns and Credits? Once again, we will be faced with business process changes that are much different from what the typical manufacturing company has to deal with – will we push that work onto existing headcount – or staff up? One alternative might be to connect with an external partner – leveraging their experience and resource flexibility, and delaying the need to commit to incremental headcount until the demand for these new products and services proves out.

• Cost of Goods: Don’t forget to account for any incremental material costs; sensors are getting cheaper every day, but they aren’t quite free. Product Engineering will know to do this – just remember to bring that impact into the overall payback / profitability calculation.

Other Considerations

The final format of your business case will depend on the style of presentation preferred by the decision makers – and how they see investments of this type. Is this an incremental R&D investment? Then maybe a simple Cost / Benefit / Payback model will be required. If, however, a larger investment with a longer break-even period is required, maybe a return model that compares this investment with, say, and acquisition or other particularly large capital project.