Logo en.artbmxmagazine.com

Modeling and management by processes for efficiency

Table of contents:

Anonim

Modeling and management by processes for efficiency

SUMMARY

The achievement of efficiency, effectiveness and, in general, quality in the production of goods and services is a primary endeavor of any institution. Business organization studies and reengineering techniques deal with this subject with particular attention, within which the process is established as a fundamental and key concept and it is defined that these are the ones that determine the quality of what is produced.

The objective of this work is to show the usefulness of modeling the processes of an institution as a tool to act in a systematic and methodical way, that is, with a scientific and technical basis, in the improvement of the operation and of the goods and services produced. by an organization.

The modeling of the processes is carried out, according to this presentation, using a methodology called IDEF-0 and the BPwin 2.5 software designed specifically for this purpose and whose effectiveness has been proven in international practice, while in Cuba it has been used successfully, but only at the level of the company or partial processes an institution.

Its application does not require the use of additional forces or the acquisition of new equipment or equipment; It is enough to have a computer and the methodology and software indicated. The modeling is carried out by an ad hoc interdisciplinary team, made up of specialists from the processes developed by the institution itself and who work part-time, without abandoning their normal tasks. For these reasons, the costs of its application are minimal at the same time that the positive effects can be achieved in any of the universe of processes of the institution, both strategic, essential or complementary.

Basic concepts

The changing environment in which Organizations operate implies evolving rapidly to face new opportunities, risks and expectations and it is vital to internalize the concept of changes as part of the organizational culture and thus avoid the resistance that occurs due to fear of the new. to the unknown.

Organizations are social systems and therefore are governed by dynamic processes and must face change in order to survive. Even its most deeply rooted elements such as culture are impacted by this need. The people that make up the human social subsystem share attitudes, beliefs, motivations, values, techniques, instruments and in general a common behavior, constituting an organizational culture.

The change of culture implies a modification of a state, a condition or situation. These transformations are shaping a new type of organizational culture, characterized by a new way of thinking and visualizing the organization, by a new way of developing activities, and an open attitude towards innovation and creativity. All of this affects the overall effectiveness of the organization. When it comes to organizational changes, it is convenient to understand that they must occur as a consequence of an existing attitude in the organization, and that they must be congruent with the existing organizational culture.

The word change has taken root within the most diverse organizations and has become a protagonist of business activity. The changes are nothing more than the new trends and attitudes of the organizations, as well as a reality that strongly affects it, so much so that it is most likely that something that is unique or solid today, tomorrow will be surprisingly different.

It should be noted that organizational changes should not be left to chance, or to improvisation, they should be properly planned as a way to ensure that the results of the same will benefit the organization.

Organizational change is the cornerstone of continuous improvement of organizations. It is the phenomenon by means of which the future invades our lives and it is convenient to observe it carefully paying the necessary attention from the point of view of the individuals who work within the organizations.

The change process encompasses all activities aimed at helping the organization to successfully adopt new attitudes, new ideas, and new forms of job performance.

An important aspect to consider is the natural tendency of people to resist change. You have to create and develop an attitude and mentality open to change, as well as a culture that allows you to welcome good initiatives and take advantage of them, as well as discard bad ones.

The most normal thing in society and the world we live in is for individuals to feel frightened by and resist changes. Human beings tend to flee and obstruct what they do not yet know, even more so when what they do not know means a drastic change in their lifestyle and way of working.

All the people who work in companies, workers and even managers, are today prisoners of antiquated theories about the organization of work, theories that date from the beginning of the Industrial Revolution. Rigid ideas - the division of labor, the need for minute control, the administrative hierarchy - no longer compete in this turbulent world of global competition, and inexorable change. To replace them, there is no new creed, nor is it possible to discard them for their own sake, but rather to focus on the aspects that fundamentally move organizations that are their processes.

For many years, almost all business organizations have been organized vertically, by role. Currently, the organization by processes allows paying more attention to customer satisfaction through effective and efficient comprehensive management: the transition from the functional management system to the process management system occurs.

Technicality and a false sense of individual specialization, together with internal competition and hierarchy, have led the members of many Organizations to be oriented to their personal task. Everyone is proud of their work from a technical point of view, and the rest does not matter.

Each person concentrates their effort on the task assigned to them, trying to do it according to the instructions and specifications received, but with little information regarding the final result of their work, that is, they do not know, at least clearly, how their work contributes to the final product.

This pyramidal structure, very valid in Organizations where decisions are always made by the main boss, begins to have difficulties when Total Quality is required in each operation, in each process; as it forces that main boss to multiply, especially in supervision.

The origin of traditional structures is based on the fragmentation of natural processes, a product of the division of labor (Taylor), and subsequent grouping of the resulting specialized tasks into functional areas or departments. In these traditional structures; no area director is solely responsible for the successful completion of a process, since responsibility is divided into areas and several areas are involved in the same process. Thus it would be up to the general management to take responsibility for it. If we summarize, in traditional management the GENERAL MANAGEMENT has to intervene very frequently in complete processes, due to the fact that in the same process many departments or areas intervene with different managers whose only coordination can be achieved by the top management.

It is about re-reunifying the activities around the processes that were previously fragmented as a result of a series of decisions, which means recognizing that the processes are first and then the organization that supports them to make them operational. It is to see the process as the natural way of organizing work. The structure may or may not coincide with the process, since in the same job position you can perform functions for different processes.

The company is a system of systems, each process is a system of functions and the functions or activities have been grouped by department or functional areas. PROCESS MANAGEMENT consists, therefore, in comprehensively managing each of the processes that the company carries out. Systems coordinate functions, regardless of who performs them. All the responsibility of a manager who delegates, but retaining the final responsibility. The general management participates in the coordination and conflicts between processes but not in a specific process, except by exception.

Each person involved in the process should not always think about how to do better what they are doing (division of labor), but why and for whom they do it; since the satisfaction of the internal or external client is determined by the coherent development of the process as a whole rather than by the correct performance of each individual function or activity.

In PROCESS MANAGEMENT, attention is focused on the result of the processes, not on the tasks or activities. There is information about the final result and everyone knows how individual work contributes to the global process; which translates into a responsibility with the total process and not with your personal task (duty).

PROCESS MANAGEMENT is based on the assignment of a manager with responsibility for each of the company's processes. In its most radical form, the departmental organization is replaced. In other forms, perhaps transitional, the departmental structure is maintained, but the person in charge of a process has responsibility for it, and at least as far as that process is concerned, they can have authority over the functional (matrix) managers.

Process management has the following characteristics:

Analyze the limitations of the vertical functional organization to improve the efficiency of the Company.

Recognize the existence of internal processes (relevant):

- Identify the processes related to the critical factors for the success of the Company.

- Measure their performance (Quality, Cost) and put it in relation to the added value perceived by the client.

Identify the needs of external clients and guide the Company towards their satisfaction.

Understand the scope differences between improvement oriented to processes (what and for whom things are done) and that focused on departments or functions (how it is done):

- Productivity of the whole versus the individual (Global effectiveness versus Partial effectiveness).

- The department is a link in the chain, a process to which it adds value

- Organization around results, not tasks.

Assign personal responsibilities to each process.

Establish in each process performance indicator and improvement objective.

Evaluate the ability of the process to satisfy them.

Keep them under control, reducing their variability and dependence on non-random causes (Use statistical process control charts to make quality and cost predictable).

Continuously improve its global performance by limiting its common variability

Measure the degree of satisfaction of the internal or external client, and put it in relation to the evaluation of personal performance.

The difficulty, great by the way, does not lie in the technical component of this way of managing an Organization, but in the change in people's attitude. Some of the paradigms under which we have been educated, such as the Taylorian logic, the organization chart and the Hierarchy, have to be called into question, as well as certain cultural values ​​now seen as a brake on creativity.

The changes in behavior, especially in managers and directors, necessary to manage the processes of the Organization are summarized in:

1. Merge in people thought and action of improvement against the Taylorian logic. It is not about working more but about working differently.

2. Commitment to results versus compliance.

3. Processes and clients versus departments and bosses.

4. Participation and support in the face of hierarchy and control.

5. Responsibility for the process in front of functional hierarchical authority.

If the mission and objectives of the processes are clearly defined in terms of the added value perceived by customers, those activities considered as ineffective and therefore essential will automatically be revealed.

Process Management Objectives

As a quality management system that it is, the main objective of Process Management is to increase the Organization's results by achieving higher levels of customer satisfaction. In addition to increasing efficiency through:

Reduce unnecessary internal costs (non-value-added activities).

Shorten deadlines (reduce cycle times).

Improve quality and value perceived by customers

To understand Process Management we can consider it as a system whose main elements are:

  • The key processes The coordination and control of its operation The management of its improvement.

Undoubtedly, an organization of this type with highly autonomous process teams is more agile, efficient, flexible and entrepreneurial than the classic bureaucratized functional organizations. It is also closer and better aimed at the client.

In conclusion, the ultimate purpose of PROCESS MANAGEMENT is to make the improvement of customer satisfaction compatible with better organizational results.

Process management is easily understood by its overwhelming logic, but it is difficult to assimilate due to the paradigmatic changes it contains.

Reengineering is one of the management phenomena with the greatest impact in recent decades, because its rapid and overwhelming expansion has caused and continues to cause large-scale changes in many organizations.

Within the various approaches given to the concept of reengineering offered by different authors. These approaches have in common that the key factors of the concept are: orientation towards processes, change and the magnitude of the expected results.

Reengineering focuses on the strategic processes of the company, that is, on those that are related to its most important activities and that are strongly linked to its strategy. The processes are not completely isolated in an organization, there are structures, policies and practices that support them. When looking for process improvements, sometimes many of these support frames have to be varied.

The objectives pursued by reengineering when analyzing the processes to find points of improvement are:

Greater economic benefit due to both the reduction of costs associated with the process and the increase in their performance.

Greater user satisfaction due to the reduction of the service period and the improvement of its quality.

Higher staff satisfaction due to better definition of processes and tasks

4. Greater knowledge and control of processes

5. Achieve a better flow of information and materials

6. Decrease in service process times.

7. Greater flexibility in the face of changes in the environment

Reengineering, as we have already stated, focuses on the study and improvement of processes, since these are the ones that move organizations. These are possibly the most important and most widespread element in business management.

Why the study of processes? Because Organizations are as effective and efficient as the processes that produce goods and services. Most of the Organizations that have become aware of this have reacted to the inefficiency and consider how to improve the processes and avoid some common evils such as: low performance, departmental barriers, useless sub-processes due to the lack of global vision of the process, among other.

A process can be defined as a set of interrelated activities that, from one or more inputs of materials or information, give rise to one or more outputs also of materials or information with added value for a user. In other words, it is the way things are done in the Organization. The starting point for organizational success is to have well-designed processes.

The transformations that occur within the processes repeatedly cross functional or structural limits, thus forcing cooperation and creating a different company culture, more open and less hierarchical, more oriented to obtain results.

To understand the relationships between the activities of the system in the processes, we must help ourselves with their modeling. A model is a representation of a complex reality. Performing the modeling of a process is to synthesize the dynamic relationships that exist in it, test its premises and predict its effects. These techniques have been developed to facilitate communication and the capture of information for a better study.

Systems (sets of processes and sub-processes integrated in an organization) are often difficult to understand, extensive, complex and confusing; with multiple points of contact with each other and with a good number of functional areas, departments and positions involved. A model can provide the opportunity to organize and document information about a system.

But what is a model? A model is a representation of a complex reality. Modeling is developing a description as accurate as possible of a system and the activities carried out in it.

When a process is modeled, with the help of a graphic representation (process diagram), the interrelationships between different activities can be easily appreciated, analyze each activity, define the points of contact with other processes, as well as identify the sub-processes involved. At the same time, existing problems can be clearly highlighted by giving the opportunity to initiate improvement actions.

Diagramming is to establish a visual representation of the processes and sub-processes, which allows obtaining preliminary information on their amplitude, their times and those of their activities.

The graphic representation facilitates the analysis, one of the objectives of which is the decomposition of work processes into discrete activities. It also makes it possible to distinguish between those that add value and those that do not, that is, they do not directly provide anything to the customer of the process or the desired result. In this last sense it is necessary to make a clarification, since not all the activities that do not provide added value have to be unnecessary; These may be support activities and may be required to make management and control functions more effective, for security reasons or for regulatory and legislative reasons.

Diagramming is an activity closely linked to modeling a process, which is itself an essential component in process management.

A first step in process modelingIt is through the process maps that are nothing more than a scheme that defines the organization as a system of interrelated processes, this also helps us to identify them and allows us to clearly document the most important elements of the Organization: what activities are necessary, how they are carried out and what resources they consume. That provides an accurate view, not only of what is being done, but whether it is being done efficiently. It encourages the organization to see beyond its geographical and functional limits, showing how its activities are related. Such "maps" provide the opportunity to improve coordination between key elements of the organization. They also give the opportunity to distinguish between key, strategic and support processes,constituting the first step to select the processes on which to act.

An effective methodology for modeling and reflecting the different processes that are developed in a complex activity company is IDEF-0, which is a simple but powerful technique, widely used in the industry during the analysis stage in process reengineering. This allows the processes and their interfaces to be appropriately identified and the documents that allow their control in any of their development stages to be prepared. With this tool we systematically analyze the Organization, focusing on the tasks that are carried out on a regular basis, the control policies that are used to ensure that these tasks are carried out correctly, the resources (both human and material) that are used to carry them out., the results of the task and the raw materials on which the activity acts.Being based on a standard with precise and rigorous specifications that allows reaching any level of detail, it has wide applicability as a means to communicate rules and processes, to obtain a strategic view of them and facilitate analysis to identify points for improvement

The IDEF-0 methodology can be represented by various software packages, such as the BPwin software. This is a powerful modeling tool for analyzing, documenting and improving processes. With a BPwin model you can easily document factors such as what activities are needed, how to carry them out, and what resources to use. This provides an integrated picture of how the organization operates, from small department workflow models to more complex tree diagrams.

Instruments Used

The literal translation of the acronym IDEF is Integration Definition for Function Modeling (Definition of integration for modeling functions). IDEF consists of a series of standards that define the methodology for the representation of modeled functions.

As explained in the previous chapter, the IDEF-0 methodology provides a framework to represent and understand the processes, determining the impact of the different events and defining how the processes interact with each other, allowing us to identify inefficient or redundant activities.

These models consist of a series of hierarchical diagrams together with some texts and cross-references between the two that are represented by rectangles or boxes and a series of arrows. The description of each process is considered as the combination of five basic quantities that are graphically represented as:

Processes or activities

Inputs

Controls

Mechanisms or resources to carry out tasks

Outputs or results achieved in the process (which may in turn be inputs, mechanisms or controls of other processes)

Processes: It is represented by a box in which all the activities that are part of the process are enclosed.

Inputs: represents the material or information that is consumed or transformed by the process in order to produce the outputs. Some processes may have no input.

Outputs: material or information produced by the process. Each process, to be considered as such, must have at least one output

Controls: regulate, limit or establish the way in which processes carry out their activities to produce outputs from inputs. Each process must have at least one control. The most common are laws, decrees, regulations, guidelines, procedures

Mechanisms: those resources that the process needs and that are generally not consumed during it. Mechanism example: quantitatively and qualitatively adequate personnel, machines, computer equipment, copiers, etc.

One of the most important aspects of IDEF-0 is that as a modeling concept it gradually introduces more and more levels of detail throughout the model structure. In this way, communication occurs by giving the reader a well-defined topic with a quantity of detailed information available to deepen the model. (See annex 1)

BPwin software is a powerful tool for process modeling. This shows us how to create a model that exemplifies the organization and on this basis we can quickly study and analyze the processes. Using BPwin you can build a diagram that clearly shows the business activities. This provides an integrated picture of how the Organization does things, from the Organization as a whole or a part of it.

With the BPwin, three modeling methodologies can be mixed into a single tool to serve the needs of business and technology analysts. These are: Business Processes (IDEF-0), Workflows (IDEF-3) and Data Flows (DFD)

For any methodology that is used with the BPwin, there is a total perspective of the complete model. Graphics (boxes and arrows) are used to provide structure, which gives the pictorial representation of the process model. With this program the entire system of interest can be seen in depth and even a detail of the organization can be analyzed, understood and perhaps more importantly communicated to other people.

Work Organization

The basis for organizing the process modeling work, as we have already indicated, is established by the IDEF-0 methodology and begins with the creation of a multidisciplinary working group made up of specialists from different areas of the institution. It is possible and advisable to vary the composition of the group according to the process to be modeled.

The practical experience of the work carried out in the Customs Bodies System teaches the need to adhere strictly to the provisions of the methodology, without violating or altering the steps indicated.

Before starting the modeling of the processes, a seminar should be held with the selected specialists to explain the objectives of the work and the content of the IDEF-0 methodology and the BPwin software.

Subsequently, the first step in creating the model is to describe the highest level, called the A-0 Context Diagram. Said diagram describes the system as a whole, that is, it provides a general description of the activity of the institution that is going to be modeled, so the definition will coincide with the mission of the organization. The way of making this A-0 diagram is the same as that used for all processes and that results in the graphic representation of the ICOM box that is described later.

To define the processes that result from the decomposition of the A-0 Context Diagram, a first session is held that begins with the team members verbally expressing all the ideas that come to mind about the activities carried out by the institution. It constitutes the second step of the methodology and that we describe below.

As the elements are raised, they are written on a blackboard and listed, with the principle that no idea is rejected or criticized. There is no limit to the ideas that can be expressed. Actually the more extensive and complete it is, the better.

Then we go on to analyze each of these ideas, from here variants arise, one is to discard it because it is not part of the process and another is to unite them with other related ones. It is important to keep the numbering because this will indicate the elements that make up the resulting process.

3. At the end there will be a list of between 3 and 8 activities that are equivalent to the threads of the context diagram. These will form the basis of the decomposition diagram, which we will explain later.

Having the defined process, the third step corresponds to drawing the ICOM (which for its acronym in English are inputs, controls, outputs and mechanisms). The ICOM consists of a rectangle to which the outputs are connected by arrows first, then the inputs, and finally the mechanisms and controls. For this, the results achieved previously are also taken into account and possible relationships with the other processes already defined and to be defined are established. In the preparation of the ICOM, which is nothing more than the graphical representation of the process, the BPwin software is used.

In a fourth step, the definition of the process is written, in the form of a glossary: ​​that is, the criteria that will identify the corresponding process will be explained.

As a fifth step, the decomposition diagrams will be drawn up in successive hierarchical form (from highest to lowest level) from the context diagram. For this, the same procedure described above will be applied when explaining the preparation of the context diagram.

The decomposition diagram represents graphically in ICOM form each of the activities that make up or integrate the process of the next higher level, reflecting through the ICOM arrows the links between each of them and with other processes outside the decomposition diagram that are elaborates.

In the case of the first decomposition diagram (the one in box A-0), the processes that comprise it are generally three: the directing process (groups the strategic activities), the executing process (which includes the activities that give the institution its own identity or characteristic) and that of supporting or complementing it (which refers to logistical or technological support activities).

Each time a decomposition diagram is completed, they are schematically transferred to the node tree, at the top of which is ICOM A-0, Each of the sub-processes that make it up. In this way, the node tree and decomposition diagrams are developed in parallel, until the institution's modeling is completed.

A successive decomposition diagram must be made for each of the sub-processes that appear in the preceding decomposition diagram until reaching the level of detail that is satisfactory for the purposes of fully and completely identifying and describing the activities of the institution.

The BPwin software gives us the graphical representation of the process. With the advantage that it indicates possible incongruities that may have been committed when defining the inputs, outputs, mechanisms and controls; allows us to see the relationship between the different processes, that is, their interconnection; to avoid duplication and we can visualize how a change in a certain process affects the others.

Knowing in depth the IDEF-0 methodology and all the elements that make it up, modeling through the BPwin software becomes quite simple.

A brief description of the program will help us understand it. It has two windows, one on the left where you can see the processes and their decomposition, called a tree diagram and another on the right where the diagram corresponding to the process selected on the left side is drawn. This diagram is made up of several boxes (ranging between 2 and 8) that are nothing more than the necessary sub-processes or activities, in a specific degree of detail, that are part of a certain process and their respective interconnections represented by the arrows already defined in Chapter III, which in turn represent people, things, concepts or events. The boxes do not give information on the temporal development or succession of the processes, but rather,together with the arrows they describe the necessary data and the information created by the activities. Arrows are named and connected to a point of origin and termination. Depending on what they represent, inputs, outputs, controls or mechanisms go from an origin process to a destination process, either within the decomposition diagram, towards other diagrams or from or to processes outside the institution, that is, the origin or destination. of the arrows in these cases are external to the organization.that is, the origin or destination of the arrows in these cases are external to the organization.that is, the origin or destination of the arrows in these cases are external to the organization.

When it is required to decompose a process into several threads, the program creates a new diagram called child where the process that gave rise to it is named parent box. In this operation, the program automatically includes in the child diagram all the arrows that connected the parent, so this allows us to see possible inconsistencies or omissions that may have occurred at the time of modeling, although more arrows can be linked to the child than make them more specific and that they don't necessarily have to appear in the parent box.

With the BPwin, the node tree diagram can also be represented, which, as already said, allows us to visualize the complete model, which helps us to concentrate on its functional decomposition.

Another possibility that the program offers us is to provide a structure that can be used to give value to the model. In other words, characteristics such as cost, time, fulfillment or metric units can be specified. This gives the possibility of using two methods, one is Activity Based on Costs (ABC) and the other is User Defined Properties.

Also very important are the numerous reports that the program provides to extract and publish the information worked on in the model.

In addition to the tools used previously exposed for the work, other instruments were used such as consultations with experts, visits to the units and consultation of documents.

Conclusions

  • With the work presented we have shown the results of the work carried out at this central level to get to specify the main processes and sub-processes, both of the customs activity itself and of directing customs and technologically supporting customs work. For this we have used the IDEF-0 methodology and the BPwin program. We understand that this is the first time that an organization has used this methodology and has studied all its essential, strategic and support processes.To this is added that we have begun to apply the results obtained in tasks such as: the identification of functions of workstation by processes and sub-processes,the use of processes as an analytical tool in strategic planning and to determine the load and capacity of facilities and of material and human resources in conjunction with operations research and mathematical statistics. And we intend to work on the organization of the normative base.

Bibliography

  • Champy, J; M. Hammer. 1994. Reengineering. Ed.Norma.F. Sáez Vacas, O. García, J. Palao and P. Rojo. Technological innovation in companies Annex No.1 Summary IDEF-0 Methodology

goals

Modeling of the functions required by a system.

Establish a generic, rigorous and precise, concise, conceptual and flexible modeling technique.

Applicability:

Projects that require modeling techniques for the analysis, development, reengineering, integration or acquisition of information systems.

Projects that incorporate modeling techniques into a business process analysis or software engineering methodology.

Definitions:

Diagram A-0: Single box IDEF-0 context diagram, containing the high-level function to be modeled, along with its inputs, outputs, controls, and mechanisms.

Arrow: Direct line composed of one or more segments that models an open channel or conduit of data or objects from a source to a use. There are four types of arrows: input, output, control and mechanism.

Arrow Label: Name that specifies the meaning of an arrow.

Arrow segment : Line segment that begins or ends in a box, branch, or line with no connected end.

Limit Arrow : Arrow with one end not connected to any box or diagram.

Box: Rectangle containing a name and a number used to represent a function.

Box name: Verb or verb phrase located inside an IDEF-0 box to describe the modeled function.

Box number : The number from 0 to 6 that is placed within the lower right corner of an IDEF-0 box to identify the box on a diagram.

Branch: Arrow branched into two or more parts that describes the same object or data.

C number: A chronologically created number that is used unequivocally to identify a diagram and to trace its history. It can be used as a detail reference expression to specify a specific version of the diagram.

Call arrow : Type of mechanism arrow that allows details to be shared between models or within a model by joining them.

Child box: Box of a child diagram.

Child diagram: Diagram that details a parent diagram.

Context diagram: Diagram that presents the context of a model whose node number is An (n greater than or equal to zero). The A-0 box diagram is a required context diagram; diagrams with number of nodes A1, A2,… are optional context diagrams.

Control arrow : Type of arrow that expresses IDEF-0 control, that is, those conditions required to produce a correct output. Data or objects modeled as controls can be transformed by the function thus creating an output. Control arrows are usually associated with the top of an IDEF-0 box. Examples can be: policies, manuals, procedures, etc.

Decomposition: Division of a modeling function into its component functions.

Detail reference expression : An expression written under the lower right corner of an IDEF-0 box to show that it is detailed and to indicate which diagram details it.

Diagram: Unit of an IDEF-0 model that presents the details of a box.

Diagram Node Number: The part of the diagram reference node that corresponds to the node number of its parent box.

Branch: A junction where an IDEF-0 segment is divided into two or more segments.

Function: Activity, process or transformation (modeled by an IDEF-0 box) identified by a verb or verb phrase that describes that it must be fulfilled.

Function name: Same as box name.

Glossary: List of definitions for keywords, phrases and acronyms used in conjunction with an IDEF-0 node or model as a whole.

ICOM code: Acronym for output, control, output and mechanism. Code that associates the endless arrows of a child diagram with the arrows of its parent diagram; also used for reference purposes.

IDEF-0 Model: Graphic description of a system or content that is developed with a specific purpose and with a specific point of view. The set of one or more IDEF-0 diagrams describes the area functions of a system or subject with graphics, text, and a glossary.

Input arrow : Type of arrow that expresses an input, data or object that is transformed by the function into an output. The input arrows are located on the left side of the box. They can be needs, requirements, states, etc. and from more concrete points of view they can be documents such as invoices, etc.

Interface: The connection between two or more model components for the purpose of passing data or objects from one to another.

Mechanism arrow: Type of IDEF0 arrows that represent mechanisms, that is, what is needed to develop a function. The mechanism arrows are located at the bottom of the IDEF0 box. From the manager's point of view, the mechanisms show the interrelationships with other processes, the external resources necessary for the process, etc. These will include personnel not attached to the process that is being represented, information systems, external advisers

Node: Box from which child boxes originate; parent box

Output arrow : Type of arrow that expresses an IDEF0 output, that is, the data or object produced by a function. The output arrows are associated with the right side of an IDEF0 box. From the manager's point of view they can be satisfactions, etc.

Parent Box: Box that is detailed by a child diagram

Parent diagram: Diagram containing a parent box

Title: verb or verb phrase that describes the general function represented in an IDEF0 diagram; the title of a child diagram corresponds to the name of its parent box.

Diagrams and their components

Boxes

The name of the box must always be a verb or verb phrase that is descriptive of the function that the box represents. The shape of the box should always be rectangular with the straight corners at 90º angles and large enough to accommodate the name of the function.

Arrows

Arrows must always contain straight segments that form 90º angles. Oblique strokes are not allowed.

The arrows that enter the box from your left are the entrances. The inputs are transformed or consumed by the function to produce the outputs. The arrows that enter the box from the top are the controls. The controls specify the conditions required by the function to produce correct outputs. The arrows that come out of the box on the right side are the exits. The outputs are data or objects produced by the function.

The arrows connected to the bottom of the box represent the mechanisms. Arrows pointing upward identify some of the media that support the performance of the function. The mechanism arrows that come down from the box are call arrows. Callout arrows make it possible to share details between models or between parts of the same model. The box that is called provides details for the “calling” box, the box that is calling, from where the arrow comes out.

Representation rules

The graphical diagram is the main component of an IDEF0 model. The functions represented by the boxes in these diagrams can be divided or decomposed into more detailed diagrams until the described topic has been described at the level necessary to achieve the specific objectives of the represented project. The top-level diagram of the model provides a more general or abstract description of the topic represented in the model. This diagram is followed by a series of child (branch) diagrams that will provide more detail on the subject.

Top-Level context diagram

Every model must have a top-level context diagram in which the theme of the model is represented with a single box with its corresponding arrows. This diagram is called the A-0 (minus zero) diagram. The arrows in this diagram interface with functions outside the topic area.

Since a single box represents the entire topic, the name that describes it will be very general. The same will happen with the interface arrows since they represent the set of external relations of the topic. Diagram A-0 also establishes the objective of the model as well as its orientation.

Diagram A-0 will also present brief reviews specifying the point of view and the purpose of the model. Point of view determines what can be seen in the context model and from what perspective.

The objective statement expresses the reason for creating the model and determines the structure of the model.

Child diagram

The function represented in the top-level diagram can be decomposed into different lower-level child diagrams. Also, these subfunctions can be decomposed into new lower-level child diagrams. In a diagram all functions can be decomposed, some, or none of them. Each child diagram contains child boxes and arrows that provide additional detail about the parent box.

Father Diagram

A parent diagram is one that contains one or more parent boxes. Each ordinary diagram (other than the context diagram) is also a child diagram since by definition it details a parent box.

The expression of the detail reference (DRE Detail Reference Expression) tells us that a parent box has a child box that details it. The ERD is a short code written below the lower right corner of the box of the diagram that is being detailed (the parent).

ERD can take one of the following forms:

A created chronological number called C-Number that uniquely identifies a specific version of the child diagram.

A page number of the child diagram in the published document in which the model appears.

The node number that the child diagram references. If there are different versions of the child diagram, a particular version cannot be specified.

The note number of the model whose text specifies the conditions for the selection of a particular child version.

Syntax rules for diagrams

Context diagrams must have node numbers An, where n is equal to or greater than zero.

The model must contain an A-0 context diagram that contains only one box.

The box number of the single box in context diagram A-0 must be 0.

A diagram other than the context diagram must have between three and six boxes.

Each box in a non-context diagram should be numbered in its lower right corner from 1 to 6.

Each box that has been detailed should have the detailed reference expression of its child diagram written under the lower right corner of the box.

Arrows must be drawn with horizontal and vertical strokes, never diagonal.

Each box must have a minimum of one control arrow and one exit arrow.

A box can have zero or more input arrows.

A box can have zero or more no-mechanism call arrows.

A box can have 0 or 1 call arrows.

The unconnected end of the limit arrows must have its own ICOM code specifying its connection to the parent box in case it is not tunnelled.

Open-ended boundary arrows representing the same data or object should be connected by branching arrows to all affected areas unless this makes the diagram incomprehensible.

The names of arrows and boxes should not consist solely of words such as: function, activity, process, input, output, control or mechanism.

Node numbering rules

The top-level context diagram is always numbered A-0

Other higher-level context diagrams not required are numbered An where n is greater than zero.

First-order child (subsidiary) diagrams are numbered A1, A2,…

The child diagrams of a lower level will be numbered A11, A12,…, A61, A66… and so on.

Activating a box

A box can activate various parts of its function under different circumstances, using different combinations of its inputs and controls, and producing different outputs. These various performances are called activations of the box.

Chain operations

Some functions in a model can be developed in a chain if the necessary conditions have been satisfied. The output of a box can provide some or all of the data and objects necessary for the activation of one or more boxes.

When the output of one box provides some or all of the inputs, controls or mechanisms necessary for another box, the activation of the last box will depend on sequential development. However, different activations of the same box with different requirements can operate in a chain.

Feedback or feedback

In IDEF0 models the feedback of controls, inputs or mechanisms can be represented. This occurs when any of these elements re-enter the process, feeding it back. The ways to express it are as follows:

Feedback controls are shown with an arrow that goes up and enters the top.

Input feedback is shown with an arrow going down and entering from the right.

Feedback mechanisms should be shown with an arrow that goes down and enters the box from the bottom.

Download the original file

Modeling and management by processes for efficiency