Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

10.02.2005

Keine Zeit für Itil, ohne Itil keine Zeit

Eckhard Klockhaus
Pragmatisch angegangen, muss die Implementierung von Itil-Prozessen nicht zum zeit- und kostenaufwändigen Mammutprojekt geraten.

Heute müssen IT-Abteilungen mit kleinerem Budget mehr leisten - wie soll das gehen? Die IT Infrastructure Library (Itil) gilt zwar als wertvolle Orientierungshilfe, um effiziente IT-Services zu schaffen. Deren Itil-gemäße Einführung, so das Vorurteil, sei aber langwierig und teuer.

Eine praxisorientierte Betrachtung des "Quasi-Standards" Itil eröffnet jedoch Alternativen zum gefürchteten "Mammutprojekt ohne Erfolgsgarantie". So lässt sich der Gefahr, dass Projekte zur Prozessoptimierung bereits im theoretischen Ansatz überstrapaziert werden und die Mitarbeiter an der Basis sich abwenden, durch Vereinfachung vorbauen.

Die Ausgangssituation

Eine Klassifizierung derjenigen Anforderungen, die Prozessveränderungen nach sich ziehen, ist nicht schwer: Im Grunde gilt es, Leistungen inhaltlich zu verbessern, vorhandene Kapazitäten optimal zu nutzen und Kosten transparent zu machen.

Bei den meisten Firmen passen die Anforderungen im Wesentlichen in dieses Raster. Für die damit einhergehenden Modifikationen stehen allerdings im Gros der Fälle weder Budget noch Personal zur Verfügung. Daher kann ein solches Projekt nur dann gelingen, wenn die Änderungen quasi im Alltag entstehen. Die einzig praktikable Lösung besteht aus vielen kleinen, pragmatischen Schritten zwischen Planung und Umsetzung. Dabei geht es weder darum, alle Abläufe gleichermaßen und vollständig einzubinden, noch ist es das Ziel, sämtliche Prozessvorgaben auf einen Schlag zu erfüllen.

Am Anfang gilt es, Leistungen in die Kategorien "Störungsbehebung", "Änderungen" und "Wartung" einzuordnen. Auf diese Weise lässt sich ein Prioritätensystem aufbauen und die gegenüber den Anwendern angestrebte Verbindlichkeit der Leistungen etablieren. Beispielsweise sind Störungsmeldungen dringlicher als Änderungsanforderungen der Fachabteilungen. Für eine solche Orientierung benötigen die IT-Mitarbeiter kein zeitaufwändiges Training - erste Verbesserungen lassen sich sehr schnell vornehmen.

So trivial diese Methode auch klingen mag: Sie ist Grundlage dafür, dass alle folgenden Prozesse - sei es zur Erhöhung der Kostentransparenz, zur Verfügbarkeits- und Kapazitätsplanung oder für die oft aus dem Ruder gelaufene Planungssicherheit im Hinblick auf die Ressourcen - eingeleitet werden können.

Prioritäten festlegen

In einem nächsten Schritt lassen sich die Prozesse gemäß Itil nach Prioritäten kategorisieren. Steht dabei die Verbesserung des Supports im Vordergrund, ist eine weitere Gliederung der Störungen in "Incident"- und "Problem"-Management erforderlich. So erfordert beispielsweise nicht jede Störung eine Ursachenanalyse - in vielen Fällen ist ein einfaches Wiederherstellen der letzten bekannten, lauffähigen Systemumgebung ausreichend. Besteht jedoch die Gefahr, dass sich die Störung ausdehnt, oder tritt sie, real oder latent, mehrfach auf, ist sie als Problem einzustufen und entsprechend zu behandeln.

Auch in der Systemkonfiguration lassen sich häufig schon durch simple Veränderungen die Leistung deutlich erhöhen sowie Nachbearbeitung und Ressourcenauslastung reduzieren. Grundsätzlich ist es ratsam, die jeweiligen Rollen bei der Einleitung, Freigabe, Umsetzung und Abnahme von Änderungen genau zu spezifizieren. Denn Probleme bei der Betriebsübergabe nach Modifikationen sind nicht selten auf die schlechte Zusammenarbeit zwischen "Änderungsverantwortlichen" in der Systemtechnik und denjenigen, die für Betrieb und Störungsbehebungen zuständig sind, sprich: dem First- und Second-Level-Support, zurückzuführen. Eine einfache Darstellung mit "abnehmenden Verantwortungen" und klaren Angaben zur Kommunikation und Dokumentation der Änderungen erhöht die Erfolgschancen.

Hier schließt sich der Kreis zwischen "Change"-, "Release"- und "Incident"-Management. Die Wiederherstellung von Funktionen und dem jeweiligen Systemstatus erfordert, dass diese auch bekannt und verfügbar sind. Zwar ist das dafür zuständige "Configuration"-Management in den Unternehmen zumindest ansatzweise etabliert, meist aber weder vollständig noch aussagekräftig und daher unsicher. Die Konsolidierung vorhandener Systembeschreibungen sowie die Katalogisierung der einzelnen Configuration-Items gerät nicht selten zu einer umfangreichen Aufräumaktion von Dateien und Daten - eine zeitaufwändige Aufgabe, die jedoch nicht eilt und keine hohen fachlichen Anforderungen stellt.

IT-Abteilung als Abnahmeinstanz

Dokumentation und Steuerung der Informationen lassen sich auf zweierlei Wegen vereinfachen: Zum einen kann die IT als interne Abnahmestelle für Änderungen positioniert werden. So werden viele Modifikationen - etwa im Bereich der Mobilgeräte - direkt von den Fachabteilungen erledigt. Endlosdiskussionen um die Schuldfrage bei fehlerhaften Systemänderungen lassen sich abkürzen, wenn die IT als Abnahmeinstanz fungiert und den letzten abgenommenen Zustand in den Service-Level-Agreements (SLAs) mit garantierten Wiederherstellungszeiten versieht - eine für alle Seiten verbindliche und konstruktive Vorgehensweise.

Zum anderen lassen sich viele Schritte bei der Dokumentation von Konfigurationen automatisieren: Anstelle aufwändiger, aber unbrauchbarer interner Installationsbeschreibungen sollten Log-Dateien, Systemsicherungen und Schattenkopien von Dateien erstellt werden, um im Fehlerfall die letzten Versionen und Zustände greifbar zu machen.

Kommunikation und Arbeitsteilung anpassen

Spürbare Verbesserungen stellen sich nur dann ein, wenn sich Arbeitsweisen und Kommunikationswege der handelnden Personen verändern. Das setzt aber voraus, dass die jeweiligen Itil-Prozesse auf ihren Wert für die betroffenen Mitarbeiter hin untersucht, umgesetzt und dargestellt werden. Bleibt es bei abstrakten Prozessüberlegungen, die der Einzelne nicht als Vorteil für seine jeweilige Arbeit wahrnimmt, ist das Projekt zum Scheitern verurteilt. Abhilfe lässt sich dadurch schaffen, dass die Verantwortlichkeiten für die Einführung der zu etablierenden Prozesse auch dort platziert werden, wo sie künftig den Arbeitsstil verändern.

Als "Single Point of Contact" für alle Anwenderfragen kommt dem Service-Desk eine zentrale Rolle zu. Allerdings hat dieser nur in den seltensten Fällen die inhaltliche Weisungsbefugnis, diese Funktion zu erfüllen. Vielmehr stehen die im User Help-Desk (UHD) tätigen Mitarbeiter oft neben den technischen Stars der IT-Abteilung, sprich: die Befugnisse richten sich nach den jeweiligen Technik-Skills. "Ein Mitarbeiter im Helpdesk hat weniger Ahnung von IT, also kann er mir auch keine Anweisungen geben", so lässt sich die Haltung vieler IT-ler gegenüber ihren UHD-Kollegen umschreiben. In einer solchen Konstellation drohen die optimierten Prozesse schon an der Kommunikation, der Arbeitsteilung und den Eskalationswegen zu scheitern. Auch dem lässt sich aber vorbauen: So haben viele Unternehmen ihre Mitarbeiter im Helpdesk sowie im First- und Second-Level-Support dazu angehalten, die Anforderungen an die Zusammenarbeit gemeinsam zu spezifizieren und verbindliche Absprachen zu treffen. Auf diese Weise lässt sich in puncto Prozessoptimierung weitaus mehr erreichen als etwa durch zeitaufwändiges Training, durch Literatur oder eine Vielzahl von Anweisungen. (kf)