Skip to main content

1.1 Warum professionelles Service Management notwendig ist

Kurz erklärt

Unternehmen und öffentliche Einrichtungen sind heute in hohem Maß von digitalen Produkten und Services abhängig.

Ein funktionierender Server allein erzeugt jedoch noch keinen verlässlichen Service. Erst das abgestimmte Zusammenspiel von Technik, Menschen, Prozessen,Arbeitsweisen, Informationen und externen Partnern ermöglicht stabile und nutzbare IT-Services.

Professionelles Service Management hilft dabei, dieses Zusammenspiel planbar, nachvollziehbar und kontinuierlich verbesserbar zu gestalten.


Vom technischen System zum nutzbaren Service

Fachinformatiker für Systemintegration arbeiten täglich mit technischen Komponenten wie:

  • Servern,
  • Netzwerken,
  • Betriebssystemen,
  • Benutzerkonten,
  • Verzeichnisdiensten,
  • Cloud-Plattformen,
  • Anwendungen,
  • Datenbanken,
  • Backups,
  • Firewalls,
  • und Monitoring-Systemen.

Für Benutzer und UnternehmenOrganisationen ist jedoch normalerweise nicht die einzelne technische Komponente entscheidend.

Sie benötigen einen funktionierenden Service.

Beispiele:

Technische Komponenten Daraus unterstüUnterstützter Service
Domain Controller, DNS, Netzwerk und Benutzerkonto Anmeldung am Arbeitsplatz
Mailserver, Cloud-Plattform,Mailplattform, Identitätsdiensttsdienst, DNS und Internetzugang E-Mail-Kommunikation
Fileserver, Berechtigungen, Netzwerk und Backup zentrale Dateiablage
VPN-Gateway, Firewall, MFA und Benutzerkonto sicherer Fernzugriff
Webserver, Datenbank, Zertifikat und DNS Unternehmensanwendung
Druckserver, Treiber, Netzwerk und Drucker zentraler Druckservice

Ein Service kann aus vielen technischen und organisatorischen Bestandteilen bestehen.

Fällt nur eine dieserwichtige Abhängigkeitenngigkeit aus, kann der gesamte Service für den Benutzer nicht mehr nutzbar sein.

Merke

Benutzer nehmen normalerweise keinen einzelnen Server oder Netzwerkdienst wahr.

Sie nehmen wahr, ob sie ihre Arbeit ausführen können.


Warum technische Kompetenz allein nicht ausreicht

Technisches Fachwissen ist unverzichtbar.

Es hilft unter anderem dabei:

  • Fehler zu analysieren,
  • Systeme zu konfigurieren,
  • Dienste wiederherzustellen,
  • Netzwerke zu betreiben,
  • Sicherheitsmaßnahmen umzusetzen,
  • und technische Ursachen zu beseitigen.ermitteln,
  • und Systeme zuverlässig zu betreiben.

Im laufenden IT-Betrieb müssen zusätzlich organisatorische und servicebezogene Fragen beantwortet werden:

  • Welcher Service ist betroffen?
  • Wer nutztverwendet diesen Service?
  • Welche geschäftlichenBenutzer Auswirkungenoder hatGeschäftsprozesse sind beeinträchtigt?
  • Wie groß sind die Störung?Auswirkungen?
  • Wie dringend ist die Wiederherstellung?
  • Wer istträgt verantwortlich?die Verantwortung?
  • Welche anderenAbhängigkeiten Systeme sind abhängig?bestehen?
  • Wurde kürzlich etwas geäverändert?
  • Wer muss informiert werden?
  • WelcheGibt es eine geeignete Zwischenlösung ist möglich?sung?
  • Was muss dokumentiert werden?
  • MussIst nach der Wiederherstellung eine UrsacheUrsachenanalyse untersucht werden?notwendig?
  • Wie kann eine Wiederholung verhindert werden?

Diese Fragen können nicht allein durch einen technischen Befehl oder ein Administrationswerkzeug beantwortet werden.

Dafür wird eine abgestimmte Arbeitsweise benötigt.


Was professionelles Service Management leistet

Professionelles Service Management schafft einen gemeinsamen Rahmen für die Planung, Bereitstellung, Unterstützung, Steuerung und Verbesserung von Services.

Es unterstützt insbesondere dabei:

  • Services und Verantwortlichkeiten eindeutig zu bestimmen,
  • Anforderungen und Erwartungen zu verstehen,
  • Störungen einheitlich zu erfassen,
  • Arbeit nach Auswirkungvereinbarten und DringlichkeitKriterien zu priorisieren,
  • Änderungen kontrolliert durchzuführen,
  • Informationen zwischen Teams auszutauschen,
  • Abhängigkeiten sichtbar zu machen,
  • Wissen dauerhaft bereitzustellen,
  • Leistung und Qualität zu bewerten,
  • Kosten und Risiken bewusst zu behandeln,berücksichtigen,
  • externe Partner einzubinden,
  • und Verbesserungen systematisch umzusetzen.

ITIL stellt hierfür ein anpassbares Best-Practice-Framework bereit.

Die

ITIL aktuelleVersion ITIL-Generation5 verbindetbetrachtet digitales Produkt- und Service-Management undstärker sollals einezusammenhängende gemeinsameAufgabe. SpracheDadurch fürsollen Teams,Produkt-, PartnerEntwicklungs-, Betriebs-, Support- und weitereServiceteams Beteiligtebesser schaffen.zusammenarbeiten :contentReference[oaicite:0]{index=0}und Entscheidungen stärker an Outcomes und Wert ausrichten.

ITIL-Grundlage

ITIL ist kein starres Regelwerk.

Die Inhalte müssen an Ziele, Größe, Risiken, Fähigkeiten und Arbeitsweise der jeweiligen Organisation angepasst werden.


Service Management ist mehr als ein Ticketsystem

Ein Ticketsystem kann Service Management unterstützen.

Es kann beispielsweise:

  • Meldungen erfassen,
  • Vorgänge kategorisieren,
  • Prioritäten speichern,
  • Zuständigkeiten zuweisen,
  • Bearbeitungsstände anzeigen,
  • Kommunikation dokumentieren,
  • Fristen überwachen,
  • und Auswertungen bereitstellen.

Das Ticketsystem allein sorgt jedoch nicht automatisch für professionelles Service Management.

DafürZusätzlich müssen zusätzlichmuss geklärt sein:

  • Welche Vorgangsarten gibt es?
  • Welche Informationen müssen erfasst werden?
  • Wie werden Vorgänge kategorisiert?
  • Nach welchen Kriterien werden Prioritäten bestimmt?
  • Wer übernimmt welche Aufgabe?
  • Wann wird eskaliert?
  • Wie werden Benutzer informiert?
  • Wann gilt ein Vorgang als gelöst oder abgeschlossen?
  • Welche Informationen werden für spätere Verbesserungen verwendet?

Typischer Fehler

Die Einführung eines Ticketsystems wird mit der Einführung von Service Management gleichgesetzt.

Ein Werkzeug kann eine Arbeitsweise unterstützen, aber keine fehlenden Verantwortlichkeiten, Regeln oder Entscheidungen ersetzen.


Service Management ist auchkeine keineinzelne einzelner ProzessPractice

Professionelles Service Management besteht nicht nur aus Incident Management oder Ticketbearbeitung.

Es verbindet verschiedene Aufgabenbereiche,Management zumPractices Beispiel:und Arbeitsbereiche, beispielsweise:

  • Service Desk,
  • Incident Management,
  • Service Request Management,
  • Problem Management,
  • Change Management,
  • Knowledge Management,
  • Service Configuration Management,
  • IT Asset Management,
  • Monitoring and Event Management,
  • Service Level Management,
  • Supplier Management,
  • Information Security Management,
  • Relationship Management,
  • und Continual Improvement.

Diese BereichePractices greifenkönnen ineinander.innerhalb eines Vorgangs zusammenwirken.

Beispiel:

  1. Das Monitoring erkennt den Ausfall eines Webdienstes.
  2. Ein Incident wird erfasst.
  3. DerBetroffene ServiceBenutzer Deskwerden informiert betroffene Benutzer.informiert.
  4. Die technische Analyse stellt eine fehlerhafte Konfiguration fest.
  5. Eine Zwischenlösung stellt den Service wieder her.
  6. Ein Problem Record wird zurfür die weitere Ursachenanalyse angelegt.
  7. Eine dauerhafte Korrektur wird als Change vorbereitet.geplant und umgesetzt.
  8. Die neue Lösung wird im Wissensmanagement dokumentiert.
  9. Monitoring und ChecklistenArbeitsanweisungen werden verbessert.

Keiner dieser Schritte ersetzt die technische Fehleranalyse.

SieDie sorgenbeteiligten Practices helfen jedoch dafür, dassdabei, die technische Arbeit koordiniert, nachvollziehbar und nachhaltig durchgeführt wird.durchzuführen.


Was ohne gemeinsame Arbeitsweise häufig passiert

Fehlt eine abgestimmte Service-Management-Arbeitsweise, können typische Schwierigkeiten entstehen.

Situation Mögliche Folge
Meldungen erfolgen nur telefonisch oder per Zuruf. Vorgänge gehen verloren oder werden nicht nachvollziehbar dokumentiert.
Jeder Mitarbeiter priorisiert nach eigenem Gefühl. Lautstärke oder persönliche Nähe bestimmen die Reihenfolge statt der tatsächlichen Auswirkung.Reihenfolge.
Verantwortlichkeiten sind unklar. TicketsVorgänge werden weitergereicht oder bleiben unbearbeitet liegen.unbearbeitet.
Änderungen werden nicht dokumentiert. Spätere Störungen lassen sich nur schwer mit früheren Eingriffen verbinden.
Lösungen bleiben im Wissen einzelner Mitarbeiter. Kollegen führen dieselbe Analyse immer wiederwiederholt durch.
Teams betrachten nur ihre eigene Komponente. Die eigentlichetatsächliche Serviceauswirkung wird übersehen.
Benutzer erhalten keine Statusmeldung.Statusinformationen. Unsicherheit und zusätzliche Rückfragen erhöhen den Arbeitsaufwand.
Wiederkehrende StörungenIncidents werden nur einzeln behoben. Die zugrunde liegende Ursache bleibt bestehen.
Kennzahlen betrachten nur Ticketmengen. Der tatsächlicheErgebnisse, Nutzen und die Servicequalität bleiben unklar.
Externe Dienstleister sindwerden nichtzu spät eingebunden. EskalationenEskalation und WiederherstellungenWiederherstellung verzögern sich.

Praxistipp

Wenn mehrere Mitarbeiter denselben Vorgang grundlegend unterschiedlich bearbeiten würden, fehlt möglicherweise eine gemeinsame oder ausreichend dokumentierte Arbeitsweise.


Praxisbeispiel: Der E-Mail-Service ist gestört

Mehrere Benutzer melden, dass sie keine E-Mails senden können.

Eine ausschließlich technische Betrachtung könnte somit folgenden Prüfungen beginnen:

  • MailserverMailplattform prüfen,
  • Warteschlangen kontrollieren,
  • DNSDNS-Auflösung testen,
  • Zertifikate kontrollieren,
  • Identitätsdienst prüfen,
  • Internetverbindung untersuchen.

Diese Prüfungen sind notwendig.

Professionelles Service Management ergänzt jedoch weitere Fragen.

Servicebezogene Einordnung

  • Ist nur das Senden oder auch das Empfangen betroffen?
  • Sind einzelne Benutzer, ein Standort oder dasdie gesamte UnternehmenOrganisation betroffen?
  • Welche Geschäftsbereiche sind besonders abhängig?
  • GibtWelche esServicezeiten eineund vereinbarteVereinbarungen Servicezeit?gelten?
  • Welche Priorität ergibt sich aus Auswirkungden undfestgelegten Dringlichkeit?Kriterien?
  • LiegtHandelt bereitses einesich größereum Störungeinen vor?Major Incident?
  • Wer übernimmt die Koordination?

Kommunikation

  • Welche Benutzer müssen informiert werden?
  • In welchemwelchen AbstandAbständen werden StatusmeldungenStatusinformationen benötigt?
  • Welche alternative Kommunikationsmöglichkeit steht zur Verfügung?
  • Wer kommuniziert gegenübermit Führungskräftenften, Kunden oder Kunden?Partnern?

Technische Bearbeitung

  • Welche Komponenten gehören zum Service?
  • Gab es kürzlich einen Change?
  • Gibt esWelche Monitoring-Meldungen?Meldungen liegen vor?
  • Ist ein externer Provider beteiligt?
  • ExistiertGibt es einen bekannten Fehler oder eine bekanntegeeignete Zwischenlösung?

Nach der Wiederherstellung

  • Wurde die Funktion überprütechnisch geprüft?
  • Wurde die Funktion aus Benutzersicht geprüft?
  • Sind alle Warteschlangen vollständig verarbeitet?
  • WurdeIst die Ursache bereits verstanden?
  • Muss ein Problem Record angelegt werden?
  • Muss ein Wissensartikel erstellt oder ergänzt werden?
  • SindMüssen Monitoring oder Alarmierung anzupassen?angepasst werden?

Hinweis

Ein Major Incident ist ein besonders schwerwiegender Incident.

Die Kriterien, Rollen, Kommunikationswege und Eskalationsverfahren werden von der jeweiligen Organisation festgelegt. Major Incident Management wird hier nicht als eigenständige ITIL Practice behandelt.

Merke

Die technische Wiederherstellung ist ein zentraler Teil der Arbeit.

Professionelles Service Management sorgt dafür, dass dabei Auswirkungen, Kommunikation, Verantwortung, Dokumentation und Verbesserung nichtebenfalls vergessenberücksichtigt werden.


Lokale Optimierung kann dem gesamten Service schaden

Ein einzelnes Team kann seine technische Aufgabe korrekt erfüllen und trotzdem den gesamten Service beeinträchtigen.

Beispiel:

Ein Netzwerkadministrator ersetztverschärft eine Firewall-Regel durch eine technisch strengere Konfiguration.Regel.

Die Änderung verbessert möglicherweisekann die Sicherheit einer einzelnen Komponente.Komponente verbessern.

Wurde jedoch nicht geprüft, welche Anwendungen und Services von der bisherigen Verbindung abhängen, können wichtige Geschäftsprozesse ausfallen.

Eine ganzheitliche Betrachtung berücksichtigt deshalb:

  • technische Funktion,
  • Serviceabhängigkeiten,
  • Benutzeranforderungen,
  • Sicherheitsziele,
  • betriebliche Auswirkungen,
  • Kosten,
  • Risiken,
  • und Erfahrungen der Beteiligten.Beteiligten,
  • und externe Abhängigkeiten.

Die vier Dimensionen

der aktuellen

ITIL Foundationverwendet umfassenvier OrganisationenDimensionen, undum Menschen, Wertströme und Prozesse, Informationen und Technologie sowie Partner und Lieferanten. Sie unterstützen eine ganzheitliche Betrachtung des digitalendigitales Produkt- und Service-Managements.Management :contentReference[oaicite:1]{index=1}ganzheitlich zu betrachten.

DimensionTypische Inhalte
Organisationen und MenschenRollen, Fähigkeiten, Kommunikation, Kultur und Verantwortlichkeiten
Informationen und TechnologieDaten, Anwendungen, Infrastruktur, Wissen und Werkzeuge
Partner und LieferantenHersteller, Provider, Verträge und externe Abhängigkeiten
Wertströme und ProzesseAbläufe, Aktivitäten, Übergaben, Kontrollen und Zusammenarbeit

Keine Dimension sollte dauerhaft isoliert betrachtet werden.

Beispiel:

Eine technisch leistungsfähige Anwendung kann trotzdem scheitern, wenn:

  • Benutzer nicht geschult wurden,
  • Verantwortlichkeiten unklar sind,
  • ein externer Provider nicht rechtzeitig eingebunden wird,
  • oder der Unterstützungsprozess ungeeignet ist.

Merke

Ein Serviceproblem ist nicht automatisch ausschließlich ein Technikproblem.


Gemeinsame Sprache statt Missverständnisse

Unterschiedliche Teams verwenden häufig unterschiedliche Begriffe.

Beispiele:

  • Störung,
  • Fehler,
  • Problem,
  • Anfrage,
  • Auftrag,
  • Änderung,
  • Freigabe,
  • Eskalation,
  • Service,
  • System,
  • Anwendung.

Werden diese Begriffe nicht einheitlich verwendet, können Missverständnisse entstehen.

Beispiel:

Ein Benutzer meldet beispielsweise ein „Problem“.

Im allgemeinen Sprachgebrauch ist das verständlich.

Im Service-Management-Kontext muss jedoch zunächst geprüft werden, ob es sich tatsächlich um:

  • einen Incident,
  • einen Service Request,
  • ein Problem,
  • ein Event,
  • oder einen Change handelt.

handelt.

Eine gemeinsame Sprache erleichtert:

  • eindeutige Kommunikation,
  • passende Zuständigkeiten,
  • vergleichbare Bearbeitung,
  • aussagekräftige Auswertungen,
  • und eine verlässliche Zusammenarbeit zwischen Teams.

ITILWichtig

stellt

Benutzer einemüssen solchenicht gemeinsamezwingend Sprachedie offiziellen ITIL-Begriffe kennen.

Die korrekte fachliche Einordnung ist Aufgabe der zuständigen Service- und strukturelleSupportorganisation.

Grundlage für modernes digitales Produkt- und Service-Management bereit. :contentReference[oaicite:2]{index=2}


Verantwortung muss über einzelne Komponenten hinausgehen

In technischen Umgebungen werden Verantwortlichkeiten häufig nach Komponenten verteilt.

Beispiele:

  • Netzwerkteam,
  • Serverteam,
  • Datenbankteam,
  • Anwendungsteam,
  • Cloud-Team,
  • Informationssicherheit,
  • externer Provider.

Ein Service kann von allen diesen Bereichen gleichzeitig abhängen.

Wenn jedes Team nur prüft, ob die eigene Komponente funktioniert, kann folgendeFolgende Situation entstehen:ist möglich:

Netzwerk funktioniert.
Server funktioniert.
Datenbank funktioniert.
Anwendung funktioniertläuft laut Monitoring.
Der Benutzer kann trotzdem nicht arbeiten.

Service Management ergänzt deshalb die technische Komponentenverantwortung um eine Ende-zu-Ende-Sicht:

  • Funktioniert der Service aus Sicht der Benutzer?
  • Wird das benötigte ErgebnisOutcome erreicht?
  • Sind alle Übergänge und Abhängigkeiten berücksichtigt?
  • Wer koordiniert die Wiederherstellung?
  • Wer trägt Verantwortung für die Servicequalität?
  • Wie wird das Ergebnis überprüft?

Wert entsteht nicht allein durch Bereitstellung

Ein Service erzeugt nicht automatisch Wert, nur weil er technisch bereitgestellt wurde.

Beispiel:

Eine neue VPN-Lösung ist:kann:

  • technisch erreichbar,
  • sicher konfiguriert,
  • vollständigdokumentiert,
  • dokumentiert,
  • leistungsfähig,
  • und hochverfügbar.gbar

sein.

Wenn Benutzer jedoch:

  • die Anmeldung nicht verstehen,
  • keine geeigneten Endgeräte besitzen,
  • regelmäßig durch fehlerhafte MFA-ProzesseAbläufe blockiert werden,
  • oder ihrenotwendige Anwendungen über die Verbindung nicht nutzenverwenden können,

liefertwird derdas Serviceerwartete Outcome möglicherweise nicht das erwartete Ergebnis.erreicht.

ITIL Version 5 betont die gemeinsamebetrachtet Wertschöpfung als Zusammenarbeit zwischen Service Provider, Service Consumer und weiteren Stakeholdern.

Dabei

Bei werdender nebenBewertung Ergebnissenkönnen auchunter anderem berücksichtigt werden:

  • Outcomes,
  • Kosten,
  • Risiken,
  • Erfahrung
  • Erfahrungen,
  • und NachhaltigkeitNachhaltigkeit.
  • berücksichtigt. :contentReference[oaicite:3]{index=3}

Merke

Ein technisch verfügbarer Service ist nicht automatisch ein fürbrauchbarer den Benutzeroder wertvoller Service.


Service Management bedeutet nicht maximale Bürokratie

ITIL schreibt UnternehmenOrganisationen nicht vor, jeden denkbaren Ablauf möglichst umfangreich zu dokumentieren.

Eine Arbeitsweise muss zurzum jeweiligen OrganisationKontext passen.

Ein kleines Unternehmen benötigt möglicherweise:

  • einfache Ticketkategorien,Kategorien,
  • wenige Freigabestufen,
  • klare persönliche Zuständigkeiten,
  • und kompakte Checklisten.

EinEine großere Konzernoder stark regulierte Organisation benötigt möglicherweise:

  • mehrere Supportgruppen,
  • formalisierte Eskalationen,
  • unterschiedliche Service Levels,
  • umfangreiche Compliance-Nachweise,
  • Funktionstrennungen,
  • und koordinierte Lieferantensteuerung.

Grundsatz

So viel Struktur wie nötig, aber nicht mehr Komplexität als sinnvoll.

Eine übermäßig komplizierte Arbeitsweise kann:

  • Bearbeitungen verzögern,
  • unnötige Übergaben erzeugen,
  • Mitarbeiter zu Umgehungslösungen verleiten,fördern,
  • und den eigentlichen Nutzen aus dem Blick verlieren.

Eine zu schwache Arbeitsweise kann dagegen:

  • Risiken erhöhen,
  • Wissen verlieren,
  • ZuständigkeitenVerantwortlichkeiten verschleiern,
  • Änderungen unkontrollierbar machen,
  • und wiederkehrende Fehler begünstigen.

Die Aufgabe besteht darin, ein angemessenes Verhältnis zu finden.


Was professionelles Service Management nicht bedeutet

Professionelles Service Management bedeutet nicht:

  • jede Kleinigkeit zu einem umfangreichen Prozess zu machen,
  • technische Entscheidungen vollständig zu zentralisieren,
  • jede Änderung durch dasselbe Gremium genehmigen zu lassen,
  • jedesjede UnternehmenOrganisation identisch zu organisieren,aufzubauen,
  • ITIL-Begriffe nur auswendig zu lernen,
  • technische Kompetenz durch Prozesse zu ersetzen,
  • oder Benutzerwünschejeden Benutzerwunsch ungeprüft umzusetzen.

Es bedeutet vielmehr:

  • Ziele und Services zu verstehen,
  • VerantwortungVerantwortlichkeiten zu klären,
  • angemessen zu planen,
  • benötigte Informationen verfügbar zu machen,
  • Risiken zu berücksichtigen,
  • Zusammenarbeit zu ermöglichen,
  • Ergebnisse zu überprüfen,
  • und aus ErgebnissenErfahrungen zu lernen.

Bedeutung für Fachinformatiker für Systemintegration

Als Fachinformatiker für Systemintegration bist dusind häufig an mehreren Stellen eines ServicesService beteiligt.

DuZu kannstihren beispielsweise:Aufgaben können gehören:

  • technische Komponenten installieren,
  • Benutzerkonten verwalten,
  • Störungen analysieren,
  • Änderungen umsetzen,
  • Systeme überwachen,
  • Backups prüfen,kontrollieren,
  • Wiederherstellungen durchführen,
  • Dienstleister einbinden,
  • DokumentationDokumentationen erstellen,
  • und Wissen an Kollegen weitergeben.

DabeiService Management hilft Servicedabei, Management,diese deinetechnischen technische ArbeitTätigkeiten in einen größeren Zusammenhang einzuordnen.

Technische Tätigkeit Zusätzliche Service-Management-Frage
Dienst neu starten Ist die Ursache bekannt und wurdeWurde die Wiederherstellung überprüft?geprüft und ist eine weitere Ursachenanalyse notwendig?
Firewall-Regel ändern Wer ist betroffen, welches Risiko besteht und wie sieht der Rückfallplan aus?
Benutzerkonto entsperren Handelt es sich um einen Incident oder einen standardisierten Service Request?
Server patchen Wie werden Test, Freigabe, Wartungsfenster und Kommunikation organisiert?
Monitoring-Alarm bearbeiten Ist das Event relevant und muss daraus ein Incident entstehen?erfasst werden?
neue Hardware einbauen Müssen Asset- und Konfigurationsinformationen aktualisiert werden?
Fehler dauerhaft beheben Ist einMüssen Problem oderManagement und Change erforderlich?Management einbezogen werden?
Lösung dokumentieren Wer benötigt dieses Wissen und wie wird es auffindbar gemacht?
Backup kontrollierenWurde nur der Sicherungslauf oder auch die Wiederherstellbarkeit geprüft?

Wie ein serviceorientierter Systemintegrator denkt

Ein serviceorientierter Systemintegrator fragt nicht nur:

Welche Komponente ist defekt?

Er fragt zusätzlich:

  • Welcher Service ist beeinträchtigt?
  • Welche Benutzer oder Geschäftsprozesse sind betroffen?
  • Welche Wiederherstellung ist zuerst notwendig?
  • Welche Abhängigkeiten bestehen?
  • Wer muss beteiligt werden?
  • Welche Risiken entstehen durch meine Maßnahme?
  • Wie kann ichder den vorherigenvorherige Zustand wiederherstellen?wiederhergestellt werden?
  • Wie überprüfe ich das Ergebnis?
  • Was muss dokumentiert werden?
  • Was können wir aus diesem Vorgang lernen?

Diese Denkweise verhindert nicht jede Störung.

Sie hilft jedoch dabei, Störungen kontrollierter, schnellernachvollziehbarer und nachhaltiger zu behandeln.


Erste Orientierung in einemeiner neuen UnternehmenOrganisation

Wenn du in einer neuen IT-Abteilung beginnst, solltest du frühzeitig herausfinden:

  • Welche wichtigen Services gibt es?
  • Wer nutztverwendet diese Services?
  • WoGibt befindetes sich dereinen Servicekatalog?
  • Welches Ticketsystem wird verwendet?eingesetzt?
  • Welche Vorgangsarten gibt es?
  • Wie werden Prioritäten bestimmt?
  • Welche Eskalationswege gelten?
  • Wer besitztträgt welche Verantwortung?
  • Welche Änderungen darfst du selbst durchführen?
  • Welche Änderungen benötigen eine Freigabe?
  • Wo befinden sich technische Dokumentationen?
  • Wo wird Wissen gespeichert?
  • Welche Servicezeiten und Vereinbarungen gelten?
  • Welche externen Dienstleister sind beteiligt?
  • Welche kritischen Abhängigkeiten bestehen?
  • Wie werden größereMajor StörungenIncidents koordiniert?
  • Welche Sicherheits- und Notfallverfahren gelten?

Praxistipp

Lerne nicht nur die technische Infrastruktur kennen.

Lerne ebenso,auch, welche Services davon abhängen und wer bei Störungen oder Änderungen beteiligt werden muss.


Anzeichen für fehlendes oder unzureichendes Service Management

Folgende Beobachtungen können darauf hinweisen, dass Arbeitsweisen verbessert werden sollten:

  • TicketsVorgänge enthalten kaum verwertbare Informationen.
  • Prioritäten werden willkürlich oder regelmäßig nachträglich geändert.
  • Benutzer umgehen den Servicevorgesehenen DeskKontaktweg und kontaktierenwenden sich an einzelne Administratoren.
  • Änderungen werden erst nach einer Störung bekannt.
  • Niemand kann dendie VerantwortlichenVerantwortung einesfür Serviceseinen wichtigen Service benennen.
  • Lösungen befinden sich nur in privaten Notizen oder Chatverläufen.
  • Wiederkehrende StörungenIncidents werden immer wieder einzeln behandelt.bearbeitet.
  • Monitoring erzeugt viele Meldungen, aber keine klare Reaktion.
  • Teams weisen sich gegenseitig die Verantwortung zu.
  • Benutzer erhalten widersprüchliche Statusinformationen.
  • Serviceberichte enthalten viele Zahlen, aber kaum Aussagen über Ergebnisse.Outcomes.
  • Nach größerenschwerwiegenden StörungenIncidents werden keine Verbesserungen umgesetzt.

Ein einzelnes Anzeichen beweist noch kein grundsätzliches Organisationsproblem.

Wiederholen sich mehrere dieser Muster, sollte die zugrunde liegende Arbeitsweise untersucht werden.


Entscheidungshilfe: Brauchen wirWird mehr Struktur?Struktur benötigt?

Prüfe folgende Fragen:

  • Gehen Meldungen oder Aufgaben verloren?
  • Werden ähnliche Vorgänge grundlegend unterschiedlich bearbeitet?
  • Sind Verantwortlichkeiten häufig unklar?
  • Werden Änderungen ohne ausreichende Abstimmung durchgeführt?
  • Treten dieselben Störungen regelmäßig erneut auf?
  • Fehlen nachvollziehbare Dokumentationen?
  • Wissen Benutzer nicht, wohin sie sich wenden sollen?
  • Werden kritische Auswirkungen zu spät erkannt?
  • Fehlen zuverlässigeverlässliche Informationen über Abhängigkeiten?
  • Werden Verbesserungen zwar besprochen, aber nicht umgesetzt?

Werden mehrere Fragen mit Ja beantwortet, besteht wahrscheinlich Verbesserungsbedarf.

Die Lösung ist jedoch nicht automatisch ein möglichst umfangreicher Prozess.

Zuerst sollte festgestellt werden:

  1. Welches konkrete Problem besteht?
  2. Welche Auswirkungen verursacht es?
  3. Welche bestehende Arbeitsweise funktioniert bereits?
  4. Welche kleinste sinnvolle Verbesserung ist möglich?
  5. Wie lässt sich derenihre Wirkung überprüfen?

Checkliste für den Arbeitsalltag

Wenn du eine technische Aufgabe erhältst, prüfe zusätzlich:

  • Welcher Service ist betroffen?
  • Wer nutztverwendet oder benötigt diesen Service?
  • Welche Auswirkungen bestehen?
  • Wie dringend ist die Aufgabe?
  • Gibt es bereits einen Vorgang im Ticketsystem?
  • Wer istträgt verantwortlich?die Verantwortung?
  • Welche Abhängigkeiten müssen berücksichtigt werden?
  • Wurde kürzlich etwas geändert?
  • Benötige ich eine Freigabe?
  • Welche Risiken besitzt meine Maßnahme?
  • Gibt es einen Rückfallplan?
  • Wer muss informiert werden?
  • Wie überprüfe ich den technischen Erfolg?
  •  Wie überprüfe ich die Nutzbarkeit des Service?
  • Was muss dokumentiert werden?
  • Muss daraus eine weitere Untersuchung oder Verbesserung entstehen?

Schnellzusammenfassung

Technik

stellt Komponenten und Funktionen bereit.

Service Management

verbindet diese KomponentenTechnik mit Menschen, Arbeitsweisen, Informationen, Partnern und Geschäftszielen.den Zielen der Organisation.

Professionelle IT-Arbeit

entsteht, wenn technische Kompetenz und serviceorientierte Arbeitsweise zusammenwirken.


Grafik vorgesehen

Vom technischen Baustein zum geschäftlichen Ergebnis

Technische Komponenten

digitales Produkt

nutzbarer Service

ErgebnisOutcome für Benutzer und UnternehmenOrganisation

wahrgenommener Wert

Die Grafik soll verdeutlichen, dass technischeTechnische Komponenten bilden die GrundlageGrundlage.

bilden, der

Der eigentliche Nutzen entsteht jedoch ersterst, durchwenn einendaraus funktionierendenein und nutzbarenfunktionierender Service entsteht.

entsteht,

Eineder spätereein interaktivebenötigtes VersionOutcome kann einen typischen Service auswählen lassen und anschließend dessen:

  • technische Komponenten,
  • beteiligte Teams,
  • externe Partner,
  • Benutzer,
  • Risiken,
  • und Abhängigkeiten

anzeigen.unterstützt.


Verwandte Seiten

  • 0.1 Über dieses Buch – Ziel, Arbeitsweise und Qualitätsmaßstab
  • 0.2 So nutzt du dieses Buch
  • 0.3 Kennzeichnungen, Quellen und Versionsstände
  • 0.4 Aktualisierungen, Versionspflege und Korrekturen
  • 1.2 Technik, Produkt, Service und Geschäftsergebnis
  • 1.3 TypischeWert, FolgenNutzen, unstrukturierterKosten IT-Arbeitund Risiken
  • 1.4 ServiceorientierungServicebeziehungen, im Arbeitsalltag
  • 2.1 Was ist ein Service?
  • Incident Management
  • Change Management
  • Continual Improvement
  • FehleranalyseRollen und TroubleshootingServiceangebote

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die grundlegenden Aussagen zu:

zur
    gemeinsamen
  • digitalemWertschöpfung, Produkt-zu den vier Dimensionen, zur Integration von Produkten und Service-Management,
  • Services
  • gemeinsamersowie Wertschöpfung,
  • zur
  • gemeinsamerAusrichtung Sprache,
  • auf
  • ganzheitlicherOutcomes, Betrachtung,
  • Kosten,
  • Zusammenarbeit,
  • Risiken,
  • Zuverlässigkeit,
  • Erfahrung
  • und kontinuierlicherNachhaltigkeit Verbesserung

wurden anhand der genannten offiziellen ITIL- und PeopleCert-Quellen geprüft. :contentReference[oaicite:4]{index=4}

Die dargestellten Praxisbeispiele, ChecklistenChecklisten, Entscheidungshilfen und betrieblichen Hinweise sind zusätzliche, herstellerneutrale Praxisempfehlungen dieses NachschlagewerksNachschlagewerks.

und

Sie stellen keine wörtlichen ITIL-Vorgaben.Definitionen und keine vorgeschriebenen ITIL-Prozesse dar.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026