Managing Information Technology

Chapter 8 • Basic Systems Concepts and Tools 343

Distinct techniques are used at each stage of
procedural-oriented development, and no one technique is
comprehensive, or best, for each phase; in fact, multiple
techniques are often used because they complement one
another. The output from one stage serves as the input for
the next. As firms gain experience with systems develop-
ment, they often develop a preference for certain
techniques or adopt variations in the notation. The
following section introduces some of the most common
techniques, concepts, and terminology using widely
recognized notation. The techniques will be presented with
the model (As-Is, Logical To-Be, Physical To-Be) with
which they are most closely associated, using a common
business example throughout: accounts payable. An
accounts payable example is useful because accounts
payable activities interact with other business activities
(such as purchasing and receiving), are familiar to most
managers and business students, and are common across
industries.

Techniques for the As-Is Model

Whether a system is entirely manual or highly automated,
the functions and flows of the existing business activity
must be captured. Knowledge of a business process is
rarely entirely in the possession of a single person, and
there could be disagreements on the actual or preferred
processes. Procedures, policies, manuals, forms, reports,
and other documentation are used along with individual
and group interviews to identify existing processes,
external participants such as vendors and other functional
departments, other databases or applications, and the
inputs and outputs of the activities concerned.
Acontext diagrampositions the system as a whole
with regard to the other entities and activities with which it
interacts. This provides a common frame of reference for
project participants and helps define the project scope.
Figure 8.11 illustrates a context diagram for an accounts

payable system. We can see from this diagram that the

accounts payable function both receives input from

vendors and sends output to them. Other accounting

functions receive summary information about payables

activities, whereas purchasing provides the input needed to

process payables. Vendors, accounting, and purchasing are

all considered to be outside the project scope for this

development effort.

Another common technique for documenting the

As-Is system is a work process flow diagram, as shown in

Figure 8.12. This flow chart identifies the existing

information sources (i.e., purchase order file, receipts

file), information sources that are updated (changes to

invoices/payables), the order in which steps occur

(approvals before checks are printed), and some of the

dependencies or decisions (need to know whether vendor

is new or not). The way in which exceptions are handled

should also be captured (e.g., what happens to invoices

not approved). No two workflow diagrams are identical,

because they capture the unique patterns and procedures—

formal and informal—of an organization.

The work process flow diagram and other As-Is tech-

niques serve to point out where the existing system does

and does not perform as desired (both missing functionality

and process inefficiencies). Common problems include

repeated handling of the same document, excessive wait

times, processes with no outputs, bottlenecks, and extra

review steps. This shows how systems development efforts

are closely associated with business process redesign

efforts. To emphasize process flows across organizational

units—where errors can be introduced and delays can

occur—one variation of the diagram in Figure 8.12, called a

swimming lane diagram, shows which steps are processed

in which area of the organization. Moving of data across

organizational boundaries (swimming lanes) cause analysts

to consider more efficient designs. Recall that the principles

of BPR suggest that one person (or one organization)

should perform all the steps in one process.

Payable Summaries

VENDOR

ACCOUNTING

Purchase Orders

Vendor Information, Stock Receipts

PURCHASING

Vendo

rInvoices

Checks

Reje

ctedInvoices

ACCOUNTS

PAYABLE

FIGURE 8.11 Context Diagram for Accounts Payable System