One asset register, whether you own the assets or sold them

Situation

Two kinds of organisation have the same problem from opposite sides.

A plant owns hundreds of installations and has to keep them running. What is installed where, when was it last inspected, which drawing is the current one, who signed off the last change.

A supplier has sold and installed equipment at dozens of customer sites and has to service it. The questions are identical — but the assets are not theirs, they sit on other people's premises, and everything has to be answerable per customer.

Software normally picks a side. Maintenance systems assume you own the plant and treat customers as an afterthought. Field-service systems assume you don't, and give up the engineering depth. Organisations that are both — and plenty are, running their own plant while servicing what they have sold — end up with two systems and reconcile them by hand.

What I built

One register that supports both readings, and the decision that makes it work is a small one: the asset hierarchy hangs off a company.

Functional locations describe where equipment sits, independently of whatever unit is installed there today — the standard maintenance idea, and the reason replacing a pump doesn't throw away ten years of history. Those locations form a tree, and the root of each tree is a company. Point it at your own company and you are managing your own plant. Point it at your customers and you are managing an installed base across all of them. Same screens, same permissions, same history; the only difference is whose name sits at the root.

On top of that structure:

The equipment as it really is. The control network documented as-built — devices, their types, their ports and interfaces, and the segments they sit on — so you can start at one device and walk outward to whatever it is connected to, instead of consulting a diagram that was accurate at commissioning and has been drifting ever since.

Documents that stay current. A revision-controlled vault holds drawings, manuals and configuration files, linked to the locations and devices they describe and previewable in the browser. You get the current revision by default, and the superseded ones are still there when someone asks what changed.

Inspections and history. Inspection records accumulate against locations, so an asset carries its own past — which is the whole point of the functional-location model.

The people around it. Companies, contacts and the contractors responsible for each area, with activity feeds and subscriptions so the right people hear about changes, plus full-text search across everything, exports and an audit trail.

Two organisations, one codebase. It runs for two enterprises with incompatible identity systems — one against corporate Active Directory, the other through OAuth. Nearly all the code lives in a shared Rails engine, with a thin host application per organisation carrying only its authentication, its overrides and its deployment configuration. A change for one no longer means reasoning about its effect on the other.

Outcome

The engineer who knew how it all fitted together is no longer a single point of failure, and one application serves both an owner-operator and a service organisation without either feeling like it is borrowing the other's tool.

Both flexible parts come from the same instinct: put the variation in the data model, where it costs nothing — a hierarchy that can root on a company — rather than in branching code that has to be maintained forever.