# 3. Service Desk, Support und operative Servicearbeit # 3.1 Der Service Desk als zentraler Kontaktpunkt > **Kurz erklärt** > > Der Service Desk stellt einen zentralen Kontakt- und Kommunikationspunkt zwischen dem Service Provider und seinen Benutzern bereit. > > Er nimmt unter anderem: > > - Störungsmeldungen, > - Service Requests, > - Fragen, > - Rückmeldungen, > - Beschwerden, > - und Informationsbedarf > > entgegen. > > Der Service Desk muss nicht jedes technische Problem selbst lösen. > > Er sorgt jedoch dafür, dass Kontakte: > > - verstanden, > - vollständig erfasst, > - fachlich eingeordnet, > - angemessen priorisiert, > - an die richtige Stelle weitergeleitet, > - nachvollziehbar koordiniert, > - und verständlich kommuniziert > > werden. > > Damit verbindet der Service Desk Benutzer, technische Teams, Management Practices, Lieferanten und Wertströme. --- **Warum ein zentraler Kontaktpunkt notwendig ist** Benutzer benötigen einen verständlichen und verlässlichen Weg, um: - eine Störung zu melden, - eine Leistung anzufordern, - eine Frage zu stellen, - Informationen zu erhalten, - oder eine Rückmeldung zu einem Service zu geben. Ohne einen klaren Kontaktpunkt entstehen häufig mehrere parallele Meldewege. Beispiele: - Ein Benutzer ruft einen bekannten Administrator direkt an. - Ein anderer Benutzer schreibt eine private Chatnachricht. - Eine Führungskraft sendet eine E-Mail an die IT-Leitung. - Eine Störung wird in einer allgemeinen Gruppe erwähnt. - Ein Mitarbeiter spricht einen Techniker auf dem Flur an. - Eine Fachabteilung meldet denselben Ausfall bei mehreren Teams. - Ein externer Dienstleister erhält eine Meldung, ohne dass die interne IT informiert wurde. Dadurch können folgende Probleme entstehen: - Meldungen gehen verloren. - dieselbe Störung wird mehrfach bearbeitet. - Informationen befinden sich in verschiedenen Systemen. - Prioritäten werden nach persönlicher Nähe oder Lautstärke vergeben. - niemand besitzt einen vollständigen Überblick. - Benutzer erhalten widersprüchliche Aussagen. - technische Teams werden unkoordiniert unterbrochen. - Bearbeitung und Entscheidungen sind später nicht nachvollziehbar. - wiederkehrende Muster werden nicht erkannt. - Servicequalität kann nicht zuverlässig ausgewertet werden. > **Merke** > > Ein zentraler Kontaktpunkt bedeutet nicht zwingend nur einen technischen Kommunikationskanal. > > Es bedeutet, dass Benutzerkontakte kontrolliert zusammengeführt und nachvollziehbar bearbeitet werden. --- **Der Service Desk als Verbindung zwischen Benutzern und Service Provider** Benutzer kennen häufig nicht: - die technische Architektur, - die zuständige Supportgruppe, - den beteiligten Lieferanten, - die interne Practice, - oder die Ursache einer Störung. Sie sollten deshalb nicht selbst entscheiden müssen, ob ein Problem zum: - Netzwerkteam, - Serverteam, - Anwendungsteam, - Identitätsmanagement, - Cloud-Provider, - Informationssicherheitsteam, - oder Softwarehersteller gehört. Der Service Desk unterstützt bei dieser Einordnung. Beispiel: Ein Benutzer meldet: > Ich kann mich nicht mehr anmelden. Mögliche Ursachen sind unter anderem: - falsches Kennwort, - gesperrtes Benutzerkonto, - fehlerhafte Netzwerkverbindung, - nicht erreichbarer Verzeichnisdienst, - gestörte Multi-Faktor-Authentifizierung, - abgelaufenes Zertifikat, - fehlerhafte Zeitsynchronisation, - deaktivierte Lizenz, - oder eine allgemeine Störung des Identitätsdienstes. Der Benutzer muss diese Ursache nicht vor der Meldung bestimmen. Der Service Desk erfasst zunächst: - wer betroffen ist, - welcher Service benötigt wird, - welches Symptom besteht, - seit wann es besteht, - welche Auswirkungen entstehen, - und welche Informationen für die weitere Bearbeitung benötigt werden. > **Grundsatz** > > Benutzer beschreiben ihre Beobachtung und ihre Beeinträchtigung. > > Die fachliche Einordnung ist Aufgabe der Serviceorganisation. --- **Der Service Desk ist mehr als eine Telefonzentrale** Ein Service Desk darf nicht auf das reine: - Annehmen, - Erstellen, - und Weiterleiten von Tickets reduziert werden. Eine wirksame Service-Desk-Practice kann unter anderem beitragen zu: - verständlicher Kommunikation, - strukturierter Erfassung, - richtiger Einordnung von Kontakten, - erster Diagnose, - direkter Lösung geeigneter Anliegen, - Koordination von Bearbeitung, - Benutzerinformation, - Eskalation, - Wissensnutzung, - Erkennung wiederkehrender Probleme, - Verbesserung von Services, - und einer positiven Benutzererfahrung. > **Typischer Fehler** > > Der Service Desk wird nur danach bewertet, wie schnell ein Kontakt beendet oder ein Ticket weitergeleitet wird. > > Dadurch kann die lokale Bearbeitungszeit sinken, während Übergaben, Rückfragen und die gesamte Lösungsdauer steigen. --- **Service Desk als Practice, Team und Kontaktpunkt unterscheiden** Der Begriff Service Desk kann in der Praxis unterschiedliche Ebenen beschreiben. | Betrachtung | Bedeutung | |---|---| | **Service-Desk-Practice** | organisatorische Fähigkeiten und Ressourcen für Kontakt, Kommunikation und Benutzerunterstützung | | **Service-Desk-Team** | Mitarbeiter, die einen wesentlichen Teil dieser Aufgaben ausführen | | **Service-Desk-Funktion** | organisatorische Einheit mit festgelegten Aufgaben und Verantwortlichkeiten | | **Kontaktpunkt** | Zugangsmöglichkeit für Benutzer zum Service Provider | | **Service-Desk-Werkzeug** | technische Unterstützung für Kontakte, Tickets, Wissen und Kommunikation | | **Supportkanal** | Telefon, Portal, E-Mail, Chat, persönlicher Kontakt oder anderer Zugangsweg | Diese Ebenen sind miteinander verbunden, aber nicht identisch. Ein Ticketsystem ist nicht der Service Desk. Ein Service-Desk-Team ist nicht automatisch für jede technische Lösung verantwortlich. Ein Portal ist nur einer von mehreren möglichen Kontaktkanälen. --- **Zweck des Service Desk** Der Service Desk unterstützt insbesondere dabei: - Kontakte zwischen Benutzern und Service Provider zu ermöglichen, - Nachfrage nach Incident-Lösung und Service Requests aufzunehmen, - Benutzer verständlich zu informieren, - Anliegen an geeignete Wertströme und Practices zu übergeben, - und die Benutzererfahrung während der Bearbeitung zu unterstützen. Der Service Desk kann zusätzlich: - erste Diagnosen durchführen, - bekannte Lösungen anwenden, - standardisierte Leistungen bereitstellen, - Wissen erfassen, - Statusinformationen kommunizieren, - Feedback aufnehmen, - und Verbesserungsmöglichkeiten erkennen. > **Wichtig** > > Der konkrete Umfang wird von der jeweiligen Organisation festgelegt. > > ITIL schreibt nicht vor, dass jeder Service Desk dieselben Aufgaben, Kanäle, Servicezeiten oder technischen Befugnisse besitzen muss. --- **Der Service Desk als Teil mehrerer Wertströme** Der Service Desk ist nicht ausschließlich Teil des Incident-Management-Wertstroms. Er kann an verschiedenen Wertströmen beteiligt sein. | Wertstrom | Möglicher Beitrag des Service Desk | |---|---| | Benutzer nach einer Störung wieder arbeitsfähig machen | Meldung aufnehmen, erste Diagnose durchführen, informieren und koordinieren | | genehmigte Standardsoftware bereitstellen | Service Request erfassen, Status kommunizieren und Ergebnis bestätigen | | neuen Mitarbeiter arbeitsfähig machen | Fragen beantworten, Übergabe unterstützen und Probleme behandeln | | Zugriff bereitstellen | Anfrage erfassen, notwendige Angaben prüfen und Status kommunizieren | | Benutzer über geplante Wartung informieren | zielgruppengerechte Kommunikation bereitstellen | | wiederkehrendes Problem reduzieren | Muster erkennen und an Problem Management weitergeben | | Service verbessern | Benutzerfeedback und Kontaktdaten auswerten | | Sicherheitsvorfall behandeln | Meldung erkennen, sicher eskalieren und vorgegebene Kommunikation verwenden | Der Service Desk ist damit häufig ein Knotenpunkt zwischen: - Benutzern, - Incident Management, - Service Request Management, - Problem Management, - Knowledge Management, - Monitoring and Event Management, - Service Level Management, - Relationship Management, - Information Security Management, - Supplier Management, - und Continual Improvement. --- **Service Desk und Incident Management unterscheiden** | Service Desk | Incident Management | |---|---| | stellt Kontakt und Kommunikation mit Benutzern bereit | behandelt negative Auswirkungen von Incidents | | nimmt unterschiedliche Kontaktarten entgegen | konzentriert sich auf Wiederherstellung des Service | | kann Incidents erfassen und erste Diagnose durchführen | koordiniert Diagnose, Eskalation und Wiederherstellung | | kann Service Requests, Fragen und Feedback bearbeiten | behandelt nicht automatisch jede Benutzeranfrage | | kann als Team oder organisatorische Funktion umgesetzt sein | ist eine organisationsweite Management Practice | | unterstützt mehrere Wertströme | unterstützt insbesondere Incident-bezogene Wertströme | Ein Service-Desk-Mitarbeiter kann Tätigkeiten des Incident Managements ausführen. Der Service Desk ist jedoch nicht mit der vollständigen Incident-Management-Practice identisch. Bei einem komplexen Incident können zusätzlich beteiligt sein: - technische Spezialisten, - Service Owner, - Incident-Koordination, - Lieferanten, - Informationssicherheit, - und Führungskräfte. --- **Service Desk und Service Request Management unterscheiden** | Service Desk | Service Request Management | |---|---| | stellt Kontakt und Kommunikation bereit | steuert die Erfüllung vereinbarter Benutzeranfragen | | nimmt einen Request möglicherweise entgegen | ordnet den Request einem geeigneten Request-Modell zu | | unterstützt bei Rückfragen und Statusinformationen | koordiniert Genehmigung, Erfüllung und Abschluss | | kann einfache Requests direkt erfüllen | kann weitere Teams und Automatisierungen einbeziehen | | bearbeitet auch Incidents, Fragen und Feedback | konzentriert sich auf vorgesehene Service Requests | Beispiel: Ein Benutzer benötigt eine freigegebene Standardsoftware. Der Service Desk kann: - den Bedarf aufnehmen, - das passende Serviceangebot auswählen, - notwendige Angaben prüfen, - und den Status kommunizieren. Service Request Management kann anschließend: - eine erforderliche Genehmigung einholen, - eine Lizenz prüfen, - die automatisierte Installation auslösen, - das Ergebnis kontrollieren, - und Asset-Informationen aktualisieren. --- **Service Desk und Helpdesk unterscheiden** Die Begriffe werden in Organisationen unterschiedlich verwendet. Häufig wird vereinfacht unterschieden: | Helpdesk | Service Desk | |---|---| | stärker auf technische Hilfe und Störungsbehebung ausgerichtet | breiter auf Servicebeziehungen, Kommunikation und Unterstützung ausgerichtet | | häufig reaktiver Fokus | kann reaktive und proaktive Aufgaben umfassen | | möglicherweise stärker komponentenorientiert | möglichst service- und benutzerorientiert | | häufig enger Aufgabenbereich | kann mehrere Practices und Wertströme verbinden | Diese Unterscheidung ist nicht in jeder Organisation identisch. Ein intern als Helpdesk bezeichnetes Team kann praktisch alle Aufgaben eines modernen Service Desk erfüllen. > **Merke** > > Die Bezeichnung allein entscheidet nicht über die Qualität oder den tatsächlichen Aufgabenbereich. --- **Service Desk und technische Supportgruppen unterscheiden** Technische Supportgruppen besitzen häufig vertieftes Fachwissen. Beispiele: - Netzwerkteam, - Serverteam, - Datenbankteam, - Anwendungssupport, - Workplace-Team, - Cloud-Team, - Identitätsmanagement, - Informationssicherheit, - und externer Herstellersupport. Der Service Desk besitzt dagegen häufig eine breitere Sicht auf: - Benutzer, - Services, - bekannte Lösungen, - Kontaktwege, - Statuskommunikation, - Priorisierung, - und den gesamten Bearbeitungsstand. Ein Anliegen kann an eine technische Supportgruppe übergeben werden. Trotzdem sollte geklärt bleiben: - Wer besitzt den Vorgang? - Wer kommuniziert mit dem Benutzer? - Welche Informationen werden übergeben? - Wer überwacht den Fortschritt? - Wer bestätigt die Wiederherstellung? - Wer schließt den Vorgang ab? > **Typischer Fehler** > > Nach der technischen Weiterleitung fühlt sich niemand mehr für die Ende-zu-Ende-Kommunikation und das Benutzerergebnis verantwortlich. --- **Support-Level sind keine zwingende ITIL-Struktur** Viele Organisationen verwenden Bezeichnungen wie: - First-Level Support, - Second-Level Support, - Third-Level Support, - Tier 1, - Tier 2, - oder Tier 3. Eine mögliche Einteilung ist: | Ebene | Möglicher Schwerpunkt | |---|---| | **First Level** | Kontakt, Erfassung, erste Diagnose und bekannte Lösungen | | **Second Level** | vertieftes technisches oder fachliches Wissen | | **Third Level** | hochspezialisierte interne Experten, Entwicklung oder Hersteller | Diese Struktur kann hilfreich sein. Sie ist jedoch keine zwingend vorgeschriebene ITIL-Organisationsform. Mögliche Nachteile einer starren Level-Struktur: - viele Übergaben, - wiederholte Rückfragen, - lange Warteschlangen, - Verantwortungsverschiebung, - und Verlust von Kontext. Alternative oder ergänzende Modelle sind beispielsweise: - funktionsübergreifende Teams, - Swarming, - direkte Zusammenarbeit, - Produktteams mit Ende-zu-Ende-Verantwortung, - oder automatisierte Standarderfüllung. --- **Swarming als mögliche Arbeitsweise** Beim Swarming wird ein komplexer Vorgang nicht nur linear von Supportstufe zu Supportstufe weitergereicht. Stattdessen werden geeignete Fachkräfte frühzeitig zur gemeinsamen Bearbeitung einbezogen. Mögliche Vorteile: - weniger Übergaben, - schnellerer Wissensaustausch, - Erhalt des ursprünglichen Kontexts, - bessere Zusammenarbeit, - und schnellere Entwicklung neuer Fähigkeiten. Mögliche Voraussetzungen: - sichtbare Informationen, - geeignete Kommunikationswerkzeuge, - klare Koordination, - ausreichende Verfügbarkeit von Fachkräften, - und nachvollziehbare Verantwortung. Swarming ist eine mögliche Praxisempfehlung und keine für jede Organisation vorgeschriebene ITIL-Struktur. --- **Mögliche Organisationsmodelle** Ein Service Desk kann unterschiedlich organisiert werden. --- **Zentraler Service Desk** Ein gemeinsames Team unterstützt mehrere Standorte oder Bereiche. Mögliche Vorteile: - einheitliche Arbeitsweise, - zentrale Übersicht, - gemeinsame Wissensbasis, - und besser bündelbare Kapazität. Mögliche Herausforderungen: - geringere Nähe zu lokalen Besonderheiten, - Sprach- oder Zeitzonenunterschiede, - und fehlendes Wissen über einzelne Standorte. --- **Lokaler Service Desk** Support befindet sich nahe bei Benutzern oder Standorten. Mögliche Vorteile: - Kenntnis lokaler Arbeitsabläufe, - persönliche Erreichbarkeit, - und Unterstützung vor Ort. Mögliche Herausforderungen: - unterschiedliche Arbeitsweisen, - Wissenssilos, - schwankende Auslastung, - und uneinheitliche Servicequalität. --- **Virtueller Service Desk** Mitarbeiter arbeiten verteilt, erscheinen für Benutzer aber als gemeinsamer Service Desk. Mögliche Vorteile: - ortsunabhängige Zusammenarbeit, - flexiblere Kapazitätsverteilung, - und gemeinsame Bearbeitung. Mögliche Herausforderungen: - technische Abhängigkeit von Kommunikationswerkzeugen, - Koordinationsbedarf, - und mögliche Informationsverluste. --- **Follow-the-Sun-Modell** Mehrere Service-Desk-Standorte in verschiedenen Zeitzonen übernehmen nacheinander die Bearbeitung. Mögliche Vorteile: - längere oder durchgehende Servicezeiten, - bessere Verteilung internationaler Nachfrage. Mögliche Herausforderungen: - Übergaben zwischen Zeitzonen, - Sprach- und Kulturunterschiede, - unterschiedliche Zugriffsrechte, - und notwendige einheitliche Dokumentation. --- **Spezialisierter Service Desk** Ein Service Desk ist auf bestimmte: - Produkte, - Services, - Kunden, - Benutzergruppen, - oder Branchen ausgerichtet. Möglicher Vorteil: - tieferes Fach- und Kontextwissen. Mögliche Herausforderung: - mehrere Kontaktpunkte und unklare Zuständigkeiten für Benutzer. --- **Kontaktkanäle** Ein Service Desk kann über mehrere Kanäle erreichbar sein. | Kanal | Geeignet für | Mögliche Herausforderung | |---|---|---| | **Self-Service-Portal** | strukturierte Incidents und Requests | Benutzer müssen das passende Angebot finden | | **Telefon** | dringende oder erklärungsbedürftige Situationen | Dokumentation muss während oder nach dem Gespräch erfolgen | | **E-Mail** | weniger dringende und schriftlich beschreibbare Anliegen | häufig unvollständige oder unstrukturierte Angaben | | **Chat** | schnelle Rückfragen und direkte Kommunikation | Gesprächskontext muss im Vorgang gesichert werden | | **virtueller Agent** | häufige Fragen und standardisierte Anliegen | Fehlinterpretation und unzureichende Eskalation möglich | | **persönlicher Kontakt** | Vor-Ort-Unterstützung und komplexe Kommunikation | Meldungen dürfen nicht außerhalb der Nachverfolgung bleiben | | **Mobile App** | Meldungen und Status unterwegs | Sicherheit und Bedienbarkeit müssen berücksichtigt werden | | **technische Integration** | automatische Erfassung aus anderen Systemen | nicht jede technische Meldung ist ein Benutzerkontakt oder Incident | Die Organisation sollte für jeden Kanal klären: - welche Anliegen geeignet sind, - welche Servicezeiten gelten, - welche Informationen benötigt werden, - wie Authentifizierung erfolgt, - wie Kontakte dokumentiert werden, - und wie bei kritischen Situationen eskaliert wird. --- **Mehrere Kanäle, aber ein gemeinsamer Überblick** Ein Benutzer kann möglicherweise: - anrufen, - eine E-Mail senden, - einen Chat beginnen, - oder ein Portal verwenden. Trotzdem sollten relevante Informationen möglichst in einer gemeinsamen Vorgangs- und Kommunikationssicht zusammengeführt werden. Andernfalls entstehen: - doppelte Tickets, - widersprüchliche Statusinformationen, - fehlender Kontext, - und unnötige Rückfragen. > **Praxistipp** > > Die Anzahl der Kontaktkanäle sollte nicht größer sein als die Fähigkeit der Organisation, diese zuverlässig zu überwachen, zusammenzuführen und zu bearbeiten. --- **Der geeignete Kanal hängt von der Situation ab** Nicht jedes Anliegen eignet sich für jeden Kanal. Beispiele: | Situation | Möglicherweise geeigneter Kanal | |---|---| | allgemeine Standardsoftware bestellen | Self-Service-Portal | | kritischer Ausfall eines wichtigen Service | Telefon oder definierter Major-Incident-Meldeweg | | einfache Statusabfrage | Portal, Chatbot oder automatische Nachricht | | möglicher Sicherheitsvorfall | besonders geschützter und bekannter Meldeweg | | komplexes Problem mit vielen Rückfragen | Telefon, Chat oder gemeinsamer Termin | | Feedback zu einem Service | Portal, Umfrage oder persönlicher Kontakt | | Kennwort vergessen | sicherer Self-Service oder verifizierter Supportkontakt | Die Organisation legt die tatsächlichen Kanäle und Regeln fest. --- **Erreichbarkeit und Servicezeiten** Der Service Desk muss nicht automatisch rund um die Uhr besetzt sein. Mögliche Modelle: - Geschäftszeiten, - erweiterte Servicezeiten, - Bereitschaft außerhalb der Geschäftszeiten, - 24×7-Betrieb, - unterschiedliche Zeiten je Service oder Benutzergruppe, - oder Kombination aus menschlichem Support und Self-Service. Zu klären ist: - Welche Services sind außerhalb der normalen Arbeitszeit kritisch? - Welche Benutzer benötigen Unterstützung? - Welche Incidents müssen sofort behandelt werden? - Welche Kontaktwege gelten außerhalb der Servicezeit? - Wer übernimmt Bereitschaft? - Welche Lieferanten sind erreichbar? - Welche Entscheidungen dürfen getroffen werden? - Wie werden Übergaben am nächsten Arbeitstag durchgeführt? > **Wichtig** > > Servicezeiten des Service Desk, Supportzeiten eines Service und technische Betriebszeiten können unterschiedlich sein. --- **Service Desk als Kommunikationszentrum** Der Service Desk besitzt häufig eine wichtige Rolle bei der Kommunikation. Dazu gehören: - Eingangsbestätigung, - Rückfragen, - Statusinformationen, - erwartete nächste Schritte, - bekannte Zwischenlösungen, - Hinweise zu geplanten Wartungen, - Informationen bei Störungen, - und Abschlusskommunikation. Gute Kommunikation sollte möglichst sein: - verständlich, - korrekt, - zielgruppengerecht, - handlungsorientiert, - zeitnah, - konsistent, - und ehrlich. Ungeeignete Statusmeldung: > Der Incident befindet sich beim Second Level. Bessere Statusmeldung: > Das Netzwerkteam untersucht derzeit die Verbindung zum zentralen Dateiservice. Eine nächste Statusmeldung erfolgt spätestens um 14:30 Uhr. Sie müssen aktuell nichts weiter unternehmen. --- **Keine unbelegten Zusagen machen** Ein Service-Desk-Mitarbeiter sollte keine Wiederherstellungszeit versprechen, wenn diese nicht ausreichend belegt ist. Ungeeignet: > Das funktioniert in zehn Minuten wieder. Besser: > Das zuständige Team untersucht die Störung. Eine verlässliche Wiederherstellungszeit liegt noch nicht vor. Die nächste Aktualisierung erfolgt um 11:00 Uhr. > **Merke** > > Ein angekündigter Zeitpunkt für die nächste Information ist häufig zuverlässiger als eine unbelegte Schätzung der vollständigen Lösung. --- **Empathie und professioneller Umgang** Benutzer melden nicht nur einen technischen Fehler. Sie erleben möglicherweise: - Arbeitsunterbrechung, - Zeitdruck, - Unsicherheit, - Frustration, - drohenden Datenverlust, - oder Auswirkungen auf Kunden und Kollegen. Professioneller Umgang bedeutet: - zuhören, - nicht vorschnell unterbrechen, - Auswirkungen verstehen, - verständlich kommunizieren, - keine Schuldzuweisungen vornehmen, - und das Anliegen ernst nehmen. Empathie bedeutet nicht: - jede Forderung ungeprüft zu erfüllen, - jede subjektive Dringlichkeit als höchste Priorität einzustufen, - oder Sicherheitsvorgaben zu umgehen. Beispiel: > Ich verstehe, dass Sie die Datei für den heutigen Kundentermin benötigen. Ich prüfe jetzt, ob nur diese Datei oder der gesamte Dateiservice betroffen ist, und informiere Sie über den nächsten Schritt. --- **Geschäfts- und Benutzerkontext verstehen** Technisches Wissen allein reicht für guten Service-Desk-Support nicht aus. Hilfreich ist auch das Verständnis: - welche Aufgaben Benutzer ausführen, - welche Services dafür benötigt werden, - welche Zeitpunkte besonders kritisch sind, - welche Begriffe die Fachabteilung verwendet, - und welche Auswirkungen eine Störung besitzt. Beispiel: Der Ausfall eines Etikettendruckers kann technisch wie ein einzelnes Geräteproblem wirken. In einem Lager kann er jedoch: - den Versand stoppen, - Liefertermine gefährden, - und mehrere nachgelagerte Prozesse blockieren. > **Praxistipp** > > Service-Desk-Mitarbeiter sollten wichtige Arbeitsbereiche und deren Abhängigkeit von digitalen Services kennenlernen. --- **Erste Diagnose** Der Service Desk kann eine erste strukturierte Diagnose durchführen. Mögliche Ziele: - Situation verstehen, - betroffenen Service bestimmen, - Umfang der Auswirkung feststellen, - bekannte Lösung finden, - benötigte Informationen sammeln, - und eine unnötige Weiterleitung vermeiden. Mögliche Fragen: - Was wollten Sie durchführen? - Was ist stattdessen geschehen? - Welche Fehlermeldung wird angezeigt? - Seit wann besteht die Störung? - Hat die Funktion vorher gearbeitet? - Sind weitere Benutzer betroffen? - Funktionieren andere Services? - Wurde kürzlich etwas verändert? - Welche Schritte wurden bereits versucht? - Besteht eine geeignete Zwischenlösung? - Können Screenshots oder Protokolle sicher bereitgestellt werden? Die Diagnose darf nicht zu einer unstrukturierten Liste beliebiger Versuche werden. Jede Maßnahme sollte: - einen erkennbaren Zweck besitzen, - zum Risiko passen, - dokumentiert werden, - und hinsichtlich ihres Ergebnisses geprüft werden. --- **First Contact Resolution** First Contact Resolution beschreibt, dass ein Anliegen während des ersten Kontakts ausreichend gelöst oder erfüllt wird. Mögliche Vorteile: - schnellere Wiederherstellung, - weniger Übergaben, - geringerer Benutzeraufwand, - und bessere Erfahrung. First Contact Resolution darf jedoch nicht durch ungeeignete Maßnahmen künstlich erhöht werden. Ungeeignet sind beispielsweise: - Ticket ohne bestätigte Lösung schließen, - Benutzer mit einer ungetesteten Anleitung abweisen, - Sicherheitskontrollen umgehen, - oder komplexe Probleme nur oberflächlich behandeln. > **Merke** > > Eine Lösung beim ersten Kontakt ist nur dann wertvoll, wenn sie korrekt, sicher und aus Benutzersicht wirksam ist. --- **Shift Left** Shift Left beschreibt die Verlagerung geeigneten Wissens und geeigneter Fähigkeiten näher zum Benutzer oder zu früheren Supportstufen. Beispiele: - bessere Self-Service-Anleitungen, - Wissensartikel für den Service Desk, - sichere Kennwort-Selbstverwaltung, - automatisierte Standardbereitstellung, - Diagnoseinformationen direkt im Ticket, - und Schulung von Service-Desk-Mitarbeitern. Mögliche Vorteile: - schnellere Lösung, - weniger Übergaben, - Entlastung spezialisierter Teams, - und bessere Skalierbarkeit. Shift Left darf nicht bedeuten: - Verantwortung ohne Befugnisse zu verlagern, - komplexe Aufgaben ungeschulten Mitarbeitern zu übertragen, - oder Risiken nur aus Kostengründen zu verschieben. --- **Funktionale Eskalation** Eine funktionale Eskalation erfolgt, wenn zusätzliche: - Fähigkeiten, - technische Berechtigungen, - Informationen, - Werkzeuge, - oder Lieferantenunterstützung benötigt werden. Beispiele: - Netzwerkfehler an das Netzwerkteam, - Datenbankproblem an den Datenbankadministrator, - Softwarefehler an den Hersteller, - Sicherheitsverdacht an das zuständige Sicherheitsteam. Eine gute funktionale Eskalation enthält: - verständliche Problembeschreibung, - betroffenen Service, - Auswirkungen, - bisherige Diagnose, - Testergebnisse, - relevante Fehlermeldungen, - durchgeführte Maßnahmen, - und erwarteten nächsten Schritt. Ungeeignet: > Geht nicht. Bitte prüfen. Besser: > Seit 09:20 Uhr können zwölf Benutzer am Standort Nord keine Verbindung zum zentralen Dateiservice herstellen. Lokale Netzwerkverbindung und DNS-Auflösung funktionieren. Der Verbindungsversuch zum TCP-Port des Dateiservice schlägt fehl. Andere Standorte sind nicht betroffen. Benötigt wird die Prüfung der Standortverbindung und der Firewall-Regeln. --- **Hierarchische Eskalation** Eine hierarchische Eskalation kann notwendig sein, wenn: - Auswirkungen erheblich sind, - Zielzeiten gefährdet werden, - Ressourcen fehlen, - Verantwortlichkeiten unklar sind, - eine Entscheidung außerhalb vorhandener Befugnisse liegt, - mehrere Teams im Konflikt stehen, - oder ein Risiko akzeptiert werden muss. Sie bedeutet nicht automatisch, dass ein technischer Vorgang an eine Führungskraft zur Lösung weitergegeben wird. Die Führungskraft oder autorisierte Rolle kann beispielsweise: - zusätzliche Ressourcen bereitstellen, - Prioritäten verändern, - eine Entscheidung treffen, - Risiken akzeptieren oder weiter eskalieren, - und Kommunikation koordinieren. --- **Ownership eines Vorgangs** Die Organisation sollte festlegen, wer einen Vorgang über seinen gesamten Verlauf besitzt. Mögliche Modelle: - Service Desk bleibt bis zum Abschluss Eigentümer des Benutzerkontakts. - technisches Team übernimmt vollständiges Ownership. - Service Desk besitzt Kommunikation, Fachteam besitzt technische Bearbeitung. - Incident Manager übernimmt bei schweren Incidents die Koordination. - Product Team besitzt das Ende-zu-Ende-Ergebnis für seinen Service. Unabhängig vom Modell muss geklärt sein: - Wer überwacht den Fortschritt? - Wer kommuniziert? - Wer eskaliert? - Wer prüft das Ergebnis? - Wer schließt den Vorgang? - Wer leitet Folgeaktivitäten ein? > **Typischer Fehler** > > Ein Ticket besitzt eine zugewiesene Gruppe, aber keine Person oder Rolle fühlt sich für das Gesamtergebnis verantwortlich. --- **Warme und kalte Übergabe** **Kalte Übergabe** Der Vorgang wird ohne direkte Abstimmung einer anderen Gruppe zugewiesen. Mögliche Folge: - Kontextverlust, - Rückfragen, - unklare Verantwortung, - und längere Wartezeit. **Warme Übergabe** Die übergebende und übernehmende Rolle stimmen sich ab. Mögliche Bestandteile: - Situation erklären, - wichtige Informationen bestätigen, - nächste Verantwortung klären, - Benutzer über die Übergabe informieren, - und Rückfragen direkt beantworten. Eine warme Übergabe ist besonders hilfreich bei: - komplexen Incidents, - emotional belastenden Situationen, - Sicherheitsvorfällen, - wichtigen Kunden, - und schwer nachvollziehbaren Fehlerbildern. Sie ist nicht für jeden einfachen Vorgang notwendig. --- **Ticketqualität** Ein gutes Ticket unterstützt: - Bearbeitung, - Kommunikation, - Nachvollziehbarkeit, - Auswertung, - Wissen, - und Verbesserung. Mögliche Mindestinformationen: - meldende Person, - betroffener Benutzer oder Bereich, - Kontaktweg, - betroffener Service, - verständliche Beschreibung, - beobachtetes Symptom, - Zeitpunkt, - Auswirkungen, - Dringlichkeit, - bereits durchgeführte Schritte, - aktuelle Verantwortung, - und nächster Schritt. Abhängig vom Vorgang können zusätzlich notwendig sein: - Gerät oder Asset, - Standort, - Fehlermeldung, - Screenshot, - Protokolldaten, - betroffene Version, - Lieferant, - Sicherheitsbezug, - oder zugehöriger Change. > **Wichtig** > > Es sollen nur Informationen erfasst werden, die einen erkennbaren Zweck besitzen und rechtmäßig verarbeitet werden dürfen. --- **Objektiv und verständlich dokumentieren** Ungeeignete Dokumentation: > Benutzer hat wieder alles falsch gemacht. Besser: > Der Benutzer verwendete den bisherigen Anmeldeweg. Seit der Änderung vom 1. August ist eine zusätzliche MFA-Bestätigung erforderlich. Die neue Anleitung war ihm nicht bekannt. Ungeeignete Dokumentation: > Server kaputt. Besser: > Der Anwendungsserver ist seit 10:15 Uhr nicht über HTTPS erreichbar. ICMP und SSH funktionieren. Der Webdienst ist beendet und startet mit Fehlercode 1. Dokumentation sollte: - sachlich, - nachvollziehbar, - diskriminierungsfrei, - und für die weitere Bearbeitung geeignet sein. --- **Kategorisierung** Kategorien können dabei helfen: - zuständige Bearbeitung zu bestimmen, - ähnliche Vorgänge zu erkennen, - Berichte zu erstellen, - Wissen zuzuordnen, - und Verbesserungen zu identifizieren. Eine Kategorie sollte nicht ausschließlich die vermutete technische Ursache abbilden. Zu Beginn ist die Ursache häufig unbekannt. Mögliche Kategorisierungsdimensionen: - betroffener Service, - Serviceangebot, - Kontaktart, - Incident oder Service Request, - technischer Bereich, - Benutzergruppe, - Standort, - und Sicherheitsbezug. > **Typischer Fehler** > > Benutzer müssen in einem Portal aus einer umfangreichen technischen Komponentenliste auswählen, obwohl sie den betroffenen Service und die Ursache nicht kennen. --- **Priorisierung** Die Priorität sollte nach den Regeln der Organisation bestimmt werden. Häufig verwendete Kriterien sind: - Auswirkungen, - Dringlichkeit, - Kritikalität des Service, - Anzahl betroffener Benutzer, - betroffener Geschäftsprozess, - verfügbare Zwischenlösung, - Sicherheits- oder Datenschutzrisiko, - drohender Datenverlust, - und zeitkritische Geschäftssituation. ITIL schreibt keine universelle Prioritätsmatrix vor. Beispiel: Ein einzelner ausgefallener Arbeitsplatz kann eine geringe Auswirkung besitzen. Ist es jedoch der einzige Arbeitsplatz zur Steuerung einer kritischen Anlage, kann die tatsächliche Auswirkung sehr hoch sein. > **Merke** > > Die Anzahl betroffener Benutzer ist wichtig, aber nicht das einzige Kriterium. --- **Der Service Desk entscheidet nicht allein nach Lautstärke** Benutzer können ihre Situation subjektiv als sehr dringend wahrnehmen. Der Service Desk sollte: - die Auswirkung ernst nehmen, - fehlende Informationen erfragen, - die organisatorischen Kriterien anwenden, - und eine abweichende Priorisierung verständlich erklären. Ungeeignet: > Das ist nicht dringend. Besser: > Ich verstehe, dass Sie die Anwendung heute benötigen. Nach unseren Prioritätskriterien ist aktuell nur Ihr Arbeitsplatz betroffen und es steht ein Ersatzarbeitsplatz zur Verfügung. Der Vorgang wird deshalb als Priorität 3 bearbeitet. Sollte auch der Ersatz nicht funktionieren oder weitere Benutzer betroffen sein, wird die Priorität erneut bewertet. --- **Major Incidents erkennen und eskalieren** Ein Major Incident ist ein besonders schwerwiegender Incident. Die Organisation muss eigene Kriterien festlegen. Mögliche Hinweise: - Ausfall eines kritischen Service, - sehr viele betroffene Benutzer, - erhebliche Geschäfts- oder Kundenwirkung, - mögliche Sicherheits- oder Datenschutzverletzung, - drohender erheblicher Datenverlust, - starke öffentliche Wirkung, - oder sehr hoher Koordinationsbedarf. Der Service Desk kann eine wichtige Rolle übernehmen bei: - Erkennen möglicher Kriterien, - schneller Eskalation, - Sammeln von Benutzerinformationen, - Verwenden freigegebener Statusmeldungen, - und Vermeiden widersprüchlicher Kommunikation. Major Incident Management wird nicht als eigenständige der 34 ITIL Management Practices behandelt. Organisationen können jedoch ein eigenes Major-Incident-Verfahren innerhalb ihrer Incident-Management-Arbeitsweise verwenden. --- **Knowledge Management** Der Service Desk benötigt gut nutzbares Wissen. Beispiele: - Diagnoseanleitungen, - bekannte Lösungen, - Workarounds, - Serviceinformationen, - Benutzeranleitungen, - Eskalationswege, - Lieferantenkontakte, - Sicherheitsverfahren, - und aktuelle Störungsinformationen. Ein Wissensartikel sollte möglichst: - verständlichen Titel, - klare Zielgruppe, - Voraussetzungen, - sichere Schritte, - erwartetes Ergebnis, - Versionsstand, - Verantwortlichen, - und Prüfdatum enthalten. Der Service Desk ist gleichzeitig eine wichtige Quelle neuen Wissens. Wiederkehrende Fragen können zeigen: - Anleitung ist unverständlich, - Funktion ist schlecht gestaltet, - Serviceangebot ist unklar, - oder Schulung fehlt. --- **Self-Service** Self-Service kann Benutzern ermöglichen: - Informationen zu finden, - standardisierte Anfragen zu stellen, - den Status zu prüfen, - Kennwörter sicher zurückzusetzen, - Software anzufordern, - oder bekannte einfache Probleme zu lösen. Erfolgreicher Self-Service benötigt: - verständliche Sprache, - gute Suchfunktion, - aktuelle Inhalte, - klare Serviceangebote, - einfache Formulare, - geeignete Authentifizierung, - barrierearme Bedienung, - und einen sichtbaren Weg zu menschlicher Unterstützung. > **Typischer Fehler** > > Ein Portal wird eingeführt und Benutzer werden gezwungen, es zu verwenden, obwohl Inhalte, Suche und Formulare unverständlich sind. Self-Service sollte Benutzeraufwand reduzieren und nicht nur Arbeit vom Service Desk auf Benutzer verlagern. --- **Automatisierung** Mögliche Automatisierungen im Service Desk: - automatische Eingangsbestätigung, - Vorschlag einer Kategorie, - Zuordnung anhand klarer Regeln, - Anzeige passender Wissensartikel, - Statusbenachrichtigungen, - sichere Kennwort-Selbstverwaltung, - automatische Standardbereitstellung, - Erkennung doppelter Tickets, - und Eskalation bei drohender Zielverletzung. Vor der Automatisierung muss geklärt sein: - Ist der Ablauf verstanden? - Sind Regeln eindeutig? - Sind Eingangsdaten zuverlässig? - Welche Ausnahmen bestehen? - Wie werden Fehler erkannt? - Wie kann ein Mitarbeiter eingreifen? - Wer trägt Verantwortung? - Wie wird der Nutzen gemessen? --- **Künstliche Intelligenz im Service Desk** KI kann unter anderem unterstützen bei: - Zusammenfassung von Kontakten, - Erkennung ähnlicher Vorgänge, - Kategorisierungsvorschlägen, - Übersetzung, - Wissenssuche, - Formulierung von Antworten, - Erkennung von Mustern, - und einfachen virtuellen Agenten. KI kann jedoch Fehler erzeugen. Mögliche Risiken: - falsche Kategorisierung, - unzutreffende Lösungsvorschläge, - Offenlegung vertraulicher Informationen, - erfundene technische Aussagen, - ungeeignete Priorisierung, - diskriminierende oder unangemessene Kommunikation, - und unklare Verantwortung. Notwendig sind unter anderem: - zugelassene Anwendungsfälle, - Datenschutz- und Sicherheitsprüfung, - geeignete Datenquellen, - menschliche Kontrolle, - transparente Kennzeichnung, - Fehlerbehandlung, - und regelmäßige Qualitätsprüfung. > **Sicherheitsrelevant** > > KI-generierte technische Anweisungen dürfen abhängig vom möglichen Risiko nicht ungeprüft an Benutzer weitergegeben oder auf produktiven Systemen ausgeführt werden. --- **Der menschliche Kontakt bleibt wichtig** Automatisierung und Self-Service können standardisierte Anliegen effizient bearbeiten. Menschliche Unterstützung bleibt besonders wichtig bei: - komplexen Situationen, - unklaren Anforderungen, - emotional belastenden Incidents, - wichtigen Geschäftsfolgen, - Sicherheitsvorfällen, - mehreren gleichzeitig auftretenden Problemen, - und Situationen, die Einfühlungsvermögen oder kreative Zusammenarbeit erfordern. Ein guter Service Desk verbindet deshalb: - menschliches Verständnis, - technisches Wissen, - Servicekontext, - geeignete Automatisierung, - und zuverlässige Informationen. --- **Informationssicherheit am Service Desk** Der Service Desk verarbeitet häufig sensible Informationen und kann ein Ziel für Social Engineering sein. Wichtige Grundsätze: - Identität nach festgelegtem Verfahren prüfen. - niemals Kennwörter erfragen oder dokumentieren. - keine Sicherheitskontrolle nur aufgrund von Zeitdruck umgehen. - administrative Zugänge besonders schützen. - sensible Informationen nur an berechtigte Personen weitergeben. - verdächtige Kontakte nach festgelegtem Verfahren eskalieren. - Remote-Zugriffe transparent und kontrolliert durchführen. - keine unbekannten Dateien oder Links ungeprüft öffnen. - Sicherheitsvorfälle nicht in ungeeigneten öffentlichen Kanälen diskutieren. - nur notwendige personenbezogene Daten erfassen. Beispiel: Eine Person ruft an und verlangt dringend die Zurücksetzung des Kennworts eines Geschäftsführers. Zeitdruck, Autoritätsbezug und angebliche Dringlichkeit dürfen die vorgesehene Identitätsprüfung nicht ersetzen. --- **Remote-Unterstützung** Bei Remote-Support sollte geklärt sein: - welches Werkzeug zugelassen ist, - wie der Benutzer zustimmt, - wie die Identität geprüft wird, - welche Aktionen durchgeführt werden dürfen, - ob Sitzungen protokolliert werden, - wie sensible Bildschirminhalte geschützt werden, - und wann die Verbindung beendet wird. Der Mitarbeiter sollte: - erklären, was er durchführt, - keine unnötigen Daten öffnen, - keine Kennwörter beobachten oder speichern, - und den Benutzer über das Ergebnis informieren. --- **Datenschutz und Vertraulichkeit** Tickets können enthalten: - personenbezogene Daten, - Gesundheitsinformationen, - vertrauliche Geschäftsdaten, - Sicherheitsinformationen, - oder technische Zugangsdaten. Deshalb sollte die Organisation festlegen: - welche Informationen notwendig sind, - wer darauf zugreifen darf, - wie lange sie gespeichert werden, - welche Inhalte nicht erfasst werden dürfen, - wie Anhänge geschützt werden, - und wie Daten gelöscht oder anonymisiert werden. > **Typischer Fehler** > > Benutzer senden vollständige vertrauliche Dokumente, obwohl für die Diagnose nur eine Fehlermeldung oder ein technisch begrenzter Ausschnitt erforderlich wäre. --- **Zusammenarbeit mit Lieferanten** Ein Service Desk kann externe Lieferanten einbinden. Dafür sollten verfügbar sein: - Anbietername, - betroffene Leistung, - Vertrags- oder Kundennummer, - Supportkontakt, - Servicezeiten, - Eskalationsweg, - benötigte Diagnoseinformationen, - und interne Verantwortung. Eine Lieferantenmeldung sollte möglichst enthalten: - konkrete Auswirkung, - betroffenen Service, - Beginn, - Umfang, - technische Beobachtungen, - bereits geprüfte Punkte, - Dringlichkeit, - und gewünschte Unterstützung. Die Weitergabe an einen Lieferanten beendet nicht die interne Verantwortung für: - Koordination, - Kommunikation, - Sicherheitsbewertung, - und Prüfung des Ende-zu-Ende-Service. --- **Service-Desk-Kompetenzen** Mögliche benötigte Kompetenzen: - aktives Zuhören, - verständliche Kommunikation, - Empathie, - technische Grundlagen, - Serviceverständnis, - strukturierte Diagnose, - Priorisierung, - Dokumentation, - Wissensnutzung, - Sicherheitsbewusstsein, - Konfliktfähigkeit, - Zusammenarbeit, - Zeitmanagement, - und Lernbereitschaft. Nicht jeder Mitarbeiter benötigt dieselbe technische Tiefe. Der Service Desk benötigt jedoch ausreichend gemeinsames Wissen über: - wichtige Benutzergruppen, - kritische Services, - grundlegende Abhängigkeiten, - typische Störungen, - Serviceangebote, - und Eskalationswege. --- **Einarbeitung neuer Service-Desk-Mitarbeiter** Eine sinnvolle Einarbeitung kann umfassen: - Organisation und Geschäftsbereiche, - wichtige Produkte und Services, - Benutzergruppen, - Kontaktkanäle, - Ticketsystem, - Sicherheits- und Datenschutzvorgaben, - Incident- und Request-Arbeitsweisen, - Prioritätskriterien, - Eskalationswege, - Knowledge-Base, - Lieferanten, - Kommunikationsstandards, - und praktische Begleitung erfahrener Mitarbeiter. Zusätzlich hilfreich: - Besuche wichtiger Arbeitsbereiche, - Beobachtung realer Benutzeraufgaben, - Übung typischer Gesprächssituationen, - und kontrollierte Bearbeitung erster Vorgänge. --- **Qualität statt reiner Geschwindigkeit** Ein Service Desk sollte nicht ausschließlich nach Geschwindigkeit beurteilt werden. Mögliche Qualitätsaspekte: - Anliegen wurde richtig verstanden. - Informationen sind vollständig. - Kategorisierung ist brauchbar. - Priorität ist nachvollziehbar. - Kommunikation ist verständlich. - Benutzer musste Informationen nicht mehrfach liefern. - Lösung ist sicher und wirksam. - Wiederherstellung wurde bestätigt. - Dokumentation unterstützt spätere Bearbeitung. - Wissen wurde aktualisiert. - mögliche Verbesserungen wurden erkannt. --- **Mögliche Kennzahlen** Kennzahlen werden von der jeweiligen Organisation festgelegt. Mögliche Beispiele: | Kennzahl | Mögliche Aussage | |---|---| | **First Contact Resolution** | Anteil geeigneter Anliegen, die beim ersten Kontakt gelöst werden | | **durchschnittliche Antwortzeit** | Zeit bis zur ersten qualifizierten Reaktion | | **gesamte Lösungs- oder Erfüllungszeit** | Ende-zu-Ende-Dauer bis zum Ergebnis | | **Abbruchquote** | Anteil abgebrochener Telefon- oder Chatkontakte | | **Wiedereröffnungsquote** | mögliche Hinweise auf unvollständige Lösungen | | **Anzahl der Übergaben** | möglicher Hinweis auf unnötige Weiterleitungen | | **Benutzerzufriedenheit** | subjektive Erfahrung nach dem Kontakt | | **erneute Kontaktaufnahme** | mögliche Hinweise auf fehlende Lösung oder Kommunikation | | **Ticketqualität** | Vollständigkeit und Nutzbarkeit der Dokumentation | | **Backlog-Alter** | Alter unbearbeiteter oder nicht abgeschlossener Vorgänge | | **Nutzung von Wissen** | Verwendung und Wirksamkeit von Wissensartikeln | | **Self-Service-Erfolgsquote** | Anteil erfolgreich selbst erledigter geeigneter Anliegen | Keine einzelne Kennzahl beschreibt die gesamte Leistung. --- **Problematische Kennzahlen** **Möglichst kurze Gesprächsdauer** Mögliche Fehlwirkung: - Benutzer wird unterbrochen. - Problem wird nicht vollständig verstanden. - spätere Rückfragen erhöhen den Gesamtaufwand. **Möglichst viele geschlossene Tickets** Mögliche Fehlwirkung: - Vorgänge werden voreilig geschlossen. - Qualität und Outcome werden vernachlässigt. **Möglichst hohe First Contact Resolution** Mögliche Fehlwirkung: - komplexe Vorgänge werden oberflächlich behandelt. - notwendige Eskalation wird vermieden. **Möglichst wenige Eskalationen** Mögliche Fehlwirkung: - Service Desk bearbeitet Aufgaben ohne ausreichende Fähigkeiten oder Befugnisse. **Möglichst geringe Kosten pro Kontakt** Mögliche Fehlwirkung: - menschliche Unterstützung wird reduziert, obwohl die Benutzererfahrung leidet. > **Merke** > > Kennzahlen beeinflussen Verhalten. > > Sie sollten deshalb gemeinsam und im Zusammenhang mit Outcomes, Qualität und Risiken betrachtet werden. --- **Benutzerfeedback** Benutzerfeedback kann erhoben werden durch: - kurze Umfragen, - Rückfragen nach Abschluss, - Interviews, - Workshops, - Auswertung von Beschwerden, - Beobachtung von Kontaktmustern, - und Gespräche mit Fachabteilungen. Feedback sollte: - freiwillig, - verständlich, - möglichst kurz, - und tatsächlich auswertbar sein. Eine sehr niedrige Rücklaufquote kann die Aussagekraft begrenzen. Negative Einzelbewertungen sollten nicht automatisch als persönliches Versagen eines Mitarbeiters behandelt werden. Zu untersuchen sind auch: - Produktqualität, - Wartezeit, - ungeeignete Vorgaben, - fehlende Befugnisse, - Lieferantenprobleme, - und unverständliche Serviceangebote. --- **Der Service Desk als Quelle für Continual Improvement** Der Service Desk erkennt häufig früh: - wiederkehrende Incidents, - unklare Serviceangebote, - häufige Benutzerfehler, - fehlende Schulung, - schlechte Dokumentation, - unnötige Prozessschritte, - fehlerhafte Automatisierungen, - und neue Benutzerbedürfnisse. Diese Erkenntnisse sollten nicht nur in einzelnen Tickets verbleiben. Mögliche Verbesserungen: - Wissensartikel erstellen, - Formular vereinfachen, - Serviceangebot verständlicher beschreiben, - Monitoring ergänzen, - Softwarefehler an Product Teams melden, - Request automatisieren, - wiederkehrendes Problem untersuchen, - oder Schulung verbessern. --- **Praxisbeispiel: Anmeldung funktioniert nicht** Ein Benutzer meldet telefonisch: > Ich kann mich nicht anmelden. **Ungeeignete Bearbeitung** 1. Ticket mit Titel „Login geht nicht“ erstellen. 2. Vorgang ohne weitere Informationen an das Serverteam senden. 3. Benutzer erhält keine Statusinformation. 4. Serverteam stellt fest, dass MFA betroffen ist. 5. Ticket wird an ein anderes Team weitergegeben. 6. Benutzer ruft erneut an. **Bessere Bearbeitung** 1. betroffenen Benutzer und Service bestimmen 2. genaue Fehlermeldung erfassen 3. feststellen, ob weitere Benutzer betroffen sind 4. Netzwerkverbindung und allgemeine Serviceinformation prüfen 5. bekannte Störungen und letzte Änderungen prüfen 6. sichere bekannte Lösung anwenden oder geeignete Fachgruppe einbinden 7. bisherigen Diagnoseweg dokumentieren 8. Benutzer über nächsten Schritt informieren 9. Wiederherstellung bestätigen 10. wiederkehrendes Muster an Problem Management oder Continual Improvement weitergeben --- **Praxisbeispiel: Drucker funktioniert nicht** Meldung: > Der Drucker ist kaputt. Mögliche Klärung: - Welcher Druckservice wird verwendet? - Welcher Drucker ist betroffen? - Können andere Benutzer drucken? - Kann der Benutzer auf einem anderen Drucker drucken? - Ist nur eine Anwendung betroffen? - Befindet sich ein Auftrag in der Warteschlange? - Zeigt das Gerät einen Hardwarefehler? - Besteht eine Netzwerkverbindung? - Wurde kürzlich ein Treiber oder eine Konfiguration geändert? - Gibt es einen alternativen Druckweg? Mögliche Einordnung: - lokaler Incident, - allgemeiner Serviceausfall, - Verbrauchsmaterial, - Hardwaredefekt, - Service Request, - oder Lieferantenfall. Das Beispiel zeigt, warum die Formulierung des Benutzers allein nicht die fachliche Kategorie bestimmt. --- **Praxisbeispiel: Verdächtige E-Mail** Ein Benutzer meldet eine verdächtige Nachricht. Der Service Desk sollte nach dem Sicherheitsverfahren handeln. Mögliche Schritte: - Benutzer auffordern, keine Links oder Anhänge zu öffnen, - erforderliche Informationen sicher erfassen, - Nachricht nicht unkontrolliert weiterleiten, - zuständige Sicherheitsrolle einbinden, - mögliche Betroffenheit weiterer Benutzer prüfen lassen, - und nur freigegebene Kommunikation verwenden. Der Vorgang darf nicht allein als normale E-Mail-Störung behandelt werden. --- **Praxisbeispiel: Mehrfachmeldungen bei einem Ausfall** Viele Benutzer melden gleichzeitig, dass die zentrale Dateiablage nicht erreichbar ist. Der Service Desk kann: 1. Meldungen zu einem gemeinsamen Incident zusammenführen 2. Auswirkung und betroffene Bereiche erfassen 3. Major-Incident-Kriterien prüfen 4. technische Teams und Lieferanten einbinden 5. bekannte Statusinformationen veröffentlichen 6. Benutzer von unnötigen Einzelrückfragen entlasten 7. Zwischenlösungen kommunizieren 8. Wiederherstellung bestätigen 9. Folgeaktivitäten dokumentieren > **Praxistipp** > > Bei einer bekannten größeren Störung kann eine gut sichtbare Statusmeldung mehr Benutzeraufwand reduzieren als die wiederholte Einzelbearbeitung identischer Kontakte. --- **Typische Fehler im Service Desk** **Fehler 1: Ticketweiterleitung als Hauptziel** Kontakte werden möglichst schnell weitergereicht, ohne ausreichende Informationen zu erfassen. --- **Fehler 2: Benutzer müssen die technische Zuständigkeit kennen** Portale oder Mitarbeiter verlangen, dass Benutzer selbst das richtige Fachteam auswählen. --- **Fehler 3: Priorisierung nach Lautstärke** Persönliche Kontakte, Hierarchie oder häufige Nachfragen bestimmen die Reihenfolge. --- **Fehler 4: Keine Ende-zu-Ende-Verantwortung** Nach einer Weiterleitung überwacht niemand Fortschritt und Benutzerkommunikation. --- **Fehler 5: Technische Wiederherstellung nicht bestätigen** Das Fachteam meldet Erfolg, aber der Benutzer kann weiterhin nicht arbeiten. --- **Fehler 6: Gesprächszeit über Qualität stellen** Mitarbeiter beenden Kontakte schnell, erzeugen dadurch aber Rückfragen und Nacharbeit. --- **Fehler 7: Service Desk als reine Einstiegsposition behandeln** Fähigkeiten, Entwicklungsmöglichkeiten und strategische Bedeutung werden unterschätzt. --- **Fehler 8: Wissen nur bei einzelnen Personen** Lösungen bleiben in privaten Notizen oder persönlichen Chatverläufen. --- **Fehler 9: Self-Service als Zwang verwenden** Benutzer erhalten keinen geeigneten menschlichen Kontaktweg für komplexe Situationen. --- **Fehler 10: KI-Antworten ungeprüft übernehmen** Falsche oder unsichere Lösungsvorschläge werden an Benutzer weitergegeben. --- **Fehler 11: Sicherheitskontrollen unter Zeitdruck umgehen** Identitäten werden nicht ausreichend geprüft oder sensible Informationen ungeschützt verarbeitet. --- **Fehler 12: Jede Meldung als Incident behandeln** Service Requests, Fragen, Feedback und Sicherheitsmeldungen werden falsch eingeordnet. --- **Fehler 13: Jeden Kontakt einzeln betrachten** Mehrfachmeldungen und wiederkehrende Muster werden nicht erkannt. --- **Fehler 14: Keine Rückmeldung bei Verzögerungen** Benutzer müssen wiederholt nach dem Status fragen. --- **Fehler 15: Ticket schließen, weil der Benutzer nicht sofort antwortet** Es wird nicht geprüft, ob angemessene Kontaktversuche, Fristen und alternative Wege verwendet wurden. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker können im Service Desk oder in nachgelagerten Fachteams arbeiten. Wichtige Beiträge sind: - technische Zusammenhänge verständlich erklären, - vollständige Diagnoseinformationen bereitstellen, - Rückfragen vermeiden, - Statusänderungen dokumentieren, - Serviceauswirkungen berücksichtigen, - sichere Lösungen anwenden, - Wissen weitergeben, - Lieferanteninformationen ergänzen, - und Verbesserungsmöglichkeiten melden. Wenn du ein Ticket aus dem Service Desk erhältst, prüfe: - Ist der betroffene Service bekannt? - Sind Symptom und Auswirkung verständlich? - Welche Diagnose wurde bereits durchgeführt? - Welche Ergebnisse liegen vor? - Ist die Priorität nachvollziehbar? - Welche Rückmeldung wird vom Fachteam erwartet? - Wer kommuniziert mit dem Benutzer? - Wie wird die Lösung bestätigt? - Muss Wissen oder Dokumentation aktualisiert werden? --- **30-Sekunden-Prüfung eines Benutzerkontakts** 1. **Person:** Wer meldet und wer ist betroffen? 2. **Service:** Welche Arbeitsfähigkeit oder welcher Service wird benötigt? 3. **Symptom:** Was wurde beobachtet? 4. **Zeit:** Seit wann besteht die Situation? 5. **Auswirkung:** Was kann nicht durchgeführt werden? 6. **Umfang:** Sind weitere Benutzer oder Standorte betroffen? 7. **Kontext:** Was wurde verändert oder bereits versucht? 8. **Einordnung:** Incident, Service Request, Frage, Feedback oder Sicherheitsmeldung? 9. **Nächster Schritt:** Wer übernimmt welche Aufgabe? 10. **Kommunikation:** Wann erhält der Benutzer die nächste Information? 11. **Ergebnis:** Wie wird die Wiederherstellung oder Erfüllung bestätigt? 12. **Lernen:** Muss Wissen oder eine Verbesserung ergänzt werden? --- **Checkliste für die Kontaktaufnahme** - [ ] Ist der Benutzer freundlich und professionell begrüßt worden? - [ ] Wurde die Identität bei Bedarf nach dem vorgesehenen Verfahren geprüft? - [ ] Ist klar, wer betroffen ist? - [ ] Ist der benötigte Service bekannt? - [ ] Wurde das beobachtete Symptom verständlich erfasst? - [ ] Wurde nach Auswirkungen und Umfang gefragt? - [ ] Wurden relevante Zeitangaben erfasst? - [ ] Wurden bereits durchgeführte Schritte dokumentiert? - [ ] Wurden sensible Informationen angemessen geschützt? - [ ] Wurde der nächste Schritt verständlich erklärt? - [ ] Wurde ein realistischer Zeitpunkt für die nächste Information genannt? --- **Checkliste für die Weiterleitung** - [ ] Ist die zuständige Practice oder Fachgruppe nachvollziehbar? - [ ] Ist der betroffene Service eindeutig? - [ ] Sind Auswirkungen und Priorität dokumentiert? - [ ] Sind Fehlermeldungen und Beobachtungen enthalten? - [ ] Sind bisherige Diagnose und Ergebnisse dokumentiert? - [ ] Sind relevante Screenshots oder Protokolle sicher beigefügt? - [ ] Ist klar, welche Unterstützung benötigt wird? - [ ] Ist die weitere Verantwortung geklärt? - [ ] Weiß der Benutzer, dass und warum weitergeleitet wurde? - [ ] Ist festgelegt, wer den Fortschritt überwacht? --- **Checkliste für die Kommunikation** - [ ] Ist die Sprache für die Zielgruppe verständlich? - [ ] Sind technische Fachbegriffe erklärt oder vermieden? - [ ] Ist die Aussage korrekt und freigegeben? - [ ] Wird klar, was bereits bekannt ist? - [ ] Wird klar, was noch untersucht wird? - [ ] Wird der nächste Schritt genannt? - [ ] Wird eine realistische nächste Statuszeit genannt? - [ ] Werden unbelegte Versprechen vermieden? - [ ] Sind Handlungshinweise eindeutig? - [ ] Werden vertrauliche Informationen geschützt? --- **Checkliste vor dem Abschluss** - [ ] Wurde die technische Funktion geprüft? - [ ] Wurde die Nutzbarkeit aus Benutzersicht geprüft? - [ ] Ist das gewünschte Outcome ausreichend erreicht? - [ ] Sind durchgeführte Maßnahmen dokumentiert? - [ ] Ist die Lösung verständlich beschrieben? - [ ] Wurde der Benutzer über den Abschluss informiert? - [ ] Sind Asset- oder Konfigurationsinformationen aktuell? - [ ] Muss ein Wissensartikel erstellt oder aktualisiert werden? - [ ] Besteht ein wiederkehrendes Muster? - [ ] Muss Problem Management einbezogen werden? - [ ] Besteht eine Verbesserungsmöglichkeit? - [ ] Sind offene Folgeaktivitäten eindeutig zugeordnet? --- **Checkliste für einen wirksamen Service Desk** - [ ] Besitzen Benutzer einen verständlichen Kontaktweg? - [ ] Werden alle angebotenen Kanäle zuverlässig überwacht? - [ ] Werden Kontakte in einer gemeinsamen Sicht zusammengeführt? - [ ] Sind Servicezeiten und Zuständigkeiten bekannt? - [ ] Sind Incident, Service Request und andere Kontaktarten unterscheidbar? - [ ] Sind Prioritätskriterien nachvollziehbar? - [ ] Sind funktionale und hierarchische Eskalationswege vorbereitet? - [ ] Sind wichtige Services und Benutzergruppen bekannt? - [ ] Ist Wissen aktuell und auffindbar? - [ ] Sind Lieferantenkontakte und Verträge zugänglich? - [ ] Sind Sicherheits- und Datenschutzverfahren bekannt? - [ ] Werden Benutzer verständlich und regelmäßig informiert? - [ ] Wird die Wiederherstellung aus Benutzersicht bestätigt? - [ ] Werden Kennzahlen gemeinsam und outcome-orientiert betrachtet? - [ ] Fließen Kontaktdaten und Feedback in Continual Improvement ein? --- **Schnellreferenz** | Frage | Bedeutung | |---|---| | Wer meldet? | Kontakt und betroffene Person bestimmen | | Was wird benötigt? | Service oder gewünschtes Outcome verstehen | | Was ist geschehen? | Symptom und Situation erfassen | | Wer ist betroffen? | Auswirkungen und Umfang bestimmen | | Wie dringend ist es? | organisatorische Prioritätskriterien anwenden | | Was wurde bereits geprüft? | doppelte Arbeit vermeiden | | Wer kann helfen? | geeignete Fähigkeiten und Practices einbinden | | Wer besitzt den Vorgang? | Ende-zu-Ende-Verantwortung klären | | Wann gibt es Neuigkeiten? | verlässliche Kommunikation sicherstellen | | Funktioniert es wieder? | technisches und benutzerbezogenes Ergebnis bestätigen | | Was lernen wir? | Wissen und Verbesserung ableiten | --- **Aufbau dieses Kapitels** Die folgenden Seiten vertiefen die operative Arbeit rund um den Service Desk: - 3.2 Kontaktkanäle und Erreichbarkeit - 3.3 Benutzerkommunikation und professioneller Umgang - 3.4 Tickets vollständig erfassen und kategorisieren - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk --- **Zusammenfassende Darstellung** > Benutzer besitzt eine Frage, Anfrage oder Beeinträchtigung > ↓ > verständlicher Kontaktkanal > ↓ > Service Desk nimmt Kontakt auf > ↓ > Identität · Service · Symptom · Auswirkung · Dringlichkeit erfassen > ↓ > Anliegen fachlich einordnen > ↓ > bekannte Lösung anwenden oder geeignete Fähigkeiten einbinden > ↓ > Verantwortung und Kommunikation aufrechterhalten > ↓ > Ergebnis technisch und aus Benutzersicht prüfen > ↓ > Vorgang nachvollziehbar abschließen > ↓ > Wissen, Muster und Verbesserungsmöglichkeiten weiterverwenden --- **Verwandte Seiten** - 1.1 Warum professionelles Service Management notwendig ist - 1.4 Servicebeziehungen, Rollen und Serviceangebote - 2.3 Die sieben Guiding Principles - 2.5 Die vier Dimensionen des Produkt- und Service-Managements - 2.7 Die ITIL Management Practices - 2.8 Value Streams und Value Stream Mapping - 2.9 Continual Improvement - 3.2 Kontaktkanäle und Erreichbarkeit - 3.3 Benutzerkommunikation und professioneller Umgang - 3.4 Tickets vollständig erfassen und kategorisieren - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Incident Management - Service Request Management - Knowledge Management - Problem Management - Monitoring and Event Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - [PeopleCert: ITIL Foundation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) - [ITIL: ITIL Foundation – Version 5](https://www.itil.com/professionals/certifications/ITIL-Foundation-Version-5) - [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/ITIL-Service-Version-5) - [PeopleCert: ITIL Service – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-service-version-5-4181) - [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706) - [PeopleCert: ITIL 4 Specialist – Monitor, Support and Fulfil](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-monitor-support-and-fulfil-batch-1-3682) - [ITIL: The ongoing relevance of the service desk in an AI world](https://www.itil.com/Itil-News-and-Announcements/service-desk-relevance-ai-world) - [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide) **Offiziell bestätigter Stand** Die offiziellen ITIL-Quellen bestätigen: - Service Desk bleibt eine der 34 ITIL Management Practices. - Die Service-Desk-Practice ist mit Incident Management, Service Request Management, Problem Management sowie Monitoring and Event Management eng verbunden. - Der Service Desk ist häufig ein zentraler Knotenpunkt mehrerer Wertströme. - Er stellt einen wesentlichen Kommunikationsweg zwischen Service Provider und Benutzern bereit. - Technische Fähigkeiten, Kommunikationsfähigkeit, Empathie und Verständnis des Benutzerkontexts bleiben wesentlich. - KI und Automatisierung können wiederkehrende Aufgaben, Wissenssuche, Klassifizierung und einfache Unterstützung übernehmen. - Menschliche Kommunikation und Einordnung bleiben insbesondere bei komplexen und belastenden Situationen wichtig. - ITIL Version 5 führt die 34 Practices weiter und verbindet sie mit dem gemeinsamen Product and Service Lifecycle. **Versionshinweis** Die öffentlich zugängliche spezialisierte Zertifizierungs- und Practice-Seite trägt derzeit weiterhin die Bezeichnung **ITIL 4 Practitioner: Service Desk**. ITIL Version 5 führt die Management Practices grundsätzlich fort und entwickelt sie weiter. Vollständige aktuelle Practice Guidance wird über die offiziellen ITIL Practice Guides bereitgestellt. Diese Seite stellt deshalb keine nicht öffentlich belegten Detailänderungen einer zukünftigen oder nur zugangsbeschränkt verfügbaren Service-Desk-Practice-Guidance als gesichert dar. **Einordnung** Die ausführlichen: - Organisationsmodelle, - Kanalbeschreibungen, - Diagnosefragen, - Checklisten, - Ticketbeispiele, - Eskalationshinweise, - Kennzahlen, - und Praxisempfehlungen sind herstellerneutrale Erläuterungen dieses unabhängigen Nachschlagewerks. Sie stellen keine für jede Organisation verbindlichen ITIL-Prozesse, Support-Level, Prioritätsmatrizen oder Organisationsstrukturen dar. Die konkrete Gestaltung des Service Desk muss an: - Benutzer, - Services, - Geschäftszeiten, - Risiken, - Sicherheitsanforderungen, - Fähigkeiten, - Lieferanten, - und verfügbare Ressourcen angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 3.2 Kontaktkanäle und Erreichbarkeit > **Kurz erklärt** > > Kontaktkanäle bestimmen, wie Benutzer den Service Desk erreichen können. > > Typische Kanäle sind: > > - Self-Service-Portal, > - Telefon, > - E-Mail, > - Chat, > - virtueller Agent, > - mobile Anwendung, > - persönlicher Vor-Ort-Kontakt, > - und besonders definierte Meldewege für Notfälle oder Sicherheitsereignisse. > > Erreichbarkeit beschreibt mehr als die technische Verfügbarkeit eines Kanals. > > Ein Kanal ist erst dann wirksam, wenn: > > - Benutzer ihn kennen, > - er für das jeweilige Anliegen geeignet ist, > - er zuverlässig überwacht wird, > - eine Bearbeitung innerhalb angemessener Zeiten erfolgt, > - Informationen nicht verloren gehen, > - und bei Bedarf ein Wechsel zu menschlicher Unterstützung möglich ist. > > ITIL schreibt keine universelle Anzahl von Kanälen und keinen grundsätzlich rund um die Uhr besetzten Service Desk vor. > > Die Organisation gestaltet Kanäle, Servicezeiten und Eskalationswege entsprechend ihren Benutzern, Services, Risiken und verfügbaren Fähigkeiten. --- **Warum die Gestaltung der Kontaktkanäle wichtig ist** Ein Service Desk kann fachlich gut organisiert sein und trotzdem schlecht erreichbar wirken. Beispiele: - Das Portal ist vorhanden, aber Benutzer finden das passende Formular nicht. - Die Support-E-Mail-Adresse wird nur unregelmäßig geprüft. - Der Chat zeigt „verfügbar“, obwohl kein Mitarbeiter angemeldet ist. - Eine Telefonnummer ist veröffentlicht, aber außerhalb der Servicezeit gibt es keine verständliche Ansage. - Ein virtueller Agent beantwortet Standardfragen, bietet jedoch keinen Übergang zu einem Menschen. - Benutzer melden kritische Störungen über einen Kanal, der erst am nächsten Arbeitstag bearbeitet wird. - Mehrere Kontaktkanäle erzeugen voneinander unabhängige Tickets für dasselbe Anliegen. - Eine Sicherheitsmeldung wird in einem allgemeinen Supportkanal mit ungeeigneten Zugriffsrechten erfasst. Die Wahl und Gestaltung der Kontaktkanäle beeinflusst damit: - Erfassungsqualität, - Bearbeitungsgeschwindigkeit, - Benutzeraufwand, - Informationssicherheit, - Barrierefreiheit, - Priorisierung, - Kommunikation, - Nachvollziehbarkeit, - und die gesamte Benutzererfahrung. > **Merke** > > Viele Kontaktkanäle bedeuten nicht automatisch gute Erreichbarkeit. > > Jeder angebotene Kanal muss zuverlässig betrieben, überwacht und in die gemeinsamen Wertströme eingebunden werden. --- **Kontaktkanal, Servicezeit und Reaktionszeit unterscheiden** | Begriff | Bedeutung | |---|---| | **Kontaktkanal** | Weg, über den ein Benutzer mit dem Service Provider in Verbindung tritt | | **technische Verfügbarkeit** | Zeitraum, in dem der Kanal technisch erreichbar ist | | **Servicezeit** | Zeitraum, in dem eine vereinbarte menschliche oder automatisierte Leistung angeboten wird | | **Supportzeit** | Zeitraum, in dem Unterstützung für einen bestimmten Service bereitsteht | | **Betriebszeit** | Zeitraum, in dem ein Produkt oder Service regulär genutzt werden soll | | **Bereitschaftszeit** | Zeitraum, in dem zuständige Personen außerhalb regulärer Zeiten bei bestimmten Ereignissen reagieren | | **erste Reaktionszeit** | Zeit bis zu einer ersten qualifizierten Rückmeldung | | **Bearbeitungszeit** | Zeit, in der aktiv an einem Anliegen gearbeitet wird | | **Lösungs- oder Erfüllungszeit** | Zeit bis zur ausreichenden Wiederherstellung oder Erfüllung | | **Statusintervall** | vereinbarter Abstand zwischen Statusinformationen | Diese Zeiten können unterschiedlich sein. Beispiel: - Ein Portal ist technisch 24 Stunden täglich erreichbar. - Neue Standardanfragen werden nur montags bis freitags bearbeitet. - Kritische Incidents können außerhalb dieser Zeit über eine Bereitschaftsnummer gemeldet werden. - Ein bestimmter Produktionsservice wird rund um die Uhr betrieben. - Nichtkritische Fragen zu diesem Service werden trotzdem nur während der normalen Service-Desk-Zeit beantwortet. > **Wichtig** > > Ein technisch rund um die Uhr erreichbares Formular bedeutet nicht automatisch einen rund um die Uhr verfügbaren menschlichen Support. --- **Die Kanalstrategie am Benutzerbedarf ausrichten** Vor der Einführung oder Änderung von Kontaktkanälen sollte die Organisation untersuchen: - Welche Benutzergruppen werden unterstützt? - Wo und wann arbeiten diese Benutzer? - Welche Geräte stehen ihnen zur Verfügung? - Welche Sprachen werden benötigt? - Welche technischen Fähigkeiten können vorausgesetzt werden? - Welche Services sind besonders kritisch? - Welche Anliegen treten häufig auf? - Welche Situationen benötigen sofortige menschliche Kommunikation? - Welche Anliegen lassen sich sicher standardisieren? - Welche gesetzlichen, vertraglichen oder betrieblichen Anforderungen gelten? - Welche Barrieren können Benutzer vom Kontakt abhalten? - Welche Kanäle können zuverlässig betrieben werden? Unterschiedliche Benutzergruppen können unterschiedliche Anforderungen besitzen. Beispiele: | Benutzergruppe | Mögliche Anforderungen | |---|---| | Büroarbeitsplätze | Portal, E-Mail, Chat und Telefon | | Produktionsmitarbeiter | leicht erreichbare Telefonnummer oder lokaler Kontakt | | Außendienst | mobile Erreichbarkeit und Self-Service | | Schichtbetrieb | erweiterte Support- oder Bereitschaftszeiten | | externe Kunden | klar getrenntes Kundenportal und vertraglich definierte Kanäle | | Führungskräfte | dieselben Prioritätsregeln, aber möglicherweise besondere Kommunikationsanforderungen | | Benutzer mit Einschränkungen | barrierearme Kanäle und alternative Kontaktmöglichkeiten | | internationale Benutzer | unterschiedliche Zeitzonen und Sprachen | | Administratoren | technischer Eskalations- und Sicherheitskanal | > **Grundsatz** > > Der bevorzugte Kanal der IT ist nicht automatisch der geeignete Kanal für alle Benutzer. --- **Single Point of Contact und mehrere Kanäle** Der Service Desk wird häufig als zentraler oder einzelner Kontaktpunkt beschrieben. Das bedeutet nicht zwingend, dass nur ein einziger Kanal erlaubt ist. Mehrere Kanäle können gemeinsam einen zentralen Kontaktpunkt bilden, wenn sie: - eindeutig zum selben Service Desk führen, - gemeinsame Informationen verwenden, - Kontakte nachvollziehbar zusammenführen, - einheitliche Prioritäts- und Eskalationsregeln anwenden, - und konsistente Statusinformationen liefern. Beispiel: Ein Benutzer kann den Service Desk erreichen über: - Portal, - Telefon, - E-Mail, - oder Chat. Alle Kontakte werden jedoch: - im selben Vorgangssystem dokumentiert, - auf mögliche Duplikate geprüft, - nach denselben Kriterien eingeordnet, - und mit einer gemeinsamen Statussicht bearbeitet. Problematisch wäre dagegen: - Portal-Tickets werden vom Service Desk bearbeitet. - E-Mails landen bei einzelnen Administratoren. - Chatkontakte werden nicht dokumentiert. - Telefonmeldungen befinden sich in privaten Notizen. - Vor-Ort-Anfragen werden gar nicht erfasst. > **Merke** > > Ein zentraler Kontaktpunkt ist eine organisatorische Fähigkeit und nicht nur eine einzelne Telefonnummer oder E-Mail-Adresse. --- **Mehrkanal und kanalübergreifende Bearbeitung** Eine Organisation kann mehrere Kanäle anbieten. Dabei sollte unterschieden werden zwischen: | Ansatz | Bedeutung | |---|---| | **Mehrkanalbetrieb** | mehrere Kanäle existieren nebeneinander | | **kanalübergreifende Bearbeitung** | Informationen und Bearbeitungsstand bleiben beim Kanalwechsel erhalten | | **einheitliche Serviceerfahrung** | Regeln, Sprache und Statusinformationen sind über die Kanäle hinweg abgestimmt | Beispiel einer schlechten kanalübergreifenden Erfahrung: 1. Benutzer meldet eine Störung per Chat. 2. Der Chat verweist auf eine Telefonnummer. 3. Am Telefon muss der Benutzer alles erneut erklären. 4. Später erhält er eine E-Mail mit einer neuen Ticketnummer. 5. Im Portal ist keiner der bisherigen Schritte sichtbar. Bessere Gestaltung: 1. Chat erfasst die ersten Informationen. 2. Ein Vorgang wird erstellt. 3. Beim Wechsel zum Telefon sieht der Mitarbeiter den bisherigen Verlauf. 4. Der Benutzer nennt nur noch die Vorgangsnummer oder wird sicher identifiziert. 5. Status und Ergebnis bleiben im Portal sichtbar. Die konkrete technische Umsetzung hängt von den verwendeten Werkzeugen ab. --- **Kanalwahl nach Art des Anliegens** Nicht jeder Kanal ist für jedes Anliegen gleich geeignet. | Anliegen | Häufig geeignete Kanäle | |---|---| | standardisierte Softwareanforderung | Self-Service-Portal | | planbarer Berechtigungsantrag | Portal mit strukturiertem Formular | | allgemeine Frage | Portal, Knowledge-Base, Chat oder E-Mail | | komplexe Störung mit Rückfragen | Telefon, Chat oder persönlicher Kontakt | | kritischer Serviceausfall | definierter dringender Meldeweg | | möglicher Sicherheitsvorfall | besonderer Sicherheitsmeldeweg | | Kennwort vergessen | sicherer Self-Service oder verifizierter Supportkontakt | | Statusabfrage | Portal oder automatische Benachrichtigung | | Feedback oder Beschwerde | Portal, Umfrage, E-Mail oder persönlicher Kontakt | | Ausfall des normalen Portals | alternativer Kontaktweg | Die Organisation sollte deutlich kommunizieren: - welche Kanäle existieren, - wofür sie gedacht sind, - wann sie bearbeitet werden, - und welcher Kanal bei dringenden Situationen verwendet werden muss. --- **Das Self-Service-Portal** Ein Self-Service-Portal kann Benutzer dabei unterstützen: - Incidents zu melden, - Service Requests auszuwählen, - Wissen zu durchsuchen, - Statusinformationen einzusehen, - Genehmigungen abzugeben, - Rückfragen zu beantworten, - und standardisierte Leistungen selbst auszuführen. Mögliche Vorteile: - strukturiertere Informationen, - rund um die Uhr mögliche Erfassung, - transparente Statussicht, - weniger Medienbrüche, - automatische Weiterleitung, - und Unterstützung standardisierter Wertströme. Mögliche Nachteile bei schlechter Gestaltung: - unverständliche Kategorien, - zu viele Formulare, - lange Pflichtfeldlisten, - technische Begriffe, - schlechte Suchfunktion, - fehlende mobile Nutzbarkeit, - kein erkennbarer Kontakt zu einem Menschen, - und hohe Abbruchquoten. > **Merke** > > Ein Portal ist kein Selbstzweck. > > Es muss den Benutzeraufwand reduzieren und die Bearbeitung verbessern. --- **Ein verständliches Portal gestalten** Ein Benutzer sollte möglichst nicht wissen müssen: - welches technische Team zuständig ist, - welche Datenbank betroffen sein könnte, - welche Practice verwendet wird, - oder welche interne Komponentenkategorie ausgewählt werden muss. Ungeeignete Auswahl: - Active Directory - Entra ID - LDAP - SAML - OIDC - RADIUS - PKI Verständlichere Auswahl: - Ich kann mich nicht anmelden. - Mein Konto ist gesperrt. - Die Mehrfaktor-Anmeldung funktioniert nicht. - Ich benötige einen neuen Zugriff. - Ich möchte ein Kennwort ändern. - Ich vermute einen unberechtigten Zugriff. Die technische Zuordnung kann anschließend: - durch Regeln, - durch den Service Desk, - oder durch geeignete Automatisierung erfolgen. --- **Formulare zweckmäßig gestalten** Ein Portalformular sollte nur Informationen verlangen, die für: - Einordnung, - Entscheidung, - Bearbeitung, - Kontrolle, - oder spätere Auswertung benötigt werden. Mögliche Gestaltungsmittel: - einfache Sprache, - kurze Hilfetexte, - Beispiele, - dynamisch eingeblendete Felder, - sinnvolle Standardwerte, - automatische Übernahme bekannter Benutzerdaten, - Auswahl verständlicher Services, - und sichtbare Angabe der erwarteten Bearbeitungszeit. Ungeeignete Pflichtfelder: - interne Supportgruppe, - vermutete technische Ursache, - interne CI-Kennung, - oder eine Priorität, deren Kriterien der Benutzer nicht kennt. Besser: - betroffener Service, - beobachtetes Symptom, - betroffene Personen oder Standorte, - benötigter Zeitpunkt, - und mögliche Auswirkungen. --- **Portal und Barrierefreiheit** Ein Portal sollte von möglichst vielen Benutzern selbstständig verwendet werden können. Zu berücksichtigen sind beispielsweise: - Tastaturbedienbarkeit, - verständliche Beschriftungen, - ausreichende Kontraste, - skalierbare Darstellung, - kompatible Formulare, - verständliche Fehlermeldungen, - keine ausschließliche Informationsvermittlung über Farbe, - alternative Texte für relevante grafische Inhalte, - und alternative Kontaktmöglichkeiten. Die konkreten verbindlichen Anforderungen hängen von Organisation, Land, Branche und Zielgruppe ab. > **Wichtig** > > Wenn ein Portal für einen Benutzer nicht nutzbar ist, muss ein angemessener alternativer Kontaktweg bestehen. --- **Telefonischer Kontakt** Telefon eignet sich besonders für: - dringende Situationen, - komplexe Fehlerbilder, - emotional belastende Incidents, - Rückfragen in Echtzeit, - und Benutzer, die keinen Zugang zum Portal besitzen. Mögliche Vorteile: - unmittelbare Interaktion, - schnelle Klärung, - bessere Wahrnehmung von Unsicherheit oder Dringlichkeit, - und direkte Anleitung. Mögliche Herausforderungen: - Wartezeiten, - eingeschränkte Nachvollziehbarkeit ohne Dokumentation, - Missverständnisse, - Sprachprobleme, - hoher Personalbedarf, - und fehlende Übertragung technischer Details. Der Service Desk sollte deshalb sicherstellen: - verständliche Begrüßung, - notwendige Identitätsprüfung, - strukturierte Erfassung, - Dokumentation während oder unmittelbar nach dem Gespräch, - realistische Statusaussagen, - und eindeutige nächste Schritte. --- **Telefonmenü und Warteschlange** Ein Telefonmenü kann Kontakte vorsortieren. Es sollte jedoch: - möglichst kurz, - verständlich, - aktuell, - und auf tatsächlich unterschiedliche Bearbeitungswege beschränkt sein. Ungeeignet: > Drücken Sie 1 für Incident Management, 2 für Service Request Management, 3 für Configuration Management. Benutzer kennen diese internen Begriffe möglicherweise nicht. Verständlicher: > Drücken Sie 1 bei einer aktuellen technischen Störung. > Drücken Sie 2 für eine Bestellung oder Zugriffsanfrage. > Drücken Sie 3 bei einer verdächtigen E-Mail oder einem möglichen Sicherheitsvorfall. Bei Warteschlangen können hilfreich sein: - ungefähre Warteinformation, - Rückrufmöglichkeit, - Hinweis auf geeigneten Self-Service, - und verständliche Ansage für dringende Notfälle. --- **E-Mail als Kontaktkanal** E-Mail ist leicht zugänglich und eignet sich unter anderem für: - weniger dringende Anliegen, - schriftliche Rückfragen, - Übermittlung strukturierter Informationen, - und Kommunikation mit externen Partnern. Mögliche Nachteile: - unvollständige Angaben, - uneindeutige Betreffzeilen, - lange E-Mail-Verläufe, - unkontrollierte Anhänge, - fehlende Prioritätsinformationen, - Duplikate, - und Sicherheitsrisiken. Eine Support-E-Mail-Adresse sollte möglichst: - automatisch eine Eingangsbestätigung senden, - eine Vorgangsnummer erzeugen, - keine privaten Postfächer verwenden, - regelmäßig überwacht werden, - und klare Hinweise zu Servicezeiten enthalten. > **Sicherheitsrelevant** > > E-Mail ist nicht für jede vertrauliche Information oder jeden Sicherheitsvorfall geeignet. > > Die Organisation muss zulässige Inhalte und alternative sichere Übertragungswege festlegen. --- **Gute Betreffzeilen und E-Mail-Inhalte** Ungeeigneter Betreff: > Hilfe!!! Besser: > Anmeldung am Zeiterfassungssystem nicht möglich – Standort Mitte Hilfreiche Angaben: - betroffener Benutzer, - betroffener Service, - beobachtetes Verhalten, - Fehlermeldung, - Beginn, - Auswirkung, - bereits durchgeführte Schritte, - und sichere Kontaktmöglichkeit. Der Service Desk sollte Benutzer nicht mit langen technischen Vorlagen überfordern. Kurze Hinweise oder automatische Fragen können die Qualität verbessern. --- **Chat und Instant Messaging** Chat eignet sich für: - kurze Rückfragen, - schnelle Orientierung, - begleitete Diagnose, - und weniger formelle Kommunikation. Mögliche Vorteile: - direkte schriftliche Kommunikation, - Übertragung kurzer technischer Informationen, - geringer Wechsel zwischen Arbeit und Support, - und parallele Bearbeitung mehrerer Kontakte. Mögliche Risiken: - unvollständige Dokumentation, - private Chats außerhalb des Supportsystems, - Erwartung sofortiger Antwort, - Übermittlung sensibler Inhalte, - und Verlust des Verlaufs. Geeignete Regeln: - offizieller Service-Desk-Chat statt privater Direktnachrichten, - Übernahme relevanter Informationen in den Vorgang, - klare Anzeige der Servicezeit, - sichere Identitätsprüfung bei kritischen Aktionen, - und Möglichkeit zur Eskalation an einen Menschen oder einen anderen Kanal. --- **Privatnachrichten an Administratoren** Direkte Nachrichten an bekannte Administratoren wirken für Benutzer häufig schnell. Sie erzeugen jedoch mögliche Probleme: - keine zentrale Übersicht, - unklare Priorisierung, - fehlende Vertretung, - Unterbrechung konzentrierter Arbeit, - keine dokumentierte Kommunikation, - und Abhängigkeit von einzelnen Personen. Eine professionelle Reaktion kann lauten: > Ich unterstütze gern. Bitte sende die Meldung über den Service-Desk-Kanal oder erlaube mir, daraus einen Vorgang zu erstellen. Dadurch bleibt die Bearbeitung auch bei meiner Abwesenheit nachvollziehbar. Bei kritischen Situationen sollte die Meldung nicht nur zurückgewiesen werden. Der Mitarbeiter sollte sicherstellen, dass: - der Vorgang erfasst, - richtig eskaliert, - und nicht durch die formale Kanalregel verzögert wird. --- **Virtuelle Agenten und Chatbots** Ein virtueller Agent kann Benutzer unterstützen bei: - häufigen Fragen, - Statusabfragen, - Auswahl eines Serviceangebots, - Erfassung strukturierter Angaben, - sicheren standardisierten Selbsthilfeschritten, - und Weiterleitung an einen Menschen. Mögliche Vorteile: - unmittelbare Unterstützung, - hohe Skalierbarkeit, - längere Erreichbarkeit, - und Entlastung bei wiederkehrenden Anliegen. Mögliche Risiken: - falsche Interpretation, - unpassende Antworten, - Schleifen ohne Lösung, - fehlende Transparenz, - unzureichende Barrierefreiheit, - und fehlender menschlicher Eskalationsweg. > **Grundsatz** > > Ein virtueller Agent sollte nicht vorgeben, ein Mensch zu sein. > > Benutzer sollten erkennen können, dass sie mit einem automatisierten System interagieren. --- **Menschliche Übergabe bei virtuellen Agenten** Ein Übergang zu einem Mitarbeiter sollte insbesondere möglich sein, wenn: - die Anfrage nicht verstanden wird, - mehrere Lösungsversuche scheitern, - die Situation kritisch ist, - Sicherheits- oder Datenschutzbezug besteht, - der Benutzer ausdrücklich menschliche Unterstützung benötigt, - oder der virtuelle Agent keine ausreichende Befugnis besitzt. Bei der Übergabe sollten bereits erfasste Informationen erhalten bleiben. Ungeeignet: 1. Benutzer beantwortet zehn Fragen im Chatbot. 2. Der Chatbot bietet eine Telefonnummer an. 3. Der Mitarbeiter sieht keine bisherigen Angaben. 4. Der Benutzer beginnt erneut. Besser: 1. Virtueller Agent erfasst grundlegende Angaben. 2. Ein Vorgang wird erzeugt. 3. Der Mitarbeiter erhält Verlauf und bisherige Ergebnisse. 4. Der Benutzer wird über die Übergabe informiert. --- **Mobile Anwendungen** Eine mobile Supportanwendung kann hilfreich sein für: - Außendienst, - mobile Mitarbeiter, - Produktionsumgebungen, - Push-Benachrichtigungen, - Statusabfragen, - und Erfassung von Fotos oder Gerätecodes. Zu berücksichtigen sind: - Authentifizierung, - Geräteverwaltung, - Datenschutz, - sichere Speicherung, - Offline-Verhalten, - Bedienbarkeit, - und Möglichkeit eines alternativen Kontaktwegs. Fotos und Anhänge sollten nur erfasst werden, wenn sie notwendig sind. Dabei können versehentlich sichtbar werden: - personenbezogene Daten, - Bildschirminhalte, - Zugangsinformationen, - Produktionsinformationen, - oder vertrauliche Dokumente. --- **Persönlicher Vor-Ort-Kontakt** Ein persönlicher Kontakt kann sinnvoll sein bei: - Hardwareproblemen, - komplexen Benutzerfragen, - Einarbeitung, - Arbeitsplätzen ohne digitalen Zugang, - und Situationen, in denen Beobachtung des tatsächlichen Arbeitsumfelds wichtig ist. Mögliche Modelle: - Walk-up Desk, - lokale Supportzeiten, - IT-Sprechstunde, - Terminvereinbarung, - oder gezielter Vor-Ort-Einsatz. Auch ein persönlicher Kontakt sollte nachvollziehbar dokumentiert werden, wenn: - eine Bearbeitung, - ein Asset-Wechsel, - eine Sicherheitsentscheidung, - ein Incident, - oder eine weitere Maßnahme entsteht. > **Typischer Fehler** > > Vor-Ort-Hilfe wird vollständig außerhalb des Service-Management-Systems durchgeführt. > > Dadurch bleiben Aufwand, wiederkehrende Probleme und wichtige Änderungen unsichtbar. --- **Walk-up Desk** Ein Walk-up Desk ist ein physischer Kontaktpunkt, an dem Benutzer persönlich Unterstützung erhalten. Mögliche Vorteile: - unmittelbare menschliche Hilfe, - gute Unterstützung bei Geräten, - geringe Hürde, - und bessere Wahrnehmung des Benutzerkontexts. Mögliche Herausforderungen: - Warteschlangen, - Unterbrechungen, - unklare Priorisierung, - nicht dokumentierte Tätigkeiten, - und Benutzer aus anderen Standorten werden benachteiligt. Zu klären sind: - Öffnungszeiten, - geeignete Anliegen, - Termin- oder Warteschlangenmodell, - Identitätsprüfung, - Umgang mit Geräten, - Dokumentation, - und Eskalation. --- **Automatisch erzeugte Kontakte** Nicht jeder Kontakt wird durch einen Menschen ausgelöst. Mögliche technische Quellen: - Monitoring, - Event-Management-System, - Endgeräteverwaltung, - Sicherheitsplattform, - Backup-System, - Cloud-Provider, - oder Integrationsschnittstelle. Solche Meldungen können automatisch: - ein Ticket, - ein Event, - einen Incident, - oder eine andere Arbeitsaufgabe erzeugen. Dabei muss geklärt sein: - Welche technische Meldung benötigt tatsächlich eine Handlung? - Wird bereits ein Vorgang bearbeitet? - Welche Priorität ist angemessen? - Wer besitzt die Verantwortung? - Wie werden Duplikate verhindert? - Wann müssen Benutzer informiert werden? > **Merke** > > Eine automatische Meldung ist nicht automatisch ein Incident. > > Sie muss entsprechend ihrer Bedeutung und Auswirkung eingeordnet werden. --- **Besondere Meldewege für Sicherheitsereignisse** Mögliche Sicherheitsereignisse benötigen häufig einen besonders definierten Meldeweg. Beispiele: - verdächtige E-Mail, - verlorenes Gerät, - möglicher unberechtigter Zugriff, - Schadsoftware, - versehentliche Datenoffenlegung, - oder verdächtiger Anruf. Der Meldeweg sollte: - leicht auffindbar, - schnell erreichbar, - sicher, - und den Benutzern bekannt sein. Zusätzlich ist festzulegen: - welche Informationen erfasst werden, - wer Zugriff auf die Meldung erhält, - wann das Sicherheitsteam eingebunden wird, - welche Kommunikation verwendet werden darf, - und wie Beweise geschützt werden. Ungeeignet wäre ein verstecktes Formular mit vielen technischen Pflichtfeldern. --- **Notfall- und Major-Incident-Kanäle** Für besonders kritische Incidents kann ein eigener dringender Meldeweg sinnvoll sein. Dieser darf nicht zur allgemeinen Beschleunigung normaler Anliegen missbraucht werden. Mögliche Regeln: - Welche Kriterien rechtfertigen den Kanal? - Wer darf ihn verwenden? - Welche Services sind umfasst? - Welche Informationen müssen genannt werden? - Wer nimmt die Meldung entgegen? - Wie wird der Major-Incident-Prozess aktiviert? - Wie wird die Kommunikation koordiniert? - Was geschieht bei Fehlalarm? Beispiel: Ein Portalhinweis kann lauten: > Bei vollständigem Ausfall eines kritischen Produktionsservice außerhalb der Service-Desk-Zeit verwenden Sie die Bereitschaftsnummer. Normale Bestellungen und Einzelplatzprobleme werden am nächsten Arbeitstag bearbeitet. --- **Alternative Kanäle bei Ausfall des Service Desk** Der normale Kontaktweg kann selbst ausfallen. Beispiele: - Ticketsystem nicht erreichbar, - E-Mail-Service gestört, - Telefonanlage ausgefallen, - Identitätsdienst verhindert Portalzugriff, - oder Standortverbindung unterbrochen. Deshalb sollte ein alternativer Meldeweg vorbereitet sein. Mögliche Alternativen: - externe Statusseite, - separate Notfallnummer, - unabhängige Mobilfunknummer, - alternativer Kommunikationsdienst, - definierter lokaler Ansprechpartner, - oder Providerkontakt. Der alternative Kanal sollte nicht von derselben ausgefallenen Komponente abhängen. > **Praxistipp** > > Die Notfallkontaktinformationen sollten auch verfügbar sein, wenn das interne Netzwerk, das Portal oder das Identitätssystem nicht funktioniert. --- **Statusseite** Eine Statusseite kann Benutzer über bekannte Störungen, Wartungen und Wiederherstellungen informieren. Mögliche Inhalte: - betroffener Service, - Beginn, - bekannte Auswirkung, - aktueller Status, - Zwischenlösung, - nächstes Update, - und Abschlussinformation. Vorteile: - weniger Mehrfachmeldungen, - konsistente Kommunikation, - geringerer Benutzeraufwand, - und Entlastung des Service Desk. Zu berücksichtigen sind: - Zielgruppe, - Zugriffsrechte, - vertrauliche Informationen, - Verantwortlichkeit für Aktualisierungen, - und technische Unabhängigkeit von betroffenen Services. Eine externe Statusseite darf keine sicherheitskritischen internen Details offenlegen. --- **Servicezeiten bestimmen** Servicezeiten sollten sich an den benötigten Outcomes und Risiken orientieren. Zu untersuchen sind: - Betriebszeiten wichtiger Services, - Arbeitszeiten der Benutzer, - internationale Zeitzonen, - Schichtbetrieb, - vertragliche Vereinbarungen, - saisonale Spitzen, - Sicherheitsanforderungen, - und verfügbare Bereitschaft. Mögliche Modelle: - normale Geschäftszeiten, - erweiterte Servicezeiten, - 24×5, - 24×7, - Bereitschaft für kritische Services, - oder unterschiedliche Zeiten nach Serviceklasse. > **Wichtig** > > Eine längere Servicezeit benötigt nicht nur einen zusätzlichen Telefonanschluss. > > Sie benötigt Personal, Wissen, Befugnisse, Werkzeuge, Eskalationswege und erreichbare Lieferanten. --- **Erreichbarkeit außerhalb der Servicezeit** Außerhalb der regulären Servicezeit sollte klar sein: - Welche Anliegen werden bearbeitet? - Welcher Kanal gilt? - Wer reagiert? - Welche Zielzeiten gelten? - Welche Befugnisse besitzt die Bereitschaft? - Welche Fachteams können erreicht werden? - Welche Lieferanten stehen zur Verfügung? - Wie erfolgt die Übergabe an den regulären Service Desk? Mögliche Ansage: > Der reguläre Service Desk ist derzeit geschlossen. Kritische Ausfälle der Produktionsservices können über die Bereitschaftsnummer gemeldet werden. Alle anderen Anliegen können im Portal erfasst werden und werden ab 08:00 Uhr bearbeitet. --- **Bereitschaft und Rufbereitschaft** Eine Bereitschaftsregelung sollte mindestens klären: - betroffene Services, - Aktivierungsbedingungen, - erreichbare Rollen, - Reaktionspflichten, - Entscheidungsbefugnisse, - technische Zugänge, - Dokumentation, - Vertretung, - und Übergabe. Problematisch sind informelle Regelungen wie: > Rufen Sie einfach jemanden aus der IT an. Dies führt zu: - unklarer Verantwortung, - persönlicher Überlastung, - fehlender Vertretung, - und nicht nachvollziehbaren Entscheidungen. --- **Follow-the-Sun** Bei internationalem Betrieb können Teams in verschiedenen Zeitzonen nacheinander übernehmen. Voraussetzungen: - einheitliche Dokumentation, - gemeinsame Werkzeuge, - klare Ownership-Regeln, - definierte Übergaben, - ausreichende Sprachkenntnisse, - gleiche Zugriffsmöglichkeiten, - und abgestimmte Prioritätskriterien. Eine Übergabe sollte enthalten: - aktueller Status, - bisherige Maßnahmen, - offene Hypothesen, - nächste Schritte, - Risiken, - erwartete Entscheidungen, - und geplante Kommunikation. > **Typischer Fehler** > > Der Vorgang wird am Schichtende nur einer anderen Gruppe zugewiesen, ohne dass Kontext und Verantwortung geklärt sind. --- **Sprachliche Erreichbarkeit** Bei mehrsprachigen Benutzergruppen ist zu klären: - Welche Sprachen werden direkt unterstützt? - Welche Servicezeiten gelten je Sprache? - Können Übersetzungswerkzeuge verwendet werden? - Wie werden technische Begriffe einheitlich übersetzt? - Wie werden Missverständnisse erkannt? - Welche Sprache gilt für Dokumentation und Lieferanteneskalation? Automatische Übersetzung kann unterstützen. Kritische Informationen sollten jedoch überprüft werden, insbesondere bei: - Sicherheitsvorfällen, - rechtlichen Aussagen, - technischen Anweisungen, - und möglichen Datenverlusten. --- **Erreichbarkeit für externe Benutzer** Externe Kunden, Partner oder Lieferanten benötigen möglicherweise andere Kanäle als interne Mitarbeiter. Zu berücksichtigen sind: - Authentifizierung, - Vertragsbezug, - Mandantentrennung, - Datenschutz, - zulässige Informationen, - Servicezeiten, - Eskalation, - und unterschiedliche Serviceziele. Ein externer Benutzer sollte nicht auf interne Portale oder Kommunikationskanäle zugreifen müssen, für die er keine Berechtigung besitzt. --- **Identitätsprüfung je Kanal** Nicht jede Anfrage benötigt dieselbe Identitätsprüfung. Der Umfang sollte sich nach Risiko und verlangter Handlung richten. Beispiele: | Handlung | Mögliche Anforderung | |---|---| | allgemeine Serviceinformation | möglicherweise keine besondere Prüfung | | Status eines eigenen Tickets | sichere Anmeldung oder Vorgangsprüfung | | Kennwort zurücksetzen | festgelegtes starkes Identitätsverfahren | | Berechtigung ändern | Identitäts- und Genehmigungsprüfung | | vertrauliche Daten übermitteln | geschützter Kanal | | administrativen Zugriff aktivieren | besonders starke Prüfung und Autorisierung | > **Sicherheitsrelevant** > > Telefonnummer, Absenderadresse oder angezeigter Name allein beweisen nicht zuverlässig die Identität einer Person. --- **Social Engineering berücksichtigen** Kontaktkanäle können durch Angreifer ausgenutzt werden. Typische Warnzeichen: - außergewöhnlicher Zeitdruck, - Berufung auf hohe Hierarchie, - Bitte um Umgehung des üblichen Verfahrens, - Zurücksetzung eines fremden Kontos, - Änderung von Kontaktdaten vor einer Sicherheitsaktion, - Übermittlung unbekannter Links oder Dateien, - oder Forderung nach vertraulichen Informationen. Mitarbeiter benötigen: - klare Verfahren, - Schulung, - Eskalationsmöglichkeiten, - und Unterstützung durch Führungskräfte. > **Grundsatz** > > Gute Erreichbarkeit darf nicht auf Kosten von Identitätsprüfung und Informationssicherheit entstehen. --- **Kapazitätsplanung für Kontaktkanäle** Ein Kanal ist nur dann zuverlässig, wenn ausreichende Kapazität vorhanden ist. Zu berücksichtigen sind: - Anzahl der Kontakte, - zeitliche Verteilung, - durchschnittliche Bearbeitungsdauer, - saisonale Spitzen, - Ausfälle größerer Services, - Personalverfügbarkeit, - Sprachen, - und Komplexität der Anliegen. Beispiele für Spitzen: - Montagmorgen, - Beginn einer Schicht, - nach einem großen Release, - nach Kennwortänderungen, - bei neuen Mitarbeitereintrittsterminen, - oder während eines Major Incidents. Mögliche Maßnahmen: - Rückrufoption, - zusätzliche Besetzung, - sichtbare Statusmeldung, - vorbereitete Störungsansage, - Self-Service für geeignete Anliegen, - und automatische Zusammenführung von Mehrfachmeldungen. --- **Warteschlangen steuern** Eine Warteschlange sollte nicht nur die Reihenfolge nach Eingangszeit berücksichtigen. Abhängig vom Kanal können relevant sein: - Priorität, - Auswirkungen, - Sicherheitsbezug, - Serviceklasse, - bereits verstrichene Zeit, - Sprachbedarf, - und benötigte Fähigkeiten. Benutzer sollten möglichst erkennen können: - dass ihre Meldung eingegangen ist, - ob weitere Informationen benötigt werden, - wie der nächste Schritt aussieht, - und wann ungefähr eine Reaktion erfolgt. --- **Überlauf und Ausweichregelungen** Bei ungewöhnlich hoher Nachfrage können Ausweichregeln notwendig sein. Beispiele: - zusätzliche interne Mitarbeiter unterstützen vorübergehend, - nichtkritische Kontakte werden zurückgerufen, - bekannte Störung wird zentral kommuniziert, - Lieferanten übernehmen vereinbarte Teile, - oder automatisierte Statusinformationen reduzieren Nachfragen. Zu vermeiden ist: - spontane Weitergabe ohne Zugriffsrechte, - Einsatz ungeschulter Personen bei sicherheitskritischen Anliegen, - und Verlust der Dokumentation. --- **Kontaktkanäle und Service Levels** Serviceziele können je Kanal und Anliegen unterschiedlich sein. Beispiele: - Telefon: kurze Annahmezeit für kritische Incidents - Portal: Eingangsbestätigung unmittelbar - E-Mail: qualifizierte Reaktion innerhalb der Servicezeit - Chat: Reaktion nur während angezeigter Verfügbarkeit - Bereitschaft: definierte Reaktion bei kritischen Services Die Ziele sollten: - verständlich, - messbar, - realistisch, - und mit ausreichenden Ressourcen unterstützt sein. Eine sehr kurze Reaktionszeit besitzt wenig Wert, wenn die erste Antwort nur lautet: > Ihr Ticket wurde erhalten. Zusätzlich sollte geprüft werden, wann: - eine qualifizierte Bearbeitung, - eine sinnvolle Statusinformation, - oder eine Wiederherstellung erfolgt. --- **Erreichbarkeit messen** Mögliche Kennzahlen: | Kennzahl | Mögliche Aussage | |---|---| | Erreichbarkeitsquote Telefon | Anteil angenommener Anrufe | | durchschnittliche Wartezeit | Zeit bis zur Annahme | | Abbruchquote | Anteil beendeter Kontakte vor Annahme | | Rückrufzeit | Zeit bis zum zugesagten Rückruf | | erste qualifizierte Reaktionszeit | Zeit bis zu einer verwertbaren Antwort | | Portal-Abbruchquote | Anteil nicht abgeschlossener Formulare | | Chat-Übertragungsquote | Anteil der Kontakte mit menschlicher Übergabe | | Kanalwechselquote | Anteil der Fälle, die einen weiteren Kanal benötigen | | Wiederholungskontakte | erneute Meldung zum selben Anliegen | | Self-Service-Erfolgsquote | erfolgreich ohne Service-Desk-Kontakt erledigte geeignete Anliegen | | Kontakte außerhalb Servicezeit | Hinweise auf unpassende Servicezeiten | | falsch gewählter Kanal | Hinweise auf unklare Kommunikation | | Benutzeraufwand | Anzahl notwendiger Kontakte oder Wiederholungen | Keine einzelne Kennzahl beschreibt die tatsächliche Erreichbarkeit vollständig. --- **Abbruchquote richtig einordnen** Eine hohe Abbruchquote kann entstehen durch: - lange Wartezeit, - technische Probleme, - unverständliches Telefonmenü, - Benutzer findet inzwischen eine Lösung, - oder parallele Nutzung eines anderen Kanals. Eine niedrige Abbruchquote beweist nicht automatisch gute Erreichbarkeit. Möglicherweise: - werden Anrufe schnell angenommen, aber schlecht bearbeitet, - Benutzer verwenden den Kanal gar nicht mehr, - oder kritische Gruppen können ihn nicht nutzen. Kennzahlen müssen deshalb gemeinsam mit: - Benutzerfeedback, - Lösungsqualität, - Kontaktvolumen, - und tatsächlichen Outcomes betrachtet werden. --- **First Contact Resolution nach Kanal** First Contact Resolution kann je Kanal unterschiedlich bewertet werden. Beispiele: - Chatbot beantwortet eine Statusfrage vollständig. - Portal führt einen sicheren Kennwort-Reset aus. - Telefonischer Mitarbeiter löst eine bekannte Störung. - E-Mail liefert eine verständliche und erfolgreiche Anleitung. Dabei muss geprüft werden: - War das Anliegen tatsächlich gelöst? - Wurde das Ergebnis bestätigt? - Musste der Benutzer einen weiteren Kanal verwenden? - Wurden Sicherheitsregeln eingehalten? - Wurde nur das Ticket geschlossen oder das Outcome erreicht? --- **Self-Service-Erfolg richtig messen** Unzureichende Kennzahl: > Anzahl der Portalaufrufe Hilfreichere Fragen: - Finden Benutzer das passende Angebot? - Werden Formulare vollständig abgeschlossen? - Wird das Anliegen ohne weiteren Kontakt erledigt? - Sind die Ergebnisse korrekt? - Wie häufig wechseln Benutzer zum Telefon? - Welche Suchbegriffe liefern keine Ergebnisse? - Wo brechen Benutzer ab? - Welche Fehler verursachen neue Tickets? > **Merke** > > Ein Benutzer, der nach mehreren erfolglosen Self-Service-Versuchen anruft, hat mehr und nicht weniger Aufwand erlebt. --- **Kanalqualität regelmäßig überprüfen** Kontaktkanäle verändern sich durch: - neue Benutzergruppen, - neue Technologien, - veränderte Arbeitszeiten, - steigende Kontaktmengen, - neue Sicherheitsrisiken, - und Feedback. Regelmäßig zu prüfen sind: - Werden alle Kanäle noch benötigt? - Sind Servicezeiten passend? - Sind Inhalte und Ansagen aktuell? - Werden Kontakte zuverlässig zusammengeführt? - Funktionieren Übergaben? - Gibt es ungenutzte oder überlastete Kanäle? - Bestehen unnötige parallele Wege? - Sind alternative Kanäle vorbereitet? - Ist die Benutzererfahrung verständlich? - Sind Sicherheitsmaßnahmen ausreichend? --- **Kanäle nicht nur hinzufügen, sondern auch entfernen** Neue Kanäle werden häufig schnell ergänzt. Alte Kanäle bleiben jedoch bestehen. Dadurch können entstehen: - unklare Auswahl, - veraltete Adressen, - schlecht überwachte Postfächer, - widersprüchliche Informationen, - und zusätzlicher Betriebsaufwand. Vor der Abschaltung eines Kanals sollte geprüft werden: - Wer verwendet ihn? - Welche Benutzergruppe wäre betroffen? - Welche Alternative besteht? - Wie wird die Änderung kommuniziert? - Müssen Weiterleitungen eingerichtet werden? - Gibt es vertragliche oder betriebliche Anforderungen? - Wie lange bleibt ein Übergangszeitraum bestehen? --- **Einführung eines neuen Kanals** Eine mögliche Vorgehensweise: 1. Benutzerbedarf und Problem beschreiben 2. geeignete Anwendungsfälle festlegen 3. Sicherheits- und Datenschutzanforderungen prüfen 4. Verantwortlichkeit bestimmen 5. technische Integration planen 6. Servicezeiten und Kapazität festlegen 7. Pilotgruppe auswählen 8. Erfolgskriterien definieren 9. Mitarbeiter und Benutzer informieren 10. Ergebnisse messen 11. Kanal anpassen oder ausweiten 12. bestehende Kanäle erneut bewerten Beispiel: Ein Chatkanal sollte nicht nur deshalb eingeführt werden, weil die verwendete Plattform diese Funktion anbietet. Zu prüfen ist: - Welche Anliegen sollen über Chat laufen? - Wer besetzt ihn? - Wird der Verlauf dokumentiert? - Wie erfolgt die Identitätsprüfung? - Wie wird an Fachteams übergeben? - Wann wird der Chat geschlossen? - Wie wird eine hohe gleichzeitige Nachfrage behandelt? --- **Kontaktkanäle bei einem Major Incident** Während eines Major Incidents kann das Kontaktvolumen stark steigen. Geeignete Maßnahmen: - bekannte Störung sichtbar veröffentlichen, - automatische Ansage aktualisieren, - identische Meldungen verknüpfen, - Service-Desk-Mitarbeitern freigegebene Statusinformationen bereitstellen, - klaren Aktualisierungsrhythmus festlegen, - und einen separaten technischen Koordinationskanal verwenden. Benutzerkanal und technischer Koordinationskanal sollten unterschieden werden. **Benutzerkanal** - verständliche Statusinformation - Auswirkungen - Zwischenlösung - nächste Aktualisierung **Technischer Koordinationskanal** - Diagnose, - Hypothesen, - technische Maßnahmen, - Entscheidungen, - Risiken, - und Verantwortlichkeiten Technische interne Diskussionen sollten nicht ungefiltert in öffentliche Statusmeldungen übernommen werden. --- **Kontaktkanäle bei Sicherheitsvorfällen** Bei einem möglichen Sicherheitsvorfall können zusätzliche Anforderungen gelten. Beispiele: - vertrauliche Behandlung, - begrenzter Zugriff, - Beweissicherung, - keine öffentliche Statusmeldung, - definierte Meldepflichten, - und besonders kontrollierte Kommunikation. Der normale Service Desk kann den ersten Kontakt aufnehmen. Er muss jedoch wissen: - wann das Sicherheitsteam einzubinden ist, - welche Informationen nicht verändert werden dürfen, - welche Kanäle zulässig sind, - und welche Aussagen vermieden werden müssen. --- **Kontaktkanäle bei Service Requests** Standardisierte Service Requests eignen sich häufig gut für Portale und Automatisierung. Beispiele: - Standardsoftware anfordern, - Gruppenmitgliedschaft beantragen, - neues Zubehör bestellen, - Verteilerliste ändern, - oder Arbeitsplatzwechsel melden. Ein gutes Request-Formular kann: - benötigte Informationen erfassen, - Genehmigung automatisch anstoßen, - den Status sichtbar machen, - und standardisierte Erfüllung auslösen. Der Benutzer sollte erkennen können: - welche Voraussetzungen gelten, - welche Kosten entstehen können, - welche Genehmigung benötigt wird, - und welche Bereitstellungszeit zu erwarten ist. --- **Kontaktkanäle beim Onboarding** Beim Onboarding entstehen häufig mehrere Kontakte: - Personalabteilung meldet den Eintritt. - Führungskraft nennt Rolle und Zugriffe. - Einkauf oder Asset Management stellt Geräte bereit. - neuer Mitarbeiter erhält Informationen. - Service Desk unterstützt bei der ersten Nutzung. Ein zentraler digitaler Einstieg kann helfen, Informationen einmalig und strukturiert zu erfassen. Dabei muss geklärt sein: - Wer darf den Eintritt melden? - Welche Daten werden benötigt? - Welche Freigaben gelten? - Wie wird der Status sichtbar? - Wie erhält der neue Mitarbeiter Unterstützung, wenn das Konto noch nicht funktioniert? Der letzte Punkt ist besonders wichtig. Ein ausschließlich internes Portal ist möglicherweise nicht nutzbar, wenn der Benutzer noch keinen funktionierenden Zugang besitzt. --- **Praxisbeispiel: Portal wird kaum verwendet** **Beobachtung** - Benutzer rufen fast immer an. - Das Portal besitzt viele Formulare. - Suchbegriffe führen zu unpassenden Ergebnissen. - Benutzer kennen die Bearbeitungszeiten nicht. **Ungeeignete Reaktion** > Ab nächster Woche werden telefonische Anfragen nicht mehr angenommen. **Bessere Untersuchung** - Welche Anliegen werden telefonisch gemeldet? - Können Benutzer die passenden Portalangebote finden? - Welche Formulare werden abgebrochen? - Sind technische Begriffe verständlich? - Funktioniert die Anmeldung zuverlässig? - Ist das Portal mobil verwendbar? - Gibt es einen menschlichen Ausweichweg? - Welchen Nutzen besitzt das Portal für den Benutzer? **Mögliche Verbesserungen** - häufige Angebote hervorheben, - Begriffe vereinfachen, - Formulare kürzen, - Suche verbessern, - Statusinformationen ergänzen, - Anmeldung vereinfachen, - und Portal gemeinsam mit Benutzern testen. --- **Praxisbeispiel: Zu viele E-Mail-Tickets** **Beobachtung** - Viele E-Mails besitzen keinen eindeutigen Betreff. - notwendige Informationen fehlen. - mehrere Personen antworten parallel. - Anhänge enthalten sensible Daten. **Mögliche Verbesserungen** - automatische Eingangsbestätigung, - kurze Hinweise zu benötigten Angaben, - sichere Uploadmöglichkeit, - automatische Verknüpfung mit bestehenden Vorgängen, - verständliches Portal als Alternative, - und Schulung des Service Desk zur Nachqualifizierung. E-Mail muss nicht zwingend abgeschafft werden. Sie kann für bestimmte Benutzergruppen weiterhin ein sinnvoller Kanal sein. --- **Praxisbeispiel: Support außerhalb der Geschäftszeit** **Ausgangslage** - Produktionsservice läuft rund um die Uhr. - Service Desk arbeitet von 08:00 bis 18:00 Uhr. - Nachts rufen Benutzer private Telefonnummern von Administratoren an. **Möglicher Zielzustand** - definierte Bereitschaftsnummer, - klare Kriterien für kritische Meldungen, - erreichbarer Incident-Koordinator, - aktueller Dienstplan, - dokumentierte Übergabe, - und Portal für nichtkritische Anliegen. **Zusätzlich zu klären** - Welche technischen Teams müssen erreichbar sein? - Welche Lieferanten bieten Nachtsupport? - Welche Maßnahmen darf die Bereitschaft durchführen? - Wer darf risikobehaftete Entscheidungen treffen? - Wie erfolgt die Information der regulären Teams? --- **Praxisbeispiel: Virtueller Agent blockiert Benutzer** **Ausgangslage** - Chatbot beantwortet Standardfragen. - Benutzer kann keinen Mitarbeiter auswählen. - Nach drei nicht passenden Antworten beginnt der Dialog erneut. - Benutzer ruft anschließend verärgert an. **Mögliche Verbesserungen** - menschliche Übergabe sichtbar anbieten, - bisherigen Verlauf übertragen, - Abbruchgründe analysieren, - Wissensquellen verbessern, - ungeeignete Anwendungsfälle entfernen, - und kritische Begriffe sofort eskalieren. > **Merke** > > Automatisierung soll einen Kontakt vereinfachen und nicht als Barriere vor menschlicher Unterstützung dienen. --- **Praxisbeispiel: Ticketsystem fällt aus** **Situation** - Service-Desk-Portal und Ticketsystem sind nicht erreichbar. - E-Mail-Tickets können ebenfalls nicht verarbeitet werden. - Benutzer benötigen weiterhin einen Meldeweg. **Vorbereitete Lösung** - unabhängige Notfallnummer, - vorübergehende gesicherte Erfassung, - externe Statusseite, - definierte Priorisierung, - und spätere Übernahme der Notfallvorgänge in das Ticketsystem. Zu vermeiden: - private Notizzettel ohne spätere Übernahme, - unkontrollierte Chatgruppen, - und Veröffentlichung interner technischer Details. --- **Typische Fehler bei Kontaktkanälen** **Fehler 1: Möglichst viele Kanäle anbieten** Die Organisation kann sie nicht zuverlässig überwachen und zusammenführen. --- **Fehler 2: Portalzwang ohne geeignete Alternative** Komplexe, dringende oder barrierebedingte Situationen werden nicht berücksichtigt. --- **Fehler 3: Technische Verfügbarkeit mit Supportzeit verwechseln** Benutzer erwarten sofortige Bearbeitung, obwohl nur eine automatische Erfassung erfolgt. --- **Fehler 4: Private Supportkanäle dulden** Meldungen verschwinden in persönlichen Chats, Postfächern oder Telefonlisten. --- **Fehler 5: Benutzer müssen das technische Team auswählen** Falsche Zuordnungen und unnötige Weiterleitungen entstehen. --- **Fehler 6: Kritische und normale Anliegen verwenden denselben unpriorisierten Kanal** Dringende Meldungen werden möglicherweise zu spät erkannt. --- **Fehler 7: Kein alternativer Kanal** Beim Ausfall von Portal, E-Mail oder Identitätsdienst ist der Service Desk nicht erreichbar. --- **Fehler 8: Virtueller Agent ohne menschlichen Ausweg** Benutzer bleiben in automatisierten Antwortschleifen. --- **Fehler 9: Kanäle werden nicht sicher gestaltet** Identitätsprüfung, Datenschutz und vertrauliche Kommunikation fehlen. --- **Fehler 10: Servicezeiten sind nicht sichtbar** Benutzer wissen nicht, wann mit einer Reaktion zu rechnen ist. --- **Fehler 11: Kanalwechsel verliert den Kontext** Benutzer müssen ihre Situation mehrfach erklären. --- **Fehler 12: Self-Service nur zur Kostensenkung** Benutzeraufwand und Abbruchquote steigen. --- **Fehler 13: Statusseite wird nicht aktualisiert** Veraltete Informationen beschädigen das Vertrauen. --- **Fehler 14: Bereitschaft ist nur informell geregelt** Einzelne Mitarbeiter werden unkoordiniert und ohne Vertretung kontaktiert. --- **Fehler 15: Kennzahlen werden isoliert optimiert** Kurze Wartezeiten werden erreicht, während Lösungsqualität und Benutzererfahrung sinken. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten häufig in Service Desk, Betrieb oder nachgelagerten Supportgruppen. Sie sollten die vorgesehenen Kontaktwege kennen und unterstützen. Wichtige Verhaltensweisen: - private Meldungen in den offiziellen Wertstrom überführen, - kritische Anliegen nicht wegen eines falschen Kanals ignorieren, - technische Rückmeldungen im zentralen Vorgang dokumentieren, - Benutzer nicht unnötig an einen weiteren Kanal verweisen, - alternative Meldewege bei Ausfällen kennen, - Sicherheitsverfahren einhalten, - und Statusinformationen an den Service Desk zurückgeben. Beispiel: Ein Benutzer schreibt einem Administrator direkt: > Der Fileserver geht nicht. Ungeeignet: > Dafür bin ich nicht zuständig. Eröffnen Sie ein Ticket. Besser: > Ich erfasse die Meldung im Service Desk, damit sie nachvollziehbar bearbeitet wird. Können Sie mir kurz sagen, ob nur Sie oder weitere Benutzer betroffen sind? Anschließend: - Vorgang erstellen, - Auswirkung prüfen, - zuständige Bearbeitung einbinden, - und Benutzer über den nächsten Schritt informieren. --- **30-Sekunden-Prüfung eines Kontaktkanals** 1. **Zielgruppe:** Wer soll den Kanal verwenden? 2. **Anliegen:** Für welche Kontakte ist er geeignet? 3. **Servicezeit:** Wann wird er tatsächlich bearbeitet? 4. **Verantwortung:** Wer überwacht den Kanal? 5. **Integration:** Werden Kontakte zentral dokumentiert? 6. **Sicherheit:** Wie werden Identität und Informationen geschützt? 7. **Barrierefreiheit:** Können die vorgesehenen Benutzer den Kanal verwenden? 8. **Eskalation:** Wie gelangen kritische Anliegen schnell zur richtigen Stelle? 9. **Alternative:** Was geschieht bei Ausfall des Kanals? 10. **Übergabe:** Bleiben Informationen bei einem Kanalwechsel erhalten? 11. **Messung:** Wie wird die Wirksamkeit überprüft? 12. **Verbesserung:** Wie wird Benutzerfeedback verwendet? --- **Checkliste für ein Self-Service-Portal** - [ ] Sind häufige Anliegen leicht auffindbar? - [ ] Werden verständliche Begriffe verwendet? - [ ] Müssen Benutzer keine internen Teams oder Practices kennen? - [ ] Sind Formulare so kurz wie möglich? - [ ] Werden nur notwendige Informationen verlangt? - [ ] Sind Servicezeiten und erwartete Bearbeitungszeiten sichtbar? - [ ] Ist der Status eines Vorgangs nachvollziehbar? - [ ] Funktioniert das Portal auf benötigten Geräten? - [ ] Sind barrierearme Nutzung und Alternativen berücksichtigt? - [ ] Ist ein menschlicher Kontaktweg sichtbar? - [ ] Werden Sicherheits- und Datenschutzanforderungen eingehalten? - [ ] Werden Suchbegriffe, Abbrüche und Feedback ausgewertet? --- **Checkliste für telefonischen Support** - [ ] Ist die Nummer leicht auffindbar? - [ ] Sind Servicezeiten veröffentlicht? - [ ] Ist die Ansage verständlich und aktuell? - [ ] Ist das Telefonmenü möglichst kurz? - [ ] Besteht eine Regel für kritische Incidents? - [ ] Werden Kontakte zentral dokumentiert? - [ ] Ist die Identitätsprüfung risikogerecht? - [ ] Bestehen Rückruf- oder Überlaufmöglichkeiten? - [ ] Sind Wartezeiten und Abbruchquoten bekannt? - [ ] Ist eine Vertretung bei Ausfall der Telefonanlage vorbereitet? --- **Checkliste für E-Mail-Support** - [ ] Wird ein gemeinsames statt eines privaten Postfachs verwendet? - [ ] Erfolgt eine automatische Eingangsbestätigung? - [ ] Wird eine Vorgangsnummer erzeugt? - [ ] Sind Servicezeiten und dringende Alternativen angegeben? - [ ] Werden Anhänge sicher verarbeitet? - [ ] Sind Regeln für vertrauliche Informationen vorhanden? - [ ] Werden E-Mail-Verläufe dem richtigen Vorgang zugeordnet? - [ ] Werden Duplikate erkannt? - [ ] Ist der Kanal regelmäßig überwacht? - [ ] Werden unvollständige Meldungen strukturiert nachqualifiziert? --- **Checkliste für Chat und virtuelle Agenten** - [ ] Ist erkennbar, ob ein Mensch oder ein automatisiertes System antwortet? - [ ] Sind die Servicezeiten sichtbar? - [ ] Wird der Verlauf dokumentiert? - [ ] Können Vorgänge automatisch erzeugt werden? - [ ] Besteht ein klarer Übergang zu einem Menschen? - [ ] Bleiben Informationen bei der Übergabe erhalten? - [ ] Werden kritische und sicherheitsbezogene Begriffe erkannt? - [ ] Ist die Identitätsprüfung für sensible Aktionen ausreichend? - [ ] Werden Fehlantworten und Abbrüche ausgewertet? - [ ] Werden Benutzer nicht in Antwortschleifen festgehalten? --- **Checkliste für Erreichbarkeit außerhalb der Servicezeit** - [ ] Ist bekannt, welche Services kritisch sind? - [ ] Sind Aktivierungskriterien für die Bereitschaft definiert? - [ ] Ist der Meldeweg veröffentlicht? - [ ] Ist ein aktueller Dienstplan vorhanden? - [ ] Besitzen Bereitschaftskräfte notwendige Zugänge und Befugnisse? - [ ] Sind technische Eskalationswege bekannt? - [ ] Sind Lieferanten außerhalb der Geschäftszeit erreichbar? - [ ] Besteht ein alternativer Kanal bei Systemausfall? - [ ] Werden alle Maßnahmen dokumentiert? - [ ] Ist die Übergabe an den regulären Service Desk geregelt? --- **Checkliste für die gesamte Kanalstrategie** - [ ] Sind Benutzergruppen und ihre Arbeitsbedingungen bekannt? - [ ] Sind geeignete Kanäle für unterschiedliche Anliegen definiert? - [ ] Werden alle Kanäle zuverlässig überwacht? - [ ] Werden Kontakte in einer gemeinsamen Sicht zusammengeführt? - [ ] Sind Servicezeiten eindeutig veröffentlicht? - [ ] Sind kritische und normale Anliegen unterscheidbar? - [ ] Sind Sicherheits- und Datenschutzanforderungen berücksichtigt? - [ ] Bestehen barrierearme und alternative Kontaktmöglichkeiten? - [ ] Bleibt der Kontext bei Kanalwechseln erhalten? - [ ] Ist der Service Desk auch bei Ausfall zentraler Systeme erreichbar? - [ ] Sind Kapazität und Bereitschaft ausreichend? - [ ] Sind Statusinformationen konsistent? - [ ] Werden Kennzahlen und Benutzerfeedback gemeinsam ausgewertet? - [ ] Werden ungenutzte oder ungeeignete Kanäle entfernt? - [ ] Fließen Erkenntnisse in Continual Improvement ein? --- **Schnellreferenz** | Kanal | Besonders geeignet für | Besonders zu beachten | |---|---|---| | **Portal** | strukturierte Incidents und Requests | Verständlichkeit, Suche und Alternativkanal | | **Telefon** | dringende und komplexe Situationen | Wartezeit, Dokumentation und Identitätsprüfung | | **E-Mail** | schriftliche, weniger dringende Anliegen | Vollständigkeit, Anhänge und Sicherheit | | **Chat** | schnelle Rückfragen und begleitete Diagnose | Dokumentation und Übergabe | | **virtueller Agent** | häufige standardisierte Anliegen | Transparenz, Qualität und menschlicher Ausweg | | **mobile App** | mobile Benutzer und Statusinformationen | Gerätesicherheit und Datenschutz | | **Vor-Ort-Kontakt** | Geräteprobleme und komplexe Unterstützung | Dokumentation und Priorisierung | | **Notfallkanal** | klar definierte kritische Situationen | Missbrauchsschutz und schnelle Eskalation | | **Statusseite** | bekannte Störungen und Wartungen | Aktualität und Schutz vertraulicher Informationen | --- **Zusammenfassende Darstellung** > Benutzer benötigt Unterstützung > ↓ > geeigneten und bekannten Kontaktkanal auswählen > ↓ > Kanal ist technisch verfügbar und organisatorisch besetzt > ↓ > Identität und Anliegen angemessen erfassen > ↓ > Kontakt zentral dokumentieren und fachlich einordnen > ↓ > geeigneten Wertstrom und zuständige Fähigkeiten einbinden > ↓ > Status über den passenden Kanal kommunizieren > ↓ > bei Bedarf Kanal wechseln, ohne Informationen zu verlieren > ↓ > Outcome bestätigen > ↓ > Kanalqualität und Benutzererfahrung auswerten > ↓ > Kontaktstrategie fortlaufend verbessern --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.3 Benutzerkommunikation und professioneller Umgang - 3.4 Tickets vollständig erfassen und kategorisieren - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Incident Management - Service Request Management - Information Security Management - Knowledge Management - Service Level Management - Service Continuity Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706) - [PeopleCert: ITIL 4 Practitioner – Service Desk Mock Exam](https://www.peoplecert.org/browse-mock-exams/it-governance-and-service-management/ITIL-1/ITIL%204%20Practitioner%20Service%20Desk%20Mock%20exam-3707) - [ITIL: The ongoing relevance of the service desk in an AI world](https://www.itil.com/Itil-News-and-Announcements/service-desk-relevance-ai-world) - [PeopleCert: Build an AI-Powered Service Desk That Runs Itself](https://www.peoplecert.org/news-and-announcements/design-a-service-desk-that-practically-runs-itself) - [ITIL: ITIL Service – Version 5](https://www.itil.com/Itil-News-and-Announcements/itil-service-version-5) - [PeopleCert: ITIL Foundation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) **Offiziell bestätigter Stand** Die offiziellen ITIL- und PeopleCert-Quellen bestätigen: - Der Service Desk dient als zentraler Kontaktpunkt zwischen Service Provider und Benutzern. - Eine wirksame Service-Desk-Practice beeinflusst Benutzererfahrung, Kundenerfahrung und Servicebeziehungen. - Informationen und Technologien sollen die Service-Desk-Practice unterstützen, Arbeitsweisen vereinfachen und Benutzererfahrung verbessern. - Virtuelle Service Desks, KI-gestützte Unterstützung, Chatbots und automatisierte Standardaufgaben sind heute verbreitete Bestandteile moderner Serviceumgebungen. - Menschliche Kommunikation, Empathie, Kontextverständnis und kreative Zusammenarbeit bleiben insbesondere bei komplexen Situationen wichtig. - Self-Service sollte durch verständliche Portale, hochwertige Wissensinhalte, Vertrauen und benutzerorientierte Gestaltung unterstützt werden. - ITIL Version 5 richtet Serviceaktivitäten stärker auf Endbenutzererfahrung, Wertfluss und Zusammenarbeit über organisatorische Grenzen hinweg aus. **Einordnung** Die auf dieser Seite beschriebenen: - Kanalmodelle, - Servicezeiten, - Bereitschaftsregelungen, - Telefon- und Portalgestaltungen, - Checklisten, - Sicherheitsmaßnahmen, - Kennzahlen, - und Praxisbeispiele sind herstellerneutrale redaktionelle Empfehlungen dieses unabhängigen Nachschlagewerks. ITIL schreibt keine universelle: - Anzahl von Kontaktkanälen, - rund um die Uhr bestehende Servicezeit, - Telefonmenüstruktur, - Antwortzeit, - Support-Level-Struktur, - oder bestimmte technische Plattform vor. Die konkrete Kanalstrategie muss an: - Benutzergruppen, - Servicekritikalität, - Arbeitszeiten, - Risiken, - Sicherheitsanforderungen, - vertragliche Verpflichtungen, - verfügbare Fähigkeiten, - und organisatorische Ressourcen angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Service-Desk-Guidance **Fachlicher Stand:** August 2026 # 3.3 Benutzerkommunikation und professioneller Umgang > **Kurz erklärt** > > Benutzerkommunikation ist ein wesentlicher Bestandteil der Serviceerfahrung. > > Ein technisches Problem wird aus Sicht eines Benutzers nicht nur danach bewertet: > > - ob es gelöst wurde, > - sondern auch wie der Kontakt verlief, > - ob das Anliegen verstanden wurde, > - ob Informationen verständlich waren, > - ob Zusagen eingehalten wurden, > - und ob der Benutzer wusste, was als Nächstes geschieht. > > Professionelle Kommunikation bedeutet: > > - aufmerksam zuhören, > - Auswirkungen verstehen, > - verständlich sprechen und schreiben, > - Erwartungen realistisch steuern, > - Unsicherheiten offen benennen, > - regelmäßig informieren, > - respektvoll bleiben, > - Sicherheits- und Datenschutzregeln einhalten, > - und das erreichte Ergebnis aus Benutzersicht bestätigen. > > Empathie ist dabei kein Ersatz für technische Kompetenz. > > Sie hilft, technische Kompetenz so einzusetzen und zu vermitteln, dass Benutzer Vertrauen gewinnen und handlungsfähig bleiben. --- **Warum Kommunikation Teil der Serviceleistung ist** Benutzer erleben einen Service nicht ausschließlich über: - Verfügbarkeit, - Leistung, - Funktionen, - oder technische Messwerte. Sie erleben ihn auch über die Interaktionen mit der Serviceorganisation. Dazu gehören: - Portaltexte, - Fehlermeldungen, - Telefongespräche, - Chatnachrichten, - E-Mails, - Statusinformationen, - Wartungsankündigungen, - Rückfragen, - Eskalationen, - und Abschlussmeldungen. Ein Service kann technisch wiederhergestellt sein und trotzdem eine schlechte Erfahrung hinterlassen. Beispiele: - Der Benutzer erhält stundenlang keine Statusinformation. - Mehrere Mitarbeiter stellen dieselben Fragen. - Der Benutzer muss technische Begriffe verstehen, die für seine Aufgabe nicht relevant sind. - Eine versprochene Rückmeldung erfolgt nicht. - Das Ticket wird geschlossen, obwohl die Arbeitsfähigkeit noch nicht wiederhergestellt ist. - Ein Mitarbeiter macht den Benutzer für den Fehler verantwortlich. - Eine Störung wird verharmlost, obwohl sie einen wichtigen Arbeitsprozess blockiert. - Es wird eine Lösung versprochen, obwohl Ursache und Zeitbedarf noch unbekannt sind. > **Merke** > > Kommunikation ist kein Zusatz zur technischen Bearbeitung. > > Sie ist ein sichtbarer Bestandteil der gesamten Serviceerfahrung. --- **Technische Qualität und Kommunikation wirken zusammen** | Technische Bearbeitung | Kommunikation | Mögliche Wahrnehmung | |---|---|---| | schnell und wirksam | verständlich und zuverlässig | sehr positive Erfahrung | | schnell und wirksam | unfreundlich oder unklar | technisch erfolgreich, aber negatives Vertrauen | | langsam oder komplex | transparent und regelmäßig | Situation bleibt belastend, aber nachvollziehbar | | langsam oder komplex | keine verlässlichen Informationen | starke Unsicherheit und negative Erfahrung | | technisch nicht lösbar | Alternativen und Grenzen werden verständlich erklärt | realistische und professionelle Behandlung | | technisch scheinbar gelöst | Benutzer kann weiterhin nicht arbeiten | tatsächliches Outcome nicht erreicht | Eine freundliche Kommunikation kann eine schlechte technische Leistung nicht dauerhaft ausgleichen. Eine gute technische Leistung kann jedoch ebenfalls an Wert verlieren, wenn die Kommunikation: - respektlos, - unverständlich, - widersprüchlich, - oder unzuverlässig ist. --- **Ziel professioneller Benutzerkommunikation** Professionelle Kommunikation soll dazu beitragen, dass: - das Anliegen richtig verstanden wird, - notwendige Informationen vollständig vorliegen, - der Benutzer den nächsten Schritt kennt, - Missverständnisse vermieden werden, - Auswirkungen angemessen berücksichtigt werden, - Vertrauen erhalten bleibt, - Sicherheitsregeln eingehalten werden, - und das gewünschte Outcome gemeinsam erreicht werden kann. Sie soll nicht nur möglichst freundlich klingen. Sie muss außerdem: - fachlich korrekt, - situationsgerecht, - nachvollziehbar, - und handlungsorientiert sein. --- **Kommunikation an Wissen und Kontext anpassen** Service-Desk-Mitarbeiter sprechen mit Personen mit unterschiedlichen: - technischen Kenntnissen, - Aufgaben, - Verantwortlichkeiten, - Sprachkenntnissen, - Erfahrungen, - und Stresssituationen. Eine identische Erklärung ist deshalb nicht für jede Person geeignet. Beispiel für einen technisch erfahrenen Ansprechpartner: > Die Namensauflösung funktioniert, aber die TCP-Verbindung zum Dienst wird am Standort blockiert. Das Netzwerkteam prüft aktuell Firewall und Routing. Beispiel für einen Benutzer ohne technischen Schwerpunkt: > Ihr Computer erreicht den zentralen Dienst derzeit nicht. Das zuständige Netzwerkteam prüft die Verbindung. Sie müssen im Moment keine weiteren Einstellungen verändern. Beide Aussagen können dieselbe Situation beschreiben. Die Formulierung wird an die jeweilige Zielgruppe angepasst. > **Merke** > > Verständliche Kommunikation bedeutet nicht, Informationen ungenau oder falsch darzustellen. > > Sie bedeutet, die benötigte Information in einer geeigneten Sprache und Detailtiefe zu vermitteln. --- **Fachsprache bewusst verwenden** Technische Fachbegriffe sind sinnvoll, wenn: - die Gesprächspartner sie verstehen, - sie für die Entscheidung notwendig sind, - oder sie eine Situation präziser beschreiben. Sie sind ungeeignet, wenn sie: - den Benutzer verwirren, - Kompetenz demonstrieren sollen, - Verantwortung auf den Benutzer verlagern, - oder den eigentlichen nächsten Schritt verdecken. Ungeeignet: > Der SAML-Assertion-Consumer-Service liefert aufgrund eines fehlerhaften IdP-Mappings einen Authentifizierungsfehler. Verständlicher: > Die Anmeldung zwischen dem Identitätsdienst und der Anwendung funktioniert derzeit nicht korrekt. Das zuständige Team prüft die Zuordnung. Ihr Kennwort müssen Sie nicht erneut ändern. Für ein technisches Fachteam kann die detaillierte Beschreibung weiterhin notwendig sein. Benutzerkommunikation und technische Dokumentation dürfen deshalb unterschiedliche Detailstufen besitzen. --- **Aktives Zuhören** Aktives Zuhören bedeutet, den Benutzer nicht nur sprechen zu lassen, sondern seine Informationen bewusst aufzunehmen und zu überprüfen. Dazu gehören: - nicht unnötig unterbrechen, - relevante Aussagen erkennen, - gezielt nachfragen, - das Verstandene zusammenfassen, - Unsicherheiten klären, - und Auswirkungen ernst nehmen. Beispiel: Benutzer: > Seit heute Morgen geht bei mir gar nichts mehr. Ungeeignete Reaktion: > Haben Sie den Computer schon neu gestartet? Bessere Reaktion: > Ich kläre kurz, was genau betroffen ist. Können Sie sich nicht am Computer anmelden oder funktionieren nach der Anmeldung bestimmte Anwendungen nicht? Die zweite Reaktion verhindert, dass sofort eine Lösung versucht wird, bevor das Problem ausreichend verstanden ist. --- **Offene und geschlossene Fragen** Beide Fragearten können sinnvoll sein. **Offene Fragen** Sie ermöglichen eine freie Beschreibung. Beispiele: - Was wollten Sie durchführen? - Was ist stattdessen geschehen? - Welche Auswirkungen hat die Störung auf Ihre Arbeit? - Was wurde bereits ausprobiert? - Was hat sich seit gestern verändert? **Geschlossene Fragen** Sie klären konkrete Punkte. Beispiele: - Sind weitere Benutzer betroffen? - Wird eine Fehlermeldung angezeigt? - Funktioniert die Anmeldung im Browser? - Ist das Gerät mit dem Netzwerk verbunden? - Besteht eine alternative Arbeitsmöglichkeit? Eine sinnvolle Gesprächsführung beginnt häufig mit einer offenen Frage und wird anschließend durch konkrete Fragen präzisiert. --- **Das Verstandene zusammenfassen** Eine kurze Zusammenfassung hilft, Missverständnisse früh zu erkennen. Beispiel: > Ich fasse kurz zusammen: Sie können sich seit ungefähr 09:15 Uhr am Zeiterfassungssystem anmelden, aber beim Speichern erscheint die Meldung „Zugriff verweigert“. Zwei Kollegen in derselben Abteilung sind ebenfalls betroffen. Andere Anwendungen funktionieren. Ist das korrekt? Vorteile: - Benutzer kann Fehler korrigieren. - technische Bearbeitung erhält eine klare Ausgangslage. - unnötige Rückfragen werden reduziert. - der Benutzer erkennt, dass sein Anliegen verstanden wurde. --- **Empathie** Empathie bedeutet, die Situation und Perspektive einer anderen Person wahrzunehmen und angemessen darauf zu reagieren. Sie bedeutet nicht: - jeder Forderung zuzustimmen, - Prioritätsregeln aufzugeben, - technische Tatsachen zu verändern, - Sicherheitskontrollen zu umgehen, - oder die Verantwortung für alle Gefühle des Benutzers zu übernehmen. Geeignete empathische Aussagen: - Ich verstehe, dass die Unterbrechung Ihren heutigen Termin gefährdet. - Das ist besonders ungünstig, weil Sie den Zugriff gerade für den Monatsabschluss benötigen. - Ich kann nachvollziehen, dass die wiederholte Anmeldung frustrierend ist. - Ich sehe, dass Sie die Datei dringend benötigen. Ich prüfe jetzt zuerst, ob eine sichere Zwischenlösung möglich ist. Ungeeignete Aussagen: - Das ist doch nicht so schlimm. - Bei mir funktioniert es. - Sie sind der einzige Benutzer mit diesem Problem. - Dafür können wir nichts. - Beruhigen Sie sich erst einmal. > **Wichtig** > > Empathie erkennt die Auswirkung an. > > Sie verspricht nicht automatisch eine sofortige Lösung. --- **Empathie und Priorisierung unterscheiden** Ein Benutzer kann stark belastet sein, während die organisatorisch bestimmte Priorität trotzdem nicht die höchste Stufe erreicht. Beispiel: > Ich verstehe, dass Sie die Anwendung für Ihre aktuelle Aufgabe benötigen. Nach unseren Kriterien ist derzeit nur Ihr Arbeitsplatz betroffen und ein Ersatzarbeitsplatz steht zur Verfügung. Der Vorgang wird deshalb mit Priorität 3 bearbeitet. Sollte auch die Alternative ausfallen oder weitere Benutzer betroffen sein, bewerten wir die Priorität erneut. Diese Aussage: - erkennt die Situation an, - erklärt die Entscheidung, - nennt die Alternative, - und beschreibt, wann eine Neubewertung erfolgt. Ungeeignet: > Dafür bekommen Sie keine höhere Priorität. --- **Eine professionelle Gesprächsstruktur** Eine mögliche Struktur für einen Benutzerkontakt ist: 1. Kontakt eröffnen 2. Identität und Zuständigkeit klären 3. Anliegen frei beschreiben lassen 4. Situation und Auswirkungen präzisieren 5. das Verstandene zusammenfassen 6. Einordnung und nächsten Schritt erklären 7. Erwartungen und Zeitpunkte klären 8. Maßnahme durchführen oder weiterleiten 9. Ergebnis prüfen 10. Kontakt professionell abschließen Diese Struktur ist eine Praxisempfehlung und kein für jede Situation vorgeschriebener ITIL-Prozess. --- **1. Kontakt eröffnen** Eine geeignete Eröffnung sollte: - freundlich, - eindeutig, - und dem Kanal angemessen sein. Telefon: > Guten Morgen, IT-Service-Desk, Max Mustermann. Wie kann ich Sie unterstützen? Chat: > Hallo, Sie sind beim IT-Service-Desk. Ich schaue mir Ihr Anliegen gern an. Wobei benötigen Sie Unterstützung? E-Mail: > Guten Tag, vielen Dank für Ihre Meldung. Ich prüfe zunächst die betroffene Anwendung und die bisher bekannten Auswirkungen. Bei bereits bekannten Vorgängen: > Guten Tag, ich melde mich zu Ihrem Vorgang 4711 bezüglich des Dateizugriffs. --- **2. Identität und Zuständigkeit klären** Abhängig vom Anliegen kann geprüft werden: - Wer meldet? - Wer ist tatsächlich betroffen? - Für welche Organisationseinheit? - Welcher Service wird benötigt? - Darf die meldende Person die gewünschte Änderung veranlassen? - Ist eine zusätzliche Identitätsprüfung erforderlich? Eine starke Identitätsprüfung darf nicht durch freundliches Auftreten oder angeblichen Zeitdruck ersetzt werden. Ungeeignet: > Sie klingen glaubwürdig. Ich setze das Kennwort direkt zurück. Besser: > Für die Kennwortzurücksetzung muss ich Ihre Identität nach unserem festgelegten Verfahren prüfen. Ich führe Sie kurz durch die erforderlichen Schritte. --- **3. Anliegen beschreiben lassen** Der Benutzer sollte zunächst ausreichend Gelegenheit erhalten, seine Beobachtung zu schildern. Hilfreiche Einstiegsfragen: - Was möchten Sie durchführen? - Was funktioniert dabei nicht wie erwartet? - Welche Meldung sehen Sie? - Welche Auswirkung entsteht für Ihre Arbeit? Zu frühe technische Vermutungen können die Beschreibung verfälschen. Beispiel: Ungeeignet: > Dann ist bestimmt Ihr VPN kaputt. Besser: > Ich prüfe zunächst, ob die Verbindung oder die Anwendung selbst betroffen ist. --- **4. Auswirkungen präzisieren** Wichtige Fragen: - Welche Tätigkeit ist blockiert? - Sind weitere Personen betroffen? - Welcher Service oder Geschäftsprozess ist betroffen? - Besteht eine sichere Zwischenlösung? - Gibt es einen zeitkritischen Termin? - Besteht ein möglicher Sicherheits- oder Datenverlustbezug? Die Kommunikation sollte nicht nur das technische Symptom erfassen. Beispiel: > Der Drucker funktioniert nicht. Die tatsächliche Auswirkung kann reichen von: - ein Benutzer kann einen internen Entwurf nicht ausdrucken bis zu: - der gesamte Warenausgang kann keine Versandetiketten erzeugen. --- **5. Zusammenfassen und bestätigen** Beispiel: > Sie können seit etwa 13:00 Uhr keine Versandetiketten drucken. Betroffen sind alle vier Arbeitsplätze im Warenausgang. Andere Drucker funktionieren, aber es gibt dort keine zulässige Alternative für die Etiketten. Der Versand steht deshalb momentan still. Ist diese Zusammenfassung korrekt? Diese Informationen unterstützen: - Priorisierung, - technische Diagnose, - Eskalation, - und Statuskommunikation. --- **6. Nächsten Schritt erklären** Der Benutzer sollte wissen: - was jetzt geschieht, - wer beteiligt wird, - ob er selbst etwas tun muss, - und wann eine weitere Information erfolgt. Beispiel: > Ich prüfe zunächst, ob bereits eine allgemeine Störung bekannt ist. Danach teste ich die Verbindung zum Druckservice. Falls die Ursache dort nicht erkennbar ist, binde ich das zuständige Druck- und Netzwerkteam ein. Ungeeignet: > Ich gebe das weiter. Besser: > Ich gebe den Vorgang mit den bisherigen Prüfergebnissen an das Netzwerkteam. Der Service Desk behält die Kommunikation. Sie erhalten spätestens um 14:30 Uhr eine Statusmeldung, auch wenn die Ursache dann noch nicht vollständig behoben ist. --- **7. Erwartungen realistisch steuern** Zu klären sind: - Was kann sofort getan werden? - Was benötigt weitere Analyse? - Welche Abhängigkeiten bestehen? - Liegt eine bekannte Zielzeit vor? - Wann erfolgt die nächste Statusmeldung? - Besteht eine Zwischenlösung? - Welche Grenzen gelten? Eine realistische Aussage ist besser als eine beruhigend gemeinte, aber unbelegte Zusage. Ungeeignet: > Das ist gleich erledigt. Besser: > Die Ursache ist noch nicht bestätigt. Das zuständige Team beginnt jetzt mit der Analyse. Eine verlässliche Lösungszeit kann ich noch nicht nennen. Die nächste Rückmeldung erfolgt spätestens um 16:00 Uhr. --- **8. Maßnahme durchführen oder weiterleiten** Während einer Maßnahme sollte erklärt werden: - was durchgeführt wird, - warum es durchgeführt wird, - ob eine Unterbrechung entsteht, - und welches Ergebnis erwartet wird. Beispiel: > Ich starte nicht den gesamten Computer neu. Zuerst beende ich nur den betroffenen Druckdienst, weil die anderen Anwendungen ordnungsgemäß funktionieren. Bei einer Remote-Sitzung: > Ich öffne jetzt die Netzwerkeinstellungen und prüfe die bestehende Verbindung. Ich ändere noch keine Konfiguration. Sollte eine Änderung erforderlich sein, erkläre ich sie vorher. --- **9. Ergebnis prüfen** Nach einer technischen Maßnahme sollte nicht nur gefragt werden: > Geht es jetzt? Präzisere Prüfung: - Können Sie sich jetzt anmelden? - Können Sie die zuvor fehlgeschlagene Datei öffnen? - Können Sie den vollständigen Arbeitsschritt durchführen? - Erscheint die Fehlermeldung erneut? - Funktioniert die Anwendung nur vorübergehend oder stabil? - Sind weitere Benutzer weiterhin betroffen? Das Ergebnis sollte sich am ursprünglichen Outcome orientieren. --- **10. Kontakt abschließen** Ein professioneller Abschluss kann enthalten: - kurze Zusammenfassung, - bestätigtes Ergebnis, - offene Punkte, - Vorgangsnummer, - nächsten Schritt, - und Kontaktmöglichkeit. Beispiel: > Die Anmeldung funktioniert wieder und Sie konnten den Auftrag erfolgreich speichern. Die Ursache war eine fehlerhafte Gruppenmitgliedschaft. Der Vorgang bleibt noch bis morgen zur Kontrolle geöffnet. Sollte der Fehler erneut auftreten, antworten Sie bitte unter Angabe der Vorgangsnummer 4711. Bei ungelöster Situation: > Die Störung ist noch nicht behoben. Das Anwendungsteam untersucht aktuell die fehlerhafte Berechtigung. Als Zwischenlösung können Sie den Auftrag über Arbeitsplatz 12 bearbeiten. Die nächste Statusmeldung erfolgt spätestens um 11:30 Uhr. --- **Klare Sprache verwenden** Klare Sprache zeichnet sich aus durch: - kurze und vollständige Sätze, - eindeutige Handlungsanweisungen, - bekannte Begriffe, - nachvollziehbare Reihenfolge, - und sichtbare nächste Schritte. Ungeeignet: > Bitte führen Sie das übliche Prozedere durch und melden Sie sich gegebenenfalls erneut. Besser: > Starten Sie die Anwendung einmal neu. Melden Sie sich anschließend erneut an. Falls wieder die Meldung „Zugriff verweigert“ erscheint, antworten Sie bitte direkt auf diese Nachricht. --- **Nur eine Handlung pro Schritt** Besonders bei Telefon, Chat oder E-Mail sollten technische Anweisungen klar gegliedert sein. Ungeeignet: > Öffnen Sie die Einstellungen, prüfen Sie die Verbindung, löschen Sie den Cache, starten Sie neu und probieren Sie es noch einmal. Besser: 1. Öffnen Sie die Anwendung noch nicht erneut. 2. Prüfen Sie unten rechts, ob das Netzwerksymbol eine Verbindung anzeigt. 3. Teilen Sie mir bitte mit, welches Symbol angezeigt wird. 4. Danach bestimmen wir den nächsten Schritt. Dadurch kann das Ergebnis jedes einzelnen Schritts bewertet werden. --- **Richtung und Ort eindeutig beschreiben** Ungeeignet: > Klicken Sie da links auf das Symbol. Besser: > Öffnen Sie oben rechts das Benutzermenü und wählen Sie anschließend „Abmelden“. Bei mehreren Betriebssystemen oder Versionen sollte vorher geklärt werden: - welches Gerät, - welches Betriebssystem, - welche Anwendung, - und welche Version verwendet wird. --- **Keine unnötigen Vermutungen als Tatsache darstellen** Ungeeignet: > Das liegt sicher an Ihrem WLAN. Besser: > Eine instabile Verbindung ist eine mögliche Ursache. Ich prüfe zunächst, ob auch andere Benutzer oder Netzwerkverbindungen betroffen sind. Ungeeignet: > Der Hersteller hat gerade eine Störung. Besser: > Beim Hersteller ist derzeit eine mögliche Störung gemeldet. Wir prüfen noch, ob sie mit Ihrem Problem zusammenhängt. --- **Transparenz über Unsicherheit** Professionelle Kommunikation darf Unsicherheit enthalten. Geeignete Aussagen: - Die genaue Ursache ist noch nicht bestätigt. - Wir haben zwei mögliche Ursachen eingegrenzt. - Der erste Wiederherstellungsversuch war nicht erfolgreich. - Die technische Funktion ist wiederhergestellt, aber wir überwachen den Service noch. - Die Zeitangabe ist eine aktuelle Schätzung und kann sich ändern. - Wir benötigen für die weitere Analyse Informationen des Herstellers. Ungeeignet ist, Unsicherheit durch scheinbare Gewissheit zu verdecken. > **Merke** > > Ehrliche Unsicherheit kann Vertrauen erhalten. > > Falsche Sicherheit beschädigt Vertrauen, sobald eine Zusage nicht eingehalten wird. --- **Zusagen einhalten** Zusagen können sein: - Rückruf, - Statusmeldung, - Prüfung, - Weiterleitung, - Dokumentation, - oder ein vereinbarter Termin. Kann eine Zusage nicht eingehalten werden, sollte die Information vor Ablauf des zugesagten Zeitpunkts erfolgen. Beispiel: > Die angekündigte Rückmeldung um 14:00 Uhr kann ich noch nicht mit einer Lösung verbinden. Das Netzwerkteam prüft weiterhin die Standortverbindung. Der Provider wurde inzwischen einbezogen. Die nächste Aktualisierung erfolgt spätestens um 15:00 Uhr. Ungeeignet: - keine Rückmeldung geben, - bis zur vollständigen Lösung warten, - oder erst nach einer erneuten Nachfrage reagieren. --- **Statuskommunikation** Eine hilfreiche Statusmeldung beantwortet möglichst: - Was ist betroffen? - Welche Auswirkungen sind bekannt? - Was wird aktuell getan? - Gibt es eine Zwischenlösung? - Was müssen Benutzer tun? - Wann folgt die nächste Information? Beispiel: > Seit 10:20 Uhr ist die zentrale Dateiablage für die Standorte Nord und West nicht erreichbar. Das Netzwerkteam untersucht die Verbindung zum Rechenzentrum. Lokal gespeicherte Dateien sind nicht betroffen. Bitte führen Sie keine wiederholten Neustarts durch. Eine nächste Statusmeldung erfolgt spätestens um 11:00 Uhr. --- **Statusmeldung ohne neue technische Erkenntnis** Auch wenn noch keine Lösung vorliegt, kann eine Statusmeldung sinnvoll sein. Beispiel: > Die Analyse läuft weiter. Eine eindeutige Ursache wurde noch nicht bestätigt. Der Hersteller prüft derzeit die Protokolldaten. Die bisher genannte Zwischenlösung bleibt gültig. Die nächste Aktualisierung erfolgt um 16:30 Uhr. Dadurch weiß der Benutzer: - der Vorgang wird weiterhin bearbeitet, - die Organisation hat ihn nicht vergessen, - und wann eine neue Information zu erwarten ist. --- **Kommunikationshäufigkeit an die Situation anpassen** Ein kritischer Incident benötigt häufigere Statusinformationen als eine normale Serviceanfrage. Mögliche Einflussfaktoren: - Auswirkung, - Dringlichkeit, - Anzahl betroffener Benutzer, - Dauer, - Unsicherheit, - verfügbare Zwischenlösung, - und Informationsbedarf der Stakeholder. Zu häufige Meldungen ohne Inhalt können: - Bearbeitung unterbrechen, - Verwirrung erzeugen, - oder wichtige Informationen verdecken. Zu seltene Meldungen erzeugen: - Unsicherheit, - Rückfragen, - Mehrfachmeldungen, - und Vertrauensverlust. --- **Zielgruppengerechte Statusinformationen** Unterschiedliche Stakeholder benötigen unterschiedliche Informationen. | Zielgruppe | Häufig benötigte Information | |---|---| | Benutzer | Auswirkung, Zwischenlösung, nächstes Update | | Service Desk | bekannte Symptome, betroffene Gruppen, freigegebene Formulierung | | technisches Team | Diagnose, Protokolle, Hypothesen, nächste Maßnahmen | | Service Owner | Serviceauswirkung, Risiken, Fortschritt und Entscheidungen | | Führungskräfte | Geschäftsfolgen, erwartete Dauer, Risiken und benötigte Entscheidungen | | Lieferant | technische Nachweise, Vertragsbezug, Priorität und gewünschte Unterstützung | | Informationssicherheit | mögliche Daten- oder Sicherheitsauswirkung und gesicherte Beweise | Eine technische Arbeitsnotiz sollte nicht unverändert an alle Benutzer gesendet werden. --- **Kommunikation bei geplanten Wartungen** Eine Wartungsankündigung sollte möglichst enthalten: - betroffener Service, - Datum und Zeitraum, - erwartete Auswirkung, - betroffene Benutzer oder Standorte, - Grund der Maßnahme, - notwendige Vorbereitung, - mögliche Alternative, - Kontaktweg, - und Abschlussinformation. Beispiel: > Am Sonntag, 9. August 2026, wird der zentrale Dateiservice zwischen 08:00 und 10:00 Uhr aktualisiert. In diesem Zeitraum können Dateien vorübergehend nicht geöffnet oder gespeichert werden. Bitte schließen Sie geöffnete Dateien bis 07:45 Uhr. Eine Statusmeldung erfolgt nach Abschluss der Arbeiten. Ungeeignet: > Am Wochenende finden Wartungsarbeiten statt. --- **Unterschied zwischen Information und Handlungsaufforderung** Benutzer sollten erkennen können, ob sie: - nur informiert werden, - etwas vorbereiten, - eine Handlung ausführen, - oder eine Rückmeldung geben müssen. Beispiel: > **Keine Handlung erforderlich:** Die Aktualisierung wird automatisch installiert. Beispiel: > **Handlung erforderlich:** Speichern Sie Ihre Arbeit und starten Sie das Gerät spätestens am Freitag neu. Eine klare Kennzeichnung reduziert Missverständnisse. --- **Schriftliche Kommunikation** Schriftliche Kommunikation sollte: - einen eindeutigen Betreff, - eine verständliche Einleitung, - die wichtigste Aussage zuerst, - klare Handlungsschritte, - Zeitangaben, - und einen erkennbaren Ansprechpartner enthalten. Ungeeigneter Betreff: > Update Besser: > Status zum Ausfall der Dateiablage – nächstes Update um 15:00 Uhr Ungeeignete Nachricht: > Wir arbeiten daran. Besser: > Die Dateiablage ist weiterhin für die Standorte Nord und West nicht erreichbar. Der Provider untersucht aktuell die externe Verbindung. Lokal gespeicherte Dateien können weiterverwendet werden. Die nächste Statusmeldung erfolgt spätestens um 15:00 Uhr. --- **E-Mail-Kommunikation strukturieren** Eine praktische Struktur: - Anlass - aktueller Status - Auswirkung - Handlung des Benutzers - nächster Schritt - nächste Rückmeldung - Vorgangsnummer Beispiel: > Guten Tag, > > der Zugriff auf das Abrechnungssystem ist seit 09:40 Uhr für mehrere Benutzer eingeschränkt. > > Das Anwendungsteam untersucht aktuell die Anmeldung. Bitte ändern Sie Ihr Kennwort nicht erneut, da das Problem nicht durch ein falsches Kennwort verursacht wird. > > Eine nächste Statusmeldung erfolgt spätestens um 11:00 Uhr. > > Vorgangsnummer: 4711 --- **Chat-Kommunikation** Im Chat sollten Nachrichten: - kurz, - aber vollständig, - in sinnvoller Reihenfolge, - und ohne unklare Abkürzungen geschrieben werden. Ungeeignet: > ok warte Besser: > Ich prüfe jetzt, ob bereits eine allgemeine Störung bekannt ist. Das dauert voraussichtlich wenige Minuten. Bitte lassen Sie das Chatfenster geöffnet. Bei längerer Unterbrechung: > Die Prüfung dauert länger als erwartet. Ich erstelle einen Vorgang und informiere Sie per E-Mail weiter. Ihre Vorgangsnummer lautet 4711. --- **Telefonische Kommunikation** Beim Telefonkontakt sind besonders wichtig: - aktiv zuhören, - langsam und deutlich sprechen, - technische Schritte einzeln erklären, - Pausen zulassen, - Ergebnisse wiederholen lassen, - und wichtige Vereinbarungen am Ende zusammenfassen. Beispielabschluss: > Wir haben die Anwendung neu angemeldet und der Zugriff funktioniert wieder. Ich dokumentiere die Lösung unter Vorgang 4711. Sollte die Meldung erneut erscheinen, rufen Sie bitte nicht alle Schritte erneut durch, sondern nennen Sie direkt diese Vorgangsnummer. --- **Persönlicher Kontakt** Beim Vor-Ort-Support sollte der Mitarbeiter: - sich vorstellen, - erklären, was geprüft wird, - Zustimmung vor Eingriffen einholen, - sensible Inhalte beachten, - und das Ergebnis dokumentieren. Ungeeignet: - ohne Erklärung Maus und Tastatur übernehmen, - private oder vertrauliche Dateien öffnen, - oder den Arbeitsplatz verlassen, ohne das Ergebnis zu erklären. --- **Kommunikation bei Remote-Support** Vor einer Remote-Sitzung sollte geklärt werden: - welches zugelassene Werkzeug verwendet wird, - ob der Benutzer zustimmt, - welche Aktionen durchgeführt werden, - und wie die Sitzung beendet wird. Geeignete Formulierung: > Mit Ihrer Zustimmung starte ich eine Remote-Sitzung. Sie können alle Schritte sehen und die Sitzung jederzeit beenden. Ich prüfe nur die Einstellungen der betroffenen Anwendung. Bitte schließen Sie vorher vertrauliche Dokumente. Während der Sitzung: > Ich öffne jetzt die Anwendungsprotokolle. Dabei werden keine persönlichen Dateien verändert. Nach der Sitzung: > Die Remote-Verbindung ist beendet. Wir haben nur die Anwendungseinstellungen angepasst. Bitte testen Sie jetzt den vollständigen Arbeitsschritt. --- **Fehler nicht vorschnell dem Benutzer zuschreiben** Ungeeignet: - Sie haben das falsch gemacht. - Das Problem sitzt vor dem Bildschirm. - Sie hätten die Anleitung lesen müssen. - Warum haben Sie das nicht früher gemeldet? Besser: - Die bisherige Anleitung beschreibt den neuen Anmeldeweg nicht ausreichend. - Der Zugriff wurde mit einer Rolle beantragt, die für diese Tätigkeit nicht ausreicht. - Die Fehlermeldung macht nicht deutlich, welcher Schritt erforderlich ist. - Für die weitere Untersuchung ist wichtig, wann das Problem erstmals aufgetreten ist. Auch wenn ein Bedienfehler vorliegt, sollte die Organisation prüfen: - War die Funktion verständlich? - War die Anleitung auffindbar? - War die Fehlermeldung hilfreich? - Ist derselbe Fehler bei mehreren Benutzern aufgetreten? - Kann das Design verbessert werden? --- **Keine Schuldzuweisung zwischen Teams** Ungeeignet gegenüber Benutzern: - Das Netzwerkteam hat wieder etwas falsch konfiguriert. - Der Hersteller ist schuld. - Die Entwicklung bekommt das nie richtig hin. - Dafür ist der Service Desk nicht verantwortlich. Besser: - Das Netzwerkteam prüft aktuell die Verbindung. - Wir haben den Hersteller einbezogen und koordinieren die weitere Bearbeitung. - Die Ursache liegt möglicherweise in der aktuellen Anwendungsversion und wird untersucht. - Der Vorgang benötigt zusätzliche technische Analyse. Ich sorge für die Weitergabe und halte Sie informiert. Interne Ursachen können später sachlich untersucht werden. Die Benutzerkommunikation sollte nicht zur öffentlichen Schuldzuweisung verwendet werden. --- **Umgang mit verärgerten Benutzern** Ein verärgerter Benutzer kann: - laut sprechen, - wiederholt nachfragen, - Vorwürfe äußern, - oder eine sofortige Lösung verlangen. Eine mögliche Vorgehensweise: 1. nicht sofort in die Verteidigung gehen 2. ausreden lassen, soweit möglich 3. Auswirkung anerkennen 4. Sachverhalt zusammenfassen 5. konkrete nächste Schritte nennen 6. realistische Grenzen erklären 7. vereinbaren, wann die nächste Information erfolgt Beispiel: > Ich verstehe, dass der wiederholte Ausfall Ihren Monatsabschluss erheblich behindert. Der Service ist noch nicht stabil. Das Anwendungsteam und der Hersteller arbeiten gemeinsam an der Ursache. Als Zwischenlösung können Sie die Buchungen derzeit über Arbeitsplatz 4 durchführen. Ich informiere Sie spätestens um 13:00 Uhr erneut. --- **Nicht jede Beschwerde persönlich nehmen** Benutzerfrust richtet sich häufig gegen: - die Unterbrechung, - wiederholte Fehler, - fehlende Informationen, - oder die Organisation insgesamt. Mitarbeiter sollten Beschwerden ernst nehmen, ohne jede Aussage als persönliche Bewertung zu übernehmen. Gleichzeitig muss respektloses Verhalten nicht unbegrenzt akzeptiert werden. --- **Grenzen bei aggressivem oder beleidigendem Verhalten** Professioneller Umgang gilt für alle Beteiligten. Mitarbeiter müssen: - Beleidigungen, - Drohungen, - Diskriminierung, - oder gezielte Einschüchterung nicht akzeptieren. Eine mögliche Reaktion: > Ich möchte Ihr Anliegen gern weiter bearbeiten. Dafür benötige ich ein respektvolles Gespräch. Wenn die Beleidigungen fortgesetzt werden, muss ich den Kontakt beenden und nach unserem Eskalationsverfahren weitergeben. Bei konkreten Drohungen oder Sicherheitsrisiken sind die internen Sicherheits- und Eskalationsverfahren anzuwenden. > **Wichtig** > > Empathie bedeutet nicht, missbräuchliches Verhalten hinzunehmen. --- **Deeskalation** Hilfreiche Maßnahmen: - ruhig und langsam sprechen, - nicht gleichzeitig widersprechen und erklären, - keine Ironie verwenden, - konkrete Fakten nennen, - Handlungsmöglichkeiten anbieten, - Verantwortung für den nächsten Schritt übernehmen, - und unbelegten Versprechen widerstehen. Ungeeignet: > Wenn Sie mich nicht ausreden lassen, kann ich auch nichts machen. Besser: > Ich möchte die Situation lösen. Dafür fasse ich kurz zusammen, was bereits bekannt ist, und erkläre anschließend die zwei möglichen nächsten Schritte. --- **Umgang mit Beschwerden** Eine Beschwerde kann Hinweise liefern auf: - schlechte Kommunikation, - unklare Erwartungen, - wiederkehrende Störungen, - ungeeignete Prozesse, - fehlende Barrierefreiheit, - oder nicht erfüllte Serviceziele. Eine Beschwerde sollte: - sachlich erfasst, - nicht abgewertet, - entsprechend ihrer Bedeutung eskaliert, - und hinsichtlich möglicher Verbesserungen ausgewertet werden. Geeignete Antwort: > Vielen Dank für die konkrete Rückmeldung. Sie haben an drei aufeinanderfolgenden Tagen keine angekündigte Statusmeldung erhalten. Ich dokumentiere das als Abweichung und lasse zusätzlich prüfen, warum die Kommunikationsintervalle nicht eingehalten wurden. Ungeeignet: > Dafür müssen Sie sich an jemand anderen wenden. --- **Umgang mit Führungskräften und wichtigen Stakeholdern** Hierarchische Positionen können besondere Informationsbedürfnisse erzeugen. Sie dürfen jedoch nicht automatisch: - Sicherheitskontrollen aufheben, - Prioritätskriterien ersetzen, - oder andere kritische Incidents verdrängen. Professionelle Kommunikation: > Ich verstehe die geschäftliche Bedeutung Ihres Termins. Für eine höhere Priorität benötige ich noch die Information, ob weitere Benutzer oder ein zentraler Geschäftsprozess betroffen sind. Die Identitätsprüfung für den Zugriff muss trotzdem vollständig durchgeführt werden. Bei Bedarf kann eine hierarchische Eskalation erfolgen. --- **Umgang mit wiederholten Nachfragen** Wiederholte Nachfragen können ein Hinweis sein auf: - fehlende Statusinformationen, - unklare Zuständigkeit, - schlechte Erwartungssteuerung, - oder hohe geschäftliche Auswirkungen. Die Antwort sollte nicht nur lauten: > Wir arbeiten noch daran. Besser: > Seit der letzten Meldung wurde der Fehler auf die Verbindung zwischen Anwendung und Datenbank eingegrenzt. Das Datenbankteam prüft aktuell die fehlgeschlagenen Verbindungen. Eine Wiederherstellungszeit liegt noch nicht vor. Die nächste Statusmeldung erfolgt um 16:00 Uhr. --- **Umgang mit nicht erfüllbaren Forderungen** Manche Forderungen können nicht erfüllt werden, weil sie: - technisch unmöglich, - nicht genehmigt, - sicherheitswidrig, - rechtlich unzulässig, - oder außerhalb des Serviceumfangs sind. Eine professionelle Ablehnung enthält möglichst: 1. klare Aussage 2. verständliche Begründung 3. mögliche Alternative 4. gegebenenfalls Eskalations- oder Antragsweg Beispiel: > Ich kann die Mehrfaktor-Authentifizierung nicht dauerhaft deaktivieren, da sie für administrative Konten verbindlich ist. Ich kann jedoch prüfen, ob ein zugelassenes alternatives Authentifizierungsverfahren für Ihr Gerät eingerichtet werden kann. --- **„Nein“ verständlich erklären** Ungeeignet: > Das geht nicht. Prozess ist Prozess. Besser: > Der direkte Zugriff kann nicht eingerichtet werden, weil dadurch personenbezogene Daten ohne die erforderliche Berechtigung sichtbar wären. Möglich ist stattdessen ein Antrag auf die freigegebene Leseberechtigung. Ich sende Ihnen das passende Serviceangebot. --- **Kommunikation bei Fehlern der Serviceorganisation** Hat die Serviceorganisation einen Fehler verursacht, sollte sie: - den Fehler nicht verschleiern, - die bekannte Auswirkung benennen, - notwendige Korrekturen erklären, - und keine unbelegten Schuldzuweisungen vornehmen. Beispiel: > Bei der gestrigen Änderung wurde eine benötigte Berechtigungsgruppe nicht übernommen. Dadurch konnten zwölf Benutzer die Anwendung heute Morgen nicht öffnen. Die Gruppe wurde wiederhergestellt. Wir prüfen zusätzlich, warum der Test die fehlende Berechtigung nicht erkannt hat. Ungeeignet: > Es gab ein kleines technisches Problem. wenn die tatsächliche Auswirkung erheblich war. --- **Entschuldigung professionell verwenden** Eine Entschuldigung sollte konkret und angemessen sein. Geeignet: > Es tut uns leid, dass Sie trotz der zugesagten Rückmeldung keine Statusinformation erhalten haben. Weniger hilfreich: > Entschuldigung für die Unannehmlichkeiten. ohne zu benennen, was geschehen ist. Eine Entschuldigung ersetzt nicht: - Korrektur, - Information, - Verantwortung, - oder Verbesserung. --- **Kommunikation bei Major Incidents** Bei einem Major Incident müssen Informationen: - konsistent, - zeitnah, - zielgruppengerecht, - und kontrolliert bereitgestellt werden. Zu klären sind: - Wer darf offizielle Statusmeldungen veröffentlichen? - Welche Informationen sind bestätigt? - Welche Vermutungen dürfen nicht veröffentlicht werden? - Welche Zielgruppen benötigen welche Details? - Welche Intervalle gelten? - Welche Kanäle werden verwendet? - Wer genehmigt sensible Aussagen? - Wie wird die Abschlussinformation gestaltet? --- **Inhalt einer Major-Incident-Meldung** Eine erste Meldung kann enthalten: - betroffener Service, - bekannte Auswirkung, - Beginn, - aktueller Bearbeitungsstatus, - mögliche Zwischenlösung, - und nächster Aktualisierungszeitpunkt. Beispiel: > Seit 08:45 Uhr ist die zentrale Anmeldung für mehrere interne Anwendungen gestört. Benutzer können sich teilweise nicht neu anmelden. Bereits aktive Sitzungen sind nach aktuellem Stand nicht betroffen. Die zuständigen Identitäts- und Anwendungsteams untersuchen die Ursache. Bitte ändern Sie Ihr Kennwort nicht. Die nächste Statusmeldung erfolgt spätestens um 09:30 Uhr. --- **Keine unbestätigten Ursachen veröffentlichen** Ungeeignet: > Der Ausfall wurde durch einen Cyberangriff verursacht. wenn dies noch nicht bestätigt ist. Besser: > Die Ursache wird untersucht. Das Informationssicherheitsteam ist vorsorglich einbezogen. Eine bestätigte Sicherheitsauswirkung liegt derzeit noch nicht vor. --- **Abschlusskommunikation nach einem Major Incident** Eine Abschlussmeldung kann enthalten: - Zeitpunkt der Wiederherstellung, - bestätigten aktuellen Zustand, - mögliche Restbeeinträchtigungen, - notwendige Benutzeraktionen, - und Hinweis auf weitere Untersuchung. Beispiel: > Der Anmeldeservice ist seit 12:20 Uhr wieder verfügbar. Neue Anmeldungen funktionieren nach aktueller Prüfung. Benutzer mit einer weiterhin angezeigten Fehlermeldung sollen die Anwendung einmal vollständig schließen und erneut öffnen. Die zugrunde liegende Ursache wird noch untersucht. Weitere Erkenntnisse fließen in die nachgelagerte Incident-Überprüfung ein. --- **Kommunikation bei Sicherheitsvorfällen** Bei möglichen Sicherheitsvorfällen gelten häufig besondere Regeln. Der Service Desk sollte: - nur freigegebene Aussagen verwenden, - keine unbestätigten Details verbreiten, - sensible Informationen schützen, - keine Beweise verändern, - und das zuständige Sicherheitsteam einbeziehen. Ungeeignet: > Ihr Konto wurde gehackt. Besser: > Es gibt Hinweise auf eine möglicherweise unberechtigte Anmeldung. Das Sicherheitsteam prüft den Vorgang. Bitte verwenden Sie das betroffene Konto bis zur weiteren Rückmeldung nicht. Die genaue Kommunikation richtet sich nach dem Sicherheitsverfahren der Organisation. --- **Datenschutz in der Kommunikation** Kommunikation kann personenbezogene oder vertrauliche Informationen enthalten. Zu vermeiden sind: - unnötige Empfänger, - vollständige vertrauliche Dokumente, - Kennwörter, - private Gesundheitsinformationen ohne erforderlichen Zweck, - technische Zugangsdaten, - oder interne Sicherheitsdetails in offenen Kanälen. Vor dem Versand sollte geprüft werden: - Wer benötigt die Information? - Ist der Kanal geeignet? - Kann der Inhalt minimiert werden? - Müssen Anhänge geschützt werden? - Ist die Identität des Empfängers ausreichend geprüft? --- **Adressaten und Verteiler prüfen** Besonders bei größeren Störungen kann eine falsche Empfängerliste: - vertrauliche Informationen offenlegen, - unnötige Unruhe erzeugen, - oder Personen mit irrelevanten Meldungen überlasten. Vor dem Versand: - Empfängerkreis prüfen, - offene und verborgene Empfänger angemessen verwenden, - automatische Verteiler verstehen, - und gegebenenfalls Freigabe einholen. --- **Barrierearme Kommunikation** Professionelle Kommunikation berücksichtigt unterschiedliche Fähigkeiten und Voraussetzungen. Mögliche Maßnahmen: - verständliche Sprache, - gut strukturierte Texte, - ausreichende Kontraste in Statusseiten, - keine Information ausschließlich durch Farbe, - Untertitel oder Textalternativen, - zugängliche Dokumente, - alternative Kontaktkanäle, - und ausreichend Zeit für Rückfragen. Ein Benutzer darf nicht als schwierig bewertet werden, weil er: - mehr Zeit benötigt, - einen anderen Kommunikationskanal bevorzugt, - technische Anweisungen wiederholen lässt, - oder Unterstützung aufgrund einer Einschränkung benötigt. --- **Mehrsprachige Kommunikation** Bei mehrsprachigen Benutzern sollte geklärt sein: - welche Sprachen unterstützt werden, - welche Sprache für technische Dokumentation gilt, - wann Übersetzung verwendet wird, - und wie kritische Aussagen überprüft werden. Automatische Übersetzung kann unterstützen, muss aber bei wichtigen Inhalten kontrolliert werden. Besonders kritisch sind: - Sicherheitsanweisungen, - rechtliche Hinweise, - Datenverlustwarnungen, - und technische Maßnahmen mit hohem Risiko. --- **Kulturelle Unterschiede** Kommunikationsstile können sich unterscheiden hinsichtlich: - Direktheit, - Höflichkeitsformen, - Umgang mit Hierarchie, - Rückfragen, - und Ausdruck von Kritik. Professioneller Umgang bedeutet: - keine vorschnellen Bewertungen, - verständliche und respektvolle Sprache, - und Nachfrage bei möglichen Missverständnissen. Es dürfen keine Annahmen über Fähigkeiten oder Verhalten allein aufgrund von: - Herkunft, - Sprache, - Alter, - Geschlecht, - Position, - oder anderen persönlichen Merkmalen getroffen werden. --- **Interne Kommunikation zwischen Supportgruppen** Benutzerkommunikation kann nur zuverlässig sein, wenn auch die interne Kommunikation funktioniert. Eine interne Übergabe sollte enthalten: - betroffenen Service, - genaue Auswirkung, - bisherige Diagnose, - Ergebnisse, - bereits durchgeführte Maßnahmen, - relevante Zeitpunkte, - gewünschte Unterstützung, - und aktuelle Benutzerkommunikation. Ungeeignet: > Bitte übernehmen. Besser: > Seit 10:05 Uhr können alle zwölf Benutzer am Standort Süd keine Verbindung zum Warenwirtschaftssystem herstellen. DNS und allgemeine Internetverbindung funktionieren. Der Zugriff auf TCP-Port 443 der Zieladresse schlägt nur vom Standort Süd fehl. Der Standort-Router wurde nicht neu gestartet. Benötigt wird die Prüfung von Standorttunnel und Firewall. Nächste Benutzerinformation ist für 11:00 Uhr angekündigt. --- **Kommunikation bei Schicht- oder Teamübergaben** Eine Übergabe sollte nicht nur den Ticketstatus nennen. Hilfreich sind: - aktueller technischer Zustand, - bekannte Auswirkungen, - offene Hypothesen, - nächste geplante Maßnahme, - ausstehende Entscheidung, - Kommunikationszeitpunkt, - und verantwortliche Rolle. Beispiel: > Der Service ist teilweise wiederhergestellt. Neue Benutzer können sich anmelden, bestehende Sitzungen zeigen vereinzelt Fehler. Der Hersteller prüft noch die Protokolle. Keine weitere Konfigurationsänderung ohne Abstimmung mit der Incident-Koordination. Nächstes Benutzerupdate um 18:00 Uhr. --- **Kommunikationsverantwortung klären** Bei mehreren beteiligten Teams sollte festgelegt sein: - Wer spricht mit dem Benutzer? - Wer veröffentlicht allgemeine Statusmeldungen? - Wer kommuniziert mit dem Lieferanten? - Wer informiert Führungskräfte? - Wer dokumentiert technische Details? - Wer genehmigt sensible Aussagen? Andernfalls entstehen möglicherweise: - widersprüchliche Informationen, - doppelte Nachrichten, - unbestätigte Aussagen, - oder lange Kommunikationslücken. --- **Vorlagen und Textbausteine** Vorlagen können Kommunikation: - beschleunigen, - vereinheitlichen, - und bei Stress unterstützen. Sie dürfen jedoch nicht unreflektiert verwendet werden. Eine Vorlage sollte angepasst werden an: - tatsächlichen Sachverhalt, - Zielgruppe, - Auswirkungen, - nächsten Schritt, - und aktuellen Zeitpunkt. Ungeeigneter Textbaustein: > Ihr Anliegen wurde erfolgreich gelöst. wenn der Benutzer die Funktion noch nicht bestätigt hat. Besser: > Die technische Funktion wurde wiederhergestellt. Bitte prüfen Sie, ob Sie den zuvor fehlgeschlagenen Arbeitsschritt jetzt vollständig durchführen können. --- **Beispiel: Eingangsbestätigung** > Ihre Meldung wurde unter der Vorgangsnummer 4711 erfasst. > > Betroffener Service: zentrale Dateiablage > Gemeldete Auswirkung: Dateien lassen sich nicht öffnen > > Der Service Desk prüft zunächst, ob eine allgemeine Störung vorliegt. Die nächste Rückmeldung erfolgt innerhalb der vereinbarten Servicezeit. --- **Beispiel: Rückfrage** > Für die weitere Analyse benötigen wir noch folgende Information: > > - genaue Fehlermeldung, > - Zeitpunkt des letzten erfolgreichen Zugriffs, > - und die Angabe, ob weitere Benutzer betroffen sind. > > Bitte senden Sie keine Kennwörter oder vollständigen vertraulichen Dokumente. --- **Beispiel: Weiterleitung** > Die erste Prüfung zeigt, dass zusätzliche Analyse durch das Netzwerkteam erforderlich ist. > > Der Vorgang wurde mit den bisherigen Prüfergebnissen weitergegeben. Der Service Desk bleibt Ihr Kontaktpunkt. Die nächste Statusmeldung erfolgt spätestens um 14:00 Uhr. --- **Beispiel: Verzögerung** > Die Bearbeitung dauert länger als zunächst erwartet, weil zusätzliche Protokolldaten des Herstellers benötigt werden. > > Die Störung wird weiterhin aktiv untersucht. Die bisherige Zwischenlösung bleibt gültig. Die nächste Aktualisierung erfolgt spätestens um 16:30 Uhr. --- **Beispiel: Wiederherstellung** > Der Zugriff auf die Anwendung ist wiederhergestellt. > > Bitte melden Sie sich erneut an und führen Sie den zuvor fehlgeschlagenen Arbeitsschritt vollständig durch. Teilen Sie uns anschließend kurz mit, ob die Funktion wieder wie erwartet arbeitet. --- **Beispiel: Abschluss** > Sie haben bestätigt, dass die Anwendung wieder vollständig nutzbar ist. > > Ursache war eine fehlerhafte Berechtigungszuordnung. Diese wurde korrigiert. Der Vorgang 4711 wird abgeschlossen. > > Die wiederkehrende Ursache wird zusätzlich durch Problem Management untersucht. --- **Beispiel: Ablehnung mit Alternative** > Die gewünschte lokale Administratorberechtigung kann nicht dauerhaft freigegeben werden, da sie nicht dem Sicherheitsstandard für Arbeitsplatzgeräte entspricht. > > Für die Installation der benötigten Anwendung steht ein genehmigtes Serviceangebot zur Verfügung. Ich habe Ihnen den entsprechenden Antrag verlinkt. --- **KI-gestützte Kommunikation** KI kann unterstützen bei: - Zusammenfassung von Gesprächen, - Übersetzung, - Vorschlägen für Antworten, - Anpassung der Detailtiefe, - Erkennung wiederkehrender Themen, - und Erstellung erster Statusentwürfe. Mögliche Vorteile: - schnellere Erstellung, - einheitlichere Formulierungen, - Unterstützung mehrsprachiger Kontakte, - und Entlastung bei wiederkehrenden Mitteilungen. Mögliche Risiken: - erfundene Fakten, - falsche technische Aussagen, - unangemessener Ton, - Weitergabe vertraulicher Daten, - falsche Priorisierung, - und fehlender Bezug zur tatsächlichen Situation. --- **KI-Ausgaben prüfen** Vor dem Versand einer KI-gestützten Antwort sollte geprüft werden: - Stimmen alle Tatsachen? - Ist der aktuelle Status korrekt? - Ist die Zielgruppe richtig angesprochen? - Sind keine vertraulichen Informationen enthalten? - Werden keine unbelegten Zusagen gemacht? - Ist die technische Anleitung sicher? - Ist der nächste Schritt eindeutig? - Ist eine menschliche Übergabe erforderlich? > **Sicherheitsrelevant** > > KI darf keine unbekannten technischen Schritte oder produktiven Änderungen allein aufgrund plausibel klingender Formulierungen veranlassen. --- **Automatisierte Nachrichten menschlich und präzise gestalten** Ungeeignet: > Ihr Ticket wurde aktualisiert. Besser: > Das Anwendungsteam hat die Analyse übernommen. Für die weitere Prüfung werden derzeit die Anmeldeprotokolle ausgewertet. Sie müssen aktuell nichts weiter tun. Die nächste Statusmeldung erfolgt spätestens um 12:00 Uhr. Automatisierung darf nicht nur interne Statuscodes an Benutzer weitergeben. --- **Kommunikationsqualität messen** Mögliche Informationen: | Messgröße | Mögliche Aussage | |---|---| | Benutzerzufriedenheit | allgemeine Wahrnehmung des Kontakts | | wahrgenommener Aufwand | wie aufwendig der Kontakt für den Benutzer war | | Verständlichkeit | ob Informationen und Anweisungen verstanden wurden | | Vertrauen | ob Benutzer Aussagen und Zusagen als verlässlich erleben | | Wiederholungskontakte | mögliche Hinweise auf fehlende Information oder Lösung | | eingehaltene Statuszusagen | Zuverlässigkeit der Kommunikation | | Anzahl notwendiger Rückfragen | mögliche Hinweise auf unvollständige Erfassung | | Beschwerden | Hinweise auf wiederkehrende Kommunikationsprobleme | | Kanalwechsel | möglicher Hinweis auf ungeeigneten Erstkanal | | Wiedereröffnungsquote | möglicher Hinweis auf voreiligen Abschluss | | Benutzerbestätigung | ob das gewünschte Ergebnis tatsächlich erreicht wurde | Eine einzelne Zufriedenheitszahl reicht nicht aus. --- **Feedback richtig einordnen** Eine negative Bewertung kann sich beziehen auf: - den Mitarbeiter, - die lange Wartezeit, - die technische Produktqualität, - fehlende Befugnisse, - einen Lieferanten, - oder eine organisatorische Vorgabe. Vor Schlussfolgerungen sollte geprüft werden: - Was genau wurde bewertet? - War die Frage verständlich? - Wie hoch ist die Rücklaufquote? - Bestehen wiederkehrende Muster? - Welche Verbesserung ist tatsächlich möglich? Mitarbeiter sollten nicht allein anhand einzelner emotionaler Bewertungen beurteilt werden. --- **Kommunikationsreviews** Eine Organisation kann ausgewählte Kontakte prüfen auf: - sachliche Richtigkeit, - Verständlichkeit, - Respekt, - Vollständigkeit, - Datenschutz, - Sicherheitskonformität, - Erwartungssteuerung, - und Ergebnisorientierung. Die Prüfung sollte der: - Entwicklung, - Schulung, - und Verbesserung dienen. Sie sollte nicht ausschließlich als Überwachung oder Fehlersuche wahrgenommen werden. --- **Gesundheit und emotionale Belastung der Mitarbeiter** Service-Desk-Mitarbeiter bearbeiten möglicherweise: - verärgerte Benutzer, - kritische Ausfälle, - Datenverluste, - Sicherheitsvorfälle, - und dauerhaft hohe Kontaktmengen. Organisationen sollten berücksichtigen: - ausreichende Pausen, - erreichbare Führungskräfte, - Unterstützung nach belastenden Kontakten, - klare Grenzen bei missbräuchlichem Verhalten, - realistische Kennzahlen, - und angemessene Personalkapazität. > **Merke** > > Empathische Kommunikation ist qualifizierte Arbeit. > > Sie benötigt Fähigkeiten, Unterstützung und ausreichende Arbeitsbedingungen. --- **Continual Improvement der Kommunikation** Verbesserungsmöglichkeiten können entstehen durch: - Benutzerfeedback, - Beschwerden, - wiederholte Rückfragen, - abgebrochene Kontakte, - unklare Statusmeldungen, - Fehler in Vorlagen, - und Erfahrungen aus Major Incidents. Mögliche Verbesserungen: - Textbausteine überarbeiten, - Fachbegriffe vereinfachen, - Statusintervalle definieren, - Kommunikationsverantwortung klären, - Mitarbeiterschulungen durchführen, - Portaltexte verbessern, - sichere Übersetzungsunterstützung bereitstellen, - und Zielgruppen genauer unterscheiden. --- **Praxisbeispiel: keine Anmeldung möglich** Benutzer: > Ich kann mich nicht anmelden und brauche die Anwendung sofort. Ungeeignete Antwort: > Haben Sie Ihr Kennwort falsch eingegeben? Bessere Antwort: > Ich verstehe, dass Sie die Anwendung gerade benötigen. Ich kläre zunächst, ob Ihr Konto oder der gesamte Anmeldedienst betroffen ist. Welche Meldung wird angezeigt und können sich Kollegen in derselben Anwendung anmelden? Nach der Prüfung: > Weitere Benutzer sind ebenfalls betroffen. Ihr Kennwort ist deshalb wahrscheinlich nicht die Ursache. Der Identitätsdienst wird bereits untersucht. Bitte ändern Sie Ihr Kennwort nicht erneut. Die nächste Statusmeldung erfolgt um 10:30 Uhr. --- **Praxisbeispiel: verlorene Datei** Benutzer: > Meine Datei ist weg. Da waren zwei Tage Arbeit drin. Ungeeignet: > Sie hätten regelmäßig speichern müssen. Bessere Antwort: > Ich verstehe, dass der mögliche Verlust sehr belastend ist. Bitte speichern oder überschreiben Sie an diesem Speicherort zunächst nichts weiter. Ich prüfe, ob eine frühere Version oder Sicherung verfügbar ist. Wann und unter welchem Namen wurde die Datei zuletzt gespeichert? Wichtig: - keine Schuldzuweisung, - keine unbelegte Wiederherstellungszusage, - und keine Maßnahmen, die vorhandene Wiederherstellungsmöglichkeiten gefährden. --- **Praxisbeispiel: angekündigter Rückruf wurde vergessen** Benutzer: > Mir wurde gestern ein Rückruf versprochen. Es hat sich niemand gemeldet. Geeignete Antwort: > Das hätte nicht passieren dürfen. Der zugesagte Rückruf wurde nicht durchgeführt. Ich prüfe jetzt den aktuellen Bearbeitungsstand und übernehme die Koordination. Sie erhalten spätestens um 11:00 Uhr eine Rückmeldung von mir, auch wenn die technische Analyse dann noch läuft. Zusätzlich sollte intern geprüft werden: - Warum ging die Zusage verloren? - War kein Verantwortlicher eingetragen? - Fehlte eine Erinnerung? - War die Kapazität unzureichend? - Muss der Arbeitsablauf verbessert werden? --- **Praxisbeispiel: Sicherheitskontrolle wird unter Zeitdruck abgelehnt** Benutzer: > Ich bin in fünf Minuten im Termin. Setzen Sie das Kennwort einfach zurück. Geeignete Antwort: > Ich verstehe den Zeitdruck. Die Identitätsprüfung kann ich trotzdem nicht überspringen, weil dadurch ein fremdes Konto übernommen werden könnte. Wir führen jetzt das vorgesehene schnelle Prüfverfahren durch. Danach kann ich die Zurücksetzung sofort veranlassen. --- **Praxisbeispiel: technisches Team benötigt mehr Zeit** Statusmeldung: > Die Anwendung ist weiterhin nicht verfügbar. Das Team hat die Datenbankverbindung als Fehlerbereich eingegrenzt, aber die genaue Ursache ist noch nicht bestätigt. Eine Wiederherstellungsschätzung liegt deshalb noch nicht vor. Die alternative Anwendung kann weiterhin verwendet werden. Nächste Statusmeldung: 15:30 Uhr. Diese Meldung: - benennt den aktuellen Stand, - vermeidet eine ungesicherte Zeitangabe, - nennt eine Alternative, - und gibt einen verbindlichen nächsten Informationszeitpunkt. --- **Praxisbeispiel: Ticket wurde voreilig geschlossen** Benutzer: > Das Ticket ist geschlossen, aber der Fehler ist noch da. Geeignete Antwort: > Danke für den Hinweis. Der Vorgang wurde zu früh geschlossen. Ich öffne ihn erneut und dokumentiere, dass die technische Maßnahme das Benutzerproblem nicht gelöst hat. Wir prüfen jetzt den vollständigen Arbeitsschritt noch einmal. Anschließend sollte untersucht werden: - Wurde nur eine technische Komponente geprüft? - Fehlte die Benutzerbestätigung? - Belohnte eine Kennzahl den schnellen Abschluss? - War die Abschlussregel unklar? --- **Typische Kommunikationsfehler** **Fehler 1: Zu früh eine Lösung vermuten** Der Benutzer wird in eine falsche Diagnoserichtung gelenkt. --- **Fehler 2: Fachbegriffe ohne Erklärung verwenden** Der Benutzer versteht weder Situation noch nächsten Schritt. --- **Fehler 3: Auswirkungen verharmlosen** Die technische Störung wirkt klein, blockiert aber einen wichtigen Arbeitsprozess. --- **Fehler 4: Unbelegte Zeitversprechen geben** Vertrauen sinkt, sobald die Zusage nicht eingehalten wird. --- **Fehler 5: Nur bei neuen Erkenntnissen informieren** Benutzer bleiben lange ohne Status. --- **Fehler 6: „Ich gebe es weiter“ ohne Verantwortung** Nächster Schritt, Kommunikationsweg und Zuständigkeit bleiben unklar. --- **Fehler 7: Benutzer oder andere Teams beschuldigen** Zusammenarbeit und Vertrauen werden beschädigt. --- **Fehler 8: Empathie mit Zustimmung verwechseln** Prioritäts-, Sicherheits- oder Genehmigungsregeln werden unnötig aufgegeben. --- **Fehler 9: Standardtexte unverändert senden** Die Nachricht passt nicht zur tatsächlichen Situation. --- **Fehler 10: Technische Wiederherstellung mit Benutzer-Outcome verwechseln** Ticket wird geschlossen, obwohl die Tätigkeit weiterhin nicht möglich ist. --- **Fehler 11: Verärgerte Benutzer persönlich angreifen** Die Situation eskaliert weiter. --- **Fehler 12: Beleidigungen unbegrenzt akzeptieren** Mitarbeiterschutz und professionelle Grenzen fehlen. --- **Fehler 13: Sensible Informationen im falschen Kanal teilen** Datenschutz- oder Sicherheitsrisiken entstehen. --- **Fehler 14: Widersprüchliche Meldungen mehrerer Teams** Es fehlt eine geklärte Kommunikationsverantwortung. --- **Fehler 15: KI-Entwürfe ungeprüft versenden** Falsche Aussagen oder unangemessene Formulierungen erreichen Benutzer. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker kommunizieren nicht nur innerhalb des Service Desk. Sie kommunizieren ebenfalls bei: - technischen Rückfragen, - Remote-Support, - Changes, - Wartungsarbeiten, - Incidents, - Lieferantenkontakten, - und Übergaben an andere Teams. Eine gute technische Rückmeldung sollte beantworten: - Was wurde geprüft? - Welches Ergebnis liegt vor? - Was ist weiterhin unbekannt? - Welche Auswirkungen bestehen? - Was ist der nächste Schritt? - Wer übernimmt ihn? - Wann ist mit einer Rückmeldung zu rechnen? - Welche Benutzerinformation ist geeignet? Ungeeignete technische Rückmeldung: > Server läuft wieder. Besser: > Der Anwendungsdienst wurde um 14:20 Uhr wiederhergestellt. Technische Funktionsprüfungen sind erfolgreich. Zwei Testbenutzer konnten sich anmelden und Datensätze speichern. Der Service wird bis 16:00 Uhr verstärkt überwacht. Die Ursache wird noch durch Problem Management untersucht. --- **30-Sekunden-Prüfung einer Benutzerkommunikation** 1. **Zielgruppe:** Mit wem kommuniziere ich? 2. **Anliegen:** Was benötigt die Person tatsächlich? 3. **Auswirkung:** Welche Arbeit oder welches Outcome ist betroffen? 4. **Verständlichkeit:** Ist die Sprache für die Zielgruppe geeignet? 5. **Fakten:** Welche Aussagen sind bestätigt? 6. **Unsicherheit:** Was ist noch nicht bekannt? 7. **Handlung:** Was geschieht als Nächstes? 8. **Verantwortung:** Wer übernimmt die nächste Aufgabe? 9. **Zeit:** Wann folgt die nächste Information? 10. **Sicherheit:** Darf der Inhalt über diesen Kanal geteilt werden? 11. **Ergebnis:** Wie wird das Outcome bestätigt? 12. **Respekt:** Ist die Formulierung sachlich und professionell? --- **Checkliste für ein professionelles Gespräch** - [ ] Wurde freundlich und eindeutig eröffnet? - [ ] Wurde die Identität bei Bedarf geprüft? - [ ] Konnte der Benutzer das Anliegen zunächst beschreiben? - [ ] Wurden gezielte Rückfragen gestellt? - [ ] Wurden Auswirkungen und Umfang verstanden? - [ ] Wurde das Verstandene zusammengefasst? - [ ] Wurden Fachbegriffe erklärt oder vermieden? - [ ] Wurde der nächste Schritt beschrieben? - [ ] Wurden keine unbelegten Zusagen gemacht? - [ ] Wurde ein nächster Informationszeitpunkt genannt? - [ ] Wurde das Ergebnis aus Benutzersicht geprüft? - [ ] Wurde der Kontakt klar abgeschlossen? --- **Checkliste für schriftliche Nachrichten** - [ ] Ist der Betreff eindeutig? - [ ] Steht die wichtigste Information am Anfang? - [ ] Ist der betroffene Service genannt? - [ ] Sind bekannte Auswirkungen beschrieben? - [ ] Sind Fakten und Vermutungen getrennt? - [ ] Ist eine Handlung des Benutzers eindeutig gekennzeichnet? - [ ] Ist der nächste Schritt genannt? - [ ] Ist der nächste Statuszeitpunkt angegeben? - [ ] Sind technische Begriffe für die Zielgruppe verständlich? - [ ] Sind Empfänger und Kanal datenschutzgerecht? - [ ] Wurden vertrauliche Details entfernt? - [ ] Ist die Vorgangsnummer enthalten? --- **Checkliste für Statusmeldungen** - [ ] Was ist betroffen? - [ ] Seit wann besteht die Situation? - [ ] Welche Auswirkungen sind bekannt? - [ ] Welche Bearbeitung läuft? - [ ] Welche Informationen sind bestätigt? - [ ] Gibt es eine Zwischenlösung? - [ ] Müssen Benutzer etwas tun? - [ ] Wann folgt die nächste Meldung? - [ ] Ist die Zielgruppe richtig gewählt? - [ ] Ist die Aussage mit der Incident-Koordination abgestimmt? - [ ] Wurden Sicherheits- und Datenschutzanforderungen beachtet? --- **Checkliste für schwierige Gespräche** - [ ] Bleibt die eigene Stimme ruhig und sachlich? - [ ] Wurde die Auswirkung anerkannt? - [ ] Wurde nicht vorschnell widersprochen? - [ ] Wurden Fakten und nächste Schritte genannt? - [ ] Wurden klare Grenzen erklärt? - [ ] Werden Sicherheitskontrollen nicht umgangen? - [ ] Wurde ein realistischer nächster Zeitpunkt vereinbart? - [ ] Ist bei Beleidigungen oder Drohungen eine Eskalation vorgesehen? - [ ] Benötigt der Mitarbeiter nach dem Kontakt Unterstützung? - [ ] Muss die Beschwerde oder das Muster ausgewertet werden? --- **Checkliste vor dem Abschluss eines Vorgangs** - [ ] Wurde das ursprüngliche Anliegen erneut betrachtet? - [ ] Ist die technische Funktion wiederhergestellt? - [ ] Kann der Benutzer den vollständigen Arbeitsschritt durchführen? - [ ] Wurde das Ergebnis bestätigt? - [ ] Sind offene Risiken oder Einschränkungen kommuniziert? - [ ] Wurde die Lösung verständlich dokumentiert? - [ ] Sind weitere Maßnahmen eindeutig zugeordnet? - [ ] Muss Problem Management einbezogen werden? - [ ] Muss ein Wissensartikel aktualisiert werden? - [ ] Muss eine Verbesserung erfasst werden? --- **Checkliste für KI-gestützte Kommunikation** - [ ] Wurde der Text von einer zuständigen Person geprüft? - [ ] Sind alle technischen Aussagen korrekt? - [ ] Entspricht der Status dem aktuellen Vorgang? - [ ] Werden keine Ursachen erfunden? - [ ] Werden keine unbelegten Zeitangaben gemacht? - [ ] Ist die Sprache respektvoll und zielgruppengerecht? - [ ] Sind keine vertraulichen Daten enthalten? - [ ] Sind Handlungsanweisungen sicher? - [ ] Ist ein menschlicher Kontaktweg vorhanden? - [ ] Wird die Verwendung der KI entsprechend den Vorgaben der Organisation gesteuert? --- **Schnellreferenz für Formulierungen** | Situation | Geeignete Formulierung | |---|---| | Auswirkung anerkennen | Ich verstehe, dass die Störung Ihren Arbeitsablauf gerade vollständig blockiert. | | Verständnis prüfen | Ich fasse kurz zusammen, damit ich nichts übersehen habe. | | Ursache unbekannt | Die genaue Ursache ist noch nicht bestätigt. | | keine Lösungszeit bekannt | Eine verlässliche Wiederherstellungszeit liegt noch nicht vor. | | nächste Rückmeldung | Sie erhalten spätestens um 14:00 Uhr eine weitere Statusmeldung. | | Weiterleitung | Ich binde das Netzwerkteam mit den bisherigen Prüfergebnissen ein. | | Verantwortung behalten | Der Service Desk bleibt Ihr Kontaktpunkt und informiert Sie weiter. | | Sicherheitsregel erklären | Die Identitätsprüfung kann ich aus Sicherheitsgründen nicht überspringen. | | Alternative anbieten | Als Zwischenlösung können Sie derzeit Arbeitsplatz 4 verwenden. | | Ergebnis prüfen | Können Sie den zuvor fehlgeschlagenen Arbeitsschritt jetzt vollständig durchführen? | | Fehler eingestehen | Der zugesagte Rückruf ist nicht erfolgt. Ich übernehme jetzt die weitere Koordination. | | respektvolle Grenze | Ich bearbeite Ihr Anliegen gern weiter, benötige dafür aber ein Gespräch ohne Beleidigungen. | --- **Zusammenfassende Darstellung** > Benutzer schildert ein Anliegen > ↓ > aufmerksam zuhören und Auswirkung verstehen > ↓ > gezielt nachfragen > ↓ > das Verstandene zusammenfassen > ↓ > Situation fachlich und verständlich einordnen > ↓ > nächsten Schritt und Verantwortung erklären > ↓ > realistische Erwartungen und Statuszeitpunkt vereinbaren > ↓ > regelmäßig, ehrlich und zielgruppengerecht informieren > ↓ > technisches Ergebnis und Benutzer-Outcome prüfen > ↓ > Kontakt professionell abschließen > ↓ > Feedback, Beschwerden und Kommunikationsprobleme verbessern --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.2 Kontaktkanäle und Erreichbarkeit - 3.4 Tickets vollständig erfassen und kategorisieren - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Incident Management - Service Request Management - Knowledge Management - Relationship Management - Service Level Management - Information Security Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706) - [ITIL: The ongoing relevance of the service desk in an AI world](https://www.itil.com/Itil-News-and-Announcements/service-desk-relevance-ai-world) - [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/ITIL-Service-Version-5) - [ITIL: ITIL Service Version 5 – An enterprise-wide approach to service thinking](https://www.itil.com/Itil-News-and-Announcements/itil-service-version-5) - [ITIL: ITIL Experience – Version 5](https://www.itil.com/professionals/certifications/ITIL-Experience-Version-5) - [ITIL: ITIL Experience Version 5 – Making digital technology feel as good as it functions](https://www.itil.com/Itil-News-and-Announcements/itil-experience-version-5) - [ITIL: How ITIL Experience Version 5 puts user experience at the core of service and availability](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-experience-user-experience) - [PeopleCert: ITIL Foundation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) **Offiziell bestätigter Stand** Die offiziellen ITIL- und PeopleCert-Quellen bestätigen: - Der Service Desk stellt einen zentralen Kontaktpunkt zwischen Service Provider und Benutzern bereit und unterstützt eine wirksame Kommunikation. - Service-Desk-Mitarbeiter benötigen überdurchschnittliche Kommunikationsfähigkeiten und müssen Gespräche an unterschiedliche Kenntnisse und Bedürfnisse der Benutzer anpassen. - Empathie und Verständnis des Benutzerkontexts sind wesentliche Fähigkeiten moderner Service-Desk-Arbeit. - ITIL Version 5 stärkt die Betrachtung von Benutzer- und Kundenerfahrung innerhalb des digitalen Produkt- und Service-Managements. - Eine technisch funktionierende Leistung kann trotzdem eine unzureichende Erfahrung erzeugen. - Kommunikation während Störungen beeinflusst Vertrauen, Wahrnehmung und Serviceerfahrung. - KI kann Kommunikation, Zusammenfassung, Übersetzung und Personalisierung unterstützen, benötigt aber Governance, menschliche Kontrolle und definierte Übergaberegeln. - Menschliche Kommunikation bleibt besonders bei komplexen, emotional belastenden und unsicheren Situationen wichtig. **Einordnung** Die auf dieser Seite dargestellten: - Gesprächsstrukturen, - Formulierungsbeispiele, - Statusvorlagen, - Deeskalationshinweise, - Checklisten, - Kommunikationsregeln, - und Praxisbeispiele sind herstellerneutrale redaktionelle Empfehlungen dieses unabhängigen Nachschlagewerks. Sie stellen keine wörtlichen offiziellen ITIL-Skripte und keine für jede Organisation verbindlichen Kommunikationsabläufe dar. Die konkrete Kommunikation muss angepasst werden an: - Zielgruppe, - Kanal, - Service, - Auswirkung, - Sicherheitsanforderungen, - Datenschutz, - organisatorische Rollen, - und die jeweils bestätigte Informationslage. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Service-Desk-Guidance **Fachlicher Stand:** August 2026 # 3.4 Tickets vollständig erfassen und kategorisieren > **Kurz erklärt** > > Ein Ticket dokumentiert einen Kontakt, eine Störung, eine Anfrage oder eine andere zu bearbeitende Arbeitseinheit. > > Ein gutes Ticket macht nachvollziehbar: > > - wer Unterstützung benötigt, > - welcher Service betroffen ist, > - was beobachtet wurde, > - welche Auswirkungen bestehen, > - seit wann die Situation besteht, > - was bereits geprüft oder durchgeführt wurde, > - wer aktuell verantwortlich ist, > - welcher nächste Schritt notwendig ist, > - und welches Ergebnis erreicht wurde. > > Die Kategorisierung ordnet den Vorgang so ein, dass: > > - die richtige Bearbeitung gefunden, > - geeignetes Wissen angezeigt, > - ähnliche Vorgänge erkannt, > - Berichte erstellt, > - und Verbesserungsmöglichkeiten sichtbar > > werden können. > > ITIL schreibt kein universelles Ticketformular, kein verpflichtendes Kategoriemodell und keinen für alle Organisationen identischen Ticketstatus vor. > > Felder, Kategorien und Arbeitsabläufe müssen zu den Services, Wertströmen, Risiken und Informationsbedürfnissen der jeweiligen Organisation passen. --- **Warum eine gute Ticketqualität wichtig ist** Ein Ticket ist nicht nur eine technische Notiz. Es unterstützt unter anderem: - Kommunikation, - Priorisierung, - Diagnose, - Weiterleitung, - Eskalation, - Zusammenarbeit, - Nachvollziehbarkeit, - Messung, - Wissensmanagement, - Problem Management, - Lieferantensteuerung, - und Continual Improvement. Unvollständige oder unklare Tickets führen häufig zu: - wiederholten Rückfragen, - unnötigen Übergaben, - falscher Priorisierung, - längeren Wartezeiten, - doppelter Arbeit, - ungeeigneten Lösungsversuchen, - fehlender Benutzerkommunikation, - und schlechter Auswertbarkeit. Beispiel für ein unzureichendes Ticket: > Drucker geht nicht. Daraus ist nicht erkennbar: - welcher Drucker betroffen ist, - welcher Benutzer Unterstützung benötigt, - welche Tätigkeit blockiert ist, - welche Fehlermeldung erscheint, - ob weitere Benutzer betroffen sind, - ob ein alternativer Drucker verfügbar ist, - und was bereits geprüft wurde. Eine bessere Erfassung könnte lauten: > Seit etwa 08:20 Uhr können alle vier Arbeitsplätze im Warenausgang keine Versandetiketten über Drucker WD-ET-01 ausgeben. Normale Bürodrucker funktionieren. Am Etikettendrucker wird „Druckauftrag nicht verfügbar“ angezeigt. Der Drucker ist eingeschaltet und im Netzwerk erreichbar. Die Druckwarteschlange enthält zwölf offene Aufträge. Der Versandprozess ist derzeit unterbrochen und es besteht kein zugelassener Ersatzdrucker. > **Merke** > > Je besser ein Ticket den tatsächlichen Arbeits- und Servicekontext beschreibt, desto weniger muss die nächste bearbeitende Person erneut erfragen. --- **Ticket ist ein praktischer Sammelbegriff** Der Begriff **Ticket** wird in vielen ITSM-Werkzeugen als allgemeine Bezeichnung für einen dokumentierten Vorgang verwendet. Je nach Inhalt kann ein Ticket beispielsweise repräsentieren: - einen Incident, - einen Service Request, - eine Frage, - eine Beschwerde, - eine Sicherheitsmeldung, - eine Aufgabe, - einen Problem Record, - einen Change, - oder einen Lieferantenfall. Diese Vorgangsarten besitzen unterschiedliche Zwecke. | Vorgangsart | Typischer Zweck | |---|---| | **Kontakt** | Interaktion mit einem Benutzer oder Stakeholder dokumentieren | | **Incident** | negative Serviceauswirkung behandeln und Service wiederherstellen | | **Service Request** | vorgesehene Benutzeranfrage erfüllen | | **Problem** | Ursache oder mögliche Ursache von Incidents untersuchen | | **Change** | eine Änderung bewerten, autorisieren und kontrolliert steuern | | **Security Incident** | mögliches oder bestätigtes Sicherheitsereignis behandeln | | **Aufgabe** | abgegrenzte Tätigkeit innerhalb eines größeren Vorgangs durchführen | | **Lieferantenfall** | externe Unterstützung oder vertragliche Leistung anfordern | > **Wichtig** > > Nicht jedes Ticket ist ein Incident. > > Nicht jede Benutzerfrage ist ein Service Request. > > Die richtige Vorgangsart beeinflusst Bearbeitung, Verantwortung, Messung und Abschlusskriterien. --- **Kontakt, Ticket und zugrunde liegender Vorgang unterscheiden** Ein Benutzerkontakt und ein Ticket sind nicht immer identisch. Beispiel: 1. Ein Benutzer meldet telefonisch einen Ausfall. 2. Der Service Desk erstellt ein Incident-Ticket. 3. Drei weitere Benutzer melden dasselbe Problem per Chat. 4. Diese Kontakte werden mit dem bereits bestehenden Incident verknüpft. 5. Ein technisches Team erhält eine zugehörige Diagnoseaufgabe. 6. Ein Provider erhält einen verknüpften Lieferantenfall. 7. Nach der Wiederherstellung wird ein Problem Record für die Ursachenanalyse eröffnet. Es bestehen damit: - mehrere Benutzerkontakte, - ein gemeinsamer Incident, - technische Teilaufgaben, - ein Lieferantenfall, - und möglicherweise ein nachgelagertes Problem. > **Merke** > > Nicht jede neue Meldung benötigt einen vollständig unabhängigen Incident. > > Mehrere Kontakte können dieselbe zugrunde liegende Störung betreffen. --- **Ziel der Ticket-Erfassung** Die Erfassung soll ausreichende Informationen bereitstellen, damit die Organisation: - das Anliegen versteht, - die richtige Vorgangsart bestimmt, - Auswirkungen und Dringlichkeit bewertet, - geeignete Fähigkeiten einbindet, - Fortschritt und Kommunikation nachvollzieht, - das Ergebnis überprüft, - und relevante Erkenntnisse weiterverwendet. Das Ziel ist nicht: - möglichst viele Felder auszufüllen, - jeden technischen Wert zu speichern, - oder Benutzer mit einem umfangreichen Formular zu belasten. > **Grundsatz** > > Es sollen so viele Informationen wie notwendig und so wenige wie möglich erfasst werden. --- **Ein mögliches Mindestset an Ticketinformationen** Abhängig von Vorgangsart und Organisation können folgende Informationen sinnvoll sein: | Information | Zweck | |---|---| | **Vorgangsnummer** | eindeutige Referenz | | **Erstellungszeitpunkt** | zeitliche Nachvollziehbarkeit | | **Meldekanal** | Herkunft und Kommunikationskontext | | **meldende Person** | Kontakt und Rückfragen | | **betroffene Person oder Gruppe** | tatsächliche Auswirkung bestimmen | | **betroffener Service** | serviceorientierte Einordnung | | **kurzer Titel** | schnelle verständliche Übersicht | | **Beschreibung** | Situation und Beobachtung dokumentieren | | **Beginn** | zeitliche Einordnung der Beeinträchtigung | | **Auswirkung** | Umfang und Geschäftsbezug | | **Dringlichkeit** | zeitliche Bedeutung | | **Priorität** | organisatorisch bestimmte Bearbeitungsreihenfolge | | **Kategorie** | Zuordnung und Auswertung | | **aktueller Status** | Bearbeitungsstand | | **verantwortliche Rolle oder Gruppe** | aktuelles Ownership | | **bisherige Maßnahmen** | doppelte Arbeit vermeiden | | **Ergebnisse der Maßnahmen** | Diagnose nachvollziehen | | **nächster Schritt** | Bearbeitung fortsetzen | | **Kommunikationszeitpunkt** | Benutzerinformation sicherstellen | | **Lösung oder Erfüllung** | Ergebnis dokumentieren | | **Abschlussbestätigung** | tatsächliches Outcome prüfen | | **verknüpfte Vorgänge** | Zusammenhänge sichtbar machen | Nicht jede Vorgangsart benötigt alle Felder. Ein einfacher Informationskontakt benötigt möglicherweise deutlich weniger Daten als ein kritischer Incident. --- **Meldende Person und betroffener Benutzer unterscheiden** Die Person, die ein Ticket meldet, ist nicht immer selbst betroffen. Beispiele: - Eine Führungskraft meldet eine Störung für ihr Team. - Die Personalabteilung bestellt einen Arbeitsplatz für einen neuen Mitarbeiter. - Monitoring meldet einen technischen Zustand ohne menschlichen Anrufer. - Ein Kollege meldet den Verlust des Geräts einer anderen Person. - Ein externer Kunde meldet eine Störung für mehrere Benutzer. - Ein Administrator erfasst einen Incident aufgrund eigener Beobachtung. Deshalb können getrennte Felder sinnvoll sein für: - meldende Person, - betroffene Person, - betroffene Organisationseinheit, - betroffenen Standort, - und bevorzugten Kommunikationskontakt. > **Typischer Fehler** > > Das Ticket wird automatisch der meldenden Person zugeordnet, obwohl eine andere Person oder ein ganzer Bereich betroffen ist. --- **Der betroffene Service gehört in den Mittelpunkt** Eine serviceorientierte Erfassung fragt nicht nur: > Welche technische Komponente ist defekt? Sondern zuerst: > Welcher Service oder welche Arbeitsfähigkeit ist beeinträchtigt? Beispiel: Technische Komponente: > Datenbankserver DB-02 Betroffener Service: > Warenwirtschaftssystem Geschäftliche Auswirkung: > Lager kann keine Warenausgänge buchen. Die Komponente kann für Diagnose und technische Zuordnung wichtig sein. Der Service ist jedoch entscheidend für: - Auswirkungen, - Kommunikation, - Serviceziele, - Stakeholder, - und Priorisierung. --- **Service und Configuration Item unterscheiden** | Information | Beispiel | |---|---| | **betroffener Service** | zentraler Dateiservice | | **betroffene Anwendung** | Dokumentenmanagement | | **Configuration Item** | Fileserver FS-03 | | **Asset** | physischer Server mit Inventarnummer | | **Standort** | Berlin-Nord | | **Benutzergruppe** | Buchhaltung | Ein Incident kann mehrere Configuration Items betreffen. Ein einzelnes Configuration Item kann mehrere Services unterstützen. Deshalb sollte das Ticket nicht ausschließlich anhand der vermuteten Komponente eingeordnet werden. --- **Einen guten Tickettitel formulieren** Der Titel sollte die Situation kurz und eindeutig zusammenfassen. Ungeeignete Titel: - Problem - Hilfe - Geht nicht - Dringend - Fehler 4711 - Bitte prüfen - Benutzerproblem - Server Bessere Titel: - Anmeldung am Zeiterfassungssystem nicht möglich - Zentrale Dateiablage am Standort Nord nicht erreichbar - Versandetiketten können im Warenausgang nicht gedruckt werden - Standardsoftware für neuen Arbeitsplatz anfordern - Verdächtige Anmeldung für Benutzerkonto erkannt - Wiederherstellung einer gelöschten Projektdatei prüfen Ein guter Titel enthält häufig: - betroffenen Service oder Arbeitsbereich, - beobachtetes Symptom, - und gegebenenfalls betroffenen Standort oder Umfang. > **Praxistipp** > > Der Titel sollte auch für eine Person verständlich sein, die das Ticket nicht selbst erfasst hat. --- **Symptom statt vermuteter Ursache dokumentieren** Zu Beginn eines Incidents ist die tatsächliche Ursache häufig unbekannt. Ungeeignet: > Firewall blockiert Anwendung. wenn dies nur vermutet wird. Besser: > Anwendung ist vom Standort Süd nicht über HTTPS erreichbar. Andere Standorte sind nach aktueller Prüfung nicht betroffen. Eine Firewall-Regel ist eine mögliche, aber noch nicht bestätigte Ursache. Die Dokumentation sollte unterscheiden zwischen: - Beobachtung, - Messergebnis, - Vermutung, - und bestätigter Ursache. | Art | Beispiel | |---|---| | **Beobachtung** | Benutzer erhält „Verbindung nicht möglich“ | | **Messergebnis** | TCP-Verbindung zu Port 443 schlägt fehl | | **Vermutung** | mögliche Blockierung durch Firewall | | **bestätigte Ursache** | Regel FW-182 wurde beim letzten Change nicht übernommen | > **Merke** > > Eine früh eingetragene Vermutung darf nicht unbemerkt zur scheinbar bestätigten Tatsache werden. --- **Fakten und Bewertungen trennen** Ungeeignet: > Benutzer hat wieder die falsche Anwendung benutzt. Besser: > Der Benutzer öffnete die bisher verwendete Anwendungsversion 4.2. Seit dem Change vom 1. August ist Version 5.0 erforderlich. Die bisherige Verknüpfung auf dem Desktop wurde nicht aktualisiert. Ungeeignet: > Netzwerk ist instabil. Besser: > Zwischen 09:10 Uhr und 09:25 Uhr gingen 18 von 100 ICMP-Paketen verloren. Zwei VoIP-Gespräche wurden in diesem Zeitraum unterbrochen. Sachliche Dokumentation verbessert: - Zusammenarbeit, - technische Analyse, - Nachvollziehbarkeit, - und professionellen Umgang. --- **Die ursprünglichen Benutzerangaben erhalten** Die Beschreibung des Benutzers kann wichtige Hinweise enthalten. Beispiel: > „Beim Speichern erscheint immer die Meldung, dass der Datensatz bereits bearbeitet wird.“ Diese ursprüngliche Beobachtung sollte nicht vollständig durch eine technische Interpretation ersetzt werden. Eine gute Dokumentation kann enthalten: - ursprüngliche Benutzerbeschreibung, - strukturierte Zusammenfassung, - technische Beobachtungen, - und durchgeführte Diagnose. Dadurch bleibt nachvollziehbar: - was der Benutzer erlebt hat, - und wie die Organisation die Situation eingeordnet hat. --- **Zeitangaben vollständig erfassen** Zeitinformationen können für Analyse und Korrelation entscheidend sein. Hilfreiche Angaben: - Beginn der Störung, - Zeitpunkt der Meldung, - letzter bekannter erfolgreicher Zugriff, - Zeitpunkt einer Änderung, - Zeitpunkt einzelner Diagnosemaßnahmen, - Wiederherstellungszeitpunkt, - und Abschlusszeitpunkt. Beispiel: > Letzter erfolgreicher Zugriff: 08:47 Uhr > Erste Fehlermeldung: 08:52 Uhr > Meldung beim Service Desk: 09:03 Uhr > letzter relevanter Change: 07:30 Uhr Diese Informationen können mit: - Monitoring, - Logs, - Changes, - Sicherheitsereignissen, - und Lieferantenmeldungen verglichen werden. > **Typischer Fehler** > > Im Ticket steht nur das Erstellungsdatum. Der tatsächliche Beginn der Beeinträchtigung bleibt unbekannt. --- **Auswirkungen vollständig beschreiben** Die Auswirkungen bestimmen, was der Incident für Benutzer und Organisation bedeutet. Zu erfassen sind möglicherweise: - Anzahl betroffener Benutzer, - betroffene Standorte, - betroffene Geschäftsprozesse, - vollständiger oder teilweiser Ausfall, - verfügbare Zwischenlösung, - mögliche Sicherheitsauswirkung, - möglicher Datenverlust, - Kundenwirkung, - und zeitkritische Termine. Unzureichend: > Ein Benutzer betroffen. Besser: > Betroffen ist der einzige Arbeitsplatz, über den die Produktionsfreigabe durchgeführt werden kann. Ohne Freigabe steht die Fertigungslinie ab 10:00 Uhr still. Ein Ersatzarbeitsplatz ist nicht verfügbar. Das Beispiel zeigt: Die reine Benutzeranzahl beschreibt nicht immer die tatsächliche Auswirkung. --- **Dringlichkeit nicht nur vom Benutzer übernehmen** Benutzer können ihre gewünschte Dringlichkeit mitteilen. Die Organisation muss sie jedoch anhand festgelegter Kriterien bewerten. Ein Benutzer kann beispielsweise „sehr dringend“ auswählen, weil: - er unter Zeitdruck steht, - er eine schnelle Bearbeitung erwartet, - oder die Bedeutung der Auswahl nicht erklärt wurde. Das Ticket sollte deshalb unterscheiden zwischen: - vom Benutzer angegebener Dringlichkeit, - organisatorisch bewerteter Dringlichkeit, - Auswirkung, - und daraus bestimmter Priorität. Die genaue Bewertung wird auf der Seite **3.5 Auswirkungen, Dringlichkeit und Priorität** vertieft. --- **Die Beschreibung sollte den Normalzustand enthalten** Für die Diagnose ist hilfreich zu wissen: - Was sollte normalerweise geschehen? - Was geschieht stattdessen? - Unter welchen Bedingungen tritt der Fehler auf? Beispiel: > Normalerweise wird nach Auswahl von „Auftrag abschließen“ innerhalb weniger Sekunden eine PDF-Rechnung erzeugt. Seit heute 08:30 Uhr bleibt der Ladebildschirm dauerhaft sichtbar. Der Auftrag wird nicht abgeschlossen und es wird keine Fehlermeldung angezeigt. Diese Beschreibung ist aussagekräftiger als: > Rechnung funktioniert nicht. --- **Reproduzierbarkeit dokumentieren** Hilfreiche Angaben: - tritt der Fehler immer oder nur manchmal auf, - bei welchen Schritten tritt er auf, - auf welchen Geräten oder Versionen, - bei welchen Benutzern, - mit welchen Daten, - und unter welchen Bedingungen. Beispiel: 1. Anwendung öffnen 2. Auftrag 4711 auswählen 3. „PDF exportieren“ anklicken 4. Anwendung schließt sich ohne Fehlermeldung Zusätzlich: - tritt bei drei getesteten Aufträgen auf, - nur in Version 5.2, - Webversion nicht betroffen. > **Wichtig** > > Reproduktionsschritte dürfen keine vertraulichen Daten oder unsicheren Handlungen unnötig offenlegen. --- **Bereits durchgeführte Maßnahmen dokumentieren** Das Ticket sollte zeigen: - welche Maßnahme durchgeführt wurde, - wer sie durchgeführt hat, - wann sie durchgeführt wurde, - warum sie durchgeführt wurde, - und welches Ergebnis entstand. Unzureichend: > Neustart gemacht. Besser: > 10:12 Uhr – Anwendungsdienst APP-SVC auf Server APP-02 kontrolliert neu gestartet, nachdem der Prozess nicht mehr auf Health Checks reagierte. Dienst startete erfolgreich. Technischer Health Check ist wieder grün. Benutzeranmeldung schlägt jedoch weiterhin fehl. Dadurch wird deutlich: - der Neustart war technisch erfolgreich, - das ursprüngliche Outcome wurde aber noch nicht erreicht. --- **Maßnahme und Ergebnis getrennt dokumentieren** | Maßnahme | Ergebnis | |---|---| | DNS-Cache geleert | Fehler besteht unverändert | | Anwendung neu gestartet | Anmeldung funktioniert einmalig | | anderes Benutzerkonto getestet | ebenfalls betroffen | | Zugriff über Mobilfunk getestet | funktioniert | | Firewall-Regel geprüft | Regel vorhanden und aktiv | | Provider kontaktiert | externe Störung bestätigt | Diese Trennung verhindert unklare Notizen wie: > Alles geprüft. --- **Chronologische Arbeitsnotizen** Eine chronologische Dokumentation unterstützt: - Schichtübergaben, - Major-Incident-Koordination, - Lieferanteneskalation, - spätere Analyse, - und Auditierbarkeit. Beispiel: > **09:05 Uhr:** Incident durch Service Desk erfasst. Fünf Benutzer betroffen. > **09:12 Uhr:** Allgemeine Statusseite geprüft, keine bekannte Herstellerstörung. > **09:18 Uhr:** Anwendung von Standort Nord und Süd getestet. Nur Nord betroffen. > **09:25 Uhr:** Netzwerkteam eingebunden. > **09:40 Uhr:** Standorttunnel zeigt Paketverlust. Providerfall P-8821 eröffnet. > **10:00 Uhr:** Benutzerstatus aktualisiert. Nächstes Update 10:30 Uhr. Arbeitsnotizen sollten nicht nachträglich so verändert werden, dass wesentliche Entscheidungen oder frühere Zustände nicht mehr nachvollziehbar sind. Korrekturen sollten transparent erfolgen. --- **Interne und externe Notizen unterscheiden** Viele Ticketsysteme bieten: - interne Arbeitsnotizen, - und für Benutzer sichtbare Kommentare. **Interne Arbeitsnotizen** Können enthalten: - technische Diagnose, - Hypothesen, - interne Koordination, - sicher freigegebene Protokollauszüge, - und interne Zuständigkeiten. **Benutzersichtbare Kommentare** Sollten enthalten: - verständlichen Status, - Auswirkungen, - nächste Schritte, - Handlungshinweise, - und nächsten Informationszeitpunkt. > **Sicherheitsrelevant** > > Interne Notizen sind nicht automatisch für jede vertrauliche Information geeignet. > > Zugriffsrechte, Aufbewahrung und Datenklassifizierung müssen berücksichtigt werden. --- **Kategorisierung** Kategorisierung ordnet einen Vorgang nach festgelegten Merkmalen ein. Sie kann unterstützen bei: - automatischer oder manueller Zuweisung, - Anzeige passenden Wissens, - Prioritätsregeln, - Service-Level-Zuordnung, - Erkennung ähnlicher Vorgänge, - Trendanalyse, - Problem Management, - und Continual Improvement. Eine Kategorie sollte einen konkreten Nutzen besitzen. > **Typischer Fehler** > > Kategorien werden nur deshalb angelegt, weil das Werkzeug beliebig viele Ebenen ermöglicht. --- **Ein einfaches Kategoriemodell** Eine mögliche Struktur lautet: > Service → Anliegenart → Symptom Beispiel: > Dateiablage → Incident → Zugriff nicht möglich Weitere Beispiele: - E-Mail → Incident → Nachrichtenversand fehlerhaft - Arbeitsplatz → Service Request → Standardsoftware anfordern - Benutzerkonto → Incident → Konto gesperrt - Netzwerkzugang → Incident → WLAN-Verbindung unterbrochen - Berechtigung → Service Request → Gruppenmitgliedschaft beantragen - Informationssicherheit → Sicherheitsmeldung → verdächtige E-Mail Die konkrete Struktur wird von der Organisation festgelegt. --- **Serviceorientierte und technische Kategorien** **Serviceorientierte Kategorien** Beispiele: - E-Mail und Kalender - Dateiablage - Arbeitsplatz - Netzwerkzugang - Warenwirtschaft - Personalverwaltung - Zeiterfassung Vorteile: - für Benutzer verständlicher, - besserer Bezug zu Serviceauswirkungen, - Unterstützung von Serviceberichten. **Technische Kategorien** Beispiele: - DNS - DHCP - Firewall - Datenbank - Betriebssystem - Speicher - Zertifikat Vorteile: - hilfreich für technische Analyse, - Unterstützung spezialisierter Teams, - technische Trendanalyse. Beide Perspektiven können kombiniert werden. > **Praxistipp** > > Der Benutzer wählt möglichst den betroffenen Service oder sein Anliegen. > > Die technische Einordnung kann während der Bearbeitung ergänzt werden. --- **Benutzerkategorie und interne Kategorie unterscheiden** Ein Portal sollte nicht zwingend dieselben Kategorien anzeigen wie das interne Ticketsystem. Benutzerfreundliche Auswahl: - Ich kann mich nicht anmelden. - Ich benötige Zugriff. - Eine Anwendung funktioniert nicht. - Ich habe eine verdächtige E-Mail erhalten. - Ich möchte Software bestellen. Interne Zuordnung: - Service: Identity and Access - Vorgangsart: Incident - Symptom: MFA fehlgeschlagen - technische Domäne: Entra ID - Supportgruppe: Identity Operations Dadurch muss der Benutzer keine interne IT-Struktur kennen. --- **Mehrere Kategorisierungsdimensionen verwenden** Eine einzige hierarchische Kategorie kann schnell zu groß und unübersichtlich werden. Alternativ können mehrere getrennte Merkmale verwendet werden. | Dimension | Beispiel | |---|---| | **Service** | E-Mail | | **Vorgangsart** | Incident | | **Symptom** | Versand nicht möglich | | **technische Domäne** | Mail Gateway | | **Standort** | Berlin | | **Benutzergruppe** | Vertrieb | | **Sicherheitsbezug** | nein | | **Ursachencode** | Zertifikat abgelaufen | | **Lösungscode** | Zertifikat erneuert | Vorteile: - bessere Auswertung, - weniger tiefe Kategorien, - und flexiblere Zuordnung. Nachteile: - mehr Felder, - höherer Pflegeaufwand, - und mögliche uneinheitliche Eingaben. Deshalb sollten nur tatsächlich benötigte Dimensionen verwendet werden. --- **Symptom-, Ursachen- und Lösungskategorien unterscheiden** Diese Kategorien entstehen zu unterschiedlichen Zeitpunkten. | Kategorie | Zeitpunkt | Beispiel | |---|---|---| | **Symptomkategorie** | bei Erfassung | Anmeldung nicht möglich | | **technische Kategorie** | während Diagnose | Identitätsdienst | | **Ursachenkategorie** | nach Bestätigung | Zertifikat abgelaufen | | **Lösungskategorie** | nach Wiederherstellung | Zertifikat erneuert | Zu Beginn darf nicht so kategorisiert werden, als wäre die Ursache bereits bekannt. > **Typischer Fehler** > > Das Ticket wird bei der ersten Meldung als „Netzwerkfehler“ kategorisiert und bleibt dort, obwohl später ein abgelaufenes Anwendungstoken als Ursache bestätigt wird. --- **Kategorien dürfen geändert werden** Eine erste Kategorisierung ist häufig vorläufig. Während der Bearbeitung können neue Erkenntnisse entstehen. Eine Kategorie sollte geändert werden, wenn: - der betroffene Service falsch erkannt wurde, - die Vorgangsart falsch war, - eine technische Ursache bestätigt wurde, - oder eine genauere Einordnung möglich ist. Die Änderung sollte: - nachvollziehbar, - nach festgelegten Regeln, - und ohne Verlust der ursprünglichen Informationen erfolgen. --- **Kategorie „Sonstiges“ kontrolliert verwenden** Eine Kategorie wie: - Sonstiges, - Allgemein, - Unbekannt, - oder Andere kann notwendig sein. Sie darf jedoch nicht zur dauerhaften Standardkategorie werden. Eine hohe Nutzung kann anzeigen: - Kategorien sind unverständlich, - wichtige Services fehlen, - Mitarbeiterschulung ist unzureichend, - das Portal ist schlecht gestaltet, - oder neue Bedarfsmuster sind entstanden. > **Praxistipp** > > Vorgänge in „Sonstiges“ sollten regelmäßig ausgewertet und bei Bedarf neu kategorisiert werden. --- **Nicht zu viele Kategorieebenen verwenden** Ungeeignetes Beispiel: > IT → Infrastruktur → Netzwerk → Standortnetz → LAN → Switch → Cisco → Modell → Port → Fehler Eine solche Struktur kann: - langsam, - fehleranfällig, - schwer wartbar, - und für Benutzer ungeeignet sein. Eine einfachere Kombination kann ausreichen: - Service: Standortnetzwerk - Symptom: Verbindung unterbrochen - betroffenes CI: Switch SW-N-03 - technische Gruppe: Network Operations > **Grundsatz** > > Die Kategorie sollte die Arbeit unterstützen und nicht selbst zu einer zusätzlichen komplizierten Arbeit werden. --- **Kategorien nicht nach Teams aufbauen** Eine Kategorie wie: - First Level - Netzwerkteam - Serverteam - Anwendungsteam beschreibt organisatorische Zuständigkeit, aber nicht unbedingt den Service oder das Anliegen. Teams können sich verändern. Services und Benutzerbedürfnisse bleiben häufig stabiler. Besser ist: - Service und Anliegen kategorisieren, - zuständige Gruppe daraus ableiten, - und Zuweisungsregeln unabhängig pflegen. --- **Vorgangsart richtig bestimmen** Eine wichtige erste Einordnung ist die Unterscheidung zwischen verschiedenen Vorgangsarten. --- **Incident** Ein Incident liegt vor, wenn eine ungeplante negative Auswirkung auf einen Service behandelt werden muss. Beispiele: - Anwendung ist nicht erreichbar. - vorhandener Zugriff funktioniert nicht. - Druckservice liefert keine Aufträge. - Leistung ist erheblich vermindert. - vorhandene Funktion erzeugt Fehler. --- **Service Request** Ein Service Request ist eine vorgesehene Benutzeranfrage. Beispiele: - Standardsoftware anfordern - neuen Zugriff beantragen - Information zu einem Service erhalten - Arbeitsplatzgerät bestellen - Verteilerliste ändern lassen --- **Frage oder Informationskontakt** Beispiele: - Wann findet die Wartung statt? - Welche Software ist freigegeben? - Wie erreiche ich den Service außerhalb der Geschäftszeit? Eine Frage kann möglicherweise direkt beantwortet werden, ohne einen umfangreichen Request-Wertstrom zu starten. --- **Sicherheitsmeldung** Beispiele: - verdächtige E-Mail - verlorenes Gerät - möglicher unberechtigter Zugriff - versehentliche Datenoffenlegung - ungewöhnliches Anmeldeverhalten Eine Sicherheitsmeldung benötigt möglicherweise: - besondere Zugriffsrechte, - vertrauliche Bearbeitung, - und schnelle Weiterleitung an das Sicherheitsteam. --- **Beschwerde oder Feedback** Beispiele: - zugesagte Rückmeldung wurde nicht eingehalten - Portal ist nicht barrierefrei nutzbar - wiederkehrende Störung beeinträchtigt die Arbeit - Servicebeschreibung ist unverständlich Feedback kann mit einem Incident oder Request verbunden sein, besitzt aber möglicherweise einen eigenen Bearbeitungs- und Verbesserungsweg. --- **Fehleinordnungen korrigieren** Beispiel: Ein Benutzer wählt: > Service Request – Kennwort ändern Während der Erfassung wird erkannt: - Das Konto ist aufgrund eines Fehlers im Identitätsdienst gesperrt. - Mehrere Benutzer sind betroffen. - Die normale Selbstverwaltung funktioniert nicht. Der Vorgang sollte dann möglicherweise als Incident behandelt werden. Ein anderes Beispiel: Der Benutzer meldet: > VPN funktioniert nicht. Die Analyse zeigt: - VPN ist grundsätzlich funktionsfähig. - Der Benutzer besitzt noch keine genehmigte VPN-Berechtigung. Dies kann ein Service Request statt eines Incidents sein. > **Merke** > > Die Formulierung oder Portalwahl des Benutzers bestimmt nicht allein die endgültige Vorgangsart. --- **Duplikate erkennen** Bei größeren Störungen entstehen häufig mehrere Tickets zum selben Incident. Duplikaterkennung verhindert: - parallele Diagnose, - widersprüchliche Maßnahmen, - mehrfache Lieferantenmeldungen, - und unklare Statuskommunikation. Vor dem Erstellen eines neuen Incidents kann geprüft werden: - Ist bereits eine bekannte Störung veröffentlicht? - Existiert ein Incident für denselben Service? - Sind Zeitraum, Standort und Symptom identisch? - Besteht ein gemeinsamer technischer Auslöser? - Handelt es sich tatsächlich um denselben oder nur um einen ähnlichen Fehler? --- **Duplikate nicht einfach löschen** Ein Duplikat kann wichtige Informationen enthalten: - zusätzliche betroffene Benutzer, - weiteren Standort, - abweichendes Symptom, - neue Zeitangabe, - oder besondere Auswirkung. Eine sinnvolle Behandlung kann sein: 1. Kontaktinformationen erhalten 2. Ticket mit dem Haupt-Incident verknüpfen 3. betroffene Person oder Gruppe ergänzen 4. Benutzerkommunikation mit dem Haupt-Incident abstimmen 5. Duplikat nachvollziehbar schließen oder unterordnen --- **Parent-, Child- und Sammel-Incidents** Bei einem größeren Incident kann ein Hauptvorgang verwendet werden. **Haupt-Incident** Enthält: - technische Gesamtkoordination, - zentrale Auswirkung, - gemeinsame Statusinformationen, - und Wiederherstellungsstand. **Verknüpfte Meldungen** Enthalten: - einzelne betroffene Benutzer, - lokale Besonderheiten, - individuelle Rückfragen, - und Bestätigung der Wiederherstellung. Das konkrete Modell hängt vom Ticketsystem und der Organisation ab. --- **Verknüpfungen zwischen Vorgängen** Tickets können miteinander verbunden werden. Beispiele: - Incident wurde durch Change verursacht. - mehrere Incidents gehören zu einem Problem. - Service Request benötigt einen Change. - Incident besitzt einen Lieferantenfall. - Major Incident besitzt mehrere technische Aufgaben. - Sicherheitsmeldung führt zu einem Security Incident. - Knowledge-Artikel dokumentiert eine bekannte Lösung. - Verbesserungsidee entsteht aus einer Incident-Auswertung. Mögliche Beziehungstypen: - verursacht durch - betrifft - Duplikat von - gelöst durch - gehört zu - Folge von - blockiert durch - bekanntes Problem - zugehöriger Change - zugehöriger Knowledge-Artikel > **Wichtig** > > Verknüpfungen sollten eine erkennbare Bedeutung besitzen. > > Eine große Menge unklarer Beziehungen verbessert die Nachvollziehbarkeit nicht. --- **Status eines Tickets** Ein Status zeigt den aktuellen Bearbeitungszustand. Mögliche Status sind beispielsweise: - Neu - Erfasst - In Prüfung - In Bearbeitung - Warten auf Benutzer - Warten auf Lieferant - Warten auf Change - Gelöst - Abgeschlossen - Abgebrochen ITIL schreibt kein universelles Statusmodell vor. Die Organisation muss festlegen: - was jeder Status bedeutet, - wer ihn setzen darf, - welche Verantwortung weiterhin besteht, - ob Zielzeiten weiterlaufen, - und welche Kommunikation ausgelöst wird. --- **„Warten“ benötigt einen Grund und nächsten Schritt** Unzureichend: > Status: Warten Besser: > Warten auf Benutzer – benötigt wird ein Screenshot der genauen Fehlermeldung. Rückmeldung bis 5. August erbeten. Falls keine Antwort erfolgt, wird am 6. August ein weiterer Kontaktversuch durchgeführt. Oder: > Warten auf Lieferant – Providerfall P-8821 wurde um 10:40 Uhr eröffnet. Nächste vertragliche Rückmeldung wird bis 12:40 Uhr erwartet. Interner Ansprechpartner bleibt Network Operations. > **Typischer Fehler** > > Ein Ticket wird auf „Warten“ gesetzt, ohne dass erkennbar ist, worauf gewartet wird und wer den Vorgang wieder aufnimmt. --- **Gelöst und abgeschlossen unterscheiden** Eine Organisation kann zwischen: - technisch oder fachlich gelöst, - und formal abgeschlossen unterscheiden. **Gelöst** - Lösung oder Erfüllung wurde durchgeführt. - Ergebnis wird möglicherweise noch bestätigt oder beobachtet. **Abgeschlossen** - Abschlusskriterien wurden erfüllt. - Dokumentation ist vollständig. - offene Folgeaktivitäten sind zugeordnet. - Benutzer wurde informiert. - Vorgang benötigt keine weitere aktive Bearbeitung. Dieses Modell ist möglich, aber nicht verpflichtend. --- **Automatischer Abschluss** Ein Ticket kann nach einer festgelegten Frist automatisch geschlossen werden. Dabei sollte berücksichtigt werden: - Wurde der Benutzer verständlich informiert? - War die Frist angemessen? - Besteht ein einfacher Weg zur Wiederaufnahme? - Ist der Service technisch überprüft? - Handelt es sich um einen kritischen oder sensiblen Vorgang? - Bestehen offene Folgeaktivitäten? Automatischer Abschluss darf nicht nur dazu dienen, Kennzahlen zu verbessern. --- **Ownership und Zuweisung** Ein Ticket sollte jederzeit eine erkennbare Verantwortung besitzen. Mögliche Felder: - verantwortliche Gruppe, - verantwortliche Person, - Service Owner, - Incident-Koordinator, - und Kommunikationsverantwortlicher. Eine Gruppe allein reicht möglicherweise nicht aus, wenn: - niemand den Vorgang aktiv übernimmt, - keine nächste Aktion geplant ist, - oder mehrere Teams beteiligt sind. > **Merke** > > „Zugewiesen“ bedeutet nicht automatisch „wird bearbeitet“. --- **Weiterleitung benötigt vollständige Informationen** Vor einer Weiterleitung sollte geprüft werden: - Ist der betroffene Service bekannt? - Ist die Auswirkung beschrieben? - Ist die Priorität nachvollziehbar? - Wurden geeignete erste Prüfungen durchgeführt? - Sind Ergebnisse dokumentiert? - Ist die Zielgruppe richtig? - Ist klar, welche Unterstützung benötigt wird? - Bleibt die Benutzerkommunikation geregelt? Ungeeignete Weiterleitung: > Bitte prüfen. Besser: > Alle Benutzer am Standort Nord können seit 09:15 Uhr den zentralen Dateiservice nicht erreichen. DNS-Auflösung und lokale Netzwerkverbindung funktionieren. Der Zugriff auf TCP-Port 445 schlägt fehl. Standort Süd ist nicht betroffen. Benötigt wird die Prüfung des Standorttunnels und der Firewall. Nächste Benutzerstatusmeldung wurde für 10:30 Uhr angekündigt. --- **Ticket-Pingpong erkennen** Ticket-Pingpong entsteht, wenn ein Vorgang mehrfach zwischen Gruppen weitergeleitet wird. Mögliche Ursachen: - Kategorien sind unklar, - Verantwortung ist nicht definiert, - Informationen fehlen, - Teams lehnen Vorgänge ohne Abstimmung ab, - Serviceabhängigkeiten sind unbekannt, - oder die Organisation arbeitet zu stark in Silos. Geeignete Maßnahmen: - warme Übergabe, - gemeinsames Swarming, - klare Zuweisungsregeln, - bessere Serviceinformationen, - und Auswertung häufig weitergeleiteter Tickets. --- **Anhänge, Screenshots und Protokolle** Anhänge können die Diagnose unterstützen. Beispiele: - Screenshot einer Fehlermeldung - gekürzter Logauszug - Export technischer Diagnosedaten - Foto eines Hardwarefehlers - Konfigurationsauszug - Testprotokoll Vor der Speicherung sollte geprüft werden: - Wird der Anhang tatsächlich benötigt? - Enthält er personenbezogene Daten? - Sind Kennwörter, Tokens oder Schlüssel sichtbar? - Enthält er vertrauliche Geschäftsangaben? - Besitzen alle Ticketleser die notwendige Berechtigung? - Wie lange wird der Anhang gespeichert? - Kann eine kleinere oder anonymisierte Auswahl ausreichen? --- **Screenshots richtig verwenden** Ein Screenshot sollte möglichst zeigen: - relevante Fehlermeldung, - Anwendung oder Kontext, - Zeitpunkt, falls wichtig, - und notwendige technische Details. Er sollte möglichst nicht zeigen: - private Nachrichten, - vollständige Kundenlisten, - Kennwörter, - Zugriffstokens, - nicht benötigte personenbezogene Daten, - oder andere vertrauliche Fenster. > **Praxistipp** > > Fordere möglichst nur den benötigten Bildausschnitt an und erkläre, welche sensiblen Inhalte vorher geschlossen oder entfernt werden sollen. --- **Protokolldaten sicher behandeln** Logs können enthalten: - Benutzernamen, - IP-Adressen, - Dateipfade, - Session-IDs, - Tokens, - personenbezogene Informationen, - und interne Architekturdetails. Sie sollten: - nur zweckgebunden verwendet, - angemessen geschützt, - nicht unkontrolliert in offene Kommentare kopiert, - und nach den Vorgaben der Organisation aufbewahrt werden. --- **Kennwörter und Zugangsdaten gehören nicht ins Ticket** Nicht gespeichert werden sollten insbesondere: - Kennwörter, - private Schlüssel, - API-Secrets, - vollständige Zugriffstokens, - Wiederherstellungscodes, - und ungeschützte Zugangsdaten. Erhält der Service Desk solche Informationen, müssen die Sicherheitsverfahren der Organisation angewendet werden. Mögliche Maßnahmen: - Information aus dem sichtbaren Vorgang entfernen oder schützen, - betroffene Zugangsdaten widerrufen, - Benutzer informieren, - und Sicherheitsrolle einbinden. --- **Datenschutz und Datenminimierung** Ein Ticket darf nur Informationen enthalten, die für einen legitimen Zweck benötigt werden. Zu prüfen sind: - Welche personenbezogenen Daten sind notwendig? - Wer darf sie sehen? - Wie lange werden sie gespeichert? - Müssen Daten anonymisiert werden? - Sind besondere Kategorien personenbezogener Daten betroffen? - Ist das Ticket für den gewählten Empfängerkreis geeignet? Ungeeignet: > Vollständige Krankheitsdiagnose eines Mitarbeiters im allgemeinen IT-Ticket. Ausreichend kann je nach Situation sein: > Benutzer benötigt aufgrund einer genehmigten Arbeitsplatzanpassung eine alternative Eingabemöglichkeit. Die verbindlichen Regeln ergeben sich aus den Datenschutz- und Sicherheitsvorgaben der Organisation. --- **Besondere Behandlung von Sicherheitsmeldungen** Sicherheitsbezogene Tickets können besondere Anforderungen besitzen. Beispiele: - eingeschränkter Leserkreis, - separate Sicherheitswarteschlange, - unveränderte Beweissicherung, - besondere Aufbewahrung, - sofortige Eskalation, - und kontrollierte Kommunikation. Ein allgemeiner Service-Desk-Mitarbeiter sollte wissen: - welche Hinweise sicherheitsrelevant sind, - welche Informationen er erfassen darf, - was nicht verändert werden darf, - und an wen der Vorgang weitergegeben wird. --- **Ticket-Erfassung bei einem möglichen Major Incident** Bei einem möglichen Major Incident sind besonders wichtig: - genauer Beginn, - betroffene Services, - betroffene Standorte und Benutzergruppen, - Geschäfts- oder Kundenwirkung, - verfügbare Zwischenlösungen, - letzte Changes, - bisherige Maßnahmen, - beteiligte Teams, - Entscheidungs- und Kommunikationsverantwortung, - und nächster Statuszeitpunkt. Ein kurzer Erstbericht darf zunächst unvollständig sein, wenn schnelles Handeln notwendig ist. Die Informationen müssen anschließend kontrolliert ergänzt werden. > **Grundsatz** > > Schnelle Erfassung und ausreichende Qualität müssen ausbalanciert werden. > > Ein kritischer Incident darf nicht wegen eines umfangreichen Pflichtformulars unnötig verzögert werden. --- **Pflichtfelder** Pflichtfelder können Informationsqualität verbessern. Sie können jedoch auch: - Erfassung verzögern, - falsche Platzhalter erzeugen, - Benutzer überfordern, - oder Mitarbeiter zum Umgehen des Systems verleiten. Ein Feld sollte verpflichtend sein, wenn die Information: - regelmäßig benötigt wird, - zum Erfassungszeitpunkt bekannt sein kann, - und einen erkennbaren Nutzen besitzt. Ungeeignetes Pflichtfeld bei der Ersterfassung: > bestätigte technische Ursache Die Ursache ist zu diesem Zeitpunkt häufig noch unbekannt. Besser: > beobachtetes Symptom --- **Dynamische Formulare** Dynamische Formulare zeigen nur Felder an, die zur gewählten Situation passen. Beispiel: Auswahl: > Verdächtige E-Mail Zusätzliche Felder: - Zeitpunkt des Empfangs - wurde Link geöffnet? - wurde Anhang geöffnet? - betroffener Benutzer - sichere Uploadmöglichkeit Auswahl: > Software anfordern Zusätzliche Felder: - benötigte Anwendung - Gerät - geschäftlicher Zweck - benötigter Zeitpunkt - Genehmigung Dadurch können Formulare kürzer und verständlicher werden. --- **Vorlagen und Ticketmodelle** Für häufige Situationen können Vorlagen verwendet werden. Beispiele: - Benutzerkonto gesperrt - Softwareanforderung - Standortausfall - verlorenes Endgerät - verdächtige E-Mail - Druckerstörung - Datenwiederherstellung - Lieferanteneskalation Eine Vorlage kann enthalten: - notwendige Fragen, - Standardaufgaben, - Zuweisungsregeln, - Kommunikationsvorlagen, - und Abschlusskriterien. Vorlagen müssen regelmäßig geprüft werden. Eine veraltete Vorlage kann falsche Diagnose oder unnötige Schritte fördern. --- **Automatisierte Erfassung** Tickets können automatisch entstehen durch: - Monitoring, - E-Mail, - Portal, - Chatbot, - Endpoint Management, - Sicherheitsplattform, - Cloud-Provider, - oder Schnittstellen. Bei automatischer Erfassung sollte geklärt sein: - Ist die Meldung handlungsrelevant? - Existiert bereits ein Vorgang? - Welcher Service ist betroffen? - Welche Kategorie ist zuverlässig bestimmbar? - Welche Priorität darf automatisch gesetzt werden? - Wer überprüft die Information? - Wie werden Fehlalarme behandelt? - Wann werden Benutzer informiert? > **Merke** > > Automatisch erzeugt bedeutet nicht automatisch richtig kategorisiert oder priorisiert. --- **KI-gestützte Kategorisierung** KI kann Vorschläge erzeugen für: - Vorgangsart, - Kategorie, - betroffenen Service, - ähnliche Tickets, - zuständige Gruppe, - Priorität, - und passende Wissensartikel. Mögliche Vorteile: - schnellere Einordnung, - einheitlichere Kategorien, - weniger manuelle Arbeit, - und Erkennung ähnlicher Formulierungen. Mögliche Risiken: - falsche Zuordnung, - unerkannte Sicherheitsmeldungen, - Verzerrungen durch schlechte Trainingsdaten, - Übernahme veralteter Kategorien, - und fehlende Nachvollziehbarkeit. --- **KI-Ausgaben müssen überprüfbar bleiben** Zu klären ist: - Welche Daten verwendet die KI? - Welche Kategorien darf sie automatisch setzen? - Wann ist menschliche Bestätigung erforderlich? - Wie werden Fehlzuordnungen korrigiert? - Wie wird aus Korrekturen gelernt? - Welche sensiblen Daten werden verarbeitet? - Wer trägt Verantwortung? - Wie wird die Qualität gemessen? Bei kritischen oder sicherheitsrelevanten Vorgängen sollte eine ungeprüfte vollautomatische Einordnung vermieden werden. --- **Kategorien regelmäßig pflegen** Ein Kategoriemodell ist nicht dauerhaft unverändert geeignet. Änderungen entstehen durch: - neue Services, - neue Produkte, - organisatorische Veränderungen, - neue Technologien, - neue Lieferanten, - und Erfahrungen aus der Bearbeitung. Regelmäßig zu prüfen sind: - Welche Kategorien werden kaum verwendet? - Welche Kategorien werden zu häufig verwendet? - Wo entstehen viele Fehlzuordnungen? - Welche Kategorien führen regelmäßig zur falschen Gruppe? - Wo wird häufig „Sonstiges“ gewählt? - Welche neuen Muster sind entstanden? - Sind Begriffe für Benutzer verständlich? - Sind Berichte weiterhin sinnvoll? --- **Kategorisierung und Reporting** Kategorien ermöglichen Auswertungen wie: - häufig betroffene Services, - wiederkehrende Symptome, - hohe Incident-Mengen, - Service-Request-Nachfrage, - häufige Weiterleitungen, - Lieferantenabhängigkeiten, - und Verbesserungspotenzial. Die Aussagekraft hängt von der Datenqualität ab. Unzuverlässige Kategorien erzeugen unzuverlässige Berichte. > **Grundsatz** > > Schlechte Eingangsdaten werden durch ein modernes Dashboard nicht automatisch zu guten Entscheidungsinformationen. --- **Keine falschen Anreize durch Kategorien** Mitarbeiter können Kategorien so wählen, dass: - Zielzeiten günstiger erscheinen, - der Vorgang nicht zur eigenen Gruppe zählt, - oder Kennzahlen besser aussehen. Beispiele: - Incident wird als Service Request erfasst. - hoher Prioritätsfall wird heruntergestuft. - wiederkehrender Incident wird unter wechselnden Kategorien gespeichert. - Ticket wird als „Benutzerfehler“ abgeschlossen, ohne die Ursache zu untersuchen. Governance und Qualitätskontrollen müssen solche Fehlanreize berücksichtigen. --- **Ticketqualität messen** Mögliche Qualitätsmerkmale: - betroffener Service eindeutig, - Titel verständlich, - Symptom vollständig, - Auswirkung nachvollziehbar, - Zeitangaben vorhanden, - Kategorie geeignet, - Vorgangsart korrekt, - Maßnahmen und Ergebnisse dokumentiert, - Ownership sichtbar, - nächster Schritt bekannt, - Benutzerkommunikation nachvollziehbar, - Lösung vollständig, - Abschlusskriterien erfüllt, - und Datenschutz eingehalten. Eine reine Vollständigkeitsquote reicht nicht aus. Ein ausgefülltes Feld kann trotzdem: - falsch, - unverständlich, - veraltet, - oder nutzlos sein. --- **Qualitätsprüfung ohne unnötige Bürokratie** Mögliche Verfahren: - Stichproben, - Peer Review, - Coaching, - automatische Plausibilitätsprüfung, - Auswertung wiedereröffneter Tickets, - Analyse häufiger Rückfragen, - und Prüfung häufig weitergeleiteter Vorgänge. Die Qualitätsprüfung sollte vor allem: - Lernen, - einheitliche Arbeitsweise, - und Verbesserung unterstützen. Sie sollte nicht ausschließlich zur persönlichen Fehlerbewertung verwendet werden. --- **Praxisbeispiel: unvollständiges Incident-Ticket** **Ursprüngliches Ticket** > Titel: Outlook geht nicht > Kategorie: Sonstiges > Priorität: Hoch > Beschreibung: Bitte schnell lösen. **Fehlende Informationen** - betroffener Service - tatsächliches Symptom - betroffener Benutzer - Zeitpunkt - weitere Betroffene - Auswirkung - Fehlermeldung - bereits durchgeführte Maßnahmen - Begründung der Priorität **Verbesserte Erfassung** > **Titel:** E-Mail-Versand über Outlook am Standort Süd nicht möglich > **Service:** E-Mail und Kalender > **Vorgangsart:** Incident > **Symptom:** Nachrichten bleiben im Postausgang > **Beginn:** etwa 09:10 Uhr > **Betroffene:** aktuell sieben Benutzer am Standort Süd > **Auswirkung:** externe Nachrichten können nicht versendet werden; Empfang funktioniert > **Fehlermeldung:** „Verbindung zum Ausgangsserver nicht möglich“ > **Prüfung:** Webmail-Versand funktioniert; Outlook und Geräte wurden nicht verändert > **Zwischenlösung:** Versand über Webmail möglich > **Nächster Schritt:** lokale Outlook- und Netzwerkverbindung prüfen --- **Praxisbeispiel: Incident oder Service Request** Benutzermeldung: > Ich komme nicht auf das Projektlaufwerk. **Möglicher Incident** - Zugriff bestand zuvor. - Berechtigung ist weiterhin zugewiesen. - Laufwerk ist plötzlich nicht erreichbar. - weitere Benutzer sind betroffen. **Möglicher Service Request** - Zugriff bestand noch nie. - Benutzer benötigt eine neue Projektberechtigung. - Genehmigung durch Projektverantwortlichen ist erforderlich. **Mögliche Sicherheitssituation** - Benutzer sieht plötzlich Daten eines fremden Projekts. - unberechtigte Berechtigung muss sofort geprüft werden. Dieselbe Formulierung kann zu unterschiedlichen Vorgangsarten führen. --- **Praxisbeispiel: Duplikate bei einer Störung** Innerhalb von zehn Minuten melden 35 Benutzer: > Dateiablage nicht erreichbar. Geeignete Behandlung: 1. gemeinsamen Incident erkennen 2. betroffene Benutzer und Standorte ergänzen 3. Duplikate mit Haupt-Incident verknüpfen 4. technische Bearbeitung zentral koordinieren 5. allgemeine Statusmeldung veröffentlichen 6. individuelle Sonderauswirkungen gesondert dokumentieren 7. Wiederherstellung für betroffene Gruppen prüfen Ungeeignet: - 35 Teams bearbeiten 35 unabhängige Incidents, - oder alle Meldungen werden gelöscht und wichtige Auswirkungen gehen verloren. --- **Praxisbeispiel: falsche Kategorisierung** Ticket wurde erfasst als: > Netzwerk → WLAN → Verbindungsfehler Die Analyse zeigt: - Netzwerkverbindung funktioniert. - Nur eine Anwendung ist betroffen. - Ursache ist eine abgelaufene Anwendungslizenz. Korrektur: - Service: Fachanwendung - Vorgangsart: Incident - Symptom: Anmeldung nicht möglich - technische Ursache: Lizenz abgelaufen - Lösung: Lizenz erneuert Die ursprüngliche Benutzerbeschreibung und bisherige Diagnose bleiben erhalten. --- **Praxisbeispiel: sicherheitskritischer Anhang** Ein Benutzer hängt einen Screenshot an. Darauf sichtbar: - Fehlermeldung, - Benutzername, - vollständiger Zugriffstoken, - interne Serveradresse, - und Kundendaten. Geeignete Reaktion: - Zugriff auf den Anhang einschränken, - Sicherheitsverfahren anwenden, - Token widerrufen, - unnötige Daten entfernen oder geschützt behandeln, - Benutzer über sichere Übermittlung informieren, - und prüfen, ob eine Datenoffenlegung vorliegt. Das Ticket darf nicht unverändert an große Verteiler oder externe Lieferanten weitergeleitet werden. --- **Typische Fehler bei Ticket-Erfassung und Kategorisierung** **Fehler 1: Titel ohne Aussage** „Problem“, „Hilfe“ oder „Dringend“ ermöglichen keine schnelle Einordnung. --- **Fehler 2: vermutete Ursache als Tatsache** Die Diagnose wird früh auf eine möglicherweise falsche Richtung festgelegt. --- **Fehler 3: nur technische Komponente erfassen** Betroffener Service und Geschäftsbezug bleiben unbekannt. --- **Fehler 4: meldende und betroffene Person verwechseln** Kommunikation und Auswirkung werden falsch zugeordnet. --- **Fehler 5: Kategorie nach Supportteam auswählen** Organisatorische Änderungen machen das Modell unbrauchbar. --- **Fehler 6: zu viele Kategorieebenen** Erfassung wird langsam und fehleranfällig. --- **Fehler 7: „Sonstiges“ als Standard verwenden** Trends und Zuständigkeiten bleiben unsichtbar. --- **Fehler 8: Kategorie nach neuen Erkenntnissen nicht korrigieren** Berichte und Wissenszuordnung bleiben falsch. --- **Fehler 9: Maßnahmen ohne Ergebnis dokumentieren** Es ist nicht erkennbar, ob ein Test erfolgreich war. --- **Fehler 10: interne Abkürzungen ohne Erklärung** Andere Teams und spätere Bearbeiter verstehen die Notizen nicht. --- **Fehler 11: Ticketweiterleitung ohne Kontext** Nächste Gruppe muss die gesamte Situation erneut untersuchen. --- **Fehler 12: Status „Warten“ ohne nächsten Schritt** Der Vorgang bleibt unbegrenzt liegen. --- **Fehler 13: Ticket schließen, sobald eine technische Aktion durchgeführt wurde** Das Benutzer-Outcome wurde noch nicht bestätigt. --- **Fehler 14: Duplikate einfach löschen** Zusätzliche Auswirkungen und Kontaktinformationen gehen verloren. --- **Fehler 15: sensible Daten unkontrolliert speichern** Datenschutz- und Sicherheitsrisiken entstehen. --- **Fehler 16: alle Felder verpflichtend machen** Benutzer und Mitarbeiter tragen Platzhalter oder falsche Werte ein. --- **Fehler 17: KI-Kategorie ungeprüft übernehmen** Kritische oder sicherheitsbezogene Meldungen können falsch eingeordnet werden. --- **Fehler 18: Kategorien nie überarbeiten** Neue Services und veränderte Arbeitsweisen werden nicht berücksichtigt. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker erhalten häufig Tickets aus dem Service Desk oder erstellen selbst technische Vorgänge. Vor Beginn der Bearbeitung sollte geprüft werden: - Welcher Service ist betroffen? - Was ist das tatsächliche Symptom? - Welche Auswirkungen bestehen? - Welche Informationen sind bestätigt? - Welche Vermutungen wurden nur angenommen? - Was wurde bereits geprüft? - Welche Ergebnisse liegen vor? - Welche Systeme und Abhängigkeiten sind betroffen? - Wer besitzt den Vorgang? - Wann erwartet der Benutzer eine Rückmeldung? Während der Bearbeitung sollten dokumentiert werden: - technische Prüfungen, - konkrete Ergebnisse, - Änderungen, - Zeitpunkte, - Risiken, - Rückfallmaßnahmen, - und nächste Schritte. Nach der Bearbeitung sollten dokumentiert werden: - wiederhergestellte Funktion, - Benutzerbestätigung, - technische Ursache, falls bekannt, - dauerhafte oder vorläufige Lösung, - offene Folgeaktivitäten, - und mögliche Verbesserungen. --- **30-Sekunden-Prüfung eines Tickets** 1. **Person:** Wer meldet und wer ist betroffen? 2. **Service:** Welcher Service oder Arbeitsprozess ist betroffen? 3. **Symptom:** Was wurde tatsächlich beobachtet? 4. **Zeit:** Seit wann besteht die Situation? 5. **Auswirkung:** Was kann nicht durchgeführt werden? 6. **Umfang:** Wer oder was ist zusätzlich betroffen? 7. **Einordnung:** Incident, Request, Frage, Feedback oder Sicherheitsmeldung? 8. **Kategorie:** Unterstützt die Kategorie Bearbeitung und Auswertung? 9. **Maßnahmen:** Was wurde bereits durchgeführt? 10. **Ergebnisse:** Was haben die Maßnahmen gezeigt? 11. **Ownership:** Wer ist aktuell verantwortlich? 12. **Nächster Schritt:** Was geschieht als Nächstes? 13. **Kommunikation:** Wann erhält der Benutzer eine Rückmeldung? 14. **Sicherheit:** Enthält das Ticket nur zulässige Informationen? 15. **Abschluss:** Wie wird das tatsächliche Outcome bestätigt? --- **Checkliste für die Ersterfassung** - [ ] Ist die meldende Person bekannt? - [ ] Ist die tatsächlich betroffene Person oder Gruppe bekannt? - [ ] Ist der betroffene Service bestimmt? - [ ] Ist der Tickettitel eindeutig? - [ ] Ist das beobachtete Symptom beschrieben? - [ ] Ist der erwartete Normalzustand bekannt? - [ ] Ist der Beginn der Beeinträchtigung erfasst? - [ ] Sind Auswirkungen und Umfang dokumentiert? - [ ] Ist eine vorhandene Zwischenlösung bekannt? - [ ] Ist die Vorgangsart vorläufig bestimmt? - [ ] Ist die Kategorie verständlich und passend? - [ ] Wurden sensible Daten vermieden? - [ ] Ist der nächste Schritt festgelegt? - [ ] Wurde ein realistischer Informationszeitpunkt genannt? --- **Checkliste für technische Arbeitsnotizen** - [ ] Ist jede Maßnahme mit Zeitpunkt dokumentiert? - [ ] Ist der Zweck der Maßnahme erkennbar? - [ ] Ist das Ergebnis der Maßnahme beschrieben? - [ ] Sind Beobachtung und Vermutung getrennt? - [ ] Sind technische Werte ausreichend präzise? - [ ] Werden interne Abkürzungen erklärt? - [ ] Sind Änderungen und Rückfallmaßnahmen dokumentiert? - [ ] Wurden Zugangsdaten und sensible Inhalte entfernt? - [ ] Ist der nächste technische Schritt erkennbar? - [ ] Kann eine andere Person die Bearbeitung übernehmen? --- **Checkliste vor einer Weiterleitung** - [ ] Ist die Zielgruppe fachlich geeignet? - [ ] Ist der betroffene Service eindeutig? - [ ] Sind Auswirkung und Priorität nachvollziehbar? - [ ] Sind bisherige Maßnahmen dokumentiert? - [ ] Sind Ergebnisse und Fehlermeldungen enthalten? - [ ] Ist klar, welche Unterstützung benötigt wird? - [ ] Sind relevante Anhänge sicher beigefügt? - [ ] Ist die weitere Verantwortung geklärt? - [ ] Ist die Benutzerkommunikation geregelt? - [ ] Wurde unnötiges Ticket-Pingpong vermieden? --- **Checkliste für die Kategorisierung** - [ ] Ist die Vorgangsart korrekt? - [ ] Ist der betroffene Service erfasst? - [ ] Beschreibt die Kategorie das Anliegen statt nur das Team? - [ ] Ist die Symptomkategorie angemessen? - [ ] Wurde keine unbestätigte Ursache als Kategorie verwendet? - [ ] Kann die Kategorie bei neuen Erkenntnissen geändert werden? - [ ] Wird „Sonstiges“ nur begründet verwendet? - [ ] Sind Kategorien für die jeweilige Zielgruppe verständlich? - [ ] Unterstützt die Kategorie Berichte oder Bearbeitung? - [ ] Ist die Anzahl der Kategorieebenen angemessen? --- **Checkliste für Anhänge und sensible Informationen** - [ ] Wird der Anhang tatsächlich benötigt? - [ ] Sind Kennwörter, Tokens und Schlüssel entfernt? - [ ] Sind personenbezogene Daten auf das notwendige Maß reduziert? - [ ] Sind vertrauliche Inhalte geschützt? - [ ] Besitzen nur berechtigte Personen Zugriff? - [ ] Ist der Übertragungsweg geeignet? - [ ] Sind Logdaten ausreichend gekürzt oder anonymisiert? - [ ] Darf der Anhang an Lieferanten weitergegeben werden? - [ ] Sind Aufbewahrungs- und Löschregeln berücksichtigt? - [ ] Muss ein Sicherheitsvorfall eröffnet werden? --- **Checkliste vor dem Abschluss** - [ ] Ist das ursprüngliche Anliegen erneut geprüft worden? - [ ] Ist die technische Funktion wiederhergestellt oder der Request erfüllt? - [ ] Kann der Benutzer den benötigten Arbeitsschritt durchführen? - [ ] Ist die Lösung oder Erfüllung verständlich dokumentiert? - [ ] Sind Ursache und Lösung korrekt kategorisiert, soweit bekannt? - [ ] Sind offene Folgeaufgaben verknüpft? - [ ] Muss ein Problem Record erstellt werden? - [ ] Muss ein Knowledge-Artikel erstellt oder aktualisiert werden? - [ ] Muss eine Verbesserung erfasst werden? - [ ] Wurde der Benutzer über das Ergebnis informiert? - [ ] Sind vertrauliche Daten ordnungsgemäß behandelt? - [ ] Sind die Abschlusskriterien erfüllt? --- **Checkliste für das Kategoriemodell der Organisation** - [ ] Orientieren sich Benutzerkategorien an verständlichen Services und Anliegen? - [ ] Sind interne technische Kategorien getrennt pflegbar? - [ ] Besitzt jede Kategorie einen erkennbaren Nutzen? - [ ] Werden unnötig tiefe Hierarchien vermieden? - [ ] Sind Kategorien nicht ausschließlich an Teams gebunden? - [ ] Können Symptome, Ursachen und Lösungen getrennt erfasst werden? - [ ] Wird die Kategorie „Sonstiges“ regelmäßig ausgewertet? - [ ] Werden Fehlzuordnungen gemessen? - [ ] Werden neue Services und Anforderungen ergänzt? - [ ] Werden veraltete Kategorien entfernt? - [ ] Sind Zuweisungsregeln transparent? - [ ] Werden Benutzer und Bearbeiter bei Änderungen informiert? - [ ] Fließen Erkenntnisse in Continual Improvement ein? --- **Schnellreferenz** | Bereich | Zentrale Frage | |---|---| | **Titel** | Ist die Situation auf einen Blick verständlich? | | **Person** | Wer meldet und wer ist betroffen? | | **Service** | Welche Arbeitsfähigkeit oder Leistung ist beeinträchtigt? | | **Symptom** | Was wurde tatsächlich beobachtet? | | **Zeit** | Wann begann die Situation? | | **Auswirkung** | Was kann nicht durchgeführt werden? | | **Vorgangsart** | Incident, Request, Frage, Feedback oder Sicherheitsmeldung? | | **Kategorie** | Unterstützt sie Bearbeitung, Wissen und Auswertung? | | **Maßnahmen** | Was wurde bereits getan? | | **Ergebnisse** | Was wurde dadurch festgestellt? | | **Ownership** | Wer besitzt den nächsten Schritt? | | **Kommunikation** | Wann erhält der Benutzer die nächste Information? | | **Sicherheit** | Sind Daten und Anhänge angemessen geschützt? | | **Abschluss** | Wurde das tatsächliche Outcome bestätigt? | --- **Zusammenfassende Darstellung** > Benutzerkontakt oder technische Meldung > ↓ > meldende und betroffene Personen bestimmen > ↓ > betroffenen Service und tatsächliches Symptom erfassen > ↓ > Auswirkungen, Umfang und Zeitangaben dokumentieren > ↓ > Vorgangsart und vorläufige Kategorie bestimmen > ↓ > Ownership und nächsten Schritt festlegen > ↓ > Maßnahmen und Ergebnisse chronologisch dokumentieren > ↓ > Kategorie bei neuen Erkenntnissen korrigieren > ↓ > verknüpfte Incidents, Requests, Problems, Changes und Lieferantenfälle sichtbar machen > ↓ > Lösung oder Erfüllung dokumentieren > ↓ > Benutzer-Outcome bestätigen > ↓ > Wissen, Muster und Verbesserungsmöglichkeiten weiterverwenden --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.2 Kontaktkanäle und Erreichbarkeit - 3.3 Benutzerkommunikation und professioneller Umgang - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Incident Management - Service Request Management - Problem Management - Knowledge Management - Service Configuration Management - Information Security Management - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706) - [PeopleCert: ITIL 4 Practitioner – Incident Management](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-incident-management-3684) - [PeopleCert: ITIL 4 Practitioner – Service Request Management](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-request-management-3690) - [PeopleCert: ITIL 4 Specialist – Monitor, Support and Fulfil](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-monitor-support-and-fulfil-batch-1-3682) - [PeopleCert: ITIL 4 Management Practices 2023](https://www.peoplecert.org/news-and-announcements/2023/itil-4-management-practices-2023) - [PeopleCert ATV: Essential Features to Look for in ITSM Software](https://atv.peoplecert.org/essential-features-to-look-for-in-itsm-software/) - [PeopleCert ATV: ITSM Software for Incident Management](https://atv.peoplecert.org/itsm-software-for-incident-management/) - [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/ITIL-Service-Version-5) - [ITIL: ITIL Service Version 5 – An Enterprise-Wide Approach to Service Thinking](https://www.itil.com/Itil-News-and-Announcements/itil-service-version-5) - [ITIL: ITIL Foundation Version 5 – What’s New?](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-foundation-whats-new-guide) **Offiziell bestätigter Stand** Die offiziellen ITIL- und PeopleCert-Quellen bestätigen: - Service Desk, Incident Management und Service Request Management bleiben zentrale ITIL Management Practices. - Die Practices umfassen mehr als einzelne Prozesse und berücksichtigen Rollen, Informationen, Technologien, Wissen, Kommunikation und Wertströme. - Incident-Management-Werkzeuge unterstützen typischerweise die Erfassung, Kategorisierung, Priorisierung, Verlaufsdokumentation, Eskalation und Statusverfolgung. - Service-Desk-Prozesse und Informationen sollen in die Wertströme der Organisation integriert werden. - Datenqualität, Kommunikation, Nachvollziehbarkeit und geeignete Werkzeugunterstützung beeinflussen Serviceleistung und Benutzererfahrung. - ITIL Version 5 führt die Management Practices fort und richtet digitale Produkt- und Servicearbeit stärker an Wert, Outcomes, Erfahrung und Ende-zu-Ende-Zusammenarbeit aus. **Einordnung** Die auf dieser Seite dargestellten: - Ticketfelder, - Kategoriemodelle, - Statusbezeichnungen, - Titelregeln, - Checklisten, - Pflichtfeldempfehlungen, - Beispiele, - und Qualitätskriterien sind herstellerneutrale redaktionelle Praxisempfehlungen dieses unabhängigen Nachschlagewerks. ITIL schreibt kein universelles: - Ticketformular, - Feldschema, - Kategoriemodell, - Statusmodell, - Supportgruppenmodell, - Prioritätsmodell, - oder Ticketsystem für alle Organisationen vor. Die konkrete Gestaltung muss angepasst werden an: - Services, - Benutzergruppen, - Wertströme, - Risiken, - Sicherheits- und Datenschutzanforderungen, - Lieferanten, - Fähigkeiten, - und technische Werkzeuge. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 3.5 Auswirkungen, Dringlichkeit und Priorität > **Kurz erklärt** > > Die Priorität bestimmt, in welcher Reihenfolge und mit welcher Aufmerksamkeit ein Vorgang bearbeitet werden soll. > > Sie sollte nicht allein davon abhängen: > > - wer am lautesten fordert, > - wer hierarchisch am höchsten steht, > - wann das Ticket erstellt wurde, > - oder welche Priorität ein Benutzer selbst auswählt. > > Eine verbreitete betriebliche Vorgehensweise ist, die Priorität anhand von: > > - **Auswirkung** > - und **Dringlichkeit** > > zu bestimmen. > > **Auswirkung** beschreibt, wie stark Benutzer, Services, Geschäftsprozesse oder andere Stakeholder beeinträchtigt sind. > > **Dringlichkeit** beschreibt, wie schnell gehandelt werden muss, bevor sich die Folgen verschlimmern oder ein wichtiges Zeitfenster verloren geht. > > Die Organisation muss selbst festlegen: > > - welche Bewertungsstufen gelten, > - welche Kriterien verwendet werden, > - wie daraus eine Priorität entsteht, > - welche Zielzeiten damit verbunden sind, > - wer die Priorität ändern darf, > - und wann eine Neubewertung erfolgen muss. > > ITIL schreibt keine universelle Prioritätsmatrix vor, die unverändert für jede Organisation übernommen werden kann. --- **Warum eine nachvollziehbare Priorisierung notwendig ist** Eine Serviceorganisation besitzt normalerweise mehr offene Arbeit, als gleichzeitig bearbeitet werden kann. Beispiele: - mehrere Benutzer melden unterschiedliche Incidents, - Service Requests warten auf Erfüllung, - Lieferanten müssen eingebunden werden, - Changes benötigen technische Vorbereitung, - und bereits laufende Vorgänge benötigen weitere Maßnahmen. Ohne nachvollziehbare Priorisierung kann die Reihenfolge bestimmt werden durch: - persönliche Beziehungen, - häufige Nachfragen, - Hierarchie, - Zufall, - technische Vorlieben, - oder das Alter des Tickets. Dadurch können schwerwiegende Situationen übersehen werden, während weniger bedeutsame Vorgänge bevorzugt bearbeitet werden. Beispiel: **Vorgang A** Ein Vorstandsmitglied kann einen zweiten, selten verwendeten Bildschirm nicht nutzen. **Vorgang B** Ein einzelner Produktionsarbeitsplatz kann keine Sicherheitsfreigaben mehr durchführen. Dadurch steht in 20 Minuten eine gesamte Fertigungslinie still. Obwohl bei beiden Vorgängen zunächst nur eine Person betroffen ist, besitzt Vorgang B wahrscheinlich die deutlich größere Auswirkung und Dringlichkeit. > **Merke** > > Priorisierung bewertet nicht die persönliche Wichtigkeit eines Benutzers. > > Sie bewertet die Bedeutung und zeitliche Kritikalität des betroffenen Outcomes. --- **Auswirkung, Dringlichkeit und Priorität unterscheiden** | Begriff | Zentrale Frage | |---|---| | **Auswirkung** | Wie schwerwiegend sind die Folgen für Benutzer, Services oder Organisation? | | **Dringlichkeit** | Wie schnell muss gehandelt werden, bevor die Folgen unvertretbar werden? | | **Priorität** | In welcher Reihenfolge und mit welcher Aufmerksamkeit wird der Vorgang bearbeitet? | Beispiel: Ein Archivsystem ist ausgefallen. **Mögliche geringe Dringlichkeit** - Das System wird erst in drei Tagen benötigt. - Eine sichere alternative Zugriffsmöglichkeit besteht. - Es droht kein Datenverlust. **Mögliche hohe Auswirkung** - Das System enthält geschäftskritische und gesetzlich aufzubewahrende Unterlagen. - Viele Bereiche sind davon abhängig. Die Auswirkung kann damit hoch sein, während die unmittelbare Dringlichkeit zunächst geringer ist. Ein anderes Beispiel: Ein einzelner Benutzer kann eine Präsentation für einen in zehn Minuten beginnenden Kundentermin nicht öffnen. - Auswirkung auf die gesamte Organisation möglicherweise begrenzt - Dringlichkeit aufgrund des unmittelbar bevorstehenden Termins hoch > **Wichtig** > > Auswirkung und Dringlichkeit beschreiben unterschiedliche Perspektiven. > > Eine hohe Auswirkung bedeutet nicht automatisch höchste Dringlichkeit. --- **Priorität ist keine technische Fehlerklasse** Ein technisch kleiner Fehler kann eine hohe geschäftliche Priorität besitzen. Beispiel: Ein abgelaufenes Zertifikat ist möglicherweise schnell erneuerbar. Wenn dadurch jedoch: - die zentrale Anmeldung ausfällt, - sämtliche Benutzer betroffen sind, - und kein sicherer Workaround besteht, kann der Incident höchste Priorität erhalten. Umgekehrt kann ein technisch komplexes Problem eine geringere Priorität besitzen. Beispiel: Ein selten verwendeter Bericht erzeugt unter einer bestimmten Kombination von Filtern einen Darstellungsfehler. Die Analyse kann technisch aufwendig sein. Wenn jedoch: - keine wichtigen Daten verloren gehen, - nur wenige Benutzer betroffen sind, - und eine einfache Alternative besteht, kann eine niedrigere Priorität angemessen sein. > **Merke** > > Technische Schwierigkeit und betriebliche Priorität sind nicht dasselbe. --- **Mögliche Einflussfaktoren auf die Auswirkung** Die Organisation kann mehrere Kriterien berücksichtigen. **Anzahl betroffener Benutzer** Mögliche Abstufung: - einzelne Person - mehrere Personen - gesamtes Team - gesamter Standort - mehrere Standorte - sämtliche Benutzer - externe Kunden oder Partner Die Anzahl allein reicht jedoch nicht aus. Ein einzelner betroffener Benutzer kann eine kritische Aufgabe ausführen. **Kritikalität des betroffenen Service** Beispiele: - zentrale Anmeldung - Produktionssteuerung - Notfallkommunikation - Zahlungsverkehr - E-Mail - Dateiablage - internes Testsystem - freiwillige Zusatzanwendung Die Organisation sollte wichtige Services und deren Abhängigkeiten kennen. **Bedeutung des betroffenen Geschäftsprozesses** Mögliche Auswirkungen: - Produktion steht still. - Rechnungen können nicht erstellt werden. - Kunden können nicht bestellen. - Personal kann keine Gehaltsabrechnung durchführen. - gesetzliche Meldung kann nicht fristgerecht übermittelt werden. - Außendienst kann keine Aufträge erfassen. - interne Schulungsplattform ist vorübergehend nicht erreichbar. **Art der Beeinträchtigung** | Beeinträchtigung | Beispiel | |---|---| | **vollständiger Ausfall** | Service ist nicht nutzbar | | **teilweiser Ausfall** | bestimmte Funktionen fehlen | | **Leistungsminderung** | Service reagiert stark verzögert | | **Qualitätsminderung** | Ergebnisse sind unvollständig oder fehlerhaft | | **Sicherheitsbeeinträchtigung** | Schutzbedarf könnte verletzt sein | | **Datenbeeinträchtigung** | Daten sind verloren, beschädigt oder inkonsistent | | **Erfahrungsbeeinträchtigung** | Service ist technisch verfügbar, aber praktisch kaum nutzbar | **Verfügbarkeit einer Zwischenlösung** Eine geeignete Zwischenlösung kann die Auswirkung oder Dringlichkeit reduzieren. Beispiele: - alternativer Arbeitsplatz - Webversion statt Desktop-Anwendung - zweiter Drucker - manuelle Ersatzbearbeitung - Ausweichstandort - vorübergehender Read-only-Zugriff - alternative Kommunikationsplattform Die Zwischenlösung muss jedoch: - sicher, - zulässig, - ausreichend leistungsfähig, - verständlich, - und für die betroffenen Benutzer tatsächlich nutzbar sein. Ungeeignet wäre beispielsweise: > Benutzer können ihre Dokumente an private E-Mail-Adressen senden. Auch wenn dadurch kurzfristig weitergearbeitet werden könnte, wäre dies möglicherweise aus Sicherheits- und Datenschutzgründen unzulässig. **Dauer und Reichweite** Die tatsächliche Auswirkung kann mit der Zeit wachsen. Beispiel: Ein Bestellsystem fällt am frühen Morgen aus. Zu Beginn bestehen nur wenige offene Bestellungen. Nach mehreren Stunden können entstehen: - wachsender Rückstand, - verpasste Liefertermine, - Kundenbeschwerden, - und finanzielle Schäden. Die Priorität muss deshalb möglicherweise während der Bearbeitung erhöht werden. **Finanzielle Auswirkungen** Mögliche Kriterien: - Umsatzverlust - Produktionsstillstand - Vertragsstrafe - zusätzliche Personalkosten - kostenpflichtige Notfallunterstützung - verlorene Arbeitszeit - drohender Kundenverlust Nicht jede Organisation kann exakte Beträge während der Ersterfassung bestimmen. Eine qualitative Bewertung kann zunächst ausreichen. **Sicherheits- und Datenschutzfolgen** Mögliche Auswirkungen: - unberechtigter Zugriff - Offenlegung vertraulicher Daten - Verlust der Verfügbarkeit - Veränderung von Daten - Schadsoftware - kompromittiertes Konto - verlorenes Gerät - unsichere technische Konfiguration Ein möglicher Sicherheitsvorfall benötigt möglicherweise: - eine eigene Klassifizierung, - einen besonders geschützten Bearbeitungsweg, - und eine sofortige Eskalation. Er darf nicht ausschließlich anhand der Zahl aktuell betroffener Benutzer bewertet werden. **Gesetzliche und regulatorische Auswirkungen** Mögliche Beispiele: - Meldefrist wird gefährdet. - gesetzlich vorgeschriebene Aufzeichnung ist nicht möglich. - Aufbewahrungspflichten könnten verletzt werden. - personenbezogene Daten wurden möglicherweise offengelegt. Die Organisation muss ihre verbindlichen Anforderungen kennen und in die Bewertung einbeziehen. **Auswirkungen auf Kunden, Öffentlichkeit und Reputation** Mögliche Folgen: - Kunden können Leistungen nicht nutzen. - öffentliche Statusseiten zeigen einen Ausfall. - Medien oder soziale Netzwerke berichten über die Störung. - vertraglich zugesagte Leistungen werden nicht erbracht. - Vertrauen in die Organisation sinkt. Reputationsauswirkung sollte nicht nur nach subjektivem Eindruck bewertet werden. Geeignete Eskalations- und Kommunikationsrollen müssen beteiligt werden. **Auswirkungen auf Gesundheit und Sicherheit** In bestimmten Umgebungen können IT-Störungen Auswirkungen besitzen auf: - körperliche Sicherheit, - medizinische Versorgung, - Gebäudezugänge, - Notfallkommunikation, - Maschinensteuerung, - oder sicherheitskritische Überwachung. Solche Situationen benötigen möglicherweise: - besonders schnelle Eskalation, - Notfallverfahren, - Business-Continuity-Maßnahmen, - und autorisierte Entscheidungen außerhalb des normalen Supportablaufs. --- **Mögliche Einflussfaktoren auf die Dringlichkeit** Dringlichkeit beschreibt die verfügbare Zeit bis zu einer wesentlichen Verschlechterung oder bis zum Verlust eines wichtigen Outcomes. **Unmittelbarer Zeitdruck** Beispiele: - Produktion steht bereits still. - Kunden können aktuell nicht bestellen. - ein gesetzlicher Meldetermin endet heute. - ein wichtiger Geschäftstermin beginnt in wenigen Minuten. - Sicherheitslücke wird aktiv ausgenutzt. - Datenverlust setzt sich fort. **Zeit bis zur erwarteten Verschlechterung** Beispiel: Ein Speicherbereich ist zu 95 Prozent belegt. Der Service funktioniert noch. Monitoring zeigt jedoch, dass der Speicher voraussichtlich innerhalb einer Stunde vollständig belegt sein wird. Obwohl noch kein vollständiger Ausfall besteht, kann hohe Dringlichkeit vorliegen. **Verbleibendes Zeitfenster** Beispiele: - Wartungsfenster endet in 30 Minuten. - Lieferantensupport ist nur noch eine Stunde erreichbar. - Abrechnungslauf beginnt am Abend. - Zertifikat läuft in zwei Tagen ab. - Produktionsumstellung beginnt am nächsten Morgen. - Backup-Zeitfenster endet vor Schichtbeginn. **Verfügbarkeit einer Zwischenlösung** Eine sichere und praktikable Zwischenlösung kann die Dringlichkeit reduzieren. Beispiel: Die Desktop-Anwendung ist ausgefallen. Die Webversion ermöglicht alle wichtigen Tätigkeiten. Die Bearbeitung kann dadurch möglicherweise kontrollierter erfolgen. Die Zwischenlösung muss allerdings hinsichtlich folgender Punkte bewertet werden: - Leistungsfähigkeit - Benutzerzahl - Sicherheit - Dauer - Datenkonsistenz - zusätzlicher Aufwand - mögliche Folgefehler **Drohender Datenverlust** Dringlichkeit kann besonders hoch sein, wenn: - Daten weiterhin überschrieben werden, - Speicherfehler weitere Dateien beschädigen, - gelöschte Daten nur begrenzte Zeit wiederherstellbar sind, - oder Logs und Beweise verloren gehen könnten. In solchen Situationen kann die erste Maßnahme darin bestehen: - weitere Veränderungen zu verhindern, - Systeme zu isolieren, - Beweise zu sichern, - oder Schreibzugriffe zu stoppen. Eine vorschnelle normale Fehlerbehebung kann Wiederherstellungsmöglichkeiten verschlechtern. **Sicherheitsbedrohung** Hohe Dringlichkeit kann vorliegen bei: - aktivem Angriff, - kompromittiertem Administratorkonto, - laufender Datenübertragung an Unberechtigte, - Schadsoftwareausbreitung, - oder bekanntem ungeschütztem kritischem Zugang. Die Bearbeitung richtet sich dann nicht nur nach Incident Management, sondern auch nach dem Sicherheitsverfahren der Organisation. **Kommender geschäftskritischer Zeitpunkt** Beispiel: Die Gehaltsabrechnung funktioniert am Montag nicht. Der endgültige Abrechnungslauf beginnt erst am Mittwoch. Die Auswirkung ist bereits erheblich. Die verfügbare Zeit bis Mittwoch beeinflusst jedoch die Dringlichkeit und den möglichen Eskalationsweg. --- **Eine mögliche Auswirkungsskala** Die folgende Skala ist ein redaktionelles Beispiel. Sie ist keine verbindliche ITIL-Vorgabe. | Stufe | Beispielhafte Bedeutung | |---|---| | **Hoch** | kritischer Service, großer Benutzerkreis, erheblicher Geschäfts-, Sicherheits- oder Kundenbezug | | **Mittel** | mehrere Benutzer oder wichtiger Teil eines Service betroffen, begrenzte Zwischenlösung vorhanden | | **Niedrig** | einzelne oder wenige Benutzer, begrenzte Folgen, geeignete Alternative vorhanden | Eine Organisation kann stattdessen verwenden: - vier Stufen, - fünf Stufen, - numerische Werte, - serviceabhängige Kriterien, - oder ein anderes nachvollziehbares Modell. --- **Beispielkriterien für hohe Auswirkung** Eine hohe Auswirkung kann beispielsweise vorliegen, wenn mindestens eines der folgenden Kriterien erfüllt ist: - kritischer Service vollständig ausgefallen - mehrere Standorte betroffen - wichtiger Geschäftsprozess gestoppt - erheblicher Kundenbezug - mögliches erhebliches Sicherheits- oder Datenschutzereignis - erheblicher Datenverlust - Gesundheits- oder Sicherheitsrisiko - keine geeignete Zwischenlösung - erhebliche finanzielle oder vertragliche Folgen Die Organisation muss festlegen, ob: - ein einzelnes Kriterium ausreicht, - mehrere Kriterien gemeinsam erfüllt sein müssen, - oder eine autorisierte Rolle die Gesamtbewertung vornimmt. --- **Eine mögliche Dringlichkeitsskala** Auch diese Skala ist ein redaktionelles Beispiel. | Stufe | Beispielhafte Bedeutung | |---|---| | **Hoch** | sofortiges Handeln erforderlich; Folgen treten bereits ein oder verschlimmern sich sehr schnell | | **Mittel** | zeitnahe Bearbeitung erforderlich; begrenztes Zeitfenster oder zunehmende Folgen | | **Niedrig** | Bearbeitung planbar; Auswirkungen verschlechtern sich voraussichtlich nicht kurzfristig | --- **Beispielkriterien für hohe Dringlichkeit** - Service steht bereits vollständig still. - Schaden nimmt fortlaufend zu. - Sicherheitsbedrohung ist aktiv. - Datenverlust setzt sich fort. - kritische Frist läuft kurzfristig ab. - keine geeignete Zwischenlösung besteht. - Wiederherstellungszeitfenster wird bald überschritten. - weitere Services könnten kurzfristig ausfallen. --- **Eine mögliche Prioritätsmatrix** Die folgende Matrix ist eine Praxisvorlage und keine verbindliche ITIL-Matrix. | Auswirkung | Dringlichkeit hoch | Dringlichkeit mittel | Dringlichkeit niedrig | |---|---:|---:|---:| | **hoch** | P1 | P2 | P3 | | **mittel** | P2 | P3 | P4 | | **niedrig** | P3 | P4 | P4 | Eine Organisation kann auch andere Ergebnisse festlegen. Beispielsweise könnte: - hohe Auswirkung und niedrige Dringlichkeit als P2 behandelt werden, - jeder mögliche Sicherheitsvorfall automatisch einen besonderen Eskalationsweg erhalten, - oder ein kritischer Service eigene Prioritätsregeln besitzen. > **Wichtig** > > Eine Matrix unterstützt Entscheidungen. > > Sie ersetzt nicht die fachliche Bewertung besonderer Situationen. --- **Mögliche Prioritätsstufen** | Priorität | Praxisnahe Bedeutung | |---|---| | **P1 – kritisch** | sofortige koordinierte Bearbeitung; sehr hohe Auswirkung und Dringlichkeit | | **P2 – hoch** | schnelle priorisierte Bearbeitung; erhebliche Beeinträchtigung | | **P3 – mittel** | normale priorisierte Bearbeitung innerhalb vereinbarter Ziele | | **P4 – niedrig** | planbare Bearbeitung bei begrenzter Auswirkung und Dringlichkeit | Manche Organisationen verwenden: - P0 bis P4, - Priorität 1 bis 5, - Kritisch, Hoch, Mittel, Niedrig, - Severity-Level, - oder serviceabhängige Modelle. Die Bedeutung muss eindeutig dokumentiert sein. --- **Priorität und Severity unterscheiden** Der Begriff **Severity** wird in Organisationen unterschiedlich verwendet. Mögliche Bedeutungen: - technische Schwere eines Fehlers, - Ausmaß der Servicebeeinträchtigung, - Softwarefehlerklasse, - oder Einstufung eines Sicherheitsereignisses. Priorität beschreibt dagegen die Bearbeitungsreihenfolge und Aufmerksamkeit. Beispiel: Ein Softwarefehler kann hohe Severity besitzen, weil er bei bestimmten Bedingungen Daten beschädigt. Wenn diese Funktion derzeit deaktiviert ist und kein unmittelbarer Schaden droht, kann die operative Bearbeitungspriorität zunächst anders eingeordnet werden. > **Praxistipp** > > Die Organisation sollte in einem Glossar eindeutig festlegen, wie Severity und Priorität verwendet werden. --- **Priorität und Servicekritikalität unterscheiden** Servicekritikalität ist eine grundsätzlichere Eigenschaft eines Service. Beispiele: - geschäftskritisch - wichtig - unterstützend - nicht produktiv Die Priorität bewertet dagegen einen konkreten Vorgang. Ein Incident an einem kritischen Service besitzt nicht automatisch immer P1. Beispiel: In einer geschäftskritischen Anwendung ist nur eine selten verwendete Berichtsfunktion betroffen. Der Kernservice funktioniert. Eine geeignete Zwischenlösung besteht. Der konkrete Incident kann deshalb eine niedrigere Priorität erhalten. Umgekehrt kann ein normalerweise weniger kritischer Service zu einem bestimmten Zeitpunkt besonders wichtig sein. Beispiel: Eine Schulungsplattform wird während einer verbindlichen Abschlussprüfung benötigt. --- **Priorität und Major Incident unterscheiden** Ein Major Incident ist ein Incident mit besonders erheblicher Bedeutung, der eine besondere Koordination und Kommunikation erfordern kann. Eine Organisation legt eigene Kriterien fest. Ein P1-Incident kann ein Major Incident sein. Dies muss jedoch nicht in jeder Organisation automatisch identisch sein. | Priorität | Major Incident | |---|---| | bestimmt Bearbeitungsreihenfolge und Zielzeiten | aktiviert besondere Koordination und Kommunikation | | kann für unterschiedliche Vorgangsarten gelten | bezieht sich auf besonders schwerwiegende Incidents | | wird häufig aus Auswirkung und Dringlichkeit bestimmt | kann zusätzliche definierte Kriterien besitzen | | kann durch normale Supportstruktur bearbeitet werden | benötigt möglicherweise Incident-Koordination, Krisenkommunikation und Managementbeteiligung | Major-Incident-Kriterien werden auf Seite **3.7 Ownership, hierarchische Eskalation und Major Incidents** vertieft. --- **Priorität und Eskalation unterscheiden** Hohe Priorität kann eine Eskalation auslösen. Eine Eskalation kann jedoch auch notwendig sein, wenn die Priorität nicht besonders hoch ist. Beispiele: - Zielzeit ist gefährdet. - zuständige Fachkenntnis fehlt. - Lieferant reagiert nicht. - Entscheidung liegt außerhalb vorhandener Befugnisse. - mehrere Teams sind uneinig. - Benutzerbeschwerde benötigt Managementbeteiligung. - regulatorische Frage muss geklärt werden. Die Priorität beschreibt nicht vollständig, welcher Eskalationstyp benötigt wird. --- **Priorität und Zielzeiten unterscheiden** Prioritätsstufen können mit unterschiedlichen Zielen verbunden sein. Mögliche Ziele: - Zeit bis zur Annahme - Zeit bis zur qualifizierten Reaktion - Zeit bis zum Beginn der Bearbeitung - Zeit bis zur Wiederherstellung - Zeit bis zur Erfüllung - Statusintervall - Eskalationszeitpunkt Beispielhafte interne Ziele: | Priorität | Qualifizierte Reaktion | Statusintervall | |---|---:|---:| | **P1** | unverzüglich | alle 30 Minuten | | **P2** | innerhalb einer Stunde | alle 2 Stunden | | **P3** | innerhalb eines Arbeitstags | nach wesentlichen Änderungen | | **P4** | nach Planung | nach Vereinbarung | Diese Werte sind nur Beispiele. Die tatsächlichen Ziele müssen zu: - Servicezeiten, - Verträgen, - Servicekritikalität, - Fähigkeiten, - Bereitschaft, - und verfügbaren Ressourcen passen. --- **Reaktionsziel ist kein Lösungsversprechen** Eine Zielzeit für die erste Reaktion bedeutet nicht automatisch, dass der Incident innerhalb dieses Zeitraums gelöst sein muss. Beispiel: > Qualifizierte Reaktion innerhalb von 30 Minuten kann bedeuten: - Situation wurde bewertet, - Ownership wurde übernommen, - erste Diagnose hat begonnen, - und Benutzer erhielt eine verwertbare Rückmeldung. Eine Wiederherstellungszeit hängt unter anderem ab von: - Ursache, - technischer Komplexität, - Abhängigkeiten, - Lieferanten, - und verfügbaren Wiederherstellungsoptionen. > **Merke** > > Serviceziele müssen verständlich benannt werden. > > „Antwort innerhalb einer Stunde“ darf nicht als „Lösung innerhalb einer Stunde“ missverstanden werden. --- **Statusintervalle nach Priorität** Bei hoher Priorität benötigen Stakeholder häufigere Informationen. Ein Statusintervall sollte festlegen: - wie oft informiert wird, - wer informiert, - welche Zielgruppen informiert werden, - und welcher Kanal verwendet wird. Auch wenn keine neue Lösung vorliegt, kann eine Statusmeldung enthalten: - was aktuell geprüft wird, - welche Maßnahmen bereits erfolgten, - welche Abhängigkeit besteht, - welche Zwischenlösung gilt, - und wann die nächste Information folgt. --- **Priorität bei der Ersterfassung** Bei der ersten Meldung liegen häufig noch nicht alle Informationen vor. Eine vorläufige Priorität kann anhand der verfügbaren Angaben gesetzt werden. Danach sollte sie überprüft werden, sobald bekannt ist: - wie viele Benutzer betroffen sind, - welcher Service tatsächlich beeinträchtigt ist, - ob eine Zwischenlösung besteht, - ob weitere Standorte betroffen sind, - und ob Sicherheits- oder Datenrisiken bestehen. > **Wichtig** > > Eine erste Priorität ist keine unveränderliche Entscheidung. --- **Priorität dynamisch neu bewerten** Eine Neubewertung ist sinnvoll, wenn: - weitere Benutzer betroffen sind, - die Störung sich ausbreitet, - eine Zwischenlösung ausfällt, - ein kritischer Termin näher rückt, - Datenverlust erkannt wird, - ein Sicherheitsbezug entsteht, - der Service vollständig ausfällt, - oder die Wiederherstellung länger dauert als erwartet. Die Priorität kann auch gesenkt werden, wenn: - ein wirksamer Workaround eingeführt wurde, - nur eine weniger wichtige Funktion betroffen ist, - oder sich die ursprüngliche Auswirkung als geringer herausstellt. Jede wesentliche Änderung sollte dokumentiert werden. --- **Prioritätsänderungen dokumentieren** Eine nachvollziehbare Dokumentation kann enthalten: - alte Priorität - neue Priorität - Zeitpunkt - Grund - entscheidende Rolle - geänderte Auswirkung oder Dringlichkeit - ausgelöste Eskalation - Kommunikationsmaßnahme Beispiel: > 10:25 Uhr – Priorität von P3 auf P1 erhöht. Ursprünglich war ein einzelner Arbeitsplatz betroffen. Inzwischen können sämtliche Benutzer des Standorts keine Produktionsfreigabe durchführen. Fertigung steht seit 10:20 Uhr. Incident-Koordination und Standortleitung wurden informiert. --- **Wer darf die Priorität ändern?** Die Organisation sollte festlegen: - wer initial priorisiert, - wer eine Priorität erhöhen darf, - wer sie reduzieren darf, - wann Management oder Service Owner beteiligt werden, - und wie Konflikte entschieden werden. Mögliche Rollen: - Service Desk - Incident Manager - Service Owner - technische Supportgruppe - Informationssicherheit - autorisierte Führungskraft Eine Priorität darf nicht allein deshalb geändert werden, weil eine Person eine schnellere Bearbeitung verlangt. --- **Benutzerwunsch und organisatorische Priorität** Benutzer sollen die Auswirkungen und zeitlichen Anforderungen beschreiben können. Sie müssen jedoch nicht zwingend die endgültige Priorität auswählen. Eine geeignete Kommunikation kann lauten: > Sie haben angegeben, dass die Angelegenheit sehr dringend ist. Ich prüfe jetzt zusätzlich, wie viele Benutzer und welcher Geschäftsprozess betroffen sind. Daraus wird die Priorität nach unseren Kriterien bestimmt. Bei abweichender Bewertung: > Ich verstehe, dass Sie die Anwendung heute benötigen. Da aktuell nur eine Person betroffen ist, eine sichere Alternative besteht und keine Frist innerhalb der nächsten Stunden gefährdet ist, wird der Vorgang als P3 bearbeitet. Sollte die Alternative ausfallen oder der Monatsabschluss gefährdet sein, bewerten wir die Priorität erneut. --- **Hierarchie ist kein automatisches Prioritätskriterium** Ein Vorgang einer Führungskraft kann hohe Auswirkung besitzen. Beispiel: Die Person muss eine zeitkritische strategische Entscheidung freigeben. Die hierarchische Position allein genügt jedoch nicht als Begründung. Ungeeignet: > Tickets der Geschäftsführung sind immer P1. Besser: - geschäftliche Auswirkungen erfassen, - Dringlichkeit bestimmen, - organisatorische Kriterien anwenden, - und gegebenenfalls besondere Kommunikationsanforderungen berücksichtigen. > **Grundsatz** > > Eine besondere Kommunikationsbehandlung ist nicht automatisch eine höhere technische Bearbeitungspriorität. --- **VIP-Regelungen kritisch gestalten** Organisationen verwenden teilweise VIP-Kennzeichnungen. Diese können unterstützen bei: - besonderen Kommunikationswegen, - Assistenzkontakten, - erweiterten Servicezeiten, - oder organisatorisch vereinbarten Leistungen. Sie sollten nicht dazu führen, dass: - kritische Incidents anderer Benutzer verdrängt werden, - Sicherheitsprüfungen entfallen, - oder Prioritätskriterien bedeutungslos werden. --- **Zwischenlösungen richtig bewerten** Ein Workaround reduziert möglicherweise die Dringlichkeit. Er löst jedoch nicht automatisch den Incident dauerhaft. Beispiel: Die Desktop-Anwendung ist ausgefallen. Benutzer können vorübergehend die Webversion verwenden. Zu prüfen ist: - Sind alle benötigten Funktionen vorhanden? - Können sämtliche betroffenen Benutzer sie nutzen? - Ist die Lösung sicher? - Entsteht zusätzlicher Aufwand? - Wie lange ist der Workaround tragfähig? - Werden Daten konsistent verarbeitet? Ein Workaround kann damit: - Priorität senken, - Zeit für Ursachenanalyse schaffen, - oder Auswirkungen begrenzen. Er darf aber nicht unkritisch als vollständige Lösung behandelt werden. --- **Priorisierung bei mehreren gleichzeitig kritischen Incidents** Mehrere P1-Incidents können gleichzeitig auftreten. Dann reicht die Prioritätsnummer allein möglicherweise nicht aus. Zusätzlich zu bewerten sind: - Gesundheits- und Sicherheitsrisiken - aktive Sicherheitsbedrohung - Datenverlust - Anzahl und Bedeutung betroffener Services - verfügbare Wiederherstellungsmöglichkeiten - Abhängigkeiten - benötigte Spezialisten - mögliche Kettenreaktionen Governance oder Incident-Koordination muss möglicherweise Ressourcen zwischen den Vorgängen verteilen. --- **Abhängige Services berücksichtigen** Ein Incident kann zunächst nur eine technische Komponente betreffen. Diese kann jedoch mehrere Services unterstützen. Beispiel: Ein zentraler Identitätsdienst zeigt erste Fehler. Aktuell ist nur eine interne Anwendung betroffen. Möglicherweise werden kurz darauf ebenfalls beeinträchtigt: - E-Mail, - VPN, - Cloud-Anwendungen, - Administrationszugänge, - und Self-Service-Portal. Die Priorität sollte potenzielle und bekannte Abhängigkeiten berücksichtigen, ohne unbelegte Worst-Case-Annahmen als Tatsache zu behandeln. --- **Verknüpfte Incidents gemeinsam betrachten** Mehrere scheinbar unabhängige Meldungen können einen gemeinsamen Auslöser besitzen. Beispiele: - Anmeldung funktioniert nicht. - VPN-Verbindung schlägt fehl. - Cloud-Anwendung öffnet nicht. - Kennwort-Self-Service ist nicht erreichbar. Wenn alle Services vom gleichen Identitätsdienst abhängen, kann ein gemeinsamer Incident mit höherer Auswirkung vorliegen. --- **Service Requests priorisieren** Nicht nur Incidents benötigen eine Bearbeitungsreihenfolge. Auch Service Requests können unterschiedliche Dringlichkeit und Bedeutung besitzen. Beispiele: - Standardsoftware für einen zukünftigen Arbeitsplatz - Zugriff für neuen Mitarbeiter - Bestellung eines Ersatzgeräts - Berechtigung für einen zeitkritischen Projekteinsatz - Information zu einem Service Service Requests sollten trotzdem nicht wie Incidents behandelt werden. Bei Requests können zusätzlich relevant sein: - gewünschter Bereitstellungstermin - Genehmigungsstatus - Standardbereitstellungszeit - Verfügbarkeit von Lizenzen oder Assets - vertragliche oder organisatorische Verpflichtung Eine verspätet eingereichte Anfrage wird nicht automatisch zum Incident. Beispiel: Eine Führungskraft beantragt erst am Freitagnachmittag einen vollständigen Arbeitsplatz für Montag. Die Anfrage ist dringend. Es liegt jedoch nicht zwingend eine ungeplante Serviceunterbrechung vor. --- **Notfall durch schlechte Planung** Eine intern verspätete Anfrage sollte nicht automatisch höchste technische Priorität erhalten. Trotzdem muss die Organisation die tatsächlichen Auswirkungen berücksichtigen. Geeignete Vorgehensweise: - Request korrekt klassifizieren, - mögliche Beschleunigung prüfen, - Risiken und Zusatzaufwand transparent machen, - notwendige Entscheidungen eskalieren, - und wiederkehrende Planungsprobleme verbessern. --- **Backlog und Priorität** Innerhalb derselben Priorität kann die Reihenfolge zusätzlich bestimmt werden durch: - Eingangszeit - Serviceziel - Alter des Vorgangs - vorhandene Abhängigkeiten - benötigte Fähigkeiten - zugesagte Termine - Effizienz der gemeinsamen Bearbeitung Ein älteres P3-Ticket sollte nicht dauerhaft durch neue P3-Tickets verdrängt werden. Backlog-Steuerung sollte deshalb auch berücksichtigen: - Ticketalter, - blockierte Vorgänge, - wiederholte Verschiebungen, - und gefährdete Serviceziele. --- **Priorität darf nicht jede Planung zerstören** Hohe Prioritäten sollten tatsächlich besonderen Situationen vorbehalten bleiben. Wenn sehr viele Vorgänge als P1 oder P2 eingestuft werden: - verliert das Modell seine Aussagekraft, - Ressourcen wechseln ständig, - geplante Arbeit wird unterbrochen, - Mitarbeiter werden überlastet, - und wichtige Vorgänge konkurrieren miteinander. Eine hohe Quote kritischer Prioritäten kann hinweisen auf: - unklare Kriterien, - unrealistische Serviceziele, - falsche Benutzerwahl, - organisatorische Fehlanreize, - oder grundsätzlich instabile Services. --- **Prioritätsinflation** Prioritätsinflation entsteht, wenn immer mehr Vorgänge hoch priorisiert werden, um schneller bearbeitet zu werden. Mögliche Anzeichen: - Benutzer wählen regelmäßig „kritisch“. - Führungskräfte verlangen Sonderbehandlung. - Supportgruppen erhöhen Prioritäten zur Eskalation. - Serviceziele werden nur durch formale Umklassifizierung eingehalten. - fast jedes Ticket ist P1 oder P2. Mögliche Maßnahmen: - Kriterien präzisieren, - Benutzerfelder überarbeiten, - Priorität automatisch vorschlagen statt frei auswählen lassen, - Stichproben durchführen, - und Fehlanreize in Kennzahlen beseitigen. --- **Falsche Herabstufung** Prioritäten können ebenfalls zu niedrig angesetzt werden. Mögliche Ursachen: - geschäftlicher Kontext ist unbekannt, - Benutzerzahl wird überbewertet, - Sicherheitsauswirkung wird nicht erkannt, - Servicekritikalität fehlt, - oder Supportteam möchte Zielverletzungen vermeiden. Beispiel: Nur ein Benutzer meldet einen Fehler. Dieser Benutzer ist jedoch für die gesetzlich fristgebundene Meldung verantwortlich. Ohne Kontext könnte der Vorgang fälschlich als geringe Auswirkung bewertet werden. --- **Automatisierte Priorisierung** Werkzeuge können eine Priorität vorschlagen anhand von: - ausgewähltem Service, - Benutzerzahl, - Standort, - Incident-Art, - Servicekritikalität, - Monitoring-Daten, - und bekannten Abhängigkeiten. Vorteile: - schnellere Ersterfassung, - einheitlichere Bewertung, - automatische Eskalation. Risiken: - unvollständige Eingangsdaten, - veraltete Servicekritikalität, - falsche Kategorien, - unerkannte Ausnahmen, - und zu starre Regeln. > **Merke** > > Automatisierung kann Priorisierung unterstützen. > > Sie ersetzt nicht die fachliche Bewertung ungewöhnlicher Situationen. --- **KI-gestützte Priorisierung** KI kann Muster erkennen in: - Tickettexten, - betroffenen Services, - vergangenen Incidents, - Benutzerangaben, - Monitoring-Daten, - Kommunikationsverläufen. Sie kann beispielsweise vorschlagen: - mögliche Auswirkung, - mögliche Dringlichkeit, - Prioritätsstufe, - notwendige Eskalation. Mögliche Risiken: - falsche Interpretation, - Benachteiligung bestimmter Benutzergruppen, - Überbewertung emotionaler Sprache, - unerkannte Sicherheitsmeldungen, - fehlende Nachvollziehbarkeit. Notwendig sind: - menschliche Überprüfung bei kritischen Fällen, - transparente Kriterien, - Qualitätsmessung, - Korrekturmöglichkeiten, - klare Ergebnisverantwortung. --- **Emotionale Sprache und KI** Eine KI darf nicht automatisch eine hohe Priorität setzen, nur weil ein Ticket Wörter enthält wie: - dringend, - sofort, - katastrophal, - Vorstand, - kritisch. Sie muss organisatorisch relevante Auswirkungen erkennen oder zur weiteren Klärung auffordern. Beispiel: > „Extrem dringend: Mauszeiger ist zu langsam.“ Die Formulierung allein beweist keine hohe Auswirkung oder Dringlichkeit. --- **Priorisierung bei Sicherheitsmeldungen** Eine Sicherheitsmeldung benötigt möglicherweise ein separates Bewertungsmodell. Zusätzliche Kriterien können sein: - Art des betroffenen Kontos - Berechtigungsumfang - aktive Ausnutzung - Datenklassifizierung - mögliche Ausbreitung - Beweislage - notwendige Meldefristen Ein scheinbar kleiner Vorfall kann hohe Kritikalität besitzen. Beispiel: Nur ein Administratorkonto zeigt eine verdächtige Anmeldung. Die Benutzerzahl ist gering. Der mögliche Berechtigungsumfang ist jedoch sehr hoch. --- **Priorisierung bei Datenverlust** Zu klären sind: - Welche Daten sind betroffen? - Sind Sicherungen vorhanden? - Werden weiterhin Daten überschrieben? - Wie groß ist das Wiederherstellungsfenster? - Sind rechtliche oder vertragliche Anforderungen betroffen? - Kann die Datenquelle isoliert werden? - Welche weiteren Benutzer oder Systeme sind gefährdet? Die erste Priorität kann darin bestehen, weiteren Schaden zu verhindern. --- **Priorisierung bei Performance-Problemen** Ein Service kann technisch verfügbar sein, aber praktisch nicht ausreichend nutzbar. Zu bewerten sind: - tatsächliche Antwortzeiten, - betroffene Benutzer, - kritische Geschäftszeiten, - Fehlerquote, - mögliche Verschlechterung, - verfügbare Alternativen. Beispiel: Eine Anwendung benötigt statt zwei Sekunden nun 30 Sekunden pro Vorgang. Bei wenigen Vorgängen ist dies möglicherweise begrenzt. Während eines Massenabrechnungslaufs kann dieselbe Verzögerung den gesamten Prozess blockieren. --- **Priorisierung bei geplanten Changes** Ein Incident nach einem Change kann besondere Aufmerksamkeit benötigen. Zu prüfen sind: - zeitlicher Zusammenhang, - betroffene Services, - Rückfallmöglichkeit, - laufendes Wartungsfenster, - Risiko weiterer Auswirkungen. Die Priorität wird weiterhin anhand der tatsächlichen Auswirkung und Dringlichkeit bestimmt. Ein Zusammenhang mit einem Change bedeutet nicht automatisch P1. --- **Priorisierung und Lieferanten** Bei Lieferantenfällen müssen möglicherweise zusätzlich berücksichtigt werden: - Vertragsprioritäten - Service-Level-Vereinbarungen - Supportzeiten - Eskalationswege - Kundennummern - notwendige Nachweise Die interne Priorität und die Lieferantenpriorität können unterschiedliche Bezeichnungen besitzen. Beispiel: Intern: > P1 Beim Provider: > Severity 1 Die Organisation muss die Zuordnung kennen und prüfen, ob die Kriterien tatsächlich übereinstimmen. --- **Kommunikation einer Priorität** Benutzer müssen nicht zwingend jedes interne Prioritätsdetail verstehen. Sie sollten jedoch nachvollziehen können: - wie die Situation bewertet wurde, - welcher nächste Schritt erfolgt, - und wann sie eine Rückmeldung erhalten. Geeignete Formulierung: > Der Vorgang wurde als hohe Priorität eingestuft, weil der gesamte Standort betroffen ist und keine Zwischenlösung besteht. Das Netzwerkteam und der Provider arbeiten bereits an der Wiederherstellung. Die nächste Statusmeldung erfolgt spätestens um 10:30 Uhr. Bei niedrigerer Priorität: > Der Vorgang wird innerhalb der normalen Servicezeit bearbeitet. Aktuell ist ein Benutzer betroffen und ein alternativer Arbeitsplatz steht zur Verfügung. Sollte diese Alternative ausfallen, melden Sie sich bitte unter Angabe der Vorgangsnummer, damit die Priorität neu bewertet werden kann. --- **Keine Prioritätsdiskussion ohne Kontext** Ungeeignet: > Das ist nur P3. Besser: > Nach den aktuellen Informationen ist eine Person betroffen und eine funktionsfähige Alternative vorhanden. Deshalb wird der Vorgang derzeit als P3 bearbeitet. Wenn weitere Benutzer betroffen sind oder die Alternative ausfällt, erhöhen wir die Priorität. --- **Governance der Priorisierung** Eine wirksame Priorisierung benötigt: - dokumentierte Kriterien, - klare Entscheidungsbefugnisse, - nachvollziehbare Änderungen, - geeignete Schulung, - regelmäßige Qualitätsprüfung, - Continual Improvement. Zu klären ist: - Wer definiert die Matrix? - Wer genehmigt Änderungen? - Wie werden kritische Services berücksichtigt? - Wie werden Sicherheitsereignisse behandelt? - Wie werden Zielzeiten festgelegt? - Wie werden Fehlpriorisierungen erkannt? - Welche Kennzahlen werden verwendet? - Wie werden Ausnahmen entschieden? --- **Prioritätsmodell regelmäßig überprüfen** Das Modell kann ungeeignet werden durch: - neue Services, - veränderte Geschäftsprozesse, - neue Standorte, - organisatorische Veränderungen, - neue Sicherheitsanforderungen, - neue Servicezeiten. Regelmäßig zu prüfen sind: - Sind die Kriterien verständlich? - Werden zu viele Tickets hoch priorisiert? - Werden kritische Situationen zuverlässig erkannt? - Passen Zielzeiten zu den Ressourcen? - Werden Workarounds korrekt berücksichtigt? - Sind Servicekritikalitäten aktuell? - Gibt es wiederkehrende Ausnahmen? - Unterstützt das Modell gewünschtes Verhalten? --- **Kennzahlen zur Priorisierung** Mögliche Kennzahlen: - Anzahl der Tickets pro Prioritätsstufe - Anteil nachträglich geänderter Prioritäten - häufige Gründe für Erhöhungen - häufige Gründe für Herabstufungen - Zielerreichung je Priorität - durchschnittliche Wiederherstellungszeit - Anzahl falsch priorisierter Incidents - Anzahl als kritisch gemeldeter, aber niedrig eingestufter Kontakte - Wiedereröffnungsquote - Benutzerbeschwerden über Priorisierung - Anteil von Sicherheitsmeldungen mit korrekter Eskalation - Alter des Backlogs je Priorität Kennzahlen sollten nicht isoliert betrachtet werden. --- **Problematische Kennzahlen** **Möglichst wenige P1-Incidents** Mögliche Fehlwirkung: - kritische Incidents werden als P2 klassifiziert. **Möglichst hohe Zielerreichung** Mögliche Fehlwirkung: - Prioritäten werden herabgesetzt, - Zielzeiten werden gestoppt, - Tickets werden voreilig geschlossen. **Möglichst kurze Lösungszeit** Mögliche Fehlwirkung: - komplexe Ursachen werden nicht ausreichend dokumentiert, - Workarounds werden als dauerhafte Lösung behandelt, - Benutzerbestätigung wird übersprungen. > **Merke** > > Kennzahlen dürfen nicht dazu führen, dass die Prioritätsbewertung manipuliert wird. --- **Praxisbeispiel: Ein Benutzer, hohe Auswirkung** **Meldung** Ein einzelner Mitarbeiter kann eine Produktionsfreigabe nicht durchführen. **Zusätzlicher Kontext** - Nur dieses Konto besitzt aktuell die notwendige Freigabeberechtigung. - Fertigungsaufträge warten. - In 30 Minuten steht die Linie still. - Kein geeigneter Stellvertreter ist verfügbar. **Bewertung** - Benutzerzahl: niedrig - Auswirkung: hoch - Dringlichkeit: hoch - mögliche Priorität: P1 Das Beispiel zeigt, warum Benutzerzahl nicht allein ausreicht. --- **Praxisbeispiel: Viele Benutzer, niedrige Dringlichkeit** **Meldung** Das interne Archivsystem ist für alle Benutzer nicht erreichbar. **Zusätzlicher Kontext** - Es wird für die aktuelle Tagesarbeit nicht benötigt. - Am nächsten Arbeitstag findet eine Prüfung statt. - Alle benötigten Unterlagen wurden vorübergehend exportiert. - Es besteht kein Datenverlust. **Bewertung** - Benutzerkreis: groß - Auswirkung: möglicherweise hoch - unmittelbare Dringlichkeit: mittel oder niedrig - mögliche Priorität: abhängig vom Organisationsmodell P2 oder P3 --- **Praxisbeispiel: Führungskraft mit geringerer Auswirkung** **Meldung** Eine Führungskraft kann einen zweiten Bildschirm nicht verwenden. **Zusätzlicher Kontext** - Hauptbildschirm funktioniert. - alle Anwendungen sind nutzbar. - kein zeitkritischer Termin wird beeinträchtigt. - Ersatzgerät kann am nächsten Tag bereitgestellt werden. **Bewertung** - Auswirkung: niedrig - Dringlichkeit: niedrig - mögliche Priorität: P4 Die Position der meldenden Person verändert die technische Auswirkung nicht automatisch. --- **Praxisbeispiel: Aktive Sicherheitsbedrohung** **Meldung** Ein einzelnes Administratorkonto zeigt mehrere ungewöhnliche Anmeldungen aus einem unbekannten Land. **Zusätzlicher Kontext** - Konto besitzt weitreichende Berechtigungen. - eine Anmeldung war erfolgreich. - Ursache ist noch unbekannt. **Bewertung** - Benutzerzahl: niedrig - mögliche Sicherheitsauswirkung: sehr hoch - Dringlichkeit: hoch - sofortige Sicherheitseskalation erforderlich --- **Praxisbeispiel: Workaround reduziert Dringlichkeit** **Meldung** Die Desktop-Version einer Fachanwendung startet nicht. **Zusätzlicher Kontext** - zehn Benutzer betroffen - Webversion funktioniert vollständig - Daten bleiben konsistent - keine kritische Frist innerhalb der nächsten Stunden **Bewertung vor Workaround** - Auswirkung: mittel oder hoch - Dringlichkeit: hoch **Bewertung nach bestätigtem Workaround** - Auswirkung weiterhin vorhanden - unmittelbare Dringlichkeit möglicherweise geringer - Priorität kann nach festgelegten Regeln neu bewertet werden --- **Praxisbeispiel: Priorität wird erhöht** **Ursprüngliche Situation** Ein Benutzer kann keine Dateien speichern. - ein Benutzer betroffen - alternativer Ordner verfügbar - Priorität P3 **Neue Erkenntnis** Innerhalb von 20 Minuten melden weitere Benutzer dasselbe Problem. Monitoring zeigt: - zentraler Speicher fast vollständig belegt - Schreibvorgänge schlagen für mehrere Services fehl - Datenbankdienst könnte als Nächstes betroffen sein **Neue Bewertung** - Auswirkung: hoch - Dringlichkeit: hoch - Priorität wird auf P1 erhöht - Incident-Koordination wird aktiviert --- **Praxisbeispiel: Request wird nicht zum Incident** Eine Führungskraft meldet am Freitagnachmittag: > Neuer Mitarbeiter beginnt Montag. Notebook, Konto und alle Anwendungen werden dringend benötigt. Die Situation ist zeitkritisch. Es handelt sich jedoch um eine verspätet eingereichte Onboarding-Anfrage und nicht automatisch um einen Incident. Mögliche Behandlung: - Request mit hoher interner Dringlichkeit erfassen - Machbarkeit prüfen - notwendige Genehmigungen und Risiken klären - verfügbare Zwischenlösung anbieten - Planungsproblem anschließend verbessern --- **Typische Fehler bei der Priorisierung** **Fehler 1: Priorität nur nach Benutzerzahl bestimmen** Ein einzelner kritischer Arbeitsplatz wird unterschätzt. **Fehler 2: Priorität nach Hierarchie bestimmen** Führungskräfte erhalten automatisch P1. **Fehler 3: Benutzer bestimmt endgültige Priorität** Subjektive Dringlichkeit ersetzt organisatorische Kriterien. **Fehler 4: Jede Störung eines kritischen Service ist P1** Teilfunktionen und geeignete Workarounds werden nicht berücksichtigt. **Fehler 5: Technische Komplexität mit Priorität verwechseln** Schwierige Fehler werden bevorzugt, obwohl andere Vorgänge größere Auswirkungen besitzen. **Fehler 6: Priorität nach der Ersterfassung nie ändern** Ausbreitung und neue Risiken bleiben unberücksichtigt. **Fehler 7: Workaround automatisch als vollständige Lösung behandeln** Ursache und verbleibende Einschränkungen werden übersehen. **Fehler 8: Sicherheit nur nach Benutzerzahl bewerten** Ein kompromittiertes Administratorkonto wird unterschätzt. **Fehler 9: Zu viele P1- und P2-Tickets** Das Prioritätsmodell verliert seine Steuerungswirkung. **Fehler 10: Hohe Priorität zur Beschleunigung missbrauchen** Normale Requests verdrängen tatsächliche Incidents. **Fehler 11: Priorität senken, um Zielverletzung zu vermeiden** Kennzahlen werden manipuliert. **Fehler 12: Priorität und Major Incident gleichsetzen** Besondere Koordination wird entweder unnötig oder zu spät aktiviert. **Fehler 13: Zielzeit als Lösungsversprechen kommunizieren** Benutzer erhalten falsche Erwartungen. **Fehler 14: Zwischenlösung nicht fachlich prüfen** Unsichere oder unvollständige Alternativen führen zu falscher Herabstufung. **Fehler 15: Prioritätsänderung nicht dokumentieren** Spätere Entscheidungen sind nicht nachvollziehbar. **Fehler 16: Servicekritikalität ist veraltet** Neue geschäftliche Abhängigkeiten werden nicht erkannt. **Fehler 17: KI-Vorschlag ungeprüft übernehmen** Emotionale Sprache oder falsche Kategorien bestimmen die Priorität. --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker liefern wichtige Informationen für die Prioritätsbewertung. Sie können beurteilen: - welcher Service betroffen ist, - welche technischen Abhängigkeiten bestehen, - wie weit sich ein Fehler ausbreitet, - ob Datenverlust droht, - ob ein Workaround technisch sicher ist, - und welche weiteren Systeme gefährdet sind. Technische Rückmeldungen sollten nicht nur lauten: > Server ist ausgefallen. Besser: > Der Server unterstützt die zentrale Anmeldung für VPN und drei Cloud-Anwendungen. Aktuell können sich neue Benutzer nicht anmelden. Bestehende Sitzungen funktionieren noch. Ohne Wiederherstellung werden bei Ablauf der Sitzungen zunehmend weitere Benutzer betroffen sein. Ein sicherer Workaround besteht derzeit nicht. Diese Informationen helfen bei der Bewertung von: - Auswirkung, - Dringlichkeit, - Priorität, - Eskalation. --- **30-Sekunden-Prüfung der Auswirkung** 1. Welcher Service ist betroffen? 2. Welche Benutzer oder Kunden sind betroffen? 3. Welcher Geschäftsprozess ist beeinträchtigt? 4. Besteht vollständiger oder teilweiser Ausfall? 5. Gibt es Datenverlust oder Sicherheitsbezug? 6. Besteht eine geeignete Zwischenlösung? 7. Sind weitere Services abhängig? 8. Welche finanziellen, vertraglichen oder rechtlichen Folgen bestehen? 9. Besteht Gesundheits- oder Sicherheitsbezug? 10. Wie stark kann sich die Auswirkung noch vergrößern? --- **30-Sekunden-Prüfung der Dringlichkeit** 1. Tritt der Schaden bereits ein? 2. Verschlimmert sich die Situation? 3. Wann wird ein kritischer Zeitpunkt erreicht? 4. Besteht eine zeitliche Frist? 5. Droht weiterer Datenverlust? 6. Besteht eine aktive Sicherheitsbedrohung? 7. Wie lange ist der Workaround nutzbar? 8. Kann die Bearbeitung sicher geplant werden? 9. Welche Wiederherstellungsfenster bestehen? 10. Wann müssen weitere Rollen oder Lieferanten eingebunden werden? --- **Checkliste für die Ersterfassung** - [ ] Ist der betroffene Service bekannt? - [ ] Sind betroffene Benutzer, Standorte oder Kunden bekannt? - [ ] Ist der betroffene Geschäftsprozess beschrieben? - [ ] Ist der Umfang der Beeinträchtigung bekannt? - [ ] Besteht vollständiger oder teilweiser Ausfall? - [ ] Ist eine sichere Zwischenlösung vorhanden? - [ ] Besteht möglicher Datenverlust? - [ ] Besteht Sicherheits- oder Datenschutzbezug? - [ ] Gibt es eine zeitkritische Frist? - [ ] Wurde Auswirkung getrennt von Dringlichkeit bewertet? - [ ] Ist die vorläufige Priorität begründet? - [ ] Ist ein Zeitpunkt für die Neubewertung festgelegt? --- **Checkliste für hohe Priorität** - [ ] Sind die Kriterien für hohe Priorität tatsächlich erfüllt? - [ ] Ist ein kritischer Service oder Geschäftsprozess betroffen? - [ ] Besteht erheblicher Benutzer- oder Kundenbezug? - [ ] Besteht keine ausreichende Zwischenlösung? - [ ] Nimmt der Schaden weiter zu? - [ ] Besteht Sicherheits-, Datenschutz- oder Datenverlustbezug? - [ ] Sind notwendige Fachteams informiert? - [ ] Ist Incident-Koordination erforderlich? - [ ] Sind Lieferanten erreichbar und eingebunden? - [ ] Ist die Kommunikationsverantwortung geklärt? - [ ] Sind Statusintervalle festgelegt? - [ ] Wird die Priorität regelmäßig neu bewertet? --- **Checkliste für eine Prioritätsänderung** - [ ] Welche neue Information liegt vor? - [ ] Hat sich die Auswirkung verändert? - [ ] Hat sich die Dringlichkeit verändert? - [ ] Ist ein Workaround verfügbar oder ausgefallen? - [ ] Sind weitere Benutzer oder Services betroffen? - [ ] Ist ein neuer Sicherheits- oder Datenbezug entstanden? - [ ] Wer hat die Änderung entschieden? - [ ] Wurde der Grund dokumentiert? - [ ] Wurden Eskalationen angepasst? - [ ] Wurden Benutzer und Stakeholder informiert? - [ ] Wurden Zielzeiten und Statusintervalle aktualisiert? --- **Checkliste für das Prioritätsmodell der Organisation** - [ ] Sind Auswirkung und Dringlichkeit eindeutig definiert? - [ ] Sind die Bewertungsstufen verständlich? - [ ] Sind kritische Services bekannt? - [ ] Werden Sicherheits- und Datenschutzereignisse angemessen behandelt? - [ ] Werden Gesundheits- und Sicherheitsrisiken berücksichtigt? - [ ] Sind Prioritätsstufen eindeutig beschrieben? - [ ] Sind Zielzeiten und Statusintervalle realistisch? - [ ] Ist festgelegt, wer Prioritäten ändern darf? - [ ] Sind Ausnahmen und Eskalationen geregelt? - [ ] Werden Workarounds angemessen berücksichtigt? - [ ] Werden Prioritätsänderungen dokumentiert? - [ ] Werden Fehlpriorisierungen ausgewertet? - [ ] Wird Prioritätsinflation überwacht? - [ ] Wird das Modell regelmäßig verbessert? --- **Schnellreferenz** | Frage | Zu bewertender Bereich | |---|---| | Wie viele Benutzer sind betroffen? | Auswirkung | | Welcher Service ist betroffen? | Auswirkung | | Welcher Geschäftsprozess steht still? | Auswirkung | | Besteht Daten- oder Sicherheitsrisiko? | Auswirkung und Dringlichkeit | | Gibt es einen geeigneten Workaround? | Auswirkung und Dringlichkeit | | Wann verschlimmert sich die Situation? | Dringlichkeit | | Welche Frist läuft ab? | Dringlichkeit | | Wie schnell muss gehandelt werden? | Dringlichkeit | | In welcher Reihenfolge wird bearbeitet? | Priorität | | Welche Zielzeiten gelten? | Priorität und Service Level | | Ist besondere Koordination notwendig? | Eskalation oder Major Incident | | Muss die Bewertung geändert werden? | dynamische Neubewertung | --- **Zusammenfassende Darstellung** > Incident oder Request wird erfasst > ↓ > betroffenen Service und Geschäftsprozess bestimmen > ↓ > Anzahl und Bedeutung der betroffenen Stakeholder bewerten > ↓ > Daten-, Sicherheits-, Finanz- und Kundenfolgen berücksichtigen > ↓ > **Auswirkung bestimmen** > ↓ > Zeitdruck, Verschlechterung, Fristen und Workaround bewerten > ↓ > **Dringlichkeit bestimmen** > ↓ > organisatorische Matrix oder Entscheidungsregel anwenden > ↓ > **Priorität festlegen und begründen** > ↓ > Zielzeiten, Ownership, Eskalation und Kommunikation auslösen > ↓ > Situation fortlaufend beobachten > ↓ > Priorität bei neuen Erkenntnissen erhöhen oder senken > ↓ > Entscheidung und Auswirkungen nachvollziehbar dokumentieren --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.2 Kontaktkanäle und Erreichbarkeit - 3.3 Benutzerkommunikation und professioneller Umgang - 3.4 Tickets vollständig erfassen und kategorisieren - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.8 Self-Service, Wissensnutzung und Automatisierung - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Incident Management - Service Request Management - Information Security Management - Service Level Management - Service Continuity Management - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - [PeopleCert: ITIL 4 Practitioner – Incident Management](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-incident-management-3684) - [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706) - [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/ITIL-Service-Version-5) - [PeopleCert: ITIL Foundation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) **Offiziell bestätigter Stand** Die offiziellen ITIL- und PeopleCert-Quellen bestätigen: - Incident Management dient der schnellen Wiederherstellung des normalen Servicebetriebs nach Störungen. - Incident Management umfasst Prozesse, Rollen, Informationen, Technologien, Partner, Messgrößen und die Integration in organisatorische Wertströme. - Einheitliche Arbeitsweisen und ein gemeinsames Verständnis helfen, inkonsistente Priorisierung und übersehene wichtige Vorgänge zu vermeiden. - Service-Desk- und Incident-Management-Practices müssen an organisatorische Bedürfnisse, Wertströme und Services angepasst werden. - ITIL Version 5 führt die Management Practices fort und richtet digitale Servicearbeit an Outcomes, Erfahrung, Resilienz und Ende-zu-Ende-Zusammenarbeit aus. **Einordnung** Die auf dieser Seite dargestellten: - Auswirkungs- und Dringlichkeitsstufen, - Prioritätsmatrix, - P1-bis-P4-Bezeichnungen, - Zielzeitbeispiele, - Statusintervalle, - Entscheidungskriterien, - Praxisbeispiele, - und Checklisten sind herstellerneutrale redaktionelle Praxisempfehlungen dieses unabhängigen Nachschlagewerks. ITIL schreibt keine universelle: - Prioritätsmatrix, - Anzahl von Prioritätsstufen, - Reaktionszeit, - Wiederherstellungszeit, - Severity-Skala, - VIP-Regel, - oder Major-Incident-Grenze für alle Organisationen vor. Die konkrete Gestaltung muss angepasst werden an: - Produkte und Services, - Geschäftsprozesse, - Servicekritikalität, - Benutzer und Kunden, - Sicherheits- und Datenschutzanforderungen, - gesetzliche Verpflichtungen, - Servicezeiten, - Fähigkeiten, - Lieferanten, - verfügbare Ressourcen. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 3.6 Erstdiagnose, Lösung und funktionale Eskalation (Teil 1/2) > **Kurz erklärt** > > Ziel der Erstdiagnose ist nicht, sofort die eigentliche Ursache zu kennen, sondern möglichst schnell die Situation zu verstehen, Auswirkungen zu begrenzen und den Service wiederherzustellen. > > Gute Diagnosen beruhen auf: > > - Beobachtungen, > - überprüfbaren Fakten, > - strukturierten Tests, > - technischem Wissen, > - vorhandenen Erfahrungen, > - und nachvollziehbaren Entscheidungen. > > ITIL empfiehlt, vorhandenes Wissen systematisch zu nutzen und Incidents möglichst früh dort zu lösen, wo die erforderlichen Fähigkeiten vorhanden sind. --- ## Ziele der Erstdiagnose Nach der Ticketaufnahme beginnt die eigentliche Analyse. Dabei sollten zunächst folgende Fragen beantwortet werden: - Was funktioniert nicht? - Was funktioniert noch? - Seit wann besteht die Störung? - Wer ist betroffen? - Welche Änderungen gab es kurz zuvor? - Welche Systeme hängen zusammen? - Gibt es bereits bekannte Incidents? - Existiert ein Workaround? Die Erstdiagnose soll möglichst schnell klären, - ob der Service wiederhergestellt werden kann, - ob Spezialisten benötigt werden, - oder ob eine funktionale Eskalation notwendig ist. --- ## Erstdiagnose ist keine Ursachenanalyse Ein häufiger Fehler besteht darin, bereits in den ersten Minuten die eigentliche Ursache finden zu wollen. Die Erstdiagnose verfolgt jedoch ein anderes Ziel. | Erstdiagnose | Ursachenanalyse | |---|---| | Service möglichst schnell wiederherstellen | eigentliche Ursache dauerhaft finden | | Minuten bis Stunden | Stunden bis Tage | | Incident Management | Problem Management | | Fokus auf Wiederherstellung | Fokus auf Prävention | Beispiel: Ein Webserver antwortet nicht. Während der Erstdiagnose genügt möglicherweise: - Dienst neu starten, - Funktion prüfen, - Benutzer informieren. Warum der Dienst abgestürzt ist, wird später im Problem Management untersucht. > **Merke** > > Ein gelöster Incident bedeutet nicht automatisch, dass die Ursache beseitigt wurde. --- ## Beobachtung vor Interpretation Techniker neigen häufig dazu, sehr früh Vermutungen aufzustellen. Besser ist folgende Reihenfolge: 1. Beobachten 2. Informationen sammeln 3. Hypothesen bilden 4. Hypothesen testen 5. Ursache bestätigen Beispiel: ❌ "Die Firewall blockiert den Zugriff." Besser: ✅ "HTTPS-Verbindungen schlagen fehl. Andere Protokolle funktionieren. Firewall ist eine mögliche Ursache." --- ## Symptome richtig erfassen Ein Symptom beschreibt das beobachtete Verhalten. Beispiele: - Anmeldung schlägt fehl - Druckauftrag bleibt hängen - Anwendung reagiert nicht - Datei lässt sich nicht öffnen - VPN verbindet nicht Ein Symptom ist noch keine Ursache. --- ## Mögliche Ursachen Für dasselbe Symptom können völlig unterschiedliche Ursachen verantwortlich sein. **Symptom** > Anmeldung nicht möglich Mögliche Ursachen: - Passwort falsch - Konto gesperrt - Active Directory nicht erreichbar - DNS-Problem - Netzwerkfehler - Zertifikat abgelaufen - MFA-Dienst gestört - Cloud-Ausfall Deshalb sollten Vermutungen immer überprüft werden. --- ## Strukturierte Diagnose Eine bewährte Reihenfolge lautet: 1. Problem verstehen 2. Umfang bestimmen 3. Änderungen prüfen 4. Logs prüfen 5. Monitoring prüfen 6. Verbindung testen 7. Komponenten eingrenzen 8. Hypothese testen 9. Ergebnis dokumentieren --- ## Umfang bestimmen Nicht jede Störung betrifft alle Benutzer. Zu klären ist: - Ein Benutzer? - Mehrere Benutzer? - Ein Standort? - Alle Standorte? - Nur Windows? - Auch macOS? - Nur VPN? - Auch intern? Je genauer der Umfang bekannt ist, desto einfacher lässt sich die Ursache eingrenzen. --- ## Änderungen berücksichtigen Viele Incidents entstehen kurz nach Änderungen. Zu prüfen sind beispielsweise: - Software-Updates - neue Firewall-Regeln - Zertifikatswechsel - DNS-Änderungen - neue Switch-Konfiguration - Benutzeränderungen - Gruppenrichtlinien - Cloud-Änderungen Frage: > **Was hat sich kurz vor dem Fehler geändert?** Diese Frage spart häufig sehr viel Diagnosezeit. --- ## Reproduzierbarkeit prüfen Ein Fehler sollte möglichst reproduziert werden. Beispiel: 1. Anwendung starten 2. Benutzer anmelden 3. Auftrag öffnen 4. Speichern Tritt der Fehler jedes Mal auf? Oder nur gelegentlich? Auch diese Information grenzt Ursachen erheblich ein. --- ## Bekannte Fehler nutzen Vor aufwendigen Analysen sollte geprüft werden: - Gibt es einen bekannten Incident? - Existiert ein Knowledge-Artikel? - Hat der Hersteller bereits einen Hinweis veröffentlicht? - Gab es ähnliche Tickets? Viele Incidents lassen sich dadurch deutlich schneller lösen. --- ## Monitoring verwenden Monitoring liefert häufig frühere Hinweise als Benutzer. Beispiele: - CPU-Auslastung - RAM - Festplattenspeicher - Netzwerk - Dienste - Zertifikate - Backup - Hardware Monitoring ersetzt jedoch keine Diagnose. Es zeigt häufig nur Symptome. --- ## Logs richtig einsetzen Logs beantworten häufig Fragen wie: - Wann trat der Fehler auf? - Welche Komponente war beteiligt? - Welche Fehlermeldung wurde erzeugt? - Welche Benutzer waren betroffen? Dabei gilt: Nicht jede Warnung ist automatisch relevant. Logs müssen immer im Zusammenhang betrachtet werden. --- ## Ausschlussverfahren Eine sehr effektive Methode ist das Ausschlussprinzip. Beispiel: VPN funktioniert nicht. Prüfung: - Internet vorhanden ✔️ - DNS funktioniert ✔️ - Anmeldung funktioniert ✔️ - VPN-Server erreichbar ✔️ - Zertifikat gültig ❌ Die Ursache lässt sich dadurch systematisch eingrenzen. --- ## Von einfach nach komplex ITIL empfiehlt keine feste Reihenfolge. In der Praxis hat sich jedoch bewährt: 1. Offensichtliches prüfen 2. Bekannte Fehler prüfen 3. Änderungen prüfen 4. Monitoring prüfen 5. Logs prüfen 6. Detailanalyse Nicht sofort mit der kompliziertesten Hypothese beginnen. --- ## Keine unnötigen Änderungen Während der Diagnose sollte möglichst nicht gleichzeitig an mehreren Komponenten gearbeitet werden. Schlecht: - Firewall ändern - DNS ändern - Server neu starten - Zertifikat erneuern Danach ist kaum nachvollziehbar, welche Maßnahme tatsächlich geholfen hat. Besser: Eine Änderung durchführen. Ergebnis prüfen. Dokumentieren. Erst danach die nächste Maßnahme. --- ## Hypothesen dokumentieren Eine gute Arbeitsnotiz enthält: **Hypothese** DNS-Auflösung fehlerhaft. **Test** Namensauflösung gegen internen DNS geprüft. **Ergebnis** DNS funktioniert. **Schlussfolgerung** Hypothese verworfen. Dadurch vermeiden andere Bearbeiter dieselben Tests. --- ## Wissen systematisch nutzen Erfahrungen sollten nicht ausschließlich im Kopf einzelner Administratoren bleiben. Hilfreich sind: - Knowledge-Artikel - Standardlösungen - Runbooks - Checklisten - bekannte Fehler - Herstellerdokumentation Dadurch steigt die First Contact Resolution deutlich. --- ## First Contact Resolution (FCR) FCR beschreibt den Anteil der Incidents, die bereits beim ersten Kontakt vollständig gelöst werden. Vorteile: - kürzere Wartezeit - zufriedenere Benutzer - weniger Eskalationen - geringere Kosten FCR darf jedoch nicht künstlich erhöht werden, indem Tickets vorschnell geschlossen werden. --- ## Shift Left Shift Left bedeutet, Wissen möglichst früh im Support bereitzustellen. Beispiele: - bessere Wissensdatenbank - Self-Service - Standardlösungen - Automatisierung - KI-Unterstützung - Schulungen Dadurch können mehr Incidents bereits im Service Desk gelöst werden. --- ## Dokumentation während der Diagnose Nicht erst am Ende dokumentieren. Nach jeder wichtigen Maßnahme sollte festgehalten werden: - Zeitpunkt - Maßnahme - Ergebnis - nächster Schritt Dadurch bleiben Übergaben nachvollziehbar. --- ## Merksätze > Symptome sind keine Ursachen. > Beobachtungen sind wichtiger als Vermutungen. > Erst den Service wiederherstellen, anschließend die eigentliche Ursache untersuchen. > Jede Diagnose sollte nachvollziehbar dokumentiert werden. > Bekannte Lösungen sind schneller als neue Vermutungen. # 3.6 Erstdiagnose, Lösung und funktionale Eskalation (Teil 2/2) > **Kurz erklärt** > > Die Erstdiagnose soll einen Incident schnell verstehen, eingrenzen und möglichst früh beheben. > > Dabei geht es zunächst nicht darum, die endgültige Ursache vollständig zu ermitteln. Das wichtigste Ziel des Incident Managements ist die schnelle Wiederherstellung des vereinbarten Servicebetriebs. > > Kann der Incident mit den vorhandenen Kenntnissen, Werkzeugen oder Berechtigungen nicht gelöst werden, erfolgt eine **funktionale Eskalation** an eine geeignete Fachgruppe. --- **Ziele der Erstdiagnose** Die Erstdiagnose soll möglichst schnell klären: - Was funktioniert nicht? - Was funktioniert weiterhin? - Wer oder was ist betroffen? - Seit wann besteht die Beeinträchtigung? - Welche Auswirkungen entstehen? - Gab es kurz zuvor einen Change? - Ist bereits ein ähnlicher Incident bekannt? - Existiert ein dokumentierter Workaround? - Kann der Service Desk den Incident direkt lösen? - Welche Fachkenntnisse werden andernfalls benötigt? Eine gute Erstdiagnose reduziert: - unnötige Rückfragen, - doppelte Prüfungen, - falsche Eskalationen, - lange Bearbeitungszeiten, - und vermeidbare Serviceunterbrechungen. --- **Erstdiagnose und Ursachenanalyse unterscheiden** Die Erstdiagnose gehört in erster Linie zum Incident Management. Die tiefergehende Ursachenanalyse gehört häufig zum Problem Management. | Erstdiagnose | Ursachenanalyse | |---|---| | Service möglichst schnell wiederherstellen | zugrunde liegende Ursache untersuchen | | kurzfristiger Fokus | langfristiger Fokus | | Workaround oder schnelle Lösung möglich | dauerhafte Lösung vorbereiten | | Incident Management | Problem Management | | Minuten bis Stunden | abhängig von Komplexität auch deutlich länger | Beispiel: Ein Anwendungsdienst reagiert nicht mehr. **Incident Management** - Dienst kontrolliert neu starten - Funktion testen - Benutzer informieren - Service wiederherstellen **Problem Management** - Ursache des Absturzes untersuchen - Speicherverbrauch analysieren - Softwarefehler prüfen - dauerhafte Korrektur planen > **Merke** > > Ein Incident kann gelöst sein, obwohl die eigentliche Ursache noch nicht bekannt oder beseitigt ist. --- **Symptom, Ursache und Auswirkung unterscheiden** | Begriff | Bedeutung | Beispiel | |---|---|---| | **Symptom** | beobachtetes Fehlverhalten | Anmeldung schlägt fehl | | **unmittelbare Ursache** | direkter technischer Auslöser | Zertifikat abgelaufen | | **Grundursache** | tiefer liegende Ursache | Zertifikatsüberwachung fehlte | | **Auswirkung** | Folge für Benutzer oder Geschäftsprozess | Benutzer können nicht arbeiten | Zu Beginn eines Incidents ist häufig nur das Symptom bekannt. Die Ursache darf deshalb nicht vorschnell als bestätigt dokumentiert werden. Ungeeignet: > Die Firewall blockiert die Anwendung. Besser: > HTTPS-Verbindungen zur Anwendung schlagen fehl. Eine Blockierung durch die Firewall ist eine mögliche, noch nicht bestätigte Ursache. --- **Beobachtung und Vermutung trennen** Eine strukturierte Diagnose folgt möglichst dieser Reihenfolge: 1. beobachten 2. Informationen sammeln 3. Umfang bestimmen 4. Hypothesen bilden 5. Hypothesen testen 6. Ergebnisse bewerten 7. Service wiederherstellen 8. Maßnahmen dokumentieren Beobachtungen sollten möglichst messbar sein. Ungeeignet: > Das Netzwerk ist langsam. Besser: > Die Antwortzeit zum Gateway liegt normalerweise unter 5 ms. Aktuell werden zwischen 80 und 150 ms sowie Paketverluste von etwa 12 Prozent gemessen. --- **Den Umfang bestimmen** Der Umfang hilft bei der Eingrenzung. Zu prüfen ist beispielsweise: - Ist nur ein Benutzer betroffen? - Sind mehrere Benutzer betroffen? - Ist ein gesamter Standort betroffen? - Betrifft der Fehler alle Geräte oder nur ein bestimmtes? - Ist nur eine Anwendung betroffen? - Funktioniert der Service intern, aber nicht über VPN? - Sind nur neue Anmeldungen betroffen? - Funktionieren bestehende Sitzungen weiterhin? - Sind bestimmte Betriebssysteme oder Versionen betroffen? Beispiel: Eine Anwendung startet bei einem Benutzer nicht. Prüfung: - anderer Benutzer am selben Gerät: funktioniert - derselbe Benutzer an anderem Gerät: funktioniert nicht - andere Anwendungen: funktionieren Damit liegt die Ursache wahrscheinlich eher im Benutzerkonto oder Benutzerprofil als im Gerät. --- **Den Normalzustand kennen** Für die Diagnose muss bekannt sein, was normalerweise geschehen sollte. Beispiel: > Nach Eingabe der Zugangsdaten sollte innerhalb weniger Sekunden die Startseite erscheinen. Stattdessen bleibt der Ladebildschirm dauerhaft sichtbar. Diese Beschreibung ist aussagekräftiger als: > Anmeldung funktioniert nicht. Hilfreiche Fragen: - Was wollten Sie durchführen? - Was sollte normalerweise geschehen? - Was geschieht stattdessen? - Wird eine Fehlermeldung angezeigt? - Wann hat es zuletzt funktioniert? --- **Änderungen berücksichtigen** Viele Incidents treten nach Änderungen auf. Zu prüfen sind beispielsweise: - Softwareupdates - neue Firewall-Regeln - DNS-Änderungen - Zertifikatswechsel - Gruppenrichtlinien - Benutzer- oder Berechtigungsänderungen - Firmwareupdates - Netzwerkumbauten - Cloud-Konfigurationsänderungen - Änderungen durch Lieferanten Eine wichtige Diagnosefrage lautet: > Was hat sich kurz vor Beginn des Fehlers verändert? Ein zeitlicher Zusammenhang beweist jedoch noch keine Ursache. Der Change muss fachlich überprüft werden. --- **Bekannte Incidents und Fehler prüfen** Vor einer aufwendigen Analyse sollte geprüft werden: - Gibt es bereits einen aktiven Incident? - Ist eine allgemeine Störung bekannt? - Existiert ein Problem Record? - Gibt es einen Known Error? - Ist ein geeigneter Knowledge-Artikel vorhanden? - Hat der Hersteller eine Störung oder ein bekanntes Problem gemeldet? - Wurde dieselbe Kombination aus Symptom und Service bereits dokumentiert? Dadurch lassen sich doppelte Analysen vermeiden. --- **Monitoring verwenden** Monitoring kann wichtige Hinweise liefern. Typische Messwerte: - CPU-Auslastung - Arbeitsspeicher - Speicherplatz - Dienststatus - Netzwerkverbindungen - Antwortzeiten - Fehlerraten - Zertifikatsgültigkeit - Backup-Status - Hardwarezustand - Cloud-Service-Status Monitoring zeigt jedoch häufig nur ein Symptom. Beispiel: > CPU-Auslastung 100 Prozent Dies beweist noch nicht, welcher Prozess oder welche Ursache verantwortlich ist. --- **Logs gezielt auswerten** Logs können zeigen: - wann ein Fehler begann, - welche Komponente beteiligt war, - welche Meldung erzeugt wurde, - welches Konto verwendet wurde, - und welche Aktion fehlgeschlagen ist. Bei der Auswertung sollte geprüft werden: - Passt der Zeitstempel zum Incident? - Betrifft die Meldung wirklich den betroffenen Service? - Ist es ein Fehler, eine Warnung oder nur eine Information? - Tritt die Meldung auch im Normalbetrieb auf? - Gibt es zeitlich passende Changes oder Events? Nicht jede rote Fehlermeldung ist für den aktuellen Incident relevant. --- **Reproduzierbarkeit prüfen** Ein reproduzierbarer Fehler lässt sich leichter eingrenzen. Zu dokumentieren sind: - genaue Arbeitsschritte - verwendete Anwendung - Version - Gerät oder Betriebssystem - Benutzerkonto - verwendete Daten - erwartetes Verhalten - tatsächliches Verhalten - Fehlermeldung Beispiel: 1. Anwendung öffnen 2. Auftrag auswählen 3. „PDF exportieren“ anklicken 4. Anwendung beendet sich ohne Meldung Zusatz: - tritt bei drei getesteten Aufträgen auf - nur Desktop-Version betroffen - Webversion funktioniert --- **Vom Einfachen zum Komplexen** Eine sinnvolle Praxisreihenfolge kann sein: 1. Meldung und Auswirkungen verstehen 2. bekannte Störungen prüfen 3. offensichtliche Voraussetzungen prüfen 4. Änderungen vergleichen 5. Monitoring und Logs auswerten 6. Fehlerbereich eingrenzen 7. Hypothesen testen 8. Spezialisten einbinden Dies ist keine feste ITIL-Vorgabe. Es verhindert jedoch, dass sofort mit besonders aufwendigen oder riskanten Maßnahmen begonnen wird. --- **Ausschlussverfahren** Beim Ausschlussverfahren werden mögliche Fehlerbereiche systematisch geprüft. Beispiel: VPN-Verbindung funktioniert nicht. | Prüfung | Ergebnis | |---|---| | Internetverbindung vorhanden | ja | | DNS-Auflösung funktioniert | ja | | VPN-Gateway erreichbar | ja | | Benutzerkonto aktiv | ja | | MFA erfolgreich | ja | | Client-Zertifikat gültig | nein | Damit wurde der Fehler auf das Zertifikat eingegrenzt. > **Merke** > > Jeder Test sollte eine konkrete Hypothese bestätigen oder verwerfen. --- **Hypothesen dokumentieren** Eine gute Arbeitsnotiz kann folgendermaßen aufgebaut sein: **Hypothese** DNS-Auflösung ist fehlerhaft. **Test** Interne und externe Namensauflösung mit dem vorgesehenen DNS-Server geprüft. **Ergebnis** Name wird korrekt aufgelöst. **Schlussfolgerung** Hypothese verworfen. Dadurch muss die nächste bearbeitende Person denselben Test nicht wiederholen. --- **Nur kontrollierte Maßnahmen durchführen** Während der Diagnose sollten nicht mehrere Änderungen gleichzeitig vorgenommen werden. Ungeeignet: - DNS ändern - Firewall-Regel anpassen - Dienst neu starten - Zertifikat erneuern - Server neu starten Wenn der Service anschließend funktioniert, ist nicht erkennbar, welche Maßnahme wirksam war. Besser: 1. Maßnahme planen 2. Risiko bewerten 3. Maßnahme durchführen 4. Ergebnis prüfen 5. dokumentieren 6. erst danach nächsten Schritt festlegen Produktive Änderungen müssen entsprechend den Regeln des Change Enablement durchgeführt werden. --- **Neustarts bewusst einsetzen** Ein Neustart kann ein sinnvoller Workaround sein. Er darf jedoch nicht reflexartig verwendet werden. Vorher sollte geprüft werden: - Gehen flüchtige Diagnoseinformationen verloren? - Werden Benutzer oder andere Services unterbrochen? - Besteht Datenverlustrisiko? - Ist eine Genehmigung erforderlich? - Gibt es eine weniger eingreifende Maßnahme? - Kann der Fehler nach dem Neustart weiterhin analysiert werden? ... *(Fortsetzung wegen Nachrichtenlängenlimit erforderlich)* # 3.7 Ownership, hierarchische Eskalation und Major Incidents (Teil 1/2) > **Kurz erklärt** > > Jeder Incident muss jederzeit einen eindeutig verantwortlichen Bearbeiter oder eine verantwortliche Gruppe besitzen. > > ITIL bezeichnet dies als **Ownership**. > > Ownership bedeutet nicht zwingend, dass diese Person den Fehler selbst behebt. Sie trägt jedoch die Verantwortung dafür, dass der Incident aktiv verfolgt, koordiniert und bis zum Abschluss begleitet wird. --- **Was bedeutet Ownership?** Ownership beantwortet die Frage: > **Wer kümmert sich aktuell um diesen Incident?** Der Owner sorgt dafür, dass: - der Incident aktiv bearbeitet wird, - keine unnötigen Wartezeiten entstehen, - Eskalationen rechtzeitig erfolgen, - Benutzer informiert werden, - der nächste Schritt bekannt ist, - und der Vorgang sauber abgeschlossen wird. Ownership bleibt bestehen – auch wenn andere Teams beteiligt werden. --- **Ownership ist nicht gleich Bearbeitung** Ein häufiger Irrtum: > Wer gerade technisch arbeitet, ist automatisch für den gesamten Incident verantwortlich. Das stimmt nicht. Beispiel: Der Service Desk erstellt ein Ticket und eskaliert es an das Netzwerkteam. Während das Netzwerkteam analysiert, kann der Service Desk weiterhin Owner bleiben und: - Rückfragen koordinieren, - den Benutzer informieren, - Fortschritte überwachen, - Zielzeiten prüfen, - und notwendige Eskalationen auslösen. Der technische Bearbeiter führt also eine konkrete Aufgabe aus. Der Owner sorgt dafür, dass der Incident insgesamt gesteuert wird. --- **Zuständigkeit, Bearbeitung und Ownership unterscheiden** | Begriff | Bedeutung | |---|---| | **Ownership** | Verantwortung für den gesamten Incident bis zum Abschluss | | **Bearbeitung** | Durchführung aktueller technischer oder organisatorischer Maßnahmen | | **Zuständigkeit** | fachliche Verantwortung für einen bestimmten Service, Bereich oder eine Komponente | | **Kommunikationsverantwortung** | Verantwortung für Statusmeldungen an Benutzer und Stakeholder | | **Entscheidungsverantwortung** | Befugnis, Prioritäten, Ressourcen oder Vorgehen festzulegen | Mehrere Personen oder Teams können gleichzeitig an einem Incident arbeiten. Der Owner sollte jedoch eindeutig festgelegt sein. --- **Warum Ownership wichtig ist** Ohne klaren Owner entstehen häufig: - doppelte Arbeiten, - lange Wartezeiten, - vergessene Tickets, - fehlende Kommunikation, - unklare Verantwortlichkeiten, - Ticket-Pingpong, - verspätete Eskalationen, - und unklare Abschlüsse. Typische Aussage: > Ich dachte, das andere Team kümmert sich darum. Genau solche Situationen soll Ownership verhindern. --- **Aufgaben des Owners** Der Owner überwacht den gesamten Incident. Typische Aufgaben: - Ticket kontrollieren, - Bearbeitung verfolgen, - Priorität prüfen, - Eskalationen auslösen, - Benutzer informieren, - Rückmeldungen koordinieren, - beteiligte Teams abstimmen, - Zielzeiten überwachen, - Workaround oder Lösung nachverfolgen, - Abschluss prüfen. Der Owner muss nicht jede technische Aufgabe selbst durchführen. Er muss aber sicherstellen, dass der Incident nicht stehen bleibt. --- **Ownership während einer funktionalen Eskalation** Auch nach einer funktionalen Eskalation bleibt Ownership bestehen. Beispiel: Benutzer ↓ Service Desk (Owner) ↓ Netzwerkteam ↓ Hersteller Das Netzwerkteam untersucht den Fehler. Der Service Desk sorgt weiterhin dafür, dass: - Statusmeldungen erfolgen, - der Benutzer informiert wird, - Fristen eingehalten werden, - offene Rückfragen geklärt werden, - und der Vorgang bis zur Wiederherstellung verfolgt wird. Eine Eskalation bedeutet also nicht automatisch, dass die Gesamtverantwortung verschwindet. --- **Ownership übertragen** In manchen Organisationen kann Ownership wechseln. Beispiele: - Service Desk → Netzwerkteam - Netzwerkteam → Incident Manager - Incident Manager → Major Incident Manager - Service Desk → Produktteam - internes Team → externer Provider mit interner Koordination Dabei sollte immer dokumentiert werden: - Zeitpunkt, - bisheriger Owner, - neuer Owner, - Grund der Übergabe, - aktueller Status, - nächster Schritt, - und Kommunikationsverantwortung. Eine Übergabe ist nur dann sinnvoll, wenn die neue Verantwortung eindeutig akzeptiert wurde. --- **Ein Ticket darf niemals besitzerlos sein** Ein Incident ohne Owner ist eines der größten Risiken im Support. Jeder Incident sollte jederzeit erkennen lassen: - Wer ist verantwortlich? - Wer arbeitet aktuell? - Wer informiert den Benutzer? - Wer entscheidet über Eskalationen? - Wer verfolgt Zielzeiten? - Wer prüft die Wiederherstellung? - Wer schließt den Vorgang ab? > **Merke** > > Ein zugewiesenes Ticket ist nicht automatisch ein aktiv gesteuerter Incident. --- **Funktionale und hierarchische Eskalation unterscheiden** Diese beiden Begriffe werden häufig verwechselt. | Funktionale Eskalation | Hierarchische Eskalation | |---|---| | fehlendes Fachwissen oder fehlende Berechtigung | Management-Unterstützung oder Entscheidung erforderlich | | Spezialisten notwendig | Priorisierung, Ressourcen oder Risikoentscheidung notwendig | | technischer Fokus | organisatorischer oder geschäftlicher Fokus | | Beispiel: Netzwerkteam einbinden | Beispiel: Service Owner oder Management informieren | | Ziel: richtige Fähigkeit einbinden | Ziel: Hindernisse, Risiken oder Entscheidungen klären | --- **Funktionale Eskalation** Die funktionale Eskalation wurde bereits in **3.6 Erstdiagnose, Lösung und funktionale Eskalation** behandelt. Beispiele: - Service Desk → Netzwerkteam - Service Desk → Serverteam - Service Desk → Datenbankteam - Service Desk → Cloud-Team - internes Team → Hersteller oder Lieferant Ziel: Die richtigen Spezialisten bearbeiten den Incident. Eine funktionale Eskalation ist keine Schuldzuweisung. Sie bedeutet nur, dass zusätzliche Fähigkeiten, Werkzeuge oder Berechtigungen benötigt werden. --- **Hierarchische Eskalation** Bei einer hierarchischen Eskalation wird nicht primär weiteres Fachwissen benötigt. Benötigt werden beispielsweise: - Entscheidungen, - Ressourcen, - Priorisierung, - Budget, - Management-Unterstützung, - Freigaben, - Konfliktlösung, - oder Kommunikation auf höherer Ebene. Beispiele: - SLA wird voraussichtlich verletzt. - Mehrere Fachbereiche sind betroffen. - Management muss informiert werden. - Ein externer Kunde eskaliert. - Ein Lieferant reagiert nicht. - Zusätzliche Ressourcen werden benötigt. - Ein Risiko kann nicht auf operativer Ebene entschieden werden. - Erheblicher Imageschaden ist möglich. --- **Wann sollte eskaliert werden?** Nicht erst, wenn: - ein SLA bereits verletzt wurde, - der Benutzer mehrfach angerufen hat, - Management sich beschwert, - oder ein Incident längere Zeit unbeachtet blieb. Sondern bereits dann, wenn erkennbar wird: - ein Ziel wird wahrscheinlich verfehlt, - weitere Unterstützung wird benötigt, - Risiken steigen, - Ressourcen nicht ausreichen, - Entscheidungen fehlen, - die Kommunikation nicht mehr ausreicht, - oder der Incident eine besondere geschäftliche Bedeutung bekommt. > **Merke** > > Gute Eskalation ist rechtzeitig, begründet und handlungsorientiert. --- **Eskalation bedeutet keine Schuld** Eine Eskalation ist keine Kritik an einzelnen Mitarbeitern. Sie dient dazu: - Hindernisse zu beseitigen, - Entscheidungen schneller zu treffen, - zusätzliche Ressourcen bereitzustellen, - Risiken sichtbar zu machen, - Kommunikation zu verbessern, - und den Service schneller wiederherzustellen. Ungeeignet: > Wir eskalieren, weil das Team es nicht schafft. Besser: > Wir eskalieren, weil die Zielzeit gefährdet ist und zusätzliche Entscheidungskompetenz benötigt wird. --- **Kommunikationseskalation** Manchmal funktioniert die technische Bearbeitung, aber die Kommunikation reicht nicht aus. Beispiele: - Benutzer erhält keine Rückmeldung. - Management verlangt Statusberichte. - Mehrere Standorte müssen informiert werden. - Es gibt widersprüchliche Aussagen. - Ein Kunde benötigt eine abgestimmte externe Meldung. - Der Service Desk besitzt keine freigegebene Kommunikationslinie. Auch hierfür kann eine Eskalation notwendig sein. Die technische Lösung und die Kommunikation müssen beide gesteuert werden. --- **Major Incident** Ein **Major Incident** ist ein besonders schwerwiegender Incident. Er besitzt normalerweise: - hohe Auswirkungen, - hohe Dringlichkeit, - viele betroffene Benutzer, - kritische betroffene Services, - erhebliche geschäftliche Folgen, - erhöhten Kommunikationsbedarf, - oder besondere Risiken. ITIL schreibt keine universelle feste Definition vor. Jede Organisation muss eigene Kriterien festlegen. --- **Mögliche Kriterien für einen Major Incident** Beispiele: - gesamte Produktion steht, - mehrere Standorte sind betroffen, - ein geschäftskritischer Service ist ausgefallen, - zentrale Anmeldung funktioniert nicht, - kritische Cloud-Dienste sind nicht verfügbar, - ein Sicherheitsvorfall wird vermutet, - externer Kundenimpact ist erheblich, - keine geeignete Zwischenlösung ist verfügbar, - gesetzliche oder vertragliche Fristen sind gefährdet, - Management- oder Krisenkommunikation ist notwendig. Die Kriterien sollten dokumentiert und regelmäßig überprüft werden. --- **Major Incident ist nicht automatisch P1** Viele Organisationen setzen: > P1 = Major Incident Dies ist jedoch keine allgemeine ITIL-Vorgabe. Ein P1-Incident kann ein Major Incident sein. Er muss es aber nicht in jeder Organisation automatisch sein. | P1 | Major Incident | |---|---| | beschreibt häufig die höchste operative Priorität | beschreibt einen besonders schwerwiegenden Incident mit besonderer Koordination | | steuert Zielzeiten und Bearbeitungsreihenfolge | aktiviert zusätzliche Rollen, Kommunikation und Steuerung | | kann durch normale Supportstruktur bearbeitet werden | benötigt häufig besondere Koordination | | wird meist aus Auswirkung und Dringlichkeit bestimmt | kann zusätzliche Kriterien enthalten | > **Merke** > > Priorität und Major-Incident-Status sollten bewusst unterschieden oder eindeutig gemeinsam definiert werden. --- **Ziele eines Major-Incident-Verfahrens** Bei normalen Incidents liegt der Fokus häufig auf der technischen Wiederherstellung. Bei Major Incidents kommen zusätzliche Aufgaben hinzu: - Koordination mehrerer Teams, - schnelle Entscheidungsfindung, - klare Kommunikation, - Priorisierung von Ressourcen, - Management-Unterstützung, - Lieferantensteuerung, - Risikoüberwachung, - Dokumentation unter Zeitdruck, - und spätere Nachbereitung. Das Ziel bleibt die Wiederherstellung des Services. Der Weg dorthin benötigt jedoch mehr Steuerung. --- **Major Incident Manager** Viele Organisationen benennen für Major Incidents einen eigenen **Major Incident Manager**. Diese Person repariert normalerweise nichts selbst. Typische Aufgaben: - Teams koordinieren, - Status sammeln, - Entscheidungen vorbereiten, - Kommunikationsfreigaben abstimmen, - Prioritäten überwachen, - Eskalationen auslösen, - War Room steuern, - Statusintervalle einhalten, - und die Nachbereitung vorbereiten. Der Major Incident Manager sorgt dafür, dass Spezialisten arbeiten können, ohne die Gesamtkoordination nebenbei leisten zu müssen. --- **Typischer Ablauf eines Major Incidents** Incident erkannt ↓ erste Bewertung ↓ Major-Incident-Kriterien prüfen ↓ Major Incident bestätigen oder ablehnen ↓ Owner und Major Incident Manager festlegen ↓ Fachteams und Lieferanten einbinden ↓ Kommunikation starten ↓ Workaround oder Wiederherstellung umsetzen ↓ Service stabilisieren ↓ Abschluss und Nachbereitung Nicht jede Organisation verwendet exakt diesen Ablauf. Entscheidend ist eine klare Koordination. --- **Sofortmaßnahmen bei Major Incidents** Zu Beginn sollte schnell geklärt werden: - Was ist betroffen? - Welche Services sind betroffen? - Welche Standorte sind betroffen? - Welche Benutzer oder Kunden sind betroffen? - Welche geschäftlichen Auswirkungen bestehen? - Seit wann besteht die Störung? - Gibt es einen sicheren Workaround? - Welche Teams werden benötigt? - Gibt es Hinweise auf einen Sicherheitsvorfall? - Wer kommuniziert offiziell? - Wann erfolgt die nächste Statusmeldung? Erst danach beginnt die tiefere technische Analyse. --- **Rollen bei Major Incidents** Typische Rollen können sein: - Service Desk, - Incident Manager, - Major Incident Manager, - technische Spezialisten, - Service Owner, - Kommunikationsverantwortliche, - Management, - Informationssicherheit, - Lieferanten, - Fachbereich, - Problem Manager. Nicht jede Organisation benötigt alle Rollen. Wichtig ist, dass Zuständigkeiten und Entscheidungswege bekannt sind. --- **War Room** Bei kritischen Incidents wird häufig ein gemeinsamer Kommunikationskanal eingerichtet. Beispiele: - Telefonkonferenz, - Videokonferenz, - Microsoft Teams, - Slack, - spezieller Incident-Kanal, - Statusboard. Vorteile: - schnellere Abstimmung, - weniger Rückfragen, - keine parallelen Einzelgespräche, - gemeinsame Faktenlage, - bessere Koordination. Ein War Room benötigt klare Regeln. Sonst entsteht schnell Unübersichtlichkeit. --- **Regeln im War Room** Sinnvolle Regeln: - eine Person koordiniert, - Fakten werden von Vermutungen getrennt, - Maßnahmen werden vor Ausführung abgestimmt, - Ergebnisse werden dokumentiert, - Kommunikation nach außen erfolgt abgestimmt, - Nebenunterhaltungen werden begrenzt, - Entscheidungen werden festgehalten, - nächste Schritte werden eindeutig zugewiesen. Ungeeignet: > Alle diskutieren gleichzeitig technische Vermutungen ohne Dokumentation. Besser: > Hypothesen werden gesammelt, priorisiert, getestet und mit Ergebnis dokumentiert. --- **Kommunikation wird wichtiger** Je größer der Incident, desto wichtiger wird regelmäßige Kommunikation. Stakeholder möchten wissen: - Was ist passiert? - Welche Auswirkungen bestehen? - Was wird aktuell getan? - Gibt es einen Workaround? - Was sollen Benutzer tun oder nicht tun? - Wann gibt es neue Informationen? Auch wenn noch keine Lösung vorliegt, ist eine Statusmeldung sinnvoll. Beispiel: > Die Ursache ist noch nicht bestätigt. Netzwerk- und Identitätsdienste werden geprüft. Ein sicherer Workaround ist derzeit nicht verfügbar. Die nächste Statusmeldung erfolgt um 11:30 Uhr. --- **Statusintervalle** Für kritische Incidents sollten Statusintervalle festgelegt werden. Beispiel: - alle 30 Minuten bei Major Incident, - alle 60 Minuten bei hoher Priorität, - nach wesentlichen Änderungen bei normaler Priorität. Die konkreten Zeiten legt die Organisation selbst fest. Nicht geeignet: > Wir melden uns, wenn alles wieder funktioniert. Besser: > Die nächste Statusmeldung erfolgt spätestens um 10:30 Uhr, auch wenn bis dahin noch keine vollständige Lösung vorliegt. --- **Single Point of Communication** Bei großen Incidents sollte möglichst eine abgestimmte Kommunikationsquelle verwendet werden. Beispiele: - Incident Manager, - Kommunikationsverantwortlicher, - Statusseite, - Service Desk mit freigegebenem Text, - zentrale E-Mail oder Portalnachricht. Dadurch werden widersprüchliche Aussagen vermieden. Technische Detaildiskussionen gehören nicht ungefiltert in Benutzerkommunikation. --- **Stakeholder zielgruppengerecht informieren** | Zielgruppe | Benötigte Informationen | |---|---| | **Benutzer** | Auswirkungen, Workaround, nächste Statusmeldung | | **Service Desk** | freigegebene Formulierung, bekannte Symptome, Ticketverknüpfung | | **technische Teams** | Logs, Hypothesen, Messergebnisse, Maßnahmen | | **Management** | geschäftliche Auswirkungen, Risiken, erwartete Entscheidungen | | **Kunden** | Serviceverfügbarkeit, Einschränkungen, nächstes Update | | **Lieferanten** | technische Nachweise, Versionen, Priorität, gewünschte Unterstützung | | **Informationssicherheit** | Sicherheitsbezug, Beweise, Risiko, Schutzmaßnahmen | Nicht jeder Empfänger benötigt dieselbe Detailtiefe. --- **Ressourcen koordinieren** Bei Major Incidents arbeiten oft mehrere Teams gleichzeitig. Der Major Incident Manager oder Incident Coordinator achtet darauf, dass: - Aufgaben verteilt werden, - Doppelarbeit vermieden wird, - Ergebnisse zusammengeführt werden, - blockierende Entscheidungen eskaliert werden, - Lieferanten eingebunden werden, - und niemand ohne Abstimmung riskante Änderungen durchführt. --- **Dokumentation während eines Major Incidents** Auch unter Zeitdruck muss dokumentiert werden. Mindestens festhalten: - Zeitpunkt, - Beobachtung, - Maßnahme, - Ergebnis, - Entscheidung, - Verantwortlicher, - nächster Schritt, - Kommunikationszeitpunkt. Diese Informationen werden später benötigt für: - Review, - Problem Management, - Audits, - Lessons Learned, - und Continual Improvement. --- **Nach der Wiederherstellung** Mit der technischen Wiederherstellung endet die Arbeit häufig noch nicht. Es folgen möglicherweise: - Stabilitätsüberwachung, - Benutzerinformation, - Abschlusskommunikation, - Ursachenanalyse, - Problem Record, - Review, - Verbesserung der Dokumentation, - Monitoring-Anpassung, - Aktualisierung von Runbooks, - und Bewertung der Kommunikation. --- **Major Incident Review** Nach Abschluss sollte geprüft werden: - Was ist passiert? - Wann begann die Störung? - Wann wurde sie erkannt? - Wann wurde eskaliert? - Welche Maßnahmen waren wirksam? - Wo gab es Verzögerungen? - War die Kommunikation ausreichend? - Waren Rollen und Verantwortlichkeiten klar? - Hat der Workaround funktioniert? - Welche Verbesserungen sind notwendig? Ziel ist Lernen, nicht Schuldzuweisung. --- **Lessons Learned** Typische Ergebnisse können sein: - bessere Dokumentation, - neue Checklisten, - Monitoring erweitern, - Alarmgrenzen anpassen, - Runbooks verbessern, - Schulungen durchführen, - Automatisierungen ergänzen, - Serviceabhängigkeiten in der CMDB korrigieren, - Lieferanteneskalation verbessern, - Kommunikationsvorlagen überarbeiten. Lessons Learned haben nur dann Wert, wenn daraus konkrete Maßnahmen entstehen. --- **Problem Management einbeziehen** Ein Major Incident führt häufig zu einem Problem Record. Dadurch kann später untersucht werden: - eigentliche Ursache, - beitragende Faktoren, - bekannte Fehler, - Workaround, - dauerhafte Lösung, - notwendiger Change, - Verbesserungsmaßnahmen. Incident Management stellt den Service wieder her. Problem Management sorgt dafür, dass die Ursache verstanden und zukünftige Wiederholungen möglichst vermieden werden. --- **Typische Fehler** **Fehler 1: Kein eindeutiger Owner** Niemand verfolgt den Incident Ende zu Ende. **Fehler 2: Ownership geht bei Eskalation verloren** Das Ticket wird weitergegeben, aber niemand koordiniert mehr. **Fehler 3: Zu späte Eskalation** Erst nach SLA-Verletzung oder Managementbeschwerde wird reagiert. **Fehler 4: Funktionale und hierarchische Eskalation werden verwechselt** Es wird ein Spezialist benötigt, aber Management informiert – oder umgekehrt. **Fehler 5: Major Incident wird nicht aktiviert** Kriterien sind unklar oder niemand entscheidet. **Fehler 6: Jeder kommuniziert etwas anderes** Es fehlt ein Single Point of Communication. **Fehler 7: Technische Vermutungen werden als Fakten veröffentlicht** Vertrauen geht verloren, wenn Aussagen später korrigiert werden müssen. **Fehler 8: Keine Dokumentation während der Störung** Nachbereitung und Ursachenanalyse werden erschwert. **Fehler 9: War Room ohne Koordination** Viele Personen diskutieren, aber wenige Maßnahmen werden entschieden. **Fehler 10: Nach Wiederherstellung keine Nachbereitung** Die Organisation lernt nicht aus dem Incident. **Fehler 11: Lessons Learned bleiben unverbindlich** Verbesserungen werden beschlossen, aber nicht umgesetzt. **Fehler 12: Problem Management wird nicht gestartet** Die eigentliche Ursache bleibt unbekannt oder unbehandelt. --- **Praxisbeispiel** **08:15 Uhr** Mehrere Standorte melden Ausfälle der zentralen Anmeldung. **08:20 Uhr** Incident wird als Major Incident bewertet. **08:25 Uhr** Major Incident Manager übernimmt die Koordination. **08:30 Uhr** Erste Statusmeldung wird veröffentlicht. **08:40 Uhr** Identity-, Netzwerk- und Cloud-Team arbeiten gemeinsam im War Room. **09:05 Uhr** Ein sicherer Workaround ist verfügbar. **09:40 Uhr** Service ist technisch wiederhergestellt. **10:00 Uhr** Abschlussmeldung wird veröffentlicht. **10:30 Uhr** Review-Termin und Problem Record werden erstellt. --- **Checkliste Ownership** - [ ] Owner eindeutig festgelegt - [ ] Bearbeiter und Owner unterschieden - [ ] Kommunikationsverantwortung geklärt - [ ] Zielzeiten werden überwacht - [ ] nächste Schritte sind dokumentiert - [ ] Eskalationen werden verfolgt - [ ] Abschluss wird geprüft --- **Checkliste Eskalation** - [ ] Eskalationsart korrekt gewählt - [ ] funktionale Eskalation bei fehlendem Fachwissen - [ ] hierarchische Eskalation bei Entscheidungs- oder Ressourcenbedarf - [ ] relevante Informationen vollständig - [ ] richtige Ansprechpartner beteiligt - [ ] Grund der Eskalation dokumentiert - [ ] Benutzerkommunikation geregelt - [ ] Ownership bleibt klar --- **Checkliste Major Incident** - [ ] Major-Incident-Kriterien geprüft - [ ] Major Incident bestätigt oder abgelehnt - [ ] Owner festgelegt - [ ] Major Incident Manager benannt - [ ] War Room oder gemeinsamer Kanal eingerichtet - [ ] beteiligte Teams informiert - [ ] Lieferanten bei Bedarf eingebunden - [ ] Kommunikationsverantwortung festgelegt - [ ] erste Statusmeldung veröffentlicht - [ ] Statusintervalle festgelegt - [ ] Workaround geprüft - [ ] Maßnahmen dokumentiert - [ ] Wiederherstellung bestätigt - [ ] Abschlusskommunikation erfolgt - [ ] Review geplant - [ ] Problem Record erstellt, falls erforderlich --- **Bedeutung für Fachinformatiker für Systemintegration** Auch wenn Fachinformatiker nicht immer selbst Incident Manager sind, sind sie häufig maßgeblich an der technischen Analyse und Wiederherstellung beteiligt. Im Arbeitsalltag bedeutet das: - strukturiert arbeiten, - Ergebnisse sauber dokumentieren, - technische Vermutungen von Fakten trennen, - Änderungen nachvollziehbar durchführen, - rechtzeitig eskalieren, - andere Teams aktiv unterstützen, - und verständlich kommunizieren. Gerade bei größeren Störungen entscheidet oft nicht nur technisches Wissen, sondern auch Zusammenarbeit, Ownership und Koordination über die Dauer des Ausfalls. --- **Zusammenfassung** > Incident übernehmen > ↓ > Owner eindeutig festlegen > ↓ > Bearbeitung koordinieren > ↓ > falls notwendig funktional oder hierarchisch eskalieren > ↓ > Major Incident aktivieren, wenn Kriterien erfüllt sind > ↓ > Rollen, Kommunikation und Statusintervalle festlegen > ↓ > Teams und Lieferanten koordinieren > ↓ > Service wiederherstellen > ↓ > Ergebnis stabilisieren und kommunizieren > ↓ > Review durchführen > ↓ > Erkenntnisse in Problem Management, Knowledge Management und Continual Improvement übernehmen --- **Verwandte Seiten** - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.8 Self-Service, Wissensnutzung und Automatisierung - Problem Management - Knowledge Management - Continual Improvement - Service Level Management - Supplier Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Service Desk - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Service Level Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Rollen, - Eskalationswege, - Major-Incident-Kriterien, - Statusintervalle, - War-Room-Regeln, - Checklisten, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Major-Incident-Definition, - Eskalationsmatrix, - Supportstufenstruktur, - Statusintervallvorgabe, - War-Room-Struktur, - oder konkrete Rollenbesetzung für alle Organisationen vor. Die konkrete Ausgestaltung muss an: - Services, - Risiken, - Service Levels, - Organisation, - Lieferanten, - Kommunikationswege, - Sicherheitsanforderungen, - und Entscheidungsbefugnisse angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 3.7 Ownership, hierarchische Eskalation und Major Incidents (Teil 2/2) **Major-Incident-Prozess** Nach der Einstufung als Major Incident beginnt eine koordinierte Bearbeitung. Ein möglicher Ablauf: Major Incident erkannt │ ▼ Owner bestätigen │ ▼ Major Incident Manager benennen │ ▼ Fachteams koordinieren │ ▼ Stakeholder informieren │ ▼ Workaround oder Wiederherstellung │ ▼ Service stabilisieren │ ▼ Incident schließen │ ▼ Problem Management starten Nicht jede Organisation verwendet exakt diesen Ablauf. Entscheidend ist eine klare Koordination. --- **War Room** Bei kritischen Incidents wird häufig ein gemeinsamer Kommunikationskanal eingerichtet. Beispiele: - Microsoft Teams - Slack - Telefonkonferenz - Videokonferenz Alle beteiligten Teams arbeiten dort gemeinsam. Vorteile: - schnellere Entscheidungen - weniger Rückfragen - keine Informationsverluste - bessere Zusammenarbeit --- **Kommunikationsregeln** Während eines Major Incidents sollte Kommunikation: - regelmäßig erfolgen, - sachlich bleiben, - bestätigte Fakten enthalten, - Vermutungen klar kennzeichnen, - Verantwortlichkeiten nennen, - nächste Schritte erläutern. Ungeeignet: > Wir glauben, dass wahrscheinlich vielleicht die Firewall schuld ist. Besser: > Die Ursache wird aktuell untersucht. Firewall und Netzwerk werden geprüft. Nächste Statusmeldung um 11:30 Uhr. --- **Stakeholder** Nicht jeder benötigt dieselben Informationen. | Stakeholder | Benötigte Informationen | |---|---| | Benutzer | Auswirkungen und Workaround | | Service Desk | aktueller Status | | Management | Geschäftsrisiken | | Kunden | Serviceverfügbarkeit | | Technik | Diagnoseinformationen | | Lieferanten | technische Details | Informationen sollten zielgruppengerecht formuliert werden. --- **Single Point of Communication** Bei großen Incidents sollte möglichst nur eine abgestimmte Kommunikationsquelle verwendet werden. Dadurch werden widersprüchliche Aussagen vermieden. Beispiele: - Statusseite - Incident Manager - Kommunikationsverantwortlicher --- **Ressourcen koordinieren** Nicht jedes Team sollte unabhängig arbeiten. Der Major Incident Manager achtet darauf, dass: - Aufgaben verteilt, - Doppelarbeiten vermieden, - Ergebnisse zusammengeführt, - Abhängigkeiten erkannt, - und nächste Schritte eindeutig zugewiesen werden. --- **Dokumentation** Auch unter Zeitdruck muss dokumentiert werden. Mindestens festhalten: - Zeitpunkt - Maßnahme - Ergebnis - Entscheidung - Verantwortlicher Diese Informationen werden später benötigt für: - Problem Management - Lessons Learned - Audits - Verbesserungen --- **Nach der Wiederherstellung** Mit der Wiederherstellung endet der Major Incident nicht vollständig. Es folgen häufig: - Ursachenanalyse - Review - Verbesserung - Knowledge-Artikel - Monitoring-Anpassungen - Automatisierungen --- **Major Incident Review** Nach Abschluss sollte überprüft werden: - Was ist passiert? - Warum? - Welche Maßnahmen waren erfolgreich? - Wo gab es Verzögerungen? - Welche Verbesserungen sind möglich? Ziel ist Lernen – nicht Schuldzuweisung. --- **Lessons Learned** Typische Ergebnisse: - bessere Dokumentation - neue Checklisten - Monitoring erweitern - Alarmgrenzen anpassen - Runbooks verbessern - Schulungen durchführen - Automatisierungen ergänzen --- **Problem Management einbeziehen** Ein Major Incident endet häufig mit einem neuen Problem Record. Dadurch kann später untersucht werden: - eigentliche Ursache - dauerhafte Lösung - Vermeidung zukünftiger Incidents --- **Häufige Fehler** **Fehler 1** Kein eindeutiger Owner. --- **Fehler 2** Mehrere Teams arbeiten ohne Koordination. --- **Fehler 3** Benutzer erhalten keine Statusinformationen. --- **Fehler 4** Zu späte Eskalation. --- **Fehler 5** Jeder kommuniziert etwas anderes. --- **Fehler 6** Techniker diskutieren Vermutungen als Fakten. --- **Fehler 7** Keine Dokumentation während des Incidents. --- **Fehler 8** Nach Wiederherstellung erfolgt keine Nachbereitung. --- **Fehler 9** Lessons Learned werden nicht umgesetzt. --- **Fehler 10** Problem Management wird nicht gestartet. --- **Praxisbeispiel** **08:15 Uhr** Mehrere Standorte melden Ausfälle. **08:20 Uhr** Major Incident aktiviert. **08:25 Uhr** Incident Manager übernimmt Koordination. **08:30 Uhr** Statusmeldung veröffentlicht. **08:40 Uhr** Netzwerk-, Server- und Cloud-Team arbeiten gemeinsam. **09:05 Uhr** Workaround verfügbar. **09:40 Uhr** Service vollständig wiederhergestellt. **10:30 Uhr** Review-Termin geplant. --- **Checkliste Ownership** - [ ] Owner eindeutig festgelegt - [ ] Verantwortlichkeiten bekannt - [ ] Benutzer informiert - [ ] Eskalationen überwacht - [ ] Ticket aktiv verfolgt --- **Checkliste Eskalation** - [ ] richtige Eskalationsart gewählt - [ ] Fachinformationen vollständig - [ ] richtige Ansprechpartner beteiligt - [ ] Entscheidungen dokumentiert - [ ] Status kommuniziert --- **Checkliste Major Incident** - [ ] Major Incident bestätigt - [ ] Incident Manager benannt - [ ] Kommunikationskanal eingerichtet - [ ] Stakeholder informiert - [ ] Workaround geprüft - [ ] Maßnahmen dokumentiert - [ ] regelmäßige Statusmeldungen - [ ] Wiederherstellung bestätigt - [ ] Review geplant - [ ] Problem Record erstellt, falls erforderlich --- **Bedeutung für Fachinformatiker für Systemintegration** Auch wenn Fachinformatiker nicht die Rolle des Incident Managers übernehmen, sind sie häufig maßgeblich an der technischen Analyse beteiligt. Im Arbeitsalltag bedeutet das: - strukturiert arbeiten, - Ergebnisse dokumentieren, - Änderungen nachvollziehbar durchführen, - sauber kommunizieren, - und andere Teams aktiv unterstützen. Gerade bei größeren Störungen entscheidet oft die Zusammenarbeit über die Dauer des Ausfalls. --- **Zusammenfassung** > Incident übernehmen > ↓ > Owner festlegen > ↓ > Bearbeitung koordinieren > ↓ > falls notwendig funktional oder hierarchisch eskalieren > ↓ > Major Incident aktivieren, wenn Kriterien erfüllt > ↓ > Kommunikation sicherstellen > ↓ > Service wiederherstellen > ↓ > Review durchführen > ↓ > Erkenntnisse in Problem Management und Continual Improvement übernehmen --- **Verwandte Seiten** - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.8 Self-Service, Wissensnutzung und Automatisierung - Problem Management - Knowledge Management - Continual Improvement --- **Quellen** - PeopleCert – ITIL 4 / ITIL 5 Incident Management - PeopleCert – ITIL 4 / ITIL 5 Service Desk - PeopleCert – ITIL Practice Guides - ITIL Service Version 5 **Framework-Stand:** ITIL Version 5 **Fachlicher Stand:** August 2026 # 3.8 Self-Service, Wissensnutzung und Automatisierung (Teil 1/2) > **Kurz erklärt** > > Ziel moderner Serviceorganisationen ist es nicht, möglichst viele Tickets zu bearbeiten, sondern Benutzern schnell und effizient zu helfen. > > ITIL fördert deshalb: > > - Self-Service, > - Wissensmanagement, > - Automatisierung, > - Standardisierung, > - und kontinuierliche Verbesserung. > > Dadurch können viele Anfragen ohne direkten Kontakt zum Service Desk gelöst werden. --- **Was bedeutet Self-Service?** Self-Service ermöglicht Benutzern, bestimmte Aufgaben selbstständig durchzuführen. Beispiele: - Passwort zurücksetzen - Software anfordern - VPN beantragen - Drucker installieren - Status eines Incidents prüfen - Knowledge-Artikel lesen - Standardsoftware herunterladen Dadurch werden Wartezeiten reduziert und der Service Desk entlastet. --- **Ziele des Self-Service** Ein gutes Self-Service-Portal soll: - leicht verständlich sein, - schnell zum Ziel führen, - rund um die Uhr verfügbar sein, - häufige Anfragen automatisieren, - den Service Desk entlasten, - die Benutzerzufriedenheit erhöhen. Der Benutzer soll möglichst keine internen IT-Strukturen kennen müssen. --- **Vorteile** Für Benutzer: - schnelle Hilfe - keine Wartezeit - jederzeit verfügbar - transparente Bearbeitung Für die IT: - weniger Standardtickets - geringere Kosten - mehr Zeit für komplexe Incidents - einheitliche Prozesse --- **Grenzen des Self-Service** Nicht jede Anfrage eignet sich für Self-Service. Beispiele: - komplexe Störungen - Sicherheitsvorfälle - Major Incidents - individuelle Beratung - Sonderfreigaben - komplexe Infrastrukturprobleme In solchen Fällen bleibt der persönliche Support notwendig. --- **Serviceportal** Das Self-Service-Portal bildet häufig den zentralen Einstiegspunkt. Typische Inhalte: - Servicekatalog - Ticketerstellung - Statusabfrage - Knowledge Base - Standardanfragen - Genehmigungen - Downloads - FAQ --- **Servicekatalog** Ein Servicekatalog beschreibt, welche Leistungen die IT anbietet. Beispiele: - Benutzerkonto - E-Mail - VPN - Arbeitsplatz - Notebook - Software - Druckservice - Cloud-Dienste Dadurch erkennen Benutzer schneller, welcher Service betroffen ist. --- **Standard Requests** Viele Service Requests lassen sich standardisieren. Beispiele: - neues Benutzerkonto - Passwort zurücksetzen - Monitor bestellen - Software installieren - Gruppenberechtigung beantragen Diese Requests besitzen häufig: - einen festen Ablauf, - definierte Genehmigungen, - standardisierte Bearbeitung. --- **Wissensmanagement** Wissen sollte dauerhaft verfügbar sein. Nicht nur erfahrene Administratoren sollen Lösungen kennen. Typische Wissensquellen: - Knowledge Base - Runbooks - FAQ - Checklisten - Standardlösungen - Herstellerinformationen --- **Knowledge Base** Eine Knowledge Base enthält wiederverwendbare Lösungen. Beispiele: - VPN funktioniert nicht - Outlook-Profil reparieren - Drucker verbinden - WLAN-Probleme - MFA einrichten - Software installieren Gut gepflegte Knowledge-Artikel erhöhen die Lösungsquote erheblich. --- **Eigenschaften guter Artikel** Ein Artikel sollte: - verständlich sein, - aktuell bleiben, - reproduzierbare Schritte enthalten, - Screenshots verwenden, - Voraussetzungen nennen, - Risiken erklären, - regelmäßig überprüft werden. --- **Zielgruppen unterscheiden** Nicht jeder Artikel richtet sich an dieselben Leser. Mögliche Zielgruppen: - Endbenutzer - Service Desk - Administratoren - Spezialisten Ein Benutzerartikel sollte keine internen Diagnoseschritte enthalten. --- **KCS (Knowledge-Centered Service)** Viele Organisationen orientieren sich an den Prinzipien von **Knowledge-Centered Service (KCS)**. Grundidee: Wissen entsteht während der täglichen Bearbeitung. Nicht erst Wochen später. Typischer Ablauf: Incident lösen │ ▼ Lösung dokumentieren │ ▼ Knowledge Base erweitern │ ▼ Nächster Incident schneller lösbar --- **Wissen aktuell halten** Veraltete Artikel verursachen: - falsche Lösungen - unnötige Tickets - Frustration - Sicherheitsprobleme Knowledge-Artikel sollten regelmäßig überprüft werden. --- **Suche verbessern** Ein gutes Wissenssystem benötigt: - verständliche Titel - Schlagwörter - Kategorien - Synonyme - Suchfunktion Benutzer suchen häufig nicht mit Fachbegriffen. Beispiel: Nicht: > SMTP Authentication Error Sondern: > Outlook kann keine E-Mails senden. --- **Automatisierung** Automatisierung übernimmt wiederkehrende Aufgaben. Beispiele: - Benutzer anlegen - Gruppenmitgliedschaften verwalten - Software verteilen - Passwort zurücksetzen - VM bereitstellen - Zertifikate erneuern - Backups prüfen Dadurch werden Fehler reduziert und Abläufe beschleunigt. --- **Vorteile der Automatisierung** - schneller - reproduzierbar - weniger manuelle Fehler - rund um die Uhr verfügbar - besser skalierbar --- **Risiken** Automatisierung ersetzt keine Kontrolle. Fehlerhafte Automatisierungen können: - falsche Benutzer anlegen, - falsche Berechtigungen vergeben, - Systeme löschen, - Daten verändern, - oder Sicherheitslücken erzeugen. Automatisierungen benötigen daher: - Tests, - Dokumentation, - Monitoring, - Rollback-Möglichkeiten, - Freigaben, - und klare Verantwortlichkeiten. --- **Runbooks** Runbooks beschreiben standardisierte Arbeitsabläufe. Beispiele: - Serverneustart - Backup-Wiederherstellung - Zertifikat erneuern - Benutzer sperren - DNS prüfen Sie sorgen für einheitliche Arbeitsweisen. --- **Merksätze** > Self-Service ersetzt nicht den Service Desk. > Wissen ist nur dann wertvoll, wenn es aktuell bleibt. > Gute Dokumentation spart zukünftige Bearbeitungszeit. > Automatisierung unterstützt Menschen – sie ersetzt keine Verantwortung. > Jede gelöste Störung kann neues Wissen erzeugen. # 3.8 Self-Service, Wissensnutzung und Automatisierung (Teil 2/2) **Runbooks und Standardabläufe** Runbooks beschreiben wiederholbare Arbeitsabläufe. Sie helfen dabei, Aufgaben einheitlich, sicher und nachvollziehbar durchzuführen. Beispiele: - Server kontrolliert neu starten - Backup-Wiederherstellung prüfen - Zertifikat erneuern - Benutzerkonto sperren - DNS-Auflösung prüfen - Dienststatus kontrollieren - Speicherplatz erweitern - Logdateien auswerten Ein gutes Runbook enthält: - Zweck des Ablaufs - Voraussetzungen - benötigte Berechtigungen - einzelne Arbeitsschritte - Prüfpunkte - Risiken - Rollback oder Abbruchkriterien - Dokumentationshinweise --- **Runbook und Knowledge-Artikel unterscheiden** | Runbook | Knowledge-Artikel | |---|---| | richtet sich häufig an IT-Mitarbeiter | richtet sich je nach Inhalt an Benutzer oder IT | | beschreibt interne Arbeitsabläufe | beschreibt Lösungen, Erklärungen oder Anleitungen | | enthält technische Prüfschritte | kann auch einfache Benutzerhilfe enthalten | | benötigt oft Berechtigungen | kann öffentlich im Serviceportal stehen | | dient der Standardisierung | dient der Wiederverwendung von Wissen | Beide Formen unterstützen eine schnellere und einheitlichere Bearbeitung. --- **Standardisierung** Standardisierung bedeutet, wiederkehrende Aufgaben nach einem einheitlichen Muster auszuführen. Beispiele: - einheitlicher Onboarding-Prozess - definierte Softwarepakete - standardisierte Berechtigungsgruppen - festgelegte Namenskonventionen - einheitliche Ticketkategorien - wiederverwendbare Kommunikationsvorlagen - geprüfte Standard-Changes - dokumentierte Wiederherstellungsverfahren Standardisierung reduziert: - Fehler, - Rückfragen, - Sonderfälle, - Bearbeitungszeit, - und Abhängigkeit von Einzelpersonen. --- **Standardisierung ist keine Starrheit** Standardisierung bedeutet nicht, dass jede Situation gleich behandelt werden muss. Sie schafft einen sicheren Normalweg. Abweichungen bleiben möglich, sollten aber bewusst entschieden und dokumentiert werden. Beispiel: Ein Standard-Request für Softwareinstallation kann automatisch laufen. Eine sicherheitskritische Spezialsoftware benötigt dagegen zusätzliche Prüfung und Freigabe. --- **Automatisierung sinnvoll einsetzen** Automatisierung sollte dort eingesetzt werden, wo Aufgaben: - häufig wiederkehren, - klar beschrieben sind, - wenig Interpretationsspielraum besitzen, - sicher überprüfbar sind, - und bei Fehlern kontrolliert zurückgenommen werden können. Gute Kandidaten: - Passwort-Reset - Benutzeranlage - Gruppenmitgliedschaften - Softwarebereitstellung - Ticket-Routing - Statusbenachrichtigungen - Standard-Reports - Zertifikatsprüfung - Speicherplatzwarnungen Weniger geeignet sind Aufgaben mit: - hoher Unsicherheit, - unklarer Datenlage, - hohem Sicherheitsrisiko, - vielen Ausnahmen, - oder notwendiger Einzelfallentscheidung. --- **Automatisierung braucht Kontrolle** Eine Automatisierung ist nur dann hilfreich, wenn sie zuverlässig gesteuert wird. Zu klären ist: - Wer besitzt die Automatisierung? - Wer darf sie ändern? - Wie wird sie getestet? - Wie werden Fehler erkannt? - Wie erfolgt ein Rollback? - Welche Logs werden geschrieben? - Welche Berechtigungen nutzt sie? - Welche Daten werden verarbeitet? - Wie wird Missbrauch verhindert? > **Merke** > > Automatisierung entfernt Arbeit nicht vollständig. Sie verlagert Arbeit in Design, Prüfung, Betrieb und Überwachung. --- **Risiken fehlerhafter Automatisierung** Fehlerhafte Automatisierungen können große Auswirkungen haben. Beispiele: - falsche Benutzer werden angelegt - falsche Berechtigungen werden vergeben - Konten werden versehentlich deaktiviert - Software wird auf falschen Geräten installiert - Daten werden überschrieben - Tickets werden falsch priorisiert - Benachrichtigungen werden nicht versendet - Zertifikate werden falsch erneuert Deshalb benötigen Automatisierungen: - Tests, - Freigaben, - Protokollierung, - Monitoring, - Fehlerbehandlung, - und klare Verantwortlichkeiten. --- **Self-Service und Automatisierung kombinieren** Self-Service wird besonders wirksam, wenn Benutzeranfragen im Hintergrund automatisiert bearbeitet werden. Beispiel: Ein Benutzer beantragt Standardsoftware im Serviceportal. Möglicher Ablauf: Benutzer wählt Software im Portal ↓ Berechtigung und Genehmigung werden geprüft ↓ Softwarepaket wird automatisch zugewiesen ↓ Installation startet auf dem Gerät ↓ Benutzer erhält Statusmeldung ↓ Ticket wird automatisch dokumentiert Dadurch muss der Service Desk nicht jeden Standardschritt manuell durchführen. --- **Genehmigungen einbauen** Nicht jede Anfrage darf sofort automatisiert erfüllt werden. Beispiele für genehmigungspflichtige Requests: - kostenpflichtige Software - erhöhte Berechtigungen - Zugriff auf vertrauliche Daten - externe Freigaben - neue Geräte - Administratorrechte - Cloud-Ressourcen mit Kostenfolge Ein guter Workflow unterscheidet zwischen: - automatisch erfüllbaren Standardanfragen, - Anfragen mit Genehmigung, - und Anfragen mit manueller Prüfung. --- **Self-Service muss benutzerfreundlich sein** Ein Self-Service-Portal bringt wenig, wenn Benutzer es nicht verstehen oder nicht finden. Wichtig sind: - klare Sprache, - gute Suche, - verständliche Kategorien, - einfache Formulare, - kurze Beschreibungen, - sichtbarer Bearbeitungsstatus, - mobile Nutzbarkeit, - und sinnvolle Hilfetexte. Benutzer sollten nicht wissen müssen, welches interne Team zuständig ist. Ungeeignet: > Antrag für AD-Gruppenmitgliedschaft CN=APP-FIN-PRD-RW. Besser: > Zugriff auf Finanzanwendung beantragen. --- **Gute Formulare** Ein Formular sollte genau die Informationen erfassen, die für die Bearbeitung notwendig sind. Beispiele: - betroffener Service - gewünschte Leistung - betroffene Person - gewünschter Zeitpunkt - Begründung - Kostenstelle - benötigte Berechtigung - Genehmiger - betroffene Geräte - Standort Zu viele Pflichtfelder führen dazu, dass Benutzer falsche Angaben machen oder den Service Desk direkt kontaktieren. Zu wenige Pflichtfelder führen zu Rückfragen und Verzögerungen. --- **Status transparent machen** Benutzer sollten erkennen können: - ob die Anfrage eingegangen ist, - wer aktuell zuständig ist, - ob eine Genehmigung fehlt, - welcher nächste Schritt erfolgt, - wann eine Rückmeldung zu erwarten ist, - und ob ein Workaround verfügbar ist. Transparenz reduziert Rückfragen. Beispiel: > Ihre Softwareanfrage wartet aktuell auf Genehmigung durch den Fachbereich. Nach Genehmigung startet die automatische Bereitstellung. --- **Wissensartikel aus Tickets erzeugen** Viele gute Knowledge-Artikel entstehen direkt aus realen Tickets. Nach einer Lösung sollte geprüft werden: - War der Fall wiederholbar? - Wird diese Frage wahrscheinlich erneut auftreten? - Ist die Lösung allgemein nutzbar? - Kann der Service Desk sie künftig selbst anwenden? - Kann ein Benutzer sie selbst durchführen? - Muss ein bestehender Artikel angepasst werden? Nicht jeder Incident benötigt einen neuen Artikel. Aber häufige oder lehrreiche Fälle sollten nicht verloren gehen. --- **Qualität von Knowledge-Artikeln sichern** Knowledge-Artikel sollten regelmäßig geprüft werden. Zu prüfen ist: - Ist der Inhalt noch korrekt? - Stimmen Screenshots und Menüpfade? - Gibt es neue Versionen? - Sind Links noch gültig? - Sind Risiken vollständig beschrieben? - Ist die Zielgruppe passend? - Gibt es Rückmeldungen von Benutzern? - Wird der Artikel tatsächlich gefunden? - Führt der Artikel zu weniger Tickets? Veraltetes Wissen kann schädlicher sein als kein Wissen. --- **Feedback nutzen** Benutzer und Service-Desk-Mitarbeiter sollten Feedback geben können. Beispiele: - Artikel hilfreich oder nicht hilfreich - Suchbegriff führte nicht zum Ergebnis - Schritt unverständlich - Screenshot veraltet - Lösung funktioniert nicht mehr - Formular enthält unklare Felder - Automatisierung hat falschen Status geliefert Dieses Feedback sollte regelmäßig ausgewertet werden. --- **Kennzahlen** Mögliche Kennzahlen für Self-Service, Wissensnutzung und Automatisierung: | Bereich | Mögliche Kennzahl | |---|---| | Self-Service | Anteil der Anfragen über Portal | | Knowledge Base | Artikelaufrufe | | Knowledge Base | hilfreiche Bewertungen | | Service Desk | First Contact Resolution | | Automatisierung | automatisch erfüllte Requests | | Automatisierung | Fehlerquote automatisierter Abläufe | | Service Requests | durchschnittliche Erfüllungszeit | | Benutzererfahrung | Zufriedenheit nach Nutzung | | Qualität | Anzahl veralteter Artikel | | Verbesserung | reduzierte Wiederholungstickets | Kennzahlen sollten nicht nur Menge messen, sondern auch Qualität. --- **Problematische Kennzahlen** Nicht jede Kennzahl führt automatisch zu gutem Verhalten. Beispiel: **Viele Knowledge-Artikel** Kann problematisch sein, wenn viele Artikel veraltet, doppelt oder unverständlich sind. Besser: - hilfreiche Artikel, - aktuelle Artikel, - gute Suchtreffer, - weniger Rückfragen. Beispiel: **Viele automatisierte Tickets** Kann problematisch sein, wenn Automatisierungen Fehler erzeugen oder Benutzer nicht verstehen, was passiert. Besser: - erfolgreiche Automatisierung, - geringe Fehlerquote, - nachvollziehbare Ergebnisse, - klare Rückmeldung an Benutzer. --- **Zusammenspiel mit Incident Management** Self-Service und Knowledge Management unterstützen Incident Management. Beispiele: - Benutzer lösen einfache Störungen selbst. - Service Desk findet schneller bekannte Lösungen. - Workarounds werden einheitlich kommuniziert. - Wiederkehrende Incidents werden sichtbar. - Known Errors können dokumentiert werden. - Automatisierte Diagnosen liefern erste Hinweise. Dadurch kann der Service schneller wiederhergestellt werden. --- **Zusammenspiel mit Service Request Management** Viele Service Requests eignen sich besonders gut für Self-Service und Automatisierung. Beispiele: - Standardsoftware anfordern - Zugriff beantragen - Hardware bestellen - Benutzerkonto erstellen - Verteilerliste anpassen - Passwort zurücksetzen Wichtig ist, dass: - der Service verständlich beschrieben ist, - Genehmigungen klar sind, - Bearbeitungszeiten sichtbar sind, - und die Erfüllung nachvollziehbar dokumentiert wird. --- **Zusammenspiel mit Change Enablement** Automatisierung und Self-Service können Changes auslösen. Beispiele: - neue Berechtigung wird gesetzt - Software wird installiert - Firewall-Regel wird beantragt - Cloud-Ressource wird erstellt - Konfiguration wird angepasst Solche Änderungen müssen entsprechend ihrem Risiko behandelt werden. Nicht jede Automatisierung ist automatisch ein Standard-Change. Die Organisation muss festlegen, welche Abläufe vorab geprüft und freigegeben sind. --- **Zusammenspiel mit Information Security Management** Self-Service und Automatisierung betreffen häufig Berechtigungen und Daten. Deshalb müssen Sicherheitsanforderungen berücksichtigt werden. Beispiele: - starke Authentifizierung - Rollen- und Rechteprüfung - Genehmigungsworkflow - Protokollierung - Zugriff nur nach Bedarf - regelmäßige Rezertifizierung - Schutz sensibler Daten - Missbrauchserkennung Benutzerfreundlichkeit darf nicht dazu führen, dass Sicherheitsregeln umgangen werden. --- **Typische Fehler** **Fehler 1** Self-Service wird nur als Ticketformular verstanden. --- **Fehler 2** Benutzer müssen interne IT-Strukturen kennen. --- **Fehler 3** Knowledge-Artikel sind veraltet. --- **Fehler 4** Artikel sind zu technisch für Endbenutzer. --- **Fehler 5** Automatisierungen werden ohne ausreichende Tests produktiv genutzt. --- **Fehler 6** Automatisierungen besitzen zu viele Berechtigungen. --- **Fehler 7** Fehler in automatisierten Abläufen werden nicht überwacht. --- **Fehler 8** Runbooks existieren, werden aber nicht gepflegt. --- **Fehler 9** Self-Service ersetzt persönliche Hilfe auch dort, wo sie notwendig wäre. --- **Fehler 10** Benutzerfeedback wird nicht ausgewertet. --- **Fehler 11** Genehmigungen sind unklar oder zu langsam. --- **Fehler 12** Wissen bleibt bei Einzelpersonen statt in dokumentierten Systemen. --- **Praxisbeispiel: Passwort-Reset** **Ausgangslage** Viele Benutzer rufen den Service Desk an, weil sie ihr Passwort vergessen haben. **Verbesserung** Ein Self-Service-Passwort-Reset wird eingeführt. **Wichtige Anforderungen** - sichere Identitätsprüfung - MFA-Unterstützung - klare Benutzeranleitung - Protokollierung - Sperrmechanismen gegen Missbrauch - Hilfeweg bei Fehlern **Nutzen** - weniger Standardkontakte - schnellere Hilfe für Benutzer - Service Desk hat mehr Zeit für komplexe Incidents --- **Praxisbeispiel: Softwareanforderung** **Ausgangslage** Software wird per E-Mail angefordert. Informationen fehlen häufig. Genehmigungen sind unklar. **Verbesserung** Ein Serviceportal bietet standardisierte Softwareanfragen. **Ablauf** Software auswählen ↓ Kosten und Lizenz prüfen ↓ Genehmigung einholen ↓ Paket automatisch bereitstellen ↓ Benutzer informieren ↓ Ticket dokumentieren **Nutzen** - weniger Rückfragen - klare Genehmigung - schnellere Bereitstellung - bessere Nachvollziehbarkeit --- **Praxisbeispiel: Knowledge-Artikel aus Incident** **Incident** Mehrere Benutzer melden, dass VPN nach einem Client-Update nicht startet. **Lösung** Der Service Desk findet eine sichere Reparaturmaßnahme. **Folgeaktivität** Ein interner Knowledge-Artikel wird erstellt. Inhalt: - betroffene Version - Symptom - Prüfschritte - Lösung - Abbruchkriterien - Eskalation an Netzwerkteam **Nutzen** Der nächste gleichartige Incident kann schneller gelöst werden. --- **Checkliste Self-Service** - [ ] Leistungen sind verständlich beschrieben - [ ] Benutzer müssen keine internen Teamnamen kennen - [ ] Formulare erfassen die richtigen Informationen - [ ] Status ist für Benutzer sichtbar - [ ] Genehmigungen sind klar geregelt - [ ] Hilfeweg bei Problemen ist vorhanden - [ ] Portal ist leicht auffindbar - [ ] Inhalte werden regelmäßig verbessert --- **Checkliste Knowledge Management** - [ ] Artikel besitzen klare Titel - [ ] Zielgruppe ist definiert - [ ] Schritte sind verständlich - [ ] Voraussetzungen sind genannt - [ ] Risiken sind beschrieben - [ ] Inhalte sind aktuell - [ ] Artikel werden gefunden - [ ] Feedback wird ausgewertet - [ ] veraltete Artikel werden überarbeitet oder entfernt - [ ] Lösungen aus Tickets werden bei Bedarf übernommen --- **Checkliste Automatisierung** - [ ] Ablauf ist standardisiert - [ ] Risiken sind bewertet - [ ] Berechtigungen sind minimal notwendig - [ ] Tests wurden durchgeführt - [ ] Fehler werden protokolliert - [ ] Monitoring ist vorhanden - [ ] Rollback oder Abbruchweg ist definiert - [ ] Verantwortlicher ist benannt - [ ] Änderungen sind dokumentiert - [ ] Benutzer erhalten verständliche Rückmeldungen --- **Bedeutung für Fachinformatiker für Systemintegration** Für Fachinformatiker ist dieses Thema besonders wichtig, weil viele praktische Verbesserungen direkt aus dem technischen Alltag entstehen. Beispiele: - wiederkehrende Fehler dokumentieren, - Standardabläufe als Runbook beschreiben, - einfache Prüfungen automatisieren, - Service Desk mit Wissen unterstützen, - sichere Self-Service-Prozesse vorbereiten, - Berechtigungen sauber modellieren, - und Monitoring für Automatisierungen einrichten. Gute technische Arbeit zeigt sich nicht nur darin, ein einzelnes Problem zu lösen. Sie zeigt sich auch darin, dass derselbe Fehler künftig schneller, sicherer oder automatisch bearbeitet werden kann. --- **Zusammenfassung** > Wiederkehrende Anfragen erkennen > ↓ > geeignete Self-Service-Möglichkeiten schaffen > ↓ > Wissen verständlich dokumentieren > ↓ > Standardabläufe definieren > ↓ > geeignete Schritte automatisieren > ↓ > Risiken, Berechtigungen und Monitoring berücksichtigen > ↓ > Benutzerfeedback auswerten > ↓ > Inhalte und Abläufe kontinuierlich verbessern --- **Merksätze** > Self-Service ersetzt nicht den Service Desk, sondern erweitert die Servicefähigkeit. > Wissen muss auffindbar, verständlich und aktuell sein. > Automatisierung braucht klare Verantwortung. > Ein automatisierter Fehler bleibt ein Fehler. > Jede gelöste Störung kann zukünftiges Wissen erzeugen. > Gute Standardisierung schafft Freiraum für komplexe Aufgaben. --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.4 Tickets vollständig erfassen und kategorisieren - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.7 Ownership, hierarchische Eskalation und Major Incidents - 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk - Knowledge Management - Service Request Management - Change Enablement - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Desk - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Service Request Management - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Change Enablement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Self-Service-Beispiele, - Portalstrukturen, - Knowledge-Artikel-Kriterien, - Runbook-Beispiele, - Automatisierungsregeln, - Checklisten, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Portalstruktur, - Knowledge-Artikel-Vorlage, - Automatisierungsquote, - Runbook-Form, - KCS-Einführung, - oder Self-Service-Pflicht für alle Organisationen vor. Die konkrete Ausgestaltung muss an: - Services, - Benutzergruppen, - Sicherheitsanforderungen, - technische Plattformen, - Genehmigungswege, - Service Levels, - Fähigkeiten, - und organisatorische Verantwortung angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026 # 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk > **Kurz erklärt** > > Kennzahlen helfen dabei, die Arbeit des Service Desks sichtbar, bewertbar und verbesserbar zu machen. > > Sie zeigen jedoch nicht automatisch, ob ein Service wirklich gut ist. > > Entscheidend ist, Kennzahlen richtig zu interpretieren und mit Qualität, Benutzererfahrung und kontinuierlicher Verbesserung zu verbinden. --- **Warum Kennzahlen wichtig sind** Ohne Kennzahlen bleibt die Leistung eines Service Desks schwer bewertbar. Kennzahlen helfen zu erkennen: - wie viele Kontakte eingehen, - welche Themen häufig auftreten, - wie schnell reagiert wird, - wie schnell gelöst wird, - wie zufrieden Benutzer sind, - wo Engpässe entstehen, - welche Services häufig gestört sind, - und wo Verbesserungen notwendig sind. Kennzahlen sollen nicht nur kontrollieren. Sie sollen helfen, bessere Entscheidungen zu treffen. --- **Kennzahlen sind kein Selbstzweck** Eine Kennzahl ist nur dann sinnvoll, wenn klar ist: - was sie misst, - warum sie gemessen wird, - wer sie nutzt, - welche Entscheidung daraus folgt, - und welche Fehlanreize entstehen können. Beispiel: Eine sehr kurze Bearbeitungszeit klingt gut. Sie kann aber problematisch sein, wenn Tickets vorschnell geschlossen werden und Benutzer später erneut Kontakt aufnehmen müssen. > **Merke** > > Eine gute Kennzahl unterstützt bessere Servicequalität. > > Eine schlechte Kennzahl erzeugt falsches Verhalten. --- **Qualität im Service Desk** Qualität bedeutet nicht nur, dass Tickets schnell geschlossen werden. Qualität bedeutet auch: - Anliegen werden korrekt verstanden, - Benutzer erhalten verständliche Rückmeldungen, - Tickets sind vollständig dokumentiert, - Lösungen sind nachvollziehbar, - Eskalationen erfolgen rechtzeitig, - Wiedereröffnungen werden vermieden, - bekannte Lösungen werden genutzt, - und Verbesserungen werden erkannt. Ein Service Desk kann viele Tickets bearbeiten und trotzdem schlechte Qualität liefern. --- **Quantität und Qualität unterscheiden** | Quantität | Qualität | |---|---| | Anzahl der Tickets | Vollständigkeit der Erfassung | | Anzahl geschlossener Vorgänge | tatsächliche Lösung aus Benutzersicht | | durchschnittliche Bearbeitungszeit | Verständlichkeit der Kommunikation | | Anzahl Anrufe | richtige Klassifizierung | | Anzahl Eskalationen | sinnvolle Eskalation mit ausreichendem Kontext | Beide Perspektiven sind wichtig. Nur Mengenkennzahlen reichen nicht aus. --- **Typische Kennzahlen im Service Desk** | Bereich | Mögliche Kennzahl | |---|---| | Kontaktvolumen | Anzahl der Kontakte pro Zeitraum | | Kanäle | Anteil Portal, Telefon, E-Mail, Chat | | Reaktion | Zeit bis zur ersten qualifizierten Rückmeldung | | Lösung | durchschnittliche Lösungszeit | | Wiederherstellung | Zeit bis zur Wiederherstellung des Service | | First Contact Resolution | Anteil beim ersten Kontakt gelöster Anliegen | | Eskalation | Anteil funktional eskalierter Tickets | | Qualität | Anteil vollständig dokumentierter Tickets | | Benutzererfahrung | Zufriedenheit nach Kontakt | | Backlog | Anzahl offener Tickets | | Wiedereröffnung | Anteil wiedergeöffneter Tickets | | Self-Service | Anteil selbst gelöster oder automatisierter Anfragen | | Knowledge | Nutzung und Bewertung von Wissensartikeln | Die konkrete Auswahl hängt von Organisation, Services und Zielsetzung ab. --- **Kontaktvolumen** Das Kontaktvolumen zeigt, wie viele Anfragen, Störungen oder Rückfragen eingehen. Zu betrachten sind: - Anzahl Kontakte pro Tag, Woche oder Monat, - Verteilung nach Kontaktkanal, - Spitzenzeiten, - häufige Services, - häufige Kategorien, - wiederkehrende Themen. Ein hohes Kontaktvolumen bedeutet nicht automatisch schlechte Leistung. Es kann auch bedeuten: - neue Services wurden eingeführt, - Benutzer kennen den Service Desk besser, - Self-Service funktioniert noch nicht, - ein wiederkehrendes Problem erzeugt viele Meldungen, - oder ein Major Incident führt zu vielen Kontakten. --- **Kanäle auswerten** Kontaktkanäle können unterschiedliche Qualität und Kosten verursachen. Beispiele: | Kanal | Typische Stärke | Typisches Risiko | |---|---|---| | Portal | strukturierte Erfassung | Benutzer finden Service nicht | | Telefon | schnelle Klärung | schlechte Dokumentation möglich | | E-Mail | einfach zugänglich | unstrukturierte Angaben | | Chat | schnelle Kurzklärung | komplexe Fälle schwer dokumentierbar | | Self-Service | sofortige Hilfe | ungeeignet bei komplexen Incidents | Die Organisation sollte prüfen, welche Kanäle für welche Anliegen geeignet sind. --- **Zeit bis zur ersten qualifizierten Rückmeldung** Diese Kennzahl misst, wie schnell der Benutzer eine verwertbare Rückmeldung erhält. Eine qualifizierte Rückmeldung ist mehr als: > Ticket wurde erstellt. Besser: > Wir haben den Incident aufgenommen. Betroffen ist der VPN-Zugriff. Erste Prüfungen laufen. Die nächste Rückmeldung erfolgt spätestens um 14:00 Uhr. Diese Kennzahl hilft, gefühlte Untätigkeit zu vermeiden. --- **Lösungszeit und Wiederherstellungszeit unterscheiden** | Kennzahl | Bedeutung | |---|---| | **Lösungszeit** | Zeit bis zur Bearbeitung oder zum Abschluss eines Vorgangs | | **Wiederherstellungszeit** | Zeit bis der betroffene Service wieder nutzbar ist | | **Bearbeitungszeit** | aktive Arbeitszeit am Vorgang | | **Wartezeit** | Zeit, in der auf Benutzer, Lieferanten, Genehmigung oder andere Abhängigkeiten gewartet wird | Diese Werte sollten nicht verwechselt werden. Ein Incident kann technisch wiederhergestellt sein, obwohl die endgültige Ursache noch im Problem Management untersucht wird. --- **First Contact Resolution** Die **First Contact Resolution (FCR)** beschreibt den Anteil der Anliegen, die beim ersten Kontakt ausreichend gelöst werden. Eine hohe FCR kann entstehen durch: - gute Knowledge Base, - geschulte Service-Desk-Mitarbeiter, - klare Standardlösungen, - ausreichende Berechtigungen, - sinnvolle Automatisierung, - gute Self-Service-Angebote. Aber Vorsicht: Eine hohe FCR ist nicht automatisch gut, wenn Tickets voreilig geschlossen werden. Zu prüfen ist deshalb auch: - Wiedereröffnungsquote, - Benutzerzufriedenheit, - Qualität der Dokumentation, - tatsächliche Lösung aus Benutzersicht. --- **SLA-Erfüllung** SLA-Erfüllung zeigt, ob vereinbarte Serviceziele eingehalten wurden. Mögliche SLA-Ziele: - Reaktionszeit, - Wiederherstellungszeit, - Erfüllungszeit für Service Requests, - Verfügbarkeit, - Statusintervalle, - Bearbeitung innerhalb vereinbarter Servicezeiten. Wichtig: SLA-Erfüllung sollte nicht nur formal betrachtet werden. Beispiel: Ein Ticket wurde innerhalb der Zielzeit geschlossen. Wenn der Benutzer danach erneut melden muss, war die Serviceerfahrung trotzdem schlecht. --- **Backlog** Der Backlog zeigt offene Arbeit. Zu betrachten sind: - Anzahl offener Tickets, - Alter offener Tickets, - offene Tickets nach Priorität, - offene Tickets nach Team, - blockierte Tickets, - Tickets mit überschrittener Zielzeit, - wiederholt verschobene Tickets. Ein Backlog ist nicht automatisch schlecht. Problematisch wird er, wenn: - Vorgänge lange unbeachtet bleiben, - Prioritäten nicht mehr gesteuert werden, - Benutzer keine Rückmeldung erhalten, - oder alte Tickets immer wieder verdrängt werden. --- **Wiedereröffnungsquote** Die Wiedereröffnungsquote zeigt, wie oft geschlossene Tickets erneut geöffnet werden. Mögliche Ursachen: - Problem wurde nicht vollständig gelöst, - Benutzer hat Lösung nicht verstanden, - Abschluss erfolgte zu früh, - Workaround wurde als Lösung behandelt, - Ursache bestand weiterhin, - Kommunikation war unklar, - oder ein verwandter Incident wurde falsch zugeordnet. Eine hohe Wiedereröffnungsquote kann auf Qualitätsprobleme hinweisen. --- **Eskalationsquote** Die Eskalationsquote zeigt, wie häufig Tickets an andere Teams weitergegeben werden. Eine hohe Eskalationsquote kann bedeuten: - Service Desk hat zu wenig Wissen, - Knowledge Base ist unzureichend, - Berechtigungen fehlen, - Kategorien sind unklar, - Services sind komplex, - oder Tickets werden korrekt an Spezialisten gegeben. Eine niedrige Eskalationsquote ist nicht automatisch gut. Sie kann auch bedeuten, dass notwendige Eskalationen zu spät erfolgen. --- **Ticketqualität messen** Ticketqualität ist wichtig für Bearbeitung, Übergabe und spätere Auswertung. Zu prüfen ist: - Ist der betroffene Service erfasst? - Ist das Symptom verständlich beschrieben? - Sind Auswirkungen dokumentiert? - Sind Priorität und Begründung nachvollziehbar? - Sind bisherige Maßnahmen dokumentiert? - Sind relevante Anhänge vorhanden? - Ist der Abschluss nachvollziehbar? - Wurde ein Workaround dokumentiert? - Ist eine Folgeaktivität notwendig? Eine gute Ticketdokumentation spart spätere Arbeitszeit. --- **Benutzerzufriedenheit** Benutzerzufriedenheit kann gemessen werden durch: - kurze Umfragen nach Ticketabschluss, - Feedback im Portal, - Service Reviews, - Beschwerden, - Lob, - qualitative Interviews, - wiederkehrende Rückmeldungen. Wichtig ist, nicht nur eine Zahl zu betrachten. Eine Bewertung sollte ergänzt werden durch: - Kommentare, - Ticketinhalt, - Servicekontext, - tatsächliche Lösung, - und Kommunikationsqualität. --- **Customer Satisfaction und Experience** **Customer Satisfaction (CSAT)** misst häufig die Zufriedenheit mit einem konkreten Kontakt. **Experience** betrachtet breiter, wie Benutzer den Service insgesamt erleben. Beispiel: Ein einzelner Service-Desk-Kontakt war freundlich und schnell. Trotzdem kann die Gesamterfahrung schlecht sein, wenn: - das Portal unübersichtlich ist, - dieselbe Störung häufig wiederkehrt, - Genehmigungen lange dauern, - oder Statusinformationen fehlen. --- **Self-Service-Kennzahlen** Mögliche Kennzahlen: - Anzahl Portalaufrufe, - Anteil über Portal erstellter Tickets, - Anteil erfolgreich selbst gelöster Anliegen, - Nutzung bestimmter Knowledge-Artikel, - Abbruchquote in Formularen, - Anzahl automatisiert erfüllter Requests, - Zufriedenheit mit Self-Service, - Rückgang bestimmter Standardkontakte. Nicht nur Nutzung zählt. Wichtig ist auch, ob Benutzer tatsächlich zum Ziel kommen. --- **Knowledge-Management-Kennzahlen** Mögliche Kennzahlen: - Artikelaufrufe, - Suchanfragen ohne Treffer, - hilfreiche Bewertungen, - veraltete Artikel, - neu erstellte Artikel, - aktualisierte Artikel, - Artikel, die zur Lösung beigetragen haben, - wiederkehrende Incidents ohne vorhandenen Artikel. Problematisch wäre, nur die Anzahl der Artikel zu messen. Viele schlechte Artikel helfen weniger als wenige gute. --- **Automatisierungskennzahlen** Mögliche Kennzahlen: - Anzahl automatisierter Abläufe, - Anteil erfolgreich automatisierter Requests, - Fehlerquote, - manuelle Nacharbeit, - durchschnittliche Durchlaufzeit, - eingesparte Bearbeitungsschritte, - fehlgeschlagene Automatisierungen, - Rollbacks, - Sicherheitsereignisse durch Automatisierung. Automatisierung muss nicht nur schnell sein. Sie muss sicher, nachvollziehbar und zuverlässig sein. --- **Trendanalyse** Kennzahlen werden besonders wertvoll, wenn sie über längere Zeit betrachtet werden. Beispiele: - VPN-Incidents steigen seit einem Client-Update. - Passwort-Reset-Anfragen sinken nach Einführung von Self-Service. - Drucker-Incidents häufen sich an einem Standort. - Wiedereröffnungen steigen in einer bestimmten Kategorie. - Backlog wächst regelmäßig zum Monatsende. - Eskalationen an ein Team nehmen stark zu. Trends helfen, Ursachen und Verbesserungsmöglichkeiten zu erkennen. --- **Qualitätssicherung im Service Desk** Qualität kann geprüft werden durch: - Ticket-Stichproben, - Gesprächsauswertung, - Review von Eskalationen, - Prüfung von Abschlussnotizen, - Bewertung von Knowledge-Nutzung, - Analyse wiedereröffneter Tickets, - Feedback der Fachgruppen, - Feedback der Benutzer. Ziel ist nicht Bestrafung. Ziel ist Lernen und Verbesserung. --- **Service Reviews** In Service Reviews werden Ergebnisse regelmäßig betrachtet. Mögliche Inhalte: - SLA-Erfüllung, - häufige Incidents, - Benutzerfeedback, - offene Risiken, - Major Incidents, - Verbesserungsmaßnahmen, - Trends, - Qualität der Kommunikation, - Leistung von Lieferanten, - Stand des Backlogs. Service Reviews verbinden operative Daten mit geschäftlicher Bewertung. --- **Dashboards** Dashboards helfen, wichtige Informationen schnell sichtbar zu machen. Ein gutes Dashboard zeigt: - aktuelle Lage, - Trends, - Engpässe, - Zielverletzungen, - Risiken, - und Verbesserungsbedarf. Ein Dashboard sollte nicht mit Kennzahlen überladen werden. Besser wenige relevante Kennzahlen als viele unklare Zahlen. --- **Ampellogik vorsichtig verwenden** Ampeln sind einfach verständlich. Beispiel: | Farbe | Bedeutung | |---|---| | Grün | Ziel erreicht | | Gelb | Ziel gefährdet | | Rot | Ziel verletzt oder Risiko hoch | Risiko: Eine Ampel kann komplexe Situationen zu stark vereinfachen. Deshalb sollten kritische Kennzahlen immer mit Kontext erklärt werden. --- **Fehlanreize vermeiden** Kennzahlen können unerwünschtes Verhalten erzeugen. Beispiele: | Kennzahl | Möglicher Fehlanreiz | |---|---| | viele geschlossene Tickets | Tickets werden zu früh geschlossen | | kurze Lösungszeit | komplexe Fälle werden gemieden | | niedrige Eskalationsquote | Eskalation erfolgt zu spät | | hohe FCR | Fälle werden oberflächlich gelöst | | hohe SLA-Erfüllung | Prioritäten werden manipuliert | | viele Knowledge-Artikel | Qualität wird durch Menge ersetzt | | viele Automatisierungen | Risiken werden unterschätzt | Kennzahlen müssen deshalb regelmäßig kritisch überprüft werden. --- **Kennzahlen gemeinsam interpretieren** Einzelne Kennzahlen können täuschen. Beispiel: - Lösungszeit sinkt, - aber Wiedereröffnungsquote steigt, - und Benutzerzufriedenheit sinkt. Dann ist die scheinbare Verbesserung wahrscheinlich keine echte Qualitätsverbesserung. Besser ist eine kombinierte Betrachtung. Beispiel: - Reaktionszeit, - Lösungszeit, - Wiedereröffnungen, - Benutzerzufriedenheit, - Dokumentationsqualität, - und SLA-Erfüllung. --- **Continual Improvement im Service Desk** Continual Improvement bedeutet, aus Daten, Feedback und Erfahrungen konkrete Verbesserungen abzuleiten. Möglicher Ablauf: Kennzahl oder Feedback erkennen ↓ Ursache oder Muster untersuchen ↓ Verbesserungsidee erfassen ↓ Nutzen und Aufwand bewerten ↓ Maßnahme umsetzen ↓ Wirkung messen ↓ Standard oder Wissen aktualisieren Verbesserung ist damit ein dauerhafter Bestandteil des Service Desk. --- **Improvement Register** Verbesserungsideen sollten nicht verloren gehen. Ein Improvement Register kann enthalten: - Verbesserungsidee, - betroffener Service, - Auslöser, - erwarteter Nutzen, - Aufwand, - Risiko, - Priorität, - Verantwortlicher, - Status, - Ergebnis, - Lessons Learned. Das Werkzeug ist nicht entscheidend. Wichtig ist, dass Verbesserungen nachvollziehbar erfasst und verfolgt werden. --- **Beispiele für Verbesserungen** | Beobachtung | mögliche Verbesserung | |---|---| | viele Passwort-Tickets | Self-Service-Passwort-Reset einführen | | häufige VPN-Probleme | Knowledge-Artikel und Clientprüfung verbessern | | viele Rückfragen bei Requests | Formulare überarbeiten | | hohe Wiedereröffnungsquote | Abschlussprüfung verbessern | | viele Eskalationen an Netzwerkteam | Service Desk mit Runbook unterstützen | | lange Wartezeiten auf Genehmigungen | Genehmigungsworkflow vereinfachen | | wiederkehrende Drucker-Incidents | Problem Management einbinden | | schlechte Suchtreffer | Knowledge Base neu strukturieren | --- **Qualitative Informationen berücksichtigen** Nicht alles Wichtige ist direkt messbar. Wertvoll sind auch: - Kommentare von Benutzern, - Erfahrungen des Service Desks, - Rückmeldungen von Fachgruppen, - Beobachtungen aus Major Incident Reviews, - Hinweise aus Service Reviews, - Beschwerden, - und wiederkehrende Missverständnisse. Zahlen zeigen oft, wo man suchen sollte. Die Ursachen versteht man häufig erst durch qualitative Informationen. --- **Typische Fehler** **Fehler 1** Es werden viele Kennzahlen gesammelt, aber keine Entscheidungen daraus abgeleitet. --- **Fehler 2** Nur Geschwindigkeit wird gemessen, nicht Qualität. --- **Fehler 3** Tickets werden schnell geschlossen, obwohl der Benutzer nicht arbeitsfähig ist. --- **Fehler 4** SLA-Erfüllung wird wichtiger genommen als tatsächliche Serviceerfahrung. --- **Fehler 5** Wiedereröffnungen werden ignoriert. --- **Fehler 6** Kennzahlen werden ohne Kontext verglichen. --- **Fehler 7** Teams werden für Zahlen verantwortlich gemacht, die sie nicht beeinflussen können. --- **Fehler 8** Benutzerfeedback wird gesammelt, aber nicht ausgewertet. --- **Fehler 9** Dashboards zeigen zu viele Werte ohne klare Aussage. --- **Fehler 10** Verbesserungsideen werden nicht verfolgt. --- **Fehler 11** Automatisierungserfolg wird nur an Geschwindigkeit gemessen. --- **Fehler 12** Knowledge Management wird nur nach Anzahl der Artikel bewertet. --- **Praxisbeispiel: Wiedereröffnete Tickets** **Beobachtung** Die Lösungszeit im Service Desk ist gesunken. Gleichzeitig steigt die Wiedereröffnungsquote. **Analyse** Viele Tickets werden geschlossen, nachdem eine Standardantwort versendet wurde. Benutzer bestätigen jedoch nicht, dass das Problem gelöst ist. **Verbesserung** - Abschlusskriterien definieren, - Benutzer-Outcome prüfen, - Abschlussnotiz verbessern, - Knowledge-Artikel überarbeiten, - Stichproben einführen. **Erfolgskontrolle** Nach zwei Monaten sinkt die Wiedereröffnungsquote. Die Benutzerzufriedenheit steigt. --- **Praxisbeispiel: Viele VPN-Incidents** **Beobachtung** VPN-Incidents steigen nach einem Client-Update stark an. **Analyse** Mehrere Tickets enthalten ähnliche Symptome. Ein Teil der Benutzer nutzt eine veraltete Konfiguration. **Verbesserung** - Known Error dokumentieren, - Knowledge-Artikel erstellen, - Clientprüfung automatisieren, - Self-Service-Hinweis im Portal ergänzen, - Problem Management einbinden. **Erfolgskontrolle** VPN-Tickets gehen deutlich zurück. Der Service Desk kann verbleibende Fälle schneller lösen. --- **Praxisbeispiel: Serviceportal wird kaum genutzt** **Beobachtung** Die meisten Anfragen kommen weiterhin per E-Mail. **Analyse** Benutzer finden die richtigen Services im Portal nicht. Formulare enthalten unklare technische Begriffe. **Verbesserung** - Kategorien vereinfachen, - Suchbegriffe ergänzen, - Formulare kürzen, - verständliche Beschreibungen verwenden, - Benutzerkommunikation verbessern. **Erfolgskontrolle** Portalnutzung steigt. Rückfragen pro Request sinken. --- **Checkliste Kennzahlen** - [ ] Zweck der Kennzahl ist klar - [ ] Datenquelle ist bekannt - [ ] Berechnung ist nachvollziehbar - [ ] Zielwert ist definiert - [ ] Fehlanreize wurden geprüft - [ ] Kennzahl wird regelmäßig bewertet - [ ] Maßnahmen werden daraus abgeleitet - [ ] Qualität wird mit betrachtet - [ ] Benutzererfahrung wird berücksichtigt - [ ] Kennzahl wird bei Bedarf angepasst --- **Checkliste Ticketqualität** - [ ] betroffener Service erfasst - [ ] Symptom verständlich beschrieben - [ ] Auswirkung dokumentiert - [ ] Priorität begründet - [ ] Maßnahmen nachvollziehbar dokumentiert - [ ] Eskalationen enthalten genug Kontext - [ ] Workaround dokumentiert - [ ] Lösung oder Ergebnis klar beschrieben - [ ] Benutzer-Outcome geprüft - [ ] Folgeaktivitäten verknüpft --- **Checkliste Continual Improvement** - [ ] Trends und Muster werden erkannt - [ ] Benutzerfeedback wird ausgewertet - [ ] Verbesserungsideen werden erfasst - [ ] Nutzen und Aufwand werden bewertet - [ ] Verantwortliche sind benannt - [ ] Maßnahmen werden umgesetzt - [ ] Wirkung wird gemessen - [ ] Knowledge Base wird aktualisiert - [ ] Runbooks werden angepasst - [ ] Ergebnisse werden kommuniziert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker liefern wichtige Daten für Kennzahlen und Verbesserungen. Sie dokumentieren: - Symptome, - technische Ursachen, - durchgeführte Maßnahmen, - Workarounds, - betroffene Komponenten, - Serviceabhängigkeiten, - und wiederkehrende Muster. Dadurch können spätere Auswertungen überhaupt erst sinnvoll durchgeführt werden. Gute technische Arbeit endet nicht mit der Reparatur. Sie schafft auch verwertbares Wissen für bessere Services. --- **Zusammenfassung** > Service-Desk-Arbeit erfassen > ↓ > sinnvolle Kennzahlen auswählen > ↓ > Qualität und Benutzererfahrung berücksichtigen > ↓ > Trends und Muster erkennen > ↓ > Verbesserungen ableiten > ↓ > Maßnahmen umsetzen > ↓ > Wirkung messen > ↓ > Wissen, Prozesse und Automatisierung verbessern --- **Merksätze** > Nicht alles, was messbar ist, ist automatisch wichtig. > Geschwindigkeit ohne Qualität ist keine gute Serviceleistung. > Eine Kennzahl braucht immer Kontext. > Benutzerzufriedenheit und Serviceergebnis zählen genauso wie Ticketzahlen. > Gute Dokumentation macht Verbesserung erst möglich. > Continual Improvement beginnt oft mit sauber erfassten Tickets. --- **Verwandte Seiten** - 3.1 Der Service Desk als zentraler Kontaktpunkt - 3.4 Tickets vollständig erfassen und kategorisieren - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.8 Self-Service, Wissensnutzung und Automatisierung - Service Level Management - Knowledge Management - Continual Improvement - Measurement and Reporting --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Desk - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Knowledge Management - PeopleCert – ITIL Practice Guide: Measurement and Reporting - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Kennzahlen, - Qualitätskriterien, - Dashboard-Beispiele, - Checklisten, - Praxisbeispiele, - und Verbesserungsansätze sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - KPI-Liste, - Zielquote, - Dashboard-Struktur, - CSAT-Methode, - Ticketqualitätsprüfung, - oder Verbesserungsmatrix für alle Organisationen vor. Die konkrete Ausgestaltung muss an: - Services, - Service Levels, - Benutzergruppen, - Organisation, - Supportmodell, - Werkzeuge, - Datenqualität, - und geschäftliche Ziele angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026