attv.uk · The Maintenance Blueprint

Guardians of the Data

1 Oct 2026 · 7 min read · Tomasz Lewandowski

Guardians of the Data
The Maintenance Blueprint — Data Ownership

Why Data Decays

Data decay is quiet. A client contact leaves, a mobile number changes, an asset is replaced, a room is renamed, a service interval is adjusted, a part number is superseded, and nobody updates the record. Nothing dramatic happens on the day. But after enough small changes, the system no longer reflects reality. Users notice. They stop trusting it. They create workarounds. The digital system becomes just another questionable source.

This decay is not usually caused by laziness. It is caused by unclear responsibility. People are busy, and maintenance work moves quickly. If nobody is specifically accountable for keeping a dataset clean, updates will be missed. The launch of a system often receives great attention; the care of the system receives much less. Yet ongoing care is what determines whether the tool remains useful after the novelty has gone.

Everyone Owns It Means Nobody Owns It

A common mistake is to say that "the team" owns the data. It sounds collaborative, but it is often meaningless. If everyone owns asset accuracy, nobody knows who must correct a wrong asset record. If "the office" owns site contacts, updates may be assumed to belong to someone else. Shared interest is useful; shared ambiguity is not.

Good data ownership names individuals, not departments. Sarah may own site contacts. James may own the asset register. Priya may own parts records. A manager may own the data quality review. Others can contribute updates, but there must be a named guardian who ensures the record is maintained. This does not create blame; it creates clarity. When ownership is visible, people know where to send corrections and who has authority to make decisions.

Assigning Responsibility to Real People

Data guardians should be chosen carefully. The right person is not always the most senior person. It is often the person closest to the data and best placed to judge its quality. Site contacts may sit naturally with contract administration. Parts data may belong with stores or purchasing. Asset records may require a partnership between engineers and office staff. The guardian needs enough authority to maintain standards and enough support to act.

Write the responsibility down. For each key dataset, define the owner, what they maintain, how often they review it, who can request changes and how disputes are resolved. This can be simple. The value lies in removing uncertainty. Without written ownership, data quality depends on memory and goodwill. With it, upkeep becomes part of the operating model.

Keeping Asset Records Alive

Asset records are particularly prone to decay because equipment changes in the field. A motor is replaced during an urgent repair. A client removes a unit. An engineer discovers that the listed serial number is wrong. If the system does not make it easy to report and process these changes, the asset register will drift away from reality. Once that happens, engineers will stop relying on it.

A good process allows field staff to flag asset changes quickly. Perhaps they can submit a correction request with a photograph. The asset guardian then verifies and updates the record. Replacement should be handled as a controlled event: retire or mark the old asset, create the new asset, link the histories where useful and update service schedules. This discipline preserves the value of the register. It also prevents the system from becoming cluttered with duplicate or dead assets.

Protecting Site and Contact Data

Site data changes more often than people expect. Clients move offices, security procedures change, access gates are locked, new contacts take over and parking arrangements shift. These details matter because they affect attendance, safety and client experience. An engineer with outdated access notes can lose time before the job has even begun.

The site data guardian should maintain a simple review rhythm. High-activity sites may be checked quarterly. Lower-activity sites may be checked annually or whenever a job is completed. Completion forms can include a prompt: "Have access details changed?" This turns every visit into a chance to improve the record. The aim is not perfection. It is a habit of correction. When the team sees that site notes improve over time, trust grows.

Parts Data and Commercial Control

Parts records are easy to neglect, yet they have direct commercial consequences. If part descriptions, prices, suppliers and stock levels are unreliable, engineers waste time, purchasing becomes reactive and margins become harder to understand. A part used on a job should connect to the work order, the asset and, where relevant, the invoice. Without that link, the business loses visibility of true job cost.

A parts data guardian should maintain naming standards, supplier references, stock locations, reorder levels and obsolete items. They should also review commonly used parts and ensure they are easy to select in the system. If engineers cannot find the correct part quickly, they will type free-text notes or choose the nearest match. That may get the job closed, but it weakens reporting. Clean parts data supports first-time fix rates, stock planning and pricing.

Reviewing Data Quality Without Drama

Data quality reviews should be routine, not accusatory. A monthly review might check duplicate assets, missing serial numbers, old open jobs, sites without contacts, parts without suppliers or work orders with incomplete completion notes. The tone matters. The purpose is to keep the system healthy, not to catch people out.

A simple dashboard or report can help. Show the number of missing fields, duplicate records or overdue updates. Celebrate improvements. Assign actions where needed. Over time, data quality becomes part of normal management conversation, like cash flow or safety. This is the point at which the system starts to mature. It is no longer a one-off project; it is an operational asset that receives regular care.

Building Trust Through Accountability

Trustworthy data gives people confidence to act. Engineers can rely on asset history. Schedulers can assign work without hunting through emails. Managers can report to clients without caveats. Business owners can make decisions based on evidence rather than instinct alone. This trust does not come from software by itself. It comes from ownership, standards and routine correction.

The idea of data guardians may sound modest, but it is one of the most important parts of the maintenance blueprint. It answers the question that every system eventually asks: who will look after this once it exists? If the answer is vague, decay will win. If the answer is clear, the system has a fighting chance of remaining useful, trusted and worth the investment.

A Common Mistake to Avoid

The common mistake is to appoint data owners in name only. A person is listed as responsible, but they receive no time, authority or process to maintain the record. They are then blamed when data quality falls, even though the organisation never made upkeep possible. Ownership without capacity is tokenism.

Make the role practical. Define what the guardian checks, how often, which reports they use, who can request changes and what authority they have to reject poor entries. Give them time to do the work and management support when standards are challenged. Data quality is not a side hobby. If the business depends on reliable records, maintaining those records is part of the work.

The Practical Next Step

List your five most important datasets: assets, sites, work orders, staff skills and parts are a useful starting point. For each one, name a guardian, define the standard and set a review rhythm. Then publish that information internally so everyone knows where corrections should go.

Begin with a monthly data quality meeting lasting no more than thirty minutes. Review missing fields, duplicates, stale records and common errors. Assign actions and close them before the next meeting. This habit will feel modest, but it changes the culture. The system becomes something the business looks after, not something it bought once and gradually neglected.

A Measure of Progress

A useful measure of progress is whether staff stop asking who has the latest version of a record. When asset details, site notes and parts information are visibly cared for, confidence returns. Track practical indicators: fewer duplicate assets, fewer missing site contacts, fewer jobs closed with poor notes and fewer corrections discovered only during emergencies. These measures may look humble, but they show whether the system is becoming part of the operation rather than a neglected archive.

The Business Owner's Takeaway

The business owner's takeaway is that data needs stewardship after launch. If nobody is named, trained and supported to maintain records, the system will decay. Assign guardians, review quality and make correction normal. Reliable data is not a feature you buy once. It is a habit the organisation keeps.

Business owner toolkit

A prompt to try

The problem: A new CMMS was launched successfully, but data quality is rapidly decaying because "everyone owns it", meaning nobody is actually accountable for correcting wrong asset records or site contacts.

You are a senior data governance consultant with deep experience in asset management, CMMS (Computerized Maintenance Management System) implementations, and preventing data decay in industrial operations. You've helped maintenance and reliability teams establish sustainable data ownership models that survive personnel changes and operational pressure.

I need your help drafting a **Data Guardianship Matrix** for my business to prevent our CMMS from decaying due to unclear ownership, stale records, and unreported field errors.

Walk me through this collaboratively in the following way:

**Step 1: Discovery**
Start by asking me to identify the **top five most critical datasets** in our CMMS. For each one, prompt me to describe:
- What the dataset contains and why it matters operationally
- How decayed/inaccurate it currently feels (rough sense is fine)
- Who currently touches it, if anyone
- The downstream consequences when it goes wrong

Ask these questions one dataset at a time, or in a structured batch — whichever you think will get the clearest answers from me. Don't move forward until you have enough signal on all five.

**Step 2: Define Ownership**
For each dataset, help me think through:
- Who the **Data Guardian** should be (role, not just a name) — the single accountable owner
- Who the **Contributors** are (people who input or update records)
- Who the **Consumers** are (people who rely on it)
- What authority the Guardian needs to enforce standards

Challenge my instincts. If I name someone who's already overloaded, or pick a role too senior/junior to realistically maintain it, push back and propose alternatives.

**Step 3: Define Review Rhythm**
Help me set a realistic review cadence for each dataset based on:
- How fast the underlying reality changes (e.g., asset registers vs. spare parts)
- The cost of letting it decay
- The Guardian's actual available bandwidth

Suggest cadences (daily, weekly, monthly, quarterly, annual audit) and what "review" actually means in practice for each — not just a calendar reminder.

**Step 4: Field Engineer Error Flagging**
Help me design a **frictionless error-flagging mechanism** that field engineers will actually use. Explore options with me:
- In-CMMS flagging vs. mobile/QR-based vs. messaging-based (Teams/WhatsApp)
- What minimum info should be captured when flagging
- How flags get routed to the right Guardian
- How engineers get feedback so they keep flagging (closing the loop)

Recommend what's likely to work best given that field engineers are typically time-pressured and skeptical of admin overhead.

**Step 5: Assemble the Matrix**
Once we've worked through the above, produce the final **Data Guardianship Matrix** as a clear table I can take to leadership, plus a short summary of:
- Risks we identified
- Decisions I still need to make
- A suggested rollout sequence (which dataset to lock down first)

**How to work with me:**
- Ask clarifying questions whenever my answers are vague — don't assume.
- Think out loud and offer your reasoning, not just conclusions.
- If you spot a governance anti-pattern in what I describe (e.g., committee ownership, no enforcement teeth, review rhythms tied to people who'll leave), call it out.
- Treat this as a working session, not a one-shot deliverable.

Begin with Step 1.

Why it works: It transforms data quality from a vague team aspiration into an assigned operational duty with clear accountability.

Related in this series: The Hidden Database · When Excel Starts to Leak

← Previous: Avoiding Scope Creep All in “The Maintenance Blueprint” →

Found on: https://attv.uk/blog/guardians-of-the-data.html

Follow the author on LinkedIn: https://www.linkedin.com/in/attvuk/ — follow for more.

Disclaimer: this article reflects the personal views of the author and is provided for general information only — it is not professional advice. © Tomasz ‘Amigo’ Lewandowski · attv.uk. Please keep this attribution when sharing.