04ITIL 变更管理流程详细设计方案.docx
《04ITIL 变更管理流程详细设计方案.docx》由会员分享，可在线阅读，更多相关《04ITIL 变更管理流程详细设计方案.docx（83页珍藏版）》请在冰点文库上搜索。
04ITIL变更管理流程详细设计方案
1综述
1.1设计目的
本文档是在《公司信息技术管理制度V1.1》基础上，结合公司信息技术部维护管理的特点，制定的变更管理流程详细设计文档。
本文档的目的是：
❑规范所有IT变更，从而保证由于变更而引起的对生产的影响降到最小，提高IT系统和服务的质量，为业务的快速发展提供更优质的IT服务
❑指导与IT变更的相关人员有一套规范的流程去执行变更
❑指导IT管理平台项目的建设
本文档是依据目前公司的信息技术日常运维状况而制定的，以后进一步的更新和优化将由公司信息技术部负责。
1.2适用范围
本文档作为本次项目的变更管理流程详细设计的交付物，读者对象为与变更管理流程相关的所有技术与管理人员。
1.3相关术语
❑ITIL（基础架构库ITInfrastructureLibrary）
是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。
❑服务台（HelpDesk）
服务台从根本上来说是提供了用户和IT部门的唯一接口。
此项功能常通过集中方式提供服务。
服务台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到二线支持等手段帮助用户恢复到正常工作状态。
❑事件管理（IncidentManagement）
ITIL流程之一，事件管理负责解决所有的IT事件、问题和用户请求。
它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。
❑问题管理（ProblemManagement）
ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。
它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。
同时问题管理流程也负责预防事件的发生。
❑配置管理（ConfigurationManagement）
ITIL流程之一，配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。
这些设备和系统被称为配置项（CI）。
每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。
❑配置管理数据库（CMDB-ConfigurationManagementDatabase）
是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。
❑变更管理（ChangeManagement）
ITIL流程之一，变更管理通过控制和管理IT相关的变更，使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。
2变更管理流程设计
2.1流程目的
变更管理流程将通过标准统一的方法和步骤来管理和控制所有对IT生产环境有影响的变更。
主要的目的包括：
❑IT部门可以管理和引导用户变更需求
❑通过对所有变更的正确评估，可以维护IT生产环境的完整性
❑变更和变更实施得到正确记录，并提供审核统计
❑减少或消除由于变更实施准备不当等原因出现的对IT环境的破坏作用
❑提高资源使用率
2.2流程主要内容
变更管理流程始于变更的接收，结束于变更的实施和回顾。
该流程包含下述主要内容：
❑提出变更请求（RFC）、评估、分类
变更申请人提出变更请求（RFC），由变更主管负责检查和完善其内容，通过查询配置管理数据库，进行风险等级的初步评估；并尽量提出可能与业务发生的关联的影响，已供决策参考。
变更主管并对变更进行分类；如为紧急变更，则按照紧急变更子流程执行；如为简单变更，直接制定变更计划，并安排实施。
❑变更主管负责组织制定变更计划、测试
变更主管安排并协调相应资源制定变更计划，包括实施计划、测试计划、回退计划、配置项更新计划等。
应安排对实施计划和回退计划进行测试，随后将测试结果、实施计划、回退计划、配置项更新计划等提交给变更经理审核。
❑变更经理评估、审批
变更经理接受变更请求（RFC），如果确定是紧急变更，则快速完成评估、审批。
对标准变更，确定变更风险等级，审阅变更实施计划、测试报告、回退计划和配置项更新计划，批准或驳回变更申请，如需要更高级别管理层的审批，则根据不同风险级别报批。
❑变更委员会（CAB）/紧急变更委员会（EC）评估、审批
变更经理将根据特定的变更请求成立特定的变更委员会（CAB）/EC，成员包括对该变更的评估和批准提供应有附加价值的技术人员和管理人员，审阅工作包括变更的风险、对现有服务的影响、实施计划、回退计划和配置项更新计划等，并做出批准与否的决定。
如为紧急变更，则快速完成以上评估、审批。
❑管理层审批
对于风险等级为“重大”的变更，在变更委员会审批通过后，必须再由变更经理报请至管理层审批。
❑协调变更实施
变更主管负责协调资源，准备实施前相关工作，组织人员按计划实施变更，变更主管监控实施过程和结果，并在必要时进行协调或做出决定。
在这阶段可能需要变更经理和变更委员会成员的帮助。
❑回顾和关闭
实施变更后，变更主管确保配置项及时得到更新，并协同变更经理负责从技术、管理、业务角度去回顾变更，确保变更请求（RFC）得到了预期效果，并寻找改进机会或行动计划，在回顾过程中可能会需要得到变更委员会中相关领域的技术人员的帮助，随后更新变更记录并关闭变更请求（RFC）。
2.3与其他流程的关系
变更管理流程可以从其他的服务管理流程接收到变更请求（RFC）。
❑和配置管理流程的关系
变更管理涉及到的配置改变应当在配置管理数据库中得到体现，改变的数据可能包括配置项、配置项间的关系或配置项的某些属性；
变更的评估需要从配置管理数据库中获取相关的信息进行分析。
❑和事件管理流程的关系
事件的解决涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变更管理流程来实现，变更成功实施后应当通知事件管理流程。
❑和问题管理流程的关系
问题管理流程中对于错误的修正涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变更管理流程，变更成功实施后应当通知问题管理流程。
2.4关键角色、职责定义
流程的实现是通过不同的流程角色以及其所赋有的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责。
变更管理流程的角色为：
变更请求者、变更主管、变更经理、变更实施人员、变更委员会CAB/紧急变更委员会EC、变更管理流程负责人。
以下描述每个角色的职责。
2.4.1变更请求者
根据工作的需要，发起变更请求的IT人员，主要负责：
❑必要时提出变更申请，创建变更请求（RFC），并提交给相关技术领域的变更主管
❑在变更处理过程中提供必要的信息
技能要求：
❑了解对于所处业务需求与环境
❑了解所处的IT生产环境与组织结构
❑了解IT技术架构从而可以向变更主管、变更经理诠释所提及变更对于运行的影响
人员安排说明：
❑所有IT维护人员
2.4.2变更主管
变更主管通常由与变更请求内容相关的具体技术领域的负责人担任。
可以根据不同的变更种类，分派不同的人员作为变更主管。
对于某些重要变更，还可以将变更主管和变更实施人员合并在一起；变更主管主要关注在实施方案、详细实施计划等方面。
职责：
❑检查由变更申请人提交的每一个变更请求变更请求（RFC），检查变更的正确性和必要性，必要时拒绝无关、无法实施或没有必要的变更请求
❑确定和检查变更请求（RFC）的分类、变更时间要求、分析风险等
❑作为具体变更的项目经理，负责领导变更的构建／测试，实施和参与回顾
❑制定变更实施计划、测试计划、回退计划等
❑针对具体变更请求，评估并分派相应资源
❑确保变更在预定的时间，资源和成本内完成
❑在必要时，确保回退计划（FallbackPlan）得以正确实施
❑负责收集与该变更有关的部门或小组的意见，综合变更对于应用的影响
技能要求：
❑充分了解IT生产环境的结构
❑了解公司组织结构和业务与客户之间的关系
❑较强的技术背景，项目管理技能
❑分析能力
❑以用户为导向、良好的沟通能力
人员安排说明：
❑通常由负责具体技术领域的人担任，如负责ERP系统的人、分公司负责某一分公司系统的人、负责网络方面的人等
2.4.3变更经理
变更经理全面负责变更管理流程中的所有具体活动执行，保障所有变更依照预定流程顺利执行。
通常由具有决策权的人员担任。
职责：
❑帮助变更主管协调必要的变更时间、人员等方面的协调工作
❑审批变更请求，确保只有授权和必要的变更才被实行，并使该种变更影响最小化
❑成立变更委员会，并领导和主持变更委员会（变更委员会）
❑定期召开变更会议，回顾变更
❑参与流程评估，对流程改进提出意见和建议，与流程负责人共同制定流程改进建议
技能要求：
❑在信息技术部门的足够级别（鉴于变更经理的工作职责包括主持变更委员会（CAB）会议、与管理层交互、驳回不合理变更请求以及对于变更流程的运行进行指导等，所以变更经理必须在组织内部拥有足够的权威且受到尊重）
❑决策力和判断力
❑深入了解企业文化
❑项目管理技能
❑有效的会议管理、部门管理和组织能力
❑充分了解IT生产环境、组织结构以及IT服务对业务与客户的影响
❑以用户为导向、良好的沟通能力
❑社交能力和良好的信用，能够与变更流程相关的角色进行有效地交涉和交流
人员安排说明：
❑通常由负责决策权的人担任，一般为部门相关领导
2.4.4变更委员会CAB、紧急变更委员会ECAB（总公司）
变更委员会（ChangeAdvisoryBoard，CAB）是IT组织中对变更进行评估和决策、批准或者拒绝某个变更请求的虚拟组织。
职责：
❑针对具体变更请求，评估潜在影响和风险，并分派相应资源
❑协助变更经理对变更做出审批、决策
❑参加变更委员会会议和紧急变更委员会会议
❑回顾失败或重大的变更，以确保今后不再发生类似情形
❑回顾已执行的重大变更，确保满足变更的目的
❑对流程改进提出意见和建议
技能要求：
❑足够的权威
❑充分了解生产环境结构IT组织结构
❑充分了解公司组织架构和业务与客户的关系
❑技术背景和洞察力
❑分析能力
❑以用户为导向、良好的沟通能力
❑社交能力和良好的信用，能够与变更流程相关的角色进行有效的交涉和交流
❑业务需求的了解
人员安排说明：
❑变更委员会是由总部信息技术中心的管理人员组成的虚拟小组。
主要由各相关领域的领导、各个IT维护小组的资深人员或者组长组成，有时也会包括发起变更请求的业务部门的代表、第三方厂商集成商等参与。
变更委员会应当由该专业有较高技能的人员组成，同时，这些成员对于业务需求、业务逻辑、IT系统技术、应用开发、测试、支持等方面也较为熟悉。
注：
紧急变更委员会通常可以属于变更委员会的一个子集，担当紧急变更委员会（ECAB）的职责。
分公司没有变更委员会，只有总公司有。
2.4.5变更实施人员
变更实施人员负责变更在生产环境中的实施，实际情况下现场厂商经常参与变更实施过程，其责任包括：
❑协助变更主管制定变更实施方案、变更实施计划
❑记录变更实施相关的信息，确保文档的完整性
❑负责实施和测试
❑变更完成后，进行监控，并记录监控结果
❑与变更主管沟通，通报变更实施的进度和结果
技能要求：
❑充分了解生产环境的IT架构，是某一领域的技术专家
❑充分了解公司的组织架构和业务与客户的关系
❑较强的学习、沟通、协调能力
❑分析能力
人员安排说明：
❑由IT部门人员担任，及运维厂商人员
2.4.6变更管理流程负责人
流程负责人通过从宏观上监控流程，来确保变更流程被正确地执行。
当流程不能够适应公司的情况时，流程负责人必须及时对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
职责：
❑确保变更流程能够取得管理层的参与和支持
❑确保变更流程符合公司实际状况和公司IT发展战略
❑总体上管理和监控流程，建立变更流程实施、评估和持续优化机制
❑确保变更流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时对此进行分析、找出缺陷、进行改进（比如增加或合并流程的角色），从而实现可持续提高流程效率
❑保持与其他流程负责人的定期沟通
技能要求：
❑深刻理解变更管理流程
❑能够很好地理解业务对于变更管理的需求
❑对质量控制与保障有很深入的了解
❑有决策权，能够确保变更管理流程设计要求在变更执行中得到贯彻和执行
❑具有良好的沟通技能，能够取得公司高层的支持，获得所需资源
人员安排说明：
❑通常由总公司负责决策权的人担任，一般为部门相关领导
2.4.7实际岗位与方案角色的映射
变更管理流程
角色
角色细分
说明
成员
变更请求者
总公司
职责：
负责受理与总公司应用系统、基础设施等相关的各种变更请求，并发起变更
岗位说明：
由总公司信息技术部技术人员担任，包括总公司服务台人员
分公司
职责：
负责受理与分公司自有应用系统、基础设施等相关的各种变更请求，并发起变更
岗位说明：
各分公司IT部门技术人员担任，包括分公司服务台人员，对应岗位包括分公司信息技术部各技术岗位
变更主管
总公司
基础设施组
职责：
负责总公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的维护变更工作
岗位说明：
由总公司信息技术部门各基础设施领域维护工作的资深技术人员或相关处室处长、副处担任
应用系统组
职责：
负责总公司自有应用系统维护支持工作
岗位说明：
由总公司负责各类应用系统维护变更工作的资深技术人员或相关处室处长、副处担任
桌面组
职责：
负责总公司桌面维护变更工作
岗位说明：
由总公司代理服务处、服务支持处资深技术人员或相关处室处长、副处担任
开发组
职责：
负责总公司应用系统开发、修改、优化工作
岗位说明：
由总公司开发类处室资深开发人员或开发类处室处长、副处担任
分公司
应用系统组
职责：
负责分公司自有应用系统维护变更工作
岗位说明：
由分公司负责各类应用系统维护变更工作的资深技术人员或分管领导担任，对应岗位包括应用管理岗、地市分公司应用管理岗、数据管理岗
基础设施组
职责：
负责分公司基础设施（包括小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件）的维护变更工作
岗位说明：
由分公司信息技术部门各基础设施领域维护工作的资深技术人员或分管领导担任，对应岗位包括设备管理岗、系统管理岗、安全岗、网络管理岗、运行维护岗、地市分公司设备管理岗
桌面组
职责：
负责分公司桌面维护变更工作
岗位说明：
由分公司负责桌面维护工作的资深技术人员或分管领导担任，对应岗位包括服务支持管理岗
开发组
职责：
负责分公司自有应用系统的开发、修改、优化工作
岗位说明：
由分公司资深开发人员或分管领导担任，对应岗位包括应用开发岗
变更实施人
总公司
职责：
负责对总公司应用系统、基础设施、桌面等方面的变更实施工作
岗位说明：
由总公司IT部门技术人员及代维厂商组成
分公司
职责：
负责对分公司自有应用系统、基础设施、桌面等方面的变更实施工作
岗位说明：
由分公司IT部门人员及代维厂商组成
变更经理
总公司
职责：
负责督导与监控总公司变更流程的正常运转，对标准变更进行审批和对重大变更进行上报等
岗位说明：
在总公司设置变更经理1人，由运行管理处处长、副处担任
分公司
职责：
负责督导与监控分公司变更流程的正常运转，对标准变更进行审批和对重大变更进行上报等
岗位说明：
在分公司设置变更经理1人，由分管基础设施方面的信息技术部副总经理担任
变更管理流程负责人
职责：
负责确定管理流程的衡量指标，从宏观上监控流程，当流程不能够适应公司发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高
岗位说明：
在总公司设置变更管理流程负责人1名
说明：
变更主管分组可进行扩充，各分公司可将现有分组提交到总公司，由总公司统一协调配置
2.5执行原则
2.5.1常规原则
❑所有影响生产环境配置项的变更都必须严格遵循变更管理流程
❑所有的变更请求记录都应被记录和追踪
❑所有变更实施过程都应记录在IT服务管理平台
❑应每月产生变更管理报表，对失败的变更和风险等级重大的变更进行回顾和检查，以更好地管理变更流程
❑应半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进变更管理流程
2.5.2流程关联原则
❑和配置管理的关联
Ø在制定变更计划时通过查询配置管理数据库，评估变更可能影响的系统，制定变更计划时需制定配置项更新计划，变更实施完成后需确保配置项信息及时更新，只有配置项更新完成后，才能关闭变更请求单
Ø配置项信息的变更需要通过变更管理流程控制
❑和事件管理的关联
Ø解决事件的过程中涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变更管理流程，如果变更管理流程是由事件管理流程触发，则事件记录必须与变更记录相关联
❑和问题管理的关联
Ø解决问题的过程中涉及到需要对基础架构、应用系统及操作系统等进行变更的需要触发变更管理流程，如果变更管理流程是由问题管理流程触发，则问题记录必须与变更记录相关联
2.5.3变更实施记录原则
❑所有变更实施过程都必须记录在IT服务管理平台，以体现出变更实施中的主要执行环节和执行情况，比如各关键步骤的起始时间、结束时间、执行人、执行结果、异常情况等。
具体记录方式可采用在该变更请求单上增加填写信息项，或新增任务单等其他方式，记录的信息项参见变更实施单信息项定义
2.5.4变更分类执行原则
❑简单变更采用预授权的方式，由变更主管直接安排实施，并通告变更经理
❑标准变更由变更经理总体负责，通过与各相关方面协同，采取多种方式（例如CAB会议），严格管理其计划、测试、评估、审批、实施
❑紧急变更提供变更快速实施处理的机制
2.5.5审批上报原则
❑风险等级为重大的变更必须提前三个工作日提交总公司审批，变更实施结束以后将变更执行结果上报至总公司备案
❑省分公司提出的风险等级为高的变更必须提前上报总公司备案
❑变更委员会负责审批风险等级为高和重大的变更；对于风险等级重大的变更，变更委员会会议建议部门领导参加，对于风险等级高的变更，变更委员会会议建议维护主管参加
❑变更经理负责审批风险等级为中和低的变更
2.5.6所有权原则
❑变更主管负责审核变更请求的有效性和正确性，制定相应的变更计划，并处理各种变更执行时的日程安排和协调，必要时可以得到变更经理的帮助
❑变更经理负责关闭紧急变更，变更主管负责关闭其他变更
❑对于不在变更经理审批权限内的变更，由变更经理负责提交至变更委员会审批
❑对风险等级为重大的变更，在变更委员会审批完成后，由变更经理负责提交至总公司审批
2.5.7变更通知原则
❑对现有业务系统产生影响的变更，例如因实施变更而需要停机或者中止业务，均需在变更执行前提前通知有关人员做好业务调整，减少对业务的影响，待实施完成后再次通告
2.5.8紧急变更处理原则
❑紧急变更必须通过E-MAIL等书面方式申请，但可以口头获得紧急变更委员会（EC）审批，事后必须在IT服务管理平台补变更申请单及相关测试和审批文档，其中变更申请单信息项中必须填写变更实施记录、变更测试记录和变更观察记录，这三项内容即为紧急变更操作日志
❑紧急变更应该制定变更计划，并快速审批和进行必要的评估，实施前需进行必要的测试，测试需包含完整的测试案例，只有测试成功后方可在生产环境进行变更。
对由于紧急变更而无法完成的测试应在实施后安排补测
❑紧急变更委员会（EC）成员一般为公司领导、部门领导，各级主管等管理层人员，为了提高执行效率，需要事先制定紧急变更委员会（EC）的人员
❑紧急变更应越少越好，因为它们对业务的干扰最大，而且有很高的失败风险
2.5.9变更测试原则
❑对生产系统进行变更时，需根据变更的性质、影响面等情况在变更请求单中选择是否需要在测试环境进行测试。
如果需要，则按照测试计划进行测试，测试后需有相关测试人员确认并提供测试报告
2.5.10变更文档控制原则
❑变更计划通常包括实施计划、测试计划、回退计划、配置项更新计划等
❑对应用软件版本上线类的变更，除变更计划外，还需包括变更功能说明文档、变更技术说明文档、包含完整测试用例的测试文档，并提供由执行测试人员确认的测试报告
❑对数据迁移类的变更，除变更计划外，还需包括转换方案，该方案一般包含数据转换策略、数据转换测试、数据备份及恢复方案、数据转换结果核对等方面的内容
❑对总公司要求上报审批的变更，提交的文档具体内容说明如下:
Ø变更总体方案（包括变更原因、变更前后系统拓扑、配置或功能对比、变更总体计划、具体方案、进度安排、人员分工、测试标准、风险评估等）
Ø测试报告（提供系统在变更前的测试范围、测试步骤、测试项目、测试情况等）
Ø变更回退/应急方案
2.6流程相关定义
2.6.1变更信息项
变更单必须包含如下变更信息项：
序号
信息项
是否必填
说明
变更发起时填写－变更发起人
1
实际请求人信息
是
记录实际变更请求人的信息，包括：
姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写）
2
关联的事件单号
否
如果变更来源是事件，则关联到相应的事件单（手工填写）
3
关联的问题单号
否
如果变更来源是问题，则关联到相应的问题单（由变更请求者手工填写）
4
变更来源
是
参见“变更来源”定义
5
变更简要描述
是
简单描述变更请求（手工填写）
6
变更描述
是
详细描述变更的内容（手工填写）
7
变更所属系统类型
是
参见“变更所属系统类型”定义
8
变更分类
是
参见“变更分类”定义
9
变更需求单位
是
两级目录树（省、地市；成员公司、养老金公司）
10
关联配置项
否
记录出现故障的配置项代码（手工填写）
11
附件
否
上传附件
12
分配对象
是
将问题分配到各组变更主管（手工填写）
变更发起时，系统自动填写
13
变更ID
是
为每个变更请求分配一个唯一的序列号（系统自动产生）
14
建单人（受理人）
是
变更请求的记录人
15
登记时间
是
变更请求创建的时间（系统自动产生）
16
变更状态
是
参见“变更状态”定义
检查、测试和计划阶段填写－变更主管
17
风险等级
是
参见“风险等级”定义
18
变更类型
是
参见“变更类型”定义
19
所影响的应用系统、部门
否
实施该变更将对哪些应用、部门产生影响，用于评估变更（手工填写）
20
变更是否中断业务
是
参见“变更是否中断业务“定义
21
变更是否需要测试
是
参见“变更是否需要测试“定义
22
需通知部门
升级会员 