Change request management
The change request management delivers the functionality to ...
- define a change request,
- monitor live change behavior during the time period of the change request(s) and
- document the correct implementation of all planned changes after completion of the change period of the change request.
Based on Versio.io Asset & Configuration Inventory.
A change request defines for which instances a change is planned at a time or series date. A change request period is created for each time or series date period of a change request. The complete documentation of a change request is documented in the change request period.
@startuml 'skinparam monochrome true rectangle "Change request" as cr rectangle "Change request period" as crp cr "1" - "+" crp @enduml
Define change request
Monitore change request
- optional review the result of an change request period
How I should interpret the change request period result?
Workflow & states
For the change request there are various state changes possible.
@startuml edit : Create and edit a new \nchange request ticket toApproval : Change request is \nready for approval active: Change request \n is in execution mode completed: Change request \n execution is completed [*] --> edit edit -> toApproval: click on \n "**For approval**" \n button toApproval -> edit : click on \n "**Not approved**" \n button and send mail to author toApproval -> active: click on \n "**Approved**" \nbutton active --> completed: **Automatic**\n if the end time \n of the change request \n is reached active --> completed: **Manual**\n if a user stop \n the change request execution \n before the end time \n (started change periods \n are stopped) completed --> [*]: click "**Delete change request**" \n includes change request periods completed --> [*]: Hold for \n reports and audits @enduml
Illustration: Possible change request state transitions
- useres can edit the configurations
- creation of first change request period (preview-init)
- delete all change request periods
- recreation of first change request period (init)
- no more change request periods will be created
Change request period
@startuml preview : Determine instances \n for which a change \nis expected in the \n change request period started : Planned changes \n are monitored \nand documented ended: Finishing change \n documentation toReview: Active confirmation \n by the purchaser finished: Change request period \n processing completed [*] -> preview: Creates if the change request \n go in state "toApproval" or \n a previous change request period \n is finished preview --> started: Start time of the \nchange period reached started -> ended : End time of the \nchange period reached ended --> toReview: Not all \n planned changes \n have been executed ended --> finished: All planned \n changes \n are executed \n as planned toReview -> finished: click on \n "**Reviewed**" \n button finished -> [*] @enduml
For the change request period exists the following states:
reviewed. Except for the manual state changes to
reviewed, these states are automated by run and can not be influenced by the user.
- create preview-init
- periodic recreation of preview-init
- process changes
- update reviewed user and time
Illustration: Possible change request period state transitions