Business process modeling

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 processes of an enterprise (i.e. modeling them), so that the current business processes may be analyzed, applied securely and consistently, improved, and automated.

Business analysts typically perform BPM, collaborating with subject matter experts to accurately model processes. It's primarily used in business process management, software development, and systems engineering.

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

Overview

The five disciplines of business process management and their relationships

The Association of Business Process Management Professionals (ABPMP) identifies business process modeling as one of five key Business Process Management (BPM) disciplines. ^{(Chapter 1.4 CBOK® structure) ← automatic translation from German} The five disciplines are:

• 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 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 Analysis of business activities) and process design specifications for to-be processes (see Business process reengineering and Business process optimization).

The focus of business process modeling is on the representation of the flow of 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." ^{(Chapter 2.1 Differences between processes and business processes) ← automatic translation from German}

But also other qualities (facts) such as data and business objects (as inputs/outputs, formal organizations and roles (responsible/accountable/consulted/informed persons, see RACI), resources and IT-systems as well as guidelines/instructions (work equipment), requirements, 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."^{(Chapter 2.4 Views of process modeling) ← automatic translation from German} There is also a brief comparison of the view concepts of five relevant German-speaking schools of business informatics: 1) August W. Scheer, 2) Hubert Österle, 3) Otto K. Ferstl and Elmar J. Sinz, 4) Hermann Gehring and 5) Andreas Gadatsch.

The term views (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." ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

According to Andreas Gadatsch, business process modeling is understood as a part of business process management alongside process definition and process management. ^{(Chapter 1.1 Process management) ← automatic translation from German}

Business process modeling is central to holistic company mapping, which also maps the corporate mission, corporate policy and corporate governance, organizational structure, process organization, application architecture, regulations, interest groups, and the market.

Typical breakdown of a process map into management, core and support processes

The European Association of Business Process Management (EABPM) identifies three types of end-to-end business processes:

• Leadership processes;
• Execution processes and
• Support processes. ^{(Chapter 2.4 Process types) ← automatic translation from German}

These three process types can be identified in every company and are used in practice almost without exception as the top level for structuring business process models. Instead the term leadership processes the term management processes is typically used. Instead of the term execution processes the term core processes has become widely accepted. ^{(Chapter 6.2.1 Objectives and concept) ← automatic translation from German, (Chapter 1.3 The concept of process) ← automatic translation from German, (Chapter 4.12.2 Differentiation between core and support objectives) ← automatic translation from German, (Chapter 6.2.2 Identification and rough draft) ← automatic translation from German}

If the core processes are organized at the next level in supply chain management (SCM), customer relationship management (CRM), and product lifecycle management (PLM), standard models like the SCOR model can be integrated into business process modeling.

History

Techniques to model business processes, such as flow charts, functional flow block diagrams, control flow diagrams, Gantt charts, PERT diagrams, and IDEF, emerged in the 20th century. Gantt charts appeared around 1899, flow charts in the 1920s, functional flow block diagrams and PERT in the 1950s, and data-flow diagrams and IDEF in the 1970s. Modern methods include the Unified Modeling Language and Business Process Model and Notation. These represent only a fraction of the methodologies used to document business processes. The term business process modeling was coined in the 1960s in systems engineering by S. Williams in his 1967 article, "Business Process Modelling Improves Administrative Control". Williams suggested applying techniques for understanding physical control systems to business processes. The term didn't become popular until the 1990s.

In the 1990s, the term process became a new productivity paradigm. Companies were encouraged to think in processes instead of functions and procedures. Process thinking looks at the chain of events in the company from purchase to supply, from order retrieval to sales, etc. The traditional modeling tools were developed to illustrate time and cost, while modern tools focus on cross-functional activities. These cross-functional activities have increased significantly in number and importance, due to the growth of complexity and dependence. New methodologies include business process redesign, business process innovation, business process management, integrated business planning, among others, all "aiming at improving processes across the traditional functions that comprise a company".

In software engineering, business process modeling contrasts with software process modeling, focusing on software development practices. Early 1990s modeling techniques illustrating business processes were consolidated as 'business process modeling languages'. The Object Oriented approach considered it essential for specifying business application systems. Business process modeling underpinned new methodologies supporting data collection, data flow analysis, process flow diagrams, and reporting. Around 1995, the first visual business process modeling and implementation tools appeared.

Objectives

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, traceability, integrity), such as those from quality management, information security management, or data protection.

Business process modeling starts by determining environmental requirements: First, define the modeling goal (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 relationships, but also formal organization, inputs, outputs, resources, information, media, transactions, events, states, conditions, operations, and methods.

The objectives of business process modeling may include (compare: Association of Business Process Management Professionals (ABPMP) ^{(Chapter 3.1.2 Process characteristics and properties) ← automatic translation from German}):

• Company business process documentation
  • to gain knowledge of the business processes
  • To map business units to applicable regulations
  • Transfer business processes to other locations
  • Determine the requirements of new business activities.
  • to provide an external framework for the rules in procedures and work instructions
  • to meet business partner or association requirements (e.g., certifications)
  • to gain competitive advantages (e.g., in tenders)
  • To comply with legal regulations (e.g., for critical infrastructure operators, banks, or arms manufacturers)
  • To check standards and compliance.
  • To create a basis for communication and discussion
  • to train or familiarize employees
  • To avoid knowledge loss due to staff turnover.
  • To support quality and environmental management
• Process performance indicators: definition and monitoring.
  • to increase process speed
  • to reduce cycle time
  • to increase quality
  • Reduce costs, including labor, materials, scrap, and capital.
• Preparing and implementing business process optimization, usually starting with a current-situation analysis
  • To support analyzing the current situation
  • to develop alternative processes
  • to introduce new organizational structures
  • to outsource company tasks
  • to redesign or improve company processes (e.g., using the CMM)
• Preparing an information technology project
  • to support software evaluation and selection
  • to customize commercial off-the-shelf software
  • Introduce automation or IT support using a workflow management system.
• Interfaces and service-level agreements (SLAs)
• Modularization of company processes
• Benchmarking company parts, partners, and competitors
• Performing activity-based costing and simulations
  • To understand how the process reacts to different stressors or anticipated changes
  • Evaluate the effectiveness of business process optimization measures and compare alternatives.
• Finding the best practice
• Accompanying organizational changes
  • such as the sale or partial sale
  • such as acquiring or integrating companies or parts of companies
  • such as IT system or organizational structure changes.
• Participation in competitions like the European Foundation for Quality Management (EFQM).

Applications

Since business process modeling in itself makes no direct contribution to the financial success of a company, there is no motivation for business process modeling from the most important goal of a company, the intention to make a profit. The motivation of a company to engage in business process modeling therefore always results from the respective purpose. Michael Rosemann, Ansgar Schwegmann und Patrick Delfmann lists a number of purposes as motivation for business process modeling:

• Organizational documentation, with the "objective of increasing transparency about the processes in order to increase the efficiency of communication about the processes" ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German, (Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German} including the ability to create process templates to relocate or replicate business functions or the objective to create a complete company model
• Process-oriented re-organization, both in the sense of "(revolutionary) business process re-engineering and in the sense of continual (evolutionary) process improvement" ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German} with the objective of a vulnerability assessment ^{(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}, process optimization (e.g. by controlling and reducing total cycle time (TCT), through Kaizen, Six Sigma etc.) or process standardization
• Continuous process management, as "planning, implementation and control of processes geared towards sustainability" ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}
• Certifications according to ISO/IEC 9001 (or ISO/IEC 14001, ISO/IEC 27001, etc.)
• Benchmarking, defined as "comparison of company-specific structures and performance with selected internal or external references. In the context of process modeling, this can include the comparison of process models (structural benchmarking) or the comparison of process key figures" ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}
• 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" ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}
• Selection of 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" ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German,} < ^{(Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}
• 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" ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German, (Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}
• Software development, using the processes for "the description of the requirements for the software to be developed at a conceptual level as part of requirements engineering"^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German, (Chapter 3 The path to a process-oriented application landscape) ← automatic translation from German, (Chapter 2.5.4 Areas of application for process modeling in practice) ← automatic translation from German}
• Workflow management, for which the process models are "the basis for the creation of instantiable workflow models" ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}
• Simulation with the aim of "investigating the system behavior over time" and the "identification of weak points that would not be revealed by a pure model view" ^{(Chapter 3.2.1 Relevant perspectives on process models) ← automatic translation from German}

Business process re-engineering (BPR)

MIT's "Management in the 1990s" research program (1984) yielded the process re-engineering approach in the early 1990s. The program explored information technology's impact on organizational survival and success. Venkatraman summarized the final report: The greatest increases in productivity can be achieved when new processes are planned in parallel with information technologies.

Thomas H. Davenport ^{(Part I: A Framework For Process Innovation, Chapter: Introduction)}, Michael M. Hammer, and James A. Champy 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." ^{(Chapter 6.2.1 Objectives and concept) ← automatic translation from German}

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

1. Identifying Process for Innovation
2. Identifying Change Levers
3. Developing Process Visions
4. Understanding Existing Processes
5. Designing and Prototyping the New Process

Certification of the management system according to ISO

International Organization for Standardization (ISO and official logo are registered trademarks)

ISO/IEC 27001:2022 standardizes management system requirements across major ISO standards, establishing a process-oriented approach.

General standard requirements for management systems with regard to processes

ISO/IEC 9001, ISO/IEC 14001, and ISO/IEC 27001 standards anchor this in Chapter 4.4.

ISO/IEC 9001:2015 Clause 4.4 Quality management system and processes	ISO/IEC 14001:2015 Clause 4.4. Environmental management systems	ISO/IEC 27001:2022 Clause 4.4 Information security management system

Each of these standards requires the organization to establish, implement, maintain and continually improve an appropriate management system "including the processes needed and their interactions".^{, ,}

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" 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 methods for effective operation and control, including monitoring, measurement, and performance indicators.
• Determine the resources needed
• Assign the responsibilities and authorities
• Address the risks and opportunities
• Evaluate and implement needed process changes for effective operation and control.
• 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

Documented information requirements for ISO management systems also apply to business process modeling.

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 improve required processes and their interactions
• To determine the necessary documented information and maintain its content
• 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. ^{(Chapter 6.3.1 Total Cycle Time (TCT), KAIZEN and Six Sigma in comparison) ← automatic translation from German}

For the total cycle time (TCT), Hermann J. Schmelzer and Wolfgang Sesselmann list the following key features: ^{(Chapter 6.3.2 Total Cycle Time (TCT)) ← automatic translation from German}

• Identify process flow barriers.
• Eliminate barriers and substitute processes
• Measure the effects of barrier removal
• Comparison of measured and target variables

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." ^{(Chapter 6.3.3 KAIZEN) ← automatic translation from German}

Six Sigma is designed to prevent errors and improve the 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)." ^{(Chapter 6.3.4 Six Sigma) ← automatic translation from German} For a reproducible measurement of process capability, precise knowledge of the business processes is required and business process modeling is a suitable tool for design for Six Sigma. Six Sigma, therefore, uses business process modeling according to SIPOC as an essential part of the methodology, and business process modeling using SIPOC has established itself as a standard tool for Six Sigma.

Inter-company business process modeling

The aim of inter-company business process modeling is to include the influences of external stakeholders in the analysis or to achieve inter-company comparability of business processes, e.g. to enable benchmarking.

Martin Kugler lists these requirements for business process modeling: ^{(Chapter 14.2.1 Requirements for inter-company business process modeling) ← automatic translation from German}

• 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

Analyzing business activities defines the framework for successful business process modeling. This is the company's starting point.

• 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." ^{(Chapter 4.6 The resource-based view) ← automatic translation from German} And further: "The alternative character initially formulated in the literature between the market-based and resource-based view has now given way to a differentiated perspective. The core competence approach is seen as an important contribution to the explanation of success potential, which is used alongside the existing, market-oriented approaches."^{(Chapter 4.7 Combination of views) ← automatic translation from German} Depending on the company's strategy, the process map will therefore be the business process models with a view to market development and to resource optimization in a balanced manner.

Identify business processes

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." ^{(Chapter 4 Process analysis) ← automatic translation from German}

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

Hermann J. Schmelzer and Wolfgang Sesselmann, on the other hand, discuss and evaluate the criticism levelled at the radical approach of business process re-engineering (BPR) in the literature and "recommend carrying out as-is analyses. A reorganisation must know the current weak points in order to be able to eliminate them. The results of the analyses also provide arguments as to why a process re-engineering is necessary. It is also important to know the initial situation for the transition from the current to the target state. However, the analysis effort should be kept within narrow limits. The results of the analyses should also not influence the redesign too strongly." ^{(Chapter 6.2.2 Critical assessment of the BPR) ← automatic translation from German}

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." ^{(Chapter 2.4 Creating the process map) ← automatic translation from German}

Example of a process map for a market-driven company

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

• Enumeration of the main processes,
• Definition of the process boundaries,
• Determining each process's strategic relevance
• Analysis of process improvement needs
• Determining the political and cultural significance of the process ^{(Chapter 4.10 Defining the process structure) ← automatic translation from German}

Business process structuring typically begins by distinguishing between management, core, and support processes.

• Management processes govern company operations. Typical processes include corporate governance and strategic management, defining corporate objectives and monitoring their achievement.
• Core processes form the core business and create the primary value stream. Typical operational processes include purchasing, manufacturing, marketing, and sales, generating direct customer benefits.
• Support processes manage operational resources, ensuring smooth business operations. They support core and management processes. Examples include accounting, recruitment, and technical support.

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

Core business processes typically comprise most of a company's identified processes, so further subdivision is common. Approaches vary by company type and activity, significantly influenced by the business process modeling application and long-term success strategy.

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

Without a clear market or resource focus, core business processes are typically divided into CRM, PLM, and SCM.

• CRM (customer relationship management) describes business processes for acquiring customers, creating quotations and orders, and providing support and maintenance.
• 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 stages to delivery to the customer, including installation and commissioning where applicable

Example of a process map for a value-driven company

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

• "Customers" describe business processes assigned to specific customer groups (e.g., private, business, investor, institutional customers).
• "Products" describes product-specific business processes (e.g., current account, securities account, loan, issue).
• "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." ^{(Chapter 2.4.3 Process map) ← automatic translation from German}

Definition of business processes

A definition of product development

The definition of business processes often starts with a company's core processes because they

• Fulfill their own market requirements,
• Operate largely autonomously from other business areas.
• Contribute to the business success of the company,

For the company

• Have a strong external impact,
• Easily distinguished from other business processes.
• Offer the greatest potential for business process optimization by improving process performance and productivity, and reducing costs.

A definition of customer relationship management

A business process should encompass a manageable number of subprocesses, while keeping the total number of business processes reasonable. Five to eight processes per business unit typically suffice.

Each business process should be independent, yet interlinked.

The definition of a business process includes: the desired outcome, the necessary activities, and the objects to be processed (orders, raw materials, purchases, products, etc.).

Corporate culture—whether embracing change or resistant to it—significantly impacts defining business processes. The ease or difficulty depends on key stakeholders, like department heads, supporting the effort. Effective communication is crucial.

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." ^{(Chapter 4.15 Influencing the design of the regulatory framework) ← automatic translation from German} In the event of considerable resistance, however, external knowledge can also be used to define the business processes.

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." ^{(Chapter 4.11 General process identification) ← automatic translation from German}

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

Defining business processes usually yields a rough value chain diagram.

Further structuring of business processes

Example of the decomposition of a business process into sub-processes – supplemented by milestones, business units, data objects and IT-systems

The business processes' structure will be decomposed into subprocesses. These subprocesses have their own attributes but contribute to the business process goal. This decomposition should reflect the application and long-term business process modeling strategy, continuing as long as subprocess tailoring improves implementation of the purpose and strategy.

A subprocess created this way uses a model to describe company procedures achieving operating goals. The model abstracts reality (or a target state), its form depending on its intended use.

Further sub-process decomposition may occur during business process modeling. If the process is a phased sequence, separated by milestones, phase decomposition is common. Transferring milestones to the next decomposition level improves understanding.

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

Assigning the process responsibility

Sample for a pyramid of process responsibility

Complete processes are handed to a responsible person or team. The process owner ensures success, sets the framework, and coordinates with other owners. They also manage inter-process communication to achieve overall goals.

Modeling business process

Design of the process chains

Business process documentation using a specific IT system and representation, such as graphical modeling, is called modeling. The resulting document is the business process model.

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, defineition of business processes and 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." ^{(Chapter 5.1 Intention of the as is modeling) ← automatic translation from German}

Disadvantages of as is modeling include:

• 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: ^{(Chapter 5.1 Intention of as-is modeling) ← automatic translation from German}

• Modeling the current situation identifies weaknesses and improvement potential.
• Knowing the current state is essential for developing migration strategies to the target state.
• Modeling the current state provides an overview of the existing situation, valuable for new and external project participants.
• As is modeling provides a starting point for training project participants in tools and methods.
• The as is model serves as a checklist for later target modeling, preventing overlooked issues.
• The as is models are useful starting points for target modeling if the target state closely resembles the current situation, at least in some areas.

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

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 as is or to be modeling, consists of:

Sub-processes

Delimitation

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 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 actions) and function (a delimited corporate function/activity area assigned to a corporate function owner).

Function tree with an excerpt of typical company actions, sales pipeline relevant functions marked

In August W. Scheer's ARIS, functions from the function view can be used as processes in the control view, and vice versa. This reuses defined processes or functions, but it also blurs the distinction between processes and functions, hindering clear separation for the ARIS user.

The first image shows the business process Edit sales pipeline as a value chain diagram, broken down into sub-processes representing the sequence of activities by phase.

The second image shows typical functions (delimited corporate function/activity areas assigned to a corporate function owner), structured by competence and responsibility. The corporate functions supporting the Edit sales pipeline business process are marked.

Utilization

A business process decomposes into sub-processes until further decomposition is meaningless (the smallest meaningful sub-process is an elementary process). All decomposition levels are usually documented using the same process symbols. These symbols, when modeling one level, typically refer to the next level's sub-processes until reaching elementary processes. Value chain diagrams often represent business processes, main processes, sub-processes, and elementary processes.

Workflow

A workflow represents a sequence of tasks performed by a person, mechanism, group, organization, or machines (including IT systems). It's always at the elementary process level, abstracting real work into shares, splits, or other ordered types. For control, it may represent real work from a specific perspective.

Functions (Tasks)

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 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 operators or 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 (models).

Sample of a Function Allocation Diagram (FAD) for outsourcing master data to a separate view in order to keep the readability of the process model

Graphical elements can supplement functions (tasks) to describe inputs, outputs, systems, and roles, improving accuracy and detail. However, this can make the model confusing. Two solutions address this: outsourcing these elements to a Function Allocation Diagram (FAD), or selectively showing/hiding them based on the question or application.

The image's function allocation diagram clearly illustrates added graphical elements describing function (task) inputs, outputs, systems, and roles.

Master data (artifacts)

The term master data is neither defined by The Open Group (The Open Group Architecture Framework, TOGAF) or John A. Zachman (Zachman Framework) nor any of the 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 and is commonly used in the absence of a suitable term in the literature. It is based on the general term for data that represents basic information about operationally relevant objects and refers to basic information that is not primary information of the business process.

For August W. Scheer's ARIS, the basic views are organizational, data, function, and performance. ^{(Chapter 1 The vision: A common language for IT and management) ← automatic translation from German}

For Andreas Gadatsch in GPM (Ganzheitliche Prozessmodellierung (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. ^{(Chapter 3.2 GPM – Holistic process modelling) ← automatic translation from German}

For Otto K. Ferstl and Elmar J. Sinz's SOM (Semantic Objektmodell), this describes the Business plan and Resourcen levels.

Master data can be, for example:

• The business unit responsible for a process
• The required business object's information
• The product produced by the process
• The policy for this process
• The risk that occurs in a process
• Improving process capability
• Process governance control
• The IT system supporting the business process
• The milestone dividing processes into phases
• etc.

Adding master data to business process modeling lets the same model serve different applications, thus accelerating return on investment.

Depending on the value assigned to master data in business process modeling, embed it in the process model or outsource it to a separate view, such as a Function Allocation Diagram.

Adding master data systematically to the business process model creates an artifact-centric business process model.

Artifact-centric business process

The artifact-centric business process model offers a holistic approach to business process modeling, providing a flexible solution for capturing operational specifications. It focuses on describing business process data ("artifacts"), characterizing data objects, their lifecycles, and related services. This approach fosters automated business operations and supports flexible workflow enactment and evolution.

Integration of external documents and IT-systems

Integrating external documents and IT systems significantly increases a business process model's value.

Direct access to objects in a knowledge database or documents in a rule framework significantly increases the benefits of business process models in everyday life, improving acceptance. All involved IT systems can exploit their advantages and cross-fertilize (e.g., link to or standardize filing structures).

• 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 widgets, showing external system output, and initiating preconfigured transactions in those systems.

External systems can use electronic data interchange (EDI).

Model consolidation

This checks for redundancies. If found, redundant subprocesses are combined; otherwise, subprocesses used more than once are outsourced to support processes. Successful model consolidation may require revising the original subprocess decomposition.

Ansgar Schwegmann and Michael Laske explain: "A consolidation of the models of different modeling complexes is necessary in order to obtain an integrated ... model." ^{(Chapter 5.2.4 Model consolidation) ← automatic translation from German} They also list a number of aspects for which model consolidation is important:

• "Modeling teams need to drive harmonization of models during model creation to facilitate later consolidation."
• "If an object-oriented decomposition of the problem domain is carried out, it must be analyzed at an early stage whether similar structures and processes of different objects exist."
• "If a function-oriented decomposition of the problem domain is undertaken, the interfaces between the modelled areas in particular must be harmonized."
• "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." ^{(Chapter 5.2.4 Model consolidation) ← automatic translation from German}

Process chaining and control flow patterns

Modal chaining (necessary finalization of sub-processes 1a, 1b and 1c before the start of sub-process 2) in an example using BPMN tools

Control Flow Patterns model how subprocesses and their functions (tasks) interrelate.

Process interfaces specify material details of chaining—what the predecessor delivers to the successor—if needed.

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.

A process flow with interface to a service process in EPC syntax (top) and BPMN syntax (bottom)

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

• Represent a business process sub-model independently.
• Represent a business process or sub-process referenced by multiple other models.
• 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 process models.

Interfaces can be defined by:

• Transferring responsibility between business units
• Data transfer between IT systems
• Initial inputs (information and 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.

To implement improved business processes, change management programs are usually needed. Advances in software design are making fully executable BPM models—enabling simulations and round-trip engineering—a reality.

Adaptation of process models

In business process management, process flows are regularly reviewed and optimized. This optimization, whether driven by continuous improvement or process reorganization (business process re-engineering), requires updating individual subprocesses or entire business processes.

Representation type and notation

In practice, combinations of informal, semiformal, and formal models are common: informal text for explanation, semiformal graphics for visualization, and formal language for simulation and code generation.

Modelling techniques

Various notation standards exist; the most common are:

• 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 (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 later adopted by Lean Management and Six Sigma practitioners
• Unified Modelling Language (UML), proposed in 1996 by Grady Booch, Ivar Jacobson, and James Rumbaugh, is continuously revised by the OMG and includes business process extensions.
• ICAM definition (IDEF0), developed for the US Air Force in the early 1980s
• Pablo Iacub and Leonardo Mayo created Formalized Administrative Notation (FAN) in the 1990s.
• Harbarian process modeling (HPM)
• Business Process Execution Language (BPEL), an XML-based language OASIS developed in 2002 to describe and automate business processes
• Turtle diagram (also turtle method, turtle model, 8W method): a simple, clear graphical representation of process facts.

Furthermore:

• Professor Hermann Krallmann of the TU Berlin's Systems Analysis Department proposed Communication structure analysis in 1989.
• Extended Business Modelling Language (xBML) (appears outdated; its founding company is defunct.)
• Uta Fahrwinkel's 1995 notation from OMEGA (object-oriented method for business process modeling and analysis, Objektorientierte Methode zur Geschäftsprozessmodellierung und -analyse in German)
• Semantic object model (SOM, proposed in 1990 by Otto K. Ferstl and Elmar J. Sinz)
• PICTURE-Methode for documenting and modeling business processes in public administration
• 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 (PCD), and other methods, employ this technique.
• ProMet, a business engineering methodology.
• State diagrams describe system behavior.

Additionally, software architecture representation types are also usable.

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

This section is an excerpt from Business Process Model and Notation.[edit]

Example of a Business Process Model and Notation for a process with a normal flow

Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes in a business process model.

Originally developed by the Business Process Management Initiative (BPMI), BPMN has been maintained by the Object Management Group (OMG) since the two organizations merged in 2005. Version 2.0 of BPMN was released in January 2011, at which point the name was amended to Business Process Model and Notation to reflect the introduction of execution semantics, which were introduced alongside the existing notational and diagramming elements. Though it is an OMG specification, BPMN is also ratified as ISO 19510. The latest version is BPMN 2.0.2, published in January 2014.

Event-driven process chain (EPC)

This section is an excerpt from Event-driven process chain.[edit]

Example of a more complex EPC diagram (in German).

An event-driven process chain (EPC) is a type of flow chart for business process modeling. EPC can be used to configure enterprise resource planning execution, and for business process improvement. It can be used to control an autonomous workflow instance in work sharing.

The event-driven process chain method was developed within the framework of Architecture of Integrated Information Systems (ARIS) by August-Wilhelm Scheer at the Institut für Wirtschaftsinformatik, Universität des Saarlandes (Institute for Business Information Systems at the University of Saarland) in the early 1990s.

Petri net

This section is an excerpt from Petri net.[edit]

A Petri net, also known as a place/transition net (PT net), is one of several mathematical modeling languages for the description of distributed systems. It is a class of discrete event dynamic system. A Petri net is a directed bipartite graph that has two types of elements: places and transitions. Place elements are depicted as white circles and transition elements are depicted as rectangles. A place can contain any number of tokens, depicted as black circles. A transition is enabled if all places connected to it as inputs contain at least one token. Some sources state that Petri nets were invented in August 1939 by Carl Adam Petri — at the age of 13 — for the purpose of describing chemical processes.

Like industry standards such as UML activity diagrams, Business Process Model and Notation, and event-driven process chains, Petri nets offer a graphical notation for stepwise processes that include choice, iteration, and concurrent execution. Unlike these standards, Petri nets have an exact mathematical definition of their execution semantics, with a well-developed mathematical theory for process analysis.

(a) Petri net trajectory example

Flowchart

This section is an excerpt from Flowchart.[edit]

A simple flowchart representing a process for dealing with a non-functioning lamp.

A flowchart is a type of diagram that represents a workflow or process. A flowchart can also be defined as a diagrammatic representation of an algorithm, a step-by-step approach to solving a task.

The flowchart shows the steps as boxes of various kinds, and their order by connecting the boxes with arrows. This diagrammatic representation illustrates a solution model to a given problem. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields.

Hierarchical input process output model (HIPO)

This section is an excerpt from HIPO model.[edit]

IBM stencil for HIPO.

HIPO model (hierarchical input process output model) is a systems analysis design aid and documentation technique from the 1970s, used for representing the modules of a system as a hierarchy and for documenting each module.

Lifecycle Modeling Language (LML)

This section is an excerpt from Lifecycle Modeling Language.[edit]

The Lifecycle Modeling Language (LML) is an open-standard modeling language designed for systems engineering. It supports the full lifecycle: conceptual, utilization, support and retirement stages. Along with the integration of all lifecycle disciplines including, program management, systems and design engineering, verification and validation, deployment and maintenance into one framework. LML was originally designed by the LML steering committee. The specification was published October 17, 2013.

This is a modeling language like UML and SysML that supports additional project management uses such as risk analysis and scheduling. LML uses common language to define its modeling elements such as entity, attribute, schedule, cost, and relationship.

Subject-oriented business process management

This section is an excerpt from Subject-oriented business process management.[edit]

Subject-oriented business process management (S-BPM) is a communication based view on actors (the subjects), which compose a business process orchestration or choreography. The modeling paradigm uses five symbols to model any process and allows direct transformation into executable form.

Each business process consists of two or more subjects which exchange messages. Each subject has an internal behavior (capsulation), which is defined as a control flow between different states, which are receive and send message and do something. For practical usage and for syntactical sugaring there are more elements available, but not necessary.

In 2011 and 2012 S-BPM has been included in Gartner's Hype Cycle.

Cognition enhanced Natural language Information Analysis Method

This section is an excerpt from Cognition enhanced Natural language Information Analysis Method.[edit]

Cognition enhanced Natural language Information Analysis Method (CogNIAM) is a conceptual fact-based modelling method, that aims to integrate the different dimensions of knowledge: data, rules, processes and semantics. To represent these dimensions world standards SBVR, BPMN and DMN from the Object Management Group (OMG) are used. CogNIAM, a successor of NIAM, is based on the work of knowledge scientist Sjir Nijssen.

CogNIAM structures knowledge, gathered from people, documentation and software, by classifying it. For this purpose CogNIAM uses the so-called ‘Knowledge Triangle’. The outcome of CogNIAM is independent of the person applying it. The resulting model allows the knowledge to be expressed in diagrammatic form as well as in controlled natural language.

SIPOC (suppliers, inputs, process, outputs and customers)

This section is an excerpt from SIPOC.[edit]

In process improvement, SIPOC or suppliers, inputs, process, outputs and customers (sometimes in the reversed order: COPIS) is a tool that summarizes the inputs and outputs of one or more business processes in table form, with each of the words forming a column in the table used in the analysis. It is used to define a business process from beginning to end before work on process improvement begins.

Unified Modelling Language (UML)

This section is an excerpt from Unified Modeling Language.[edit]

The Unified Modeling Language (UML) is a general-purpose visual modeling language that is intended to provide a standard way to visualize the design of a system.

UML provides a standard notation for many types of diagrams which can be roughly divided into three main groups: behavior diagrams, interaction diagrams, and structure diagrams.

The creation of UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design. It was developed at Rational Software in 1994–1995, with further development led by them through 1996.

In 1997, UML was adopted as a standard by the Object Management Group (OMG) and has been managed by this organization ever since. In 2005, UML was also published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) as the ISO/IEC 19501 standard. Since then the standard has been periodically revised to cover the latest revision of UML.

In software engineering, most practitioners do not use UML, but instead produce informal hand drawn diagrams; these diagrams, however, often include elements from UML.

Integration Definition (IDEF)

This section is an excerpt from IDEF.[edit]

IDEF methods: part of the systems engineer's toolbox

IDEF, initially an abbreviation of ICAM Definition and renamed in 1999 as Integration Definition, is a family of modeling languages in the field of systems and software engineering. They cover a wide range of uses from functional modeling to data, simulation, object-oriented analysis and design, and knowledge acquisition. These definition languages were developed under funding from U.S. Air Force and, although still most commonly used by them and other military and United States Department of Defense (DoD) agencies, are in the public domain.

The most-widely recognized and used components of the IDEF family are IDEF0, a functional modeling language building on SADT, and IDEF1X, which addresses information models and database design issues.

Formalized Administrative Notation (FAN)

This section is an excerpt from Formalized administrative notation.[edit]

Formalized administrative notation (FAN) is a method that enables administrators of various organizations to describe the flow and sequence of operations, identify their responsibilities, define and integrate their transactions etc. Its objective is to formulate the mode of implementing a specific system in order to have further systemization. Originally called in Spanish as MECAF (Metodo de expresion de circuitos administrativos formalizado)

Harbarian process modeling (HPM)

This section is an excerpt from Harbarian process modeling.[edit]

HPM Process Diagram

Harbarian process modeling (HPM) is a method for obtaining internal process information from an organization and then documenting that information in a visually effective, simple manner.

The HPM method involves two levels:

1. Process diagrams: High-level overviews of specific processes or workflows.
2. Systems diagrams: Mapping how each process is correlated, as well as various inputs, outputs, goals, feedback loops, and external factors.

Business Process Execution Language (BPEL)

This section is an excerpt from Business Process Execution Language.[edit]

The Web Services Business Process Execution Language (WS-BPEL), commonly known as BPEL (Business Process Execution Language), is an OASIS standard executable language for specifying actions within business processes with web services. Processes in BPEL export and import information by using web service interfaces exclusively.

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. Modelling tools may also enable collaborate modelling of complex processes by users working in teams, where users can share and simulate models collaboratively. Business process modelling tools should not be confused with business process automation systems – both practices have modeling the process as the same initial step and the difference is that process automation gives you an 'executable diagram' and that is drastically different from traditional graphical business process modelling tools.

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. This component is often referenced as the engine of the BPM suite.

Programming languages used in BPM include:

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

• Ivar Jacobson's 1992 Use case diagrams (integrated into UML)
• Activity diagrams (also adopted by UML)

Related concepts

Business reference model

Example of the US Federal Government Business Reference Model

A business reference model focuses on the functional and organizational aspects of a enterprise, service organization, or government agency. A reference model embodies the basic goal or idea of something, serving as a reference. A business reference model describes an organization's business operations, independent of its structure. Other models can depict relationships between business processes, functions, and business areas. These layered models provide a foundation for analyzing service components, technology, data, and performance.

The most familiar business reference model is the US federal government's Business Reference Model. This function-driven framework describes federal government business operations independently of the agencies involved. It provides an organized, hierarchical structure for describing daily operations. While other organizational models exist—organizational charts, location maps, etc.—this model uses a functional approach.

Business process integration

Example of the interaction between business process and data models

A business model, an elaboration of a business process model, shows business data, organizations, and processes. Showing processes and information flows, it lets stakeholders define, understand, and validate their enterprise. The data model shows how business information is stored, aiding software code development. See the figure on the right for an example of the interaction between business process models and data models.

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.

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.

Business process re-engineering

Diagram of the business process reengineering cycle

Business process reengineering (BPR) aims to improve the 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.

Business process management

Change management programs typically implement improved business processes. Advances in software design are making fully executable BPM models, capable of simulations and round-trip engineering, a reality.

Adaptation of process models

In business process management, process flows are regularly reviewed and optimized as needed. Whether driven by continual improvement process or business process re-engineering, this adaptation updates individual sub-processes or entire business processes.

See also

• Business architecture
• Business Model Canvas
• Business plan
• Business process mapping
• Capability Maturity Model Integration
• Drakon-chart
• Generalised Enterprise Reference Architecture and Methodology
• Model Driven Engineering
• Outline of consulting
• Value Stream Mapping

Further reading

• Aguilar-Saven, Ruth Sara. "Business process modelling: Review and framework Archived 2020-08-07 at the Wayback Machine." International Journal of production economics 90.2 (2004): 129–149.
• Barjis, Joseph (2008). "The importance of business process modeling in software systems design". Science of Computer Programming. 71: 73–87. doi:10.1016/j.scico.2008.01.002.
• Becker, Jörg, Michael Rosemann, and Christoph von Uthmann. "Guidelines of business process modelling." Business Process Management. Springer Berlin Heidelberg, 2000. 30–49.
• Hommes, L.J. The Evaluation of Business Process Modelling Techniques. Doctoral thesis. Technische Universiteit Delft.
• Håvard D. Jørgensen (2004). Interactive Process Models. Thesis Norwegian University of Science and Technology Trondheim, Norway.
• Manuel Laguna, Johan Marklund (2004). Business Process Modeling, Simulation, and Design. Pearson/Prentice Hall, 2004.
• Ovidiu S. Noran (2000). Business Modelling: UML vs. IDEF Paper Griffh University
• Jan Recker (2005). "Process Modelling in the 21st Century". In: BP Trends, May 2005.
• Ryan K. L. Ko, Stephen S. G. Lee, Eng Wah Lee (2009) 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). "EM-BrA2CE v0.1: A vocabulary and execution model for declarative business process modelling". DTEW – KBI_0728.

External links

• Media related to Business process modeling at Wikimedia Commons

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