ITIL Knowledge: Was bedeutet eigentlich …?
ITIL verwendet ein spezielles Vokabular. Die Verständigung unter den «IT Gurus» ist einfacher mit den richtigen Begriffen – vorausgesetzt, alle verstehen darunter auch wirklich dasselbe. Dieter Gut, ID Direktion, Qualitäts- und Prozessmanagement, erklärt drei wichtige Begriffe. Für die einen sicher eine willkommene Repetition.
- IT Service
- Release Management
- Change Management
Dass diese drei Dinge miteinander sehr eng verknüpft sind, wird aus den nachstehenden Erläuterungen deutlich.
IT Service
Das ist unsere Leistung, die beim Benutzer ankommt. Sie wird bestimmt durch die Usability und die Warranty.
- Usability Was kann es?
- Warranty Wie und wann kann ich es benutzen?
Ein IT Service besteht aus verschiedenen Bausteinen, den Patterns und den CIs. Welche Ausprägungen dieser Bausteine miteinander verbunden werden und wie sie voneinander abhängig sind, ist die Bauvorschrift (Solution), also das Design für einen bestimmten Release des Services.
Abbildung 1: Servicebausteine [Quelle: Fabio Consani]
Jeder Service hat Herstellkosten und einen Preis. Da der Preis Verhandlungssache ist (in der ETH oft Null) steuern sich viele Serviceproduzenten über die internen Herstellkosten.
Beispiele für IT Services: E-Mail Service, managed Database, managed Storage …
Release Management
Es gibt hauptsächlich
- Service Releases
- Software Releases
- Hardware Releases
- Firmware Releases
Die Relationen zwischen den Releases sind gegeben durch das Servicedesign.
Das Releasemanagement verfolgt die Entwicklung der Versionen der eingesetzten Produkte, insbesondere auch jener Produkte, die man nicht selber beeinflussen kann. Es entscheidet, welche Releases geändert werden sollen oder müssen. Es evaluiert die Abhängigkeiten und erstellt daraus einen Plan. Mit diesem Wissen wird ein Change durchgeführt, welcher die Komponenten eines Services aktualisiert, ohne die Funktionalität des Services zu beeinträchtigen oder zu erweitern.
Change Management
Das Change Management steuert jede Veränderung an IT Services oder deren Komponenten nachvollziehbar und ohne Ausnahme. Eigene Produktentwicklungen oder Projekte brauchen ebenfalls ein Change Management. Das hat aber nur indirekt mit jenem des Service Management zu tun, das ich hier beschreibe.
Wird eine Änderung einer oder mehrerer Komponenten eines Services geplant, so sorgt das Change Management für
- einen vollständigen Plan mit gegenseitigen Abhängigkeiten und zeitlichen Vorgaben
- klare Verantwortlichkeiten
- eine Risikoabschätzung
- einen Testplan vor, während und nach der Durchführung des Changes
- einen Fallbackplan mit Zeitlimiten
- eine Freigabe durch das Change Advisory Board (CAB), sofern es sich nicht um einen vorbereiteten Standardchange handelt
- die Sicherstellung der Information an alle Betroffenen (Kunden, ID Personal), vor, während und nach dem Change
- das Debriefing (PIR) bei komplexen und heiklen Änderungen
Es gibt zwei grundsätzliche Arten von Changes – den regulären Change wie oben skizziert und den Standardchange. Letzterer ist ein immer wiederkehrendes Vorgehen, welches stets nach denselben Workflows und mit denselben Bewilligungen abläuft. Ein Beispiel für einen Standardchange ist das Einrichten eines Benutzer-Accounts. Das Verfahren ist klar definiert und hundertfach erprobt und kann darum sehr schnell ausgeführt werden. Solche Changes können häufig vollständig automatisiert werden.
Bei einem Notfall gibt es ein definiertes Expressverfahren. So kann ein sicherheits- oder zeitkritischer Change zuverlässig und schnell implementiert werden.
Posted on
in Kommunikation, Mail, Web, Multimedia, Drucken, News, Passwort, Applikationen, Software, Arbeitsplätze, Speicher, Support, Wissenschaftl. Rechnen
