Zusammenfassung
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
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.
Mit dem Ergebnis der Evaluierung liegt folglich ein erster Vergleichswert vor, der -falls dies zu einem späteren Zeitpunkt erforderlich erscheint- als Maßstab bei weiteren Evaluierungen herangezogen werden kann.
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
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
Abbildung in dieser Leseprobe nicht enthalten
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 abgeschlossen mit der Betrachtung der Support-Prozesse eines konkreten Software-Unternehmens (Abschnitt 1.3).
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-Unternehmens. 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.
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.
In diesem Abschnitt wird zunächst der Ist-Zustand beim betrachteten Software-Unternehmen beschrieben (Abschnitt 1.3.1) und darauf aufbauend eine Schwachstellenanalyse durchgeführt (Abschnitt 1.3.2). Des weiteren werden die daraus gewonnenen Erkenntnisse herangezogen, um Ansatzpunkte zur Optimierung zu identifizieren (Abschnitt 1.3.3). Abschließend wird in diesem Absatz die Frage „Make or Buy?“ aufgegriffen (Abschnitt 1.3.4), also geklärt, ob die Optimierungsmöglichkeiten effizienter mit einer Eigenentwicklung realisiert werden können, oder ob es sinnvoller ist, eine Software-Lösung fremd zu beziehen.
Bei dem betrachteten Unternehmen handelt es sich um einen eher kleinen aber im deutschen Sprachraum jedenfalls im relevanten Marktsegment namhaften Hersteller individueller und sehr branchenspezifischer Software-Systeme, mittels derer die Branchenteilnehmer ihr komplettes Tagesgeschäft abwickeln können.
Einige Branchengrößen aus Deutschland, der Schweiz und Österreich zählen zu den Kunden des Unternehmens. Neben den Bestandskunden gibt es regelmäßig ebenfalls zu betreuende bzw. zu beratende Interessenten für die unterschiedlichen Software-Produkte des Unternehmens. Der Kreis potentieller Kunden wird dabei unter Service-Gesichtspunkten durchweg wie ein Bestandskunde behandelt.
Geschäftsführung und Vertrieb sowie Beratung und Support sind in Deutschland angesiedelt. Jedem Kunden und jedem Interessenten ist ein konkreter Ansprechpartner des Unternehmens benannt, der für Beratung und Support als erste Anlaufstelle dient. Die weiteren Mitarbeiter und der Geschäftsführer sind den Kunden und Interessenten ebenfalls bekannt und werden von diesen zu bestimmten Themen oder als Vertretung auch direkt kontaktiert.
Die Software-Entwicklung hingegen wird überwiegend von Mitarbeitern des Unternehmens in einem osteuropäischen Land durchgeführt, ein geringer Teil der Programmierung erfolgt auch in Deutschland.
Abbildung 1-1 zeigt in Anlehnung an [Zarnekow u. a 2005, Seite 260] die wesentlichen Eigenschaften der Ausgangssituation, differenziert nach den Beschreibungsebenen Strategie, Prozesse und Systeme sowie dem Leidensdruck.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1-1: Ausgangssituation beim betrachteten Unternehmen
Es herrscht im Unternehmen eine serviceorientierte Sichtweise vor. Die Geschäftsprozesse der Kunden werden durchweg verstanden und im Support berücksichtigt.
Die eigenen Prozesse sind eher themenbezogen und nicht durchgängig gestaltet. Eingehende Kundenanfragen, seien es nun Problemmeldungen zum Umgang mit dem Programm, Fehlermeldungen oder Änderungswünsche, werden per Chat-Tool (ICQ) oder im Falle eines Eingangs der Anfrage per Mail entsprechend an die nachgelagerten Service-Einheiten weitergeleitet, wenn die Anfrage nicht sogleich beantwortet werden kann.
Betrifft eine Anfrage ein ausschließlich in der deutschen Niederlassung zu bearbeitendes Thema, so erfolgt die Weiterleitung auch häufig nur verbal direkt von Mitarbeiter zu Mitarbeiter.
Die direkten Lösungen werden in der Regel nicht dokumentiert, es gibt aber ein internes Word-Dokument, in dem häufiger gestellte Fragen der Kunden mit entsprechenden Lösungen hinterlegt werden.
Komplexere Anfragen sowie anerkannte Programmfehler werden in Excel-Listen verwaltet, wobei jeder Mitarbeiter seine eigenen Listen pro Kunden/Interessenten pflegt.
Teilweise werden von den Kunden „Offene Posten Listen“ per proprietärer Groupware[2] oder ebenfalls per Excel vorgehalten, auf die einige Mitarbeiter des Unternehmens Zugriff haben. Zu einzelnen Kunden wird auch eine Fehler-Datenbank über eine hinzu gekaufte Software[3] geführt, die ein Front-end zu einer MS Access Datenbank darstellt.
Anzumerken bleibt noch, dass die meisten Kunden bzw. deren autorisierte Anwender bei der Verwendung von E-Mail ihre Anfragen nicht an einen konkreten Mitarbeiter senden, sondern über Verteiler-Listen oder als „CC“ an alle ihnen bekannten Mitarbeiter des Unternehmens.
Trotz der beschriebenen Zustände wird die aktuelle Situation von den Mitarbeitern und auch von den Kunden nicht als problematisch angesehen. Alle Anfragen werden vollständig und in akzeptabler Zeitspanne erledigt. Die Zusammenarbeit wird von allen Seiten jedenfalls als effektiv beurteilt. Aufgrund des somit fehlenden Leidensdrucks ergibt sich aus Sicht der meisten Mitarbeiter keine zwingende Notwendigkeit zu Veränderungen.
Obwohl die Situation wie dargelegt als wenig oder gar nicht belastend empfunden wird, lassen sich dennoch einige Mängel im bestehenden Ablauf erkennen. Diese werden nachfolgend als Schwachstellen bezeichnet zusammengefasst.
- fehlende Kontrolle offener Fälle bzw. des aktuellen Standes
Die gegenwärtig eingesetzten Systeme ermöglichen es nicht, mit vertretbaren Aufwand ad hoc einen Überblick über die eigenen offenen Fälle bzw. deren Status zu gewinnen.
- Unklarheiten hinsichtlich der Zuständigkeiten
Als eine Folge des zuvor aufgeführten Punktes ergibt sich auch der Nachteil, dass die Mitarbeiter über keine Mittel verfügen, sich rasch einen Überblick über die weitergeleiteten Fälle zu verschaffen.
- Streuung der Kommunikation
Die Streuung eingehender Anforderungs-Mails kann theoretisch dazu führen, dass die Bearbeitung gleichzeitig von mehreren Mitarbeitenden begonnen wird. Dies kommt aufgrund der räumlichen Nähe und der geringen Anzahl betroffener Mitarbeiter zwar so gut wie nie in der Praxis vor, grundsätzlich besteht aber mindestens unterschwellig ständig die Notwendigkeit zur Abstimmung.
- Reporting
Die statistische Auswertung der Support-Leistungen ist mit den derzeit zur Verfügung stehenden Mitteln nicht möglich. Bereits die Ermittlung der Anzahl bearbeiteter Anfragen insgesamt oder pro Mitarbeiter zu ermitteln, wäre nur mit unverhältnismäßigem Aufwand durchführbar. Eine Auswertung der durchschnittlichen Bearbeitungsdauer der Anfragen insgesamt oder gar nach Kunde oder Projekt kumuliert ist erst recht nicht möglich.
- Informationsdefizite
Aufgrund der teils fehlenden teils lediglich separat pro Mitarbeiter vorgehaltenen Dokumentation der bereits erfolgreich bearbeiteten Vorfälle bleiben die Synergie-Effekte aus, die entstehen könnten, wenn ohne weiteres auf bereits bekannte Lösungen zugegriffen werden kann.
Optimierungspotential ergibt sich hinsichtlich aller zuvor benannten Schwachstellen durch den Einsatz von Automatisierungs-Software.
Um die vielfältigen Aufgaben effizient bewältigen zu können bedarf es leistungsfähiger Arbeitsmittel. Damit sind nicht die einschlägigen Office-Produkte gemeint, sondern spezialisierte Software-Systeme, welche die Aktivitäten der Prozesse möglichst vollständig und durchgängig abbilden können (vgl. [Olbrich 2006, S. 181]).
Die Frage „Make or Buy?“ ist in einem Software-Unternehmen natürlich anders zu beantworten als üblich, insbesondere bei einer ins Ausland ausgelagerten und kostengünstig wirtschaftenden eigenen Entwicklungsabteilung. Hier wird man sich jedenfalls im Falle geschäftskritischer Funktionalitäten eher zu einer Eigenentwicklung entschließen als dies eventuell bei anderen Unternehmen der Fall sein wird.
Bei der Beantwortung der Frage spielt im konkreten Anwendungsfall aber auch der noch fehlende Leidensdruck bei den für Support und Beratung zuständigen Mitarbeitern eine wichtige Rolle (siehe oben Abschnitt 1.3.1).
Somit ist es derzeit nur schwer durchsetzbar, die Ressourcen der Entwicklungsabteilung auch dann zu beanspruchen, wenn geeignete und auf die eigenen Geschäftsprozesse passende Software kostenneutral (im Hinblick auf die reine Anschaffung) zu erhalten wäre.
Im zweiten Kapitel werden zum besseren Verständnis der nachfolgenden Ausführungen die theoretischen Grundlagen zusammen gestellt. Hierzu wird zunächst allgemein beschrieben, was unter Software und deren Support verstanden wird und welche Bedeutung dem Software Support als Dienstleistung im IT Service Management zukommt (Abschnitt 2.1).
Anschließend werden diejenigen Inhalte der IT Infrastructure Library (ITIL) als Beispiel eines Standardisierungsansatzes für das IT Service Management aufgeführt (Abschnitt 2.2), auf deren Basis die Service Support Prozesse identifiziert werden sollen.
Schließlich werden die hinter den Begriffen Trouble Ticket System (Abschnitt 2.3) und Open Source Software (Abschnitt 2.4) liegenden Konzepte kurz vorgestellt.
Wie bereits in der Einleitung dargelegt, müssen jedenfalls die Prozesse, mit denen ein Kunde sein Geld verdient, durch die lizenzierte Software best möglich abgebildet werden. Die Kunden eines Software-Herstellers kaufen daher in der Regel nicht bloß fertige Produkte, sondern erwarten zudem weitere Leistungen, die auf deren optimale Nutzung ausgerichtet sind. Ein derart serviceorientierter Ansatz wird unter dem Begriff IT Service Management (ITSM) erfasst, wobei die IT-Services das Fundament des ITSM darstellen und der Software Support einer dieser Services ist. Den Zusammenhang veranschaulicht die Abbildung 2-1.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2-1: Komponenten des ITSM
Hinter dem Begriff IT Service Management verbirgt sich ein ganzes Bündel von Maßnahmen und Aktivitäten, mit denen die Qualität und Quantität von IT-Services optimal und zielgerichtet geplant, überwacht und gesteuert werden kann (vgl. [Ebel 2006, Seite 17]).
Nachfolgend werden die Begriffe Software (Abschnitt 2.1.1), IT-Service und Software Support (im Abschnitt 2.1.2) näher betrachtet und in Bezug auf die in dieser Arbeit relevanten Bestandteile des IT Service Management abgegrenzt.
Unter dem Begriff Software fasst man ganz allgemein[4] alle im Gegensatz zur Hardware nicht physischen Funktionsbestandteile eines Computers bzw. eines jeden technischen Gegenstandes, der mindestens einen Mikroprozessor enthält, zusammen.
Es wird dabei differenziert nach Software, die zum Betrieb des Systems erforderlich ist (System-Software und systemnahe Software) und der Anwendungssoftware, mittels derer die Benutzer den eigentlichen Nutzen aus der Arbeit mit dem Computer erlangen, indem sie in der Abbildung ihrer Geschäftsprozesse unterstützt werden.
Anwendungssoftware lässt sich darüber hinaus nach mehreren Kriterien weiter unterteilen. Ein für die Arbeit relevantes Kriterium ist das Lizenzierungsmodel, ein weiteres liegt in der Unterscheidung von Standard- und Individual-Software.
Im Gegensatz zu Standard-Software wird Individual-Software den konkreten Anforderungen eines einzelnen Kunden entsprechend erstellt, also nicht für eine große Menge (potentieller) Kunden entwickelt[5].
Hinsichtlich des Lizenzierungsmodels und den daraus abgeleiteten Überlassungsmodellen können grob zwei Arten von Software unterscheiden werden, proprietäre (kommerzielle) Software und freie Software. Auf Letztere wird im vierten Abschnitt dieses Kapitels detaillierter eingegangen, da die im Rahmen dieser Arbeit gesuchte Software in diesem Umfeld gefunden werden soll.
Proprietäre Software kann auf zwei unterschiedliche Arten kommerzialisiert werden, sie kann verkauft werden oder es kann ein Nutzungsrecht an der Software überlassen werden.
Der vollständige Verkauf inklusive aller weitergehenden Rechte kommt relativ selten vor und ist auf den Bereich spezieller Auftragsprogrammierung oder eines Unternehmensübergangs beschränkt. Üblicher ist sowohl bei Individual-Software als auch erst Recht bei Standard-Software hingegen die Gebrauchsüberlassung.
Die Software-Produkte des betrachteten Unternehmens werden zu kommerziellen Zwecken auf dem Markt angeboten, es handelt sich aufgrund eines jeweils pro Kunden umfangreich durchgeführten Customizing[6] um Individual-Software. Neben den Software-Produkten müssen, wie bereits aufgezeigt, weitere Dienste[7] zur Unterstützung[8] angeboten werden. Um diese Dienste geht es im nächsten Unterabschnitt.
Die Begriffe Support und Service müssen aufgrund ihrer in der Literatur je nach Anwendungsgebiet unterschiedlichen Verwendung genauer betrachtet werden (vgl. [Eidner 2004, Seite 3]), damit dargelegt werden kann, wie der aus diesen beiden Begriffen zusammengesetzte Begriff Support Service im Rahmen dieser Arbeit verwendet wird. Abschließend wird auf den im Rahmen der Arbeit relevanten Service, dem Software Support eingegangen.
Service
Ein Service ist wörtlich übersetzt ein Dienst. Nach Sommer handelt es sich bei einem IT-Service um die zur Unterstützung ausgewählter Geschäftsprozesse erforderliche Gesamtheit von physischen und logischen Komponenten [Sommer 2004, Seite 37]. Ein Dienst kann somit von einer Software bereit gestellt werden oder auch eine von Personen erbrachte Leistung sein.
Als IT Service kann folglich jede Dienstleistung aus dem Bereich der Informationstechnologie angesehen werden. Dies umfasst Beratung und Planung sowie die Ausführung von Hardware- und Software-Leistungen ebenso, wie auch unterstützende Tätigkeiten beim Betrieb der IT-Systeme.
IT-Services werden dabei nach dem serviceorientierten Ansatz des ITSM von externen Anbietern, aber auch von unternehmenseigenen Abteilungen, als abgeschlossene Einheit ähnlich einem Produkt angeboten.
Support
Der Begriff Support bezeichnet prinzipiell jede Form der Unterstützung, die Benutzer von Computersystemen und Programmen bei auftretenden Problemen erhalten können, sei es durch einen Mitarbeiter der eigenen Firma, einer Fremdfirma, oder durch die Hersteller von Hard und Software (vgl. [Brockhaus 2003, Seite 857]). Support kann also allgemein[9] als eine problemorientierte Beratungstätigkeit angesehen werden, wie sie etwa in Call-Centres oder an Telefon-Hotlines anzutreffen ist. Das Ziel ist grundsätzlich die Bearbeitung und Lösung von Supportanfragen (Tickets) interner oder externer Kunden vor Ort, via E-Mail, Live-Support-System, Telefon, Fernwartung oder anderen Kommunikationsmitteln. Den dazu häufig auf Seiten des Dienstleistungsgebers verwendeten Automatisierungs-Werkzeugen widmet sich der eigene Abschnitt 2.3 dieser Arbeit.
Support Service
Die Dienste (Services), die im Rahmen der Unterstützungsleistungen (Support) erbracht werden, können unter der Bezeichnung Support Service zusammengefasst werden.
Support Services werden unter wirtschaftlichen Gesichtspunkten erbracht, sie dienen also nicht einem bloßen Selbstzweck, sondern müssen für Dienstleister und Dienstnehmer einen Nutzen erbringen. Zum einen stellt sich seitens der Abnehmer die Frage, für welche Systeme überhaupt ein Service benötigt wird und welcher Umfang hier sinnvoll ist. Andererseits ist auch der Anbieter gezwungen, seine Dienstleistungen wirtschaftlich zu bewerten. Support Services müssen sich folglich hinsichtlich ihres Erfolges messen lassen können.
Im nächsten Unterabschnitt wird näher auf den speziellen und für diese Arbeit relevanten Support Service des Software Supports eingegangen.
Software Support
Nach den obigen Ausführen kann Software Support folglich definiert werden als Gesamtheit der Dienstleistungen, die für ein Softwareprodukt angeboten werden, um einen optimalen Betrieb beim Anwender zu gewährleisten (vgl. [Eidner 2004, Seite 3]).
Nach anderer Ansicht besteht Software Support darin, dass der Anwender bei Fehlfunktionen eines Programms oder bei Fehlbedienung Hilfe erhält (vgl. [Brockhaus 2003, Seite 857]). Diese Definition ist aber insbesondere bei enger Auslegung des Fehlerbegriffs nicht umfassend genug, da dabei der Bereich der Softwarewartung unzulässiger Weise ausgeklammert wird. Im folgenden Unterabschnitt wird die Bedeutung der Software-Wartung herausgehoben.
Softwarewartung
Als Bestandteil des Software Supports befasst sich die Softwarewartung mit Änderungen an bereits im Einsatz befindlichen Softwareprodukten. Die Änderungen können dabei auf verschiedene Weise motiviert sein (vgl. [Balzert 1998]).
- Es kann sich um Programmierfehler handeln, die bei der Erstellung der Software gemacht wurden
- Rahmen- oder Umweltbedingungen können sich geändert haben. Die verwendete Version der Software kann etwa aufgrund von Änderungen im Hardware- oder Systemsoftware-Bereich oder der organisatorischen Einbettung nicht mehr betrieben werden.
- Mit fortschreitender Verwendung des Systems treten vermehrt Änderungswünsche der Anwender auf.
Ein Software-Unternehmen hat auf alle genannten Motive entsprechend zu reagieren, um zu verhindern, dass die Software veraltert und an Gebrauchstauglichkeit und damit zwangsläufig an Wert verliert. Nach [Balzert 1998] lassen sich die dagegen gerichteten Maßnahmen in korrektive Tätigkeiten (Wartung) und progressive Tätigkeiten (Pflege) einteilen.
Bei den korrektiven Tätigkeiten handelt es sich um Maßnahmen zur Stabilisierung und Korrektur sowie zur Optimierung bzw. Leistungsverbesserung.
- Stabilisierung und Korrektur: Beim Test unentdeckte Fehler treten im Betrieb auf und müssen korrigiert werden. Bei der Beseitigung werden erfahrungsgemäß neue Fehler gemacht, die nach Aufdeckung bei nächster Gelegenheit ebenfalls beseitigt werden müssen.
- Optimierung bzw. Leistungsverbesserung: Unter Zeitdruck freigegebene Software ist in der Regel hinsichtlich der Ressourcen Rechenzeit, Hauptspeicher und Datenbankanbindung nicht optimal. Die Leistungsverbesserung wird in die Wartungsphase verschoben.
Als progressive Tätigkeiten lassen sich Anpassungen und Änderungen sowie Erweiterungen der Software identifizieren.
- Anpassungen und Änderungen: Die Anpassung der Funktionen, der Benutzeroberfläche oder der technischen Einbindung kann aufgrund sich ändernder Gesetze oder betriebliche Regeln erforderlich werden, wenn neue Formulare benötigt werden oder neue Betriebsysteme zum Einsatz kommen.
- Erweiterung: Des weiteren kommt es häufig vor, dass Funktionen im ersten Produktionszyklus nicht realisiert werden konnten oder Benutzer den Bedarf neuer Funktionen erst im laufenden Betrieb feststellen.
In der Tabelle 2-1 werden zur Vollständigkeit die weiteren Eigenschaften von Wartung und Pflege gegenüber gestellt (vgl. [Balzert 1998]).
Tabelle 2-1: Gegenüberstellung von Wartung und Pflege nach [Balzert 1998]
Abbildung in dieser Leseprobe nicht enthalten
Obwohl der Wartungsbegriff somit eigentlich nur die korrektiven Maßnahmen umfasst, werden im alltäglichen Sprachgebrauch auch die progressiven Tätigkeiten dem Bereich der Wartung zugeordnet (vgl. [Eidner 2004, Seite 4] mit weiterem Nachweis).
Demnach wird nur auf die Richtung der Anforderung abgestellt:
- Wird die Änderung am Softwareprodukt als Reaktion auf eine Anfrage des Kunden vorgenommen, so wird dies reaktive Softwarewartung genannt.
- Geht die Änderung hingegen von der Wartungsorganisation aus, so handelt es sich um proaktive Softwarewartung.
Für den Fortgang der Arbeit ist diese unterschiedliche Sichtweise indes nicht wesentlich, denn das nach der Aufgabenstellung zu suchende Automatisierungswerkzeug muss jedenfalls sämtliche Anfragen der Anwender verwalten können, unabhängig ihrer bisweilen nicht trivialen Einstufung als Fehler oder Erweiterung bzw. Wartung oder Pflege.
Die Erfahrung zeigt, dass der überwiegende Anteil der im Software Support eingehenden Meldungen nicht auf Fehlfunktionen der Software zurückzuführen ist, sondern in der Organisation der Geschäftsprozesse des Kunden oder auf einer Fehlvorstellung des Anwenders bezüglich der Funktionalität der Software liegt. Insbesondere bei sehr komplexen Softwareprodukten ist es auch für die Support-Mitarbeiter bisweilen recht problematisch, eingehende Meldungen entsprechend zu klassifizieren. Daraus resultieren einige Anforderungen an die Support-Organisationen der Softwareunternehmen. Einerseits müssen die Produkte im Rahmen der Wartungsverträge gewartet werden und des weiteren wird dem Kunden bzw. den Anwendern eine entsprechende Beratungsleistung geschuldet, wenn es sich nicht um ein Problem aufgrund eines Fehlers in der Software handelt. Letzteres muss allerdings zunächst einmal erkannt werden, was, wie bereits ausgeführt, teilweise nicht trivial ist und folglich einer eingehenden Analyse eines qualifizierten Mitarbeiters des Support-Teams bedarf.
[...]
[1] Zur Definition von KMU vgl.
http://ec.europa.eu/enterprise/enterprise_policy/sme_definition/index_de.htm (22.07.2007)
[2] Lotus Notes, siehe etwa http://de.wikipedia.org/wiki/Lotus_Notes (Stand 15.07.2007)
[3] BugLister, siehe http://www.litwindow.com/de/BugLister/index.html (Stand 15.07.2007)
[4] vgl. http://de.wikipedia.org/wiki/Software (Stand 22.07.2007)
[5] vgl. http://de.wikipedia.org/wiki/Individualsoftware (Stand 22.07.2007)
[6] engl. Ausdruck für die Anpassung von Serienprodukten,
vgl. http://de.wikipedia.org/wiki/Customizing (Stand 22.07.2007)
[7] engl. Services
[8] engl. Support
[9] vgl. http://de.wikipedia.org/wiki/Support_%28Dienstleistung%29 (Stand 22.07.2007)
