While each of the Personas discussed in the first segment of this blog have very different purposes and needs, they all require data from a machine or asset, yet not all machines are able to communicate the same information to one back-office system. And in most use cases the “fleet” is made up of different makes and models of machines causing even more challenges. So how do you support a mixed asset or fleet environment to gain actionable intelligence?
A majority of solutions today that support this mixed asset (one make, many models) and/or fleet (many makes, many models) are derived from a vertical specific or niche need in the marketplace and require aftermarket hardware to be installed on the machine. An example of this is CiDRA’s SMARThatch™ solution where they are providing preconfigured bolt on sensors and equipment to allow quality technicians the ability to remotely monitor the quality of concrete while it is in route to the construction site. In this case they are selling the hardware, transport and back-office experience for use on a majority of cement truck makes and models. This scenario highlights the challenge for OEMs who are building machinery and systems that are being leveraged across numerous vertical markets.
Let’s take a look at a couple of options being implemented to help OEMs solve this particular problem.
Platform-to-Platform
Once a device is programmed to communicate with a specific back-office, it’s no easy task to change that connection being that it could take months of code development and testing to properly transition. With a majority of back-office environments, Application Programming Interfaces (APIs) are made available so that data sharing can occur between different systems. These APIs can be leveraged for Platform-to-Platform communications that will allow desperate Telematics systems the ability to share insightful data into multiple solutions that best fit the Personas being served.
Hardware Redirection
A second option utilized within Telematics is redirection of data from the hardware to a back-office environment of choice. In theory this isn’t a challenging feat being that the various communications standards like MQTT, HTTP based APIs, and others are available. The basic connectivity schemas are there. The challenge comes with coordinating the implementation, on-going support, and management of the entire solution. An example of this is if a new feature is developed within the back-office, there is a very good chance that work would be required at the module level and would have to be performed by another organization or team. In today’s fast pace development world, aligning the release of hardware and back office features to achieve alignment could be difficult.
Multiple Solutions
Yet another option, which is being used out of necessity rather than choice, is the use of multiple hardware/back-office solutions to get the value necessary for the end user. For example, in one vehicle you could implement one module type and portal to deliver fuel usage information and then use a completely separate hardware/back-office solution to monitor maintenance. While this method can support both value propositions, the cost and convenience of multiple, separate solutions become a burden. The cost to maintain multiple solutions includes support, data transport, module upgrades, etc. and will grow over time. In addition, usage of the solutions - would not be maximized being that an end-user would need to flip between solutions. This solution methodology is great for getting into market faster, but its longevity comes at a higher cost.
As with any product, clearly identifying and knowing your target customer is critical to the success of the product. With Telematics, the opportunity for success is magnified considering the numerous personas that can gain value from the solution, the infinite layers of makes/models and the various organizations that can impact how a solution is developed and used. Taking the time early on in your telematics solution design phases to define the scope, as well as using a steppingstone approach ie: target customer (a-b) , then add features to support customers (c-e) drives clarity around what value your solution is providing and will drastically increase your solutions success factor.
Related Blog Posts:
How to Define Your IoT Solution - Segment 1: Personas
Part 1: Telematics What is it and Why is it Important?
Part 2: Telematics and Data Collection
Part 3: Telematics and Data Transmission
Part 4: Telematics and Data Aggregation, Visualization and Storage
More on Telematics