Information

Systems
Operations and
Maintenance
Rose Andrea Dimaano, CPA, MSAC, MBA,
MICB-UK

1
 TOC

Overview Review of Information System

Understanding the problems
Project objective
Target audience
Market trends
Cycle diagram

SYSTEMS DEVELOPMENT AND MAINTENANCE. The information

needs of users are met by two related functions: systems
development and systems maintenance. The former group is
responsible for analyzing user needs and for designing new systems
to satisfy those needs. The participants in system development
include systems professionals, end users, and stakeholders.

2
Systems professionals include systems analysts, database
designers, and programmers who design and build the system.
Systems professionals gather facts about the user’s problem, analyze
the facts, and formulate a solution. The product of their efforts is a new
information system. End users are those for whom the system is built.
They are the managers who receive reports from the system and the
operations personnel who work directly with the system as part of
their daily responsibilities

2
The managerial obligation to evaluate strategic match and to implement IT
systems begins with the board of directors and must cascade down
into the organization. This means that the board, top executive
management, and lower level managers all must work toward the same
goal of ensuring IT systems and strategy align with the organization’s
strategic goals. To match company strategy to IT systems, the company
should have an IT governance committee and a formal process to select,
design, and implement IT systems. The IT governance committee is a
group of senior managers selected to oversee the strategic management
of IT. The formal process that many organizations use to select, design,
and implement IT systems is the system development life cycle, or SDLC.
Both of these management tools, the IT governance committee and the

2
SDLC, are necessary in the strategic management of IT systems

The IT governance committee should constantly assess the long term

strategy of the company and determine the type of IT systems to
purchase, develop, and use that will help the organization achieve its
objectives. Once the IT governance committee has determined the priority
it places on various IT systems, the SDLC is the process that manages the
development, implementation, and use of those IT systems.

2
· the various parts of the IT system must fit together in a way that
maximizes the overall effectiveness and efficiency of the company
operations.

· there is a limit to the funds that a company can spend to purchase,

develop, and implement IT systems. With limited funds available, the
proper long term and short term management of IT systems becomes very
critical. The organization must strategically manage IT systems to achieve
maximum effectiveness of the systems at a cost that matches the IT
budget.

2
· the lack of systematic, regular steps to strategically manage the IT
systems leads to chaotic and unorganized IT systems. In such an
unorganized environment, the company is less likely to be successful in
competing against other companies and may struggle to survive.

2
The systems development life cycle (SDLC) is a systematic
process to manage the acquisition, design, implementation, and use
of IT systems. The oversight and management of the SDLC is
normally the responsibility of the IT governance committee.

3
The IT governance committee is usually made up of:

• the top managers of the organization, including the chief executive

officer (CEO), the chief financial officer (CFO), the chief information
officer (CIO), top managers from user departments, and top
management from internal audit.

In addition to developing a long term vision and objectives for IT systems,

the IT governance committee oversees the SDLC.

3
In the early days of computers, most organizations had to develop,
program, and implement accounting software in house. It was not feasible
to buy accounting software, nor was it available at a reasonable price.
During that time, the SDLC was a systematic set of regular steps to
accomplish the IT systems selection, design, programming, and
implementation.

3
SYSTEM DEVELOPMENT PARTICIPANTS

4
Systems planning is the evaluation of long term, strategic objectives
and the prioritization of IT systems in order to assist the organization
in achieving its objectives. Systems planning also involves the
planning and continuous oversight of the design, implementation, and
use of those IT systems.

5
Systems analysis is a study of the current system to determine the
strengths and weaknesses and the user needs of that system. Analysis
requires the collection of data about the system and the careful scrutiny of
that data to determine areas of the system that can be improved.

Systems design is the creation of the system that meets user needs and
that incorporates the improvements identified by the systems analysis
phase

5
Systems implementation is the set of steps undertaken to program, test,
and activate the IT system as designed in the system design phase.

Operation and maintenance is the regular, ongoing functioning of the IT

system and the processes to fix smaller problems, or “bugs,” in the IT
system. During operation, management should request and receive
ongoing reports about the performance of the IT system.

5
Notice that the SDLC is a cycle that eventually loops back to systems
planning. This is true because the IT governance committee must
continually evaluate how well the current IT systems match the company’s
strategic objectives. At some point, the IT governance committee will most
likely find it necessary to go back through the phases of the SDLC to
design new and improved IT systems

The major difference now, compared with earlier days of computers, is that
the majority of companies purchase the accounting software they use
rather than designing and programming the software in house. However,
even when accounting software is purchased, it may require extensive

5
modification to make it fit the organization’s needs. Therefore, even when
purchasing accounting software, it is important to use a systematic, regular
set of steps to evaluate, purchase, modify, and implement the software.
The SDLC phases may be slightly different, but still comprise necessary
steps for the proper strategic management of IT systems.

The important factor is that the company has a working budgeting process,
not whether it uses a particular method. Likewise, it is important that the
SDLC have a logical sequence of phases, but those phases may vary
slightly from company to company

5
5
The process map shows the same phases as the SDLC overview in
Exhibit 5 1, but with an expanded set of processes within the system
design phase.

6
These expanded processes are necessary because there is usually more
than one software or system type that meets the needs of the organization.
For example, if a company wishes to modify the payroll processes and
systems in use, there are several ways to approach the modification.

• First, the company could do time keeping in house, but outsource the
actual payroll processing to a payroll processing firm.

• Second, the company could buy or write a stand alone payroll

processing program.

6
• As a third alternative, the company could buy or write an integrated
payroll system as part of a more comprehensive human resource
management software system. To guide this process of designing a new
payroll system, the company should have defined steps that identify
the alternative system approaches, evaluate the fit of each alternative to
the company’s needs, select the best fit, and design or buy that system.

6
 SYSTEM PLANNING

Systems planning is a managerial function of the IT governance

committee.

The IT governance committee must constantly monitor the IT

system through feedback about network utilization, security
breaches, and reports on the operation of the system. This constant

7
• monitoring allows the IT governance committee to determine whether
the current system meets organizational needs. When the committee
determines that a part or parts of the IT system are not meeting
organizational needs, it should begin the process to study and evaluate
the feasibility of modifying or updating those parts of the system. The IT
governance committee will also receive specific requests from those
who use the IT systems to modify or upgrade parts of the system. This
means that at any one time the IT governance committee may be
considering not only modifications or upgrades that they have noted
need attention, but also upgrades or modifications requested by users.
Usually, it is not possible to simultaneously modify or upgrade all of
these areas. The IT governance committee must have procedures to
follow that will assist it in prioritizing the most important needs of the IT

7
modification or upgrade.

To prioritize these projects, the IT governance committee should consider

two broad aspects:

(1) the assessment of IT systems and their match to strategic

organizational objectives, and

(2) the feasibility of each of the requested modifications or upgrades.

7
For example, suppose that a company has decided that a main strategic
objective is to improve customer satisfaction. If the IT governance
committee has received requests to begin modifications of the customer
order entry system and the payroll system, they are likely to place a higher
priority on the customer order entry system, since it will affect the service
and satisfaction of customers. The payroll system modifications may be of
a lower priority because such a change does not match as well with the
strategic objective of improved customer satisfaction.

7
This need to match IT systems to organizational objectives also highlights
the need for the IT governance committee to include as its members top
management such as the CEO, CFO, CIO, and other high level managers.

The committee should do several things to initiate the next phases of

the SDLC:

1. Formally announce the project they have chosen to undertake.

2. Assign the project team that will begin the next phase, the systems
analysis.

7
3. Budget the funds necessary to complete the SDLC.

4. Continue oversight and management of the project team and proposed

IT changes as the remaining SDLC phases occur.

7
WHO IS SYSTEM STEERING COMMITTEE?

8
9
10
11
The objective of systems strategy is to link individual system projects
to the strategic objectives of the firm. Firms that take systems strategy
seriously establish a steering committee to provide guidance and
oversight for systems projects. The composition of the steering
committee may include the chief executive officer (CEO), the chief
financial officer, the chief information officer, senior management from
user areas, the internal auditor, and senior management from

12
computer services. External parties, such as management consultants and
the firm’s external auditors, may also supplement the committee.

12
preliminary project feasibility study is conducted at this early stage to
determine how best to proceed with the project. By assessing the
major constraints on the proposed system, management can evaluate
the project’s feasibility, or likelihood for success, before committing
large amounts of financial and human resources. The acronym
TELOS provides guidance for assessing project feasibility. The term
stands for technical, economic, legal, operational, and schedule

13
feasibility.

For example, the user may need an order entry system that can handle
5,000 transactions per hour, maintain up-to-the-minute inventory status,
and allow all orders received by 2 pm to be shipped to the customer by the
end of the day.

Technical feasibility is concerned with whether the system can be

developed under existing technology or if new technology is needed.

13
Economic feasibility pertains to the availability of funds to complete the
project. At this point, we are concerned with management’s financial
commitment to this project in view of other competing capital projects
under consideration.

Legal feasibility involves ensuring that the proposed system is not in

conflict with the company’s ability to discharge its legal responsibilities

Operational feasibility pertains to the degree of compatibility between the

13
firm’s existing procedures and personnel skills and the operational
requirements of the new system. Implementing the new system may
require adopting new procedures and retraining operations personnel.

Schedule feasibility relates to the firm’s ability to implement the project

within an acceptable time.

13
14
15
16
17
18
 SYSTEM ANALYSIS

Exhibit 5 4 illustrates typical steps within the systems analysis phase

of the SDLC: a preliminary investigation, a survey of the current
system, a determination of user information needs, analysis, and
business process reengineering. At the end of this phase, the project
team will prepare and deliver a systems analysis report.

19
The preliminary investigation occurs within a short period ranging from a
few hours to a few days and should not exceed two to three days. At this
point, the purpose is to make a “go” or “no go” decision.

19
20
 SURVEY OF CURRENT SYSTEM

System Survey: The Study of the Current System

· You have to understand the system

21
For example, it would be difficult for you to improve on the fuel efficiency of
a car if you did not know details about how gas is used in the car, what
quantities of gas the car uses, and which characteristics of the car affect
fuel efficiency

All of these factors and others affect the throughput of an accounting

system. Throughput is a measure of transactions per period.

21
Advantages of Surveying the Current System There are three advantages
to studying the current system. First, it is a way to identify what aspects of
the old system should be kept. Some elements of the system may be
functionally sound and can provide the foundation for the new system. By
fully understanding the current system, the analyst can identify those
aspects worth preserving or modifying for use in the new system. Second,
when the new system is implemented, the users must go through a
conversion process whereby they formally break away from the old system
and move to the new one. The analyst must determine what tasks,
procedures, and data will be phased out with the old system and which will
continue. To specify these conversion procedures, the analyst must know
not only what is to be done by the new system but also what was done by
the old one. This requires a thorough understanding of the current system.

21
Finally, by surveying the current system, the analyst may determine
conclusively the cause of the reported problem symptoms. Perhaps the
root problem is not the information system at all; it may be a management
or employee problem that can be resolved without redesigning the
information system. We may not be able to identify the root cause of the
problem if we discard the existing system without any investigation into the
symptoms.

21
 THE SURVEY STEP

A systems survey requires collecting data about the current system,

including the following:

1. Inputs—sources of data

2. Outputs—the uses of information from processing and

22
outputs such as checks, reports, or forms

3. Processes—the individual steps undertaken to process

transactions, including both manual and computerized processes

4. Controls—the internal controls within the processing

system

5. Data storage—how and where data is stored, and the size

of the data storage

6. Transaction volumes—number of transactions per day or

22
 per hour

7. Errors—number of transaction processing errors

The data collection in a systems survey requires several different methods

of collecting data from different sources. Data collection involves
observation, documentation review, interviews, and questionnaires. A
project team would use each of these methods to collect the necessary
data. The first two methods are described in this section, and the final two
are described in the section that follows. Observation is watching the steps
that employees take as they process transactions in the system. The

22
purpose of the observation is to enable the project team to gain an
understanding of the processing steps within the system. Documentation
review is the detailed examination of documentation that exists about the
system to gain an understanding of the system under study. The project
team would examine any relevant documentation about the system, such
as flowcharts, run manuals, operating manuals, input forms, reports, and
outputs

REVIEWING KEY DOCUMENTS. The organization’s documents are

another source of facts about the system being surveyed. Examples of
these include: Organizational charts Job descriptions Accounting records

22
Charts of accounts Policy statements Descriptions of procedures Financial
statements Performance reports System flowcharts Source documents
Transaction listings Budgets Forecasts Mission statements

Determination of User Requirements

Interviews are the face to face, verbal questioning of users to determine

facts or beliefs about the system. The questions asked can be structured,
unstructured, or some mixture of the two.

22
Questionnaires are also used to solicit feedback from users. However,
questionnaires are a written, rather than an oral, form of questioning users
to determine facts or beliefs about the system.

22
THE ANALYSIS STEP

23
Analysis of the System Survey

In many cases, the analysis phase and the attempt to create

improvements may lead to business process reengineering (BPR).
BPR has been defined as “fundamental rethinking and radical

24
redesign of business processes to bring about dramatic improvements” in
performance. Business processes are the many sets of activities within the
organization performed to accomplish the functions necessary to continue
the daily operations. For example, every organization has a process to
collect and record the revenue earned. In a smaller company, the revenue
collection process may simply be a single person who mails bills, receives
customer checks in the mail, totals the checks, records them in the
accounting records, and deposits the funds. Through rethinking and
redesigning this process, the company may be able to improve the process
and thereby speed up the collection of revenue. This rethinking and
redesign is especially aided by the use of IT. When technology or
computers are introduced, the processes can be radically redesigned to
take advantage of the speed and efficiency of computers to improve

24
processing efficiency. IT and BPR have a mutually enhancing relationship.
BPR will probably begin at this stage of the SDLC, but it may continue
through several phases of the SDLC.

24
 SYSTEM DESIGN

PROCESS MAP FOR PURCHASE SOLUTION

Often, an organization hires a consultant to assist in the selection,

design, and implementation of purchased software. If the organization
intends to hire a consulting firm, such hiring may take place at this

25
point. However, it is important to understand that a consultant could be
hired for any part or parts of the SDLC. The process to solicit proposals is
called a request for proposal, or RFP. A RFP may be sent to each software
vendor offering a software package that meets the system and user needs.
When the vendor returns the RFP, it will include details such as a
description of the software that it intends to sell, the technical support that
it intends to provide, and the related prices. Once all RFPs have been
received, the project team and IT governance committee should evaluate
the proposals in order to select the best software package

In general, purchased software is less costly and more reliable and has a

25
shorter implementation time than software designed in house. Purchased
software has these advantages because it is written by the software
vendor, its cost is spread over several clients, and the coding and testing
are already complete when a customer buys the software.

25
nearly every organization has unique needs or circumstances that
may not match the software exactly. There is often a need to
customize the software or the reports within it. s. In the case of major
modifications to purchased software or in the case of in house design,
the system design phase would include specific steps to design the
outputs, inputs, processes, controls, and data storage of the revised

26
system

26
 CONCEPTUAL DESIGN

Conceptualization phase:

Brainstorming. In the case of purchased software, this step is taken by

sending RFPs to several software vendors. In the case of in house
design, the project team must identify different conceptual design
approaches. For example, there are different types of payment

27
processing available to organizations to receive and pay invoices. The
different approaches range from a traditional system that matches the
purchase order, receiving, and invoice documents and involves relatively
little complex technology to a Web based electronic invoice presentment
and payment (EIPP) system. The EIPP system is a “matchless” system in
which invoices are paid as soon as they are electronically delivered; there
is no matching of documents prior to the approval and payment of the
invoice. While both of these systems accomplish the payment of invoices,
they each rely on technology differently. The EIPP system requires more
complex and advanced technology and fewer manual steps. The traditional
document matching requires simpler technology and involves more manual
tasks. These are examples of different conceptual design approaches. The
project team should identify the different conceptual designs that meet the

27
identified needs.

27
ACCOUNTANT’S ROLE IN CONCEPTUAL DESIGN

28
 SYSTEMS EVALUATION AND SELECTION

When the conceptual designs are identified, the project team must
evaluate the alternatives and choose the best design. Evaluation and
selection is the process of assessing the feasibility and fit of each of
the alternative conceptual approaches and selecting the one that best
fits the organization’s needs.

29
example, the IT governance committee might have been trying to
determine whether revising the order entry system is more important than
revising the invoice payment system. Assume that the IT governance
committee decided that the invoice payment system is the higher priority.
The end result of the system planning phase would be to announce this
decision and to assign resources and a project team to begin the revision
of the invoice payment system. Now we move forward through the other
phases. In the conceptual design phase, the project team identified a
traditional invoice matching system and a Web based invoice payment
system as the alternative conceptual designs. At the point of evaluation
within the design phase, the project team must now evaluate whether the

29
matching or Web based system better meets organizational needs, and
select the optimal system

Operational feasibility. number of employees, their capabilities and

expertise, and any supporting systems necessary to operate each
alternative design.

Economic feasibility. The costs and benefits can be compared by a

formal cost–benefit method such as net present value, internal rate of

29
return, or payback period. The purpose of this analysis is to determine
which of the alternative designs is most cost effective. The costs of the
system designs might include hardware and software costs, training
expenses, and increases in operating and supplies costs.

For each alternative design, the project team must estimate the total
amount of time that will be required to implement the revised system. The
designs that take longer to implement are less feasible.

The task of summarizing and analyzing can become difficult because there
may be conflicting signals across the four feasibilities. For example, a

29
system may have high benefits when costs are compared (economic
feasibility), but it may also require a longer time to implement (schedule
feasibility). The team must then

The task of summarizing and analyzing can become difficult because there
may be conflicting signals across the four feasibilities. For example, a
system may have high benefits when costs are compared (economic
feasibility), but it may also require a longer time to implement (schedule
feasibility). The team must then

29
ACCOUNTANT’S ROLE IN SYSTEM SELECTION

30
 Cloud Computing as a Conceptual Design

1. The customer support provided by the cloud

vendor
2. The service level agreement (SLA) with the cloud
provider.
3. The manner of monitoring cloud service usage.

Design At some point in the SDLC, managers might consider cloud

computing as part of the conceptual model or approach to their IT
system. You may recall from previous chapters that there are several
approaches to cloud computing, including public clouds, private
clouds, Software as a Service (SaaS), Database as a Service (DaaS),
Infrastructure as a Service (IaaS), and Platform as a Service (PaaS).
Regardless of the approach the company considers, the incorporation

31
of cloud computing requires a careful, controlled approach to system
design. This means the team conducting the SDLC must consider the
risks, costs and benefits, and feasibility of the cloud computing approach.
Cloud computing can entail greater security, availability, processing
integrity, and confidentiality risks (as described in chapter 4), and these
must be appropriately weighed against the b enefits of scalability,
expanded access, cost savings, and IT infrastructure changes

1. The customer support provided by the cloud vendor

31
2. The service level agreement (SLA) with the cloud provider.

3. The manner of monitoring cloud service usage. Since cloud

computing is often a pay for service model in which the client pays for the
level of service used, it is important that the client is able to monitor usage
and reconcile billing with the actual service usage. As a simple analogy,
you probably carefully review your cell phone bill to make sure you were
not charged for more services than you used.

*should follow the steps within the SDLC

31
31
Role of Accountants

32
 DETAILED DESIGN

The purpose of the detailed design phase is to create the entire set of specifications necessary
to build and implement the system.

● INPUTS-the forms, documents, screens, or electronic means used to put data into the
accounting system
● PROCESSES-Internal controls are much more effective when they are designed into the
processes from thebeginning.
● OUTPUTS-Income statements, aged accounts receivable listings, inventory status
reports, and sales by product; turnaround documents
● STORAGE- data storage method and size must match the design of the inputs, processes,
and outputs

The purpose of the detailed design phase is to create the entire set of
specifications necessary to build and implement the system. The
various parts of the system that must be designed are the outputs,
inputs, processes, data storage, and internal controls. Each of these
parts must be designed in enough detail that programmers and
analysts can develop the program code necessary to build the
software system. However, the actual writing of program code is not

33
part of the design phase. The coding of software occurs in the
implementation phase

output- For example, checks printed by the accounts payable system and
invoices printed by the billing system are outputs

INPUT-

33
1. Keying in data with a keyboard from data on a paper form. The person
operating the keyboard must enter data from a paper form into an input
screen on the computer.
[Link] ink character recognition (MICR) is used on checks and turn
around documents such as the portion of your credit card bill that you
return. The computer system reads the magnetic ink to determine
information such as account number.
[Link] data interchange (EDI), in which standard business
documents are transmitted electronically.
[Link] commerce, in which the customer enters customer and order
data. 5. Bar code scanning, such as in the point of sale systems used by
grocery and department stores.

33
PROCESSES- For example, processing payroll checks requires many
steps, including timekeeping, calculation of gross pay and deductions,
approvals for the payroll, and printing and distribution of checks. ll of the
individual steps within a process must be designed. The project team
again should have user input in designing these processes. Without user
input, the processes may be designed in a way that makes it difficult or
undesirable for users to use the system. Any such difficulties or reluctance
by users to use the system can lead to efficiency problems or errors in the
process. The internal controls within the system must be designed during
the detailed design phase To understand why this is true, let’s think about
the global positioning systems (GPSs) that are now built into some cars.

33
When those cars were designed, the electronics, dashboard space, and
dashboard controls had to be designed simultaneously. If you buy a car
without the GPS and decide to add it later, your add on system is likely to
be less effective than a built in GPS. Likewise, internal controls that are
initially designed into the system are more effective.

The project team must design the method, size, and format of the data
storage. For example, if data is to be stored in a relational database, the
team must design all the elements, including the tables, the rows and
columns within the tables, and the relationships between the tables

33
When the project team has completed the detailed design of outputs,
inputs, processes, internal controls, and data storage, the implementation
phase can begin.

33
Data conversion

34
 Detailed Feasibility Study

One method of identifying costs is to divide them into two categories:

one-time costs and recurring costs. One-time costs include the initial
investment to develop and implement the system. Recurring costs
include operating and maintenance costs that recur over the life of the
system. Table 13-2 shows a breakdown of typical one-time and
recurring costs.

35
RECURRING COSTS
• HARDWARE MAINTENANCE.
This involves the cost of upgrading the computer (for example,
increasing the memory), as well as preventive maintenance and repairs
to the computer and peripheral equipment. The organization may enter into
a maintenance contract with the vendor to minimize and budget these
costs. Estimates for these costs can be obtained from vendors and existing
contracts.

• SOFTWARE MAINTENANCE.
These costs include upgrading and debugging operating systems,
purchased applications, and in-house developed applications.
Maintenance contracts with software vendors can be used to specify these

35
costs fairly accurately. Estimates of in-house maintenance can be derived
from historical data.

• INSURANCE.
This covers such hazards and disasters as fire, hardware failure,
vandalism, and destruction by disgruntled employees

• SUPPLIES.
These costs are incurred through routine consumption of such items
as printer cartridges and paper, magnetic disks, magnetic tapes, and
general office supplies.

• PERSONNEL.

35
These are the salaries of individuals who are part of the information
system. Some employee costs are direct and easily identifiable, such as
the salaries of operations personnel exclusively employed as part of the
system under analysis. Some personnel involvement, for example, the
database administrator and computer room personnel, is common to many
systems. Such personnel costs must be allocated on the basis of expected
incremental involvement with the system.

ONE-TIME COSTS
• HARDWARE ACQUISITION.
This includes the cost of mainframe servers, PCs, and peripheral
equipment, such as networks and disk packs. The cost figures for items
can be obtained from the vendor.

35
• SITE PREPARATION.
This involves such frequently overlooked costs as building
modifications, for example, adding air-conditioning or making structural
changes; equipment installation, which may include the use of heavy
equipment; and freight charges. Estimates of these costs can be obtained
from the vendor and the subcontractors who do the installation.

• SOFTWARE ACQUISITION.
These costs apply to all software purchased for the proposed system,
including operating system software, if not bundled with the hardware;
network control software; and commercial applications, such as accounting
packages. Estimates of these costs can be obtained from vendors.
• SYSTEMS DESIGN.

35
These are the costs that systems professionals incur performing the
planning, analysis, and design functions. Technically, such costs
incurred up to this point are sunk and irrelevant to the decision. The
analyst should estimate only the costs needed to complete the detailed
design
• PROGRAMMING AND TESTING.
Programming costs are based on estimates of the personnel hours
required to write new programs and modify existing programs for the
proposed system. System testing costs involve bringing together all the
individual program modules for testing as an entire system. This must be a
rigorous exercise if it is to be meaningful. The planning, testing, and
analysis of the results may demand many days of involvement from

35
systems professionals, users, and other stakeholders of the system. The
experience of the firm in the past is the best basis for estimating these
costs.

• DATA CONVERSION.
These costs arise in the transfer of data from one storage medium or
structure to another. For example, the accounting records of a manual
system must be converted to digital form when the system becomes
computer-based. This can represent a significant task. The basis for
estimating conversion costs is the number and size of the files to be
converted.

• TRAINING.

35
These costs involve educating users to operate the new system. This
could be done in an extensive training program that an outside
organization provides at a remote site or through on-the-job training by in-
house personnel. The cost of formal training can be easily obtained. The
cost of an in-house training program includes instruction time, classroom
facilities, and lost productivity.

35
All the choices

36
 CB ANALYSIS TANGIBLE BENEFITS

This phase in the SDLC is a formal mechanism for selecting the

one system from the set of alternative conceptual designs that
will go forward for construction. The systems evaluation and
selection phase is an optimization process that seeks to identify the
best system. This decision represents a critical juncture in the SDLC.
At this point, there is a great deal of uncertainty about the system, and
a poor decision can be disastrous. The purpose of a formal evaluation

37
and selection procedure is to structure this decision making process and
thereby reduce both uncertainty and the risk of making a poor decision.
PERFORM COST-BENEFIT ANALYSIS
Cost-benefit analysis helps management determine whether (and by
how much) the benefits received from a proposed system will
outweigh its costs. This technique is frequently used for estimating the
expected financial value of business investments. In this case, however,
the investment is an information system, and the costs and benefits are
more difficult to identify and quantify than those of other types of capital
projects. Although imperfect in this setting, cost-benefit analysis is
employed because of its simplicity and the absence of a clearly better
alternative. In spite of its limitations, cost-benefit analysis, combined with

37
feasibility factors, is a useful tool for comparing competing systems
designs. There are three steps in the application of cost-benefit analysis:
identifying costs, identifying benefits, and comparing costs and benefits.

TANGIBLE BENEFITS.
Tangible benefits are benefits that can be measured and expressed in
financial terms. Table 13-3 lists several types of tangible benefits.
Tangible benefits fall into two categories: those that increase revenue and
those that reduce costs. For example, assume a proposed EDI system will
allow the organization to reduce inventories and at the same time improve
customer service by reducing stock-outs. The reduction of inventories is a
cost reducing benefit. The proposed system will use fewer resources
(inventories) than the current system. The value of this benefit is the dollar

37
amount of the carrying costs that the annual reduction in inventory saves.
The estimated increase in sales because of better customer service is a
revenue-increasing benefit. When measuring cost savings, only escapable
costs should be included in the analysis. Escapable costs are directly
related to the system and cease to exist when the system ceases to exist.
Some costs that appear to be escapable to the user are not truly
escapable and, if included, can lead to a flawed analysis. For example,
data processing centers often charge back their operating costs to their
user constituency through cost allocations. The charge-back rate they use
for this includes both fixed costs (allocated to users) and direct costs that
the activities of individual users create. Figure 13-7 illustrates this
technique. Assume the management in User Area B proposes to acquire a
computer system and perform its own data processing locally. One benefit

37
of the proposal is the cost savings derived by escaping the charge-back
from the current data processing center. Although the user may see this as
a $400,000 annual charge, the organization as a whole can only escape
the direct cost portion ($50,000). Should the proposal be approved, the
remaining $350,000 of the charge-back does not go away. The remaining
users of the current system must now absorb this cost.

37
 CB ANALYSIS INTANGIBLE BENEFITS

INTANGIBLE BENEFITS. Table 13-4 lists some common categories of

intangible benefits. Although intangible benefits are often of overriding
importance in information system decisions, they cannot be easily
measured and quantified. For example, assume that a proposed point-
of-sale system for a department store will reduce the average time to
process a customer sales transaction from 11 minutes to 3 minutes.
The time saved can be quantified and produces a tangible benefit in

38
the form of an operating cost savings.
An intangible benefit is improved customer satisfaction; no one likes to
stand in long lines to pay for purchases. But what is the true value of this
intangible benefit to the organization? Increased customer satisfaction may
translate into increased sales. More customers will buy at the store—and
may be willing to pay slightly more to avoid long checkout lines. But how
do we quantify this translation? Assigning a value is often highly subjective.
Systems professionals draw upon many sources in attempting to quantify
intangible benefits and manipulate them into financial terms. Some
common techniques include customer (and employee) opinion surveys,
statistical analysis, expected value techniques, and simulation models.
Even though systems professionals may succeed in quantifying some of
these intangible benefits, more often they must be content to simply state

38
the benefits as precisely as good judgment permits. Because they defy
precise measurement, intangible benefits are sometimes exploited for
political reasons. By overstating or understating these benefits, a system’s
proponents may push it forward or its opponents may kill it

38
COMPARING COSTS AND BENEFITS

39
ANNOUNCING THE NEW SYSTEM PROJECT

40
41
42
OutSourcing

Outsourcing – two kinds

Business Process Outsourcing (BPO)
range from routine assistance with asingle application
Ø

to almost all the accounting functions of the organization.

Ø

Knowledge Process Outsourcing (KPO) - three areas

intellectual property
Ø

data mining of consumer data,

Ø

and research and development related to medical drugs

Ø

and biotechnology

43
OutSourcing/Consulting Decision

Advantages and Disadvantages of Outsourcing.

● Focus on core competencies
● Potential Savings
● outsourcing also frees managerial time, financial assets, and
related resources for other purposes
● disadvantage is inflexibility.
● loss of control
● loss of competitive advantage

44
 SYSTEM
IMPLEMENTATION
AND OPERATION
PROCESS MAP

There are so many different tasks within the implementation and

operation phase that it would be impossible to describe all of them in
this chapter. Instead, a few of the critical steps are described. The
employee training, program testing, and documentation can all be
undertaken at the same time. For example, the documentation does
not need to begin after employee training.

45
45
 ● Software Programming
● Training Employees
● Software Testing
● Document The System
● Data Conversion
● System Conversion
● User Acceptance
● Post Implementation Review

Software Programming Using the design specifications developed in

the detailed design phase, the programming staff would write the
program code for the new or revised system. In the case of purchased
software, the programming staff would modify the program code as
necessary to meet the design specifications. While accountants may
not be directly involved in programming, they would have frequent
interaction with the programming staff to ensure that the programming

46
meets the identified accounting requirements.

Training Employees As the programming is completed or nearing

completion, employees should be trained to use the new system.
Depending on the extent of changes from the old system, employees may
need training in the use of new input screens, output reports, and
processes.

Software Testing As programmers complete the programming of the new

system, the programs and the modules that make up the programs must
be tested. Software should never be implemented before it is tested;
otherwise, it can cause errors or problems in the accounting system and

46
thereby result in erroneous accounting data. The most common way to test
software is to use test data, which is specially created and entered into the
software to ensure that the software works correctly.

Documenting the System Since inputs, outputs, and processes are very
likely to change as systems are revised, it is important to write the
documentation that matches the new inputs, outputs, and processes.
There are many kinds of documentation necessary to operate and
maintain an accounting system, including flowcharts, data flow diagrams,
entity relationship diagrams, process maps, operator manuals, and data
dictionaries. Unfortunately, many companies do not always rewrite
documentation at this stage, even though they should. The lack of
up to date documentation makes it much more difficult for new employees

46
to understand the system and makes future revisions to the system more
complicated.

Data Conversion Though it is not always necessary, the implementation

of a new or revised system may require that the data be converted to a
new format. The file or database storage for the new system may be
different from the storage format of the old system. In most instances, a
conversion program can be written or acquired that will convert the data
from the old to the new format. Accountants should oversee the data
conversion process to make sure that all accounting data is completely
and correctly converted. To check the accuracy of the conversion,
accountants can reconcile control totals from the old data set to control
totals from the converted data. These control totals should match for all

46
converted data.

The system conversion is the actual changeover from the old to the new
system. Often, this is called the “go live” date. The go live date is the day
that the new system becomes fully in operation. There are several different
conversion methods to choose from: parallel conversion, direct cutover
conversion, phase in conversion, and pilot conversion. We will elaborate
more on that .

User acceptance means that when the manager of the primary users of
the system is satisfied with the system, he will sign an acceptance
agreement. The enforcement of user acceptance makes it much more
likely that project teams will seek user input and that the project team will

46
work hard to meet user needs.

A few months after implementation, the project team should review the
SDLC steps for the project that was implemented. This
post implementation review is a review of the feasibility assessments
and other estimates made during the process. The purpose of the review is
to help the organization learn from any mistakes that were made. The
review does not correct any errors made, but it helps the company avoid
those same errors in the future.

46
46
47
48
 The Modular Approach to Programming

PROGRAMMING EFFICIENCY. Modules can be coded and tested

independently, which vastly reduces programming time. A firm can
assign several programmers to a single system. Working in parallel,
the programmers each design a few modules. These are then
assembled into the completed system.

MAINTENANCE EFFICIENCY. Small modules are easier to analyze

49
and change, which reduces the start-up time during program maintenance.
Extensive changes can be parceled out to several programmers
simultaneously to shorten maintenance time.

CONTROL. By keeping modules small, they are less likely to contain

material errors of fraudulent logic. Because each module is independent of
the others, errors are contained within the module.

49
 Deliver the System: Testing

The implementation process engages the efforts of designers,

programmers, database administrators, users, and accountants. , not
all steps are part of every system’s implementation, and not all are of
direct concern to accountants. For example, the implementation
activities of ordering equipment from vendors, preparing the site,
installing equipment, and training employees are not performed with
each new system. Moreover, these are technical tasks that do not

50
usually involve the accounting function. When all modules have been
coded and tested, they must be brought together and tested as a whole.
User personnel should direct systemwide testing as a prelude to the formal
system cutover. The procedure involves using the system to process
hypothetical data.
Saving Test Data
The preparation of test data is a tedious, time-consuming activity. The
auditor should save these data during system reviews for future use. By
preserving the test data, we create what is called a base case, which
documents how the system performed at a point in time. At any future
point, the base case data should generate the same results. System
changes (maintenance) that have occurred since system implementation

50
will explain the differences between base case results and current test
results.

50
 The Test Data Approach

Programmers should test completed modules independently before

implementing them. This usually involves the creation of test data.
Depending on the nature of the application, this could include test
transaction files, test master files, or both.
Assume the module under test is the Update AP Records program
(Module H) represented in Figure 14-17. The approach taken is to test

51
the application thoroughly within its range of functions. To do this, the
programmer must create some test accounts payable master file records
and test transactions. The transactions should contain a range of data
values adequate to test the logic of the application, including both good
and bad data. For example, the programmer may create a transaction with
an incorrect account number to see how the application handles such
errors. The programmer will then compare the amounts posted to accounts
payable records to see if they tally with precalculated results.

51
The system’s documentation describes how the system works. Users
need documentation describing how to use the system. User tasks
include such things as entering input for transactions, making inquiries
of account balances, updating accounts, and generating output
reports. The nature of user documentation will depend on the user’s
degree of sophistication with computers and technology

52
52
 User Documentation

Users need documentation describing how to use the system. User tasks include such things as
entering input for transactions, making inquiries of account balances, updating accounts,
and generating output reports. Thus, before designing user documentation, the systems
professional must assess and classify the user’s skill level. The following is one classification
scheme. Which one are you?

● Novices
● Occasional Users
● Frequent light users
● Frequent PowerUsers

Novices have little or no experience with computers and may be

embarrassed to ask questions. Novices also know little about their
assigned tasks. User training and documentation for novices must be
extensive and detailed.

Occasional users once understood the system but have forgotten

some essential commands and procedures. They require less training

53
and documentation than novices.

Frequent light users are familiar with limited aspects of the system.
Although functional, they tend not to explore beneath the surface and lack
depth of knowledge. This group knows only what it needs to know and
requires training and documentation for unfamiliar areas.

Frequent power users understand the existing system and will readily
adapt to new systems. They are intolerant of detailed instructions that
waste their time. They like to find shortcuts and use macro commands to
improve performance. This group requires only abbreviated
documentation.

53
 User Documentation and trainings
HANDBOOK• An overview of the system and its major functions • Instructions for getting
started • Descriptions of procedures with step-by-step visual references • Examples of input
screens and instructions for entering data • A complete list of error message codes and
descriptions • A reference manual of commands to run the system • A glossary of key terms •
Service and supportinformation

Online documentation will guide the user interactively in the use of the system.
Some commonly found online features include tutorials and help features.

TUTORIALS. Online tutorials can be used to train the novice or the occasional user. The success
of this technique is based on the tutorial’s degree of realism. Tutorials should not restrict the
user from access to legitimate functions.

HELP FEATURES When the user makes an error, the system will send the message, ‘‘Do you
need help?’’ The help feature analyzes the context of what the user is doing at the time of the
error and provides help with that specific function (or command)

User Handbook. With these classes in mind, user documentation often

takes the form of a user handbook, as well as online documentation.

HELP FEATURES. Online help features range from simple to

sophisticated. A simple help feature may be nothing more than an
error message displayed on the screen. The user must walk through

54
the screens in search of the solution to the problem. More sophisticated
help is context related. When the user makes an error, the system will send
the message, ‘‘Do you need help?’’ The help feature analyzes the context of
what the user is doing at the time of the error and provides help with that
specific function (or command)

54
 Designer and Programmer Documentation.

documentation provides the auditor with essential information about

how the system works.
Systems designers and programmers need documentation to debug
errors and perform maintenance on the system. This group is involved
with the system on a highly technical level, which requires both
general and detailed information. Some of this is provided through

55
DFDs, ER diagrams, and structure diagrams. In addition, system
flowcharts, program flowcharts, and listings of program code are important
forms of documentation. The system flowchart shows the relationship of
input files, programs, and output files. However, it does not reveal the logic
of individual programs that constitute the system. The program flowchart
provides a detailed description of the sequential and logical operation of
the program. A separate program flowchart represents each program in the
system’s flowchart. From these, the programmer can visually review and
evaluate the program’s logic. The program code should itself be
documented with comments that describe each major program segment.

Computer operators use documentation describing how to run the system

called a run manual.

55
•The name of the system, such as Purchases System. The run schedule
(daily, weekly, time of day, and so on).
•Required hardware devices (tapes, disks, printers, or special hardware).
File requirements specifying all the transaction (input) files, master files,
and output files used in the system.
•Run-time instructions describing the error messages that may appear,
actions to be taken, and the name and telephone number of the
programmer on call, should the system fail.
•A list of users who receive the output from the run
For security and control reasons, system flowcharts, logic
flowcharts, and program code listings are not part of the operator
documentation. Operators should not have access to the details of a

55
system’s internal logic.

55
For example, the move from a manual system to a computer system
will require converting files from paper to magnetic disk or tape. In
other situations, writing special conversion programs may accomplish
data transfer. A case in point is changing the file structure of the
databases from sequential direct access files. In any case, data
conversion is risky and must be carefully controlled.

56
1. Validation. The old database must be validated before conversion.
This requires analyzing each class of data to determine whether it should
be reproduced in the new database

2. Reconciliation. After the conversion action, the new database must be

reconciled against the original. Sometimes this must be done manually,
record by record and field by field. In many instances, writing a program
that will compare the two sets of data can automate this process

3. Backup. Copies of the original files must be kept as backup against

discrepancies in the converted data. If the current files are already in
magnetic form, they can be conveniently backed up and stored. However,
paper documents can create storage problems. When the user feels

56
confident about the accuracy and completeness of the new databases, the
paper documents may be destroyed.

56
 CONVERTING TO THE NEW SYSTEM
The process of converting from the old system to the new one is called the cutover

● Cold Turkey Cutover (Big bang Approach)

● Phased Cutover
● Parallel OperationCutover

cold turkey cutover approach (also called the big bang approach), the
firm switches to the new system and simultaneously terminates the old
system. When implementing simple systems, this is often the easiest
and least costly approach. With more complex systems, it is the
riskiest. Cold turkey cutover is akin to skydiving without a reserve
parachute. As long as the main parachute functions properly, there is
no problem. But things don’t always work the way they are supposed

57
to. System errors that were not detected during the walk-through and
testing steps may materialize unexpectedly. Without a backup system, an
organization can find itself in serious trouble.

Sometimes an entire system cannot, or need not, be cut over at once. The
phased cutover begins operating the new system in modules.
•starting with the sales subsystem, followed by the inventory control
subsystem, and finally the purchases subsystem.
•we reduce the risk of a devastating system failure. However, the phased
approach can create incompatibilities between new subsystems and yet-
to-be-replaced old subsystems. Implementing special conversion systems
that provide temporary interfaces during the cutover period may alleviate
this problem

57
Parallel operation cutover involves running the old system and the new
system simultaneously for a period of time. Figure 14-21 illustrates this
approach, which is the most time-consuming and costly of the three.
Running two systems in parallel essentially doubles resource consumption.
During the cutover period, the two systems require twice the source
documents, twice the processing time, twice the databases, and twice the
output production. The advantage of parallel cutover is the reduction in
risk. By running two systems, the user can reconcile outputs to identify and
debug errors before running the new system solo. Parallel operation
should usually extend for one business cycle, such as 1 month. This allows
the user to reconcile the two outputs at the end of the cycle as a final test
of the system’s functionality

57
57
Answer B

58
Program evaluation and Review Technique
•Helps identify critical paths
•Recognize areas where slack time occurs
-network diagram
-duration is shown in parentheses
-successor and predecessor activities are identified

59
59
60
The final step in the implementation phase actually takes place some
months later in a postimplementation review. The objective is to
measure the success of the system and of the process after the dust
has settled. Although systems professionals strive to produce systems
that are on budget, on time, and meet user needs, this does not
always happen. The postimplementation review of the newly installed
system can provide insight into ways to improve the process for future

61
systems. The areas discussed in the following section are of particular
concern

Uncertainty complicates the task of estimating time, costs, and benefits for
a proposed system. This is particularly true for large projects involving
many activities and long time frames. The more variables in the process,
the greater the likelihood for material error in the estimates. History is often
the best teacher for decisions of this sort. Therefore, a review of actual
performance compared to budgeted amounts provides critical input for
future budgeting decisions. From such information, we can learn where
mistakes were made and how to avoid them the next time.

61
Answer C

62
Provide Technical Expertise
The detailed design phase involves precise specifications of
procedures, rules, and conventions to be used in the system. In the
case of an AIS, these specifications must comply with GAAP, GAAS,
SEC regulations, and IRS codes. Failure to so comply can lead to
legal exposure for the firm. For example, choosing the correct
depreciation method or asset valuation technique requires a technical

63
background that systems professional don’t necessarily possess. The
accountant must provide this expertise to the systems design process.

Specify Documentation Standards In the implementation phase, the

accountant plays a role in specifying system documentation. Because
financial systems must periodically be audited, they must be adequately
documented. The accountant must actively encourage adherence to
effective documentation standards.

Verify Control Adequacy The applications that emerge from the SDLC
must possess controls that are in accordance with the provisions of
Statement on Auditing Standards No. 78. This requires the accountant’s
involvement at both the detailed design and implementation phases.
Controls may be programmed or manual procedures. Some controls are

63
part of the daily operation of the system, while others are special actions
that precede, follow, or oversee routine processing. The extent of control
techniques makes it impossible to treat them within this chapter. Instead,
we have devoted the next two chapters to the study of control concepts
and design.

63
64
65
66
67