Lesezeit 5 Minuten
Abseits von ausgefeilter strategischer Ausrichtung, Prozessdesign und raffinierter Implementierung gibt es vier einfache Punkte, die den Anwendersupport in der Praxis sofort erfolgreich machen und eine positive UX gewährleisten … ja wirklich:
Gerade das Vermitteln von komplexen Inhalten stellt im Support immer wieder eine besondere Herausforderung dar – gilt es doch, eine zielgruppengerechte Ansprache zu finden und den Anwender einzubinden und abzuholen.
Schließlich macht es schon einen großen Unterschied, ob ich mich mit einem Azubi, digital native und mit social media aufgewachsen, unterhalte – oder mit der etwas älteren Dame aus der Buchhaltung, die mit diesem ganzen Computerkrams sowieso auf Kriegsfuß steht.
Im reinen Telefonsupport kommen zusätzliche Herausforderungen hinzu:
Da gibt es zuerst den kooperativen und folgsamen Anwender, der eben genau meinen telefonischen Anweisungen folgt – den etwas hektischen Anwender, hin und wieder zwei Klicks voraus, den man deshalb etwas einbremsen muss mit dem Hinweis, doch bitte genau meinen Anweisungen zu folgen.
Und dann gibt es noch den chaotischen Anwender, der überall panisch draufklickt und bei dem ein reiner telefonischer Support nicht mehr funktioniert. Hier geht dann nur noch Teamviewer und den Desktop übernehmen oder – wen möglich und besser – gleich persönlich vorbei schauen.
Grundsätzliche wichtige Eigenschaften im Support sind vor allem Coolnes und buddhistische Gelassenheit – und die Fähigkeit, auch deeskalierend einwirken zu können, um einen aufgebrachten Anwender sachlich aber bestimmt wieder auf den Teppich zu bringen – bis zu einem gewissen Punkt, Hanswurst lasse ich natürlich nicht mit mir machen.
Übrigens kann man auch hinter Corona Maske oder am Telefon ein Lächeln erkennen – an den Augen und der Stimme!
Werbung
Ein alter Hut – jedes Ticket, Störung oder Incident muss zuerst einmal klar und nach definierten Kriterien eingeordnet werden – und zwar nach Anzahl der betroffenen User [affected user] und nach Art der Störung [incident].
Ist jetzt z.B. ein major service wie etwa Email ausgefallen und alle User sind betroffen, so gilt Prio 1 – alle verfügbaren Kräfte die Füße hoch, evtl. externe Dienstleister hinzuziehen – und diesen Incident so schnell wie möglich beheben!
Handelt es sich aber um ein “Geister Incident” – selten und nur schwer oder gar nicht zu reproduzieren – und es sind auch nur 1 bis 3 User betroffen, so gilt Prio 4 und Ruhe bewahren – damit kann man sich dann beschäftigen, wenn Zeit ist und es nichts Weiteres zu tun gibt.
Eine klare Priorisierung eines Incident ist auch gegenüber dem Anwender leicht verständlich kommunizierbar – nicht der, der am lautesten schreit, kommt auch zuerst dran – fertig.
Werbung
Zum einen kann man mit entsprechend definierten Kennzahlen [z.B. Median anstatt Mittelwert!] den Service in der Vergangenheit qualitativ bewerten – zum anderen aber ermöglichen Kennzahlen auch einen Blick in die Zukunft.
Mit Daten aus der Vergangenheit lassen sich Trends erkennen und machen so einen proaktiven Service möglich, der nicht nur reagiert wenn es schon zu spät ist, sondern der technische Störungen prädiktiv schon im Vorfeld erkennt und behebt!
Zur Erhebung von Daten im Support muss es übrigens nicht immer ein monströses und völlig überdimensioniertes Ticketsystem sein. Dauert z.B. die Eingabe eines Tickets länger als das eigentliche Lösen des Incident, wird das auf nur wenig Gegenliebe bzw. Akzeptanz stossen.
Gerade in kleineren Unternehmen bietet sich hier die – vielfach verschmähte – Excel Tabelle an, allerdings mit sehr viel Sorgfalt und einer extra Portion Liebe gepflegt und bearbeitet.
Besser auf diesem Wege Daten erheben als nur auf Zuruf oder aus dem Bauch heraus zu reagieren.
Das Wichtigste zum Schluss – ok, auch wenn jeder echte ITler nur bei dem Wort schon mittelschweren bis schweren Hautausschlag bekommt: Dokumentation!
Aufbau und Pflege einer Wissensdatenbank mit viel Liebe und Hingabe ist von zentraler Bedeutung. So muss der Mitarbeiter im Support nicht immer wieder das Rad neu erfinden, sondern kann direkt auf geprüfte und erfolgreiche Lösungsansätze zurückgreifen!
Im Rahmen eines Self Service kann eine solche Knowledge Base, natürlich entsprechend aufbereitet, auch direkt für den Anwender zugänglich gemacht werden und so die Zahl der Tickets reduzieren.
Zusätzlich sollte man evtl. über einen regelmäßigen Newsletter aus der IT nachdenken, indem man von aktuellen Projektfortschritten oder Neuerungen in der IT berichtet – oder einfach nur interessante HowTows oder Security Sensibilisierung reinpackt.
So bleibt die IT sichtbar und wichtig für das Unternehmen.
So, ich hoffe das war nützliche Anregung für den Alltag und viel Spaß mit Euren Anwendern!
(übrigens unter Sysadmins eine böse Beschimpfung: “Du Anwender …!“)
Marcus
Werbung
Lesezeit 3 Minuten
„Do you see difficulties in every new opportunity or opportunities in every new difficulty?“
Besonders hohe Bedeutung für ein effizientes IT-Controlling spielen Key Performance Indicators und Service Level Agreements – die eben – wie der Name schon sagt – Leistungen und Services sichtbar, quantitativ fassbar und dadurch letztendlich bewertbar machen sollen.
Kurz zum Unterschied: KPIs kommen mehr intern zum Einsatz und bewerten z.B die Leistung des Service Desk oder die Performance eines Projekts, SLAs finden dagegen zumeist in der Bewertung der Leistung eines externen Dienstleisters ihren Einsatz und regeln darüber hinaus auch noch weitere Aspekte wie Definition von Art und Umfang der Serviceerbringung oder auch strategische Aspekte wie z.B. langfristig geplanter Ausbau der IT Infrastruktur.
So weit, so gut – doch jetzt zum eigentlichen Problem:
KPIs und SLAs sind zunächst einmal Indikatoren, die die Realität in Zahlen fassen – statistische Kenngrößen wie z.B. eben der Mittelwert, Prozentangaben oder absolute Zahlen.
Zahlen sind immer gut, gerade in der IT – Zahlen sind objektiv und unbestechlich – wir lieben Zahlen und wir glauben an Zahlen!
Aber stimmt das wirklich???
Werbung
Tasten wir uns an das Problem heran mit dem klassischen Beispiel über die Aussagekraft eines Mittelwertes:
Mit meiner linken Hand fasse ich in das Gefrierfach meines Kühlschranks mit -30 Grad, die Rechte lege ich auf eine Herdplatte mit 100 Grad – ergibt einen Mittelwert von 35 Grad [(100-30)/2], also alles in bester Ordnung!
Und so geht es in der Welt der IT mit diesen bunten KPIs und SLAs munter weiter.
Ein beliebtes Beispiel: ein externer Dienstleister garantiert eine mittlere Reaktionszeit von 1,5 Stunden und die monatliche Auswertung ergibt auch exakt diesen Wert – alles prima! Bei genauerer Betrachtung hat dieser Dienstleister aber in einigen Fällen schon nach 10 Minuten zurückgerufen, manchmal aber auch erst am nächsten Tag – Gefrierfach und Herdplatte eben.
Was ist hier passiert? Der absolute Mittelwert hat ohne ergänzende Angaben zur Range keinerlei Aussagekraft – oder man nimmt gleich den Median – alle Werte werden ihrer Ausprägung nach sortiert und der Median gibt dann den 50 Prozent Schnitt an.
Ein weiteres beliebtes Beispiel: da garantiert z.B. ein externer Dienstleister eine Serververfügbarkeit von 99 Prozent – wow, das sieht klasse aus!
Kurz den Taschenrechner bemüht ergibt das aber einen Ausfall von 87.6 Stunden über das ganze Jahr gerechnet [(365×24)x0,01] und sieht – so betrachtet – nun nicht mehr wirklich toll aus – für einen Webshopbetreiber völlig inakzeptabel.
Was ist hier passiert? Nun, der Indikator und die Messgröße wurden falsch gewählt! Nicht die garantierte Laufzeit, sondern die maximale Ausfallzeit ist entscheidend – und dann bitte in Stunden oder Tagen und nicht in Prozent – glatter Fall von Augenwischerei.
Alarm im Service Desk! Die Anzahl ungelöster Tickets im System ist in der letzten Woche rasant angestiegen! Doch bei genauerer Betrachtung ergibt sich: alles nur völlig unwichtige Prio 4 Tickets – also Incidents, die niemanden wirklich stören oder von der Arbeit abhalten – halt nur etwas nervig.
Was ist hier passiert? Selbst absolute – scheinbar objektive – Zahlenwerte müssen stets hinterfragt und mit zusätzlichen qualitativen Informationen hinterlegt und untermauert werden, bevor es zu einer Bewertung der Situation kommen kann.
Ganz einfach: genau hinsehen, hinterfragen, nochmals hinterfragen:
“Was sagt mir diese Kennzahl jetzt genau?”
Und vor allem einen anderen Blickwinkel einnehmen – und schon gar nicht an Zahlen glauben!
Werbung
Lesezeit 4 Minuten
Werbung
„Never change a running system“- so lautet eine der goldenen Grundregeln in der IT und heißt auf Deutsch: Finger weg von einem sauber und rund laufenden System! So lässt sich auch erklären, dass in der Finanzbranche doch tatsächlich noch viele uralte Systeme laufen, die in der Jahrhunderte alten Programmiersprache COBOL und in Keilschrift umgesetzt wurden.
Doch die Realität sieht anders aus, aus verschiedenen Gründen muss oftmals ein stabil und rund laufendes System angefasst werden. Da gibt es z.B. Updates für das Betriebssystem, die kritische Sicherheitslücken schließen, oder aber Softwareupdates, die die Stabilität dieser Software erhöhen und neue Funktionalität mit sich bringen – oder aber der Support durch den Hersteller läuft aus.
Für großen Wirbel und manchmal auch blinden Aktionismus hat hier z.B. das Ende des Supports für Win 7 durch Microsoft gesorgt – dessen ungeachtet läuft übrigens auf den meisten Behördenrechnern diese Sicherheitslücke Win 7 noch immer völlig ungestört weiter.
Ist jetzt der endgültige Zeitpunkt gekommen und ein Update steht unweigerlich und hartnäckig vor der Tür, so bedarf dies zuerst buddhistischer Gelassenheit und weiter umfassender und sorgsamer Konzeption, Planung und Umsetzung – Patchmanagement eben!
Oberstes Gebot im eben beschriebenen Patchmanagement lautet jetzt: Testen, Testen und nochmals Testen! Updates sollten dabei aber nicht nur in einer kontrollierten und definierten Laborumgebung getestet werden – kann man machen, hat aber nur wenig Aussagekraft.
Vielmehr müssen solche Test auf eine breite Basis gestellt werden und dazu müssen Testuser herangezogen werden – aus möglichst unterschiedlichen Abteilungen mit unterschiedlicher Rechnerkonfiguration und Softwareausstattung. So kann man vielleicht schon im Vorfeld feststellen, dass die Finanz- und Buchhaltungssoftware das Betriebssystemupdate nicht so richtig mag, die ganze Sache schon im Vorfeld analysieren und zumindest einen Workaround dafür entwickeln, ohne gleich die gesamte Buchhaltung außer Gefecht zu setzen.
Ach ja, zusätzlich zu der ganzen Vorbereitung, Planen und Testen sollte man vielleicht auch noch einen netten wöchentlichen Newsletter an alle User raushauen und grob über das Vorhaben und den aktuellen Stand der Dinge informieren.
Und spätestens jetzt braucht das Projekt einen richtig knackigen Namen – sowas wie „the next Generation IT“ oder etwas kürzer „thenextGenIT“.
Überhaupt sollte man mal über eine solche proaktive Kommunikationspolitik und regelmäßigen Kontakt mit dem Kunden nachdenken – eben über einen solchen wöchentlichen Newsletter aus der IT!
Und gibt es mal nichts Konkretes zu berichten, so nutzt man den Newsletter zur Userschulung und packt coole LifeHacks rund um Windows, Office oder sonst was rein.
Werbung
Doch zurück zum eigentlichen Thema:
Zusätzlich kannst du mit sehr hoher Wahrscheinlichkeit davon ausgehen, dass es in der hintersten Ecke deines Netzwerks unter Garantie noch eine Software gibt – selbstgeschrieben und uralt, wird auch nur noch von drei Usern benutz, ist aber unglaublich wichtig! – die den Patch ebenso nicht mag und die man trotz genauester Planung einfach übersehen hat – ja wirklich, garantiert!
Zielführend ist es jetzt, ein bereits getestetes PowerShell Script in der Hinterhand zu haben, was den Patch erst mal vollständig von der Platte putzt und den vorherigen Zustand wieder herstellt. So läuft Alles erst mal wieder und man kann sich in Ruhe weitere Gedanken dazu machen.
Werbung
Das Wichtigste zum Schluss – ok, schon allein das Wort Dokumentation sorgt bei echten ITlern für mittelschweren bis schweren Hautausschlag, bedeutet aber doch nichts weiteres, als festzuhalten, was man gemacht hat und was dabei herausgekommen ist – sehr hilfreich und wichtig für den Überblick – ohne Zweifel!
Völlig verstreute Dokumentation über Ticketsysteme und Excel Tabellen hinweg ist dabei jetzt nicht nur nervig und zeitraubend, eben dieser Überblick kommt dabei nicht zustande. Jetzt muss man aber pragmatisch bleiben und nicht gleich das Rad neu erfinden bzw. eine völlig neue Dokumentation aufbauen.
Vielmehr reicht es oft, die eingesetzten Tools zur Dokumentation nach definierten Kriterien zu analysieren und sich darauf aufbauend für ein bereits vorhandenes Tool zu entscheiden, was zukünftig hauptsächlich genutzt werden soll.
So kann sich z.B. das Ticketsystem als pragmatischste Lösung herausstellen, weil hier zusätzlich Tickets und Reports mit Dokumentation verknüpft werden können oder umgekehrt, was die Aussagekraft der Dokumentation weiter erhöht.
Jetzt nur noch alle alten Excel Tapeten mit dem Ticketsystem verknüpfen oder gleich übertragen – et voilà le travail!
So, ich hoffe das war nützliche Anregung für euer Projekt und viel Spaß mit Euren Anwendern!
(übrigens unter Sysadmins eine böse Beschimpfung: “Du Anwender …!”)
Meinungen oder auch vernichtende Kritik gerne erwünscht!
Markus
weiter mit: