Business Process Modeling: Basic Concepts and History

Basic Concepts

Business process, business method or business function is a collection of related, structured activities or tasks performed by people or equipment, in which a specific sequence produces a product or service (serves a particular business goal) for a particular customer or customers. Business processes occur at all levels of an organization and may or may not be visible to customers. A business process can often be visualized (modeled) as a flowchart of a sequence of activities with interleaving decision points, or as a process matrix of a sequence of activities with relevance rules based on data in the process. The benefits of using business processes include improved customer satisfaction and greater agility in responding to rapid market changes. Process-oriented organizations break down the barriers between structural units and try to avoid functional silos.
When discussing business process modeling, we will use the terminology of several fields of knowledge at once, relating to economics, computer science, and the modeling of complex systems. Therefore, before moving on, it is necessary to introduce a number of basic concepts and definitions.
First, let us try to understand what "business process modeling" actually is. A business process is defined as a logically complete chain of interrelated and repeatable activities in which the enterprise's resources are used to transform an object (physically or virtually) in order to achieve certain measurable results or to create products that satisfy internal or external consumers. The customer of a business process may be another business process. The chain usually includes operations that are performed according to certain business rules. Business rules are understood as the ways of implementing business functions within a business process, as well as the characteristics and conditions of executing the business process.

The activities that make up a business process may be performed by people (manually or with the aid of computer tools or mechanisms) or be fully automated. The order in which activities are performed and the efficiency of whoever performs them determine the overall efficiency of the business process. The task of every enterprise striving to improve its operations is to build business processes that are efficient and include only the activities that are truly necessary.

Workflow

A workflow is the procedural movement of information, materials, and tasks from one participant to another. A workflow includes the procedures, people, and tools involved at each stage of a business process. A single workflow can be sequential, where each step depends on the completion of the previous one, or parallel, where several steps are performed simultaneously. Multiple combinations of individual workflows can be linked to achieve an overall end-to-end process.

Business Process Reengineering

Business process reengineering (BPR) was originally conceived by Hammer and Davenport as a means of improving an organization's efficiency and productivity. It may involve starting from a "clean slate" and completely recreating the core business processes, or comparing the "as-is" process with the "to-be" process and mapping the path of change from one to the other. BPR often involves the use of information technology to deliver significant productivity gains. Unfortunately, the term became associated with corporate "downsizing" in the mid-1990s.

Business Process Management (BPM)

Although the term has been used contextually for mixed effect, "business process management" (BPM) can generally be defined as a discipline that encompasses a combination of a wide variety of streams of business activity (for example, business process automation, modeling, and optimization) and seeks to support enterprise goals within and across many boundaries, involving many people, from employees to customers and external partners. The core of BPM's support for the enterprise consists of continuously assessing existing processes and identifying ways to improve them, which results in a cycle of overall organizational improvement.

Knowledge Management

Knowledge management is the identification of the knowledge that employees and systems use to perform their functions, and keeping it in a format accessible to others. Duhon and the Gartner Group defined it as "a discipline that promotes an integrated approach to identifying, capturing, evaluating, retrieving, and sharing all of an enterprise's information assets. These assets may include databases, documents, policies, procedures, and previously uncaptured expertise and experience of individual workers."

Total Quality Management

Total quality management (TQM) emerged in the early 1980s, when organizations sought to improve the quality of their products and services. In the mid-1980s it was followed by the Six Sigma methodology, first introduced by Motorola. Six Sigma consists of statistical methods for improving business processes and thereby reducing defects in outputs. The "lean" approach to quality management was introduced by Toyota Motor Company in the 1990s and focuses on customer needs and waste reduction.

Information Technology as a Tool for Business Process Management

Advances in information technology over the years have transformed business processes within and between enterprises. In the 1960s, operating systems had limited functionality, and any workflow management systems in use were tailored to a specific organization. In the 1970s and 1980s, data-driven approaches were developed as data storage and retrieval technologies improved. The starting point for building an information system was data modeling rather than process modeling. Business processes had to be adapted to information technology, because process modeling was not given due attention. A shift toward process-oriented management occurred in the 1990s. Enterprise resource planning software with workflow management components, such as SAP, Baan, PeopleSoft, Oracle, and JD Edwards, appeared, as did business process management systems (BPMS) later.

In the world of e-business, a need arose for business process automation in organizations, which in turn created a need for industry-wide standardized protocols and languages for web service composition. Business Process Model and Notation (BPMN) and the Business Motivation Model (BMM) are widely used standards for business modeling. The Business Modeling and Integration Domain Task Force (BMI DTF) is a consortium of vendors and user companies that continues to work together on developing standards and specifications to facilitate collaboration and integration of people, systems, processes, and information within and between enterprises.

The most recent trends in BPM are influenced by the emergence of cloud technologies, the proliferation of social networks, mobile technologies, and the development of analytical methods. Cloud technologies allow companies to acquire resources quickly and as needed, regardless of their location. Social networks, websites, and smartphones are the newest channels through which organizations reach and support their customers. The abundance of customer data collected through these channels, as well as through call center interactions, email, voice calls, and customer surveys, has led to enormous growth in data analytics, which in turn is used to manage performance and improve the way a company serves its customers.

Modeling

The term modeling has two main meanings. First, modeling is understood as the process of building a model as a representation
(image) of an original that reflects its most important features and properties. Once a model has been built, modeling is the process of studying (analyzing) how a system, or rather its model, functions. The basic goal of business process modeling is to describe how a company's business processes actually run. To do this, it is necessary to determine what the outcome of the process is, who performs which actions, in what order, how documents move during the process, how reliable the process is (the probability of unsuccessful execution), and how it can be extended or modified in the future.

Making the course of business processes transparent is important because only then will the business process owner (the company employee who manages the course of a business process and is accountable for its results and efficiency), the business analyst, management, and other stakeholders have a clear understanding of how the work is organized. Understanding how existing business processes run makes it possible to judge their efficiency and quality, and is necessary for developing the IT infrastructure that supports the business. Application systems that support the execution of business processes from start to finish can be developed successfully only when the processes themselves are clear in detail.

Business process model

A business process model is a formalized (graphical, tabular, textual, or symbolic) description of a process that reflects the actual or intended activity of an enterprise. A model typically contains the following information about a business process:

• the set of steps that make up the process — business functions;
• the order in which the business functions are performed;
• the control and management mechanisms within the business process;
• the performers of each business function;
• incoming documents/information and outgoing documents/information;
• the resources required to perform each business function;
• the documentation/conditions governing the performance of each business function;
• the parameters characterizing the performance of the business functions and of the process as a whole.

Various methods can be used to model business processes. A modeling method, or methodology, includes the sequence of actions that must be carried out to build a model, i.e., the modeling procedure, and the notation (language) used. The most popular business modeling methodology is ARIS, but Catalyst from CSC, Business Genetics, SCOR (Supply \
Chain Operations Reference), POEM (Process Oriented Enterprise Modeling), and others are also well known. A modeling language has its own syntax (the symbols for the various elements and the rules for combining them) and semantics (the rules for interpreting models and their elements). In theory and in practice there are various approaches to building and presenting business process models, the main ones being the functional and the object-oriented approaches. In the functional approach, the main structure-forming element is the function (business function, action, operation), and the system is represented as a hierarchy of interrelated functions. In the object-oriented approach, the system is broken down into a set of objects that correspond to real-world objects and interact with one another by sending messages.

By type of modeling methodology, the following are distinguished:

- structural modeling tools (BPwin);

Fig. Business modeling tools

Business function

A business function is a specific type of work (operations, actions) performed on products or services as they move through a business process. As a rule, business functions are determined by the company's organizational structure itself, ranging from the functions of top management, through middle- and lower-level management functions, to the functions assigned to production personnel.
The functional approach to business process modeling comes down to building a business process diagram as a sequence of business functions, with which material and information objects, resources used, organizational units, and so on are associated. The advantage of the functional approach is the clarity of the sequence and logic of operations in the company's business processes; its drawback is a degree of subjectivity
in the level of detail of operations.

When modeling a company's business processes, the objects can be specific items or real entities, for example a customer, an order, a service, and so on. Each object is characterized by a set of attributes whose values determine its state, as well as a set of operations for checking and changing that state. The object-oriented approach involves first identifying objects and then defining the actions in which they participate. A distinction is made between passive objects (materials, documents, equipment), on which actions are performed, and active objects
(organizational units, specific performers, software), which carry out actions. This approach makes it possible to identify operations on objects more objectively and to decide whether using those objects is appropriate. The drawback of the object-oriented approach is that specific business processes are less easy to visualize.

An important concept in any business process modeling method is relationships (in graphical notations they are usually drawn as arrows). Relationships describe how objects and/or business functions relate to one another. Such relationships can include: sequence of execution over time, a link via an information flow, use by another object, and so on.

Enterprises use business process models for various purposes, which determines the type of model developed. A graphical business process model in the form of a clear, universally understandable diagram can be used to train new employees in their job duties, to coordinate actions between the company's organizational units, to select or develop information system components, and so on. Describing
existing and target business processes with models of this type is used to optimize and improve the company's operations by eliminating bottlenecks, duplicated functions, and the like. Simulation models of business processes make it possible to assess their efficiency and to see how a process would run with inputs not yet encountered in the enterprise's real work. Executable business process models can be run on specialized software to automate the process directly from the model.
Since business process models are intended for a wide range of users (business analysts, rank-and-file employees and company management), and are often built by people who are not information technology specialists, graphical models are the most widely used: following a particular methodology, the business process is represented as a clear
graphical image — a diagram consisting mainly of rectangles and arrows. Such a representation offers high, multidimensional informational richness, expressed through various properties (color, background, typeface, etc.) and attributes (weight, size,
cost, time, etc.) of each object and connection. In recent years, developers of business process modeling software have paid great attention to converting graphical models into models of other kinds, in particular executable ones, whose purpose is to automate the business process and integrate the work of the information systems involved in its execution. According to another classification, borrowed from the modeling of complex systems, the following types of business process models are distinguished:

• functional models, describing the set of functions performed by a system and their inputs and outputs;
• behavioral models, showing when and/or under what conditions business functions are performed, using categories such as system state, event, transition from one state to another, transition conditions, and sequence of events;
• structural models, characterizing the morphology of the system — the composition of subsystems and their interrelationships;
• information models, reflecting data structures — their composition and interrelationships.

A business process begins with a mission objective (an external event) and ends with the achievement of a business goal by delivering a result that provides value to the customer. In addition, a process can be divided into subprocesses (process decomposition) and individual internal process functions. Business processes may also have a process owner, responsible for ensuring the smooth operation of the process from start to finish.

In general terms, according to von Rosing et al., business processes can be divided into three types:

1. Operational processes, which constitute the core business and create the primary value stream, for example, taking orders from customers, opening an account and manufacturing a component.
2. Management processes, which control the operational processes, including corporate governance, budget oversight and staff supervision.
3. Supporting processes, which support the core operational processes, for example accounting, recruitment, call center, technical support and safety training.

Kirchmer proposes a somewhat different approach to these three types:

1. Operational processes, which are aimed at the correct performance of the organization's operational tasks; this is where staff "get things done"
2. Management processes, which ensure that operational processes are properly executed; this is where managers "ensure efficient and effective work processes"
3. Governance processes, which ensure that the organization's activities fully comply with the necessary legal regulations, guidelines and shareholder expectations; this is where executives ensure compliance with the "rules and guidelines for business success".

A complex business process can be divided into several subprocesses, which have their own attributes but also contribute to achieving the overall business goal. Business process analysis typically involves mapping or modeling processes and subprocesses down to the activity/task level. Processes can be modeled using a large number of methods and techniques. For example, Business Process Model and Notation is a business process modeling technique that can be used to draw business processes as a visualized workflow. Although breaking processes down into types and categories can be useful, caution should be exercised, as overlap may occur. After all, all processes are part of a largely unified outcome, that of "creating value for the customer". This goal is advanced through business process management, which aims at the analysis, improvement and implementation of business processes.

Development and History of Business Process Modeling

An important early (1776) description of processes was given by the economist Adam Smith in his famous example of the pin factory. Inspired by an article in Diderot's Encyclopédie, Smith described the making of a pin as follows:

"One man draws out the wire; another straightens it; a third cuts it; a fourth points it; a fifth grinds it at the top for receiving the head; to make the head requires two or three distinct operations; to put it on is a peculiar business; to whiten the pins is another ... and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some factories are performed by distinct hands, though in others the same man will sometimes perform two or three of them."

Smith was also the first to realize how output could be increased through the division of labor. Previously, in a society where handmade goods predominated in production, one person performed all the actions required in the production process, whereas Smith described how the work was divided into a set of simple tasks performed by specialized workers. The result of the division of labor in Smith's example was a productivity increase of 24,000 percent (sic), that is, the same number of workers made 240 times more pins than they had produced before the division of labor was introduced.

It is worth noting that Smith did not advocate the division of labor at any cost and in itself . The appropriate level of task division was determined through experimental design of the production process. Unlike Smith's view, which was limited to a single functional area and included activities that follow one another directly in the production process ^, today's concept of a process includes cross-functionality as an important characteristic. Following his ideas, the division of labor became widespread, while the integration of tasks into a functional or cross-functional process was not considered an alternative until much later.

The history of business process modeling spans almost a century, although until
the early 1990s, when the term "business process" came into wide use, people spoke of
describing how an organization carries out its functions and performs
various tasks. The development of business process modeling and automation methods is usually
divided into three stages, or three "waves".

Each of them began with a fresh surge of interest in improving the efficiency of enterprises and in process management,
occurring each time at a new qualitative level.

The main characteristics of these
stages are given in Table 1.1, in comparison with the corresponding stages of development of
information technology and approaches to improving company performance.

Table 1.1

The beginning of the first stage is dated to the 1920s and is associated with the name of Frederick Taylor and his
book "The Principles of Scientific Management". In this period the need was first recognized
to study business processes, describe them in various documents, and act in accordance with
those descriptions. Business processes are described in text, tabular, and graphical
form, and the latter is becoming increasingly formalized.
During the "first wave," flowcharts,
directed graphs, Petri nets, and the SADT, IDEF, and DFD methodologies were used to model business processes. Flowcharts based on the
notation for algorithm, program, data, and system diagrams defined in GOST 19.701-90 (known in English-language literature
as ANSI flowcharts) remain to this day the simplest, yet practically important, formal graphical language for modeling business processes. An example of describing a process with a flowchart is shown in Fig. 1.1.
Flowcharts make it possible to show the steps of a business process quickly and clearly
in a form that everyone can understand; however, their notation does not provide for a formalized description of
many details of a process, in particular the performers of business functions.
We will discuss the SADT and IDEF methodologies in detail in the next chapter. As for Petri
nets, using this apparatus directly to describe business processes, although
it has its supporters, has not gained wide popularity, because its graphical notation
is not intuitive (it is difficult for business analysts and managers to work with).
In addition, there are processes that cannot be described with it. However, looking
ahead, we note that Petri nets would form the basis of a number of languages specifically designed for
modeling business processes in the "third wave."
In the 1980s, the first attempts were made to automate business processes (to be precise: not
individual steps, but the course of a process as a whole) by implementing, in software for
document management — electronic document management systems — functions for
tracking the sequence of actions performed, in order to automate the procedures for
approving and issuing documents. The success of such systems inspired software developers to
extend a similar approach to the automation of other functional areas of business.
Business modeling emerged as an independent scientific and applied field only by
the early 1990s. Most of the methodologies created and used up to that point
were not designed specifically for describing business processes, but were developed for modeling
complex systems and designing software. They often lack strictly defined semantics.
Models produced with such methodologies are, as a rule, perceived intuitively, and their
interpretation may vary depending on the user or the application area of the model. These
models are well suited for discussing business processes between company employees and
management, which is what they were in fact used for, but they cannot serve as the basis for the operation of an
information system, since they are incomplete and allow different interpretations.

Fig. 1.1. Example of describing a business process as a flowchart

The start of the second stage was marked by the publication of the book by M. Hammer and J. Champy, "Reengineering
the Corporation: A Manifesto for Business Revolution," which revived interest in the management community
in describing and analyzing business processes with the aim of radically redesigning them —
reengineering. Business process reengineering involves building two models of a
business process: as is and to be, and then implementing
the latter in the enterprise.
As the next step in business process automation, second-generation
Workflow Management Systems (WfMS) appeared in the 1990s,
designed to route workflows of any type within a company's
business processes. These systems were equipped with a development environment,
which could theoretically be used to model various non-standard business processes; in practice, however, in most cases implementing a new process or changing an
existing one required the work of programmers.
Even more limited capabilities for configuring and changing processes were offered by
Enterprise Resource Planning (ERP) systems that supported workflow management.
Making any significant change to a business process turned into a very expensive and long-term software design and
development project, while the business process models built
by analysts were used to formulate requirements more clearly, which were then
handed over to programmers. ARIS and
the widespread ERP system SAP R/3 can be cited as examples of a second-generation methodology and automation tool for
business processes, respectively.
The inflexibility of the models and automation tools and their inability to ensure a prompt
response to constant changes in the business environment became the main shortcomings of
"second wave" systems, spurring the development in the early 2000s of methodologies of
the next — third — generation. The book by H. Smith and P. Fingar, "Business
Process Management: The Third Wave"1
, can rightly be called the manifesto of the "third wave" in business process modeling.
Radical reengineering gives way to
systematic and "smooth" management. The changeability of business processes and the ability to
adjust them in response to changes in the business become the main criterion for
using information technology as a means of gaining
advantages in the market.
The idea behind third-generation modeling methodologies and tools is
to allow management and company employees to create and implement new
processes themselves "on the fly." Process automation is carried out by means of so-called
Business Process Management Systems (BPMS), which
make it possible to implement business processes directly in accordance with
a formal model that has been built, and do not require the development of additional software.

Developing machine-understandable "executable" models requires more precise
modeling methods. Such methods include XML-based modeling languages:
BPML, BPEL, and XPDL. However, building models directly in these languages is
inconvenient for business users. In this regard, software developers pay great attention to tools for converting graphical models of
business processes into executable ones. This allows a business analyst or manager to
build business process models using a graphical notation and then
convert the resulting model (so far often with the help of a technical
specialist) into an executable form.
It should be understood that graphical models intended for conversion into executable ones
must be much stricter and more formal than models created for
analytical purposes. For example, a graphical model built as a flowchart with
extensive text comments cannot be automatically converted into an executable format.
The BPMN notation emerged as a language that makes it possible to build a clear model, understandable to an untrained
user, which can then be unambiguously converted into an executable language
(originally this was BPML). It supports the description of such "
programmer" functions as event and error handling, transaction rollback, and so on.
The "third wave" brought a drive toward standardization to business process modeling.
Methodologies for building executable models are developed and published by organizations
standardization bodies and international consortia:

• OASIS (Organization for the Advancement of Structured Information Standards, founded in 1993) publishes the ebXML and BPEL specifications, as well as various standards for e-business based on XML and web services;
• OMG (Object Management Group, founded in 1989) publishes the BPMN and UML standards, as well as MDA and CORBA;
• W3C (World Wide Web Consortium, founded in 1994) publishes the WS-CDL and WSCI standards, as well as the XML specifications, web service technologies, and many others;
• WfMC (Workflow Management Coalition, founded in 1993) publishes the Wf-XML and XPDL standards.

At the present stage, the scope of business process modeling and automation increasingly includes automating the enterprise's interaction with its external environment. A business process model reflects the company's interaction with various external entities: customers, commercial partners, suppliers, and government agencies. When a process is automated, these interactions are also automated wherever possible. Technologies for automating inter-company interaction — business-to-business (B2B) — are developing especially actively.

The need to automate business processes involving interaction between enterprises arose as early as the 1960s. The first generation of electronic B2B systems is described by the UN/EDIFACT standard (United Nations Rules for Electronic Data Interchange for Administration, Commerce and Transport, ISO 9735), which, despite strong competition from XML-based systems in recent years, is still quite widely used in Europe across many sectors of the economy.

The development of the Internet gave impetus to new methods and technologies in the field of electronic data interchange. One of the most successful methods of electronic exchange is the methodology of the RosettaNet consortium, which appeared in 1998. This technology describes an open platform for electronic interaction based on the XML standard and allows the parties involved to exchange business information over the Internet. The standard was originally developed for the high-tech industry (information technology and electronics), but the proposed approach became the basis for interaction mechanisms in enterprises of other industries as well. Within the RosettaNet methodology, standards have been developed for more than a hundred business interaction processes between different companies or between divisions within a single enterprise. These standardized processes are called Partner Interface Processes (PIP) and specify transactions between two business systems in the form of an XML-based dialogue.

Another modern technology for automating inter-company interaction is ebXML (Electronic Business using eXtensible Markup Language, ISO 15000). Work on ebXML began in 1999 on the initiative of UN/CEFACT (the United Nations Centre for Trade Facilitation and Electronic Business) and the OASIS consortium, which had accumulated extensive experience in conducting business on the Internet based on XML. The goal of the project is to develop an e-business infrastructure — a complete set of specifications enabling business interactions through a uniform XML environment. With the advent of ebXML, companies gained a de facto standardized method for exchanging data and business messages, as well as uniform terms for the information support of trade relations.
The ebXML architecture combines message format specifications, business process models, a set of syntax-neutral core components, and distributed data stores (repositories). The ebXML standard is becoming ever more widespread with the adoption of Web Services technology.

The Importance of the Process Chain

Business processes consist of a set of sequential subprocesses or tasks, with alternative paths depending on the conditions that apply, performed to achieve a given goal or produce specified results. Each process has one or more required inputs. Inputs and outputs may be received from or sent to other business processes, other departments of the organization, or internal or external stakeholders.

Business processes are designed to manage one or more functional units and emphasize the importance of the "process chain" rather than of individual departments.

In general, the various tasks of a business process can be performed in one of two ways:

1. manually
2. with the help of business data processing systems, such as ERP systems

As a rule, some process tasks are performed manually and some on a computer, and these tasks can be arranged in different ways. In other words, the data and information processed in the process may pass through manual or computer tasks in any given order.

Policies, Processes, and Procedures

The improvement areas mentioned above apply equally to policies, processes, detailed procedures (subprocesses / tasks), and work instructions. Improvements made at a higher level have a cascading effect on improvements made at a lower level. ^[26]

For example, if a recommendation to replace a given policy with a better one is made with proper justification and accepted in principle by the business process owners, then the corresponding changes in the subsequent processes and procedures will follow naturally to ensure that the policies are implemented.

Reporting as an Important Basis for Execution

Business processes should include up-to-date and accurate reports to enable effective action. An example of this is the availability of purchase order status reports for tracking delivery by the supplier, as described in the section on efficiency above. There are many examples of this across all possible business processes.

Another example from manufacturing is the process of analyzing line rejects occurring on the shop floor. This process should include a systematic periodic analysis of failures by cause and present the results in a suitable information report that identifies the main causes and trends in those causes, so that management can take corrective action to control failures and keep them within acceptable limits. Such a process of analyzing and summarizing line rejection events is clearly superior to a process that simply investigates each individual rejection as it occurs.

Business process owners and operators should understand that process improvement often comes with the introduction of appropriate transaction, operational, highlighted, exception, or MIS reports, provided that they are consciously used for day-to-day or periodic decision-making. We hope that this understanding will lead to a willingness to invest time and other resources in improving business processes by implementing useful and relevant reporting systems.

Basic Principles of Business Process Modeling

Let us now look at what business process modeling means in practice.
Business process modeling in a company can be aimed at solving a large number of
different tasks:

• Define precisely the outcome of a business process and assess its value to the business.
• Define the set of activities that make up the business process. A clear definition of the tasks and activities to be performed is extremely important for a detailed understanding of the process.
• Define the order in which activities are performed. Activities within a single business process may be performed either sequentially or in parallel. Obviously, parallel execution, where it is permissible, reduces the overall process execution time and therefore increases its efficiency.
• Divide the areas of responsibility: determine, and then track, which employee or company division is responsible for performing a particular activity or the process as a whole.
• Identify the resources consumed by the business process. By knowing exactly who uses which resources and for which operations, you can improve resource utilization through planning and optimization.
• Understand the nature of the interactions between the employees and divisions of the company involved in the process, and assess and then improve the effectiveness of communication between them.
• See the flow of documents during the process. Business processes produce and consume various documents (in paper or electronic form). It is important to understand where documents or information flows come from and go to, and to determine whether their movement is optimal and whether all of them are really necessary.
• Identify potential bottlenecks and opportunities for process improvement, which will be used later to optimize it.
• Implement quality standards, such as ISO 9000, more effectively and successfully pass certification.
• Use business process models as a guide for new employees.
• Effectively automate business processes as a whole or individual steps of them, including automating interaction with the external environment — customers, suppliers, partners.
• By understanding the totality of the company's business processes, understand and describe the activity of the enterprise as a whole.

In turn, the main task when modeling a company's business processes is to describe the processes that exist in it in order to build "as-is" models of them. To do this, it is necessary to collect all available information about the process, which, as a rule, is fully held only by the company's employees who are directly involved in carrying out the process. Thus, we arrive at the need for a detailed survey (interviewing) of all employees involved in the business process. It should be emphasized that one cannot limit oneself to the information about the process provided by the head of the department and by managers. Usually only a conversation with the employee who directly performs the actions within the business process being described gives an adequate picture of how the process functions in reality. The first question when building an "as-is" model concerns the outcome of the business process under consideration. It happens that obtaining a clear formulation of the outcome of a business process is not easy, despite the importance of this concept for the company's operational effectiveness. After the outcome has been defined, one should work out the sequence of actions that make up the process. The sequence of actions is modeled at different levels of abstraction. At the top level, only the most important steps of the process are shown (usually no more than ten). Then each of the high-level
steps (subprocesses) is decomposed. The depth of decomposition is determined by the complexity of the process and the required degree of detail. To get a truly complete picture of a business process, one must decompose it down to atomic business functions — well-understood elementary actions (individual operations in software or performed by a person) that it makes no sense to break down further. Based on the information collected, a model of the normal, or optimal, execution of the process is built, and possible scenarios of its execution with failures are identified. Various failures (exceptional situations — exceptions) can disrupt the optimal course of the process, so it is necessary to specify how the exceptions will be "handled", that is, what actions are taken when an exceptional situation occurs.

Fig. 1.2 Steps in building a business process model

Fig. 1.2 shows the main steps in building a business process model.
An important part of building a business process model is examining aspects of its efficiency. This includes the use of resources, the time employees take to perform work, and possible delays and idle time. A system of indicators, or metrics, needs to be developed to assess the efficiency of the process. Some of the metrics may be taken from the KPIs (Key Performance Indicators) used in the company, but additional indicators characterizing the process under consideration may also be required.

During modeling, the business goals to which the modeled process contributes are identified. One should distinguish between the concepts of a business goal and a process outcome. Every business process must have at least one outcome and be aimed at achieving at least one business goal. For example, the outcome of the "Subscriber connection order fulfillment" process can be defined as "Receipt of connection confirmation from the customer", whereas the business goals pursued when performing this process may include "Ensuring minimum order
fulfillment time" and "Ensuring a minimum percentage of complaints". To define the goals, one should refer to the company's business strategy.

It is necessary to identify the events that can interrupt the course of the process. In case of an interruption, it may be necessary to correctly "roll back" (compensate for) those steps of the process that have already been completed. To do this, the logic of compensating actions should be defined for each interrupting event.
Finally, the existing software tools that support the business process should be examined. This is important because software may hide some features of process behavior that are not fully known to the employees performing individual steps. The information collected at this stage will be useful for further automation of the process.

Having collected all of the above information, one can get a good picture of the course of the business process. At the modeling stage, the following results should be obtained:

• A process map showing the relationships between the various business processes and their interactions. On a process map, as a rule, each business process of the company is depicted as a rectangle, arrows show the links between them (for example, the dependence of one process on another, or the replacement of one process by another when a certain condition is met), and the various documents that are passed from process to process or govern their course (standards, instructions, etc.) are also presented.
• A role diagram showing the roles in the execution of the process and the relationships between them. A role diagram is not hierarchical. It represents such relationships as group membership, management, communication, substitution of one role by another, etc.
• An "as-is" model of each business process examined, describing the process in detail and reflecting the flow of the process, activities, roles, document flow, and also the points of possible optimization.

Such a model includes:

• a process context diagram, representing the business process as a single activity (that is, not revealing the flow of the process), for which the following can be shown: the event that triggers the process, the required inputs, the outcome, roles, performance indicators, interrupting events and compensating processes, governing documents, and related business goals;
• a high-level process diagram showing its major steps (usually no more than ten) and the roles associated with them;
• detailed diagrams for each step of the high-level model (depending on the complexity of the process, several hierarchically organized diagrams may be used here), showing in detail the flow of the process, interrupting events, business rules, roles, and documents;
• an exception handling diagram showing which actions are performed in the case of a given exceptional situation and by whom, and also where control is passed after exception handling is completed.

In practice, the following composition of the team carrying out
business process modeling has proven itself well:

• the business process owner and one or two employees of the same company department who assist them;
• a quality management specialist;
• business analyst(s);
• an IT department representative;
• an external consultant (optional).

Capabilities of Tools

The main functional capabilities of modeling tools:

• visual modeling - creating diagrams interactively using visual tools;
• model validation – checking compliance with syntactic and semantic rules, checking model consistency, ensuring the integrity of design data;
• business process characteristics analysis – activity-based costing, simulation modeling, and other analysis methods;
• documentation – preparing project documentation, generating process and work instructions;
• maintaining a library of standard models – the ability to save standard templates in a library and use them when building new models;
• support for teamwork – the ability to merge models created by different developers.

Problems in Choosing a Business Process Modeling Tool

• The problem of choosing a standard methodology (vendors sell tools, not methods; they train people on systems, not on methodologies)
• Fit with project objectives (it is hard to determine in advance how well a chosen methodology suits a particular project)
• The difficulty of regulating the use of tools (there are many features, and the more flexible and powerful the system, the harder it is to use correctly)
• The lack of standards and standard terminology
• The lack of information and opportunities for a real exchange of project experience

Criteria for choosing a tool:

• Functionality and methodology.
• They must match actual needs. You should not "overpay" for a tool with excess capabilities.
• If the goal is to build information systems that support business processes, Oracle Designer, Power Designer and Rational Rose are more suitable.
• If you need a tool for modeling a business that is small in scale and not overly complex, BPwin is a better fit.
• If you are carrying out a large business reengineering project that requires careful analysis of the proposed options for restructuring the business (calculating time, cost and other quantitative indicators) and their subsequent optimization, ARIS Toolset is a better fit.

Staff skill level.

As a rule, the broader the capabilities of a tool environment, the higher the requirements placed on its users. Working with tools that are hard to learn (for example, Rational Rose, ARIS) requires training staff or hiring qualified specialists who are already trained. This entails additional costs and lengthens development times. Therefore, it is better to use tools that are relatively easy to learn (Design/IDEF, BPwin), provided their capabilities match your needs.

Cost of tools

The price of tools from different vendors can vary significantly. Moreover, an enterprise's budget costs will be determined not only by the initial investment in acquiring the tool, but also by subsequent costs for technical support, staff training, possible upgrades of the hardware and software platform, potential "upgrades," and so on.

Characteristics of the hardware and software platform.

When choosing a tool environment, you need to assess:

• - technical platform requirements;
• - system-wide software requirements;
• - telecommunications requirements;
• - information security capabilities;
• - the number of installation sites for user applications.

Fig. BPwin tool

• [[b7317]]
• [[b8804]]
• [[b8209]]
• Business analysis
• Business method patent
• Business process automation
• Business process definition metamodel
• Business process mapping
• Business process outsourcing

See also

• Buisness process. Reengineering. Review of business process design methodologies
• EPC (Event-Driven Process Chain) and eEPC Notation
• Business Process Modeling: Basic Concepts and History