Valacich J., George J., Hoffer J.A. Essentials of Systems Analysis and Design
Подождите немного. Документ загружается.
User documentation
Written or other visual
information about how an
application system works,
and how to use it.
External documentation
System documentation that
includes the outcome of
structured diagramming
techniques such as data-flow
and entity-relationship diagrams.
Internal documentation
System documentation that is part
of the program source code or is
generated at compile time.
System documentation
Detailed information about a
system’s design specifications, its
internal workings, and its
functionality.
Chapter 10 Systems Implementation and Operation 333
support. Whether a lapse in service is required or not, the installation schedule
should be announced to users well in advance to let them plan their work
schedules around outages in service and periods when their system support
might be erratic. Successful installation steps should also be announced, and
special procedures put in place so that users can easily inform you of problems
they encounter during installation periods. You should also plan for emergency
staff to be available in case of system failure so that business operations can
be recovered and made operational as quickly as possible. Another considera-
tion is the business cycle of the organization. Most organizations face heavy
workloads at particular times of the year and relatively light loads at other
times. A well-known example is the retail industry, where the busiest time of
the year is the fall, right before the year’s major gift-giving holidays. You
wouldn’t want to schedule installation of a new point-of-sale system to begin
December 1, for a department store.
Planning for installation may begin as early as the analysis of the organization
supported by the system. Some installation activities, such as buying new hard-
ware, remodeling facilities, validating data to be transferred to the new system,
and collecting new data to be loaded into the new system, must be done before
the software installation can occur. Often the project team leader is responsible
for anticipating all installation tasks and assigns responsibility for each to
different analysts.
Each installation process involves getting workers to change the way they
work. As such, installation should be looked at not as simply installing a new
computer system, but as an organizational change process. More than just a
computer system is involved—you are also changing how people do their jobs
and how the organization operates.
Documenting the System
In one sense, every information systems development project is unique and will
generate its own unique documentation. In another sense, though, system
development projects are probably more alike than they are different. Each
project shares a similar systems development life cycle, which dictates that cer-
tain activities be undertaken and that each of those activities be documented.
Specific documentation will vary depending on the life cycle you are following,
and the format and content of the documentation may be mandated by the
organization you work for. Start developing documentation elements early, as
the information needed is captured.
We can simplify the situation by dividing documentation into two basic types,
system documentation and user documentation. System documentation
records detailed information about a system’s design specifications, its internal
workings, and its functionality. System documentation can be further divided
into internal and external documentation. Internal documentation is part of
the program source code or is generated at compile time. External documen-
tation includes the outcome of all of the structured diagramming techniques
you have studied in this book, such as data-flow and entity-relationship dia-
grams. User documentation is written or other visual information about how
an application system works and how to use it. Although not part of the code
itself, external documentation can provide useful information to the primary
users of system documentation—maintenance programmers. For example,
data-flow diagrams provide a good overview of a system’s structure. In the past,
external documentation was typically discarded after implementation, primarily
because it was considered too costly to keep up to date but today’s integrated
development environment makes it possible to maintain and update external
documentation as long as desired.
334 Part V Systems Implementation and Operation
FIGURE 10-7
Online user documentation for
Microsoft Visio.
Source:
Microsoft product screen
shot(s). Reprinted with permission
from Microsoft Corporation.
Whereas system documentation is intended primarily for maintenance pro-
grammers, user documentation is intended mainly for users. An organization
should have definitive standards on system documentation. These standards
may include the outline for the project dictionary and specific pieces of docu-
mentation within it. Standards for user documentation are not as explicit.
User Documentation
User documentation consists of written or other visual information about an
application system, how it works, and how to use it. An excerpt of online user
documentation for Microsoft Visio appears in Figure 10-7. The documentation
lists the item necessary to perform the task the user inquired about. The user
controls how much of the help is shown.
Figure 10-7 represents the content of a reference guide, just one type of user
documentation. Other types of user documentation include a quick reference
guide, user’s guide, release description, system administrator’s guide, and ac-
ceptance sign-off. Most online reference guides allow you to search by topic area
or by typing in the first few letters of your keyword. Reference guides are great
for specific information (as in Figure 10-7) but are not as good for the broader pic-
ture of how to perform all the steps required for a given task. The quick reference
guide provides essential information about operating a system in a short, concise
format. Where computer resources are shared and many users perform similar
tasks on the same machines (as with airline reservation or mail-order-catalog
clerks), quick reference guides are often printed on index cards or as small books
and mounted on or near the computer terminal. The purpose of a reference guide
is to provide information on how users can use computer systems to perform spe-
cific tasks. The information in a user’s guide is typically ordered by how often
tasks are performed and how complex they are. Increasingly, software vendors
are using Web sites to provide additional user-guide content. Figure 10-8 shows
the Microsoft Visio help page. Web-based documentation allows the vendor to
provide more up-to-date reference material without issuing new software CDs.
Because most software is reissued as new features are added, a release de-
scription contains information about a new system release, including a list of
Chapter 10 Systems Implementation and Operation 335
FIGURE 10-8
Structure of an online reference
user’s guide.
Source:
Microsoft product screen
shot(s). Reprinted with permission
from Microsoft Corporation.
complete documentation for the new release, features and enhancements,
known problems and how they have been dealt with in the new release, and
information about installation. A system administrator’s guide is intended pri-
marily for a particular type of user—those who will install and administer a new
system—and contains information about the network on which the system will
run, software interfaces for peripherals such as printers, troubleshooting, and
setting up user accounts. Finally, the acceptance sign-off allows users to test for
proper system installation and then signify their acceptance of the new system
and its documentation with their signatures.
Preparing User Documentation
User documentation, regardless of its content or intended audience, is now
most often delivered online in hypertext format. In all its forms, user documen-
tation is an investment that reduces training and consultation costs. As a future
analyst, you need to consider the source of documentation, its quality, and
whether its focus is on the information system’s functionality or on the tasks the
system can be used to perform.
The traditional source of user and system documentation has been the orga-
nization’s information systems department. Until recently, the bulk of this doc-
umentation was system documentation, intended for analysts, programmers,
and those who must maintain the system.
In today’s end-user information systems environment, users interact directly
with many computing resources; users have many options or querying capabil-
ities from which to choose when using a system; and users are able to develop
many local applications themselves. Analysts often serve as consultants for
these local end-user applications. For end-user applications, the nature and pur-
pose of documentation has changed from documentation intended for the
Support
Providing ongoing educational
and problem-solving assistance
to information system users.
Support material and jobs must
be designed along with the
associated information system.
336 Part V Systems Implementation and Operation
maintenance programmer to documentation for the end user. Application-
oriented documentation, whose purpose is to increase user understanding and
utilization of the organization’s computing resources, has also come to be
important. Although some of this user-oriented documentation continues to be
supplied by the information systems department, much of it now originates with
vendors and with users themselves.
Training and Supporting Users
Training and support are critical for the success of an information system. As
the person responsible for the new system, you and other analysts on the proj-
ect team must ensure that high-quality training and support are available. Train-
ing and support help people adequately use computer systems to do their
primary work. Without proper training and the opportunity to ask questions and
gain assistance/consultation when needed, users will misuse, underuse, or not
use the information system you develop.
Although training and support can be talked about as if they are two separate
things, in organizational practice, the distinction between the two is not all that
clear, as the two sometimes overlap. After all, both deal with learning about com-
puting. It is clear that support mechanisms are also a good way to provide train-
ing, especially for intermittent users of a system. Intermittent or occasional
system users are not interested in, nor would they profit from, typical user train-
ing methods. Intermittent users must be provided with “point-of-need support,”
specific answers to specific questions at the time the answers are needed. A
variety of mechanisms, such as the system interface itself and online help facil-
ities, can be designed to provide both training and support at the same time.
Training Information System Users
Many organizations tend to underinvest in computer skills training. It is true
that some organizations institutionalize high levels of information system train-
ing, but many others offer no systematic training at all. Many studies show that
training users to be effective with the systems they have now can be a cost-
effective way to increase productivity, even more so than installing hardware
and software upgrades.
The type of necessary training will vary by type of system and expertise of
users. The list of potential topics from which you must determine whether train-
ing will be useful include the following:
쐍 Use of the system (e.g., how to enter a class registration request)
쐍 General computer concepts (e.g., computer files and how to copy them)
쐍 Information system concepts (e.g., batch processing)
쐍 Organizational concepts (e.g., FIFO inventory accounting)
쐍 System management (e.g., how to request changes to a system)
쐍 System installation (e.g., how to reconcile current and new systems
during phased installation)
As you can see from this partial list, many topics go beyond simply how to use
the new system. It may be necessary for you to develop training for users in
other areas so that they will be ready, conceptually and psychologically, to use
the new system. Some training, such as concept training, should begin early in
the project because this training can assist in convincing users of the need for
system and organizational change.
Each element of training can be delivered in a variety of ways. Table 10-5 lists
the most common training methods used by information system departments.
Electronic performance
support system (EPSS)
Component of a software
package or application in which
training and educational
information is embedded. An
EPSS may include a tutorial,
expert system, and hypertext
jumps to reference material.
Chapter 10 Systems Implementation and Operation 337
The most common delivery method for corporate training remains traditional
instructor-led classroom training. Many times users turn to the resident expert
and to fellow users for training. Users are more likely to turn to local experts for
help than to the organization’s technical support staff, because the local expert
understands both the users’ primary work and the computer systems they use.
Given their dependence on fellow users for training, it should not be surprising that
end users describe their most common mode of computer training as “self-training.”
One conclusion from the experience with user training methods is that an
effective strategy for training on a new system is first to train a few key users
and then to organize training programs and support mechanisms that involve
these users to provide further training, both formal and on-demand. Often, train-
ing is most effective if you customize it to particular user groups, and the lead
trainers from these groups are in the best position for this task.
Increasingly, corporations are turning to e-learning as a key delivery mode for
training. Although the term e-learning is not precisely defined, it generally
means the same thing as distance learning, i.e., a formalized learning system
designed to be carried out remotely, using computer-based electronic commu-
nication. You may have taken a distance learning course at your school, or you
may have experience in on-campus classes with some of the dominant software
packages used in e-learning, such as WebCT, Blackboard, or Desire2Learn.
E-learning courses can be delivered over the Internet or over company in-
tranets. Such courses can be purchased from vendors or prepared by the cor-
poration’s in-house training staff. E-learning is relatively inexpensive, compared
to traditional classroom training, and it has the additional advantage of being
available anytime from just about anywhere. Students can also learn at their
own pace. E-learning systems can make available several different elements
that enhance the learning experience, including simulations, online access to
mentors and experts, e-books, net meetings, and video on-demand. Another
trend in corporate training is blended learning, the combining of e-learning with
instructor-led classroom training. A recent survey reported that over 80 percent
of respondents were using e-learning or blended learning to train their employ-
ees. Half of the respondents in the study believed that e-learning would become
the dominant training delivery method in their organizations by 2010.
Another training method listed in Table 10-5 is software help components. One
common type is called an electronic performance support system (EPSS).
Electronic performance support systems are online help systems that go be-
yond simply providing help—they embed training directly into a software pack-
age. An EPSS may take on one or more forms: It can be an online tutorial,
provide hypertext-based access to context-sensitive reference material, or con-
sist of an expert system shell that acts as a coach. The main idea behind the
development of an EPSS is that the user never has to leave the application to get
the benefits of training. Users learn a new system or unfamiliar features at their
TABLE 10-5: Types of Training Methods
Method of Training
Formal courses—several people taught at the same time
Resident expert
E-learning/distance learning
Blended learning (combination of instructor-led training and e-learning)
Software help components
External sources, such as vendors
Help desk
A single point of contact for all
user inquiries and problems
about a particular information
system or for all users in a
particular department.
Issue tracking system
Typically a Web-based tool for
logging, tracking, and assigning
system bugs and change
requests to developers.
338 Part V Systems Implementation and Operation
own pace and on their own machines, without having to lose work time to at-
tend remote group-training sessions. Furthermore, this learning is on-demand
when the user is most motivated to learn, because the user has a task to do.
EPSS is sometimes referred to as “just-in-time knowledge.”
Supporting Information System Users
Historically, computing support for users has been provided in one of a few
forms: paper, online versions of paper-based support, as well as help desks pro-
vided by vendors or resident experts within the same organization. As we stated
earlier, support, whatever its form, has often been inadequate for users’ needs.
Yet users consider support to be extremely important.
As computing spreads throughout organizations, especially with the advent of
personal computers, the need for support increased as more and more employ-
ees came to rely on computing to do their jobs. As organizations moved to
client/server architectures, their need for support increased even more, and or-
ganizations relied more and more on vendor support. This increased need for
support comes in part from the lack of standards governing client/server prod-
ucts and the resulting need to make equipment and software from different ven-
dors compatible.
Automated Issue Tracking Bugs and change requests in any software
release are inevitable. Previously, we talked about using a system service
request (see also Chapter 3), a standard form for requesting systems
development work. To automate this process, many organizations are deploying
a Web-based issue tracking system to provide a systematic way to log, track,
and assign system bugs and change requests to developers (see Figure 10-9); the
types of information typically captured within an issue tracking system are
summarized in Table 10-6.
Automating Support As vendors have primarily shifted their offerings from
expensive mainframe packages to inexpensive off-the-shelf software, they have
found that they can no longer bear the cost of providing support for free. Most
vendors now charge for support, and many have instituted toll-free numbers and
other automated support mechanisms or sell customers unlimited support for a
given monthly or annual charge. Common methods for automating support
include online support forums (on private Web sites) and voice-response systems.
Online support forums provide users access to information on new releases, bugs,
and tips for more effective usage. Voice-response systems allow users to navigate
option menus that lead to prerecorded messages about usage, problems, and
workarounds. Organizations have established similar support mechanisms for
systems developed or purchased by the organization. Internal e-mail and instant
messaging can be used to support such capabilities within an organization.
Providing Support through a Help Desk Whether assisted by vendors
or going it alone, the center of support activities for a specific information
system in many organizations is the help desk. A help desk is an information
systems department function, staffed by IS personnel. The help desk is the first
place users should call when they need assistance with an information system.
The help desk staff either deals with the users’ questions or refers the users to
the most appropriate person.
Today, help desks are increasingly common as management comes to appre-
ciate the special combination of technical skills and people skills needed to
make good help desk staffers. Many software packages exist to automate the
record keeping for a help desk. Records must be kept on each user contact, the
content of the question or problem, and the status and resolution of the prob-
lem. Help desk managers use the software to track problems with different
Chapter 10 Systems Implementation and Operation 339
FIGURE 10-9
Bugzilla is a popular Web-
based issue tracking system.
information systems, assess help desk personnel efficiency and effectiveness,
and identify users who require training.
Help desk personnel need to be good at communicating with users, by listen-
ing to their problems and intelligently communicating potential solutions.
340 Part V Systems Implementation and Operation
These personnel also need to understand the technology they are helping users
with. It is crucial, however, that help desk personnel know when new systems
and releases are being implemented and when users are being trained for new
systems. Help desk personnel themselves should be well trained on new sys-
tems. One sure recipe for disaster is to train users on new systems but not train
the help desk personnel these same users will turn to for their support needs.
Support Issues for the Analyst to Consider
Support is more than just answering user questions about how to use a system
to perform a particular task or about the system’s functionality. Support also
consists of such tasks as providing for recovery and backup, disaster recovery,
and PC maintenance; writing newsletters and offering other types of proactive
information sharing; and setting up user groups. It is the responsibility of ana-
lysts for a new system to be sure that all forms of support are in place before
the system is installed.
For medium-to-large organizations with active information system units,
many of these issues are dealt with centrally. For example, users may be pro-
vided with backup software by the central information systems unit and a
schedule for routine backup. Policies may also be in place for initiating recov-
ery procedures in case of system failure. Similarly, disaster recovery plans are
almost always established by the central IS unit. Also, IS unit specialists may be
in charge of composing and transmitting newsletters or overseeing automated
bulletin boards and organizing user groups.
When all of these (and more) services are provided by central IS, you must fol-
low the proper procedures to include any new system and its users in the lists of
those to whom support is provided. You must design training for the support staff
on the new system, and you must make sure that system documentation will be
available to it. You must make the support staff aware of the installation sched-
ule. You must also keep these people informed as the system evolves. Similarly,
any new hardware and off-the-shelf software have to be registered with the cen-
tral IS authorities.
When no official IS support function is available to provide support services,
you must come up with a creative plan to provide as many services as possible.
You may have to write backup and recovery procedures and schedules, and the
users’ departments may have to purchase and be responsible for the maintenance
TABLE 10-6: Information Captured in an Issue Tracking System
Information in an Issue
Tracking System Rationale for Capturing This Information
Version of product • Is used in the planning of the next version of the product
• Specifically identifies problems that might carry over from different versions
Which customer has encountered the issue • Tracks not only the issue but the origination of the issue
• Allows for deeper analysis when designing a solution
Severity of the issue • Allows developers to prioritize bugs and changes so that the most critical
issues are addressed first
Who fixed the issue • Creates accountability for the developers
• Allows managers to track developer productivity
Who verified the fix • Ensures that all software fixes are tested and retested for reliability
• Provides a critical aspect of the system maintenance process
Chapter 10 Systems Implementation and Operation 341
of their hardware. In some cases, software and hardware maintenance may
have to be outsourced to vendors or other capable professionals. In such situa-
tions, user interaction and information dissemination may have to be more in-
formal than formal: informal user groups may meet over lunch or over a
coffeepot rather than in officially formed and sanctioned forums.
Why Implementation Sometimes Fails
Despite the best efforts of the systems development team to design and build a
quality system and to manage the change process in the organization, the im-
plementation effort sometimes fails. Sometimes employees will not use the new
system that has been developed for them, or if they do use the system, their level
of satisfaction with it is low.
The conventional wisdom that has emerged over the years is that at least two
conditions are necessary for a successful implementation effort: management
support of the system under development and the involvement of users in the
development process. Yet, despite the support and active participation of man-
agement and users, information systems implementation still sometimes fails.
Let’s review some insights about the implementation process:
쐍 Risk. User involvement in the development process can help reduce
the risk of failure when the system is complex, but it can also make
failure more likely when financial and time constraints affect the
development process.
쐍 Commitment to the project. The system development project should be
managed so that the problem being solved is well understood and that
the system being developed to deal with the problem actually solves it.
쐍 Commitment to change. Users and managers must be willing to
change behaviors, procedures, and other aspects of the organization.
쐍 Extent of project definition and planning. The more extensive the
planning effort, the less likely is implementation failure.
쐍 Realistic user expectations. The more realistic a user’s early
expectations about a new system and its capabilities, the more likely it
is that the user will be satisfied with the new system and actually use it.
Whether a system implementation fails or succeeds also depends on your def-
inition of success. Although determining whether an implementation has been
successful can be done in a number of ways, the two most common and trusted
are the extent to which the system is used and the user’s satisfaction with the
system. Whether a user will actually use a new system depends on several ad-
ditional factors:
1. How relevant the system is to the work the user performs.
2. System ease of use and reliability.
3. User demographics, such as age and degree of computer experience.
4. The more users can do with a system and the more creative ways they can
develop to benefit from the system, the more they will use it. Then the
more people use the system, the more likely they are to find even more
ways to benefit from the system.
5. The more satisfied the users are with the system, the more they will use it.
The more they use it, the more satisfied they will be.
It should be clear that, as an analyst and as someone responsible for the
successful implementation of an information system, you have more control
over some factors than others. For example, you have considerable influence
over the system’s ease of use and reliability, and you may have some influence
342 Part V Systems Implementation and Operation
over the levels of support that will be provided for users of the system. You have
no direct control over a user’s demographics, relevance of the system, manage-
ment support, or the urgency of the problem to the user. However, you can’t ig-
nore these factors. You need to understand these factors well, because you will
have to balance them with the factors you can change in your system design and
implementation strategy. You may not be able to change a user’s demographics
or personal stake in a system, but you can help design the system and your im-
plementation strategy with these factors in mind.
The factors mentioned so far are straightforward. For example, a lack of com-
puter experience can make a user hesitant, inefficient, and ineffective with a
system, leading to a system’s not achieving its full potential benefit. If top man-
agement does not seem to care about the system, why should subordinates
care? However, additional factors can be categorized as political, and may be
more hidden, difficult to effect, and even unrelated to the system you are im-
plementing, yet instrumental to the system’s success.
The basis for political factors is that individuals who work in an organization
have their own self-interested goals, which they pursue in addition to the goals
of their departments and of their organizations. For example, people may act to
increase their own power relative to that of their coworkers, and at other times,
people will act to prevent coworkers with more power (such as bosses) from us-
ing that power or from gaining more. Because information is power, information
systems are often seen as instruments of one’s ability to influence and exert
power. For example, an information system that provides information about the
inventory and production capabilities of plant A to other plants, may be seen as
undesirable to managers in plant A, even if this information makes the company
operate more efficiently overall. Users in plant A may resist participation in sys-
tems development activities, may continue (if possible) to use old systems and
ignore the new one, or may initiate delaying tactics to stall the installation of the
new system (such as asking for more studies and analysis work to “perfect” the
system). Thus, you must attempt to understand the history and politics around
an information system and deal with negative political factors, as well as the
more objective and operational ones.
Project Closedown
In Chapter 3, you learned about the various phases of project management,
from project initiation to closing down the project. If you are the project man-
ager and have successfully guided your project through all of the phases of the
systems development life cycle presented so far in this book, you are now ready
to close down your project. Although systems operation is just about to begin,
the development project itself is over. As you will see in the following sections,
maintenance can be thought of as a series of smaller development projects,
each with its own series of project management phases.
As you recall from Chapter 3, your first task in closing down the project in-
volves many different activities, from dealing with project personnel to plan-
ning a celebration of the project’s ending. You will likely have to evaluate your
team members, reassign most to other projects, and perhaps terminate others.
As project manager, you will also have to notify all of the affected parties that
the development project is ending and that you are now switching to operation
and maintenance mode.
Your second task is to conduct post-project reviews with both your manage-
ment and your customers. In some organizations, these postproject reviews
follow formal procedures and may involve internal or electronic data process-
ing (EDP) auditors. The point of a project review is to critique the project, its
methods, its deliverables, and its management. You can learn many lessons to
improve future projects from a thorough postproject review.