论文部分内容阅读
摘要:Change Management通过采用标准化的方法和过程快速高效地处理change。在Change Management 处理过程中,前两个步骤:1. 接受并核查RFC;2. 评估Change,记录风险和影响,是后续计划、授权、执行等步的基础,通过一系列的标准化过程,完成change 的过滤、分类、影响和风险评估等步骤,并在此过程中实现了对部分change 请求的优化。
关键词:IT服务管理,变更管理,模型,流程
Change Management 是IT 服务管理框架中的重要组成部分。
IT 服务管理中所谓变更change,即可能对IT 服务造成影响的对任何事物的增加、更改或移除。其涵盖范围包括所有的IT 服务、配置项、流程、文档等。这些change 可能是IT 内部发起的,也可能来自用户的要求;既可能是主动发起的改进,也可能是incident、problem 所导致的;既可能是服务改变、应用系统开发启动这样高层次变更,也可能是具体的操作,比如办公室搬家、服务器替换。
负责控制所有change 生命周期的流程就是变更管理流程Change Management Process。Change Management 的首要目的是使有益的Change 发生,同时最小化IT 服务的中断。它通过采用标准化的方法和过程快速高效地处理change。实际上,Change Management 的过程就是用可控的方式保证change 被记录、评估、授权、优先级划分、计划、测试、部署、归档和回顾检查的过程。在这个过程中,相关的信息被记录至配置管理系统,整体的业务风险获得优化。
在ITIL v3 中,v2 时原有的10个流程被进一步分化、加强,Service Strategy 阶段以及Transition Planning and Support 等流程的引入,使得对投资和风险的优化可以更加专业的发生在多个层次上,使Change Management 可以更加专注于处理操作层面change 或是对高层次change 进入实践的最后一步控制,从某种程度上为Change Management 减负,也使这套IT 服务管理架构获得了更好的适应性,以应对更大规模的或是业务管理灵活的组织。
1. 变更管理中变更请求受理及评估过程的意义
按照change 的定义,所谓“可能对IT 服务造成影响的”“对任何事物的增加、更改或移除”,意味着IT 服务管理中涉及的change 无处不在,新员工账号的创建、离职员工账号的删除、新电脑的加入、会议室网口的增加、新应用系统的上线、老应用系统或是服务器的下线、服务器密码的统一修改、Windows 系统的定期补丁升级或其他应用系统更新、办公室搬迁、新型号打印机的引入、文件服务器上share folder 的调整、服务合同的续签、对某些网站访问的屏蔽、leased line 带宽升级等等,还包括那些难以分类界定的和IT 有关的需求。
实践中的change数量巨大,而Change Management 要求快速高效地处理change 同时还要控制风险, 在某些组织中还希望尽可能优化资源投入,难度可想而知,于是采用标准化的方法和过程成为必然。同时,change 又是多种多样的,为了达到标准化处理的目的,首先就需要采取分类处理的办法。
Normal change 处理的主要过程为,
1. 接受并核查RFC;
2. 评估Change,记录风险和影响;
3. 计划及授权;
4. 准备Change 执行;
5. 执行Change;
6. 检查并结束Change。
此外对于standard change 可以建立单独的处理流程,
7. Standard Change 流程
分类的过程发生在步骤1. 接受并核查RFC。在所需信息基本完整的情况下,尽早进行分类,可以使后续工作的标准化更加容易。例如可以在步骤1 处选择是否进入standard change 流程以及判断属于哪类standard change。信息收集和分类,是所有后续Change Management 活动的基础,应细腻适度。
步骤2. 评估Change,记录风险和影响,这步是change 授权决策及执行的最重要的基础,也是Change Management 实现其价值的重要步骤。Change Management 的价值不仅体现在change 的实施结果、多个change 间的安排和执行中的资源调度优化上,也体现在通过影响和风险的分析,提出良好的实施方案,以及对风险的避免或弱化,这部分的价值是无论change最终是否实施都存在的。
2. 方法和模型
步骤1. 接受并核查RFC
鉴于change 的复杂性,Change Management 所接收的RFC (Request for Change) 可能有各种不同的来源,包括发起自IT 组织本身的,也包括源自客户或是最终用户的。由于Service Desk 是最终用户与IT 组之间的主要联络点(Primary Point of Contact),因此绝大部分直接来自最终用户的变更需求都会是经由Service Desk 及其所主要工作在的Incident Management 流程转至Change Management。此外,其他IT 服务管理流程,如Service Design 中的Service Level Management,Service Transition 中的Transition Planning and Support,Service Operation 中的Problem Management 等等,几乎所有流程,只要涉及变更,都需要触发Change Management,即生成RFC 发送至Change Management,并由Change Management 完成相应的授权及管理控制。
步骤1.1 接收和过滤RFC。RFC 的提交不同的组织中可以采取不同的方式,可以通过电子邮件附带特定格式的word 或是excel 文件、可以通过网页或是InfoPath 提交、也可以采用专用的IT 服务管理信息系统如Remedy 等。无论采用何种方式,一般来说,RFC 中都会包含以下内容,申请者信息、变更的描述、原因、相关记录(incident、problem 或其他change 等)、已知的影响和风险、建议的优先级、建议的实施时间、预期的时间和费用消耗等。
除了明确定义为属于service request 或其它流程处理范围的,或是明确定义为不属于change 或IT 服务范围的,其他所有包含变更的请求都有可能会被发送至Change Management。Change Management 小组成员需要根据相关政策、要求确认所接收到的请求是否为Change Management 处理范围,如果不是,则返还给请求的发送者,或是转发给正确的处理者。如果初步判定为在Change Management 处理范围内,则需确认所需信息是否完整齐备。
步骤1.2 核对相关合同。来自用户的对信息、设备、标准变更、或服务使用权等的请求,如要求重置密码、新用户申请邮件账号等,属于合同范围你的标准服务请求,通常归为service request,由Service Desk 在Request Fulfillment 流程中完成,此类请求不会进入Change Management,或是在1.1 接收和过滤RFC 阶段中即被退回。对于没有被当前服务合同所完全涵盖、同时有必要通过合同进行处理的变更请求,一般首先需要进行进行项目的开发、准备,而不是直接进入Change Management 审批。这种类型的变更请求往往意味着含有较大的商业机会、变更规模或影响较大、现有IT 运营层面的操作无法满足。此外其他的请求,通常Change Management 可以直接受理,其中既可以包括IT 服务合同已包含的服务项目,也可以包括合同中没有但也不必需要合同的服务项目。
步骤1.3 分类。根据已有信息进行分类,依据不同的类别,可以采取不同的处理方式的响应级别。例如对于有固定的操作模式、经常发生、成本和风险都在可控范围内的standard change 应用对应的standard change 流程;对于紧急的变更请求,则须加快响应速度并在后续操作中采取应急的处置方式。进入此步同时意味着正式接受该RFC,因此,如果有应用Change Management 的管理信息系统,应此步或此步之前完成change ticket 的录入。
步骤2 评估Change,记录风险和影响
步骤2.1 识别所需的变更。指识别在此change 中要求变更哪些配置项,需要考虑到其他正在执行或已经计划的change。
步骤2.2 识别受影响的服务和潜在收益。根据2.1 所识别出的配置项识别受影响的服务和潜在收益。
步骤2.3 识别所有受影响的配置项。根据2.2 中识别出的受影响的服务进一步挖掘会受影响的所有配置项,需要考虑到其他正在执行或已经计划的change。
步骤2.4 如果涉及多项变更,可创建多个change 记录。
步骤2.5 评估并记录影响和高风险。可以采用组织中已有的风险管理方法来完成此步,seven Rs 的方法可以帮助风险评估者完成此项工作。7个R 对应着7个问题,它们有助于进一步理解此变更的风险和价值。
Who RAISED the change? 谁提交的此项变更?
What is the REASON for the change? 变更的原因是什么?
What is the RETURN required from the change? 希望达成何种结果?
What are the RISKS involved in the change? 牵扯了哪些风险?
What RESOURCES are required to deliver the change? 需要哪些资源来完成此项变更?
Who is RESPONSIBLE for the build, test and implementation of the change? 谁负责构建、测试和实施此项变更?
What is the RELATIONSHIP between this change and other changes? 此项变更与其他变更间有什么关系?
步骤2.6 联系发起者补充信息。
步骤2.7 拒绝该RFC 并告知发起者。
3. 总结
Change Management 流程的实现要求通过标准化的方式,其中的每一个步骤也应尽量做到标准化,并考虑到前一步是下一步的准备,同时避免无效的活动、以全局利益的实现为根本。在Change Management 的实施中,应严格禁止未授权变更的出现。同时,ITIL 的核心方法论是PDCA,流程和规则都不是死的,需要不断改进,Change Management流程步骤也需要根据业务发展不断调整。
参考文献:
1.Sharon Taylor, et al. ITIL Service Transition[M]. UK: TSO, 2007.
作者介绍:
1. 武装,北京信息科技大学,计算机学院,研究生导师,计算机网络及信息管理方向
关键词:IT服务管理,变更管理,模型,流程
Change Management 是IT 服务管理框架中的重要组成部分。
IT 服务管理中所谓变更change,即可能对IT 服务造成影响的对任何事物的增加、更改或移除。其涵盖范围包括所有的IT 服务、配置项、流程、文档等。这些change 可能是IT 内部发起的,也可能来自用户的要求;既可能是主动发起的改进,也可能是incident、problem 所导致的;既可能是服务改变、应用系统开发启动这样高层次变更,也可能是具体的操作,比如办公室搬家、服务器替换。
负责控制所有change 生命周期的流程就是变更管理流程Change Management Process。Change Management 的首要目的是使有益的Change 发生,同时最小化IT 服务的中断。它通过采用标准化的方法和过程快速高效地处理change。实际上,Change Management 的过程就是用可控的方式保证change 被记录、评估、授权、优先级划分、计划、测试、部署、归档和回顾检查的过程。在这个过程中,相关的信息被记录至配置管理系统,整体的业务风险获得优化。
在ITIL v3 中,v2 时原有的10个流程被进一步分化、加强,Service Strategy 阶段以及Transition Planning and Support 等流程的引入,使得对投资和风险的优化可以更加专业的发生在多个层次上,使Change Management 可以更加专注于处理操作层面change 或是对高层次change 进入实践的最后一步控制,从某种程度上为Change Management 减负,也使这套IT 服务管理架构获得了更好的适应性,以应对更大规模的或是业务管理灵活的组织。
1. 变更管理中变更请求受理及评估过程的意义
按照change 的定义,所谓“可能对IT 服务造成影响的”“对任何事物的增加、更改或移除”,意味着IT 服务管理中涉及的change 无处不在,新员工账号的创建、离职员工账号的删除、新电脑的加入、会议室网口的增加、新应用系统的上线、老应用系统或是服务器的下线、服务器密码的统一修改、Windows 系统的定期补丁升级或其他应用系统更新、办公室搬迁、新型号打印机的引入、文件服务器上share folder 的调整、服务合同的续签、对某些网站访问的屏蔽、leased line 带宽升级等等,还包括那些难以分类界定的和IT 有关的需求。
实践中的change数量巨大,而Change Management 要求快速高效地处理change 同时还要控制风险, 在某些组织中还希望尽可能优化资源投入,难度可想而知,于是采用标准化的方法和过程成为必然。同时,change 又是多种多样的,为了达到标准化处理的目的,首先就需要采取分类处理的办法。
Normal change 处理的主要过程为,
1. 接受并核查RFC;
2. 评估Change,记录风险和影响;
3. 计划及授权;
4. 准备Change 执行;
5. 执行Change;
6. 检查并结束Change。
此外对于standard change 可以建立单独的处理流程,
7. Standard Change 流程
分类的过程发生在步骤1. 接受并核查RFC。在所需信息基本完整的情况下,尽早进行分类,可以使后续工作的标准化更加容易。例如可以在步骤1 处选择是否进入standard change 流程以及判断属于哪类standard change。信息收集和分类,是所有后续Change Management 活动的基础,应细腻适度。
步骤2. 评估Change,记录风险和影响,这步是change 授权决策及执行的最重要的基础,也是Change Management 实现其价值的重要步骤。Change Management 的价值不仅体现在change 的实施结果、多个change 间的安排和执行中的资源调度优化上,也体现在通过影响和风险的分析,提出良好的实施方案,以及对风险的避免或弱化,这部分的价值是无论change最终是否实施都存在的。
2. 方法和模型
步骤1. 接受并核查RFC
鉴于change 的复杂性,Change Management 所接收的RFC (Request for Change) 可能有各种不同的来源,包括发起自IT 组织本身的,也包括源自客户或是最终用户的。由于Service Desk 是最终用户与IT 组之间的主要联络点(Primary Point of Contact),因此绝大部分直接来自最终用户的变更需求都会是经由Service Desk 及其所主要工作在的Incident Management 流程转至Change Management。此外,其他IT 服务管理流程,如Service Design 中的Service Level Management,Service Transition 中的Transition Planning and Support,Service Operation 中的Problem Management 等等,几乎所有流程,只要涉及变更,都需要触发Change Management,即生成RFC 发送至Change Management,并由Change Management 完成相应的授权及管理控制。
步骤1.1 接收和过滤RFC。RFC 的提交不同的组织中可以采取不同的方式,可以通过电子邮件附带特定格式的word 或是excel 文件、可以通过网页或是InfoPath 提交、也可以采用专用的IT 服务管理信息系统如Remedy 等。无论采用何种方式,一般来说,RFC 中都会包含以下内容,申请者信息、变更的描述、原因、相关记录(incident、problem 或其他change 等)、已知的影响和风险、建议的优先级、建议的实施时间、预期的时间和费用消耗等。
除了明确定义为属于service request 或其它流程处理范围的,或是明确定义为不属于change 或IT 服务范围的,其他所有包含变更的请求都有可能会被发送至Change Management。Change Management 小组成员需要根据相关政策、要求确认所接收到的请求是否为Change Management 处理范围,如果不是,则返还给请求的发送者,或是转发给正确的处理者。如果初步判定为在Change Management 处理范围内,则需确认所需信息是否完整齐备。
步骤1.2 核对相关合同。来自用户的对信息、设备、标准变更、或服务使用权等的请求,如要求重置密码、新用户申请邮件账号等,属于合同范围你的标准服务请求,通常归为service request,由Service Desk 在Request Fulfillment 流程中完成,此类请求不会进入Change Management,或是在1.1 接收和过滤RFC 阶段中即被退回。对于没有被当前服务合同所完全涵盖、同时有必要通过合同进行处理的变更请求,一般首先需要进行进行项目的开发、准备,而不是直接进入Change Management 审批。这种类型的变更请求往往意味着含有较大的商业机会、变更规模或影响较大、现有IT 运营层面的操作无法满足。此外其他的请求,通常Change Management 可以直接受理,其中既可以包括IT 服务合同已包含的服务项目,也可以包括合同中没有但也不必需要合同的服务项目。
步骤1.3 分类。根据已有信息进行分类,依据不同的类别,可以采取不同的处理方式的响应级别。例如对于有固定的操作模式、经常发生、成本和风险都在可控范围内的standard change 应用对应的standard change 流程;对于紧急的变更请求,则须加快响应速度并在后续操作中采取应急的处置方式。进入此步同时意味着正式接受该RFC,因此,如果有应用Change Management 的管理信息系统,应此步或此步之前完成change ticket 的录入。
步骤2 评估Change,记录风险和影响
步骤2.1 识别所需的变更。指识别在此change 中要求变更哪些配置项,需要考虑到其他正在执行或已经计划的change。
步骤2.2 识别受影响的服务和潜在收益。根据2.1 所识别出的配置项识别受影响的服务和潜在收益。
步骤2.3 识别所有受影响的配置项。根据2.2 中识别出的受影响的服务进一步挖掘会受影响的所有配置项,需要考虑到其他正在执行或已经计划的change。
步骤2.4 如果涉及多项变更,可创建多个change 记录。
步骤2.5 评估并记录影响和高风险。可以采用组织中已有的风险管理方法来完成此步,seven Rs 的方法可以帮助风险评估者完成此项工作。7个R 对应着7个问题,它们有助于进一步理解此变更的风险和价值。
Who RAISED the change? 谁提交的此项变更?
What is the REASON for the change? 变更的原因是什么?
What is the RETURN required from the change? 希望达成何种结果?
What are the RISKS involved in the change? 牵扯了哪些风险?
What RESOURCES are required to deliver the change? 需要哪些资源来完成此项变更?
Who is RESPONSIBLE for the build, test and implementation of the change? 谁负责构建、测试和实施此项变更?
What is the RELATIONSHIP between this change and other changes? 此项变更与其他变更间有什么关系?
步骤2.6 联系发起者补充信息。
步骤2.7 拒绝该RFC 并告知发起者。
3. 总结
Change Management 流程的实现要求通过标准化的方式,其中的每一个步骤也应尽量做到标准化,并考虑到前一步是下一步的准备,同时避免无效的活动、以全局利益的实现为根本。在Change Management 的实施中,应严格禁止未授权变更的出现。同时,ITIL 的核心方法论是PDCA,流程和规则都不是死的,需要不断改进,Change Management流程步骤也需要根据业务发展不断调整。
参考文献:
1.Sharon Taylor, et al. ITIL Service Transition[M]. UK: TSO, 2007.
作者介绍:
1. 武装,北京信息科技大学,计算机学院,研究生导师,计算机网络及信息管理方向