Der Prozess für die Erfassung und Bearbeitungen von Changes (Request for Changes „RFCs“, ITIL®-Prozess „Change Enablement“) dient der strukturierten Genehmigung, Bearbeitung und Dokumentation aller Änderungen, die an bestehenden Funktionen, Geräten und Services durchgeführt werden. Dabei stehen auch die Beurteilung der Aufwände/Kosten und das Risiko eines durchzuführenden Changes im Vordergrund.
Der ITIL®-Prozess „Change Enablement“ ist auch als gleichnamige Ansicht für Tickets verfügbar. Die Ansicht enthält besondere Felder, die für den Change wichtig sind: Change-Typ, Risiko und Genehmigungsstatus für den Change etc. Außerdem sind in den referenzierten Informationen (Aufklappen eines Tickets innerhalb der Liste) zusätzlich direkt die Liste der Genehmigungen ersichtlich.
Das Change-Ticket folgt ansonsten dem Formularaufbau des Standard-Tickets.
Es gibt folgende Change-Typen, der bei der Ticketerfassung bzw. -klassifizierung gewählte Typ wird im Reiter Klassifizierung und im Ticket-Kopfbereich unter dem Titel angezeigt:
•Normaler Change: Der Change wird standardmäßig durchgeführt. Alle vorgesehenen Genehmigungen und Workflows müssen durchlaufen werden
•Standard-Change: Ein Standard-Change kann ausschließlich über eine Ticketvorlage erstellt werden. Standard-Changes sind vorab definierte Changes, die immer auf die gleiche Art und Weise durchgeführt werden können.
•Notfall-Change: Ein Notfall-Change ist ein sehr dringender Change, der so schnell wie möglich umgesetzt werden muss, da z. B. Fehler in geschäftskritischen Anwendungen entstanden sind. . Aufgrund dieser Tatsache ist es sehr wichtig, dass eine saubere Dokumentation erfolgt. Die Priorität wird dabei automatisch auf die höchste Stufe gestellt.
Die Sektion „Planung“ wird eingeblendet und enthält die folgenden zusätzlichen Felder:
•Geplanter Aufwand Gesamt (h): zeigt den Aufwand in Stunden an, der vorab für die Umsetzung des Changes geschätzt wurde.
•Gebuchter Aufwand Gesamt (h): zeigt die Summe der erfassten Zeiten auf das Change Ticket
•Implementierung von: Zeitpunkt an dem die Umsetzung beginnen soll
•Implementierung bis: Zeitpunkt, bis zu dem der Change umgesetzt sein soll
Die Sektion "Eigenschaften" enthält die folgenden zusätzlichen Felder:
•Risiko: Einschätzung des Risikos für die Umsetzung dieses Changes. Bei aktivierter Berechnungsmatrix kann das Eisiko indirekt automatisch aus Auswirkung und Wahrscheinlichkeit berechnet werden
•Stakeholder: In der Liste können die Personen eingetragen werden, die ein Interesse an dem betroffenen Asset/ Service/ CI haben (da sie direkt oder indirekt davon betroffen sind oder eine Management-Rolle haben die damit in Bezug steht) und somit automatisch über das Change Ticket informiert werden müssen. Über einen Button können automatisch alle Personen die auf den betroffenen Assets in der Personenliste eingetragen sind sowie die Asset Verantwortlichen in die Stakeholder Liste übernommen werden. Über den "E-Mail-Button" wird eine neue Nachricht geöffnet, die alle Stakeholder als Empfänger enthält und entsprechend über den anstehenden Change direkt informiert werden können.
Die Sektion „Lösung“ enthält die folgenden zusätzlichen Felder und Funktionen:
•Ergebnis der Implementierung: dokumentiert das Ergebnis der Implementierung. Die Optionen sind „Erfolgreich“, "Rollback planen" oder „Rollback durchgeführt“. Der Rollback ist erforderlich, wenn die Umsetzung des Changes nicht erfolgreich war und der Zustand vor der Umsetzung wiederhergestellt werden muss. Bei der Auswahl „Rollback durchgeführt“ erscheint ein Pflichtfeld („Rollback Info“) für einen Textkommentar. Falls für den Change in der Ticketvorlage Roll-Back aufgaben definiert wurden, werden diese automatisch in der Aufgabenliste erzeugt. Diese dienen dazu, genauso wie bei der Erfassung der Aufgaben für die Umsetzung des Changes auch die Erfassung der Aufgaben für den Rückbau zu beschreiben.
