Editing Business process modeling (section)

== Topics ==
=== Analysis of business activities ===
==== Define framework conditions ====
The analysis of business activities determines and defines the framework conditions for successful business process modeling. This is where the company should start,
* define the relevant ''applications'' of business process modeling on the basis of the [[business model]] and where it is positioned in the [[value chain]],
* derive the ''strategy for the long-term success of business process modeling'' from the [[business strategy]] and develop an approach for structuring the business process models. Both the relevant ''purposes'' and the ''strategy'' directly influence the [[process map]].
This ''strategy for the long-term success of business process modeling'' can be characterized by the market-oriented view and/or the resource-based view. ''Jörg Becker and Volker Meise'' explain: "Whereas in the market view, the industry and the behavior of competitors directly determine a company's strategy, the resource-oriented approach takes an internal view by analyzing the strengths and weaknesses of the company and deriving the direction of development of the strategy from this."<ref name="BECKER-MEISE"/> <sup>(Chapter 4.6 The resource-based view) ← automatic translation from German</sup> And further: "The alternative character initially formulated in the literature between the market-based and resource-based view has now given way to a differentiated perspective. The core competence approach is seen as an important contribution to the explanation of success potential, which is used alongside the existing, market-oriented approaches."<ref name="BECKER-MEISE"/><sup>(Chapter 4.7 Combination of views) ← automatic translation from German</sup> Depending on the company's strategy, the ''process map'' will therefore be the business process models with a view to market development and to resource optimization in a balanced manner.

==== Identify business processes ====
Following the identification phase, a company's business processes are distinguished from one another through an analysis of their respective business activities (refer also to business process analysis). A business process constitutes a set of interconnected, organized actions (activities) geared towards delivering a specific service or product (to fulfill a specific goal) for a particular customer or customer group.

According to the European Association of Business Process Management (EABPM), establishing a common understanding of the current process and its alignment with the objectives serves as an initial step in process design or reengineering."<ref name="EABPM" /> <sup>(Chapter 4 Process analysis) ← automatic translation from German</sup>

The effort involved in analysing the as-is processes is repeatedly criticised in the literature, especially by proponents of business process re-engineering (BPR), and it is suggested that the definition of the target state should begin immediately.

''Hermann J. Schmelzer and Wolfgang Sesselmann'', on the other hand, discuss and evaluate the criticism levelled at the radical approach of business process re-engineering (BPR) in the literature and "recommend carrying out as-is analyses. A reorganisation must know the current weak points in order to be able to eliminate them. The results of the analyses also provide arguments as to why a process re-engineering is necessary. It is also important to know the initial situation for the transition from the current to the target state. However, the analysis effort should be kept within narrow limits. The results of the analyses should also not influence the redesign too strongly."<ref name="SCHMELZER"/> <sup>(Chapter 6.2.2 Critical assessment of the BPR) ← automatic translation from German</sup>

[[File:Core_process_(quality_management).gif|thumb|Typical breakdown of a '''process map''' into management, core and support processes]]

==== Structure business processes – building a process map ====
''Timo Füermann'' explains: "Once the business processes have been identified and named, they are now compiled in an overview. Such overviews are referred to as process maps."<ref name="FUEERMANN">Timo Füermann: ''Prozessmanagement: Kompaktes Wissen, Konkrete Umsetzung, Praktische Arbeitshilfen'', Hanser, München 2014, ISBN 978-3-446-43858-3</ref> <sup>(Chapter 2.4 Creating the process map) ← automatic translation from German</sup>

[[File:Process-map-for-a-market-driven-company.png|thumb|Example of a '''process map''' for a market-driven company]]
''Jörg Becker and Volker Meise'' provide the following list of activities for structuring business processes:
* Enumeration of the main processes,
* Definition of the process boundaries,
* Determining the strategic relevance of each process,
* Analysis of the need for improvement of a process and
* Determining the political and cultural significance of the process<ref name="BECKER-MEISE"/> <sup>(Chapter 4.10 Defining the process structure) ← automatic translation from German</sup>

The structuring of business processes generally begins with a distinction between management, core, and support processes.
* ''Management processes'' govern the operation of a company. Typical management processes include corporate governance and [[strategic management]]. They define corporate objectives and monitor the achievement of objectives.
* ''Core processes'' constitute the [[core business]] and create the primary value stream. Typical operational processes are [[purchasing]], [[manufacturing]], [[marketing]], and [[sales]]. They generate visible, direct customer benefits.
* ''Support processes'' provide and manage operational resources. They support the core and management processes by ensuring the smooth running of business operations.  Examples include [[accounting]], [[recruitment]], and [[technical support]].

[[File:VAC-production-company.png|thumb|Example of a '''process map''' for a resource-driven company]]

==== Structure core processes based on the strategy for the long-term success of business process modeling ====
As the ''core business processes'' clearly make up the majority of a company's identified business processes, it has become common practice to subdivide the core processes once again. There are different approaches to this depending on the type of company and business activity. These approaches are significantly influenced by the defined ''application'' of business process modeling and the ''strategy for the long-term success of business process modeling''.

In the case of a primarily market-based strategy, end-to-end core business processes are often defined from the customer or supplier to the retailer or customer (e.g. "from offer to order", "from order to invoice", "from order to delivery", "from idea to product", etc.). In the case of a strategy based on resources, the core business processes are often defined on the basis of the central corporate functions ("gaining orders", "procuring and providing materials", "developing products", "providing services", etc.).

In a differentiated view without a clear focus on the market view or the resource view, the core business processes are typically divided into CRM, PLM and SCM.
* CRM (customer relationship management) describes the business processes for customer acquisition, quotation and order creation as well as support and maintenance
* PLM ([[product lifecycle management]]) describes the business processes from product portfolio planning, product planning, product development and product maintenance to product discontinuation and individual developments
* SCM ([[supply chain management]]) describes the business processes from supplier management through purchasing and all [[Production (economics)|production stages]] to delivery to the customer, including installation and commissioning where applicable
[[File:Process-map-for-a-value-driven-company.png|thumb|Example of a '''process map''' for a value-driven company]]
However, other approaches to structuring core business processes are also common, for example from the perspective of customers, products or sales channels.
* "Customers" describes the business processes that can be assigned to specific customer groups (e.g. private customer, business customer, investor, institutional customer)
* "Products" describes the business processes that are product-specific (e.g. current account, securities account, loan, issue)
* "Sales channels" describe the business processes that are typical for the type of customer acquisition and support (e.g. direct sales, partner sales, online).
The result of structuring a company's business processes is the ''process map'' (shown, for example, as a [[value chain diagram]]). ''Hermann J. Schmelzer and Wolfgang Sesselmann'' add: "There are connections and dependencies between the business processes. They are based on the transfer of services and information. It is important to know these interrelationships in order to understand, manage, and control the business processes."<ref name="SCHMELZER" /> <sup>(Chapter 2.4.3 Process map) ← automatic translation from German</sup>

=== Definition of business processes ===
[[File:VAC-production-company3.png|thumb|A definition of product development]]
The definition of business processes often begins with the company's core processes because they
* Fulfill their own market requirements,
* Operate largely autonomously/independently and independently of other business areas and
* Contribute to the [[contribution margin|business success]] of the company,
For the company
* Have a strong external impact,
* Can be easily differentiated from other business processes and
* Offer the greatest potential for business process optimization, both by improving [[Business performance management|process performance]] or [[productivity]] and by reducing [[costs]].

[[File:VAC CRM Sales order-processing-and-project management.png|thumb|A definition of customer relationship management]]
The scope of a business process should be selected in such a way that it contains a manageable number of sub-processes, while at the same time keeping the total number of business processes within reasonable limits. Five to eight business processes per business unit usually cover the performance range of a company.

Each business process should be independent – but the processes are interlinked.

The definition of a business process includes: What result should be achieved on completion? What activities are necessary to achieve this? Which objects should be processed (orders, raw materials, purchases, products, ...)?

Depending on the prevailing corporate culture, which may either be more inclined towards embracing change or protective of the status quo and the effectiveness of communication, defining business processes can prove to be either straightforward or challenging. This hinges on the willingness of key stakeholders within the organization, such as department heads, to lend their support to the endeavor. Within this context, effective communication plays a pivotal role.

In elucidating this point, Jörg Becker and Volker Meise elucidate that the communication strategy within an organizational design initiative should aim to garner support from members of the organization for the intended structural changes. It is worth noting that business process modeling typically precedes business process optimization, which entails a reconfiguration of process organization – a fact well understood by the involved parties. Therefore, the communication strategy must focus on persuading organizational members to endorse the planned structural adjustments."<ref name="BECKER-MEISE" /> <sup>(Chapter 4.15 Influencing the design of the regulatory framework) ← automatic translation from German</sup> In the event of considerable resistance, however, external knowledge can also be used to define the business processes.

[[File:VAC PLM with SCRUM.png|thumb|Value chain diagram with exemplary representation of "product life cycle management" with SCRUM]]

==== General process identification and individual process identification ====
''Jörg Becker and Volker Meise'' mention two approaches (''general process identification'' and ''individual process identification'') and state the following about general process identification: "In the general process definition, it is assumed that basic, generally valid processes exist that are the same in all companies." It goes on to say: "Detailed reference models can also be used for general process identification. They describe industry- or application system-specific processes of an organization that still need to be adapted to the individual case, but are already coordinated in their structure."<ref name="BECKER-MEISE"/> <sup>(Chapter 4.11 General process identification) ← automatic translation from German</sup>

''Jörg Becker and Volker Meise'' state the following about individual process identification: "In individual or singular process identification, it is assumed that the processes in each company are different according to customer needs and the competitive situation and can be identified inductively based on the individual problem situation."<ref name="BECKER-MEISE"/> <sup>(Chapter 4.12 Individual process identification) ← automatic translation from German</sup>

The result of the definition of the business processes is usually a rough structure of the business processes as a value chain diagram.

=== Further structuring of business processes ===
[[File:VAC-production-company4.png|thumb|Example of the decomposition of a business process into sub-processes – supplemented by milestones, business units, data objects and IT-systems]]
The rough structure of the business processes created so far will now be decomposed – by breaking it down into sub-processes that have their own attributes but also contribute to achieving the goal of the business process. This decomposition should be significantly influenced by the ''application'' and ''strategy for the long-term success of business process modeling'' and should be continued as long as the tailoring of the sub-processes defined this way contributes to the implementation of the ''purpose'' and ''strategy''.

A sub-process created in this way uses a [[Scientific modelling|model]] to describe the way in which procedures are carried out in order to achieve the intended operating goals of the company. The model is an abstraction of reality (or a target state) and its concrete form depends on the intended use (application).

A further decomposition of the sub-processes can then take place during [[#Modeling business process|business process modeling]] if necessary. If the business process can be represented as a sequence of phases, separated by [[Milestone (project management)|milestones]], the decomposition into phases is common. Where possible, the transfer of milestones to the next level of decomposition contributes to general understanding.

The result of the further structuring of business processes is usually a hierarchy of sub-processes, represented in value chain diagrams. It is common that not all business processes have the same depth of decomposition. In particular, business processes that are not safety-relevant, cost-intensive or contribute to the operating goal are broken down to a much lesser depth. Similarly, as a preliminary stage of a decomposition of a process planned for (much) later, a common understanding can first be developed using simpler / less complex means than ''value chain diagrams'' – e.g. with a textual description or with a turtle diagram<ref name="FUEERMANN" /> <sup>(Chapter 3.1 Defining process details) ← automatic translation from German</sup> (not to be confused with [[Turtle graphics|turtle graphic]]!).

=== Assigning the process responsibility ===
[[File:Pyramid-of-process-responsibility.png|thumb|Sample for a pyramid of process responsibility]]
Complete, self-contained processes are summarized and handed over to a responsible person or team. The ''[[Ownership|process owner]]'' is responsible for success, creates the framework conditions, and coordinates his or her approach with that of the other process owners. Furthermore, he/she is responsible for the exchange of information between the business processes. This coordination is necessary in order to achieve the overall goal orientation.

=== 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).

=== Model consolidation ===
This is about checking whether there are any redundancies. If so, the relevant sub-processes are combined. Or sub-processes that are used more than once are outsourced to support processes. For a successful model consolidation, it may be necessary to revise the original decomposition of the sub-processes.

''Ansgar Schwegmann and Michael Laske'' explain: "A consolidation of the models of different modeling complexes is necessary in order to obtain an integrated&nbsp;... model."<ref name="SCHWEGMANN-LASKE" /> <sup>(Chapter 5.2.4 Model consolidation) ← automatic translation from German</sup> They also list a number of aspects for which model consolidation is important:
* "Modeling teams need to drive harmonization of models during model creation to facilitate later consolidation."
* "If an object-oriented decomposition of the problem domain is carried out, it must be analyzed at an early stage whether similar structures and processes of different objects exist."
* "If a function-oriented decomposition of the problem domain is undertaken, the interfaces between the modelled areas in particular must be harmonized."
* "In general, a uniform level of detail of the models" (in each decomposition level) "should be aimed for during modeling in order to facilitate the comparability of the submodels and the precise definition of interfaces."
* "After completion of the modeling activities in the teams of the individual modeling complexes, [the] created partial models are to be integrated into an overall model."
* "In order to facilitate the traceability of the mapped processes, it makes sense to explicitly model selected business transactions that are particularly important for the company and to map them at the top level.&nbsp;... Colour coding, for example, can also be used to differentiate between associated organizational units."<ref name="SCHWEGMANN-LASKE" /> <sup>(Chapter 5.2.4 Model consolidation) ← automatic translation from German</sup>

=== Process chaining and control flow patterns ===
[[File:BPMN-Modale-Prozessverkettung AND.png|thumb|Modal chaining (''necessary'' finalization of sub-processes 1a, 1b and 1c before the start of sub-process 2) in an example using BPMN tools]]
The chaining of the sub-processes with each other and the chaining of the functions (''tasks'') in the sub-processes is modeled using Control Flow Patterns.

Material details of the chaining (What does the predecessor deliver to the successor?) are specified in the process interfaces if intended.

=== Process interfaces ===
Process interfaces are defined in order to
* Show the relationships between the sub-processes after the decomposition of business processes or
* Determine '''what''' the business processes or their sub-processes must 'pass on' to each other.
As a rule, this '''what''' and its structure is determined by the requirements in the subsequent process.

Process interfaces represent the exit from the current business process/sub-process and the entry into the subsequent business process/sub-process.

[[File:Process-flow-with-interface-to-service-process.png|thumb|A process flow with interface to a service process in EPC syntax (top) and BPMN syntax (bottom)]]
Process interfaces are therefore description elements for linking processes section by section. A process interface can
* Represent a business process model/sub-process model without the business process model referenced by it already being defined.
* Represent a business process model/sub-process model that is referenced from two/multiple superordinate or neighboring business process models.
* Represent two/multiple variants of the same business process model/sub-process model.
Process interfaces are agreed between the participants of superordinate/subordinate or neighboring business process models. They are defined and linked once and used as often as required in [[business process model|process model]]s.

Interfaces can be defined by:
* Transfer of responsibility/accountability from one business unit to another,
* Transfer of data from one IT-system to another,
* Original input (information / [[material]]s at the beginning of the business process),
* Transfer of intermediate results between sub-processes (output at the predecessor and input at the successor are usually identical) or
* Final output (the actual result / goal of the business process).

In real terms, the transferred inputs/outputs are often data or information, but any other business objects are also conceivable (material, products in their final or semi-finished state, documents such as a delivery bill). They are provided via suitable transport media (e.g. data storage in the case of data).

=== Business process management ===
See article Business process management.

In order to put improved business processes into practice, [[change management]] programs are usually required. With advances in software design, the vision of BPM models being fully executable (enabling simulations and round-trip engineering) is getting closer to reality.

==== Adaptation of process models ====
In business process management, process flows are regularly reviewed and optimized (adapted) if necessary. Regardless of whether this adaptation of process flows is triggered by [[Continual improvement process|continuous process improvement]] or by process reorganization (business process re-engineering), it entails an update of individual sub-processes or an entire business process.