Die Phase der Umsetzung
Aufgrund seiner Marktbedeutung beschränken wir uns bei den weiteren Betrachtungen auf OTRS. Das System, das kostenfrei heruntergeladen und ausprobiert werden kann, ist zügig installiert. Nutzern wird es leicht fallen, die ersten Warteschlangen für Tickets (so genannte Queues) einzurichten. So lassen sich recht einfach ITSM-Praxiserfahrungen sammeln. Ein funktionales System wird daraus aber noch nicht.
Die meisten größeren ITSM-Projekte kommen ohne das Know-how eines spezialisierten Dienstleisters nicht aus. Je nach Ausprägung des Anfrage-Managements kann er dabei helfen, weitere Prozesse zu integrieren, so dass Event-, Konfigurations- und Change- oder Release-Management reibungslos funktionieren.
- KIX4OTRS von c.a.p.e. IT
c.a.p.e. IT ist ein Anbieter von Open Source Software und hat sich im deutschsprachigen Raum als Dienstleister für die Einführung von IT Service Management mit OTRS positioniert. Die OTRS-basierte Integrationsplattform KIX4OTRS bietet beispielsweise folgende Funktionen: - Der Queuebaum
Alle Angestellten in der IT lassen sich über Rollen bestimmten Agentengruppen zuordnen. Über einen Explorer-Baum haben sie eine übersichtliche Darstellung der Systemstruktur sowie die Tickets in den Queues (Warteschlangen) für sie persönlich oder ihre Gruppe. - Die CMDB-Ansicht der CI-Daten
Die wichtigsten Daten eines Konfigurationsobjektes aus der CMBD werden angezeigt. Bei diesem Rechner sind es Informationen zur Hardware und der installierten Software mit dem Hinweis, dass die Software „opsi“ von uib weitere Details birgt. - Die Karteikartenreiter der CI-Daten
Navigation und Bedienung durch Karteikartenreiter (Tabs) erhöhen die Übersichtlichkeit der Daten durch die Gruppierung von relevanten Informationen. - Die Karteikartenreiter für verknüpfte Objekte
Ein IT-Mitarbeiter erkennt auf einen Blick, welche Objekte (zum Beispiel Tickets, andere Konfigurationsobjekte, FAQ-Einträge, Services und Personen) in welcher Form mit einem ausgewählten Konfigurationsobjekt aktiv verknüpft sind. - Karteikartenreiterfür die Versionen
Die Anzeige der neuen Attribute eines Konfigurationsobjektes im Vergleich zu einer älteren Versionen lässt die Änderungen schneller zu erkennen, zum Beispiel nach Software-Updates auf einem Rechner. - Das Dashboard mit Eskalationen
Farbliche Markierungen der offenen Tickets sorgen nach vordefinierten Regeln für eine Eskalation bei der Bearbeitung von Incidents. - Die Eskalationsansicht
Ohne Suchaufwand lassen sich alle eskalierten Tickets (Vorgänge) nach ihrer Eskalationszeit erkennen, um sie entsprechend ihrer Prioritäten bearbeiten zu können. - Die Ansicht nach Queues
Viel zu tun – und zwar subito! Eine andere Anzeige präsentiert dringende Aufgaben (Tickets) vor einer Gesamtanzeige der Warteschlangen (Queues). - Die Ticket-Vorlagen
Anwender sollten ihre Tickets mit einer ihnen gewohnten Vorlage erstellen können. Hier ein Beispiel für ein Ticket (Rechnerbestellung) aus der IT selbst, das eine automatische Verknüpfung des angeforderten Systems mit anderen Konfigurationsobjekten ermöglicht. - Die Ticket-Ansicht
Hilfe für den Helpdesk: Zu den per Tickets gemeldeten Incidents kann der Support Lösungshilfen aus einem FAQ-Verzeichnis oder anderen Quellen aufrufen.
Kommt OTRS zum Einsatz, lassen sich Event-Meldungen aus Monitoring-Tools wie "Nagios" oder dem Fork "Icinga" automatisch einbinden. Auch proprietäre Produkte wie "HP Openview" können berücksichtigt werden. Auch das Konfigurations-Management ist offen für Erweiterungen wie die automatische Software-Verteilung "opsi" von der Mainzer uib, für Thin-Client-Tools von Igel oder für die CMDB "i-doit" als Alternative oder Ergänzung zur OTRS-eigenen CMDB. Hinzu könnten "Bugzilla" oder "JIRA" für das Change- und Release-Management kommen. Ein MediaWiki und andere Erweiterungen für den Self-Service sind ebenfalls möglich.
Die weitaus größte Projektherausforderung ist die Qualität der Datenbasis, die in die CMDB einfließen soll. In den meisten Fällen sind bei den Inventardaten die Konfigurationsobjekte in verschiedenen Datenbanken, Tabellen oder Listen erfasst, Informationen über die Beziehungen zwischen den Objekten fehlen. Das Einbinden, Strukturieren und Homogenisieren der Konfigurationsdaten verschlingt meistens viel Zeit.
Ähnlich verhält es sich mit den Kundendaten. In der Regel sind alle Informationen über die Mitarbeiter in einem Verzeichnisdienst erfasst, von wo sie sich theoretisch leicht integrieren lassen sollten. Die Praxis hält allerdings regelmäßig Überraschungen bereit. Geht man Fehlermeldungen auf den Grund, stößt man auf Dubletten oder Datensätze, denen bestimmte Attribute fehlen. In OTRS-Umgebungen muss das Attribut "E-Mail-Adresse" immer gefüllt sein, es ist ein Pflichtfeld.
Wichtig ist auch das Filtern der Informationen, die in das ITSM-System einfließen. Allein die Basissysteme liefern eine erschlagende Menge an Daten, von denen der überwiegende Anteil für die Organisation der IT-Prozesse völlig unerheblich ist. Dabei braucht beispielsweise der Helpdesk die wichtigsten Informationen auf einen Blick, weil er möglichst schnell Entscheidungen treffen muss, die dem Endanwender helfen. Tausende Detaildaten verschleiern das Problem nur. Reichen die Informationen, um Anfragen auf den Grund zu gehen, nicht aus, kann er vertiefende Daten aus den Subsystemen holen. Auf diese Selektion, die Bestimmung des relevanten Inputs für den Großteil der Incident-Meldungen, sollte viel Wert gelegt werden. Sie wird bei jedem Unternehmen etwas anders ausfallen.
Selbstverständlich wollen alle Verantwortlichen Reports. Dabei sind sie als Tätigkeitsnachweis (Wie viele Tickets pro Monat?) häufig wenig hilfreich. Sinnvoller sind Reports, die sich von konkreten Indikatoren ableiten und dazu beitragen, Incidents künftig vorzubeugen. So kann zum Beispiel eine Häufung von Router-Ausfällen anzeigen, dass ein Gerätetyp für bestimmte Umweltbedingungen wie Hitze und Staub ungeeignet ist. Auslastungsdaten von Druckern geben Hinweise darauf, ob Kauf oder Leasing der Geräte wirtschaftlicher ist. Indikatoren können auch die Qualität der angebotenen Serviceleistungen sein.
Die Basiseinrichtung eines ITSM-Systems muss dokumentiert werden. Tatsächlich geschieht das aufgrund der oft hohen Belastung des IT-Personals meistens nur lückenhaft. Unabdingbar aber ist, wenigstens die Konfigurationsänderungen gegenüber dem Standard-OTRS festzuhalten.
Die Phase der ITSM-Einführung
In der ITSM-Einführungsphase ist es wichtig, die IT-Mitarbeiter gut geschult in die Produktivphase des neuen ITSM-Systems mit gegebenenfalls neuen Prozessen starten zu lassen. "Learning by Doing" ist hier der falsche Weg. Sind die IT-Mitarbeiter im Umgang mit dem neuen system nicht kompetent, erkennen die Endanwender das sofort. Sie werden das Projekt ablehnen und in der Folge entsteht eine Investitionsruine.
Die Endanwender sind der eigentliche Knackpunkt. Sie haben sie sich an bestimmte Verfahren zur Problemlösung gewöhnt, zum Beispiel Papierformulare, auf denen sie ihr Anliegen festhalten. Diese Formulare sollten möglichst genau in elektronische Vorlagen umgesetzt werden. Finden die Anwender ihre gewohnte Umgebung wieder, werden sie auch im produktiven Betrieb mit den neuen Mitteln arbeiten - und einer der wichtigen "Quick-Wins" ist erreicht.
Sollen die Endanwender etwas anders machen, als sie es gewohnt sind, muss man es ihnen erklären. Wichtig ist, dass der Support über eine zentrale Telefonnummer und Mailadresse zu erreichen ist. Das wird die Kunden nicht davon abhalten, ihren bekannten Supporter anzurufen oder sogar persönlich aufzusuchen. Deshalb werden die IT-Mitarbeiter Geduld aufbringen müssen, den Anwendern das Ticket-System sowie Organisation und Steuerung des Helpdesk mitsamt den Vorteilen zu erklären. Allerdings sei vor der Illusion gewarnt, durch das Schreiben von Tickets seien alle Firmenangehörige gleich. Die Sekretärin vom Chef wird auch in Zukunft gleicher sein. Zu diesem Zweck gibt es Klassifizierungsmerkmale wie Ticket-Typen, Services und SLAs, um Tickets vorab zu priorisieren.
Die Betriebsphase
Die Einführungsprobleme ziehen sich weit in die eigentliche Betriebsphase hinein. Nun aber ist es Zeit, die Früchte klugen Vorgehens zu ernten. Aus der Praxis Dutzender Projekte lässt sich feststellen, dass ITSM, selbst auf der unteren Ebene des Helpdesk, ein nie endendes Projekt ist. Und das ist durchaus im Sinne der ITIL-Vordenker, denen zufolge sich die IT dynamisch an die sich wandelnden Anforderungen von Unternehmen und Verwaltungen anzupassen hat.
Das manifestiert sich vor allem darin, dass regelmäßig schon bald nach der Produkteinführung neue Wünsche hinsichtlich Funktionalität und Prozesskonfiguration auftauchen. Erstaunlicherweise haben diese meistens herzlich wenig mit den in der Vorbereitungsphase vorgebrachten Wunschanforderungen zu tun. Das unterstreicht, wie wichtig es ist, die anfängliche Anforderungsliste möglichst klein zu halten und zu priorisieren.
Ganz sicher aber wird sehr bald in der IT die Idee aufkommen, man könne die Arbeitslast durch "Customer Self Service" weiter reduzieren. An dieses Thema ist mit Vorsicht und Planung heranzugehen. Der Ansatz "Jetzt helfe ich mir selbst" richtet in der IT eher Schaden an, jedenfalls wenn es um die Behebung von Funktionsstörungen geht. Unproblematischer ist sie, wenn es um das Bereitstellen von Applikationen geht oder den Zugang zu Dateiverzeichnissen, E-Mail oder ähnlichem. Dazu bedarf es aber zum Teil neuer innerbetrieblicher Abläufe und ihrer elektronischen Nachbildung - womit das nächste Projekt auf dem ITSM-Weg starten kann. (mhr)