Einführung eines Helpdesk für IT-Probleme

Aus Winfwiki

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

1 Titel

Titel der Arbeit: "Konzept für die Einführung eines Helpdesks für IT-Probleme - Im Fach Fallstudie I"
Hochschule und Studienort: FOM Hochschule für Oekonomie & Management, Berlin
Name des Autors / der Autoren:
Holger Brecko, Matrikelnr.: 247217
Martin Briegert, Matrikelnr.: 241069
Kay Griesert, Matrikelnr.: 239124
Frank Nordmann, Matrikelnr.: 243649



Betreuer: Prof. Dr. Ralf Hötling

Berlin, 30.08.2010

2 Einleitung

Go to top

Die Bedeutung der Verfügbarkeit von IT Systemen wächst permanent. Nicht nur, dass übliche Office-Anwendungen und Mailsysteme den Arbeitsalltag einiger Bereiche beherrschen, ebenso sind IT Systeme wichtiger Bestandteil von Geschäftsprozessen geworden. IT Systeme steuern u.a. Maschinen und Anlagen und bilden Schnittstellen zu weiteren Sub- und übergeordneten wie bspw. logistischen Systemen. IT Systeme und deren Verfügbarkeit können enormen Impact auf die Ausbringung eines Unternehmens haben. Problem: Sofern Störungen auftreten und diese nicht schnellstmöglich und professionell gelöst werden, führt das schlimmstenfalls zu wirtschaftlichen Verlusten.

Abbildung 1: Ziele des Help Desk
Abbildung 1: Ziele des Help Desk

Ziele eines Helpdesks, zentrale Schnittstelle zwischen Anwender und Provider

Eine IT Störung ist ein Ereignis, das nicht Bestandteil eines Service ist und das tatsächlich oder potentiell eine Beeinträchtigung der Service-Qualität verursacht bzw. verursachen könnte - def. nach ITIL[1].

Das Incident Management hat die Aufgabe, den IT-Service so schnell wie möglich wieder für den geschäftlichen Anwender verfügbar zu machen. Das Problem Management hat die Aufgabe, die Ursachen zu ermitteln, die einer Störung zugrunde liegen, und anschließend Wege zur Behebung und Vorbeugung zu finden.

Ziel dieser Arbeit ist es aufzuzeigen, wie der sogenannten Incident- und Problem-Management Prozess eingeführt werden kann und welche Kriterien und Hilfsmittel (IT Systeme) dabei berücksichtigt werden sollten - Der Schritt vom Helpdesk zum strukturierten Service Desk -. Desweiteren wird aufgezeigt, welche Einflüsse dabei wirken, Schwierigkeiten des Veränderungsprozesses durchzusetzen, wie bspw. Alleinstellungsmerkmale abzulösen, Disziplin in ein Serviceteam zu verankern. Einen Ausblick darauf, wie ein stabiler Service Desk funktionieren kann, und welche Software auf dem Markt erhältlich ist, bis hin zu eigenen schlanken Software-Lösungen wird hier ebenso erörtert.

Der eingentliche Nutzwert eines Trouble Ticket Systems hat viele Facetten. So können Wirtschaftlichkeitsfragen und der eigentliche Mehrwert durch Einführung eines solchen Systems schnell Antworten aufgrund von Auswertbarkeit geben. Der Vergleich, wie der Zustand sich vorher abzeichnete, bleibt zunächst schwer nachzuvollziehen, sofern keinerlei Daten dazu erfasst wurden (Was ist hier Benchmark?).

Die schnellen Fortschritte in der Informationstechnologie erfordern peu a' peu den Einsatz, die Nutzung und Verbreitung von Systemen, die den täglichen Arbeitsablauf erleichtern und optimieren können. Ein Unternehmen betrachtet heutzutage jeden Bereich einzeln und möchte eine möglichst hohe Transparenz über alle kritischen Geschäftsprozesse. Der Einsatz und vor allem die Controllingmöglichkeiten eines Trouble-Ticket-Systems kann ggf. auch zur Wettbewerbsfähigkeit einen Beitrag leisten. Outsourcing ist zunehmend ein interessantes Instrument, Tätigkeiten und Know-How abzugeben, um sich auf die wesentliche Kernkompetenz zu fixieren. Ein Unternehmen das mit dem Bau von Flugzeugen, Autos, Möbel oder ähnlichem wirtschaftlich stark am Markt performed, muss nicht zwingend über einen internen IT Dienstleister verfügen. In einigen Bereichen wird es jedoch zunehmend problematisch kritische Systeme stabil zu betreiben. Hinzu kommt, dass man Gefahr läuft kritische Informationen nach außen zu geben. Wie ein Unternehmen sich auch entscheidet, ist es stets von Vorteil, das eigene Systemwissen und Know-How zu erfassen. Flurfunk war gestern.

3 Abkürzungsverzeichnis

Go to top
  • BSC - Balanced Scorecard
  • CIP - Continous Improvement Process
  • CSF - Critical Success Factor
  • CMM - Capability Maturity Model
  • CMMI - Capability Maturity Model Integration
  • DLV - Dienstleistungsvereinbarung
  • EFQM - European Foundation for Quality Management
  • ERP - Enterprise Resource Planning
  • IT - Information Technology
  • ITIL - Information Technology Infrastructure Library
  • ITSM - Information Technology Service Management
  • KPI - Key Performance Indicator
  • KVP - kontinuierlicher Verbesserungsprozess
  • LAN - Local Area Network
  • OTRS - Open Source Trouble Ticket System
  • PDCA - Plan-Do-Check-Act
  • TCO - Total Cost of Ownership
  • UWG - Ursachen-Wirkungs-Diagramm
  • SLA - Service Level Agreement

4 Problemstellung und Zielsetzung

Go to top

Ein mittelständisches Unternehmen, Ghost Industries, hat IT Mitarbeiter mit unterschiedlichen Qualifikationen. Die bestehende Infrastruktur ist in den letzten Jahren aufgrund steigender Produktion und Mitarbeiteranzahl organisch gewachsen.

Der organisatorische Aufbau/Ablauf der bisherigen IT-Services ist auf Anforderung der Geschäftsleitung hin zu optimieren. In der Vergangenheit beklagten sich die Mitarbeiter, dass der IT-Support und die Störungsbearbeitung tlws. mangelhaft ist, dies geprägt durch lange Warte- und Reaktionszeiten.

  • Es existiert kein zentraler Service Desk, statt dessen verschiedene nicht-intergierte Systeme ('Insellösungen').
  • Ereignisorientierte Reaktionen - Störungen und deren Behebung werden nicht systematisch erfasst und sind nicht rückverfolgbar.
  • Durch behobene Störungsfälle generiertes Wissen (DIKW-Modell) verpufft weitestgehend ohne Widerverwendung.
  • Die allgemeine Qualifikation der Mitarbeiter im Betrieb hat ebenso Verbesserungspotentiale, dass sich durch die Art der Störungsübermittlung aufzeigen lässt.

Auch die Verfügbarkeit der Systeme gerät aufgrund des Impacts der Produktionsausbringung sukzesiive in einen anderen Fokus. Die Geschäftsleitung bittet den Leiter der IT Abteilung in diesem Rahmen über folgende Kriterien reportingfähig zu werden, um das Business hinsichtlich einer besseren INforamtionsversorgung und damit Entscheidungsgrundlage zu versorgen:

  • IT Störungen (Anzahl p.a., Art und Schweregrad)
  • Dauer der Störungsbehebung
  • Störungshistorie
  • Verfügbarkeit der Systeme mit der messbaren Größe "Lost Units" (durch IT Störungen).

Darüber hinaus möchte der verantwortliche Leiter der IT Abteilung sicher stellen, dass das Wissen der IT Mitarbeiter zur Störungsbehebung genaustens erfasst wird, um den Support langfristig mit weniger Ressourcen besetzen zu können. Hier im besonderen Blickfeld; die TotalCost of Ownership (TCO) des IT-Service-Betriebs.

Der Geschäftsleitung soll nun konzeptionell aufgezeigt werden, mit welchen Maßnahmen, Methoden und ggf. Werkzeugen der IT Betrieb optimiert werden kann. In Anlehnung an den aktuellen Standard ITIL wird sich die IT Abteilung der Ghost Industries orientieren und vergleichen, mit welchen Maßnahmen oben stehende Ausgangszustände verbessert bzw. auf die genannten Zielszustände hin optimiert werden können.

5 Analyse und Konzeptansatz

Go to top

5.1 Dokumentation von IT Störungen

Go to top

Ein Trouble Ticket lässt sich im Wesentlichen mit dem Krankenblatt eines Patienten vergleichen. Bei der erstmaligen Einlieferung in das Krankenhaus wird das Krankenblatt im Zuge der Anamnese neu angelegt. Jeder Arzt trägt nun seine Diagnose, sowie die verordnete Therapie und Medikation ein und dokumentiert deren Erfolg. Das Krankenblatt gibt nun einen schnellen Überblick, gewährleistet eine schnelle Einarbeitung und verhindert eine Mehrfachdosierung von Medikamenten. Ist die Krankheit besiegt und der Patient entlassen, wird das Krankenblatt archiviert. Quelle der Definition: http://doc.otrs.org/2.0/de/pdf/otrs_admin_book

  • Digitale Erfassung von IT Störungen mit einem Trouble-Ticket-System:

Heute erfassen die Mitarbeiter im Helpdesk keine Störungsmeldungen, man reagiert ereignisorientiert. Um Störungen zu erfassen und korrekt entgegen zu nehmen, sollten dem Anwender einige Vorgaben gemacht werden, damit Störungen fachlich korrekt zugeordnet, sowie mit der entsprechenden Proirität bearbeitet werden. Ziel ist es dem Anwender in einem menuegeführten Ticket-System zu "begleiten", so dass bereits bei der Aufnahme von Störungen jedweder Art ('Incidents') eine Störungs-Klassifizierung durch den Anwender erfolgt. Diese Kategorisierung sollte in folgenden groben Clustern erfolgen:

Bild:Kateg_bre.jpg

Abbildung 2: Störungsklassifizierung (Eigene Darstellung gewählt, durch oben stehende Anforderung zur Problemstellung.)

Nach dem Eingang eines Tickets können die oben stehende Informationen zur Weiterbearbeitung durch den IT Support genutzt und ggf. ergänzt werden.

5.1.1 Anforderungen

Go to top

Eine schnelle, wirkungsvolle und möglichst kostengünstige Behebung von Problemen muss sichergestellt werden. Aus diesem Grund muss der Einsatz vorhandener Ressourcen, die zur Fehler- oder Problem-Behebung zu allokieren sind, immer den auf den geschäftlichen Anforderungen beruhenden Prioritäten entsprechen. Unterstützung des Incident Managements durch proaktives Aufspüren und Beheben von Problemen sowie bekannten Fehlern (Known Errors), so dass Störungen minimiert bzw. möglichst ausgeschlossen werden. Steigerung der Produktivität des Support-Personals durch den Einsatz einer entsprechenden Datenbankapplikation die das Incident Management und Problem Management vereint. Um die Transparenz dieses "neuen" Services zu verdeutlichen, sind zyklische Reports aus der Störungsdokumentation eine Prämisse, um Management Informationen möglichst einfach und schnell zur Verfügung stellen zu können. Weitere Anforderungen:

  • Periodenbezogene Reduktion von Anzahl und Dauer ungeplanter Downtimes (Alarmierungs- und Dokumentationsfunktion).
  • Einhaltung und vor allem Festlegung von SLAs bzgl. der Performance, des Datendurchsatzes, der Verfügbarkeit und Wiederherstellungszeit (Erinnerungsfunktion, SLA läuft aus etc).
  • Sicherstellung, dass die benötigten IT-Technik- und Service Ressourcen innerhalb der aus Sicht des Unternehmens erforderlichen und vereinbarten (SLAs) Zeiträume wiedergewonnen werden können (Dokumentation der Backup- und Notfallstrategien, sowie deren zyklischer Test).

5.1.2 Auswertbarkeit

Go to top

Hauptanliegen ist, die Ausfallzeiten bis auf ein absolutes Minimum zu reduzieren. Eine vollständig fehlerfreie Serviceumgebung ist leider Wunschdenken (dieses Ziel erreichen nicht mal die besten SixSigma-Unternehmen der Welt) dennoch muss man die Qualität der Leistungen in messbaren Auswertungsgrößen definieren um der Utopie-Vorstellung vollständiger Fehlerfreiheit mit maximal möglicher Annäherung zu begegnen. Daher hier nun ein paar Beispiele nach welchen Kriterien eine Auswertung geschehen kann:

  • Dauer
  • Schweregrad
  • Häufigkeit nach Kategorien (Server-, Applikations- oder Anwenderproblem)
  • Zuständigkeit
  • Ticketaufkommen
  • Ticketabarbeitung
  • Auswertung nach Statustypen


Wird nach der Auswertung der Incidents erkannt, dass es immer mehr Probleme in der Handhabung bestimmter Applikationen gibt, zum Beispiel mit Microsoft Office, wäre es voraussichtlich einfacher eine Anwenderschulung zu organisieren um diese aufkommenden Incidents zu minimieren.

Eine Auswertung nach Abteilungen kann in Erwägung gezogen werden, wenn es um die Auslastung der Hotline geht. Stehen zu viele Aufträge in der Warteschlange, weil es zu wenig Mitarbeiter in der Abteilung gibt, oder ist die Auslastung zu gering, können zeitweise Ressourcen temporär für andere Abteilungen/Aufgaben eingesetzt werden können, wo möglicherweise höhere Arbeitslasten bestehen.

Abbildung 3: Beispiel für Diagramme
Abbildung 3: Beispiel für Diagramme

Die Auswertungen können in den verschiedensten Diagrammen dargestellt werden, wie zum Beispiel:


  • Liniendiagramm
  • Balkendiagramm
  • Punktdiagramm
  • Linienpunktdiagramm
  • Flächendiagramm
  • Tortendiagramm


Über die verschiedenen Auswertungen können Informationen generiert werden, die potentielle Aktivitäten und Aktionen zur Verbesserungen des Systems naheliegen bzw. direkt ansteuern können. Ist das Ticketaufkommen auf eine längere Zeit hin wesentlich höher als die Ticketabarbeitung sollten mehr Agents eingesetzt werden oder die Verteilung auf die einzelnen Service Levels neu besprochen werden. Gibt es sehr häufige Ausfälle mit Servern oder Workstations könnte zum Beispiel über einen Hardware Rollout nach gedacht werden um die alte Anfällige Technik zu ersetzen.


Wie die Auswertung im Genauen aussehen soll, bzw. in welchen Perioden die Auswertungen erfolgen müssen, ist von der IT-Führungsebene festzulegen (Anm.: Design von Prozessen top-down, Implementierung bottom-up), und in den Dienstgütevereinbarungen festzuhalten. Natürlich gibt es auch die Möglichkeit diese Daten zu exportieren, um dann mit einem Auswertungsprogramm wie zum Beispiel CrystalReports weiterzuarbeiten.

Das Hauptmerkmal der Auswertung richtet sich derzeit auf die Reaktionszeiten der einzelnen Incidents. Wie lange dauert die Bearbeitung von Tickets? Wie hoch sind Ausfallzeiten? Wie hoch ist das Ticket-Aufkommen über einen fesgelegten Zeitraum - sortiert und gruppiert nach:

  • pro Tageszeit
  • pro Tag
  • pro Woche
  • pro Monat

Alle oben genannten Kriterien können nach den verschiedenen Kategorien, wie zum Beispiel Server, Anwender oder Applikation unterteilt werden, wodurch eine genauere Auswertung möglich ist. Wie wichtig es ist, eine Unterteilung in Kategorien vorzunehmen, sieht man bei der Auswertung. Im Besonderen, wenn es um die Ausfallzeiten von Servern geht.

Pro Tag und gruppiert nach Uhrzeiten ist besonders dann wichtig, wenn die Geschäftsleitung bzw. Einsatzplanung sehen möchte, wann das Ticketaufkommen am höchsten ist, um zum Beispiel die Einsatzplanung zu verändern.

5.1.3 Inhalte eines Trouble Tickets

Go to top


Folgende Felder sollten Bestandteil eines Tickets sein:

Abbildung 4: Aufnahme eines Tickets durch den Agent
Abbildung 4: Aufnahme eines Tickets durch den Agent


  • (fortlaufende) Ticket ID
  • Ticket Zustand
  • Ticketersteller (Support, Anwender)
  • Personalien (Name, Vorname, Telefon, Standort, Erreichbarkeit)
  • Betroffenes / gestörtes Asset (System, Gerät, PC, Drucker, Bildschirm, Programm usw.)
  • Priorität
  • Dateiupload
  • Zeitstempel
  • Problembeschreibung
  • Problemlösung


Die Ticket ID wird dem Hilfesuchenden übermittelt, sodass er bei Nachfragen schneller an die gewünschten Informationen kommt. Der Ticket Zustand kann die Attribute offen, gelöst, In Bearbeitung, weitergeleitet oder warten annehmen. Über den Zeitstempel wird im Hintergrund automatisch die Historie der Bearbeitung angefertigt. Es ist ersichtlich, wann hat wer das Ticket bearbeitet. Der erste Zeitstempel enthält die Information zum initialen Auftreten des Fehlers. Informationen aus einem Forschungsbericht der FernUni Hagen entnommen


Über einige Ticketsysteme können die Systemlogs der Workstations oder Server ausgelesen werden. Dies ist sehr wertvoll bezüglich der Ausfallsicherheit der Server. Falls es zu einem Fehler auf einem Server kommt, wird automatisch ein Ticket eröffnet, in dem das jeweilige Logfile angehängt ist. Über dieses Logfile kann genau gesehen werden, welcher Server betroffen ist und was für Fehler dokumentiert wurden. Die vollständige Überwachung des IT Netzwerkes inklusive der Hardwarekomponenten erweist sich als sinnvoll, da bereits kleine Fehler die komplette IT beeinträchtigen.

Dieses Ticket wird am Besten an eine vordefinierte E-Mail Adresse oder an eine Gruppe verschickt. Es ist angedacht die IT so auszubauen, dass es auch möglich ist E-Mails auf dem Handy zu empfangen, so kann ein Bereitschaftsdienst aufgestellt werden, und es ist kann überlegt werden, von einem 3 Schichtsystem auf ein 2 Schichtsystem zu wechseln, und für die Nachtzeiten eine Gruppe von Bereitschaftsdienstlern einzusetzen.

5.1.4 Softwareunterstützung im Prozess

Es gibt einige OpenSource System auf dem Markt die mit minimalen Anforderungen leicht inbetriebgenommen werden können und geringe technische Voraussetzungen erfordern. Eines der Hauptziele ist es eine Weiterentwicklungsmöglichkeit zu gewährleisten um etwaige eigene Anforderungen kostengünstig zu realisieren. Unter den OpenSource Produkten ist das OTRS System geradezu prädestiniert und erfüllt folgendes Anforderungsprofil [2]:

   * 100% Open Source
   * Keine Software-Lizenzkosten
   * Die einzige PinkVERFIY-zertifizierte ITIL®-kompatible Open Source ITSM-Lösung
   * Steigerung der Erstlösungsrate um 30%
   * Minimierung übersehener Vorgänge um bis zu 50%
   * Einsparung administrativer Kosten um 25% durch Self-Service
   * Um 95% schnellere Lösung wiederkehrender Störungen
   * Webapplikation

OTRS kann unter vielen Betriebssystemen installiert werden. Neben Linux und den verschiedenen Unix-Derivaten (z. B. OpenBSD oder FreeBSD), läuft OTRS auch unter allen Windows-Versionen. Bezüglich der Hardware empfiehlt es sich, mindestens einen 2 GHz Pentium Xeon oder vergleichbare CPU, 2 GB RAM und eine 160 GB Festplatte zu verwenden.

Für den Betrieb von OTRS werden einige externe Software-Komponenten benötigt. Ein Web- sowie ein Datenbankserver und eine funktionierende Perl-Installation mit einigen Zusatzmodulen sind die Grundvorraussetzungen für ein funktionierendes System. Der Webserver und Perl müssen auf der gleichen Maschine installiert sein, auf der später auch OTRS ausgeführt werden soll. Das Datenbank-Back-End kann auf der lokalen oder auf einer entfernten Maschine installiert werden.

Für den Webserver wird empfohlen, auf apache 2 zurück zu greifen. Vor allem durch die Erweiterung der apache-Konfiguration um das mod-perl-Modul, kann die Geschwindigkeit von OTRS enorm gesteigert werden. Prinzipiell sollte aber jeder Webserver, der die Ausführung von Perl-Skripten unterstützt, für den Betrieb von OTRS geeignet sein.

Als Datenbank-Back-End eignen sich MySQL, PostgreSQL, Oracle, MSSQL oder DB2. Ein Vorteil der Benutzung von MySQL ist, dass OTRS über einen Webinstaller die Datenbank und Tabellen automatisch anlegen kann.

Für Perl gilt mindestens die Version 5.8.8 zu verwenden. Es werden einige Zusatzmodule benötigt, die Sie entweder direkt über die Shell von Perl und CPAN oder mit Hilfe des Paketmanagers (yast, apt-get) Ihres Betriebssystems einspielen müssen.

Software-Anforderungen:

Perl:

Perl 5.8.8 oder höher

Webserver:

Webserver mit CGI support (CGI ist jedoch nicht empfohlen)

Apache2+mod_perl2 oder höher (empfohlen, mod_perl ist sehr schnell!)

IIS6 oder höher

Datenbanken:

MySQL 4.1 oder höher

PostgreSQL 8.0 oder höher

Oracle 10g oder höher

DB2 8 oder höher

MSSQL 2000 oder höher

Quelle:OTRS

Abbildung 5: OTRS Verbreitung
Abbildung 5: OTRS Verbreitung


OTRS hat sich im Vergleich zu vielen anderen TroubleTicket Systemen am Markt etabliert und wird in Servicedesks aufgrund der geringen Anschaffungskosten und Weiterentwicklungsmöglichkeit bevorzugt eingesetzt.


Vergleichbare Web-Datenbankapplikationen:

  • Bugzilla

Bugzilla ist die verbreitetste und leistungsstärkste Bugtracking-Software. Bei kleineren Projekten erweist sich der Featurereichtum jedoch leicht als Effizienzbremse. Bugzilla: Bugzilla

  • Mantis

Das PHP-basierte Mantis ist schnell installiert. Die oft recht oberflächliche Dokumentation erschwert es jedoch, das System den eingenen Vorstellungen anzupassen. Mantis

  • Request Tracker

Die aktuelle Fassung setzt die neuesten Versionen vieler Perl-Module voraus. Weil diese selbst wieder bestimmte Releases anderer Perl-Komponenten benötigen, ist es lästig, diese von Hand einzubinden. Requesttracker

  • Trac

Trac ist ein Bugtracker und hat damit eine andere Zielgruppe als die bisher vorgestellen Systeme. Da Trac auf der in der Webentwicklung weniger verbreiteten Sprache Python basiert, müssen die benötigten Komponenten oft selbst aus den Quellen gebaut werden. Trac

Quelle: http://www.linux-magazin.de/Heft-Abo/Ausgaben/2007/01/Passgenau-zugeteilt/%28offset%29/6

5.1.5 Installation und Konfiguration am Beispiel OTRS

Im folgenden wird die Installation von OTRS auf Microsoft Windows (Win32) Systemen beschrieben. Der Automatic Installer wurde unter Microsoft Windows 2000 und XP getestet, sollte aber auch unter Windows NT4 und 2003 voll funktionsfähig sein. Es ist darauf zu achten, dass das Betriebssystem auf dem aktuellsten Stand ist, bevor mit der Installation begonnen wird. Eine relativ einfache Überprüfung ist Beispielsweise über die Microsoft-Updatefunktion möglich. Diese kann am schnellsten unter folgender URL überprüft werden: http://windowsupdate.microsoft.com/

Wichtig: Der OTRS Installer unterstützt keine 16-Bit-Windows Versionen (z.B. Windows 98, 98SE, ME).

otrs4win32 - Der Automatische Installer

Der automatische Installer von OTRS ist die komfortabelste Lösung um alle für OTRS notwendigen Software Komponenten zu installieren. Folgende Versionen der Software-Komponenten werden installiert:


Die aktuelle Version des OTRS Installers kann unter http://otrs.org/download bezogen werden. Der Name der ausführbaren Datei mit der Endung .exe folgt hierbei der folgenden Konvention: otrs4win32-<OTRS-VERSION>-<STATUS>.exe.

Wenn die Datei Authentiziiert werden soll, so muss die noch zugehörige md5-Datei heruntergeladen werden . Mit Hilfe des md5-summer (http://md5summer.org/) kann demzufolge die Echtheit bestätigt werden.

Installation:

Eine Voraussetzung für die Installation stellen die administrative Rechte auf dem Zielsystem dar.

Der Installer ist gedacht für neu zu installierende OTRS Systeme.

Start der OTRS Applikation:

Es muss sichergestellt werden, dass keine anderen Serveranwendungen auf den Ports 25 (smtp), 80 (http), 443 (https), 3306 (MySQL) laufen. Andernfalls ist zu überprüfen, welche Serverdienste auf diesen Ports Aktivitäten zeigen. Beispiele dafür sind Microsoft's IIS Webserver, der unbemerkt im Hintergrund mitläuft oder der dazugehörige SMTP Dienst. Diese Dienste sollten beendet werden.

Damit die Server des Systems nach der Installation direkt gestartet werden können, ist die entsprechende Option auf der letzten Seite des Installers oder Eintrag im Startmenü zu verwenden.

Die Startphase des Apache Servers kann einige Wartezeit in Anspruch nehmen. Standardmäßig wird der ApacheMonitor nach der Installation gestartet, wie auch WinMySqlAdmin, ein Monitor für MySQL. Dieser dient dazu das Laufverhalten und den Status zu kontrollieren.

Durch browsereingabe http://localhost/otrs/installer.pl, kann der Webinstaller gestartet werden, der es ermöglicht die Datenbank anzulegen und mit Anfangswerten zu befüllen. Nach Abschluss des Webinstallers erfolgt eine automatische Weiterleitung auf die Login Seite: http://localhost/otrs/index.pl.

Die Benutzeroberfläche für den Anwender ist über den folgenden Link erreichbar: http://localhost/otrs/customer.pl

Um den Server für etwaige Wartungszwecke zu stoppen ist wie folgt vorzugehen:

Wenn der Server als Systemdienst installiert wurde, kann das Startmenü oder die Diensteverwaltung von Windows genutzt werden, um die Dienste zu beenden. Hilfreich ist es dazu ein einfaches Batchscript mit den Befehlen Net Stopp und Net Start, gefolgt von den dazugehörigen Dienstnamen, zu schreiben.

Weiterführende Hilfen und zahlreiche Tipps findet man unter folgender Quelle: Quelle und weiterführende Infos

5.1.6 Störungshandling/Ablauf

Go to top


Abbildung 6: Fallbearbeitung, Ablauf und Kommunikation zw. Anwender und Serviceprovider.
Abbildung 6: Fallbearbeitung, Ablauf und Kommunikation zw. Anwender und Serviceprovider.


Beim Telefonat mit dem Anwender sollten bereits in den ersten Sätzen Anhaltspunkte heraus gehört werden, um was für ein Problem es sich handelt. Also ist es ein reines Anwendungsproblem? Fehlen dem Benutzer eventuell Administrative rechte um zum Beispiel einen Drucker zu installieren? Oder sind es doch größere Probleme mit einer Datenbank, Workstation oder gar einem Server?


Dem entsprechend sollte dann auch gleich die Einstufung des Problems stand finden, handelt es sich um einen Hinweis der allerdings das laufende System nicht beeinträchtigt (Grafikbug in einem Programm) oder ist es eine Störung die auf längere Zeit zu einem Systemausfall werden könnte? Oder ist es sogar ein Problem was schnellst möglichen Handlungsbedarf erfordert da sonst längere Ausfallzeit in Kauf genommen werden müssen?

Abbildung 7: Userhinweis
Abbildung 7: Userhinweis

Falls der Anwender sich nicht deutlich ausdrücken kann was genau der Fehler ist, da es in einigen Fällen passieren kann/wird nur ein „ Es Funktioniert überhaupt nichts“ kommt, sollte der Support sich per Remote auf den PC schalten können und sich den Fehler direkt zeigen lassen. In einigen Fällen ist danach zu sehen dass sich um einen einfachen Anwender Fehler handelte.

Der Supporter kann dadurch auch denn genauen Hergang eines Fehlers Reproduzieren. Bei einigen Fehlern ist es dann sogar hilfreich sich einen Bildschirmausdruck zu machen, um zum Beispiel eine Fehlermeldung zu Dokumentieren. Außerdem kann der Screenshot für die jeweilige Fachabteilung sehr Hilfreich für die Fehlerfindung und Behebung sein. Durch diese Art der Dokumentation können längerer Ausfallzeiten verhindert werden. In dem Falle das sich bestimmte Fehler zum Beispiel bei einer Anwendung häufen, sollte drüber nach gedacht werden einen Patch zu entwickeln und diesen dann Zeitgleich auf die Rechner und Server zur Installation zu verteilen.

Nach der Aufnahme des Fehlers wird dem Kunden noch eine Auftragsnummer mitgeteilt unter der er sich über den Bearbeitungsstand erkundigen kann. Außerdem wird dem Kunden diese auch nochmals per Mail zugesandt.


Bei Verwendung eines Ticket Systems wie dies von OTRS hat der Kunde auch die Möglichkeit sich über ein Webfrontend anzumelden um sich über seine offenen Tickets zu erkundigen. Der Vorteil dieses Webfrontend ist, der Kunde muss nicht Ewigkeiten in einer Warteschleife warten und da drüber sehen in welcher Abteilung ist bereits sein Ticket und was wurde bereits damit gemacht. Ist es sogar ein Abteilungsleiter kann diesem eine besondere Berechtigung vergeben werden so das er die gesamten Tickets einsehen kann die von sein eigenen Abteilung erstellt wurden.

Abbildung 8: Beispiel eines UWG
Abbildung 8: Beispiel eines UWG


Durch Zusammenarbeit aller betroffenen Stellen, wie zum Beispiel der Programmierer, Techniker und Anwender können bereits die Incidents minimiert oder die Reaktionszeiten verbessert werden, wie in dem Beispiel für ein Ursachen-wirkungs-Diagramm ersichtlich. Die Programmierer können zum Beispiel ihren Quell Code verbessern, so dass die Programme an Stabilität gewinnen. Wenn die Techniker nun noch veraltete und anfällige Hardware erkennen und ersetzen wird auch diese Stabiler laufen und Systemausfälle können ebenfalls minimiert beziehungsweise verhindert werden. Auch der Anwender kann seinen Teil dazu beitragen in dem er an Angebotenen Anwenderschulungen Teilnimmt. Wenn nun noch die angebotenen Updates regelmäßig Installiert werden kann Beispielsweise auch die bereits käuflich erworbene Software verbessert werden.

5.2 Standardisierung Software / Hardware

Abbildung 9: Nutzung von Computer und Internet (2002-09) Quelle:www.destatis.de
Abbildung 9: Nutzung von Computer und Internet (2002-09) Quelle:www.destatis.de

Je komplex ein System wird, desto aufwendiger wird sein Betrieb und die Instandhaltung. Daher wurde bereits seit 1962 in Deutschland das Augenmerk verstärkt auf die Vereinheitlichung von Systemen geachtet. Hierfür wurde ein separater Ausschuss des Deutschen Instituts für Normung gebildet. Mit dem verstärkten Einsatz von Kommunikationstechnik und der stetig wachsenden Vernetzung kam es zu internationalen Kooperation.

Es wurden Normen und Richtlinien definiert, um Systeme transparenter, flexibler und sicherer zu gestellten und dabei die Kosten zu minimieren.

Abbildung 10: Preisindex (2009 ggü. 2005) Quelle:www.destatis.de
Abbildung 10: Preisindex (2009 ggü. 2005) Quelle:www.destatis.de

Bei der Einführung von einheitlicher Hardware und Software kann auf am Markt etablierte Unternehmen zurückgegriffen werden. Diese bieten in der Regel Komplettlösungen an aber auch Teillösungen für einzelne Unternehmensbereiche sind denkbar. Vorteilhaft ist bei Komplettlösungen die Reduzierung von Kompatibilitätsproblemen auf ein Minimum. Zudem können je nach Unternehmensgröße Mengenrabatte ausgehandelt werden.

Standardisierung (vgl. auch Geschäftsprozessorientierung und -Optimierung) ist die grundsätzliche Methodik, um Fehler zu reduzieren und Produktions- sowie Servicekosten zu minimieren; demnach Grundvorraussetung, um langfristig konkurrenzfähig am Markt agieren zu können.

Ist die Hardware und Software standardisiert, das Personal auf geregelte Prozesse geschult, dann können unvorhergesehene Störfälle auf ein Minimum reduziert werden. Ausfallzeiten werden so kurz wie möglich gehalten und größere Störfälle geben den Anstoß zu einer neuen Verbesserung des gesamten Systems.

5.3 Kostenreduktion

Go to top

Die Unterteilung der Kosten für die IT kann mannigfaltige Strukturen annehmen. Es Fallen Kosten für die Bereitstellung von Hardware und Software an, für die Produktivsetzung und die Instandhaltung. Es können Personal-, Lizenz- oder Sachkosten entstehen.
All dies wird in Kauf genommen, um innerhalb der Unternehmung Informationen zu generieren und zu sichern.
Wächst die Unternehmung fallen erneut hohe Kosten an, um die IT Infrastruktur im gleichen Maß mit auszuweiten und für das Wachstum Kapazitäten zu schaffen.

Abbildung 11: Einfluss auf die Kosten
Abbildung 11: Einfluss auf die Kosten

Bereits bei der ersten Inbetriebnahme von Systemen ist darauf zu achten, ob sie flexibel auf die Bedürfnisse des Unternehmen reagieren und mögliche technischen Entwicklungen adaptieren können. Es ist abzuwägen, welche Option die geeignetste ist.

  • Update bezeichnet die Aktualisierung von Softwareprodukten, durch die kleine Fehler (Bugs) oder Verbesserungen am Programm durchgeführt werden. Updates sind kostenfrei in Form von Service Releases, Patches oder Hotfixes vom Hersteller zu beziehen.
  • Eine bereits vorhandene Version wird durch Kauf und Installation des Upgrades auf die neueste Version gebracht. Das Upgrade bieten im Vergleich zur Neuanschaffung einen Preisvorteil, da der Hersteller den Kunden weiterhin binden möchte.

Beide Varianten bieten in der Regel den Vorteil, dass der Nutzer sowie der Service Desk mit dem Programm und den Funktionen vertraut ist.

Die Anlernzeit wird minimiert ebenso wie der Aufwand für Schulungen.Durch die Standardisierung konzentriert sich das Wissen der Service Desk Mitarbeiter auf klar definiertes Spektrum an Hardware und Software. Problembehandlungen können dokumentiert werden und sind mehrfach einsetzbar.

Die Optimierung der Abläufe bietet zudem die Möglichkeit die Kapazität des Service Desk zu erhöhen bzw. Überkapazitäten durch Umstrukturierungen zu vermeiden.
Die neu geschaffenen Kapazität ist ein Resultat der effektiveren Behebung von Stör- und Problemfällen. Das Gesamtvolumen an zu bearbeiteten Anfragen wächst an. Die Motivation beim Service Desk Personal, sowie beim Anwender wird gesteigert.

Über das Ticket System von OTRS können Auswertungen gefahren werden, die nach entsprechender Analyse Schwachstellen erkennen lässt oder zum Erweitern der Dokumentation für regelmäßige bzw. ähnliche Probleme herangezogen werden kann. Das so erlangte Wissen dient den Mitarbeitern des Service Desk als kontinuierliches Schulungsmaterial oder zur Einarbeitung neuer Kollegen.

5.4 Prozessgestaltung & Kommunikation

Go to top
  • Allgemeines / IT Governance / ITSM

Als Konsequenz einer immer stärkeren Kunden-, Service und Prozessorientierung ergeben sich für die IT-Verantwortlichen eine Reihe neuer Herausforderungen, wobei intern steigende Qualitätsanforderungen und eine sich gleichsam rasant verändernde Außenwelt (rechtliche und regulatorische Rehamenbedingungen, sowie rasanter technischer Fortschritt) mit den betriebsiwirtschaftlichen Anforderungen des Unternehmens in Einklang gebracht werden müssen.

Abbildung 12: IT Spannungsumfeld
Abbildung 12: IT Spannungsumfeld

Die IT im Spannungsfeld zahlreicher Interessengruppen - Quelle: Baurschmid 2005

Aufgrund allgemeiner betriebswirtschaftlicher Rahmenbedingung ist die Kostenoptimierung einer der zentralen Faktoren für den Erfolg eines Unternehmens, und nur, wenn die Kosten für die IT im budgetären Rahmen erfüllt werden, kann das Unternehmen konkurrenzfähig arbeiten. Neben den rein finanziellen Aspekten bestimmt zudem hauptsächlich die Orientierung der Services an den bestehenden Geschäftsprozessen der Kunden (gleich ob intern oder über die Unternehmensgrenze hinweg) den Rahmen des nötigen IT Service Managements.

5.4.1 Change Management / Kommunikation

Im Falle der hier betrachteten Einführung eines Service-Helpdesk muss die Erbringung des zukünftigen IT-Services, am Bedarf der Haupt-Stakeholder ausgerichtet sein. Als solche sind zu identifizieren:

  • Die Geschäftsführung (Informationsbedürfnisträger, Prozess-Trigger)
  • Die Mitarbeiter der IT-Abteilung (Prozessausführende)
  • Die Anwender des Service-Supports

Neben Erbringung der IT-Leistungen in entsprechender Qualität und Geschwindigkeit ist die Orientierung am Bedarf der Anwender zu berücksichtigen. Insbesondere der Anwendersupport durch den Helpdesk muss benutzerorientiert erbracht werden, da nicht nur die technische Qualität der Services, sondern insbesondere die individuelle Wahrnehmung des Nutzers eine entscheidende Rolle für die Akzeptanz der definierten IT Services spielt. Ohne diese Orientierung werden die anzubietenden Services letztendlich auf wenig Akzeptanz stoßen, da sie nicht oder nicht ausreichend zur Erreichung der jeweiligen Kunden-/Anwenderziele beitragen. Um diese Geschäftsprozessorientierung zu erreichen sind mit den Serviceabnehmern entsprechende Ziele zu definieren, an denen sich die Erbringung der benötigten IT-Serviceleistungen ausrichtet. Im Weiteren wird hier ausschließlich die nötige interne Kommunikation und Prozessoptimierung betrachtet.

Kommunikation spielt eine entscheidende Rolle in allen Phasen des IT-Service Mangements und im Rahmen von am IT-Prozess orientierten Veränderungsvorhaben. Kommunikation ist nicht als eigenständiger Prozess definiert, dennoch sind klare Regeln für effiziente und effektive Kommunikation vorhanden[3]:

  • Kommunikation ist wichtig. Unnötige Kommunikation ist jedoch zu vermeiden, um die bestehende Informationsmenge nicht ohne sinnvollen Anlass für eine konkrete, sich ergebende Aktion zu komplexieren.
  • Informationen sind nur zu kommunizieren, wenn der geplante Informationsrezipient verfügbar, die Art und Weise der Übermittlung vorher definiert, und festgelegt ist, was Folge des Informationsempfang sein soll.
  • Es ist sicher zu stellen, das distribuierte Informationen tatsächlich empfangen wurden.
  • Die Art und Weise der Kommunikation ist unerheblich, wenn und insofern die Beteiligten Einverständnis darüber haben, wie und wann die Kommunikation stattfindet, und alle Beteiligten über die zu nutzenden Kommunikationsmittel tatsächlich verfügen.

5.4.1.1 Widerstände erkennen und Lösungen vorbereiten

Bestehende Strukturen beinhalten gebundene Energie. Restrukturierung, also hier, erhebliche Umbauarbeiten bei der Funktionsweise durch die bisherigen Wissensträger, und Einführung eines neuen Services, der die Geschäftsführung in die Situation bringen soll, die nötigen Informationen als Grundlage zur Entscheidungsfindung zu erhalten, wird diese Energie freisetzen. Die schlichte Veränderung bzw. Abschaffung bestehender Strukturen und Funktionen, sagt allerdings noch nichts darüber aus, wie sich die freigesetzte Energie entfaltet – ob produktiv oder destruktiv.

5.4.1.2 Frühzeitige Beteiligung der „Betroffenen“

Nur, wenn die Befindlichkeiten aller, die einen solchen Change-Prozess, bewusst oder unbewusst torpedieren könnten, durch die Schaffung von Gemeinsamkeiten, in ausreichendem Maße berücksichtigt werden, kann ein sinnvoller Wandel entstehen[4]. John F. Kennedy soll gesagt haben:“Fortschritt ist ein hübsches Wort. Aber sein Motor ist Veränderung und die hat viele Feinde“. Es ist also unerlässlich, bereits in einem frühen Stadium der Planung, alle pot. Beteiligten von Beginn an in den Ideenfindungsprozess zu integrieren, dies aus folgenden Gründen :

  • praxisgerechte Lösungen

Nur die unmittelbar betroffenen, die die jeden Tag mit den alltäglichen Unzulänglichkeiten des bisherigen Set-Ups arbeiten, kennen die relevanten Details und wissen, worauf im Besonderen geachtet werden muss, damit der neue Service in der Praxis tatsächlich funktioniert.

  • Erzeugung von Motivation und Identifikation mit dem Unternehmen

Nur, wer an der Erarbeitung von Lösungen bzw. neuen Prozessen aktiv beteiligt ist, fühlt sich vom Unternehmen als Mitarbeiter ernst genommen und wird sich persönlich mit diesem identifizieren, und sich bei Einführung des neuen IT-Services für eine erfolgreiche Implementierung einsetzen.

Der gewählte Ansatz, die Aufgaben der IT-Abteilung im Rahmen der Einführung eines prozess-orientierten IT-Service Helpdesks zu überführen, wird das im Unternehmen befindliche Wissen besser und mittelfristig unabhängiger von Einzelpersonen verfügbar machen bzw. weiterentwickeln. Auf die, zu diesem Gesamtkonzept gehörende Implementation eines entsprechenden Wissensmanagement-Systems, dass über den Aufbau des nötigen IT-Knowledgements hinausgeht, wird hier nicht vertiefend eingegangen.

5.4.2 Prozessgestaltung

Die bisherige Funktionsweise der IT-Abteilung (reaktiv) ist strukturell darauf ausgerichtet, die für die Leistungserbringung notwendigen Funktionen bereitzuhalten, zu positionieren und klar voneinander abzugrenzen. Die Strukur ist relativ hierarchisch und stark an den bisher eingesetzten Hardware-Systemen und existierender Software bzw. eingesetzten Applikationen orientiert und schematisiert. Es gibt verschiedene Mitarbeiter (bzw. Organisationseinheiten) die sich jeweils um LAN, Datenbanken, ERP-Systeme und andere Buinessspezialsoftware kümmern; Diese also - relativ autark - planen, implementieren und betreuen.

Das Wissen der einzelnen Mitarbeiter steht der gesamten Unternehmensorganisation somit nur nach individueller Verfügbarkeit der Wissensträger zur Verfügung. Die eigene Teilleistung wird somit primär dargestellt und protektioniert, unabhängig vom Gesamterfolg des Unternehmens.

Die Vorgehensweise zum nötigen Prozessmodell kann im Rahmen eines fünfstufigen Modells beschrieben werden[5].

  • 1. Prozessverantwortung

Jedem Prozess muss ein mit entsprechender Autorität und Kompetenz ausgestatteter Prozess-Owner zugewiesen sein. Dieser beschreibt, misst, steuert und verbessert den Prozess.

  • 2. Prozessbeschreibung

Der Prozess wird hinsichtlich der spezifischen Charakteristika (Input, Output, Methoden, Ablauf und Schnittstellen, sowie bestehenden Vereinbarungen mit dem Serviceabnehmer) beschrieben und dokumentiert. Spezifische KPIs sind entsprechend zu initialisieren.

  • 3. Prozessmessung

Um die Merkmale mit dem Anforderungsprofil des Prozesses vergleichen zu können, sind Inputs und Outputs sowie Methoden/Tätigkeiten regelmäßig gemessen bzw. erfasst.

  • 4. Prozessbeherrschung

Der Prozess ist derart zu steuern, das den Kundenanforderungen (s. jeweilige SLA) bestmöglich entsprochen wird; sprich IST-Werte sich den PLAN-Werten annähern, evtl. Prozessvolatilitäten frühzeitig erkannt werden und die Beständigkeit der Inputs gewährleistet ist.

  • 5. Prozessverbesserung

Der Prozess wird in kleinen Schritten verändert bzw. optimiert, dadurch auf eine höhere Leistungsstufe gebracht, mit dem Ziel absoluter Fehlerfreiheit und dementsprechend höchster Qualität. Nach Stufe 5 (Prozessverbesserung) folgt erneut die Stufe 2, sodass bestehende Prozesse in einem vierstufigen Lauf (die Festlegung auf den Prozesseigner muss nur initial erfolgen!) und mehrfachen kleinen Schritten einem Idealzustand entgegengebracht werden können - KVP (kontinuierlicher Verbesserungsprozess).

KVP geht zurück auf die Unternehmensphilosophie von W. Edwards Deming, der Verbesserung als einen permanenten Prozess verstand, den er in dem sog. Deming-Kreis oder PDCA-Zyklus veranschaulichte. Dieser beschreibt einen Zyklus aus vier Phasen ("Plan-Do-Check-new Act"), die immer wieder aufs Neue ablaufen, bis die letzte Ebene der kontinuierlichen Entwicklung und damit die höchstmögliche Qualitätsstufe erreicht wird.

Abbildung 13: Deming-Cycle Quelle:www.anyresearch.com
Abbildung 13: Deming-Cycle Quelle:www.anyresearch.com

KVP wird mit gleicher inhaltlicher Bedeutung im englischen Sprachraum mit "Continous Improvement Process (CIP)", in Japan mit "Kaizen" bezeichnet..

5.4.3 Reifegrad

Der praktische Nutzen von Reifegradmodellen besteht darin, in strukturierter Weise die Ist-Situation einer Organisation oder einzelner Geschäftsprozesse zu bestimmen, darauf aufbauend Verbesserungsmaßnahmen abzuleiten und zu priorisieren, sowie anschließend den Erfolg ihrer Umsetzung zu überwachen[6].

Deming nutzt bei der Bewertung der Umsetzung zur Prüfung das Capability Maturity Modell (CMM) basierend auf COBIT 3. Dabei geht es nicht um die Leistung des Prozesses an sich, sondern um den Grad der Kontrolle über die geprüften Abläufe und Prozesse. COBIT geht jeweils von einem Ideal aus. Je nach Entwicklungs- bzw. Projektstand kann eine vermeintlich schlechtere Bewertung durchaus unter Berücksichtigung der Zeit in Ordnung sein.

Zweck der Reifegradbewertung ist die Vergleichbarkeit, Nachvollziehbarkeit und Verbesserung von Prozessen. Eine kritische Bewertung soll dabei möglichen Handlungsbedarf und das Verbesserungspotenzial aufzeigen[7].

Reifegradkennzahlen bewerten einen bestimmten Prozess demnach anhand seines formalen Zustands, z. B., ob der Prozess beschrieben ist und ein Prozessverantwortlicher existiert. Sie entsprechen den Kennzahlen zum Grad der Prozessorientierung, beziehen sich jedoch auf einzelne Prozesse. Das fünfstufige „Capability Maturity Model (CMM)“ des „Software Engineering Institute (SEI)“ wurde ursprünglich zur Bewertung von Softwareentwicklungsprozessen entwickelt, lässt sich aber für jeden Typ von Geschäftsprozessen anwenden.

2003 wurde CMM durch Capability Maturity Model Integration (CMMI) ersetzt, das 6 Abstufungen beinhaltet:


Level Entwicklung
0 - Nicht existent
  • erkennbare Prozesse fehlen
  • Erkennnis über nötigen Handlungsbedarf nicht vorhanden
1 - Initiiert
  • Erkenntnis über notwendigen Handlungsbedarf existent
  • standardisierte Prozesse fehlen jedoch und werden durch Ad-Hoc Maßnahmen ersetzt
2 - Teilweise definiert
  • Prozess sind etabliert, und werden für gleiche Aufgabe in ähnlicher Weise genutzt
  • Keine einheitliche Schulung und Kommunikation der Prozesse
  • jeder Einzelne trägt die Verantwortung
3 - Definiert
  • Prozesse sind standardisiert, dokumentiert und kommuniziert
  • jeder Einzelne trägt die Verantwortung, Einhaltung nicht überprüft
  • → Abweichungen vom Prozess sind schwer erkennbar
4 - Kontroliert
  • Einhaltung der Prozesse wird kontrolliert und gesteuert
  • Ansatz für Korrekturmaßnahmen vorhanden
5 - Optimiert
  • Prozesse sind optimiert (Up-to-Date)
  • Werkzeuge zur Verbesserung von Qualität und Effizienz werden eingesetzt
  • schnelle Anpassung der Organisation an Veränderungen möglich
Quelle:Grundlagen und Modelle des Information Lifecycle Management von Günter Thome und Wolfgang Sollbach (2007)

Über das hier vorgestellte Reifegradmodell CMMI hinaus, existieren eine Vielzahl von verschiedenen Reifegradmodellen (z.B. SIEMENS/EFQM, IBM- oder ISO Reifegradmodell [ISO9004:2000]. In 2008 waren bereits mehr als 135 identifziert[8].

5.5 Service Operation in Anlehnung an ITIL 3

Zur Einführung des gewünschten IT-Helpdesk legen wir in dieser Arbeit weitestgehenden Fokus auf die Anleitungen, Methoden und Tools zur Sicherstellung von Effektivität und Effizienz bei der Erstellung und Lieferung von IT-Services. Diese finden hinsichtlich des zeitlichen Verlaufs einer ITIL-Implementation in der Regel in der nachfolgend beschriebenen Reihenfolge statt[9]:

  • Ist-Zustandsermittlung mittels BSC
  • Ableitung der kritischen Erfolgsfaktoren (CSF) aus der BSC-Methode
  • Ermittlung der jeweiligen KPIs und Formulierung in respektiven SLAs

KPIs sind Messgrößen für Prozesse im Zusammenahng mit den SLAs, z.B.:

Prozessdurchlaufzeiten
Wie lange dauert die Bearbeitung im First-Level-Support?
Wie sind die Reaktionszeiten im Problem-Management?
Wie viele Störungen werden im Incident-Management pro Zeiteinheit bearbeitet?z.B.
Angaben ohne Prozessbezug
Anruferanzahl im Service-Desk pro Tag
Lizenzkosten pro Mitarbeiter oder Team
Anzahl betreuter Kunden pro Service-Desk-Mitarbeiter usw.


  • Reifegradbestimmung (z.B. CMMI- oder EFQM-Modell)
  • KVP

5.5.1 Service Desk

Abbildung 14: IT-Helpdesk Quelle: ITIL Heroe's Handbook, Alex D. Paul, zohoCorp
Abbildung 14: IT-Helpdesk Quelle: ITIL Heroe's Handbook, Alex D. Paul, zohoCorp

Der Service Desk ist die zentrale Anlaufstelle für Kundenwünsche und Störmeldungen ('Trouble Tickets') und bildet somit die Kommunikationsschnittstelle zwischen Service/Serviceprovider- und Anwenderebene und übernimmt in der Regel einen Großteil des anfallenden First-Level Supports. Er ist somit ein 'Single Point of Contact' (SPOC), der die IT-Organisation als Front-Office mit fachlicher und methodischer Kompetenz repräsentiert.

Der Service-Desk stellt keinen eigenen Prozess, sondern vielmehr eine zentrale Funktion dar, die alle Prozesse des Service-Supports koordiniert. Durch die Entgegennahme von Incidents, die nicht bereits durch Monitoring-Systeme automatisch erfasst werden, macht der Service Desk die zu implementierenden/implementierten Service-Prozesse erst abrufbar.

Ein Service-Desk verfolgt verschiedene Ziele. Sein Einsatz sollte:

  • qualitativ hochwertige Unterstützung der Kunden/Anwender bieten,
  • die Kunden durch Steigerung der Zufriedenheit mit Hilfe von hoher Erreichbarkeit und schnellen Reaktionszeiten binden,
  • ein positives Image aufbauen und stützen, sowie die Mitarbeiterzufriedenheit steigern,
  • die nachgelagerten Abteilungen entlasten,
  • die „First Fix“-Rate (erste Lösung) steigern,
  • das Störungsaufkommen und unnötige Eskalationen minimieren,
  • die Servicekosten senken und
  • die vorhandenen Ressourcen effizient auslasten.

5.5.2 Incident Management

Abbildung 15: Incident Management Workflow Quelle: ITIL Heroe's Handbook, Alex D. Paul, zohoCorp
Abbildung 15: Incident Management Workflow Quelle: ITIL Heroe's Handbook, Alex D. Paul, zohoCorp
  • Begriffsdefinition Incident: ungeplantes Ereignis, das nicht zum standardisierten Betrieb eines Services gehört und tatsächlich oder potentiell eine Unterbrechung oder eine Verminderung der Servicequalität verursacht.

Das Incident-Management (nachfolgend 'IM' genannt) befasst sich mit allen Ereignissen, die einen Service stören oder negativ beeinflussen oder beeinflussen können, und ist während des gesamten Life-Cycles eines Incidents mit diesem beschäftigt. Primäres Ziel des IM ist die schnellstmögliche Wiederherstellung des jeweils betroffenen Services (gemäß Vereinbarung in pot. SLAs) und die Minimierung negativer Folgeauswirkungen auf die bestehenden Geschäftsprozesse.

Um die minimal mögliche, negative Auswirkung auf die Anwender-Geschäftsprozesse zu realisieren, ist neben dem Hauptaugenmerk einer schnellstmöglichen Wiederherstellung, insbesondere bei nur begrenzt verfügbaren Ressourcen, die zeitliche Reihenfolge der Incident-Abarbeitung von entscheidender Bedeutung.

Unter dem Begriff 'Incident' sind nicht nur tatsächliche Fehler oder Störungen zu verstehen. Unter diese Begriffsdefinition fallen ebenso:

  • Fragen von Anwendern
  • Meldungen von IT-Mitarbeitern
  • Events, die von eingesetzten Monitoring-Tools endeckt wurden und automatische Trigger auslösen

Egal wie schwer ein Incident (z.B. definierte Major Incidents, denen in der Regel deutlich kürzere Wiederherstellungszeiten zu Grunde lieggen) auch ausfällt, die Abgrenzung zu Problems (s. Problem-Management) ist in jedem Fall zu beachten. Incidents fokussieren auf Symptome und die sofortigen Auswirkungen dessen, während Problems hinsichtlich der Erforschung und Behebung der Ursachen betrachtet werden.

Für den Fall, dass zur Behebung eines Incidents, im SLA-konformen Zeitrahmen keine endgültigen Lösungen zur Verfügung stehen, sind entsprechende Workarounds zu definieren und einzusetzen. Diese sollten als Teil des Incident Management-Prozesses via Known-Error-Database bereit stehen.

Jedes auftretende Incident ist gemäß nachfolgendem, stichpunktartig beschrieben Verlauf zu dokumentieren, bzw. zu verfolgen:

  • Incident-Aufzeichnung (Logging)

Eine vollständige Erfassung (inkl. Zeitstempel einer jeden, den jeweiligen Incident betreffenden Aktion) dient als Basis die Gestaltung von zentralen Faktoren ind der Prozessgestaltung, ferner zur Bewertung der Prozessperformance. Im Incident-Ticket sind die relevanten Informationen und Maßnahmen zu dokumentieren.

  • Incident Kategorisierung zur korrekten Zuordnung evtl. Second-Level Support-Teams
  • Incident-Priorisierung zur korrekten zeilichen Abfolge der Bearbeitung verschiedener gleichzeitiger Incidents

Die Einstufung der Priorität eines Incidents hat auf einer Matrix-Auswertung der beiden Teilfaktoren 'Auswirkung' und 'Dringlichkeit' zu erfolgen

  • Initiale Diagnose und ggf. Eskalation an 2nd- oder higher-Level Support
  • Reparatur und Wiederhrstellung
  • Incident schliessen

Hierbei ist wichtig, dass der Service-Anwender die vom Service-Desk gebotene Lösung tatsächlich akzeptiert, andernfalls ist der Incident nicht zu schliessen.

Die Möglichkeit, Incidents so früh wie möglich zu entdecken, ist ein wichtiger Faktor für ein effizintes Incident Management. Mittels eines ausgerieften Event-Managements-Systems ist es durchaus möglich Incidents schon aufzuspüren, bevor der betreffende Anwender eine daraus resultierene Störung wahrnehmen kann. Um eine solche Situation zu erreichen, ist es nötig, neben dem Service-Desk weitere Quellen als Incident-Eingang zu implementieren (z.B. diverse Monitoringsysteme, die Incidents automatisch melden und die Incidentbeseitigung automatisch triggern. Um einen effizienten und pro-aktiven Incident-Management-Prozesses bereit zu stellen, ist es wichtig, dass nötige Informationen aus dem Problem-Management (z.B. Known-Errors und Informationen zu erfolgreichen Workarounds) zur Verfügung stehen.

5.5.3 Problem Management

Abbildung 16: Problem Management Workflow Quelle: ITIL Heroe's Handbook, Alex D. Paul, zohoCorp
Abbildung 16: Problem Management Workflow Quelle: ITIL Heroe's Handbook, Alex D. Paul, zohoCorp


Begriffsdefinition Problem: ungeplante Ursache für einen oder mehrere Incidents.

Das Problem-Management (nachfolgend 'PM' genannt) beschäftigt sich mit der Vermeidung von Incidents, insbesondere von sich wiederholenden Incidents, sowie der Minimierung von Auswirkungen von Incidents, die nicht im Vornherein vermeidbar waren.

Probleme, deren Ursachen identifiziert, und die Behebung desen bzw. ein effektives Workaround definiert sind, werden als Known Errors bezeichnet und finden Eingang in die sogenannte 'Known-Error-Database' und stehen auf diesem Weg anderen Service-Prozessen (z.B. dem Incident-Management-Prozess, s. vorhergehender Abschnitt) zur Verfügung.

Für die Untersuchung und Behebung von Problems haben sich die folgenden Methoden etabliert:

  • Chronologische Analyse

Sehr einfache Methode, die den chronologischhen Verlauf eines Problems dokumentiert und anschliessend aus der Chronologie konkrete Schlüsse gewonnen werden können, hinsichlich der Ursachen und möglicher Folgeerscheinungen.

  • Pain-Value-Analysis

Anzahl und Kritikalität (z.B. Anzahl betroffener Anwender, tatsächliche Down-Times von businesskritischen Services oder Funkionen) von aufgetretenen Incidents werden gegenübergestellt, um die Priorität der Abarbeitungsreihenfolge festzulegen.

  • Kepner and Tregoe

Methode zur strukturierten Problemanalyse [10] mit Abarbeitung der Methodenschritte "Problemdefiniton, Problembeschreibung, Identifizieren der möglichen Ursachen, Testen der möglichen Ursachen in der Reihenfolge der höchsten Wahrscheinlichkeiten, erkannte Ursache überprüfen".

  • Pareto-Analyse (80/20)

Methode zur Abgrenzung wichtiger von weniger wichtigen Problemen. Pareto basiert auf der Annahme, dass die meisten (80%) auftretenden Probleme auf nur wenige (20%) Ursachen zurückzuführen sind. Die Beseitigung der derart identifizierten Ursachen könnte demnach eine Beseitigung der allermeisten Probleme folgen.

5.5.4 weitere ITIL Serviceprozesse

Über die vorstehend beschriebenen ITIL-Serviceprozesse hinaus, existieren weitere in ITIL3 (Book: Service-Operation) beschriebene Prozesse, die für ein ganzheitliches ITSM mittlerweile als Standard und best-practice-cases etabliert sind. Dazu gehören u.a. das:

  • Eventmanagement
  • Request Fulfilment
  • Access Management
  • Change Management
  • Confiuration Management
  • Release Management

deren detaillierte Beschreibung hinsichtlich Design und Intrafunktionalität den Rahmen dieser Ausarbeitung sprengen würde. Die für die konzeptionelle Erarbeitung hinsichtlich der Einführung eines HelpDesks hauptsächlich zugrunde liegenden Services wurden vorstehend beschrieben.

5.6 Kundenorientierung

Go to top
Abbildung 17: Beispiel für einen Feedbackbogen
Abbildung 17: Beispiel für einen Feedbackbogen

"Kundenorientierung ist die umfassende, kontinuierliche Ermittlung und Analyse der individuellen Kundenerwartungen sowie deren interne und externe Umsetzung in unternehmerische Leistungen sowie Interaktionen im Rahmen eines Relationship-Marketing-Konzepts mit dem Ziel, langfristig stabile und ökonomische vorteilhafte Kundenbeziehungen zu etablieren." Manfred Bruhn, 2003[11]

Fehler in IT Systemen, insbesondere solche, die unternehmenskritische Systeme betreffen, müssen frühzeitig erkannt, klar identifiziert und schnell behoben werden – die Anforderungen an die Qualität der betreffenden Prozesse, des sogenannten IT Services, sind dementsprechend hoch.

In einer Umfrage der Industrie und Handelskammer im Raum Stuttgart gaben 90 Prozent der Unternehmen an, dass sie aktiv Kundenbindungsmaßnahmen anwenden. Allerdings führten lediglich 43 Prozent regelmäßige Kundenzufriedenheitsbefragungen durch. [12] Wie soll man den Service und die Leistung verbessern, wenn man nicht weiß was gut ist und was verbesserungswürdig?

Was im Dienstleistungssektor selbstverständlich ist, soll für den Service Desk eines Unternehmens zu Grunde gelegt werden. Der Service Desk ist Dienstleister innerhalb eines Unternehmens. Die Anwender entscheiden über die Effektivität des Service und zukünftige Anfragen. Dies ist stark Abhängig von der Service Qualität.

Die Servicezeiten richten sich nach den Betriebszeiten des Unternehmen, denn immer wenn Mitarbeiter Technik nutzen wollen, ist mit Fragen und Problemen zu rechnen. Anfragen erreichen den Service Desk auf allen Kommunikationskanälen (Mail, Chat, Telefon & direkt).

Der schlimmste Fall ist ein Betriebsstillstand. Ist dieser durch die IT verursacht muss der Service Desk schnellst möglich an dessen Behebung arbeiten, um die Ausfallzeiten und damit verbundene "Lost Units" zu minimieren.

Informationen zum Bearbeitungsstatus für die Nutzer und Anfragensteller sind aktiv vom Service Desk zu kommunizieren. Ebenso ist eine Befragung und Analyse der bearbeiteten Tickets notwendig, um regelmäßig Informationen zum geleisteten Service zu erhalten. Hilfreich hierfür ist ein kurzer Feedbackbogen, den die Mitarbeiter nach Abschluss des Falls via Mail oder Internetformular bearbeiten.

5.7 Service Level Agreement

Wartungsverträge für Hardware und Software werden heute in der Regel durch Service Level Agreements ersetzt. In diesemn Dokument wird zwischen den Vertragsparteien geregelt in welchem Umfang Leistungen und Pflichten exisiteren. Für vier Fälle sind SLAs besonders geeignet:

  • Netzwerkdienste
  • Systemservices
  • Aplicationservices
  • End-To-End (Kombinationsvertrag)

Rechtlich gesehen werden SLAs als Dauerschuldverhältnisse behandelt. Sie können unbefristet & befristet sein und dabei für beide Vertragsparteien Sonderkündigungsrechte beinhalten. Für eine fristlose Kündigung sind jedoch hohe Anforderungen im SLA zu vermerken.

IM SLA sind die Leistungen des Service Anbieters und die Pflichten des Kunden genau beschrieben.

Gänginge Leistungsbereiche[13]im SLA:

  • Instandhaltung, nutzungsabhängig oder nach einem festen Zeitplan
  • Instandsetzung aufgrund einer Fehlermeldung oder eines Kundenabrufes
  • Fernwartung oder Ferndiagnose
  • zusätzliche Leistungen, beispielsweise die vorübergehende Überlassung einer Ausweichanlage bei längerer Instandsetzung
  • Beseitigung von Mängeln
  • Telefonische Unterstützung/Hotline
  • Lieferung von Updates und Upgrades
  • Schulung von Mitarbeitern
  • Beratung bei der Bedienung und Erweiterung der EDV-Anlage

Für den Kunden sind in erster Linie die im SLA festgehaltenen Service- und Reaktionszeiten interessant. Durch diese Angabe ist festgelegt in welchem Zeitrahmen der Service Anbieter täglich zur Verfügung stehen muss und wieviel Zeit ihm für die Instandsetzung der Systeme maximal bleibt.

Zudem sollten in jedem SLA die folgenden Punkte geregelt sein:

  • Vergütung
  • Gewährleistung & Haftung
  • Urheberrechte von Software
  • Datenschutz, -sicherung
  • salvatorische Klausel

Ein mit allen Punkten ausgestatter Vertrag hilft allen Parteien im täglichen Umgang mit der IT. Zudem gibt er Sicherheit im Streitfall.

6 Fazit

Die Übersicht der unterschiedlichen Open Source Trouble Ticket Systeme in dieser Arbeit zeigt, dass es einen Markt mit unterschiedlichen Schwerpunkten gibt. Je nach Anwendungsfall und Anforderungen kann auch mit wenig Budget zielgerichtet eine Supportinfrastruktur aufgesetzt und ggf. nach eigenen Bedürfnissen ergänzt oder angepasst werden. Der Einsatz des OTRS Systems war für die Bedarfe der Ghost Industries die optimale Entscheidung.

Ein Trouble Ticket System ist ein erster Schritt einen Helpdesk mit einem professionellen Tool auszurüsten, um kundenorientieren Anforderungen gerecht zu werden.

Ein IT Problem kann unterschiedliche Ausprägungen und Folgen haben. Der Leidtragende, der Anwender und oder Applikation Eigner, setzt demzufolge Vertrauen in die Organisation bei dem er um Hilfe bittet.

Mit der Einführung des Trouble Ticket-Systems wird der IT Betrieb der Ghost Industries unter anderem dem Anwender durch eine professionelle Abwicklung in der Störungsannahme, zyklischen Statusberichten über den Werdegang und Entwicklung einer gemeldeten Störung, Ursachenbericht und abschließenden Feedbackbogen ein großes Maß kundenorientierter Störungsabwicklung entgegenbringen, sowie es auch von der Geschäftsleitung gefordert wurde.

Die optimale Bearbeitung von IT Problemen im Zusammenspiel mit dieser Knowledge Area stellt eine gewisse Unabhängigkeit sicher und sorgt für einen standardisierten Prozess im täglichen Störungshandling.

Ein Hindernis bei der Einführung eines Trouble Ticket System könnte sich durch Mitarbeiter ergeben, die ihr Wissen durch Alleinstellungsmerkmale nur unzureichend dokumentieren. Je größer ein Unternehmen und je ausgeprägter seine Kultur sind, umso länger dauert ein offener Umgang mit Wissen. Die methodische Entwicklung und systematische Erfassung von Geschäftsprozessen und Abhängigkeiten der unterschiedlichen IT Komponenten ist ein wichtiger Schritt zur Wandlung von einem funktionalen zu einem prozessorientierten Unternehmen.

Durch eine zentrale Anlaufstelle (Service-Desk) werden Kosten minimiert, da das Störungsaufkommen nun „messbar“ und dadurch transparent wird. Schwerpunkte und immer wiederkehrende Störungen werden sich schnell herauskristallisieren, so das zielgerichtet Maßnahmen oder Systemoptimierungen vorgenommen werden können – ggf. bis hin zu einem Redesign eines Systems führen zur Vermeidung von LostUnits -.

Auch mangelndes Anwender Know How kann einen positiven Wandel herleiten, in dem entsprechende Systemschulungen organisiert werden.

Ein Innovationshindernis kann der Faktor Zeit werden: Der Service-Desk benötigt Mitarbeiter, die genügend Freiraum haben, sowie ein gewisses Maß an Disziplin mitbringen das Trouble Ticket System nach gewissen „Prioritäten und Spielregeln“ zu bedienen und regelmäßig zu pflegen.

Die Verbesserung des IT Supports durch die Einführung eines Trouble Ticket Systems ist nur ein Teil der Wertschöpfungskette. Der Einsatz des bestehenden Supportteams und durch Veränderung der Störungsbearbeitung kann dazu beitragen, dass weitere Synergien entstehen und die IT-Mitarbeiter wertschöpfender - im Sinne von IT Betrieb und Support – eingesetzt werden.

7 Fußnoten

  1. Vgl. ITIL 2.0
  2. http://otrs.org
  3. Vgl. ITSM in der Praxis mit ITIL 3 - M. Beims, 2010
  4. Vgl. Doppler, Fuhrmann, Lebbe-Waschke und Voigt 2002
  5. Vgl. Melan, 1993
  6. de Bruin T, Rosemann M, Freeze R, Kulkarni U, 2005
  7. Grundlagen und Modelle des Information Lifecycle Management von Günter Thome und Wolfgang Sollbach, 2007
  8. Mettler, Tobias, A Design Science Research Perspective on Maturity Models in Information Systems, St. Gallen : Institute of Information Management, 2009
  9. Informatik im Fokus - ITIL, C. Styck, K. Zeppenfeld, 2008
  10. http://www.kepner-tregoe.com
  11. Manfred Bruhn, 2003, [1]
  12. Kundenorientierung - Eine Analyse bei Dienstleistern in der Region Stuttgart, [2]
  13. Leistungsbereiche im SLA[3]

8 Abbildungsverzeichnis

Abbildung 1 Ziele des Help Desk
Abbildung 2 Störungsklassifizierung
Abbildung 3 Beispiel für Diagramme
Abbildung 4 Aufnahme eines Tickets durch den Agent
Abbildung 5 OTRS Verbreitung
Abbildung 6 Fallbearbeitung, Ablauf und Kommunikation zw. Anwender und Serviceprovider
Abbildung 7 Userhinweis
Abbildung 8 Beispiel eines UWG
Abbildung 9 Nutzung von Computer und Internet (2002-09) Quelle:www.destatis.de
Abbildung 10 Preisindex (2009 ggü. 2005) Quelle:www.destatis.de
Abbildung 11 Einfluss auf die Kosten
Abbildung 12 IT Spannungsumfeld
Abbildung 13 Deming-Cycle
Abbildung 14 IT-Helpdesk
Abbildung 15 Incident Management Workflow
Abbildung 16 Problem Management Workflow
Abbildung 17 Beispiel für einen IT Feedbackbogen
Persönliche Werkzeuge