When I started working more deeply on business processes, I expected the challenge to be about understanding workflows and finding technology to support them.
I was right, but only partly.
Over the past year I have worked across process design, data, integrations, governance and organizational change. The most valuable lessons were not about methodology or tooling. They were about how organizations actually work.
The hardest process problems are rarely process or technology problems. They are problems of ownership, governance, decisions and change.
The happy path is not the process
Drawing a process is easy. Who does what, what information is required, which system supports each step.
Reality gets interesting when something goes wrong.
What happens when an owner leaves? Who fixes outdated information? What happens when two teams read the same rule differently? Who owns an exception nobody anticipated?
A process is only proven when the organization knows what to do at that point. That means designing for exceptions, escalation, ownership and recovery, not just the ideal workflow.
Data problems are usually governance problems
When information moves between systems and something breaks, the reflex is "there must be a problem with the integration."
Sometimes there is.
The better first question is whether the integration created the problem or simply exposed it.
A technically perfect integration will faithfully move incomplete or outdated information from one place to another. So instead of asking how to fix the data, I now ask where it should have been correct in the first place.
Fixing information downstream solves today's incident. Fixing ownership and validation at the source prevents tomorrow's.
Source of truth is more complicated than it sounds
It is easy to draw two boxes, connect them with an arrow and declare one the source of truth.
Information has a lifecycle. It originates in one place, gets enriched somewhere else, triggers a decision elsewhere, and later changes because reality no longer matches the original assumptions.
So the question is not only which system owns this information, but who owns it at this point in its lifecycle. That distinction changes how you design both processes and integrations.
Edge cases are where architecture becomes real
A new request following the expected lifecycle is straightforward.
Now change the assumptions halfway through. Reduce the scope. Change the dates. Replace an owner. Discover that a previous decision can no longer be executed.
Assumptions hidden inside the process become visible.
I have become a believer in deliberately trying to break a process before calling it complete. Happy paths validate workflows. Edge cases validate architecture.
An uncomfortable question can be a deliverable
Early in my career I equated good work with finding answers. Identifying the right unanswered question can create just as much value.
Who owns this? Who decides when two sources disagree? Where should an error be corrected? What happens when the person responsible is gone?
Turning an implicit ambiguity into an explicit decision is often the most useful thing you can do. Making ambiguity visible is part of solving the problem.
Documentation is organizational memory
Process diagrams, architecture views, assumptions, risks and decision records are not valuable because producing documents is valuable.
They matter because eventually someone asks why we designed it this way. Remembering the decision without remembering the alternatives, constraints and risks is surprisingly easy.
I try to document not only what was decided, but why. Good documentation preserves reasoning, not just outcomes.
Teaching tests understanding
Explaining a process to someone else exposes gaps that are easy to ignore when the knowledge only lives in your head.
There is a difference between "I know how this works" and "I can explain why it works this way, what happens when it fails, and which questions remain open."
The second takes much deeper understanding.
A year later
Process design without ownership creates ambiguity. Integration without data governance just moves problems faster. Automating a broken process makes the broken process faster.
And my understanding of Business Process Management has shifted. I used to think it was about understanding and improving processes. Now I see it as creating clarity around how an organization operates, how information moves, who owns decisions, and what happens when reality does not follow the diagram.