IHK-Vorbereitung · Fachinformatiker Systemintegration
Supportanfragen (Incidents, Service Requests) werden im Ticketsystem nach Komplexität und Fachkompetenz auf drei Level verteilt. Ziel ist es, einfache Fälle schnell zu lösen und spezialisiertes Know-how gezielt einzusetzen.
1st Level Support – Erster Ansprechpartner
Nimmt alle eingehenden Tickets entgegen, klassifiziert und priorisiert sie. Löst Standardprobleme direkt anhand von Lösungsartikeln (Wissensdatenbank / SOPs). Ziel: möglichst hohe Erstlösungsrate (First Call Resolution, FCR).
2nd Level Support – Technischer Spezialist
Übernimmt Tickets, die der 1st Level nicht lösen konnte. Tiefere technische Analyse, Remote-Zugriff, Konfigurationsänderungen. Fachkenntnisse in Netzwerken, Servern, Betriebssystemen oder spezifischer Software.
3rd Level Support – Hersteller / Experte
Hersteller, externe Spezialisten oder interne Entwickler. Behandeln schwerwiegende Bugs, Sicherheitslücken oder systemkritische Fehler, die spezialisiertes Expertenwissen erfordern. Eskalation nur bei hochkomplexen Fällen.
Erfassung
Nutzer meldet Problem per Telefon, E-Mail oder Self-Service-Portal. Ticket wird angelegt mit Datum, Beschreibung, Kategorie.
Klassifizierung & Priorisierung
Kategorie (Incident / Service Request / Problem / Change) und Priorität (Auswirkung × Dringlichkeit) werden festgelegt. SLA-Uhr startet.
Zuweisung & Bearbeitung
Ticket wird dem zuständigen Level oder Team zugewiesen. Bearbeiter dokumentiert alle Schritte im Ticket.
Eskalation (bei Bedarf)
Wenn das aktuelle Level keine Lösung findet oder SLA-Fristen drohen zu reißen, wird das Ticket eskaliert.
Lösung, Dokumentation & Abschluss
Lösung wird dokumentiert und ggf. als Wissensdatenbank-Artikel gespeichert. Nutzer bestätigt, Ticket wird geschlossen.
| Kennzahl | Bedeutung | Typischer Zielwert |
|---|---|---|
| FCR – First Call Resolution | Anteil der Tickets, die beim 1st Level sofort gelöst werden | ≥ 70–80 % |
| MTTR – Mean Time To Resolve | Durchschnittliche Zeit von Ticket-Öffnung bis Schließung | Laut SLA |
| MTBF – Mean Time Between Failures | Durchschn. Zeit zwischen zwei Ausfällen desselben Systems | Möglichst hoch |
| SLA-Einhaltung | Anteil der Tickets, die innerhalb der SLA-Frist gelöst wurden | ≥ 95 % |
| Ticket-Backlog | Offene Tickets zum Stichtag – Indikator für Überlastung | Trend fallend |
Es gibt zwei grundlegend verschiedene Eskalationswege, die in der Prüfung klar voneinander abgegrenzt werden müssen:
Funktionale Eskalation
Fachlich
Ticket wird an ein höheres Support-Level oder ein Fachteam weitergegeben, weil die nötige Fachkompetenz fehlt. Beispiel: 1st Level → 2nd Level.
Hierarchische Eskalation
Managementebene
Problem wird an Vorgesetzte oder Management gemeldet, wenn es kritisch für das Business ist oder SLAs wiederholt gerissen werden. Beispiel: IT-Leitung informieren.
Eine SOP ist eine schriftlich festgelegte, schrittweise Anleitung für einen wiederkehrenden Prozess. Sie stellt sicher, dass Aufgaben immer gleich, fehlerfrei und nachvollziehbar ausgeführt werden – unabhängig davon, welcher Mitarbeiter das Ticket bearbeitet.
Titel und Zweck
Was regelt diese SOP? Für welchen Prozess oder Vorfall gilt sie? (z. B. „SOP: Passwort-Reset AD-Nutzer")
Geltungsbereich & Zuständigkeit
Wer ist verantwortlich? Für welche Systeme, Teams oder Vorfallstypen gilt die SOP?
Voraussetzungen / Vorbedingungen
Welche Zugriffsrechte oder Tools werden benötigt? Was muss vorab geprüft werden?
Schritt-für-Schritt-Anleitung
Nummerierte Schritte, präzise und eindeutig formuliert. Ggf. mit Screenshots oder Entscheidungspunkten.
Eskalationsregeln innerhalb der SOP
Was tun, wenn ein Schritt nicht funktioniert? Wer wird kontaktiert?
Dokumentation & Abschluss
Was wird im Ticket vermerkt? Wie wird der Abschluss bestätigt? Wer pflegt die SOP bei Änderungen?
Ein SLA ist eine vertragliche Vereinbarung zwischen IT-Dienstleister und Auftraggeber, die definierte Serviceziele festlegt. Im Ticketsystem steuern SLAs automatisch die Priorisierung und lösen Eskalationsalarme aus.
| Priorität | Auswirkung (Beispiel) | Reaktionszeit | Lösungszeit |
|---|---|---|---|
| Kritisch P1 | Produktionsausfall, alle Nutzer betroffen | 15 Minuten | 4 Stunden |
| Hoch P2 | Wichtige Funktion eingeschränkt | 1 Stunde | 8 Stunden |
| Mittel P3 | Einzelner Nutzer betroffen, Workaround möglich | 4 Stunden | 3 Werktage |
| Niedrig P4 | Kosmetisches Problem, kein Arbeitsausfall | 1 Werktag | 5 Werktage |
Eine Wissensdatenbank ist ein strukturiertes, durchsuchbares Repositorium für IT-Lösungen, Anleitungen und bekannte Fehler (Known Errors). Sie ist das Herzstück des Wissensmanagements nach ITIL und ermöglicht es dem 1st Level, häufige Probleme ohne Eskalation zu lösen.
Ziel
Wissenstransfer sicherstellen
Lösungen werden einmalig erarbeitet und dauerhaft für das gesamte Team nutzbar gemacht.
Direkter Nutzen
FCR erhöhen
Je besser die Wissensdatenbank, desto mehr Tickets kann der 1st Level selbst lösen – ohne Eskalation.
How-To / Anleitung (SOP-Artikel)
Schrittweise Anleitungen für Standardprozesse, z. B. „VPN einrichten unter Windows 11". Grundlage für die SOPs des 1st Level.
Known Error (bekannter Fehler)
Dokumentierter Fehler mit bekannter Ursache (Root Cause) und ggf. Workaround – auch wenn noch kein permanenter Fix existiert. Wichtiges ITIL-Konzept!
FAQ / Troubleshooting-Guide
Gesammelte häufige Fragen und Diagnoseschritte zu einem System oder einer Anwendung. Hilft beim strukturierten Eingrenzen von Fehlern.
CMDB-Eintrag (Konfigurationsinformation)
Technische Dokumentation eines Configuration Items (CI), z. B. Server-Specs, IP-Adressen, Abhängigkeiten. Teil der ITIL Configuration Management Database.
Das SKMS ist laut ITIL das übergeordnete System, das alle wissensbezogenen Daten und Tools umfasst. Es beinhaltet:
Bekannte ITSM-Tools (Ticketsysteme), die eine Wissensdatenbank integrieren: Jira Service Management, ServiceNow, OTRS, Zammad, Freshdesk.
ITIL (Information Technology Infrastructure Library) ist ein weltweit verbreitetes Rahmenwerk (Best-Practice-Sammlung) für IT-Service-Management (ITSM). Es beschreibt, wie IT-Dienstleistungen geplant, erbracht und verbessert werden sollen – nicht als starres Vorgehensmodell, sondern als Sammlung bewährter Praktiken.
Incident (Störung)
Eine ungeplante Unterbrechung oder Beeinträchtigung eines IT-Services. Ziel: schnellstmögliche Wiederherstellung des Normalbetriebs – auch durch einen Workaround. Die Ursache muss nicht bekannt sein.
Problem
Die (noch) unbekannte Ursache eines oder mehrerer Incidents. Problem Management sucht die Root Cause, um zukünftige Incidents zu verhindern. Solange die Ursache unbekannt ist, heißt es Problem; ist sie bekannt, wird es zum Known Error.
Change (Änderung)
Jede Hinzufügung, Modifikation oder Entfernung von etwas, das einen Service beeinflussen könnte. Change Management steuert, genehmigt und überwacht alle Änderungen, um Risiken zu minimieren.
Service Request
Eine formelle Anfrage eines Nutzers für Standard-Services, die keine Störung sind – z. B. neues Benutzerkonto, Software-Installation, Informationsanfrage. Kein Incident, sondern geplante Leistungserbringung.
SLA – Service Level Agreement
Schriftliche Vereinbarung zwischen IT-Dienstleister und Kunde über Qualität und Verfügbarkeit von Services (Reaktionszeit, Lösungszeit, Verfügbarkeit in %). Verletzungen des SLA können zu Vertragsstrafen führen.
CI – Configuration Item
Alles, was für die Erbringung von IT-Services relevant ist und daher verwaltet werden muss: Server, Software, Netzwerkkomponenten, Dokumentation, Verträge. Alle CIs sind in der CMDB erfasst.
Workaround
Temporäre Lösung, die die Auswirkungen eines Incidents oder Problems reduziert, ohne die eigentliche Ursache zu beheben. Ermöglicht Weiterarbeit bis zur dauerhaften Lösung.
Major Incident
Incident mit sehr hoher Auswirkung (viele Nutzer, kritische Systeme betroffen). Erfordert sofortige hierarchische Eskalation, dediziertes Response-Team und seperate Kommunikation an das Management.
| Praktik / Prozess | Kurzbeschreibung | Prüfungsrelevanz |
|---|---|---|
| Incident Management | Störungen schnell beheben, Normalbetrieb wiederherstellen | Hoch |
| Problem Management | Root Cause finden, Known Errors dokumentieren, zukünftige Incidents verhindern | Hoch |
| Change Management | Änderungen kontrolliert einführen, Risiken bewerten, CAB-Genehmigung | Mittel |
| Service Request Management | Standardanfragen effizient bearbeiten (kein Incident) | Mittel |
| Knowledge Management | Wissen dokumentieren, SKMS & KEDB pflegen | Mittel |
| Configuration Management (CMDB) | Alle CIs erfassen und Beziehungen pflegen | Grundwissen |
| Continual Improvement | KPIs messen, Prozesse laufend verbessern (PDCA-Zyklus) | Grundwissen |
Diese Abgrenzung ist eine der häufigsten Prüfungsfragen!
Incident
Symptom
Drucker druckt nicht. Server nicht erreichbar. → Sofort beheben!
Problem
Ursache
Warum druckt der Drucker nie? Defekter Treiber? → Root Cause suchen.
Change
Änderung
Neuen Druckertreiber ausrollen. Genehmigung einholen, dann umsetzen.
Fortschritt
0 von 7 beantwortet
1. Ein Nutzer kann sich nicht mehr am System anmelden. Der 1st Level Support setzt das Passwort zurück – das Problem ist sofort gelöst. Um welche ITIL-Kategorie handelt es sich?
2. Was ist der Unterschied zwischen einem „Problem" und einem „Known Error" nach ITIL?
3. Welche Art von Eskalation liegt vor, wenn der 1st Level ein Ticket an den 2nd Level weitergibt, weil er das technische Problem nicht lösen kann?
4. Wofür steht die Abkürzung FCR und was misst sie?
5. Ein Nutzer stellt eine formelle Anfrage, einen neuen Laptop zu bekommen. Das ist keine Störung. Wie wird diese Anfrage nach ITIL klassifiziert?
6. Welche drei Schutzbedarfskategorien unterscheidet der BSI IT-Grundschutz bei der Schutzbedarfsanalyse?
7. Was ist eine SOP (Standard Operating Procedure) und welchen Hauptnutzen hat sie im IT-Support?
Lern_Apps
AP2_Lernplan
FISI_Tools
Cherry_Apps
Arcade_Tresor
Magic_Apps