Business process modeling: Difference between revisions

Revision as of 21:37, 31 January 2025

Revision as of 16:08, 10 March 2025

Line 17:

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

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.

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

Line 35:

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}

Business process modeling is also a central aspect of holistic company mapping -– which also deals with the mapping of the [[Mission statement|corporate mission statement]], corporate policy/[[corporate governance]], 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]]

Line 57:

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

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 231:

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

Line 279:

The scope of a business process should be selected in such a way that it contains a manageable number of sub-processes, while at the same time keeping the total number of business processes within reasonable limits. Five to eight business processes per business unit usually cover the performance range of a company.

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

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

Line 285:

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

Line 297:

=== Further structuring of business processes ===

[[File:VAC-production-company4.png|thumb|Example of the decomposition of a business process into sub-processes -– supplemented by milestones, business units, data objects and IT-systems]]

The rough structure of the business processes created so far will now be decomposed -– by breaking it down into sub-processes that have their own attributes but also contribute to achieving the goal of the business process. This decomposition should be significantly influenced by the ''application'' and ''strategy for the long-term success of business process modeling'' and should be continued as long as the tailoring of the sub-processes defined this way contributes to the implementation of the ''purpose'' and ''strategy''.

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

Line 304:

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

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

=== Assigning the process responsibility ===

Line 347:

They also list five basic principles that have proven their worth in the creation of ''to be'' models:

* Parallel processing of sub-processes and individual activities is preferable to sequential processing -– it contains the greater potential for optimization.

* The development of a sub-process should be carried out as consistently as possible by one person or group -– this allows the best model quality to be achieved.

* Self-monitoring should be made possible for individual sub-processes and individual activities during processing -– this reduces quality assurance costs.

* If not otherwise possible, at least one internal customer/user should be defined for each process -– this strengthens customer awareness and improves the assessability of process performance.

* Learning effects that arise during the introduction of the target processes should be taken into account -– this strengthens the employees' awareness of value creation.

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

Line 398:

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

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

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

Line 428:

For example, direct access to objects in a [[knowledge database]] or documents in a [[Business rule|rule framework]] can significantly increase the benefits of the business process model in everyday life and thus the acceptance of business process modeling. All IT-systems involved can exploit their specific advantages and cross-fertilize each other (e.g. link to each other or standardize the filing structure):

* short response times of the knowledge database; characterized by a relatively high number of auditors, very fast adaptation of content, and low requirements for the publication of content -– e.g. realized with a [[wiki]]

* Legally compliant documents of the rule framework; characterized by a very small number of specially trained auditors, validated adaptation of content, and high requirements for the release of content -– e.g. implemented with a [[document management system]]

* Integrating graphical representation of processes by a BPM system; characterized by a medium number of auditors, moderately fast adaptation of content, and modest requirements for the release of content

Line 492:

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

Line 568:

=== 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 diagram' and that is drastically different from traditional graphical business process modelling tools.{{citation needed|date=November 2017}}

=== Programming language tools ===

Line 642:

* Jan Recker (2005). [http://www.bptrends.com/publicationfiles/05-06-ART-ProcessModeling21stCent-Recker1.pdf "Process Modelling in the 21st Century"]. In: BP Trends, May 2005.

* Ryan K. L. Ko, Stephen S. G. Lee, Eng Wah Lee (2009) [https://wayback.archive-it.org/all/20120917072604/http://ryanko.files.wordpress.com/2008/03/bpm-journal-koleelee-bpms-survey.pdf ''Business Process Management (BPM) Standards: A Survey'']. In: Business Process Management Journal, Emerald Group Publishing Limited. Volume 15 Issue 5. ISSN 1463-7154.

* [[Jan Vanthienen]], S. Goedertier and R. Haesen (2007). [https://lirias.kuleuven.be/bitstream/123456789/162944/1/KBI_0728.pdf "EM-BrA2CE v0.1: A vocabulary and execution model for declarative business process modelling"]. DTEW -– KBI_0728.

== External links ==