Data Governance in Asset-Heavy Organisations, Made Practical

I have watched more than one data governance programme die in its first year. Not because the idea was wrong, but because it was launched as a framework: a steering committee, a glossary nobody read, a policy document with forty defined terms and zero enforcement. Six months later the sponsor moved on and the whole thing quietly evaporated. This is governance stripped down to what a maintenance or facility director can actually run without a dedicated data team.

Start with a fix, not a framework

The single biggest predictor of whether governance survives is how it launches. Programmes that launch as frameworks fail. Programmes that launch as a fix to one visible, painful problem succeed, then expand from there.

So do not open with a mission statement. Open with the thing that already annoys people. In asset-heavy organisations there are usually two obvious candidates:

• Duplicate assets. The same pump exists three times under three tag conventions, so PM compliance is nonsense and nobody trusts the asset count.
• Missing failure codes. Work orders close with "fixed" and no failure reason, so you can never answer why anything breaks or which assets to replace.

Pick one. Fix it in public. Show the before and after. Now, when you say "we need a rule about who creates asset records," people already believe the rule buys something, because they saw the mess it prevents. Governance earns its next mandate by delivering the last one. Everything below is the machinery you switch on once that first fix has bought you credibility, and it is deliberately small.

The one-page data policy

A data policy that runs to twenty pages is a policy nobody has read, which means it is not a policy at all. Yours fits on one page and answers five questions in plain language:

1. What data we govern. Name the domains: asset, location, work order, inventory, vendor, meter. If it is not on the list, it is not governed yet.
2. Who owns each domain. One named owner per domain, a person, not a department.
3. How records get created. Who can create an asset, a location, a vendor. Everyone else requests, they do not create.
4. Our quality standard. The handful of fields that must be present and correct, and the target completeness for each.
5. How we change the rules. The change process, pointing at the section below.

That is the whole policy. It should be readable in two minutes by a storeman or a contract manager, because those are the people who actually keep or break the data. A policy they cannot read is a policy they will not follow. For the underlying discipline this sits on top of, see my note on master data management for assets.

A RACI for six data domains

Ownership is where governance lives or dies. "The data team owns it" is not ownership, it is a place blame goes to hide. Instead, assign every domain across the real roles who touch it, using RACI: Responsible does the work, Accountable owns the outcome and signs off, Consulted is asked before decisions, Informed is told after.

There is exactly one A per row. If two people are accountable, nobody is. Here is a starting matrix using roles that exist in most asset-heavy operations. Adjust the names to your structure, but keep the shape.

Read a row and it tells a story. Asset data: the maintenance planner is accountable for it being right, IT is responsible for making the changes in the system, finance and the contract manager get consulted because depreciation and contract scope both depend on the register. Vendor data: finance owns it because a bad vendor record is a payment problem before it is a maintenance one. The point is not that these exact letters are correct for your organisation. The point is that every domain has one accountable name, and everyone can see where they sit.

The monthly 45-minute forum

Governance needs a heartbeat, and the heartbeat is one short standing meeting. Not a two-hour committee. Forty-five minutes, monthly, same agenda every time, the accountable owners from the RACI in the room. A fixed agenda is what keeps it from sprawling into a general operations gripe session.

The four standing metrics the scorecard reviews are deliberately few, because a scorecard with thirty numbers is a scorecard nobody reads:

1. Duplicate rate. Suspected duplicate assets as a share of the register. Trending down is the whole game.
2. Critical-field completeness. Percentage of asset records with the mandatory fields populated (class, location, criticality, make/model).
3. Failure-code capture. Percentage of closed corrective work orders with a valid failure code, not "other" or blank.
4. Vendor record health. Percentage of active vendors with complete, non-duplicate master records.

Each metric has a target and a colour. Green stays quiet. Amber gets a comment. Red gets five minutes and a named owner. That is the entire performance-management surface of the programme, and it is enough.

The data-quality scorecard

The scorecard is the one artefact you circulate between forums. One page, four metrics, three columns: current, target, trend. Nothing else. Its job is not to be comprehensive, it is to be glanceable by a director who has ninety seconds. When a number goes red two months running, that is your signal to launch the next visible fix, exactly the way you launched the first one.

A worked example: the site that wants a new status

Here is the kind of decision this machinery exists to make. A site manager emails: "We want to add a local asset status value called Awaiting Parts, Site Hold so we can track our stuck jobs." Reasonable request, real need. Without governance, it gets added quietly, and now one site has a status value no report understands and no other site uses. Multiply that by twenty sites and your status field is unusable.

With governance, it goes to the change-request slot in the forum, and the accountable owner for work order data walks it through:

• What problem is this solving? Jobs are stuck waiting for parts and the site cannot see them as a group.
• Is it local or global? Every site has stuck-for-parts jobs. This is not a local need, it is a universal one badly expressed as a local request.
• Does an existing value cover it? There is already a system status of Awaiting Parts. The real gap is not a new status, it is visibility.

The decision: reject the new local status value, and offer the alternative path instead. Rather than a bespoke status, the site gets a saved filter and a dashboard tile built on the existing Awaiting Parts status plus the linked purchase order. The site gets exactly the visibility it asked for, the status field stays clean and comparable across all sites, and every other site inherits the same view for free. The requester leaves happier than if you had simply said yes, because they got a better answer than the one they came in with.

That is what good governance feels like from the floor: not "no," but "here is a cleaner way to get what you actually want."

The change process for fields and classes

The worked example only works because there is a defined path for changes. Adding a field, an asset class, or an allowed value is a governance decision, not an admin task, because every addition is permanent and every site inherits it. Keep the process to four steps:

1. Request. Anyone can raise one, in a single simple form: what you want, and what problem it solves.
2. Triage. The domain owner checks it against three questions: does an existing field or value already cover it, is the need local or global, and what breaks in reporting if we add it.
3. Decide. Approve, reject, or offer an alternative, at the monthly forum. Decisions and their reasons get written down, so the next identical request gets the same answer.
4. Apply and communicate. IT makes the change, and every site is told what changed and why. Silent schema changes are how trust erodes.

The discipline that matters most is the default. The default answer to "can we add a field" is not yet, prove the need first. Fields are easy to add and almost impossible to remove once data lives in them. A schema that grows by accretion becomes the exact mess governance was meant to prevent. This connects directly to how you structure the register in the first place, which I cover in asset hierarchy design.

On tooling: what to actually use

Vendors will tell you that you need a data governance platform: a catalogue, a business glossary, automated lineage, policy workflow engines, the full enterprise suite. For a global bank or a national utility with thousands of data sources, that case exists. For a maintenance or FM organisation running one EAM or CAFM system and a finance system, it does not.

I will say it plainly: if your organisation runs fewer than a handful of core systems, do not buy enterprise data-governance tooling. It will cost more than the problem, take a year to configure, and demand a specialist you do not have to keep it alive. The tool becomes the programme, and the programme becomes the tool, and the actual data stays dirty. I have seen six-figure catalogue licences sit unused next to a duplicate-ridden asset register.

What to use instead:

• The one-page policy and the RACI in a shared document. That is your governance system of record.
• The scorecard as a spreadsheet or a saved report inside the EAM or CAFM you already own. Most of these systems can already report completeness and duplicates.
• The change log as a simple tracked list. A ticket queue or a shared sheet is plenty.
• The forum as a recurring 45-minute meeting. No licence required.

Buy the platform later, if you ever genuinely outgrow this. The signal to upgrade is real pain that the lightweight setup can no longer carry, not a vendor demo. Governance is a set of habits and owners, not a piece of software, and the habits have to work before any tool can help. If the underlying platform economics are what you are weighing, I break the numbers down in what an operational data platform costs.

Where the formal frameworks fit

None of this means the established bodies of knowledge are wrong. They are the reference you reach for when you are ready to go deeper on a specific domain, not the thing you launch with. Two are worth knowing:

• The DAMA International DMBOK is the canonical map of data-management disciplines. Read it to borrow structure, not to copy it wholesale.
• ISO 8000 is the data-quality standard, useful when you need a shared vocabulary for completeness and accuracy with a demanding customer or auditor.

Take one idea from each when a real problem calls for it. Do not adopt either as a programme on day one. The whole argument of this piece is that scope kills governance, and the frameworks are large by design.

Conclusion

Governance in an asset-heavy organisation does not need a department or a platform. It needs a one-page policy, a RACI with one accountable name per domain, a 45-minute monthly forum with a fixed agenda, a four-metric scorecard, and a change process that says "not yet" by default. Launch it as a fix to duplicate assets or missing failure codes, prove it works, and let it earn its next mandate. Small, visible, and alive beats comprehensive, documented, and dead every time.

Independence note: I am not affiliated with, and receive no commission from, any software vendor, DAMA, or ISO. The tools and standards named here are referenced only to help you decide. The advice reflects my own project experience, and your context may differ.