As your fleet of connected devices grows, so the tools and techniques needed to manage them changes.
Here we define the stages and explore which kinds of management you need for each stage.
But first, let's clarify the 3 "layers" of IoT management. Starting at the bottom:
- Device Management ensures that the device is correctly "provisioned" - it has the right security credentials and is running the right software. These lower layers of the technology stack are very device-specific, so are usually provided by the device stack vendor.
- Network Management ensures that the device is connected over its wide-area network. For example, in a cellular-connected device, it's about SIM provisioning, billing etc. and is provided by your cellular comms provider.
- Service Monitoring/Management is about making sure that the device is actually delivering value to the customer. A drink vending machine might be powered-up and connected, but out of cups. So Service Monitoring operates up at the Application level, watching the device in operation, seeing how customers are interacting, and measuring the service, the value delivered.
The first two of these types of management are essential technical components even in the very early days. As the fleet grows, a third type of management - Service Monitoring/Management really comes into its own. It does change a lot as your fleet grows. It's not needed in the very early stages, but becomes increasingly indispensable as the fleet grows (so you should plan ahead), and has several different use-cases which we'll discuss here, as we focus on how IoT Service Monitoring/Management helps you manage your IoT devices.
The Service Monitoring journey
While your exact mileage will vary, from our experience across a wide range of IoT device types, there are clearly identifiable stages in every IoT growth journey. The chart below shows these as rough "orders-of-magnitude" from 10 devices deployed, up to one million deployed.
Starting at the bottom, the first 3 stages (R&D, trials and Pilot) are all quite small-scale. Certainly during the first two of these stages an ad-hoc, manual approach to management and monitoring is probably just fine. In fact, the manual approach can be positively beneficial, as it allows humans to see and identify all the sorts of surprising ways that the device goes wrong (or the user gets "stuck") and either feed them back into product development, or start to think about what business processes will be needed as full rollout commences. We can call these first 3 stages the "build" stages. Building things for the first time is always hard, with lots of surprises, but has the nice characteristic that you only need to do the R&D once, then you can amortise all that investment of money and effort against large production volumes in the future.
But once you cross the threshold of about 1,000 devices deployed, you discover that running your device fleet is even harder than building it. That's for two main reasons:
- IoT devices are deployed in the real world, where anything that can happen will happen - there are lots of uncontrolled externalities. This makes the job of managing the devices hard - at each new order of magnitude of scale, you'll discover new types of issue, and then have to characterise and resolve them.
- But the real killer is that - unlike building IoT - the challenges of running a device fleet do not amortise with scale. As you go from 1,000 devices deployed to 10,000 devices deployed, if you change nothing else then the job of running those devices gets 10x harder. You'll spend 10x as much, need 10x as many people etc. Clearly that's unsustainable, which is why a fundamentally different approach is needed. With the right processes and tools, a slowly-growing operations team can support a rapidly-growing device fleet.
Service Monitoring use-cases
Now let's break Service Monitoring into its key use-cases, and see which of them is relevant at each stage of your growth journey.
Starting at the bottom...
R&D: In the early days, with a few devices sitting on a lab bench, you really only need the Visibility aspects of Service Monitoring - the ability see what you have deployed, where it is, who has it, what software and hardware versions are running, etc. You don't need a tool to do this, you can do it in a spreadsheet - though a tool certainly makes it easier, especially if more than one person is involved in deploying and running the devices.
Trials: As friendly users start to trial devices in the field for the first time, you'll start to need some kind of Monitoring too. How many devices are working? How will we know when one fails? Do we have any reliability or usability problems? e.g. Are batteries running flat? Are we losing connectivity? You'll also need some kind of Reporting to summarise where your trial is at (e.g. "of our 100 pre-production units, we've currently got 46 live in the field, the others have died with various problems, and of the live ones, we're seeing 5 with comms problems, and another 8 seem to be having a problem with short battery life".
Pilot and Early Rollout: As you trials expand to now include paying customers for the first time, the above use-cases of Visibility, Monitoring and Reporting all start to become a bit more serious. It gets harder and harder to keep track of the big picture of your device fleet by using just manual spreadsheets. You'll also start to notice that some problems are systemic - they occur regularly with predictable causes - and so it's worth starting to build business processes to identify them and address them. This is the beginnings of Troubleshooting and Automation. If battery life is an issue, then a) how can a customer service agent detect when a device battery needs replacing? and b) what actions should they then take to resolve the problem? The Pilot stage is the time to when you need to be prototyping all the business processes that you'll need for subsequent stages. If you can find a way to automate the solution to a systemic problem (e.g. by sending someone an email asking them to replace the battery) then this will pay huge dividends in terms of speed and cost to resolve, while boosting customer happiness.
Main Phase and Maturing: By the time you reach this kind of scale you will probably have at least one "big" customer. In a B2B scenario then one of your customers may be key to your success, and/or have a lot of devices. In a B2C scenario then you may have a channel partner customer who has lots of their customers using your devices. These big customers have a lot of klout - so as they start to work out what good-enough looks like, they'll start to hold you to it. Which is where SLA management comes in. Service Monitoring is both the place where you and your customer defines good-enough, and also how you ensure you deliver it. Read more about SLAs here.
You'll notice on the right hand side of the diagram above that we have highlighted how Flexibility is important in the early days, but Efficiency becomes increasingly important later-on. In the early days, with a small number of devices, it is often necessary to make changes such as software upgrades, and it's easy to do so because you'll only be touching tens or hundreds of devices. The "cost per device" of doing something is dwarfed by large fixed costs such as R&D engineers. So flexibility rules.
But as the volume grows, the "cost per device" becomes the dominant factor, and so efficiency now starts to become the most important aspect. Since people usually remain your largest cost at any scale, this is primarily a question of how to make efficient use of your customer support and operations staff, by empowering them with tools which give them leverage to understand and manage an ever-growing device fleet - to see the "wood for the trees".
IoT Service Monitoring is a collection of several use-cases. At the very early stage on the lab bench, none of these is essential. But there's a rubicon to cross, typically at around 1,000 devices deployed, where Service Monitoring shifts from being a nice-to-have to becoming an essential tool to ensure that your IoT devices are consistently delivering the value that your customer is paying for, and that you build an increasingly efficient operation to manage devices as you scale.
Read more thoughts about managing IoT:
|Is managing IoT really any different from managing anything else?|
|Managing software updates|
|Easy-but-great IoT customer experience||Should you build your own Operations tool for IoT? Probably not.|