Content deleted Content added
rm automated translation as unintelligible |
m clean up spacing around commas and other punctuation, replaced: ,and → , and |
||
| (48 intermediate revisions by 34 users not shown) | |||
Line 1:
{{Short description|Activity of representing processes of an enterprise}}
{{Multiple issues|
{{Copy edit|date=March 2024}}
{{Very long|date=March 2024}}
{{Technical|date=March 2024}}
{{Overly detailed|date=March 2024}}
}}
[[File:BPMN-AProcessWithNormalFlow.svg|alt=|thumb|400x400px|
'''Business process modeling''' ('''BPM''') 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 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]].
▲[[File:BPMN-AProcessWithNormalFlow.svg|alt=|thumb|400x400px|Example of business process modeling of a process with a normal flow with the [[Business Process Model and Notation]]]]
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
* Process modeling : Creating visual or structured representations of business processes to better understand how they work.
*
*
*
*
However,
The focus of business process modeling is on the [[#Representation type and notation|representation]] of the flow of [[Action (philosophy)|actions (activities)]], according to
But also other [[Quality (philosophy)|qualities]] (facts) such as [[data]] and [[business object]]s (as
The term ''
According to
Business process modeling is also a central aspect of holistic
[[File:Core_process_(quality_management).gif|thumb|Typical breakdown of a '''process map''' into management, core and support processes]]
According to the
*
*
*
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"/> <sup>(Chapter 6.2.1 Objectives and concept) ← automatic translation from German,</sup>
If the ''
== History ==
Techniques to model business
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,
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
== Objectives
[[File:Influencing-factors-on-the-business-process-model.png|thumb|Influencing factors on the business process model]]
The objective of business process
Business process modeling typically begins with determining the environmental requirements: First, the [[goal]] of the modeling ([[#Applications of business process modeling|applications of business process modeling]]) must be determined. Business process models are now often used in a multifunctional way (see above). Second the model addressees must be determined, as the properties of the model to be created must meet their requirements. This is followed by the determination of the business processes to be modeled.
The qualities of the business process that are to be
*
** to gain knowledge of the business processes
** to map business unit(s) with the applicable regulations
Line 70 ⟶ 78:
** to avoid loss of knowledge (e.g. due to staff leaving)
** to support quality and environmental management
*
** to increase process speed
** to reduce cycle time
** to increase quality
** to reduce costs, such as labor, materials, scrap, or capital costs
*
** to support the analysis of the current situation
** to develop alternative processes
** to introduce new organizational structures
** to outsource company tasks
** to redesign, streamline, or improve company processes (e.g. with the help of the [[Capability Maturity Model|CMM]])
*
** to support a ''software evaluation''
** to support the customizing of [[commercial off-the-shelf]] software
** to introduce automation or IT support
*
* [[Modularity|
* [[
*
** 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
*
*
** 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
*
== 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''
* Organizational ''documentation'', with the
* Process-oriented ''re-organization'', both in the sense of
* Continuous ''process management'', as
* ''Certifications'' according to DIN [[ISO 9001|ISO/IEC 9001]] (or also according to [[ISO 14000|ISO/IEC 14001]], [[ISO/IEC 27001]] etc.)
* [[Benchmarking]], defined as
* [[Knowledge management]] with the
* ''Selection'' of [[Enterprise resource planning|ERP]] software, which
* Model-based ''customization'', i.e.
*
*
*
=== Business process re-engineering (BPR) ===
Within an extensive research program initiated in 1984 titled "Management in the 1990s" at [[Massachusetts Institute of Technology|MIT]], the approach of ''process re-engineering'' emerged in the early 1990s. The research program was designed to explore the impact of information technology on the way organizations would be able to survive and thrive in the competitive environment of the 1990s and beyond. In the final report, N. Venkat Venkatraman<ref>N. Venkat Venkatraman: ''IT-Induced Business Reconfiguration'' in M. S. Scott Morton (publisher): ''The Corporation of the 1990s: Information Technology and Organizational Transformation'', 1st edition, Oxford University Press 1991, ISBN 978-0-19-506358-5</ref> summarizes the result as follows: The greatest increases in productivity can be achieved when new processes are planned in parallel with information technologies.
This approach was taken up by [[Thomas H. Davenport]]<ref name="DAVENPORT">[[Thomas H. Davenport]]: ''Process Innovation: Reengineering Work through Information Technology'', Harvard Business Press, Boston 1993, ISBN 978-0-87584-366-7</ref> <sup>(Part I: A Framework For Process Innovation, Chapter: Introduction)</sup> as well as [[Michael Martin Hammer|Michael M. Hammer]] and [[James A. Champy]]<ref name="HAMMER-CHAMPY">[[Michael Martin Hammer|Michael M. Hammer]], [[James A. Champy]]: ''Reengineering the Corporation: A Manifesto for Business Revolution'', Harper Business, New York 1993, ISBN 978-0-88730-640-2</ref> and developed it into
Business process re-engineering 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 high-level approach to BPR according to
# Identifying Process for Innovation
# Identifying Change Levers
Line 128 ⟶ 136:
=== Certification of the management system according to ISO ===
[[File:ISO_Logo_(Red_square).svg|thumb|International Organization for Standardization (''ISO'' and official logo are registered trademarks)]]
With
==== General standard requirements for management systems with regard to processes ====
In the
{| class="wikitable"
! ISO/IEC 9001:2015
Line 141 ⟶ 149:
|}
Each of these standards requires the organization to establish, implement, maintain and continually improve an appropriate management system
In the definition of the standard requirements for the ''processes needed and their interactions'',
*
*
*
*
*
*
*
*
In addition, clause 4.4.2 of the
detailed requirements with regard to processes:
*
*
The
==== Specific standard requirements for management systems with regard to documented information ====
In the standards
The standard requirements of ISO/IEC 9001 used here as an example ''include'' in clause "7.5.1. General"
*
*
''
*
*
* Review and approval
*
*
*
*
*
*
Based on the standard requirements,
=== Business process optimization ===
For the '''total cycle time''' (TCT)
* Identify barriers that hinder the process flow
* Eliminate barriers and substitute processes
* Measure the effects of barrier removal
* Comparison of the measured variables with the targets
Consequently, business process modeling for TCT must support adequate documentation of barriers, barrier handling, and measurement.
=== 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
''Martin Kugler'' lists the following requirements for business process modeling in this context:<ref name="KUGLER">Martin Kugler: ''Supply Chain Management und Customer Relationship Management - Prozessmodellierung für Extended Enterprises'' in Jörg Becker, Martin Kugler and Michael Rosemamm (publisher): ''Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung'', 2. corrected and expanded edition, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7</ref> <sup>(Chapter 14.2.1 Requirements for inter-company business process modeling) ← automatic translation from German</sup>
* Employees from different companies must comprehend business process models, highlighting the critical importance of familiarity with modeling techniques. Acceptance of business process modeling is bolstered by the simplicity of representation. Models should be clear, easy to understand, and as self-explanatory as possible. Standardization of the presentation of inter-company business process models across different companies is essential to ensure consistent comprehensibility and acceptance, particularly given the varied representations used within different organizations. It is imperative to employ an industry-neutral modeling technique to accommodate the diverse backgrounds of companies along the value chain (supplier, manufacturer, retailer, customer), which typically span different industries.
== Topics ==
Line 211 ⟶ 216:
==== Define framework conditions ====
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 ''
* 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:
▲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"/> <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-MEISE"/><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, with a view to resource optimization or in a balanced manner.
==== Identify business processes ====
The effort involved in analysing the as-is processes is repeatedly criticised in the literature, especially by proponents of
''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
[[File:Core_process_(quality_management).gif|thumb|Typical breakdown of a '''process map''' into management, core and support processes]]
==== Structure business processes
''Timo Füermann'' explains:
[[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:
*
* 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
The structuring of business processes generally begins with a distinction between
* ''Management processes'' govern the operation of a company. Typical management processes include
* ''Core processes'' constitute the [[core business]] and create the primary value stream. Typical operational processes are [[purchasing]], [[manufacturing]], [[marketing]], and [[sales]]. They generate visible, direct customer benefits.
* ''Support processes'' provide and manage operational resources. They support the core and management processes by ensuring the smooth running of business operations. Examples include [[accounting]], [[recruitment]], and [[technical support]].
Line 247 ⟶ 250:
==== Structure core processes based on the strategy for the long-term success of business process modeling ====
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 ''
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. "
In a differentiated view without a clear focus on the market view or the resource view, the core business processes are typically divided into CRM, PLM and SCM.
* CRM (
* PLM ([[
* SCM ([[
[[File:Process-map-for-a-value-driven-company.png|thumb|Example of a '''process map''' for a value-driven company]]
However, other approaches to structuring core business processes are also common, for example from the perspective of customers, products or sales channels.
* "Customers" describes the business processes that can be assigned to specific customer groups (e.g. private customer, business customer, investor, institutional customer)
* "Products" describes the business processes that are product-specific (e.g. current account, securities account, loan, issue)
* "Sales channels"
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:
=== Definition of business processes ===
[[File:VAC-production-company3.png|thumb|
The definition of business processes often begins with the company's core processes because they
*
*
*
*
*
*
[[File:VAC CRM Sales order-processing-and-project management.png|thumb|
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
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, ...)?
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" /> <sup>(Chapter 4.15 Influencing the design of the regulatory framework) ← automatic translation from German</sup> 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]]
==== 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:
''Jörg Becker and Volker Meise'' state the following about individual process identification:
The result of the definition of the business processes is usually a rough structure of the business processes as a
=== Further structuring of business processes ===
[[File:VAC-production-company4.png|thumb|Example of the decomposition of a business process into sub-processes
The rough structure of the business processes created so far will now be decomposed
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 299 ⟶ 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,
=== 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
=== Modeling business process ===
Line 312 ⟶ 317:
;''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 ''
;''As-is'' modeling
Ansgar Schwegmann and Michael Laske explain:
The following disadvantages speak against ''as is'' modeling:
*
*
These arguments weigh particularly heavily if
* Modeling the current situation is the basis for identifying weaknesses and potential for improvement
* Knowledge of the current state is a prerequisite for developing migration strategies to the target state
Line 333 ⟶ 338:
* The ''as is'' model is suitable for supporting certification of the management system
* The ''as is'' model can serve as a basis for organizational documentation (written rules, specifications and regulations of the organization, ...)
* The requirements for
* Key figures can be collected on the basis of the ''as is'' model in order to be compared with the key figures achieved after a reorganization and to measure the success of the measures.
;''To be'' modeling
)</sup>
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
* The development of a sub-process should be carried out as consistently as possible by one person or group
* Self-monitoring should be made possible for individual sub-processes and individual activities during processing
* If not otherwise possible, at least one internal customer/user should be defined for each process
* Learning effects that arise during the introduction of the target processes should be taken into account
The business process model created by ''as is modeling'' or ''to be modeling'' consists of:
Line 354 ⟶ 359:
[[File:VAC Process sales pipeline.png|thumb|Breakdown of the business process ''Process sales pipeline'' into sub-processes based on phases]]
In addition, some German-speaking schools of
[[File:FT-Excerpt-of-company-functions.png|thumb|Function tree with
For example, in
The first image shows as a value chain diagram how the business process ''Edit sales pipeline'' has been broken down into ''sub-processes'' (in the sense of
The second image shows an excerpt of typical ''functions'' (in the sense of delimited ''corporate function''/
;Utilization
A business process can be decomposed into sub-processes until further decomposition is no longer meaningful/possible (smallest meaningful sub-process = ''elementary process''). Usually, all levels of decomposition of a business process are documented in the same methodology: Process symbols. The process symbols used when modeling one level of decomposition then usually refer to the sub-processes of the next level until the level of ''elementary processes'' is reached. Value chain diagrams are often used to
;Workflow
A [[workflow]] is a
==== Functions (''Tasks'') ====
Line 377 ⟶ 382:
;Delimitation
The term ''functions'' is often used synonymously for a delimited ''corporate function''/
;Utilization
The graphical elements used at the level of elementary processes then describe the (temporal-logical) sequence with the help of functions (''tasks''). The sequence of the functions (''tasks'') within the ''elementary processes'' is determined by their logical linking with each other (by [[Logical connective|logical operators]] or [[Business Process Model and Notation#Gateway|Gateways]]), provided it is not already specified by input/output relationships or
[[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]]
Furthermore, the functions (''tasks'') can be supplemented with graphical elements to describe inputs, outputs, systems, roles, etc. with the aim of improving the accuracy of the description and/or increasing the number of details. However, these additions quickly make the ''model'' confusing. To resolve the contradiction between accuracy of description and clarity, there are two main solutions: Outsourcing the additional graphical elements for describing inputs, outputs, systems, roles, etc. to a [[Function Allocation Diagram]] (FAD) or selectively showing/hiding these elements depending on the question/application.
The ''function allocation diagram'' shown in the image illustrates the addition of graphical elements for the description of inputs, outputs, systems, roles, etc. to functions (''tasks'') very well.
==== Master data (
The term ''[[master data]]'' is neither defined by [[The Open Group]] ([[The Open Group Architecture Framework]], TOGAF) or [[John Zachman|John A. Zachman]] (
For
For
For
Master data can be, for example:
*
*
*
*
*
*
*
*
*
* etc.
By adding master data to the business process modeling, the same business process model can be used for different ''
Depending on how much value is given to master data in business process modeling, it is still possible to embed the master data in the process model without negatively affecting the readability of the model or the master data should be outsourced to a separate view, e.g. [[Function Allocation Diagram]]s.
Line 419 ⟶ 425:
====Integration of external documents and IT-systems====
The integration of external [[document]]s and
For
* short response times of the
* Legally compliant documents of the
* Integrating graphical
If all relevant objects of the ''knowledge database'' and / or documents of the ''rule framework'' are connected to the processes, the end users have
The direct connection of external systems can also be used to integrate current measurement results or system statuses into the processes (and, for example, to display the current operating status of the processes), to display [[Software widget|widget]]s and show output from external systems or to jump to external systems and initiate a transaction there with a preconfigured dialog.
Further connections to external systems can be used, for example, for [[
=== Model consolidation ===
This is about
''Ansgar Schwegmann and Michael Laske'' explain:
*
*
*
*
*
*
=== Process chaining and control flow patterns ===
[[File:BPMN-Modale-Prozessverkettung AND.png|thumb|Modal chaining (''necessary'' finalization of sub-processes 1a, 1b and 1c before the start of sub-process 2) in an example using BPMN tools]]
The chaining of the sub-processes with each other and the chaining of the functions (''tasks'') in the sub-processes is modeled using
Material details of the chaining (What does the predecessor deliver to the successor?) are specified in the process interfaces
=== Process interfaces ===
Process interfaces are defined in order to
*
*
As a rule, this '''what''' and its structure is determined by the requirements in the subsequent process.
Process interfaces represent the exit from the current business process/sub-process and the entry into the subsequent business process/sub-process.
[[File:Process-flow-with-interface-to-service-process.png|thumb|
Process interfaces are therefore description elements for linking processes section by section. A process interface can
*
*
*
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:
*
*
*
*
*
In real terms, the transferred inputs/outputs are often data or information, but any other
=== Business process management ===
See article
In order to put improved business processes into practice, [[change management]] programs are usually required. With advances in software design, the vision of BPM models being fully executable (enabling simulations and round-trip engineering) is getting closer to reality.
==== Adaptation of process models ====
In
== Representation type and notation ==
In practice, combinations of ''informal'', ''semiformal'' and ''formal'' models are common: ''informal'' textual descriptions for explanation, ''semiformal'' graphical representation for [[Visualization (graphics)|visualization]], and ''formal language'' representation to support [[simulation]] and transfer into executable code.
=== Modelling techniques ===
There are various standards for notations; the most common are:
*
* [[Event-driven process chain]] (EPC), proposed in 1992 by a working group under the leadership of
* ''Value-added chain diagram'' ([
* [[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 495 ⟶ 501:
* [[Subject-oriented business process management]] (S-BPM)
* [[Cognition enhanced Natural language Information Analysis Method]] (CogNIAM)
*
* [[Unified Modelling Language]] (UML), proposed in 1996 by [[Grady Booch]], [[Ivar Jacobson]], and [[James Rumbaugh]], continuously revised under the aegis of the
*
* [[Formalized Administrative Notation (FAN)]], created by Pablo Iacub and Leonardo Mayo in the 1990s
* [[Harbarian process modeling]] (HPM)
* [[BPEL|Business Process Execution Language]] (BPEL), an XML-based language developed in 2002 by [[Organization for the Advancement of Structured Information Standards|OASIS]] for the description and automation of business processes
*
Furthermore:
* ''Communication structure analysis'', proposed in 1989 by Prof. [
* ''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>{{
* 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>{{
* ''Semantic object model'' ([
* [
* [[Data-flow diagram]], a way of representing a flow of data through a process or a system
* [[Swimlane]] technique, mainly known through [[BPMN]] but also
* [
* [[State diagram]], used to describe the behavior of systems
Line 561 ⟶ 567:
=== Tools ===
Business process modelling tools provide business users with the ability to model their business processes, implement and execute those models, and refine the models based on as-executed data. As a result, business process modelling tools can provide transparency into business processes, as well as the centralization of corporate business process models and execution metrics.<ref name="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
</ref> Business process modelling tools should not be confused with business process automation systems
=== 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="NIH07"/> This component is often referenced as the ''engine'' of the BPM suite.
Programming languages that are being introduced for BPM include:<ref name="bpmfaq">{{cite web |title=Business Process Modelling FAQ |url=http://www.BPModeling.com/faq/ |access-date=2008-11-02 |url-status=dead |archive-url=https://web.archive.org/web/20081109082206/http://www.bpmodeling.com/faq/ |archive-date=2008-11-09
* [[Business Process Execution Language]] (
* [[Web Services Choreography Description Language]] ([[WS-CDL]]).
* [[XML Process Definition Language]] ([[XPDL]]),
Line 578 ⟶ 584:
=== 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="NIH07" />
* [[Use case diagram]]s created by
*
== Related concepts ==
=== Business reference model ===
[[File:Government Business Reference Model.svg|thumb|360px|Example of the US Federal Government Business Reference Model<ref>FEA (2005) [https://www.archives.gov/records-mgmt/pdf/rm-profile.pdf FEA Records Management Profile, Version 1.0]. December 15, 2005.</ref>]]
A [[business reference model]] is a reference model, concentrating on the functional and organizational aspects of an [[Business|enterprise]], [[Tertiary sector of the economy|service organization]], or [[government agency]]. In general, a [[reference model]] is a model of something that embodies the basic goal or idea of something and can then be looked at as a reference for various purposes. A business reference model is a means to describe the business operations of an organization, independent of the organizational structure that
The most familiar business reference model is the Business Reference Model of the US federal government. That model is a [[function model|function-driven]] framework for describing the business operations of the federal government independent of the agencies that perform them. The Business Reference Model provides an organized, hierarchical construct for describing the day-to-day business operations of the federal government. While many models exist for describing organizations – [[organizational chart]]s, ___location maps, etc. – this model presents the business using a functionally driven approach.<ref>[https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/fea_docs/FEA_CRM_v23_Final_Oct_2007_Revised.pdf FEA Consolidated Reference Model Document] {{Webarchive|url=https://web.archive.org/web/20101011082020/http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_CRM_v23_Final_Oct_2007_Revised.pdf |date=2010-10-11
=== Business process integration ===
[[File:Process and data modeling.svg|thumb|320px|Example of the interaction between business process and data models<ref name="SS93"/>]]
A
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
=== Business process re-engineering ===
[[File:Business Process Reengineering Cycle.svg|thumb|Diagram of the business process reengineering cycle]]
[[Business process reengineering]] (BPR) aims to improve the [[Business efficiency|efficiency]] and effectiveness of the
Business process re-engineering (BPR) began as a private sector technique to help organizations fundamentally rethink how they do their work. A key stimulus for re-engineering has been the development and deployment of sophisticated information systems and networks. Leading organizations use this technology to support innovative business processes, rather than refining current ways of doing work.<ref name="GAO97">[https://govinfo.library.unt.edu/npr/library/gao/bprag.pdf Business Process Reengineering Assessment Guide] {{Webarchive|url=https://web.archive.org/web/20170218131136/http://www.gao.gov/special.pubs/bprag/bprag.pdf |date=2017-02-18
===Business process management===
▲[[Change management]] programs are typically involved to put any improved business processes into practice. With advances in software design, the vision of BPM models becoming fully executable (and capable of simulations and round-trip engineering) is coming closer to reality.
====Adaptation of process models====
In
== See also ==
{{Portal|Business and economics}}
* [[Business architecture]]
* [[Business Model Canvas]]
* [[Business plan]]
* [[Business process mapping]]
* [[Capability Maturity Model Integration]]
* [[DRAKON|Drakon-chart]]
Line 631 ⟶ 633:
== Further reading ==
<!-- This section should only contain notable publications about BPM in general, and not about specialized BPM methodologies.-->
* Aguilar-Saven, Ruth Sara. "[http://secure.com.sg/courses/ICT353/Session_Collateral/TOP_04_ART_03_ARTICLE_AGUILAR_Biz_Proc_Modelling.pdf Business process modelling: Review and framework] {{Webarchive|url=https://web.archive.org/web/20200807172900/http://secure.com.sg/courses/ICT353/Session_Collateral/TOP_04_ART_03_ARTICLE_AGUILAR_Biz_Proc_Modelling.pdf |date=2020-08-07 }}." ''International Journal of production economics'' 90.2 (2004): 129–149.
* {{cite journal|doi=10.1016/j.scico.2008.01.002 |title=The importance of business process modeling in software systems design |journal=Science of Computer Programming |volume=71 |pages=73–87 |year=2008 |last1=Barjis |first1=Joseph |doi-access=free
* 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 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
== External links ==
Line 648 ⟶ 650:
{{Systems Engineering}}
{{|bot=InternetArchiveBot |fix-attempted=yes
{{DEFAULTSORT:Business Process Modelling}}
[[Category:Business process modelling| ]]
| |||