ELEMENTS OF THE SYSTEMS IMPLEMENTATION PHASE OF THE SDLC (STUDY OBJECTIVE 6)

There are many individual tasks that must be undertaken to implement a new or revised accounting system. This is true regardless of whether the software is purchased or designed in-house. Implementation time would be much shorter for purchased software, since the software has already been written and tested by the vendor. However, even purchased software is often modified, and those modifications should be coded and tested in the implementation phase. Exhibit 6-7 is a process map of the systems implementation and operation phase.

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.

As depicted in Exhibit 6-7, some tasks can occur simultaneously. 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.

Exhibit 6-7 Implementation and Operation Process Map

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 meets the identified accounting requirements.

TRAINING EMPLOYEES

As the programming is completed or near completion, employees should be trained to use the new system. Depending on the 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 thereby result in erroneous accounting data. The most common way to test software is to use test data, which are specially created and entered into the software to ensure that the software works correctly. The test data approach is described in Chapter 7.

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 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 are 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 converted data.

SYSTEM CONVERSION

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. Each of these methods has advantages and disadvantages, and the company should choose the method that best fits its situation.

Parallel conversion is a conversion method in which the old and new systems are operated simultaneously for a short time. For example, the company may run the old and new versions of a system in parallel for a one-month period. The advantage to the parallel conversion is that it is the least risky. If errors or problems become apparent in the new system, the company can continue to use the old system until the problems are resolved. However, the disadvantage is that parallel conversion is the most costly and time-consuming conversion method, since it requires that the operating staff operate two systems and input all data twice—once in each system.

Direct cutover conversion means that on a chosen date the old system operation is terminated and all processing begins on the new system. This method is in many ways the opposite of parallel conversion. Direct cutover is the most risky method, but the least costly and time consuming. Since systems are not run in parallel, there is no backup in the form of the old system if problems occur.

The phase-in conversion is a method in which the system is broken into modules, or parts, which are phased in incrementally and over a longer period. As an example, assume that a company is implementing an entirely new accounting system, using a phase-in approach. The company might first implement only the order-entry part of the system. If that is successful, it may then choose to phase in the accounts receivable module. When that is working well, it may then phase in the cash receipts module. The phase-in approach is a low-risk approach, as it does not disrupt large parts of the organization at the same time. However, it will take longer to phase in all the parts of the accounting system.

In a pilot conversion, the system is operated in only one or a few subunits of the organization. For example, suppose that a bank intends to implement new loan processing software at its branch offices. The bank may choose a few of its locations as pilot test sites for the software. The bank would implement the new software at the selected pilot sites and work out any problems in the system at those sites. Once the bank is satisfied with the operation at the pilot sites, the system can be implemented at the remaining sites.

USER ACCEPTANCE

To ensure that user needs have been met, many organizations require a user acceptance at the end of the implementation of a new system. 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 work hard to meet user needs.

POST-IMPLEMENTATION REVIEW

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.