Managing Information Technology

Chapter 8 • Basic Systems Concepts and Tools 335

change in IT is made in an organization—such as the intro-
duction of a new software application—this change is likely
to affect the other three components. For example, people
will have to be retrained, methods of work (business process-
es) will have to be redesigned, and old reporting relationships
(organization structure) will have to be modified. The
important principle here is that:

Each time we change characteristics of one

or more of these four components, we must

consider compensating changes in the others.

This raises an interesting question: With which of
the four components do we start? There is no universal
answer to this question, and organizational politics can
play a key role in this decision. For example, organization
theorists have argued that changes in technology can lead
to organizational changes (technological imperative); that
organizational factors can drive changes in technology
(organizational imperative); and that changes are difficult
to predict because of variations in purpose, processes, and
organizational settings (Markus and Robey, 1988). In the
1990s many large U.S. companies chose to make large-
scale changes in the way they conducted business by
replacing custom information systems with a large
software package (such as an enterprise resource planning
[ERP] system) in which a vendor embedded the “best
practices” for a business function or even an industry.

Systems Analysis and Design

A major process used in developing a new information
system is called systems analysis and design (SA&D).
SA&D processes are based on a systems approach to
problem solving. Here we describe several fundamental
principles associated with good SA&D techniques that stem
from the key system characteristics described previously.
The first two principles are these:

• Choose an appropriate scopeSelecting the boundary
  for the information system greatly influences the
  complexity and potential success of an IS project.


• Logical before physicalYou must know what an
  information system is to do before you can specify
  how a system is to operate.

SYSTEM SCOPE Often the fatal flaw in conceiving and
designing a system centers on choosing an inappropriate
system scope. Apparently the designer of the house in
Figure 8.1 outlined each component separately, keeping
the boundaries narrow and manageable, and did not see all
the necessary interrelationships among the components.
Turning to a business situation, when a salesperson sells a

cheaper version of a product to underbid a competitor, that

salesperson has focused only on this one sale. However,

the costs of handling customer complaints about inadequacy

of the product, repeated trips to install upgrades, and other

possible problems make this scope inadequate.

The system boundary indicates the system scope. As

discussed earlier under the topic of system boundary,

defining the boundary is crucial to designing any system or

solving any problem. Too narrow a scope could cause you

to miss a really good solution to a problem. Too wide a

scope could be too complex to handle. Choosing an

appropriate scope is difficult but crucial in problem

solving in general and in IS projects in particular.

LOGICAL BEFORE PHYSICAL Any description of a

system is abstract because the description is not the system

itself, but different system descriptions can emphasize

different aspects of the system. Two important general

kinds of system descriptions are logical and physical

descriptions. Logical descriptions concentrate on whatthe

system does, and physical descriptions concentrate on how

the system operates. Another way to say this is “function

before form.”

Returning to our example of a house as a system, as

an architect knows, function precedes form with the

design of a new house. Before the house is designed, we

must determine how many people will live in it, how each

room will be used, the lifestyle of the family, and so on.

These requirements comprise a functional, or logical,

specification for the house. It would be premature to

choose the type of materials, color of plumbing fixtures,

and other physical characteristics before we determine

the purpose of these aspects. (Even though a recent TV

commercial in the United States has a woman telling an

architect “Design my house around this” as she presents a

faucet to him, this is not how systems should be

designed.)

We are often anxious to hurry into designing the

physical form before we determine the needed functionality.

The penalty for violating the function-before-form principle

is increased costs—the cost and efforts to fix a functional

specification error grow exponentially as you progress to the

physical. We must get the logical or functional specifica-

tions right to understand how to choose among alternate

physical implementations.

As an example of the difference between a logical

and a physical information system, consider a class

registration system. A logical systemdescription would

show such steps as submitting a request for classes,

checking class requests against degree requirements and

prerequisites, and generating class registration lists. A

physical systemdescription would show whether the