Managing Information Technology

Chapter 8 • Basic Systems Concepts and Tools 339

teleconferencing, group support systems, e-mail,

and others can create an information processing

environment in which time and space are

compressed. Hammer reports on the experience of

Hewlett-Packard, which treats the purchasing

departments of 50 manufacturing units as if they

were one giant department by using a shared data-

base on vendor and purchase orders. The result is

50 to 150 percent improvement in key performance

variables for the purchasing function.

5. Link parallel activities instead of integrating their
   resultsThis principle says that related activities should
   be constantly coordinated rather than waiting until a
   final step to ensure consistency. For example, Hammer
   suggests that different kinds of credit functions in a
   financial institution could share common databases,
   use communication networks, and employ teleconfer-
   encing to coordinate their operations. This would
   ensure, for example, that a customer is not extended a
   full line of credit from each unit.


6. Have the people who do the work make all the
   decisions, and let controls built into the system
   monitor the processThe result of this principle is
   the drastic reduction of layers of management, the
   empowerment of employees, and the shortcutting of
   bureaucracy. This principle emphasizes the impor-
   tance of building controls into a system from the
   start, rather than as an afterthought (see the section
   entitled “Information Systems Controls to Minimize
   Business Risks” at the end of this chapter).

However, not all BPR projects of the early 1990s
were successes. In fact, Keen (1997) points out that Mutual
Benefit Life, whose radical reengineering example was
described previously, was taken over by regulators due to
insolvency about the time Hammer lauded it as a success
story. By the mid-1990s many firms began to acknowledge
that a combination approach of both radical change and
incremental change (such as continuous improvements
as part of quality management initiatives) was more
successful (El Sawy, 2001).
By the mid-1990s client/server versions of enterprise
system packages had also become widely available,
making it possible for large companies to implement
systems that would support complex processes across
multiple functions for the first time: Earlier attempts to
become more process oriented had been aborted because
systems to support their reengineered processes were too
difficult to custom develop. For example, as described in
Chapter 5, enterprise resource planning (ERP) packages
offered by vendors such as SAP and Oracle provide
integrated software modules that use the same centralized

database for manufacturing, purchasing, and accounting

transactions. Similarly, packages to support customer rela-

tionship management (CRM) by vendors such as Siebel

from Oracle provide modules that can integrate customer

data from multiple communication “channels,” which are

typically managed by different business units (e.g.,

marketing, sales, and customer support).

PROCESSES AND TECHNIQUES TO

DEVELOP INFORMATION SYSTEMS

We turn now to processes and techniques for developing

information systems. Our intent here is to introduce the

key concepts that underlie the toolkits of system

professionals. We also emphasize topics of use to both IS

specialists and business managers who are asked to

participate in, or lead, systems projects.

The Information Systems Development

Life Cycle

Figure 8.8 presents the three phases of a generic systems

development life cycle (SDLC) model: Definition,

Construction, and Implementation. Although there are

various versions of the SDLC, some with more refined

phases, this three-phase model captures the essence of

what IS specialists and business managers participate in.

In the Definitionphase, end users and systems

analysts conduct a multistep analysis of the current

business operations and the information system or systems

in the area of concern. Current operations and systems are

described, at a high level, via both process-oriented and

data-oriented notations. A high-level description is usually

sufficient for identifying issues and for later understanding

how to transition from the As-Is to the To-Be systems.

Process-oriented analysis concentrates on the flow, use,

and transformation of data. Data-oriented analysis focuses

on the kinds of data needed in a system and the business

FIGURE 8.8 Generic Systems Development Life Cycle

Definition

Implementation

Construction