“All happy families are alike; each unhappy family is unhappy in its own way.” Every time someone tells me about their struggling IoT projects, I am reminded of Tolstoy’s intro to “Anna Karenina.” That’s because every IoT project struggles in its own way — even as participants expect to use many of the same technological building blocks as others to make it work.
Thankfully for those still struggling, the Industrial IoT Consortium has published research on more than 30 of its testbed projects to determine what makes them succeed and what makes them fail. The IIC lays out some rules that I’ve been trying to hammer home for quite some time.
First, however, know that there are going to be three stages of any IoT deployment (the report only covers the first two): the pre-pilot phase, the pilot phase, and the scaling-out phase. As the IIC notes, in order to succeed companies should find a use case, but establish different goals for that use case in the pre-pilot phase than in the pilot phase. In the pre-pilot phase, companies should focus on understanding conditions in the field and ensuring they define reasonable expectations.
For example, figuring out what tools work with a company’s environment and its machines might be a part of the pre-pilot phase. It’s also in this phase where a company may realize that its business goals don’t align with the way information is collected or analyzed, necessitating a change in strategy. So, having a pre-pilot, investigatory stage both helps to keep management from killing a project before it finds its feet, and helps build trust between management and the people trying to deploy new technology.
In the pilot phase, after some of the goals have been tested and the anticipated outcomes have become more clear, companies should focus on understanding all the trade-offs associated with the deployment. While an IoT deployment may help meet a business objective, for example, it might have hidden costs, such as aggravating employees or creating a system that is vulnerable to failure. New technology might introduce security risks, and require a company to mitigate the new problems.
As the report notes, it’s important at both the pilot and pre-pilot stage that companies make sure everyone involved has agreed upon the goals of the project and the terms being used. I often see a misalignment there, even when companies talk about something as ubiquitous as edge computing. One person might define the edge as a machine analyzing data from its own sensors while another person might define the edge as a server on a factory floor analyzing data from several machines. Once terms are defined, companies need to ensure their business goals are narrow and well-defined. For example, they shouldn’t just make “optimizing a particular manufacturing line” the goal, but make clear whether the optimization is aimed at faster products, fewer defects, saving energy, or some combination of all three.
The biggest mistakes, according to report author Jacques Durand, Director of Standards and Engineering, Fujitsu North America, come from a failure to understand the role of people in the process. As he notes, companies are already trying to implement IoT solutions to help automate their jobs, but people are still essential to those jobs.
With IoT business processes can change, and people make or break a process. An employee’s expertise and experience are also crucial when it comes to training an artificial intelligence. So for now, employees are valuable for training and keeping things running smoothly. “Down the road, we know automation is the way to go,” writes Durand. “But today we still need people.”
With that in mind, Durand has another suggestion for companies that want to learn from the IIC testbeds: think about your vendor relationships carefully. The most successful implementations required the vendor (traditionally an IT provider) to have more of a partnership with the customer. This fits with what I’ve been saying for the last few months about how IoT will force companies to have to move from transaction-based agreements to relationships. Durand notes that in the testbed deployments, IT staff had to understand exactly what a customer needed to do before they could design products for it.
It’s one thing to expect corporate buyers to adjust to working with software productivity tools, but it’s another thing entirely to try to sell a manufacturing firm on a computer system designed to handle a highly individualized factory. This focus on relationships is born of a realization that every IoT implementation is unique. Which brings us back to Tolstoy.
On the surface, all of the IIC testbeds may look alike in their successes. But when IoT implementations fail, it’s usually because of a unique circumstance or individual. This report helps companies plan for that.