Business process modeling: Difference between revisions

Revision as of 05:32, 8 May 2024

Revision as of 13:23, 8 May 2024

Line 6:

{{Overly detailed|date=March 2024}}

}}

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

'''Business Processprocess Modelingmodeling''' ('''BPM'''), mainly used in [[business process management]]; [[software development]] , or [[systems engineering]], 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 orchestrated by business analysts, leveraging their expertise in modeling practices. Subject matter experts, equipped with specialized knowledge of the processes being modeled, often collaborate within these teams. Alternatively, process models can be directly derived from digital traces within IT systems, such as event logs, utilizing 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 Modelingmodeling

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

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

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

* Process Transformationtransformation (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}

Line 41:

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 ''core processes'' are then organized/decomposed at the next level in [[supply chain management]] (SCM), [[Customercustomer Relationshiprelationship Managementmanagement]] (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 processes 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, Functionalfunctional Flowflow Blockblock Diagramdiagram and PERT in the 1950s, and Data[[data-flow Flow Diagramsdiagram]]s 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 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 [[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 177:

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

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 sub-processes, with Kaizen it is the process steps and activity and with Six Sigma it is the sub-processes, 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}

* Identify barriers that hinder the process flow

* Eliminate barriers and substitute processes

* Measure, e the effects of barrier removal

* Comparison of the measured variables with the targets

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

Line 253:

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 (Customercustomer Relationshiprelationship Managementmanagement) describes the business processes for customer acquisition, quotation and order creation as well as support and maintenance

* PLM ([[Productproduct Lifecyclelifecycle Managementmanagement]]) describes the business processes from product portfolio planning, product planning, product development and product maintenance to product discontinuation and individual developments

* SCM ([[Supplysupply Chainchain Managementmanagement]]) describes the business processes from supplier management through purchasing and all [[Production (economics)|production stages]] to delivery to the customer, including installation and commissioning where applicable

[[File:Process-map-for-a-value-driven-company.png|thumb|Example of a '''process map''' for a value-driven company]]

However, other approaches to structuring core business processes are also common, for example from the perspective of customers, products or sales channels.

Line 264:

=== Definition of business processes ===

[[File:VAC-production-company3.png|thumb|Example of aA definition of the business process ''Productproduct development'']]

The definition of business processes often begins with the company's core processes because they

* fulfill their own market requirements,

Line 274:

* offer the greatest potential for business process optimization, both by improving [[Business performance management|process performance]] or [[productivity]] and by reducing [[costs]].

[[File:VAC CRM Sales order-processing-and-project management.png|thumb|Example of aA definition of the business process ''Customercustomer Relationshiprelationship Management''management]]

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

Line 391:

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 (Artifactsartifacts) ====

The term ''[[master data]]'' is neither defined by [[The Open Group]] ([[The Open Group Architecture Framework]], TOGAF) or [[John Zachman|John A. Zachman]] (Zachman Framework) nor any of the five relevant German-speaking schools of business informatics: 1) [[August-Wilhelm Scheer|August W. Scheer]], 2) [[Hubert Österle]], 3) Otto K. Ferstl and Elmar J. Sinz, 4) Hermann Gehring and 5) Andreas Gadatsch and is commonly used in the absence of a suitable term in the literature. It is based on the general term for [[data]] that represents basic information about operationally relevant objects and refers to basic information that is not primary information of the business process.

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

Line 434:

The direct connection of external systems can also be used to integrate current measurement results or system statuses into the processes (and, for example, to display the current operating status of the processes), to display [[Software widget|widget]]s and show output from external systems or to jump to external systems and initiate a transaction there with a preconfigured dialog.

Further connections to external systems can be used, for example, for [[Electronic Data Interchange|electronic data interchange]] (EDI).

=== Model consolidation ===

Line 461:

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

[[File:Process-flow-with-interface-to-service-process.png|thumb|Example of aA process flow with interface to a service process in EPC syntax (top) and BPMN syntax (bottom)]]

Process interfaces are therefore description elements for linking processes section by section. A process interface can

* represent a business process model/sub-process model without the business process model referenced by it already being defined.