技术变更流程范文

导语：如何才能写好一篇技术变更流程，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。

篇1

一、变更管理的标准流程

商业银行在不断发展中，不可避免地会存在各种各样的变更活动，无论是自行开发的软件版本投产，还是修改供应商提供的软硬件参数，或是改变系统、网络部署模式、搬迁机房等操作，如何对以上各类变更活动进行有效管理？一般情况下，建议通过规范化、标准化变更管理流程的方式，对变更申请、审批、准备、实施等全流程进行精细化管理以减小变更可能引发的生产事件及对业务连续性产生的影响。具体流程如图1所示。（1）变更申请变更申请作为变更流程的第一步，应由需求方向实施方提出正式的变更申请，通常要填写统一的变更申请表并注明申请人、申请时间、详细的变更需求、原因及内容、期望变更完成时间等。对于中高风险变更，需求方还应评估该变更可能产生的影响。最后，变更申请表经由需求方的负责人审核后提交给实施方。（2）变更准备实施方接收到变更申请后，根据变更需求制定详细的实施方案，内容应包括：实施过程的详细步骤、实施完成的验证方案、实施不成功的回退方案等。实施方案应由技术部门负责人进行审批。对于中高风险变更，还应由技术专家对实施方案进行评审后提交给管理人员进行审批。（3）变更实施实施部门应安排有经验的技术人员实施变更，实施人员应严格按照实施方案实施，并保障双人操作，一人实施，一人复核。实施完成后，必须认真审核结果并进行技术验证。（4）变更反馈变更实施完成后，由需求方进行需求验证，验证通过后，应反馈给实施人。对于未成功实施的变更，应及时联系实施人，分析变更失败原因，准备进行下次变更。

对于以上标准流程，还应重点关注以下几点：（1）准确定义变更风险度不同的变更风险引起的关注程度是不一样的，对于高风险变更需要各方面的业务骨干、技术专家，甚至高层领导一同研究实施方案，确认实施步骤。但是对于低风险变更，一个技术人员即可确定如何进行操作。因此，准确定义变更风险度对于提供所需的技术及人力资源极其重要。同时，如果一个高风险变更被定义成了低风险，并未引起大家的足够重视，则可能会引起重大的生产事故。（2）变更实施时间的选择对于有计划的变更，应充分考虑时间安排的合理性，应选择在基本不影响业务的情况下实施，例如一些重要柜面业务系统的变更，为保障不影响正常业务的开展，应选择在周末的夜间进行。对于紧急变更，也应尽可能的在满足时间要求的情况下，选择在对系统影响最小的时候实施，例如在正常工作日要实施紧急变更以解决某个业务系统的bug，此时，应在该业务系统交易量最小的时刻进行操作，以防止由于高峰时段业务的突然中断而产生巨大影响。（3）高度重视变更审批变更审批决定着做不做变更，以及怎样做。在变更申请中，需求的审批应在进行了充分的业务影响分析的情况下完成，以保障变更确实能在风险可控的情况下达到预期目标。在变更准备中，审批者需尽职尽责，严格审核实施方案，以保障实施结果的正确性并保障在产生问题时能及时回馈。对于由方案不完善、不准确这类原因所导致的变更失败等问题，变更审批人员甚至应承担比实施方案制定人员及实施人员更多的责任。（4）紧急变更应参照标准流程执行对于紧急变更，可通过邮件或电话先进行审批，实施完成后可再按照正式流程进行加补申请。但是对于变更方案的制定、实施及反馈仍需按照标准流程进行，并需要有资质的人员进行把关审核，保障紧急变更能以对业务影响程度最小的形式进行。

二、变更管理中应关注的其他方面

1.建立一套全面完善的制度规范体系为提高变更管理的有效性，规范变更的处理流程，合理有效地调配资源，防范变更风险，建立一套广泛适用于全行的变更制度规范体系是不可或缺的。其中，应包括以下强制规定：（1）各个变更相关部门及岗位的职责；（2）变更各个阶段的活动内容及相关要求，并细化到针对不同类型、不同风险程度的变更管理，采用不同流程；（3）变更实施方案的编写要求与具体步骤，比如实施方案中不能含有客户敏感信息，网络类实施方案应精确到指令级等；（4）应明确各种例外情况的处理方法，特别是对紧急变更要给出一套行之有效的流程方案。通常，变更管理作为一个单独完整的制度被提出，但有时可能也与问题管理、事件管理等IT服务共同组成一套体系规范。

2.培训的重要性在变更管理的过程中，加强人员培训是必不可少的关键环节。不论是对制度规范的理解，还是技术水平的提高，都应该有规划、有组织地进行系统化的培训。同时，还应进行安全意识的培训，重点关注变更管理中的安全方面，例如保护客户信息敏感性的重要性，关注生产环境与测试环境的网络隔离、防止变更人员的客户端感染病毒等。

3.对变更的审计为保障变更管理按照制度流程执行的规范性，需要指定专人定期对变更进行审计。审计主要关注以下方面：（1）变更申请、准备、审批、实施、验证、反馈等各环节的合规性；（2）变更实施方案的质量，包括生产变更方案是否细化到指令级，应急方案和回退方案是否具有可操作性，变更内容是否符合变更需求，变更实施方案是否审批到位等；（3）紧急变更流程，重点审计变更实施未经任何形式的审批，也就是未经变更流程实施变更，这种情况极易产生生产事件，对于这种情况，审计程序应先找到发生变更的事实，可通过信息系统日志记录，然后从中去寻找是否有变更申请，是否有未经过变更审批就进行操作实施的不符合项。需要注意的是，变更审计人员应保持独立性，不能执行自己所参与变更的审计任务。此外，变更审计结果应引起各级领导的高度重视并积极加以整改。

篇2

关键词：医院信息系统 信息系统项目变更管理

中图分类号：F062.5　文献标识码：A

文章编号：1004-4914(2011)09-233-01

随着新医疗改革的进行，医院面对的市场竞争日益激烈，各大医院为了降低成本，提高效率，纷纷采用信息技术来加强医院管理，各种医院信息系统项目纷纷上马。但目前医院信息化建设项目管理大致状况是不太遵循项目管理的标准，项目管理水平低下，特别是在医院信息系统项目初期虽能制定详细的项目计划，但在项目实施过程中要么拒绝项目变化，要么随意项目变化，由此带来了医院信息系统项目的变更管理问题。

一、医院信息系统项目变更的原因与形式

1.医院信息系统项目的变更原因。由于医院信息系统项目面临的内外环境不断变化，形成了医院信息系统项目变更的多方面原因，如医院信息系统项目合同内容不完整、客户要求修改工作范围、客户的功能需求改变、项目进度延期或提前、项目预算增加或减少、国家的医疗政策发生改变等等。

2.医院信息系统项目变更的形式。医院信息系统项目的变更形式有三种：项目内容的减少，如项目客户需求变少、如项目范围缩小、项目有的内容不需要等等。项目内容的转换，如项目一部分内容由新的内容取代。项目内容的增加，如项目范围扩大、项目需求增多等等。不论医院信息系统项目变更属于哪种原因与形式，都会对项目的进度、成本、风险、质量和合同等产生影响。

二、医院信息系统项目变更管理的对策

1.事前对医院信息系统项目中的可能变更进行预测。在医院信息系统项目的评估阶段，项目经理可以依据个人的项目管理经验，或公司既往的医院信息系统项目管理成果来对项目中可能出现的变更进行预测，预测主要可以从以下三方面人手：服务提供商可能出现的变更。硬件产品供应商缺货导致的变更。另外，医院信息系统项目组也可以聘请专家对项目可能出现的变更进行评估，对项目变更进行有效的指导。客户在需求方面可能的变更。

2.确定医院信息系统项目的变更流程。客户提出医院信息系统项目变更请求时，项目成员必须向项目经理报告，由项目经理来处理。通常处理项目变更的流程分为以下几步：评估。设立医院信息系统项目变更管理机构。对项目中的变更进行评估，评估内容包括是否属于变更、变更对项目的结果、时间进程、预算的影响等。项目变更在软件上主要是软件内容和技术变更。对硬件来说，市场价格、时间变化是造成项目变更的主要原因；对软件来说，项目变更的主要原因是技术难度、新功能需求等。分析和处理。对医院信息系统项目变更的分析和处理，可根据项目变更对项目影响的大小灵活掌握。对项目影响小的变更，可以不追加费用，但一定要让客户明白我们作了让步，并牺牲了利润。这样做是为了使小的变更不至于影响项目的进展。但对大的变更，医院信息系统项目经理一定要坚持重新谈判、重新审定时间、预算、人力资源的成本。一些软件项目增加功能时，看上去提高了项目的完美度，实际上却不容易完成。在增加功能时，一定要认真评估项目在技术、时间、成本和可操作性上的难度。最好的办法就是把增加的部分从原项目中分离出来单独立项，这样不至于影响到原项目的时间进程和验收、收款工作。规范医院信息系统项目变更的流程。处理医院信息系统项目变更的过程一定要规范。要制作项目变更确认书，由双方合同负责人和项目负责人签字。附在原有合同后面。合同书要写明，涉及项目变更的应以变更书为准。这对按时收款极为有利。项目变更中的时间进程和成本一定要重新核算。并交与客户签字确认。如项目变更中遇到系统扩展或人员调整等情况时，要注意代码管理、文档管理和人员管理等。要加强对软件工程师的管理，提高他们的变更管理意识，改变技术人员轻视成本费用重视技术的习惯。验收时，要由客户重新确认。规范化的流程带来标准化的服务，一且客户认识到这样的好处。最后双方都会感到满意，项目也就能顺利进行。不断总结提高。项目变更的原因、变更的方法和经验教训要及时总结和整理，并把这些资料记录存档，为今后的项目提供参考。

篇3

关键词：运维体系、服务台、事件管理、问题管理、变更管理、管理、配置管理

运行维护方案

1.1 方案设计思路

本方案的设计思路是：按照IT服务管理理论、方法和标准，结合用户实际和建设需要，遵循立足需求、统一规划、保障重点、分步实施、务求实效的原则，建立一套融合组织、制度、流程、人员、技术为一体的IT服务管理体系，建立组织机构，制定规章制度，规范管理流程，明确职责分工，强化技术支撑，使技术团队能够以此为依托，实现对用户应用的综合管理监控和日常技术支持，快速响应和及时解决信息系统运行过程中出现的各种问题和故障，确保用户应用的正常、稳定、高效运行。

建立一个完善的IT服务管理体系，首先需要切合用户需求和用户特点。

本方案运行维护的用户群可归纳为两大类：

 内部用户：包括用户、相关单位等；

 外部用户：进行用户业务办理、查询的单位和个人。

在方案实施时，将进行详细调研，系统整理和规划服务对象类型和数量，制定针对性的服务设计，满足不同用户的服务期望。

维护对象包括机房、网络、主机和服务器、应用软件等。

在需求调研中，需要规划配置管理方案，确定配置属性，梳理配置关系。同时对于不同维护对象，各有技术特点，需要制定针对性的运维技术手册。

运维团队由用户信息中心、（总）集成商、集成商、应用开发商共同组成，可概括为三个服务团队体系：服务台、内部运维团队和外部运维团队。

1.1.1 本项目运维体系设计重点

在本项目运维服务体系设计中，重点投入在服务支持建设上，服务支持描述了所提供的IT 服务日常支持和维护活动相关的过程，是在实现运维支撑平台中最常用到的模块。

服务支持主要功能模块有：服务台与事件管理、问题管理、变更管理、管理、配置管理。

1.1.1.1 服务台与事件管理

服务台是组织机构内为所有IT 用户所提供的单一、集中的联系点，它处理所有事故、查询和请求。它为所有其它服务支持过程提供了一个接口。

事件管理负责管理所有事故从检测和记录到解决和完成的所有内容。事故管理的目标是快速有效地响应最终用户，使它们能够迅速恢复工作，以减小对最终用户的影响。

事件管理涉及主要活动如下：

(1) 事件查明和记录

(2) 分类和初步支持

(3) 调查和诊断

(4) 解决和恢复

(5) 关闭

1.1.1.2 问题管理

问题管理的目标是最小化事故和问题对业务的负面影响。为了达到这个目标，问题管理通过管理所有主要事故和问题来辅助事故管理，问题管理尽力记录所有的工作环境并对相应已知错误进行“快速修补”，并且在可能时产生变更以实施持久的结构性的解决方案。问题管理也对事故和问题进行分析和趋势分析，以预见性的预防进一步事故和问题的发生。

问题管理涉及主要活动如下：

(1) 问题识别、记录和归类

(2) 问题评审

(3) 调查和诊断

(4) 解决和关闭

(5) 已知错误识别和记录

(6) 已知错误分类和评估

(7) 已知错误解决和关闭

1.1.1.3 变更管理

一个单一的集中化的有效和高效地处理变更的变更管理过程，是任何IT 机构成功运营的关键。在变更从启动和记录到过滤、评估、分类、授权、调度、建设、测试、实施以及最终的审核和收尾的整个生命周期中，必须谨慎仔细地对其进行管理。此过程的一个关键成果是前向变更调度（FSC-Forward Schedule of Change），它是基于业务影响和紧急性的所有领域都同意变更的一个中央程序。

变更管理涉及主要活动如下：

(1) 启动、接受和分类

(2) 评估和审批

(3) 安排和分配

(4) 建设

(5) 实施

(6) 关闭

1.1.1.4 管理

管理过程采用了对IT 服务变更的整体全局视野，它考虑的所有技术和非技术方面。管理负责组织机构内所使用的所有硬件和软件的所有法律和合同义务。为了实现此目标并保护IT 资产，管理为定义硬件库（DHS-Definitive Hardware Store）中的硬件和定义软件库（DSL- Definitive Software Library）中的软件建立了一个安全的环境。

管理负责控制版本变更的频度。这涉及到对变更的整合或将变更分拆成更小的版本模块。这些举措基于一系列对业务需求、员工需求（开发、测试、实施、运作）和用户/业务影响的权衡考虑。

管理涉及主要活动如下：

(1) 启动、接受请求

(2) 策略制定

(3) 实施计划制定

(4) 方案审批

(5) 构建测试环境

(6) 实施

(7) 对实施结果测试

(8) 结束

1.1.1.5 配置管理

配置管理提供了成功的IT 服务管理的基础，它支持着所有其它过程。其基础成果是配置管理数据库（CMDB)，在数据库中包含了一个或多个综合数据库详细描述了组织机构中的所有IT 基础设施组件以及其它重要的相关的资产。就是这些资产提供了IT 服务，它们也被称之为配置项（CIs)。CMDB 同普通的资产注册所不同之处在于那些关系、或链接，它们定义了每个配置项（CI）如何互连以及如何同其邻居相互依赖。这些关系允许执行例如影响分析和“如果..将会…”等的活动。理想情况下，CMDB 也包含了同每个CI 相关的所有事故、问题、已知错误和变更的细节。

配置管理涉及主要活动如下：

(1) 登记组成服务的资产信息；

(2) 登记这些资产之间的关系；

(3) 确保配置管理信息库中的各类相关信息能够得以及时更新。

1.2 运维体系设计内容

运维体系设计内容包括：运维组织架构、角色与职责、运维相关流程、运维工作表单、服务度量指标。

1.2.1 运维组织架构

运维组织架构包括涉及运维管理的所有单位、部门、人员的组织信息，用树形层次结构记录，作为运维系统基础数据管理。

为确保整个运维工作的协调运转，建议采用分级管理模式规划运维组织架构，即组建运维服务台，三级运维支持部门协同工作，共同完成运维工作。

建立统一接入的服务台，实行中央控制，分级授权的集中式加分布式的服务台设计。当最终用户提出请求或者需对应用系统进行主动运维时，运维服务台作为呼叫受理反馈部门接受服务请求，并提供一线帮助。对于无法解决的问题，提交二线也即系统运维组处理，运维服务台同时进行跟踪和催办。

系统运维组包括内部运维团队和外部运维团队，作为核心团队负责运行维护和管理工作，针对应用系统进行主动运维，并解决运维服务台转交的请求，在必要时协调供应商、开发商等外部资源。

供应商、开发商作为三线支持，对运维中心提供二线不能解决的问题支持。

采用上述分级管理的工作模式，可以按照运维人员的不同技术能力分配到一、二、三线，实现了运维人员的专业化分工；对于技术要求相对较低的一线可根据工作量的增长及时增加，确保服务呼叫处理率，对于承担核心运维工作的二线人员，避免了初级服务请求的直接处理，保证其对关键应用和紧急故障的处理，可以大大提高运维服务效率和质量；同时，分级管理的工作模式充分发挥不同人员的技术能力，克服了高能低用情况的发生，降低了运维服务总体成本。

1.2.2 角色与职责

本方案运维管理的角色与职责设置，将以ITILV3标准为参考，结合总集成商历年来大量的运维服务实践，针对本项目用户进行设计。所涉及的角色及职责的定义，主要包括服务台、事件管理、问题管理、变更管理、管理、配置管理各个角色和职责。例如，服务台、一线工程师、二线工程师、事件经理、问题经理、问题分析工程师、变更经理、变更咨询委员会、配置管理员等角色。

各类角色在运行维护过程中承担不同的职责，并将在方案实施时根据用户特点进行完善。

1.2.3 运维相关流程

运维相关流程的定义和设计，根据用户的业务需求特点进行定义，主要包括服务台、事件管理、问题管理、变更管理、管理、配置管理、知识管理等流程。

在本方案实施时，将进行运行服务流程设计。主要流程设计工作内容包括：

1、服务台/事件管理流程设计

2、问题管理/知识管理流程设计

3、变更管理流程设计

4、配置管理流程设计

1.2.4 运维文档体系

建立文档体系是进行运行维护服务中持续进行的工作。完善的文档体系有助于维护团队工作持续性，维持稳定的客户服务能力。如运维流程类文档（事件报障信息表单、发起问题信息表单、变更申请表单、管理申请表单、配置信息记录表单等）、服务器、数据库日常维护操作类文档；日常检查模板；日常沟通工作模板、应用流程等等，这类标准化文档的建立，将规范运维管理，改善运维效率。

文档体系的建立并非易事，因此需要从思想上重视并不断更新文档，严格按文档实施操作，要监督文档质量等。

文档体系的建设包括两方面内容：

1、文档体系完善

2、规范梳理和固化

在实际运维中，由于运维活动具有多样性、复杂性，规范的制订往往跟不上运维实际的要求。但结合客户业务需要，有选择地制订关键的运维规范不失为一种有效方法。

定义：这里的规范指运维过程中应该遵循的、客户导向的行为约定。包括操作方法、结果提交方式、运维过程控制点的确认等。以升级为例：故障出现后，故障的等级判断标准，处理时长与升级的关系，升级的途径和相关人等，都受升级规范的约束。

流程的梳理是一个渐进的过程，规范内容也会随用户系统生命周期、运维局势不同而及时调整。对于规范梳理，需关注两方面的内容：

 其一是目前运维中影响较大、问题较多急需明确的流程；

 其二是明确确认规范的主体。

另外和规范相关的接口有客户和项目组，需分别进行梳理，并区分其各自不同的特点。明确责任，合理分工。这部分工作是服务持续改善计划的难点所在。

1.2.5 服务度量指标

制定服务度量指标，对运维系统制定内部和外部服务管理级别，对员工制定员工绩效考核标准。

规划的工作内容如下：

 配合用户技术支持部门梳理所有现有SLA相关资料编制服务目录；

 完善和巩固服务目录，同时加强客户沟通和宣传，让更多客户充分了解服务团队目前提供的服务内容；

 基于ITIL建立标准的服务水平管理流程，规范定义包括服务水平管理计划、客户需求管理、服务水平确定、OLA磋商、UC需求确定、SLA签署、监控和回顾等在内的各项服务水平管理活动；

 建议采用需求调研表和访谈的方式对客户的IT服务需求进行收集、整理和分析，从而确定服务水平需求；

 由客户服务部依据与客户签订的SLAs将相关的具体指标细化为各分相关职能部门的OLA，并与分解相应UC到对应供应商；

 利用工具监控和收集实际的服务水平管理数据，并通过与SLA的比较发现差距生成报告，交由OLA和UC支持团队进行改进；

 建立服务水平协议回顾和检查过程；

篇4

【关键词】核电工程设计；变更技术；变更技术澄清

1前言

核电工程现场设计变更文件是对原设计文件的修改、补充、完善和优化，与施工图纸一样是施工的重要依据。设计变更文件的管理则是极为重要的技术管理工作，是保证工程质量、加强工程管理的重要环节。

2电力工程的设计变更

2．1设计变更分类

长期以来国内电力工程的设计变更管理遵循的是国家电网公司2003年颁发的《电力建设工程施工技术管理导则》中的《设计变更管理》制度。设计变更分为以下三种:(1)小型设计变更。不涉及变更设计原则，不影响质量和安全、经济运行，不影响整洁美观，不增减概(预)算费用的变更事项。由现场设计、建设单位代表签字同意后生效。(2)一般设计变更。工程内容有变化，但还不属于重大设计变更的项目。经建设单位审核后，由设计代表签发设计变更通知书并经建设单位会签后生效。(3)重大设计变更。变更设计原则，变更系统方案，变更主要结构、布置、修改主要尺寸和主要材料以及设备的带环等设计变更项目。由项目部总工程师组织各方充分论证后，设计单位出具设计变更通知书，经建设、监理、施工单位会签后生效。

2．2设计变更管理不足之处

随着建筑业市场经济的建立、设备组合程度的提高和施工技术的发展，这项制度逐渐暴露出了一些不足之处，列举如下:(1)变更分类不科学，界限不清。《设计变更管理》将设计变更的内容按大、中、小原则来划分，即分为:小型设计变更、一般设计变更、重大设计变更。但要界定大、中、小却不是容易的事，如图纸尺寸的差错更正属于小型变更，那么高电压设备的对地距离小了，直接威胁到人身和设备的安全，并将引起一系列的设计变更。(2)《设计变更管理》将设计变更的发起者指的是施工单位或项目工地，实际在施工过程中设计单位本身也会对设计图纸提出变更，该制度缺少这方面的规定。因此有的设计单位将施工单位提出的变更称为“变更设计”，将设计人员提出的变更称为“设计变更”。(3)《设计变更管理》缺少设计变更的处理流程。现场设计变更文件是施工的重要文件，从变更的提出、审批、执行、检查、验收、改图、签证和关闭应有一套严格的管理程序，哪一环节都不能出现问题，这样才能真正避免同类型的不同工程犯同样的错误，才能保证整体工程的质量。

3中广核集团设计变更文件的分类及处理流程

3．1澄清要求

澄清要求(CR)是施工承包商对文件中某些不清楚或不完整或不理解的地方提出的要求澄清的文件，它不需要修改文件/图纸，但设计单位可能针对CR提出的问题答复发DEN或要求施工承包商发TA或FCR。CR由现场设计工程师答复，设计经理批准，抄报业主。

3．2技术变更

技术变更(TA)是施工承包商为适应某些特殊的资源或方法或某些特殊的现场条件而对设计单位/供应商的文件提出的修改。施工承包商提出TA，在TA中写明修改的理由和进行修改的建议，列出所涉及的文件/图纸编号，经施工承包商内部审查后交设计单位批准并报业主备案即可。如业主有不同意见，仍可要求施工承包商停止执行TA。

3．3现场变更申请

现场变更申请(FCR)是施工承包商或业主提出的修改建议。当施工承包商或业主发现现场实际情况不允许完全按照原设计图进行施工时，他们先与设计单位的现场代表协商解决方案，然后由施工承包商提出FCR。

3．4设计改进通知

设计改进通知(DEN)是设计单位给业主和施工承包商发出的通知，表示需要对已宣布生效的施工文件进行修改。

4国家核电变更文件的分类及处理流程

4．1信息请求

信息请求(RFI)回复文件仅仅是技术咨询文件，严格来讲不是设计变更文件，信息请求程序仅被限于问题的澄清。也有可能通过信息请求(RFI)，WEC会发出设计变更文件，但信息请求绝不能代替没有经WEC批准的任何设计变更文件。信息请求(RFI)不适用于由于承包商不遵守设计文件而造成的不符合项(NCR)。

4．2现场变更申请

现场变更申请是施工承包商在现场根据已供使用的设计文件施工时发现图纸与实际有冲突、不符合等情况不允许完全按照原设计文件施工时提出的包含有修改建议的变更申请。一份完整的现场变更请求(FCR)还不是一个可执行的设计文件。现场变更请求(FCR)一旦被批准，负责回复的设计部门必须设计变更申请(EDCR)。施工承包商在收到通过文控中心的已批准的FCR和EDCR后才能进行安装，并要确认所完成的工作符合FCR和其相对应的可使用的EDCR的要求。

4．3设计变更申请

由设计单位对已批准的设计文件提出的变更申请。施工承包商在收到通过文控中心的已批准的EDCR(或带修改图纸)才可进行施工。

4．4设计变更关闭

各类技术文件(图纸、程序、质量计划等)在编制、审查、执行及竣工的各个阶段有不同的状态，即PRE(Preliminary，初步)、CFC(CertifiedForconstruction，施工)、CAE(CertifiedAsExecuted，竣工)、DES(Design，设计)等四种状态。CFC状态的文件由设计单位发出后，经业主向施工承包商发出供使用通知，才能在现场正式使用。一个变更文件关闭的标志是现场执行和文件图纸修改全部结束，改图是变更文件关闭的最后一道工序。改图完成后，要改变图纸的版次。国家核电和中广核集团采用的设计变更程序代表了我国目前核电站建设变更文件管理的二种不同的做法，其共同特点是思路相似，分类科学，表达准确，流程清晰，管理严密，基本满足了现场施工管理的需要。但我们还能看到二者存在着粗细程度的差别。核电站工程建设采用的是与国际接轨的工程管理模式，其现场变更管理具有一定的先进性，可以借鉴。通过以上的归纳、对比和总结，提出亮点建议:一是国家电力建设的主管部门在充分调查研究的基础上，吸收各核电集团设计变更程序的有点，该制定适合国情的新的《设计变更管理》制度，作为指导类文件;二是在常规电力工程建设中，也可以研究并适度采用核电站工程建设的设计变更管理办法。

参考文献:

［1］秦宏伟．浅议核电站设计变更管理［J］．建筑设计管理，2009(7):16～18．

篇5

（一）ITIL简述

1986年英国政府中央计算机和电信局（C—TA，后来并入英国商务部OGC）实施名为“政府信息技术基础设施管理方法论（GITMM）”的研究项目，目标是根据各个行业在IT管理方面的最佳实践中总结归纳出一套规范化的、可量化的IT资源使用的管理方法，以提高IT资源的利用率和服务质量，项目的最终成果就是ITILv1版。OGC将I-TILv1逐渐扩充成为庞大的ITSM方法论知识体系，并于1999年了ITILv2版。2001年英国标准协会（BSI）正式基于ITIL的ITSM英国国家标准BS15000。2005年12月，国际标准化组织（ISO）和国际电工委员会（IEC）正式以BS15000作为蓝本的第一个ITSM国际标准ISO/IEC20000。OGC在整合了v1和v2版的精华并融入了当前ITSM的最佳实践后，于2007年5月正式了ITILv3版。目前应用最成熟的ITILv2版的体系架构如图1所示，包括服务管理、IT服务管理规划和实施、业务管理、应用管理、IT基础设施管理、安全管理等六大模块。服务管理模块是ITIL的核心模块，它把IT管理活动梳理归纳为服务支持和服务提供两组流程及一些辅助流程。服务支持流程组属于基础性的运营级（或称操作级）管理流程，包括一个服务台职能和事件管理、问题管理、配置管理、变更管理、管理5个流程。服务提供流程组属于提高性的战术级管理流程，包括服务级别管理、IT服务财务管理、IT服务持续性管理、可用性管理、能力管理5个流程。

（二）运营级的服务支持流程

服务支持流程主要面向IT基础设施和应用系统，用于规范IT服务的“前端”，负责日常服务工作中对各种故障和问题的处理，侧重于对客户的技术支持和设施维护，目的是使客户有一个稳定运行的IT环境。运营级管理流程把服务台作为与外部联系的单一入口，以配置管理的核心———配置管理数据库（CMDB）为中心把事件管理、问题管理、变更管理及管理作为节点构成一个管理闭环。在ITILv2中，“服务请求”是指IT服务提供者与客户前期已经协商好、需要提供给用户的服务，属于标准操作。“事件”是指在某一服务中不属于标准操作且已经导致或可能导致该项服务中断或服务质量下降的任何事情，它往往是临时发生的，具有突发性。“问题”是指导致一起或多起事件的潜在原因。事件是表征，问题才是本质。事件的发生并不一定就表明IT系统存在问题，而问题也不一定要等事件发生后才能发现。服务台是IT服务管理的核心功能，所有服务支持流程都要通过服务台为客户提供单点联系，接受客户服务请求和故障报告、IT基础设施和应用系统的故障报警，为客户提供一线技术支持，回复客户的相关问题和需求，协调客户与二线或三线支持之间关系，全程监控服务请求和事件处理进展状态并向客户报告。事件管理流程目标是采取应急措施或临时修复方案使被中断或受影响IT服务尽快恢复正常运行，尽量减少对业务的负面影响。它的特点是以尽快解决突发事件为目的，属于“被动”、“治标”行为。若事件反复出现或属于重大事件，则必须提交给问题管理流程。问题管理流程的目标是深入分析问题存在的根本原因，提供有效解决方案解决问题避免类似事件再次发生。实施主动问题管理，在事件发生前发现和解决问题。它具有“预防”、“主动”、“治本”的特点。配置管理处于服务管理的中心位置，CMDB是实施配置管理的基础，CMDB中最基本的信息单元是配置项，包含了IT基础设施、应用系统等IT资源所有精确信息。配置管理通过识别和确认配置项，记录和报告配置项的状态、变更情况、版本信息及配置项之间关系信息，控制配置项访问权限，验证配置项的正确性和完整性等活动为其他管理流程的执行提供支持。变更管理流程使用标准化的变更控制过程处理对IT基础设施和应用系统所做的变更，目标是以对服务最小的干扰实现有益的变更。变更控制过程使用标准的方法和步骤：提出变更请求、评估变更的风险和影响以及业务收益、批准或拒绝变更请求、尽快实施已获批准的变更、验证变更是否已正确实施。管理流程负责对IT基础设施和应用系统的规划、设计、构建、配置、测试，以便为实际运行环境提供一系列的组件，并将新的或变更的组件迁移部署到运行环境中，目标是保证正确的组件被以及运行环境的完整性。变更管理和管理均需要对CMDB的相关配置项进行更新，它们与配置管理是紧密结合的。

（三）战术级的服务提供流程

服务提供流程，主要用于规范IT服务的“后端”，负责定制IT服务，规范IT服务应达到的工作目标、服务水平和服务质量，目的是解决IT服务的规划、设计、实现、持续性问题，并优化IT服务的成本绩效。服务级别管理主要负责与客户协商就所要提供的IT服务的类型和质量水平，签订服务级别协议（SLA），并确保协议得以执行。此外，IT服务提供商还需与内部人员签订运营级别协议（OLA），与外部供应商签订支持合同（UC）。OLA与UC用来支持实现SLA中的服务级别。服务级别管理还监控并报告服务级别，定期进行评审以便改进，确保服务级别协议的更新和持续有效。IT服务财务管理负责为IT服务提供者对所提供的IT服务编制预算和核算服务运营成本，并向客户收取相应服务费用，目标是如何经济节约地提供IT服务，合理平衡服务质量、成本、客户需求三方关系。主要包括预算编制、会计核算和服务计费三个子流程，产生的预算和核算信息可为服务级别管理、IT服务持续性管理、能力管理等流程提供决策依据。IT服务持续性管理负责灾难预防、增强IT基础设施的恢复能力和容错能力，它需要在灾难发生后有足够的技术、资金和管理资源来确保应用系统运行所需的IT基础设施和IT服务在限定时间内得到恢复，保证服务的持续性。能力管理负责在当前和未来的业务需求和运营成本的双重约束下，适时部署相应IT资源，提升服务能力以确保服务品质满足约定的服务级别目标的要求，同时使组织的IT资源发挥最大效能并与运营需求相匹配，主要包括业务能力管理、服务能力管理、资源能力管理三个子流程。可用性管理是通过前瞻性分析客户的可用性需求，使用适当的资源、技术和方法优化IT基础设施和应用系统的可用性，设计适当措施将突发事件发生频率降到最低，从而确保以合理的成本达成服务级别协议的可用性目标。（四）ITIL应用的六大要素实施ITIL需要综合人员、流程、技术三大方面因素，还可进一步细分为六个要素。1.领导力：主管领导的支持，可在资源投入、组织架构整合、部门间协同方面发挥重要作用。负责ITIL运作的执行团队主管和核心骨干能够领导和激励整个团队积极推进工作。2.组织文化：全员参与ITIL培训，培养服务意识，逐渐把“以客户为中心、以流程为导向、提供高质量低成本服务”的ITIL理念变成一种组织文化。3.人员组织包括合理设置职能部门的组织架构、人员的角色和职责及技能要求、人员绩效考核标准等。4.流程是为实现一个特定目标按照既定的方法进行一系列有序活动的过程，一个完整的流程包含目标、范围、输入（处理的对象）、输出（期望的结果）、活动（执行的动作）、角色（流程负责人、流程经理、流程执行人）和职责、关键绩效指标KPI、与其他流程之间接口、激活条件等基本元素。5.工具对于实现ITIL具有非常重要的作用，能够提高服务质量和效率，主要包括IT系统运行监控和诊断优化工具、流程自动化工具两类。监控工具的监控对象是IT基础设施和应用系统，流程化工具是对各项管理流程的电子化实现。6.信息：对ITIL运作中产生和积累的大量信息进行分析，发现潜在问题，持续改进服务质量和提升客户满意度。

二、基于ITIL的电子政务IT运维服务管理体系

运维管理组织架构和角色及职责设置、运维服务管理流程、运维服务支撑系统、运维服务管理对象（IT资源、IT用户、供应商等）、提供的运维服务等五个要件构成了完整的IT运维服务管理体系。在基于ITIL的电子政务IT运维服务管理体系中，IT运维服务提供者与政府客户的IT运维服务管理部门（政府信息化办公室）签署服务级别协议，运维服务团队中各司其职的运维人员通过执行符合ITIL规范的服务管理流程和使用信息化支撑工具为IT用户提供针对电子政务系统（IT资源，包括IT基础设施和应用系统）的运维服务，确保电子政务系统正常稳定、安全可靠、高效经济地运行。根据IT运维服务提供者和政府客户之间是否存在组织上隶属关系，运维服务管理模式有自主模式、完全外包模式和介于前两者之间的混合模式。如果IT运维服务提供者是政府内部IT部门，则属于自主运维；若IT运维服务全部由外部提供商负责，则属于完全外包模式；既有自主也有外包的属于混合模式。我国的政府部门和大多数企业的组织架构一般都是按照职能进行纵向的部门和岗位划分，而在ITIL应用实践却是按照流程进行横向划分，是彻底按照ITIL规范重组还是按照实际情况适度调整，这需要根据运维管理模式、领导支持度等多方面情况综合衡量。这个问题也是ITIL在我国落地应用的难点之一。从IT运维服务提供者的视角看，运维人员在管理流程的角色设置有流程负责人、流程经理、流程执行人。流程负责人对特定的流程负责，权责涵盖了整个流程的生命周期，在流程设计、确定流程目标和关键绩效指标、宏观上监控流程的执行、评估流程实际达到的目标和运行绩效、对流程持续改进优化、与其他流程的协同等方面负起全责，通常由IT运维服务提供者的业务主管担任。流程经理的职责是全程督导、协调和监控流程的执行，确保其正常运转，通常由IT运维服务团队的主管和技术骨干担任。流程执行人的职责是按照既定规范执行预定动作，由具备相应专业技能的运维人员担任，他们可以是来自IT运维服务提供者内部组织，也可以来自软硬件系统供应商、电子政务应用系统开发商和集成商等外部组织。IT运维服务支撑系统是开放式集成软件平台，一方面，把IT运维服务提供者制定的符合ITIL规范的服务管理流程实现信息化处理，可以更高效地向IT用户提供高质量IT运维服务，同时实现对整个IT运维服务的监督、评估和绩效考核；另一方面，支撑系统能够对所有IT资源进行管理和实时运行监控。ITIL是IT服务管理的标准框架，它只告诉我们要做些什么（What），而没有告诉如何去做（How）。要真正实现ITIL在电子政务IT运维服务管理体系的落地，首先必须与客户进行现场访谈，分析现状，并与最佳实践进行差距分析，进而确定合理的目标和达到目标的实施路径，进行人员组织架构、流程、技术支撑系统的规划和设计，上线运行，持续对每个流程和整个体系的运行绩效进行回顾评审，进而优化改进，这个过程不断循环往复。

三、电子政务运维服务管理体系中服务管理流程的具体实现

笔者长期从事电子政务系统运维工作，所在单位是XX市政府电子政务系统的运维外包服务商，逐步分阶段初步构建基于ITILv2的电子政务运维服务管理体系。第一阶段首先实现了服务台职能、事件管理、问题管理、变更管理、配置管理、知识管理和对部分IT基础设施和应用系统的分散监控。第二阶段全部实现了完整的服务支持流程以及运行管理、供应商管理，同时进一步完善、优化、整合管理流程和工具，对重要IT基础设施和核心应用系统实现了集中监控。规划将在第三阶段实现所有的服务提供流程，采用运维服务开放式集成管理平台。笔者曾参与了该外包项目前期规划阶段的客户服务需求捕获、服务管理流程梳理和设计等部分工作，现作为运维团队主管。在不改变原组织架构前提下经单位领导授权，笔者通过角色—职责分配矩阵将原来属于基础设施维护组、应用系统支持组、网络维护组、系统维护组、安全管理支持组等职能部门的人员映射到运维服务管理流程的角色中，并赋予相应责任，同时一些重要角色设置了A、B角。单位分管领导是所有流程的负责人，笔者负责该市政府电子政务系统的日常运维服务管理工作，担任事件管理、问题管理和变更管理的流程经理，同时兼任变更顾问委员会（CAB）副主管，参与重要变更审批工作。XX市政府与作为外包商的单位通过在电子政务运维服务体系中实施ITIL，大大地提高了运维服务水平，客户满意度获得很大提升，同时降低了运营成本，外包商公司也实现商誉大幅增值，实下面从运维外包商视角论述两个关键的服务支持流程的设计实践。

（一）服务台职能/事件管理流程

所有服务支持流程都通过服务台为客户提供单点联系，服务台设值班经理1名，热线人员2名。服务台人员负责记录并受理客户的服务请求、故障报告、咨询、投诉和技术人员定期巡检发现的系统故障以及运行监控系统报警，回复客户的相关问题，进行初级支持，或派单给合适技术人员为客户提供一线支持服务，在事件升级后协调客户与二线或三线支持之间联系，全程监控服务请求和事件处理进展状态并向客户报告。服务台职能与事件管理流程集成在一起。事件管理流程目标是尽快恢复被中断或受影响IT服务，主要执行活动包括：事件的检测识别、记录、分类、优先级排序、初步支持、事件的调查和诊断、事件的解决和恢复以及事件的关闭。事件管理流程概略设计样例如图6所示。事件管理流程运行阶段的角色设置分为：事件经理：由笔者本人担任，负责全程监控和协调每个事件的执行，特别是事件升级、重大事件处理等与流程运行绩效密切相关的活动，确保服务质量，满足与客户约定的要求；对执行人员实施绩效考核；主持重大事件的事后回顾评审会议，参与定期的流程回顾会议，把流程执行中存在的不足和改进建议向事件管理流程负责人报告，以便以后改进优化；定期撰写事件管理分析报告。一线支持人员：包括机房值班人员、部分专业维护组成员，负责日常处理大量相对简单、重复出现的事件和服务请求。二线支持人员：由资深技术专家领衔的专业维护团队组成，负责处理复杂度较高或一线支持无法解决的事件。三线支持人员：由来自软硬件系统供应商、电子政务应用系统开发商和集成商的技术人员担任，负责处理与这些供应商产品或服务相关的事件。

（二）问题管理流程

问题管理流程目标是深入分析导致事件发生的根本原因，提供有效解决方案解决存在的问题，避免类似事件再次发生，或是在事件发生前发现和解决问题。执行的主要活动有：问题的识别、记录、分类、优先级排序，问题的调查和诊断、问题的解决以及问题的关闭等活动。问题管理流程概略设计样例如图7所示。问题管理流程运行阶段的角色设置分为：问题经理：由笔者担任，负责协调问题管理活动的日常执行和流程中的工作调度，将提交来的问题进一步识别、审核和分类，根据问题紧迫性和影响程度确定优先级，根据技能和工作负荷把问题分派给合适的问题专家小组处理，并为其调配必要的资源；监控已分派问题队列，特别关注重大问题和需升级问题；监督流程执行确保遵循相应标准和步骤；对执行人员实施绩效考核；主持重大问题的事后回顾评审会议，参与定期的流程回顾会议，把执行中存在的不足和改进建议向问题管理流程负责人报告，以利改进优化；定期撰写问题管理统计分析报告。问题专家：由资深技术专家领衔的专业维护团队组成，负责问题的调查和诊断，找出问题产生的根本原因，提出解决方案或规避措施并实施。

四、结语

篇6

关键词：电力通信工程；设计质量；作业流程阶段；标准化

一、设计作业内容及流程阶段质量控制

在电力通信工程施工开始之前要经历设计作业流程，这一流程的质量把控直接影响工程项目全局。具体来说，设计作业流程应该包括工程设计管理、施工图设计、设计变更这3大主要作业流程，以下作出一一解读。

1.工程设计管理设计作业流程解读。工程设计管理设计作业流程应该基于PDCA质量环科学方法来进行解读，它特别强调对设计作业过程的计划、执行、检查与纠正，目前在电力通信工程设计中较为常见，以下给出该阶段的设计作业流程质量控制简析。首先电力通信公司会创设项目待上级审批后向社会组织招标投标，然后对投标施工团队进行筛选与合同签订，在确立施工方以后评审合同，并对他们下达设计任务书，编制设计计划，这也是设计阶段（Plan）的主要内容。其次在执行阶段（Do），它的主要流程分为现场勘查、专业设计、内部审查和设计文件出版4大部分。其中现场勘查包括勘查计划的制定与施工现场相关数据勘查，这其中包括地质勘查、建筑环境勘查以及周围环境勘查等等子项目；专业设计阶段则包括了基于现场状况的初步设计和涉及项目全局的施工图设计；内部审查则以两查（施工方审查、监理方审查）和三审（投标方资格预审、投标方资格后审、投标文件符合性审查）来为设计流程奠定基础，最后是设计文件出版，它分为设计文件校对和出版文件检验两方面。在检查阶段（Check）和处理阶段（Action），主要包括以下基于质量控制的设计流程：设计文件交付（设计文件归档）设计审查会设计收口工程回访持续改进。

2.施工图设计作业流程解读。施工图设计作业流程涉及项目整体的所有技术环节，因此要加强该阶段质量管理，做到详细阅读设计计划书，施工图纸，并根据现场勘测队施工设计图进行随时更正，以避免施工开始后质量把控，减少意外事故所造成的二次返工现象出现。3.设计变更作业流程解读。在电力通信工程项目中，设计变更作业一般实施闭环管理方法，它的具体变更内容主要交由设计单位来行使完成，并由监理单位和企业进行流程监督。如果施工图纸有变更需要，电力企业要首先交出设计变更内容申请，由设计单位和监理单位进行共同审核，最后交由施工建设单位审核。这其中如果单项工程设计变更内容累计不大于10万，要在设计单位认可后备案交由建设单位发文作为变更凭证；如果单项工程设计变更内容累计大于10万，则要向企业申请审核批准并发文，审批后将企业发文作为设计变更凭证。最后由施工单位实施已变更设计内容，由建设施工、设计、监理和企业共同进行质量流程监督。

二、设计流程各阶段质量有效控制策略

电力通信工程设计除规范具体设计作业流程外，还要对设计内容进行有效质量控制，下文主要从设计阶段和后期服务阶段两方面展开分析。

1.设计阶段质量控制策略电力通信工程设计阶段要在电力行业领域技术指导及国家质量标准的背景下来完成设计文件，使其起到指导工程建设及实施的重要作用。因此，设计阶段质量控制要做到全面把控，主要围绕组织技术接口、设计过程两大大控制点展开。首先看组织技术接口，考虑到电力通信工程内容设计跨越多专业领域，涉及多部门联合因素，所以在组织与技术实施方面要做到接口多元化，确保设计内容在工程项目中的正确输入。就目前诸多电力通信工程的组织接口设计过程来看，他们通常以图纸会签作为各部门之间的组织接口技术控制手段之一，它实现了施工图纸的全员化审批同意过程，在一定程度上也打下了后期施工质量的有效稳定基础。其次是设计过程，它包括“设计输入——过程转化——设计输出”3大流程，这一过程对说明书、图纸和概预算进行了全面分析，也实现了对工程资料、现场勘查内容的全面整理。作为项目设计中最为关键核心的环节，设计阶段的质量控制主要追求质量合理化和设计控制完全技术化，希望以设计过程质量有效控制提高技术含量和项目决策水平，将项目内容设计具体化。一般来说，电力通信工程项目的设计阶段主要由两部分组成，首先是项目内容设计方案编制，它主要完成了项目设计所涉及全部内容的技术构思，包括多设计方案比对选择，进而明确最终设计内容。另一方面则强调绘制设计图纸与编制工程的概预算分析，根据所需成本来编写设计说明书，选择应用哪种技术流程展开施工，这是质量控制与成本控制融合的过程，它们共同组成了一整套完整的设计文件。

2.后期服务阶段质量控制策略。后期服务阶段主要是对前期设计内容的补正工作，由于受到各种条件变化及技术变化影响，设计图纸可能并不完美，所以必须通过后期服务来加以解决，后期服务质量也决定了工程项目的整体设计质量，应该引起企业及工程项目各方的足够重视。后期服务应该配合工程建设有效展开，所以它基本贯穿于施工、项目试运行、运行以及项目使用阶段。要做好每一阶段内容的设计验证和质量检查工作，随时为工程内容质量改进提出技术参考依据。在施工完毕，项目投入使用的后期服务阶段中，回访工作必不可少。重大电力通信工程项目通过及时有效回访来实现对项目设计建设中问题的补缺，也是企业及建设方对项目成功经验及教训的再学习过程，这不但利于用户，更对电力企业维持稳定高效发展具有利好。因此，电力企业及建设方应该积极接受用户反馈意见，随时做好对项目问题的改进工作准备，同时认真归纳和总结用户意见，以为以后的同类工程项目积累经验，不断精炼技术经验。

3.推行设计质量标准化理念。推行设计质量标准化理念对电力通信工程来说，设计规范规程能够衡量项目设计及其文件内容的素质高低，所以设计质量标准化理念推行也是为了解决工程项目中所存在的设计深度不足、设计表达差错等现实质量问题。电力企业为了全面推行设计质量标准化概念，迎合时展，应该搭建FTP服务器，将电力通信工程项目中所涉及的所有技术规范、标准及相关内容double上传到FTP服务器中，确保企业内员工能够随时浏览学习。该标准化工作作为电力通信工程设计质量管控的基础策略，其建设目的就是为了有效消除行业间技术规范理解差异，解决在项目设计中可能存在的校对及审核矛盾，最大限度降低返工工作量，实现提高工程效率及设计质量控制的目标，从而适应新技术的现实发展及应用过程。

三、结语

电力企业建立科学全面的通信工程设计体系是十分有必要的，它提高了项目设计过程中参与全员的责任心，也形成了针对工程设计的严格和细致把控原则，强大了电力企业在市场中的核心竞争力。但企业也要意识到，工程项目设计质量控制与提高并非一蹴而就的短期目标，它也要经过漫长的质量管理内容调整和科学发展过程，在不断更新设计技术及质量管理实践理论的基础上发展电力通信工程，实现阶梯渐进性提高。

参考文献：

[1]雷晓.电力通信工程设计和质量控制[J].数字化用户,2013(25):13-13.

[2]桂晓明,雍蓉.论电力通信工程设计质量的有效控制[J].中国新通信,2015(18):50-50.

篇7

关键词：电力施工；需求变更；管理策略；控制流程

在电力施工过程中，需求变更的问题是不可避免的，它是通过流程把变更纳入可管理的范围内，避免产生这种混乱，但是如果需求变更的发展失控的话，就会使项目陷入一种混乱且不稳定的状况，从而严重破坏了整个项目的管理过程，如何正确进行需求变更的控制，是一个很重要的管理过程。所以，为了能更好地控制电工管理中的需求变更，我们必须做一些措施来使需求变更有计划的、有目的、更顺畅的进行，从而使电工施工过程进行良好的变更控制。

1 电工施工中引起需求变更的主要因素

在电力施工过程中，引起需求变更的因素有很多，例如增减工程量的清单的内容和工作量，包括施工进度计划的变动，施工程序的改动，质量标注的调整，技术要求的修改和补充，这些都是在电力施工过程中引起需求变更的因素，可以分为：

1、从需求变更的性质来看，引起需求变更的因素分为主观因素和客观因素。

①主观因素。例如电力设计工作的不细致，从而使工程实施过程中发现了很多在设计文件中没有考虑到或估算不准确的工程量，致使必须改变施工项目或增减工程量。

②客观因素。这就是指在电力施工中因为一些自然灾害或不可预见的事故、社会因素引起的停工和工期拖延等，这样的工程变更是不可避免的，也是无法预料到的。

2、从引发需求变更的对象来看，引起需求变更的主要因素

①某些施工单位主动提出工程变更。某些施工单位会向设计单位提出对图纸、设计说明不明确的问题的询问，或是提出技术修改图，对施工方法、施工议案提出修改，或是要求修改图纸等问题，这些都是施工单位主动提出的需求变更。

②由监理单位提出的工程变更。在电力施工过程中监理工程师要经常在施工现场巡视，凭借着他们自身的丰富实践经验，他们往往会发现工程中存在着很多问题，并针对这些问题提出工程变更的建议。

③设计单位提出需求变更。在施工过程中，设计单位或者是其驻工代表对原设计中存在的一些错、漏、缺、碰等问题，提出一些设计的修改和完善。

④由该工程的业主提出的工程变更。为了更好地完善使用功能，从而保证工程的质量、加快工程进度等原因，在施工过程中，业主时常提出一些工程变更的要求。

在电力施工管理中，由于需求变更会引发工程量现场签证、设计、进度的变化、合同变化等问题，我们需要对需求变更进行严格控制，从而将项目变更的影响降低到最小。

2 对需求变更的控制策略

对于在电力施工过程中，对需求变更的控制，如果仅仅按需求加强监督执行是不够的，因为这样的做法会造成项目各方对变更控制的乏力和被动，从而引发工程质量、工程成本等一系列问题的产生，甚至可能使在发展中发生变更失控的现象，这是要绝对避免的。要想在电力施工管理中，使需求变更得到控制，就要确定一个选择、分析和决策的流程，使所有的需求变更都要遵循和支持改流程，从而通过这个流程对需求变更进行控制。但是在遵循这个流程中还需要注意几方面的问题：

1、要有明确的授权。在电力施工管理之前，要事先明确工程各方有权提出变更申请的人员和有权受理变更的人员，决不允许未授权的人员进行私下协商，只有这样做才可以对需求变更有整体的控制。

2、对需求变更进行必要的审核。对电力施工管理中的需求变更不是所有的变更都要执行和立刻执行，审核的目的是决定是否需要变更和何时变更。

3、评估变更的代价和影响。在电力管理中的需求变更都是有代价和影响的，所以在确定变更之前，必须事先评估变更所带来的代价和影响，使工程双方了解了变更的后果之后，再一起做出判断和认可。

4、要严格执行需求变更的管理流程。小的变更也会引起变更最终的不可控制，所以小的变更也要进行正规的需求管理流程，并且施工单位要严格避免在变更确认之前，要按变更设想进行施工，否则可能会造成需求变更的整体失控。

3 需求变更的控制流程

在电力施工管理中，需求变更控制的主要手段是要明确定义流程并且可以严格的执行，主要分为提出、评估和实施的三个步骤。首先，要由授权的人员进行提出需求变更，无论是哪一方提出的需求变更，都要履行工程变更的手续，并以书面形式交给总监。其次，要由总监召集专业的建立工程师来进行审查，认为可行后，设计单位根据业主要求的设计变更进行设计，变更要求必须以书面形式给出，然后设计单位签署意见和设计出图。设计单位完成施工图的设计后，业主需要把图纸给专业的职能部门和审图机构审核，审核通过交还业主，再由业主组织设计、施工、监理各方一起对图纸进行会审，尽可能地把存在的问题提出来，进行研究和探讨，并由设计单位做出解答，形成文字资料后作为日后施工的依据。最后要由总监给出确认后的工程变更通知后，才可以交由施工单位进行执行，按照施工图进行施工。

需求变更实施之前，是要经过工程各方的审核、评估和确认的，在进行电力实施过程中要跟踪与验证，确保变更的正确执行，在变更实施的整个过程中，在没有拿到工程变更通知前任何一个步骤出现异议，整个流程都要重头开始，并且施工单位也不会进行施工，这样是为了确保整个需求变更始终是可以控制和管理的。

4 应注意的问题

目前，很多企业都在遵循质量与健康、安全和环境管理体系的互相补充、相辅相成，在电力施工过程中，他们为了在需求变更中遵循质量、安全和环境管理的一体化，为了更好地实施“ISO9000质量管理体系”和“HES-MS”的管理，他们将“ISO9000-QMS”、“HSE-MS”、“ISO14000-EMS”整合成一个系统，但是在具体操作中会遇到很多问题：

1、对“ISO9000质量管理体系”和“HES-MS”的管理范围必须明确划分，对于它俩的共用文件和资料应按所属管理的范围划分到所属的系统中，对影响二者的的文件应确定与“HES-MS”的接口，制定出明确的管理文件。

2、机构要统一，发挥资源优势。很多企业把质量、安全、环保等职能部门都分开属于不同部门管理，这样日程工作中协调减少了，增加了管理费用，造成了资源的浪费，因此各个部门机构要配备管理人员，从实际出发，健全管理机构。

3、体系要统一，工作重点要有所侧重。针对企业的具体情况，不同性质的企业需要遵循的管理体系是不同的，在电力施工管理过程中，是必须要遵循安全、质量、环境体系的一体化的，从而确保施工过程都有序进行，保障劳动者的安全和健康，实现经济效益、社会效益和环境效益的统一。

5 结论

在电力施工管理过程中的需求变更的发展如果得不到很好的控制，项目就可能会陷入不能正常进行的状态，变更的控制对项目正常有序的施工有着重要的影响，所以，如何正确的进行需求变更的控制，是一个重要的管理过程。定义需求变更是保证变更正常有序的一个有效的措施，并且需求变更流程使得变更施工能够有计划、有目的地进行，也只有这样才能对整个施工过程进行良好的变更控制。

参考文献

[1]范伟健.浅议电力施工管理中的需求变更管理[J].现代企业文化，2010（18）

[2]罗韦军.浅析电力施工管理中的需求变更控制[J].中国电力教育，2006（5）

篇8

交通银行是中国第一家全国性的国有股份制商业银行，也是中国五大主要商业银行之一。随着业务的不断发展、技术不断更新、项目规模不断扩大、开发人员数量不断增加，特别是交行贷记卡及数据大集中项目的开发和上线，使得交行在软件资源控制和生产维护管理上遇到了前所未有的挑战。在项目实施过程中，会使用各种技术、采用不同的程序语言、数据库、中间件等，从而导致种类繁多的文件产生，文件的变化和不同的状态都直接影响了最终产品的和维护。

这已不单纯是技术问题，而是管理的问题。随着软件技术的发展，变更管理越来越成为管理的重点，其中更为注重的是对变更控制流程的强化。交行信息科技部正面临提供更高质量产品以及更短开发生命周期和更简便维护的压力。

寻找症结

为了加强程序版本的管理，交行在项目初期就开始尝试使用操作系统自带的版本管理工具，但随着业务的发展，其功能已不能满足需要。交通银行版本管理的负责人说:“分散在各分行的数据集中到总行数据中心来管理，生产变更的风险比较大。而相对而言，程序变更是生产系统方面最大量的变更。所以，交行要保证全行生产变更的安全，首先要对程序的变更进行有效的管理。”

CA应用开发生命周期管理的观点进入了交行的视野。作为一套全面的解决方案，AllFusion的引入策略非常重要，其应用需要循序渐进地逐步引入才能确保投资能够得到有效的回报。基于对自身情况的科学评估，交行找到对自身影响最大的不成熟点―版本管理―进行改进。交通银行版本管理的负责人认为:“程序版本管理混乱可能会导致项目进度延迟，甚至不能按时完成，频繁的变更以及需求变化，给安全生产的效率和质量都产生了不可估量的后果。”

为了保证贷记卡和数据大集中项目的顺利实施，工程进度紧，管理人员在每批人做完项目之后再做整理，辛苦自不必说，还很难保证质量。通过有效地软件版本管理，不仅可帮助软件开发团队提高软件开发过程的稳定性，而且还保证软件产品具有良好的可维护性和可重用性，为当前形势下要求的快速建立高质量应用提供必要的支撑。

2004年9月，交行正式上马AllFusion Endevor Change Manager变更管理解决方案，对所管理的对象集中受控。需要对受控的对象进行编辑的时候，将对象检出系统，在开发环境中经过修改后再检入到系统中，在检入时系统将比较检入的对象与检出的对象之间是否存在不同。当存在不同时，系统将以一个新的版本号对变更进行标识，所标识的变更将被以增量的方式存储下来。在后续的技术发展中，又在版本主干的基础上增加了分支及归并的支持，以支持对受管理的对象的并发的修改工作。

“银行业务开发需求总是层出不穷，建设版本管理系统的真正挑战就是在不影响生产力的情况下将控制引入应用软件的运维过程。”参与进行交行版本管理系统建设的CA技术顾问郭进说。

另外，还有一个磨合的问题。贷记卡和数据大集中是两个不同的项目，用同一个流程把这两个项目涉及的不同理念、操作习惯、人员等都真正用标准的流程化管理起来，难度可想而知。“2002年交行才使用了大型机，所以我们缺乏这方面的经验，必须从零开始。建立版本变更控制的流程，组织架构、人员配备等要和技术工具相结合，是个新的挑战。”

版本管理自动化

如今，交行的版本管理系统，能够提供检出、检入、分支的创建与分支的归并等功能。通过这些功能，交行实现了对受控对象的变更的历史变更轨迹的记载和变更的控制和管理，同时支持团队的并发工作需求。

第一，有效的安全控制和备份保护机制保护软件资产。之前因缺乏相关工具，交行信息建设的项目出现过一些意想不到的“干扰”，目标程序和源码不能相互对应的情况时有发生，一些运行时间较长的应用都不敢轻易变更的状况。同时抵御风险的能力也大大降低。通过CA的变更管理解决方案，交行可方便地对不同阶段、不同用户的版本进行统一的管理，保障了目标程序和源码的一致性、完整性。

第二，自动化版本管理与管理系统。交通银行通过AllFusion Endevor Change Manager变更管理解决方案，在应用系统的开发、测试和投产过程中，实现了自动化的版本控制，并且能在短时间内提供其它分支机构的任何版本，确保软件产品能够正确地运行在目标机器上面。通过提供全面的安全策略，使得不同的用户只能访问修改不同的环境，进一步保障了数据的安全性。

第三，保证各项目最终更新至生产系统流程的合理性及一致性。在AllFusion Endevor Change Manager的功能中可配合AllFusion Change Manager Enterprise Workbench软件与AllFusion CCC HARVEST集成，实现Mainframe平台的应用系统的变更与相对应的前置系统的应用系统的一致性管理，从而保证各项目最终更新至生产系统流程的合理性及一致性，达到最大的一体性。

篇9

关键词 WCDMA；站址选择；隔离度；初勘；复堪；设计变更

中图分类号TP39 文献标识码A 文章编号 1674-6708（2013）92-0192-03

1背景及范围

WCDMA网络的建设在中国通信市场中是一种新型的应用，由于其网络本身的自干扰特性及功率控制性能要求造成了网络规划的特殊性与复杂性，尤其在无线网络的规划与选址过程中，须充分考虑当地地形、地貌特点及与现有网络的结合；在工程建设过程中须进一步严格站址变更审核、审批流程，确保规划方案的落实，保障网络效果。

1.1站址选择原则

基站选址是网络规划中的一项最重要的基础工作。基站位置的选择，关系到基站能否实现设计要求达到的覆盖、质量指标；对于CDMA等自干扰系统，同时也会影响到本基站和周边基站的容量、数据业务速率，进而影响到整个网络的覆盖、容量、质量指标。因此，基站位置的选择务必谨慎、合理。以下是站址选择的相关要求：

1.2必须保障的选址要求

3）站址周围应比较开阔，50m半径范围内无高层建筑或障碍阻挡；对于定向天线，在天线主瓣覆盖方向100米内应无高于基站天线高度的高大建筑物阻挡；

4）根据设站目的确定站址高度，市区基站天线挂高比周围建筑物平均高度高10m～15m，最少不得少于5m；郊区基站天线挂高根据地形、覆盖要求等确定，一般要比覆盖目标高40m～60m，并在满足技术要求的前提下尽量利用地形减少铁塔高度，降低配套投资；

9） 基站的站址不宜设在易燃、易爆及有腐蚀性物品的仓库和材料堆积场，以及在生产过程中容易发生火灾和爆炸危险的工业、企业附近。

1.4站址选择流程

基站覆盖的目标场所选取应符合联通移动网发展的需求。根据联通的市场与业务发展需求，由设计院编制可研与设计文件，提出工程建设的设计目标，提供基站规划和选址的原则，指导工程的建设实施。联通移动网络建设部门组织网优部、市场部等相关部门，通过投诉资料收集分析、网络摸查、实地调研等工作，筛选和论证建设需求的目标场所。

对于所提出的目标场所，应通过初勘、业主谈判、复堪、施工图纸设计4个主要环节开展设计工作；在方案实施过程中根据需要选择设计变更环节。工作流程如下图所示。

1） 初堪阶段

根据设计目标区域和基站站址、站高要求，在合理区域内选定意向站址，要求有1个主用站址和1～2个备用站址。输出结果为勘查选站单，选站单要包含位置、天线安装方式、天线安装高度、天线方位角和下倾角、周围环境等信息，并尽量附带地图信息（见附件1）。

2）业主谈判阶段

根据初堪选站单和业主进行谈判，优选主用站点。谈判时，要明确机房、天面可以使用区域、是否可以建设楼等增高架等。

3）复堪阶段

根据谈判阶段确定下来的站址，进行详细勘查。复堪阶段要明确机房内所有设备、走线架、馈线窗的位置和安装方式，要明确天线安装方式、高度、方向角、下倾角，并根据复堪结果，能提供详细而准确的施工图纸和材料清单，并对特别事项进行说明（如加固）。

4）施工图纸设计阶段

设计院根据复堪结果绘制施工图纸，图纸要求能反映现场情况并指导施工；设计院提交图纸后，建设单位负责组织建设、优化、维护等部门进行施工图设计会审。会审通过后再提交给施工单位进行施工。

2基站安装及站址变更管理要求

由于WCDMA网无线站址位置的变化会影响到整体网络信号的强度分布、网络干扰等，在工程施工过程中，须严格按照设计图纸规范施工，如因施工现场发生变化，或因业主原因需要对设备、天线等的安装位置、安装方式发生变化，须履行设计变更审批流程。

2.1基站安装及站址变更管理要求

1）设计文件批准后，就具有一定的严肃性，不能随意进行修改和变更；

2）在移动工程施工过程中，设计部门、主要设备厂家应配备常驻现场技术人员，配合工程施工，及时上报设计文件的执行情况；

3）站址变更可由建设单位自行提出，也可由承包单位提出。施工图设计文件交付建设单位使用后，如果出现由于建设单位要求或现场施工条件的变化等原因而引起设计变更，必须办理书面变更手续；

4）在无线基站设备安装工程开工之前，设计人员必须到施工现场进行二次勘察，填写《二次勘察确认单》，对设计位置及工艺要求进行核实，经当地分公司工程主管部门签认后方可开工。如工程现场与施工图纸设计要求不符，须立即通知当地分公司工程主管部门提出设计变更申请；

5）移动网工程设计变更发生后，必须视变更内容所涉及的范围经由相关部门批准同意后方可实施。具体要求如下：

（1）盟（市）分公司在进行无线基站选址及物业谈判过程中，由于业主干扰或其他原因需对站址位置、天线挂高、天线方位角、下倾角进行调整，须按照如下流程处理：

①选定的楼宇、站址变化挪动在1/4站距之内，须由分公司建设主管部门提出设计变更需求，并组织网优、主设备厂家督导及设计人员审核，如移动后的站点位置比较合理，须填写《设计变更现场确认单》，由设计院负责重新勘察出图；

②基站站址位置没有变化，由于现场条件的限制，需对天线挂高、天线方位角、下倾角进行调整，须由当地公司建设主管部门提出设计变更需求，并组织优化、主设备厂家督导及设计人员审核，如不影响网络规划效果，须填写《设计变更现场确认单》，由设计院负责重新勘察出图；

③由于工程设计方案变更，造成配套工程建设投资增加，如追加投资额在批复概算范围之内，额度在5万元之内的，须由分公司建设主管部门填写《设计变更审批单》，并经分公司主管领导确认后实施；

④如属上述范围之外的设计变更，须由分公司建设主管部门填写《设计变更审批单》，并经分公司主管领导审批同意后，通过OA系统“通用流程”报省公司建设主管部门审批。

（2）在工程施工过程中，工程承包单位、主要设备厂家、现场设计人员负责对基站位置及工艺要求进行核实，如遇业主干扰或现场施工条件不符，需对施工设计方案进行变更，须于24小时之内通知分公司建设主管部门发起设计变更需求。分公司组织进行现场查勘后，参照上述（1）决定是否报上级主管部门审批。

5）建设单位和承包单位在提出设计变更要求时，要进行统筹考虑，确定其必要性，同时将设计变更对网络建设效果、工程造价及工期的影响分析清楚，报上级主管部门审批；

6）省公司建设部门对盟（市）分公司上报的设计变更申请进行归口管理，视变更内容所涉及的范围及规模组织有关部门进行审核，并报主管领导批示同意后，进行设计变更。

2.2移动工程站址变更及审批流程图

篇10

关键词：变更管理；版本管理；CMDB；ITIL

中图分类号：TP311.52

二十一世纪全球信息化增速显著，信息系统的地位已经从原先的为了取代纸笔的环保目的，逐步融入到生产生活的方方面面中去，成为新产业的推动力。企业信息化的程度决定着企业在行业中的竞争力水平。高度信息化催生出的对信息系统的高度依赖也给企业的日常生产带来了风险。如何建立一套适合大型企业的应用系统变更管理成为了企业IT部门规划工作中的焦点问题。在实施变更管理的过程中，我们主要关心三点：（1）如何与现有工作流程进行结合，使工作有序高效的持续进行。如果要修改现有流程，怎样才能更科学合理的定义各类用户角色；（2）如何利用CMDB的特点及CMDB中的配置项数据资源来实施变更管理；（3）如何将版本管理和变更管理相互结合。

1 综述

1.1 CMDB。20世纪80年代末，英国政府部门CCTA指定了ITIL（Information Technology Infrastructure Library）。ITIL经历了近四十年的发展，现如今最新的版本3已经相当成熟，它整合了前两个版本的精华[1]，并且扩展内容，融入了IT服务管理领域的最佳实践。ITIL为IT部门提供了科学的框架管理方案，指导IT工作更科学、有效地开展。

ITIL的核心模块是“服务管理”，而这个核心模块又被划分为“服务提供”和“服务支持”，其中配置管理、变更管理、管理、事件管理、问题管理和服务台属于“服务支持”流程。[2]配置管理数据库（Configuration Management Database，简称CMDB）是以配置管理为基础，通过信息技术手段实现变更管理、管理、事件管理等多种功能的信息平台。CMDB在“服务支持”流程中占据着核心地位，也是企业信息工作的核心。ITIL定义了CMDB必须追踪六个方面的内容，硬件、软件、网络通信、工作人员、位置以及文档等等，这些都被称为CMDB的配置项。虽然CMDB名字里有个“数据库”，但它并非传统意义上的数据库。CMDB不仅仅存储了所有的IT元素，还可以存储并以层次结构的方式展示它们之间的相互联系。CMDB的特殊之处在于它必须拥有4个至关重要的功能，即联邦性、协调性、同步性、可视化。只有遵守了这四大原则，CMDB才能实现对IT资产的梳理，减少故障产生几率提高响应时间，有效提高工作效率与用户满意度，更好的理解业务降低新项目的成本[3]。

1.2 变更管理。软件工程中信息系统的需求被定义为用户对应用系统实现的想法及目标要求，通俗的讲就是使用该应用系统或软件最终可以做什么。变更管理可以定义为：合理的收集、整理、筛选需求之后，安排制定开发计划，在开发的项目阶段对需求的满足情况进行跟踪，在代码层面对版本进行管理，保证软件在生命周期内的稳定运行。需求变更管理是ITIL模型的一部分，也是企业IT部门日常工作的核心。需求管理包括：需求控制、需求跟踪、版本管理等。变更管理的目的是控制需求提交、审核、筛选、安排计划等环节，将变更可能对生产造成的影响降到最低。变更管理的目标是高效的控制，快速的响应，科学的安排，可查询可回溯。

1.3 版本管理。在应用系统的开发过程中，多人参与开发、分阶段开发、修正系统错误等等原因，使得代码必须进行反复的修改而非彻底重写，为了节约人力成本缩短系统开发周期，引入了应用系统的版本。版本管理，或版本控制就是在应用系统的声明周期里对上述的应用系统涉及到的不同版本进行管理控制。版本管理是是变更管理的核心。版本管理的核心思想是：科学的定义软件版本号，对不同版本的源代码进行备份，按照计划对软件版本进行升级，遇到突况对版本进行回退。

1.4 SVN与SVNKIT。SVN是Apache软件基金会的一款开源、免费的版本管理软件，SVN支持各种主流的编程语言。SVN由客户端和服务器端两部分组成。用户在服务器端先建立代码库（repository），而后将代码通过客户端的add和commit操作提交到服务器端。用户可以通过客户端的update操作获取最新版本的代码。每个版本的代码都在服务器端留有备份，如果需要回退版本，可以在客户端使用update to revision回退到指定版本。SVN也支持Tag和分支（branch），开发人员可以通过使用SVN实现运维和项目的同时进行。SVN具有集成简单、加密存储、合理利用带宽等特点。

SVNKIT是一种开源、免费的纯java开发工具库，它支持各种操作系统。通过使用SVNKIT可以在自己开发的java应用中实现与SVN客户端相同的各种功能。

2 角色职责定义

为了维持大型企业数量众多的信息系统的稳定运行，明确的角色职责定义是必要的。

2.1 应用负责人的职责为自始至终地负责信息系统项目的立项、开发、运维，来自用户的需求首先将会被提交到应用负责人，由应用负责人进行整理、筛选，并在变更管理系统中登记。参与项目生命周期的全过程。对于信息系统的技术运用及业务需求均有深层次的理解。

2.2 系统开发人员负责对信息系统进行开发。项目开发阶段和运维阶段的开发人员可以由不同人员担任，但都必须对信息系统开发的技术运用有一定的认识。系统开发人员可以自行搭建开发环境部署应用系统。

2.3 开发运维委员会由各节点工作人员组成的开发运维委员会每周召开例会，将应用负责人筛选过的在系统中登记的需求进行优先级排序，并赋予批次号、核对生产计划时间等信息。系统开发人员和应用负责人可以根据批次号展开工作。测试、生产人员可以根据系统中的记录做好工作计划，保证工作的准时、顺利进行。

2.4 代码检查人员对信息系统开发设计的技术有相当的了解，并且会根据企业对于信息系统的编码标准规范对代码、数据库脚本、测试用例等是否符合规范进行检查。

2.5 测试人员负责将开发完成，且已经在开发环境完成测试的应用系统部署到测试环境，在测试环境数据库执行数据库脚本的专职人员。除此之外，测试人员还需要维护测试环境的日常运行，参数调整等等。生产前的各项手续，各类申请验收单据也都是由测试人员保管，是审核流程中的关键节点。

2.6生产人员负责将在测试环境通过各项测试，且手续齐全的应用系统部署到测试环境，在生产环境数据库执行数据库脚本的专职人员。企业内部除生产环境人员以外，无人可以直接接触生产环境。

3 流程设计

应用负责人填写应用系统问题数据及相关的信息，并上传此次变更涉及的代码及文档；开发运维委员会安排变更开发计划，对本次变更赋予变更号；由代码检查人员检查代码是否符合相关规范标准，并给予打分；如检查结果不通过，则退回由开发人员重新修改代码直到检查通过。与此同时，测试人员到测试环境中间件；测试人员根据变更号从SVN上获取对应的代码，编译代码打包部署到测试环境中间件，然后由应用负责人和开发人员进行系统功能测试；在测试通过后且代码检查人员检查通过后，应用负责人提交相关经领导签字确认的验收文档；在确认生产所需停机时间后，由生产人员将应用系统到生产环境中间件，完成后通知应用负责人。如发现生产环境在升级到新版本之后存在问题，可由生产环境人员将生产环境回退到上一个版本，确保生产环境应用的稳定性及可用性。应用负责人进入系统修改对应此次变更的应用系统问题记录的状态，将open状态改为close，并录入生产的日期。

4 系统相关设计实现

系统主要实现了应用负责人录入信息并将本地文件同步到SVN服务器生成记录，开发运维委员会修改记录状态维护记录信息下载SVN服务器上的增量文件，应用负责人最后修改记录状态的功能。即变更从申请提出，到开发测试，直到开发完成、生产、变更申请被关闭的变更管理的整个流程。

4.1 使用SVNKIT的步骤。（1）导入开发所需的SVNKIT类；（2）声明客户端管理类；（3）初始化版本库；（4）设置版本库的访问链接、用户名、密码等参数，用以连接SVN服务器访问代码库；（5）创建客户端管理类实例；（6）进行SVN操作。

4.2 使用SVNKIT实现系统功能。用户创建需求申请时选择或输入的信息，系统统一中间件服务器与SVN服务器上对该应用的标识，根据用户输入或选择的页面控件值获取字符串拼接出中间件服务器的上传文件名，然后转换为对应SVN服务器的版本库路径。

使用SVNKit后，有如下优点：（1）预先设定的目录结构使得代码与文档的管理更科学高效；（2）在每一次执行此功能时首先执行一次删除操作，是为避免上次执行上传操作的过程中删除中间件服务器目录下文件未能完成；（3）以用户每次录入变更申请时自动产生的序号与变更标题组成SVN代码库中的文件夹名，与页面上的申请记录一一对应，一目了然便于管理；（4）系统自动判定文件在SVN服务器端是否已经存在，如果已经存在则进行commit操作，如不存在则先执行add操作再进行commit。

5 结束语

随着时代的发展，科技的进步，信息系统的发展有目共睹。企业规模的大幅提升，业务逻辑的变化催生出越来越多的变更。在这样的情况下，版本管理与变更管理在IT项目中也变得越来越重要，在企业中实施基于SVNKit的变更管理是一个非常具有挑战性的项目。本文根据ITIL的体系规范，结合企业的实际情况，制定合理的流程，编写高效的应用系统，设计并实现了变更管理。此变更管理系统已经在企业IT部门进行日常使用，从两年的使用情况来看，系统大大提升了员工的工作效率及质量，节约了人力成本，有效的提升了IT部门的影响力以及在企业中的作用。这对于致力于建设IT的国内企业具有极大的参考价值。

参考文献：

[1]张述冠.ITIL3.0 一个更趋完美的乌托邦[J].CIO Weekly，2007（26）：41-44.

[2]朱玮.IT服务变更管理设计与实现[J].软件导刊，2013（09）：38-39.

[3]赵成栋.构建统一精准的CMDB[J].软件世界，2006（06）：76.