Warum Zurufe die eigentlichen IT-Probleme verdecken

In vielen mittelständischen Betrieben läuft die IT-Unterstützung über drei Wege gleichzeitig: einen Anruf, eine Mail an eine persönliche Adresse und das Gespräch auf dem Gang. Solange das Haus klein und die zuständige Person erreichbar ist, funktioniert das erstaunlich gut. Es funktioniert genau so lange – und es verdeckt bis dahin, wie viel Arbeit die IT tatsächlich bindet und woran sie eigentlich hängt.

Die eigentliche Schwäche des Zurufs ist nicht die Unordnung, sondern die Unsichtbarkeit. Was niemand erfasst, lässt sich nicht zählen, nicht einordnen und nicht begründen. Die Geschäftsführung sieht keine Störungen, sondern nur den Eindruck, dass die IT viel zu tun hat. Wer daraus einen Antrag auf eine zusätzliche Stelle, ein anderes Werkzeug oder den Austausch einer Altanwendung ableiten will, hat dafür keine Grundlage außer dem eigenen Bauchgefühl.

Ein zweiter Effekt ist noch unangenehmer: Zurufe werden in der Reihenfolge ihres Eintreffens bearbeitet, nicht in der Reihenfolge ihrer Bedeutung. Wer am lautesten ruft oder dem Büro der IT am nächsten sitzt, kommt zuerst. Der stillgelegte Arbeitsplatz in der Fertigung wartet, während ein defekter Bildschirmständer in der Verwaltung erledigt wird.

Was ein Vorgang leistet und ein Zuruf nicht

Ein Ticketsystem ist im Kern ein Eingangsbuch mit Zuständigkeit. Jede Meldung erhält eine Nummer, einen Melder, einen Eingangszeitpunkt, eine Einstufung und eine verantwortliche Person. Der Verlauf bleibt am Vorgang hängen, nicht im Postfach eines Einzelnen. Damit ist auch nach Wochen nachvollziehbar, wer was entschieden hat und warum eine Sache liegen blieb.

Der zweite Nutzen entsteht erst mit der Zeit und wird regelmäßig unterschätzt: Wiederkehrende Meldungen werden sichtbar. Dreißig einzeln bearbeitete Anrufe zum langsamen Aufbau einer Anwendung sind dreißig Ärgernisse. In einer Auswertung sind sie ein benennbares Problem mit einer Ursache, über die man entscheiden kann. Ohne Erfassung wird jedes Mal das Symptom behandelt.

Wichtig ist dabei die Trennung zweier Dinge, die gern zusammengeworfen werden. Eine Störung ist ein Zustand, der von der vereinbarten Funktion abweicht und behoben werden soll. Eine Anfrage ist ein Wunsch nach etwas Neuem – ein zusätzliches Konto, eine Software, ein Zugriff. Beides braucht andere Fristen, andere Genehmigungen und andere Bearbeiter. Wer beides in einen Topf wirft, bekommt eine Warteschlange, in der nichts mehr vergleichbar ist.

Ein Meldeweg, nicht fünf

Die häufigste Ursache dafür, dass ein neu eingeführtes System nach einem halben Jahr leer bleibt, ist der Fortbestand der alten Wege. Solange eine Meldung per Mail an die persönliche Adresse des Administrators zum Ziel führt, wird sie genau dorthin gehen. Der Meldeweg muss deshalb nicht nur vorhanden, sondern der einfachste verfügbare sein. Bewährt haben sich wenige, klar benannte Regeln:

Der letzte Punkt entscheidet über die Akzeptanz. Wer beim Melden das Gefühl hat, sich rechtfertigen oder erst selbst analysieren zu müssen, meldet beim nächsten Mal gar nicht mehr – und arbeitet mit einem Umweg weiter, von dem niemand erfährt.

Einstufung: Auswirkung und Dringlichkeit sind zwei Fragen

Eine Priorität, die der Melder selbst setzt, ist wertlos: Für jeden ist das eigene Problem dringend. Tragfähig wird die Einstufung erst, wenn sie aus zwei getrennten Größen entsteht. Die Auswirkung beschreibt, wie viel Betrieb betroffen ist – eine Person, eine Abteilung, ein Standort, ein Geschäftsprozess. Die Dringlichkeit beschreibt, wie schnell der Schaden wächst, wenn nichts geschieht.

Aus der Kombination ergibt sich eine kleine Matrix mit drei oder vier Stufen, mehr braucht kein Mittelständler. Entscheidend ist, dass die Stufen an Beispielen aus dem eigenen Haus festgemacht werden und nicht an abstrakten Begriffen. Steht die Auftragsannahme, ist das die höchste Stufe. Kann eine Person nicht drucken, während ein Ersatzdrucker im Nebenraum steht, ist es die niedrigste – auch wenn sie es anders empfindet.

Zwei Sonderfälle gehören ausdrücklich geregelt. Der erste ist der Sicherheitsvorfall: Er hat eine eigene Eskalationskette, weil hier Fristen von außen wirken. Unternehmen im Anwendungsbereich des BSI-Gesetzes müssen erhebliche Sicherheitsvorfälle unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntnis, in einer Erstmeldung anzeigen, innerhalb von 72 Stunden mit einer Bewertung nachlegen und spätestens einen Monat nach der Meldung eine Abschluss- oder Fortschrittsmeldung abgeben. Diese Uhr läuft ab Kenntnis – also ab dem Moment, in dem die Meldung im Servicedesk liegt. Der zweite Sonderfall ist der Datenschutzvorfall, der eine eigene interne Meldekette zum Datenschutzbeauftragten braucht.

Zuständigkeit heißt Eigentümer, nicht Bearbeiter

Jeder Vorgang braucht genau eine Person, die für seinen Fortgang verantwortlich bleibt – auch dann, wenn die Arbeit bei einem Dienstleister, einem Hersteller oder einer Fachabteilung liegt. Diese Rolle ist nicht die des Bearbeiters, sondern die des Eigentümers. Ohne sie entstehen die Vorgänge, die formal zugewiesen sind und sachlich seit sechs Wochen niemanden beschäftigen.

Für eine kleine IT-Mannschaft genügen zwei Ebenen. Die erste nimmt an, ordnet ein und erledigt alles, was mit Standardhandgriffen zu lösen ist. Die zweite übernimmt, was Systemwissen verlangt. Wird die IT teilweise oder ganz extern betreut, sollte das Ticketsystem dem Unternehmen gehören und der Dienstleister darin arbeiten – nicht umgekehrt. Sonst bleibt die Betriebsgeschichte beim Anbieter, und ein Wechsel kostet nicht nur Geld, sondern Wissen.

Fünf Kennzahlen genügen

Die Versuchung ist groß, alles zu messen, was das Werkzeug hergibt. Nützlich sind wenige Zahlen, die eine Entscheidung tragen, und ein Blick darauf einmal im Monat:

Bei Auswertungen ist eine Grenze zu beachten. Zahlen zur Leistung einzelner Bearbeiter sind arbeitsrechtlich heikel. Nach § 87 Absatz 1 Nummer 6 des Betriebsverfassungsgesetzes unterliegt die Einführung und Anwendung technischer Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung der Beschäftigten zu überwachen, der Mitbestimmung des Betriebsrats. Ein Ticketsystem kann dazu gehören. Wer Auswertungen bewusst auf Kategorien, Systeme und Zeiträume beschränkt und personenbezogene Ranglisten von Anfang an ausschließt, umgeht keine Regel – er vermeidet eine Diskussion, die das Vorhaben sonst um Monate verzögert.

Was bei der Einführung regelmäßig schiefgeht

Der erste Fehler ist die Werkzeugwahl am Anfang. Die Reihenfolge lautet: Meldeweg festlegen, Kategorien und Einstufung festlegen, Zuständigkeiten festlegen – und erst dann ein Werkzeug suchen, das das abbildet. Der zweite Fehler ist ein zu feines Kategorienschema. Vierzig Kategorien führen dazu, dass niemand sorgfältig einordnet; zehn bis fünfzehn reichen, und sie lassen sich nach einem halben Jahr anhand der tatsächlichen Vorgänge schärfen.

Der dritte Fehler ist der stille Start. Ein System, das eingerichtet, aber nicht angekündigt wird, bleibt ungenutzt. Es braucht eine kurze Ansage der Geschäftsführung, dass ab einem Datum über diesen Weg gemeldet wird, eine Erklärung von wenigen Minuten je Abteilung und die Disziplin der IT, Zurufe freundlich, aber konsequent in den Vorgang zu überführen. Der vierte Fehler ist der Verzicht auf eine Rückmeldung beim Abschluss: Wer nie erfährt, dass und wie seine Meldung gelöst wurde, glaubt dem System nicht.

Für die Geschäftsführung bleibt am Ende eine einfache Probe. Sie fragt nach der Zahl der offenen Vorgänge, nach den drei häufigsten Meldungsarten des letzten Quartals und danach, welches Vorhaben daraus abgeleitet wurde. Kommen die Antworten aus einer Auswertung und nicht aus der Erinnerung, arbeitet der Servicedesk. Kommen sie aus der Erinnerung, existiert er auf dem Papier.

Verwandte Themen: Wer hier weiterdenkt, liest bei IT-Monitoring, Dokumentenmanagement und IT-Sicherheitsbudget weiter.