[Previous] [Next]
VI: Implementing the System


Cutting over to the new system alone

With the increased dependency on technology, an obvious task before cutting over to the new system is to take snapshots of data, in the event of a disaster and the need to go back. That is perhaps one of the most compelling reasons why the cutover takes place at fiscal year end. The snapshots have to be at the various levels of detail that would enable a recovery. At the very least, balance totals for object codes (income and expense classes) should be captured. This will probably be automatic if it is being done at fiscal year end.

When the actual cutover day arrives, it is important to understand that for all practical purposes, there is no going back. The costs attendant on such a move are likely very high. For most institutions, if the cutover occurs at fiscal year end, a significant delay may mean a one-year delay. However, if the implementation plan and the parallel testing have been done correctly, this will be a huge anticlimax. No one will notice except the finance organization.

The cutover to the new system can be accomplished in a number of ways, but it will usually fall into one of two basic types -- a simultaneous cutover of all components of the system at once, or a phased implementation of components.

Full-fledged cutover at once of all components -- transaction processing, general ledger, and associated components -- is a very difficult proposition for many institutions and may only be possible when the number of users is very limited. The reason for this relates to the scale of the training required to accomplish it. The prospect of having to train hundreds of users in the use of the new screens for transaction processing in a very short time makes it virtually impossible at a large institution. The idea of JIT training would probably be impossible with so large a number of users. The technical coordination and workstation configuration alone might prove too difficult to address.

Having said that, there is no doubt that if it is possible, a onetime cutover to the entire system by all users has real payoffs. The benefits of the new system will be realized by all from day one. The reallocation of finance and other support staff will be shortened in time. The impact alone of the implementation being done all at one time will really focus the attention of the institution and make for a very visible beginning.

However, numbers of users and/or their different levels of readiness may make it practical to phase in the use of the new transactions department by department and have the other documents sent to a central data entry area where well-trained staff can do the input until the training process is completed over a longer, more manageable period. This minimizes the severity levels of first-day problems for the finance and technical support staff.

The general ledger poses an entirely different problem. It is usually not possible to manage two ledgers for any length of time, so the only possibility is to cut over all data to the new G/L at one time. Half the institution cannot run on one set of books and the other half on another.

This presents a training challenge, but one more manageable than the prospect of bringing the entire user base up on the transaction system at once. The problem essentially boils down to training staff on the use and interpretation of the new standard reports, and this can be accomplished by a series of educational sessions held over a period of no more than one month, usually the last month of the parallel operation. This gets the institution onto the new general ledger in one move and offers the best chance to bring it quickly to a stable mode of operation. The implementation of the transaction system can then proceed in an orderly manner dictated by training resources and organizational readiness. Of course, during this phase-in period, the central accounting functions will have to shoulder the data entry burden of those units not doing their own transaction data entry.

It is important to remember that the only thing that has to happen is that at the end of the next fiscal period the books can be closed again. If some transactions have to be entered by the accounting department from paper copies or "batched" in for a month or two, that may be acceptable.

The greatest danger related to cutover is that there will be too much caution and this day will be postponed indefinitely. Those waiting for perfection will be like those waiting for Godot. Judgment is critical at this point. The system must be of sufficient integrity to go live, not necessarily to be perfect. The reason for this is that the period of greatest learning and adjustment will be right after cutover, so strive to get there as soon as possible!

A critical success factor for in-house or partner-developed systems is ensuring technical competency at this stage of the project, more than any other. During the design and development phases, technical decisions are always being made, but during implementation they have to be made more quickly and correctly. The system cannot be "down" for too long or the users will lose confidence in the entire process. This is when the technical competence of the developers and the judgment of the project leadership are at a premium.


[Previous] [Next]