Please request a free consultation appointment with us.
The Internet of Things is characterized by the technical connection of devices and systems to the Internet. Although this connection is the starting point of many IoT projects, in most cases it can be realized with relatively little effort after careful consideration of the available options.
The mere technical use of IoT, however, does not generate any business value per se, neither for the product, for the process nor for the company as the product or process owner.
One of the challenges that must be considered at the beginning of a project is the definition of the so-called use case. The use case describes, among other things, the possibilities for users or external systems to interact with the considered system.
These interactions should converge to a corresponding entrepreneurial objective because the IoT application receives a value in the product or in the process then by the later application. This application is built on the technical foundation, such as data or new communication possibilities. The basic categories in which IoT applications can achieve value and how this can be quantified will be discussed in a future article.
In practice, the use case definition for IoT often faces the challenge of switching between the technology perspective and the application perspective and systematizing the ideas of what could be achieved with a sensor, a sensor combination or an evaluation of the collected data. The present paper contains a methodological proposal on how the back and forth from technology to the application as well as from application to technology can be systematically used in the use case definition in the idea phase.
The service provider IFTTT launched its platform on the US market in 2010. IFTTT means "if this then that" and describes a simple set of rules with so-called recipes, which react based on an input event ("if this") with certain actions ("then that"). The application has been highly praised in the media, which is most likely due to the simplicity of the application. Simple automation tasks can thus be solved quickly, whereby inter-connection of various systems from different manufacturers via triggers and actions is possible.
For example, the detection of a person by the cameras of cloud supplier A can switch on the light in the house via cloud supplier B. SWMS has already featured IFTTT in an earlier article from a technical point of view. But how does the approach behind IFTTT help with the use case definition for IoT systems?
The simple structure of the thought pattern behind IFTTT helps to find the use case, which in practice takes place in the field of tension between technological possibilities and actions or values to be achieved. It is important that we only follow the simple pattern of thinking here and first free ourselves from the actual technology. It is only a matter of basically determining that certain technical prerequisites (alone or in combination) leading to actions that then determine the value of IoT for the product or process.
The simplest case to start with is often the recording of the status quo with regard to acquired data and sensors used because in most cases IoT projects are characterized by the fact that an already existing system or process is to be "digitized" and further automated. Therefore, start by clarifying the current structure of your considered system. It is relatively independent whether it is a product or a process you are looking at. For example, a product already uses various sensors for its internal control and thus switches actuators, such as in the swimming pool sketched above. In a process, start and end times, quality criteria or certain machine settings may already be recorded, albeit manually and only sporadically.
From this collection, ideas for new applications of physical measurements and collected data can now be derived and formulated according to the simple idea of recipes à la IFTTT. It is important that possible technical hurdles are consistently ignored. It is not a matter of determining the specification in detail, but of formulating an idea systematically and in principle, which describes which technical situation recorded ("if this") should result in which statement and possible action ("then that"). A simple pattern using the swimming pool as an example: "If the outside temperature > 26 °C, then switch off the heating". Of course, the potential of IoT is by no means exhausted here, but you can model your use case according to the same scheme with more complex rules. Example: "If the chlorine concentration is low and the number of visitors high and the last chlorine order x days ago, then order new chlorine automatically". Here the value of automation of the business process and the service becomes much clearer because the technical parameters are used in combination to generate this value: Namely, a simplified and automatic ordering system, which significantly simplifies a task for the operator and at the same time allows a pool builder to establish an after-sales business.
The application idea can also take the initial role in companies. Let's stick to the example of the pool. A pool builder can, of course, first ask himself how he ties his customers to him, for example after the sale and establishment of the pool, and may also come up with the idea that, among other things, the continuous supply of chlorine to his customers would be an interesting business. He is also convinced that he can persuade his customers to order chlorine from him continuously if he succeeds in automating the control, monitoring and inventory management that is so annoying for the customer. "We have all the necessary data for this, don't we?" is the central question that can also be methodically used with the help of "if this then that" modelling in such a way that the event triggers ("if this") can be defined with the necessary technical conditions from the action (supply of chlorine, "then that"). Often it is the stakeholders, i.e. customers, internal service employees, product development, etc., who are the idea givers or addressees of these actions.
In our opinion, the success of the IFTTT provider lies above all in the fact that manufacturer-independent connections were guaranteed. With this, almost infinite combinations of rules and regulations can be created without great technical restrictions due to the functional scope of individual manufacturers. Even when modelling the IoT system using this methodology, one should be aware that early technical restrictions should be avoided. In both cases, therefore, correlations can be formulated vaguely, i.e. for example, "if anomalies in the vibration sensor at the pump increase over time, then send a message to the connected ERP system".
Any data sources or events that are conceivable are suitable for the definition of use cases. Especially external data sources and systems offer incredible potential for innovative approaches. Sources are for example
The term "method" is almost too broad, but in this paper, we have presented a simple procedure for systematically deriving the application and action ("then that") from the technical possibility ("if this").
The second way from the application idea ("then that") to the necessary technological prerequisites ("if this") is also possible. Embedded in the description of the status quo, consisting of
a) the product or process to be 'digitised',
b) the technical capability or data it possesses to date; and
c) the stakeholders interested in the actions,
this procedure leads to a simple description of possible Use Cases and thus to the possibility of deriving the Use Cases, which find further consideration in the context of an IoT project.
A template for the development of the Use Cases is available here for free download (PDF). No registration is required for the download.
Was denkst du?