[Previous] [Next]
[Previous] [Next]
A potential land mine in this effort is that it is possible to get so concerned with the data integrity that the cleanup doesn't get done. The functional area must do some audits of the important data files to be carried forward, make a judgment about when they are "acceptable," and proceed with caution.
Many older systems did not have such things as referential integrity checks built into the databases, and there may be some "orphan" data in the files. When the new system is turned on, and referential integrity rules are applied, errors will almost certainly surface. There will be a conflict here between the data purists and the pragmatists, and the resolution of this issue may require some real leadership and judgment. Implementation could be delayed almost indefinitely by too strict a set of rules; a good compromise is to develop some system assurance reports that can be run after cutover in order to catch the errors and correct them as the system is being shaken down. The exception here is missing data in key fields; those must be corrected.
The reason that data cleanup is necessary is that in most situations, it is unacceptable to implement the new financial system without bringing some of the old system data forward into it. The simplest reason for this is the need to be able to generate reports against the "old" data from both the old system and the new one for system commissioning purposes. Quite apart from the fact that the institution's financial office will need to feel comfortable with the system integrity, the auditors will require this before accepting the new system. A new system, with data from the old one correctly converted, should be able to reproduce reports equivalent to those of the old system.
This conversion of old data can pose a variety of problems. Unlike the new system, the older system probably used a file or nonrelational database structure. This makes data modeling difficult at best, but if data are to be retrospectively converted, they must in some way be remodeled into the new structure.
One way to facilitate this process is to develop a bulletproof set of data conversion programs for each legacy system whose data will be converted. This must be among the most thoroughly tested code in the entire system, because the initial data that will be used will have been converted by it. Those converted data will then become part of the new "historical" record of the institution and be the source of any audits, historical trend analyses, or other activities. However, the team should convert only as much data as will be necessary for operation of the system. A minimum set is one fiscal year's worth. Too much retrospective conversion will drain resources by requiring time to be spent doing cleanup. The campus CFO and the auditors are the best judge of this retrospective conversion need.
[Previous] [Next]