Editing Business process modeling (section)

=== Modeling business process ===
==== Design of the process chains ====
If business processes are documented using a specific IT-system and [[#Representation type and notation|representation]], e.g. graphically, this is generally referred to as modeling. The result of the documentation is the ''business process model''.

[[File:TOBE-modell and ASIS-modell in PDCA.png|thumb|''To be'' model and ''as is'' model superimposed on the PDCA]]
;''As is'' modeling and ''to be'' modeling

The question of whether the business process model should be created through ''as is modeling'' or ''to be modeling'' is significantly influenced by the defined ''application'' and the ''strategy for the long-term success of business process modeling''. The previous procedure with analysis of business activities, [[#Definition of business processes|defineition of business processes]] and [[#Further structuring of business processes|further structuring of business processes]] is advisable in any case.

;''As-is'' modeling

Ansgar Schwegmann and Michael Laske explain: "Determining the current status is the basis for identifying weaknesses and localizing potential for improvement. For example, weak points such as organizational breaks or insufficient IT penetration can be identified."<ref name="SCHWEGMANN-LASKE">Ansgar Schwegmann and Michael Laske: ''Istmodellierung und Istanalyse'' in Jörg Becker, Martin Kugler and Michael Rosemamm (publisher): ''Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung'', 2nd corrected and expanded edition, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7</ref> <sup>(Chapter 5.1 Intention of the ''as is'' modeling) ← automatic translation from German</sup>

The following disadvantages speak against ''as is'' modeling:
* The creativity of those involved in the project to develop optimal target processes is stifled, as old structures and processes may be adopted without reflection in downstream target modeling and
* The creation of detailed ''as is'' models represents a considerable effort, also influenced by the effort required to reach a consensus between the project participants at interfaces and responsibility transitions
These arguments weigh particularly heavily if Business process re-engineering (BPR) is planned anyway.

Ansgar Schwegmann and Michael Laske also list a number of advantages of ''as is'' modeling:<ref name="SCHWEGMANN-LASKE" /> <sup>(Chapter 5.1 Intention of as-is modeling) ← automatic translation from German</sup>
* Modeling the current situation is the basis for identifying weaknesses and potential for improvement
* Knowledge of the current state is a prerequisite for developing migration strategies to the target state
* Modeling the current state provides an overview of the existing situation, which can be particularly valuable for newly involved and external project participants
* The ''as is'' modeling can be a starting point for training and introducing project participants to the tools and methods
* The ''as is'' model can serve as a checklist for later target modeling so that no relevant issues are overlooked
* The ''as is'' models can be used as starting models for target modeling if the target state is very similar to the current situation, at least in some areas
Other advantages can also be found, such as
* The ''as is'' model is suitable for supporting certification of the management system
* The ''as is'' model can serve as a basis for organizational documentation (written rules, specifications and regulations of the organization, ...)
* The requirements for workflow management can be checked on the basis of the ''as is'' model (definition of processes, repetition rate, ...)
* Key figures can be collected on the basis of the ''as is'' model in order to be compared with the key figures achieved after a reorganization and to measure the success of the measures.

;''To be'' modeling

Mario Speck and Norbert Schnetgöke define the objective of ''to be'' modeling as follows: "The target processes are based on the strategic goals of the company. This means that all sub-processes and individual activities of a company must be analyzed with regard to their target contribution. Sub-processes or activities that cannot be identified as value-adding and do not serve at least one non-monetary corporate objective must therefore be eliminated from the business processes."<ref name="SPECK-SCHNETT" /> <sup>(Chapter 6.2.3 Capturing and documenting ''to be'' models
)</sup>

They also list five basic principles that have proven their worth in the creation of ''to be'' models:
* Parallel processing of sub-processes and individual activities is preferable to sequential processing – it contains the greater potential for optimization.
* The development of a sub-process should be carried out as consistently as possible by one person or group – this allows the best model quality to be achieved.
* Self-monitoring should be made possible for individual sub-processes and individual activities during processing – this reduces quality assurance costs.
* If not otherwise possible, at least one internal customer/user should be defined for each process – this strengthens customer awareness and improves the assessability of process performance.
* Learning effects that arise during the introduction of the target processes should be taken into account – this strengthens the employees' awareness of value creation.

The business process model created by ''as is modeling'' or ''to be modeling'' consists of:

==== Sub-processes ====
;Delimitation

[[File:VAC Process sales pipeline.png|thumb|Breakdown of the business process ''Process sales pipeline'' into sub-processes based on phases]]
August W. Scheer is said to have said in his lectures: ''A process is a process is a process.'' This is intended to express the [[recursion|recursiveness]] of the term, because almost every process can be broken down into smaller processes (sub-processes). In this respect, terms such as ''business process'', ''main process'', ''sub-process'' or ''elementary process'' are only a desperate attempt to name the level of process decomposition. As there is no universally valid agreement on the granularity of a ''business process'', ''main process'', ''sub-process'' or ''elementary process'', the terms are not universally defined, but can only be understood in the context of the respective business process model.

In addition, some German-speaking schools of business informatics do not use the terms ''process'' (in the sense of representing the sequence of [[Action (Philosophy)|actions]]) and ''function'' (in the sense of a delimited ''corporate function''/action (activity) area that is clearly assigned to a ''corporate function owner'').

[[File:FT-Excerpt-of-company-functions.png|thumb|Function tree with an excerpt of typical company actions, ''sales pipeline'' relevant functions marked]]
For example, in August W. Scheer's ARIS it is possible to use functions from the ''function view'' as processes in the ''control view'' and vice versa. Although this has the advantage that already defined processes or functions can be reused across the board, it also means that the proper purpose of the ''function view'' is diluted and the ARIS user is no longer able to separate ''processes'' and ''functions'' from one another.

The first image shows as a value chain diagram how the business process ''Edit sales pipeline'' has been broken down into ''sub-processes'' (in the sense of representing the sequence of actions (activities)) based on its phases.

The second image shows an excerpt of typical ''functions'' (in the sense of delimited ''corporate function''/action (activity) areas, which are assigned to a ''corporate function owner''), which are structured based on the areas of competence and responsibility hierarchy. The ''corporate functions'' that support the business process ''Edit sales pipeline'' are marked in the function tree.

;Utilization

A business process can be decomposed into sub-processes until further decomposition is no longer meaningful/possible (smallest meaningful sub-process = ''elementary process''). Usually, all levels of decomposition of a business process are documented in the same methodology: Process symbols. The process symbols used when modeling one level of decomposition then usually refer to the sub-processes of the next level until the level of ''elementary processes'' is reached. Value chain diagrams are often used to represent ''business processes'', ''main processes'', ''sub-processes'' and ''elementary processes''.

;Workflow

A [[workflow]] is a representation of a sequence of tasks, declared as work of a person, of a simple or complex mechanism, of a group of persons,<ref>{{Cite web|url=https://www.iso.org/home.html|title=ISO - International Organization for Standardization|website=ISO|date=27 May 2024 }}</ref> of an organization of staff, or of machines (including IT-systems). A workflow is therefore always located at the elementary process level. The workflow may be seen as any abstraction of real work, segregated into workshare, work split, or other types of ordering. For control purposes, the workflow may be a view of real work under a chosen aspect.

==== Functions (''Tasks'') ====
[[File:Actions-of-an-elementary-process.png|thumb|Tasks of an elementary process, task sequence determined by three different approaches]]
;Delimitation

The term ''functions'' is often used synonymously for a delimited ''corporate function''/action (activita) area, which is assigned to a ''corporate function owner'', and the atomic [[Task (project management)|activity (task)]] at the level of the ''elementary processes''. In order to avoid the double meaning of the term ''function'', the term ''task'' can be used for the atomic activities at the level of the ''elementary processes'' in accordance with the naming in BPMN. Modern tools also offer the automatic conversion of a ''task'' into a ''process'', so that it is possible to create a further level of process decomposition at any time, in which a ''task'' must then be upgraded to an ''elementary process''.

;Utilization

The graphical elements used at the level of elementary processes then describe the (temporal-logical) sequence with the help of functions (''tasks''). The sequence of the functions (''tasks'') within the ''elementary processes'' is determined by their logical linking with each other (by [[Logical connective|logical operators]] or [[Business Process Model and Notation#Gateway|Gateways]]), provided it is not already specified by input/output relationships or Milestones. It is common to use additional graphical elements to illustrate interfaces, states (events), conditions (rules), milestones, etc. in order to better clarify the process. Depending on the modeling tool used, very different graphical representation ([[model]]s) are used.

[[File:FAD-with-input-output-resources-and-regulations.png|thumb|Sample of a '''F'''unction '''A'''llocation '''D'''iagram (FAD) for outsourcing master data to a separate view in order to keep the readability of the process model]]
Furthermore, the functions (''tasks'') can be supplemented with graphical elements to describe inputs, outputs, systems, roles, etc. with the aim of improving the accuracy of the description and/or increasing the number of details. However, these additions quickly make the ''model'' confusing. To resolve the contradiction between accuracy of description and clarity, there are two main solutions: Outsourcing the additional graphical elements for describing inputs, outputs, systems, roles, etc. to a [[Function Allocation Diagram]] (FAD) or selectively showing/hiding these elements depending on the question/application.

The ''function allocation diagram'' shown in the image illustrates the addition of graphical elements for the description of inputs, outputs, systems, roles, etc. to functions (''tasks'') very well.

==== Master data (artifacts) ====
The term ''[[master data]]'' is neither defined by [[The Open Group]] ([[The Open Group Architecture Framework]], TOGAF) or [[John Zachman|John A. Zachman]] (Zachman Framework) nor any of the five relevant German-speaking schools of business informatics: 1) [[August-Wilhelm Scheer|August W. Scheer]], 2) [[Hubert Österle]], 3) Otto K. Ferstl and Elmar J. Sinz, 4) Hermann Gehring and 5) Andreas Gadatsch and is commonly used in the absence of a suitable term in the literature. It is based on the general term for [[data]] that represents basic information about operationally relevant objects and refers to basic information that is not primary information of the business process.

For August W. Scheer in ARIS, this would be the basic information of the organization view, data view, function view and performance view.<ref name="SCHEER">August-W. Scheer: ''ARIS: Von der Vision zur praktischen Geschäftsprozesssteuerung'' in August-W. Scheer and Wolfram Jost (Hrsg.): ''ARIS in der Praxis: Gestaltung, Implementierung und Optimierung von Geschäftsprozessen'', Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-43029-6</ref> <sup>(Chapter 1 The vision: A common language for IT and management) ← automatic translation from German</sup>

For Andreas Gadatsch in GPM ('''G'''anzheitliche '''P'''rozess'''m'''odellierung (German), means holistic process modelling), this would be the basic information of the organizational structure view, activity structure view, data structure view, and application structure view.<ref name="GADATSCH"/> <sup>(Chapter 3.2 GPM – Holistic process modelling) ← automatic translation from German</sup>

For Otto K. Ferstl and Elmar J. Sinz in SOM ('''S'''emantic '''O'''bjekt'''m'''odell), this would be the basic information of the levels Business plan and Resourcen.

Master data can be, for example:
* The [[Organizational structure|business unit]] in whose area of responsibility a process takes place
* The business object whose information is required to execute the process
* The [[product (business)|product]] that is produced by the process
* The [[policy]] to be observed when executing the process
* The [[risk]] that occurs in a process
* The measure that is carried out to increase the process capability
* The [[Control (management)|control]] that is performed to ensure the governance of the process
* The IT-system that supports the execution of the business process
* The milestone that divides processes into process phases
* etc.

By adding master data to the business process modeling, the same business process model can be used for different ''application'' and a [[return on investment]] for the business process modeling can be achieved more quickly with the resulting synergy.

Depending on how much value is given to master data in business process modeling, it is still possible to embed the master data in the process model without negatively affecting the readability of the model or the master data should be outsourced to a separate view, e.g. [[Function Allocation Diagram]]s.

If master data is systematically added to the business process model, this is referred to as an ''artifact-centric business process'' model.

;Artifact-centric business process

The [[artifact-centric business process model]] has emerged as a holistic approach for modeling business processes, as it provides a highly flexible solution to capture operational specifications of business processes. It particularly focuses on describing the data of business processes, known as "artifacts", by characterizing business-relevant data objects, their life-cycles, and related services. The artifact-centric process modelling approach fosters the automation of the business operations and supports the flexibility of the workflow enactment and evolution.<ref>{{cite journal|last1=Yongchareon|first1=Sira|title=A View Framework for Modelling and Change Validation of Artifact-Centric Inter-Organizational Business Processes|journal=Information Systems|year=2015|volume=47|pages=51–81|doi=10.1016/j.is.2014.07.004}}</ref>

====Integration of external documents and IT-systems====
The integration of external [[document]]s and IT-systems can significantly increase the added value of a business process model.

For example, direct access to objects in a [[knowledge database]] or documents in a [[Business rule|rule framework]] can significantly increase the benefits of the business process model in everyday life and thus the acceptance of business process modeling. All IT-systems involved can exploit their specific advantages and cross-fertilize each other (e.g. link to each other or standardize the filing structure):
* short response times of the knowledge database; characterized by a relatively high number of auditors, very fast adaptation of content, and low requirements for the publication of content – e.g. realized with a [[wiki]]
* Legally compliant documents of the rule framework; characterized by a very small number of specially trained auditors, validated adaptation of content, and high requirements for the release of content – e.g. implemented with a [[document management system]]
* Integrating graphical representation of processes by a BPM system; characterized by a medium number of auditors, moderately fast adaptation of content, and modest requirements for the release of content

If all relevant objects of the ''knowledge database'' and / or documents of the ''rule framework'' are connected to the processes, the end users have context-related access to this information and do not need to be familiar with the respective filing structure of the connected systems.

The direct connection of external systems can also be used to integrate current measurement results or system statuses into the processes (and, for example, to display the current operating status of the processes), to display [[Software widget|widget]]s and show output from external systems or to jump to external systems and initiate a transaction there with a preconfigured dialog.

Further connections to external systems can be used, for example, for [[electronic data interchange]] (EDI).