Keywords

1 Introduction

In the modern economy, we see complex business processes with a physical character that are executed collaboratively by a set of autonomous business organizations. We find examples in many business domains. In international container logistics [14], a network of transportation and administration companies collaborate to facilitate the process of physically moving containers from a location on one continent to a location on an another continent. The containers are physical objects to be managed, but so are the transportation vehicles, such as ships, trains and trucks. In integrated supply and manufacturing networks, we see multiple companies that tightly collaborate - but in a distributed fashion - to provide services and produce complex products. These products need to be physically moved around, but also physical manufacturing resources, such as robots, need to be controlled. This development is evident in the well-known Industry 4.0 concept [1]. In collaborative healthcare chains [11], we see how patients (here the main physical objects) are treated by multiple, distributed organizations in an overall treatment plan and their logistics need to be monitored and managed. In smart mobility solutions for people transport [15], we see comparable processes in which organizations collaborate to efficiently move people in urban contexts.

Over time, these processes have become more complex, more business-critical, more time-critical, and at the same time heavily mass-customized. Increasing process complexity is mainly created by increasing product complexity, but also by increasing rules and regulations. Increased competition in the global marketplace has made processes more business-critical. The necessity is growing to more explicitly collaborate and integrate processes with business partners to operate more efficiently. Customers expect processes to be ever faster, making them more time-critical. Given these ‘pressures’ on business processes, they need to be mass-customized as well - think of individual routing for single containers to meet strict delivery deadlines or highly individualized health care processes.

In this position paper, we present our view on automated support for these processes. In Sect. 2, we develop a conceptual view on the integration of three technology domains that is required for this support. In Sect. 3, we relate this conceptual view to a high-level systems view focusing on control. In this section, we also discuss an example from sea container logistics. In Sects. 4 and 5, we present a discussion of our position from the points of view of the state of the art, respectively implied challenges. We conclude this short paper in Sect. 6.

2 Towards a Trinity of BPM, IoT and DA

The developments outlined in the previous section imply that processes need to be managed more explicitly in an increasingly real-time fashion, with ample attention to individual process cases. This calls for advanced business process management (BPM) principles and technology - both within organizations and between organizations to arrive at process-oriented virtual organizations [16]. But for the processes we discuss in this paper, BPM cannot be fully executed in the digital domain - it needs to be connected to the physical world where ‘the action takes place’. To deal with the time-critical and mass-customized nature of the processes, this connection must be both real-time (or at least near-real-time) and linked to all individual physical objects being handled in the process - which may be many. This connection has become possible through what is called the Internet of Things (IoT) [20], that couples the physical world to the digital world and allows individual physical objects to produce data and to be digitally actuated (i.e., to be given commands to change its state in one way or the other). The amounts of data being generated can be overwhelming in size though - think of a process managing a large container ship that transport many thousands of individual smart containers, each of which produces data in a continuous fashion, reporting its location and physical state (such as temperature). To process this flood of data, we need advanced analytics. But we do not want all data to be analyzed at a central location. This would require all data to be transported (think of all the containers, that may be linked to the internet through a satellite link), would require huge central processing facilities, and last but certainly not least, would imply great business privacy and security threats. Consequently, we want the IoT data to be processed as much as possible at its origin (i.e., at what we call ‘the edge’ of the Internet), leading to distributed analytics (DA).

To support this kind of processes, we therefore propose to integrate business process management (BPM - to manage the processes), internet of things (IoT - to sense and actuate the physical objects) and distributed analytics (DA - to take the right decisions at the right place in real-time) technologies into an integrated trinity. This trinity is illustrated in Fig. 1. In this figure, we see how the three technology domains are complementary to ‘close the control loop’ for advanced, distributed, physical business processes. In this loop, BPM is concerned with realizing business goals by managing processes implementing these goals, DA is concerned with domain-specific reasoning logic that operationalizes the business logic of the domain, and IoT is concerned with managing the physical, real-world situation - both in sensing and in actuating. As the figure shows, DA is essential to transform low-level, high-volume data and events into high-level, low-volume information and triggers that have direct meaning to decision making in process management. DA also enables learning from the behavior of “things” and processes.

Fig. 1.
figure 1

Trinity view of BPM, DA and IoT

Full size image

3 A Systems View

The trinity of technologies shown in Fig. 1 is of a high-level, conceptual nature - and hence not fit for systems engineering - i.e., for designing systems that combine BPM, DA and IoT to support the distributed physical processes we have discussed in the previous section. For this purpose, we have to map the trinity of technologies to a systems view. We use an adapted version of a multi-level control model for advanced, flexible information systems [2], shown in Fig. 2. This model can be seen as a highly abstracted (and hence simplified) layered architecture for a BPM+DA+IoT system. The architecture is comprised of a set of logical components that represent the processing associated with the layer’s function. Each logical component can be mapped to a set of actual processing nodes in a technical architecture.

Fig. 2.
figure 2

(adapted from [2])

Multi-level abstract control model

Full size image

In the control model, we place IoT technology at the lowest of the four layers: the physical layer. This layer contains the physical objects, but also the low-level digital interfaces to sense and actuate them. In the processes described before in this paper, this layer is of a highly distributed nature, containing for example large numbers of smart sea containers being transported or connected patients being treated.

We place DA technology in the event layer. This is where data is received from the physical layer, recorded, analyzed and translated into decision information. This layer is also highly distributed - but possibly with fewer nodes than the physical layer: a single DA node may handle multiple IoT nodes. In container logistics, a DA node per container ship may process data from a set of IoT nodes (i.e., containers) on that ship to generate overall cargo characteristics of a transport order (for example, the average temperature or the average vibration measured by the sensors in the containers).

We place BPM technology in the process layer. This is where decisions are made about the execution of business processes, based on information from the DA layer - and information from non-physical sources, of course. In our container transport example, the process layer can receive information from a DA node on a ship about the status of the containers and the ship itself, and information from a DA node in the port where the ship is expected to dock about the availability of physical objects required to unload the ship (cranes and container trucks). The functionality in the process layer can well be of a collaborative nature, supporting collaborative business networks that execute inter-organizational business processes [16].

The business layer of the control model is out of scope for this paper.

So in practice, there will be a number of business processes that rely on a number of analytics nodes to obtain their decision data, each of which is connected to a number of things (in the IoT sense) that provide the data to distill the information from. This is illustrated in Fig. 3, with three business processes (BP), four analytics nodes (A) and a number of things (T). Note that analytics nodes can be shared among business processes: the same information can be used to steer multiple processes. Note also that the command interface from BP to T has been omitted from the figure, to not make it too messy.

Fig. 3.
figure 3

Business processes, analytics nodes and things

Full size image

We can make the abstract picture of Fig. 3 concrete by an application example from container transport that illustrates the complexity of a real-world situation. We have four processes: a shipping process at a freight forwarder, a transportation process at a shipping line, a trans-shipment process at a deep-sea terminal, and a transportation process at a trucking company. The involved things are: container ships, container trucks, reefer containers (transmitting information on status, including temperature), cranes at the terminal (one kind for unloading the ships, another kind for loading the trucks), and automated guided vehicles (AGVs) that take the container to/from temporary storage at the terminal. In this context, the following example analytics services can be deployed:

  • Container monitoring: using data from the trucks, cranes and containers to check if the container is being handled properly (used primarily by freight forwarders);

  • Location monitoring: using data from the ships and trucks to monitor the location of the container (used by shipping lines, trucking companies, freight forwarders);

  • Storage monitoring: using data from cranes, AGVs, containers to monitor the status of the container in storage (used by freight forwarders, trucking companies – to check if the container can already be picked up, and terminals).

4 Discussion: State of the Art

The combination of BPM and IoT has already gained some attention in research and development [3, 6, 12, 21]. An example application domain is collaborative transport and logistics [14]. An analysis of potential benefits and important challenges has been published [3]. Analytics is mentioned in this analysis, but distributed analytics is not positioned explicitly as a third required technology domain here, however, to complement BPM and IoT. Business models for IoT have also been studied [6]. An integration of business processes, social networks, and Internet of Things into a single platform called Business-2-Social was also proposed [12].

The combination of IoT and (distributed) analytics has also received attention [17]. Platforms for the combination of the two domains are under development. The concept of fog computing (as a highly distributed, local version of cloud computing) plays a role here [18]. Making IoT-based analytics distributed in a structured way with explicit attention for BPM as required for our proposed trinity is a topic of research still, however.

The combination of BPM and analytics has received a great deal of attention already, mostly in the field of process mining [7]. Process mining, however, is mainly focused on redesigning business processes (i.e., on the design time column of Fig. 2), not on supporting decision making during execution of processes. Distribution aspects have not received much attention in process mining. A notable challenge in distributed process mining is the absence of a single notion of ‘case’ (i.e., process instance), such that it is difficult to discover the relations between process instances from different partners [8].

Supporting decision making is explicitly addressed in the machine learning (ML) field. Recent advances in deep learning methods (that can be seen as part of ML) allow building models with high predictive power from big data [4]. Transfer learning frameworks [9] can support distributed analytics. To support privacy preservation in ML, differential privacy techniques can be used [13]. Research on the link between ML and IoT is ongoing [5], but the ML field is not yet strongly connected to the BPM field.

5 Discussion: Challenges

From the discussion in the previous section, we can observe that some groundwork for our trinity is under development, but there is no complete framework yet for the entire concept. There are currently plenty of challenges, both from the application point of view, from the architecture point of view and from the technology point of view.

From the application point of view, granularity of things (again in the IoT sense) and related bundling and unbundling is an important and hard topic. Revisiting the container transport case, we can treat individual containers as things (which makes sense from say a temperature control perspective), but we can also treat a ship with 5000 containers on board as a thing (which makes sense from a location management perspective, as all containers move the same way while on board). These changes, however, once the containers get unloaded at the destination port, where they are each unloaded individually (unbundling), but may be regrouped again on trains or river barges (bundling). Another important issue is event binding: when an event is generated by a thing and processed by an analytic node, it is important to be able to relate the event to the right business process instance, and consequently to the right party in a collaborative logistics network. The exact way of event binding can be highly dependent on the application domain.

From an architecture point of view, there is an interesting question: does a three-layer model suffice? Given Fig. 3, it may make sense to have multiple analytics layers between the things and the business process layer, certainly if the number of things is very large. To illustrate numbers using our sea container example: in 2016, the Port of Rotterdam handled approximately 7.4 million sea containers [10] and a single large container ship can transport over 20,000 TEU (Twenty Foot Equivalent Unit) [19], or over 10,000 large sea containers. Using multiple DA layers in the systems view allows for computation load distribution by increasing parallelism in analytical processing. Using multiple DA layers also allows to have multiple layers of data privacy and hence more flexibility in collaborative data sharing between organizations. In the container example, we may want (i) one privacy layer in which all details of individual containers are visible (but not shared); (ii) one layer in which detailed handling data are visible (and shared between specific collaborating transport parties) but not the details on the contents of the containers (as these may be of a competitive nature for the owners of the goods); (iii) one layer in which aggregated handling data are visible on a per-ship basis (and shared with all partners in a collaborative network); and (iv) one layer in which aggregated handling data are visible only on the overall port level (and are completely public).

From the technology point of view, there are several issues to be addressed. One important issue is the dynamic deployment of analytics functionality from the process layer to the distributed analytics layer. In other words: when the BPM layer requires specific information or specific triggers, there is a need to instruct the DA layer about this. This can be done by deploying analytics code into the DA layer, which may in turn need to deploy code in the IoT layer. Certainly, in a multi-layer model as discussed above, there are plenty of questions to be answered here. Note that additional complexity is introduced if the involved BPM and DA/IoT nodes are owned by different partners in a collaborative business network: specific privacy and security issues will need to be addressed.

A final challenge that we want to briefly discuss here is the use of BPM for managing ‘traditional’ business processes (i.e., business processes that directly serve customers) versus the use of BPM for learning processes in our trinity framework. When we use BPM for managing customer-oriented business processes, we assume the existence of appropriate analytics models to be deployed in the DA and IoT layers. Where these models do not yet exist (i.e., the parameters of models still have to be learned), BPM can also be used to manage the distributed learning process. In this case, the complex deployment process of iterative distributed learning is managed by a process engine. Obviously, both uses of BPM can be combined in complex, collaborative application scenarios - but the ways to model, deploy and execute this imply open research questions at this point.

6 Conclusions

In this position paper, we present a view on an integration of business process management, distributed analytics and internet of things technology. This integration is required to effectively and efficiently manage complex, distributed, collaborative business processes that have a real-time, data-intensive character in handling physical objects.

We are convinced that more and more ‘physical’ processes will evolve in this direction, in many collaborative application domains. An example is urban mobility  [15], where a business domain of ‘just’ operating rather isolated fixed lines of public transport (without much notion of individual travelers and real-time circumstances) is transforming into real-time, collaborative travel management on a mass-customized basis.

The conceptual trinity model of BPM, IoT and DA and its operationalization into an abstract control model are merely the start of thinking about a structural integration of the three technology domains towards the support of complex collaboration networks in various business domains. As we have pointed out, there are plenty of challenges to overcome and questions to be answered by research. We have identified the following questions in this paper:

  • How can we deal with the granularity of IoT things handled in collaborative business processes, certainly in the context of bundling and unbundling?

  • Is a single DA layer sufficient in the proposed control model, or should be have multiple DA layers to support multiple privacy levels and increased parallelism?

  • How do we dynamically deploy analytics functionality in a structured (and standardized) way from the BPM to the DA and IoT layers? In a collaborative business network, how to do this when the involved nodes belong to different partners?

  • How do we combine knowledge management processes (like advanced federated learning) with operational business processes, both in modeling and enactment?