i

RESEARCH PROJECT REPORT FUNDED BY THE

EXTERNAL ACQUISITION RESEARCH PROGRAM (EARP)

REDESIGNING ACQUISITION PROCESSES:

A NEW METHODOLOGY BASED

ON THE FLOW OF KNOWLEDGE

AND INFORMATION

NED KOCK

FREDERIC MURPHY

July 2001

DEFENSE ACQUISITION UNIVERSITY PRESS

DEFENSE SYSTEMS MANAGEMENT COLLEGE

FORT BELVOIR, VIRGINIA
Report Documentation Page Form Approved

OMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and

maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,

including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington

VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it

does not display a currently valid OMB control number.

1. REPORT DATE

JUL 2001

2. REPORT TYPE

N/A

3. DATES COVERED

 - 

4. TITLE AND SUBTITLE

Redesigning Acquisition Processes: A New Methodology Based on the

Flow of Knowledge and Information

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

Defense Acquisition University Defense Systems Management College

Fort Belvoir, VA

8. PERFORMING ORGANIZATION

REPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT 

NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT

Approved for public release, distribution unlimited

13. SUPPLEMENTARY NOTES

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 

ABSTRACT

SAR

18. NUMBER

OF PAGES

81

19a. NAME OF

RESPONSIBLE PERSON

a. REPORT

unclassified

b. ABSTRACT

unclassified

c. THIS PAGE

unclassified

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std Z39-18 
i

July 2001

Research Project Report Funded by the

External Acquisition Research Program (EARP)

PUBLISHED BY THE DEFENSE ACQUISITION UNIVERSITY PRESS

Fort Belvoir, Virginia 22060-5565

Ned Kock

Temple University

1810 N. 13th Street, 210C Speakman Hall, Philadelphia, PA 19122

Phone: (215) 204-4573, Fax: (215) 204-3101, E-mail: kock@sbm.temple.ed

Frederic Murphy

Temple University

1810 North 13th Street, 111 Speakman Hall (006-00), Philadelphia, PA 19122

Phone: (215) 204-8189, Fax: (215) 204-5698, E-mail: fmurph@sbm.temple.edu

REDESIGNING ACQUISITION PROCESSES:

A NEW METHODOLOGY BASED

ON THE FLOW OF KNOWLEDGE

AND INFORMATION
ii
iii

ACKNOWLEDGMENTS

The original title of this project was “Developing a Methodology for Redesigning Acquisition

Processes Based on Information Load Analysis.” The new title of this report is slightly different to

better reflect the final outcomes of the project. We would like to thank the External Research Acquisition Program coordinators, particularly Mark Nissen, for their relentless and generous support. We

would like to also thank the employees of Computer Sciences Corporation and Lockheed Martin as

well as the officials from the Department of Defense who participated in this project.
iv
v

TABLE OF CONTENTS

List of Figures and Tables .......................................................................................................... vii

Abstract ........................................................................................................................................ ix

Organization of this Report......................................................................................................... xi

Chapters

1 Research Problem, Goals, and Plan .................................................................................... 1

Problem Statement ........................................................................................................ 1

Goal and Approach ....................................................................................................... 1

Project Deliverables ...................................................................................................... 3

Potential Impact and Significance ................................................................................. 3

Dissemination of Results ............................................................................................... 4

Support Web Site .................................................................................................... 4

Conference Papers .................................................................................................. 4

Journal Articles........................................................................................................ 4

2 Conceptual Foundation ....................................................................................................... 5

Process Views: Focusing on Certain Aspects of Processes ............................................ 5

The Work-flow View of Processes ................................................................................ 5

The Data-flow View of Processes ................................................................................. 7

Other Process Views ................................................................................................... 10

The Systems View ................................................................................................. 10

The Object-oriented View ..................................................................................... 11

Data, Information, and Knowledge: Different Words for the Same Concept? ............ 11

Data are Carriers ......................................................................................................... 14

Information is Descriptive ........................................................................................... 15

The Value of Information ...................................................................................... 16

Knowledge is Associative ........................................................................................... 18

The Value of Knowledge ...................................................................................... 20

Linking Data, Information, and Knowledge ............................................................... 22

3 The Infodesign Methodology ............................................................................................ 25

Underlying Principles .................................................................................................. 25

The “Minimum Data Proportion” Principle ........................................................... 26

The “Maximum Information Proportion” Principle ............................................... 26

The “Maximum Shared Knowledge” Principle ..................................................... 26

The “Minimum Data Transfer Points” Principle .................................................... 26

The “Minimum Data Transfer Costs” Principle..................................................... 27
vi

The “Quality versus Productivity” Principle ......................................................... 27

The “Continuous Improvement” Principle ............................................................ 27

InfoDesign at a Glance ................................................................................................ 27

The InfoDesign Group .......................................................................................... 29

The InfoDesign Group Leader .............................................................................. 30

The InfoDesign Group Facilitator ......................................................................... 30

The InfoDesign Group Member ............................................................................ 30

General Guidelines for InfoDesign ............................................................................. 30

InfoDesign in Detail: Activities, Guidelines, and Representation Tools ...................... 31

Definition Stage: Identify Problems ...................................................................... 31

Definition Stage: Identify Processes ...................................................................... 32

Definition Stage: Select a Process for Redesign .................................................... 33

Analysis Stage: Model the Process ........................................................................ 33

Analysis Stage: Summarize Performance Information .......................................... 37

Analysis Stage: Highlight Improvement Opportunities ......................................... 39

Redesign Stage: Search for Suitable Changes ....................................................... 39

Redesign Stage: Incorporate Changes into the Process ......................................... 42

Redesign Stage: Evaluate Redesign Feasibility ..................................................... 42

Subsequent Stages: Implement and Refine Redesign ............................................ 42

4 The Need for a Shift in Redesign Focus ........................................................................... 43

A Brief Historical Review of Business Process Redesign ........................................... 43

Current Business Process Redesign Practices: A Rehash of Old Methods? ................ 43

Current Focus on Activity Flows and Associated Problems ........................................ 44

5 Validating InfoDesign Through an Action Research Study............................................... 47

Research Hypothesis and Its Negative Form ............................................................... 47

Research Approach Employed: Action Research ........................................................ 47

Process Redesign Work and Information Flow Focus ................................................. 48

Discussion and Conclusion ......................................................................................... 50

Bibliography .............................................................................................................................. 53

Author Notes .............................................................................................................................. 59

Appendices

A Project Schedule ............................................................................................................... 61

B Activity-flow and Data-flow Diagrams Used .................................................................... 63

C Business Process Redesign Guidelines Used .................................................................... 65
vii

FIGURES

1. “Receive Materials” Process of a Chimney Manufacturer ......................................................... 6

2. “Fulfill Order” Process of a Central Kitchen at an Italian Restaurant Chain ............................. 8

3. The Value of Information ........................................................................................................ 17

4. The Relationship Between Data, Information, and Knowledge .............................................. 24

5. Types of Processes According to the Amount of

Knowledge Transfer at Execution Time ............................................................................ 25

6. InfoDesign as a Set of Interrelated Activities ........................................................................... 29

7. Example of Activity Table ....................................................................................................... 34

8. InfoDesign Diagram Symbols ................................................................................................. 35

9. Example of InfoDesign Diagram ............................................................................................ 36

TABLES

Table 1. Examples of Supply-Chain and Knowledge-Intensive Processes .................................... 25
viii
ix

ABSTRACT

Current business process redesign practices, in the defense sector as well as in business in general, are based on several assumptions inherited from Taylor’s scientific management method, including the key assumption that activity-flow representations should provide the basis for business process redesign. While this assumption was probably correct for most organizations in the early 1900s,

it is clearly inconsistent with the fact that, currently “information” is what flows the most in business

processes, even in manufacturing organizations. This project is based on the key assumption that the

current focus of business process redesign approaches should be on information flows rather than

activity flows.

The main goal of this project is to develop a methodology for redesigning acquisition processes

based on knowledge and information-flow analysis. The methodology, called InfoDesign, focuses

on the knowledge embedded in a business process, the information processing resources involved in

execution of the process, and the information flowing through the process. The InfoDesign methodology was developed and partially validated during a one-year project. The validation of the methodology was conducted as an action research study in which one acquisition process involving the U.S.

Government and one key supplier was analyzed and redesigned. The results of the study support the

key assumption on which InfoDesign was built — that current business process redesign approaches

should focus on information flows rather than activity flows.
x
xi

ORGANIZATION OF THIS REPORT

This report is divided into five chapters. A description of each of these chapters is provided below:

• Chapter 1: Research Problem, Goals, and Plan. This segment of the report discusses the

motivation of the research project and its main goals. It also provides details about the project

schedule, main deliverables, and potential impact within the defense sector and elsewhere.

• Chapter 2: Conceptual Foundation. This segment of the report discusses the concept of

process as well as several popular views of processes, with particular attention to the dataflow and work-flow views. It also discusses three fundamental concepts — data, information

and knowledge. This discussion is particularly important because of the rather confusing way

in which these terms are used in both academic as well as more popular ways. We offer new

conceptualizations that suggest that data is a carrier of information and knowledge; and, while

information is eminently descriptive, knowledge is mostly predictive in nature. Although these

conceptualizations are heavily based on previous theoretical frameworks from cognitive science and artificial intelligence, we tried to eliminate technical jargon as much as possible and

explain our views through examples involving simple day-to-day situations.

• Chapter 3: The InfoDesign Methodology. This segment of the report discusses the InfoDesign

methodology, which was developed as part of this project. A methodology for process redesign is necessarily made up of guidelines that are followed by those employing it. Since those

guidelines should be defined for each step of the methodology, there are usually many of

them, several of which may appear disconnected and coming out of nowhere. Given this, key

principles that are used as a basis for the creation of guidelines are discussed in this chapter.

• Chapter 4: The Need for a Shift in Redesign Focus. This segment of the report argues that

current business process redesign practices, in the defense sector as well as in business in

general, are based on several assumptions inherited from Taylor’s scientific management method,

including the key assumption that activity-flow representations should provide the basis for

business process redesign. It also argues that the current focus of current business process

redesign approaches should be on information flows rather than activity flows. This point is at

the source of the development of the InfoDesign methodology.

• Chapter 5: Validating InfoDesign through an Action Research Study. In this chapter, the

point made in Chapter 4 is formalized by means of a hypothesis, which is tested through an

action research study of a business process redesign project. The project results in the redesign

of a software development procurement process involving the Department of Defense (DoD)

and Computer Sciences Corporation. The study supports the claim by showing that the members of a business process redesign team voluntarily favored the use of InfoDesign, which is

based on an information-flow approach to business process redesign over a traditional approach based on activity flows.
xii
1

CHAPTER 1

RESEARCH PROBLEM, GOALS, AND PLAN

Problem Statement

The economic environment surrounding organizations in virtually every industry is undergoing change at a pace that has never been experienced before. This is caused by several factors,

including the fast development of new technologies, the emergence of new competitors, and market pressure for changes. New technologies enable increases in productivity, customer satisfaction,

and market reach. As capitalism spreads throughout the world, new competitors emerge from unlikely quarters, such as firms from other industries or countries that were not previously major

competitors in world trade. Information about features of highly competitive services and products

is quickly disseminated, driving market pressure for change (Kock, 1998). These forces not only

push suppliers to continuously redesign their business process to keep their acquisition process

effective and competitive but also push buyers into similar patterns of change so they can take

advantage of new products and forms of delivery (Davenport, 1993; Deming, 1986; Harrington,

1991).

In addition to the accelerated pressure for change, the nature of work has become more complex and specialized as new knowledge is continuously created and incorporated into the production of goods and services (Davenport et al., 1996), mirroring a larger-scale trend towards knowledge specialization and fragmentation (Hayek, 1996). Products and services are, thus, increasingly

more sophisticated and knowledge intensive, requiring the involvement of a variety of experts,

each holding a key piece of specialized knowledge to be produced and delivered. It has been

shown that, as knowledge becomes more specialized and fragmented, the information flowing

among individuals holding different types of expertise increases substantially (Kock and McQueen,

1996; 1998) and, in many cases, leads to an “information overload” (Evaristo et al., 1995; Kock,

1999).

Current business process redesigning, which focuses on work flows (or activity flows), is inconsistent with the above trends. In fact, many aspects of the current trend have been referred to as

modern-day versions of older techniques. These older methods include the mechanistic methods,

based on the “time-and-motion” analysis developed from the early notions of Adam Smith (1910;

1910a), and the subsequent development of scientific management methods by Taylor (1911). New

process redesign methods are needed. These new methods should focus on knowledge management

and information flow. While their main goal is to fill a methodological gap, these new methods can

complement and potentially replace existing methods based on work flows.

Goal and Approach

The goal of this project is to develop a methodology for redesigning acquisition processes based

on knowledge- and information-flow analysis. This methodology, called InfoDesign, focuses on the

knowledge embedded in a business process, the information processing resources involved in execution of the process, and the information flowing through the process. While the development of
2

InfoDesign is one of the components of this proposal, the methodology combines, develops, and

refines specific aspects of one previously published methodology and two theoretical frameworks

listed below:

• MetaProi stands for Meta Process for Process Improvement (Kock, 1999a). MetaProi is a

refinement of the PROI methodology (Kock, 1995) and is a process redesign method focused

on information-flow streamlining.

• Theory of Constraints (Bramorski et al., 1997; Goldratt, 1990; Goldratt and Cox, 1986;

Goldratt and Fox, 1986). One of the hypotheses of this theory is that a focus on “bottlenecks”

leads to optimal business process design, from both an efficiency and effectiveness perspective. Bottlenecks are defined as subprocesses (or activities) that pose constraints on process

cost reduction and reduce throughput. In other words, the theory hypothesizes that, if process

redesign is conducted (based on the identification and redesign of bottlenecks), the process

will be accomplished cheaper and faster and without any impact on process redesign quality

than if no focus on bottlenecks occurs.

• Information Load Theory (Evaristo et al., 1995). The term “information overload” has been

used in the business literature without first considering the true meaning of “information load,”

the underlying construct. This theoretical treatment suggests that there are several antecedents

of information load, some affecting demand for information processing resources and others

affecting the supply of these resources. “Information load” is how much of the supply is being

used by the demand for these resources. In particular, knowledge about the demand antecedents can be invaluable in controlling the level of information load and, therefore, the potential

performance in certain tasks.

InfoDesign is used in this research project for the identification of “information-flow bottlenecks”

in business processes. Building on MetaProi, a set of guidelines is developed to restructure business

processes based on process modeling and analysis outcomes. Information-load theory is used for the

preparation of these guidelines by providing a conceptual basis for the optimization of information

loads. Part of the objective is to avoid letting the load become too low or too high, situations that are

likely to lead to lower performance levels.

The InfoDesign methodology was developed and partially validated during a project lasting approximately 1 year. The project’s main tasks and subtasks are described in the Project Schedule (see

Appendix A). The validation of the methodology was conducted as an action research study (Checkland,

1991; Elden and Chisholm, 1993; Kock et al., 1997; Winter, 1998) in which one acquisition process,

involving the U.S. Government and one key supplier, was analyzed and redesigned. The process redesign proposal was cross-evaluated for quality and for the likely organizational impact by stakeholders of

the organizations involved. This was performed immediately after its delivery and before its implementation. Six months after the delivery of the process redesign proposal, a review of its implementation was

conducted to assess its bottom-line impact on process efficiency and quality.

The following table lists potential suppliers, who were initially contacted and who have

partnered with the researchers in previous projects; products; and respective buyers within the
3

Project Deliverables

This project has one main deliverable — a methodology, which is described as a set of activities,

guidelines, support forms, and graphical tools for redesigning acquisition processes. (The graphical

representations used in this report are independent from current computerized process-modeling tools.)

The main stages of this methodology include:

(a) Process modeling that is focused on knowledge distribution, information processing resources, and information flow;

(b) Identification of “information-flow bottlenecks” in acquisition processes;

(c) Information-flow analysis focused on the bottlenecks identified in stage (b);

(d) Process redesign based on the analysis performed in stage (c); and

(e) Implementation of process redesign changes.

In addition to the methodology discussed in detail in this report, other deliverables include a

dissemination web site and several publications. These are described later in this chapter under the

heading “Dissemination of Results.” This final report includes a detailed discussion of the action

research study used for the validation of the methodology, conclusions, and suggestions for future

research, refinement, and application of the methodology.

Potential Impact and Significance

Based on the amounts of money involved in U.S. Government acquisition processes, it is clear

that even small improvements can result in large savings. We expect that the InfoDesign methodology will contribute to such improvements.

U.S. Government. We eventually partnered with Computer Sciences Corporation and Lockheed Martin for this research project. Each of the two companies contributed a group of employees to work on the

redesign of a software acquisition process involving the Department of Defense and Computer Sciences

Corporation. (Lockheed Martin often partnered with Computer Sciences Corporation to develop software products.)

Buyer

Supplier Products (U.S. Government)

Computer Sciences Corporation Software U.S. Navy

http://www.csc.com

Day & Zimmerman Munitions U.S. Army

http://www.dayzim.com

Lockheed Martin Rockets and aviation U.S. Air Force,

http://www.lockheedmartin.com/ equipment NASA

Concurrent Technologies Corporation High-end simulation U.S. Navy

http://www.ctc.com equipment
4

Due to resource scarcity — not only physical equipment but also knowledge and human resources — and the increasing irrelevance of geographical location to establish a business, it is likely

that a higher percentage of projects will be distributed in nature in the near future. Therefore, we do

anticipate that this research project will also have another important consequence in the future. Given

the emphasis on information flows, which usually occur asynchronously and independently of geographical location, the knowledge generated by this research project will be particularly useful in the

redesign of acquisition processes involving several geographically distributed suppliers.

Dissemination of Results

The results of this project are being disseminated through the following main outlets: A support

web site, two conference papers, and two journal articles. The conference papers and journal articles

are available from the support web site (the versions on the web site do not incorporate editorial

changes). These outlets are discussed below.

Support Web Site

This web site contains a description of the project; documents developed during the project,

including the final report on the project; and several multimedia components discussing key project

issues. The web site is available at www.mis.temple.edu/earp.

Conference Papers

1. Kock, N. and Murphy, F. (to be submitted), “Communication as the Focus of Business Process

Redesign: An Action Research Study of Defense Contractors,” International Conference on Information Systems [December 2001, Boston, MA].

2. Kock, N. (submitted Feb 2001), “Web-driven Management Thinking: A Look at Business

Process Redesign in the Age of the Internet,” IFIP Conference on E- Business [October 2001, Zurich,

Switzerland].

Journal Articles

1. Kock, N. (submitted Feb 2001), “Changing the Focus of Business Process Redesign from Activity

Flows to Information Flows: A Defense Acquisition Application,” Acquisition Review Quarterly.

2. Kock, N. (accepted, forthcoming), “Managing with Web-based IT in Mind: A Simple Framework Based on Practice,” Communications of the ACM.

3. Kock, N. (2000), “Benefits for Virtual Organizations from Distributed Groups,” Communications of the ACM, V.43, No.11, pp. 107-113.

The support web site and any publications based on this project leave out and/or disguise classified information and any details deemed confidential by the project participants.
5

CHAPTER 2

CONCEPTUAL FOUNDATION

Process Views: Focusing on Certain Aspects of Processes

As a concept becomes more abstract so does the discrepancy in the ways different people construe its meaning. A concept that refers to a tangible object, like that of a chair for example, is likely

to be understood more or less in the same way by two people. With abstract concepts, such as those

used in a process, however, understanding is much less likely to be achieved without further clarification. One of the reasons for this difficulty is that abstractions are not perceived by our five senses as

“real” objects (like a chair that we can see and touch) and, therefore, must be understood based on

abstract models. If these models do not exist or if they are too rough and incomplete, a sense of

perplexity often develops.

As with most abstract entities, processes need to be modeled so people can understand them and,

more importantly, so two or more people can understand them in roughly the same way. Irrespective

of how complex, models are limited representations in most cases, whether of real objects or abstract

entities. A representation of a transistor, for example, can help one predict how it will behave (e.g.,

amplify an electrical input) when an electrical impulse of a certain voltage is applied to it. Still, the

same representation can be almost useless when predicting the operation of the same transistor if the

input is an alternating current with a frequency above a certain level (e.g., as in analog telecommunication circuits). Similarly, a certain representation of a car, such as a diagram in an owner’s manual

that explains the basic operation of the car, can be detailed enough for someone who wants to drive

the car yet useless to someone who needs to repair the car. In fact, perhaps the only characteristic that

is shared by all models is that they are all incomplete.

A few main types of process models or views are discussed in the following subsections. As

discussed above, these views lead to incomplete representations of processes and, therefore, should

be understood in terms of their pros and cons in today’s information- and knowledge-intensive organizational environments.

 The Work-flow View of Processes

Although there seems to be little agreement on what a process is or the main elements that make

it up, the predominant view among academics and practitioners seems to be that a process is a set of

interrelated activities (Hunt, 1996; Ould, 1995). In this sense, processes are seen as activity flows

(a.k.a., work flows) composed of activities that bear some sort of relationship with each other (White

and Fischer, 1994). This means that, if activities are not perceived as interrelated, they are not part of

the same process.

Among activities in processes, there are at least three main types of relationships, which we refer

to as: (a) common predecessor, (b) common successor, and (c) predecessor-successor. These relationships are illustrated in Figure 1.
6

 In this figure, activities are shown within oval shapes, and the arrows indicate the flow of execution of the activities in the process. Also, a rectangular shape represents an external supplier of the

process, whereas a diamond shape indicates a decision point in the process. Each activity is described by

its name and followed (within parentheses) by the organizational function that carries out the activity

and the italicized name of the main tool used by this function. Freestanding text that begins with a

“dash” is used to describe a “product,” which can be a piece of data or a material thing that flows

between activities.

The common predecessor relationship joins together activities that have a common immediate

predecessor activity. In the Figure 1 process, this relationship is shown by the activities order a

replacement batch, which is carried out by the acquisitions assistant (usually by fax), and send a

receipt to supplier, which is also carried out by the acquisitions assistant, who typically uses ordinary

mail. Both activities have the same immediate predecessor — the inspect materials activity — that is

done by the quality inspector, who uses specialized quality inspection equipment. This common

predecessor must be carried out before each of these two interrelated activities.

The common successor relationship connects activities that have a common immediate successor

activity. The activities stock materials and update stock system (the former done by the stock assistant

with the use of a forklift and the latter by the sales assistant on a computerized stock system) are

connected through a common successor relationship. Both activities have a common successor —

the activity check materials in stock against stock system — which is performed by the production

Figure 1. “Receive Materials” Process of a Chimney Manufacturer.

Adapted from Kock et al. (1997a, p. 72).

Aluminum & Co.

Chimney

Accessories & Co.

receive tubes or parts

(acquisitions assistant)

send quality inspection

report to stock assistant

and sales assistant

(quality inspector:

internal mail ) update stock system

(sales assistant:

computer stock system)

–aluminum tubes

–accessory

parts

inspect materials

(quality inspector:

quality inspection

equipment )

–delivery form

materials OK?

send receipt to supplier

(acquisitions assistant:

mail )

yes

no order a

replacement batch

(acquisitions assistant:

fax)

–materials

receipt

–replacement order

stock materials

(stock assistant:

fork lift )

inform quality inspector

 of materials arrival

(acquisitions assistant:

phone or E-mail )

check materials in stock

against stock system

(production manager:

laptop-based computer stock system)

–quality inspection report
7

manager by walking through the stock warehouse and comparing it with the inventory database by

using a laptop-based version of a computerized stock system.

The predecessor-successor relationship, the most common type of relationship between activities, joins together two activities that take place in sequence, one after the other. Note that, as with the

two types of relationships described above, a predecessor-successor relationship can exist even if

there is no flow of data or materials between activities. The activities receive tubes or parts and

inform quality inspector of materials arrival are connected by a predecessor-successor relationship

as they can only be carried out in sequence, the second after the first.

The process of creating work-flow representations of processes is typically called flowcharting. According to Harrington (1991, p. 86), this process is “... an invaluable tool for understanding

the inner workings of, and relationships between, business processes.” Irrespective of this opinion,

however, work-flow representations of processes, such as those in Figure 1, illustrate an important

point — although flowcharts can show the data or materials that flow between activities in a process,

these data or materials do not actually flow between activities. Hence, the data-flow representation in

flowcharts can be somewhat misleading. For example, the delivery form, which apparently flows

between the activities inform quality inspector of materials arrival and inspect materials, in reality

flows between the organizational functions that carry out these activities — acquisitions assistant and

quality inspector. The delivery form is a data repository that allows for the exchange of information

between these two functions. This shortcoming of the work-flow view can be of significant importance if the focus of a process redesign attempt is on the flow of data, not the activity configuration in

a process. This is because the work-flow view “hides” information about the flow of data in organizational processes (Kock and McQueen, 1996).

There are a number of variations of work-flow representations similar to the one shown in

Figure 1. The work flow in Figure 1 itself is an adaptation of the ANSI standard flowchart, and it has

been extensively used in our work with process improvement groups. (See Kock (1995; 1999a) for a

description of the use of this flowcharting tool in process improvement groups.) Flowchart variations

include the block diagram, functional flowchart, functional timeline flowchart, and geographic flowchart. (See Harrington (1991) for a more detailed discussion of these.)

The Data-flow View of Processes

Another traditional view of business processes is through data flows, where processes are seen as

data processing entities. Data-flow representations have been largely used in the 1980s by systems

analysts as an important component of what are known as structured systems analysis and design

techniques (Davis, 1983) — a predecessor of the object-oriented analysis and design approach

(Somerville, 1992).

Data-flow representations have been used chiefly to understand the flow of data within processes

and, later, to automate this flow “as is” rather than to redesign processes. This “automation-of-oldprocesses” approach has been the target of strong criticism in the early 1990s and has often been

described as the main cause of the low return on investment in information technology (IT) observed

in both the 1970s and 1980s. The service sector has been particularly affected by IT’s low return on
8

investment, which has steadily declined to even negative figures; and IT investment has led to a

decrease in productivity in a number of service industries, such as banking and insurance (Hackett,

1990).

Like the work-flow view of processes, the data-flow view can be expressed through a family of

graphical representations, from which the most widely used is the data-flow diagram (DFD) (Gore

and Stubbe, 1988; Pressman, 1987). An example of a DFD obtained from the analysis of the flow of

data between the restaurants and the central kitchen of an Italian restaurant chain is shown in Figure

2. In this figure, a rectangular shape represents a data source or destination — the restaurant manager

and the central kitchen manager functions. Arrows indicate the flow of data, which are described by

freestanding text located beside the arrows. Oval shapes represent activities. Open-ended rectangles

represent data repositories.

The process mapped through the DFD in Figure 2 starts with a chain restaurant manager, who

tells the manager of the central kitchen, where all dish items are prepared, that the restaurant is short

of some specific items (e.g., Bolognese sauce, spaghetti, Italian bread). The manager of the central

kitchen then fills out a form, specifying what items are out-of-stock and which restaurant needs them.

This form is then placed in the assistant manager’s in-box. Approximately every 2 hours, the assistant

manager of the central kitchen goes through the forms in the in-box, generates the orders to be prepared by the cooking team, and stores the orders in the out-box. When scheduling, the assistant

manager tries to optimize the work of the cooking team by grouping requests that require the same

resources (e.g., ingredients, cooking equipment). The cooking team then collects the orders from the

assistant manager’s out-box and prepares the Italian dish items ordered on a first-come, first-served

basis. They also pack and stock these items in the delivery room as soon as they are ready. Delivery

Figure 2. “Fulfill Order” Process of a Central Kitchen at an Italian Restaurant Chain.

Adapted from Kock (1995, p. 44).

restaurant

manager

–orders

central kitchen

manager

–out-of-stock items –restaurant –out-of-stock items

per restaurant

–out-of-stock items

–out-of-stock items –restaurant

–order

prepare and

stock order

(central kitchen's

cooking team)

–order

fill out order

delivery form

(central kitchen's

chief cook)

deliver items to

restaurant

(delivery team)

–delivery

–delivery

issue order

(central kitchen's

assistant manager)

–deliveries
9

forms are filled out and attached to each of the packaged items for the restaurants, which are periodically delivered by the central kitchen’s delivery team.

Although an incomplete model of real processes, representations based on the data-flow view of

processes, such as DFDs, show the flow of data and how it is stored in a relatively clear way. As such,

one can reasonably expect these representations, in some cases, to be more appropriate than representations based on work flow, such as flowcharts. This is true especially in the analysis of processes

where the flow of data is particularly intense.

A dramatic increase in the flow of data has been predicted as one of the characteristics of today’s

and the near future’s economy, particularly in the developed and developing countries (Drucker,

1989; Toffler, 1970; 1991). Hence, it is reasonable to expect that representations based on the dataflow view of processes become more useful in process improvement attempts than representations

based on the work-flow view. As mentioned before in this chapter, the latter type of representations

tend to provide a poorer picture of the flow of data, preventing the identification of, for example, data

“buffers.” Data buffers are organizational functions (rectangular shapes in DFDs) that perform the

job of transferring data among other organizational functions. In a given process, these “buffers” are,

therefore, strong candidates to be removed from the process and replaced by information technology

applications. This is the case in Figure 2, where the function central kitchen manager acts as a buffer

between the restaurant manager and the assistant manager of the central kitchen. In the process analyzed, the manager of the central kitchen receives data from the restaurant manager and stores it in a

data repository that will be used as input by the assistant manager of the central kitchen to generate an

order. A more efficient version of the process would have the restaurant manager storing this data

with no mediation of the manager of the central kitchen, who could use that time to do other things.

How much detail should be in the diagram when mapping processes through either flowcharts or

DFDs? The activities in a process representation can be seen as subprocesses themselves, which can,

in turn, be broken into new activities. In fact, seeing the activities of processes as lower-level processes and generating more-detailed diagrams by “exploding” these lower-level processes is a common practice in both flowcharting and DFD generation (Davis, 1983; Maull et al., 1995; Pressman,

1987). In doing so, however, two simple guidelines are suggested (Kock and McQueen, 1996):

• Each graphical representation of a process should not have more than 14 activity symbols.

• In a process improvement context, the breadth of improvement sought should define the level

of detail when modeling processes.

The first guideline is based on studies about general human cognitive limitations relating graphical representations and diagrams used in systems analysis and design (Kock, 1995a). The second

guideline is based on a relatively new concept — the breadth of process improvement (Hall et al.,

1993). Roughly speaking, the breadth of improvement correlates the number of different departments

or distinct areas affected by process improvement decisions. The larger the breath of improvement,

the less process detail is necessary. If one wishes to improve processes that cut across several (perhaps

all) of the departments of an organization, the process representation should comprise little detail
10

about subprocesses that belong to individual departments. As a general rule of thumb, the total number of high-level processes used to effectively represent any organizational unit can be anywhere

between 10 and 20 (Hammer and Champy, 1993; Maull et al., 1995).

Other Process Views

Although the two previously discussed process views — the work-flow views and the dataflow views — are the most relevant ones for the purposes of this project, there are other views of

processes. Among these are the systems view and the object-oriented view, briefly discussed below.

The Systems View

The systems view of processes is based on the traditional concept of system — an assembly of

parts that cannot be understood just in terms of its components. A system can be defined by its

emergent properties, which are system properties and, therefore, meaningless in terms of the parts that

make up the system. This concept is illustrated in the following excerpt by Checkland and Scholes

(1990, p. 19):

The vehicular potential of a bicycle is an emergent property of the combined parts of

a bicycle when they are assembled in a particular way to make the structured whole.

According to the systems view, a process can be operationally defined as an abstract entity that

represents the transformation of inputs into outputs (Childe et al., 1994; Childe, 1995; Kock, 1995a).

In a process, suppliers provide inputs, and customers consume outputs. The transformation of inputs

into outputs is aimed at adding value to the customers of the process. The inputs and outputs of a

process may be of three different types — goods, services, and data (Juran, 1989; Kock and Tomelin,

1996).

While philosophically appealing, the main problem with the systems view of processes is that it

adds little to our understanding of the inner workings of a process and, therefore, may be of little use

to those who try to change the process. In the system view, processes are defined by means of sets of

emergent properties that characterize them; the relationship between their components is of secondary importance.1

In spite of its limitations, the systems view has proven to be more useful than the work-flow view

in the analysis of very complex (and often “messy”) processes, such as those related to strategic

decision making. These processes typically cannot be analyzed as work flows because, among other

things, the number of activities and decision points required to represent them is too large to allow for

effective modeling.

1 We are referring mainly to the British systems perspective here, which has been highly influenced by Peter

Checkland and colleagues. Another systems view of processes that is popular in American research circles, particularly

in the field of operations research, focuses on managing and coordinating complex interactions, e.g., global warming.

This other systems view later evolved into the so-called “chaos theory.”
11

The Object-oriented View

One of the main proponents of the object-oriented view of processes is Ivar Jacobson, who developed a methodology to model processes as data objects. Jacobson’s methodology was based on the

concept of the software object (Jacobson et al., 1995). A software object is a data repository with a

number of associated operations. These operations are also called methods in the technical jargon of

object-oriented analysis and programming (Thomas, 1989). A software object typically stores data in

its attributes, which are analogous to the attributes of real objects like a chair (e.g., the attributes of an

object chair are its color, weight, and number of legs) (Partridge, 1994).

The object-oriented view can be seen as an extension of the data-flow view in which data

repositories, represented in DFDs by open-ended rectangles (see Figure 2), are permanently linked

to activities that change the content of those repositories. There is a clear advantage in adopting this

view. Many believe that object-oriented programming is increasingly becoming the dominant software development paradigm (i.e., it has been adopted by most of the major players who were

active in the software development industry during the 1990s). Also, the object-oriented view of

processes allows for an inexpensive transition between: (a) process analysis and redesign, and (b)

the development of new computer systems to support the implementation of the new redesigned

processes.

However, the object-oriented view has been criticized for its excessively technical orientation,

which prevents less sophisticated users (i.e., those who are unfamiliar with object-oriented concepts)

from effectively understanding it in its full complexity and adopting it in process improvement projects.

Process analysis and design methodologies using object-oriented representations, such as the Unified

Modeling Language (UML), are still too complex to be widely accepted and used in organizations in

spite of the fact that UML has been endorsed by several “heavyweights” in the computer community

(Meyer, 1998). This has been compounded by the fact that, among less sophisticated users, there are

often senior managers who are usually absorbed in strategic management issues and, therefore, do

not have the time to become technically sophisticated. The problem with this situation is that the

support of such managers is a fundamental ingredient in successful process improvement initiatives

(Davenport, 1993).

Moreover, some recent software industry developments have turned the building of customized

computer systems (often “in-house”), which is facilitated by the adoption of the object-oriented view

of processes, into an often undesirable and expensive alternative. Buying and customizing of-theshelf applications and enterprise resource planning systems as well as outsourcing data and application management to enable new organizational processes are seen by many as more desirable approaches made possible by such developments.

Data, Information and Knowledge: Different Words for the Same Concept?

We hear the words “data,” “information,” and “knowledge” quite often being used as if they were

synonymous; but are they actually the same thing? If not, what are the differences?
12

The contribution of IT providers has perhaps been unmatched in its potential to add to our

confusion over the distinction between data and information. Examples can be found in almost any

specialized IT publication, conversations with IT company representatives, and even in public

speeches by IT “gurus.” For example, a senior vice-president of a large software development

company was one of the keynote speakers of a recent information systems conference. He referred

to the advantages of a well-known commercial group support system in the following terms:

“... information overflow can be considerably reduced ... for example, a few weeks

ago I prepared a 2 megabyte report and sent it via electronic mail to ten people. Each

of these ten people forwarded a copy of the report to about ten other people ... as a

result, my report had generated a flow of 200 megabytes of information in the network, in less than four days ...”

In the example above, the speaker was referring to data, which can be measured in megabytes, as

synonymous with information. This can often be misleading because large sets of data may have very

low information content, depending on how well the data receiver is prepared to make sense of it.

Mistakenly identifying data as information is as commonplace as confusing knowledge with information.

It is curious that the confusion over what information and knowledge are has been nurtured by

some of those people who are widely recognized as among the forerunners of the study of information and knowledge and their impact on organizations and society. For example, one of the most

highly regarded management consultants and researchers, Peter Drucker (1989, pp. 207-208), describes the emergence of the information-based organization in the following terms:

... the business, and increasingly the government agency as well, will be knowledge-based, composed largely of specialists who direct and discipline their own

performance through organized feedback from colleagues and customers. It will be

an information-based organization ... Today’s typical organization, in which knowledge tends to be concentrated in service staffs perched rather insecurely between top

management and the operating people, will likely be labeled a phase, an attempt to

infuse knowledge from the top rather than obtain information from below [our emphasis].

If information and knowledge were the same thing, why use two words when just one would

suffice? Even though information and knowledge mean different things to different people, most

people use them in different senses. The main reason these two words are often used interchangeably

is exactly because there is no agreement over their meaning.

But, why should we worry about the different nature of data, information, and knowledge? One

reason is because an ocean of data may contain only a small amount of information that is of any

value to us, and sifting through this ocean of data may be severely time-consuming (Goldratt, 1991).

But there are other reasons, and they relate to our understanding of the world.
13

The world is not only what we perceive it to be through our senses; it is a combination of these

perceptions and what is stored in our body, mostly in our brain in the form of neural networks (Callatay,

1986; Dozier, 1992). We can develop our neural networks by interacting with matter and living

organisms, notably other human beings. However, in order to interact with other human beings, we

need to externalize what is stored in our neural networks by means of a code. Other human beings

must understand this code so communication takes place.

If data and information are the same, how can the content of one E-mail message be interpreted

differently by various recipients? Let us suppose that an E-mail message, written in Spanish (a specific code), is sent to two different recipients. While one of the recipients can read Spanish very well,

the other cannot. In this example, the message takes up the same disk space (say, 3.6 kilobytes) on the

computers of each of the recipients, which is a measure of the amount of data related to the message.

Yet, its information content is much higher for the recipient who can read Spanish than for the recipient who cannot.

If data and information are the same, then they should not yield different “amounts” when measured for the same object (in this case, the E-mail message in Spanish). It is important to stress that

different terms could have been used in this discussion; for example, instead of “data” and “information,” “alpha-stractum” and “capta” could be used. The more commonly used terms data and information are used in this report because we believe that the sense in which we have just used these two

terms is their most “usual” sense.

The distinction between knowledge and information is a bit more abstract than the distinction

between information and data. In order to make this distinction as clear as possible, consider the

following dialogue between a doctor (D) and her patient (P):

D: So, what brings you here today?

P: I don’t know doctor, I’ve been feeling a bit strange in the last couple of weeks.

D: What do you mean by “strange”?

P: Burning eyes, stuffy nose ... and these things go and come several times a day.

D: Any headaches or fever?

P: No, not at all.

D: Well, we’ll run a checkup on you, but I think you probably have an allergy.

The patient was feeling the symptoms of what could be an allergy and, therefore, went to see the

doctor, an expert who likely knows more about medicine than the patient. The patient described the

symptoms, and the doctor made the tentative diagnosis, “... you probably have an allergy.” Is what

the patient told the doctor enough for anyone without any medical expertise to come up with the same

tentative diagnosis? Well, if this were the case, very few people would agree to pay doctors for

consultations. Doctors possess more of something the patients do not have, something typically referred to as knowledge, in the specific field of medicine.
14

Is the nature of the expert knowledge possessed (by the doctor, in this case) the same as that of the

perception of symptoms experienced by the patient? No, for the simple reason that expert knowledge

can be used to generate conclusions based on the description of symptoms. This is something that the

descriptions alone cannot do. Therefore, the natures of descriptions and expert knowledge are different, and it can be shown that neither of them is the same as the nature of data. This also suggests that

descriptions are instances of something unique — referred to here as information.

Data are Carriers

In the usual sense of the term, data are considered carriers of information and knowledge. The

flow of data in organizational processes among the functions that carry out process activities takes

place through various media, particularly, paper, digital electrical impulses (e.g., electronic data interchange systems), analog electrical waves (e.g., telephone), electromagnetic waves (e.g., radio), and

air vibrations (e.g., face-to-face conversation). Data can also be stored for later use on different storage media, such as magnetic media (e.g., hard and floppy disks), paper, and volatile digital memories

(e.g., RAM memory in personal computers).

Data are either transferred or stored through a process of “changing” or generating perturbations on a given medium. A blank sheet of paper, for example, can be used for data storage (e.g.,

to write down an address of a friend) or transfer (e.g., to write a memo to an employee by

applying ink to paper). Or, from a more business-oriented perspective, if a machine operator

wants to tell his supervisor about a problem with a metal-shaping machine, the operator can

approach the supervisor and speak face-to-face. In doing so, the operator uses vocal cords to

generate vibrations in the air (volatile data) that will be received and decoded by the recipient

through hearing organs.

Data will only become information or knowledge when it is interpreted by human beings (Kryt,

1997) or, in some cases, by artificial intelligence. (See Russel and Norvig, 1995, for an example.) As

data can be stored and transferred by process functions through applying changes to storage and

communication media that will be interpreted by other process functions, an operational definition

within the context of process management might be as follows:

If John performs an organizational function, such as carrying out an activity in an

organizational process, then the data are permanent or volatile changes applied to a

communication medium by John to store or transfer information or knowledge. These

will later be used by John or someone else (or an artificial intelligence agent) to perform an organizational activity.

The measurement of data depends on the medium used to store or transfer it as well as on the code

used. In most organizational processes, data can be measured in words or symbols, when the medium

used is paper, and in bits or bytes (1 byte is a group of 8 bits), when the medium used is a digital one.

In many ways, a bit can be considered the smallest and most fundamental unit of data. It can take

only two values: 0 (or false) and 1 (or true). A group of 8 bits forms a byte; and, since the number of
15

possible bytes is 28 or 256, there can be a direct correspondence between bytes and certain symbols

(e.g., the letters of the English alphabet and other alphabets). One such set of symbols, which is

largely used to convert alphanumeric characters into bytes and vice-versa, is called the ASCII code

(American Standard Code for Information Exchange). Most computer operating systems use the

ASCII code, or an extended version of it, to map symbols that have meaning to human beings (e.g.,

letters and numbers) into bytes stored in any of the computers’ data storage devices (e.g., RAM, hard

disk, etc.).

Information is Descriptive

A hot issue in business circles in the 1990s has been the advent of the “information society,” the

“information era,” and the “information-intensive” organizations. However, any discussion regarding

these issues should, of necessity, focus on the nature of information. What is it? Is it a specific kind of

entity? If yes, how can we differentiate information from other similar entities? These are core questions in the continuing debate within a number of disciplines, such as information systems, management science, engineering, and philosophy. A substantial portion of the literature in these disciplines

is devoted to defining information, however, as Budd and Raber (1996, p. 217) note in the following:

In the course of doing so [i.e. defining information], many aspects of information

(technical, physical, semantic, epistemological) are featured as part of the discussion.

Part of what emerges is a multifaceted idea and thing that is, at times, defined in terms

of what it is not. For instance, information is not merely data; organization and intended meaning transform the bits of data into something that can inform.

From a process-oriented view, information can be seen as carried by data and as being eminently

descriptive. From a linguistic perspective, the typical instance of information is the utterance called

assertion. One example of assertion is: “Today is a sunny day.” Independently of what this assertion

means exactly (the word “sunny” can mean different things to different people, from sparsely clouded

to clear-sky weather), it provides a description of the current state of the environment surrounding us.

If the environment is seen as an object, the assertion can be seen as defining an attribute of the

object, in this case, the weather as sunny.

Information can be qualified in different ways. It can be more or less complete or accurate; and it

can refer to the past, present, and future. For example, the assertion, “Today is hot!” conveys less

accurate information than the assertion, “Today’s average temperature is 85 degrees Fahrenheit.”

Both assertions describe the present, that is, today. The assertion, “The temperature on this day during

the last 3 years has averaged 87 degrees Fahrenheit,” provides information about the past. The assertion, “Tomorrow the top temperatures will be in the low 90s,” provides a description of the future.

Although similar to descriptions of the past and the present, descriptions of the future, by their own

nature, always carry a certain degree of uncertainty.

Knowledge, which will be discussed in more detail in the next section, is often used to generate

more information based on information at hand. The information thereby generated (or inferred) is

usually not obvious and, therefore, possesses some added value in relation to the primary information
16

received as an input by the knowledge holder. One example is the generation of information about the

future (e.g., the weather in New York tomorrow) based on information about the present and past

(e.g., the weather patterns in New York during the last 2 years) up to now. This type of information

about the future is produced by meteorologists, based on their knowledge about the science of weather

forecasting. It is then purchased by news services that, in turn, broadcast the information to their

audiences and, in the process of doing so, manage to make a profit.

The Value of Information

One interesting aspect of information is that it has value — how much someone is willing to pay

for it and can benefit from it. In general, this seems to directly correlate some of its attributes. Among

these attributes, it has:

• Advanceness, that is, how much time in advance it describes the future (if it refers to the future

rather than to the past or present);

• Accuracy, that is, how accurate the description is; and

• Completeness, that is, how complete the description is.

Let us explain the different nature of the attributes above in a business context. The “corporate

war” between Coca-Cola and Pepsi in the 1980s was largely one of product differentiation (Ramsey,

1987). Both Coca-Cola and Pepsi tried to increase their shares of the “cola” soft drink market by

launching new differentiated (e.g., diet) products ahead of each other. Consider the similar situation

of two companies, A and B, competing for 2 million customers in the same industry. Each customer

consumes a product supplied by both companies. Analogous to the “cola” war, the product is essentially the same, the main difference being the brand. Each customer consumes 70 units of the product,

which costs $3 each, every year; this makes it a $420 million per year market. Company A has 90

percent of the market or $378 million, while Company B has the other 10 percent or $42 million.

Both companies sell with a pretax profit margin of 17 percent, which yields approximately $64

million for Company A and $7 million for Company B in absolute pretax profits.

Now, suppose Company B decides to launch a new product into the market, whose development

time is approximately 9 months. The product has the potential to bring Company B’s market share up

to 20 percent, and send Company A’s share down to 80 percent. This would raise Company B’s

pretax profits up to about $14 million and make Company A’s profits plummet to nearly $57 million.

From Company A’s perspective (the value of information always depends on its user and the context),

one piece of information — the information that Company B is going to launch a new product — can

make a big difference. This piece of information can have a high advanceness if it is provided to

Company A well in advance of the product launch, which would enable Company A to take appropriate countermeasures. The same piece of information can have a high accuracy, providing accurate

details about the product that is going to be launched (e.g., it might include the precise date of launch).

The information can also have high completeness by providing a rich description of the new aspects

of the product (i.e., the new flavor, amount of saturated fat, sweetener used, etc.).
17

If Company A has no access to information about the new product launch and obtains some

imprecise information a few weeks before the new product is launched, it will have to endure a loss

in pretax profits of $7 million — the worst-case scenario. However, if it gets accurate and complete

information early enough, it can take preventive measures whereby it can at least reduce its losses.

For example, if the information is obtained more than 9 months in advance (i.e., has high advanceness)

but leaves uncertainty about the characteristics of the product (i.e., has low accuracy and completeness), Company A might have to develop a range of new products to dampen the potential impact of

Company B’s new product on the market share. Its profits may still be reduced due to increased

product development costs.

Having access to detailed information about Company B’s new product (i.e., highly accurate and

complete information) only 4 months before the launch (i.e., low advanceness information) may lead

to a similar end result; that is, Company A may be able to develop an intermediary product that will

reduce the impact of Company B’s new product on market share.

Perhaps the best scenario is that, if Company A has access to highly detailed information (i.e.,

highly accurate and complete information) about Company B’s new launch early enough (i.e., the

information has high advanceness), it can develop a similar new product and get it out into the market

before Company B. According to our initial assumptions, this could potentially bring Company A’s

market share up to 95 percent and increase profits by about $4 million.

In the example above, no information or information with low accuracy, completeness, or

advanceness, would be of low value to Company A. Information with high accuracy and completeness, but low advanceness (or vice versa) would have a medium value as it could prevent a loss of $7

million in pretax profits a year. Finally, information with high accuracy, completeness, and advanceness

would have a high value, enabling an increase in profits of $4 million a year. This relationship between information value and its attributes is illustrated in Figure 3.

Although the example above is concerned with a decision-making process at the strategic level,

the relationship between information value and the attributes advanceness and accuracy can be extrapolated from most organizational processes. Simply put, process-related information seems to be

an important enabling factor for the members of a process team (i.e., those who perform process

activities) to do their job efficiently and effectively, whatever the process is.

Figure 3. The Value of Information.

High Advanceness Medium Value High Value

Low Advanceness Low Value Medium Value

Low Accuracy High Accuracy

and Completeness and Completeness
18

Knowledge is Associative

While information is eminently descriptive and can refer to the past, present, and future, knowledge is highly associative. That is, knowledge allows us to “associate” different world states and

respective mental representations. These representations are typically linked to, or described by, pieces

of information (i.e., knowledge allows us to link different pieces of information and make decisions

based on associations). The associative aspect of knowledge can be divided into two types, namely

correlational and causal, which are, in turn, only two types of what is referred to by Weick and

Bougon (1986, p. 104) as “cognitive archetypes.”

Correlational knowledge usually connects two or more pieces of information that describe events

or situations that have happened, are happening, or will happen at the same time. Causal knowledge

connects pieces of information that describe the state of the world at different times. For example,

consider the associative knowledge represented in the following decision rule: “If John has a fever and

is sneezing, then John is likely to have a cold.” The knowledge embodied in this decision rule is of the

correlational type because it affirms that someone who has a fever and sneezing is, in fact, displaying

typical cold symptoms (i.e., “fever,” “sneezing,” and “cold”) typically happen at the same time.

Another example of a different type of knowledge is provided by the rule, “If John smokes a lot,

then he will probably die from lung cancer.” This decision rule expresses causal knowledge. As such,

the rule connects two events that take place at different times — John smokes a lot in the present, and

John may dye of lung cancer in the future. Dennett (1991, p. 144) refers to causal knowledge when

he claims that:

The brain’s task is to guide the body it controls through a world of shifting conditions

and sudden surprises, so it must gather information from that world and use [it] swiftly

to “produce future” — to extract anticipations in order to stay one step ahead of disaster [original emphasis].

Knowledge drives the flow of myriad decisions that have to be made even in the simplest organizational processes. Steel plants, for example, rely on process teams to load and operate smelters.

Consider the predictive knowledge expressed in the rule, “If the smelter is set at a temperature of

3,000 degrees Celsius, then a 1-ton load of steel will be smelted in 43 minutes.” This is one of the

pieces of knowledge that allows a smelter operator to predict that a batch of solid steel weighing

about 1 ton will be in liquid form approximately 43 minutes after it is loaded into the smelter, if the

smelter is set properly. This prediction allows the smelter operator to program a stop in the smelting

process at the right time and let the liquid steel flow out of the smelter, which saves energy and, at the

same time, prevents the steel from overcooking.

For teamwork to yield effective and efficient outcomes, those who perform activities in a process

must share predictive knowledge. In the example, those who use the steel in liquid form for shaping

steel parts should ideally hold at least part of the knowledge held by the smelter operator. If they know

of the “43 minute rule,” they can also predict that a batch of steel will be ready 43 minutes from the

time it is loaded in solid form and have their own equipment prepared at the right time to work on the

liquid steel.
19

In general, business knowledge is inextricably linked with decision making (Olson and

Courtney, 1992; Holsapple and Whinston, 1996), perhaps because one of the best ways of assessing the actual value of knowledge is through the assessment of the outcomes of decisions

made based on it. Holsapple and Whinston (1996, p. 6) talk of the importance of knowledge for

decision making:

For centuries, managers have used the knowledge available to them to make decisions

[original emphasis] shaping the world in which they lived. The impacts of managers’

decisions have ranged from those affecting the world in some small or fleeting way to

those of global and lasting proportions. Over the centuries, the number of decisions

being made per time period has tended to increase. The complexity of decision activities has grown. The amount of knowledge used in making decisions has exploded.

There is no sign that these trends are about to stop. If anything, they appear to be

accelerating.

Knowledge has been distinguished from information. It is also linked with decision making in

different fields of research and academic disciplines. In the field of artificial intelligence, for example,

information has been typically represented through “facts.” Knowledge, on the other hand, has been

expressed by means of a number of different representations, such as semantic networks, frames,

scripts, neural networks, and production rules; the latter is the most common in practical knowledgebased computer systems (Callatay, 1986; Holyoak, 1991; Olson and Courtney, 1992). Production

rules are conditional statements in if-then form, like the ones used to exemplify knowledge in this

section.

In the fields of psychology and social cognition, knowledge has been expressed through schemas

(Lord and Foti, 1986) and cognitive maps (Weick and Bougon, 1986). These are, in turn, seen as

guiding individual and group behavior and using, as input, environmental stimuli obtained through

the senses. The concept of schema was developed as a reaction to studies of memory pioneered by

Ebbingaus, who made use of arbitrary materials and sensorial stimuli to determine factors that influence the formation of memory and recall of information (Gardner, 1985). The development of the

concept of schema is credited to Bartlett (1932), who used an Indian folktale called “The War of the

Ghosts” to show that existing mental structures strongly influenced memory formation and recall.

Such existing mental structures, which were used by Bartlett’s study subjects to process information

coming from the tale, were called schemas. Essentially, Bartlett has shown that individuals possessing different schemas would interpret the tale, which is filled with strange gaps and bizarre causal

sequences, in substantially different ways.

In biology (more particularly in neurology) knowledge is typically associated with long-term,

nerve-based memory structures that mainly process information (Pinker, 1997). Information is seen

as usually associated with short-term neural connections that appear to “vanish” from conscious

memory after a while. For example, the knowledge of how to operate a telephone is stored in longterm memory structures, whereas the information represented by a phone number is stored in shortterm memory structures.
20

The Value of Knowledge

Knowledge is usually much more expensive to produce than information. For example, information in the form of mutual fund indicators (e.g., weekly earnings, monthly price fluctuation, etc.) is

produced by means of simple calculations performed on data about share prices and their fluctuation

over a time period. The knowledge of how mutual fund indicators fluctuate, however, requires years

of analysis of information built up over time. This analysis of information leads to the development of

knowledge that allows an expert investor to select the best mutual funds according to the configuration of the economy. This leads us to the question: How is knowledge produced?

Comparative studies of experts and nonexperts suggest that expertise is usually acquired through

an inductive process in which generalizations are made based on the frequency with which a certain

piece of information occurs. These generalizations are the basis for the construction of knowledge

(Camerer and Johnson, 1991).

A different and less common method used to generate knowledge is deduction, whereby hidden

knowledge is produced based on existing knowledge taken through a set of logical steps (Teichman and

Evans, 1995). This method has been used in the development of a large body of knowledge in the form

of “theorems,” particularly in the fields of mathematics and theoretical physics (Hawking, 1988).

An example of knowledge-building through induction is that undergone by novice investors in

the stock market. The observation that shares of a small number of companies in high technology

industries have risen10 percentage points above the Standard & Poor’s 500 Average Index during a

period of 6 months may prompt novice investors to put all of their money into these shares. However,

a professional investor with10 years experience as a broker in the stock market knows that a 6-month

observation period is not long enough to support such a risky decision and opts for a more diversified

portfolio. In cases such as these, a novice will probably sell, based on the same pattern used when

buying, and will eventually lose money. These decisions were based on inferences based on a time

span that is too short, leading the novice investor to buy shares that are overvalued and sell these

shares when they are undervalued. According to Boroson (1997), most nonprofessional investors

follow this recipe, which, in most cases, leads to disastrous consequences.

The example above illustrates a key finding from research on cognitive psychology — people

usually tend to infer knowledge based on the observation of a small number of events, that is, on

limited information (Feldman, 1986). Moreover, once knowledge structures are developed, changing

these structures can become more difficult than developing them from scratch (Woofford, 1994). A

conversation that one of us (Ned Kock) recently had with a university colleague illustrates these

cognitive biases. The colleague had gone to two different agencies of the New Jersey Motor Vehicle

Services (MVS) where he met employees who lacked sympathy and friendliness. He also had gone

to a similar agency in Pennsylvania, whose employees he found to be very nice. Later, during a chat

with friends, he said:

“... All MVS employees in New Jersey are very grumpy, difficult to deal with ... The

state of Pennsylvania is much better in that respect ...”
21

He had just made a gross generalization, given the small sample of MVS agencies visited — two in

New Jersey and only one in Pennsylvania. Although he agreed this was a generalization, he was nevertheless adamant that he would never go to a New Jersey MVS agency again, unless it was absolutely

necessary. If this was the case, he said he would ask a less “touchy” person to go — his wife.

The development of theories of knowledge (or epistemologies) and scientific methods of inquiry

has been motivated by a need to overcome cognitive biases as illustrated above. This has been one of

the main common goals of such thinkers as Aristotle, René Descartes, Gottlob Frege, Bertrand Russell,

Karl Popper, and Thomas Kuhn. Epistemologies and scientific methods have provided a basis for the

conduct of research in general and, in consequence, for technological advances that have shaped

organizations and society. Every year hundreds of billions of dollars are invested in research with the

ultimate goal of generating highly reliable and valid knowledge. And the market value of organizations is increasingly assessed based on the amount of knowledge that they possess rather than on their

material assets base (Davidow and Malone, 1992; Toffler, 1991).

Paul Strassmann, a former information technology executive at organizations such as Xerox,

Kraft Foods, and the U.S. Department of Defense, suggests that variations in the perceptions of

organizational knowledge account for the growing trend toward overvaluing or undervaluing common stocks in the share market. According to Strassmann, the perception that a stock is overvalued

stems from the failure of current accounting systems to account for the knowledge assets of organizations, and he presents an impressive array of data to support this idea. Abbott Laboratories is one of

the companies he used to illustrate this point.

Over a period of 7 years from 1987 to 1994, the ratio between Abbott’s market value (defined by

stock price), and its equity has swung from five up to nearly eight and back down to about seven.

However, the ratio between market value and “equity-plus-knowledge assets” remained almost constant over that period, smoothly gravitating around two. This supports Strassmann’s (1997, p. 13)

position that the market perceives the accumulation of knowledge assets, which is reflected in the

high correlation between share prices of organizations and their knowledge assets, even though the

knowledge assets are not shown on a company’s balance sheet:

The sustained stability of the market-to-capital ratio, which accounts for the steady

rise in the knowledge capital of Abbott Laboratories confirms that the stock market

will recognize the accumulation of knowledge as an asset even though the accountants do not. The stock market will also reward the accumulators of knowledge capital

because investors recognize that the worth of a corporation is largely in its management, not its physical of financial assets.

When we move from a macroeconomic to a microeconomic perspective and look at the business

processes of a firm, the trend toward valuing knowledge seems to be similar to the one just described.

Knowledge allows for the prediction of process-related outcomes, from the more general prediction

of acceptance of a new product by a group of customers to much more specific predictions, such as

slight manual corrections needed on a computer board surface after it goes through an automatic drill.

Correlational knowledge enables process-control workstation operators at a chemical plant to link a
22

sudden rise of an acidity gauge to an incorrect setting of the flow through a pipe valve. This enables

the operators to take the appropriate measures to bring the acidity level down to normal.

The workers who hold bodies of expert knowledge are rewarded according to their ability to

perform process activities in an efficient and effective way. This is typically done through linking

different types of information, which can be done through formal educational or personal experience

(i.e., the building of mental knowledge bases), and generating information about the future based on

information about the past or present (i.e., predicting the future). Organizational wealth is closely

linked to the ability to build and use technological artifacts to control future states of the (economic,

physical) environment in which organizations operate. However, this control is impossible without

the related ability to predict the future, which, in turn, relies heavily on predictive knowledge.

Organizational knowledge is believed to be the single most important factor that ultimately defines the ability of a company to survive and thrive in a competitive environment (Davidow and

Malone, 1992; Drucker, 1995). This knowledge is probably stored mostly in the brains of the workers of an organization, although it may also be stored in computer systems and databases (Alster,

1997; Strassmann, 1996; 1997) and other archival records (e.g., printed reports).

Whatever form it takes, knowledge is a commodity; and, as such, it can be bought and sold,

which makes its value fluctuate according to the laws that regulate supply and demand. Abundant

knowledge, which can be represented by a large number of available professionals with the same

type of expertise, becomes cheap when supply surpasses demand, which is typically reflected in a

decrease in the salaries of some groups of professionals. On the other hand, a situation in which

some types of highly specialized knowledge are in short supply, while demand grows sharply in a

short period of time, can lead the knowledge holders to be caught by surprise when faced with

unusually high bids by employers. For example, Web Java programmers were being offered salaries of up to $170,000 early in 1996, even though the demand for their new expertise was virtually

nil until 1995. This was the year Java was first released by Sun Microsystems and 2 years after the

University of Illinois began the distribution of its World Wide Web browser Mosaic.

Linking Data, Information, and Knowledge

Although they are different conceptual entities, data, information, and knowledge are inextricably connected. This may be one of the reasons why they are so often confused. As discussed before,

data are perturbations on a communication or storage medium that are used to transfer or store information and knowledge. Therefore, knowledge and information can neither be communicated nor

stored without data.

Information is used to describe the world and can provide a description of the past, present, and

future. (Information about the future always carries a certain degree of uncertainty.) Correlational

knowledge allows for the linking of different pieces of information about the present. In this case,

usually some of the information pieces are obvious and are used as a departure point; and the other

pieces are hidden and allow for relevant decisions. Predictive knowledge enables the production of

information about the future, typically based on information about the past and the present; that is,

information is generated based on both correlational and predictive knowledge. However, the reverse
23

relationship is also valid; that is, knowledge can be generated based on information. In fact, the main

means by which reliable knowledge is produced is the systematic analysis of information about the

past. This analysis typically leads to the observation of patterns that are combined into predictive and

associative rules (i.e., knowledge).

The following case involves Hopper Specialty, a retail vendor of industrial hardware in

Farmington, New Mexico, and NCR, a large developer of computer hardware and software, headquartered in Dayton, Ohio, (Geyelin, 1994). In 1987, Hopper Specialty decided to purchase a

computerized inventory-management system from NCR. The system in question was called, “Warehouse Manager,” and it was installed in 1988. Several problems surfaced immediately after the

system had been installed.

According to Hopper Specialty’s representatives, the system never worked as it was supposed to.

It displayed an assortment of problems such as extremely low response times, constant locking up

of terminals, and corrupted data files. In 1993, more than 5 years after the system was installed,

Hopper Specialty cancelled the contract with NCR and sued the company. They claimed that they

had suffered a loss of $4.2 million in profits due to problems caused by the installation and use of

Warehouse Manager. NCR’s lawyers immediately asked that the lawsuit be dismissed on the grounds

that it was filed too late. (New Mexico’s statute of limitations for this type of lawsuit is only 4

years.)

Ethical considerations aside, NCR’s lawyers had access to information and knowledge that

allowed them to safely move for a case dismissal. The information to which we refer here regards

New Mexico’s statute of limitations and can be expressed by the assertion: “In New Mexico, a law

suit, such as the one filed by Hopper Specialty, should be filed within at least 4 years after the

alleged breach of contract occurs.” The knowledge possessed by NCR’s lawyers allowed them to

build a link between information about the law, in this case the statute of limitations, and the likely

consequence (information about the future) of grounding their defense on New Mexico’s statute of

limitations. This knowledge can be summarily expressed by the rule: “If we move for a case dismissal based on New Mexico’s statute of limitations, then it is likely that the case will be quickly

dismissed by the judge presiding the case.”

Figure 4 depicts the relationship between data, information, and knowledge based on the case

discussed above. The following printed or electronic documents store information that could be used

by NCR’s lawyers to defend their company in the lawsuit filed by Hopper:

• The lawsuit notification;

• The contract between NCR and Hopper;

• Warehouse Manager’s documentation;

• A legal database of previous cases;

• Law books; and

• New Mexico’s constitution.
24

In Figure 4, items are physical or electronic records (i.e., data first read by NCR’s lawyers). Once

these records were read, the lawyers could extract some pieces of relevant information about the

present situation. Examples of such pieces of relevant information are the terms of the contract between NCR and Hopper and New Mexico’s statute of limitations.

Present information can then be combined with knowledge linking the main goal — generic

statute of limitations — and the likely consequences of not observing the stipulated lawsuit filing

expiration date. This combination of knowledge and information allows for the prediction of the

future with a certain degree of certainty, that is, the generation of “future information” or information

about the future. In the case of NCR versus Hopper, this future information was the prediction that the

presiding judge would dismiss the case based on New Mexico’s statute of limitations. NCR’s lawyers, therefore, took the appropriate action of moving for a case dismissal.

–Lawsuit notification

–Contract between NCR & Hopper

–System documentation

–Legal database

–Law books

–New Mexico's constitution

Future information (lawyers' brains)

This case will probably be dismissed

based on New Mexico's statute of

limitations

Reading

Knowledge (lawyers' brains)

If

a lawsuit is filled after the period

stipulated by the statute of limitations

then

there is a good chance that a judge will

dismiss the case upon request.

Action taking:

Move for

case dismissal

Reasoning

Present information (lawyers' brains) 

–Lawsuit basis

–Contract terms

–New Mexico's statute of limitations

Data (printed docs, electronic databases)

Figure 4. The Relationship Between Data, Information, and Knowledge.
25

Supply-chain Processes Knowledge-intensive Processes

Order taking Training

Acquisition Technology Transfer

Production Process Improvement

Delivery Strategic Planning

Distribution New Product Design

Table 1. Examples of Supply-Chain and Knowledge-Intensive Processes.

Figure 5. Types of Processes According to the Amount of Knowledge Transfer at Execution Time.

LOW HIGH

Supply-chain Processes Knowledge-intensive Processes

Amount of Required Knowledge Transfer at Execution Time

CHAPTER 3

THE INFODESIGN METHODOLOGY

Underlying Principles

InfoDesign’s underlying principles are tailored to the redesign of supply-chain processes. The

term “supply chain” is based on a simple categorization of processes according to the amount of

knowledge transfer required during their execution. Processes can be categorized as supply-chain

and knowledge-intensive processes. If we built a scale measuring the amount of knowledge transferred at execution time, these two types of processes are at different extremes. Supply-chain processes would be at the lower end of the scale. Knowledge-intensive processes would be at the high

end (see Figure 5).

Examples of supply-chain and knowledge-intensive processes are provided in Table 1. In addition to the amount of knowledge transfer, supply-chain and knowledge-intensive processes can be

differentiated based on their frequency and degree of standardization. Supply-chain processes are

usually executed more frequently than knowledge-intensive processes. For example, an “order taking” process is usually executed several times a day (at least once for each product or service sold),

while a “training” process takes place every once in a while (e.g., every quarter). Supply-chain processes are also usually more standardized than knowledge-intensive processes. For example, it is

likely that there will be better defined procedures to execute a “production” process than to execute

“technology transfer” processes. This is primarily due to the fact that knowledge-intensive processes

are more “messy” and irregular than supply-chain processes.

Supply-chain and knowledge-intensive processes are closely related in that the latter are completed typically to ensure that the former are executed well and that they generate expected outcomes.

For example, a “training” process may be executed to ensure that the “acquisition” process is executed according to regulations and in an optimal way.
26

A methodology for process redesign is necessarily made up of guidelines that are followed by

those who employ it. Since those guidelines should be defined for each step of the methodology,

there are usually many of them, several of which may appear disconnected and coming out of nowhere. Given this, it is usually advisable to define key principles that are used as a basis for the

creation of guidelines. The InfoDesign methodology is based on the seven key principles outlined

below: (For simplicity, data, information, and knowledge are referred to by the letters “D,” “I,” and

“K,” respectively, in this discussion.)

The “Minimum Data Proportion” Principle

• Maximization of the I/D and K/D ratios in data exchanges of supply-chain processes leads to

lower communication losses and, thus, higher process productivity.

For example, if a data exchange using a 20-field form (with approximately 400 kilobytes of data)

could transfer the same amount of information and knowledge using a 5-field form (with approximately 100 kilobytes of data), then the 5-field form would lead to lower communication losses and

higher process productivity. In this case, higher communication losses would not be due to telecommunication costs but to extra cognitive effort and likely mistakes caused by the need to filter relevant

information and knowledge from meaningless data (Kock, 1999).

The “Maximum Information Proportion” Principle

• Maximization of the I/K ratio in data exchanges of supply-chain processes leads to lower

communication losses and, thus, higher process productivity.

For example, if an employee who is responsible for a component activity of a supply-chain process needs to “learn” how to conduct that activity while executing it, more time would be spent

communicating about the activity than if only discrete pieces of information were being exchanged

(Kock and McQueen, 1998; Kock et al., 1997a).

The “Maximum Shared Knowledge” Principle

• Maximization of shared K among supply-chain process agents leads to lower communication

losses and, thus, higher process productivity.

For example, if each member of a six-employee team, which is responsible for the execution of a

supply-chain process, knows a great deal about what the others do, then their communication will

become more efficient, and the productivity of the process, as a whole, will be increased (Kock,

1999a).

The “Minimum Data Transfer Points” Principle

• Minimization of the number of required data exchanges in supply-chain processes leads to

lower communication losses and, thus, higher process productivity.
27

For example, if the number of data exchanges (happening by means of forms, memos, E-mails,

etc.) in a supply-chain process could be reduced from 20 to 5 with no effect on the information and

knowledge requirements of the process, then communication losses would be reduced and productivity increased.

The “Minimum Data Transfer Costs” Principle

• Minimization of the cost of data exchanges leads to lower overall supply-chain process costs

and higher process productivity.

For example, if 10 data exchanges of approximately 1 megabyte each cost $100 because of the

use of an expensive medium (e.g., a private mobile-phone network), then the adoption of a cheaper

medium (e.g., the Internet) will reduce their costs. This will, in turn, lead to lower overall process

costs and increased process productivity.

The “Quality versus Productivity” Principle

• If quality is compromised to gain productivity, productivity gains will not materialize in

supply-chain processes.

For example, if an increase in productivity in a supply-chain process leads to a less desirable

product, the demand for that product would go down. Thus the productivity increase would not

contribute to bottom-line financial gains (Deming, 1986).

The “Continuous Improvement” Principle

• Organizational changes that take place outside the scope of supply-chain processes require the

supply chain to be continually redesigned.

For example, even if the application of all the previous principles leads to an optimized supplychain process today, it is likely that the process will not be optimal 6 months to 1 year from now.

Therefore, measurement and review activities must be incorporated into supply-chain processes to

force continuous and incremental revisions of the processes to cope with changes in the organizational environment surrounding the processes (Davenport, 1993; Deming, 1986; Hammer and Champy,

1993).

The principles discussed above provide a consistent and comprehensive framework upon which

more specific guidelines for process redesign are based. Those guidelines are applied in the context of

activities that make up the InfoDesign meta-process, which is discussed below.

InfoDesign at a Glance

InfoDesign is a methodology to guide the work of groups redesigning acquisition processes. One

of its components is a group process (or meta-process). As a methodology, InfoDesign can be fully
28

defined as a set of activities, guidelines, and representation tools to be used by process redesign

groups. It is suggested that group size should be between 3 to 25 participants who play the roles of

group leader, facilitator, and ordinary members. The goal of the group is to identify an acquisition

process where improvement opportunities exist and to propose changes that will translate those opportunities into practical improvement.

InfoDesign is made up of three main stages: process definition, analysis, and redesign. Each stage

comprises interrelated activities. In order to define the guidelines and representation tools to be used

in InfoDesign, it is important to identify the activities in each of the stages as well as the group roles

involved. Group roles in InfoDesign are analogous to process functions in organizations. The activities involved in each of the stages are summarized below:

• Process Definition (Definition Stage):

— Identify problems

— Identify processes

— Select a process for redesign

• Process Analysis (Analysis Stage):

— Model the process

— Summarize performance information

— Highlight opportunities for improvement

• Process Redesign (Redesign Stage):

— Search for suitable changes

— Incorporate changes into the process

The illustration in Figure 6, which follows, is a simplification of the real meta-process. The goal

of this illustration is to provide a clear, yet limited, view of InfoDesign as a whole. Loops and interactions with members outside the group are not represented, though these are likely to occur in real

process redesign groups. For instance, while performing the activity “evaluate redesign feasibility,” a

group may decide that it must go back to the activity “search for suitable changes” due to the impossibility of implementing some of the proposed changes. Also, the facilitator of a group targeting a

specific acquisition process in the IT Department of an organization may need information from the

Finance Department during the stage “raise performance information.”

Two permanent groups should be set up by an organization implementing InfoDesign in order to

guarantee the success of process improvement groups — the Process Improvement Committee and

the Process Improvement Support Team.

The Process Improvement Committee analyses process redesign proposals and, when necessary,

coordinates and supports their implementation and standardization throughout the organization. The

Process Improvement Committee members should have enough authority to coordinate the imple-
29

Figure 6. InfoDesign as a Set of Interrelated Activities.

Definition

Stage

Analysis

Stage

Redesign

Stage

List of

Problems

List of

Processes

Selected

Process

Process

Model

Performance

Information

--Process Model

--Performance Information

--Improvement Opportunities 

Redesigned

Process

Possible

Changes

. . . . 

. . . . 

. . . . 

. . . . . . . . . . . . . . . 

Incorporate Changes

Into the Process

(Facilitator)

Evaluate Redesign

Feasibility

(Whole Group)

Search for

Suitable Changes

(Whole Group)

Summarize

Performance Information

(Facilitator)

Highlight Opportunities

of Improvement

(Facilitator)

Model the

Business Process

(Facilitator)

Identify

Business Processes

(Whole Group)

Select a Business

Process for Redesign

(Whole Group)

Identify Problems

(Leader)

. . . . 

. . . . 

. . . . 

. . . . . . . . . . . . . . . 

. . . . 

. . . . 

. . . . 

. . . . . . . . . . . . . . . 

mentation of strategic changes, such as those requiring large investments and organization-wide restructuring.

The Process Improvement Support Team’s main function is to provide process improvement

groups with necessary methodological and technological support. It is also responsible for documenting, organizing, and providing public access to the information about process improvement initiatives

in the organization (e.g., documents generated by previous process redesign groups).

The InfoDesign Group

InfoDesign comprises three group roles: leader, facilitator, and member. A process redesign

group is initiated by a self-appointed leader, who should initially identify a set of problems related

to an acquisition process to be tackled by the group. The group leader then invites other members

to be part of the group and appoints one of these members as the group facilitator. The group leader

should advise the Process Improvement Support Team that the group has been created, so the

Process Improvement Support Team can support and document the group’s evolution.
30

The InfoDesign Group Leader

The leader coordinates the activities of the group and interacts with the Process Improvement

Support Team. The responsibilities of a group leader include:

• Scheduling meetings and making sure the necessary resources are available. Such resources

may include, for instance, a room with an overhead projector or an electronic conferencing

system (in the event the group will meet primarily electronically);

• Contacting group members and making sure they are able to attend the group meetings,

either face-to-face or electronically; and

• Gathering and organizing the documentation generated by the group and, after the process

redesign group has completed its work, supplying the Process Improvement Support Team

with this documentation.

The InfoDesign Group Facilitator

The InfoDesign group facilitator plays two roles at the same time — a support role as well as a

moderator role. This person is responsible for:

• Creating and maintaining a model of the process targeted for redesign, and

• Summarizing performance information about the process and highlighting opportunities for

improvement.

To meet these responsibilities, the facilitator must have a thorough understanding of InfoDesign’s

guidelines and representation tools. The facilitator does not make decisions alone on the adoption of

specific changes; this is a prerogative of the InfoDesign group as a whole and must be achieved by

consensus.

The InfoDesign Group Member

The other members of the group (i.e., the “ordinary” members) will provide their inputs throughout the group discussion in a “low-cost” participation manner. As in most types of moderated group

discussions, the majority of the burdens of coordinating communication, compiling member contributions, and documenting group decisions are on the leader and the facilitator. One person can play

more than one role in the group. For example, one person can be the group leader, the facilitator, and

provide inputs as a group member.

General Guidelines for InfoDesign

Guidelines are “how-to” rules that can refer to the InfoDesign meta-process, as a whole, or its

component activities. Guidelines follow that relate to the InfoDesign meta-process as a whole; they

are not specific to a particular activity.
31

• The process improvement group should develop a redesign proposal in a limited amount of

time, ideally in no more than 8 weeks. Previous research shows that an acceptable “average”

time is 3 weeks (Kock and McQueen, 1995).

• The stages a process redesign group goes through should be documented. The leader is primarily responsible for this documentation, which is essential to building historical documentation

about organizational process redesign initiatives. This information can be used for many purposes, such as a basis for future process redesign groups and as evidence of the organization’s

commitment to improving process quality in quality accreditation audits. For example, the

organization may use process improvement group documentation in ISO-9000 certification

audits to show that exemplary procedures for dealing with “nonconformities” were followed

(Kock and McQueen, 1997).

• Each of the group meetings should conclude with a link to the next meeting. A meeting where

the activities “identify problems” and “identify processes” are accomplished should end with

a preliminary selection of a process to be redesigned. This preliminary selection works as a

link to the next meeting, where the first activity will be “select a process for redesign.” These

“links” between meetings are aimed at improving group focus.

• The facilitator should not try to enforce the group process (i.e., InfoDesign) described in this

document. Instead, this person should induce it in a “transparent” way. In most cases, this will

occur almost naturally as the facilitator is responsible for several of the key activities of the

process redesign group.

InfoDesign in Detail: Activities, Guidelines, and Representation Tools

The following subsections provide a discussion of each of the activities in InfoDesign, including

guidelines and representation tools used. (Subsection titles are formed by the main stage, which is

followed by a colon and the name of the activity.)

Definition Stage: Identify Problems

In the definition stage, the first group activity is to identify problems. As discussed before, the

person who first brings the problems up for discussion is a self-appointed group leader. Virtually

anyone can be a group leader, which helps spread the responsibility for the innovation over the

organization and reduces the innovation’s reliance on managers. This broadens the process

improvement’s scope of application as the number of managers in one organization is usually smaller

than that of line employees.

In some forms of process improvement where the improvement is gradual and accomplished by

permanent groups (e.g., quality circles), the search for improvement does not necessarily rely on the

previous identification of problems. In these cases the improvement is routinely sought based on the

assumption that every process can always be improved in one way or another. However, research

shows that the identification of problems as sources of discontent within the organization is a success

factor in process improvement (Hall et al., 1993).
32

The identification of problems fosters interest in process improvement among organization

members and, at the same time, gives them an idea of what is to be achieved with the improvement. The identification of problems, though, is only the beginning of InfoDesign. The main

outcome of InfoDesign is process improvement, not problem solving. The identification of problems is an intermediate step that leads to the selection of a process for improvement (Harrington,

1991).

Guidelines

• Generate a list of interrelated problems, and submit it to the process improvement group so

mistakes and omissions can be corrected. The group leader should prepare the preliminary

version of the list. This is the first step in the formation of the group.

• Concurrently with the generation of the list mentioned above, the leader should invite prospective group members. Listing problems and inviting group members are two interrelated

tasks. Expect little involvement from group members who have no interest in the problems

initially listed.

• Problems in the list should be at least intuitively related. A list of problems that is excessively

broad and involves several different areas of an organization, for example, leads to the identification of several processes for redesign. This is likely to disperse the focus of the process

improvement group.

• Problems should be approached in a very clear and open way. There should be no fear of

disclosing discontent with the actual situation. Poor identification of problems (e.g., certain

problems are not discussed because they may upset some individuals) leads to poor process

redesign (Deming, 1986; Kock and Tomelin, 1996).

Definition Stage: Identify Processes

Once a list of interrelated problems is identified, the next step is to identify the processes associated with those problems. At this point it may be found that some processes are clearly defined, while

others are not (Wastell et al., 1994). For instance, it may be found that several problems are associated

with the activity “inform bidders about the outcomes of the review of bids,” which was not previously

seen as part of a set of interrelated activities.

Guidelines

• A process improvement group should not try to build process models in this activity. Instead, the interrelated activities that are perceived by the group as the causes of problems

should be listed using one or a few words. For example, the acquisition-related problems

listed may be “late invoices,” “customer complaints about invoice complexity,” “inaccurate

invoices,” and “late payment.” As these are all related to the process of issuing invoices, the
33

processes can be simply described in this activity as “invoicing.” Later, in the second stage

of InfoDesign — the process analysis stage — the selected process or processes will be

analyzed in more detail.

• A process improvement group should not expect to identify one process for each problem

or vice-versa. The relationship between problems and processes may be a “many-to-many”

one. That is, several processes can cause one problem; and, conversely, several problems

can be caused by one process. Thus, even though the initial list of problems may have

only “one” problem, it may help in the identification of several processes for improvement.

Definition Stage: Select a Process for Redesign

This activity is a conclusion of the work started in the previous activity, “identify processes.”

Here, one of the processes identified in that activity will be chosen for redesign.

When several processes are identified, group members may want to select more than one process

for improvement. This is frequently the case when there are no clear boundaries between processes

within the organization. However, as the number of selected processes increases, so does the complexity in the next stage, “process analysis.” An additional drawback of the selection of many processes for redesign is the high number of changes likely to be proposed by the group. A high number

of processes selected for redesign may hinder the process improvement group from focusing on one

specific process that needs urgent attention. It may also reduce the level of care given to the analysis

and redesign of each individual process.

Guidelines

• The process improvement group should strive to select as few processes as possible. Ideally,

only one process should be selected.

• The process that is associated with the most critical problems should be given priority in the

selection.

• After applying the preceding guidelines, the process that is associated with the highest number

of problems should be given priority in the selection.

Analysis Stage: Model the Process

In this activity the process considered for improvement by the process improvement group is

modeled using two process representation tools. The goal of this activity is to understand the relationships between process activities and to obtain a clear view of the process as a whole.
34

Representation Tool:Activity Table

The activity table provides a first step in the process modeling activity and sets the stage for the

development of the InfoDesign diagram, which is discussed in the next section. An example of an

activity table, based on a software development acquisition process, is provided in Figure 7. A

typical activity table has five columns. The first column, on the left, shows the number of each

activity. The other four columns are titled, “What,” “When,” “Who,” and “How.” In the “What”

column, each activity is briefly described by a transitive verb in the infinitive form followed by its

object. The “When” column indicates when the activity is conducted — this is usually done by

specifying what activity or activities immediately precede the current activity. The “Who” column

indicates who performs the activity — usually by means of an organizational function (e.g., technical lead) or a group within the organization (e.g., contracts department). The “How” column is a

memo-type column where a description of how the activity is conducted is provided — usually

specific tools or artifacts used in the activity are indicated in this column (e.g., automated proposal

preparation system).

# What When Who How

1 Receive Request for Beginning of Contracts Manager Using Secure Workflow process from

Proposal (RFP) process customers’ Contracts Officer

2 Announce RFP After 1 Contracts Manager Using E-mail and highlighting suspense

date (due date) requested by customer

3 Prepare proposal After 2 Technical Lead, Contracts Using automated proposal preparation

Manager, Finance and system

Accounting

4 Prepare Basis of After 2 Technical Lead Using historical data and BOE template

Estimate (BOE) (MS Word)

...... ... ... ...

Figure 7. Example of Activity Table.

Developing an activity table is a preliminary step that may or may not be taken by an InfoDesign

group. The goal is to give the group a basic idea of what the process looks like using a simple textbased, work-flow representation. The next step is the development of an InfoDesign diagram to show

how information and knowledge flow and are stored in the process. Assuming that information and

knowledge flow and they are stored by means of data items, data flows are not represented explicitly

in InfoDesign diagrams.
35

Representation Tool: InfoDesign Diagram

An InfoDesign diagram is made up of a combination of the four symbols shown in Figure 8. The

“process agent” symbol represents an organizational function that plays a role in an acquisition process. The “process activity” symbol represents an activity that makes up an acquisition process. The

“IK flow” symbol represents the flow of information and/or knowledge in an acquisition process.

Finally, the “IK store” symbol represents an information and/or knowledge “store” of an acquisition

process. A “store” can be any repository that stores information and knowledge through data in a

temporary or permanent way.

Process Agent Process Activity

IK Flow IK Store

Figure 8. InfoDesign Diagram Symbols.

 (IK = Information and Knowledge)

A process agent usually carries out one or more activities in an acquisition process. Some activities may be carried out without human intervention (i.e., automatically) and still be represented in an

InfoDesign diagram using “process activity” symbols. Activities can be “exploded” into other activities in “lower-level” InfoDesign diagrams. That is, an acquisition process can be represented by

several InfoDesign diagrams, each modeling the acquisition process at different levels of detail. The

highest-level InfoDesign diagram is the level 1 InfoDesign diagram. In a level 1 InfoDesign diagram,

activities are numbered from 1 to N, N being the number of activities represented in an InfoDesign

diagram. These numbers should indicate the sequence of execution of activities in an acquisition

process in an approximate way.

If an acquisition process activity seems too complex to be understood without further decomposition, then it can be “exploded” into a separate InfoDesign diagram. Let’s assume that activity 2 of

an acquisition process is very complex. This activity can be “exploded” into a level 2 InfoDesign

diagram, where the component activities will be numbered 2.1, 2.2, 2.3, and so on. If one of the

activities of this level 2 InfoDesign diagram (say activity 2.3) is too complex and needs to be

“exploded,” a level 3 InfoDesign diagram can be created. The component activities of level 3 will be

numbered 2.3.1, 2.3.2, 2.3.3, etc.

The InfoDesign diagram incorporates all the elements of the activity table, as well as other elements that indicate how information and knowledge are stored and how they flow in an acquisition
36

process. An example of InfoDesign diagram, based on a software development acquisition process, is

provided in Figure 9. Only part of the process is shown in Figure 9; the emphasis is on the communication of a Request for Proposals (RFPs) from a Department of Defense (DoD) branch to a software

development contractor2 and the internal activities at the contractor that immediately follow this communication.

2

The diagram is based on a Computer Sciences Corporation (CSC) process redesign project; one of the authors was

involved in this project.

Guidelines

• The description within a “process activity” symbol should be as brief as possible and begin

with a verb in the infinitive form (e.g., download RFP, announce RFP, prepare draft proposal,

conduct Alpha Negotiations, drill a computer card, load a batch of parts onto a truck, etc.).

I: RFPA

I: RFPA

I: RFPA

I: RFPA

Project Manager

Accounting

IK: Draft Proposal

IK: Explanation of

 Technical Constraints

I: RFP

IK: Explanation of

Project Needs

Prepare Draft

Proposal (Contracts

Manager)

3

IK: Draft Proposal

Technical Lead

I: RFPA

I: DoD’s RFPs

Download RFP

(Contracts Manager:

Secure Work flow)

1

Announce RFP

(Contracts Manager:

Secure Work Flow)

2

Conduct Alpha

Negotiations (Technical

Lead, DoD Branch)

4

I: RFPs

I: RFP

I: RFP

I: RFP

I: RFPA

I: RFPA

DoD Branch

Notes:

• Alpha Negotiations: Initial negotiations between DoD Branch and

Technical Lead to define the budget for the project

• DoD: U.S. Department of Defense

• RFP: Request for Proposal

• RFPA: RFP Announcement

• Secure Workforce: DoD Branch application that allows selective

access to RFPs

Figure 9. Example of InfoDesign Diagram.

 (IK = Information and Knowledge)
37

• An InfoDesign diagram should have a limited number of symbols so it is not too complex

for someone who did not participate in its development. Studies on human cognition limitations provide the basis for establishing an optimum number of symbols in process modeling

diagrams (Miller, 1956). These studies suggest that this number should be between 5 and 9

symbols (i.e., 7 plus or minus 2). When a process cannot be represented with less than 14

symbols (i.e., twice the optimum average) due to its complexity, some of the activities should

be “exploded” into lower-level InfoDesign diagrams (Pressman, 1987).

• Trivial artifacts should not be described in “process activities” (e.g., pen and paper, telephone,

etc.). A rule of thumb is to describe only artifacts that are specific to an activity (or type of

activity) and without which the activity could not be carried out (e.g., Secure Work Flow (a

computer system shown in Figure 9), lathe, computerized drill, cheese processor, inventory

control system, etc.). An artifact is specific to an activity or type of activity whenever it has

been designed to support only that activity or type of activity.

• When modeling a process, the facilitator should not be afraid of adding handwritten notes and

marks to the diagram if they are needed to clarify certain points. The emphasis should be on

using the graphical tool in an effective way to convey information and knowledge that will

allow the group to redesign the process rather than in a “rule-abiding” way. Keep the chart as

neat and tidy as possible by strictly sticking with the charting symbolism.

Analysis Stage: Summarize Performance Information

In this activity, information about the performance of the process is summarized for the

InfoDesign group. This information should gravitate around two main process attributes — quality

and productivity. A direct measure of process quality is customer satisfaction, so the best way to

evaluate it is to obtain information on how the customers of the process perceive its outputs. The

customers of an acquisition process are those inside and outside the organization who receive

outputs generated by activities of the process. Such outputs may include budgets, proposals, specifications, project plans, etc. For example, a well-prepared, high-quality budget is a budget that not

only meets the requirements of the project at the lowest possible cost for the buyer but also does not

fall below the specified requirements. Similarly, a budget that is lower than is necessary to meet all

the requirements of the project under bid is likely to lead to the delivery of low-quality outputs or to

the delivery of no outputs at all.

Productivity is traditionally measured by the ratio outputs/inputs (Misterek et al., 1992). This

means that an acquisition process that employs 10 people and completes 2 acquisition “units”

(i.e., an arbitrary metric used to count acquisitions) per month may be said to have a productivity

of 2/10 = 0.2 acquisition units per month per employee. If the same process is redesigned so it

can complete the same 2 acquisition units per month but, now, with 5 employees, then its productivity will be 2/5 = 0.4 acquisition units per month per employee. That is 100 percent higher

than before.
38

A better way to measure process productivity is by considering the ratio (production capacity)/

(production costs). This offers two advantages against the (input/output) approach discussed above:

• It considers the costs of the inputs to the process and not their quantity; and

• It takes into consideration the capacity of a process and not its realization.

Even when its cost is reduced, the quantity of each input may remain the same due to process

improvement. For example, an acquisition process may benefit from a smarter use of less expensive

information technologies, whether the number of acquisition units is reduced or not. This is why the

analysis of cost is critical to productivity measurement as opposed to the approach of counting the

number of inputs. Yet, this approach implies a higher measurement complexity as costs can vary

considerably with time.

The measurement of the production capacity for a process implies forecasting. To say that an

acquisition process has a production capacity of 300 acquisition units a year means that the acquisition process can produce that figure on average but not that it is the real average output. Since production in real contexts depends on consumption expectancy, which in turn is based on the buyer’s

budget and needs, the simple measure of outputs can lead to wrong assumptions about productivity.

This risk is suppressed when productivity assessment is based on production capacity (Goldratt and

Fox, 1986). Complexity here is, again, increased by the need to estimate process output capacity

based on historical figures and resource capacity of specific units. However, in many cases this may

be easier than relying on real numbers with measurements that are severely hampered by the added

cost of extensions in the accounting system of the organization (Mark, 1984).

So, the analysis of productivity should be based on estimates of production capacity and costs

rather than on outputs and inputs. While likely to add complexity to measurement, this is useful

because it draws a line between productivity and quality assessment. The output/input approach

disregards the fact that quality improvement is bound to generate more consumption and, consequently, promote an increase in output (Deming, 1986). By connecting productivity with the actual

outputs produced by a process, one could mistake quality for productivity improvement. This is

particularly true when a surge in demand, due to higher quality, is simply supported by excess capacity, not augmented productivity.

Guidelines

• In the first activity of InfoDesign — the one aimed at identifying problems — the group

should have gathered information on process customer complaints. In this activity, the facilitator should try to find quantitative data associated with those complaints and should try, for

example, to identify, by means of quantitative measures, the problems customers see as the

most critical and as occurring the most often.

• In this activity, the facilitator should not be concerned with generating performance information. The facilitator should, instead, focus on summarizing existing information about the process performance. This information may come from areas of the organization that are not
39

represented in the process improvement group. Generating performance information may take

too long and, therefore, make the process improvement group lose momentum. A lack of

process performance information, identified by a group in its analysis stage, may become a

problem to be tackled by a different process improvement group.

Analysis Stage: Highlight Improvement Opportunities

Based on performance information raised in the previous activity, the facilitator highlights opportunities for improvement in this activity. This is helpful in leading the InfoDesign group towards the

discussion of concrete changes to improve the process.

Guideline

The facilitator should highlight process improvement opportunities by proposing changes in the

process to be discussed by the group. These changes should be based on the information gathered

during the two previous activities, namely, “model the process” and “raise performance evaluation.”

They should also follow the guidelines “search for suitable changes” discussed in the next activity.

Redesign Stage: Search for Suitable Changes

In this activity group members propose suitable changes in the process so improvements of quality and productivity can be achieved. The literature on process improvement provides several guidelines for making improvements. These guidelines can help process improvement group members

formulate their redesign proposals.

Guidelines

Harrington (1991) provides several guidelines for process improvement based on general principles such as process and activity simplification, bureaucracy elimination, standardization, and technology utilization. Hall et al. (1993) and Venkatraman (1994) propose guidelines for redesigning

processes according to improvement dimensions and scope levels. Guha et al. (1993) and Wastell et

al. (1994) present some process improvement guidelines as part of specific process redesign programs. Dingle (1994) and Caron et al. (1994) draw guidelines from the analysis of process reengineering

cases. Kock (1999a) summarizes these guidelines and proposes several of his own, based on the

analysis of face-to-face and computer-mediated process improvement groups. The guidelines below

build on this body of normative work; they are organized around the seven principles discussed

earlier in this chapter.

• Maximize the I/D (information/data) and K/D (knowledge/data) ratios in data exchanges.

This can be achieved by analyzing each data exchange (e.g., form, memo, etc.) and eliminating data components that are not used (i.e., not processed). For example, a project

requirements form of a call for proposals may contain 20 different fields, but only 5 of

those fields are actually used by those who are going to prepare a draft proposal. In this

case, the number of fields on the form should be reduced to 5, which are the fields that are

actually used.
40

• Maximize the I/K (information/knowledge) ratio in routine data exchanges. This can be

achieved by eliminating the knowledge content in routine data exchanges and creating special

processes. These processes are external and ancillary to the acquisition process being considered, and their main goal is knowledge sharing. These special processes will likely limit the

need for the exchange of knowledge content in routine data exchanges, which has been shown

to negatively affect process productivity (Kock and McQueen, 1998).

• Maximize shared K (knowledge) among processes. As discussed above, this can be achieved

by creating special processes whose main goal is knowledge sharing. One type of process that

has been shown to be conducive to knowledge sharing is “process improvement” (Kock,

1999a). Thus, using a methodology, such as InfoDesign, is likely to increase the amount of

knowledge that process agents, who worked as process improvement teams, share about the

process they participated in.

• Minimize the number of required data exchanges. This can be achieved by eliminating

duplication of information and reducing information flow, control, and the number of contact

points in the process.

— Eliminating duplication of information is particularly important in static repositories (e.g., a

database of suppliers) as opposed to dynamic repositories (e.g., a supplier data entry form)

because the former hold information on a more permanent basis. Duplication of information in different static repositories often creates inconsistency problems, which may have a

negative impact on productivity and quality and lead to unnecessary exchanges of data in

acquisition processes.

— Reducing information flow is key to minimizing the number of required data exchanges

since data exchanges take place primarily so information can be transferred, usually between people. Information flow reduction can be achieved by selecting the information that

is important in acquisition processes and eliminating the rest. Information flow can also be

reduced by effectively using group support and database management systems. Thus, information can flow across several hierarchical levels without the need for filtering and

“poligonation” (i.e., information that needs to go from individual A to individual B, first

going to one or more individuals who simply forward the information to the next person).

(See Kock, 1999a.)

— Reducing control is important because control activities lead to unnecessary exchanges of

data. Moreover, while some control activities are crucial to prevent major problems from

happening, others are not; and they add little or no value to customers. The latter are often

designed to prevent problems from happening as a result of human mistakes. In several

cases, however, control itself fosters neglect and can have a negative impact on productivity. Additionally, some types of control, such as those aimed at preventing fraud, may prove

to be more costly than no control at all.

— Finally, reducing the number of contact points in an acquisition process is likely to reduce

the number of required data exchanges because many contact points include data exchanges.

Contact points can be defined as points where there is interaction among two or more

people. Contact points generate delays and inconsistencies and, when in excess, lead to
41

process customer perplexity and dissatisfaction. Additionally, it is much easier to monitor

customer perceptions in situations where there are a small number of contact points. This

makes it easier to improve process quality.

• Minimize the cost of data exchanges. There are a number of different ways this can be

achieved through the smart implementation of information technologies. From a conceptual

perspective, however, one of the key ways this can be achieved is by fostering asynchronous

communication. When people exchange information or knowledge, they can do it synchronously (i.e., interacting at the same time) or asynchronously (i.e., interacting at different times).

One example of synchronous communication is a telephone conversation. If the conversation

takes place via E-mail, it then becomes an example of asynchronous communication. It has

been observed, especially in formal business interaction, that asynchronous communication is

more efficient almost always. On the other hand, synchronous communication often leads to

wasted time (e.g., waiting for the other person to be found), and communication tends to be

less objective. Asynchronous communication can be implemented with simple artifacts such

as in-boxes and out-boxes, fax trays, and billboards. These artifacts work as dynamic information repositories.

• Maximize quality. The “quality versus productivity” principle argues that, if quality is compromised so productivity gains can be achieved, productivity gains will not materialize. The focus

of the process redesign guidelines discussed so far has been on the increase of process productivity by focusing on data, information, and knowledge. This guideline, “maximize quality,” is a

“moderating” guideline in that it moderates the application of the other guidelines. The application of the “maximize quality” guideline should begin with a question during the application of

each of the previous guidelines in a real acquisition process. Ask if the resulting process change

is going to have a negative impact on quality. If it is, then the implementation of the process

change under consideration should be reconsidered and, if necessary, abandoned.

• Incorporate “continuous improvement” activities into the process. The “continuous improvement” principle argues that organizational changes that take place outside processes

require the continuous redesign of processes. The process redesign guidelines discussed here

are aimed at discrete or “one-shot” process improvement. Nevertheless, continuous improvement is also necessary (Kock, 1999a) to both refine the “one-shot” changes resulting from an

InfoDesign project and allow for small and incremental process changes to take place over

time in response to changes that take place outside the process. This can be achieved by

incorporating three types of activities into the new process: (1) process performance measurement activities, (2) process performance review activities, and (3) process revision activities.

The frequency of these activities should be lower than that of the process itself. For example,

if an acquisition process is completed every week, continuous improvement activities could

be completed every quarter.

At this point, it is important to stress that process improvement group members should not be

concerned about the feasibility of their redesign proposals. This concern will only limit the innovativeness

of the redesign and, therefore, its effectiveness. Redesign feasibility analysis will be carried out at a

later point in an activity included especially for this purpose.
42

Redesign Stage: Incorporate Changes into the Process

In this activity, the facilitator should incorporate the changes proposed by the group into the

process models and respective written descriptions. The models of the new process provide feedback

to the group so proposed changes can be discussed and refined before they are put into practice.

Guideline

At this point, the facilitator should try to state who would be responsible for implementing the

proposed changes in the process. If such changes need involvement from higher management levels,

this should be clearly stated. Such involvement may be needed, for example, for investment approvals

and certain changes in the organizational structure.

Redesign Stage: Evaluate Redesign Feasibility

This is the last conceptual activity of InfoDesign, and the final product is a new process to be

implemented with the support of information technologies. In this activity the group members should

discuss the feasibility of the changes proposed to the process so far and, if necessary, modify them to

adapt those changes to the reality of the organization.

Subsequent Stages: Implement and Refine Redesign

The next stages are the initial implementation of the changes and their refinement so they can be

used in a routine way. The group can proceed on its own to these stages, provided that no involvement from higher management levels is necessary to implement the changes. For example, if the

group has enough authority to approve and support the changes proposed and the resources to carry

this implementation out, the group can proceed to process change implementation right away. If the

proceeding is not the case, the group should submit the change proposal to those who are in a position

to have it implemented. Ideally, this should be done through the Process Improvement Committee,

which is the committee responsible for the evaluation of redesign proposals and coordination of their

implementation.
43

CHAPTER 4

 THE NEED FOR A SHIFT IN REDESIGN FOCUS

A Brief Historical Review of Business Process Redesign

As discussed previously, business processes are sets of interrelated activities that are performed to

achieve a business goal. Business process redesign dates back to the early 1900s, when Frederick

Taylor (1911) published The Principles of Scientific Management. The scientific management movement strongly influenced process redesign ideas and approaches throughout the Second Industrial

Revolution (1850-1950). During this period, business process redesign was primarily concerned

with productivity (i.e., efficiency) improvement in manufacturing plants.

The work of Elton Mayo in the 1930s and others, such as McGregor, Maslow, and Herzberg,

represented the emergence of the “humanist” school of management, which tried to shift the focus of

organizational development from “business processes” to “people.” While these management thinkers succeeded in doing so during the mid 1900s, business process redesign was far from “dead.” The

work of the “humanists” set the stage for the emergence of what many saw as a more “humane”

business process-redesign school of thought. This new school of thought, generally known as total

quality management, not only succeeded scientific management as a business process-based method

but also represented a shift in focus from productivity to quality in the improvement of business

processes. Total quality management began in Japan after the World War II. It was largely due to the

work of William Deming and Joseph Juran and is widely credited as having propelled Japan to

economic superpower status (Bergner, 1991; Chapman, 1991; Deming, 1986; Juran, 1989; Walton,

1989). In the 1980s it became widely practiced in the U.S. and other Western capitalistic countries.

As with scientific management, its primary focus is the improvement of manufacturing operations.

In the early 1990s, business process reengineering replaced total quality management as the predominant school of thought regarding business process redesign. Michael Hammer and Thomas

Davenport independently developed business process reengineering as, respectively, a better alternative (Hammer’s version) and a complement (Davenport’s version) to total quality management. Total

quality management’s primary goal is quality improvement, not productivity. With this in mind, they

based their work on the premise that incremental gains in productivity obtained by implementing total

quality management were insufficient for organizations coping with an accelerated rate of change

fostered by information technologies (Davenport, 1993; 1993a; Davenport and Short, 1990; Hammer, 1990; Hammer and Champy, 1993). Differently from scientific management and total quality

management, business process reengineering was presented as a method for the improvement of

services as well as manufacturing operations.

Current Business Process Redesign Practices: A Rehash of Old Methods?

An analysis of the business process redesign practices throughout the 100-year period, from the

development of scientific management to the emergence of business process reengineering, suggests

an interesting, perhaps cyclic, pattern. Even though processes have changed significantly since
44

Frederick Taylor’s times, the business process redesign practices employed then seem very similar to

those of the 1990s (Kock, 1999a; Kock and McQueen, 1996; Waring, 1991).

The scientific management method consisted of breaking down a business process into component activities, for which a pictorial as well as a quantitative model was generated. The pictorial

model depicted the execution flow of the activities and the associated motions, whereas the quantitative model included information about physical distances associated with motions and the times needed

to perform each of the activities. Taylor showed that managers could empirically devise optimal (or

quasi-optimal) business process configurations that could, then, be standardized through financial

incentives to workers (Taylor, 1885; 1911).

The total quality management movement broke away from the productivity-only orientation of

scientific management by emphasizing business process quality as the main goal of organizational

development. One difficulty faced by the quality movement stems from the fact that “quality” is

primarily a gauge of customer satisfaction and, thus, difficult to be measured. This may explain the

gradual but steady emphasis on quality “process” standardization, which is also known as quality

“systems” standardization. Total quality management gradually became a movement dominated by

quality process (or system) standards, such as the influential ISO-9000 set of quality standards (Arnold,

1994). As such, the view that “quality companies” were those that complied with quality process

standards became increasingly widespread. Many view this as having pushed total quality management in a wrong direction and into the hands of bureaucrats who specialized in quality standards

implementation and certification.

The dissatisfaction created by the “bureaucratization” of total quality management and its alleged

small and incremental impact on the “bottom-line” of the companies that implemented it (Hammer

and Champy, 1993) set the stage for the emergence of business process reengineering. Many argue

that business process reengineering is a “modernized” version of scientific management (Earl, 1994;

Kock and McQueen, 1996; Rigby, 1993; Waring, 1991). The popularity of reengineering reached its

peak by the mid-1990s and has since slumped due to a number of reported failures. James Champy,

a pioneer of reengineering, argued that 70 percent of all reengineering projects failed to achieve their

goals (Champy, 1995). In spite of this, reengineering created renewed interest in business process

redesign, making it the most widely practiced form of organizational development in the Year 2000.

Business process redesign in the New Millennium is usually conducted in conjunction with the implementation of enterprise systems and e-business applications (Biggs, 2000; Davenport, 2000; Hammer, 2000).

Current Focus on Activity Flows and Associated Problems

Unlike the “heyday” of scientific management, when business process improvement meant “materials-flow” improvement, information is what flows the most in business processes today. As pointed

out by Drucker (1993): “In 1880, about 9 out of 10 workers made and moved things; today, that is

down to one out of five. The other four out of five are knowledge people or service workers.” A study

by Kock and McQueen (1996) shows that, even in manufacturing organizations, approximately 80

percent of what flows in business processes is information, while the other 20 percent is made up of
45

materials. In service organizations, this ratio is usually very close to 100 percent to 0 percent. These

figures seem to confirm the once visionary claims that “we are living in an information society”

(Toffler, 1991) and that organizations have become “information organizations” (Drucker, 1989).

The high proportion of information flow is also consistent with the widespread use of information

technologies in organizations and its increasing importance in the improvement of business processes.

Paradoxically though, most of today’s business process redesign practices focus on the analysis

of business processes as sets of interrelated activities, and little attention is paid to the analysis of the

information flow in business processes. The most widely adopted normative approaches for business

process redesign embody general guidelines that place no special emphasis on the redesign of the

information flow. Thus, the information-intensive nature of business processes is discarded (Kock

and McQueen, 1996). This is also true for the DoD, where the IDEFO approach for business process

redesign (Ang and Gay, 1993) has been chosen as the official approach. The IDEFO approach is

based on activity flow and is by far the most widely used (Dean et al, 1995). One widely used

activity-flow approach proposed by Harrington (1991, p. 108) goes as far as stating that: “As a rule

[information flow diagrams] are of more interest to computer programmers and automated systems

analysts than to managers and employees charting business activities.” (See also Harrington et al.,

1998.) While this opinion is obviously at odds with the notion that information processing is the main

goal of business processes (Galbraith, 1977), it is very much in line with the original claims of

reengineering (Hammer and Champy, 1993) and most of the current business process redesign practice.
46
47

CHAPTER 5

VALIDATING INFODESIGN THROUGH AN ACTION RESEARCH STUDY

Research Hypothesis and Its Negative Form

Given the discussion so far in this report, it is reasonable to expect that business process redesign

approaches that focus on the flow of information will be more effective. Thus, they are preferred by

practitioners over those based on the traditional activity-flow view of processes, simply because they

will provide a better understanding of the business processes targeted and a clearer view of how

process changes should be implemented. This expectation, which is at the source of the development

of the InfoDesign methodology, is formalized in hypothesis H1a below:

H1a: Business process redesign practitioners perceive approaches that focus on information

flow as more effective than approaches that focus on activity flow.

H1b (negative form of H1a that was developed for hypothesis testing purposes):

H1b (negative form of H1a): Business process redesign practitioners perceive approaches

that focus on information flow as either less effective than, or presenting the same effectiveness as, approaches that focus on activity flow.

By providing both positive and negative forms of the hypothesis, Popper’s (1992) “falsifiability

criterion” for hypotheses corroboration could be used in this study, which adds robustness to the

study’s findings. The falsifiability criterion is explained in more detail in the next section.

Hypothesis H1a and its negative form, H1b, were tested through an action research study of a

business process redesign project involving the DoD and Computer Sciences Corporation, a leading

software provider for the defense sector. The project also involved employees from Lockheed Martin,

a regular business partner of the Computer Sciences Corporation.

Research Approach Employed: Action Research

The research approach employed was action research (Checkland, 1991; Rapoport, 1970; Susman

and Evered, 1978; Winter, 1989); it was adapted for the specific context of business and information

technology research (Baskerville, 1997; Lau, 1997; Wood-Harper, 1985). One of the main characteristics of organizational action research is that the researcher, or research team, applies “positive”

intervention to the participating organization while collecting research data (Elden and Chisholm,

1993; Francis, 1991; Peters and Robinson, 1984). In this research project, the researcher (one of the

principal investigators) provided business process improvement training and facilitation to the members of a business process redesign team involving employees from the DoD and Computer Sciences
48

Corporation. The facilitation was solely methodological (i.e., no specific process redesign suggestions were offered), and it was also “methodologically neutral.” This neutrality prevented biased

perceptions of the redesign approaches used.

Action research was employed for two reasons. First, action research places the researcher in the

“middle of the action,” allowing close examination of real-world business situations in their full complexity. Therefore, it is a particularly useful research approach for the study of “new” business topics

and hypotheses, such as those addressed by this research study. The second reason stems from the use

of Popper’s “falsifiability criterion.” This criterion states that a researcher should prove a hypothesis

not only by looking for evidence that supports it but also by looking for evidence suggesting an

exception to the hypothesis (i.e., evidence supporting the negative version of the original hypothesis).

Therefore, based on the “negation” of H1a in the previous section, H1b was formulated. According

to Popper’s epistemology (i.e., Popper’s accepted rules for creation of valid knowledge), the absence

of contradictory evidence becomes a strong corroboration of the original hypothesis (Popper, 1992).

In action research, the researcher is an “insider” as opposed to a “removed observer” and, thus, has

access to a broader body of evidence than in other research approaches (e.g., case research, survey

research, and experimental research). For this reason, action research is particularly effective when

employed in combination with Popper’s “falsifiability criterion.”

The business process redesign project focused on the Computer Sciences Corporation, from whom

the DoD purchased software, and its software development procurement process. The Computer

Sciences Corporation is the 13th largest defense contractor in the U.S. and ranks 2nd in information

technology contracts. The business process redesign team had nine members; six are from Computer

Sciences Corporation and three from Lockheed Martin, a company that was a subcontractor for

Computer Sciences Corporation in many software development projects. (Lockheed Martin also

regularly subcontracted Computer Science Corporation.) DoD members also participated in the project

as information providers but not as members of the business process redesign team.

Process Redesign Work and Information-Flow Focus

An analysis conducted by the business process redesign team of the target process led to the

identification of several problems, including the following:

• The work plan in the software development proposal developed for the DoD often did not

include all the departments that participated in the actual work; thus, internal budgeting difficulties developed.

• The justification of the items in the Basis of Estimates (BOEs) document, which forms the

basis on which the budget is generated, often did not meet the needs of the DoD.

• Participating departments were not informed on time about how much project funding was

allocated to them; and, as a result, they were often forced to transfer initial overhead costs to

other projects.

• Because there were no process metrics in place, the contracts manager at Computer Sciences

Corporation had difficulty managing process quality and productivity.
49

• There were incidents when proposal data was lost; and, as a result, many hours of work were

wasted. Also, disaster recovery procedures were not in place.

The business process redesign team employed activity-flow as well as information-flow modeling tools. The activity-flow modeling tool used was the functional timeline flowchart, as proposed by

Harrington (1991) and Harrington et al. (1998). It incorporated information about the organizational

functions involved in the process (e.g., contracts manager, program manager, technical lead, etc.), the

activities carried out by each organization function, the order of execution of each activity in relation

to other activities, the “process time” for each activity (i.e., the amount of time required to perform

each activity), and the “cycle time” for each activity (i.e., the elapsed time between the end of the

activity and the end of the previous activity). See Appendix B for a sample functional timeline flowchart generated by the business process redesign team.

The information-flow modeling tool used was a modified version of the “data-flow diagram”

used in structured systems analysis and design (Davis, 1983; Dennis and Wixom, 2000), as proposed

and illustrated by us in Chapter 3 of this report. It incorporated information about the organizational

functions involved in the process (e.g., contracts manager, program manager, technical lead, etc.), the

activities carried out by each organizational function, the information flows between organizational

functions, and the information repositories in the business process. See Appendix B for a sample

data-flow diagram generated by the business process redesign team.

Without interference from the facilitator, the redesign team independently proposed nine major business process changes based on the redesign guidelines listed in Appendix C. A content analysis of the

descriptions of the proposed changes indicated the following breakdown according to their foci:

• Eight focused only on the information flow of the target business process and led to changes

in the Request for Proposals (RFP) receipt and announcement, Alpha Negotiations, and receipt and announcement of project awards.

• One focused on both the activity and information flow of the target business process and led to

the inclusion of activities related to the compilation and regular review of process metrics.

The team generated a functional timeline flowchart and a data-flow diagram of the new process, including the proposed changes above. The team then developed a “generic” information

technology “solution” (i.e., a product-independent, computer-based infrastructure and system specification) to implement the new business process. The solution was illustrated through a rich pictorial representation with icons representing computers, databases, and organizational functions. The

redesign team members saw this pictorial representation as an important aid for them to use when

explaining the new process to Computer Science Corporation employees and DoD representatives. The pictorial representation was generated entirely based on the information-flow representation of the new process.

A focus group discussion was conducted with the members of the business process redesign

team immediately after the above tasks had been completed. In this discussion the members unanimously indicated that, based on their experience in the project, a focus on the information flow of
50

a business process was more likely to lead to successful redesign outcomes than would a focus on

the activity flow of the business process. However, there was no consensus on the reason for this.

Some suggested that information-flow representations were easier to generate than activity-flow

representations of business processes. Others disagreed, arguing that, while information-flow representations were more difficult to generate, they made it easier to spot business process improvement opportunities.

All of the process changes proposed by the redesign team were approved and subsequently implemented. The implementation of the process changes was accomplished through modifications in the

computer system used by the DoD for procurement. This computer system is known as the Joint

Computer-aided Acquisition and Logistics Support (JCALS) system, and it was originally developed

by the Computer Sciences Corporation. A process performance review conducted approximately 6

months after the implementation of the changes indicated that the business process redesign outcomes

led to productivity and quality gains.

Discussion and Conclusion

The evidence from the business process redesign project provides support to hypothesis H1a and,

more importantly, fails to support H1b, which is the negative form of H1a. The most relevant pieces

of evidence are briefly discussed below:

H1a states that, “Business process redesign practitioners perceive approaches that focus on information flow as more effective than approaches that focus on activity flow.” Key pieces of evidence in

support of this hypothesis follow:

• The business process redesign team used only the information-flow representation to develop

almost all (eight out of nine, or 88.89 percent) of their change recommendations. The remaining change recommendation was also based on the information-flow representation, although

not exclusively.

• The pictorial representation of the “generic” information technology “solution” was generated

entirely based on the information-flow representation of the new process.

• In the focus group discussion, conducted with the members of the business process redesign

team immediately after completion of the process, they unanimously indicated that a focus on

a business process information flow was more likely to lead to successful redesign outcomes

than a focus on a business process activity flow.

H1b, the negative form of H1a, states that, “Business process redesign practitioners perceive

approaches that focus on information flow as either less effective than or presenting the same effectiveness as approaches that focus on activity flow.” The following items suggest a lack of evidence in

support of this hypothesis:

• The business process redesign team favored the information-flow representation even

though it had generated both activity-flow and information-flow representations of the
51

business process. Because the team was familiar with both representations, it is likely

that, if the team had perceived both types of representation as equivalent in terms of

effectiveness, they would not have favored one over another. If they had perceived the

activity-flow representation as superior, they would likely have favored it over the

information-flow representation.

• Even though the business process redesign team had generated both activity-flow and information-flow representations of the new business process (i.e., the business process resulting

from the change recommendations) the pictorial representation of the “generic” information

technology “solution” was based only on the information-flow representation of the new process. Since the members of the redesign team had both representations available to them, it is

likely that, if they had perceived both types of representations as equivalent in terms of effectiveness, they would not have chosen one. Also, they would not have referred to that type of

representation as more likely to lead to successful results, as they did in the focus group discussion. If they had perceived the activity-flow representation as superior, they would likely

have favored it over the information-flow representation.

• One might argue that the team perceived the pictorial representation as of little importance.

Otherwise, they might have used the activity-flow representation as a basis. Yet, it is clear

from the evidence that the pictorial representation was seen as very important by the redesign

team because it illustrated how information technology would enable the new process. Also,

the team saw the pictorial representation as an important aid for explaining the new process to

Computer Science Corporation employees and DoD representatives.

When considering the items above and the evidence of this study, it seems that business process

redesign practitioners perceive approaches that focus on information flow as more useful and effective than approaches that focus on activity flow.

The evidence also suggests that the perceptions above are warranted. It indicates that business

process redesign approaches focusing on information flow may not only be “perceived” as more

effective but also may “actually” be more effective than the more pervasive approaches based on

activity flows. The key reason for this conclusion is that the business process redesign project studied

was a successful one. If the business process redesign project had been unsuccessful, the fact that

practitioners favored one approach over another would be less meaningful.

This study suggests the need for a change of focus in business process redesign in the defense

sector (and possibly elsewhere). The shift should be from approaches based on activity flow to those

based on information flow, such as InfoDesign. Given the widespread use of approaches based on

activity flow today and their high rate of failure (Champy, 1995; Nissen, 1998), such a change of

focus may have a dramatic impact on future business process redesign practices and bottom-line

business impact.
52
53

BIBLIOGRAPHY

Alster, N. (1997), “Do U.S. Firms Spend Too Much on Information Technology?” Investor’s Business Daily, April 3.

Ang, C.L. and Gay, R.K.L. (1993), “IDEF0 Modeling for Project Risk Assessment,” Computers in

Industry, V.22, No.1, pp. 31-46.

Arnold, K.L. (1994), The Manager’s Guide to ISO 9000, The Free Press, New York, NY.

Bartlett, F.C. (1932), Remembering, Cambridge University Press, Cambridge, MA.

Baskerville, R.L. (1997), “Distinguishing Action Research from Participative Case Studies,” Journal

of Systems and Information Technology, V.1, No.1, pp. 25-45.

Bergner, J.T. (1991), The New Superpowers: Germany, Japan, the US, and the New World Order, St.

Martin’s Press, New York, NY.

Biggs, M. (2000). “Enabling a Successful E-business Strategy Requires a Detailed Business Process

Map,” InfoWorld, V.22, No.10, p. 64.

Boroson, W. (1997), Keys to Investing in Mutual Funds, Barron’s Educational Series, Hauppauge,

NY.

Bramorski, T., Madan, M. and Motwani, J. (1997), “Application of the Theory of Constraints in

Banks,” The Bankers Magazine, V.180, No.1, pp. 53-59.

Budd, J.M. and Raber, D. (1996), “Discourse Analysis: Method and Application in the Study of

Information,” Information Processing & Management, V.32, No.2.

Callatay, A.M. (1986), Natural and Artificial Intelligence, North-Holland, Amsterdam, The Netherlands.

Camerer, C.F. and Johnson, E.J. (1991), “The Process-Performance Paradox in Expert Judgment,”

Toward a General Theory of Expertise, Ericsson, K.A. and Smith, J. (Eds), Cambridge University Press, Cambridge, MA.

Caron, J.R., Jarvenpaa, S.L., and Stoddard, D.B. (1994), “Business Reengineering at CIGNA Corporation: Experiences and Lessons Learned from the First Five Years,” MIS Quarterly, V.18,

No.3.

Champy, J. (1995), “Reengineering Management,” Harper Business, New York, NY.

Chapman, W. (1991), Inventing Japan: The Making of a Postwar Civilization, Prentice Hall, New

York, NY.

Checkland, P. (1991), “From Framework through Experience to Learning: The Essential Nature of

Action Research,” Information Systems Research: Contemporary Approaches and Emergent

Traditions, Nissen, H., Klein, H.K. and Hirschheim, R. (Eds), North-Holland, New York,

NY, pp. 397-403.

Checkland, P. and Scholes, J. (1990), Soft Systems Methodology in Action, John Wiley & Sons, New

York, NY.

Childe, S.J. (1995), “Business Process Reengineering,” Management Bibliographies & Reviews,

V.21, No.3.

Childe, S.J., Maull, R.S. and Benett, J. (1994), “Frameworks for Understanding Business Process

Reengineering,” International Journal of Operations & Productions Management, V.14,

No.12.
54

Davenport, T. (2000), Mission Critical: Realizing the Promise of Enterprise Systems, Harvard Business School Press, Boston, MA.

Davenport, T.H. (1993), Process Innovation, Harvard Business Press, Boston, MA.

Davenport, T.H. (1993a), “Need Radical Innovation and Continuous Improvement? Integrate Process Re-engineering and Total Quality Management,” Planning Review, V.21, No.3, pp. 6-

12.

Davenport, T.H. and Short, J.E. (1990), “The New Industrial Engineering: Information Technology

and Business Process Redesign,” Sloan Management Review, V.31, No.4, pp. 11-27.

Davenport, T.H., Jarvenpaa, S.L. and Beers, M.C. (1996), “Improving Knowledge Work Processes,”

Sloan Management Review, V.37, No.4, pp. 53-65.

Davidow, W.H. and Malone, M.S. (1992), The Virtual Corporation, HarperCollins, New York, NY.

Davis, W.S. (1983), System Analysis and Design: A Structured Approach, Addison-Wesley, Reading, MA.

Dean, D.L., Lee, J.D., Orwig, R.E., Vogel, D.R. (1995), “Technological Support for Group Process

Modeling,” Journal of Management Information Systems, V.11, No.3, pp. 42-63.

Deming, W.E. (1986), Out of the Crisis, Center for Advanced Engineering Study, Massachusetts

Institute of Technology, Cambridge, MA.

Dennett, D.C. (1991), Consciousness Explained, Little, Brown and Co., Boston, MA.

Dennis, A. and Wixom, B.H. (2000), Systems Analysis and Design: An Applied Approach, John

Wiley & Sons, New York, NY.

Dingle, M.E. (1994), Business Process Reengineering: A New Zealand Perspective, Research Report, Department of Executive Education, Massey University, Palmerston North, New Zealand.

Dozier, R.W., Jr. (1992), Codes of Evolution, Crown Publishers, New York, NY.

Drucker, P.F. (1989), The New Realities, Harper & Row, New York, NY.

Drucker, P.F. (1993), “Professional’s Productivity,” Across the Board, V.30, No.9, p. 50.

Drucker, P.F. (1995), “Rethinking Work,” Executive Excellence, February.

Earl, M.J. (1994), “The New and the Old of Business Process Redesign,” Journal of Strategic Information Systems, V.3, No.1, pp. 5-22.

Elden, M. and Chisholm, R.F. (1993), “Emerging Varieties of Action Research,” Human Relations,

V.46, No.2, pp. 121-141.

Evaristo, J.R., Adams, C. and Curley, S. (1995). “Information Load Revisited: A Theoretical Model,”

Proceedings of the 16th International Conference on Information Systems, DeGross, J.I.,

Jarvenpaa, S. and Srinivasan, A. (Eds), The Association for Computing Machinery, New

York, NY.

Feldman, J. (1986), “On the Difficulty of Learning from Experience,” The Thinking Organization,

Sims, H.P., Jr. and Gioia, D.A. (Eds), Jossey-Bass, San Francisco, CA.

Francis, D. (1991), “Moving from Non-Interventionist Research to Participatory Action,” Proceedings of The First World Congress on Action Research, V.2, Collins, C. and Chippendale, P.

(Eds), Acorn, Sunnybank Hills, Queensland, Australia, pp. 31-42.

Galbraith, J. (1977), Organizational Design, Addison-Wesley, Reading, MA.

Gardner, H. (1985), The Mind’s New Science, Basic Books, New York, NY.

Geyelin, M. (1994), “Doomsday Device,” The Wall Street Journal, August 8.
55

Goldratt, E. (1990), Theory of Constraints, North River Press, New York, NY.

Goldratt, E.M. (1991), The Haystack Syndrome: Sifting Information out of the Data Ocean, North

River Press, New York, NY.

Goldratt, E.M. and Cox, J. (1986), The Goal: A Process of Ongoing Improvement, North River

Press, New York, NY.

Goldratt, E.M. and Fox, R.E. (1986), The Race, North River Press, New York, NY.

Gore, M. and Stubbe, J.W. (1988), Elements of Systems Analysis, Brown Publishers, Dubuque, IA.

Guha, S., Kettinger, W.J. and Teng, J.T.C. (1993), “Business Process Reengineering, Building a

Comprehensive Methodology,” Information Systems Management, Summer.

Hackett, P. (1990), “Investment in Technology — The Service Sector Sinkhole?” Sloan Management Review, Winter.

Hall, G., Rosenthal, J. and Wade, J. (1993), “How to Make Reengineering Really Work,” Harvard

Business Review, November-December.

Hammer, M. (1990), “Reengineering Work: Don’t Automate, Obliterate,” Harvard Business Review,

V.68, No.4, pp. 104-114.

Hammer, M. (2000), “Reengineering Redux,” CIO Magazine, V.13, No.10, pp. 143-156.

Hammer, M. and Champy, J. (1993), Reengineering the Corporation, Harper Business, New York,

NY.

Harrington, H.J. (1991), Business Process Improvement, McGraw-Hill, New York, NY.

Harrington, J.H. (1991), Business Process Improvement, McGraw-Hill, New York, NY.

Harrington, J.H., Esseling, E.K.C. and Van Nimwegen, H. (1998), Business Process Improvement

Workbook: Documentation, Analysis, Design, and Management of Business Process Improvement, McGraw-Hill, New York, NY.

Hawking, S.W. (1988), A Brief History of Time, Bantam Books, New York, NY.

Hayek, F.A. (1996), “The Use of Knowledge in Society,” Knowledge Management and Organizational Design, Myers, P.S. (Ed), Butterworth-Heinemann, Boston, MA, pp. 7-15.

Holsapple, C.W. and Whinston, A.B. (1996), Decision Support Systems: A Knowledge-Based Approach, West Publishing, St. Paul, MN.

Holyoak, K.J. (1991), “Symbolic Connectionism: Toward Third-Generation Theories of Expertise,”

Toward a General Theory of Expertise, Ericsson, K.A. and Smith, J. (Eds), Cambridge University Press, Cambridge, MA.

Hunt, V.D. (1996), Process Mapping: How to Reengineer your Business Processes, John Wiley &

Sons, New York, NY.

Jacobson, I., Ericsson, M. and Jacobson, A. (1995), The Object Advantage, Addison-Wesley, New

York, NY.

Juran, J. (1989), Juran on Leadership for Quality, The Free Press, New York, NY.

Kock, N. (1995), Process Reengineering, PROI: A Practical Methodology, Editora Vozes, Sao Paulo,

Brazil (in Portuguese).

Kock, N. (1998), “Government Transformation and Structural Rigidity: Redesigning a Service Acquisition Process,” Acquisition Review Quarterly, V.5, No.1, pp. 1-18.
56

Kock, N. (1999), “Information Overload in Organizational Processes: A Study of Managers and

Professionals’ Perceptions,” Managing Information Technology Resources in Organizations

in the Next Millennium, Khosrowpour, M. (Ed), Idea Group Publishing, Hershey, PA, pp.

313-320.

Kock, N. (1999a), Process Improvement and Organizational Learning: The Role of Collaboration

Technologies, Idea Group Publishing, Hershey, PA.

Kock, N. and McQueen, R.J. (1995), “Integrating Groupware Technology into a Business Process

Improvement Framework,” Information Technology & People, V.8, No.4.

Kock, N. and McQueen, R.J. (1996), “Product Flow, Breadth and Complexity of Business Processes: An Empirical Study of Fifteen Business Processes in Three Organizations,” Business

Process Reengineering & Management, V.2, No.2, pp. 8-22.

Kock, N. and McQueen, R.J. (1998), “Knowledge and Information Communication in Organizations: An Analysis of Core, Support and Improvement Processes,” Knowledge and Process

Management, V.5, No.1, pp. 29-40.

Kock, N. and McQueen, R.J. (1997), “Using Groupware in Quality Management Programs,” Information Systems Management, V.14, No.2.

Kock, N., McQueen, R.J. and Scott, J.L. (1997), “Can Action Research be Made More Rigorous in

a Positivist Sense? The Contribution of an Iterative Approach,” Journal of Systems and Information Technology, V.1, No.1, pp. 1-24.

Kock, N.F., Jr. and Tomelin, C.A. (1996), PMQP: Total Quality Management in Practice, Business

Development Center, SENAC, Curitiba, Brazil (in Portuguese).

Kock, N.F., Jr., McQueen, R.J. and Corner, J.L. (1997a), “The Nature of Data, Information and

Knowledge Exchanges in Business Processes: Implications for Process Improvement and

Organizational Learning,” The Learning Organization, V.4, No.2.

Kryt, J. (1997), “Information Conundrum: Semantics ... With a Payoff!” Informatica, V.21, No.2.

Lau, F. (1997), “A Review on the Use of Action Research in Information Systems Studies,” Information Systems and Qualitative Research, Lee, A.S., Liebenau, J. and DeGross, J.I. (Eds),

Chapman & Hall, London, England, pp. 31-68.

Lord, R.G. and Foti, R.J. (1986), “Schema Theories, Information Processing and Organizational

Behaviour,” The Thinking Organization, Sims, H.P., Jr. and Gioia, D.A. (Eds), Jossey-Bass,

San Francisco, CA.

Mark, J.A. (1984), “Productivity Measurement: The Government’s Role in the United States,” The

Measurement and Implications of Productivity Growth, Sherer, P. and Malone, T. (Eds), Australian Government Publishing Service, Canberra, Australia.

Maull, R., Childe, S., Bennett, J., Weaver, A.M. and Smart, P.A. (1995), Report on Different Types of

Manufacturing Processes and IDEF0 Models Describing Standard Business Processes, Working Paper WP/GR/J95010-4, School of Computing, University of Plymouth, Plymouth, England.

Mayo, E. (1945), The Social Problems of an Industrial Civilization, Macmillan, New York, NY.

Meyer, B. (1998), “The Future of Object Technology,” IEEE Computer, V.31, No.1.

Miller, G.A. (1956), “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information,” The Psychological Review, V.63.

Misterek, S.D.A., Dooley, K.J. and Anderson, J.C. (1992), “Productivity as a Performance Measure,” International Journal of Operations & Production Management, V. 12, No. 1.
57

Nissen, M.E. (1998), “Redesigning Reengineering through Measurement-driven Inference,” MIS

Quarterly, V.22, No.4, pp. 509-534.

Olson, D.L. and Courtney, J.F., Jr. (1992), Decision Support Models and Expert Systems, Macmillan,

New York, NY.

Ould, M.A. (1995), Business Processes: Modeling and Analysis for Reengineering and Improvement, John Wiley & Sons, Chichester, England.

Partridge, C. (1994), “Modeling the Real World: Are Classes Abstractions or Objects?” Journal of

Object-Oriented Programming, V.7, No.7.

Peters, M. and Robinson, V. (1984), “The Origins and Status of Action Research,” The Journal of

Applied Behavioral Science, V.20, No.2, pp. 113-124.

Pinker, S. (1997), How the Mind Works, W.W. Norton & Co., New York, NY.

Popper, K.R. (1992), Logic of Scientific Discovery, Routledge, New York, NY.

Pressman, R. (1987), Software Engineering: A Practitioner’s Approach, McGraw-Hill, New York,

NY.

Ramsey, D.K. (1987), The Corporate Warriors, Houghton Mifflin, Boston, MA.

Rapoport, R.N. (1970), “Three Dilemmas in Action Research,” Human Relations, V.23, No.6, pp.

499-513.

Rigby, D. (1993), “The Secret History of Process Reengineering,” Planning Review, V.21, No.2,

March/April, pp. 24-27.

Russel, S. and Norvig, P. (1995), Artificial Intelligence: A Modern Approach, Prentice Hall, Upper

Saddle River, NJ.

Smith, A. (1910), The Wealth of Nations, Vol.1, J.M. Dent & Sons, London, England (first published

1776).

Smith, A. (1910a), The Wealth of Nations, Vol.2, J.M. Dent & Sons, London, England (first published 1776).

Somerville, I. (1992), Software Engineering, Addison-Wesley, New York, NY.

Strassmann, P. (1996), The Value of Computers, Information and Knowledge, Working Paper,

Strassmann Inc., New Canaan, CT.

Strassmann, P. (1997), The Squandered Computer, The Information Economics Press, New Canaan,

CT.

Susman G.I. and Evered, R.D. (1978), “An Assessment of the Scientific Merits of Action Research,”

Administrative Science Quarterly, V.23, December, pp. 582-603.

Taylor, F.W. (1885), A Piece Rate System, McGraw-Hill, New York, NY.

Taylor, F.W. (1911), The Principles of Scientific Management, Norton & Company, New York, NY.

Teichman, J. and Evans, K.C. (1995), Philosophy: A Beginner’s Guide, Blackwell, Oxford, UK.

Thomas, D. (1989), “What’s in an Object,” Byte, March.

Toffler, A. (1970), Future Shock, Bantam Books, New York, NY.

Toffler, A. (1991), Powershift, Bantam Books, New York, NY.

Venkatraman, N. (1994), “IT-Enabled Business Transformation: From Automation to Business Scope

Redefinition,” Sloan Management Review, V.35, No.2.

Walton, M. (1989), The Deming Management Method, Mercury, London.
58

Waring, S.P. (1991), Taylorism Transformed, The University of North Carolina Press, Chapel Hill,

NC.

Wastell, D.G., White, P. and Kawalek, P. (1994), “A Methodology for Business Process Redesign:

Experiences and Issues,” Journal of Strategic Information Systems, V.3, No.1.

Weick, K.E. and Bougon, M.G. (1986), “Organizations as Cognitive Maps: Charting Ways to Success and Failure,” The Thinking Organization, Sims Jr., H.P. and Gioia, D.A. (Eds), JosseyBass, San Francisco, CA.

White, T.E. and Fischer, L. (Eds) (1994), The Work-flow Paradigm, Future Strategies, Alameda, CA.

Winter, R. (1989), Learning from Experience: Principles and Practice in Action-Research, The Falmer

Press, New York, NY.

Wood-Harper, A.T. (1985), “Research Methods in Information Systems: Using Action Research,”

Research Methods in Information Systems, Mumford, E., Hirschheim, Fitzgerald, G. and

Wood-Harper, A.T. (Eds), North-Holland, Amsterdam, The Netherlands, pp. 169-191.

Woofford, J.C. (1994), “Getting Inside the Leader’s Head: A Cognitive Processes Approach to Leadership,” SAM Advanced Management Journal, V.59, No.3.
59

AUTHOR NOTES

Ned Kock

Ned Kock is Assistant Professor in the Department of Computer and Information Sciences, Temple

University, Philadelphia, PA. He holds a B.E.E. in electronics engineering, a M.Sc. in computer

science, and a Ph.D. in information systems from the University of Waikato, New Zealand. Ned has

been working as a systems analyst and organizational development consultant since 1987 and has

provided services to several companies including HSBC Bamerindus Bank, PricewaterhouseCoopers,

Johnson & Johnson, Rio de Janeiro State Construction Company, Westaflex, New Zealand Ministry

of Agriculture and Fisheries, True North, and Day and Zimmermann. He is the author of three scholarly books, including Process Improvement and Organizational Learning: The Role of Collaboration Technologies (Idea Group Publishing, 1999). He has also authored articles in a number of journals including the Acquisition Review Quarterly, Communications of the ACM, Journal of Organizational Computing and Electronic Commerce, Information & Management, Information Systems Journal, and Information Technology & People. Ned is associate editor of the Journal of Systems and

Information Technology, coeditor of ISWorld‘s Professional Ethics Section, and a member of the

editorial board of the Journal of Information Technology Cases and Applications. Branches of the

Brazilian, New Zealand, and U.S. governments, as well as several private organizations in these

countries, have funded his research. His current research interests are on knowledge communication

in organizations, the relationship between organizational cognition modes and competitiveness, and

collaborative systems support effects on organizational cognition and improvement.

Frederic Murphy

Frederic H. Murphy is a Professor in the Department of Management Science/Operations Management in the Fox School of Business and Management at Temple University. He has a B.A. in

mathematics (1968) and Ph.D. (1971) in the area of operations research from Yale University. Prior to

joining Temple in 1982, he forecasted domestic energy markets at the Energy Information Administration (EIA) of the Department of Energy for several years. At the EIA he managed the development

of a large-scale forecasting system with a team that included staff programmers and contractors. An

important feature of the modeling system was that it redesigned the process by which the forecasts

were developed, substantially reducing the workload of the forecasting team. As a summer research

fellow at Resources for the Future, he worked on issues of energy security. He has also been a

consultant to the EIA on the development of its latest forecasting system. He has published in the

areas of operations research and energy policy analysis and modeling. He was the editor in chief of

Interfaces, and he is an area editor of Operations Research.
60
61

APPENDIX A

PROJECT SCHEDULE

PROJECT SCHEDULE

July October January April

ID Task Name Duration Start May 1 Jun 1 Jul 1 Aug 1 Sep 1 Oct 1 Nov 1 Dec 1 Jan 1 Feb 1 Mar 1 Apr 1 May 1

 1 Develop methodology 80 days Wed 05/17/00 2 Develop support web site 20 days Wed 08/09/00 3 Conduct validation (process redesign) 80 days Wed 09/06/00 4 Write and submit 1st conference paper 30 days Wed 12/27/00 5 Review process redesign implementation 5 days Wed 02/07/01 6 Write and submit 2nd conference paper 30 days Wed 02/14/01 7 Review process redesign implementation 5 days Wed 03/28/01 8 Write and submit 2 journal articles 30 days Wed 04/04/019 Write and submit final report 30 days Wed 04/04/01

Task Project schedule

Date Fri 1/7/00
62
63

APPENDIX B

ACTIVITY-FLOW AND DATA-FLOW DIAGRAMS USED

Sample Functional Timeline Flowchart Generated by the Redesign Team

(Activity names were listed next to the diagram.)

Start 1

3.1

4

3.6 3.6 3.6

7.1 7.1 7.1

7

5

6

7.2 7.1

Contracts

Manager

Contracts

Administrator Customer

Program

Manager

Finance &

Accounting

Technical

Level

ActivityProcessingTime (Days)Cycle Time(Days)

1

2

3.1

3.2

3.3

3.4

3.5

3.6

4

5

6

7

7.1

7.2

8

9

10

11

12

13

14

14.1

14.2

14.3

14.3.1

14.3.3

14.4

15

1

2

5

10

5

5

2

5

1

0.5

3

5

3

3

1

2.5

5

1

1

3

5

1

1

4

5

3

1

1

1

3

1

1

2

2

1

1

1

62.5

1

1

1

5

1

5

7.5

3

1

1

1

10

1

10

20

5

1

1

1

114

2

3.3

3.2

3.4

3.5

7.1

7.2 7.1
64

Sample Data-flow Diagram Generated by the Redesign Team

APPENDIX B

ACTIVITY-FLOW AND DATA-FLOW DIAGRAMS USED — Continued
65

APPENDIX C

BUSINESS PROCESS REDESIGN GUIDELINES USED

The business process redesign team used the following guidelines, compiled from a large body of

literature on business process redesign. These guidelines are discussed in more detail in Chapter 3 of

this report. In the list below, the name of the technique is followed by a brief description of why the

technique may lead to business process improvement. This information is provided here for quick

reference. (Note: There will be some overlapping between the descriptions below and those provided

in Chapter 3.)

• Foster asynchronous communication. When people exchange information, they can do it

synchronously (i.e., interacting at the same time) or asynchronously (i.e., interacting at different times). One example of synchronous communication is a telephone conversation. If the

conversation takes place via E-mail, it then becomes an example of asynchronous communication. It has been observed, especially in formal business interaction, that asynchronous communication is almost always more efficient. For example, synchronous communication often

leads to time waste (e.g., waiting for the other person to be found), and communication tends

to be less objective. Asynchronous communication can be implemented with simple artifacts,

such as in-boxes and out-boxes, fax trays, and billboards. These artifacts work as dynamic

information repositories.

• Eliminate duplication of information. Static repositories, as opposed to dynamic repositories,

hold information on a more permanent basis. A student file maintained by a primary school, for

example, is a static repository of information. Conversely, the data entry form used to temporary

store student information that will be entered into the student file is not a static repository. Duplication of information in different static repositories often creates inconsistency problems, which

may have a negative impact on productivity and quality. Kock (1995) describes a situation where

a large automaker’s purchasing division tried to keep two supplier databases updated. One database was updated manually and the other through a computer system. Two databases were

being kept because the computer database had presented some problems and, therefore, was

deemed unreliable. This, in turn, caused a large number of inconsistencies between the two

databases. Each database stored data regarding over 400 parts suppliers.

• Reduce information flow. To the detriment of effectiveness, excessive information flow is often

caused by an over-commitment to efficiency. Information is perceived as an important component of processes, and this perception drives people to an unhealthy information hunger. This

hunger causes information overload and the creation of unnecessary information processing

functions within the organization. Information overload leads to stress and, often, the creation of

information filtering roles. These roles are normally those of aides or middle managers, who are

responsible for filtering in the important bit from the information coming from both the bottom

and outside of the organization. Conversely, excessive information that flows top-down forces

middle managers to become messengers and, thus, damages their more important roles. Information flow can be reduced by selecting the information that is important in processes, eliminating

the rest, and by effectively using group support and database management systems.
66

• Reduce control. Control activities do not normally add value to customers. They are often

designed to prevent problems from happening as a result of human mistakes. In several cases,

however, control itself fosters neglect and has a negative impact on productivity. For example,

knowing that there will be some kind of control to catch mistakes, a worker may not be careful

enough when performing a process activity. Additionally, some types of control, such as those

aimed at preventing fraud, may prove to be more costly than no control at all. Some car

insurance companies, for example, have determined that the cost of accident inspections for a

large group of customers was much more expensive than the average cost of frauds committed

by that group.

• Reduce the number of contact points. Contact points can be defined as points where interaction between two or more people, both inside and outside of the process, occurs. This involves

contacts between functions and between functions and customers. Contact points generate

delays and inconsistencies and, when in excess, lead to customer perplexity and dissatisfaction. For example, in self-service restaurants and warehouses, the points of contact were successfully reduced to a minimum. Additionally, it is much easier to monitor customer perceptions in situations where there are a small number of contact points. This makes it easier to

improve process quality.

• Execute activities concurrently. Activities are often executed in sequence, even when they

could be done concurrently. This has a negative impact primarily on productivity and is easier

to spot on process flowcharts than in data-flow diagrams. For example, in a car assembly

process, doors and other body parts can be assembled concurrently with some engine parts;

and, by redesigning their processes accordingly, several automakers noted that the assembly

of certain car models was significantly speeded up.

• Group interrelated activities. Closely interrelated activities should be grouped in time and

space. Activities that use the same resources (i.e., artifacts or functions) may be carried out at

the same location and, in some cases, at the same time. Ned Kock (1999) illustrates this point

using the case of a telephone company that repaired external and internal house telephone

connections. This company had two teams, one team performed internal repairs and the other

performed external repairs. Internal repairs occur (by definition) within the boundaries of a

commercial building or residence, and external repairs involve problems outside these boundaries. Whenever a customer complaint was received, the telephone company sent its internal

team first. Should this team find no internal connection problem, the external team would then

be dispatched to check the problem. A process improvement group determined that most of

the problems were external; and, by not combining the two teams into a single repair team, the

company was wasting thousands of dollars a year and upsetting their customers due to repair

delays

• Break complex processes into simpler ones. Complex processes with dozens (hundreds in

some cases) of activities and decision points should be “broken” into simpler ones. It is often

much simpler to train workers to execute several simple processes than one complex process.

It is also easier to avoid mistakes in this way because simple processes are easy to understand

and coordinate. In support of this point, Ned Kock (1999) presented the case of an interna-
67

tional events organizer, which was structured around two main processes — the organization

of national and international events. After a detailed analysis of these two processes, which

embodied over a hundred activities each, it was found that they both could be split into three

simpler subprocesses — the organization of exhibitions, conferences, and exhibitor’s participation. This simplification improved the learning curve for the processes and reduced the

occurrence of mistakes. It did not, however, lead to an increase in the number of employees

needed because, with simpler processes, one person could perform functions in various processes at the same time.
68