A Tangible Modeling Interface for Subject-Oriented Business Process Management

Abstract

Processes are an important part of every organization’s value creation and therefore have to be executed in the most effective and efficient way. Process Analyses are a first step of Business Process Management to identify weak spots and potential improvements within processes. Even a rough documentation of processes in a graphical way, a so-called process model, raises process awareness and transparency for all involved parties. However, it is not as common as one might think that an organization has all processes documented in a complete and up-to-date form or documented at all. In reality even existing process models might not properly reflect the executed processes because the involved process actors are not part of the process survey. And even if they are involved, the complexity of most modeling notations and their respective tools can have a deterrent and overwhelming effect on the user. For executing process surveys we offer a tangible modeling tool that provides a modeling framework and enables even modeling novices to directly model their own part of the process, the S-BPM Buildbook. The method and the notation are based on Subject-oriented Business Process Management and its low complexity of only five symbols. The modeling process itself is completely detached from any kind of software to further lower the complexity and instruction time and to increase intuitiveness. We are aware that for process management steps, like a detailed analysis, documentation or implementation, some kind of software support is required. For this a recognition algorithm was developed that converts the tangible process model into a digital form as a generic XML file. The XML file can then be imported into the software tool in use. Two case studies were executed to examine the S-BPM Buildbook. The first case study evaluates the tool regarding its intuitiveness and usability to describe real-life processes. The second case study compares the time needed for instructions and the actual modeling process while using the S-BPM Buildbook, with a pen and paper approach.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Today, processes are a very important, if not the most important part, of an organizations value creation. Every organization, be it charitable, commercial or otherwise, executes many different processes on a different bases. However, from our own experiences in the fields of industrial engineering and informatics, we have recognized that this does not necessarily mean that neither the processes are executed in an effective or efficient way, nor the process executors are aware of their involvement in a process. Independently from the actual field of application it is crucial to execute processes as effectively and efficiently as possible.

In general this task is accomplished through Business Process Management (BPM) activities, even though the term process is not restricted to specific fields or divisions and can represent, among others, a business process, a development process, a production process, or the process of process improvement itself (Fischermanns 2006). A first step for an ongoing process analysis is to survey and document the processes in a graphical way, the process model. Even a rough process model increases the level of transparency and helps all involved parties to better understand existing and future processes (Fischermanns 2006; Horváth and Partners 2005). However, business practice has revealed that process models are often outdated, incomplete or nonexistent. So for the necessary steps of process analyses it is important to keep process models up to date and ensure that the models include all relevant process information necessary to describe and execute the processes. But why is this often not the case? One reason for this is the fact that the actual “end users are typically not participating in the modeling process” (Mutschler and Reichert 2013). This means that the one element that actually executes the process, which is responsible for it and may provide the most experiences and knowledge regarding a process, is excluded from the process survey : the process actor.

By actively incorporating the process actors into the survey and modeling phase it is possible to directly document relevant process knowledge and experience, and validate the gathered knowledge (the process model) at the same time. However, the complexity of most modeling notations and their respective tools often has deterrent and overwhelming effect on the user (Horváth and Partners 2005). This includes novices and experts alike. For instance, the Business Process Model and Notation (BPMN) applies 40–170 symbols, depending on how one counts. Although everyone might learn the most complex modeling language and tool, a common process actor rarely is an expert in modeling, and neither has the time nor the desire to learn a complex modeling tool (Turetken and Demirors 2013). In addition, organizations often focus on the technical application of the tool instead of fulfilling the requirements for an efficient application of the modeling procedure and the resulting process models (Schmelzer and Sesselmann 2013).

These aspects has led us to develop a tool that provides a framework for process modeling and directly involves the process actor in the modeling process. The tool has to be intuitive to understand in a way that even process modeling novices are able to use it in an intuitive way. The modeling design and notation have to be as simple as possible but still convey all relevant process information. Furthermore, for simplicity reasons the modeling process itself should be as far as possible detached from any kind of software. By using the notation of the Subject-oriented Business Process Management method and its five symbols (Fleischmann et al. 2012) we developed a tangible modeling interface which we term the “S-BPM BuildBook” (Fleischmann 2013; Fleischmann and Bachinger 2014; Fig. 8.1).

Fig. 8.1

The S-BPM Buildbook

On the following pages we will explain the development of the S-BPM Buildbook in detail. We will describe the development of a prototype and the final version of the tool, present the notation for modeling, and provide some design rationale. Furthermore, we will present two case studies. The first case study evaluates the intuitiveness of the S-BPM Buildbook, involving a group of testers (Fleischmann 2013), and the second one compares the S-BPM Buildbook with a traditional pen and paper approach (Aumayr and Bloderer 2014). Hereby, the process management steps following the process survey cannot be neglected. Phases like documentation or implementation are often accomplished with the support of software-based tools. For this instance we have developed a recognition algorithm that allows us to convert the tangible process model into a generic XML file via camera or mobile phone.

2 Defining a Framework for Modeling: Design and Notation

S-BPM allows us to decompose a process into subjects and to describe each subject behavior as its own part of the process (Fleischmann et al. 2012). In this way S-BPM enables each process actor to model his part of the process by himself/herself. So why not just give the process actor a pen and some sheets of paper and say “Go for it!”? Everyone knows how to use a pen, no instructions required, and the modeling process is as intuitive as it can get. That is true, if we only regard the perspective of the process actor. But someone, namely the modeling expert, has to read and interpret all the different subject behaviors to bring them together and to create a whole process. Two experimental case studies executed by Recker et al. (2010) and Weitlaner et al. (2013) show that if there is no framework for the modeling process the same process will be modeled in many varying designs, ranging from “all text” to “all graphics” (Fig. 8.2).

Fig. 8.2

Process design archetypes (Recker et al. 2010)

These different designs make it particularly difficult for third parties to interpret and understand the process models and bring the various process parts together. Consequently, modeling without any restrictions might meet the requirement for intuitiveness, because no instructions are needed, but fail for structured working conditions for the modeling expert. At least some degree of framework is required to provide such conditions. According to these case studies, Flowchart Design (Recker et al. 2010) is considered the most intuitive and also the one leading to models with the best process quality . In this case quality refers to the relevant process information contained in the process model as well as the understandability of the process models for third parties.

A Flowchart Design mainly consists of abstract graphics (i.e., rectangles) and text to describe processes. It uses none or a negligible amount of concrete graphics. The latter supports the S-BPM notation through abstract symbols and by documenting concrete process information, like message or subject names, in textual form. The S-BPM notation uses five symbols which keep the complexity of the notation relatively low. Three symbols visualize the “function” state, the “send” state and the “receive” state, one symbol the subject, and one symbol (an arrow or comparable) state transitions and messages (Fleischmann et al. 2012). Based on the S-BPM notation and the Flowchart Design we have developed the S-BPM Buildbook (Table 8.1).

Table 8.1 S-BPM Buildbook notation (Fleischmann 2013)

3 Developing the S-BPM Buildbook

Existing tangible modeling tools like tabletop concept mapping (TCM) already apply S-BPM in conjunction with a tangible modeling interface to model processes by arranging blocks on a digitally augmented tabletop (Oppl and Stary 2009; Oppl 2011). So why should we develop another tangible tool? Well, the TCM tool still requires input via keyboard and mouse, in addition to the tangible blocks, to enter concrete subject names, message names or other process information. Hence, TCM does not allow a complete detachment from a software suite, and still requires at least one expert who can operate the software during the modeling process.

The goal of using a tangible interface without any kind of software resulted in the application of a letter case as basic structure. The process is modeled by arranging different colored plugs on the surface of the letter case. The application of the Flowchart Design and the S-BPM notation resulted in the following notation for the S-BPM Buildbook (Fleischmann 2013; Fleischmann and Bachinger 2014).

The modeler can then write relevant process information, like names of the states or messages, on top of the plugs by using an overhead marker. For the basic structure when modeling the size of an average laptop was used for initial orientation.

3.1 The First Version

The first prototype had a size of 450 × 250 × 40 mm (closed) and was made out of a material called “Corian” (Fig. 8.3; cf. Wikipedia 2014). The plugs are held in place on a predefined grid by magnets inside the plugs. This ensures that the plugs cannot move by accident and still enables the modeler to change the created model anytime.

Fig. 8.3

The first prototype of the S-BPM Buildbook (Fleischmann 2013)

However, with a weight of 6.5 kg the first prototype was too heavy, the transition plugs were too small to write on, and the measurements of the state plugs were too space consuming given the limited space of the frame. These findings have led to the development of the second version of the S-BPM Buildbook.

3.2 The Second Version

For the second version of the S-BPM Buildbook all plugs were changed, resulting in a uniform size, achieved by smaller state plugs and bigger transition/message plugs compared with the first version (Fig. 8.4). The overall height could be reduced to 19 mm (from 40 mm) by using a construction of alternating layers (corian-metal-corian) instead of steel balls. This also resulted in a weight reduction, down to 3.6 kg.

Fig. 8.4

The S-BPM Buildbook with the different colored plugs (Fleischmann 2013)

The use of software tools for more advanced process management phases could not be neglected. In order to support them we developed a “tangible to digital” conversion interface allowing the user to import the tangible process model into a software-based tool by making a picture of the S-BPM Buildbook. The step of converting the tangible process model into a digital one is still completely detached from the actual modeling process.

4 Tangible-to-Digital Process Model Conversion

Utilizing the concrete orientation of the plugs through the grid, the small number of symbols, and the clear differentiation of states by color, an image detection algorithm and an appropriate interface for a digital conversion was developed. By taking a picture via camera or mobile phone it is possible now to document and convert the process model from the S-BPM Buildbook into a generic XML file (Fleischmann 2013; Fleischmann and Bachinger 2014).

Figure 8.5 shows the subject behavior of a generic supplier. After receiving an order the supplier calculates the price and depending on the actions taken by the ordering actor either starts negotiations and prepares the delivery, or ends the process (Fig. 8.5).

Fig. 8.5

Supplier process modeled with the S-BPM Buildbook

In a second step the picture has to be loaded into the recognition software. The textual information on the plugs has to be entered manually on the right side of the user interface. This includes the information for each plug and the name of the state-transition plugs (Fig. 8.6).

Fig. 8.6

The supplier process in the recognition software (left) and the XML file (right)

After manually adding the textual information the XML file can be generated (Fig. 8.6, on the right). The plugs are identified via an ID and their state is defined by the color. Due to the generic XML format it is possible to import the file into practically any software suite—assuming that a proper interface exists.

A first version of such an interface was developed for the Metasonic Suite (Metasonic GmbH 2014), which is a software tool specifically developed for S-BPM. Figures 8.7, 8.8 and 8.9 show how the supplier process can be imported into the software suite with only a few mouse clicks.

Fig. 8.7

Buildbook import into the Metasonic Suite

Fig. 8.8

The automatically generated subject interaction diagram in the Metasonic Suite

Fig. 8.9

The automatically generated subject behavior diagram of the Supplier

The example shows that the modeling process itself is completely detached from any kind of software requirements. After the process has been imported the software-based modeling tool can be used for further, more advanced, process management steps like documentation, optimization or even integration.

So much for the theory; but how does the S-BPM Buildbook work in an actual process survey? Two case studies are reported in the next sections.

5 Case Studies

Would the S-BPM Buildbook be as intuitive as intended? Two case studies were performed in the field, one in the course of a diploma thesis (Fleischmann 2013), and another in the course of a bachelor thesis, both intended to examine the intuitiveness of such a new tool.

5.1 First Case Study: Novices in Modeling and the S-BPM Buildbook

The goal of the first case study was to test the S-BPM Buildbook during a practical application regarding its usability and intuitiveness. The interviewed actors were modeling novices and had little or no knowledge regarding process management and process modeling. To evaluate the intuitiveness of the S-BPM Buildbook we created a questionnaire the respondents had to answer after performing the survey.

The case study was carried out at the “Center für industrielle Produktivität” (Center for Industrial Productivity, CiP) at the Technical University Darmstadt. The CiP is an initiative by the TU Darmstadt and McKinsey & Company with the goal to educate and research in the fields of real-life production processes. The surveyed process represents a production process for hydraulic cylinders, including the delivery of the raw material, the manufacturing of the single components, the internal logistics, and the final assembly of the cylinders. The production process, the various workstations (the subjects) and their interactions are clearly defined, although not documented in an explicit form.

The four participating actors received a 20-min introduction into the S-BPM method and the S-BPM Buildbook. Each of the participants is an actor in the production process and any actor is able to operate at any workstation. After the introduction each actor was assigned to one of the working stations (each representing a subject) and was given the task of modeling his respective subject behavior by using the S-BPM Buildbook.

After approximately two hours all actors had completed their respective process models.

Figure 8.10 shows two out of five subject behaviors modeled in the course of the field study. The subject behavior on the left side describes the production. The subject behavior on the right side captures the internal logistics.

Fig. 8.10

Two subject behaviors that were modeled during the first case study (Fleischmann 2013)

The sample survey and the results from the questionnaires seem to confirm the S-BPM Buildbook’s intuitiveness. The actors began to model their processes simultaneously and during the survey the actors autonomously began to mutually review each other’s process models. Even if we consider the fact that each actor is able to execute any part of the process we may assume a level of intuitiveness of the design and notation in this behavior. Real life experience has shown that even modeling experts are not always able to understand a process model that was modeled by a different person, even if both know the process and the notation. The questionnaires show that the modelers rate the letter case as very intuitive and flexible to operate and easy to understand. They actually commented that the S-BPM Buildbook is fun to work with, in our opinion a claim not many modeling tools can make.

However, as promising as this evaluation might seem there are several factors that have to be considered. In order to collect sufficient data for a proper evaluation it is necessary to examine the S-BPM Buildbook in connection with different processes. There are many different process types (like management processes, production processes, etc.) with varying degrees of complexity. Production processes tend to be highly structured, which make them relatively simple to document. Surveys with more abstract processes, like management processes, have to be executed as well to elevate the S-BPM Buildbook’s application with any kind of process survey.

In the performed survey all the process actors represented “working level” employees from the production line. This allows no conclusion on how employees from the higher management level would work with the Buildbook, or how a survey would work with a mixture of different employee levels. Finally, there were only four process actors involved, a number too small for any quantitative or qualitative evaluation.

5.2 Second Case Study: “Pen and Paper” Versus “the Buildbook”

In the second case study a process survey executed with the S-BPM Buildbook is compared to a survey done with pen and paper . To create an identical starting point the surveys were done in a company which consists of two independent business areas. Although they are in different business areas the executed processes are practically the same. The only differences were the actual employees, allowing us to compare the same process surveyed with different tools and different people.

All process participants modeled their respective part of the process either with pen and paper or with the S-BPM Buildbook. In a second step the process models were transferred in a process modeling software by modeling experts. The measuring points for the comparison were the time needed for instructions, the time needed for the process actors to finish their process models, and the time needed to transfer the process models into a software tool. This includes the time required for additional questions addressed to the process actors because of obscurities. Please note that at the time of this case study the tangible-to-digital interface for the S-BPM Buildbook was not completed. The process models were transferred to the software tool manually.

The surveyed process is a process used to create proposals. The involved subjects in this process are the secretary, the technician and the CEO.

In the beginning of the survey all participants got a brief introduction to business processes and process documentation. This general introduction took 30 min. The instruction for using the S-BPM Buildbook took 30 min while for the pen and paper method the instruction time was practically zero. Each process actor modeled his or her process isolated from the other participants. This measure was deemed necessary to prevent the process actors from communicating with, and so influencing, each other, although under normal circumstances it is recommended to allow and support communication between all process modelers. In the following the direct comparison is provided of the process models that were created with the respective tools, as well as a brief description of each part of the process (Aumayr and Bloderer 2014).

The process begins as soon as the secretary receives a customer request either by e-mail, mail, fax or phone. The secretary verifies the customer data for correctness and completeness. If the customer is not in the system a new entry is created for the customer and the request is forwarded to the technician. If the order is taken the secretary has to verify the technician’s price calculation (Fig. 8.11).

Fig. 8.11

Subject behavior of the secretary; S-BPM Buildbook (left) and pen and paper (right) (Aumyar and Bloderer 2014)

After the technician receives the customer request he will communicate with the customer to specify the specific requirements. The technician then decides whether the order can be fulfilled according to the requested specifics. In case the order is taken and all details with the customer have been clarified the technician creates a first cost estimation which the CEO has to verify in case the order value is higher than 5000 €. If the technician receives a positive answer from the CEO he calculates the actual price and sends it to the secretary for confirmation. If the calculation is confirmed by the secretary the technician sends it to the customer (Fig. 8.12).

Fig. 8.12

Subject behavior of the technician; S-BPM Buildbook (left) and Pen and paper (right) (Aumayr and Bloderer 2014)

If the estimated order value is higher than 5000 € the CEO has to verify the order for the technician (Fig. 8.13).

Fig. 8.13

Subject behavior of the CEO; S-BPM Buildbook (left) and Pen and paper (right) (Aumayr and Bloderer 2014)

Table 8.2 shows the overall time needed for each step for both of the used modeling methods.

Table 8.2 Time comparison of both modeling methods

The pen and paper method did not require any instructions as everybody is familiar with the use of pen and paper. About 30 min were needed to explain the S-BPM Buildbook and how to use it. The overall time needed to model the processes required about 45 min with pen and paper and 40 min with the S-BPM Buildbook. The actual difference between the two methods was the overall time needed for the process conversion . To completely understand the various parts of the process modeled with pen and paper and transfer it to the software an overall time of 120 min was needed. This was due to the fact that the process actors had to be contacted and questioned again to clarify obscurities and misunderstandings. Using the processes modeled in the S-BPM Buildbook the time required to transfer the process information was only 45 min.

Although the S-BPM Buildbook requires more instruction time than a modeling method using pen and paper, the overall time required is still far less than the time needed for instructions for a software tool. In addition, the case study has shown again that modeling novices are able to use the S-BPM Buildbook to model processes of varying complexity. The biggest advantage of the S-BPM Buildbook compared to pen and paper is the provided framework which helps third parties to understand and interpret the process models. This can be clearly seen in the time needed for the conversion of the process models from tangible to digital. However, some kind of learning effect on the side of the modeling experts (the interviewers) could result in a shorter period of time required for understanding and interpreting the process.

6 Overall Conclusion

As shown in the first case study the S-BPM Buildbook can be operated in a straightforward way by modeling novices using an intuitive modeling design and notation. The predefined design and notation serve as guideline, to prevent inconsistencies between different users and ensure the highest possible quality of the resulting process models. The S-BPM Buildbook provides a framework to modelers to create non-redundant and syntactically correct process models while being detached from software-based input to model processes. The tool can be provided to several modelers simultaneously, thus supporting a subject-oriented approach for collective process surveys.

The first case study gives a first insight regarding the practical application of the S-BPM Buildbook. Although the participants were modeling novices, all process actors were students and the CiP represents a laboratory environment. Additionally, there was no possibility to evaluate whether the quality of the surveyed process models is sufficient for moving on in business process management.

The second case study also shows that it is possible for modeling novices to use the S-BPM Buildbook after giving only a brief introduction. Furthermore, the S-BPM Buildbook provides a proper framework for process modeling that supports third parties that are not involved in the actual process understanding and in interpreting the process. Further case studies have to be performed, especially to gain insight in how to model larger and more complex processes when using the S-BPM Buildbook.