Business process modeling: Difference between revisions

Revision as of 02:23, 13 June 2024

Latest revision as of 00:20, 29 June 2025

(33 intermediate revisions by 24 users not shown)

Line 7:

}}

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

'''Business process modeling''' ('''BPM'''), mainly used in [[business process management]]; [[software development]], or [[systems engineering]], is the action of capturing and representing [[business processes|processes]] of an enterprise (i.e. [[modeling]] them), so that the current business processes may be analyzed, applied securely and consistently, improved, and automated. BPM is typically orchestrated by business analysts, leveraging their expertise in modeling practices. Subject matter experts, equipped with specialized knowledge of the processes being modeled, often collaborate within these teams. Alternatively, process models can be directly derived from digital traces within IT systems, such as event logs, utilizing process mining tools.

BPM is typically performed by business analysts, with subject matter experts collaborating with these teams to accurately model processes. It is primarily used in [[business process management]], [[software development]], or [[systems engineering]].

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

== Overview ==

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

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

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

* Process modeling

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

* Process design (: redesign -– business process reengineering -– or redesign of business processes -– business process optimization).

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

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

However, athese completelydisciplines separatecannot consideration of the disciplinesbe isconsidered notin possibleisolation: Business process modeling always requires a ''business process analysis'' for modeling the as-is processes (see section [[#Analysis of business activities|Analysis of business activities]]) or specifications from ''process design'' for modeling the to-be processes (see sections [[#Business process re-engineering (BPR)|Business process reengineering]] and [[#Business process optimization|Business process optimization]]).

The focus of business process modeling is on the [[#Representation type and notation|representation]] of the flow of [[Action (philosophy)|actions (activities)]], according to Hermann J. Schmelzer and Wolfgang Sesselmann consisting "of the cross-functional identification of value-adding activities that generate specific services expected by the customer and whose results have strategic significance for the company. They can extend beyond company boundaries and involve activities of customers, suppliers, or even competitors."<ref name="SCHMELZER">Hermann J. Schmelzer and Wolfgang Sesselmann: ''Geschäftsprozessmanagement in der Praxis'', 9th edition, Hanser, Munich 2020, ISBN 978-3-446-44625-0</ref> ^{(Chapter 2.1 Differences between processes and business processes) ← automatic translation from German}

Line 23 ⟶ 27:

But also other [[Quality (philosophy)|qualities]] (facts) such as [[data]] and [[business object]]s (as inputs/outputs, [[formal organization]]s and [[Actor (UML)|roles]] (responsible/accountable/consulted/informed persons, see [[Responsibility assignment matrix|RACI]]), [[resource]]s and [[application software|IT-systems]] as well as [[guideline]]s/instructions ([[Means of labor|work equipment]]), [[requirement]]s, [[Performance indicator|key figure]]s etc. can be modeled.

TheIncorporating more of these characteristics are incorporated into the business process modeling, the betterenhances the abstractionaccuracy of theabstraction businessbut processalso models reflects reality - and the more complex the business processincreases modelsmodel becomecomplexity. "To reduce complexity and improve the comprehensibility and transparency of the models, the use of a view concept is recommended."<ref name="GADATSCH">Andreas Gadatsch: ''Management von Geschäftsprozessen / Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker'', 2nd revised and expanded edition, Vieweg, Braunschweig/Wiesbaden 2002, ISBN 978-3-528-15759-3</ref>^{(Chapter 2.4 Views of process modeling) ← automatic translation from German} There is also a brief comparison of the view concepts of five relevant German-speaking schools of [[business informatics]]: 1) August W. Scheer, 2) Hubert Österle, 3) Otto K. Ferstl and Elmar J. Sinz, 4) Hermann Gehring and 5) Andreas Gadatsch.

The term ''view''s ([[August-Wilhelm Scheer|August W. Scheer]], Otto K. Ferstl and Elmar J. Sinz, Hermann Gehring and Andreas Gadatsch) is not used uniformly in all schools of business informatics -– alternative terms are ''design dimensions'' (Hubert Österle) or ''perspectives'' (Zachman).

M. Rosemann, A. Schwegmann, and P. Delfmann also see disadvantages in the ''concept of views'': "It is conceivable to create information models for each perspective separately and thus partially redundantly. However, redundancies always mean increased maintenance effort and jeopardize the consistency of the models."<ref name="ROSEMANN">Michael Rosemann, Ansgar Schwegmann and Patrick Delfmann: ''Vorbereitung der Prozessmodellierung'' in Jörg Becker, Martin Kugler and Michael Rosemamm (publisher): ''Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung'', 2nd corrected and expanded edition, Springer, Berlin/Heidelberg/New York 2002, ISBN 978-3-540-00107-2</ref> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

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

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

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

According to the European Association of Business Process Management EABPM, "there are three different types of end-to-end business processes:

* Leadership processes;

* Execution processes and

* Support processes."<ref name="EABPM"/> ^{(Chapter 2.4 Process types) ← automatic translation from German}

These three process types can be identified in every company and are used in practice almost without exception as the top level for structuring business process models.<ref>Knowledge database: [https://der-prozessmanager.de/aktuell/wissensdatenbank/prozesslandkarte ''In 6 einfachen Schritten zur Prozesslandkarte''], DER PROZESSMANAGER GmbH (last accessed: January 25, 2024)</ref> Instead the term ''leadership processes'' the term ''[[management process]]es'' is typically used. Instead of the term ''execution processes'' the term ''[[Business processes|core process]]es'' has become widely accepted.<ref name="SCHMELZER"/> ^{(Chapter 6.2.1 Objectives and concept) ← automatic translation from German,}<ref name="BECKER-KAHN">Jörg Becker and Dieter Kahn: ''Der Prozess im Fokus'' in Jörg Becker, Martin Kugler and Michael Rosemamm (publisher): ''Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung'', 2nd corrected and expanded edition, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7</ref> ^{(Chapter 1.3 The concept of process) ← automatic translation from German,}<ref name="BECKER-MEISE">Jörg Becker and Volker Meise: ''Strategie und Organisationsrahmen'' in Jörg Becker, Martin Kugler and Michael Rosemamm (publisher): ''Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung'', 2nd corrected and expanded edition, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7</ref> ^{(Chapter 4.12.2 Differentiation between core and support objectives) ← automatic translation from German,}<ref name="SPECK-SCHNETT">Mario Speck and Norbert Schnetgöke: ''Sollmodellierung und Prozessoptimierung'' in Jörg Becker, Martin Kugler and Michael Rosemamm (publisher): ''Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung'', 2nd corrected and expanded edition, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7</ref> ^{(Chapter 6.2.2 Identification and rough draft) ← automatic translation from German}

Line 46 ⟶ 50:

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

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

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

== Objectives of business process modeling ==

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

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

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

Line 59 ⟶ 63:

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

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

* documentationDocumentation of the company's business processes

** to gain knowledge of the business processes

** to map business unit(s) with the applicable regulations

Line 74 ⟶ 78:

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

** to support quality and environmental management

* definitionDefinition of process performance indicators and monitoring of process performance

** to increase process speed

** to reduce cycle time

** to increase quality

** to reduce costs, such as labor, materials, scrap, or capital costs

* preparationPreparation/implementationImplementation of a ''business process optimization'' (which usually begins with an analysis of the current situation)

** to support the analysis of the current situation

** to develop alternative processes

Line 85 ⟶ 89:

** to outsource company tasks

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

* preparationPreparation of an [[information technology]] project

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

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

** to introduce automation or IT support - with a [[workflow management]] system

* definitionDefinition of interfaces and [[Service-level agreement|SLAs]]

* [[Modularity|modularizationModularization]] of company processes

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

* performPerforming [[activity-based costing]] and [[simulation]]s

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

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

* findingFinding the [[best practice]]

* accompanyAccompanying organizational changes

** such as the sale or partial sale

** such as the acquisition and integration of companies or parts of companies

** such as the introduction or change of IT systems or organizational structures

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

== Applications of business process modeling ==

Since business process modeling in itself makes no direct contribution to the financial [[Profit (economics)|success]] of a company, there is no motivation for business process modeling from the most important goal of a company, the [[For-profit corporation|intention to make a profit]]. The motivation of a company to engage in business process modeling therefore always results from the respective purpose. ''Michael Rosemann, Ansgar Schwegmann und Patrick Delfmann'' listlists 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

* 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="ROSEMANN" /> ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German} with the objective of a [[vulnerability assessment]]<ref name="GADATSCH"/> ^{(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-SPARLING">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''

Line 148 ⟶ 152:

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:

* determineDetermine the inputs required and the outputs expected

* determineDetermine the sequence and interaction

* defineDefine and apply the criteria and methods (including monitoring, measurement, and related performance indicators) for effective operation and control

* determineDetermine the resources needed

* assignAssign the responsibilities and authorities

* addressAddress the risks and opportunities

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

* improveImprove

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

detailed requirements with regard to processes:

* maintainMaintain documented information

* retainRetain documented information for correct implementation

The implementation of the standard requirements for the ''processes needed and their interactions'' and, in particular, proof of the implementation of the standard requirements with adequate documentation (business process modelling) is common practice. This also means that the standard requirements for ''documented information'' are also relevant for business process modelling as part of an ISO management system.

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

Line 168 ⟶ 172:

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

* documentedDocumented information by the standard requirements; and

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

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

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

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

* Review and approval

* Überprüfung und Genehmigung;

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

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

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

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

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

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

* toTo consider storage and disposition of further whereabouts.

Based on the standard requirements,

#* toTo determine and continuously improve the ''required processes and their interactions''

#* toTo determine and maintain the content of the ''documented information'' deemed necessary and

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

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

=== Business process optimization ===

Line 200 ⟶ 204:

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

Six Sigma is designed to prevent errors and improve the [[Process capability index|process capability]] so that the proportion of process outcomes that meet the requirements is 6σ -– or in other words, for every million process outcomes, only 3.4 errors occur. Hermann J. Schmelzer and Wolfgang Sesselmann explain: "Companies often encounter considerable resistance at a level of 4σ, which makes it necessary to redesign business processes in the sense of business process re-engineering (design for Six Sigma)."<ref name="SCHMELZER" /> ^{(Chapter 6.3.4 Six Sigma) ← automatic translation from German} For a reproducible measurement of process capability, precise knowledge of the business processes is required and business process modeling is a suitable tool for design for Six Sigma. Six Sigma, therefore, uses business process modeling according to [[SIPOC]] as an essential part of the methodology, and business process modeling using SIPOC has established itself as a standard tool for Six Sigma.

=== Inter-company business process modeling ===

Line 213 ⟶ 217:

The analysis of business activities determines and defines the framework conditions for successful business process modeling. This is where the company should start,

* define the relevant ''applications'' of business process modeling 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, with a viewand to resource optimization or in a balanced manner.

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, with a view to resource optimization or in a balanced manner.

==== Identify business processes ====

Line 229 ⟶ 231:

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

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

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

[[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 the strategic relevance of each process,

* Analysis of the need for improvement of a process and

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

The structuring of business processes generally begins with a distinction between management, core, and support processes.

Line 250 ⟶ 252:

As the ''core business processes'' clearly make up the majority of a company's identified business processes, it has become common practice to subdivide the core processes once again. There are different approaches to this depending on the type of company and business activity. These approaches are significantly influenced by the defined ''application'' of business process modeling and the ''strategy for the long-term success of business process modeling''.

In the case of a primarily market-based strategy, end-to-end core business processes are often defined from the customer or supplier to the retailer or customer (e.g. "Fromfrom offer to order", "Fromfrom order to invoice", "Fromfrom order to delivery", "Fromfrom 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 ("Gaininggaining orders", "Procuringprocuring and providing materials", "Developingdeveloping products", "Providingproviding services", etc.).

In a differentiated view without a clear focus on the market view or the resource view, the core business processes are typically divided into CRM, PLM and SCM.

Line 266 ⟶ 268:

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

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

* fulfillFulfill their own market requirements,

* operateOperate largely autonomously/independently and independently of other business areas and

* contributeContribute to the [[contribution margin|business success]] of the company,

forFor the company

* haveHave a strong external impact,

* canCan be easily differentiated from other business processes and

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

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

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

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

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

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

In elucidating this point, Jörg Becker and Volker Meise elucidate that the communication strategy within an organizational design initiative should aim to garner support from members of the organization for the intended structural changes. It is worth noting that business process modeling typically precedes business process optimization, which entails a reconfiguration of process organization -– a fact well understood by the involved parties. Therefore, the communication strategy must focus on persuading organizational members to endorse the planned structural adjustments."<ref name="BECKER-MEISE" /> ^{(Chapter 4.15 Influencing the design of the regulatory framework) ← automatic translation from German} In the event of considerable resistance, however, external knowledge can also be used to define the business processes.

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

Line 295 ⟶ 297:

=== Further structuring of business processes ===

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

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

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

Line 302 ⟶ 304:

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

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

=== Assigning the process responsibility ===

[[File:Pyramid-of-process-responsibility.png|thumb|Sample for a pyramid of process responsibility]]

Complete, self-contained processes are summarized and handed over to a responsible person or team. The ''[[Ownership|process owner]]'' is responsible for success, creates the framework conditions, and coordinates his or her approach with that of the other process owners. Furthermore, he/she is responsible for the exchange of information between the business processes. This coordination is necessary in order to achieve the overall goal orientation.

=== Modeling business process ===

Line 322 ⟶ 324:

The following disadvantages speak against ''as is'' modeling:

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

* theThe creation of detailed ''as is'' models represents a considerable effort, also influenced by the effort required to reach a consensus between the project participants at interfaces and responsibility transitions

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

Line 345 ⟶ 347:

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

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

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

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

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

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

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

Line 357 ⟶ 359:

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

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 (activities)]]) and ''function'' (in the sense of a delimited ''corporate function''/action (activity) area that is clearly 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]]

Line 396 ⟶ 398:

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

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

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

Master data can be, for example:

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

* theThe business object whose information is required to execute the process

* theThe [[product (business)|product]] that is produced by the process

* theThe [[policy]] to be observed when executing the process

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

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

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

* theThe IT-system that supports the execution of the business process

* theThe milestone that divides processes into process phases

* etc.

Line 426 ⟶ 428:

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

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

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

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

Line 455 ⟶ 457:

=== Process interfaces ===

Process interfaces are defined in order to

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

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

Line 463 ⟶ 465:

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

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

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

* representRepresent two/multiple variants of the same business process model/sub-process model.

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.

Interfaces can be defined by:

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

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

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

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

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

Line 490 ⟶ 492:

=== Modelling techniques ===

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

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

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

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

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

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

Line 509 ⟶ 511:

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=ArchivedBusiness copyProcess 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>{{WebarchivWebarchive |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

Line 519 ⟶ 521:

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

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

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

Line 566 ⟶ 568:

=== Tools ===

Business process modelling tools provide business users with the ability to model their business processes, implement and execute those models, and refine the models based on as-executed data. As a result, business process modelling tools can provide transparency into business processes, as well as the centralization of corporate business process models and execution metrics.<ref name="NIH07">[http://enterprisearchitecture.nih.gov/ArchLib/AT/TA/WorkflowServicePattern.htm Workflow/Business Process Management (BPM) Service Pattern] {{webarchive|url=https://web.archive.org/web/20090113184950/http://enterprisearchitecture.nih.gov/ArchLib/AT/TA/WorkflowServicePattern.htm |date=2009-01-13}} June 27, 2007. Accessed 29 nov 2008.</ref> Modelling tools may also enable collaborate modelling of complex processes by users working in teams, where users can share and simulate models collaboratively.<ref>Christensen, Lars Rune & Thomas Hildebrandt (2017) [https://pure.itu.dk/portal/files/83457483/Christensen_Hildebrandt_2017.pdf Modelling Cooperative Work at a Medical Department]. Proceedings of the 8th International Conference on Communities and Technologies. Troyes, France. ACM.

</ref> Business process modelling tools should not be confused with business process automation systems -– both practices have modeling the process as the same initial step and the difference is that process automation gives you an 'executable diagram' and that is drastically different from traditional graphical business process modelling tools.{{citation needed|date=November 2017}}

=== Programming language tools ===

Line 598 ⟶ 600:

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

Business models are developed asto definingdefine either the current state of the process, resulting in which case the final product is called the "'as is"' snapshot model, or a conceptvision of what the process should becomeevolve into, resultingleading into a "'to be"' model. By comparing and contrasting "the 'as is"' and "'to be"' models the, business analysts can determine if the existing business processes and information systems are sound and only needrequire minor modifications, or if reengineering is requirednecessary to correctenhance problemsefficiency. orAs improvea efficiency. Consequentlyresult, business process modeling and subsequent analysis can be used to fundamentally reshape the way an enterprise conducts its operations.<ref name="SS93"/>

=== Business process re-engineering ===

Line 640 ⟶ 642:

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

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

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

== External links ==