Change
Management Bizagi Suite
Change Management | 2
Table of Contents
Change Management .........................................................................................................................5
Process Elements ..........................................................................................................................6
RFC Entering ...........................................................................................................................6
Enter RFC .................................................................................................................................6
¿Technical Review Required? ...........................................................................................8
Technical Review and Sign off .........................................................................................8
Impact and Risk Analysis ....................................................................................................11
Review, Assess and Evaluate ............................................................................................11
RFC Evaluation Result ....................................................................................................... 14
Send Notification of Rejection ....................................................................................... 14
Send Notification ................................................................................................................ 15
Request Changes ................................................................................................................ 16
Type of Change ................................................................................................................... 16
Impact Level ......................................................................................................................... 17
Authorization ......................................................................................................................... 17
Authorize Change ............................................................................................................... 17
Change Advisory Board Authorization ....................................................................... 19
¿ECAB Approval Required? ............................................................................................. 21
Emergency Change Advisory Board Authorization ................................................ 21
¿Change Authorized? ....................................................................................................... 24
Send Notification of Rejection ...................................................................................... 24
Type of Change .................................................................................................................. 25
Receive and Plan Change ............................................................................................... 25
Requirements Development ................................................................................ 28
Enter Test Results .............................................................................................................. 28
Test Successful? ................................................................................................................... 31
Implementation .................................................................................................................... 31
Coordinate and Schedule Implementation ............................................................... 31
Communicate Implementation Schedule ................................................................. 34
Copyright © 2016 | Bizagi Confidential
Change Management | 3
Enter Implementation Results ....................................................................................... 34
Post Implementation Review......................................................................................... 37
Change Evaluation .......................................................................................................... 37
Evaluate Change ................................................................................................................ 37
Wait for Requester Evaluation ...................................................................................... 40
Requester Authorizes closing the RFC? ..................................................................... 40
Evaluate Change Failures ................................................................................................. 41
Review and Close ............................................................................................................... 43
Requirements Development ......................................................................................................... 46
Process Elements ....................................................................................................................... 47
Notify Assignment ............................................................................................................ 47
Report Development Results ...................................................................................... 48
Performers ........................................................................................................................................... 49
Copyright © 2016 | Bizagi Confidential
Change Management | 4
Organizations are supported by technologies to increase the business added-value and
concentrate their efforts and resources on achieving high customer satisfaction and
economic profits. Businesses are dependent on information technology and there has
to be defined procedures and policies to efficiently manage it.
Reliability of the technological resources is fundamental. Ensuring total availability,
capability and security according to business demands, can be a real headache for
organizations. Information Technology Departments have been created to provide
assurance in the availability and reliability of information, and the proper technological
infrastructure operation. But the bigger the organization, the more difficult is the
technological resources management. Change Management is one of the areas where
there is most risk involved.
Change Management responds to the needs of introducing changes as part of the
business continuity, new business requirements and continuous improvement. It also
minimizes the impact and disruption by properly evaluating possible effects, planning
and controlling the execution of changes.
Bizagi´s Change Management Process template is based on the principals of ITIL V3
practices to help guarantee Changes by planning, impact and risk evaluation, level of
authorization, communication, implementation and documentation. The definition of a
standard process flow, responsibilities, necessary information that must be recorded
for each activity and the traceability of each change will allow you to prioritize and
respond to change requests, reduce the number of unsuccessful changes, meet
external requirements, provide better estimations of time and cost, aid productivity,
reduce response times and catch useful data for continuous improvement.
Analyze and implement the changes for your organization in an agile and efficient way.
Copyright © 2016 | Bizagi Confidential
Change Management | 5
Change Management
Description
The process starts with the creation of an RFC (Request for Change) by a person or
group. Once the RFC has been planned and reviewed it is submitted to the Change
Management Department. This department establishes an initial assessment and
evaluation and decides if the RFC is accepted, rejected or requires amendment.
Changes have to be approved according to their classification and impact level.
When the RFC has been authorized, its implementation is planned, communicated and
executed. Then the Change implementation is evaluated by the Requester (person or
group) who confirms if the implementation was successful or not. The necessary actions
to remedy the unexpected or undesired effects of the implementation are performed
if required.
Finally, the Change manager reviews the development of the Change and closes the
RFC.
Copyright © 2016 | Bizagi Confidential
Change Management | 6
Process Elements
RFC Entering
Description
This phase covers the activities that are carried out to formally submit the RFC (Request
for Change) to the Change Management Department.
Enter RFC
Description
In this activity the Change Requester enters the information related to the proposed
change on the RFC (Request for Change). The level of detail of the information depends
on the type and impact of the change.
The following are definitions of information that must be included in the RFC and
defines the flow the process will follow:
Type of Change
Standard: Is a pre-authorized Change to applications or infrastructure for which
the risk is low and its effects are known and well understood.
Normal: A Normal change is a change that must follow the complete change
management process.
Emergency: Is a change that requires immediate action to restore service or
prevent service disruption.
Change Classification
Infrastructure: Change related to any component of the technological
infrastructure of the organization.
Applications: Change related to any technological application of the
organization.
Copyright © 2016 | Bizagi Confidential
Change Management | 7
Impact
The impact is a measure that defines the level of effect that a change has over the
business process and users. Normally, the impact level is defined through an evaluation
that uses an impact matrix. This matrix is a set of questions, whereby each one has an
associated set of answers and each answer has a related score. The total score defines
the impact level according to established policies. You can define the questions,
answers and scores in the matrix that Bizagi offers you in the form of this activity.
For more information about question parameterization please refer to the Change
Management Construction Document.
Performers
Requester
Forms
Name: Enter RFC Form
Description: This form is used to enter the information of the RFC
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 8
Actions
Type Description
On enter Get Requester: This rule is used to obtain
the information of the person who
opened the case.
On save Get Impact Level: Rule to obtain the
impact level of the RFC according to the
established policies.
On exit Update History: This rule updates the
history of the RFC.
¿Technical Review Required?
Description
This gateway evaluates the condition related to the technical review of the RFC
Gateways
YES: The process continues to the activity “Review and Sign Off”
NO: The process continues to the activity “Review, Assess and Evaluate”
Technical Review and Sign off
Description
The technical group in charge of the type of change requested, reviews the technical
information. This review is performed to verify the correctness of the procedures,
documentation, feasibility and worst case impact among other things. Once the
information has been reviewed the technical group decides whether to issue the sign
off or not.
Performers
Technical Group
Copyright © 2016 | Bizagi Confidential
Change Management | 9
Allocations
Condition Description
This activity must be performed by the
proper technical group according to the
type of change requested.
The activity is assigned to the person with
the Role “Technical group Member”
Forms
Name: Technical Review Form
Description: This form is used to enter the information related to the technical
review
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 10
Copyright © 2016 | Bizagi Confidential
Change Management | 11
Actions
Type Description
On exit 1-Get Requester: This rule is used to
obtain the information of the technician
who reviewed the RFC.
2-Update History: This rule updates the
history of the RFC
3-Change Status: Rule to change the
status of the RFC to “Requested”
Impact and Risk Analysis
Description
In this phase an impact and risk evaluation is performed by the Change Management
Department to identify the feasibility and level of authorization necessary to start the
Change Implementation
Review, Assess and Evaluate
Description
The Change Analyst reviews the RFC to verify if the request information is complete, is
not necessary or it is related to other RFCs. The analyst decides if the RFC is accepted,
rejected or returned to the requester to make the necessary amendments.
An assessment and evaluation of the impact and risk of the change must be executed
for the accepted RFCs. The impact level and priority must be assigned to the RFC
according to the company´s policies.
Performers
Change Analyst
Copyright © 2016 | Bizagi Confidential
Change Management | 12
Allocations
Condition Description
This activity must be performed by the
Change Analyst
The activity is assigned to the person with
the Role “Change Analyst”
Forms
Name: Impact Evaluation Form
Description: This form is used to enter the information related to initial
evaluation of the RFC
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 13
Copyright © 2016 | Bizagi Confidential
Change Management | 14
Actions
Type Description
On enter Set Opening Date: Rule to set the RFC
opening date
On save Get Impact Level: Rule to obtain the
impact level of the RFC according to the
established policies
RFC Evaluation Result
Description
This gateway evaluates the condition related to the evaluation of the RFC performed
by the Change Analyst
Gateways
Accepted: The process continues to the “Send Notification” activity
Rejected: The process continues to the “Send Notification of Rejection”
activity
Request Changes: The process continues to the “Create RFC” activity
Send Notification of Rejection
Description
A notification is sent to the Requester to inform him/her of the reasons of the RFC
rejection
Script
Dear <RFC.Requester. fullname>
We regret to inform you that your RFC <CaseNumber> has been rejected for the
following reasons:<RFC.RejectionComments>
Thank you for your comprehension.
Yours sincerely
Change Management
Copyright © 2016 | Bizagi Confidential
Change Management | 15
Actions
Type Description
On enter Generate Email: Rule to create the email
that will be sent in this activity
Change Status: Rule to change the status
of the RFC to “Rejected”
Send Notification
Description
A notification is sent to the Requester to inform the acceptance of the RFC
Script
Dear <RFC.Requester. fullname>
We have accepted your RFC <CaseNumber>. The Change will be analyzed and we will
inform you about our decision as soon as possible.
Yours sincerely
Change Management
Actions
Type Description
On enter Generate Email: Rule to create the email
that will be sent in this activity.
Change Status: Rule to change the status
of the RFC to “Accepted”.
Copyright © 2016 | Bizagi Confidential
Change Management | 16
Request Changes
Description
A notification is sent to request changes to the RFC
Script
Dear <RFC.Requester.fullname>
We have analized your RFC <CaseNumber>. It is necessary to make the following
changes before we can evaluate your request:<RFC.RequestedChanges>
Yours sincerely
Change Management
Actions
Type Description
On enter Generate Email: Rule to create the email
that will be sent in this activity
Type of Change
Description
This gateway evaluates the classification of the RFC
Gateways
STANDARD: The process continues to the “Type of Change” gateway
NORMAL: The process continues to the “Impact Level” gateway
EMERGENCY: The process continues to the “ECAB Authorization Required?”
gateway
Copyright © 2016 | Bizagi Confidential
Change Management | 17
Impact Level
Description
This gateway evaluates the impact level of the RFC to manage the correct level of
authorization.
Gateways
LOW: The process continues to the “Authorize Change” activity.
MEDIUM, HIGH: The process continues to the “Meet CAB and Authorize
Change” activity.
Authorization
Description
This phase covers the necessary activities to authorize the RFC according to its type
and classification.
Authorize Change
Description
Normal changes with low impact must be authorized by the Change Manager.
Performers
Change Manager
Allocations
Condition Description
This activity must be performed by the
Change Manager
The activity is assigned to the person with
the Role of Change Manager
Copyright © 2016 | Bizagi Confidential
Change Management | 18
Forms
Name: Change Authorization Form
Description: This form is used to enter the information related to the RFC
Authorization
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 19
Actions
Type Description
On exit Approved by: Rule to obtain the
information of the level of authorization
that approved the change.
Update History: This rule updates the RFC
history
On save Get Impact Level: Rule to obtain the
impact level of the RFC according to the
established policies
Change Advisory Board Authorization
Description
Normal Changes with Medium or High impact must be assessed, evaluated, authorized
and prioritized by the Change Advisory Board (CAB). In this activity the Change
Manager enters the evaluation results of the CAB meeting.
Performers
Change Manager
Allocations
Condition Description
This activity must be performed by the
Change Manager
The activity is assigned to the person with
the Role of Change Manager
Copyright © 2016 | Bizagi Confidential
Change Management | 20
Forms
Name: CAB Meeting Form
Description: This form is used to enter the information related to the RFC
Authorization
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 21
Actions
Type Description
On exit 1-Approved by: Rule to obtain the
information of the level of authorization
that approved the change.
2-Update History: This rule updates the
RFC history.
On save 1-Get Impact Level: Rule to obtain the
impact level of the RFC according to the
established policies
¿ECAB Approval Required?
Description
This gateway evaluates the need to authorize an Emergency Change by the Emergency
Change Advisory Board.
Gateways
YES: The process continues to the “Meet ECAB and Authorize Change”
activity.
NO: The process continues to the “Change Authorized” gateway.
Emergency Change Advisory Board Authorization
Description
Emergency Changes cannot wait for a formal CAB meeting so an Emergency Change
Advisory Board (ECAB) must be conformed to assess, evaluate and authorize them. In
this activity the Change Manager enters the evaluation results of the ECAB meeting.
Performers
Change Manager
Copyright © 2016 | Bizagi Confidential
Change Management | 22
Allocations
Condition Description
This activity must be performed by the
Change Manager
The activity is assigned to the person with
the Role of Change Manager
Forms
Name: ECAB Meeting Form
Description: This form is used to enter the information related to the RFC
Authorization
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 23
Copyright © 2016 | Bizagi Confidential
Change Management | 24
Actions
Type Description
On exit 1-Approved by: Rule to obtain the
information of the level of authorization
that approved the change.
2-Update History: This rule updates the
RFC history
On save 1-Get Impact Level: Rule to obtain the
impact level of the RFC according to the
established policies
¿Change Authorized?
Description
This gateway evaluates if the RFC was authorized.
Gateways
YES: The process continues to the “Type of Change” gateway.
NO: The process continues to the “Send Notification of Rejection” activity.
Send Notification of Rejection
Description
A notification is sent to the Requester to inform him/her of the rejection of the RFC.
Script
Dear <RFC.Requester. fullname>
We regret to inform you that your RFC <CaseNumber> has been rejected for the
following reasons:
<RFC.RejectionComments>
Thank you for your comprehension.
Yours sincerely
Change Management
Copyright © 2016 | Bizagi Confidential
Change Management | 25
Actions
Type Description
On enter 1-Generate Email: Rule to create the email
that will be sent in this activity
2-Change Status: Rule to change the
status of the RFC to “Rejected”
Type of Change
Description
This gateway evaluates the type of change of the RFC
Gateways
INFRASTRUCTURE: The process continues to the “Coordinate and Schedule
Implementation” activity.
APPLICATIONS: The process continues to the “Receive and Plan Change”
activity.
Actions
Type Description
On enter 1-Change Status: Rule to change the
status of the RFC to “Authorized”
Receive and Plan Change
Description
The Change Coordinator defines with the technical group the application change plan.
The plan establishes the project duration, change requirements and the person
responsible for each one.
Performers
Change Coordinator
Copyright © 2016 | Bizagi Confidential
Change Management | 26
Allocations
Condition Description
This activity must be performed by the
Change Coordinator
1-The activity is assigned to the person
with the Role of Change Coordinator.
Forms
Name: Application Change Plan Form
Description: This form is used to enter the information related to the Change
Planning
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 27
Copyright © 2016 | Bizagi Confidential
Change Management | 28
Actions
Type Description
On enter 1-Update History: This rule updates the
RFC history.
On exit 1-Get Implementer: Rule to obtain the
information of the Change Coordinator.
2-Change Status: Rule to change the
status of the RFC to “Under
Development”.
Requirements Development
Description
This multiple sub-process is thrown for each requirement. In this sub-process, the
persons assigned to each requirement are notified about their allocation and, once the
requirement has been developed, they report the results of the development.
Diagram
Requirement Development
Process
Loop type
Multi-Instance
MI Ordering
Parallel
Enter Test Results
Description
Once the development of all requirements have been accomplished it is necessary to
perform certification tests to ensure that what has been developed corresponds to what
was requested. Bizagi suggests establishing a Test Case format.
Copyright © 2016 | Bizagi Confidential
Change Management | 29
The success of each developed requirement is verified in this activity. When all
requirements work as expected the “Pass to production checklist” is attached.
Performers
Change Coordinator
Allocations
Condition Description
This activity must be performed by the
Change Coordinator
The activity is assigned to the person with
the Role of Change Coordinator.
Forms
Name: Test Results Form
Description: This form is used to enter the information related to Test Results
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 30
Copyright © 2016 | Bizagi Confidential
Change Management | 31
Actions
Type Description
On enter 1-Update History: This rule updates the
RFC history Change Status: Rule to change
the status of the RFC to “Under Test””
On exit 1-Test Concluded: this rule evaluates if all
the requirements pass the tests.
2-Throw Sub-process; Rule to identify the
Requirements that must be reviewed.
Test Successful?
Description
This gateway evaluates if the all requirements worked as expected in the test phase.
Gateways
YES: The process continues to the “Coordinate and Schedule Implementation”
activity.
NO: The process continues to the “Requirements Development” Sub-process.
Implementation
Description
Once the RFC has been authorized the implementation phase starts. Here, the Change
coordinator plans, communicates and executes the Change Implementation.
Coordinate and Schedule Implementation
Description
In this activity the Change Coordinator defines the implementation plan. The date of
implementation, the expected implementation time and the people that have to be
notified must be entered.
Copyright © 2016 | Bizagi Confidential
Change Management | 32
Performers
Change Coordinator
Allocations
Condition Description
This activity must be performed by the
Change Coordinator
The activity is assigned to the person with
the Role of Change Coordinator.
Forms
Name: Implementation Plan Form
Description: This form is used to enter the information related to
Implementation Planning
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 33
Copyright © 2016 | Bizagi Confidential
Change Management | 34
Communicate Implementation Schedule
Description
An email is sent to the people affected by the change to ensure that the change and
its scheduled implementation is known. This way the individual activities can be planned
previously.
Script
We wish to inform you that we will be implementing a Change on
<RFC.ImplemenationDate> and its estimated duration is <RFC.Estimated duration>,
the Change description is: <RFC.ChangeDescription>
Any questions or comments please contact us
Yours sincerely
Change Management
Actions
Type Description
On enter 1-Generate Email: Rule to create the email
that will be sent in this activity
2-Change Status: Rule to change the
status of the RFC to “Scheduled””
Enter Implementation Results
Description
Once the Change has been implemented, the Change Coordinator enters the results
of the implementation
Performers
Change Coordinator
Copyright © 2016 | Bizagi Confidential
Change Management | 35
Allocations
Condition Description
This activity must be performed by the
Change Coordinator
The activity is assigned to the person with
the Role of Change Coordinator.
Forms
Name: Enter Implementation Results Form
Description: This form is used to enter the information related to the Change
Implementation Results
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 36
Copyright © 2016 | Bizagi Confidential
Change Management | 37
Actions
Type Description
On exit 1-Change Status: Rule to change the
status of the RFC to “Implemented”
2-Update History: This rule updates the
history of the RFC
Post Implementation Review
Description
Once the implementation has been accomplished, the Requester should evaluate it and
authorize or reject the closure of the RFC. If the closure of the RFC is rejected, the
necessary actions to remedy the unexpected effects of the implementation must be
performed by the Change Coordinator. When the RFC is ready to be closed, the Change
Manager performs the final review and closes the case.
Change Evaluation
Description
This Event based gateway is used to give the Requester a maximum time to evaluate
the Change Implementation. The “Evaluate Change” activity enables the Requester to
report his/her concept about the Change. If he/she does not accomplish this activity
within an established timeframe, it will be disabled assuming the Change was a success
and did not have unexpected or undesired effects.
Evaluate Change
Description
The Requester reports the results of the implementation and evaluates the success of
the change by answering some questions.
Copyright © 2016 | Bizagi Confidential
Change Management | 38
Performers
Requester
Allocations
Condition Description
This activity must be performed by the
Requester of the Change
The activity is assigned to the person who
opened the case through the CaseCreator
expression.
Forms
Name: Requester Evaluation Form
Description: This form is used to enter the information related to the evaluation
of the change.
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 39
Copyright © 2016 | Bizagi Confidential
Change Management | 40
Wait for Requester Evaluation
Description
This Intermediate Timer Event controls the maximum time the Requester has to
evaluate the Change Implementation. If the time is exceeded, the timer will continue
to the next task.
Actions
Type Description
On enter Timer Duration: Rule to set the timer
duration
Requester Authorizes closing the RFC?
Description
This gateway evaluates if the Requester authorized the closure of the RFC
Gateways
YES: The process continues to the “Review and Close” activity.
NO: The process continues to the “Evaluate Change Failures” activity.
Actions
Type Description
On enter Change Status: Rule to change the status
of the RFC to “Rejected by the Requester”
or "Ready to Close" according to the
Requester´s Review.
Copyright © 2016 | Bizagi Confidential
Change Management | 41
Evaluate Change Failures
Description
In this activity the Change Coordinator reviews the reasons why the Requester did not
authorize the closure of the Change and reports the actions that were carried out to
remedy the failures of the change (Application of Remediation plan, evaluation of the
CAB, a new RFC to undo the effects of the current Change, etc.).
Performers
Change Coordinator
Allocations
Condition Description
This activity must be performed by the
Change Coordinator
The activity is assigned to the person with
the Role of Change Coordinator.
Forms
Name: Evaluate Failures Form
Description:
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 42
Copyright © 2016 | Bizagi Confidential
Change Management | 43
Actions
Type Description
On exit Change Status to Ready to Close :Rule to
change the status of the RFC to "Ready to
Close"
Review and Close
Description
Useful information can be extracted from finished cases as part of Change
Management continuous improvement. In this activity the Change Manager reviews
and evaluates the development of the Change verifying if requester and stakeholders
are satisfied with the results, if there are unexpected effects, if the change was executed
as planned, on time and on cost, and the effects of remediation plans, if necessary.
Finally, the CMDB (Change Management Database) must be updated.
Performers
Change Manager
Allocations
Condition Description
This activity must be performed by the
Change Manager
The activity is assigned to the person with
the Role of Change Manager
Copyright © 2016 | Bizagi Confidential
Change Management | 44
Forms
Name: Final Review Form
Description
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 45
Actions
Type Description
On exit Change Status: Rule to change the status
of the RFC to “Closed”
Copyright © 2016 | Bizagi Confidential
Change Management | 46
Requirements Development
Description
This multiple sub-process is thrown for each requirement. In this sub-process, the
persons assigned to each requirement are notified about their allocation and, once the
requirement has been developed, they report the results of the development.
Copyright © 2016 | Bizagi Confidential
Change Management | 47
Process Elements
Notify Assignment
Description
An email is sent to the person assigned to develop a specific requirement to inform
him/her such assignment.
Script
Dear <Requirement.Responsible>
You have been selected to develop the following requirement:
<Requirement.Description>
The due date of this development is <Requirement.Duedate>
Please report your results in Bizagi once the requirement has been accomplished.
Thank you
Change Coordinator.
Actions
Type Description
On enter Generate Email: Rule to create the email
that will be sent in this activity
Copyright © 2016 | Bizagi Confidential
Change Management | 48
Report Development Results
Description
In this activity the developer in charge of the requirement enters the results of its
development.
Performers
Developer
Allocations
Condition Description
This activity must be performed by the
Developer in charge of the Requirement
The activity is the responsibility of the
person assigned to the Requirement
Development by the Change Coordinator
in the “Receive and Plan Change” activity.
Forms
Name: Development Results Form
Description: This form is used to enter the information related to Development
Results
Prototype:
Copyright © 2016 | Bizagi Confidential
Change Management | 49
Performers
Requester
Person or group who identifies the need for the change and develops, plans, and
submits the RFC
Change Manager
The main functions of the Change Manager are:
Authorize changes with low impact
Meet with the Change Advisory Board and the Emergency Change Advisory
Board when the appropriate.
Review the documentation of an RFC
Create change management metrics
Technical Group
Group of technicians in charge of reviewing technical information of RFCs related to
their specialized area
Change Coordinator
Person in charge of coordinating and monitoring RFCs developments, tests and
implementations.
Developer
Person who develops requirements