Cleanup Is a Workflow Problem

Over the last few scoping calls, I noticed something that explains why most cleanup projects never actually solve the problem.

A firm knows its data needs work. Duplicates, inconsistent values, broken reporting. Maybe a migration that didn’t land right.

So the question becomes: “Can someone help us clean this up?”

Fair question. But most of the time, the real problem isn’t the data itself.

It’s the gap between what leadership wants the system to report and what operations actually has to do to move work forward.

Leadership wants clean numbers. Operations wants to get through the day. When the system only serves one, the other adapts by breaking things.

People take shortcuts. They duplicate entries. They write notes in fields that were never built for notes. Not because they’re careless. Because the system made that the path of least resistance.

Those aren’t mistakes. They’re signals.

You can clean the data. But if the underlying workflow stays the same, you’ll be cleaning it again in three months. I’ve watched firms do exactly that. Same dataset, same problems, every quarter, because nobody touched the process generating them.

The fix that actually holds is a translation layer between operations and data architecture. Operations teams move work forward in ways that make sense to them. The system handles translating that into something structured that leadership can actually report on. When that layer exists, you stop asking operational users to behave like database administrators.

We stabilize the data, but the more important work is finding where the workflows, integrations, and governance are pulling against each other.

The goal isn’t to be the best cleanup team. It’s to make cleanup less necessary.