Business process modeling: Difference between revisions

Revision as of 10:08, 20 March 2024

Revision as of 10:20, 20 March 2024

Line 1:

{{Short description|Activity of representing processes of an enterprise}}[[File:BPMN-AProcessWithNormalFlow.svg|alt=|thumb|400x400px|Example of business process modeling of a process with a normal flow with the [[Business Process Model and Notation]]]]

'''Business process modeling''' ('''BPM'''), mainly used in [[business process management]]; [[software development]] or [[systems engineering]], is the action of capturing and [[#Representation type and notation|representing]] [[business processes|processes]] of an enterprise (i.e. [[modeling]] them), so that the current business processes may be analyzed, applied securely and consistently, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. Alternatively, the process model can be derived directly from digital traces in IT systems (such as events' logs) using [[process mining]] tools.

''This article explains the typically '''manual''' action of creating and [[#Representation type and notation|presenting]] '''conceptual''' business process models of a company based on expert knowledge. For '''automatic''' evaluation of '''transactional''' business process models based on digital traces in IT systems see [[process mining]].''

[[File:BPMN-AProcessWithNormalFlow.svg|alt=|thumb|400x400px|Example of business process modeling of a process with a normal flow with the [[Business Process Model and Notation]]]]

'''Business process modeling''' ('''BPM'''), mainly used in [[business process management]]; [[software development]] or [[systems engineering]], is the action of capturing and [[#Representation type and notation|representing]] [[business processes|processes]] of an enterprise (i.e. [[modeling]] them), so that the current business processes may be analyzed, applied securely and consistently, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. Alternatively, the process model can be derived directly from digital traces in IT systems (such as events' logs) using [[process mining]] tools.

== Overview ==

[[File:Fife-Disciplines-Of-The-BPM.png|thumb|The five disciplines of business process management and their relationships]]

According to the ''Association of Business Process Management Professionals ABPMP'', '''business process modeling''' is one discipline of [[business process management]] that comprises the following five disciplines:<ref name="EABPM">Association of Business Process Management Professionals ABPMP (publisher): ''Guide to the Business Process Management common body of knowledge - BPM CBOK®'' in the translated and edited German edition of → European Association of Business Process Management EABPM (publisher): ''Business Process Management Common Body of Knowledge - BPM CBOK®'', 2nd version, Verlag Dr. Götz Schmidt, Gießen 2009, ISBN 978-3-921313-80-0</ref> ^{(Chapter 1.4 CBOK® structure) ← automatic translation from German}

* ''Process Modeling''

* ''Process Analysis'' (understanding the as-is processes and their alignment with the company's objectives - ''analysis of business activities'')

* ''Process Design'' (redesign - ''business process reengineering'' - or redesign of business processes - ''business process optimization'')

* ''Process Performance Measurement'' (can focus on the factors ''time'', ''cost'', ''capacity'' and ''quality'' or on the overarching view ''[[Kaizen#The seven Muda|waste]]'')

* ''Process Transformation'' (planned, structured development, technical realization and transfer to ongoing operations)

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]] / [[Input output|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-Wilhelm Scheer|August W. Scheer]]'', 2) ''[https://de.wikipedia.org/wiki/Hubert_%C3%96sterle Hubert Österle]'', 3) ''Otto K. Ferstl and Elmar J. Sinz'', 4) ''[https://de.wikipedia.org/wiki/Hermann_Gehring_(Wirtschaftswissenschaftler) Hermann Gehring]'' and 5) ''[https://de.wikipedia.org/wiki/Andreas_Gadatsch Andreas Gadatsch]'' Further details on view concepts can also be found in [https://de.wikipedia.org/wiki/Unternehmensabbildung company mapping] (German).

The term ''viewsview''s (''[[August-Wilhelm Scheer|August W. Scheer]]'', ''Otto K. Ferstl and Elmar J. Sinz'', ''[https://de.wikipedia.org/wiki/Hermann_Gehring_(Wirtschaftswissenschaftler) Hermann Gehring]'' and ''[https://de.wikipedia.org/wiki/Andreas_Gadatsch Andreas Gadatsch]'') is not used uniform in all schools of [[business informatics]] - alternative terms are ''design dimensions'' (''[https://de.wikipedia.org/wiki/Hubert_%C3%96sterle Hubert Österle]'') or ''perspectives'' (''[[Zachman Framework|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 ''[https://de.wikipedia.org/wiki/Andreas_Gadatsch 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}

Business process modeling is also a central aspect of holistic [https://de.wikipedia.org/wiki/Unternehmensabbildung company mapping] (German) - which also deals with the mapping of the [[Mission statement|corporate mission statement]], corporate policy/[[corporate governance]], [[Formal organization|organizational structure]], process organization, [[enterprise architecture|application architecture]], regulations and interest groups as well as the [[Market (economics)|market]].

[[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}

If the ''[[Businesscore processes|core process]]es'' are then organized/decomposed at the next level in [[supply chain management]] (SCM), [[Customer Relationship Management]] (CRM) and [[product lifecycle management]] (PLM), standard models of large organizations and industry associations such as the ''[[Supply chain operations reference|SCOR model]]'' can also be integrated into business process modeling.

== History ==

Techniques to model business process such as the [[flow chart]], [[functional flow block diagram]], [[control flow diagram]], [[Gantt chart]], [[PERT]] diagram, and [[IDEF]] have emerged since the beginning of the 20th century. The Gantt charts were among the first to arrive around 1899, the flow charts in the 1920s, Functional Flow Block Diagram and PERT in the 1950s, Data Flow Diagrams and IDEF in the 1970s. Among the modern methods are [[Unified Modeling Language]] and [[Business Process Model and Notation]]. Still, these represent just a fraction of the methodologies used over the years to document business processes.<ref name="TD03">Thomas Dufresne & James Martin (2003). [https://web.archive.org/web/20061220024049/http://mason.gmu.edu/~tdufresn/paper.doc "Process Modeling for E-Business"]. INFS 770 Methods for Information Systems Engineering: Knowledge Management and E-Business. Spring 2003 {{dead link|date=October 2010}}</ref> The term 'business process modeling' was coined in the 1960s in the field of [[systems engineering]] by S. Williams in his 1967 article 'Business Process Modelling Improves Administrative Control'.<ref>Williams, S. (1967) "Business Process Modeling Improves Administrative Control," In: ''Automation''. December, 1967, pp. 44 - 50.</ref> His idea was that techniques for obtaining a better understanding of physical control systems could be used in a similar way for [[business process]]es. It was not until the 1990s that the term became popular.

In the 1990s the term '[[business process|process]]' became a new productivity paradigm.<ref name="Rol95">Asbjørn Rolstadås (1995). "Business process modeling and re-engineering". in: ''Performance Management: A Business Process Benchmarking Approach''. p. 148-150.</ref> Companies were encouraged to think in ''processes'' instead of ''functions'' and ''procedures''. Process thinking looks at the chain of events in the company from purchase to supply, from order retrieval to sales, etc. The traditional modeling tools were developed to illustrate time and cost, while modern tools focus on cross-functional activities. These cross-functional activities have increased significantly in number and importance, due to the growth of complexity and dependence. New methodologies include [[business process redesign]], business process innovation, [[business process management]], [[integrated business planning]], among others, all "aiming at improving processes across the traditional functions that comprise a company".<ref name="Rol95"/>

In the field of [[software engineering]], the term 'business process modeling' opposed the common [[software process]] modeling, aiming to focus more on the state of the practice during [[software development]].<ref>Brian C. Warboys (1994). ''Software Process Technology: Third European Workshop EWSPT'94'', Villard de Lans, France, February 7–9, 1994: Proceedings. p. 252.</ref> In that time (the early 1990s) all existing and new modeling techniques to illustrate business processes were consolidated as 'business process [[modeling language]]s'{{Citation needed|date = April 2014}}. In the [[Object Oriented]] approach, it was considered to be an essential step in the specification of business application systems. Business process modeling became the base of new methodologies, for instance, those that supported [[data collection]], data flow analysis, process flow diagrams, and reporting facilities. Around 1995, the first visually oriented tools for business process modeling and implementation were being presented.

Line 49 ⟶ 46:

[[File:Influencing-factors-on-the-business-process-model.png|thumb|Influencing factors on the business process model]]

The objective of business process modelling is a - usually graphical - [[#Representation type and notation|representation]] of end-to-end processes, whereby complex facts of reality are documented by means of a uniform (systematized) representation and reduced to the substantial ([[Quality (philosophy)|qualities]]). Regulatory requirements for the documentation of processes often also play a role here (e.g. [[document control]], [[Requirements traceability|traceability]] or [[integrity]]), for example from [[quality management]], [[information security management system|information security management]] or [[data protection]].

Business process modeling typically begins with determining the environmental requirements: First, the [[goal]] of the modeling ([[#Applications of business process modeling|applications of business process modeling]]) must be determined. Business process models are now often used in a multifunctional way (see above). Second the model addressees must be determined, as the properties of the model to be created must meet their requirements. This is followed by the determination of the business processes to be modeled.

The qualities of the business process that are to be [[#Representation type and notation|represented]] in the model are specified in accordance with the goal of the modeling. As a rule, these are not only the functions constituting the process, including the [[Relations (philosophy)|relationships]] between them, but also a number of other qualities, such as [[formal organization]], [[Input/output|input]], [[Input/output|output]], [[resources]], [[information]], [[Data storage|media]], [[Database transaction|transactions]], [[Event (philosophy)|event]]s, [[State pattern|states]], [[Necessity and sufficiency|conditions]], [[Operation (mathematics)|operations]] and [[Philosophical methodology|methods]].

In detail, the objectives of business process modeling can include (compare: Association of Business Process Management Professionals (ABPMP)<ref name="EABPM"/> ^{(Chapter 3.1.2 Process characteristics and properties) ← automatic translation from German}):

Line 70 ⟶ 67:

** to avoid loss of knowledge (e.g. due to staff leaving)

** to support quality and environmental management

* definition of process [[performance indicator]]sindicators and monitoring of process performance

** to increase process speed

** to reduce cycle time

Line 107 ⟶ 104:

* [[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) ===

Within an extensive research program initiated in 1984 titled "Management in the 1990s" at [[Massachusetts Institute of Technology|MIT]], the approach of ''process re-engineering'' emerged in the early 1990s. The research program was designed to explore the impact of information technology on the way organizations would be able to survive and thrive in the competitive environment of the 1990s and beyond. In the final report, N. Venkat Venkatraman<ref>N. Venkat Venkatraman: ''IT-Induced Business Reconfiguration'' in M. S. Scott Morton (publisher): ''The Corporation of the 1990s: Information Technology and Organizational Transformation'', 1st edition, Oxford University Press 1991, ISBN 978-0-19-506358-5</ref> summarizes the result as follows: The greatest increases in productivity can be achieved when new processes are planned in parallel with information technologies.

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. … 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:

# Identifying Process for Innovation

# Identifying Change Levers

Line 128 ⟶ 125:

=== Certification of the management system according to ISO ===

[[File:ISO_Logo_(Red_square).svg|thumb|International Organization for Standardization (''ISO'' and official logo are registered trademarks)]]

With [[ISO/IEC 27001]]:2022, the standard requirements for management systems are now standardized for all major ISO standards and have a process character.

==== General standard requirements for management systems with regard to processes ====

In the [[ISO 9001|ISO/IEC 9001]], [[ISO 14001|ISO/IEC 14001]], [[ISO/IEC 27001]] standards, this is anchored in Chapter 4.4 in each case:

{| class="wikitable"

! ISO/IEC 9001:2015

Line 143 ⟶ 140:

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 9001|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 152 ⟶ 149:

* evaluate these processes and implement any changes needed for effective operation and control

* improve

In addition, clause 4.4.2 of the [[ISO 9001|ISO/IEC 9001]] lists some more

detailed requirements with regard to processes:

* maintain documented information

Line 161 ⟶ 158:

==== Specific standard requirements for management systems with regard to documented information ====

In the standards [[ISO 9001|ISO/IEC 9001]], [[ISO 14001|ISO/IEC 14001]], [[ISO/IEC 27001]] the requirements with regard to ''documented information'' are anchored in clause 7.5 (detailed in the respective standard in clauses "7.5.1. General", "7.5.2. Creating and updating" and "7.5.3. Control of documented information").

The standard requirements of ISO/IEC 9001 used here as an example ''include'' in clause "7.5.1. General"

Line 185 ⟶ 182:

=== Business process optimization ===

''Hermann J. Schmelzer and Wolfgang Sesselmann'' point out that the field of improvement of the three methods mentioned by them as examples for process optimization (control and reduction of total cycle time (TCT), [[Kaizen]] and [[Six Sigma]]) are processes: In the case of total cycle time (TCT), it is the [[business processes]] (end-to-end processes) and [[business process|sub-processes]], with Kaizen it is the [[activity|process steps]] and [[activity]] and with Six Sigma it is the [[business process|sub-processes]], [[activity|process steps]] and [[activity]].<ref name="SCHMELZER"/> ^{(Chapter 6.3.1 Total Cycle Time (TCT), KAIZEN and Six Sigma in comparison) ← automatic translation from German}

For the '''total cycle time (TCT)''', ''Hermann J. Schmelzer and Wolfgang Sesselmann'' list the following key features:<ref name="SCHMELZER"/> ^{(Chapter 6.3.2 Total Cycle Time (TCT)) ← automatic translation from German}

Line 194 ⟶ 191:

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

Looking at the '''Kaizen''' tools, there is initially no direct connection to business processes or business process modeling. Nevertheless, Kaizen and business process management can benefit from each other. «In the context of business process management, the KAIZEN objectives are derived directly from the objectives for business processes and sub-processes. This link ensures that KAIZEN measures support the 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 ===

The aim of inter-company business process modeling is to include the influences of external [[Stakeholder (corporate)|stakeholders]] in the analysis or to achieve inter-company comparability of business processes, e.g. to enable [[benchmarking]].

''Martin Kugler'' lists the following requirements for business process modeling in this context:<ref name="KUGLER">Martin Kugler: ''Supply Chain Management und Customer Relationship Management - Prozessmodellierung für Extended Enterprises'' in Jörg Becker, Martin Kugler and Michael Rosemamm (publisher): ''Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung'', 2. corrected and expanded edition, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7</ref> ^{(Chapter 14.2.1 Requirements for inter-company business process modeling) ← automatic translation from German}

* Employees from different companies must understand the business process models, which is why the degree of familiarity with the [[#Representation type and notation|modelling techniques]] (representation) is particularly important.

* Acceptance of business process modeling increases with the simplicity of the representation; it must be clear, easy to understand and as self-explanatory as possible.

* The presentation of inter-company business process models must be standardized in the various companies in order to achieve consistent comprehensibility and acceptance, especially since different representations are used within the various companies.

* An industry-neutral modelling technique ([[#Representation type and notation|representation]]) must be used, as the various companies along the value chain (supplier, manufacturer, retailer, customer) typically come from different industries.

== Topics ==

Line 211 ⟶ 208:

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

Line 218 ⟶ 215:

==== Identify business processes ====

Afterwards a company's [[business process]]esprocesses are identified and differentiated from one another by analysing the business activities (see also [[Business process management|business process analysis]]). A business process is a collection of related, structured [[Action (philosophy)|actions (activities)]] that produce a specific service or product (to serve a particular goal) for a particular customer or customer group.

The ''European Association of Business Process Management EABPM'' states: «As a first step in process design or reengineering, a common understanding of the current process and its alignment with the objectives should be established.»<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}

Line 239 ⟶ 236:

* 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 process|management]], [[Business process|core]] and [[Business process|support process]]esprocesses.

* ''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]].

Line 247 ⟶ 244:

==== 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 ''[[#Applications of business process modeling|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

Line 271 ⟶ 268:

* have a strong external impact,

* can be easily differentiated from other business processes and

* offer the greatest potential for [[Business process management|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|Example of a definition of the business process ''Customer Relationship Management'']]

Line 289 ⟶ 286:

''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]].

=== 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 ''[[#Applications of business process modeling|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).

Line 299 ⟶ 296:

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, [[#Representation type and notation|represented]] in [[value chain diagram]]sdiagrams. 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" /> ^{(Chapter 3.1 Defining process details) ← automatic translation from German} (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 (see also ''accountable'' in [[Responsibility assignment matrix|RACI]]). 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 ===

Line 312 ⟶ 309:

;''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 ''[[#Applications of business process modeling|application]]'' and the ''strategy for the long-term success of business process modeling''. The previous procedure with [[#Analysis of business activities|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

Line 321 ⟶ 318:

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

* 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

Line 333 ⟶ 330:

* 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>

Line 354 ⟶ 351:

[[File:VAC Process sales pipeline.png|thumb|Breakdown of the business process ''Process sales pipeline'' into sub-processes based on phases]]

[[August-Wilhelm Scheer|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 [[#Representation type and notation|representing]] the sequence of [[Action (Philosophy)|actions (activities)]]) and ''function'' (in the sense of a delimited ''corporate function''/[[Action (Philosophy)|action (activity) area]] that is clearly assigned to a ''corporate function owner'').

[[File:FT-Excerpt-of-company-functions.png|thumb|Function tree with a excerpt of typical company actions, ''sales pipeline'' relevant functions marked]]

For example, in [[August-Wilhelm Scheer|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 [[#Representation type and notation|representing]] the sequence of [[Action (Philosophy)|actions (activities)]]) based on its phases.

The second image shows an excerpt of typical ''functions'' (in the sense of delimited ''corporate function''/[[Action (Philosophy)|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 [[#Representation type and notation|represent]] ''business processes'', ''main processes'', ''sub-processes'' and ''elementary processes''.

;Workflow

A [[workflow]] is a [[#Representation type and notation|representation]] of a sequence of tasks, declared as work of a person, of a simple or complex mechanism, of a group of persons,<ref>[http://www.iso.org See e.g., ISO 12052:2006]</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'') ====

Line 377 ⟶ 374:

;Delimitation

The term ''functions'' is often used synonymously for a delimited ''corporate function''/[[Action (Philosophy)|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 [[Business Process Model and Notation|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 [[Milestone (project management)|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 type and notation|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) ''[https://de.wikipedia.org/wiki/Hermann_Gehring_(Wirtschaftswissenschaftler) Hermann Gehring]'' and 5) ''[https://de.wikipedia.org/wiki/Andreas_Gadatsch 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-Wilhelm Scheer|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> ^{(Chapter 1 The vision: A common language for IT and management) ← automatic translation from German} (see also [https://de.wikipedia.org/wiki/Unternehmensabbildung Company mapping (German)])

For ''[https://de.wikipedia.org/wiki/Andreas_Gadatsch 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"/> ^{(Chapter 3.2 GPM - Holistic process modelling) ← automatic translation from German} (see also [https://de.wikipedia.org/wiki/Unternehmensabbildung Company mapping (German)])

For ''Otto K. Ferstl undand Elmar J. Sinz'' in SOM ('''S'''emantic '''O'''bjekt'''m'''odell), this would be the basic information of the levels ''Business plan'' and ''Resourcen''. (see also [https://de.wikipedia.org/wiki/Unternehmensabbildung Company mapping (German)])

Master data can be, for example:

Master data can be, for example (see also section [[#Definition of functional requirements for business process modeling|Definition of functional requirements for business process modeling]]):

* 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

Line 404 ⟶ 402:

* 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 [[application software|IT-system]] that supports the execution of the business process

* the [[milestone (project management)|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 ''[[#Applications of business process modeling|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.

Line 419 ⟶ 417:

====Integration of external documents and IT-systems====

The integration of external [[document]]s and [[application software|IT-systems]] can significantly increase the added value of a business process model.

For or 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 [[Business rule|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]] system

* Integrating graphical [[#Representation type and notation|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.

Line 445 ⟶ 443:

=== 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 [[Business Process Model and Notation|Control Flow Patterns]].

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

Line 465 ⟶ 463:

Interfaces can be defined by:

* transfer of responsibility/accountability from one [[organizational structure|business unit]] to another,

* transfer of data from one [[Application software|IT-system]] to another,

* original [[Input/output|input]] ([[information]] / [[material]]s at the beginning of the business process),

* transfer of intermediate results between sub-processes ([[Input/output|output]] at the predecessor and [[Input/output|input]] at the successor are usually identical) or

* final [[Input/output|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 object]]sobjects 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|busness 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.

== Representation type and notation ==

Line 486 ⟶ 484:

=== Modelling techniques ===

There are various standards for notations; the most common are:

* [[Business Process Model and Notation]] (BPMN), proposed in 2002 by Stephen A. White, published by the Business Process Management Initiative - merged in June 2005 with [[Object Management Group]]

* [[Event-driven process chain]] (EPC), proposed in 1992 by a working group under the leadership of [[August-Wilhelm Scheer]]

* ''Value-added chain diagram'' ([https://de.wikipedia.org/wiki/Wertsch%C3%B6pfungskettendiagramm VAD]), for visualizing processes mainly at a high level of abstraction

* [[Petri net]], developed by [[Carl Adam Petri]] in 1962

Line 495 ⟶ 493:

* [[Subject-oriented business process management]] (S-BPM)

* [[Cognition enhanced Natural language Information Analysis Method]] (CogNIAM)

* [[SIPOC]] diagram, invented in the 1980s as part of the [[Total Quality Management]] movement and then adopted by [[Lean Management]] and [[Six Sigma]] practitioners

* [[Unified Modelling Language]] (UML), proposed in 1996 by [[Grady Booch]], [[Ivar Jacobson]], and [[James Rumbaugh]], continuously revised under the aegis of the [[Object Management Group|OMG]] (provides extensions for business process)

* [[IDEF|ICAM DEFinition]] ([[IDEF0]]), developed for the US Air Force in the early 1980s

* [[Formalized Administrative Notation (FAN)]], created by Pablo Iacub and Leonardo Mayo in the 1990s

* [[Harbarian process modeling]] (HPM)

* [[BPEL|Business Process Execution Language]] (BPEL), an XML-based language developed in 2002 by [[Organization for the Advancement of Structured Information Standards|OASIS]] for the description and automation of business processes

* [[Turtle diagram]] (also turtle method, turtle model, 8W method), a simple, clear and easy-to-understand graphical representation of facts about the process

Furthermore:

Line 510 ⟶ 508:

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

* [[Data-flow diagram]], a way of representing a flow of data through a process or a system

* [[Swimlane]] technique, mainly known through [[BPMN]] but also [[SIPOC]], the ''Process chain diagram'' ([https://de.wikipedia.org/wiki/Vorgangskettendiagramm PCD]) and other methods use this technique

* [https://de.wikipedia.org/wiki/ProMet ProMet], a method set for business engineering

* [[State diagram]], used to describe the behavior of systems

In addition, representation types from [[software architecture]] can also be used:

* [[Flowchart]], standardized in DIN 66001 from September 1966 and last revised in December 1983 or standardized in [[ISO 5807]] from 1985

* [[Nassi-Shneiderman diagram]] or structure diagram, proposed in 1972/73 by [[Isaac Nassi]] and [[Ben Shneiderman]], standardized in DIN 66261.

Line 568 ⟶ 566:

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

* [[XML Process Definition Language]] ([[XPDL]]),

Line 578 ⟶ 576:

=== Simulation ===

The simulation functionality of such tools allows for pre-execution "what-if" modelling (which has particular requirements for this application) and simulation. Post-execution optimization is available based on the analysis of actual as-performed metrics.<ref name="NIH07" />

* [[Use case diagram]]s created by [[Ivar Jacobson]], 1992 (integrated in [[Unified Modelling Language|UML]])

* [[Activity diagram]]sdiagrams (also adopted by UML)

== Related concepts ==

=== Business reference model ===

[[File:Government Business Reference Model.svg|thumb|360px|Example of the US Federal Government Business Reference Model<ref>FEA (2005) [https://www.archives.gov/records-mgmt/pdf/rm-profile.pdf FEA Records Management Profile, Version 1.0]. December 15, 2005.</ref>]]

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 perform 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 model]]smodels 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>

Line 590 ⟶ 588:

=== Business process integration ===

[[File:Process and data modeling.svg|thumb|320px|Example of the interaction between business process and data models<ref name="SS93"/>]]

A [[business model]], which may be considered an elaboration of a business process model, typically shows business data and business organizations as well as business processes. By showing business processes and their information flows, a business model allows business stakeholders to define, understand, and validate their business enterprise. The [[data model]] part of the business model shows how business information is stored, which is useful for developing [[software code]]. See the figure on the right for an example of the interaction between business process models and data models.<ref name="SS93">Paul R. Smith & Richard Sarfaty (1993). [http://www.osti.gov/energycitations/servlets/purl/10160331-YhIRrY/ Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools.] Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group.</ref>

Usually a business model is created after conducting an interview, which is part of the [[business analysis]] process. The interview consists of a facilitator asking a series of questions to extract information about the subject business process. The interviewer is referred to as a facilitator to emphasize that it is the participants, not the facilitator, who provide the business process information. Although the facilitator should have some knowledge of the subject business process, but this is not as important as the mastery of a pragmatic and rigorous method interviewing business experts. The method is important because for most enterprises a team of facilitators is needed to collect information across the enterprise, and the findings of all the interviewers must be compiled and integrated once completed.<ref name="SS93"/>

Line 599 ⟶ 597:

[[File:Business Process Reengineering Cycle.svg|thumb|Diagram of the business process reengineering cycle]]

[[Business process reengineering]] (BPR) aims to improve the [[Business efficiency|efficiency]] and effectiveness of the [[business process|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===

[[Change management]] programs are typically involved to put any improved business processes into practice. With advances in software design, the vision of BPM models becoming fully executable (and capable of simulations and round-trip engineering) is coming closer to reality.

See article [[business process management]].

[[Change management]] programs are typically involved to put any improved business processes into practice. With advances in software design, the vision of BPM models becoming fully executable (and capable of simulations and round-trip engineering) is coming closer to reality.

====Adaptation of process models====

In [[business process management]], process flows are regularly reviewed and, if necessary, optimized (adapted). Regardless of whether this adaptation of process flows is triggered by [[continual improvement process]] or [[business process re-engineering]], it entails updating individual sub-processes or an entire business process.

== See also ==

{{Portal|Business and economics}}

* [[Artifact-centric business process model]]

* [[Business architecture]]

* [[Business Model Canvas]]

* [[Business plan]]

* [[Business process mapping]]

* [[Business Process Model and Notation]]

* [[Capability Maturity Model Integration]]

* [[DRAKON|Drakon-chart]]