变更管理流程设计说明书.doc

资源描述

文档编号：变更管理流程设计说明书。目录目录 3 1 流程目的 7 2 流程主要内容 7 3 与其他流程的关系 8 4 关键角色、职责定义 8 4.1 变更请求者 8 4.2 变更主管 9 4.3 变更经理 9 4.4 变更委员会变更委员会（CAB）、紧急变更委员会E变更委员会（CAB） 10 4.5 变更实施人员 11 4.6 变更管理流程负责人 11 5 执行原则 12 5.1 常规原则 12 5.2 流程关联原则 12 5.3 变更实施记录原则 13 5.4 变更分类执行原则 13 5.5 审批上报原则 13 5.6 所有权原则 13 5.7 变更通知原则 13 5.8 紧急变更处理原则 13 5.9 变更测试原则 14 5.10 变更文档控制原则 14 6 流程相关定义 14 6.1 变更信息项 14 6.2 变更来源 19 6.3 变更类型 19 6.4 变更是否中断业务 20 6.5 变更是否需要测试 20 6.6 风险等级 20 6.7 变更所属系统类型 21 6.8 变更分类 23 6.9 是否启动总公司审批或备案 24 6.10 变更状态 24 6.11 回顾代码 27 6.12 变更结束代码 27 6.13 变更实施单信息项 28 7 流程概要设计 28 7.1 紧急变更子流程 31 8 流程详细设计 32 8.1 （400.1）变更发起 32 8.2 （400.2）直管领导进行需求审批 33 8.3 （400.3）检查、测试和计划 34 8.4 （400.4）评估审批 36 8.5 （400.5）变更委员会（CAB）评估审批 37 8.6 （400.6）总公司审批 38 8.7 （400.7）收集审批意见 39 8.8 （400.8）安排和分派任务 40 8.9 （400.9）实施变更任务 41 8.10 （400.10）回顾变更 42 8.11 （400.11）关闭变更 43 9 关键衡量指标 44 1 综述 1.1 设计目的本文档是在《CF保险股份有限公司信息技术管理制度V1.1》基础上，结合CF保险股份有限公司信息技术部维护管理的特点，制定的变更管理流程详细设计文档。本文档的目的是： q 规范所有IT变更，从而保证由于变更而引起的对生产的影响降到最小，提高IT系统和服务的质量，为业务的快速发展提供更优质的IT服务 q 指导与IT变更的相关人员有一套规范的流程去执行变更 q 指导IT管理平台项目的建设本文档是依据目前CF保险股份有限公司的信息技术日常运维状况而制定的，以后进一步的更新和优化将由CF保险股份有限公司信息技术部负责。 1.2 适用范围本文档作为本次项目的变更管理流程详细设计的交付物，读者对象为与变更管理流程相关的所有技术与管理人员。 1.3 相关术语 q ITIL（基础架构库 IT Infrastructure Library ）是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。 q 服务台（HelpDesk）服务台从根本上来说是提供了用户和IT部门的唯一接口。此项功能常通过集中方式提供服务。服务台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到二线支持等手段帮助用户恢复到正常工作状态。 q 事件管理（ Incident Management） ITIL流程之一，事件管理负责解决所有的IT事件、问题和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。 q 问题管理（Problem Management） ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。同时问题管理流程也负责预防事件的发生。 q 配置管理（Configuration Management） ITIL 流程之一，配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI) 。每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。 q 配置管理数据库（CMDB - Configuration Management Database）是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。 q 变更管理（Change Management） ITIL流程之一，变更管理通过控制和管理IT相关的变更，使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。 2 变更管理流程设计 2.1 流程目的变更管理流程将通过标准统一的方法和步骤来管理和控制所有对IT生产环境有影响的变更。主要的目的包括： q IT部门可以管理和引导用户变更需求 q 通过对所有变更的正确评估，可以维护IT生产环境的完整性 q 变更和变更实施得到正确记录，并提供审核统计 q 减少或消除由于变更实施准备不当等原因出现的对IT环境的破坏作用 q 提高资源使用率 2.2 流程主要内容变更管理流程始于变更的接收，结束于变更的实施和回顾。该流程包含下述主要内容： q 提出变更请求（RFC）、评估、分类变更申请人提出变更请求（RFC），由变更主管负责检查和完善其内容，通过查询配置管理数据库，进行风险等级的初步评估；并尽量提出可能与业务发生的关联的影响，已供决策参考。变更主管并对变更进行分类；如为紧急变更，则按照紧急变更子流程执行；如为简单变更，直接制定变更计划，并安排实施。 q 变更主管负责组织制定变更计划、测试变更主管安排并协调相应资源制定变更计划，包括实施计划、测试计划、回退计划、配置项更新计划等。应安排对实施计划和回退计划进行测试，随后将测试结果、实施计划、回退计划、配置项更新计划等提交给变更经理审核。 q 变更经理评估、审批变更经理接受变更请求（RFC），如果确定是紧急变更，则快速完成评估、审批。对标准变更，确定变更风险等级，审阅变更实施计划、测试报告、回退计划和配置项更新计划，批准或驳回变更申请，如需要更高级别管理层的审批，则根据不同风险级别报批。 q 变更委员会（CAB）/紧急变更委员会（EC）评估、审批变更经理将根据特定的变更请求成立特定的变更委员会（CAB）/EC，成员包括对该变更的评估和批准提供应有附加价值的技术人员和管理人员，审阅工作包括变更的风险、对现有服务的影响、实施计划、回退计划和配置项更新计划等，并做出批准与否的决定。如为紧急变更，则快速完成以上评估、审批。 q 管理层审批对于风险等级为“重大”的变更，在变更委员会审批通过后，必须再由变更经理报请至管理层审批。 q 协调变更实施变更主管负责协调资源，准备实施前相关工作，组织人员按计划实施变更，变更主管监控实施过程和结果，并在必要时进行协调或做出决定。在这阶段可能需要变更经理和变更委员会成员的帮助。 q 回顾和关闭实施变更后，变更主管确保配置项及时得到更新，并协同变更经理负责从技术、管理、业务角度去回顾变更，确保变更请求（RFC）得到了预期效果，并寻找改进机会或行动计划，在回顾过程中可能会需要得到变更委员会中相关领域的技术人员的帮助，随后更新变更记录并关闭变更请求（RFC）。 2.3 与其他流程的关系变更管理流程可以从其他的服务管理流程接收到变更请求(RFC)。 q 和配置管理流程的关系变更管理涉及到的配置改变应当在配置管理数据库中得到体现，改变的数据可能包括配置项、配置项间的关系或配置项的某些属性；变更的评估需要从配置管理数据库中获取相关的信息进行分析。 q 和事件管理流程的关系事件的解决涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变更管理流程来实现，变更成功实施后应当通知事件管理流程。 q 和问题管理流程的关系问题管理流程中对于错误的修正涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变更管理流程，变更成功实施后应当通知问题管理流程。 2.4 关键角色、职责定义流程的实现是通过不同的流程角色以及其所赋有的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责。变更管理流程的角色为：变更请求者、变更主管、变更经理、变更实施人员、变更委员会CAB/紧急变更委员会EC、变更管理流程负责人。以下描述每个角色的职责。 2.4.1 变更请求者根据工作的需要，发起变更请求的IT人员，主要负责： q 必要时提出变更申请，创建变更请求（RFC），并提交给相关技术领域的变更主管 q 在变更处理过程中提供必要的信息技能要求： q 了解对于所处业务需求与环境 q 了解所处的IT生产环境与组织结构 q 了解IT技术架构从而可以向变更主管、变更经理诠释所提及变更对于运行的影响人员安排说明： q 所有IT维护人员 2.4.2 变更主管变更主管通常由与变更请求内容相关的具体技术领域的负责人担任。可以根据不同的变更种类，分派不同的人员作为变更主管。对于某些重要变更，还可以将变更主管和变更实施人员合并在一起；变更主管主要关注在实施方案、详细实施计划等方面。职责： q 检查由变更申请人提交的每一个变更请求变更请求（RFC），检查变更的正确性和必要性，必要时拒绝无关、无法实施或没有必要的变更请求 q 确定和检查变更请求（RFC）的分类、变更时间要求、分析风险等 q 作为具体变更的项目经理，负责领导变更的构建／测试，实施和参与回顾 q 制定变更实施计划、测试计划、回退计划等 q 针对具体变更请求，评估并分派相应资源 q 确保变更在预定的时间，资源和成本内完成 q 在必要时，确保回退计划（Fallback Plan）得以正确实施 q 负责收集与该变更有关的部门或小组的意见，综合变更对于应用的影响技能要求： q 充分了解IT生产环境的结构 q 了解公司组织结构和业务与客户之间的关系 q 较强的技术背景，项目管理技能 q 分析能力 q 以用户为导向、良好的沟通能力人员安排说明： q 通常由负责具体技术领域的人担任，如负责8版系统的人、分公司负责某一分公司系统的人、负责网络方面的人等 2.4.3 变更经理变更经理全面负责变更管理流程中的所有具体活动执行，保障所有变更依照预定流程顺利执行。通常由具有决策权的人员担任。职责： q 帮助变更主管协调必要的变更时间、人员等方面的协调工作 q 审批变更请求，确保只有授权和必要的变更才被实行，并使该种变更影响最小化 q 成立变更委员会，并领导和主持变更委员会(变更委员会) q 定期召开变更会议，回顾变更 q 参与流程评估，对流程改进提出意见和建议，与流程负责人共同制定流程改进建议技能要求： q 在信息技术部门的足够级别 (鉴于变更经理的工作职责包括主持变更委员会（CAB）会议、与管理层交互、驳回不合理变更请求以及对于变更流程的运行进行指导等，所以变更经理必须在组织内部拥有足够的权威且受到尊重) q 决策力和判断力 q 深入了解企业文化 q 项目管理技能 q 有效的会议管理、部门管理和组织能力 q 充分了解IT生产环境、组织结构以及 IT服务对业务与客户的影响 q 以用户为导向、良好的沟通能力 q 社交能力和良好的信用，能够与变更流程相关的角色进行有效地交涉和交流人员安排说明： q 通常由负责决策权的人担任，一般为部门相关领导 2.4.4 变更委员会CAB、紧急变更委员会ECAB（总公司）变更委员会( Change Advisory Board ， CAB)是IT组织中对变更进行评估和决策、批准或者拒绝某个变更请求的虚拟组织。职责： q 针对具体变更请求，评估潜在影响和风险，并分派相应资源 q 协助变更经理对变更做出审批、决策 q 参加变更委员会会议和紧急变更委员会会议 q 回顾失败或重大的变更，以确保今后不再发生类似情形 q 回顾已执行的重大变更，确保满足变更的目的 q 对流程改进提出意见和建议技能要求： q 足够的权威 q 充分了解生产环境结构IT组织结构 q 充分了解公司组织架构和业务与客户的关系 q 技术背景和洞察力 q 分析能力 q 以用户为导向、良好的沟通能力 q 社交能力和良好的信用，能够与变更流程相关的角色进行有效的交涉和交流 q 业务需求的了解人员安排说明： q 变更委员会是由总部信息技术中心的管理人员组成的虚拟小组。主要由各相关领域的领导、各个IT维护小组的资深人员或者组长组成，有时也会包括发起变更请求的业务部门的代表、第三方厂商集成商等参与。变更委员会应当由该专业有较高技能的人员组成，同时，这些成员对于业务需求、业务逻辑、IT系统技术、应用开发、测试、支持等方面也较为熟悉。注：紧急变更委员会通常可以属于变更委员会的一个子集，担当紧急变更委员会（ECAB）的职责。分公司没有变更委员会，只有总公司有。 2.4.5 变更实施人员变更实施人员负责变更在生产环境中的实施，实际情况下现场厂商经常参与变更实施过程，其责任包括： q 协助变更主管制定变更实施方案、变更实施计划 q 记录变更实施相关的信息，确保文档的完整性 q 负责实施和测试 q 变更完成后，进行监控，并记录监控结果 q 与变更主管沟通，通报变更实施的进度和结果技能要求： q 充分了解生产环境的IT架构，是某一领域的技术专家 q 充分了解公司的组织架构和业务与客户的关系 q 较强的学习、沟通、协调能力 q 分析能力人员安排说明： q 由IT部门人员担任，及运维厂商人员 2.4.6 变更管理流程负责人流程负责人通过从宏观上监控流程，来确保变更流程被正确地执行。当流程不能够适应公司的情况时，流程负责人必须及时对此进行分析、找出缺陷、进行改进，从而实现可持续提高。职责： q 确保变更流程能够取得管理层的参与和支持 q 确保变更流程符合公司实际状况和公司 IT发展战略 q 总体上管理和监控流程，建立变更流程实施、评估和持续优化机制 q 确保变更流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时对此进行分析、找出缺陷、进行改进(比如增加或合并流程的角色)，从而实现可持续提高流程效率 q 保持与其他流程负责人的定期沟通技能要求： q 深刻理解变更管理流程 q 能够很好地理解业务对于变更管理的需求 q 对质量控制与保障有很深入的了解 q 有决策权，能够确保变更管理流程设计要求在变更执行中得到贯彻和执行 q 具有良好的沟通技能，能够取得公司高层的支持，获得所需资源人员安排说明： q 通常由总公司负责决策权的人担任，一般为部门相关领导 2.4.7 实际岗位与方案角色的映射变更管理流程角色角色细分说明成员变更请求者总公司职责：负责受理与总公司应用系统、基础设施等相关的各种变更请求，并发起变更岗位说明：由总公司信息技术部技术人员担任，包括总公司服务台人员分公司职责：负责受理与分公司自有应用系统、基础设施等相关的各种变更请求，并发起变更岗位说明：各分公司IT部门技术人员担任，包括分公司服务台人员，对应岗位包括分公司信息技术部各技术岗位变更主管总公司基础设施组职责：负责总公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的维护变更工作岗位说明：由总公司信息技术部门各基础设施领域维护工作的资深技术人员或相关处室处长、副处担任应用系统组职责：负责总公司自有应用系统维护支持工作岗位说明：由总公司负责各类应用系统维护变更工作的资深技术人员或相关处室处长、副处担任桌面组职责：负责总公司桌面维护变更工作岗位说明：由总公司代理服务处、服务支持处资深技术人员或相关处室处长、副处担任开发组职责：负责总公司应用系统开发、修改、优化工作岗位说明：由总公司开发类处室资深开发人员或开发类处室处长、副处担任分公司应用系统组职责：负责分公司自有应用系统维护变更工作岗位说明：由分公司负责各类应用系统维护变更工作的资深技术人员或分管领导担任，对应岗位包括应用管理岗、地市分公司应用管理岗、数据管理岗基础设施组职责：负责分公司基础设施（包括小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件）的维护变更工作岗位说明：由分公司信息技术部门各基础设施领域维护工作的资深技术人员或分管领导担任，对应岗位包括设备管理岗、系统管理岗、安全岗、网络管理岗、运行维护岗、地市分公司设备管理岗桌面组职责：负责分公司桌面维护变更工作岗位说明：由分公司负责桌面维护工作的资深技术人员或分管领导担任，对应岗位包括服务支持管理岗开发组职责：负责分公司自有应用系统的开发、修改、优化工作岗位说明：由分公司资深开发人员或分管领导担任，对应岗位包括应用开发岗变更实施人总公司职责：负责对总公司应用系统、基础设施、桌面等方面的变更实施工作岗位说明：由总公司IT部门技术人员及代维厂商组成分公司职责：负责对分公司自有应用系统、基础设施、桌面等方面的变更实施工作岗位说明：由分公司IT部门人员及代维厂商组成变更经理总公司职责：负责督导与监控总公司变更流程的正常运转，对标准变更进行审批和对重大变更进行上报等岗位说明：在总公司设置变更经理1人，由运行管理处处长、副处担任分公司职责：负责督导与监控分公司变更流程的正常运转，对标准变更进行审批和对重大变更进行上报等岗位说明：在分公司设置变更经理1人，由分管基础设施方面的信息技术部副总经理担任变更管理流程负责人职责：负责确定管理流程的衡量指标，从宏观上监控流程，当流程不能够适应CF发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高岗位说明：在总公司设置变更管理流程负责人1名说明：变更主管分组可进行扩充，各分公司可将现有分组提交到总公司，由总公司统一协调配置 2.5 执行原则 2.5.1 常规原则 q 所有影响生产环境配置项的变更都必须严格遵循变更管理流程 q 所有的变更请求记录都应被记录和追踪 q 所有变更实施过程都应记录在IT服务管理平台 q 应每月产生变更管理报表，对失败的变更和风险等级重大的变更进行回顾和检查，以更好地管理变更流程 q 应半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进变更管理流程 2.5.2 流程关联原则 q 和配置管理的关联 Ø 在制定变更计划时通过查询配置管理数据库，评估变更可能影响的系统，制定变更计划时需制定配置项更新计划，变更实施完成后需确保配置项信息及时更新，只有配置项更新完成后，才能关闭变更请求单 Ø 配置项信息的变更需要通过变更管理流程控制 q 和事件管理的关联 Ø 解决事件的过程中涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变更管理流程，如果变更管理流程是由事件管理流程触发，则事件记录必须与变更记录相关联 q 和问题管理的关联 Ø 解决问题的过程中涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变更管理流程，如果变更管理流程是由问题管理流程触发，则问题记录必须与变更记录相关联 2.5.3 变更实施记录原则 q 所有变更实施过程都必须记录在IT服务管理平台，以体现出变更实施中的主要执行环节和执行情况，比如各关键步骤的起始时间、结束时间、执行人、执行结果、异常情况等。具体记录方式可采用在该变更请求单上增加填写信息项，或新增任务单等其他方式，记录的信息项参见变更实施单信息项定义 2.5.4 变更分类执行原则 q 简单变更采用预授权的方式，由变更主管直接安排实施，并通告变更经理 q 标准变更由变更经理总体负责，通过与各相关方面协同，采取多种方式（例如CAB会议），严格管理其计划、测试、评估、审批、实施 q 紧急变更提供变更快速实施处理的机制 2.5.5 审批上报原则 q 风险等级为重大的变更必须提前三个工作日提交总公司审批，变更实施结束以后将变更执行结果上报至总公司备案 q 省分公司提出的风险等级为高的变更必须提前上报总公司备案 q 变更委员会负责审批风险等级为高和重大的变更；对于风险等级重大的变更，变更委员会会议建议部门领导参加，对于风险等级高的变更，变更委员会会议建议维护主管参加 q 变更经理负责审批风险等级为中和低的变更 2.5.6 所有权原则 q 变更主管负责审核变更请求的有效性和正确性，制定相应的变更计划，并处理各种变更执行时的日程安排和协调，必要时可以得到变更经理的帮助 q 变更经理负责关闭紧急变更，变更主管负责关闭其他变更 q 对于不在变更经理审批权限内的变更，由变更经理负责提交至变更委员会审批 q 对风险等级为重大的变更，在变更委员会审批完成后，由变更经理负责提交至总公司审批 2.5.7 变更通知原则 q 对现有业务系统产生影响的变更，例如因实施变更而需要停机或者中止业务，均需在变更执行前提前通知有关人员做好业务调整，减少对业务的影响，待实施完成后再次通告 2.5.8 紧急变更处理原则 q 紧急变更必须通过E-MAIL等书面方式申请，但可以口头获得紧急变更委员会（EC）审批，事后必须在IT服务管理平台补变更申请单及相关测试和审批文档，其中变更申请单信息项中必须填写变更实施记录、变更测试记录和变更观察记录，这三项内容即为紧急变更操作日志 q 紧急变更应该制定变更计划，并快速审批和进行必要的评估，实施前需进行必要的测试，测试需包含完整的测试案例，只有测试成功后方可在生产环境进行变更。对由于紧急变更而无法完成的测试应在实施后安排补测 q 紧急变更委员会（EC）成员一般为公司领导、部门领导，各级主管等管理层人员，为了提高执行效率，需要事先制定紧急变更委员会（EC) 的人员 q 紧急变更应越少越好，因为它们对业务的干扰最大，而且有很高的失败风险 2.5.9 变更测试原则 q 对生产系统进行变更时，需根据变更的性质、影响面等情况在变更请求单中选择是否需要在测试环境进行测试。如果需要，则按照测试计划进行测试，测试后需有相关测试人员确认并提供测试报告 2.5.10 变更文档控制原则 q 变更计划通常包括实施计划、测试计划、回退计划、配置项更新计划等 q 对应用软件版本上线类的变更，除变更计划外，还需包括变更功能说明文档、变更技术说明文档、包含完整测试用例的测试文档，并提供由执行测试人员确认的测试报告 q 对数据迁移类的变更，除变更计划外，还需包括转换方案，该方案一般包含数据转换策略、数据转换测试、数据备份及恢复方案、数据转换结果核对等方面的内容 q 对总公司要求上报审批的变更，提交的文档具体内容说明如下: Ø 变更总体方案（包括变更原因、变更前后系统拓扑、配置或功能对比、变更总体计划、具体方案、进度安排、人员分工、测试标准、风险评估等） Ø 测试报告（提供系统在变更前的测试范围、测试步骤、测试项目、测试情况等） Ø 变更回退/应急方案 2.6 流程相关定义 2.6.1 变更信息项变更单必须包含如下变更信息项：序号信息项是否必填说明变更发起时填写－变更发起人 1 实际请求人信息是记录实际变更请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写） 2 关联的事件单号否如果变更来源是事件，则关联到相应的事件单（手工填写） 3 关联的问题单号否如果变更来源是问题，则关联到相应的问题单（由变更请求者手工填写） 4 变更来源是参见“变更来源”定义 5 变更简要描述是简单描述变更请求（手工填写） 6 变更描述是详细描述变更的内容（手工填写） 7 变更所属系统类型是参见“变更所属系统类型”定义 8 变更分类是参见“变更分类”定义 9 变更需求单位是两级目录树（省、地市；成员公司、养老金公司） 10 关联配置项否记录出现故障的配置项代码（手工填写） 11 附件否上传附件 12 分配对象是将问题分配到各组变更主管（手工填写）变更发起时，系统自动填写 13 变更ID 是为每个变更请求分配一个唯一的序列号（系统自动产生） 14 建单人（受理人）是变更请求的记录人 15 登记时间是变更请求创建的时间（系统自动产生） 16 变更状态是参见“变更状态”定义检查、测试和计划阶段填写－变更主管 17 风险等级是参见“风险等级”定义 18 变更类型是参见“变更类型”定义 19 所影响的应用系统、部门否实施该变更将对哪些应用、部门产生影响，用于评估变更（手工填写） 20 变更是否中断业务是参见“ 变更是否中断业务“定义 21 变更是否需要测试是参见“变更是否需要测试“定义 22 需通知部门否需要通知的部门名称（手工填写） 23 变更计划否使用附件形式。变更计划通常包括变更的实施计划、测试计划、回退计划、配置项更新计划等（手工填写） 24 计划开始时间是变更计划开始时间 YYYY-MM-DD HH:MM（手工填写） 25 计划完成时间是变更计划完成时间YYYY-MM-DD HH:MM（手工填写） 26 中断关键业务1名称否描述该变更所中断的关键业务系统1的名称，填写内容参见“变更所属系统类型”中的子类定义，如“营销管理”。（手工填写） 27 关键业务1中断时长否描述该变更所中断的关键业务系统1的时长，按分钟计算。（手工填写） 28 中断关键业务2名称否描述该变更所中断的关键业务系统2的名称，填写内容参见“变更所属系统类型”中的子类定义，如“营销管理”。（手工填写） 29 关键业务2中断时长否描述该变更所中断的关键业务系统2的时长，按分钟计算。（手工填写） 30 中断关键业务3名称否描述该变更所中断的关键业务系统3的名称，填写内容参见“变更所属系统类型”中的子类定义，如“营销管理”。（手工填写） 31 关键业务3中断时长否描述该变更所中断的关键业务系统3的时长，按分钟计算。（手工填写） 32 中断关键业务否描述该变更所中断的所有关键业务系统名称。（手工填写） 33 关键业务中断总时长否描述该变更中断的所有关键业务系统的时长，按分钟计算。（手工填写） 34 变更测试记录是描述测试的情况、测试结果（手工填写）同9 关联配置项否记录出现故障的配置项代码（手工填写）同10 附件否上传附件 35 变更主管是变更主管姓名（系统填写） 36 变更实施单位是两级树形目录 37 变更主管接受变更时间是变更主管接受变更请求的时间（条件触发自动填写） 38 是否启动总公司审批或备案否参见“ 是否启动总公司审批或备案“定义（分公司特有）需求审批阶段填写－变更经理 39 变更审批记录是记录变更审批的历史记录，包括如下信息：审批人姓名、审批结果、原因、时间等（手工填写）同11 分配对象是将变更分配到各组变更主管（手工填写）审批阶段填写－变更委员会同16 变更审批记录是记录变更审批的历史记录，包括如下信息：审批人姓名、审批结果、原因、时间等（手工填写）实施阶段填写－变更实施人 40 派发变更任务否派发变更任务给变更实施人员 41 变更实施记录是用于描述实施时的现场情况（手工填写） 42 实际开始时间是变更实际开始时间YYYY-MM-DD HH:MM（手工填写） 43 实际完成时间是变更实际完成时间YYYY-MM-DD HH:MM（手工填写）回顾阶段填写－变更主管 44 变更观察记录否描述变更结束后，观察期间的情况（手工填写） 45 回顾意见否变更委员会对变更进行回顾后得出的意见（手工填写） 46 回顾代码否参见“回顾代码”定义（手工填写）关闭时填写－变更主管 47 变更结束代码是参见“变更结束代码”定义 48 关闭人是关闭人的姓名（系统填写） 49 关闭时间是变更关闭的时间，关闭人手工填写。YYYY-MM-DD HH:MM 其他 50 备注否留用 2.6.2 变更来源变更来源用于区分触发变更的其他流程或需求，以便进行有效地关联。编号代码描述 1 事件变更来源于事件 2 问题变更来源于问题 3 配置变更来源于配置项信息的调整 4 其他变更来源于其他方面，如项目建设等 5 业务部门 2.6.3 变更类型变更类型用于区分变更，提高变更处理的效率。编号代码描述 1 简单变更指频繁发生、影响范围较小、紧急程度较低、实施风险较小（不会带来重大后果）、实施较简单的变更，如库表大小的改动，crontab时间的修改，文件的删除等。 2 标准变更指涉及影响范围较大（影响客户、业务部门、分公司或者社会影响较大）、实施风险较大、实施较复杂的变更。这些变更可以进行充分的计划和测试。如业务割接、机房搬迁、软件升级等。（需求审批；上线审批） 3 紧急变更指如果不进行变更，会立即或正在严重影响业务运行、导致严重影响服务等级或者带来重大影响的变更，应当得到尽可能快速的处理，减少流程的复杂性，但是又要有良好的控制。如紧急事件引发的紧急变更。 2.6.4 变更是否中断业务变更可能会引起业务中断，需要在变更评估时加以说明。编号代码描述 1 是变更会引起业务中断 2 否变更不会引起业务中断 2.6.5 变更是否需要测试变更实施前需进行必要的测试。编号代码描述 1 是变更需要测试 2 否变更不需要测试 2.6.6 风险等级除简单变更外，变更主管、变更经理、变更委员会/紧急变更委员会对标准变更和紧急变更根据下表所列的衡量因素来量化评估实施变更可能带来的风险，该评估结果用于决定是否批准变更，是否需要更高级别的审批，以及实施完成后的观察期。该评估由变更主管进行初步评定，再由变更经理或变更委员会进行最终确定。风险等级量化评估表如下：衡量因素条件得分地区IT用户数量（受到实施或取消的影响）影响一个以上关键省或半数以上省 1 影响一个以上省但未达到半数,并没有关键省受影响 2 影响一个省的全部用户 3 影响一个省的部分用户 4 准备/实施必需的资源 3个或更多支持小组 1 2个支持小组 2 超过1人，相同的支持小组 3 1人 4 变更成功的可能性无法测试，变更失败可能性很高 1 能实现部分测试，变更失败可能性较高 2 有成熟的变更方案，变更失败可能低 3 无需测试，变更失败可能性没有 4 变更规划时间 6天或更长 1 2-6 天 2 1-2天 3 小于1天 4 变更实施时间超过2小时或在线/服务断供期 1 1-2小时 2 不到1小时 3 不到30分钟 4 回退时间回退时间超过2小时 1 回退难度中等以上（1-2小时） 2 回退难度适中（1小时或更短） 3 易于回退（30分钟或更短） 4 根据上表对每个变更进行评估，最终得出风险等级。风险分为四个等级：重大、高、中、低。不同的风险等级分别有对应的审批级别和实施完成后的观察期，具体定义如下表：总得分对应风险等级对应审批级别实施完后的观察周期 6 – 9 重大变更委员会、总公司 5-7天 10 – 13 高变更委员会 4-5天 14 – 17 中变更经理 2-3天 18 + 低变更经理 1 天 2.6.7 变更所属系统类型定义变更所属的业务系统。业务系统分类子业务系统分类简称办公管理 IT服务管理系统 ITSM 综合办公系统　电子邮件系统请填写简称电子商务网上招聘系统 CORS 管理决策团体年金报表子系统 GARS 财务计算机管理系统 CLAF 集团财务计算机管理系统 GCLAF CF财务报表辅助系统 EASY-REPORT 大中城市业绩考核分析系统 CSIS 财务分析系统 LIFA 基础率分析系统 EAS 精算系统 ATMS 每日业务快报系统 ZHCX 统计信息系统 TJXX 审计系统 AMS 核心运营综合业务处理系统7版 CBPS7 集团综合业务处理系统7版 NBPS 老业务处理系统 OBPS 综合业务处理系统8版 CBPS8 出单管理系统(七版) Printpro 档案影像管理系统 CIMS 单证管理系统 CVMS 打印管理系统 CPMS 数据清理系统 CLEANER 投连万能处理系统 UBPS 团体年金核心业务处理系统 GAPS 中介业务处理系统 ABPS 统括业务处理系统 UNITE 再保险系统 RBPS 健康意外险系统 HDPS 互联网销售系统 ISS 销售客服团体年金大客户支持子系统 GACS 团体年金报价子系统 GAPS 团体年金销售支持系统 GA3S 个人代理人管理信息系统 AMIS 讲师管理系统 TMIS 会员管理系统2005 MMIS 个人代理人营销支持系统 E-MSS 大客户支持系统 anntsuport 网络查询系统 netquery CF呼叫中心系统 CALL CENTER CF短信系统 SMS 其他非业务系统类 OTS 说明：第一层为”其它”的话，分公司可以对其子类可以扩充并提交到总公司，由总公司统一协调配置 2.6.8 变更分类一级分类二级分类三级分类服务器SR 小型机（EPS）　 PC 服务器（SPC）　存储设备 RD 磁盘阵列（RAD）　磁带库（TAP）　其他存储设备（OTR）　网络NW 交换机（SWT）网络交换机（SWT）光纤交换机（FST）路由器（RUT）　防火墙（FRW）　 VPN网关（VPG）　安全网关（SEG）　链路（LNK）　其他网络设备（OTN）　终端TR 台式机（COM）笔记本（NTB）字符终端（CTR）图形终端（GTR）外设及其他PR 外设（DDV）打印机（PRT）扫描仪（SCN）绘图仪（DRW）其他（SSO）机房（DCE）监控系统（）消防系统其他（OTR）　软件SW

展开阅读全文