公司业务变更的管理流程

1、1 / 50业务变更治理流程版本记录0.12007-0120XX初稿1.02007-0321XXX流程修改，增加代码描述，形成提交稿1. 文档介绍 11.1. 文档简介 11.2. 文档用途 12. 变更治理流程简介 32.1. 变更治理流程描述 32.2. 目的 42.3. 范围 52.4. 要紧内容 62.5. 业务价值 93. 变更治理的人员角色和职责 113.1. 变 更经理 113.2. 变更顾问委员会（ CAB/EC） 133.3. 变 更主管 143.4. 变 更实施人员 153.5. 某 客户人员角色定义 164. 变更治理流程讲明 174.1. 变 更治理总体流程 174.2

2、. 变 更治理流程和其他治理流程的关系 194.3. 变 更治理详细流程 204.3.1. （350）紧急变更逻辑流程204.3.2. （300.1 ）提交变更请求224.3.3. （300.2 ）同意变更请求234.3.4. （ 300.3 ）评估风险 / 阻碍244.3.5. （ 300.4 ）测试 /实施打算4.3.6. （300.5 ）打算 &沟通264.3.7. （300.6 ）变更实施274.3.8. （300.7 ）回忆284.3.9. （300.8 ）结束2944 SD相关代码定义 304.4.1 请求者优先级不304.4.2 阻碍度304.4.3 风险314.4.4.

3、 状 态324.4.5. 变 更工单实施状态334.4.6. 结束代码334.4.7. 类 不( Category )334.4.8. 类型( Type)345. 变更治理流程操纵 375.1. 变更治理流程政策 / 建议 375.1.1. 政策5.1.2. 建 议395.2. 治 理报表 395.3. 工 作报表 406. 附件 . 411.文档介绍1.1. 文档简介本文档是某客户变更流程设计讲明及分析报告，是中国某公司和某客户信息科技部安全运行处（以下简称某客户）一起制定的变更治理的流程讲明文档，通过制定该流程，能够关心所有实施IT变更的人员有一套规范的分步流程去更新或升级生产环境中的IT

4、系统。从而保证由于变更而引起的对IT环境的阻碍降到最小，提高IT系统和服务的质量，为业务的快速进展提供更优质的IT服务，同时能够有效地实施其他相关ITSM治理流程，如配置治理。本文档描述的是依据目前某客户的IT服务状况而制定的变更治理流程讲明，以后进一步的更新和优化将由某客户负责。文档用途来自.1.2.本文档一方面作为本次ITSM项目的变更治理流程讲明的交付物，也可为进一步设计变更治理流程的蓝本，读者对象为与变更治 理流程相关的所有技术和治理人员。本文档所描述的流程在IT服务治理中有许多作用，它提供一个统一的一致的生产系统的实施和变更流程以确保：a）所有需要的递交物已完成；b) 所有的系统已测

5、试；c) 已完成完全的实施打算。变更治理流程确保在打软件补丁，实施事件解决方案或引入新 系统时有能够遵循的流程。它详细描述在某客户的 IT 环境中如何 实施一个变更，如，上线一个新系统。 并包括定义在变更流程中 涉及的文档资料。2.变更治理流程简介2.1. 变更治理流程描述变更治理理想来看应该是一个单一的职能流程来操纵和治理整 个IT运行环境中的一切变更，并和配置治理建立接口。变更治理 应该由治理工具来支持，治理的范围可包括软件，硬件，通讯设备 和文档等的变更。变更经理应该对整个变更流程负责，但这并不意味着自己要做 每件情况，而是要确保有人在做应该做的情况。ITIL建议成立一个变更顾问委员会

6、(CAB)来关心和支持变更经 理，CAB的成员依照变更的实质能够包括客户代表，运维支持，应 用开发和供应商等跟变更有关的人员。CAB通过开会等手段来考虑和评估变更请求(RFC)的：?潜在风险和阻碍；?实施变更需要的资源；?是否批准变更；?假如批准，什么时刻实施。本公司建议：初期 CAB-个季度对已实施的变更回忆一次，正 常运行后某客户再依照运行情况确定周期；针对具体某一项变更回 忆的报告结果能够用附件的方式附加在该变更单上进行保存；CAB也负责变更实施后的回忆以确保：? 变更是否成功？? 是否产生其他副作用？? 实际所用的资源和预期的是否一致，假如不是，调整评估流程。批准后，变更将进入打算，测

7、试 / 构建和实施时期。 打算 / 构 建时期也包括开发一个恢复打算 (Fallback Plan) ，用以在实施时 期出现问题或紧急状况时需要把变更回退回去。变更治理流程也负 责紧急变更，在此种情况下，变更的评估，打算，测试和实施时期 都将快速进行。来自2.2. 目的某客户 IT 变更治理流程将通过标准统一的方法和步骤治理和 操纵所有对 IT 生产环境有阻碍的变更，要紧的目的包括：? IT 部门能够治理和引导用户变更需求；? 通过对所有变更的正确评估，能够维护 IT 环境的完整性；? 变更和变更实施得到正确记录，并提供审核统计；? 减少或消除由于变更实施预备不当等缘故出现的对 IT 环境 的

8、破坏作用；? 提供了一致性的变更实施质量操纵；? 提高资源使用率（如，未得到正确操纵和授权的变更需要 更多的后续资源）；? 确保实施的变更可不能超出预定的系统利用限值；? 确 保紧急 变更请求 得到快速实 施（ 由 紧急变 更委员会 （CAB/EC ）负责）。2.3. 范围变更治理流程涵盖生产环境及 CMD中CI的所有变更，包括：? 服务器；? 业务系统 （ 新系统上线，生产系统的变动 ） ；? 客户端；? 网络设备；? 存储设备；? 机房环境；? 在ServiceDesk中的CMDB数据项及其和 CI之间的配置关系；不包括：? 尚处于开发时期的 IT 元素的变更；? 不需要某客户 IT 部门

9、介入，同时不阻碍 IT 运维的由用户操纵的行为动作；2.4. 要紧内容某客户 IT 变更治理流程将包括如下内容：? 同意RFC变更请求）所有变更请求，都需递交到变更经理，供评估和批准。 评估变更分类、变更级不等，确定与变更相关的CAB 人员，变更经理对常规变更进行实施；? 变更请求分类和登录通过分类，确定该 RFC 的批准人和领导执行人，并确定 是否是紧急变更，紧急变更适用同一流程但将得到快速批 准和实施。提交RFC到变更顾问委员会（CAB进行评估，确定阻碍度 变更经理将依照特定的变更请求成立特定的CAB成员包括对该变更的评估和批准提供应有附加价值的技术人员和治 理人员。评估工作包括技术可行性

10、，对容量的阻碍，对现 有服务的阻碍，资源需求等。批准 RFC变更经理确定对该RFC有批准权的经理参加 CAB必要时参与评估。评估后该经理依照推断决定是否批准RFC。? 检查变更打算测试结果，并批准实施变更经理确定合适人员主管该变更并参与CAB， 称为变更主管。变更请求得到评估和批准后，变更主管安排相应资源进行变更的构建开发，然后需要对将要实施到生产环境的变更进行测试，并制定实施打算，随后提交测试结果和打算给变更经理以获得实施。变更经理必需要确保测试结果和打算都有文档记录和得到签署，并确认变更对生产环境没有阻碍或阻碍能够得到操纵。这一步骤为变更流程 的关键质量检查点。? 规划 RFCRFC旦获得

11、批准，它必须依照资源和其他情况进行规划， 确定实施日期，分配相应资源，并通知请求人。? 协调变更实施 Coordinating the change implementation一切就绪后，能够实施变更。建议某客户计算机中心的运 维组实施相应变更，变更经理监视实施过程，并在必要时 进行协调。? 更新变更状态在整个变更过程中，变更的状态从登记，评估，回忆到最 后关闭是不同的。变更经理负责更新预先定义好的变更状 态。? 回忆和关闭实施变更后，变更经理负责从技术和流程角度去回忆变 更，该回忆在预先定义好的时刻段针对变更单独进行，除 确保RFC得到了预期效果外，也查找流程的改进机会，如 资源打算和实际

12、使用的一致性。确定是否满足了变更目 的，有没有副面阻碍，否则需制定后续行动打算。随后， 变更经理负责利用预先定义好的结束状态关闭RFC。? 总结汇报向治理层提供流程报表，向客户提供变更的相关执行信 息。定期向相关小组部门依照流程衡量标准汇报专门重要，只有如此，才能够基于现有环境的最新信息，作出进 一步的改进建议。? 变更会议变更经理负责定期或不定期召开变更会议，以在 IT 内部以 及与客户就变更治理有一个好的沟通。在会上，能够传递 女口，最近变更规划（FSC），将要实施变更的信息，也 包括对变更流程的反馈和建议等。? 变更流程回忆建议定期回忆变更治理流程以提高效率和效能，在实施变 更流程不久之

13、后，能够进行第一次回忆，以确保流程得到 正确实施并起到预期目的，发觉的问题必须追根溯源并尽 快解决。之后，能够定期进行正式的回忆如每三个 月。2.5. 业务价值本流程将有助于实现某客户提高 IT 系统可用性的运维目标：? 确保所有变更的实施都可不能对业务产生负面阻碍；? 确保所有变更的处理和实施都遵循规范的变更流程；? 确保所有变更及实施都得到完整记录；? 快速响应变更请求 RFC；确保变更得到跟踪直至解决；? 确保和所有相关人员 / 部门能就变更状态有良好沟通；? 变更请求能有从业务 / 客户角度定义的阻碍度；? 变更的处理机遇所定的阻碍度分析； 变更治理流程要紧的好处在于：? 提高 IT

14、环境的稳定性；? 面对客户需求和技术的快速变化，变更的治理和操纵将使对生产环境的变更实施可能带来的风险最小化。? 降低运行成本；来自.良好的变更记录有助于运维流程的持续性改进，并加快变更相关问题的解决。3.变更治理的人员角色和职责在变更治理流程中，ITSM对角色建议有4个，变更经理，变更 顾问委员会(CAB，变更主管和变更实施人员。在标准ITIL标准流程中采纳 CAB环节一般作为参考条件，然 而考虑到某客户目前专门多运维和变更工作需要各个组协同执行， 因此推举成立CAB 各角色述职如下：3.1.变更经理依照ITSM最佳实践，结合某客户的实际情况，建议变更经理 和配置经理的角色是一个人，如此能够使变更治理和配置治理结合 得更加紧密，同时能够保障配置治理CMDB的准确性。另外，还能够使相关流程更加简捷，确保 ITSM治理流程的可推广性。变更经理职责：?同意变更请求(RFC)，并做初步筛选；?确保变更请求(RFC)得到评估，授权,操纵和打算；?确保所有相关人员都尽可能地引入到变更请求的评估中；?确保治理层得到足够关于变更的数量，阻碍度的信息；?成立变更委员会，并领导变更委员会 (CAB)和主持相关会议；? 确保变更在符合组织风险和需求的情况下，并