How many utilities that purchase AMR systems are less than impressed by the data reporting and archiving capabilities of their system? Of all the aspects reviewed in selecting an AMR system, the operation and data management capabilities of the AMR control computer are the least focused on – and ultimately the least understood.

It is not out of line to say that most AMR vendors are hardware- centric and hence the top priority is to ensure the actual AMR module has the ability to interface to multiple meters, decipher various protocols and send the data over a communication medium to a control computer. The software development is secondary. The development effort necessary for the management of thousands or even hundreds of thousands of AMR modules often comes later – in some cases, after the deal is secured to supply the hundreds of thousands of devices to a particular utility customer.

Invariably, as these AMR systems mature, some vendors have become more proficient and are providing more sophisticated levels of data collection and management software. All vendors will say their AMR provides the fundamentals:

  1. Retrieval of meter reads.
  2. Ability to query read success.
  3. Reporting features for tracking and managing unsuccessful read attempts.

How these functions are accessed, how easy it is to get to the necessary information and how easily a utility can ascertain the actual issues occurring in the field and despatch a work order can often be another story!

While the AMR vendor is one facet of why meter data management is not fully realised or utilised in many AMR system installations, the utility is often the other component that hampers the launching of the enhanced data collection features that promise to optimise day-to-day operations and customer service.

For anyone who has checked AMR deployment progress in conjunction with the actual realisation of all the benefits that can be acquired from the AMR system, the following information quite adequately indicates progress levels in how these benefits are being achieved.

LEVEL 1

Utilities continued to read meters based on the manual meter reading cycles, even after the AMR system is fully deployed and operational. In many cases these utilities never keep more than the monthly meter read that is required to send the bill to the customer. Departmental processes remain the same, and the utility, for whatever reason, chooses to ignore the promised benefits associated with collecting and storing more data, even if it is possible with the AMR system they have deployed!

LEVEL 2

Utilities may collect and store in the AMR control computer
30-40 days’ worth of individual customer meter data for bill verification. The final meter read for billing purposes is the only data transferred to the CIS at the end of the month. Data is purged, as the capacity to store beyond the 30 days requires an enhanced level of investment in personnel and funds. Database management, reporting and storage or data archiving and report generation on historical data beyond monthly reads is simply not a part of the base AMR system purchased.

LEVEL 3

Utilities collect and store all reads in a separate data warehouse, and build customised reporting modules to address identified operation optimisations and customer services programmes. These programmes were highlighted as having intrinsic value to the utility, and while the tangible benefits were not articulated in the business case, they were part of the strategy for purchasing a more robust data collection system.

Does it seem shocking that few utilities are actually at level 3 in their AMR data management activities? In all fairness, many may have moved to varying degrees beyond level 2, but few are actually realising concrete benefits derived from using the meter data as outlined in level 3.

Why do utilities continue to search for the quantification of operational benefits beyond the traditional cost justification line items associated with tried and true tangibles if they are not prepared to implement them themselves when they finally install an AMR system worthy of these expectations?

FOUR SPEED BUMPS ON THE ROAD TO USING AMR DATA

Speed Bump 1
Engineers pivotal in the initial AMR selection process and development of the business strategy often ignore the concerns and questions of marketing and energy service staff. Marketing and energy service staff may have originally been part of the AMR selection team, but when their needs or interests are not addressed they tend to lose interest in the AMR project, and feel no ownership regarding its success when it is finally implemented. Early alienation of these staff members – who are ultimately the end users of the system – is often the key reason why utilities do not move much beyond the replacement of the manual process with automation.

Speed Bump 2
The AMR system is able to complete the data collection process, but the operation to consolidate the data is so intensive or onerous that the utility loses interest in moving beyond the basic read and bill initiative.

Figure 1

Speed Bump 3
The original enthusiasm and high profile of the AMR selection, strategy and deployment diminishes over time. The resources dedicated to the initial championing of the process lose their lustre as the daily grind of installing units takes over. By the time the units are in place, the staff and expertise needed to facilitate the data utilisation have been side-tracked by the next high-profile initiative currently underway at the utility.

Speed Bump 4
The AMR software that comes with the engineer-selected resilient hardware does not actually perform to the level that enables the data to be stored, archived and put in reportable/useful format. IT requirements are necessary within the utility to integrate this data into a common platform that enables the easy access of this information by multiple utility departments. These IT people were not part of the project decision-making process and have little interest in giving this new task top priority status without direction from senior management.

DODGING THE SPEED BUMPS

Get a Champion
The person in charge of the AMR project is pivotal to its long-term success. If this is just a metering project with visibility diminishing after its implementation, the system may end up being run by whoever is left. Strategic goals must be championed by a champion.

Set Goals, Reach Targets
Weekly meetings that structure and retain the focus of the project must be conducted while continuing to move toward the original project goals and adhering to timelines and deliverables. Sliding schedules diminish credibility.

Involvement by Multiple Stakeholders
Cross-departmental participation from staff from IT, CIS, metering, energy/water/gas management, customer services, billing and planning should be present and active in all on-going AMR meetings.

Timely AMR Project Branded News
Regular updates of recent successes, feature articles of AMR project staff, successes with installations and the use of data to achieve promised benefits and customer satisfaction go a long way to building support, appreciation and support for the on-going development of the AMR data initiative.

USER GROUPS

The need to be active and participate in or initiate a users’ group for your particular AMR system is critical. Many utilities, especially those that are short on resources, will find this is the best way to retain their original enthusiasm for the system. The ability to network and to develop contacts with peers in order to share operation and programme-related experiences is the best vehicle for enticing utilities to take the initiative to step forward and use AMR usage data to realise those intangible benefits.

Utility leaders in AMR have developed their own data management tools, built or requested custom software modifications from vendors, purchased middleware, and are willing to share insider operation tips on how to get to full use out of AMR data. Most acknowledge the AMR vendor must have robust hardware, but actual data management beyond the AMR control computer is something that can often be acquired or developed and managed by middleware software options.