Description of the idef0 functional model. Principles of constructing the idef0 model. Principles for limiting the complexity of IDEF0 diagrams

The main one of the three methodologies supported by BPwin is IDEF0. IDEF0, belongs to the IDEF family, which appeared in the late sixties under the name SADT (Structured Analysis and Design Technique). IDEF0 can be used to model a wide range of systems. For new systems, the use of IDEF0 is aimed at defining requirements and specifying functions for the subsequent development of a system that meets the requirements and implements the selected functions. When applied to existing systems, IDEF0 can be used to analyze the functions performed by the system and map the mechanisms by which those functions are performed. The result of applying IDEF0 to a system is a model of that system consisting of a hierarchically ordered set of diagrams, documentation text, and vocabularies that are cross-referenced together. The two most important components that make up IDEF0 diagrams are the business functions or activities (represented in the diagrams as boxes) and the data and objects (represented as arrows) that connect the activities. In this case, the arrows, depending on which face of the work rectangle they enter or which face they exit from, are divided into five types:

Entry arrows (included in the left side of the work) - depict data or objects that change during the execution of the work.

Control arrows (included in the upper edge of the work) - depict the rules and restrictions according to which the work is performed.

Exit arrows (extending from the right side of the work) - depict data or objects that appear as a result of the work.

Mechanism arrows (included in the bottom edge of the work) - depict the resources necessary to complete the work, but do not change during the work (for example, equipment, human resources...)

Call arrows (coming from the bottom of the work) - depict connections between different diagrams or models, pointing to some diagram where this work discussed in more detail.

All jobs and arrows must be named. The first diagram in the IDEF0 diagram hierarchy always depicts the functioning of the system as a whole. Such diagrams are called context diagrams. The context includes a description of the purpose of the modeling, the scope (a description of what will be considered as a component of the system and what as an external influence) and the point of view (the position from which the model will be built). Typically, the point of view is the point of view of the person or object responsible for the operation of the modeled system as a whole.

Figure 7.1. Functional block and interface arcs

Activities on diagrams are depicted as rectangles (functional blocks). Each job depicts some function or task and is named by a verb or verb phrase indicating the action, for example, “Making a product,” “Customer service,” etc. Arrows are marked with a noun and indicate objects or information that connects the works with each other and with the outside world.

After describing the context, a functional decomposition is carried out - the system is divided into subsystems and each subsystem is described in the same syntax as the system as a whole. Then each subsystem is divided into smaller ones, and so on until the desired level of detail is achieved. As a result of this partition, each fragment of the system is depicted on a separate decomposition diagram.

Once the context has been described, the following diagrams in the hierarchy are constructed. Each subsequent diagram is more detailed description(decomposition) of one of the jobs in the above diagram. An example of contextual work decomposition is shown in Figure 7.2 and Figure 7.4. The description of each subsystem is carried out by an analyst together with a subject area expert. Typically the expert is the person in charge of that subsystem and therefore has a thorough knowledge of all its functions. Thus, the entire system is divided into subsystems to the required level of detail, and a model is obtained that approximates the system with a given level of accuracy. Having received a model that adequately reflects current business processes (the so-called AS IS model), the analyst can easily see all the most vulnerable points of the system. After this, taking into account the identified shortcomings, it is possible to build a model of a new organization of business processes (TO BE model).

One of the most important features of the SADT methodology is the gradual introduction of greater and greater levels of detail as diagrams representing the model are created.

Figure 7.2, which shows three diagrams and their relationships, shows the structure of the IDEF0.-model. Each component of the model can be decomposed into a different diagram. Each diagram illustrates the "internal structure" of a block in its parent diagram.

Figure 7.2 - Example of a context diagram

As can be seen in Fig. 7.2, BPwin allows you to highlight activities and arrows in different colors, as well as link the names of the arrows to the arrows themselves (an arrow named “Reporting”), which increases the clarity and readability of the diagram.

Figure 7.3 - Example of a decomposition diagram

Drawing7 . 4 - Context diagram example

Figure 7.5 - Decomposition diagram example

Diagram Hierarchy

The construction of the IDEF0 model begins with the representation of the entire system in the form of the simplest component - one block and arcs depicting interfaces with functions outside the system. Because a single block represents the entire system as a whole, the name specified in the block is generic. This is also true for interface arcs - they also represent the complete set of external interfaces of the system as a whole.

The block that represents the system as a single module is then detailed in another diagram using several blocks connected by interface arcs. These blocks represent the main subfunctions of the original function. This decomposition reveals a complete set of subfunctions, each of which is represented as a block, the boundaries of which are defined by interface arcs. Each of these subfunctions can be decomposed in a similar way to provide a more detailed representation.

In all cases, each subfunction can contain only those elements that are included in the original function. In addition, the model cannot omit any elements, i.e., as already noted, the parent block and its interfaces provide context. Nothing can be added to it, and nothing can be removed from it.

The arcs going in and out of a block in a top-level diagram are exactly the same as the arcs going in and out of a lower-level diagram, because the block and the diagram represent the same part of the system.

Figure 7.6 - Structure of the SADT model. Decomposition of diagrams

Figure 7.7 - Compliance must be complete and consistent

Some arcs are connected to the diagram blocks at both ends, while others have one end unattached. Unconnected arcs correspond to inputs, controls and outputs of the parent block. The source or destination of these boundary arcs can only be found in the parent diagram. The unattached ends must match the arcs on the original diagram. All boundary arcs must continue on the parent diagram for it to be complete and consistent.

As noted, the mechanisms (arcs on the bottom side) show the means by which functions are performed. The mechanism can be a person, a computer, or any other device that helps perform a given function (Figure 7.8).

Rice. 7.8. Mechanism example

Each block on the diagram has its own number. A block of any diagram can be further described by a lower-level diagram, which in turn can be further detailed with the required number of diagrams. Thus, a hierarchy of diagrams is formed.

Chart numbers are used to indicate the position of any chart or block in the hierarchy. For example, A21 is a diagram that details block 1 in diagram A2. Similarly, A2 details block 2 in diagram A0, which is the topmost diagram of the model. Figure 7.9 shows a typical diagram tree.

Figure 7.9 - Hierarchy of diagrams

Lecture 8. MethodologiesDFDAndIDEF3

Keywords: structural analysis and design, functional model, functional block, interface arc, context diagram, decomposition, glossary, goal, point of view, subprocess identification, decomposition, complexity limitation, tunneling.

Definition

IDEF0 (Integration Definition for Function Modeling) – a functional modeling methodology for describing enterprise functions, offering a functional modeling language for analysis, development, reengineering and integration of business process information systems; or software engineering analysis.

The IDEF0 methodology is a development of the structural analysis and design method SADT (Structured Analysis and Design Technique).

IDEF0 as a standard was developed in 1981 as part of the ICAM (Integrated Computer Aided Manufacturing) program.

IDEF0 – Integration DEFinition language 0 – is based on SADT and in its original form includes simultaneously: a definition of a graphical modeling language (syntax and semantics) and a description of a comprehensive model development methodology.

Latest edition IDEF0 was released in December 1993 by the US National Institute of Standards and Technology (NIST).

IDEF0 was adopted as a federal standard in the United States in 1993, and as a standard in the Russian Federation in 2000.

Application of IDEF0

IDEF0 is used to create functional model, that is, the result of applying the IDEF0 methodology to the system is the IDEF0 functional model.

Functional model is a structural representation of functions, activities or processes within the modeled system or subject area.

The IDEF0 methodology can be used to model a wide range of both automated and manual systems.

For systems being designed, IDEF0 can be used to first define requirements and functions and then create an implementation that satisfies those requirements and performs those functions.

For existing systems, IDEF0 can be used to analyze the functions performed by the system, as well as to account for the mechanisms by which those functions are performed.

Goals of the IDEF0 Standard

Main objectives (objectives) of the standard:

document and explain the IDEF0 modeling technique and how to use it;

provide a means for completely and consistently modeling the functions of a system or domain, as well as the data and objects that connect these functions;

provide a modeling language that is independent of CASE methods or tools, but can be used using those methods and tools;

provide a modeling language that has the following characteristics:

general(generic) – for analysis of systems and subject areas;

strict and precise(rigorous and precise) – to create correct, usable models);

brief(concise) – to facilitate understanding, communication, agreement between stakeholders and verification. (to facilitate understanding, communication, consensus and validation);

abstract(conceptual) – to represent functional requirements independent of physical or organizational implementations;

flexible– to support different phases life cycle project.

Rigor and precision(Rigor and Precision)

The IDEFØ rules require sufficient rigor and precision to satisfy the needs without overly constraining the analyst. IDEFØ rules include the following:

control of the details communicated at each level – from three to six functional blocks at each level of decomposition;

Bounded Context – there should be no missing or unnecessary details that go beyond the established framework;

Diagram Interface Connectivity – numbers of nodes, functional blocks, C-numbers and Detail Reference Expression);

data structure coherence. (Data Structure Connectivity) – ICOM codes and the use of parentheses;

Unique Labels and Titles – no duplicate names;

syntax rules for graphics (Syntax Rules for Graphics) – function blocks and arrows;

restrictions on data arrow branches (Data Arrow Branch Constraint) – labels for restrictions on data flows on branches;

separation of data into Input versus Control Separation – a rule for determining the role of data);

data arrow markings. Data Arrow Label Requirements (minimum labeling rules);

presence of Control (Minimum Control of Function) – all functions must have at least one Control;

Purpose and Viewpoint – all models have a statement of purpose and point of view.

IDEF0 Basic Concepts

The methodology is based on four main concepts:

functional block;

interface arc;

decomposition;

glossary.

Function block(Activity Box) represents some specific function within the system in question.

According to the requirements of the standard, the name of each functional block must be formulated in the verbal mood (for example, “produce services”).

In the diagram, a functional block is depicted as a rectangle (Fig.). Each of the four sides of the functional block has its own specific meaning (role), and:

the top side is set to “Control”;

the left side is set to “Input”;

the right side is set to “Output”;

the bottom side has the meaning “Mechanism”.

Rice. Function block

Interface arc/arrow(Arrow) displays a system element that is processed by a function block or otherwise affects the function represented by that function block. Interface arcs are often called flows or arrows.

Using interface arcs, various objects are displayed that, to one degree or another, determine the processes occurring in the system. Such objects can be elements of the real world (parts, cars, employees, etc.) or flows of data and information (documents, data, instructions, etc.).

Depending on which side of the functional block this interface arc fits, it is called “incoming”, “outgoing” or “controlling”.

It should be noted that any functional block, according to the requirements of the standard, must have at least one control interface arc and one outgoing one. This is understandable - each process must occur according to some rules (displayed by the control arc) and must produce some result (outgoing arc), otherwise its consideration does not make any sense.

The mandatory presence of control interface arcs is one of the main differences between the IDEF0 standard and other methodologies of the DFD (Data Flow Diagram) and WFD (Work Flow Diagram) classes.

Decomposition(Decomposition) is a core concept of the IDEF0 standard. The principle of decomposition is used when breaking a complex process into its component functions. In this case, the level of detail of the process is determined directly by the model developer.

Decomposition allows you to gradually and structuredly present the system model in the form of a hierarchical structure of individual diagrams, which makes it less overloaded and easier to digest.

The last of the IDEF0 concepts is glossary(Glossary).

For each of the IDEF0 elements - diagrams, function blocks, interface arcs - the existing standard requires the creation and maintenance of a set of corresponding definitions, keywords, narrative statements, etc. that characterize the object displayed by this element.

This set is called glossary and is a description of the essence of this element. The glossary harmoniously complements the visual graphic language, providing the diagrams with the necessary additional information.

Modeling. The IDEF0 model always begins with a view of the system as a single whole—one functional unit with interface arcs extending beyond the domain under consideration. Such a diagram with one functional block is called context diagram.

The explanatory text for the context diagram must indicate target(Purpose) to construct a diagram in the form of a brief description and recorded point of view(Viewpoint).

Definition and formalization goals development of the IDEF0 model is an extremely important point. In effect, the goal defines the relevant areas in the system under study that need to be focused on first.

Point of view determines the main direction of model development and the level of required detail. A clear fixation of the point of view allows you to unload the model by refusing to detail and study individual elements that are not necessary, based on the chosen point of view on the system.

6.2. Purpose and composition of the SADT methodology (IDEF0)

SADT methodology (Structured Analysis and Design Technique - methodology of structural analysis and design) is a set of methods, rules and procedures designed to build a functional model of a system.

The development of this methodology began with Douglas Ross (USA) in the mid-60s. XX century Since then, system analysts at SofTech, Inc. improved SADT and used it to solve a wide range of problems. Software telephone networks, diagnostics, long-term and strategic planning, computer-aided manufacturing and design, computer system configuration, personnel training, financial and logistics management are some of the areas where SADT can be effectively applied. The wide range of areas indicates the versatility and power of the SADT methodology. The US Department of Defense's Integrated Computer Aided Manufacturing (ICAM) program recognized the usefulness of SADT. This led to the publication of part of it in 1981, called IDEF0 (Icam DEFinition), as a federal development standard software. Under this name, SADT began to be used by thousands of specialists in military and industrial organizations. The latest edition of the IDEF0 standard was released in December 1993. National Institute of Standards and Technology (NIST).

This methodology when describing the functional aspect information system competes with data flow-oriented (DFD) methods. In contrast, IDEF0 allows:

Describe any systems, not just information systems (DFD is intended to describe software);

Create a description of the system and its external environment before determining the final requirements for it. In other words, using this methodology, you can gradually build and analyze a system even when it is still difficult to imagine its implementation.

Thus, IDEF0 can be used in the early stages of building a wide range of systems. At the same time, it can be used to analyze the functions of existing systems and develop solutions to improve them.

The basis of the IDEF0 methodology is a graphical language for describing processes. A model in IDEF0 notation is a collection of hierarchically ordered and interconnected diagrams. Each diagram is a unit of description of the system and is located on a separate sheet.

The model (AS-IS, TO-BE or SHOULD-BE) may contain 4 types of charts [ , ]:

Context diagram;

Decomposition diagrams;

Node tree diagrams;

Diagrams for exposure only (FEO).

Context diagram (top-level diagram), being the top of the tree structure of diagrams, shows the purpose of the system (main function) and its interaction with the external environment. Each model can have only one context diagram. After describing the main function, functional decomposition is performed, i.e., the functions that make up the main one are determined.

Next, the functions are divided into subfunctions and so on until the required level of detail of the system under study is achieved. Diagrams that describe each such fragment of the system are called decomposition diagrams . After each decomposition session, examination sessions are conducted - subject matter experts indicate the correspondence of real processes to the created diagrams. Found inconsistencies are eliminated, after which further detailing of the processes begins.

Node Tree Diagram shows the hierarchical dependence of functions (works), but not the connections between them. There can be several of them, since the tree can be built to an arbitrary depth and from an arbitrary node.

Exposure charts are constructed to illustrate individual fragments of the model in order to display an alternative point of view on the processes occurring in the system (for example, from the point of view of the organization’s management).

6.3. Elements of IDEF0 graphic notation

The IDEF0 methodology has found wide acceptance and application, primarily due to the simple graphical notation used to build the model. The main components of the model are diagrams. They display system functions in the form of rectangles, as well as connections between them and the external environment through arrows. Using just two graphic primitives (rectangle and arrow) you can quickly explain the rules and principles of IDEF0 diagramming to people unfamiliar with this methodology. This advantage allows you to connect and activate the customer’s activities in describing business processes using a formal and visual graphic language.

The following figure shows the main elements of the IDEF0 graphical notation.

Rice. 6.1. Elements of IDEF0 graphic notation

The rectangle represents work (process, activity, function or task) , which has a fixed goal and leads to some final result. The name of the work should express the action (for example, “Manufacture of a part”, “Calculation of permissible speeds”, “Creation of a statement of work center No. 3”).

The interaction of works between themselves and the outside world is described in the form of arrows. IDEF0 distinguishes 5 types of arrows :

- entrance (English input) - material or information that is used and transformed by work to obtain a result (output). The input answers the question “What is being processed?” The input can be either a material object (raw materials, part, exam card) or one that does not have clear physical contours (a database query, a teacher’s question). It is allowed that the work may not have a single entry arrow. Entry arrows are always drawn entering the left edge of the work;

- control (English control) – control, regulating and normative data that guides the work. Management answers the question “In accordance with what is the work being done?” Management influences work, but is not transformed by it, i.e. acts as a limitation. Management may include rules, standards, regulations, prices, or verbal instructions. Control arrows are drawn entering the top edge of the work. If, when constructing a diagram, the question arises about how to correctly draw an arrow from above or to the left, then it is recommended to draw it as an input (arrow on the left);

- exit (English output) – material or information that represents the result of the work. The output answers the question “What is the result of the work?” The output can be either a material object (part, car, payment documents, statement) or an intangible object (sampling data from a database, answering a question, verbal instructions). Exit arrows are drawn emanating from the right edge of the work;

- mechanism (English mechanism) – resources that do the work. The mechanism answers the question “Who does the work or through what?” The mechanism can be enterprise personnel, a student, a machine, equipment, or a program. The arrows of the mechanism are drawn entering the lower edge of the work;

- call (English call) - the arrow indicates that some part of the work is being performed outside the block in question. Exit arrows are drawn emanating from the bottom edge of the work.

6.4. Types of connections between jobs

After determining the composition of functions and the relationships between them, the question arises about their correct composition (combination) into modules (subsystems). This implies that each individual function must solve one, strictly defined task. Otherwise, further decomposition or separation of functions is necessary.

When combining functions into subsystems, it is necessary to strive to ensure that the internal connectivity (between functions within a module) is as strong as possible, and the external connectivity (between functions included in different modules) is as weak as possible. Based on the semantics of connections of the methodology, we will introduce a classification of connections between functions (works). This classification is an extension. Types of bonds are given in decreasing order of their significance (binding strength). In the examples given, thick lines highlight functions between which there is the type of connection under consideration.

1. Hierarchical connection (relationship “part” - “whole”) takes place between a function and the subfunctions of which it is composed.

Rice. 6.2. Hierarchical relationship

2. Regulatory (control, subordinate) connection reflects the dependence of one function on another, when the output of one work is directed to control another. The function from which management comes should be considered regulating or controlling, and the function into which it is included should be considered subordinate. Distinguish direct communication to management , when control is transferred from a higher job to a lower one (Fig. 6.3), and management feedback when control is transferred from lower to higher (Fig. 6.4).

3. Functional (technological) connection occurs when the output of one function serves as the input to the next function. From the point of view of the flow of material objects this connection shows the technology (sequence of work) for processing these objects. Distinguish direct input connection , when the output is transferred from a higher operation to a lower one (Fig. 6.5), and login feedback , when the output is transmitted from the lower one to the higher one (Fig. 6.6).


Rice. 6.5. Direct connection by input	Rice. 6.6. Login feedback

4. Consumer Communication occurs when the output of one function serves as a mechanism for the next function. Thus, one function consumes resources produced by another.

Rice. 6.7. Consumer Communication

5. Logical connection observed between logically homogeneous functions. Such functions, as a rule, perform the same job, but in different (alternative) ways or using different input data (materials).

Rice. 6.8. Logical connection

6. Collegial (methodological) communication occurs between functions whose operation algorithm is determined by the same control. An analogue of such a connection is collaboration employees of one department (colleagues) subordinate to a boss who gives instructions and orders (control signals). Such a connection also arises when the algorithms for the operation of these functions are determined by the same methodological support (SNIP, GOST, official regulatory materials, etc.), which serves as control.

Rice. 6.9. Methodical connection

7. Resource connection occurs between functions that use the same resources for their work. Resource-dependent functions generally cannot be executed simultaneously.

Rice. 6.10. Resource connection

8. Information communication occurs between functions that use the same information as input.

Rice. 6.11. Information communication

9. Temporary connection occurs between functions that must be executed simultaneously before or simultaneously after another function.

In addition to the cases indicated in the figure, this connection also occurs between other combinations of control, input and mechanism entering the same function.

Rice. 6.12. Temporary connection

10. Random connection occurs when there is little or no specific connection between functions.

Rice. 6.13. Random connection

Of the above types of connections, the strongest is the hierarchical connection, which, in essence, determines the combination of functions into modules (subsystems). Regulatory, functional and consumer ties are somewhat weaker. Functions with these relationships are usually implemented in a single subsystem. Logical, collegial, resource and information connections are among the weakest. Functions that have them, as a rule, are implemented in different subsystems, with the exception of logically homogeneous functions (functions connected by a logical connection). Temporal communication indicates a weak dependence of functions on each other and requires their implementation in separate modules.

Thus, when combining functions into modules, the first five types of connections are the most desirable. It is better to implement functions connected by the last five links in separate modules.

IDEF0 has conventions (rules and guidelines) for creating diagrams that are designed to make the model easier to read and examine [ , ]. Some of these rules are supported automatically by CASE tools, while others must be enforced manually.

1. Before building a model, it is necessary to decide which model(s) of the system will be built. This implies determining its type AS-IS, TO-BE or SHOULD-BE, as well as determining the position from the point of view of which the model is being built. A “point of view” is best thought of as the place (position) of a person or object in which one must stand in order to see a system in action. For example, when building a model of the operation of a grocery store, you can choose a salesperson, cashier, accountant or director among the possible candidates from the point of view of which the system is considered. Typically, one point of view is selected that most fully covers all the nuances of the system's operation, and, if necessary, for some decomposition diagrams, FEO diagrams are constructed that display an alternative point of view.

2. The context diagram displays one block showing the purpose of the system. It is recommended to display 2-4 arrows entering and exiting on each side.

3. The number of blocks on decomposition diagrams is recommended within 3–6. If a decomposition diagram has two blocks, then it usually does not make sense. If there are a large number of blocks, the diagram becomes oversaturated and difficult to read.

4. Blocks in a decomposition diagram should be arranged from left to right and from top to bottom. This arrangement allows you to more clearly reflect the logic and sequence of work. In addition, the arrow routes will be less confusing and have a minimum number of intersections.

5. The absence of both control and input arrows for a function is not allowed. This means that the launch of this function is not controlled and can occur at any arbitrary point in time or never at all.

Rice. 6.14. Function without control and input

A block with only control can be considered as a call in a program to a function (procedure) without parameters. If a block has an input, then it is equivalent to calling a function with parameters in the program. Thus, a block without control and input is equivalent to a function that is never called for execution in the program.

In Fig. 6.7–6.12, displaying fragments of IDEF0 diagrams, there are blocks without input and control. This should not be considered an error, since one of these arrows is intended to be there.

6. Each block must have at least one output.

Rice. 6.15. Function without output

Work without results has no meaning and should not be modeled. The exception is works displayed in the AS-IS model. Their presence indicates the inefficiency and imperfection of technological processes. In the TO-BE model, these activities should be absent.

7. When constructing diagrams, you should minimize the number of intersections, loops and turns of arrows.

8. Feedbacks and iterations (cyclic actions) can be depicted using back arcs. Input feedbacks are drawn as a “bottom” loop, Feedback for control – “top” (see Fig. 6.4 and 6.6).

9. Each block and each arrow on the diagrams must have a name. It is allowed to use branching (decomposition) or merging (composition) of arrows. This is due to the fact that the same data or objects generated by one job can be used in several other jobs at once. Conversely, the same or homogeneous data and objects generated by different jobs, can be used in one place.

Rice. 6.16. Branching arrows

In this case, it is possible to assign qualifying names to different branches of the arrow after branching (before merging). If any branch is not named after the branch, then its name is considered to correspond to the name of the arrow written before the branch.

So, in Fig. 6.16 controls included in the blocks “Manufacturing of parts” and “Assembling a product” have clarifying meanings and are integral part more general management"Blueprints". All drawings are used to operate the Quality Control block.

It is not allowed to draw arrows on the diagram when they are not named before and after the branch. In Fig. 6.17 the arrow included in the “Generation of standard statements” block does not have a name before and after the branch, which is an error.

Rice. 6.17. Incorrect naming of arrows

10. When constructing diagrams, the arrow tunneling mechanism can be used for better readability. For example, in order not to clutter the upper-level (parent) diagrams with unnecessary details, in decomposition diagrams the beginning of the arc is placed in a tunnel.

Rice. 6.18. Arrow tunneling

IN in this example when building a model for holding a New Year's party, the “two axes” mechanism will not be displayed on the diagrams of the upper levels, when reading which a fair question may arise: “Why are two axes needed at a New Year’s party?”

Similarly, you can tunnel with the opposite goal of preventing the arrow from appearing on lower-level diagrams. In this case, parentheses are placed at the end of the arrow. In the context diagram (see Fig. 6.21), the “Track Service Engineer” mechanism, included in the “Determination of Allowable Speeds” block, is tunneled. This decision was made since the engineer is directly involved in all the work displayed on the decomposition diagram of this block (see Fig. 6.22). In order not to show this connection and not to clutter the decomposition diagram, the arrow was tunneled.

11. All arrows entering and leaving the block, when constructing a decomposition diagram for it, must be displayed on it. The exception is tunneled arrows. The names of the arrows transferred to the decomposition diagram must match the names indicated on the top-level diagram.

12. If two arrows run parallel (starting from the same face of one work and ending on the same face of another work), then, if possible, they should be combined and called a single term.

Rice. 6.19. Merging connections

13. Each block on the diagrams must have its own number. Chart numbers are used to indicate the position of any chart or block in the hierarchy. A block on a top-level diagram is designated by 0, blocks on second-level diagrams by numbers from 1 to 9 (1, 2, ..., 9), blocks on the third level by two numbers, the first of which indicates the number of the detailed block from the parent diagram, and the second block number in order on the current diagram (11, 12, 25, 63), etc. The context diagram has the designation “A - 0”, the decomposition diagram of the first level is “A0”, the decomposition diagrams of the next levels are marked with the letter “ A" followed by the number of the block being decomposed (for example, "A11", "A12", "A25", "A63"). The figure shows a typical tree diagram (node tree diagram) with numbering.

Rice. 6.20. Diagram Hierarchy

In modern CASE tools, work numbering mechanisms are supported automatically. CASE tools also provide automatic construction of node tree diagrams that contain only hierarchical relationships. The vertex of such a diagram can be any node (block), and it can be built to any depth.

6.6. An example of building an IDEF0 model for a system for determining permissible speeds

Calculating permissible train speeds is a labor-intensive engineering task. When a train passes any section, the actual speed of the train must not exceed the maximum permissible speed. This maximum permissible speed is set based on operating experience and specially conducted tests on motion dynamics and the impact on the rolling stock track. Not exceeding this speed guarantees the safety of train traffic, comfortable riding conditions for passengers, etc. They are determined depending on the type of rolling stock (brand of locomotive and type of cars), parameters of the upper structure of the track (type of rails, ballast, sleeper diagram) and plan (radius curves, transition curves, outer rail elevations, etc.). As a rule, to establish permissible speeds, it is necessary to determine at least two (on straight lines) and five (in curves) speeds, from which the final permissible speed is selected as the lowest of all calculated ones. The calculation of these speeds is regulated by Order of the Ministry of Railways of Russia No. 41 of November 12, 2001 “Norms for permissible speeds of rolling stock on 1520 (1524) mm gauge railways of the Federal Railway Transport.”

As noted, the construction of the IDEF0 model begins with the representation of the entire system in the form of a simple component (context diagram). This diagram displays the purpose (main function) of the system and the necessary input and output data, control and regulatory information, as well as mechanisms.

The context diagram for the problem of determining permissible speeds is shown in Fig. 6.21. To build the model, the BPwin 4.0 product from Computer Associates was used.

Rice. 6.21. Context diagram of the system for determining permissible speeds (IDEF0 methodology)

As background information, on the basis of which the permissible speeds are determined, the following are used:

New line or reconstruction project data (contains all necessary information for the implementation of the project, namely mileage, axes of separate points, line plan, etc.);

Detailed longitudinal profile (contains information similar to that discussed above);

Passport of the track distance (contains information similar to that discussed above, as well as information about the superstructure of the track (VSP));

Data on the results of surveying the track plan using a track measuring car;

List of outer rail elevations in curves (contains information about the track plan).

Some of the background information can be taken from different sources. In particular, information about the plan (curve parameters) can be taken from the design of a new line or reconstruction project, a detailed longitudinal profile, a track distance certificate, etc.

Control data are:

Instruction from the head of the road track service or the Department of Track and Structures of JSC Russian Railways for the calculation;

Order No. 41, containing regulatory and reference information, procedures and formulas for determining permissible speeds;

Information on current or planned train traffic (data on the brands of locomotives in circulation and the types of cars used);

Information about planned track repairs, reconstruction and reconstruction of structures and devices.

The result system operation should be:

Lists of permissible speeds, containing all types of calculated speeds and allowing to establish the reason for their limitation;

Sheets of the Order of the head of the road on the establishment of permissible speeds on stretches and separate points (Order “N”) in accordance with the form accepted on the road. The approved Order “N” officially establishes the permissible train speeds;

Standard forms No. 1, 1a and 2, containing planned permissible speeds for developing train schedules.

The speeds contained in Order “N” and standard forms may differ from those calculated and shown in the permissible speed sheets. This is due to the fact that they reflect speed limits not only on the design of the rolling stock, VSP parameters and curves, but also on the state of devices and structures (deformation of the roadbed, misalignment of overhead contact network supports, etc.). In addition, they are adjusted taking into account planned track repairs, reconstruction and reconstruction of structures and devices, etc.

Once constructed, the context diagram is detailed using a first-level decomposition diagram. This diagram displays the system functions that must be implemented within the core function. The diagram for which the decomposition has been performed, in relation to the diagrams detailing it, is called parental . A decomposition diagram with respect to its parent is called subsidiary .

The first level decomposition diagram for the problem under consideration is shown in Fig. 6.22. As a rule, when constructing a decomposition diagram, the original function (decomposed) is divided into 3–8 subfunctions (blocks). In this case, it is recommended to arrange the blocks on the decomposition diagram from left to right, top to bottom, so that the sequence and logic of interaction of subfunctions is better visible.

Rice. 6.22. First level decomposition diagram (IDEF0 methodology)

The order of execution of functions to solve the problem under consideration is as follows:

Input and adjustment of regulatory and reference information and data on road sections (blocks 1 and 2);

Preparing a calculation task (block 3). It indicates for which section and track, as well as the brand of locomotive and type of cars, the calculation should be performed;

Calculation of permissible speeds in accordance with the procedure and formulas specified in Order No. 41 (block 4). The initial information is data on the route of the section (plan, superstructure of the track, etc.) and standards selected on the basis of the calculation task;

Formation of lists of permissible speeds (block 5). Based on the calculation results, several types of output documents are created, which, on the one hand, make it possible to identify the cause of speed restrictions, on the other hand, act as the basis for the preparation of regulated documents;

Formation and preparation of the draft Order “N” and standard statements (blocks 6 and 7).

After constructing the first-level decomposition diagram, separate diagrams are constructed for the functions indicated on it (second-level decomposition diagrams). Then the process of decomposition (diagramming) continues until further detailing of the functions becomes meaningless. For each atomic function that describes an elementary operation (that is, a function that does not have a decomposition diagram), a detailed specification is compiled that defines its features and implementation algorithm. Algorithm flowcharts may be used as a supplement to the specification. Thus, the process of functional modeling consists of gradually building a hierarchy of functions.

6.7. ICOM codes

The arrows going in and out of a box in a top-level diagram are the same as the arrows going in and out of a lower-level diagram, because the box and the diagram represent the same part of the system (see Figure 1). And ). As a consequence, the boundaries of a top-level function are the same as the boundaries of a decomposition diagram.

ICOM codes (an acronym for Input, Control, Output and Mechanism) are intended to identify boundary arrows. The ICOM code contains a prefix corresponding to the type of arrow (I, C, O or M) and a serial number (see figure).

The abbreviation IDEF0, known today not only in narrow circles, is the first methodology that standardizes work on business processes. It was developed in the middle of the last century as part of an aerospace project in the USA and, having shown its effectiveness, became a federal standard. In our country, in 2000, a document was prepared “ Functional modeling methodology IDEF0. Guidance document Functional Modeling Methodology IDEF0 Guidance Document. Official publication. State Standard of Russia RD IDEF0 – 2000. Developed by the Research Center CALS – Applied Logistics Technologies. Adopted and put into effect by the Decree of the State Standard of Russia in 2000, Moscow", but it was never approved as a standard. Although this did not prevent this methodology from becoming one of the most popular tools for graphical modeling of business processes in our country. In this article, I invite you to consider the IDEF0 model and evaluate the relevance of this approach at the present time.

Basic concepts and abbreviations

Let's look a little at the names of the key elements of the methodology. The IDEF0 graphic standard is part of the SADT (Structured Analysis and Design Technique) methodology. IDEF is an abbreviation for ICAM Definition, and ICAM is derived from Integrated Computer Aided Manufacturing, which translates as integrated computerization of production. The SADT methodology is a whole family of 15 different models, which together should have made it possible to study the structure, parameters and characteristics of production, technical and organizational-economic systems.

IDEF0 is a functional model, which is the core of the construction of all other structures; it links together information and material flows, organizational structure, control influences and the very activities of the company. The graphical standard for modeling processes is also called notation. That is, notation is a system of requirements and rules for constructing an activity model in one form or another. Therefore, IDEF0 is appropriately called a notation that is part of the SADT methodology.

The IDEF0 notation is a fairly strict methodology that was originally developed, like technical design standards, for manual modeling. Therefore, it contains requirements for the placement of arrows, the format of all elements, the content of the information frame for the IDEF0 diagram, etc. Since the company’s activities are a complex multi-level system of actions, there are always many diagrams, and unambiguous systematization and navigation through all elements of the model is necessary. Nowadays this is mostly done computer systems, supporting modeling in this notation. In Russia, the most famous and accessible systems today are AllFusion Process Modeler and Business Studio. I plan to devote separate articles to a review of these systems.

Function block

The central element of the IDEF0 model is the function, which is shown in the diagram as function block– a rectangle inside which an action is indicated in the form of a verbal noun. The action can be very different in scale - from the activities of the company in general and to specific manipulation in particular. Examples: “Production and sale of ceramic tableware” and “Applying a design to a product.”

Required Function Block Elements in IDEF0

Regardless of the scale of actions, all functions are displayed uniformly and necessarily contain 4 key flows, which are rigidly assigned to the sides of the function block:

on the left are the inputs or resources used to perform the function;
on the right are the outputs or results of executing the function;
on top are control actions that determine how and how many results need to be produced;
below are the mechanisms that reflect who should do this work and with what help.

This approach allows you to save a little on explanations in the diagrams and achieve unambiguity in the display of flows, which makes the entire model harmonious.

To build a functional model, the IDEF0 methodology requires the following rules to be observed.

Inputs are resources that transfer their value to outputs completely, that is, they are completely spent on creating the result, and mechanisms are resources that transfer their value only partially (equipment through depreciation, and people through wages).
Management is a necessary element of the model, since it ties all actions to the company’s system of regulations, clearly indicating what rules and requirements must be observed in the process of performing the function. Often this flow is treated formally, but in this case the scheme loses rigor and sometimes even meaning.
Each function block must have at least one arrow on each side (since there can be no work without resources or results, and instructions are incomplete without a performer or instructions).

The considered scheme is the “building block” of the IDEF0 approach. Functional modeling involves a gradual transition from the general to the specific through decomposition. Decomposition is “deepening” into the function under consideration, dividing it into smaller functions. Moreover, when a top-level function is presented in a generalized manner and then decomposed, it is appropriate to call it a process.

Context diagram

At the highest level, the company is represented as a “black box” in which certain activities occur that translate inputs into outputs. This level is usually called “,” that is, a diagram that describes the context of the company’s activities. Additionally, the context diagram displays key characteristics of the entire model.

The goal is a specific formulation of the purpose of the model, against which the accuracy of the model can be verified in the future.
Point of view - on whose behalf the model is built, since the model is always dependent on its author and focus of attention. If we build a general model of an enterprise, then it is usually presented from the point of view of its director.
Model type is an indication of what information is displayed on the diagrams. There can be 2 fundamental options: AS IS (“as is”) or TO BE (“as will be”). This division is necessary, since we can build models both for analyzing activities and for transforming them. We must be clear about what we are doing, and also convey this information to others.

Thus, the context diagram contains in the most general form a description of the company’s activities, which are permeated by flows connecting the company with the outside world. I think we should also look at them in a little more detail.

Main threads

Experience has shown that, despite the apparent simplicity and formality of this level, one often has to linger on it for a long time, since all results that are significant for the owner and the market must be reflected here. An error can lead to the creation of models that do not fulfill the business objectives. To check that meaningful flows are reflected, make sure that all 4 main types of flows are present in your diagram.

Material: materials and components at the input and finished products at the output.
Client: potential client at the entrance and satisfied at the exit.
Financial: the input is usually investments, customer payments (revenue), loans and other income; The output is payments to suppliers, taxes, loan payments and profits.
Informational: the input is all flows of information about the external environment (market conditions, behavior of competitors, technological innovations, etc.), and the output is the flow of information that the company communicates about itself to the world (all advertising information, as well as all types of reporting before regulatory authorities).

Please note that the company is open system, and nothing arises or disappears in it. The company is only able to transform incoming flows into outgoing ones, and if it does this well, then additional cash flow (profit) appears, which in some sense reflects the quality of the entire system.

(click to enlarge)

It's a good idea to highlight each of these types of flows with a different color so that you can easily distinguish the movement of resources and not miss important points. For example, you can often observe the absence of a client in the company’s flows, so work with him is based on the residual principle - the client often feels like a hindrance to company employees whose tasks are focused on processing the flow of documents.

Control arrows can be represented by only 1 type of flow - information, which can be divided into 2 subtypes. The first is documents such as:

laws and regulations;
orders, instructions;
instructions and regulations;
plans;
design documentation, etc.

The second is undocumented information, which most often refers to the requirements of the owners.

And finally, mechanisms - there are only 2 types of flows: equipment (material) and performers (divisions and people). There can be no documents here, just as there can be no people on the control switches!

For navigation, the model provides continuous numbering. The context diagram is numbered "A-0". Subsequently, each functional block receives its own number, no matter how deep the decomposition is.

Decomposition

After working through the flows of the context diagram, we can move on to decomposition. Moving to a lower level, as if opening a “black box,” we first see Blank sheet with arrows that were attached to the function block.

(click to enlarge)

And this is where functional modeling itself begins - we must understand what set of actions can connect these flows and ensure that all requirements are met. The difficulty is that there are a lot of actions in the company, and on the diagram we have the right to display no more than 9 functions, otherwise the diagram will become unreadable and therefore useless.

It is not always easy to arrange complex activities so that they remain visual, readable, and at the same time complete. Most often, they resort to dividing the entire variety of processes into major large blocks, the most significant of which are the following.

Creation of a product (result).
Promotion and sales – working with client flow.
Ensuring product creation activities are secondary processes that are necessary to comply with government requirements or ease of work (personnel and accounting, transport services, cleaning, etc.).
Creating control flows is the activity of developing management decisions that will determine the requirements for all company processes.

The figure below shows the decomposition diagram of our example.

(click to enlarge)

On the diagram, processes should be located diagonally - this is called the principle of dominance, which implies the arrangement of functional blocks from left to right and from top to bottom - in order of importance or in chronological order. The numbering of blocks occurs in the same way.

Further work on the model is similar to the first step - decomposition of each functional block of the first level is carried out. The block numbering will contain the number of the first level: A1.1 ... A1.n, A2.1 ... A2.n, etc.

Conclusions about the relevance of the notation

Within the framework of this article, we were able to display only the basic concepts of the IDEF0 notation using a short example of IDEF0, from which, of course, it is difficult to judge the methodology as a whole. But quite a lot of experience using this notation in practice allows me to draw the following conclusions.

The model has good visualization potential, but, in my opinion, its greater importance lies in its disciplinary effect. The rules and restrictions embedded in the methodology force us to develop a systematic and strict attitude towards models, which has a very good effect on the quality of the final result.
The model allows you to build communication flows between seemingly not very connected things: to connect the front and back office subsystems with management, which is much worse achieved by other notations.
The approach is simple and understandable for most project participants. Building and reading diagrams in this notation is limited only by the desire to delve into the intricacy of business flows.

Some of the above arguments make us think that this approach is the best and only one for complete activity modeling. But we must not forget that the functional model is designed only for the upper level of modeling. Using the IDEF0 notation to design work at the executor level leads to the fact that the diagrams are purely illustrative and it is impossible to build meaningful regulations on their basis, since they do not contain:

specifying the events of starting and stopping the process;
conditions for transition from one action to another;
the ability to visually display all resources and performers without overloading the diagram with arrows.

Therefore, if you use this notation for the tasks for which it is intended (structuring top-level activities), then IDEF0 is practically the only notation today that allows you to do this meaningfully and accurately.

In project management, this modeling standard is most applicable where it is necessary to connect different projects or processes with visual flows. Graphic model at the same time, it will allow for a more rational distribution of responsibility and resources among tasks. The logic for completing project tasks, reflected in the diagrams, will help prepare a better schedule in the form of a Gantt chart.

A picture is worth a thousand words

Folk wisdom

Often in my work there is a need not only to study and solve a certain problem, but to identify its location in the overall operating model of the company. It is not enough to understand that a certain unit is not working correctly, it is important to understand how it interacts with others. Otherwise, it is impossible to identify all existing problems and choose the optimal method for solving the problem. And for this you need to study the work of the company and draw up its functional model.

Of course, in theory, the manager should have a functional model of the company’s work, and it doesn’t matter whether we are talking about organizing the work of a warehouse or an IT system from lead to application. But in reality it almost never turns out to be, and therefore, in the process of studying and searching for a solution to the client’s problem, I also create a functional model of the company’s work or a certain process (function) on my own.

A few words about the advantages of graphics

As you know, IDEF0 functional models are always graphical diagrams. They have their own characteristics and rules of composition. We'll talk about this a little later. Now I would like to give a couple of examples of the effectiveness of graphics. Why am I focusing on this? Most likely, after my statement about the need for a functional model of the company’s work, many people thought that all this was not necessary, they could explain in words how this or that function works in the company. This is what I want to talk about.

Let's start with a short excursion into history. Let's go back to the distant year 1877, during the Russian-Turkish War. It was then that the printer Sytin first used graphics to describe military operations. Now all this is familiar to us; when describing any battle, cards with arrows appear before our eyes, which clearly show the course of the battle. And in those days, military actions were described in words. For each battle there are many, many words. And in the end it was very difficult to understand what was happening.

Therefore, Sytin’s idea was truly revolutionary - he began printing lithographic copies of maps indicating fortifications and locations of military units. These cards were called “For Newspaper Readers. Allowance.” The idea turned out to be so relevant that the first edition of the “Benefits” sold out instantly. And then such applications were in great demand. The reason is obvious. Graphics helped to understand what was almost impossible to understand with words alone.

I can also give a similar example of the helplessness of verbal descriptions from my own practice. One of my customers really asked me to take on the implementation of an ERP system for his company. When I asked if they had any technical specifications, I received the answer: “Yes, they do. But it’s 400 pages.” At the same time, the client complained greatly that my colleagues, whom he had contacted earlier, either refused the project altogether or quoted clearly inflated prices. After I saw that in terms of reference really 400 pages, and it consists solely of a text description, I understood the reasons for the developers’ behavior. Reading such a volume of text, delving into it, understanding all the nuances just to understand the task and name the price is really very difficult.

I offered this client Alternative option- describe everything that is possible graphically in the form of notations. Showed him examples of modeling. As a result, they are now rethinking their wishes and the design of the technical specifications.

I also know many other examples where graphical modeling of business processes helped both my colleagues, business consultants and developers, and businessmen themselves.

Why is this important to my work?

My work always involves making changes to existing system. And in order to make changes and get the desired result, you need to study what already exists. And it doesn’t matter what exactly we do - set up or install a CRM system from scratch, create an effective ERP system, do integration various systems to increase automation of work in general. In any case, first, you need to get an idea of the existing work scheme, and only after that you can propose some changes and think through options for solving the problem.

After studying the current state of affairs, I, like any other third-party specialist, create a commercial proposal in which I reveal in as much detail as possible my vision of the current situation, as well as the actions that need to be performed to solve the problem, and, of course, the expected result.

Such work survey reports are voluminous and take up more than one page, which, on the one hand, is necessary, but on the other, complicates perception. At first, like many others, I thought that voluminous reports were good, because a person pays for the work and you need to provide him with as much detailed information as possible.

Common mistakes

Functional modeling is performed using a variety of tools, including those not intended for modeling. In the latter case, there is no error checking and no standard restrictions. The desire to increase visibility and lack of experience often result in mistakes.

Using different colors

All elements in the diagram are equally important. In functional modeling, there are no more or less important elements. The disappearance of any will lead to disruption of the process and manufacturing defects.

Often when modeling on paper or in various programs, users try to increase visibility by using different colors. This is one of the most common mistakes. In fact, the use of multi-colored arrows and blocks only adds additional confusion and also distorts the perception of the diagram.

Your model should be readable in black and white, without any additional color schemes. This approach simultaneously helps to avoid misunderstandings and disciplines the model creator, resulting in increased readability and literacy of the model.

Too many blocks

When drawing up a model, they often try to display on one sheet all the nuances of the company’s work with all the details. The result is a very large number of blocks with big amount control arrows. In this case, readability is lost.

The best option is enough detail to understand the issue, and nothing more. Detailed details of the work of each department or even employee can be revealed when choosing a detailed view of a particular process. And such a structure is created only if it is really necessary for work or decision-making.

Violation of the structure when making adjustments

Be careful to ensure that there is no confusion or processes without inbound, outbound, or other important elements. For example, if in the example above, I find it necessary to shift the point of view to the copywriter, I will remove the author from the scheme. And then the control elements “author’s experience and third-party sources”, as well as the publication plan, become unnecessary. After all, the author uses them. A copywriter works with an audio file. And if they stay in general scheme, then when detailing it will lead to an unclear direction and cause confusion.

Likewise, if I decide to add a block, it's important to make sure it also has all the required attributes. Care is very important here, since when modeling complex business processes, changes in one part of the model may lead to changes in another. They definitely need to be included.

Rules for naming control elements and blocks

It is important to remember a simple rule: control arrows are called nouns, blocks are called verbs. This is accepted in the IDEF0 standard, and this approach helps to avoid confusion and errors.

Most often, mistakes are made when naming blocks. For example, instead of “Create an article,” they write “Creating an article.” Blocks in this approach are actions, and therefore they should always be verbs.

Benefits of using IDEF0

The very first benefit is obvious – visibility. You yourself begin to understand how this or that system works, and you can also clearly explain where the “thin spots” are in this system and how your solutions will help get rid of them.
Mutual understanding and absence of discrepancies. When discussing the work of a company using a functional model, you have visual and intuitive blocks of tasks with control elements. In addition, functional modeling involves creating, if necessary, a glossary that reveals symbols and terms. As a result, you and the client, manager, and other employees speak the same language when discussing a problem.
Simplicity and high speed creating a model. Of course, learning to model is not as easy as it seems. After all, a diagram is, in essence, a super-dense presentation of information, which is very good for understanding, but implementing such a presentation requires a special approach. The analyst’s brain acts in this case as a very powerful press on the one hand, and a filter on the other. But with experience this process becomes very fast. As a result, you get a tool that will help you figure out what is happening in a particular system and, using a visual aid created in a short time, illustrate important points to colleagues or customers.
Discipline and no mistakes. The IDEF0 standard provides strict frameworks and rules. This approach creates discipline, and the habit of acting within the standard helps to avoid mistakes due to inattention. Any violations of the standard become immediately noticeable.

What is the difficulty of using IDEF0

It is important to understand that only in the simplest cases will two business analysts create exactly the same functional models to describe the company’s work. Any model is a reflection of the analyst's experience, depth of understanding of the business he seeks to describe, and also, in some way, his personal point of view on this business. Those. a person develops a business model from the point of view of a manager, as if he were the manager.

At the same time, I believe that a business analyst is not exactly a profession; every business manager or developer of some systems who analyzes the business and strives to build the most effective system is engaged in business analytics. It is for these people and for these purposes that the IDEF0 tool is designed.

Therefore, when drawing up a functional “as is” business model, it is very important to constantly consult with the head of the company so as not to make mistakes that will automatically entail errors at the decomposition stages. Also, at subsequent stages, additional approvals with managers may be required. structural divisions and employees. Only if your “as is” functional model truly reflects the real state of things can you make any changes and suggestions. And to achieve high-quality results in such work, first of all, practical experience and knowledge of the characteristics of a particular type of business are required.