| In the mid-1970s, Douglas Ross worked with the U.S. Air Force to develop a method for modeling processes on the ICAM (Integrated Computer-Aided Manufacturing) program. Shortly thereafter, he applied the new method to an ITT telephonic system requirements definition effort. The name "Structured Analysis and Design Techniques" (SADT) was coined by Mr. Ross as a result of discussions with ITT. This was based on the principle that graphic models of various kinds should be used to communicate between the different disciplines involved in system development. In 1981 the Air Force recognized the usefulness of the concepts in SADT and derived from them a series of IDEF ( I ntegrated computer-aided manufacturing DEF inition) methods . One of these, IDEF0, addressed the modeling of functions and processes, while a second, IDEF1 (later extended to IDEF1X), addressed the modeling of data structure. In 1998 Clarence Feldmann wrote a guide to IDEF0, The Practical Guide to Business Process Reengineering Using IDEF0 . His focus was less on preparing for new computer systems than on simply understanding the nature of an enterprise and how it might be reworked. This section is largely derived from that book. [3] [3] Your author would like to express particular appreciation to Mr. Feldmann for his help with this section. On the surface, IDEF0 models are similar to data flow diagrams, but they are different in several significant ways: -
While a data flow diagram shows only the communication of data between activities, an IDEF0 model can also show material flows and control flows as well. Previously, the distinction between data and messages was described, but it was observed that the data flow diagram does not represent that distinction graphically. Here this distinction is made explicit. A message from one activity to another asserts control over the second activity. It is not merely an input to it. -
An IDEF0 diagram contains neither external entities nor data stores. The input and output lines document external entities and double as data stores, in that, where there is more than one input, data will wait in each flow until other needed flows are present. Arrows into and out of the diagram can, however, be documented separately as to where they are coming from and going to. -
Where a data flow diagram process can only be decomposed to a single lower-level diagram, an IDEF0 activity may be exploded in alternative ways. There are explicit constraints on the ways activities may be decomposed. (See p. 147.) In addition, there is a provision to link an activity to other documentation. -
The activities in an IDEF0 model show constraints, not sequential processes. That is, the execution of an activity is actually controlled by other activities. It is not just an optional branch. -
As normally used, the orientation of the model is toward the operation of the business, not the operation of an information system. Of course the symbols could be used to describe physical activities in all their technical glory , but that is not their intended use. That is, while mechanisms may be explicitly shown on the diagram, these need not affect the organization or the nature of the activities. Fundamentally, the diagram is supposed to be technologically neutral. Syntax The basic symbol in an IDEF0 model is a rectangle that represents an activity . Figure 4.18 shows this. The four sides of the box represent the four elements of the activity. Arrows coming into the left are inputs . An input arrow from the left describes input data that will be transformed by the activity. Arrows going from the box to the right are outputs . An output arrow describes the results of the transformation. Arrows going into the box at the top are controls . A control arrow describes something that affects the execution of the activity. This could be a message that triggers it, or a set of constraints that affect how the activity works. Arrows going into the box from below describe mechanisms , the physical means by which the activity is carried out. A mechanism arrow could describe a physical resource, such as a computer system, or it could describe the people or organizations that perform the activity. Figure 4.18. IDEF0 Activity Box.  Finally, an arrow from the box at the bottom is a "call" to another activity. This is used to refer either to a common process that is invoked in multiple places or to a process that is at a lower level of abstraction. In the first case, a call might be to a "Report Process" function or to a "Copy and Distribute" function. In the second case, the call arrow refers to a list of types of functions that are performed at this point in the model. For example, the box might be "Perform manufacturing process", and the called models might be "press", "treat", "form", etc. As with data flow diagrams, IDEF0 begins with a context diagram, labeled "A-0". This consists of one box for the entire portion of the enterprise being modeled . Figure 4.19 shows an example of this, for the same example that was used previously (Figure 4.14, page 161). Note that the federal standard for IDEF0 specifies the page layout for all IDEF0 diagrams. The "node" shows the position of this diagram in the overall structure. "BAQ", for example is the name of this project, and "A-0" means that this is the overview diagram. The name of the diagram is in the middle, and "DH63" on the right is a diagram number for this sheet of paper. (As you go through various drafts of the same model, each will have a different diagram number.) Figure 4.19. A-0 IDEF0 Diagram.  Note the following controls that can be shown here that did not appear on the context data flow diagram: "Funds" was shown as a data flow on that diagram. Here the flow is "Funds From County". Also note the addition of the following mechanisms: For readability purposes, an IDEF0 diagram is limited to no more than six activities. If more detail is required, one or more of these six can be exploded to describe how it works. This is a more rigorous requirement than was ever expressed for data flow diagrams, although the principle has always been around. Mr. DeMarco tended to have fewer processes on a diagram and a deeper explosion structure than Ms. Sarson and Mr. Gane, who liked broader, shallower diagrams. But the rules were never expressed as explicitly as this. (This is more rigorous than required by Mr. G.A. Miller's 1956 finding that a person can hold about seven plus or minus two elements in his mind at a time. In principle, one could have seven or even up to nine and still achieve the simplicity desired, but six was the number chosen .) With only six activities per page, it is easy to put the page on a single 8.5 by 11 [4] piece of paper. The activities are arranged from upper left to lower right. [4] ... or A4, if you are European... Information appears on this diagram that was not on the data flow diagrams. First, the books themselves show up as flows ("book shipment", "received book", "catalogued book", and "wrong book"). We also show the system provided by Baker and Taylor (the book distributor) which is used both for ordering and cataloguing. The bundle which is the "Baker and Taylor" system is split into two parts : the "Order System" and the "Cataloguing System". The players are shown as another resource, "Library Staff", which is split into the "Orderer", "Purchaser", and "Cataloguer". External entities are not shown but are inferred. In the case of the company supplying the books, this is not a problem, although it would be nice to know where the "Classification Guidelines" came from. Being vague on the origin of "Market Demand" is actually desirable in this case, since to characterize that more finely in this model would require more details than are appropriate at this time. This "Node" is shown as being the top-level diagram (A0) in the application area "BAQ". (Note that "A-0" is the context diagram, while "A0" is the highest-level detailed diagram.) Note in Figure 4.20 that the physical book shipment is shown, along with information about it. This is different from a data flow diagram's concern with information alone. Note that processing of the shipment is "controlled" by the specification of which books were ordered. If a book received wasn't ordered, it is returned to the sender. Figure 4.20. An IDEF0 Model. (Diagram by Clarence G. Feldmann.)  Note also that this example does not show " catalogue book" combined with "Receive each book", as was done in the essential activity analysis. IDEF0 has no specific provision for determining essential activities, although the process described in the previous section could certainly be applied here. Rules One of the strengths of the IDEF0 approach is the discipline it applies to the modeling process. Mr. Feldmann's book, for example, spends an entire chapter describing the " pragmatics " of developing IDEF0 models. He lays out criteria for organizing the project (including defining its purpose and viewpoint), creating the model (including the mechanics of its creation, as well as its validation), conducting peer reviews and critiques, presenting models to an audience, and analyzing the impact of changes that arise out of the modeling effort. In fact much of what he says applies to any modeling effort and is reflected in the material presented in Chapter 2 of this book. In addition, he presents very specific rules for the formation of the model itself [Feldmann, 1998, pp. 107122]: Box Rules -
Identify each activity box with a single-digit number, placing it in the lower right corner. -
Assign each activity at least one control arrow and one output arrow. (Unlike with data flow diagrams, it is not necessary for an activity to have an input arrow.) -
Name each box with a verb phrase consisting of an active verb and a direct object. -
Eventually, represent all covered activities in the lowest level of detail. Arrow Rules -
Match the arrows going into and out of the activity being decomposed to the arrows going into and out of a decomposed diagram. For example, the explosion of "Receive each book" must have arrows at the boundary describing "Book shipment", "Books ordered", etc. This means that alternative decompositions of an activity are possible, as long as the arrows match. Note that it is not recommended to "split by type", where an activity is split into different versions of the same activity. For example, the activity "Process product" should not be split into one activity for each work center. Those diagrams are not of the same level of abstraction as the parent. It is better to use the call arrow pointing to different diagrams for each work center. -
Label each arrow with an adjective and a noun. -
Some arrows may constitute groups of flows. If an arrow branching from a main arrow contains less than all the flows in the parent arrow, it must be labeled accordingly . -
Bundle arrows according to the appropriate level of detail of the processes involved. -
Show arrows as orthogonal (north/south or east/west), with rounded corners. -
Do not assign the same name to more than one arrow that goes into or out of one activity. Diagram Rules -
Each diagram must have between three and six activities represented. Identify each diagram by a project abbreviation, plus "A" with a hierarchical code. The context level with one box is called "A-0," and the highest level showing the first six activities is "A0". The first-level activities are identified as A1, A2, A3, etc.; the next level, A11, A12,..., A21, A22, and so forth. [5] [5] The "A" comes from the fact that the original SADT technique involved activity models and data models. So, activities were designated with an "A" and entities with a "D". -
Label the flows connecting between different diagrams. Each flow within a diagram may be identified as <source activity number>{ICOM}<flow number on that side>. So, for example, the third input to a process coming from process 2 is labeled "2I3". A flow to the outside of the diagram, then, is labeled with the target diagram identifier, plus the flow definition within that diagram. A flow in diagram PRJ/A23, which on that diagram is 4O2, may be labeled to connect with 1I3 on diagram A32. This would be PRJ/A32/1I3. -
Diagrams show constraint. They are not data flow diagrams or flow charts . For example, Figure 4.21 shows a flow chart, with its sequence of steps and its branch, next to an IDEF0 diagram, where the data flows are constrained by the control flow. Figure 4.21. Constraints, Not Flows.  Model Rules Restrict a model to a single viewpoint and purpose. The model's purpose must be clearly stated before the effort begins. It will affect how things are represented. The viewpoint is also important in determining how processes will be described: Is it technical? Managerial? Financial? An important component of viewpoint is the level of abstraction of the model. "Manage the corporation" is at a different level of abstraction than "Run the accounting department", and "manufacture product" is at a different level than "press ingots into sheets", "anneal sheets", and "form boxes". Note that this is different from "level of detail". A model of "Manage the corporation" may be very detailed in describing the tasks required, but these tasks are very different from the detailed tasks required to "Press ingots into sheets". There are also specific criteria that can be applied to determine an IDEF0 model's quality (Many of these can also be applied to other process model techniques as well): -
Model Validation An IDEF0 model must be put through a comprehensive process of review both for technical correctness (did it follow the rules described above?) and factual accuracy (does it reflect the actual nature of the business?) Questions to ask during validation include: -
What controls each activity? -
How does the activity respond to erroneous arrow content? -
Is there any feedback to previously completed activities? -
Which inputs and controls are used to produce each possible set of outputs? -
Which events trigger activation of the diagram? If the model is of the current operation and is to be used to modify the organization, it must be checked to be sure it is in sufficient detail to provide a basis for developing such modifications. To address this, questions might be: -
Is there a single organization responsible for performing this activity? If not, further decomposition is needed. -
Is there sufficient detail to analyze the activity in detail? For example, can you analyze its operating costs? If not, further decomposition is needed. -
What additional facts does this decomposition diagram provide? -
Are the facts related to the purpose of the diagram? If they are not, try a different decomposition. -
Are the facts related to the stated viewpoint? If not, determine where a viewpoint shift occurred. -
Fog Factor Testing The best test of the readability of a diagram is to evaluate the responses of various readers of the diagram. A more mechanical approach is to simply analyze the components of the diagram. Add together the number of boxes, the number of input, control, and output arrows per box, the number of arrow forks or joins, and the number of arrow crossings. If this number is greater than your corporate threshold (50, for example), then the model is too complex and should be simplified. Put more details in lower-level diagrams. [6] [6] This, by the way, is not a bad technique for evaluating any model. -
Arrow Label Precision /Arrow Label Description/Precise Control Arrow Content The name chosen for each arrow is critical to understanding the meaning of a model. It must be specific enough to convey accurately what the flow is about. Don't simply say "procedures". Say "accounting procedures" or "assembly procedures" or whatever. Don't simply say "rules" as a control. Specify which rules, or at least what category of rules. And don't just describe the medium, like "computer output" or "daily fax". Describe the contents of the flow. Note that a bundle may branch at some point and go to multiple different activities. If, when this happens, an arrow contains less than the full bundle, it must be labeled accordingly. For example, back in Figure 4.20, the bundle "Library Staff" consists of "Orderer", "Purchaser", and "Cataloguer". The cataloguer bundle branches three ways, but all three are the cataloguer, so they don't have to be labeled separately. In particular, the names of control arrows must be assigned carefully at each level. -
Diagram Simplicity The limit of six activities on a diagram helps to keep it from becoming too complex. It is equally important to be sure that the diagram isn't too simple. Are all the activities meaningful? Are all the flows and controls present that are required for a full understanding of the process involved? The way to test this is to imagine different scenarios and make sure that each of them can be handled (described) by the diagram. -
Arrow Bundle Grouping As the level of detail in successive diagrams increases , naturally the level of detail of the information flows will also increase. At the higher levels, it is reasonable to have data flows that are clusters of elements. These are broken out at lower levels. Even at a particular level, you have choices to make about the extent to which you group flows together. It is certainly possible to make the qualitative assertion that each data flow should be a coherent single thing at an appropriate level of detail, although there are few guidelines as to what constitutes an "appropriate level of detail". Too many flows obviously clutter the diagram. Too few provide too little information about what is happening. In general, any time you have multiple flows between the same two processes, you have the opportunity to bundle them together. The bundling should make logical sense, however. You may still wind up with two or three bundles. -
Correct Identification of Controls While it is better if this is not so, some bundles at a higher level will contain flows that are both inputs to an activity and controllers of it. When they are broken out at lower levels, this will become clear. At the higher level, though, if any part of the bundle is used for control, it should all be considered a control bundle. It is certainly important, even at a high level, to keep clear the distinction between inputs and controls. An input is something that is modified by the activity to produce an output. A control, on the other hand, determines how the activity works. -
Viewpoint Focus If the diagram seems to show many kinds of data from different viewpoints, the modeler should consult the model's viewpoint definition (described above, p. 177) to see which viewpoint is supposed to be represented on the diagram. -
Text Selection Each diagram should be accompanied by a body of text that explains and clarifies it. This should not, however, be a detailed description of what is on the drawing. That should be self-evident. Rather, the text simply clarifies circumstances, gives examples, and describes business rules that are not apparent on the diagram. -
Function and Design Separation Finally, an IDEF0 diagram should describe the functions of the businesswhat it is or wants to do (including sequential processes)not the design of the business. Yes, mechanisms are added as comments on the bottom of the activity boxes, but the presence of these mechanisms should not in any way affect the shape of the drawing or the descriptions of the activities. |
