Stoppt die Vorratsdatenspeicherung! Jetzt klicken &handeln! Willst du auch an der Aktion teilnehmen? Hier findest du alle relevanten Infos
und Materialien:
Sie sind hier: Startseite Referenzen Change-Beschreibungen im Rahmen eines ITIL-Change-Prozesses

Die Aufgabe:

Change-Beschreibungen im Rahmen eines ITIL-Change-Prozesses

Die Lösung von Goebel Consult:

Im Rahmen eines ITIL-Changemanagement-Prozesses müssen die Changes ausführlich beschrieben werden.

Die Lösung im Detail

Mitentwickeln des Einstufungs-Konzepts, Entwurf einer Matrix bzw. Entscheidungstabelle

An Hand

  • der Dringlichkeit eines Changes,
  • der schwere der Störung während des Changes/Änderungen und
  • den Folgen für das Geschäft des Kunden, falls was schief läuft

wird der Change eingestuft und der zugehörige Prozess festgelegt. Die Prozesse waren bereits unternehmensweit definiert (nur Mitteilung, Genehmigung durch Change-Management, Genehmigung durch Change Advicery Board).

Durch meine Matrix wurde klar, dass Changes oft "höher" eingestuft wurden als nötig wäre (zu viele Changes wären "ganz oben" gelandet). Diese Erkenntnis ermöglichte, die Change-Matrix anzupassen und den Change-Prozess effizienter zu gestalten.

Erarbeiten eines Nummern-Konzepts

Jeder Change-Typ hat einen Nummer, die in Klassen eingeteilt sind, ähnlich Buchhaltungskonten:

1xxxx: LAN
2xxxx: WAN
3xxxx: Basis-Infrastuktur (DNS, Mail, etc.)
4xxxx: Firewalls etc.

100xx: MPLS
x10xx: München
x20xx: Frankfurt Süd
x201x: Frankfurt Nord
455xx: Firewallsystem GSAA

xxx10: Update Betriebssystem
xxx11: Update Anwendung 1
xxx12: Update Anwendung 2
xxx20: Einbau Hardwad/Netzwerkkarte
xxx21: Umbau Hardwad/Netzwerkkarte
xxx22: Ausbau Hardwad/Netzwerkkarte
xxx99: Sonderlocken, einmalige Aktionen

Zur Beschreibung gehören Dinge wie:

  • betroffene Systeme (Netzbereich N, gesamtes Firmennetz, Anbindung an Partner P, alle Mailsysteme)
  • Störung durch Change (Ausfall mm Minuten; keine, da redundant; Verringerung der Redundanz; ...)
  • Business-Folgen, falls was schief geht (soweit von der Technik abschätzbar)

Effizenz durch Abstrahieren

Damit die Admins diese Beschreibungen nicht jedesmal neu schreiben müssen, habe ich die erstellt. Dabei habe ich abstrahiert, um mit wenige Aufwand viele gute Beschreibungen zu erstellen:

  • Nokia-Betriebsystem-Update dauert 20 Minuten je Maschine
  • Cisco-Betriebsystem-Update dauert 15 Minuten je Maschine
  • Solaris-Betriebsystem-Update dauert 4 Stunden je Maschine
  • Cluster mit 2 Maschinen -> Update dauert 2-mal so lange
  • redundant -> kein Ausfall, aber verringerte Bandbreite, verringerte Redundanz
  • Checkpoint-Update -> ....
  • Einbau einer Netzwerk-Karte -> Störungen/Unterbrechung
    • bei Nokia: Dauer XX Minuten
    • bei Cisco: Dauer YY Minuten

       

Damit läßt sich ein Firewallsystem "GSAA"beschreiben als

  • 2-fach redundant
  • Nokia-Basis
  • Checkpoint-Firewall
  • betroffen sind die GSAA-Server, die Anbindung an Partner P2 und der Netzbereich 10.11.12.64/22

Durch diese Abstrahierung ließen sich der große Teil der Change-Beschreibungen automatisch erstellen.

Arbeitserleichterung für Admins

Da das Remedy-Tool, über da die Changes erfasst und bearbeitet werden, zu unflexibler ist, können die Admins weder neue Geräte (und die zugehörigen Changenummern) erstellen noch Texte ändern, noch konnte man für alle Felder Texte hinterlegen. Daher wurde als "ad-hoc" Lösung eine Wiki aufgesetzt. Dort pflegen die Admins die Beschreibungen und nehmen neue Geräte auf. Die Text werden per Copy & Paste in das Change-Tool eingegeben.

Hartmut Goebel denkt daran, dass alles praktikabel sein muss.