IoT and Process Management
Process management might not be the first thing that comes to mind when talking about IoT solutions. This is because many IoT projects initially struggle with getting assets and devices connected, and then building the basic services in the backend. Also, as discussed in this chapter, many projects will focus on analyzing and managing inbound event streams, or building up basic analytics. However, once the initial IoT solution functionality is established and the system scales up in terms of connected devices and incoming data, process efficiency will eventually become a very important topic. In an IoT solution, many business processes will be triggered by individual events coming from devices and assets, or by the results of more advanced analytics that look at multiple, only indirectly related events (see Complex Event Processing in the previous chapter).
Take, for example, predictive maintenance. As discussed, for example, in the Rexroth case study, sophisticated machine-learning algorithms are applied to sensor data to identify situations which indicate that a machine breakdown is imminent. You can literally see the sensor network expert and the data scientist putting their heads together for weeks to figure out how to identify these trigger points. But what comes next? What do you do with the information that the conveyor belt at ACME mining has an 87.25% chance of breaking down between Monday and Wednesday of next week because of a problem with the liquids in a hydraulic component? And what do you do if this type of information actually comes in hundreds of times a week for the tens of thousands of customers who are using your machine components? This is exactly the point where Business Process Management (BPM) comes in, to help ensure that these requests can be processed efficiently and that the field service team is utilized as well as possible.
Take, as another example, the eCall service that we have already used so many times: yes, the initial focus of the project is to correctly identify potential crash situations and send this information to a call center so that it can be processed. And this is exactly where BPM starts, at least from the call center manager’s point of view. They have to focus on two things: First, to ensure proper process execution. This means classifying the distress call and routing it to a call center agent with the right language skills. Secondly, call center utilization. These days, most call centers support multiple services. Implementing efficient call-routing processes is extremely important for ensuring SLAs, but also for ensuring profitability.
Or take, for example, the large telecom companies who build and operate large communication networks with hundreds of thousands of network elements and millions of customers. eTom, the TM Forum’s blueprint for running a telecom company, identifies hundreds of critical business processes, from network management to customer-related processes such as sales, product activation, and customer service requests. After all, the IoT will not be so different.
So some interesting questions that we have to ask ourselves regarding BPM and IoT include:
- How do we identify the most critical processes in an IoT solution that should be addressed first, from a process automation point of view?
- How much automation will be possible (or desirable)?
- When should we use BPM tools for process automation, and when should we use other approaches like hard-coded business logic?
- What is the nature of these processes? For example, structured, unstructured, etc.
- Is software provisioning and management on devices a BPM process or an application feature?
- What type of tools should be used? BPM engines, workflow management tools, or collaboration tools like Jira?
- Is it an advantage if my IoT application platform has a built-in BPM engine?
- What does the technical integration look like (Device2Process and Process2Device)?
In order to better understand these questions and the potential answers to them, let`s take a closer look at how process management potentially fits into an IoT solution. The figure below is an AIA that builds on the AIA from the previous chapter (Data Management), because at the end of the day processes need to operate based on data, events, and the results of analytics.
In the example below, we have positioned the BPM/workflow/case management component between the M2M/IoT application platform (see next chapter) on one hand, and the existing enterprise application systems (ERP, CRM, PLM, etc.) on the other. A pattern that we call Device2Process and Process2Device is responsible for initiating new processes based on input that comes from assets and devices. The same pattern is also responsible for signaling to existing process instances if a relevant event from a device comes in which should potentially change the process flow. Similarly, processes can also be initiated by the results of the analytics engines. A use case for this would be predictive maintenance, where a predictive analytics algorithm comes to the conclusion that a machine breakdown is becoming likely, and then initiates a process to have customer service deal with this situation.
BPM, workflow, and case management in the context of the IoT
Process Diversity
Notice that we are differentiating between BPM, workflow, and case management. These are three different concepts that have been developed over time to address the fact that, in complex solutions, there are usually different sub-processes or process segments with very different characteristics. BPM is usually seen as being very strong in process automation, including orchestration of multiple backend systems, such as ERP, CRM, PLM, etc. Workflow systems focus more on human workflows, and less on process automation. Finally, case management is adding a data-centric (“case folder”) perspective with flexible work flow control.
If you think back to the discussion in the introduction about the impact of the IoT on the Distributed Assets Lifecycle, it becomes clear that it is important to understand the nature of the different sub-processes and to choose the right process management concept to support them. For example, the activation of IoT products is typically a highly automated process that could be implemented based on BPM. Service processes usually require a lot of human interaction, so they would usually rely on workflow management. In some situations, case management could also be interesting for support services, because case management is usually very good at gathering all related data and context information belonging to a case. For example, a service technician could get an information pack that tells them which support vehicle and support tools they should use and what time they should visit a customer, as well as providing details of the customer history and a description of the particular product.
Example of complex process
Finally, the mapping between processes and events can also be quite complex and can require a lot of flexibility. Take the example in the figure above, which is based on a scenario involving an industrial conveyor belt – similar to the use case provided by Bosch Rexroth in the previous Data Management chapter. The conveyor is equipped with sensors that support a machine-learning approach in the backend. Let`s assume that the analytics engine signals that there is a problem with one of the key components, and that the forecast indicates this part will break in 2-3 weeks (1). A process (or case, or workflow) should be initiated that creates a task for a call center agent to contact the customer and make an appointment within the next 2-3 weeks (2). Now let’s assume that the situation at the customer site gets worse: Our CEP (Complex Event Processing) component has correlated a set of events that, in sum, indicate that the situation got worse much faster than forecasted (3). An internal rule decides that, based on these conditions, the conveyor belt will be shut down immediately to avoid further damage (4). The process must now advise the call center agent to contact the customer again urgently to agree on an emergency procedure (5).
This scenario shows how important it will be in IoT environments to be able to deal with processes in a very flexible manner. One good way of doing this is by using Adaptive Case Management (ACM), the most flexible version of case management.
Expert Opinion
In the following section, we will discuss this topic with Torsten Winterberg from Opitz Consulting. Torsten is also a very active member of the Enterprise BPM Alliance (www.enterprise-bpm.org), which develops and maintains a BPM methodology based on Enterprise BPM, the predecessor to this book.
Dirk Slama: Torsten, can you explain to us why applying process management to the IoT world is important?
Torsten Winterberg: Efficient process management might not be the first thing you think of in an IoT project. In fact, putting your Arduino experts in the same room with a bunch of Aris process analysts might not be a good idea. However, I believe we can learn from the evolution of the backend processes and systems of the large telcos. They have learned over the last couple of decades how to manage millions of remote devices used by end customers. Given the scale of their business, they were forced to look at process efficiency sooner rather than later. This includes many different types of processes, from sales and product configuration to product activation and customer service processes. At the moment, most IoT initiatives are focusing on solving basic problems like actually integrating devices and implementing the basic service functions. But as soon as these initiatives start upscaling, they will face the same problems. Managing millions of remote devices in the field as well as their related end customers means finding efficient ways of pre-filtering events and other information in order to deploy business rules to help with automated decision making, and to ensure that only those problems which can’t be automated reach the human support staff.
Dirk Slama: What is the easiest way to connect the device world to the BPM side of things?
Torsten Winterberg: The easiest way to derive benefit from an automated process in the IoT world is to identify an “interesting scenario,” and then directly implement a process to handle that scenario. For example, think of some warehouses where temperature-sensitive goods are stored. If a temperature device detects that a threshold is exceeded, it can trigger a process in the backend that takes care of the problem. This process could try to find a solution by applying some predefined measures. If they fail, then a human can be notified to look into the problem. This leads to a much better and more efficient working environment; the employee responsible only has to react to deviations, maybe by means of an automated text message or a generated call.
Dirk Slama: Okay, that’s a very simple example. In reality, things are more complex. A process instance might have to react to several different incoming signals from devices. How would you solve this with BPMN?
Torsten Winterberg: Well, the BPMN engines have pretty good built-in mechanisms to handle signals, and therefore a process instance can react to a number of incoming events. But of course, this way of addressing the problem is not the BPMN’s specialty. The process models tend to get polluted with a lot of event-handling symbols, which makes it hard to keep control of the complex business rules of the different events. Changing the environment will always necessitate changing the BPMN model. To sum up, the complexity of this scenario and the lack of flexibility to adapt to a change of environment will overstrain the BPMN paradigm. Therefore, we advise using a BPM discipline called ACM.
Dirk Slama: Can you explain what you mean by ACM?
Torsten Winterberg: In short, ACM means Adaptive Case Management, and is an interesting alternative to BPMN when process models get too complex, when you don’t just have simple happy path models, or when you have to deal with lots of exception handling “code” which pollutes your nice BPMN models. ACM eliminates the need for transitions between activities in BPMN and typically replaces these transitions with a set of decision rules. ACM is goal-driven, for example, like in a navigation system in a car, where the goal is clear, but the path (the process itself) is unclear and full of escalation. BPMN, on the other hand, can be seen as railway system with predefined tracks: If you need a shortcut or a new route, you can only use the existing tracks or prebuild new ones. When the IT world speaks about “unstructured processes” – this is the sense of ACM.
Dirk Slama: So ACM is a BPM discipline that can be used for unstructured processes. How does this help with IoT?
Torsten Winterberg: The term “unstructured” usually implies something chaotic, but this is not the case here. Many processes are goal-orientated or case-orientated, and the path the knowledge worker chooses to reach this goal is often not rigidly defined, and takes their evaluation of information into account. For example, think of a medical case: A patient enters a hospital and is routed by the expertise of different people through several stations. From a process perspective, the patient enters the hospital, then some unstructured things happen, and the goal is that the patient leaves the hospital again (hopefully healthy), and then a bill is sent.
With the emergence of the IoT, these types of cases will evolve. Remote health monitoring can provide additional inputs to the clinical case, like real-time events related to patient health. Usage-Based Insurance (UBI) will have an impact on how insurance companies deal with insurance-related cases in the future.
In ACM you typically have a dashboard in your portal used by knowledge workers to view the “case.” The UI highlights those activities, depending on the current state of the underlying knowledge base, that can be executed by the knowledge worker. An ACM engine in collaboration with an integration platform can easily collect all kind of incoming events from different devices. These events may or may not change the underlying knowledge base, thus implying a change to the adaptive process. So some signal signs can be “green” or “red,” and some kinds of activities can be enabled or disabled, depending on the business effect an incoming event should have. The relation to the clinical case is simple. Each device with its messages can be viewed as a clinical appliance or clinical test measuring different values and implying and determining an appropriate response by the doctor.
Dirk Slama: Interesting approach. But doesn’t this approach introduce an overly complex mechanism in the BPM world?
Torsten Winterberg: Yes and no! For the user of the system, ACM makes life much easier because the focus of the work is the business case, and the person working on the process has a new degree of freedom to perform the process in the most effective way. Again, compare this to the way you use a navigation system. The goal is to reach the target address, but you have the freedom to take the best possible route. In most cases this might be the given, compiled route, but undefined circumstances might need a flexible reaction and a route change. This ease of use from the side of the “knowledge worker” necessitates higher complexity in designing the ACM engine case. But today’s ACM engines are integrating business rule engines and are getting better through transparency of these underlying rules, so that this complexity isn’t much of a hurdle anymore.
Dirk Slama: We learned that ACM is a very valuable approach for the Device2Process solution. But what about the other way around? Is there a correlation with Process2Device, too?
Torsten Winterberg: To complete a case successfully, you might perform a task that will manipulate the outside world including the case data and the case status itself. You use small BPMN processes behind these tasks, since they are, in general, well-defined and stable. A blood analysis as an example is a well-defined task, but the outcome and the necessary reaction in relation to the blood values are not so well-defined. So the question is that if a process (which is executable in BPMN) is able to interact with a “thing” as in your Process2Device example above, what implications could this have? We think there is still some work to do to figure this out. Of course a process could interact with a thing, such as adjusting the thresholds of alarm values. But we think it is more likely that a process will simply emit an event or a message, which is then consumed by some other system (like an IoT cloud), which will in turn interact with the single device. Normally you don’t want too close a coupling between your process and your device world, because things will evolve extremely quickly over the next few years, so your architecture needs to be adaptive.
To sum up, having too much data and complexity to compile manually, analyze and react to, and the wish to have a goal-oriented and flexible way to perform a business process makes a solid case for an ACM approach with BPMN sub-processes for well-defined sub-tasks and the integration of devices.
We are very excited, since this combined approach should be able to resolve many shortcomings of today’s BPM implementations. Currently there is a gold rush atmosphere out there, looking forward to a large amount of still-unforeseen new business models, and perhaps also big, new players ready to leverage the possibilities presented by the availability of mass personal data.