Plotting idef3 (and idef0) diagrams - which program to do? Description of the IDEF0 standard Image in idef0 choice of alternative solutions

Workshop on Using IDEF0 to Functionally Describe CAD Software

Workshop on Using IDEF0 for Functional Description of Software
Part 1.

If you analyze the ads for the hiring of employees of firms engaged in software development, then there has recently been an acute shortage of project managers who can competently carry out the setting of tasks. The problem is not that they cannot formulate the task, but that they cannot correctly draw up the documentation taking into account modern design standards. For the customer alreadyit is not enough to give a few leaves typed in Word. He wants documentation formatted in BPWin, ErWin, S-Designer, Power Designer, Rational Rose, etc. There is a standard behind each of these CASE tools. This article is dedicated to one of them - IDEF0.

Introduction. When drawing up the documentation, each project manager considers it an honor to come up with something "of his own" - his own "super format" for presenting his ideas. The complexity of projects is growing, the volume of documentation for the project is growing, the documentation goes beyond the working group ... and then it becomes clear that the documentation does not suit the customer or the group of developers who are finalizing the project and supporting it.

Usually, the project manager is either a class programmer (the lead programmer of the topic - the project), or a person who is fluent in a foreign language and is familiar with programming. These are the main selection criteria for the project manager position. This is the root of the problem. You can be a cool programmer or just a good employee, but this has nothing to do with the design of the documentation.

Typically, the specification for each type of manager slides down either to the description of the model of the program itself (the architecture of modules, classes, DLLs, the structure of the database and its use, etc.) or to the description of user-defined functions (what they should do, what forms should be in program, etc.).

Ideal when the client sets the task. In this case, you can live according to the principle "the customer wants", and as long as he is satisfied, you get money from the customer. But more and more projects are created in the depths of an organization, and then they are offered to the customer. And in this case, the quality of the documentation, what you have done and what you intend to do, comes to the fore. The documentation decides everything in this case ...

The IDEF0 (Integrated Definition Function Modeling) standard is intended for functional modeling and is adopted as a federal standard in the United States. The IDEF0 standard is one of a group of standards widely used to describe any business process. Its use for describing software projects is a very young direction, but the use of IDEF0 guarantees that your partners will take you seriously ...

The use of IDEF group standards (IDEF0, IDEF1, etc.) is the actual condition for obtaining the status of an organization that meets ISO9000, ISO9001. These standards for an organization are an opportunity to increase sales of products, an opportunity to prove that it is "on the crest of a wave."

Many programmers use CASE ErWin extensively without knowing that it is based on the IDEF1 standard. It's not just something that you like or like your customers. This is the standard - and that says it all.

Brief basic concepts of the IDEF0 standard. The IDEF0 standard is based on the concept of a function. A function is a controlled action on an input that results in an output, using some mechanism through which this action is carried out.

The IDEF0 standard is based on three basic principles:

1.the principle of functional decomposition - any function can be decomposed (detailed, broken down) into simpler functions;

2. the principle of limiting complexity - the number of blocks on the diagram should be 2 ... 6 (readability condition);

3. the principle of context - modeling a business process begins with building a context diagram, which displays only one block - the main function of the modeling system, which limits the area of the boundary of the modeling system (regulates the initial stage of building a model).

IDEF0 diagrams are built using blocks. Each block describes a complete action (function).

The four sides of the block have different purposes. The input data is displayed on the left, the output data is on the right, the control is on the top, and the mechanism is on the bottom.

Input data - initial resources for the function described by the block (initial information, materials).

Output data - the resulting resources obtained as a result of the execution of the function described by the block (output information, processed source materials).

Control is what affects the process of performing the function described by the block and allows you to influence the result of performing an action (controls, sensors, people).

A mechanism is what a given action is carried out (machines, devices, human resources, software).

The interaction between the blocks is displayed as arcs (arrows). Sometimes the sides of a block are called directions and the arrows are called flows. Arrows can be signed. Signatures are associated with the corresponding arrow using a zigzag (lightning).

A general view of the implementation of the IDEF0-diagram block is shown in Fig. 1.

Fig. 1. Implementation of the block used in IDEF0 diagrams.

When decomposing (detailing) a function, a newly generated diagram displays all incoming and outgoing arrows (arcs, flows) associated with the function being split. The number of arrows at any level of the diagram and in any direction is not limited. The diagram is called the block (function) being split. Only the name of the context diagram (DK) coincides with the name of the function contained in the diagram.

In their essence, diagrams form a tree. Any diagram acts as a DC in relation to the underlying ones.

As an example, consider some abstract function. This function has input data, two heterogeneous types of output data, is controlled by an external influence and is implemented by mechanisms A and B. An example of the main context diagram is shown in Fig. 2, and a detailed (decomposed) version of this function, consisting of two functions (more elementary actions ) is shown in Fig. 3. In turn, functions 1 and 2 can also be detailed (decomposed).

Fig. 2. An example of a basic diagram.

Fig. 3. An example of decomposition of the main function.

The diagram is located on a special form, which contains the name of the function, its graphic image, the designation of the diagram with a nesting level, links with other functions, special information about the author, organization and the described project.

Connections. Arrows or arcs show the relationships between blocks. Arrows usually sign. Arrow signatures are selected as nouns. For convenience, the arrows are connected to the signatures with lightning. For readability of the IDEF0 diagram, it is recommended to place labels either above the arrow or to the right of the arrow.

Typically, wire routing begins with data. Input data is the data required to execute a function. With this direction, questions rarely arise. Output data is data that is the result of executing a function. The simplest situation is when the output is input to another block. Is this always the case? If a function, processing input information, forms a control command, this is control. The situation is approximately the same when the function forms the data format. A data format is a mechanism for conveying information.

The main types of links between blocks in the diagram, formed on the basis of the output information, are shown in Fig. 1.

Fig. 4. Types of links between blocks in the diagram. Accordingly, a) data communication, b) control communication, c) mechanism communication, d) feedback.

Feedback is a link that forms a ring between blocks of data, control, or format. An example of such a connection is shown in Fig. 2.d. When this relationship appears, check to see if your diagram boils down to a flowchart. The presence of such a connection is not a sign of error.

Block priority and numbering. All blocks have priority. The priority of the blocks depends on the sequence of their execution. The blocks on the left and top have the highest priority. The dominant position is horizontal.

Block numbering (block index in the diagram) in the diagram is determined based on priority. Numbering starts from one. The chart code consists of the letter "A" and a number. DC has code A-0. The letter "A" means active action (from the English. Active). The diagram, which is a decomposed version of the DC, will have the A0 code. Each item in diagram A0 will be coded from A1 to A6 according to priority. In turn, when one of the blocks A1 ... A6 is decomposed, the codes of the blocks of the newly decomposed diagram will consist of the code of the decomposed diagram plus the index of the selected block. Chart block codes do not repeat throughout the entire chart.

By the number of digits in the code of the diagram, you can determine the level of the diagram - the level of decomposition of the DC. It is customary to consider DC as the main level, and all the others are from the first decomposition level and above.

Types of sequence of actions. Data can be processed sequentially or in parallel.

An example of sequential processing is filling the address book (after all, you cannot write two addresses into it at the same time). Each block always processes only one copy of the data, sequentially changing after each processing. Blocks are located either sequentially horizontally, or obliquely from the upper left corner to the lower right.

An example of parallel processing - you can watch TV and eat an apple at the same time. In this case, two actions are performed simultaneously. These actions are not related to each other. Such blocks are stacked vertically on top of each other in the diagram.

Often there is a group of actions (blocks) on the diagram, of which only one is executed, depending on some condition. Such actions are called alternative actions. The condition should be applied to such blocks as a control action (choice of action). It is recommended to introduce a special block into the diagram that processes the conditions for choosing an alternative action (block). This block generates separate selectable commands for each block.

The role of humans in IDEF0 diagrams. Is he a control or a mechanism? You decide what functions the person performs in the described task. If the action contained in the block is controlled by a person, then control. If an action is performed by a person, then a mechanism. It all depends on the degree of abstraction of the presentation of your task.

There are cases when a person (including the same person) will act as a mechanism and control for one block. THAT HAPPENS. Example, a person writes a letter. It is written by this person, and the same person controls the content of this letter.

Control data. Management is a team. If a command contains an informative part (names, conditions, deadlines, etc.), then the informative part of the command is input data.

The simplest solution is to split the original arrow into two: control and data. These arrows lead to the corresponding sides of the block. Both separated arrows should be labeled accordingly.

Sergey Sokolov (Minsk, BSUIR)
E-Mail:

Gennady Vernikov

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

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

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

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

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

IDEF1X (IDEF1 Extended) is a methodology for building relational structures. IDEF1X is a type of Entity-Relationship (ER) methodology and is typically used to model relational databases relevant to the system in question;

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

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

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

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

The history of the IDEF0 standard

The IDEF0 methodology can be considered the next stage in the development of the well-known graphical language for describing functional systems SADT (Structured Analysis and Design Teqnique). Several years ago, a small edition of the book of the same name was published in Russia, which was devoted to 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 called ICAM (Integrated Computer Aided Manufacturing) and was proposed by the US Air Force. The IDEF family of standards itself inherited its designation from the name of this program (IDEF = 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 framework of 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 of a limiting nature, and its last revision was released in December 1993 by the US National Institute for Standards and Technology (NIST).

Basic elements and concepts of IDEF0

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

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

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

The top side is Control;

The left side is set to Input;

The right side is set to Output;

The bottom side is set to Mechanism.

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

Figure 1. Functional block.

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

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

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

Depending on which of the sides this interface arc fits to, it is called "inbound", "outbound" or "control". In addition, only functional blocks can be the "source" (beginning) and "sink" (end) of each functional arc, while the "source" can only be the output side of the block, and the "sink" can be any of the three remaining ones.

It should be noted that any functional block, according to the requirements of the standard, must have at least one control interface arc and one outgoing one. This is understandable - each process must follow some rules (displayed by the control arc) and must produce some result (outgoing arc), otherwise it makes no sense to consider it.

When 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 function block "Process workpiece".

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

Figure 2.

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

Figure 3.

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

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

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

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

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

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

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

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

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

There are often cases when individual interface arcs do not make sense to continue to be considered in child diagrams below a certain level in the hierarchy, or vice versa - individual arcs have no practical meaning above a certain level. For example, it makes no sense to reflect an interface arc representing a "detail" at the input to the "Turn on a lathe" function block on diagrams of higher levels - this will only overload the diagrams and make them difficult to understand. On the other hand, there is a need to get rid of individual "conceptual" interface arcs and not detail them deeper than a certain level. To solve such problems, the IDEF0 standard provides for the concept of tunneling. The "Arrow Tunnel" notation in the form of two parentheses around the beginning of the interface arc denotes that this arc was not inherited from the functional parent block and appeared (from the "tunnel") only in this diagram. In turn, the same designation around the end (arrow) of the interface arc in the immediate vicinity of the receiver block means the fact that this arc is 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 final concept in IDEF0 is the Glossary. For each of the IDEF0 elements: diagrams, functional blocks, interface arcs, the existing standard implies the creation and maintenance of a set of relevant definitions, keywords, narratives, etc. that characterize the object displayed by this element. This set is called a glossary and is a description of the essence of this element. For example, for the "payment order" control interface arc, the glossary may contain a list of fields of the document corresponding to the arc, the required set of visas, etc. The glossary harmoniously complements the graphical language, providing the diagrams with the necessary additional information.

Figure 4. Decomposition of functional blocks.

The principles of limiting the complexity of IDEF0 diagrams

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

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

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

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

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

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

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

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

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

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

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

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

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

What goes to the unit "at the entrance"?

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

Who is responsible for each of the functions?

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

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

After agreeing on draft diagrams within each specific department, they are assembled by the consultant into a draft enterprise model, in which all input and output elements are linked. At this stage, all discrepancies of individual diagrams and their controversial places are recorded. Further, this model again passes through the functional departments for further agreement and making the necessary adjustments. As a result, in a fairly short time and with the involvement of a minimum of human resources from a consulting company (and these resources, as you know, are very expensive), an IDEF0-model of an enterprise is obtained according to the "As is" principle, and, more 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 company management and optimize the main processes, transforming the "As is" model into the corresponding "As should be" view. Based on these changes, a final conclusion is made, which contains recommendations for reorganizing the management system.

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

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

Known today not only in narrow circles, the abbreviation IDEF0 is the first methodology to standardize work on business processes. It was developed in the middle of the last century as part of an aerospace project in the United States and, having shown its effectiveness, has become a federal standard. In our country in 2000, a document was prepared " Functional Modeling Methodology IDEF0. Guidance document Functional Modeling Methodology IDEF0 Guidance Document. Official edition. Gosstandart of Russia RD IDEF0 - 2000. Developed by the Research Center CALS - Technologies "Applied Logistics". Adopted and put into effect by the Decree of the Gosstandart of Russia 2000, Moscow”, But as a standard it was never approved. Although this did not prevent this methodology from becoming one of the most popular tools for graphical modeling of business processes in our country. In this article, I invite you to review the IDEF0 model and assess the current relevance of this approach.

Basic concepts and abbreviations

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

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

IDEF0 notation is a fairly rigorous technique that was originally developed, like technical design standards, for manual modeling. Therefore, it contains requirements for the placement of arrows, the format of all elements, the content of the information frame for the IDEF0 diagram, etc. Since the company's activities are a complex multi-level system of actions, there are always many schemes, and an unambiguous systematization and navigation through all elements of the model is required. Now this is done mainly by computer systems that support modeling in this notation. On the territory of Russia, the most famous and available today are the AllFusion Process Modeler and Business Studio systems. I plan to devote separate articles to the review of these systems.

Functional block

The central element of the IDEF0 model is the function, which is displayed on the diagram as functional block- a rectangle, inside which the action is indicated in the form of a verbal noun. The action can be very different in scale - from the activities of the company in general and to specific manipulation in particular. Examples: "Production and sale of ceramic tableware" and "Drawing on a product".

Mandatory function block elements in IDEF0

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

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

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

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

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

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

Context diagram

At the very top level, the company is presented as a "black box" in which some activity takes place, transferring entrances to exits. This level is usually called "", that is, a diagram describing the context of the company's activities. Additionally, the context diagram displays the key characteristics of the entire model.

The goal is a specific formulation of the purpose of the model, by which the accuracy of the model construction can be checked in the future.
Point of view - on whose face the model is built, since the model is always dependent on its author and focus of attention. If we build a general model of the enterprise, then it is usually presented from the point of view of its director.
The model type is an indication of what information is displayed on the diagrams. There can be 2 principal options: AS IS ("as is") or TO BE ("as will be"). This separation is necessary, since we can build models for both the analysis of activity and its transformation. We must be clearly aware of what we are doing, and also convey this information to others.

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

Main streams

Experience has shown that, despite the seeming simplicity and formality of this level, it is often necessary to stay at it for a long time, since all the results that are significant for the owner and the market should be reflected here. A mistake can lead to the creation of models that do not fulfill the tasks set for the business. To verify that significant flows are reflected, make sure that all 4 main flow types are present in your diagram.

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

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

(click to enlarge)

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

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

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

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

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

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

Decomposition

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

(click to enlarge)

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

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

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

The figure below shows the decomposition diagram of our example.

(click to enlarge)

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

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

Conclusions about the relevance of the notation

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

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

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

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

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

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

Purpose of work:

studying the basic principles of the IDEF0 methodology,
creating a new project in BPWin,
formation of a context diagram,
making connections.

Describing a system using IDEF0 is called a functional model. The functional model is intended to describe existing business processes in which both natural and graphical languages are used. To convey information about a specific system, the source of the graphical language is the IDEF0 methodology itself.

IDEF0 methodology prescribes the construction of a hierarchical system of diagrams - single descriptions of system fragments. First, the system as a whole and its interaction with the outside world are described (context diagram), after which functional decomposition is carried out - the system is divided into subsystems and each subsystem is described separately (decomposition diagrams). Then each subsystem is broken down into smaller ones, and so on until the desired level of detail is achieved.

Each IDEF0-charts a contains blocks and arcs. The blocks represent the functions of the simulated system. Arcs link blocks together and represent the interactions and relationships between them.

Functional blocks (work) in diagrams are represented by rectangles representing named processes, functions, or tasks that occur over time and have recognizable results. The name of the job must be expressed by a verbal noun denoting an action.

IDEF0 requires a diagram to have at least three and no more than six blocks. These constraints maintain the complexity of diagrams and models at a level that is readable, understandable, and usable.

Each side of the block has a specific, well-defined purpose. The left side of the block is for inputs, the top is for control, the right is for outputs, and the bottom is for mechanisms. This designation reflects certain system principles: inputs are converted into outputs, control limits or prescribes the conditions for performing conversions, mechanisms show what and how a function performs.

Blocks in IDEF0 are arranged in order of importance, as the author of the diagram understands it. This relative order is called dominance. Dominance is understood as the influence that one block has on other blocks in the diagram. For example, the most dominant block of a diagram can be either the first of a required sequence of functions, or a planning or control function that affects all others.

The most dominant block is usually located in the upper left corner of the chart, and the least dominant in the right corner.

The arrangement of blocks on the page reflects the author's definition of dominance. Thus, the topology of the diagram shows which features have the greatest impact on the others. To emphasize this, the analyst can renumber the blocks according to their dominance order. Dominance order can be indicated by a number placed in the lower right corner of each rectangle: 1 will indicate the most dominance, 2 will indicate the next, etc.

The interaction of works with the outside world and among themselves is described in the form of arrows, depicted by single lines with arrows at the ends. The arrows represent some kind of information and are named with nouns.

Arrow types

IDEF0 distinguishes between five types of arrows.

entrance- objects used and transformed by work to obtain a result (output). It is assumed that the work may not have any entry arrows. The entry arrow is drawn as entering the left side of the work.

Control-. information governing the activities of the job. Typically, the control arrows carry information that indicates that the job is to be done. Each job must have at least one control arrow, which is depicted as entering the top face of the job.

Output- the objects to which the inputs are converted. Each job must have at least one exit arrow, which is drawn as coming from the right edge of the job.

Mechanism- the resources that do the work. The arrow of the mechanism is drawn as entering the lower edge of the work. At the analyst's discretion, mechanism arrows may not appear on the model.

Call- a special arrow pointing to a different model of work. The call arrow is drawn as coming from the bottom of the work and is used to indicate that some work is being done outside the simulated system.

Rice. 2.1 Arrow types

In the IDEF0 methodology, only five types of interactions between blocks are required to describe their relationships: control, input, control feedback, input feedback, output-mechanism. The control and input links are the simplest because they reflect direct actions that are intuitive and very simple.

Rice. 2.2. Exit communication

Rice. 2.3. Management communication

A control relationship occurs when the output of one block directly affects the less dominant block.

Control feedback and input feedback are more complex because they are iteration or recursion. Namely, the outputs from one job affect the future performance of other jobs, which will subsequently affect the original job.

Management feedback occurs then; when the output of some block affects the block with a large dominance.

Exit-mechanism relationships are rare. They reflect a situation in which the output of one function becomes a means to an end for another.

Rice. 2.4. Input Feedback

Rice. 2.5. Management feedback

Exit-mechanism relationships are common in resource allocation (eg tools required, trained personnel, physical space, equipment, funding, materials).

In IDEF0, an arc rarely depicts a single object. It usually symbolizes a collection of objects. Since arcs represent collections of features, they can have multiple start points (sources) and end points (destinations). Therefore, arcs can branch out and connect in various ways. The entire arc or part of it can emerge from one or more blocks and end in one or more blocks.

Forking arcs, shown as diverging lines, means that all or part of the content of the arcs can appear in each branch. The arc is always tagged before the forking to give a name to the entire set. In addition, each branch of an arc can be marked or unmarked according to the following rules:

unmarked branches contain the weight of the objects specified in the arc label before the branch;
the branches marked after the bifurcation point contain all or part of the objects specified in the arc label before the bifurcation.

Merging arcs in IDEFO, depicted as lines converging together, indicates that the contents of each branch go to form a label for the arc resulting from the merging of the original arcs. After a merge, the resulting arc is always flagged to indicate a new set of features after the merge. In addition, each branch may or may not be flagged before being merged according to the following rules:

Rice. 2.6. Output-mechanism communication

unmarked branches contain the weight of the objects specified in the shared label after the merge;
branches marked before the merge contain all or some of the objects listed in the general mark after the merge,

Quantitative analysis of charts

To conduct a quantitative analysis of the diagrams, we list the model's indicators:

the number of blocks in the diagram - N;
chart decomposition level - L;
balance diagram - V;
the number of arrows connecting to the block - A

This set of factors applies to each diagram in the model. Recommendations for the desired values of the chart factors will be listed below.

It is necessary to strive to ensure that the number of blocks in the diagrams of lower levels would be lower than the number of blocks in the parent diagrams, that is, with an increase in the level of decomposition, the coefficient would decrease. Thus, the decrease in this coefficient suggests that. that as the model is decomposed, the functions should be simplified, therefore, the number of blocks should decrease.

Charts need to be balanced. This means that within the framework of one diagram, the situation depicted in Fig. 2.7: work 1 has significantly more incoming and control arrows than outgoing ones. It should be noted that this recommendation may not be followed in models describing production processes. For example, when describing an assembly procedure, a block may include many arrows describing the components of the product, and one arrow may go out - the finished product.

Rice. 2.7. An example of an unbalanced chart

Let's introduce the balance factor of the diagram

It is necessary to strive to Kh was minimal for the chart.

In addition to analyzing the graphical elements of the diagram, it is necessary to consider the names of the blocks. To evaluate the names, a dictionary of elementary (trivial) functions of the modeled system is compiled. In fact, functions of the lower, level of diagram decomposition should get into this dictionary. For example, for a database model, the functions “find a record”, “add a record to the database” can be elementary, while the function “user registration” requires further description.

After forming the vocabulary and compiling a package of system diagrams, it is necessary to consider the lower level of the model. If there are coincidences of the names of the blocks of diagrams and words from the dictionary on it, then this indicates that a sufficient level of decomposition has been achieved. The coefficient that quantitatively reflects this criterion can be written as L * C - the product of the model level by the number of matches of block names with words from the dictionary. The lower the level of the model (higher L), the more valuable the coincidences.

BPWin Toolkit

When BPWin is launched, the main toolbar, tool palette and Model Explorer appear by default.

When creating a new model, a dialog appears in which you should indicate whether the model will be created anew, or it will be opened from the ModelMart repository, enter the name of the model and select the methodology in which the model will be built (Fig. 2.8).

Figure 2.8 Model creation dialog

BPWin supports three methodologies - IDEF0, IDEF3 and DFD. In BPWin, it is possible to build mixed models, that is, a model can contain both IDEF0 and IDEF3 and DFD diagrams at the same time. The composition of the tool palette changes automatically when switching from one notation to another.

A model in BPWin is viewed as a collection of activities, each of which operates on a certain set of data. If you click on any object of the model with the left mouse button, a pop-up context menu appears, each item of which corresponds to the editor of a property of the object.

Example

Building a model of a system should begin by examining all documents describing its functionality. One of these documents is the terms of reference, namely the sections "Purpose of development", "Goals and objectives of the system" and "Functional characteristics of the system".

After studying the source documents and interviewing customers and users of the system, it is necessary to formulate the goal of modeling and determine the point of view on the model. Let us consider the technology of its construction using the example of the system "Employment Service within the University", the main capabilities of which were described in laboratory work No. 1.

Let us formulate the goal of modeling: to describe the functioning of the system, which would be understandable to its user, without going into details related to the implementation. We will build the model from the point of view of users (student, teacher, administrator, dean's office, company).

Let's start by building a contextual IDEF0 diagram - According to the description of the system, the main function is to serve its customers by processing requests from them. Thus, let us define the only work of the context diagram as "Serve the system client". Next, we define the input and output data, as well as mechanisms and controls.

In order to serve a client, it is necessary to register him in the system, open access to the database and process his request. The input data will be "client name", "client password", "source database", "client request". Execution of a query leads either to receiving information from the system, or to changing the content of the database (for example, when drawing up expert assessments), therefore, the output data will be "reports" and "modified database". The process of processing requests will be performed by the system monitor under the control of the administrator.

Context diagram

Thus, we define the context diagram of the system (Fig. 2.9).

Fig 2.9. System context diagram

Let's decompose the context diagram, describing the sequence of customer service:

Determining the level of access to the system.
Subsystem selection.
Subsystem access.
Changing the database (if necessary).

We get the diagram shown in Fig. 2.10.

After completing the decomposition of the context diagram, proceed to the decomposition of the next level diagram. Typically, when looking at the third and lower levels, the models go back to the parent diagrams and adjust them.

Rice. 2.10. Decomposition of the work "Service, client of the system"

We decompose all the blocks of the resulting diagram sequentially. The first step in determining the level of access to the system is to determine the category of the user. The client's name is searched in the user base, defining its category. According to a certain category, the authorizations granted to the system user are clarified. Next, the procedure for accessing the system is carried out, checking the access name and password. By combining information about the authority and the level of access to the system, a set of permitted actions is formed for the user. Thus, the definition of the level of access to the system will look as shown in Fig. 2.11.

Rice. 2.11. Decomposition of work "Determining the level of access to the system"

After going through the procedure for accessing the system, the monitor analyzes the client's request, choosing a subsystem that will process the request. Decomposition of the work “Addressing a Subsystem” does not correspond to the purpose and point of view of the model. The user of the system is not interested in the internal algorithms of its operation. In this case, it is important for him that the choice of the subsystem will be made automatically, without his intervention, therefore the decomposition of the call to the subsystem will only complicate the model.

Let's decompose the work "Client request processing" performed by the request processing subsystem, defining user categories and permissions. Before searching for an answer to a request, you must open the database (connect to it). In general, the database can be located on a remote server, so it may be necessary to establish a connection to it. Let's define the sequence of works:

Opening the database.
Executing the request.
Generation of reports.

After opening the database, it is necessary to inform the system about the establishment of a connection with the database, then execute the request and generate reports for the user (Fig. 2.12).

It should be noted that the "Execution of a request" includes the work of various subsystems. For example, if the request includes testing, then it will be executed by a subsystem of professional and psychological tests. At the stage of query execution, it may be necessary to change the content of the database, for example, when drawing up expert assessments. Therefore, the diagram must provide for such a possibility.

Rice. 2.12.

Adjusting the chart

When analyzing the resulting diagram, the question arises, what are the rules for generating reports? It is necessary to have pre-formed templates, according to which the selection from the database will be made, and these templates must correspond to requests and must be predetermined. In addition, the client should be given the opportunity to choose the form of the report.

Let's correct the diagram by adding the arrows "Report templates" and "Requests to change the database" and the tunnel arrow "System client" to it. Tunneling of the "System Client" is applied in order not to place the arrow on the top diagram, since the function of selecting the report form is not important enough to display it on the parent diagram.

Changing the diagram will lead to the adjustment of all parent diagrams (Fig. 2.13 - 2.15).

It is advisable to decompose the work "Execution of a query" using the DFD diagram (laboratory work No. 3), since the IDEF0 methodology considers the system as a set of interrelated works, which poorly reflects information processing processes.

Rice. 2.13. Decomposition of work "Client request processing"

Rice. 2.14. Decomposition of the work "System client service" (option 2)

Rice. 2.15. System context diagram (option 2)

Let's move on to the decomposition of the last block "Database change". From the client's point of view, these systems are located in one database. There are actually six databases in the system:

User database,
DB of students, (option 2)
DB of vacancies,
Performance database,
DB of tests,
DB of expert assessments,
DB summary.

According to the purpose of modeling, it is important for the client to understand that the received data is not immediately updated in the system, but goes through an additional stage of processing and control. The change algorithm can be formulated as follows:

The database in which the information will change is determined.
The operator forms a temporary data set and provides it to the administrator.
The administrator controls the data and enters them into the database.

This model can be implemented in a different way, providing the ability to update the database directly on request, bypassing the data control process. In this case, it is necessary to ensure the integrity control of the database to avoid damage to it. In this case, the diagram will look like this (Fig. 2.17).

Rice. 2.16. Decomposition of work "Database change"

Rice. 2.17. Decomposition of work "Database change" (option 2) For the first option, shown in Fig. 2.12

Carrying out further decomposition of "Database Changes" will complicate the model, explaining how the physical change of the database in the system is carried out. In this case, the user will not receive any additional information about the work of the employment service system. It is advisable to decompose this work in the process of designing a database system at the stage of creating a logical database model.

Decomposition of the Query Execution work will be carried out in the next lab, illustrating the use of DFD diagrams to describe information processing processes.

Let us carry out a quantitative analysis of the models shown in Fig. 2.12 and 2.13, according to the above procedure. Let us consider the behavior of the coefficient ^ for these models. The parent diagram "Client request processing" has a coefficient of 4/2 = 2, and a decomposition diagram is 3/3 = 1. The value of the coefficient decreases, which indicates a simplification of the description of functions with a decrease in the model level.

Consider the change in the coefficient K b in two model variants.

for the second option

Coefficient K b does not change its value, therefore, the balance of the diagram does not change.

We will assume that the level of decomposition of the considered diagrams is sufficient to reflect the purpose of modeling, and elementary functions (from the point of view of the user of the system) are used as titles of work on the diagrams of the lower Level.

Summing up the considered example, it is necessary to note the importance of considering several options for diagrams when modeling a system. Such variants may arise when adjusting diagrams, as was done with the "Processing a client request" or when creating alternative implementations of system functions (decomposition of the work "Modifying the database"). Consideration of options allows you to choose the best one and include it in the package of diagrams for further consideration.

Control questions

List Test questions:

What is a model in IDEF0 notation?
What do IDEF0 jobs mean?
What is the order of naming works?
How many jobs should be on one diagram?
What is called a dominance order?
How are the works arranged according to the principle of dominance?
What is the purpose of the sides of the work rectangles in diagrams?
List the types of arrows.
What are the types of relationships.
What are boundary arrows?
Explain the naming convention for branching and merging arrows.
What methodologies are supported by BPWin?
List the main elements of the main BPWin window.
Describe the process of creating a new model in BPWin.
How to make a connection between works?
How to set the name of the job.
Describe the work breakdown process.
How do I add work to a diagram?
How to resolve tunneled arrows?
Can a BPWin model contain diagrams of multiple methodologies?

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

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

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

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

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

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

The history of the IDEF0 standard

The IDEF0 methodology can be considered the next stage in the development of the well-known graphical language for describing functional systems SADT (Structured Analysis and Design Teqnique). Several years ago, a small edition of the book of the same name was published in Russia, which was devoted to 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 called ICAM (Integrated Computer Aided Manufacturing) and was proposed by the US Air Force. The IDEF family of standards itself inherited its designation from the name of this program (IDEF = 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 framework of “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.

Basic elements and concepts of IDEF0

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

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

The top side is Control;

The left side is set to “Input”;

The right side is set to “Output”;

The underside is “Mechanism”.

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

Figure 1. Functional block.

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

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

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

Figure 2.

Figure 3.

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

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

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

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

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

Figure 4. Decomposition of functional blocks.

The principles of limiting the complexity of IDEF0 diagrams

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

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

What goes to the unit “at the entrance”?

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

Who is responsible for each of the functions?

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

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

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