Supplier Management (or the Management of Suppliers)
Our latest guest blogger is ITIL Zealot and eConsultant® Simon Dorst. Take it away, Simon…
Recently, I have been working on the SIAM Body of Knowledge, which gave me the opportunity to do more of a deep-dive into the SIAM theory. I found there are concepts that on the surface seems straightforward enough, but are actually surprisingly complex.
Take the management of suppliers, which is an essential concept of service integration and management (SIAM).
“The multi-provider delivery models evident in many modern enterprises have created an interest in the benefits SIAM can bring. More and more customers are calling for better defined and more cohesive control structures that will allow the management of multiple service providers in a consistent and efficient way.”
Source: Who is the King of SIAM? Whitepaper, Simon Dorst, Michelle Major-Goldsmith, Steve Robinson, Copyright © AXELOS 2015. All rights reserved
The easy solution is to conclude that SIAM is nothing new and that other enabling practices, like ITIL, have already covered this. Specifically, within the globally recognised ITIL service management best practice there is a process defined as Supplier Management, with its goal:
“to manage suppliers and the services they supply, to provide seamless quality of IT service to the business, ensuring value for money is obtained”
Source: ITIL® Service Design Copyright© AXELOS 2011. All rights reserved
So there you have it, case closed, it’s all sorted….
However, Supplier Management is a multi-faceted process. It is defined within the Service Design publication, but includes activities across all of the service management lifecycle; starting with a supplier strategy and policy from Service Strategy, the definition, design & evaluation of new suppliers & contracts, the establishment (or transition) of these as well as the management of supplier & contract performance on a daily, operational basis.
Overlaid on the SIAM ecosystem, which consists of the customer retained, strategic organisation (governance), the service integrator tactical functions (control) and service delivery providers (operations), this is not an easy fit.
Source: SIAM Foundation Body of Knowledge, Copyright© Scopism Limited 2016
Thus, we need to redefine Supplier Management, what it is and what it isn’t and perhaps rename the ‘leftovers’ to clarify what activity they perform (and for which stakeholder).
To me, the essence of Supplier Management is simply that: ‘managing the supplier’. As such it clearly sits in the Service Integrator layer of the SIAM ecosystem. And this, in turn, automatically means there is little involvement in the definition of a supplier strategy and policy, as that is a customer retained, strategic component.
The involvement of supplier management, and the service integrator performing this process, will increase with the ‘design’ of each service provider’s contract & engagement, and the transition of selected (external) service providers. But the process really concentrates around the day-to-day management of all, internal and external, providers (‘end-to-end’).
At the same time the process should not become too technical and detailed\operational, as supplier management needs to keep the overall value of each supplier in focus, without getting ‘bogged’ into nitty-gritty performance … (compare for instance the sensible differentiation between Change Management vs. Release & Deployment Management which also distinguished between a higher level change assessment and approval and a more technical testing & implementation).
Performance Management is the day-to-day control of the service providers, and whilst there is a clear link with Supplier Management, it is also relevant to separate these activities, in particular if a hybrid SIAM integrator structure is chosen as this will allow a distinct separation between the customer SIAM and external integrator role (i.e. the customer can perform Supplier Management, leaving the external integrator to do Performance Management).
Performance Management will also link to a more technical capability (than Supplier Management), specifically around an integrated toolset to be used across the service providers (and as such links to Event Management).
To a degree this process maps onto a ‘Measuring and Reporting’ process which is not specifically defined within the ITIL framework, but certainly implied, but more clearly described in for instance ISO\IEC 20000 (‘Service Reporting’). It deals more tangibly with metrics, targets and reporting, allowing the Supplier Management process to focus more on the relationships and overall value obtained from each provider.
But neither of these processes deals with the specifics of a legal contract or agreement.
The role of contract management begins with the obvious management of the legal documentation that defines the engagement, requirements and performance of each provider. These contracts are held by the customer organisation (as otherwise it would be a prime provider model, which is not quite SIAM -as in this model the providers are not integrated nor managed by the customer-) and thus not easily allocated within the Supplier Management process described earlier.
But the strategy and policy activities that were ‘left out’ of that process, can now be incorporated into this new, separate Contract Management.
The outcome is a customer-retained process that works on a strategic\tactical level (i.e. very little day-to-day activities, other than from an escalation point-of-view). This also then easily defines the relation with Supplier Management (in the ‘upper’ SIAM Control layer, looking after tactical value of the service providers) and Performance Management (in the ‘lower’ SIAM and the Service Provider layer, focusing on operational performance).
However, all these ‘management’ processes focus on defined, measurable performance, relationships and contracts. What is more or less ‘forgotten’ is that in order to truly deliver value to the customer, end-to-end, it is important that each individual service provider not only delivers their targets and contractual performance requirements, but has a focus on the ‘common good’ of the business goals.
In a SIAM ecosystem, service providers need to put competitive considerations aside and adopt a new way of working. On an operational level this culture or attitude can be described as ‘Fix first, argue later’: when there is as service affecting issue, service providers need to work together rather than assign blame or pass issues around.
But when looking at processes like Knowledge Management or Continual Service Improvement, it goes a step further where providers should actively participate, contribute, share and collaborate towards efficiency and effective benefits, even if these benefits may not directly reflect on their individual provider contract.
Managing and encouraging this collaboration is, in my opinion, over and above the described processes of Contract, Supplier and Performance Management. It relates to Knowledge Management and CSI processes, but again this is not an easy, natural fit. And when taking a concept like innovation into account, it is clear that this is a lesser defined but certainly not unimportant aspect of the service integrator’s role in a SIAM ecosystem.
I look forward to watching how the definition of SIAM will further develop this, and other capabilities. The recent release of the SIAM Foundation Body of Knowledge, and accompanying SIAM Foundation training and certification program, is a great step to create a more uniform definition of what SIAM is, but also to provide a structure that will allows us to further define, discuss and hopefully augment our practices around SIAM.
Simon Dorst, @ITILZealot