Change Management. Bizagi Suite

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

Change Management 3 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

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.

Change Management 5 Change Management Version: 1.0 Author: 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.

Change Management 6 Process Elements RFC Entering This phase covers the activities that are carried out to formally submit the RFC (Request for Change) to the Change Management Department. Enter RFC 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.

Change Management 7 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 : This form is used to enter the information of the RFC Prototype:

Change Management 8 Actions Type On enter Get Requester: This rule is used to obtain the information of the person who opened the case.

Change Management 9 On save On exit Get Impact Level: Rule to obtain the impact level of the RFC according to the established policies. Update History: This rule updates the history of the RFC. Technical Review Required? 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 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

Change Management 10 Allocations Condition 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 : This form is used to enter the information related to the technical review Prototype:

Change Management 11

Change Management 12 Actions Type 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 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 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

Change Management 13 Allocations Condition 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 : This form is used to enter the information related to initial evaluation of the RFC Prototype:

Change Management 14

Change Management 15 Actions Type On enter On save Set Opening Date: Rule to set the RFC opening date Get Impact Level: Rule to obtain the impact level of the RFC according to the established policies RFC Evaluation Result 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>

Change Management 16 Thank you for your comprehension. Yours sincerely Change Management Actions Type 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 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

Change Management 17 Actions Type 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. Request Changes 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 On enter Generate Email: Rule to create the email that will be sent in this activity

Change Management 18 Type of Change 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 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 This phase covers the necessary activities to authorize the RFC according to its type and classification.

Change Management 19 Authorize Change Normal changes with low impact must be authorized by the Change Manager. Performers Change Manager Allocations Condition This activity must be performed by the Change Manager The activity is assigned to the person with the Role of Change Manager Forms Name: Change Authorization Form : This form is used to enter the information related to the RFC Authorization Prototype:

Change Management 20

Change Management 21 Actions Type 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 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 This activity must be performed by the Change Manager The activity is assigned to the person with the Role of Change Manager Forms Name: CAB Meeting Form : This form is used to enter the information related to the RFC Authorization

Change Management 22 Prototype:

Change Management 23 Actions Type 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 ECAB Approval Required? 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 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.

Change Management 24 Performers Change Manager Allocations Condition 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 : This form is used to enter the information related to the RFC Authorization Prototype:

Change Management 25

Change Management 26 Actions Type 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 Authorized? 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 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:

Change Management 27 <RFC.RejectionComments> Thank you for your comprehension. Yours sincerely Change Management Actions Type 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 Type of Change 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.

Change Management 28 Actions Type On enter Change Status: Rule to change the status of the RFC to Authorized Receive and Plan Change 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 This activity must be performed by the Change Coordinator The activity is assigned to the person with the Role of Change Coordinator. Forms Name: Application Change Plan Form : This form is used to enter the information related to the Change Planning Prototype:

Change Management 29

Change Management 30 Actions Type On enter On exit Update History: This rule updates the RFC history. 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 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 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.

Change Management 31 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 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 : This form is used to enter the information related to Test Results Prototype:

Change Management 32

Change Management 33 Actions Type On enter On exit Update History: This rule updates the RFC history Change Status: Rule to change the status of the RFC to Under Test 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? 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 Subprocess. Implementation Once the RFC has been authorized the implementation phase starts. Here, the Change coordinator plans, communicates and executes the Change Implementation.

Change Management 34 Coordinate and Schedule Implementation 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 Condition 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 : This form is used to enter the information related to Implementation Planning Prototype:

Change Management 35

Change Management 36 Communicate Implementation Schedule 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.Change> Any questions or comments please contact us Yours sincerely Change Management Actions Type 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 Scheduled Enter Implementation Results Once the Change has been implemented, the Change Coordinator enters the results of the implementation

Change Management 37 Performers Change Coordinator Allocations Condition 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 : This form is used to enter the information related to the Change Implementation Results Prototype:

Change Management 38

Change Management 39 Actions Type 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 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 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 The Requester reports the results of the implementation and evaluates the success of the change by answering some questions.

Change Management 40 Performers Requester Allocations Condition 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 : This form is used to enter the information related to the evaluation of the change. Prototype:

Change Management 41

Change Management 42 Wait for Requester Evaluation 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 On enter Timer Duration: Rule to set the timer duration Requester Authorizes closing the RFC? 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 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.

Change Management 43 Evaluate Change Failures 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 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 : Prototype:

Change Management 44

Change Management 45 Actions Type On exit Change Status to Ready to Close :Rule to change the status of the RFC to "Ready to Close" Review and Close 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 This activity must be performed by the Change Manager The activity is assigned to the person with the Role of Change Manager

Change Management 46 Forms Name: Final Review Form : Prototype:

Change Management 47 Actions Type On exit Change Status: Rule to change the status of the RFC to Closed

Change Management 48 Requirements Development Version: 1.0 Author: 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 An email is sent to the person assigned to develop a specific requirement to inform him/her such assignment.

Change Management 49 Script Dear <Requirement.Responsible> You have been selected to develop the following requirement: <Requirement.> 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 Generate Email: Rule to create the email that will be sent in this activity Report Development Results In this activity the developer in charge of the requirement enters the results of its development. Performers Developer

Change Management 50 Allocations Condition 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 : This form is used to enter the information related to Development Results Prototype:

Change Management 51 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