Kompetenzziele ICT-Berufsbildung

Einen ICT-Service vereinbaren und überwachen (Modul 498)

Einen ICT-Service vereinbaren und überwachen (Modul 452)

Service Management (ITIL) – Grundlagen

498 / HK: 1.1. / Kap. 2 S. 54 + 68-69, Alles was man lernen muss

Warum betreiben wir IT?

Prozesse unterstützen

Als Werkzeug

Nicht IT als Selbstzweck einsetzen

Was ist ITIL?

I Information

T Technology

I Infrastructure

L Library

Eine herstellerunabhängige Sammlung von Best Practice Ansätzen

Unterstützt IT Organisationen dabei, Effizienzsteigerungen innerhalb der IT-Prozesse zu erzielen und den Kunden einen gleichbleibenden Service zu liefern

Führendes Framework (Werkzeugkoffer) für die Steuerung, Koordination des Management der IT

Stellt heute ein «de-facto-Standard» dar

Die IT Infrastructure Library ist eine Sammlung von Publikationen, die eine mögliche Umsetzung eines IT-Service-Managements beschreiben und gilt inzwischen als Standard.

Aufbau ITIL Zusammenfassung

Kernpublikationen ITIL

Service Strategy (Service Strategie, Finanzen)

Service Design (Service Konzeption und – Planung) / Anforderungen von Kunden

Service Transition (Service Implementierung bzw. Einführung) DL erzeugen

Service Operation (operativer Betrieb von Services) / Überführung in Betrieb

Continual Service Improvement (kontinuierliche Verbesserung von Services) Verbesserungsprozess

Framework

Ein Framework (englisch für Rahmenstruktur) ist ein Programmiergerüst, das in der Softwaretechnik, insbesondere im Rahmen der objektorientierten Softwareentwicklung sowie bei komponentenbasierten Entwicklungsansätzen, verwendet wird. Im allgemeineren Sinne bezeichnet man mit Framework auch einen Ordnungsrahmen.

Wie ist ITIL entstanden?

ITIL® entstand in den 80er Jahren durch eine Initiative der Britischen Regierung

Folgende Versionen wurden seither publiziert

V1 (1986 –1999)

V2 (1999 –2007)

V3 (ab 2007)

V3 Ausgabe 2011 (ab 2013)

Service Management

Service Management ist eine Menge von spezialisierten organisatorischen Fähigkeiten, die einen Mehrwert für den Kunden erzeugen. Diese werden in Form einer Dienstleistung (Service) angeboten.

Beinhaltet die Planung und Bereitstellung einer kundenorientierten Dienstleistung mit Hilfe eines prozessorientierten Verfahrens.

IT Service Management

ITSM bezeichnet die Gesamtheit von Massnahmen und Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen durch die IT-Organisation zu erreichen. Die Gewährleistung und Überwachung der Business Services, also für den Kunden sichtbaren IT-Dienstleistungen.

IT Service Management Zusammenfassung

Ziele des Service Managements

Ausrichtender IT-Services auf die gegenwärtigen und zukünftigen Anforderungen des Business und seiner Kunden.

Optimierender Qualität der erbrachten IT-Services.

Reduzierender (langfristigen) Kosten der Serviceerbringung.

Was ist ein Service?

Ein Service stellt eine Methode dar, einen Mehrwert für die Kunden zu generieren. Er orientiert sich hierbei an den Ergebnissen, welche die Kunden erzielen wollen, ohne dass diese die Kosten und die Risiken der Erzeugung tragen.

Ein Service ist eine Möglichkeit, einen Mehrwert für Kunden zu erbringen, indem das Erreichen der von den Kunden angestrebten Ergebnisse erleichtert oder gefördert wird. Dabei müssen die Kunden selbst keine Verantwortung für bestimmte Kosten und Risiken tragen.

Beispiele: Bestellungen, Versicherungen

Standardisierte Services

Solche Services sind:

Service Desk

Desktop Services

Server Hosting

Webhosting

SAP Services

Lohnabrechnung

Mails

SAP

Office 365

Cloud

Unterschied zwischen Produkt und Service

Eigenschaften eines Services:

Zusammenfall von Konsum und Produktion

Fehlende Lagerfähigkeit, Vergänglichkeit

Kein Eigentumstransfer

Zeitliche Gebundenheit der Produktion

Standortgebundenheit

Unvorhersehbare Qualität, direkt wirksam beim Kunden

Hoher, direkter Einbezug des Kunden

Eigenschaften eines Produkts

Produkte können gelagert werden

Produkte sind nicht vergänglich

Produkte kann man anfassen

Die Qualität der Produkte ist vor Übergabe an Kunden prüfbar

Beispiel Produkt und Service

Beispiel, wo sich Produkt und Service ergänzen und als Ganzes für den Kunden als Gesamtservice erkennbar ist:

Einkauf in einer Bäckerei. Produkt ist das Brot. Zusätzliche werden folgende Services geboten: Verkauf an guter Lage, Bezahlung mit Bargeld oder Karte

Unterschied Service und IT-Service

Einzig die zusätzliche Verwendung von Informationstechnologie macht den Unterschied aus. Alle anderen Elemente eines Service sind identisch.

Was ist ein IT-Service?

Ist eine Dienstleistung, die für einen oder mehrere Kunden von einem IT-Service-Provider bereitgestellt wird. Ein IT-Service basiert auf dem Einsatz der Informationstechnologie und unterstützt die Geschäftsprozesse des Kunden. Ein IT-Service besteht aus einer Kombination von Personen, Prozessen und Technologien und sollte über ein Service-Level-Agreement (SLA) definiert werden.

Bestellungen von IT-Services

Als Service Requests im Rahmen des Request Fulfilments (Auftragserfüllung)

Diese kümmert sich um die Bereitstellung von Standarddienstleistungen (Standard Services) für welche ein vordefiniertes Verfahren existiert.

Vordefinierte Fälle für Bestellungen:

Um dies zu unterstützen werden oftmals Request Modelle erstellt

Diese sind vordefinierte Abläufe für spezifische Request und stellen quasi einen Standard Change

Service Lifecycle

Ist ein organisatorisches Modell

Ist ein Ansatz für die Koordination und Steuerung der verschiedenen Funktionen, Prozesse und Systeme, die für das Management des gesamten Lifecycle notwendig sind.

Die Architektur von ITIL® basiert auf dem Service Lifecycle

Der Service Lifecycle umfasst 5 Phasen

Er beschreibt die Beziehungen zwischen den einzelnen Phasen und den Prozessen und Aktivitäten

Die Struktur kann als ein «organisiertes» Framework verstanden werden

Der Service Lifecycle-Ansatz unterstützt die Struktur des «systembezogenen» Service Managements und erzeugt damit die notwendige Flexibilität und Dynamik, welche die Voraussetzung für eine schnelle Reaktion auf geforderte Änderungen des Business ist

!!

•Auf Grund der Service Strategie, die auf Basis der IT-Strategie entwickelt wird, werden neue Services entwickelt und in den Betrieb überführt.

• Zur permanenten Verbesserung von produktiven Services dient das Continual Service Improvement

Aufbau eines IT-Service

Was ist ein Service Provider?

Sind Anbieter von Diensten, Inhalten oder technischen Leistungen, die für die Nutzung oder den Betrieb von Inhalten und Diensten im Internet erforderlich sind.

Der Service Provider erbringt (IT) Service Leistungen an das Business

ITIL®unterscheidet hierzu drei unterschiedliche Geschäftsmodelle für Service Provider:

Interne Service Provider, welcher in derselben Businessunit angesiedelt ist wie der Kunde

Shared Service Provider, welcher Leistungen für verschiedene Businessunits in einer Unternehmung erbringt

Externer Service Provider, welcher Leistungen für verschiedene Unternehmen erbringt.

Provider Auswahl

Faktoren - Provider Auswahl

Know-how

Kompetente Beratung

Sicherheit

Referenzen

Preis = Support kostet extra

Leistungen = Anforderungen abdecken

Zahlungsbedingungen

Sprache

Welche Bestandteile beinhaltet ein sog. Asset und welche zwei Haupttypen gibt es?

Die Assets eines Service Provides umfassen alle Elemente, die zur Erbringung eines Services beitragen können.

Die beiden Haupttypen lauten Ressourcen und Fähigkeiten.

Welche Fragen muss sich ein Service Provider aus Sicht des Marketings stellen?

Was ist unser Geschäft

Wer sind unsere Kunden

Was schätzt der Kunde

Wer hängt von unseren Services ab

Wie benützen sie unsere Services

Warum sind sie ihnen wertvoll

Stakeholder Service Provider

Interne/externe Kunden Service Provider

Die Kunden beauftragen den Service Provider und bezahlen für den Service

Sie definieren und vereinbaren die Service Level Ziele

Grundsätzlich unterscheiden wir jedoch zwischen internen und externen Kunden:

Interne Kunden generieren nur interne finanzielle Transaktionen (interne Verrechnung oder Umlagen in der Kostenrechnung)

Externe Kunden generieren Cashflow

In Bezug auf die Leistung und die Service Level sind interne und externe Kunden identisch zu behandeln

Was ist ein Prozess?

Eine definierte Menge Aktivitäten, mit deren Hilfe ein bestimmtes Ziel erreicht werden soll

Wandelt einen Input in einen definierten Output

Kann beliebige Rollen, Verantwortlichkeiten, Hilfsmittel, Tools und Steuerungen für das Management enthalten, die für die Sicherstellung des Outputs erforderlich sind

Kann den Anforderungen entsprechende Richtlinien, Standards, Leitlinien, Aktivitäten und Arbeitsanweisungen definieren

Merkmale eines Prozesses?

Ziele

Input (Auslöser, Anforderungen Kunde)

Aktivitäten (Tätigkeiten)

Output (Ergebnis)

Bedingungen (Umfeld)

Qualität (Leistungsindikatoren)

Inhalt Prozessbeschreibung

IT Prozesse und Funktionen

Erfolgsfaktoren für eine erfolgreiche Prozessmodelierung

Frühzeitiges Einbinden des Managements in das Projekt

Bildung von Prozessmodellierungs-Teams in angemessener Grösse

Moderation der Prozessmodellierung durch eine neutrale Person

Vorherige Festlegung des Umfangs und des Detaillierungsgrades

Festlegen von Standards (z.B. zu verwendende Notation)

Iterativer Ansatz – kleine, dafür regelmässige Schritte

Lernen –bereits ab Beginn den Ansatz der kontinuierlichen Verbesserung verfolgen

Nicht direkt mit einem Prozessmodellierungs-Tool anfangen

Erfolgsfaktoren für die Einführung von Service Management

Geschäftsprozesse der Kunden

Kunden & Anwender der IT

Mitarbeiter & Management der IT

IT-Prozessmodell

Kultur & Organisation

ITSM-Tools

Was ist eine Rolle

Ein Satz von Verantwortlichkeiten, Aktivitäten und Kompetenzen, die einer Person oder einem Team zugewiesen sind

Eine Rolle wird in einem Prozess definiert

Einer Person oder einem Team können mehrere Rollen zugewiesen sein

Die Rolle des Configuration Managers und des Change Managers können beispielsweise von derselben Person wahrgenommen werden

Rollenmodell

Prozess-Sponsor (Förderer)

Bereitstellung der benötigten Mittel

Autorisierung erforderlichen Investitionen definiert

Sorgt für die notwendige «Management Attention»

Prozess-Owner (Ergebnisverantwortlicher)

Verantwortlich für das Design und die Weiterentwicklung des Prozesses

Schafft die Rahmenbedingen und sorgt für die Qualitätssicherung der Abläufe

Fokus liegt auf der kontinuierlichen Verbesserung der Abläufe

Definiert die Messpunkte zur Ermittlung von Leistungsindikatoren

Prozess-Manager (Durchführungsverantwortlicher)

Verantwortlich für den täglichen Betrieb seines Prozesses

Sorgt für die Einhaltung der definierten Arbeitsabläufe

Verantwortlich für die Erhebung und das Reporting der Leistungskennzahlen

Ansprechpartner und Eskalationsinstanz für die Prozess Practitioner

Prozess-Practitioner (Mitwirkende/Ausführende)

Übernimmt bestimmte Aktivitäten im Rahmen des Prozessablaufes

Berichtet an den Prozess-Manager im Rahmen der definierten Prozessabläufe

Service Owner (Applikation, Mail etc.)

Ist für das Management eines oder mehrerer Services über den gesamten Lebenszyklus verantwortlich

Unterstützt die Entwicklung der Servicestrategie

Verantwortlich für den Inhalt des Serviceportfolios

Prozess-Coach (Beratender)

Steht den anderen Prozessrollen als aktiver Gesprächspartner zur Seite

Leitet diese mit seinen Erfahrungen zu den gesetzten Zielen

RACI

Ist eine Technik zur Analyse und Darstellung von Rollen und Verantwortlichkeiten.

Was ist eine Funktion?

Eine Funktion ist ein separater Aufgaben- und Verantwortungsbereich innerhalb einer Organisation

Dies kann z.B. ein Team sein, das eingesetzt wird, um einen oder mehrere Prozesse oder fachliche sowie prozessuale Aktivitäten durchzuführen.

Eine Funktion ist charakterisiert durch folgende Schlüsselkriterien:

Funktionen geben der Organisation Struktur und Stabilität

Funktionen sind eigenständige Einheiten mit eigenem Ressourcen und Fähigkeiten

Funktionen sind für ihre Zusammenarbeit auf Prozesse angewiesen

Beispiele: Service Desk, Team

5 Phasen Service Lifecycle

Service Strategy

Service Design

Service Transition

Service Operation

Continual Service Improvement

Prozessgruppen einer Unternehmung

Managementprozess

Kernprozess

Unterstützungsprozess

Identifikation Kernprozesse Unternehmung

Entlang der Wertschöfpfungskette (es wird Wert generiert)

Direkter Mehrwert für den Kunde

Hauptaufgaben der IT in einer Unternehmung

Unterstützung der (Kern)-Prozesse damit die Unternehmung einen Mehrwert generieren kann.

Servicequalität

Unter Servicequalität ist der Umfang bzw. das Ausmass zu verstehen, in dem ein Service den Anforderungen und Erwartungen eines Kunden entspricht.

Aufgabe der Qualitätssicherung wird durch den Prozess «Continual Service Improvement» übernommen. Innerhalb dieses Prozesses ist das Service Level Management für die Messung und Berichterstattung über die Messungen zuständig.

Service Management (ITIL) – Service Strategy

Definition

Gestaltet, entwickelt und implementiert IT Service Management und stimmt die Strategie und die Services auf die Ziele des Business, bzw. der Kunden ab.

Was sind wir? Wo wollen wir hin?

Rollen: Service Owner, Chief Sourcing Officer

Prozesse

Strategy Management for IT Services

Service Portfolio Management

Financial Management for IT Services

Demand Management

Business Relationship Management

Servicekonzept

Zusammensetzung eines Services

Servicegliederung

Ermittlung eines notwendigen Service Assets

Strategy Management for IT Services

Definition der Perspektive, Position, Pläne und Patterns (Muster) für einen Service Provider bezüglich seiner Services und dem Management dieser Services

Service Portfolio Management

Die richtige Zusammenstellung im Portfolio, heute und in Zukunft

Balance zwischen Wert und Investitionen

Balance zwischen Risiken und Ertragschancen

Financial Management for IT Services

Budgeting

Ausgabe von Geldmitteln wird prognostiziert und gesteuert

Umfasst einen periodischen Verhandlungszyklus, um zukünftige Budgets festzulegen (in der Regel jährlich) sowie das aktuelle Budget zu überwachen und anzupassen

Accounting

Ist-Kosten für die Bereitstellung von IT Services werden identifiziert und mit den Kosten aus der Finanzplanung verglichen, um Budget-Abweichungen zu handhaben

Charging

Bezahlung für IT Services in Form von Berechnungen oder Verrechnungen

Für IT Services ist eine Leistungsverrechnung optional; viele Organisationen führen ihren IT Service Provider als Cost Center

Financial Management Zusammenfassung

Demand Management

Reaktion auf die dynamischen Anforderungen der Geschäftsprozesse aus Sicht der Service Provider

Ausbalancierung zwischen Businessanforderungen und den bereitzustellenden Kapazitäten

Ein funktionierendes Demand Management stellt sicher, dass keine Kosten durch überschüssige und nicht genutzte Kapazitäten entstehen

Verschiedene Techniken im Demand Management, wie «Off Peak Pricing», «Volume Discounts» oder gestaffelte Service Level können den Bedarf im Rahmen von spezifischen Modellen beeinflussen

Kapazitäten und Ressourcen, die einem Service zur Verfügung gestellt werden, sollten an Bedarfsprognosen ausgerichtet sein

Business Relationship Management

Die Etablierung und Pflege einer Business Beziehung zwischen dem Service Provider und dem Kunden

Identifikation der Kunden-Anforderungen

Sicherstellung, dass der Service Provider in der Lage ist, diese Anforderungen zu erfüllen.

Business Case

Herausfordrungen

Ziele

Fokussierung auf praktische und übergreifende Ansätze des Service Management

Definieren und Implementieren von Strategien (Business Strategie)

Definieren und Überwachen der wirtschaftlichen Aspekte von Services und Service Management

Definition von Standards und Richtlinien für Design, Entwicklung, Implementierung, den operativen Servicebetrieb und die kontinuierliche Verbesserung von Service Management

Strategische Assets

Einen wirtschaftlichen und qualitativen Mehrwert für das Business zu erreichen

Fragestellungen

Welche Services sollen wem angeboten werden?

Wie kann sich ein Service Provider von seinen Konkurrenten differenzieren?

Wie kann ein tatsächlicher Mehrwert für die Kunden generiert werden?

Wie können strategische Investitionen im Service Management begründet werden?

Wie ist die Servicequalität zu definieren?

Vorteile

Erzeugung von Wertschöpfung durch die übergreifende, strategische und wirtschaftliche Betrachtung bezüglich Service Management und strategische Assets

Erfassung der technischen sowie auch ablauforientierten Komplexität und Aufsetzen der dafür aus strategischer Sicht sinnvollen und gezielten Strukturen.

Klare Weichenstellung für die Bereitstellung von Services bzw. Service Assets bezüglich der Parameter Effizienz und Effektivität

Unterschied Utility

Warranty

Utility ist das, was der Kunde erhält. Warranty beschreibt, wie der Kunde den Service nutzen kann.

Nur wenn die Utility und die Warranty gleichzeitig in dem vereinbarten Mass bereitgestellt werden, wird durch den Service aus Sicht des Kunden ein Mehrwert generiert.

Welche Prozesse stellen die Warranty-Aspekte eines Services sicher?

Capacity Management

Availability Management

Continuity Management

Information Security Management

Fit for purpose –Utility (zweckmässig)

Der Service reflektiert die Anforderungen des Kunden so, dass ein positiver Effekt bezüglich des Outputs entsteht

Ein positiver Output ist dann gegeben, wenn durch den Service die Performance des Geschäftsprozesses unterstützt wird oder Beschränkungen beseitigt werden

Fit for use –Warranty (einsatzfähig)

Die Servicestruktur aus Sicht des Betriebs sind so ausgeprägt, dass der Service stabil und sicher bereitgestellt werden kann

Der Service verfügt über das richtige Mass an Verfügbarkeit, Kapazität, Kontinuität und Sicherheit

Market Space (Marktraum)

Möglichkeiten, die ein IT Service Provider nutzen könnte, um den Business-Anforderungen der Kunden gerecht zu werden

Repräsentiert die möglichen IT Services, deren Bereitstellung sich der IT Service Provider vorstellen könnte.

Wenn Services sich denselben Marktraum teilen, werden sie auch die Fähigkeiten und Ressourcen, Kosten, Risiken und Herausforderungen für die Umsetzung und den Betrieb teilen und sollten somit einer gemeinsamen Betriebsverantwortung unterstehen

Serviceportfolio

Gesamtheit aller Services, die von einem Service Provider gemanaged werden

Es wird für das Management des gesamten Lebenszyklus aller Services genutzt

Servicemodelle

Zeigen, wie die Service-Assets mit den Kunden-Assets interagieren, um einen Mehrwert zu generieren

Beschreiben die Struktur eines Services (wie die «Configuration Items» zusammenpassen) und die Dynamik des Services (Aktivitäten, Ressourcenfluss und Interaktionen)

Kann als Vorlage oder Blueprint für viele Services genutzt werden

Constraints (Beschränkungen)

Restriktionen bzw. Rahmenbedingungen, die den Gestaltungsraum zur Umsetzung von Business Anforderungen beeinflussen

Können allgemeingültig, aber auch kundenspezifisch sein

Die innerhalb dieser Restriktionen möglichen Ausrichtungen ergeben den «Lösungsraum» (Solution Space), also den Bereich, in dem man sich mit einer umsetzbaren Lösung bewegen kann

Risiko

Ein mögliches Ereignis, das zu einem Schaden oder Verlust führen oder das Erreichen von Zielen beeinträchtigen könnte.

Ein Risiko wird anhand der Wahrscheinlichkeit einer Bedrohung, der Verwundbarkeit des Assets durch die Bedrohung gemessen.

Risiko kann auch als Unsicherheit eines Ergebnisses definiert werden und im Kontext der Wahrscheinlichkeitsmessung eines positiven als auch eines negativen Ergebnisses genutzt werden.

P’s

1. Perspective / Perspektiven

Vision, Mission, Strategie

Definieren die übergeordneten Werte und Überzeugungen und vermitteln ein Gefühl für den Zweck, um die Richtung festzulegen

Bestimmen die Art und Weise der Servicebereitstellung

2. Position / Positionierung

Definieren die Herangehensweise und Differenzierungen in Markträumen und im Wettbewerb

Legen die strategischen Positionen fest: z.B. Kostenführer, Innovator, Segmentierung, Differenzierung

3. Plan

Basiert auf Perspektiven und Positionen

Langfristige Pläne zur Erreichung der strategischen Ziele

4. Muster / Pattern

Master-Framework für die gesamte Organisation, z.B. Budget, Prozessmodell

Konsequenz aus Perspektiven, Positionen und Plänen

Bildet die strategischen Verhaltens-und Entscheidungsmuster

Summary

Service Management (ITIL) – Service Design

498 / HK: 1.3. / Block 3 Service Design Folie 10 + Clavis Map

498 / HK: 2.1+2.2. / Alles was man lernen muss S. 100, IT-Security S. 107

498 / HK: 4.1+4.2. / Alles was man lernen muss S. 108-111

498 / HK: 6.1. / Alles was man lernen muss S. 109

Phase Service Design

Aufgabe in der Phase Service Design im Servicelebenszyklus:

Sicherstellen, dass sich die Servicestrategie im Service Design Prozess und in den erstellten Service Design wiederspiegeln.

Erstellen qualitativ hochwertiger, sicherer und belastbare Desings für neue oder verbesserte Services

Messen der Effizienz und Effektivität des Service Designs und der unterstützenden Prozesse.

Definition

Konzentriert sich auf Entwurf und Entwicklung von neuen oder geänderten IT Services unter Berücksichtigung von Lösungen, Systemen, Prozessen, Werkzeugen und Metriken.

Rollen: Service Design Manager, Service Catalogue Manager, Service Level Manager, Availability Manager, Service Continuity Manager, Capacity Manager, IT PlannerSecurity Manager, ITSCM Manager, Supplier Manager

4 P’s

Erfolgreiches IT Service Management

People

Process

Products

Partners/Provider

Drei Aspekte des Balanced Design

Funktionalität

Ressourcen (MA, Infrastruktur, Finanzen, Verfügbarkeit)

Planung

Ziele Service Design

Design von neuen oder geänderten Services für ihre Einführung in den operativen Betrieb

Service Design definiert und designed Services und Service Assets (Policies, Architekturen und Portfolio) auf Basis der strategischen Ziele und Business-Anforderungen

Ermittlung der Kundenanforderungen und Übersetzung in Service und Service Management Lösungen

Das Service-Design betrachtet alle Designaspekte bei der Planung von neuen Services sowie Änderungen oder die Anpassung der Services und des Service Management

Wert fürs Business

Verbesserung TCO (Total Cost of Ownership)

Verbesserung Service Qualität

Einfachere Implementierung von neuen und geänderten Services

Sicherstellung der Konsistenz der Services

Service Alignement

Bessere Erfüllung der Businessanforderungen

Nutzen

Service Design Package (SDP)

Besteht aus einer Sammlung an Dokumenten, in denen alle Aspekte eines IT Services einschliesslich dessen Anforderungen innerhalb jeder Phase des Lebenszyklus des IT Services definiert sind

Wird für neue IT Services, umfassende Changes sowie die Stilllegung von IT Services erstellt

Service-Lösungen für neue oder veränderte Services

Es ist sicherzustellen, dass neue oder geänderte Services in das bestehende Serviceportfolio passen und sich in die bestehenden Supportstrukturen einbinden lassen

Management Information Systeme und Tools

Es ist sicherzustellen, dass das Service Management System den entsprechenden Supportgewährleistet

Der Einsatz der richtigen Management Systeme, Tools und ein hohes Mass an Automatisierung ist ein wichtiger Erfolgsfaktor für ein effizientes Service Management

Technologie- und Management-Architekturen

Es ist sicherzustellen, dass die eingesetzten Technologien, die Infrastruktur und die Applikationen mit dem neuen oder geänderten Service vereinbar sind, so dass der Betrieb und die Wartung des neuen Services wertschöpfend möglich sind.

Folgende Aspekte müssen berücksichtigt werden:

Servicearchitektur

Anwendungsarchitektur

Informations-/Datenarchitektur

IT-Infrastruktur Architektur

Umgebungsarchitektur

Benötigte Prozesse

Es ist sicherzustellen, dass das Prozessdesign sowie die damit verbundenen Rollen und Verantwortlichkeiten sowie Prozessfähigkeiten geeignet sind, den neuen oder geänderten Service zu betreiben, zu unterstützen und zu warten.

Service Design Prozesse:

- Design Coordination

- Service Catalogue Management

- Service Level Management

- Capacity Management

- Availability Management

- IT Service Continuity Management

- Information Security Management

- Supplier Management

Messmethoden und –Metriken

Es ist sicherzustellen, dass bestehende Messmethoden den neuen oder geänderten Service unterstützen und es erlauben, die erforderlichen Kennzahlen und Metriken zu liefern.

Metriken - Beschreibung

Eine Softwaremetrik, oder kurz Metrik, ist eine (meist mathematische) Funktion, die eine Eigenschaft von Software in einen Zahlenwert, auch Masszahl genannt, abbildet. Hierdurch werden formale Vergleichs-und Bewertungsmöglichkeiten geschaffen.

„Eine Softwarequalitätsmetrik ist eine Funktion, die eine Software-Einheit in einen Zahlenwert abbildet, welcher als Erfüllungsgrad einer Qualitätseigenschaft der Software-Einheit interpretierbar ist.“

Metriken sollen….

- die Service Management-Prozesse unterstützen

- verständlich sein

- ohne große Kosten / Overhead erhoben werden

- Nachvollziehbarkeit gewährleisten

- die Grundlage für Planung darstellen

- die Grundlage für Berechnung und Verrechnung bilden

- vorbeugend warnen

- aussagekräftige Berichte ermöglichen

Metriken - Grundsätze

- Jeder Bereich hat seine individuellen Metriken

- Metriken müssen auf den Empfänger abgestimmt sein

- Nur die Metriken erheben, die wirklich notwendig sind –Messen kostet Overhead –und das Lesen der Metriken ihre Zeit!

- Wenn Metriken nur im Kontext sinnvoll sind, dann den Kontext herstellen

- Alle 6 Monate die Notwendigkeit der Metriken in Frage stellen (CSI)

- Metrik-und Berichtgenerierung muss automatisiert sein

Service Management Metriken

Dashboard

Vorteile

Reduzierung der Total Cost of Ownership (TCO)

Verbesserung der Service Konsistenz (Umfrage, Messen (Kapazitäten, Verfügbarkeiten, KUZU)

Einfachere Implementierung von neuen oder geänderten Services

Optimierung des Service Alignments (Alignment = Ausrichtung)

Gesteigerte Effektivität in der Leistungsfähigkeit (Anforderungserfüllung)

Verbesserung im Zusammenspiel mit Governance

Kürzere Time-to-Market Zeiten

Bessere Erfüllung der Businessanforderungen

Prozesse

Design Coordination Planung und Koordination für Design

Service Catalogue Management Sicherstellung der Finanzierung

Service Level Management Sicherstellung der Serviceleistung gemäss vereinbarten Zielen

Capacity Management Erfüllung der Kapazitätsanforderungen

Availability Management Erfüllung der Verfügbarkeitsziele

Service Continuity Management Betrieb der geschäftskritischen Services im Katastrophenfall

Information Security Management Schutz der Assets, Informationen, Daten

Supplier Management Qualitäts- und Kostenüberwachung hinsichtlich der Zulieferer

Design Coordination

Prozessaktivitäten

Ziele und Zweck

Sicherstellen, dass die Service Design Zielsetzungen erreicht werden

Zentrale Koordinations-und Kommunikationsschnittstelle aller Aktivitäten

Gewährleisten eines konsistenten und effektiven Designs der Services durch Planung und Koordination aller Design Aktivitäten und der dazu erforderlichen Ressourcen und Fähigkeiten.

Service Portfolio Management

Das Service Portfolio beschreibt die Services aus Sicht des Business.

Er beschreibt die Business Anforderungen und wie diese durch die Services abgedeckt werden.

Das Service Portfolio beinhaltet sämtliche Services über den gesamten Service Life Cycle, solche die sich in der Pipeline befinden, Services welche bereits Bestandteil des Servicekatalogs sind und bereits abgelöste Services.

Service Catalogue Management

Ziel und Zweck

Bereitstellung und Pflege einer zentralen und konsistenten Informationsquelle zu allen operativen Services

Bereitstellung dieser Informationen an alle autorisierten Personen und Funktionen

Abstimmung mit Service Portfolio Management

Management des Servicekatalogs

Bereitstellung der Servicekatalogansichten (Views)

Basiskonzepte

Servicekatalog

Datenbank oder ein strukturiertes Dokument mit Informationen zu allen geplanten und aktiven IT Services einschliesslich der Services, die für das «Deployment» verfügbar sind. Auch die Services die zwar nicht mehr angeboten werden, aber „per Knopfdruck“ reaktiviert und wieder angeboten werden können, sind im Servicekatalog enthalten

Teil des Serviceportfolios und enthält Angaben zu zwei Arten von IT Services:

Kundengerichtete Services, die für das Business sichtbar sind; sind typischerweise Services, die die Geschäftsprozesse des Kunden oder der Business Unit direkt unterstützen oder direkt einen durch den Kunden gewünschten Output produzieren

Unterstützende Services, die für den Service Provider notwendig sind, um kundengerichtete Services bereitzustellen

Prozessaktivitäten

Vereinbaren und dokumentieren einer Servicedefinition und Beschreibung für jeden Service mit allen betroffenen Parteien

Herstellen der Schnittstelle zum Service Portfolio Management zur Abstimmung der Inhalte von Service Portfolio und Servicekatalog.

Service Katalog
-> Inhalt

Kategorisierung

Version

Status

Phase

Service Portfolio / Service Katalog
-> Big Picture

Service Katalog
-> Hierarchie

Servicebeschreibung
-> Beispiel

Service Level Management

Zweck und Ziele

Definition, Vereinbarung, Überwachung, Messung, Review und Rapport der bereitgestellten IT Services zwischen der IT-Organisation und den Kunden

Erfassen, Vereinbaren und Dokumentieren von Kundenanforderungen (Service Level Requirements, SLR)

Verfassen von Service Level Agreements (SLA) mit Kunden sowie deren periodische Überprüfung

Konzipieren und Dokumentieren von internen Vereinbarungen im Rahmen der Serviceerstellung sowie Integration von externen Partnern

Gewährleisten, dass alle aktuellen und geplanten IT-Services entsprechend der vereinbarten und erreichbaren Zielen bereitgestellt werden.

Basiskonzepte

Service Level Requirements (SLR)

Anforderungen des Kunden hinsichtlich seiner benötigten IT Services werden beschrieben

Service Level Agreement (SLA)

Qualitative und quantitative Vereinbarungen zwischen dem Kunden und der IT Organisation hinsichtlich der zu leistenden IT Services werden festgelegt

Ein SLA lässt sich grundsätzlich in einen Leistungsbereich (Inhalt und Leistungsparameter) und in einen kaufmännischen und juristischen Bereich unterteilen.

Operational Level Agreement (OLA)

Nach innen gerichtete Vereinbarung zwischen den internen Fachbereichen der IT-Organisation über die Erstellung und Erbringung eines Teilservices zur Erfüllung eines SLA

Interne Vereinbarungen in Form eines OLA enthalten keinen juristischen Anteil

Underpinning Contract (UC)

Extern gerichtete Vereinbarung mit einer dritten Partei (externer Dienstleister) über die Lieferung von definierten Services als Teilerbringung eines SLA gegenüber dem Kunden

Vertragswerk mit einem rechtswirksamen Anteil

Supplier Management (Prozess) befasst sich mit den Lieferanten

SLA definieren

SLAs = unabdingbaren Werkzeuge sind, um die IT stärker auf die Geschäftsanforderungen auszurichten.

Die folgende begriffliche und inhaltliche Abgrenzung der verschiedenen SLAs ist für das Verständnis der folgenden

Abhandlung zentral. Diese Abgrenzung bezieht sich auf die Stellung der Partner aus Sicht der IT-Organisation:

• SLAs (Service Level Agreement) - alle Serviceverpflichtungen gegenüber Kunden.

• OLAs (Operation Level Agreements) - alle internen Vereinbarungen zwischen dem Service Management

und den Abteilungen der Firma und/oder den IT-Fachabteilungen, damit Kundenanforderungen,

die in den SLAs vereinbart wurden, erfüllt werden können.

• UCs (Underpinning Contracts) - Vereinbarungen der IT-Organisation mit seinen Unterlieferanten

(Software Wartungsverträge, Hardware Wartungsverträge, Supportverträge, Outsourcingverträge etc.).

-

SLAs dienen dazu die Qualität von IT-Services zu standardisieren, zu messen und dem Servicenehmer die zugesicherte Leistung nachzuweisen. Die dazu gemeinsam vereinbarten Kennzahlen, die messbar und operativ relevant sein müssen, bilden dabei den eigentlichen Kern der SLAs. Ziel eines erfolgreichen IT-Unternehmens ist es,

SLAs möglichst nahe an den im Servicekatalog beschriebenen Dienstleistungen zu halten. Dies ermöglicht dass

einheitliche Geschäftsprozesse für alle Servicenehmer gelten und reduziert so die Individualität und hält damit

die Kosten tief. Ein Beispiel für eine Vereinbarung (Kennzahl) aus einem SLA könnte lauten: ‚Erreichbarkeit des

First Level Supports über Telefonnummer 123/456 78 90 Mo.-Fr. von 07:00 bis 18:30 Uhr’.

Zu den SLA-Kennzahlen gehört auch die Spezifikation von Konsequenzen bei (positiven und negativen) Abweichungen von den vereinbarten Soll-Werten. Dies ist eine sogenannte Bonus-Malus-Vereinbarung.

• Malus: Konsequenzen bei Verletzung eines Service-Levels (z.B. finanzielle Entschädigung)

• Bonus: Konsequenzen bei Übererfüllung eines Service-Levels(z.B. Kostensenkung)

Anforderungen definieren

Verfügbarkeit:

Bedingungen der Nichtverfügbarkeit

Ziele der Verfügbarkeit

Zuverlässigkeit(MTBF)

Wartungsfenster (wann, wie lange,Einschränkungen)

Capacity:

Benötigte Kapazitäten (Speicher, Anzahl Transaktionen, Anzahl User,…)

Antwortzeiten, Transferzeiten, Ausführungszeiten,…

Service Continuity:

Zeitpunkt bis definierter Service Level erreichtist

Zeitpunkt bis normaler Service Level erreichtist

Reporting

Usability-Anforderungen

Service Level Management
-> Overview

SLA Kosten/Preise kalkulieren

Typische Service Level

Amortisations-rechnung

Service Level – Messung, Reporting, Steuerung

Messkritieren

Service Level -Qualitätskriterien und KPI‘s

Typische Messkriterien

Beispiele zu Qualitätskriterien und KPIs

Aspekte von Messverfahren

Service Level Reporting SLR

Beispiel Bericht:

SLA – Folgen Erfüllung / Nicht Erfüllung

Auswirkungsanalyse (Impact Analyse)

Eine Analyse der Auswirkungen beim Ausfall oder Teilausfall eines Services wird als Impact Analyse bezeichnet.

Diese Analyse umfasst drei Bereiche:

Als Erstes muss festgestellt werden, welche Geschäftsprozesse oder Geschäftstätigkeiten durch einen Ausfall oder Teilausfall betroffen sind und wie stark sie betroffen sind.

Vorausschauend sollten mögliche Störungen von Services als Risiko betrachtet werden. Diese Risiken sollten analysiert und bewertet werden (Risiko-Analyse).

Sind die Risiken bekannt, können die entsprechenden Massnahmen bestimmt werden, um diese Risiken zu vermeiden oder die Auswirkung zu reduzieren.

Betroffene Geschäftsprozesse ermitteln

Geschäftsprozesse werden durch IT-Services unterstützt. Dabei können mehrere IT-Services einen bestimmten

Prozess unterstützen, oder ein bestimmter IT-Service unterstützt mehrere Geschäftsprozesse. Auch eine eins-zueins

Beziehung kann vorkommen.

Bei der Analyse sollte vor allem darauf geachtet werden, dass auch ein IT-Service selbst aus mehreren Teil-

Services bestehen kann!

Damit eine solche Analyse vorgenommen werden kann, ist es notwendig, eine genaue Übersicht über alle Beziehungen

zu haben. Ein gut gepflegtes Konfigurations-Management-System (CMS, CMDB, Service-Katalog) ist hier

unbedingt erforderlich.

Risiken ermitteln

Entscheidungen bezüglich Risiken müssen so getroffen werden, dass über den potenziellen Nutzen ein Mehrwert

für die Organisation generiert werden kann.

Dieser Mehrwert sollte höher sein als die Kosten der Risiken. Auch eine Innovation kann bspw. risikoreich sein.

Durch die Verbesserung kann jedoch ein grösserer Nutzen erzielt werden.

Für Analysezwecke kann es nützlich sein, die positiven Risikoarten zu kennen, vor allem jene, die mit Gelegenheiten, Investitionen und Innovationen in Verbindung stehen.

Im Gegensatz dazu kann unter negativen Risiken verstanden werden:

• Auslassen von Gelegenheiten.

• Erfolglose Investitionen.

• Ignoranz gegenüber Innovationsmöglichkeiten.

Massnahmen bestimmen

Das Risikomanagement stellt sicher, dass es Prozesse gibt, die sich auf die Überwachung der Risiken fokussieren.

Das heisst, dass zuverlässige und fortlaufende Informationen über Risiken geliefert werden und entsprechende

Regelungen existieren, wie mit den Risiken umzugehen ist.

Dies wird mittels einer entsprechenden Kontrolle gewährleistet.

Die Entscheidungsfindung stützt sich auf ein Rahmengerüst, das sich aus Risikoanalyse und Risikobewertung

zusammensetzt.

Kontrolle der Leistungsvereinbarungen

Eine regelmässige Kontrolle der Service-Leistungen ermöglicht es potenzielle Störungen rechtzeitig zu erkennen.

Dazu ist ein geeignetes Berichtswesen (Reporting) notwendig.

Service-Messsystem

Die Leistung eines Services entsteht nicht an einem Ort. Ein Service besteht aus verschiedenen Komponenten,

welche auch wieder in Gruppen und Systemen zusammengefasst sind.

Wichtig ist es darum, die Messungen auf mehrere Ebenen zu implementieren. Nur so kann eine Gesamtleistungszahl

definiert und ausgewiesen werden.

Die Geschäftsprozesse sollten beim Aufbau des Messsystems in Vordergrund stehen. Die kritischen Geschäftsprozesse

sind auf die höchste Leistungsqualität angewiesen.

Das Messen von Services ist nicht der eigentliche Hauptzweck! Vielmehr geht es darum, Verbesserungspotenzial

für die Services zu entdecken.

Ein Service-Messsytem sollte folgende Punkte umfassen:

• Die Services.

• Die Service-Komponenten.

• Die Service Management Prozesse, welche die Services unterstützen.

• Die Aktivitäten innerhalb den Prozessen.

• Die Erzeugnisse (Output).

Das Messsystem sollte ausgewogen und stabil sein. Änderungen sind auch hier Bestandteil des Lebenszyklus und

sollten die Stabilität nicht gefährden.

Die nachfolgende Tabelle zeigt einige Schlüsselelemente für ein Messsystem:

Kritische Elemente für ein Messsystem

Für ein erfolgreiches Messsystem sind folgenden Voraussetzungen kritisch:

Das System sollte folgende Kriterien erfüllen:

• In der Geschäftsplanung integriert sein.

• Auf die Geschäftsziele und IT-Ziele ausgerichtet sein.

• Kosteneffektiv sein.

• Ausgewogen sein in Bezug auf dem, was gemessen wird.

• Robust gegenüber Änderungen sein.

Die Leistungsmessungen sollten:

• Genau und Zuverlässig sein.

• Klar definiert und spezifisch sein.

• Relevant sein in Bezug auf die Zielerreichung.

• Kein negatives Verhalten verursachen (Intrusion).

• Verbesserungsmöglichkeiten anpeilen.

Die Leistungsziele sollten das «SMART» Prinzip unterstehen. Dieser Begriff bezieht sich auf die folgenden Eigenschaften:

«Specific, Measurable, Achievable, Relevant and Timely».

Service Level Managemen - Zusammenfassung

Aufgaben

Input

Output

XE "SLM Messgrössen"

Formalitäten

Bezeichnung des Services

2. Freigabeinformationen (mit Ort und Datum)

2.1 Service Level Manager

2.2 Verantwortlicher Vertreter des Service-Kunden

3. Laufzeit des Vertrages

3.1 Beginn-und Ende-Datum

3.2 Regelungen zur Verlängerung und Beendigung der Vereinbarung (ggf. auch

Regeln für eine vorzeitige Vertragsbeendigung)

Kundennutzen

Bezeichnung des Services

2. Freigabeinformationen (mit Ort und Datum)

2.1 Service Level Manager

2.2 Verantwortlicher Vertreter des Service-Kunden

3. Laufzeit des Vertrages

3.1 Beginn-und Ende-Datum

3.2 Regelungen zur Verlängerung und Beendigung der Vereinbarung (ggf. auch

Regeln für eine vorzeitige Vertragsbeendigung)

Strukturen SLA

Servicebasiertes SLA

Deckt einen Service ab, der für jeden Kunden in identischer Form erbracht wird

Kundenbasiertes SLA

Deckt alle Anforderungen eines Kunden oder einer Kundengruppe ab

Multi-Level-SLA

Bestmögliche Abdeckung von verschiedenen Anforderungen aus Unternehmenssicht kombiniert mit den verschiedenen bereitgestellten Services

Unternehmen, Kunde, Service

SLA / Anforderung definieren

SLA Inhalt

Bezeichnung des Services

Freigabeinformationen (mit Ort und Datum)

Service Level Manager

Verantwortlicher Vertreter des Service-Kunden

Laufzeit des Vertrages

Beginn- und Endedatum

Regelungen bezüglich Verlängerung und Beendigung der Vereinbarung (ggf. Regeln für vorzeitige Beendigung)

Beschreibung/ angestrebtes Kundenergebnis

Nutzen aus Geschäftssicht

Kundenseitige Business-Prozesse/ Aktivitäten, die vom Service unterstützt werden

Angestrebtes Ergebnis in Bezug auf Utility (Nutzen, z.B.: "Außendienstmitarbeiter haben jederzeit und von jedem Ort aus Zugriff auf die Unternehmensanwendungen xxx und yyy")

Angestrebtes Ergebnis in Bezug auf Warranty (Gewährleistung, z.B.: "Hohe Verfügbarkeit während Bürozeiten)

Kommunikation zwischen Kunde und Service-Provider

Verantwortliche Kontaktperson auf Kundenseite mit Kontaktdaten

Zuständiger Business Relationship Manager auf Seite des Service-Providers mit Kontaktdaten

Berichtswesen (Inhalte und Intervalle der vom Service-Provider zu erstellenden Service-Berichte)

Verfahren zur Behandlung von Ausnahmen und Beschwerden (z.B. im Falle einer Beschwerde bereitzustellende Informationen, vereinbarte Antwortzeiten, Eskalations-Prozedur)

Kundenzufriedenheits-Umfragen (Beschreibung Verfahrens regelmäßige Ermittlung Kundenzufriedenheit)

Service-Reviews (Beschreibung des Verfahrens regelmäßige Durchführen Reviews mit Beteiligung des Kunden)

Service- und Asset-Kritikalität

Liste unternehmenskritischer Assets in Zusammenhang mit diesem Service

Vital Business Functions (VBF, kritische Geschäftsprozesse), die von Service unterstützt werden

Sonstige kritische Assets, die im Rahmen des Services genutzt werden (z.B. bestimmte Art Geschäftsdaten)

Geschätzter Schaden für das Unternehmen durch Verlust des Services oder von Assets (ausgedrückt in finanziellen Beträgen oder unter Verwendung eines Klassifizierungsschemas)

Servicezeiten

Zeiten, zu denen der Service zur Verfügung stehen muss

Ausnahmen (z.B. Wochenenden, Feiertage)

Erforderliche Support-Typen und -Levels

Vor-Ort-Support (Bereich/Standort, User-Typen, Reaktions- & Lösungszeiten von Incidents

Remote Support

Bereich/ Standorte

User-Typen (User-Gruppen mit Zugang zum Service)

Zu unterstützende Anwendungen und Infrastrukturkomponenten

Reaktions- und Lösungszeiten (nach Prioritäten, Definition von Prioritäten z.B. für Einordnung von Incidents)

Service-Level-Anforderungen/ -Ziele

Verfügbarkeitsziele und -verpflichtungen

Bedingungen, unter denen der Service als nichtverfügbar gilt (z.B. falls der Service an verschiedenen Standorten erbracht wird)

Ziele im Hinblick auf Verfügbarkeit (genaue Festlegung der Art und Weise, wie die vereinbarten Availability Levels auf der Grundlage der vereinbarten Servicezeiten und Ausfallzeiten berechnet werden)

Ziele im Hinblick auf Zuverlässigkeit (von einigen Kunden gefordert, in der Regel definiert als MTBF (Mean Time Between Failures – durchschnittliche Zeit zwischen zwei Ausfällen) oder MTBSI (Mean Time Between Service Incidents – durchschnittliche Zeit zwischen zwei Service Incidents))

Ziele im Hinblick auf Wartbarkeit (von einigen Kunden gefordert, in der Regel definiert als MTRS (Mean Time to Restore Service – durchschnittliche Zeit bis zur Wiederherstellung des Services))

Downzeiten für Wartung (Anzahl erlaubter Downzeiten, Ankündigungsfristen)

Einschränkungen bei der Wartung, z.B. erlaubte Wartungsfenster, saisonale Wartungbeschränkungen und Verfahrensweisen bei der Ankündigung geplanter Service-Unterbrechungen

Definitionen von Major Incidents sowie Notfall-Changes und -Releases zur Behebung dringender Problemen, einschließlich Verfahrensweise bei der Ankündigungen ungeplante Serviceunterbrechungen

Anforderungen an das Availability-Reporting

Capacity/ Performance-Ziele und -Verpflichtungen

Benötigte Kapazität (Ober-/Untergrenze) für den Service, z.B. (Anzahl & Art von Transaktionen, Anzahl User/User Typen, Business-Zyklen (täglich, wöchentlich) & saisonale Schwankungen

Antwortzeiten der Anwendungen

Anforderungen an die Skalierbarkeit (Annahmen über die mittel- und langfristige Zunahme der Auslastung und Inanspruchnahme des Services)

Anforderungen in Bezug auf das Capacity- und Performance-Reporting

Verpflichtungen in Bezug auf Service Continuity (Verfügbarkeit des Services im Katastrophenfall)

Zeitraum, innerhalb dessen ein festgelegter Service Level wieder erreicht sein muss

Zeitraum, innerhalb dessen normale Service Levels wiederhergestellt sein müssen

Technische Standards/ Spezifikation der Service-Schnittstelle

Verpflichtende technische Standards und technische Spezifikation der Service-Schnittstelle

Verantwortlichkeiten

Pflichten des Service Providers

Pflichten des Kunden (Vertragspartner)

Verantwortlichkeiten der Service-Nehmer (z.B. in Bezug auf IT-Sicherheit)

IT-Sicherheitsaspekte, die bei der Nutzung des Services zu beachten sind (ggf. Verweis auf die entsprechenden IT-Sicherheitsrichtlinien)

Preismodell

Basispreis für die Serviceerbringung

Regelungen für Vertragsstrafen/ Rückverrechnungen

Change-Historie zu diesem Vertrag

Liste der Anhänge und Verweise

(z.B. auf eine mitgeltende SLA-Master-Vereinbarung)

Glossar

(falls erforderlich)

SLA – Verfügbarkeit

SLA Kennzahlen

maximale Dauer eines einzelnen Ausfalls (Verfügbarkeit: Ausfallzeit im Jahresdurchschnitt, auch Verfügbarkeitsklasse),

Mean Time to Repair (MTTR, mittlere Dauer der Wiederherstellung nach einem Ausfall)

Mean Time between Failure (MTBF, mittlere Betriebszeit zwischen zwei auftretenden Fehlern ohne Reparaturzeit), •

Mean Time to Failure (MTTF, siehe MTBF, wird jedoch bei Systemen/Komponenten verwendet, die nicht repariert, sondern ausgetauscht werden).

Service Delivery Zusammenfassung

Capacity Management

Ziel und Zweck

Sicherstellen der momentan vereinbarten und der zukünftigen Leistung zu wirtschaftlichen Bedingungen

Erstellung und Pflege eines angemessenen und aktuellen Kapazitätplanes, der die momentanen und zukünftigen Bedürfnisse des Business widerspiegelt

Bereitstellung von Informationen und Erstellung von Richtlinien für alle Bereiche des Business – die in Zusammenhang mit der IT stehen – zu leistungs-und kapazitätsabhängigen Fragen

Bereitstellung von Informationen und Richtlinien für sämtliche Kapazitäts-und Performance-Belange der IT und des Business

Gewährleisten einer wirtschaftlichen Erfüllung der vereinbarten aktuellen und zukünftigen Kapazitätsanforderungen an die IT Services.

Aufgaben

Anforderungen ermitteln, planen und steuern

Ressourcen zur Leistungserbringung bereitstellen

Leistung überwachen und Feinabstimmung durchführen

Verbesserungen zur Erreichung der vereinbarten Service Levels planen und durchführen

Kapazitätsplan erstellen und pflegen

Messbarkeit wie Antwortzeiten, Durchsatz und Qualität fixieren und einhalten

Basiskonzepte

Business Capacity Management (BCM)

Trend, Prognose, Modell, Prototyp, Grösse und Dokumentation der zukünftigen Geschäftsanforderungen an die IT Services

Service Capacity Management (SCM)

Monitoring, Analyse, Tuning und Bericht über die aktuelle Service Performance, Erstellung von Mindestanforderungen und Profilen für den Gebrauch von Services und die Regelung des Servicebedarfs

Component Capacity Management (CCM)

Monitoring, Analyse und Bericht über die Auslastung der verschiedenen technologischen IT-Komponenten, Erstellung von Mindestanforderungen und Profilen für den Gebrauch von Komponenten

Capacity Management Zusammenfassung

Availability Management

Ziel und Zweck

Erstellung eines angemessenen und aktuellen Verfügbarkeitsplans, der die momentanen und zukünftigen Anforderungen des Business and die Serviceverfügbarkeit abdeckt

Sicherstellung, dass die erreichte Serviceverfügbarkeit den vereinbarten Zielen (Bedürfnisse) entspricht oder über diese hinausgeht

Unterstützung bei der Diagnose und Lösung von Störungen und Problemen in Bezug auf die Verfügbarkeit

Untersuchung der Auswirkungen von Changes auf den Verfügbarkeitsplan sowie auf die Performance und Verfügbarkeit aller Ressourcen in den Services

Bereitstellung von Richtlinien und Anleitungen bezüglich der Verfügbarkeit

Basiskonzepte

Availability (Verfügbarkeit)

Fähigkeit eines Services, einer Komponente oder eines Configuration Items im Rahmen der vereinbarten Funktionalität zu arbeiten

Wird meistens in Prozent ausgedrückt

Serviceability (Servicefähigkeit)

Die Fähigkeit eines Drittanbieters, die Bedingungen einzuhalten

Umfasst den vereinbarten Umfang der Zuverlässigkeit und die Wartbarkeit oder Verfügbarketi eines Services

Reliability (Zuverlässigkeit)

Kontinuität, mit der ein IT Service angeboten werden kann

Die Zeit zwischen zwei Ausfällen eines IT Services sagt etwas über die Zuverlässigkeit dieses Services aus

Maintainability (Wartbarkeit)

Aufwendungen, die notwendig sind, um den operativen Betrieb eines IT Services sicherzustellen

Availability Management Zusammenfassung

Service Continuity Management

Lebenszyklus

Katastophenfall, worse case zenario

Ziel und Zweck

Erstellen von IT Service Continuity-Plänen, die den Business Continuity-Plan unterstützen

Vervollständigung regelmässiger Business Impact-Analysen, um sicherzustellen, dass alle Continuity-Pläne mit den sich ändernden Businessanforderungen übereinstimmen

Kommunikation und Aufrechterhaltung des Bewusstseins der Ziele innerhalb der unterstützten Geschäftsbereiche und IT Service Bereiche

Sicherstellung, dass entsprechende Continuity-und Recovery-Mechanismen umgesetzt werden, um die vereinbarten Business Continuity-Ziele zu erreichen

Verhandlung und Vereinbarung von Verträgen mit Zulieferern für die notwendige Erbringung von Leistungen zur Wiederherstellung

Unterstützen des übergeordneten Business Continuity Management (BCM) durch Gewährleistung der Wiederherstellung geschäftskritischer IT Services in schwerwiegenden Ausnahmesituationen zur Währung der Handlungsfähigkeit des Unternehmens.

Unterschiede

Business Continuity Management (BCM)

Beschäftigt sich mit dem Management von Risiken

Konzentriert sich auf die Kontinuität des allgemeinen Geschäftsbetriebes

Reduziert das Risiko auf ein akzeptables Niveau

Plant die Wiederherstellung der notwendigen Geschäftsprozesse und unterstützende Funktionen im Schadensfall

IT Service Continuity Management (ITSCM)

Ist ein Bestandteil des BCM-Prozesses

Legt den Fokus auf die Wiederherstellung der IT Services

Continuity Management Zusammenfassung

Supplier Management

Ziel und Zweck

Aushandeln und Vereinbaren von Verträgen mit Zulieferern (DRITTEN) und Verwaltung dieser über deren Lebenszyklus

Sicherstellen, dass Absicherungsverträge und Vereinbarungen mit Zulieferern den Anforderungen des Business entsprechen

Verwaltung von Lieferantenbeziehungen

Bewerten der Performance von Zulieferern

Verwalten von Richtlinien für Zulieferer sowie Aufbau und Pflege des Supplier and Contract Management Information Systems (SCMIS)

Gewährleisten, dass Leistungen externer Zulieferer auf die Geschäftsanforderungen abgestimmt sind und in der geforderten Qualität und zum vereinbarten Preis erbracht werden.

Basiskonzept

Supplier and Contract Management Information System (ISCMIS)

Eine Kombination von Tools, Daten und Informationen, die zur Unterstützung des Supplier Management genutzt werden.

Information Security Management

Ziel und Zweck

Vermeidung von Sicherheitsverletzungen durch ein klares und ganzheitliches Information Security Managements

Angemessene und planvolle Reaktion auf Sicherheitsverletzungen

Zusammenführung der Sicherheitsanforderungen und geschäftlichen Anforderungen

Erstellung des Security-Plans

Berücksichtigung von strategischen, taktischen und operativen Rahmenbedingungen

Gewährleisten des Schutzes von Assets, Informationen, Daten und IT Services bezüglich ihrer Anforderungen an Verfügbarkeit, Vertraulichkeit, Integrität und Authentizität.

Prinzipien

Confidentiality

Vertraulichkeit von Daten

Integrity

Integrität, Vollständigkeit und Richtigkeit von Daten

Availability

Verfügbarkeit von Daten

Inhalte Security Policy

Allgemeine Informationene

Regelung von Zugriff (Access control)

Remote-Zugangsregeln

Passwort-Umgang

E-Mail und Internet-Regeln

Anti-Virus-Strategie

Klassifizierungsregeln für Informationen und Dokumente

Regeln im Umgang mit Lieferanten

Vernichtungsverfahren und -vorgehen

Ergebnisse der Phase Design

Summary

Mean time Between Failures

Die durchschnittlich ausfallfreien Intervalle

Messgrösse, die für die Messung und Berichte in Bezug auf die Zuverlässigkeit eingesetzt wird.

Ist die durchschnittliche Zeit, während derer ein CI oder IT-Service mit der vereinbarten Funktionalität ohne Unterbrechnung betrieben oder bereitgestellt werden kann.

Mean time Between Service Incidents

Messgrösse, die für die Messung und Berichte auf die Zuverlässigkeit eingesetzt wird

Ist die durchschnittliche Zeit zwischen einem Ausfall eines Systems oder IT Service bis zum nächsten Ausfall

MTBSI entspricht MTBF+MTRS

Mean time to Repair (Durchschnittliche Zeit bis zur Reparatur)

Durchschnittliche Zeit, die für die Reparatur eine CI oder IT Service nach einem Ausfall benötigt wird.

Die MTTR wird ab dem Zeitpunkt des Ausfalls des CI oder IT Service bis zur Fertigstellung der Reparatur gemessen

Die MTTR umfasst nicht die Zeit, die zur Instandsetzung oder Wiederherstellung selbst erforderlich ist.

Wird manchmal fälschlicherweise anstelle von MTR verwendet

Service Management (ITIL) – Service Transition

Definition

Überführt kontrolliert neue und geänderte IT Services dazu notwendige Fähigkeiten in das Business und den operativen Betrieb

Sicherstellen, dass Services wie in Service Strategy und Service Design definiert in den operativen Betrieb überführt werden können.

Rollen: Change Manager, Change Advisory Board (CAB), Service Asset Manager, Configuration Manager, Configuration Analyst, Configuration Administrator, CMS/Tool-Administrator, Release and Deployment Manager, Release Packaging and Build Manager

Modell

Ziele

Planung und Managen der Ressourcen, die notwendig sind, um neue oder geänderte Services erfolgreich zu implementieren

Definition und Bereitstellung der Release- und Kommunikationspläne

Definition und Anwendung grundlegender Qualitätssucherungs- und Validierungsmassnahmen

Bereitstellung notwendiger Informationen über die Services bzw. Servicestrukturen für den operativen Betrieb

Nutzen

Bewertung aller Änderungen aufgrund der Businessanforderungen

Keine unnötigen Änderungen. Im Vordergrund stehen immer Kundenzufriedenheit uns Anwendungsproduktivität

Schnelle Umsetzung von Änderungen aufgrund wiederverwendbarer Verfahren

Hohe Erfolgsquote von Änderungen durch ständige Bewertung von Verbesserung der Qualität

Einhaltung der vereinbarten Service Level durch umfassende Abstimmungs- und Testaktivitäten

Vorteile

Einführung und Überführung von Release in die Produktivumgebung unter Berücksichtigung von wirtschaftlichen Aspekten

Management der Organisation und das kulturellen Wandels während des Überganges

Service Knowledge Management System im Rahmen der Unterstützung der lernenden Organisation

Steigerung der Kunden und Mitarbeiterzufriedenheit durch die Einführung und Nutzung der Service Transition Practices

Genaue Abschätzung der erforderlichen Zeit und Ressourcen

Bessere Steuerung der Service Assets

Genauere Vorhersagen von Utility & Warranty

Zunahme erfolgreicher Changes

Weniger Verzögerungen durch Changes

Bessere Steuerung der Erwartungen

Erhöhung des Vertrauens in Transition-Fähigkeiten

Zweck

Sicherstellen, dass neue, geänderte oder stillgelegte Services, die definierten Business-Anforderungen erfüllen

Sicherstellen, dass Services wie in Service Strategy und Service Design definiert in den operativen Betrieb überführt werden können

Prinzipien

Aufsetzen auf vorhandene Systeme und Verfahren

Nutzung von Standards, Best Practices und bestehenden Frameworks

Wiederverwendbarkeit sicherstellen

Kommunikation und Beziehungsmanagement

Verstösse sanktionieren

Wichtige Rollen

Change Manager

Verantwortlich für den täglichen Betrieb und die Einhaltung des Change Management-Prozesses

Sicherstellung, dass der Prozess und die Prozessaktivitäten überwacht werden und dass Verbesserungen/Aktualisierungen vorgenommen werden

Regelmässige Reviews des Change Management-Prozesses

Regelmässiges und präzises Reporting an das IT-Management und den Vorsitz

Zusammensetzung und Koordination der CAB-und ECAB-Meetings

Im Rahmen der Change Authority kann er die Kompetenz erhalten, Changes zu autorisieren

Change Advisory Board (CAB)

Gremium, das den Change Manager bei der Genehmigung der Changes einer hohen Kategorie unterstützt

Der Change Manager hat den Vorsitz des CAB

Die Zusammensetzung des Boards kann sich aufgrund der anliegenden Changes ändern

Emergency Change Advisory Board (ECAB)

Änderungsbeirat, der sicherstellt, dass kurzfristig notwendige Entscheidungen bezogen auf vorgeschlagene Änderungen getroffen und umgesetzt werden können

Ziel ist, die Kontrolle über Änderungen auch im Notfall aufrechtzuerhalten und auch hier die negativen Auswirkungen auf den produktiven Betrieb so gering wie möglich zu halten

Unterstützen des Change Managers bei der Evaluierung von Emergency Changes und beim Treffen der Entscheidung ob die Emergency Changes autorisiert werden sollen.

Prozesse

Unterstützen den gesamten Lifecycle

Change Management

Service Asset Management and Configuration Management

Knowledge Management

Die die Service Transition Phase stark unterstützen

Transition Planning and Support

Release and Deployment Management

Service Validation und Testing

Change Evaluation

Change Management

Ziel und Zweck

Steuerung aller Change über ihren gesamten Lebenszyklus, damit nutzbringende Changes mit minimalen Auswirkungen auf das Business und die IT-Services überführt werden können.

Antworten auf Änderungsanforderungen von Business und IT

Maximierung der Wertschöpfung

Minimierung von Incidents

Sicherstellung der korrekten Erfassung, Bewertung, Entscheidung aller Änderungsanfragen

Planung, Test, Implementierung, Dokumentation und Review aller Changes sicherstellen

Sicherstellen, dass das CMS aktuell ist

Optimieren des Risikos für das Business

Aktivitäten

Management von RfC

Autorisierung und Planung von Änderungen

Überwachung von Realisierung, Test, technische Freigabe und Implementierung

Qualitätskontrolle und Erfolgsnachweis

7 R’s

Raised – Wer will die Änderung? Wer hat die Änderung (Change) eingereicht?

Reason – Aus welchem Grund? Was ist der Grund für den Change?

Return – Was ist das Ziel/Ergebnis/Ertrag? Was passiert, wenn nichts passiert?

Risk – Welches Risiko besteht?

Resources – Welche Ressourcen sind notwendig?

Responsible – Wer ist verantwortlich für die Durchführung (Erstellung, Test und Einführung)?

Relationship – Gibt es Abhängigkeiten zu anderen Änderungen?

Change Kategorien

Normaler Change

Durchläuft alle Prozessschritte

Änderungen mit einer entsprechenden Komplexität

Übergreifende Koordination und Freigabeprozedur mit eventueller Einbindung des CAB notwendig

Standard Change

Freigabe wurde einmalig im Vorfeld vom CM gegeben. Er muss nicht alle Prozessschritte durchlaufen

Standardisierbare Änderungen, die häufig auftreten, ein geringes Risiko aufweisen und deren Auswirkungen definiert sind

Durchführung erfolgt nach einem vereinfachten Prozessablauf

Sind praktisch vorab genehmigt, sofern sie in der vorgegebenen Prozedur durchgeführt werden

Notfall Change

Änderung muss sofort umgesetzt werden

Änderungen, die kurzfristig und mit höchster Dringlichkeit notwendig sind

Die Durchführung erfolgt auf Basis klarer und kurzer Prozessstufen

Grundsätze und Verfahrensweise müssen vorhanden sein

Basiskonzepte

Service Change

Hinzufügen, Verändern oder Entfernen Services oder Servicekomponenten und der dazugehörigen Dokumentationen

Fokus auf Service Assets und Configuration Items

Change-Kategorien

Die Kategorisierung von Changes soll helfen, das richtige Mass an Bürokratie auf das Risiko Management von Changes anzuwenden

Die Priorität eines Changes wird anhand der Kombination von Auswirkung (Impact) und Dringlichkeit (Urgency) bestimmt und liefert ein Indiz dafür, mit welcher Geschwindigkeit und Gewichtung ein Change durchzuführen ist

Risikoanalyse

Risikostufen/Risikoklassen ermöglichen eine Bewertung und Beurteilung von Changes bezüglich deren Auswirkung auf den IT Service

Change Management Zusammenfassung

Service Asset and Configuration Management (SACM)

Ziel

ITIL Service Asset und Configuration Management stellt Informationen zu Configuration Items (Konfigurationselementen) bereit, die zur Erbringung von IT-Services erforderlich sind, einschließlich ihrer Beziehungen untereinander.

Management der Configuration Items (CI) über ihren gesamten Lebenszyklus

Definition und Steuerung der Bestandteile eines IT Services und der dazugehörigen Infrastruktur und Pflege der aktuellen Konfigurationsdaten

Einhaltung der Anforderung der Corporate Governance, die Assetbasis zu steuern, die Kosten zu optimieren und Änderungen bzw. Releases effektiv zu managen sowie Incidents und Probleme schneller zu lösen.

Tätigkeiten: Identifizierung von Cis, Aufzeichnung von Beziehungen zwischen Cis, Aufzeichnung und Steuerung virtueller CIs

Zweck

Hiermit wird ein Configuration Management System bereitgestellt, das neben den Configuration Items und deren Beziehungen auch eine erweiterte Sicht auf Daten wie Incidents, Problems, Known Errors und Changes zur Verfügung stellt.

Nutzen

Verbessertes Asset Management

Ganzheitliche Betrachtung der Service Assets

Geringeres Fehlerrisiko durch Changes

Effektivere Unterstützung der Anwender im Rahmen der Störungsbehandlung und bei der Ursachenanalyse

Einfachere Erfüllung gesetzlicher Verpflichtungen

Unterstützung des Budgetierungprozesses

Basis für Service Level Management und Service Catalogue Management

Prozess und Hauptaktivitäten von SACM:

Management und Planung

Configuration Identifizierung

Configuration Steuerung

Statusnachweis und Berichterstattung

Verifizierung und Audit

Configuration Manager - Prozessverantwortlicher

Der Configuration Manager stellt die für das IT Service Management notwendigen Informationen über Infrastruktur und Services (Configuration Items, CIs) bereit. Dazu bildet er die IT-Infrastruktur und die Verknüpfungen der darin enthaltenen Komponenten sowie der IT-Services in einem logischen Modell ab.

Service Asset

Damit ein Service überhaupt eine Wertschöpfung erreichen kann, ist das Zusammenspiel der richtigen Ressourcen (Finanzielles Kapital, Infrastruktur, Applikationen, Informationen und die Anzahl der Mitarbeiter) und die dazu passenden Fähigkeiten (Management, Organisation, Prozesse, Wissen und Erfahrung der Menschen) unabdingbar.

Die Assets eines Service Providers umfassen alle Elemente, die zur Erbringung eines Services beitragen können. Die beiden Haupttypen lauten Ressourcen und Fähigkeiten.

Basiskonzepte

Asset

Materieller oder immaterieller Vermögenswert in Unternehmen (z.B. Software, Computer, Server, Drucker, etc.)

Service Asset

Fähigkeiten und Ressourcen eines IT Providers, die direkten Einfluss auf die Wertschöpfung der Kunden Assets haben und damit die Performance der Kunden Assets und Organisation des Business wertbringend beeinflussen.

Configuration Item (CI)

Logische, eindeutige Konfigurationseinheit

Dient dem Management von IT Services

Ist in der CMBD abgelegt, diese ist Teil des CMS (Configuration Management Systems)

Die Aktualität und Zuverlässigkeit der Info zu CI, werden durch Integration in das Change und Releasemanagement gewährleistet

Configuration Management System (CMS)

Übergreifende Systemdimension (logisches Datenmodell), welche eine weiterführende Sicht auf die Daten liefert, die alle anderen ITSM-Prozesse benötigen

Beinhaltet alle Informationen über Cis bezüglich des definierten Umfangs.

Im CMS werden die Beziehungen zwischen den Servicekomponenten und den Incidents, Problems, Known Errors oder Changes gepflegt.

Configuration Model

Liefert ein Modell zu den Services, Assets und der Infrastruktur durch die Definition und Abbildung von Beziehungen zwischen den Configuration Items.

Definitive Media Library (DML)

Ein oder mehrere Standorte, an dem die endgültigen und genehmigten Versionen aller Software Configuration Items sicher gespeichert sind.

Die DML ist als einzelner logischer Speicherbereich definiert, auch wenn sie in verschiedenen Speicherorten aufgeteilt ist.

Aufbewahrt wird: Kopien von gekaufter Software, Kopien von intern entwickelter Software und Relevante Lizenz-Dokumentationen

Configuration Management Zusammenfassung

Knowledge Management

Ziel und Zweck

Bereitstellen von Perspektiven, Erfahrungen, Ideen und Informationen, und zwar:

Am richtigen Ort

Zur richtigen Zeit

Der richtigen Person

Die richtigen Informationen

Zur Unterstützung von Entscheidungen und der Serviceerbringung

Wer ist Abnehmer der Informationen?

Alle Service Prozesse, primär aber Operations

Aktivitäten

Entwicklung Knowledge Management

Erfassung und Pflege von Wissen

Wissenstransfer

Service Knowledge Management System

Rollen

Knowledge Manager

Beispiele: Wissen älterer MA ist nirgends niedergelegt. Dieses Wissen muss unbedingt gesichert werden

Transition Planning and Support

Ziele und Zweck

Neue oder geänderte Service in die Service Operation einführen (Koordination, wie kommt der neue Service in den operativen Betrieb)

Sicherstellen, dass neue oder geänderte Services effektiv in die Service Operation überführt werden

Planung und Koordinierung der benötigten Ressourcen

Festlegen der Rahmenbedingungen bezüglich Kosten sowie der Qualitäts-und Zeitkriterien

Identifizierung, Managen und Steuerung der Risiken der übergreifenden Aktivitäten in der Service Transition

Sicherstellen, dass alle involvierten und mit der Durchführung beauftragten IT-Bereiche den übergreifenden Standards und Prozessen folgen

Bereitstellung klarer und übergreifender Pläne, die es dem Kunden und dem Business ermöglichen, sich mit den Aktivitäten der Service Transition Phase abzugleichen

Aktivitäten

Festlegung einer Transition Strategie: Leitbild

Definition der Lebenszyklusphase für die Service Transition

Vorbereitung der Service Transition

Planung und Koordination der Service Transition

Bereitstellung von Unterstützung für die Service Transition

Fortschrittsüberwachung und Reporting

Schnittstelle zum Changemanagement

Release und Deployement Management

Ziel und Zweck

Planen und Steuern des Build, Test und Deployment von Releases

Liefern der neuen Funktionalität für das Business bei gleichzeitigem Schutz der bestehenden Services

Pläne definieren und abstimmen (mit dem Kunden)

Release Packages erstellen

Release Packages testen und ausliefern

Risikomanagement

Wissenstransfer

Management des Wandels (insb. organisatorischer Wandel)

Releases (Software) in DML einpflegen

Basiskonzept

Release

Umfasst mehrere Release Units

Bezeichnet einen oder mehrere Changes an einem IT-Service, deren Build, Test und Deployement gemeinsam durchgeführt werden.

Ein Release kann Changes an HW, SW, Dokumentation, Prozessen oder anderen Komponenten enthalten.

Release Unit

Komponenten eines IT Services, die üblicherweise im selben Release veröffentlicht werden

Umfasst in der Regel genügend Komponenten, um eine nützliche Funktion auszuführen

Umfasst einen Satz von neuen, geänderten und/oder unveränderten Configuration Items, die gemeinsam getestet und in die produktive Umgebung ausgerollt werden, um einen oder mehrere freigegebene Changes zu implementieren.

Release Package

Kann eine einzelne Release Unit oder ein strukturiertes Set von Release Units sein

Release-und Deployment-Modelle

Definieren Mechanismen, Prozeduren und Richtlinien, die sich auf die Grundlagen und Vorgaben des Service Designs beziehen

Service-V-Modelle

Grundlegendes Basiskonzept im Bereich der Service Transition-Phase

Umfassende Projektmanagement-Struktur für die IT Systementwicklung

Nutzen

Schnellere und effizientere Bereitstellung der Releases für die Kunden in der Produktivumgebung bei gleichzeitiger Kostenoptimierung

Sicherstellung, dass die Kunden und die User den neuen oder geänderten Service nutzen können

Verbesserung der Vorgehensweise für übergreifende Implementierung

Einführung und Überführung von Releases in die Produktivumgebung

Aktivitäten

Planung Releases / Deployements

Build und Test der Releases

Deployement des Release-Package

Review

Schnittstelle

Transistion und Planung und Support

Change Management

Service Operation

Rollen

Releasemanager

BigPicture Change- & Releasemanagement

Releasemanagement Zusammenfassung

Service Validation and Testing

Ziele und Zweck

Testen von Services während der Transition Phase. Sicherstellen, dass der Service den Businessanforderungen genügt. Sicherstellen, dass der vereinbarte Service und erwartete Mehrwert erreicht wird.

Sicherstellen, dass der neue oder geänderte Service den geforderten Business Value liefert und das Release Package entsprechend der Designanforderungen aufgesetzt wurde

Validierung des Services zum Nachweis, dass der Service die geforderte Performance unter Berücksichtigung der gesetzten Rahmenbedingungen liefert (Fit for purpose)

Sicherstellung, dass ein Service den definierten Leistungsparametern entspricht und auf Basis strukturierter Test die Stabilität in den Servicebereitstellung (Fit for use) gegeben ist

Nutzen

Steigerung der Servicequalität durch gezielte Test-und Validierungsmassnahmen

Reduzierung der Wahrscheinlichkeit möglicher Serviceunterbrechungen nach Produktivnahme bestimmter Release Packages und/oder Services

Einbindung der User durch deren Test und Abnahme auf Basis der Businessanforderungen schaffen die frühzeitige Akzeptanz

Durchführung von strukturierten und detaillierten Test-und Validierungsmassnahmen reduziert die Kosten der Nacharbeit und des Service Support

Rollen: Testmanager

Welches Modell kommt oft zum Einsatz?

V-Modell

Change Evaluation

Ziele und Zweck

Gewährleisten, dass beabsichtigte und unbeabsichtigte Auswirkungen und Folgen eines Service Changes bekannt, beurteilt und eingeschätzt sind.

Bereitstellen eines konsistenten und standardisierten Ansatzes zur Bewertung der Leistungsfähigkeit eines Service-Changes

Steuern der Erwartungen der Stakeholder

Bereitstellung vom richtigen und aussagekräftigen Informationen für das Change Management

Sicherstellen, dass Changes die Möglichkeit des Services nicht negativ beeinflussen und nicht ungeprüft in Operations überführt werden

Basiskonzepte / Deming Cycle

Aktivitäten

Verstehen der Folgen der Änderungen​

Messen der aktuellen Leistung​

Abgleich gegen vereinbarte Leistung​

Management der Abweichungen im Sinne der Kunden​

Zusammenarbeit mit weiteren ITIL-Prozessen/Schnittstellen

Changemanagement​

Projektmanagement​

Knowledge Management​

Asset und Configuration Management​

Rollen

Change Manager autorisiert und dokumentiert sämtliche Änderungen​

Change Advisory Board (CAB) bei weitreichenden Veränderungen​

Je nach Erfordernis wird eine Zusammenarbeit folgender Rollen notwendig

Anwendungssystem-Analytiker, Technischer Analyst, Configuration Manager, Projektmanager und Risikomanager

Summary

Service Management (ITIL) – Service Operation

498 / HK: 5.1+5.2. / Alles was man lernen muss S. 200 / Clavis-Map

Definition

Gewährleistet den möglichst ausfallsicheren Betrieb, Support und Unterhalt der Services. Damit wird die Wertschöpfung der Services für die Kunde sowie den Service Provider sichergestellt.

Koordination und Ausführung der Prozesse und Aktivitäten, die für die Bereitstellung und das Management von Services, gemäss vereinbarter Service Levels, für Anwender und Kunden aus dem Business erforderlich sind.

Zweck

Koordination und Ausführung der Prozesse und Aktivitäten, die für die Bereitstellung und das Management von Services, gemäss vereinbarter Service Levels, für Anwender und Kunden aus dem Business erforderlich sind.

Ziele

Koordination aller Aktivitäten, um den vereinbarten Service zu liefern

Permanentes Management und Support der vorhandenen Technik

Kontrolle, Steuerung und Durchführung der täglichen Prozesse

Informationssammlung und Analyse für die kontinuierliche Verbesserung des Tagesgeschäftes

Realisierung des Kundennutzens durch Betrieb und Support der Services und Servicekomponenten

Service Operation stellt sicher, dass die IT Services effektiv und effizient erbracht werden

Service Operation beinhaltet die Bearbeitung von Anwender-Anfragen und Erarbeitung von Problemlösungen ebenso wie die Erbringung von Betriebsaufgaben im laufenden Tagesgeschäft

Die in der Strategie definierten Ziele werden in der Service Operation durch den wertschöpfenden Betrieb realisiert

Sicherstellung der notwendigen reaktive und proaktive Aktivitäten

Nutzen

Wert für das Business

Qualifizierte Ausführung der operativen Prozesse und Service

Integration von Service und Infrastruktur zur Erzeugung des Customer Value

Sicherstellung von Betriebsbalance zwischen interner IT Sicht und externer Business Sicht

Service Operation stellt die Services bereit und betreibt die Services gemäss vereinbarten Service Leveln

Schneller und effektiver Zugriff auf Standardservices

Reduktion der Aufwände für Serviceunterbrechung

Lieferung von Daten für Serviceverbesserungen

Umsetzung der Vorgaben und Policies

Basis für Automatisierung und der damit verbundenen Steigerung der Effizienz und Kostenoptimierung

Prozesse

Event Management (Identifizieren)

Ziel und Zweck

Erkennen/Managen von Ereignissen

Das Event Management bildet somit die Basis für das operationelle Monitoring, die Steuerung und Automatisierung vieler Routineoperationen (z.B. für das Ausführen von Scripts)

Weiter stellt das Event Management einen Einstiegspunkt für zahlreiche operative Service Prozesse und Aktivitäten dar

Status Configuration Items

Die Fähigkeit, Events zu erkennen, Schlüsse aus ihnen zu ziehen und die angemessenen Kontrollmassnahmen zu bestimmen.

Anwendungsbereich

Event Management kommt in jedem Bereich der kontrolliert oder automatisiert werden soll zur Anwendung:

Configuration Items

Statusüberwachung (z.B. Router, Switch)

Systemänderungen (z.B. Updatestatus)

Überwachungssysteme (z.B. Rauch-oder Feuermelder)

Softwarelizenzüberwachung (z.B. Softwaremetering)

Sicherheitssysteme (z.B. Alarmanlagen)

Erkennung von Eindringungsversuchen

Auslöser

Event Management kann durch verschiedene Vorfälle initialisiert werden, mögliche Auslöser sind:

Fehler innerhalb eines automatisierten Prozesses

Fehler innerhalb eines Geschäftsprozesses, der überwacht wird

Fehler innerhalb eines definierten Performance Level

Fertigstellung eines automatisierten Jobs oder einer Aufgabe

Statusänderung an einer Komponente oder Datenbankeintrag

Zugriff auf eine Datenbank oder eine Applikation durch einen Anwender oder einen Prozess

Erreichung eines bestimmten, definierten (Schwell-)Werts (z.B. bei einem Speichersystem oder bei einer Datenbank)

Incident Management (schnelle Lösungen)

Ziel und Zweck

Wiederherstellung nach Incidents, Erarbeitung von Workarounds

Ziel des Incident Managements ist die schnellstmögliche Wiederherstellung eines Services und somit die Wiederherstellung der Arbeitsfähigkeit der Kunden und Anwender.

Dadurch soll sichergestellt werden, dass die Störung eine möglichst geringe Auswirkung auf das Business hat.

Das Incident Management behält die Verantwortung für einen Incident während seinem gesamten Lebenszyklus.

Umfang

Incident Management beinhaltet alle Störungen eines Services, der ihn beeinträchtigt oder beeinträchtigen kann, dies umfasst Störungen:

Die direkt vom Anwender gemeldet werden

Die vom Service Desk gemeldet werden

Die über eine Schnittstelle vom Event Management gemeldet werden

Von Technikern erkannt werden

Incident

Ein Incident ist ein ungeplantes Ereignis, das die Erbringung eines Services beeinflusst und eine Unterbrechung oder Beeinträchtigung der Qualität dieses Services zur Folge hat

Eine potentielle Störung eines Services (z.B. Ausfall eines Cluster-Knotens) ist ebenfalls ein Incident, auch wenn die Auswirkungen dieser Störung für die Anwender nicht direkt spürbar sind

Eskalation

Eine Eskalation ist eine Aktivität, bei der zusätzliche Ressourcen eingeholt werden, die erforderlich sind, um den Service Level Zielen oder Kundenerwartungen gerecht zu werden

Eskalationen können innerhalb aller Prozesse erforderlich sein, werden jedoch primär beim Incident Management oder den Problem Management angewendet

Es wird zwischen funktionaler Eskalation und hierarchischer Eskalation unterschieden

Funktionale Eskalation

Wenn eine Support-Einheit (z.B. der Service Desk) nicht in der Lage ist, einen Incident innerhalb der definierten Zeit zu lösen muss dieser an eine weiterführende Support-Einheit eskaliert werden.

Dies kann z.B. jede beliebige Second-oder Third-Level-Support-Einheit sein, die über spezielles Fachwissen verfügt.

Die Verantwortung für den Incident (Incident Ownership) bleibt nach ITIL®trotz funktionaler Eskalation immer beim First-Level, z.B. dem Service Desk.

Hierarchische Eskalation

«Hat ein Incident sehr schwerwiegende Folgen oder kann nicht schnell genug bearbeitet werden, so muss eine höhere hierarchische Stufe informiert werden, damit diese die Rahmenbedingungen zur Bearbeitung des Incident schaffen kann.

Hierarchisch wird eskaliert, sobald die IT-Organisation Gefahr läuft, einen vereinbarten Service Level zu verletzen.»

Incident Management Zusammenfassung

Incident Management - Prozess

Meldung einer Störung beim Help Desk

Incident Management Prozess

Störung wird indentifiziert und die Zeit wird im System festgehalten -> Ticket als 1. Rückmeldung an Nutzer

Ab diesem Zeitpunkt läuft dieReaktionszeit

Weitere Reaktionen können vereinbart werden, z.B. Benachrichtigung über den Status und das weitere Vorgehen nach einer Stunde

Die Reaktionszeit sagt nichts darüber aus, wann die Störung behoben wurde, das wäre die Wiederherstellungszeit

Problem Management (dauerhafte Lösungen)

Ziel und Zweck

Die Zielsetzung des Problem Managements liegt in der Verwaltung aller aufgetretenen Problemen, bis diese langfristig behoben sind.

Das Problem Management kümmert sich um den gesamten Lebenszyklus eines Problems.

Das Problem Management minimiert ebenfalls die Auswirkung, den auftretende Incidents und bestehende Probleme auf das Business haben.

Nachhaltige Behebung von Incidents

Die Zielsetzung des Problem Managements liegt in der Verwaltung aller aufgetretenen Problemen, bis diese langfristig behoben sind.

Das Problem Management kümmert sich um den gesamten Lebenszyklus eines Problems.

Das Problem Management minimiert ebenfalls die Auswirkung, den auftretende Incidents und bestehende Probleme auf das Business haben.

Problem

Die unbekannte Ursache von einem oder mehreren Incidents

Problem Management Zusammenfassung

Request Fulfilment (Bestellung)

Ziel und Zweck

Zweck des Request Fulfilments (Auftragserfüllung) ist die Bearbeitung von Service Requests der Anwender

Bereitstellung von Standarddienstleistungen (Standard Services) für welche ein vordefiniertes Verfahren existiert

Bereitstellung von Informationen für die Anwender über die Verfügbarkeit von Dienstleistungen und darüber wie diese zu beschaffen sind

Beziehen und Liefern der Komponenten von beantragten Standarddienstleistungen, wie z.B. Lizenzen oder Softwaremedien

Unterstützung mit generellen Informationen bei Beschwerden oder Kommentaren / Vorschlägen

Abwicklung aller Requests

Request-Modelle:

Eine grosse Anzahl der Service Requests kommen oftmals in identischer Form vor

Dadurch erfordern sie wiederholbares Handeln, um die vereinbarten Service-Levels zu erfüllen.

Um dies zu unterstützen, werden oftmals Request Modelle erstellt.

Diese sind vordefinierte Abläufe für spezifische Requests und stellen einen Standard Change dar.

Werden vordefinierte Fälle für Bestellungen abgebildet

Beispiele sind z.B. IMACS, Bestellung von Standardsoftware, etc.

Access Management (Zugreifen)

Ziel und Zweck

Das Access Management stellt den Anwendern einen Service zur Verfügung, indem den Anwendern der Zugriff auf diese Services gewährt wird.

Dabei bewilligt es autorisierten Anwendern das Recht, einen Service zu nutzen und unterbindet gleichzeitig den Zugriff für unautorisierte Anwender.

Es führt Vorgaben aus, durch das Information Security Management definiert worden sind.

Gewährung/Kontrolle von Zugriffen (Areal, Gebäude, Räumlichkeiten, mobiler Zugriff)

Das Access Management stellt den Anwendern einen Service zur Verfügung, indem den Anwendern der Zugriff auf diese Services gewährt wird.

Dabei bewilligt es autorisierten Anwendern das Recht, einen Service zu nutzen und unterbindet gleichzeitig den Zugriff für unautorisierte Anwender.

Es führt Vorgaben aus, durch das Information Security Management definiert worden sind.

Grundkonzepte:

Zugriff

Ist der Grad und das Ausmass einer Servicefunktionalität oder von Daten, auf die ein Anwender zugreifen darf

Identität

Informationen, die sich individuell unterscheiden und den Status innerhalb der Organisation prüfen

Die Identität eines Anwenders ist eindeutig dem Anwender zugeordnet

Rechte

Das aktuelle Umfeld, in dem ein User berechtigt ist, Zugriff auf einen Service oder eine Gruppe von Services zu erhalten und definieren das Ausmass des Zugriffs

Typische Rechte sind «lesen», «schreiben», «ausführen», «ändern», oder «löschen»

Services oder Servicegruppen

Die meisten Anwender nutzen nicht nur einen Service, Anwender, die ähnliche Rollen oder Funktionen inne haben, nutzen oft ähnliche Services

Anstatt Zugriff zu jedem einzelnen Service für jeden Anwender separat zu gewähren, ist es sinnvoll und effizienter, einzelnen Anwendern oder einer Gruppe von Anwendern Zugriff auf mehrere Services zur selben Zeit zu gewähren

Directory Services

Beziehen sich auf eine spezielle Art von Tool, das entsprechende Zugriffe und Rechte verwaltet.

Funktionen

Service Desk

zentrale Ansprechstelle (SPOC) für User,

bearbeitet Incidents und Requests, zentrale Koordinationsstelle

Primärer Ansprechpartner für Anwender bei Störungen, für Service Requests sowie für definierte Requests for Change

Eingangskanal für alle Belange der Anwender

Zentraler Ansprechpartner für Kunden

Zentrale Koordinationsstelle

Kommunikationsplattform für jegliche Art von Information für die Anwender

lokaler Service Desk

Zentraler Service Desk

Virtueller Service Desk

Technical Management

Liefert benötigtes detailliertes technisches Wissen und Ressourcen, um die IT-Infrastruktur zu betreiben (z.B. Server, Netzwerk, etc.)

Spielt eine wichtige Rolle beim Design, Testen, Release und bei der Verbesserung der IT Services

In vielen Unternehmen auch für ausgesuchte tägliche Aufgaben in der IT-Infrastruktur verantwortlich

Application Management

Verantwortlich für das Management der Applikationen über ihren gesamten Lebenszyklus

Unterstützt und betreibt die im Einsatz befindliche Applikationen

Spielt eine wichtige Rolle beim Design, Testen, Release und bei der Verbesserung von Applikationen

IT Operations Management

Verantwortlich für die täglichen operativen Aktivitäten

IT Operations Control

IT Operations Control, das primär im Schichtbetrieb tätigen Mitarbeitenden besetzt ist und sicherstellt, dass routinemässige Operationen durchgeführt werden. IT Operations Control führt auch zentralisierte Monitoring-und Steuerungsaktivitäten durch.

Facilities Management

Facilities Management bezieht sich auf das Management der physikalischen IT-Umgebung (z.B. Rechenzentren und Computerräume). In einigen Organisationen wurden viele physikalische Komponenten der IT-Infrastruktur extern ausgelagert und das Facilities Management überwacht die dazugehörigen Verträge.

Service Support Zusammenfassung

Rollen

Anwendungsbereich

Event Management kommt in jedem Bereich der kontrolliert oder automatisiert werden soll zur Anwendung:

Configuration Items

Statusüberwachung (z.B. Router, Switch)

Systemänderungen (z.B. Updatestatus)

Überwachungssysteme (z.B. Rauch-oder Feuermelder)

Softwarelizenzüberwachung (z.B. Softwaremetering)

Sicherheitssysteme (z.B. Alarmanlagen)

Auslöser

Event Management kann durch verschiedene Vorfälle initialisiert werden, mögliche Auslöser sind:

Fehler innerhalb eines automatisierten Prozesses

Fehler innerhalb eines Geschäftsprozesses, der überwacht wird

Fehler innerhalb eines definierten Performance Level

Fertigstellung eines automatisierten Jobs oder einer Aufgabe

Statusänderung an einer Komponente oder Datenbankeintrag

Zugriff auf eine Datenbank oder eine Applikation durch einen Anwender oder einen Prozess

Erreichung eines bestimmten, definierten (Schwell-)Werts (z.B. bei einem Speichersystem oder bei einer Datenbank)

Reaktiv/Proaktiv

Reaktiv:

Ist eine Organisation, die nicht aktiv wird, ehe sie von aussen dazu getrieben wird.

Proaktiv:

Komponenten überwachen (Monitoringtool)

Ist eine Organisation, die immer nach Wegen schaut, die aktuelle Situation zu verbessern.

Schaut ständig die interne und externe Umgebung an

Frisst Ressourcen; Kosten im Griff halten

Priorisierung

Auswirkung und Dringlichkeit

Priorisiert wird nach Dringlichkeit; wie schnell das Business eine Lösung benötigt und Auswirkungen z.B. wie viele Anwender betroffen sind.

Incident

Ein Incident ist ein ungeplantes Ereignis, das die Erbringung eines Services beeinflusst und eine Unterbrechung oder Beeinträchtigung der Qualität dieses Services zur Folge hat

Eine potentielle Störung eines Services (z.B. Ausfall eines Cluster-Knotens) ist ebenfalls ein Incident, auch wenn die Auswirkungen dieser Störung für die Anwender nicht direkt spürbar sind

Known Error (Bekannte Fehlerursache)

Der Zustand nach erfolgreicher Diagnose der eigentlichen Ursache eines ös, d.h. wenn die fehlerhafte Komponente (CI) identifiziert wurde und ein Workaround bekannt ist

Workaround

Umgehungslösung, bis Störung oder Problem endgültig beseitigt ist

Summary

Wiederherstellung eines Services

RPO

RTO

Service Management – Continual Service Improvement

Definition

Dient der kontinuierlichen Verbesserung des IT Service Managements und der Services durch Steigerung von Effizienz und Qualität und mittels Kostenreduktion

Rollen: Service Manager, CSI Manager, Service Owner, Reporting Analyst

CSI Modell

Prozesse

7 Step Improvement Process

Sicherstellung kontinuierlicher Verbesserung

Grundsatz

Man kann nicht managen, was man nicht steuern kann

Mann kann nicht steuern, was man nicht messen kann

Mann kann nicht messen, was man nicht definieren kann

KUZU, Anrufe etc. können gemessen werden

Ziele

Erarbeitung von Empfehlungen in jeder Phase des Service Lifecycle

Verbesserungen auf Basis übergreifender Betrachtungen

Monetäre Betrachtung

Verstärkte Betrachtung der Investition und Aufbau von Know-how und Soft Skills

Übergreifende Verbesserung der Qualität der Servicebereitstellung zur Unterstützung der Business-Prozesse

Nachweisbarkeit des Abweichungsgrades zwischen Anforderungen und den gelieferten Leistungen

Übergreifende Produktivitätssteigerung und Erhöhung der Effizienzpotenziale

Höhere Flexibilität für das Business durch klare und messbare Strukturen

Erhöhte Kundenzufriedenheit durch Qualitätskennzahlen gemäss Anforderung

Verbesserung der Wirtschaftlichkeit

Nutzen

Vorteile

Übergreifende Verbesserung der Qualität der Servicebereitstellung zur Unterstützung der Business Prozesse

Nachweisbarkeit des Abweichungsgrades zwischen Anforderungen und Delivery

Übergreifende Produktivitätssteigerung und Erhöhung der Effizienzpotenziale

Höhere Flexibiliät für das Business durch klare und messbare Strukturen

Erhöhte Kundenzufriedenheit durch Qualitätskennzahlen gemäss Anforderung

Improvement (Verbesserung)

Positives Ergebnis aus der Prozessleistung bzw. der Serviceerbringung

Beispiel: Reduzierung der Anzahl von fehlgeschlagenen Änderungen, die durch die Verbesserung eines etabliertes Change Management erreicht wird

Benefit (Vorteile)

Effekte, die durch die Verbesserungen erzielt wurden

Beispiel: Reduzierung der Anzahl von fehlgeschlagenen Änderungen hat dem Unternehmen CHF 310’000.-an Kosten für verlorene Produktivität und Nacharbeiten gespart

ROI –Return on Invest (Investitionsertrag)

Differenz zwischen dem erzielten Benefit und den Kosten, die verursacht wurden, um den Benefit zu erwirtschaften

Wird in der Regel in Prozent ausgedrückt

ROI ist ein Faktor, mit dem die Güte einer Investition ausgedrückt werden kann

Beispiel: Das Unternehmen hat CHF 200’000.-für die Etablierung eines Change Management Prozesses ausgegeben. Dieser Change Prozess hat dem Unternehmen im ersten Jahr eine Ersparnis von CHF 370’000.-gebracht. Der ROI war demnach CHF 170’000.-oder 85%

Baseline

Der dokumentierte und akzeptierte Ausgangspunkt für spätere Vergleiche und GAP-Analysen

In der Regel wird die erste Messung zur Baseline

Baselines gibt es für strategische Ziele, die Prozessreife (taktisch) sowie Metriken und Key Performance Indikatoren (operationell)

Configuration Baseline: erfasst die Struktur, Inhalte und Einzelheiten der Infrastruktur und stellt verschiedene Elemente dar, die miteinander in Zusammenhang stehen

PDCA-Cycle (Deming Cycle)

«Process Continuous Improvement Cycle»: Kontinuierlicher Kreislauf der Qualitätsverbesserung

Um Prozesse und Services mit einer entsprechenden Qualität zu designen und implementieren zu können, sind eindeutige Zielsetzungen und konkrete Vorstellungen bezüglich der erwarteten Ergebnisse erforderlich

Die Ergebnisse und die darüber hinaus möglichen Verbesserungen und Optimierungsansätze müssen nach einem strukturierten Verfahren kontrollierbar erzielt werden

Service Measurement

Aktivität CSI

Welche ist die erste Aktivität im Continual Service Improvement (CSI) Ansatz?

Vision und Ziele des Business verstehen.

Verbesserungsprozess

7-Stufen-Verbesserungsprozess beschreiben:

Ein Prozess der definiert, was gemessen wird, der Daten sammelt, der Daten verarbeitet und sie nutzt, um korrigierende Massnahmen zu treffen.

Summary

498 / HK: 1.2. / Alles was man lernen muss S. 22-46 / IT-Security Kap. 2.2-2.3

CMMI (Capability Maturity Model Integration )

= Reifegradmodell zur Beurteilung und Verbesserung der Qualität von Entwicklungsprozessen in Organisationen.

- Stärken & Schwächen einer Entwicklung werden objektiv analysiert, damit Verbesserungsmassnahmen bestimmt & in sinnvolle Reihenfolge gebracht werden können.

- gibt Überblick über bewährte Praktiken (z.B. in der Projektplanung)

- Wird im Wesentlichen zur Optimierung der Produktentwicklung genutzt

Die CMMI-Modelle sind Referenzmodelle, die bewährte Praktiken zusammenfassen:

- Produktentwicklung

- Produkteinkauf

- Serviceerbringung

Das Modelle Serviceerbringung ist in 4Kategorien eingeteilt:

- Projektmanagement

- Unterstützung

- Prozessmanagement

-Etablierung und Lieferung von Services

ISO 20000

'Die ISO/IEC 20000 IT Service Management dient als messbarer Qualitätsstandard für das IT-Service-Management (ITSM). Dazu werden in der ISO/IEC 20000 die notwendigen Mindestanforderungen an Prozesse spezifiziert und dargestellt, die eine Organisation etablieren muss, um IT-Services in definierter Qualität bereitstellen und managen zu können.

Dieses Modell basiert auf die Prozesse in ITIL-V2, und ergänzt diese um einen PDCA-Zyklus. Das kombinierte Modell wurde als Basis für ITIL-V3 genommen.

'Vorgaben sind dokumentiert, die ein Unternehmen einhalten, sicherstellen und nachweisen muss um die Zertifizierung zu erhalten.

Vorteil: Erhöhung Transparenz, Reduktion operativer Risiken, Erhöhung der Leistungsfähigkeit

Nachteil: Arbeitsaufwand durch interne Barrieren bei Einführung

COBIT

COBIT: «Control Objectives for Information and related Technology»

Framework für die Umsetzung von IT Governance, d.h.Steuerung und Kontrolle der IT

COBIT wurde ursprünglich vom internationalen Verband der IT Revisoren entwickelt

COBIT basiert auf den international anerkanntesten Standards, Frameworks und Best Practices (z.B. ITIL®, PMBOK oder ISO27000)

In COBIT werden die wichtigsten Ziele in einem übergeordneten Framework zusammengefasst

COBIT konzentriert sich dabei darauf was erforderlich ist, um eine angemessene Steuerung zu erreichen und nicht primär auf das wie

.

Ziele des Frameworks:

- Ausrichtung der IT auf das Kerngeschäft des Unternehmens: Verbindungen von Unternehmenszielen zu IT-und Prozesszielen
- Effiziente Unterstützung der Geschäftsprozesse durch die IT und damit verbundene Gewinnmaximierung
- Verantwortungsvoller Umgang mit IT Ressourcen und deren Absicherung
- Angemessenes Management von IT Risiken

Anforderungen:

Prince2

= PRojects IN Controlled Environments

- wurde als Standard der britischen Regierung für IT-Projektmanagement entwickelt.

- durch ständige Weiterentwicklung ist Standard heute nicht mehr nur für IT-Projekte verwendbar, sondern seit 1996 (PRINCE2) ein generischer Ansatz zum Management von Projekten jeglicher Art und Grösse

- Beinhaltet 4 grundlegende Elemente: Grundprinzipien, Themen, Prozesse, Beschreibung der möglichen Anpassung

- Das Projekt wird in kontrollierbare Phasen aufgeteilt

Folgende Punkte werden durch PRINCE2 sichergestellt:

• kontrollierter Start, kontrollierter Projektverlauf, kontrolliertes Projektende

• Fokus auf permanente Überwachung des Aufwandes und der Risiken

• definierte Organisationsstruktur

• flexible Entscheidungsmomente

• regelmäßige und planmäßige Fortschrittskontrolle

• automatische Korrekturmöglichkeit durch das Management bei Abweichungen vom Plan

• Commitment des Managements und der Projektbeteiligten im richtigen Moment und für die richtigen Themen

• gute Kommunikationskanäle zwischen den Projektverantwortlichen und der Organisation im Unternehmen

MSP

= Managing Successful Programmes (MSP)

- Leitfaden für Best Practices im Bereich Programm-Management

- bietet bewährtes Rahmenwerk für Umsetzung von Veränderungen/Erneuerungen mithilfe von Programm-Management (= Durchführung der koordinierten Organisation, Anordnung, Implementierung eines Portfolios von Projekten)

- breite Anwendung im öffentlichen & privaten Sektor

- Programm-Management-Ansatz bietet Organisation einen strukturierten Rahmen, denn Organisationen scheitern bei Umsetzung von Änderungen mit hoher Wahrscheinlichkeit, wenn:

• keine ausreichende Unterstützung des Senior Managements gewährleistet ist

• Führungskapazitäten fehlen

• Kapazität & Fähigkeit der Organisation zur Veränderung unrealistisch eingeschätzt wird

• die Erzielung der Vorteile nicht ausreichend im Vordergrund steht

• es keine reale Vorstellung der zukünftigen Kapazität gibt

• die Vision unzureichend definiert ist und schlecht vermittelt wird

• die Organisation nicht in der Lage ist, ihre Kultur zu verändern

• die Interessenvertreter sich nicht genug engagieren

498 / HK: 1.4. / Erläuterung aus Internet

Nachhaltigkeit

Mit der wachsenden Bedeutung von Informationstechnologien nimmt deren Einfluss auf Ökonomie, Ökologie und Gesellschaft zu. In Anbetracht steigender Kosten für Ressourcen und einer zunehmenden globalen Vernetzung sind nachhaltige Konzepte für das IT-Servicemanagement erforderlich. Während das Konzept der Nachhaltigkeit in anderen industrialisierten Branchen bereits seit Längerem verfolgt wird, fehlt es im IT-Servicemanagement, abgesehen von den eher technisch orientierten Maβnahmen im Rahmen einer »Green IT«, noch weitgehend an einer theoretischen und konzeptionellen Grundlage. Das Konzept der Nachhaltigkeit lässt sich in das IT-Servicemanagement als Vorgehensmodell übertragen. Möglichkeiten zur Integration von Nachhaltigkeitsaspekten des IT-Servicemanagements in eine IT-Balanced-Scorecard sowie in IT-Reifegradmodelle sind gegeben.