The stages of implementation are:
Hardware and software acquisition
Hardware and software acquisition
This involves buying required hardware and software. Need ITT
Aimed at maximising staff utilisation of the system. If you want to maximise your investment in new systems you will need to invest in staff training to ensure staff can maximise their utilisation of that system.
There are a number of keys to good training.
1 Plan the training to be as close as possible to live usage so that members of staff do not get the chance to forget what they have learned.
2 Get the design team to produce user documentation for the training course. User manuals are necessary.
3 Who are you going to get to do the training for you? If the systems are supplied externally then the software house will be best, though for common ‗off-the-shelf‘ pack-ages there will be a number of cheaper computer training specialists.
At this stage the new system will be physically installed into the firm‘s premises. This requires careful management:
It will need to be addressed early in the systems development work as it may have a long lead-time. For instance it may be necessary to obtain planning permission for any building alterations;
It is very easy to overlook simple things like ensuring you have sufficient power points, desk space, filing cabinets and so on;
It requires close consultation with all of the interested parties i.e. hardware and software suppliers, communication services providers, builders, users and so on.
Now that the new system is physically located on the premises the next stage is to load the correct standing data and opening balances onto the new system.
This will take two forms:
1 Test data posted to the new system prior to live use to check it will process accurately. A (now poverty stricken) MP said recently ―Asking Lloyds to self regulate Lloyds is like asking the Mafia to self regulate the Mafia‖. When designing the test data take care that the programmers are not designing it — it is their work you are testing. The users or, if available, Internal Audit are best.
Periods of acceptance testing where there will be careful testing of live transactions in the early periods of use. The principle of acceptance testing is that the system is only completed when the users accept it is functioning properly.
The four changeover options are direct, pilot, phased and parallel running:
Direct changeover .
The immediate replacement of the old system by the new. Often this is your only choice
— there may not be office space to run both systems or you may be using new software on your existing hard-ware. It is to be positively recommended where the new system is based on an established off-the-shelf solution. As long as staff has been trained and the system has been tested it should work well.
A distinct part of the new system is brought into use and, once tested, will be brought into use immediately elsewhere. This is particularly useful in distributed systems where you can pilot the new system in, say, the Leeds office and once it is working bring it into use in all other offices with immediate effect. Another type of pilot is known as
‗Restricted Data Running‘ where, say, customers A-D are processed on the new systemand once functioning properly all customers will be processed on it. In effect with pilot implementation you are selecting a typical part of the organisation and testing the new system within it using live, rather than test, data.
This is another popular option but it is more time-consuming than both direct and pilot. Here you will gradually introduce distinct parts of the new system. You can use either local offices in a wide area network — say, Nairobi in August, Mombasa in September, Eldoret in October and so on, or distinct software modules — say, payroll in August, stock control in September, word-processing in October. One advantage of phased implementation is cash-flow — you can spread the cost out over the phases, however it will cause disruption within the business as different parts of it are using different, often incompatible, systems.
This is often assumed to be the best option. Certainly error detection is excellent as there is direct comparison of information between the old and new systems. It is however very costly and if your staff don‘t complain about being overworked during a parallel run then you are over staffed! It should be used only for
‗business critical‘ systems where the cost of failure would be high.