Parallel Run is the stage where the existing systems of the bank run concurrently with the new Oracle FLEXCUBE system. The basic objective of this activity is to ensure stability of the new system, enable the users to become comfortable with the new processes and to develop confidence leading to complete switch over. However, the parallel stage places tremendous pressures on resources, time constraints and co-operation by bank personnel. Therefore, careful considerations must be made to all activities, to ensure that all tasks and resources are evenly distributed. It should be ensured that the users understand their responsibilities, and differences in the operation procedures, on the two systems. Remember the users have to use two systems simultaneously, and this alone is enough to cause confusion if not properly planned. In fact, even the movement of paper - tickets, contracts, etc. must be planned.
As in the case of conversion, the day to day verification of account balances, contracts, static maintenance and transactions must be diligently performed. This must be done by a team independent of the persons doing the input. The verification of financial equality of the two systems is the main point behind the parallel run, and any laxity in this area, might lead to indefinite extensions of the parallel run. For the same reason, if there are any differences, they must be resolved immediately.
Ideally at least one End of Month should be included in the parallel run. Details on how and when to conduct call backs, accruals/liquidation, error reporting and correction, as well as training on dummy conversions are described in this chapter.
The Senior Operations Manager from the bank and the Project Manager from Oracle Financial Services will co-ordinate and plan the parallel run procedure in line with job functions and bank staff usage of the system.
Note
The rule should be postings to Oracle FLEXCUBE should precede other systems.
Each department will call back its entries prior to leaving at the end of the day. This callback should catch the majority of posting errors.
Accounting Journal should be compared with the equivalent reports from the existing system by each department and a report should be submitted to the Reconcilement Controller at the end of each day. Data Center should commence End of Day operation only when all departmental reconcilement are correct.
The information on the current records on the existing system must be compared to that on Oracle FLEXCUBE through detailed callbacks. Callbacks should be done by a central callback team and various user departments. Wherever possible, use of spreadsheets or automated tools should be made to ease the manual workload.
Reports are classified as Core and Module specific. Core reports are those which contain key financial information across bank/branch. Module specific reports are key reports relating to the front-end modules. In addition to the reports, advices and messages generated should also be checked and compared.
Some of the critical reports to be checked are:
Core Reports
Module Specific Reports
Error Recording and Correction
The timely correction of errors is essential for a controlled parallel. Errors should be recorded in a Parallel Log. The log should contain the following for each day of the parallel run:
It should be the responsibility of the Parallel Controller to maintain this record. The Senior Branch Operations Manager should review the Parallel Log on a daily basis and initial it.
A series of training sessions should be conducted to explain method for performing call-backs, completing documentation and error correction before the financial conversion.
A Dummy Conversion and Parallel should be conducted for one week prior to the live conversion to confirm that all participants understand the process.
The conversion and parallel involves a significant additional workload on the bank. The bank should plan to minimize the additional workload on the operations during this period.