Procurement process improvement
Most procurement functions are not slow because the people are slow. They are slow because the process was never designed. It accumulated, one approval and one workaround at a time, until nobody could describe it end to end.
The problem this solves
A requisition passes through more approvers than the value justifies, because thresholds were set years ago and never revisited. A AED 4,000 purchase and a AED 4 million contract follow the same path, so the small ones clog the queue and the large ones get the same cursory glance.
The steps that add control and the steps that merely add delay look identical from inside the process, so every attempt to speed it up is resisted as a loss of governance. Nobody has separated the two.
The business responds the way businesses always do. It routes around procurement entirely, and the spend that most needed a process ends up with none at all.
What we actually do
The steps, in the order we run them.
Map what actually happens
Not the policy document, the real path. We walk transactions through the system with the people who handle them and record every touch, wait and rework loop, including the ones nobody admits to in workshops.
Measure the delay
Each step gets a cycle time and a queue time. Almost always the working time is a small fraction of the elapsed time, and the delay sits in handoffs and waiting for approvals rather than in the work itself.
Separate control from friction
Every step is tested against one question: what risk does this control, and what would happen if it were removed? Steps that control nothing are removed. Steps that control something real are kept and, wherever possible, automated.
Redesign around thresholds
Approval paths are rebuilt so effort scales with value and risk. Low-value, low-risk, on-contract purchases flow through with minimal intervention, freeing senior attention for the decisions that deserve it.
Embed and hand over
New process, updated delegation of authority, revised policy and the training to go with it. We stay through the first cycles, because a process that is not used in month three was never really implemented.
What you get
- An end-to-end process map of the current state, with cycle and queue times
- A redesigned procure-to-pay process with risk-based approval thresholds
- An updated delegation of authority matrix
- Revised policy and procedure documents your auditors will accept
- Role-based training and the first cycles run alongside your team
Separating genuine controls from inherited friction typically takes 50 to 75 per cent out of sourcing and tendering cycle times, while the control environment gets stronger rather than weaker, because the controls that remain are actually enforced instead of routinely bypassed.
Questions we get asked
Will cutting steps weaken our controls?
It does the opposite when done properly. A process with fifteen approvals that everyone bypasses under deadline pressure controls less than a process with four that are genuinely enforced. We remove steps that control nothing and strengthen the ones that control something real.
How long does process improvement take?
Eight to twelve weeks from mapping to a redesigned process in use, for a single procure-to-pay flow in a mid-sized organisation. Complex multi-entity groups with several ERPs take longer, and we would scope that honestly before starting.
Do we need new software to fix the process?
Usually not first. Automating a broken process makes it fail faster and at greater expense. We fix the process, then decide what technology it justifies. Sometimes the answer is configuration of what you already own.
What if our people resist the change?
Expect it, and design for it. Resistance is usually rational: people have been measured on the old process and burned by past changes. We involve the people who run the process in redesigning it, which is slower at the start and far faster at adoption.
Where to start
Run the free procurement maturity diagnostic for a scored view of where the gaps are, or talk to a consultant about this specific problem. Both take less time than a meeting about having a meeting.
Talk to a consultant