By Peter Thorne
In order to avoid disaster and reap the benefits produced by the Internet of things, the nascent technology requires a response from several departments, including in-house IT teams in product development, manufacturing and field service organizations.
To operate efficiently and successfully, the Internet of things needs IT services. The electronics and software that are embedded in a product are, of course, essential for a given device to enter an IoT ecosystem. Yet just as essential are the IT services that handle the information and service requests generated by these embedded systems. These IT services will be a core part of smart product and service delivery, and this increasingly involves everything electric.
For many product types, the embedded electronics and software can be quite specialist, perhaps involving integration with real-time control systems. This is natural territory for engineering teams.
The back-end IT services provide an entirely different area of focus.
These are the IT systems that look after the “things” in the field. For these IT services, it is non-engineering IT teams that have the right background. But will this make them the natural first choice to create and maintain the capability? A lot depends on the way in which IT leaders react.
As always, there is a spectrum of choice. Planning to architect, develop and deliver these capabilities? Or watch as groups in the company recognize IoT opportunities and start signing up third parties? If you are one of a company’s IT leaders, you already know that groups from sales, engineering and service have been looking at the options. Corporate IT may have been asked by top management for information, briefing and assessments. The momentum is growing.
For CIOs, the growth of IoT is creating a major decision point. For some, the IoT challenge is irresistible. It represents something that is not only critical (such as the ERP system), but is also truly at the sharp end of their companies’ reason for being. The cost-efficiency and razor-sharp administration of a great ERP implementation may be important, but it’s not usually the subject the CEO chooses to talk about at an investor meeting, nor is it a candidate for the unique selling points the sales teams want prospects to hear about. For this group of CIOs, the choice is clear: Own the IoT data, architect the systems, guide the line-of-business groups, run the projects and show the CEO that IT is not just a cost to be squeezed, it can be a source of core value to the customer.
For other CIOs, the balance is different. If the business has a diverse set of business units, it may well be that the key value-add from a central IT function has much more to do with governance, risk-management and compliance. So the focus is the vision of consistency and integration with core corporate systems. This does not mean that IT should be the source of rules and restrictions that stop things happening. Far from it, IT’s experience of agile development projects will be a key source of risk mitigation, and the way to ensure visibility of complex change. This is the capability which will enable the company to run experiments, learn from them, engage stakeholders and identify the most effective way of creating and operating IT for IoT.
Here are some examples in which an IoT capability depends substantially on the nature of the back-end IT services used by smart products.
Configure to contract. Standard products that are configured for specific uses are not a new concept. In the past, the local sales office or distributor might have earned points of margin for setting switches to match the needs of an international region. More recently, they may have needed to apply the bar code that the product reads on first start up to configure itself. The IoT version of this is that the product phones home to find out what set of functions it should deliver during its current assignment. For the CIO, triumph will be actual configurations that match sales orders. Disaster will be a workaround in which field service activates all functions, because no one knows what was ordered.
Usage and performance analysis. The engineering department wants to monitor in-service performance so the next version can be made better. Warranty processing wants to check claims and be sure the product was operated within its specifications. Field service wants to run a help desk where products can trigger alarms and service people can connect to them to see its status. This all starts with connectivity, but the needs of the three groups are different. Engineering wants to see and think about all the information. Field service needs to work through a diagnostic or adjustment process. Warranty needs legally defendable records of exceptions. For the CIO, triumph will start with a briefing to the executive team on the implications of direct visibility of products in service. But if design faults are visible earlier, will this mean a non-negligent company must fix them sooner? What if sensor readings show the help desk that a pump on the other side of the world is about to burst into flames? Disaster will be much later, in a court case, when counsel asks why the company failed to take note of temperatures consistently higher than expected in a particular model of pump.
Online upgrades. Sales would like to make use of the new over-the-air software upgrade capability and change the way that new features are offered and delivered to customers. Is the service contract valid; is this part of a teaser promotion; has the customer signed off on a change to the product’s capability? For the CIO, triumph will be integration with both the CRM system as well as the as-delivered information held by field service. Disaster will follow a period of ad-hoc upgrades during which no one kept track of which upgrades were sold, which were free of charge and which were 30-day trials. It may be the calls from customers with products damaged by incorrect upgrades that are the first indication of the problem.
Predictive service. Customer service wants to go through a transition in which they offer a better service than existing third-party service groups. So they want to invest in the data analytics that will interpret a product’s sensor readings and predict a need for service. They’ll reduce costs by eliminating unnecessary regular maintenance, and they’ll get better customer satisfaction scores. For the CIO, triumph will be suitable visibility (of data capture, analysis and actions); appropriate links to customer and product systems of record; and cost-effective hosting (customer, third party or in-house) for the required cloud systems. Disaster will follow if the ad-hoc approach used to get the idea launched-a service engineer claiming expenses to cover cloud time for analysis of data collected from a set of customer emails–becomes the long-term way of working.
If you are an IT leader in an organization that might be affected by IoT, the key is to get involved in the early conversations. Show your line-of-business teams that the IT team has something to say and something to offer in relation to new business opportunities such as those discussed above. Show the executive team that alongside the opportunities, the types of complexities and risks that must be handled are familiar territory for IT professionals.
Everyone knows the way Steve Jobs changed the game by describing his new audio player as “a thousand tunes in your pocket,” but of course it was the ecosystem of IT services that supported the player that was a vital contributor to its business success. Help your organization beat the competition by encouraging experiments and prototypes, but in a framework that will use the results to make your IoT IT services a solid, fast, scalable platform for the future.
Peter Thorne is director for research analyst and consulting firm Cambashi. Peter has more than 30 years of experience in applied information technology and works closely with IT vendors to match their products and services to real industry needs.
