The most expensive and least examined workflow in most IT organizations is procurement. It is not flashy. It does not appear on transformation roadmaps. It does not have a dashboard the executive committee studies. It runs in the background of every other initiative the function delivers, and because it runs in the background, almost nobody asks whether the background process is actually working. When I joined Apple Bank, the IT procurement workflow was nine days long, took eleven approval steps, and produced an error rate that meant about a third of requests required rework before they ever became a purchase order. The procurement team was not negligent. They were optimized for compliance and document accuracy, which is the right thing to optimize for if you frame procurement as a finance function. The frame was the problem.
What happens when procurement is a finance function
The procurement workflow Apple Bank inherited was the standard one. A requester logged into a request system. Their request went to the IT manager. The IT manager reviewed it for technical fit. The request was then routed to a finance form, which had to be filled out separately from the original request, because the request system did not know about the finance form. The finance form was submitted to accounts payable. Accounts payable validated the request against budget, vendor master data, and an approval matrix. If anything was missing, the form went back. The cycle averaged nine days.
Every step in that workflow was defensible in isolation. The IT review made sense for technical fit. The finance form made sense for budget compliance. The A/P validation made sense for vendor master accuracy. The problem was that every step in that workflow was designed to protect the function that owned the step. No step was designed to deliver a service to the requester. The cumulative effect was a nine-day cycle for what was, at the user level, a single decision: I need this piece of software, please get it.
What happens when procurement becomes a service function
The reframe was simple to articulate and complicated to implement. The reframe said that the requester is a user, the request is a service, the eleven approval steps are service design choices, and every step that does not produce information the service needs is a candidate for removal. Once you start asking that question on every step, three of eleven are immediately defensible and the other eight have to make their case. Some of those eight survive the case. Most do not.
The implementation was the integration between ServiceNow and the bank's Accounts Payable system. The integration is technically straightforward. The hard part was not the integration. The hard part was the political work of convincing four functions (IT, finance, A/P, and vendor management) that they were no longer the owners of their own approval steps. They were now the owners of an end-to-end service that crossed all four of them. That reframe is what produced the chart above. The integration was the artifact. The reframe was the work.
The handoff that wasn't
The clearest way to see what changed is to look at the handoff structure. The before workflow had three handoffs between functions, each of which produced delay, rework risk, and friction. The after workflow has zero handoffs because the workflow is now one process that the three functions execute against, rather than three processes that hand off to each other. The boxes look almost identical. The arrows between them are doing fundamentally different work.
Why PO cycle time is a service KPI, not a finance KPI
The most important number on the chart in Fig. 1 is the cycle time. Not because it is the largest improvement, although it is. Because it is the only one of the five numbers that the business actually feels. The business does not care how many approval steps a procurement workflow has. The business cares how long they wait between asking for something and getting it. Cycle time is the user experience of the procurement function. It is the equivalent of time-to-productivity for a service desk. It is the metric a business leader would put on the dashboard if they could only have one.
For most of my career, that metric was not reported anywhere except inside the procurement team. The procurement team owned it. The procurement team also owned the workflow, which meant any complaints about the cycle time were complaints against the procurement team, which produced a defensive posture, which produced a slower workflow. The reframe to treat procurement as a service moved the metric out of the procurement team and into the service operating model. Now it is reported alongside every other service KPI. The procurement team is no longer defending the number. They are working with the rest of IT to improve it. That is a completely different relationship than the one I inherited.
The governance conversation that made this possible
The integration project would not have produced any of the chart's results without the governance work that came before it. The four functions involved had to agree, in advance, on three things. First, that procurement was a service whose ownership crossed function boundaries. Second, that cycle time was the primary metric, with first-time-right rate as a secondary measure and total spend as the financial outcome. Third, that any of the four functions could escalate a process step that was no longer earning its keep, and any of the four had standing to remove it after a thirty-day review.
That third agreement was the hard one. It required each function to give up unilateral control of its own approvals. We made the trade because the alternative was the workflow staying nine days long forever. Once we had the agreement, the integration became downstream work. We could not have done the integration without the agreement. Most integrations fail because they try.
If your procurement workflow takes more than seventy-two hours for a standard IT request, that is not a finance problem. It is a service design problem. Tell me how you would fix it.
What CFOs notice
The most interesting part of this story is what happened with the CFO. The CFO had inherited the same nine-day workflow and had quietly assumed it was a constraint of running a regulated bank. When the cycle time dropped to twenty-eight hours and the spend dropped fifteen percent in the same year, the CFO became an active sponsor of the next service-reframing project I proposed. The relationship between IT and Finance, which had been transactional, became collaborative. The cycle-time improvement was the receipt that earned us the next conversation.
That sequence (deliver a real receipt, earn the next conversation) is the entire game at the executive level. IT functions that wait to be invited into strategic conversations do not get invited. IT functions that produce one undeniable result and then ask for the next conversation get the conversation, and then the conversation after that. The procurement reframe was the first such receipt I produced at Apple Bank. It is also the reason every subsequent reframe has had executive support.