Description of modeling and analysis of business processes. Techniques for the analysis of business processes. Organizational Business Modeling Templates

Business process is a part of process management. His model is main element business process management. The business process must be divided into a number of features that characterize each of its properties or abilities. With this division, the process is easier to recognize, compare and analyze. There is an important concept business process modeling.

Basic approaches to business process modeling

Modeling of business processes of the company can be performed in a variety of ways. Special attention should be given to object-oriented and functional approaches. Within the framework of the functional approach, the main structure-forming element is the function (action), while the object-oriented approach is the object.

Within the framework of the functional approach, the organization of business process modeling implies the construction of a scheme technological process as a sequence of operations.

At the input and output of each, objects of different origin are displayed: material and informational types, as well as the resources used, organizational units.

As part of the functional modeling methodology, where structural diagrams of business processes and information flows are constructed, a sequence of functions is displayed in which the choice of specific process alternatives is rather complicated, and there are no object interaction schemes.

Functional modeling of business processes has a significant advantage - visibility and clarity of display at different levels of abstraction. This is especially important at the stage of introduction of created business processes into the departments of the company.

At functional approach the detailing of operations is presented in a somewhat subjective form, which leads to the complexity of building business processes.

Modeling of business processes in the object-oriented approach is built according to the following scheme: first, classes of objects are distinguished, and then actions are determined in which the objects must take part. Objects can be active, that is, performing actions (organizational units, certain performers, information subsystems), and passive, on which actions are performed (we are talking about equipment, documentation, materials). Modeling business processes in an object-oriented way reflects the objects, functions and events in which certain processes are performed because of the objects.

The object-oriented approach also has a number of advantages, the main of which is a more precise definition of operations on objects, which leads to a reasonable solution to the problem of the expediency of their existence.

We also note the minus of the method. Specific processes for decision makers become less visible. But thanks to modern software products, it is quite easy to present functional diagrams of objects.

Complex business process modeling methodologies have the most promise. For example, thanks to ARIS technology, it is possible to select the most optimal models according to the goals of the analysis.

Applied business process modeling methods

Now we can note the trend of integration of different methods of modeling and analysis of systems. It manifests itself in the fact that integrated tools for modeling business processes are being created. One of them is a product of the German company IDS Scheer called ARIS - Architecture of Integrated Information System.

The ARIS system includes a set of tools that allow you to analyze and model the work of the company. The system is based on various modeling methods, which together reflect different views on the environment under study. The same model can be created using several methods. Thanks to this, experts different levels theoretical knowledge can use it for their own purposes and configure it to interact with systems with their own specifics.

The ARIS system provides support for 4 types of models that reflect various objects of the system under study:

To create models of the types described above, they use both their own ARIS modeling methods and various well-known methods and languages ​​- ERM, UML, OMT, etc.

When modeling business processes, each aspect of the company's activities is first considered separately. After all aspects have been worked out, an integrated model is created that displays all the relationships of different aspects with each other.

In ARIS, models are diagrams consisting of various objects - “functions”, “events”, “ structural units”, “documents”, etc. All sorts of connections are established between objects. At the same time, each object has its own set of attributes that are assigned to it, which allows you to enter additional information about it. Attribute values ​​can be used during simulation or cost analysis.

The key business model of ARIS is eEPC (extended Event Driven Process Chain - an extended model of the chain of business processes controlled by events). In fact, it expands the capabilities of IDEF0, IDEF3 and DFD, has its own pluses and minuses. Using a sufficient number of objects connected to each other by various types of links allows you to significantly increase the size of the model and turn it into a poorly readable one.

In eEPS, a business process is a flow of sequential work (functions, procedures, activities) arranged in chronological order. The exact duration of the procedures in eEPC is not displayed clearly, as a result of which it is possible that situations may arise during the development of models in which one performer will have to solve two tasks at the same time. The logic symbols used in the simulation help to show the branching and connection of the process. To find out how long the processes actually take, you should use other description tools, for example, Gantt charts in the MS Project system.

Ericsson Penker

The Ericsson-Penker method is interesting mainly because within its framework an attempt was made to use the UML when process modeling of business processes was carried out. The developers of the method have created their own UML profile to perform business process modeling. To do this, they introduced a set of stereotypes that described the resources, processes, goals and rules of the company.

Within the framework of the method, 4 main categories of business model are used:

1. Resources - different objects that are used or participate in business processes (we can talk about materials, products, people, information).

2. Processes are activities that result in the transition of resources from one state to another according to certain business rules.

3. Goals - the purpose of business processes. They can be divided into components and correlate these sub-goals with specific processes.

4. Business rules - conditions or restrictions on the implementation of business processes (functional, structural, behavioral). Rules can be defined using the OCL language.

5. The main diagram of the UML method is the activity diagram. Ericsson-Penker demonstrates the process as an activity with the "process" stereotype (the representation is based on the extension of the IDEF0 method). A complete business model includes many views that are similar to software architecture views. All views are separately expressed in one or more UML diagrams. Charts may include different types and depict goals, rules, processes and resources in interaction. The method uses 4 different views of the business model:

Rational Unified Process

There is also business process modeling according to the Rational Unified Process (RUP) methodology, within which two models are built:

The business process model is an extension of the UML use case model by introducing a set of stereotypes - Business Actor (actor stereotype) and Business Use Case (use case stereotype). Business Actor is a kind of role that is external to the company's business processes. Business Use Case acts as a description of the order of activities in a single process, bringing visible results to a specific person. This definition similar to the general definition of a business process, but its essence is more precise. In terms of the Business Use Case object model, this is a class. Its objects are certain flows of events in the described business process.

When describing a Business Use Case, you can also indicate the goal. It, as in the case of the Eriksson-Penker method, is modeled using a class with the "goal" stereotype, and the goal tree is depicted as a class diagram.

For each Business Use Case, it is necessary to build an object model to describe the business process in terms of objects interacting with each other (business objects - Business Object), which belong to two classes - Business Worker and Business Entity.

Business Worker is a class that represents an abstract worker that performs specific work in a business process. Performers are in interaction and implement Business Use Case scenarios. As for the Business Entity (entity), it is an object of various actions performed by executors.

In the business analysis model, in addition to the diagrams of the above classes, there may be:

• organizational, which represent the system structure - company divisions, positions, specific persons in the hierarchy, the relationship between them, the territorial affiliation of structural departments;
• functional, which reflects the hierarchy of chains facing the administrative apparatus, with a set of function trees necessary for the implementation of existing tasks;
• informational, which reflects the structure of information that is required to perform all functions in the system as a whole;
• management models, which are a comprehensive view of the execution of business processes.
• conceptual, showing the structure of problems and goals;
• process representation, which is the interaction between resources and a process (as a set of activity diagrams);
• a structural view showing the structure of the company and resources (class diagrams are displayed);
• representation of behavior (how individual resources behave, as well as detailing resources in the form of diagrams of work, states and interactions).
• business processes (Business Use Case Model);
• business analysis (Business Analysis Model).

1. Sequence diagrams (and cooperative diagrams) that describe Business Use Case scenarios as a sequence of message exchange between objects - actors and objects that are performers. Thanks to such diagrams, it is possible to determine what responsibilities this or that performer should be assigned to, and display a set of his operations in the model.
2. Activity diagrams that describe the relationship between scenarios in one or more Business Use Cases.
3. State diagrams that describe how individual business processes behave.

There are certain advantages to the Rational Unified Process modeling approach:

• building a business process model is carried out around the interested people involved in the process and their tasks; Thanks to the model, you can understand what the company's customers need. The approach is used, for the most part, for firms operating in the service sector (trade and insurance companies, banking organizations);
• Using use case-based modeling, customers better understand business models.

But it is worth emphasizing that when modeling the work of a large enterprise that both produces products and provides services, you need to use different methods of creating models. This is due to the fact that, for example, when modeling production processes, it is better to use process modeling of business processes, in particular, the Eriksson-Penker method.

IBM WebSphere Business Modeler

IBM WebSphere Business Modeler allows you to model and simulate business processes, analyze and create reports for their improvement. The system has a number of advantages, including:

1. Extensive and best-in-class capabilities for analysis, simulation and modeling.
2. Continuous improvement of processes.
3. Improved integration options.
4. Improved return on investment.
5. Improved development features.

The main feature is more extensive opportunities for simulating business processes. In the model, you can add business values, isolate additional data. You can also export models in formats used in other applications.

When importing or defining models from other sources, it is possible to perform a more accurate analysis of the operation of business processes. You can associate processes with information models, organizations, resources. With customizable and standard reports, analysis data can be exchanged.

It is allowed to implement several versions of models at the same time and publish process models.

• A simple formula to understand that an enterprise needs business process automation

Which business process modeling standard to use

With an integrated approach to management, they mainly use the IDEF0 business process modeling standard, since this classical method. The key principle of the approach is that the company's activities are structured on the basis of its business processes, and not the organizational chart. Business processes that generate a meaningful result for the consumer are the most valuable, and in the future they need to be improved.

The IDEF0 business process modeling standard is a set of procedures and rules designed to develop a functional model of an object of a specific subject area.

The IDEF0 model is a series of diagrams with accompanying documents. Diagrams break a multi-stage object into several components (blocks), which greatly simplifies the process. Details of all blocks are shown as blocks in other diagrams. All detailed diagrams are block decompositions from the previous level. At each stage of decomposition, the diagram of the previous level is called the parent diagram for the more detailed diagram. The total number of levels in the model is no more than 5-6. Experience shows that this is quite enough to build a complete functional model of a modern company operating in any field.

Initially, the IDEF1 standard was developed to become a tool for analyzing and studying the relationship between information flows within financial activities enterprises. Modeling business processes according to the IDEF1 method is designed to show how the information structure of a company should look like.

Information modeling of business processes includes several components. The main elements are:

• diagrams - drawings of an information model with a certain structure, representing the relationship and composition of the data used based on a set of rules;
• dictionary - each element of the model is accompanied by a text description.

The main concept in IDEF1 is an entity, which is defined as an abstract or real object endowed with a set of known distinctive properties. Each entity has attributes and a name.

Since it is quite difficult to analyze dynamic systems, at the moment the standard is almost not used, and it has hardly appeared, it has ceased to be developed. Today there are algorithms and their computer implementations, with the help of which it becomes possible to turn a set of IDEF0 statistical programs into dynamic models, the basis for which are "colored Petri nets" (CPN - Color Petri Nets).

IDEF3 - IDEF14

The main element of IDEF3 is a diagram, as in IDEF0. An equally important component is the action, which is also called the “unit of work”. Actions within this system are reflected in the form of a rectangle of diagrams. Actions are called using verbal nouns or verbs. However, each has a unique identification number that is not reused, even if the action is removed during model development. In IDEF3 diagrams, the action number is usually preceded by the number of its parent. The ending of one often contributes to the beginning of another action or even several. It also happens that one action may require others to be completed before its implementation can begin.

IDEF4 is a methodology for building object-oriented systems. Thanks to IDEF4, you can visually display the structure of objects and the underlying principles by which they interact. This makes it possible to analyze and improve complex object-oriented systems.

IDEF5 is a methodology for studying complex systems.

IDEF6 - Design Rationale Capture - rationale for design actions. IDEF6 greatly simplifies the process of obtaining information about modeling, its presentation and application in the creation of firms. management systems. “Knowledge about the method” is certain circumstances, reasons, ulterior motives that justify the chosen methods for creating models. That is, “knowledge of the method” can be interpreted as an answer to the question: “Why did this particular model turn out, with these and not other characteristics?”. Most of the modeling methods focus on the models being created, without delving into their development. The IDEF6 variant is aimed specifically at development.

IDEF 7 - Information System Auditing - audit information systems. The method is in demand, but it has not been finalized.

IDEF8 - User Interface Modeling. Method for creating interfaces for interaction between the system and the operator (user interfaces). At the moment, when developing interfaces, the main attention is paid to their appearance. IDFE8 focuses on programming optimal user-interface communication at 3 levels: operation (what it is); interaction options that depend on the specific role of the user (how exactly this or that user should perform it); and, finally, on the components of the interface (the controls offered by it for the operation).

IDEF9 - Scenario-Driven IS Design (Business Constraint Discovery method) - a method for studying business constraints. Designed to facilitate the detection and analysis of limitations in the company's work environment. As a rule, when creating models, they do not fully describe the constraints that can change the course of processes in the organization. Information about the main limitations, the nature of their influence, at best, remains not fully coordinated, not rationally distributed, but often it is not available in principle. This does not always mean that the constructed models are not viable. It's just that their implementation will be accompanied by certain difficulties, which will lead to unrealized potential. However, when it is precisely the improvement of structures or adaptation to likely changes that takes place, information about the limitations becomes very important.

IDEF10 - Implementation Architecture Modeling - modeling of the execution architecture. The business process modeling system is quite in demand, despite the fact that it has not been fully developed.

IDEF11 - Information Artifact Modeling. Also in demand, but not fully developed method.

IDEF12 - Organization Modeling - organizational modeling of business processes. The method is in demand, but not fully developed.

IDEF13 - Three Schema Mapping Design - three-scheme design of information transformation. Demanded, but not finally created method.

IDEF14 - Network Design - design method computer networks, which are based on specific network components, network configurations, requirements analysis. The method also supports a decision on the reasonable allocation of funds, which allows significant savings.

Information flow diagrams DFD is a hierarchy of functional processes that link information flows. The purpose of the view is to show how each process transforms inputs into outputs, and to show relationships between processes.

According to this method, the system model is defined as a hierarchy of information flow diagrams that describe the asynchronous process of data transformation from their input into the system to issuance to the user. Information sources (entities from the outside) generate information flows that transfer data to processes or subsystems. The same transform data into new streams that transmit information to other subsystems or processes, information accumulators or external entities - data consumers.

Information flow diagrams have a number of components, the key ones being:

• external entities;
• systems and subsystems;
• processes;
• information accumulators;
• information flows.

An external entity is designated as a square, which is located above the diagram and casts a shadow on it. So it is more convenient to select a character from the rest.

A subsystem is identified by a number - that's what it's designed for. In the name field, enter its name in the form of a sentence, where there is a subject, appropriate additions and definitions.

The process is a transformation according to a certain algorithm of input information flows into output ones. Physically, it is implemented in a number of ways: by creating a department in the company that processes input documentation and reports; program preparation; using a logical device in the form of an apparatus, etc.

A process, like a subsystem, is identified by a number. The name of the process is entered in the name field - a sentence where there is an active unambiguous verb in an indefinite form (calculate, calculate, receive, check), followed by nouns in the accusative case, for example: “Enter information about current costs”, “Check the receipt of funds " etc.

About a company department, program, or hardware device that performs this process, learn thanks to information from the field of physical implementation.

A data storage device is an abstract device where information is stored. This data can be transferred to the drive at any time and, after a certain time, isolate. In this case, the options for placement and isolation can be different. As a storage device, you can use a file cabinet, microfiche, table, file, etc.

The data drive is assigned an arbitrary number and the letter D. The name of the drive is chosen so that, looking at it, the designer receives maximum information.

As a rule, the storage of information is a prototype of the future database. The information stored in it must match the model.

A data flow defines the information that is sent over a connection from a source to a destination. The flow of information on the diagram is shown as a line that ends with an arrow showing where the flow is going. Each data stream has a name that reflects the information it contains.

The construction of the DFD hierarchy is required, first of all, for a clear and understandable description of the system at all levels of detail, as well as the division of these levels into several parts with a certain relationship.

• How to put things in order in business processes if you got a “bad” company

The main stages of business process modeling

Stage 1. Identification.

At this stage, business processes are identified, the boundaries of their modeling and interactions are described, and different goals are often set. Processes may already exist in the company (then they are described as is (As Is)) or developed, adjusted (To Be).

Stage 2. Collection of information.

Based on the knowledge about the process, specialists are engaged in determining its control points, identifying in them key indicators, make a plan for collecting information about the process. All obtained data is further used for analysis.

Stage 3. Information analysis.

The information collected in the previous step is analyzed, see if they disagree with the actual data (as business requirements for the process should be developed) and resort to simulation.

Stage 4. Making improvements.

When the development of business requirements comes to an end, they begin to be implemented, making changes to the methodological documentation, information systems, carrying out a number of organizational activities, making adjustments to the reporting system, etc. Once a business process is implemented, it is considered as an active element in the process management system.

Stage 5. Implementation control.

At a certain control time set during implementation or on the basis of information collected during planned monitoring, it is analyzed how effective the introduction of the business process is. As part of the analysis, actual and planned indicators are compared and a conclusion is made whether additional changes need to be made to the business process. If yes, then they start continuously improving business processes again.

The concept of a model

Model represents an artificial, man-made object of any nature (speculative or materially realized), which replaces or reproduces the object under study.
The process of building, studying and applying models is called modeling.

Model- a simplified, approximate image that reflects the most significant (from the point of view of the purpose of modeling) properties of the original.
The correspondence of the model to the original is called the adequacy of the model.
Adequacy includes requirements for completeness and accuracy (correctness). Requirements must be met to the extent that is sufficient to achieve the goal.

For the same object, many different models can be built to meet different goals.

Watch Appearance Model

Structural diagram of the watch

Similarity types: direct (model, photograph), indirect (similarity by analogy), conditional (based on agreements).

The modeling process has the property of dynamism: models develop, are specified, pass one into another.

Model classification

Cognitive (explanatory) models reflect already existing objects.

Normative (pragmatic) models reflect the objects to be implemented.
Gradations of normative models: from the reference (for a whole class of objects) to the model of a specific object.

Static Models do not take into account the time factor.
Dynamic Models reflect changes in an object over time. The dynamic model itself can be static or dynamic (simulation model).

material models built from real objects.
abstract patterns - these are ideal constructions made by means of thinking, consciousness.

Declarative Models reflect properties, structures, states of objects.
Procedural Models reflect procedural, operational knowledge.

Deterministic Models reflect processes and phenomena that are not subject to chance.
Stochastic- reflect random processes described by probabilistic characteristics and statistical patterns.

Formalized Models may not have a meaningful meaning.
In content models the semantics of the modeled object is preserved.

Model description languages

Model description languages: analytical, numerical, logical, set-theoretic, linguistic, graphic.

Graphic models (schemes, diagrams, graphs, drawings)- visible.
Notation- system symbols(signs) and the rules for their use, adopted in a specific methodology.

Notation requirements:

• simplicity- a simple sign is preferable to a complex one;
• visibility- at least a remote resemblance to the original;
• individuality - sufficient difference from other designations;
• uniqueness- it is impossible to designate different objects with one symbol;
• certainty- clear rules for using the model;
• respect for established traditions.

The business model reflects:

• the functions that the business system should perform - what it does, for whom, for what purpose;
• processes, the sequence of individual steps of processes (works, operations);
• organizational structures that ensure the implementation of processes;
• material and information flows arising during the execution of processes;
• the data required in the execution of processes and the relationships between these data.

Business Modeling Methods

Based on the sequential decomposition of the system into smaller and smaller subsystems.

Principles of the structural approach:

• "divide and conquer" - breaking complex problems into many smaller tasks that are easy to understand and solve;
• hierarchical ordering - the organization of the constituent parts of the problem into hierarchical tree structures.

Two groups of methods: modeling functional structure and data structure

The most widely used methodologies are:

• IDEF0 - functional models based on the SADT method;
• IDEF1X - Entity-Relationship Data Diagrams (ERD);
• IDEF3 - workflow diagrams (Work Flow Diagrams);
• DFD - Data Flow Diagrams.

Designed to create system models for the purpose of their subsequent implementation in the form of object-oriented programs

The most famous methods:

• Booch'93 G. Booch,
• OMT J. Rumbach
• OOSE by A. Jacobson
• UML (Unified Modeling Language) - based on Booch'93, OMT, OOSE

The main structure-forming element is the object.
In programming, an object is a structure that combines data and procedures.
In the business model, objects- these are business process participants (active objects) and passive objects (materials, documents), on which active objects perform actions.

Allows simulation on a computer (using special programs) the processes of functioning of a real system (in compressed time mode or step by step mode).

The most common methods:

• Petri nets and colored Petri nets (CPN, Colored Petri Nets);
• GPSS (General Purpose Simulating System) - a unified simulation language;
• SIMAN (SIMulation ANalysis) is a visual modeling language.

Integrated modeling methods combine different kinds of models– structural analysis, object-oriented, simulation, etc.

• ARIS (Architecture of Integrated Information System) allows you to reflect in a single integrated model: organizational structures, functions, data, processes. Uses many types of models.
• G2 - methodology for creating dynamic intelligent systems allows you to model processes using expert knowledge.
• BRM (Business Rules Management) is a business rules management methodology.

Structural Methodologies

is based on the SADT (Structured Analysis and Design Technique) Ross method, designed for a structured presentation of system functions and analysis of system requirements.
IDEF0-model consists of diagrams and text fragments. In the diagrams, all the functions of the system and their interactions are presented as blocks (functions) and arcs (relations).

The main elements of the model:

• Function block (Activity) – transformation (activity);
• Outputs (Output) - the result of the transformation;
• Inputs (Input) - objects that are converted to Outputs;
• Control (Control) - information about how the transformation occurs;
• Mechanism - objects that perform the transformation.

Function block can be decomposed - represented as a set of other interconnected blocks that describe the original block in detail.


Thus, The IDEF0 model consists of a set of hierarchically linked diagrams
In the diagram, the blocks are connected by arcs: the output arcs of some blocks can be the inputs (control, mechanism) of others.
Arcs with one free end have a source or destination outside the diagram. Letters are used to designate external arcs:

• I (Input),
• C (Control),
• O (Output) and
• M (Mechanism).

Types of links between blocks:

IDEF3 Methodology

IDEF3 models are used to document technological (information) processes, where the sequence of the process is important

There are four elements of the IDEF3 model:

Unit of work - display actions, processes, events, stages of work. A unit of work can only have one input and one output.

Links (Referents):
the necessary elements to complete the process (raw materials, materials);
the result of the process (product);
process activators (client, supplier).

Links which are of two types:
transfer activities from one unit of work to another


connect the link to the unit of work (activate the unit of work)

Crossroads – elements of the model, due to which the logic and sequence of the execution of the process stages are described.
There are two types:
Confluence Crossings – Fan-in

Intersection types

the output process will start if all input processes have finished

after the end of the input process, all output processes will start

the output process will start if all input processes have terminated at the same time

after the completion of the input process, all output processes will start, and they will start simultaneously

the output process will start if one or more input processes terminate

after the completion of the input process, one or more output processes will start

the output process will start if one or more input processes have completed, and completed at the same time

after the completion of the input process, one or more output processes will start, and they will start simultaneously

the output process will start if only one input process has completed

after the input process ends, only one output process will start

Rules for creating intersections

1. Each confluence intersection must be preceded by a branch intersection.
2. A merge AND junction cannot follow a synchronous, asynchronous, or exclusive OR branching junction.
3. An XOR merge intersection cannot follow an AND branch intersection.
4. An intersection that has one arrow on one side must have more than one arrow on the other.
5. An intersection cannot be both a junction and a branch at the same time. In a situation where it is necessary to simultaneously merge and branch work flows, a cascade of intersections is introduced.

Unit of Work Rule

Only one sequence link can enter and exit a block. Crossings are used to display multiple entrances and exits.
Multiple job decomposition is allowed:
for the same work, several decomposition diagrams can be created (to describe different options for the implementation of the work).

Job number A13.1.2 means:
parent work has code A13,
decomposition number - 1
the number of the work on the current diagram is 2.

DFD Methodology

DFD data flow diagrams allow you to effectively and visually describe the processes of document circulation and information processing.
Two notations are used: Jordan and Gein-Sarson

Types of structural elements (in Hein-Sarson notation):
1. Processes (functions, operations, actions) that process and modify information. Processes show how input data streams are transformed into output

2. Data streams, which denote the interaction of processes with the outside world and with each other. A data flow connects the output of a process (object) to the input of another process (object).

3. Data warehouses- represent the actual data to which access is carried out. This data can be created or modified by processes.

4. External entities- define external elements that participate in the process of information exchange with the system. External entities represent inputs to the system (sources of information) and/or outputs from the system (recipients of information). Examples: customer, staff, supplier, client, warehouse, bank

Example:

Object Oriented UML

UML language was developed to create models of information systems (IS) with a view to their subsequent implementation in the form of object-oriented programs.
All ideas about the model of a complex system are fixed in the form of diagrams - special graphic structures (diagrams, graphs).
There are 8 main types of UML diagrams, reflecting various aspects: the processes performed by the system (services provided to the user), the sequence of algorithmic operations performed by the system,
the structure of program objects, their interaction (message exchange), etc.

Currently, the UML language is used not only to create IS, but also to analyze and redesign business processes:
instead of IS process models, business process models are built,
instead of program objects, the models reflect objects of business processes (performers, products, services, etc.),
instead of the IS environment (IS users), the business environment (suppliers, partners, customers) is modeled.

Reflects the main business processes, their interaction with the environment.
Starts with building an external diagram (Use Case Diagram) showing how the business is seen from the outside

— the subject of the business environment. Examples of actors: Client, Buyer, Supplier, Partner, Shareholder, Customer.

- a relatively complete sequence of actions within a certain business process, bringing a tangible result to a particular actor.
Example use cases: Product Manufacturing Product Sales, Service, Product Development, Marketing and Sales.

Instance (implementation) of a use case- a specific variant of the course of events - a class of precedents - a generalized precedent.

For actors, the concepts of class and instance are also distinguished.
Actors of different classes may have common characteristics or common obligations.
One can introduce a generalized class of actors.

Relationships of communication are established between precedents and actors (association relationship with the communicate stereotype).
They model the relationship of use cases with the environment (information and material flows)
Between precedents, as a rule, only dependency relations are established, as well as relations that structure precedents - relations of generalization, inclusion (dependencies with the include stereotype), extensions (dependencies with the extend stereotype).

For each of the elements of the model, a specification is compiled.
In the actor specification: name, stereotype (business actor), description, list of attributes, list of obligations, etc.

In the use case specification: name, stereotype (business use case), brief description, list of subdiagrams and documents related to the use case

Use Case Event Stream

Stream of events- description of precedents by a sequence of steps

The flow of events for the "Selling a product" use case:

• The seller receives the customer's order
• If the order contains a finished product, the Seller checks the availability of the product in stock. If the product is out of stock, the use case ends. If the product is in stock, then the use case continues from step 6.
• If a custom product is indicated in the application, the Seller forms an order and transfers it
• Product manufacturer.
• The manufacturer manufactures the product in accordance with the requirements of the client and reports the readiness to the Seller.
• The manufacturer sends the product to the Warehouse.
• The Seller informs the Client about the readiness of the product and accepts payment from the Client.
• The Seller informs the Sender of the quantity of the product and the customer's address and orders the transport.
• The sender receives the product from the warehouse and delivers it to the customer.

Tracks:
If several objects participate in the execution of the use case, then the actions performed by each object are placed on the corresponding track.

Structuring use cases

To simplify the description of a use case, it is necessary to structure it. Let's consider two ways of structuring.
1. Selection of fragments
If a fragment representing a relatively complete sequence of events can be distinguished from the description of a precedent with alternative streams of events, then this fragment is considered as a separate precedent. An include relationship is established between the selected precedent and the base case.
Sometimes an extension relation is used. It is set between a base use case and a use case containing some additional behavior that is executed under certain conditions.

2. Generalization
If several use cases have similar behavior, then you should separate the common behavior into a separate use case (parent). A generalization relationship is established between each of the particular precedents and the parent one.

Business process object model

Reveals the internal structure of the business: what types of resources are used to implement use cases and how they interact.
Business model object classes:
active - process executors (business worker stereotype), for example, Vendor, Manufacturer, Developer;

passive - entities (business entity stereotype), for example, Product, Order, Invoice.

Sometimes among the active are:
interface (stereotype Boundary) - active objects interacting with the environment, i.e. with actors. Examples - Seller, Registrar, Secretary..
control objects (stereotype Control) are active objects that participate in the execution of processes, but do not have contact with the environment. Examples - Product Developer, Manufacturer, Project Manager..

Classes and Objects

Class– some type of objects (a set of similar objects),
instance- a specific object (class representative).

Objects have:
name (class name can be specified through a colon)
properties - described using attributes
behavior - represented by operations

Objects of the same class have the same set of attributes and operations.
They differ in attribute values, because class instances describe the characteristics of a particular object.

Dynamic and static interaction diagrams are used to display the relationships of objects in the process of executing a precedent.
A class diagram is used to display structural and associative links between classes.

Use case "Selling a custom product":
The seller receives the customer's order
The Seller forms an order and transfers it to the Product Manufacturer.
The manufacturer makes the product.
The manufacturer sends the product to the Warehouse and informs the Seller about the readiness.
The Seller informs the Client about the readiness of the product and accepts payment from the Client.
The Seller informs the Sender of the client's address and orders the transport.
The sender receives the product from the warehouse and delivers it to the customer.

Sequence diagram elements

In the upper part of the diagram, there are active objects (and actors) in the form of a rectangle (“little man”), from which a “life line” is drawn down.
Message (message) – a segment of a horizontal line with an arrow drawn from the lifeline of the object (actor) sending the message to the lifeline of the object (actor) receiving the message.

The message relationship models material or information flow.
Reception of messages initiates some action by the receiver

Messages are ordered by time: the first message is displayed at the top of the diagram, the next one is lower, the next one is even lower, and so on.
However, the chart does not contain a time metric (distance between messages is not a time interval)

Collaboration Diagram

class diagram

Class diagram (Class diagram) is used to display stable relationships between classes of objects

Description of objects

The ARIS (Architecture of Integrated Information System) methodology was developed in the 1990s by Professor A.-V. Scheer


For each of these representations, several types of models can be built (in ARIS 5.0, the total number of diagram types is 130)

There are four main types of models (four representations):

• organizational models - the structure of the organization (hierarchy of departments and positions);
• functional models - a hierarchy of functions (goals) performed in the organization;
• information models - the structure of information necessary for the implementation of system functions;
• process/management models - a comprehensive view of the implementation of business processes within the system

Organization Chart

Organizational models include Organizational chat.
The main types of objects in this model are:

The model is built hierarchically- from the top level of the structure to the bottom.
The lowest level is the description of subdivisions at the level of positions - staff units occupied by specific employees.

Feature Tree

Only one type of object is used - function (work, action, stage within the process).
At the top level, functions represent business processes. The detailing of functions forms a hierarchical structure.
The lowest level represents the basic functions (which can no longer be divided into constituent elements).

Process event chain

Main types of objects:

• Function - some (process step). A function can be associated with: performers, input and output documents, software, etc.
• An event is any completed state of an object that affects the further course of the process. On the one hand, events are a stimulus for the performance of functions, on the other hand, they are their result.
• Logical operators (AND, OR, XOR) show branches in the process flow.

Examples:

Model Integration

The relationship between ARIS models is provided through two mechanisms: integration and refinement.

By storing objects in a single repository (special database).
When a new object is created, a separate entry appears in the repository that specifies the description of the object.
An object can be copied from one model and pasted into another using the Copy/Paste commands.

Model detailing

2. Detail mechanism: for objects of the current model, you can set links to other models, which are a detailed description of this object.
The drill types that are allowed to be used depend on the object type.

The drill down mechanism avoids overloading models with information, making them more visual.

Tools

Tools Capabilities

• visual modeling that allows you to create a graphical model (in the form of diagrams, flowcharts, graphs) interactively using visual tools;
• model validation - verification of compliance with the syntactic and semantic rules for building models defined in the modeling methodology used;
• analysis of the constructed models - the ability to calculate the cost and time characteristics of processes, test the hypotheses "what if ...", identify logical errors, etc.;
• documentation - output of information presented in models in the form of text descriptions contained in files of a given format;
• integration of various information systems - the ability to exchange information about the simulated processes between different applications;
• automatic creation of components of information systems - for example, automatic code generation (creation of computer programs), generation of databases based on the entered models and diagrams.

References

1. National Research Tomsk Polytechnic University. Tomsk. Silich V.A. 2016. 75 p. Presentation for the lecture.

business process modeling tools

In Russia, the following modeling tools are widely used for modeling and analyzing business processes: Rational Rose, Oracle Designer, AllFusion Process Modeler (BPWin) and AllFusion ERwin Data Modeler (ERWin), ARIS, power designer. Abroad, in addition to those mentioned, such tools as System Architect, Ithink Analyst, ReThink, etc. are actively used. Table 1 presents a list of tools involved in the review. The information provided includes:

• name of the tool;
• data about the supplier and representative in Russia;
• a brief description of instrumental tool.

Table 1. List of tools

№	Name	Provider	Main representative in Russia	a brief description of
1	BPWin and ERWin	Computer Associates (formerly Platinum) http://www.ca.com	Interface Ltd. http://www.interface.ru	BPWin is a visual modeling tool for business processes. ERWin is a tool used to model and create databases of arbitrary complexity based on entity-relationship diagrams.
2	Oracle Designer	Oracle Company http://www.oracle.com	Representative office of Oracle in Russia http://www.oracle.com/global/ru/index.html	Functional tool for describing the subject area. Included in the Oracle9i Developer Suite toolkit for designing software systems and databases that implement CASE technology and Oracle's own IS development methodology - "CDM", allowing the development team to carry out the project, from business process analysis through modeling to code generation and obtaining prototype, and later on the final product. It makes sense to use this tool when targeting the entire Oracle product line used to design, develop, and implement a complex software system. Member of the Russian market. Localized. Sales, support, training in Russia.
3	Rational Rose	IBM (formerly Rational Software, now a division of IBM) http://www.ibm.com	Representative office of IBM in Russia http://www.ibm.com	Modeling tool for object-oriented information systems. Allows you to solve almost any task in the design of information systems: from the analysis of business processes to code generation in a specific programming language. Allows you to develop both high-level and low-level models, thereby implementing either abstract design or logical design. One of the leaders of the Russian market. Localized. Sales, support, training in Russia.
4	ARIS	IDS Scheer AG http://www.ids-scheer.com	Business Logic Company http://www.blogic.ru	An integrated business process modeling tool that integrates a variety of system modeling and analysis methods. First of all, it is a tool for describing, analyzing, optimizing and documenting business processes than a software design tool. Leader in the global market. Localized. Sales, support, training in Russia.
5	System Architect	Telelogic (formerly Popkin Software, now a division of Telelogic) http://www.telelogic.com	Telelogic in Russia http://www.telelogic.com	System Architect is a universal CASE tool that allows you to carry out not only data design, but also structural modeling. The data design and ER diagramming tool is one of the components of this product. One of the world leaders, not yet featured on Russian market. Localization tentatively by July 2006. Sales and support from the Netherlands so far.
6	power designer	Sybase Company http://www.sybase.com	Sybase Company http://www.sybase.ru	PowerDesigner is a business process modeling, database design and object modeling tool. A participant in the Russian market, a pursuer of leaders in the world market. There is support, sales, training in Russia. There is no information on the number of licenses sold, the number of users, so it is quite difficult to estimate the prevalence in Russia.
7	Re-Think	Gensym company http://www.gensym.com		Graphical object-oriented environment for creating and maintaining intelligent applications for monitoring, diagnosing and managing complex dynamic systems in real and simulated situations. One of the persecutors of world leaders.
8	Itink Analyst	High Performance Systems Company http://www.hps-inc.com	Company Tora-center http://www.tora-center.ru	Package for situational modeling. Allows you to build visual and accurate models of the most complex political and economic situations using a library of basic models and methods of system dynamics. Also used in analysis investment projects and reengineering. One of the participants in the global market. The package is not distributed on the Russian market. There is no Russian interface. Sales, support and training in Russia is carried out by only one company. Educational materials in Russian exist.
9	Workflow Modeler(formerly Design/IDEF)	Meta Software Company http://www.metasoftware.com	Information on Russian companies representing this product was not found.	A package for functional and information modeling, analysis and design of business processes. It is used as an integral part of some well-known packages such as CIM (Computer Integrated Manufacturing) and CAE (Computer Aided Engineering) and adopted as a standard for projects funded by American and European sponsors. One of the participants in the global market.

We single out the main criteria that allow us to choose from the presented modeling tools those whose use in Russia could more likely justify itself. These criteria are:

• stable position of the product in the market(its lifetime, product development program, problem reporting system, set of applications, etc.);
• product prevalence(number of licenses sold, presence, size and level of activity of the user group);
• vendor support availability. Such services may include telephone hotline", technical and advisory support through a representative of the supplier in Russia;
• accessibility of education. Training may be conducted at the premises of the supplier's representative in Russia, the user, or elsewhere;
• availability of product materials. These may include computer-based learning materials, study guides, books, articles, information on the Internet, demos.

From the list of tools given in the table, for a more detailed analysis, we select those software products that meet the specified criteria. In this case, BPWIn / ERWin, Oracle Designer, Rational Rose, Power Designer, ARIS fall within the scope of our further consideration, for which a more detailed description is provided below.

BPWin and ERWin from Computer Associates. Computer Associates International Inc. (CA) is one of the top five manufacturers software, offering tools for modeling, backup, enterprise infrastructure management (networks, servers, etc.), information security, business intelligence, etc. The BPWin package is based on the IDEF methodology and is intended for functional modeling and analysis of the enterprise. The IDEF methodology, which is the official US federal standard, is a set of methods, rules and procedures designed to build a functional model of an object in any subject area. The IDEF functional model reflects the functional structure of an object, i.e. the actions it performs and the connections between these actions.

BPwin features:

• supports three standard notations at once - IDEF0 (functional modeling), DFD (data flow modeling) and IDEF3 (work flow modeling). These three main perspectives allow you to describe the subject area in the most comprehensive way;
• allows you to optimize procedures in the company;
• fully supports costing methods by volume economic activity(functional cost analysis, ABC);
• facilitates ISO9000 quality certification;
• integrated with ERwin (for database modeling), Paradigm Plus (for modeling software components), etc.;
• integrated with Arena simulation tool;
• contains its own report generator;
• allows you to effectively manipulate models - merge and split them;
• has a wide range of tools for documenting models, projects.

The ERWin package is a conceptual database modeling tool. It is used in modeling and creating databases of arbitrary complexity based on "entity-relationship" diagrams. Currently, ERWin is the most popular data modeling package due to its support for a wide range of DBMS of various classes. ERWin features:

• supports the SADT structural modeling methodology and the following notations: IDEF1x standard notation for ER-diagrams of data models, IE notation and a special notation for designing data warehouses - Dimensional;
• direct (creation of a database based on a model) and reverse (generation of a model from an existing database) design is supported for 20 types of DBMS: desktop, relational and specialized DBMS designed to create data warehouses;
• integrated by the Computer Associates product line to support all stages of IS development, Oracle Designer CASE tools, Rational Rose, development tools, etc.;
• allows you to reuse components of previously created models, as well as use the developments of other developers;
• collaboration of a group of designers with the same models is possible (using AllFusion Model Manager);
• allows you to transfer the database structure (not the data itself!) from a DBMS of one type of DBMS to another;
• allows you to document the structure of the database.

Oracle Designer by Oracle. The Oracle Designer toolkit offers an integrated solution for developing enterprise application systems for Web and client/server applications. Oracle Designer is involved in every phase life cycle software development - from business process modeling to implementation. The use of a single repository makes it possible to use any of its components for the rapid development of scalable, cross-platform distributed applications. The task of Oracle Designer is to collect data about the needs of users and automate the construction of flexible graphical applications. Oracle Designer is used not only to create applications, but also to keep track of the changes that inevitably occur during the operation of the system. Graphical project definition models integrated with the multi-user repository make it much easier to work with Oracle Designer. The tools are built around common methodologies that span the entire development life cycle and allow users to work in a way that is familiar to their organization. This provides flexibility and an open approach to software development by using only those parts of the product that are required for a given task. The development process supports RAD, JAD, information design, waterfall method, iterative method, etc. Using these principles, you can achieve a successful balance of organizational needs and technological capabilities, and even effectively manage the risk associated with frequent unavoidable and important changes both in one area and in the other. Oracle Designer conceptual modeling tools include:

• ER-diagrams (diagrams of the information structure of the subject area, represented as objects and their relationships);
• functional hierarchy diagrams that describe the functions that the system performs;
• diagrams of data flows circulating in the enterprise.

Such models present information needs in a convenient and visual way for perception, which makes them a good means of communication between designers and users in the process of refining the setting of tasks. Any developer is interested that the description of the conceptual model be used to create specifications that describe the structure and main components of the future system. In Oracle Designer, all system design specifications are developed from conceptual level models and ensure that all the requirements and constraints contained in them are met. The resulting system components can be converted into real database objects, screen forms and reports. The final part of the project development - automatic generation of server components - is possible not only for the Oracle database server, but also for Microsoft SQL Server, DB / 2, Sybase and a number of others. Any changes in business processes can be made to the models and a modified application is immediately generated, based on new business schemes. At the same time, everything developed earlier will be saved and will be included in the new project. Open Designer automatically creates reports that contain all information about the project and can be used as a set of documents reflecting the current state of the project.

IBM Rational Rose. IBM Rational Rose is part of the IBM Rational Suite and is designed to model software systems using a wide range of tools and platforms. Rational Rose is one of the leading visual modeling tools in the software industry with full UML support and multilingual team development support. The tool fully supports the component-oriented process of creating IP. Any project participant - analysts, modelers, developers, and others - can use models built in Rational Rose to greater efficiency creating the final product. For business analysts, the Rational Rose tool provides the ability to describe and analyze business processes in a given subject area in detail. System analysts, using these descriptions, will be able to develop the necessary IS functionality that will best satisfy the customer's needs. For architects, the Rational Rose tool will be useful in creating a powerful and flexible system architecture. For database analysts, Rational Rose gives you the ability to visually design and generate databases of any size. Thus, you can create Microsoft SQL Server, Oracle, Sybase, SQL Anywhere, IBM DB2 and any other databases that support the ability to run ANSI SQL standard scripts. Any models created with this tool are interrelated: business model, functional model, analysis model, design model, database model, component model, and system physical deployment model. It is possible to create templates for architectural solutions that allow you to use the experience gained in previous projects. There are Rational Rose extensions that allow you to perform skeletal (round-trip) development of ISs created based on C / C ++, Java, Smalltalk, Ada, Object Pascal (Borland Delphi), etc. Thus, you can generate a program code framework on any from the specified languages ​​or perform a reverse engineering procedure, which allows you to create a model based on existing code. It is possible to publish the model on the Internet, which serves as the basis for bringing together the work of remote development teams. The integration of Rational Rose with Rational RequisitePro allows you to develop a complete set of requirements based on a visual model that must be implemented to create the final product. Rational Rose integration with Rational TestManager allows you to create test scripts based on a visual model. The integration of Rational Rose with Rational ClearCase allows you to version control the whole model or in parts. Rational Rose integration with Rational SoDA automates the process of creating documents and reports based on a visual model.

Sybase PowerDesigner. Sybase has traditionally been a leading provider of information technology to the global market since its founding. financial institutions: Sybase technologies are used by 90% of the world's securities market companies, 60% of the world's banks and 68% of Wall Street companies. Since 1996, when an office was opened in Moscow, Sybase has been actively working in Russia and other CIS countries. In April 2002, the company's offices were opened in St. Petersburg and Kyiv. Sybase offices in Moscow, St. Petersburg and Kyiv provide comprehensive work with clients, including the supply of technologies, equipment, development of complete solutions, user training, full-featured technical support and consulting services. PowerDesigner is a comprehensive application and business process modeling and development solution for organizations that need to quickly, consistently, and cost-effectively build or reengineer business applications. PowerDesigner removes the following barriers to effective development projects: differences in the professional training of project participants, heterogeneous platforms and an abundance of development languages ​​- something that is typical for most modern companies. This allows you to focus on the business needs of creating applications throughout the entire development process - from system analysis and design, to the direct generation of code for the application. The latest version of the product, PowerDesigner, has new capabilities for business process modeling, UML-based object modeling, and supports both traditional and emerging modeling technologies within one advanced graphical environment. This allows you to significantly reduce the costs and time of the project, which must operate on various platforms and tool environments. One of the main advantages of PowerDesigner is also the use of an enterprise-wide repository to store and manage all information related to application modeling and design at all levels of business in the company. This allows you to properly organize the workflow and dramatically increase the efficiency of the developer. Key features of PowerDesigner:

• Business Process Modeling: PowerDesigner allows non-technical business professionals to design and model business processes based on business objectives and terms they know, using a simple and intuitive graphical non-technical model.
• Data modeling: PowerDesigner allows you to design and generate a database schema through two-level (conceptual and physical) relational database modeling that supports classic database design techniques. It also has built-in data warehouse modeling tools.
• Object Modeling: PowerDesigner offers a complete technology for analyzing and designing systems using the UML standard (business process diagrams, execution sequences, classes and components). Based on the class diagram, PowerDesigner automatically generates and reengineers code for popular frameworks such as JavaTM (including EJB 2.0), XML, Web Services, C++, PowerBuilder, Visual Basic, and more through a custom code generator.
• Enterprise Repository: The Enterprise version of PowerDesigner contains the enterprise class repository functionality. The repository allows all members of your team to easily view and share models and other information. The repository is highly scalable and supports user role-based security, version control, search, and reporting capabilities.

ARIS from IDS Scheer AG. Currently, there is a tendency to integrate various methods of modeling and analysis of systems, which manifests itself in the form of the creation of integrated modeling tools. One such tool is a product called ARIS, developed by the German company IDS Scheer. IDS Sheer AG was founded in 1984. The main direction is software and consulting. The company currently serves 4,000 customers in 50 countries through its network of offices and partners. The quality of IDS Scheer solutions was confirmed in June 2005 by the gold medal of the Poznań International Fair, where only the best products are awarded. And also in July 2005, when ARIS 7 software products were introduced to the world market with completely new web products - all of them have common feature- intuitive and expressive interface. The ARIS system is a set of tools for analyzing and modeling the activities of an enterprise. Her methodological basis is a set of different modeling methods that reflect different views on the system under study. The same model can be developed using several methods, which allows specialists with different theoretical knowledge to use ARIS and customize it to work with systems that have their own specifics. The ARIS modeling technique is based on the theory of building integrated information systems developed by Professor August Scher, which determines the principles of visual display of all aspects of the functioning of the analyzed companies. ARIS supports four types of models that reflect various aspects of the system under study:

• organizational models representing the structure of the system - hierarchy organizational units, positions and specific persons, the relationship between them, as well as the territorial binding of structural units;
• functional models containing a hierarchy of goals facing the management apparatus, with a set of function trees necessary to achieve the goals;
• information models that reflect the structure of the information necessary for the implementation of the entire set of system functions;
• management models representing a comprehensive view of the implementation of business processes within the system.

To build these types of models, both ARIS' own modeling methods and various well-known modeling methods and languages, in particular, ER and UML, are used. In the modeling process, each aspect of the enterprise is first considered separately, and after a detailed study of all aspects, an integrated model is built that reflects all the links between various aspects. ARIS does not impose restrictions on the sequence of building the above types of models. The modeling process can be started from any of them, depending on the specific conditions and goals pursued by the developers. Models in ARIS are diagrams, the elements of which are various objects - "function", "event", "structural unit", "document", etc. Various connections are established between objects. Each object corresponds to a specific set of attributes that allow you to enter additional information about a particular object. Attribute values ​​can be used in simulations or for cost analysis. Thus, based on the results of this stage, a set of interrelated models emerges, which are the source material for further analysis. It is worth noting several features of the ARIS system. The first one is the family of ARIS software products focused on process description. The main business model of ARIS is eEPC (extended Event-driven Process Chain - an extended model of the event-driven process chain). Essentially, the eEPC model extends the capabilities of IDEF0, IDEF3, and DFD with all their strengths and weaknesses. The second feature is that the ARIS system has an internal database that allows you to check the model for consistency, integrity, and verify the model. This is not the case for other products. The third feature: ARIS is the only system focused on the description of the business, where there are different views on the business system, which we can evaluate and consider from different angles, which is not the case in other software products. Over the past five years, ARIS has been a confident leader among modeling tools.

We indicate the main purpose of each product under consideration from a variety of its applications:

• Erwin, Power Designer and Rational Rose tools are more suitable for database modeling;
• Oracle Designer, Power Designer and Rational Rose are more suitable for modeling the components of applications being developed;
• BPwin, ARIS and Rational Rose are more suitable for business process modeling.

Table 2 below compares the functionality and features of workspaces designed for business process modeling.

Table 2. Comparative analysis by basic functions

Comparative functional analysis
	Functionality, environment	ARIS	BPWin	Rational Rose
1	Supported standard	eEPS (IDEF3 extension), ERD, UML, own methods in a different notation, which implement the main meaning of the IDEF, DFD methods	IDEF0, IDEF3, DFD	UML
2	Availability of expressive means of graphic display of models	The representativeness of the models is high		Representativeness of models is low
3	Modeling diagrams of various types	+	+/-	+/-
4	Functional cost analysis	+	+	+/-
5	Simulation	+	+/-	-
6	Ability to decompose an object	+	+	+
7	Registration of project documentation: generation of technological and work instructions	+	+/-	+
8	Storage of business models	+	+/-	+/-
9	Control and ensure the integrity of design data	+	+/-	+
10	Maintaining a library of typical business models	+	+/-	+/-
11	Possibility of group work	+	+	+
12	Easy to learn product	Hard	Just	Hard
"+" - yes "+/-" - partial implementation that needs to be improved by other tools "-" - No

A business process is a logical, sequential, interrelated set of activities that consumes resources, creates value, and delivers results. In the international standard ISO 9000:2000, the term "process" is adopted, but at present these terms can be considered synonymous. Business process modeling is effective remedy finding ways to optimize the company's activities, which allows you to determine how the company works as a whole and how activities are organized at each workplace. The methodology (notation) for creating a model (description) of a business process is understood as a set of ways in which objects real world and the links between them are represented as a model. Each object and links is characterized by a number of parameters or attributes that reflect certain characteristics of a real object (object number, name, description, execution time (for functions), cost, etc.).

The basis of many modern methodologies for modeling business processes was the SADT methodology (Structured Analysis and Design Technique - a method of structural analysis and design), the IDEF family of standards (Icam DEFinition, where Icam is Integrated Computer-Aided Manufacturing) and algorithmic languages.

The main types of methodologies for modeling and analyzing business processes:

• Modeling of business processes (Business Process Modeling). The most widely used methodology for describing business processes is the IDEF0 standard. Models in IDEF0 notation are intended for a high-level description of a company's business in a functional aspect.
• Description of workflows (Work Flow Modeling). The IDEF3 standard is intended to describe workflows and is close to algorithmic methods for constructing flowcharts.
• Description of data flows (Data Flow Modeling). The DFD (Data Flow Diagramming) notation allows you to reflect the sequence of work performed during the process, and the flows of information circulating between these works.
• other methodologies.

IDEF0

The model consists of diagrams, text fragments and a glossary with links to each other. Diagrams are the main components of the model, all functions and interfaces are presented as blocks and arcs. The connection point of the arc with the block determines the interface type:

interface type:

• Control information enters the block from the top.
• The input information is included in the block on the left.
• The results exit the block on the right.
• The mechanism (human or automated system) that performs the operation enters the unit from below.

Each component of the model can be decomposed (deciphered in more detail) in another diagram. It is recommended to stop modeling when the level of detail of the model satisfies its purpose. The total number of levels in the model should not exceed 5-6.

Diagramming begins with the representation of the entire system in the form of a single block and arcs depicting interfaces with functions outside the system. Then the block that represents the system as a single module is detailed in another diagram using several blocks connected by interface arcs. Each detailed diagram is a block decomposition from the diagram of the previous level. At each decomposition step, the diagram of the previous level is called the parent diagram for the more detailed diagram.

Such diagrams do not explicitly indicate either sequence or time. The method has a number of disadvantages: the complexity of perception ( a large number of arcs in diagrams and a large number of decomposition levels), the difficulty of linking several processes.

IDEF3

This method is designed to model the sequence of actions and the interdependence between them within the processes. IDEF3 models can be used to drill down IDEF0 functional blocks that do not have decomposition diagrams.

IDEF3 diagrams display an activity as a rectangle. Actions are named using verbs or verbal nouns, and each action is given a unique identification number (the action number is usually preceded by the number of its parent, eg 1.1.). All links in IDEF3 are unidirectional and are organized from left to right.

Types of IDEF3 links:

• Temporal precedence, simple arrow. The source activity must complete before the end activity can begin.
• Object flow, double-tipped arrow. The output of the original action is the input of the final action. The source activity must complete before the end activity can begin. The names of streaming links must clearly identify the object that is transmitted with their help.
• Fuzzy Relationship, dotted arrow.

The completion of one action may initiate the start of the execution of several other actions at once, or vice versa, a certain action may require the completion of several other actions before starting its execution (process branching).

Process branching is reflected using special blocks:

• "And", block with sign &.
• "Exclusive OR" ("one of"), block with X sign.
• "OR", block with O sign.

If the actions "AND", "OR" must be performed synchronously, this is indicated by two double vertical lines inside the block, asynchronously - one.

The IDEF3 method allows you to decompose an activity multiple times, which ensures that alternative process flows are documented in a single model.

DFD

The purpose of such a representation is to demonstrate how each process transforms its inputs into outputs. It can reflect not only information, but also material flows.

Also, as in other models, decomposition is supported.

The main components of data flow diagrams are:

• External entities (material object or individual, which are the source or receiver of information, for example, customers, personnel, suppliers, customers, warehouse).
• Systems and subsystems (for example, a subsystem for working with individuals).
• Processes (transformation of input data streams into output ones in accordance with a certain algorithm; physically, this can be, for example, a subdivision of an organization (department) that processes input documents and issues reports, a program, a hardware-implemented logical device, etc.).
• Data storage devices (abstract devices for storing information).
• Data flows (arrows on the diagram).

It is necessary to place on each diagram from 3 (less does not make sense) to 7 (more - not perceived) processes, without cluttering the diagrams with details that are insignificant at this level. The first step in building a DFD hierarchy is to build context diagrams. Typically, when designing relatively simple systems, a single context diagram with a star topology is built, in the center of which is the so-called main process, connected to receivers and sources of information. For complex systems (ten or more external entities, distributed nature and multifunctionality of the system), a hierarchy of context diagrams is built. At the same time, the top-level context diagram contains not a single main process, but a set of subsystems connected by data flows.

Each process on a DFD can be detailed using a DFD or (if the process is elementary) a specification. Specifications are descriptions of algorithms for tasks performed by processes. Specification languages ​​can range from structured natural language or pseudocode to visual modeling languages.

In business process modeling, data flow diagrams (DFDs) are used to build "AS-IS" and "AS-TO-BE" models, thus reflecting an organization's existing and proposed business process structure.

ARIS

Currently, there is a tendency to integrate a variety of modeling methods, manifested in the form of the creation of integrated modeling tools. One of these means is software, called ARIS (Architecture of Integrated Information Systems), developed by the German company IDS Scheer.

ARIS supports four types of models (and many types of models in each type) that reflect different aspects of the system under study.

Supported model types in ARIS:

• Organizational models representing the structure of the system - the hierarchy of organizational units, positions and specific individuals, the links between them, as well as the territorial binding of structural units.
• Functional models containing a hierarchy of goals facing the management apparatus, with a set of trees of functions necessary to achieve the goals.
• Information models that reflect the structure of the information necessary for the implementation of the entire set of system functions.
• Management models representing a comprehensive view of the implementation of business processes within the system.

To build the listed types of models, both ARIS's own modeling methods and various well-known modeling methods and languages, in particular, UML, are used. The modeling process can be started with any of the model types.

The main business model of ARIS is eEPC (extended Event-driven Process Chain, extended event-driven process chain model). ARIS notation eEPC is an extension of the IDEF3 notation. A business process in eEPC notation is a flow of sequentially performed work (procedures, functions) arranged in the order in which they are performed. The actual duration of the procedures in eEPC is not visually reflected. To obtain information about the actual duration of processes, it is necessary to use other description tools, for example, MS Project.

Models in ARIS are diagrams, the elements of which are various objects - "functions", "events", "structural divisions", "documents", etc. Between objects of certain types, links of certain types can be established ("performs", "makes a decision", "should be informed about the results", etc.). Each object corresponds to a specific set of attributes that allow you to enter additional information about a particular object.

The main objects of the eEPC notation are:

• Function. Serves to describe the functions (procedures, work) performed by departments / employees of the enterprise. Every function must be initiated by an event and must end with an event; Each function cannot enter more than one arrow, "starting" the execution of the function, and exit more than one arrow, describing the completion of the function.
• Event. Used to describe real events that affect the execution of functions.
• Organizational unit. For example, management or department.
• Document. Reflects real media, such as paper documents.
• Application system.
• information cluster. Characterizes a set of entities and relationships between them.
• Communication between objects. The type of relationship between objects, for example, the activation of the execution of a function by some event.
• Boolean operator. The "AND", "OR" or exclusive "OR" operator allows you to describe the branching of the process.

If, when creating a model in eEPC, you specify only the sequence of procedures, not caring about the reflection of control documents and information, the resulting models will be of low value in terms of analysis and further use.

Business process modeling has become a fashionable trend in recent years, engulfing many large (and even not very large) enterprises. In many companies, departments are growing like mushrooms. organizational development, process management departments and other divisions whose main task is to develop recommendations for improving the company's activities based on the application of the process approach. Offers in the field of process consulting are also available on the service market, including offers with a specific industry specialization (for example, in the field of setting application development processes or maintaining other IT projects, or in the field of improving company management systems).

This series of articles is devoted to the use of the process approach, business process modeling and their practical application. Topics planned for coverage in this cycle include a discussion of the most common types of models, how they are stored, their advantages and disadvantages. In addition, we will discuss integration tools with information systems and business process management tools (including solutions using business process description languages); simulation modeling of processes, control and analysis of the execution of processes in real life, creation of solutions based on business process modeling tools.

I want to draw attention to the fact that, firstly, this cycle presents the author's personal point of view on business process modeling, which is not related to the official opinions of the suppliers of the discussed tools and services; secondly, this cycle does not pretend to be a systematic presentation - it only reflects the aspects of the process approach that seemed to the author the most interesting and worthy of attention.

Briefly about the process approach

The essence of the process approach is simple. The activities of the company's employees are divided into two categories: repetitive (periodically or as a result of the occurrence of any events), called processes, and non-repeating, called projects, events or programs. From this point of view, a process is an associated set of repeatable actions that transform input and/or information into a final product (or service) according to pre-established rules. As a rule, processes make up a significant part of the activities of organizations. Given that the process has final result, considering the company's activities as a set of processes allows you to more quickly respond to changes in external conditions, avoid duplication of activities and costs that do not lead to the desired result, properly motivate employees to achieve it.

Business process modeling usually means their formalized graphical description. Although modeling the application of the process approach and improving the company's activities based on it is not mandatory, it has recently received serious attention in many companies. Next, we will discuss what problems can be solved with its help.

Practical application of business process modeling

Business process modeling is used in practice to solve a wide range of problems. One of the most typical applications of such models is the improvement of the processes being modeled. In practice, the processes are described "as is" (that is, exactly as they occur in reality), and then bottlenecks in these processes are identified in various ways, and based on this analysis, several "as it should be" models are created.

Identifying bottlenecks in processes can be done in different ways. One of them is simulation modeling. The initial data for such modeling are information about the probability of occurrence of events that affect the execution of the process, the average execution time of functions in the process and the laws of distribution of execution time, as well as other characteristics, for example, the resources involved in the process.

Another way to identify bottlenecks is based on the analysis of real processes and, accordingly, the real time of executing functions or waiting for the availability of resources. Real values ​​can either be obtained from information systems (if the process is automated to a sufficiently high degree), or determined by conventional timing and other observations.

Another way to use the business process description is to use a set of process models to generate a corporate regulatory framework, such as process regulations, business unit regulations, job descriptions. Especially often, such technologies are used when preparing a company for certification for compliance with one of the quality standards. Today, almost all business process modeling tools allow you to get data about objects on models and their relationships and present them in the form of documents, although the technologies underlying such solutions may be different.

Often, business process models are used to improve the company management system and develop a personnel motivation system - for this, company goals are usually modeled, each of which is divided into more detailed ones until this breakdown becomes so detailed that individual goals turn out to be related to activities specific employees. Then, for these purposes, quantitative indicators are formed that characterize the degree of their achievement, and on the basis of these indicators a system of personnel motivation is created.

Business process modeling is widely used in the design of information systems or other IT solutions - today, the description of processes in requirements management and specification creation has become almost a good form, and in modern terms of reference it is quite possible to see not only a list of requirements, but also process models. And, no matter what experts in the field of management and process consulting say about this topic, we should not forget that in many cases it is the task of correct automation and information support of the company's activities that is the main one when deciding on business process modeling.

The listed tasks are far from exhausting the scope of business process modeling - here are just some examples of the use of this type of modeling.

Process approach and CASE technologies

Models, Objects, and Relationships

When modeling business processes, as a rule, the concepts of model, object, and relationship are manipulated. A model is a set of graphic symbols, their properties, attributes and relationships between them, which adequately describes some properties of the modeled subject area. The possible types of models and the rules for their construction (including the graphic symbols available for use and the rules for the existence of links between them) are determined by the chosen modeling methodology, and the conventions adopted in the model used are determined by the chosen notation.

There are quite a few modeling methodologies used today in describing business processes. The most popular of them include the DFD (Data Flow Diagrams) methodology, which describes data flow diagrams that are used in requirements analysis and functional design of information systems; STD (State Transition Diagram), considering state transition diagrams for designing real-time systems; ERD (Entity-Relationship Diagrams), which considers entity-relationship diagrams that are used in the logical design of information systems; FDD (Functional Decomposition Diagrams), which describes functional decomposition diagrams; SADT (Structured Analysis and Design Technique), which is a technology of structural analysis and design that was quite popular in the 90s. Also popular lately ARIS methodology, which considers a set of different types of models (including those supported by some other methodologies) that are used to describe all subsystems of a company. No less popular is the family of IDEF methodologies used for designing business processes and data (database developers, as a rule, are quite familiar with the IDEF1X methodology describing logical and physical data models, and the IDEF0 methodology is very popular with analysts describing business processes) . The UML (Unified Modeling Language) methodology is very popular among application developers, which is used in the design of information systems and applications in order to describe the requirements for an information system, user scenarios, changes in system and data states in the process of work, and classes of a future application.

Modeling tools

Although drawing models on paper is not forbidden, modern business process modeling is usually carried out using CASE tools - Computer Aided System Engineering - designing systems using a computer. On modern market software CASE-tools more than one hundred. In such a situation, it makes sense to discuss their classification and the tasks that can be solved with their help (in relation to the process approach).

From information technology, CASE-tools usually include tools that allow you to automate certain processes of the life cycle of IT solutions. However, with their help, tasks that are not directly related to IT solutions are often solved.

The features of modern CASE tools are visual graphical tools for creating models, the use of tools for storing them in the form of files or as data in a special repository, and often integration tools with other tools (for example, with application development tools, office applications, other CASE- means, tools used in the implementation of information systems). Often CASE tools contain reporting tools based on models, reengineering tools - generating models based on existing data (for example, contained in a relational database). Often, CASE tools include application programming interfaces and even development environments for solutions on their own.

CASE tools can be classified into types:

• analysis and modeling tools designed to create descriptions of processes and other subject areas as such;
• analysis and design tools used to manage requirements and document IT projects;
• application modeling tools (today the most common category of such tools is the family of UML modeling tools);
• data design tools that provide data modeling and database schema generation for the most common DBMS.

All of the listed categories of tools are used to describe business processes, except perhaps the last one: data modeling is a special area with very specific tasks and a specific expected result and is used not so much by business analysts as by application developers.

Rice. 1 Borland Together

The most popular business process description tools in our country include Rational Rose (IBM) and Together (Borland) UML modeling tools - fig. 1, the AllFusion Business Process Modeler (BPwin) family for describing business processes using the IDEF0 (Computer Associates) methodology and organizing collective work on a single repository of models (Fig. 2), ARIS (IDS Scheer) - a tool for collective work on a set of interrelated models different types (Fig. 3) designed to describe business processes, data and information systems, company activities, Visio (Microsoft) is a tool for creating various types of business process and data models that allows you to create diagrams and models using various methodologies (Fig. . 4).

Rice. 2. CA AllFusion Business Process Modeler (BPwin)

Rice. 3. ARIS Business Architect

Rice. 4.Microsoft Visio

We have repeatedly written about many of the tools listed above in our magazine, and those who are interested can find the relevant articles on our website: .

Which of the tools should be chosen for business process modeling? First of all, this is determined by the goals and volume of modeling, the functionality of the tools, their integration with other tools and applications, and to a much lesser extent, the knowledge and experience of using a particular tool among the authors of the models. Naturally, in this case, it is necessary to imagine what capabilities of the modeling tool are required to solve the problem facing the user. However, we will talk more about the possibilities of such tools in subsequent articles.