IT‑IS‑Networking
Projects › Local government — enterprise asset and work management

Enterprise Asset and Work Management Platform

Fifteen years and two titles on a platform carrying several lines of business and two outside agencies — stood up as a governed project, fed from the systems that knew the truth, and split in the chargeback model.

It ran on IBM WebSphere with WebSphere MQ messaging, and it was not a single department’s tool. Fleet and transportation ran their own instance. Public works, solid waste, facilities and telecommunications were on it. The electric utility, the Sheriff’s Office and the public library were customers of the same platform. From 2013 it was integrated with the City’s citizen service request system through an interface synchronizing change orders, which made it a dependency for citizen-facing requests rather than an internal system.

A platform carrying several lines of business, two external agencies and a service-request integration is an enterprise asset, and the questions it raises are enterprise questions: who owns the data model, who pays for it, and what happens to the service request when it falls over.

Stood up as a governed project, not a software installation

Under the Technology Officer title in 2009: a vendor demonstration in January, a project charter in February, a kick-off in March, then status reporting and a documented walk-through of the division’s own process.

Charter before kick-off is the part that matters. Scope and ownership were settled on paper before the build started, and the department’s existing process was documented for the project rather than assumed by it.

The platform was entered into the Enterprise Security Committee’s application dependency list in April 2009 and named on the network outage escalation sheet with its own escalation path. That is what it means for something to be an enterprise system rather than a departmental one: it gets registered as a dependency, assigned an escalation owner and written into the security committee’s view of the estate — or it is invisible on the day it fails.

Fed from the systems that actually knew the truth

A register is only as good as its feeds. In January 2013, four requests were filed inside four days to pull telephony asset data into the platform automatically rather than by hand, from the call-by-call databases on the legacy exchange and the systems alongside them. The objective was a single authoritative asset record populated from the operational systems rather than from a spreadsheet.

The scale of that problem is visible years later: roughly 5,100 City telephones and 1,300 at a separate authority still being reconciled against the platform in 2020.

Manual asset data is not a data-entry problem to be staffed. It is a feed problem, and staffing it is how an organization pays forever for something it could have automated once.

Holding the enterprise view across a release

The 2013 version upgrade moved the platform to a new database, so the dependencies moved with it: steps run against the service request system’s database because of the upgrade, the employee-update interface, the feeds. Completion and smoke testing were confirmed here to the Chief Information Officer and the assembled teams.

The honest footnote on any integration-heavy cutover is in this one too. Three months later a script was still being run to push comments into the service request system that the upgrade had missed.

Which half is an enterprise service, and which is a department’s cost of doing business

In 2013 the platform was split for cost allocation: data entry treated as non-core, workflow processing treated as core, with the core element becoming a billed line to the consuming departments.

That decision outlived the involvement that made it. A 30.05 percent increase on that line was being flagged in 2022, and the following fiscal year’s increase was attributed to a new managed support services arrangement.

This is one of roughly sixteen hundred costed lines in the service catalog, shown here in full because the reasoning is the interesting part. Drawing the boundary between the enterprise service and the department’s own consumption is the hardest call in a chargeback model. It is the call that determines whether a department can argue with its own bill — and a bill that cannot be argued with does not get paid by anyone who is free to decline it.

Outcome

An asset register fed from operational systems rather than from a spreadsheet, and a cost split that outlived the person who drew it.