Procurement as a Service (Part 1): Should Procurement Really Be a “Service Provider”?

service Andrey Popov/Adobe Stock

Many procurement organizations may wince at the idea of being called a "service provider.” The term seems very transactional and low impact. Most procurement organizations are striving for much deeper spend influence and usually prefer a term like "business partner."

Yet the world is moving to a service orientation, not just in the consumer world but also in the business world, which in turn is becoming a digital world. Whether procurement groups choose to use the “service provider” terminology or not (e.g., the principles can be adopted without using the explicit terminology with stakeholder), they will need to consider a services-oriented operating model, or “service delivery model,” if they want to improve their delivered value.

Here’s why.

At many large organizations, “global business services” has increasingly become a standard operating model for all major functional areas such as finance, HR, IT, real estate, procurement, customer support and other areas. (You can read more here and here on this impact on procurement.) This model is not about rebadging shared services and making procurement report up to a glorified CAO, or making corporate staff get pushed out to shared service centers in low-cost countries. Rather, it’s about running a service-oriented model to ensure that budget owning business units (and partner functions) are getting value from their investment in procurement.

More fundamentally, a service orientation forces a level of rigor and discipline within procurement regarding what value it fundamentally adds, and then getting alignment surrounding performance metrics and internal service level agreements (SLAs). A business process becomes a service when the outputs of that process to a “customer” (e.g., think about SIPOC model) are specified, funded, measured and improved.

Whether the services in the “service catalog” are transactional (e.g., the time to respond to a non-catalog purchase request), operational (e.g., on-time delivery of sourcing projects) or strategic (e.g., level of supplier innovation delivered into the product/service delivery process), the act of specifying them helps bring transparency to these value streams.

Specifying services also means specifying service levels. If you want supplier service contracts to have SLAs, it’s reasonable to expect your stakeholders may want the same from you. SLAs are also key for setting expectations. Your suppliers may set service levels in accordance with, say, the lead times you give them. The same applies in how you do the same with your internal customers, and many procurement organizations have indeed set in place these type of bi-directional SLAs.

Services (and associated SLAs) should have some sort of basic linkages to KPIs, right? But, often there are major disconnects. For example, if you are performing lots of value-creating services, but aren’t getting credit for them, should you be doing them? If it’s valuable, you should have a “customer” for that service. Conversely, do your internal customers feel they’re getting any real services from you that are helping them? If so, you need to align your services and SLAs to the metrics of importance to them.

That said, these need to be services that you should be performing based on shareholder value (and not end user convenience), and again, you need to get agreement with your internal customers on this. Some stakeholders may like white glove concierge service and lob over free-text requisitions, but this is not a service that procurement may want to offer, except for specific tail-spend requirements. In this case, the service delivery model should either specify that procurement won’t help (e.g., p-card spend that’s low spend and low risk) or that the service will be sub-contracted out to a third-party service provider.

The consideration of third-party service providers and service models will be the subject of the next installment of this series. Stay tuned.

Discuss this:

Your email address will not be published. Required fields are marked *