【正文】 nge 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:167。 Implementing/developing fully authorized Change167。 Creating Functional and Technical Specifications167。 integration testing after Change implementation/development167。 Updating manuals and operating instructions when applicable167。 Verifying proper authorizations have been obtained and documented in the Change Record prior to scheduling the change167。 Backing out an unsuccessful Change, if required167。 Reviewing functional specifications created by BTL Change Manager167。 Updating transport numbers, if required167。 Making sure required documentation is in placeProcess RoleOrganizational RoleServiceNow FieldOTL Change SME (ABB)Subject Matter ExpertChange Task Assignment Group/Change Task Assigned To BTL Deployment Manager (Service Provider)This role is part of current ADONIS process. BTL Deployment Manager performs the daytoday management of the deployment activities.Major responsibilities include:167。 Confirming that deployments are carried out on schedule167。 Carrying out the deployment plan to its pletion167。 Executing the Change remediation procedures, in case of a failure during one of the implementation procedures167。 Raising updates to CMDB for CI status changes167。 Being the owner of Business Service in SNOW167。A ApproverThis role is not part of current ADONIS process. In case where changes are processed which impact ABB IS RUN customers, the SDamp。 Evaluating and approving changes (emergency, major amp。 Manages Client Relationship and Business interface 167。A ApproverSDamp。 Being accountable for Tower Control changes167。 Suggesting improvements to Change Management process167。 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 Assignee RACI MatrixDetailed RACI is described Process Policy Document – Change Management. Principles and PoliciesAll Principles and Policies have been described in Process Policy Document – Change Management. Most important ones have been described in below sections. Change TypesClassification of changes into different types is required for an efficient and effective Change Management process primarily because of the following reasons: 167。 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 change167。 Changes with different levels of risk to the controlled environment have different predeployment 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 Incidentinitiated ChangeIncidentinitiated Change – MajorIncidentinitiated ChangeIncidentinitiated Change – MinorTable 2 Change TypesNOTE: The differentiation between categorizing a Change Type as minor or major occurs through the pletion 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/TowerCSPEUCHostingNetworkStandardCisco Prime installation.Minor (Operational)Additional full backup done of the Server on AO request.Core Network switch upgrade in DC (requiring device downtime).Disable a nonannounced (by MS) new feature from O365 (. Sway).Critical security patch distribution.Hotfix for O365 client software following recent update. Frequently performed and implementation for such a change that is simple and routine167。 Proven implementation record – has been processed at least 5 times167。 Execution during standard maintenance windows unless otherwise agreed167。 Do not add any new bigger elements or functionality to the existing services167。 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. RFC Minor Operational ChangeA Minor change can be marked as Operational Change which has the following characteristics: 167。 review phase 167。 Daily operational changes to keep infrastructure running (not business originated) 167。 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. RFC Major ChangeA Major Change usually has any of the following characteristics:167。 Different levels and types of testing are required for implementation167。 The change is less predictable or has high risk167。 It is required to resolve an Incident and can only be raised from a preceding Incident ticket167。 Result from Severity 1 Incidents and/or Problems167。 Changes are unplanned and are to have a short lead time to restore IT Services, whilst following the workflow based approval process167。 Will be subject to a deployment approval by an Emergency Change Advisory Board (ECAB) in advance of deployment, rather than a standard single tower or E2E Change Advisory Board (CAB)NOTE: Emergency Change is subject to categorization of a Minor or Major Change based on structured Change Evaluation and Assessment.More information can be