IT Service Management und Web 2.0

Der Trend zu Web-2.0-Applikationen und -Prozessen ist heute kaum mehr aufzuhalten. Immer mehr Firmen nehmen die Ideen auf und fangen an, Web 2.0 in Ihre Prozesskette und Online-Umgebung zu integrieren. Wenn man streng nach der Web-2.0-Lehre arbeitet, stellen sich allerdings durchaus interessante Anforderungen für das tägliche Arbeiten mit diesen Applikationen dar – insbesondere im Betrieb und im gesamten Bereich IT Service Management.

Unter dem Fachbegriff Web 2.0 versteht man im allgemeinen Web-Technologien, die eine andere Art und Weise der Darstellung und Interaktion mit dem Kunden bzw. mit den Internet-Nutzern darstellen. Anwender generieren die Inhalte, treten über die Plattform untereinander in Kontakt und die Applikation, das Netz, wird als soziales Netzwerk wahrgenommen. Die Darstellung und die Applikation selbst treten in den Hintergrund, Inhalt und Kontakt in den Vordergrund.

Mit einher geht die Idee des ‘always beta’, das man bei zahlreichen bekannten Firmen in der jüngsten Vergangenheit permanent beobachten konnte. Applikationen werden frühzeitig auf die Kunden losgelassen und entwickeln sich dann rapide mit den Benutzern weiter. Dies führt zu einem gewollten bzw. gelebten Release-Zyklus von teilweise unter 30 Minuten.

Was aber bedeutet dieser Trend für IT Service Management und den operativen Betrieb? Können Rahmenwerke wie ITIL uns ausreichend Freiräume schaffen, um diese ‘always beta’- und ’30 min Releases’-Ansätze zu unterstützen?

Die Perspektive über ITIL

Unter IT Service Management versteht man im allgemeinen sämtliche Maßnahmen, Regelwerke und Methoden, um die Geschäftsprozesse eines Unternehmens durch die darunter liegende IT-Organisation bestmöglich zu unterstützen. ITIL selbst ist ein mittlerweile etabliertes Rahmenwerk für IT Service Management, welches im Rahmen des britischen Office of Government Commerce (OGC) derzeit weiterentwickelt wird.

Sowohl ‘always beta’ als Dogma für Web2.0 als auch damit einhergehend ein ’30 min Releases’-Takt müssen unweigerlich zu Änderungen in der Organisationsstruktur und den dazugehörigen Prozessen führen.

Aus Sicht von ITIL sind davon insbesondere Change-, Configuration- und Release Management betroffen. Auswirkungen auf Incident Management, Problem Management und Service-Delivery-Prozessen sind aber ebenfalls zu verzeichnen. Im weiteren werden wir uns bewusst auf diese Aspekte beschränken, obwohl noch eine Vielzahl an weiteren Aspekten dieses Thema betreffen, wie zum Beispiel:
· ITSM Tools mit Web-2.0-Unterstützung, insbesondere bei Disziplinen mit großen Schnittstellen zu Anwendern oder IT-fremden Bereichen, also Interdisziplinarität und Interaktion mit anderen Suiten.
·  Einsatz von Web-2.0-Technologien für ITSM (Known Error DB auf Wiki-Basis, RSS Feeds für Forward Schedule of Changes, etc.).
· Problematik der Inkonsistenzen durch flüchtige Applikationen, Daten und Verknüpfungen.
· Abdeckung des Daten-Gedanken (Daten statt Service) im ITSM
· Und vieles mehr.

Betrachtet man die Aufgabe des Change Managements, so lässt sich feststellen, dass ein Change-Rhytmus von 30 Minuten zu massiven Problemen in den Standard-Prozessen von ITIL führen kann. Einerseits ist es im Normalfall nicht üblich, in dieser Taktung zu fahren, andererseits müssen dafür vollkommen neue Wege/Gremien gefunden werden. Ein CAB alle 30 Minuten macht weder Sinn noch ist es finanziell und organisatorisch abbildbar. Hierfür eignen sich einerseits vorautorisierte generelle Änderungen, andererseits auch die Zusammenfassung des CAB und dazugehörigen Prozesses auf eine Person, die dafür auch dann die alleinige Verantwortung zu tragen hat.

Dieselbe Person hat auch (mit geänderter Rolle) sicherzustellen, dass sämtliche Änderungen der Release-Stände in der CMDB (Configuration Management Database) korrekt und vollständig eingetragen sind. Die Nachvollziehbarkeit bei einem Service, der so häufigen Release-Wechseln ausgesetzt wird, ist dringendst aufrecht zu erhalten.

Unabhängig von den Verfahren für die Entwicklung der neuen Releases – sei es nach agilen oder klassischen Ansätzen oder nach Extreme Programming, wobei das Wasserfallmodell bei 30-Minuten-Releases durchaus spannend darzustellen sein wird – stellt sich für das Release-Management die Herausforderung als sehr markant dar.

Eine der Aufgaben des Release-Management ist der Schutz der Produktivumgebung durch Formalismen und Verfahren. Dies muss auch bei dieser engen Taktung sichergestellt werden. Automatisierte Testumgebungen, automatisierte Rollout-Verfahren etc. stellen einen maßgeblichen Teil der Aufgaben sicher, können aber immer nur als vom Menschen ausgelöst betrachtet werden. Im Umkehrschluss heißt dies, dass für den professionellen Einsatz von Web-2.0-Applikationen, oder besser von Web-2.0-Services eine Unmenge an Vorarbeiten getroffen werden muss, um das volle Potenzial ausschöpfen zu können. Gerade für Telcos und ISPs ist diese Herausforderung aus heutiger Sicht nicht zu unterschätzen.

Datenkonsistenz bei unbekannten Datenquellen?

Incident Management ist insofern betroffen, als dass mit einer 30-Minuten-Taktung eine ungleich höhere Wahrscheinlichkeit an Störungen bzw. unerwünschten Verhaltens auftreten wird als gewohnt. Ob Call Center bzw. Service Desk wie im gewohnten (Endkunden-)Sinne überhaupt für Web-2.0-Unternehmen bzw. -Bereiche notwendig sind ist fraglich, da ja die Applikation in den Hintergrund treten sollte und die Daten bzw. Interaktion in den Vordergrund – zumindest teilweise. Heute agierende Web-2.0-Unternehmen verzichten bewusst auf diese Endkundeneinrichtungen und haben nur mehr ein internes, hocheffizientes Incident Management etabliert.

Auch die klassischen Themen Service Level Management, Capacity Management und Security Management sind davon betroffen. Insbesondere dann, wenn das User-Verhalten nicht mehr zu 100 Prozent durch die Applikation und das Marketing gesteuert werden kann und durch die Vernetzung der einzelnen Dienste untereinander eine Abhängigkeit und Komplexität entstehen kann, die mit heutigen Mitteln und Tools nur sehr schwer abbildbar und auch berechenbar ist und bleibt.

Security Management muss eindeutig sicherstellen, dass die Integrität der Daten gewährleistet ist. Was aber, wenn die Datenquelle selbst nicht bekannt ist? Wie kann mit einem allgemein unbekannten Verfasser die Integrität und Vertrauenswürdigkeit festgestellt werden? Viele Herausforderungen kommen hier auf das klassische ITSM zu, die bedacht sein sollen.

Web 2.0 bietet viele Vorteile und die Evolution des Netzes, das soziale Netzwerk, ist absolut begrüßenswert. Die Verantwortlichen auf Seiten der IT müssen allerdings frühzeitig Methoden und Prozesse definieren, um vollständig auf den Zug Web 2.0 aufspringen zu können. Dies muss auch glaubhaft dem Management und dem Business gegenüber praktiziert werden. Web 2.0 ist nicht eine weitere Software, eine weitere zu verwendende Bibliothek. Web 2.0 ist eine Denkweise und Interaktion, die über die unternehmensweiten ITSM-Rahmenwerke frühzeitig abzustimmen ist. Nur so lässt sich das Spannungsfeld zwischen ‘always beta’ und kontinuierlichen Service-Leistungen im Sinne des Business überbrücken.