Planung und Einsatz von Helpdesk-Systemen

Praxis: Wie man ein Helpdesk-System richtig einführt

25. März 2009, 13:36 Uhr | Bernd Reder

Fortsetzung des Artikels von Teil 1

Effizienz nur durch Integration in Client-Management

In einem vollintegriertem Helpdesk-System lassen sich neue Tickets einfach per Mausklick mit einem inventarisierten Rechner verknüpfen.
In einem vollintegriertem Helpdesk-System lassen sich neue Tickets einfach per Mausklick mit einem inventarisierten Rechner verknüpfen.
Vor der Installation eines Helpdesk-Systems sollte ein Unternehmen definieren, welche IT-Systeme geschäftskritisch sind und dann durch entsprechende Eskalationsstufen sicherstellen, dass dort auftretende Probleme schnell behoben werden.
Vor der Installation eines Helpdesk-Systems sollte ein Unternehmen definieren, welche IT-Systeme geschäftskritisch sind und dann durch entsprechende Eskalationsstufen sicherstellen, dass dort auftretende Probleme schnell behoben werden.
Ist der Helpdesk komplett in das Systemmanagement mit Inventarisierung und Softwareverteilung integriert, kann der First-Level-Support kleinere Probleme schnell selber lösen.
Ist der Helpdesk komplett in das Systemmanagement mit Inventarisierung und Softwareverteilung integriert, kann der First-Level-Support kleinere Probleme schnell selber lösen.
Eine Knowledgebase macht es einfacher, häufig wiederkehrende Anfragen zu beantworten.
Eine Knowledgebase macht es einfacher, häufig wiederkehrende Anfragen zu beantworten.

Ruft beispielsweise ein Benutzer beim Helpdesk an, weil auf seinem Windows-Rechner »der Abteilungsdrucker verschwunden ist«, so kann ein Mitarbeiter im Support in einem für sich allein stehenden Helpdesk dieses Problem zwar korrekt erfassen und qualifizieren. Die Suche nach der Ursache des Problems sowie die notwendigen Maßnahmen zur Lösungen werden ihn jedoch eine gute Weile beschäftigen.

Denn zunächst muss sich der Support die Daten des betroffenen Rechners zusammensuchen, hoffen, dass diese aktuell sind, dann die Anwendung für das Client-Management starten und schließlich dort versuchen, das Problem zu lösen.

Bei einem vollintegrierten System ist der Ablauf hingegen deutlich schneller: Hier sieht bereits der First-Level-Support nach dem Erfassen des Tickets im Helpdesk mit einem Mausklick die Inventarisierungsdaten des betroffenen Rechners, stößt mit einem zweiten Klick die Softwareverteilung an und stellt anschließend mit einem hinterlegten Skript die richtigen Verknüpfungen wieder her.

Solche Standardfälle machen in der Praxis den Löwenanteil der Supportanfragen aus. Sie lassen sich daher nur dann effizient bearbeiten, wenn Helpdesk, Inventarisierung und Softwareverteilung eng miteinander verzahnt sind.

Eine theoretische Alternative zu einem vollständig in das Client-Management integrierten Helpdesk sind Systeme unterschiedlicher Hersteller, die über Schnittstellen zusammenarbeiten.

In der Praxis bedeutet dies aber, dass man bei Helpdesk, Inventarisierung und Softwareverteilung bereits zwei Schnittstellen definieren und pflegen muss. Die Implementierung solcher Schnittstellen erfordert jedoch bei der Erstinstallation in den meisten Fällen zusätzliche Beratungsleistung.

Zudem bergen Schnittstellen immer das Risiko von nicht kalkulierbaren Folgekosten. Bringt beispielsweise der Hersteller der Inventarisierungssoftware eine neue Version seines Produkts heraus, kann es sein, dass dies eine Nacharbeitung der entsprechenden Schnittstelle zum Helpdesk erfordert.

Ein vollständig integriertes Produkt stellt dagegen sicher, dass solche Probleme in der Zukunft gar nicht erst auftauchen. Es bietet Anwendern somit Investitionssicherheit.

Schon vor der Installation eines Helpdesk-Systems sollte sich ein Unternehmen darüber hinaus Gedanken über Service-Level und Eskalationsstufen machen. Ein Service-Level legt fest, wie lange ein bestimmtes System ausfallen darf beziehungsweise wie schnell mit der Fehlerbehebung zu beginnen ist.

Um die Wichtigkeit eines Systems zu bestimmen, hilft es, die Kosten zu berechnen, die ein Systemausfall verursachen würde sowie dessen Wahrscheinlichkeit zu schätzen. Je höher die Kosten, desto höher sollte dann auch die Priorität bei der Fehlerbehebung sein.

Allgemeine Empfehlungen auszusprechen, ist dabei schwierig. Denn für einen Internet-Händler hat beispielsweise der eigene Web-Server eine ganz andere Priorität als für eine Organisation, die dort lediglich über ihre Ziele und Kontaktmöglichkeiten informiert.

Während bei letzterer ein Ausfall des Web-Servers für ein paar Tage zwar ärgerlich, aber nicht kritisch wäre, könnte dies für den Online-Händler existenzbedrohend sein. Vergleichbares gilt für andere Serversysteme wie Mailserver, Datenbanken oder Faxdienste ebenso wie für Arbeitsstationen.

Eskalationsstufen legen fest, ab welchem Zeitpunkt der Helpdesk einen Vorfall an die nächsthöhere Instanz »eskaliert« und um welchen Personenkreis es sich dabei handelt. Auch hier ist die Umsetzung in der Praxis individuell an die Prozesse des eigenen Unternehmens anzupassen.

Im Fall des Web-Servers des Internet-Händlers wäre eine sehr schnelle Eskalation eines Problems vom Second-Level-Support beispielsweise direkt an die Geschäftsleitung anzuraten. Der Ausfall des PC-Arbeitsplatzes eines Praktikanten könnte hingegen erst nach einem Tag an den Leiter Helpdesk eskaliert werden, wenn bis dahin noch keine Maßnahmen zur Fehlerbehebung ergriffen wurden.

Tickets sollten auch dann automatisch eskaliert werden, wenn sie nicht innerhalb einer bestimmten Zeit von einem Mitarbeiter im First-Level-Support qualifiziert wurden. Denn meldet beispielsweise ein Kunde ein Problem mit dem Web-Shop, so kann der zuständige Systembetreuer nur dann reagieren, wenn er auch über das Problem informiert wurde.

Ebenso wie die Planung von Service-Leveln und Eskalationsstufen sollte vor der Einführung eines Helpdesk-Systems die Erstellung von Notfallplänen stehen. Diese enthalten unter anderem Verfahren und Anweisungen für das IT-Personal, wie in ganz konkreten Problemfällen vorzugehen ist sowie Erstmaßnahmen zur Schadensbegrenzung, Schritte für den Übergang in den operativen Betrieb nach der Fehlerbehebung sowie Kontaktinformationen.

Notfallpläne sollten idealerweise direkt im Helpdesk in einer Wissensdatenbank abgelegt sein, damit die entsprechenden Mitarbeiter im Schadensfall schnell darauf zugreifen können.

Ebenfalls bei der Einführung eines Helpdesks ist zu klären, ab wann ein offenes Ticket als erledigt gilt. Darf beispielsweise der Helpdesk automatisch ein Ticket schließen, wenn dessen Status länger als zwei Wochen auf »Warten auf Rückmeldung vom Benutzer« steht?

Eine generelle Regel ist auch hier schwer festzulegen. Doch sollte die automatische Schließung von Tickets sehr gut überlegt sein.

Dabei spielt zudem die Servicementalität und erwünschte Servicequalität der IT-Abteilung eine Rolle. So ist es zwar lästig, einem Benutzer mehrmals hinterher zu telefonieren, um herauszufinden, ob sein Problem gelöst wurde. Einem externen Kunden hingegen würde man diesen Dienst wahrscheinlich ohne großes Nachdenken erbringen, wenn die Qualität des Kundenservice einen hohen Stellenwert hat.

Andererseits kann gerade in großen Unternehmen oder bei einem Helpdesk für Endkundensupport im Massenmarkt eine automatische Ticketschließung sogar notwendig sein, um der großen Zahl von – teils unqualifizierten und unnötigen – Anfragen überhaupt Herr zu werden.

Beim unternehmensinternen Support kann auch die Förderung der sozialen Kompetenz der restlichen Mitarbeiter dabei helfen, Helpdesk-Prozesse zu optimieren. Eine simple Antwort-E-Mail mit den Worten »Danke, Problem gelöst« ist dann nicht nur Zeichen dafür, ein Ticket zu schließen, sondern freut und motiviert auch die IT-Abteilung.

Gerade bei der Definition von Service-Leveln, Eskalationsstufen, Notfallplänen und Ticketstati ist es in der Praxis meist sinnvoll, sich externer Beratung zu bedienen. Für Unternehmen mittlerer Größe reichen dafür in der Regel ein bis zwei Tage Beratungsleistung aus, und dieses Geld ist gut investiert.

Denn der Erfahrungsschatz eines etablierten Dienstleisters hilft dabei, die eigene Betriebsblindheit zu überlisten und Designfehler zu vermeiden, die später ein Vielfaches an Kosten verursachen können.

Soll eine bestehende Insellösung in ein integriertes Helpdesk- und Clientmanagement-System überführt werden, so stellt sich schließlich noch die Frage nach der Migration der dort eingepflegten Daten.

In den meisten Fällen wird man darauf wahrscheinlich verzichten, weil alte und geschlossene Trouble-Tickets hauptsächlich statistischen Wert haben. Statt einer Datenübernahme bietet es sich hier an, den alten Helpdesk zunächst parallel zum neuen integrierten System zu betreiben, solange dort noch ungelöste Incidents offen sind.

Neue Tickets werden dann nur noch im neuen System angelegt. Einträge aus der Wissensdatenbank sollten hingegen auf das neue System migriert werden. Hier bietet ein Systemwechsel in der Praxis immer einen willkommenen Anlass dafür, Altlasten loszuwerden. So interessieren heute wahrscheinlich kaum einen Administrator oder Mitarbeiter Anleitungen zur Fehlerbehebung unter Windows NT 3.51 oder NT 4.

Vor der Einführung eines Helpdesks sollte sich ein Unternehmen viele Gedanken machen, damit das Projekt auch das bringt, was es sich davon erwartet. Nur mit einer guten Planung lassen sich die Voraussetzungen dafür schaffen, die Effizienz der IT-Abteilung zu steigern, unnötige Tätigkeiten zu vermeiden und Transparenz herzustellen.

Bei der Auswahl des richtigen Helpdesk-Systems sollten Unternehmen dazu frei nach Loriot vorgehen: Ein Helpdesk ohne integriertes Client-Management ist möglich, aber sinnlos.

Der Autor: Sebastian Weber ist Produktmanager bei Aagon und verantwortlich für die Clientmanagement-Lösung ACMP.


  1. Praxis: Wie man ein Helpdesk-System richtig einführt
  2. Effizienz nur durch Integration in Client-Management

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Aagon Consulting GmbH

Matchmaker+