Business process modeling: Difference between revisions

Revision as of 21:43, 23 April 2024

Revision as of 15:50, 1 May 2024

Line 1:

{{Short description|Activity of representing processes of an enterprise}}
{{Multiple issues|

{{Copy edit|date=March 2024}}

{{Very long|date=March 2024}}

Line 18 ⟶ 19:

However, a completely separate consideration of the disciplines is not possible: ''Business process modeling'' always requires a ''business process analysis'' for modeling the as-is processes (see section [[#Analysis of business activities|Analysis of business activities]]) or specifications from ''process design'' for modeling the to-be processes (see sections [[#Business process re-engineering (BPR)|Business process reengineering]] and [[#Business process optimization|Business process optimization]]).

The focus of business process modeling is on the [[#Representation type and notation|representation]] of the flow of [[Action (philosophy)|actions (activities)]], according to Hermann J. Schmelzer and Wolfgang Sesselmann consisting «"of the cross-functional identification of value-adding activities that generate specific services expected by the customer and whose results have strategic significance for the company. They can extend beyond company boundaries and involve activities of customers, suppliers, or even competitors.»"<ref name="SCHMELZER">Hermann J. Schmelzer and Wolfgang Sesselmann: ''Geschäftsprozessmanagement in der Praxis'', 9th edition, Hanser, Munich 2020, ISBN 978-3-446-44625-0</ref> ^{(Chapter 2.1 Differences between processes and business processes) ← automatic translation from German}

But also other [[Quality (philosophy)|qualities]] (facts) such as [[data]] and [[business object]]s (as [[Input output|inputs]] / outputs), [[formal organization]]s and [[Actor (UML)|roles]] (responsible/accountable/consulted/informed persons, see [[Responsibility assignment matrix|RACI]]), [[resource]]s and [[application software|IT-systems]] as well as [[guideline]]s/instructions ([[Means of labor|work equipment]]), [[requirement]]s, [[Performance indicator|key figure]]s etc. can be modeled.

The more of these characteristics are incorporated into the business process modeling, the better the abstraction of the business process models reflects reality - and the more complex the business process models become. «"To reduce complexity and improve the comprehensibility and transparency of the models, the use of a view concept is recommended.»"<ref name="GADATSCH">Andreas Gadatsch: ''Management von Geschäftsprozessen / Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker'', 2nd revised and expanded edition, Vieweg, Braunschweig/Wiesbaden 2002, ISBN 978-3-528-15759-3</ref>^{(Chapter 2.4 Views of process modeling) ← automatic translation from German} There is also a brief comparison of the view concepts of five relevant German-speaking schools of [[business informatics]]: 1) August W. Scheer, 2) Hubert Österle, 3) Otto K. Ferstl and Elmar J. Sinz, 4) Hermann Gehring and 5) Andreas Gadatsch.

The term ''view''s ([[August-Wilhelm Scheer|August W. Scheer]], Otto K. Ferstl and Elmar J. Sinz, Hermann Gehring and Andreas Gadatsch) is not used uniform in all schools of business informatics - alternative terms are ''design dimensions'' (Hubert Österle) or ''perspectives'' (Zachman).

M. Rosemann, A. Schwegmann and P. Delfmann also see disadvantages in the ''concept of views'': «"It is conceivable to create information models for each perspective separately and thus partially redundantly. However, redundancies always mean increased maintenance effort and jeopardize the consistency of the models.»"<ref name="ROSEMANN">Michael Rosemann, Ansgar Schwegmann and Patrick Delfmann: ''Vorbereitung der Prozessmodellierung'' 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 978-3-540-00107-2</ref> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

According to Andreas Gadatsch, business ''process modeling'' is understood as a part of ''business process management'' alongside ''process definition'' and ''process management''.<ref name="GADATSCH" /> ^{(Chapter 1.1 Process management) ← automatic translation from German}

Line 33 ⟶ 34:

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

According to the European Association of Business Process Management EABPM, «"there are three different types of end-to-end business processes:

* Leadership processes;

* Execution processes and

* Support processes.»"<ref name="EABPM"/> ^{(Chapter 2.4 Process types) ← automatic translation from German}

These three process types can be identified in every company and are used in practice almost without exception as the top level for structuring business process models.<ref>Knowledge database: [https://der-prozessmanager.de/aktuell/wissensdatenbank/prozesslandkarte ''In 6 einfachen Schritten zur Prozesslandkarte''], DER PROZESSMANAGER GmbH (last accessed: January 25, 2024)</ref> Instead the term ''leadership processes'' the term ''[[management process]]es'' is typically used. Instead of the term ''execution processes'' the term ''[[Business processes|core process]]es'' has become widely accepted.<ref name="SCHMELZER"/> ^{(Chapter 6.2.1 Objectives and concept) ← automatic translation from German,} <ref name="BECKER-KAHN">Jörg Becker and Dieter Kahn: ''Der Prozess im Fokus'' 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> ^{(Chapter 1.3 The concept of process) ← automatic translation from German,} <ref name="BECKER-MEISE">Jörg Becker and Volker Meise: ''Strategie und Organisationsrahmen'' 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> ^{(Chapter 4.12.2 Differentiation between core and support objectives) ← automatic translation from German,} <ref name="SPECK-SCHNETT">Mario Speck and Norbert Schnetgöke: ''Sollmodellierung und Prozessoptimierung'' 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> ^{(Chapter 6.2.2 Identification and rough draft) ← automatic translation from German}

Line 103 ⟶ 104:

== Applications of business process modeling ==

Since business process modeling in itself makes no direct contribution to the financial [[Profit (economics)|success]] of a company, there is no motivation for business process modeling from the most important goal of a company, the [[For-profit corporation|intention to make a profit]]. The motivation of a company to engage in business process modeling therefore always results from the respective purpose. ''Michael Rosemann, Ansgar Schwegmann und Patrick Delfmann'' list a number of purposes as motivation for business process modeling:

* Organizational ''documentation'', with the «"objective of increasing transparency about the processes in order to increase the efficiency of communication about the processes»"<ref name="ROSEMANN"/> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German,}<ref name="GADATSCH"/> ^{(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German} including the ability to create process templates to relocate or replicate business functions or the objective to create a complete company model

* Process-oriented ''re-organization'', both in the sense of «"(revolutionary) [[business process re-engineering]] and in the sense of [[Continual improvement process|continual (evolutionary) process improvement]]»"<ref name="ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German} with the objective of a [[vulnerability assessment]]<ref name="GADATSCH"/> ^{(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}, ''process optimization'' (e.g. by controlling and reducing total cycle time<ref name="MILTENBURG-SPARLING">John Miltenburg, David Sparling: ''Managing and reducing total cycle time: models and analysis'' in Elsevier ''International Journal of Production Economics'', December 1996, Pages 89-108</ref> (TCT), through [[Kaizen]], [[Six Sigma]] etc.) or ''process standardization''

* Continuous ''process management'', as «"planning, implementation and control of processes geared towards sustainability»"<ref name="ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

* ''Certifications'' according to DIN [[ISO 9001|ISO/IEC 9001]] (or also according to [[ISO 14000|ISO/IEC 14001]], [[ISO/IEC 27001]] etc.)

* [[Benchmarking]], defined as «"comparison of company-specific structures and performance with selected internal or external references. In the context of process modeling, this can include the comparison of process models (structural benchmarking) or the comparison of process key figures»"<ref name="ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

* [[Knowledge management]] with the «"aim of increasing transparency about the company's knowledge resource in order to improve the process of identifying, acquiring, utilizing, developing and distributing knowledge»"<ref name="ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

* ''Selection'' of [[Enterprise resource planning|ERP]] software, which «"often documents its functionality in the form of (software-specific) reference models, so that it makes sense to also use a comparison of the company-specific process models with these software-specific models for software selection»"<ref name="ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German,}<<ref name="GADATSCH"/> ^{(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}

* Model-based ''customization'', i.e. «"the configuration of commercial off-the-shelf software»" often by means of «"parameterization of the software through configuration of reference models»"<ref name="ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German,}<ref name="GADATSCH"/> ^{(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}

* Software development, using the processes for «"the description of the requirements for the software to be developed at a conceptual level as part of [[requirements engineering]]»"<ref name="ROSEMANN"/>^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German,} <ref name="MOLTER">Michael Molter: ''Die Prozessorientierte Applikationslandschaft'' in August-W. Scheer, Wolfram Jost and Karl Wagner (publisher): ''Von Prozessmodellen zu lauffähigen Anwendungen'', Springer Berlin, Heidelberg, New York 2005, ISBN 3-540-23457-8</ref> ^{(Chapter 3 The path to a process-oriented application landscape) ← automatic translation from German,}<ref name="GADATSCH"/> ^{(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}

* Workflow management, for which the process models are «"the basis for the creation of instantiable workflow models»"<ref name="ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

* Simulation with the aim of «"investigating the system behavior over time»" and the «"identification of weak points that would not be revealed by a pure model view»"<ref name="ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

=== Business process re-engineering (BPR) ===

Line 120 ⟶ 121:

This approach was taken up by [[Thomas H. Davenport]]<ref name="DAVENPORT">[[Thomas H. Davenport]]: ''Process Innovation: Reengineering Work through Information Technology'', Harvard Business Press, Boston 1993, ISBN 978-0-87584-366-7</ref> ^{(Part I: A Framework For Process Innovation, Chapter: Introduction)} as well as [[Michael Martin Hammer|Michael M. Hammer]] and [[James A. Champy]]<ref name="HAMMER-CHAMPY">[[Michael Martin Hammer|Michael M. Hammer]], [[James A. Champy]]: ''Reengineering the Corporation: A Manifesto for Business Revolution'', Harper Business, New York 1993, ISBN 978-0-88730-640-2</ref> and developed it into business process re-engineering (BPR) as we understand it today, according to which business processes are fundamentally restructured in order to achieve an improvement in measurable performance indicators such as costs, quality, service and time.

Business process re-engineering has been criticized in part for starting from a "green field" and therefore not being directly implementable for established companies. ''Hermann J. Schmelzer and Wolfgang Sesselmann'' assess this as follows: «"The criticism of BPR has an academic character in many respects. …&nbsp;... Some of the points of criticism raised are justified from a practical perspective. This includes pointing out that an overly radical approach carries the risk of failure. It is particularly problematic if the organization and employees are not adequately prepared for BPR.»"<ref name="SCHMELZER" /> ^{(Chapter 6.2.1 Objectives and concept) ← automatic translation from German}

The high-level approach to BPR according to Thomas H. Davenport consists of:

Line 144 ⟶ 145:

|}

Each of these standards requires the organization to establish, implement, maintain and continually improve an appropriate management system «"including the processes needed and their interactions»".<ref name="ISO-9001">ISO 9001:2015: ''Quality management systems - Requirements'', Fifth edition 2015-09, [https://www.iso.org/standard/62085.html ISO, the International Organization for Standardization] 2015.</ref>^,<ref>ISO 14001:2015: ''Environmental management systems - Requirements with guidance for use'', Third edition 2015-09, [https://www.iso.org/standard/60857.html ISO, the International Organization for Standardization] 2015.</ref>^,<ref>ISO 27001:2022: ''Information security, cybersecurity and privacy protection Information security management systems - Requirements'', Third edition 2022-10, [https://www.iso.org/standard/27001 ISO, the International Organization for Standardization] 2022.</ref>

In the definition of the standard requirements for the ''processes needed and their interactions'', ISO/IEC 9001 is more specific in clause 4.4.1 than any other ISO standard for management systems and defines that «"the organization shall determine and apply the processes needed for»"<ref name="ISO-9001"/> an appropriate management system throughout the organization and also lists detailed requirements with regard to processes:

* determine the inputs required and the outputs expected

* determine the sequence and interaction

Line 197 ⟶ 198:

Consequently, business process modeling for TCT must support adequate documentation of barriers, barrier handling and measurement.

When examining Kaizen tools, initially, there is no direct connection to business processes or business process modeling. However, Kaizen and business process management can mutually enhance each other. In the realm of business process management, Kaizen's objectives are directly derived from the objectives for business processes and sub-processes. This linkage ensures that Kaizen measures effectively support the overarching business objectives..»"<ref name="SCHMELZER" /> ^{(Chapter 6.3.3 KAIZEN) ← automatic translation from German}

Six Sigma is designed to prevent errors and improve the [[Process capability index|process capability]] so that the proportion of process outcomes that meet the requirements is 6σ - or in other words, for every million process outcomes, only 3.4 errors occur. Hermann J. Schmelzer and Wolfgang Sesselmann explain: «"Companies often encounter considerable resistance at a level of 4σ, which makes it necessary to redesign business processes in the sense of business process re-engineering (design for Six Sigma).»"<ref name="SCHMELZER" /> ^{(Chapter 6.3.4 Six Sigma) ← automatic translation from German} For a reproducible measurement of process capability, precise knowledge of the business processes is required and business process modeling is a suitable tool for design for Six Sigma. Six Sigma therefore uses business process modeling according to [[SIPOC]] as an essential part of the methodology and business process modeling using SIPOC has established itself as a standard tool for Six Sigma.

=== Inter-company business process modeling ===

Line 215 ⟶ 216:

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"/> ^{(Chapter 4.6 The resource-based view) ← automatic translation from German} 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"/>^{(Chapter 4.7 Combination of views) ← automatic translation from German} Depending on the company's strategy, the ''process map'' will therefore be the business process models with a view to market development, with a view to resource optimization or 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" /> ^{(Chapter 4 Process analysis) ← automatic translation from German}

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"/> ^{(Chapter 6.2.2 Critical assessment of the BPR) ← automatic translation from German}

[[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> ^{(Chapter 2.4 Creating the process map) ← automatic translation from German}

[[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"/> ^{(Chapter 4.10 Defining the process structure) ← automatic translation from German}

The structuring of business processes generally begins with a distinction between management, core, and support processes.

Line 260 ⟶ 261:

* "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" /> ^{(Chapter 2.4.3 Process map) ← automatic translation from German}

=== Definition of business processes ===

Line 282 ⟶ 283:

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" /> ^{(Chapter 4.15 Influencing the design of the regulatory framework) ← automatic translation from German} 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"/> ^{(Chapter 4.11 General process identification) ← automatic translation from German}

''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"/> ^{(Chapter 4.12 Individual process identification) ← automatic translation from German}

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

Line 318 ⟶ 319:

;''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> ^{(Chapter 5.1 Intention of the ''as is'' modeling) ← automatic translation from German}

The following disadvantages speak against ''as is'' modeling:

Line 340 ⟶ 341:

;''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>

Line 360 ⟶ 361:

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 (activities)]]) 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 aan 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.

Line 438 ⟶ 439:

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" /> ^{(Chapter 5.2.4 Model consolidation) ← automatic translation from German} 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" /> ^{(Chapter 5.2.4 Model consolidation) ← automatic translation from German}

=== Process chaining and control flow patterns ===

Line 508 ⟶ 509:

Furthermore:

* ''Communication structure analysis'', proposed in 1989 by Prof. [https://de.wikipedia.org/wiki/Hermann_Krallmann ''Hermann Krallmann''] at the Systems Analysis Department of the TU Berlin.

* ''Extended Business Modelling Language'' (xBML)<ref>Cedric G. Tyler and Stephen R. Baker: ''Business Genetics: Understanding 21st Century Corporations using xBML'', John Wiley & Sons Ltd, 2007, ISBN 978-0-470-06654-6</ref> (seems to be outdated, as the founding company is no longer online<ref>{{Cite web |url=http://www.xbmlinnovations.com/Home.aspx |title=Archived copy |access-date=2024-02-19 |archive-date=2014-01-09 |archive-url=https://web.archive.org/web/20140109032735/http://www.xbmlinnovations.com/Home.aspx |url-status=bot: unknown }} accessed February 19, 2024.</ref>)

* Notation from ''OMEGA'' (object-oriented method for business process modeling and analysis, '''O'''bjektorientierte '''Me'''thode zur '''G'''eschäftsprozessmodellierung und -'''a'''nalyse in German), presented by Uta Fahrwinkel in 1995<ref>{{Webarchiv |url=http://prof-mayr.de/bpe.html |text=Prof. Dr.-Ing. R. Mayr: ''OMEGA+ Beschreibungsmethode'' |wayback=20131022212248}}, auf prof-mayr.de, zuletzt abgerufen:retrieved 5. FebruarFebruary 2024; PDF "VL4030_OMEGA+-Beschreibungsmethode.pdf" nicht mehr verfügbar</ref>

* ''Semantic object model'' ([https://de.wikipedia.org/wiki/Semantisches_Objektmodell SOM]), proposed in 1990 by ''Otto K. Ferstl and Elmar J. Sinz''

* [https://de.wikipedia.org/wiki/PICTURE-Methode PICTURE-Methode] for the documentation and modeling of business processes in public administration

Line 564 ⟶ 565:

=== Tools ===

Business process modelling tools provide business users with the ability to model their business processes, implement and execute those models, and refine the models based on as-executed data. As a result, business process modelling tools can provide transparency into business processes, as well as the centralization of corporate business process models and execution metrics.<ref name="NIH07">[http://enterprisearchitecture.nih.gov/ArchLib/AT/TA/WorkflowServicePattern.htm Workflow/Business Process Management (BPM) Service Pattern] {{webarchive|url=https://web.archive.org/web/20090113184950/http://enterprisearchitecture.nih.gov/ArchLib/AT/TA/WorkflowServicePattern.htm |date=2009-01-13 }} June 27, 2007. Accessed 29 nov 2008.</ref> Modelling tools may also enable collaborate modelling of complex processes by users working in teams, where users can share and simulate models collaboratively.<ref>Christensen, Lars Rune & Thomas Hildebrandt (2017) [https://pure.itu.dk/portal/files/83457483/Christensen_Hildebrandt_2017.pdf Modelling Cooperative Work at a Medical Department]. Proceedings of the 8th International Conference on Communities and Technologies. Troyes, France. ACM.

</ref> Business process modelling tools should not be confused with business process automation systems - both practices have modeling the process as the same initial step and the difference is that process automation gives you an ‘executable'executable diagram’diagram' and that is drastically different from traditional graphical business process modelling tools.{{citation needed|date=November 2017}}

=== Programming language tools ===

BPM suite software provides programming interfaces (web services, application program interfaces (APIs)) which allow enterprise applications to be built to leverage the BPM engine.<ref name="NIH07"/> This component is often referenced as the ''engine'' of the BPM suite.

Programming languages that are being introduced for BPM include:<ref name="bpmfaq">{{cite web |title=Business Process Modelling FAQ |url=http://www.BPModeling.com/faq/ |access-date=2008-11-02 |url-status=dead |archive-url=https://web.archive.org/web/20081109082206/http://www.bpmodeling.com/faq/ |archive-date=2008-11-09 }}</ref>

* [[Business Process Execution Language]] (BPEL),

* [[Web Services Choreography Description Language]] ([[WS-CDL]]).

Line 589 ⟶ 590:

A [[business reference model]] is a reference model, concentrating on the functional and organizational aspects of an [[Business|enterprise]], [[Tertiary sector of the economy|service organization]], or [[government agency]]. In general, a [[reference model]] is a model of something that embodies the basic goal or idea of something and can then be looked at as a reference for various purposes. A business reference model is a means to describe the business operations of an organization, independent of the organizational structure that performs them. Other types of business reference model can also depict the relationship between the business processes, business functions, and the business area's business reference model. These reference models can be constructed in layers, and offer a foundation for the analysis of service components, technology, data, and performance.

The most familiar business reference model is the Business Reference Model of the US federal government. That model is a [[function model|function-driven]] framework for describing the business operations of the federal government independent of the agencies that perform them. The Business Reference Model provides an organized, hierarchical construct for describing the day-to-day business operations of the federal government. While many models exist for describing organizations – [[organizational chart]]s, ___location maps, etc. – this model presents the business using a functionally driven approach.<ref>[https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/fea_docs/FEA_CRM_v23_Final_Oct_2007_Revised.pdf FEA Consolidated Reference Model Document] {{Webarchive|url=https://web.archive.org/web/20101011082020/http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_CRM_v23_Final_Oct_2007_Revised.pdf |date=2010-10-11 }}. Oct 2007.</ref>

=== Business process integration ===

Line 604 ⟶ 605:

[[Business process reengineering]] (BPR) aims to improve the [[Business efficiency|efficiency]] and effectiveness of the processes that exist within and across organizations. It examines business processes from a "clean slate" perspective to determine how best to construct them.

Business process re-engineering (BPR) began as a private sector technique to help organizations fundamentally rethink how they do their work. A key stimulus for re-engineering has been the development and deployment of sophisticated information systems and networks. Leading organizations use this technology to support innovative business processes, rather than refining current ways of doing work.<ref name="GAO97">[https://govinfo.library.unt.edu/npr/library/gao/bprag.pdf Business Process Reengineering Assessment Guide] {{Webarchive|url=https://web.archive.org/web/20170218131136/http://www.gao.gov/special.pubs/bprag/bprag.pdf |date=2017-02-18 }}, United States General Accounting Office, May 1997.</ref>

===Business process management===

Line 631 ⟶ 632:

<!-- This section should only contain notable publications about BPM in general, and not about specialized BPM methodologies.-->

* Aguilar-Saven, Ruth Sara. "[http://secure.com.sg/courses/ICT353/Session_Collateral/TOP_04_ART_03_ARTICLE_AGUILAR_Biz_Proc_Modelling.pdf Business process modelling: Review and framework]." ''International Journal of production economics'' 90.2 (2004): 129–149.

* {{cite journal|doi=10.1016/j.scico.2008.01.002 |title=The importance of business process modeling in software systems design |journal=Science of Computer Programming |volume=71 |pages=73–87 |year=2008 |last1=Barjis |first1=Joseph |doi-access=free }}

* Becker, Jörg, Michael Rosemann, and Christoph von Uthmann. "[https://web.archive.org/web/20130903223457/http://udoo.uni-muenster.de/downloads/publications/1717.pdf Guidelines of business process modelling]." ''Business Process Management.'' Springer Berlin Heidelberg, 2000. 30–49.

* Hommes, L.J. ''[https://repository.tudelft.nl/islandora/object/uuid%3A1d209c45-4b2a-41f2-9e94-a54b8ee76d78 The Evaluation of Business Process Modelling Techniques]''. Doctoral thesis. Technische Universiteit Delft.

Line 647 ⟶ 648:

{{Systems Engineering}}

{{|bot=InternetArchiveBot |fix-attempted=yes }}

{{DEFAULTSORT:Business Process Modelling}}

[[Category:Business process modelling| ]]