The new system has been live for six months. Your team uses it daily. The dashboards exist, the audit log is queryable, the workflow runs as designed. The implementation closed on time, slightly over budget, which counts as a win.
Then another department asks about a piece of work done last Tuesday. The team lead walks through it: Tomas took the request. He used the defaults because that’s how he learned. He skipped an optional step. He marked the work done when the requester emailed back saying thanks. A colleague handled the same kind of work two months earlier — different settings, different judgment about what counted as “finished,” different note attached at the end.
If you asked either of them to describe what they were doing, you’d get two different answers. Both are inside the system, which has no opinion about which one is right. Because before the new system existed, nobody asked.
A Tool Records the Way You Work. It Doesn’t Improve It.
This is the part the demo doesn’t say out loud. The platform is a recording medium. If the way work gets done is consistent, the recording is consistent. If the way is “whoever takes the work decides what to do next,” the recording shows you that.
A team that ran on memory and habit — Marta does it this way, Petras does it that way, both worked fine for years — adopts a system that promises standardization. After rollout, the system contains both ways, faithfully. The dashboard now shows the variation as a metric instead of hiding it as folklore.
People mistake visibility for improvement. Seeing the inconsistency in a chart is not the same as resolving it.
Required Fields Don’t Make Meaning
Some systems try to force the issue with required fields and gated transitions. It works on structure — the entry exists, the box is ticked. It doesn’t reach content. People who haven’t agreed on what a field means fill it with whatever clears the validation: a required “resolution notes” field gets “done,” “ok,” or “see email.” A mandatory category dropdown gets whatever option is first in the list. People aren’t being lazy. The field is asking them to settle, on their own, a question the team never answered. The audit log looks clean. The standardization is cosmetic.
Write It Down Before You Build It
A process two people can describe the same way is one a tool encodes honestly. A process they describe differently can still be encoded — the tool just forces one path, and the people who weren’t consulted route around it or quietly mark things done their old way.
Not all variation is drift. Some processes vary because different inputs need different handling, and that variation belongs in the design. What needs resolving is the variation that exists only because nobody made the call: workarounds for problems that no longer exist, small decisions each person made on their own. The first step isn’t software selection. It’s writing down what people actually do, comparing the versions, and deciding which differences are real and which are leftover.
This is the unglamorous work the platform vendor doesn’t include in the timeline. It’s also the step that decides whether the investment pays off or just produces a more expensive version of what was there before.
Could Two People on Your Team Describe This Process the Same Way?
Pick a process that matters. Ask two people who run it to write down the steps independently, in their own words. Compare. The gap between their versions is the work the next software won’t do for you.