Business process modeling: Difference between revisions

Revision as of 16:08, 10 March 2025

Latest revision as of 00:20, 29 June 2025

(12 intermediate revisions by 9 users not shown)

Line 7:

}}

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

'''Business process modeling''' ('''BPM''') is the action of capturing and 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, with subject matter experts collaborating with these teams to accurately model processes. It is primarily used in [[business process management]], [[software development]], or [[systems engineering]].

Line 15:

== 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 the five key disciplines within [[business process management|Business Process Management]] that comprises the following five disciplines:(BPM).<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} The five disciplines are:

* Process modeling : Creating visual or structured representations of business processes to better understand how they work.

* 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 of time, cost, capacity, and quality or on the overarching view of [[Kaizen#The seven Muda|waste]]).

* Process transformation (: planned, structured development, technical realization, and transfer to ongoing operations).

However, athese completelydisciplines separatecannot consideration of the disciplinesbe isconsidered notin possibleisolation: 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}

Line 27:

But also other [[Quality (philosophy)|qualities]] (facts) such as [[data]] and [[business object]]s (as 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.

TheIncorporating more of these characteristics are incorporated into the business process modeling, the betterenhances the abstractionaccuracy of theabstraction businessbut processalso models reflects reality – and the more complex the business processincreases modelsmodel becomecomplexity. "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 uniformly in all schools of business informatics – alternative terms are ''design dimensions'' (Hubert Österle) or ''perspectives'' (Zachman).

Line 38:

[[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 54:

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 presented.

== Objectives of business process modeling ==

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

The objective of business process modeling is a – usually graphical – representation of end-to-end processes, whereby complex facts of reality are documented using a uniform (systematized) representation and reduced to the substantial (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 [[Information privacy|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.

Line 96:

* [[Modularity|Modularization]] of company processes

* [[Benchmarking]] between parts of the company, partners and competitors

* Performing [[activity-based costing]] and [[simulation|simulations]]s

** to understand how the process reacts to different stress rituals or expected changes

** to evaluate the effectiveness of measures for ''business process optimization'' and compare alternatives

Line 106:

* Participation in competitions (such as [[European Foundation for Quality Management|EFQM]]).

== 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'' lists 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

Line 181:

* To ensure suitable and available at the place and time as required;

* To ensure protection (e.g. against loss of confidentiality, improper use or loss of integrity);

* To consider distribution, access, retrieval, and use;

* To consider filing/storage and preservation (including preservation of readability);

* To perform monitoring of changes (e.g. version control); and

Line 281:

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

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

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

Line 494:

* 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'' ([[:de:Wertsch%C3%B6pfungskettendiagrammWertschöpfungskettendiagramm|VAD]]), for visualizing processes mainly at a high level of abstraction

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

* Follow-up plans (e.g. in the specific form of a [[Flowchart]]), proposed in 1997 by Fischermanns and Liebelt