Approach

Change the business first. Buy the software third.

Maxim Afanasyev, who heads financial services for Google Cloud across Asia Pacific and ran AI transformation at Standard Chartered before that, puts the order plainly: business change first, organisational change second, and technology ‘only the third one is a minor part’. His illustration is a 386 his father kept in the corner of a public-enterprise office and moved to the front of the desk only when the innovators from headquarters visited. This page is that argument translated from banking into battery-backed power, with five worked examples and one paragraph about what the evidence will not carry. The stack I deploy has its own page.

Afanasyev is Financial Services Industry Head, Asia Pacific and Japan, at Google Cloud. Sources are listed at the foot of the page; his quoted phrases are taken from the recorded interviews.

Read the threat correctly

Afanasyev's central claim is that the customer changed, not the technology, and his illustration is credit. A bank assembled data on who repays, found the attributes that predicted it and lent accordingly. The whole apparatus assumed the bank was smarter than the person across the desk. Now the applicant has an agent that can find the gaps in the approval process and shape an application to pass through them. His answer is not a better model but what he calls mechanism design, which means redesigning the offer so that it still produces value when the counterparty knows as much as you do. The parallel in stored energy is exact, and it has already started: any firm whose margin depends on the customer not knowing how a daily energy figure becomes a battery capacity, what separation AS/NZS 5139 demands of a cabinet against a boundary wall, or which released edition of AS/NZS 4777.2 a network operator is enforcing this quarter is charging for an information gap, and the gap is closing. He puts the consequence to directors as a question about themselves, whether running the old model in an AI-equipped market still discharges their fiduciary duties, and he leaves it unanswered. So will I.

Digitise the workflow before the assistant

The best thing in the interviews is a memory. As a boy Afanasyev visited his father's office at a public enterprise and found a 386 in the corner, the height of innovation to the children and abandoned by the adults. His father could do the same arithmetic in five minutes on a calculator that took thirty in Lotus 1-2-3. The machine came to the front of the desk only when the innovators from headquarters visited. The modern version is worse, he argues, because everyone is online now and somebody in the technology department can count logins, so the counting becomes the point. His sequence runs from a board under pressure to look ‘AI-driven’, through a vendor beauty contest, to a mandate to use the tool for writing longer emails and then surveillance of the logs to demonstrate ‘adoption’; it does not merely fail but “leads to productivity drains even”. Start with the evidence, not the interface.

Pay people to want it

He puts incentives before technology and is unusually direct about the order. Get the people on board so that they can see they will benefit, or accept the alternative, which is reward and punishment, and mostly punishment. This is the recommendation directors nod at and then ignore, because acting on it costs money in a way a licence does not. Take a senior application engineer whose standing rests on being the person who knows how AS/NZS 5139 treats a cabinet near a boundary; she has no reason to help build the thing that answers the question without her unless the firm has decided in advance, and told her, what she is worth afterwards. None of the examples on this page is a headcount reduction, and that constraint is deliberate rather than diplomatic. Afanasyev's own reading of a chief executive who cuts twenty per cent of the workforce and attributes it to AI is that the executive failed to adjust the business model, and is now advertising the failure.

His most practical suggestion follows from that. The people who understand the business logic and the people who write software are not the same people, and every translation between them loses something. So let the business owner build the prototype herself, without code, and hand engineering a working artefact instead of a specification. He is careful about what it is worth: the prototype may bear no relation to how the thing is finally built, and it cannot be delegated, because “there's no shortcuts in that sense”.

Five things I would build first

The examples below are grounded in the standards a supplier of battery-backed power already works to, because a reader should recognise their own Tuesday in them.

Publish the calculator, sell the simulation

Put a clean implementation of AS/NZS 4509.2 clause 3.4.7.3 on the public site, with the clause 3.4.7.8 temperature correction applied to the real minimum cell temperature, and hand it to the engineer who was going to guess anyway. Then build what the standard does not contain. Clause 3.4.7.6 names loss-of-load probability as the right criterion. It then offers a table of typical autonomy values between about one and a half and five days, which is how most stand-alone systems in the country get sized. A time-series simulation replaces that choice with an answer: twenty years of half-hourly irradiance at the actual coordinates, the actual load shape, the actual generator logic. The hard part is that the load profile for a site that does not yet exist is a guess, so the honest tool runs a spread of scenarios, publishes the range and names the assumption doing the work.

Keep the customer inside the warranty

A commercial battery arrives with a capacity guarantee, eighty per cent at ten years or a near neighbour, followed by a page of operating conditions in smaller type. There is no industry standard for degradation curves, so every supplier writes its own. When the owner claims at year seven the argument is never about the chemistry but about whether the system ever left that envelope, and almost nobody can answer because the logs rolled over years ago. So encode that contract's envelope as executable rules and evaluate the installed system against it continuously. Tell the owner in month nine that the battery has sat at ninety-five per cent state of charge all winter. The hard part is political, because a tool that makes a warranty auditable makes your own brand principal's warranty auditable too.

Fix the intake before the assistant

A firm quoting commercial storage assembles its hazard case from documents it did not write: IEC 62619 cell certificates, IEC 62933 system declarations and UL 9540A propagation reports. They arrive as inconsistently formatted files from several vendors, each using its own words for the same abuse test, and the useful build is the extraction layer that turns the pile into structured records with the source page cited beside every value. The hard part is that a UL 9540A report belongs to a tested configuration, not a brand. A test on a five-module rack in an open installation says nothing dependable about seven modules in a plant room, and the system's most valuable behaviour is refusing to clear the quotation and naming the gap.

Let her build the fleet triage

Give the engineer who has quoted a thousand telecom cabinets a weekend with the replacement-sequencing tool she has been describing to people for years. A valve-regulated lead-acid string that gives four to seven years in a temperature-controlled exchange falls to two or three once the ambient sits above thirty degrees, while lithium offers both a longer life and the state-of-health telemetry lead-acid never had. Feed in location, string age, grid reliability and drive time, and rank the fleet by which sites to convert first. The hard part is the temperature that kills the battery, which is not the weather station's but the inside of a sealed roadside cabinet in afternoon sun, and hardly anyone has measured it; the tool's most important output is the list of inputs it is guessing.

Build the register of what you commissioned

AEMO's April 2023 compliance report found that only 28 per cent of audited inverters with visible settings could be confirmed correct against AS/NZS 4777.2:2015, and that between 30 and 50 per cent of 2015-standard systems failed to show the required over-frequency response during real disturbances. That is why the 2020 edition exists, and why Amendment 2 arrived in August 2024 to become mandatory a year later. Somebody will eventually have to find those machines. A firm that can say which units it commissioned, at which sites, against which edition, holds a re-commissioning book no competitor can assemble afterwards. So pull serial numbers, firmware versions, settings tables and commissioning dates out of the records you already hold, and bind them to sites. The hard part is identity, across a job-numbering system that changed twice and a filing convention that never shared a key with either.

Screen the adviser hard

Afanasyev specifies three capabilities in one head and is emphatic that three specialists in a room will not substitute: deep knowledge of how the business makes money, the transformation skill to redesign workflows and win genuine adoption, and enough technology awareness for sound architectural choices. He rejects the retrained bandwagon candidate bluntly, since a professional whose previous field has cooled cannot be sent on a two-week course and emerge an applied expert, because “it takes decades years”. And he insists on placement, because the person reports to the chief executive, sits on the board and commands technology and operations resources, since nobody executes structural change from a middle-management implementation role. The criteria are falsifiable in an interview. My record is on the about page; check it against them.

What this evidence will and will not carry

It is worth saying plainly what Afanasyev's account is not. It is not a study; it rests on his own practice, offered in two recorded interviews and a few articles, with no sample, no control group and no measurement, and Google Cloud has the same commercial interest in enterprises deciding they must transform that McKinsey has. The survey evidence sits awkwardly beside him. McKinsey's 2025 survey of 1,993 respondents across 105 countries found 88 per cent using AI in at least one function, which is the number everybody quotes, and 39 per cent able to attribute any enterprise-level profit impact to it, which is the number almost nobody quotes, with 7 per cent describing AI as fully scaled. The MIT figure that 95 per cent of pilots return nothing is real and rests on 153 surveyed leaders and about 300 public implementations, a far thinner base. Every case Afanasyev discusses is banking, whose product is information; that a customer with an agent can game an autonomy calculation the way one can game a credit score is a hypothesis, not a finding. Test it cheaply. Ask the next three customers what they ran before they called.

The stack, and why it is open

Technology is the third step, and the tools I deploy when it arrives are open-source and self-hosted by choice, as a governance decision rather than a preference: your compliance team can read the code, trace where the data goes and sign off without taking a vendor's word for it, and you can leave at any time with the code in hand. The 32 platforms, one section each with an architecture diagram, are on their own page.

Sources

Ask the next three customers what they ran

A first call is a scoping conversation about what your firm sells once the information gap has closed, not a product demonstration.