5.0变更管理
变更管理是itop里面流程最复杂的一个模块，也是实施ITIL最重要的一个环节，所以这一章会说得相对详细一些，这是针对ITIL的手册，对于简单模式的本手册不用讨论（更简单），大家自行参考官方文档简单变更管理
变更管理涉及到的人很多，相对复杂，对于不了解变更的人，上这套系统还是需要点时间的，本章会分别针对普通变更、紧急变更、计划变更进行说明，对角色的设定、流程的进行讲解。但是作为一个一个用户使用手册并非itop实施手册，部分设计方面的东西不会在这里解释
看完本章，你应该会使用已经配置好的变更管理，我会从使用者身份去分章节来讲解。
先把变更管理的流程图贴到这里，看到相关章节需要理解的回到这个地方查看就好了
5.1 变更管理的角色
变更管理里面的角色有点多，在介绍角色之前先来看看它的生命周期（以普通变更Normal change为例）
可以看到，变更过程有这么多状态（前面是显示名称，后面括号是实际状态值）
New (new)
Validated (validated)
Rejected (rejected)
Assigned (assigned)
Planned and scheduled (plannedscheduled)
Approved (approved)
Not approved (notapproved)
Implemented (implemented)
Monitored (monitored)
Closed (closed)
我们的整个变更过程就是围绕这些状态变化，让相关的角色去执行操作的。
变更的阶段有：变更申请→变更计划和方案制定→变更审批→变更实施→变更回顾及关闭
根据前面的流程图分析，我们后面会讲到这样一些角色
- 变更发起人（任何人）
- 变更实施（实施团队、实施人）
- 变更主管（验证变更内容、拆分、指定团队和负责人）
- 变更经理（对变更内容、计划进行最终审批）
- 变更委员会（一般指紧急变更委员会，进行商议决策）
随后的角色使用手册都会噫NormalChange为例，对于EmergencyChange和RoutineChange进行单独说明。
5.2变更申请
变更申请也就是变更的发起，这个发起人其实是多方面的，有主动的也可能有被动的。通常是由其他系统的需求产生的变更需求。
但是不管需求是怎么来的，轮到你去创建这个变更的时候都是一样的步骤，在变更管理菜单里面找到创建菜单
进入主界面开始填写必要信息：
变更的创建者应该填写的内容其实主要就是变更需求，organization必须是caller所在的组织，title和description没什么好说的，然后parent change只有在是子变更的情况下（通常可能是拆分的）需要填写。
注意，一个生产环境下组织、发起人、父变更等肯定都是通过搜索已有的，不是直接填写或者新建。
一般情况下，创建的人也不会去关联CIs，不过可以考虑关联联系人和相关问题、请求等，根据实际情况确定。
大家可能注意到了主题区第一行有 cancel 、Create、validate、reject，为什么呢，这个在开始的时候说了，变更的这些东西都是围绕状态来的，现在是刚创建，相当于状态是New，这个可以在数据模型里面的生命周期看到。当然了这个还有权限问题，如果没有权限进行validate的是看不到的，正常应该就两个按钮， cancel和Create。
如果作为普通用户点击Create创建完成就算完成了，等待流程走向变更主管；如果是变更主管以上的人自己创建，这里可以直接进行validate，不过不推荐如此操作。
变更被创建以后就完成了申请任务，下一步会由变更主管（分析处理）进行确认拆分等工作。
5.3.1变更主管对变更进行确认
变更创建以后就应该通知到变更主管团队，负责对变更进行确认，按理说这里应该有一个变更咨询委员会（CAB）讨论变更的具体方案。
注意我们这里说的是Normal change，所以有这个步骤，emergency change是没有validate这个步骤的。
确认后会分配给对应的处理团队（主管团队）
这个地方有三个团队需要选择。
Team：负责实施变更的团队，里面包含变更实施者
Supervisor team：变更主管团队，负责指派具体的实施者，并对变更负责，监督整个变更过程。
Manager team：变更经理团队，负责变更的管理监督，对变更进行审批，通常是对于部门的经理，当变更方案和回退计划做好了后会交给审批团队。
如图，会有确定的团队名称、时间、以及确认的结果。
5.3.2 变更主管团队进行实施者分配
一旦变更状态变为 validated就意味着现在这个变更生效了，要开始干活了,应当设置提醒，这个时候通知到变更主管团队进行人员指派。
这个过程非常简单，通常在人少的团队这个是由实施团队内部的人进行分配的，在成熟的团队里面是由团队主管进行分配的。
angent就是实施者，要负责做计划和实施变更
Supervisor是主管，也是本次变更的主要负责人
manager是变更经理，本次变更的最高受意领导
到这里，我们只能选择上一步validated指定的团队内的人了，不能选择团队之外的人，如果有疑问需要让有权限的人修改之前指定的团队角色。
一旦Assign，流程就会走到具体的实施者那里，进行方案设计、回退计划
变更的实施者会经历两个阶段，计划和实施，一般来说计划好了需要经过经理审批，然后才开始实施
5.4.1 变更计划的制定
当变更分配给实施者后，实施者就应该开始做变更计划和回退计划了,一个完整的变更计划和严谨的回退方案是很有必要的。
对于领导来说，更关心的是业务的中断、持续时间、回退是否可靠。
虽然这个Plan界面就这么多东西，不过这里你可以做详细的方案附件说明，可以调整相关联的CI看是否正确，和主管进行沟通确定实施方案
impact：说明主要影响是什么
outage：是否会中断业务
fallback plan：回退办法和应急方案
startdata/enddata：计划的实施时间
一定要说清楚，不要让审批者迷惑，无法作出判断
这个步骤的状态会变为plannedscheduled
5.4.2 变更的实施和回顾
作为变更实施者，当变更经理审批通过了你的方案后就需要开始准备实施，
实施的线上操作非常简单了
我们只需要按照计划进行一步一步操作就可以了实施完成后点击
，点完后状态会变为implemented
然后我们安排回顾检查，进入monitor环境
这个环节可以是实施者自己操作，也可以由变更主管团队的人进行。
这里需要提醒的是：一定是做了相关操作才点击这两个按钮，不要什么都做完了一次点完，这样系统记录的时间和步骤就没有太大意义了。我们依赖系统的前提是要按照它的游戏规则来玩。
5.5 变更审批操作
变更经理的职责其实远不止审批这么简单，虽然只需要点一下审批流程就可以过了。
右上角的Actions菜的那可以供变更经理选择的有approve和 reject approval，如果觉得方案没有问题，或者沟通后觉得ok的，一般来说就直接approve了；但是如果需要重新修改方案的，这里可以reject，不管选择哪个，下一步都会回到实施者手里；不管选择什么我们都会需要填写审批意见
重要的变更，作为变更经理一般在前期就会参与到变更的讨论中去，事先必须知道这次变更的主要内容，审批只是对变更计划的一次最终审核，看是否严谨是否和预先讨论的相符合，回退计划是否做得到位，影响是否判断准确。
变更经理会承担重大事故的管理责任，所以在变更的审批中拥有重要的作用，通常来说，不同的变更项目可能会是不同的变更经理来审批，这个在变更主管进行变更确认的时候就要选好。
文章评论
博主，最近我研究了itop的功能。发现，cmdb功能配置想很详细，但是变更流程和cmdb整合似乎很弱。就是想发起关联一个配置项项配置具体变更，只能变更流程提单，然而并没有办法预设详细变更内容、关联，实施人只是实施后，再去手工变更cmdb。。。这个也太弱了吧。。。
@lamda 是的，你说的这个问题是现在所有cmdb的通病，所谓的cmdb3.0只能到这个程度，所有的变更都是人工干预的，少量自动化的只是在事件管理这块，比如通过监控日志分析等进行事件的录入。目前行业里面正在发展的cmdb4.0就是为了解决这个问题，引入AI/develops来实现自动配置和修正。
就目前而言，我们可以做的是有针对性的实现半自动化。
能否提供流程图，文中的图不够清晰，谢谢。purple1229@hotmail.com
@qryz 博客中的应该算可以的了吧，我回头看看有没有完善后的版本，更新一个高清版本的。
请教下如果审批有好几层的需求怎么办？比如经理→科长→部长→总经理
二次开发的话有什么好的建议呢
@kirin Itop的核心是cmdb，所以在审批流程方面很弱，可以说，没有流程（单步流程）。当然了，如果你的逐级审批是没有其他条件的，我们也可以在上面做一点二开实现；但是，但是，我强烈不推荐这样做，因为大部分情况下，涉及到多级审批的一定会有各种条件，会有复杂的流程演变，所以，我脱机把这些审批（多数是申请权限类）做到我们拥有流程引擎的系统里面去，比如OA系统。itop的三方接口是标准的rest API ，操作起来非常方便。
这个地方可以进行测试：https://jsfiddle.net/pgoiffon/8fs67agL/
有什么问题可以继续留言。