Incident Management mit Open Source Software E-Book

Lajos Vilt

• Herausgeber: GRIN Verlag
• Sprache: Deutsch

Veröffentlichungsjahr: 2007

Beschreibung

Diplomarbeit aus dem Jahr 2007 im Fachbereich Informatik - Wirtschaftsinformatik, Note: 1,0, Fachhochschule Dortmund, Sprache: Deutsch, Abstract: Der Zielsetzung entsprechend wurde im Rahmen dieser Arbeit ein Automatisierungswerkzeug zur Abbildung des Incident Managements gesucht und schließlich mit dem Trouble Ticket System OTRS::ITSM auch gefunden. Die Evaluierung erfolgte dabei mit Hilfe eines Anforderungskataloges, der auf die Geschäftsprozesse des betrachteten Unternehmens ausgerichtet die Best Practices eines anerkannten De-facto-Standards, der ITIL abprüfte. Der hierzu auf Basis früherer Arbeiten verfeinerte Anforderungskatalog konnte auf das im Rahmen einer durchgeführten Recherche identifizierte Produkt OTRS::ITSM erfolgreich angewendet werden und dadurch seine Praxis-Tauglichkeit unter Beweis stellen. Neben dem gefundenen Trouble Ticket System steht somit als Ergebnis der Arbeit ein erprobtes Werkzeug zur Evaluierung geeigneter Software-Produkte für das Incident Management in kleineren und mittelständischen Unternehmen zur Verfügung. Aufgrund seiner Struktur und insbesondere auch wegen der Auslagerung spezieller Kriterien in Bezug auf Open Source Software, ist der Anforderungskatalog geeignet, beim Test weiterer - auch proprietärer - Software für das Incident Management Ergebnisse zu liefern, die einen direkten Vergleich der getesteten Produkte auf sehr feiner Abstraktionsebene zulassen. Die Produkte können somit einem differenzierten Ranking unterzogen werden, womit dem zweiten Anliegen dieser Arbeit entsprochen wurde. Wie die Arbeit zeigt gibt es im Open Source Umfeld mittlerweile (mindestens) ein Trouble Ticket System, mit dem der Prozess des Incident Managements im Service Desk eines klein- und mittelständischen Software-Unternehmens nach Maßgaben der ITIL abgebildet werden kann. Da auch die weiteren, aus der Praxis resultierenden nicht funktionalen Anforderungen hinreichend erfüllt werden, kann das erfolgreich evaluierte Open Ticket Request System in Verbindung mit der ITSM-Erweiterung uneingeschränkt für den Einsatz empfohlen werden.

Leseprobe

Impressum:

Copyright (c) 2013 GRIN Verlag GmbH, alle Inhalte urheberrechtlich geschützt. Kopieren und verbreiten nur mit Genehmigung des Verlags.

Bei GRIN macht sich Ihr Wissen bezahlt! Wir veröffentlichen kostenlos Ihre Haus-, Bachelor- und Masterarbeiten.

Jetzt beiwww.grin.comhochladen und weltweit publizieren.

Coverbild: www.pixabay.com

Für Maximilian.

Zusammenfassung

Das Incident Management kleiner und mittelständischer Unternehmen aus dem Bereich der Software-Entwicklung hat sich neben Problemen im Zusammenhang mit der eigenen IT-Infrastruktur auch um die Belange der externen Kunden und Interessenten zu kümmern. Bis zu einem gewissen Umfang können die hierbei durchzuführenden Aktivitäten in der Regel ohne Tool-Unterstützung bewältigt werden und anfallende Informationen mit einfachsten Mitteln zur Texterfassung (Office-Anwendungen, Mail-Client) verwaltet werden. Früher oder später ist aber über eine unterstützende Software nachzudenken, und sei es nur aus dem Grund, im Trend der Zeit bleiben, oder bestimmten Qualitäts-Standards entsprechen zu müssen.

In diesem Zusammenhang hat sich in den letzten Jahren mit der IT Infrastructure Library auch in Deutschland ein De-facto-Standard etabliert, nach dessen Empfehlungen der Einsatz unterstützender Software zur service-orientierten Leistungserbringung dringend geboten ist.

Mit der vorliegenden Arbeit wurde daher der Versuch unternommen, die Einführung einer solchermaßen unterstützenden Software vorzubereiten. Dabei waren insbesondere die Belange bei einem eher kleinen Software-Hersteller zu berücksichtigen, bei dem die Support-Prozesse noch im überschaubaren Rahmen verlaufen und sich ein Software-Einsatz nicht unbedingt aufdrängt.

Um ein solches Projekt rechtfertigen zu können wurden zunächst die Support-Prozesse analysiert, Schwachstellen identifiziert sowie die sich bietenden Optimierungsmöglichkeiten aufgezeigt. Da letztere in ausreichender Menge zu finden waren konnte über einen Tool-Einsatz in Form eines Trouble Ticket Systems nachgedacht werden. Hierbei stellte sich aber die Frage, ob eine Anschaffung oder Eigenentwicklung wirtschaftlich vertretbar ist. Die Beantwortung konnte dahingestellt bleiben, wenn es am Markt geeignete Software-Produkte aus dem Bereich der Open Source gibt. Eine solche Software sollte gesucht und gegebenenfalls auf ihre Gebrauchstauglichkeit hin evaluiert werden.

Dazu wurden im weiteren Verlauf der Arbeit zunächst die an eine unterstützende Software gestellten Anforderungen ermittelt, wobei einerseits die sehr abstrakt gehaltenen Vorgaben der IT Infrastructure Library entsprechend konkretisiert und des weiteren Belange aus der Praxis berücksichtigt werden mussten.

Die identifizierten Anforderungen wurden sodann in einen speziellen Anforderungskatalog übernommen, dem im Rahmen dieser Arbeit in mehrfacher Hinsicht eine besondere Bedeutung zukommt. Einerseits war nicht abzusehen, dass innerhalb der zur Verfügung stehenden Bearbeitungszeit tatsächlich eine Software abschließend beurteilt werden konnte. Daher wurde ein Instrument benötigt, mit dem die Suche jederzeit fortgesetzt oder wiederaufgenommen werden konnte, wenn sich die zunächst präferierte Software als ungeeignet herausstellen sollte. Des weiteren sollte ermöglicht werden, Anforderungen an die unterstützende Software unterschiedlich gewichten zu können, damit die Evaluierung nach individuellen Gesichtspunkten erfolgen und die Ergebnisse unterschiedlicher Produkte auf sehr differenzierter Ebene vergleichbar gemacht werden konnten.

Als Ergebnis der Arbeit konnte mit dem Open Ticket Request System (OTRS::ITSM) eine Open Source Software identifiziert werden, welche den Prozess des Incident Managements im Service Desk eines Software-Unternehmens weitestgehend ITIL-konform abbilden kann und dabei auch die weiteren, sich aus der unternehmerischen Praxis ableitbaren Anforderungen sehr gut unterstützt.

Inhaltsverzeichnis

Zusammenfassung

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung

1.1 Aufgabenstellung

1.2 Vorgehensweise und Gliederung

1.3 Support-Prozesse des betrachteten Unternehmens

1.3.1 Beschreibung des Ist-Zustandes

1.3.2 Schwachstellenanalyse

1.3.3 Optimierungsmöglichkeiten

1.3.4 Make or Buy

2 Theoretische Grundlagen

2.1 Software Support

2.1.1 Software-Begriff

2.1.2 Support Service

2.1.3 IT Service Management

2.2 Information Technology Infrastructure Library (ITIL)

2.2.1 Überblick

2.2.2 IT Service Management nach ITIL

2.2.3 ITIL Service Desk

2.2.4 Incident Management

2.3 Trouble Ticket Systeme

2.3.1 Definition: Trouble Ticket System

2.3.2 Anforderungen an Trouble Ticket Systeme

2.4 Open Source Software

2.4.1 Definition: Open Source Software

2.4.2 SWOT-Analyse

3 Evaluierung eines geeigneten Open Source Trouble Ticket Systems

3.1 Anforderungskatalog für das Incident Management

3.1.1 Struktur des Anforderungskataloges

3.1.2 ITIL-Bewertungskriterien

3.1.3 Allgemeine Bewertungskriterien

3.1.4 Erstellung des Anforderungskataloges

3.2 Übersicht verfügbarer OSS Trouble Ticket Systeme

3.2.1 Eingrenzung des Suchfeldes

3.2.2 Auswahl verfügbarer Systeme

3.3 Evaluierung

3.3.1 Anwendung der 4-Felder-Entscheidungsmatrix für OTRS

3.3.2 Einrichtung der Testumgebung

3.3.3 Testdurchführung

3.3.4 Bewertung

4 Fazit

4.1 Zusammenfassung

4.2 Schlussfolgerungen

4.3 Ausblick – Nächste Schritte

4.3.1 Einführung des evaluierten Tools

4.3.2 Kontinuierlicher Verbesserungsprozess

4.3.3 Implementierung weiterer ITIL-Prozesse

Literaturverzeichnis

Anhang

A. OTRS Layout Anpassung des Kunden Frontends

B. erweiterte Ereignisgesteuerte Prozessketten

C. Zusammengeführter Anforderungskatalog

Abbildungsverzeichnis

Abbildung 1‑1: Ausgangssituation beim betrachteten Unternehmen

Abbildung 2‑1: Komponenten des ITSM

Abbildung 2‑2: Marktanteile der IT Infrastructure Library [Aalen 2004]

Abbildung 2‑3: ITIL-Übersicht [OGC 2002a]

Abbildung 2‑4: Wirkungskette von ITIL bis zu den Geschäftsprozessen

Abbildung 2‑5: Service Desk Ausprägungen [Olbrich 2006, Seite 22]

Abbildung 2‑6: Incident-Bearbeitung im Service Desk [OGC 2003, Annex 5E]

Abbildung 2‑7: Optimierungspotenzial im ITSM in % [Koll 2004, Seite 9]

Abbildung 2‑8: Incident, Problem, Known Error und RFC [OGC 2003, Kapitel 5.3.5]

Abbildung 2‑9: Incident Management Prozess-Umfeld [OGC 2003, Kapitel 5.2]

Abbildung 2‑10: Incident Lifecycle (vgl. [OGC 2003, Kapitel 5.3.1])

Abbildung 2‑11: Erweiterung durch Funktionsblöcke [Kruse 2001, Seite 5]

Abbildung 3‑1: Strategie zur Tool-Evaluierung (vgl. [Olbrich 2006, Seite 183])

Abbildung 3‑2: Modell zur Strukturierung der Anforderungen

Abbildung 3‑3: Beispiel zum Berechnungsverfahren (vgl. [Brenner 2002, S. 30])

Abbildung 3‑4: Incident Detection and Recording (eEPK)

Abbildung 3‑5: Classification und Initial Support (eEPK)

Abbildung 3‑6: Investigation and Diagnosis (eEPK)

Abbildung 3‑7: Resolution and Recovery (eEPK)

Abbildung 3‑8: Incident Closure (eEPK)

Abbildung 3‑9: OTRS Web-Installer (Willkommen-Bildschirm)

Abbildung 3‑10: OTRS Web-Installer (Fertig-Meldung)

Abbildung 3‑11: OTRS Start-Bildschirm

Abbildung 3‑12: OTRS Admin-Bereich

Abbildung 3‑13: OTRS::ITSM Start-Bildschirm

Abbildung 3‑14: OTRS Customer-Interface (default)

Abbildung 3‑15: OTRS Customer-Interface (individuell)

Abbildung Anhang‑1: eEPK - Elemente

Tabellenverzeichnis

Tabelle 2‑1: Gegenüberstellung von Wartung und Pflege nach [Balzert 1998]

Tabelle 2‑2: Rollen im Incident Management [Zarnekow u. a. 2005]

Tabelle 2‑3: Schnittstellen des Incident Managements

Tabelle 2‑4: Grunddaten eines Trouble Tickets nach [Kruse 2001, Seite 6]

Tabelle 2‑5: 4-Felder-Entscheidungs-Matrix für OSS

Tabelle 3‑1: Gewichtungen von (Teil-) Kriterien [Pfleger 2005, Seite 61]

Tabelle 3‑2: Definition der Bewertungsstufen

Tabelle 3‑3: Berechnungsverfahren mittels Tabellen-Kalkulationsprogramm

Tabelle 3‑4: Erweitertes Berechnungsverfahren

Tabelle 3‑5: Gewichtung der Teil-Kataloge

Tabelle 3‑6: Gewichtung der Hauptkriterien

Tabelle 3‑7: Gewichtung der Basiskriterien zur Datensicht

Tabelle 3‑8: Gewichtung der Basiskriterien zur Tool-Unterstützung

Tabelle 3‑9: Gewichtung der Basiskriterien zur Integration

Tabelle 3‑10: Gewichtung der Basiskriterien zur Ablaufsteuerung

Tabelle 3‑11: Gewichtung der Basiskriterien zur Benutzbarkeit

Tabelle 3‑12: Gewichtung der Basiskriterien zur Anpassbarkeit

Tabelle 3‑13: Gewichtung der Basiskriterien zum Betrieb

Tabelle 3‑14: Gewichtung der Basiskriterien zur Sicherheit

Tabelle 3‑15: Open Source Software Projekte

Tabelle 3‑16: 4-Felder-Entscheidungs-Matrix für OTRS::ITSM

Tabelle 3‑17: Beurteilung der Datensicht von OTRS::ITSM

Tabelle 3‑18: Beurteilung der Tool-Unterstützung von OTRS::ITSM

Tabelle 3‑19: Beurteilung der Integration von OTRS::ITSM

Tabelle 3‑20: Beurteilung der Ablaufsteuerung von OTRS::ITSM

Tabelle 3‑21: Gesamt-Beurteilung der funktionalen Anforderungen

Tabelle 3‑22: Beurteilung der Benutzbarkeit von OTRS::ITSM

Tabelle 3‑23: Beurteilung der Anpassbarkeit von OTRS::ITSM

Tabelle 3‑24: Beurteilung des Betriebs von OTRS::ITSM

Tabelle 3‑25: Beurteilung der Sicherheit von OTRS::ITSM

Tabelle 3‑26: Gesamt-Beurteilung der nicht funktionalen Anforderungen

Tabelle 3‑27: Bewertung der Tool-Evaluierung von OTRS::ITSM

Tabelle Anhang‑4‑1: gewichtete Anforderungen zur Tool-Evaluierung

Abkürzungsverzeichnis

1 Einleitung

Im Vergleich zu den großen Systemhäusern verfügen kleinere und mittelständische Unternehmen (KMU)[1] aus dem Bereich der Software-Entwicklung in der Regel über weniger Personal, geringere Budgets und weniger komplexe IT-Umgebungen (vgl. [BMC 2005]). Dies gilt auch für die - aus Sicht des Autors fälschlicher Weise leider - oft nicht zum eigentlichen Kerngeschäft der Software-Entwicklung angesehenen Geschäftsbereiche, wie zum Beispiel dem externen Software-Support. Auch KMU müssen aber zum einen sämtliche Anforderungen der (Bestands-) Kunden des Unternehmens im Rahmen von Service Level Agreements erfüllen und sich des weiteren effizient um das Neukundengeschäft sowie um aktuelle Einführungsprojekte kümmern. Daher muss auch hier versucht werden, den Betrieb der Software beim Kunden und die Unterstützung bei der Nutzung so zu gestalten, dass das Zusammenspiel aller Beteiligten (Hersteller, Kunde und Anwender auf Seiten des Kunden) wohl definiert geschieht. Nur so können die Prozesse, mit denen der Kunde sein Geld verdient, auf optimale Weise durch die lizenzierte Software ermöglicht bzw. unterstützt werden. 

In den nachfolgenden Abschnitten dieses einleitenden Kapitels wird zunächst präzisiert, welche Aufgabe sich somit stellt (Abschnitt 1.1). Anschließend wird die Vorgehensweise sowie die sich daraus ergebende Gliederung (Abschnitt 1.2) dargelegt. Das Kapitel wird ab­ge­schlossen mit der Betrachtung der Support-Prozesse eines konkreten Software-Unter­nehmens (Abschnitt 1.3).

1.1 Aufgabenstellung

Im Rahmen dieser Arbeit soll ein Automatisierungswerkzeug gefunden werden zur bestmöglichen Unterstützung der für den (externen) Anwender-Support relevanten Geschäftsprozesse des Software-Unter­nehmens. Derartige Software-Produkte werden überwiegend unter dem Begriff Trouble Ticket System subsumiert.

Es soll darüber hinaus insbesondere auch geprüft werden, ob am Markt eine geeignete Software aus dem Bereich Open Source verfügbar ist, mit der im Idealfall im Hinblick auf eine mögliche Zertifizierung der Workflow in allgemein anerkannter Weise abgebildet werden kann. In diesem Zusammenhang hat sich in jüngster Vergangenheit die IT Infrastructure Library (ITIL) als geeignetes Rahmenwerk herausgebildet und eine breite Akzeptanz erfahren (vgl. [Schmidt 2004]). Die Untersuchung ist folglich auf ITIL auszurichten.

Nach [Clauss 2006b, Seite 2] gibt es mit Stand November 2006 keine infrage kommenden Software-Lösungen, weder kommerzieller Art noch im Open Source Bereich. Gegenteiliges ist allerdings von einigen Herstellern zu vernehmen, die ihre Produkte bisweilen posthum als ITIL-konform bezeichnen.

Es soll also eine Open Source Software mit möglichst breiter ITIL-Abdeckung gesucht werden. Dazu müssen unter Einbeziehung noch aufzustellender unternehmensspezifischer Gewichtungen am Markt verfügbare Produkte einer vergleichenden Bewertung unterzogen werden können. Folglich ist eine Möglichkeit zur Verfügung zu stellen, mittels derer infrage kommende Lösungen auch noch zu einem späteren Zeitpunkt einem Ranking unterworfen werden können.

1.2 Vorgehensweise und Gliederung

Eine kurze Beschreibung der Supportprozesse des betrachteten Unternehmens (Abschnitt 1.3) schließt den einleitenden Teil dieser Arbeit ab.

Das zweite Kapitel stellt den Kontext der Arbeit vor, indem das thematische Umfeld beschrieben wird und theoretische Grundlagen zu den hinter den Konzepten Software-Support (Abschnitt 2.1), ITIL (Abschnitt 2.2), Trouble Ticket System (Abschnitt 2.3) und Open Source Software (Abschnitt 2.4) liegenden Inhalten vermittelt werden.

Das dritte Kapitel stellt den Kern der Arbeit dar. Mit einem im Abschnitt 3.1 zu erstellenden Anforderungskatalog, der auf die im zweiten Kapitel zu den Basis-Konzepten herausgestellten Anforderungen abstellt, soll ein im Abschnitt 3.2 als aussichtsreicher Kandidat identifiziertes Software-Produkt im Abschnitt 3.3 bewertet werden.

Im vierten Kapitel werden die Ergebnisse der Arbeit zusammengefasst (Abschnitt 4.1) und Schlussfolgerungen gezogen (Abschnitt 4.2). Ein Ausblick auf weitere Schritte (Abschnitt 4.3) schließt die Arbeit ab.