Data Quality & Governance Playbook for Operations

Welcome — Why this playbook matters

Operational teams rely on data to make rapid, often safety- or cost-sensitive decisions. When that data drifts, dashboards silently mislead, models degrade, and teams stop trusting metrics. This playbook gives a minimum viable governance approach you can adopt in weeks: clear roles, simple rules, routine checks, and a light change-control process so operations can trust and act on data.

Who should use this

Plant leads, operations managers, OT/IT collaborators, data stewards, and site data engineers who need a practical, low-friction approach to keep operational data reliable.

Core hungers addressed

• Prevent bad transformations from silently corrupting dashboards and models.
• Make operational metrics reliable enough for daily use and decisions.
• Enable fast, low-friction collaboration between OT, IT, and data teams.

1) Roles & a lightweight RACI

Keep roles minimal and tied to authority and accountability. Use these roles as starting points and adapt to your org.

• Data Owner (often a process or operations manager): accountable for the meaning and acceptance criteria of a dataset or metric.
• Data Steward (site-level): responsible for daily data health checks, documentation, and first-response triage.
• Data Engineer (IT/Data team): responsible for transformations, pipelines, and corrective changes in code or ETL.
• OT Subject-Matter Expert (SME): advises on physical meaning of signals, units, and acceptable ranges.
• Data Consumer: regular users of the dataset (supervisors, analysts) who report anomalies.

Sample RACI for a dataset (e.g., equipment run-hours):

• Define metric & acceptance criteria — R: Data Owner, A: Plant Manager, C: OT SME, I: Data Engineer
• Daily health checks & triage — R: Data Steward, A: Data Owner, C: Data Engineer, I: Users
• Transformation changes — R: Data Engineer, A: Data Owner, C: Data Steward & OT SME, I: Users

2) Define source-of-truth and canonical identifiers

Be explicit about what system holds the authoritative value for each field or metric. For operations this often means choosing between PLC tags, historians, MES, or the ERP as the canonical source.

• Record: Dataset name, canonical source system, canonical field name, unit, frequency, owner
• Tag fields as: "Source of Truth: Historian (tag ABC), Aggregation: 1-min moving average," etc.
• Where multiple sources exist, document reconciliation rules (e.g., prefer MES when production state is "Running"; else historian).

3) Basic data quality rules (apply these consistently)

Start with a small, well-defined set of rules you can operationalize quickly:

1. Completeness: Expected rows/timestamps exist for the reporting interval. Example rule: >95% expected samples per hour.
2. Timeliness: Data arrives within expected latency. Alert if > X minutes delayed.
3. Range & Units: Values fall within documented engineering limits and correct units are used.
4. Format & Types: Numeric fields are numeric; timestamps valid and in expected timezone.
5. Uniqueness & Cardinality: Unique keys (e.g., equipment_id + timestamp) are unique; cardinality within expected bounds.
6. Lineage/Provenance: Each transformed value links back to source fields and transformation version.

4) Daily data health checks (practical checklist)

Make the daily check a short routine (5–15 minutes) a Data Steward can run. Capture results in a one-line log or quick form.

• Confirm ingest is running for critical sources (OK / delayed / stopped)
• Check completeness for top 5 operational datasets (OK / gaps)
• Spot-check ranges for key signals (within expected limits?)
• Verify recent transformation deployment status and version
• Note any user-reported anomalies since yesterday
• If any failures, escalate to Data Engineer and tag Data Owner

Suggested recording: date, steward name, quick status (green/yellow/red), short note, action owner.

5) Lightweight change-control for transformations

Keep the process short but explicit so transformations do not silently break downstream metrics.

1. Every change to a transformation must have a short description, owner, and version tag.
2. Run a smoke test: known test inputs should produce expected outputs (store results).
3. Notify Data Owners and Data Stewards before deploy; allow 24-hour observational window for critical datasets.
4. If an emergency rollback is needed, reapply the previous version and notify stakeholders.

6) Documentation templates (minimum viable catalog entry)

Each operational dataset should have a short catalog entry capturing:

• Dataset name and brief description
• Canonical source & field names
• Units, frequency, and expected cardinality
• Owner and steward contact info
• Acceptance criteria (completeness %, allowed ranges)
• Transformation versions and change log
• Known caveats and common downstream consumers

7) Example incidents and responses

Make triage fast by pre-defining common incidents and next steps:

• Missing data (ingest stopped): check collector, restart pipeline, log incident, notify Data Owner.
• Sudden shift in units or scale (e.g., readings 1,000x): pause downstream refreshes, rollback recent transformation, confirm units with OT SME.
• Intermittent timestamp jumps: flag as ‘timing error’, apply alignment fix, verify corrective rule before reprocessing historical data.

8) Implementation checklist (first 30 days)

1. Identify top 10 operational datasets and assign Owner + Steward.
2. Create catalog entries for those datasets using the template above.
3. Define 2–4 core quality rules and implement daily health check for them.
4. Create a simple change-control policy and versioning convention for transformations.
5. Run a two-week daily health-check trial and refine thresholds and alerts.

9) Recommended KPIs to track

• % of critical datasets passing daily health checks
• Mean time to remediate data incidents
• Number of downstream incidents traced to data changes
• % of datasets with complete catalog entries

10) Next steps & scaling

Once the lightweight playbook is stable at a site, consider automating checks, storing daily check results in a simple form, surfacing alerts to owners, and adding dataset lineage tracking. Package the core templates and checks as a site toolkit so other plants/units can copy and adapt them.

Appendix — Quick templates

Use these starters in your documentation system or simple shared spreadsheet:

• Catalog entry heading: name | source | units | frequency | owner | steward | acceptance criteria
• Change log entry: date | change summary | author | version | smoke-test result | notes
• Daily health log row: date | steward | dataset | status (G/Y/R) | note | action owner

Adopt this playbook iteratively. Keep checks short, roles clear, and documentation deliberately minimal — you want adoption, not bureaucracy.