The Power of the Service Catalogue

If you look at the agenda of recent IT Service Management events, you might notice that the service catalogue has become a very popular discussion topic and it’s obvious that more and more IT organizations are seeking to implement the often so-called ‘missing link between IT and business’.  However, having participated in some of these discussions, I was surprised how often they were limited to a nicely looking service brochure or in best case a shopping cart in place. One reason for this might be the misleading word Catalogue, which makes people automatically think of a shopping cart as the only purpose (this is why I actually prefer the term Service Map). In my opinion another reason is ironically the ITIL Best Practice framework itself, which was so far not able to link the IT Service Management processes consequently into the service catalogue, – which is in fact the ‘core’ of what you provide to your customers. Service Catalogue Management and the resulting catalogue is not just another ITSM process and process result which needs to be ‘Under Control’, it is in fact the backbone of the whole Service Lifecycle – together with the Service Portfolio Management. Please allow me to make it clear with some examples:

  • The Service Catalogue with it’s elements is the base to determine what are the actual full costs of your services and therefore part of any service ROI calculation
  • It is a prerequisite for negotiating and agreeing service levels (warranty) with your customer
  • Without a service catalogue you will never understand what happens to your business if certain service components fail
  • Going down to IT Operations the service catalogue will help you to categorize your Incidents and Service Requests in a meaningful way and handle them properly

I would like to highlight the role of the Service Catalogue along the IT Service Lifecycle as follows.

Service Catalogue Management – A Wrap Up

Let’s first do a short wrap-up of some core definitions around Service Catalogue Management (Please skip this section if you are familiar with it). According to Best Practice, the purpose of Service Catalogue Management is to provide and maintain a single source of consistent information on all operational services and those being prepared to be run operationally, and to ensure that it is widely available to those who are authorized to access it. Logically, it is embedded into the more strategic process Service Portfolio Management, which has a wider focus by deciding which services you actually want to offer as an IT service provider and which not. The result out of the Service Catalogue Management process is the Service Catalogue, which is basically divided into two connected layers:

  • Customer-facing services: IT services that are seen by the customer. These are typically services that support the customer’s business processes, directly facilitating some outcome desired by the customer. An example for this is an SAP HR application service, which supports the HR process of a company.
    Always keep in mind: A service is a means of delivering value to customers by facilitating the outcome customers want to achieve, without the ownership of costs and risks.
  • Supporting services: (sometimes also called ‘service components’ or ‘enabling services’): IT services that support or ‘underpin’ the customer-facing services. These are typically invisible to the customer, but essential for the delivery of customer-facing IT services. An example for this could be the network, which is needed in order for the customer to access the email-service (customer facing). This layer usually can be linked further down to other CI, in our example routers, switches etc.

The  Graph below nicely illustrates the link between the business processes, customer-facing and supporting services:

Service Catalogue Structure

What to use it for?

In order to answer the question what  use is the service catalogue, it is important to put it into context of other ITSM processes along the service lifecycle. You can get some interesting ideas on this  out of my first blogs (‘Don’t forget the Service Lifecycle’). Basically the ITSM processes give you some guidance on how to manage the IT Services, but you should link them into the actual services (which in turn is something coming out of the service catalogue). This is also why it is the backbone of the Service Lifecycle.  I will to go through the most prominent examples as follows:

Service Level Management (SLM): By agreeing, securing, monitoring and controlling service level agreements (SLAs), the SLM process is a key player around ensuring service quality. What is often not understood is that SLM is just covering the warranty-aspects of a service, meaning on how good they are provided (typically this will be the service availability, e.g. 99.9991%). The definition what is delivered is always defined through the services that have found their way to the service catalogue through service portfolio management.

Incident Management: If it comes to the point that an IT Service is interrupted, the Incident Management process steps in to restore normal service operation as fast as possible. The essential steps of this process include having an understanding of the incident category and priority of each incident.  “Which service is affected by the incident?” is here the leading question, and of course you can only answer this if you understand the services which come out of the catalogue. In addition, the critical aspect of a service, which also should be included in the service catalogue, is the main source for the proper prioritization of the incident.

Financial Management: Identifying and quantifying IT cost drivers such as infrastructure elements and humans resources is fairly easy, but has only limited informative value. What is much more interesting from a service-perspective is to determine what are the actual costs and value of your services. This is where the service catalogue comes into place. It shows the link from the actual customer-facing service to IT service-components down to each infrastructure CI. This is how you are able to recomposition your costs into true service costs.

Request Fulfillment: The service catalogue plays a central role in the Request Fulfillment process. Each request to the Service Desk should have a clear link to a service that is offered to the end user (->Service Catalogue). This becomes especially important if you automate your Request Fulfillment process through a self-service portal. The end user can order the service directly out of the service catalogue, each one with clear service levels attached and automatically linked to the underlying service components (which)

Event Management: The most critical success factor in Event Management is to have the right rules in place to separate the events that have a meaning for the management of the IT infrastructure from the events that have just informational character. By having an understanding of the services and how they are made up from an infrastructure perspective (something you get out of the service catalogue), you are definitely able to measure the right events and set the right thresholds.

Availability Management: Similar as in Event Management, you can look at the service catalogue from an availability influence perspective. E.g. which are the service components that make up the e-mail service and what happens if they fail? Modern availability dashboards are based on a service catalogue, because they show the availability of the IT Service by linking them end-to-end from business view (customer facing) down to IT Infrastructure.

IT Service Continuity Management (ITSCM): In order to manage the risks that can seriously impact IT services (which is the main goal of ITSCM), you first need to have an understanding which IT Services are critical to the business (Business Impact Analysis). The Service Catalogue is the main source for this, because it shows the link from IT Services to Business Processes.

3 Kommentare zu «The Power of the Service Catalogue»

  1. Kernfrage – die im Blog nicht beantwortet wurde – ist die Auseinandersetzung mit dem Service-Begriff. Die Referenz auf die krude OGC-Formulierung ist da wenig hilfreich.

    Ein Service ist und bleibt etwas Einmaliges, denn es ist ein Dienst, der bei Bedarf bzw. nach Vereinbarung abgerufen und sofort erbracht wird. Beispiele hierzu wären:
    – Konzertbesuch
    – Friseurbesuch (1x waschen, schneiden, fönen, stylen)
    – Restaurantbesuch (= Catering-Service)

    Ein Service ist auch nicht “managebar”, wie erwähnt, er ist schlicht erbringbar. Die gute-alte Binärlogik kann hier hilfreich Anwendung finden: JA oder NEIN (1 oder 0) oder Service-Versprechen, Service-Versagung.

    Schaut man auf die Prozesse des Empfehlungs-Frameworks, dann fällt auf, dass einige Prozesse im Zusammenhang mit der Portfolioerstellung schon relevant sind: Capacity, Availability, Continuity, Finance Management.

    Request Fulfillment oder gar Incident sind aus der Sicht des Service Managements irrrelevant, denn sie wären im Bereich des System Managements denkbar.

    Warum?

    Ein nicht gelieferter, unterbrochener Service wurde nicht erbracht, also dem Konsumenten versagt (Konzert findet nicht statt, weil …). Das Incident Management (Störungsbehebung) dient nun zur Schadensbegrenzung, that’s it. Möglichst schnell, damit die Service-Erbringungsbereitschaft wieder hergestellt und der Konsument einen weiteren Service-Abruf tätigen kann. Aber der Schaden durch den nicht gelieferten Service hat der Konsument, egal wie gut oder schlecht die Behebung der Störung organisiert ist.

    Die Anknüpfung an Geschäftsprozesse ist naheliegend, denn die “Consumer-facing” Services sind die altbekannten Business Services. Und eben daraus sollte ein Portfolio bestehen und in der Anwendersprache auch im Katalog ausformuliert sein.

    Die Unterstützungsservices werden als Service-Beiträge IT-intern oder per Ausschreibung extern vergeben/beschrieben. Ich kann mit der Strukturabbildung daher nur wenig anfangen.

    Vielleicht ergeben sich auf dem Blog noch interessante Antwortden, die das Gesamtbild eines Service Katalogs schärfen bzw. vervollständigen. Bin & bleibe gespannt.

    Viele Grüße
    Peter Bergmann

    1. Guten Tag Herr Bergmann,
      VIelen Dank für Ihr Feedback und dass Sie sich für meinen Blogbeitrag interessieren.
      Die Kernfrage dieses Artikels ist nicht die Auseinandersetzung mit dem Service-Begriff, dazu gibt es bereits haufenweise spannende Fachbeiträge und teils uferlose Forumsdiskussionen. Die OGC-Kurzdefinition des Service-Begriffs ist sicherlich nicht abschliessend (kann sie auch nicht) und Ihre Ergänzungen diesbezüglich sind ohne Zweifel alle korrekt (die ausführlicheren OGC Definition widerspricht diesen nota bene auch nicht). Ich habe an dieser Stelle bewusst auf die Vertiefung verzichtet (zudem denke ich hat die ITSM Community zum Servicebegriff inzwischen ein ausreichendes Verständnis), nicht zuletzt weil es den Weg zur eigentlichen Kernbotschaft dieses Blogbeitrags versperrt hätte, nämlich dass der oft missverstandene Service Katalog (besser: Service Map) als Instrument ausserordentlich wichtig ist, um die Services im Kontext des Kunden und der unterliegenden Supporting Services und der gesamten Infrastruktur besser zu verstehen und weiterzuentwickeln und die ITSM Prozesse konsequent nach diesen Services auszurichten (u.a. AUCH Incident Mgmt und die ganzen anderen Prozess-Beispiele in meinem Beitrag).
      Zu Ihrer Aussage, dass ein Service nicht ‘managebar’ sondern nur erbringbar ist: Ich verstehe, was Sie damit meinen und rein begriffstechnisch haben sie damit auch Recht, aber streng genommen müsste demnach der Begriff ‘Service-Management’ und all die Bücher mit dem Begriff ‘Managing Services’ im Titel aus dem Verkehr gezogen werden… Das kann es wohl nicht sein;-) Ich bin sicher, Sie verstehen jetzt, dass es bei diesem Begriff einfach nur darum geht, wie der Service-Lifecylce (D.h. von der Strategie bis hin zur Erbringung) erfolgreich gemanaged wird, d.h. mit all die ITSM-Prozesse welche wir ja von ITIL her schon lange kennen. Aber vielen Dank aber nochmals für Ihr feedback, solche Diskussionen sind wichtig/spannend und im nächsten Blog wird es sicher noch mehr davon geben, dann geht es nämlich um das Design und die Implementierung des Service Katalogs (der schwierige Teil).
      Freundliche Grüsse
      Alex Lichtenberger

  2. Grüß Gott Herr Lichtenberger,

    herzlichen Dank für Ihre aufschlussreiche Antwort.

    Ich sehe es identisch, dass ein Service Katalog ein wichtiges Instrument für das Service-Management. Der Begriff gehört samt Literatur nicht abgeschafft, sondern ENDLICH, ENDLICH richtig gestellt: Service-Management ist mit Dienst-Leistung zu interpretieren, so wie Service als Dienst im Kontext verstanden werden sollte.

    Da ein Service-Angebot nun einmal aus Services besteht, lohnt es sich, diesen klar zu verstehen und zu benennen. Sogar die aufschlussreichen Gespräche im Service-Circle im Oktober mit Prof. Dr. Bruhn, Prof. Dr. Hadwich, Prof. Dr. Voeth ergaben branchenübergreifend ein uneinheitliches und nicht ausgereiftes Bild zum Service-Begriff.

    Service Management ist –soweit ich die IT-Szene kenne- bisher auffällig oft eigenwillig verstanden worden. Zuallererst wird der Incident Prozess (im Allgemeinen auch als Störungsbeseitigung ausgelegt) genannt und im Zusammenhang mit Services gebracht. In Wirklichkeit ist das ein Prozess zur Schadensbegrenzung und zur Wiederherstellung der Service-Bereitschaft.

    Vergleichen wir: ein Taxi-Service: wir sitzen im Taxi auf der Fahrt von A nach B. Das Fahrzeug geht kaputt. Der Taxiunternehmer versucht nun 1) schnellstens ein Ersatzfahrzeug dorthin zu beordern und 2) das Auto für den Wiedereinsatz reparieren zu lassen. Aber: die laufende Service-Erbringung ist beeinträchtigt (Verzögerung bis das Ersatzauto da ist) bzw. sogar versagt (Aussteigen, anderweitig weiterkommen).

    Ich bleib dabei, dass die in der v2 des Frameworks beschriebenen Support-Prozesse zur Bereitstellung bzw. zum Erhalt der Service-Bereitschaft dienen, aber nicht mehr. Solange kein Anwender mit einem Service-Abruf (SEND; COMMIT, SUBMIT, STORE, SEARCH – Button) die Erbringung anstößt „idelt“ die Infrastruktur vor sich her. (Vergleichbar: Sie veranstalten ein Konzert und niemand kommt; die Taxis stehen am Stand und kein Fahrgast will transportiert werden; die Gaststätte hat geöffnet und niemanden durstet oder hungert es).

    Und weil „Service“ und „Service Management“ in der IT falsch interpretiert werden, schauen die Service-Kataloge heute aus, wie abgehalfterte Produktverzeichnisse, entnommen aus einer CMDB und „angehübschelt“ Tagesaktivitäten (Bsp. erst kürzlich gesehen: Bereitstellung von x GB WORMS für Archivierungszwecke). Das ist Capacity Management und selbstverständlich! Warum wird das als Service in einem Katalog für Kunden angeboten?

    Eine Service-Map kommt richtigerweise ins Spiel, wenn wir Service-Erbringungsketten konzipieren. Da ein Service aus Einzelbeiträgen besteht und diese wahlweise intern oder extern erbracht werden können, kommt einer Service Map eine wirkliche Bedeutung zu. Sie ist ein Instrument eines Providers, seine Supplier zu steuern und die Einzelleistungen zu einem abrufbaren Service zusammenzutragen.

    Meine Erfahrungen zeigen, die bisher erarbeiteten Service Kataloge von der Business Site eher belächelt werden. Ich behaupte sogar, dass es für diese Art von Service Management von den Fachbereichen keine wirkliche Nachfrage gibt.

    Wenn es uns IT-Treibenden endlich gelingt, so genannte Business Support Services zu spezifizieren, werden sich Fachbereiche (Kunden bis zum Endanwender) und IT annähern. Die interne IT-Organisation muss zum Service-Provider werden und die Kunden nicht mit IT-Denglish behelligen. Auch die Mutmaßung von Supporting Services führt in die Irre, denn es interessiert keinen Kunden, wie, mit welcher Unterstützung, wann und wo die IT die Infrastrukturkomponenten betreibt, wartet und aktualisiert.

    Womit wir beim „managen von Services“ sind. Die IT-Sprachakrobaten haben schon viele Stielblüten kreiert, aber diese gehört wirklich und endgültig vom Markt genommen.

    Zum Hintergrund: Ich habe bereits im letzten Jahrtausend die ersten Kunden betreut, SLAs als Geschäftsgrundlage angesehen und ein Customer Care Center unterhalten (Geschäftsgegenstand war übrigens SAP-Outsourcing im eigenen RZ). Seitdem beschäftige ich mich mit Service Management, in internen bzw. externen Konstellationen. Etwas plakativ: Wenn wir ITIL® so weiter interpretieren wendet sich die Nachfrage noch stärker und von selbst ab.

Kommentar verfassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert