Content deleted Content added
Fgnievinski (talk | contribs) Tags: Mobile edit Mobile web edit Advanced mobile edit |
Edit for brevity using EditEngine - an experimental LLM-powered program Tags: Reverted nowiki added Visual edit |
||
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 [[
Alternatively, process models can be directly modeled from IT systems
== Overview ==
[[File:Fife-Disciplines-Of-The-BPM.png|thumb|The five disciplines of business process management and their relationships]]
* 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.
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]]).
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> <sup>(Chapter 2.1 Differences between processes and business processes) ← automatic translation from German</sup>
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.
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><sup>(Chapter 2.4 Views of process modeling) ← automatic translation from German</sup> 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 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).
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> <sup>(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German</sup>
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" /> <sup>(Chapter 1.1 Process management) ← automatic translation from German</sup>
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]]
* Leadership processes;
* Execution processes and
* Support processes.<ref name="
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 ''[[
If the ''core processes'' are
== History ==
Techniques to model [[Business process|business processes]], such as
In the 1990s, the term ''[[
In
== 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]].
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.
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 objectives of business process modeling may include (compare: Association of Business Process Management Professionals (ABPMP)<ref name="EABPM4" /> <sup>(Chapter 3.1.2 Process characteristics and properties) ← automatic translation from German</sup>):
* Company business process documentation
** to gain knowledge of the business processes
**
**
**
** to provide an external framework for the
** to meet
** to gain competitive advantages
**
**
**
** to train or familiarize employees
**
**
*
** to increase process speed
** to reduce cycle time
** to increase quality
**
*
**
** to develop alternative processes
** to introduce new organizational structures
** to outsource company tasks
** to redesign
*
** to support
** to
**
*
* [[Modularity|Modularization]] of company processes
* [[Benchmarking]]
* Performing [[activity-based costing]] and [[
**
**
* Finding the [[best practice]]
* Accompanying organizational changes
** such as the sale or partial sale
** such as
** such as
* Participation in competitions
== 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:
*
* 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" /> <sup>(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German</sup> with the objective of a [[vulnerability assessment]]<ref name="GADATSCH4" /> <sup>(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German</sup>, ''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''
* Continuous ''process management'', as "planning, implementation and control of processes geared towards sustainability"<ref name="ROSEMANN4" /> <sup>(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German</sup>
* ''Certifications'' according to [[ISO 9001|ISO/IEC 9001]] (or [[ISO 14000|ISO/IEC 14001]], [[ISO/IEC 27001]], etc.)
* [[
* [[Knowledge management]] with the "aim of increasing transparency about the company's knowledge resource in order to improve the process of identifying, acquiring, utilizing, developing and distributing knowledge"<ref name="ROSEMANN4" /> <sup>(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German</sup>
* ''Selection'' of [[Enterprise resource planning|ERP]] software, which "often documents its functionality in the form of (software-specific) reference models, so that it makes sense to also use a comparison of the company-specific process models with these software-specific models for software selection"<ref name=" * Model-based ''customization'', i.e. "the configuration of commercial off-the-shelf software" often by means of "parameterization of the software through configuration of reference models"<ref name="
* 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="
* Workflow management, for which the process models are "the basis for the creation of instantiable workflow models"<ref name="
* 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="
=== Business process re-engineering (BPR) ===
[[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> <sup>(Part I: A Framework For Process Innovation, Chapter: Introduction)</sup>, [[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.
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. ... 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" /> <sup>(Chapter 6.2.1 Objectives and concept) ← automatic translation from German</sup>
Thomas H. Davenport's high-level approach to BPR consists of:
# Identifying Process for Innovation
# Identifying Change Levers
Line 136 ⟶ 138:
=== 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)]]
==== General standard requirements for management systems with regard to processes ====
{| class="wikitable"
!
Clause 4.4 Quality management system and
!
Clause 4.4. Environmental management systems
!
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><sup>,</sup> <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><sup>,</sup> <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:
* Determine required inputs and expected outputs.
* Determine the sequence and interaction
* Define criteria and
* Determine the resources needed
* Assign the responsibilities and authorities
* Address the risks and opportunities
* Evaluate
* Improve
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
==== 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").
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.
''Demand'' in clause "7.5.2. Creating and updating"
* 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 availability when and where needed.
* To ensure protection against loss of confidentiality, improper use, or data loss.
* To consider distribution, access, retrieval, and use.
* Consider filing, storage, and preservation, including readability.
* To monitor changes (e.g., version control).
* Consider further storage and disposition.
Based on the standard requirements,
* To determine and
* To
* 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="
For the '''total cycle time''' (TCT), Hermann J. Schmelzer and Wolfgang Sesselmann list the following key features:<ref name="SCHMELZER4" /> <sup>(Chapter 6.3.2 Total Cycle Time (TCT)) ← automatic translation from German</sup>
* Identify process flow barriers.
* Eliminate barriers and substitute processes
* Measure the effects of barrier removal
* Comparison of
Business process modeling for TCT must document barriers, their 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="SCHMELZER4" /> <sup>(Chapter 6.3.3 KAIZEN) ← automatic translation from German</sup>
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=" === 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
* 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 ====
* Define relevant business process modeling ''applications'' based on the [[business model]] and its [[value chain]] position.
* 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]].
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" /> <sup>(Chapter 4.6 The resource-based view) ← automatic translation from German</sup> 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" /><sup>(Chapter 4.7 Combination of views) ← automatic translation from German</sup> 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 ====
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" /> <sup>(Chapter 4 Process analysis) ← automatic translation from German</sup>
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" /> <sup>(Chapter 6.2.2 Critical assessment of the BPR) ← automatic translation from German</sup>
[[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="
[[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''
* Enumeration of the main processes,
* Definition of the process boundaries,
* Determining
* Analysis of
* Determining the political and cultural significance of the process<ref name="BECKER-
* ''Management processes'' govern company operations. Typical processes include corporate governance and [[strategic management]], defining corporate objectives and monitoring their achievement.
* ''
* ''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 ====
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.).
*
* 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]]
* "
* "
* "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" /> <sup>(Chapter 2.4.3 Process map) ← automatic translation from German</sup>
=== Definition of business processes ===
[[File:VAC-production-company3.png|thumb|A definition of product development]]
The definition of business processes often
* Fulfill their own market requirements,
* Operate largely autonomously
* Contribute to the [[
For the company
* Have a strong external impact,
*
* Offer the greatest potential for business process optimization
[[File:
Each business process should be independent,
The definition of a business process includes:
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-
[[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-
''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-
=== 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
A
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="
=== Assigning the process responsibility ===
[[File:Pyramid-of-process-responsibility.png|thumb|Sample for a pyramid of process responsibility]]
Complete
=== Modeling business process ===
==== Design of the process chains ====
[[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
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-
* The project's creativity suffers because old structures and processes may be uncritically adopted in downstream target modeling.
* 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" /> <sup>(Chapter 5.1 Intention of as-is modeling) ← automatic translation from German</sup>
* 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.
Other advantages can also be found, such as
* 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" /> <sup>(Chapter 6.2.3 Capturing and documenting ''to be'' models )</sup>
They also list five basic principles proven effective in creating ''to be'' models:
* Parallel processing of subprocesses and activities is preferable to sequential processing for optimization.
* One person or group should consistently develop each subprocess for optimal model quality.
* Self-monitoring of individual subprocesses and activities reduces quality assurance costs.
* Each process should have at least one internal customer to improve customer awareness and process performance assessment.
* Consider learning effects when introducing target processes; this enhances employee awareness of value creation.
The business process model, created by
==== Sub-processes ====
; Delimitation
[[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]]
The first image shows
The second image shows
; Utilization
A business process
; Workflow
A [[workflow]]
==== 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'' 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''.
; 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]]
The image's ''function allocation diagram''
==== 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
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="
For Otto K. Ferstl and Elmar J. Sinz
Master data can be, for example:
* The [[Organizational structure|business
* The
* The [[
* The [[policy]] for this process
* The [[risk]] that occurs in a process
*
*
* The IT
* The milestone
* etc.
Depending on
; Artifact-centric business process
The [[artifact-centric business process model]]
====Integration of external documents and IT-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.
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.
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
''Ansgar Schwegmann and Michael Laske'' explain: "A consolidation of the models of different modeling complexes is necessary in order to obtain an integrated ... model."<ref name="SCHWEGMANN-LASKE4" /> <sup>(Chapter 5.2.4 Model consolidation) ← automatic translation from German</sup> 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 447 ⟶ 475:
* "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. ... Colour coding, for example, can also be used to differentiate between associated organizational units."<ref name="SCHWEGMANN-
=== Process chaining and control flow patterns ===
[[File:BPMN-Modale-
=== Process interfaces ===
Process interfaces are defined in order to
* 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
* Represent a business process
* Represent
* 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:
* 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.
==== Adaptation of process models ====
In business process management, process flows are regularly reviewed and optimized
== Representation type and notation ==
In practice, combinations of ''informal'', ''semiformal'', and ''formal'' models are common: ''informal''
=== Modelling techniques ===
* 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.
* [[Event-driven process chain]] (EPC), proposed in 1992 by a working group led by August-Wilhelm Scheer
* ''Value-added chain diagram'' ([[:de:Wertschöpfungskettendiagramm|VAD]], visualizing high-level processes)
* [[Carl Adam Petri]] developed the [[Petri net]] in 1962.
* Follow-up plans, such as a [[Flowchart]], proposed in 1997 by Fischermanns and Liebelt
* 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
* [[Unified Modelling Language]] (UML), proposed in 1996 by [[Grady Booch]], [[Ivar Jacobson]], and [[James Rumbaugh]], is continuously revised
* ICAM
* Pablo Iacub and Leonardo Mayo created [[Formalized Administrative Notation (FAN)]]
* [[Harbarian process modeling]] (HPM)
* [[BPEL|Business Process Execution Language]] (BPEL), an XML-based language
* Turtle diagram (also turtle method, turtle model, 8W method)
Furthermore:
* Professor [[:de:Hermann Krallmann|''Hermann Krallmann'']] of the TU Berlin's Systems Analysis Department proposed ''Communication structure analysis'' in 1989.
* ''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>)
* 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 567 ⟶ 602:
=== 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="
=== 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="
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>
* [[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.
* [[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="
* 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:
A [[business reference model]]
The most familiar business reference model is
=== Business process integration ===
[[File:
A business model,
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="
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="
=== Business process re-engineering ===
[[File:
[[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 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 management===
Change management programs
====Adaptation of process models====
In business process management, process flows are regularly reviewed and
== See also ==
{{Portal|Business and economics
}} * [[Business architecture]]
* [[Business Model Canvas]]
Line 631 ⟶ 671:
{{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
* {{cite journal |
* 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 645 ⟶ 685:
== External links ==
* {{Commons category-inline}}
{{Software engineering}}{{Systems Engineering}}<nowiki>{{|bot=InternetArchiveBot |fix-attempted=yes}}</nowiki>
{{DEFAULTSORT:Business Process Modelling}}
| |||