Data processing:Computerizing the subsystems

Computerizing the subsystems

This is the next phase in the systems project. It consists of a number of studies, usually carried out consecutively, covering the various subsystems that were identified in the feasibility report for computerization. The stages of each study are:

1 Problem selection.

2 Terms of reference.

3 Investigation.

4 Analysis.

5 Design.

6 Implementation.

Let's look at each of these stages in turn.

1 Problem selection. This stage will in fact form part of the feasibility study. The principle is that a subsystem should be investigated only if the benefits expected from the investigation are likely to exceed the costs. These costs include the costs of the investigation itself. The analyst will therefore concentrate on systems which have reasonably heavy volumes of routine data processing work, and which therefore offer substantial savings if computerized.

2 Terms of reference. These must be written down before the study of a subsystem begins. They should identify the subsystem and so fix the boundaries of the analyst's investigation. Although he will need to investigate the way in which the subsystem impinges on other subsys­tems of the business, he should not, during the current study, make recommendations for changing those subsystems.

The senior management will draw up the terms of reference in consultation with the analyst. They will normally include a statement setting down in general terms the benefits expected from the investigation, and an estimate of the expected duration of the investigation and the number of staff to be allocated to it.

3 Investigation. This stage and the next (the analysis) comprise the subsystem feasibility study. Don't confuse this with the overall project feasibility study discussed earlier. The purpose of this (subsystem) feasibility study is to identify the ways in which the various procedures within the subsystem might be improved, and to quantify the expected costs of these improvements and the ben­ efits. The cost of running the present system must be compared with the cost of running the proposed system, the cost of change-over must be worked out, and the value of any improvements in, say, management infor­mation and customer service must be quantified as accurately as possible.

This investigation involves gathering as much relevant information about the subsystem as possible by question­ing managers and staff (using interviews or questionnaire forms), and by tracing the flow of data through the system. The object is to find out what procedures are used, what transaction documents and management reports are produced, and what the volumes of work are, i.e. how many documents of each type are produced each day or week.

4 Analysis. The analyst is now in a position to examine critically the existing procedures and outputs of the sub­ system. He will attempt to answer the following questions:

• Are managers receiving the reports they need from the subsystem, and are these being produced at the right frequency?

• Can the transaction documents produced by the subsystem be improved - are some unnecessary, should others be introduced, or should they contain more, or less, information?

• How can the procedures be made more efficient?

At this point in his study the analyst must find out the costs and try to quantify anticipated benefits that will arise from any improvements he might make in outputs and procedures. It may not be cost effective to provide all the information needed by managers, and a compro­mise may have to be worked out. He will eventually arrive at a set of recommendations that he will present to management in a feasibility report. In this he will suggest in outline form the structure of the proposed system, and what transaction documents and reports it should produce. Expected costs and benefits will be quantified and compared. In most cases management will accept his report, with perhaps some amendments.

5 Design. Once management has accepted the feasibility report the analyst can set to work on the design phase of the study. In the case of any procedures which are not to be computerized, this involves revising the manual ways of doing the work, redesigning forms, and producing procedure manuals. For the procedures which are to be computerized, the analyst will need to:

• Design the computer files.

• Design the computer procedures together with input (source) documents and output (transaction) documents and reports.

• Produce a report, called the systems definition, which describes the proposed system.

File design includes deciding whether sequential or random access should be employed, as well as determin­ing what fields, field lengths, and coding systems should be used in the records. The analyst must also define how the data is to be input, how the output is to be produced, and any validation and other control procedures.

In the system definition he will give details of every aspect of the proposed system, from specifying how the data is to be input to examples of the transaction documents and reports that are to be produced. He will also describe the computer programs needed.

6 Implementation. The implementation of the proposed system must be comprehensively planned by the systems analyst, and these plans should be included in the system definition. It will involve the following steps.

• Produce documentation describing the new system and how to operate it.

• Retrain the staff, in particular the clerical staff who are to operate the new procedures and equipment.

• Create the master files, by coding the data currently held on manual files and keying it into the system.

• Order the computer stationery.

• Test the new system. Although the individual programs that make up the system will have been tested by the programmers, there may be errors in the system as a whole. This is best checked by using the new system to process data that has recently been processed by the old system, and comparing the results. Discrepancies must be investigated, and any errors that come to light in the new system must be rectified.

• Run the new system in parallel with the existing system for several weeks, and investigate any further discrep­ancies that might arise.

Comments

Popular posts from this blog

WORKED EXAMPLES ON PROCESS SPECIFICATION.

Why do we need information systems, management structure, requirements of information at different levels of management.

The User Interface:Establishing User Interfaces