Ein Dirigent dirigiert ein Orchester.

Ist SIAM die Lösung?

Die Diskussion zum Thema Service Integration and Management (SIAM) wird recht kontrovers geführt. Manch einer fragt sich, ob SIAM eigentlich überhaupt über ITIL hinausgeht oder ob hier von der Beraterbranche lediglich einmal wieder eine neue Sau durchs Dorf getrieben wird (vgl. z.B. https://www.internationalbestpractice.com/Blog/?DI=644675).

Die klassische ITIL-Welt

Es ist in diesem Zusammenhang interessant sich kurz zu vergegenwärtigen vor welchem Hintergrund ITIL damals eigentlich entstanden ist und welche Probleme mit dem ITIL-Ansatz gelöst worden sind: In der Zeit um 1990 wurde die IT-Welt beherrscht von Systemmanagern einerseits und Software-Entwicklern andererseits. Die Systemmanager waren dafür verantwortlich, dass ‚ihr‘ Server ‚lief‘. Solange die Software, die auf dem Server installiert war keine Systemabstürze oder ernsthafte Performanceprobleme verursachte, interessierte sich der Systemverwalter für die Applikationen, die sein Server unterstützte kaum. Gab es Probleme, wurde die Software deaktiviert.

Der Software-Entwickler hingegen interessierte sich für ‚seine‘ Software in der Regel nur während der Entwicklungsphase. Nach der Abnahme der Software wollte er mit Problemen, die diese Software vielleicht in der Praxis machte, typischerweise nicht mehr konfrontiert werden, da er inzwischen in neue Projekte abgetaucht war. Fehlermeldungen kommentierte er meist lapidar „Das hat eigentlich immer funktioniert!“ oder „Sicher ein Systemproblem!“ Diese Konstellation hatte zur Folge, dass dem Anwender für Fragen oder Probleme eigentlich kein Ansprechpartner zur Seite stand und dass es keinen ‚Serviceverantwortlichen‘ gab.

Neue Herausforderungen für das Servicemanagement

Diese Probleme sind längst schon Geschichte. Selbstverständlich gibt es in jeder IT-Organisation inzwischen ein Service Desk als zentrale Anlaufstelle für die Anwender, Changemanagement-Prozesse zur kontrollierten Abwicklung von Serviceanpassungen, eine CMDB zur Verwaltung der IT-Systeme, usw. Die meisten IT-Organisationen sind inzwischen auch ‚serviceorientiert‘ aufgestellt in dem Sinn, dass jede Stelle in der Servicekette sich als Serviceprovider für einen nachgelagerten Kunden in der Supply-Chain versteht. Die Erweiterung der Servicekette um Glieder die externen Organisationen angehören, d.h. ein ‚Multi-Sourcing‘, könnte man meinen ist daher keine prinzipiell neue Herausforderung.

Auch bisher gab es ja schon unterschiedliche Serviceprovider, die bei der Serviceproduktion zusammenwirkten, ob intern oder extern, wo ist denn da der große Unterschied? Zwar muss vermieden werden, dass Principal-Agent-Probleme nicht überhandnehmen und dass der Dienstleister einen nicht ‚über den Tisch‘ zieht. Aber mit einem vertrauensbasierten Ansatz und dem Wissen, dass man nur gemeinsam erfolgreich sein kann, müsste das doch zu schaffen sein, oder?

Lösungsansätze in Sicht

Leider ist es nicht ganz so einfach. Das fundamental Neue ist nicht, dass Service-Provider nun unterschiedlichen Organisationen angehören. Das Neue ist viel mehr, dass diese Provider jeweils viele unterschiedliche Kunden bedienen und deswegen ihre Services nicht auf einen Kunden ausrichten, sondern nur standardisiert erbringen können. Hier unterscheidet sich die IT-Welt auch von der oft als Beispiel referenzierten Automobilbranche, denn die Zahl der Kunden eines IT-Service-Providers wie amazon oder Microsoft ist weit größer als die Zahl der Kunden eines Zulieferers im Automobilbereich.

Dies bedeutet konkret z.B., dass der Service-Provider

  • Aktivitäten zur Störungsbehebung nicht im Incidentmanagement-System des Kunden dokumentieren wird
  • Änderungen an Systemkomponenten nicht über die kundenseitigen Change-Prozesse kontrollieren lassen und nicht in der Kunden-CMDB pflegen wird
  • usw.

Erschwert wird die Situation dadurch, dass die Serviceprovider zwar bestrebt sind, Services standardisiert, automatisiert und industrialisiert zu erbringen, dass es aber keine Standards hierfür gibt, denn eine ‚DIN-Norm für IT-Services‘ gibt es nicht und ist auch nicht in Sicht.

Die bisherigen Ansätze zum Thema SIAM sind noch recht generisch und umreißen eher das Problem, als dass Sie bereits eine Lösung darstellen würden. Klar ist jedoch: Finden Unternehmen keine Lösung für den Problembereich, so sind sie im Cloud-Zeitalter bald wieder da, wo alles begann: Der IaaS-Dienstleister erklärt, es handle sich um ein reines Softwareproblem, der SaaS-Anbieter hat für Fragen nur eine automatische Hotline-Nr. geschaltet,….

SIAM ist also (noch) nicht die Lösung. Die Entwicklung dazu ist jedoch spannend und wir werden das Thema weiter verfolgen.