Utilities Management Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does outage scope get written as a screen instead of an event pipeline?

Most utility operations builds go wrong in the first fortnight, when someone writes a requirement saying the dispatcher needs one screen showing outage calls, meter pings and device status. That is a reasonable sentence and it produces the wrong system. A screen is a view. What a storm actually needs is a pipeline that ingests interactive voice response call records, last-gasp events from the Itron, Landis+Gyr or Sensus head end, and read-only status points from the control room, normalises them into a single event stream, and rolls that stream up against your transformer-to-meter connectivity model to predict a protective device.

The difference shows at hour three of an ice storm. Three panels leave the correlation in the dispatcher's head, which is exactly where it lived before you spent the money. A pipeline puts one predicted device in front of her with the calls and pings that support it, and she confirms it with a click.

The fix is a scope test you can apply before you sign anything. Ask the developer to describe what happens to a call that arrives four minutes after a recloser lockout on the same feeder. If the answer is that both appear in a list for the dispatcher to interpret, you are buying a dashboard. If the answer is that the call attaches to the existing predicted outage and does not create a second event, you are buying the thing that helps. Write that behaviour into the acceptance criteria rather than into a wish list.

What goes wrong with the connectivity model your prediction depends on?

Outage prediction is arithmetic over your transformer-to-meter mapping. If that mapping is wrong, the arithmetic is confidently wrong, which is worse than no prediction at all because dispatch will trust it for about two storms and then stop.

The mapping degrades quietly. Services get moved during a rebuild and the as-built sits in a job folder for three months. Meters get exchanged and the new serial never reaches the geographic information system. Acquired territory arrives with a connectivity model somebody digitised from paper. The result is a system that predicts beautifully on the newest feeders and badly on the oldest ones, and nobody can tell you which is which.

Fix it with a reconciliation before you build anything else. Match service points in the customer information system against meter inventory in the head end against connectivity in the geographic information system, and produce three lists: meters with no transformer, transformers with no meters, and serials that disagree between systems. That report is usually uncomfortable and it is always cheaper to run in week one than in month nine. Then carry a confidence rating per feeder into the build itself, so prediction degrades explicitly on the feeders you know are weak rather than silently everywhere. The other half of the fix is structural: the field work order application has to write as-built edits back for engineering review, or the model you just cleaned starts drifting again the day after go live.

Why do MultiSpeak and head-end integrations break after launch?

Integration in this domain is not a one-time connection, it is a standing relationship with three vendors who upgrade on their own schedule. MultiSpeak version mismatches between your customer information system and your outage management system are the usual first casualty, because both vendors support the standard and neither supports exactly the same revision of it. Head-end interfaces change with firmware and platform releases. Certificates expire on a Sunday.

The second breakage is volume. A read path proven against a quiet Tuesday export falls over at fifty times normal event rate, which is the only condition under which anyone cares whether it works. Utilities discover this during the first real storm after launch, when the queue backs up and the dispatcher goes back to paper.

Two engineering decisions prevent most of it. First, contract tests against every endpoint, run nightly and alerting a named person, so a vendor upgrade shows up as a failed test on a calm morning rather than as a silent gap during an event. Second, queue-based ingestion with buffering and replay, so a head end that goes away for twenty minutes produces a delay rather than a permanent hole in your event history. Ask any prospective developer what the system does when the outage management system stops accepting writes mid-storm. The honest answer involves a durable queue and a documented degraded mode, not a promise that it will be up.

What happens when reliability reporting is not covered from the start?

Reliability reporting gets deferred on almost every one of these projects because it feels like a phase two report. Then something worse than a missing report happens. Your new pipeline now holds outage events that the outage management system never saw, so the two systems disagree about how many customers were out and for how long, and the engineer preparing the commission filing quietly picks whichever source produces a defensible number.

The root cause is that cause code and affected customer count were not made mandatory at the moment of confirmation and restoration. Retrofitting them means a year of events you cannot use. Major event day exclusions under the IEEE 1366 beta method then get computed by hand in a spreadsheet, which is exactly where an auditor will push, and Rural Utilities Service Form 7 becomes a two week project every year forever.

The fix costs very little if it is done at the start. Make cause code, device, and customer count required fields on confirmation and on restoration. Store events immutably so a restoration correction is a new record rather than an overwrite. Compute the reliability indices continuously from that store, flag candidate major event days automatically, and make every figure in the export click through to the source events. The reporting stops being a project and becomes a review.

Should you build custom or configure what you already own?

If you are under roughly 10,000 meters, bill standard residential rates, and live inside one vendor suite, configure what you have and do not build. Buy the advanced metering infrastructure integration module for your outage management system even though it carries a per-meter fee. Turn on the outage map and notifications in SmartHub. Use the work order module in NISC iVUE as it ships. At that scale the module fees are genuinely cheaper than a build, your dispatcher knows every feeder by name, and the vendor roadmap will reach most of your gaps before a custom system would pay for itself.

Even above that size, our position after building in this category is that you should not replace the customer information system. iVUE, SEDC and Daffron should stay the record for money and members. Milsoft should stay the outage engine your dispatchers already know. What you build is the correlation layer between them, the offline field application, and the member notification service, all exchanging data through MultiSpeak and vendor interfaces. The build case starts when staff re-key the same job into three systems, when rate changes are quoted in quarters, and when storm response depends on one person's memory.

How do hidden costs get into the quote?

The commonest is integration counted as one line. A quote that says integration with existing systems is hiding the fact that a second head end, a control room historian feed and a work management system are three separate pieces of engineering with three separate access approvals. Insist on a price per endpoint and a named owner for each.

Storm-load engineering is the next one. A system built for average volume and load tested at average volume is not finished, and the work to make ingestion, notification and the database behave at fifty times normal is real. Ask for the load test target in the proposal.

After that: connectivity model cleanup, which is data work and belongs in the budget rather than in the assumptions; offline capability for territory with no coverage, which is a different architecture rather than a setting; the security boundary work to keep the system outside your electronic security perimeter; and parallel running, because you will operate the old process and the new one through at least one storm season. None of these are surprises to anyone who has delivered in utilities, which is precisely why their absence from a quote tells you something.

What separates a build that works from one that fails here?

The teams that succeed do four things. They measure the metric before they start, usually average time from first call to correct crew arrival, or days from job completion to as-built posting, so the argument about value is settled with numbers rather than opinion. They pick one thing for release one, prove it in a real event, and expand from there rather than launching a platform in October.

They test domain understanding before contract signature by asking the developer to whiteboard how a call rolls up through a transformer and a tap fuse to a recloser, and what happens when the connectivity model is wrong. A team that cannot do that will model your outages as a flat ticket queue and you will find out during a storm.

And they settle ownership and boundaries in writing at kickoff: the repository in your own account from the first commit, custom systems outside the electronic security perimeter with one-way read-only feeds, and enough accounting literacy that work order costs land in the right plant accounts. A practical next step is to pull your last major event, lay the call log, the head-end events and the outage management records side by side on a table, and ask a candidate developer to show you exactly which of those records their system would have joined automatically.