Zum Thema «Systems» stellte Bert Rotmans sein – wie er es nannte – aktuelles «Hobby Projekt» vor. Darin untersucht er, welche Inhalte gemäss ITIL® v3 das geforderte Service Knowledge Management System haben sollte. Der Ausgangspunkt seiner Arbeit sind alle Dokumente und Unterlagen, welche in den 1000 Seiten des Standardwerks zum Thema IT Service Management, der IT Service Management Library (ITIL), gefordert werden. In einem ersten Schritt wurden hier alle Dokumente in den fünf Büchern der Library erfasst und katalogisiert. Des weiteren wurden alle Informationselemente erfasst, die zu jedem Dokument benannt wurden.
Das sich ergebende Bild zeigt bereits an dieser Stelle, dass es viele Schnittstellen, Überschneidungen und Redundanzen zwischen den einzelnen Dokumenten gibt. Des weiteren kann man davon ausgehen, dass nur sehr wenige Unternehmen in der Lage sein werden, die schiere Anzahl von Dokumenten und Unterlagen zu erstellen, geschweige denn auf einem aktuellen Stand zu halten.
Zurzeit werden die Überschneidungen und Widersprüche zwischen den einzelnen Quellen in der Original-Dokumentation eliminiert, so dass ein sauberes Datenmodell erstellt werden kann, das man dann mittelfristig in einer Datenbank abbilden kann.
Neben den Arbeiten, welche Informationen in der SKMS zu finden sein sollen, stellte Bert Rotmans auch dar, wie die Navigation zu den jeweiligen Informationen in seiner zukünftigen Lösung aussehen sollte. Ziel ist es, mit nur drei Klicks die gewünschte Information zu finden. Dieser Ansatz bedingt aber auch, dass entsprechende Klassifikationen/Kategorisierungen vorliegen und jede Information, die in dem System abgelegt ist, entsprechend verschlagwortet ist.
Auf das Ergebnis dieses Projektes kann man gespannt sein. Bert Rotmans plant, bis Ende 2011 seine Ergebnisse in einem Buch zu dokumentieren und einen Prototypen des SKMS zu programmieren, welcher dann als Referenz genutzt werden kann.
Im «Service»-Teil des Abends erfuhren die Teilnehmer, was Architekten mit denjenigen, die modernes IT Service Management betreiben, gemeinsam haben. Paul G. Huppertz zeigte ganz eindrücklich, welche Vorraussetzungen geschaffen werden mussten, um den Kölner Dom zu bauen und wie uns dieses Wissen im Design und Umgang mit IT Services helfen kann. So muss man eine Architektur separat vom IT Service entwerfen, die aber mit diesem sehr eng zu verweben ist. Die starke Abhängigkeit voneinander gilt es zu beachten, da man die Services sonst nicht so erbringen kann, dass sich der Nutzen für den Service Empfänger einstellt.
Mit seinen Überlegungen basiert Paul G. Huppertz auf einer recht einfachen und eingängigen Definition, was ein Service ist. Für ihn ist ein Service ein Bündel von Nutzen für den Service Empfänger. Dieser Definition folgend hat er zwölf Attribute abgeleitet, welche einen Service beschreiben. Anhand von praktischen Bespielen zeigte er, wie diese zu beschreiben sind und wie diese Beschreibung anschliessend die Architektur des Service-erbringenden IT Systems beeinflusst.
An den Beispielen konnte man auch gut erkennen, dass der Service das Bindeglied zwischen dem Geschäftsprozess und den Service-liefernden IT Systemen ist. Aus dieser Idee leitet sich auch die Aussage ab, dass ITIL eine Anleitung ist, wie man IT Systeme «ordentlich» betreibt, aber nicht, wie man Services wirklich erbringt. Gemäss Huppertz existiert bis heute keine zusammenhängende Service/Dienstleistungs-Theorie. Diese gilt es noch zu entwickeln und wissenschaftlich zu beschreiben. Zu jedem Service gehört ein klares Service Konzept, welches sich aus den Komponenten Spezifikation (Was ist der Service?), Komponenten (Welche Systemkomponenten braucht es?) und dem Drehbuch (Wie wird der Service mit den Komponenten erbracht?) zusammensetzt.
Jede IT Organisation, so Huppertz, muss sich einem modernen Triathlon stellen. Dieser besteht aus:
• Sicherstellen der notwendigen Service-Erbringungsbereitschaft
• Sicherstellen einer ausreichenden Erbringungskapazität
• Sicherstellen, dass die Services erbracht werden, und zwar so, dass diese den entsprechenden Nutzen liefern.