Gleichgewicht zwischen externem und internem Fokus Der größte Konflikt in allen Phasen des ITSM Lebenszyklus besteht zwischen der Betrachtung der IT

Transkript

1

2 2

3 3

4 Gleichgewicht zwischen externem und internem Fokus Der größte Konflikt in allen Phasen des ITSM Lebenszyklus besteht zwischen der Betrachtung der IT als Gruppe von IT Services (externer Business-View) und der Betrachtung der IT als Gruppe von Technologiekomponenten (interne IT-View). Die Organisation, die den Fokus nur auf die Business Anforderungen legt, ohne darüber nachzudenken wie Sie diese Bereitstellen kann, endet damit, dass sie Versprechen abgibt, die sie nicht halten kann. Die Organisation, die den Fokus nur auf die internen Systeme legt, ohne darüber nachzudenken welchen Service sie damit unterstützen, endet mit teuren Services, die wenig Mehrwert liefern. 4

5 Gleichgewicht zwischen Stabilität und Reaktionsfähigkeit Der Servicebetrieb muss dafür sorgen, dass die IT-Infrastruktur stabil und dem Design entsprechend verfügbar ist. Dem Servicebetrieb muss jedoch auch bewusst sein, dass die Business- und IT- Anforderungen Änderungen unterworfen sind. Viele Änderungen passieren allerdings sehr schnell und manchmal unter enormem Druck. Beispiel: Eine Geschäftseinheit erhält überraschend einen Auftrag, für den zusätzliche IT Services, mehr Kapazität und schnellere Antwortzeiten notwendig sind. Die Fähigkeit, auf diese Art von Änderungen zu reagieren, ohne andere Services zu beeinträchtigen, ist eine große Herausforderung. 5

6 Gleichgewicht zwischen Kosten und Qualität Die Service Operation wird kontinuierlich benötigt, um den Kunden und Anwender IT Service gemäß dem vereinbarten Level bereitzustellen und gleichzeitig die Kosten und die Ressourcenauslastung zu optimieren. Das angestrebte Gleichgewicht zwischen Kosten und Qualität sollte in der Service Strategy und Service Design Phase des Lebenszyklus festgelegt werden. In vielen Organisationen fällt diese Aufgabe jedoch den Service Operation Teams zu von denen viele nicht alle Fakten kennen oder nicht autorisiert sind, diese Entscheidung zu treffen. 6

7 Gleichgewicht zwischen Servicequalität und Servicekosten In der Abbildung oben führt eine Qualitätssteigerung zu einem Anstieg der Servicekosten und umgekehrt. Das Verhältnis ist jedoch nicht immer direkt proportional. Eine Schlüsselrolle im Service Management besteht darin, ein Gleichgewicht zwischen Kosten und Qualität (dargestellt zwischen den gestrichelten Linien in Abbildung oben) zu finden. Es gibt keine Branchennorm für diesen Bereich, da jeder Service abhängig von der Art des Service und der Art des Business-Zieles einen anderen Optimierungsbereich aufweist. 7

8 Gleichgewicht zwischen reaktiv und proaktiv Eine reaktive Organisation handelt erst, wenn sie durch eine externe Motivation dazu veranlasst wird, z. B. eine neue Business- Anforderung, eine neu entwickelte Anwendung oder eine Eskalation der Beschwerden von Anwendern und Kunden. Eine proaktive Organisation ist ständig auf der Suche nach Möglichkeiten, die aktuelle Situation zu verbessern. Sie überprüft laufend die interne und externe Umgebung und sucht nach Anzeichen für Änderungen mit potenziellen Auswirkungen. 8

9 9

10 10

11 Event ist jede erkennbare Begebenheit, die Bedeutung für die Serviceerbringung (oder für das Management der dafür benötigten IT- Infrastruktur) hat und deren Auswirkungen zu Abweichungen in der Servicequalität führen oder führen können. Es gibt verschiedene Arten von Events: Informationen (beschreiben reguläre Operationen) werden lediglich protokolliert wie z. B. Benachrichtigung über ein abgeschlossenes Backup Warnungen (beschreiben ungewöhnliche aber keine Ausnahmesituationen, die sich selbst regulieren können oder einen menschlichen Eingriff erfordern), z. B.: Die Hauptspeichernutzung bewegt sich 5 % unterhalb der akzeptierten Toleranzmarke Ausnahme Zustände wie z. B. Anmeldeversuch mit einem falschen Passwort oder der Betrieb eines Service oder eines Geräts verläuft derzeit nicht ordnungsgemäß Alarm wird häufig über System Management Tools erstellt und verwaltet die Verwaltung erfolgt im Event Management Prozess.

12 12

13 Normaler Service Betrieb = Service innerhalb des vereinbarten SLA

14 Das bedeutet jedoch nicht, dass alle Events Incidents sind. Viele Event-Klassen führen nicht zu Unterbrechungen, sondern weisen vielmehr auf einen normalen Betrieb hin oder sind rein informativ.

15 Incident Auch ein Ausfall eines Configuration Item ohne bisherige Auswirkungen auf einen Service ist ein Incident. Beispiel: Ein Ausfall einer oder mehrerer Festplatten in einer gespiegelten Partition. Workaround z. B. Neustart eines ausgefallenen Configuration Item. Workarounds werden in Known Error Records dokumentiert. Workarounds für Incidents, die nicht über zugeordnete Problem Records verfügen, werden in Incident Records dokumentiert.

16 Auf der Grundlage der Auswirkung und Dringlichkeit werden Prioritäten zugewiesen. Dringlichkeit (Urgency) Ein Wert, der wiedergibt, wie lange es dauert, bis ein Incident, Problem oder Change maßgebliche Auswirkungen auf das Business hat - wie schnell das Business eine Lösung benötigt. Ein Incident mit erheblichen Auswirkungen kann beispielsweise von geringer Dringlichkeit sein, wenn die Auswirkungen das Business bis zum Ende des Geschäftsjahrs nicht beeinträchtigen. Auswirkung (impact) Ein Maß für die Folgen eines Incident, Problems oder Change auf die Business-Prozesse. Die Auswirkung basiert häufig auf Anzahl der betroffenen Anwender. Weitere Faktoren, die das Ausmaß der Auswirkung beeinflussen können: Risiko für Leib und Leben, Anzahl der betroffenen Services, Ausmaß des finanziellen Verlusts, Auswirkung auf das geschäftliche Ansehen, Rechts- oder Gesetzesverstöße.

17 17

18 18

19 Das Problem Management ist verantwortlich für die Erstellung und Verwaltung von bekannten Fehlern während ihres gesamten Lebenszyklus. Zum Zeitpunkt der Erstellung eines Problem Record ist die Ursache in der Regel unbekannt. Known Error: Bekannte Fehler können auch von der Software Entwicklung, dem Release und Deployment Management oder den Suppliern identifiziert werden. In einigen Fällen kann es allerdings sinnvoll sein, einen Known Error Record zu einem noch früheren Zeitpunkt im Gesamtprozess zu erfassen etwa zu Informationszwecken auch wenn die Diagnose noch nicht beendet ist oder ein Workaround gefunden wurde. Ein solcher Record sollte jeweils dann erstellt werden, sobald es sinnvoll erscheint. KEDB: Diese Datenbank wird vom Problem Management erstellt und vom Incident und Problem Management eingesetzt. Die Known Error Database ist Teil des Service Knowledge Management Systems.

20 20

21 Request Fulfilment ist ein generischer Prozess, der die vielfältigen Serviceanfragen (Service Requests) behandelt, die von den Anwendern an die IT gestellt werden. In der Regel handelt es sich um Anfragen, die Standard-Changes nach sich ziehen, die zudem mit geringen Risiken und abschätzbaren Kosten verbunden sind, und regelmäßig auftreten, oder aber einfach nur um Informationsanfragen.

22 Viele Service Requests treten wiederholt auf, so dass die Definition vordefinierter Arbeitsabläufe (als Service Request Modelle) sinnvoll ist. Diese Vordefinition umfasst die erforderlichen Arbeitsschritte, die involvierten Mitarbeiter, Zeit- und Kostenvorgaben sowie die Eskalationspfade. Falls zur Bearbeitung der Service Requests ein Change erforderlich ist, kann dieser als Standard-Change definiert werden. Dabei könnte es sich beispielsweise um das Zurücksetzen eines Passworts oder die Bereitstellung standardmäßiger IT Services für einen neuen Anwender handeln. Die Ownership für den Prozess Service Request liegt im Service Desk, da dort die Anforderungen der Anwender überwacht, eskaliert, weitergeleitet und oftmals auch direkt erfüllt werden.

23 Vertraulichkeit Informationen stehen nur autorisierten Personen zur Verfügung Integrität Information ist vollständig, korrekt und gegen nicht autorisierte Veränderung geschützt Verfügbarkeit Informationen sind immer wenn erforderlich verfügbar und nutzbar

24 24

25 25

26 Die in der Abbildung oben dargestellten Service Operation Funktionen dienen dem Management einer dauerhaft stabilen operativen IT-Umgebung. Es handelt sich hierbei um logische Funktionen, die nicht zwangsläufig von einer vergleichbaren organisatorischen Struktur ausgeführt werden müssen. Das bedeutet, dass das Technical und Application Management in beliebiger Konstellation und aus einer beliebigen Anzahl von Abteilungen organisiert werden kann. In der Abbildung oben wird auch die organisatorische Überschneidung zwischen Technical Management IT Operations Management und Application Management dargestellt.

27 Der Service Desk ist der Single Point of Contact für die Kommunikation zwischen Service Provider und Anwendern. Nutzen eines Service Desk Verbesserter Kunden Service, -Wahrnehmung und Zufriedenheit Steigerung der Erreichbarkeit durch einen Single Point of Contact, Kommunikation und Information Bessere Qualität und schnellere Behandlung von Kunden oder Anwender Anfragen Erweiterter Fokus und eine proaktive Vorgehensweise um Service bereitzustellen Reduktion negativer Auswirkungen auf das Business Besser verwaltete Infrastruktur und Steuerung Optimierte Ausnutzung der IT Support Ressourcen und erhöhte Produktivität des Business Personals Mehr aussagekräftige Management Informationen für Entscheidungsunterstützung Die beste Vorgehensweise um First-Level Support Belange zu behandeln Verbesserte Teamarbeit und Kommunikation

28 Es gibt eine Vielzahl von Möglichkeiten zur Strukturierung und Unterbringung von Service Desks, die je nach Organisation variieren. In der Praxis muss eine Organisation allerdings häufig eine Struktur implementieren, bei der eine Kombination verschiedener Optionen berücksichtigt werden muss, um den Business-Bedürfnissen voll und ganz gerecht zu werden.

29 29

30 30

31 31

32 32

33 33

34 34

35 Application Management ist für das Verwalten der Anwendungen über deren Lebenszyklus hinweg verantwortlich. Hilfestellung bei der Identifikation von funktionalen und Management- Anforderungen an die Anwendungssoftware und beim Design und Deployment dieser Anwendungen, beim fortlaufenden Support und bei Verbesserungen für diese Anwendungen angeboten wird.

36 Die Funktion des Application Managements wird durch jede Abteilung, Gruppe oder Team, die in das Managen und Unterstützen der betrieblichen Anwendungen eingebunden sind, durchgeführt Application Management ist auch im Design, Test und der Verbesserung von Anwendungen, die Teil eines IT Services sind, vertreten. Es stellt die tatsächlichen Ressourcen für die Unterstützung des ITSM Lebenszyklus zur Verfügung. In dieser Rolle, sichert das Application Management, dass die Ressourcen effektiv geschult und für das Design, die Umsetzung, die Transition, den Betrieb und der Verbesserung der Technologie, die notwendig ist um IT Services zu liefern und zu unterstützen, eingesetzt wird.

37 37