change management - bizagi - digital transformation ... · for change) to the change management...

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? ............................................................................................... 9

Technical Review and Sign off ............................................................................................. 9

Impact and Risk Analysis ....................................................................................................... 12

Review, Assess and Evaluate ............................................................................................... 12

RFC Evaluation Result ............................................................................................................ 15

Send Notification of Rejection........................................................................................... 15

Send Notification ..................................................................................................................... 16

Request Changes ..................................................................................................................... 17

Type of Change ........................................................................................................................ 18

Impact Level ............................................................................................................................... 18

Authorization .............................................................................................................................. 18

Authorize Change .................................................................................................................... 19

Change Advisory Board Authorization .......................................................................... 21

¿ECAB Approval Required? ................................................................................................ 23

Emergency Change Advisory Board Authorization ................................................. 23

¿Change Authorized? ............................................................................................................ 26

Send Notification of Rejection.......................................................................................... 26

Type of Change ........................................................................................................................27

Receive and Plan Change.................................................................................................... 28

Requirements Development .................................................................................... 30

Enter Test Results ................................................................................................................... 30

Test Successful? ....................................................................................................................... 33

Implementation ........................................................................................................................ 33

Coordinate and Schedule Implementation ................................................................. 34

Communicate Implementation Schedule .................................................................... 36

Copyright © 2014 | Bizagi Confidential


Enter Implementation Results ........................................................................................... 36

Post Implementation Review............................................................................................. 39

Change Evaluation ............................................................................................................... 39

Evaluate Change...................................................................................................................... 39

Wait for Requester Evaluation .......................................................................................... 42

Requester Authorizes closing the RFC? ........................................................................ 42

Evaluate Change Failures .................................................................................................... 43

Review and Close .................................................................................................................... 45

Requirements Development .............................................................................................................. 48

Process Elements ............................................................................................................................. 48

Notify Assignment.................................................................................................................. 48

Report Development Results .......................................................................................... 49

Performers ................................................................................................................................................... 51



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.



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.



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.

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:



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



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:



Actions

Type Description

On exit 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”

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



Change Analyst


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:



Actions

Type Description

On enter Set Opening Date: Rule to set the RFC

opening date



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

Actions

Type Description

On enter Generate Email: Rule to create the email

that will be sent in this activity


of the RFC to “Rejected”

Send Notification

Description

A notification is sent to the Requester to inform the acceptance of the RFC

Script


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


that will be sent in this activity.


of the RFC to “Accepted”.

Request Changes

Description

A notification is sent to request changes to the RFC

Script


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





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.

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



Change Manager


the Role of Change Manager

Forms

Name: Change Authorization Form

Description: This form is used to enter the information related to the RFC

Authorization

Prototype:



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




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



Change Manager



Forms

Name: CAB Meeting Form


Authorization



Prototype:



Actions

Type Description





history




¿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



Change Manager



Forms

Name: ECAB Meeting Form


Authorization

Prototype:



Actions

Type Description





history




¿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


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 Description




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 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



Change Coordinator


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:



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.


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.

Performers

Change Coordinator

Allocations



Change Coordinator



Forms

Name: Test Results Form

Description: This form is used to enter the information related to Test Results

Prototype:



Actions

Type Description

On enter 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

Allocations



Change Coordinator



Forms

Name: Implementation Plan Form

Description: This form is used to enter the information related to

Implementation Planning

Prototype:



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




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

Allocations



Change Coordinator



Forms

Name: Enter Implementation Results Form

Description: This form is used to enter the information related to the Change

Implementation Results

Prototype:



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 some questions.



Performers

Requester

Allocations



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:



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.



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



Change Coordinator



Forms

Name: Evaluate Failures Form

Description:

Prototype:



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



Change Manager





Forms

Name: Final Review Form

Description:

Prototype:



Actions

Type Description

On exit Change Status: Rule to change the status

of the RFC to “Closed”



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.

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



Report Development Results

Description

In this activity the developer in charge of the requirement enters the results of its

development.

Performers

Developer



Allocations



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:



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

change management - bizagi - digital transformation ... · for change) to the change management...

Documents