Business process modeling: Difference between revisions

Revision as of 02:44, 23 June 2025

Latest revision as of 00:20, 29 June 2025

(One intermediate revision by one other user not shown)

Line 1:

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

{{Multiple issues|
{{Copy edit|date=March 2024}}

{{Very long|date=March 2024}}

{{Technical|date=March 2024}}

{{Overly detailed|date=March 2024}}
}}

[[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 [[Businessbusiness 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.

BusinessBPM analystsis typically performperformed BPM,by collaboratingbusiness analysts, with subject matter experts collaborating with these teams to accurately model processes. It's is primarily used in [[business process management]], [[software development]], andor [[systems engineering]].

Alternatively, process models can be directly modeled from IT systems, likesuch as event logs.

== Overview ==

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

TheAccording to the Association of Business Process Management Professionals (ABPMP) identifies, business process modeling asis one of the five key disciplines within [[Businessbusiness process management|Business Process Management]] (BPM) disciplines.<ref name="EABPM4EABPM">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 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, these disciplines cannot be considered in isolation: 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}

* Process modeling: Creating visual or structured representations of business processes for better understanding.

* Process analysis: understanding current processes and their alignment with company objectives—analyzing business activities.

* Process design: redesign, business process reengineering, or business process optimization.

* Process performance measurement focuses on time, cost, capacity, and quality, or on minimizing [[Kaizen#The seven Muda|waste]].

* Process transformation: planned development, technical implementation, and operational transfer.

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.

However, these disciplines are interconnected: Business process modeling requires ''business process analysis'' for as-is processes (see [[Business process modeling#Analysis of business activities|Analysis of business activities]]) and ''process design'' specifications for to-be processes (see [[Business process modeling#Business process re-engineering (BPR)|Business process reengineering]] and [[Business process modeling#Business process optimization|Business process optimization]]).

Incorporating more of these characteristics into business process modeling enhances the accuracy of abstraction but also increases model complexity. "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 focus of business process modeling is on the [[Business process modeling#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="SCHMELZER4">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}

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

But also other [[Quality (philosophy)|qualities]] (facts) such as [[data]] and [[Business object|business objects]] (as inputs/outputs, [[Formal organization|formal organizations]] and [[Actor (UML)|roles]] (responsible/accountable/consulted/informed persons, see [[Responsibility assignment matrix|RACI]]), [[Resource|resources]] and [[Application software|IT-systems]] as well as [[Guideline|guidelines]]/instructions ([[Means of labor|work equipment]]), [[Requirement|requirements]], [[Performance indicator|key figures]] etc. can be modeled.

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}

Incorporating more of these characteristics into business process modeling enhances the accuracy of abstraction but also increases model complexity. "To reduce complexity and improve the comprehensibility and transparency of the models, the use of a view concept is recommended."<ref name="GADATSCH4">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.

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}

The term views ([[August-Wilhelm Scheer|August W. Scheer]], Otto K. Ferstl and Elmar J. Sinz, Hermann Gehring and Andreas Gadatsch) isn't uniformly used in business informatics; alternatives include ''design dimensions'' (Hubert Österle) and ''perspectives'' (Zachman).

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

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="ROSEMANN4">Michael Rosemann, Ansgar Schwegmann and Patrick Delfmann: ''Vorbereitung der Prozessmodellierung'' in Jörg Becker, Martin Kugler and Michael Rosemamm (publisher): ''Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung'', 2nd corrected and expanded edition, Springer, Berlin/Heidelberg/New York 2002, ISBN 978-3-540-00107-2</ref> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

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

Business process modeling is central to holistic company mapping, which also maps the [[Mission statement|corporate mission]], corporate policy and [[corporate governance]], organizational structure, process organization, [[Enterprise architecture|application architecture]], regulations, interest groups, and the [[Market (economics)|market]].

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

TheAccording to the European Association of Business Process Management (EABPM), identifiesthere are three different types of end-to-end business processes:

* Leadership processes;

* Execution processes and

* Support processes.<ref name="EABPM4EABPM" /> ^{(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 ''[[Managementmanagement process|management processes]]es'' is typically used. Instead of the term ''execution processes'' the term ''[[Business processes|core processesprocess]]es'' has become widely accepted.<ref name="SCHMELZER4SCHMELZER" /> ^{(Chapter 6.2.1 Objectives and concept) ← automatic translation from German,}<ref name="BECKER-KAHN4KAHN">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-MEISE4MEISE">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-SCHNETT4SCHNETT">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), [[customer relationship management]] (CRM), and [[product lifecycle management]] (PLM), standard models likeof 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|business processes]], such as the [[Flowflow chart|flow charts]], [[Functionalfunctional flow block diagram|functional flow block diagrams]], [[Controlcontrol flow diagram|control flow diagrams]], [[Gantt chart|Gantt charts]], [[PERT]] diagramsdiagram, and [[IDEF]], have emerged insince the beginning of the 20th century. The Gantt charts appearedwere among the first to arrive around 1899, the flow charts in the 1920s, functional flow block diagramsdiagram and PERT in the 1950s, and [[Datadata-flow diagram|data-flow diagrams]]s and IDEF in the 1970s. ModernAmong methodsthe includemodern themethods are [[Unified Modeling Language]] and [[Business Process Model and Notation]]. TheseStill, these represent onlyjust a fraction of the methodologies used over the years to document business processes.<ref name="TD034TD03">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> WilliamsHis suggestedidea was applyingthat techniques for obtaining a better understanding of physical control systems tocould businessbe processes.used Thein terma didn'tsimilar becomeway popularfor [[business process]]es. It was not until the 1990s that the term became popular.

In the 1990s, the term ''[[Businessbusiness process|process]]'' became a new productivity paradigm.<ref name="Rol954Rol95">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="Rol954Rol95" />

In the field of [[software engineering]], the term ''business process modeling'' contrastsopposed the withcommon [[software process]] modeling, focusingaiming to focus more on the state of the practice during [[software development]] practices.<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> EarlyIn that time (the early 1990s) all existing and new modeling techniques illustratingto illustrate business processes were consolidated as 'business process [[Modelingmodeling language|modeling languages]]s'.{{Citation needed|date = April 2014}}. TheIn the [[Object Oriented]] approach, it was considered itto be an essential forstep in the specification specifyingof business application systems. Business process modeling underpinnedbecame the base of new methodologies, for instance, those that supportingsupported [[data collection]], data flow analysis, process flow diagrams, and reporting facilities. Around 1995, the first visualvisually oriented tools for business process modeling and implementation toolswere appearedpresented.

== Objectives ==

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

Business process modeling aims to graphically represent end-to-end processes, documenting complex realities using a uniform system. This often involves meeting regulatory requirements for process documentation (e.g., [[document control]], [[Requirements traceability|traceability]], [[integrity]]), such as those from [[quality management]], [[Information security management system|information security management]], or [[Information privacy|data protection]].

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 starts by determining environmental requirements: First, define the modeling [[goal]] ([[Business process modeling#Applications of business process modeling|applications of business process modeling]]). Business process models are now often used multifunctionally (see above). Second, identify the intended model users, as the model's properties must meet their needs. Finally, determine which business processes to model.

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 modeled business process qualities depend on the modeling goal. Typically, these include not only the process functions and their [[Relations (philosophy)|relationships]], but also formal organization, inputs, outputs, [[resources]], [[information]], [[Data storage|media]], [[Database transaction|transactions]], [[Event (philosophy)|events]], [[State pattern|states]], [[Necessity and sufficiency|conditions]], [[Operation (mathematics)|operations]], and [[Philosophical methodology|methods]].

The qualities of the business process that are to be 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, [[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]].

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

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

* Company business process documentation

* Documentation of the company's business processes

** to gain knowledge of the business processes

** Toto map business unitsunit(s) towith the applicable regulations

** Transferto transfer business processes to other locations

** Determineto determine the requirements of new business activities.

** to provide an external framework for the set of rules infrom procedures and work instructions

** to meet the requirements of business partnerpartners or association requirementsassociations (e.g., certifications)

** to gain competitive advantages over competitors (e.g., in tenders)

** Toto comply with legal regulations (e.g., for criticaloperators infrastructureof operatorscritical infrastructures, banks, or armsproducers of manufacturersarmaments)

** Toto check the fulfillment of standards and compliance. requirements

** Toto create athe basis for communication and discussion

** to train or familiarize employees

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

** Toto support quality and environmental management

* ProcessDefinition of process performance indicators: definition and monitoring. of process performance

** to increase process speed

** to reduce cycle time

** to increase quality

** Reduceto reduce costs, includingsuch as labor, materials, scrap, andor capital. costs

* PreparingPreparation/Implementation andof implementinga ''business process optimization'', (which usually startingbegins with aan analysis of the current-situation analysissituation)

** Toto support analyzingthe analysis of the current situation

** to develop alternative processes

** to introduce new organizational structures

** to outsource company tasks

** to redesign, streamline, or improve company processes (e.g., usingwith the help of the [[Capability Maturity Model|CMM]])

* PreparingPreparation of an [[information technology]] project

** to support a ''software evaluation'' and/''software selection''

** to customizesupport the customizing of [[commercial off-the-shelf]] software

** Introduceto introduce automation or IT support usingwith a [[workflow management]] system.

* InterfacesDefinition andof service-levelinterfaces agreementsand ([[Service-level agreement|SLAs]])

* [[Modularity|Modularization]] of company processes

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

* Performing [[activity-based costing]] and [[Simulation|simulationssimulation]]s

** Toto understand how the process reacts to different stressorsstress rituals or anticipatedexpected changes

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

* Finding the [[best practice]]

* Accompanying organizational changes

** such as the sale or partial sale

** such as acquiringthe oracquisition integratingand integration of companies or parts of companies

** such as the introduction or change of IT systemsystems or organizational structure changes.structures

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

== Applications ==

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

* OrganizationalProcess-oriented ''documentationre-organization'', withboth in the "objectivesense of increasing"(revolutionary) transparency[[business aboutprocess there-engineering]] processesand in order to increase the efficiencysense of communication[[Continual aboutimprovement theprocess|continual (evolutionary) process processesimprovement]]"<ref name="ROSEMANN4ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German,} with the objective of a [[vulnerability assessment]]<ref name="GADATSCH4GADATSCH" /> ^{(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}, ''process includingoptimization'' the(e.g. abilityby tocontrolling createand processreducing templatestotal tocycle relocatetime<ref orname="MILTENBURG-SPARLING">John replicateMiltenburg, businessDavid functionsSparling: or''Managing theand objectivereducing tototal createcycle atime: completemodels companyand modelanalysis'' in Elsevier ''International Journal of Production Economics'', December 1996, Pages 89-108</ref> (TCT), through [[Kaizen]], [[Six Sigma]] etc.) or ''process standardization''

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

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

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

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

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

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

* [[BenchmarkingKnowledge management]], definedwith asthe "comparisonaim of company-specificincreasing structurestransparency andabout performancethe withcompany's selectedknowledge internalresource orin externalorder references.to Inimprove the contextprocess of processidentifying, modelingacquiring, thisutilizing, candeveloping include the comparison of process models (structural benchmarking) or the comparison of processand keydistributing figuresknowledge"<ref name="ROSEMANN4ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

* ''Selection'' of [[KnowledgeEnterprise managementresource planning|ERP]] withsoftware, thewhich "aimoften ofdocuments increasingits transparencyfunctionality aboutin the company'sform knowledgeof resource(software-specific) inreference models, so that it makes ordersense to improvealso use a comparison of the company-specific process ofmodels identifying,with acquiring,these utilizing,software-specific developingmodels andfor distributingsoftware knowledgeselection"<ref name="ROSEMANN4ROSEMANN" /> ^{(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 ''Selectioncustomization'' of [[Enterprise resource planning|ERP]] software, whichi.e. "oftenthe documentsconfiguration itsof functionality incommercial off-the-shelf form of (software-specific)" referenceoften models,by someans thatof it makes sense to also use a comparison"parameterization of the company-specificsoftware processthrough modelsconfiguration withof these software-specificreference models for software selection"<ref name="ROSEMANN4ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German,} <<ref name="GADATSCH4GADATSCH" /> ^{(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}

* Model-basedSoftware ''customization''development, i.e.using the processes for "the configurationdescription of commercialthe requirements for off-the-shelf software" oftento bybe meansdeveloped ofat "parameterizationa ofconceptual thelevel softwareas through configurationpart of reference[[requirements modelsengineering]]"<ref name="ROSEMANN4ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German,} <ref name="GADATSCH4MOLTER">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}

* 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="ROSEMANN4" />^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German,} <ref name="MOLTER4">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="GADATSCH4" /> ^{(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}

* WorkflowSimulation management,with forthe whichaim of "investigating the processsystem modelsbehavior areover time"the basis forand the creation"identification of instantiableweak points that would not be revealed by a pure workflowmodel modelsview"<ref name="ROSEMANN4ROSEMANN" /> ^{(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="ROSEMANN4" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

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

[[MassachusettsWithin Institutean ofextensive Technology|MIT]]'sresearch program initiated in 1984 titled "Management in the 1990s" researchat program[[Massachusetts (1984)Institute yieldedof Technology|MIT]], the approach of ''process re-engineering'' approachemerged in the early 1990s. The research program exploredwas informationdesigned technology'sto explore the impact of information technology on organizationalthe survivalway organizations would be able to survive and successthrive 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> summarizedsummarizes the finalresult reportas follows: The greatest increases in productivity can be achieved when new processes are planned in parallel with information technologies.

[[Thomas H. Davenport]]<ref name="DAVENPORT4">[[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)}, [[Michael Martin Hammer|Michael M. Hammer]], and [[James A. Champy]]<ref name="HAMMER-CHAMPY4">[[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> developed this approach into business process re-engineering (BPR). BPR fundamentally restructures business processes to improve measurable performance indicators like costs, quality, service, and time.

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

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

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

Thomas H. Davenport's high-level approach to BPR consists of:

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

# Identifying Process for Innovation

# Identifying Change Levers

Line 138 ⟶ 136:

=== 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, standardizesthe standard requirements for management systemsystems requirementsare acrossnow standardized for all major ISO standards, establishingand have a process-oriented approachcharacter.

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

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

{| class="wikitable"

! ISO/IEC 9001:2015

Clause 4.4 Quality management system and its processes

!| ISO/IEC 14001:2015

Clause 4.4. Environmental management systems

!| ISO/IEC 27001:2022

Clause 4.4 Information security management system

|}

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-90014">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>

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

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

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

* Determine required inputs and expected outputs.

* Determine the inputs required and the outputs expected

* Determine the sequence and interaction

* Define criteria and methodsapply forthe effective operationcriteria and control,methods (including monitoring, measurement, and related performance indicators.) for effective operation and control

* Determine the resources needed

* Assign the responsibilities and authorities

* Address the risks and opportunities

* Evaluate these processes and implement needed processany changes needed for effective operation and control.

* Improve

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

Clause 4.4.2 of ISO/IEC 9001 lists additional items. detailed requirements with regard to processes:

* Maintain documented information

* Retain documented information for correct implementation

DocumentedThe informationstandard requirements for ISO''documented managementinformation'' systemsare also applyrelevant tofor business process modelingmodelling as part of an ISO management system.

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

ISO/IEC 9001, ISO/IEC 14001, and ISO/IEC 27001 anchor ''documented information'' requirements in clause 7.5 (detailed in clauses "7.5.1. General," "7.5.2. Creating and updating," and "7.5.3. Control of documented information").

In the standards ISO/IEC 9001, 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").

ISO/IEC 9001's standard requirements, exemplified in clause "7.5.1. General", ''include''

* Documented information meeting standard requirements.

* Include documented information on the management system's effectiveness.

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

* Documented information by the standard requirements; and

* Documented information on the effectiveness of the management system must be included;

''Demand'' in clause "7.5.2. Creating and updating"

* Labelling and description (e.g. with title, date, author or reference number);

* Suitable format (e.g. language, software version, graphics) and medium (e.g. paper, electronic); and

* Labelling and description (e.g., title, date, author, or reference number).

* Suitable format and medium.

* Review and approval

And ''require'' in clause "7.5.3. Control of documented information"

* 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 ensure availability when and where needed.

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

* To ensure protection against loss of confidentiality, improper use, or data loss.

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

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

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

* Consider filing, storage, and preservation, including readability.

* To consider storage and disposition of further whereabouts.

* To monitor changes (e.g., version control).

* Consider further storage and disposition.

Based on the standard requirements,

* To determine and continuously improve the ''required processes and their interactions''

* To determine and improvemaintain ''requiredthe processescontent andof theirthe interactions''documented information'' deemed necessary and

* To determineensure the necessarysecure handling of ''documented information'' and(protection, maintainaccess, itsmonitoring, and contentmaintenance)

Preparing for ISO certification of a management system is a very good opportunity to establish or promote business process modelling in the organisation.

* To ensure secure handling of ''documented information'' (protection, access, monitoring, and maintenance)

ISO certification provides a good opportunity to establish or improve business process modelling.

=== 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 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="SCHMELZER4SCHMELZER" /> ^{(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="SCHMELZER4" /> ^{(Chapter 6.3.2 Total Cycle Time (TCT)) ← 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 process flow barriers.

* Identify barriers that hinder the process flow

* Eliminate barriers and substitute processes

* Measure the effects of barrier removal

* Comparison of the measured andvariables targetwith variablesthe targets

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

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

Business process modeling for TCT must document barriers, their handling, and measurement.

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.

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="SCHMELZER4" /> ^{(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="SCHMELZER4" /> ^{(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 thesethe following requirements for business process modeling in this context:<ref name="KUGLER4KUGLER">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 comprehend business process models, highlighting the critical importance of familiarity with modeling techniques. Acceptance of business process modeling is bolstered by the simplicity of representation. Models should be clear, easy to understand, and as self-explanatory as possible. Standardization of the presentation of inter-company business process models across different companies is essential to ensure consistent comprehensibility and acceptance, particularly given the varied representations used within different organizations. It is imperative to employ an industry-neutral modeling technique to accommodate the diverse backgrounds of companies along the value chain (supplier, manufacturer, retailer, customer), which typically span different industries.

* Employees from different companies need to understand business process models, highlighting the importance of familiarity with modeling techniques. Simple models improve acceptance. Models should be clear, easy to understand, and self-explanatory. Standardizing inter-company business process models ensures consistent comprehensibility and acceptance, especially given varied organizational representations. Using an industry-neutral modeling technique accommodates diverse company backgrounds across the value chain (supplier, manufacturer, retailer, customer), which typically span different industries.

== Topics ==

=== Analysis of business activities ===

==== Define framework conditions ====

AnalyzingThe analysis of business activities determines and defines the framework conditions for successful business process modeling. This is where the company's startingshould point.start,

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

This ''strategy for the long-term success of business process modeling'' can be characterized by the market-oriented view and/or the resource-based view. ''Jörg Becker and Volker Meise'' explain: "Whereas in the market view, the industry and the behavior of competitors directly determine a company's strategy, the resource-oriented approach takes an internal view by analyzing the strengths and weaknesses of the company and deriving the direction of development of the strategy from this."<ref name="BECKER-MEISE"/> ^{(Chapter 4.6 The resource-based view) ← automatic translation from German} And further: "The alternative character initially formulated in the literature between the market-based and resource-based view has now given way to a differentiated perspective. The core competence approach is seen as an important contribution to the explanation of success potential, which is used alongside the existing, market-oriented approaches."<ref name="BECKER-MEISE"/>^{(Chapter 4.7 Combination of views) ← automatic translation from German} Depending on the company's strategy, the ''process map'' will therefore be the business process models with a view to market development and to resource optimization in a balanced manner.

==== Identify business processes ====

* Define relevant business process modeling ''applications'' based on the [[business model]] and its [[value chain]] position.

Following the identification phase, a company's business processes are distinguished from one another through an analysis of their respective business activities (refer also to business process analysis). A business process constitutes a set of interconnected, organized actions (activities) geared towards delivering a specific service or product (to fulfill a specific goal) for a particular customer or customer group.

* Derive a ''strategy'' for long-term business process modeling success from the [[business strategy]] and develop a business process model structuring approach. Relevant ''purposes'' and ''strategy'' directly influence the [[process map]].

According to the European Association of Business Process Management (EABPM), establishing a common understanding of the current process and its alignment with the objectives serves as an initial step in process design or reengineering."<ref name="EABPM" /> ^{(Chapter 4 Process analysis) ← automatic translation from German}

This ''strategy for the long-term success of business process modeling'' can be characterized by the market-oriented view and/or the resource-based view. ''Jörg Becker and Volker Meise'' explain: "Whereas in the market view, the industry and the behavior of competitors directly determine a company's strategy, the resource-oriented approach takes an internal view by analyzing the strengths and weaknesses of the company and deriving the direction of development of the strategy from this."<ref name="BECKER-MEISE4" /> ^{(Chapter 4.6 The resource-based view) ← automatic translation from German} And further: "The alternative character initially formulated in the literature between the market-based and resource-based view has now given way to a differentiated perspective. The core competence approach is seen as an important contribution to the explanation of success potential, which is used alongside the existing, market-oriented approaches."<ref name="BECKER-MEISE4" />^{(Chapter 4.7 Combination of views) ← automatic translation from German} Depending on the company's strategy, the ''process map'' will therefore be the business process models with a view to market development and to resource optimization in a balanced manner.

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.

==== Identify business processes ====

Following identification, a company distinguishes its business processes by analyzing their activities (see also business process analysis). A business process is a set of interconnected actions delivering a specific service or product to a customer or customer group.

According to the European Association of Business Process Management (EABPM), establishing a common understanding of the current process and its alignment with the objectives serves as an initial step in process design or reengineering."<ref name="EABPM4" /> ^{(Chapter 4 Process analysis) ← automatic translation from German}

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

Analyzing current processes is frequently criticised in the literature, especially by business process re-engineering (BPR) proponents, who suggest immediately defining the target state.

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

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

==== Structure business processes – building a process map ====

''Timo Füermann'' explains: "Once the business processes have been identified and named, they are now compiled in an overview. Such overviews are referred to as process maps."<ref name="FUEERMANN4FUEERMANN">Timo Füermann: ''Prozessmanagement: Kompaktes Wissen, Konkrete Umsetzung, Praktische Arbeitshilfen'', Hanser, München 2014, ISBN 978-3-446-43858-3</ref> ^{(Chapter 2.4 Creating the process map) ← automatic translation from German}

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

''Jörg Becker and Volker Meise'' list these activities for structuring business processes:

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

''Jörg Becker and Volker Meise'' provide the following list of activities for structuring business processes:

* Enumeration of the main processes,

* Definition of the process boundaries,

* Determining each process'sthe strategic relevance of each process,

* Analysis of processthe need for improvement needsof a process and

* Determining the political and cultural significance of the process<ref name="BECKER-MEISE4MEISE" /> ^{(Chapter 4.10 Defining the process structure) ← automatic translation from German}

Business processThe structuring typicallyof business processes generally begins bywith a distinguishingdistinction between management, core, and support processes.

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

* ''Management processes'' govern company operations. Typical processes include corporate governance and [[strategic management]], defining corporate objectives and monitoring their achievement.

* ''CoreSupport processes'' formprovide and manage operational resources. They support the [[core business]] and createmanagement processes by ensuring the primarysmooth valuerunning streamof business operations. Typical operational processesExamples include [[purchasingaccounting]], [[manufacturing]], [[marketingrecruitment]], and [[salestechnical support]], generating direct customer benefits.

* ''Support processes'' manage operational resources, ensuring smooth business operations. They support core and management processes. Examples include [[accounting]], [[recruitment]], and [[technical support]].

[[File:VAC-production-company.png|thumb|Example of a '''process map''' for a resource-driven company]]

==== Structure core processes based on the strategy for the long-term success of business process modeling ====

CoreAs the ''core business processes'' typicallyclearly comprisemake up the mostmajority of a company's identified business processes, soit furtherhas subdivision isbecome common practice to subdivide the core processes once again. ApproachesThere varyare bydifferent companyapproaches to this depending on the type of company and business activity,. These approaches are significantly influenced by the defined ''application'' of business process modeling and the ''application''strategy andfor the long-term success strategyof 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.).

WithoutIn a differentiated view without a clear focus on the market view or the resource focusview, 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

* CRMPLM (customer[[product relationshiplifecycle management]]) describes the business processes forfrom acquiringproduct customersportfolio planning, creatingproduct quotationsplanning, andproduct orders,development and providingproduct supportmaintenance to product discontinuation and maintenance.individual developments

* PLM ([[product lifecycle management]]) describes the business processes involved in product portfolio planning, planning, development, maintenance, discontinuation, and individual improvements.

* 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

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

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

* "Customers" describes the business processes that can be assigned to specific customer groups (e.g. private customer, business customer, investor, institutional customer)

* "CustomersProducts" describedescribes the business processes assignedthat toare product-specific customer groups (e.g., privatecurrent account, businesssecurities account, investorloan, institutional customersissue).

* "ProductsSales channels" describesdescribe product-specificthe business processes that are typical for the type of customer acquisition and support (e.g., currentdirect accountsales, securities account,partner loansales, issueonline).

The result of structuring a company's business processes is the ''process map'' (shown, for example, as a [[value chain diagram]]). ''Hermann J. Schmelzer and Wolfgang Sesselmann'' add: "There are connections and dependencies between the business processes. They are based on the transfer of services and information. It is important to know these interrelationships in order to understand, manage, and control the business processes."<ref name="SCHMELZER" /> ^{(Chapter 2.4.3 Process map) ← automatic translation from German}

* "Sales channels" describe typical customer acquisition and support processes (e.g., direct sales, partner sales, online).

The result of structuring a company's business processes is the ''process map'' (shown, for example, as a [[value chain diagram]]). ''Hermann J. Schmelzer and Wolfgang Sesselmann'' add: "There are connections and dependencies between the business processes. They are based on the transfer of services and information. It is important to know these interrelationships in order to understand, manage, and control the business processes."<ref name="SCHMELZER4" /> ^{(Chapter 2.4.3 Process map) ← automatic translation from German}

=== Definition of business processes ===

[[File:VAC-production-company3.png|thumb|A definition of product development]]

The definition of business processes often startsbegins with athe company's core processes because they

* Fulfill their own market requirements,

* Operate largely autonomously/independently fromand independently of other business areas. and

* Contribute to the [[Contributioncontribution margin|business success]] of the company,

For the company

* Have a strong external impact,

* EasilyCan distinguishedbe easily differentiated from other business processes. and

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

[[File:VAC_CRM_Sales_orderVAC CRM Sales order-processing-and-project_managementproject management.png|thumb|A definition of customer relationship management]]

AThe scope of a business process should encompassbe selected in such a way that it contains a manageable number of subprocessessub-processes, while at the same time keeping the total number of business processes within reasonable limits. Five to eight business processes per business unit typicallyusually cover the performance range of a sufficecompany.

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

The definition of a business process includes: theWhat desiredresult outcome,should thebe necessaryachieved on completion? What activities, andare thenecessary to achieve this? Which objects toshould be processed (orders, raw materials, purchases, products, etc.)..)?

CorporateDepending culture—whetheron the prevailing corporate culture, which may either be more inclined towards embracing change or resistantprotective toof it—significantlythe impactsstatus quo and the effectiveness of communication, defining business processes. Thecan prove to be either easestraightforward or difficultychallenging. dependsThis hinges on the willingness of key stakeholders within the organization, likesuch as department heads, supportingto lend their support to the effortendeavor. EffectiveWithin this context, effective communication isplays a pivotal crucialrole.

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-MEISE4MEISE" /> ^{(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]]

[[File:VAC PLM with SCRUM.png|thumb|Value chain diagram with exemplary representation of "product life cycle management" with SCRUM]]

==== General process identification and individual process identification ====

''Jörg Becker and Volker Meise'' mention two approaches (''general process identification'' and ''individual process identification'') and state the following about general process identification: "In the general process definition, it is assumed that basic, generally valid processes exist that are the same in all companies." It goes on to say: "Detailed reference models can also be used for general process identification. They describe industry- or application system-specific processes of an organization that still need to be adapted to the individual case, but are already coordinated in their structure."<ref name="BECKER-MEISE4MEISE" /> ^{(Chapter 4.11 General process identification) ← automatic translation from German}

''Jörg Becker and Volker Meise'' state the following about individual process identification: "In individual or singular process identification, it is assumed that the processes in each company are different according to customer needs and the competitive situation and can be identified inductively based on the individual problem situation."<ref name="BECKER-MEISE4MEISE" /> ^{(Chapter 4.12 Individual process identification) ← automatic translation from German}

DefiningThe result of the definition of the business processes is usually yields 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' structurecreated so far will now be decomposed into– subprocesses.by Thesebreaking it down into sub-processes subprocessesthat have their own attributes but also contribute to achieving the goal of the business process goal. This decomposition should reflectbe significantly influenced by the ''application'' and ''strategy for the long-term success of business process modeling ''strategy'', continuingand should be continued as long as subprocessthe tailoring improvesof the sub-processes defined this way contributes to the implementation of the ''purpose'' and ''strategy''.

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

FurtherA further decomposition of the sub-processprocesses decompositioncan then maytake occurplace during [[Business process modeling#Modeling business process|business process modeling]] if necessary. If the business process iscan abe phasedrepresented as a sequence of phases, separated by [[Milestone (project management)|milestones]], phasethe decomposition into phases is common. TransferringWhere possible, the transfer of milestones to the next level of decomposition levelcontributes to improvesgeneral 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="FUEERMANN4FUEERMANN" /> ^{(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]]'' ensuresis responsible for success, setscreates the framework conditions, and coordinates his or her approach with that of the other process owners. TheyFurthermore, alsohe/she manageis inter-processresponsible communicationfor the exchange of information between the business processes. This coordination is necessary in order to achieve the overall goalsgoal orientation.

=== Modeling business process ===

==== Design of the process chains ====

BusinessIf processbusiness documentationprocesses are documented using a specific IT -system and [[Business process modeling#Representation type and notation|representation]], such as graphicale.g. modelinggraphically, this is calledgenerally referred to as modeling. The resultingresult documentof the documentation is the ''business process model''.

[[File:TOBE-modell_and_ASIS-modell_in_PDCA.png|thumb|''To be'' model and ''as is'' model superimposed on the PDCA]]

[[File:TOBE-modell and ASIS-modell in PDCA.png|thumb|''To be'' model and ''as is'' model superimposed on the PDCA]]

; ''As is'' modeling and ''to be'' modeling

;''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 ''application'' and the ''strategy for the long-term success of business process modeling''. The previous procedure with analysis of business activities, [[Business process modeling#Definition of business processes|defineition of business processes]] and [[Business process modeling#Further structuring of business processes|further structuring of business processes]] is advisable in any case.

; ''As-is'' modeling

Ansgar Schwegmann and Michael Laske explain: "Determining the current status is the basis for identifying weaknesses and localizing potential for improvement. For example, weak points such as organizational breaks or insufficient IT penetration can be identified."<ref name="SCHWEGMANN-LASKE4LASKE">Ansgar Schwegmann and Michael Laske: ''Istmodellierung und Istanalyse'' in Jörg Becker, Martin Kugler and Michael Rosemamm (publisher): ''Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung'', 2nd corrected and expanded edition, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7</ref> ^{(Chapter 5.1 Intention of the ''as is'' modeling) ← automatic translation from German}

DisadvantagesThe offollowing disadvantages speak against ''as is'' modeling include:

* 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

* The project's creativity suffers because old structures and processes may be uncritically adopted in downstream target modeling.

These arguments weigh particularly heavily if Business process re-engineering (BPR) is planned anyway.

* Creating detailed ''as is'' models requires considerable effort, influenced by the need for consensus among project participants regarding interfaces and responsibility transitions.

These arguments are especially important if Business process re-engineering (BPR) is planned.

Ansgar Schwegmann and Michael Laske also list a number of advantages of ''as is'' modeling:<ref name="SCHWEGMANN-LASKE4" /> ^{(Chapter 5.1 Intention of as-is modeling) ← automatic translation from German}

* Modeling the current situation identifies weaknesses and improvement potential.

* Knowing the current state is essential for developing migration strategies to the target state.

* Modeling the current state provides an overview of the existing situation, valuable for new and external project participants.

* ''As is'' modeling provides a starting point for training project participants in tools and methods.

* The ''as is'' model serves as a checklist for later target modeling, preventing overlooked issues.

* The ''as is'' models are useful starting points for target modeling if the target state closely resembles the current situation, at least in some areas.

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

* Modeling the current state provides an overview of the existing situation, which can be particularly valuable for newly involved and external project participants

* The ''as is'' modeling can be a starting point for training and introducing project participants to the tools and methods

* The ''as is'' model can serve as a checklist for later target modeling so that no relevant issues are overlooked

* The ''as is'' models can be used as starting models for target modeling if the target state is very similar to the current situation, at least in some areas

Other advantages can also be found, such as

* 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

* The ''as is'' model supports management system certification.

* The ''as is'' model serves as a basis for organizational documentation (written rules, specifications, and regulations).

* Workflow management requirements can be checked using the ''as is'' model (process definitions, repetition rates, etc.).

* Key figures, using the ''as is'' model, can be compared to post-reorganization figures to measure the measures' success.

; ''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-SCHNETT4" /> ^{(Chapter 6.2.3 Capturing and documenting ''to be'' models )}

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

They also list five basic principles proven effective in creating ''to be'' models:

)</sup>

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

* Parallel processing of subprocesses and activities is preferable to sequential processing for optimization.

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

* One person or group should consistently develop each subprocess for optimal model quality.

* 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 of individual subprocesses and activities reduces quality assurance costs.

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

* Each process should have at least one internal customer to improve customer awareness and process performance assessment.

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

* Consider learning effects when introducing target processes; this enhances employee awareness of value creation.

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

==== Sub-processes ====

;Delimitation

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

; Delimitation

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

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

August W. Scheer reportedly said in his lectures: ''A process is a process is a process.'' This highlights the [[Recursion|recursiveness]] of the term, as almost every process comprises smaller subprocesses. Terms like ''business process'', ''main process'', ''subprocess'', and ''elementary process'' merely attempt to categorize process decomposition levels. Because there's no universally agreed-upon granularity for these terms, their definitions depend on the specific business process model.

Some German business informatics schools avoid the terms ''process'' (representing a sequence of [[Action (Philosophy)|actions]]) and ''function'' (a delimited ''corporate function''/activity area assigned to a ''corporate function'' owner).

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

InFor example, in August W. Scheer's ARIS, ''it is possible to use functions'' from the ''function view'' can be used as processes in the ''control view,'' and vice versa. ThisAlthough reusesthis has the advantage that already defined processes or ''functions'', butcan be reused across the board, it also blursmeans that the distinctionproper betweenpurpose of the ''function view'' is diluted and the ARIS user is no longer able to separate ''processes'' and ''functions,'' hinderingfrom clearone separation for the ARIS useranother.

The first image shows as a value chain diagram how the business process ''Edit sales pipeline'' ashas a value chain diagram,been broken down into ''sub-processes'' (in the sense of representing the sequence of actions (activities)) based on byits phasephases.

The second image shows an excerpt of typical ''functions'' (in the sense of delimited ''corporate function''/action (activity) areas, which are assigned to a ''corporate function'' owner''), which are structured bybased on the areas of competence and responsibility hierarchy. The ''corporate functions'' supportingthat support the business process ''Edit sales pipeline'' business process are marked in the function tree.

; Utilization

A business process decomposescan be decomposed into sub-processes until further decomposition is meaninglessno (thelonger meaningful/possible (smallest meaningful sub-process is an= ''elementary process''). AllUsually, decompositionall levels areof usuallydecomposition of a business process are documented usingin the same processmethodology: Process symbols. TheseThe process symbols, used when modeling one level, typicallyof decomposition then usually refer to the next level's sub-processes of the next level until reachingthe level of ''elementary processes'' is reached. Value chain diagrams are often used to represent ''business processes'', ''main processes'', ''sub-processes'', and ''elementary processes''.

; Workflow

A [[workflow]] representsis a representation of a sequence of tasks, performeddeclared byas work of a person, mechanism,of group,a organization,simple or machinescomplex (includingmechanism, ITof systems).a group of persons,<ref>{{Cite web |date=27 May 2024 |title=ISO - International Organization for Standardization |url=https://www.iso.org/home.html|title=ISO - International Organization for Standardization|website=ISO|date=27 May 2024 }}</ref> It'sof an organization of staff, or of machines (including IT-systems). A workflow is therefore always located at the elementary process level,. abstractingThe workflow may be seen as any abstraction of real work, segregated into sharesworkshare, splitswork split, or other ordered types of ordering. For control purposes, itthe workflow may representbe a view of real work fromunder a specificchosen perspectiveaspect.

==== Functions (''Tasks'') ====

[[File:Actions-of-an-elementary-process.png|thumb|Tasks of an elementary process, task sequence determined by three different approaches]]

;Delimitation

The term ''functions'' is often used synonymously for a delimited ''corporate function''/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 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''.

; Delimitation

;Utilization

The term ''functions'' often denotes a delimited ''corporate function''/action area assigned to a ''corporate function owner'', and also an atomic [[Task (project management)|activity]]. To avoid ambiguity, use ''task'' for atomic activities at the elementary process level, consistent with BPMN naming. Modern tools automate ''task''-to-''process'' conversion, allowing further process decomposition; a ''task'' then becomes an ''elementary process''.

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 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 ([[model]]s) are used.

; Utilization

Elementary processes use graphical elements to show the temporal-logical sequence of functions (''tasks''). This sequence is determined by logical linking (using [[Logical connective|logical operators]] or [[Business Process Model and Notation#Gateway|Gateways]]), unless specified by input/output relationships or milestones. Additional graphical elements often illustrate interfaces, states (events), conditions (rules), and milestones for clarity. Modeling tools use varying graphical representations ([[Model|models]]).

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

GraphicalFurthermore, elements can supplementthe functions (''tasks'') can be supplemented with graphical elements to describe inputs, outputs, systems, and roles, etc. with the aim of improving the accuracy of the description and/or increasing the number of detaildetails. However, thisthese canadditions quickly make the ''model'' confusing. TwoTo solutionsresolve addressthe thiscontradiction between accuracy of description and clarity, there are two main solutions: outsourcingOutsourcing thesethe additional graphical elements for describing inputs, outputs, systems, roles, etc. to a [[Function Allocation Diagram]] (FAD), or selectively showing/hiding themthese basedelements depending on the question or /application.

The image's ''function allocation diagram'' clearlyshown in the image illustrates addedthe addition of graphical elements describingfor functionthe (task)description of inputs, outputs, systems, and 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) 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's in ARIS, this would be the basic viewsinformation areof organizationalthe organization view, data view, function, view and performance view.<ref name="SCHEER4SCHEER">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="GADATSCH4GADATSCH" /> ^{(Chapter 3.2 GPM – Holistic process modelling) ← automatic translation from German}

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

Master data can be, for example:

* The [[Organizational structure|business unit]] in whose area of responsibility a process takes place

* The [[Organizational structure|business unit]]object whose information is required responsibleto forexecute athe process

* The required[[product (business)|product]] object'sthat informationis produced by the process

* The [[Product (business)|productpolicy]] producedto be observed when byexecuting the process

* The [[policy]] for this process

* The [[risk]] that occurs in a process

* ImprovingThe measure that is carried out to increase the process capability

* Process governanceThe [[Control (management)|control]] that is performed to ensure the governance of the process

* The IT -system supportingthat supports the execution of the business process

* The milestone dividingthat divides processes into process phases

* etc.

AddingBy adding master data to the business process modeling lets, the same business process model servecan be used for different ''application''s, thusand acceleratinga [[return on investment]] for the business process modeling can be achieved more quickly with the resulting synergy.

Depending on thehow much value assignedis given to master data in business process modeling, it is still possible to embed itthe master data in the process model without negatively affecting the readability of the model or outsourcethe itmaster data should be outsourced to a separate view, such as ae.g. [[Function Allocation Diagram]]s.

AddingIf master data is systematically added to the business process model, this is referred to createsas an ''artifact-centric business process'' model.

; Artifact-centric business process

The [[artifact-centric business process model]] offershas emerged as a holistic approach tofor modeling business process modelingprocesses, providingas it provides a highly flexible solution forto capturingcapture operational specifications of business processes. It particularly focuses on describing the data of business processprocesses, dataknown as ("artifacts"), by characterizing business-relevant data objects, their lifecycleslife-cycles, and related services. ThisThe artifact-centric process modelling approach fosters automatedthe automation of the business operations and supports flexiblethe flexibility of the workflow enactment and evolution.<ref>{{cite journal |last1=Yongchareon |first1=Sira |year=2015 |title=A View Framework for Modelling and Change Validation of Artifact-Centric Inter-Organizational Business Processes |journal=Information Systems |year=2015|volume=47 |pages=51–81 |doi=10.1016/j.is.2014.07.004}}</ref>

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

IntegratingThe integration of external [[Document|documentsdocument]]s and IT -systems can significantly increasesincrease the added value of a business process model's value.

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

* 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

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.

* Short response times from the knowledge database; many auditors enable fast content adaptation and easy publication—e.g., using a [[wiki]].

* Legally compliant documents, governed by a small number of specially trained auditors, require validated content adaptation and stringent release criteria; for example, using a [[document management system]].

* A BPM system's graphical process representation; characterized by a moderate number of auditors, relatively fast content adaptation, and modest content release requirements.

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.

If all relevant ''knowledge database'' objects and ''rule framework'' documents are connected to processes, end users contextually access this information without needing to know the connected systems' filing structures.

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

Integrating external systems allows incorporating current measurements and system statuses into processes (e.g., displaying process status), displaying [[Software widget|widgets]], showing external system output, and initiating preconfigured transactions in those systems.

External systems can use [[electronic data interchange]] (EDI).

=== Model consolidation ===

This checksis forabout checking whether there are any redundancies. If foundso, redundantthe subprocessesrelevant sub-processes are combined;. otherwise,Or subprocessessub-processes that are used more than once are outsourced to support processes. SuccessfulFor a successful model consolidation, it may requirebe revisingnecessary to revise the original subprocess decomposition of the sub-processes.

''Ansgar Schwegmann and Michael Laske'' explain: "A consolidation of the models of different modeling complexes is necessary in order to obtain an integrated&nbsp;... model."<ref name="SCHWEGMANN-LASKE4" /> ^{(Chapter 5.2.4 Model consolidation) ← automatic translation from German} They also list a number of aspects for which model consolidation is important:

''Ansgar Schwegmann and Michael Laske'' explain: "A consolidation of the models of different modeling complexes is necessary in order to obtain an integrated&nbsp;... model."<ref name="SCHWEGMANN-LASKE" /> ^{(Chapter 5.2.4 Model consolidation) ← automatic translation from German} They also list a number of aspects for which model consolidation is important:

* "Modeling teams need to drive harmonization of models during model creation to facilitate later consolidation."

* "If an object-oriented decomposition of the problem ___domain is carried out, it must be analyzed at an early stage whether similar structures and processes of different objects exist."

Line 475 ⟶ 447:

* "In general, a uniform level of detail of the models" (in each decomposition level) "should be aimed for during modeling in order to facilitate the comparability of the submodels and the precise definition of interfaces."

* "After completion of the modeling activities in the teams of the individual modeling complexes, [the] created partial models are to be integrated into an overall model."

* "In order to facilitate the traceability of the mapped processes, it makes sense to explicitly model selected business transactions that are particularly important for the company and to map them at the top level.&nbsp;... Colour coding, for example, can also be used to differentiate between associated organizational units."<ref name="SCHWEGMANN-LASKE4LASKE" /> ^{(Chapter 5.2.4 Model consolidation) ← automatic translation from German}

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

[[File:BPMN-Modale-Prozessverkettung_ANDProzessverkettung 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]]

ControlThe Flowchaining Patternsof modelthe howsub-processes subprocesseswith each other and theirthe chaining of the functions (''tasks'') interrelatein the sub-processes is modeled using Control Flow Patterns.

ProcessMaterial interfacesdetails specifyof materialthe detailschaining of(What chaining—whatdoes the predecessor deliversdeliver to the successor—ifsuccessor?) are specified in the process interfaces if neededintended.

=== Process interfaces ===

Process interfaces are defined in order to

* Show the relationships between the sub-processes after the decomposition of business processes or

* Determine '''what''' the business processes or their sub-processes must 'pass on' to each other.

As a rule, this '''what''' and its structure is determined by the requirements in the subsequent process.

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

* Show the relationships between sub-processes after decomposing business processes.

* Determine '''what''' business processes must share.

This structure is determined by subsequent process requirements.

Process interfaces mark the transition between business processes or subprocesses.

[[File:Process-flow-with-interface-to-service-process.png|thumb|A 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.

* Represent a business process model/sub-process model independentlythat is referenced from two/multiple superordinate or neighboring business process models.

* Represent atwo/multiple variants of the same business process or model/sub-process referenced by multiple other modelsmodel.

Process interfaces are agreed between the participants of superordinate/subordinate or neighboring business process models. They are defined and linked once and used as often as required in [[business process model|process model]]s.

* Represent two or more variants of the same business process model.

Participants in related business process models agree on process interfaces. These interfaces are defined and linked once, then reused as needed in [[Business process model|process models]].

Interfaces can be defined by:

* Transfer of responsibility/accountability from one business unit to another,

* Transfer of data from one IT-system to another,

* Original input (information / [[material]]s at the beginning of the business process),

* Transfer of intermediate results between sub-processes (output at the predecessor and input at the successor are usually identical) or

* Final 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 objects 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).

* Transferring responsibility between business units

* Data transfer between IT systems

* Initial inputs (information and [[Material|materials]]) at the business process start.

* Transfer of intermediate results between subprocesses (predecessor output and successor input are usually identical)

* Final output (the business process's result).

Transferred inputs and outputs are often data or information, but may also include other business objects: materials, finished or semi-finished products, or documents like delivery bills. These are conveyed via appropriate transport media (e.g., data storage for data).

=== Business process management ===

See article Business process management.

ToIn implementorder to put improved business processes into practice, [[change management]] programs are usually neededrequired. AdvancesWith advances in software design, arethe vision of BPM models makingbeing fully executable BPM models—enabling(enabling simulations and round-trip engineering—aengineering) is getting closer to reality.

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

In business process management, process flows are regularly reviewed and optimized (adapted) if necessary. ThisRegardless optimization,of whether driventhis adaptation of process flows is triggered by [[Continual improvement process|continuous process improvement]] or by process reorganization (business process re-engineering), requiresit updatingentails an update of individual subprocessessub-processes or an entire business processesprocess.

== Representation type and notation ==

In practice, combinations of ''informal'', ''semiformal'', and ''formal'' models are common: ''informal'' texttextual descriptions for explanation, ''semiformal'' graphicsgraphical representation for [[Visualization (graphics)|visualization]], and ''formal language'' languagerepresentation forto support [[simulation]] and codetransfer generationinto executable code.

=== Modelling techniques ===

VariousThere notationare various standards existfor 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

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

* ''Value-added chain diagram'' ([[:de:Wertschöpfungskettendiagramm|VAD]]), for visualizing processes mainly at a high level of abstraction

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

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

* ''Value-added chain diagram'' ([[:de:Wertschöpfungskettendiagramm|VAD]], visualizing high-level processes)

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

* [[Carl Adam Petri]] developed the [[Petri net]] in 1962.

* [[HIPO model]], developed by IBM around 1970 as a design aid and documentation technology for software (in a non-technical, but business-oriented form)

* Follow-up plans, such as a [[Flowchart]], proposed in 1997 by Fischermanns and Liebelt

* [[Lifecycle Modeling Language]] (LML), originally designed by the LML steering committee and published in 2013

* IBM developed the [[HIPO model]] around 1970 as a software design and documentation aid, presented in a business-oriented format.

* [[Lifecycle Modeling Language]] (LML), originally designed by its steering committee and published in 2013

* [[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 laterthen adopted by [[Lean Management]] and Six Sigma practitioners

* [[Unified Modelling Language]] (UML), proposed in 1996 by [[Grady Booch]], [[Ivar Jacobson]], and [[James Rumbaugh]], is continuously revised byunder the aegis of the OMG and(provides includesextensions for business process extensions.)

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

* Pablo Iacub and Leonardo Mayo created [[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]] developedfor inthe 2002 to describedescription and automateautomation of business processes

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

Furthermore:

* ''Communication structure analysis'', proposed in 1989 by Prof. [[:de:Hermann Krallmann|''Hermann Krallmann'']] at the Systems Analysis Department of the TU Berlin.

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

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

* ''Semantic object model'' ([[:de:Semantisches Objektmodell|SOM]]), proposed in 1990 by ''Otto K. Ferstl and Elmar J. Sinz''

* [[:de: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'' ([[:de:Vorgangskettendiagramm|PCD]]) and other methods use this technique

* [[:de: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:

* Professor [[:de:Hermann Krallmann|''Hermann Krallmann'']] of the TU Berlin's Systems Analysis Department proposed ''Communication structure analysis'' in 1989.

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

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

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

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

* ''Semantic object model'' ([[:de:Semantisches Objektmodell|SOM]], proposed in 1990 by ''Otto K. Ferstl and Elmar J. Sinz'')

* [[:de:PICTURE-Methode|PICTURE-Methode]] for documenting and modeling business processes in public administration

* [[Data-flow diagram|Data-flow diagrams]] represent data flow through a process or system.

* [[Swimlane]] diagrams, primarily known through [[BPMN]] but also used in SIPOC, process chain diagrams ([[:de:Vorgangskettendiagramm|PCD]]), and other methods, employ this technique.

* [[:de:ProMet|ProMet]], a business engineering methodology.

* [[State diagram|State diagrams]] describe system behavior.

Additionally, [[software architecture]] representation types are also usable.

* [[Flowchart|Flowcharts]], standardized in DIN 66001 (September 1966, last revised December 1983) and [[ISO 5807]] (1985)

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

==== Business Process Model and Notation (BPMN) ====

Line 602 ⟶ 567:

=== 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="NIH074NIH07">[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 ===

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

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

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

Some vendor-specific languages:

* [[Architecture of Integrated Information Systems]] (ARIS) supports EPC,

* [[Architecture of Integrated Information Systems]] (ARIS) supports EPC.

* [[Java Process Definition Language]] ([[JBPM]]),

Other technologies related to business process modelling include [[model-driven architecture]] and [[service-oriented architecture]].

=== 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="NIH074NIH07" />

* [[Use case diagram]]s created by Ivar Jacobson, 1992 (integrated into UML)

* Ivar Jacobson's 1992 [[Use case diagram|Use case diagrams]] (integrated into UML)

* Activity diagrams (also adopted by UML)

== Related concepts ==

=== Business reference model ===

[[File:Government_Business_Reference_ModelGovernment Business Reference Model.svg|thumb|360x360px360px|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]] focusesis a reference model, concentrating on the functional and organizational aspects of aan [[Business|enterprise]], [[Tertiary sector of the economy|service organization]], or [[government agency]]. AIn general, a [[reference model]] is a model of something that embodies the basic goal or idea of something, servingand can then be looked at as a reference for various purposes. A business reference model describesis ana organization'smeans to describe the business operations of an organization, independent of itsthe organizational structure that performs them. Other types of business reference models can also depict relationshipsthe relationship between the business processes, business functions, and the business areasarea's business reference model. These layeredreference models providecan be constructed in layers, and offer a foundation for analyzingthe analysis of service components, technology, data, and performance.

The most familiar business reference model is the Business Reference Model of the US federal government's. BusinessThat Referencemodel Model.is Thisa [[Functionfunction model|function-driven]] framework describesfor federaldescribing governmentthe business operations independentlyof the federal government independent of the agencies involvedthat 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> It provides an organized, hierarchical structure for describing daily operations. While other organizational models exist—[[Organizational chart|organizational charts]], ___location maps, etc.—this model uses a functional approach.

=== Business process integration ===

[[File:Process_and_data_modelingProcess and data modeling.svg|thumb|320x320px320px|Example of the interaction between business process and data models<ref name="SS934SS93">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>]]

A business model, which may be considered an elaboration of a business process model, typically shows business data, and business organizations, andas well as business processes. ShowingBy showing business processes and their information flows, ita letsbusiness 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, aidingwhich is useful for developing [[software code]] development. See the figure on the right for an example of the interaction between business process models and data models.<ref name="SS934SS93">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="SS934SS93" />

Business models are developed to define either the current state of the process, resulting in the 'as is' snapshot model, or a vision of what the process should evolve into, leading to a 'to be' model. By comparing and contrasting the 'as is' and 'to be' models, business analysts can determine if existing business processes and information systems require minor modifications or if reengineering is necessary to enhance efficiency. As a result, business process modeling and subsequent analysis can fundamentally reshape the way an enterprise conducts its operations.<ref name="SS934SS93" />

=== Business process re-engineering ===

[[File:Business_Process_Reengineering_CycleBusiness 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 organizational processes. It examines business processes from a "clean slate" perspective to determine optimal design.

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

Business process re-engineering (BPR) initially helped organizations fundamentally rethink their work. Sophisticated information systems and networks spurred this re-engineering. Leading organizations use this technology to support innovative processes, not merely refine existing ones.<ref name="GAO974">[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 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 implementinvolved to put any improved business processes into practice. AdvancesWith advances in software design, arethe makingvision fully executableof BPM models, becoming fully executable (and capable of simulations and round-trip engineering,) is coming closer ato reality.

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

In business process management, process flows are regularly reviewed and, optimizedif asnecessary, optimized needed(adapted). WhetherRegardless drivenof whether this adaptation of process flows is triggered by [[continual improvement process]] or business process re-engineering, thisit adaptationentails updatesupdating individual sub-processes or an entire business processesprocess.

== See also ==

{{Portal|Business and economics}}

}}

* [[Business architecture]]

* [[Business Model Canvas]]

Line 671 ⟶ 631:

{{Reflist}}

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

* Aguilar-Saven, Ruth Sara. "[http://secure.com.sg/courses/ICT353/Session_Collateral/TOP_04_ART_03_ARTICLE_AGUILAR_Biz_Proc_Modelling.pdf Business process modelling: Review and framework] {{Webarchive|url=https://web.archive.org/web/20200807172900/http://secure.com.sg/courses/ICT353/Session_Collateral/TOP_04_ART_03_ARTICLE_AGUILAR_Biz_Proc_Modelling.pdf |date=2020-08-07 }}." ''International Journal of production economics'' 90.2 (2004): 129–149.

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

* Aguilar-Saven, Ruth Sara. "[http://secure.com.sg/courses/ICT353/Session_Collateral/TOP_04_ART_03_ARTICLE_AGUILAR_Biz_Proc_Modelling.pdf Business process modelling: Review and framework] {{Webarchive|url=https://web.archive.org/web/20200807172900/http://secure.com.sg/courses/ICT353/Session_Collateral/TOP_04_ART_03_ARTICLE_AGUILAR_Biz_Proc_Modelling.pdf|date=2020-08-07}}." ''International Journal of production economics'' 90.2 (2004): 129–149.

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

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

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

Line 685 ⟶ 645:

== External links ==

*{{Commons category-inline}}

{{Software engineering}}

* {{Commons category-inline}}

{{Software engineering}}{{Systems Engineering}}<nowiki>{{|bot=InternetArchiveBot |fix-attempted=yes}}</nowiki>

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

{{DEFAULTSORT:Business Process Modelling}}

[[Category:Business process modelling| ]]