Skip to content

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 Item Inventory.

Entities

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

Processs

  • Define change request

  • Monitore change request

    • optional review the result of an change request period
    • Documentation

Best practices

How I should interpret the change request period result?

Workflow & states

Change request

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

edit (automatic)

  • useres can edit the configurations

edit --> toApproval (manual)

  • creation of first change request period (preview-init)

toApproval --> edit (manual)

  • delete all change request periods

toApproval --> active (manual)

  • recreation of first change request period (init)

toApproval --> active (manual/automatic)

  • 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: preview --> started --> ended --> reviewed. Except for the manual state changes to reviewed, these states are automated by run and can not be influenced by the user.

preview (automatic)

  • create preview-init
  • periodic recreation of preview-init

preview --> started (automatic)

  • init
  • process changes

started --> ended (automatic)

  • finalize

ended --> toReview (manual)

  • update reviewed user and time

Illustration: Possible change request period state transitions