技术变更流程

前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇技术变更流程范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。

技术变更流程范文第1篇

[关键词] 商业银行；IT变更管理；信息化

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2014 . 03. 016

[中图分类号] F830.33；TP315 [文献标识码] A [文章编号] 1673 - 0194（2014）03- 0030- 04

1 概 述

IT变更管理信息化是针对IT项目生存周期中的变更进行管理的过程，而商业银行IT变更管理（以下简称“商业银行变更管理”、“变更管理”）信息化是针对商业银行要求系统稳定性高、风险可控性高、数据安全性高以及业务影响小（“三高一小”）的特点，将程序和数据变更的管理过程通过信息系统实现信息化、自动化的过程。通过变更管理信息化建设可以有效减少因硬软件问题造成业务中断，降低操作风险[1]，实现变更管理自动化，全程可控可回退。

目前主要针对管理信息化和变更管理两方面的研究较多，但对变更管理信息化，尤其是商业银行IT变更管理信息化方面的研究较少。由于商业银行变更管理对业务系统稳定性要求高，商业银行组织结构复杂，随着业务发展各项规章制度调整频繁，信息系统多样，数据管理和共享要求多，信息化需求较多，我们需有针对性地研究其信息化方法，以变更操作信息化、自动化为核心，研究其所需方法、规划、架构和技术。

商业银行变更管理信息化应覆盖现有变更流程及要素，基于业务连续性及系统稳定性要求，达到变更全流程可回退、可控、可验证，对变更后系统运行情况可跟踪、可验证、可评价，对系统变更的原因、方法、效果、问题可记录、可搜索、可挖掘，建立专家知识库系统，及时响应变更流程及变更要素变化，建立快速响应与持续开发运维机制。本文结合商业银行IT变更特点，对商业银行变更管理信息化建设过程进行了研究，对层次设计、开发模式、团队架构、技术实现等方面进行探讨，并在大型商业银行进行实践。

2 变更管理

2.1 组织结构

商业银行变更管理的组织结构涉及科技管理部门、应用开发部门、应用保障部门、运维部门以及业务部门等多个部门（见图1），科技管理部门负责制定变更评审管理制度，组织协调变更评审工作开展，制定与变更评审报告；应用开发部门负责项目研发、程序数据修改与测试、变更申请、变更资源准备与变更文档填写；应用保障部门负责安全措施等进行评审，根据评审结果对变更进行审批以及特护管理；运维部门负责制订变更实施计划，变更实施，对变更实施结果进行；业务部门负责组织实施业务验证。

2.2 管理流程

商业银行系统变更过程要进行安全审查，采取风险控制措施[2]，变更管理流程以变更评审为核心，包括变更申请、变更受理、变更评审、变更实施、变更验证、变更回顾6个环节（见图2），应用开发部门、应用保障部门和运维部门对应用系统程序、数据和资源发出变更申请，并准备程序、数据、硬件设施等变更资源以及测试报告、风险分析报告、投产变更实施方案、应急方案等变更文档；应用保障部门承担变更评审受理工作并分配变更评审任务，变更评审人员对变更进行评审准备；变更评审由评审团队通过召开会议的方式进行，会议对变更合规性、风险性等方面进行审查，评审团队一般由来自应用开发部门、应用保障部门、运维部门的技术专家组成；变更实施一般由商业银行运维部门（如数据中心）承担，通过变更评审批准的变更方能授权进行实施，实施部门根据评审意见与实施方案制订完备的实施计划并对变更进行实施；变更实施完成之后，由业务部门和运维部门按照验证计划实施验证，对验证结果进行反馈，对不符合验证计划要求的变更进行回退；科技管理部门对变更评审与实施情况进行分析，并定期以报告的形式在相关部门进行，使管理层和变更人员及时了解当前变更评审、实施和运行情况。

3.2 开发模式

商业银行由于业务多样性、分行特色、历史存续问题等造成系统类型的多样性，针对不同系统的变更方法多样，为适应业务发展，稳定性要求也在不断演变。商业银行变更类型包括程序变更、数据变更、硬件变更、架构变更、业务流程变更等方面，造成需求范围边界界定困难。鉴于此，需要对变更管理信息化系统进行充分设计，采用原型化方法进行系统建模，系统建设者与变更制度制定者、变更执行者不断调整原型各要素使其更贴近真实场景，各方试用后进入下一步开发。

针对建设周期大于变更制度变化周期的特点，应在开发模式中应用敏捷开发的模式。规划建设周期数、各建设周期下的建设任务及各任务的优先级，划分敏捷开发模式的迭代维度及频度。变更信息化系统规划的初期利用关键成功要素法（Critical Success Factors，CSF），通过变更失败或成功的原因分析，识别变更信息化的关键要素，确定系统开发任务的优先顺序。再利用目标集转移法（Strategy Set Transformation，SST），识别变更管理的战略集。首先描绘变更组织中的各类实体结构（如变更申请人、柜员、一般员工、变更评审专家、变更评审责任人、变更实施人、变更验证经理、变更决策人），其次识别每类变更角色的目标，最后对于每类变更角色识别其使命及战略。最终利用业务系统规划法（Business System Planning ，BSP）校核两个目标，提出建议书与开发计划。主要环节为调研变更需求、识别变更流程、变更流程重组、定义变更数据类、定义变更信息系统逻辑结构、确定变更信息系统总体结构中的优先顺序、变更各子系统按先后顺序排出开发计划、划分敏捷开发模式的迭代维度及频度。

3.3 团队架构

团队架构要确定参与系统建设人与角色，在商业银行变更管理信息化的组织结构中，强调以变更责任人为核心，变更制度制定者、变更管理流程执行者、信息化系统建设者全程介入开发及持续运维各阶段的组织结构模式（见图4）。商业银行IT变更管理信息化项目一般规模较大，按照项目规模及迭代维度，建立多团队敏捷开发组织框架，每个团队安排领域产品负责人（APO）[4] ，此外商业银行各系统运行环境复杂多样，其变更自动化，有较强的技术难度，往往构成系统开发的关键路径，所以需组成公共控件组先行研究相应的技术解决手段。

3.4 技术实现

在技术实现时，首先研究低耦合、高内聚功能模块集，需划分变更管理信息化模块及功能最小集合，以完成信息系统逻辑结构定义。因变更管理很重要一环是对变更流程管理，故需工作流程管理模块；变更管理涉及复杂人员组织体系，故需人员机构模块；变更管理是针对系统应用或数据作出变更，故需应用系统模块；变更管理需对变更实施后业务影响验证及评价，故需业务数据监控模块；变更管理需对相关变更场景进行比对检索过程，故需知识专家库模块；变更管理需对应用进行自动部署回退等，故需变更自动化工具模块。

其次针对各模块可能遇到的技术瓶颈、所需公共控件，由公共控件组研究相应的技术解决手段。变更管理涉及复杂的文档管理过程，需要建立文档解析引擎及文件传输控制引擎；变更操作及验证涉及向服务器发送及解析信令的过程，需要建立远程主机通信自动解析调用引擎；数据变更的自动化，需要建立数据库规则语义检查与调度管理引擎，以完成数据变更的安全检查、自动备份、执行、回退；程序变更流程自动化，需要建立应用服务器自动引擎，以完成程序变更的自动备份、、回退；这些技术模块与引擎共同构成变更管理信息化的技术要素，通过不同的组合和应用，为变更管理各组应用场景提供技术支撑。

4 实 践

A银行是一家国有大型商业银行，近年来随着各项业务量迅猛增长，变更管理工作日益繁杂。为进一步提高变更保障能力和变更管理工作信息化水平，规范变更管理工作流程，从变更管理实际工作出发，结合变更管理未来发展需要，特开发变更管理系统（简称S系统），整合变更管理各个环节。该系统累计投入人力超过187人月，建设工期近一年，采用原型法加敏捷开发模式，以变更评审人为核心，实现变更操作自动化、变更管理流程信息化、变更验证自动化、专家知识库等功能模块。

通过对变更信息化平台应用实践，A银行弥补了变更申请、变更评审、变更实施在严肃性、合规性和流程性上的不足，有效防控了投产变更风险，提高了变更执行成功率，为A银行在科技风险管理与防控方面作出了重要贡献。以2012年为例，日均用户1 200余人次，执行变更2 157个，变更执行成功率持续提高，变更异常率同比降低50%，目前A银行在总行层面的变更管理信息化程度相对较高，后期将在一级分行逐步进行推广执行。

5 总 结

本文就商业银行IT变更管理信息化建设体系进行了研究，提出了信息化方法，并在大型国有商业银行进行了初步实践。本文所提出的方法其应用范围还有待进一步扩大，其通用性、规模性还有待加强。

主要参考文献

[1]中国银行业监督管理委员会.商业银行信息科技风险管理指引[Z].2012.

[2]中国银行业监督管理委员会.银行业金融机构重要信息系统投产及变更管理办法[Z].2009.

技术变更流程范文第2篇

关键词：自动化测试；业务流程；SG-ERP

中图分类号：TP29

在庞大而复杂的SG-ERP系统建设、运维中，系统变更往往需要对涉及到的多个业务流程进行全方位的测试，制作大量的测试脚本及准备多角度的测试数据和用例，同时还需要进行完整的多轮回归测试。目前SG-ERP系统尚无专门的自动化测试工具，因而亟需提升SG-ERP系统的测试水平，加强和促进自动化测试技术在SG-ERP中的应用，在更广层面、更深层次上提升SG-ERP系统的运维能力。有鉴于此，本文依据江苏电力企业架构成果，以业务流程为导向，选取业务系统中典型的、复杂的业务场景和功能模块作为试点项目，研究不同功能应用场景的自动化关键技术与支持工具，并开发了一套应用于SG-ERP系统的自动化测试工具。当系统发生任何功能变更后，该工具能自动识别受影响的业务流程，并将相关的测试信息以不同的颜色框架展示给用户。

1 系统总体架构

在系统分析和总结电力信息系统自动化测试的研究成果，并考虑企业级自动化测试技术的应用现状需求的基础上，本文对相关的关键理论和技术进行了深入研究，提出了基于业务流程的智能自动化测试框架，自下而上包括分为并行与压力测试模块、数据驱动测试模块、可视化动态展示平台，其中可视化动态展示平台包括用户交互有关的模块：业务对象维护、变更处理输入、业务流程展示、流程动态监控、事件响应处理、日志查询等。数据驱动测试模块包括多种类测试脚本整合、测试脚本传递与连续执行的数据处理、业务流程测试过程动态执行，具体的体系架构见图1。

图1 项目总体研究体系架构图

2 试点应用仿真

该自动化测试工具以SG-ERP的业务流程为基础，将ERP中实现的软件流程配置在工具内，并把流程中功能点所包含的测试案例制作成对应的脚本，配置脚本数据及其关系，最终实现业务流程、功能点、测试案例的系统化管理。当业务流程发生任何需求变更时，均可快速识别受影响的业务流程并实现全过程的自动化测试。

2.1 业务流程

选取江苏电力业务架构中的“服务需求计划提报”流程作为试点应用实例，该业务流程是项目管理模块中的一个典型复杂业务场景，此场景中选取了两个典型流程，分别是非招标服务需求计划流程和国网服务采购招标物资部汇总流程。非招标服务需求计划流程涉及的功能点有服务需求计划的填报、服务合同的签订、服务确认以及发票预制，国网服务采购招标物资部汇总流程涉及的功能点有服务需求计划的填报、服务需求计划的审批和汇总、服务合同的签订、服务确认以及发票预制。图3给出了服务需求计划提报流程的整体业务流程图。其中，节点10和20是服务需求计划填报的流程节点，节点30和40是服务合同的签订的流程节点，节点100到110是服务确认以及发票预制的流程节点，节点50～90是服务需求计划的汇总和审批的流程节点。

图2 服务需求计划提报业务流程

2.2 软件流程系统化

软件流程系统化分为业务流程系统化、脚本系统化和测试案例系统化三部分：

（1）业务流程系统化。自动化测试工具将业务流程分层级维护和管理，以清晰展现业务流程的各个节点，即第一层为业务流程，第二层为流程包含的功能点，第三层为功能点包含的脚本。图3给出了“非招标服务需求计划提报流程”的业务流程系统化示意图，首先在系统中维护第一层级非招标服务需求计划提报流程，然后在第二层级维护服务采购申请填报、服务合同签订、服务确认及发票预制等功能点，最后在第三层级维护提报服务需求计划、部门审批接口、创建服务采购订单、采购订单两级审批、服务确认以及发票预制等脚本。层级的划分完全满足客制化的定制需求，并且具备增、删、改、查等功能。

图3 业务流程系统化示意图

图4 功能点系统化示意图

（2）脚本系统化。自动化测试工具包含脚本库的维护和管理，脚本整合管理。首先该工具提供脚本库维护事务，能够根据层级分类维护脚本；其次将不同类型的脚本自动整合成工具识别的广义脚本。如图4所示，该工具整合了SECATT类和Function类脚本。

（3）测试案例系统化。测试案例在不同的测试过程中是可以部分重复使用的，自动化测试工具可以人为地选择需要保存的案例，此功能降低了多轮回归测试过程中案例的准备工作量，提高了测试效率，形成了测试案例的系统化管理。图5保存了上一次服务需求计划提报的案例数据，在下轮的回归测试中重复使用，并且案例数据在测试过程中可随时更改和导入。

图5 测试案例配置关系示意图 图6 需要被测试的业务流程列表

2.3 系统变更

当系统变更完成时，自动化测试工具能够根据请求号获得下面的对象列表，同时利用自主开发的对象影响分析功能搜索主程序和事物代码，当与配置的主程序或事物代码匹配时，则进入被影响区域，从而自动生成需要被测试的业务流程列表，即实现根据需求变更自动生成测试计划的目的。自动生成的需要被测试的业务流程列表如下图6所示：

选择某一个具体的业务流程后，即可进入主页面进行测试，实时展示流程中各节点的运行状态（测试前，测试中，测试后），并用不同的颜色框架展示给用户。同时，用户可以方便地查看任何一个功能或测试脚本的详细测试日志，实现测试系统的过程可控性及360度动态监控。

2.4 系统验证

在SAP项目的实施中，测试部分通常分为单元测试与集成测试[8]。单元测试是对软件中最小可测试单元进行检查和验证，在SAP中就是单功能点测试；集成测试是将所有的模块按照设计要求组装成子系统或系统进行测试，在SAP中表现为跨模块、跨系统的综合测试。针对业务流程相关脚本的变更，本文将传统的测试过程和自动化测试工具引入后的测试过程进行了场景模拟和实验比较验证。

（1）测试计划的生成过程。在传统的测试过程中，测试计划是由人工分析和整理的。在人工整理的过程中人员对系统、业务流程以及功能点的熟悉程度是关键因素，分析过程会耗费大量的人力并且对测试人员素质有很高的要求，而自动化测试工具能够根据变更对象在流程库中智能的搜索和分析，自动生成一套全面的、严谨的测试计划。

（2）单元测试和集成测试的数据采集。首先在自动化测试工具中完成非招标服务需求计划提报、国网服务招标采购流程（物资部汇总）这两个流程的相关配置、脚本制作等工作，如表1所示。

表1 脚本制作时间表（单位：小时）

本文针对两个业务场景进行测试工作。场景一：当部门审批接口发生变更时，在单元测试和集成测试过程中分别收集完成手工测试维护执行时间和自动化工具执行时间。场景二：当经法系统接口发生变更时，在单元测试和集成测试过程中分别收集完成手工测试维护执行时间和自动化工具测试执行时间。其中脚本变更维护时间分别为部门审批提交脚本的维护时间和经法系统接口变更脚本的维护时间，单元测试阶段只存在单个变更脚本的测试时间，集成测试阶段是对整个流程的测试，所以存在流程中每个脚本执行、维护的测试时间。

（3）自动化测试效益分析。自动化测试的经济成本通常可以描述为固定成本和可变成本。固定成本主要指软硬件成本，包括：硬件、应用软件的许可证、应用软件的技术支持、自动化测试环境的设计和搭建、脚本开发工具软件、脚本开发工具的许可证等，其不受自动化测试的成果数量和运行次数影响。可变成本主要包括测试准备成本、创建自动化测试的成本、执行自动化测试的成本、维护自动化测试的成本和测试报告生成成本。这些因素中，创建自动化测试的成本、执行自动化测试的成本、维护自动化测试的成本对测试成本的统计结果影响较大。而测试往往是一个重复的活动，这就带来了计算ROI（Return On Investment投资回报率）时的另外两个重要因素：自动化测试的运行次数和手工测试运行次数。在此本文给出一个自动化测试投资回报率的计算公式：

自动化测试投资回报率采用式（1）计算：

在前6次的测试中，ROI为负值，手工测试成本低于自动化测试，并且ROI随着测试次数的增加而增加，在第7次测试时（ROI由负值到0.04）手工测试成本与自动化测试成本大致平衡，此后，自动化测试的成本小于手工测试成本。当自动测试被重复利用20次时，收益达到0.78。由此可得，自动化测试的时间越长、测试次数越多，ROI会越大，收益越高。由此可见自动测试的效率提高还是相当显著的。

3 结束语

本文以江苏电力公司现有的测试体系为基础，利用数据与脚本分离技术，提出一种根据需求变更自动生成测试计划的新理念，开发了一套应用于SG-ERP系统的自动化测试工具，并将其应用于项目管理模块的典型业务流程测试，实验结果表明该测试工具在快速实现需求变更的情况下能保证业务体系的功能完整性，为智能电网业务系统的稳定运行提供坚实的保障。在下一步的工作中，将会对自动化测试过程中生成的异常报告集和分析，形成处理方案，并汇总形成知识库，进而建立软件质量闭环管理机制，保证软件产品质量。

参考文献：

[1]Thomas H.Davenport，Mission Critical：Realizing the Promise of Enterprise Systems[M].US，Harvard Business Press，2000：1-3.

[2]陈启申.ERP――从内部集成起步[M].北京：电子工业出版社，2005：4-5.

[3]方菲，孙家，王立福.面向对象软件回归测试技术研究[J].软件学报，2001（03）：372-376.

[4]姚实颖，肖沙里，谭霞.软件测试自动化中建立可维护脚本的技术[J].计算机工程，2003（11）：79-81.

[5]章晓芳，徐宝文，聂长海.一种基于测试需求约简的测试用例集优化方法[J].软件学报，2007（04）：821-831.

[6]梁煜，李舒，张辉.关于并行程序时序测试中测试覆盖率的研究[J].计算机研究与发展，1999（02）：160-165.

[7]吴立松，杨根兴，蔡立志.基于构件的测试脚本复用技术研究[J].计算机应用研究，2009（04）：1323-1326.

[8]黄超，黄地龙.ERP管理软件的测试[J].电子测试，2008（12）：81-85.

[9]于秀山.软件自动化测试效费分析[J].计算机工程与应用，2003（17）：107-109.

[10]史永莉，陈元琰，罗晓曙.软件自动化测试方案的效益分析[J].微计算机信息，2010（06）：226-227.

技术变更流程范文第3篇

关键词：合同管理；管理流程；信息系统；界面管理

中图分类号：F284　文献标识码：B　文章编号：1008－0422(2007)09－0073－06

1　引言

大型项目的合同种类繁多，传统的手工管理方法耗时费力，很难实现合同信息的快速提取，对合同执行状况难以进行动态跟踪，对合同索赔缺乏信息支持。基于管理流程的合同管理信息化的目标是对大型施工企业的所签订的各类合同的基本信息进行管理；对合同状态进行跟踪；通过信息平台实现合同评审的网络化；根据合同确定项目的预算成本，作为成本控制依据，并对合同执行情况进行对比跟踪；依据历史工程索赔事件建立索赔事件库为项目获取索赔机会提供信息支持。

近年来，信息技术的高速发展为管理流程的改进提供了很大的空间，全面推动了流程管理的实现与组织的变革，对工程项目合同管理的实施进行流程分析，将相互关联的管理过程作为系统加以识别、分析和理解，确定项目管理流程、操作程序、工作逻辑关系，从而提出并优化有关管理流程，建立一套标准化、工作程序化、规范化、科学合理的管理工作流程，将有利于对整个项目系统或系统中的某个过程及其相互作用进行动态的、系统的管理，从而保证了各项工程施工活动的决策正确性及其实施结果的预期性，最终有效地保证项目合同管理目标的实现。

2　大型建设项目的合同管理流程简介

2．1　大型建设项目合同管理流程的概念

管理流程是指管理活动中一系列相互关联行为的序列结构，它反映了在某种活动目标的导向下，这些活动的先后顺序、承转关系，制约、推进和输入输出的客观规律。按其性质和作用可以分为总体流程、局部流程和细部流程，总体流程规定了管理活动的阶段划分以及各阶段的相互关系；局部流程反映各管理阶段重要环节的相互关系；细部流程则反映各管理环节中业务活动的相互关系和流转过程。

大型建设项目合同管理流程是它反映了建设工程施工生产的客观规律和管理活动的特点，将施工过程所需要的信息流和物质流进行有机结合，并为施工技术作业和管理活动输入行为目标、物质条件、运作规则，促使其产出预期的结果。

2．2　大型建设项目合同管理流程的特点

管理流程具有目的性、必然性、多样性、系统性和层次性的特点。

2．2．1　目的性是指管理流程表达了管理业务完成的过程，一定以实现相应的管理业务为目的：

2．2．2　必然性指管理业务的完成必然要通过某种流程；

2．2．3　多样性指许多管理业务完成方式不具有唯一性，指一个管理系统中总是存在多种管理业务，因此存在多种流程，而且这些流程之间是密切相关的，是严密的组织的。一个管理系统的流程是由多种不同的流程构成的流程体系；

2．2．4　层次性指由于管理系统的功能具有层次性，相应的管理业务与流程也具有层次性，即一个综合性的管理业务的流程可以分解为若干较管理业务流程组合。

2．3　大型建设项目合同管理流程的构建步骤

为了保证建设项目合同管理的成功实施，必须建立一套高效的管理流程体系，而一个理想的流程体系结构应该满足以下两个条件；(1)流程同步，指流程应具备在质量、数量、时间等方面准确满足建设项目合同目标实现的能力。(2)流程高效，是用总的流程成本来计算，理想水平是用尽可能低的成本来保证项目信息流程、资金流、物资流的运转。管理系统流程设计的主要内容有管理业务分解、相关管理业务分析、构建管理流程责任分配矩阵、绘制各级管理流程图等。

管理流程设计是大型建设项目造价管理系统设计的重要组成部分，管理流程设计通过将某项管理工作分解为各个管理活动，直到管理工序，并区分具有不同性质或特点的工序，根据管理科学原理采用不同的工序完成方式，在此基础上确定的管理工作完成过程，为科学地确定系统结构、系统的管理规范奠定了基础。特别是在现有管理系统重新设计中，通过流程研究，优化与再设计，使进一步通过结构再设计实现系统整体优化有了较好的基础。项目合同管理工作的分解及相应流程的构建一般经过如下几个步骤：

(1)对建设合同管理工作进行研究与探索，确定分解的准则，是按管理职能划分或是按工程实施顺序划分等准则；

(2)确定某项管理工作的管理活动组成，并理清管理活动中各个管理工序，初步拟定某项管理工作完成的综合流程和相应的子流程；

(3)去除每项管理职能的流程中的不可行的方案或明显劣于其他方案的方案，保留较好的方案。

2．4　大型建设项目合同管理流程的控制

大型建设项目合同管理流程控制是利用现代工程项目管理相关学科知识和技术方法，通过对影响建设项目合同管理的目标的因素进行识别、建设环境进行分析，对工程项目建设合同管理的目标控制的原则、原理、方法及措施做出全面的系统规划，进而对建设行为状态实行跟踪控制和组织协调，从而保证对建设项目管理职能的履行，最终实现工程项目的建设目标。

它涉及到利用信息系统所提供的信息，对管理活动做出最优化决策和指令，使每个管理过程始终逼近项目目标计划。控制系统的决策、指令及执行，是由项目管理部门的高级、中级、及技术管理三个层次实现的，三个层次的水平将直接影响目标计划的实现。信息系统的信息敏感程度，与控制系统的决策优化水平关系极大，而控制系统的决策优化水平，直接影响到计划与实际的差异程度。因此，信息系统与控制系统必须设计成相匹配的系统。

2．5　合同管理流程的界面分析与管理

界面，又称接口，是指相互作用的子系统之间的界限，是子系统之间既相区别又相联系的纽带。界面管理是指协调相互作用的子系统之间的能量、物质、信息交换以实现系统目标的活动，除了组织上、管理上、技术上的协调之外，还要协调各系统界面的相互关系。

在现代工程项目管理中，人们越来越强调系统的集成，在工程项目中界面具有十分广泛的意义，项目的各类系统，如目标系统、技术系统、行为系统、组织系统等，他们的系统单元之间，以及系统与外部环境之间都存在着复杂的界面。项目管理系统各子系统之

间及各个子系统内部存在复杂的界面，而直接的表现形式是各管理流程之间的接口。

我们可以看出项目管理系统与外界以及项目管理系统内部之间的流程要素以及各管理流程之间存在复杂的关系，他们之间互相作用、互相联系、互相影响，建设项目管理流程的界面有很多种类型，可以从很多不同的角度来描述：

(1)项目的各类组织系统之间以及项目整个系统与外界环境系统之间存在复杂的管理界面。例如，政府主管部门、项目管理组织、承包商、材料供应商等项目参建单位之间的工作往来形成了复杂的管理流程界面：从总体上，项目所需要的资源、信息、资金、技术等都是通过界面输入的，项目向外界提品、服务、信息等也是通过界面输出的，所以整个系统与外界也存在着复杂的界面。

(2)在工程项目生命周期的各阶段之间的管理流程界面。建设项目自可行性研究至设计、设计到施工、施工到验收，在这些界面的两侧的管理环境及参与单位都有着显著的不同从而导致管理流程的差异，这些差异造成不同的工作、人员行为以及控制方针，从而形成了项目管理实施过程之间的管理流程界面。

(3)各管理子系统之间的职能管理流程界面。在建设项目的管理中，项目管理的各个职能以及各个管理部门在项目过程中形成一定的关系，互相依赖、互相影响，由于各子系统的功能不同、目标不同，按其职能可将项目管理系统分解为进度管理子系统、成本(投资)管理子系统、质量管理子系统、合同管理子系统等，从而各个子系统之间构成复杂的职能管理流程界面。

(4)在项目建设的各个管理职能系统内部也存在管理流程的界面，例如进度计划管理系统中，进度计划的编制分为总体实施计划及各年度、季度、月度计划的编制。在总体计划编制的管理模块中，输入是项目管理目标及上层系统组织的意图，输出是项目的总体实施进度计划，对于年度进度计划的编制而言，其输入是总体实施计划，输出是项目的年度实施计划。所以，不同阶段的计划编制工作之间存在流程界面。

(5)部门间流程界面。部门间流程是跨越两个或两个以上职能部门的流程，即流程的系列活动是由不同职能部门的人来共同完成的。部门间流程的活动是不同的，但却是相关的，活动之间有着内在的联系，有些活动乍看起来是不相干的，但通过某些其他活动的媒介，这些活动间也发生了远程联系，通过这些不同部门间的相关活动的共同作用产生了特定的结果，从而构成某一工作完成的特定流程。诸如，在建设项目的计量支付中，对于项目管理组织而言，首先必须由工程处对工程质量验收合格，随后由计划处计量人员进行造价审核，最后由分管领导审查签字。这项管理工作的实施跨越了三个部门，产生了部门间的流程界面。

因此，我们要对整个管理系统进行全面分析，运用集成管理的思想，对流程实施集成管理，做好各管理流程的界面协调，保证各管理子系统之间以及各子系统内不同管理流程的物资、能量、信息通畅地流动，同时要处理好系统与外部环境的关系，使整个管理系统始终处于有效平稳的状态。

3　大型建设项目合同管理流程的设计与实现

3．1　背景分析

某大型项目的合同管理流程系统需要全面地归纳建设项目合同管理的事务，其中包括招投标文档，并通过分类登记、关联管理、跟踪催办，使原本散落在各个部门和各个人案头、柜子中的所有合同台账、费用往来、文件往来、进度款、付款凭证、变更及其处理过程记录等均可有条不紊地记载到该系统中，使原本难以理清的施工管理和合同事务变得有章可循。要求该系统不仅本身具有强大的管理功能，还可很好地桥接工程项目的其它业务管理，如：对进度计划管理、材料与物资管理、投资控制管理、质量安全管理等各个管理系统之间起到协调、监控作用。

3．2　本项目合同流程管理的目标分析

本项目的合同流程管理主要是实现对项目合同签订、履行、变更、索赔、终止、结算等的全过程跟踪管理，同时为决策提供相应的支持信息和完整的文档管理。具体包括：

(1)实现对合同签约的流程化管理，该部分内容可链接到招投标管理子系统中；

(2)以合同为主线，以费用为中心，实现对合同全生命周期的管理；

(3)对合同变更、索赔等重要合同事件进行记录、分析，其中变更部分链接到计量支付中的工程变更管理；

(4)对工地会议、大事件、物资供应等进行记录，以便查询。

本系统所涵盖的业务范围是针对工程相关合同生命周期中的各项业务，包括基本信息的管理、工程各类合同的签订、履约监控、变更、索赔、终止、结算等业务和工程备忘录。

按照合同的生命周期，本系统合同管理子系统涉及的业务过程有合同的申请审核、工程各类合同的签约、履约、计量与支付、变更和索赔、终止、结算等业务。本系统主要分为基本信息管理、合同签约管理、合同进程管理、合同变更管理、合同索赔管理、合同终止管理、工程备忘录七大模块。

合同管理子系统采用目录树层状结构，对合同申请、审核、签订、索赔、计量、支付、变更等合同相关业务进行全面、有效地管理，使工程项目各有关单位之间建立有机的联系，相互协调，共同实现进度、质量、费用三大目标。

3．3　合同管理综合流程图

根据本项目的特点，建立的合同管理综合流程图。

3．4　主要的功能模块的分析

3．4．1　合同签约管理模块

本功能模块是保证项目的顺利进行，规范经济行为，有效控制投资规模，规范合同的签约行为。其主要功能包括如下几点：

(1)实现合同文本审核流转单的增、删、改；

(2)实现合同文本审核流转单的在线流转；

(3)实现合同文本电子文档的挂接；

(4)实现对合同模板的增、删、改；

(5)实现对因招标项目的信息查询；

(6)实现合同文本电子文档的在线批注、审核。

合同签约管理流程。

3．4．2　合同进程管理

合同进程管理主要包括进度信息管理、质量信息管理、计量信息管理、支付信息管理四大管理模块。

1、进度信息管理

该模块主要反映工程的进度计划与完成情况，可由各标段的进度计划与完成情况的相关数据编制汇总得出进度汇总表。该功能模块要实现的功能如下：

(1)实现进度计划、完成情况的调用；

(2)实现进度计划、完成情况的信息查询；

(3)实现各标段进度计划、完成情况的对比分析。

2、质量信息管理

该模块主要提供工程检测与评定及质量事件的信息。可由各标段质量检测、评定及其相关数据汇总得出工程质量汇总报表。该功能模块要实现的功能如下：

(1)实现质量信息的调用；

(2)实现质量检测、评定与质量事件的信息查询：

(3)实现各标段质量情况的对比分析。

3、计量信息管理

该模块主要是对各标段每期工程计量信息的查询与汇总，可由各标段审核后的计量及相关信息，如工程量清单、中间计量表汇总出审核后的中间计量总表。其流程图。

该功能模块要实现的功能如下：

(1)实行计量信息的调用：

(2)能够察看其他模块中相关的支付、质量与进度信息，能够对累计完成数据进行统计，并且用直方图对合同完成情况进行统计分析；

(3)能够对完成项目进行费用分摊；

(4)对以往审核后计量信息的查询。

4、支付信息管理

该模块主要是对各标段每月支付信息进行查询与汇总。可由审核后的各标段支付及其相关信息，如中间支付单、付款单等汇总出审核后的中间支付汇总表。支付流程图包括中间支付流程图和竣工支付流程图。

该功能模块要实现的功能如下：

(1)实现调用支付信息；

(2)实现对中间支付信息的查询；

(3)对支付金额超过支付比例的进行预警；

(4)对支付款项做支付跟踪，查询实际支付时间、支付数量，及累计各期的支付数。

3．4．3　合同变更

主要实现合同变更的查询汇总，并分析合同变更的变更工程量和计算审核，实现对非合同变更(工程变更和设计变更)的量价分析，并设置是否记人合同总价调整的功能。可实现由合同变更的基本信息，包括变更原因、变更内容、变更时间、审核记录等汇总得出合同变更情况一览表，并予以合同的变更管理的功能。

该功能模块要实现的功能如下：

(1)当有新合同变更单进入系统时报警，提示相关工作人员；

(2)对各标段合同变更单的查询：

(3)对各类变更进行量价分析；

(4)对合同变更审核过程进行查询；

(5)能够通过查询相关的设计变更单审核工程变更单。

3．4．4　合同索赔

该模块主要实现合同索赔的查询汇总，并分析合同索赔的变更工程量和单价以及工期。本功能模块不实现索赔的录入，索赔申请审核在投资控制子系统系统中实现。该模块可实现由合同索赔的基本信息，包括索赔日期、索赔原因、索赔内容、索赔审核意见等汇总得出合同索赔信息一览表。该功能模块要实现的功能如下：

(1)提示、查询、跟踪合同索赔状况；

(2)合同索赔与相关工程问题关联：

(3)合同索赔需进行量价分析和费用分摊。

合同索赔的基本流程图见图7所示

3．4．5　合同终止管理

1、合同中止和终止合同中止和终止后要进行结算和资料移交等工作。该模块的输入为合同中止和终止的基本信息，该模块的输出主要为合同中止和终止的基本信息列表。该功能模块要实现的功能如下：

(1)合同中止申请审核信息和终止信息的增、删、改：

(2)合同中止申请审核信息和终止信息的查询。

2、合同结算

合同结算指系统根据结算日期汇总合同投资的各项信息，如合同金额，发生变更金额，累计完成投资额，累计进度款支付金额，剩余合同投资等，本管理模块可以实现合同结算功能。该功能模块要实现的功能如下：

(1)合同结算信息的增、删、改；

(2)合同后生成合同剩余工程量清单。

3．5　接口

合同控制系统不使用外部专用软件，因此本系统的接口主要是指与其他子系统的接口。

在工程项目实施中合同管理是投资、进度、安全/质量控制的依据。

(1)与投资控制子系统通过合同分解编码和清单分解编码相联系，两个系统的交叉主要在实际计量支付的管理和变更、索赔对投资的影响上，实际审核的流程交由投资管理子系统实施，审核结果的支付数额、变更索赔数额等传给合同子系统做进一步查询分析。

(2)对于计划进度控制子系统可通过合同编码直接和进度子系统相联系，合同子系统关于进度计划与计划完成情况的信息由计划进度子系统调用，由合同子系统进行查询分析。

(3)对于质量控制子系统可通过合同编码直接和合同子系统相联系，合同子系统关于质量检测、评定与质量事件的信息由质量控制子系统调用，由合同子系统进行查询分析。

(4)对于招投标项目的合同相关信息可由招投标子系统调用，包括在合同申请过程中招标项目的中标信息。

技术变更流程范文第4篇

【关键词】经济签证和设计变更的目的；流程；内容；时效性

每一个单位工程的施工过程中都有签证和设计变更的产生，这些直接对建筑产品的成本息息相关，怎样才能更好的控制签证和设计变更的产生，以及更好的做好签证和设计变更的管理制度和流程，本文谈谈其管理制度和流程。

1.目的

加强设计变更及现场签证管理，规范工作流程，有效地控制成本，确保工程质量和工程进度。

2.范围

适用于公司各开发项目的设计变更及现场签证管理工作。

3.设计变更内容、格式要求及流程

3.1设计变更的内容及格式要求

3.1.1设计变更是对设计内容进行修改、完善、优化，需要设计单位的签字、盖章，及发包单位项目部的确认。

3.1.2设计变更的主要类型：

由于设计单位的施工图出现错、漏、碰、缺等情况，而导致做法变动、材料代换或其他变更事项；

由于发包单位改变建设标准、结构功能、使用功能、增减工程内容，而导致做法变动、材料代换或其他变更事项；

由于发包单位、监理单位、承包单位采用新工艺、新材料或其他技术措施等，而导致做法变动、材料代换或其他变更事项；

由于销售部门、客户服务中心、业主要求提出变更，而导致做法变更、材料代换或其他变更事项。

3.1.3所有设计变更审批表必须使用公司规定的标准表格，并明确以下内容：编号、工程名称、发生的时间、发生的部位或范围、变更的内容做法及原因说明、增加的工程量、减少的工程量、相关图纸说明。

3.1.4发包单位、承包单位均应对设计变更单进行编号，并整理归档、妥善保存；双方都应设置设计变更事项的单据交付记录，即交付对方单据时要求对方签收，接受方不得拒签。

3.2设计变更办理一般流程：

3.2.1经办人在填写设计变更审批表时，若因本专业变更导致其它专业需要一同变更的，应发相关通知。（如因墙置改变导致水电管线移位）

3.2.2预算人员在对变更费用进行估算时，应对措词不清，结算时易引起分歧、纠纷的变更单退回，要求提出部门表达清楚，不致引起歧义。

3.2.3一般来说，现场工程师确认时只需要按照相应的设计变更文件确认完成或未完成的事实，而不需要确认具体的工程量。但当无法根据设计变更文件直接计算出工程量，或者相应设计变更文件的某条或某几条只完成一部分时，监理工程师及项目部现场工程师应直接在设计变更单中确认相应的工程量。

3.2.4对于造价调减的设计变更，发包单位现场工程师要及时跟踪、落实、核定减少的具体数额，并与承包单位形成书面记录，防止因漏报而给公司造成损失。

4.现场签证的内容、格式要求及流程

4.1现场签证的内容及格式要求

4.1.1现场签证的主要类型：

因设计变更导致已施工的部位需要拆除（需注明设计变更编号）；

施工过程中出现的未包含在合同中的各种技术措施处理；

在施工过程中，由于施工条件变化、地下状况（土质、地下水、构筑物及管线等）变化，导致工程量增减，材料代换或其他变更事项；

发包单位在施工合同之外，委托承包单位施工的零星工程；

合同规定需实测工程量的工作项目；

4.1.2所有的现场签证审批表都必须使用公司规定的标准表格，并明确以下内容：编号、工程名称、发生的时间、发生的部位或范围、变更签证的内容做法及原因说明、增加的工程量、减少的工程量、相关图纸说明。

4.1.3关于临时用工的签证事项，双方应在签证通知单上洽商确定以下问题：工作内容及工作量、工日。

4.1.4所有现场签证单只有加盖发包单位专用章或发包单位公章才能生效，承包单位和监理单位也应加盖有效印章。

4.1.5发包单位、承包单位均应对现场签证单进行编号，并整理归档、妥善保存；双方都应设置现场签证事项的单据交付记录，即交付对方单据时要求对方签收，接受方不得拒签。

4.2现场签证的一般办理流程

4.2.1监理工程师及项目部工程师在签证前必须认真核对签证工程的施工时间、工作内容、发生原因、发生工程量、工日数、机械台班数以及签证所发生的费用应由何方负担等。特别是对发生原因的交代应详细、明了。

4.2.2对于措词含糊容易引起纠纷的签证，现场工程师在签署时应征求预算人员意见，预算人员审核重大签证费用也应避免用词不准在结算时造成经济纠纷。

4.2.3签证内容完成后，工程师应避免签署类似“情况属实”或“工程量属实”等模糊性内容，而必须确定实量后签字确认完成或未完成的事实或者工程量、材料材质和规格、工日数、机械台班等。原则上监理工程师不应直接在签证上签认有关单价或总价。

4.2.4如果签证单附有交工图纸，则监理及项目部工程师应审核图纸是否与实际施工结果相符，并在图纸上签字确认，此时可以不对工程量进行确认，由预算人员人员按照图纸核算工程量。

4.2.5项目工程师对签证单上直接签定的工程量的准确性负责。

4.2.6如签证单涉及到隐蔽施工、金额及其它事后不可复核的项目时，则应由项目部工程师及预算人员人员共同现场认定。

5.设计变更及现场签证办理时间的规定（包括图纸会审及施工组织设计审批流程）

5.1正常的设计变更和现场签证单，应提前5个工作日内书面提出，现场工程师按照表格汇报给工程部及总工处，应由有效签字人共同签署完成，并由预算人员做出估价并获得审批后，在5个工作日内给予书面答复后，才通知承包单位开始实施。特急类（指如果不立即实施将造成更大损失的签证）设计变更和现场签证，可以先实施再由预算人员做出估价；如属隐蔽工程及事后不可复核的工程，则必须要求承包单位在隐蔽部位覆盖之前或拆毁前提出预算并由项目部工程师会同监理单位对工程量进行核实。

5.2监理、现场工程师应在变更签证内容完成后的5个工作日内在设计变更和现场签证单上对完成时间和完成情况进行说明。

5.3图纸会审流程：由施工单位中标后在接到图纸7个工作日之内，提出图纸中的问题，由现场工程师组织设计、监理、施工各单位进行会审，并提前2天通知工程部及总工参加，并将现场形成的图纸会审纪要，必须在5个工作日之内返回工程部一份。

5.4施工组织设计审批流程：在中标后15个工作日内，经现场工程师及监理审核过的施工组织设计文件，报工程部及总工在5个工作日内进行审核后，方可进行签字盖章。

技术变更流程范文第5篇

关键词：电力系统；通信；IT服务管理

一、电力系统通信部门的IT服务管理

电力系统通信部门IT服务管理体系包括展现层、功能层、数据层。通过对各种系统状态进行实时监控，将现有软硬件环境、网络资源、应用系统、人力资源、知识库有机地融为一体，合理调配资源，切实解决了机构人员、管理模式、业务流程、技术集成等方面实际问题，真正实现科学高效的IT服务管理。

二、典型处理流程

IT服务管理是一种面向流程的管理模式。在电力系统通信部门原有的业务流程的基础上，对其进行优化和改造，在此提出了IT服务管理四个典型处理流程，下面分别从流程目的、功能等角度进行说明：

（一）事件管理流程

事件是任何不符合标准操作且已经引起或可能引起服务中断和服务质量下降的事件。在ITSM引入以前，事件管理没有特定的流程，所有事件都通过通信故障专线通知到通信调度部门，然后由值班员派工单给检修班成员，并不区分事件的“轻重缓急”，也没有技术层面的审核，因此故障派修单回单率一直很低，很多单据由于不具备执行条件而在班组和通信科之间来回推诿，降低了故障解决时间，也没有相关考核指标。

事件管理的流程如下：首先，事件通过运行单位填报、用户填报或者通信检修部门巡视发现填报，所有事件记录进系统，对于已经处理的缺陷只要补报即可。接着通信调度进行分类预判断并分派，确定是事件的影响范围和优先等级：如果是事件处理影响范围小或无影响，则直接进行派单；如果事件处理影响范围大，则要求检修部门先进行停服役申请，再进行事件处理。然后，检修部门消缺完毕后，由用户和通信调度分别进行消缺验收，判断是否已解决确定问题：如解决，则由检修班回单给通信科，则纳入审核管理或者填报缺陷归档，关闭记录；如没有解决，则纳入通信科审核管理继续诊断，纳入下一季度大修工程，必要时转省调、厂商和集成商、服务商等进行支持解决等。最后更新文档，必要时进行回顾，事件支持人员将根据管理要求定期产生相关报表。

（二）问题管理流程

问题管理流程设立的主要功能是分析已被列为问题的事件（一组或一个）的根本原因，然后找出和建议永久性解决方案。其目的包括：（1）确保分析并确定事件的根本原因，以防止再次发生；（2）确保问题分派了正确支持人员，提高解决率。（3）根据IT资源情况分派问题优先级；（4）主动提供预防性措施；（5）提高IT服务的可靠性；（5）降低IT支持成本；（6）提高通信部门的整体形象和名誉。

（三）配置管理流程

通信部门的所有资源都通过手工和电子配置管理是通过手工形式派发“电路（设备、线路）投入、改接单”，单据与实际资源状况出入较大。待单据完成后，由专人进行手动的资料更新和管理，而经常出现资料忘记更新或资料更新出错，缺乏必要的考核体系。

配置管理的流程如下：首先进行配置申请。接着配置管理员根据需求进行方案设计，经配置管理经理审批后生成配置工单。配置工单由配置经理审核后进行工单派发，此时由于工单并未真正实施，配置资源处于预占状态。然后配置管理员根据班组回单进行完成确认，若确认完成，则将资源预占状态更改为运行状态；否则取消资源预占状态。并定期进行资源检查验证，流程回顾，每个一个季度由系统自动生成配置管理报告，据此可进行资源分析、预警等。

（四）变更管理流程

变更管理流程将通过标准统一的方法和步骤管理和控制所有对通信系统运行环境有影响的变更。其目的在于：通过对所有变更的正确评估，可以维护通信系统运行环境的完整性；确保变更和变更实施得到正确记录，并提供审核统计；减少或消除由于变更实施准备不当等原因出现的故障；提供一致性的变更实施质量控制；提高资源使用率（如未得到正确控制和授权的变更需要更多的后续资源）；确保实施的变更不会超出预定的系统利用限值确保紧急变更请求得到快速实施。

三、IT服务管理体系的实施效果评价

杭州市电力局通信部门IT服务管理系统2006年初上线运行，截止到2007年9月30日，IT服务管理系统的配置项数据包括服务器、客户端设备、网络设备、变电站通信机房、变电站通信屏体信息、数据采集与监视控制系统（SCADA）采集点以及其他各种设备信息，总计有36个分类、95000多条记录。自投运以来总共记录有效服务呼叫8546条，电力通信网和管理信息化共关闭8492条，完成比率达99%。

杭州市电力局通信部门IT服务管理系统固化了18种处理流程及衡量标准、20项事件流程服务指标、10项工作量考核指标、28种事件分类指标等可量化的IT运行维护指标,电力通信网和管理信息化都分别设置了流程经理,每个流程又明确了流程负责人，负责处理流程时限、效率和质量。IT服务管理系统提供了可观、可测、可控、可量化的工作环境,工作量考核、系统风险识别、流程实施关键绩效指标（KPI）、人员技术能力等都可用“数字说话”。通过系统实施，事件处理更加高效,变更管理更加规范、问题管理更加可控、IT服务水平和人员素质得到了极大提高，为IT管理人员提供了方便高效的管理手段。

四、结语

IT服务管理系统运行两年的实践证明了ITSM是一套科学的方法论。实施效果表明该体系应用成效显著，流程清晰,责权分明,运行维护内容可量化，服务质量可考核，运作模式彻底告别了被动的救火队式的管理，开始步入主动的有预案的IT服务管理良性发展轨道。通过系统的实施，各流程的关键绩效指标越来越好，问题的可控程度也越来越高。因此，有计划、分步骤地将各流程应用在日常的系统运行维护和管理中去是现阶段最切实可行的方法。

参考文献

[1]曹汉平，王强，贾素玲．现代IT服务管理——基于ITIL的最佳实践[M]．清华大学出版社，2005．

[2]孙强，左天祖，刘伟．IT服务管理——概念、理解与实施[M]．机械工业出版社，2007．