Campus Financial Systems for the Future

Operating the system in parallel

It is almost unthinkable to convert to a new system without some period during which both the new and old systems are running in parallel with data being fed to each. The audit issues alone will necessitate such a parallel operation. A tradeoff almost always exists between the benefits and security of a long parallel systems period and the difficulty of keeping both systems in synch. A minimum might be three months.

In some ways the time period may be less important than the quality of the activities going on during the period, that is, that the players know their roles and responsibilities and that duplicate effort is not occurring. To adequately test a new system in parallel will take significant effort; if that is to be limited to a relatively short period, such as a quarter, then the plan must be very precise. This is not one of those areas where an army of people can be applied to get the job done in a short time. There are probably a limited number of people in the financial offices of the institution who can really validate the system, and their time resource must be used effectively.

Another reason why this period has to be very carefully planned is that in some ways it is going to be the only phase of the effort that has an absolutely firm deadline. The parallel period usually ends with the annual closing process so that the books may be closed with the old system that started the fiscal year. It is this latter requirement that makes the schedule so inflexible. Most auditors will not permit the closing of the fiscal year on a system that was not the one with which the year was opened. As a corollary to that, usually it is not an option to postpone implementation a full year. So, once the parallel period is started, the die is cast.

It is probably very useful to have some hardy "early adopters" outside the finance unit begin to use the system at this stage (for example, departmental business managers). They will test the system better than the finance unit ever could. Their participation will be key during the ensuing sign-off process. There should be a firm schedule of what is to be tested in each fiscal period, and no slippage can be allowed in this phase. This recruiting of early adopters will also conserve the resources of the finance offices for system validation, as opposed to having them occupied doing transaction entry. If these individuals are recruited early enough in the process, they might also serve on one or more of the implementation teams.

There cannot be enough "system assurance" reports during this phase. Consider testing a limited set of the transactions (especially those related to critical processes) during each period very thoroughly, as opposed to testing all transactions every period not so thoroughly. If the source of transactions to be tested in the initial parallel period are controlled carefully, it will be clear what to look for for on the output side of the process. It is important to understand that output might be different between the old and new system, and not to assume that the new output is incorrect, as new systems may be more date sensitive than older ones.

"Rogue" transactions that are not pre-audited can cause very time-consuming analysis. Remember, this phase of the implementation has an inflexible deadline, and there is no alternative to a completed test. It is better to completely test and validate the essential components of the system so that cutover can occur than to try to test every possible combination of transactions and not get the basics done. Thus, an 80/20 rule applies here, too. Validate that the transactions that fall into the 80 percent category will go through flawlessly, and concentrate the analytical time after cutover to watching the 20 percent more carefully.

For in-house or partner-developed systems (i.e., ones that have not previously been deployed elsewhere), there is the danger of a false sense of security on the part of the designers and developers at this stage, and sometimes a tendency for some team members to relax. Designers, developers, and other technical members will feel that their tasks are over for now and they can sit back a little -- they have done their testing and handed over a stable, functional set of code. Few developers feel their work is going to be flawed and cause problems! Most seem to think, in the face of all the contrary evidence, that they have written bug-free code and all will be well. For reasons stated above, time is more critical during the parallel testing period than at any other phase and the developers need to be available to quickly make code changes.

[Previous] [Next]