20150829 淡然

续上

2.3.1      变更登记与分类

重要定义：

变更管理的目的是有效的审批和控制对于IT设施变更，从而减少对于业务和用户的影响，以达到提高服务质量和实现服务等级。但是，绝对的控制等同于绝对的没有效率。因此，对于某公司建议确立变更的分类处理以提高变更管理的效率。                             ITSS考试

1.   紧急变更

紧急变更指的是如果不进行变更，会立即或正在严重影响业务运行、导致严重影响服务等级或者带来重大社会影响的变更，紧急变更的实施往往无法获得足够的相关人员的参与和充分的测试，因此针对紧急变更需要采取特别的紧急处理流程。

2.   重大变更

指涉及影响范围较大（影响整个部门、分公司或者社会影响较大）、实施风险较大（实施的失败会带来重大后果）、实施较复杂（例如需要集成开发，多部门协同实施处理）的变更。对于重大变更，建议由变更经理总体负责，通过与各相关方面协同，采取多种手段（例如CAB会议），严格管理其计划实施。

3.   一般变更

指涉及影响范围较小（仅影响个人或小组，不影响业务的运行）、紧急程度较低（不需要立即实施）、实施风险较小（不会带来重大后果）、实施较简单（不需要集成开发，单一部门或个人实施处理）的变更。对于一般变更，建议直接由变更经理指定并授权变更负责人计划执行。往往对于一般变更采用预授权的方式。例如，一台7x20服务的工作组服务器需要补丁升级，服务器的配置项主管(CI Owner)提交需要升级的变更请求，通常该变更主管已经获得了此类变更的预授权，从而可以独立安排时间完成升级，并知会变更协调员和变更经理。

4.   多方变更

鉴于太平洋保险集团的组织机构较多，且对于IT系统的管理也相对较复杂。因此往往可能会需要进行一些跨部门和跨公司的变更。对于此类的多方变更，我们建议通过可以考虑通过变更经理统一调度来协调执行，采纳各方意见并进行统一授权，由统一的变更主管负责；或者通过各变更方的升级机制来协调。对于此类变更，在本流程指南中，建议作为重大变更来处理。

5.   标准变更

标准变更指的是那些相对常见、有着基本固定流程、并且为组织之内广为接受和需要的变更。例如为了可以安装某一通用软件而需要对PC的升级、为新员工的IT系统基本配备等等，其基本的元素为：     

§  广为人知并被验证是成熟的

§  预先的授权

§  通常由服务台提出

§  变更提交人通常已经获得所需的预算要求

其主要的目的是为了提高变更管理的效率而对一些经常发生的、成熟的变更采取预先授权和确定的执行路径。对于标准变更，应针对不同的类型设立相应的标准变更模式以便统一执行。

6.   服务请求（Service Request）

鉴于变更管理的范围了所有对于IT设施的变更，如果对于所有的变更都采用统一的流程，势必会影响效率，服务请求特指那些涉及IT设施的变更，同时又涵盖在企业IT服务台(ServiceDesk)所提供的标准服务内的用户请求。例如，用户通过IT服务台要求更改应用用户密码、为了业务的需要用户要求安装新的企业标准化应用等等。尽管此类请求的满足也涉及变更，但是建议采取预授权给服务台的形式提高管理的效率。

图 4  变更登记与分类

[td]

编号	步骤	输入/触发	描述	输出/完成标准	变更状态	适用性考虑
6.3.1.1	变更请求初步审查	触发: 变更提交人提出的变更请求	变更协调人收到变更请求并判别这是否是合理的变更请求	接收或拒绝请求	已登记	1. 发起人 对于变更的发起人，建议通过机制保证所有的合法变更都可以提交到变更管理流程，但是为了提高效率，可以考虑每个相关部门指定变更提交人员负责收集提交本部门的变更请求 2．变更协调员 对于一个统一运作的IT实体，建议设置统一的变更协调员或协调员组，但是对于某公司目前的分布式运行方式，可以考虑在各实体，例如集团公司、财险、寿险或电子商务部设立独立的变更协调员，负责接收本部门或本公司的IT变更请求。
6.3.1.2	驳回RFC	输入：RFC初步审查	基于预先设定条件或经验，由变更协调员作出判断，对于被驳回的RFC，需要提供理由                   ITSS认证	驳回RFC的理由	已驳回
6.3.1.3	接受RFC	输入：RFC初步审查	变更协调员确认RFC的完整性和信息准确性，如果没有问题，执行 6.3.1.5 如果信息不完整则执行 6.3.1.4	确认完毕	已登记	主要的目的在于避免在处理过程中的信息错误与信息不足，从而导致变更失败或者用户体验的下降。 因此可以考虑采用某些技术手段来确保，例如采用标准模板，标准问题列表(Questionnaire)来保证信息完整性。 对于集中式的IT管理模式，建议设立唯一的变更经理，负责所有变更协调员接受的请求。但是鉴于某公司目前的分布式运行方式，可以考虑在各实体，例如集团公司、财险、寿险或电子商务部设立独立的变更经理，负责本实体内部的变更。对于可能发生的多方变更，可以考虑两种方法： §  确定唯一变更经理协调负责。总而言之，建议每一个变更只有唯一的变更经理。 §  各实体进行变更，当发现涉及多方时，通过升级上报方式向其他涉及方发送RFC，协调实现。
6.3.1.4	协助变更提交人完成RFC	输入：已接收但不完整的RFC	变更协调员与变更提交人协同完成RFC的内容，从而接受RFC（6.3.1.3）	完成 RFC	已登记	过程可能是交互的，该活动可能发生在变更生命周期的任何时候，但是希望尽可能一次性获得所有需要的信息。
6.3.1.5	判断紧急变更	输入：接受的 RFC	如果变更经理认为这是紧急变更的，启动6.3.8 紧急变更流程	判断为紧急流程	已登记
6.3.1.6	预设优先级	输入：非紧急变更	根据经验或事先确定的判断条件来设置RFC优先级，比如：立即、高、中和低	优先级划分完毕	已登记
6.3.1.7	判别变更类型	输入：设置好优先级的变更	根据文档纪录的判断标准决定变更的类型	如果是标准变更，执行步骤6.3.9.1 如果不是标准变更，设定相应的变更负责人	已登记	对于非紧急的变更，分类的目的在于提高效率。特别对于标准变更，建议每个IT管理实体（集团、财、寿）等都制定和维护标准变更模式列表。
6.3.1.8	确认变更主管	输入：非标准变更	根据情况选择和指派变更主管。	确认到变更主管	已登记	特别在涉及多个部门或机制协作的变更时，应该注意选择合适的变更主管，同时亦确定相关各负责人的参与和支持。（例如需要通过软件开发解决应用的某一缺陷时同时涉及开发与系统的部门）
6.3.1.9	授权变更主管	输入：一般变更	对于风险和影响已知的一般变更，变更经理就可以授权该变更给变更主管	如果为一般变更，将其授权给变更主管	已登记
6.3.1.10	是否需要争议处理	输入：被驳回变更	考虑是否需要争议处理，如果需要争议处理，必须获得变更提交人的直线管理者的同意和批复	是否变更请求争议的决定                  ITSS培训	已驳回
6.3.1.11	争议处理	输入：提交的被驳回变更	通过变更经理、变更协调人、发起人与发起人管理者协同争议处理	争议处理结果	已驳回

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

本帖关键字：ITSS

20150829 淡然

续上

2.3.1      变更登记与分类

重要定义：

变更管理的目的是有效的审批和控制对于IT设施变更，从而减少对于业务和用户的影响，以达到提高服务质量和实现服务等级。但是，绝对的控制等同于绝对的没有效率。因此，对于某公司建议确立变更的分类处理以提高变更管理的效率。                             ITSS考试

1.   紧急变更

紧急变更指的是如果不进行变更，会立即或正在严重影响业务运行、导致严重影响服务等级或者带来重大社会影响的变更，紧急变更的实施往往无法获得足够的相关人员的参与和充分的测试，因此针对紧急变更需要采取特别的紧急处理流程。

2.   重大变更

指涉及影响范围较大（影响整个部门、分公司或者社会影响较大）、实施风险较大（实施的失败会带来重大后果）、实施较复杂（例如需要集成开发，多部门协同实施处理）的变更。对于重大变更，建议由变更经理总体负责，通过与各相关方面协同，采取多种手段（例如CAB会议），严格管理其计划实施。

3.   一般变更

指涉及影响范围较小（仅影响个人或小组，不影响业务的运行）、紧急程度较低（不需要立即实施）、实施风险较小（不会带来重大后果）、实施较简单（不需要集成开发，单一部门或个人实施处理）的变更。对于一般变更，建议直接由变更经理指定并授权变更负责人计划执行。往往对于一般变更采用预授权的方式。例如，一台7x20服务的工作组服务器需要补丁升级，服务器的配置项主管(CI Owner)提交需要升级的变更请求，通常该变更主管已经获得了此类变更的预授权，从而可以独立安排时间完成升级，并知会变更协调员和变更经理。

4.   多方变更

鉴于太平洋保险集团的组织机构较多，且对于IT系统的管理也相对较复杂。因此往往可能会需要进行一些跨部门和跨公司的变更。对于此类的多方变更，我们建议通过可以考虑通过变更经理统一调度来协调执行，采纳各方意见并进行统一授权，由统一的变更主管负责；或者通过各变更方的升级机制来协调。对于此类变更，在本流程指南中，建议作为重大变更来处理。

5.   标准变更

标准变更指的是那些相对常见、有着基本固定流程、并且为组织之内广为接受和需要的变更。例如为了可以安装某一通用软件而需要对PC的升级、为新员工的IT系统基本配备等等，其基本的元素为：     

§  广为人知并被验证是成熟的

§  预先的授权

§  通常由服务台提出

§  变更提交人通常已经获得所需的预算要求

其主要的目的是为了提高变更管理的效率而对一些经常发生的、成熟的变更采取预先授权和确定的执行路径。对于标准变更，应针对不同的类型设立相应的标准变更模式以便统一执行。

6.   服务请求（Service Request）

鉴于变更管理的范围了所有对于IT设施的变更，如果对于所有的变更都采用统一的流程，势必会影响效率，服务请求特指那些涉及IT设施的变更，同时又涵盖在企业IT服务台(ServiceDesk)所提供的标准服务内的用户请求。例如，用户通过IT服务台要求更改应用用户密码、为了业务的需要用户要求安装新的企业标准化应用等等。尽管此类请求的满足也涉及变更，但是建议采取预授权给服务台的形式提高管理的效率。

图 4  变更登记与分类

[td]

编号	步骤	输入/触发	描述	输出/完成标准	变更状态	适用性考虑
6.3.1.1	变更请求初步审查	触发: 变更提交人提出的变更请求	变更协调人收到变更请求并判别这是否是合理的变更请求	接收或拒绝请求	已登记	1. 发起人 对于变更的发起人，建议通过机制保证所有的合法变更都可以提交到变更管理流程，但是为了提高效率，可以考虑每个相关部门指定变更提交人员负责收集提交本部门的变更请求 2．变更协调员 对于一个统一运作的IT实体，建议设置统一的变更协调员或协调员组，但是对于某公司目前的分布式运行方式，可以考虑在各实体，例如集团公司、财险、寿险或电子商务部设立独立的变更协调员，负责接收本部门或本公司的IT变更请求。
6.3.1.2	驳回RFC	输入：RFC初步审查	基于预先设定条件或经验，由变更协调员作出判断，对于被驳回的RFC，需要提供理由                   ITSS认证	驳回RFC的理由	已驳回
6.3.1.3	接受RFC	输入：RFC初步审查	变更协调员确认RFC的完整性和信息准确性，如果没有问题，执行 6.3.1.5 如果信息不完整则执行 6.3.1.4	确认完毕	已登记	主要的目的在于避免在处理过程中的信息错误与信息不足，从而导致变更失败或者用户体验的下降。 因此可以考虑采用某些技术手段来确保，例如采用标准模板，标准问题列表(Questionnaire)来保证信息完整性。 对于集中式的IT管理模式，建议设立唯一的变更经理，负责所有变更协调员接受的请求。但是鉴于某公司目前的分布式运行方式，可以考虑在各实体，例如集团公司、财险、寿险或电子商务部设立独立的变更经理，负责本实体内部的变更。对于可能发生的多方变更，可以考虑两种方法： §  确定唯一变更经理协调负责。总而言之，建议每一个变更只有唯一的变更经理。 §  各实体进行变更，当发现涉及多方时，通过升级上报方式向其他涉及方发送RFC，协调实现。
6.3.1.4	协助变更提交人完成RFC	输入：已接收但不完整的RFC	变更协调员与变更提交人协同完成RFC的内容，从而接受RFC（6.3.1.3）	完成 RFC	已登记	过程可能是交互的，该活动可能发生在变更生命周期的任何时候，但是希望尽可能一次性获得所有需要的信息。
6.3.1.5	判断紧急变更	输入：接受的 RFC	如果变更经理认为这是紧急变更的，启动6.3.8 紧急变更流程	判断为紧急流程	已登记
6.3.1.6	预设优先级	输入：非紧急变更	根据经验或事先确定的判断条件来设置RFC优先级，比如：立即、高、中和低	优先级划分完毕	已登记
6.3.1.7	判别变更类型	输入：设置好优先级的变更	根据文档纪录的判断标准决定变更的类型	如果是标准变更，执行步骤6.3.9.1 如果不是标准变更，设定相应的变更负责人	已登记	对于非紧急的变更，分类的目的在于提高效率。特别对于标准变更，建议每个IT管理实体（集团、财、寿）等都制定和维护标准变更模式列表。
6.3.1.8	确认变更主管	输入：非标准变更	根据情况选择和指派变更主管。	确认到变更主管	已登记	特别在涉及多个部门或机制协作的变更时，应该注意选择合适的变更主管，同时亦确定相关各负责人的参与和支持。（例如需要通过软件开发解决应用的某一缺陷时同时涉及开发与系统的部门）
6.3.1.9	授权变更主管	输入：一般变更	对于风险和影响已知的一般变更，变更经理就可以授权该变更给变更主管	如果为一般变更，将其授权给变更主管	已登记
6.3.1.10	是否需要争议处理	输入：被驳回变更	考虑是否需要争议处理，如果需要争议处理，必须获得变更提交人的直线管理者的同意和批复	是否变更请求争议的决定                  ITSS培训	已驳回
6.3.1.11	争议处理	输入：提交的被驳回变更	通过变更经理、变更协调人、发起人与发起人管理者协同争议处理	争议处理结果	已驳回

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

本帖关键字：ITSS