Information Modeling of Rule-based Logistic Planning Processes

Kanban Loop Planning Supported by a Workflow Engine

Stephanie Bäuml

, Daniel Hilpoltsteiner

, Sebastian Meißner

and Christian Seel

Technology Centre for Production and Logistics Systems, Landshut University of Applied Sciences, Landshut, Germany

Institute for Project Management and Information Modeling, Landshut University of Applied Sciences, Landshut, Germany

Keywords: Rule-based Logistic Planning Processes, Kanban Loop Planning, Knowledge Management, Information

Modeling, Workflow Engine.

Abstract: This paper discusses the modeling of rule-based logistics planning processes. These are mostly inadequately

documented and modeled, especially for small and medium-sized enterprises (SMEs). As a starting point, the

ways of representing rule-based logistics planning processes and the modeling languages suitable for the pro-

cesses are introduced. In addition, it is shown how decision rules can be represented in modeling languages.

Based on this, a prototypical representation for the planning of a kanban loop is presented as a technical

model. This serves as the basis for a workflow, which is constructed by transforming the domain-oriented

model into a technical model. A workflow engine is used to execute and evaluate the technical model.

1 INTRODUCTION

There are a number of logistics planning processes

that are necessary to describe the strategic, tactical,

and operational activities of a logistics planner. How-

ever, there are only a few formally defined planning

processes. According to a survey of the needs of lo-

gistics planners (S

CHUBEL, 2017), they want “reusa-

ble, formalized and standardized solutions for logis-

tics process planning”. By using standardized process

models, important resources can already be saved

when planning logistics processes, resulting in more

efficient and effective planning processes.

A first formalization was undertaken with the sup-

port system of

(SCHUBEL, 2017). The implementation

of the support system includes a rudimentary visual

representation of strategic material supply processes

in the EPC (event-driven process chain) modeling

language. However, no rule-based logistics planning

processes that are suitable for automation are de-

scribed in

(SCHUBEL, 2017). An example of a rule-

based logistics planning process is the planning and

design of kanban loops (Gorecki and Pautsch, 2014)

which are necessary for material supply in produc-

tion. In addition, the modeling language BPMN

(Business Process Model and Notation) (Allweyer,

2015) has established itself as the de facto standard in

business process modeling (Kocbek et al., 2015). A

comparison between polyglot and pure BPMN mod-

eling stacks has shown that pure BPMN stacks have

advantages in the transformation from the domain-

oriented to the technical level (Seel, 2014). This

transformation is important for implementing pro-

cesses on a workflow engine and will be described

below, both as a domain-oriented and technical

model. The representation of rule-based logistics

planning processes and their execution can therefore

be identified as a research gap. From this the follow-

ing research questions arise:

RQ1 How can rule-based logistics planning pro-

cesses be represented?

RQ2 How can rule-based logistics planning pro-

cesses be supported by a workflow engine?

The paper is divided into six sections: after the in-

troductory section with the research questions, the re-

search methodology used is presented in section two.

Section three explains the current state of scientific

knowledge on the ways of representing logistics plan-

ning processes. It also explains ways of representing

decision rules that are necessary for the automated

representation of rule-based logistics planning pro-

cesses. Based on the kanban loop rule-based logistics

planning process, a workflow engine based on the

BPMN 2.0 modeling language is used in section four

and we explain the steps necessary to move from a

Bäuml, S., Hilpoltsteiner, D., Meißner, S. and Seel, C.

Information Modeling of Rule-based Logistic Planning Processes Kanban Loop Planning Supported by a Workﬂow Engine.

DOI: 10.5220/0008053701670175

In Proceedings of the 11th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2019), pages 167-175

ISBN: 978-989-758-382-7

167

domain-oriented to a technical level and thus again to

the executable model. In section five, the modeled

process is executed on a workflow engine to evaluate

the process. In the last section, the advantages of the

model presented for logistics planning are summa-

rized.

2 RESEARCH METHOD

The present article is methodologically guided by the

Design Science Research (DSR) according to (He-

vner and Chatterjee, 2010). The starting point is a

practical problem in production logistics – more pre-

cisely, in the automation of rule-based logistics plan-

ning processes, such as the planning and design of a

kanban loop. In accordance with the DSR, an artefact

is constructed for this purpose. This is presented in

this paper as a process model. This artefact is devel-

oped as a domain-oriented model for the documenta-

tion of the process and then transferred into a tech-

nical model. The technical model is a workflow that

is executed on a workflow engine. The constructed

artifacts are evaluated in accordance with the DSR in

section five, which describes the execution on a work-

flow engine and the complete integration of the rules

described in this paper. In addition, the artifact is

checked for plausibility with experts from production

logistics (logistics planners) and for applicability

within companies. It is important to note that the im-

plementation represents a generic process via the do-

main and is not tailored to the interfaces of individual

companies.

3 REPRESENTATION OF

RULE-BASED LOGISTICS

PLANNING PROCESSES

Production logistics describes the area of responsibil-

ity in logistics that deals with the optimal design of

the value stream from the receipt of goods (ac-

ceptance of the necessary production factors) to the

issue of goods (handing over the finished products to

distribution) (Plümer and Steinfatt, 2016). Planning is

a structured information-processing process to

achieve business goals (Plümer and Steinfatt, 2016).

Business objectives are necessary as input variables

for economic planning. The planning takes place un-

der consideration of the principle of rationality. The

fundamental problem in planning is the unpredictabil-

ity of events (Plümer and Steinfatt, 2016). Logistics

planners try to protect themselves against this uncer-

tainty through their experience and by considering

buffers. It follows that it is necessary to design logis-

tics planning processes dynamically, as customer de-

mands are constantly changing and fluctuating in vol-

atile markets. This affects material supply processes

in particular. The planning for this must be constantly

revised in order to keep it up to date. The effort for

this is considerable, especially because the planning

processes in many companies are still carried out

manually (Helmke, 2019). Rule-based planning pro-

cesses in particular are suitable for automation, as

they follow decision rules. So-called workflow man-

agement systems (WfMS) or business process man-

agement systems (BPMS) are mostly used to auto-

mate processes. Most of the terms are used synony-

mously, though there are slight differences (All-

weyer, 2015). The central element of these systems is

the so-called workflow engine (Freund and Rücker,

2017), which is used to execute and monitor the mod-

eled process.

Logistics planning processes are inadequately

formalized (Schubel et al., 2015).

SCHUBEL ET AL.

carried out a systematic literature analysis on the sub-

ject of “information models for production and logis-

tics planning”. They found that small and medium-

sized enterprises (SME) in particular have a need for

action in the systematic presentation of their logistics

processes. Especially the logistics planning processes

have a considerable potential, since the effectiveness

and efficiency of planning projects can be supported

by modeled processes (Schubel et al., 2015).

According to (Liebetruth, 2016b), it is necessary

to model processes realistically as a first step. When

modeled by technical experts, certain steps can be

omitted or even combined in order to prevent the pro-

cess from becoming too complex (Liebetruth, 2019).

A representation of the real process is a model and its

depiction is called modeling. The aim of modeling is

to map actual processes or target processes of opera-

tional processes precisely and formally correctly

(Gadatsch, 2017). The consistency of the presentation

form is particularly important in order to keep the

transformation effort between the domain-oriented

and the technical model low and avoid content-wise

differences between the two model levels. The do-

main-oriented model is implemented by an expert in

the department. They have the best understanding of

the process as well as implicit and explicit knowledge

relevant to the implementation of the process. The

preservation of expert knowledge in particular is a

major advantage for companies (Liebetruth, 2016). If

the processes are not represented, knowledge is lost

during employee turnover and relocation, which leads

KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems

168

to higher training costs for new employees. With the

processes described, knowledge transfer for employ-

ees can be made more efficient. When restructuring

business processes, it can be helpful in decision-mak-

ing if the actual processes are known so that the con-

sequences of change initiatives can be better assessed.

In addition, they are necessary to generate transpar-

ency in the processes and to successfully pass certifi-

cations and audits. Moreover, they ensure the effi-

cient development of business processes and are help-

ful in the digitization of processes. Digitization means

shaping the change from analog to digital business

processes. This includes the automation of manual

decision-making processes, the use of existing data

for decision-making, the use of data and the resulting

information to develop new business models and sim-

ulate various scenarios (Liebetruth, 2016)

There are numerous ways of modeling processes.

As already mentioned at the beginning, the represen-

tation of logistics planning processes is inadequate

and is criticized by experts (Schubel, 2017). This

leads to inefficient processes and ties up qualified and

specialized staff resources. In the case of SMEs, it

was found in collaboration with the cooperation part-

ners that – in contrast to large companies – they do

not have one person working as logistics planner, but

that the tasks are shared by other employees (Schubel,

2017). For this reason in particular, it is important for

small and medium-sized enterprises to conserve and

make more efficient use of their already scarce staff

resources in the specialist departments through docu-

mented and modeled processes (Federal Ministry for

Economic Affairs and Energy, 2018).

When choosing the right modeling system, it is

important to consider beforehand which goal will be

pursued (Gadatsch, 2017; Liebetruth, 2016). Model-

ing content must therefore not only be error-free, but

also represented target group-oriented (Gadatsch,

2017).

LIEBETRUTH distinguishes between three tar-

get groups with different requirements for the repre-

sentation of processes:(1) the upper management

(strategy), for which a general representation of the

processes as a value chain and a subdivision into core

and support processes is sufficient (Porter, 1986); (2)

process managers, who are responsible for the perfor-

mance and quality of the individual processes and are

therefore interested in the representation of individual

process models, sub-processes and even individual

work steps; (3) the lower management and executors,

who monitor the implementation of the individual

work steps and are thus interested in detailed infor-

mation on the processes, such as work instructions

and documents (Liebetruth, 2016). Those responsible

for logistics planning processes are among the last

two target groups.

(Gadatsch, 2017) has compared numerous

modeling systematics. In an empirical study con-

ducted by the Zurich University of Applied Sciences

in 2011 asking “Which notations are used in your or-

ganization for the documentation of business process

models?” the results were as follows: (N=186; multi-

ple answers were possible): simple, non-formalized

flowcharts (63 %), BPMN 2.0 (49 %), EPC (47 %)

and, to a lesser extent, IT-related UML (Unified Mod-

eling Language) (20 %). A further interesting ques-

tion was: “In which departments are BPM methods

applied in your organization?” 32 of the companies

(N=191) stated logistics. This functional area was

ranked seventh behind IT, consulting/provision of

services, procurement/purchasing, finance/control-

ling, production and sales/distribution. At the same

time, 47 of the companies stated that the greatest ben-

efit was seen in logistics (Minonne, 2011). A particu-

lar challenge in the presentation of processes in logis-

tics and purchasing lies in the strong link between

physical and administrative or IT processes (Liebe-

truth, 2016). Both BPMN 2.0 and EPC offer a means

to map physical and administrative processes. Ac-

cording to (Allweyer, 2015), EPC is still frequently

used as notation in the field of business process mod-

eling. EPC is mainly established in German-speaking

countries, but has disadvantages in automation. EPC

should no longer be preferred for process modeling in

the context of process automation (Freund and

Rücker, 2017). In addition, there is a clear trend to-

wards modeling business processes in BPMN 2.0.

The BPMN 2.0 modeling language is well-suited

where existing processes are to be documented and

modeled in a domain-oriented way and where the

main focus is the technical modeling and execution of

the models (Gadatsch, 2017; Liebetruth, 2016). One

notation introduced by the Object Management

Group (OMG) for modeling decision rules in business

process management is the Decision Model and No-

tation (DMN) (Freund and Rücker, 2017). Describing

the principle of decision logic of the process as busi-

ness rules has existed for a long time (Endl, 2004).

There are some software solutions on the market like

Drools or IBM Websphere ILOG JRules. However,

the use of the two standards DMN and BPMN makes

it possible to map and integrate the decision logic di-

rectly via a workflow management system. An ad-

vantage is thereby the combinability with BPMN,

which will be further improved in the BPMN 2.1

specification. In addition, the implementation of an

automated decision making process is possible, which

can present the requirements for the department as

Information Modeling of Rule-based Logistic Planning Processes Kanban Loop Planning Supported by a Workﬂow Engine

169

well as the IT in an understandable way. BPMN 2.0

thus offers three major advantages over EPC which

are important for the representation of rule-based lo-

gistics planning processes. First, it is designed to be

usable by logistics experts and skilled personnel with-

out IT knowledge. Secondly, it offers a way of mak-

ing modeled processes executable (Liebetruth, 2016).

Thirdly, BPMN 2.0 is supported by DNM, which is

relevant for the presentation of the rules. Thus, EPC

is not suitable for the representation of rule-based lo-

gistics planning processes.

As already mentioned at the beginning, the mate-

rial supply processes are most strongly affected by the

fast pace. The strongly fluctuating markets require a

waste-free, synchronized and short-cycle supply of

production to avoid bottlenecks in material supply.

An example of a rule-based logistics planning process

in production logistics is the planning and calculation

of the kanban loop. So far, these logistics planning

processes have been insufficiently represented by

models in standard modeling languages. Planning the

kanban loops is very time-consuming and is carried

out manually in many companies. However, this prin-

ciple is potentially error-prone. Basically, the proce-

dure is based on the principle of processing decision

rules that have a direct influence on the design of the

kanban loop. Decision rules can be documented in the

implicit knowledge of employees, in the program

code or in formally written down rules.

There are two options for modeling in a standard

modeling language. Decision logic can be integrated

into the model as scripts or external files in program-

ming languages such as Java or C++ can be connected

to the model. The disadvantage of linking to external

files is obvious, as logistics planners usually do not

have in-depth programming knowledge. In addition,

the logistics planner can no longer view the process

knowledge in the program code. External systems can

be linked to the process model by web service calls

through the code either in the models themselves or

in associated files. With the introduction by the OMG

of DMN as the official standard for decision rules, a

way to define deterministic decision logics for pro-

cesses, which can also be maintained by business us-

ers was created. An overview of the decision rules

used in the BPMN model (Figure 2) is shown in the

DMN decision table (Figure 1). This is linked to the

BPMN model and can be used to extract decision

logics from the model and present it in an easily un-

derstandable form.

Figure 1: Decision rules in the DMN-Model.

4 WORKFLOW

IMPLEMENTATION

In general, business processes are modeled based on

logically linked activities and can be automated using

a workflow engine. Workflows are automated process

operations in which, in addition to the processes,

predefined rules as well as the interacting participants

and systems are defined. When modeling executable

processes, the transition from domain-oriented to

technical models is the focus. Modeled processes are

basically semi-formal, represented in flow diagrams,

not directly executable and serve primarily for the

documentation and visualization of processes.

Executable workflows, on the other hand, must be

exact and allow a clear interpretation of the process

and the interaction. For this purpose, information

sources and sinks must be defined in the process, and

this includes ERP systems or other inventory

management systems in which the relevant

information for processes is stored: lot sizes,

packaging units and consumptions. Ideally, these

systems provide interfaces through which they can be

accessed from outside. If interfaces do not exist, they

must be defined additionally, otherwise automated

data exchange cannot be ensured. The modeling

language BPMN 2.0 is suitable for the automation of

business processes. The following

section describes how the exemplary implementation

of a workflow was carried out using the rule-based

“kanban loop” logistics planning process. Therefore

we describe the domain-oriented model, the technical

model and the necessary steps to get from the domain-

oriented to the technical model.

In the modeling of information models, a general

distinction is made between a domain-oriented model

and a technical model (Freund and Rücker, 2017).

The domain-oriented model contains more

organizational structures and forms a basic

framework for the documentation of the process. A

technical model, on the other hand, extends the

domain-oriented model with information that is

required as a workflow at the execution time. For this

KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems

170

purpose, the individual steps of the domain-oriented

model must be broken down into transactional tasks

which are implemented by individual components.

Figure 2 shows the model of a rule-based logistics

planning process: the kanban loop. Its description in

the literature is limited to the interpretation and

calculation of the number of kanban. Kanban in Jap-

anese stands for sign or card, but it is far more than

that. It stands for the production control element that

transforms a push system into a pull system (Gorecki

and Pautsch, 2014). Here, each kanban stands for a

real stock keeping unit and triggers the replenishment

process when it is removed. This means that the num-

ber of kanban limits the actual inventory. Therefore,

the planning of kanban loops is an important logistics

planning process, ensuring the material supply of

production. Individual planning process steps have

been described in the literature (Becker, 2018;

Gadatsch, 2017; Liebetruth, 2016). However, no

kanban loops with the planning process steps needed

have yet been modeled. This was developed in

collaboration with the partners of the “Intelligent

Production Logistics Competence Network” project,

e.g. a company for agriculture textile products or a

company for conductors and other technical experts.

At the beginning, a first process draft based on the

knowledge from practice and literature was prepared.

This process was then subjected to a plausibility

check by partners and other experts from logistics

planning. The domain-oriented model was modeled

in BPMN 2.0 and continuously further developed

with the knowledge and experience of the technical

experts. The model contains the steps for calculating

the number of kanban as well as the upstream and

downstream process steps that are necessary for the

design and introduction of the kanban loop. In the

following, these three focal points of the process are

referred to as process building blocks. The upstream

planning process steps (upstream process building

block) include executing an ABC/XYZ analysis to

check the kanban capability of the component,

determining the source and sink, checking the lot size

with the packaging unit, and determining the kanban

type. The ABC/XYZ analysis divides the components

according to consumption value (high, medium and

low) and prediction accuracy (high, medium and

low). Components with the properties AX, AY, BX,

CX, BY and CY are suitable for consumption control

and thus for kanban loops. An ABC/XYZ analysis is

a valuable aid for the logistics planner, but not the

only criterion as to whether there is kanban capability

or not. Other criteria may include component size and

technological limitations of the source and sink.

Therefore, after performing the analysis, the logistics

planner can still decide whether to cancel the process

even after kanban capability has been determined, or

to continue the process even though the component

BX, CX, BY or CY is not assigned. There are three

loop options in production logistics: warehouse to

supermarket, supermarket to production and

production to production. The decision for the loop

option influences the selection of the kanban type, lot

size and replenishment lead time. The next process

step is to check the ratio of the lot size to the

packaging unit. The packaging unit is the number of

components in the container. In the extreme case, the

packaging unit must be adapted to the container. In

Figure 2 the kanban loop process was terminated for

this scenario. In order to concentrate Figure 2 on the

essentials, a process termination was chosen. The

selection of the kanban type influences the

calculation. The kanban types to be selected are:

K-kanban: Classic kanban in which a card (K) is

attached to the container and is given to the operative

logistician when the last component is removed, thus

triggering the order for the next lot size.

B-kanban: This type also has a card, but this is not

removed when the last component is removed;

instead, the entire container (B) is returned with the

card to the source as empties, thus triggering the

order.

E-kanban: The logic is identical to that of the K-

kanban but the card is not returned. Instead a signal

that the last component was removed is sent back to

the source electronically.

The information flow of the order is shorter than with

K-kanban and B-kanban. The “physical

transmission” by card or container is eliminated and

replaced by an electronic transmission. Once the

upstream process building block has been completed,

the actual process steps for calculating the number of

kanban start. The kanban formula is described in

detail in the literature and is as follows (Burrows,

2015; Klevers, 2009):

Number of kanban = (replenishment lead

time * average consumption

rate)/packaging unit * safety factor +

safety stock

As already mentioned, the replenishment lead

time depends on the kanban type and is made up of

three parts: transport time, post-production time and

transmission or waiting time. The transport time is the

time between source and sink and depends on the

transport medium, transport cycles and handling

times. The post-production time depends on the lot

size in the case of the production-production cycle

option. It is omitted in the possible cycles warehouse-

supermarket and supermarket-production. The

transmission and waiting time depends on the

Information Modeling of Rule-based Logistic Planning Processes Kanban Loop Planning Supported by a Workﬂow Engine

171

selected kanban type. The average consumption is

calculated from past values and therefore involves

some uncertainty. This uncertainty is addressed using

the safety factor. In case of strongly fluctuating

consumption, the maximum consumption is often

used in the formula. In practice, this information is

retrieved either from the ERP system (Enterprise

Resource Planning System) or from databases.

During plausibility checks of the kanban loop rule-

based logistics planning process, it was often pointed

out that some information is not available in the ERP

system, for instance the packaging unit, which in

some cases was not maintained as a master data

record. This is particularly true for small and

medium-sized enterprises. In addition, it was pointed

out that implicit knowledge and the experience of

logistics planners play an essential role in whether the

number of kanban was calculated correctly. In the

process described, there are still two variants of the

triggering of an order. Variant 1 (V1) describes the

triggering of an order by a signalling point, also

known as collective or signal kanban. Here, kanban

are bundled according to a defined limit before the

order is triggered. Another variant (V2) describes

how an order is triggered with each kanban. The

decision is made in cooperation with operative

logisticians and production planners. It depends on

the local conditions and a high consumption rate.

After the successful calculation of the kanban loop,

the third and last process building block – the so-

called downstream process steps – starts. They

describe the steps required to implement a kanban

loop. For the implementation, the kanban must first

be generated. The type depends on the kanban type

selected at the beginning. With K-kanban and B-

kanban, the kanban must be attached to the containers

and the containers must be brought into the cycle.

With E-kanban, it is not absolutely necessary to print

out the kanban. However, it is necessary to check the

type of data transmission. The decisive factor is

whether technological support already exists or

whether technologies have to be procured before the

implementation of the kanban loop. Finally, the

operative logistician (e.g. tugger train driver) must be

informed. In practice, a further process for checking

the transport capacities between source and sink must

also be started here. This process was not take into

consideration here because of the concentration on

the kanban loop. So far, the domain-oriented part of

the entire kanban control cycle rule-based logistics

planning process has been described. Next, the steps

necessary to move from a domain-oriented model to

a technical one will be described, since the former

model is not yet suitable for execution on a workflow

Figure 2: The technical model.

KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems

172

engine. A technical model, which is also called a

workflow, “is a formally described, completely or

partially automated business process” (Gadatsch,

2017). Compared to the domain-oriented model, the

technical model contains additional information such

as error handling, responsibilities, but also interface

call-ups to other systems.

As shown in Figure 2 all tasks in the model, which

are relevant for automation, contain an icon that

defines their type. This determines which properties a

task has. Service tasks (represented by a cogwheel)

offer the ability to store scripts, whereas user tasks

(represented by a human as icon) offer input options.

In Figure 2 the differences to the domain-oriented

model are marked in red. Due to the lack of space one

can find the domain-oriented model online

(https://github.com/DanielHilpoltsteiner/KMIS_201

9_Paper_Appendix). All changes in the technical

model serve to refine the process flow and better

allocate tasks to the system or user. At the beginning,

the technical model was supplemented by the

information that has to be entered by the user at the

start of the process. For this purpose, the task “enter

part no.” was inserted at the beginning of the process

as a user task, in which the user must enter the article

number in an input screen. In addition, the service

task “database query” was added, which specifies that

information on the article number must be retrieved

from an external system so that it is available later in

the process. At the same time, scripts were stored and

variables defined in the aforementioned tasks in order

to be able to use the values in the workflow engine at

execution time. The same procedure was used to

check the lot size for the packaging unit, since here

too the information must be obtained from an external

system. The “calculate replacement time” task was

challenging during the transformation because

process logic has to be entered here. This was solved

by defining the calculations in the DMN table

“KanbanReplenishmentTime” from Figure 1. To

perform this work, the task was defined as a business

rule task and DMN used as the implementation detail.

It would also have been possible to implement this via

embedded scripts or an external program code.

However, both approaches would have the

disadvantage that the business rules could not be

maintained by the business experts themselves, since

most of them have no experience in programming. In

the case of external file links, it must be ensured that

this is known to a workflow engine at the time of

execution and is in the correct directory. When the

task is executed, information is exchanged between

the engine and the script using the input and output

parameters of the task.

During the transformation of the domain-oriented

into a technical model, it was also found that the

definition of output parameters and variables within

the model can only be used to a limited extent with

regard to the data types. While information entered in

input interfaces contains numbers or truth values,

neither of these two data types can be used as the

output of a task. This problem is solved by using

external scripts and files in which the program code

is managed. Even the design of forms within a model

is only possible in a rudimentary way and so it makes

sense to outsource this functionality to an external

program code.

5 EVALUATION

As intended in the DSR according to (Hevner and

Chatterjee, 2010), the developed artifact (Figure 2) is

evaluated. The domain-oriented model was con-

structed in cooperation with various technical experts

and thus represents a scientifically founded kanban

loop that includes factors relevant to practice. The do-

main-oriented model was increasingly refined in sev-

eral iterations. The next step was to transform the do-

main-oriented model into a technical model. As al-

ready described, broader requirements apply to this

model than to the technical model. It is important that

after the transformation the technical correctness is

maintained. Therefore, the process was executed on a

workflow engine and tested to ensure that it ran cor-

rectly and that all elements in the model were reached

and processed. For this, the model must be uploaded

to the engine. This was done by using a REST (Rep-

resentational State Transfer) from the modeling envi-

ronment.

Since digitization affects many SMEs are in-

volved in technology transfer projects, when choos-

ing a workflow engine open source providers and free

product versions were consciously considered. Fur-

thermore, the application can be used for further re-

search by third parties. SMEs are often financially

limited in their digitization resources. In addition,

many companies are only beginning to digitize their

processes and can approach the topic slowly by using

freely accessible software. The “Community Plat-

form” by Camunda was used as a concrete example

of a workflow engine. shows the first interface seen

by the user when they start the process. Here, the user

must enter the article number for which they want to

plan a kanban loop.

The application on the workflow engine was

made available to the logistics planner as a technical

model for testing the logic. It was noted that during

Information Modeling of Rule-based Logistic Planning Processes Kanban Loop Planning Supported by a Workﬂow Engine

173

implementation, the interfaces to external systems

such as inventory management systems were left out.

Exemplary values were chosen and firmly integrated

into the DMN (Figure 1) and BPMN models (Figure

2). Requesting the values from external systems is ul-

timately only an implementation detail. By publish-

ing the model and the decision rules, everyone is free

to take this step towards integration within their own

systems.

6 CONCLUSION

It has been shown that the challenge lies in bundling

implicit and explicit employee knowledge in logistics

planning and preparing it for programmers in a way

that ensured efficient and effective automation of

rule-based logistics planning processes. This helps

companies digitize their processes. The BPMN 2.0

modeling language in combination with DMN is able

to represent rule-based logistics planning processes.

It is equally suitable for employees from specialist de-

partments and for programmers in companies. The

processes can be represented completely, sustainably

and uniformly in a common notation. DMN also al-

lows rules to be mapped in the processes. The ad-

vantages of a transformation from a domain-oriented

to a technical model towards an executable process in

a workflow engine are obvious. It eliminates the extra

time and effort involved in software modeling. Spe-

cialist departments can model their processes them-

selves. The process logic is determined on the basis

of the decision rules, and employee knowledge is rec-

orded and documented. Continuous improvements,

which are necessary to survive in a volatile market,

can be implemented quickly through this approach as

resources can be used in a targeted manner. Special-

ized changes in the process can be carried out by the

departments themselves without needing the re-

sources of in-house programmers. Coordination pro-

cesses between specialist departments and program-

mers can be made more efficient through a common

(modeling) language. The process specifies the pro-

cess flow in the workflow engine. This means that the

process is not determined by the information flow, but

rather the reverse: the process defines the information

flow.

This procedure will be further elaborated and

checked for plausibility within the framework of the

“Intelligent Production Logistics Competence Net-

work” project, e.g. a company for agriculture textile

products or a company for conductors. The approach

offers small and medium-sized enterprises the oppor-

tunity to use their technical resources more sustaina-

bly. The free licenses of the open source platforms for

BPMN and DMN also offer small companies the op-

portunity to automate their processes and to start out

on digital transformation.

ACKNOWLEDGEMENTS

The “Competence Network Intelligent Production

Logistics” technology transfer project is funded by

the European Regional Development Fund (ERDF) -

Operational Program “Investment in Growth and Em-

ployment”, Bavaria 2014-2010.

REFERENCES

Allweyer, T. (2015) BPMN 2.0 - Business Process Model

and Notation: Einführung in den Standard für die

Geschäftsprozessmodellierung, 3rd edn, Norderstedt,

BOD - Books on Demand.

Becker, T. (2018) Prozesse in Produktion und Supply Chain

optimieren, Berlin, Heidelberg, Springer Berlin Heidel-

berg.

Burrows, M. (2015) Kanban: Verstehen, einführen, an-

wenden [Online], s.l., dpunkt. Available at http://

gbv.eblib.com/patron/FullRecord.aspx?p=4350075.

Endl, R. (2004) Regelbasierte Entwicklung betrieblicher

Informationssysteme: Gestaltung flexibler Infor-

mationssysteme durch explizite Modellierung der Ges-

chäftslogik (Zugl.: Bern, Univ., Diss., 2004), Köln, Eul.

Federal Ministry for Economic Affairs and Energy (2018)

SMEs Digital: Strategies for the digital transformation

[Online]. Available at https://www.mittelstand-digi-

tal.de/MD/Redaktion/DE/Publikationen/mittelstand-

digital-broschuere-englisch.html (Accessed 24 April

2018).

Freund, J. and Rücker, B. (2017) Praxishandbuch BPMN:

Mit Einführung in CMMN und DMN, 5th edn, Mün-

chen, Hanser.

Gadatsch, A. (2017) Grundkurs Geschäftsprozess-Manage-

ment, Wiesbaden, Springer Fachmedien Wiesbaden.

Gorecki, P. and Pautsch, P. (2014) Praxisbuch Lean Man-

agement: Der Weg zur operativen Excellence, 2nd edn,

München, Hanser.

Helmke, B. (2019) ‘Digitalisierung in der Logistik’, in Har-

tel, D. H. (ed) Projektmanagement in Logistik und Sup-

ply Chain Management: Praxisleitfaden Mit Beispielen

Aus Industrie, Handel und Dienstleistung, 2nd edn,

Wiesbaden, Gabler, pp. 183–207.

Hevner, A. R. and Chatterjee, S. (2010) ‘Design Research

in Information Systems Theory and Practice’, Inte-

grated Series in Information Systems Volume 22.

Klevers, T. (2009) Kanban: Mit System zur optimalen

Lieferkette, München, mi-Wirtschaftsbuch FinanzBuch-

Verl.

KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems

174

Kocbek, M., Jost, G., Hericko, M. and Polancic, G. (2015)

‘Business process model and notation: The current state

of affairs’, Computer Science and Information Systems,

vol. 12, no. 2, pp. 509–539.

Liebetruth, T. (2016) ‘Prozessmodellierung’, in Liebetruth,

T. (ed) Prozessmanagement in Einkauf und Logistik,

Wiesbaden, Springer Fachmedien Wiesbaden, pp. 27–

57.

Liebetruth, T. (2019) Die Informationsbasis des Supply

Chain Controllings: Forschungsstand, empirische An-

alyse, Gestaltungsempfehlungen, Wiesbaden, Springer

Fachmedien Wiesbaden GmbH.

Minonne, C., ed. (2011) Business-Process-Management

2011 - Status quo und Zukunft: Eine empirische Studie

im deutschsprachigen Raum ; building competence,

crossing borders, Zürich, vdf Hochschulverl. AG an

der ETH.

Plümer, T. and Steinfatt, E., eds. (2016) Produktions- und

Logistikmanagement, Berlin, Boston, De Gruyter.

Porter, M. E. (1986) Wettbewerbsvorteile: Spitzen-

leistungen erreichen und behaupten = Competitive ad-

vantage, Frankfurt, Campus.

Schubel, A. (2017) Dezentrale und kurzfristige Produk-

tionslogistikplanung.

Schubel, A., Seel, C. and Schneider, M. (2015) ‘Infor-

mationsmodelle für die Produktions- und Logistikpla-

nung - Eine Literaturanalyse des aktuellen Refer-

enzmodellbestands’, Wirtschaftsinformatik Proceed-

ings 2015.

Seel, C. (2014) ‘Vergleichende Analyse von polyglotten

mit reinen BPMN-Modellierungsstacks’, in, pp. 10–20.

Information Modeling of Rule-based Logistic Planning Processes Kanban Loop Planning Supported by a Workﬂow Engine

175