某跨国公司变更管理流程设置.docx

ABB IS Service & Supply IntegrationChange ManagementProcess Operations ManualContents1.Introduction61.1Purpose of the document61.2Audience62.Change Management process62.1Definition62.2Scope62.3Process Inputs and Outputs72.4Related Processes72.5Process Objectives72.6Roles and Responsibilities82.7Principles and Policies122.8Change Types122.9Environment Scope162.10Change Creation162.11Approvals172.12Change Evaluation and Assessment182.13Change Planning202.14Lead Time242.15Change Development242.16Change Testing242.17Change Priority252.18Change Outages252.19Change Freeze262.20Change Advisory Board (CAB)262.21Emergency Change Procedure322.22Post Implementation Review342.23Change Closure342.24Notifications352.25Change Management Process Flows & Workflows362.26ADONIS Level 4 Process Flow362.27SNOW Workflows per change type373.Reporting (KPIs + SLAs)494.Tower Specifics504.1EUC504.2EUS504.3Core Software Platform (CSP)504.4Network505.Stakeholders506.Templates506.1RFC Template506.2Functional Specification506.3Change Test Results516.4Implementation plan516.5Backup Plan516.6Point of No return details516.7Communication Plan516.8Backout plan516.9CAB Readiness Checklist516.10CAB Agenda & Minutes516.11Deployment Verification Plan516.12Post Implementation Review516.13Weekly CAB meetings517.Vocabulary528.External References538.1Process Policy Document Change Management538.2Change Management workflows in SNOW538.3Change Management Stakeholders list531. Introduction1.1 Purpose of the documentThe purpose of this document is to explain Change Management process defined and implemented within ABB IS RUN. It describes definitions, scope, policies, activities, roles & responsibilities and many other practicalities that will help understand and run Change Management process from operational perspective. This document outlines the operating guidelines for daily activities and processes used by all Change Management stakeholders.1.2 AudienceThis document is intended to be used by ABB IS RUN personnel and Service Suppliers. Specifically Service Suppliers will be responsible to align their internal working practices to this document in regards to handling Changes.2. Change Management process2.1 DefinitionA Change is defined as the addition, modification or removal of an authorized, planned or supported service or Configuration Item (CI). Changes may occur due to introduction of a new service, modification to an existing service or termination of an existing service in an IT Infrastructure or for fixing a problem in an existing system.Change Management helps organizations understand and work to minimize risks of changes to the IT environment. It is essentially a process for managing the people-side of change. 2.2 ScopeChange Management process can be used to track and manage all IT infrastructure changes. A software application change may include enhancements/modifications to existing applications to address identified problems, address business needs or any other requirement. Similarly a hardware change may include changes to computing devices, network components, storage devices and other hardware Configuration Items (CI) to replace malfunctioning hardware, increase hardware capacity or other requirements. In other words, changes to all Configuration Items will be governed by this process. 2.3 Process Inputs and OutputsUpdated CMDBPIR ReportsApproved and ImplementedChange DocumentationOther ProcessesPIR ReportsBusiness RequirementsChange PoliciesCI Data from CMDBChange Management process2.4 Related ProcessesProcess Input to Change Management Output from Change Management Incident Management Trigger for Change Report on incidents arising out of the failed changes Approvals, Risk Assessment and control of change required to be implemented for incident resolution.Problem Management Trigger for Change Report on problems arising out of the failed changes Approvals, Risk Assessment and control of change required to be implemented for problem resolution.Service Asset andConfiguration Management CI Verification Information on changes to CIs for updates of CMDBKnowledge Management Input for process improvement Change Reports Service Catalogue Management Service Requests Updates to Service CatalogueTable 1Related Processes2.5 Process ObjectivesThe goal of Change Management process is to maintain the integrity of the controlled IS environment. Change Management is the “gateway” through which every change must pass on its way to the controlled environment. Change Management process primarily aims at ensuring the implementation of changes with minimum risk to the business. The objectives of Change Management process are: Ensure efficient and prompt handling of changes Provide accurate and regular information about all planned changes Ensure consistent procedures for change implementation to minimize the risk of failure Minimize Incidents resulting from the introduction of Changes Ensure risk and impact analysis to assess risk of changes and minimize risk of implementation Monitor and track the lifecycle of all changes Ensure proper categorization of changes and that proper procedures are followed for each type of change Reduce bureaucracy without compromising on controls for implementation of changes2.6 Roles and ResponsibilitiesThis section describes roles and responsibilities within Change Management process.2.6.1 Change Requester (ABB, Service Provider)This role is part of current ADONIS process. The Change Requester is the person who creates the change request and submits it for further processing.Major responsibilities include: Creating and submitting a Change Request with accurate and detailed level of information Obtaining additional information, as needed, for submitted Change Requests Working with the OTL Change Coordinator to resolve any data inconsistencies with the request Identifying parties to be notified and defining notification criteria Testing and verifying Change was implemented according to requestProcess RoleOrganizational RoleServiceNow FieldChange Requester (ABB, Service Provider)Service ProvidersABB IS RUNRequested by2.6.2 OTL Change Coordinator (ABB)This role is part of current ADONIS process. The OTL Change Coordinator is responsible for seeing that Change Manager and other specialists bring the Change to a close.Major responsibilities include: Monitoring the lifecycle of an assigned Change Verifying the supporting documentation accompanying the Change Record is complete Assisting Change Requester with change creation Performing Change Assessment (based on questions and answers) Confirming Change Planning done by BTL Change Manager Assisting Change Requester with test implementation when required Chairing CAB/ECAB meetings Conducting Post Implementation Review to verify implementation when required Managing escalations relating to a Change Making sure all required stakeholders are notified about the changeProcess RoleOrganizational RoleServiceNow FieldOTL Change Coordinator (ABB)IS Tower Service CoordinatorChange Task Assignment Group/Change Task Assigned To2.6.3 BTL Change Manager (Service Provider)This role is part of current ADONIS process. BTL Change Manager is responsible for carrying out various activities in order to implement the change.Major responsibilities include: Planning and coordinating technical execution of the Change Implementing/developing fully authorized Change Attempting to resolve any issues with the implementation/development Creating Functional and Technical Specifications Performing unit & integration testing after Change implementation/development Conducting Post Implementation Review to verify implementation when required Updating manuals and operating instructions when applicable Documenting Change implementation/development results (Post Rollout Documentation) Verifying proper authorizations have been obtained and documented in the Change Record prior to scheduling the change Coordinating the implementation/development of the Change Backing out an unsuccessful Change, if required Verifying the update of the CMDB to reflect the implemented ChangeProcess RoleOrganizational RoleServiceNow FieldBTL Change Manager (Service Provider)Service ProviderChange Assignment Group/Change Assignee2.6.4 OTL Change SME (ABB)This role is part of current ADONIS process. OTL Change SME is the one responsible to technically review and assess the change before it goes to production environment.Major responsibilities include: Reviewing functional specifications created by BTL Change Manager Reviewing change before change deployment from technical point of view Updating transport numbers, if required Setting Post Rollout Documentation requirement, if necessary Making sure required documentation is in placeProcess RoleOrganizational RoleServiceNow FieldOTL Change SME (ABB)Subject Matter ExpertChange Task Assignment Group/Change Task Assigned To2.6.5 BTL Deployment Manager (Service Provider)This role is part of current ADONIS process. BTL Deployment Manager performs the day-to-day management of the deployment activities.Major responsibilities include: Defining implementation approach for deployment activities Confirming that deployments are carried out on schedule Implementing authorized Changes to the production environment Carrying out the deployment plan to its completion Attempting to resolve any issues arising during the deployment Executing the Change remediation procedures, in case of a failure during one of the implementation procedures Updating manuals and operating instructions when applicable Raising updates to CMDB for CI status changes Verifying the Configuration Information is updated as appropriateProcess RoleOrganizational RoleServiceNow FieldBTL Deployment Manager (Service Provider)Service ProviderChange Task Assignment Group/ Change Task Assignee2.6.6 CI OwnerThis role is part of current ADONIS process. Service Owner is responsible for individual Business Service.Major responsibilities include: Being the owner of Business Service in SNOW Evaluating and approving changes during Pre-Approval, Functional Approval and for SOX related changesProcess RoleOrganizational RoleServiceNow FieldCI OwnerSystem/Application OwnerService Owner based on Business Service2.6.7 SD&A ApproverThis role is not part of current ADONIS process. In case where changes are processed which impact ABB IS RUN customers, the SD&A function shall be involved in the approval process before the change is deployed into production. This approach ensures consistent decision making processes and allows for a pro-active communication towards the ABB IS RUN customers.Major responsibilities include: Evaluating and approving changes (emergency, major & minor with Critical/High risk) before change deployment Manages Client Relationship and Business interface Acts as a Single Point of Contact for communication to and from Business stakeholdersProcess RoleOrganizational RoleServiceNow FieldSD&A ApproverSD&A ManagersApprover Group member2.6.8 Technical Service Owner (ABB)This role is not part of current ADONIS process. Technical Service Owner holds the responsibility for managing the Tower Control.Major responsibilities include: Being accountable for Tower Control changes Approving Changes during CABECAB meetingProcess RoleOrganizational RoleServiceNow FieldTechnical Service Owner (ABB)Tower Control LeadChange Task Assignment Group/ Change Task Assignee2.6.9 Change Process Manager (ABB)This role is not part of current ADONIS process. Change Process Manager holds operational responsibility for managing the whole process.Major responsibilities include: Suggesting improvements to Change Management process Reporting on the Key Performance Indicators (KPIs) to evaluate the effectiveness and efficiency of the process Ensuring all relevant staff have the required training on the process and are aware of their role in the processProcess RoleOrganizational RoleServiceNow FieldChange Process Manager (ABB)SSIChange Task Assignment Group/ Change Task Assignee2.6.10 RACI MatrixDetailed RACI is described Process Policy Document Change Management.2.7 Principles and PoliciesAll Principles and Policies have been described in Process Policy Document Change Management. Most important ones have been described in below sections.2.8 Change TypesClassification of changes into different types is required for an efficient and effective Change Management process primarily because of the following reasons: All changes are not equal and need to be treated differently Differentiation between changes that have different levels of risk has to be made and Change Management process needs to achieve a balance between “change lifecycle times” and “controls for risk mitigation”. This can be achieved by having different workflows for each class of change Simple and Standard changes should be easy to implement and should not go through multiple levels of approvals Changes with different levels of risk to the controlled environment have different pre-deployment requirements for risk control and mitigationThe following change types have been defined:Change typeChange CategoryRequest for Change (RFC)RFC Major ChangeRequest for Change (RFC)RFC Minor Change Request for Change (RFC)RFC Minor Operational ChangeStandard ChangeStandard ChangeEmergency ChangeEmergency ChangeEmergency ChangeExpedited Change Incident-initiated ChangeIncident-initiated Change MajorIncident-initiated ChangeIncident-initiated Change MinorTable 2 Change TypesNOTE: The differentiation between categorizing a Change Type as minor or major occurs through the completion of a structured Change Evaluation and Assessment.The Emergency Change type is further categorized as Emergency Change or Expedited Change. The differentiation is based on the definitions in the Emergency Change Categorization Policy.Change Type/TowerCSPEUCHostingNetworkStandardDelete a Shared mailbox.There are no standard changes implemented in Service Catalogue as of yet. These could be:- Software packaging- Addition of Network Printer in the officeThere are no standard changes implemented in Service Catalogue as of yet.There are no standard changes implemented in Service Catalogue as of yet.MinorOU creation on every Country sub-OU.Software distribution in one country or region by Wipro with ABB involved in its specification.Add new VM capacity (RAM, Drive, storage).Cisco Prime installation.Minor (Operational)Add a new DNS record.Software distribution in one country or region by Wipro without ABB involved in specification.Additional full backup done of the Server on AO request.Skybox amendment.MajorNew GPO deployed globally.Printing outage in whole country.Worldwide deployment of a software that significantly affects user.Desktops and is integrating with other systems.Core Network switch upgrade in DC (requiring device downtime).WAN/LAN takeover/cutover.EmergencyDisable a non-announced (by MS) new feature from O365 (i.e. Sway).Critical security patch distribution.Hotfix for O365 client software following recent update.VM Disc extension to 1 TB due to no free space on SQL instance.Router exchange due to failure.Router reboot.Change of configuration.Table 3 Change Types examples2.8.1 Standard ChangeA pre-approved change which has the following characteristics: Frequently performed and implementation for such a change that is simple and routine Known and low risk but may include downtime Proven implementation record has been processed at least 5 times Uses a fixed execution plan or is fully automated Execution during standard maintenance windows unless otherwise agreed Standard Change must be approved by CAB as routine in order to be included in the standard changes catalogue 2.8.2 RFC Minor ChangeA Minor change usually has the following characteristics: Do not add any new bigger elements or functionality to the existing services Should have no or very low impact to the users or business functionality Is predictable and has a proven track recordNOTE: The categorization of a Minor or Major Change in ABB depends on a structured Change Evaluation and Assessment.2.8.3 RFC Minor Operational ChangeA Minor change can be marked as Operational Change which has the following characteristics: Typically no requirements engineering therefore no functional specification & review phase Do not require ABBs involvement during requirements gathering Daily operational changes to keep infrastructure running (not business originated) Mostly requested by Service Suppliers and ABB SMEs Requiring only review and acceptance by SME for technical aspects and timelineNOTE: The categorization of a Minor or Major Change in ABB depends on a structured Change Evaluation and Assessment.2.8.4 RFC Major ChangeA Major Change usually has any of the following characteristics: Has a high impact or risk to end-users or business functionality Different levels and types of testing are required for implementation Requires