HomeMy WebLinkAbout4 - Final Report Utility Rate Structure and Billing System Evaluation Study - Volume 2
City of Boulder
Final Report
Utility Rate Structure and
Billing System Evaluation Study
Volume 2 – Utility Billing System Evaluation
Prepared by
Economic and Engineering Services, Inc.
In Association with Langham Consulting
January 16, 2004
Ms. Joanna Crean
Ms. Carol Linn
City of Boulder
Department of Public Works
1739 Broadway
Boulder, Colorado 80306
Dear Ms. Crean and Linn:
Subject: Volume 2 – Evaluation of Utility Billing System; Project #3-03-197
Dear Ms Crean and Linn:
Economic and Engineering Services, Inc. (EES), in association with Langham Consulting
Services, Inc. (Langham) were retained by the City of Boulder to provide a comprehensive
evaluation of the city’s water rate structures and utility billing system. This volume represents
the culmination of Langham’s efforts to review the city’s utility billing system. Volume 1, the
companion volume to this study, provides the comprehensive evaluation of the city’s water rate
structure.
This report discusses our approach, findings, conclusions and recommendations concerning the
city’s utility billing system. We have developed this report based upon our review of the city’s
current billing system and a business process review. Langham has also conducted a “buy versus
build” analysis and a peer review of the billing systems of other comparable water utilities.
We appreciate your contributions and assistance, along with that of the city’s management team
and the Water Resources Advisory Board (WRAB), in the development of this report. Thank
you for the opportunity to provide this technical assistance.
Sincerely,
LCS,I.
ANGHAM ONSULTINGERVICESNC
Gary Thorson, Ph.D.
Principal
GT:smn
Contents
Definitions
1 Introduction and Overview of the Study
1.1 Introduction.........................................................................................................1-1
1.2 Goals and Objectives in Reviewing the City’s Utility Billing System...............1-1
1.3 Overview of the Approach Used to Conduct the Study......................................1-1
1.4 Overview of the Volume 2 Report......................................................................1-2
1.5 Summary.............................................................................................................1-2
2 Overview of the Current Utility Billing System
2.1 Introduction.........................................................................................................2-1
2.2 Customer Base....................................................................................................2-1
2.3 Description of the Current Billing System..........................................................2-1
2.4 Summary.............................................................................................................2-2
3 Business Process Review
3.1 Introduction.........................................................................................................3-1
3.2 Overview of the Approach Used.........................................................................3-1
3.3 Overview of the Current Utility Business Process.............................................3-1
3.4 Summary.............................................................................................................3-5
4 Potential Enhancements to the Current Billing System and
Business Process
4.1 Introduction.........................................................................................................4-1
4.2 Potential Billing System and Business Process Enhancements..........................4-1
4.3 Summary.............................................................................................................4-5
5 “Buy Versus Build” Analysis
5.1 Introduction.........................................................................................................5-1
5.2 Building or Enhancing a Custom System...........................................................5-1
5.3 Purchasing a Vendor Supplied System...............................................................5-3
5.4 Costs and Considerations....................................................................................5-5
5.5 Summary.............................................................................................................5-8
Contents i
City of Boulder—Volume 2—Utility Billing System Evaluation
6 Peer Comparison
6.1 Introduction.........................................................................................................6-1
6.2 Overview of the Peer Utilities.............................................................................6-1
6.3 Review of Systems Being Utilized.....................................................................6-2
6.4 Lessons to be Learned from the Peer Review.....................................................6-4
6.5 Summary Matrix of the Peer Review..................................................................6-5
6.6 Summary.............................................................................................................6-8
7 Review of the Rate Structure Alternatives and Billing
System Vendors
7.1 Introduction.........................................................................................................7-1
7.2 Review of Potential Vendors..............................................................................7-1
7.3 Rate Structure and Billing System Considerations.............................................7-1
7.4 Overview of the Rate Structures.........................................................................7-3
7.5 Ease of Use/Maintenance..................................................................................7-11
7.6 Wastewater/Stormwater/Flood Management....................................................7-11
7.7 Cost Estimates...................................................................................................7-11
7.8 Summary...........................................................................................................7-12
8 Billing System Evaluation Recommendation
8.1 Introduction.........................................................................................................8-1
8.2 “Buy versus Build” Recommendations..............................................................8-1
8.3 Potential Vendors................................................................................................8-2
8.4 Summary and Next Steps....................................................................................8-3
Contents ii
City of Boulder—Volume 2—Utility Billing System Evaluation
Computer/Utility Billing System Definitions
3TC/SA
– A 3 tier client/server application is an application
IER LIENTERVER PPLICATION
program that is organized into three major parts, each of which is distributed to a different place
or places in a network. The three parts are the workstation or presentation interface, the business
logic, and the database and programming related to managing it.
AMR(AMR)
– Water meters that have a disked installed in the meter
UTOMATEDETER EADING
pit lid or box located near the meter pit can be read via a radio signal by meter technicians.
BP
– A batch job is a program that is assigned to the computer to run without
ATCHROCESSING
further user interaction. In some computer systems, batch jobs are said to run in the background
and interactive programs run in the foreground.
CIS(CIS)
– Similar to a utility billing system but a CIS product
USTOMER NFORMATIONYSTEM
focuses more on customer information.
C/SE
– A client/server environment describes the relationship
LIENTERVERNVIRONMENT
between two computer programs in which one program, the client, makes a service request from
another program, the server, which fulfills the request.
CBOL(COBOL)
– A programming language which was
OMMONUSINESSRIENTED ANGUAGE
the first widely used high-level programming language for business applications.
IVR(IVR)
–A system that allows customers to access account
NTERACTIVE OICEESPONSE
information via telephone.
P
– A billing calculation that is performed when a customer’s consumption falls into
RORATION
two different time periods (e.g. winter price and a summer price) or when there is a change in
consumption block sizes between two time periods. The customer’s bill must be calculated
(prorated) to reflect the portion of the consumption that occurred in the first time period and the
remainder in the second time period. The prorated consumption in each time period is then
charged (priced) at the appropriate rate for that time period.
RTP
– Real time is a level of computer responsiveness that a user senses as
EAL IMEROCESSING
sufficiently immediate or that enables the computer to keep up with some external process (e.g.
present visualizations of weather as it constantly changes). Real time describes a human rather
than a machine sense of time.
Computer/Utility Billing System Definitions
City of Boulder—Volume 2—Utility Billing System Evaluation
Section 1
Introduction and Overview of the Study
1.1 Introduction
Economic and Engineering Services, Inc. (EES) and Langham Consulting Services, Inc.
(Langham) were retained by the city of Boulder to provide a comprehensive evaluation of the
city’s water rate structures and utility billing system. In providing this review, a two-volume
report has been developed. Volume 1 discusses the evaluation of the city’s water rate structure.
Volume 2 discusses the review and evaluation of the utility billing system.
1.2 Goals and Objectives in Reviewing the City’s Utility
Billing System
The city had multiple goals and objectives in evaluating the utility billing system. Provided
below is a listing of these goals and objectives.
Provide a detailed review and evaluation of the relevant business requirements needed in the
utility billing system, regardless of the rate structure selected.
Assist the city in an evaluation and analysis of software and vendor options, which meet the
city’s overall needs, and are also capable of billing the proposed rate structure(s).
Provide a well-written report of the findings, conclusions and recommendations associated
with the evaluation of the city’s billing system.
In conducting this study for the city, the approach used to review the city’s utility billing system
was designed specifically to meet the above goals and objectives.
The city’s present utility billing system was developed in-house in the early 1980’s. The present
utility billing system has served the city well over the years. However, during the drought of
2002, the limitations of the present billing system came to light as alternative rate structures were
suggested to encourage more efficient use and conservation of water. The purpose of this study
was to review the city’s existing billing system, business processes, and the potential alternatives
available to the city to upgrade/update their utility billing system.
1.3 Overview of the Approach Used to Conduct the Study
A logical and systematic approach was used to review the city’s current billing system and the
alternatives available to upgrade/update their system. The first step of this process was to gain
an understanding of the city’s existing utility billing system hardware and software applications.
To that end, Langham conducted a business process review. The objective of a business process
review is to conduct an assessment of each functional area that utilizes the billing system. As
part of the business process review, interviews were conducted with city staff to better
Introduction and Overview of the Study 1-1
City of Boulder—Volume 2—Utility Billing System Evaluation
understand the city’s business process and functional requirements. From that review, the
business processes and workflow for the city can be documented. This is a very important task
since any new utility billing software must be able to meet the city’s functional requirements, or
the city must be willing to change their business process to adapt to the new billing software.
The information collected in the business process review will be used by the city as they move
forward after this study with the issuance of a Request for Information (RFI) to software
vendors.
In addition to the above, a “build vs. buy” analysis was undertaken. The objective of this
analysis is to review the advantages and disadvantages of building a custom system versus
buying packaged software. This includes an analysis of the potential cost of each option.
In order to gain a better understanding of the utility billing system software practices of other
utilities, a peer review was conducted. One of the objectives of this study was to consider the
“water budget” rate structure alternatives as discussed in Volume 1. In conducting the peer
review, particular emphasis was placed upon contacting those utilities with water budget rate
structures to gain a better understanding of the utility billing applications used at those utilities.
Based upon Langham’s industry knowledge of current vendor software, a review was undertaken
of each of the final water rate structures and the utility billing software implications of each, and
the potential vendors that may be able to meet the city’s requirements (i.e. off-the-shelf) for each
rate structure.
Finally, given the above research and analysis, a set of findings, conclusions and
recommendations have been provided on the utility billing system.
1.4 Overview of the Volume 2 Report
This report is designed to document the approach used to evaluate the city’s utility billing
system. Section 2 provides a brief overview of the city’s current billing system. Next, Section 3
provides a brief summary of the business process review undertaken for the city. Section 4
follows this discussion by detailing possible enhancements to the city’s current billing system
and business processes. Section 5 then compares the advantages and disadvantages of the “buy
versus build” scenario and the estimated costs associated with each approach. Section 6 provides
a summary of the peer review undertaken of the billing systems used by other comparable
utilities. Next, Section 7 provides a review of the various rate structures that the city is
considering and discusses the potential issues associated with vendor provided billing software.
Finally, Section 8 provides the summary recommendations for this volume of the study.
1.5 Summary
This section of the report has provided a brief overview of the report prepared for the city
reviewing the city’s utility billing system. The next section of the report will provide a brief
overview of the city’s present utility billing system.
Introduction and Overview of the Study 1-2
City of Boulder—Volume 2—Utility Billing System Evaluation
Section 2
Overview of the Current Utility Billing System
2.1 Introduction
The present utility billing system has served the city well over the years. However, during the
drought of 2002, the limitations of the present system came to light as alternative rate structures
were suggested to encourage more efficient use and conservation. Unfortunately, the present
billing system did not have the capability to bill customers using those specific rate structures.
This section of the report will provide an overview of the city’s current utility billing system.
2.2 Customer Base
The city’s water utility provides services to approximately 110,000 residents within and
immediately surrounding the city limits. This translates to approximately 28,000 billing
accounts. At the present time, utility billing accounts are established in one of five customer
classes. The present customer classes are:
Single-family residential;
Trailer parks & districts;
Multi-family residential;
Commercial/industrial; and
Irrigation or sprinkler.
Approximately 72 percent of the city’s accounts are billed as single-family residential. The
University of Colorado is located in Boulder with a student enrollment of approximately 25,000.
Approximately one-half of the properties within the city of Boulder are rental properties.
2.3 Description of the Current Billing System
The city’s utility billing system is an in-house application that was originally developed in the
early 1980’s and it was modified to run in a client/server environment in 1997. The city’s
current utility billing system is a 3-tier client/server application. The system bills, records
payments, and tracks consumption for all water, wastewater, and stormwater/flood management
customers. The current system also records meter inventory and maintenance information.
The billing application uses a combination of real-time update and batch processing. Oracle
Forms 6 modules make up the graphical user interface (GUI) for the bulk of the application. All
data for the current application is stored in an Oracle database that resides on a UNIX (AIX)
server. Batch processing runs nightly and consists of a variety of MicroFocus COBOL
programs. A web application has been developed using html/JavaScript and Java 1.2 programs
Overview of the Current Utility Billing System 2-1
City of Boulder—Volume 2—Utility Billing System Evaluation
for processing credit card payments. The web application updates the database nightly prior to
the start of batch processing.
Reports from the billing system are primarily generated using COBOL for daily, weekly and
monthly process reporting and Oracle (using Discoverer) for immediate request reporting. The
billing system is supported in-house by the city’s information technology staff. In some
instances, support is contracted with an outside vendor depending on the scope of the project,
staff skill set, staff resource availability, and project timeframe.
2.4 Summary
This section of the report has provided a brief overview of the city’s existing utility billing
system. The next section of the report will discuss the business process review that was
undertaken for the city.
Overview of the Current Utility Billing System 2-2
City of Boulder—Volume 2—Utility Billing System Evaluation
Section 3
Business Process Review
3.1 Introduction
One of the first steps in evaluating the need for any new utility billing system software is to gain
an understanding of the current business process. The business process is documented such that
it will enable the city to communicate to potential vendors the specific software requirements
needed to meet the city’s business process (i.e. functional requirements).
This section of the report will provide a summary overview of the business process review
undertaken by Langham as a part of this study. It should be noted that the discussion provided
within this section of the report is at a summary level. Langham has provided the city a more
detailed business process (functional needs) document that is suitable for vendor distribution and
vendor evaluation purposes.
3.2 Overview of the Approach Used
In developing the business process review, Langham obtained data and information in two
distinct and different ways. The information was obtained through written documentation
provided by the city of Boulder, as well as personal interviews conducted with city staff. These
interviews were conducted as a part of a utility billing system functional needs analysis.
Software functional requirements were developed in the context of the city’s current utility
business processes and industry standard practices. One of the primary goals of this project was
to assess the benefit of potentially replacing the city’s current utility billing system either through
in-house development or with a state of the art “off the shelf” Customer Information System
(CIS) product provided by any one of the industry’s leading vendors. The functional needs,
developed as a part of the business process review, form the basis for this evaluation process.
3.3 Overview of the Current Utility Business Process
Provided below is a summary overview of the city’s current utility billing system business
process. To more clearly illustrate the workflow, the business process description is divided into
functional areas.
3.3.1 Monthly Utility Rates and Fees
The city has three utilities that are billed using the city’s present utility billing system. Provided
below is a brief conceptual overview of the rates for each of the utilities.
Business Process Review 3-1
City of Boulder—Volume 2—Utility Billing System Evaluation
Water Rates
– In 1988, the city adopted its current rate structure, an increasing block rate
structure, in which charges are composed of two parts, a fixed service charge and a consumption
charge based upon metered usage. The service charge is based upon whether the account is
inside or outside the city and by meter size. The service charge is designed to recover costs for
meter reading, maintenance, billing, collection and other costs attributable to each customer
regardless of quantity of water used. The consumption charge consists of three different blocks
of rates and may vary between customer classes. As the amount of water use increases and
moves into the next rate block, the cost per thousand gallons of water increases. The breakpoints
for the rate blocks are determined using each customer’s average winter consumption (AWC).
The AWC is the average consumption as reflected on a customer’s December through March
bills. The present rate structure has capped the AWC at 8,000 gallons/month.
Wastewater Rates
– Wastewater charges consist of a monthly service charge, based on meter
size, and a volumetric (flow) charge. Both the service and volumetric charges vary by inside city
or outside city classification. The customer’s AWC is used to calculate monthly wastewater
charges April through Novemeber. Actual consumption is used to calculate monthly wastewater
charges December through March. In addition, customers with above average strength sewer
discharges are assessed excess strength charges. These excess strength charges do not appear on
the monthly utility bill, but are billed separately through the city’s finance system.
Stormwater & Flood Management Rates
– A monthly stormwater and flood management fee is
assessed to all properties within the city limits to recover operation, maintenance and
replacement costs of the existing stormwater system and construction of new storm drainage and
flood control facilities. For single-family residential customers the fee is assessed based upon
property lot size. For all other customers the fee is calculated based on an equation that utilizes
total property area and impervious area.
3.3.2 Billing Process
Currently the city bills for water, wastewater, and stormwater/ flood management services on a
monthly basis. There are approximately 200 meter read areas throughout the city. Meters are
read throughout the month and the data is uploaded into the billing system for bill generation.
Each meter read area that is loaded into the system is visually checked and validated against a
number of criteria, such as zero reads and high/low variance, before being manually released for
billing. The billing system is capable of (limited to) receiving and billing 18 read areas per
night.
Bill Printing
– Using the prior day’s meter read data, the billing system generates an electronic
billing file that is sent to an outside vendor for printing and mailing of invoices, including
verification of zip codes. The same bill format, including billing messages and enclosures, is
used for every customer class of service (e.g. single-family, commercial, etc.).
Payment Process/Cash Receipting
– The city receives payments in several ways and the billing
system identifies the method of payment on each account. Payments receive a transaction source
designation as they are posted to the individual accounts. Starting with the largest number of
transactions, the payment processes include:
Lockbox processing center –
Approximately 18,000 payments per month are processed by a
lockbox processing center at the city’s bank and deposited into the city’s bank account. On a
Business Process Review 3-2
City of Boulder—Volume 2—Utility Billing System Evaluation
daily basis, the processing center sends the city an electronic file that lists payments,
including amount and account number. This payment information is uploaded into the
billing system and posted to the appropriate account.
Automated withdrawal from checking or savings accounts –
Customers can fill out a
form authorizing the city to withdraw payment from their bank accounts for their monthly
utility bills. The billing system maintains pertinent information such as the bank ABA
number, bank account name and number, prenote date, first draft date, and the last date a
payment was withdrawn from the bank account. An electronic file is sent to the bank that
has the customer’s bank account number(s) from which to withdraw payments. A stop
payment may be put on the withdrawal if there is a question about the bill.
Recurring credit card payments –
Customers may fill out a form authorizing monthly
collection (payment) of their utility bill via a credit card. A program is run nightly to
determine which accounts should have a payment charged to their credit card. An outside
vendor processes the city’s request to have payments charged to the credit cards and deposits
the collected funds into the city’s bank account. The billing system has a screen that
identifies all credit card transactions that have occurred, or that have been attempted, along
with an approval/denial code. A daily report identifies any failed transactions and the reason
for the failure. A monthly program identifies accounts that cannot be processed because of
the expiration date on the billing system, or accounts that are on hold. Currently, credit card
payments may be made using either VISA or Mastercard, which utilize the State’s credit
card contract. American Express is part of the State’s credit card contract, but it has not yet
been implemented by the city.
E-Lockbox or on-line banking
– The city also accepts payments by e-lockbox or on-line
banking. The receipt of these payments was automated in December 2003. Prior to this date
these payments were processed manually. Approximately 1,000 accounts use this payment
option.
Manual processing –
The utility billing office can receive payments by mail or accept
payments at the walk-in customer service window. Payments that the lockbox processing
center cannot process are also handled by staff in the utility billing office. These consist of
payments that do not include remittance stubs or account information. Manual receipts are
created for those payments without remittance stubs. The city averages 600 to 700 manual
payments a month. The billing office receives notice when a check, ACH or credit card
payment is returned for non-sufficient funds. The staff manually reverses the payment on
each account and charges that account with a return payment fee.
Telephone call-in of credit card number for immediate payment –
When a customer calls
in with credit card information, the credit card transaction is processed immediately, while
the customer is on the phone. This gives the billing staff member the ability to know right
away if there is a problem with the customer’s credit card. The application of the payment to
the customer’s account occurs as part of a nightly batch process. All individual transactions
that occur during the day are accumulated and applied at night.
Electronic Funds Transfer (EFT) –
The city has some federal government accounts that
pay their utility bill via EFT. The bank notifies the city of these transfers by e-mail and the
payments are manually entered into the billing system.
Business Process Review 3-3
City of Boulder—Volume 2—Utility Billing System Evaluation
3.3.3 Credit and Collections
Although collections are an important financial function to the city, the city does not turn unpaid
accounts over to a collection agency. Instead, the city annually certifies unpaid utility bills to the
county for inclusion on property tax bills of the specific property. The billing system produces a
report that identifies accounts that are to be certified. These certified accounts are considered a
lien on the property and are paid to the city by the County Tax Collector either upon payment by
the owner of their property taxes, foreclosure of the property, or payment by the owner prior to
foreclosure. Throughout the year the city uses multiple techniques to avoid the certification
process. These include but are not limited to the following:
Courtesy reminder letters –
The city does not currently charge interest or late fees on past
due accounts. The billing system generates courtesy reminders when a customer’s account is
two months plus ten days past due. The courtesy reminders are sent to the payer on the
account and also to any “notify” persons (e.g., property owners or property managers). An
electronic file is sent to the outside bill processing vendor, where the reminder letters are
printed and mailed out.
Final notice letters –
The billing system generates final notices when a customer’s account
is three months, plus ten days past due. Prior to generating the letters, a report is produced
which lists all accounts that fit the parameters for final notice letters and a fee and turn-off
date are placed on the account. City billing staff reviews this list and a notation is made on
the “comment” screen identifying that the account has been sent a final notice. The day after
the final notice report is generated, letters are sent out to the payers on the accounts. Letters
are also sent to anyone designated on the “notification” screen for the account. Final notice
letters are printed and mailed in-house.
Payment agreements –
In those instances when a customer cannot pay their outstanding bill,
a payment agreement is established to allow the customer to pay over time. The billing staff
designates when a payment agreement is in effect on an account. This prevents reminder
notices or final notices from being generated. An indicator identifies when this feature is
active on an account.
“Cash Only” designation –
An account can be designated as “cash only” due to a history of
non-sufficient fund check returns. The current system has an indicator that immediately
identifies the account as “cash only.”
Bankruptcy –
An account can be designated as being in bankruptcy. This status prevents
any reminders/notices from being mailed and alerts staff to the special handling that is
required with these accounts.
3.3.4 Customer Service
There are currently three full-time billing service representatives and one full-time supervisor
that support the city’s utility billing operations. The billing service representatives are available
via the walk-up window or telephone. Customers can connect directly with a representative or
they can use the Interactive Voice Response (IVR) system that allows customers to access
account information via telephone. The current system is accessed by entering an account
number and mailing zip code. The information provided to the customer includes the following:
Current balance;
Last payment and payment date;
Business Process Review 3-4
City of Boulder—Volume 2—Utility Billing System Evaluation
Last meter reading date;
Last bill amount and date;
History of payments (last five payments and dates and last five bills and dates); and
An explanation of how bills are calculated and current rates.
The billing system currently maintains seven (7) years of billing data that can easily be
referenced for billing questions.
3.3.5 Meter Field Service/Work Orders
The final functional area of the business process review was the meter field service/work orders.
This is discussed in detail below.
Meter Reading
– The city has Badger water meters and uses the Badger automated meter
reading (AMR) system to read meters via radio frequency. To date, the AMR system has been
installed on approximately 98% of the city’s meters, including all single-family residential
accounts. The billing system interfaces (downloads) to populate the AMR system with customer
account numbers, prior meter read information, meter locate information, and transponder
numbers so that automated reading can occur. Some customer accounts have not yet been set up
on the AMR system. For these accounts, the billing system downloads the account information
into hand-held devices (ITRON) that are used to read these meters. Once the meters are read, the
data from the AMR and hand-held devices is uploaded into the billing system to generate bills.
Meter Inventory
– The meter inventory is also maintained within the billing system. Meter
numbers are cross-checked when setting up new billing accounts. The billing system prevents
duplication of meter numbers and issuance of incorrect meter numbers.
Meter Maintenance
– The AMR transponder number, installation date, and the change battery
due date are also recorded on the meter maintenance screen within the billing system. As with
the meter number, the billing system does not allow for a user to enter the same transponder
number for two different billing accounts. The transponder installation date is used in
determining the replacement date for the AMR battery, although this date can also be manually
changed.
Work Orders
– The billing system also generates work orders for meter re-reads, turn-offs, turn-
ons, repairs, etc. and maintains maintenance history related to the meters. The work orders can
be created in the billing system by billing staff or the meter readers themselves.
3.4 Summary
This section of the report has discussed the business process review that was undertaken as apart
of this study. The objective of this review was to determine the functional needs of the city for
their software requirements. While this section of the report has provided a brief overview and a
summary of the process used and the findings, a more detailed document discussing the city’s
business process review and functional needs analysis has been provided to the city staff. This
document is suitable for purposes of the issuance of a Request for Information (RFI) to software
vendors.
The next section of the report will discuss the potential enhancements to the current billing
system and business process.
Business Process Review 3-5
City of Boulder—Volume 2—Utility Billing System Evaluation
Section 4
Potential Enhancements to the Current Billing
System and Business Process
4.1 Introduction
The initial tasks of this study focused on the review of the city’s current billing system and the
business process review. From those tasks, a detailed understanding was gained of the
capabilities and limitations of the city’s current billing system. At the same time, the business
process review provided an understanding of the flow of work and the requirements that need to
be met by any new billing system software.
4.2 Potential Billing System and Business Process
Enhancements
After an extensive review of the current utility business process, it was evident that there were
several areas in which a change to the current utility billing system could potentially benefit the
city. Below is a description of some of these possible enhancements to the current billing system
and business process. The discussion below only includes those enhancements that are
considered most beneficial or significant. Therefore, this list of enhancements is not meant to be
all encompassing. The possible enhancements are grouped according to the functional areas that
were used in the previous business process discussion.
4.2.1 Monthly Utility Rates and Fees
One of the main objectives of this study was to review alternative rate structures and the billing
systems capable of handling those structures. One of the constraints of the city’s current billing
system is the lack of flexibility in changing the rate structure within the billing system. This
potential enhancement is discussed in more detail below.
Increase Flexibility and Ease of Changing Rates
–Many CIS products will give the city greater
flexibility in implementing changes to the rate structure. Currently, entering rates into the billing
system is a somewhat time consuming effort because the process is not fully automated. Rates
need to be changed, tested, and then implemented. A new CIS product would provide more
automation in changing the rates. However, this would not eliminate the need for testing to
ensure that the correct rate is used for bill calculation.
Many CIS products will also automate pre-defined rate changes. The rate structure is set once
and the system automatically moves from one rate value to the next pre-defined rate value as the
year progresses. This would be beneficial in implementing seasonal rates, where the rates change
Potential Enhancements to the Current Billing System and Business Process 4-1
City of Boulder—Volume 2—Utility Billing System Evaluation
from one season to the next. In addition, some rate changes are planned many months in
advance. Given that, current CIS systems would allow the city to enter the new rate or the new
rate structure as soon as the change has been approved with the effective dates of the change.
Many CIS products also provide the ability to prorate charges by calculating the bill using the
effective rate for when consumption occurred. For example, a rate change could become
st
effective on January 1. A customer’s bill in January would calculate any consumption from the
st
prior month at the previous rate and any consumption after January 1 at the new rate. This
proration feature would be required for all of the single-family residential water rate structures
being reviewed (seasonal and water budget). Proration would be required two times per year
under the seasonal rate structure (spring and fall period). In contrast, the water budget rate
nd
structures would appear to require proration every month due to the shaping of the 2 block.
nd
Each month, the 2 block is a slightly different size, therefore, a customer’s bill would have a
nd
portion of their consumption in the prior month’s 2 block size and a portion of their
nd
consumption in the current month’s 2 block size.
A major improvement in the flexibility of a billing system software, particularly since the
development of the city’s billing software, is that they are configurable, utilizing a table driven
structure to identify business rules. This configurable, table driven structure makes it easier for
the user to implement different rates for different customer classes, add additional billing blocks
for different customer classes or change the billing block sizes for different customer classes of
service without changing programming code.
Bill for Additional Utility Services
– As discussed in the previous section, the city charges
customers for water, wastewater, and stormwater/flood management services. At the present
time, the city’s current billing system is limited to charging for three services. Most CIS
products allow for multiple definitions of services. These could include not only specific
services like water and wastewater, but also taxes such as a transportation or trash tax. There is
also an opportunity to include other water services on the bill such as drought surcharges, meter
maintenance, etc. These charges would be defined as a separate line item on the bill, which is
something that the city’s current billing system is unable to do.
4.2.2 Billing Process
The billing process focuses on the automation of processes, master billing, bill print function and
the collection/crediting process. Provided below is an overview the potential enhancements to
the billing process.
Additional Automation
– Currently, the billing staff visually checks and manually releases each
meter read area for billing. However, most CIS systems provide on-line access to billing
exceptions. Therefore, the bills falling within normal criteria are automatically released for
billing. Since the majority of the readings are accurate and simply need to be passed through to
the billing process, this would be a time saving measure. The exceptions (i.e., those that don’t
fall within normal criteria) would continue to be manually reviewed and corrected.
Potential Enhancements to the Current Billing System and Business Process 4-2
City of Boulder—Volume 2—Utility Billing System Evaluation
Another area for additional automation includes billing adjustments. Currently, whenever
changes are made to the bill, all recalculations must be done manually. These manual
adjustments introduce an opportunity for error. In contrast to this, most modern CIS systems
provide the ability to enter a consumption adjustment and the system automatically calculates
any adjustments to month-to-date and year-to-date values in consumption, charges and financial
transactions. These system calculations are made using the same logic as the original bill.
Ability to “Master” Bill
– A large landlord or business with multiple locations may want a single
bill listed by location showing the total amount due. This is sometimes referred to as a “master
billing” or a “consolidated” bill. It is currently not possible to consolidate these bills into a
single bill. Many CIS systems can accommodate this by generating a “master” bill. In addition,
many systems allow one check that can be distributed across all of the outstanding bills for a
single customer or provide a single bill to the master location with individual bills sent to the
service location.
Flexible bill format and messaging
–At the present time, the city is limited to one bill format
for all customers. With a new billing system, the city would have the capability of customizing
bills by customer type, location (inside vs. outside city), etc. A new billing system would also
allow for different messages to be entered based upon customer type, location, etc. The current
system only allows for one message (maximum of 391 characters) to be printed in a 2 ½” by 3
1/2” rectangle on the bills.
Generate Duplicate Bills
– As a billing service representative works with a customer to resolve
billing issues, it is frequently necessary to provide a printed summary of the results. Currently,
this is accomplished by printing as many account history screens as necessary to display the
information. Alternatively, most modern CIS systems provide a feature that allows for a reprint
of the original bill or printing a revised bill after adjusting charges.
On-line Bill Review
–Once the billing information has been sent to the third-party printing
service, the current system does not allow staff to view the bill. Therefore, when a customer
calls with a billing question, city staff has to research the billing problem without actually being
able to see the document that was sent to the customer. Most modern CIS systems provide the
ability to access the actual bill image or a replica that would enable staff to more quickly and
effectively respond to customer questions.
Cashiering
– The city does not currently have a cashiering system and receipts are manually
prepared. Most modern CIS systems offer cash receipting functions within their products. This
feature gives the city the opportunity to maintain automated cash controls. Each person
receiving cash would have a running balance of cash and checks received, both at the counter
and via lockbox or mail. As the day ends, a validation of the deposit is calculated by the system
to insure proper postings of cash receipts.
Potential Enhancements to the Current Billing System and Business Process 4-3
City of Boulder—Volume 2—Utility Billing System Evaluation
4.2.3 Credit and Collections
Given the number of rental units served by the city, an improved credit history function would
greatly benefit the city. Provided below is a discussion of the possible enhancements to the
city’s credit and collection function.
Credit History
– Currently, the city tracks billing information by service location and does not
monitor or track customer (payment) activity (this is more a function of the current business
process than the billing system capabilities). However, within the “credit history” feature
provided by most systems, the city could make automated decisions depending on customer
credit history. For example, by maintaining a history on the customer, the city would have the
ability to send a friendly reminder to a customer that has never had a late payment or any other
delinquent activity. However, for the customer that habitually pays late, but stays under the 90
day mark, a different and potentially stronger letter could be produced. The potential of differing
letters (messages) is just one example of the use of the credit history. Other uses include priority
consideration during follow-up, reduced fees for negative action, or even an opportunity for a
better rate.
4.2.4 Customer Service
The ability to provide tailored communication to specific customers is a key advantage of
modern CIS systems. The areas of potential enhancement to customer service are discussed
below.
Enhanced Customer Information
–Many billing systems provide the ability to track customer
information to enable better, and more personal customer service. For example, when an
account goes inactive, the current billing system allows for active, new account, inactive (read,
no-bill), and final bill sent designation. This could be expanded, becoming more flexible with
values such as off due to delinquency, final bill pending, and vacation hold. Another feature
provided by most systems is to identify items such as, elderly, on life support, etc. which may
impact the actions taken during turn-off, work order scheduling, etc.
As part of the expanded customer service capabilities, there are opportunities to provide
informational letters and notices to keep the customer better informed. For example,
automatically generating a letter telling the customer that their credit card will expire in two
months and to please call the city to update the informationor that there is maintenance work
scheduled next week in their neighborhood. Once defined, many CIS systems automatically
produce these notices by utilizing customer information maintained within the database.
4.2.5 Meter Field Service/Work Orders
Meter reading is a critical component to the billing process. Provided below is a brief overview
the potential areas for enhancement in the area of meter reading.
Expanded Upload of Meter Reads (Areas)
– The current system only allows the field service
personnel to download/upload 18 meter read areas per day without intervention from the IT
Department. A new system would likely have the flexibility to allow an unlimited number of
meter reading uploads/downloads to support the time available.
Potential Enhancements to the Current Billing System and Business Process 4-4
City of Boulder—Volume 2—Utility Billing System Evaluation
Increase Number of Meter Reads Per Billing Cycle
– Currently, when a meter read is received
and entered into the billing system it must be billed. The ability to read multiple times
throughout the month, but bill only once, could provide more frequent water usage information
about a location. More frequent information would assist customers in monitoring their water
usage. This would be especially beneficial if the city were to select a water budget rate structure.
A key assumption of the water budget rate structure is that the customer will manage the amount
of water allocated for their needs. If more frequent “feedback” (e.g. meter reads) on their
consumption is not available, it will be difficult for customers to truly “manage” their
consumption.
4.3 Summary
This section of the report has discussed the potential enhancements and benefits from a more
modern billing system. While the city’s present system is operating properly and successfully
achieving its main task (i.e. billing the customer), the current system lacks flexibility and
automation in certain areas. As has been noted in this section of the report, an updated system
could provide benefits in the area of more efficient operations, better customer communication,
and most importantly, greater flexibility, particularly as it relates to the potential for different rate
structures.
The next section of the report will discuss the “buy versus build” analysis that was undertaken as
part of this study.
Potential Enhancements to the Current Billing System and Business Process 4-5
City of Boulder—Volume 2—Utility Billing System Evaluation
Section 5
“Buy Versus Build” Analysis
5.1 Introduction
When the current utility billing system was created, each utility maintained a large mainframe
computer and an equally large information technology (IT) staff. It required full time staff to
build and maintain the systems that were used to support the business. At the time, there
realistically was no other option. However, in today’s technical environment, the decision is not
as “clear cut.” Software vendors have been working with utilities to improve and perfect their
products since the early 1990’s. The question of whether to buy or build has become much more
complicated. In addition, there are advantages, disadvantages and risks to both options. This
section of the report will discuss the advantages and disadvantages of buying versus building a
system to support the current business processes, along with the potential changes being
discussed in the city’s rate structure and billing practices.
5.2 Building or Enhancing a Custom System
A starting point for considering the question of building versus buying is to consider the
advantages and disadvantages of building or enhancing a custom system. Provided below is a
brief listing of the perceived advantages and disadvantages of building or enhancing a custom
system.
5.2.1 Advantages of Building a Custom System
The advantages of a custom built system center around the development of a system, built to the
exact specifications and needs of the city. In this process, it is assumed that the city would need
to outsource for technical and human resources to assist the city in the development of the
software. More specifically, the advantages are as follows:
You Can Get Exactly What You Want (i.e. a custom product)
– During the design phase
of a software development project, there is a “definition” activity. As part of the “definition”
9activity, each business requirement is clearly defined and the approach is agreed upon
between the software designer and the business user (i.e. the city). Further, the data location,
format and definition are documented. Therefore, once the system is built, it should look,
act, work and produce products/reports exactly the way the city wanted it to.
Total Control of Functions/Upgrades & Timing of Enhancements
– Another advantage
of building is related to changes in business practices that may occur over time. As the city’s
business practices change or new requirements are added, these requirements can be
immediately designed and implemented on the city’s schedule. In contrast, under a “buy”
scenario, the city may be required to wait until the software vendor produces a new version
of the software.
“Buy Versus Build” Analysis 5-1
City of Boulder—Volume 2—Utility Billing System Evaluation
Control of Changes to Any Business Processes –
Since the system is designed to the city’s
specifications it will follow the exact business processes currently in place. The city will also
have the control as to any business process changes and the timing of such changes.
Outsourcing Adds a Large Group of Resources for a Short Period of Time –
Using an
external software group supplements the city’s IT resources for the duration of the project,
and provides for a more timely completion of the project. In addition, as with the use of any
outside consultant, once the project (software) is completed, the outside consulting costs are
eliminated. Any recruiting and overhead costs associated with the consulting personnel are
the responsibility of the outside software firm. Finally, the risk involved with quality and
skills of the resource remains with the outside software firm, typically assuring a more
reliable skill base.
Less Dependency on Outside Vendors –
Once the system is built, the city has the choice to
maintain and enhance internally, or it may outsource this activity. In short, the software is
owned by and controlled by the city. There is no dependency on an outside vendor to create
or change the system, assuming adequate internal IT resources and support.
5.2.2 Disadvantages of Building a Custom System
While there are a number of advantages to building a system, at the same time there are also
issues and risks associated with outsourcing the building of a system. These issues and risks are
detailed below.
Knowledge and Skills Are Retained Within the Software Development Firm –
When
outsourcing the development of a custom system, the software firm provides the technical
and design skills. The city may retain the software firm for maintenance or contract with the
firm to train internal resources. To insure that the knowledge of the city’s business processes
is retained in-house, the city would have at least one person in IT acting as a business and
development liaison that would ensure the transfer of knowledge from an outsourcing effort.
High Cost of Development and Long Development Time –
Custom systems are built from
a concept. Therefore any design, code or test must be created during the project. Current
technical tools have reduced the effort in many areas. However, as all work products are
original, the time needed to properly create them must be taken into consideration.
Higher Risk of Costs and Failure Will Have to be Absorbed –
As all work products that
are original, there is a higher risk of failure. Custom development projects must be managed
very carefully with checkpoints and detailed contingency planning. The city will be
accepting the risk of delays and rework.
High Maintenance Cost –
Whether completed internally or externally, there will only be a
few resources that can maintain the system. Therefore, those resources will be at a premium
when a problem is found or a change must be made. Given that the system is custom, the
cost will not be shared by other users, but rather, must be paid solely by the city. If
maintenance is accomplished internally, it is important to stay technically current or it will be
difficult to find resources that are qualified to maintain and update the system.
Higher Defect Rate –
As all work products that are original, it is very important to insure
testing is very thorough. Adequate time and resources should be allocated to review, correct
and re-test the software. Regardless of whether the billing system is pre-packaged or custom
“Buy Versus Build” Analysis 5-2
City of Boulder—Volume 2—Utility Billing System Evaluation
built, those systems that are developed following a methodological and disciplined approach
will have fewer defects than those developed in an ad-hoc manner.
As can be seen, the main advantages of building custom software is the amount of control over
the final design and features of the software. Counter-balancing those advantages is the potential
risk that custom software brings. These risks are primarily related to the cost of the development
of the software, maintenance of the software and the quality of the final software that is
developed.
5.3 Purchasing a Vendor Supplied System
The alternative to building or enhancing a custom system is to purchase a system from an outside
vendor. As with a custom system, there are certain advantages and disadvantages to purchasing
a vendor supplied system. Provided below is a brief overview of the advantages and
disadvantages of purchasing a vendor supplied system.
5.3.1 Advantages of Purchasing a Vendor Supplied System
The advantages of purchasing a vendor supplied system are related to the “convenience” and
technical support that comes from a software product developed with multiple and varying end
users in mind. Provided below is a brief overview of the advantages of purchasing a vendor
supplied system.
A “Best Practices” Approach to Business –
In general, vendor products have evolved and
improved over the last twenty years. There are many new vendors that have entered the
market in the last few years that have built configurable systems. These configurable
systems begin with the best practices of all those vendors/software programs previously
developed. By using a “best practices” approach, vendors minimize their initial design and
development costs and duration. In addition, as a user reviews their software requirements,
the use of “best practices” should improve the user’s business process. Finally, as industry
requirements change, the vendor retains the risks and costs of developing/updating the
product, in order to continue to meet these “best practices” requirements demanded by users.
However, if the city chooses to implement a rate structure that is not a common industry-
wide approach (such as a water budget) than the city would be part of a small group of
municipalities who are implementing this and would not be labeled as best practice.
Therefore, the city may not encounter the benefits mentioned above.
Peers Using the Same Product (User’s Group) –
As environmental and regulatory
requirements change, or as the city’s basic business practices change, it is often
helpful/useful to understand how other comparable utilities are responding to similar
situations/conditions. A software user’s group is an excellent place to share ideas,
approaches and possible solutions. Normally, the reason why a utility purchased a product is
because they have a similar “vision” as the vendor providing the product. Utilities with the
same “vision” or approach to business practices influence the product development. In
addition, during the user group meetings new techniques for using the product to solve a
business problem can be discussed and thereby implemented.
Vendor Support for Implementation & Maintenance
– Just as “best practices” are
provided by the software vendor, so is an implementation methodology. The implementation
“Buy Versus Build” Analysis 5-3
City of Boulder—Volume 2—Utility Billing System Evaluation
methodology steps the utility through a series of decisions points, asking specific questions,
to insure that the system is configured to meet the utility’s business needs. Most
implementations contain an activity whereby the current business processes are reviewed to
insure that they are still necessary or correct, given that a new software system will be
supporting the business. In addition, the vendors are very experienced with implementation,
and are capable of efficiently addressing most implementation issues as they arise. As a
result of their experience in implementation issues, steps are not missed. They have
specialists in conversion, design, modification, documentation and project management.
These specialists support the implementation and maintenance of the specific product being
provided.
A Fully Documented System –
As a system ages, the biggest challenge is to know why
something is done, or was done, within the business process or the software. Most vendor
provided system starts with a set of documentation that defines each of the standard business
processes. These processes are normally updated to the specific configuration that is
implemented. As with the business processes, there are software documentation standards
for both the base software product and any modifications that are made specifically for the
utility. In addition, any enhancements over the years are added to the documentation to
maintain a consistent set of detail concerning the utility’s software. Overall, some vendors
document in a very detailed manner while other vendors provide poor or no documentation.
This is simply a function of the method and discipline of each software firm.
Technology Upgrades –
Technology is rapidly changing. Some vendors focus on keeping
their products current with technology. These operating system and database vendors require
their customers to operate on current releases to maintain support. Vendor software
purchases include a provision for yearly maintenance. This maintenance normally includes:
service calls and questions, issue resolution, and product upgrades, both functional and
technical. The vendor retains the cost and risk to insure that their software is compliant with
the latest releases of technology.
Relatively Short & Cost Effective Implementation –
As described above, a vendor product
will have a specific implementation methodology that has been developed for the product.
Most vendor products are configurable to meet a utility’s business processes. Specialists in
conversion have tools to simplify the movement of data from one system to another. With
the experience of implementing their product many times, there are generally few surprises.
This is not to say that there can’t be long and costly packaged implementations, especially if
there are modifications involved.
Compatibility with other applications –
Most vendor software packages are designed to
interface with a variety of utility related products without modification. The majority of
vendor products included within this study contain utility billing, accounts receivable, cash
receipting, collections, work order management, meter management and inventory.
Easier and Faster Testing –
A vendor packaged product goes through normal software
development testing. However, the multiple utility users of the software give it a much more
rigorous test. This helps to assure that the software performs properly.
“Buy Versus Build” Analysis 5-4
City of Boulder—Volume 2—Utility Billing System Evaluation
5.3.2 Disadvantage of Purchasing a Vendor Supplied System
While there are numerous advantages to purchasing vendor software, there can also be
disadvantages. Provided below is a listing of the potential disadvantages of purchasing vendor
software.
Packaged Product May Not Meet All Business Needs -
As discussed in the build section,
the vendor product may not support all internal business processes. Modifying the vendor
system impacts the ability to upgrade as new releases are available. These modifications are
normally maintained at an additional cost to the standard maintenance fee. Given that, there
is a balance between changing business processes and adding required features not available
in the packaged system. If these enhancements are done external to the base product, the
impact is minimal.
Dependent On Vendor Availability –
The counter balance to the benefits of a user group is
that when changes are made to the software, it must meet the needs of the masses. Therefore,
vendor changes to the software, both through normal releases or utility requested, must be
prioritized and scheduled. As a result of this prioritization process, the schedule for
revisions/upgrades may not meet the needs of the city. In addition, many vendors will
invalidate warranty and/or maintenance if non-certified technical resources modify the
software.
No Control of Packaged Business Functions –
A packaged product is designed to meet the
needs of the mass market. Therefore, in some cases, business functions may require changes
to current practices.
Intellectual Property Rights Ownership –
The software, and all related work products, are
owned by the vendor. This fact normally includes any modifications designed and paid for
by the vendor’s clients. In addition, the direction and vision of the product can be
influenced, but not defined, by the organizations most affected by these decisions.
In summary, the advantages of purchasing vendor software center around a well developed,
documented and tested product that uses a “best practices” approach. In contrast, the
disadvantages of purchasing vendor software focus on those situations where the vendor
software may not perfectly fit the city’s business process, and the possible implications of
modifying or not modifying the software to exactly meet the city’s business process.
5.4 Costs and Considerations
A cost analysis is an integral part of the review of the advantages and disadvantages for building
versus buying a system. In order to begin to understand the possible costs associated with
purchasing a system, various vendors were contacted and asked to provide cost estimates for a
billing system. Provided below is a summary of the findings of that process.
Thirteen (13) vendors that focus on the municipal utility market were contacted as a part of this
study. Three (3) of the vendors would not respond to a telephone survey and therefore, were not
included in the cost analysis. In addition to vendor products, costs to build a system from
“scratch” were provided by the vendor currently used to support the utility billing system. Given
that a formal Request For Information or Proposal was not issued as a part of this process, the
“Buy Versus Build” Analysis 5-5
City of Boulder—Volume 2—Utility Billing System Evaluation
vendors were asked to provide an estimate of the costs associated with a multi-service utility
with approximately 30,000 customers.
Vendors were asked to provide costs associated with three aspects of the transaction: software
license (the right to use the product), implementation (all activities required from installation
through production execution of the software) and maintenance (ongoing technical and business
support from the vendor). The costs do not include any enhancements or interfaces that might be
required to meet the city’s specific detailed requirements. Provided below in Graph 5-1 are the
vendor responses.
Graph 5-1
Comparison of Estimated Vendor Costs Versus Building Costs
$1,200,000.00
$1,000,000.00
$800,000.00
$600,000.00
Maintenance Fee
Implementation
$400,000.00
Licensing / Development
$200,000.00
$0.00
Vendors
The costs to replicate the current system in new technology were provided by the software
organization currently maintaining the city’s utility billing system. This technology upgrade
includes database redesign but does not include changes to business processes. Rather, it
migrates the current system to a technology foundation consistent with the other systems within
the city of Boulder. Implementation costs for the “build” solution were not estimated. The
implementation approach, if a build solution is selected, has not been defined. However,
implementation costs for the build solution must be taken into consideration when reviewing this
cost analysis.
5.4.1 Implementation Activities and Costs
Detailed below are typical activities involved with a CIS implementation. The costs of these
activities are dependent on the ratio of internal and external staff.
“Buy Versus Build” Analysis 5-6
City of Boulder—Volume 2—Utility Billing System Evaluation
Project Planning and Management –
This is a coordination activity to insure that a task or
sets of tasks do not delay the overall project and that all the pieces come together at the
appropriate time. If a development firm builds the software then this task will require staff
from both the city and the development firm. The planning associated with the creation of
the software must be coordinated with the implementation of the software.
Requirements Definition and Documentation –
The initial requirements definition for the
city was completed with the creation of the functional specifications. However, these
requirements are at a very high level and must be further defined with the inclusion of
detailed business processes and synchronization between requirements. This activity
requires that city staff carefully review the documentation to insure that it includes all
requirements.
Software and Database Design –
Once the requirements are clearly understood by the staff
building the system, database and software design begins. There are many techniques to
accomplish this activity. However, during this stage, city staff will be involved in reviewing
the approach taken to fulfill the business needs.
Coding and Initial Testing –
This activity is normally completed entirely by the staff
commissioned to build the system. Within this activity there is time to review the results as
they are built. However, any changes after the design activity is complete impacts the
delivery time and cost of the system. That is why it is important to review all requirements
and design documents very carefully.
Conversion –
Data from the old system is needed to properly support and bill customers as
you move to a new system. Key decisions must be made such as: what data must be moved,
what format will it be, and will it be moved in summary or detail. Conversion and
conversion testing is one of the most time consuming activities within an implementation.
Interface Design and Development –
Interfaces must be defined, designed, coded and
tested. The challenge when designing and building an interface is that data within one
system may not be structured or in the format that the new utility billing system requires.
Therefore, additional effort to reconfigure the data may be required.
System, Integration and Acceptance Testing –
The final activity is testing to insure that the
new system meets the city’s business needs. The system test insures that the requirements, as
defined, are successfully completed. Integration testing insures that the billing system works
with the other systems within the city environment: bill print, Geographic Information
System (GIS), etc. Finally, acceptance testing insures that the entire solution is working
correctly in the city of Boulder environment. It should be noted that testing is always the
area underestimated in any project. It is also the area that is critical to making sure that the
system correctly bills and supports the city’s client base.
Whether a system is purchased from a vendor or built as a custom solution for the city of
Boulder, ongoing maintenance must be considered. Currently, the city is spending
approximately $200,000 to support and enhance the current utility billing system. The internal
costs for CIS support are not expected to reduce and may increase dependent on the final
solution. Provided below in Table 5-1 is a summary of the city’s annual billing system support
costs.
“Buy Versus Build” Analysis 5-7
City of Boulder—Volume 2—Utility Billing System Evaluation
Table 5-1
Summary of the City’s Annual Billing System Support Costs
2003 Total Utility
Costs for IT % of 2003 Cost 2003 IT Costs for
Servicesfor Billing System Billing System
Application Support $191,299 93.1% $178,099
Systems Support 27,488 34.0% 9,346
Server-Annual Replacement Costs 8,000
Total In-House IT Costs $195,455
Contracted Support 20,000
Total Costs $215,455
As can be seen in the table above, in 2003, the utilities paid approximately $195,000 to IT for
support of the utility billing system. It should be noted that the costs shown for 2003
(specifically the “application support” costs) reflect significant modifications made to the billing
system to receive credit card payments. Application support can fluctuate from year-to-year and
is typically from $65,000 to $180,000 depending on the extent of modifications or enhancements
implemented. Also shown in Table 5-1 are the costs associated with retaining outside contracted
support for the system. At the time of the preparation of this report, the city had paid
approximately $20,000 for these outside support services.
Currently the utility billing system co-exists on a server with other similar databases. The exact
type and number of databases can change from time to time, but generally the utility billing
system database is the largest on the server. The server is replaced every five years and costs
approximately $40,000. If the city decides to buy a packaged system, IT recommends the system
run on a dedicated server.
5.5 Summary
Determining whether to buy or build a system is a complex decision. There are advantages and
disadvantages to each option, along with short-term and long-term issues, implications and risks.
In the end, the city must determine the approach that best fits their needs, while balancing costs
and risks.
If the city were to build a new utility billing system, it would have complete control over
technology, features, and timing. The drought of 2002 raised issues and created billing system
challenges that other areas of the country may not have experienced. These challenges may
create additional requirements that only a custom-built system can support. However, a custom-
built system is very expensive to build and maintain, both initially and on-going. All the
implementation tasks that would normally be performed by a vendor will need to be completed
by either the city of Boulder or the software development firm. There is a high risk that the
initial system delivered will not meet the expectations of the user of the system. Conversely,
purchasing a vendor supplied system requires compromise. The benefits of a purchased product
include stability, lower risk and shared development. However, to receive these benefits, the city
may require process reengineering and cooperation. By purchasing a packaged vendor product,
“Buy Versus Build” Analysis 5-8
City of Boulder—Volume 2—Utility Billing System Evaluation
the city and its users are able to see exactly what the product does and can relate features within
the product to business requirements. However, what is available may not exactly meet all of the
city’s business requirements. In addition, the direction and timing of enhancements can only be
influenced, not controlled.
In the end, the final decision between building a product and buying a product will have to wait
until after the evaluation of the response by vendors to the functional specification. Only by
closely examining and evaluating vendor products can an understanding of the features of each
product be understood, and how well these features match the city’s functional requirements
(business process).
“Buy Versus Build” Analysis 5-9
City of Boulder—Volume 2—Utility Billing System Evaluation
Section 6
Peer Comparison
6.1 Introduction
It is always best to learn from success and failures of others. As the requirements to meet water
utility regulatory and customer needs has changed, so has the technology and CIS software. This
section of the report will discuss the peer review undertaken as a part of this study. The
objective is to understand the approach and systems used by other comparative utilities.
6.2 Overview of the Peer Utilities
The peer review utilities selected for this review were from states with a focus on conservation
and conservation-based rates. These states included Arizona, California, Colorado, New Mexico
and Utah. In addition, some Florida utilities were included since water conservation is also an
important issue in that state. For the most part, municipal utilities providing the same services
will have similar issues when evaluating and implementing software solutions. However, size of
the utility often defines the vendor solutions available for consideration. Provided below in
Table 6-1 is a summary of the “peer” utilities used for this study.
Table 6-1
Summary of the Front Range Communities
City of Boulder Manchester Water Works (NH)
City of Antioch (CA) Mesa Consolidated W.D. (CA)
City of Aurora City of Napa (CA)
Daly City (CA) Otay Water District (CA)
Denver Water Board Palmdale Water District (CA)
East & Central Plantation (FL) Pinellas County (FL)
City of Fairfield (CA) Port Orange (FL)
City of Fort Collins Racine Water District (WI)
Town of Gilbert (AZ) Rancho California W.D. (CA)
Green Bay Water Utility (WI) Sacramento Suburban W.D. (CA)
Hesperia Water District (CA) City of Santa Clara (CA)
Irvine Ranch Water District (CA) City of Thornton
Lake Havasu (CA) UTE Water Conservancy District
Lee County (FL) Yorba Linda Water District (CA)
City of Longmont City of Westminster
Peer Comparison 6-1
City of Boulder—Volume 2—Utility Billing System Evaluation
6.3 Review of Systems Being Utilized
There are numerous systems being utilized to the meet the billing and CIS needs of utilities. In
general, these systems can be categorized between custom-built and pre-packaged vendor
software solutions. Provided below is a discussion of these two types of systems.
6.3.1 Custom-Built Billing Systems
Custom-built systems, are as the name implies, built specifically for the utility. In many cases,
these custom-built systems may be fairly old, and built before the large array of vendor products,
such as those available today, were on the market.
Within the thirty peer utilities reviewed for this study, there are two categories of custom-built
system users. These two categories are as follows:
Utilities currently using a custom built system
Utilities currently using a custom-built system, but have already selected and are
implementing a new vendor provided system.
Of the thirty, ten are using a custom system with four intending to move to a pre-packaged
system. East & Central Plantation, Irvine Ranch Water District, Racine Water, Sacramento
Suburban Water District, Yorba Linda Water District, and Pinellas County are all running
systems that were custom built. Daly City, Town of Gilbert and City of Westminster are
currently running custom built systems, but have recently purchased new systems and are in the
process of implementing pre-packaged solutions. Sacramento Suburban Water District is using a
custom system built in 1985. However, the District is planning on buying a new pre-packaged
system soon. Their main reason for looking for a new system is the desire for more streamlined
navigation.
The level of satisfaction with custom-built system varies. In discussions with East & Central
Plantation, they plan to continue to use their custom-built system and are satisfied with its
performance. The system at Irvine Ranch Water District was built in the early 1990’s by their IT
staff. The system supports their five-tier water budget rate structure and they have no plans to
replace the system. At Racine Water in Wisconsin, they currently run a COBOL based system
built in 1984. They have found that it is becoming harder to integrate the information within CIS
with other systems – like GIS. Similar to Boulder’s system, they have continually enhanced
their system over the years. Racine’s system is maintained by the same company that wrote the
original software in 1984. Yorba Linda Water District selected a pre-packaged vendor system
from a little known vendor. Unfortunately, the pre-packaged software did not meet the
requirements of the District. Yorba Linda had completed the implementation of the pre-
packaged software and were running both systems in parallel, but finally had to revert back to
their old custom system. The demonstration provided by the vendor was very good. However, it
was later discovered that the backbone behind the images presented to the District didn’t exist.
Finally, Pinellas County is currently using a custom-built system but recognizes that it is getting
outdated. The County needs to integrate the system with other applications, but resources are an
issue, especially since many of the original creators are retiring. This has also created
maintenance issues.
Peer Comparison 6-2
City of Boulder—Volume 2—Utility Billing System Evaluation
6.3.2 Pre-Packaged Software Products
There are many software companies that provide pre-packaged systems to the municipal market.
Many of these companies focus totally on customer information solutions. During our
discussions with the various peer utilities it was noted that there were different opinions about a
vendor depending on when the software was installed, the involvement of the in-house IT staff
and the priorities of the organization. Provided below is a discussion of the vendors as provided
by the peer utilities.
Cogsdale
– Cogsdale’s product is a solution that comes from a history of buyouts (Aquillium
became MDS, and then Cogsdale). The product uses Microsoft Great Plains as a foundation.
Mesa Consolidated Water District and Palmdale Water District both purchased Cogsdale.
Their implementation experience varies dramatically. Mesa’s implementation took over two
(2) years. In contrast, Palmdale’s was completed within six (6) months. Mesa experienced
many defects and problems. They would not recommend the system. Palmdale, on the other
hand, stated that the Cogsdale product is good and they have received good support. The key
difference seems to be that Mesa bought the product in 2000 and Palmdale selected it in
2002. Mesa experienced the transition of the product through the buyouts from one vendor
to another, until Cogsdale finally purchased the software.
Eden Systems
– Eden Systems has been providing financial systems to the municipal market
for many years and has just recently built a CIS offering. The City of Napa, City of
Westminster, Town of Gilbert, and Otay Water District all purchased the Eden Systems
product. The City of Napa recently purchased the Eden Systems suite and stated that they
feel like a “guinea pig” because there are very few Eden CIS clients. The City of
Westminster also recently purchased Eden Systems. The Town of Gilbert used Eden
Systems Financials and are in the process of implementing the CIS portion of the product.
The Town of Gilbert wants to implement conservation-based rates in the future and believes
that Eden Systems is flexible enough to handle it. Otay Water District has been working
with Eden Systems for over a year in a joint development project to add features to the
billing system. They plan to go live with the billing system in January 2004 and financials in
2005. Although their current system supports water budgets, as defined by city of Boulder, it
will not be in the Eden Systems product when Otay goes live. It should be noted that Otay
no longer uses water budget rate structures.
Hansen
- Hansen has been providing software to the public sector market for almost 20
years. However, only two of the cities we spoke with have purchased this product. The city
of Daly City just recently purchased Hansen. They use a twelve-tier rate structure for
conservation and are having Hansen customize the system to support this structure. The City
of Thornton is in the process of implementation. They are very satisfied with the product and
implementation process so far.
Harris Computer Systems
- Harris Computer Systems has been providing CIS and financial
management solutions to public and municipal utilities for over 26 years. The City of Santa
Clara needed a system for Y2K and stated that over the past few years they have seen a vast
improvement in the support received. Green Bay Water Utility purchased the Harris system
in 2001. They are very satisfied with the system, and noted that the system does pretty much
anything.
Peer Comparison 6-3
City of Boulder—Volume 2—Utility Billing System Evaluation
HTE
- HTE, a Sungard company, provides a variety of software solutions to government
offices, agencies and utility companies. The City of Port Orange is satisfied with HTE
because it allows them to view their accounts comprehensively, including account history.
Lake Havasu City went live with HTE in January of 2000. The implementation took longer
than expected due to communication and training issues. However, they are satisfied with
the system and estimate that it has increased productivity by one-third. They are very
pleased with the support and the fact that there are two to three workshops held each year in
addition to online training. The City of Manchester decided three years ago to consolidate
into a city-wide system. Manchester Water Works purchased an HTE system to support this
initiative. Worth noting is the fact that the HTE vendor runs on a propriety hardware and
environment that the city of Boulder does not currently support.
Orcom
- Orcom was recently purchased by Alliance Data Systems and provides outsourcing
solutions to water, gas and electric companies. Lee County Utilities has been expanding over
the past few years and now supports over 60,000 customers. They purchased Orcom in 1999
and just recently upgraded to the latest release of the product. They have completed four
conversions and are very satisfied with the support they received during each process. Any
issues are entered on-line and the problem is normally fixed within 1-2 days.
Miscellaneous Other Vendors
- Many peer utilities that were interviewed were using
smaller, local vendors. These included the City of Antioch which purchased, in May 2003,
their Windows-based packaged solution from InCode, a company based in Texas. Antioch is
very satisfied with InCode, citing that it is much simpler to use, and it has increased
efficiency and productivity. The vendor provides good support and good training. Hesperia
Water District purchased the Logos by New World in 1998. Although it only took 6 months
to implement the entire suite, the person we spoke with is not satisfied with the product.
They monitor conservation by comparing usage between the prior year and this year. The
product continually has problems supporting this concept. He noted that support was
unacceptable - especially due to time differences. Rancho California Water District
purchased the Gough Systems in 1989 and has been very satisfied with it. UTE Water
Conservancy District selected Caselle in 1996. The product, when purchased was DOS
based, and it has subsequently been upgraded to Windows.
As can be seen, the experiences of the peer utilities with pre-packaged software has ranged from
very satisfied to very dissatisfied. However, within the peer review there appeared to be a
greater level of satisfaction than dissatisfaction.
6.4 Lessons To Be Learned From the Peer Review
Each of the utilities reviewed had varying experiences in the definition, selection,
implementation and support of their Customer Information System. Most peers believe that their
systems provide the required features to support their business. However, the peer utilities had a
number of suggestions to improve the selection and implementation processes. The various
areas of improvement were as follows:
Peer Comparison 6-4
City of Boulder—Volume 2—Utility Billing System Evaluation
Selection Process:
When analyzing buy vs. build – pay attention to whether resources are available internally to
support a custom-built system including capacity, skills, budget, etc.
Pay attention to the demonstration and make sure that there is really substance behind the
demonstration.
Be aware of what you are really being sold – be very careful of “hidden” costs in the
contract.
Forward current system and business rules to the vendor to make sure they can support your
needs.
Some vendors don’t like to customize their system unless all their clients want the
modifications. In addition, many will not customize unless the utility is willing to pay.
When researching the potential products, spend a day with a current customer to see the
system really working at a client site. The on-site demo isn’t as revealing or beneficial as
going to another utility and watching people actually using an installed system.
Implementation Process:
Understand the statement of work. One utility was told that the implementation would take
seven to eight months, and it took far longer.
Don’t underestimate the amount of time the move to a new system will take. It takes time
and effort to make the decisions and implement the system.
Even though the utility tried to minimize any customizations, the utility found that they
required a lot of customization.
Don’t just copy your current processes, take advantage, review and improve.
If the city’s IT staff is going to write the interfaces, allocate extra time for IT staff to
understand the new system.
Monitor the vendor to make sure that there is enough staff to support the implementation – be
aware of staff turnover.
During training, make sure there is enough time to go over all the different processes before
moving to the next step.
The conversion process can be problematic – do lots of testing.
Pay attention to system requirements such as whether an SQL or an Oracle platform is
needed.
Test, test, test and then test some more.
6.5 Summary Matrix of the Peer Review
Provided in Table 6-2 is a summary matrix of the peer review conducted for this portion of the
study. It should be noted that all of the utilities listed were contacted for information. In some
cases, the utilities did not respond to the request for information. As a result, some information
was obtained from the utility’s web site (e.g. rate structures, customers served, etc.).
Peer Comparison 6-5
City of Boulder—Volume 2—Utility Billing System Evaluation
6.6 Summary
This section of the report has provided a summary of the peer review conducted for the city. In
general, the peer review found a number of utilities that have custom-built systems. However, it
appears that most utilities utilize pre-packaged vendor software. As would be expected, the level
of satisfaction with both custom-built and pre-packaged software varied from user to user.
The next section of the report will discuss the rate structure alternatives being explored by the
city, and the compatibility of those rate structures with pre-packaged vendor software.
Peer Review 6-8
City of Boulder—Volume 2—Utility Billing System Evaluation
Section 7
Review of the Rate Structure
Alternatives and Billing System Vendors
7.1 Introduction
An important element of the city’s study was the development of various rate structure
alternatives designed to meet the city’s overall goals and objectives. Given the review and
development of those rate structures, this section of the report will review the billing system
capabilities needed to utilize each of these structures, and the possible vendors that may have
software capable of billing these rate structures. In addition, this section of the report will
discuss the possible challenge(s) that these rate structures may present when implementing them
within the context of a vendor provided CIS product.
7.2 Review of Potential Vendors
Improved technology and past lessons learned have expanded the ability of vendors to provide
products that meet a wide variety of functional needs. Utility rates and the corresponding billing
process has always been the greatest challenge for any vendor supplied (“off the shelf”) CIS
package. The challenge for public utilities is to support unique needs, while trying to balance the
cost impacts needed to maintain the infrastructure required to provide the utility’s desired level
of customer service. Various utilities have approached the challenge in different ways. Many of
these alternatives have been “built” into packaged products and are supported by vendors
focused on the municipal market.
To analyze the vendor/billing software options potentially available to the city of Boulder, this
portion of the study started with thirteen (13) vendors that have sold products to and supported
public utilities in the past. Four (4) of these vendors were eliminated because they did not
answer the questions posed as a part of this study (they may answer the questions in a formal
Request For Information), leaving nine (9) vendors included in this review.
7.3 Rate Structures and Billing System Considerations
As a part of the city’s study, various conceptual rate structures have been developed for each
customer class of service. These rate structures are discussed in detail in Volume 1 of this study.
In reviewing these rate structures, from a CIS/billing system perspective, a number of issues and
considerations should be taken into account. In particular, when evaluating the vendors in
relationship to the proposed rate structures, the systems must have certain capabilities as they
relate to customer classes of service, fixed costs/rates, variable costs/rates, ease of use, reporting,
maintenance and other services. Provided below is a more detailed discussion of some of these
elements of the rate structure and the capabilities required within a CIS/billing system.
Review of the Rate Structure Alternatives and Billing System Vendors 7-1
City of Boulder—Volume 2—Utility Billing System Evaluation
CCS
– The capability of grouping and billing customers by
USTOMER LASSES OF ERVICE
designated customer classes of service (e.g. single-family residential, multi-family residential,
etc.) has been a standard practice within software products for many years. The vendors
evaluated within this study do not restrict the number of customer classes of service that can be
defined and established within their CIS product. They allow the utility to define as many
customer classes or sub-groupings as is needed to support a utility’s business processes. These
could include, at least initially, the four customer classes of service identified within Volume 1
(i.e. single-family residential, multi-family residential, commercial/large user and metered
irrigation). However, these classes could be expanded to include customer types based on the
city’s predefined groupings (e.g., commercial subgrouped as restaurants, office buildings,
supermarkets, etc.) or based on a standardized identification such as SIC (Standard Industrial
Classification) codes.
FC/FR
- The concept of fixed costs can be broken down into two types.
IXED OSTSIXED ATES
The first type of fixed cost is typically identified as the cost(s) that are associated with the
customer service and billing of a customer. This portion of the fixed rate may also fund a
portion of the operation and maintenance of the city’s system. These costs are often billed
monthly to the customer via a fixed rate and are frequently grouped and billed as a single line
item on the customer’s bill. These fixed rates often take the form of a service (meter) charge that
is dependent upon the size of the customer’s meter (e.g. 5/8”, 3/4”, etc.). The second type of
fixed cost may be specific to the customer and their associated services (e.g., fixture count, etc.)
and is normally detailed on the customer’s bill. Some vendors within this evaluation can easily
support both types of charges (detailed and summary). As the bill presentation and fee
accounting becomes more complex, software modification costs could occur. However, it is not
anticipated that any of the fixed rates within the proposed rate structures are such that it would
require modification of any vendor software.
VC/VR
– These costs are billed to the customer in the form of a
ARIABLE OSTSARIABLE ATES
variable charge. The variable charge portion of the customer’s bill is a function of their metered
use and the variable rate. The variable rate can take many forms and contain different rates for
different levels of use (i.e. an inverted/tiered block variable rate). In the case of the city’s study,
the variable portion of the rate structure is based upon two different approaches. The first
approach to the variable rate is a seasonal inverted block rate structure. This rate structure
should not pose any problems for vendors. The alternative approach is a “water budget” rate
structure, in which the customer is provided with various sized consumption blocks to reflect
their indoor and outdoor needs. The more difficult variable rate structure for the CIS/billing
system vendors is the “water budget” structure. This aspect of the evaluation is discussed in
more detail later in this section.
Given this brief overview of the typical components of rate structures, the discussion shifts to the
evaluation of the city’s rate structures from a CIS/billing system perspective.
Review of the Rate Structure Alternatives and Billing System Vendors 7-2
City of Boulder—Volume 2—Utility Billing System Evaluation
7.4 Overview of the Rate Structures
The rate structure evaluation discussed in Volume 1 is organized based on four customer classes.
These customer classes of service include:
Single-Family Residential
Multi-Family Residential
Commercial/Large Use
Metered Irrigation
An overview of each of these customer classes of service will be provided, followed by a more
detailed individual discussion of each rate structure and the projected support by vendor
provided products.
7.4.1 Single Family Residential
Six (6) different rate structures were reviewed for the
PC
single-family residential customer class of service.
RORATING ONSUMPTION
There are two common requirements found within the
A situation may exist where a rate
potential single-family residential rate structures – 1)
st
change goes into effect on the 1 of the
the ability to identify and differentiate between winter
month. However, the customer is
and summer rates and 2) the ability to designate
billed on the 8th of the month. The
customer specific consumption block thresholds
ability to prorate consumption,
within the rate structure where the price will increase
assuming 30 days of service, would
due to excessive use. Langham believes that all the
enable the system to bill 22/30 of total
consumption at the old rate and 8/30
CIS products evaluated herein support user defined
of total consumption at the new rate.
effective dates, which can be used to designate winter
Proration provides a more accurate set
and summer periods. In addition, each CIS product
of charges for the customer.
provides the ability to designate blocks or tiers within
each rate structure. Another consideration when
implementing any of these structures is the system’s ability to prorate consumption. Prorating
will be required for both the seasonal and water budget rate structures. The level of complexity
for proration varies between the rate structure alternatives. The more complex rate structures,
such as the water budget rate structure, where the blocks are shaped and can change from month
to month, will be more difficult to establish the proration calculation within the capabilities of
the system.
All of the single-family rate structures contain a fixed meter charge and a variable consumption
charge. All the CIS/billing systems are capable of handling the city’s fixed meter charge
component. The focus of the discussion below is on the variable consumption charge portion of
the rate structure.
SFRRS1–
The
S-FR
INGLE AMILY ESIDENTIAL ATE TRUCTURE
INGLEAMILY ESIDENTIAL
first single-family residential rate structure reviewed is a
RS1
ATE TRUCTURE
seasonally differentiated rate structure. This rate structure
Seasonally Differentiated Rate
uses an inverted block rate structure for the variable rates.
Structure with a 2-Block Winter
It should be noted that this rate structure is similar to
Rate and a 3-Block Summer Rate.
those used by many municipal water utilities and water
Review of the Rate Structure Alternatives and Billing System Vendors 7-3
City of Boulder—Volume 2—Utility Billing System Evaluation
districts. It would most likely be supported by any vendor responding to the city’s Request For
Information (RFI). As a result, it is anticipated that no special programming or modifications to
vendor software would be required to implement this rate structure.
S-FRRS25–
Single-Family Residential
INGLEAMILY ESIDENTIAL ATE TRUCTURES THROUGH
Rate Structures 2 through 5 can be grouped into the overall category of “water budgets”. These
rate structures are typically considered more complex than traditional rate structures. The
complexity may be a function of the development of the rate based upon individual customer
characteristics, the shaping and sizing of the water blocks on a monthly basis, and the potential
need to prorate bills on a monthly basis. Specifically, the complexity begins at the second block
within each of these rate structures. The second block references ancillary data such as: lot size,
impervious area, irrigable area, etc. This ancillary data is used to initially identify a customer’s
water allocation for irrigation purposes. Once calculated, the total amount of water within the
nd
2 block must be allocated and distributed across the year using a predefined formula based
upon weather and evapotranspiration (ET). Any CIS system selected must have access to all of
the elements within the algorithm. In addition, it must store the values used for future activity
such as adjustments, estimation, reporting, etc. Most vendors support the block or tier structure,
definition of impervious area, pervious area, lot size, etc. However, only the most flexible
vendors will provide software to support the monthly water allocation calculation for irrigation
which involves using weather and ET factors. If the city were to select one of the water budget
rate structures, and depending upon the final complexity of the structure, then the number of
potential vendors would be significantly reduced and probably only include: Open C, PeopleSoft,
and Cayenta. There are some other vendors that responded that say they have implemented
“simple” water budgets or “water budget like” conservation rate structures. These include
Systems & Software, Hansen, and Harris Computer Systems.
A review of each of the individual single-family residential water budget rate structures is
provided below.
S-FRRS2–
INGLEAMILY ESIDENTIAL ATETRUCTURE
S-FR
INGLEAMILY ESIDENTIAL
This rate structure is based on a four (4) block approach.
RS2
ATE TRUCTURE
The first block is calculated using a fixed cost per 1,000
gallons and is supported by most potential CIS vendors,
Water Budget With Four (4)
and appears to be no different than most inverted block
Consumption Blocks. Block 1 Is
rate structures. However, the second block and third
Fixed For Indoor Use, Block 2 Is
Based Upon The Irrigation blocks are shaped and sized (recalculated) each month
Requirements Of A 9,000 Square
depending on historic ET. These block calculations will
Size, And Block 3 Uses
Foot Lot
prove to be challenging for most CIS products. The
150% Of Block 2 To Determine
constantly changing elements within the calculation
Size.
may also impact the features within a standard CIS
product. These features include consumption and
charge estimation, proration, and billing adjustments. Given that these standard features may be
affected by use of a water budget rate structure, it may require modification of the software to
report and calculate correctly.
Review of the Rate Structure Alternatives and Billing System Vendors 7-4
City of Boulder—Volume 2—Utility Billing System Evaluation
S-FRRS3–
INGLEAMILY ESIDENTIAL ATE TRUCTURE
S-FR
INGLEAMILY ESIDENTIAL
As with the previous water budget rate structure, this
RS3
ATE TRUCTURE
rate structure requires the following components: lot
size and a tier structure which utilizes a monthly
Water Budget With Four (4)
recalculated water allocation based on the lot size and
Consumption Blocks. Block 1 Is
ET. However, with this rate structure there are three
Fixed For Indoor Use, Block 2 Uses
Three Different “Bins” to Determine
(3) possible options for the monthly allocation, based
Irrigation Requirements, and Block
upon the placement within a “bin.” The bin
3 Uses 125% of Block 2 to
determines the volume of water allocated to the
Determine Size.
customer, which is then shaped for ET. The majority
of the vendors interviewed within this study provide
CIS products that include the option of storing a “bin number” within the property information.
The initial entry of the bin number could be a manual process which is entered one time as the
property is initially measured or could be included within the block calculation the first time the
value doesn’t exist in the system. Each vendor will approach the determination of irrigation
requirements differently depending on the design of their base system. As described in rate
structure 2, the fact that elements within the block calculation can change as a result of historic
ET and weather may also impact standard features provided within a vendor CIS product.
S-FRRS4–
INGLEAMILY ESIDENTIAL ATE TRUCTURE
S-FR
INGLEAMILY ESIDENTIAL
This rate structure is very similar to rate structure 2
RS4
ATE TRUCTURE
nd
with the exception that the 2 block is based upon the
individual customer’s tax assessed lot size. Given
Water Budget With Five (5)
that, this rate structure requires separate calculations
Consumption Blocks. Block 1 Is
for each property. In essence, the city would have an
Fixed For Indoor Use, Block 2 Is
Based on Tax Assessed Lot Size,
individual rate structure for each individual single-
Block 3 Is 125% Of Block 2, And
family residential customer. Most vendors support the
Block 4 Is 150% Of Block 2.
gathering and storing of lot size and the use of lot size
within a tiered calculation of charges. As with the
previous water budget rate structures, the challenging portion of this rate structure for the
nd
CIS/billing system and potential vendors is the monthly shaping of the 2 block water allocation
for historical ET. Because of this structure’s complexity, simple features become much more
complex to automate (e.g. bill estimation for non-reads and bill comparison (history) to same
time last year).
S-FRRS5
INGLEAMILY ESIDENTIAL ATETRUCTURE
S-FRR
INGLEAMILY ESIDENTIAL ATE
–
This rate structure combines the elements of both
S5
TRUCTURE
water budget rate structures 2 and 4. The irrigable
size element is supported within the CIS product of
Water Budget With Four (4)
most of the vendors interviewed within this study.
Consumption Blocks. Block 1 is Fixed
However, even though this rate structure appears to
For Indoor Use, Block 2 is Based Upon
Either a Customer Provided Irrigable
be more straightforward, when utilizing a CIS
Size, or a Default of 5,200 Square Feet of
system, the fact that the customer can provide the
Irrigable Area. Succeeding Blocks Based
irrigable size adds the complexity of rate structure 4.
Upon Relationship to Block 2.
Therefore, the same issues involving the
maintenance of historical data apply to this rate
Review of the Rate Structure Alternatives and Billing System Vendors 7-5
City of Boulder—Volume 2—Utility Billing System Evaluation
structure. An additional consideration when reviewing this rate structure is the initial setup of
information about the property. Unlike using tax assessed lot size, which is used within rate
structure 2, 3, and 4, and available within the tax records, irrigable area would need to be
manually calculated (determined) whenever a customer appeals the default irrigable area. The
revised irrigable area would then be entered into the customer records. In addition, any changes
to the property could impact the validity of that irrigable data.
S-FRRS6–
INGLEAMILY ESIDENTIAL ATE TRUCTURE
S-FR
The final single-family residential rate structure that
INGLEAMILY ESIDENTIAL
RS6
was reviewed was a modified version of the city’s
ATE TRUCTURE
existing single-family residential rate structure. This
Existing City Rate Structure
rate structure utilizes the approach of calculating the
Modified To Reflect Current City
individual customer’s Average Winter Consumption
Goals.
nd
(AWC) to determine the first block size. The 2 block
size is a fixed block size based upon the irrigable
requirements for a standard lot. From a CIS/billing perspective, the most challenging portion of
this rate structure is the calculation of the individual AWC. Most vendors support the ability to
designate the months used for consideration and calculation of the individual AWC. It is
anticipated that this rate structure is most likely supported by any vendor with established clients
similar to the city in size and services.
In summary, it appears that each of the single-family residential rate structures could be
supported by an existing CIS vendor. However, some vendor products would require more
modification. The water budget rate structures, depending upon their final form and complexity,
may be supported by utilizing current features within the CIS product. It is very important when
discussing “water budgets” with a prospective vendor that the definition of the city’s “water
budget” is clear. As stated initially, vendors have responded that they have implemented
“simple” water budgets or “water budget like” conservation rate structures. However, when
interviewing both the peer communities and vendors, the term “water budget” had many
meanings - from a simple multi-tier structure to the definition as used in this report – a set water
allocation shaped for irrigable requirements.
7.4.2 Multi-Family Residential
There are three rate structures being considered within the multi-family customer class of
service. The vendor support for these structures is similar to that indicated for the single-family
residential customer class above. If the city selects analogous rate structures for both the single-
family and multi-family residential classes, the cost of implementation will likely be less than it
would be if the city was to implement dissimilar rate structures for these two customer classes of
service.
Review of the Rate Structure Alternatives and Billing System Vendors 7-6
City of Boulder—Volume 2—Utility Billing System Evaluation
M-FRRS1–
ULTIAMILY ESIDENTIAL ATETRUCTURE
M-FR
ULTIAMILY ESIDENTIAL
Similar to the first rate structure reviewed for the single-
RS1
ATE TRUCTURE
family residential rate structures, this rate structure is a
seasonal rate structure that has an inverted block rate
Seasonally Differentiated Rate
structure in the winter and the summer period. As
Structure with a 2-Block Winter
discussed previously, this structure is similar to structures
Rate and a 3-Block Summer Rate.
used by many municipalities and water districts. As a
result, no issues or concerns were noted for this rate
structure in relation to vendor software capabilities.
M-FRRS23–
Multi-family residential rate
ULTIAMILY ESIDENTIAL ATETRUCTURES AND
structures 2 and 3 are water budget structures. As described in the review of the single-family
residential water budget rate structures, the most complex portion of the water budget rate
structure is the calculation of the monthly water allocation for the outdoor use block. For the
rd
multi-family residential rate structures, this is the 3 block. Only the most flexible vendors
provide modeling tools within their rate engines. Therefore, if the city selects either of these rate
structures, there will be the same limited number of vendors (Open C, PeopleSoft, and Cayenta)
as described in single-family residential that could potentially provide the required functionality
“out of the box” (meaning, without modifications). The other vendors would require some
modification to their system to meet this requirement. An additional consideration would be the
ease of obtaining, entering, and maintaining the information needed in calculating the
algorithms. This could create a requirement for additional staff resources or the reallocation of
existing resources to manage and maintain the required data within the CIS system.
A more detailed review of the remaining two multi-family residential rate structures is provided
below.
M-FRRS2-
ULTIAMILY ESIDENTIAL ATETRUCTURE
M-FR
This rate structure includes six blocks. The first two
ULTIAMILY ESIDENTIAL
RS2
blocks are fixed in size and based upon the number of
ATE TRUCTURE
living units for the multi-family account. Therefore, the
Water Budget With Six (6)
system would need to be able to differentiate the
Consumption Blocks. Blocks 1 and
number of living units associated with a specific
2 Are Fixed Per Unit Thresholds,
account. This aspect of the rate structure would not
Block 3 Is Based On The Customer
seem to be a major hurdle for the majority of vendors.
Specific Irrigable Area, and
The third block is based upon the customer specific
Succeeding Blocks Based Upon
irrigable area. This block is sized and shaped around
Relationship To Outdoor Goal.
historical ET. The remaining blocks are sized in
rd
relation to the 3 block. As with the single-family
nd
residential 2 block, the most challenging portion of this rate is the sizing and shaping of the
outdoor irrigation block. As described in the single-family residential rate structures, this
calculation will prove a challenge for most CIS vendors. The ever-changing elements, due to
monthly shaping, within the calculation may also impact the features within a standard CIS
product. These features include consumption and charge estimation, proration, and adjustments.
Each of these standard features may be affected by the use of a water budget rate structure and
could require a modification to report and calculate these standard features correctly.
Review of the Rate Structure Alternatives and Billing System Vendors 7-7
City of Boulder—Volume 2—Utility Billing System Evaluation
M-FRRS3–
ULTIAMILY ESIDENTIAL ATETRUCTURE
M-FR
ULTIAMILY ESIDENTIAL
This rate structure is very similar to the multi-family
RS3
ATE TRUCTURE
residential rate structure 2. The difference is the
rd
development of the succeeding blocks after the 3 block.
Water Budget With Five (5)
Given that, the comments and observations noted for the
Consumption Blocks. Blocks 1 and
multi-family rate structure 2 will also apply to this rate 2 Are Fixed Per Unit Thresholds,
Block 3 Is Based On The Customer
structure when evaluating potential CIS vendor
Specific Irrigable Area, and
capabilities. The fact that the final block has a lower
Succeeding Blocks Based Upon
threshold has no impact on the challenges presented to a
Relationship To Outdoor Goal.
CIS system, particularly as they relate to the
rd
establishment and calculation of the 3 block.
In summary, for the multi-family residential rate structure, it was concluded that most vendors
should be able to support rate structure 1. As previously defined in the single-family residential
section, there are a limited number of vendors that could potentially provide (support) rate
structures 2 and 3 “out-of-the-box” (meaning, without modifications). However, if the city
selects analogous rate structures across the residential customer classes, the cost of
implementation may be favorably affected.
7.4.3 Commercial/Large User
There are three rate structures being considered for the commercial/large user customer class of
service. The first two rate structures are very similar in structure and would be supported by
most vendors to a point. The structures define that the initial block will be calculated using three
years of consumption history. In most products, even though there are multiple years of history
stored, the software uses twelve months of history to calculate the water budget or average
consumption. The expansion of this functionality to include the additional 24 months of history
needed for this calculation, as defined, would be a modification to most systems. The third rate
structure uses meter sizes to create block sizes. This adds a level of complexity to the system,
but should be supported by most vendors.
The city has also noted the potential of expanding the definition of commercial/large user
customer classes within their CIS system. As discussed previously, for the vendor systems being
reviewed as a part of this study, it is not anticipated that the expansion of the commercial
customer classes of service, for purposes of data collection or redefined future commercial rate
schedules, would be an issue or a constraint.
Presented below is a more detailed review of each of the commercial/large user rate structures.
C/LURS1–
The
OMMERCIALARGE SERATETRUCTURE
C/LU
OMMERCIALARGE SER
first commercial/large user rate structure is a seasonal
RS1
ATE TRUCTURE
rate structure. This structure is similar to the other
seasonal rate structures reviewed as a part of this study,
Seasonally Differentiated Rate
and this structure is similar to that used by many
Structure With A 2-Block Winter
municipal utilities and water districts. This structure
Rate And A 2-Block Summer Rate.
would most likely be supported by any vendor
responding to the city’s RFP. However, in most
Review of the Rate Structure Alternatives and Billing System Vendors 7-8
City of Boulder—Volume 2—Utility Billing System Evaluation
products, even though there are multiple years of history stored, the software uses twelve months
of history to calculate the average consumption. The expansion of this functionality to include
an additional 24 months of history needed for this calculation, as defined by the city within this
study, would be a modification to most systems.
C/LURS2–
The
OMMERCIALARGE SERATETRUCTURE
C/LU
OMMERCIALARGE SER
second commercial/large user rate structure is very
RS2
ATE TRUCTURE
similar to the previous rate structure. The only
difference is the calculation of the first block. It is
Seasonally Differentiated Rate
calculated in the same manner as the previous rate
Structure With A 2-Block Winter
Rate And A 2-Block Summer Rate
structure, but a factor of 90% is then applied to the
and the First Block Set at 90% of
three-year average. This rate structure is similar to
Average Use.
structures used by many municipal utilities and water
districts, and would not appear to pose any problems for
a CIS vendor. However, as noted previously, in most products, even though there are multiple
years of history stored, the software uses twelve months of history to calculate average
consumption for billing purposes. The expansion of this functionality to include the additional
24 months of history needed for this calculation, as defined, would be a modification to most
systems, and be similar to the modification needed for the previous commercial/large user rate
structure.
C/LURS3–
The
OMMERCIALARGE SERATETRUCTURE
C/LU
third commercial/large user rate structure is a non-
OMMERCIALARGE SER
RS3
seasonal rate structure that varies by meter size. This
ATE TRUCTURE
structure is unique for the customer classes of service
Non-Seasonal Rate Structure
reviewed. For each meter size, the average monthly use
With Two Blocks. The First
of all the customers within that meter size is calculated
Block Size Is Based Upon the
and that is the basis for establishing the first block size.
Customer Meter Size, and the
There would be two billing issues associated with this
Average Monthly Use of the
rate structure. The first would be the determination of
Customers With That Same
the first block size. This determination could be
Meter Size.
performed by city staff, or automated within the CIS
system. If the calculation is performed by city staff,
then the system must be able to have different block sizes for different meter sizes. This should
not pose a problem for most CIS vendors. If the calculation is to be automated, the issue is
similar to the discussion above on the capturing of historical data. The other component that the
system must be able to address is the meter size of the customers. This information is in the
customer database and should not be an issue.
In summary, for the commercial/large user customer class of service, it is concluded that the rate
structures being reviewed by the city are most likely supported by the vendors included within
this study. In addition, many prospective vendor products will support the possibility of the city
further defining customers with additional data elements such as predefined groupings (e.g.,
restaurant, office building, and supermarket) or standardized identification such as SIC (Standard
Industrial Codes). Customer billing would initially proceed using the master classification of
commercial/large user, but could be changed to utilize the sub-classification at a future time. It
Review of the Rate Structure Alternatives and Billing System Vendors 7-9
City of Boulder—Volume 2—Utility Billing System Evaluation
is expected that the CIS vendor products included in this study could support the transition to a
more refined classification while still correctly reporting consumption and revenue history.
7.4.4 Metered Irrigation
There are three rate structures being considered within this customer class. The vendor support
for these structures is similar to the rate structures previously reviewed and in particular to the
water budget rate structures for the single-family residential. Again, if the city selects analogous
rate structures across the customer classes, the cost of implementation may be favorably affected.
MIRS1–
The first
ETERED RRIGATION ATETRUCTURE
MI
ETERED RRIGATION
metered irrigation rate structure is very simple and
RS1
ATE TRUCTURE
straight-forward. It has a uniform rate for the
consumption charge, which is the most basic rate
Uniform Rate Structure.
structure that can be used. Under this structure, all
consumption is billed at the same rate. This structure is used by many municipal utilities and
water districts. Therefore, this rate structure should be supported by all the vendors in the CIS
market place.
MRS2–
The
ETERED IRRIGATION ATETRUCTURE
MI
ETERED RRIGATION
second metered irrigation rate structure is a water
RS2
ATE TRUCTURE
budget rate structure. Unlike many of the single-family
water budget rate structures, this particular water
Water Budget with Three (3)
budget uses the customer’s specific irrigable area to
Consumption Blocks. Block 1 is
determine their first block size. This block size is then
Based Upon Customer Specific
Irrigable Area, Succeeding Blocks
shaped by historic ET. As noted with the single-family
are Based Upon Relationship To
rate structure, this aspect of the rate structure is the
Outdoor Goal.
most complex portion of this rate structure. Only the
most flexible vendors provide modeling tools within
their rate engines. Therefore, depending upon the overall complexity of the final rate structure
and the potential use of additional elements, there will be a limited number of vendors that can
provide the required functionality without modifications. The other vendors would require a
modification to their system to meet this requirement. In addition, when reviewing this rate
structure, the initial setup of information (i.e. irrigable area) must be considered. The customer
specific irrigable size would need to be determined and entered into any CIS system that is
selected. Also, any changes to the property could impact the validity of this data.
MIRS3–
The
ETERED RRIGATION ATETRUCTURE
MI
ETERED RRIGATION
final metered irrigation rate structure uses concepts
RS3
ATE TRUCTURE
similar to those used for the commercial/large user rate
structure. In this particular case, the first block is based
Inverted Block Rate with Three (3)
upon the customer’s average summer consumption
Consumption Blocks. Block 1 is
(ASC). Most vendors can calculate the ASC utilizing
Based Upon 90% of the Customer’s
defined months. However, the functionality available
Average Summer Consumption
to perform this calculation normally uses the previous (ASC), Succeeding Blocks are Based
Upon Relationship to Block 1.
year’s summer consumption as input data for the ASC
calculation. Therefore, even though the historical
Review of the Rate Structure Alternatives and Billing System Vendors 7-10
City of Boulder—Volume 2—Utility Billing System Evaluation
information is available in the database, the calculation only uses one year of history. Adding
the requirement for three years of history to be included in the calculation would be outside the
normal configuration done during the setup phase by most vendors. Therefore, a modification
would most likely be required.
In summary, for the metered irrigation customers, the only rate structure that would pose a
concern for a vendor would be the water budget rate structure. The issues that a vendor would
encounter would be similar to those previously identified for the other customer classes of
service using the water budget rate structure.
7.5 Ease of Use/Maintenance
A final consideration when reviewing rate structures is the ease of use and maintenance. The
CIS vendors included within this evaluation support the effective dates required for the
summer/winter rate structure calculation. The utility customer is assigned to a particular class of
service and the corresponding rate structure and the rate charged is automatically calculated
based upon the month of the year. However, as the rate structure becomes more complex by
utilizing average consumption, weather, impervious/pervious area, lot size, etc. the maintenance
of this ancillary data can become difficult and time consuming for city staff. The timely and
accurate maintenance of this data is an absolute requirement. Data entered in error can result in
unbilled accounts and increased customer complaints. Standard information, such as lot size,
which does not change by month, is supported in a variety of ways by all the vendors
interviewed. However, any variable information which requires daily or monthly updating, such
as monthly adjustments for ET, is not supported by all vendors and may require modification to
support the city’s specific requirements and needs. However, at this time, the city does not
anticipate having water budgets that adjust for actual weather.
7.6 Wastewater/Stormwater/Flood Management
In addition to billing for water, the city of Boulder currently bills for wastewater, stormwater and
flood management fees. The vendors included within this study all support utility customers that
bill for these services. Currently, the elements used within these fee calculations include meter
size, inside/outside city, average winter consumption, lot size, and impervious area. As has been
discussed throughout this document, these are all elements that are contained within the vendor
CIS products chosen for this study.
7.7 Cost Estimates
As discussed above, there are some potential rate structures that are supported by the vendors
interviewed within this study. However, if a water budget rate structure is selected by the city,
the number of vendors that will be able to support the new rate structure, without modification,
will be reduced depending on the complexity of the final water budget rate structure selected.
Some of the vendors interviewed have indicated that they currently support clients utilizing some
form of water budgets at one or more of their client sites. These vendors include: Open C,
PeopleSoft, Cayenta, Systems & Software, Hansen, and Harris Computer Systems. These
Review of the Rate Structure Alternatives and Billing System Vendors 7-11
City of Boulder—Volume 2—Utility Billing System Evaluation
vendors can configure, without modifications, their systems to support some implementation of a
water budget.
As the city progresses with this process there are a number of items to consider. First, when
speaking to a vendor about a “water budget rate structure” the city needs to insure that there is a
common definition. Next, the city needs to consider whether the elements necessary to calculate
the water budget allocation are available without modification. Finally, if the software must be
modified, the city needs to consider the complexity of the modification. A modification must be
replicated each time that the system is upgraded from one release to another. This includes both
business features and technical upgrades. Vendors will charge a fee for retrofitting the
modification into a new release. More complex water budgets may require initial modification
costs that range from $4,500 - $40,000.
In addition to the previously mentioned vendors, there are two additional vendors that, while not
currently supporting clients utilizing water budgets, may be able to support the requirements for
the city of Boulder. These are Eden Systems and Axiom Corporation. Both of these software
vendors provide CIS products to the municipal utilities market and would be viable options for a
replacement CIS system. Eden Systems does not support water budgets in their current product.
However, Otay Water District is currently implementing Eden Systems and has utilized water
budgets in the past. At present, Otay uses a multi-tier inverted block rate structure, rather than a
water budget rate structure that utilizes monthly water allocations However, Otay is working in
partnership with Eden Systems to expand their product. The addition of water budgets has been
discussed. However, until more clearly defined; it is unknown as to whether this addition will
support the city’s requirements. Axiom does not have any clients billing water or sewer,
however; they model their rates within EXCEL. Therefore, if the rate can be calculated in an
EXCEL format, then that rate structure can presumably be billed.
Some vendors consider the long-term effect on their product and future migrations. Vendors
such as HTE will modify their system if they believe that the enhancement will enrich their
system. Any modification that is not likely to be used by others, or is deemed too complex by
the vendor, will typically not be estimated or offered in an initial RFP response from the vendor.
This does not mean that the city would not be able to ultimately obtain such a modification from
the vendor. It simply means that the vendor would rather not modify their system to that extent.
However, if pressed, the vendor would probably do so for a premium charge.
7.8 Summary
The majority of the components within the rate structures being evaluated by the city are
supported by existing software vendor products. These components include the customer
classes, summer/winter rate differentials, the tiered (inverted) block structure, history based
consumption calculations and the additional information such as impervious area, lot size,
pervious area, and number of living units. However, many of the water budget rate structures
reviewed included options for utilizing historical weather and ET. When reviewing these
structures consider the following: the recalculation of the water allocation from month to month
will require specific logic for the city. The cost of this CIS modification will vary depending on
the flexibility of the vendor’s current product, and the complexity of the rate structure. As the
Review of the Rate Structure Alternatives and Billing System Vendors 7-12
City of Boulder—Volume 2—Utility Billing System Evaluation
rate structure becomes more complex, the access to information via reports and ad hoc queries
may become more complex even with additional effort from city Information Technology and
vendor staff. Ongoing considerations for the city include ease of daily use, resources required
for accurate and timely billing, and the ability of the system to produce reports for consumption
and rate analysis.
In summary, it would appear that all of the non-water budget rate structures can be handled
currently by vendor software with potentially little or no modifications. The exception to that
comment is the calculation of average summer consumption and average monthly consumption
based upon a three-year historical period. In contrast to this, the water budget rate structures
may be difficult for vendors to provide, depending upon the level of complexity of the final rate
structure. Even the simplest water budget rate structure may have a limited number of vendors
capable of billing a water budget rate structure, without some modification to their software.
The more complex water budgets may have a very limited number of vendors, and would
probably require custom modifications.
Review of the Rate Structure Alternatives and Billing System Vendors 7-13
City of Boulder—Volume 2—Utility Billing System Evaluation
Section 8
Billing System Evaluation Recommendations
8.1 Introduction
The objective of the billing system evaluation was to provide a business process review and
functional needs analysis. At the same time, an evaluation of the “build versus buy” option was
conducted, along with reviewing the potential vendors for a pre-packaged system. Next, a peer
review was undertaken. Finally, an evaluation was undertaken of the potential vendors that can
support the rate structures being reviewed by the city.
This report is the beginning of a process to provide better tools to support the city of Boulder’s
client base and utility goals and objectives. An improved billing system can automate processes
that could improve productivity and eliminate duplication of data and manual effort. These
automated processes could be provided by expanding the current system, redesigning and
developing a system to meet the specific needs of the city or purchasing a vendor supplied
system. Obviously, there are advantages and disadvantages to each potential solution, which
must be carefully evaluated and weighed by the city.
Other communities have experienced similar challenges to the city of Boulder. The most notable
is the drought that the western states have experienced over the last few years. The peer review
provided some perspective about how these utilities approached both their rate structures and
information processing. Many of these peers have replaced their billing or customer information
systems within the last few years. Technology and better information access were found to be
the primary reasons for this replacement.
From analysis conducted as a part of this study, a number of conclusions and recommendations
have been reached. Provided below is a discussion of the billing system recommendations.
8.2 “Buy versus Build” Recommendations
The business process review conducted for the city identified key requirements that are not
negotiable. These requirements would integrate the organization to efficiently support the city’s
customers. In addition, the rate structure changes being discussed would necessitate significant
changes to the current billing system. Therefore it is a logical time to review how these
requirements will be supported. As discussed throughout this document, vendor supplied
software products have improved and matured. These software packages have benefited from
the technology advances that enable a vendor to install the same product in two different client
sites, configuring the system to meet the unique requirement of both utilities.
Billing System Evaluation Recommendations 8-1
City of Boulder—Volume 2—Utility Billing System Evaluation
It is Langham Consulting’s opinion that the next step for city of Boulder, once a final rate
structure is selected, should be to complete the final definition of the functional requirements and
release a Request for Information (RFI) for a new Customer Information System. Only after
reviewing the responses to the RFI will the city know whether there is a vendor supplied package
that can meet all the city’s requirements. The city has been supplied with a detailed list of the
weighted requirements defined during this study. The weighting designates the importance to
the city. Consideration should be given to a vendor product that can meet all the “must provide”
requirements, with the expectation that some of the lesser requirements will have to be delayed
or scaled back.
At this time, Langham is of the opinion that the benefits to purchasing a vendor supplied product
out-weigh the benefits of building a custom product. Langham reaches this conclusion based
upon the fact that a vendor software product would be available and ready for configuration,
while involving less risk and more control of total costs. As discussed in the buy versus build
section of the report, a major concern with any custom built product is the risk of quality, timely
completion and cost. That is not to say that pre-packaged software is not without risk, but the
risk is likely reduced and more manageable.
8.3 Potential Vendors
It is important to cull the list of vendors that could supply a pre-packaged software solution for
the city’s requirements. Most of the requirements detailed in the functional specification within
this document can be supported by software vendors focused on the municipal market.
As described in Section 7, if a water budget rate structure is selected by the city, the number of
vendors that will be able to support the new rate structure, without modification, will be
significantly reduced. Vendors that have supported some form of water budget in the past
include: Open C, PeopleSoft, Cayenta, Systems & Software, Hansen, and Harris Computer
Systems. Each of these vendors is being used by one or more of the peer communities included
within this study. They have varying experience with the municipal utility requirements, but
have successfully supplied software to this market.
If the city chooses not to implement a water budget rate structure but continues to utilize an
inverted block rate structure, the number of vendors greatly expands. However, Langham
continues to recommend the selection of an experienced vendor in the municipal market. Many
of the CIS vendors supply software to government agencies and utilities. However, there is a big
difference between requirements for an investor owned utility compared to a municipality.
Therefore, consideration should be given to the rest of the nine (9) vendors included in this
study. Each has experience in billing all the services supported by the city.
Any of these vendors could provide the solution needed at the city of Boulder. Many times the
selection of the vendor is determined not only by what the product currently can do, but the
technology and business direction of the software product. Finally, it is important to view a
vendor product purchase as a long-term partnership.
Billing System Evaluation Recommendations 8-2
City of Boulder—Volume 2—Utility Billing System Evaluation
8.4 Summary and Next Steps
The business process review conducted as a part of this study has provided the foundation to
begin the process of moving forward with an RFI. In doing so, it is important to use the business
process review in an effective manner. When an organization uses the same business processes
for many years there is a tendency to accept what is currently being done. Only when new staff
or other changes are introduced is the process reviewed and questioned. However, when the
business goals are being achieved, that typically implies that funds and attention that could be
focused on the billing system, are focused elsewhere. The rate structure review and subsequent
business process review has provided an opportunity for the city to step back and evaluate their
needs. Even before the final rate structure is defined, there is the potential for changes in the
city’s business processes. Whether the city of Boulder modifies their current system, custom
builds a new system or purchases a pre-packaged vendor product, the city has the beginning of a
roadmap for improvement. A final course of action will be determined after the city has selected
a water rate structure to implement and has completed the RFI process.
Billing System Evaluation Recommendations 8-3
City of Boulder—Volume 2—Utility Billing System Evaluation