Resource management is an important part of modern business processes. Although some extensions for handling resource allocation within the modeling standard Business Process Model and Notation have been proposed before, we argue that these are limited for the dynamic management of resources in business processes, where an efficient allocation of resources to tasks is of crucial importance for achieving overall efficiency. In this paper we show challenges of resource management based on a real-world example, and why current approaches are not able to fully handle them. We propose to extend existing business process management systems by a so-called Resource Manager with which powerful optimization algorithms for resource allocations can be used and discuss its main functionality and remaining challenges.
Business processes are indispensable for organizations to achieve certain goals,
such as selling products or hiring employees. Especially for a business, its processes
increase in amount and complexity alongside with its growth [
For enacting business processes, resources (e.g. employees, organizations,
hardware, software, etc.) are indispensable [
parcel delivery Parcel delivery requested Scheduled time occured
Parcel delivered
Rule-based allocations of resources to tasks cannot leverage the full potential
of an efficient resource management. The example in Fig. 1 shows a very simple
process model of a parcel delivery process where each parcel has its own process
instance. For each parcel, the delivery is scheduled and when the scheduled
time is reached, the parcel is delivered to the customer. Clearly, resources, i.e.,
delivery vehicles, are needed in order to actually conduct the delivery. In order to
efficiently utilize these vehicles, the scheduling of the individual parcels must be
conducted in such a way that cost-efficient routes for the vehicles can be found,
allowing to deliver all parcels at their scheduled times. Thus, the scheduling
represented as a simple user task (cf. Fig. 1) is a complex task, where all suitable
vehicles and all other delivery requests should be considered. In our example, we
assume that this task is done manually by a dispatcher, who has knowledge about
all resources available and all delivery requests. However, the task could also
be executed by an optimization engine using algorithms for solving a so-called
vehicle routing problem [
Similar combinatorial optimization problems, in which rule-based allocations of tasks to resources can lead to significant efficiency problems, can also be found in many other business processes. Therefore, an innovative approach that enables current business processes to be extended by the means to dynamically manage resources is needed. We propose an extension of existing Business Process Enactment Systems by introducing a new component, which is responsible for resource allocations – the Resource Manager. The Resource Manager is supposed to accumulate and congregate the knowledge of the different resources, as well as having access to currently running processes, resulting in a highly adaptive resource allocation.
In the next section 2, existing approaches concerning resource allocation are discussed. In section 3 we introduce the Resource Manager and what requirements it has to fulfill. On top of that, we will explain how our approach can fill the shortcoming of the current approaches in accordance to the given example. Lastly, in section 4 we will give an outlook on how we will work to realize our proposal as well as validate its functionality. 2
Next to the control-flow and data-flow perspective, the resource-perspective is
essential for business processes describing how to allocate required resources to
a process task for its successful execution [
In this section, we introduce a new approach that extends the current business process management system by adding one further component (see Fig. 2). Traditionally, a BPMS consists of two main components: the Process Modeling and the Process Engine component. With the Modeling component, process models can be created by a process designer and stored into a Process Model Repository. The current versions of the models in the Repository are then accessed by the Engine to execute them. If the process contains service tasks, the Engine calls other applications – in the case of a user task, the Engine provides the tasks to the process participants over an user interface via the Environment.
The new component is an additional service for business processes, which allows an optimized resource allocation. It is independent from the individual process execution, but has on the other hand knowledge on the existing resources, their characteristics (static data), their availability (dynamic data), and on the other hand, access to the currently executing process cases (i.e. process instances). Our extension is built up similarly to the traditional BPMS and consists of three parts: Resource Modeling, Resources, and Resource Manager.
Process Participant
Resource Designer
Manager
static Resources dynamic Traditional BPES Extension Resource Modeling. Similar to the Process Modeling, this component is used by the Resource Designer to model the static part of resources according to a notation, that can be translated and executed by the Resource Manager. The Resource Modeling is responsible for defining the static data required to determine whether a resource may be allocated to a request or not, as well as the data required to assess and evaluate resource allocations. For example, the data may include the type of the resource, the hourly costs, capacity, etc. Resources. The Resources contain the full information on the static information of resources that are supposed to be modeled. During runtime the Resources additionally contain dynamic data, which is updated by the Resource Manager only. In this way the Resources part contains the exact representation of the existing resources. This means if a resource can not be found in the Resources it does not exist and if we find two resources of the same type, we have exactly two resources. Additionally we propose to give read-only access to the Resources to the Process Designer during Process Modelling in order to make sure if the process is going to use resources, it is done correctly. Thanks to that, in contrast to traditional process designing, the Process Designer does not need to specify the concrete resource for an activity but can instead ask the Resource Manager to allocate the needed resource at run-time. This means that there is the need of a change in the Process Modeling, whenever a resource is a part of the process (see Fig. 3). Resource Manager. The Resource Manager is a component maintaining information about the current state (dynamic data) of all resources. Whenever a resource is requested by a process instance, it collects all relevant data concerning the resource request so that allocation decisions can be made. The actual allocation decisions can then either be performed via an appropriate user interface by a human decision maker or via a suitable interface by an optimization engine. Whenever a resource is allocated to one or multiple requests, the state of the resource is updated and the respective process instances are informed about the allocation. Whenever a requested resource is no longer needed, the Resource Manager is informed by the process instance so that the state of the resource can be updated accordingly.
Resource Manager e n i g n E s se Parcel delivery Request co requested vehicle r P
Deliver parcel Vehicle allocated
Release Parcel allocation delivered
Fig. 3 shows an adaptation of the parcel deliver process in which the communication between the process model and the Resource Manager is explicitly modelled. In comparison to the process shown in Fig. 1, the scheduling task is no longer executed within the process instance itself. Thus, instead of having the planning tasks distributed over all individual process instances, the scheduling task, which should consider information about all delivery requests and vehicles, can be executed where all of this information is available. As the Resource Manager has to be called from inside the Engine that executes the business process, there has to be a close connection between these two components. Another idea would be to fully incorporate the Resource Manager into the Engine. However, this will lead to problems as the Resource Manager is supposed to manage the resources for multiple processes (instances) as those different execution might not necessarily be on the same Engine. That is why we need to have the Resource Manager as a stand-alone component. Furthermore, the Resource Manager is expected to be the expert concerning all resources it is in charge of. This means it further encapsulates the resource specific knowledge as not all processes need the complete information or on different detail levels.
In this work we introduced a concept to extend the architecture of BPMS in such a way that an effective linking between tasks and resources is possible to cope with challenges from multiple and even freshly emerging fields (e.g. IoT, parcel delivery, cloud etc.). However, so far we only theoretically showed the shortcomings of existing approaches and how a component managing resources as a service could bridge these gaps. In order to evaluate our approach, we are going to implement a proof of concept. We have identified three main challenges we need to accomplish. Firstly, as mentioned during the explanation of the Resource Modeling, the challenge is to define a standard notation for resource models. After we have resources defined in such a way processes can use them, we can create resource-aware business processes. For this we need to adapt the Process Modeling part, so that a process now can access resources when needed. This means we will have to introduce new modeling concepts concerning resources. Lastly we are going to implement a Resource Manager that at runtime uses its expertise to enable dynamic resource allocation. As the Resource Manager is supposed to be the expert for many different allocation problems, we need to define the communication between the Engine and Resource Manager. For this we are going to define an interface for each allocation problem the Resource Manager can solve, where the Engine will send its constraints and expectation on the result, which are used to come up with an efficient allocation. We are going to evaluate the implementation on a real-world example in the context of a logistics project (SMile Project). Depending on these results we can then further refine our approach.