D880 – Load Live Start-up Data
All initial start-up data should be collected, prepared and loaded. This includes manual or automated preparation and cleanup tasks in addition to the running of conversion suites and manual data entry.
This process covers the setting up of live start-up data. Live data includes:
The two primary methods used to load data are manual data entry and the running of automated conversion suites. Preparatory tasks may also be appropriate, for example to verify, clean up or supplement the old data. Very often these preparatory tasks may have started months before the final conversion process. The overall approach will usually have been considered and signed off in preceding Implementation Papers.
Once the data load has been completed, the start-up data will be verified and signed off by the responsible user managers – see Process D890.
PATH PLANNING GUIDANCE
Dependent procedures (Finish-Start):
Working conversion suites
Data Conversion Strategy IP – see Process D180
Data Conversion IPs – see Process D400 / D450 / D600 / D604 as appropriate
System Handover plan IP – see Process D830
DETAILED DESCRIPTION OF TASKS
The preparatory tasks and conversion of live data will be carried out in accordance with the System Handover Plan IP using the techniques agreed in the Data Conversion IPs and the Data Conversion Strategy IP.
Data validation and purification
Well before the final conversion of data, tasks may be undertaken:
to improve the quality of the data,
to collect new or supplementary data,
to validate the current contents of data,
to archive or delete old unnecessary data.
These tasks are usually handled by the normal administrative staff responsible for the aspect of the business. In some cases they will be assisted by standard reports from the old system or by custom validation, reporting and extraction programs developed as part of the project.
Whether or not data clean up procedures have been formally defined, the users should be encouraged to improve the quality of the data prior to conversion – it is often invalid data which leads to problems with the conversion process.
Automated Conversion Programs
If appropriate, data conversion suites will have been defined, designed, developed, tested and accepted. Conversion programs are often only used once for live purposes (although test or dummy conversions may have been made to prove the programs work properly). In some cases these programs may have been developed to lower standards with less documentation and testing. Inevitably, there will be concerns about achieving the conversion within the time and resource constraints available.
Conversion suites will often include validation and reporting functions. These will be used to check that the conversion has been correctly performed. Auditing needs will normally require that the transfer of data to the new package has been performed correctly. The transfer of data should be traceable, which means that records should be kept detailing:
the original data set,
the conversion routines including program source codes and explanatory descriptions, and
the resulting data in the new package.
To make the conversion routines auditable, checksums for totals and subtotals for reasonable sort-criteria (eg number items transported or amounts posted in total and per category) should be documented and checked before production starts. A formal sign-off by the user department that data has been transported correctly into the production system avoids later problems of data integrity after system startup.
Manual Data Load
Manual techniques may be used to enter live start-up data – it may often be more efficient to use this approach than to develop and test a major suite of programs. This will have been considered and agreed in the appropriate Implementation Papers.
Normally, the package’s standard data entry facilities will be used. This has the advantage of invoking the package’s full validation routines. People entering data will require adequate training in using the relevant facilities of the package for manually loading data. This experience can sometimes act as an excellent consolidation of the training for the people concerned.
In some cases, the normal data entry process will be inappropriate, for example, it may not be possible to backdate the depreciation calculation for a new asset so that an old asset can be entered through the normal facility for new assets. Most packages, however, provide some automated support for normal types of live data set up.
For very high volumes and high productivity, it may be possible to set up an alternative form of manual entry, for example, using a “key-to-disk” system to set up batch records for processing through the system. Combined with specialist data-entry staff this can provide a very rapid manual take on of data.
Staff will often be required to work unusual hours or in unfamiliar ways or conditions. Temporary specialist data-entry staff can often be hired to help. Such details need to be agreed with the appropriate bodies within the client organisation.
Manual techniques will lead to a significant error rate. Appropriate measures should be taken to validate the data, to minimise the number of errors and to minimise the impact of those errors. It is, however, normal to assume that data is never 100% accurate and the business risks of some invalid data should be balanced against the costs of obtaining perfect data.
Just as in automatic data conversion, audit checks with checksums for totals and subtotals for reasonable sort-criteria should be documented and signed-off to make sure that the data-entry figures correspond to old data. Adequate records should be kept to preserve the original version of the information and to track the way in which it has been converted and input to the new system.