20150829   淡然

续上

2.3.2      变更风险与影响评估

重要定义：

§  变更管理委员会（Change Advisory Board，简称CAB）

变更管理委员会(Change Advisory Board)是为了帮助评估变更、制定优先级和审批而召集的组织，CAB的成员之选择需要保证可以从业务和技术的角度全面的评估所有的变更，因此CAB应该包括那些明确业务需要和用户状况、了解技术开发以及IT支持职能的人员和管理层。

建议的CAB的人员组成包括：                            ITSS考试

·         变更经理

·         业务用户（特别是业务负责人）

·         用户代表和经理

·         应用开发人员和维护人员

·         相关方面专家和技术顾问（可能包括CPIC外部的专家）

·         服务人员（根据需要）

·         办公环境服务人员(如果变更需要影响办公环境)

·         外包方代表（对于第三方外包的情况）

需要强调的是：

·         CAB成员将根据相应的变更而变化，建议变更经理保留一份CAB成员候选列表

·         供应商的参与可能会有相当的帮助

·         需要同时反映业务用户和业务负责人的要求

·         需要涉及问题经理、服务级别管理经理和用户关系管理代表

图 5: 变更风险与影响评估

[td]

编号	步骤	输入/触发	描述	输出/完成标准	变更状态	适用性考虑
6.3.2.1	制定初步变更计划	已登记分类的变更	变更经理责成变更主管制定初步的变更计划。特别的，当变更将涉及多个部门或实体的协调时（例如设计软件开发解决应用缺陷时，需要开发主管和系统主管的参与确认），应由变更经理进行协调、监督和确认。 变更计划的目的是为CAB会议评审作准备。该计划应该尽可能的详细，从而足以支持CAB会议作出决定。	初步计划	已登记	因此初步变更计划应该包括：资源、技术步骤、业务考虑等方面。对于暂时不确认的信息，应该明确罗列，并于CAB会议时澄清。
6.3.2.2	判断是否一般变更	输入：RFC	如果为一般变更，执行步骤 6.3.2.3 如果为重大变更，执行步骤 6.3.2.4	一般变更指派给变更主管 将重大故障交付给CAB	已登记
6.3.2.3	评估一般变更的风险与影响	输入：一般变更	变更主管回顾一般变更并估计完成改工作的工作量，随后再估计实施该变更的风险和对于环境的可能影响，对于一般变更，不需要通过CAB会议讨论，直接交由变更主管负责准备计划开始实施。如果变更主管如果认为目前阶段实施变更并非合适，应给向变更经理给出相应意见                ITSS认证	一般变更风险评估结果	已评估	变更主管主要通过CMDB的查询，了解对应CI的改变与业务的关系，所需的时间以及从技术角度的考量
6.3.2.4	召集CAB成员	输入：需要CAB研究决定的重大变更	根据变更的内容和变更提交人的要求，变更经理决定针对本次变更需要着的CAB成员，确保CAB成员可以代表客户、业务和技术各方面的利益和足够的权威。并在召开CAB会议之前将会议相关材料事先交给与会人员，并确认会议日程与地点。	CAB成员已通知并同意与会	已登记	CAB的组成 召集CAB的目的是获得足够的支持和资源来授权实施变更，因此CAB应包括针对本变更的所有责任人（stakeholders，包括可以代表业务、资源等方面）。变更经理应该建立并维护CAB候选人名单，针对每一个变更的不同，召集的不同的人员，可能也需要包括外部供应商的参与。此外，建议考虑建立CAB例会制度，尽可能将需要讨论的变更问题在例会中解决
6.3.2.5	影响、风险和工作量评估	输入：需要CAB研究决定的重大变更	变更经理召开CAB会议，详细评估工作量、影响和实施风险，确认客户的满意、业务需要的满足和技术资源的充足。	会议记录及风险评估讨论结果	已登记	特别当变更需要涉及多个部门或机制的配合时，应在CAB会议中确认各方职责。
6.3.2.6	回顾和更新变更的范畴、影响和优先级	输入：经过CAB研究的变更请求	根据CAB会议的结果，变更经理和变更主管重新判断和更新变更的范畴、影响和优先级以及其他任何信息的更新，如果有必要重新调整流程处理类型	变更重要属性回顾结果，包括范畴、影响和优先级	已评估	CAB应该获得对于所讨论变更活动的一致意见，其过程是交互的。

2.3.3      变更审批

图 6: 变更审批

[td]

编号	步骤	输入/触发	描述	输出/完成标准	变更状态	适用性考虑
6.3.3.1	评估所有相关RFC	输入：变更影响评估结果	由于某些变更可能涉及多个RFC，或者不同的RFC之间可能存在的相互联系与依赖性，所以变更经理需要通过对这些RFC的全面了解来更好的把握需要执行的变更任务	准备回顾和完成变更的审批	已评估	主要为了排除不同变更之间的资源争夺和互斥性
6.3.3.2	回顾和讨论CAB结果	输入：CAB对于变更的分析结果	变更经理与变更主管讨论变更会议结论并考察其他相关的细节事宜	准备好审批变更的足够信息	已评估	在此，CAB各成员应该已对该变更获得基本一致。
6.3.3.3	变更审批	输入：回顾审核好的变更信息	变更经理根据评估结果作出批准或是拒绝的判断	完成变更的审批	已授权/已驳回	变更经理在总结CAB的意见基础下，做出授权。对于重大变更，建议CAB重要成员的意见应该被文档化，并提供签字确认。
6.3.3.4	调集资源	输入：已审批的变更	变更批准后，变更主管负责协调开发、测试变更的资源准备             ITSS培训	可以准备开发和测试变更阶段	已授权	变更主管 对于重大变更，建议由唯一的变更主管负责，当然对于目前可能存在的多方变更，需要各方负责人的参与，对于各方负责人的设定，建议在CAB会议上确认。
6.3.3.5	通知变更的驳回	被驳回的变更	变更经理通知变更提交人与变更主管该变更已被驳回，并陈述理由。	已通知变更的驳回	已驳回

待续http://www.itilxf.com/thread-52357-1-1.html

本帖关键字：ITSS

20150829   淡然

续上

2.3.2      变更风险与影响评估

重要定义：

§  变更管理委员会（Change Advisory Board，简称CAB）

变更管理委员会(Change Advisory Board)是为了帮助评估变更、制定优先级和审批而召集的组织，CAB的成员之选择需要保证可以从业务和技术的角度全面的评估所有的变更，因此CAB应该包括那些明确业务需要和用户状况、了解技术开发以及IT支持职能的人员和管理层。

建议的CAB的人员组成包括：                            ITSS考试

·         变更经理

·         业务用户（特别是业务负责人）

·         用户代表和经理

·         应用开发人员和维护人员

·         相关方面专家和技术顾问（可能包括CPIC外部的专家）

·         服务人员（根据需要）

·         办公环境服务人员(如果变更需要影响办公环境)

·         外包方代表（对于第三方外包的情况）

需要强调的是：

·         CAB成员将根据相应的变更而变化，建议变更经理保留一份CAB成员候选列表

·         供应商的参与可能会有相当的帮助

·         需要同时反映业务用户和业务负责人的要求

·         需要涉及问题经理、服务级别管理经理和用户关系管理代表

图 5: 变更风险与影响评估

[td]

编号	步骤	输入/触发	描述	输出/完成标准	变更状态	适用性考虑
6.3.2.1	制定初步变更计划	已登记分类的变更	变更经理责成变更主管制定初步的变更计划。特别的，当变更将涉及多个部门或实体的协调时（例如设计软件开发解决应用缺陷时，需要开发主管和系统主管的参与确认），应由变更经理进行协调、监督和确认。 变更计划的目的是为CAB会议评审作准备。该计划应该尽可能的详细，从而足以支持CAB会议作出决定。	初步计划	已登记	因此初步变更计划应该包括：资源、技术步骤、业务考虑等方面。对于暂时不确认的信息，应该明确罗列，并于CAB会议时澄清。
6.3.2.2	判断是否一般变更	输入：RFC	如果为一般变更，执行步骤 6.3.2.3 如果为重大变更，执行步骤 6.3.2.4	一般变更指派给变更主管 将重大故障交付给CAB	已登记
6.3.2.3	评估一般变更的风险与影响	输入：一般变更	变更主管回顾一般变更并估计完成改工作的工作量，随后再估计实施该变更的风险和对于环境的可能影响，对于一般变更，不需要通过CAB会议讨论，直接交由变更主管负责准备计划开始实施。如果变更主管如果认为目前阶段实施变更并非合适，应给向变更经理给出相应意见                ITSS认证	一般变更风险评估结果	已评估	变更主管主要通过CMDB的查询，了解对应CI的改变与业务的关系，所需的时间以及从技术角度的考量
6.3.2.4	召集CAB成员	输入：需要CAB研究决定的重大变更	根据变更的内容和变更提交人的要求，变更经理决定针对本次变更需要着的CAB成员，确保CAB成员可以代表客户、业务和技术各方面的利益和足够的权威。并在召开CAB会议之前将会议相关材料事先交给与会人员，并确认会议日程与地点。	CAB成员已通知并同意与会	已登记	CAB的组成 召集CAB的目的是获得足够的支持和资源来授权实施变更，因此CAB应包括针对本变更的所有责任人（stakeholders，包括可以代表业务、资源等方面）。变更经理应该建立并维护CAB候选人名单，针对每一个变更的不同，召集的不同的人员，可能也需要包括外部供应商的参与。此外，建议考虑建立CAB例会制度，尽可能将需要讨论的变更问题在例会中解决
6.3.2.5	影响、风险和工作量评估	输入：需要CAB研究决定的重大变更	变更经理召开CAB会议，详细评估工作量、影响和实施风险，确认客户的满意、业务需要的满足和技术资源的充足。	会议记录及风险评估讨论结果	已登记	特别当变更需要涉及多个部门或机制的配合时，应在CAB会议中确认各方职责。
6.3.2.6	回顾和更新变更的范畴、影响和优先级	输入：经过CAB研究的变更请求	根据CAB会议的结果，变更经理和变更主管重新判断和更新变更的范畴、影响和优先级以及其他任何信息的更新，如果有必要重新调整流程处理类型	变更重要属性回顾结果，包括范畴、影响和优先级	已评估	CAB应该获得对于所讨论变更活动的一致意见，其过程是交互的。

2.3.3      变更审批

图 6: 变更审批

[td]

编号	步骤	输入/触发	描述	输出/完成标准	变更状态	适用性考虑
6.3.3.1	评估所有相关RFC	输入：变更影响评估结果	由于某些变更可能涉及多个RFC，或者不同的RFC之间可能存在的相互联系与依赖性，所以变更经理需要通过对这些RFC的全面了解来更好的把握需要执行的变更任务	准备回顾和完成变更的审批	已评估	主要为了排除不同变更之间的资源争夺和互斥性
6.3.3.2	回顾和讨论CAB结果	输入：CAB对于变更的分析结果	变更经理与变更主管讨论变更会议结论并考察其他相关的细节事宜	准备好审批变更的足够信息	已评估	在此，CAB各成员应该已对该变更获得基本一致。
6.3.3.3	变更审批	输入：回顾审核好的变更信息	变更经理根据评估结果作出批准或是拒绝的判断	完成变更的审批	已授权/已驳回	变更经理在总结CAB的意见基础下，做出授权。对于重大变更，建议CAB重要成员的意见应该被文档化，并提供签字确认。
6.3.3.4	调集资源	输入：已审批的变更	变更批准后，变更主管负责协调开发、测试变更的资源准备             ITSS培训	可以准备开发和测试变更阶段	已授权	变更主管 对于重大变更，建议由唯一的变更主管负责，当然对于目前可能存在的多方变更，需要各方负责人的参与，对于各方负责人的设定，建议在CAB会议上确认。
6.3.3.5	通知变更的驳回	被驳回的变更	变更经理通知变更提交人与变更主管该变更已被驳回，并陈述理由。	已通知变更的驳回	已驳回

待续http://www.itilxf.com/thread-52357-1-1.html

本帖关键字：ITSS