Service Management als Good Practice

Transkript

1 Service Management als Good Practice Definition eine Reihe von speziellen organisatorischen Fähigkeiten, mit denen Nutzen in Form von Services den Kunden zugeführt werden kann. 4 P s des Service Managements Partners Personen Prozesse Produkte (Supplier, Vertragspartner) (Kunden, Benutzer, IT-Mitarbeiter) (ITSM, ITIL) (Tools, Technologien) Die vier Hauptbereiche, die bei der Gestaltung eines effek tiven Service Management betrachtet werden müssen Service - Definition Service Management Gesamtheit des spezialisierten organisatorischen Fähigkeiten, die zur Generierung eines Mehrwerts für Kunden in Form von Services verfügbar sind Service Möglichkeit, einen Mehrwert für Kunden zu erbringen, indem das Erreichen der von den Kunden angestrebten Ergebnis erleichtert oder gefördert wird. Die Kunden selbst tragen keine Verantwortung für bestimmte Kosten und Risiken (Dienstleistung) IT Service Ein Service, der für einen oder mehrere Kunden von einem ITS-Provider bereitgestellt wird. basiert auf dem Einsatz der Informationstechnologie und unterstützt die Business-Prozesse der Kunden. (von den Mustern der Business-Aktivitäten getrieben) besteht aus der Kombination von Personen, Prozessen und Technologie und sollte in einem SLA definiert werden. Funktion, Rolle, Prozess Funktion Ein Team von Personen und Hilfsmittel, die eingesetzt werden, um einen oder mehrere Prozesse oder Aktivitäten durchzuführen (zb. Servicedesk) ( eigenständige Organisationseinheiten ) Rolle Ein Satz von Verantwortlichen und Aktivitäten und Kompetenzen, die einer Person oder einem Team zugewiesen sind wird von einer Person definiert. Einer Person oder einem Team können mehrere Rollen zugewiesen werden (zb. Incident Manager) Prozess eine Reihe koordinierter Abläufe, der Ressourcen und Fähigkeiten einführt und koordiniert, die zu einem Ergebnis führen direkt und indirekt wird ein Nutzen geschaffen, der einem externen Kunden dient (zb. Incident Management Prozess) (Wert für Stakeholder erzeugen) Prozess Manager Eine Rolle, die für das operative Management eines Prozesses verantwortlich ist. Verantwortlichkeiten: Planung und Koordination aller Aktivitäten, die zur Ausführung, Monitoring und Berichtserstellung in Bezug auf einen Prozess erforderlich sind. Mehrere Prozess-Manager möglich für einen Prozesse (zb. regionale Change Manager oder ITS Continuity Manager für jedes Rechenzentrum) wird häufig der Person zugewiesen, die bereits die Rolle des Process Owners hat In grösseren Organisationen oft auch separat zugewiesen

2 Prozessmodell Hilft, die unverwechselbaren Merkmale eines Prozesses besser zu verstehen ist eine Reihe strukturierter Abläufe zur Erreichung bestimmter Ziele nimmt eine oder mehrere Eingaben (Input) und wandelt sie in definierte Ausgaben (Output) um beinhaltet alle Rollen, Verantwortlichkeiten, Tools und Managementkontrollen, die benötigt werden, um zuverlässig die Ergebnisse zu liefern kann auch Richtlinien, Standards, Leitfäden, Arbeitsabläufe, Verfahren und Arbeitsanweisungen definieren oder revidieren Prozesseigenschaften Prozessdefinitionen beschreiben Abläufe, Abhängigkeiten und Abfolgen. Eigenschaften von Prozessen: messbare Grösse - sie sind leistungsunabhängig, GL will Kosten, Qualität und anderes messen, Fachleute hingegen Laufzeiten und Ertragsfähigkeiten bestimmte Ergebnisse - muss einzeln erkennbar und zählbar sein. Ein Service Desk ist deshalb eine Funktion, eine Change ein Prozess, da er zählbar ist. Kunden - liefert Hauptergebnisse an Kunden. Dieser kann innerhalb oder ausserhalb der Organisation sein, das Ergebnis muss aber den Erwartungen entsprechen entsprechen bestimmter Gegebenheiten - ein Prozess kann permanent oder sich wiederholend sein, sollte aber auf bestimmte Auslöser (Geschäftsfälle) zurückverfolgbar sein RACI Modell grundlegend darauf werden Rollen und Verantwortlichkeiten definiert. Verantwortlichkeiten definieren und dokumentieren ist eines der fundamentalen Prinzipien der Corperate Governance. RACI steht für: Responsible - zuständig für die Durchführung Accountable - Haftung (1x!), letztendlich verantwortlich für die Aktivität, Owner Consulted - Beratung muss/soll beteiligt werden, liefert Wissen und Information Informed - muss über den Fortschritt und Qualität informiert werden eine RACI Chart ist eine Tabelle, welche die Rollen und Verantwortlichkeiten bezogen auf das RACI Modell dokumentiert. Die Verantwortlichkeiten jedes Prozesses muss mit einem RACI-Chart dokumentiert werden. Governance und Business Case - Definitionen Governance Sicherstellen, dass Richtlinien und Strategien auch tatsächlich implementiert werden und die erforderlichen Prozesse korrekt eingehalten werden umfasst die Definition von Rollen und Verantwortlichkeiten, Massnahmen, Berichte sowie Aktionen zur Lösung aller identifizierten Anliegen Business Case Dokument mit einer Rechtfertigung für einen umfassenden Ausgabenposten (Investition). Beinhaltet Informationen zu Kosten, Nutzen, Optionen, offenen Punkten, Risiken und möglichen Problemen. Service Design - Balances Scorcard Balanced Scorecards stellen ein Managementsystem dar, dass einer immer grösser werdenden Anzahl von Unternehmen erlaubt, ihre Visionen und Strategien in Massnahmen zu verdeutlichen In Bezug auf interne Geschäftsprozesse liefern sie Feedback und externe Ergebnisse, um laufend Leistungsfähigkeit und Resultate zu verbessern. verschafft jedermann im Unternehmen ein Bild über die Leistungsfähigkeit des Unternehmens auf angemessenem Niveau Service Verbesserungen - vier geläufige Ausdrücke Verbesserungen - Resultat, das verglichen mit dem vorherigen Zustand, eine messbare Zunahme in einem erwünschten, eine messbare Abnahme in einem erwünschten Messsystem anzeigt Gewinne - durch Verbesserungen erreichte Erträge, die in der Regel aber nicht immer in Geldwerten ausgedrückt werden ROI - Differenz zwischen erreichtem Gewinn (Einsparung) und dem ausgegebenen Betrag, um diesen Gewinn zu erreichen (in Prozent) (Return on Investment)

3 VOI - Der Extrawert geschaffener Erträge, deren Gewinne aus nichtmonetären Werten oder langfristigen Ergebnissen bestehen (Value on Investment) ROI ist Bestandteil von VOI Service Knowledge Management System - Grundsätze STRATEGY im Fokus des Service Knowledge Management Systems (SKMS) Wissen wird an einen zentralen Ort in einem Ablagesystem oder Configuration Management System (CMS) und Configuration Management Database (CMDB) aufbewahrt SKMS ist ein breit gefächertes Konzept, das eine umfangreiche Wissensbasis abdeckt: - Erfahrungen der Belegschaft - Aufzeichnungen von Randthemen, zb. Wetter, Benutzernr., Verhalten, Unternehmenszahlen - Anforderungen, Fähigkeiten und Erwartungen an Supplier, Partner - typisches und erwartetes User Fachwissen-Niveau CMS ist Teil des SKMS Knowledge Management - Definition Der Prozess, der für die Sammlung, Analyse, Speichern und die gemeinsame Nutzung von Wissen und Informationen innerhalb einer Organisation verantwortlich ist Wichtigster Zweck ist eine gesteigerte Effizienz, indem bereits vorhandenes Wissen nicht erneut entwickelt werden muss Service Strategy Service Strategy Zweck und Ziel Um langfristig funktionieren und wachsen zu können, müssen sich Provider die Fähigkeit aneignen, auf strategisches Art und Weise zu denken und handeln Zweck der Service Strategy ist, Organisationen zu helfen, solche Fähigkeiten zu entwickeln die Errungenschaft strategischer Ziele oder Zielsetzungen erfordert den Gebrauch strategischer Vermögenswerte (Asset) Service Strategy zeigt auf, wie Service Management in einen strategischen Vermögenswert verwandelt werden kann Leser profitieren, indem sie Beziehungen zwischen verschiedenen Services, Systemen oder Prozessen sehen, die sie bewirtschaften gilt auch für die Geschäftsmodelle, Strategien oder Zielsetzungen, die sie unterstützen Fragestellungen Welche Services sollten wir wem anbieten? Wie unterscheiden wir uns gegenüber konkurrierenden Alternativen? Wie schaffen wir Nutzen für unsere Kunden? Wie können wir für unsere Anspruchsträger Werte schaffen? Wie schaffen wir Argumente für strategische Investitionen? Wie könnte das Finanzmanagement die Wertschöpfung kontrollieren und sichtbar machen? Wie sollten wir Service Qualität definieren? Wie wählen wir zwischen verschiedenen Wegen zur Optimierung der Service Qualität? Wie kontengieren wir effizient Ressourcen quer durch ein Service Portfolio? Wie lösen wir widersprechende Nachfragen nach gemeinsam genutzten Ressourcen? Grundlagen der Wertschöpfung mittels Services Wenn man den wirtschaftlichen Wert eines Services berechnet, kann es finanziell ausgedrückt manchmal kompliziert sein. In anderen Fällen ist es allerdings schwieriger, den Nutzen quantitativ zu bestimmen, obwohl es möglich ist, ihn genau zu beschreiben. Der Nutzen wird nicht nur streng nach der Begrifflichkeit der Geschäftsergebnisse des Kunden definiert: er ist auch in hohem Masse abhängig von der Wahrnehmung des Kunden. je immaterieller der Nutzen, desto wichtiger werden Bestimmung und Unterscheidung.

4 Kunden sind beim Kauf zurückhaltend, wenn es mangelnde Eindeutigkeit in der Ursachen und Wirkung Beziehung zwischen Gebrauch eines Service und der Realisierung von Nutzen gibt. Es obliegt dem Provider den Nutzen zu demonstrieren, Wahrnehmung zu beeinflussen und auf Vorlieben zu reagieren Marketing Denkweise STRATEGY was sind die Ergebnisse, die zählen? Wie werden sie in Bezug auf Kundenwahrnehmung und Vorlieben bestimmt und eingeordnet? Um diese Fragen erfolgswirksam beantworten zu können, braucht es eine Marketingdenkweise, die sich von den Denkweisen des Engineerings und Operations sehr unterscheidet. Statt seinen Blick nach Innen, auf die Produktion von Services zu richten, braucht es einen Blick von Aussen nach Innen, aus der Sicht des Kunden Die Marketingdenkweise beginnt mit einfachen Fragen: - Was ist unser Geschäft? - Wer sind unsere Kunden? - Was schätzt der Kunde? - Wer hängt von unserem Service ab? - Wie benutzen sie unsere Services? - Warum sind sie ihnen wertvoll? Utility und Warranty - Definition Aus der Sicht des Kunden setzt sich ein Mehrwert aus zwei grundlegenden Elementen zusammen: Utility (Nutzen oder Zweckmässigkeit) Eine Funktionalität, die von einem Produkt / Service angeboten wird, um einem bestimmten Kundenbedürftnis gerecht zu werden Utility beschreibt, was ein Produkt oder Service dem Kunden erbringt (=Nutzen) Warranty (Gewähr- oder Gebrauchstauglichkeit) Eine Zusage oder Garantie, dass ein Produkt / Service den vereinbarten Anforderungen entspricht. Warranty beschreibt, wie ein Kunde ein Produkt oder Service erhält (=Gewährleistung) Assets - Definition Bezeichnung für sämtliche Ressourcen oder Fähigkeiten (Kompetenzen) eines Unternehmens Die Assets eines Service Providers umfassen alle Elemente, die zur Erbringung eines Service beitragen können. Ressourcen und Fähigkeiten - Definition Ressourcen Ein allgemeiner Begriff, der die IT-Infrastruktur, Personen, Geld oder andere Elemente umfasst, die zur Erbringung eines ITS beitragen können. Ressourcen werden als Assets (Vermögenswerte) einer Unternehmung betrachtet. Beispiele: Personen, Informationen, Applikationen, Infrastruktur, finanzielles Kapital (siehe Grafik) Fähigkeiten (Kompetenzen) Die Fähigkeit einer Organisation, Person, Prozesses, Anwendung, Configuration Item oder IT Service zur Durchführung einer Aktivität Fähigkeiten gehören zu den nicht greifbaren Assets einer Unternehmung Beispiele: Management, Organisation, Prozesse, Knowledge, Personen (siehe Grafik)

5 STRATEGY Service Modelle beschreibt die Struktur und Dynamik eines Service, die von der Service Operation mittels Service Operation Plan geliefert wird. Servicemodelle beschreiben auch das Kräftespiel der Wertschöpfung: Aufgabenbereiche, Ressourcenfluss, Koordination und Interaktionen Service Provider - Definition eine Organisation, die einem oder mehreren internen oder oder externen Kunden Services zur Verfügung stellt. Service Provider wird häufig als Kurzform des Begriffs IT Service Provider verwendet. Service Provider Typ I interner Service Provider, der Teil eines Geschäftsbereichs ist. Innerhalb einer Organisation können mehrere Typ 1 Service Provider vorhanden sein. Service Provider Typ II ein interner Service Provider, der gemeinsam genutzte IT Services für mehr als einen Geschäftsbereich bereitstellt Service Provider Typ III Ein Service Provider, der IT Services für externe Kunden bereitstellt Service Strategy - Die vier Hauptaktivitäten 1. Definition des Marktes Services und Strategien den Kunden verstehen Chancen erkennen und verstehen Klassifizieren und visualisieren (Bsp: Sprache?)

6 (Bsp: Standardisieren?) (Bsp: wie geht man in Supportfall vor?) STRATEGY 2. Serviceangebot entwickeln der Markt ergebnisorientierte Definition von Services Serviceportfolio, Servicepipeline und Service Katalog 3. Strategische Assets entwickeln 4. Vorbereitung und Ausführung Service Portfolio - Definition Die Gesamtheit aller Services, die von einem Service Provider verwaltet werden wird für das Management des gesamten Lebenszyklus aller Services genutzt umfasst drei Kategorien: Servicepipeline (beantragt oder in der Entwicklung) Servicekatalog (Live oder bereit zum Deployment) Services ausser Betrieb verkörpert die Verpflichtungen und Investitionen eines Service Providers quer durch alle Kunden- und Marketingsegmente verkörpert gegenwärtige vertragliche Verpflichtungen, neue Entwicklungen von Services und Pläne zu fortwährender Verbesserung von Services. Service Portfolio Management Ziele ein wichtiges Instrument für das Management (IT Führung), um Entscheidungen zu treffen und folgende strategischen Fragen zu beantworten: Wie ist ein Service im Markt positioniert? Warum soll ein Kunde diesen Service bei uns einkaufen? Wie sehen die Preis- und Ausgleichsmodelle aus? Was sind unsere Stärken und Schwächen, was die Chancen und Risiken? (SWOT-Analyse) Wie können wir unsere Ressourcen und Fähigkeiten optimiert einsetzen um die die Services effizient und effektiv bereitzustellen? Basiskonzept Das Service Portfolio Management als dynamischer und fortwährender Prozess enthält folgende Aktivitäten: Definieren: ITS inventarisieren, Business Cases sicherstellen, Daten validieren Analysieren: Werterhaltung und Wertemaximierung der Services innerhalb des Portfolios, anpassen und priorisieren, Balance zwischen Angebot und Nachfrage sicherstellen Bewilligen: Vorgeschlagenes Portfolio bewilligen, Services und Ressourcen autorisieren Umsetzen: Entscheidungen kommunizieren, Ressourcen zuordnen, Services umsetzen Demand Management - Definition Aktivitäten, die sich mit dem Bedarf des Kunden an Services befassen und auf diesen Bedarf, sowie auf die Bereitstellung der Kapazität Einfluss nehmen, um diesen Bedarf gerecht zu werden Auf strategischer Ebene kann das Demand Management die Analyse von BusinessAktivitätsmustern und Anwenderprofilen einbeziehen. Auf taktischer Ebene kann es eine differenzierte Leistungsverrechnung einsetzen, um die Nutzung von ITS bei den Kunden zu Zeiten mit einer geringeren Auslastung zu fördern. Die Geschäftstätigkeit treibt die Nachfrage nach Services an (wie wächst das Geschäft? Wie bereite ich in der IT darauf vor?) Financial Management Ziele Business und IT können den Wert der ITS und der Service Assets finanziell quantifizieren Der Nutzen der IT kann dem Business aus finanzieller Sicher aufgezeigt werden Modelle Diese Begriffe sollte man zuordnen können: Service Valuation (Service Bewertung) direkte vs. indirekte Kosten

7 Service Design Service Design STRATEGY DESIGN Personalkosten variable Kostenelemente Zuordnung von Kostendetails zu Service Kosten Variable Cost Dynamics (Variable Kostendynamik) Kauf Ausgliederung Änderung Service Provisioning, Models & Analysis (Modelle und Analysen für die Servicebereitstellung) managed Service Beschaffung Shared Services Utility-based Provisioning (sehr effizient) On-Shore, Off-Shore, Near-Shore Service provisioning cost analysis Chargeback (Leistungsverrechnung) notional Charging (fiktive Verrechnung) tiered subscription (abgestufte Abo-Kosten) metered usage (gemessener Verbrauch) direct plus fix oder Userkosten Funding Model Alternative (Alternative Finanzierungsmodelle) rollende Planung Trigger basierter Plan Zero based funding (aktuelle Kosten eines Services) Zweck und Ziel Gestalten neuer oder zu ändernder Services bei allen Aspekten des Designs eine ganzheitliche Verfahrensweise anwenden wird ein Designelement verändert, müssen alle anderen Elemente berücksichtigt werden wenn eine neue Anwendung gestaltet und entwickelt wird, sollten auch die Auswirkungen auf den gesamten Service, den Managementsystemen und Tools berücksichtigt werden. Service Portfolio Service Katalog Service Management Prozesse Messungen und Metriken Nutzen Reduzierte Total Cost Of Ownership (TCO) Cost of ownership kann nur dann reduziert werden, wenn alle Aspekte von Services, Prozessen und Technologien genau gestartet werden und die nach Design eingeführt wird Verbesserte Service Qualität Services und operative Qualität werden verbessert Einfachere Einführung von neuen und geänderten Services Verbesserte Service Anpassung Mitwirkung von der Service Idee weg Verbesserte IT Governance Mitwirkung bei der Einführung und Kommunikation einer Reihe von Kontrollen zu einer effektiven IT Governance Effektiveres Service Management und IT Prozesse Prozesse werden kostendeckend qualitativ optimal gestaltet Verbesserte Information und Federführung Bessere Messwerte und Metriken führen zu besseren Entscheidungen und verbessern dauernd die Service Management Praxis in der Designphase des Lebenszyklus Umfang die Service Design Phase des Lifecycles beginnt mit einer Reihe neuer oder geänderter Geschäftsanforderungen und endet mit der Entwicklung einer Servicelösung, welche die dokumentierten Anforderungen des Unternehmens berücksichtigt

8 Diese entwickelte Lösung wird zusammen mit ihrem Service Design Package (SDP) der Service Transition (Lifecycle) übergeben, damit dieser den neuen oder geänderten Service bewerten, erstellen, testen und einsetzen kann. Nach Abschluss dieser Transationstätigkeiten wird die Kontrolle der Service Operation Phase des Lifecycles übertragen DESIGN Die 5 Haupt-Design-Aspekte Ein umfassende integrierende Herangehensweise sollte für die Design-Aktivitäten angewendet werden und folgendes umfassen: Service Solution Design Warranty + Utility Servicelösungen, inklusive aller funktionellen Anforderungen, Ressourcen und Fähigkeiten: erforderlich und bewilligt Service Portfolio Design sicherstellen, dass man das ganze managen kann Service Managementsystem und Tools, insbesondere das Service Portfolio für die Verwaltung und Kontrolle der Services während ihres Lebenszyklus Technology und Architektur Design aus Techn. und Architekturstrategie abgeleitet Technologiearchitekturen und Tools, die benötigt werden, um die Services bereitzustellen Prozess Design wie wird grundsätzlich ein neuer Service entwickelt? Prozesse, die benötigt werden, um Services zu entwerfen, überleiten, betreiben und zu verbessern Design der Messsysteme wie werden entsprechende Messungen durchgeführt? Messsysteme, Methoden und Messgrössen für die Services, die Architekturen und ihre einzelnen Komponenten und Prozesse Technologie und Architektur Design Es gibt zwei getrennte Herangehensweisen, um eine Managementarchitektur zu entwickeln: Wahl einer proprietären Management Architektur basiert auf der Wahl einer Reihe von Managementprodukten und Tools, welche von einem einzelnen proprietären Supplier von Managementlösungen stammt. Diese Herangehensweise erfordert üblicherweise weniger Anstrengungen, fügt sich in eine allumfassende Toolarchitektur ein Wahl einer Best of Breed Architektur bringt es mit sich, dass eine Reihe von Managementtools und Produkten aus einer Anzahl der besten ihrer Art ausgewählt werden müssen, die von einigen Lösungsanbietern offeriert werden. Die Tools müssen integriert werden, damit eine allumfassende Managementlösung zustande kommt Prozess Design ein Prozess ist eine Reihe strukturierter Abläufe zur Erreichung bestimmter Ziele ein Prozess nimmt eine oder mehrere Eingaben und wandelt sie in festgelegte aus Ausgaben um ein Prozess beinhaltet alle Rollen, Verantwortlichkeiten, Tools und Management-Steuerung, die benötigt werden, um zuverlässig die Ergebnisse zu liefern ein Prozess kann falls nötig Richtlinien, Standards, Leitfäden, Abläufe, Verfahren und Arbeitsanweisungen definieren oder revidieren Prozesskontrolle kann folgendermassen definiert werden: Das Planen und Anordnen eines Prozesses mit der Absicht diesen Prozess wirksam, einwandfrei und gleichbleibend auszuführen sobald Prozesse definiert werden, sollten sie dokumentiert und kontrolliert werden einmal unter Kontrolle, können sie wiederholt und bewirtschaftet werden es können Kontrollgrade definiert werden, damit Prozessbewertungen und Masseinheiten in den Prozess eingebaut werden können, um ihn mit Kontroll- und Verbesserungsabläufen zu verbessern Design der Messsysteme wenn du es nicht messen kannst, kannst du es auch nicht steuern damit Designprozesse verwaltet und kontrolliert werden können, müssen sie überwacht und gemessen werden. Dies gilt für alle Aspekte des Designprozesses. es sollten nur Messungen, die zur Erreichung von Geschäftszielen oder erwünschten Verhaltensveränderungen führen, ausgewählt werden In allen Designaktivitäten sollten folgende Anforderungen erfüllt werden: Lösungen entwerfen, welche fit for purpose sind Design für den angemessenen Level of Quality - nicht über- oder unterentwickelt Lösungen entwerfen, die sofort einsatzbereit sind und den erwartenden Zielen entsprechen

9 Lösungen bereitstellen, welche die Menge an Nacharbeiten oder Add-On s verringern Bereitstellen der Lösungen, die im Hinblick auf Geschäft und Kundschaft wirksam und leistungsfähig sind. Der Schwerpunkt sollte auf den Lösungen liegen, die erfolgreich sind und die innerhalb der Randbedingungen leistungsfähig bleiben. DESIGN Service Design Package Definition das SDP ist ein Satz von Dokumenten, in denen alle Aspekte eines ITS einschliesslich dessen Anforderungen für jede Phase des Lebenszyklus des ITS definiert sind. ein SDP wird neue IT Services, umfassende Changes und die Ausserkraftsetzung von ITS erstellt Inhalt Requirements - Beschreibung der Businessanforderungen Service Design - Beschreibung der neuen oder geänderten Funktionen, Service Level Requirement (SLR), Anforderungen aus dem Betrieb, technische Voraussetzungen Organizational Readiness Assessments - Nachweis des Businessnutzens und der Umsetzbarkeit Service Lifecycle Plan - Projektmanagement-Aufgaben, Service Transition Plan Service Katalog Definition eine DB oder ein strukturiertes Dokument mit Informationen zu allen operationell verfügbaren ITS, einschliesslich der Services, die für den Rollout (Deployment) verfügbar sind Der Servicekatalog ist der einzige Bestandteil des Serviceportfolios, der an die Kunden ausgehändigt wird. Er unterstützt den Vertrieb und die Bereitstellung von IT Services. Der Servicekatalog enthält Angaben zu Lieferergebnissen, Preisen, Bestellungen und Anfragen sowie Kontaktinformationen. der Servicekatalog ist die für den Kunden sichtbare Auswahl an Dienstleistungen und somit eine Teilmenge aus dem Serviceportfolio Service Katalog Management Ziele eine zentrale Datenquelle mit allen zurzeit für den Kunden verfügbaren ITS managen und bereitstellen. Hohe Qualität der Daten über produktive und sich in Planung befindlichen ITS sicherstellen Abläufe über Veränderungen dieser Daten festlegen, steuern und überwachen

10 DESIGN Rollen Ein Service Katalog Manager hat die Verantwortung für die Herstellung und Aufrechterhaltung des Service Katalogs. Dazu gehören Aufgaben wie sicherstellen, dass alle operativen und in der Vorbereitung befindlichen Services im SK erfasst sind dass alle Informationen innerhalb des SK korrekt und auf aktuellem Stand gehalten werden dass alle Informationen innerhalb des SK mit denjenigen im Service Portfolio im Einklang stehen dass die Informationen innerhalb des SK auf angemessene Weise geschützt und gesichert werden Ausprägungen Der Business Service Katalog: enthält Details über ITS, die dem Kunden zur Verfügung stehen, inklusive Beziehungen zu Geschäftseinheiten und ITS abhängigen Businessprozessen. Dies ist der Service Katalog aus Sicht des Kunden der technische Service Katalog: enthält Details über alle ITS, inklusive Beziehungen zu den unterstützenden und gemeinsam genutzten Services, Komponenten und CIs, die benötigt werden, um den Service dem Business zur Verfügung zu stellen. Diese sollte den Business Service Katalog untermauern und nicht Bestandteil der Kundensicht sein. Basiskonzept

11 Definition DESIGN Vereinbarungen und Verträge Service Level Agreement (SLA) eine Vereinbarung zwischen einem IT Service Provider und einem Kunden beschreibt den jeweiligen ITS, dokumentiert Service Level Ziele und legt die Verantwortlichkeiten des IT Service Providers und des Kunden fest. Ein einzelnes SLA kann mehrere IT Services oder mehrere Kunden abdecken. Operational Level Agreement (OLA) eine Vereinbarung zwischen einem IT Service Provider und einem anderen Teil derselben Organisation unterstützt die Bereitstellung von ITS durch den IT Service Provider für den Kunden definiert die zu liefernden Waren oder Services und die Verantwortlichkeiten beider Parteien Underpinning Contract (UC) Vertrag zwischen einem IT Service Provider und einer Drittpartei. Die Drittpartei stellt Waren oder Services zur Verfügung, die die Bereitstellung eines ITS für einen Kunden unterstützen definiert Ziele und Verantwortlichkeiten, um die in einem SLA vereinbarten Service Level Ziele zu erreichen. Service Level Agreement Multilevel SLA s Struktur erlaubt SLA s auf eine handhabbare Grösse zu halten verhindert unnötige Doppelspurigkeiten senkt Bedarf an häufigen Aktualisierungen besondere Anstrengungen, um innerhalb des Service Katalogs und des Configuration Managementsystems (CMS) die benötigten Beziehungen und Verbindungen aufrecht zu erhalten viele Unternehmen finden es wertvoll, Standards und eine Reihe von Vorlagen zu erstellen, die als Ausgangspunkt für alle SLA s, SLRs und OLAs verwendet werden können wenn man Standards und Vorlagen entwickelt hat, kann man gewährleisten, dass alle Vereinbarungen einheitlich entwickelt werden, was den anschliessenden Gebrauch, Betrieb und die Verwaltung erleichtert Ziel Definition, Pflege und Verbesserung der IT Services für den Kunden Aufbau von Beziehungen: mit IT Kunden zwischen funktionalen Gruppen innerhalb der IT Aufbau von Beziehungen mit der Gemeinschaft der Anbieter, welche die Dienstleistung für die IT bereitstellen Das Service Level Management ist mehr als nur ein SLA!

12 DESIGN Ebenen Ablauf Supplier eine Drittpartei, die für die Bereitstellung von Waren oder Services verantwortlich ist, die für die Erbringung von IT Services benötigt werden zu den Suppliern zählen u.a. Hardware- und Softwareanbieter, Netzwerk- und Telekommunikationsanbier oder Outsourcing-Organisationen

13 Definition DESIGN Supplier Management Der Prozess ist dafür verantwortlich sicherzustellen, dass alle Verträge mit Suppliern die Anforderungen des Business unterstützen und alle Supplier ihre vertraglichen Verpflichtungen erfüllen Es ist wichtig, dass Supplier Management Prozesse und Planung in allen Phasen des Service Lifecycle eingebunden sind. Von Strategie und Design, bis zum Übergang in den Betrieb und schliesslich zu Verbesserung. Um Übereinstimmung und Leistungsfähigkeit zu erreichen, sollten bei der Umsetzung der Richtlinien eine Supplier- und Vertragsdatenbank (Supplier and Contracts Database, SCD) zusammen mit klar definierten Rollen und Verantwortlichkeiten eingerichtet werden. Im Idealfall sollte der SCD ein integrierter Bestandteil eines umfassenden CMS oder SKMS bilden Umfang Einführung und Durchsetzung der Supplier-Richtlinien Pflege einer Supplier- und Vertragsdatenbank (SCD) Supplier- und Vertragseinstufung und Risikoüberprüfung Supplier- und Vertragsbewertung und Auswahl Entwicklung, Verhandlung und Vertragsvereinbarungen Vertragsrevision, Erneuerung und Auflösung Bewirtschaftung der Supplier und der Leistungsfähigkeit der Supplier Vereinbarung und Einführung von Services und Verbesserungsplänen für Supplier Pflege von Standardverträgen und allgemeinen Geschäftsbedingungen Bewirtschaftung von vertraglichen Konfliktlösungen Bewirtschaftung von nebenvertraglichen Suppliern Ziele etwas fürs Geld zu bekommen gewährleisten, dass UCs und Vereinbarungen mit Zuliefern auf die Businessanforderungen und auf die vereinbarten Ziele in den SLA s ausgerichtet sind Unterhalten der Beziehungen mit den Suppliern Leistungsvermögen der Supplier steuern können Verhandeln und Vereinbaren von Verträgen mit Suppliern und sie durch ihren Lebenszyklus führen Prozess

14 Delivery Modelle DESIGN Sourcing Ansätze und Optionen Partnerschaft oder Multisourcing offizielle Absprachen zur Zusammenarbeit zwischen zwei oder mehreren Organisationen zu Design, Entwicklung, Überleitung, Unterhalt, Betrieb und/oder Support von IT Services. Der Schwerpunkt hier neigt zu strategischen Partnerschaften, die auf entscheidendes Fachwissen oder Marktchancen eine Hebelwirkung ausübt Business Process Outsourcing (BPO) bei BPO geht es darum, bestimmte Geschäftsfunktionen oder Prozesse vollständig auszulagern, mit dem Ziel Kosten zu sparen. Beispiel: Buchhaltung, Servicedesk Der Prozess ist intern bekannt, bevor er outgesourct wird! Application Service Provider (ASP) Vereinbarung mit einem ASP, welcher IT-unterstützende Services (Applikationen) mittels Netzwerk für die gemeinsame Nutzung zur Verfügung stellt auf diese Weise angebotene Anwendungen werden zuweilen als On Demand Software oder Software as a Service bezeichnet Knowledge Process Outsourcing (KPO) neueste Form von Outsourcing, geht noch einen Schritt weiter als BPO, neben dem Prozesswissen wird dabei auch das Businesswissen ausgelagert hier ist der Prozess intern nicht unbedingt bekannt, bevor er outgesourct wird Capacity Management Nutzen Planned buying is cheaper than panic buying der Kapazitäts- und Ressourcenbedarf des Kunden ist im Voraus bekannt die Wahrscheinlichkeit für Kapazitätsengpässe wird reduziert die verfügbaren Ressourcen werden optimiert Capacity Management kann genaue Prognosen über den zukünftigen Bedarf erstellen (Trends) die Wirtschaftlichkeit der Leistungserbringung wird verbessert vermindertes Risiko von Performance-Problemen oder Ausfällen Ziel Bereitstellen der richtigen Kapazität an IT-Mitteln zu vertretbaren Kosten unter Berücksichtigung der bestehenden und künftigen Bedürfnisse des Kunden Sub-Prozesse Die drei Sub-Prozesse: Business Capacity, Service Capacity und Component Capacity Management Rollen Aufbau und Pflege der Capacity Management Datenbank Erstellen von Auswertungen und Berichten Erstellen von Kapazitätsplänen Überwachen des Bedarfs und der Business-Anforderungen Überwachen der Services - gegen SLA s prüfen Überwachen der Ressourcen Berechnen des Kapazitätsbedarfs Ermittlung der Kosten Bewertungen neuer Technologien Availability Fähigkeit eines Configuration Item oder IT Service, bei Bedarf die dafür vereinbarte Funktion auszuführen wird durch Aspekte in Bezug auf Zuverlässigkeit, Wartbarkeit, Servicefähigkeit, Performance und Sicherheit bestimmt wird in der Regel als Prozentwert (zb. 99.5%) ausgedrückt, der häufig basierende auf der vereinbarten Servicezeit und der Ausfallzeit berechnet wird

15 vereinbarte Servicezeit [h] Ausfallszeit [h] x 100 vereinbarte Servicezeit [h] Grundsätze DESIGN Availability [ %] = der Geltungsbereich des Availabilty Managements deckt Design, Einführung, Messung und Management der Availability von IT Infrastruktur und IT Services der Availability Management Prozess stellt fortwährend sicher, dass alle operativen Services verfügbar sind (SLA als Treiber) neue und veränderte Services angemessen in Bezug auf Availability gestalten Availability Management soll sowohl reaktiv als auch proaktiv tätig sein: Reaktive Tätigkeiten: der reaktive Aspekt des Availabilty Managements schliesst Überwachung, Messung, Analyse und Bewirtschaftung aller Ergebnisse, Zwischenfälle und Probleme mit ein, welche die Nichtverfügbarkeit verursacht. Diese Tätigkeiten betreffen hauptsächlich geschäftsbetriebliche Rollen Proaktive Tätigkeiten: die proaktiven Tätigkeiten des Availability Managements beinhalten proaktives Planen, Design und Verfügbarkeitsvergesserung. Diese Tätigkeiten betreffen hauptsächlich das Design und planerische Rollen Terminologie und Messgrössen Servicefähigkeit (Service Ability) Die Fähigkeit eines Drittanbieters, die Bedingungen eines Vertrages einzuhalten. Dieser Vertrag umfasst den vereinbarten Umfang der Zuverlässigkeit, Wartbarkeit oder Verfügbarkeit für ein Configuration Item Wartbarkeit (Maintainability) ein Mass dafür. wie schnell und effektiv der normale Betrieb für ein Configuration Item oder einen IT Service nach einem Ausfall wiederhergestellt werden kann. Die Wartbarkeit wird häufig als MTRS gemessen und berichtet. Der Begriff Wartbarkeit wird auch im Zusammenhang mit der Entwicklung von SW oder ITS verwendet und bezeichnet dann die Fähigkeit, ob ein Change oder eine Reparatur einfach durchgeführt werden kann Zuverlässigkeit (Reliability) Ein Richtwert, der wiedergibt, wie lange ein Configuration Item oder ITS seine vereinbarte Funktion ohne Unterbrechung ausführen kann. Wird in der Regel als MBTF oder MTBSI angegeben. Der Begriff Zuverlässigkeit bezeichnet auch die Wahrscheinlichkeit, dass Prozesse, Funktionen, etc. den gewünschten Output erzielen (siehe Verfügbarkeit) MTBF Mean Time Between Failure durchschnittliche Zeit zwischen zwei Ausfällen MTRS Mean Time to Restore Service durchschn. Zeit bis zur Wiederherstellung des Service MTBSI Mean Time Between Service Incidents MTTR Mean Time To Repair durchschn. Zeit zwischen zwei Service-Incidents durchschnittliche Zeit bis zur Reparatur

16 DESIGN IT Service Continuity Management (ITSCM) Ziel Vorsorge-Massnahmen treffen zur Vermeidung von katastrophenbedingten IT-ServiceUnterbrechungen bzw. schnelle Wiederherstellung der IT-Services nach der Katastrophe Nutzen Schutz / Erhaltung der Unternehmensprozesse Schnelle Wiederherstellung der Services Ununterbrochene Fortsetzung der Geschäftstätigkeit Erhaltung des Marktanteils Erhaltung der Rentabilität Minimierung des Gesichtsverlusts gegenüber Kunden Recovery Optionen Nichts tun kann für manche Services ein taugliches Mittel sein; kleines Risiko verbunden mit minimalem Einfluss auf Geschäftsprozesse, falls Risiko eintrifft Manuelle Umgehungslösungen (manual workaround) kann eine effektive Interimsmassnahme sein, aber manche Services können nicht auf diese Weise zur Verfügung gestellt werden

17 IT Infrastruktur steht an einem anderen Ort zur Verfügung, Parametrisierung fehlt (reciprocal arrangement) kann zb. für Printspooling und Offsite-Storage passend sein Voraussetzung: Nutzung von ähnlichen oder identischen Technologien Gradual Recovery (cold standby) vorbereitete IT_Umgebungsinfrastruktur, aber keine Computer-Ausrüstung. kann an einem festen Ort bezugsbereit sein oder mobil angefordert werden. Computersysteme müssen installiert und IT-Services darauf abgebildet werden. Zeitaufwändig Intermediate Recovery (warm standby) Computersysteme in einer vorbereiteten IT-Umgebung bereit zum Gebrauch. Setup der Systeme und Einspielen der Daten notwendig. Fast Recovery Systeme stehen parametrisiert zur Verfügung, Daten sind gespiegelt. Kurze Umschaltzeit notwendig. Immediate Recovery Dediziertes Computersystem überwacht kritische Business Systeme. Ist jederzeit bereit, bei einem Ausfall des Hauptsystems ohne Unterbruch und ohne Datenverlust die Stellvertretung zu übernehmen. Information Security Management Ziele Zweck ist die Angleichung von IT- und Unternehmenssicherheit mit folgenden Zielen: Informationen sind verfügbar und verwendbar, wo notwendig (Availability) Informationen stehen ausschliesslich autorisierten Personen zur Verfügung (Vertraulichkeit) Informationen sind vollständig, korrekt und vor unautorisiertem Zugriff geschützt (Integrität) Transaktionen und Informationsaustausch zwischen Firmen und Partnern sind verlässlich (Authentizität) Grundkonzepte Das Information Security Management und das Framework beinhalten folgende Grundkonzepte: Grundsätze der Informationsicherheit, Information Security System (ISMS) eine umfassende Sicherheitstrategie bezogen auf das Unternehmen wirksame Sicherheitsstrukturen und -steuerungsmittel Risiko Management Überwachungskonzepte Kommunikationsstrategie Schulungsstrategie Framework DESIGN

18 DESIGN Rolle Security Manager Der Security Manager hat dafür zu sorgen, dass die Ziele des Information Security Managements erfüllt werden. Dies beinhaltet Aufgaben und Verantwortlichkeiten wie: Information Security Policy entwickeln, pflegen, verbreiten und durchsetzen Identifizierung der zu schützenden IT Komponenten (CIs) für das Unternehmen (Security relevant) durchführen von Security Risk Analysen Unterstützung bei Business Impact Analysen Förderung der Bildung und Sensibilisierung von Security als zentrale Anlaufstelle für alle Sicherheitsfragen auftreten Service Transition Service Transition Zweck TRANSITION Security Controls Planen und Bewirtschaften der nötigen Kapazitäten und Ressourcen, um einen Release zu bilden, testen, packen (zusammenstellen) und produktiv anzuwenden Service aufbauen, der von Kunden und Anspruchsberechtigten vorgegeben ist Bereitstellen einer soliden Practice. Bevor ein neuer oder geänderter Change eingesetzt wird, sollen damit Service Fähigkeit und Risikoprofil ausgewertet werden Aufbau und Unterhalt der Vollständigkeit aller erkannten Services, Infrastrukturen und Konfigurationen, die während der Service Transition Phase entstehen Bildung wertvollen Wissens und nützlicher Informationen, damit das Change-, Release- und Deployment Management einen Release effektiv durch Test- und Produktivumgebungen befördern kann. gewährleisten, dass der Service bewirtschaftet, angewendet und unterstützt wird Ziele Kundenerwartungen dahingehend zu lenken, dass Gebrauch und Leistungsfähigkeit neuer oder geänderter Services zu betrieblichen Änderungen benutzt werden können Betrieblichen Änderungsprojekten oder Kunden ermöglichen, in ihren Geschäftsprozessen und Services einen Release zu integrieren In vorhergesagten und gegenwärtigen Leistungsverhalten Schwankungen der umgewandelten Services zu reduzieren Die bekannten Fehler reduzieren und die Risiken neuer und geänderter Services, die in die produktive Umgebung überleitet werden zu minimieren Gewährleisten, dass der Service in Übereinstimmung mit den Anforderungen und Einschränkungen genutzt werden kann, die in den Service Anforderungen festgelegt wurden

19 TRANSITION Nutzen Insbesonders liefert Service Transition dem Betrieb einen Mehrwert, indem: es die Fähigkeit sich adäquat neuen Anforderungen und Marktgegebenheiten anzupassen verbessert (Wettbewerbsvorteil) die betriebliche Erfolgsrate von Changes und Releases erhöht die Vorhersagen von Service Levels und Gewährleistungen für neue und geänderte Services verbessert werden das Vertrauen in den Einhaltungsgrad von Betrieb- und Geschäftsführungsanforderungen während eines Changes erfüllt werden es, wenn Komponenten ausser Betrieb gesetzt oder abgesetzt werden, Wartungsverträge für Softund Hardware rechtzeitig ändert oder kündigt es den Risikograd während und nach Changes, zb. Service Ausfälle, Unterbrüche und Nacharbeiten in Betracht zieht Configuration Item Alle Komponenten (Assets), die verwaltet werden müssen, um einen ITS bereitzustellen zu können Informationen zu den einzelnen CIs werden in einem Configuration Record innerhalb des Configuration Management Systems erfasst und über den gesamten Lebenszyklus hinweg vom Configuration Management verwaltet CIs unterstehen der Steuerung und Kontrolle des Change Managements CIs umfassen vor allem ITS, Hard- und Software, Gebäude, Personen und formale Dokumentationen, beispielsweise zum Prozess und SLA s Configuration Management System (CMS) Definition enthält Informationen zu Incidents, Problemen, Known Errors, Changes und Releases und kann auch Daten zu Mitarbeitern, Supplieren, Standorten, Geschäftsbereichen, Kunden und Anwendern beinhalten. umfasst Hilfsmittel zum Sammeln, Speichern, Verwalten, Aktualisieren und Präsentieren von Daten zu allen Configuration Items und deren Beziehungen untersteht der Zuständigkeit des Configuration Managements und wird von allen IT Service Management Prozessen eingesetzt Beispiel Beim Service Provider sind einige Elemente des Service Managements ausgegliedert, währende andere im Haus bleiben verschiedene Elemente können zu unterschiedlichen externen Supplieren outgesourct werden zb. könnten der Netzwerk- und Hardwaresupport vom Supplier A, Umgebung und Anlagen vom Supplier B und mehrere Anwendungssupplier und das Incident Management intern gehandhabt werden Der Servicedesk wird auf die Informationen im CMS zugreifen dieses System (CMS) wird seine Daten von getrennten Aufbewahrungsorten herleiten - jeder eine CMDB - Besitz und Unterhalt: von den drei Parteien, jedoch Zusammenarbeit, um einen alleinstehenden, aktuellen Datenbestand bereit zu stellen Definitive Media Library (DML) ein oder mehrere Standorte, an dem die endgültigen und genehmigten Versionen aller Software Configuration Items sicher gespeichert sind. kann darüber hinaus zugehörige CIs wie Lizenzen und Dokumentationen beinhalten ist als einziger logischer Speicher definiert, auch wenn auf verschiedene Speicherorte aufgeteilt die gesamte Software in der DML untersteht der Steuerung des Change und Release Managements und wird im Configuration Management System erfasst für einen Release ist ausschliesslich der Einsatz von Software aus der DML akzeptabel

20 TRANSITION Beziehungen zwischen DML und CMDB Change Management Ziel Changes wirtschaftlich, termingerecht und mit minimalen Risiken umsetzen (durch standardisierte Methoden und Verfahren) Angemessenes Reagieren auf die sich ändernden Kundenanforderungen und die Vermeidung von Störungen und Service Unterbrüchen Terminologien Der Anwendungsbereich vom Change Management umfasst Änderungen an Dienstleistungseinheiten, die während des gesamten Lifecycles auf einer Baseline und Configuration Items (CIs) basiert Backoutplan (Rollback) Change Types: Normal Change, Standard Change, Emergency Change Kategorien: Standard, Minor, Significant, Major RFC: Request for Change CS: Change Schedule CAB: Change Advisory Board, ECAB: Emergency Change Advisory Board Configuration Baseline PSO: Projected Service Outage (Verfügbarkeitszeit reduzieren) Service Change, Strategic Change, Tactical Change, Operational Change Change Authority ( CAB, bei Major und Strategic Changes: GL) Change Logging (RFC, zb. in Excel oder was auch immer) Project Initiation Document Nutzen Geringe Beeinträchtigung der IT durch die bzw. bei der Implementierung von Changes Zuverlässigere Kostenschätzungen weniger Betriebsunterbrechungen durch sinnvolle Zusammenfassung von Changes geringer Zahl fehlerhafter Changes bessere Kommunikation mit Kunden Stabilere Services Change - Definition Hinzufügen, Modifizieren oder Entfernen eines Elements inkl. Dokumentation, das

21 Auswirkungen auf die IT Services oder IT Service Komponenten haben könnte der Umfang eines Changes sollte sämtliche IT Services, Configuration Items, Prozesse, Dokumentationen etc. einschliessen Change Typen TRANSITION Normaler Change wird mit normalen Vorgehensweisen bearbeitet kein Standard-Change muss von einer Change Authority bewertet werden (zb. CAB) Standard Change wird nach einem bewährten Vorgehen abgewickelt ist akzeptierte Lösung für eine spezifische Anforderung (zb. PC Upgrade, neues Konto) die Aufgaben sind bekannt und dokumentiert die Bewilligung wird effektiv im Voraus erteilt die Serie von notwendigen Aktivitäten für den Change kann normalerweise vom Servicedesk initiiert werden Budgenehmigung sind typischerweise vorbestimmt oder innerhalb der Kontrolle des Change Requesters hat ein bewährtes und dokumentiertes Verfahren (Standardmodell) muss immer als normaler Change ein erstes Mal durch CAB bewertet werden Emergency Change (Notfall-Change) Changes, die zu dringend sind, um das normale Verfahren anzuwenden Prüfen und bewerten des Changes The 7 R s of Change Management Die folgenden Fragen müssen für alle Changes beantwortet werden. Ohne diese Informationen kann das Impact Assessment nicht abgeschlossen werden und das Gleichgewicht zwischen Risiko und Nutzen zum laufenden Service nicht verstanden werden. Dies könnte dazu führen, dass der Change nicht alle möglichen oder erwarteten Geschäftsnutzen liefert oder sogar eine nachteilige, unerwartete Auswirkung auf die laufenden Services hat: Who Raised the Change - wer hat den Change veranlasst? Reason - was ist der Grund für den Change? Return - was ist der Ertrag aus diesem Change? Risk - was sind die dem Change anhaftenden Risiken? Resources - welche Ressourcen braucht es, um diesen Change durchzuführen? Responsible - wer ist verantwortlich für den Aufbau, den Test und die Einführung des Changes? Relationship - was sind die Beziehungen zwischen diesem Change und den anderen Changes? Aufgaben Management von RFCs Planung und Freigabe von Changes Überwachung und Realisierung, Test und Implementierung von Changes Review aller implementierten Changes Kontrolle und Steuerung Prozess PIR kommt bestimmt an Prüfung!

22 Ziel die Vermögenswerte (Assets) eines Unternehmens, welches zur Erbringung von IT Services notwendig sind, dokumentieren und verwalten. Bei den Vermögenswerten spricht man auch von Configuration Items (CIs) Asset Management Beziehungen zwischen den CIs verwalten und deren Datenqualität sicherstellen Configuration Management TRANSITION Service Asset und Configuration Management (SACM) Hauptziel den IT Service Management Prozess umfassend unterstützen, indem akkurate Daten zur Konfiguration von Komponenten der Infrastruktur und IT Services den ITIL Prozessen zur Verfügung gestellt werden. Grundkonzepte (Konfigurationsmodell) Um ein unternehmensweites Verständnis für die Struktur und Abhängigkeit der Vermögenswerte (CIs) zu etablieren, ist ein zentrales logisches Konfigurationsmodell (Datenmodell) notwendig. Dies erlaubt es anderen Prozessen auf wertvolle Informationen zugreifen zu können, zb.: Abschätzen der Ursachen und Auswirkungen von Incidents und Problemen Abschätzen der Auswirkungen von beabsichtigten Changes Planen und gestalten neuer und geänderter Services Planen von Technologieerneuerungen und Softwareupgrades Planen von Releases und Migrationen Optimierungen von Vermögensgebrauch und Kosten, zb. Konsolidierungen Configuration Baseline Eine Configuration Baseline ist die Konfiguration eines IT Service oder einer Infrastruktur Komponente, die ausdrücklich geprüft und genehmigt wurde. Sie dient als Basis für weitere Arbeiten und kann nur mittels offizieller Änderungsverfahren verändert werden das Erstellen einer Baseline ermöglicht: einen Meilenstein im Service Design abzustecken Service Design Baseline Ändern oder Wiederherstellen einer bestimmten Version zu einem späteren Zeitpunkt Fallback Zusammenstellen aller relevanten Komponenten eines Changes oder Releases Service V Model ist ein Framework mit verschiedenen Ebenen, welches die über den Lifecycle entstehenden Configuration Items strukturiert zu jeder Ebene im Lifecycle wird die adäquate Verifikation und Test-Aktivität gegenübergestellt. Ziel ist es, dass jedes Ergebnis überprüft werden kann

23 eine Zusammenstellung von Hardware, Software, Dokumentation, Prozessen oder anderen Komponenten, die für die Implementierung eines oder mehrere genehmigter Changes an IT Services erforderlich ist. Die Inhalte jedes Releases werden als eine Einheit verwaltet, getestet und implementiert TRANSITION Release und Deployment Management Zweck und Ziel Release und Deployment Management übernimmt die entwickelten IT Services aus dem Service Design, testet und überführt sie in den produktiven Betrieb. Es werden folgen Ziele verfolgt: Changes mit so geringen Unterbrüchen wie möglich in die Produktion überführen Neue oder geänderte ITS schneller, günstiger und geringerem Risiko in die Produktion überführen Package Versionen sind untereiner und in bestehender Umgebung kompatibel Wissenstransfer zum Kunden gewährleistet Vorgehensweise der Einführung standardisieren und für die Nachverfolgbarkeit (Audits, Vorschriften) dokumentieren Release Unit ist eine in sich konsistente Einheit, die als Ganzes in die Produktion eingeführt wird enthält alle Komponenten eines ITS, die üblicherweise im selben Release veröffentlicht werden umfasst in der Regel genügend Komponenten, um eine nützliche Funktion auszuführen könnte zb. ein Desktop PC mit Hard-, Software, Lizenzen, Dokumentationen sein. Eine weitere Release Unit könnte die gesamte Anwendung für die Lohnbuchhaltung sein, einschliesslich ITBetriebsverfahren und Anwendertrainings Release Packaging and Build Release Packaging und Build Management beinhalten die Aktivitäten Aufbau, Planung, Entwicklung, Test, Implementierung, Betrieb und Optimierung, um neue oder geänderte ITS oder Infrastruktur Komponenten gemäss Anforderungen aus dem Service Design in die Produktion zu überführen. Aufgaben der Release Packaging und Build Manager sind: baut die endgültige Release-Konfiguration liefert die endgültige Version in die Produktion die letzten Tests vor der Lieferung unabhängiger Tests Definition von bekannten Fehlern und Workarounds liefert Input für die endgültige Umsetzung des Sign-Off-Prozesses Deployment Die Aktivität, die für den Übergang neuer oder geänderter Hard-, Software, Dokumentation, Prozesse etc. in die Live-Umgebung verantwortlich ist. Mitarbeiter, welche für das Deployment zuständig sind,

24 TRANSITION haben folgende Aufgaben: stellen die finale physische Lieferung der Service-Implementerierung bereit stellen Release Dokumentation, Kommunikation mit Kunden, einschliesslich Schulung, sicher stellen im gesamten Release Prozess die technische und applikatorische Beratung sicher, inklusive Known Errors und Workarounds Rückmeldung über die Wirksamkeit des Releases zeichnen für die Prüfung der SLA-Einhaltung Messwerte auf Early Life Support Support für einen Release für eine bestimmte Zeitspanne nach der Freigabe. Während des Early Life Supports kann der IT Service Provider die KPIs, Service Levels und Monitoring-Grenzwerte überprüfen und zusätzliche Ressourcen für das Incident- und Problem-Management bereitstellen. Mitarbeiter, welche für den Early Life Support zuständig sind, haben folgende Aufgaben: fördern Release Akzeptanz mittels rascher und nachhaltiger Unterstützung von Betrieb und Business (Kunde) behandeln anfallende Incidents und Probleme Überwachung und Aufzeichnung der Performance Daten anpassen und vervollständigen von Informationen aus der Erfahrung der ersten Nutzung, zb: Benutzer-Dokumentation Support-Dokumentation einschliesslich Known Errors und Workarounds OPERATIONS Grafik Folie 164 Service Operations Zweck und Ziele die Service Operations koordinieren und führen Aufgabenbereiche und Prozesse, die nötig sind, um Geschäftsnutzern und Kunden nach Leistungsverträgen Services zu liefern und zu bewirtschaften sind verantwortlich für die fortwährende Bewirtschaftung der Technologie, die zur Bereitstellung und den Support von Services gebraucht wird gut gestaltete und gut eingeführte Prozesse sind wenig wert, wenn der tägliche Betrieb diese Prozesse nicht sauber führt, kontrolliert und bewirtschaftet Nutzen es ist schwierig während der operativen Phase finanzielle Mittel aufzubringen, um Mängeln oder unvorhergesehenen Anforderungen nachzukommen, weil diese nicht Teil des Anschaffungswertes darstellen häufig kommen diese Probleme erst nach einer gewissen Zeit an die Oberfläche. die meisten Unternehmen besitzen keinen offiziellen Mechanismus, um operative Services auf Gestaltung und Nutzen zu überprüfen diese Angelegenheit wird dem Incident- und Problem-Management überlassen - als wenn dies lediglich ein operatives Problem wäre Rolle der Kommunikation in der Service Operation eine gute Kommunikation ist notwendig, wenn man mit anderen IT Teams und Abteilungen, mit Benutzern und internen Kunden interagieren will sie wird auch zwischen den Service Operation Teams und den Abteilungen selbst benötigt. Mit angemessener Kommunikation können Streitfragen oftmals vermieden oder entschärft werden. ein wichtiges Prinzip besteht darin, dass sämtliche Kommunikation einen Zweck oder eine sich daraus ergebende Handlung haben muss die Service Operations Prozesse: Incident Management Problem Management Access Management Event Management Request Management

25 OPERATIONS Die Sichtweisen Event Management der Prozess, der alle Ereignisse überwacht, die in der IT Infrastruktur geschehen, damit der normale Betrieb ablaufen kann. Er deckt auch ausserordentliche Zustände auf und eskaliert sie weiter das Event Management ist eine der wichtigsten Aktivitäten des IT Betriebs und wird typischerweise von Monitoringsystemen in Systemmanagement erzeugt Events werden dokumentiert, gefiltert und beurteilt. Je nach Beurteilung können dieses im Incident-, Problem- oder Change-Management Eingang finden Ziele erkennt, filtert und dokumentiert alle eingehenden Events der unternehmensweiten Systemlandschaft kann die Auswirkungen eines Events beurteilen und bedient den entsprechenden Folgeprozess (Incident-, Problem- oder Change-Management) mit den notwendigen Informationen konsolidiert mehrere Events, kann Häufigkeiten erkennen und leitet nach Bedarf den entsprechenden Prozess ein (zb. Incident Management) Löst automatisch oder initiiert manuelle Aktionen zu Behebung des Events aus Massnahmen aus den entsprechenden Prozessen auf deren Wirksamkeit überprüfen Event und Alert Event: eine Statusänderung, die für die Verwaltung eines Configuration Item oder ITS von Bedeutung ist bezeichnet darüber hinaus einen Alarm oder eine Benachrichtigung durch einen ITS, ein CI oder ein Monitoring Tool bei Events müssen in der Regel die Mitarbeiter des IT-Betriebs aktiv werden und häufig führen Events zur Erfassung von Incidents Alert eine Warnung, dass ein Grenzwert erreicht oder eine Änderung vorgenommen wurde bzw. dass ein Ausfall aufgetreten ist ein Alarm wird häufig über System Management Tools erstellt und verwaltet, die Verwaltung erfolgt im Event Management Prozess

26 OPERATIONS Prozess Incident Management der Prozess konzentriert sich auf die möglichst rasche Wiederherstellung des Service für den Benutzer, damit die Auswirkungen auf das Geschäft auf ein Minimum reduziert sind. der Prozess, der für die Verwaltung des Lebenszyklus aller Incidents verantwortlich ist. Incident Management Prozess 2. Dimension der Priorität Auswirkung (Impact) ein Mass für die Folgen eines Incidents, Problems oder Change auf die Business-Prozesse die Auswirkung basiert häufig darauf, inwieweit Service Levels betroffen sind mithilfe der Auswirkung und Dringlichkeit erfolgt die Zuweisung einer Priorität Dringlichkeit (Urgency) ein Wert, der wiedergibt, wie lange es dauert, bis ein Incident, Problem oder Change massgebliche Auswirkungen auf das Business hat ein Incident mit erheblichen Auswirkungen kann beispielsweise von geringer Dringlichkeit sein, wenn die Auswirkungen das Business bis zum Ende des Geschäftsjahres nicht beeinträchtigen auf der Grundlage der Auswirkung und Dringlichkeiten werden Prioritäten zugewiesen Priorität eine Kategorie, die verwendet wird, um die relative Wichtigkeit eines Incidents, Problems oder Change zu identifizieren basiert auf der Auswirkung und Dringlichkeit und wird eingesetzt, um den erforderlichen Zeitbedarf für die auszuführenden Aktionen zu ermitteln ein SLA x kann beispielsweise angeben, dass Incidents der Priorität innerhalb von 12 Stunden behoben werden müssen

27 Prio 1 Prio 2 Prio 3 Prio 4 4 Std Prio 5 SLA 1 15 Min 1 Std 2 Std 24 Std SLA 2 2 Std 4 Std 12 Std 48 Std SLA x 4 Std 12 Std 48 Std 10 Tage 30 Tage 10 Tage OPERATIONS SLA Auswirkung, Dringlichkeit und Priorität Incident Management Erfassen eines Incidents - Inhalte einzigartige Referenznummer Incident Einstufung (oftmals zwischen 2 und 4 Ebenen von Unterkategorien aufgeschlüsselt) Incident Dringlichkeit Incident Auswirkung Incident Priorisierung Erfasste Datum- und Zeitwerte Name/ID der Person und/oder Gruppe, welche den Incident erfasst Aufzeichnungsart (telefonisch, automatisch, , persönlich etc.) Name/Abteilung/Telefon/Standort der Benutzer Rückmeldungsmethode (Telefon, Mail etc9 Beschreibung von Symptomen Incident Status (aktiv, abwartend, geschlossen) Abfolge: zugehörige CIs Supportteam/Person, bei welcher der Incident zugewiesen ist - Identifikation zugehöriges Problem/Knwon Error - Logging - Kategorisierung unternommene Massnahmen zur Lösung des Incidents - Priorisierung Zeit und Datum der Lösung -... Abschlusskategorie Request Fulfilment der Prozess erledigt Service Requests von Benutzern mit unterschiedlichen Anliegen die Anliegen lösen tatsächlich kleine Changes mit kleinem Risiko (häufig vorkommend, kleine Kosten usw.) aus, welche aber nicht im Change oder Incident Management abgearbeitet werden müssen, um diese Prozesse nicht zu überladen Beispiele: Passwortrücksetzung, Installation zusätzlicher Anwendungen auf Desktop, Anfrage nach Informationen usw. Ziele bereitstellen eines Service Kanals für die Benutzer, damit sie Standard-Services über ein festgelegtes Eignungs- und Bewilligungsverfahren beantragen und erhalten können Benutzer und Kunden, Informationen über vorhandene Services aus dem Service Katalog

28 und die Bewilligungsverfahren für den Zugriff auf diese zur Verfügung stellen Komponenten der beantragten Standard Services (zb. Lizenzen, Software) beziehen, ausliefern. Incident und Change Management Prozesse von Kleinstaufträgen entlasten Rollen Service Requests werden üblicherweise zentral über die Funktion Servicedesk bearbeitet je nach Service Requests sind nebst dem Servicedesk unterschiedliche Funktionen und Rollen im Application Management und / oder Operation involviert OPERATIONS Service Request eine Anfrage eines Anwenders nach Informationen, Beratung, einem Standard-Change oder nach Zugriff auf einen IT Service dabei könnte es sich beispielsweise um das Zurücksetzen eines Passworts oder eine Bereitstellung standardmässiger IT Services für einen neuen Anwender handeln Service Requests werden in der Regel von einem Servicedesk bearbeitet und erfordern üblicherweise nicht die Einreichung eines RFC Problem Management bezieht Ursachenanalyse (Rootcause) mit ein, um die Ursachen von Ereignissen und Vorfällen zu bestimmen und zu lösen. Ergreift proaktive Massnahmen, um zukünftige Problems/Incidents (Probleme/Vorfälle) aufzuspüren und zu vermeiden ein Known Error Subprozess, der raschere Diagnose und Lösung erlaubt, wenn sich weitere Vorfälle ereignen. Prozess Unterscheidung das Problem Management besteht aus zwei hauptsächlichen Prozessen Reaktives Problem Management, das im allgemeinen als Teil der Service Operation ausgeführt wird Proaktives Problem Management, das von der Service Operation angeregt wird, aber im allgemeinen als Teil des Continual Service Improvements betrieben wird Workaround Workarounds für Probleme werden in Known Error Records dokumentiert Workarounds für Incidents, die nicht über zugeordnete Problem Records verfügen, werden in Incident Records dokumentiert. in einigen Fällen ist es möglich, für die von Incidents verursachten Probleme einen Workaround zu erarbeiten - eine provisorische Art, die Schwierigkeiten zu überwinden eine manuelle Ausbesserung zb. könnte an einem Inputfile vollzogen werden, um einer Anwendung zu ermöglichen, ihren Programmstart erfolgreich abzuschliessen und einem Fakturierungsprozess zu einem befriedigenden Abschluss zu verhelfen

29 in den Fällen, wo ein Workaround gefunden wurde, ist es deshalb wichtig, dass der Problemdatensatz offen bleibt und Details über den Workaround stets innerhalb des Problemdatensatzes aufgezeichnet werden Known Error OPERATIONS ein Problem, für das die zugrunde liegende Ursache und ein Workaround dokumentiert wurden das Problem Management ist verantwortlich für die Erstellung und Verwaltung von bekannten Fehlern während ihres gesamten Lebenszyklus bekannte Fehler können auch von der Entwicklung oder den Suppliern identifiziert werden Ablage in der Known Error Database schnellere Reaktion bei zukünftigen ähnlichen Incidents bzw. Problemen Known Error Database (KEDB) enthält sämtliche Records bekannter Fehler wird vom Problem Management erstellt und vom Incident- und Problem-Management eingesetzt ist Teil des Service Knowledge Management Systems KEDB Eigenschaften Sinn und Zweck ist das Aufbewahren von Vorkenntnissen über Incidents und Probleme und deren Bewältigung. Dies ist hilfreich, wenn es darum geht bei Vorkommnissen rascher zu diagnostizieren und zu lösen die Known Error Eintragung sollte über die vorgefallenen Symptome und Ausfälle genaue Details enthalten ebenso sollten ergriffene Workarounds und Lösungsvorgänge zur Wiederherstellung von Services gespeichert werden um den Lösungsprozess zu beschleunigen, sollte während Incident- und Problemdiagnosephasen die KEDB benutzt werden - und neue Eintragungen sollten so rasch wie möglich hinzugefügt werden, sobald ein neues Problem bestimmt und diagnostiziert wird sowohl die KEDB als auch die CMS stellen einen wesentlichen Teil des Service Knowledge Management Systems (SKMS) dar Incident eine nicht geplante Unterbrechung (Störung) eines ITS oder eine Qualitätsminderung eines ITS auch ein Ausfall eines Configuration Items ohne bisherige Auswirkungen auf einen Service ist ein Incident. Beispiel: Ausfall einer oder mehrere Festplatten in einer gespiegelten Partition Problem die Ursache für einen oder mehrere Incidents zum Zeitpunkt der Erstellung eines Problem Records ist die Ursache in der Regel unbekannt für die weitere Untersuchung ist der Problem Management Prozess verantwortlich Access Management der Prozess, der für die Zulassung der Nutzung von IT Services, Daten und anderen Assets durch Anwender verantwortlich ist das Access Management bietet Unterstützung beim Schutz der Vertraulichkeit, Integrität und Availability von Assets, indem sichergestellt wird, dass nur berechtigte Anwender auf die jeweiligen Assets zugreifen oder Änderungen an diesen vornehmen können das Access Management kann auch als Berechtigungs-Management (Rights Management) oder Identitäts-Manangement (Identity Management) bezeichnet werden via Access Management kommen Regeln und Massnahmen zur Anwendung, welche im Securityund Availability-Management definiert wurden Ziele den Zugang der Benutzer auf Assets via IT Services steuern und kontrollieren Regeln und Massnahmen aus dem Security und Availability Management durchsetzen Access Management stellt sicher, dass die Benutzer bedarfsgerecht (gemäss Userprofil) die nötigen Berechtigungen für die Nutzung von IT Services erhalten Access Management ist nicht verantwortlich für die Availability der IT Services

30 es ist wichtig, dass ein zentraler Access Management Prozess vorhanden ist Zugriffsanfragen auf IT Services sollten zentral über die Funktion Servicedesk gebündelt werden. Typischerweise werden solche Anfragen als Service Requests behandelt je nach Anfrage und Regeln aus dem Security Management sind unterschiedliche Funktionen um Application Management und/oder Operation im Access Management Prozess involviert OPERATIONS Rollen Service Operation Funktionen Ziel zentrale Schnittstelle zwischen den Benutzern und der IT befasst sich mit Störungen, Service Requests und Anfragen und stellt eine Schnittstelle für andere IT Service Aktivitäten dar überwacht die Einhaltung der Service Vereinbarungen mit dem Kunden Service Desk Basiskonzept Der Servicedesk bietet ein erweitertes Angebot von Services an und kann folgende Aufgaben lösen: Störungs-Abwicklung Anfragen Service Requests Reklamationen lokaler Service Desk an mehreren Orten, beim Anwender vor Ort teilweise redundant, was zu höheren Kosten führt einheitliche Verfahren, Eskalation, umfassendes Reporting, Personaleinsatz, Know-How-Austausch werden erschwert zentraler Service Desk an einem Ort für alle erreichbar senkt Betriebskosten und erleichtert den Personaleinsatz Aufwand grösser für die Koordination lokaler Einsätze virtueller Service Desk auf mehrere Orte verteilt, durch Kommunikationstechnik integriert senkt Betriebskosten und erleichtert den Personaleinsatz lokaler Service Desk zentraler Service Desk virtueller Service Desk Technical vs. Application Management Technical Management die Funktion, die für die Bereitstellung von technischem Fachwissen zur Unterstützung von ITS und für das Management der IT Infrastruktur verantwortlich ist

31 das Technical Management definiert die Rollen von Support-Gruppen sowie die erforderlichen Tools, Prozesse und Verfahren Application Management die Funktion, die für die Verwaltung von Anwendungen während ihres gesamten Lebenszyklus verantwortlich ist Bereitstellung von Fachwissen im APS-Bereich OPERATIONS IT Operation Management die Funktionen des IT Service Providers, die die täglichen Aktivitäten durchführt, welche zur Verwaltung von IT Services und Unterstützung der IT Infrastruktur erforderlich sind und beinhaltet: IT Operations Control die Funktion, die für das Monitoring und die Steuerung der ITS und IT Infrastruktur verantwortlich ist Facilities Management die Funktion, die für die physische Umgebung (Stromversorgungs- und Kühlungssystem, Access Management, Zutrittsrechte und die Umgebungs-Überwachung) verantwortlich ist, in der sich die IT Infrastruktur befindet. Service Operation Tools aus der Sicht der Service Operation wird unterschieden zwischen: Selbsthilfe (Online Help) Anfragen über Services sollten über ein Web-Frontend dem Benutzer zur Verfügung gestellt werden (FAQ). Servicedesk Organisationen können somit stark entlastet werden Workflow oder Prozess Engine für die Dokumentation, Steuerung und Kontrolle der Prozesse innerhalb eines Unternehmens sind Workflow-Systeme unerlässlich Discovery/Deployment/Licensing Technologie zur Unterstützung des Lizenzmanangements, Verteilung von Software-Komponenten und Ermittlung der ITInfrastruktur Remote Control ist ein sehr sinnvolles Hilfsmittel für den Servicedesk bei der Analyse von Störungen bei ArbeitsplatzSystemen. Der SD Mitarbeiter kann damit die Kontrolle (unter Berücksichtigung von Security-Richtlinien) des PCs des Benutzers übernehmen Diagnose Utilities ist sehr hilfreich für den Sevicedesk und andere Support-Organisationen, um den Zustand eines mit Fehlern behafteten Systems automatisch zu analysieren Reporting und Dashboards dabei handelt es sich generell um eine geeignete Darstellung von Informationen. Bei Dashboards geht es in erster Linie um eine übersichtliche Darstellung von Echtzeit-Informationen (zb. Systemüberwachung oder das Management) MoSCoW Analysis M MUST have this S SHOULD have this if at all possible C COULD have this if it does not affect anything else W WON T have this time but WOULD like in the future

32 CSI Continual Service Improvement Continual Service Improvement Zweck Hauptzweck ist das ständige Ausrichten und Wiederausrichten der IT Services an die sich verändernden Geschäftsbedürfnisse dabei werden Verbesserungen an Geschäftsprozess unterstützenden IT Prozessen erkannt und eingeführt Diese Optimierungsarbeiten unterstützen die Herangehensweise des Lifecycles mittels Service Strategy, Service Design, Service Transition und Service Operation. sucht nach Möglichkeiten, die Wirksamkeit und Leistungsfähigkeit, als auch die Wirtschaftlichkeit zu verbessern Zu Beachten: Messungen und Betriebsführung: - man kann nicht bewirtschaften, was nicht kontrolliert werden kann - man kann nicht kontrollieren, was man nicht messen kann - man kann nicht messen, was man nicht definieren kann Ziele Bewerten, Analysieren und Empfehlen von Verbesserungschancen in jeder Lifecycle-Phase: Service Strategy, Service Design, Service Transition und Service Operation Bewerten und Analysieren von Ereignissen zur Aufrechterhaltung von Service Levels Bereitstellen von IT Services mit verbessertem Kostennutzen, ohne Verluste von Kundenzufriedenheit Sicherstellen, dass anwendbare Qualitätsmanagement-Methoden benutzt werden, um fortwährende Verbesserungsmassnahmen zu unterstützen Deming Cycle Bedeutung Der Deming-Zyklus ist für das CSI an zwei Stellen entscheidend: Einführung von CSI Anwendung von CSI auf Services und Service Management Prozesse

33 CSI Verbesserung von Services und Service Management Prozessen CSI CSI Vorgehensweise Ziele Der 7-stufige Verbesserungsprozess Geschäftsnutzen 4 Gründe für Überwachung und Messung Plausibilisieren überwachen und messen, um vorangegangene Entscheide zu plausibilisieren Lenken überwachen und messen, um eine Richtung für die Arbeitsbereiche zu geben, damit die gesetzten Ziele erreicht werden. Es ist der vorherrschende Grund für die Überwachung und Messung Rechtfertigen überwachen und messen, um mit sachbezogenen Beweisen oder Beweismitteln zu rechtfertigen, dass eine Vorgehensweise benötigt wird Eingreifen überwachen und messen, um einen Interventionspunkt mit den nachfolgenden Änderungen und Korrekturmassnahmen zu bestimmen.