Idef0 software development. Use of different colors. The principle of building the IDEFO model

Learn to see and understand the functional structure of your business!

At present, in Russia, interest in generally accepted management standards in the West has sharply increased, however, in real management practice, there is one very indicative moment. Many executives can still be baffled by a direct question about the organizational structure of the company or the design of existing business processes. The most advanced managers who regularly read economic periodicals, as a rule, begin to draw hierarchical diagrams that only them understand, but even in this process they usually quickly come to a dead end. The same applies to employees and managers of various services and functional units. In most cases, the only set of outlined rules, in accordance with which the enterprise must operate, is a set of individual regulations and job descriptions. Most often, these documents were drawn up more than one year ago, are poorly structured and not interconnected and, as a result, simply gather dust on the shelves. For the time being, such an approach was justified, since during the formation of the Russian market economy, the concept of competition was practically absent, and there was no particular need to consider costs - the profit was gigantic. As a result, over the past two years, we have seen a completely understandable picture: large companies that grew in the early 90s are gradually losing their positions, right up to their complete withdrawal from the market. This is partly due to the fact that the enterprise did not implement management standards, the concept of a functional model of activity and mission was completely absent. With the help of modeling various areas of activity, it is possible to efficiently analyze the “bottlenecks” in management and optimize the overall business scheme. But, as you know, at any enterprise, only those projects that directly bring profit are of the highest priority, therefore, it is usually only during a tangible crisis in the management of the company that we are talking about the survey of activities and its reorganization.

At the end of the 90s, when the market was sufficiently competitive and the profitability of enterprises began to fall sharply, managers felt enormous difficulties in trying to optimize costs so that products remained both profitable and competitive. Just at this moment, the need to have before your eyes a model of the enterprise's activity, which would reflect all the mechanisms and principles of the interconnection of various subsystems within the framework of one business, was clearly manifested.

The very concept of "business process modeling" came into the everyday life of most analysts simultaneously with the appearance on the market of complex software products designed for complex automation of enterprise management. Such systems always imply a deep pre-project survey of the company's activities. The result of this survey is an expert opinion, in which individual points are made recommendations to eliminate bottlenecks in the management of activities. Based on this conclusion, immediately before the project of introducing an automation system, the so-called reorganization of business processes is carried out, sometimes quite serious and painful for the company. This, and naturally, a team that has developed over the years is always difficult to force to “think in a new way”. Such complex surveys of enterprises are always complex and significantly different tasks from case to case. There are well-tried methodologies and standards for solving such problems of modeling complex systems. These standards include the methodologies of the IDEF family. With their help, it is possible to effectively display and analyze the models of the activity of a wide range of complex systems in various sections. At the same time, the breadth and depth of examination of the processes in the system is determined by the developer himself, which allows not to overload the created model with unnecessary data. At the moment, the following standards can be attributed to the IDEF family:

IDEF0 is a functional modeling methodology. With the help of the visual graphic language IDEF0, the system under study appears to developers and analysts in the form of a set of interrelated functions (functional blocks - in terms of IDEF0). Typically, IDEF0 modeling is the first step in learning about any system;

IDEF1 is a methodology for modeling information flows within the system, which allows you to display and analyze their structure and relationships;

IDEF1X (IDEF1 Extended) - methodology for building relational structures. IDEF1X refers to the type of methodology "Entity-relationship" (ER - Entity-Relationship) and, as a rule, is used to model relational databases related to the system in question;

IDEF2 is a methodology for dynamic modeling of systems evolution. Due to the very serious difficulties of analyzing dynamical systems, this standard was practically abandoned, and its development was suspended at the very initial stage. However, at present there are algorithms and their computer implementations that make it possible to transform a set of static IDEF0 diagrams into dynamic models based on “colored Petri nets” (CPN - Color Petri Nets);

IDEF3 is a methodology for documenting the processes occurring in the system, which is used, for example, in the study of technological processes in enterprises. IDEF3 describes the scenario and workflow for each process. IDEF3 has a direct relationship with the IDEF0 methodology - each function (functional block) can be represented as a separate process by means of IDEF3;

IDEF4 is a methodology for building object-oriented systems. IDEF4 tools allow you to visually display the structure of objects and the underlying principles of their interaction, thereby allowing you to analyze and optimize complex object-oriented systems;

IDEF5 is a methodology for the ontological study of complex systems. Using the IDEF5 methodology, the ontology of a system can be described using a specific vocabulary of terms and rules, on the basis of which reliable statements about the state of the system under consideration at a certain point in time can be formed. On the basis of these statements, conclusions about the further development of the system are formed and its optimization is carried out.
In this article, we will look at the most commonly used functional modeling methodology IDEF0.

The history of the IDEF0 standard

The IDEF0 methodology can be considered the next stage in the development of the well-known graphical language for describing functional systems SADT (Structured Analysis and Design Teqnique). Several years ago, a small edition of the book of the same name was published in Russia, which was devoted to the description of the basic principles of constructing SADT diagrams. Historically, IDEF0 as a standard was developed in 1981 as part of an extensive industrial automation program called ICAM (Integrated Computer Aided Manufacturing) and was proposed by the US Air Force. The IDEF family of standards itself inherited its designation from the name of this program (IDEF \u003d ICAM DEFinition). In the process of practical implementation, the participants of the ICAM program faced the need to develop new methods for analyzing interaction processes in industrial systems. At the same time, in addition to an improved set of functions for describing business processes, one of the requirements for the new standard was the availability of an effective methodology for interaction within the “analyst-specialist” framework. In other words, the new method was supposed to provide group work on the creation of the model, with the direct participation of all analysts and specialists involved in the project.

As a result of the search for appropriate solutions, the IDEF0 functional modeling methodology was born. Since 1981, the IDEF0 standard has undergone several minor changes, mostly of a limiting nature, and its last revision was released in December 1993 by the US National Institute for Standards and Technology (NIST).

Basic elements and concepts of IDEF0

The graphic language IDEF0 is surprisingly simple and harmonious. The methodology is based on four main concepts.

The first of these is the concept of the Activity Box. A functional block is graphically depicted in the form of a rectangle (see Fig. 1) and personifies some specific function within the framework of the system under consideration. According to the requirements of the standard, the name of each functional block should be formulated in the verb mood (for example, “produce services”, not “production of services”).

Each of the four sides of a functional block has its own specific meaning (role), while:

The top side is Control;

The left side is set to “Input”;

The right side is set to “Output”;

The downside is “Mechanism”.

Each functional block within a single considered system must have its own unique identification number.

Figure 1. Functional block.

The second “whale” of the IDEF0 methodology is the concept of an interface arc (Arrow). Also, interface arcs are often called streams or arrows. The interface arc displays a system element that is processed by a function block or otherwise affects the function displayed by this function block.

The graphical display of the interface arc is a unidirectional arrow. Each interface arc must have its own unique name (Arrow Label). As required by the standard, the name must be a noun turnover.

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

Depending on which side the given interface arc is suitable for, it is called “incoming”, “outgoing” or “controlling”. In addition, only functional blocks can be the “source” (beginning) and “sink” (end) of each functional arc, while the “source” can only be the output side of the block, and the “sink” can be any of the three remaining ones.

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 follow some rules (displayed by the control arc) and must produce some result (outgoing arc), otherwise it makes no sense to consider it.

When building IDEF0 - diagrams, it is important to correctly separate the incoming interface arcs from the control ones, which is often not easy. For example, figure 2 shows the function block "Process workpiece".

In a real process, the worker performing the processing is given a workpiece and technological instructions for processing (or safety rules when working with the machine). It may mistakenly seem that both the workpiece and the document with technological instructions are incoming objects, but this is not so. In fact, in this process, the workpiece is processed according to the rules reflected in the technological instructions, which should be respectively displayed by the control interface arc.

Figure 2.

Another thing is when technological instructions are processed by the chief technologist and changes are made to them (Fig. 3). In this case, they are displayed as an already incoming interface arc, and the control object is, for example, new industrial standards, based on which these changes are made.

Figure 3.

The examples above emphasize the seemingly similar nature of incoming and outgoing interface arcs, but there are always certain distinctions for systems of the same class. For example, in the case of considering enterprises and organizations, there are five main types of objects: material flows (parts, goods, raw materials, etc.), financial flows (cash and non-cash, investments, etc.), document flows (commercial, financial and organizational documents), information flows (information, data of intent, oral instructions, etc.) and resources (employees, machines, machines, etc.). In this case, in various cases, all types of objects can be displayed by incoming and outgoing interface arcs, which control only those related to the flows of documents and information, and only resources can be displayed by arcs-mechanisms.

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.

The third basic concept of the IDEF0 standard is Decomposition. The decomposition principle is used when breaking down a complex process into its constituent functions. In this case, the level of detail of the process is determined directly by the model developer.

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

The IDEF0 model always starts with representing the system as a whole - a single functional block with interface arcs extending beyond the considered area. Such a diagram with one functional block is called a context diagram, and is denoted by the identifier “A-0”.

The explanatory text for the context diagram must indicate the Purpose of building the diagram in the form of a brief description and fix the point of view (Viewpoint).

Defining and formalizing the goal of developing an IDEF0 - model is an extremely important point. In fact, the goal identifies the relevant areas in the system under study that should be focused on first. For example, if we model the activities of an enterprise in order to build an information system on the basis of this model in the future, then this model will differ significantly from the one that we would develop for the same enterprise, but with the aim of optimizing supply chains.

The point of view defines the main direction of development of the model and the level of detail required. A clear fixation of the point of view allows you to unload the model, refusing to detail and study individual elements that are not necessary, based on the chosen point of view on the system. For example, the functional models of the same enterprise from the point of view of the chief technologist and the financial director will differ significantly in the direction of their detailing. This is due to the fact that, in the end, the CFO is not interested in the aspects of processing raw materials on production machines, and the chief technologist does not need drawn schemes of financial flows. The correct choice of point of view significantly reduces the time spent on building the final model.

In the process of decomposition, the functional block, which in the context diagram displays the system as a whole, is drilled in another diagram. The resulting diagram of the second level contains functional blocks that display the main subfunctions of the functional block of the context diagram and is called a child diagram (Child diagram) in relation to it (each of the functional blocks belonging to a child diagram is respectively called a child block). In turn, the parent function block is called the parent block in relation to the child diagram (Parent Box), and the diagram to which it belongs is called the parent diagram (Parent Diagram). Each of the sub-functions of the child diagram can be further detailed by a similar decomposition of the corresponding functional block. It is important to note that in each case of decomposition of a functional block, all interface arcs included in this block or outgoing from it are fixed in the child diagram. This achieves the structural integrity of the IDEF0 model. The principle of decomposition is clearly shown in Figure 4. You should pay attention to the relationship between the numbering of functional blocks and diagrams - each block has its own unique serial number on the diagram (the number in the lower right corner of the rectangle), and the designation at the right angle indicates the number of the child diagram for this block ... The absence of this designation means that there is no decomposition for this block.

There are often cases when individual interface arcs do not make sense to continue to be considered in child diagrams below a certain level in the hierarchy, or vice versa - individual arcs have no practical meaning above a certain level. For example, it makes no sense to reflect the interface arc depicting a “detail” at the entrance to the “Turn on a lathe” function block on diagrams of higher levels - this will only overload the diagrams and make them difficult to understand. On the other hand, there is a need to get rid of individual “conceptual” interface arcs and not detail them deeper than a certain level. To solve such problems, the IDEF0 standard provides for the concept of tunneling. The Arrow Tunnel designation in the form of two parentheses around the beginning of the interface arc denotes that this arc was not inherited from the functional parent block and appeared (from the "tunnel") only in this diagram. In turn, the same designation around the end (arrow) of the interface arc in the immediate vicinity of the receiver block means the fact that in the child diagram of this block this arc will not be displayed and will not be considered. Most often it happens that individual objects and their corresponding interface arcs are not considered at some intermediate levels of the hierarchy - in this case, they are first “plunged into the tunnel” and then, if necessary, “returned from the tunnel”.

The last of the IDEF0 concepts is the Glossary. For each of the IDEF0 elements: diagrams, functional blocks, interface arcs, the existing standard implies the creation and maintenance of a set of appropriate definitions, keywords, narratives, etc. that characterize the object displayed by this element. This set is called a glossary and is a description of the essence of this element. For example, for a control interface arc “payment order”, the glossary may contain a list of fields of the document corresponding to the arc, the required set of visas, etc. The glossary harmoniously complements the graphical language, providing the diagrams with the necessary additional information.

Figure 4. Decomposition of functional blocks.

The principles of limiting the complexity of IDEF0 diagrams

Typically, IDEF0 models carry complex and concentrated information, and in order to limit their congestion and make them readable, the corresponding complexity limits are adopted in the corresponding standard:

Limiting the number of functional blocks in the diagram to three to six. The upper limit (six) forces the designer to use hierarchies when describing complex items, and the lower limit (three) ensures that there is enough detail on the corresponding diagram to justify its creation;

Limiting the number of interface arcs suitable for one functional block (leaving one functional block) to four.
Of course, it is not at all necessary to strictly follow these restrictions, however, as experience shows, they are very practical in real work.

Discipline of group work on the development of the IDEF0-model

The IDEF0 standard contains a set of procedures that allow a large group of people from different areas of the modeled system to develop and agree on a model. Typically, the development process is iterative and consists of the following conditional stages:

Creation of a model by a group of specialists related to various areas of the enterprise. This group is called Authors in terms of IDEF0. Building an initial model is a dynamic process, during which authors interview competent persons about the structure of various processes. Based on the existing provisions, documents and survey results, a draft (Model Draft) of the model is created.

Distribution of the draft for review, approval and comments. At this stage, the draft model is discussed with a wide range of competent persons (in terms of IDEF0 readers) in the enterprise. In this case, each of the diagrams of the draft model is criticized and commented in writing, and then transferred to the author. The author, in turn, also agrees in writing with the criticism or rejects it, outlining the logic of the decision-making and returns the revised draft for further consideration. This cycle continues until the authors and readers come to a consensus.

Model approval. The approved model is approved by the head of the working group in the event that the authors of the model and the readers do not have disagreements about its adequacy. The final model is a consistent view of the enterprise (system) from a given point of view and for a given purpose.
The visibility of the IDEF0 graphic language makes the model quite readable for people who did not take part in the project of its creation, as well as effective for holding shows and presentations. In the future, on the basis of the constructed model, new projects can be organized aimed at making changes in the enterprise (in the system).

Features of the national practice of using functional modeling by means of IDEF0

In recent years, interest in the IDEF family of methodologies has been steadily growing in Russia. I constantly observe this, looking at the statistics of calls to my personal web page (http://www.vernikov.ru), which briefly describes the basic principles of these standards. At the same time, I would call interest in such standards as IDEF3-5 theoretical, and in IDEF0 quite practically justified. As a matter of fact, the first Case-tools allowing to build DFD and IDEF0 diagrams appeared on the Russian market back in 1996, simultaneously with the release of the popular book on the principles of modeling in the SADT standards.

Nevertheless, most executives still regard the practical application of modeling in IDEF standards as a fashion statement rather than an effective way to optimize the existing business management system. Most likely, this is due to a pronounced lack of information on the practical application of these methodologies and with the indispensable software bias of the vast majority of publications.

It is no secret that almost all projects for the survey and analysis of the financial and economic activities of enterprises now in Russia are in one way or another connected with the construction of automated control systems. Thanks to this, the IDEF standards, in the understanding of the majority, have become conditionally inseparable from the implementation of information technologies, although with their help it is sometimes possible to effectively solve even small local problems, literally with the help of a pencil and paper.

When conducting complex enterprise survey projects, the development of models in the IDEF0 standard allows you to visually and effectively display the entire mechanism of enterprise activity in the desired context. Most important, however, is the collaboration that IDEF0 provides. In my practice, there were quite a few cases when the construction of the model was carried out with the direct help of employees of various departments. At the same time, the consultant explained to them the basic principles of IDEF0 in a fairly short time and taught them to work with the corresponding application software. As a result, employees of various departments created IDEF diagrams of the activities of their functional unit, which were to answer the following questions:

What goes to the unit “at the entrance”?

What functions, and in what sequence, are performed within the unit?

Who is responsible for each of the functions?

What is the executor guided by when performing each of the functions?

What is the result of the unit's work (output)?

After agreeing on draft diagrams within each specific department, they are collected by the consultant into a draft enterprise model, in which all input and output elements are linked. At this stage, all the discrepancies of individual diagrams and their controversial places are recorded. Further, this model again passes through the functional departments for further agreement and making the necessary adjustments. As a result, in a fairly short time and with the involvement of a minimum of human resources from a consulting company (and these resources, as you know, are very expensive), an IDEF0-model of an enterprise is obtained according to the “As is” principle, and, which is important, it represents an enterprise with positions of employees who work in it and thoroughly know all the nuances, including informal ones. In the future, this model will be transferred for analysis and processing to business analysts who will look for bottlenecks in company management and optimize the main processes, transforming the “As is” model into the corresponding “As should be” view. Based on these changes, a final conclusion is made, which contains recommendations for reorganizing the management system.

Of course, such an approach requires a number of organizational measures, primarily on the part of the management of the surveyed enterprise. This is due to the fact that this technique implies the assignment of additional responsibilities to some staff in the development and practical application of new methodologies. However, in the end, this pays off, since an additional one or two hours of work of individual employees over several days can significantly save money on paying for consulting services to a third-party company (which in any case will tear off the work of the same employees with questionnaires and questions). As for the employees of the enterprise themselves, in one way or another, I have not met any expressed opposition on their part.

The conclusion from all this can be done as follows: it is not at all necessary to come up with solutions for standard problems every time. Whenever you are faced with the need to analyze a particular functional system (from a spacecraft design system to the process of preparing a complex dinner), use methods that have been tried and tested over the years. One of these methods is IDEF0, which allows you to solve complex life problems with the help of its simple and understandable tools.

The purpose of the methodology is to construct a functional diagram of the system under study, describing all the necessary processes with an accuracy sufficient for unambiguous modeling of the system's activity.

The methodology is based on four main concepts: function block, interface arc, decomposition, glossary.

Functional block (Activity Box) represents some specific function within the framework of the considered system. According to the requirements of the standard, the name of each functional block must be formulated in the verb mood (for example, "to produce services"). In the diagram, the functional block is represented by a rectangle (Fig. 3.).

Each of the four sides of a functional block has its own specific meaning (role), while:

The top side is Control;

The left side is Input;

The right side is set to Output;

The downside is "Mechanism".

Interface arc (Arrow) displays a system element that is processed by a function block or has some other effect on functionrepresented by this function block. Interface arcs are often referred to as streams or arrows.

Fig. 3. - Functional block

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

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 the basic concept of the IDEF0 standard. The decomposition principle is applied when dividing a complex process into its constituent parts. function... In this case, the level of detail of the process is determined directly by the model developer.

Decomposition allows you to gradually and structured represent the system model in the form of a hierarchical structure of individual diagrams, which makes it less overloaded and easy to digest (Fig. 4.).

The last of the IDEF0 concepts is the Glossary. For each of the IDEF0 elements - diagrams, functional blocks, interface arcs - the existing standard implies the creation and maintenance of a set of appropriate definitions, keywords, narratives, etc. that characterize the object displayed by this element. This set is called a glossary and is a description of the essence of this element. The glossary harmoniously complements the graphic language, providing the diagrams with the necessary additional information.

The IDEF0 model always starts with the presentation of the system as a whole - a single functional block with interface arcs extending beyond the considered area. Such a diagram with one functional block is called context diagram.

The explanatory text for the context diagram must indicate target (Purpose) constructing the diagram as a short description and fixed point of view.

Fig. 4. - Scheme of decomposition of functional blocks of the model

Determining and formalizing the goal of developing an IDEF0 model is an extremely important point. In fact, the target identifies the relevant areas in the system under study that should be focused on first.

The point of view defines the main direction of development of the model and the level of detail required.

A clear fixation of the point of view allows you to unload the model, refusing to detail and study individual elements that are not necessary, based on the chosen point of view on the system. The correct choice of point of view significantly reduces the time spent on building the final model.

Highlighting subprocesses... In the process of decomposition, the functional block, which in the context diagram displays the system as a whole, is drilled in another diagram. The resulting diagram of the second level contains functional blocks that display the main subfunctions of the functional block of the context diagram, and is called the Child Diagram in relation to it (each of the functional blocks belonging to the child diagram, respectively, is called the Child Box).

In turn, the parent function block is called the parent block in relation to the child diagram (Parent Box), and the diagram to which it belongs is called the parent diagram (Parent Diagram). Each of the sub-functions of the child diagram can be further detailed by a similar decomposition of the corresponding functional block. In each case of decomposition of a functional block, all interface arcs entering or leaving this block are fixed in the child diagram. This achieves the structural integrity of the IDEF0 model.

Sometimes it makes no sense to continue to consider individual interface arcs of the higher level on the diagrams of the lower level, or vice versa - to reflect individual arcs of the lower level on diagrams of higher levels - this will only overload the diagrams and make them difficult to understand. To solve such problems, the IDEF0 standard provides for the concept of tunneling. The "Arrow Tunnel" notation in the form of two parentheses around the beginning of the interface arc indicates that this arc was not inherited from the functional parent block and appeared (from the "tunnel") only in this diagram.

In turn, the same designation around the end (arrow) of the interface arc in the immediate vicinity of the receiving block means that this arc will not be displayed and will not be considered in the child diagram of this block. Most often, individual objects and their corresponding interface arcs are not considered at some intermediate levels of the hierarchy - in this case, they first "plunge into the tunnel" and then, if necessary, "return from the tunnel".

Typically IDEF0 models carry complex and concentrated information, and in order to limit their congestion and make them readable, the standard adopts appropriate complexity constraints.

It is recommended to represent on the diagram from three to six functional blocks, while the number of interface arcs suitable for one functional block (leaving one functional block) is assumed to be no more than four.

The IDEF0 standard contains a set of procedures that allow a large group of people from different areas of the modeled system to develop and agree on a model.

Usually the development process is iterative and consists of the following conditional stages: Creation of a model by a group of specialists related to various areas of the enterprise. This group is called Authors in terms of IDEF0. Building an initial model is a dynamic process, during which authors interview competent persons about the structure of various processes, creating models for the activities of departments.

At the same time, they are interested in the answers to the following questions:

What goes into the unit "at the entrance"?

What kind function and in what sequence are they performed within the unit?

Who is responsible for the implementation of each of the functions?

What is guided by the performer when performing each of functions?

What is the result of the unit's work (output)?

Based on the existing provisions, documents and survey results, a draft (Model Draft) of the model is created.

Distribution of the draft for review, approval and comments. At this stage, there is a discussion of the draft model with a wide range of competent persons (in terms of IDEF0 - readers) in the enterprise. At the same time, each of the diagrams of the draft model is criticized and commented in writing, and then transferred to the author. The author, in turn, also agrees in writing with the criticism or rejects it outlining the logic of decision-making and returns the revised draft for further consideration. This cycle continues until the authors and readers come to a consensus.

The visibility of the IDEF0 graphic language makes the model quite readable for persons who did not take part in the project of its creation, as well as effective for holding shows and presentations. In the future, on the basis of the constructed model, new projects can be organized aimed at making changes in the model.

The IDEF0 model is recommended for use in an enterprise when describing business processes at the top level. When compiling a functional model of a business process (IDEF0), the functions performed and the input, output flows of material, financial resources and information (documents, files) are described.

IDEF0 format conventions are presented in Tables 2, 3.

Table 2. - Graphic symbols of notation IDEF0

Symbol	Picture	Description
Block		The block describes the process. A typical block is shown in fig. 1. Each block contains its name and number. The name must be an active verb, a verbal turnover, or a verbal noun. The block number is located in the lower right corner. Block numbers are used for identification in the diagram and in the corresponding text.
Arrow		Arrows indicate objects (data) inbound and outbound from the process. Each side of a function block has a standard meaning in terms of block-arrow communication. In turn, the side of the block to which the arrow is attached uniquely defines its role. Arrows entering the left side of the block are entrances. Arrows entering the block from above are controls. Arrows leaving the process on the right are exits, i.e. data or material objects produced by the process. Arrows connected to the underside of the unit represent mechanisms.
Tunneling arrow		Tunneled arrows indicate that the data indicated by these arrows is not viewed in the parent chart and / or in the child chart. An arrow placed in the tunnel where it joins the block means that the data expressed by that arrow is not required at the next level of decomposition. An arrow placed in a tunnel at the free end means that the data it represents is not present in the parent chart.
External reference		An external reference is a place, entity or subject that is outside the boundaries of the modeled system. Used to indicate the source or destination of an arrow outside the model. In diagrams, the Xref is displayed as a square, next to which the Xref name is shown.
Inter-diagram link		An element that designates another chart. Used to indicate the transition of arrows to the diagram of another business process without showing the arrow in the above diagram (when using hierarchical models).

Table 3. - Graphic symbols of IDEF0 notation

IDEF0 is a graphical modeling notation used to create a functional model that depicts the structure and functions of a system, as well as the flows of information and material objects that link these functions. The IDEF0 (Integration Definition for Function Modeling) standard was approved in the USA in 1993 as the Federal Information Processing Standard. In Russia, it has been in the status of a guiding document since 2000 and is currently not approved as a standard. Nevertheless, the IDEF0 methodology is one of the popular approaches for describing business processes. Its features include:

using a context diagram;

decomposition support;

dominance;

selection of 4 types of arrows.

Context diagram. The topmost diagram, in which the modeling object is represented by a single box with boundary arrows. This diagram is called A-0 (A minus zero). The arrows in this diagram represent the relationships of the modeling object with the environment. Chart A-0 sets the modeling area and its boundary. An example of diagram A-0 is shown in Fig. one.

Figure 1. Diagram A-0 in IDEF0 notation

Decomposition support. IDEF0 notation supports sequential decomposition of the process to the required level of detail. The child diagram created by decomposition covers the same area as the parent process, but describes it in more detail. According to the IDEF0 methodology, during the decomposition, the arrows of the parent process are transferred to the child diagram in the form of boundary arrows.

Domination. IDEF0 model blocks on a non-contextual diagram should be located diagonally - from the upper left corner of the diagram to the lower right corner in the order of the assigned numbers. The blocks in the diagram at the top left "dominate" the blocks at the bottom right. "Dominance" is understood as the influence that a block has on other blocks in the diagram. The arrangement of blocks on the chart sheet reflects the author's understanding of dominance. Thus, the topology of the diagram shows which features have the greatest impact on the others.

Allocation of 4 types of arrows. The following types of arrows are distinguished: "Input", "Output", "Mechanism", "Control". The inputs are transformed or consumed by the process to create what appears in its output. The controls define the conditions necessary for the process to produce the correct exit. Outputs are data or material objects produced by the process. Mechanisms identify the means that support the execution of a process. Thus, the IDEF0 block shows the transformation of an input into an output using mechanisms taking into account control actions.

Description of the purpose of graphic symbols used in IDEF0 notation is given in Table 1.

Name	Graphic symbol	Description
		The process is indicated by a rectangular box. Each block contains its name and number. The name must be an active verb, a verbal phrase, or a verbal noun. The block number is located in the lower right corner. Block numbers are used for identification in the diagram and in the corresponding text.
		Arrows indicate objects (data) entering and leaving the process. Each side of the function block has a standard meaning in terms of block-arrow communication. In turn, the side of the block to which the arrow is attached uniquely defines its role. Arrows entering the left side of the block are entrances. Arrows entering the block from above - controls. Arrows leaving the process on the right are exits, i.e. data or material objects produced by the process. Arrows connected to the underside of the block represent mechanisms.
Tunneling arrow		Tunneled arrows indicate that the data flowing through these arrows is not viewed in the parent chart and / or child chart. An arrow placed in the tunnel where it joins the block means that the data expressed by that arrow is not required at the next level of decomposition. An arrow placed in a tunnel at the free end means that the data it represents is not present in the parent chart. Tunneled arrows can be used on process diagrams in the notations IDEF0, "Process", "Procedure".
		The element designates a place, entity or subject that is outside the boundaries of the modeled system. Xrefs are used to indicate the source or destination of an arrow outside the model. In diagrams, an xref is shown as a square, next to which the xref name is shown. External links can be used in process diagrams in any notation.
		An element that designates another chart. An inter-diagram link is used to indicate the transition of an arrow to a diagram of another process without displaying an arrow on the above diagram (when using hierarchical models). An EPC and BPMN process diagram cannot be used as an inter-diagrammatic reference. Inter-diagrammatic links can be used on process diagrams in the notations IDEF0, "Process", "Procedure".
		The element denotes a reference to a typical process model. The most frequently repeated processes within the business process model can be identified as typical in a separate folder in Navigator... The diagram of a typical process is formed once in one place Navigator... Further, on any diagram, a process linking to a typical process can be used. The parameters of a typical process are filled directly in Properties window typical process. A permanent list of subjects participating in the implementation of a typical process is also formed in Properties window typical process. The list of subjects participating in the implementation of a typical process within the framework of the overlying process is formed in Properties window process-links to a typical process. Reference processes can be used in process diagrams in any notation.
		A callout element designed to add comments. The element can be used in process diagrams in any notation.

Known today not only in narrow circles, the abbreviation IDEF0 is the first methodology to standardize work on business processes. It was developed in the middle of the last century as part of an aerospace project in the United States and, having shown its effectiveness, has become 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 edition. Gosstandart of Russia RD IDEF0 - 2000. Developed by the Research Center CALS - Technologies "Applied Logistics". Adopted and put into effect by the Resolution of the Gosstandart of Russia 2000, Moscow”, But as a standard it was never approved. 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 review the IDEF0 model and assess the current relevance of this approach.

Basic concepts and abbreviations

Let's understand a little about 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 were supposed to allow the study of the structure, parameters and characteristics of production-technical and organizational-economic systems.

IDEF0 is a functional model, which is the core of all other structures, it links together information and material flows, organizational structure, control actions and the very activity 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, it is appropriate to call IDEF0 the notation that is part of the SADT methodology.

IDEF0 notation is a fairly rigorous technique 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 schemes, and an unambiguous systematization and navigation through all elements of the model is required. Now this is done mainly by computer systems that support modeling in this notation. On the territory of Russia, the most famous and available today are the AllFusion Process Modeler and Business Studio systems. I plan to devote separate articles to the review of these systems.

Functional block

The central element of the IDEF0 model is the function, which is displayed on the diagram as functional block - a rectangle, inside which the 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 "Drawing on a product".

Mandatory function block elements in IDEF0

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

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

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

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 spent on creating a result in full, 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 which rules and requirements must be observed in the process of performing the function. Often this flow is treated formally, but the scheme loses its rigor and sometimes even meaning.
Each functional block must have at least one arrow on each side (since there can be no work without resources or results, and an instruction without an executor or instruction will be incomplete).

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

Context diagram

At the highest level, the company is presented as a "black box" in which some activity takes place, which translates inputs into outputs. This level is usually called "", that is, a diagram describing the context of the company's activities. Additionally, the context diagram displays the key characteristics of the entire model.

The goal is a specific formulation of the purpose of the model, by which the accuracy of the model construction can be checked in the future.
Point of view - on whose face 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.
The model type is an indication of what information is displayed on the diagrams. There can be 2 basic options: AS IS ("as is") or TO BE ("as will be"). This separation is necessary, since we can build models for both the analysis of activities and for its transformation. We must be clearly aware of what we are doing, and also convey this information to others.

Thus, the context diagram contains in the most generalized form a description of the company's activities, which is permeated by the flows that connect the company with the outside world. I think we should also dwell on them in more detail.

Main streams

Experience has shown that, despite the seeming simplicity and formality of this level, it is often necessary to stay at it for a long time, since all the 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 tasks set for the business. To verify that significant flows are reflected, make sure that all 4 main flow types are present in your diagram.

Material: materials and components at the entrance and finished products at the exit.
Client: a potential client at the entrance and a satisfied one at the exit.
Financial: at the entrance, these are usually investments, customer payments (revenue), loans and other income; the output is payments to suppliers, taxes, loan payments and profits.
Informational: at the input, these are all flows of information about the external environment (market conditions, competitors' behavior, technological innovations, etc.), and at the output, this 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 the regulatory authorities).

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

(click to enlarge)

It is good if you highlight each of these types of flows with your own color so that you can easily distinguish the movement of resources and do not miss important points. For example, it is often possible to observe the absence of a client in the company's flows, therefore, work with him is built on a leftover principle - the client often feels like a hindrance for the company's employees, whose tasks are focused on processing the flow of documents.

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

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

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

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

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

Decomposition

After working out the flows of the context diagram, we can proceed to decomposition. Moving to a level below, as if opening a "black box", we first see a blank sheet with arrows that have been attached to the functional block.

(click to enlarge)

And here the actual functional modeling begins - we must understand what set of actions can connect these flows and ensure that all the requirements are met. The difficulty lies in the fact 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, accordingly, useless.

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

Creation of a product (result).
Promotion and sale - working with customer flow.
Support for product creation activities are secondary processes that are necessary to comply with government requirements or to ensure the convenience of work (personnel and accounting, transport services, cleaning of premises, etc.).
Creation of management flows is the activity of developing management solutions that will determine the requirements for all processes of the company.

The figure below shows the decomposition diagram of our example.

(click to enlarge)

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

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

Conclusions about the relevance of the notation

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

The model has good visualizing potential, but, in my opinion, its greater importance is in the disciplining effect. The rules and limitations embedded in the methodology force us to develop a systematic and strict attitude to the 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 strongly connected things: to connect the front and back office subsystems with management, which is much worse for other notations.
The approach is simple and understandable for most of the project participants. Building and reading diagrams in this notation is limited only by the desire to delve into the intricacies of business flows.

Some of the above arguments make one think that this approach is the best and only one for a complete modeling of activities. But do not forget that the functional model is designed only for the upper level of modeling. The use of the IDEF0 notation for the design of work at the performer level leads to the fact that the diagrams are purely illustrative and on their basis it is impossible to build a sensible regulation, since they do not contain:

concretizing the events of starting and stopping the process;
conditions for the 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 for today that allows you to do this meaningfully and accurately.

In project management, this modeling standard is most applicable where you need to link different projects or processes with visual flows. At the same time, the graphical model will make it possible to more rationally distribute responsibility and resources by tasks. The logic of the project tasks, reflected in the diagrams, will help to prepare a better schedule in the form of a Gantt chart.

One 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 general model of the company's work. It is not enough to understand that a certain unit is not working properly, it is important to understand how it interacts with others. Otherwise, it is impossible to identify all existing problems and choose the best method for solving the problem. And for this it is required 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 if we are talking about organizing the work of a warehouse or about an IT system from lead to application. But in reality, it almost never turns out, and therefore in the process of studying and searching for a solution to the problem posed by the client, I also create a functional model of the company's work or a certain process (function) on my own.

A few words about the benefits of graphics

As you know, IDEF0 functional models are always graphical diagrams. They have their own characteristics and compilation rules. We will 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 assertion about the need for a functional model of the company's work, many people thought that all this was not necessary, it is possible to explain in words how this or that function works in the company. This is what I want to talk about.

And to begin with, let's make a small excursion into history. Let's go back to the distant 1877, during the Russo-Turkish War. It was then that the polygraphist Sytin first used graphics when describing military operations. Now for us all this is familiar, when describing any battle, cards with arrows appear in front of everyone's eyes, which clearly show the course of the battle. And in those days, military actions were described in words. There are many, many words for each fight. And it was very difficult to understand what was happening in the end.

Therefore, Sytin's idea was truly revolutionary - he began to print lithographic copies of maps showing the fortifications and locations of military units. These cards were called “For newspaper readers. Benefit ”. The idea turned out to be so relevant that the very first edition of the "Manuals" was sold out instantly. And then such applications were in great demand. The reason is obvious. The graphics helped to understand what was almost impossible to make out with the help of words alone.

I can give a similar example of the helplessness of verbal descriptions from my own practice. One of my clients very much asked to take up the implementation of an ERP system for his company. When asked if they had any technical task, I received the answer: “Yes, there is. But it has 400 pages. ” At the same time, the client complained very much that my colleagues, whom he had contacted earlier, either abandoned the project altogether, or called clearly inflated prices. After I saw that the terms of reference really had 400 pages, and it consisted exclusively of a text description, I understood the reasons for the behavior of the developers. To read such a volume of text, to delve into it, to understand all the nuances just in order to understand the task and name the price - this is really very difficult.

I offered this client an alternative option - to 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 task.

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

Why is it important to my job

My job is always related to making changes to the existing system. And in order to make changes and get the desired result, you need to study what exists now. And it doesn't matter what exactly we do - we set up or install a CRM system from scratch, create an effective ERP system, integrate various systems to increase the automation of work in general. In any case, to begin with, you need to get an idea of \u200b\u200bthe existing scheme of work, and only after that you can propose some changes and think over 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 disclose my vision of the current situation in as much detail as possible, as well as the actions that need to be performed to solve the task, and, of course, the expected result.

Such reports on the survey of work are voluminous, occupy more than one page, which, on the one hand, is necessary, and on the other, complicates perception. At first, like many others, I thought that lengthy reports are good, because a person pays for work and needs to be provided with as much detailed information as possible.

Typical mistakes

Functional modeling is performed using a wide variety of tools, including those not intended for modeling. In the latter case, there is no error checking and limitations of the standard. The desire to increase visibility and lack of experience often end 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 process disruption and production 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 colored arrows and blocks only adds confusion and 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 improved 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 a large number of control arrows. In this case, readability is lost.

The best option is detailing, sufficient to understand the issue, and nothing more. Detailed detailing of the work of each department or even an 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.

Breakdown of structure when making adjustments

Be careful not to create confusion or processes without incoming, outgoing and other important elements. For example, if in the example above, I see fit to shift the point of view to the copywriter, I will remove the author from the schema. And then the "author experience and third-party sources" controls and publication plan become unnecessary. After all, the author uses them. A copywriter works with an audio file. And if they remain in the general scheme, then, when detailed, they will lead it is not clear where and cause confusion.

Likewise, if I decide to add a block, it is important to make sure that it also has all the required attributes. Carefulness is very important here, since when modeling complex business processes, changes in one part of the model can lead to changes in another. They must be entered.

Rules for naming controls and blocks

It is important to remember a simple rule: control arrows are called nouns, blocks are called verbs. This is 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 article" they write "Create article". Blocks in this approach are actions, and therefore they must always be verbs.

Benefits of using IDEF0

The very first benefit is obvious - it's visibility. You yourself begin to understand how this or that system works, and you can also clearly explain where the “bottlenecks” are in this system and how your decisions will help get rid of them.
Mutual understanding and lack of discrepancies. When discussing the work of a company using a functional model, you have visual and intuitive task blocks with control elements. In addition, functional modeling involves the creation, if necessary, of a glossary in which conventions and terms are disclosed. As a result, you and the client, the manager, and other employees speak the same language when discussing the problem.
Simplicity and high speed of model creation. Of course, learning to model is not as easy as it sounds. After all, a scheme is, in fact, an ultra-dense presentation of information, which is very good for understanding, but a special approach is required to implement such a presentation. In this case, the analyst's brain acts 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 to figure out what is happening in a particular system, and with the help of a visual aid created in a short time, illustrate important points to colleagues or customers.
Discipline and lack of error. The IDEF0 standard assumes strict frameworks and rules. This approach is disciplined, and the habit of acting within the standard helps to avoid mistakes due to inattention. Any violations of the standard are immediately visible.

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, the depth of understanding of the business that he seeks to describe, as well as, 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 leader, as if he were the leader.

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

That is why it is very important, when drawing up a functional business model "as is", to constantly consult with the head of the company, so as not to make mistakes, which will automatically entail mistakes at the stages of decomposition. Also, at subsequent stages, additional coordination with the heads of structural divisions and employees may be required. Only if your functional model "as is" really reflects the real state of affairs, you can make some changes and suggestions. And in order to achieve high-quality results in such work, first of all, practical experience and knowledge of the features of a particular type of business are required.