Part Four Process Oriented Modeling and Analysis 8 IDEF3 Process Capture Method

Abstract IDEF3 is one of IDEF series modeling methods. It is applied to business process modeling and analysis. IDEF3 was originally developed for concurrent engineering. Recently, it is used for business process reengineering and business process management. The syntax and semantics of IDEF3 for business process modeling are introduced in this chapter. The structured approach for IDEF3 model development is also discussed.

8.1 Introduction to IDEF3

The IDEF3 Process Description Capture Method describes sequences of activities. Its primary goal is to provide a structured method to describe the operation of a particular system or organization. IDEF3 was designed to [1]: • Collect, describe, store, manage, and reuse process information. • Be used in engineering, manufacturing, logistics, business systems and even government operation areas. • Model a small- and large-scale system at both high abstract and high detailed levels. • Be integrated with other IDEF methods. • Be easy to learn and use by stakeholders. Benefits of IDEF3 are cost savings, time reducing, quality improvement, organizational capability improvement, and continuous improvement of organizational mechanism and business process. IDEF3 has been used to [1]: • Identify business processes in various areas. • Provide an implementation-independent specification for human-system interaction. • Define business process management and change management. • Document the decision procedures of an enterprise or a government department. • Be a useful interview supporting tools. • Develop real-time control software by providing a mechanism to clearly define facts, decision points, and job classifications. • Define the behavior of workflow management systems and applications. 160 8 IDEF3 Process Capture Method

• Design new processes rapidly. • Speed the development of high quality IDEF0 function models. • Speed the development and validation of simulation models. • Find redundant and/or non-value-added activities for business process optimization. • Support Business Process Re-engineering and continuous process improvement. There are several versions of IDEF3 [1, 2, 3] with distinct syntax and semantics. The latest version introduces concepts on object from IDEF5 Ontology Capture. Following introduction is based on the latest version technique report. IDEF0, IDEF1X and IDEF3 are the three main modeling methods in The IDEF modeling family. They are respectively function oriented, data oriented and process oriented system design and analysis methods. KBSITM distinguished their purposes, concepts and so forth in Table 8.1.

Table 8.1. Comparison among IDEF0, IDEF1X, and IDEF3 IDEF0 IDEF1X IDEF3 What you do What you need to know How you do it Functional dependencies Information management or Precedence and cause-&- database design eﬀect Used to “target” activities Information or data require- Reduce cycle time that need improvement ments A modeling method Analysis method/design A description method method

8.2 Syntax and Semantics of IDEF31

IDEF3 uses a series of concepts, symbols, and rules for business process descriptions. It also provides a mechanism to develop and optimize models for business process analysis and management.

8.2.1 Basic Concepts of IDEF3

An IDEF3 process model describes the events network in a scenario. IDEF3 descriptions include two diﬀerent views: Process Centered View and Object Centered View. They are cross-referenced to each other to represent complex process descriptions. Scenario is the key concept of IDEF3 and is used as the basic organizing framework for IDEF3 Process Descriptions. A scenario is a set of situations that describe a typical kind of problems, or the environment that a

1 The structure, content, and examples of the section reference the technical report “Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report” by KBSI. 8.2 Syntax and Semantics of IDEF3 161 process occurs. Scenarios establish the focus and boundary conditions of a description. Using scenarios, stakeholders can describe what they know on an ordered sequence of activities within the context of a given scenario or situation. Scenarios also help to organize process-centered knowledge. The primary role of a scenario is to form the context of an IDEF3 Process Description [1]. Scenario names often take the form of a verb or verb phrase and a verb that functions as a noun. An IDEF3 Process Description is developed based on two strategies: process-centered strategy and object-centered strategy. The process-centered strategy focuses on processes and their temporal, causal, and logical relations within a scenario. The object-centered strategy focuses on objects and their state change behavior in a single scenario or across multiple scenarios [1]. Both strategies use the basic elements of the IDEF3 language, as shown in Fig. 8.1. An IDEF3 Process Description may contain zero or more process diagrams and zero or more object diagrams. The scenario concept is used to organize both the process-centered and object-centered views.

8.2.2 Process Diagram

Process diagrams are the most familiar and widely used components of the IDEF3 method. These diagrams provide a visualization mechanism for process-centered descriptions of a scenario. The graphical elements of process diagrams include Unit of Behaviors (UOBs), precedence links, junctions, referents, and notes. Referents and notes provide associations between process diagrams and object diagrams. (1) Unit of Behavior A UOB describes a type of situation or activity. Its instance is an occurrence of the UOB. When one captures “what’s going on” in a given system, that does not mean what in fact happened in the system at particular time, but rather what happens in general that can occur again and again in the system [1]. A process description represents the types of situations (processes, functions, etc.) that can occur in the system and the logical and temporal constraints that combine them together [1]. A UOB is represented by a special kind of box with a unique label, as shown in Fig. 8.1. (2) Link A link is the glue that connects UOBs to form representations of dynamic processes. A link is drawn to start or end on a UOB or junction symbol. There are two basic types of links used in IDEF3 process diagrams: precedence link and dashed link. Precedence links describe temporal precedence relations between instances of one UOB and those of another. They are the most widely used link and 162 8 IDEF3 Process Capture Method

Fig. 8.1. Symbols used for IDEF3 8.2 Syntax and Semantics of IDEF3 163 are denoted by a solid arrow, sometimes with an additional marker attached to the stem of the arrow, as shown in Fig. 8.1. Dashed links carry no predefined semantics. They are often used as user- defined links or relational links. This type of link points out a possibly constraining relationship between two UOBs [1]. All links have an elaboration and unique link numbers. Displaying link numbers on the process diagrams is optional [1]. PL (for “precedence link”) and DL (for “dashed link”) are prefaced for Precedence links and Relational links. Link numbers are assigned sequentially. (3) Junction Junctions provide a mechanism to define the logic of process branching. They simplify the capture of timing and sequencing relationships between multiple process paths. IDEF3 diagrams involve four kinds of branch points [1]: • Points at which a process branches into multiple parallel sub-processes; • Points at which a process branches into multiple alternative sub-processes; • Points at which multiple parallel sub-processes join into a single line; • Points at which multiple alternative sub-processes join into a single line. IDEF3 includes four general types of junctions to express the four general kinds of branch points. The first two kinds are expressed by fan-out junctions: Conjunctive fan-out junctions represent points of branch involving multiple parallel sub-processes, while disjunctive fan-out junctions represent points of branch involving multiple alternative sub-processes. The last two kinds of branch points are expressed by fan-in junctions: conjunctive fan-in junctions represent points of convergence involving multiple parallel sub-processes, while disjunctive fan-in junctions represent points of convergence involving multiple alternative sub-processes [1]. There is one type of conjunctive junction, or AND junction, indicated by “&”. There are two types of disjunctive junctions: inclusive and exclusive junctions, or OR and XOR junctions. The classification of junctions is described in Fig. 8.2.

Fig. 8.2. Classiﬁcation of junctions 164 8 IDEF3 Process Capture Method

A fan-out AND junction means that there will be UOBs that are (immediate) successors of the junction. If a synchronous AND junction is used, then, those UOBs must all start at the same time. Similarly, the meaning of a fan-in AND junction is that there will be UOBs that are (immediate) predecessors of the junction. And if a synchronous AND junction is used, then, those UOBs must all end at the same time [1]. Junctions represent branch points in a general process as shown in Fig. 8.3. To make unambiguous references to the junctions, junction reference numbers are attached near relative junctions, which start with the letter J. Two distinct junctions have diﬀerent junction numbers.

Fig. 8.3. Precedence links connecting to junctions

(4) Referent Referents enhance understanding, provide additional meaning, and simplify both process and object diagrams. Referents may be used in IDEF3 process and object diagrams to do the following [1]. • Refer to a predefined UOB without duplication of its definition. • Transfer control or indicate a loopback in the processing. • Form references or links between the process diagrams and object diagrams (5) Decomposition The IDEF3 method allows users to describe processes at various levels of abstraction by decomposition, which can provide a more detailed description of a UOB. The decomposition diagram follows the same syntax and semantic rules and uses the same IDEF3 elements. A UOB can have any number of different decompositions, which represent different viewpoints relating to the UOB, all at the same level. Each view is presented in a separate decomposition with a unique label and number as shown in Fig. 8.4. A UOB box number is assigned to each UOB. The UOB number consists of three distinct numbers separated by dots. The leftmost number is the rightmost number of its parent UOB. The middle number is the number assigned to the particular decomposition of the parent box. The rightmost number is simply the UOB’s sequence number. The UOB number displays a UOB’s sequence number, the decomposition to which it belongs, and its parent UOB sequence number. The assignment of reference numbers is shown in Fig. 8.5. 8.2 Syntax and Semantics of IDEF3 165

Fig. 8.4. An example of decomposition

Fig. 8.5. UOB numbering method

8.2.3 Object Diagram

IDEF3 Object diagrams capture, manage, and display object-centered descriptions of a process – that is, information about how objects of various kinds are transformed into other kinds of things through a process, or how objects of a given kind change their states through a process [1]. In IDEF3, an object is any physical or conceptual thing. Object names are nouns or noun phrases. Fig. 8.6 represents an example of object transition diagram. A certain kind of object being in a certain state is represented by a circle with a label that captures both the kind itself and a corresponding state, thereby representing the type (or class) of objects that are in that state [1]. The ﬁrst step to develop an object diagram is to identify the possible 166 8 IDEF3 Process Capture Method

Fig. 8.6. An example of object transition diagram states. An object diagram focuses on distinguished states for particular purposes. The transition arc (with an arrow style head) connecting the circles represents a state transition, the activity of changing from one state to another. Referents are linked to the arrows and describe the relationships between objects states and UOBs, scenarios, or other transition diagrams that participate in a scenario occurrence. The relative positioning of referents on the transition diagram indicates the order in which they occur. The transition junctions containing an “X” (for exclusive or) indicate the choice of exactly one path among several possible paths in an occurrence [1].

8.3 Structured Approach of IDEF3

Similar to IDEF0 and IDEF1X, the team members’ roles involved in IDEF3 models development are as follows [1]: • Analyst: An IDEF3 expert who is the author of the IDEF3 description. The analyst relies on the domain expert for the technical content of the description, during both description capture and the kit review cycle. • Reviewer: All personnel who review the IDEF3 kit. • Commenter: A commenter is knowledgeable in the application domain, and proficient enough in IDEF3 to offer structured comments in writ- ing. The commenter reads the material prepared by analysts and verifies its technical accuracy, so as to find errors and suggest improvements in the IDEF3 process description. The commenter determines whether the purpose has been achieved, and whether errors or oversights exist. The commenter writes down suggestions or comments during the review process. 8.3 Structured Approach of IDEF3 167

• Reader: IDEF3 kits are distributed to readers for informational purposes only. • Librarian: A librarian maintains files of project-related documents and description artifacts, makes copies, distributes IDEF3 kits, and keeps records. • Project manager: The leader of the model development project who con- trols the operation direction of the project. • Technical committee: A working group to overcome barriers of the modeling task. The procedure of IDEF3 models development includes [1]: (1) Define purpose and context The purpose and context are recorded on the IDEF3 process description summary form. The analyst identifies candidate scenarios and prepares an IDEF3 scenario pool. The contents of this pool will be refined and maintained throughout the lifecycle of the project. (2) Collect data The analyst collects original data for modeling task. The most valuable mechanisms for this data collection are interviews and enterprise management documents reviews. (3) Develop process diagrams Once the identification of objects, activities, facts, and constraints is finished, the IDEF3 process diagrams will be formulated. The original data from the interviews are used as the basis for the process diagram development. Developing a process diagram will construct UOBs in correct sequence and develop UOB elaborations. • Layout initial process diagram The process of identifying the UOBs and specifying the precedence between them occurs in several steps. – Identify the leftmost UOB in the process description. – Identify the next UOB. – Develop first path. – Complete the remaining paths and join paths together with junctions. – Adjust the originally finished diagram. • Develop elaborations After the initial process diagram has been completed, elaborations must be added to each UOB. (4) Develop object diagrams To provide a detailed characterization of the objects that participate in a process, it is necessary to develop object diagrams. Object diagrams provide an object-centered view of the process. Object diagrams are most often developed after the process diagram; however, some users find it easier to begin with the object diagram. • Select objects The first step in developing an object diagram is to select the object or objects of interest. 168 8 IDEF3 Process Capture Method

• Identify object states Having determined the main object, the analyst begins to develop the object diagram by identifying candidate object states. Identifying the possible state changes in a process often requires that the analyst work with domain experts [1]. • Layout initial object diagram The process of constructing the identified object states into a transition diagram is [1]: – Identify the initial, or leftmost, object state in the diagram. – Identify the next state or states to which the object can transition. – Repeat above two steps until all the possible state transitions are identified. It is generally helpful to identify and document one transition path at a time before attempting to develop a diagram illustrating all possible paths. – Combine the paths into a single diagram by introducing the appropriate logical junction(s). – Once the possible paths have been identified and integrated to reflect alternative state transition paths, referents for participating UOBs, scenarios, and other transition diagrams will be identified and attached to appropriate points on the diagram. • Develop elaborations Once the initial transition diagram is completed, elaborations must be added. (5) Review IDEF3 diagram The correctness of the process diagram, the object diagram and associated elaborations are confirmed through validation with the domain expert. The IDEF3 kit review cycle keeps the same as that of IDEF0. If there are arguments that cannot get a tradeoff, the project manager will make the decision, or a technical committee meeting will be held to overcome the problem.

References

[1] Mayer R J, Menzel C P. Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report. KBSI Co., 1995. [2] Knowledge Based Systems Laboratory, Texas A&M University. IDEF3 Tech- nical Report, Version 1.0. NASA-CR-190279, 1990 [3] Knowledge Based Systems Laboratory, Texas A&M University. IDEF3 Tech- nical Report. AL-TR-1992-0057, 1992