The system view

A discipline for seeing wholes

A framework for seeing interrelationships rather than things
An antidote to the sense of helplessness one feels when confronted with complexity

This section provides some templates for analyzing, describing, and redesigning systems. The
systems concepts we discuss are general ones, although we will use many information systems
examples.
What Is a System?
A system is a set of interrelated components that must work together to achieve some common
purpose. This is simply said but more difficult to apply. An information system (IS) can be
defined in a very broad way as the collection of IT, procedures, and people responsible for the
capture, movement, management, and distribution of data and information. As with other
systems, it is crucial that the components of an IS work well together. That is, the components
must be consistent, minimally redundant, complete, and well connected with one another.
Seven Key System Elements
Systems share the seven general elements; it is one or more of these elements that change or are
created when we redesign or design a new (information) system. These seven general system
elements are briefly defined as follows:
1. Boundary The delineation of which elements (such as components and storage) are
within the system being analyzed and which are outside; it is assumed that elements
within the boundary are more easily changed and controlled than those outside.
2. Environment Everything outside the system; the environment provides assumptions,
constraints, and inputs to the system.
3. Inputs The resources (i.e., data, materials, supplies, energy) from the environment that are
consumed and manipulated within the system.
4. Outputs The resources or products (i.e., information, reports, documents, screen displays,
materials) provided to the environment by the activities within the system.
5. Components The activities or processes within the system that transform inputs into
intermediate forms or that generate system outputs; components may also be considered
systems themselves, in which case they are called subsystems, or modules.
6. Interfaces The place where two components or the system and its environment meet or
interact; systems often need special subcomponents at interfaces to filter, translate, store,
and correct whatever flowsthrough the interface.
7. Storage Holding areas used for the temporary and permanent storage of information,
energy, materials, and so on; storage provides a buffer between system components to
allow them to work at different rates or at different times and to allow different
components to share the same data resources. Storage is especially important in IS
because data are not consumed with usage; the organization of storage is crucial to handle
the potentially large volume of data maintained there.
SYSTEM BOUNDARY The system boundary delineates what is inside and what is outside a
system. A boundary segregates the environment from the system or delineates subsystems from

each other. A boundary in the systems world is often arbitrary. That is, we can often choose to
include or exclude any component in the system. The choice of where to draw the boundary
depends on factors such as these:
1. What can be controlled Recognizing you cant control everything Elements outside the
control of the project team are part of the environment, and the environment often places
a constraint on the system scope. For example, if a preexisting billing system is treated as
part of the environment of a new product management system, the product management
system would be limited to devising products that can be priced and billed in ways
already supported.
2. What scope is manageable within a given time period Make progress and move on to the
next job Complex systems often take so long to design and develop that the envisioned
systems solution could no longer be the best choice by the time the project is complete.
3. The impact of a boundary change While you were gone over the weekend, we decided to
As the business changes or new information about the organization is uncovered, a
different system boundary can appear to be beneficial. This decision requires careful
analysis of the impact of such a change.
COMPONENT DECOMPOSITION
Five important goals of hierarchical decomposition of a system are the following:
1. To cope with the complexity of a system Decomposition of a complex system allows us
to break the system down into understandable pieces.
2. To analyze or change only part of the system Decomposition results in specific
components at just the right level of detail for the job.
3. To design and build each subsystem at different times Decomposition allows us to
respond to new business needs as resources permit while keeping unaffected components
intact.
4. To direct the attention of a target audience Decomposition allows us to focus on a subset
of components of importance to a subset of the total user population.
5. To allow system components to operate more independently Decomposition allows
problem components to be isolated and components to be changed, moved, or replaced
with minimal impact on other components.
Organizations as Systems
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 largescale 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 scope Selecting the boundary for the information system greatly
influences the complexity and potential success of an IS project.
Logical before physical You must know what an information system is to do before you
can specify how a system is to operate.
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 process is the chain of activities
required to achieve an outcome such as order fulfillment or materials acquisition. Information
systems are used to facilitate radical restructuring from silos to true core business processes.
Identifying Business Processes
According to Peter Keen (1997), the identification of a firms 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 firms core processes should not be viewed just as its workflows. Rather, these
business processes should be viewed as the firms assets and liabilities. By evaluating the worth
of a given process to a firms 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.
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 radically change the way
they did business: Dont 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 improvements in business
processes by questioning the assumptions, or business rules, that underlie the organizations
structures and procedures, some of which could have been in place for decades. New, disruptive,
technologies can be the catalyst for such radical redesigns (e.g., telecommunications, in general,
and group meeting tools such as WebEx, in particular, have changed the way meetings among
geographically dispersed employees are conducted).
IT as an Enabler of BPR
In both of these examples, IT played a key role as an enabler of radical business process
redesign. Hammer and Champy (1993) encourage managers to go through exercises that help
them think about how IT can be used to break old assumptions and rules. Three examples of

rule-breaking IT are provided in Figure 8.7. Hammer (1990) advocated the use of key principles
for redesigning business processes. A consolidated list of six principles is presented next.
1. Organize business processes around outcomes, not tasks This principle implies that one
person should perform all the steps in a given process, as in the case of Mutual Benefit
Life, where one manager handles the whole application approval process. IT is used to
bring together all the information and decisionmaking resources needed by this one
person. Often this principle also means organizing processes around customer needs, not
the product.
2. Assign those who use the output to perform the process The intent of this principle is to
make those most interested in a result accountable for the production of that result. For
example, Hammer reports the case of an electronics equipment manufacturer that
reengineered its field service function to have customers perform simple repairs
themselves. This principle reduces nonproductive overhead jobs, including liaison
positions. Principles 1 and 2 yield a compression of linear steps into one step, greatly
reducing delays, miscommunication, and wasted coordination efforts. Information
technologies, like expert systems and databases, allow every manager to perform
functions traditionally done by specialty managers.
3. Integrate information processing into the work that produces the information This
principle states that information should be processed at its source. For example, at Ford
this means that the receiving department, which produces information on goods received,
should also enter this data, rather than sending it to accounts payable for processing. This
puts data capture closest to the place where data entry errors can be detected and
corrected, thus minimizing extra reconciliation steps. This principle also implies that data
should be captured once at the primary source, thus avoiding transmittal and transcription
errors. All who need these data work from a common and consistent source. For example,
the true power of electronic data interchange (EDI) comes when all information
processing related to an EDI transaction works from a common, integrated database. This
principle also implies that process design should begin early in the information systems
development process, when enabling technologies can influence breaking long-standing
business rules before they are perpetuated by new information processing.
4. Create a virtual enterprise by treating geographically distributed resources as though they
were centralized This principle implies that the distinction between centralization and
decentralization is artificial with IT. Technologies such as 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 HewlettPackard, which treats the purchasing departments of 50 manufacturing units as if they
were one giant department by using a shared database 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 results This 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 teleconferencing 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 process The 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 importance of building controls into a system from the start,
rather than as an afterthought
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.