Aus ALM- (Asset & Liability Management) Überlegungen …roger-wiesendanger.ch/files/studiportal/ZF SLAM.pdf · SLAM Eidg. Dipl. Wirtschaftsinformatiker INHALTSVERZEICHNIS 1. Service

Zusammenfassung SLAM Autor: Marco Storchi & Roger Wiesendanger Version ZF SLAM 030405 / Benutzer

SLAM Eidg. Dipl. Wirtschaftsinformatiker

INHALTSVERZEICHNIS

1. Service Level Management 5 1.1 ITIL-Modell (IT Infrastructure Library) ...........................................................................5

1.1.1 ITIL-Prozesse.........................................................................................................6 1.1.2 Vor- / Nachteile zur Einführung von ITIL ................................................................7

1.2 Incident Management / Zwischenfall.............................................................................8 1.2.1 Definition Incident...................................................................................................8 1.2.2 Beispiele für Incidents ............................................................................................8 1.2.3 Ziele des Incident Management .............................................................................8 1.2.4 Aufgaben des Incident Management......................................................................8 1.2.5 KPI, Kennzahlen für das Incident Management .....................................................8 1.2.6 Definitionen Incident/Problem/ Fehler ....................................................................8 1.2.7 Incident Management Prozess...............................................................................8 1.2.8 Attribute eines Incident Records ............................................................................9 1.2.9 Schnittstellen zu anderen Prozessen ...................................................................10 1.2.10 Organisatorische Einbettung des Incident Management....................................10 1.2.11 Kritische Erfolgsfaktoren ....................................................................................10 1.2.12 Nutzen des Incident Management......................................................................10

1.3 Problem Management...................................................................................................11 1.3.1 Ziele des Problem Management ..........................................................................11 1.3.2 Aufgaben des Problem Management...................................................................11 1.3.3 Nutzen des Problem Management.......................................................................11 1.3.4 KPI, Kennzahlen für das Problem Management ..................................................11

1.4 Configuration Management..........................................................................................13 1.4.1 Ziele des Configuration Management ..................................................................13 1.4.2 Aufgaben des Configuration Management...........................................................13 1.4.3 Nutzen des Configuration Management...............................................................13 1.4.4 KPI, Kennzahlen für das Configuration Management ..........................................13 1.4.5 Attribute für ein Configuration Item.......................................................................14 1.4.6 Schnittstellen zu anderen Prozessen ...................................................................14

1.5 Change Management....................................................................................................15 1.5.1 Ziele des Change Management ...........................................................................15 1.5.2 Aufgaben des Change Management....................................................................15 1.5.3 Typen von Changes .............................................................................................15 1.5.4 Zusammensetzung des Change Advisory Board .................................................15 1.5.5 Gründe für RFC‘s .................................................................................................15 1.5.6 Change Management Prozess.............................................................................16 1.5.7 Attribute eines RFC’s ...........................................................................................17 1.5.8 KPI, Kennzahlen für das Change Management ...................................................17 1.5.9 Nutzen des Change Management........................................................................17

1.6 Release Management ...................................................................................................18 1.6.1 Ziele des Release Management...........................................................................18 1.6.2 Aufgaben des Release Management ...................................................................18 1.6.3 Unterschiedliche Releasetypen............................................................................18 1.6.4 Software Library (DSL)/ Hardware Store (DHS)...................................................18 1.6.5 KPI, Kennzahlen des Release Management........................................................18 1.6.6 Nutzen des Release Management .......................................................................19 1.6.7 Herausforderungen des Release Management ...................................................19

1.7 Service Level Management ..........................................................................................20 1.7.1 Aktivitäten des Service Level Management .........................................................20 1.7.2 Beziehungen des SLM zu anderen Prozessen ....................................................21

1.8 Availability(Verfügbarkeit) Management.....................................................................22 1.8.1 Ziele des Availability Management.......................................................................22 1.8.2 Aufgaben des Availability Management ...............................................................22 1.8.3 KPI, Kennzahlen des Availability Management ....................................................22 1.8.4 Nutzen des Availability Management ...................................................................22

1.9 Capacity Management ..................................................................................................23 1.9.1 Ziele des Capacity Management..........................................................................23 1.9.2 Aufgaben des Capacity Management ..................................................................23 1.9.3 Nutzen des Capacity Management ......................................................................23

1.10 Cost Management .......................................................................................................24

Marco & Roger, 13.07.05 SLAM 2/45


1.10.1 Ziele des Cost Management ..............................................................................24 1.10.2 Von ITIL empfohlene Input Kosten.....................................................................24 1.10.3 Aufgaben des Cost Management.......................................................................24 1.10.4 Wie hält man die variablen Kosten unter Kontrolle.............................................24 1.10.5 Nutzen des Cost Management...........................................................................24

1.11 Contingency (Risiko-Mngt) Management..................................................................25 1.11.1 Ziele des Contingency Management..................................................................25 1.11.2 Contingency Plan Vorstudie...............................................................................25 1.11.3 Aspekte der Verfügbarkeit..................................................................................25 1.11.4 Nutzen des Contingency Management ..............................................................25

1.12 Nutzen des ITIL-Modells .............................................................................................26 2. Hotline / Support 27 3. Änderungsmanagement 28

3.1 Ziele................................................................................................................................28 3.2 Phasen des Änderungsmanagement ..........................................................................28

3.2.1 Sammlung und Bewertung von Änderungsanträgen............................................28 3.2.2 Planung der Änderungsanträge ...........................................................................29 3.2.3 Durchführung der Änderung.................................................................................29 3.2.4 Verrechnung und Kontrolle der Änderung............................................................29

3.3 Beteiligte Personen / Prozess......................................................................................30 3.4 Beispiel: Änderungsplan..............................................................................................30

4. Service Level Agreements 31 4.1 Einleitung.......................................................................................................................31

4.1.1 Definition SLA ......................................................................................................31 4.1.2 Organisatorische Voraussetzungen für SLA‘s......................................................31

4.2 Gründe für ein SLA.......................................................................................................32 4.3 Auswirkungen von Service Level Agreements ..........................................................32

4.3.1 KEF, Stolpersteine eines SLA..............................................................................32 4.3.2 Beurteilung von SLA‘s..........................................................................................32 4.3.3 Vorteil / Nutzen von Service Level Agreements ...................................................33 4.3.4 Nachteile von SLA................................................................................................33 4.3.5 Umgang mit AGB .................................................................................................33 4.3.6 Grundsätze zur Erstellung SLA............................................................................33

4.4 Erstellungs-Prozess SLA .............................................................................................34 4.5 Leistungsmerkmale ......................................................................................................35

4.5.1 Betriebszeiten ......................................................................................................35 4.5.2 Wartungsbetrieb...................................................................................................35

4.6 Prioritätsstufen .............................................................................................................36 4.6.1 Critical ..................................................................................................................36 4.6.2 Urgent ..................................................................................................................36 4.6.3 Normal .................................................................................................................36 4.6.4 None ....................................................................................................................36

4.7 Eskalationsprozedere...................................................................................................37 4.7.1 Eskalationsstufen .................................................................................................37

4.8 Elemente eines Servicekatalogs..................................................................................37 4.8.1 Elemente eines Specsheet (Service Spezifikation) ..............................................37 4.8.2 Inhaltsverzeichnis SLA.........................................................................................38

4.9 Beispiel Schnittstellenvereinbarung ...........................................................................39 5. Erstellung von Service Level Agreements 40

5.1 Inhalte von SLA‘s..........................................................................................................40 5.1.1 Gegenstand .........................................................................................................40 5.1.2 Leistungen ...........................................................................................................40 5.1.3 Vertragsdokumente..............................................................................................40 5.1.4 Vertraulichkeit ......................................................................................................40 5.1.5 Garantie ...............................................................................................................40 5.1.6 Mitwirkungspflicht des Auftraggebers (Kunde).....................................................40 5.1.7 Urheberrechte an den Arbeitsergebnissen...........................................................40 5.1.8 Zuständigkeiten....................................................................................................40 5.1.9 Haftung und Schadenersatz.................................................................................41 5.1.10 Eigentum............................................................................................................41



5.1.11 Höhere Gewalt ...................................................................................................41 5.1.12 Treuepflicht ........................................................................................................41 5.1.13 Finanzielles Kosten ............................................................................................41 5.1.14 Vertragsänderungen ..........................................................................................41 5.1.15 Gerichtsstand und anwendbares Recht .............................................................41 5.1.16 Inkrafttreten, Vertragsdauer ...............................................................................41

6. Anhänge 42 6.1 Anhang 1.0 – SLA C/S Infrastruktur - Rahmenvertrag...............................................42 6.2 Anhang 1.1 – SLA C/S Infrastruktur - Dienstleistungen ............................................42 6.3 Anhang 1.2 – SLA C/S Infrastruktur - Preise ..............................................................42 6.4 Anhang 2 – SLA Betrieb Callcenter.............................................................................42



1. Service Level Management

1.1 ITIL-Modell (IT Infrastructure Library) Das drei Ebenenkonzept der ITIL-Prozesse



1.1.1 ITIL-Prozesse



1.1.2 Vor- / Nachteile zur Einführung von ITIL Vorteil Nachteil - klare Trennung der Aufgaben - Kunden und Service orientiertes Vorgehen - Qualitätssteigerung der Sicherheit,

Verfügbarkeit, Performance der IT Dienstleistungen durch ein wirkungsvolles Service Management.

- Verbessert und messbare IS Service Qualität, welches auf die Bedürfnisse der Kunden ausgerichtet ist.

- Durch die Standardisierung sind die Abläufe dokumentiert. Stv. Regelung, MA-Wechsel

- Der finanzielle und organisatorische Aufwand für die Aufgabe und Grüsse der Firma ist sehr hoch.

- Bei kleinen Unternehmen (KMU) müssen einige MA mehrere Aufgabe übernehmen. (klare Regelung der Aufgabenteilung)

- hohe Initialkosten bei Ersteinführung. - eventuell Kulturwechsel im Unternehmung

welche vom Mngt getragen werden muss.



1.2 Incident Management / Zwischenfall

1.2.1 Definition Incident Ein Incident ist eine Zwischenfall oder eine Störung.

1.2.2 Beispiele für Incidents Applikationen: Service nicht verfügbar ♦

♦ ♦ ♦ ♦ ♦

♦ ♦ ♦

♦ ♦

♦ ♦ ♦ ♦ ♦ ♦

Applikationen: User kann nicht mit Applikation X arbeiten Hardware: System down Hardware: Printer druckt nicht Service Request: „Wie mache ich das“-Fragen Service Request: Passwort vergessen

1.2.3 Ziele des Incident Management Wiederherstellung eines Services so schnell wie möglich Minimierung von Incidents auf das Business Sicherstellung eines hohen Qualitätlevels und einer hohen Verfügbarkeit (dies im Rahmen des SLA)

1.2.4 Aufgaben des Incident Management Das Incident Management ist vergleichbar mit dem Firstlevel-Support (Hotline) Es werden nur die Incidents und nicht die Ursachen behoben

1.2.5 KPI, Kennzahlen für das Incident Management Anzahl der Incidents Durchschnittliche Zeit zum lösen eines Incidents (elapsed) Prozentuale Anzahl Incidents, welche innerhalb der vereinbarten Zeit gelöst wurden (SLA) Durchschnittliche Kosten pro Incident Prozentualer Anteil der Incidents, welche vom Service Desk gelöst wurden Prozentualer Anteil der Incidents, welche remote gelöst wurden

1.2.6 Definitionen Incident/Problem/ Fehler Definitionen Incident - Ein Incident ist ein Zwischenfall Problem - Ein Problem ist die unbekannte Ursache von einem oder mehreren

Incidents (unbekannter Fehler) Bekannter Fehler - Der Zustand nach erfolgreicher Diagnose der eigentlichen Ursache

eines Problems Beziehungen zwischen Incident, Problem, bekannter Fehler und RFC Fehler - Z.B. Fehler in der Infrastruktur Incident - Meldung/ Zwischenfall

- Der Incident wird versucht zu lösen (Reparatur, RFC, Work-around)

Problem - Kann der Incident nicht behoben werden, wird daraus ein Problem (unbekannter Fehler)

Bekannter Fehler - Wenn das Problem gelöst ist, wird aus dem Problem ein bekannter Fehler

Request for Change (RFC) - Aus dem bekannten Fehler wird ein RFC abgeleitet. Strukturierte Lösung - Lösung

1.2.7 Incident Management Prozess Incident aufdecken und erfassen ♦

♦ ♦

Klassifizierung (Auswirkungen/ Dringlichkeit) und erster Support Analyse und Diagnose



Lösen und Wiederherstellen ♦ ♦ Incident schliessen

1.2.8 Attribute eines Incident Records Attribute eines Incident Records

ID ID007 Trouble Ticket eröffnet durch Callagent Hans Müller Datum - Erfassung - Lösung - Close

01.01.2001 xx.xx.xxxx xx.xx.xxxx

Impact/ Urgency/ Priority Priorität 1 Anrufender Benutzer Hans Muster Wie (Tel. /Fax. etc.) Rückruf auf 071 225 12 54 Wer bezahlt, Kostenstelle 61200 Symthombeschreibung Computer hat keinen Strom Configuration Item (CI) welches betroffen ist

0078 Compaq Deskpro 4000

Kategorie (HW/SW) Hardware Klassifikation Hardware History Eröffnung Trouble Ticket am 01.01.2001 Status offen



1.2.9 Schnittstellen zu anderen Prozessen Schnittstellen zu anderen Prozessen

Prozess Input Rückfluss Change-Management RFC infolge eines Incidents Lösung Problem-Management Nicht lösbarer Incident Nachführung des Problems, der Lösung, des

Work-arounds Configuration-Management

Nachführen der Konfigurations-DB (CMDB)

Lösung in der CMDB.

1.2.10 Organisatorische Einbettung des Incident Management Call Center (professionelles Handling) ♦

♦ ♦

♦ ♦

♦ ♦

♦

Help Desk (Managen, koordinierten und lösen von Incidents) Service Desk (globaler Ansatz mit weiteren Schnittstellen zu Prozessen wie Change Request, Maintenance, SLM, Lizenzverwaltung, CM, Availability Management, Contingency Management) - Zentral - dezentral - virtuell (follow the sun)

1.2.11 Kritische Erfolgsfaktoren Eine aktuelle CMDB (Configuration-Management Datenbank) Eine Wissensdatenbank mit aktuellen Problemen und Fehlern um effektive Lösungen und Work-arounds zu liefern Ein automatisiertes System (Tool) Eine enge Verbindung zum SLM sollte angestrebt werden, um die in den SLA’s gemachten Vereinbarungen auf die Incidents herunter zu brechen Rechtzeitig gelöste Incidents führen zu zufriedenen Kunden.

1.2.12 Nutzen des Incident Management Nutzen des Incident Management

Mit Incident Management Ohne Incident Management Business

- Höhere Effektivität - Niemand managed und eskaliert Incidents - Business orientierte Management-

Informationen abgestimmt mit dem SLA - Keine koordinierten Management

Informationen IT

- Optimaler Einsatz von Mitarbeitern was zu höherer Produktivität führt

- Hochspezialisierte Mitarbeiter werden bei ihrer Arbeit gestört („kannst du mir diese Funktion erklären?“

- Elimination von „verlorenen“ oder inkorrekten Incidents

- Verlorene, inkorrekte und schlecht koordinierte Incidents

- Besseres Monitoren und Management Information

- Keine koordinierten Management Informationen

- Stärkere Kundenorientierung - - Höhere Verfügbarkeit der IT Services - Das Rad wird immer wieder neu erfunden

(keine Wissensdatenbank)



1.3 Problem Management

1.3.1 Ziele des Problem Management Minimieren der nachteiligen Folgen von Incidents und Problemen, welche durch die IT-Infrastruktur verursacht wurden

♦

♦ ♦

♦

♦

♦

♦ ♦

♦ ♦ ♦

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

Verhindern des Wiederauftreten von gleichen Incidents Ursachen von Incidents analysieren und entsprechende Massnahmen einleiten, dass diese nicht wieder auftreten

1.3.2 Aufgaben des Problem Management Problem Control (Identifizieren, Klassifizieren, Analyse und Diagnose, RFC und Problemlösung) Error Control (Identifizieren und erfassen, Assessment, Festhalten der Lösung -> RFC, Close) Proaktives verhindern von Problemen - Trend Analyse - Volumen der Incidents - Anzahl der betroffenen Benutzer - Relative Kosten und Dauer bis Incident behoben ist - Kosten für das Business - Nach jedem grösseren Problem ein Review Identifizierung von Trends Management Informationen

1.3.3 Nutzen des Problem Management Fehlerdokumentation Proaktives verhindern von Problemen (Behebung der Ursachen) Leistungsnachweis gegenüber dem Management

1.3.4 KPI, Kennzahlen für das Problem Management Anzahl generierter RFC’s (Request for Change) Aufgewendete Zeit für Analyse und Diagnose Anzahl und Auswirkungen der Incidents bevor die Ursachen des Problems gelöst wurden Pläne zur Lösung offener Probleme Elapsed Time für geschlossene Probleme/ Errors Durchschnittliche Zeit um ein Problem/ Error zu schliessen Geschätzte Zeit bis das Problem/ Error geschlossen wird Action Plan





1.4 Configuration Management

1.4.1 Ziele des Configuration Management Eigentliches Accounting für alle IT-Geräte (Assets) , Konfigurationen und IT-Services innerhalb der Organisation

♦

♦

♦

♦ ♦

♦ ♦

♦

♦ ♦

♦

♦ ♦

♦ ♦ ♦

Liefert richtige Informationen über eine Konfiguration an die Anderen Prozesse des Service Management Verifiziert die Konfigurationsrecords gegen die Infrastruktur und korrigiert falls Ausnahmen bestehen

1.4.2 Aufgaben des Configuration Management Planung Identifikation (HW, SW, SLA, Lizenzen, Dokumentationen, Prozesse, RFC’s etc.) Die Komponenten werden in der Configuration Management Datenbank (CMDB) geführt. Kontrolle (Registrierung, Update, Archivierung, Inventarisierung aller Configuration-Items) Status Accounting/ Management-Reporting (Informationen über nicht registrierte und inkorrekte Configuration Items, Mengeninformationen, Wert der Assets, Lokationen etc.) Verifikation und Audit

1.4.3 Nutzen des Configuration Management Vollständige und richtige Inventar- und Konfigurationsinformationen Basis für Weiterverrechnung der Leistungen (in der Praxis meistens über Pauschalen, d.h. die IT-Infrastruktur wird durch die IT-Abteilung gekauft und an die Fachbereiche verleast) Basisinformationen für das Finanz- und Rechnungswesen (Abschreibungen)

1.4.4 KPI, Kennzahlen für das Configuration Management Incidents und Probleme, welche zurückverfolgt werden können zu falschen Changes Nicht erfolgreich implementierte RFC’s (Gründe: Mangelndes Impact Assessment, inkorrekte Daten der CMDB etc.) Cycle Time für das Bewilligen und Implementieren von Changes Lizenzinformationen (abgelaufene, nicht gebrauchte etc.) Nicht autorisierte IT-Komponenten



1.4.5 Attribute für ein Configuration Item Attribute eines Configuration Items

CI-Nr RID098980 Nachfolger CI --- Vorgänger CI RID098544 Kategorie (HW/ SW/ Dokumentation) Hardware Kategorie (HW/ SW/ Dokumentation) Hardware Kategorie (HW/ SW/ Dokumentation) Hardware Typ Desktop PC Hersteller Compaq Bezeichnung Deskpro Versionsnummer 4000 EN Seriennummer (Hardware) 340958-23039-323443 Lieferant Computer 2000 Anschaffungspreis 3000.00 Kaufdatum 01.01.1999 Installationsdatum 15.01.1999 Lieferdatum 30.01.1999 Datum Garantieablauf 01.01.2000 Lizenznummer (auch Verträge) Carepaq Vertrag 1236544 Standort ABC, Raum 101R Benutzer Heinrich Müller Kostenstelle 62102 RFC, Change-, Problem-, Incident-Nr. ID0254 Festplatte ausgetauscht

ID0658 RAM auf 128 MB aufgerüstet Aktueller Status (Test, Live, Archiviert) Live

1.4.6 Schnittstellen zu anderen Prozessen Schnittstellen zu anderen Prozessen

Prozess Input Rückfluss Incident-Management

Incidents werden in der CMDB nachgeführt

Entnahme von Lösungen für Incidents

Problem-Management

Probleme werden in der CMDB nachgeführt

Entnahme von Lösungen für Probleme

Change-Management

Changes werden in der CMDB nachgeführt

Basisinformationen für Changes



1.5 Change Management

1.5.1 Ziele des Change Management Sicherstellen, dass standardisierte Methoden und Prozeduren gebraucht werden, für ein effizientes Handling der Changes. Dies um die Auswirkungen auf die Servicequalität von Changes abhängigen Incidents zu minimieren.

♦

♦

♦ ♦ ♦ ♦ ♦

Change ist der Prozess um von einem definierten Status zum anderen zu gelangen.

1.5.2 Aufgaben des Change Management Filtern von Changes Managen von Changes und Changeprozess Vorsitz des Change Advisory Board (CAB) Review und schliessen von RFC’s Managementreporting

1.5.3 Typen von Changes

Changes MINOR SIGNIFIKANT MAJOR Zuständigkeit Anordnung durch den

Change Manager Change Advisory Board

Abteilungsübergrei-ffend

Ressourcen Wenig Ressourcen Mehrere Ressourcen Viele Ressourcen Kosten Approval durch Change

Manager

Kostenfreigabe durch Change Advisory Board

Wir meistens in Form eines Projektes abgewickelt inkl. Projektbudget

1.5.4 Zusammensetzung des Change Advisory Board Change Manager (Vorsitz) ♦

♦ ♦ ♦ ♦ ♦ ♦

♦ ♦ ♦ ♦ ♦ ♦ ♦

Service Level Manager Application Manager Vertreter der Geschäftsbereiche Problem Manager Release Manager Manager Finanzabteilung

1.5.5 Gründe für RFC‘s Einführung eines neuen Configuration Items Incident oder Problem-Report (Hardware muss z.B. ersetzt werden) Service Level Management oder Customer Liasion (periodischer Austausch) Upgrade der Infrastruktur (z.B. neues Betriebssystem) Rechtsänderungen Businessrequirements Produkt- oder Service-Änderungen von Verkäufern oder anderen Vertragspartnern



1.5.6 Change Management Prozess

Request

Change Manager:Filtern

Change Manager:Priorisierung

Dringend

Change Manager(Minor):Autorisierung u. Planung

Change Manager:Kategorie u./o.Standardmodell

Change Manager(Signifikant):Zirkulation der RFC's an die

CAB

IT-Mgmt (Major):Autorisierung u. Planung

CAB:Impact/ Ressourcen/

Scheduling/ Priorität bestätigt

Autorisiert

N

Reject

Change Builder:Baut den Change u. Backout

(Notfallszenario)

Unabhängiger Tester:Testet den Change

Change Manager:Koordiniert d. Implementation

i.O.

Change Manager:Review durchführen

erfolgreichChange schliessen zum Anfang

Change Builder:Impl. Back-out

Fehler

Change Manager:Initiiert CAB o. CAB-Meeting

CAB:Assessment von Impact/Ressourcen/ Dringlichkeit

Dringend

nicht dringend

Change Builder:Change wird gebaut

Zeit für Tests?

Unabhängiger Tester:Testet den Change

Erfolgreich

Change Manager:Koordiniert d. Implementation

i.O.

Change Builder:Impl. Back-out

Change Manager:Kontrolliert die Records

Change Manager:Review durchführen

erfolgreich

Change schliessen

N

N

N

Prozedur fürStandardmodelle

N

J Prozedur für dringende Changes

Standardmodelle

N



1.5.7 Attribute eines RFC’s Attribute eines Configuration Items

RFC-NR RFC0215 Status offen Timestamps - Eröffnung - Auftreten - Close

01.01.2000

Configuration Item Winword 2000 Kategorie Software Beschreibung/ Ursache Thesaurus funktioniert nicht richtig Empfehlung Service Pack 1 installieren Build (durch Wen) Microsoft Effekt bei Nichtimplementierung Thesaurus funktioniert nicht Benutzerdaten (Wann, Wer) Alle Benutzer der Abteilung XY Priorität 3 Kosten (geschätzt/ IST) Schätzung 50 x 150 Fr. = 7500.-- Bewilligungslaufweg/ Approval Fachbereichsleiter/ Change Manager Reviewdatum/ Ergebnisse

1.5.8 KPI, Kennzahlen für das Change Management Anzahl RFC’s ♦

♦ ♦ ♦ ♦

♦ ♦ ♦ ♦

♦ ♦ ♦ ♦ ♦ ♦ ♦

Anzahl Changes Anzahl verworfener Changes Anzahl dringender Changes Anzahl Changes welche auf Implementierung warten - nach Kategorie - nach ausstehender Zeit Anzahl implementierter Changes Change-Backlog Kosten pro Change Business Impact der Changes

1.5.9 Nutzen des Change Management Weniger Beeinträchtigungen durch Changes Zuverlässigere Kostenschätzung von Changes Mehr fehlerfreie Changes Bessere Kommunikation mit dem Kunden Management- Infos Erhöhte Produktivität Weniger fehlerhafte Changes



1.6 Release Management

1.6.1 Ziele des Release Management Rollout von Software und dazugehöriger Hardware planen und überwachen ♦

♦ ♦ ♦

Verteilung und Installation von Prozeduren für Changes Sicherstellen, dass nur getestete und korrekte Versionen autorisierter Software eingesetzt wird Management der Benutzererwartung während dem Rollout

HAUPTZIEL: Richtige Soft- und Hardware am richtigen Ort zur richten Zeit

1.6.2 Aufgaben des Release Management Release Policy und Planung ♦

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

Releases designen, bauen und konfigurieren Rollout Planung Testen von vordefinierten Übernahmekriterien Release freigeben für die Implementation Installation oder Upgrade von Hardware Speichern von kontrollierter Software (dezentral oder zentral) Freigeben, Verteilung und Installation der Software Kommunikation, Vorbereitung und Training

1.6.3 Unterschiedliche Releasetypen Releasetypen

Full Release Delta Release Package Release Vorteil Alle Komponenten der

Releaseeinheit werden zusammen getestet, verteilt und implementiert

Es werden lediglich die geänderten Module verteilt (z.B. Bugfix)

Bildung von zeitlichen und inhaltlich festgelegten Release-Packeten

Nachteil Hoher Zeit- und Ressourcenbedarf

Aufwendiges Change-Management. Jede Änderung an einzelnen Modulen muss genau nachvollziehbar sein.

Abhängigkeit von/zu geänderten Modulen kann zu unvorhergesehenen Ergebnissen führen, resp. muss getestet werden

1.6.4 Software Library (DSL)/ Hardware Store (DHS) Der Term DSL (Definitive Software Library) wird gebraucht, um einen sicheren Ort zu beschreiben, in dem die definitive und autorisierte Version von allen Software CI’s aufbewahrt werden. DHS (Definitiver Hardware Store) ist ein sicherer Ort zur Zwischenlagerung von Hardwareteilen. Details dieser Komponenten werden ebenfalls in der CMDB gespeichert. Aufgaben der DSL

Release Erstellung ♦ ♦ ♦ ♦ ♦ ♦ ♦

♦ ♦ ♦

Software + verknüpfte Configuration Items Physische Speicherung Logische Bibliothek Physische Verteilung Logische Speicherung Qualitätsprüfung

1.6.5 KPI, Kennzahlen des Release Management Anzahl Releases Anzahl der Probleme, welche mit neuen Releases zusammenhängen Anzahl von neuen, geänderten und gelöschten Objekten bei der Einführung eines neuen Releases



Anzahl Releases welche innerhalb der vereinbarten Zeit vervollständigt wurden ♦

♦ ♦ ♦ ♦ ♦ ♦ ♦

♦

♦

♦ ♦ ♦ ♦ ♦

1.6.6 Nutzen des Release Management Standortübergreifende Bereitstellung konsistenter Hard- und Software Erkennen und bereinigen unkorrekter Versionen Garantierte Qualität der produktiven Software Beseitigte Fehler treten in späteren Releases nicht mehr auf Fehlervermeidung durch bessere Koordination von Releases Sichere Aufbewahrung der Software Im Notfall kann auf Baselines und vertrauenswürdige Software zurückgegriffen werden

1.6.7 Herausforderungen des Release Management Widerstand der Mitarbeiter (Arbeiten in gewohnter Umgebung, Wiederstand gegenüber Neuerungen/Änderungen) Umgehung des Release Management (meist wird dem Release-Management zuwenig Beachtung geschenkt z.B. infolge Termindruck) „Emergency“-Fixes Installation „on time“ Unklare Rollenverteilung zwischen Operation/ Development Nicht genügend Ressourcen Ungenügende Testumgebungen



1.7 Service Level Management siehe auch SLA

Unter Service Level Management wird das Verfahren verstanden, welches die Qualität und den Umfang der angebotenen IT- Services regelt.

Service Level Management Gelieferte Services Leistungserbringung SLA‘s mit dem Kunden Interne Prozesse Lieferantenbeziehungen (Bezug zum ITIL-Modell

Bei SLA’s gibt es drei Partner

Kunde: schliesst aufgrund des Servicekatalogs mit dem IT-Dienstleister oder auch eder IT-Abteilung ein SLA ab

♦

♦ ♦

IT-Dienstleister oder Abteilung: schliesst mit dem Kunden ein SLA ab. Hersteller/ interner Lieferant: Der IT-Dienstleister schliesst mit dem Hersteller/ Lieferant ein OLA (Operational Level Agreement) ab. Dies als Rückversicherung seiner Leistungen.

1.7.1 Aktivitäten des Service Level Management



1.7.2 Beziehungen des SLM zu anderen Prozessen Schnittstellen zu anderen Prozessen

Prozess Input Output Service Level Management Requirements der Anwender,

des Kunden Quality of IT Services Kosten des SLA’s

PLANUNG Capacity Management Kosten des SLA’s

Performance-Anforderungen Kosten, Performance, Recovery

Cost Management Kosten des SLA’s Kosten, Performance, Recovery Availability Management Kosten des SLA’s Kosten, Performance, Recovery Contingengy Management Kosten, Performance, Recovery

INFRASTRUKTUR Configuration Management Verfügbarkeits-Anforderungen

Request for Improving Impact auf Planung

Release Management Request for Improving Impact auf Planung SUPPORT

Incident Management Verfügbarkeits-Anforderungen Request for Improving Problem Management Verfügbarkeits-Anforderungen Request for Improving Change Management Verfügbarkeits-Anforderungen Request for Improving



1.8 Availability(Verfügbarkeit) Management

1.8.1 Ziele des Availability Management Planung und Management der CI-Verfügbarkeit ♦

♦ ♦

♦ ♦

♦ ♦ ♦ ♦ ♦ ♦

Planung und Management der Service-Verfügbarkeit (definiert in den SLA’s) Vorschlagen und durchführen von vorbeugenden Massnahmen, damit die geforderte Verfügbarkeit erreicht werden kann Kontrolle der mit den Lieferanten ausgehandelten Zuverlässigkeit Abwägung der Kosten <-> Nutzenproblematik

1.8.2 Aufgaben des Availability Management Planung welche folgende Aktivitäten umfasst

das Einrichten der benötigten Systemmessungen das Sicherstellen, dass die Ergebnisse verfügbar sind das Bestimmen der Dokumentationen, die benutzt werden sollte das Festlegen der Aufzeichnungsverfahren das Einrichten der Change-Control und Review-Verfahren sowie deren Periodizität das Ausbilden der Operations-Mitarbeiter

1.8.3 KPI, Kennzahlen des Availability Management

♦ MTBSI (Mean Time between System Incident =Zuverlässigkeit)

MTTR (Mean Time between Repair = Wartbarkeit) ♦ ♦ ♦ ♦

♦ ♦

MTBF (Mean Time between Failure = Verfügbarkeit) Anzahl der von einem Fehler betroffenen Benutzer Ursache des Ausfalles

1.8.4 Nutzen des Availability Management Kostenersparnisse infolge verbesserter Produktivität Höhere Arbeitsmoral bei Usern und IT-Mitarbeitern



1.9 Capacity Management Das Capacity Management stellt sicher, dass die Dienstleitungen rechtzeitig und mit minimalen Kosten erstellt und ausgeliefert werden. Es ist verantwortlich für die Ermittlung der benötigten, kostenmässig vertretbaren Kapazität der IT-Ressourcen in Abstimmung mit den vereinbarten Service Levels.

1.9.1 Ziele des Capacity Management Das Capacity Management stellt sicher, dass die vorhandenen Hardware-Ressourcen optimal eingesetzt werden und dass Erweiterungen zeitgerecht durchgeführt werden. Zudem werden Informationen für die Kosten/Nutzen-Beurteilung von neuen Systemen und Hardware-Erweiterungen bereitgestellt.

1.9.2 Aufgaben des Capacity Management

1.9.3 Nutzen des Capacity Management - Fähigkeit zur Erstellung und Management von SLA’s - Weniger Probleme (Systemengpässe werden frühzeitig erkannt und die Kapazität kann präventiv

erweitert werden) - Höhere User Zufriedenheit - Höhere Verfügbarkeit - Bessere Prognose und Budgets - Bessere Verhandlungsposition



1.10 Cost Management

1.10.1 Ziele des Cost Management Das Cost Management hat zum Ziel ein optimales Kostenermittlungs- und Kostenverrechnungssystem zu schaffen. Es umfasst sowohl das Costing der Services als auch Methoden zur Ermittlung der richtigen Gebühren.

1.10.2 Von ITIL empfohlene Input Kosten - Equipment - Organisation, Mitarbeiter - Transfer - Gebäude - Software

1.10.3 Aufgaben des Cost Management Betriebsabrechnung auf Vollkostenbasis

Costing: Alle Periodenkosten eines Betriebes (Imputkosten nach ITIL) ♦ ♦ Charging Kalkulation nach BEBU (Kostenarten, -träger und – stellenrechnung) Beispiel: Grundkosten errechnet aufgrund von Best-Practice und geschätzte variable Kosten

Charging und Pricing (Optionen) Charging Pricing - Kein Charging - Charging fiktiver Kosten - Charging tatsächlicher Kosten

- Berechnung der Selbstkosten - Selbstkosten plus Zuschlag - Marktpreis - etc.

1.10.4 Wie hält man die variablen Kosten unter Kontrolle Modell welches je nach Situation angepasst werden kann - 1. Change < 1 AT: Mail an CIO - 2. Change > 1 AT und < 3 AT: Mail an CIO mit Bestätigung - 2. Change > 3 AT und < 20 AT: Unterschrift von CIO - 4. Change >20 AT: kein Change mehr sondern ein Projekt Changerecord / Kostenkontrolle - Kurze Beschreibung der Änderung - Analyse - Approvals - Journal

1.10.5 Nutzen des Cost Management - Kostenüberwachung / Bereitstellung von Managementinformationen - Entscheidungen auf kostenwirksamen Informationen abzustützen - Professionelle Entscheidungen treffen - Absicherung künftiger Investitionen - Erkennung wertvoller Produktivitätssteigerungen



1.11 Contingency (Risiko-Mngt) Management

1.11.1 Ziele des Contingency Management - Das Contingency Management ist dafür zuständig, dass ein Contingency-Plan (Katastrophen Plan,

Risikoverminderungsmassnahmen) aufgesetzt und gemanagt wird. Dieser beinhaltet alle Massnahmen, welche erforderlich sind, um im Falle eines Zusammenbruches die IT-Services wieder herzustellen

- Diese Katastrophen-Vorsorge wird in 3 Schritten entwickelt – Planung Vorstudie – Implementierung Erstellen des Contingency-Plans – Unterhalt Regelmässiges prüfen, revidieren und testen

1.11.2 Contingency Plan Vorstudie - Risikoanalyse

– Wert des Vermögens – Bedrohung – Schwachstellen

- Risikomanagement – Gegenmassnahmen – Planen für den Eventualfall – Bewältigen einer Katastrophe

Erstellen, Implementierung Contingency Plan - Test - Genehmigung - Erstellung der Service-Verträge - Verteilung der Pläne - Schulung der Mitarbeiter - Anpassung der SLA‘s

Beispiel - Administration - IT-Infrastruktur (HW/SW) - Betriebs-Prozeduren (Management u. Betrieb

der IT-Infrastruktur) - Personal - Sicherheitsmassnahmen - Zurück zum Normalbetrieb (Return to Normal

Procedure)

=> Wichtig: Regelmässiges prüfen mit Aktionsplan aus den Abweichungen! Die ITIL-Optionen / Handlungsmöglichkeiten - Nichts tun - Manueller Betrieb (z.B. Kassabuch) - Wechselseitige Ausfallsicherung (andere Umgebung) - Der „Festungs-Gedanke“ - „Kaltstart“ Feste Einrichtung - „Kaltstart“ Portable Einrichtung - „Warmstart“ Extern, Intern oder Mobil - „Hot-Fallback-Data-Center“

1.11.3 Aspekte der Verfügbarkeit - Reliability (Zuverlässigkeit) - Maintainability (Wartbarkeit) - Resilience (Stabilität) - Serviceability (Lieferantenverträge) - Security (Sicherheit)

1.11.4 Nutzen des Contingency Management - Weniger Ausfälle - Geringere Beeinträchtigung im Katastrophenfall - Kontrollierte Wiederherstellung



- Service-Kontinuität - Minimale Unterbrechung der Geschäftsabläufe

1.12 Nutzen des ITIL-Modells Das ITIL-Modell soll die Kundenorientierung und Prozessorientierung verbessern sowie eine Qualitätsverbesserung bewirken

Wegleitung zur Definition der internen Prozesse auch im Hinblick auf die ISO-Zertifizierung wo die Prozessorganisation im Vordergrund steht

♦

♦ ♦

Ganzheitliche Sicht Klare Schnittstellen in der Kommunikation mit dem Kunden

Service DeskAnwender

Top -Management Service Manager



2. Hotline / Support etc. ….



3. Änderungsmanagement

3.1 Ziele ♦ ♦ ♦ ♦ ♦ ♦

♦

♦

♦ ♦ ♦

Integration des Änderungsmanagements in das ISM Steuerung durch den Fachbereich Kontrollierter Anteil der Gesamtkapazität für Änderungen Verursachungsgerechte Abrechnung pro Applikation / Jahr Effektivität des Änderungsmanagements Flexibilität des Änderungsmanagements

3.2 Phasen des Änderungsmanagement 1. Sammlung und Bewertung von Änderungsanträgen 2. Planung der Änderungsanträge 3. Durchführung der Änderung 4. Verrechnung und Kontrolle der Änderung

3.2.1 Sammlung und Bewertung von Änderungsanträgen Aktivitäten Sammlung der Änderungsanträge

- Periodisch (nicht abwarten bis Jahresende -> Ressourcen) Beschreibung der Auswirkungen eines Änderungsantrags - welche Applikationen sind betroffen? - Konsequenzen aus Sicht der bestehenden Applikationen - eventuell Aufwandschätzung korrigieren (> 2 PM -> Projekt Ordnung nach bestehenden Applikationen Ordnung nach Terminen Ordnung nach Kategorie (Anforderungsgruppen) - Fehlerbehebung - Anpassungen (z.B. gesetzliche Bestimmungen) - Weiterentwicklung (< 2PM)

Org. Verantwortung ♦ ♦

Fachbereich, Architektur-Entwicklung, IS-Entwicklung Ausschüsse des ISM

Ausführungsmodus ♦ ♦

Laufend Applikationsausschuss -> Entscheid an den Sitzungen

Input ♦ ♦

IS-Antrag (ISM-Stab, IS-Leiter, IS-Entwicklung) Info über Zustand Applikation (IS-Entwicklung, Architektur-Entwicklung)

Output ♦ ♦

IS-Anträge zur Bearbeitung (ISM-Stab, IS-Leiter, IS-Entwicklung) Liste der nicht zu bearbeiteten Änderungen (Applikationsausschuss, Fachbereich, dezentraler IS-Ausschuss)



3.2.2 Planung der Änderungsanträge Aktivitäten ♦

♦ ♦ ♦

Überprüfung der Kapazitäten Detailplanung der Änderungsanträge Kontrolle des Änderungsplanes (Risikoanalyse) Publikation des Änderungsplanes im Fach- und IS-Bereich

Org. Verantwortung ♦ ♦

ISM-Stab organisiert Planungssitzung Teilnehmer: Leiter IS-Bereich, Arch.-, IS-Entwicklung, Fachbereich

Ausführungsmodus ♦ ♦ ♦

Detailplanung soll mindestens den Zeitraum von 3 Mt. Abdecken Rollende Aktualisierung alle 2 Wochen � Jahresende Releasemanagement jährliche Grobplanung

Input ♦ ♦ ♦

IS-Antrag (ISM-Stab) IS-Entwicklungsplan (dezentraler IS-Ausschuss) IS-Konzept (zentraler IS-Ausschuss)

Output ♦ Änderungsplan dezentraler Bereich (IS-Entwicklung, Organisation, Fachbereich, Applikationsausschuss)

3.2.3 Durchführung der Änderung Aktivitäten ♦

♦ ♦ ♦ ♦ ♦

Ablauf wie kleines Entwicklungsprojekt -> Projektmanagement Lückenlose Zeitaufschreibung Dokumentation, Schulungsunterlagen, Help-Menus etc. Tests mit Überprüfung der Nebenwirkungen auf angrenzende Appl. Übergabe der Programme, Module etc. Übergabe an IS-Architektur (Codes, Protokolle

Org. Verantwortung ♦ ♦ ♦

IS-Entwicklung Architektur-Entwicklung Fachbereich


Laufend Einhaltung des Änderungsplans

Input ♦ IS-Anträge (ISM-Stab) Output ♦

♦ Meldung über Abschluss (IS-Leiter, Fachbereich) Geänderte Architekturteile (Architekturentwicklung)

3.2.4 Verrechnung und Kontrolle der Änderung Aktivitäten ♦

♦

Erfolgskontrolle - hat sich ursprüngliche Anforderung an Applikation verändert ? - Läuft die Applikation fehlerfrei ? - Wurde der erwartete Nutzen realisiert ?

Lückenlose Zeitaufschreibung - Verrechnung an den Fachbereich - Vergleich IST <-> SOLL - Aufrechnung auf Gesamtapplikationskosten - Verrechnungssystem soll Aufschluss über die gesamten und periodischen

Applikationskosten geben Org. Verantwortung ♦

♦ Fachbereich Unterstützung durch ISM-Stab


Nach Abschluss der Änderung Monatliche Verrechnung

Input ♦ ♦

Meldung über Abschluss (IS-Entwicklung) Zeitaufschreibung, Sachaufwand (Architektur-, IS-Entwicklung)

Output ♦ ♦

Zusammenfassung der durchgeführten Änderungsanträge (dezentr. IS-Leiter) Investitionen pro Applikation (dezentr. IS-Leiter, Finanzbereich)



3.3 Beteiligte Personen / Prozess

IS-LeiterISM-Stab

IS-Entwicklung

Fachbereiche IS-Architektur IS-Controlling Andere Ebe-nen des ISM

Sammlung und Bewertung

Planung

Durchführung

Kontrolle

Genehmig. desÄnderungsplans

Bewertung vonIS-Anträgen

IS-Entwicklungs-planung

IS-Anträge

Änderungsplanpro ApplikationÄnderungsplanpro Applikation

Umsetzung derArchitektur

Kapazitäten

Verrechnung

3.4 Beispiel: Änderungsplan

Datum:

Ersteller:

Verantwortlich

Nr. BeschreibungDatumEintrag

Aufw.(Tage) Beginn Ende Release Entw. Fachabt. Prio. Kat.

11.05.1998

M: MusterApplikation: Projekt XY

Änderungsplan



4. Service Level Agreements

4.1 Einleitung Die Grundlage für die Erstellung von SLA’s sind die Kundenanforderungen. Viele Geschäftsprozesse sind heute IT unterstützt deshalb müssen geschäftskritische Anwendungen eine hohe Verfügbarkeit aufweisen und Störungen rasch behoben werden. Vor allem im E-Business ist die Verfügbarkeit ein kritischer Erfolgsfaktor.

Anforderungen/ Nutzen Verfügbarkeit IT-System - Minimierung der Ausfallzeit von IT-Systemen Verfügbarkeit IT-Dienstleister

- Erreichbarkeit des IT-Dienstleisters - Garantierte Reaktionszeit des IT-Dienstleisters

Kosten - Vertraglich fixierte und damit kalkulierbare Kosten für die Behebung von Störungen.

Die Ausprägung der Anforderungen haben letztendlich auch einen Einfluss auf den Kosten bzw. den Preis von SLA’s. Als Grundlage für SLA’s dient der Servicekatalog des IT-Dienstleisters oder der Abteilung. Der Kunde wählt die gewünschten Services aus. Aufgrund der gewählten Services wird ein SLA erstellt. Der IT-Dienstleister sichert sich Basisleistungen wiederum mit einem OLA (Operational Level Agreement) beim Hersteller/ Lieferanten ab.

4.1.1 Definition SLA Service Level Agreements sind Vereinbarungen zwischen Dienstleistungserbringern und –bezügern. In ihnen werden die Abweichungen zum Servicekatalog festgehalten. Sie legen Umfang, Verantwortlichkeiten und Konsequenzen fest, die bei der Erbringung der Dienstleistung gelten.

4.1.2 Organisatorische Voraussetzungen für SLA‘s Damit die Leistungen gemäss SLA’s erfüllt werden können müssen die internen Prozesse definiert sein.

♦

♦ Vereinbarte Leistungen müssen erfüllt werden können



4.2 Gründe für ein SLA Verselbständigung der Informatik-Abteilungen ♦

♦ ♦

♦ ♦ ♦ ♦ ♦

♦ ♦ ♦ ♦

♦ ♦ ♦ ♦

♦ ♦ ♦

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

♦ ♦ ♦ ♦ ♦

Bilden von Profit-Centers Konzentration auf’s Kerngeschäft (SLA’s werden zu einem wichtigen Bestandteil in verschiedenen Branchen, nicht nur in der Informatik !) Sourcing (In- bzw. Outsourcing) Vergabe gewisser Dienstleistungsbereiche, oder Teile davon an externe, spezialisierte Firmen Kostentransparenz Sensibilisierung der Benutzer (Kostenbewusstsein) Neue Leistungen in der Informatik und der Telekommunikation

4.3 Auswirkungen von Service Level Agreements Verhältnis zwischen IT und Enduser wird neu definiert

Veränderte organisatorische Regelungen (Zusammenarbeit zwingend notwendig) Verwaltungsaufwand Leistungsdruck für die IT Umdenken für den Enduser (Informatik ist nicht gratis)

Einsatz, SLA ist sinnvoll, wenn

Anforderungen der Enduser an die IT stetig steigen Entscheidungsgrundlagen für/gegen Outsourcing benötigt werden Keine Transparenz in Bezug auf IT-Leistungen besteht Die bestehenden Führungsinformationen nicht ausreichen

4.3.1 KEF, Stolpersteine eines SLA genaue Definition und Formulierung des Leistungsumfangs Klare Preisstruktur Klare Termine und Qualität des Services beschrieben - messbar - erreichbar - aussagekräftig - beeinflussbar - akzeptiert SLA’s werden zu Positionskämpfen missbraucht SLA’s werden bei strukturellen Veränderungen nicht angepasst Formulierungen sind zu technisch oder zu wenig fachlich Orientiert Benutzer war nicht involviert Management Commitment notwendig Proaktiver Einbezog aller Parteien Klare Kommunikation und Stakeholder-Management Kooperationsbereitschaft Einbezug von Mensch, Technologie und Organisation Better roughly right than exactly wrong

4.3.2 Beurteilung von SLA‘s Folgende Punkte sind bei einer Prüfung von SLA’s zu beachten:

Sind die Leistungen genau definiert und abgegrenzt? Ist die Konfiguration (Gegenstand) genau definiert? Sind die Verantwortlichkeiten genau definiert? Ist das SLA widerspruchsfrei? siehe auch KEF



4.3.3 Vorteil / Nutzen von Service Level Agreements genaue Messkriterien ♦

♦ ♦ ♦ ♦ ♦

♦

♦

♦

♦

♦ ♦

♦ ♦ ♦

♦

♦

♦ ♦

♦ ♦ ♦ ♦ ♦

bessere Lieferantenbeziehungen höhere Qualität der IT-Leistungen besseres Management der IT / SLM wird zum Führungsinstrument Kostenrechtfertigung der IT Verbesserte User-Services (Verfügbarkeitsziele)

4.3.4 Nachteile von SLA Relativ grosser administrativer und personeller Aufwand bei korrekter Handhabung (ist nicht zu unterschätzen!) Das Messen der Leistungsparameter kann aufwendig und kostspielig werden (Einsatz geeignete Tools !) Aufwendiges Umfeld zur Erbringung der Leistung (Help-Desk, Call-Center, organisatorische Massnahmen etc.)

4.3.5 Umgang mit AGB Falls ein Passus in den AGB geändert werden soll, so muss

1. dieser durchstrichen werden 2. von beiden Parteien unterschrieben werden (Angabe von Datum)

4.3.6 Grundsätze zur Erstellung SLA Beide Parteien, der Leistungsbezüger und der Leistungserbringer müssen der Einführung von SLA’s positiv gegenüberstehen. Das Vorgehen zur Erstellung der SLA‘s muss klar sein. Bei der Erarbeitung sollen beide Parteien (Leistungsbezüger und Lesitungserbringer) gleichenteils involviert sein. Der Konstrukt/Aufbau und Inhalt der (Vertrags-) Dokumente muss klar sein. Die Leistung werden so gut, wie der Detaillierungsgrad der Leistungsmerkmale in den SLA’s. Bei der Leistungsbeschreibung nicht vom 100sten ins 1000ste verfallen (Details in Anhänge, Handbücher oder andere „related documents“ verweisen). Die Qualitäts- und Quantitätsmerkmale der Endprodukte vom Benutzer formulieren lassen oder zumindest aus Benutzersicht formulieren. Häufig ändernde Angaben, wie Namen, Tel.Nr., email-Adressen, Mengen, Konfigurationen, SW-Releases etc. nicht im Vertragsdokument (SLA) selber, sondern in Anhängen aufführen. Weder Qualitäts- noch Quantitäts-Angaben aufführen, die nicht messbar sind. Für Mengendefinitionen (z.B. Anzahl Arbeitsplatzgeräte), gilt der Status des Unterzeichnungsdatums (Toleranzen definieren/erlauben). Messaufwände abschätzen und bewerten (soll kein Verhältnisblödsinn werden!). SLA als Führungsinstrument (MBO) einsetzen. SLA-Reviews und SLA-Anpassungen vorsehen. Organisation und personelle Vorkehrungen, sowie System Management Tools für das SLA-Management vorsehen.



4.4 Erstellungs-Prozess SLA



4.5 Leistungsmerkmale

4.5.1 Betriebszeiten 4.5.1.1 Bedienter Betrieb

Als bedienter Betrieb gilt die Zeit in der der Help-Desk garantiert besetzt ist

4.5.1.2 Bedienter Betrieb gilt zu folgenden Zeiten:

Montag - Freitag von 08.00 - 17.00 Uhr

4.5.1.3 Unbedienter Betrieb

Als unbedienter Betrieb gilt die Zeit Während der nicht garantiert wird, dass der Help-Desk besetzt ist

4.5.1.4 Unbedienter Betrieb gilt zu folgenden Zeiten:

Montag - Freitag von 17:00 - 08:00 Uhr / Samstag und Sonntag ganzer Tag

4.5.1.5 Exklusivbetrieb

Für grössere Hard- und/oder Softwareänderungen werden Exklusivwartungsfenster benötigt. Die betroffenen Systeme stehen den Kunden während diesen Exklusivzeiten nicht zur Verfügung. Die Exklusivzeiten werden speziell behandelt und dem Kunden schriftlich und/oder über das Ebulletin frühzeitig mitgeteilt.

4.5.2 Wartungsbetrieb Für die XYZ -Server sind die folgenden Wartungsfenster definiert. Spezielle Anforderungen außerhalb dieser Zeit fallen in den Exklusivbetrieb. Montag – Freitag: 20.00 Uhr - 22.00 Uhr Samstag: 17.00 Uhr - 22.00 Uhr Sonntag: 06.00 Uhr - 22.00 Uhr



4.6 Prioritätsstufen

4.6.1 Critical Ein wesentlicher Teil der IT-Infrastruktur (Arbeitsplatzgeräte, Server, Netzwerke, etc.) ein zentraler Service, oder eine Hauptanwendung für einen Geschäftsbereich ist nicht verfügbar und somit die Erledigung des Tagesgeschäfts der LEISTUNGSBEZÜGERIN be- bzw. verhindert.

4.6.2 Urgent Das Tagesgeschäft einer Benutzergruppe/Fachstelle wird durch eine Störung teilweise eingeschränkt oder verunmöglicht, bzw. eine Applikation, oder ein Service ist nicht verfügbar, wird aber unmittelbar zur Erledigung des Tagesgeschäfts benötigt.

4.6.3 Normal Die Tagesarbeit eines Benutzers wird durch eine Störung teilweise eingeschränkt oder gänzlich verhindert oder eine Applikation, ein Service ist nicht oder nur teilweise verfügbar, wird aber nicht unmittelbar zur Erledigung der Tagesarbeit benötigt. Der Benutzer verlangt eine allgemeine Hilfestellung. Trotz der Beeinträchtigung kann er seine Tagesarbeit erledigen, da die Beeinträchtigung keinen gravierenden Einfluss auf Termine noch die Qualität seiner Arbeit hat.

4.6.4 None Eine Benutzeranfrage muss bis zu einem, in Absprache mit dem Benutzer vereinbarten Termin (langfristiger Termin min. 1 Woche) erledigt sein. Wird die Anfrage nicht direkt beim Anruf vom Helpdesk beantwortet, werden die Anfragen gemäss den in diesem SLA festgelegten Prioritätsstufen eskaliert.



4.7 Eskalationsprozedere

4.7.1 Eskalationsstufen Das Trouble-Ticket System überwacht den mit dem Kunden vereinbarten Termin bezüglich nächster Aktion. Bei Überschreitung des Termins wird eine Alarmmeldung gemäss nachfolgender Eskalationstabelle an die zuständige Instanz abgesetzt.

4.8 Elemente eines Servicekatalogs Inhalt (Versionsnummer, Erstellungsdatum, Abnahmedatum, Inhaltsverzeichnis) ♦

♦ ♦ ♦ ♦

♦ ♦

♦ ♦ ♦

Vorwort Profil des Serviceproviders Servicezeiten und Verfügbarkeit des Serviceproviders Überblick über die Services und Produkte – Services- und Produktebeschreibungen – Spezifikationen – Deliverables – Servicezeiten – Qualitätsziele – Maintenancezeiten – Request- und Changeprozeduren – Supportzeiten – Deliveryzeiten – Requiremens Contingency (Disasterfall) Pricing und Charging

4.8.1 Elemente eines Specsheet (Service Spezifikation) Service-Beschreibung, Datum, Dauer, Leistungen Parteien, Name, Datum, Unterschrift Verfahren für – Unterzeichnung



– Changes – Lieferung – Korrekturmassnahmen Security, Backup & Recovery ♦

♦ ♦ ♦

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

♦ ♦

Service Levels, Availability, Performance Gelieferte Produkte & Zubehör Servicezeiten & Ort, Lieferbedingungen, finanzielle Bedingungen

4.8.2 Inhaltsverzeichnis SLA Inhalt (Versionsnummer, Erstellungsdatum, Abnahmedatum, Inhaltsverzeichnis) Releasemanagement Unterschriften Globale Statements Kurze Beschreibung des Providers und der Kundenorganisation Summary der Verantwortlichkeiten Spezifikation der Services (gleiche Gliederung wie Servicekatalog) – Services- und Produktebeschreibungen – Spezifikationen – Deliverables – Servicezeiten – Qualitätsziele – Maintenancezeiten – Request- und Changeprozeduren – Supportzeiten – Deliveryzeiten – Requirements Managementreporting Reviewprozeduren



4.9 Beispiel Schnittstellenvereinbarung Formular Schnittstellenvereinbarung

Nr. Kapitel Bemerkungen Nr. 1 Schnittstellenvereinbarung für: Parteien auflisten Nr. 2 Kurzbeschreibung: Inhalt der Vereinbarung (kurz)

Nr. 3 Beteiligte Personen: - Datenlieferant - Data Worhouse:

Namen / Instradierung der Beteiligten Parteien

Nr. 4 Schnittstellenart XML SQL View FlatFiles (CSV) Andere...

Definition der möglichen Schnittstellenarten

Nr. 5 Lieferperiodizität: stündlich täglich wöchtentlich monatlich Andere

Nr. 6 Aufbewahrungszeit: > Monat > 1 Jahr > 5 Jahre < 6 Monate < 1 Jahr

Daten-Volumen (ohne Header) Anzhahl Records Anzahl Megabyte Initial Worst Case

Nr. 7

Durchschnitt pro Extration

Nr. 8

Headerinformationen: - Bezeichnung - Systemname - Datum - Anzahl Records - Anzahl Attribute

Attribute Nr. 9 Name Typ Format Bezeichnung

Referenzwerte: Nr. 10 Attributname Typ Max. Wert Ref. Wert

Nr. 11 Liefert Daten über: ..................................................................... Beschrieb (kurz) Nr. 12 Betroffener Bereich:

Allfinanz Marketing Management Verkauf Andere

Nr. 13 Grenzwerte / Konsequenzen: Beschrieb, was passiert, wenn die Vereinbarung nicht eingehalten wird (Kosten)

Nr. 14 Unterschriften der Verantwortlichen - Datenlieferant / Ort und Datum - Datenwarehouse / Ort und Datum:



5. Erstellung von Service Level Agreements Dieses Kapitel streift wichtige Inhalte von Service Level Agreements.

5.1 Inhalte von SLA‘s

5.1.1 Gegenstand um welche Services handelt es sich? ♦

♦ ♦

♦

♦ ♦

♦

♦ ♦

♦ ♦

♦

♦

♦ ♦

♦

♦

Genaue Abgrenzung ist sehr wichtig Die Konfigurationen müssen bei Abschluss genau festgelegt und umschrieben sein. Meist wird dies in Form eines Anhanges gemacht. Bei grundlegenden Änderungen ist eine Anpassung des SLA’s erforderlich.

5.1.2 Leistungen Um welche Leistungen handelt es sich? – Wartung – Betrieb – Störungsbehebung Welche Leistungen sind NICHT enthalten Verantwortlichkeiten (Zuständigkeitsmatrix) – Wer ist für welche Leistungen verantwortlich‘ - Welche Basis muss der Kunde erbringen? Wann und in welchem Umfang sind diese zu erbringen? – Reaktionszeit – Arbeitszeiten (Normalarbeitszeit, Spezialarbeitszeit etc.)

5.1.3 Vertragsdokumente Welche Dokumente bilden integrierenden Bestandteil des SLA’s? Meist wird ein sogenannter Manntelvertrag abgeschlossen. Änderungen können in zusätzlichen Anhängen festgehalten werden.

5.1.4 Vertraulichkeit - Kunde und IT-Dienstleister verpflichten sich zu Vertraulichkeit betr. Informationen über Betriebs- und

Geschäftsgeheimnisse. - Ist z.B. wichtig, wenn der Kunde dem IT-Dienstleister Systempasswörter aushändigt

5.1.5 Garantie Der IT-Dienstleister garantiert dem Kunden ausgebildete Mitarbeiter einzusetzen. SLA‘s dürfen nie auf einzelne Mitarbeiter abgeschlossen werden!

5.1.6 Mitwirkungspflicht des Auftraggebers (Kunde) Zugang zu allen für die Vertragserfüllung notwendigen Informationen (Standorte, Räume, Systeme etc.) Zur Verfügungstellung für die Vertragserfüllung notwendige Infrastruktur (PC’s, Bildschirme, Printer etc.) Ggfs. Dial-In Möglichkeit für IT-Dienstleister zu Wartungszwecken Der Kunde muss einen Ansprechpartner stellen

5.1.7 Urheberrechte an den Arbeitsergebnissen Im Rahmen des SLA’s werden zum Teil auch Arbeitsergebnisse erstellt. Der IT-Dienstleister garantiert, dass die Ergebnisse nur für den Kunden verwendet werden. Soweit an den Ergebnissen Urheberrechte entstehen, stehen diese dem Kunden sowie dem IT-Dienstleister gleichermassen zu.

5.1.8 Zuständigkeiten Die Zuständigkeiten müssen genau definiert werden. Dafür kann unter anderem das ITIL-Modell herangezogen werden.



Ein wichtiger Prozess ist das Change-Management. Es gilt zu vermeiden, dass der IT-Dienstleister die Verantwortung für den Betrieb der IT-Infrastruktur trägt und der Kunde laufend unkoordinierte Änderungen vornimmt welche zur Instabilität der Systeme führen.

♦

♦

♦

♦

♦

♦ ♦ ♦ ♦

♦

♦ ♦

♦ ♦

♦

♦ ♦

5.1.9 Haftung und Schadenersatz Der Schadenersatz beschränkt sich meistens auf eine kostenlose Nachbesserung. Auf keinen Fall wird für indirekte Schäden wie z.B. entgangener Gewinn gehaftet!

5.1.10 Eigentum Die für die Betreuung zur Verfügung gestellten vorbestehenden Prozeduren und Konzepte verbleiben im Eigentum des IT-Dienstleister. Für den Kunden erarbeitete Prozeduren und Konzepte verbleiben im Eigentum des Kunden. Alle Prozeduren können durch den Kunden uneingeschränkt genutzt und verändert werden, auch nach Beendigung des Vertrages.

5.1.11 Höhere Gewalt Ereignisse höherer Gewalt (Streik, Aussperrung etc.) können den IT-Dienstleister daran hindern die vertraglichen Leistungen zu erbringen oder eine Verzögerung zur Folge haben. Diese Umstände bewirken eine Leistungsverzögerung. Der IT-Dienstleister kann dafür nicht haftbar gemacht werden.

5.1.12 Treuepflicht Mit Treuepflicht ist eine Abwerbeklausel gemeint. Der Kunde könnte versuchen den externen Mitarbeiter dem IT-Dienstleister abzuwerben. Diese Loyalitätsklausel ist im Sinne des IT-Dienstleisters.

5.1.13 Finanzielles Kosten Genaue Regelung finanzieller Angelegenheiten Pauschalbetrag Abmachung (immer inkl. Mwts) Festlegung des Stundenansatzes (Angabe von inkl. Mwts) Wie erfolgt die Leistungsverrechnung? – Named User (Anzahl im System registrierte Benutzer) – Concurrent User (Anzahl gleichzeitig arbeitende Benutzer) – Stundenbasis (Messung der Onlinezeiten der Benutzer) Nennung von Spesen, wie werden Spesen abgerechnet? - Pauschale Spesen – Effektive Spesen Wird die Anfahrtszeit berechnet oder nicht? Ab wann werden welche Zeitzuschläge berechnet?

5.1.14 Vertragsänderungen Bedürfen der Zustimmung beider Parteien! Änderungen müssen schriftlich erfolgen.

5.1.15 Gerichtsstand und anwendbares Recht Ist vorallem dann wichtig, wenn der Sitz des Kunden oder IT-Dienstleisters im Ausland ist.

5.1.16 Inkrafttreten, Vertragsdauer In der Regel wird eine Mindestlaufzeit festgelegt (mindestens 1 Jahr) Die Kündigungsfrist sollte mindestens 6 Monate betragen. Dies lässt dem Kunden genügend Zeit einen neuen IT-Dienstleister zu finden und neue SLA’s abzuschliessen. Für den IT-Dienstleister ist eine Finanz- und Ressourcenplanung wichtig.



6. Anhänge Der Zusammenfassung sind Praxisbeispiele als Anhänge beigefügt. Nachfolgend wird auf die wichtigsten Punkte in den Service Level Agreements eingegangen

6.1 Anhang 1.0 – SLA C/S Infrastruktur - Rahmenvertrag Die Anhänge 1.0 – 1.2 beziehen sich alle auf ein Service Level Agreement mit einer Brauerei. Die Infrastruktur umfasst 2-5 Server sowie 40 Arbeitsstationen. Der Rahmenvertrag regelt den allgemeinen Teil des Vertrages. Die Dienstleistungen sowie die Preise des SLA’s sind in separaten Anhängen aufgeführt. Vertragsänderungen - Können als zusätzliche Anhänge dem Vertrag beigefügt werden (mit entsprechenden Unterschriften) Weitere Punkte welche im Rahmenvertrag geregelt sind - Mitwirkungspflicht Kunde - Haftung und Schadenersatz - Eigentum - Zahlungsfristen, Abwicklungsmodalitäten - Gerichtsstand und anwendbares Recht - Inkrafttreten, Vertragsdauer

6.2 Anhang 1.1 – SLA C/S Infrastruktur - Dienstleistungen Im Anhang Dienstleistungen sind folgende Punkte geregelt: - Aktuelle Systemkonfiguration (Abgrenzung) - Arbeitszeitregelung - Umfang der Leistungen in Form von Modulen (der Kunde hätte auch nur einzelne Module auswählen

können) - Explizit nicht enthaltene Leistungen - Voraussetzungen zur Vertragserfüllung durch den Kunden (Zutritt etc.) Hinweis: Bei diesem Vertrag muss der Kunde als Basis einen Vetrag mit dem Hardwarehersteller abschliessen (Garantie auf Systemkomponenten)

6.3 Anhang 1.2 – SLA C/S Infrastruktur - Preise In Anhang Preise sind folgende Punkte geregelt: - Tarife (variable Kosten) - Pauschalen - Stundenansätze, Zuschläge - Rahmenbedingungen (Reisezeit, Teuerung) - Modulpreise (fixe Kosten)

6.4 Anhang 2 – SLA Betrieb Callcenter Dieses Praxisbeispiel beinhaltet ein SLA für den Betrieb eines Callcenters mit rund 200 Arbeitsplätzen. Speziell bei diesem Beispiel ist, dass Lufthansa Systems als weiterer Partner eingebunden ist. Es existieren also die Parteien Kunde, IT-Dienstleister und Lufthansa Systems. Der IT-Dienstleister verleast dem Kunden die Infrastruktur. Dies ist ebenfalls im SLA geregelt. Spezielles am Vertrag - Der IT-Dienstleister ist berechtigt, Leistungen durch Dritte erbringen zu lassen. Inkrafttreten



Das Inkrafttreten wurde auf ein bestimmtes Datum fixiert. Wenn der IT-Dienstleister die Leistungen aber schon voher erbringt, muss der Kunde diese ab dann bezahlten. Ich finde dies etwas problematisch. Es müsste zumindest eine schriftliche Abnahme seitens des Kunden erfolgen.

♦

♦

♦

♦

♦

♦

♦

Leistungen

Dieses SLA ist wie Beispiel 1 ebenfalls Modular aufgebaut. Allerdings muss der Kunde ausser dem Modul Infrastruktur alle anderen Module abnehmen da sonst der Vertrag nicht zu stande kommen würde. In den einzelnen Modulen sind jeweils Betriebszeiten, Ausfallzeiten und Verfügbarkeit und Wartungsfenster geregelt. Gut finde ich, dass auf die einzelnen Definitionen eingegangen wird. Weiter ist eine Leistungsbeschreibung aufgesplittet auf die einzelnen Komponenten pro Modul vorhanden. Die Verantwortlichkeiten sind detailliert in einem Zuständigkeitsmatrix festgehalten.

Leistungsübergabepunkt

Als Leistungsübergabepunkt ist die LAN-Steckdose aufgeführt. Dies heisst, dass bis zum Netzwerkanschluss der Kunde die Verantwortung trägt.

Voraussetzungen

Der Vertrag kommt nur zustande, wenn der Kunde vorgängig einen Vertrag mit Luftthansa Systems abschliesst.

Anhänge

Die Systemkonfiguration ist bis hin auf eine Stückliste heruntergebrochen



INDEX

E A Nutzen Availability Mgmt ..... 22 Nutzen Capacity Mgmt ......... 23 Eigentum .............................. 40 AGB........................................33 Nutzen Change Mgmt........... 17 Ä Elemente Specsheet.............. 37 Nutzen Cost Mgmt................ 24 Error Control .......................... 11 Änderungsmanagement .........28 Nutzen des Configuration

Management ...................... 13 Erstellung SLA ..................... 39 Änderungsplan .......................30 Exklusivbetrieb....................... 35 A

Nutzen des Contingency Management ...................... 25

F Anwendbares Recht .............40 Finanzielles........................... 40 Application Manager...............15

Nutzen Incident Mgmt .......... 10 Full Release........................... 18 Aspekte Verfügbarkeit .........25 Nutzen ITIL-Modells ............. 26 G Attribute Change Record .....17 Nutzen Problem Mgmt ......... 11 Garantie ................................ 39 Attribute Incident Records.....9 Nutzen Release Mgmt .......... 19 Gerichtsstand....................... 40 Aufgaben Availability Mgmt.22 Nutzen SLA ........................... 33 Gründe Changes .................. 15 Aufgaben Capacity Mgmt.....23 O Grundgedanken ITIL ............ 26 Aufgaben Change Mgmt ......15 OLA........................................ 20 H Aufgaben Cost Mgmt ...........24 Operational Level Agreement. 20 Aufgaben DSL ........................18 Haftung und Schadenersatz 40 Organisatorische Einb.

Incident Mgmt ................... 10 Aufgaben Incident Mgmt........8 Hardware Store .................... 18 Aufgaben Problem Mgmt .....11 Herausforderung Release

Mgmt ................................. 19 P Aufgaben Release Mgmt ......18 Package Release ................... 18 Auswirkung SLA...................32 Hersteller/ interner Lieferant: Partner Availability.............................21 SLA .................................... 20

SLA .................................... 20 Availability Management......22 Höhere Gewalt...................... 40 Performance Management..... 23 B I Pricing .................................... 24 BEBU (Kostenarten, -träger und

– stellenrechnung) ..............24 Incident .............................. 8, 21

Prioritätsstufen ....................... 36 Incident Management ............ 8 Problem ................................. 21 Beispiele Incident ...................8 Incident Mgmt Prozess .......... 8 Problem Control ..................... 11 Betriebszeiten.........................35 Inhalte SLA ........................... 39 Problem Management .......... 11 Beurteilung SLA......................32 Input Kosten ......................... 24 Problem Manager................... 15 C IT-Dienstleister oder Abteilung Prozesse Capacity ................................21 SLA .................................... 20

ITIL-Prozess......................... 6 Capacity Management..........23 ITIL R Begriff .................................. 5 Change Advisory Board..........15 Rahmenvertrag ..................... 41 K Change Management .....15, 21

Haftung............................... 41 Change Management Prozess16 Kapazitätsplanung ................. 23 Release.................................. 21 Change Manager....................15 Kennzahlen.............................. 8 Release Management ........... 18 Changerecord .......................24 Availability-Mgmt................ 22 Release Manager ................... 15 Charging.................................24 Change-Mgmt .................... 17 Releasetypen ........................ 18 CI, Configuration Item ..........14 Configurationsmgmt........... 13

Arten................................... 18 Concurrent User .....................40 Kennzahlen ITIL................... 8 Reliability................................ 25 Configuration ........................21 Problemmagt-Kennzahlen . 11 Request for Change Configuration Management ....13 Releasemgmt..................... 18

RFC...................................... 8 Configuration-Management Datenbank

Kennzahlen Availability Mgmt........................................... 22 Resilience............................... 25

Ressourcen Management ...... 23 CMDB.................................10 Kennzahlen Change Mgmt .. 17 S Contingency (Disasterfall) ......37 Kennzahlen für das

Configuration Management 13 Schnittstellen andere Prozesse............................ 10

Contingency Management ...25 Contingency Plan .................25 Kennzahlen Incident Mgmt.... 8

Schnittstellen SLA................ 21 Contingengy..........................21 Kennzahlen Problem Mgmt . 11 Schnittstellen zu anderen

Prozessen .......................... 14 Cost .......................................21 Kennzahlen Release Mgmt.. 18 Cost Management.................24 Kosten.................................... 40

Schnittstellenvereinbarung Critical ....................................36 Kostenkontrolle.................... 24 Beispiel............................... 38 D Kritische Erfolgsfaktoren .... 10

Security .................................. 25 Kunde Definition SLA.........................31 Service Level Agreements... 31 Definitionen Incident ..............8 SLA .................................... 20 Service Level Management 20,

21 L Delta Release .........................18

Demand Management ............23 Leistungen SLA.................... 39 Service Level Manager........... 15 DHS ........................................18 M Service Spezifikation .............. 37 DHS (Definitiver Hardware

Store) .................................18 Maintainability ........................ 25 Serviceability .......................... 25 Major Change ........................ 15 Servicekatalogs................ 20, 37 Diese Katastrophen-Vorsorge

...........................................25 Manager Finanzabteilung ...... 15 Signifikant Change ................. 15 Minor Change ........................ 15 SLA DSL ........................................18 Mitwirkungspflicht ............... 39 Inhalte ................................ 39 DSL (Definitive Software Library)

...........................................18 N Inhaltsverzeichnis SLA ....... 37 Normal ................................... 36 SLA Aktivitäten..................... 20



SLA Betrieb Callcenter ...........41 SLA C/S Infrastruktur -

Dienstleistungen .................41 SLA C/S Infrastruktur - Preise 41 SLA C/S Infrastruktur -

Rahmenvertrag...................41 SLA ist sinnvoll.....................32 SLA’s ......................................31 Software Library ...................18 Stolpersteine eines SLA .........32 T Treuepflicht ...........................40 Typen Changes.....................15 U Urgent.....................................36

Urheberrechte ...................... 39 V Verfügbarkeit.....................22, 25 Verhältnis zwischen IT und

Enduser............................. 32 Vertragsänderungen.......40, 41 Vertragsdauer....................... 40 Vertragsdokumente ............. 39 Vertraulichkeit ...................... 39 Vollkostenbasis ...................... 24 Voraussetzung SLA ............. 31 W Wartbarkeit ............................ 22 Workload Management.......... 23

Z Ziele Availability Mgmt......... 22 Ziele Capacity Mgmt............. 23 Ziele Change Mgmt .............. 15 Ziele Contingency Mgmt ...... 25 Ziele Cost Mgmt.................... 24 Ziele Incident Mgmt................ 8 Ziele Problem Mgmt ............. 11 Ziele Release Mgmt .............. 18 Zuständigkeiten...................... 39

SLA .................................... 39 Zuverlässigkeit ....................... 22

Disclaimer Alle angebotenen Inhalte dienen ausschliesslich zu persönlichen Information. Eine kommerzielle Nutzung der Inhalte ist nicht gestattet. Die hier öffentlich zugänglich gemachten Dokumente, inklusive weiterer dazugehöriger Daten wie z.B. Bilder, Grafiken, sind urheberrechtlich geschützt. Verantwortlich für die Inhalte sind die jeweiligen Autoren (siehe jeweilige Quellen). Einzelne Vervielfältigungen, z.B. Kopien und Ausdrucke, dürfen nur zum privaten und sonstigen eigenen Gebrauch angefertigt werden. Alle Inhalte auf diesem Server werden ohne Gewähr für ihre Richtigkeit, Aktualität und Vollständigkeit wiedergegeben. In keinem Fall wird für Schäden, die sich aus der Verwendung der abgerufenen Informationen ergeben, eine Haftung übernommen. Für die Inhalte der über Hyperlinks verbundenen Angebote auf anderen Servern sind die jeweiligen Betreiber verantwortlich.


Documents

Aus ALM- (Asset & Liability Management) Überlegungen …roger-wiesendanger.ch/files/studiportal/ZF SLAM.pdf · SLAM Eidg. Dipl. Wirtschaftsinformatiker INHALTSVERZEICHNIS 1. Service