Change Management
ITIL Based
Bizagi Process Modeler
www.bizagi.com
Table of Contents
1
CHANGE MANAGEMENT ............................................................................................................................................. 5
DESCRIPTION ........................................................................................................................................................................ 5
PROCESS ELEMENTS .................................................................................................................................................................. 6
RFC ENTERING ................................................................................................................................................................. 6
ENTER RFC ....................................................................................................................................................................... 6
¿TECHNICAL REVIEW REQUIRED? ................................................................................................................................... 8

TECHNICAL REVIEW AND SIGN OFF................................................................................................................................ 8
IMPACT AND RISK ANALYSIS ....................................................................................................................................... 10
REVIEW, ASSESS AND EVALUATE ................................................................................................................................. 10
RFC EVALUATION RESULT ........................................................................................................................................... 12
SEND NOTIFICATION OF REJECTION ........................................................................................................................... 12
SEND NOTIFICATION .................................................................................................................................................... 13
REQUEST CHANGES ...................................................................................................................................................... 13
TYPE OF CHANGE .......................................................................................................................................................... 14

IMPACT LEVEL ................................................................................................................................................................ 14
AUTHORIZATION ........................................................................................................................................................... 15
AUTHORIZE CHANGE .................................................................................................................................................... 15
CHANGE ADVISORY BOARD AUTHORIZATION .......................................................................................................... 17
¿ECAB APPROVAL REQUIRED? ................................................................................................................................... 19
EMERGENCY CHANGE ADVISORY BOARD AUTHORIZATION .................................................................................... 19
¿CHANGE AUTHORIZED? ............................................................................................................................................. 21
SEND NOTIFICATION OF REJECTION ........................................................................................................................... 21
TYPE OF CHANGE .......................................................................................................................................................... 22

RECEIVE AND PLAN CHANGE ....................................................................................................................................... 22
REQUIREMENTS DEVELOPMENT .................................................................................................................................. 24
ENTER TEST RESULTS .................................................................................................................................................... 24

TEST SUCCESSFUL? ....................................................................................................................................................... 26
IMPLEMENTATION ......................................................................................................................................................... 26
COORDINATE AND SCHEDULE IMPLEMENTATION ..................................................................................................... 26


www.bizagi.com
COMMUNICATE IMPLEMENTATION SCHEDULE .......................................................................................................... 28
ENTER IMPLEMENTATION RESULTS ............................................................................................................................. 28
POST IMPLEMENTATION REVIEW................................................................................................................................. 30
CHANGE EVALUATION ............................................................................................................................................... 30

EVALUATE CHANGE....................................................................................................................................................... 30
WAIT REQUESTER EVALUATION................................................................................................................................... 32
REQUESTER AUTHORIZE CLOSING THE RFC? ............................................................................................................. 33
EVALUATE CHANGE FAILURES...................................................................................................................................... 33
REVIEW AND CLOSE ...................................................................................................................................................... 36
2
REQUIREMENTS DEVELOPMENT ........................................................................................................................... 39
DESCRIPTION ..................................................................................................................................................................... 39
PROCESS ELEMENTS ............................................................................................................................................................... 40
NOTIFY ASSIGNMENT ................................................................................................................................................... 40
REPORT DEVELOPMENT RESULTS ............................................................................................................................. 40
3
PERFORMERS ................................................................................................................................................................. 42
www.bizagi.com
Confidential
3
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.
www.bizagi.com
Confidential
4
1 Change Management
Version: 1.0
Author:
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.
www.bizagi.com
Confidential
5
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.
www.bizagi.com
Confidential
6
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:
www.bizagi.com
Confidential
7
Actions
Type
On enter
Description
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
Allocations
Condition
Description
This activity must be performed by the proper The activity is assigned to the person with the
technical group according to the type of change Role “Technical group Member”
requested.
www.bizagi.com
Confidential
8
Forms
Name: Technical Review Form
Description: This form is used to enter the information related to the technical review
Prototype:
Actions
Type
On exit
Description
Get Requester: This rule is used to obtain the
information of the technician who reviewed the
RFC.
Update History: This rule updates the history of
the RFC
Change Status: Rule to change the status of the
RFC to “Requested”
www.bizagi.com
Confidential
9
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
Allocations
Condition
Description
This activity must be performed by the Change The activity is assigned to the person with the
Analyst
Role “Change Analyst”
Forms
Name: Impact Evaluation Form
Description: This form is used to enter the information related to initial evaluation of the
RFC
www.bizagi.com
Confidential
10
Prototype:
Actions
Type
On enter
Description
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
www.bizagi.com
Confidential
11
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
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
Actions
Type
On enter
Description
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”
www.bizagi.com
Confidential
12
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
On enter
Description
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”
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
www.bizagi.com
Confidential
13
Actions
Type
On enter
Description
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
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
www.bizagi.com
Confidential
14
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 The activity is assigned to the person with the
Manager
Role of Change Manager
Forms
Name: Change Authorization Form
Description: This form is used to enter the information related to the RFC Authorization
www.bizagi.com
Confidential
15
Prototype:
Actions
Type
On exit
Description
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
www.bizagi.com
Confidential
16
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 The activity is assigned to the person with the
Manager
Role of Change Manager
Forms
Name: CAB Meeting Form
Description: This form is used to enter the information related to the RFC Authorization
www.bizagi.com
Confidential
17
Prototype:
Actions
Type
On exit
Description
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
www.bizagi.com
Confidential
18
¿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
Allocations
Condition
Description
This activity must be performed by the Change The activity is assigned to the person with the
Manager
Role of Change Manager
Forms
Name: ECAB Meeting Form
Description: This form is used to enter the information related to the RFC Authorization
www.bizagi.com
Confidential
19
Prototype:
Actions
Type
On exit
Description
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
www.bizagi.com
Confidential
20
¿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
Actions
Type
On enter
Description
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”
www.bizagi.com
Confidential
21
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
On enter
Description
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
Allocations
Condition
Description
This activity must be performed by the Change The activity is assigned to the person with the
Coordinator
Role of Change Coordinator.
www.bizagi.com
Confidential
22
Forms
Name: Application Change Plan Form
Description: This form is used to enter the information related to the Change Planning
Prototype:
www.bizagi.com
Confidential
23
Actions
Type
Description
On enter
Update History: This rule updates the RFC history
On exit
Get Implementer: Rule to obtain the information
of the Change Coordinator.
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.
The success of each developed requirement is verified in this activity. When all requirements work as
expected the “Pass to production checklist” is attached.
www.bizagi.com
Confidential
24
Performers
Change Coordinator
Allocations
Condition
Description
This activity must be performed by the Change The activity is assigned to the person with the
Coordinator
Role of Change Coordinator.
Forms
Name: Test Results Form
Description: This form is used to enter the information related to Test Results
Prototype:
www.bizagi.com
Confidential
25
Actions
Type
On enter
Description
Update History: This rule updates the RFC history
Change Status: Rule to change the status of the
RFC to “Under Test””
On exit
Test Concluded: this rule evaluates if all the
requirements pass the tests.
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.
Performers
Change Coordinator
www.bizagi.com
Confidential
26
Allocations
Condition
Description
This activity must be performed by the Change The activity is assigned to the person with the
Coordinator
Role of Change Coordinator.
Forms
Name: Implementation Plan Form
Description: This form is used to enter the information related to Implementation Planning
Prototype:
www.bizagi.com
Confidential
27
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
On enter
Description
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 “Scheduled””
Enter Implementation Results
Description
Once the Change has been implemented, the Change Coordinator enters the results of the
implementation
Performers
Change Coordinator
www.bizagi.com
Confidential
28
Allocations
Condition
Description
This activity must be performed by the Change The activity is assigned to the person with the
Coordinator
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:
www.bizagi.com
Confidential
29
Actions
Type
Description
On exit
Change Status: Rule to change the status of the
RFC to “Implemented”
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 a some questions.
Performers
Requester
www.bizagi.com
Confidential
30
Allocations
Condition
Description
This activity must be performed by the Requester The activity is assigned to the person who
of the Change
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:
www.bizagi.com
Confidential
31
Wait 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.
www.bizagi.com
Confidential
32
Actions
Type
On enter
Description
Timer Duration: Rule to set the timer duration
Requester Authorize 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
On enter
Description
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.
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
www.bizagi.com
Confidential
33
Allocations
Condition
Description
This activity must be performed by the Change The activity is assigned to the person with the
Coordinator
Role of Change Coordinator.
Forms
Name: Evaluate Failures Form
Description:
Prototype:
www.bizagi.com
Confidential
34
www.bizagi.com
Confidential
35
Actions
Type
On exit
Description
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 The activity is assigned to the person with the
Manager
Role of Change Manager
Forms
Name: Final Review Form
Description:
Prototype:
www.bizagi.com
Confidential
36
www.bizagi.com
Confidential
37
Actions
Type
On exit
Description
Change Status: Rule to change the status of the
RFC to “Closed”
www.bizagi.com
Confidential
38
2 Requirements Development
Version: 1.0
Author:
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.
www.bizagi.com
Confidential
39
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
On enter
Description
Generate Email: Rule to create the email that will
be sent in this activity
Report Development Results
Description
In this activity the developer in charge of the requirement enters the results of its development.
Performers
Developer
www.bizagi.com
Confidential
40
Allocations
Condition
This activity must be performed by
Developer in charge of the Requirement
Description
the 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:
www.bizagi.com
Confidential
41
3 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 RFC´s developments, tests and implementations.
Developer
Person who develops requirements
www.bizagi.com
Confidential
42