Runn= ing head: CONVERSION STRATIGES

Conversion Strategies when Converting from a Manual to a Computerized System

Wayne Machuca
Northcentral University

October, 2005

Introduction

&= nbsp; The conversion of an existing manual system to a computerized system is a proce= ss which can be both gratifyingly and excruciatingly painful. Much will depend= on how the implementer prepares the ground-work for the change that is to come. Within the broader fram= ework of the conversation of a conversion, a great deal of research, investigatio= n, and preparation needs to be done.

Conversion Concepts
&= nbsp; In a systems conversion an analyst will follow a multi-step approach. Both Oz (2004) and Satzinger, Jackson, & Burd (2002) describe a 5-step approach= to information systems development and will be used as the basis for this essa= y. The steps in brief are 1) planning, 2) analysis, 3) design, 4) implementati= on, and 5) support. This is, of course, by no means the only possible approach = to systems development. Condor (n.d.) and Liu (n.d.) both note a six-step approach, where the U.S. House of Representatives (1999) maintain a seven-s= tep approach. While any number of steps or phases can be identified as essentia= l to accurate systems development, many can be (and are) combined into larger ph= ases for ease of identification.

Planning

&= nbsp; In the first phase of planning it is critical that the analyst perform several “ground-level” functions. Initially, the analyst must define the problem. In analyst parlance, it is important that the project at hand is n= ot a “solution in search of a problem”. That is, for the solution to make sense, it must be solving something. It is the responsibility of the analyst to ascertain that 1) there is a problem and 2) that the project wil= l be the solution to that problem.

&= nbsp; In this phase, the analyst should become versed in the operations of the exist= ing system or status quo. The analyst needs to know what the existing sy= stem provides and does not provide. The analyst must also be aware of how the us= er perceives their data and develop a user model which is essentially an understanding of how the user perceives their own reality. Satzinger (2002) notes that in this phase, the project will also be staffed and launched.

Analysis

&= nbsp; In the analysis phase, the analyst will investigate the existing system, define system requirements and generate possible solutions. During this phase, participation by both management and especially operations staff is critica= l. A project design that only satisfies the requirements of management may be unusable once it goes-live and fails to function for operations. Satzinger (2002) recommends the creation of prototype systems to allow users and othe= rs the opportunity to experience the look and feel of the new system.

&= nbsp; The analysis phase is also the time when the analyst shall produce a project schedule and determines feasibility. Oz (2004) expands this step to include= a study of technical feasibility, economic feasibility, and operational feasibility. Essentially, what the analyst must determine is can this proje= ct be done and is its development within the scope of the organization. An exa= mple of this decision, in a gross sense, would be if a middle-sized business des= ire to convert from type-written memos to ones created on a word processor. Whi= le the organization could technically create a home-grown word processing application to do so, it would not be economic to do so.

Design

&= nbsp; In the design phase, the project is actually built. There are several issues to consider during this phase including the larger aspects of systems integrat= ion, or how this system will function in the larger scope of information systems= at the organization. Of the issues, there are two which are critical to the survival of the project. The first is testing. Testing, sometimes considere= d as a distinct phase, should actually occur all along design and development. A= ll aspects of the project should be tested extensively and should use “live” data whenever possible. Using real data gives the develo= pers the opportunity to estimate how the system will respond in real life.

&= nbsp; The second critical issue is the development of interfaces. Specifically, the u= ser interface is the method by which the users will operate the new system. User interfaces must be understandable, easy to use, and in many cases have a familiar look and feel when compared to the original method. Activities sho= uld be named, for example, similarly to how they were described in the past. Systems interfaces are equally important especially if the system needs to = function within a local area network, intranet, or data base system.

Implementation

&= nbsp; Implementation of the system is the time when the project is made available to the organization for use. It is a critical time, and one which probably causes = the most sleepless nights for the analyst.

&= nbsp; Oz (2004) rightly points out that before implementation takes place, the user community needs to be trained in the new system. This training can take on = many forms depending upon the size of the project. At its basest sense, the user upon whom the new system is to be inflicted needs to know how that system w= ill function and be able to recognize its workings.

&= nbsp; The implementation step itself will usually follow one or more of four basic strategies. One strategy is known as shut-down-start-up or cut over (Oz, 20= 04). Here, the old system is shut down and the new system is turned on. The advantage of this strategy is that the old system is gone and the users must make the new system work. This is also a disadvantage if the new system fai= ls to function as required by the organization. Nevertheless, a strong commitm= ent to this strategy will support the organization in accepting and using the n= ew system.

&= nbsp; Another strategy is known as phase-in or phased. This is particularly beneficial to= the implementation of larger systems and is a process where parts of the new sy= stem are brought on-line a little at a time. With a larger system, the design ph= ase may take years and it may be inappropriate to make the user community wait. Also, as newer modules are introduced, lessons learned from earlier modules= can be incorporated as upgrades. One important disadvantage to the phase-in str= ategy is that should the user community rebel against the new system, it is often= too easy to abandon the project and return to the old system.

&= nbsp; A third strategy for implementation is known as parallel. Here, the old system and new system are run side-by-side for a time until the new system, free f= rom problems, can stand on its own and the old system can be terminated. The primary advantage to this strategy involves the replacement of mission crit= ical systems. If the organization will suffer adversely should the conversion fa= il, a parallel implementation would be appropriate. The disadvantage of the parallel strategy, similar to the phase-in is that it is too easy to abandon the new system should it not perform to expectations. Another disadvantage = is that during a parallel implementation, the old and new system may need to be in communication with each other making system interfaces critical.

&= nbsp; Oz (2004) describes a fourth strategy called pilot which is very similar to the parallel strategy. In pilot, both the old and new systems run simultaneously until the new system is ready to completely replace the old. One area where this strategy would work well is in a larger organization where one part of= the organization works with, or pilots” the new system while the rest of = the organization maintains the old. Then, when the new system is proven, it will then be incorporated into the rest of the organization.

Support

&= nbsp; The final step in the development of the new system is called support. Here and ongoing, the organization will require staffing and service to care for the system and the organization. Oz (2004) identifies support as post-implementation debugging, changes and additions, and user help. Satzin= ger (2002) graciously uses the terms maintain and enhance instead= of debugging. Both agree on the important need for user help.

Post Implementation
&= nbsp; After the new system is in place, over time new needs will develop, new issues wi= ll arise that will require the analyst to eventually reinvestigate the system = and the process may begin again. This creates the cyclical nature of the systems development life-cycle.

&= nbsp;

References

Liu, Y. (n.d.). A= ppendix A. Retrieved on October 7, 2005 from http://www.cis.uab.edu/info/grads/liuy/appendi= x_a.pdf#search=3D'systems%20development%20phases'.

Oz, E. (2004). Ma= nagement information systems. Boston, MA: Course Technology. 4d.

Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2002). Systems analysis and design in a changing world. Boston, MA: Course Technology. 2d.

“Systems development life cycle consists of six phases”. (n.d.). Retrieved on October 7, 2005 from http://cond= or.depaul.edu/~danderso/powerp2/tsld015.htm.

U.S. House of Representatives (1999, March 24). Systems development life-cycle policy.= Retrieved on October 7, 2005 from http://www.house.gov/cao-opp /PDFSolicitations/SDLCPOL.pdf#search=3D'systems%20development%20phases'= .

&= nbsp;