L10 system implementation

THE IMPLEMENTATION PROCESS
• The purpose of implementation is to put the
theoretical design into practice. It can involve
the installation of a complete system or the
introduction of a small subsystem . The aim of
this phase is to implement a fully-documented
operational system which meets the original
requirements according to the design given in
the systems design specification

Implementation
Implementation involves the following activities:
(a) Writing, documentation and testing of all the
programs required.
(b) Creation of all the master files required in the
system.
(c) Preparation of user and data processing
department operating instructions.
(d) Commissioning of the new system.
(e) Education and training of all staff who will use
the system.

Implementation of a Package
• If it is possible to use a package, activity step
(a) will not be required.
• All the other activities, (b) to (e), will have to
be carried out, and it may look as if we are not
saving much effort by choosing a package

System Testing
• Integration issues may come up even for a very good
program of system.
• System testing will follow a similar pattern to the
testing of programs. First, simple files will be created
and the sequence of the data flow diagram followed.
The output from each program will be scrutinised to
see that the data has been processed correctly.
• When the programs can pass data reliably between
themselves, then the data is made more complex, until
there is sufficient confidence to use live data.

File Conversion/Creation
• When a new system is to be implemented, it is likely that
the master files either do not exist, or, if they do, that they
are not organised as required by the new system. Before
the system becomes operational, the master files must be
created . This can be a major task, and it may involve the
production of a file-conversion system, with its own
programs that will be used only once
• With many systems, it is possible to enter the static data
into the new files over an extended period of time prior to
the changeover to the new system, leaving only the
dynamic data for later entry. For example, product
descriptions, code number, supplier details, etc. could all
be entered into a product file quite a long time before the
stock levels.
• For volatile data, file conversion may be done during a
weekend and data files are frozen thus no transactions

Education and Training
• All staff must appreciate the objectives of the
new system, and how it will operate, as well as
the facilities it will provide. Those staff who
prepare data, operate the system and use the
output will require detailed training and practice.
• Special practice sessions must be arranged,
especially where there is a direct changeover,
when there is no "running-in" practice period of
pilot or parallel running.
• Training must also cover the procedures to be
followed when something goes wrong.

Implementation Planning
• The successful implementation of any system is based upon the following
points:
• A project control monitoring time, cost and quality of output.
• Managerial commitment and involvement at all levels.
• Analysts who are good communicators and have a thorough knowledge of
the organisation's operations and applications.
• The users' knowledge of and agreement with the system objectives.
• Recognition of user responsibilities in the system development.
• A computer manager capable of getting user support and of instilling
confidence in users.
The planning must be very thorough and include all activities and related
responsibilities to make the new system work and to withdraw the old one
with its documentation. In larger installations a co-ordination committee will
be appointed. Their purpose is to ensure a smooth implementation. The
analyst will be the committee secretary and will have the major responsibility.
A timescale is established and regular progress meetings are held to ensure
the timescale is being kept to.

Implementation Personnel
As well as the specialist computing staff responsible for the
implementation of a system, other personnel have an essential
role:
• The business manager and user group, including those
involved in the prototyping, will be brought in to make the
final test.
• The technical manager will assist the users with the
mechanics of actually running the machine(s).
• Hardware representatives will be consulted over problems
and for general advice.
• Consultants will be available for specialist advice on larger
projects.
• The administrative section will be advised of new personnel,
job and responsibility changes and all the necessary clerical
backup; again this is applicable to larger projects.

USER INVOLVEMENT
User Involvement in System Testing –
• There is the problem of how staff can carry out normal
duties, while at the same time being concerned with
their new roles.
• User testing and carrying out totally new tasks may
well involve evening and weekend working. Checking
outputs is not a familiar task, and the sheer amount of
work involved may be daunting. Managers may find it
hard to check output which is in an unfamiliar form.
Despite such problems, though, attempts must be
made to carry out tests involving the user as much as
possible.

User Involvement in Implementation
In operation of the system, the line management
must know the new duties that their staff will be
required to perform. They have to make sure that:
(a) Input data is being prepared correctly, and on
time.
(b) New reports are being properly used.
(c) Their staff are able to use and understand the
system. During the project development period,
the user management will have a great deal
more work to do in helping with the new
system.

CHANGEOVER STRATEGIES
Importance of Successful Changeover
• The changeover implies changes in working practices: from
clerical to computerised, from centralised computing to
distributed computing; from one type of machine to
another; and so on. Staff tend to resent change, and so to
ease the way they must be kept fully informed, and in a
direct manner. Any individuals adversely affected must be
told personally.
• Changeover has to have the support and involvement of
managers and the co-operation of systems staff and users.
• There are two basic methods of changeover – direct and
parallel – and some variations of these.

Direct Changeover
• Using direct changeover, at a specified time the old system is switched off
and the new switched on. This is advantageous in that resources are
spared – the method involves the immediate discontinuance of the old
system. However, the new system must have been thoroughly tested so
as to minimise risks in initial operation. Should the new system meet with
unexpected problems – hardware, software, or design – then the old
system may not be able to be retrieved.
As you will realise, this technique is potentially dangerous since it implies
transfer of dependence from a current working system to a new system
which, although tested, has not been used in a real situation. However, there
are several situations where the technique is applicable or unavoidable:
• In very small systems it is often not worthwhile considering any other
technique, owing to the inherent simplicity of the system.
• In very large systems it is sometimes not feasible to maintain two systems
simultaneously (as in parallel and pilot running) owing to the work
involved.
• Where there is little similarity between the old and new systems, the
simultaneous running of both systems may be unhelpful.
• Moist fearsome and some staff may absentee themselves

Parallel Changeover
• In parallel changeover the old and new systems are run
with the same data until there is confidence in the new
system, whereupon the old system is dropped.
• Parallel changeover or parallel running of the old and the
new systems simultaneously allows a comparison of output
to be made between them. Any shortcomings of the new
system can be rectified, and continuous cross-checks made.
This is the most common method of changeover, but it is
important to identify objectives, and a timescale must be
established.
• Problem if there is different results and it isnt clear which
system is wrong.
• Not clear when to terminate the old system
• Sometimes there is overuse of staff and other resources to
run two systems

Phased Changeover
• Within the two basic methods discussed above we find a number of variations, of
which the most common is phased changeover, where the new system is
introduced in phases or stages as each stage is implemented and operating
correctly. The phases continue until the whole system is in operation. This method
would be used for very large information systems which possess many complex
components and which cross organisational frontiers. The method consists of a
series of direct changes. The implementation of each phase can be controlled, and
risk to the user department is thus reduced considerably.
• This method allows easier transfer of staff and is probably the most satisfactory
method of working, where it is possible. It permits thorough testing under real
conditions while limiting the risk of system failure. It requires, however, that part
of the system functioning can be conveniently separated from the rest. It also
requires some additional clerical effort in handling two different systems
simultaneously. This method is sometimes called 'pilot running' (see later),
although note that pilot running can also be achieved under the parallel running
method.
• The great disadvantage of using any phased or pilot implementation is that users
often have to wait many months, or even years, for a system to be available to
them which completely fulfils their needs. Their needs may well change during the
implementation period, and if their new needs are to be featured in the system,
the final system may never be seen.

Pilot Running
• Pilot running is usually used to mean where the
new system is run under controlled conditions
using old data, where a small representative part
of the old system is used as a test area This is a
similar concept to parallel running but is less
disruptive – data from one or more previous
periods is run first on the old system and then on
the new one. Timings are thus less critical,
although realistic timing and data
capture/conversion are not simulated.

Changeover Methods Compared(a) Direct Changeover
Advantages:
• This is the simplest method: stop one system, start another. It is usually only undertaken over a weekend or holiday period.
• No extra work in running two systems together for a time.
Disadvantage:
• Very high-risk – if the new system is disastrously wrong, it is difficult to recreate the old system.
(b) Parallel Changeover
Advantages:
• This is a safer method as the old system is kept operational while the new system is brought in.
• Much greater security.
Disadvantages:
• Greater effort is needed to run the two systems and to compare the outputs.
• It may not be very easy to revert to the old system should things go wrong. The new system may handle the information differently, making it
awkward to compare outputs.
• The responsibilities of staff may well change between systems, leading to confusion.
• Knowing when to make the actual changeover. This is usually a compromise between too short a time, keeping costs to a minimum, and too long a
time, allowing for extensive testing.
(c) Phased Changeover
Advantage:
• There is considerable control as only manageable chunks are being changed over at a time.
Disadvantages:
• The system may not easily be split into phases.
• The phases may well be different in the two systems.
• The interfaces between remaining old system phases and the new system
• phases already changed over, are extremely difficult to control.
(d) Pilot running This is often the preferred method.
Advantage:
• Considerable control is retained and no risks are taken even if direct changeover is applied to each area.
• Disadvantages:
• Time is needed to collect and collate the data to be used.
• The two systems may handle the data differently, making comparison of outputs difficult.

TRAINING
End-users will expect thorough training as part of their acceptance of the new
system, and it is also in the interests of the organisation that their staff should be
properly trained in its use. There are three aspects to be considered in developing
effective training:
• Who should be trained?
• How should they be trained?
• What levels of training are needed?
• These questions can only be completely answered with a full knowledge of the
system involved. But generally:
• Those who just need knowledge can attend a manufacturer's training school or
attend targeted in-house courses.
• Those requiring a skill can go on specialist training courses, which can be
conducted internally or by the product manufacturer.
The training should be provided in relays, i.e. only so many staff at a time, whilst the
others continue to operate the old system and receive information and instructions
relating to the new system. With careful planning, the training should not create
many problems. At all times, care should be taken with staff problems and worries.

L10 system implementation

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to L10 system implementation

Similar to L10 system implementation (20)

More from OMWOMA JACKSON

More from OMWOMA JACKSON (16)

L10 system implementation