Construct, Deliver and Maintain Systems Project:Deliver the System

Deliver the System

The system is now ready to be implemented. In this phase, database structures are populated with data, equipment is purchased and installed, employees are trained, and the system is documented. This phase concludes with the roll-out of the new system and the termination of the old system.

The implementation process engages the efforts of designers, programmers, database administrators, users, and accountants. All the steps in this stage warrant careful management. Nevertheless, 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 usually involve the accounting function. This section focuses on those activities that have the greatest direct implications for accountants and auditors.

TESTING THE ENTIRE SYSTEM

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. The outputs of the system are then reconciled with predetermined results, and the test is documented to provide evidence of the system’s performance. Finally, when those conducting the tests are satisfied with the results, a formal acceptance document should be completed. This is an explicit acknowledgment by the user that the system in question meets stated requirements. The user acceptance document becomes important in reconciling differences and assigning responsibility during the post-implementation review of the system.

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 will explain the differences between base case results and current test results. Hence, the base case provides a reference point for analyzing the effects of system changes and eases the burden of creating test data.

DOCUMENTING THE SYSTEM

The system’s documentation describes how the system works. In this section, we consider the documentation requirements of four groups: systems designers and programmers, computer operators, end users, and accountants.

Designer and Programmer Documentation

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 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 sepa- rate 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.

Operator Documentation

Computer operators use documentation describing how to run the system called a run manual. The typical contents of a run manual include:

• 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 system’s internal logic. We will discuss this point more fully in Chapter 15.

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. The nature of user documentation will depend on the user’s degree of sophistication with computers and technology. Thus, before designing user documentation, the systems professional must assess and classify the user’s skill level. The following is one classification scheme:

• Novices

• Occasional users

• Frequent light users

• Frequent power users

Novices have little or no experience with computers and may be embarrassed to ask questions. Nov- ices 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 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.

With these classes in mind, user documentation often takes the form of a user handbook, as well as online documentation. The typical user handbook will contain the following items:

• 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 support information

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. 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 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).

Accountant (Auditor) Documentation

With responsibility for the design of certain security procedures, accounting controls, and audit trails, accountants are stakeholders in all AIS applications. For these tasks, accountants may draw upon all of the documentation described previously. As internal and external auditors, accountants also require document flowcharts of manual procedures. We have encountered numerous examples of document flow- charts in the chapters dealing with the revenue, expenditure, and conversion cycles. Document flowcharts differ from DFDs in an important way. DFDs describe the overall logic of the system. Document flow- charts show explicitly the flow of information between departments, the departments in which tasks are actually performed, and the specific types and number of documents that carry information. A physical view such as this is needed to understand the segregation of duties, the adequacy of source documents, and the location of files that support the audit trail. Document flowcharts are not always included as part of the system’s documentation. When not provided, auditors must create their own during the audit process.

CONVERTING THE DATABASES

Database conversion is a critical step in the implementation phase. This is the transfer of data from its current form to the format or medium the new system requires. The degree of conversion depends on the technology leap from the old system to the new one. Some conversion activities are very labor-intensive, requiring data to be entered into new databases manually. 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. The following precautions should be taken:

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 confident about the accuracy and completeness of the new databases, the paper documents may be destroyed.

CONVERTING TO THE NEW SYSTEM

The process of converting from the old system to the new one is called the cutover. A system cutover will usually follow one of three approaches: cold turkey, phased, or parallel operation.

Cold Turkey Cutover

Under the 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 to. System errors that were not detected during the walk-through and testing steps may materialize unexpectedly. Without a backup sys- tem, an organization can find itself in serious trouble.

Phased Cutover

Sometimes an entire system cannot, or need not, be cut over at once. The phased cutover begins operating the new system in modules. For example, Figure 14-20 shows how we might implement a system, starting with the sales subsystem, followed by the inventory control subsystem, and finally the purchases subsystem.

By phasing in the new system in modules, we reduce the risk of a devastating system failure. How- ever, 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.

Parallel Operation Cutover

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.

POSTIMPLEMENTATION REVIEW

The final step in the implementation phase actually takes place some months later in a postimplementa- tion review. The objective is to measure the success of the system and of the process after the dust has set- tled. 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 systems. The areas discussed in the following section are of particular concern.

System Design Adequacy

The physical features of the system should be reviewed to see if they meet user needs. The reviewer should seek answers to the following types of questions:

1. Does the output from the system possess such characteristics of information as relevance, timeliness, completeness, accuracy, and so on?

2. Is the output in the format most useful and desired by the user (such as tables, graphs, electronic, hard copy, and so on)?

3. Are the databases accurate, complete, and accessible?

4. Did the conversion process lose, corrupt, or duplicate data?

5. Are input forms and screens properly designed and meeting users’ needs?

6. Are the users using the system properly?

7. Does the processing appear to be correct?

8. Can all program modules be accessed and executed properly, or does the user ever get stuck in a loop?

9. Is user documentation accurate, complete, and easy to follow?

10. Does the system provide the user adequate help and tutorials?

Accuracy of Time, Cost, and Benefit Estimates

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 pro- vides critical input for future budgeting decisions. From such information, we can learn where mistakes were made and how to avoid them the next time. The following questions provide some insight:

1. Were PERT and Gantt chart estimates accurate to within 10 percent?

2. What were the areas of significant departures from budget?

3. Were departures from the budget controllable (internal) in the short run or noncontrollable (for exam- ple, supplier problems)?

4. Were estimates of the number of lines of program code accurate?

5. Was the degree of rework due to design and coding errors acceptable?

6. Were actual costs in line with budgeted costs?

7. Are users receiving the expected benefits from the system?

8. Do the benefits seem to have been fairly valued?

THE ROLE OF ACCOUNTANTS

The role of accountants in the construct and deliver phases of the SDLC should be significant. Most sys- tem failures are due to poor designs and improper implementation. Being a major stakeholder in all financial systems, accountants must apply their expertise in this process to guide and shape the finished system. Specifically, accountants should get involved in the following ways.

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 regula- tions, 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 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 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.