336 Part III • Acquiring Information Systems
submission of a request for classes is via a computer
terminal or a touch-tone telephone, whether the prerequisite
checking is done manually or by electronic comparison of
transcript with course descriptions, and so on.
Some people find logical system descriptions to be
too abstract to confirm what functionality is really needed
and if business requirements will be met. To overcome
this disconnect, a physical system can be used to commu-
nicate the logical system. Some systems development
methods (which we describe in Chapter 9 under the general
category of prototyping) intermix logical and physical
design. In these methods, building a physical, working
prototype of an information system is done for the purpose
of developing, communicating, and testing ideas about the
functionality (logical system). The prototype is very likely
NOT the physical design that will be used for the
information system that goes into production. The final
prototype is interpreted as a concrete logical system to
inform the actual physical design process. For very small
information systems, the final prototype may have
evolved into a workable physical design.
PROBLEM-SOLVING STEPS The three following principles,
or problem-solving steps, have also been associated with
good SA&D processes. In fact, they are recommended as
good principles for problem solvers in general.
- A problem (or system) is actually a set of prob-
lems; thus, an appropriate strategy is to keep
breaking a problem down into smaller and smaller
problems, which are more manageable than the
whole problem. - A single solution to a problem is not usually obvious
to all interested parties, so alternative solutions
representing different perspectives or which make
different trade-offs among desired outcomes should
be generated and compared before a final solution is
selected. - The problem and your understanding of it could
change while you are analyzing it, so you should
take a staged approach that incorporates reassess-
ments; this allows an incremental commitment to a
particular solution, with a “go” or “no-go” decision
after each stage.
Later in this chapter, we will introduce a generic life-
cycle process for developing new systems, as well as some
specific techniques used by SA&D professionals. First,
however, let us develop a shared understanding of the
“what” that is driving many IS development and
implementation projects today: systems to support cross-
functional business processes.
BUSINESS PROCESSES
In the 1990s, many organizations began to transform their
businesses in an effort to sense and respond more quickly to
global threats and demands for cost cutting. Many of these
transformation efforts were directed at moving away from a
functional “silo” approach to a more process-oriented
approach. Organizing work and work structures around
business processes—rather than business functions or
business products—requires a new mind-set in which basic
assumptions are challenged and change is embraced. A
business processis the chain of activities required to
achieve an outcome such as order fulfillment or materials
acquisition. Information systems are used to facilitate radi-
cal restructuring from silos to true core business processes.Identifying Business Processes
According to Peter Keen (1997), the identification of a
firm’s core processes is a key analytical task. For example,
a typical manufacturing firm may have six core processes:
sensing the market, developing product, sourcing of
materials, manufacturing product, selling product, and
fulfilling customer order. A firm’s core processes should
not be viewed just as its workflows. Rather, these business
processes should be viewed as the firm’s assets and liabili-
ties. By evaluating the worth of a given process to a firm’s
competitiveness, managers should be able to identify a
small number of processes that need their attention the
most. These are the processes where improvements,
including “best practice” information processing, can yield
the greatest value.
Figure 8.6 shows one way in which managers can
evaluate the importance of a given business process. Folklore
processes are those processes that are carried out only
because they have been in the past; they are often difficult to
identify because they are so embedded in an organization’s
tasks. When they are identified, they should be abandoned
because they create no economic value. Keen also warns that
the importance (salience) of a given process is not necessarily
the same in different companies in the same industry or even
in the same company under different circumstances.Business Process Redesign
In a seminal article published in the Harvard Business
Review, reengineering expert Michael Hammer urged
companies to start with a “clean slate” and use IT to radi-
cally change the way they did business: “Don’t automate;
obliterate!” By the early 1990s, consulting firms had
developed expertise in what came to be referred to as
business process reengineering (BPR):radical business
redesign initiatives that attempt to achieve dramatic