Smart Meters, Legacy Back Office: What a Co-op Actually Inherits

The rollout finished and the work started

You approved an AMI project. The meters are on the poles, the head end is collecting, the vendor has moved to the next co-op, and your billing team is still reconciling exports by hand every cycle. Somebody on the board wants to know why a completed project produced a new recurring task instead of removing one.

That question has a specific answer, and it is not the one the meter vendor gave you.

You did not buy a meter project

A co-op that goes from twelve reads a year to one every fifteen minutes has changed the input rate of every process downstream by four orders of magnitude. The meters are the visible part. What actually changed is that a set of processes designed around a monthly, human-mediated read now receive a continuous machine feed, and processes do not scale by accident.

The metering industry says this about itself when it is being honest. A long-circulated industry perspective paper concedes that nearly all operational processes change in some fashion once smart meters are installed, with field services, operational compliance and meter maintenance most affected. That is the vendor side admitting the scope is operational, in a document most buyers never read, while the sales conversation stays on hardware and network coverage.

Page one of any search for this topic will tell you the answer is a meter data management layer, and that the back office is a wiring problem. Install the MDM, integrate to CIS and OMS, done. The MDM is genuinely useful and most co-ops should have one. But it is a place to put validated data, not a decision about what validated means, and it does not tell you which system is right when two of them disagree.

The first thing to break is not billing

Everyone braces for billing. Billing is loud, it has an owner, it has a deadline, and when it goes wrong the co-op finds out within a cycle. It usually survives, in the sense that member bills go out, because the billing team absorbs the difference manually. CSA, an MDM vendor writing about its own category, describes billing teams manually reconciling head-end exports against billing system imports as a process that can take days every cycle and raise the error rate. Read that as the vendor's own framing of the normal outcome, not as a worst case.

The thing that actually breaks quietly is the map.

Every co-op has a model of which meter hangs off which transformer, which transformer sits on which phase, and which feeder serves all of it. That model exists in at least three places. The CIS knows it as a service point tied to an account. The GIS knows it as a spatial asset with a connectivity relationship. The OMS knows it as a node in a restoration tree. Before AMI, nobody had to reconcile the three, because nothing in a monthly manual read exercised the relationship hard enough for the disagreement to surface.

Interval data exercises it constantly. Voltage and consumption patterns at fifteen minute resolution make the true electrical topology observable, and what they observe is that the records drift. The academic literature on distribution topology correction is direct about the failure modes: customers modelled on the wrong distribution transformer, transformers modelled on the wrong phase, assets present in GIS that were never physically installed. This is not sloppiness. Field crews swap a failed transformer at two in the morning and the paperwork follows a week later, or does not. Thirty years of that is a map with real error in it.

Nobody owned that error before, because nobody could see it.

Why the discovery lands as a staffing problem

Here is the sequence we see, and it is remarkably consistent.

The AMI system starts producing outage notifications and transformer load figures. Engineering looks at a transformer showing 140 percent loading and sends someone to check. It is fine. Three meters that GIS says are on it are actually on the unit next door. Operations looks at an outage that OMS rolled up to the wrong device and dispatched a crew to the wrong intersection. Reliability indices start moving for reasons no one can explain, because mis-associated meters change SAIDI and CAIDI arithmetic without anything on the grid changing.

Each of these is a small correction. There are thousands of them. And because the corrections have to be made in three systems that were never designed to agree, the co-op invents a reconciliation function nobody budgeted, staffed by whoever is least able to refuse it. The burden grows with the rollout, which is the opposite of how a technology project is supposed to behave.

This is a version of a pattern we see well outside utilities: automation makes an existing data problem legible, and legibility is expensive before it is valuable. We have written about the same dynamic in what an AI pilot costs when you include the parts nobody quotes, where data cleanup is the line item that turns a modest pilot into a large program. AMI is that story with a twenty-year asset attached.

What the honest sequencing looks like

The useful question is not whether to fix the map. It is what the map has to be right about, and by when.

Some AMI value needs no connectivity model at all. A last-gasp message from a meter is a device-level fact. The meter is telling you it lost power, and it is telling you the truth regardless of what GIS thinks it is connected to. Any capability that consumes only device-level facts can be turned on early and will behave.

Other value is entirely a function of the model being correct. Affected customer counts, nested outage rollup, estimated restoration times, transformer load management, phase balancing, hosting capacity for member solar. Every one of those is arithmetic performed on the connectivity relationships, and every one produces a confident wrong answer when the relationships are wrong. A confident wrong answer delivered to a member during an outage is worse than silence.

So the sequencing decision is a governance decision before it is a technical one: which system of record wins when CIS, GIS and OMS disagree, who is allowed to change it, and which capabilities you are willing to leave switched off until the answer holds. Co-ops that make that call before go-live spend money on correction. Co-ops that defer it spend the same money on correction and a second budget on the credibility they lost in between.

The related trap is treating the whole thing as a systems integration project when a real part of it is process ownership. That distinction is the subject of what workflow orchestration actually is, and it applies here directly. Integration moves the data. It does not decide who owns the answer.

The part we will argue against

If you are a co-op board being asked to approve an analytics layer on top of AMI data before anyone has quantified the error in the connectivity model, argue for the delay. Analytics built on a wrong map will produce outputs that look precise, get quoted in a rate proceeding, and become very awkward later. There is a general version of this argument in when AI is the wrong answer to an operations problem, and the utility version is sharper because the outputs are regulated.

Fix what the map has to be right about. Turn on what does not depend on it. Resist the rest until the data earns it. That ordering is unglamorous, and it is the difference between a modernisation that compounds and one that generates a permanent reconciliation desk.

Current is only useful when you know where it is going.

Where this gets specific

The general shape is above. The part that decides your outcome is not general: how much error is actually in your connectivity model, which of your three systems is closest to the truth, which capabilities your members and your board will judge you on first, and what order that implies for a co-op your size with your staffing.

That is a week of looking at your systems, not an article. If you are mid rollout, or finished and wondering why the work went up, talk to us. We will tell you which parts of the map you can afford to leave wrong.