Making Work Visible

Initially, my thought process at work was quite straightforward.

Understand the issue. Identify the bottleneck. Build a solution that actually solves the problem. Then ask for feedback, let people give input, improve it, and make sure the solution addresses something with real urgency.

To me, that felt natural.

If something was slowing people down, the goal was to understand why and fix it. If a task was repetitive or taking too much time, the goal was to find a better way to do it.

But over time, I realised something.

Knowing the problem is one thing. Explaining it clearly to others is another.

Even if you understand the issue in your head, and even if you can explain it in simple terms, it does not always mean everyone sees the same thing. Different people may understand the process differently. Some may only see their own part of the workflow. Some may not understand it through words, text or mind maps alone. Some may need to see how the process actually flows before the issue becomes clear.

That was when I was introduced to BPM at work.

At first, I looked at frameworks like DMAIC and felt that some parts overlapped with what I was already doing. Define the problem, understand the root cause, improve the process and test whether it works. In many ways, these were things I was already doing.

But the value of a framework is not just that it teaches you something completely new.

Sometimes, the value is that it gives structure to what you already know.

For me, BPM made process improvement more visible and more repeatable. It is not just about connecting boxes in a workflow diagram. It is about breaking down each process into simple but meaningful steps, understanding the objective of each step, identifying dependencies and seeing how work actually moves from one person to another.

It creates a common language.

Instead of saying "this process is messy," you can show where the process gets stuck.

Instead of saying "there are too many follow-ups," you can show which step depends on missing information.

Instead of saying "this task takes too long," you can show where time is being lost or spent waiting for someone else.

That makes conversations easier.

People can point to a specific step and say, "Actually, this is where the issue happens." Or, "This part is missing." Or, "This is not how it happens in practice."

That feedback matters because the best process map is not the one that looks the nicest. It is the one that reflects reality clearly enough for people to improve it together.

That is how I started incorporating BPM into my workflow.

Not as a fancy framework, but as a way to make invisible work visible.

Because sometimes, solving a bottleneck is not just about building a tool or changing a step. It is about helping people see the process clearly enough to understand where the problem really is.

And once people can see the process, it becomes easier to improve it.

There are also many AI tools that can support BPM-related work today, from drafting process maps to summarising interviews and identifying workflow gaps.

Anyone interested to find out more about these tools can lmk.