Before the new system can begin live operation, the technical staff who assume support responsibility must be properly prepared. Training for the operations staff falls into two categories: Operations Training and Software Support Training.
Operations Training
Operations training is intended for Information Systems employees who work in or around the data center or "computer room". In a distributed environment, this may include staff who work in a remote warehouse or manufacturing facility. An outline of this training would include:
Procedures and timing for system backups
How to print Payroll checks, Accounts Payable checks, Invoices, Statements, Pick Slips, Work Order Routings, Parts Lists, or other special forms
Procedures for bursting, binding, and distributing forms and reports
Troubleshooting hardware connections, and setting up new user workstations
Software Support Training
Software Support Training is particularly important if the application software was implemented primarily by a software vendor or outside consulting firm, who will not be readily available on short notice in the future. This training should cover:
how to access source code and documentation for the application software
access to source code and documentation for any custom modifications or system interfaces developed during the implementation project
standards used in the development of all custom software in use
procedures for applying future vendor-supplied software upgrades
Transaction and Master File data which is of relatively small volume will be entered manually. As with all conversion data, the issue of cutoff timing is critical.
Cutoff Timing
Failure to carefully coordinate the cutoff and re-entry of conversion data can cause errors and confusion. For example, assume a listing of all open receivable items is printed on Friday at noon. The report is to be used to enter the identical invoices into the new system as startup data.
Following the printing of the report users are allowed to continue entering invoices the rest of the afternoon. When the data is re-keyed into the new system, the invoices entered on Friday afternoon are lost. Receivable balances for these customers are also inaccurate.
Data entry cutoffs, report printing, and access to the new system should carefully controlled according to the conversion script developed in the System Integration phase.
Entering the Data
Due to the costs associated with professional services and with the project team members' time, much of the data will likely be keyed either by an internal clerical resource or an outside temporary employee. This individual may not be as familiar with the new software as project team members are.
Most application software screens have "hard edits" on certain data items, requiring a user to key information into these fields. The data entry clerk, in this case, needs to be aware that much more information may be needed for each record than what the software requires.
For example, a file of customer records entered with only a customer number, name, and address will be useless if the operating procedures require items such as credit limit, payment terms, and primary contact person to be entered for each customer.
Conversion programs read Master File or transaction records in the format of the source system, convert them to the format of the target system, and write to the target data base.
Preparation for Automated Conversions
Before any conversion programs are run:
The conversion programs should have been executed in a test conversion, using production data from an earlier period, including reconciliation and approval by user management.
All files which are to be updated in the production environment should be backed up.
> All target files should be verified to be empty, and no users should have access to enter records.
Conversion Batches
The conversion of transaction and historical records is often done in batches, corresponding to months, years, or customer groups, rather than all at once. These batches may be converted over time, as long as the system is not opened up for user input until the conversion has "caught up" and converted all data. In these situations, data base backups should be taken in between each batch.
Note that master file records must typically be converted before converting transaction data. Otherwise, the transactions will refer to items, accounts, customers, or vendors which do not exist in their respective master files. This is a temporary data integrity error which most integrated application packages will not tolerate well.
The sequence of file conversions is determined by data dependency, as described above, rather than on whether a given data item is to be converted manually or electronically.
A Verification Procedure
At the end of the Conversion and Startup section of this guide is a Conversion Reconciliation form which may used to help reconcile both Master File and Transaction File data. The form compares certain quantitative measures, for a given data item (file), on the source system vs. the target system, including:
the number of records in the file, and any records rejected during the conversion process
the total for certain key fields (balances or quantities)
The following page shows a sample of how the form should be completed.
Records counts should be readily available from on both the source and target systems. Field totals can be generated by any SQL-type query tool or report writer, or by the conversion programs themselves.
Follow-up
A follow-up process must be in place for manually entering or correcting any records which have failed to pass edits during the running of the conversions programs. These records may have missing or incorrect data items, and should also be included in the reconciliation totals.
Once all totals have been verified, a spot check of randomly selected records should be performed on the target system. All data fields should be examined on these records, including text fields which are not reflected in automated totaling. The spot checks may be done on-line (provided this does not require giving user update access) or through hard copy reports.
Conversion Reconciliation
FILE
|
Data File:
|
Date Converted:
|
Filename(s): (Source System)
|
Filename(s): (Target System)
|
|
Open A/P Items
|
October 2, 19XX
|
F87011
|
DAT031
|
|
|
|
|
DAT032
|
|
Note: The target data base uses two files to hold open A/P items.
|
|||
|
File Totals
|
Source File(s)
|
Target File(s)
|
|
|
Records in File:
|
1371
|
1355
|
|
|
|
|
||
|
Records Rejected in Conversion:
|
|
16
|
|
|
|
|
||
|
|
|
||
|
Total Records:
|
1371
|
1371
|
|
FIELD
|
Selected Field:
|
Field Name:
|
Field Description:
|
|
APONAMT
|
Open Amount
|
|
|
Note: Amount may be negative, indicating a debit memo.
|
||
|
Field Totals
|
Source File(s)
|
Target File(s)
|
|
|
|
|
||
|
Total Value:
|
612,876.15
|
607,670.15
|
|
|
|
|
||
|
Plus Total from Rejected Records:
|
|
5205.65
|
|
|
|
|
||
|
Total:
|
|
612,876.15
|
|
APPROVED: Jay Kent (A/P Mgr.) DATE: 10/3/XX
Just as the converted Master Files must be queried and examined, transaction records must also be reconciled, whether the conversion was automated or manual.
Types of Data
In a business application environment, converted transaction data might include:
Accounts Payable Items open at the conversion date
Accounts Receivable Items open at the conversion date
Open Sales Orders
Open Purchase Orders
Open Manufacturing Work Orders
General Ledger Balances
General Ledger Journal Entries (Debits and Credits)
Payroll Check and Deduction History
Most of these items involve dollar amounts in at least one data field. Therefore, the primary method of reconciling converted transaction data is to total the dollar amounts for all records before and after conversion, followed by a spot examination of all fields on random records.
Data which does not include financial totals can be reconciled through record count comparisons and individual inspection of selected records.
To further verify the integrity of the converted data items, standard reports provided by the application software should be run against the newly-loaded files. These reports, such as Trial Balances and Open Order Listings, are good sources of comparison information for reconciliation of amounts in the old and new processing environments.
Responsibility
The reconciliation work is the ultimate responsibility of user management, rather than the implementation project team. They are the ultimate owners of production data, and will have to deal with any errors or loss of data which may have occurred during the conversion.
The project team, however, must furnish the responsible user with whatever reports or system access the user requires to examine the data and compare totals without a great deal of manual effort. If system access is required, it should be on a "read-only" basis.
Once verification of all converted data is complete, and sign-offs are obtained from the responsible users, user access for input and update may be allowed. Under no circumstances should transaction data be entered into the new system until all converted data is balanced, reconciled, and verified.
This activity begins with the users taking control of the day-to-day processing on the new system solution. Once all converted data has been verified as accurate, system transactions begin to flow through the new solution, at full volumes.
Monitoring Production Data
During the early days and weeks of live system use, extra attention must be paid to monitoring the transaction volume and content. Transaction Registers, such as Journal Entry Batch Posting Reports, Cash Application Registers, Daily Order Summaries, and Inventory Balance Reports, should be run on a frequent basis.
After a few weeks of live processing, management may decide that paper copies of these reports are not needed, and they will be copied onto tape, micro-fiche or optical storage archives. However, just after conversion, the hard copies will be useful tools for verifying the flow of production data through the system, and in the event that any trouble shooting or error correction is required.
System Integrity reports should be run as often as daily during this startup period. These are reports which validate the integrity of system data in one of several ways:
General Ledger balances match the General Ledger detail (debit and credit records) for each account and fiscal period, and all accounting entities are in balance..
Open Accounts Receivable per customer match the total A/R dollar amounts in the matching General Ledger asset accounts.
There are no financial or inventory movement transactions which reference an account, customer, vendor, warehouse, inventory item or work center which is not defined in the appropriate master file.
All indexes, record keys, and pointers are pointing to a valid data record, in each file or table. (Sometimes system utilities will actually rebuild these various kinds of indexes for you, if necessary.)
Most application software packages come with reports like these, and many may be run interactively and viewed on-line.
Milestones
Several milestones will occur in the early life of any information system. For a business application environment, these might include the following:
The first few Sales Orders are picked, packed, shipped, and invoiced
The first Payroll is processed and checks are printed
The first set of Accounts Payable checks are generated
The first Customer Statements are printed
During these milestone events, the project team members need to plan to spend extra time coaching the new system users through the process. It should be expected that several hours of analysis and troubleshooting may be required at any time, a task beyond the skills of most system users.
The first few weeks after conversion are not a good time for the project team to schedule vacations, or to immediately plunge into the next system project. The need for rapid response and user "hand-holding" is a trademark of a new processing environment.
The last activity in the Conversion and Startup phase is primarily for systems generating or processing financial data. Even if the new system only feeds the financial reporting system, the first period-end requires posting, manipulating, and summarizing information from a new source, the recently converted system.
Allowing some extra time
Companies where fiscal account periods are used typically like to close each month's financial books between the 4th and 10th of the following month.
However, closing the first period under the new system will not likely proceed as smoothly as the months that follow. Therefore, expectations should be set with top management (or a parent company) that the Balance Sheet, Income Statement, and other financial reports may be a few days late the first time around.
During this time period, dependence on outside consults, brought in to assist with the implementation, should be reduced. Internal resources should assume support roles, and should retain the knowledge to carry the system through maintenance and upgrades as required. The implementation is now essentially complete.
Project Phase 2
Many software applications are simply too large to conduct all at once. In these cases a high-level outline of what a Phase 2 might contain has likely been developed and set aside.
Now is the time to review, revise and refine any plans for adding those additional applications, functionality or business units to the new software solution. If possible, a waiting period of one to three months between projects will be useful in letting the current configuration "settle down". This is also a good time to take vacations, and to identify staffing needs and schedules for the startup of a second project phase.
At the completion of all other activities in the Conversion and Startup Phase, the appropriate Quality Management Checklists need to be reviewed or completed.
Quality Management Checkpoints, end of Conversion and Startup Phase:
Review & Complete Programming and Conversion Checklist
Conversion Reconciliation
FILE
|
Data File:
|
Date Converted:
|
Filename(s): (Source System)
|
Filename(s): (Target System)
|
|
|
|
|
|
|
|
|||
|
Note:
|
|||
|
File Totals
|
|
Source File(s)
|
Target File(s)
|
|
|
|
|
|
|
Records in File:
|
|
|
|
|
|
|
|
|
|
Records Rejected in Conversion:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Total Records:
|
|
|
|
FIELD
|
Selected Field:
|
Field Name:
|
Field Description:
|
|
|
|
|
|
Note:
|
||
|
Field Totals
|
|
Source File(s)
|
Target File(s)
|
|
|
|
|
|
|
Total Value:
|
|
|
|
|
|
|
|
|
|
Plus Total from Rejected Records:
|
|
|
|
|
|
|
|
|
|
Total:
|
|
|
|
APPROVED: DATE: