1
Q
Was ist ITSM?
A
- IT Service Management
- geplanter Einsatz von Gütern zur Unterszützung von Geschäftsanforderungen
- ermöglichen von schnellem und effizienten reagieren auf ändernde Bedürfnisse, ungeplante Ereignisse und ändernde Geschäftsanforderungen
- kontinuierliche Evaluation Prozessen und deren performanz um Möglichkeiten für Verbesserungen zu erkennen
2
Q
Was ist ITIL?
A
- IT Infrastructure Library
- Sammlung von Best Practices im Bezug auf den Aufbau effektiver IT Prozesse.
3
Q
Was sind Beispiele für Services einer IT?
A
- Technisch Basierte
- Nezwerkzugänge, Datenbanken
- System Basierte
- E-Mail, ERP-Zugänge
- Business Orientierte
- Online Shop, Kreditkarten authentifizierung
- Service und Support
- Arbeitsplatz Unterstüzung, Schulungen
- Betrieb laufender Dienste
- Backup, Datenspeicherung
- Seltene
- Beschaffung und Lagerung von IT Infrastruktur
4
Q
Was ist der Unterschied zwischen einem Incident und einem Problem?
A
- Problem Resultat mehrerer (oder besonders schlimmer) Incidents
- Ziel ist es die gemeinsamen Ursachen zu finden un zu beheben
- Incidents sind akute Ausfälle die das erfüllen von Business Aufgaben behindern
- beschränken sich meist auf ein CI
5
Q
Was sind potentielle Vorteile von ITIL?
A
- Zwingt zum Überdenken eigener Prozesse
- Bietet einen strukturierten Ansatz zu allen IT Aspekten
- Gut angenommen. Generell kein Widerstand zu erwarten bei Einführung.
- Verhindert Wissensverlust durch knowledge Management
- Bietet Karrieremöglichkeiten durch Spezialisierung
- Best Practice Ansatz: Kein Bedarf das Rad neu zu erfinden
- Erstellt eine einheitliche Terminologie
- Unterstützt genug flexibilität
6
Q
Was sind potentielle Nachteile von ITIL?
A
- Keine wissenschaftlich nachweisbaren Vorteile
- Verhindert Innovation
- Erstellt unnötigen Consultant Markt
- wird zu einem eigenen Ziel (in konkurenz zum Geschäftsziel)
- Gefahr sich durch ITIL zu sicher zu fühlen und auf verbesserungen zu verzichten
- Es ist nicht die Lösung aller Probleme
- Sehr bürokratisch => Overhead
7
Q
Was sind Vorteile durch den Einsatz von ITSM?
A
- Gesteigerte Effizienz
- Verbesserung des Kundenservice
- Verbesserte Systemstabilität
- Verringerte Kosten
- Verbesserte compliance und Accountability
- Verbeserung interner IT Abläufe
8
Q
Business Alignment
Was bedeutet IT-Business Alignment
A
In wie weit die IT in das erreichen des Geschäftszieles eingebunden ist und nicht als eigenständige Organisation und notwendiges Übel angesehen wird.
9
Q
Business Alignment
Wie findet man heraus wie aligned man ist?
A
- Fragenkatalog
- Wo ist der Parkplatz des CIO
- Wem ist der CIO unterstellt
- Nimmt der CIO an allen Geschäftsratssitzungen teil?
- Sind IT Metriken teil des Geschäftsberichtes?
- Kann jeder IT Mitarbeiter das Geschäftsziel beschreiben
- Können Angestellte aus anderen Abteilungen IT Mitarbeiter benennen
- Gibt es konkrete 5 Jahrespläne für die IT
- Wann wurde das letzte Mal ein IT mitarbeiter Mitarbeiter des Monats
10
Q
Wie verbessert man das Alignment der IT?
A
- Pläne zur Kostenreduzierung vorstellen
- Mit Abteilungsleitern reden und Pläne für deren Top 5 IT Probleme finden
- Standardkonfigurationen für PC’s vorschlagen
- Internes Schwarzes brett mit nützlichen Infos füllen
- Abteilungsleiter zu IT-Bereichsmeetings einladen
- Personalisierung der IT Seiten mit Fotos
- Daür plädieren IT Metriken in Geschäftsbericht aufzunehmen.
11
Q
Was sind die drei Arbeitsbereiche der ITSM?
A
- Operate (assets)
- React (to People)
- Improve (Processes)
12
Q
Service
Was ist ein Service?
A
Eine Dienstleistung die durch die IT-Abteilung angeboten wird.
13
Q
Service
Was sind zu betrachtende Aspekte bei der Definition eines Services?
A
- Wer sind die Nutzer?
- Was sind die Anforderungen der Nutzer?
- Was sind die Leistungen
- Welche Informationen muss ein Nutzer liefern?
- Was sind zugangsmechanismen?
- Welche Resourcen/Skills/Personen werden für die Durchführung benötigt?
- Wie wird der Service kontrolliert?
- Was sind vertragliche Anforderungen
- Wie wird es gemessen? Metriken
- Wie verfügbar ist der Service
- Was ist die Kapazität
- Was ist die Service Level requirement
- Was sind SLA Metriken
- Was sind die Sicherheitsanforderungen
- Was sind die Kosten
14
Q
Service
Wie sollte man bei der Service Definition vorgehen?
A
- Anforderungsanylse
- Durchfühbarkeitsanalyse
- Modelle entwickeln
- Untersuchen ob aktuelle Services den Service schon anbieten
- Entwickeln von Modellen und Tests
- Abschätzung des Implementierungsaufwandes
- Zuweisen von Mitarbeitern
- Verbesserungsprozesse entwickeln
- Service Name
15
Q
Service
Was ist ein Service Katalog
A
- Beschreibung aller angebotenen IT Services mit ihren Preisen und Leistungen
- Sammlung von SLAs
- Abteilungen können sich Services aussuchen
16
Q
Service
Was sind häufige Probleme des Service Katalogs?
A
- zu detailierte/generelle Definition der Services
- Sind nur theoretisch vorhanden, werden nie umgesetzt
- Zu viel technischer Jargon
- Zu wenig Rücksprache mit Interessensgruppen
- Fehlendes Verständniss von IT Services
17
Q
Self Service
Was ist Self Service
A
- Versuch Nutzer zu ermöglichen sich bei Problemen zuerst selber zu helfen
- Meist Webbasiert
18
Q
Self Service
Was sind die Ziele vom Self Service?
A
- Verkürzen der benötigten Zeit zum Erfassen von Incidents udn Service Requests
- Zugang zu Unternehmenswissen ermöglichen
- Nutzer ermöglichen Probleme selber zu diagnostizieren
- Selbstständige Hardwarebeschaffung durch Nutzer (nur Kleinstbeträge)
- Ermöglicht Echtzeitfeedback ob Probleme eventuell bereits behoben
- Verringern von Anrufen ob an einem Problem gearbeitet wird
- Lückenlose Integration in das Intranet
19
Q
Self Service
Was sind häufige Probleme des Self Service?
A
- Geringe Nutzung
- Veraltete/Falsche Informationen werden dargestellt
- Unangemessener Inhalt wird geteilt
- Fehlende Integration in restliche IT Abteilung
- Schlechte Überprüfung des Nutzens
- Frustration wenn Lösung nicht gefunden werden kann
20
Q
Self Service
Typische Komponenten eines Self Service Portals
A
- Forum
- Context sensitiver Inhalt (bezogen auf Position)
- Beantragen von Services
- Ticketing System
- FAQ’s, Lösungsdatenbank
- Zufriedenheitsumfrage
- Kummerkasten
- Links zum Trainingsportal
21
Q
Self Service
Ist Self Service immer angebracht?
A
- Ja
- kann zu einer deutlichen entlastung der Service Desk führen.
22
Q
Self Service
Was sind besondere Anforderungen an ein Self Service System?
A
- Es muss besonders Nutzerfreundlich sein
- selbsterlärend
- übersichtlich
- Möglichst wenig UI Felder
- Nutzer müssen im Einsatz geschult werden
23
Q
Interaction Management
Was ist Interaction Management?
A
- Das Managen von Interaktionen zwischen IT Angestellten und Mitarbeitern anderer Abteilungen oder externer Nutzer
24
Q
Interaction Management
Was sind die Ziele des Interaction Management?
A
- Steigern der Effizienz von Kommunikationen
- Verringern vom Rückfragebedarf
- gezieltes Routen an zuständige Personen
- Konsistenz über alle Kommunikationswege erstellen
25
Interaction Management
Was sind häufige Probleme des Interaction Managements?
* Zu hohe Last an Anfragen
* Verlust von Detailinformationen
* Zu hohe Antwortzeiten
* Zu hoher Einsatz unpersöhnlicher Interaktionen
* Qualität/Sinn von automatisierten Antworten
* Falsches Routing
* Missverstädnisse
26
Interaction management
Was sind geeignete Metriken?
* Anzahl an Interaktionen
* Anzahl von Antworten in vorgegebener Antwortzeit
* Anzahl von Antworten das sich um etwas gekümmert wurde
27
Interaction Management
Welcher Rahmen wird vom Interaction Management überwacht
Jegliche Kommunikation aller Arten.
28
Request Management
Was ist Request Management?
* Handhaben von eingehenden Anfragen von Nutzern
*
29
Request Management
Was sind die Ziele des Request Managements?
* Genaues bestimmen des benötigten Service am Servicedesk
* Sammeln aller benötigter Informationen
* Direkts lösen der Anfrage
* Weiterleiten der Informationen an zuständige Abteilung
* Status updates an Nutzer geben
* Einen Ansprechpartner für alles schaffen
30
Request Management
Was ist der Unterschied zum Incident/Problem Management?
* schwer zu unterscheiden
* Requests haben in der Regel einen Approval Prozess
* Request
* Einen Wunsch nach etwas äußern, um etwas Bitten
* Incident
* akutes Aufreten eines Problems
31
Request Management
Was sind häufige Probleme des Request Managements?
* Verlängerte Antwortzeit
* Ungenaues/Falsches Erfassen der Anforderung
* Falsche Zuweisung an 2. Level
* Rückfragen benötigt
* Fehlende Sichrbarkeit des Bearbeitungsstatus
32
Request Management
Was sind mögliche Metriken des Request Manegement?
* Anzahl abgeschlossener Anfragen in einem Zeitintervall
* Anzahl benötigter Rückfragen
* Anzahl neu zugewiesener Anfragen
33
Request Management
Was sind typische Request Typen
* Fragen
* Support Anforderungen
* Beschwerden
* Service Anforderungen
* Profil Updates
* Equipment Austausch
* Nachfüllen von Verbrauchsgütern
* Buchen von Ressourcen
34
Request Management
Was bewirken Skripte?
* Konsistente Nutzerexperience
* können missbraucht werden
* Verringern gefahr der Informationsverlustes
35
Incident Management
Was ist Incident Management?
Das bearbeiten akuter Ausfälle, die den normalen Betrieb stören.
36
Incident Management
Was sind die Ziele des Incident Managements?
* Schnell einsatzfähigkeit wiederherstellen
* Schaden für das Geschäft minimieren
* Finden von kurzfristigen Workarounds und langfristigen Lösungen
* Minimieren der Anzahl von incidents die erneut geöffnet werden müssen
* Minimieren der benötigten Interaktionen (Fix bei erster Interaktion)
37
Incident Management
Was sind häufige Probleme des Incident Management?
* Falsche Zuweisung des Incidents
* Fehlende Informationen
* Incident lässt sich nicht lösen
* Hoher Zeitaufwand
* Inkonsistener Lösungsansatz
* Hoher Bedarf an Rückfragen
* Fehlende konsolidierung mit Wissensdatenbank
* Workarounds werden als Fixes angesehen
* Falsche Kategorisierung des Incident
38
Incident Management
Was sind Sub Prozesse des Incident Managements?
Incident investigation / analysis
Klassifizierung und front line Support
Untersuchen und diagnose
Lösen und beheben des Problems
Schliesen des Problemes
39
Incident Management
Was sind potentielle Metriken?
* Anzahl geschlossener Incident im Front Line Support
* Anzahl geschlossener Incidents in einem festegelegten zeitlichen Rahmen
* Durchschnittliche lösungszeit von Incidents
* Anzahl wieder geöffneter Incident
* Anzahl an neuzuweisungen
* Gesamtanzahl an Incidents
* Verteilung von Incidents (zeitlich/Abteilung/GEographisch)
40
Incident Management
Welche Kategorisierungswege gibt es?
* Symptombasiert
* Betroffenes CI
* Kombinierte Asset/Symptom Hierachie
* Service Bezogene Kategorisierung
* Funktionale / Abteilungsbezogene Kategorisierung
* Ursachenbezogen
41
Incident Management
Wann sollte kategorisiert werden?
1. Beim Eintreffen des Incidents am Frontline
2. Nach schliesen des Incidents
3. Wenn die Ursache gefunden wurde
42
Incident Management
Was sind Gründe für kategorisierung?
* Erlaubt Suche in Knowledge Database um frühere Lösungen zu finden
* Verbessert Routing der Probleme
* Einhalten von SLAs
* Berichterstellung
43
Incident Management
Was sind häufige Probleme bei der Kategorisierung?
* Zu detailierte/Grobe Kategorisierung
* Zu komplexes Kategorisierungsmodell
* Zwang immer gleich viele Elemente pro Ebene
* Einsatz von Akronymen und Jargon
* Zu gleiche Optionen
* Zwang bis zum genauesten Detailgrad zu kategorisieren
44
Incident Management
Wie priorisiert man Incidents?
* Anzahl betroffener Personen
* Schweregrad des Ausfalls
* Priorität des betroffenen Services
* Rolle der betroffenen Person
* Effekt auf das Geschäft
* Zeitsensibilität
* Gefahr SLA zu brechen
45
Incident Management
Wieso sollte man Incidents priorisieren
* Effektiveres Nutzen von Arbeitszeit
46
Incident Management
Was sind häufige Probleme beim Priorisieren?
* Falsche Priorisierung (zu hoch/niedrig)
* Einsatz interner/externer Prioritäten
* Einsatz von Standard Priorität
* Ändern der Priorität im lebenszyklus eines Incident
47
Incident Management
Wie lautet die Formel zur Abschätzung der Priorität
Schweregrad x Anzahl betroffener Nutzer x Dringlichkeit
48
Incident Management
Wozu dient das Incident Status Model?
* Rückmeldung an Requester über Fortschritt
* Information für Management über aktuelle Auslastung
* Informationsfluss, dass andere an einem incident weiter arbeiten können
49
Incident Management
Was ist bei der Kommunikation mit Nutzern im Rahmen der Incidentbehebung zu beachten?
* Weniger ist mehr
* bei zu viel input wird wichtiger input nicht wahrgenommen
50
Incident Management
Welche Zuweisungsarten gibt es?
* Manuelle Zuweisung
* automatisierte Zuweisung
* Automatisierte Gruppenzuweisung
* automatisierte / Manuelle einzelzuweisung
51
Incident Management
Was ist das Problem bei persöhnlicher Wahl von Incidents?
* Bearbeiter können sich auf High Profile Incidents beschränken
* Falsche Wahrnehmung von Mitarbeiterwert
* Aufbau von Wissensilos
* Bearbeiter velassen Komfortzone nicht
52
Incident Management
Was sind mögliche Routingverfahren bei der automatisierten Zuweisung?
* Skill basiert
* Geographisch basiert
* Erfahrungsbasiert
* Verfügbarkeits basiert
53
Incident Management
Was sind mögliche Incident Diagnose Techniken?
* Untersuchen von Unterschieden (in Konfigurationen) zu wie es vorher war
* Newtons Gesetz. Was wurde vorher gemacht
* Logs durchsuchen
54
Incident Management
Was sind bessere Fragen im Rahmen der Incident Diagnose?
* Wie ist ihnen das Problem aufgefallen
* Wie wissen sie ob der Fehler behoben ist
* Was ist die aktuelle Situation
* Werden weitere Informationen benötigt
55
Incident Management
Wie sollte sich der Frin Line Support verhalten und was bringt das Verhalten?
* SMILE
* Immer freundlich sein und auf Nutzer eingehen
* sich voll dem Erfolg des Nutzers verschreiben
* Nutzer werden kooperativer
56
Incident Management
Was ist ein Workaround?
Temporäre Lösung die es ermöglicht dein betroffenen Service vorerst wieder zu benutzen
57
Incident Management
Wann wird ein Workaround zu einem Fix?
Wenn er das zu grunde liegende Problem beseitigt.
58
Incident Management
Wann sollte ein Incident geschlossen werden
Sobald die zu grunde liegende ursache gefunden und behoben ist. Nicht sobald der Einsatz des Services wieder möglich ist.
59
Incident Management
Wer kann für das Zweisen von Incidents verantwortlich sein
Manager
60
Knowledge Management
Was ist Knowledge Management?
Das zentrale bereitstellen einer Wissensdatenbank um Nutzern den Zugriff auf bestehendes Unternehmenswissen zu ermöglichen
61
Knowledge Management
Was sind Ziele des Knowledge Management?
* Wissensverlust durch ausscheiden von Mitarbeitern reduzieren
* Wiederverwendung von bereits erzeugtem Wissen fördern
* Senken der benötigten Zeit für Incident lösung
* Schnellen und einfachen Zugang zu Unternehmenswissen
62
Knowledge Management
Was sind häufige Probleme?
* Veraltetes Wissen
* Schlecht geschriebener Inhalt
* Ablehnung von Mitarbeitern erarbeitetes Wissen preiszugeben
* Schwieriger Zugang
* Lokale Wissensilos
* Unzureichende Zulassungsprozesse
* Mangelnde zugewiesene Zeit und Ressourcen
* Schwer genaue Geschäftsvorteile klar zu machen
63
Knowledge Management
Was sind mögliche Metriken
* Anzahl mit KM eintrag bearbeiteter Incidents
* Anzahl an Einträgen
* Wie oft Einträge überarbeitet werden müssen
* Anzahl eingereichter neuer Einträge
* Gesparte Zeit durch Einsatz von KM
64
Knowledge Management
Was sollte in einer Knowledge Management Solution enthalten sein?
* Inhalt
* Suchfunktion
* Zulassungsprozesse
* Wartung
* Nutzungsanalyse
* Feedbackzyklen
65
Problem Management
Was ist Problem Management?
Der Versuch Probleme (welche aus mehreren oder besonders schweren Incidents entstehen) zu lösen um das weitere Auftreten von Incidents zu vermeiden.
66
Problem Management
Was sind die Ziele des Problem Managements?
* Probleme lösen
* Auftreten von Incidents verhindern
* Services Stabiler machen
* Prozessverbesserungen
67
Problem Management
Was sind häufige Probleme?
* Probleme werden nicht erkannt
* Incident falsch kategorisiert
* Zu wenig Ressourcen um vorbeugende Masnahmen einzuleiten
* Fehlende benötigte Daten
* Schlecht definierte Abhängigkeiten zwischen CIs
* Unrealistische Erwartungen
68
Problem Management
Was sind potentielle Metriken des Problem Managements?
* Behobene Probleme in einem Zeitintervall
* Verhinderte Incidents
* Eingesparte Kosten durch weniger Serviceausfälle
* Anzahl laufender Programme
* Anzahl aufgetretener Incidents die dem Problem zugeschrieben werden
69
Problem Management
Wie identifiziert man Probleme?
* Statistische Analyse
* wiederkehrende Incidents
* besonders Kostenintensive Incidents
* Automatisierte Problem Vorschläge
* Problemliste durch Abteilungsleiter
* Nutzerforderung
* Management Sponsored
* Besonders schwere Incidents
* Risiko Analyse
* Qualitative Messungen
70
Problem Management
Was sollte bei der Problem Analyse gemacht werden?
1. Rahmen des Problems definieren
2. Historische Daten analysieren
3. Geimeinsame Symptome identifizieren
4. Unterliegende Prozesse, Werkzeuge und Umgebungen analysieren
5. Mögliche Grundursache herausfinden
6. Hypothese entwickeln
7. Weitere benötigte Datensätze sammeln
8. Test der hypothese
9. Hypothese verbessern
10. Hypothese akzeptieren oder verwerfen
71
Problem Management
Was ist Statistical Process Controll (SPC) ?
* anerkannte Qualitätsmanagementmethodology
* Proaktives Messen von Prozessmetriken welcher einer bekannten Varianz unterliegen wenn alles funktioniert
* Änderungen in der Varianz können herausgefunden werden
* Fehlerentdeckung möglich ohne Ursache zu kennen
* kann auf verschiedene Szenarios übertragen werden
72
Problem Management
Was sind die Regeln General Electrics?
1. Liegt ein Punkt auserhalb der dreifachen Standardabweichung
2. Liegen 2 von 3 Punkten auserhalb der doppelten Standardabweichung
3. Liegen 4 von 5 Punkten auf einer Seite außerhalb der einfachen Standardabweichung
4. 8 Punkte liegen auf der selben Seite von der Mittellinie
5. Fünfzehn Punkte liegen innerhalb der einfachen Standardabweichung
73
Problem Management
Wie ist ein Control Chart aufgebaut?
* Fünf Linien
* Mittellinie
* Obere/Untere Kontrollinie
* Obere/Untere Alarmlinie
74
Problem Management
Was sind die üblichen Verdächtigen?
* Nutzer (falsches training, falsche Bedienung, Überlastet)
* Prozesse (unrealistische Anforderungen, falsch Modelliert)
* Material/Equipment (Falsche Haldbarkeitsabschätzung)
* Design (fehlerhafte Kalkulationen, Randbedigung nicht beachtet)
* Informationen (nicht zugägnlich, veraltet, fehlerbehaftet)
* Change (unauthorisiert, fehlerhaft durchgeführt)
75
Problem Management
Wie testet man eine Hypothese?
* Problem nachspielen über eine Menge an definierten schritten und überprüfen ob problem auftritt
* Mit hoher Wahrscheinlichkeit vorhersagen, wann das nächste Incident auftritt
* Logische Schlussfolgerung erstellen und präsentieren
* Szenarios identifizieren die vermutlich den Incident hervorrufen
76
Problem Management
Wie ist beim Beheben des Problems vorzugehen?
* Erfolgskriterien definieren
* Change Request erstellen
* Bekannten Fehler dokumentieren
* Event Management nutzen um fehler zu vermeiden
* Zusätzliche Daten erheben
* SPC Parameter anpassen
* Bei Nutzer Problemen: Schulungen veranlassen)
* Messen der Effekte des Problem managements auf die Umgebung
77
Problem Management
Was kann gegen das Beheben eines Problems sprechen
* Kosten Nutzen Faktor geht nicht auf
* Es kann zu anderen Problemen führen
* Anzahl an Änderungen zu groß
* beteiligtes Personal streubt sich Fehler einzugestehen
* Fehlendes Budget
* Problem ist dem Geschäft nicht wichtig genug
78
Change Management
Was ist das Change Management
Das organisierte einspielen von Änderugnen in ein System mit dem Überprüfen ob die ÖÄnderungen nebeneffekte hat
79
Change Management
Was sind die Ziele des Change Management?
* Effizientes und fehlerfreies durchführen von Änderungen
* Service Unterbrechungen minimieren
80
Change Management
Was sind häufige Probleme?
* Änderungen unzureichend definiert
* Fehlende/fehlerhafte Dokumentation von Abhängigkeiten
* Unkontrollierte/Ungeplante Änderungen
* Unzureichende Einbindung in die Planungsphase der Änderung
* Unzureichende Kommunikation
* Konkurrierende Ressourcenbedürfnisse
* Zu detaillierter Change Plan
81
Change Management
Was sind mögliche Metriken?
* Erfolgreich durchgeführte Änderungen
* in einem definierten Zeitrahmen
* Anteil an termingerechten Änderungen
* Anteil im Budgetrahmen gebliebener Änderungen
* Anzahl abgebrochener Änderungen
* Durchschnittliche Zeit bis Änderung durchgeführt wurde
82
Change Management
Was sind typische Change Typen?`
* 1:1 Ersetzung
* Vergleichbarer Austausch
* Upgrade einer Komponente
* Downgrade einer Komponente
* Hinzufügren/entfernen
* Modifikation
* Neuinstallation
* Umzug
83
Change Management
Was ist das Problem bei der Klassifizierung von Change Requests?
* Änderungen können (so unbedeutend wie sie auch scheinen) große Auswirkungen haben
* Beispiel: Challenger Dichtungsring
84
Change Management
Was gibt es für Klassifizierungen?
* Normal
* Minor
* Major
* Significant
* Letzten 3 nicht eindeutig unterschieden in ITIL
85
Change Management
Woraus sollte ein Change Modell bestehen?
* Ziel der Änderung
* Benötigte Arbeitsschritte
* Reihenfolge der Arbeitsschritte
* Erwartete Dauer der Arbeitsschritte
* Abnahme zyklen
* Meilensteine und Checkpoints
* Mögliche Pausenpunkte
* Benötigte Skills und Werkzeuge
* Zugewiesene Personen
* Notfallplan
86
Change Management
Was ist das grobe Vorgehen bei einer Änderung?
* Anforderungen festlegen
* Erlaubnis erhalten
* Plan erstellen
* Risiko Analyse
* Plan überarbeiten, erneute Abnahme
* Benötigten Resourcen sammeln
* Arbeitsschritte zuweisen
* Arbeitsschritte in Reihenfolge durchführen
* Checkpoints überwachen
* Gesamterfolg messen
87
Cahnge Management
Welche Schritte sollte ein Abnahmeprozess enthalten?
* Finanzielle Abnahme
* Technische Abnahmen
* Logische Abnahme
* Implementierungs Abnahme
* Prüfen ob Rahmenbedingungen eingehalten werden
* Management Checkpoint
* Point of no return Validierung
* Zulassung / Ablehnung
88
Change Management
Welche Informationen werden zur Abnahme benötigt
* Kosten-/Nutzen Analyse
* Geschäftliche rechtfertigung
* Effekte bei nicht Durchführung
* Technische Beschreibung
* List aller betroffenen und abhängigen Systeme
* Worst Case Szenario
* Risikoanalyse
* Erfolgskriterien
* Ressourcenbedarf
89
Change Management
Wie sollte man Tasks definieren
* Beschreibung der duchzuführenden Arbeiten
* Referenzen zu Dokumentationen
* Name der verantwortlichen Gruppe/Person
* Geplante Start- Endzeitpunkte
* Erwartete Dauer
* Abhängigkeiten zu anderen Tasks
90
Change Management
Was ist ein Change Calendar?
* Zentrales Dokument in welchem geplante Änderungen eingetragen werden
* enthält auch geplante Events und reguläre Downtimes
* Kann dazu genutzt werden bei einem regulären Herunterfahren der Server ein Update einzuspielen.
* Enthält die reguläre Auslastung von Services zu verschiedenen Zeiten
* Sollte Filterfunktionen enthalten
91
Change Management
Was ist Risk Management
* Abschätzen und beurteilen potentieller Risiken
* erstellen von Masnahmeplänen
92
Change Management
Wie kann man Risiken beurteilen?
1. Gefahr identifizieren
2. Indentifizieren wer und was betroffen sein könnte
3. Das Risiko Quantifizieren
4. Kontrollmasnahmen festlegen um das Risiko zu verringern
5. Restrisiko bestimmen
93
Change Management
Wie kann man Risiken beurteilen?
Risiko = Wahrscheinlichkeit x Schweregrad
94
Change Management
Wie berechnet man den Schweregrad?
Schweregrad = Umfang x Wahrscheinlichkeit
95
Change Management
Was sind häufige Risiken bei IT Änderungen?
* Kommunikationsprobleme
* Informationsprobleme
* Technologische Probleme
* Datenprobleme
* Falsche Annahmen
* Falsche Abschätzungen
* Ressourcenprobleme
96
Change Management
Was kann man gegen Risiken unternehmen?
Man kann mit hilfe von Virtualisierung Änderungen testen und "trainieren"
97
Change Management
Wozu dienen Kontrollmasnahmen?
Jegliche Masnahmen zum verringern oder vermeiden von Risiken.
98
Change Management
Wie ist die Kontrolmasnahmen Hierachie?
* Risikoärmere alternative finden
* Hardware Redundanz
* Isolieren der Änderung vom Produktionssystem bis fehlerfrei
* Alt und Neusystem parralel betreiben
* Risikobewusst arbeiten
* Regressionstests
99
Change Management
Berechnung des Restrisikos
(Risiko - Effektivität der Kontrollmasnahmen) x Externe Faktoren
100
Change Management
Wozu dient Change Controll?
* Überwachen der verschiedenen Schritte währen einer Änderung
* Checkpoints, Break points , Dauer
* Kontinuierliche Risikoanalyse
101
Change Management
Was ist nach der Implementierung zu beachten?
* CPU Auslastung, Speichernutzung
* Antwortzeiten
* Anwendungslevel Warnungen
* Physische Anzeichen
* Review über den Vorgang
* Untersuchung auf Nebeneffekte
102
Release Management
Was ist Release Management?
* Dem Change Management sehr ähnlich
* Fasst mehrere Änderungen zusammen
* Änderungen die viele Nutzer (und daher über einen langen Zeitrahmen) betreffen
* OS wechsel
103
Release Management
Bekannte Probleme
* Fehlende Übersicht über durchzuführende Änderungen in einer Umgebung
* Unzureichende Menge an Details bezüglich geplanter Changes
* Fehlende Übersicht über Zständigkeiten und hierachie foo
* Unklare Definition des Release Prozesses
* Release Umfang wird immer größer
* Nicht alle benötigten Informaitonen / Abhängigkeiten im Package
* Schwierigkeit festzsustellen, ob der Release zu jedem Knotenpunkt kam
104
Release Management
Was sind die Ziele des Release Managements?
Fehlerfrei und Zeitnah änderungen durchführen
Serviceunterbrechungen minimieren
105
Release Management
Welche Releasetypen gibt es?
* Geplanter Wartungs Release
* basiert auf festgelegten Intervallen
* Einmalige / Projektbezogene Releases
* ungeplantes Bundel an Changes
* Inkrementeller Release
* Gleichstellungsrelease
106
Release Management
Wie können verschiedene Systeme helfen?
Änderungen können zuerst auf Testsystemen auf virtuellen Maschinen getestet werden. Dadurch ist eine bessere Risikoanalyse möglich.
107
Release Management
Was sind Packages
Sammlung an Anforderungen des Change
Enthalten
* Inventarliste
* Erfolgskriterien
* benötigte Arbeitsschritte
108
Release Management
Welche Abnahmephasen gibt es?
1. Test des Packages auf Vollständigkeit
2. Formale Abnahme im Pre Production System
109
Release Management
Was sollte das Release Team nicht machen?
* Besser wissen was zu tun ist
* Rahmen der Änderung ändern
110
Release Management
Welche Fragen sollten vor der Abnahme gestellt werden?
* Sind die Abnahmekriterien klar und unmissverständlich?
* Haben Team Mitglidier die Erfahrung um eine aussagekräftige Entscheidung zu treffen?
* Deckt der Abnahmeplan alle OS Kombinationen ab?
* Können die Änderungen in einer Pre Production Umgebung getestest werden?
* Verhält sich die Änderung wie vorhergesehen
* Waren die Implementierungsschritte korrekt?
* Ist das Release Team zuversichtig
111
Release Management
Welche Releaseaktivitäten gibt es?
1. Identifizieren der Vorbedingungen
2. Vorbedingungen erfüllen
3. Support vowarnen, berit machen
4. Inventar/Inhalte in Position bringen
5. Team training/ Skills zertifizierung und verifizierung
Nach dem release
1. Aufräumen
2. Incident Analyse
112
Release Management
Wann wird ein Change zu einem Release?
* Lange Durchführungszeit
* wenn viele Maschienen betroffen sind
* Wenn die Änderung komplex ist
113
Release Management
Wie legt man den Inhalt eines Releases fest?
* Basierend auf Formaler Anfrage
* entscheidung des Release managers
* Änderung ist Abhängig von anderer Änderung
114
Asset Lifecycle Management
Was ist das Asset Lifecycle Management
Prozess der das Management, tracken und inventar Management von Geschäftsobjekten überwacht
115
Configuration Management
Was ist das Configuration Management?
Sub Disziplin des Asset Lifecycle Managements, welches die aktuelle Kofiguration eines CI Überwacht
116
Configuration Management
Was ist die Configuration management Database (CMDB)
Zentrale Verwaltung welche alle Konfigurationen der CI, sowie weitere Informationen enthält.
117
Asset Lifecycle Management
Was sind die Ziele des Asset Lifecycle managements?
* Den maximalen Gewinn bei minimalem Kostenaufwand aus einem CI herausholen
* Den Lebenszyklus von Gütern verlängern
* Beziehungen und Abhängigkeiten in der IT Infrastruktur verstehen
* Verlässlichkeit und Verfügbarkeit von Assets verlängern
118
Asset Lifecycle Management
Was sind häufige Probleme des Asset Lifecycle Managements?
* Diebstahl von Gütern
* Kein Überblick über Position von Gütern
* Lokale (unbekannte) Lagerstellen
* Eigenmächtige IT Beschaffung durch Abteilungen
* Ungeplante/Unauthorisierte Umzüge
* Unzurechende Informationen über mögliche Garantieleistungen
* Fehlender Überblick über Leasingverträge, daher Strafzahlungen
* Datenverlust
* Nicht genutze Farantien
* Ressourcen werden nicht ausgenutzt
119
Asset Lifecycle Management
Was sind potentielle Metriken?
* Anzahl von genutzten Einheiten
* Anteil von Gütern die nicht dem IT Standard entsprechen
120
Asset Lifecycle Management
Was sind die Grundlegenden Schritte eines Lebenszyklus?
* Bedarfserkennung und Kauf
* Ankunft und Installation
* Einlagerung
* Zuweisung und Auslieferung
* Routine Nutzung
* Inspektion und Test
* Effizienzreview (periodisch)
* Modernisierung / aufbesserung / Upgrade
* Neuzuweisung
* Ausschuss
121
Asset Lifecycle Management
Was ist ein Configuration Item (CI)
Element einer IT Infrastruktur oder zur Ausführung von Services benötigte Komponenten
122
Asset Lifecycle Management
Was sind potentielle Merkmale von CI
* Klassifizierung
* Beschreibung
* Eindeutiger Identifikator
* Status
* Schlüssel Meilenstein
* Hauptsächlicher Nutzen
123
Asset Lifecycle Management
Was für Beziehungen gibt es zwischen CIs?
* Technische Abhängigkeiten
* Logische Abhängigkeiten
* Relation zu Performanz Zielen (SLAs)
* Relation zu Personen
* Beziehungen zu anderen Dingen
* Indirekte Beziehungen
124
Asset Lifecycle Management
Wie befüllt man eine Configuration management Database?
* Identifiziern und bewerten von Quellen
* Entscheiden welche Datensätze von welcher Quelle in den Master kommen
* Datensätze bereinigen (Duplikate löschen)
* Integration der Datenquellen
* Importfunktionen definieren und zeitliche Intervalle festlegen
* Datenvalidierungsregeln implementieren
* Daten in das System importieren
* Daten zusammenfügen und zu einem Datensatz verbinden
* periodisch aktualisieren
125
Asset Lifecycle Management
Was sind häufige Probleme von CMDBs?
* Zu viele Configuration items werden überwacht
* Schlechte Datenqualität
* Zu kompliziertes Datenmodell
* Verschiedene Datenquellen mit verschiedenen Qualitätsgraden
* Schwierigkeiten beim zusammenfügen von Datensätzen
126
Asset Lifecycle Management
Was ist Teil des Configuration Managements Prozesses?
* Planen
* definieren der Ziele
* Identifizieren
* Konfigurationsstrukturen erkennen
* Kontrollieren
* Statusüberwachung
* Verifikation und Audit
127
Asset Lifecycle Management
Was kann das Configuration Management über ITIL hinaus machen?
* Analyse technischen Fortschrittes
* Untersuchen und Festlegen der Anzahl an Standardkonfigurationen in einem Unternehmen
* Technische Definition von Standardkonfigurationen
* Analyse der aktuellen IT Architektur
* Identifizieren notwendiger Änderungen
* Entwickeln von Rationalisierungsplänen
128
Asset Lifecycle Management
Was ist Procurement Management?
Beschaffunsmanagement
Die kontrolle über Anschaffungsentscheidungen innerhalb einer IT
129
Asset Lifecycle Management
Was sind Ziele des Procurement Managements?
* Einfluss auf Kaufentscheidungen bzgl IT nehmen
* Bewerten von Anbietern entsprechend verschidener Kennzahlen
* Verringerung von nicht genehmigten wild einkäufen
* Aushandeln verbesserter Rahmenverträge mit Anbietern
* Automatisieren von Routine einkäufen
130
Asset Lifecycle Managements
Was sind die Aufgaben des Procurement Managements?
* Initiale Kaufanforderungen
* Formale mehrschrittige Finanzielle und technische Abnahmetests entwickeln
* Formales einkaufen und bestellen bei Händlern
* Liefern
* Festhalten von Warenannahmen
* Güter einordnen und ins System eintragen
* Rechnungen prüfen
* Kostenzuweisungen
131
Asset Lifecycle Management
Was ist das Inventory Management?
Gibt aufschluss über die Güter allokierung und eine Übersicht über die (gegraphishe) Verteilung von Gütern
132
Asset Lifecycle Management
Was sind die Ziele des Inventory Managements?
* Minimieren von unnötigen Geldausgaben für Güter die bereits vorrätig sind
* Wiederverwenden und neuzuweisen von zurückgegebenen equipment
* Reduzieren von Lagerbeständen und Lagerkosten auf ein Minimum
* Nachverfolgen von Geschäftskritischen It Infrastructur teilen
* Einen angemessenen Grunstock an vorrätigem IT Equipment halten
* Planen und Abschätzen von zukünftigem IT Nutzen
* Lagerkosten für obsoletes Equipment vermeiden
133
Asset Lifecycle Management
Was sind die Aufgaben des Inventory Managements?
* Einlagern & Transportieren
* Inbetribenahme von CI
* Tägliches Geschäft
* Performanz überwachung
* Resourcenausnutzung überwachen
* Migrationsplanung
* Planen von Rationalisierung
134
Asset Lifecycle Management
Was ist Preventive Maintanance/Routine Operations and Planned Work
Ausführen proaktiver Masnahmen zu Verbesserung der Verfügbarkeit und Stabilität von IT Diensten
135
Asset Lifecycle Management
Was sind Probleme des Routine Operations and Planned Works / Preventive Maintanance
* Keiner hat einen vollen Überblick
* Bessere Werkzeugunterstützung benötigt
136
Asset Lifecycle Management
Wie kann man Routine Aufgaben Schedulen?
* Basiert auf Zeitintervallen
* aufgrund von gemessenen systemcharacteristiken
137
Asset Lifecycle Management
Was ist ein Ongoing Viability Assesment
Das Überprüfen ob es Sinn mache ein CI weiterhin zu betreiben oder ob es effektiver wäre dieses abzuschreiben
138
Asset Lifecycle Management
Was sind potentielle Faktoren des Ongoibng Viability Assesment?
* Kosten nutzen Analyse
* Verfügbarkeit von Ersatzteilen
* Verfügbarkeit von benötogten Fähigkeiten
* Aktuelle Verfügbarkeit und Verlässlichkeit
* Performanz, Kapazität, Erweiterbarkeit
* Physikalische Größe
* Risiken
139
Asset Lifecycle Management
Was ist beim außer Betrieb nehmen zu beachten?
* Rückführen aller Lizenzen
* Datensicherheit gewährleisten
* Potentielle Ersatzteile sichern
* Umweltgerecht entsorgen
* Wurden wichtige Teile des Systems gesichert
* Bei geleasten Sachen den geforderten Zustand herstellen
140
Service Level Management
Was ist Service Level Management?
Bietet die Möglichkeit IT Dienste und die daran zu erwartende Leistungen klar zu definieren und eine Grundlage für Leistungsevaluationen schaffen.
141
Service Level Management
Was sind die Ziele des Service Level Management?
* Performanz der Dienste ist im Rahmen der Vorgaben
* Vermeiden von SLA brüchen
* Identification und Überwachung von Leistungskennzahlen
* Weitergabe von relevanten Informationen an das Service Design um Dienste zu verbessern.
142
Service Level Management
Was sind häufige Probleme des Service Level Managements?
* Unrealistische SLAs die ohne Rücksprache mit verantwortlichen eingegangen wurden
* Zu Komplexe SLA Definitionen
* Zu viele Benachrichtigungen
* Zu hoher Leistungsüberschuss zur SLA
* Umleiten von Ressourcen zu einer nicht einhaltbaren SLA
* Einsatz von SLAs zum Bewerten von Mitarbeitern
* Systeme und Prozesse die das betrügen/Fälschen von SLA Metriken ermöglichen
143
Service Level Management
Was sind Bestandteile einer SLA
* Festgelegten Ziele
* Fokus auf was die SLA überwachen soll
* Reporting Zeitrahmen
* Definition was in einen Zeitrahmen gehört
* Validierungsschalter
* Überwachungshäufigkeit
* Eskalationsgrenzwerte
* Notfallpläne
144
Beyond ITSM
Was sind weitere ITIL V3 Bereiche?
* Design
* Service Catalogue Management
* Supplier Management
* Service Operation
* Access Management
* Event Management
* Request Fullfilment
* Service Operation
* Tranistion Planning and Support
* Service Validation and Testing
* Evaluation
145
Was sind Industrietrends bezüglich ITIL?
* Versuch mehr an Dienstleister abzugeben
* Stetig wachsender Einsatz von Cloud Diensten
* Hardware wird stetig intellegenter
146
In wieweit sollte sich der Service Desk weiterentwickeln?
* Mehr zuständigkeit für nicht IT Fragen
* Human Resources
* Facilities
* Finanzielles
* Geschäftsberichte
147
Was sind weitere ITSM-Standards?
* COBIT Control Objectives for Information and Related Technology
148
COBIT
Was ist COBIT
* Framework zur IT-Governance
* Definiert 34 Prozesse mit 300 Steuerungsvorgaben
* Ist mehr von der Geschäftlichen perspektive
149
Wie unterscheiden sich COBIT und ITIL?
* ITIL
* Wie wird etwas getan
* Fokus auf Nutzerbedürfnisse
* COBIT
* Was ist zu tun, was sind die Ziele
* sicherstellen der IT Governance
* Compliance und Sicherheit
150
IT Governance
Was ist IT Governance
* Unterdisziplin der Geschäftsführung
* Hat den Fokus Wertschöpfung mit der IT zu betreiben
* IT bezogene Fragen von CIO oder Senior MGMT machen?
151
IT Governance
Was sind grundlegende Entscheidungsbereiche?
* IT Prinzipien
* IT Architektur
* IT Infrastruktur
* Bedürfnisse von Geschäftsanwendungen
* IT Investitionen und Priorisierung
152
IT Governance
Was sind IT Principles (Prinzipien)
* Ein Definition wie IT im Geschäft genutzt werden soll
* Sollte im Detail definieren:
* Was ist das angestrebte Operationelle Geschäftsmodell
* Wie wird IT das Geschäftsmodell unterstützen
* Wie wird IT finanziert
1. Enable the business
2. Ensure information integrity
3.
Create a common customer view
4.
Promote consistent architecture
Utilize industry standards
Reuse before buy; buy before build
Manage IT as an investment
153
IT Governance
Was definiert IT Achitecture?
* Eine organisierende Logik für Daten Anwendungen und Infrastruktur
* Wird in Policies, Beziehungen und Kaufentscheidungen festgehalten
* Hat zum Ziel Prozesse und Daten zu standardisieren
* Fragen:
* Was sind die Grundlegenden Geschäftsprozesse und wie hängen diese zusammen?
* Welche Informationen werden für diese Prozesse benötigt?
* Welche technischen Aspekte sollten Standardisiert werden
154
IT Governance
Was ist IT Infrastructure?
* Definition der zur verfügung stehenden IT Ressourcen (Hardware sowie Personal)
* Fragen:
* Welche Infrastrukturdienste sind dem Unternehmen am wichtigsten
* Wie teuer sollten die Dienste sein
* Wie soll die grundlegende Infrastruktur aktuell gehalten werden
155
IT Governance
Was definiert Business Application needs?
(Geschäftsanwendungen)
* Identifizieren von neuen Bedürfnissen
* Kreativität vs Disziplin
* Fragen
* Welchen Markt gibt es für neue Geschäftsanwendungen
* Wie können Experimente helfen diese Ideen zu bewerten
* Wem werden die Ergebnisse der Experimente gehören?
156
IT Governance
Was ist IT Investment & Priorization?
* Zeit um Wertschöpfung aus IT zu machen kürzer als in anderen Bereichen
* Drei Grundlegende Dillema
* Wieviel ausgeben
* Wofür Geld ausgeben
* Wie die Bedürfnisse verschiedener Parteien zusammenbringen
157
IT Governance
Welche Entscheidungsmodelle gibt es?
* Business Monarchie
* Top Management entscheidet
* IT Monarchie
* IT entscheidet
* Feudal
* Geschäftsbereiche entscheiden
* Federal
* Geschäftsführung entscheidet mit Bereichen (IT nicht immer dabei)
* IT Duopoly
* IT und eine andere Gruppe
* Anarchie
* Jeder entscheidet für sich
158
IT Governance
Was sind erfolgreiche Prinzipien?
* Für IT Prinzipien
* IT Duopoly
* Architektur
* IT Monarchie
* Infrastruktur
* Duopoly geeignet, meist wieder IT Monarchie
* Investment
* Außerhalb der IT
159
IT Governance
Was zeichnet gute Governance aus?
* Managers konnten IT Governance beschreiben
* Einbindung verschiedener Verantwortlicher
* Direkte Einbindung verschiedener Manager
* Klare Geschäftsziele für IT Investitionen
* Klar abgetrennte Geschäftsstrategien
* Weniger Änderungen
160
Availability Management
Was ist Availibility Management?
Disziplin dafür zu Sorgen, dass ein Dienst wirklich verfügbar ist
161
Availibility Management
Was sind Ziele des Availibility Managements?
* Klare Definition der Geschäftsanforderung in Bezug auf der Verfügbarkeit des Dienstes
* Planen Messen und Überwachen um die Verfügbarkeit zu verbessern
162
Availibility Management
Was sind die Probleme des Availibility Managements?
* Zu hohe Erwartungen der Geschäftsseite
* Unzureichend definierter Geschäftskatalog und Verfügbarkeitsvorhersagen
* Änderungen verlassen das angesetzte Zeitfenster
* Unzureichend viel Zeit, Ressourcen,
163
Capacity Management
Was ist Capacity Management?
Dafür Sorgen das gegebenen Kapazitäten die Geschäftsanforderungen erfüllen
164
Capacity Management
Was sind die Ziele des Capacity Managements?
* Verstehen was die Gescäftanforderungen bezüglich Kapazität sind
* Planen, messen, überwachen um Kapazitäten besser zu nutzen
165
Capacity Management
Was sind häufige Probleme des Capacity Managements?
* Unvorhersehbare Anfordeungen
* Plötzliche Lastspitzen
* Externe Ereignisse
* Schlechte Abschätzug des Bedarfwachstums
166
Continuity Management
Was ist Continuity Management?
Sollte im einklang mit Business Continuity sein
Definiert mindesanforderungen an Dienste
167
Financial Management
Was ist Financial Management
Kostenprüfung von Diensten
Zuweisen von Finanzen
168
IT Security Management
Was ist IT Security Management
Eigene Disziplin
Sicherheitsanforderungen festlegen und testen.
IT-Management
flashcards
Decks in class (1)
# Cards
