<<Back

Converting Utility Billing System Data Files

 

If your utility agency is planning to implement a new system now or some time in the near future, you may be concerned about moving data from your current system into your new system. Technology Consultants, Inc. has been doing utility billing and financial system data conversions since 1996.  This article is to share with Association members some of the things we have learned that may help avoid pitfalls common to many data conversions.  There are a number of common problems that can be avoided with informed pre-conversion planning.  There are also some questions which, asked at the right time, can be a great asset to the utility agency.

 

Data conversions create problems just by their nature of moving data from one system to another.  The first and often, biggest problem is data integrity.  A new system is only as good as the data that gets moved into its files.  If the data from the old system has errors or is less than accurate (based on the new system's parameters), the data will not get better when it is moved into the new system.  It may in fact, get worse.  Frequently, vendors who sell and install software do not know the right questions to ask that will help a utility agency identify and resolve data integrity problems in their old system.  It is therefore incumbent upon the utility to understand and resolve data integrity issues before the conversion begins.

 

One solution is for the utility to bring all data in the old system to a consistent level of completeness and accuracy.  This means fixing known data problems that someone in the office has developed a way to work around rather than fix.  The new system will not have the facility to handle workarounds.  For example, we recently converted a billing system that was supposed to have 6000 customers.  The conversion file had 23,000 customers which was a real surprise to the utility agency.  After a brief discussion they realized the file had never been purged of old customers.  We encouraged them to purge old customers and related history.  The cost to purge was minimal.  The resultant conversion was 12,000 customers instead of 6,000 and gave the utility an excellent converted file for their new system.  The file included information on customers they unknowingly would have lost had we converted only the original 6000 accounts.

 

Other problems occur when the utility fails to communicate necessary information to the conversion team.  Frequently this happens because the information is obvious to the utility but not to an outsider.

 

As Stephen R. Covey teaches, it is important to "begin with the end in mind".  For a data conversion this means to identify what you expect from the conversion and to document HOW you will know your expectations have been met.  Balancing the new system against the old system is an obvious step but is frequently misunderstood.  There will always be balancing differences so one must identify them and how they will be resolved.  For example, a system that does not contain transactions for late penalties in the history file but does include those fees in the individual account balances, creates a balancing nightmare for the unsuspecting conversion team.  One solution is to decide ahead of time that all late penalty fees from the old system will be lumped into one reconciling transaction per customer.  Determine what that amount will be per customer and in total.  Then determine and document the resulting error in the history and how it will be handled.  When it comes time to balance, this information will save the conversion team hours of needless work.

 

Other examples could be cited but the point is clear.  Planning and preparing for a conversion will make it go smoother and take less time.  For those who are concerned about taking extra time for this planning and preparation work, let me refer you to research done on this very subject some time ago.  It clearly demonstrated that when changes are made in systems design after programming has started, the cost will be several times greater than changes that are made during the design phase and before programming begins.  Similarly, the design work for conversions will solve problems at a fraction of the cost of finding problems during the conversion itself.

 

KW Norris

Technology Consultants

1999