Data and process audit
Before anything gets built on your data, somebody has to establish what is actually there. Not what the system diagram claims — what the records contain, how complete they are, and which of them can be trusted enough to base a decision on.
Everyone assumes the data is fine
It usually isn't, and nobody finds out until a project depends on it. Customer records exist in three systems with three different spellings, a critical field has been used for two different purposes since a process change in 2021, and the report everyone cites has been quietly wrong for a year. These are ordinary findings, and they are far cheaper to discover deliberately than during a build.
You’ll recognise this if
- Two teams produce different numbers for the same question
- Nobody can say with confidence how many customers you have
- A project stalled once it reached the data
- You are considering AI and don't know if your data can support it
What we actually deliver
An inventory of what you actually hold
Every meaningful source — systems, exports, shared drives, the spreadsheets on individual machines — with an owner, an update frequency, and a note on how far it can be trusted.
A quality assessment against real checks
Completeness, duplication, consistency, and freshness measured rather than estimated, so 'the data is messy' becomes a specific list of defects with counts attached.
A map of how work really flows
How information moves through the organisation in practice, including the manual steps and workarounds that never appear on the official diagram.
A prioritised remediation plan
What to fix, in what order, with effort against each — separated into what blocks your goal and what is merely untidy.
The way we approach it
Profile the data, don't ask about it
We run checks against the actual records. What people believe about their data and what is in it are reliably different, and only one of those can be measured.
Trace a few records end to end
Following a handful of real cases through every system they touch exposes more than any amount of documentation review. It is where the surprises are.
Report plainly, including the awkward parts
If a key report has been wrong, or a system everyone relies on is not what it is believed to be, that goes in the document. Discovering it now is the point of the exercise.
What changes
- A clear statement of what your data can and cannot support today
- Defects quantified rather than described
- A remediation plan ordered by what actually blocks you
- A realistic basis for scoping anything downstream
Asked often enough to answer here
How long does an audit take?
Usually two to three weeks. It is deliberately short — the aim is a decision-ready picture, not an exhaustive catalogue that takes months and is out of date on delivery.
What if the findings are bad?
Then you have learned it for the cost of an audit instead of the cost of a failed build. That is the cheapest possible time to find out, and the plan you get is written to move you forward from where you actually are.
Do you need access to production systems?
Read-only access is ideal, but we can work from representative extracts where access is restricted. We work within whatever your security position allows and agree it before starting.
Related
Wherever you’re starting from, let’s figure out the next step.
Tell us what you’re building — we’ll tell you honestly whether we’re the right team for it.