In common with many engineers, I do enjoy shopping for new power tools for my workshop. I therefore often find myself totally absorbed in hardware stores, captivated by new innovative devices for solving almost any problem. The low cost of modern mass-produced tools, particularly those from China, make it affordable to try out something new at relatively low risk. Sometimes, I leave with a new shiny object, full of intent to use it when I get back home. Frequently the new tool is used just once and is then delegated to the back shelf of the workshop, having served a very brief purpose.
The reason my track record in buying power tools is not that good, is that in most instances I purchase the tool without a clear understanding of the problem I want to solve. While this might seem like a trivial example, it is unfortunately analogous to the way many companies approach implementing information technology solutions. New technology becomes available, and we become captivated by ‘shiny object syndrome’; feeling an urgency to try it out so that our organisation is not left behind. We push ahead with a technology pilot project, which inevitably demonstrates the potential of the concept. But, in most cases (more than 75% for IIoT projects according to ARC Advisory Group), the initiative ends there – at the pilot phase.
According to Business Insider(1), manufacturing companies will spend about $70 billion on the IoT in 2020, up from $29 billion in 2015. The companies making these investments are set to increase their operating income proportionally; and as a result, the competitive landscape can be expected to shift.
Understanding the business problem
The Industrial Internet of Things (IIoT) is a collection of emerging technologies that together have the potential to create significant business value and even create new business models. But you will not get much traction with an IIoT project without first precisely understanding the business problem you need to solve.
The nature of the business problem will generally be different for different industries, for example:
• In mining the challenge might be to bring together field and business data into a common platform to generate useful operational insights.
• In a process manufacturing company, the requirement might be to improve energy efficiency, production performance and safety.
• In a discrete or batch manufacturing process the challenge might be to improve product quality, traceability, planning/scheduling and/or to reduce working capital.
• In consumer industries the challenge might be to gain deeper insights into actual customer use of the product to help prioritise new product research and development.
• In service industries the challenge might be to automate and streamline monitoring of equipment performance so that maintenance is proactive and service levels are improved.
For each of these examples, the specific business case for an IIoT implementation will be unique.
At the beginning of an IoT project, it is important to start with defining the exact problem you want to solve. This step must occur ahead of finding a technology solution. A well-defined business problem must be very specific. A poorly defined business problem like ‘improve operational performance’ is not as useful as ‘reduce the total cost of field service by 25% this year by remote monitoring and proactive maintenance of all compressors installed at customers’.
Not all of these technologies will be required to solve every problem. But, it is important when selecting a platform to make sure that it can grow to accommodate future requirements. The selected IIoT platform architecture should allow vertical integration (business processes connected to sensors) as well as integration along the value chain (connecting suppliers, manufacturing processes, logistics and customers). When designing the solution there might be a number of alternative approaches, for example:
1. Best-of-breed point solutions integrated through middleware.
2. Simplify towards a single vendor solution where possible.
3. Extending/upgrading your existing platforms systems.
4. Sandbox your legacy systems and surround these with loosely coupled proof of concept/pilot solutions.
5. On-premise versus cloud deployments.
6. Bespoke development versus package solution.
Selecting partners for an IIoT implementation project
Your choice of platform will involve assessing the capabilities of your existing IT/OT environment together with a formal evaluation of specific vendor products. The vendors involved might include control and automation, MES, business systems, cloud platform providers, managed service providers and so on. In many cases, your evaluation will be an iterative process where your solution will be influenced by the exact capabilities of the vendor solutions. At this stage of the process, you should introduce the business stakeholders to new ideas and technologies (for example artificial intelligence, digital twins and 3D printing), and work with consultants and vendors to help you identify possible breakthroughs. Other considerations at this stage will be cybersecurity processes and data/privacy protection.
Many vendors are competing for market share in the fast-growing IIoT space and not all of them will survive. Selecting the right strategic IIoT partner is therefore also very important. Traditional instrumentation and control vendors are building new capabilities into the cloud from which data becomes universally accessible. Business systems vendors are working to incorporate data from physical sensors into their business applications. Middleware vendors are deepening their integration and analytics capabilities. And so on.
Develop the business case for investment
Having developed a good understanding of the business problem, identified several alternative feasible technologies and selected some potential partners; the next step is to estimate the costs of the solution and develop a detailed business case. At this stage, you will typically still be dealing with a number of alternatives. The process of selecting the recommended solution will involve ranking alternatives against those criteria that are important to your business. These might include an assessment of vendor risk profile, total cost of ownership, time to implement etc. The costs, together with the relative advantages and disadvantages of the alternatives, are ranked and scored to eventually come up with a recommended solution.
The resulting business case for an IIoT project will typically include:
1. The problem to be solved.
2. Alternatives considered.
3. The recommended solution.
4. Risks and opportunities.
5. Human resources considerations e.g. mitigating job losses.
6. The project execution strategy (implementation approach, schedule, reinvestment strategy, pilot and rollout plans, resources, partners etc.).
7. Quantified business value (ROI, compliance, risk etc.).
8. Cost analysis.
Reap the reward
Abraham Lincoln once commented: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” I suspect that in business he would also have spent most of the time on defining the business problem.
Provided the IIoT project remains focused on solving a well-defined problem, it has a reasonably high chance of success. During the project execution, proactive management of risks and opportunities should continue to ensure that the project outcomes always remain aligned to the business requirements. Remember that business is never static, and nor is technology – be prepared to redefine the problem and pivot to a new solution when it becomes necessary.
Back to my original analogy of buying a power tool from the hardware store: How much more sensible is it to first properly identify the problem before chasing the ‘shiny new object’? If we understand this simple concept, then why not follow the same common-sense approach in implementing IIoT projects in our businesses?
References
(1) Business Insider ‘How the Internet of Things is revolutionizing manufacturing’ https://www.businessinsider.com/internet-of-things-in-manufacturing-2016-10?IR=T
This article was first published on SA Instrumentation and Control.