Success factors for multi-provider sourcing

The dynamics in the market environment of IT providers are unbroken and the developments in the field of cloud offerings are far from complete. The result is that IT departments are facing a growing and heterogeneous landscape of IT providers.

by Anton Klee

Senior Consultant

19 January 2022

A multi-provider approach is the rule rather than the exception in today's agile environment. This blog looks at the factors for a successful multi-provider approach from a procurement and operations perspective and concludes with five golden rules.

Why multiproviders at all?

Doesn't it make more sense to source everything from a single source, i.e. classic one-stop shopping? The times when a company was a classic "IBM/HP/Cisco/Microsoft/..." shop" are long gone. Today, to put it bluntly, the IT departments have lost control of IT to a greater or lesser extent due to the various cloud services. The business units set the pace and the IT departments see themselves in the role of "integrators" of the various services they receive. Of course, the business units expect their applications to run smoothly and efficiently and - Log4J says hello - security to be guaranteed at all times.

What does this mean for IT departments? Differentiation according to the size of the company is a good idea. For (MSEs) it can make sense to rely on only one provider. As a rule, however, the core applications (be it a dispatch system for a courier service provider or a billing system for a law firm) are delivered by the specialist and usually also maintained. It is conceivable that a single external provider takes the lead here and coordinates all other providers in the sense and on behalf of the SME.

For larger MUs and large enterprises, on the other hand, a multi-provider approach is likely to be the norm, starting with the internet provider, through public cloud services such as mail and voice, to the procurement of server and storage services, virtually all companies today are confronted with a multi-provider environment. The big IT providers will try to refute this argument: Their offerings are global and provide the full range of IT services: from the data centre to networks to applications and the SOC. Such an approach can certainly be attractive and mitigate part of the multi-provider issue, but it presupposes that the IT department also has a 'global reach' and can meet providers of this size on an equal footing. Otherwise, caution is called for here: the willingness of the providers to engage with the needs of the demanding IT departments decreases as the size of the provider increases. This is not due to an inability or "bad will", but simply the compulsion of the large providers to use the "economies of scale".

Procurement and lots

So what to do? For now, let's turn to the question of procurement of IT services. The triggering point for procurement can be of various kinds: technology change, end of support, end of contract, cost pressure, public procurement law and others. It therefore coincides only coincidentally with an internal discussion about the sourcing strategy and thus the right mix of IT providers. Of course, it would be elegant if the IT and purchasing departments had a joint, medium-term plan in mind according to which the various IT services are procured. In this way, the multi-provider strategy could not only be defined, but also implemented. Ideally, the duration of the individual contracts would be synchronised or at least coordinated.

However, since this is usually not the case, it is advisable to ask the question about the envisaged provider strategy for upcoming larger procurement projects. The concrete question in this regard is the question of lot formation. Often, the lot formation is made according to purchasing aspects, with the understandable thought that large lots can lead to lower prices. However, this consideration alone does not go far enough. In fact, the multiprovider strategy is determined by the lots. Somewhat simplified and reflected in the generic IT stack, it is therefore necessary to determine which elements are to be procured jointly, i.e. as an integral lot, and which as an individual lot.

The graphic below can be used to launch the discussion. There will probably not be a unanimous opinion on the correct lot formation, but consensus building as such is already helpful: Here, the crucial questions are brought to the table from the diverse perspectives of the participants and mutual understanding for the respective positions is created.

Multiprovider Sourcing

It is quite obvious that the question of lot formation cannot be solved independently of the multi-provider strategy. Rather, the latter is determined by it. Two alternatives are shown above as examples, one for a 4-provider strategy and one for a 3-provider strategy.

The crux of the decision regarding the lots is not so much the actual procurement as a one-off matter, i.e. RFP with specifications, evaluation and award of contract, but rather the subsequent operational phase, which will last for years. During the operational phase, it will become clear whether the lots were chosen in such a way that the providers and the internal IT can function successfully together.

atrete sourcing advisory

IT sourcing advisory

Would you like to learn more about procurement with atrete?

Read more here

Process integration

This addresses process integration. As shown above, it is imperative that the ITIL processes function across the entire IT stack. It must be obvious that a larger number of involved providers also require more process coordination. Just take the example of the incident management process. The first question is who is responsible for incident management. The simple answer to this is that each provider must of course take responsibility for its services. Sounds plausible, but in practice it is not, because in the classic case the fault is always assumed to be with the other provider, thus starting the well-known back and forth of ticket assignments. Direct, straightforward troubleshooting, as envisaged by the ITIL textbook, is likely to be the exception.

Well, how can this be remedied? Since the problem is multi-layered, it is also worthwhile to act on different levels. We see three levels of action: one of the soft skills type, one technical and one formal:

  • Soft skills: transparency through communication, learning and continuous training
  • Technique: E-bonding[1]
  • Formal: Service Level Agreements (SLAs)

Creating transparency means showing the rough connections and making them known to all those involved, i.e. the external providers as well as the internal IT departments. The primary objective is to create clarity about responsibilities during and after the procurement phase. We are not talking about multi-page workflow presentations here, but about overviews that offer the various support units - each at their own level - an orientation in the provider landscape. Once implemented, this will probably become superfluous, because the teams involved will establish a working mode as experts in their fields. It is important to continuously improve this working mode through periodic exchange of experiences, FAQs, documentation of known errors and their workarounds as well as the deposit of knowledge base articles in the relevant ITSM tools. This may already be common practice in many companies today and not worth mentioning per se. The important point is that this common practice actually applies to every single provider. Whether a CH, near-shore or even an off-shore provider is involved, all will be familiar with ITIL processes and will have implemented them with a top ITSM tool. In practice, however, it turns out that these are good prerequisites, but not a guarantee that the incident management process will work in the multi-provider environment discussed here! The decisive factor for success is that the learning and training of the interrelationships of the IT environment and the ongoing improvement of incident management is done from the perspective of the purchasing company! To bring this about is - and will probably remain for a while - a challenge for the internal IT departments.

E-bonding is the buzzword of the second level of action. A buzzword that typically goes down well among IT cracks and - since it is technically elegantly feasible - is associated with great expectations. Often the need for e-bonding in procurement projects is also recognised and provided for in the agreements and contracts. Experience shows, however, that it is precisely here that attention must be paid to the chosen multi-provider approach. Who is the master? The ticketing tool of the largest provider or that of the company? Who sets the designations, the support groups, the priorities? If one of the big providers is in play, it might be difficult to override their standards. In a relationship of equals, on the other hand, it is easier to enforce internal ideas. Whatever the size of the relationship, it is essential that the internal process owners have their say in the matter. And it is equally clear that the internal IT architects must be on board with the design, because the technical implementation is usually more complex, more expensive and more time-consuming than is assumed in the course of and under the time pressure of the procurement.

The enticing thing about e-bonding - and this is also the reason why it should not be abandoned without necessity - is the company's ability to be close to the basis of reporting. Knowing whether and how the agreed services - i.e. the service levels - are being delivered by the various providers is match-critical, because knowledge is power - or more simply, knowing whether the SLAs are being met is the basis of the relationship with the providers. This brings us to the next level of action, the formal SLAs.

This third, formal level is about contractually securing the service levels, i.e. the SLAs. We deliberately mention this level only as the third, because in a certain sense it represents the fall-back level. Because it is possible - and often the case - that the SLAs are defined by all the rules of the art. Key performance indicators (KPIs) are precisely recorded and technically described in great detail, the operating hours and all other related definitions for fault reporting, ticket acceptance and what goes with it are agreed. Nevertheless, we cannot achieve certainty that the desired availabilities will be met - to stay with the example of fault clearance. The reason is simple: we can conclude SLAs with exactly one provider at a time. However, the achieved availabilities of the IT services are the result of the combined efforts of the troubleshooting across the entire provider landscape. The graphic below attempts to illustrate this.

However, this does not mean that SLAs are not important - the opposite is the case. In the multi-provider environment, coordinated SLAs are a mandatory prerequisite for achieving the service levels demanded by the business. The focus in procurement must be to contractually agree with each individual provider on the internal and thus the same operating model - starting with operating and on-call times - in the form of SLAs. The SLAs represent the common bracket of the operating model in the multi-provider environment!

In practice, the popular definition of minimum availability in the style of 99.99% cannot meet this requirement. Each provider will define these figures from his own point of view and not act from the company's point of view.

Multiprovider Sourcing

To mention it again: Smooth troubleshooting will primarily depend on the soft skills of those involved. The decisive contribution is made by the teams involved in the day-to-day business and assertive provider managers as mediators between the company and the providers. Technology (e-bonding) and formalism (SLAs) are useful "aids".

Let's turn to the "hot spot" of troubleshooting in a multi-provider environment, the service desk. We would venture to say that the service desk is THE success factor for successful troubleshooting. As the first point of contact for all messages and calls for help from IT users, this is where the decision is made as to how the troubleshooting will proceed. The first action of the service desk is triage, whether this is done by a human or - increasingly often - a robot. In the multi-provider environment discussed here, assigning the opened ticket to the correct support group is not always a simple matter. Knowledge of the entire IT landscape, the company AND the support organisation of the individual providers is required. Even more, the interrelationships of the individual IT services - i.e. the service chain - must also be known.

These are formidable requirements and the question arises whether, given the relevance of the tasks, a service desk in a multi-provider environment can be outsourced at all. Given the given importance, should this not better remain an internal function?

Practice shows that outsourcing of the service desk is prevalent, but unfortunately not always with the hoped-for success. The reason is simple: cheap offers in the near- or off-shoring sector tempt people to buy in service desk services. After all, maintaining a 24/7 support service by competent IT experts is a costly business at the local wage level. The counterpart of a 'cheap' offer is often a reduction in triage competence. Unfortunately, robots can only provide a rudimentary remedy, as these digital friends are nowadays mainly strong in solving standard cases. But standard situations are rarely the case when it comes to faults in the multi-provider environment. And if they are, they are 'known errors' and already covered by checklists or FAQs.

So how to proceed?

An interesting approach from our point of view, which we see more and more in practice, is the addition of a "1.5" level support to the classic 1st level support. In this case, a QA function is established and staffed with internal know-how carriers. As an 'inserted' QA function, this 1.5 level support monitors the correct allocation of tickets to the providers involved. Or in other words: an internal validation of the ticket queue and the allocation to the support groups is carried out by the 1st level initially. The goal: an improvement in the hit rate for faults in the multi-provider environment. A development that makes this approach additionally attractive is the current shift towards IT services from the various clouds; with the 'Journey to the Cloud', further complexity comes into play. And the preservation and maintenance of internal triage competence is gaining in importance.

Finally, a reflection on the topic of in- or outsourcing, a topic that in recent years has mostly been discussed with a preference for outsourcing. At most - more in the sense of appeasing those affected - the term 'right-sourcing' was still included. Today, the pendulum is already swinging back. We are increasingly seeing organisations that are re-sourcing important IT functions such as security. For the multi-provider issue, this means that internal departments are also to be classified as 'providers'. Sounds simple, but it is not: an SLA (external contractual obligation) is easier to claim than an OLA (an internal 'agreement'). The ticket flow in the event of a malfunction must also be regulated in detail again. Both in terms of the SLA-relevant times and the technology - the keyword e-bonding should be mentioned again here.

The fact is that sourcing strategy is not a one-way street towards out-sourcing and that the multi-provider theme is likely to gain importance through selective in-sourcing. Let's summarise the five golden rules:

The 5 golden rules

  1. Multiprovider decision
    Don't let your provider landscape be a product of coincidences. Remain the driving force of your multi-provider approach and not the trigger points for IT procurements that arise rather randomly!
  2. Process integration
    Try to focus on the IT processes across all involved providers from the beginning and act on several levels for process integration: Soft skills - Technology - SLAs
  3. SLAs
    Understand the SLAs as a 'bracket' of your operating model. Standardise the SLAs company-wide and demand them from the providers.
  4. Service Desk
    The Service Desk is the business card of the IT department and the key to functioning troubleshooting. Adding a QA layer in the sense of 1.5 level support at triage is an alternative worth considering.
  5. In-versus outsourcing
    You should 'think' about in-sourcing when making these considerations. With in-sourcing, internal departments become providers. And your multi-provider landscape becomes even more diverse - SLAs become OLAs.

Theory and the knowledge of how things should be is one thing - the other is the experience needed to make multi-provider sourcing a success. atrete has been active in this environment for more than 20 years and has been able to build up broad-based know-how. We advise and accompany sourcing mandates throughout the entire sourcing cycle. 

[1] E-bonding is a concept for directly linking the customer's ITSM systems with those of their service partners via a digital interface. The transmission of incident tickets, change or service requests by telephone or mail and the associated multiple entries are no longer necessary.