Business Process Modeling

Introduction

Objectives

Concepts

Documentation

Steps

Tutorial

References

Business Process Modeling

Introduction

The purpose of Business Process Modeling (BPM) is the construction of a concise, unambiguous representation of a business or business area in terms of:

the activities that take place currently ('AS-IS' or 'current state' model), or should take place in future ('TO-BE' or 'desired state' model), within the business or business area

the order in which those activities can take place

the mechanisms whereby the activities are carried out

the inputs to, and outputs from, the activities

the measures of process performance.

The model or models thus constructed may be used:

as an agreed description of the activities that are currently in operation (an 'AS-IS' model, or 'current state' model)

as an agreed description of the goals and activities that will comprise an improved or re-engineered process (a 'TO-BE' or 'desired state' model)

as the basis for cost calculations

as the basis for the definition of measures of process performance

as a starting point for simulation studies.

Business Process Modeling

Objectives

construct a concise and unambiguous representation of a set of interdependent business activities that together form a business process

in a way that

describes each of the component activities together with its inputs and outputs

details the mechanisms (including roles) whereby each activity is carried out

defines the relationships between activities in terms of inputs, outputs, mechanisms and controls

defines relevant measures of process performance

so that

a re-engineered or improved process can be envisaged.

Business Process Modeling

Concepts

What is a Process
Business Processes and Internal Processes
Choice of Modeling Methodology, Notations and Tools
IDEF0 Process Concepts
"BPM Lite" (L)

Next - Business Processes and Internal Processes

Concepts

What is a Process

A process may be defined as a "A specific ordering of work activities across time and place, with a beginning, an end, and clearly identified inputs and outputs: a structure of action" (Davenport 1993).

An alternate description from Jacobson focuses on the fact that the activities behave synergistically in order to ensure a particular outcome: "�a [business] process is the set of internal activities performed to serve a customer. The purpose of each business process is to offer each customer the right product or service�with a high degree of performance measured against cost, longevity, service and quality" (Jacobson et al 1995).

Next - Choice of Modeling Methodology, Notations and Tools

Concepts

Business Processes and Internal Processes

The term "Business Process" as generally used has a strict meaning and a more inclusive meaning.

Strict Usage

For a process to qualify as a business process in the strict sense, it must:

be initiated by a stimulus that originates outside the organization (e.g., a customer places an order for some goods);

end by delivering some value to a recipient outside the organization (e.g., goods are delivered to a customer in fulfillment of an order).

When the strict usage of the term "Business Process" is in force, the term "Internal Process" means a set of activities that may:

be initiated from within the organization's boundaries;

deliver value to a recipient within the organization.

More Inclusive Usage

More inclusively, the term "Business Process" may be used to denote any set of activities that together achieve some defined goal, regardless of whether that process begins or ends outside the enterprise boundary.

Previous - Business Processes and Internal Processes

Concepts

Choice of Modeling Methodology, Notations and Tools

IDEF Methods and Notations
Use of IDEF Method Support Tools
Object-Oriented Alternatives to IDEF

Previous - Choice of Modeling Methodology, Notations and Tools

Choice of Modeling Methodology, Notations and Tools

IDEF Methods and Notations

This technique uses an activity-based modeling approach called IDEF0. It also references the IDEF1/IDEF1X and the IDEF3 methods.

�IDEF� stands for �ICAM DEFinition�, where �ICAM� in turn stands for �Integrated Computer-Aided Manufacturing�.

Background to the IDEF Methods

IDEF0 Process Modeling

IDEF3 Workflow Modeling

Use of Data Flow Diagramming in an IDEF0 Context

Relationship to Static (Data and/or Object) Modeling

IDEF Methods and Notations

Background to the IDEF Methods

During the 1970s, the U.S. Air Force Program for Integrated Computer Aided Manufacturing (ICAM) sought to increase manufacturing productivity through systematic application of computer technology. The ICAM program identified the need for better analysis and communication techniques for people involved in improving manufacturing productivity.

As a result, the ICAM program developed a series of techniques known as the IDEF (ICAM Definition) techniques which included the following:

IDEF0, used to produce a "function model". A function model is a structured representation of the functions, activities or processes within the modeled system or subject area.

IDEF1, used to produce an "information model". An information model represents the structure and semantics of information within the modeled system or subject area.

IDEF2, used to produce a "dynamics model". A dynamics model represents the time-varying behavioral characteristics of the modeled system or subject area.

Note: IDEF2 is not referenced further in this technique.

In 1983, the U.S. Air Force Integrated Information Support System program enhanced the IDEF1 information modeling technique to form IDEF1X (IDEF1 Extended), a semantic data modeling technique.

In parallel, the IDEF3 method was also developed as part of the US Air Force�s Information Integration for Concurrent Engineering (IICE) program, sponsored by the Armstrong Laboratory�s Logistic Research Division.

Previous - Background to the IDEF Methods

IDEF Methods and Notations

IDEF0 Process Modeling

The BPM technique makes use of the IDEF0 Process Modeling technique as defined in the Federal Information Processing Standards (FIPS) Publication 183 (see [IDEF0]). IDEF0 has a number of advantages in this context.

It is comprehensive and expressive, capable of graphically representing a wide variety of business, manufacturing and other types of enterprise operations to any level of detail.

It is a coherent and simple language, providing for rigorous and precise expression, and promoting consistency of usage and interpretation.

It is accessible to practitioners of a wide variety of software engineering approaches; in particular it is not limited to practitioners of a particular methodology, object-oriented (OO) or otherwise.

An IDEF0 model is suitable for the application of further model analysis techniques, such as Activity-Based Costing (ABC) and simulation.

Next - Use of Data Flow Diagramming in an IDEF0 Context

IDEF Methods and Notations

IDEF3 Workflow Modeling

The IDEF0 standard document provides a slogan to explain the difference between IDEF0 and IDEF3: "think constraint, not sequencing".

Normally, it is sufficient in BPM to depict data-driven dependencies between activities (shown by arrows) rather than strict activity sequencing. If detailed sequencing must be modeled, IDEF3 is a more suitable notation than IDEF0. Whereas IDEF0 depicts inter-activity relationships relatively abstractly in terms of output-input, output-control and output-mechanism relationships, IDEF3 has the ability to show sequencing, AND/OR/XOR branching and merging, repetition and parallelism. In such situations, IDEF3 is used an alternate notation for one or more of the child diagrams in a hierarchy of IDEF0 diagrams.

The IDEF3 Workflow Modeling notation is widely accepted by the DoD as a useful adjunct to IDEF0. However, it is not a Federal standard.

This BPM technique does not provide any further information on IDEF3. The interested reader can obtain a copy of the specification from Knowledge-based Systems, Inc. [IDEF3]. Further information on IDEF3 can also be obtained from the documentation accompanying Computer Associates� BPWin tool, which allows child diagrams in IDEF0 models to be constructed using IDEF0, IDEF3, or Data Flow Diagramming.

Next - Relationship to Static (Data and/or Object) Modeling

IDEF Methods and Notations

Use of Data Flow Diagramming in an IDEF0 Context

For certain modeling assignments, the ability to show stores of data explicitly is useful. In such situations, data flow diagramming is used an alternate notation for one or more of the child diagrams in a hierarchy of IDEF0 diagrams. Since neither IDEF0 nor IDEF3 has the ability to show data stores, this is one case in which the use of data flow diagrams is indicated.

The BPM technique does not cover data flow diagramming. Further information about it is provided in the "Data Flow Diagrams" technique, and also in the documentation accompanying the BPWin tool.

Previous - Use of Data Flow Diagramming in an IDEF0 Context

IDEF Methods and Notations

Relationship to Static (Data and/or Object) Modeling

IDEF0 provides an activity-based view of the business area under study. This is only one perspective on understanding the area; an equally important one is the static data-oriented perspective. This perspective is modeled by concurrent use of a data or object modeling technique alongside IDEF0.

The IDEF1X (extended IDEF1) data modeling approach is often used in conjunction with IDEF0 on U. S. Government projects. In addition, a variety of static modeling techniques are provided in the process library. See, for example, the Data Modeling technique, and the System Object Modeling (UML-compliant object-oriented) techniques.

Whichever approach, notation and technique is chosen, it is important to understand the semantic relationship between an IDEF0 model and a static model, and to check this relationship for consistency at suitable points during the development of the IDEF0 model. Put simply, each arrow on an IDEF0 diagram represents the transmission of one or more data items from one activity to another. Merging of arrows implies aggregation of data items into a record structure, entity or object instance, while splitting of arrows represents the projection of a subset of aggregated data items out of a record structure, entity or object instance. When checking the model against a static model, it is important to ensure that all the data items, record structures and entity or class definitions implied by the IDEF0 model are represented within the static model. Tools such as Computer Associates� BPWin can help in conducting such checks of an IDEF0 model.

Previous - Relationship to Static (Data and/or Object) Modeling

Next - Object-Oriented Alternatives to IDEF

Choice of Modeling Methodology, Notations and Tools

Use of IDEF Method Support Tools

The use of IDEF0 and IDEF1 is made significantly easier by the use of suitable modeling tools.

Although IDEF0 is essentially a simple notation that is suitable for "whiteboard use", the full IDEF0 standard places a considerable clerical burden on the modeler, especially as regards the maintenance of the many Working Information and Identification Information fields on the standard IDEF0 form. Even without such obligations, the need to maintain complete diagram sets in correct hierarchical relationship can become onerous.

IDEF1 and IDEF1X are graphically simple, but a tool can help greatly by maintaining entity and data item information in a dictionary associated with the diagrams. Typically, a suite of related IDEF tools will also offer the ability to reconcile the data content of IDEF0 and IDEF1 models as described in step 5 of this technique. Without this facility, such reconciliation can be time-consuming.

Previous - Use of IDEF Method Support Tools

Choice of Modeling Methodology, Notations and Tools

Object-Oriented Alternatives to IDEF

One of the key attributes of object-oriented methods is "seamlessness". Seamlessness is achieved by the use of the same concepts and models to represent artifacts at multiple levels of abstraction: strategic planning, analysis, architecture, design, and construction, for example. Although IDEF0 can be used as the Business Process Modeling approach in the context of a consciously object-oriented or component-based project, seamlessness will be better served if an object-oriented BPM technique is adopted.

Two candidate object-oriented techniques should be considered in these situations:

Jacobson's BPM technique as described at length in his book "The Object Advantage" [Jaco95];

BPM with Catalysis, described in "Objects, Components and Frameworks with UML: The Catalysis Approach" [DSou98].

Of these two, the Catalysis technique is more powerful and better defined, but requires prior knowledge of a slightly wider range of concepts, in particular, the notion of refinement as applied to use cases.

The Catalysis technique is expected soon to be available in a forthcoming release of the Process Library.

Previous - Object-Oriented Alternatives to IDEF

Concepts

IDEF0 Process Concepts

Pre-conditions and Inputs
Outcomes, Outputs and Deliverables
Control
Activity
Function
Mechanism

Next - Outcomes, Outputs and Deliverables

IDEF0 Process Concepts

Pre-conditions and Inputs

Activities are often able to take place only if certain pre-conditions have been met. An artifact that must be present before an activity can start is called an input.

IDEF0 process models are capable of describing the ways in which activities influence one another by means of interconnected inputs, outputs, controls and mechanisms. IDEF3 workflow models are capable of showing activity interdependency and timing in much greater detail; making branching and merging of process flow, choice, looping and parallelism explicit. The IDEF0 standard document provides a modeler's slogan to help keep this distinction in mind: "think constraint, not sequencing".

IDEF0 Process Concepts

Outcomes, Outputs and Deliverables

Activities are executed in order to bring about some desired state of affairs. Usually this takes the form of a tangible artifact such as a document or software component. Such artifacts are called outputs. Sometimes, though, the desired state of affairs takes a less tangible form, in which case it may be called an outcome or post-condition. For example, the outcome of a management briefing activity is a group of people who know more than they did previously. Unless we rather artificially say that the briefing assessment form is the output, there is no tangible output from this activity, only an outcome.

Jacobson [Jaco95] also suggests the following definition. If the result of the activity is the complete delivery of some kind of service, but no concrete artifact is created, then the term deliverable may be used.

Previous - Outcomes, Outputs and Deliverables

IDEF0 Process Concepts

Control

A control in IDEF0 is a special kind of activity input that:

influences or constrains the way in which the activity is carried out;

is not itself consumed during activity execution.

Controls are commonly policies, standards, and procedures. Additionally, in software engineering processes, where it is exceptional for inputs to be consumed by activities, there is usually a choice between representing an in-flow of information to an activity as a control or as an input. Useful rules of thumb in making the decision are:

If the input is consumed, it must be represented as an input, not a control;

If there is an output that is derived in a fairly obvious way from the input in question, it should be represented as an input;

If the main effect of the input is to modify the way in which the activity is carried out, rather than to provide content for one or more outputs, it should be represented as a control.

Finally, since each activity has a minimum of one control, where there is only one source of information for the activity, the resulting information in-flow must be shown as a control. The notion of "control" has the connotation of "main input" in such cases.

IDEF0 Process Concepts

Activity

An activity is a process component that transforms inputs (more generally, pre-conditions) into outputs (more generally, outcomes) by means of mechanisms, under the influence of controls.

IDEF0 Process Concepts

Function

Synonym for activity.

IDEF0 Process Concepts

Mechanism

Activities are carried out by particular people, devices or systems. These are grouped together as mechanisms in IDEF0 modeling. A mechanism can therefore represent, amongst other things:

a human resource playing a particular role, in which case the mechanism arrow will have a role name;

a computer system, or a functional area within a computer system, in which case the mechanism arrow will be labeled with the name of that system or subsystem's function;

a particular machine resource, in which case the mechanism arrow will be labeled with the type of machine that is used to carry out or support the activity.

Note, however, that a technique or approach that is used to execute an activity is classified as a control, not as a mechanism.

Concepts

"BPM Lite" (L)

For fast-track application of this technique, certain aspects of the notation and technique may be abridged or omitted entirely, as suggested in the following notes. Further notes, in addition to those provided here, have been embedded in various sections of this technique. The names of the sections containing �BPM Lite� notes have been flagged with an �(L)�.

Informal Model Initiation

Simplified Documentation

Working on the Model as a Whole rather than Sequentially

Dispensing with the Static Model

Simplifying the Review Cycle

"BPM Lite" (L)

Informal Model Initiation

Scoping and information gathering may be carried out and documented informally. However, it is still essential to know or to determine the objectives of the modeling assignment, as described in Step1.

Next - Working on the Model as a Whole rather than Sequentially

"BPM Lite" (L)

Simplified Documentation

Provided that an IDEF0 model is not very large, it need not be documented using the whole repertoire of cross-reference and identification fields that the standard prescribes for the Working and Identification fields on the standard form. In fact, provided that the relationship between different model components remains clear, the form itself may be dispensed with. Instead, the model may be initially drafted on white board, flip chart, or blank paper, and thereafter composed into a document whose structure reflects the hierarchical relationships between the different parts.

"BPM Lite" (L)

Working on the Model as a Whole rather than Sequentially

The IDEF0 standard recommends a carefully sequential procedure for working on different parts of the model. However, this approach can impose too great an overhead in the form of the model-reconcile-rework cycle. Instead of working sequentially, attention may be cycled rapidly between levels and processes quickly re-assigned between diagrams, either between siblings or between parents and children, rather than attending to levels separately as described in Steps 3 and 4. However, it is still advisable to pay particularly careful attention to definition of the context diagram, since the single most critical step in constructing the model is the definition of its scope and context.

Previous - Working on the Model as a Whole rather than Sequentially

"BPM Lite" (L)

Dispensing with the Static Model

Depending on the purpose of the modeling assignment, it is not always important to construct a static model in parallel with the activity-based model. If the aim is just to get a clearer view of the activities taking place, but not necessarily to prepare for the commissioning of new business activities and information systems with significant data content, such a model may be superfluous. However, BPM is commonly carried out early on in a series of analysis activities that will lead to the adoption of new technology and/or the commissioning of new systems. In such cases, it will almost always be worth constructing a static model in conjunction with the activity-based model. Note also that, if a static model is constructed, it should be reconciled with the activity-based one as described in Step 5.

Previous - Dispensing with the Static Model

"BPM Lite" (L)

Simplifying the Review Cycle

This technique prescribes a submit-review-finalize cycle within its last two steps. However, in less formal settings, it may be possible to elide these steps, thereby shortening the amount of time required to get from the initial draft of the model to the accepted version. Note that it is still important to review the model and to process all reviewer comments in a systematic manner so that none of the benefit of submitting the model to review is lost.

Business Process Modeling

Documentation

IDEF0 Standard Diagram Form (L)
IDEF0 Standard Diagram Elements

Documentation

IDEF0 Standard Diagram Form (L)

IDEF0 is a predominantly diagrammatic standard, but there are also well-defined rules for the textual components that support the diagrams. In particular, each diagram must be drawn on a standard form, detailing certain fields, which are explained next. The standard layout for such a form may be seen in Annex C.4 of [IDEF0].

In the BPM Lite variant of this technique, some of the formal documentation elements prescribed by the IDEF0 standard may be simplified or omitted. [See the "BPM Lite" section, above.]

The standard diagram form consists of three sections:

Working

Message

Identification;

placed at the top, middle and bottom of the form, as shown below.

Section Name

Section Explanation

Working Information (top)

The form is designed so that the Working Information Fields at the top of the form may be cut off when a final "approved for publication" version is completed.

Message Field (center)

The Message Field contains all the model content, both diagrammatic and supporting text. The standard recommends that all information be documented on these forms, including FEO ("for exposition only") diagrams, checklists, notes, sketches, and so on.

Identification Fields (bottom)

The Identification Fields at the bottom are designed to show, one under the other, when the forms are spread vertically and thumb-tacked, in top down order, on a cork board or wall.

The Working Information fields are as follows. More detailed explanations are available in Annex C.4 of [IDEF0].

Field Name

Field Explanation (where needed)

Author/Date/Project

Reader Notes

This provides a check-off for reader notes written on the diagram sheet. As a comment is made on a page, the corresponding note number is crossed out. This process ensures that each reader note on a diagram is assigned a unique note number, and that the note numbers on each diagram are consecutive.

Status Field

The status classifications indicate stages of approval. The standard stages are WORKING, DRAFT, RECOMMENDED and PUBLICATION.

Reader/Date

This area is where a reader should initial and date each form.

Context

A sketch of only the box layout of the parent diagram, with the parent box highlighted. (Tools such as BPWin generate this field automatically.)

Used At

This is a list of diagrams, other than the parent context, which use or reference this diagram-form page in some way.

The fields in the Identification Section are as follows. More explanation can be obtained from [IDEF0], Annex C.4.

Field Name

Field Explanation (where needed)

Node

Contains the complete node reference for the sheet.

Title

Contains the name of the material presented on the diagram form, in the message field.

Number (large area)

The large area of the number field contains the "C-number" (chronological number), comprising the author's initials followed by a unique serial number. This number is tracked during version control. Updated versions of forms must show the new C-number followed by the C-number of the superseded form in parentheses, thus: new(old).

Number (small area)

A kit page number is written by the librarian at the right hand side of the number field inside the small rectangle. This is composed of the document number followed by the letter identifying the sheet within the document.

Previous - IDEF0 Standard Diagram Form (L)

Next - IDEF0 Graphic Diagram Notations and Conventions

Documentation

IDEF0 Standard Diagram Elements

A full treatment of this notation is beyond the scope of the current technique. Only highlights are presented here. More detailed information can be obtained from [IDEF0], or from the documentation for a compliant or partially compliant modeling tool, such as Computer Associates� BPWin.

IDEF0 models are composed of three types of information: graphic diagrams, text and glossary. Only the graphic diagram notations will be described further in this section.

IDEF0 Graphic Diagram Notations and Conventions

Previous - IDEF0 Standard Diagram Elements

IDEF0 Standard Diagram Elements

IDEF0 Graphic Diagram Notations and Conventions

Boxes and Arrows
Top-Level Context Diagram
Child Diagrams and Parent Diagrams
Arrows, Constraints and Sequencing
Branching (Forking and Joining) of Arrows
Box Layout and Connections in Child Diagrams
Tunneled Arrows
Feedback Arrows

Previous - IDEF0 Graphic Diagram Notations and Conventions

IDEF0 Graphic Diagram Notations and Conventions

Boxes and Arrows

Function Box Notation

A rectangle, with or without rounded corners (a box, or cartouche), contains a name and number and represents a function (activity).

Arrow Positions and Roles

Arrows start and finish at the box boundary. Both the box side and the direction of the arrow are significant.

Arrow positions, directions and roles are summarized in the following table.

Box Side

Arrow Direction

Meaning

Left

Incoming

Input

Top

Incoming

Control

Right

Outgoing

Output

Bottom

Incoming

Mechanism

Bottom

Outgoing

Call

Meaning of �ICOM�

The acronym ICOM stands for the quadruple: input, control, output and mechanism.

Number of Arrows per Box

Every activity box has to have a minimum of one control arrow and one output arrow. It may also have zero or more input arrows, zero or more mechanism arrows, and zero or one call arrows.

�Call� Arrows

A call arrow provides a mechanism for inclusion of sub-processes that is analogous to a subroutine call in a programming language, hence the name Instead of decomposing an activity on a child diagram sub-tree, a call arrow labeled with one or more node references may be drawn, meaning that the function of the box is performed by one or more other boxes described on other sheets. If there is more than one such reference, a model note on the arrow label explains the conditions that govern the "calling" of each node thus referenced.

Boundary Arrows and Internal Arrows

Arrows are classified into:

Boundary arrows

Connected from the edge of the diagram to a box side

Internal arrows

Connected between one box side and another.

Arrow Curves, Forks and Joins

Next - Child Diagrams and Parent Diagrams

IDEF0 Graphic Diagram Notations and Conventions

Top-Level Context Diagram

Every IDEF0 model must contain a context diagram. A context diagram is at the root of the hierarchy of IDEF0 activity diagrams. It follows that there can only be one activity on a context diagram. The single activity box is shown with boundary arrows that connect it with functions outside the subject area. In this way, the context diagram establishes the focus (or scope) of the model. In IDEF0 numbering, the context diagram is called the A-0 diagram (pronounced "A minus zero").

The A-0 diagram is also required to present brief textual statements specifying the model's viewpoint and purpose. These are both key factors in guiding and constraining the model.

A Top-Level Context Diagram

The node reference for the single box on the A-0 diagram is "A0". Because this is the top level diagram by definition, the parental context is recorded in the Identification Section of the diagram form as "TOP". Sub-activities at the first level are numbered A1�An. A decimal reference notation is used for nodes at further levels of decomposition.

The IDEF0 standard also allows for higher levels of context diagram to be produced in order to define the model context more fully. Higher context levels are numbered using decreasing negative numbers: A-0; A-1; and so on.

Next - Arrows, Constraints and Sequencing

IDEF0 Graphic Diagram Notations and Conventions

Child Diagrams and Parent Diagrams

Each function box on a diagram may be decomposed into two or more sub-functions on a child diagram, which are thought of as logically contained within the parent function. The child diagram contains boxes and arrows that provide added detail about the parent box. Unless the arrow "tunneling" notation has been used (see later section), arrows on child diagrams are required to match the corresponding arrows on parent diagrams.

Previous - Child Diagrams and Parent Diagrams

Next - Branching (Forking and Joining) of Arrows

IDEF0 Graphic Diagram Notations and Conventions

Arrows, Constraints and Sequencing

Arrows joining function boxes indicate a dependency on some information from the producing activity by the consuming activity. The arrows represent pathways along which data items flow. This situation is exemplified in the diagram above.

Just as function boxes on higher-level diagrams cover larger portions of the subject area than boxes on lower-level diagrams, the data being transmitted in higher-level arrows is in a more aggregated form (such as record structures) than the data flowing along lower level arrows. Lower-level arrows carry data at a level that is relatively close to individual data items.

It is important to realize that IDEF0 notation is not capable of representing the precise nature of inter-activity dependency. Although an arrow connection represents data flow, it does not convey enough information to describe exactly when and how often a consuming activity will be able to execute as a result of receiving data. If the modeling requirement is to represent sequencing constraints and inter-activity dependencies in a highly detailed way, IDEF3 is a more suitable notation than IDEF0.

Previous - Arrows, Constraints and Sequencing

Next - Box Layout and Connections in Child Diagrams

IDEF0 Graphic Diagram Notations and Conventions

Branching (Forking and Joining) of Arrows

It is useful to think of high-level arrows as pipelines or conduits. If an arrow splits, forming two or more new arrow segments, each arrow segment may have a more specific label, as shown below. In this diagram, pipeline A splits into B and C to provide controls to X and Y. Note the use of the "squiggle" notation to enable arrow labels to be seen clearly.

An arrow may branch (fork or join), indicating that the same kind of data or object may be needed or produced by more than one function. The branches may represent the same thing, or portions of the same thing. Labeling is important in such situations, because the labels indicate the nature of the content in each arrow segment, as illustrated here.

Previous - Branching (Forking and Joining) of Arrows

IDEF0 Graphic Diagram Notations and Conventions

Box Layout and Connections in Child Diagrams

Except for the single-box A-0 context diagram, a graphic diagram contains a minimum of three and a maximum of six boxes. Boxes are normally organized diagonally from the upper left corner to the lower right in a staircase configuration.

Any output may provide data or an objects as some or all of the input, control or mechanism for another box. Of course, the arrow may also fork, thereby providing data or objects to several boxes, as in this example.

Previous - Box Layout and Connections in Child Diagrams

IDEF0 Graphic Diagram Notations and Conventions

Tunneled Arrows

Arrow tunneling by means of a pair of parentheses at either the connected or unconnected end of an arrow is used to indicate that the arrow is specific to the current level of decomposition. I.e., it was not considered necessary to show it on other levels.

Tunneling at the connected end means that the arrows do not correspond to boundary arrows on the child diagram.

Tunneling at the unconnected end means that the arrow does not correspond to arrows connecting to the parent box.

IDEF0 Graphic Diagram Notations and Conventions

Feedback Arrows

Output arrows may "feed back" into activities that are further to their left in a diagram. The feedback can be:

output-to-mechanism

output-to-input, or

output-to-control.

In such cases, rules exist that govern whether an arrow goes "up and over" or "down and under" the box for the activity that generates the output.

Next - Step 1. Determine the Scope and Purpose of the Model (L)

Business Process Modeling

Steps

Step 1. Determine the Scope and Purpose of the Model (L)
Step 2. Gather and Organize Business Information (L)
Step 3. Define the Context Diagram and the Top-Most Diagram of the Model (L)
Step 4. Define Lower Levels of the Model and Supporting Material (L)
Step 5. Check Model against, and possibly Integrate it with, Static Models (L)
Step 6. Review the Model (L)
Step 7. Finalize Model Content

Next - Business Process Re-engineering (BPR), Business Process Improvement (BPI), and/or exploiting New Technology

Steps

Step 1. Determine the Scope and Purpose of the Model (L)

Before beginning the model, it is essential to determine its scope and purpose. The scope is usually considered in terms of both context and viewpoint.

Although it is still essential to establish the context, viewpoint and purpose of the model, when applying the BPM Lite variant of this technique it will typically be possible to combine steps 1 and 2 in order to streamline model initiation and information gathering.

The context establishes the subject of the model as part of a larger whole. It defines a boundary with the environment by describing external interfaces. The context diagram that will be drawn in step 3 captures the information about the context of the model that is gathered in this step and in step 2.

The viewpoint determines what can be "seen" within the context, and from what "slant" or perspective. Depending on the purpose, different viewpoints may be adopted that emphasize different aspects of the subject. When choosing viewpoints it may be helpful to bear the following in mind.

Multiple viewpoint models of the same business area are often helpful when constructing an 'AS-IS' model, because each one clearly captures the results of information gathering activities from a particular information source.

When constructing a 'TO-BE' model, it is often possible to describe the entire process from one viewpoint; namely that of the process owner. However, more viewpoints may be represented in models if they help significantly in understanding the process.

In the BPM Lite variant of this technique, it will often be possible to simplify the modeling assignment by limiting the model to one or two viewpoints.

Documenting the purpose of the model clarifies the aim of carrying out the modeling assignment, and the goal of communication that the model is intended to serve. IDEF0 models can be used for a wide variety of purposes, including functional specification, implementation design, customer operations, and so on. In the context of BPM, however, it is particularly important to discover and document the following aspects of the model's purpose.

Business Process Re-engineering (BPR), Business Process Improvement (BPI), and/or exploiting New Technology

Estimating the Depth and Breadth of the Modeling Assignment

Deciding whether a Static Model will be Necessary (L)

Determining the Importance of Measuring Process Performance

Previous - Step 1. Determine the Scope and Purpose of the Model (L)

Next - Estimating the Depth and Breadth of the Modeling Assignment

Step 1. Determine the Scope and Purpose of the Model (L)

Business Process Re-engineering (BPR), Business Process Improvement (BPI), and/or exploiting New Technology

Is the model being constructed to enable Business Process Re-engineering (BPR), Business Process Improvement (BPI), or is there some specific business motivation behind the study, such as discovering opportunities to exploit new technology?

BPR is a "revolutionary" change in the way of doing business that will be undertaken relatively infrequently. The scope of modeling assignments in a BPR context is likely to be relatively wide, and there will typically be a strong expectation that the modelers will "think outside the frame" of current ways of operating, particularly when constructing 'TO-BE' models. In a sense, if the resulting 'TO-BE' models are not radically different from the current state models, something has gone wrong with the BPR initiative. Another essential discipline in BPR is to consider "end-to-end" processes, i.e., those that start outside the organization and end in the delivery of some value to a recipient outside the organization. (As explained in the "Concepts" section, these are business processes in the strict sense of the term.) The aim of BPR will be to facilitate those end-to-end processes, while playing down the importance of more traditional functional departmental divisions within the organization.

BPI, while seeking to engineer some of the same business optimizations as BPR, takes an evolutionary, rather than a revolutionary, approach. One or more processes in a particular business area are typically selected for study, and modeling techniques are applied. On examination of the models, process problems can be diagnosed, and process measures identified. 'TO-BE' models will always be constructed, but sometimes the benefits of spending effort on building 'AS-IS' models may be judged to be outweighed by the time and costs required to do so. Once the 'TO-BE' models have been made, process goals, expressed in terms of target levels of various process measures, should be set. Another difference between BPR and process improvement is that process improvement is typically carried out at frequent intervals, rather than adopting the "big bang" approach that is often used for BPR.

Often the real objective of a BPM assignment is not BPI for its own sake, but process investigation to determine opportunities to exploit new technology or new business ideas. If this is the true focus of the study, modelers must keep this purpose very clearly in mind at all times during information gathering and model-building activities. In particular, the �TO-BE� business process model must be constructed in such a way as to allow for the exploitation of the candidate new ideas or technology.

Previous - Business Process Re-engineering (BPR), Business Process Improvement (BPI), and/or exploiting New Technology

Next - Deciding whether a Static Model will be Necessary (L)

Step 1. Determine the Scope and Purpose of the Model (L)

Estimating the Depth and Breadth of the Modeling Assignment

How extensive is the area of business operations that must be documented? Modelers can err both by including too much and too little in the scope of their assignment.

If the scope is set too widely, the model will take too long to make, will contain irrelevant information, and will be unnecessarily difficult and costly both to construct and to review.

If the scope is set too narrowly, there is a real danger that important process improvements may be missed. Many business people are pragmatic in temperament, and do not feel comfortable with activities such as modeling. They may therefore want to short-cut the study in order to get to a definition of the new processes as quickly as possible. Pressure of this kind, whether explicit or implicit, or simple failure to consider a relevant aspect of the business area under study can all militate against getting business benefits in return for the costs of carrying out the modeling assignment.

Previous - Estimating the Depth and Breadth of the Modeling Assignment

Next - Determining the Importance of Measuring Process Performance

Step 1. Determine the Scope and Purpose of the Model (L)

Deciding whether a Static Model will be Necessary (L)

Is the scope, purpose, criticality and likely content of the BPM study sufficient to merit the construction of a static (data or object) model alongside the process model? If so, the modelers must choose which modeling technique and notation to use, and ensure that arrow data are reconciled with static model content as the process model is built up. (If IDEF0 is being used for the process model, then IDEF1 is usually the notation of choice for the static model, however.)

In this technique, we discuss static models particularly in the Concepts section (see sub-section "Relationship to Static (Data and/or Object) Modeling"), and in Step 5 ("Check Model against, and possibly Integrate it with, Static Models").

In the BPM Lite variant of this technique, one way of scaling down the effort and duration required for its application is to omit the construction of a static model and its reconciliation with the process model. However, this can only be done with safety if the data content on which the process model depends is truly insignificant, given the scope and purpose of the model.

Previous - Deciding whether a Static Model will be Necessary (L)

Next - Step 2. Gather and Organize Business Information (L)

Step 1. Determine the Scope and Purpose of the Model (L)

Determining the Importance of Measuring Process Performance

Every study of organizational processes provides an invaluable opportunity to determine which are the significant measures of process performance, and to take initial samples of those measures. Indeed, it may be said that a purely qualitative understanding of business processes is of little value.

Common measures that are always relevant are as follows.

Time to complete an activity.

Time to complete a whole process instance, e.g., �Fix one bug�; �resolve one help desk query�. This measure is usually called the process �cycle time�.

Cost of carrying out an activity.

Sometimes the effort required to carry out an activity will also be relevant, especially when contrasted with the elapsed time required. For example, one study of a process to generate an initial estimate for a mainframe installation discovered that a few hours� work was spread over several days because of the number and inefficiency of the hand-offs that were built into the process.

Definition and sampling of measures is an area in which a modeling assignment can easily over- or under-shoot the expectations of the sponsors. Modelers must be particularly careful to determine how much effort should appropriately be devoted to this aspect of the work, in light of the terms of reference that they are given, the constraints set, and the overall purpose of the study.

Previous - Determining the Importance of Measuring Process Performance

Next - Step 3. Define the Context Diagram and the Top-Most Diagram of the Model (L)

Steps

Step 2. Gather and Organize Business Information (L)

In a sense, having a second step concerned with information gathering is somewhat artificial because, in reality:

information gathering takes place continuously from the moment the modeling assignment begins until the time that it is concluded;

modelers will inevitably go through alternate phases of information gathering and information structuring in terms of the model, because each activity informs the other.

However, the rationale for mentioning information gathering particularly at this point is that, once the scope and purpose of the model has been set in step 1, the amount of effort being put into information gathering can safely be escalated, because the limits of the area under investigation are known.

Common activities in information gathering are to:

collect and read all available background material, such as existing documents, using tables of contents to locate needed information;

observe the system in operation if it already exists;

conduct interviews and workshops with managers, subject matter experts and other key personnel;

survey a group of people, through questionnaires or other such means;

use whatever information is already known to the author or authors;

guess or invent a hypothetical description, and ask readers to help bring it closer to reality.

In addition it is important to organize the gathered information before trying to diagram it.

These are all basic systems analysis techniques, and will not be discussed further here. More information and guidance on conducting workshops is provided in the "Interactive Development" technique.

When applying the BPM Lite variant of this technique, information gathering can be accelerated by favoring quick-response techniques such as Interactive Development workshops.

Previous - Step 2. Gather and Organize Business Information (L)

Next - Step 4. Define Lower Levels of the Model and Supporting Material (L)

Steps

Step 3. Define the Context Diagram and the Top-Most Diagram of the Model (L)

When applying the BPM Lite variant of this technique, this step and the next can be tackled together, rather than sequentially. However, it is still critical to focus more attention on the context level (A-0) diagram first, because of its importance in defining the scope of the rest of the model.

To start model construction:

create the A-0 (context level) diagram that shows the single A0 process box, together with its interface arrows;

also create the A0 child diagram containing the 3-6 top-level child boxes.

The easiest way to work on these diagrams is usually to alternate between work on one and work on the other until they are both complete. Drawing the A-0 diagram raises issues about in-flows and out-flows on the A0 diagram, and vice versa.

Note that. according to the IDEF0 standard, the A-0 diagram must include textual narrative explaining the purpose and viewpoint of the model.

This step is critical for adjusting and optimizing the overall scope and level of detail in the model to match the purpose and viewpoint defined in step 1. Getting the scope and leveling of detail right on both levels (context and top) may require several drafts. When working on these diagrams, bear in mind that:

all in-scope activities conceptually lie within the single box shown on the A-0 diagram;

the A0 diagram decomposes the single activity on the A-0 diagram into its three to six major sub-functions.

Previous - Step 3. Define the Context Diagram and the Top-Most Diagram of the Model (L)

Next - Step 5. Check Model against, and possibly Integrate it with, Static Models (L)

Steps

Step 4. Define Lower Levels of the Model and Supporting Material (L)

When applying the BPM Lite variant of this technique, this step and the previous can be tackled together, rather than sequentially. However, it is still critical to focus more attention on the context level (A-0) diagram first, because of its importance in defining the scope of the rest of the model.

Defining Child Diagrams

The general approach is to decompose each activity on a diagram into three to six child activities on a child diagram, where necessary. Although in principle this could be done in any order provided the hierarchical structure of the model is kept in mind, in practice it is useful to complete all the child diagrams for a particular level before going decomposing any activities to the next level. This is because lower level diagrams clarify the meaning of their parent diagrams, and may even lead to the parent diagrams being re-drawn as modeling proceeds.

For example, given this hierarchy:

the recommendation would be to complete the A0 diagram (containing activities A1-A3), before making a serious attempt to draft the A1 diagram (containing activities A11 to A13) or the A3 diagram (containing activities A31 to A33).

To detail each box in terms of three to six child boxes:

obtain any additional information that may be required to go to the next level;

create a first draft child diagram;

list all data and objects related to the function being decomposed;

check that the list covers the entire scope of the parent box so that no portion is lost in the decomposition;

draw boxes that associate candidate sub-function names with appropriate data and objects from the list;

depict the data and object flows using arrows;

modify or re-draw the child diagram several times until a satisfactory result is obtained.

It may be necessary to split activities (break up a box into two or more other boxes at the same level), or cluster them (combine several boxes on the same level into one new box) in order to get an optimal decomposition.

Measuring Process Performance

If the scope of the modeling assignment includes definition and sampling of measures of process performance, such as activity time, duration, and cost, and cycle time, duration and cost, then these measurements must be defined and sampled for each activity in the model. Measurements for parent activities can often be derived by aggregation from those for the child activities. Obviously, the use of a modeling tool normally makes such calculations easier than maintaining aggregate values by hand would be.

Creating Supporting Material

Each diagram in an IDEF0 model should be supported by:

narrative text

model glossary entries

FEO ("for exposition only") diagrams.

Supporting narrative for a diagram should "tell a story" concisely that helps the reader to get a better understanding of the information that is already present in the diagram. It is unhelpful to provide supporting narrative redundantly that merely paraphrases some or all of the information that the diagram already conveys, so this practice must be avoided.

The glossary explains the definitions that the author gives to functions and data objects in a diagram. These definitions are important because terms used in the model may have a completely different meaning in one context from the meaning they have in another. (Sometimes even different business units in the same corporation use conflicting terminology.)

FEO ("for exposition only") diagrams are diagrams that highlight particularly interesting or subtle points about a model. Unlike other diagrams in the model, they are not restricted to using a particular notation, and may even include incomplete fragments of IDEF0 notation.

Previous - Step 4. Define Lower Levels of the Model and Supporting Material (L)

Steps

Step 5. Check Model against, and possibly Integrate it with, Static Models (L)

If the BPM Lite variant of this technique is being used, this step may prove unnecessary. However, it will usually still be needed in cases where BPM leads into the commissioning of any kind of automated business solution, since the role of the new technology in processing business data must be understood in relation to the data associated with the �AS-IS� business process model.

There often exist one or more static (data or object) models of the business area that is being modeled using the BPM technique because of previous studies or projects. Alternatively, a static model may not pre-exist, but:

during activity modeling it may become clear that a static model is required to make sense of the process model;

such a model is one of the required outputs from the study, so the opportunity is taken to derive a static model from the process model during this step (Step 5).

The semantic relationship between an IDEF0 model and a static model was explained in the Concepts sub-section "Relationship to Static (Data and/or Object) Modeling"; that information is not replicated here. Suffice to say that each arrow in an IDEF0 model carries one or more objects and data items, and also that arrows can join and branch, implying the existence of more and less aggregated groupings of these data items or objects, respectively.

If there are any relevant pre-existing static models of the business area, the IDEF0 model should be reconciled with the static model(s) in the following way.

Reconcile the terminology used in the static model(s) with that used in the IDEF0 model. This may be no easy task, since the models will probably have been constructed by different teams at different times. The IDEF0 glossary should help, as should any clues regarding the significance of static model terms that were left behind by the static modelers.

Check that the groupings of data items in arrows within the IDEF0 model are represented in the static model. Remember to take arrow merges and branches into account.

If there are no pre-existing models of relevance, this step provides an opportunity to derive one.

Previous - Step 5. Check Model against, and possibly Integrate it with, Static Models (L)

Steps

Step 6. Review the Model (L)

Once the model is stabilized and has passed personal reviews by the modelers themselves, it is ready for review by personnel outside the modeling team. The technique to be used for review may be a walkthrough review or an inspection, depending on the level of formality that is mandated by the process of which this technique is a part.

If a �BPM Lite� approach is being used, the formality of the procedures used for review and rework may be relaxed considerably, rather than invoking the full procedure described in [IDEF0]. It is still important, however, to carry out reviews and to process all review feedback carefully and systematically.

The IDEF0 standard gives very extensive guidance on how to prepare, review and correct models, and the reader is referred to [IDEF0] for details. Some highlights from that publication are paraphrased as follows.

The standard forms, numbering and referencing in IDEF0 are designed to ensure that reviewers always know exactly what they are looking at, and how to navigate from one piece of the presented model to another. It is important that reviewers avail themselves of these facilities.

The standard describes how to compile a standard review package from the model elements. This is called a "Standard Kit". The kit goes through a number of review cycles called "Kit Cycles". The standard describes exactly how reviewers record their comments, and how the author(s) must make use of, and respond to, those comments.

The standard roles for reviews distinguishes between "commenters" and "readers". Commenters are expert enough to make comments on the subject matter, and also trained enough in IDEF0 to make written comments in the approved manner. Readers are knowledgeable in the subject matter, but not qualified to make written comments to IDEF0 standards.

Section C.6 of [IDEF0] contains a detailed process for walking through an IDEF0 model. Key points are:

Present the model to be analyzed by using its node index (table of contents), and provide a quick overview;

Present selected glossary terms;

Present each diagram for review;

Examine the diagram;

Check the parent diagram for compatibility;

Examine the internal arrow pattern in the diagram;

Read the supporting documentation;

Set the review status of the diagram to one of the standard status values (in IDEF0, these are WORKING, DRAFT, RECOMMENDED, and PUBLICATION).

Steps

Step 7. Finalize Model Content

Finalize the model by processing all review comments. File the model according to approved project filing, versioning and configuration management procedures.

Previous - Step 7. Finalize Model Content

Next - Step 1. Determine the Scope and Purpose of the Model

Business Process Modeling

Tutorial

This tutorial describes a small modeling assignment that is being carried out as a pilot by an analysis team at the Widget Warehouse Company. The Senior Management of the company believes that there are opportunities for significant process improvement, and they wish to start an improvement program.

Step 1. Determine the Scope and Purpose of the Model

Step 2. Gather and Organize Business Information

Step 3. Define the Context Diagram and the Top-Most Diagram of the Model

Step 4. Define Lower Levels of the Model and Supporting Material

Step 5. Check Model against, and possibly Integrate it with, Static Models

Steps 6 and 7. Review the Model and Finalize the Content

Step 7. Finalize Model Content

Next - Step 2. Gather and Organize Business Information

Tutorial

Step 1. Determine the Scope and Purpose of the Model

In this step, the analysis team is concerned to determine and document the scope and purpose of the model assignment.

Scope: Context

The analysts are told that the aim of the study will be to gain experience in using the BPM technique, hence only a small area of the company�s operations is being targeted initially. The scope of the model will be to cover a part of the inventory control activities within the company. They may choose exactly which set of inventory control activities to target as the assignment proceeds; the only proviso being that there should be enough in the chosen area to be worth studying and to allow the team to gain meaningful experience in constructing a process model.

Scope: Viewpoint

The modeling viewpoint will be an operational one; i.e., the view of the activities being carried out as seen by those performing them, rather than, for example, an accounting view of those same activities, which would look quite different.

Purpose

As stated previously, this is a pilot study to gain experience with the modeling technique, and to �debug� the process. Based on these experiences, a full plan and estimates for the initial phase of the company�s BPI program will be drawn up.

BPR or BPI?

The bias of the study is towards BPI rather than BPR. Furthermore, the BPI program may eventually lead to the adoption of new technology, but that is not the focus of the pilot, which will attempt only to construct an �AS-IS� model.

Depth and Breadth

The pilot study must be time-boxed to three weeks, so it will be important not to allow the scope to become too wide or deep. The analysts will aim to find an interesting but well-circumscribed aspect of the company�s operations to study.

Necessity for Static Modeling

For the purposes of the current study, static modeling may be omitted unless it turns out to be essential to an understanding of the area being modeled.

Importance of Measuring Process Performance

The sponsors expect that simple measures of process performance will be identified, and baseline readings taken in the area studied. The relevant measures will be activity completion time and, if possible, cost. Documentation of measures and measurements may be limited to the most detailed level of the model in order to preserve time-box constraints.

Previous - Step 1. Determine the Scope and Purpose of the Model

Next - Step 3. Define the Context Diagram and the Top-Most Diagram of the Model

Tutorial

Step 2. Gather and Organize Business Information

Initial investigations of the inventory control activities in the company reveal that there are several separate areas of activity:

Receiving materials

Testing materials

Returning discrepant materials to vendors

Warehousing materials

Issuing materials

Monitoring the physical inventory

Analyzing usage and stock levels over time

Replenishing materials.

After a series of time-limited interviews with key staff, the relationships between these areas become clearer. It seems to the analysis team that materials replenishment will be a good sub-process to use as the basis for the study. It is reasonably complex, although not excessively so, and measures of performance happen to be reasonably easily available.

Previous - Step 2. Gather and Organize Business Information

Next - Step 4. Define Lower Levels of the Model and Supporting Material

Tutorial

Step 3. Define the Context Diagram and the Top-Most Diagram of the Model

In this step, the A-0 (context) and A0 modeling levels are attempted. The initial draft of A-0 comes out as follows.

So far, so good. The analysts have established from their initial information gathering that the inventory control function deals with receiving stock from suppliers, returning defective or incorrectly delivered stock to suppliers, and issuing stock from the warehouse.

The next task is to construct an A0 (top-level child) diagram to go with the A-0 (context) diagram. However, constructing this diagram reveals some deficiencies in the context diagram.

The A0 diagram raises the questions about:

What triggers the issuing of stock from the warehouse?

How does the replenishment function request new goods from outside suppliers?

On the A0 diagram, these questions are answered by two new flows:

Stock Request

Material/Service Request.

Unless these new flow arrows are represented in tunneled form, which does not seem justifiable in this case, they must be reflected on the context diagram also. The analysts therefore re-draw the context diagram as follows.

The A-0 and A0 levels now seem consistent and stable enough to justify going on to model lower level activities.

Previous - Step 3. Define the Context Diagram and the Top-Most Diagram of the Model

Next - Step 5. Check Model against, and possibly Integrate it with, Static Models

Tutorial

Step 4. Define Lower Levels of the Model and Supporting Material

In order to stay within their time-box while covering at least one area in full detail, the team decides to concentrate on the �replenish materials� function.

A detailed study of the activities in the area reveals the following picture. The estimated costs for each activity are shown in the lower left corner of each activity box.

The cycle cost of each occurrence of the �replenish� activity turns out to be around $20. The following picture shows the same activities, only this time the typical duration of each activity is shown in the lower left corner of each activity box.

In this sub-model, the activities follow on from one another, so the total cycle time for the �replenish� activity is the total of the individual durations for each of the activities. This adds up to around 48 minutes.

Previous - Step 4. Define Lower Levels of the Model and Supporting Material

Next - Steps 6 and 7. Review the Model and Finalize the Content

Tutorial

Step 5. Check Model against, and possibly Integrate it with, Static Models

Since static modeling has been placed out of scope for this study, this step is null.

Previous - Step 5. Check Model against, and possibly Integrate it with, Static Models

Tutorial

Steps 6 and 7. Review the Model and Finalize the Content

This small pilot model is reviewed, reworked and finalized using a less formal procedure than that prescribed in [IDEF0]. Copies of the model are prepared in a document that separates the levels into different sections, and carefully documents the scope and purpose, presents the context level, and then the lower levels via a tree-walk of the child diagrams.

Review comments are solicited on a simple standard form. Once gathered in, they are classified and disposed according to severity and impact. All review comments that have been accepted and analyzed are processed and the model updated accordingly.

The pilot study, small though it is, has already demonstrated that there are several aspects of the replenishment procedure alone that could be optimized. Like many unexamined business processes, it:

is relatively bureaucratic, requiring multiple non-value-added reviews;

requires manual retrieval and organization of information;

requires simple, repetitive, rule-based decisions to be made by people rather than machines.

The scene is now set for further AS-IS modeling to take place, followed by process re-design, leading to improved performance, which will be documented in a TO-BE model.

Previous - Steps 6 and 7. Review the Model and Finalize the Content

Business Process Modeling

References

[IDEF0] Draft Federal Information Standards Publication 183 (1993) Integration Definition for Function Modeling (IDEF0).

This document defines IDEF0, and contains a large amount of useful information for anyone considering the application of IDEF0. It is available from the NIST web-site, which is at http://www.nist.gov.

[Jaco95] Jacobson, I., Ericsson, M., Jacobson, A. (1995) The Object Advantage: Business Process Re-engineering with Object Technology, Addison Wesley, ISBN 0-201-42289-1.

This book contains many interesting observations and references on the subject of Business Process Re-engineering and Modeling. However, it focuses on the use of specific object-oriented techniques, which are relatively untested at this time in comparison with IDEF0.

[Dave93] Davenport, T. H. (1993) Process Innovation, Re-engineering Work through Information Technology, Harvard Business School Press.

This book provides useful definitions, as well as numerous examples of firms that have succeeded or failed in combining business change and technology initiatives. Appropriate emphasis is also placed on new organization structures and human resource programs in facilitating process innovation.

[IDEF3] Mayer, R. J., Painter, M. K., Menzel, C. P., Perakath, B., deWitte, P. S., Blinn, T. (1995) Information Integration for Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report.

This document describes the IDEF3 process capture method. As yet it is still in an interim state. Copies can be obtained from the Knowledge-based Systems Inc web-site, which is at http://www.kbsi.com.

[DSou98] D'Souza, D. F, and Wills, A. C., (1998), Objects, Components and Frameworks with UML: The Catalysis Approach, Addison-Wesley Pub Co; ISBN: 0201310120.

This book describes the Catalysis component-based development (CBD) method.