A process can be documented, reviewed, and approved while the business continues to experience the same delays, missing information, and last minute escalations. The document may be correct. The operating model may still be incomplete.
That distinction matters in Finance & Administration modernization. A policy explains the rules. A workflow shows the path. A procedure explains the steps. None of them, by themselves, proves that work moves reliably between people or that the process holds when something goes wrong.
The executive question is simple: are we improving how the work gets done, or improving how we describe it? Answering it requires looking beyond the approved version and following actual work through the business.
The gaps often live between the boxes
Consider a routine invoice. Operations believes the supporting information has been provided. Accounts Payable believes it is waiting for confirmation. The approver sees a request without enough context. Each team may have followed its own instructions, yet the transaction still stops.
This is an illustrative example, not a client case. It shows why a handoff needs more than an arrow on a diagram. The sending team must know what makes the work ready. The receiving team must know how to accept it, where to find the evidence, and what to do if the package is incomplete.
For each critical handoff, define the required inputs, the receiving owner, the acceptance criteria, and the expected response window. Also define where status is recorded. An email sent is not the same as work accepted, and work accepted is not the same as an outcome delivered.
Exceptions are part of the process
A clean workflow typically shows the normal path. Daily operations introduce missing approvals, disputed amounts, incorrect job coding, unavailable decision makers, and urgent requests. If the process has no usable route for those situations, people create one.
Those informal routes can keep work moving, but they can also obscure accountability and weaken controls. A well designed exception path identifies who owns resolution, what evidence is needed, what work must pause, and when the issue should be escalated. Any temporary deviation should be authorized, recorded, and reviewed rather than quietly becoming the new standard.
Not every exception needs executive involvement. Leadership should establish the boundaries within which teams can resolve routine problems and identify the risks or decisions that require a higher level of authority.
Workarounds reveal design problems
A spreadsheet outside the system, a personal reminder list, or a repeated phone call is useful evidence. Before eliminating it, ask what job it performs. Does it supply missing visibility? Translate inconsistent inputs? Compensate for an unclear owner? Or bridge a system limitation?
The broader cost of workarounds is explored in our October Executive Perspective. For process improvement, the next step is more specific: use that evidence to identify the design gap. Removing a workaround before replacing its function can make the approved process harder to use.
Adoption has to be designed
Publishing a procedure is a release event, not an adoption result. People need to understand what changes in their daily work, how to find the right instructions, and where to get help when reality does not match the example.
Start with one bounded process and a representative set of users. Walk a routine transaction and an exception through the proposed steps. Include the people who provide inputs, not just the team that processes them. Test under normal workload, gather friction points, and adjust before expanding the rollout.
Keep the operating aid close to the work. A short checklist, clear submission requirements, or a visible exception queue may be more useful at the decision point than another long document. The full procedure remains the reference; the practical aid makes it usable.
Measure the change in the work
Document completion is a useful project milestone. Business improvement requires a different set of measures. Choose a small number, establish a baseline, and review them with the process owner:
- Handoff quality: How often is work accepted without being returned for missing information?
- Flow: Where does work wait, and how long does it take to reach the intended outcome?
- Exceptions: Which issues repeat, how old are unresolved items, and who owns them?
- Adoption: Are teams using the agreed path, and why do they depart from it?
Interpret these measures together. Faster completion is not improvement if required evidence or approvals are being bypassed. A temporary increase in reported exceptions may reflect better visibility rather than worse performance.
What good looks like in daily operation
The practical operating standard is straightforward: work arrives ready, a named owner accepts it, exceptions have a visible route, and leaders review evidence that the process is being used and producing the intended result. That is the bridge from this week’s executive question to a usable operating standard.
Before calling a process complete, ask the receiving team to demonstrate a real handoff. Ask the owner to show an unresolved exception. Ask a user to find the instructions without help. Then review whether rework and delays are improving.
Documentation creates a shared understanding. Modernization succeeds when that understanding changes the way the business operates.