Enterprise Asset Management + Solution Design

TechnologyOne

Where the pattern became obvious: understand the operational problem first, then bend the technology around the outcome rather than defending the default workflow.
2006-2010EAMMobile work / FSMUtilitiesPresalesCustomer recovery

The role

I led presales engagements across Assets, Works, Projects, Inventory and Contract Management before moving into EAM account management while retaining solution-design responsibility. The work sat between customer operations, sales, product development and delivery.

Designing mobile work from the field backwards

TechnologyOne was also where I became deeply involved in the first generation of mobile work execution. I was not writing the production code; I was doing the customer discovery and UX thinking around how maintenance and field crews actually needed the application to behave.

That meant getting into operational details that disappear in a generic process diagram. A council road crew, for example, might need six people assigned to a job while one worker leaves for a medical appointment and later returns. The system still needs to represent labour, time and work execution accurately without making the crew fight the software.

Good field-service design starts with the exceptions the people doing the work already know about.

That experience later made full FSM, mobile workforce and work-execution conversations at IFS familiar territory rather than a new domain.

48 seconds versus five minutes

During a major government ERP programme, a final maintenance workshop exposed a serious adoption problem. The customer's bespoke legacy system performed a critical high-volume maintenance transaction in exactly 48 seconds. The replacement workflow took roughly five minutes.

The customer's concern was not resistance to modernisation for its own sake. The new process was objectively worse for the people who had to use it.

Rather than defend the product, I treated the 48 seconds as a design constraint.

A newly released platform capability had been intended for portal, reporting and KPI experiences. I suspected it could be used more interactively. I pulled in a strong technical colleague, validated the idea quickly, then redrew the workflow around the actual maintenance task: find the person or address, see the relevant room/equipment, identify warranty status, and raise the repair from there.

The customer accepted the concept. The resulting solution later went live and handled roughly 800 maintenance calls in its first week with only one how-to support enquiry.

140+ customersPart of the team that secured more than 140 new accounts in less than four years.
$50k → $600kHelped lift average licence and services revenue per sale through larger, more complete solution design.
30+ → 8Reduced a large pool of troubled/delayed accounts to eight within about 12 months after moving into account ownership.
First utility winsHelped secure early large-scale EAM wins in power and water.

Why it still matters

This is still how I approach AI. The model, platform or product is material. The operating problem is the design brief. If the customer's current method is better, say so, understand why, and redesign the answer.

Back to profile