保险公司IT变更管理流程设计说明书.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 保险股份有限公司信 息技术部维护管理的特点，制定的变更管理流程详细设计文档。本文档的目的是： 规范所有 it 变更，从而保证由于变更而引起的对生产的影响降到最小，提高 it 系统和服务的质 量，为业务的快速发展提供更优质的 it 服务 指导与 it 变更的相关人员有一套规范的流程去执行变更 指导 it 管理平台项目的建设 本文档是依据目前 cf 保险股份有限公司的信息技术日常运维状况而制定的，以后进一步的更新和优 化将由 cf 保险股份有限公司信息技术部负责。 1.2 适用范适用范围围 本文档作为本次项目的变更管理流程详细设计的交付物，读者对象为与变更管理流程相关的所有技 术与管理人员。 1.3 相关相关术语术语 itil（基础架构库 it infrastructure library ） 是英国政府在 1987 年制定的有关 it 服务管理的方法论，现已成为事实上的 it 管理标准。 服务台（helpdesk） 服务台从根本上来说是提供了用户和 it 部门的唯一接口。此项功能常通过集中方式提供服务。服务 台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到二线支持等手段帮助用户恢复到正 常工作状态。 事件管理（ incident management） itil 流程之一，事件管理负责解决所有的 it 事件、问题和用户请求。它的目的是尽快恢复被中断或 受到影响的 it 服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。 问题管理（problem management） itil 流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件 的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。同时问题管理流程也负责预防事件 的发生。 配置管理（configuration management） itil 流程之一，配置管理负责描述，跟踪和汇报所有 it 基础架构中的每一个设备或系统的管理流程。 这些设备和系统被称为配置项(ci) 。每一个 ci 必须有效管理，跟踪和控制以支持公司的 it 服务和基础 设施成功运行。 配置管理数据库（cmdb - configuration management database） 是在配置管理流程中用于记录企业所有 it 相关配置项信息及其相互关系而建立的数据库。 变更管理（change management） itil 流程之一，变更管理通过控制和管理 it 相关的变更， 使变更对生产环境可能的影响和风险降到 最小，从而提高 it 环境的整体稳定性。 2变更管理流程设计变更管理流程设计 2.1 流程目的流程目的 变更管理流程将通过标准统一的方法和步骤来管理和控制所有对 it 生产环境有影响的变更。主要的 目的包括： it 部门可以管理和引导用户变更需求部门可以管理和引导用户变更需求 通过对所有变更的正确评估，可以维护通过对所有变更的正确评估，可以维护 it 生产环境的完整性生产环境的完整性 变更和变更实施得到正确记录，并提供审核统计变更和变更实施得到正确记录，并提供审核统计 减少或消除由于变更实施准备不当等原因出现的对减少或消除由于变更实施准备不当等原因出现的对 it 环境的破坏作用环境的破坏作用 提高资源使用率提高资源使用率 2.2 流程主要内容流程主要内容 变更管理流程始于变更的接收，结束于变更的实施和回顾。该流程包含下述主要内容： 提出变更请求（提出变更请求（rfc） 、评估、分类、评估、分类 变更申请人提出变更请求（rfc） ，由变更主管负责检查和完善其内容，通过查询配置管理数据 库，进行风险等级的初步评估；并尽量提出可能与业务发生的关联的影响，已供决策参考。变更主 管并对变更进行分类；如为紧急变更，则按照紧急变更子流程执行；如为简单变更，直接制定变更 计划，并安排实施。 变更主管负责组织制定变更计划、测试变更主管负责组织制定变更计划、测试 变更主管安排并协调相应资源制定变更计划，包括实施计划、测试计划、回退计划、配置项更 新计划等。应安排对实施计划和回退计划进行测试，随后将测试结果、实施计划、回退计划、配置 项更新计划等提交给变更经理审核。 变更经理评估、审批变更经理评估、审批 变更经理接受变更请求（rfc） ，如果确定是紧急变更，则快速完成评估、审批。对标准变更， 确定变更风险等级，审阅变更实施计划、测试报告、回退计划和配置项更新计划，批准或驳回变更 申请，如需要更高级别管理层的审批，则根据不同风险级别报批。 变更委员会（变更委员会（cab）/紧急变更委员会（紧急变更委员会（ec）评估、审批）评估、审批 变更经理将根据特定的变更请求成立特定的变更委员会（cab）/ec，成员包括对该变更的评估 和批准提供应有附加价值的技术人员和管理人员，审阅工作包括变更的风险、对现有服务的影响、 实施计划、回退计划和配置项更新计划等，并做出批准与否的决定。如为紧急变更，则快速完成以 上评估、审批。 管理层审批管理层审批 对于风险等级为“重大”的变更，在变更委员会审批通过后，必须再由变更经理报请至管理层 审批。 协调变更实施协调变更实施 变更主管负责协调资源，准备实施前相关工作，组织人员按计划实施变更，变更主管监控实施 过程和结果，并在必要时进行协调或做出决定 。在这阶段可能需要变更经理和变更委员会成员的 帮助。 回顾和关闭回顾和关闭 实施变更后，变更主管确保配置项及时得到更新，并协同变更经理负责从技术、管理、业务角 度去回顾变更，确保变更请求（rfc）得到了预期效果，并寻找改进机会或行动计划，在回顾过程 中可能会需要得到变更委员会中相关领域的技术人员的帮助，随后更新变更记录并关闭变更请求 （rfc） 。 2.3 与其他流程的关系与其他流程的关系 变更管理流程可以从其他的服务管理流程接收到变更请求(rfc)。 和配置管理流程的关系和配置管理流程的关系 变更管理涉及到的配置改变应当在配置管理数据库中得到体现，改变的数据可能包括配置项、 配置项间的关系或配置项的某些属性 ； 变更的评估需要从配置管理数据库中获取相关的信息进行分析。 和事件管理流程的关系和事件管理流程的关系 事件的解决涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变更管理流程 来实现，变更成功实施后应当通知事件管理流程。 和问题管理流程的关系和问题管理流程的关系 问题管理流程中对于错误的修正涉及到需要对基础架构、应用系统及操作系统等进行变更的需 要触发变更管理流程，变更成功实施后应当通知问题管理流程。 2.4 关关键键角色、角色、职责职责定定义义 流程的实现是通过不同的流程角色以及其所赋有的职责来实现的，因此流程的每一个角色可以被定 义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予 多个职责。 变更管理流程的角色为：变更请求者、变更主管、变更经理、变更实施人员、变更委员会 cab/紧急 变更委员会 ec、变更管理流程负责人。以下描述每个角色的职责。 2.4.1 变更请求者变更请求者 根据工作的需要，发起变更请求的 it 人员，主要负责： 必要时提出变更申请，创建变更请求（rfc） ，并提交给相关技术领域的变更主管 在变更处理过程中提供必要的信息 技能要求：技能要求： 了解对于所处业务需求与环境 了解所处的 it 生产环境与组织结构 了解 it 技术架构从而可以向变更主管、变更经理诠释所提及变更对于运行的影响 人员安排说明：人员安排说明： 所有 it 维护人员 2.4.2 变更主管变更主管 变更主管通常由与变更请求内容相关的具体技术领域的负责人担任。可以根据不同的变更种类，分 派不同的人员作为变更主管。对于某些重要变更，还可以将变更主管和变更实施人员合并在一起；变更 主管主要关注在实施方案、详细实施计划等方面。 职责：职责： 检查由变更申请人提交的每一个变更请求变更请求（rfc） ，检查变更的正确性和必要性，必要 时拒绝无关、无法实施或没有必要的变更请求 确定和检查变更请求（rfc）的分类、变更时间要求、分析风险等 作为具体变更的项目经理，负责领导变更的构建测试，实施和参与回顾 制定变更实施计划、测试计划、回退计划等 针对具体变更请求，评估并分派相应资源 确保变更在预定的时间，资源和成本内完成 在必要时，确保回退计划（fallback plan）得以正确实施 负责收集与该变更有关的部门或小组的意见，综合变更对于应用的影响 技能要求：技能要求： 充分了解 it 生产环境的结构 了解公司组织结构和业务与客户之间的关系 较强的技术背景，项目管理技能 分析能力 以用户为导向、良好的沟通能力 人员安排说明：人员安排说明： 通常由负责具体技术领域的人担任，如负责 8 版系统的人、分公司负责某一分公司系统的人、 负责网络方面的人等 2.4.3 变更经理变更经理 变更经理全面负责变更管理流程中的所有具体活动执行，保障所有变更依照预定流程顺利执行。通 常由具有决策权的人员担任。 职责：职责： 帮助变更主管协调必要的变更时间、人员等方面的协调工作 审批变更请求，确保只有授权和必要的变更才被实行，并使该种变更影响最小化 成立变更委员会，并领导和主持变更委员会(变更委员会) 定期召开变更会议，回顾变更 参与流程评估，对流程改进提出意见和建议，与流程负责人共同制定流程改进建议 技能要求：技能要求： 在信息技术部门的足够级别 (鉴于变更经理的工作职责包括主持变更委员会（cab）会议、与 管理层交互、驳回不合理变更请求以及对于变更流程的运行进行指导等，所以变更经理必须在 组织内部拥有足够的权威且受到尊重) 决策力和判断力 深入了解企业文化 项目管理技能 有效的会议管理、部门管理和组织能力 充分了解 it 生产环境、组织结构以及 it 服务对业务与客户的影响 以用户为导向、良好的沟通能力 社交能力和良好的信用，能够与变更流程相关的角色进行有效地交涉和交流 人员安排说明：人员安排说明： 通常由负责决策权的人担任，一般为部门相关领导 2.4.4 变更委员会变更委员会 cab、紧急变更委员会、紧急变更委员会 ecab（总公司）（总公司） 变更委员会( change advisory board ， cab)是 it 组织中对变更进行评估和决策、批准或者拒绝某 个变更请求的虚拟组织。 职责：职责： 针对具体变更请求，评估潜在影响和风险，并分派相应资源 协助变更经理对变更做出审批、决策 参加变更委员会会议和紧急变更委员会会议 回顾失败或重大的变更，以确保今后不再发生类似情形 回顾已执行的重大变更，确保满足变更的目的 对流程改进提出意见和建议 技能要求：技能要求： 足够的权威 充分了解生产环境结构 it 组织结构 充分了解公司组织架构和业务与客户的关系 技术背景和洞察力 分析能力 以用户为导向、良好的沟通能力 社交能力和良好的信用，能够与变更流程相关的角色进行有效的交涉和交流 业务需求的了解 人员安排说明：人员安排说明： 变更委员会是由总部信息技术中心的管理人员组成的虚拟小组。主要由各相关领域的领导、各 个 it 维护小组的资深人员或者组长组成，有时也会包括发起变更请求的业务部门的代表、第三 方厂商集成商等参与。变更委员会应当由该专业有较高技能的人员组成，同时，这些成员对于 业务需求、业务逻辑、it 系统技术、应用开发、测试、支持等方面也较为熟悉。 注：紧急变更委员会通常可以属于变更委员会的一个子集，担当紧急变更委员会（ecab）的职责。分公司没 有变更委员会，只有总公司有。 2.4.5 变更实施人员变更实施人员 变更实施人员负责变更在生产环境中的实施，实际情况下现场厂商经常参与变更实施过程，其责任 包括： 协助变更主管制定变更实施方案、变更实施计划 记录变更实施相关的信息，确保文档的完整性 负责实施和测试 变更完成后，进行监控，并记录监控结果 与变更主管沟通，通报变更实施的进度和结果 技能要求：技能要求： 充分了解生产环境的 it 架构，是某一领域的技术专家 充分了解公司的组织架构和业务与客户的关系 较强的学习、沟通、协调能力 分析能力 人员安排说明：人员安排说明： 由 it 部门人员担任，及运维厂商人员 2.4.6 变更管理流程负责人变更管理流程负责人 流程负责人通过从宏观上监控流程，来确保变更流程被正确地执行。当流程不能够适应公司的情况 时，流程负责人必须及时对此进行分析、找出缺陷、进行改进，从而实现可持续提高。 职责：职责： 确保变更流程能够取得管理层的参与和支持 确保变更流程符合公司实际状况和公司 it 发展战略 总体上管理和监控流程，建立变更流程实施、评估和持续优化机制 确保变更流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时对此进行 分析、找出缺陷、进行改进(比如增加或合并流程的角色)，从而实现可持续提高流程效率 保持与其他流程负责人的定期沟通 技能要求：技能要求： 深刻理解变更管理流程 能够很好地理解业务对于变更管理的需求 对质量控制与保障有很深入的了解 有决策权，能够确保变更管理流程设计要求在变更执行中得到贯彻和执行 具有良好的沟通技能，能够取得公司高层的支持，获得所需资源 人员安排说明：人员安排说明： 通常由总公司负责决策权的人担任，一般为部门相关领导 2.4.7 实际岗位与方案角色的映射实际岗位与方案角色的映射 变更管理流程变更管理流程 角色角色角色细分角色细分说明说明成员成员 总公司 职责：负责受理与总公司应用系统、 基础设施等相关的各种变更请求，并 发起变更 岗位说明：由总公司信息技术部技术 人员担任，包括总公司服务台人员 变更请求者 分公司 职责：负责受理与分公司自有应用系 统、基础设施等相关的各种变更请求， 并发起变更 岗位说明：各分公司 it 部门技术人 员担任，包括分公司服务台人员，对 应岗位包括分公司信息技术部各技术 岗位 基础设施组 职责：负责总公司小型机、pc 服务器、 存储设备、网络交换机、路由器、防 火墙、网络链路等系统硬件及操作系 统、中间件、数据库等系统软件的维 护变更工作 岗位说明：由总公司信息技术部门各 基础设施领域维护工作的资深技术人 员或相关处室处长、副处担任 应用系统组 职责：负责总公司自有应用系统维护 支持工作 岗位说明：由总公司负责各类应用系 统维护变更工作的资深技术人员或相 关处室处长、副处担任 桌面组 职责：负责总公司桌面维护变更工作 岗位说明：由总公司代理服务处、服 务支持处资深技术人员或相关处室处 长、副处担任 变更主管总公司 开发组 职责：负责总公司应用系统开发、修 改、优化工作 岗位说明：由总公司开发类处室资深 开发人员或开发类处室处长、副处担 任 应用系统组 职责：负责分公司自有应用系统维护 变更工作 岗位说明：由分公司负责各类应用系 统维护变更工作的资深技术人员或分 管领导担任，对应岗位包括应用管理 岗、地市分公司应用管理岗、数据管 理岗 基础设施组 职责：负责分公司基础设施（包括小 型机、pc 服务器、存储设备、网络交 换机、路由器、防火墙、网络链路等 系统硬件及操作系统、中间件、数据 库等系统软件）的维护变更工作 岗位说明：由分公司信息技术部门各 基础设施领域维护工作的资深技术人 员或分管领导担任，对应岗位包括设 备管理岗、系统管理岗、安全岗、网 络管理岗、运行维护岗、地市分公司 设备管理岗 桌面组 职责：负责分公司桌面维护变更工作 岗位说明：由分公司负责桌面维护工 作的资深技术人员或分管领导担任， 对应岗位包括服务支持管理岗 分公司 开发组 职责：负责分公司自有应用系统的开 发、修改、优化工作 岗位说明：由分公司资深开发人员或 分管领导担任，对应岗位包括应用开 发岗 变更实施人总公司 职责：负责对总公司应用系统、基础 设施、桌面等方面的变更实施工作 岗位说明：由总公司 it 部门技术人 员及代维厂商组成 分公司 职责：负责对分公司自有应用系统、 基础设施、桌面等方面的变更实施工 作 岗位说明：由分公司 it 部门人员及 代维厂商组成 总公司 职责：负责督导与监控总公司变更流 程的正常运转，对标准变更进行审批 和对重大变更进行上报等 岗位说明：在总公司设置变更经理 1 人，由运行管理处处长、副处担任 变更经理 分公司 职责：负责督导与监控分公司变更流 程的正常运转，对标准变更进行审批 和对重大变更进行上报等 岗位说明：在分公司设置变更经理 1 人，由分管基础设施方面的信息技术 部副总经理担任 变更管理流 程负责人 职责：负责确定管理流程的衡量指标， 从宏观上监控流程，当流程不能够适 应 cf 发展需要时，流程负责人必须 及时的对此进行分析、找出缺陷、进 行改进，从而实现可持续提高 岗位说明：在总公司设置变更管理流 程负责人 1 名 说明：说明：变更主管分组可进行扩充，各分公司可将现有分组提交到总公司，由总公司统一协调配置 2.5 执执行原行原则则 2.5.1 常规原则常规原则 所有影响生产环境配置项的变更都必须严格遵循变更管理流程 所有的变更请求记录都应被记录和追踪 所有变更实施过程都应记录在 it 服务管理平台 应每月产生变更管理报表，对失败的变更和风险等级重大的变更进行回顾和检查，以更好地管 理变更流程 应半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有 效性，以改进变更管理流程 2.5.2 流程关联原则流程关联原则 和配置管理的关联 在制定变更计划时通过查询配置管理数据库，评估变更可能影响的系统，制定变更计划时 需制定配置项更新计划，变更实施完成后需确保配置项信息及时更新，只有配置项更新完 成后，才能关闭变更请求单 配置项信息的变更需要通过变更管理流程控制 和事件管理的关联 解决事件的过程中涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变 更管理流程，如果变更管理流程是由事件管理流程触发，则事件记录必须与变更记录相关 联 和问题管理的关联 解决问题的过程中涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变 更管理流程，如果变更管理流程是由问题管理流程触发，则问题记录必须与变更记录相关 联 2.5.3 变更实施记录原则变更实施记录原则 所有变更实施过程都必须记录在 it 服务管理平台，以体现出变更实施中的主要执行环节和执行 情况，比如各关键步骤的起始时间、结束时间、执行人、执行结果、异常情况等。具体记录方 式可采用在该变更请求单上增加填写信息项，或新增任务单等其他方式，记录的信息项参见变 更实施单信息项定义 2.5.4 变更分类执行原则变更分类执行原则 简单变更采用预授权的方式，由变更主管直接安排实施，并通告变更经理 标准变更由变更经理总体负责，通过与各相关方面协同，采取多种方式（例如 cab 会议） ，严 格管理其计划、测试、评估、审批、实施 紧急变更提供变更快速实施处理的机制 2.5.5 审批上报原则审批上报原则 风险等级为重大的变更必须提前三个工作日提交总公司审批，变更实施结束以后将变更执行结 果上报至总公司备案 省分公司提出的风险等级为高的变更必须提前上报总公司备案 变更委员会负责审批风险等级为高和重大的变更；对于风险等级重大的变更，变更委员会会议 建议部门领导参加，对于风险等级高的变更，变更委员会会议建议维护主管参加 变更经理负责审批风险等级为中和低的变更 2.5.6 所有权原则所有权原则 变更主管负责审核变更请求的有效性和正确性，制定相应的变更计划，并处理各种变更执行时 的日程安排和协调，必要时可以得到变更经理的帮助 变更经理负责关闭紧急变更，变更主管负责关闭其他变更 对于不在变更经理审批权限内的变更，由变更经理负责提交至变更委员会审批 对风险等级为重大的变更，在变更委员会审批完成后，由变更经理负责提交至总公司审批 2.5.7 变更通知原则变更通知原则 对现有业务系统产生影响的变更，例如因实施变更而需要停机或者中止业务，均需在变更执行 前提前通知有关人员做好业务调整，减少对业务的影响，待实施完成后再次通告 2.5.8 紧急变更处理原则紧急变更处理原则 紧急变更必须通过 e-mail 等书面方式申请，但可以口头获得紧急变更委员会（ec）审批，事 后必须在 it 服务管理平台补变更申请单及相关测试和审批文档，其中变更申请单信息项中必须 填写变更实施记录、变更测试记录和变更观察记录，这三项内容即为紧急变更操作日志 紧急变更应该制定变更计划，并快速审批和进行必要的评估，实施前需进行必要的测试，测试 需包含完整的测试案例，只有测试成功后方可在生产环境进行变更。对由于紧急变更而无法完 成的测试应在实施后安排补测 紧急变更委员会（ec）成员一般为公司领导、部门领导，各级主管等管理层人员，为了提高执 行效率，需要事先制定紧急变更委员会（ec) 的人员 紧急变更应越少越好，因为它们对业务的干扰最大，而且有很高的失败风险 2.5.9 变更测试原则变更测试原则 对生产系统进行变更时，需根据变更的性质、影响面等情况在变更请求单中选择是否需要在测 试环境进行测试。如果需要，则按照测试计划进行测试，测试后需有相关测试人员确认并提供 测试报告 2.5.10变更文档控制原则变更文档控制原则 变更计划通常包括实施计划、测试计划、回退计划、配置项更新计划等 对应用软件版本上线类的变更，除变更计划外，还需包括变更功能说明文档、变更技术说明文 档、包含完整测试用例的测试文档，并提供由执行测试人员确认的测试报告 对数据迁移类的变更，除变更计划外，还需包括转换方案，该方案一般包含数据转换策略、数 据转换测试、数据备份及恢复方案、数据转换结果核对等方面的内容 对总公司要求上报审批的变更，提交的文档具体内容说明如下: 变更总体方案（包括变更原因、变更前后系统拓扑、配置或功能对比、变更总体计划、具 体方案、进度安排、人员分工、测试标准、风险评估等） 测试报告（提供系统在变更前的测试范围、测试步骤、测试项目、测试情况等） 变更回退/应急方案 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 风险等级风险等级 除简单变更外，变更主管、变更经理、变更委员会/紧急变更委员会对标准变更和紧急变更根据下表 所列的衡量因素来量化评估实施变更可能带来的风险，该评估结果用于决定是否批准变更，是否需要更 高级别的审批，以及实施完成后的观察期。该评估由变更主管进行初步评定，再由变更经理或变更委员 会进行最终确定。 风险等级量化评估表如下： 衡量因素衡量因素条件条件得分得分 影响一个以上关键省或半数以上省1 影响一个以上省但未达到半数,并没有关键省受影响2 影响一个省的全部用户3 地区 it 用户数量（受到 实施或取消的影响） 影响一个省的部分用户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） 磁盘阵列（rad） 磁带库（tap） 存储设备 rd 其他存储设备（otr） 网络交换机（swt） 交换机（swt） 光纤交换机（fst） 路由器（rut） 防火墙（frw） vpn 网关（vpg） 安全网关（seg） 链路（lnk） 网络 nw 其他网络设备（otn） 台式机（com） 笔记本（ntb） 字符终端（ctr） 终端 tr 图形终端（gtr） 打印机（prt） 扫描仪（scn） 绘图仪（drw） 外设（ddv） 其他（sso） 监控系统（） 机房（dce） 消防系统 外设及其 他 pr 其他（otr） 自主开发（sdv） 外包开发（odv） 应用软件 app 商业软件（frd） 数据库（sdb） 操作系统（ops） 中间件（smd） 软件 sw 系统软件 sys 其他（syo） 管理文档（adc） 技术文档（tdc） 维护文档（odc） 工程文档（pdc） 产品购买合同（pus） 文档 dc 合同 crt 维护合同（man） 应用系统名称（api） 应用系统模块（apm） 应用系统 ap 其他应用（apo） 2.6.9 是否启动总公司审批或备案是否启动总公司审批或备案（分公司）（分公司） 对风险等级为重大的变更，变更经理需启动总公司审批 对风险等级为高的变更，变更经理需启动总公司备案 编号编号代码代码描述描述 1是需要总公司审批或备案 2否不需要总公司审批或备案 2.6.10变更状态变更状态 变更从提出到最后被关闭，会历经各个阶段。变更处于不同的处理阶段具有不同的状态，需要不同 的角色参与。以下是变更请求从提出、实施到结束的整个生命周期中的不同状态： 编号编号代码代码描述描述 1已登记变更请求已登记入系统，变更主管还未受理 2接收需求变更主管接收变更申请人的变更请求 3需求审批变更经理对变更请求（rfc）进行需求审批 4计划中 变更主管对变更进行规划，检验变更单的分类和信息是否正确， 提交必要的变更文档 5等待审批变更请求提交给变更经理或变更委员会、或总公司等待审批 6已批准变更单得到批准（或简单变更预先批准） 7处理中 变更主管在此状态下，进行任务的创建、分发，变更实施者实施 变更 8已完成变更实施完成，进入观察期 9关闭变更关闭，关闭变更时需指定关闭代码（成功，失败，已取消） 2.6.11回顾代码回顾代码 回顾代码用于描述变更计划和实施过程的质量，以便更好地改善未来的变更。 编号编号代码代码描述描述 1实施正常变更实施计划、操作没有问题 2计划不全变更实施计划有缺陷，不完善 3实施操作有误变更实施人员在实施过程中操作有误 4不可预料情况其他不可预料的意外情况，如系统突然无法启动 2.6.12变更结束代码变更结束代码 变更结束代码用来描述其完结时的不同状态。 编号编号代码代码描述描述 1成功变更成功完成 2失败变更不成功，执行了回退计划 3已取消变更因为各种原因被取消 2.6.13变更实施单信息项变更实施单信息项 序号序号信息项信息项描述描述 1实施单 id 为每个变更实施单分派一个唯一的序列号（系统自动产生） 2变更请求单号 该变更实施单所属的变更请求单号，来源于变更信息项（系统自动关联） 3标题 简单描述变更请求，来源于变更信息项 4实施内容 描述变更实施的内容（手工填写） 5关联的配置项 变更实施关联的配置项信息 6记录登记时间 变更实施单创建的时间（系统自动产生） 7实施单状态 该变更实施单的状态，由各省自行定义 8实施人员信息 姓名、手机、办公电话、邮件地址、联系方式、 地域、机构、部门 （手工填写） 9核查人信息 姓名、手机、办公电话、邮件地址、联系方式、 地域、机构、部门（手工填写） 10计划开始时间 该实施单的计划开始时间（手工填写） 11计划完成时间 该实施单的计划完成时间（手工填写） 12实际开始时间 该实施单的实际开始时间（手工填写） 13实际完成时间 该实施单的实际完成时间（手工填写） 14实施任务记录 实施任务的工作日志、系统日志（手工填写） 15核查结论实施任务的核查结论（手工填写） 2.7 流程概要设计流程概要设计 概要设计流程图 变变更更主主管管 变变更更主主管管 变变更更委委员员会会 变变更更委委员员会会 变变更更经经理理 变变更更经经理理 变变更更实实施施人人员员 变变更更实实施施人人员员 变变更更请请求求者者 变变更更请请求求者者 外外部部流流程程/用用户户 外外部部流流程程/用用户户 变更请求 变更请求提交人、 服务台人员 事事件件管管 理理流流程程 问问题题管管 理理流流程程 配配置置管管 理理流流程程 400.1 变更发起 各类处室、岗位 处长、副处 分公司部门副总 部门分管副总、处 室领导、总公司司 副总、技术资深人 各类处室、岗位 经验丰富人员 400.2 检查、测试、计划 401 紧紧急急变变更更子子流流程程 400.7 安排、分派任务 400.8 实施 变更任务 400.3 评估审批 400.4 cab评估审批 400.6 收集、综合 审批意见 400.9 回顾变更 400.10 关闭变更 简单变更 标准变更 批准或驳回 风险等级为 重大或高 批准或驳回 驳回批准 简单变更 紧急变更 非 简 单 变 更 简单变更 配配置置管管 理理流流程程 事事件件管管 理理流流程程 取消 400.5 总公司审批分公司 重大变更 分公司内风险等级为重大的变更 需提交总公司审批 批准或驳回 问问题题管管 理理流流程程 变更管理概要设计流程图如下： 序号序号步骤名称步骤名称责任人责任人说明说明 400.1 变更发起变更请求者 变更申请人根据来自维护自发或其他 it 人员、项目建设提出的、或 事件、问题、配置管理流程提出的需求，收集信息，跟相关部门或 用户确认 创建变更请求记录 初步为变更分配类型、风险等级等 保证变更信息项的完整性和正确性 400.2 检查、测试和 计划 变更主管 判断变更类型，对简单变更，制定变更计划，直接转 400.7 安排和分 派任务 对标准变更，提交本部门变更经理，进行需求审批 对紧急变更，确认后立刻提交给变更经理按照 401 紧急变更子流程处 理 查询配置管理数据库 初步评估变更的类型、风险等，必须提出可能会影响哪些业务系统 和部门，以供决策参考 对标准变更，协调资源，制定变更计划，包括实施计划、测试计划、 回退计划、配置项更新计划等 实施计划要求有详细的操作命令，并包括实施变更的具体时间、操 作执行人、核查人以及实施变更后观察期内的监控人员等 配置项更新计划包括配置项属性和关系的更新等 对变更进行必要的测试，即对实施计划以及回退计划进行测试，提 供测试报告，确保系统变更的正常进行及回退的有效性 变更主管将实施计划、测试报告、回退计划、配置项更新计划等提 交给变更经理审批 400.3 评估、审批变 更 变更经理 变更经理接受变更请求，评估和确定变更的类型、风险等级等 审阅所有提交的计划，包括实施计划、测试报告、回退计划、配置 项更新计划等 变更经理将风险等级为重大或高的变更报送变更委员会审批，变更 委员会的成员由变更经理确定 变更经理可以做出驳回或批准的意见 400.4 变更委员会 评 估、审批 变更委员会 变更委员会由各领域的专家、领导、用户或相关厂商组成，对变更 实施计划、测试报告、回退计划、配置项更新计划等审阅 变更委员会可以做出驳回或批准的意见 对于分公司的变更如果是重大变更，必须提前至少 3 个工作日报请总 公司审批，转 400.5 由变更经理提交至总公司审批 400.5总公司审批总公司 总公司可以做出驳回或批准的意见 400.6收集审批意见变更经理 变更经理收集审批意见，驳回或批准变更。对于驳回的变更请求， 可以建议变更主管取消变更或重新计划等 如果审批意见是批准，转 400.7 安排和分派任务，并将高风险等级变 更提交至总公司备案 否则，转 400.2 检查、测试和计划，可以取消或重新计划 400.7 安排和分派任 务 变更主管 变更主管负责日程安排和变更实施人员安