Building a single source of truth for operations data

Ask three managers how many tons shipped last month and you may get three answers. One counts the scale tickets, one counts the invoices, and one counts what the spreadsheet says. None is wrong, and none is the number.

A single source of truth fixes that. It does not require a giant project or a new platform. It requires agreeing on what the numbers mean, and connecting the systems that create them.

What does “single source of truth” actually mean?

It means one place where the important operational facts are stored in a consistent way, and everyone who needs a number reads it from there.

It does not mean one system for everything. Your scale software, ERP, maintenance system, dispatch tool and spreadsheets will still exist. The single source is a layer that collects from them, cleans the data, applies shared definitions, and serves reports and dashboards.

Why do operations numbers disagree?

The causes are mundane:

• The same event is entered in two systems at different times
• Material, customer or part names differ between systems
• Definitions are informal: does “shipped” mean left the dock, was weighed out, or was invoiced?
• Spreadsheets get copied, edited and emailed, producing many versions
• Corrections are made in one place and not the other
• Reports are built by whoever needed them, with their own filters

Technology does not fix those. Decisions about definitions do, and then technology enforces them.

Where should you start?

Start with decisions, not data.

1. List the five to ten decisions people make every week. Which suppliers are profitable, which machines are down, which loads are late, what inventory is on hand, what to quote.
2. For each, write the number that informs it and who uses it. “Net tons received by material and supplier, for the buyer, daily.”
3. Find where that number is born. Which system records it first, and who enters it?
4. Write the definition in one sentence. Get the people who disagree in the same room and settle it.

The result is a short list of metrics with owners. That is the real specification for the data project.

What data usually goes in first?

Pick the records that touch money and flow every day. In an industrial business that commonly means:

Record	Where it usually lives	What it answers
Scale tickets	Scale or weighing software	What came in and went out, by weight, material and party
Work orders	Maintenance system, ERP or spreadsheets	What is being repaired or produced, and how long it takes
Loads and shipments	Dispatch, TMS, ERP	What is moving, when, and for whom
Inventory	ERP, WMS or yard counts	What is on hand and where
Orders and contracts	ERP or CRM	What was promised and at what price
Downtime and quality events	Shop floor logs, paper, sensors	Why output was lost

Do two or three of these well before adding more. Scale tickets joined to orders and loads often answer more questions than a dozen dashboards built on partial data.

How does the data get from the systems to one place?

There are a few common ways, and most companies use a mix.

• Direct database reads from systems that allow it. Fast and complete, but be careful not to load production.
• Scheduled exports (CSV, flat files) picked up automatically. Crude, reliable and often the only option with older systems.
• APIs where the vendor offers them.
• Change capture from databases, for near-real-time needs.
• Controlled spreadsheet intake for the data that only lives in spreadsheets, with a fixed template and validation, rather than a free-for-all.

The destination is typically a reporting database or data warehouse in a cloud account that you own. Keep the raw copy of everything as it arrived, then build cleaned, joined tables on top. That way when someone questions a number you can trace it back to the original ticket.

How do you handle messy and duplicate data?

Expect it. Plan for it.

• Master data first. One list of customers, suppliers, materials and parts, with a key that every system maps to. This is boring and it matters more than any chart.
• Mapping tables that connect “ABC Metals,” “ABC Metal Inc” and “A.B.C. Metals” to one supplier record.
• Validation at the edge. Reject or flag records with missing weights, impossible dates or unknown materials as they arrive.
• A visible exceptions list. Someone owns clearing it each day.
• Corrections flow one way. Fix errors in the system where they originate, and let the fix propagate. Editing the warehouse copy breeds a second truth.

What makes dashboards that people actually use?

Most dashboards are abandoned. The ones that survive share some traits.

• They answer a question someone asks daily. If no one is asking, no one will look.
• They are built with the person who uses them, on their screen, in their language.
• They load fast and show today. A number that is a day old and takes a minute to open will lose to a phone call.
• They show few things. Five numbers that drive action beat fifty that describe.
• They link to the underlying records, so a surprising number can be traced to the tickets behind it.
• They name an owner. If a number looks wrong, someone fixes it.
• They live where people already are. A printed daily sheet, a tablet in the scale house, a morning email. Not only a login people forget.

Test it simply: after two months, are people opening it without being asked?

Do you need AI on top of this?

Not at first. Reliable, shared numbers come first. After that, models can help with things like summarizing exceptions in plain language, answering questions about the data, or flagging unusual tickets. They work far better on a clean, consistent base. Putting them on top of conflicting spreadsheets just produces confident disagreements.

How long should this take?

A first useful slice, for example scale tickets joined to orders with a handful of agreed metrics, is a matter of weeks, not a year. Expand from there based on which decisions get better. If someone proposes an 18-month data platform before showing any result, push back and ask for a smaller first phase.

What are the common mistakes?

• Buying a platform before defining the questions
• Skipping definitions and hoping tools will reconcile them
• Trying to cover every system at once
• Letting IT build it alone, without the operators who use it
• Treating it as a project with an end date instead of something that needs an owner
• Locking data in a vendor’s format that you cannot export