20151106 淡然

续上

4.3   变更管理流程4.3.1                现状描述

基于某公司变更及升级管理的现状，可以发现各个业务系统运维组对业务系统的变更，特别是升级可能带来的风险非常重视，建立了一系列受控的方法，如：固定的升级窗口、升级评审机制、升级通知单等，确保减少变更过程中的风险。同时，也发现由于专家组对变更评估过程中缺少明确的评价维度，风险定义模糊不清，在最终需要管理层决策的变更中，缺乏有效的专业支撑，此类问题是变更管理中需要重点关注的。其中，以“集中交易系统”为例，针对变更管理流程的现状如下：

表 4‑6 集中交易系统变更管理流程现状

[td]

编号	内容	现状
1	流程认知	·           目前，对于系统升级类变更十分重视，需要实现提交变更申请，并在每周三下午变更评审会上通过评审后，周五的变更窗口才能执行该变更。                  ITSS考试
2	流程操作	·           在“创建变更并分类分级”活动中： 1.   由于“标准变更列表”中种类少（包括：权限、报盘参数的增、删、改等），业务系统管理员即使是标准变更的情况下，也选择了非标准变更，如：ID-CH-20140221-00002； 2.   不关联由变更导致的事件情况。 ·           在“制定变更方案”和“确认测试结果”活动中： 1.   没有明确的方案提供标准，方案中的组成部分无强制要求，当变更通过时，即使缺少如“回退方案”等，也无需事后补单； 2.   测试结果的验证也仅通过检查主要业务的方式进行，无明确的验证标准。 ·           在“变更执行”活动中： 1.   可以通过分发任务单的方式分别执行，但更多是管理员个人为主，其他资源辅助的方式进行； 2.   为标准化操作建立了，如：upliso、upappso、upconf等自动化执行脚本，规范升级过程； 3.   变更执行中，回退的情况少，目前仅1起，由于没有特别的关单代码，业务系统管理员也无法回溯具体工单号。
3	流程平台	·           业务人员在发起业务变更时，使用BPM平台，ITSM平台和BPM平台的数据不同步，导致变更较难完整统计；                               ITSS认证 ·           ITSM系统可以帮助业务系统管理员初步判断上下游影响的其他关联系统，业务系统管理员据此联系相关系统负责人， 通知变更情况。

根据某公司运营中心的管理要求，我们分析了自2013年7月至2014年6月，一年间的故障-变更对比记录。试图了解变更执行对于事后故障发生的影响，具体数据如下：

图 4.13升级与对应故障统计

图 4.14升级与对应故障统计（续）                               ITSS培训

虽然在升级与对应故障统计中看到，升级之后7天内发生故障的比例占到近6成，但由于在ITSM中并没有直接关联升级及对应的故障，无法明确判断升级与故障的内在联系，仅能从发生时间上进行统计，这对于分析变更风险，统计关联故障的实际帮助意义不大。

待续http://www.ITILxf.com/thread-52999-1-1.html

本帖关键字：ITSS

展开全部

微信扫一扫，阅读更方便^_^

20151106 淡然

续上

4.3   变更管理流程4.3.1                现状描述

基于某公司变更及升级管理的现状，可以发现各个业务系统运维组对业务系统的变更，特别是升级可能带来的风险非常重视，建立了一系列受控的方法，如：固定的升级窗口、升级评审机制、升级通知单等，确保减少变更过程中的风险。同时，也发现由于专家组对变更评估过程中缺少明确的评价维度，风险定义模糊不清，在最终需要管理层决策的变更中，缺乏有效的专业支撑，此类问题是变更管理中需要重点关注的。其中，以“集中交易系统”为例，针对变更管理流程的现状如下：

表 4‑6 集中交易系统变更管理流程现状

[td]

编号	内容	现状
1	流程认知	·           目前，对于系统升级类变更十分重视，需要实现提交变更申请，并在每周三下午变更评审会上通过评审后，周五的变更窗口才能执行该变更。                  ITSS考试
2	流程操作	·           在“创建变更并分类分级”活动中： 1.   由于“标准变更列表”中种类少（包括：权限、报盘参数的增、删、改等），业务系统管理员即使是标准变更的情况下，也选择了非标准变更，如：ID-CH-20140221-00002； 2.   不关联由变更导致的事件情况。 ·           在“制定变更方案”和“确认测试结果”活动中： 1.   没有明确的方案提供标准，方案中的组成部分无强制要求，当变更通过时，即使缺少如“回退方案”等，也无需事后补单； 2.   测试结果的验证也仅通过检查主要业务的方式进行，无明确的验证标准。 ·           在“变更执行”活动中： 1.   可以通过分发任务单的方式分别执行，但更多是管理员个人为主，其他资源辅助的方式进行； 2.   为标准化操作建立了，如：upliso、upappso、upconf等自动化执行脚本，规范升级过程； 3.   变更执行中，回退的情况少，目前仅1起，由于没有特别的关单代码，业务系统管理员也无法回溯具体工单号。
3	流程平台	·           业务人员在发起业务变更时，使用BPM平台，ITSM平台和BPM平台的数据不同步，导致变更较难完整统计；                               ITSS认证 ·           ITSM系统可以帮助业务系统管理员初步判断上下游影响的其他关联系统，业务系统管理员据此联系相关系统负责人， 通知变更情况。

根据某公司运营中心的管理要求，我们分析了自2013年7月至2014年6月，一年间的故障-变更对比记录。试图了解变更执行对于事后故障发生的影响，具体数据如下：

图 4.13升级与对应故障统计

图 4.14升级与对应故障统计（续）                               ITSS培训

虽然在升级与对应故障统计中看到，升级之后7天内发生故障的比例占到近6成，但由于在ITSM中并没有直接关联升级及对应的故障，无法明确判断升级与故障的内在联系，仅能从发生时间上进行统计，这对于分析变更风险，统计关联故障的实际帮助意义不大。

待续http://www.ITILxf.com/thread-52999-1-1.html

本帖关键字：ITSS

展开全部

微信扫一扫，阅读更方便^_^