Software
Now Reading
BACK TO BASICS IN OUTSOURCING Part 2: How to properly build a service catalogue for an outsourcing contract?

BACK TO BASICS IN OUTSOURCING Part 2: How to properly build a service catalogue for an outsourcing contract?

CONTENT: What is the construction of an SLA agreement? What are differences between SLA and KPI? How to properly build a service catalogue for outsourcing? – please read our second article of „Back to Basics in outsourcing” series.

 

The subject of the first part of our series concerned issues, which are commonly regarded as the essence of outsourcing, i.e. a description of the quality of services delivered by an outsourcer – SLA/KPI models. As my experiences revealed, despite the fact that almost each manager associates outsourcing with SLA and KPI terms, barely anyone can properly answer the question about the differences between SLA and KPI. What is more, there is also a small number of people able not only to construct „some SLA model” for his or her contract but also to build an optimal model. Several tips how to do it can be found in my first article of our series:

Back to Basics – PART 1 – SLA

 

However, before we start to build a model of the evaluation of the services quality for an outsourcing contract, it is essential to make the first step, i.e. a precise description of „WHAT” a service provider should perform for us. Thus, we have to construct a service catalogue.

A starting point for this should be precise understanding who an addressee of services will be, as the specificity of such developed catalogue should properly reflect the specificity of service users. For example, if these are to be business users, development of a strongly technical catalogue, e.g. at the level of configuring servers or the frequency of databases tuning has no sense. On the other hand, if an addressee is the IT department, it may be improper to mention services like „the time of printing an invoice”.

So, how a properly developed catalogue of service should look like? According to its name, such document should properly catalogue/categorise (and order!) ALL services served by an outsourcer for a customer within the scope of a particular contract.

Proper categorisation of service in a catalogue is extremely crucial as it allows one to provide proper lucidity of the whole structure of services, as well as enables future managerial and financial analyses for particular areas of services delivered by an outsourcer.

Let us return to the structure of a services catalogue itself … In general, the beginning of such document includes a general introduction, terms and definitions and, optionally, a graphically presented the services structure. A further part of a catalogue includes so called „service cards”. Depending on the level of the contract complexity, there are ten-odd to several dozens of them. Each service card describes one main service and may also include so called constituent services (or sub-services).

To illustrate this issue, let us use an example of a technical service called „SAP Basis system administration”. In fact, such main service is composed of numerous sub‑services, proper realisation of which by an outsourcer, in the final effect guarantees a required quality of the main service. So, staying with our example, the service card for „ SAP Basis system administration”, should include constituent services like below:

  • Administration of technical SAP users
  • Administration of SAP mandates
  • ABAP Dumps
  • EWA
  • Installation of patches and updates
  • Background tasks
  • Printouts
  • System backup copies
  • System updating
  • Maintenance of interfaces with external systems

 

The above list is not complete. It should just show that including only the „SAS Basis system administration” statement in a contract does not guarantee that an outsourcer will perform all activities you expect. In many cases customers assume that it is obvious that an outsourcer should perform some sub-services within the scope of the main service. In such cases, they are greatly disappointed when a service provider tells them: „Of course, we administrate over SAP Basis system at the basic price but the cost of making each backup copy of the system is 500€ ”!!! Thus, in order to avoid such unpleasant situations, it is worth to devote some time to precisely note down all main services and related constituent services.

Description of each main service in a catalogue should include a proper set of attributes characteristic for it. For example, they should include:

  • service description;
  • terms of service provision;
  • parameters of service provision;
  • KPI parameters of service;
  • service overhaul;
  • service clients;
  • distribution of responsibility at service realisation.

 

Some of above attributes themselves can be quite complex and may include numerous elements. For example, “Service description” can include such constituents like:

  • service name;
  • service ID;
  • service type;
  • service category;
  • date of service launch;
  • date of service withdrawal.

 

Another essential issue that should be properly addressed in a services catalogue is a distribution of responsibility at realisation of a particular service along with its constituent services. In general, in my outsourcing activity I use RACI model (Responsible, Accountable, Consulted, Informed). In some contracts, there is used a little more complex model – RASCI (where „S” stands for Supportive).

Construction of a proper responsibility model for each service allows us to avoid future unpleasant discussions between contract parties:

  • who should do it?
  • who activates a particular service?
  • who should have been informed about a particular event?
  • with whom this issue should have been consulted?
  • who was to provide particular support at realisation?

 

The last but not least (!!!) element of a service card, which I would like to discuss are quality parameters – so called KPIs (Key Performance Indicators). Most of services defined in a service catalogue should be accompanied by particular quality parameters, which we want to be provided by an outsourcer at realisation of the agreement. Examples of such parameters are as below:

  • time of generating a report by the system;
  • time of blocking a user’s account;
  • percentage of disc space.

 

Of course, KPI parameters strongly depend on the specificity of a particular service. They may be technical in one case, while more business in other.

KPI parameters are the element of a service catalogue, which closely relates it with a whole SLA model of a contract. You can learn more about dependencies and relations between SLA and KPI from our first article of the “Back to Basics in outsourcing” series:

Back to Basics – PART 1 – SLA

 

An example of a service card is presented in the picture below:

3a. Sample service card

*) Note: the above service card is not complete and is only an example.

 

I hope that thanks to this article, when constructing your own outsourcing contracts, you will not just specify the scope of services in few sentences in a single paragraph of the main agreement but you will decide to completely describe all services rendered by an outsourcer in a service catalogue!

See you soon in the third article of „Back to Basics in outsourcing” series!

 

 

 

Author:

Piotr Rutkowski, a Managing Partner at SourceOne Advisory

For 20 years in business and 15 years of experience in outsourcing industry. Advised on outsourcing projects worth up to $100 million for many reputable customers like T-Mobile, DHL, ING Bank, HDI, Polish Television, Polish Railways, Polish Post, PZU, Polkomtel, PKN Orlen, Energa, Raben, Pinebridge Investments, AmRest.

Laureate of many outsourcing industry awards. Author of numerous publications in the field of outsourcing and sourcing. Lecturer on outsourcing, sourcing strategies and procurement at Warsaw School of Economics and Kozminski University.

In 2006 created and has since managed his own independent consulting company SourceOne Advisory (www.sourceone.pl/en/), specializing in outsourcing consultancy and supporting IT procurement processes.