On Data, Information, and Knowledge Representation in Business Process Models

Abstract

Three different phenomena, data, information, and knowledge, are relevant in business process modeling. However, business process modeling notations currently do not provide an opportunity to clearly distinguish between them. Therefore, it is necessary to analyze the existing notations to learn from their capabilities and drawbacks in order to arrive at modeling tools that can clearly distinguish between data, information, and knowledge.

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

Data, information, and knowledge are terms that are widely used in various fields of human activities and have caused discussions about their meaning since ancient times. Although there are various research works on scientific theories of data, information, and knowledge interpretation, e.g., in psychology, epistemology, social science, philosophy, cognitive science, and information theory, these terms still are used intuitively and often have no explicit unified definition even within one area of research.

This chapter shows that ambiguity exists concerning above-mentioned concepts as well as their use in several business process modeling notations (Expert Paper 2007; ARIS Method; ARIS community; IDEF3; IDEF0; BPMN; UML; Activity diagrams in UML 2.0; Business Modeling 1998; GRADE user guider; Arbeitsbericht; Heisig 2006; Woitsch and Karagiannis 2005; Weidong and Weihui 2008). This chapter presents experiments with the notations most frequently mentioned in scientific literature showing that by them data and information objects are not differentiated and often data, information, and material flow are represented by the same artifacts. The goal of this chapter is not to provide explicit and unified definitions. It strives analytically and experimentally to compare the most frequently studied business process modeling languages/notations (namely, extended event-driven process chain (eEPC) in ARIS tool (Expert Paper 2007; ARIS Method; ARIS community), Integration Definition for Function Modeling (IDEF0) (IDEF3; IDEF0), business process modeling notation (BPMN 2.0) (BPMN), Unified Modeling Language (UML 2.0) activity diagram (UML; Activity diagrams in UML 2.0), and business modeling language GRAP;ES-BM in GRADE tool (Business Modeling 1998; GRADE user guider)) from the point of view data, information, and knowledge.

Additionally to business process modeling notations, this chapter covers notations for modeling of knowledge intensive processes where basic phenomenon is knowledge. In these processes, the principal success factor is adequate modeling of knowledge conversions. At the same time approaches that focus on knowledge management within the business process level have limited capabilities. Usually knowledge is modeled using specific knowledge modeling notations (e.g., KMDL (Arbeitsbericht), GPO-WM (Heisig 2006)), and only few of them include process perspective (e.g., PROMOTE (Woitsch and Karagiannis 2005), RAD (Weidong and Weihui 2008)).

Knowledge might be considered as one of the business process dimensions, because knowledge is created as a result of process execution, knowledge is used to perform a process, and it is distributed among process participants (Heisig 2006). Benefits provided by extending business process models with knowledge dimension are described in Supulniece et al. (2010). This chapter considers the Knowledge Modeling and Description Language (KMDL 2.2) which has widest knowledge modeling capabilities among the process-oriented knowledge modeling languages (Supulniece et al. 2010).

The rest of this chapter is structured as follows – Sect. 2 briefly describes data, information, and knowledge representation within selected modeling notations. Section 3 illustrates differences and similarities in data, information, and knowledge dimension by presenting the deposit contract conclusion process in selected modeling notations. This chapter concludes with Sect. 4, where preliminary research results and further research are discussed.

2 Data, Information, and Knowledge Modeling

The existence of an organization is achieved by the coordination of member activities because members without the coordination are individuals rather than an organization. Coordination of BP activities within an organization is achieved with information exchange between organization members. This is the basis for knowledge generation and distribution. Information is usually defined as interpreted data. In the remainder of this chapter, we consider data as facts about the universe of discourse. Knowledge then is the model of the universe of discourse which is used for interpretation of data. However, in cases where particular business process modeling languages are discussed, we stick to their “native” interpretations of data, information, and knowledge (if such interpretations are available).

Business process modeling notations support data and information inclusion into business process models. For example, a data element is presented in various notations (Expert Paper 2007; ARIS Method; ARIS community; IDEF3; IDEF0; BPMN; UML; Activity diagrams in UML 2.0; Business Modeling 1998; GRADE user guider); however, interpretation of this element differs per notation. Additionally notations do not separate accurately data from information, allowing the use of the same symbols for both concepts. Usually knowledge is modeled by means of specific knowledge modeling notations (e.g., KMDL (Arbeitsbericht), GPO-WM (Heisig 2006)), and only a few of them include process perspective (e.g., PROMOTE (Woitsch & Karagiannis 2005), RAD (Weidong and Weihui 2008)). These BP-oriented knowledge management methods focus on storing and sharing knowledge. As a result, they lack the ability to model in an adequate manner the decisions, actions, and measures, which are causing a sequence of processes. Most of these methods are convenient only for knowledge management experts and require additional training for nonexperts (Supulniece et al. 2010).

In this section, we will give brief overview of data, information, and knowledge concept representation and interpretation of the following notations: GRAPES-BM in GRADE tool (Business Modeling 1998; GRADE user guider), eEPC diagrams in ARIS (Expert Paper 2007; ARIS Method; ARIS community), KMDL (Arbeitsbericht), IDEF0 (IDEF0), UML 2.0 activity graphs (UML), and BPMN 2.0 (BPMN).

2.1 Data Representation

BPMN – BPMN is constrained to support only the concepts of modeling that are applicable to business processes; therefore, data and information models are out of the scope of its specification (BPMN). While BPMN shows the flow of data (messages) and the association of data artifacts to activities, it is not a data flow language. To model the items (physical or information items) that are created, manipulated, and used during the execution of a process, the following constructs are used: data objects, messages, and data associations (Fig. 49.1a–c). Data is represented with the following four elements: data objects, data inputs, data outputs, and data stores (Fig. 49.1a). ARIS eEPC – ARIS eEPC notation allows multiple ways to show data in a process model (Expert Paper 2007): either as abstract clusters or technical terms that describe information, or depicted as information carriers, such as documents and CDs. ARIS eEPC does not explicitly separate data and information; thus, the same objects could be used to represent both concepts. A document reflects real information holders (Fig. 49.2a), but a cluster is data collection and is used to represent the data model (Fig. 49.2b).

Fig. 49.1

BPMN elements for data and data flow modeling (a) Data objects, (b) Messages, (c) Data associations

Fig. 49.2

ARIS eEPC elements for data and data flow modeling (a) Document, (b) Cluster of data

GRAPES-BM – The graphical representation of a business process diagram in GRADE (Business Modeling 1998; GRADE user guider) is similar to a flowchart. It is possible to specify data or information items on the event arrows that connect the tasks of the process, thus showing data and information flows. Besides, there are two special symbols to represent the use of data in BP diagram: a data store and a data object (Fig. 49.3). A data store symbol indicates a persistent store of data or materials. A typical use of the data store is to represent a related database. On the other hand, data stores may simply represent a stock of goods. A data object represents just one unit. It is a temporary store of information or materials.

Fig. 49.3

GRAPES-BM elements for data and data flow modeling (a)A: Data store and data object, (b) Data and information flows

UML2 Activity Diagram (UML) – UML2 activity diagram is used for business process modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the detailed logic of a business rule. It is based on data flow models – a graphical representation of how data move around an information system (Activity diagrams in UML 2.0).

The specification of this notation defines only a data store element. A data store node is the central buffer node for non-transient information. The data store notation is a special case of the object node notation. See Fig. 49.4 for example.

Fig. 49.4

Data store node example (Activity diagrams in UML 2.0)

IDEF0 – There are several methods under IDEF family, e.g., IDEF0 for function modeling for process modeling (IDEF0). The IDEF0 does not separate data and information. These concepts could be modeled by one and the same symbol – an arrow: input arrow and output arrow (Fig. 49.5). Arrows convey data or objects related to functions to be performed.

Fig. 49.5

IDEF input/output arrows for data flow modeling

2.2 Information Representation

BPMN – Information does not have special element in BPMN, although message, message flow, conversation, and choreography refer to information and information flow (BPMN). Message is an object which depicts the contents of communication between two participants, which is transmitted through message flow (see Fig. 49.1b). Message flow is a connecting object that shows the flow of messages between two participants. A conversation (Fig. 49.6a) represents a set of message flows grouped together based on a concept and/or a correlation key. A conversation involves two or more participants. Choreography is a type of process, which differs in purpose and behavior from a standard BPMN process (Fig. 49.6b). Choreography formalizes the way business participants coordinate their interactions. The focus is not on orchestration of the work performed by these participants, but rather on the exchange of information (messages) between these participants. Choreography is a definition of expected behavior; it brings into view message exchanges and their logical relation as conversations.

Fig. 49.6

Example of additional process types in BPMN (a) Collaboration, (b) Choreography

GRAPES-BM – Information does not have a specific symbol; however, it is possible to specify information items on the event and path arrows that connect task, event, and decision nodes. Additionally events with the category “message” corresponding to objects produced by one task and transmitted to another (Business Modeling 1998; GRADE user guider) could be considered as information object. This may be an informal object, such as a notice that something has been completed, or a formal one, such as an invoice and bill, when the information is formally associated with the event via a corresponding data type.

UML2 Activity Diagram (UML; Activity diagrams in UML 2.0), ARIS eEPC (Expert Paper 2007; ARIS Method; ARIS community), and IDEF0 (IDEF0) – These diagrams can be used for modeling information flows in business processes; however, the original notations do not provide an explicit definition for the information concept. Moreover, UML activity diagram is more expressive for modeling data flows inside information system and is less suitable for business process modeling.

KMDL – This language is not primarily intended for information flow representation, yet it includes a special symbol for information. Information is modeled as information object, which usually exists as a text, drawing, or diagram on paper or electronic form (e.g., a document, audio file, and bitmap). Information exists outside the people and can include explicit knowledge of people (Arbeitsbericht). Information objects can be in the form of an input or output object of conversion.

2.3 Knowledge Representation

ARIS eEPC – Knowledge is represented by two object types, knowledge category and documented knowledge, and can be model by two model types, knowledge structure diagram and knowledge map (ARIS Method). The object type knowledge category is an object with its content referring to specific knowledge (both implicit and explicit), such as project management knowledge, specific industry knowledge, and specific technology knowledge (Fig. 49.7a). The documented knowledge object type deals with knowledge which is explicitly documented or at least can be documented in principle (Fig. 49.7b). The knowledge structure diagram knowledge categories can be organized into subgroups based on their content. A knowledge map depicts the distribution of various knowledge categories within an organization.

Fig. 49.7

Knowledge representation in ARIS eEPC (a) Knowledge category, (b) Documented knowledge

KMDL (Arbeitsbericht) – In KMDL 2.2, there is a basic distinction between three views: (1) process-based view, (2) activity-based view, and (3) communication-based view.

In the first process-based view, tasks are combined in a sequence of actions. For every task roles and the used information systems can be specified.

A task in the process-based view can consist of multiple knowledge conversions that could be specified in the second activity-based view. Start and end objects of conversions can be both information objects and knowledge objects (Fig. 49.8b). Knowledge objects can be related to persons, teams, or undefined persons. Additionally, it is possible to define knowledge as requirements for appropriate task (Fig. 49.8a), namely, functional, methodical, social, or technical requirements. The technical requirements can be covered by functions of information systems. The coverage of the remaining requirements is ensured by – also differentiated – knowledge objects of persons/teams. Beside the types of requirements, it is possible to differentiate between mandatory and optional requirements.

Fig. 49.8

Knowledge representation in KMDL (a) Knowledge and information objects, (b) possible types of conversions

Finally, the third communication-based view provides the basis to model communication within an organization. Knowledge objects are artifacts which refer to tacit knowledge of the person, and they might be used for creation of the skill catalogue.

Within KMDL, it is possible to model only tacit knowledge which belongs to certain person or group. Knowledge is anchored in the activities and skills of the knowledge carrier and additionally in her/his ideals, values, and experiences. In contrast, explicit knowledge could be modeled with information objects that are attached to certain conversion in business process model.

3 Comparisons of the Modeling Notations

In this section, three notations are selected for comparison (BPMN, ARIS eEPC, and KMDL) because taken together they represent almost all aspects of data, information, and knowledge modeling discussed in the previous section. To illustrate the described differences of data, information, and knowledge representation, a simplified business process example from the banking industry is used. The presented business process does not reflect all details and flow alternatives as this is not the aim of this chapter. Business process starts when client contacts the bank with the aim to open a deposit account. Bank employee presents to the client available products/services and their conditions. Based on this information, client chooses fixed-term deposit (also known as a term deposit, a bond, or fixed deposit in other countries). Selection of other deposit products is not modeled. Then the bank employee presents possible “terms” (period of time) and respective interest rate offers, and the client selects the one. The bank employee asks if the client has the bank account. The process branch for the client without account is not modeled to keep example as small as possible. If the client has the account, then the employee starts identification process to perform manipulations with client’s account. For identification, the employee ask the client’s document, e.g., passport, ID, or similar document. Then he/she enters some client data in the information system to check validity of the document if the client has rights to manipulate with the account and other information according to internal regulations. When the client is successfully identified, the bank employee prepares the contract in the information system and asks the client to sign it. Simplified business process example ends when the client signs the contract.

To illustrate data, information, and knowledge interpretation in BPMN notation, three diagrams were created for the described business process – a basic processes view (Fig. 49.9), choreography model (Fig. 49.10), and collaboration model (Fig. 49.11).

Fig. 49.9

Example of data and information flow modeling in BPMN

Fig. 49.10

Example of choreography modeling in BPMN

Fig. 49.11

Example of collaboration modeling in BPMN

BPMN stresses the process view representation, offering a number of symbols for modeling various processes and event types. For these tasks, BPMN is one of the most suitable modeling notations. However, data and information flow representation is considered secondary. As a result, the developed process models are not clear enough for data and the information analysis. It should be noted that BPMN and other modeling languages under discussion do not separate accurately data from information, allowing the use of the same symbols for both concepts. For example, in Fig. 49.9, the client’s data is represented by data object, and the data of interest rate, maturity, and amount are modeled by data collection symbol. The same data object symbol is used to model documents. Information flow is represented with message arrows and message symbols.

BPMN provides a specific choreography model which allows to concentrate only on conversation between performers. It means that if the basic process model shows frequent communication between performers, then it is useful to model this interaction in a separate model, showing the initiators of communication for each activity and potential speech act. It is possible to consider that in this case it is modeled as nonmaterialized information flow. For example, using choreography model, it is possible to model standard conversation models in bank for bank employers who communicate with clients (Fig. 49.10). However, this model does not show how performer’s knowledge changes during the conversation and does not specify the available communication tools.

The choreography model in Fig. 49.10 represents possible communication within a particular business process; in contrast, a collaboration model in Fig. 49.11 includes all possible types of interactions between performers within an organization. There is a possibility to add collaboration symbols to particular business process activities, thus showing the communication point. For example, in Fig. 49.11, it is possible to see when and by whom the bank employee interacts performing his/her tasks. Collaboration models are another way how to represent nonmaterialized information flow.

To illustrate data, information, and knowledge interpretation in ARIS eEPC notation, two diagrams are created – process view (Fig. 49.12) and process view with knowledge dimension (Fig. 49.13). To model process view, the modeler needs to choose the viewpoint because the process cannot be represented from the client’s and bank employee’s viewpoints simultaneously. Process view includes sequence of activities and events from the bank employee’s viewpoint. A role is added for each activity. In Fig. 49.12, process is modeled from the bank employee’s perspective, the activities are mainly assigned to bank employee role, and events are invented by actions of the client. According to notation, event does not have an assigned role. If a document is used during activity (e.g., contract document created), a document symbol is linked to particular activity. In comparison, BPMN uses data artifact for contract.

Fig. 49.12

A simplified example of data and information flow modeling in ARIS eEPC

Fig. 49.13

Example of knowledge modeling in ARIS eEPC

ARIS eEPC has an advantage over the discussed notations since it allows visualizing data and information flows though it does not separate these two concepts. Besides, ARIS eEPC contains many symbols to specify additional information of process activities.

ARIS eEPC process view with the knowledge dimension allows to model only output knowledge (created during activity or obtained/documented as result of activity), mainly for processes which create innovative knowledge. Requirements for the role or input knowledge are not envisaged. The bank employee in deposit contract conclusion example does not collect new knowledge if we do not interpret temporal information about client goals and purpose of the visit as knowledge. Thus, process view is redone according to client perspective, where it is possible to show new knowledge that the client acquires. In Fig. 49.13, knowledge about products and conditions is linked to “get information about products and conditions” activity as the client acquires this knowledge during the conversation with the bank employee. The same knowledge is presented also in KMDL notation (Fig. 49.15).

ARIS eEPC allows modeling separately knowledge hierarchy structure (knowledge categories, tacit/implicit, and documented knowledge) or knowledge map. The knowledge structure diagram is located in the requirements definition data view. The knowledge map, like the expanded model types for business process modeling, is in the requirements definition control view.

KMDL anticipates modeling in three views: (a) process view presents only the sequence of activities and actors (IS, person, or group), similarly to high-level process representation in other business process modeling notations; (b) activity view models particular activity in detail if this is a knowledge intensive activity. It is possible to demonstrate knowledge conversions and identify requirements for successful activity fulfillment; (c) communication view shows general communication channels, like conversation model in BPMN notation. In this chapter, we present first two views, namely, Fig. 49.14 shows process view and Fig. 49.15 represents activity view.

Fig. 49.14

Example of process view in KMDL

Fig. 49.15

Example of knowledge modeling in KMDL

KMDL all materialized issues are considered as information. Actually in some cases, it might not be so, e.g., “visual materials” from an example (Fig. 49.15) can be considered as a snapshot of several professionals’ knowledge. Besides, it is impossible to specify the owner of information, and consequently if more than one performer is involved in the process, it is impossible to establish the information source. Thus, in KMDL, knowledge can be modeled only as tacit, but explicit knowledge is considered as documented information. However, in many cases, it is very useful (functional, methodical, social, and technical requirements) to define explicitly what knowledge and skills are mandatory for activity performer. One more interesting KMDL feature is that it is impossible to model a situation when the process is carried out by one performer who converts existing tacit knowledge into new tacit knowledge. Finally, KMDL has no possibility to model business process logic in full if compared to BPMN and ARIS eEPC.

From the above-mentioned, we can conclude that BPMN and ARIS eEPC are more expressive for modeling process logic, decision points, and control flows, where BPMN offers extended notation for concerning control flow structures and ARIS eEPC is far more expressive in linking with other dimensions (e.g., information systems, products, organization, risks, and key performance indicators). Besides, BPMN diagrams are even directly executable by a process engine. In contrast, ARIS eEPC was originally not designed to describe processes to be executed on a process engine. Instead, it is meant as a language to capture and visualize business processes (ARIS community). Knowledge modeling is possible with KMDL and ARIS eEPC, for data modeling UML activity diagram is more convenient, but for information flows BPMN collaboration and choreography models could be used. However, the discussed modeling languages/notations do not distinguish information and data, allowing their modeling with the same symbols. As a result, this leads to ambiguity and misunderstanding of developed models.

4 Conclusions and Future Work

In this chapter, several business process modeling notations are reviewed, some are process oriented and some are knowledge oriented. The most frequently studied notations in scientific literature were selected to understand their data, information, and knowledge interpretation and modeling capabilities. From the selected list of notations, only ARIS EPC and KMDL support knowledge modeling. ARIS eEPC knowledge modeling support is incomplete, but KMDL has poor capabilities of process control flow modeling. Other notations (BPMN, UML activity diagram, IDEF0, GRAPES-BM, including ARIS eEPC) enable data and information modeling, but do not offer a strict border between these terms allowing using the same elements and symbols for data and information representation.

In the future work, it is planned to review these terms from information theory perspective, analyzing their physical nature and proposing respective definitions. Secondly, it is proposed to implement knowledge dimension in business process models based on well-established data, information, and knowledge definitions.