【正文】 Organization, Availability, Integrity – will be rated against a scale 1 – 5 but points will be doubled, earning a score of up to ten points for each, depending on selectionCategoryOrganization (Impact)Cost (Likelihood)Availability (Likelihood)Integrity (Impact)Complexity (Likelihood)Infrastructure (Likelihood)QuestionWhich target group is affected by the change request?What are the expected estimated costs for this change?What is the expected downtime of the affected service?To what extend does the change has impact to critical functionality?What is the plexity of the change?What is planned implementation path for this change?Risk Rate\Weight for Change TypesX2x1X2X2X1X1Risk Rate\Weight for Impact amp。A ManagerCAB GroupRequester/ OTL Change CoordinatorTable 4 Approvals39。 All SNOW mandatory information (fields) related to Change must be plete167。 ProdWhere a full implementation path through the Development and QA environments is selected to get to production, additional development, testing, transport and approval tasks are required – likely to be used for application changes and more plex infrastructure changes. Where a reduced implementation path straight to the production environment is selected, fewer tasks are required – likely to be used for the majority of infrastructure changes.NOTE: Implementation path is usually set on Business Service level. However, it can be also selected or updated manually. Change Creation167。 ProductionThere are four implementation paths available for changes depending on the technical environments involved in the change which can be selected while processing the change. The implementation path for a change, selected when the change is initially logged, influences the workflow required to process the change in the service management tool. The following implementation paths are available for Minor/Major Changes: 167。 Single Tower Emergency Changes: Tower will execute the process and retain responsibility for the end to end management of the change, which includes authorization for build and for production deployment. SSI would be actively involved in Major Incident resolution and as such will provide a munication platform acting as ECAB and authorizing change deployment to production for Major Incidents. For all other Single Tower emergency changes, SSI may be engaged by tower in case of escalation or arbitration is required. SSI will always be engaged for PIR process step. Cross Tower Changes: Occur when significant involvement from more than one Tower is required to effect the change. 167。 Changes are unplanned and are to have a short lead time to restore IT Services, whilst following the workflow based approval process167。 It is required to resolve an Incident and can only be raised from a preceding Incident ticket167。 Different levels and types of testing are required for implementation167。 Daily operational changes to keep infrastructure running (not business originated) 167。 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。 Execution during standard maintenance windows unless otherwise agreed167。 Frequently performed and implementation for such a change that is simple and routine167。Core Network switch upgrade in DC (requiring device downtime).Cisco Prime installation.Minor (Operational) 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。 Suggesting improvements to Change Management process167。A ApproverSDamp。 Evaluating and approving changes (emergency, major amp。 Being the owner of Business Service in SNOW167。 Executing the Change remediation procedures, in case of a failure during one of the implementation procedures167。 Confirming that deployments are carried out on schedule167。 Updating transport numbers, if required167。 Backing out an unsuccessful Change, if required167。 Updating manuals and operating instructions when applicable167。 Creating Functional and Technical Specifications167。 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 To 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:167。 Assisting Change Requester with test implementation when required167。 Verifying the supporting documentation acpanying the Change Record is plete167。 Working with the OTL Change Coordinator to resolve any data inconsistencies with the request Service Requests167。 CI Verification167。 Approvals, Risk Assessment and control of change required to be implemented for incident resolution.Problem Management167。 Minutes 51 Deployment Verification Plan 51 Post Implementation Review 51 Weekly CAB meetings 517. Vocabulary 528. External References 53 Process Policy Document – Change Management 53 Change Management workflows in SNOW 53 Change Management – Stakeholders list 531. Introduction 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 amp。ABB IS Service amp。 responsibilities and many other practicalities that will help understand and run Change Management process from operational p