变更管理流程在目前的ITSS集中交易系统中的状况
本帖最后由monicazhang于2015-11-611:16编辑20151106淡然续上
4.3变更管理流程4.3.1现状描述基于某公司变更及升级管理的现状，可以发现各个业务系统运维组对业务系统的变更，特别是升级可能带来的风险非常重视，建立了一系列受控的方法，如：固定的升级窗口、升级评审机制、升级通知单等，确保减少变更过程中的风险。同时，也发现由于专家组对变更评估过程中缺少明确的评价维度，风险定义模糊不清，在最终需要管理层决策的变更中，缺乏有效的专业支撑，此类问题是变更管理中需要重点关注的。其中，以“集中交易系统”为例，针对变更管理流程的现状如下：
表4‑6集中交易系统变更管理流程现状
编号
内容
现状
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
页:
[1]