Archive for the water billing software Category

Detecting theft

One of the issues a utility faces is theft by its users.  Most often this is occasional, where a fire house outlet is used to wash the adjacent floor.  Some however is persistent, where the consumer manages to by-pass the meter by intercepting the supply before it reaches the meter, and diverting it.  Water billing software can sometimes be used to detect this activity, by reporting on abnormally low consumption.  Most utilities concentrate on consumption that is abnormally high - no-one wants to send out a large bill if it is incorrect

Reviewing abnormally low consumption is done less rigorously, as there can be multiple reasons including a vacant property.  One of the more common requirements from those looking for a new water billing sytem is detecting when there has been low or zero consumption and then consumption rises - most usually when somneone has moved in and not advised the water company.  Monitoring low consumption for possible theft by itself is a lesser requirement, and is usually met when a meter reader visits the premises and observes a by-pass pipe.  However, with the increasing use of remote reads, a water thief may get away with illegal use for considerable periods of time if physical observation has been the main means of monitoring.  Water billing software in the future will need to provide more rigor in reviewing patterns of consumption, both high and low

Automated water meter reads

Water utilities continue to move towards remote automated meter reads to support their water billing software.  How such a solution will scale up remains to be seen.

For example, in Wisconsin the Baraboo Water Utility will begin replacing 4,578 aging residential, commercial and industrial water meters over the next few years with meters that can be read by remote control, the Barbaroo News Republic reports.  Interestingly the same story states that Council is also spending $26,600 for new water billing software, thus indicating yet again that large sums of money do not need to be spent to acquire simple water billing software.  The total contract is for $1.2 million for the meters, related computer software and services.  The metering supplier is H D Supply Waterworks of Sun Prairie, and the program for changing out the meters will be carried out over two-and-a-half years.  City workers will replace the old meters while a contracted management team calls residents and businesses to schedule days when workers visit them.

When installed every house and business will have a radio box and that box communicates with a central tower; all that data will go straight to the City Services Building.  The data will then be imported to the water billing software.

What German utility billing software would that be?

Stories have hit the Johannesburg press about problems with the city’s new water and electricity billing software.  It’s the thing that all billing managers fear – stories of incorrect bills and angry consumers getting into the newspaper.  Neither of the stories have reported the name of the software being used, but the chairman of the Finance Committee is reported as saying “German specialists were periodically brought in because the billing system had been designed by a German company.”  That’s all pretty clear then.  However the problems as reported seem to lie not so much with the software but with the implementation.  Mayor Amos Masondo admitted that Project Phakama - to set up the new billing system - had not been implemented fully, with two of five modules not put into effect.  There also seems to have been an issue with customers old accounts not having been migrated to the new system.  The two stories – and you can bet there will be others – about the electricity water billing system can be followed up here and here.

Comparing utility billing software

Not the product manager

Not the product roadmap

Screwing up

The Register has a recent, chatty article about successful implementations – ERP (again) but the general principles apply.  Their first point goes to the heart of the services we offer:

It’s obviously necessary to define your requirements appropriately and select a package that fits. Indeed, one of the most prominent recommendations coming back from Reg readers is to minimise the amount of development work associated with customisations and extensions. You can only do this if you start out with a reasonable match between the software and your requirements. And of course when modifications to standard functionality are necessary it helps if the software you have chosen is based on an open platform that is easy to work with from a development and integration perspective.

Do projects ever end?

In the public sector, the billing system usually represents the biggest single entity within the IT environment.  However even if the billing system  doesn’t account for a lot of the infrastructure per se, it is one of those applications (or suites of applications) a lot of other stuff needs to be plugged into. It’s therefore not something you can easily put to one side and forget about.

The truth is that while everyone focuses on the initial implementation project when considering the cost and resource requirements of the billing system, it doesn’t all come to a nice sweet end after the initial go-live. Whether it’s looking after the beast itself from an operations, maintenance or enhancement perspective, or making sure it remains properly integrated with everything around it, the end result is typically a significant ongoing effort on the part of the IT department.

In terms of routine activity, there’s the usual application of patches and fixes from the vendor, which could be to do with minor functional enhancements, the implementation of regulatory changes, or more systems related things such as supporting the latest upgrade to the database management system upon which the application depends. There’s then the more traditional systems ops side of the equation, ranging from patch management and maintenance of the underlying hardware and platform software, through storage and information management, to performance monitoring and management, including troubleshooting server, storage and network issues as they arise.

In addition to this core activity, an area that has become more of a consideration over the past few years in particular is security and access. As billing systems have been opened up to broader and faster moving audiences, especially customers, more thought and effort has needed to be given to user provisioning and making sure access routes are properly secured. And, of course, the billing system needs to be kept in sync with everything else from a policy perspective.

Some of these developments have come about quite naturally as technology has evolved and opportunities have arisen to take advantage of new ways of doing things within the business. In other areas, technology advancements have also enabled efficiencies to be introduced into the underlying platform. Modern servers, for example, can reduce the cost of ownership considerably when you look at improvements to price performance, energy consumption, space requirements and - not least - manageability. And improvements at this level are not going to let up, so the occasional replatforming project is inevitable in most organisations, with all of the migration work that goes with it.

Beyond the systems side of things we have the day-to-day keeping up with what’s going on in the business. This includes handling change requests for minor modifications and enhancements to the system, and here it is not just the technical work that needs doing, but managing the whole review and approval process, which can understandably be quite strict in some organisations where even a relatively minor mistake could easily have disastrous consequences from a business integrity, continuity and regulatory point of view. All of this adds to the overhead on IT, without even thinking about more substantial projects such as major package upgrades, implementation of new components/modules, extension and customisation work, and integration overhauls as other systems with which billing is inter-dependant are changed or added, etc.

In some organisations, the level of ongoing activity is such that they maintain permanent development and test environments alongside the live system to control and manage the throughput.

Implementing the software wisely

In the second part of a recent Computerworld series on ensuring software implementation project success, Ian Anderson, director at SAP services company DNAstream sets out four elements that he regards as critical:

The first one is a telling reflection on SAP in particular:

“The chosen software must be able to meet the required business processes, not absolutely, but at least to a level that is agreed in advance as acceptable, perhaps a 70% to 80% fit. This is often achieved through a level of compromise, such as adapting the business processes to fit the software where possible.

It is essential to have these business processes identified, documented, understood, mapped to the software and signed off by the business before you start implementation.”

A lot of billing folks would regard a 70 to 80% fit for billing to be a failure.  To be fair to Anderson, he was talking about ERP.

The second is “choose the vanilla flavor”.  In billing that’s not always possible, as billing rules are often mandated by external agencies and regulators.  Here’s what Anderson says:

“The overwhelming advice is to keep the software as standard as possible to avoid potentially costly effort on support and future developments, including upgrades. This is often referred to as vanilla ERP.”

His third point is always a timely one, especially where utilities rush out to get advice from a big-name consulting firm, as if that minimises their risk – use a consultant who understands your business and will know the best approach for you, rather than simply repeating the method he used at his previous client.

Lastly, “Constantly check and review during the project.”  A well-managed project is a prerequisite for a successful implementation.

The care and feeding of the product manager

Henry Ford once declared that if he had only listened to his customers he would have built a better horse and buggy.  While listening to a customer is an important part of the effective product manager’s role, turning what he has heard into enhanced functionality needs a different skill-set than just listening.  The produce manager must be able to make the leap of how emerging software technologies may be able to deliver the outcome in an entirely new way.  What Henry Ford heard was his customers expressing a desire to get from A to B quickly, safely and cheaply.  He was able to turn that desire into a completely different transport paradigm.  The effective billing manager should be able to do the same.