Coursework: Development of a model of a greenhouse enterprise using IDEF0, DFD and IDEF3 design methodologies. Creation of the IDEF0 model The IDEF0 methodology on the example of testing

Open the project where you want to create the model. If you have not created any project yet, you can use the DEMO project, which is available immediately after installing Cradle, or create your own project.

To enter the DEMO project use Username — MANAGER, password - MANAGER

How to create your project is shown in detail in this video

After creating a new project, you can also use to login Username — MANAGER and password - MANAGER

Model creation

To create an IDEF0 model, enable Project panel and go to simulation section Essential Domain

Note : Similarly, you can create models in the Implementation Domain modeling section, as well as in any section configured by the user. The modeling section is actually a namespace within which threads can be reused.

To create an IDEF0 context model, right-click on the IDEF0 section and select New->Element

Please note that this is the name of the whole model, not the function block on A0.

This opens the drawing area and you can start creating the context model.

Creating a function block

To do this, select the function block symbol on the palette

and click once on the work area where you want to create the function block.

A dialog box will appear in which you must enter the name of the function block, and then click OK.

As a result, a function block with the name you specified will be created.

You can select the border of a block and change its scale

Creating threads

To create flows, select the flow symbol from the palette (without tunneling or with tunneling)

then click on the side of the function block with which you want to create a flow and click on any area of ​​the function block

after that, a dialog box for entering the name of the stream will appear. Enter a short stream name and click OK

Note: You will be able to enter detailed description flow then in its specification.

After that, by analogy, you can create all the necessary flows

Save the model by pressing the floppy disk button or by pressing CTRL+S. When you save, symbol specifications will be created that you can edit to give a more detailed description of the model elements.

After saving the model, you will be able to see the created specifications in the project panel in the same section where you created the model. Two types of specifications will be created - Function and Flow.

Model decomposition

in the dialog that appears, leave the default settings and click OK

After that, a child diagram A1 will be created and all flows from diagram A0 will be transferred to it.

Now you can rename the created function block blank (with a question instead of a name) and create additional ones, in the same way as we created them earlier.

To rename a function block preset, select it and select Rename from the context menu

and enter the required name

By analogy, create other function blocks corresponding to this level of decomposition

To create flows between these functional blocks, you must first click on the source, then on the intermediate point to create a bend, and then on the destination, for example, like this:

As a result, you will get a flow with two bends.

You can adjust the position of the bends by selecting the flow and dragging the bend points to the desired location

Watch the video clip to see it in action

To remove (or add) a bend point, press the SHIFT key on your keyboard and click on the point you want to remove or where you want to create it in the flow

Save the diagram and make sure the appropriate specifications are created

By analogy, it is possible to decompose the functional blocks A1.

Known today not only in narrow circles, the abbreviation IDEF0 is the first methodology that standardizes work on business processes. It was developed in the middle of the last century as part of an aerospace project in the United States and, having shown its effectiveness, became a federal standard. In our country, in 2000, a document “ IDEF0 Functional Modeling Methodology. Guidance Document Functional Modeling Methodology IDEF0 Guidance Document. Official edition. State Standard of Russia RD IDEF0 - 2000. Developed by the Research Center for CALS - technologies "Applied Logistics". Adopted and put into effect by the Decree of the State Standard 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 suggest that you consider the IDEF0 model and evaluate the relevance of this approach at the present time.

Basic concepts and abbreviations

Let's deal a little with the names of the key elements of the methodology. The IDEF0 graphics 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 in a complex should have allowed to study the structure, parameters and characteristics of production, technical and organizational and economic systems.

IDEF0 is a functional model, which is the core of building all other structures, it links together informational and material flows, organizational structure, control actions and the very activities of the company. A graphical standard for process modeling is also commonly referred to as a notation. That is, notation is a system of requirements and rules for building an activity model in one form or another. Therefore, IDEF0 is appropriate to call the notation that is part of the SADT methodology.

The IDEF0 notation is a fairly rigorous technique that was originally developed, like engineering 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 a lot of schemes, and unambiguous systematization and navigation through all elements of the model is necessary. Now they do it mostly computer systems, supporting modeling in this notation. AllFusion Process Modeler and Business Studio systems are the most famous and available on the territory of Russia today. I plan to devote separate articles to the review of these systems.

Function block

The central element of the IDEF0 model is the function , which is displayed in the diagram as function 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 dishes" and "Drawing on the product."

Required Function Block Elements in IDEF0

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

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

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

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

1. Inputs are resources that transfer their value to outputs completely, that is, they are completely spent on creating the result, and mechanisms are resources that transfer their value only partially (equipment through depreciation, and people through wages).
2. Management is a necessary element of the model, as 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 a function. Often this stream is treated formally, but at the same time the scheme loses its rigor, and sometimes even its meaning.
3. Each function 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 the "brick" of the IDEF0 approach. Functional modeling involves a gradual transition from the general to the particular through decomposition. Decomposition is a “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 way and then decomposed, it is appropriate to call it a process.

Context diagram

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

1. The goal is a specific formulation of the purpose of the model, according to which the accuracy of building the model can be verified in the future.
2. Point of view - from whose face the model is built, since the model is always dependent on its author and the focus of attention. If we are building general model enterprise, it is usually presented from the point of view of its director.
3. The model type is an indication of what information is displayed on the diagrams. There can be 2 fundamental options here: AS IS (“as is”) or TO BE (“as will be”). This separation is necessary because we can build models for both the analysis of activity and its transformation. We must be clear about what we are doing and communicate this information to others.

Thus, the context diagram contains in the most generalized form a description of the company's activities, which are permeated by the flows that connect the company with the outside world. I think they should also be a little more detailed.

Main streams

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

1. Material: materials and components at the input and finished products at the exit.
2. Client: a potential client at the entrance and a satisfied one at the exit.
3. Financial: at the input it is usually investments, customer payments (revenue), loans and other income; the output is payments to suppliers, taxes, payments on loans and profits.
4. Informational: at the input, these are all flows of information about external environment(market conditions, competitor behavior, technological innovations, etc.), and the output is the flow of information that the company reports about itself to the world (all advertising information, as well as all types of reporting to regulatory authorities).

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

(click to enlarge)

It's good if you highlight each of these types of flows with a different color so that you can easily distinguish the movement of resources and not miss important points. For example, it is often possible to observe the absence of a client in the company's flows, therefore, work with him is based on a residual principle - the client often feels like a hindrance to 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 - informational, which can be divided into 2 subtypes. 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 (divisions and people). There can be no documents here, just as there can be no people on the control arrows!

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

Decomposition

After working out the flows of the context diagram, we can move on to decomposition. Going one level lower, as if opening a "black box", we first see Blank sheet with arrows that have been attached to the function block.

(click to enlarge)

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

It is not always easy to arrange a complex activity in such a way that it remains 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.

1. Creation of a product (result).
2. Promotion and sale - work with a client flow.
3. Ensuring product development activities are secondary processes that are necessary for compliance state requirements or convenience of work (personnel and accounting, transport services, cleaning of premises, etc.).
4. Creation of control flows - development activities management decisions, which 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 located diagonally - this is called principle of dominance, which implies the arrangement of functional blocks from left to right and from top to bottom - in order of importance or in chronological order. The block numbering is the same.

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

Conclusions about the relevance of the notation

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

1. The model has a good visualization potential, but, in my opinion, its greater value is in the disciplinary effect. The rules and restrictions laid down in the methodology make it necessary to develop a systematic and strict attitude to the models, which has a very good effect on the quality of the final result.
2. The model allows you to build communication flows between externally not strongly related things: to connect the subsystems of the front and back offices with management, which is much worse for other notations.
3. The approach is simple and understandable for most project participants. Building and reading diagrams in this notation is limited only by the desire to delve into the intricacies of business flows.

Some of the above arguments lead one to think that this approach is the best and only one for complete activity modeling. But we must not forget that the functional model is designed only for the upper level of modeling. Using the IDEF0 notation for designing work at the level of performers leads to the fact that the schemes are purely illustrative and it is impossible to build an explanatory regulation on their basis, since they do not contain:

• specifying the start and stop events of the process;
• conditions for the transition from one action to another;
• the ability to visually display all resources and performers without overloading the scheme with arrows.

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

In project management, this modeling standard is most applicable where you need to link different projects or processes in visual flows. At the same time, the graphical model will allow for a more rational distribution of responsibility and resources among tasks. The logic of the project tasks, reflected in the diagrams, will help to prepare a better calendar plan in the form of a Gantt chart.

Learn to see and understand functional structure 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 leaders can still be baffled by the direct question of organizational structure 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 count the costs - the profit was gigantic. As a result of this, over the past two years we have seen a quite understandable picture: large companies, which grew up in the early 90s, are gradually losing their positions, 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. Through simulation various areas activities, it is possible to effectively analyze the “bottlenecks” in management and optimize the overall business scheme. But, as you know, in any enterprise, only those projects that directly generate 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 competitive and the profitability of enterprises began to plummet, 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 involve 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 - modeling methodology information flows within the system, allowing 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 ontology of a system 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 automation program industrial enterprises, which bore the designation ICAM (Integrated Computer Aided Manufacturing) and was proposed by the US Department of the Air Force. The IDEF family of standards itself has inherited its designation from the name of this program (IDEF=ICAM DEFinition). In the process practical implementation, participants in the ICAM program were faced with 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, new method was supposed to ensure 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 the last revision was issued 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 of an 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 of an 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 three remaining.

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.). At the same time, 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 partitioning complex process to its component 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 hierarchical structure individual diagrams, making it less cluttered and easier to digest.

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 short description and fixed point of view (Viewpoint).

Definition and formalization of the IDEF0 development goal - models is 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 in the future on the basis of this model information system, 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 points 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. Right choice 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 “Process on lathe” does not make sense to reflect on the charts more than high 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 of 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 the Glossary. For each of the elements of IDEF0: diagrams, function blocks, interface arcs, the existing standard implies the creation and maintenance of a set of appropriate 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 you to develop and agree on a model big group people belonging to different areas of activity of the modeled system. 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 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 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://www.vernikov.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. This is most likely due to a pronounced lack of information on practical application of these methodologies and with an indispensable software bias of the vast majority of publications.

It is no secret that almost all survey and analysis projects of financial and economic activity enterprises in Russia are now one way or another connected with the construction automated systems management. Due to this, the IDEF standards in the understanding of the majority have become conditionally inseparable from the implementation information technologies, 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 practical activities there were quite a few cases when the model was built 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 transferred for analysis and processing to business analysts who will search for “bottlenecks” in the management of the company 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 it justifies itself, since an additional one or two hours of work individual employees within a few days, they can significantly save money on paying for consulting services of a third-party company (which in any case will interrupt the same employees from work 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 design system spaceship, before the process of preparing a complex dinner) - use methods that have been tried and tested for years. One of these methods is IDEF0, which allows using its simple and understandable toolkit to solve complex life problems.

One picture is worth a thousand words

folk wisdom

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 the organization of the warehouse or the IT system (from lead to request). But in reality, it almost never turns out to be, and therefore, in the process of studying and searching for a solution to the task set by the client, I also create a functional model of the company or a certain process (function) on my own.

A few words about the benefits of graphics

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

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

That is why Sytin's idea was truly revolutionary - he began to print lithographic copies of maps with the designation of 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 print run of the "Help" 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 also cite a similar example of the helplessness of verbal descriptions from my own practice. One of my clients asked me to take on the implementation of an ERM system for his company. When I asked if they had some kind of technical task, I received the answer: “Yes, they do. But it has 400 pages.” At the same time, the client complained very much that my colleagues, whom he contacted earlier, either refused the project altogether, or called clearly inflated prices. After I saw that the terms of reference were indeed 400 pages long and consisted solely of a textual description, I understood the reasons for the developers' behavior. Reading such a volume of text, delving into it, understanding all the nuances just to understand the task and name the price is really very difficult.

I offered this client 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 terms of reference.

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

Why is this important to my work

My work 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 already exists. And it doesn't matter what exactly we do - we set up or install a CRM system from scratch, we create an effective ERP system, we integrate various systems to increase the automation of work in general. In any case, to begin with, it is necessary to get an idea of ​​the existing scheme of work, and only after that it is possible to propose some changes and think over options for solving the task.

After studying the status quo, I, like any other third-party specialist, create offer, in which I reveal in as much detail as possible my vision of the current situation, as well as the actions that need to be taken to solve the task, and, of course, the expected result.

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

In fact, it is important not to provide volume, but to convey the essence as quickly and fully as possible. Large volumes of text require time, which businessmen often have very little. And the graphics allow me to reduce the volume of my proposal and clearly, in an understandable form, show the solution. As a result, my proposals were significantly reduced, graphics appeared in them, and decisions on the beginning of cooperation began to be made faster.

It is for this reason that I use visual models. As you know, one picture is worth a thousand words. And in the case of describing business processes and options for modernizing the work of a business, this is true. And IDEF0 notations are very well suited here.

But first, let's understand the basic concepts of what notations are, why they are needed, what IDEF0 is, what are the features and advantages of this method.

What is business process description notation

A notation is a format for describing a business process, which is a set of graphic objects used in modeling, as well as modeling rules.

In fact, notations are a special graphic language that allows you to describe the work of a company, visually demonstrate the interaction between different departments, i.e. describe business processes. Notations can be used for process or functional modeling.

In general, notations can be called a programming language in business analysis.

What is IDEF0?

IDEF0 is a functional modeling methodology and graphical notation designed to formalize and describe business processes. Distinctive feature IDEF0 is its emphasis on the subordination of objects. IDEF0 considers the logical relationships between jobs, not their temporal sequence (workflow). Wikipedia

The IDEF0 standard was developed in 1981 by the US Department of the Air Force for industrial automation. On development stage software developers are faced with the need to develop new methods for analyzing business processes. As a result, the IDEF0 functional modeling methodology appeared, in which special IDEF0 notations are used for analysis.

Functional model of the company

The IDEF0 functional model is a set of blocks, each of which is a "black box" with inputs and outputs, controls and mechanisms that are detailed (decomposed) to the required level. The most important function is located in the upper left corner. And the functions are connected with each other with the help of arrows and descriptions of functional blocks. Moreover, each type of arrow or activity has its own meaning. This model allows you to describe all the main types of processes, both administrative and organizational.

Arrows can be:

• Inbox - introductory, which set a specific task.
• Outgoing - displaying the result of the activity.
• Managers (from top to bottom) - control mechanisms (positions, instructions, etc.).
• Mechanisms (from bottom to top) - what is used in order to produce the necessary work.

It would be more accurate to call incoming and outgoing arrows input and output, since in English they are called Input and Output, respectively. But the features of the translation and the usual names already look the way they have. And yet, for a correct understanding of the terms, it is important to remember their meaning in this case. This is also confirmed by the fact that this notation was created primarily for software development, and it is more correct to translate the terms in this point of view.

Arrows are signed using nouns (experience, plan, rules), and blocks are signed using verbs, i.e. they describe the actions that are performed (create a product, conclude a contract, make a shipment).

IDEF0 is a very simple and at the same time visual language for describing business processes. With the help of this standard, the transfer of information between developers, consultants and users is possible. The standard was developed very carefully, it is convenient for design, universal. There are many tools to work with it, for example, VISIO, BPWIN, ERWIN, Bussines studio, etc.

In addition, using IDEF0 to create business models is not only convenient, it is also right. This tool was designed for business intelligence, it has undergone a long and thorough debugging and polishing. Therefore, using IDEF0 to create a functional model without errors is much easier than without using this standard.

As you know, it is best to hammer nails with a hammer. Of course, you can use other tools for this, but a hammer is the most functional and it is easiest to hammer a nail neatly and accurately with it. So with the use of IDEF0 - this tool was created for functional modeling, and with its help you can get the desired result much faster and more accurately.

An example of creating an IDEF0 functional model

In order to understand how to work with functional modeling, I will give an example of the process of writing an article.

The main block is “Write an article”.

Incoming arrows - "Experience", "Information from third-party sources". These are the inputs you need to get started.

The guides for writing an article are the “Publication Plan”, “Publisher Requirements”, “Rules of the Russian Language”.

And in the role of "Mechanisms" are the author, copywriter, proofreader and software. In this case, the author creates an audio material in which he collects all the thoughts and ideas that should be reflected in the article. A copywriter is a person who creates, on the basis of this material, guided by the requirements of the publisher, the publication plan and the rules of the Russian language, the finished text of the article. The proofreader checks the material for errors. And software is the tools that all participants in the process use in their work.

Thus, I set the main parameters of the process, its input, output, as well as everything necessary for successful process. But this is only the basic framework of the process. This describes the general scheme of the company as a whole.

In fact, the process of creating an article, like any business process, can and should be detailed. To do this, I decompose the general “write an article” block into interconnected elements.

In our case, the work is divided into 4 main stages:

1. Prepare audio.
2. Prepare text
3. Prepare text for publication.
4. Place an article in a publication.

The diagram clearly shows at what stage which control elements and which mechanisms are involved.

So, when creating audio, the author uses his knowledge and experience, while being guided by the publication plan and the requirements of the publisher. The copywriter receives an audio recording as input, from which, guided by the rules of the Russian language, he creates a text. The proofreader receives the text and checks it, also guided by the rules of the Russian language. To place an article in a publication, special software is required.

When creating a functional model key parameters are purpose and point of view. Based on them, modeling of the same processes may look somewhat different. For example, in my case, the goal is "to talk about the process of writing an article." And the copywriter's point of view is "writing and publishing an article from the point of view of the process manager."

So, if the same process were described from the point of view of a copywriter, then the input would be an experience and an audio file from the author. Moreover, in this case, Experience would mean the experience of a copywriter, but not a leader or author. Therefore, the first thing to determine when creating a business process model is to choose a point of view and clearly articulate the goal.

Such modeling is not only visual, but also very convenient for making effective management decisions. For example, in the business process described above, there are two separate specialists - a copywriter and a proofreader. If I set the task of optimizing project financing, then thanks to the scheme, I will immediately see where it is and how it can be done. So, a copywriter and a proofreader use approximately the same rules, but the copywriter receives audio and gives the result in the form of text, while the proofreader both accepts and gives text. And therefore, if necessary, I can, say, for half the cost of the duties of a proofreader, offer a copywriter. So I will save money and time on the interaction of different specialists. Of course, I understand all the merits of proofreaders and why it is better to work with individual specialists. But I remind you that I have a task: cost optimization.

Without such a visual tool, it would be more difficult to determine which of the blocks can be removed and thus optimize the work.

How to create IDEF0 notations

There are many different software products that can be used to create notations. Some are designed specifically for functional modeling, others are designed for any work with graphic elements. Where and how you build these models is up to you.

I personally think that at the first stage there is nothing better than regular paper, a simple pencil and an eraser to make adjustments in case of mistakes.

In order to create a notation for existing business processes, i.e. to describe how the company works now, it is necessary to study the principles of work. A third-party specialist (consultant, developer) conducts an interview for this. At the first stage, the head of the company answers the questions, then, in the process of detailing the notation, interviews are conducted with employees responsible for various stages of work.

It is important to understand that as a result, 2 notations will be required. The first will display business processes as they are. You create it on the basis of an interview and coordinate every detail with the company's employees and the manager. It is very important that your vision of existing processes coincides with reality, and this is what requires confirmation at all levels.

The second notation is “as it should be”. It is created on the basis of the first and those changes that you propose to make to the structure of work to optimize and automate the work of the company as part of the task.

IDEF0 requirements

The basic requirements of the IDEF0 standard, in principle, I described above and showed with an example.

1. In the upper left corner is always the main element.
2. All elements must have incoming and outgoing arrows, since for execution it is necessary to receive something at the input (order, task), and after processing at the output, it is necessary to transfer the finished product. Incoming arrows are always on the left, outgoing arrows are always on the right.
3. Above are the control elements, below are the mechanisms necessary to complete the process.
4. If there are several blocks on one sheet (screen), each subsequent block is located to the right and below the previous one.
5. It is necessary to strive to create schemes in such a way that the intersection of the arrows is reduced to the necessary minimum.

Common Mistakes

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

Use of 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 a disruption of the process and a manufacturing defect.

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

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

Too many blocks

When compiling 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. Readability is lost.

The best option is detailing sufficient to understand the issue, and nothing more. Detailed details 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.

Violation of the structure when making adjustments

Watch carefully to avoid confusion or processes without incoming, outgoing and other important elements. For example, if in the above example, I see fit to shift the point of view to the copywriter, I will remove the author from the schema. And then the controls "experience of the author and third-party sources", as well as the publication plan become unnecessary. After all, the author uses them. The copywriter works with the audio file. And if they remain in the general scheme, then when detailing, they will lead incomprehensibly where and introduce confusion.

Likewise, if I decide to add a block, it's important to make sure that it also has all the required attributes. Carefulness is very important here, because 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 accepted in the IDEF0 standard, and this approach helps to avoid confusion and errors.

Most often, mistakes are made when naming blocks. For example, instead of "Create an article" they write "Create an 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 is visibility. You yourself begin to understand how this or that system works, and you can also clearly explain where there are “thin spots” in this system and how your solutions will help get rid of them.
• Mutual understanding and lack of disagreement. When discussing the work of the company using the functional model, you have visual and intuitive task blocks with controls. In addition, functional modeling involves the creation, if necessary, of a glossary in which symbols and terms are revealed. As a result, you and your client, manager, and other employees speak the same language when discussing a problem.
• Simplicity and high speed model creation. Of course, learning to model is not as easy as it seems. After all, a scheme is, in fact, a super-dense presentation of information, which is very good for understanding, but a special approach is required to implement such a presentation. The analyst's brain acts in this case as a very powerful press on the one hand, and a filter on the other. But with experience, this process becomes very fast. As a result, you get a tool that will help you figure out what is happening in a particular system yourself, and with the help of the created in short time visual aids to illustrate important points to colleagues or customers.
• Discipline and no mistakes. The IDEF0 standard assumes strict frameworks and rules. This approach disciplines, and the habit of acting within the framework of the standard helps to avoid mistakes due to inattention. Any violation of the standard becomes immediately noticeable.

What is the difficulty of using IDEF0

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

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

Therefore, it is very important to constantly consult with the head of the company when compiling a functional business model “as is”, so as not to make mistakes that will automatically entail errors at the stages of decomposition. Also, at subsequent stages, additional approvals from managers may be required. structural divisions and employees. Only if your functional model "as is" will really reflect the real state of affairs, you can make some changes and suggestions. And to achieve quality results such work requires, first of all, practical experience and knowledge of the features of a particular type of business.

Gennady Vernikov

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 count the costs - the profit was gigantic. As a result, over the past two years we have seen a quite 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 generate 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 competitive and the profitability of enterprises began to plummet, 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 "modeling business processes" 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 involve 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) - a methodology for building relational structures. IDEF1X belongs to the Entity-Relationship (ER) type of methodology and is typically used to model relational databases relevant to the system in question;

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 static IDEF0 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 ontology of a system 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 the last revision was issued 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 of an 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 value "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 of an 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 side the given 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 follow 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 the incoming interface arcs from the control ones, which is often not easy. For example, Figure 2 shows the "Process workpiece" function 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.). At the same time, 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 starts with a view of the system as a whole - a single functional block 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 the point of view (Viewpoint) should be fixed.

The definition and formalization of 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 - 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 of tunneling. The designation "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 the 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://www.vernikov.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. Thanks 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 transferred for analysis and processing to business analysts who will search for "bottlenecks" in the management of the company 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.