The main methodologies for surveying organizations. IDEF0 standard.

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

At present, interest in management standards generally accepted in the West has sharply increased in Russia, however, in real management practice, there is one very significant moment. Many managers can still be baffled by a direct question about the organizational structure of the company or about the scheme of existing business processes. The most advanced and regularly reading economic periodicals managers, as a rule, begin to draw hierarchical diagrams understandable only to them alone, but in this process they usually quickly come to a standstill. The same applies to employees and heads of various services and functional units. In most cases, the only set of stated rules under which an enterprise must operate is a set of separate regulations and job descriptions. Most often, these documents were compiled more than one year ago, they are poorly structured and unrelated to each other and, as a result, they 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 calculate the costs - the profit was gigantic. As a result of this, over the past two years we have seen a completely understandable picture: large companies that grew up in the early 90s are gradually losing ground, up to a complete withdrawal from the market. This is partly due to the fact that management standards were not introduced at the enterprise, the concept of a functional model of activity and mission was completely absent. By modeling various areas of activity, it is possible to effectively analyze "bottlenecks" in management and optimize the overall business scheme. But, as you know, in any enterprise, only those projects that directly bring profit have the highest priority, so it is usually a question of examining activities and reorganizing it only during a tangible crisis in the management of the company.

In the late 1990s, when the market began to become more competitive and the profitability of enterprises began to fall sharply, managers felt great difficulty in trying to optimize costs so that products remained both profitable and competitive. Just at that moment, the need to have before our eyes a model of the enterprise's activity, which would reflect all the mechanisms and principles of the interconnection of various subsystems within one business, clearly manifested itself.

The very concept of "business process modeling" came into the 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 recommendations are made in separate paragraphs to eliminate "bottlenecks" in the management of activities. Based on this conclusion, immediately before the implementation of the automation system, the so-called reorganization of business processes is carried out, sometimes quite serious and painful for the company. This is, of course, a team that has developed over the years is always difficult to make "think in a new way." Such comprehensive surveys of enterprises are always complex and differ significantly from case to case. There are well-established methodologies and standards for solving such problems of modeling complex systems. These standards include the IDEF family of methodologies. With their help, you can effectively display and analyze the activity models of a wide range of complex systems in various sections. At the same time, the breadth and depth of the examination of processes in the system is determined by the developer himself, which allows not to overload the created model with unnecessary data. Currently, the following standards can be attributed to the IDEF family:

IDEF0 is a functional modeling methodology. With the help of a visual graphical language IDEF0, the system under study appears to developers and analysts as a set of interrelated functions (functional blocks - in terms of IDEF0). Typically, IDEF0 modeling is the first step in learning any system;
IDEF1 - a methodology for modeling information flows within a system that allows you to display and analyze their structure and relationships;
IDEF1X (IDEF1 Extended) is a methodology for building relational structures. IDEF1X belongs to the type of Entity-Relationship (ER) methodologies and is usually used to model relational databases relevant to the system under consideration;
IDEF2 is a methodology for dynamic modeling of systems evolution. In connection with the very serious difficulties in the analysis of 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 allow turning a set of IDEF0 static diagrams into dynamic models built on the basis of “colored Petri nets” (CPN – Color Petri Nets);
IDEF3 is a methodology for documenting processes occurring in a system, which is used, for example, in the study of technological processes in enterprises. IDEF3 describes the scenario and sequence of operations for each process. IDEF3 has a direct relationship with the IDEF0 methodology - each function (functional block) can be represented as a separate process using IDEF3 tools;
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 system ontology can be described using a certain vocabulary of terms and rules, on the basis of which reliable statements about the state of the system under consideration at some point in time can be formed. Based on these statements, conclusions are drawn about the further development of the system and its optimization is carried out.

Within the framework of this article, we will consider the most commonly used IDEF0 functional modeling methodology.

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). A few years ago, a small edition of a book of the same name was published in Russia, dedicated to describing the basic principles of constructing SADT diagrams. Historically, IDEF0 as a standard was developed in 1981 as part of an extensive industrial automation program, which bore the designation ICAM (Integrated Computer Aided Manufacturing) and was proposed by the US Air Force Department. The IDEF family of standards itself has inherited its designation from the name of this program (IDEF=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”. 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 restrictive, and its last revision was released in December 1993 by the US National Institute of Standards and Technology (NIST).

Basic elements and concepts of IDEF0

The IDEF0 graphical language is remarkably simple and harmonious. The methodology is based on four main concepts:

The first of these is the concept function block (Activity Box). The functional block is graphically depicted as a rectangle (see Fig. 1) and represents some specific function within the considered system. According to the requirements of the standard, the name of each functional block must be formulated in the verbal mood (for example, “to produce services”, and not “to produce services”).

Each of the four sides of the 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 bottom side has the meaning “Mechanism” (Mechanism).

Each functional unit within the single system under consideration must have its own unique identification number.

Figure 1. Function block.

The second “whale” of the IDEF0 methodology is the concept interface arc (Arrow). Also, interface arcs are often called flows or arrows. An interface arc represents 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 one-way arrow. Each interface arc must have its own unique name (Arrow Label). According to the standard, the name must be a turnover of a noun.

With the help of 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, wagons, employees, etc.) or data and information flows (documents, data, instructions, etc.).

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

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.

When constructing IDEF0 diagrams, it is important to correctly separate incoming interface arcs from control arcs, which is often not easy. For example, Figure 2 shows the “Process workpiece” functional block.

In a real process, the worker performing the processing is given a workpiece and technological instructions for processing (or safety regulations when working with the machine). It may mistakenly appear that both the workpiece and the document with technological instructions are input objects, but this is not the case. In fact, in this process, the workpiece is processed according to the rules reflected in the technological instructions, which should be respectively depicted 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 already displayed by the incoming interface arc, and the control object is, for example, new industrial standards, based on which these changes are made.

Figure 3

The above examples emphasize the seemingly similar nature of incoming and controlling 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, verbal orders, etc.) and resources (employees, machines, machines, etc.). In this case, in various cases, incoming and outgoing interface arcs can display all types of objects that manage only those related to the flow of documents and information, and only resources can be displayed as 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 core concept of the IDEF0 standard is decomposition. The principle of decomposition is applied when a complex process is broken down into its constituent functions. In this case, the level of detail of the process is determined directly by the developer of the model.

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

The IDEF0 model always begins with a view of the system as a whole - a single functional unit with interface arcs extending beyond the considered area. Such a diagram with one function block is called a context diagram, and is denoted by the identifier "A-0".

In the explanatory text for the context diagram, the purpose (Purpose) of constructing the diagram in the form of a brief description should be indicated and fixed point of view(viewpoint).

Determining and formalizing the purpose of developing an IDEF0 model is an extremely important point. In fact, the goal determines the relevant areas in the system under study, which need to be focused first. For example, if we model the activities of an enterprise in order to build an information system based on 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 determines the main direction of the 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, functional models of the same enterprise from the point of view of the chief technologist and financial director will differ significantly in the direction of their detailing. This is due to the fact that, in the end, the financial director is not interested in the aspects of processing raw materials on production machines, and the chief technologist is not interested in the 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 detailed 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 the child diagram is respectively called a child block - Child Box). In turn, the functional block - the ancestor 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 subfunctions of the child diagram can be further detailed by a similar decomposition of its 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 on 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 corner indicates the number of the child diagram for this block . The absence of this designation indicates that there is no decomposition for this block.

Often there are cases when it does not make sense to continue to consider individual interface arcs in child diagrams below a certain level in the hierarchy, or vice versa - individual arcs do not make practical sense above a certain level. For example, an interface arc depicting a “detail” at the input to the “Machining on a lathe” function block does not make sense to reflect on diagrams of higher levels - this will only overload the diagrams and make them difficult to read. On the other hand, there is a need to get rid of separate "conceptual" interface arcs and not to detail them deeper than a certain level. To solve such problems, the IDEF0 standard provides for the concept tunneling. The designation of the “tunnel” (Arrow Tunnel) in the form of two parentheses around the beginning of the interface arc means that this arc was not inherited from the functional parent block and appeared (from the “tunnel”) only on this diagram. In turn, the same designation around the end (arrow) of the interface arc in the immediate vicinity of the receiver block means that this arc will not be displayed and will not be considered in the child diagram of this block. 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 first “plunge into the tunnel”, and then, if necessary, “return from the tunnel”.

The last of the IDEF0 concepts is glossary. For each of the IDEF0 elements: diagrams, function blocks, interface arcs, the existing standard implies the creation and maintenance of a set of corresponding definitions, keywords, narrative statements, etc., which 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 the control interface arc “payment order”, the glossary may contain a list of fields corresponding to the arc of the document, the required set of visas, etc. The glossary harmoniously complements the visual graphic language, providing the diagrams with the necessary additional information.

Figure 4. Decomposition of functional blocks.

Principles for 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 restrictions are adopted in the corresponding standard:

Limiting the number of function blocks in the diagram to three to six. The upper limit (six) forces the designer to use hierarchies when describing complex subjects, and the lower limit (three) ensures that the corresponding diagram has enough detail to justify its creation;
Limiting the number of interface arcs approaching 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.

The discipline of group work on the development of an IDEF0 model

The IDEF0 standard contains a set of procedures that allow the development and approval of a model by a large group of people belonging to different areas of activity of the system being modeled. Typically, the development process is iterative and consists of the following conditional steps:

Creation of a model by a group of specialists related to various areas of the enterprise. This group is called Authors in IDEF0 terms. Building the initial model is a dynamic process during which the authors ask 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 consideration, approvals 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. 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 with the criticism in writing or rejects it with a statement of the logic of the decision and again returns the corrected draft for further consideration. This cycle continues until authors and readers reach 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 readers have no 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 demonstrations 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 using IDEF0 tools

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

However, most managers still regard the practical application of modeling in IDEF standards more as a tribute to fashion than as 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 of survey and analysis of the financial and economic activities of enterprises in Russia are now one way or another connected with the construction of automated control systems. Due to this, the IDEF standards in the understanding of the majority have become conditionally inseparable from the introduction of information technology, although with their help it is sometimes possible to effectively solve even small local problems, literally with 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 an enterprise's activities in the right context. Most importantly, though, is the collaborative capability 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 in a fairly short time explained to them the basic principles of IDEF0 and taught them how 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 supposed to answer the following questions:

What enters the unit "at the entrance"?
What functions and in what sequence are performed within the unit?
Who is responsible for each function?
What guides the performer in the performance of each of the functions?
What is the result of the unit's work (output)?

After coordinating draft diagrams within each specific unit, they are assembled by a consultant into a draft enterprise model, in which all input and output elements are linked. At this stage, all the inconsistencies of individual diagrams and their controversial places are fixed. Further, this model again passes through the functional departments for further coordination and making the necessary adjustments. As a result, in a fairly short time and with the involvement of a minimum of human resources from the 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, importantly, 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 submitted for analysis and processing to business analysts who will search for “bottlenecks” in the company’s management and optimize the main processes, transforming the “As is” model into the corresponding “As it should be” representation. 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 imposition on some employees of additional responsibilities for the development and practical application of new methodologies. However, in the end, this justifies itself, since an additional one or two hours of work by individual employees over several days can significantly save money on paying for consulting services from a third-party company (which in any case will interrupt 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 from them in my practice.

The conclusion from all this can be drawn as follows: it is absolutely not 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 the spacecraft design system to the process of preparing a complex dinner), use proven and run-in methods over the years. One of these methods is IDEF0, which allows using its simple and understandable toolkit to solve complex life problems.