A document is not a process
I like structure.
I like knowing who owns something, what should happen next and what “done” actually means.
But I don't believe a company becomes organised just because it has written more SOPs.
A document is not a process.
A process exists only when people actually work differently because of it.
The problem with many SOPs
A lot of SOPs are created for the wrong reason.
Someone asks: “Do we have an SOP for this?”
A document gets written.
It is saved somewhere.
Maybe the team reads it once.
A few weeks later, people are again asking the same questions in messages and meetings.
Who should do this?
Who approves it?
What happens if something goes wrong?
What happens next?
Technically, the company has an SOP.
Operationally, nothing changed.
A good SOP should reduce decisions
People should not have to repeatedly make basic operational decisions that have already been made.
If a candidate reaches this stage, what happens next?
If a customer makes a payment, who verifies it?
If work is rejected, who receives it back?
If an employee needs approval, where should it go?
If every employee has to ask someone each time, the process still depends on people remembering what to do.
A useful SOP should remove some of that uncertainty.
Ownership matters more than documentation
One of the biggest process problems I see is unclear ownership.
Three people may be involved in something, but nobody actually owns the final outcome.
That creates follow-ups.
Follow-ups create delays.
Delays create more meetings.
Eventually everyone looks busy, but the work is still waiting.
An SOP should make ownership obvious.
Not just: “Sales will coordinate with Accounts.”
But: Who sends it? When? What information is required? Who can approve it? What happens if it is incomplete? Who owns the next step?
Those details are where processes actually work or fail.
Exceptions matter too
Processes usually look good when everything goes perfectly.
The real test is what happens when something doesn't.
A customer pays only part of an invoice.
A candidate misses an interview.
An approval is rejected.
An employee submits incomplete information.
A client changes the requirement halfway through.
If the process works only for the ideal situation, people will still create their own solutions whenever something unusual happens.
Good operational design needs to think about exceptions, not only the normal path.
SOPs should evolve
I also don't believe an SOP should become permanent just because somebody approved it.
Businesses change.
Teams change.
Customers change.
Software changes.
Sometimes a process that worked six months ago becomes unnecessary today.
Sometimes employees find a much better way of doing something.
A useful SOP should be controlled, but it should also be allowed to improve.
The real question
When I look at a process, I don't want to know only whether there is documentation.
I want to know: Can the employee understand what they need to do? Can the next person understand what they are receiving? Is ownership clear? Are exceptions handled? Can the business see where something is stuck?
If the answer is no, writing another document probably won't solve the problem.
The purpose of an SOP is not to prove that a company has processes.
It is to make good execution easier.