The core system is twenty years old and nobody touches it. Meanwhile the new work lives in spreadsheets.
In utilities you don't replace legacy: you surround it. Pwas builds the missing layer on top of existing systems — contracts, field work, case handling — without asking you to switch anything off.
Nobody replaces the billing system. But nobody can keep waiting for it either.
In a utility the core system works, was expensive, and is high-risk to touch: it holds contracts, meter data and billing, and an error there hits thousands of customers immediately. The problem is that everything created since — a new service, a new disclosure duty, a digital customer channel, field work management — doesn't fit into it, or fits at a cost and timescale nobody accepts. So every new requirement spawns its own tool: a spreadsheet, a departmental database, an application bought in a hurry. Ten years on, the company has a solid core system surrounded by twenty islands that don't talk.
illustrative scenario
A new connection request at a regional multi-utility.
A customer requests a new connection. The request arrives at the counter, is logged on a worksheet, and from there begins a journey across four systems and three departments: the engineer schedules the survey in a separate diary, the outcome comes back as a PDF report in a network folder, the quotations office calculates the amount on a spreadsheet holding the current tariffs, the customer's acceptance arrives by email, the works are assigned to a crew through another application, and finally the activation has to be recorded in the core system.
Every step works. But the process as a whole exists nowhere, and that produces two constant consequences: nobody can say precisely where a case stands without phoning three people, and the end-to-end timings — the ones the company has obligations on and the customer judges it by — are measured after the fact, when it's too late to act.
What changes with Pwas
The core system isn't touched: it remains the ledger for contracts, meter data and billing. Instead, we describe the process that today has no owner: a connection case has an applicant, a supply point, a type; it involves a survey with a structured outcome, a quotation calculated with the tariffs in force at the date, an acceptance, a works assignment and an activation; every phase has a deadline, an owner by role and explicit conditions for moving to the next.
From that description come the counter screens, the department queues, the field application for crews and the management dashboards. The core system is read and written through its interfaces, or — where it has none — through structured file exchange, which is the reality of many systems of that generation. Legacy isn't replaced: it's surrounded by a layer that knows what's going on.
The same case, afterwards
The request comes in and the case is created with its deadline calculated. The survey is scheduled by the system, which knows crew availability and the zone; the engineer records the outcome in the field on a tablet, with the structured fields that type requires, and the photos stay attached to the case instead of ending up in a folder. The quotation is calculated from declared, versioned tariffs, not from a spreadsheet somebody has to remember to update.
Management, meanwhile, looks at a dashboard and sees how many cases are at risk of breaching their deadline, by type and by zone, right now — not in next month's report. When the customer calls, the counter answers in twenty seconds. And if the company chooses, the customer checks the status themselves.
When a new reporting obligation arrives
A regulatory decision introduces an obligation to record and report an additional data item for a category of cases, effective shortly. On the core system that would be an expensive, slow and risky change; conventionally it gets solved with yet another parallel spreadsheet that somebody will later have to reconcile.
In the declarative layer it's adding a field with its conditional mandatoriness and, where needed, a control preventing case closure when it's missing. Screens, the field application and the extracts know about it without anyone modifying them. The adjustment happens inside the effective-date window, which conventionally almost never succeeds.
the comparison
What happens today, what happens afterwards.
The recurring situations in a company with a historic core system and many processes created later.
Today
The process lives in the gaps between systems
A case's status is reconstructed by phoning three departments.
Survey outcomes are PDFs in network folders, not data.
Quotation tariffs live in a hand-maintained spreadsheet.
Process timings are measured after the fact, when you can no longer act.
Every new obligation spawns a parallel spreadsheet to reconcile.
Touching the core system is too expensive and risky, so it doesn't happen.
With Pwas
There's a layer governing the process
The case has state, owner by role and a calculated deadline, visible to whoever has permission.
The survey outcome is structured data captured in the field, with photos attached.
Tariffs are declared and versioned, with the correct effective date.
At-risk timings are visible on a real-time dashboard, by type and zone.
A new obligation is a field and a rule, adjustable within the effective-date window.
The core system stays untouched and keeps doing its job.
how you get there
The path, concretely.
Designed around the main constraint: the core system isn't touched.
01
We map the process and its islands
We follow one real case end to end, noting every system, spreadsheet and manual step it crosses. The map of the islands is the map of the work to do.
02
We check what legacy can give and take
Decisive, and done early: which interfaces exist, which file exchanges are already in use, what constraints those who maintain it impose. It determines what is realistic, and must be clarified before promising anything.
03
We describe one process, not all of them
We pick a representative process — typically connections or field work — and formalise it: phases, deadlines, roles, field-captured data, transition conditions. You validate it.
04
Real operation in one zone or type
It goes into use on a narrow scope, with real crews and real customers. This is where operational exceptions emerge, and they get formalised as they appear instead of being worked around with a spreadsheet.
05
Rollout and internal ownership
We extend to the other processes, repetitions of a validated pattern, and train internal staff on maintaining the configuration, so regulatory adjustments don't depend on a contract cycle.
an example flow
From request to activation, without four systems.
The request is registered once, the survey runs on mobile even with no coverage, the works order is tracked and activation closes the loop with billing.
what changes structurally
Properties of the system, not promised outcomes.
Characteristics verifiable in a demonstration, not performance figures from other utilities.
0
changes required to the core system
The declarative layer is built on top of legacy, reading and writing through what it exposes or via structured file exchange.
1
place where process state lives
Counter, technical departments, field crews and management read the same data, instead of separate extracts and spreadsheets.
versioned
tariffs and rules, with effective dates
A quotation stays readable with the values in force when it was produced, even after tariffs change.
same day
the time for a new field or control
A new reporting obligation is a configuration change written, verified and published on the same day.
These figures describe how the platform works, not results measured at specific companies. The feasibility of integration with your core system must be verified at the start of the project and shapes both timings and scope.
in depth
The questions operations and IT directors ask us.
"Our core system exposes almost nothing. Can you still work with it?"
In most cases yes, but it's the first thing to verify and must never be promised sight unseen. Systems of that generation typically offer three routes, in order of preference.
Application interfaces, where they exist: the best route, because it's synchronous and controllable.
Structured file exchange, which is the most common reality: periodic extracts inbound and return files with what was produced. It works well, provided frequency and discrepancy handling are designed carefully.
Direct database reads, read-only and agreed with whoever maintains the system: workable when the other two don't exist, but to be treated with care and never for writes.
What we never do is write directly into a billing system's database, bypassing its application logic. That's the shortcut that seems to solve everything and that produces the worst damage months later.
"Field crews are the weak point. How do you get them working?"
The criterion is the same as for any operational work: if recording costs more than it returns, it won't get recorded, and the project fails regardless of software quality.
In practice that means three precise choices. First: the engineer doesn't fill in a generic form but the fields of that job type, which the system knows because the type is declared. Second: as much as possible is captured without typing — photos, location, code scanning, pre-filled selections. Third: it works without a network, because the field is full of areas with no coverage; captured data stays on the device and syncs by itself when connectivity returns.
The benefit to the engineer must be immediate and obvious: finding the asset record without phoning the office, having the previous job history to hand, closing the report without going back to fill in paper. Without that, no company directive holds for long.
"Every regulatory decision has us playing catch-up. What really changes?"
What changes is where the rule lives. Today, in most utilities, a new obligation translates into three possible responses: a change to the core system, which costs and arrives late; a parallel spreadsheet, which arrives immediately and creates debt; or a manual procedure entrusted to people, which holds as long as someone oversees it.
When the processes live in a declarative layer, the adjustment is an edit to a configuration document: a new field with conditional mandatoriness, a control preventing closure of an incomplete case, an extract selecting the required data according to the declared rule. It's written, verified and published within a timescale compatible with the effective date.
What doesn't change, and should be said honestly: someone still has to read the decision, understand its implications and decide how they translate into your process. That's domain expertise and no technology replaces it. What disappears is the gap between the moment the decision is made and the moment the system applies it.
"We're being pitched AI everywhere. What actually holds up in our context?"
Little of what's pitched, and a few things very well. Nothing that decides on billing, metering or safety holds up, and it shouldn't: those are areas requiring deterministic, verifiable rules, not estimates.
Three things do hold up. Inbound documents: requests, case files, third-party reports and technical documentation arriving as PDFs or scans are read and their data proposed pre-filled, with human verification — the heaviest time cost in a case-handling office. Operational questions: "which connection cases in the northern zone are past their deadline and awaiting a survey?" becomes an immediate answer instead of a report request. Repetitive correspondence: draft customer communications pre-filled with the case's real status, for a person to check and send.
The structural guarantee, in a regulated sector, is the part that matters most: the agent cannot perform actions that aren't declared as possible for the user who asked. It builds a plan, the plan is verified against real permissions, sensitive actions require explicit confirmation and every step stays reconstructable. An agent doesn't close cases, doesn't change meter data and doesn't contact customers on its own initiative.
quick check
Is this your company?
Probably yes
You have a core system that can't be touched and new processes that don't fit in it.
The processes that matter cross several systems and nobody governs them.
Field crews produce documents instead of data.
Regulatory adjustments always find you behind the effective date.
You measure process timings only after the fact, when you can no longer act.
You have departments that have built themselves parallel databases and spreadsheets.
Probably not
You're looking for a billing or metering management system.
You need a SCADA or plant supervision platform.
Your core system already covers processes created in recent years well.
Those who maintain the legacy system can't be involved in the feasibility check.
frequently asked
Utilities and energy: the specific questions.
Will we have to replace the core system?
No, and that's the premise of the approach. Pwas builds the process layer on top of what exists, reading and writing through available interfaces or via structured file exchange. The core system remains the reference for contracts, meter data and billing. If you later decide to replace it, the process layer stays in place and only the way it exchanges data changes.
Does the field application work without a connection?
Yes, and we design for it explicitly, because coverage in the field is often missing. Captured data stays on the device and syncs automatically when connectivity returns. Which data can be captured offline and which requires an online check is decided together, because it depends on which steps cannot wait in your process.
Does it integrate with remote metering, GIS and field systems?
Where those systems expose data exchange interfaces, yes: each is declared as an external resource with its own calls and fields. The principle applied is that each system remains the owner of its data and the process layer references it rather than duplicating it. Integration scope is verified at the start, because it depends on what those systems make available.
Where does the data reside?
Where you decide: in your own infrastructure, on European cloud or in a mixed setup. For utilities with operational continuity or infrastructure data constraints, installation within their own perimeter is the most frequent choice and is a full deployment mode, not a reduced version of the product.
How long to the first process in operation?
For a well-defined process the order of magnitude is a few weeks from the agreed formalisation, plus the time for integration with the core system, which is the most uncertain variable and depends on what that system exposes and on the availability of whoever maintains it. That's why the feasibility check is the second step of the path and not the last.
How is it procured, if we're subject to public procurement rules?
The choice of procurement procedure rests with your contracting authority supported by its own procurement office. We can provide the technical documentation needed to prepare the file and take part in preliminary market consultations when they're run. We don't provide legal advice on award procedures.
We use technical cookies and, with your consent, analytics cookies (Google Analytics) to understand how the site is used. Read our Privacy & Cookie Policy.