O?oh-4379’8’ $3.00 + .a0 C l‘i8.c Pergamon Press Ltd.

A METHODOLOGY TO MODEL THE DYNAMIC STRUCTURE OF AN ORGANIZATION

RALPH R. BRAVOCO and SURYA B. YADAV College of Business Administration, Texas Tech University, Box 4320, Lubbock, TX 79409.

U.S.A.

(Received 10 f)ecember 1983: in revised form 3 October 19&t)

Abstract-The Integrated Computer Aided Manufacturing (ICAM) program of the U.S. Air Force identified a need to better coruscate and analyze manufactu~~g for the people involved in improving productivity. To satisfy that need, the ICAM program developed the IDEF (ICAM Definition) method to address particular characteristics of manufacturing. This IDEF Method is equally applicable in analyzing other types of organizations.

IDEF comprises of three modeling methodologies: function model methodology (IDE&,), infor- mation model methodology (IDEFi) and dynamics model methodology (IDEFa). This paper reports on the dynamics model me~~oiogy only. This rne~~olo~y is used to construct models which help in underst~~ng the Dynamic (time-varying behavior) structure which the functions of an organization exhibit.

Keywords: Information Reauirements. Modeline an Organization, Dynamic Structure of an Organi- zation. Requirements Analysis.

1. IhTRODUCT’tON

Literature on systems analysis suggests that a high percentage of design errors in contemporary com- puter-based i~ormation systems can be attributed to the lack of understanding of an organization to be supported by the information system. The rea- son is that the lack of underst~ding results in in- correct, inconsistent and unclear requirements for a system which in turn results in a faulty design of the system. This suggests that one must try to de- termine a correct and complete set of requirements before embarking on the design of a system.

This paper is based on the authors’ contention that (1) the understanding of an organization is the key for arriving at a correct and complete set of requirements[ 171. (2) The need for underst~ding an organization for the effective development of an information system has been widely recognized[l, 2, 10, 11, 131, but not well formalized. (3) Under- standing an orgamzation is a difficult task.

In undersizing an org~ization one is con- fronted with the following three major issues:

The understanding of an organization is diffi- cult because of its inherent complexity and size. One tackles complexity by modeling an organization in such a way that one can study part of the organization at a time while not los- ing the overall context. This warrants a step- wise refinement approach to modeling. The lack of formalism in describing an organ- ization leads to ambiguity and inconsistency, The problem is compounded for large organi- zations where a group of people work together to understand and determine requirements. A formal notation to describe and understand an organization minimizes the problems of com- muncatio~, inconsistency and ~biguity.

3. One has to deal with several organizational var- iable in understanding and determining require- ments for an organization. These variables are org~ization~ goals, strategies, structures and processes. The function of a user has to be seen in the context of an organization set upll?].

To resoive these issues we present a method- ology which inciudes techniques to model an object system formally. (An object system is an organi- zation or a part of it.) Formal models are very useful for doing further analysis to see if the description of an organzation is complete and consistent. Com- pleteness refers to the fact that none of the required functions are left out or incompletely specified. In- completeness may force designers to resort to as- sumptions which often prove to be incorrect. In- consistency refers mainly to the fact that parts of the document give different specifications. Such contradictions render the document incorrect. The methodology, presented here, helps develop models using well-defined and rigorous techniques. These models, because of their formal nature, can be analyzed to discover incompleteness and incon- sistency in their descriptions.

Recently there has been several efforts to de- velop methodologies to model an object system. It appears that Langeforsill] was the first who rec- ognized the need for modeling an organization to determine requirements. Since then several meth- odologies such as SADTIf23, ISACI91, BSPl71, BIAIT161, MILLER[llI and YADAVIISJ, etc., have been developed. Most of these methodologies, however. take only a partial view of an object sys- tem and invariably this view is the functional model and/or the data model of the system. This partial view provides only an incomplete understanding of a problem especially for the designer. We assert

299

300 R. R. BRAVOCO and S. B. YADAV

that one needs to look at an object system from at least three different but related viewpoints in order to get a complete understanding of the object sys- tem. These viewpoints are functions, data and dy- namics of an object system. These three viewpoints give rise to three different models. These models are:

1. Functional model, 2. Information model, and 3. Dynamics model.

A functional model helps us in understanding the activities and their inte~elationships within an ob- ject system. An notation model helps in under- standing the structure of information to be required by the object system. A dynamics model shows the behavior of functions and information interacting over time.

In this paper we outline a methodology which provides techniques to look at an object system from three different viewpoints. This methodology is known as IDEF meth~ologyrl41.

IDEF (ICAM Defmition) technique is a set of modeling methods which is currently being devel- oped and used by the U.S. Air Force on its ICAM (Integrated Computer Aided Manufacturing) Pro- gram. The goal of ICAM is to cut costs on aerospace products by increasing industry productivity. To accomplish this goal, the Air Force is sponsoring a multiyear program to develop automated manufac- turing systems and to disseminate these systems to the aerospace manufacturing industry.

In order to develop systems in an orderly, con- trolled manner, the ICAM hogram Office has rec- ognized the need to employ structured methods to better understand an object system. The entire set of methods has been namded IDEF, and each in- dividual method has been given a chronological subscript as it is developed and added to IDEF.

To date, there are-three such IDEF methods:

IDEF,, (function model methodologylO

IDEF, (information model methodology)141

IDEFz (dynamics model methodology)

The three IDEF methods, ~~0~~ different in constructs, are used in the following set of inte- grated steps to totahy model an organization:

Step 1

Modeling Task Develop a function model of the organi- zation’s current environment (IDEFo, “As-is model”) Develop an isolation model of the or- g~iza~on’s current env~onment (IDEFi , “As-is model”) Compare the function and information models developed in steps 1 and 2 and make them consistent

The roots of IDEFz were developed by Pritsker & Associates and Higher Order Software, Inc. who were, at different times, the IDEFz development task leaders working for Soffech, Inc., the IDEF methodology prime contractor for the Air Force. In addition to the principles stated above, the final form of IDEFz included technical contributions from Boeing Computer Services, Northrop Corp., and Hughes Aircraft Co. The methodology was used and validated at Northrop Corporation’s Mar- iposa Facilityll61.

1.2 Objective of IDEF: Utilizing the consistent IDEFo and IDEF, The problems facing manufacturers continue to “As-is models” developed in step 3 de- grow in size and complexity. Tools, equipment and

velop IDEFt “As-is” dynamic models to portray the organization’s time varying behavior From the IDEFo.i,Z “As-is models,” state- of-the-art te~~olo~, and the organiza- tion’s ideas of their future needs develop a function model of the organization’s fu- ture environment (IDEFo “To Be” model) From the IDEFo,i,2 “As-is models,” state- of-the-art technology, and the organiza- tion’s ideas of their future needs develop an information model of the organization’s future environment (IDEF, “To Be” model) Compare the function and information models developed in steps 5 and 6 and make them consistent Utilizing the consistent IDEF, and IDEF,, “To Be” models developed in step 7 de- velop IDEFz “To Be” dynamic models to portray the organ~ation~s time varying behavior

. . Utdtze the IDEFo.i.2 “To Be” models to develop the computer based information systems for the organization’s future environment

The abovestated process gives one a complete description of the organization in that the current environment is modeled, the future environment is modeled, and both environments are integrated. The process gives one a consisient description in that the three IDEF models are integrated in both the “As-is” and “To Be” environments and the “To Be” models are developed from the “As-is” models. The process also gives one a correct de- scription in that each model and their integration to each other follow formal rules of review and ap- proval that is part of the IDEF modeling technique. In this manner correct means agreed to be rig& as compared to the formal definition of correct.

The remainder of this paper discusses IDEFz only. These modeling methods have been proven equally applicable to other types of industries for understanding and determining their requirements.

I. 1 Origins of IDEFz

Dynamic structure of an org~~zation 301

management systems are more sophisiticated, often involving a computer to perform their functions. As a result, a personnel with specialized training are required to operate the equipment, and complicated manufacturing procedures must be defined. In ad- dition. natural resources are less available, and manufactu~ng is constrained by the limited supply and expense of raw materials. Increases in tech- nology and decreases in natural resource availabil- ity are only two causes for increased complexity in manufacturing. There are many others, all of which result in new, large, and complex problems which have created a need for new procedures and tech- niques such as modeling for understanding and solving m~ufactu~ng problems.

IDEF2 is a methodology which has been de- signed to allow one to describe the time-varying behavior of manufacturing systems in such a way that the descriptions can be analyzed using com- puter simulation to generate measures of manufac- turing system performance. System models which generate measures of system performance can be used to make better decisions regarding real systems.

It is important when building an IDEFz model to clearly and explicitly define the problem, mod- eling objectives, modeling purpose and the mode- ler’s viewpoint. Then the boundaries of the system and level of modeling detail are established based

on the purpose and objectives. A schematic of this approach to modeling is shown in Fig. 1.

To develop a good model it is essential that the modeler also understand the structure and opera- ting rules of the system in order to extract the es- sence of the system without including unnecessary detail. The amount of detail included in a model should be based on the modeling purpose and ob- jectives. and only elements which could cause dif- ferences in decision making should be considered. The definition of level of modeling detail involves the definition of model elements, the specification of modeling assumptions, and the definition of model element interactions.

An IDEFz model can be employed in five ways depending on the modeling purposes:

As an explanatory device to define a system or problem; As a communications vehicle to determine system elements, components or issues; As a documentation medium: As a design assessor to synthesize and eval- uate proposed solutions to problems: As a predictor to forecast and aid in pIanning future developments.

The first three of these uses of IDEF2 models em- phasize their use as descriptive tools, while the sec- ond two emphasize their use as analysis tools. As a descriptive tool. an IDEF2 model is used to iden-

SYSTEM

OF DETAIL

MODELER VIEWPOINT

Fig. 1. Approach to model building.

302 R. R. BRAVOCO and S. B. YADAV

tidy the components of systems which affect or cause a system’s behavior to change over time. A clear and complete understanding of the behavior of an existing system is essential in developing good solutions to existing problems. In addition, a com- plete description of new systems early in their de- sign will help ensure a successful new system. IDEFz provides a structure and syntax which will aid in acquiring an accurate understanding of sys- tem elements and their operation.

The last two uses of IDEFl emphasize the use of IDEFZ models as analysis tools. Once an IDEFz model of a system is built, one can experiment with the model via simulation to draw inferences about the real system. There are several advantages to this type of modeling. First, a proposed system de- sign may be evaluated in terms of its expected per- formance without actually building the system. Sec- ond, one may experiment with existing systems without disturbing the systems, incurring unnec- essary costs or creating unsafe conditions. Thirdly, a system’s limit or capacity may be determined without destroying the system. Thus modeling can be used for design, procedural analysis, and per- formance assessment.

Manufacturing systems can be viewed and mod- eled in many different ways. IDEFo views a system as the set of functions it performs. Alternatively, IDEF, views a system by studying information it contains. IDEF- on the other hand views the time- varying behavior of a system. These three views of systems are not contradictory but are complemen- tary.’ Each view provides a modeler with a tool to focus on a particular aspect of a system according to his needs and modeling purpose.

In IDEFz a modeler has the capabilty to describe the elements of manufacturing systems which vary over time or cause other elements to vary over time. In order to characterize the time-varying behavior of systems it is first important to describe those elements which change over time.

Some of these elements are represented by IDEF,, and IDEF,, although their behavior over time is not. Consider the functions performed by a system which are described by IDEFo. While IDEFo focuses on the static aspects of these func- tions, they also have dynamic aspects. For exam- ple, each activation of a particular function takes a specific amount of time to complete. In addition, if all inputs, controls, and mechanisms required for an activation are not present then the function would have to wait until they become present. Thus, while IDEFo does not describe it, there is time-varying behavior associated with the functions performed by a system. IDEFz can represent this time-varying behavior.

Also consider the information required to sup- port a system which is characterized by IDEF,. While IDEF, focuses on the static aspects of in- formation, there can be variation over time of the information itself or in the relationships between

various types of information. These dynamic as- pects of information are not represented in IDEF, , but can be characterized using IDEFz.

As part of the overall objective, IDEFz is to rep- resent a wide class of manufacturing systems. The methodology was designed to allow a modeler to represent the dynamic aspects of: hardware sys- tems such as production lines or group technology cells; software systems such as part program gen- eration for computer-controlled robots; or com- munications systems and procedural systems such as design processes or shop order release systems. In addition, IDEFz allows the representation of these systems at any level of detail desired. High- level models may aggregately represent activities and decisions as a single activity while models at a lower level of detail will explicitly represent each activity and decision.

In addition to allowing one to represent many types of manufacturing systems, IDEF2 was de- signed to allow one to solve various types of man- ufacturing problems including scheduling, capacity planning, inventory management, raw material re- quirements planning, quantity control program as- sessment and capital investment analysis.

The IDEFz methodology fulfiills several needs within the life cycle of system development de- scribed by the ICAM System Development Meth- odology[5]. IDEFz can be used in the requirements definition step, the preliminary design step, and the detailed design step of system development. Within the requirements definition step, IDEF2 provides a framework and syntax in which a modeler can de- scribe the time-varying aspects of the AS-IS (IDEFo, IDEF, models) manufacturing system. The process of describing the time-varying behavior of the AS-IS system is an important step in the de- velopment of a TO-BE (IDEFo, IDEF, models) sys- tem because it forces system designers to detail the operational elements of the AS-IS system. Thus, the task of developing an IDEFz model will force designers to consider the details of the current sys- tem before considering any new structures for the TO-BE system. An AS-IS IDEFz model can then be validated via simulation to ensure that the IDEFz model performs as the real system does. This val- idation will ensure that the system designers have an accurate perception of problems associated with the AS-IS system before attempting to alleviate them in the TO-BE system design.

In addition to its applicability in the require- ments definition step, IDEFz will also be useful in the preliminary design step of system development. Within the preliminary design step IDEFz models of design alternatives are built to evaluate the ef- fectiveness of the TO-BE system high level design alternatives. These IDEFz models aid in determin- ing and quantifying system design alternatives. These IDEFz models aid in determining and quan- tifying system design problems early in the devel- opment of the systems. Potential problems which

Dynamic structure of an organization 303

can be identified include inadequate throughout, processing bottlenecks and high in-process inven- tories. In addition, performance/cost tradeoffs and capability/cost tradeoffs can be made. In this man- ner IDEFz can be used to make tradeoffs with re- spect to cost, time and technology. After building IDEFz models of various design alternatives and performing tradeoff studies, the modeler or de- signer will choose the design which appears most promising. Thus, the selection of the “best” overall design and the initial performance testing of this “best” design could also be performed with an IDEFz model.

Within the detailed design step of system de- velopment, the IDEFt model of the best high-level design developed in the prelimin~ design step is expanded to in&de the details developed in the detailed design step. The modeler can us the IDEF- model to evaluate alternate detailed system designs including new algorithms or operating rules which will govern the TO-BE system. The detailed IDEFz model allows the modeler or designer to determine the details of system operation as well as the cost of system operation. Therefore, in the prelimin~y design phase the components of the system and their costs are identified while the operating rules and associated costs are determined in the detailed design phase. Thus, using IDEFz, a system designer will have some assurance by the end of the detailed design step that the TO-BE system will indeed per- form as desired and meet the needs of its users.

2. IDEFz BASIC CONCEPTS

A manufacturing system produces products and information based on orders and requests subject to rules, procedures and the availability of raw ma- terials, facilities, material handling equipment. manpower, and machines. To describe a manufac-

turing system in IDEFz, the manufacturing system is decomposed into four submodels as shown in Fig. 2. An IDEFz model consists of a Facility Submodel, an Entity Flow Submodel. a Resource Disposition Submodel and a System Control Submodel.

The IDEFz Entity Flow Submodel is the mean by which the flow of products or i~ormation through facilities is described. An entity may be real or conceptual. Examples of entities are products or information which are operated on or produced by the system being modeled. It is in the Entity Flow Submodel that the actual processing of products or information is described. The activities which are performed as well as the decisions regarding alter- nate flow of entities are also described.

The IDEFz Resource Disposition Submode is used to describe the disposition of resources when they become available. A resource in IDEFz is any part of the system which must be present to perform an activity. The IDEFz modeler uses tree structures to ask questions concerning the status of the system and to specify what actions should be taken with respect to the available resource.

The System Control Submodel describes the oc- currences of activities which control but do not pre- scribe the flow of entities. Situations handled by System Control Submodels include the breakdown and repair of resources, the arrival of entities, the alteration of resource capacities, the initiation and termination of shifts and the alteration of job priorities.

The IDEFz Facility Submodel describes the re- sources which are used by the system to produce the final products or information. These resources may be physical, logical or cognitive. Physical re- sources are any physical components of systems such as people, machines and materials. Logical re- sources are any logical components of systems which determine their operation, such as computer

15EF2

MODEL

OF A

MANUFACTURING SYSTEM

ENTITY RESOURCE SYSTEM FACILITY FLOW 5ISPOSITION CONTROL SUBMODEL SUBMODEL SUBHODEL SUBMODEL

Fig. 2. IDEFz manufacturing system decomposition.

304 R. R. Ba~voco and S. B. YADAV

+ It t, !ifa ** DYNAMICS MOOEL OF S

MEASURES OF SYSTEM

+ &

low2 htGOE& IO& ANNY!3S SOFTWARE

YSTEM

PERFORMANCE

Fig. 3. Describe and analyze manufacturing system dynamics.

software or manufacturing procedures. Cognitive The building of IDEFz models will follow a resources are those resources which are required slightly different procedure than that used for build- for thought processes, such as experience and crea- ing IDEFo and IDEF, models because the goals of tivity. Because one is allowed to utilize any stan- building an IDEFz model is to anaiyze as well as dard facility modeling technique such as a Flow. describe the dynamic behavior of a m~ufactu~ng Planning diagram[l5], we will not discuss Facility system. Submodel in this paper. An IDEFo model of the use of IDEFz to DE-

10EFl CI

Mcthodology-rr,

c3 Modalinq Objectivaf

Ml M2

sot- TITLE: A0 OESCRIEE AND ANALYZE MANUFACTURING SYSTEM DYNAMIC

NUMBEA-

I

Fig. 4. Describe and analyze manufacturing system dynamics.

Dynamic structure of an organization 305

Cl Cl yrt*m nforlnation f.

DETERMINE

-_ BUILD DYNAMICS MODEL

I ,

Fig. 5. Build IDEF2 model.

SCRIBE AND ANALYZE MANUFACTURING SYSTEM DYNAMICS is shown in Figs. 3-5. The A-O diagram is shown in Fig. 2. The input to the function DESCRIBE AND ANALYZE MANU- FACTURING SYSTEM DYNAMICS is SYSTEM INFORMATION. This includes all the data re- quired to structure, support, and validate an IDEF2 model. The things which control the DESCRIBE AND ANALYZE activity are the IDEFz METH- ODOLOGY, MODELING OBJECTIVES, and STATISTICS. The IDEF, METHODOLOGY and the MODELING OBJECTIVES will be used to build the IDEK MODEL of the system. The MOD- ELING OBJECTIVES and STATISTICS control the analysis of the IDEFl model. The mechanisms used to perform this function are the IDEFz MO- DELER and IDEFz ANALYSIS SOFTWARE (to be described in future papers). The outputs of the DESCRIBE AND ANALYZE function are the DY- NAMICS MODEL OF SYSTEM and MEASURES OF SYSTEM PERFORMANCE. The MEAS- URES OF SYSTEM PERFORMANCE will be the result of analyzing the IDEFz model.

Figure 4 contains the A-O diagram of the func- tion DESCRIBE AND ANALYZE MANUFAC- TURING SYSTEM DYNAMICS. This function breaks down into four subfunctions at this level: BUILD DYNAMICS MODEL, VALfDATE MODEL, DESIGN ANALYSIS EXPERIMENT, and PERFORM ANALYSIS OF DYNAMICS MODEL. All of the inputs, controls, mechanisms and outputs from the A-O diagram are shown in this diagram as they affect the subfunctions of the

function DESCRIBE AND ANALYZE MANU- FACTURING SYSTEM DYNAMICS.

Figure 5 illustrates the subfunctions of the func- tion BUILD DYNAMICS MODEL. The first step in building a DYNAMICS model is to DETER- MINE DESIRED PERFORMANCE MEAS- URES. That is, determine what measures of per- formance are used to judge the ability of the real system to perform its job. These performance meas- ures then control the dete~nation of system boundaries. When modeling a system with IDES, all details concerning a manufacturing system are not represented. Only those which could affect the dynamic behavior of the system are included. Once the system boundaries are defmed, they are used with the desired performance measures to deter- mine the DATA REQUIREMENTS for the DY- NAMICS model. These DATA REQUI~MENTS contro1 the COLLECT REQUIRED DATA func- tion whose input is the raw SYSTEM INFOR- MATION which includes other IDEFo,, models, if available and whose output is the data required for IDEF2 modeling. Next the MODELING OBJEC- TIVES, DESIRED PERFORMANCE MEAS- URES, IDES METHODOLOGY, and RE- QUIRED DATA for modeling are used to build the graphic portions of the DYNAMICS submodels. If additional data is required to build the graphic por- tions of the submodels then additional data must be collected. The REQUIRED DATA for modeling and the IDEFl METHODOLOGY are used by the function SUPPLY SUPPORTING INFORMA- TION to produce the DATA FORMS WITH SUP-

306 R. R. B~~vocoand S. B. YADAV

Fig. 6. IDEFl diagram of dynamics model building information.

PORTING INFORMATION which join with the GRAPHIC DYNAMICS MODEL to produce the complete DYNAMIC MODEL. If all required data is not available to SUPPLY SUPPORTING IN- FO~ATION then additions data may need to be collected.

Figure 6 contains an IDEF, diagram which de- scribes the information characteristics of a DY- NAMICS model. In building a DYNAMICS model the MODELING PURPOSE is used to determine the MODEL OBJECTS as well as to determine the PERFORMANCE MEASURES. PERFORM- ANCE MEASURES are also determined by the MODELER’S VIEWPOINT. The MODEL BOUNDARIES and MODELING OBJECTS gen- erate DATA REQUIREMENTS which are satisfied by SYSTEM DATA. The SYSTEM DATA is then used to build the DYNAMICS MODEL which is scoped by the MODEL BOUNDARIES.

There are several advantages to the abovestated approach. Fist, by breaking a large system down into smaller components attention can be focused on a few details at a time. In this manner, large projects can be divided among several modelers or sequential modeling can be performed. Second, the data collection for large systems will be simplified because procedures can be developed which or- ganize and structure the data in the same way the submodels are structured. Third, the diftlcult sta- tistical and modeling concepts are segregated from the description of entity Sow. Modelers are not re- quired to use difficult statistical and modeling con- cepts. A fourth advantage to the decomposition ap-

proach is that certain submodels could potentially be used with different types of analysis mecha- nisms. For example, the Facility Submodel could potenti~ly be used for plant layout analysis as well as for simulation analysis. A fifth advantage to the decomposition approach is that certain submodels may be standardized and used in several IDEFr models without requiring that they be redeveloped. This decomposition approach to dynamics model- ing results in structured data collection and mod- eling efforts.

2.1 Fundamental concepts of IDEFz Each of the submodels within an IDEFt model

contains a graphical component and supporting documentation contained on forms. The graphical components of these submodels each have a symbol set designed to facilitate their construction in a straightforward and understandable manner. The following paragraphs describe the respective sym- bologies for the Entity Flow Network, Resource Disposition Trees, and System Control Networks, the graphic components of the three IDEF* sub- models covered in this paper. The section is con- cluded with a discussion of the supporting docu- mentation required to support each of these graphical tools.

2.1.1 Entity _flow network. An Entity Flow Net- work is a graphical network representation of all possible paths an entity can take in flowing througb a system along with the resources that are required for passage through the system. Each entity flow path represents a sequence of activities. Arrows are

Dynamic structure of an organization

PART BEING

ARRlViNG PART

OUEUE OF PARTS AWAITING DRILUNG OPERATION

DRILL COMPLETED PART

Fig. 7. A schematic of a simple production system.

307

used to gra~~ic~1~ portray activities. Nodes are used to separate activities and represent the deci- sion elements, queues, and milestones associated with the modeling of entity movement through a system.

An entity is something that forms an important part of the real world being modeled. Entities may be either real or conceptual. ExampIes of real en- tities are parts, jobs, and materials. Examples of conceptual entities are ideas, requests, and pieces of ~fo~ation. Entities have ch~acte~sti~s that are referred to as attributes. Example attributes of the entity “part” are its number, class, lot number, and priority, The concept of entities within IDEFl is consistent with the IDEFl definition[4].

IDEFz models system behavior by examining the manner in which entities flow through the sys- tem. and the reaction of the system to entity flow. For example, a part is said to flow along a produc- tion line as operations are carried out on it. If the production line is the system being modeled, the parts produced can be seen as entities flowing through the system. The IDEF2, activities in which entities engage are represented with arrows. The arrows are separated by nodes.

Each entity flows over the network and each may have a different route as branching from nodes can occur probabi~sti~~y or ~ondition~iy. Also, rules (procedures) are specified to select from among competing elements such as parallel queues and servers, alternative resources, and subordi- nates activities. If two different entity types require exactly the same processing they might have iden- tical Entity Flow Submodeis. However, if their flow through the system depends on the entity type, a separate Entity Flow Submodel may be required for each entity type.

2.1.1.1 Symb&gy of entity now networks. As an introduction to understanding Entity Flow Net- works, let us consider a simple production system in which parts arrive, wait to be processed, are op- erated on by a single resource (a drill), and depart the system. A schematic of such a system is shown in Fig. 7. In this system, parts arrive requiring a drilling operation. If the drill is free when a part arrives, it is processed immediately, If the drill is inoperative or occupied with another part, the ar- riving part must await service in a queue. As soon

as a part completes processing, the first part waiting in the queue is processed while the completed part exits the system.

The passage of time in Entity Flow Networks is represented by an ACTIVITY, Arrows are the graphical representation of ACTIVITIES. In our example, the drilling operation takes time, and is thus graphically modeled by an arrow. If a part is being drilled when another part arrives, the arriving part must wait until the drill becomes available, Waiting occurs at QUEUE nodes. The figure shown below illustrates the Entity Flow Network repre- sentation of the drilling operation and the location of parts awaiting service.

DRlL~#Q +

M)EUE MODE nRlLL aCTMTY

If another operation succeeds the drilling oper- ation and parts may again wait far processing, the network would look like the one shown below.

DRILLING and BORING are the names of the drilling and boring operations. In IDEFl any re- sources which are required to perform ACTIVI- TIES are shown on Entity Flow Networks. Re- sources are allocated to entities at the beginning of ACTIVITIES and are freed at the completion of ACTIVITIES. The allocation of a resource is ac- ~mp~shed with RESOURCE ALLOCATION nodes, which specify the type and quantity of the resource being allocated. In the network shown here, a single drill is allocated to parts to perform a drilling operation.

308 R. R. %k.~~oand S. B. YADAV

If, at the end of ao ACTIVITY, the resource is NOW consider ‘an ACTIVITY where different no longer required by the part, it is freed via a RE- types of resources can perform the same ACTIV- SOURCE RELEASE symbol. The resource type ITY. An example of this is the case where an AC- being freed and the quantity being released are T&TTY can be performed either manually or with specsed on the symbol, as shown below: automated machinery. Alternative resource sets are

DRILLING

t-

.E I

DRILL f i

1 t

RESOURCE RELEASE SYIWBUL

+

RESOURCE TYPE

OIJANTITY REtEA%t?

Some activities require more than one resource modeled by using adjacent columns of RESOURCE type. The DRILLING ACTIVITY in our example ALLOCATION and RESOURCE RELEASE sym- may require the presence of a human operator in bols as shown in the tigure below. The resource set addition to the drill. If so, another RESOURCE that is selected to perform the ACTIVITY is re- ALLOCATION symbol is used beneath the fmt leased upon completion of the ACTIVITY. The SE- one and another RESOURCE RELEASE symbol LECTGR node will choose the appropriate set of is required at the ACTIVITY’s end. resources to perform the drilling operation based

ORIUlNG

t b

OPERATOR H 1 1 I

I

Resources may remain a&cated to entities for successsive ACTIVITIES. If_ for instance, a single operator can operator multiple machine types, the network shown below may be appropriate. Here, the resource OPERATOR is allocated to a part in order to perform two successive operations. Since he is not released after the DRILLING ACTIVITY, he is assumed to be also required for the milling operation. At the end of the MILLING ACTIVITY, both the MILL and OPERATOR resources are released.

on a selection rule specified by the modeler. SE- LECTOR nodes are used to select between com- peting resources, activities, branches, and queues. In the example shown below, the RESOURCE label indicates that a selection must be made be- tween ahernative resource sets.

BOUNDARY nodes identify locations where entities may enter a network, exit a network, or be transferred to another location within a network. Three types of BOWN~~Y nodes are available to IDEFt madefers: START, END, and GO TO. Add-

Dynamic structure of an organization 309

DENOTES RESOURCE NAME OF NODE SELECTION

ALTERNATIVE RESOURCE SETS

ing BOUNDARY nodes to our last example net- work, we have the network shown in Fig. 8.

2.X.1.2 Summ~. Entities form an important part of the real world system modeled with IDEF>. They may be real or conceptual. Entity Flow Net- works model the flow of entities through manufact- uring systems. They represent the paths entities fol- low through systems and specify the resources required for entity passage. The concepts involved in modeling entity flow are embodied in a set of node types and the graphical representation of ACTIVITIES.

These brief introductory examples were in- tended to briefly expose the beginning IDEF, mo- deler to the concept of entity flow. represented by network elements. Figure 9 presents all the ele-

A Resource Disposition Tree consists of nodes containing QUESTIONS, the answers to which de- termine either the next QUESTION or what AC- TIONS are to be taken on the available resources. In this manner, the leaf nodes of each tree contain ACTIONS to be taken on the available resources.

To iilustrate the use of pertinent QUESTIONS in Resource Disposition Trees, consider the case of a machine that processes parts that queue in front of it. Each time the machine completes a part, the disposition of the machine must be determined. If no parts are awaiting processing, the machine be- comes idle: if parts are waiting, the machine is al- located to the first part in its QUEUE. The Res- source .Disposition Tree for this situation appears below.

ments used in the Entity Flow Networks to allow the reader to better understand their meaning and the modeling concepts they facilitate.

2.1.2 Resource ~is~osiri~~ trees. When a re- source completes an ACTIVITY, its disposition de- pends on the status of the system. That is, it may become idle if no other entities require its attention; it may be allocated to an entity that requires its use to engage in an ACTIVITY; or it may wait for other resources to become available in order to perform an ACTIVITY requiring multiple resources. The decision regarding a resource’s disposition is made via a Resource Disposition Tree.

In this example, the QUESTION “ANY RE- QUESTS?” asks if any requests for the services of the resource are outstanding, i.e. are any parts aw~ting processing? If the answer to this “NO,” the arrow labeled “NO” is taken and FREE AC- TION is specified. The info~ation in the top row of the box states that resources type MACHINE is affected with one unit being freed. If the question is answered “YES,” the arrow labeled “YES” is taken and the action specified is to ALLOCATE one unit of resource type MACHINE to the node named MACHINEQ.

FREE and ALLOCATE are examples of AC-

R. R. B~uvoco and S. B. Y~DAV

Fig. 8. Example entity flow network.

TIONS that may be specified in Resource Dispo- sition Trees. Four types of ACTIONS are available to lDEFz modelers, as shown-in Fig. 10.

Using Resource ~s~si~on.Trees, the analyst can ask questions about the &us of the system in order to decide the disposition of resources. Several typical questions are shown in Fig. Il. If a modeler wants to ask a question that does not appear on the list, he may create questions which better suit his purpose. Most modelers will find. the list presented quite adequate for their modeling needs.

Several rules for p~emption are listed in Fig. 12.

In our example thus far, resources have been allocated to specified nodes. IDES permits re- source allocation to be specified with many allo- cation rules which are listed in Fig. 13.

Consider another example. A tool and die shop makes several types of dies for a fabricating man- ufacturer. Many of the dies are heavy enough to prohibit manual transportation between machine stations. These transfers between stations are ac- complished by a single lift truck which handles all transfer requests with the shop. The Resource Dis- position Tree for this lift truck is shown below.

Upon a “YES” answer to the fust QUESTION, the availability of a driver is examined. If no drivers are free, the truck is FREED. If there is a driver available, TRUCK is assigned to the highest prior- ity job requesting a transfer. Both TRUCK and DRIVER are allocated to that job.

Resource Disposition Trees are used to deter- mine the disposition of resources that have become available. The trees consist of nodes containing QUESTIONS concerning the status of the system, whose answers either specify another QUESTION or the ACTION(S) to be taken on the available re- sources. By combining QUESTIONS and AC- TIONS in the manner illustrated in this section, IDEFz modelers can specify both simple and com- plex resource disposition procedures.

2.1.3 System Control Networks. System Con- trol Networks portray activities or conditions which may affect the status of the system and tlow of entities but do not directly cause entity flow. They can be used to create entities, alter attributes of entities, and to alter the capacity of resources. In general, System Control Networks are used to initiate entity, resource, and facility changes.

The activities or conditions represented in Sys-

ATE

Dynamic structure of an organization 311

REQUIRED OPTIONAL ATTRIBUTES ATTRIBUTES SYMBOL COMPONENT

QUEUE node 1. Identifying name 5. Full condition 2. Ranking rule 6. Selector node priority 3. Maximum capacity 4. Initial number in queue

(--Z-J

RESOURCE NAME El NUMBER REQUIRED

RESOURCE ALLOCATION 1. Resource name symbol 2. Number of units required

RESOURCE RELEASE symbol

ASSIGNMENT node

Resource name Number of units to be released

Identifying name Variable to which an assignment is to be made Value or expression for assignment

l repeats of 2 and 3 .

SELECTOR node

BOUNDARY node

1. Identifying name 2. Selection type 3. Selection rule

3. Inventory shrinkage costs 4. Units cost 5. Unit profit 6. Lost sales cost 7. Inventory carrying cost

NAME

8

BOUNDARY

1. Identifying name 2. Type of boundary

5. Number of entities required for the first node release if it is dierent from “number for release”.

ACCUMULATE node 1. Identifying name 2. Number for release 3. Number of release 4. Attribute save criteria

MATCH node 1. Identifying name 2. Matching attribute

0 NAME ASSEMBLY node

ACTIVITY symbol

BRANCH symbol

1. Identifying name 2. Matching attribute

1. Identifying name 2. Duration

3. Priority ACTIVITY NAME

1. Branch type 2. Conditional expression or

probability

Fig. 9. Attribute specifications of components of entity flow network.

ALLOCATE FREE

PREEMPT ERROR

tern Control Networks are triggered by events; these are happenings, occurrences, milestones, or decisions. Event times are the instants at which the status of the system may change. Immediately prior

Fig. 10. Possible action types for IDES resource dispo- to an event occurrence, it is not possible to predict

sition trees. the future status of the system with certainty.

312

QUESTION

ANY REQUESTS?

ANY SINGLE REQUESTS?

ANY MULTIPLE REQUESTS?

ANY LAST RESOURCE REQUESTS?

ANY RESOURCE REQUIREMENTS SATISFIED?

RESOURCE R IS FREE?

RESOURCE R WILL BE AVAILABLE IN N TIME UNITS?

IS UTILIZATION (R) .RC. VALUE?

IS THE NUMBER IN (QUEUE NAME) .RC. VALUE?

PROCESSED BY ACTIVITY Y?

NOT PROCESSED BY ACTIVITY Y?

LAST PROCESSED BY ACTIVITY Y?

R. R. Bn~vocoand S. B. YADAV

CLARIFICATION

Are there any entities currently waiting to use this resource?

Are there any entities which are waiting to use only this resource?

Are there any entities requiring this and other resources?

Are there any entities requesting this resource which have had all other required resources allocated to them?

Are there any entities requesting multiple resources where all required resources are either available or already allocated to the entity?

Are any resource R’s free?

Will resource R be released from the activity it is currently performing in N time units?

How does the utilization of resource R compare to the given value where RC = {EQ, NE, LT, GT, LE, GE}?

How does the number in queue (queue name) compare to the given value where RC = {EG, NE, LT, GT, LE. GE}?

Are there any entities which have been processed by activity Y?

Are there any entities which have not been processed by activity Y?

Are there any entities whose most recent activity was activity Y?

Fig. 11. A list of questions for use in modeling resource.

Events may occur randomly or at specified intervals.

An illustrative example will provide an intro- duction to the concept of System Control Net- works. Consider the arrival of entities to a system. Entity arrival is an event because it causes a change in system status, i.e. the system contains one more entity after the entity arrives. Once the entity enters the system, its flow is modeled with an Entity Flow Network. However, its insertion into the system is modeled through a System Control Network. Fig- ure 14 illustrates the representation of entity ar- rivals and insertions into Entity Flow Networks with System Control Network symbology.

The network shown in Fig. 13 demonstrates sev- eral features of System Control Networks. The SE- LECTOR and BOUNDARY nodes serve the same purposes as those introduced in entity flow net-

working. The CREATE node models the arrival of entities to the system. The arc on the CREATE node denotes the time between arrivals of entities to the system.

The SELECTOR node dispenses entities to BOUNDARY nodes which enter the entities into Entity Flow Networks. BRANCH(A) specifies con- ditional, take-all branching as the basis for branch selection. The first branch will be taken if the user- defined variable NUM has a value greater than 25 and an entity will be entered into the Entity Flow Network where the node named S12 appears. The second branch will be taken if the number of entities in the node QUEl is less than twelve, while the third branch is taken if the current time is less than 1000.

Several symbol types used in Entity Flow Net- works are also used in System Control Networks.

PREEMPT RESOURCES FROM THE:

ENTITY NEAREST COMPLETION ENTITY NEAREST END OF OPERATION ENTITY FARTHEST FROM COMPLETION ENTITY FARTHEST FROM END OF OPERATION CLOSEST FACILITY LOCATION (TO ENTITY PREEMPTING) CLOSEST TO (FACILITY LOCATION) HIGHEST PRIORITY ENTITY LOWEST PRIORITY ENTITY LEAST RESOURCES REQUIRED MOST RESOURCES REQUIRED

Fig. 12. Possible preemption rules,

Dynamic structure of an organization 313

ALLOCATE

SINGLE REQUEST LAST RESOURCE RESOURCE REQUIREMENTS SATISFIED A QUEUE AN ACTIVITY CLOSEST FACILITY LOCATION HIGHEST PRIORITY ENTITY LOWEST PRIORITY ENTITY FEWEST RESOURCES REQUIREMENTS MOST RESOURCES REQUIREMENTS LEAST ADDITIONAL RESOURCES REOUIRED MOST ADDITIONAL RESOURCES REQUIRED

Fig. 13. Possible allocation rules.

The list of common symbol types include ASSIGN nodes. RESOURCE RELEASE symbols, ACCU- MULATE nodes and BOUNDARY nodes. De- scriptions of these symbols given in Section 2.1.1 and Fig. 8 are directly applicable to System Control Networks. Node types that are unique to System Control Networks are described in Fig. 15.

System Control Networks model influences that may change the status of man~actu~ng systems. They permit the analyst to model highly irregular activities based upon the status of related system elements. The flexibility of System Control Net- works provides the IDEF2 modeler with powerful techniques for modeling the occurrence of events.

2.2 Supporting documents In order to understand and analyze the dynamic

behavior of a complex manufactu~ng system, we must characterize elements of the system and por- tray the interactions between the system elements. The graphical portion of IDEF:, i.e. the Entity Flow Networks, Resource Disposition Trees, Sys- tem Control Networks, and Facility Diagrams pro- vide a visual display of the behavior of the system. For instance, the presence of a QUEUE node in- dicates that entities are awaiting service by a re- source. But important characteristics of the QUEUE such as its maximum size, its ranking priority scheme, and its status at the beginning

point in the analysis are not included on the graph- ical image. For this reason, supporting documents are required on which to specify additional char- acteristics of the graphical elements on IDEFz models.

Resource Disposition Trees are self-document- ing in that all the i~ormation required to process the disposition of resources is found on the trees. However. Entity Flow Networks, System Control Networks, and Facility Diagram contain graphical images which require characterization via support- ing documents.

All IDEF2 graphical elements except Resource Disposition Tree elements have attributes for which values must be defined. These required attributes define the basic characteristics of the system ele- ments they represent. Graphical symbols, without characterization of the physical system elements that they portray cannot be used for analysis of per- formance. These required attributes along with the IDEF: diagrams complete the requirements for the construction of IDEFt models. Any required attri- butes which are not contained on the IDEF:! sym- bols must be supplied on IDEF2 forms.

Figures 9 and 1.5 list the required and optional attributes to be specified for Entity Flow Networks, and System Control Network, respectively.

In addition to the attributes of the Entity Flow Nodes. System Control Nodes, and Facility Dia- gram Components, IDEF2 models must describe the attributes of entities which flow through Entity Flow Networks, the initial disposition of entities in Entity Flow NerNorks, the initial disposition of all resources, and the initial values of any continuously valued attributes. This information is to be provided on Entity Definition forms, Initial Entity Disposi- tion forms, Initial Resource Disposition forms and Initial Continuous System Definition forms, re- spectively. Two of these forms that are used most often are included in Figs. 16 and 17.

2.3 Relationship among submodels Consider a typical scenario of a manufacturing-

like environment. Various events occur which re-

IN ENTlTY NET WORK!5

BOUNMNY WOES

Fig. 14. System control network for entity creations.

314 R. R. Ba~voco and S. B. YADAV

REQUIRED OPTIONAL ATTRIBUTES ABBOTS

CREATE node 1. Identifying name 6. Cost of initial purchase 2. Start node name 7. Cost of initial 3. Time batween creations transportation

or historical trace

ALTER node

ENTER node

ACTIVATE node

4. Time of fust creation 5. Entity type

1. Identifying mune 2. Resource type 3. Change in capacity/new

quantity

1. Identifying name 2. Time of entry

DEACTIVATE node 1. Identifying name 2. Resource type/SHIfT

CONVEYOR

PREEMPT node

DETECT node

1. Identifying uame 2. Resource type 3. Entity destination 4. Resource destination 9. Remaining Processing

Time

6. List of activities from which resources can be preempted

S?‘MBOL

PART

TIME

ENTER NODE

ACTIVATE NOCE

DEACTIVATE NOOE

NODE NAME

DESTINATION Of

‘\ ENTtTY

\ i

RESOURCE TYPE \ BEING PREEMPTED ’

DESTINATION OF’ RESiXJRCE

1. Ident~y~~ name 2. Attribute name 3. Facility, entity, or

resource 4. Direction of crossing

(positive, negative) 5. Threshold value 6. Tolerance

Fig. 1% Attribute specification for components of system control networks.

sult into activities to be performed. These activities in turn use resources to complete tasks. This sce- nario describes basically the time-varying behavior of a system. Here we note that there is a good deaf of interaction among events, activities and re- sources. Events control the flow of entities on which activities are performed and resources are consumed. One can create an integrated model to show all three aspects-events, flow of entities and disposition of resources into one model. However,

as discussed earlier, the IDEFt creates submodeis to capture these aspects. These submodels when combined together describe the system, These sub- models relate to each other as follows.

The system control submodei models events which control the flow of entities. Once the flow is decided, an entity flow submodel is used to show all the activities performed on an entity from the start to the end. The disposition of each of the re- sources shown in the entity flow submodel is de-

Dynamic structure of an organiration 315

INITIAL ENTSTY DISPOSITION

Rfb!AI#Int TYPE

JUTES

YALUE Al CREATION

ATTRII YWBER

. U5TS

RF3

TYPE

CES

runef R

ACCL'MJLATE OUEUE

OR ACflVtTY

MME

RFYAINING AtTlVITY

TINE

Fig. 16. Initial entity disposition form.

fNiTtAt RESOURCE DSSPOSIlION

I

f

TYPE

!mlE

AT:

IOfNTlFIER

BUTES

VALUE AT CREATION

Fig. 17. Initial resource deposition form.

316 R. R. BRAV~CO and S. B. YADAV

ENTITV FLOW NOOP AHRI8UTE OEflNlllON

SYzEL 10Et4~4ElNG AnRleUTES

IOENTlflER VALUE

QUEUK SAWlQ MNKINC MILK FlllST.tN. FIlvT.0U-T MAKIMUt.4 NVWlEll IN QUKUK INITXAL NUMEEK IN QUEIJK ;

ACIlVlT7 SIKKPAIR DURATION uTwulw%JD)

-. lntLK YWlwKR -- KKl!EA&4WI.6.1 1

__ SAW, KKF*,”

I I

Fig. lg. Entity flow form for SAW/Repair.

ACTIVITY ACTIVITY

SYSTEM CONTROL NODE ATTRIBUTE Dffl((klON

~ AlTRleUTES IOE;;;;NG

IDENTIFIER ! VALUE

I I

CMssAWl

SIRKPAIR TIME BETWEEN SAW1

BRLAKDDWNS

REMAINING ACTlVITl TIME LIST OF ACTIVITIKS PnlORITY DURATION DURATION

RE!nART FnOM 9rOP SAWING I I RKLfFtKSAWI) EKFONEKTML(4S)

Fig. 19. System control form for SAW1 breakdowns.

Dynamic structure of an organization 317

scribed by a resource disposition submodel. A fa- cility submodel is used to show where in a physical environment the system activities represented by the other three models take place. It is not actually considered to be part of the modeling process and we have not discussed this submodel in this paper.

3. USE OF IDEFz TO ANALYZE SYSTEMS PERFORMANCE

Our Entity Flow Network graphically portrays the passage of entity through the system. However, it is incomplete in its use as an analysis tool. We need to quantify all of the dynamic characteristics of the system in order to measure the systems per- formance. To accomplish this we need to complete a set of Entity Flow Node Attribute Definition forms for each of the elements in our system. By considering the nature of our problem, we can read- ily suggest pieces of information that would be nec- essary to perform an analysis of the dynamics of our system.

For example, in order to measure the length of time that parts spend in a manufacturing system, * must specify a time for each of the activities that the parts engage in. Also we must quantify the storage space available at each machine site. All of these attributes are described using attribute de& nition forms. As an example, we show an Entity Flow Node Attribute Definition form in Fig. 18. Similarly the attributes System Control Nodes are defined using System Control Node Attribute def- inition form shown in Fig. 19. Node attribute def- inition forms for each submodel provide adequate information to simulate models in order to assess performance. We see that additional detailed in- formation is required about submodels in order to use them for analyzing system performance. Space limitation does not permit a detailed discussion of systems performance here.

REFERENCES

[l] R. L. Ackoff: Management misinformation systems. Management Science 4, 147-156 (1%7).

[2] Roeber J. Benjamin: A generation perspective of in- formation system development. Communfcation of the ACM 15, 640-643 WY 1972).

131

[41

[63

171

181

[91

[lOI

[Ill

1121

[I31

1141

[151

Ralph R. Bravoco and Surya B. Yadav: A method- ology to model the functional structure of an organ- ization. Computers in Industq (submitted for review, September 1984). Ralph R. Bravoco and Surya B. Yadav: A method- ology to model the information structure of an or- ganization. The Journal ofSystems and Software tac- cepted for publication. September 1984). Ralph R. Bravoco and Surya B. Yadav: Requirement definition architecture-An overview. Computer in Industp (submitted for review. September 1984). Walter M. Carlson: Business information analysis and integration techniaue fBIAlT)-The new hori- zon. Da&base. Spring; 3-9 (1979): International Business Machines: Business Svsrems Planning-information Systems Planning Guide, Manual GE20-0527-2, 2nd ed. (1978). B. Langfors: Some approaches to the theory of in- formation systems. BIT 3, 229-254 (1983). Mats Lundeberg, Goran Gldkuhl and Anders Nils- son: Information Systems Development-A System- atic Approach. Prentice-Hall. Englewood Cliffs. New Jersey (1980). F. W. McFarlan, R. L. Nolan and D. P. Norton: In- formation System Administration. Hold Rienhart & Winston, New York (1973). J. C. Miller: Conceptual models for determining in- formation requirements. Proceedings of the Spring Joint Computer Conference, pp. 609-620 (1964). D. T. Ross et al.: Structured analysis for require- ments definition. IEEE Trans. on Software Engi- neering SE-3, (1) (Jan. 1977). M. H. Schwartz: MIS planning. Datamarion, pp. 30- 31 (September 1970). U.S. Air Force: Integrated computer-aided manufac- turing (ICAM) architecture. Part 11, Volume II-Ar- chitecture-A structured approach to manufactur- ing. AFWAL-TR-81-4023, Wright-Patterson Air Force Base, Ohio 45433 (June 1981). U.S. Air Force: Integrated computer-aided manufac- turing (ICAM) architecture. Part Il. Volume Vl-Dy- namics modeling manual (lDEF2). AFWAL-TR-81- 4023, Wright-Patterson Air Force Base, Ohio 45433 (June 1981).

[ 161 U.S. Air Force: Integrated computer-aided manufac- turing (ICAM) architecture. Part Il. Volume X-Dy- namics model of a sheet metal center subsystem (SMCz). AFWAL-TR-81-4023, Wright-Patterson Air Force Base, Ohio 45433 (June 1981).

[17] Surya B. Yadav: Determining an organization’s in- formation requirements: A state of the art survey. Database (Spring 1983).

[18] Surya B. Yadav: A methodology for modeling and organization to determine and derive information sys- tems requirements. Ph.D. Dissertation University Microfilm International, Ann Arbor, Michigan .._^. (1Y81).