“We’re supposed to do it this way, but it’s easier if I do it like this.”

That could be one of the most useful things an employee tells me when I’m trying to understand how a business actually operates. It immediately points to a central idea: there is often a difference between the documented process and the process people rely on to get the work done.

The interesting part is why they felt they needed to change it.

A workaround usually exists for a reason.

An employee might put information into a spreadsheet because the main system doesn't handle something properly. They may still use part of an older process because the replacement created extra work, or they may have developed their own way of handling an exception because the official route regularly slows things down.

None of those situations automatically means the employee is ignoring the process or resisting change. In many cases, they are trying to keep work moving despite a limitation somewhere in the workflow.

That distinction matters. If you remove the workaround without understanding the problem it was compensating for, you may bring the original issue back.

The official process may only tell you part of the story.

Management can explain how a workflow was designed to operate, and process documentation can show the intended steps. Both are useful, but neither necessarily tells you what happens when real customers, exceptions, and imperfect systems get involved.

That is where speaking directly to the people doing the work becomes important. They can explain where the process regularly breaks down, which steps take longer than expected, and where they have had to create another route from one stage to the next.

A workflow can look perfectly sensible on paper while relying on several unofficial steps in practice. If those steps are invisible to management, the business may be making decisions about a process it does not fully understand.

Workarounds can reveal problems between systems.

Some of the most useful workarounds to investigate appear between different systems.

Perhaps customer information arrives in one platform but has to be re-entered somewhere else. An employee might export data into a spreadsheet, change the format, and upload it into another system because the two applications do not communicate properly.

The workaround may be effective enough that the wider business accepts it as part of the job. Over time, nobody questions why the employee is still manually moving information that already exists elsewhere.

That is exactly the kind of thing I want to understand during an operational review. The workaround isn't just extra administration; it is evidence that the underlying workflow may have a gap.

People will usually adapt to a process that does not work for them.

Employees still have work to complete even when the system or process is awkward.

If the formal route regularly slows them down, they will often find a practical alternative. That might mean an extra spreadsheet, a personal checklist, information stored somewhere unexpected, or a manual step that was never part of the original design.

Some of those adaptations may be sensible. Others may introduce risk, duplication, or inconsistency.

You cannot really judge that until you understand why they exist.

That is why I think the first response to an unofficial process should be curiosity rather than correction. The workaround may point directly to a weakness that would otherwise remain hidden.

Staff need to feel comfortable explaining what really happens.

This is one reason employee conversations matter during an operational audit.

If staff believe they are being assessed on whether they follow the documented process perfectly, they may be reluctant to explain how they actually work. You then risk documenting the version of the business that exists on paper instead of the version that operates every day.

I would rather hear where the process is awkward, which systems people avoid for certain tasks, and where they have developed their own ways to keep work moving. That information is often much more useful than a perfectly clean description of how the workflow is supposed to function.

The purpose is to understand what someone's behaviour is telling you about the process.

Investigate before deciding what to change.

Finding an unofficial process does not automatically tell you what the solution should be.

Perhaps the documented process needs changing. Two systems might need proper integration, the software may need different configuration, or employees may need better training. In some cases, the workaround itself may be the more practical process and should be formalised.

The important thing is to investigate before deciding.

When a business looks only at how work was designed to happen, it can miss the operational reality employees deal with every day. The gap between the official process and the working version often shows what really needs attention.