Internet of Reliability Challenges

If internet-connected reliability operations were easy, everyone would be doing it, right? It is no secret that the journey into the Internet of Reliability can be an uphill struggle, with many projects getting stuck in what is often referred to as “pilot purgatory.” Learn how to navigate and overcome these common hurdles.

Welcome back to Noria's new web series called "The Internet of Reliability." I'm your host, Jeremy Drury with IoT Diagnostics, and we're here to be your guide into this new data-driven, internet-connected reliability operation.

So far, we've talked about some higher-level concepts — what is Industry 4.0, the internet of things and the internet of reliability — and we even got into the fully realized value of doing all of this. I'm going to take a different approach today. I'm going to look at the other side, because if you've been following any sort of media, you know this stuff isn't exactly easy. In fact, the often-cited Cisco study from 2017 suggested that 70 percent of IoT pilot projects failed. Some would call this pilot purgatory, meaning that the projects started, but they never really got anywhere.

I want to talk with you today to help you understand why some of that happens. I’ll look at three different reasons why IoT projects or internet of reliability projects get stuck in this idea of pilot purgatory. Those three reasons include dealing with the IT department, sealing and getting funding and/or buy-in from upper-level decision-makers, and finally having a nice relationship with all the different emerging IoT platform providers out there. I think we have some good ideas on how to get through each one of those hurdles. The first one is probably the most important: dealing with the IT department.

IT Department Challenges

Let's put ourselves in the IT department’s shoes. I recently read that for small to medium-sized businesses, there is a hacking attempt every 43 seconds in today's world, and that number is getting faster and faster. Imagine putting yourself in the IT department’s shoes where they must be the first line of defense and guardian against these types of attacks into the organization.

So, what are we going to do? We're going to ask them to put more devices or more entrances into their network because that's what we need in order to fully realize data getting out and data coming into the business. Sure, we're going to potentially offer up more access points for hacking attempts and different things like that, which will probably put a lot of IT departments on the defensive, but there are ways around that.

What I would always suggest is getting all the information you possibly can for your IT department in advance. What are some of those things? That's going to be who your potential IoT platform providers are and the devices they're offering to you, what level of encryption comes in with those platform providers and those devices, and how they connect — Wi-Fi or cellular — different things like that. Are you using a cloud service? If so, what cloud service? What amount of data is being transmitted and where is it going? Who has access to this data?

You have all this subject-matter expertise. You are the SMEs at your organizations, and you are pulled in a lot of different directions. Every time an asset goes down or a process starts to break down, you're pulled in. It's a very reactive place to be. So, even though you may know these assets and processes and your approaches to reliability better than everybody else, you can only take that so far because you're one person. And that's the life of a non-connected reliability engineer, reliability manager, director or whatever your title may be.

If the first time you sit down with your IT department, you say, "Hey, I want to throw an IoT device on the network," or "I want to start an IoT platform project, and here is all the information that you need to know about this device," I can almost assure you that they are going to be much more receptive to look through that checklist. I would encourage you to get that information from your IoT partners and platform providers upfront, so you can get over that barrier of the IT department.

Getting Buy-in

Now, let’s shift gears to think about the buy-in side of this. When you start thinking about more of a massive build-out of sensing capabilities and network capabilities, sometimes this can flow into more capitally intensive types of projects. The return on investment (ROI) is getting better, and doing these kinds of build-outs is becoming more cost-effective, but sometimes it still requires some sort of higher-level buy-in into the purchasing decision. That puts us in a spot where we've got to know ahead of time what kind of ROI this project is going to bring for this organization.

Two things to keep in mind with this is you want these early projects to be simple and specific. When you look at your operations, I want you to find a critical process or a critical application inside your operations. Inside that, I want you to find a critical piece of that process or operation and then go even one step further and find one or two parameters inside of that piece of the application that you feel is critical to your uptime.

One scenario would be to think of a hydraulic pump in an injection-molding application. This pump is largely responsible for getting fluid into this application to maintain uptime. I could argue that if the application is plastic injection molding, the asset is the hydraulic pump. I want to look at the flow of that pump to determine if there are inefficiencies developing in that process.

So, I would want to look to an IoT platform provider to say, "How can I actually sense up doing a flow measurement? Can I put some sort of flow device and get that information out and be able to use it from a networking standpoint to influence my decisions?" Then I can start to say, "OK, I can do better about predicting potential downtime with flow inefficiencies, and therefore I can actually flip that into increased uptime."

Dealing with Providers

Now we can move to a spot where I'm potentially suggesting that I can show you how to generate more revenue for your company. The third piece of this, and perhaps the trickiest because it doesn't have clean and clear answers for you yet, is dealing with the IoT provider side of this. What I mean by that is a lot of companies are getting involved in this IoT place, inside this emerging internet of reliability, from big players to small players and international players. The problem with that is whether it be greed or good ideas or whatever, you're starting to find more and more siloed, turnkey, suggested providers, meaning that, "OK, to use my devices, I need you to use my network, my cloud, all these different types of things." No company is set up to do all the measurements that you need inside your operations. That puts you in a tricky spot where you're trying to manage all these different silos of IoT build-outs in your plant. That becomes a problem.

The way to get over that hurdle is to continue to look for providers who allow each other to work more with each other. Are they able to share data back and forth inside one master network or two networks?

The second part of that, and it's a tough pill to swallow, but I'm going to ask you to be patient, because I can almost promise you that in the near term, top emerging networks are going to supplant themselves into this space to provide some commonality across the IoT build-out. I would encourage you to continue to experiment on the sensing side and on the general networking side with the IoT devices and wait and see as the master type of network providers prevail into this space.

So, there you have it — three hurdles and three practical ways to get ahead of these hurdles, to get over these hurdles, to help get your pilot projects out of pilot purgatory and get them ascended faster into your organization so you can build this out and truly realize the ROI.

Thank you for watching today. Again, this is Noria's new web series called “The Internet of Reliability.” I'm your host, Jeremy Drury, and I look forward to talking with you again soon.