Folie 1

1
Service Support im Überblick
Service Support
Configuration Management
Incident Management (Service Desk)
Release Management (Software Control/ Distribution
)
I T I L
I T I L
Problem Management
Change Management
Unterstützung/ Information
Quellen Köhler, P., ITIL, Das IT-Servicemanagemen
t Framework, Berlin, Heidelberg 2007 Elsässer,
W., ITIL einführen und umsetzen, Leitfaden für
effizientes IT-Management durch
Prozessorientierung
2
Incident-Management mit Service-Desk
KPI Key Performance Indicator
Service-Desk (früher Benutzerservice/Helpdesk)
Kommunikationsschnittstelle zw.
Informationstechnologie und den Benutzer/Kunden,
Schaltstelle für ITIL Prozesse. Incident
Störungen als auch Service-Requests. Workaround
kurzfristige Lösungsmethode für Störung liegt
bereits vor. Problem nicht bekannte Ursache für
eine Unterbrechung bzw. Störung. Known-Error
Ursache erkannt und passende Lösung erarbeitet.
Incident-Mangt. Wird üblicherweise durch den
Benutzerservice, fallwise das Call-Center
durchgeführt sorgt für eine schnelle Beseitigung
einer Störung, um IT-Services wieder zu
aktivieren.

• Beginnt mit der Entgegennahme der Meldung und
  wird durch die Wiederherstellung der Dienste
  abgeschlossen. Schritte
• Störung entgegennehmen und registrieren
• Klassifizierung nach Kategorien der IT (Netze,
  Hardware)
• Prüfung auf Auswirkungen, Dringlichkeitsgrad und
  Definition der Priorität
• Beachtung der SLA-Bedingungen
• Feststellung von möglichen Gefahren oder
  Konsequenzen
• Erste Unterstützung des Anrufers
• Falls Service-Request vorliegt, Verfahren zur
  Service-Anforderung initiieren
• Prüfung ob Störung bekannt Prüfen, ob Workaround
  möglich
• In beiden Fällen wird Störung umgehend beseitigt
• Bei nicht bekannter Ursache wird analysiert und
  diagnostiziert
• Bei Behebung Betroffene benachrichtigen
• Abschluss und Speicherung des Lösungsweges in
  Datenbank

Kurzbeschreibung
Prozess
Störung Workstation fällt komplett aus, Zugriff
auf Datenbank nicht möglich
Beispiel

• Ansprechpartner für die Kunden
• Entgegennahme für die Anfragen und Meldungen
• Bearbeitung der Anfragen und Speicherung in einer
  Datenbank
• Klassifizierung und Priorisierung
• Schnelle Hilfe und Wiederherstellung der Dienste
  einleiten
• Kommunikation mit weiteren ITIL-Prozessen
• Geschäftsprozessunterstützung während der Dauer
  einer Störung
• Verfolgung und Beendigung mit Lösungsmeldung
• Ein Trouble-ticket-System (Software und
  Datenbank) hilft hier bei späteren, gleichen
  oder ähnlich gelagerten Fällen zur schnellen
  Lösungsfindung.

Aufgaben und Funktionen
Einführung und wichtige Schnittstellen KPI
Verantwortlicher Manager einsetzen Überwachung
von Prozess und Ergebnisse. Interfaces zu
weiteren ITIL Hauptprozessen Problem-Management
Können Incidents nicht unmittelbar behoben werden
? Problem Mgt. Change-Management Tritt in Aktion
wenn Änderungen nötig Configuration-Management
Änderungsinformationen ablegen Release-Management
Bei globalen Änderungen Service-Level-Management
muss informiert werden, wenn sich aufgrund der
Veränderung Auswirkungen auf die SLAs
ergeben Service- Anforderungsverfahren bei
Existenz eines Service-Request. Das Verfahren
wird vordefiniert und läuft nach einem festen
Schema ab. KPI Anzahl der gemeldeten Störungen
aufgeschlüsselt nach Priorität, Durchschnittliche
Reaktionszeit sowie Zeitdauer bei
Störungsbehebung, Durchsch. Kosten, Anzahl von
Störungen deren Randparameter gegen einen
definierten SLA verstossen.
Einführung und wichtige Schnittstellen KPI
Schnelle und effiziente Bearbeitung und die
Störungsbeseitigung sind die wichtigsten Ziele.
Zudem müssen die Geschäftsprozesse und die
vereinbarten Serviceleistungen möglichst schnell
und sicher wieder aufgenommen werden können.
Nicht zu vergessen sind auch die Kunden- und
Mitarbeiterzufriedenheit und die damit
zusammenhängenden Beziehungen.
Ziele
3
Schematische Darstellung des Incident-Management-
Prozess
BEWERTUNG Incident-Management
Incident Management Prozess
Input
Output

Störungsbearbeitung Informationen RfCs Reports
Incident (Störungsmeldung) Informationsanfrage Bes
chwerden
Steuerungs- größen
Verhaltenskodex der First-Level- Mitarbeiter
Effiziente Service Desk- oder Ticket
Management- Software
Ausbildungsstand der First-Level-Mitarbeiter
CI und CI-Beziehungen Incidents Bekannte
Probleme Durchgeführte Änderungen Releases und
Versionen
CMDB
KPIs Erreichbarkeit Reaktions-Fehlerbehebungszeitr
aum Anzahl der Beschwerden Abgearbeitete
Störungsmeldungen Fehlerlösungsrate durch
First-Level-Support
Schematischer Incident-Magt.-Prozess
Nutzer eines DV-Verfahrens meldet eine Störung
Störungsmeldung/Nutzeranfragen entgegennehmen und
dokumentieren
Priorisierung der Störungsmeldungen sowie
qualifiziertes Weiterleiten
Störung verifizieren und analysieren sowie
Monitoring und Verwaltung
Problemlösung, Dokumentation und
Nutzerbenachrichtigung
4
Problem-Management
KPI Key Performance Indicator
Kurzbeschreibung Zweite Ebene des
Incident-Magt. Vorrangige .Aufgabe Wieder-
aufnahme des Services schnellstmöglich zu
sichern. Im Vordergrund steht die Entdeckung der
Ursachen von Fehlern und Störungen. Mitarbeiter
müssen zum einen über eine hohe Qualifikation
verfügen und zum Zweiten andere Hilfsmittel zur
Fehlersuche verwenden. (z.B. Reihe von
Komponenten, Systemen, Datensammlungen und
Programme) Notwendige Informationen werden von
und zu anderen ITIL- oder Magt- Prozessen
geliefert.

• Prozess
• Problem-Control-Prozess Erkennung u. Fixierung
  des Problems. Gemeldete Störungen werden zum
  Problem umgeformt, und zwar normalerweise durch
  den Service-Desk-MA. Probleme sind es dann, wenn
  ein erneutes Auftreten erwartet wird.
  Service-Level-Probleme sind mit höchster
  Priorität zu bearbeiten. Klassifizierung/Kategoris
  ierung. Einteilung Eskalationsgruppen.
  Weiterleitung an Experten. Bereitstellung aller
  zur Lösung notwendigen Daten und Ressourcen.
  Feststellen von möglichen Aufwirkungen.
  Festlegung der Priorisierung. Fortführen des
  Bearbeitungsstatus. Zuweisung zum
  Problemmanagementteam. Weiterleitung an
  zuständige Stelle. Erfassung und
  Lösungsvorbereitung. Bereitstellung notwendiger
  Informationen aus diversen Quellen.
  Analyse/Diagnose. Tests. Abläufe und Testhilfen
  verwenden. Ursachen ermitteln
• Error-Control-Prozess
• Proaktives Problem-Management

Kurzbeschreibung
Prozess
Beispiel Datenbankfehler, Anwendungsprogrammfehl
er, Hardware-Fehler, Netzwerkfehler,
Sicherheitsfehler, Betriebssystemabstürze,
Virenprobleme
Beispiel

• Aufgaben und Funktionen
• Man unterscheidet 3 Problem-Management-Subprozesse
  
• Problem-Control Problembearbeitung als solche.
  Incidents ausscheiden, Beschreibung und
  Klassifizierung sowie die Fest-legung der
  Bearbeitungspriorität. Detaillierte Untersuchung
  des Problems und dessen Auswirkungen.
  Ursachenforschung.
• Error-Control Known Error, Daten und
  Inforamtionen in Trouble-ticket-Datenbasis.
  Lösungen werden initiiert und delegiert. Request
  for Change an das Change Management weiterleiten.
  Bei Known Errors sollte Ursache in Problem-Mgt.
  gefunden werden, solche IT-Komponenten werden als
  Configuration ITEM (CI) in der CMDB
  abgespeichert.
• Proaktives Problem-Management Vorkehrungen
  treffen, um Problem nicht entstehen zu lassen.
  Hierzu werden die früheren Lösungen analysiert
  und aus Trends das Entstehen von Problemen im
  Vorfeld erkannt.

Aufgaben und Funktionen
Einführung und wichtige Schnittstellen KPI
SLAs diskutieren und zusammenstellen,
Prozessabläufe festlegen, Notfallpläne,
IT-Infrastruktur für Änderungen bereit stellen,
Kommunikationswege einrichten,
Verantwortlichkeiten und Zuständigkeiten
festlegen, Schnittstellen zu anderen Mgt.-Arten
und IT-Bereichen definieren, Zeitrahmen für
Lösungs-findung fixieren SLAs minimal/maximal Fü
r das Prob.-Mgt. gibt es etliche Interfaces zu
anderen Prozessgruppen oder IT-Funktionen. KPIs P
roaktiv gefundene Fehlerursachen, Kosten,
Termingerechte Problemlösung, Anzahl der
erfolgreich eingeleiteten RFCs und durchgeführten
Änderungen, Noch offene aber bekannte Fehler,
Gelöste und dokumentierte Probleme, Fehler, die
einer speziellen Problemursache zugeordnet werden
können, bevor diese Ursache beseitigt wurde,
Anzahl von Aufträgen an externe Vertragspartner
zur Beseitigung von Problemfeldern, Anzahl von
Fehlerursachen, die Garantiefälle sind.
Einführung und wichtige Schnittstellen KPI
optimale, schnelle
Ursachenforschung, Elimination der Ursachen,
Aufrechterhaltung der IT-DL, Vermeiden von
Systemunterbrechungen, Schadensbegrenz.,
Vermeiden v. Prob.
Ziele
5
Schematische Darstellung des Problem-Management-P
rozess
BEWERTUNG Problem-Management
Problem Management Prozess
Input
Output

Lösungen zu Fehlerzuständen RfCs Vorbeugende
Maßnahmen Work Arounds (Umgebungslsg.) Analysen
der DV-Verfahren
Störungsmeldungen-Einzelheiten Fehlerbeseitigungsm
aßnahmen Konfigurationsdetails der CMDB Anfragen/
Beschwerden Schon bekannte Fehler
Steuerungs- größen
Verhaltenskodex der Mitarbeiter
Effiziente Service Desk- oder Ticket
Management- Software
Ausbildungsstand der Problem-Mgt.-Mitarbeiter

• KPIs
• RfCs die erfolgreich durchgeführt wurden
• Verkleinerungen der Störungsmeldungen im
  First-Level
• Verfügbarkeitssteigerung eines DV-Verfahrens
• Anzahl von bekannten und ermittelten Fehlern

-Work Arounds zu bek. Fehlern -Beschreibung von
Fehler ursachen -Änderungen und Auswirkungen -MA
im Störungsfall
CMDB
Schematischer Problem-Magt.-Prozess
Service Desk, Aktueller Fehler, Nutzeranfragen,
Fehlerrecherche des Probl-Mgt.
Problemidentifikation, Fehlerkontrolle und deren
Dokumentation
Problemanalyse
Problemlösung
6
Change-Management
KPI Key Performance Indicator
Kurzbeschreibung Sinnvolle Verwaltung von
Installationen und Änderungen aller Art. Das
betrifft jede Art von Software (Betriebssysteme,
Tools, Utilitie, Anwendungsprogramme Hardware
Updates Änderung IT- Infrastruktur) Zentrale
Überwachung und Steuerung von Änderungen. Auch
als Folge von Veränderungen bei Geschäftsprozesse
können Änderungen an den IT-Abläufen respektive
bei den Applikationssystemen erforderlich werden.
Auch Vorbereitungsaufgaben für Umstellungen
durchführen. Sicherheitsmanagement. Koordination
der Changes

• Prozess
• Erstellung und Weitergabe des RfC an das
  Configuration-Management, Erfassung des RfC und
  Abspeicherung in der CMDB, Genehmigungsverfahren
  endet positiv oder negativ, Einspeicherung in die
  CMDB durch das Config.-Mgt., hierdurch entstehen
  die CIs, Zusatzinformationen über Kosten aus dem
  Financial-Mgt., Aufstellen eines FSC (Forward
  Schedule of Change) als Planungsgrundlage für die
  implementierung, Ressourcen-Planung für die
  Veränderungsaktionen, Aktivierung des
  Config.-Mgt., Aktivierung des Release-Mgt.,
  Klassifizierung der RfC-Art und der
  Dringlichkeitsstufen, Entwicklungsarbeiten
  durchführen, falls notwendig, Die dazugehörigen
  Testaufgaben abwickeln, Prüfen der Auswirkungen
  auf die Anwendungen, Erstellen eines PIR (Post
  Implementation Review), Freigabe, Einführung,
  CI-Abschluss, Meldung an alle Beteiligte.

Kurzbeschreibung
Prozess
Beispiel Netzwerkbetriebssystemumstellungen,
Austausch von Netzwerkkomponenten, Neue
Verkabelungstechnologie, neue Tools für das
Intranet, VoIP wird eingerichtet
Beispiel

• Aufgaben und Funktionen
• Änderungsanforderungen müssen überprüft werden.
• Beschaffungen werden nach Genehmigung angestoßen.
• Implementierungen werden gesteuert und überwacht.
• Inventarlisten aktualisieren
• Kosten für Veränderungen festhalten.
• Verwaltung der Lizenzen.
• Patch-Management von Software-Updates.
• Aufgrund Request for Changes (RFCs) notwendige
  Changes initi.
• Das technische Personal muss fallweise
  eingreifen.
• Regelmäßige Updates von Virenscannern.
• In bestimmten Fällen sind Wartungsverträge
  notwendig.
• Zeitpläne für Umstellungen sind aufzustellen.

Aufgaben und Funktionen

• Einführung KPI
• Entwickeln einer Akzeptanzstrategie für
  betroffene MA, gutes Berichtswesen Richtung
  Top-Mangament, Dokumentation aller Changes, nur
  genehmigte und autorisierte Veränderungen
  zulassen. Ständige Kommunikation mit
  Anwendern/Kunden, Erarbeiten von
  Notfallprozeduren und Pläne um bei dringenden
  Änderungen schneller reagieren zu können, Suche
  nach optimaler Relation zw. Stabilität und
  Flexibilität, Reduktion von Risiken durch
  Standardisierungsdefinitionen für Beschaffungen.
• Wo möglich standardisierte Verfahren einsetzen,
  Staistiken über die Aktionen erstellen,
  Transparente Abläufe und Prozesse.
• Changemanagement prinzipiell für alle Bereiche
  und Organisationseinheiten zuständig.
• KPIs
• Qualität
• Kosten
• Termintreue
• Anzahl der durchgeführten Änderungen,
• Anzahl der abgelehnten Änderungen
• Mit den Änderungen verbundener Sytemausfallzeitrau
  m

Einführung und wichtige Schnittstellen KPI
Änderungen bei Geschäftsprozessen
schnell durchführen, Auswirkungen auf DL
transparent machen, Geschäftsprozesse müssen
innerhalb der IT flexibel realisiert werden,
IT-Services aufrechterhalten, Risiken sollten im
Vorfeld abgeschätzt werden können, Neue
Technologien müssen sicher/schnell eingeführt
werden können, Tests sind durchzuführen, Keine
Folgefehler.
Ziele
7
Schematische Darstellung des Change-Management-Pr
ozess
BEWERTUNG Change-Management
Change Management Prozess
Input
Output

Incident (Störungsmeldung) Kostenreduktionsbestreb
ungen Aktualisierung von Hard- und
Softwarekomponenten notwendig
Steuerungs- größen
Post Implementation Review (PIR) Durchgeführte
Änderungen
Verhaltenskodex der First-Level- Mitarbeiter
Effiziente Service Desk- oder Ticket
Management- Software
Ausbildungsstand der First-Level-Mitarbeiter
CMDB
KPIs Erreichbarkeit Reaktions-Fehlerbehebungszeitr
aum Anzahl der Beschwerden Abgearbeitete
Störungsmeldungen Fehlerlösungsrate durch
First-Level-Support
Change Management Prozess mit Verzweigungen
komplexer
Fachbegriffe RFC (Request for Change) CAB
(Change Advisory Board) PIR (Post
Implementation Review) FSC (Forward Schedule of
Change) Backout Plan beschreibt, was im Falle
des Misslingens eines Changes passieren soll.
8
Configruation-Management
KPI Key Performance Indicator
Kurzbeschreibung Vor allem zuständig für
IT-Infrastruktur. Nutzt Datenbanken und
Softwarepakete, um allen notwendigen
Informationen über den Bestand der Hard- und
Software zu verwalten. Diese Datensammlungen
müssen stets aktuell und konsistent sein. die
schon erwähnten CMDBs. Innerhalb des Config.-Mgt.
werden die Daten der Vermögenswerte erfasst und
überprüft. In den CMDBs befinden sich zusätzlich
die wichtigsten techn. Informationen und
Leistungsdaten. Die Datensätze werden als
Configuration Item (CI) bezeichnet. Auch Daten zu
Standorte der Komponenten, Auch Programme und
Softwaresysteme CI, d.h. es werden in CMDBs auch
Abläufe beschrieben, die Programmdokumentationen
ab-speichern und Schnittstellen zu weiteren
Subsystemen definieren.

• Prozess
• Initiiert allgemein durch das Change-Mgt.,
  welches vorhandene Daten liefert.
• Changes ziehen folgende Konfigurationsaktivitäten
  nach sich
• Strategieplanung des kompletten Prozesses,
  Zielsetzungen definieren, Beschaffung von
  ergänzenden Informationen, Ressourcenwahl und
  Utility-Installationen, Interfaces zu den anderen
  ITIL Prozessen aktivieren, Datenmodellierung und
  Datenbank- Definitionen, CIs erfassen/abspeichern
  
• Erbebnis1 stets aktuelle CMDB-Datensammlung,
• Ergebnis 2 Management- Reporting an verschiedene
  Personenkreise
• Ergebnis 3 Informationsweiterleitung an weitere
  ITIL Prozessgruppen.

Kurzbeschreibung
Prozess
Beispiel Kategorien Software, Hardware,
Dokumentationen, Datensammlungen, Nicht direkt
der IT zuzuordnende Komponenten z.B. Mobiliar,
Fachliteratur
Beispiel

• Aufgaben und Funktionen
• Auswertungen zur Verfügung stellen, CMDB-Aufbau,
  Datenbank-administration und Strukturierung,
  Datenmodellierung eines CI-Aufbaus,
  Identifizierung eines CI, Interfaces zu weiteren
  Systemen der IT bzw. ITIL-Prozessen,
  Kategorisierung der CIs und der CI-Gruppen,
  Komponenten erfassen und einspeichern, Management
  Informationen für die weiteren ITIL- Disziplinen
  bereitstellen, Relationen bilden, hier sind
  Verknüpfungsdaten notwendig, Sicherstellen, dass
  nur autorisierte und genehmigte Komponenten
  verwendet werden, Statusfelder für Zustände,
  Benutzungszwecke oder Bearbeitungsstand
  festlegen, technische Daten und Leistungsdaten
  erfassen, Verantwortlicher für CI muss
  gespeichert werden, Versionierung der CIs,
  Zugriffs- und Zugangssicherung.

• Einführung und Schnittstellen KPI
• In der Einrichtungsphase Projekt einrichten. CMDB
  wird häufig in mehreren Schritten aufgebaut, Grad
  der Detaillierung wird zunehmend verbessert.
• Das Config.-Mgt. befindet sich zw. dem Change und
  Release-Mgt., Schnittstellen
• CIO, Service Desk, Asset- oder Inventarisierungssy
  steme, IT-Anwendungen, IT-Entwicklungsabteilung,
  Anwendergruppen/ Fachbereiche, Availability-Mgt.,
  Capacity-Mgt., Continuity-Mgt., Problem-Mgt.,
  Incident-Mgt., Release-Mgt., Operations-Mgt.
• KPIs
• Anzahl der neu erfassten oder veränderten CIs
• Abdeckungsgrad aller DV-Verfahren an das
  Config.-Mgt.
• Kosten
• Zufriendenheitsgrad
• Anzahl der auf Aktualität überprüften CIs
• Abdeckungsgrad der benötigten Informationen

Aufgaben und Funktionen
Einführung und wichtige Schnittstellen KPI
ITIL Prozesse Availability-Mgt.,
Capacity-Mgt., Continuity Mgt. können mit den
Informationen des Config.-Mgt. optimal versorgt
werden. Letztlich auch strategische Ziele und
Aufgaben berücksichtigen
Ziele
9
Schematische Darstellung des Cofiguration-Managem
ent-Prozess
BEWERTUNG Configuration-Management
Output
Input
Configuration Management Prozess

Request for Change (RfC) Neue DV-Infrastruktur Lag
everänderung des CI Änderungswunsch an
die Struktur eines CI
CI geändert Neue CIs in die CMDB hinzugefügt CIs
überprüft Struktur eines CIs geändert
Steuerungs- größen
Verschiedene Stellen einer Firma melden neue
DV-Infrastruktur
Gutes Personal
Optimaler Configuration Management Plan
CMDB
Hardware Software Dokumentation Wartungsverträge Ö
rtliche Lage Personal und Verantwortlichkeit
KPIs Anzahl von neu erfassten CIs Anzahl von
veränderten CIs Zufriedenheitsgrad Anzahl von
überprüften CIs
Aktivitäten des Configuration-Management
Identifikation und Integration
Verändern
Configuration Item
Zugriff auf die Informationen des CI
Überprüfen
10
Release-Management
KPI Key Performance Indicator
Kurzbeschreibung Dafür zuständig die CIs für
die Anwendungen produktionsreif zu gestalten.
Programme und Prozesse befinden sich noch in der
Testumgebung und werden erst ausgiebig geprüft.
Jede Art von Configuration Item wird als Release
bezeichnet, welches ein vorhandenes älteres CI
ersetzt oder ganz neu hinzukommt. Auch
Hardwarekomponenten aller Art. Produktionsumgebung
Bereich indem sich die Benutzer später bewegen.

• Prozess
• Allgemein sind beim Release-Mgt. 3
  Umgebungsvarianten im Spiel
• Die Entwicklungsumgebung, falls
  vorhanden/notwendig
• Die Testumgebung
• Die Produktionsumgebung
• Prozessschritte nicht untergliedert
• Vorarbeiten
• Design und Realisierungsvorbereitung
• Tests und Abnahmen
• Einführungsplanung
• Anwendervorbereitung
• Rollout
• Die Abläufe sind oft variierbar, je nach Umfang
  oder Art des Releases.

Kurzbeschreibung
Prozess
Beispiel Emergeny Release Programmfehler wurde
entdeckt und muss umgehend beseitigt werden, da
ansonsten die Abläufe und Services behindert
werden
Beispiel

• Aufgaben und Funktionen
• Die Abspeicherung aller Softwarepakete in Form
  von Runtime-Modulen, also lauffähiger IT-Prozesse
• Installation von Jobs und Jobnetzen, welche
  praktisch die Geschäftsprozesse unterstützen
  sollen
• Die Auswertung von Tests für Hardware/Software
• Durchführung von Freigabeprozeduren nach festen
  Schema
• Softwaredistribution
• Auch in Produktionsumgebung Testprozedur unter
  realistischen Einsatzbedingungen
• Einführung der Anwender in die Systeme ist
  ebenfalls wichtig, damit sie problemlos damit
  arbeiten können

Aufgaben und Funktionen

• Einführung KPI
• Das Release-Mgt. benötigt Schnittstellen zu
• Top Management
• Anwendergruppen und Bereichsleiter
• CIO
• Service Desk
• IT- Entwicklungsabteilung (bei Bedarf)
• Technikergruppe (bei Bedarf)
• Change-Management
• Configuration-Management
• KPIs
• Durchgeführte erfolgreiche Releases
• Implementierte Releases in geplanter Zeit
• Kosten
• Eingespielte Releases durch externe Firmen
• Ausfallzeiten durch einspielen neuer Releases
• Anzahl von Backouts

Wichtige Schnittstellen KPI
Betroffene MA informieren, nur
getestete Software in die Produktionsumgebung,
nur zugelassene/legale Software, Hardware muss
UN-Standard entsprechen, Enge Zusammenarbeit mir
Change- und Configuration-Mgt. muss gewährleistet
sein, CMDB muss aktuell sein, Umstellungsarbeiten/
Implementierungen müssen schnell, sicher,
benutzergerecht durchgeführt werden,
Zeit-planungen für Einzelaktionen und komplette
Installationen müssen ständig erarbeitet/überwach
t werden, Produktionsumgebung schützen (Vorgaben
Security-Mgt.), die geforderten Services müssen
fehlerlos, nach SLA-Bedingungen erbracht werden
können.
Ziele
11
Schematische Darstellung des Release-Management-P
rozess
BEWERTUNG Release-Management
Release Management Prozess
Input
Output

Aktualisierung von Hard- und Softwarekomponenten
notwendig
Erfolgreich durchgeführte Änderung Release
Policy Rollout-Vorgehensweise Releasedokumentation
Steuerungs- größen
Einsatz einer DSL
Einsatz intelligenter Testverfahren
Einbindung der Nutzer oder des Kunden
CMDB
KPIs Anzahl erfolgreich durchgeführter
RFCs Niedrige Downtime, hervorgerufen durch neue
RFCs
Releas Management Prozess mit Verzweigungen
komplexer
Fachbegriffe Build Management Hiermit ist das
Binden verschiedener Softwaremodule oder
Hardwarekomponenten zu einer lauffähigen
Applikation oder Hardwareeinheit zu verstehen,
welche in nachvollziehbarer Weise immer wieder
gleich erfolgt. Rollout-Plan Release Policy DSL
(Definitive Software Library, Bibliothek oder
Versionierungsarchiv)