SYSTEMS ANALYSIS & DESIGN

1. SYSTEMS ANALYSIS & DESIGN PHASE 4 SYSTEMS IMPLEMENTATION Installation and Evaluation

2. Chapter 11 Installation and Evaluation

3. Objectives • Discuss the main tasks in the installationand 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

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

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

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

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

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

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

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

11. Click to see Figure 11-5 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

12. Click to see Figure 11-6a Click to see Figure 11-6b 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

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

14. Click to see Figure 11-7 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

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

16. Click to see Figure 11-9a Click to see Figure 11-9b 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

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

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

19. Click to see Figure 11-11 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

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

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

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

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

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

25. Click to see Figure 11-13 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

26. Post-Implementation Evaluation • A post-implementation evaluation is basedon 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

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

28. 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?

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

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

31. SOFTWEAR, LIMITED • Perform training tasks • 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

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

33. Click to see Figure 11-14 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