SYSTEMS ANALYSIS & DESIGN PHASE 4 SYSTEMS IMPLEMENTATION Installation and Evaluation

Chapter 11 Installation and Evaluation

Objectives Discuss the main tasks in the installation and evaluation process Explain why it is important to maintain separate operational and test environments Develop an overall training plan with specific objectives for each group of participants Explain three typical ways to provide training, including vendors, outside resources, and in-house staff

Objectives Describe online tutorials and other user training techniques Create an outline for a training manual and describe the contents of each section Describe the file conversion process Identify four system changeover methods and discuss the advantages and disadvantages of each

Objectives Explain the purpose of a post- implementation evaluation and list the specific topics covered during the evaluation Specify the contents of the final report to management

Introduction Installation and evaluation completes the systems implementation phase The new system is now ready to be used Remaining tasks Prepare an operational environment and install the new system Provide training for users, IS staff, and managers Perform file conversion and system changeover Carry out post-implementation evaluation Present a final report to management

Operational and Test Environments Programmers and analysts use the test environment to develop and maintain programs The test environment contains copies of Programs Procedures Test data files Click to see Figure 11-1 Click to see Figure 11-2

Operational and Test Environments Operational environment Also called the production environment Access is limited to information system users IS staff enter the production environment only to correct problems or perform authorized work Live, actual data is used All changes must be verified and user approval obtained

Operational and Test Environments Preparation of the operational environment Examine all system components that affect system performance Hardware and software configurations Operating system programs and utilities Network resources Check all communications features, both before and after loading programs Include network specifications in documentation

Training A training plan should be considered early in the systems development process Specific training is necessary for Users Managers IS department staff members Click to see Figure 11-3 Click to see Figure 11-4

Training Vendor training If hardware or software is purchased outside, vendor training should be considered Many vendors offer free or nominal cost training for customers Vendor training can be performed at the vendor’s site or at the customer’s location Vendor training often provides the best return on training dollars Click to see Figure 11-5

Training Outside training resources If vendor training or internal training is impractical, outside trainers or consultants can be used Outside training generally is not practical for in-house developed systems Many sources of training information exist Consultants Universities Information management organizations Industry associations Click to see Figure 11-6a Click to see Figure 11-6b

Training In-house training IS staff and user departments usually share responsibility for developing and conducting training for in-house systems Training techniques can include many techniques and training aids, including multimedia, demonstrations, videotapes, and charts

Training In-house training Some guidelines to consider Train people in groups, with separate programs for distinct groups Select the most effective place for training Provide for learning by hearing, seeing, and doing Prepare a training manual Click to see Figure 11-7

Training Some guidelines to consider Train people in groups, with separate programs for distinct groups Select the most effective place for training Provide for learning by hearing, seeing, and doing Prepare a training manual Develop interactive tutorials and training tools Rely on previous trainees When training is complete, conduct a full-scale simulation for users to gain experience and confidence Click to see Figure 11-8a Click to see Figure 11-8b

Training Some guidelines to consider Train people in groups, with separate programs for distinct groups Select the most effective place for training Provide for learning by hearing, seeing, and doing Prepare a training manual Develop interactive tutorials and training tools Rely on previous trainees When training is complete, conduct a full-scale simulation for users to gain experience and confidence Click to see Figure 11-9a Click to see Figure 11-9b

File Conversion File conversion can take place after the operational environment is established and training has been performed Issues to consider Automated conversion techniques Methods of exporting data to the new system Programs designed to extract and convert data Controls required to protect vulnerable data Verification of results by users

System Changeover System changeover puts the new system online and retires the old system Four typical approaches exist Direct cutover Parallel operation Pilot operation Phased changeover Each approach involves different cost and risk factors Click to see Figure 11-10

System Changeover System changeover puts the new system online and retires the old system Four typical approaches exist Direct cutover Parallel operation Pilot operation Phased changeover Each approach involves different cost and risk factors Click to see Figure 11-11

System Changeover Direct cutover With direct cutover, changeover from the old system to the new system occurs immediately, as the new system becomes operational Cost is relatively low because only one system is in operation Risk is relatively high because there is no backup option Timing is an important factor for systems that have periodic processing cycles

System Changeover Parallel operation With parallel operation, both the new and the old systems operate fully for a specified period Data is input to both systems, and results can be verified Cost is relatively high, because both systems operate for a period of time Risk is relatively low, because results can be verified and a backup option exists Method is impractical if the systems are dissimilar or cannot be supported together

System Changeover Pilot operation With pilot operation, both the new and the old systems operate, but only at a selected location, called a pilot site The rest of the organization continues to use the old system Cost is relatively moderate, because only one location runs both systems Risk also is relatively moderate, because the new system is installed only at the pilot site and the risk of failure is reduced

System Changeover Phased changeover With phased changeover, the system is implemented in stages, or modules across the organization Phased changeover gives part of the system to entire organization Cost is relatively moderate, because the system is implemented in stages, rather than all at once Risk also is relatively moderate, because the risk is limited to the module being implemented

Post-Implementation Evaluation After the system is operational, two main tasks must be performed Post-implementation evaluation Final report to management Click to see Figure 11-12

Post-Implementation Evaluation Post-implementation evaluation feedback Includes various areas Accuracy, completeness, and timeliness of output User satisfaction System reliability and maintainability Adequacy of system controls and security Hardware efficiency/platform performance Effectiveness of database implementation Performance of the IS team Completeness and quality of documentation Quality and effectiveness of training Accuracy of cost-benefit estimates and development schedules Click to see Figure 11-13

Post-Implementation Evaluation A post-implementation evaluation is based on fact-finding methods similar to techniques used during the systems analysis phase Ideally, post-implementation evaluation should be performed by people who were not involved in the development process Usually done by IS staff and users Internal or external auditors often are involved

TRADEOFF When should post-implementation evaluation occur — how soon after system operation begins? If too long, users remember less about the development process and how it might be improved If too soon, users have insufficient time to assess system strengths and weaknesses Six months of operation is desirable, but pressure to finish sooner often exists

A KEY QUESTION At Yorktown Industries, Cindy Winslow needs your advice The new human resources system was finished under budget and ahead of schedule Cindy's boss wants her to handle the post-implementation evaluation, even though she headed the development effort for this project Cindy comes to you for advice — what should she do?

Final Report to Management Report contents 1. Final versions of all system documentation 2. Planned modifications and enhancements to the system that have been identified 3. A recap of all systems development costs and schedules 4. A comparison of actual costs and schedules to the original estimates 5. The post implementation evaluation, if it has been performed

SOFTWEAR, LIMITED The payroll package from Pacific Software has been implemented, and the ESIP system installation is ready to begin Perform installation tasks for the ESIP system extract module Confirm SWL’s network can handle the load Install the ESIP application on the payroll server Check server and mainframe communication Test the extract module, and confirm that the mainframe generates and downloads the proper data file to the ESIP server

SOFTWEAR, LIMITED Perform training tasks Establish security levels Conduct training session with the payroll group Explain the user manual Answer questions and obtain user feedback Establish security levels Set up password and authorization for director of human resources to modify ESIP options Provide security documentation, which is not printed in the user manual

SOFTWEAR, LIMITED Verify processing results Use test data with errors purposely inserted Continue manual handling of ESIP deductions Select and carry out system changeover Perform direct cutover, in connection with the weekly payroll cycle on May 7, 1999 Verify all results Obtain feedback from all users Update documentation and complete direct cutover procedures

SOFTWEAR, LIMITED Conduct post-implementation evaluation Evaluation scheduled after successfully completing eight weekly payroll cycles and two monthly deduction transfers The evaluation team was not involved in ESIP system project (one IS member, one from finance department) Team performed various fact-finding tasks Final report was prepared and sent to management Click to see Figure 11-14