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ätsstandards entsprechen zu müssen. […] Mit der vorliegenden Arbeit wird 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. […] 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.

Kapitel 2.3, Trouble Ticket Systeme: Zur Unterstützung des Incident Managements empfiehlt ITIL [OGC 2003] die Verwendung entsprechender Automatisierungs-Software (Tools). In diesem Abschnitt geht es daher um eine spezielle Art Management-Software, die sich besonders für die Aktivitäten im Zusammenhang mit dem Annehmen und Erfassen (vgl. Teilprozess 1: Incident Detection and Recording [OGC 2003]) sowie dem Monitoring und Tracking eignet (vgl. Teilprozess 6: Ownership, Monitoring, Tracking and Communication [OGC 2003]). Diese Art Software wird überwiegend unter der Bezeichnung Trouble Ticket System (TTS) geführt, wobei teilweise auch Kombinationen der Begriffe Trouble, Bug, Incident, Request, Problem und Ticket oder Tracking verwendet werden, überwiegend aber jeweils Ähnliches bis Gleiches gemeint ist: Die Software soll sicherstellen, dass der Überblick hinsichtlich noch zu erledigender Aktivitäten nicht verloren geht und bereits vorhandenes Wissen jederzeit abrufbar ist. Im folgenden Unterabschnitt wird zunächst der Begriff Trouble Ticket System definiert, anschließend werden die an ein zeitgemäßes Trouble Ticket System zu stellenden Anforderungen betrachtet. 2.3.1 Definition: Trouble Ticket System: Ein Trouble Ticket System (TTS) ist eine Art von Software, um Empfang, Bestätigung, Klassifizierung und Bearbeitung von Kundenanfragen (Trouble-Tickets) zu handhaben. Moderne TTS unterstützen dabei verschiedene Medien wie Web, Mails und Faxe und haben offene Schnittstellen zu anderen Systemen wie z. B. Kun-dendatenbanken. Die Einsatzgebiete von Trouble Ticket Systemen sind dabei vielfältig, das Grundprinzip solcher Systeme ist aber ähnlich. Unabhängig davon ob es sich um Problem Tracking Systeme, Bug Tracking Systeme, Feature Request Systeme etc. handelt, wird grundsätzlich zu einem Vorgang ein Ticket mit einer Beschreibung der aufgetretenen Situation angelegt, zu der mit der Zeit weitere Informationen in Form von Ticketeinträgen hinzugefügt werden. Dabei kann es sich um Informationen aus Telefongesprächen handeln, oder auch einfach um Anmerkungen, die sich im Laufe der Zeit zu dem Vorgang ergeben und bei der weiteren Bearbeitung eventuell als hilfreich herausstellen können. Ein Trouble Ticket ist dabei ein Datensatz für genau eine Störung, der zumindest Störungsmelder, betroffene Komponente, Störsymptome und Lösung enthält [Kruse 2001]. Zusätzlich zur erfassten Information erhalten die Tickets weitere Angaben in Form von Metadaten, mit deren Hilfe es ermöglicht wird, den Datensatz selbst oder ähnliche Vorgänge im System zu suchen. Ein Trouble Ticket dokumentiert den gesamten Lebenszyklus eines Incidents, Problems oder Fehlers. Ein (minimales) Trouble Ticket System muss somit neben Ein- und Ausgabe-Möglichkeiten mindestens aus einer Datenbank zur Speicherung der Tickets sowie zur Recherche im Datenbestand bestehen. Neben diesen grundsätzlichen Bestandteilen verfügen moderne Systeme über eine Reihe weiterer Funktionalitäten, auf die im nächsten Unterabschnitt eingegangen wird. [...] 2.4 Open Source Software: Im letzten Abschnitt der theoretischen Grundlagen zu dieser Arbeit wird zunächst das hinter dem Begriff Open Source Software (OSS) liegende Konzept erläutert Anschließend wird ein Werkzeug zur Entscheidungsunterstützung vorgestellt, welches im späteren Verlauf der Evaluierung verwendet werden soll. Der Abschnitt zur Definition der Open Source Software basiert vollständig auf einer im Vorfeld dieser Arbeit durchgeführten Projektarbeit (siehe [Vilt 2007]). Im Rahmen des Projekts wurde zur fallbezogenen Beurteilung der Eignung jeweils konkreter Open Source Software eine 4-Felder-Entscheidungs-Matrix für OSS erstellt, die am Ende des Abschnitts in diese Arbeit eingeführt wird. Im dritten Kapitel soll das Werkzeug zur Vorauswahl der zu evaluierenden Trouble Ticket Systeme herangezogen werden. 2.4.1 Definition: Open Source Software: Die Bezeichnungen Open Source Software bzw. Free Software werden vielfach als Synonym für kostenlose Software gehalten [Wichmann 2005]. Die tatsächlich dahinter liegenden komplexen Konzepte zur Erweiterung der Rechte sowie auch einiger Pflichten der Softwarebenutzer müssen daher kurz angesprochen werden. Der Begriff ‘Freie Software’ bzw. dessen amerikanische Bezeichnung ‘Free Software’ wurde Mitte der 1980er Jahre von Richard Stallman (Begründer der Free Software Foundation, FSF) geprägt. Nach dessen Definition (vgl. [Stallman-1]) lässt sich die Freiheit einer Software in verschiedene Stufen aufteilen, beginnend mit der Freiheit, eine Software unabhängig vom Verwendungszweck benutzen zu dürfen (Stufe 0), die Software untersuchen, verstehen und anpassen zu dürfen (Stufe 1) sowie Kopien verteilen zu dürfen (Stufe 2) bis hin zur Freiheit, die Software zu verändern, zu verbessern und diese zu veröffentlichen, damit dies der Gemeinschaft diene (Stufe 3). Hinter dieser Definition von ‘free’ steckt eine gesellschaftliche, teils auch politische (vgl. [Grassmuck 2004]) Intention im Sinne von umfassenden Freiheiten, sie erstreckt sich keinesfalls nur auf den Preis der Software, wie auf den ersten Blick eventuell suggeriert wird. Der Terminus Open Source entstand Anfang 1998 als Antwort der Open Source Initiative (OSI) auf verschiedene Probleme, die sich aufgrund der ideologisch geprägten Definition von Free Software bis dahin ergeben hatten (vgl. [Stallman 2007] zu dessen aktueller Sicht der Dinge). Open Source sollte nun als eine Art Symbol unter ganz pragmatischen Zielsetzungen einen gemeinsamen Nenner bilden für alles, was quelloffene freie Software charakterisiert und mit dem auch und gerade die kommerzielle Software-Industrie noch leben kann [Siekmann 2001]. Beide Initiativen (FSF und OSI) sind am Markt aktiv, und regeln im wesentlichen das gleiche. Der Unterschied zwischen beiden liegt darin, dass die FSF soziale Gründe berücksichtigt, während die Open Source Bewegung mehr Wert auf die praktischen Aspekte legt (vgl. [Gläßer 2004]). In beiden ist der freie Zugang zum Quellcode jedenfalls elementar. Damit die Freiheit der Software in der beabsichtigten Form garantiert werden kann, stellt der ursprüngliche Entwickler seine Arbeit unter eine ‘freie Software-Lizenz’. Hierzu wird überwiegend (vgl. [Heinze und Keller 2004]) die GNU General Public License (GPL) verwendet, deren hauptsächliches Anliegen im sog. Copyleft liegt. Demnach müssen Modifikationen einer Software, die unter der GPL-Lizenz stand, selbst wiederum dieser Lizenz unterliegen, wodurch freie Software vor Patentierungsbestrebungen und Besitzansprüchen geschützt wird (vgl. [Grassmuck 2004]). Eine allgemein anerkannte Definition von Open Source Software stammt von der Open Source Initiative (OSI). Die Open Source Definition (OSD) baut dabei auf der Definition der freien Software auf, verfolgt aber einen deutlich anderen, kommerzielleren Ansatz (vgl. [Karduck 2004]). [...]

• Incident Management

• KMU

• Software-Entwicklung

• Open Source Software

• IT-Infrastruktur

• De-facto-Standard

• IT Infrastructure Library

• Software-Hersteller

• Open Ticket Request System

• ITIL