Implementierung des ITIL® Service Desk mit Open Source Software

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Quelltextverzeichnis

Abkürzungsverzeichnis

1 Einleitung und Überblick
1.1 Einleitung
1.2 Überblick

2 Konzepte für Service-Desk-Applikationen
2.1 Information Technology Infrastructure Library (ITIL)
2.1.1 Definition: ITIL
2.1.2 Definition und Abgrenzung: Service Desk
2.1.3 Definition und Abgrenzung: Incident Management
2.2 Open Source Software (OSS)
2.2.1 Definition: OSS
2.2.2 Argumentation: Pro und Kontra von Open-Source-Lösungen

3 Anforderungskriterien an ITIL-Service-Desk-Lösungen
3.1 Anforderungskatalog für Service-Desk-Applikationen
3.1.1 Allgemeine Anforderungen aus ITIL
3.1.2 Allgemeine Anforderungen an OSS-Projekte
3.1.3 Anforderungen aus der Praxis
3.1.4 Erstellung des Anforderungskatalogs
3.1.4.1 Methodik
3.1.4.2 Aufbau
3.1.4.3 Zusammenfassung
3.2 Analyse verschiedener Open-Source-Produkte anhand des Anforderungskatalogs
3.2.1 Auswahl der Projektplattformen
3.2.1.1 Zope
3.2.1.2 PHP: Hypertext Preprocessor (PHP)
3.2.2 Recherche infrage kommender OSS
3.2.2.1 Recherche nach Anwendungen auf der Basis von Zope
3.2.2.1.1 Tracker
3.2.2.1.2 KnowledgeKit
3.2.2.1.3 OpenTicket
3.2.2.1.4 Xen
3.2.2.1.5 Free2Work (f2w) Helpdesk Project
3.2.2.2 Recherche nach Anwendungen auf der Basis von PHP
3.2.2.2.1 Double Choco Latte (DCL)
3.2.2.2.2 Information Ressource Manager (IRM)
3.2.2.2.3 DotProject
3.2.2.2.4 Help Center Live
3.2.2.2.5 Issue Tracker, OpenTicket und Open-ITIL
3.2.2.2.6 Support Information Tracker (SITR)
3.2.3 Evaluation
3.2.3.1 Aufbau der Testumgebung
3.2.3.2 Anwendung des Anforderungskatalogs auf ausgewählte OSS
3.2.3.2.1 f2w Helpdesk Project
3.2.3.2.1.1 Bewertung der ITIL-Anforderungen
3.2.3.2.1.2 Anforderungen an OSS
3.2.3.2.1.3 Anforderungen aus der Praxis
3.2.3.2.1.4 Zusammenfassung
3.2.3.2.2 DCL
3.2.3.2.2.1 Bewertung der ITIL-Anforderungen
3.2.3.2.2.2 Anforderungen an OSS
3.2.3.2.2.3 Anforderungen aus der Praxis
3.2.3.2.2.4 Zusammenfassung
3.2.3.2.3 DotProject
3.2.3.2.3.1 Bewertung der ITIL Anforderungen
3.2.3.2.3.2 Anforderungen an OSS
3.2.3.2.3.3 Anforderungen aus der Praxis
3.2.3.2.3.4 Zusammenfassung
3.2.3.3 Fazit der Evaluation

4 Implementierung einer ITIL-konformen Service-Desk-Applikation auf der Basis eines Open-Source-Werkzeuges
4.1 Überblick
4.2 Analyse der verwendeten OSS
4.2.1 Test- und Entwicklungsumgebung
4.2.2 Zielumgebung
4.2.3 Funktionsbeschreibung der OSS
4.2.3.1 Aufnahme eines neuen Incident
4.2.3.2 Aktivitäten bei einer Anfrage
4.2.3.3 Aktivitäten bei einer Störung
4.2.3.4 Abschluss eines Incident
4.2.4 Quelltextanalyse anhand der Entwicklerdokumentation
4.2.5 Kriterienabgrenzung für die Implementierung
4.2.5.1 Muss-Kriterien
4.2.5.2 Wunschkriterien
4.3 Implementierung und Installation
4.3.1 Methodik
4.3.2 Umsetzung der Muss-Kriterien
4.3.2.1 Identifizierung und Produktbezeichnung
4.3.2.2 ITIL-Wording
4.3.2.3 Incident-Datensatz
4.3.2.4 Incident Workflow
4.3.2.5 Funktionale Aspekte
4.3.2.6 Wissensdatenbank
4.3.2.7 Organisationsanforderungen aus der Praxis
4.3.3 Umsetzung der Wunschkriterien
4.3.4 Installation und Distribution
4.4 Zusammenfassung

5 Schlussbemerkungen und Ausblick

6 Literaturverzeichnis
6.1 Printquellen
6.2 Elektronische Quellen

7 Anhang

Abbildungsverzeichnis

Abbildung 1: Kapitelübersicht

Abbildung 2: ITIL-Komponenten

Abbildung 3: Incident-Bearbeitung im Service Desk

Abbildung 4: Incident Management innerhalb des ITIL Service Support Set

Abbildung 5: Aktivitäten des Incident Management

Abbildung 6: Kostenoptimierungspotenzial im IT-Service Management (in %)

Abbildung 7: Der erste Eindruck des f2w Helpdesk

Abbildung 8: DCL bei der Eingabe eines Tickets

Abbildung 9: Anlegen eines neuen Tickets in DotProject

Abbildung 10: Implementierung des OSS ITIL Service Desk

Abbildung 11: DCL-Systemkonfiguration

Abbildung 12: Hyperlink zu dem eigentlichen Incident

Abbildung 13: DCL-Startseite mit visuellen Eskalationsmarkierungen

Abbildung 14: IT-Service-DeskTop-Logo

Abbildung 15: Übersetzung und Anpassung im IT Service DeskTop Setup

Abbildung 16: Verknüpfung von CIs im IT Service DeskTop

Abbildung 17: Darstellung verknüpfter CIs

Abbildung 18: Auswahl der Kategorie und Unterkategorie

Abbildung 19: Einfügen bereits existierender Tickets

Abbildung 20: Einfügen einer Referenz auf ein existierendes Ticket

Abbildung 21: Die Wissensdatenbank wird als Menüeintrag in DCL integriert

Abbildung 22: Einbindung der Erfahrungsdatenbank für Lösungen von Incident-Tickets

Abbildung 23: Auswahl einer gespeicherten Lösung aus der Erfahrungsdatenbank 105 Abbildung 24: Die Lösung des Zwischenfalls wird aus der Erfahrungsdatenbank gelesen

Abbildung 25: LDAP-Integration bei der Auswahl eines Kontakts

Abbildung 26: Hyperlink auf die Detailinformationen des LDAP-Accounts

Abbildung 27: Auswahl von Kontaktdaten aus der Incident-Ticket-Historie

Abbildung 28: Suche nach Störungen bestimmter CIs oder Nutzer

Tabellenverzeichnis

Tabelle 1: Einfacher Anforderungskatalog

Tabelle 2: f2w Helpdesk und ITIL-Wording

Tabelle 3: f2w Helpdesk und Incident-Datensätze

Tabelle 4: f2w Helpdesk bei den funktionalen Aspekten

Tabelle 5: Unterstützung der Organisation bei f2w Helpdesk

Tabelle 6: Anforderungen an die IT-Technologie des f2w Helpdesk

Tabelle 7: DCL und das ITIL-Wording

Tabelle 8: Funktionale Aspekte, die von DCL erfüllt werden

Tabelle 9: Eine Wissensdatenbank ist nicht in DCL enthalten

Tabelle 10: DCL liegt in einer Beta-Version vor

Tabelle 11: DCL erfüllt kein Kriterium der Organisationsanforderungen aus der Praxis

Tabelle 12: DCL erfüllt alle entscheidenden Kriterien des Anforderungskatalogs

Tabelle 13: DotProject hat größtenteils keine ITIL-Konformität

Tabelle 14: DotProject zeigt weitere ITIL-Schwächen

Tabelle 15: Organisationskriterien werden nicht von DotProject unterstützt

Tabelle 16: Die IT-Technologie bei DotProject

Tabelle 17: Anforderungskatalog für OSS im Bereich des ITIL Service Desk

Quelltextverzeichnis

Quelltextauszug 1:Datei str/de/tck.str

Quelltextauszug 2: Datei str/de/sev.str

Quelltextauszug 3: Datei inc/class.htmlCIs.inc.php

Quelltextauszug 4: Datei inc/functions.inc.php, Funktion CreateLinkedText

Quelltextauszug 5: Datei contrib/escalateagent/class.htmlEscalateAgent.php

Quelltextauszug 6: Datei contrib/escalateagent/class.htmlEscalateAgent.php

Quelltextauszug 7: Datei inc/class.jsAttributesets.inc.php

Quelltextauszug 8: Datei inc/class.htmlTckUrgImpPri.inc.php

Quelltextauszug 9: Datei templates/default/htmlTicketForm.tpl

Quelltextauszug 10: Datei inc/functions.inc.php

Quelltextauszug 11: Datei inc/class.dbSession.inc.php

Quelltextauszug 12: Datei inc/class.boITILKBSession.inc.php

Quelltextauszug 13: Datei inc/functions.inc.php, Funktion CreateLinkedText

Quelltextauszug 14: Datei inc/class.boTickets.inc.php

Quelltextauszug 15: Datei inc/ITILconfig.inc.php

Quelltextauszug 16: Datei templates/custom/itil_notify_tck_add_de.tpl

Quelltextauszug 17: Datei inc/class.boITILNotifications.inc.php

Quelltextauszug 18: Datei ldap/class.htmlLDAPAccounts.php

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung und Überblick

1.1 Einleitung

Hohe Investitionen im IT-Bereich müssen gut begründet sein - gerade in der heutigen Zeit. Die Anwendung von ITIL verspricht zwar ein hohes Optimierungs- und Einsparungspotenzial, jedoch entstehen im Allgemeinen vorher erhebliche Kosten für die Implementierung der ITILProzesse, die Ausrichtung und Schulung des Personals sowie für die Entwicklung IT-unterstützter Workflows.

Nicht nur der Kostendruck, sondern auch der Selbsterhaltungsgedanke rücken stärker in die durch Outsourcing geprägte und teilweise schlecht organisierte Unternehmens-IT: Wer jahrelang im IT-Support in mittelständischen Betrieben gearbeitet hat oder die Entwicklung begutachtet, sieht ganz klar, dass es teilweise Probleme bereitet, alle Anfragen und Störungen innerhalb der zugesicherten Zeit zu bearbeiten. Sind dann u. U. noch mehrere Mitarbeiter nur zeitweise mit der Erledigung von Störungen betraut, wie z. B. studentische Hilfskräfte, werden Anfragen und Störungen möglicherweise vergessen oder mehr schlecht als recht behoben. Mit dem ITIL-Modell können in Problembereichen, wie z. B. dem Incident Management, Qualität und Übersichtlichkeit etabliert werden.

Zur Unterstützung der ITIL-Prozesse können ITIL-Automatisierungs- Werkzeuge in Form von Software Verwaltungsaufgaben koordinieren und kontrollieren. Kosteneinsparungen können dabei bereits bei den Anschaffungskosten dieser Software-Werkzeuge erzielt werden: Gerade kleine Unternehmen bis 1000 Mitarbeitern brauchen keine kommerziellen „Alleskönner“, sondern können auch mit frei ladbaren Tools aus dem Internet bereits in das ITIL-Framework einsteigen.¹

Mit dem Open-Source-Lizenzmodell ist es heute möglich, eine hohe Anpassbarkeit an die Organisation zu erreichen. Die kommerzielle Unabhängigkeit, der kostengünstige Einstieg und die Tatsache, das Rad nicht neu erfinden zu müssen, sind weitere unschlagbare Vorteile.

Diese Arbeit widmet sich der Erarbeitung und Implementierung einer ITIL- Automatisierungs-Software für mittelständische Unternehmen, welche das Incident Management im Service Desk umfassend abbilden kann. Grundlage für dieses Automatisierungstool soll ein Open-Source-Projekt sein, welches die noch aufzustellenden Anforderungen am besten erfüllt. Gleichzeitig wird herausgestellt, ob sich Open Source Software grundsätzlich für den Einsatz im Zusammenhang mit ITIL eignet.

1.2 Überblick

Die Vorgehensweise ist in Abbildung 1 schematisch dargestellt und wird im Folgenden kurz zusammengefasst:

Im theoretischen Abschnitt 2 (Konzepte für Service-Desk-Applikationen) werden die bestehenden Konzepte ITIL und Open Source vorgestellt und in Beziehung zu dem relevanten Kontext ITIL Service Desk gesetzt. Dabei wird das ITIL-Framework speziell auf die Einstiegsbereiche abgestimmt behandelt und das Open-Source-Lizenzmodell mit wichtigen rechtlichen und arbeitstheoretischen Hintergründen für den Umgang mit Open Source vorgestellt.

In Abschnitt 3 (Anforderungskriterien an ITIL-Service-Desk-Lösungen) werden die Anforderungen aus den Service-Desk-Konzepten und allgemeinen Anforderungen aus der Praxis in einen Anforderungskatalog überführt. Nach der Recherche verschiedener Projektplattformen und der darauf aufsetzenden Open Source Software für den Service Desk wird dieser Anforderungskatalog als Grundlage für die Bewertung genutzt.

Nach den Grundlagen aus Abschnitt 2 und der Evaluation aus Abschnitt 3 versucht der praktische Abschnitt 4 (Implementierung einer ITIL- konformen Service-Desk-Applikation auf der Basis eines Open-Source- Werkzeuges) konkret aus einem zuvor als ITIL-anforderungskonform evaluierten Open-Source-Software-Projekt die Kriterien umzusetzen, die eine umfassende Eignung für den ITIL Service Desk zulassen.

Abschnitt 5 (Schlussbemerkungen und Ausblick) resümiert die Resultate kurz.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Kapitelübersicht

2 Konzepte für Service-Desk-Applikationen

2.1 Information Technology Infrastructure Library (ITIL)

In der heutigen Zeit sind viele Informations-Technologie(IT)-Abteilungen zu Dienstleistern innerhalb des Unternehmens geworden: Hohe Qualitätsansprüche und Kostenbewusstsein werden zunehmend an diese Dienstleistungen gestellt; früher dagegen stand die Lieferung von Informationstechnik im Mittelpunkt. Der Wandel hat sich vom Technik- zum Kundenfokus vollzogen: IT-Abteilungen sind nicht zuletzt aus Selbsterhaltungsmotiven angehalten, die internen Fachabteilungen als eigene Kunden zu behandeln, denn das in Mode gekommene Outsourcing könnte bei andauernder Unzufriedenheit leicht die einst gefällte Entscheidung für eine interne IT revidieren.

Mitte der 80er-Jahre erkannte die zentrale Informatikberatungsstelle der britischen Regierung, die Central Computer and Telecommunications Agency (CCTA), dass Wirtschaftsunternehmen und Behörden in immer größere Abhängigkeiten der eigenen IT gerieten, um den zukünftigen Geschäftsanforderungen gerecht zu werden und unternehmerische Ziele zu verwirklichen. Ausgangspunkt für die Analyse der IT-Dienstleistungen war die Aufforderung der britischen Regierung an ihre Behörden, alle Services zu dokumentieren, um die damals infrage gestellte Leistungsfähigkeit der öffentlichen Verwaltung zu überprüfen.² Aufbauend auf Analysen von IBM aus dem vorherigen Jahrzehnt begann das heutige Office of Government Commerce Großbritannien (OGC früher CCTA) in weltweiter Zusammenarbeit mit IT-Beratern, -Trainern und -Technikern einheitliche Regeln für die IT zu entwickeln, die in der ITIL-Bücherreihe veröffentlicht und ständig erweitert werden.³

2.1.1 Definition: ITIL

Wie der Name „IT Infrastructure Library“ schon ausdrückt, besteht ITIL aus einer Sammlung von „Best Practice“⁴ -Büchern. In ihrer ursprünglichen Form bestand die Bibliothek aus über 40 Büchern. Die aktuelle Überarbeitung zur ITIL-Version 2.0 fasst das Regelwerk in sieben Büchern zusammen; das ergänzende achte Buch, „The Business Perspective“, erscheint noch im Sommer 2004.⁵ ITIL beschreibt nicht nur die reine Lehre der notwendigen Prozesse und Abläufe für den IT-Betrieb, sondern auch ein systematisches und professionelles Vorgehen für das Management dieser IT und ihrer Services. Die ITIL-Bibliothek stellt neben den Kunden die Bedeutung der Erfüllung von Unternehmensanforderungen⁶ in den Mittelpunkt.

ITIL ist ein generisches Modell, das von den jeweiligen IT-Organisationen mit Leben gefüllt werden muss: Das Rahmenwerk bildet alle Funktionsbereiche ab, ohne auf die konkrete Implementierung in Form von Verfahrensanweisungen oder Ähnlichem einzugehen. Die Vorteile dieser Bibliothek sind vor allem die Herstellerunabhängigkeit, die öffentliche Verfügbarkeit und die Autonomie von Branche und IT-Technologie; unter anderem hat sich ITIL deshalb zu einem weltweit anerkannten De-facto- Standard entwickelt. In Ländern wie Großbritannien, USA, Niederlande, Australien oder Südafrika ist ITIL der Inbegriff für IT Service Management geworden (ITSM).⁷ Auch in Deutschland bestätigt eine Umfrage der Universität Dortmund die immer größer werdende Bedeutung von ITIL für deutsche Unternehmen im IT-Service-Umfeld.⁸

Mit nach ITIL implementierten ITSM-Prozessen können erhebliche Betriebskosten eingespart werden: Informationen und Kommunikation sind kritische Bestandteile von Geschäftsprozessen geworden; an ITIL ausgerichtete Prozesse beseitigen z. B. alle IT-basierten Störungen per Definition proaktiv, qualifiziert und kostenoptimal. Besondere Beachtung schenkt ITIL der Gestaltung von bestehenden Service-Prozessen sowie den organisatorischen Informationsschnittstellen. Zudem werden die transparente Darstellung mit einer eindeutigen Begriffsdefinition als Kommunikationshilfe und die Messung des Erfolgs der tatsächlich erbrachten Services nach innen und außen gefördert.⁹

„Nach der bisherigen Praxiserfahrung enthält das Service Management das Potential, die Kosten zu reduzieren, die betriebsunterstützenden IT- Dienstleistungen effizienter zu erbringen sowie die Kunden- und Mitarbeiterzufriedenheit zu steigern. Insbesondere die Zuverlässigkeit und Verfügbarkeit der IT-Dienstleistungen kann durch die Gestaltung der ServiceProzesse nach diesem Ansatz signifikant erhöht werden.“¹⁰

Für das ITSM gelten die ITIL-Bibliotheken als umfassende Methodiken für die Konzeption, Steuerung und Optimierung von IT-basierten Geschäftsprozessen. Der Einsatz von ITIL fördert die Ausführungen von IT-Dienstleistungen, die den Kundenanforderungen entsprechen; eine höhere Kundenzufriedenheit und besseres Kundenverständnis ist die Folge. Mit geringem Aufwand ermöglicht das Rahmenwerk die Entwicklung von Prozessen, Prozeduren und Arbeitsanweisungen im IT- Bereich; das integrierte Wissensmanagement sichert eine hohe Produktivität durch den gezielten Einsatz von Wissen und Erfahrung. Durch die einheitliche Begriffsdefinition werden Missverständnisse zwischen Fachbereichen, IT und Lieferanten reduziert und - z. B. im Falle von Umstrukturierungen und Rationalisierungsmaßnahmen - die Integration der verschiedenen Einheiten unterstützt.¹¹

Thematisch enthält ITIL zwölf Kernkomponenten, darunter elf Prozesse und eine Funktion, die sich auf die Bereiche „Service Support“ und „Service Delivery“ aufteilen. Jeder Teil definiert eine Reihe von Prozessen, Funktionen, Verantwortlichkeiten, Gestaltungselementen sowie Leitlinien, die eine IT-Abteilung erfüllen sollte, um den immer umfangreicher werdenden Anforderungen in ihrem Umfeld zu begegnen.¹² Der Bereich „Service Support“ bildet die Anwendersicht auf der operationalen Ebene ab, wie etwa das tägliche „doing“, d. h. die Erbringung und Unterstützung der jeweils angebotenen IT-Dienstleistungen; der Bereich „Service Delivery“ beschreibt die Kundensicht auf der strategischen Ebene, wie z. B. die langfristige Planung und Verbesserung der IT-Service- Leistungen. Während die Service-Support-Module bereits in der ITILBibliothek umfassend beschrieben sind, unterliegen die Prozesse des Service Delivery der ständigen Anpassung und Weiterentwicklung. Die enthaltenen Komponenten werden in Abbildung 2 aufgelistet:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: ITIL-Komponenten

Das Service Support Set enthält die Module „Incident Management“, das eine schnellstmögliche Wiederherstellung des normalen IT-Betriebs bei minimaler Behinderung des Geschäftsbetriebs sicherstellt, „Problem Management“, das die durch Fehler in der IT-Infrastruktur verursachten Auswirkungen auf den Geschäftsbetrieb proaktiv verhindert und „Configuration Management“, das ein Konfigurationsverzeichnis aller beteiligten IT-Komponenten, inklusive ihrer jeweiligen Versionen, Ausstattungen und Zuordnungen, darstellt. Das „Change Management“ legt standardisierte Verfahren für kleine bis mittlere Veränderungen der ITLandschaft fest, um änderungsbedingte Störungen oder Ausfälle zu vermeiden bzw. ein „Rollback“¹³ zu ermöglichen. Für größere Änderungen, wie unternehmensweite Software-Einführungen oder -Release-Wechsel ist das „Release Management“ eingerichtet. Die Funktion des Service Desk wird als zentrale Schnittstelle zwischen IT-Benutzern und IT-Dienstleistern etabliert und in 2.1.2 näher erläutert.¹⁴

Das Service Delivery Set beschreibt den Prozess „Service Level Management“, der die Dokumentation, Anpassung und Überwachung der qualitativen Service-Ziele in Service Level Agreements¹⁵ (SLAs) beinhaltet; Financial Management ergänzt die betriebswirtschaftliche Kostenperspektive, „Capacity Management“ plant die Soll-IT-Infrastruktur anhand der Erfordernisse aus der Unternehmensplanung und -strategie. Das „Continuity Management“ stellt die gegenwärtige und zukünftige Verfügbarkeit der IT-Infrastruktur sicher, „Availability Management“ optimiert die Leistungsfähigkeit der IT-Ressourcen in Richtung Verfügbarkeit und garantiert deren kostenwirksame und nachhaltige Umsetzung. Das „IT Security Management“ komplettiert das Continuity Management um Sicherungsmaßnahmen, wie die Benutzerkontenpflege oder Datensicherungsprozesse.¹⁶

ITIL ist ferner die Grundlage für ein Qualitätsmanagement im IT-Bereich¹⁷: Alle Prozesse haben eine enge Anlehnung an Qualitätssysteme, wie z. B. DIN EN ISO 9000:2000, und Total Quality Frameworks, wie z. B. der European Foundation for Quality Management (EFQM); durch die definierten Prozesse und „Best Practice“-Methoden für das Management von IT-Services ermöglicht ITIL so einen schnellen Weg zur QualitätsZertifizierung der IT.¹⁸

2.1.2 Definition und Abgrenzung: Service Desk

Der ITIL Service Desk ist der primäre Kontakt zwischen der IT-Service- Support-Abteilung und den Kunden bzw. den Endbenutzern, die Hilfe benötigen, Fragen oder neue Anforderungen stellen. Ohne diesen wichtigen operativen Kontaktpunkt¹⁹ würde das Unternehmen zeitintensive und somit kostspielige Ressourcen aufwenden müssen, um alle Zwischenfälle umfassend zu lösen und um die Ausfallzeiten der IT- Infrastruktur zu minimieren.²⁰ Das Hauptziel des Service Desk ist die kompetente Benutzerbetreuung, die eine Kundenbindung aufbaut. Im Rahmen des Incident Management gewährleistet der Service Desk die Sicherstellung bzw. Wiederherstellung des normalen Service-Betriebs innerhalb der definierten SLA’s bei Störungen.

„Der Service Desk ist der einzige Kontaktpunkt zwischen den Service Providern und den Benutzern auf einer Tag-zu-Tag-Basis. Er ist ebenso Fokus für das Berichten von Zwischenfällen, als auch für die Annahme von Service- Anfragen. Vor diesem Hintergrund ist der Service Desk angehalten, die Benutzer über Service-Ereignisse, Aktionen und Angelegenheiten zu informieren, die deren Tagesgeschäfte in irgendeiner Weise beeinträchtigen könnten.“²¹

Es gibt mehrere Service-Desk-Typen, die sich unterscheiden lassen in einfache Anrufabwicklung bei Call-Centern, die erweiterte Annahme von Anrufen, Störungen und Benachrichtigungen der Benutzer bei laienhaften Service Desks, die Verwaltung und Beseitigung vieler Störungen durch einen professionellen Service Desk und den hoch qualifizierten Service Desk, der den Großteil aller anfallenden Störungen selbst behebt und verwaltet.²² Zu den Tätigkeiten aller Typen gehört der „First Line Support“²³ ; außer dem reinen Call-Center vereint der Service Desk (siehe Abbildung 3) das Aufnehmen von Störungen und Zwischenfällen, den so genannten „Incidents“, deren Klassifikation, Priorisierung und Eskalation. Weiterhin gehören das Suchen nach „Work-arounds“²⁴ und die Fortschreibung der Benutzer- und IT-Ressourcen-Daten in der Configuration Management Database (CMDB) als Teil des Incident Management (siehe 2.1.3) zu den Aufgaben des Service Desk.²⁵

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Incident-Bearbeitung im Service Desk ²⁶

Der Service Desk führt jede Art von Kommunikation der anderen ITILProzesse aus, wie etwa die Benachrichtigungen zu Release-Wechseln, die Veröffentlichung von Zeitplänen für Umstellungen oder die SLABerichte für das Management.²⁷

Neben der Bereitstellung aller benötigten Informationen muss der Service Desk dafür sorgen, dass ein Kundenauftrag autorisiert ist und alle folgenden Aktivitäten angestoßen werden. Unumgänglich ist bei allen Tätigkeiten die vollständige Dokumentation aller Prozess- und Funktionsschritte.²⁸

Der zentrale Bestandteil des Service Desk ist der Kontakt zu den Kunden; in einer modernen IT-Infrastruktur sind die Kunden nicht mehr nur auf den persönlichen Kontakt zu den Support-Mitarbeitern oder auf Telefonanrufe beschränkt, um Fragen zu Registrierung, Updates sowie Anfragen sonstiger Art mitzuteilen: Die Kundeninteraktion findet hauptsächlich durch E-Mail, Internet bzw. Intranet²⁹ oder Telefax statt; diese Schnittstellen der Kommunikation sind optimal für unkritische Störungen und Zwischenfälle geeignet, wie z. B. bei Software-Problemen, bei Umzügen, Installationen oder Bedarfsmeldungen.³⁰

Die Nutzung eines computerunterstützten Service Desk ist ein Muss für die moderne Service-Support-Organisation: Digitales Management ermöglicht ein hohes Maß an Effizienz, Genauigkeit und schnellen Zugriff auf Lösungen bekannter Probleme, den so genannten „Known Errors“³¹, Anrufhistorien und Managementinformationen.³²

2.1.3 Definition und Abgrenzung: Incident Management

Incident Management ist ein Prozess (siehe Abbildung 4) innerhalb des ITIL Service Support Sets: Ziel dieses Prozesses ist die schnellstmögliche Wiederherstellung des normalen Geschäftsbetriebes mit der geringsten Auswirkung auf die Geschäftsprozesse. Der Incident Manager ist nach dem Rollenkonzept von ITIL verantwortlich für diesen gesamten Prozess. Störungen im Sinne von ITIL sind jegliche Ereignisse, die nicht Teil vordefinierter Rahmenbedingungen bzw. SLAs der IT-Dienste sind und in irgendeiner Form zu Störungen oder Minderungen der Qualität dieser Dienste beitragen. Auch Anfragen für neue IT-Dienste, so genannte „Request for Change“³³ (RFC), werden bei ITIL als „Incident“ verstanden.³⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Incident Management innerhalb des ITIL Service Support Set³⁵

Die Ursachenbeseitigung steht bei den Aktivitäten des Incident Management im Hintergrund: Bereits ein „Work-around“ zählt als Beseitigung der Störung. Um die Reaktionszeit zu verkürzen und die Kundenzufriedenheit zu erhöhen, wird das Incident Management über den Service Desk (siehe 2.1.2) gesteuert.³⁶

Die Aktivitäten des Incident Management lassen sich in sechs Bereiche aufteilen (siehe auch Abbildung 5): Zuerst gelangt eine Anfrage bzw. ein Zwischenfall durch den Service Desk oder ein automatisches Ereignis- Management-System (siehe Abbildung 4) in den Prozess des Incident Management; hier werden die Anfragen analysiert, aufgezeichnet und der Initiator benachrichtigt. Nachfolgend kann eine Störung aus den aufgenommenen Details klassifiziert, teilweise aus einem Vergleich mit bekannten Fehlern abgeschlossen und der erste Support initiiert werden. Als dritte Aufgabe gehört das gründliche Erforschen und die Diagnose der aufgenommenen Zwischenfälle zu den investigativen Schritten bei der Behebung von Störungen; hierbei sind umfangreiche Analysen in Zusammenarbeit mit dem Service Desk und die Einbeziehung der Kunden erforderlich. Als wichtigste Datenbasis dient hierbei die CMDB, die z. B. Abfragen über die Störungs-Historie einer bestimmten IT-Ressource ermöglicht, aber auch zusätzlich als Erfahrungsdatenbank für bekannte Probleme dient. Als vierte Aufgabe gehen die Behebung und die Wiederherstellung des normalen Geschäftsbetriebes durch eine Lösung, ein Work-around oder einen RFC in den Prozess des Incident Management ein. Als Abschluss für den Kunden wird ein Zwischenfall mit einer Abschlusskennung versehen und als geschlossen vermerkt.

Der Service Desk ist angehalten, die erforderlichen Informationen über involvierte und affektierte Ressourcen, den so genannten „Configuration Items“ (CIs), zu den entsprechenden Incidents zu verknüpfen und zu aktualisieren. Den gesamten Lebenszyklus eines Zwischenfalls begleitet der Service Desk als Verantwortlicher: Wenn im Prozess des Incident Management eine spezialisiertere Support-Gruppe die Behebung einer Störung übernehmen soll, muss gewährleistet werden, dass der Incident bis zur vollständigen Befriedigung des Kunden überwacht wird. Darüber hinaus liegt dem gesamten Prozess des Incident Management die Supervisor-Funktion des Service Desk zugrunde: Alle Zwischenfälle bedürfen des individuellen Monitorings, d. h. kritische Überprüfung und Überwachung der Stati und Fortschritte aller noch zu schließenden Vorfälle, und der Benachrichtigung der Kunden.³⁷

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Aktivitäten des Incident Management³⁸

Das Incident Management gehört nach einer Umfrage der Meta-Group zu den Einstiegsbereichen bei ITIL-Implementierungen; nach Koll ist generell der Support-Bereich, wie z. B. das reaktive Incident Management, weiter verbreitet als proaktive Services.³⁹

Vor allem im Einsatz von softwarebasierten Automatisierungstools steckt ein hohes Kostenoptimierungspotenzial (Abbildung 6) für das ITSM: Wesentliche Entlastungen der IT-Mannschaft versprechen Tools in Bereichen des Service Delivery sowie bei einer Automation des Incident Management (30 %) und des Service Desk (24 %).⁴⁰

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Kostenoptimierungspotenzial im IT-Service Management (in %)⁴¹

Koll fasst in einer Umfrage der wichtigsten ITIL-Funktionäre zusammen, dass für den Einstieg in das ITIL-Framework bei kleineren Unternehmen bereits frei ladbare Tools aus dem Internet ausreichen, um Service Desk, Incident Management und die CMDB abzubilden. Da kleinere Unternehmen bis 1000 Mitarbeiter einfache Tools verwenden können, um Kosteneinsparpotenziale in ihrer IT zu realisieren, sind aus Sicht dieser Firmen ITIL-Support-Werkzeuge interessant, die dem Prinzip des offenen und freien Quellcodes (siehe 2.2) unterliegen, da die Anschaffungskosten⁴² minimal sind und Anpassungen an die eigenen Prozesse und Organisationsstrukturen sowie Modifikationen der Software einfach möglich sind. Die generellen Vor- und Nachteile von Freier Software sollen in 2.2.2 behandelt werden.

2.2 Open Source Software (OSS)

„Traditionell bestimmt sich der Preis einer Ware aus den Faktoren Angebot und Nachfrage. Da die Freie Software per Definition beliebig kopiert und verteilt werden darf, und weil die Reproduktion im Zeitalter von CD-ROM und Internet mit keinen nennenswerten Kosten verbunden ist, wird das Angebot beliebig groß. Der Preis für die Software muss demnach selbst bei überwältigender Nachfrage beliebig klein werden. In der Realität befindet er sich tatsächlich auf dem Niveau des Selbstkostenpreises für die Reproduktion. Einen Internetanschluss vorausgesetzt, ist Freie Software ohne zusätzliche Kosten erhältlich.“⁴³

2.2.1 Definition: OSS

1984 wurde die Entwicklung von Open Source durch das „GNU’s not Unix“ (GNU)-Projekt eingeleitet. Richard Stallmann, der Begründer von GNU, wollte eine Software entwickeln, die unter dem Betriebssystem Unix, aber ohne Auflagen durch proprietäre Software verbreitet werden konnte. GNU sollte ein komplett freies Betriebssystem werden. Seit 1984 sind viele Programme durch das GNU-Projekt implementiert worden, darunter auch z. B. das Linux Kernel⁴⁴ des Linux-Betriebssystems.⁴⁵

Der Begriff „Open Source“ ist nicht allgemein gültig und wird erst seit 1998 verwendet. Abgeleitet ist die 1998 veröffentlichte Open-Source-Definition von der „Debian Free Licence“ des Debian-Betriebssystems:

Open Source ist zu 100 % frei verfügbar und wird in erster Linie für den Benutzer gemacht und nicht für die Hersteller. Das Lizenzmodell beruht auf einem Geben und Nehmen, da der modifizierte Code wieder freigegeben wird.⁴⁶

Die Begriffe „Free Software“ und „Open Source Software“ sind in der Folge praktisch identisch; heutzutage wird im Allgemeinen OSS mit Free Software gleichgesetzt.

Mertens beschreibt OSS als ein alternatives Entwicklungs-, Lizenzierungs- und Geschäftskonzept für Anwendungen, das folgende wichtige Merkmale hat: Kunden dürfen den Quellcode⁴⁷ inspizieren und prüfen, ob unerwünschte versteckte Funktionen und Schnittstellen eingebaut sind. Zusätzlich dürfen die Lizenznehmer einer OSS deren Quellcode nach eigenen Wünschen weiterentwickeln und modifizieren, solange dabei die Entwickler von verwendeter Software als Urheber genannt werden.⁴⁸

Damit die Freiheit der Software in dieser Form garantiert wird, stellt der ursprüngliche Entwickler seine Arbeit unter eine so genannte „freie Software-Lizenz“. Bei der Wahl der Open-Source-Lizenz wird überwiegend die GNU General Public License (GPL) verwendet.⁴⁹ Für eine Liste von kompatiblen zertifizierten Open-Source-Lizenzen sei auf die Open Source Initiative (OSI)⁵⁰ verwiesen.

Die Absicht, die hinter der GPL steckt, ist das Copyleft. Damit wird ausdrücklich die uneingeschränkte Verteilung und Verwendung der unter dem Schutz dieser Lizenz stehenden Programme erlaubt. Weiterhin wird darin festgelegt, dass Modifikationen einer Software, die ursprünglich unter der GPL-Lizenz standen, selbst wiederum unter das Copyleft fallen müssen. Ziel dieser Auflage ist es, die Freie Software vor Patentierungsbestrebungen und Besitzansprüchen zu schützen.⁵¹

Aus den Ausführungen geht hervor, dass OSS nicht vollkommen frei ist, sondern genannte Punkte zu beachten sind, wenn man OSS selbst modifiziert und weitergibt. OSS impliziert für den Anwender Rechte und Pflichten.

Im Zusammenhang mit OSS schreibt Raymond von Projekten, die als Software aus eigenem Antrieb, meist als persönliche Problemlösung, geboren werden:

„Um ein interessantes Problem zu lösen, fängt man mit einem Problem an, das einen selbst interessiert.“⁵²

Aus der Idee, eine Lösung für die individuellen und alltäglichen technischen Probleme zu finden und der breiten Öffentlichkeit zugänglich zu machen, kann sich OSS sehr schnell verbreiten, weil sich das Problem als typisch für eine umfangreiche Klasse von Benutzern herausstellt.⁵³

Zu einem OSS-Projekt gibt es meist eine zentrale Gruppe, die am längsten an der Software und Dokumentation gearbeitet hat, das so genannte „Core Team“: Diese Gruppe entscheidet meist über die allgemeine einzuschlagende Richtung der Implementierung und über das Design. Das Core Team ist so organisiert, dass innerhalb des Projekts Produktbereiche von „Maintainern“ verwaltet werden. Die größte Resonanz erfährt das Projekt einer OSS, wenn vor allem aufgetretene Fehler, Ideen für Funktionserweiterungen und Vorschläge von der internationalen Community⁵⁴ in das Projekt zurückfließen. Standardisierte Projektplattformen (siehe 2.2.2) im Internet sorgen für den optimalen Workflow zwischen dem Core Team und den internationalen Interessierten: Werkzeuge der Kommunikation sind E-Mails, Mailinglisten und Newsgruppen, also die Dienste des Internets.⁵⁵

2.2.2 Argumentation: Pro und Kontra von Open-Source-Lösungen

Henkel stellt die Vor- und Nachteile dar, die einem Unternehmen entstehen, wenn es sich an der Entwicklung von OSS beteiligt, die danach nicht verkauft werden kann, für alle verfügbar ist und sogar von Konkurrenten weiterhin modifizierbar ist.

Ein Nutzen für Firmen, die selber OSS einsetzen, ergibt sich aus der Adaption existierender OSS für die eigenen speziellen Anforderungen. Hierdurch kann zum einen der Anteil aufwändiger Eigenentwicklung reduziert und zum anderen Lizenzkosten vermieden werden, die anfallen, wenn auf proprietäre Software-Bauteile zurückgegriffen werden müsste. Risiken könnten entstehen durch den Verlust von Wettbewerbsvorteilen. Die Gewichtung dieser Gefahr ist nach Henkel von den folgenden Faktoren abhängig: Wettbewerbsgrad, Relation der Software zu der Wettbewerbsdomäne⁵⁶, Verfügbarkeit von substituierbaren Produkten und Grad der Spezifikation der Software für das Unternehmen. Je spezieller die Software auf die Anforderungen einer bestimmten Firma geeicht ist, desto weniger attraktiv ist es für die Konkurrenten, darauf aufbauend Wettbewerbsvorteile zu ziehen. Andererseits gewährt die Firma durch Offenlegung einer sehr firmenspezifischen Software Einblick in den Geschäftsprozess. Für Firmen, die OSS produzieren und nicht nur selber einsetzen, sieht Henkel den Vorteil in der Steigerung des Absatzes durch Verkauf von komplementären, also die OSS ergänzenden Produkten. Ein Motiv zur Förderung von OSS kann auch das Schwächen eines Mitbewerbers⁵⁷ oder die Verringerung von Abhängigkeit zu einem Anbieter sein.⁵⁸

„Durch ihre Unabhängigkeit von Produktzyklen, Marktkonzentration und Insolvenzen bietet die freie Software eine unübertreffliche Sicherheit der getätigten Investitionen in Menschen, Hard- und Software. Die kontinuierliche Entwicklung kann durch immer neue Generationen von Programmierern aufrecht erhalten werden. Die Angst vor der Abhängigkeit von einem einzigen Lieferanten einer Software ist für viele Anwender in Unternehmen und Behörden ein wichtiges Argument für freie Software. Diese schließt Monopolbildung aus und fördert eine lokale Infrastruktur von kleinen und mittelgroßen Dienstleistern.“⁵⁹

Neben den Linux-Distributionen treten die OSS-Produkte vor allem im Server-Bereich proprietären Konkurrenten den Rang ab: Das Open- Source-Web-Server-Projekt „Apache“⁶⁰ war im Mai 2003 Grundlage für 63 % aller weltweiten Web-Auftritte. So hat auch die OSS Sendmail⁶¹, welche den Versand von E-Mails über das Internet ermöglicht, einen Marktanteil von 75 %.⁶² Freie Basisprodukte und Datenbankapplikationen, wie z. B. MySQL⁶³, Open-Source-Skriptsprachen, wie z. B. PHP⁶⁴, und dazu freie Entwicklungswerkzeuge runden das Angebot an OSS für die Internet- und Intranet-Applikationen-Entwicklung ab.

Im Internet, welches das Phänomen der weltweiten Open-Source- Entwicklung erst ermöglicht, gibt es mittlerweile Web-Portale, die sich auf die Unterstützung und Verbreitung von OSS und vor allem auf die Förderung der Community spezialisieren. Beispielsweise bietet das Open- Source-Portal „Sourceforge“⁶⁵ eine komplette Entwickler-Oberfläche für neue und bestehende „Freie Projekte“ an: Release-Management, Bug- Tracking, Foren, Concurrent Version System (CVS) und Repository- Unterstützung, eine Homepage sowie die Dokumentationsverwaltung gehören zu den wiederum kostenlosen Standardoptionen für Entwickler, die sich dem Open-Source-Modell anschließen möchten. Weitere Plattformen wie Freshmeat⁶⁶ oder OSTG⁶⁷ motivieren Besucher, ihre eigenen Ideen in Form von Freier Software als Projekt anzulegen und nach interessierten Mitentwicklern zu suchen.

Durch das stark wachsende Angebot an OSS in jedem Anwendungsbereich können umfangreiche Suchabfragen auf den angesprochenen Portalen gestartet werden, die Projekte nach Aktivität, Entwicklungsplattform und Programmiersprachen sortieren. So kann je nach Bedarf und Implementierungsphilosophie nach Software gesucht werden, um z. B. Synergien mit vorhandenen Tools zu nutzen. Redaktionell erarbeitete Bewertungen von Open-Source-Werkzeugen, wie z. B. von Vepstas, fordern inzwischen die Entwicklergemeinde auf, die Flut von vielen kleinen, nicht endgültig bis zur Produktionsreife gebrachten Projekten zu vermeiden und stattdessen die bestehende OSS noch weiter zu verfeinern sowie die Qualität zu verbessern.⁶⁸

Der klare Vorteil gegenüber proprietärer Software ist die Tatsache, dass weltweit Entwickler für die Fehlerfreiheit und für die Qualität der OSS kostenlos und aus eigenem Antrieb sorgen:

„Die Stabilität dieser Software, d. h. ihr Grad an Fehlerfreiheit, verdankt sich nicht der Genialität ihrer Entwickler, sondern der Tatsache, dass jeder Anwender Fehler an den Pranger stellen kann und die kollektive Intelligenz von Hunderten von Entwicklern meist sehr schnell eine Lösung dafür findet.“⁶⁹

Mantz geht auf die rechtlichen Konsequenzen, die Vorteile und Risiken von Open-Source-Lizenzen ein: Ein Nutzer von Open Source Software geht nach dem deutschen Recht einen Schenkungsvertrag unter einer Bedingung mit dem Urheber des Werkes ein.⁷⁰ Wenn die GPL vom Nutzer bereits bei der Installation oder beim Start des jeweiligen Programms zur Kenntnis genommen wird, gilt diese als Vertragsbestandteil in Form Allgemeiner Geschäftsbedingungen:

„Die GPL stellt einen urheberrechtlichen Nutzungsvertrag dar, der auch Regelungen bezüglich Gewährleistung und Haftung enthält. Die GPL ist demzufolge eine Sammlung vorformulierter Vertragsbedingungen, ihre Bestimmungen sind nach deutschem Recht Allgemeine Geschäftsbedingungen.“⁷¹

Ferner muss sichergestellt sein, dass auf die Lizenz hingewiesen wird und diese in elektronischer Form der Software beiliegt. Die abgefasste Sprache der Lizenz ist bei der GPL in Englisch; allerdings gibt es Übersetzungen in viele andere Sprachen: Ist die OSS nicht nur für den deutschen Markt bestimmt, wovon bei dem grundsätzlich mehrsprachigen internationalen Internet ausgegangen werden kann, gilt eine englische Lizenz als zumutbar.⁷² Mantz ist der Ansicht, dass die GPL teilweise nicht mit dem deutschen Urheberrecht und den Allgemeinen Geschäfts- bedingungen vereinbar ist; die grundlegenden Gedanken der Lizenz sind jedoch auch in Deutschland als verbindlich anzusehen: Für Bereiche, in denen die Bestimmungen der GPL nicht wirksam sind, greift allerdings deutsches Recht. Somit ist die Verwendung der GPL für OSS in Deutschland geeignet.⁷³

„Die General Public License (GPL) hat laut Gerichtsbeschluss auch in Deutschland Gültigkeit. […] Sie kann daher auch mit verbindlicher Wirkung in Softwarenutzungsverträge einbezogen werden.“⁷⁴

Für Schenkungen gilt nach deutschem Recht nicht der generelle Gewährleistungsausschluss, wie von der GPL statuiert; Schadensersatz- ansprüche können nur geltend gemacht werden, sofern diese vom Autor arglistig verschwiegen werden, was bei OSS sehr unwahrscheinlich ist, da bei diesem Lizenzmodell gerade versucht wird, potenziell schädliche Funktionen im Ansatz zu vermeiden. Ebenso kann Haftungsausschluss nur auf Vorsatz oder grobe Fahrlässigkeit reduziert werden.⁷⁵

Auf der anderen Seite stellt Mantz die Situation des Urhebers dar, falls ein Nutzer gegen die Bestimmungen der unter die GPL gestellten Programme verstößt: Wird ein nach deutschem Recht wirksamer Punkt der GPL durch einen Nutzer nicht beachtet, so erlöschen alle Wirkungen, die vorher von der GPL gewährt worden sind (siehe 2.2.1, S. 29). Folglich stellen die weitere Nutzung, die Weitergabe und Modifikation der Software internationale Urheberrechtsverletzungen dar und werden rechtlich verfolgbar. Gleiches gilt, falls ein Nutzer alle Hinweise auf die ursprüngliche Lizenz entfernt, diese Software dann weitergibt oder verkauft: Seine Nutzungsrechte sind erloschen und können somit auch nicht weitergegeben werden. Der Empfänger einer solchen Software läuft Gefahr, rechtlich belangt zu werden.⁷⁶

„Open Source Software ist nicht nur eine ernst zu nehmende Alternative zu kommerziellen Produkten. Sie ist oftmals mindestens gleichwertig, teilweise sogar überlegen. Zudem steht hinter Open Source Software eine Philosophie, die immer breitere Anerkennung und Verbreitung findet und dem Benutzer kostengünstige Möglichkeiten eröffnet. Open Source Software ist auch im deutschen Rechtssystem verankerbar und fügt sich in die deutschen Rechtskategorien ein. Anwender und Autoren finden in der GPL, in Bereichen, in denen die GPL unwirksam ist im deutschen Recht, klare Regelungen, die es ihnen ermöglichen, ihre Situation und Handlungsmöglichkeiten sowie die Konsequenzen einzuschätzen.“⁷⁷

Grassmuck stellt eine weitere Eigenschaft Freier Software heraus: OSS wird heute nicht als Produkt, sondern - ebenso wie ITIL - als kontinuierlicher Prozess verstanden:

„Zahlreiche Projekte haben bewiesen, dass eine Entwicklergemeinschaft ihre Software über lange Zeit zuverlässig und in hoher Qualität unterstützen und weiterentwickeln kann. In der amerikanischen Debatte ist von einer »evolutionären« Softwaregenese durch Mutation, Selektion und Vererbung die Rede. Der »Basar« sorge dafür, dass in einem »darwinistischen Selektionsprozess« die bestangepasste und effizienteste Software überlebe.“⁷⁸

Für den Einstieg in eine neue IT-Herausforderung wie z. B. ITIL werden per se hohe Kosten für die Implementierung der Prozesse und die Schulung der Mitarbeiter fällig; um einen effektiven Vorteil bei der Auswahl für Tools rund um die Automation der Einstiegsbereiche zu erlangen, bieten Open-Source-Werkzeuge eine günstige Alternative, um WorkflowOptimierungen und erste Schritte auf neuem Terrain zu machen.⁷⁹

3 Anforderungskriterien an ITIL-Service-Desk- Lösungen

3.1 Anforderungskatalog für Service-Desk-Applikationen

Die Auswahl geeigneter OSS für den Einsatz als Service-Desk- Anwendung lässt sich über einen konkreten Anforderungskatalog mit anschließender Bewertung realisieren: Es werden hauptsächlich Anforderungen aus dem ITIL-Framework, praxisbezogene Kriterien und generelle Anforderungen an die OSS-Projekte gestellt. Wichtigste Voraussetzung ist die nach der OSI⁸⁰ zertifizierte Lizenz⁸¹, unter die ein in die Auswahl gekommenes Software-Werkzeug zwingend gestellt sein muss, damit die Freiheit und Flexibilität der Weiterentwicklung, Modifikation und die nachfolgende Distribution gewährleistet sind. ITIL Software Tools sollen die konkreten ITIL-Prozesse einer Unternehmung unterstützen. Nicht nur für Einstiegsbereiche, wie z. B. im Incident Management, müssen Tools gewährleisten, die ITIL-Sprache⁸² und die ITIL-Prozesse zu beherrschen. Schon 1992 führte das OGC in die ITIL- Bibliothek Anforderungen für ITIL-kompatible Software Tools ein, die bis heute ihre Gültigkeit haben. An dieser Stelle sei auf die weiterführende Literatur „IT Infrastructure Support Tools“ des OGC verwiesen.

Für die Funktion des Service Desk mit dem Prozess Incident Management ergeben sich vor diesem Hintergrund Muss- und Kann-Kriterien, die über eine Auswahl für eine OSS entscheiden. Ziel dieser Auswahl ist ein optimales Open-Source-Projekt, welches die Kriterien für ITIL weitestgehend erfüllt; Anpassungen der Projekte für die volle Unterstützung von ITIL, wenn auch nur für den Bereich „Service Desk“, lassen sich, wie im weiteren Verlauf dieser Arbeit deutlich wird, nicht vermeiden. Daher schließen sich an die allgemeinen Anforderungen ebenfalls praxisorientierte Kriterien an, die in die Auswahl mit einfließen. Auf der Seite der OSS sind Abgrenzungskriterien zu nennen, wie z. B. die Anpassbarkeit der Software, die Erfahrung des Projektteams, der letzte Aktualisierungszeitpunkt, die Anzahl der Programmierer im Core Team, die Unterstützung von mehreren Sprachen, Interoperabilität und Betriebssystemunabhängigkeit.

Im weiteren Verlauf dieser Arbeit soll bewertet werden, inwiefern bestimmte OSS konform mit dem anschließend beschriebenen Anforderungskatalog sind. Unter „konform“ ist hier die Fähigkeit eines Tools gemeint, in der ausgelieferten Basis-Konfiguration bzw. BasisVersion die Prozesse und Anforderungen des ITIL-Rahmenwerks sowie der ergänzenden allgemeinen Kriterien des nachfolgend erarbeiteten Katalogs einwandfrei abzubilden.

3.1.1 Allgemeine Anforderungen aus ITIL

Die Anforderungen an ein Software Tool zur Automatisierung des ITIL Service Desk richten sich weitgehend nach den Vorgaben aus dem ITIL- Framework⁸³: Auf der einen Seite muss der Service Desk Workflow (siehe 2.1.2, S. 21) von der Software unterstützt werden, als auch auf der anderen Seite das ITIL-Wording für die Akzeptanz und Sicherstellung der Verwendbarkeit des Tools nach dem offiziellen „Glossary of ITIL terms“⁸⁴.

Damit eine Service-Desk-Applikation den Prozess des Incident Management nach ITIL erfüllen kann, stellt das OGC eine Reihe von Kriterien auf, die über die Güte und den Erfüllungsgrad einer Software nach ITIL entscheiden:

Ein automatisiertes Tool für das Incident Management muss gewährleisten, dass Incident-Records bzw. Incident-Tickets erstellt, modifiziert und gelöscht werden können. Dabei erhält jeder Zwischenfall eine eindeutige, fortschreibende Nummer, z. B. INC-1, INC-2 usw., um den Incident-Record etwa bei einem Anruf eines Kunden sofort wieder zu finden und bearbeiten zu können. Damit die ITIL-Prozesse Incident, Problem und Change Management exakt separiert werden können, ist es erforderlich, die Datensätze auch physikalisch voneinander zu trennen, damit die unterschiedlichen Prozesse nicht durcheinander geworfen werden. Incident-Records enthalten wichtige Daten⁸⁵ zu einem Zwischenfall für das Incident Management, wie z. B. die Priorität, die Kategorie, den Status und die Version; außerdem enthalten diese Datensätze eine Reihe von Informationen, die eine Verknüpfung zur IT- Landschaft, zu den CIs über die CMDB gewährleisten, wie z. B. die Verweise auf den betreffenden User-Account und die betroffene Hard- und Software. Für eine Integration des Problem und Change Management können Störungs-Tickets auch zu Problem-Records und Requests for Change (RFC) verlinkt werden. Um die Behebung von Störungen im Rahmen der SLA’s zu gewährleisten, müssen Incident-Records durch die Software automatisch zur Eskalation gebracht werden: Der Incident Manager und die verantwortlichen Service-Desk-Mitarbeiter werden über die Nichteinhaltung von bestimmbaren Toleranzgrenzen in Bezug auf die zeitnahe Lösung von Störungen, z. B. über E-Mail, informiert.

Um das von ITIL geforderte Berichtswesen zu automatisieren, sollte ein flexibles Reporting in den Tools integriert sein: Reports für Aufzeichnungen von Incidents aus der Vergangenheit sowie die Analyse von Trends sollten möglich sein. Für eine Auflistung aller bereits geschlossenen oder noch ausstehenden Incident-Datensätze sind weiterhin umfangreiche Suchfunktionen erforderlich; von der Software sollte die Verknüpfung von Incident-Records mit den so genannten Closure Codes⁸⁶ möglich sein, um die Behebung eines Zwischenfalls zu spezifizieren.

Die funktionalen Anforderungen für ITIL-konforme Software-Lösungen im Incident Management gewährleisten, dass der Incident Management Workflow durch Automation für die Benutzer erleichtert und verbessert wird: Bei kritischen Zwischenfällen sollte es möglich sein, mehrere Empfänger hiervon in Kenntnis zu setzen und diese der Störung als Verantwortliche zuzuordnen. Für den allgemeinen Informationsfluss ist es wichtig, dass betroffene Kunden, z. B. über eine Intranetseite, den Status ihrer selbst gemeldeten Zwischenfälle einsehen können.

Die Automation bei der Klassifikation von Incidents im Service Desk ist von Tools derart zu unterstützen, dass bestimmbare Kategorien die automatische Priorisierung und Eskalation von Incident-Tickets vorgeben: So können Tickets aufgrund definierter Relationen zwischen Geschäftsauswirkung, Dringlichkeit, Priorität⁸⁷ und Kategorien automatisch klassifiziert werden.

Eine Steigerung des Anteils von sofort beantworteten Fragen im Service Desk wird durch die Einbindung der Erfahrungsdatenbank als Teil der CMDB realisiert: In der Wissensdatenbank ist es möglich, auf vorhandene Standardlösungen zurückzugreifen sowie neue Work-arounds, Lösungen und Dokumentationen hinzuzufügen.

Um den Workflow bei sofort beantworteten Fragen zu beschleunigen, soll die Software den Abschluss von Incident-Datensätzen kurz nach deren Aufnahme ermöglichen.

Neben Verknüpfungsmöglichkeiten von CIs sollten auch Tickets untereinander verlinkt werden können, um Parallelen zu dokumentieren.

3.1.2 Allgemeine Anforderungen an OSS-Projekte

Besondere Kriterien für OSS ergeben sich durch das sehr spezielle (siehe 2.2.1) Lizenzierungskonzept: Zwingend erforderlich muss die recherchierte Software unter eine gültige Open-Source-Lizenz gestellt sein. Als exemplarisches Beispiel wird in dieser Arbeit (siehe 2.2.1, S. 29) die GPL vorgestellt; eine Liste von kompatiblen Open-Source-Lizenzen aktualisiert und verabschiedet die OSI-Organisation.⁸⁸

Für Open-Source-Projekte gelten ebenfalls folgende Anforderungen als Gütekriterien: Erfahrung⁸⁹ und Anzahl der Projektteilnehmer, Lebenszyklus, letzte Aktualisierung⁹⁰ und Projektplattform (siehe 2.2.2, S. 32).

Aus diesen Kriterien lassen sich Aussagen über die Unterstützung von Mehrsprachigkeit, Interoperabilität und Betriebssystemunabhängigkeit ableiten. Von der Projektplattform lassen sich über die Projekt-Homepage Informationen und Statistiken abrufen, wie z. B. die quantitativen Downloads und Seitenabrufe der jeweiligen Projekte, Informationen über jeden Entwickler, Programmiersprachen und unterstützte Betriebs- systeme.

Über die Reaktionszeit bzw. Behebungszeit auf eine eingestellte Frage oder einen Fehlerbericht kann die Support-Fähigkeit des Projekts geprüft werden. An dem Downloadverhalten und der Revisionskennung der Software lassen sich nicht getestete Versionen von stabilen Versionen unterscheiden.

Für die Auswahl eines konkreten Open-Source-Projekts stellen sich weiterhin folgende unternehmensspezifische Anforderungen: Die Service Desk Software muss auf Basis-Komponenten⁹¹ aufbauen, die sehr weit verbreitet sind, die eine breite Entwicklergemeinde haben und sehr einfach an die Organisation angepasst werden können bzw. schon vorhandene Technologien, wie z. B.: proprietäre Datenbanken von Oracle oder Active Directory® von Microsoft, nutzen können.

3.1.3 Anforderungen aus der Praxis

Praxis-Anforderungen für Service Desk Software werden hauptsächlich aufgrund der Unternehmensgröße gestellt: In dieser Arbeit werden exemplarisch die Anforderungen von kleinen Unternehmen bis zu 1000 Mitarbeitern vorgestellt (siehe 2.1.3, S. 27), da es hier durchaus Sinn macht, mit frei ladbaren Tools aus dem Internet eine Automatisierung des Service Desk zu erreichen.⁹²

Nach Rovers ist es aus der Sicht der Organisation wichtig, dass ein Service Desk Tool nicht etwa den Ablauf des Incident-Management- Prozesses diktiert, sondern auch den eigenen Workflow abbilden kann: Die Software sollte sich ohne Probleme in die organisatorische Landschaft einbinden lassen, da jedes Unternehmen eigene Eskalationsprozeduren, Benachrichtigungsregeln und Genehmigungsverfahren bereitstellt.

Auf der Seite der IT-Technologien werden vielfach schon existierende Tools⁹³ benutzt, um Daten über die IT-Ressourcen und die Eigenschaften von Nutzer-Accounts zu erfassen, wie z. B. der Standort und der Raum eines Druckers und wem oder welcher Gruppe von Nutzern dieser zugeordnet ist; eine Service-Desk-Applikation muss in der Lage sein, diese Synergien zu nutzen, um den Datenaustausch zwischen verschiedenen Systemen zu gewährleisten, automatisch Meldungen von intelligenten IT-Netzwerk-Ressourcen⁹⁴ einzubinden, Wissensaufbau aus schon vorhandenen Wissensdatenbanken zu erleichtern oder zu nutzen.⁹⁵

Allgemeine Anforderungen an Software schließen die Konformität zu internationalen Standards, die Flexibilität bei der Implementierung, die Nutzbarkeit und Nützlichkeit der Anwendung sowie die zentrale Datenspeicherung ein. Sicherungsmaßnahmen wie die Authentifizierung von Nutzern des Service Desk Tool sowie die Möglichkeit, alle Daten zu sichern, müssen integriert sein.

Die ausgewählte Software sollte auf Basis-Technologien aufbauen, deren Benutzerschnittstellen hauptsächlich per Web-Browser bereitgestellt werden, um mehrere verschiedene unabhängige Systeme abzulösen. Hieraus ergibt sich der Vorteil, dass eine Anwendung größere Flexibilität erreicht und schneller über die gesamte Organisation ausgerollt werden kann mit zugleich geringeren Kosten. Die Verwendung der Web- Technologie schließt ebenfalls die allgemeinen Standards der Hypertext Markup Language (HTML) ein, wie z. B. die Unterstützung von Hyperlinks oder Anhänge und Anlagen, wie z. B. bei E-Mail-Programmen üblich.⁹⁶

Da hier exemplarisch Tools für die Eignung zu ITIL Service Desk gesucht werden, kommen für die Recherche nur Anwendungen infrage, die sich rund um das Thema „Help Desk und Projektmanagement“ ansiedeln.

3.1.4 Erstellung des Anforderungskatalogs

3.1.4.1 Methodik

Der konkrete Anforderungskatalog setzt sich aus den Anforderungs- kriterien der vorangehenden Punkte zusammen. Die Methodik stellt dar, wie die Anforderungen in einen auswertbaren Katalog überführt werden können und wie die Bewertungskriterien für ein konkretes Tool aussehen.

Da das ITIL-Framework an die Bewertungen die Bedingung knüpft, dass 80 %⁹⁷ aller funktionalen Kriterien erfüllt werden müssen, damit ein Tool weitestgehend geeignet ist, um im ITIL-Bereich Prozesse automatisieren zu können, sind die Bewertungen der parallelen, jedoch prinzipiell untergeordneten Anforderungen, wie die speziellen Kriterien für Organisation (siehe 3.1.3), genauso zu bewerten. Insgesamt reicht also ein naiver Katalog aus, der alle Kriterien auflistet und eine Bewertung über Erfüllung oder Nichterfüllung zulässt. Wenn demnach ein infrage gekommenes Tool in die engere Auswahl kommt, müssten 80 % der Kriterien für einen endgültigen Einsatz erfüllt werden. Für eine spätere Implementierung wären infolgedessen die Kriterien schon selektiert, die gegen Aufwand zusätzlich programmiert werden müssten. Durch die Evaluation eine Software ausfindig zu machen, die alle vorgeschriebenen Kriterien der ITIL-Bibliothek erfüllt, ist nicht zu erwarten, da diese OSS vollständig nach ITIL entwickelt sein müsste: Stichproben und die Recherche nach Tools, die explizit als ITIL und Open Source ausgewiesen waren, werden jedoch ebenfalls bewertet.

3.1.4.2 Aufbau

Der Kriterienkatalog ist in Tabellenform angelegt und enthält alle Kriterien der Anforderungsanalyse bis zu einem noch einfach evaluierbaren Detaillierungsgrad⁹⁸, da mehrere Projekte bewertet werden sollen. Zuerst werden die Kriterien zu ITIL, danach jene zu OSS und zum Schluss jene der Praxisanforderungen genannt. Der Aufbau eines Kriteriums sei an dieser Stelle (siehe Tabelle 1) exemplarisch für die Anforderungen an einen Incident-Datensatz und einer Lösungsaktion aufgeführt:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Einfacher Anforderungskatalog

Erfüllt ein Programm die Vielzahl, also 80 % der funktionalen Anforderungen eines Kriteriums, so ist automatisch das Hauptkriterium erfüllt. Die Evaluation der Kriterien erfolgt mit der gleichen Formel für die Unterkriterien: Im Beispiel (siehe Tabelle 1) werden alle Unterkriterien des Kriteriums „Incident-Aktion-Datensatz“ erfüllt. Daher sind mindestens 80 %, hier 100 %, aller Unterkriterien, wie z. B. die Eingabemöglichkeit eines Service-Spezialisten, der die Aktion eingeleitet hat, erfüllt worden.

In den vorangegangenen Ausführungen wurden ergänzend bestimmte Ausschlusskriterien (K.O.-Kriterien) formuliert, die bei Nichterfüllung zur Folge haben, dass betreffende Programme nicht weiter evaluiert werden und als nicht anforderungskatalog-konform ausscheiden. Ein solches Kriterium ist z. B. die zwingende Open-Source-Lizenz und die mindestens entfernte Verwandtschaft der OSS zu Projektmanagement- oder Help- Desk-Anwendungen. Die schlussendliche Bewertung erfolgt dann über diese K.O.-Kriterien, wobei die Erfüllung von mindestens 80 % der Hauptkriterien als weiteres Ausschlusskriterium aufgenommen wird.

3.1.4.3 Zusammenfassung

Da der hier erarbeitete Anforderungskatalog auf OSS angewendet werden soll, ist an dieser Stelle zu kritisieren, dass hier die „eierlegende Wollmilchsau“ gesucht werden soll: Im Grunde ist die Recherche danach ausgelegt, ein Produkt zu finden, welches schon nach ITIL implementiert worden ist, somit die Prozesse sowie das „Wording“ nach ITIL voll unterstützt und dabei praktisch keine Anschaffungskosten anfallen. Im weiteren Verlauf dieser Arbeit wird sich zeigen, ob es überhaupt veröffentlichte Tools im Internet gibt, die alle Anforderungen zu 100 % erfüllen. Eventuell müssen Abstriche in gewissen Bereichen gemacht werden, die dann in Form von Implementierungsanforderungen in 4.2.5 Einzug nehmen. Auf den vollständigen Kriterienkatalog sei im Anhang (siehe 7, S. 128) verwiesen.

3.2 Analyse verschiedener Open-Source-Produkte anhand des Anforderungskatalogs

Die Analyse von OSS erfolgt nach einem bestimmten Vorgehensmodell, welches sich zeitsparend und effektiv umsetzen lässt: Auf der Suche nach geeigneter OSS werden zuerst mögliche Basis-Technologien aus dem Open-Source-Sektor geprüft, ob diese einfachen Anforderungskriterien genügen. Die eigentlich zu recherchierenden Anwendungen für den ITIL Service Desk haben die Anforderung, über Web-Browser-Technologien benutzbar zu sein und sind deshalb auf Basis-Technologien angewiesen, wie z. B. Web-Server, Datenbanken und Programmiersprachen für das Internet⁹⁹. Das Vorgehensmodell soll geeignete Basis-Technologien bzw. Projektplattformen herausarbeiten, die im Bereich des ITIL Incident Management eingesetzt werden können, um darauf aufsetzende OSS- Tools zu testen und zu evaluieren. Damit das komplette Rahmenwerk rund um den automatisierten ITIL Service Desk als Open-Source-Lösung betrachtet werden kann, sind Betriebssystem, Basis-Technologien und letztendlich auch das eigentliche Tool unter den Open-Source-Projekten zu suchen.

3.2.1 Auswahl der Projektplattformen

Die Auswahl der Projektplattformen richtet sich nach mehreren Anforderungen, die nachfolgend beschrieben werden: Die Basis- Technologien wie Web-Server, Datenbank und Programmiersprachen sollen auf einem Open-Source-Betriebssystem, wie z. B. Debian Linux¹⁰⁰, eingesetzt werden können und möglichst auch schon bei der Standardinstallation des Betriebssystems enthalten sein. Die Projektplattformen müssen ebenfalls als OSS freigegeben sein und in stabilen Versionen herunterladbar sein. Die Installation, Wartung und das Verhalten der Basis-Technologien muss den Anforderungen an Software der internationalen Standards entsprechen und Sicherheiten wie Authentifizierung und Stabilität bieten. Weiterhin sollte es eine breite Entwicklergemeinschaft geben, die aufsetzend auf diesen Technologien OSS implementiert und verbreitet. Exemplarisch werden in dieser Arbeit zwei Projektplattformen ausgewählt, die den Standardinstallationen des Debian-Linux-Betriebssystems beiliegen und weit verbreitet sind.¹⁰¹

3.2.1.1 Zope

Zope¹⁰² ist eine Web-Server-Technologie, die einen auf Python¹⁰³ basierenden Applikations-Server bereitstellt. Diese Projektplattform ist sehr umfangreich und erfreut sich hoher Popularität im Web-Server- Bereich, z. B. für Homepages und Web-Applikationen auf Python-Basis. Dabei ist Python eine vollwertige Programmier- und Skriptsprache, die Programmierer wegen ihrer schnellen Prototyping¹⁰⁴ -Eigenschaften bevorzugen. Als eigentlicher Web-Server-Prozess greift Zope auf Medusa¹⁰⁵ Information Server zurück, der ebenfalls seit Mai 2000 zu OSS gehört. Zope steht unter der Zope Public License (ZPL), die als Open- Source-Lizenz zertifiziert ist und als kompatibel zur GPL angesehen wird.¹⁰⁶ Zope verfügt über eine eigenständige Datenbank, die bei Bedarf über spezielle Python-Schnittstellen durch andere verbreitete Datenbanksysteme substituiert werden kann.

3.2.1.2 PHP: Hypertext Preprocessor (PHP)

PHP ist ein universeller Applikations-Server mit einer auf C/C++ basierten Skriptsprache. PHP ist der Urvater aller Applikations-Server mit der meisten Popularität und einer der größten Entwicklergemeinden.¹⁰⁷ Als Web-Server-Technologie lassen sich sehr viele Produkte zusammen mit PHP nutzen, wie z. B. der Open-Source-Web-Server „Apache“¹⁰⁸. Apache selbst ist der populärste Web-Server im Internet; das Apache-Projekt ist dabei stets angehalten, eine hohe Qualität und Stabilität ähnlich wie bei kommerziellen Anwendungen zu gewährleisten.

PHP ist unter der „PHP Licence“ veröffentlicht, die ebenfalls eine gültige Open-Source-Lizenz ist.¹⁰⁹

3.2.2 Recherche infrage kommender OSS

Als Grundlage für die Recherche von geeigenten Open-Source- Werkzeugen werden die Basis-Technologien aus 3.2.1 ausgewählt, um die Suche effektiv einzuschränken. Als weitere Hilfestellung dienen die Open-Source-Portale (siehe 2.2.2, S. 32) für die Suche nach entsprechenden Tools. Außerdem lassen sich bereits erarbeitete Referenzlisten aus dem Internet, wie z. B. die von Vepstas¹¹⁰ oder Portalux¹¹¹, für eine erste Auswahl heranziehen. Die Recherche wird also über die konkrete Projektplattform bis zur Klassifikation des Tools durchgeführt.

3.2.2.1 Recherche nach Anwendungen auf der Basis von Zope

Für Zope kommen nach Vepstas die Produkte „Tracker“, „KnowledgeKit“, „OpenTicket“ und „Xen“ infrage.¹¹² Die eigene Recherche über Sourceforge brachte noch das interessante „f2w Helpdesk Project“ als Zope-Applikation hervor. Die genannten Lösungen sollen im Folgenden kurz vorgestellt werden.

3.2.2.1.1 Tracker

Tracker¹¹³ ist ein einfaches Fehlerverfolgungssystem für Programmfehler und wird lediglich durch einen Entwickler betreut. Das Herunterladen des Quellcodes ist insofern problematisch, als dass die Online-Ressource für das Herunterladen des Projekts nur sehr schwer auffindbar ist. Die letzte Änderung geht auf einen Eintrag im Februar 2000 zurück, was die Applikation für die anschließende Bewertung ausschließt.

3.2.2.1.2 KnowledgeKit

KnowledgeKit¹¹⁴ ist eine selbstständige Erweiterung zu Zope, die aus einem Frequently Asked Questions(FAQ)-Modul und einer Wissens- datenbank besteht. Die letzte Revision 1.6.7 steht seit dem 9. Dezember 1999 zum Download bereit. Das System ist als eigenständiges Modul zu sehen ohne Integrationsmöglichkeiten zu einem Service-Desk-System. Aufgrund des Alters lässt sich diese Anwendung von der weiteren Bewertung ausschließen.

3.2.2.1.3 OpenTicket

OpenTicket¹¹⁵ stellt sich selbst als ITIL Help Desk Tool vor: Die Anwendung soll auf Zope aufsetzen und Basis-Funktionalitäten für das Incident Management bieten. Sogar Berichtsfunktionen sollen integriert sein. Optional können Prioritäten und Status-Optionen frei konfiguriert werden. Der Download gestaltet sich sehr einfach, jedoch wird sofort offensichtlich, dass es sich nicht um eine Zope-Anwendung handeln kann, da alle Projektdateien auf „.php“ enden. Diese Anwendung wird aufgrund der hier verwendeten Vorgehensweise weiter unten bei den PHP- Anwendungen noch einmal aufgeführt.

3.2.2.1.4 Xen

Xen¹¹⁶ ist ein sehr junges und funktionsreiches Projektmanagement- System auf der Basis von Zope, welches die Bereiche Aufgaben- und Incident-Ticket-Management, Kontakt-Verwaltung und Berichterstattung abdeckt. Die ursprünglich initiierende Firma existiert nicht mehr; die Quellen sind jedoch unter einer kompatiblen Open-Source-Lizenz veröffentlicht worden. Da es aus diesem Grunde keine aktiven Entwickler und keinen Support für diese Applikation mehr gibt, ist Xen von den Bewertungen auszuschließen.

3.2.2.1.5 Free2Work (f2w) Helpdesk Project

Das Free2Work Helpdesk Project¹¹⁷ ist eine Anwendung für den Zope- Applikations-Server, die per Voreinstellung über eine PostgreSQL- Datenanbindung¹¹⁸ verfügt. Optional können beliebige, zu Zope kompatible Datenbanken verwendet werden. Auf die Schnittstelle zu MySQL wird explizit verwiesen. Der Veröffentlichungstermin des letzten stabilen Releases geht auf ein Datum im September 2003 zurück. Aktuelle Verbesserungen schließen sich an. Vorteilhaft sind die integrierte Wissensdatenbank und die Verfügbarkeit der Anwendung in vielen Sprachen.

3.2.2.2 Recherche nach Anwendungen auf der Basis von PHP

Für PHP kommen nach Vepstas z. B. die Produkte „Double Choco Latte“ und „IRM“ infrage¹¹⁹. Die eigene Recherche über Sourceforge brachte weitere Anwendungen, wie z. B. „DotProject“, „Help Center Live“, „Issue Tracker“, „SITR“ und „Open-ITIL“, hervor. Der erste Eindruck soll im Folgenden beispielhaft vermittelt werden.

3.2.2.2.1 Double Choco Latte (DCL)

Double Choco Latte¹²⁰ ist eine auf PHP basierte Anwendung, die ein Projekt-Management-Modul, ein Ticket- und Aufgaben-Management- Modul und eine Kontaktverwaltung bietet. Der modulare Aufbau wird durch die eigene Datenbank-Abstraktion zu gängigen Datenbanken unterstützt. Die letzte Version 0.9.4.2 ist seit Januar 2004 veröffentlicht und befindet sich noch in der endgültigen Testphase, der so genannten „Beta-Phase“. Die aktuelle Version geht aus der letzten stabilen Version 0.9.4 hervor; aktuelle Erweiterungen werden über das CVS-System allen Interessierten zur Verfügung gestellt. DCL steht unter der GPL-Lizenz. Vorteilhaft gegenüber anderen Lösungen ist der integrierte E-Mail-Gateway, der ankommende Anfragen per E-Mail automatisch klassifiziert und in die Datenbank schreibt. So können auch automatische Warnmeldungen, wie z. B. von Netzwerk-Komponenten oder Anti-Viren-Software, bereits in der Standardversion verarbeitet werden. DCL wird mit acht verschiedenen Sprachen ausgeliefert und lässt sich einfach über sechs Oberflächen- Designs an den eigenen Geschmack oder an bereits bestehende Anwendungen anpassen. DCL bietet zudem eine Online-Demonstration auf der Homepage an, um die Applikation vor dem Download auszutesten. Das Projekt besteht aus einem Hauptentwickler und etwa sechs involvierten Nebenentwicklern. Außerdem gibt es Maintainer für die Bereiche „Dokumentation“ und „Übersetzung“ des Projekts. Eine Datenbank für FAQ ist in der Basis-Version integriert.

3.2.2.2.2 Information Ressource Manager (IRM)

IRM¹²¹ ist eine PHP-Anwendung, die speziell das Configuration Management unterstützt. Die Verwaltung und Auswertung aller IT- Ressourcen steht im Vordergrund bei dieser auf der GPL-Lizenz veröffentlichten Applikation. Die Unterstützung und Einbindung von Lightweight Directory Access Protocol(LDAP)-Verzeichnissen¹²² und die Berichtsfunktionen über die Lizenzanzahl im Unternehmen sind Vorteile; die fehlende Integration der Service-Desk-Aktivitäten macht IRM jedoch nur zu einem möglichen Ergänzungsprodukt zu einer ITIL-Service-Desk- Anwendung.

3.2.2.2.3 DotProject

DotProject¹²³ ist ein Projekt-Management-Werkzeug für PHP. Auffällig ist hier die ansprechend entworfene Oberfläche der Web-Applikation, die als Demo-Version bereits vor dem Download begutachtet werden kann. Der Fokus von DotProject liegt klar bei der Unterstützung bestehender und neuer Projekte aller Art; ein einfaches Ticket-Management-Modul ist auch hier integriert. Die aktuelle Version 1.0.2-1 steht seit März 2004 zum Download bereit und ist stabil. Außergewöhnlich gut ist in diesem Feld der Anwendungen die Unterstützung von grafischen Projektverlaufsplänen. Ein E-Mail-Gateway für die automatische Annahme von Tickets ist ebenfalls integriert. Für DotProject wird daher eine Bewertung durchgeführt.

3.2.2.2.4 Help Center Live

Help Center Live¹²⁴ ist ein rein englischsprachiges Online-Werkzeug, das auf die Lösung von Problemen in Echtzeit spezialisiert ist. Unter anderem werden Module für Live-Chats und Video-Konferenzen integriert. Da dieses Produkt in der Version 1.1 P1 über lediglich einen Entwickler verfügt und im Grunde nur die Echtzeit-Behebung von Tickets unterstützt, fließt das Help Center Live nicht als Vollprodukt in die Bewertung mit ein, sondern höchstens als interessante Ergänzung zu einer anderen Anwendung.

3.2.2.2.5 Issue Tracker, OpenTicket und Open-ITIL

Issue Tracker¹²⁵, OpenTicket (siehe 3.2.2.1.3) und Open-ITIL¹²⁶ sind einfache Ticketverfolgungs-Werkzeuge mit wenigen Details. Meist handelt es sich um einzelne Programmierer, die aufgrund eigener Bedürfnisse ein lauffähiges Programm entwickelt haben. Da bei diesen Produkten schon von Anfang an klar ist, dass hier wichtige Integrationsschnittstellen, wie z. B. das Configuration Management und die Wissensbasis, nicht angedacht sind, wird von der Bewertung abgesehen. Gerade bei dem selbst ernannten ITIL Helpdesk Tool OpenTicket sind offensichtlich nur wenige ITIL-Anforderungen in die Implementierung eingegangen. Bei Open-ITIL in der Version 0.1 vom April 2004 wird man nach den theoretischen Ausführungen des organisierenden Beratungs- unternehmens Webhuis¹²⁷ ein ausgereiftes Tool nach ITIL-Standards erwarten und findet nach dem Download ein doch sehr rudimentäres Tool aus acht Quelldateien. Von akribischen Bewertungen dieses Tools wird daher abgesehen.

3.2.2.2.6 Support Information Tracker (SITR)

SITR¹²⁸ ist eine einfache Wissensdatenbank mit Support-Anfragen- Verwaltung auf der Basis von PHP. Ein Entwickler ist an der Version 2.0.4 vom November 2003 maßgeblich beteiligt. Positiv fallen bei SITR Revisionstechniken und Freigabeverfahren für Dokumente in der Wissensdatenbank auf. Die Übersetzung der Oberfläche ist über eine einfache Datenbankabfrage für jeden Interessierten aus dem Englischen möglich. Da das Ticket-System den Anforderungen an ITIL schon auf den ersten Blick in die Demo-Version nicht genügt, ist SITR jedoch von der Einfachheit und Funktionalität für eine Integration in ein bestehendes Incident-Management-Werkzeug als Wissensdatenbank für gelöste Probleme, Work-arounds und Zwischenfälle geeignet. SITR wird wegen der Schwächen im Incident-Management-Bereich nicht bewertet.

3.2.3 Evaluation

Für die Evaluation der in 3.2.2 aufgeführten Open-Source-Werkzeuge werden nur die überhaupt infrage kommenden Applikationen auf Basis des Anforderungskatalogs bewertet. Von den recherchierten Projekten kommen auf der Basis des Zope-Web-Applikationen-Servers unter den angemerkten Ausschlusskriterien nur die Version 1.5.1 des f2w Helpdesk Project in die Bewertungsauswahl und auf der Basis des PHP- Applikations-Rahmenwerkes die Versionen 0.9.4.2 von DCL und 1.0.2-1 von DotProject. Die Bewertung der angesprochenen Projekte wird über die Installation in einer Testumgebung anhand von Beispielfällen durchgeführt. Die K.O.-Kriterien des Anforderungskatalogs (siehe 3.1.4.2, S. 44) werden durch die Recherche in 3.2.2 schon weitestgehend durch die oben genannten Projekte erfüllt. Für die Bewertung des Engagements der Open-Source-Projekte selbst wird jeweils ein fiktiver Installationsfehler an die betreffenden Foren eingestellt. Die bewerteten Evaluationskataloge sind auf der beiliegenden CD-ROM zu finden.

3.2.3.1 Aufbau der Testumgebung

Die Testumgebung für die Evaluation der bestimmten Projekte wird auf einer virtuellen Maschine¹²⁹ mit einer Test-Version von VMWare®¹³⁰ erstellt. Grundlage ist die aktuelle Debian Linux Distribution¹³¹, die bereits erforderliche Basis-Technologien für beide Arten von Projekten in der Standard-Installation bereitstellt. Für das Zope-Projekt „f2w Helpdesk“ wird der Zope-Web-Server auf dem Port 81, für die PHP-Software der Apache Web-Server auf dem Port 80 als Dienst gestartet. Für Zope muss zusätzlich die aktuelle Version von Python und für PHP¹³² das integrierte Modul für Apache¹³³ - mod_php - installiert werden. Als Datenbank- Server stehen sowohl der MySQL-Server als auch ein PostgreSQL-Server unter Debian zur Verfügung.

Nach dem erfolgreichen Aufsatz der Testumgebung kann mit der Evaluation der Projekte begonnen werden.

3.2.3.2 Anwendung des Anforderungskatalogs auf ausgewählte OSS

Das Vorgehen bei der Bewertung der OSS fängt an bei der Beschaffung der erforderlichen Installationspakete von den Projekt-Homepages, geht über das Extrahieren der Pakete in einen lokalen Projektordner auf dem Testsystem und der Einrichtung und Parametrisierung der Anwendung bis hin zur Datenbankanbindung und dem Erstellen der erforderlichen Projekttabellen in der Datenbank.

3.2.3.2.1 f2w Helpdesk Project

Der Download der Version 1.5.1 kann direkt von der Projekt-Homepage¹³⁴ erfolgen und stellt sich als einfach dar. Benötigt werden ein Installationspaket, hier die Datei „f2w-1.5.zexp“, die in verschiedenen Sprachen zur Verfügung steht, die Konfigurationsdatei „config.zexp“ und die Datenbank-Import-Dateien, die sich in dem Archiv „f2w-psql-1.5.tgz“ befinden. Die Installation ist ebenfalls unkompliziert und erfolgt durch eine Kopie der aufgezählten Dateien in das „Import“-Verzeichnis der Zope- Installation. Nach dem Import über das Konfigurations-Modul, das per Voreinstellung unter einer lokalen Web-Adresse¹³⁵ zu erreichen ist, steht das f2w Helpdesk Project ohne weitere Maßnahmen zum Testen bereit. Für die Datenbank-Einrichtung und die Nutzung anderer Datenbanken sei auf die Internetseite¹³⁶ des Projekts verwiesen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Der erste Eindruck des f2w Helpdesk

Der erste Eindruck nach der Installation (siehe Abbildung 7) lässt bereits eine Vielzahl der Anforderungskriterien bewerten.

3.2.3.2.1.1 Bewertung der ITIL-Anforderungen

Auf den ersten Blick sind markante Abweichungen zu den „Glossary of ITIL terms“¹³⁷ zu erkennen: Anstatt „Request“ wird in ITIL z. B. der Begriff „Incident-Record“ oder „Incident-Ticket“ verwendet; statt „Operator“ wird in ITIL der Begriff „Service Support Spezialist“ verwendet. Das liegt entscheidend an der Tatsache, dass der f2w Helpdesk nicht mit der Intension nach ITIL entwickelt wird, sondern allgemeinen Kriterien des Projekt-Managements und der Software-Entwicklung genügen sollte. Daher ist diese Anforderung nicht erfüllt (siehe Tabelle 2).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: f2w Helpdesk und ITIL-Wording

Die Anforderungen an den eigentlichen Incident-Datensatz werden ebenfalls nicht zufrieden stellend erfüllt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: f2w Helpdesk und Incident-Datensätze

In den Anforderungskatalog (siehe Tabelle 3) werden jeweils nur die erkennbaren Felder aus Abbildung 7 als erfüllt übernommen.

Im Anschluss fallen die funktionalen Aspekte nach ITL negativ auf (siehe Tabelle 4).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: f2w Helpdesk bei den funktionalen Aspekten

Im Test können zwar automatisch Prioritäten zu Kategorien festgelegt werden, doch werden keine Relationen zwischen Auswirkung einer Störung auf den Geschäftsbetrieb oder die Dringlichkeit eines Zwischenfalls hergestellt.

Für das Hauptkriterium ITIL sind somit bereits weniger als 80 % der zu erfüllenden Unterkriterien erreicht worden und lassen ITIL als nicht erfüllt in der Bewertung stehen.

3.2.3.2.1.2 Anforderungen an OSS

Die Analyse der OSS-Fähigkeiten des f2w Helpdesk lassen keine Schwächen erkennen, sodass die Evaluation der Praxis-Anforderungen zum schlussendlichen Auswahlkriterium avanciert.

3.2.3.2.1.3 Anforderungen aus der Praxis

Bei der Bewertung der Organisationsanforderungen werden die Dokumentation und die Menüs der Web-Oberfläche herangezogen: Die Software wird ohne Mittel und Wege für eigene Anpassungen der Organisationsbelange ausgeliefert (siehe Tabelle 5).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Unterstützung der Organisation bei f2w Helpdesk

Entscheidende Unzulänglichkeiten lassen sich auch bei der Unterstützung und Integration von IT-Technologien feststellen (siehe Tabelle 6).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Anforderungen an die IT-Technologie des f2w Helpdesk

Der Austausch und die Integration mit anderen Komponenten sind nur unzureichend implementiert, und die Anbindung mit anderen Datenbanken wird erst durch komplizierte Schnittstellenprogramme erreicht. Leider fehlt auch die Einbindung von veranschaulichenden Anhängen zu Incidents. Positiv sind die optionalen Automatisierungs-Skripte im Archiv „f2w- scripts-1.4.tar.gz“ für ein tägliches Backup und ein E-Mail-Gateway zu bewerten.

3.2.3.2.1.4 Zusammenfassung

Insgesamt genügt das Free2Work-Helpdesk-Projekt nicht den erarbeiteten Anforderungen und zeigt die größten Schwächen im Bereich ITIL und den Praxis-Anforderungen. Damit werden zwei von drei Hauptkriterien nicht erfüllt und weisen die Software als nicht konform zurück.

3.2.3.2.2 DCL

Die Installationsdateien von DCL können bequem von der Internet-Projekt- Seite¹³⁸ aus bezogen werden. Für die Evaluation wird das Archiv „dcl- 0.9.4.2.tar.gz“ in einen Unterordner des Apache-Web-Servers entpackt, typischerweise in das Verzeichnis, in dem alle Web-Dokumente des Servers liegen¹³⁹. An dieser Stelle sei auf die von DCL mitgelieferte ausführliche Installationsanleitung verwiesen. Sehr überzeugend ist die web-basierte Setup-Routine, die erste Konfigurationseinstellungen sowie die Datenbankanbindung sehr einfach umsetzt. Am Ende des Setup kann sofort auf das DCL-System zugegriffen werden. Nach der Eingabe der Stammdaten über die Web-Oberfläche können direkt neue (Incident)- Tickets angelegt und die Bewertung angegangen werden. Für weitere Einstellungen in Bezug auf PHP und den Apache-Web-Server sei auf die Installationsanleitung¹⁴⁰ von DCL verwiesen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: DCL bei der Eingabe eines Tickets

3.2.3.2.2.1 Bewertung der ITIL-Anforderungen

Auch bei Double Choco Latte lassen sich bereits nach dem ersten Blick auf die Applikation (siehe Abbildung 8) viele Kriterien des Anforderungskatalogs analysieren: So wird das ITIL-Wording nur in Ansätzen oder rein zufällig¹⁴¹ benutzt, wie z. B. bei der Bezeichnung des Zwischenfalls oder bei der Angabe der Priorität. Außerdem wird nicht nach Kategorien und Unterkategorien, sondern nach Produkten und Modulen unterschieden. Die Bezeichnung eines Zwischenfalls durchgängig als Ticket ist als ausreichende Schwäche für das Unterkriterium zu nennen, um ITIL-Wording nicht zu genügen (siehe Tabelle 7). Als großer Vorteil ist in diesem Fall die Abstraktion von Daten und Präsentation bei DCL zu sehen, da im Falle des ITIL-Wording einfach die Sprachdateien angepasst werden müssen, um die entsprechenden Schwächen zu beheben.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7: DCL und das ITIL-Wording

Bei den ITIL-Kriterien sieht es ansonsten viel versprechend für DCL aus, da hier die wichtigsten Punkte für den Aufbau der Incident-Records und ein sehr komfortables Berichtswesen, mit z. B. integrierter grafischer Statistik über Aktivitäten und Tickets, bereits in der Standardinstallation integriert sind. Schwächen ergeben sich noch in den funktionalen Anforderungen an ITIL (siehe Tabelle 8).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 8: Funktionale Aspekte, die von DCL erfüllt werden

Eine Relation zwischen Kategorien und Prioritäten lässt sich nicht konfigurieren, und auch die Referenzierung von Tickets miteinander, wie z. B. bei einer Störung, die mehrere Nutzer eines Netzwerksegmentes betreffen, ist nicht möglich.

Auf der Seite der Wissensdatenbank ist DCL nicht sehr gut ausgestattet: Als Modul für die Wissensbasis wird eine FAQ-Datenbank angeboten, die auf eine Frage hin eine Lösung anbietet und bestimmten Oberthemen zuordnet. Leider ist diese Art der Datenbank nicht optimal für die Arbeit mit Work-arounds, Known Errors und Prozeduren für die Störungsbeseitigung geeignet (siehe Tabelle 9).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 9: Eine Wissensdatenbank ist nicht in DCL enthalten

Insgesamt erfüllt DCL ebenfalls nicht alle Kriterien, die nach ITIL erfüllt sein müssen, wenn auch nur sehr knapp unter der strengen Auflage des ITIL-Wordings.

3.2.3.2.2.2 Anforderungen an OSS

DCL erfüllt alle Kriterien, die an OSS gestellt werden, bis auf die Tatsache, dass die Software laut Entwicklerteam noch als Beta-Version zu betrachten ist. Dieser Klassifikation ist auch nichts entgegenzusetzen, da jede Software über Fehler verfügt. Im Vergleich zu den anderen Programmen kann man hier sogar von einer stabilen Version sprechen, da mit „Beta“ der Fertigstellungsstatus in Bezug auf den noch zu erweiternden Umfang bezeichnet wird.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 10: DCL liegt in einer Beta-Version vor

Bisher stehen drei stabile Vorgänger-Versionen von DCL zum Download bereit. Besonders hervorzuheben ist der freundliche Kontakt zu dem Hauptentwickler, der durch die vorgetäuschte Support-Anfrage zu Stande kam; der Programmierstil und die Vorgaben, die in der Entwicklerdokumentation beschrieben werden, lassen keine Wünsche mehr offen: DCL ist auf mehreren Abstraktionsebenen verankert, die für eine Trennung von Daten, Anwendung und Präsentation sorgen (siehe Tabelle 10).

3.2.3.2.2.3 Anforderungen aus der Praxis

Bei den Anforderungen, die aus der Praxis an DCL gestellt werden, scheitert erneut die Integration der einsetzenden Organisation (siehe Tabelle 11).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 11: DCL erfüllt kein Kriterium der Organisationsanforderungen aus der Praxis

Weder Eskalationsprozeduren für Tickets noch eigene Benachrichtigungsregeln werden in DCL bei der Standardinstallation realisiert. Allerdings können in dem Auftragsmodul sehr wohl individuelle Eskalationszeitpunkte auf Tagesbasis definiert werden.

Die Anforderungen an die IT-Technologie werden sehr gut von DCL erfüllt: Vor allem der Datenaustausch mit XML¹⁴² -Dateien, der Import von Tickets und Arbeitsaufträgen und die Möglichkeiten für angehängte Dateien sind positiv hervorzuheben.

Damit werden auch die Anforderungen aus der Praxis im Sinne des Anforderungskatalogs erfüllt.

3.2.3.2.2.4 Zusammenfassung

DCL erfüllt zwei der drei Hauptkriterien, nämlich die Anforderungen an die OSS-Eigenschaften und die Anforderungen aus der Praxis des Anforderungskatalogs und ist somit anforderungskatalog-konform. Im Test ergeben sich kleinere Schwächen in der Umsetzung der ITIL- Anforderungen, die sich nicht durch die Standardinstallation, jedoch durch kleinere Modifikationen von Textdateien, wie z. B. bei den ITIL-Wording- Schwächen, realisieren lassen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 12: DCL erfüllt alle entscheidenden Kriterien des Anforderungskatalogs

3.2.3.2.3 DotProject

DotProject lässt sich ebenfalls über einen Download von der Internet-seite des Projekts herunterladen. Das komprimierte Archiv „dotproject_v1_0_2- 1.zip“ wird gleichermaßen wie bereits DCL in das Dokumenten- Verzeichnis des Apache-Web-Servers entpackt. Auch hier dient die mitgelieferte Installationsanleitung als Grundlage für die ersten Schritte. Leider ist die Prozedur zum Einrichten der Applikation nicht automatisiert und besteht aus neun Schritten und weiteren Einstellungstätigkeiten. Vor allem die Einbindung der Datenbank und die Parametrisierung sind in diesem Fall nicht so einfach wie beispielsweise bei DCL.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Anlegen eines neuen Tickets in DotProject

3.2.3.2.3.1 Bewertung der ITIL Anforderungen

Offensichtlich hat ITIL in DotProject keine Bedeutung und wird auch nicht im Ansatz unterstützt. Für das Kriterium „ITIL“ sind weder das ITIL- Wording noch eines der wichtigsten Unterkriterien erfüllt: Große Schwächen ergeben sich bei der Speicherung von neuen Tickets (siehe Abbildung 9), da die aufgenommenen Kriterien für eine ITIL-Applikation zu gering ausfallen. Im Grunde werden zwar versteckte Attribute wie das Datum und der Status gesetzt, diese können aber nicht das Spektrum von Kategorien und erweiterten Kontaktdaten ersetzen (siehe Tabelle 13).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 13: DotProject hat größtenteils keine ITIL-Konformität

Die Attribute eines Incident-Aktionen-Datensatzes werden von DotProject in einer zweiten Sicht auf die Tickets realisiert und in Form von Beiträgen und Kommentaren an das ursprüngliche Ticket angehängt.

Weder die funktionalen ITIL-Anforderungen, eine Wissensdatenbank oder die umfassende Berichterstattung sind in DotProject integriert (siehe Tabelle 14).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 14: DotProject zeigt weitere ITIL-Schwächen

Insgesamt lassen sich große Schwachstellen im Zusammenhang mit ITIL feststellen, die dazu führen, dass die ITIL-Anforderungen nicht erfüllt werden.

3.2.3.2.3.2 Anforderungen an OSS

Der überwiegende Teil der OSS-Eigenschaften wird von DotProject erfüllt. Einen negativen Beigeschmack hat die nicht eingetroffene oder vergessene Antwort auf die fiktive Support-Anfrage. Das Kriterium „OSS“ ist dennoch erfüllt.

3.2.3.2.3.3 Anforderungen aus der Praxis

Die Praxisanforderungen der Organisation können nicht von DotProject erfüllt werden, da hier z. B. eine Definitionsmöglichkeit eigener Benachrichtigungsregeln fehlt (siehe Tabelle 15).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 15: Organisationskriterien werden nicht von DotProject unterstützt

Auch bei der IT-Technologie fehlt es DotProject an den entscheidenden Kriterien: Die Installation stellt sich schwieriger dar als z. B. bei DCL; aber auch Anhänge zu Tickets oder einfacher Datenaustausch sind mit der Standardinstallation nicht möglich (siehe Tabelle 16).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 16: Die IT-Technologie bei DotProject

3.2.3.2.3.4 Zusammenfassung

Zusammenfassend lässt sich sagen, dass DotProject im Grunde kein spezialisiertes System für das Management von Incidents darstellt, wie es im ITIL Service Desk nötig ist. Die Hauptkriterien werden bis auf die allgemeinen Anforderungen an OSS nicht erfüllt und lassen DotProject als nicht konform bewerten.

3.2.3.3 Fazit der Evaluation

Aus den gewählten Produkten (siehe 3.2.3.2) für die Bewertung nach dem Anforderungskatalog (siehe 3.1.4) zeigt sich, dass alle Open-Source- Werkzeuge Schwächen bei der Umsetzung der ITIL-Anforderungen haben. Die Anforderungen an OSS haben alle Produkte zufrieden stellend erfüllt, auf der anderen Seite werden die Organisationskriterien der IT- Technologie nicht integriert. Aus den Bewertungen geht hervor, dass nur DCL überhaupt in die Endauswahl kommen kann, obwohl hier auch bestimmte Mängel in Bezug auf ITIL vorliegen. Zusammenfassend geht aus der erfolgten Evaluation hervor, dass es keine getestete OSS gibt, die alle Anforderungen anstandslos erfüllt. Folglich kommt man nicht ohne Anpassungen und Modifikationen zu dem gewünschten Ergebnis, um z. B. die eigene Organisation in das neue Tool einzubinden oder um das ITIL-Wording nach den „Glossary of ITIL terms“ zu integrieren. Im Folgenden soll nun die in diesem Abschnitt evaluierte und für konform befundene Software DCL in der Form angepasst werden, dass sich eine nahezu 100 %ige Deckung der ITIL-Anforderungen in einem Service Desk Tool aus DCL und komplementären Open-Source-Projekten kristallisiert. Die Anforderungen für die Anpassung ergeben sich unwillkürlich aus den nicht erfüllten Punkten des Anforderungskatalogs.

4 Implementierung einer ITIL-konformen Service-Desk-Applikation auf der Basis eines Open-Source-Werkzeuges

4.1 Überblick

Auf die Vorgehensweise in diesem Abschnitt wird an dieser Stelle separat eingegangen, da dieser Abschnitt erst aufgrund der Anforderungen und Resultate aus dem vorangegangenen Abschnitt 3 (Anforderungskriterien an ITIL-Service-Desk-Lösungen) möglich ist. Veranschaulicht wird die Vorgehensweise schematisch in Abbildung 10.

Die aus dem Abschnitt 3 gewonnene Open Source Software DCL wird aufgrund der Konformität zu den Konzepten aus dem Abschnitt 2 (Konzepte für Service-Desk-Applikationen) für fähig befunden, das Incident Management innerhalb des Service Desk automatisieren zu können.

Der praktische Abschnitt 4 geht nun detailliert auf die Fähigkeiten der evaluierten Lösung ein und versucht anhand der Quelltextanalyse die Aufwandsschätzung für die Implementierung festzustellen. Nach dem Vergleich der Anforderungen aus ITIL mit den Fähigkeiten von DCL kann anschließend die Umsetzung der abgegrenzten Kriterien erfolgen.

Zum Ende des vierten Abschnitts wird eine Installationsanleitung des endgültigen Open-Source-Produkts für den ITIL Service Desk beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Implementierung des OSS ITIL Service Desk

4.2 Analyse der verwendeten OSS

4.2.1 Test- und Entwicklungsumgebung

Für die Analyse der OSS-DCL, die sich aufgrund der Anforderungs- evaluation (siehe 3.2.2.2.1, S. 52) für konform herausgestellt hat, wird die Testumgebung aus 3.2.3.1 verwendet. Die Entwicklungsumgebung kann unabhängig von der Testumgebung je nach Bedarf gewählt werden, da jedes Betriebssystem und jede Konfiguration mit Zugriff auf die virtuelle Testumgebung in Betracht kommt. Als Quelltext-Bearbeitungs-Anwendung wird hier das ebenfalls unter der GPL stehende freie Tool „DevPHP“¹⁴³ für Microsoft Windows® oder der interne Editor der Debian Distribution ausgewählt.

Die Testumgebung dient bei der Analyse von DCL als Web-Server, von dem aus alle Funktionalitäten in den nachfolgenden Testfällen untersucht und alle nötigen Modifikationen zeitnah gestestet und visualisiert werden können. Die Entwicklungsumgebung ermöglicht die Erforschung des fremden Quelltextes in gewohnter Umgebung, um schnell und effizient Funktionsschwächen aufzudecken und um kurze Wege und bessere Möglichkeiten für die Umsetzung von Anforderungen zu bieten.

4.2.2 Zielumgebung

Die Erarbeitung der angepassten OSS in Hinblick auf den ITIL Service Desk soll hier konkret in dem mittelständischen kunststoffverarbeitenden Unternehmen Sonderhoff GmbH¹⁴⁴ am Standort Köln eingesetzt werden:

Die Sonderhoff GmbH ist ein mittelständisches Chemieunternehmen, dessen Tätigkeitsbereich die Entwicklung, Herstellung und der Vertrieb von Dichtungs-, Verguss- und Klebesystemen auf der Basis von Polyurethanen, Silikon oder PVC ist. Diese Systeme werden für die Kunden maßgeschneidert entwickelt und zur Serienreife gebracht.

Hauptanwendungsgebiete sind die Automobil- und Automobil- zuliefererindustrie sowie die Elektro-, Verpackungs- und Schaltschrank- industrie. Am Standort Köln werden etwa hundert Workstations, zehn Server und etliche Intelligente Netzwerkkomponenten bereitgestellt. Mehr als hundert Mitarbeiter werden als User mit E-Mail- und Enterprise Ressource Planning(ERP)-System-Accounts betreut. Die IT-Abteilung besteht aus drei Mitarbeitern - zwei Studenten und mir als Koordinator und Incident Manager -, die alle IT-bezogenen Anfragen bearbeiten und hauptsächlich selbstständig lösen; Third-Line-Support wird teilweise bei externen Dienstleistern beauftragt. Als Kunden der IT-Abteilung werden alle übergreifenden internen Kostenstellen der Abteilungen sowie die nationalen und internationalen Schwestergesellschaften, Handelsvertreter und Dependenzen, z. B. in den USA, Spanien, Tschechien und Österreich, angesehen. Die Vorgaben an die Kategorien von Incident- Tickets ergeben sich aus der Erfahrung und dem Bestand an zu betreuenden IT-Ressourcen, wie z. B. ERP-System, Hardware und Software. Unterkategorien für Hardware sind z. B. Drucker, Server, Workstations und andere Netzwerk-Komponenten sowie Telefone und Mobilgeräte. Bei Sonderhoff werden alle IT-Ressourcen in einem digitalen LDAP-Verzeichnis verwaltet und aktualisiert. Als einfache Wissensdatenbank dient bisher der „Öffentliche Ordner“ in der Microsoft Exchange®-Umgebung.

4.2.3 Funktionsbeschreibung der OSS

Nach der oberflächlichen Bewertung der offensichtlichen Fähigkeiten und Möglichkeiten von DCL (siehe 3.2.2.2.1, S. 52) ist es für die weitere Arbeit notwendig, die gesamten Funktionen von DCL aufzudecken und zu beschreiben, die sich für den ITIL Service Desk im Hinblick auf den Incident Management Workflow verwenden lassen. Die Prozessschritte werden in 2.1.3 (siehe Abbildung 5) dargestellt. Im Service Desk ergeben sich daraus die in 2.1.2 (siehe Abbildung 3) visualisierten Tätigkeiten, die hier exemplarisch mit den Möglichkeiten von DCL dargestellt werden. Für die Anfertigung der Funktionsbeschreibung werden vorab die wichtigsten Daten über das Verwaltungs-Menü „Admin“ hinterlegt: Die Eingabe von Kunden, Support-Mitarbeitern, Kategorien und Unterkategorien, die Arten abgeschlossener und noch offener Tickets, die Prioritätsschlüssel und die Typen von Tickets können dort zentral eingestellt werden.

4.2.3.1 Aufnahme eines neuen Incident

Nach der in 2.1.3 ausgeführten Beschreibung des Incident-Management- Prozesses beginnt der Service Desk mit der Aufnahme eines Zwischenfalls, also z. B. mit einer Anfrage oder einer Störung. DCL bietet in der Standardkonfiguration keinen direkten Zugriff auf die Erstellung eines neuen Incident-Tickets von der Startseite aus¹⁴⁵ ; über den Menüpunkt „Tickets“ kann man in der etwas „holperigen“ deutschen Übersetzung auf „Addieren“ klicken und kommt somit auf das Aufnahme- Formular eines neuen Tickets.

Die Eingabe des anrufenden Kontakts gestaltet sich als sehr aufwendig, da hier manuell die Telefonnummer, E-Mail-Adresse, der vollständige Name und die Kundezuordnung eingegeben werden müssen. In der Standardinstallation müssen vorab die Kunden hinterlegt werden, da eine dynamische Population der Auswahlfelder mit neuen Daten nicht erfolgt. In diesem Zusammenhang ist die interne Definition von Kunden ausschlaggebend für das weitere Procedere; im konkreten Testfall werden die internen Kostenstellen der Abteilungen zu Grunde gelegt.

Mit der Installation des E-Mail-Gateway integriert DCL die Möglichkeit, automatisch E-Mails von Usern oder von intelligenten IT-Netzwerkgeräten, wie z. B. die Wartungsmeldung eines Druckers, zu empfangen. Da die Priorisierung und Klassifikation der so eingetroffenen Incidents per Automation voreingestellt werden, ist eine nachträgliche Supervision, wie ITIL von dem Service Desk fordert, unabdingbar. Die einzelnen folgenden Schritte sind deshalb aus Sorgfaltsgesichtspunkten für den Service Desk ebenfalls durchzuführen.

Die Klassifikation wird in DCL über Kategorien und Unterkategorien, in der deutschen Übersetzung mit „Produkte“ und „Module“ bezeichnet, vorgenommen und stellt sich als einfach dar. Wiederum müssen die hinterlegten Daten an anderer Stelle eingegeben werden, damit die automatische Zuordnung von Modulen zu Kategorien getestet werden kann. Auch hier fehlt eine dynamische Übernahme von neuen Kategorien.

Die Klassifikation einer Anfrage zu einer Störung oder einer ServiceAnfrage, wie z. B. einer Bedarfsmeldung, kann von DCL über den Typ eines Tickets realisiert werden, setzt man die vorhergehende Einrichtung der Typen für Tickets in der Verwaltung von DCL voraus.

4.2.3.2 Aktivitäten bei einer Anfrage

Wird zum Beispiel eine Schulung für einen neuen Benutzer angefragt, können in DCL über das Modul „Checklisten“ per XML Standardvorlagen erzeugt werden, die den Workflow für ein Zu-Stande-Kommen einer Mitarbeiter-Schulung unterstützen. Das Abrufen einer Dokumentation für die Einrichtung eines neuen Benutzers ist jedoch nicht möglich.

4.2.3.3 Aktivitäten bei einer Störung

Da auch die Abfrage der CMDB bei DCL nicht integriert ist, können keine dynamischen Angaben zu Fehlern von konkreten Störungsobjekten oder -orten gemacht werden, sondern ausschließlich Informationen über den Fließtext mitgeteilt werden. Die CMDB könnte Trends und Störungs- häufigkeiten ermitteln. Bei der Vergabe der Priorität sind die Vorgaben der eigenen IT-Organisation ausschlaggebend, um z. B. die Störung eines ERP-Systems mit der notwendigen Dringlichkeit, Priorität und geschäftlichen Auswirkung richtig festzulegen. Zu dieser Thematik bietet DCL, wie auch schon im Anforderungskatalog bewertet, keine Unterstützung an. Der Einfachheit halber wird selbst in dem ITIL- Framework die Priorität einer Störung über den Typ der Anfrage sowie über die Kategorien und Unterkategorien ermittelt.¹⁴⁶

Nach der Angabe der Priorität folgt die Beschreibung des Zwischenfalls. Notizen und Anhänge können bequem mit der Tastatur oder anderen Eingabegeräten, wie z. B. mit Spracherkennung, eingegeben werden.

Nach der Aufnahme eines Zwischenfalls kann der Bearbeiter einen Verantwortlichen aus einem vorgegebenen Menü auswählen, falls der Bearbeiter die Störung nicht persönlich lösen kann. Diese Zuordnung ist zum Beispiel erforderlich, wenn der Bearbeiter beurteilen kann, dass eine andere Support-Linie oder ein anderer Mitarbeiter die Störung effizienter und effektiver lösen könnte. Im Falle der Übertragung an einen internen Service-Mitarbeiter kann DCL mehrere Angehörige einer Gruppe oder Organisation zusammenfassen¹⁴⁷ und auch externe Dienstleister so problemlos integrieren.

4.2.3.4 Abschluss eines Incident

Die Behebung einer Störung, ob intern oder durch Externe, und die Erledigung einer sonstigen Anfrage kann bei DCL sofort nach der Eingabe eines Tickets erfolgen. Auch die verzögerte Schließung eines Tickets, z. B. nach erfolgter Lieferung einer Bestellung bei einem Hardware- Distributor oder einer Dienstleistung des Netzwerkinstallateurs, ist über die Eingabe der eindeutigen Nummer eines Tickets möglich. DCL bietet von sich aus nicht die Möglichkeit, bei jedem neu aufgenommenen, modifizierten oder geschlossenen Ticket eine automatische Benachrichtigung an den User oder Kontakt zu senden; ausschließlich die Benachrichtigung von bereits angelegten Benutzern von DCL ist möglich. Mögliche Abschlussarten und Closure-Codes können bei DCL den Eigenschaften von Tickets hinzugefügt werden.

4.2.4 Quelltextanalyse anhand der Entwicklerdokumentation

Die Quelltextanalyse dient der groben Orientierung in der verwendeten Software. Bei OSS ist diesbezüglich nicht nur der Überblick über die grafische Benutzerschnittstelle (GUI¹⁴⁸ ), sondern auch die Einsicht hinter die GUI für die geplante Anpassung und Modifikation nötig. Für die Implementierung kann nach erfolgter Analyse herausgestellt werden, welche Anpassungen durch die Änderung von Parametern in Konfigurationsdateien oder Datenbanktabellen und welche Modifikationen durch Hinzufügen von Programmiercode umgesetzt werden müssen.

Die Entwicklerdokumentation liegt DCL im Unterverzeichnis „docs“ in englischer Sprache bei und ermöglicht einen schnellen Überblick über die Konstruktion der Software: DCL abstrahiert die Logik, die Daten und die Präsentation mit verschiedenen ineinander greifenden Modulen. Für die sinnlogischen Zusammenhänge und Funktionen ist die Kennung „bo“ für Business-Logik, für alle datenbankspezifischen Abfragen die Kennung „db“ für Datenbank und für alle Ausgaben die Kennung „html“ vergeben. Die Ausgabe wird zusätzlich noch in den Programmierteil und in den HTML-Teil aufgesplittet: Alle erforderlichen Daten werden in einem PHP- Skript mit der Endung „php“ aufbereitet und über spezielle standardisierte Funktionen in so genannte „templates“ überführt, die keine serverbasierten Skripte mehr enthalten, sondern nur HTML-Quelltext und clientbasierte Javascript-Funktionen. Auf diese Weise kann ein Entwickler auf Anhieb zusammengehörige Elemente aus dem Namen der Quelltext- Dateien ableiten: So sind beispielsweise alle Module für den Aufbau der persönlichen Startseite an der Kennung „My“ zu erkennen. Für den Aufbau der Datenbank wird das Datenbank-Schema als Bild „img1.png“ ebenfalls im „docs“-Unterverzeichnis mitgeliefert.

Die Konfiguration wird teilweise über die Konfigurationsdatei „config.inc.php“ im Verzeichnis „inc“ ermöglicht, die bei der Installation automatisch mit den erforderlichen Parametern ausgefüllt wird. Im Nachhinein sind hier Einträge für beliebig viele Datenbanken und Mandanten möglich. Das Aussehen der GUI und erweiterte Konfigurationsdaten von DCL werden über Konfigurationseinstellungen in der Datenbank gesteuert, die über das Auswahlmenü „Admin“ nach dem Anmelden in DCL zu finden sind (siehe Abbildung 11).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: DCL-Systemkonfiguration

4.2.5 Kriterienabgrenzung für die Implementierung

Die Kriterienabgrenzung richtet sich nach den nicht erfüllten Anforderungen aus 3.2.3.2.2. Ziel dieser Abgrenzung soll eine Übersicht aller funktionalen Schwächen von DCL für den ITIL Service Desk sein, mit einer Bewertung über den Schwierigkeitsgrad der Umsetzung und dem Aufwand für eine vollständige Erfüllung der Kriterien. Für die spätere Umsetzung des ITIL Service Desk mit DCL werden Muss-Kriterien aufgestellt, die bei der Implementierung und der Installation berücksichtigt werden müssen; Wunschkriterien sollen alle Anforderungen sein, die nicht existentiell notwendig für das Incident Management nach ITIL sind.

4.2.5.1 Muss-Kriterien

Die wichtigsten Anforderungen an DCL sind unter anderem die ITIL- Sprache, bestimmte zusätzliche Felder bei einem Incident-Datensatz, die Einbeziehung einer Konfigurations- und Erfahrungsdatenbank sowie die Hinterlegung der ITIL-Priorisierungs-Schlüssel nach Dringlichkeit, Auswirkung und Priorität:

Der Schwierigkeitsgrad für die Umsetzung des ITIL-Wordings ist als niedrig einzustufen, da sämtliche Texte auf der Oberfläche von DCL an Sprachdateien gekoppelt sind, die nach Themen sortiert angepasst werden können. So können z. B. über die Datei „tck.str“ im Unter- verzeichnis „str/de“ alle Texte mit Bezug auf Tickets in Deutsch abgeändert werden und sind fortan applikationsweit auf die ITIL-Sprache abgestimmt. Damit der ITIL Service Desk offensichtlich für den Benutzer aus DCL hervorgeht, werden alle Bilder und Vorkommnisse, die auf eine Standard-Installation von DCL hinweisen, weitgehend modifiziert: Das Ergänzungsprodukt wird in „IT Service DeskTop“ umbenannt und erhält ein neues Logo. Der Verweis auf DCL und der Hintergrund des IT Service DeskTop bleiben jedoch vollständig erhalten.

Die Integration von weiteren Feldern bei Incident-Datensätzen, wie z. B. die Verlinkung auf vorhandene Problemlösungen und Work-arounds oder CIs, kann mit einem mittleren Schwierigkeitsgrad umgesetzt werden: Bei der Anlage eines konkreten Arbeitsauftrages aus einem Incident-Ticket, wie z. B. die Terminierung und Durchführung eines Tonerwechsels, wird im Fließtext der Anfrage ein Verweis in Form eines Hyperlinks dargestellt, der den Arbeitsauftrag referenziert; genauso wird der Link im Arbeitsauftrag auf das ursprüngliche Incident-Ticket hervorgehoben (siehe Abbildung 12).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Hyperlink zu dem eigentlichen Incident

Über reguläre Ausdrücke¹⁴⁹ wird der Fließtext der Notizen auf das Muster „dcl://tickets/“ überprüft und dann mit einem Hyperlink auf das entsprechende Ticket ersetzt. Auf diese Art und Weise ist es mit mehreren regulären Ausdrücken möglich, weitere Ersetzungen für z. B. Known Errors aus der CMDB oder CIs vorzunehmen. Basiswissen über reguläre Ausdrücke wird beispielsweise im PHP-Handbuch¹⁵⁰ vermittelt. Als besondere Schwierigkeit für die Ersetzung mit Hilfe von regulären Ausdrücken lassen sich CIs schlecht über eindeutige Nummern identifizieren und werden meist über einen eindeutigen Namen erkannt, der auch Leerzeichen enthalten kann. Die Einbindung von anderen Incident-Tickets zu neuen Datensätzen kann ebenfalls über diese Ersetzungsfunktionen realisiert werden.

Die eigentliche CMDB wird mit mittlerem Schwierigkeitsgrad aus dem kurz vorgestellten SITR-Wissensdatenbank-Modul (siehe 3.2.2.2.6) in DCL als neuer Menüpunkt „CMDB“ integriert: Da SITR ein eigenständiges Anmeldeverfahren und eine eigene Datenbasis besitzt, müssen hier alle Authentifizierungs- und Hyperlink-Funktionen überprüft und zusammengelegt werden. Die Einbindung der Netzwerkkomponenten und IT-Ressourcen erfolgt über eine beliebige Datenbank, die eine Liste aller verfügbaren Geräte und Ressourcen darstellen kann und mit Parametern gewisse Detailinformationen zu bestimmbaren CIs ausgibt. In Betracht kommt z. B. das kurz vorgestellte IRM (siehe 3.2.2.2.2) oder eine Implementierung der Schnittstelle zu vorhandenen LDAP-Verzeichnissen.

Die Relation von Prioritätsschlüsseln nach ITIL kann mit niedrigem Schwierigkeitsgrad über eine Zuordnung der Prioritäten zu hinterlegten Zeiten und Auswirkungsparametern in einer neuen separaten Konfigurationsdatei „ITILconfig.inc.php“, die ebenfalls bei der Installation voreingestellt werden kann, umgesetzt werden. So können Incident- Tickets bei der Vergabe einer Priorität automatisch zur Eskalation gebracht oder Standard-Werte für neue Tickets voreingestellt werden. Die automatische Auswahl der Prioritätsschlüssel nach Kategorien kann über Erfahrungswerte hinterlegt werden: Die letzte Zuordnung einer Störung zu bestimmten Kategorien und Prioritäten wird bei einer erneuten Auswahl der Kategorie vorgeblendet.

Aus dem organisatorischen Praxisteil bleibt bei DCL für die einsetzenden Unternehmen die Einbindung eigener Eskalationsprozeduren und Benachrichtigungsregeln offen:

Die Standardinstallation von DCL benachrichtigt alle involvierten oder beobachtenden Benutzer von DCL über eine Veränderung oder Neuanlage von Incident-Tickets. Eine typische Meldung ist nach einer definierbaren Vorlage aufgebaut, die per Voreinstellung im Unter- verzeichnis „templates\custom“ zu finden ist. Hier werden alle aktuellen Parameter und Daten eines Tickets in die entsprechenden Felder eingesetzt und an den bekannten DCL-Benutzer versendet. Eine Benachrichtigung an den User, der die Anfrage gestellt hat, ist nur bei einer Qualitätsumfrage nach dem Abschluss eines seiner Tickets angedacht. Mit einem mittleren Schwierigkeitsgrad lassen sich weitere Nachrichten bezüglich des Incident Management an die vorhandenen Benachrichtigungen anschließen und nach Art des Incident und Status der Anfrage auswählen. Die Einstellungen für die Vorlagendateien sollen sprachenunabhängig über die oben angesprochene ITILKonfigurationsdatei parametrisiert werden.

Die Eskalation von Tickets wird bei DCL über eine einfache, auf fünf Einträge begrenzte Liste innerhalb der Startseite realisiert, die eigene und selbst eingestellte Incidents nach Gewichtung der Prioritäten und Typen ordnet (siehe Abbildung 13).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: DCL-Startseite mit visuellen Eskalationsmarkierungen

Bei Arbeitsaufträgen wird indes eine optische Unterscheidung vorgenommen, um die Fälligkeit bzw. das Fertigstellungsdatum darzustellen. Diese visuelle Hervorhebung durch verschiedenfarbige Ausrufezeichen ist auch auf Incident-Tickets anzuwenden, um die Toleranzgrenzen für die jeweilige Eskalation der Störungen anzuzeigen. Die Umsetzung erfolgt auf der Basis hinterlegter Toleranzgrenzen für die Prioritätenschlüssel, um den Eskalationszeitpunkt und die Toleranz- überschreitungen zu bestimmen. Da Anfragen z. T. über die Tages-Basis hinausgehen, weil z. B. auf einen externen Dienstleister gewartet wird, muss die Startseite der Übersicht halber auf die zehn wichtigsten Einträge erweitert werden. Die Startseite wird für die Störungen übersichtlich in die Bereiche „Meine Incident-Tickets“ und „Meine eingestellten Incident- Tickets“ mit den jeweils zehn wichtigsten Incidents sowie den Bereich „Sonstige Incident-Tickets“ mit Anfragen, die nicht zu den oben aufgeführten Bereichen gehören, unterteilt. Diese Ansicht kann durch Einstellungen an die jeweiligen Bedürfnisse angepasst werden. Wenn ein Incident-Ticket eine Toleranzgrenze überschreitet, soll automatisch eine E-Mail an den Incident Manager versandt werden, die über die Eskalation einer Störung informiert. Die Umsetzung erfolgt mit einem mittleren Schwierigkeitsgrad.

4.2.5.2 Wunschkriterien

Die Wunschkriterien ergeben sich ebenfalls aus der Analyse in 3.2.3.2.2: Die Einbindung von LDAP-Verzeichnissen als Grundlage für die Verwaltung von CIs oder die Erstellung von Erfahrungseinträgen aus bereits vorliegenden Datenbeständen in die Wissensdatenbank können aus der Sicht von Sonderhoff die Synergien aus bereits eingesetzten Produkten mit dem IT Service DeskTop verknüpfen.

Bei einer festgelegten Organisationsstruktur und einer überschaubaren Anzahl von Usern, wie z. B. bei Sonderhoff, ist es sinnvoll, den Eingabeprozess von Incident-Tickets durch eine Automatisierung der Auswahl des zugehörigen Kunden, der zugehörigen E-Mail-Adresse und Telefonnummer von Kontaktdaten zu beschleunigen. Über ein Auswahl- Fenster könnten alle bereits aufgenommenen Kontakte vorgeblendet werden und über eine anschließende Eingabe in die Muss-Felder des Datensatzes eingefügt werden. Eine Integration des vorhandenen LDAP- Verzeichnisses, in dem alle Daten bereits gepflegt werden, ist ebenfalls über einen Auswahl-Dialog möglich. Der Schwierigkeitsgrad setzt sich aus der Kombination mehrerer Skriptsprachen und der Verwendung der LDAP-Abfrage-Syntax zusammen und lässt sich als mittelschwer bewerten.

Um bei den Automatisierungen einen Zeitvorteil zu erreichen, muss ein Zwischenspeicherungsverfahren bzw. „Caching“, wie z. B. für die Abfrage der LDAP-Server, gewährleisten, dass die Anzeige der Auswahl-Fenster beschleunigt wird. Die erforderlichen Caching-Mechanismen setzen sich aus der Speicherung der relevanten Datenbasis aus den Datenbankabfragen und kompletten HTML-Seiten zusammen und sind leicht umzusetzen.

Im Umgang mit dem IT Service DeskTop fallen in der täglichen Benutzung immer wieder kleinere Schwächen von DCL auf, die für eine effiziente Arbeit mit dem Tool aus Sicht von Sonderhoff überarbeitet werden sollten: Die Spaltenaufteilung bei Auflistungen von Störungs-Tickets ist nicht immer optimal für das Wiederfinden geeignet, und die Suche nach Tickets wird an einigen Stellen nur über die Referenznummer ermöglicht; um eine offene Anfrage zu schließen, ist z. T. der Umweg über eine Auswahl-Liste eingerichtet und kann nicht direkt aus dem Ticket erfolgen. Die Überarbeitung ist mit mittlerem bis schwerem Schwierigkeitsgrad umzusetzen, weil jede Änderung die Analyse der verknüpften Quelltext- Beziehungen erfordert. Die eigentliche Programmierarbeit ist sicherlich zu vernachlässigen.

Da DCL das Modul „Arbeitsaufträge“ bereits in der Basisinstallation anbietet, ist es sinnvoll, alle zukünftigen Aufgaben, die sich aus Störungen und Anfragen ergeben, ebenfalls über den IT Service DeskTop zu steuern. ITIL sieht für die Terminierung und Durchführung von Arbeitsaufträgen in Beziehung zu Incidents die Notwendigkeit der Benachrichtigung der betroffenen User als wichtigstes Integrations-kriterium, welches sich nach dem Muster für Benachrichtigungen von Incident-Tickets leicht umsetzen lässt¹⁵¹.

4.3 Implementierung und Installation

4.3.1 Methodik

Das Kapitel „Implementierung und Installation“ stellt alle Änderungen an der Basis-Installation dar, indem teilweise Quelltextauszüge und veranschaulichende Abbildungen exemplarisch für die Implementierungs- anforderungen eingebettet werden. Um die Änderungen im Quelltext visuell abzuheben, werden gelöschte Zeilen mit einem „-“ und hinzugefügte Zeilen mit einen „+“ versehen. Die Orientierung im Quelltext kann über die angegebenen Zeilennummern und die Angabe des Dateinamens erleichtert werden: Die Angabe „@@ -1,28 +1,29 @@“ beispielsweise zeigt an, dass der Zeilenbereich von eins inklusive aller folgenden 28 Zeilen aus der Basis-Version von DCL mit dem Zeilenbereich eins und den nachfolgenden 29 Zeilen der veränderten ITIL- Version verglichen wird. Neu erstellte Quelltextdateien werden logischerweise ohne Änderungsmarkierungen abgedruckt, enthalten aber die Startzeile in der entsprechenden Datei. Falls Teile des abgedruckten Quelltextes nicht kommentiert werden, so wird die Schriftfarbe kontrastschwächer eingefärbt; so bleibt der Zusammenhang erhalten.

Alle Quelltext-Änderungen und -Anpassungen werden in Form einer installierbaren Distribution auf der beiliegenden CD-ROM zur Verfügung gestellt.

4.3.2 Umsetzung der Muss-Kriterien

Auf der Basis der Evaluation des Anforderungskatalogs aus 3.2.3 und der Detailanalyse der Implementierungsanforderungen aus 4.1 wird die Umsetzung auf der in 4.2.1 beschriebenen Test- und Entwicklungs- umgebung durchgeführt.

4.3.2.1 Identifizierung und Produktbezeichnung

Als Produktname für das überarbeitete DCL geht ein Zusammenschluss aus den Anforderungen hervor: Aus der Kombination „Open Source“, „ITIL“ und „Service Desk“ wird die OSS: „IT Service DeskTop“. Über die Such- und Ersetzungsfunktion in der Entwicklungsumgebung DevPHP werden alle Vorkommnisse von „Double Choco Latte“ in „IT Service DeskTop“ umbenannt. Als neues Logo dient ein simples grafisches Sechseck mit dem Schriftzug „IT Service DeskTop“, dem ITIL-Logo „Best Practice“ und der Kennzeichnung aller enthaltenen Basis-Komponenten, wie z. B. DCL und SITR (siehe Abbildung 14).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: IT-Service-DeskTop-Logo

4.3.2.2 ITIL-Wording

Die Überarbeitung der Sprachdateien wird exemplarisch in Deutsch vorgenommen und bezieht sich auf das Verzeichnis „str/de“ unterhalb des Hauptinstallationsverzeichnisses von DCL. Zu jedem Modul und jedem Bereich von DCL werden in diesem Ordner Sprachdateien definiert, die jeweils Platzhalter und den eigentlichen Übersetzungstext beinhalten (siehe Quelltextauszug 1):

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 1:Datei str/de/tck.str

In der Datei „tck.str“ werden alle Einträge, die direkt das ITIL-Wording betreffen, umbenannt. Zentrale Bedeutung hat der Begriff „Incident-Ticket“ im ITIL-Sprachschatz und wird an markanten Stellen, wie z. B. auf der Startseite, verwendet. Um die Übersichtlichkeit zu fördern, wird an allen anderen Stellen, wo der Platz begrenzt ist, auf die Nennung von „Incident“ verzichtet und „Ticket“ als Abkürzung benutzt.

In Abbildung 15 sind die Anpassungsarbeiten und Übersetzungsarbeiten an der Datei „admin.str“ veranschaulicht: Die Konfiguration des IT Service DeskTop wird nach ITIL-Gesichtspunkten vorgenommen, sodass eine Neuinstallation oder Wartung der Software durch die Beschreibung der ITIL-Ausdrücke, wie z. B. „Stati“, erleichtert wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Übersetzung und Anpassung im IT Service DeskTop Setup

Änderungen sind auch im Bereich „Incident-Typ“ zu veranlassen (siehe Quelltextauszug 2):

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 2: Datei str/de/sev.str

In der übergreifenden Sprachdatei „cmmn.str“ werden in der Standard- Installation Module und Produkte als Klassifikationskriterien für Incident- Tickets hinterlegt; für ITIL sind hier anstatt Module und Produkte Kategorien und Unterkategorien in Deutsch einzutragen.

Weitere Anpassungen sind im Bereich „Arbeitsaufträge“ in der Datei „wo.str“ und im Bereich „Menü“ in der Datei „menu.str“ erforderlich, um die Konfigurations- und Wissensdatenbank sowie die Integration von Arbeitsaufträgen einzubinden.

4.3.2.3 Incident-Datensatz

Für die vollständige Erfüllung der Anforderungen an einen Incident- Datensatz müssen die Punkte „Rückrufmöglichkeit“, „zugehörige CIs“ und „zugehörige Problems/Known Errors“ aus dem Kriterienkatalog im neuen IT Service DeskTop umgesetzt werden.

Die Rückrufmöglichkeit wird über einen Parameter gesteuert, dessen Bedeutung über die Dokumentation im Incident Management an die Benutzer des IT Service DeskTop weitergereicht werden muss: Bei Eingabe der E-Mail-Adresse des betroffenen Users wird dieser künftig automatisch per E-Mail über den Status seiner Anfragen informiert; im Falle der Nicht-Eingabe muss der User telefonisch benachrichtigt werden. Die Eingabe der E-Mail-Adresse kann auch zu einem späteren Zeitpunkt erfolgen. Die technischen Details werden bei der Umsetzung der Benachrichtigungsregeln aufgeführt.

CIs, die als betroffene Objekte und Ressourcen der IT-Infrastruktur in den Lebenszyklus der Tickets eingebunden werden sollen, werden über eine Schaltfläche bei der Eingabe von neuen Störungs-Datensätzen eingeblendet. Als Datenbasis für die Konfigurationsdatenbank dient bei Sonderhoff ein öffentliches Verzeichnis, das alle Parameter und Einstellungen der im Netzwerk befindlichen Komponenten in einzelne XML-Dateien speichert und aktualisiert. Das Werkzeug nennt sich „ci2xml“ und ist eine eigene Entwicklung, um alle Lizenzen und Konfigurationen zentral zu verwalten und grafisch flexibel auszuwerten. Der Distribution des IT Service DeskTop liegt eine freie Version von ci2xml bei. Um die Einbindung möglichst flexibel zu gestalten, wird das Verzeichnis, das alle Informationen enthält, in einer Liste ausgegeben (siehe Quelltextauszug 3) und kann per Mausklick in die Beschreibung eines neuen Tickets eingehen.

Die neu angelegte Datei „class.htmlCIs.inc.php“ enthält die Präsentationsebene und ermöglicht über den Einsatz von Javascript das Öffnen eines Dialog-Fensters, welches die Auswahl eines CIs zulässt.

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 3: Datei inc/class.htmlCIs.inc.php

In der Testumgebung sieht die Umsetzung wie folgt aus:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: Verknüpfung von CIs im IT Service DeskTop

Mit einem Klick auf die Schaltfläche „Verknüpfte Objekte“ liest die Klasse „htmlCIs“ alle verfügbaren CIs ein und gibt diese in Form einer Liste aus. Mit einem weiteren Klick auf ein entsprechendes Objekt fügt das DialogFenster einen Eintrag in das Symptome-Textfeld, wie z. B. [CI://CIS/Server3.xml] für einen Klick auf Server3, ein. Über die Implementierung eines neuen regulären Ausdrucks in der Datei „inc/functions.inc.php“ (siehe Quelltextauszug 4) können fortan die Details zu dem verknüpften Objekt verwaltet werden.

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 4: Datei inc/functions.inc.php, Funktion CreateLinkedText

Ein Mausklick auf das beispielhafte CI „Server3“ über den Hyperlink „[CI://CIS/Server3.xml]“ öffnet ein neues Browser-Fenster und zeigt die aktuellsten Konfigurationsdetails des Servers an (siehe Abbildung 17).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: Darstellung verknüpfter CIs

Verknüpfungen zu Known Errors oder Wissensdatenbankeinträgen wird auf die gleiche Weise wie bei der Integration der CIs bei der Implementierung der Wissensdatenbank realisiert.

4.3.2.4 Incident Workflow

Die automatische Eskalation von Incidents ist in DCL nicht integriert und muss neu implementiert werden. Als konzeptioneller Entwurf dient ein Skript, welches periodisch aufgerufen wird und alle Störungs-Tickets an den Incident Manager weiterleitet und überträgt, die über eine bestimmbare Toleranzgrenze bzw. den Eskalationszeitpunkt hinausgehen. Die Definition der Toleranzgrenzen wird ebenfalls auf der Präsentationsebene, wie z. B. bei der persönlichen Startseite, benötigt. Das Skript erhält den Namen „escalateAgent“; das PHP-Skript wird autark von der eigentlichen Browser-Umgebung von einem Betriebssystem- Dienst gestartet. Eine automatische Anmeldung in DCL muss erfolgen, um die Incident-Datensätze in der Datenbank modifizieren zu dürfen und die Benachrichtigungs-Logik von DCL verwenden zu können.

Die automatische Anmeldung an DCL kann über eine manipulierte Umgebungsvariable „Session“ erfolgen, aus der DCL die Anmeldeparameter ausliest und den Agenten authentifiziert (siehe Quelltextauszug 5).

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 5: Datei contrib/escalateagent/class.htmlEscalateAgent.php

Über die globale Variable „DCLID“ wird der Administrator mit der Identifikation „1“ als Benutzer des Skripts in DCL angemeldet und in der Session registriert. Nach der Registrierung der Session ist der integrierte Systemadministrator-Account für alle Authentifizierungsfunktionen als angemeldet hinterlegt, und die Abfrage aller Störungs-Tickets (siehe Quelltextauszug 6), die noch offen sind und zusätzlich eine bestimmte Toleranzgrenze überschritten haben, schließt sich an. Die Toleranzgrenze von 75 oder 95 % vor dem zugesicherten Lösungstermin kann über eine Einstellung in der „ITILconfig.inc.php“-Datei gesetzt werden. Wenn also z. B. in einem bestimmten Incident-Ticket der Prioritäts-Schlüssel „Hoch“ definiert wird, dann kann mit der Relation zu der bestimmten Dringlichkeit die Zeit berechnet werden, in der das Ticket gelöst sein müsste. Wird diese Zeit überschritten oder ist noch keine Aktion innerhalb der Toleranzgrenze erfolgt, dann wird die Störung an den Incident Manager weitergeleitet.

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 6: Datei contrib/escalateagent/class.htmlEscalateAgent.php

4.3.2.5 Funktionale Aspekte

Zu den erforderlichen Punkten zählt die Umsetzung der Prioritäts- Schlüssel nach Kategorien: Nach der Auswahl einer Kategorie für ein neues oder bestehendes Incident-Ticket sollte automatisch die Priorität, der Typ des Zwischenfalls und die hinterlegten Werte für die Auswirkung und Dringlichkeit bestimmt werden. Somit kann die Klassifikation aus Erfahrungswerten erfolgen und macht die Beurteilung jeder einzelnen Störung einfacher und sicherer. Um aus den Kategorien und zugehörigen Unterkategorien abzuleiten, welche Prioritäts-Schlüssel zu hinterlegen sind, wird über ein kontinuierliches Audit eine Erfahrungsdatenbank mit Informationen über die Relation angereichert, die bei jedem neuen oder geänderten Zwischenfall eingesetzt werden. Wird ein neues Ticket nach diesem Audit mit den gleichen Kategorien angelegt, werden die hinterlegten Werte des vorherigen Tickets für die Priorität, Dringlichkeit, Auswirkung und des Typs vorgeblendet. Die Umsetzung erfolgt über eine Kombination aus der clientbasierten Skriptspache „Javascript“, die eine dynamische Auswahl der Prioritäts-Schlüssel während der Laufzeit erlaubt, und PHP, welche für die serverseitige Speicherung und Fortschreibung der Erfahrungswerte zuständig ist.

Die dynamische Auswahl der Priorität und des Incident-Typs wird bei einer Änderung des Kategorie-Feldes für ein neues Ticket eingeleitet (siehe Abbildung 18).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18: Auswahl der Kategorie und Unterkategorie

Wird eine Kategorie in der Basis-Version ausgewählt, so werden automatisch die hinterlegten Prioritäts- und Typ-Schlüssel geladen, die für eine bestimmte Kategorie festgelegt worden sind, jedoch ohne die Vorblendung der konkreten Priorität aus Erfahrungswerten zu berücksichtigen. Diese Abfrage geschieht per Javascript und wird für die Auswahl vordefinierter Prioritäts- und Typ-Schlüssel überarbeitet (siehe Quelltextauszug 7).

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 7: Datei inc/class.jsAttributesets.inc.php

Innerhalb des PHP-Skriptes werden Javascript-Befehle und Funktionen kodiert, die bei der Auswahl der Kategorie nun auch die Priorität und den Incident-Typ vorblenden, sofern die Erfahrungswerte bei einem der vorherigen Tickets hinterlegt worden sind. Die Besonderheit, dass Kategorien nicht verpflichtend Unterkategorien haben müssen, wird über die Abfrage einer gültigen Unterkategorie in Javascript abgefangen. Um alle bisherigen Schlüssel in Javascript zu überführen, wird eine Konvertierungsfunktion erstellt, die aus den Relationen in PHP eine verkettete Liste „relPriImpUrg[]“ für Javascript generiert (siehe Quelltextauszug 8).

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 8: Datei inc/class.htmlTckUrgImpPri.inc.php

Bei der Neuanlage oder Änderung eines Incident-Tickets werden fortan automatisch die letzten Werte zu einer Kategorie und Unterkategorie abgespeichert und für neue Tickets und Arbeitsaufträge zur Verfügung gestellt.

Die Verlinkung eines neuen Incident-Tickets auf bereits existierende Datensätze wird über einen einfachen Button unterhalb der Schaltfläche für verknüpfte CIs realisiert (siehe Abbildung 19).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 19: Einfügen bereits existierender Tickets

Über die Javascript-Funktion „insertTck()“ kann die eindeutige Nummer eines existierenden Tickets in das Symptome-Textfeld eingefügt werden (siehe Quelltextauszug 9).

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 9: Datei templates/default/htmlTicketForm.tpl

Wird in das Textfeld (siehe Abbildung 20) hinter „INC#“ die Ziffer „1“ eingegeben und die Schaltfläche „verknüpfen“ (1.) betätigt, erscheint der Text „dcl:\\tickets\1“ in dem Symptome-Textfeld. Nach dem erfolgreichen Speichervorgang des Incident-Datensatzes (2.) wird über die Mustererkennung (siehe 4.2.5.1, S. 83) das verknüpfte Incident-Ticket als Hyperlink hinterlegt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 20: Einfügen einer Referenz auf ein existierendes Ticket

4.3.2.6 Wissensdatenbank

Die Integration einer anforderungskonformen Wissensdatenbank als Teil der ITIL-Anforderungen wird durch die Zusammenführung von DCL mit der OSS-SITR herbeigeführt. Über einen weiteren Menüpunkt innerhalb des IT Service DeskTop, „CMDB“, welcher die Konfigurationsdatenbank und die Erfahrungsdatenbank vereint, können relevante Standardlösungen aufgefunden oder neue Lösungen von Problemen hinzugefügt werden.

Die Projektdateien von SITR werden in das Unterverzeichnis „KB“ für „Knowledgebase“ kopiert und ebenfalls über die Konfigurationsdatei „ITILconfig.inc.php“ parametrisiert.

SITR wird in der Basis-Installation mit der Systemsprache Englisch ausgeliefert; die Einrichtung einer anderen Sprache erfolgt nicht wie bei DCL über Sprachdateien, sondern über die Datenbank-Tabelle „sys_language_keys“. Die deutsche Übersetzung liegt dem Installationspaket für den IT Service DeskTop bei und wird bei der Installation aktiviert, damit eine durchgängig deutschsprachige GUI gewährleistet werden kann.

Die Anlage des neuen Menüpunkts im IT Service DeskTop wird über die Erweiterung der Menüliste umgesetzt (siehe Quelltextauszug 10):

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 10: Datei inc/functions.inc.php

Die wichtigsten Elemente und Funktionen im Zusammenhang mit der Wissensdatenbank werden als direkte Aufrufe durch einen Klick auf den entsprechenden Menüeintrag eingeblendet (Abbildung 21).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 21: Die Wissensdatenbank wird als Menüeintrag in DCL integriert

Da SITR und DCL verschiedene Authentisierungsverfahren benutzen, ist es notwendig, eine Single-Sign-On-Lösung¹⁵² zu implementieren: Über die Anmeldung am IT Service DeskTop wird gewährleistet, dass kein unberechtigter Benutzer auf die Inhalte der Incident-Tickets zugreifen kann. Durch diese eindeutige Identifikation ist es möglich, die erforderliche „Session“¹⁵³ -Registrierung für SITR aus DCL zu steuern. Bei der Anmeldung an DCL werden gleichzeitig die korrespondierenden Authentifizierungstoken¹⁵⁴ für den integrierten Einsatz von SITR registriert und bei der Abmeldung gelöscht (siehe Quelltextauszug 11). So kann gewährleistet werden, dass der Benutzer innerhalb einer Web-Browser- Sitzung auf beide Datenquellen zugreifen kann.

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 12: Datei inc/class.boITILKBSession.inc.php

Über die Initialisierung der Session (siehe Quelltextauszug 12) als angemeldeter Benutzer durch DCL erübrigt sich die erneute Anmeldung an SITR. Die Integration wird durch die Übergabe der Design-Pfade für das Aussehen von SITR an DCL angeglichen.

Damit relevante Standardlösungen in Störungs-Tickets eingebunden werden können, wird an dieser Stelle erneut die Möglichkeit der Mustererkennung und Ersetzung sowie die Umsetzung und Auswahl über ein Dialog-Fenster (siehe 4.3.2.3, S. 93) herangezogen.

Neben der manuellen Eingabe der Lösungsdetails wird die Schaltfläche „Standard aus Wissensbasis“ neben dem Textfeld eingeblendet (siehe Abbildung 22).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 22: Einbindung der Erfahrungsdatenbank für Lösungen von Incident-Tickets

Bei der Betätigung der Schaltfläche wird ein Dialog-Fenster angezeigt, welches die Auswahl von Standardlösungen, Work-arounds oder Dokumentationen nach Kategorien zulässt, die in der Wissensdatenbank eingetragen werden (siehe Abbildung 23).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 23: Auswahl einer gespeicherten Lösung aus der Erfahrungsdatenbank

Falls die Maus auf dem entsprechenden Hyperlink betätigt wird, kann dieser als Verweis in die Lösung von DCL übertragen und angezeigt (siehe Abbildung 24) werden. Fällt der Mausklick auf „Neues Dokument“, kann ein neuer Erfahrungseintrag, wie z. B. aus der vorher gelösten Störung, hinzugefügt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 24: Die Lösung des Zwischenfalls wird aus der Erfahrungsdatenbank gelesen

Der Aufruf eines Dokuments aus der Wissensdatenbank über den Hyperlink im gespeicherten Störungs-Ticket wird mit einer zusätzlichen Mustererkennung und -Ersetzung implementiert (siehe Quelltextauszug 13), wie zuvor bei der Behandlung der CIs (siehe 4.3.2.3, S. 94).

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 13: Datei inc/functions.inc.php, Funktion CreateLinkedText

4.3.2.7 Organisationsanforderungen aus der Praxis

Die Muss-Kriterien an den IT Service DeskTop für den Einsatz in Organisationen werden auf der einen Seite durch die anpassungsfähigen Eskalationsprozeduren (siehe 4.3.2.4) und Benachrichtigungsregeln sowie auf der anderen Seite durch Genehmigungs- und Authentisierungs- verfahren bestimmt. Da in die Eskalationssteuerung und -benachrichtigung (siehe 4.3.2.4) bereits eine benutzerdefinierte Toleranzgrenze implementiert ist, geht der Fokus an dieser Stelle auf die Benachrichtigungsregeln und -Funktionen über.

Die Benachrichtigungsfunktionen in der Standard-Installation von DCL werden um die für ITIL notwendigen Benachrichtigungsmeldungen ergänzt und überarbeitet. Um alle Beteiligten umfassend zu informieren, wird von ITIL in erster Linie die Bestätigung über den Erhalt eines Incident gefordert und inhaltlich vorgeschrieben.¹⁵⁵

Um die Benachrichtigungsfunktionen im IT Service DeskTop um-zusetzen, wird hier exemplarisch die Einbindung der Bestätigung über den Erhalt einer Anfrage vorgestellt:

Bei der Speicherung eines neuen Incident-Tickets werden alle involvierten Mitarbeiter von einer E-Mail über die neue Anfrage informiert (siehe Quelltextauszug 14). DCL kann auch für eine Qualitätsumfrage eingesetzt werden und schickt in diesem Ausnahmefall eine entsprechende E-Mail an den User. Da diese Qualitätsumfrage nur sporadisch erfolgt, muss immer eine weitere E-Mail an den Kontakt bzw. meldenden User verschickt oder ein Anruf getätigt werden. Nur bei eingetragener, gültiger E-Mail-Adresse wird angenommen, dass E-Mail-Benachrichtigungen gewünscht werden (siehe S. 92 f.).

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 14: Datei inc/class.boTickets.inc.php

Wird eine Benachrichtigung aufgrund eines neuen Incident-Tickets an den User verschickt, wird aus der Konfigurations-Datei „ITILconfig.inc.php“ das aktuell zu verwendende Template (siehe Quelltextauszug 15) für den Aufbau der Nachricht herangezogen. Für jeden Fall, der in ITIL definiert ist, wird eine Template-Datei angelegt:

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 15: Datei inc/ITILconfig.inc.php

Der Inhalt jeder Nachricht kann durch die Nutzung von Templates an die Bedürfnisse der Organisation angepasst werden (siehe Quelltextauszug 16). Alle dynamischen Inhalte, wie Incident-Ticket-ID ({VAL_TICKETID}) und der geplante Abschlusstermin ({VAL_CLOSEDON}) werden während der Laufzeit durch die entsprechenden Werte ersetzt.

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 16: Datei templates/custom/itil_notify_tck_add_de.tpl

Die Ersetzung der Platzhalter und der Versand von Benachrichtigungen werden von dem Skript „inc/class.boITILNotifications.inc.php“ umgesetzt, welches universell jede Art von Benachrichtigung aus einem Template generieren kann (siehe Quelltextauszug 17). Die Ersetzung des Platzhalters für die Bestimmung des Abschlusstermins wird z. B. aus dem Prioritäts-Parameter des Incident-Tickets ausgelesen und mit der Vorgabe aus der Konfigurationsdatei „inc/ITILconfig.inc.php“ vorgenommen. Wird eine kritische Störung gemeldet, so erhält die Benachrichtigungs-E-Mail ebenfalls das Attribut „X-Priority: 1“, welches von den meisten E-Mail- Programmen als rotes Ausrufezeichen vor der Nachricht gekennzeichnet wird und die Nachricht so von anderen E-Mails visuell abhebt. Die eindeutige Referenznummer für den gemeldeten Incident wird in der Betreff-Zeile mit einem „INC“ für Incident hinterlegt und bei jeder folgenden E-Mail, wie z. B. bei einem erfolgreichen Abschluss, eingesetzt.

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 17: Datei inc/class.boITILNotifications.inc.php

Neben der Implementierung von organisationsspezifischen Benachrichtigungsprozeduren kann das Authentisierungsverfahren in DCL problemlos an existierende Benutzer-Accounts anknüpfen, wenn auch die Pflege und Verwaltung in verschiedenen Systemen erfolgen muss: Da die Benutzer in DCL nicht unbedingt den vordefinierten Benutzer-Accounts und -zugriffsmöglichkeiten in einer anderen Anmeldedomäne entsprechen müssen, ist die Trennung der Anmeldedaten beispielsweise für die Anmeldung an einem Arbeitsplatzrechner und an DCL sinnvoll. Eine Übernahme bestehender Benutzer-Accounts oder ein Abgleich mit bestehenden LDAP-Verzeichnissen wird in dieser Arbeit nicht behandelt.

4.3.3 Umsetzung der Wunschkriterien

Die Wunschkriterien bilden jeweils die spezifischen Anforderungen von Sonderhoff ab, die nicht unbedingt für den IT Service DeskTop als Universalapplikation für das Incident-Management im Service Desk erforderlich sind, jedoch Arbeitszeiteinsparungen und somit Effizienzsteigerungen bei der täglichen Arbeit mit dem IT Service DeskTop erreichen. An erster Stelle werden die fehlenden Anforderungs-Kriterien aus der Praxis (siehe 3.2.3.2.2.3) mit Bezug auf Sonderhoff umgesetzt; auf die nicht so umfangreichen Modifikationen, die das „Look & Feel“¹⁵⁶ verbessern, wird nicht eingegangen.

Die Einbindung der LDAP-Technologie in den IT Service DeskTop ermöglicht die Zuordnung von existierenden Domänen-Accounts und beliebigen Elementen der IT-Infrastruktur als CIs. In LDAP-Verzeichnissen werden Informationen in einer Baum-Struktur über die Konfiguration einer unternehmensweiten IT-Infrastruktur verwaltet und können in PHP mit einer einfachen Abfrage-Syntax eingebunden werden. Bei Sonderhoff soll ein proprietäres Microsoft Active Directory®-Verzeichnis im IT Service DeskTop eingebunden werden. Um die LDAP-Unterstützung in PHP zu aktivieren, sei auf die ausführliche Anleitung in der Dokumentation von PHP verwiesen.¹⁵⁷

Die interessanten LDAP-Informationen beziehen sich auf die Benutzer- Accounts, um eindeutige Zuordnungen von Störungs-Tickets auf einen bestimmten User zu erhalten. Außerdem können Eingabefehler ausgeschlossen werden, wenn die Baum-Struktur aus dem LDAP- Verzeichnis ähnlich dem Dialog der CIs aus 4.3.2.3 abgebildet und über einen Klick auf den entsprechenden User dem neuen Incident-Ticket zugeordnet wird. Auf der anderen Seite wird durch die Eindeutigkeit des Kontakts eine Abfrage möglich, die alle Anfragen eines bestimmten Users auflistet. Detailinformationen über den Benutzer-Account sind dann über eine Abfrage des LDAP-Servers zu realisieren und zu verwalten. Entsprechende Vorteile ergeben sich aus der Integration der CIs aus dem LDAP-Verzeichnis. Da die LDAP-Schnittstelle ein Wunschkriterium ist, kann diese optional über einen Parameter in der ITIL-Konfigurationsdatei hinterlegt werden. Die Einstellungen für den LDAP-Server werden ebenfalls in die Installationsroutine mit eingebunden.

Die LDAP-Integration wird an dieser Stelle exemplarisch für die BenutzerAccounts vorgestellt:

Wie in Abbildung 25 angedeutet, wird bei der Neuaufnahme oder Bearbeitung eines Incident-Tickets über eine Schaltfläche (1.) die Auswahl von LDAP-Benutzern oder -Kontaktobjekten ermöglicht. Ein Dialog- Fenster (2.) zählt dabei alle gepflegten Kontakte aus der LDAP-Datenbank auf, um über einen Mausklick die hinterlegten Daten des Kontakts in die entsprechenden Eingabefelder des IT Service DeskTops einzufügen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 25: LDAP-Integration bei der Auswahl eines Kontakts

Bei der Betätigung der Schaltfläche wird das LDAP-Schnittstellen-Skript „ldap/class.htmlLDAPAccounts.php“ über ein neues Fenster geladen; da der Abruf der relevanten Daten von einem LDAP-Server abhängig von der Größe des zu verwaltenden Verzeichnisses ist, kann die Abfrage über das PHP-Skript unter Umständen mehrere Sekunden dauern. Eine gute Möglichkeit bietet hier das Zwischenspeichern einer Anfrage mit allen relevanten Inhalten über Kontakte in einer so genannten „Cache-Datei“, die bei Bedarf erneuert wird. So kann das Fenster in weniger als einer Sekunde aufgebaut werden (siehe Quelltextauszug 18).

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 18: Datei ldap/class.htmlLDAPAccounts.php

Nach der Auswahl des zutreffenden User-Accounts wird zusätzlich eine eindeutige Referenz¹⁵⁸ des Kontakts in das Symptome-Textfeld übertragen, die, ähnlich wie bei der Einbindung der Erfahrungs- datenbankeinträge (siehe 4.3.2.6, S. 106), durch einen Hyperlink auf die Detailinformationen eines Benutzer-Accounts oder Kontakts per Mustererkennung ersetzt wird (siehe Abbildung 26).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 26: Hyperlink auf die Detailinformationen des LDAP-Accounts

Abbildung 27 demonstriert den Fall, dass keine LDAP-Integration möglich ist: Die Schaltfläche für die Auswahl der Kontakte wird hier mit einer Abfrage über alle bisherigen Incident-Tickets hinterlegt (1.), die eine von Duplikaten befreite Liste aller bisherigen Kontaktdaten liefert (2.) mit der Zuordnung der E-Mail-Adresse, Telefonnummer und den hinterlegten Kundeninformationen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 27: Auswahl von Kontaktdaten aus der Incident-Ticket-Historie

Die Integration der eindeutigen Kontakt- und CI-Daten aus einem LDAPVerzeichnis erleichtert und verbessert die Übersicht und Verwaltung der Konfigurationsdatenbank erheblich (siehe Abbildung 28): Über zwei neue Menüeinträge (1.), die, wie unter 4.3.2.6 beschrieben, eingebunden werden, können alle Incident-Tickets zu einem Benutzer-Account oder einem Infrastruktur-CI abgefragt werden (2.).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 28: Suche nach Störungen bestimmter CIs oder Nutzer

Die Überführung alter Erfahrungsdatenbestände in den IT Service DeskTop ist für Sonderhoff mit geringem Aufwand manuell umzusetzen, da bereits ein Großteil aller Erfahrungsdokumente in einem E-Mail-Format mit Dateianlagenunterstützung vorliegen und per „Ziehen und Ablegen“¹⁵⁹ mit der Maus in die Wissensdatenbank eingefügt werden können. Bei der Neuanlage der Wissensdatenbank macht es daher auch Sinn, über die Aktualität und Kategorisierung von Elementen neu zu entscheiden.

Eine automatische Backup-Funktion, wie in dem Anforderungskatalog gefordert, ist über das Betriebssystem möglich, da die Datenbestände aus der Datenbank und die Dateianhänge im Dateisystem vorliegen und problemlos in ein tägliches Sicherheitskonzept integriert werden können.

4.3.4 Installation und Distribution

Die Installation des IT Service DeskTop kann in vier Schritten erfolgen:

Zuerst werden alle benötigten Komponenten, wie die aktuelle Version von DCL „dcl-0.9.4.2.tar.gz“, die aktuelle Version von SITR „SITR-2.0.4.tar.gz“ und die freie Version des CI2XML-Programms „ci2xml-0.01.zip“, aus den entsprechenden Distributions-Dateien extrahiert und in einen Ordner „ITILSDT“ für IT Service DeskTop verschoben. Dabei werden alle Dateien von DCL unverändert in den Ordner „ITILSDT“ und alle Dateien von SITR in den Unterordner „ITILSDT/KB“ kopiert. Die Dateien aus dem ci2xml- Archiv werden in den Unterordner „ITILSDT/CI2XML“ verschoben. Als zweiter Schritt werden nun alle Dateien aus dem Archiv „itilsdt-0.1.0.zip“ in den Ordner „ITILSDT“ kopiert, wobei alle modifizierten Dateien überschrieben werden müssen. Somit sind die Vorbereitungen der Installation abgeschlossen und die Basis-Versionen von DCL und SITR auf den IT Service DeskTop migriert.

Das Datenbankschema und alle Parameter für ITIL werden über den Import des SQL-Skripts „ITILSDTSetup-0.1.0.sql“ in die MySQLDatenbank voreingestellt. Die angelegte MySQL-Datenbank hat per Voreinstellung den Namen „ITILSDT“.

Nach der erfolgreichen Übernahme des ITILSDT-Datenbank-Schemas erfolgt die Konfiguration über den Web-Browser. Über eine lokale IntranetAdresse¹⁶⁰ können daraufhin die Parameter über einen modifizierten Installations-Assistenten weiter fortgesetzt werden.

Über einen Hyperlink, der am Ende der Installation eingeblendet wird, gelangt man auf die Anmelde-Maske des IT Service DeskTops. Mit dem Benutzernamen „sa“ und dem gleich lautenden Passwort ist der IT Service DeskTop bereit für das Incident Management und den Einsatz im Service Desk. Anschließende organisationsspezifische Anpassungen, wie z. B. die Anlage der Service-Desk-Benutzer und Abteilungen ist dann unter dem Menü-Punkt „Admin“ modifizierbar (siehe Abbildung 15, S. 91).

Alle verwendeten und aufgeführten Dateien und Ressourcen sowie diese Arbeit in digitaler Form liegen der beiliegenden CD-ROM als Distribution bei.

4.4 Zusammenfassung

Der Implementierungsteil dieser Arbeit zeigt, dass aus einem bereits entwickelten OSS-Produkt, wie in diesem Falle DCL, ein vollwertiges und umfassendes ITIL-Tool für das Incident-Management im Service Desk erarbeitet werden kann. Durch die detaillierte Analyse und die Abgrenzung der Kriterien ist es innerhalb dieser Arbeit möglich, alle wichtigen Anforderungen schrittweise umzusetzen.

Eine anschließende Evaluation des IT Service DeskTops anhand des Anforderungskatalogs aus 3.1 kann auf die Kriterien reduziert werden, die in dem Ursprungsprodukt DCL nicht erfüllt sind: Alle Schwächen der Basis-Version von DCL in Bezug auf ITIL und der Praxis sind in der Implementierungsphase beseitigt worden.

Der IT Service DeskTop bildet nun den Prozess des ITIL Incident Management im Service-Desk-Bereich vollständig ab. Exemplarisch wurde in dieser Arbeit der Fokus auf mittlere bis kleine Unternehmen gesetzt, auf die der IT Service DeskTop als Open-Source-Lösung zugeschnitten ist. Weitere Prozesse von ITIL werden nicht durch den IT Service DeskTop abgebildet, da die ITIL-Einstiegsbereiche für Unternehmen im Vordergrund stehen.

5 Schlussbemerkungen und Ausblick

Für die Implementierung eines automatisierten ITIL Service Desk mit Open Source Software muss keineswegs eine völlig neue Software programmiert werden: Es gibt sehr viele Open-Source-Projekte, die sich mit Themen wie Help Desk, Ticket Tracking usw. beschäftigen.

Die umfassende ITIL-Alternative ist aus der Recherche in dieser Arbeit nicht hervorgegangen, obwohl vereinzelt Mitglieder der Open-Source- Gemeinde diesen Gedanken geboren haben, ihn aber noch nicht bis zur Vollendung oder gar in Ansätzen realisieren konnten.

Das Lösungskonzept dieser Arbeit basiert daher auf einer Kombination verschiedener OSS-Projekte, die sich gegenseitig ergänzen. Die einzelnen Projekte müssen zwar manuell zusammengeführt werden, doch eine angepasste ITIL-Parametrisierung in Form von Modifikationen und Add-Ons standardisiert die Installation und Konfiguration.

Diese Arbeit zeigt, dass derartige Anpassungen von Open-Source- Produkten im ITIL-Umfeld unumgänglich sind, was dazu führt, nur solche Open-Source-Projekte auszuwählen, bei denen Quelltext-Änderungen möglichst einfach realisiert werden können.

Wichtige Kriterien für die Auswahl eines Open-Source-Service-Desk- Produkts sind die ITIL-Konformität, Anpassbarkeit, Erfahrung des Projektteams, letzte Aktualisierung, Anzahl der Programmierer im Core Team, Mehrsprachigkeit, Interoperabilität und Plattformunabhängigkeit. Als beste Lösung erwies sich das Open Source Projekt: Double Choco Latte (DCL), eine Help-Desk-Applikation mit den umfangreichsten Möglichkeiten, mittlerer bis hoher ITIL-Konformität und leichter Anpassbarkeit.

Als Grundlage für die Konfigurations- und Erfahrungsdatenbank wird das Projekt „Support and Information Tracker“ (SITR) in DCL integriert, da hier eine sehr einfache Zusammenführung der Authentisierungsprozeduren und der Datenbanken möglich ist.

Aus der Kombination von Open Source Software als Basis und Modifikationen und Anpassungen im Bereich des ITIL Incident Management sowie Service Desk geht aus dieser Arbeit ein vollwertiges Open Source Tool für den ITIL Service Desk hervor: der IT Service DeskTop.

Mit dem in dieser Arbeit erstellten Tool für die Unterstützung des ITIL Service Desk ist es kleinen bis mittleren Unternehmen möglich, ihrer IT ein Werkzeug an die Hand zu geben, welches den ITIL-Best-Practice-Ansatz bereits implementiert. Nicht nur zu vernachlässigende Anschaffungskosten, eine einfache Installation und ein hohes Maß an Anpassungsfähigkeit zeichnen den IT Service DeskTop aus.

Nicht zu empfehlen ist der Einsatz eines ITIL-Tools, wenn in den einsetzenden Unternehmen nicht nach ITIL ausgerichtete IT-Prozesse implementiert wurden: Ein Tool für die Automatisierung ersetzt keinesfalls die Schulung der Mitarbeiter, ITIL-konform zu handeln. Auch die Endbenutzer sollten vor einem Einsatz des IT Service DeskTops darüber informiert werden, dass ab einem gewissen Zeitpunkt automatisch Benachrichtigungs-E-Mails auf Anfragen verschickt werden und, wie damit umzugehen ist.

Als Fazit lässt sich festhalten: Der Aufwand für die Implementierung des ITIL Service Desk aus bestehender Open Source Software ist eher gering. Allerdings muss ITIL-Best Practice in den einsetzenden Unternehmen gelebt werden.

6 Literaturverzeichnis

6.1 Printquellen

Abbildung in dieser Leseprobe nicht enthalten

6.2 Elektronische Quellen

Abbildung in dieser Leseprobe nicht enthalten

7 Anhang

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 17: Anforderungskatalog für OSS im Bereich des ITIL Service Desk

[...]

---

¹ Vgl. Koll, CZ 2/2004, S. 9.

² Vgl. Hage, R., Feldbrügge, R., CW 7/2002, S. 34.

³ Vgl. Bon, IT Service Management, S. 228 ff.

⁴ erprobte, Erfolg versprechende Methoden

⁵ Vgl. OGC, <www.ogc.gov.uk/index.asp?id=1000364> (22.05.2004).

⁶ Vgl. engl. „Business IT Alignment“.

⁷ Vgl. Masters Consulting, <www.itil-portal.de/itil.html> (22.05.2004).

⁸ Vgl. Koll, CZ 2/2004, S. 9.

⁹ Vgl. Hofmann, WI 1/2000, S. 91.

¹⁰ Ebd., S. 91.

¹¹ Vgl. Masters Consulting, <www.itil-portal.de/itil.html> (22.05.2004).

¹² Vgl. Wisothky, CZ 12/2003, S. 24.

¹³ Wiederherstellung des Zustandes vor der Änderung

¹⁴ Vgl. Masters Consulting, <www.itil-portal.de/itil.html> (22.05.2004).

¹⁵ SLA’s definieren, welche IT-Leistungen unter welchen Bedingungen geliefert werden

¹⁶ Vgl. Masters Consulting, <www.itil-portal.de/itil.html> (22.05.2004).

¹⁷ Vgl. OGC, Service support, <service_support/cd/content/ss/ss_apdx_d_01.htm>.

¹⁸ Vgl. Ebd., <service_support/cd/content/ss/ss01_01.htm#1.1.4>.

¹⁹ Vgl. engl. „Single Point of Contact“ (SPOC).

²⁰ Vgl. Addison, <www.itil.org.uk/sm-why.htm> (22.05.2004).

²¹ Vgl. OGC, Service support, <service_support/cd/content/ss/ss02_06.htm>.

²² Vgl. Addison, <www.itil.org.uk/sm-goal.htm> (22.05.2004).

²³ erste Anlaufstelle der Benutzer bei Störungen der IT

²⁴ zeitlich befristete Übergangslösung für eine Störung

²⁵ Vgl. Addison, <www.itil.org.uk/sm-activites.htm> (22.05.2004).

²⁶ Vgl. OGC, Service support, <service_support/cd/content/ss/ss05_5e.htm>.

²⁷ Vgl. Addison, <www.itil.org.uk/sm-cost.htm#040401> (22.05.2004).

²⁸ Vgl. Hage, R., Feldbrügge, R., CW 7/2002, S. 34.

²⁹ ein auf Internet-Technologie basiertes internes Netzwerk

³⁰ Vgl. OGC, Service support, <service_support/cd/content/ss/ss04_01.htm#4.1.10>.

³¹ ein erfolgreich gelöstes Problem, für das ein Work-around existiert

³² Vgl. OGC, Service support, <service_support/cd/content/ss/ss04_03.htm#4.3.1>.

³³ Änderungsanfragen wie Revisionswechsel oder Hardware- und Software Updates

³⁴ Vgl. OGC, Service support, <service_support/cd/content/ss/ss05_02.htm#5.2>.

³⁵ Vgl. OGC, Service support, <service_support/cd/content/ss/ss05_02.htm>.

³⁶ Vgl. IT-Resulting, <www.it-resulting.com/e-trolley/page_801/> (22.05.2004).

³⁷ Vgl. OGC, Service support, <service_support/cd/content/ss/ss05_06.htm>.

³⁸ Vgl. OGC, Service support, <service_support/cd/content/ss/ss05_03.htm>.

³⁹ Vgl. Koll, CZ 2/2004, S. 9.

⁴⁰ Vgl. Ebd., S. 9.

⁴¹ Vgl. Koll, CZ 2/2004, S. 9.

⁴² Kosten für die Internetverbindung

⁴³ Hetze, <http://mikro.org/Events/OS/ref-texte/hetze.html> (22.05.2004).

⁴⁴ Kern des Betriebssystems

⁴⁵ Vgl. GNU, <www.gnu.org/gnu/thegnuproject.html> (22.05.2004).

⁴⁶ Vgl. Debian, <www.debian.org/social_contract.html#guidelines> (22.05.2004).

⁴⁷ lesbarer Text eines Softwareprogramms bei Kenntnis der Programmiersprache

⁴⁸ Vgl. Mertens, Lexikon der Wirtschaftsinformatik, S. 210.

⁴⁹ Vgl. Grassmuck, Freie Software, S. 285 f.

⁵⁰ Vgl. OSI, <www.opensource.org/licenses/> (22.05.2004).

⁵¹ Vgl. Grassmuck, Freie Software, S. 284 ff.

⁵² Raymond, <[…]/RaymondCathedralBazaar/catb_g.10.html> (22.05.2004).

⁵³ Vgl. Ebd., <[…]/RaymondCathedralBazaar/catb_g.10.html> (22.05.2004).

⁵⁴ Entwicklergemeinschaft von OSS

⁵⁵ Vgl. Grassmuck, Freie Software, S. 234 ff.

⁵⁶ Marke, Produktqualität, etc.

⁵⁷ Vgl. Sun versus Microsoft

⁵⁸ Vgl. Henkel, Open Source Software from Commercial Firms, S. 12 ff.

⁵⁹ Grassmuck, Freie Software, S. 343.

⁶⁰ Vgl. Apache, <http://httpd.apache.org> (13.06.2004).

⁶¹ Vgl. Sendmail, <www.sendmail.org> (13.06.2004).

⁶² Vgl. Henkel, Open Source Software from Commercial Firms, S. 6.

⁶³ Vgl. MySQL, <http://dev.mysql.com> (13.06.2004).

⁶⁴ Vgl. PHP, <www.php.net> (13.06.2004).

⁶⁵ Vgl. Sourceforge, <www.sourceforge.net> (13.06.2004).

⁶⁶ Vgl. Freshmeat, <www.freshmeat.net> (13.06.2004).

⁶⁷ Vgl. OSTG, <www.ostg.com> (13.06.2004).

⁶⁸ Vgl. Vepstas, <http://linas.org/linux/pm.html> (13.06.2004).

⁶⁹ Grassmuck, Freie Software, S. 243.

⁷⁰ Vgl. Mantz, Rechtsfragen von Open Source, S. 10.

⁷¹ Ebd., S. 13 f.

⁷² Vgl. Mantz, Rechtsfragen von Open Source, S. 21.

⁷³ Vgl. Ebd., S. 26.

⁷⁴ Hengl, CZ 8/2004, S. 5.

⁷⁵ Vgl. Mantz, Rechtsfragen von Open Source, S. 20 f.

⁷⁶ Vgl. Mantz, Rechtsfragen von Open Source, S. 24.

⁷⁷ Ebd., S. 34.

⁷⁸ Grassmuck, Freie Software, S. 246.

⁷⁹ Vgl. Koll, CZ 4/2004, S. 16.

⁸⁰ Vgl. OSI, <www.opensource.org/licenses/> (13.06.2004).

⁸¹ Vgl. Ebd., <www.opensource.org/docs/definition.php> (13.06.2004).

⁸² Vgl. engl. „ITIL-Wording“.

⁸³ Vgl. OGC, Service support, <service_support\cd\content\ss\ss05_10.htm>.

⁸⁴ Vgl. Ebd., <service_support\cd\content\ss\ss_apdx_a_02.htm>.

⁸⁵ Vgl. OGC, Service support, <service_support\cd\content\ss\ss05_5c.htm>.

⁸⁶ genauere Bezeichnung des Schließgrundes für einen Incident

⁸⁷ Vgl. engl. „Impact, Urgency, Priority“.

⁸⁸ Vgl. OSI, <www.opensource.org/licenses/> (13.06.2004).

⁸⁹ Vgl. engl. „Skills“.

⁹⁰ Vgl. engl. „Last Change“.

⁹¹ Webserver, Datenbank, Skript-Sprachen

⁹² Vgl. Koll, CZ 4/2004, S. 16.

⁹³ Vgl. Lightweight Directory Access Protocol (LDAP) oder Microsoft Active Directory®.

⁹⁴ Vgl. Druckerschnittstellen, Switches, Virus-Alarm-Meldungen, etc.

⁹⁵ Vgl. Rovers, SW 11/2002, S. 14.

⁹⁶ Vgl. Infra, <www.infra.com.au/helpdesksoftware.asp> (13.06.2004).

⁹⁷ Vgl. OGC, Service support, <service_support/cd/content/ss/ss10_02.htm>.

⁹⁸ Evaluation mit einfachen Mitteln, wie z. B. mit Ausprobieren, möglich

⁹⁹ Vgl. PHP, PERL, HTML, Javascript, ASP, etc.

¹⁰⁰ Vgl. Debian, <www.debian.org> (13.06.2004).

¹⁰¹ Vgl. Vepstas, <http://linas.org/linux/pm.html> (13.06.2004).

¹⁰² Vgl. Zope, <www.zope.org> (13.06.2004).

¹⁰³ Vgl. Python, <www.python.org> (13.06.2004).

¹⁰⁴ von der Idee zum ablauffähigen Programm

¹⁰⁵ Vgl. Medusa, <www.nightmare.com/medusa> (13.06.2004).

¹⁰⁶ Vgl. OSI, <www.opensource.org/licenses/zpl.php> (13.06.2004).

¹⁰⁷ Vgl. Vepstas, <http://linas.org/linux/pm.html> (13.06.2004).

¹⁰⁸ Vgl. Apache, <http://httpd.apache.org/> (13.06.2004).

¹⁰⁹ Vgl. OSI, <www.opensource.org/licenses/php.php> (13.06.2004).

¹¹⁰ Vgl. Vepstas, <http://linas.org/linux/pm.html> (13.06.2004).

¹¹¹ Vgl. Portalux, <[…]/development/project-management/> (13.06.2004)

¹¹² Vgl. Vepstas, <http://linas.org/linux/pm.html> (13.06.2004).

¹¹³ Vgl. Tracker, <[…]/Members/klm/TrackerWiki/FrontPage> (13.06.2004).

¹¹⁴ Vgl. Knowledgekit, <[…]/Members/Bill/Products/KnowledgeKit> (13.06.2004).

¹¹⁵ Vgl. Openticket, <http://sourceforge.net/projects/openticket/> (13.06.2004).

¹¹⁶ Vgl. Midnightxen, <http://midnightxen.sourceforge.net> (13.06.2004).

¹¹⁷ Vgl. Free2Work, <http://sourceforge.net/projects/f2w> (13.06.2004).

¹¹⁸ Vgl. PostgreSQL, <www.postgresql.org/> (13.06.2004).

¹¹⁹ Vgl. Vepstas, <http://linas.org/linux/pm.html> (13.06.2004).

¹²⁰ Vgl. DCL, <http://sourceforge.net/projects/dcl> (13.06.2004).

¹²¹ Vgl. IRM, <http://irm.schoenefeld.org> (13.06.2004).

¹²² spezielle Art einer Datenbank für die Darstellung von IT-Landschaften

¹²³ Vgl. Dotproject, <www.sourceforge.net/projects/dotproject> (13.06.2004).

¹²⁴ Vgl. Help Center Live, <www.helpcenterlive.com> (13.06.2004).

¹²⁵ Vgl. Issue Tracker, <http://issue-tracker.com> (13.06.2004).

¹²⁶ Vgl. Open-Itil, <http://open-itil.nl/> (13.06.2004).

¹²⁷ Vgl. Webhuis, <http://webhuis.nl/> (13.06.2004).

¹²⁸ Vgl. SITR, <http://sitr.sourceforge.net> (13.06.2004).

¹²⁹ Software-Emulation einer Hardware-Umgebung

¹³⁰ Vgl. VMWare, <www.vmware.com> (13.06.2004).

¹³¹ Vgl. Debian, <http://www.debian.org> (13.06.2004)

¹³² Vgl. PHP, <www.php.net> (13.06.2004).

¹³³ Vgl. Apache, <http://httpd.apache.org> (13.06.2004).

¹³⁴ Vgl. Free2Work, <http://sourceforge.net/projects/f2w> (13.06.2004).

¹³⁵ Zope Management, <http://localhost:8080/manage> (02.07.2004).

¹³⁶ Vgl. Free2Work, <http://sourceforge.net/projects/f2w> (13.06.2004).

¹³⁷ Vgl. OGC, Service support, <service_support\cd\content\ss\ss_apdx_a_02.htm>.

¹³⁸ Vgl. DCL, <http://sourceforge.net/projects/dcl> (13.06.2004).

¹³⁹ Vgl. engl. „Document Root“.

¹⁴⁰ Vgl. DCL, <http://sourceforge.net/projects/dcl> (13.06.2004).

¹⁴¹ Der Hauptentwickler gab an, vor meinem Kontakt noch nie von ITIL gehört zu haben.

¹⁴² XML ist Akronym für „eXtensible Markup Language“.

¹⁴³ Vgl. DevPHP, <http://devphp.sf.net/> (11.07.2004).

¹⁴⁴ Vgl. Sonderhoff GmbH, <www.sonderhoff.de> (11.07.2004).

¹⁴⁵ abhängig vom benutzten Oberflächendesign innerhalb von DCL

¹⁴⁶ Vgl. OGC, Service support, <service_support/cd/content/ss/ss05_5a.htm>.

¹⁴⁷ z. B. über E-Mail-Verteilerlisten

¹⁴⁸ Vgl. engl. „Graphical User Interface“.

¹⁴⁹ ein Suchmuster, um Übereinstimmungen in einer Eingabe oder Texten zu finden

¹⁵⁰ Vgl. PHP-Handbuch, <www.php.net/manual/de/> (11.07.2004).

¹⁵¹ Vgl. OGC, Service support, <service_support/cd/content/ss/ss04_01.htm#4.1.11>.

¹⁵² einmalige Authentisierung für verschiedene Programme

¹⁵³ Informationen, die während einer Web-Browser-Sitzung gespeichert werden

¹⁵⁴ gültige, zeitbegrenzte Anmeldung, die an unabhängige Prozesse weitergegeben wird

¹⁵⁵ Vgl. OGC, Service support, <service_support/cd/content/ss/ss04_01.htm#4.1.11>.

¹⁵⁶ die Fähigkeit, sich in einer GUI schnell orientieren zu können

¹⁵⁷ Vgl. PHP-Handbuch, <www.php.net/manual/de/> (24.07.2004).

¹⁵⁸ bleibt auch bei Namensänderungen des Kontakts erhalten

¹⁵⁹ Vgl. engl. „Drag & Drop“.

¹⁶⁰ Vgl. IT Service DeskTop Setup, <http://127.0.0.1/itilsdt/setup/index.php>.