流程管理业务变更管理流程.docx
《流程管理业务变更管理流程.docx》由会员分享,可在线阅读,更多相关《流程管理业务变更管理流程.docx(31页珍藏版)》请在冰豆网上搜索。
![流程管理业务变更管理流程.docx](https://file1.bdocx.com/fileroot1/2023-2/6/67daf65d-9293-4089-abce-129cd4bf5114/67daf65d-9293-4089-abce-129cd4bf51141.gif)
流程管理业务变更管理流程
业务变更管理流程
版本记录
版本号
日期
修改人
描述
0.1
2007-01-20
XX
初稿
1.0
2007-03-21
XXX
流程修改,增加代码描述,形成提交稿
1.文档介绍
1.1.文档简介
本文档是某客户变更流程设计说明及分析报告,是中国某公司和某客户信息科技部安全运行处(以下简称某客户)一起制定的变更管理的流程说明文档,通过制定该流程,可以帮助所有实施IT变更的人员有一套规范的分步流程去更新或升级生产环境中的IT系统。
从而保证由于变更而引起的对IT环境的影响降到最小,提高IT系统和服务的质量,为业务的快速发展提供更优质的IT服务,并且可以有效地实施其他相关ITSM管理流程,如配置管理。
本文档描述的是依据目前某客户的IT服务状况而制定的变更管理流程说明,以后进一步的更新和优化将由某客户负责。
文档用途来自
本文档一方面作为本次ITSM项目的变更管理流程说明的交付物,也可为进一步设计变更管理流程的蓝本,读者对象为与变更管理流程相关的所有技术和管理人员。
本文档所描述的流程在IT服务管理中有许多作用,它提供一个统一的一致的生产系统的实施和变更流程以确保:
a)所有需要的递交物已完成;
b)所有的系统已测试;
c)已完成彻底的实施计划。
变更管理流程确保在打软件补丁,实施事件解决方案或引入新系统时有能够遵循的流程。
它详细描述在某客户的IT环境中如何实施一个变更,如,上线一个新系统。
并包括定义在变更流程中涉及的文档资料。
2.变更管理流程简介
2.1.变更管理流程描述
变更管理理想来看应该是一个单一的职能流程来控制和管理整个IT运行环境中的一切变更,并和配置管理建立接口。
变更管理应该由管理工具来支持,管理的范围可包括软件,硬件,通讯设备和文档等的变更。
变更经理应该对整个变更流程负责,但这并不意味着自己要做每件事情,而是要确保有人在做应该做的事情。
ITIL建议成立一个变更顾问委员会(CAB)来帮助和支持变更经理,CAB的成员根据变更的实质可以包括客户代表,运维支持,应用开发和供应商等跟变更有关的人员。
CAB通过开会等手段来考虑和评估变更请求(RFC)的:
Ø潜在风险和影响;
Ø实施变更需要的资源;
Ø是否批准变更;
Ø如果批准,什么时间实施。
本公司建议:
初期CAB-个季度对已实施的变更回顾一次,正常运行后某客户再根据运行情况确定周期;针对具体某一项变更回顾的报告结果可以用附件的方式附加在该变更单上进行保存;
CAB也负责变更实施后的回顾以确保:
Ø变更是否成功?
Ø是否产生其他副作用?
Ø实际所用的资源和预期的是否一致,如果不是,调整评估流程。
批准后,变更将进入计划,测试/构建和实施阶段。
计划/构建阶段也包括开发一个恢复计划(FallbackPlan),用以在实施阶段出现问题或紧急状况时需要把变更回退回去。
变更管理流程也负责紧急变更,在此种情况下,变更的评估,计划,测试和实施阶段都将快速进行。
来自
2.2.目的
某客户IT变更管理流程将通过标准统一的方法和步骤管理和控制所有对IT生产环境有影响的变更,主要的目的包括:
ØIT部门可以管理和引导用户变更需求;
Ø通过对所有变更的正确评估,可以维护IT环境的完整性;
Ø变更和变更实施得到正确记录,并提供审核统计;
Ø减少或消除由于变更实施准备不当等原因出现的对IT环境的破坏作用;
Ø提供了一致性的变更实施质量控制;
Ø提高资源使用率(如,未得到正确控制和授权的变更需要更多的后续资源);
Ø确保实施的变更不会超出预定的系统利用限值;
Ø确保紧急变更请求得到快速实施(由紧急变更委员会(CAB/EC)负责)。
2.3.范围
变更管理流程涵盖生产环境及CMDB中CI的所有变更,包括:
Ø服务器;
Ø业务系统(新系统上线,生产系统的变动);
Ø客户端;
Ø网络设备;
Ø存储设备;
Ø机房环境;
Ø在ServiceDesk中的CMDB数据项及其和CI之间的配置关系;
不包括:
Ø尚处于开发阶段的IT元素的变更;
Ø不需要某客户IT部门介入,并且不影响IT运维的由用户控制的行为动作;
2.4.主要内容
某客户IT变更管理流程将包括如下内容:
Ø接受RFC(变更请求)
●所有变更请求,都需递交到变更经理,供评估和批准。
●评估变更分类、变更级别等,确定与变更相关的CAB人员,变更经理对常规变更进行实施;
Ø变更请求分类和登录
通过分类,确定该RFC的批准人和领导/执行人,并确定是否是紧急变更,紧急变更适用同一流程但将得到快速批准和实施。
Ø提交RFC到变更顾问委员会(CAB)进行评估,确定影响度
变更经理将根据特定的变更请求成立特定的CAB,成员包括对该变更的评估和批准提供应有附加价值的技术人员和管理人员。
评估工作包括技术可行性,对容量的影响,对现有服务的影响,资源需求等。
Ø批准RFC
变更经理确定对该RFC有批准权的经理参加CAB,必要时参与评估。
评估后该经理根据判断决定是否批准RFC。
Ø检查变更计划/测试结果,并批准实施
变更经理确定合适人员主管该变更并参与CAB,称为变更主管。
变更请求得到评估和批准后,变更主管安排相应资源进行变更的构建/开发,然后需要对将要实施到生产环境的变更进行测试,并制定实施计划,随后提交测试结果和计划给变更经理以获得实施。
变更经理必需要确保测试结果和计划都有文档记录和得到签署,并确认变更对生产环境没有影响或影响可以得到控制。
这一步骤为变更流程的关键质量检查点。
Ø规划RFC
RFC一旦获得批准,它必须根据资源和其他情况进行规划,确定实施日期,分配相应资源,并通知请求人。
Ø协调变更实施Coordinatingthechangeimplementation
一切就绪后,可以实施变更。
建议某客户计算机中心的运维组实施相应变更,变更经理监视实施过程,并在必要时进行协调。
Ø更新变更状态
在整个变更过程中,变更的状态从登记,评估,回顾到最后关闭是不同的。
变更经理负责更新预先定义好的变更状态。
Ø回顾和关闭
实施变更后,变更经理负责从技术和流程角度去回顾变更,该回顾在预先定义好的时间段针对变更单独进行,除确保RFC得到了预期效果外,也寻找流程的改进机会,如资源计划和实际使用的一致性。
确定是否满足了变更目的,有没有副面影响,否则需制定后续行动计划。
随后,变更经理负责利用预先定义好的结束状态关闭RFC。
Ø总结汇报
向管理层提供流程报表,向客户提供变更的相关执行信息。
定期向相关小组/部门根据流程衡量标准汇报很重要,只有如此,才可以基于现有环境的最新信息,作出进一步的改进建议。
Ø变更会议
变更经理负责定期或不定期召开变更会议,以在IT内部以及与客户就变更管理有一个好的沟通。
在会上,可以传递如,最近变更规划(FSC),将要实施变更的信息,也包括对变更流程的反馈和建议等。
Ø变更流程回顾
建议定期回顾变更管理流程以提高效率和效能,在实施变更流程不久之后,可以进行第一次回顾,以确保流程得到正确实施并起到预期目的,发现的问题必须追根溯源并尽快解决。
之后,可以定期举行正式的回顾——如每三个月。
2.5.业务价值
本流程将有助于实现某客户提高IT系统可用性的运维目标:
Ø确保所有变更的实施都不会对业务产生负面影响;
Ø确保所有变更的处理和实施都遵循规范的变更流程;
Ø确保所有变更及实施都得到完整记录;
Ø快速响应变更请求RFC;
Ø确保变更得到跟踪直至解决;
Ø确保和所有相关人员/部门能就变更状态有良好沟通;
Ø变更请求能有从业务/客户角度定义的影响度;
Ø变更的处理机遇所定的影响度分析;
变更管理流程主要的好处在于:
Ø提高IT环境的稳定性;
Ø面对客户需求和技术的快速变化,变更的管理和控制将使对生产环境的变更实施可能带来的风险最小化。
Ø降低运行成本;
来自
Ø良好的变更记录有助于运维流程的持续性改进,并加快变更相关问题的解决。
3.变更管理的人员角色和职责
在变更管理流程中,ITSM对角色建议有4个,变更经理,变更顾问委员会(CAB),变更主管和变更实施人员。
在标准ITIL标准流程中采用CAB环节一般作为参考条件,但是考虑到某客户目前很多运维和变更工作需要各个组协同执行,所以推荐成立CAB。
各角色述职如下:
3.1.变更经理
根据ITSM最佳实践,结合某客户的实际情况,建议变更经理和配置经理的角色是一个人,这样可以使变更管理和配置管理结合得更加紧密,同时可以保障配置管理CMDB的准确性。
另外,还可以使相关流程更加简捷,确保ITSM管理流程的可推广性。
变更经理职责:
Ø接受变更请求(RFC),并做初步筛选;
Ø确保变更请求(RFC)得到评估,授权,控制和计划;
Ø确保所有相关人员都尽可能地引入到变更请求的评估中;
Ø确保管理层得到足够关于变更的数量,影响度的信息;
Ø成立变更委员会,并领导变更委员会(CAB)和主持相关会议;
Ø确保变更在符合组织风险和需求的情况下,并在适当的时间内实施,在变更单中确定选择实施时间(保证实施时间的有效性);
Ø分派相应资源;
Ø协调变更的构建/测试和实施;
Ø领导,支持和指导员工,确保变更管理人员足够的积极性和绩效表现;
Ø确保变更管理流程,制定相关工作步骤及准则;
Ø提供复杂变更请求(RFC)的项目管理指导;
Ø生成有效的管理报表;
变更经理主要技能:
Ø非常了解变更管理、问题管理、配置管理和事件管理流程及其他们之间的关系;
Ø了解公司的IT架构和环境;
Ø了解配置项之间的关系;
Ø较强的沟通技巧;
Ø较强的组织能力;
Ø很强的团队领导能力;
变更经理主要考核指标:
Ø变更请求(RFC)的有效管理和控制;
Ø在变更回顾中,无效和负面变更的情况;
Ø对其他管理流程的支持力度;
3.2.变更顾问委员会(CAB/EC)
变更顾问委员会(CABorCAB/EC)职责:
Ø回顾所有提交重要的RFC,并确保它们的潜在影响和风险得到评估;
Ø针对具体变更请求,评估并讨论相应资源的分派;
Ø回顾所有已执行的变更,确保满足变更目的;
Ø参加CAB会议和紧急CAB会议;
Ø协作变更经理确定变更优先级及变更规划;
Ø在某客户,变更经理可能对CAB成员(大部分是运维组成员)没有行政权,为了保证CAB成员都能够参加讨论,同石化相关人员确认建议,可以在CAB中加入运维组组长;
变更顾问委员会(CABorCAB/EC)的组成人员:
ØCAB的组成人员可以根据具体的变更种类指定不同的人参与;
Ø固定成员:
变更经理、运维组组长、变更主管、项目组组长;
Ø如果是重大的实施类变更,需要某客户计算机中心领导人参与,如,科长或主任等;
Ø一般的实施类变更,CAB成员可以简化,如,变更主管可以和变更实施人员合并;
3.3.变更主管
变更主管属于不确定具体人员的角色,可以根据不同的变更种类,分派不同的人员作为变更主管。
对于普通的实施类变更,还可以将变更主管和变更实施人员合并在一起。
变更主管主要关注在测试计划、技术方案、实施计划等。
变更主管职责:
Ø接受变更请求,并协调实施;
Ø作为具体变更的项目经理,负责领导变更的构建/测试,实施和参与回顾;
Ø制定变更项目计划和时间规划等;
Ø更新项目记录,生成变更工单;
Ø在整个变更中协调各工单,以维护变更项目的整体性;
Ø确保变更在预定的时间,资源和成本内完成;
Ø在必要时,确保恢复计划(FallbackPlan)得以正确实施。
3.4.变更实施人员
变更实施人员主要关注在测试、具体现场实施等。
变更实施人员职责:
Ø根据变更主管制定的变更计划实施变更;
Ø执行分派的任务以推进变更项目;
Ø向变更主管汇报工作进程(在系统中加入时间限定:
当变更没有在预定的时间内得到实施,系统将自动通知变更主管和变更经理);
Ø现场负责变更实施或恢复实施。
3.5.某客户人员角色定义
角色
人员安排
备份安排
变更管理委员会
变更经理
XXX
变更主管
XX、XX
变更实施人员
系统管理员、项目组人员
4.变更管理流程说明
4.1.变更管理总体流程
根据某客户IT的具体情况,同时结合ITIL的最佳经验,某公司给出下面的变更管理的逻辑流程:
注:
相关符号的说明:
=相关工具和人员
=流程
=决策
所有优先级为普通、中、高的变更都将完全按照如上流程执行,各步骤的描述如下:
序号
步骤名称
责任人
说明
300.1
提交变更请求
变更请求者
请求者找出变更求请需求,然后跟相关部门或客户确认后填写变更请求单并提交给变更经理,如果常规变更,则由变更经理直接执行并结束变更。
300.2
接受变更请求
变更经理
接受变更请求,检查变更请求的完整性和正确性,确定相关变更顾问委员会CAB成员和变更主管。
常规类变更?
变更经理
判断所提交的变更是否为常规类变更,如果是,直接至“结束”判断框,此时变更经理直接执行变更并结束变更;如不是常规类变更,则继续。
紧急吗?
变更经理
判断是否为紧急变更,如是,则转紧急变更流程,否则继续。
300.3
评估风险/影响
变更顾问委员会CAB
召开会议或指定人员对变更请求进行评估并得出评估结果。
授权吗?
变更顾问委员会CAB
决定是否对该变更请求授权,如果授权,则继续,否则拒绝变更请求并有变更经理与变更请求者进行沟通。
300.4
测试/实施计划
变更主管
变更主管作为该变更项目经理,负责协调开发、测试和制定实施计划,并把测试结果和实施计划递交给变更经理以批准实施。
批准吗?
变更经理
决定是否批准实施变更,必要时召集变更顾问委员会,如批准,则继续,否则把测试结果和实施计划退还给变更主管并要求重新提交。
300.5
计划和沟通
变更经理
确定一个最合适的实施日期并和相关部门进行充分沟通。
300.6
实施
变更实施人员
根据实施计划执行变更实施,在必要时启动恢复计划(FallbackPlan)。
300.7
回顾
变更顾问委员会CAB
变更经理召开变更顾问委员会对实施的变更进行回顾以确定变更目的是否已达到,如没有,要求变更主管制定一个后续行动计划并通过变更经理的审核。
300.8
结束
变更经理
更新相关信息,关闭变更记录。
4.2.变更管理流程和其他管理流程的关系
4.3.变更管理详细流程
结合上面的逻辑流程和某客户的实际情况,某公司建议如下变更管理的物理流程。
(350)紧急变更逻辑流程
在日常运维过程中,紧急的变更和运维工作占了很大运维比率。
为了使紧急流程更能够符合某客户的实际情况,项目组在该问题上做了深入的讨论。
某客户对紧急流程处理的目标是:
1.实施流程尽量简化;
2.保证对流程的控制;
来自
在ITSM/ITIL中确定了紧急流程的定义,但并没有详细做法。
结合某公司顾问的经验和某客户的实际情况,具体确定了以下策略来确保紧急变更流程的实施。
对于紧急变更,某公司顾问建议成立CAB紧急委员会,称为CAB/EC,对紧急变更请求进行评估和授权。
下面是紧急变更逻辑流程,其物理流程和正常变更的物理流程一致(具有相同的流程步骤名称,除了在每个名称前加上“快速”以作区别)。
CAB/EC成员可以是固定的,建议由某客户信息科技部安全运行处长、运维组组长和变更经理组成。
紧急变更的特殊之处是变更文档可以在变更实施完之后提交,但必须在可能的情况下通知变更经理并得到CAB/EC的口头批准。
流程详细描述如下:
序号
步骤名称
责任人
说明
350.1
紧急度确认
CAB紧急委员会(CAB/EC)
得到变更经理的紧急变更的口头或电子请求后,进行紧急度确认;
紧急吗?
CAB紧急委员会(CAB/EC)
召开紧急会议或以Email+电话形式确定是否确属紧急变更请求,如不是,返回正常流程300.3,(建议参与CAB/EC者有信息科技部部长、安全运行处处长和变更经理,而且安全运行处处长必须参加并执行决定权,)如果是,继续;
350.2
快速评估
CAB紧急委员会(CAB/EC)
召开紧急会议,对紧急变更请求进行快速评估,包括影响度/风险和所需资源评估,并快速得出评估结果;
350.3
快速测试和制定计划
变更主管
快速进行各种测试并制定必要的实施计划,并安排实施;
350.4
快速实施
变更实施人员
根据实施计划,快速执行变更,必要时启动恢复计划(FallbackPlan);
350.5
收集相关文档资料
变更经理
紧急变更结束后,变更经理收集由变更实施人员递交的相关文档,包括测试结果和实施计划;资料周期的搜集期限是2个工作日。
350.6
回顾
CAB紧急委员会(CAB/EC)
变更经理召开紧急变更顾问委员会CAB/EC,对实施的紧急变更进行回顾以确定变更目的是否已达到,资料收集是否完整,加以控制,需要对其进行实效控制(2个工作日);如没有,要求变更主管制定一个后续行动计划并通过变更经理的审核;
350.7
结束
变更经理
更新相关信息,关闭变更记录;
(300.1)提交变更请求
物理流程详细描述如下:
序号
责任人
步骤名称
描述
300.1.1
变更请求者
找出变更请求
基于技术需求和业务需求,找出变更机会;
300.1.2
变更请求者
收到变更请求
从其他IT成员或从客户部门得到变更请求;
300.1.3
变更请求者
确认变更请求
和部门负责人对变更请求进行确认,并得到批准;
300.1.4
变更请求者
填写变更请求
打开变更管理页面,填入相关变更信息;
300.1.5
变更请求者
提交变更请求
把变更请求提交(分派)给变更经理,变更经理将获得相关通知;
(300.2)接受变更请求
物理流程详细描述如下:
序号
责任人
物理流程描述
300.2.1
变更经理
接受提交过来的变更请求;
300.2.2
变更经理
根据变更的具体情况,确定变更顾问委员会成员和变更主管;
300.2.3
变更经理
更新变更请求的相关信息;
紧急吗?
变更经理
判断是否为紧急变更请求,如是,转紧急变更流程350,否则继续;
(300.3)评估风险/影响
评估风险/影响物理流程详细描述如下:
序号
责任人
物理流程描述
300.3.1
变更顾问委员会CAB
根据已确定的变更顾问委员会成员,确定会议议程,召开变更评估会议;
300.3.2
变更顾问委员会CAB
根据变更的具体情况,确定该变更的影响度及其影响度代码;
300.3.3
变更顾问委员会CAB
根据变更的具体情况,确定该变更的风险情况及其代码;
300.3.4
变更顾问委员会CAB
确定变更所需要的资源,包括所需时间等;
300.3.5
变更顾问委员会CAB
总结所有分析结果,得出最终决定;
变更顾问委员会CAB
决定是否给变更授权,如是转300.3.7,否则继续;
300.3.6
变更经理
根据CAB决定,拒绝变更请求;
300.3.7
变更经理
记录评估结果,并相应做初步规划;
300.3.8
变更经理
跟变更请求者进行沟通,告知变更请求被拒绝原因;
300.3.9
变更经理
更新工单状态,结束。
(300.4)测试/实施计划
测试/实施计划物理流程详细描述如下:
序号
责任人
物理流程描述
300.4.1
变更主管
在需要的情况下做完必要的开发和功能测试后,制定变更项目实施的沟通计划,如在什么条件下谁该做什么,应该联系谁等;
300.4.2
变更主管
根据具体要实施的变更,制定具体的任务列表;
300.4.3
变更主管
制定从运维角度看如何满足运营要求的运维接受测试(OAT)计划;
300.4.4
变更主管
根据先前风险评估得出的风险及其风险度,制定相应的风险管理计划;
300.4.5
变更主管
根据风险情况,制定相应的恢复计划(FallbackPlan),以在需要时恢复变更
300.4.6
变更主管
收集测试结果和制定的实施计划,提交给变更经理;
300.4.7
变更经理
分析由变更主管提交的变更测试结果和实施计划,作出相应的决定;
批准?
变更经理
根据分析,以确定是否批准实施,如是,转300.5.1,如否,退还变更主管重新测试和制定计划;
(300.5)计划&沟通
计划&沟通物理流程详细描述如下:
序号
责任人
物理流程描述
300.5.1
变更经理
根据变更请求日期,测试结果和实施计划,确定实施日期;
300.5.2
变更经理
根据确定的实施日期,找出与其相关的其他变更,并解决相互的关联关系,包括资源、人员等;
300.5.3
变更经理
确定变更实施时间的冲突关系并协调解决;
300.5.4
变更经理
判断确定的实施日期是否可行,如是,继续,否则返回300.5.1,重新确定日期;
300.5.5
变更经理
根据确定的实施日期,与相关人员进行沟通,包括变更主管,变更实施人员等;
300.5.6
变更经理
把变更相关信息通知相关用户,如可能的影响等;
(300.6)变更实施
变更实施流程详细描述如下:
序号
责任人
物理流程描述
300.6.1
变更实施人员
执行变更主管制定的运维接受测试(OAT)计划,以确认变更能符合运维的要求;
OK?
变更实施人员
判断运维接受测试是否成功?
是则继续,否则重新进行OAT测试;
300.6.2
变更经理
根据测试结果再次确认实施时间;
300.6.3
变更实施人员
在确定的变更实施时间根据实施计划具体实施变更;
成功?
变更主管
判断变更是否成功,是则继续,否则转300.6.5,执行恢复计划;
300.6.4
变更经理
确认实施确已完成并符合预期质量要求;
300.6.5
变更实施人员
执行变更主管制定的恢复计划(FallbackPlan),以恢复变更;
(300.7)回顾
回顾流程详细描述如下:
序号
责任人
物理流程描述
300.7.1
变更经理
召开回顾会议(可以是各种形式,包括电话会议);
实施了恢复计划?
变更经理
判断是否实施了恢复计划,是则转300.7.2分析根本原因,否则转300.7.3开始技术回顾;
300.7.2
变更顾问委员会CAB
分析变更失败的根本原因;
300.7.3
变更顾问委员会CAB
从技术的角度回顾变更的实施过程;
300.7.4
变更顾问委员会CAB
从流程的角度回顾变更的实施;
变更目的达到?
变更顾问委员会CAB
综合起来判断变更目的是否达到,是则转300.7.7,记录回顾结果,否则转300.7.5,制定后续行动计划;
300.7.5
变更主管
根据分析出的变更失败的根本原因制定后续行动计划,并将该后续行动计划进行测试和指定实施计划(300.4.1);
300.7.6
变更经理
记录和整理回顾的结果,包括成功的变更和