Ein undurchsichtiges, fehleranfälliges, mailbasiertes System
Im Unternehmen ist der zentrale Kommunikationskanal ein simples Mailkonto, das per IMAP über etwa fünf Rechner abgerufen und synchronisiert wird. Mehr als 95 Prozent der dort einlangenden Nachrichten sind Kundenanfragen, das reibungslose Funktionieren dieser Mailadresse ist daher von enormer Wichtigkeit. Das Mailkonto wird vor Ort von drei Personen betreut, zwei weitere rufen es im Home-Office ab. Vor Ort sind die Nutzer aufgrund der vorhandenen IT-Betreuung – ja, das ist der Herr, der 2006 noch meinte, niemand brauche Tab-Browsing – an Microsoft Outlook gebunden. Und das, obwohl sie außer den sechs Funktionen „Neue Nachricht erstellen“, „Antworten“, „Allen antworten“, „Weiterleiten“, „Löschen“ und „In Ordner verschieben“ keine einzige der vielen weiteren Funktionen des Programms nutzen. Stattdessen ist im Laufe der Jahre ein kompliziertes System von Zuweisungsregeln entstanden, das, vor allem bei einem Blick von Außen, bestenfalls als „Irrsinn“ beurteilt werden kann.
Von den einlangenden Kundenanfragen kann ein Teil sofort, unproblematisch und vor Ort beantwortet werden. Ein Teil benötigt eine gewisse Zeit, weil zB Recherchen durchgeführt oder Terminkollisionen aufgehoben werden müssen, und wird daher erst später beantwortet; und ein weiterer Teil muss an die dafür Zuständigen weitergeleitet werden. Gibt es Anmerkungen zu einer Anfrage, so werden diese in einem Notizbuch aufgeschrieben (!) oder das E-Mail wird ausgedruckt und händisch kommentiert (!). Über diese Vorarbeiten wird dann die Person, die die Anfrage übernehmen soll, meist telefonisch (!) informiert. Ist die Anfrage selbsterklärend, so wird sie, je nach Bearbeitungsstand und bearbeitender Person in verschiedene IMAP-Ordner verschoben. Und genau so sieht das Mailkonto auch aus: Eine Sammlung von für Außenstehende und solche, die nicht tagtäglich damit zu tun haben, nicht mehr durchschaubare Ordnerstrukturen. – In meinen Augen Zeichen dafür, dass das Handling und dieses „System“ die eigentliche Tätigkeit nicht unterstützt, sondern blockiert.
Vorteile des Ticketing-Sytems
Wen funktionelle Argumente nicht interessieren, kann zum nächsten Kapitel springen.
Da ich immer wieder wegen diverser Probleme mit diesem „System“ Support leisten muss, habe ich der Geschäftsführung unter Beisein zweier die Anfragen bearbeitender Personen den Vorschlag gemacht, anstelle der manuellen Bedienung des Systems mittels Outlook ein Ticketing-System einzurichten, das alle Probleme, die es bis dato gab, auf einen Schlag löst:
(1) Jeder Bearbeiter erhält sein eigenes Login. Gegenwärtig wird ein Mailkonto mit fünf Rechnern synchronisiert. Alle Clients nutzen ein und daselbe Login. Möchte einer der beiden im Home-Office arbeitenden Personen das Mailkonto auf einem neuen Rechner einrichten, ist die Gefahr immer groß, dass Funktionen wie die AutoArchivierung (Danke, Outlook!) oder schlichtweg die Wahl des falschen Protokolls (POP) zu massiven Problemen führt. E-Mails verschwinden, werden verschoben, gelöscht… Außerdem ist das gemeinsame Login eine riesige Sicherheitslücke, vor allem bei denjenigen, die ihr Notebook gerne unverschlüsselt und ohne Kennwort gesichert an gut zugänglichen Orten liegenlassen. Würde auch nur einer der Personen das Notebook zB gestohlen werden, hätte der Dieb vollen Zugang zu mehreren Jahren an E-Mail-Kommunikation.
Mit dem Ticketing-System wäre das Problem mit einem Schlag vom Tisch. Erstens, das System ist webbasiert, ergo können auch keine Daten durch den Diebstahl eines Rechners nach Außen gelangen. Zweitens hat jeder Nutzer eine spezifische Rolle und ein eigenes Login. Damit können Anfragen, die nunmehr nicht als E-Mails, sondern als Tickets gespeichert werden, bestimmten Personen zugeordnet und damit nicht mehr zB doppelt bearbeitet werden.
(2) Zuordnung, Status und Archivierung. Auch dieser Punkt ist in einem Ticketingsystem gelöst. Eine Anfrage wird erstellt und sofort einer Person zugewiesen (oder für alle offen gelassen). Für jeden ist sofort ersichtlich, ob die Anfrage offen, in Bearbeitung oder abgeschlossen ist. Mit dem Status „abgeschlossen“ tritt auch eine dem Nutzerverhalten logisch entsprechende Aktion ein: Das Ticket/die Anfrage wird aus dem Bereich der zu bearbeitenden Anfragen entfernt und archiviert. – Die Archivierung wird damit zum Teil des inhaltlich relevanten Tuns und ist nicht ein nutzerzentriertes Feature.
(3) Möglichkeit der internen Kommunikation, Historie und Nachverfolgbarkeit. Auch dieses Problem, ich habe es oben schon beschrieben, ist groß und würde mit dem Ticketingsystem aus der Welt geschafft werden. Jeder einzelnen Nachricht, jedem Ticket, jeder noch so kurzen Anfrage können interne Notizen hinzugefügt werden, die den Verlauf kommentieren oder um wichtige Informationen ergänzen. Natürlich könnte man nun argumentieren, dass das in den meisten Fällen nicht notwendig ist, aber um die geht es nicht. Es geht um genau die Fälle, wo ein Notizblock, der 2009 wichtige Informationen enthielt, im Jahr 2015 nicht mehr auffindbar ist; um die Anfragen, die sich auf vorige Anfragen beziehen. Der wichtigste Punkt daran ist aber, dass das Ticket und die interne Kommunikation im gleichen System gespeichert sind. Und das bringt mich auch gleich zum zweiten Punkt.
Da die Tickets Kunden zugeordnet werden, gibt es für Kunden Anfragehistorien (inklusive interne Mitteilungen dazu). Sehr häufig reagieren Kunden fast schon befremdet, wenn das Unternehmen nach bestimmten Daten nachfragen muss, die in einem modernen CRM vorhanden sein sollten. Mit dem Ticketingsystem würde man sich diese Peinlichkeit ersparen, denn das Suchsystem ist deutlich ausgereifter als jenes eines E-Mailprogramms.
(4) Deadlines. Wenn eine Anfrage mit einem E-Mailprogramm beantwortet wird, dann wird sie bearbeitet, sobald Zeit dazu ist. Zeitkritische Anfragen können dabei zu spät bearbeitet werden. Das Ticketingsystem schafft hier Abhilfe, denn jeder eingehenden Anfrage kann ein Ablaufdatum zugeordnet werden. Wird nicht nur das Ablaufdatum, sondern auch ein Bearbeiter zugeordnet, wird dieser mit Erinnerungsmails an die nahende Deadline erinnert. Ein E-Mailprogramm macht das nicht.
(5) Statistiken. Natürlich könnte man sich, selbst im schwerfälligsten E-Mailprogramm, Statistiken ausgeben lassen. Das Ticketingsystem bringt sie aber von Haus aus mit. Wer hat wieviel wann bearbeitet. Wann ist das höchste Aufkommen, wann nicht? Wer hat die wenigsten Rückfragen, wer praktiziert erfolgreiches upselling? All diese Daten sind gegenwärtig inexistent.
Diese fünf Punkte habe ich der Geschäftsführung mitgeteilt. Sie sind, meiner Meinung nach, überzeugend genug, um die Qual des Mailschreibens endlich in produktives, zielgerichtetes und dem Stand der Dinge adäquates Arbeiten zu leiten. „Man kenne sich damit nicht aus und habe meine Argument per E-Mail an den IT-Verantwortlichen geschickt.“
Einspruch
Sehr zu meinem Erstaunen wurde gegen das von mir vorgeschlagene System Einspruch erhoben. Dabei ist es jedoch zu einer Verschiebung des Problems gekommen, denn während ich die Diskrepanz zwischen offensichtlicher Anforderung und von Outlook zur Verfügung gestellter Funktionalität kritisiert habe, wurde mein E-Mail als Kritik am Mailclient Outlook (und hier ganz besonders als Kritik an der Empfehlung, Outlook als E-Mailclient zu verwenden) verstanden. Auf den Vorschlag des Ticketingsystems wurde im sehr langen Antwortmail nur wenig eingegangen. Dafür gab es einen langen Rundumschlag zugunsten Outlook.
Ich hätte auf das E-Mail mit den Worten „Themenverfehlung. Setzen!“ antworten müssen, habe mich aber doch hinreissen lassen, auf die ewig gleichen Argumente die weig gleichen Antworten zu schreiben. Nein, wir brauchen kein Microsoft Exchange, ja, Outlook ist eh okay, aber nein, Outlook ist einfach viel zu überladen und die scheinbar bis heute nicht behobenen Probleme mit Standard-IMAP-Konten sind nicht Schuld alle anderen, sondern einfach ein gezieltes Vorgehen vom Hersteller des kostenpflichtigen Programms und des kostenpflichtigen Protokolls.
Wie nicht anders zu erwarten, folgte darauf ein nur noch am Thema „Warum Outlook ein guter Mailclient ist“ ausgerichtetes Antwortmail. Mühsam. Und zwar so mühsam (die Diskussion wird ja nun schon seit fast zehn Jahren geführt), dass ich meinen Vorschlag des Ticketingsystems zurückgezogen habe. Wenn mein ehrlich gemeinter Verbesserungsvorschlag argumentativ nicht angenommen wird und in Grabenkämpfen bezüglich des Mailclients endet, dann ist das ein Niveau, mit dem ich nichts zu tun haben will.
„Das ist eine emotionale Entscheidung!“
Obwohl das Thema für mich vom Tisch war, hatte ich vor wenigen Tagen ein aufschlussreiches Telefonat. Darin wurde mir in einer Rückblende auf die Diskussion zum Ticketingsystem erklärt, dass der Verlauf der oben geschilderten Diskussion „ganz normal“ sei und vor allem unter „jungen Männern“ üblich. In anderen Firmen wären es „Abteilungen, die gegeneinander agierten“, in dem Fall zwei Personen. Da sich aber die Vorgesetzten ohnehin nie auskannten, wäre es eine rein emotionale Sache, wie und ob ein Projekt umgesetzt werden würde.
Meine Antwort darauf bezog sich auf die zugewiesenen Kompetenzen und Wirkungsbereiche, die sich in diesem Fall nur marginal überschneiden: Outlook gehört definitiv zur internen IT, wird vom Betreuer gewartet und er ist die Person, die anzusprechen ist, wenn es Probleme gibt. Das Ticketingsystem, weil webbasierend, fällt in meinen Bereich. – Nein, das ist nicht so. Hier gibt es eine Überlappung. Denn mit der zukünftigen Bearbeitung von Anfragen mittels des Ticketingsystems ist auch der IT-Betreuer betroffen. – Ja, weil er weniger zu tun hat. – Nein, nicht weil er weniger zu tun hat. Verstehen Sie das bitte, im Endeffekt ist das keine Sachfrage mehr, sondern eine emotionale Entscheidung. – Emotional? Also die vorgebrachten Argumente sind sinnlos? – Nein, aber Emotion ist ein Argument. – Und von welchen Emotionen sprechen wir da? Schließlich hat ja der IT-Betreuer per se und mit dem Ticketingsystem noch viel mehr nichts mit den Anfragen zu tun. Das entlastet ihn ja sogar! Wie kann dann… Ach so, es geht also darum, dass etwas nicht gemacht wird, weil’s jemandem nicht in den Kram passt, ja? – Ja genau. Die Emotion ist ein Argument. Wenn es dem IT-Betreuer nicht passt, auch wenn er nichts damit zu tun hat, dann wird es nicht gemacht. – […!]
Darauf war ich nicht vorbereitet. Ich verstehe, wenn Entscheidungen derart basierend im familiären Umfeld getroffen werden. Oder unter Freunden. Aber in einem Unternehmen, das seit Jahren schon mit der Flut an Anfragen nicht zurechtkommt, weil die Softwareinfrastruktur nicht stimmt? Und seit Jahren verzweifelt nach Lösungen sucht? Da zählen solche „Emotionen“ gleichgesetzt als „Argumente“?
SSKM. Aber echt.