Managing Information Technology

342 Part III • Acquiring Information Systems

Sales

History

Inventory

Back Orders Demand Forecast

Bill of

Materials

Master Schedule

Management

Judgment

Stock

Outs

On

Hand

Planned

Adjusted

Dates

WorkOrders Shop Orders

Released

Requisitions

Scrap

Receipts

Orders

Shop Order

Shipments

Allocations

Orders Orders

Handle

Customer

Order

Forecast

Demand

Material

Requirements

Planning

Determine

Master

Production

Schedule

Account

for

Inventory

Release

Shop

Orders

Manufacturing

Activity

Planning

Purchase

and Receive

Items

Monitor

Plant

FIGURE 8.10 Physical Model of a System

logical before the physical, even though the logical is
influenced by what new technology makes possible.
Creation of the Physical To-Be model is a task
dominated by IS specialists, as it requires technology
expertise to map the logical requirements to available
technology. Although information systems are implement-
ed with specific hardware and software, participants in
systems development efforts are cautioned to resist the
urge to make decisions related to design and implementa-
tion until as late as possible in the project. Premature
fixation on a particular technology has often led to unsatis-
factory outcomes because it can cause important aspects of
the system to go undiscovered or put undue emphasis on
howto do something before there is certainty about what
needs to be done. In reality, although no IS project is truly
a “clean slate,” delaying judgment until the Physical To-Be
stage is the recommended strategy.
After a new system has been implemented and is
operational, a diagram like that in Figure 8.10 would be used
to show a physical model of the key system components and
their relationships. It uses the following symbols:

Note, however, that this diagram makes no references

to details such as what type of computer hosts the software

or what language it is written in. Instead, the Physical To-Be

model is a high-level model. It communicates how the new

system will work and helps identify any dependencies that

might lead to downstream impacts, such as data integrity

problems or inadequate process definitions. It is implicit,

however, that it will be technically possible to implement the

physical model with available hardware, software, and

networking, or that new technology can be developed.

A Physical To-Be model may use different symbols to

distinguish between human and computerized processes,

may use notations to indicate which processes communicate

across different computers and even geographical locations

of processes and data. However, references are not made to

specific pieces of equipment or people.

Boxes for Major modules

Cylinders for Databases

Arrows for Flow of data