A customer information system is vitally important to every utility; and a new CIS is chosen carefully. Most utilities go through a fairly formal process of analysing their needs, identifying possible vendors, evaluating systems, and eventually selecting a system that meets their needs at a competitive cost.

But many utilities do not extend their analysis to determining what it will actually take to implement the CIS system. Since this is (at least we hope it is) a once-in-a-lifetime event, the utility business and technical managers will generally have little experience to draw on. CIS system vendors are knowledgeable about their own products, but often have little experience of the specifics of implementing their products into a utility’s unique business and technical environment.

A CIS implementation project requires expertise and commitment from almost every part of the organisation; it is often the largest software project that a utility will undertake. Given these factors, it isn’t surprising that many, if not most, utilities underestimate the time and costs of implementation.

There is a set of activities that will have to be performed to implement a CIS, no matter how large or small the utility may be and no matter what CIS software is chosen. These activities are:

  • Configuration
  • Interfaces
  • Data Conversion
  • Change Management and Training
  • Test.


Configuration is the customisation of the software to meet the needs of a specific utility. Most modern CIS ‘packaged’ systems are table-driven. Table-driven configuration consists of setting values in tables that direct the software to perform in a certain way. This can be complicated; one CIS I worked with had about 600 tables, 400 of which were configuration tables. Table-driven configuration is generally the responsibility of the utility, with help from the vendor. While it doesn’t require actual programming knowledge, it does need highly developed analytical ability, attention to detail, and specific business knowledge. Table-driven configuration is usually not intuitive and may be poorly documented, because it tends to be specific to each utility.

Configuration can also be achieved by plug-ins or application program interfaces (APIs) where custom code is inserted to meet the special needs of the utility. This is typically done when the CIS needs significant functional changes that cannot be accomplished with table-driven configuration. Linking up a utility’s interfaces is often done using this method. The plug-ins are maintained and compiled separately from the CIS, to allow standard upgrades to occur without disturbing the plug-in customisation. They are written either by the vendor or by the utility using a standard computer language.

Configuration can also be achieved by inserting the custom code into the CIS itself, so that it becomes an integral part of the system. This is usually done when very large changes are required, or when the utility intends to maintain the CIS without help from the vendor. This is generally the responsibility of the utility. Its advantages are execution efficiency and a more coherent technical design, but it should only be undertaken by a utility that has programming staff capable of understanding and maintaining the system.

Configuration can also be achieved by a combination of table-driven, plug-in, and custom code configuration. Before the CIS purchase, the utility and the vendor should discuss the types of configuration offered, and decide what method(s) will be used.


Interfaces are the systems external to the CIS that must exchange data with it. The term interface is used to refer to the external system itself, and to the link between the external system and the CIS. Some typical interfaces for a utility are meter reading, payment processing, credit/collection follow up, outage management and field service orders. Reworking interfaces to fit with a new CIS can often be one of the most difficult and time-consuming parts of a CIS implementation. A utility can have as many as 50 to 60 interfaces. Each one must be analysed to determine if it is still needed and how its functional and technical design must change. Often functionality that was part of an interface is now part of the new CIS; alternatively, a CIS is lacking a function that now must be provided by an interface.

CIS implementation

Interfaces can be real-time (where data is passed between the interface and the CIS immediately) or batch (where the data is saved up and passed at specific points in time). Specialised interfaces may need to be linked up through custom code. Integration software (referred to as EAI, enterprise application integration, or AI, application integration) can be purchased to standardise and sometimes simplify the implementation of interfaces. Some CIS vendors have partnerships with the vendors of common utility interfaces such as meter reading or CRM (customer relationship management) where there is a standard interface between the two products. However, it is usually the responsibility of the utility to design and program the interfaces.


Data conversion is the process of moving the data from the legacy into the new CIS system. This is probably the most visible and sensitive task in the implementation plan and is often the longest running activity, as well as being a common source of problems after implementation.

The first step in data conversion is data mapping – the legacy system data must be analysed to determine where it will be placed in the new system. Since the old and new systems are often very different, the legacy data may have to be edited or transformed to fit properly into the new system. For example, it is common that customer financial information such as balances, payments, and account receivable totals will be stored very differently in the new CIS, requiring complex programming, audits, and controls to ensure correctness.

Typically some legacy data will have been corrupted or lost its meaning over time, and activities to clean it up must be undertaken. Data mapping and data cleanup are the responsibility of the utility, often with the help of the CIS vendor, who knows the new system’s data requirements.

The actual process of moving the data from one system to another can be done by writing special programs to change, edit, and move the data automatically, or by executing transactions within the new CIS itself to build the database. Many CIS vendors provide data conversion utilities for their products, and tools are also available from third-party vendors. However, these tools do not do the actual analysis upon which data mapping depends; this must be done by experts who understand both the legacy data and the new system’s data structures. Prior to purchasing a CIS, the utility should be aware of the conversion tools provided by the vendor and should negotiate the level of support the vendor will provide to data conversion.

Conversions can be done all at once (big bang) or over time (phased). Generally big bang is technically more simple and less expensive; it is also perceived to be more risky.


Change management refers to all the activities needed to prepare the organisation for the new CIS, including training, publicity, business process and organisational changes. It is the utility’s responsibility. The complexity depends on the amount of change the new CIS will introduce, and the utility’s size and culture. The CIS vendor should provide documentation to support user training and technical training.


Testing consists of executing the CIS to make sure it works as it was designed and supports the business needs. The CIS vendor should have performed unit, integration and system tests prior to selling it to the utility. The vendor should be able to provide the utility with system test cases (the situations that were tested) and the test results (what happened when those test cases were executed). During the implementation process, the vendor should execute a second system test that includes all plug-ins and customised code it has written for the utility.

A complete test must be done at the utility’s site, executed by an experienced test team, using the utility’s own equipment, interfaces, configurations, converted data, revised business processes, and a rigorous set of test cases and conditions. It is time-consuming and expensive, but is the only way to be sure the CIS will support the utility’s business needs. Ideally this test is a joint effort between the CIS vendor and the utility, but it can be accomplished by the utility without the vendor’s help.

A user acceptance test is a subset of the system test that focuses on the deliverables provided by the CIS vendor. It is often a contractual acceptance of the CIS, and is the responsibility of the utility. While it need not be as comprehensive as the system test, it must include enough of the utility’s configurations, converted data, and equipment to ensure that the system will meet the utility’s needs.

A CIS implementation can take from several months to several years, depending on the extent of the changes, the size of the utility, and the number of other subsidiary projects (such as upgrades to interfaces) that are undertaken simultaneously. Other utilities of similar size, rather than the CIS vendor, are the best sources of help in estimating the project length. It is common for some implementation activities such as data cleanup and additional customisation to continue even after the CIS is put into operation – be sure to include these in your estimates.

No two CIS implementations are alike, but the activities described here are always needed in some shape or form. Installing the CIS system itself is the easy part; a general understanding of all these activities will aid the utility manager in the choice of a CIS, as well as help to develop a clear picture of the true cost of its implementation.