Bad processes cost organisations 30% of annual revenue. What makes that number persistent is the layer beneath it: most organisations know which processes are broken, redesign them on schedule, and then watch the improvement dissolve within six months. The analysis was correct. The redesign was sound. The problem was ownership — or the absence of it.
A process owner is the person with formal authority to approve changes to a process's design, exceptions, and performance thresholds. That definition matters because it is different from how most organisations use the term. "Process owner" typically names a person. What it rarely specifies is the decision rights that make the title real.
The gap between title and authority is where most improvements die.
The category error every org chart makes
Your organisation almost certainly has process owners on paper. Their names appear on SOPs, audit attestations, and transformation project plans. Ask five people in operations who owns your customer onboarding process. You will likely get six answers.
This is a category error. "Process owner" has been defined as a title — a label attached to a person — when what processes actually require is decision authority attached to a specific role. The title creates the appearance of ownership. The authority creates the reality.
The consequence shows up predictably. A process improvement project completes. An owner is named. The project closes. Three months later, a regulatory update, a staffing change, or a new system integration alters the process informally. Nobody has the authority to reject the informal change. Nobody has the mandate to trigger a formal redesign. The workaround becomes the new standard. By month six, the improvement is indistinguishable from the problem it replaced.
Process improvement fails at the ownership layer, not the analysis layer.
What decision rights actually mean
Three rights define whether a process owner can exercise genuine ownership:
Design authority. The owner can approve changes to the steps, sequence, inputs, or outputs of the process. They do not require committee approval for standard modifications. Committee escalation is appropriate for major redesigns; requiring it for every iteration is how processes drift unchecked between reviews.
Exception authority. The owner sets the conditions under which the standard process may be bypassed, and approves or denies exception requests when they arrive. Every exception that is logged — not handled informally — becomes an input to the next improvement cycle.
KPI authority. The owner sets the performance thresholds that define a healthy process. They hold the authority to trigger a redesign when those thresholds are breached. This right converts the feedback loop from advisory to binding.
These three rights are separable. A bank might assign design authority to an operations lead, exception authority to a compliance manager, and KPI authority to a finance controller. What is not acceptable — if improvement is to last — is leaving any of the three unassigned. Partial ownership is tested and fails at the first real pressure point.
The distinction between decision rights and responsibility is the moat. Many people are responsible for a process — they execute it, monitor it, and escalate when it fails. Only the owner has the authority to change it. That single distinction is what separates an improvement that holds from one that slowly reverts. Responsibility without authority produces accountable people who cannot act; authority without accountability produces owners who never hear the signal that action is needed.
In banking operations, this distinction has a practical test. When a regulatory update arrives mid-quarter, the first question the compliance team should be able to answer quickly is: who holds authority to approve the process change this update requires? If that question takes multiple email exchanges to resolve, the rights are ceremonial, not operational. Ownership that cannot be reached and exercised on the day a change is needed functions the same as ownership that does not exist.
Why banking operations amplifies the problem
Processes in banking operations face more change events than processes in most industries. Regulatory updates from MAS or BNM alter compliance steps. System migrations change input formats. Talent turnover depletes the informal knowledge held in the team. Each event tests whether the named process owner's authority is real or ceremonial.
Consider a hypothetical scenario common across regional banks. (Illustrative — this is a constructed example, not a client result.)
An operations lead is named process owner for a bank's credit file verification workflow. The name appears on the SOP. The lead attends quarterly reviews and signs the annual compliance attestation.
A compliance update arrives mid-year. The compliance team issues internal guidance and adds a verification step to their own checklist. The operations team continues following the original SOP. Two versions of the process run in parallel for six weeks before an audit finding surfaces the discrepancy.
The named owner had responsibility — but not exception authority. The compliance team did not know a formal change-control step was required. The owner did not know they had authority to demand one. The title existed. The rights did not.
How ESSAM's 7-step cycle assigns ownership at Step 4
The ESSAM E-S-S-A-M framework — Eliminate waste, Simplify & Standardize, Automate, Migrate low-value work — operates through a 7-step cycle: Baseline → Analyze → Optimize → Document → Deploy → Feedback → Repeat.
Step 4 — Document & Approve — is the ownership moment. It is not merely the step where the SOP is written. It is where the three decision rights are recorded in the process document alongside the steps themselves.
At Step 4, the process record names:
- Who holds design authority, and what scope of change they can approve without escalation
- Who holds exception authority, and what logging requirement accompanies each approved exception
- Who holds KPI authority, the threshold values, and the trigger condition for initiating Step 7 (Repeat)
This structure is intentional. Steps 5 through 7 — Deploy, Feedback, Repeat — depend on named authorities being in the loop. When the Feedback step returns performance data, it goes to a named KPI authority who can act on it. When a Repeat cycle is triggered, it routes to a named design authority who can approve the updated SOP. The cycle closes because ownership rights are embedded in the record, not assumed from the org chart.
Without this structure, the cycle does not close. Feedback goes to a shared inbox. Redesign proposals go to a committee with no mandate to decide. The process drifts back toward its pre-improvement baseline — within the same six-month window the consulting engagement bought it.
This is why ESSAM's conversational capture matters at this stage. A single session produces not just the documented steps, but the governance layer that sits above them. No flowchart software required. No IT team required. One conversation yields a process record with ownership rights embedded and ready for approval.
Four questions to assign rights before the next project closes
If a process improvement project is currently in its Optimize or Document phase, this is the window for ownership assignment. Four questions determine whether the rights are covered.
1. Who can change the steps? Name one person with design authority, not a committee. Committees serve major redesigns. They are a bottleneck for the iteration that follows every compliance update or system change.
2. Who approves exceptions? Name the exception authority and set a 24-hour response expectation. An exception authority that cannot respond within 24 hours is a bottleneck, not a safeguard — Simplify the exception step before assigning authority to it.
3. What triggers a redesign? Set the KPI threshold in advance. A process owner with KPI authority but no defined threshold has no signal to act on. The threshold converts authority into an operational trigger.
4. How do changes reach staff? In Singapore and Malaysia, WhatsApp penetration among the working population is 88% and 92% respectively — industry data, externally sourced. ESSAM deploys approved SOPs through WhatsApp, requiring no app installation and no retraining event. When the owner approves a change at Step 4, staff receive the updated SOP the same day. Ownership decisions without deployment reach are incomplete.
Where this model has limits
Decision rights solve the authority gap. They do not solve the bandwidth gap. An exception authority holder managing three concurrent projects will become a bottleneck. If the exception-approval step requires 48-hour turnaround, the process will accumulate informal bypasses faster than the owner can close them. Assign exception authority to someone with the operational time to exercise it.
Rights must also be embedded where they are used — in the process record staff and stakeholders consult during change events. Governance documents that exist outside the process record are discovery failures waiting to become audit findings. A three-page governance deck in a shared folder does not govern a process; the rights embedded in the SOP record do.
Finally, the cycle must run. A process owner with decision rights but no scheduled Feedback review has authority over a process that generates no signal. Compliance-focused processes in SG and MY typically require quarterly reviews at minimum. High-volume transaction processes may require monthly reviews. When the cycle does not run, the rights are dormant — and dormant rights do not prevent drift.
There is also a sequencing consideration. Ownership assignment at Step 4 only works if the process record produced at that step is the authoritative version staff actually use. If the SOP lives in one location and the approval record lives in another, the gap between them is where informal change takes hold. ESSAM's conversational capture produces a single record that holds both: the steps and the governance layer that controls them.
The ownership layer that keeps improvements alive
The Kuwait bank procurement case produced a 59% cycle-time improvement: 139 days down to 57. That result was not preserved by the analysis that identified the waste or the redesign that removed it. It was preserved by the ownership layer that governed what happened next — and by the feedback loop that surfaced drift before it could compound.
Every process improvement project produces an analysis and a redesign. The ones that last produce an owner: with named rights, embedded in the record, connected to a deployment channel that reaches staff on the day a decision is made.
Your org chart has owners for every department. The question is whether any of them own a process — with the three decision rights to prove it, embedded in a record that staff and stakeholders can consult when change arrives.
Get a decision-rights audit for one process
Describe one process your team improved but suspects is drifting. Send it to ESSAM. We return a decision-rights assessment: which of the three ownership authorities are assigned, which are gaps, and what the Step 4 documentation should contain to close those gaps. No software installation. No specialist required. One process, one conversation, one session.
Send the process description to https://apac.essam.ai/contact.
Frequently asked questions
What is a process owner?
A process owner is the person with formal authority to approve changes to a process's design, exceptions, and performance thresholds. The role requires three explicit decision rights: design authority, exception authority, and KPI authority. A title without those rights is not ownership — it is accountability without the means to act on it.
What is the difference between a process owner and a process manager?
A process manager runs the process day-to-day: supervising staff, handling escalations, and monitoring throughput. A process owner holds the authority to change the process when performance drifts or conditions change. One person may hold both roles in smaller teams. In larger banking operations, separating the two prevents operational managers from making ad-hoc design changes without formal authorization.
Why do process improvements fail within six months of the consultant leaving?
Most improvement projects name a process owner without assigning decision rights. When the first exception arrives — a regulatory change, a staffing shift, or a system update — no one has authority to decide whether the process adapts formally or holds. The exception becomes an informal workaround. The workaround becomes the new default. The improvement dissolves before anyone notices the backslide.
How does ESSAM assign process ownership at Step 4?
Step 4 of ESSAM's 7-step cycle — Document & Approve — embeds the three decision rights into the process record alongside the SOP steps. The record names who holds design authority, who holds exception authority, and who holds KPI authority with defined thresholds. Subsequent steps — Deploy, Feedback, Repeat — operate with those named authorities in the loop, so the cycle closes rather than stalling after go-live.
Why does WhatsApp deployment matter to process ownership?
A process owner who approves a design change at Step 4 needs a channel that reaches staff the same day. That channel should require no app installation, no IT ticket, and no training event. ESSAM deploys approved SOPs through WhatsApp — the primary communication channel for operations staff across Singapore and Malaysia. The deployment channel is part of the ownership model: authority without reach is a signature on a document nobody reads.
Related reading: