Keywords

1 Introduction

Process maps are a key concept for providing an overview of a company’s business processes [1]. They visualize the main relationships between processes and facilitate a basic understanding of how the company operates. The importance of process maps is illustrated by the growing extent of process modeling initiatives in practice. Often companies maintain process model repositories with thousands of process models [2]. Typically, creating a process map is the first task when introducing Business Process Management (BPM) into an organization as it provides an abstract view of all processes [3]. The process map is then used as a foundation for conducting the subsequent steps of the BPM lifecycle [4].

To date, a lot of research has focused on the quality and the design of singular process models [5–7]. Due to the increasing size of process model repositories in practice, many frameworks for the successful management of large repositories were introduced [8–10]. Also, some techniques have been developed for automatically deriving process categories from process model collections [11]. In this context, process architectures turned out to be a particularly useful strategy. Process architecture serves to systematically organize a collection of process models into different categories and store the details of each process model in the appropriate architecture level [12]. A process map is considered as the top most abstract level of the corresponding process architecture, hence, it represents the entrance to the different levels. While there is some initial research on abstraction and categorization of model collections [11, 13, 14], there is notable insecurity on how to capture such process-related information on the most abstract level i.e. the process map [1].

In practice, process maps are used for that purpose, however, without a standard modeling language being available. The major challenge in this context remains the specification of a language for process map design that integrates insights from actual usage in practice. Despite the importance of process maps for a BPM initiative and the management of process model repositories, there is only little research on process map design. For instance, prior research demonstrated that the design of process maps may have negative effects on the business process management success if due to incompleteness and incorrectness the maps cannot be understood intuitively [1]. One of the major challenges is that there are no standards available for creating process maps. Hence, companies freely define and visualize their process maps based on their own creativity. As a result, the meaning of the introduced symbols is often not well defined, and important aspects are subject to misinterpretation [1].

In this paper, we address this research gap by conducting an explorative study in order to better comprehend the nature of existing process maps. More specifically, we investigate the included concepts of 67 process maps from practice. As a result, we present a process map meta-model which integrates the concepts and relationships represented in these maps. Furthermore, we investigate patterns of usage of these concepts. In this way, we aim to provide a foundation for the standardization of a language for process map design.

The rest of the paper is structured as follows. Section 2 gives an overview of BPM and process maps. Section 3 introduces the collection of process maps we used for analysis along with the methods we used to derive our findings. Section 4 presents the results of our study. This includes a process map meta-model, as well as statistical analysis of the usage of process map concepts. Section 5 points to implications for practice and research. Section 6 concludes the paper.

2 Background

In this section, we discuss the background of our research. We first give insights into the organization of business processes within a company and the available techniques for doing so. Then, we present an overview of the current state of the art of process maps and highlight the motivation for our study.

2.1 Organizing business processes

Organizations operate through business processes which consist of activities performed in a particular order. Typically, a sequence of such business processes is performed in order to create a value for the customer [3]. However, processes may differ in their importance for value creation. Thus, they are commonly categorized based on the degree of their proximity to the end-user. To manage interrelations between the processes and to systematically document how the firm operates as a whole, organizations often adopt the BPM approach and start modeling their processes in form of process models. A process model visualizes the process steps by providing a diagrammatic representation of a business process. As a result of such modeling initiatives, organizations often end up with a large collection of process models, which may have limited value, if not organized properly. In this case, a process architecture helps to store all detailed process models and the relations between them in a systematic manner [12]. A process map is typically used as the top-level and most abstract model in a process architecture. It visualizes all processes and their relationships in a compact way [1].

In prior work, a rich stream of research has proposed guidelines for modeling singular processes [6–8] and for process architecture design  [12, 15–22]. Frameworks such as SCOR [23], eTom [24], Handels-H model [25], ARIS [26], DoD architecture framework [27], or the BPTrends pyramid [28] provide guidance for structuring process models on the different architecture levels. Some apply only to specific industry domains (SCOR, eTom, etc.), while others are more domain-neutral (ARIS, BPTrends Pyramid, etc.). In contrast to all these efforts, hardly any guidelines for designing process maps on the most abstract level of the process architecture exists. Existing process modeling languages (e.g. BPMN, EPC) are being used by practitioners for depicting singular business processes in details, however hardly any process map from practice has been designed using the rich pallette of symbols these modeling languages offer. Practitioners typically use their own creative capabilities and software not primarily developed for process modeling purposes (e.g. PowerPoint) when designing their process maps. As a result we are faced with a vast amount of heterogeneous process map designs, despite the fact that they all serve a similar purpose. Hence, up until now a modeling language for process map design is missing.

2.2 Process Maps

We can trace back the concept of process maps to the early 1980s when Porter introduced the value-chain model. The value chain provides a process view of an organization and represents it as a set of core activities a company has to conduct in order to create value for the customer [29]. Support activities are also required for value creation, but of less strategic importance. In order to understand their mutual dependence, linkages between activities have to be identified [30]. Scheer adopts the concept of a value-added chain [26]. He introduces a diagram that represents those processes that create value for the company. These processes are shown in a sequence, and each could be hierarchically decomposed into subprocesses that a super-ordinate process needs in order to be executed [26]. SIPOC is another frequently used approach, especially in Six Sigma and Lean manufacturing, stemming from the late 1980s [28, 31]. It stands for supplier, inputs, process, outputs, and customer and is used as a guide for analyzing these five aspects with main focus on the customer [28].

Beyond the process view of an organization, there are additional (external and internal) parties that influence the value creation. A framework encompassing all these is referred to as the business model. An example of such a model is the e3-value business model, which integrates three different value viewpoints, namely the business value viewpoint, i.e. the way economic value is created and consumed by the actors, the process viewpoint, i.e. the value viewpoint in terms of business processes, and the system architecture viewpoint, i.e. the information systems that enable and support business processes [32, 33]. Nine perspectives are distinguished by the business model canvas [34]. For an overview see [35].

Examples of concrete process maps can also be found in literature [3, 28, 36–41]; however, all studies refer to process maps coming from practice. Most are based upon the value-chain concept, while some include additional information as being used in business models. One thing all process maps have in common is that they all provide means of identifying typical process categories and the role each type of process plays for the company. Most of these process maps depict processes belonging to three different categories. An example of such a process map can be seen in Fig. 1.

Fig. 1.
figure 1

Example process map, adapted from [36]

Full size image

As illustrated in Fig. 1, generally, those processes that directly create value for the customer and generate revenue are called core processes [1, 37]. In a process map, these processes are usually related to each other in a sequential manner. Hence they are represented as end-to-end processes because they have a customer request as an input, and contain all those processes that lead to the request being served [42]. An end-to-end process is commonly a cross-functional process, i.e. a process that goes through more than one organizational unit [42]. In Fig. 1, the six core processes constitute an end-to-end process, with an indicated input (Supplier) and output (Customer). While an end-to-end process is build up of a number of core processes, a core process is a singular process that contains activities. A large-scale enterprise deals with core processes that contain even hundreds to thousands of such activities [8]. Therefore, in order to avoid a process model becoming too complex, it is usually hierarchically decomposed into subprocesses [12, 37]. For example, in Fig. 1 the core process “Order Processing” is hierarchically decomposed into five subprocesses (Process Order, Create Offer, etc.). Accordingly, this set of subprocesses build up to the initial core process.

In addition to the core process category, there are also processes that indirectly influence the value creation. These are clustered as support and management processes. Support processes provide resources to the core processes and enable them to operate in the most effective and efficient way, such as human resource management, information technology, etc. [37, 43]. Whereas, management processes include those processes that develop strategic plans, measure and analyse the performance of the core processes, and ensure that their execution is aligned with the company’s strategy [1, 37]. Thus, management processes are present throughout the entire core process flow, whereas support processes are called only when necessary. For example, the end-to-end process in Fig. 1 is triggered by a “Supplier” providing input, and all core processes are executed up until the customer has received the order. During the process execution the support process “Accounting” may be called in case some payment done by the customer needs to be handled. Similarly, a management process takes care that throughout the entire process flow all activities carried out are in compliance with the company’s strategy, such as high quality product, customer satisfaction, etc.

In addition to process categories, a process map also depicts relationships between the processes. According to [1], a relationship between processes coming from both same and different process categories, can be implicitly or explicitly shown. An explicit relationship occurs in case of a directed arrow or a close proximity between two processes, such as the end-to-end process in the core process category in Fig. 1. Also, most process maps explicitly portray a process decomposition into subprocesses [1]. The notion of input/output can as well be very often observed in process maps from practice. Same applies for resources, which serve as intermediate supply during process execution.

Whereas all these components are depicted in most process maps, hardly any research has been conducted on the extent to which these elements serve all the representational needs of process map designers. Therefore, we identify a meta-model on the basis of existing process maps from practice. In this way, we aim to consolidate the current practice of process map design in order to provide a foundation for developing a language that helps practitioners to design process maps in a standardized manner.

3 Research Design

The objective of this study is to understand the current practice of process map design. To this end, we analyze process maps from practice. In this context, we focus on the following goals:

  1. 1.

    Elicit meaning and develop knowledge of the concepts used within a single process map and the relations between them.

  2. 2.

    Find patterns of the combined usage of concepts and their frequency.

3.1 Methods

To address the first point, we gather process maps and analyze each of them for the concepts being used and any means by which the identified concepts were related to each other. We do this by examining each process map and identifying all concepts that are included within them. For example, the process map in Fig. 1 exhibits the notion of processes (e.g. Controlling, Pre Sales, Storage, Process Request, Accounting, etc.) belonging to three different process categories (Management, Core and Support). The processes in the core process category are represented as a value-chain diagram, hence we identify the sequential relation between the core processes. We can also observe the decomposition relation, because almost all of the core processes are decomposed into subprocesses. Due to the pentagon-shaped symbol used for the management processes pointing to the core processes, we assume an implicit manage relation between these two process categories. We observe the same behaviour between the support and core processes, thus assume the relation between these two categories is support coming from the support processes towards the core processes. Last, this process map also includes the notion of Supplier and Customer, which are instances of the concepts input/output, as they are positioned right before the first core process of the value-chain and directly after the last core process of the value-chain, respectively, showing that a core process starts with a trigger from a supplier, while the outcome of a core process goes to a customer.

Therefore, for identifying the concepts included in all process maps under investigation we rely on both the visual representation (e.g. symbols used) and the semantics of each represented concept (e.g. Customer after a value-chain of core processes indicates a consumer of a process output). As a result, we generate a process map meta-model which encapsulates all concepts and relations we observed. In this way, we generalize from a set of instance models towards their underlying meta-model. A similar research approach has been used in [44], however, with the goal of building hypotheses. In our research, we are interested in uncovering the implicitly used meta-model. We use UML (Unified Modeling Language) as a language to design the meta-model.

For identifying the frequency and combinations of concepts, we adopt the approach of [45]. First, we created an Excel spread sheet and recorded each concept, relation between the concepts, whether these relations occur between singular processes or a set of processes, etc. For example, in the process map from Fig. 1 we observed and recorded the following concepts: process, category (core, support and management), input, output, and relation (sequential trigger, decompositional trigger, support, manage). We treated each process map as a single unit of observation, and denoted each concept occurrence with a binary value. Consequently, we derived a chart depicting the most often used concepts in process maps from practice. As we encode usage of each concept with 1 and 0, we can apply hierarchical clustering using the Euclidean distance measure which finds the co-occurrence relationship between concepts, based on how many concepts the process maps have in common. In this way, we identify concepts that most frequently occur in a specific combination, and also those that rarely occur together within a single map.

3.2 Data Collection

Although we analyze process maps coming from both practice and literature, we refer to all as process maps from practice, because process maps from literature are typically slightly adapted maps taken as example from practice. As there are only very few research articles that discuss process maps, we browsed the following BPM books, which all cover process architecture as a topic [36–41, 46–50]. We ended up with a total of 21 adapted practice process maps from literature. In addition, we used three sources to collect the process maps we use for analysis. First, we conducted interviews with companies and 13 of them provided us with a print of their process map. Also, we used 5 process maps that were part of published case studies [51]. In order to reach saturation, thus make sure we cover all concepts used in existing process maps, we searched for additional process maps using an Internet search engine. For this we used two key words, namely “process map" and “process landscape". Besides the many search results, we chose 23 process maps that seemed to be somewhat different than the ones we already had (e.g. the concepts within these process maps had a slightly different visual representation of the concepts, or we spotted new concept combinations within single process maps, etc.). Altogether, we use 67 process maps in the analysis.

4 Findings

In this section, we discuss the findings of our study. In Sect. 4.1, we present the meta-model that we derived from the process map analysis and explain the included concepts. In Sect. 4.2 we give insights into the use of process map concepts, and we present the results of the hierarchical cluster analysis.

4.1 Process Map Meta-Model

The results of the process map analysis are summarized in the meta-model depicted in Fig. 2. The model provides a generic way to deal with process map design by depicting all unique concepts we found in the 67 process maps. In the following paragraphs, we describe the meta-model concepts in detail.

Process. The key component of process maps is a business process. A process is triggered by an input from the supplier. A process is usually clustered in a category with other processes that serve a similar purpose. A process could also belong to one or more phases depending on the time of execution. Processes can be conducted by actors and could eventually use a resource during their execution. It can be related to other processes in order to produce an output for the customer.

Fig. 2.
figure 2

Process map meta-model

Full size image

Supplier. A supplier is a party that provides inputs that triggers the execution of an end-to-end process, i.e. a sequence of core processes. The types of input provided by a supplier may include:

  • \(\circ \) An order (e.g. product, service, requirement, problem, etc.)

  • \(\circ \) A by-product (e.g. outcome of other processes within the same organization)

  • \(\circ \) A communication channel (e.g. telephone, email, etc.)

  • \(\circ \) A document (e.g. invoice, research data, etc.)

  • \(\circ \) A raw material (e.g. an unprocessed item used to create an end product)

  • \(\circ \) etc.

Customer. A customer is the one who receives outputs resulting from the execution of a process. An output consumed by a customer may include:

  • \(\circ \) A consummated order (e.g. ordered products, service, support, etc.)

  • \(\circ \) A document (e.g. invoice, process data, etc.)

  • \(\circ \) A finished good (e.g. product, etc.)

  • \(\circ \) etc.

Resource. A resource is a source of supply or support that can be drawn upon when needed by any process or an instance of a process. As example, consider the resource water, which is required during the production of energy. If necessary, one process uses one or more resources throughout its execution. However, a process does not necessarily need to use a resource in order to produce an output.

Actor. One process can have one or more actors (e.g. process owners) that are responsible for its performance. However, a process could also be executed without having an assigned actor.

Category. A category is a group of processes that have a particular role within one company. One process can belong to only one category. Processes that are clustered in one category serve a similar purpose. For example, the core process category typically holds all value-creation processes, while those processes that analyse and measure the performance of the core processes are usually placed in the management process category.

Phase. A phase is a temporal cluster of processes that contains a subset of processes coming from one or more process categories. It is temporal because a certain number of processes need to be performed in order for an intermediate outcome to be produced. This intermediate outcome is used as a trigger for the processes that belong to the next phase. The intermediate outcome could also be kept in the database for later usage, thus it does not necessarily need to trigger the next phase of processes. For example, manufacturing a product is commonly done in different phases. The first phase will deal with supplying all material needed for the product to be manufactured. The second phase would keep all those processes that handle the actual production. Finally, the third phase contains the processes that market or sale the finished goods.

Condition. The condition constraints or guards the relation that is used between two or more processes. For instance, if process C can only start after processes A and B have been executed, than the condition will rule-out all those relations that do not capture this behavior.

Relation. One process can be related to other processes through one or more relation types. There are four main process relations: trigger relation, data flow relation, support relation, and manage relation.

Trigger relations could be used between processes that belong to the same or to different process categories. There are two types of trigger relations:

  • \(\circ \) Sequential trigger is a control-flow relation used between processes to indicate order of performance. Thus, if two processes are related by a sequential trigger, then only when the first process finishes, the second process can start with execution. Alternative variations of process order are also possible. For instance, when one process is finished with execution, it could trigger more than one process. Accordingly, processes could also be executed in parallel. There could also exist process loops, which means that one single process, if necessary, could be triggered several times in a row until the desired outcome is produced.

  • \(\circ \) Decompositional trigger involves abstraction. It relates a core process with its subprocesses. Thus, if a process is hierarchically decomposed, it automatically has one or more subprocesses that need to be executed in order for the core process to finish. For example, for the core process “Pre Sales" from Fig. 1 to be performed, the subprocess “Process Request"need to be executed. On the other hand, the core process “Order Processing" can finish its execution if only the subprocess “Process Order" has been done. Typically after a decompositional trigger has been used, the next process to be performed is related with a sequential trigger. Otherwise, the process ends.

Data flow could be used between processes that belong to the same or different categories. This relation, when used, does not necessarily trigger another process. Instead, it only passes information from one process to another without interrupting its performance. For example, if process A produces some type of a document, and this document is one of many documents needed by process B, then process A passes the document to process B. However, even after receiving the document from process A, process B is still in an idle state and starts only when it has received all necessary documents.

Support relation is used only between processes that belong to different categories. This relation exists between the core and support process category. The direction of support goes from the support processes to the core processes. It is an implicit relation, thus no direct explicit relation is shown between two particular processes, as it is typically the case of using an arrow to indicate sequential trigger relation. Instead, all support processes are there to serve any immediate need by all of the core processes.

Manage relation, similarly like the support relation, is used only between processes that belong to different categories. However, this relation exists only between the management and core processes. The management processes manage the core processes by governing the entire process during its execution and by taking care that the process is performed according to the rules defined by the management processes.

4.2 Use of Process Map Concepts

The presented meta-model from Fig. 2 summarizes process map concepts in a compact fashion, whereas Fig. 3 gives an overview of the process map concepts and their use in the investigated maps.

Fig. 3.
figure 3

Occurrence frequency of process map concepts

Full size image

The numbers from Fig. 3 illustrate that the three category types core, management, and support are the most frequently used concepts. In fact, there is not a single process map without a core process category. However, also the management and support category are used by more than 85 % of the investigated maps. On the other hand, while sequential trigger is used by more than 50 % of the process maps, the remaining concepts included in process maps are significantly lower. About 40 % of the process maps are using inputs (Supplier) and outputs (Customer). Interestingly, the support and manage relations can be seen in only about 30 % of the process maps. This is quite unexpected considering the high usage of the corresponding categories. Apparently, the explicit inclusion of relations is only done by a few maps. Nevertheless, also other concepts are used by only some of the process maps. Particularly, the actor and the resource concept is rarely included. Also legends for explaining the illustrated concepts can only be found in a few cases.

In order to gain a deeper understanding of how the various process map concepts are utilized, we conducted a hierarchical cluster analysis using the Euclidean distance measure. As a result, we obtained a hierarchical classification of process map concepts that indicates which concepts are used alternatively and which concepts are used in combination.

Fig. 4.
figure 4

Hierarchical clusters of process map concepts

Full size image

Figure 4 illustrates the result of the hierarchical cluster analysis. The Figure gives us insights into the design of process maps, namely, it shows us which concepts are most frequently used together in a combination within one process map. On first glance we see that apparently there is a connection between the four most frequently used concepts as seen in Fig. 3 and the most frequent combination of concepts that usually appear in a single process map as seen in the upper part of Fig. 4. Thus, in most process maps we can expect to see the three process categories, and a sequential relation between the processes.

Concerning the categories, we learn that the management and the support category typically occur together. This indicates that organizations either focus on core processes (which are included in all investigated process maps), or they provide a broader view. In case they aim at providing a broader view, they tend to include both, the management and the support category.

With the relations we can also identify a clear pattern. While the sequential relation is often used in connection with the previously discussed categories, this does not apply to the other relations such as data flow or the manage and support relations. It appears that there are organizations with varying opinions about the level of detail they include in their process maps. While some organizations have process maps that provide many details including several types of relations, other organizations’ process maps aim at providing a broad overview and omit relations other than the sequential trigger. As for the supplier and the customer, we observe that both are part of one cluster. This indicates that these concepts are very likely to occur together. So, organizations tend to either show both or none of them.

Concerning the less frequently used concepts as seen in Fig. 3, we observe two aspects. First, actors, resources, and legends are part of one cluster. Hence, their occurrence is positively correlated. This can be explained by the phenomenon we already discussed in the context of relations. Either an organization provides all in their process map or they include none. Apparently, this tendency also applies to actors and resources. Moreover, if these two are used, they are likely to also be accompanied by a legend. The second point relates to the co-occurrence of actors, resources, and data flow. As indicated by the clusters, there is a tendency for these concepts to occur together. This illustrates that maps containing actors and resources are also more likely to illustrate how these resources are used during the entire process flow, until the point an output is produced.

The hierarchical cluster analysis points to the fact that process maps might be used with differing intentions. While some maps provide extensive detail such as actors, resources, and triggers, other are rather inclined to provide an abstract picture of the company’s processes. The latter category tends to omit concepts like data flow relations and other details such as actors and resources.

5 Implications

The findings from this paper have several implications for research and practice. In relation to implications for practice, we emphasize the importance of process map design. We argue that a well-designed process map should be able to elicit basic understanding over the company’s operations. This is particularly important because of the heterogeneous nature of currently used process maps due to the lack of a standardized modeling language for process map design. As such they might not be readily readable to people who were not involved in the creation of the process map. Therefore, in order to assure that the process map will be correctly interpreted and understood by all concerned parties, besides depicting the company’s processes in process categories, the process map designer should in addition include all concepts that aid in transmitting the knowledge the process map should convey. Hence, using a wide range of concepts makes a process map self-explanatory i.e. a person could interpret how the company operates without necessarily going into process details [1]. Beyond this, and also a topic for future research, despite the formal concepts included in all process maps, the creation of a process map should incorporate additional visual variables, such as color, shape, size, etc. [52], that will assist in transferring the knowledge in a cognitively effective manner [1]. The study [1] has shown that the inclusion of more concepts and visual variables in a process map does indeed have an effect on the underlying BPM success in a company. Also, taking into account that a process map design is considered as a strategic step and as such the foundation for the consequent BPM implementation [4, 53], a process map design could strongly influence the subsequent detailed process modeling.

In terms of implications for research, the analysis we present, along with the meta-model, provides solid basis for consolidation of concepts and represents a step towards a standardized language for process map design. Thus, this paper sets a starting point for their design by summarizing all used concepts in currently existing process maps from practice. This particularly assists in establishing a body of knowledge on current process map design.

This paper is also related to a stream of research that aims to improve conceptual modeling by investigating actual usage. In this way, it complements papers that investigate UML usage [54], BPMN usage [45], as well as the usage of models versus text [44].

6 Conclusion

In this paper, we investigated the concepts used in 67 process maps from practice. Based on this analysis, we derived a process map meta-model that covers all concepts these process maps use, as well as the relations between them. We presented the occurrence frequency of process map concepts. In addition, by using a hierarchical clustering method we showed the most frequent combinations of concepts used within a single process map.

We found that the core process category is used in all process maps, while those maps that include a support category also have a tendency to include the management process category. The sequential relation is frequently used by most maps to relate processes. In addition, our findings showed that those process maps that include additional information beyond process categories and relations, such as an actor, are also likely to include even more extra concepts, such as a resource, and show how all this information flows throughout the process execution with the use of a data flow relation.