变更管理流程范文
时间：2024-03-06 17:38:06
导语：如何才能写好一篇变更管理流程，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。
篇1
按照UCM的方法，我们也将CPMM的组成部分抽象为不同的工作流，其中最重要的工作流程包括：
1、变更预估流程 （Change Forecast Process，CFP）；
2、变更请求与处理流程 （Change Apply and Manage Process，CAMP）；
3、变更评估流程（Change Evaluation Process，CEP）。
CFP在软件工程项目的初期对工程中可能产生的变更进行预估。这是在软件工程项目中经常被忽略的流程。通过这个流程，可以在软件的时间和经费预算中提前考虑变更所带来的影响，同时在软件项目的设计和规划中预留接纳变更的空间。保证在产生变更的情况下软件工程项目仍然能有序地进行和正常地完成。
变更预估是软件工程中比较难以把握的方面，目前的预估都是依靠个人经验的主观判断。这样的预估存在准确性低和不能量化的缺点，这对软件工程本身并不能提供有用的帮助。CPMM中的CFP流程对软件工程中的变更评估采用定量的计算方式。在进行项目的需求分析时，通过对影响项目变更的因素，如评估项目的创新程度 T(1)、客户对项目的把握程度 T(2)、我方对项目的把握程度 T(3)和需求调研的详细程度 T(4)等方面的数值，计算出软件项目的各个过程中可能发生的变更概率。由此对软件工程项目的预算、项目规划提供有力支持。
软件工程步骤i可能产生的变更概率如下面“变更预估公式”所示：
其中：V (i)为软件项目过程i完成时可能发生的变更概率。
C (ij)为各项因素对变更比率产生影响的系数，这个系数需要根据不同的开发小组情况和项目类型有所不同。系数的产生和修改则需要根据变更评估流程产生和修改。
D (i)为修正因子。
CAMP是在项目中接纳变更的处理流程，包括变更的提交、审批、实施及完成。CAMP主要强调通过规范的方式接纳变更，并且通过各种有效的手段严格控制变更被引入的方式和时间，确保系统开发的有序进行。CAMP主要通过图1所示的流程处理变更：
篇2
[关键词] 商业银行；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.
篇3
4M变更管理办法最新版
1、目的
在生产过程中，对影响产品质量的4M要素(人、机、料、法)进行管理和控制，使
这四个因素在保证质量的范围内安全合理的变动，从而保证产品质量的稳定和提高，符合标准及客户要求。
2、适用范围
适用于批量产品生产过程中4M(人、机、料、法)要素的管理。
3、4M定义：
是指批量产品生产过程中，涉及的人(Man)、机(Machine)、料(Material)、法(Method)，
(含环境场所)等给产品质量带来一定影响的变更。
人(Man)：是指生产过程中作业者因缺勤、调动、离职、代岗或复岗时，由另一个新作业者代替进行作业时，所产生的变更;
机(Machine)：是指生产过程中的设备、模具、工装、夹具、检具的新增、修理、代用变更; 料(Material)：是指生产过程中的加工原物料、辅料、包装物资等变更。
法(Method)：是指生产过程中的工艺流程、工艺参数(设备参数、材料配比等)、检验方法、作业方法(制造、整理、包装、周转等)变更。
4、职责
4.1变更提出
原则上公司内部变更各部门均可提出申请，并根据变更内容对产品质量的影响程度进行必要研讨，经评审后由实施部门负责执行变更;各4M变更实施部门要建立4M变更的台帐，记录变更的编号、产品型号和结果等。
4.1.1制造部技术组：负责产品工艺流程、模具、工装、检具及方法等变更的实施。
4.1.2制造部生产组：作业人员晋升变更的申请，并根据岗位技能要求进行资格验证，实施变更;内部变更引起的呆滞物料变更处理的申请，跟踪等。
4.1.3供应链：材料(含构成零部件)变更的申请提出和实施，及供应商的变更受理;
4.1.4工程部：机器，方法、设备变更的申请提出和实施;
4.1.5市场部：负责客户提出的变更受理，负责收集和内部反馈客户的评审结果;订单完成后库存呆滞料的变更处理的申请，跟踪等。
4.1.6体系：负责对所有变更事项进行监督及对变更的有效性进行跟踪确认。汇总4M变更结果，应建立4M变更总台帐。
4.2 变更评审实施
4.2.1 变更申请通过部门负责人审核后，由申请部门组织相关评审部门，根据变更内容对产品品质的影响程度进行必要的研讨;由各评审部门审查确认后，变更责任部门执行变更;或根据变更管理类别(送样、申请，记录)由市场项目收集客户意见后实施; 4.2.3 对相关部门进行变更培训，记录保存变更履历。
注：评审部门包括但不限于技术部门/生产部门/质量部门/采购部门/设备管理部门。
4.2.4 4M变更实施部门对变更过程中可能出现的意外要有应对预案;
4.2.5 4M变更实施部门及相关部门需修订变更涉及事项(如工程图纸、SOP、FMEA、控制计划,SIP，ECN,BOM，QC工程图，工艺流程图等);
5 4M变更管理类别：送样，申请，记录
5.1 送样：变更前须试制样品，并向客户送样认可。
5.1.1 变更前，需向部门内部提出变更申请，由实施部门组织评审部门评审，通过后由变更实施部门试制样品，并向客户送样，合格后客户认可，才能实施变更;
5.1.2 变更申请部门须填写《(4M)工程更改申请单》并执行4M变更管理流程。 变更实施部门审查后，由变更实施人将通过的《(4M)工程更改申请单》和其它相关评审报告记录在《(4M)工程更改通知单》中，客户评价结果由市场部项目收集客户评价结果反馈给变更实施部门等有关部门，批准生效后，实施工程变更。
5.2 申请：变更须启动4M变更管理流程进行评审实施。
变更前，需向部门内部提出变更申请，变更申请部门须填写《(4M)工程更改申请单》并启动4M变更管理流程。由实施部门组织评审部门评审，经客户或责任部门确认同意后才能实施变更;
5.3 记录：此类变更须责任部门记录并保存。
由责任部门管理记录相应变更，并保存相关记录。为了确保变更的履历(可追踪性)，供应商应自从该变更品的交货日算起保管3 年。
6 变更管理内容
6.1 客户提出的4M变更
客户提出的4M变更由市场部向公司内部提出申请，按新产品管理流程进行;
6.2 供应商的4M变更
供应商提出的4M变更，由供应商向采购部门提出，向公司内部传达;
6.3 公司内部的4M变更
6.4 变更点的区分管理
6.5 变更品的首次交货
6.5.1变更品的首次交货，需在外包装箱加贴变更后首批次出货标签，并连续3批作出标识。
6.5.2变更品与原来产品在同一批交货时，需：
1.原来产品与变更品的外包装分开;
2.在外包装箱加贴变更后首批次出货标签，并连续3批作出标识。
篇4
关键词：电力系统；通信；IT服务管理
一、电力系统通信部门的IT服务管理
电力系统通信部门IT服务管理体系包括展现层、功能层、数据层。通过对各种系统状态进行实时监控，将现有软硬件环境、网络资源、应用系统、人力资源、知识库有机地融为一体，合理调配资源，切实解决了机构人员、管理模式、业务流程、技术集成等方面实际问题，真正实现科学高效的I T 服务管理。
二、典型处理流程
IT服务管理是一种面向流程的管理模式。在电力系统通信部门原有的业务流程的基础上，对其进行优化和改造，在此提出了IT服务管理四个典型处理流程，下面分别从流程目的、功能等角度进行说明：
（一）事件管理流程
事件是任何不符合标准操作且已经引起或可能引起服务中断和服务质量下降的事件。在ITSM引入以前，事件管理没有特定的流程，所有事件都通过通信故障专线通知到通信调度部门，然后由值班员派工单给检修班成员，并不区分事件的“轻重缓急”，也没有技术层面的审核，因此故障派修单回单率一直很低，很多单据由于不具备执行条件而在班组和通信科之间来回推诿，降低了故障解决时间，也没有相关考核指标。
事件管理的流程如下：首先，事件通过运行单位填报、用户填报或者通信检修部门巡视发现填报，所有事件记录进系统，对于已经处理的缺陷只要补报即可。接着通信调度进行分类预判断并分派，确定是事件的影响范围和优先等级：如果是事件处理影响范围小或无影响，则直接进行派单；如果事件处理影响范围大，则要求检修部门先进行停服役申请，再进行事件处理。然后，检修部门消缺完毕后，由用户和通信调度分别进行消缺验收，判断是否已解决确定问题：如解决，则由检修班回单给通信科，则纳入审核管理或者填报缺陷归档，关闭记录；如没有解决，则纳入通信科审核管理继续诊断，纳入下一季度大修工程，必要时转省调、厂商和集成商、服务商等进行支持解决等。最后更新文档，必要时进行回顾，事件支持人员将根据管理要求定期产生相关报表。
（二）问题管理流程
问题管理流程设立的主要功能是分析已被列为问题的事件（一组或一个）的根本原因，然后找出和建议永久性解决方案。其目的包括：（1）确保分析并确定事件的根本原因，以防止再次发生；（2）确保问题分派了正确支持人员，提高解决率。（3）根据IT资源情况分派问题优先级；（4）主动提供预防性措施；（5）提高IT服务的可靠性；（5）降低IT支持成本；（6）提高通信部门的整体形象和名誉。
（三）配置管理流程
通信部门的所有资源都通过手工和电子配置管理是通过手工形式派发“电路（设备、线路）投入、改接单”，单据与实际资源状况出入较大。待单据完成后，由专人进行手动的资料更新和管理，而经常出现资料忘记更新或资料更新出错，缺乏必要的考核体系。
配置管理的流程如下：首先进行配置申请。接着配置管理员根据需求进行方案设计，经配置管理经理审批后生成配置工单。配置工单由配置经理审核后进行工单派发，此时由于工单并未真正实施，配置资源处于预占状态。然后配置管理员根据班组回单进行完成确认，若确认完成，则将资源预占状态更改为运行状态；否则取消资源预占状态。并定期进行资源检查验证，流程回顾，每个一个季度由系统自动生成配置管理报告，据此可进行资源分析、预警等。
（四）变更管理流程
变更管理流程将通过标准统一的方法和步骤管理和控制所有对通信系统运行环境有影响的变更。其目的在于：通过对所有变更的正确评估，可以维护通信系统运行环境的完整性；确保变更和变更实施得到正确记录，并提供审核统计；减少或消除由于变更实施准备不当等原因出现的故障；提供一致性的变更实施质量控制；提高资源使用率（如未得到正确控制和授权的变更需要更多的后续资源）；确保实施的变更不会超出预定的系统利用限值确保紧急变更请求得到快速实施。
三、IT服务管理体系的实施效果评价
杭州市电力局通信部门I T 服务管理系统2006 年初上线运行，截止到2007年9 月30 日，IT服务管理系统的配置项数据包括服务器、客户端设备、网络设备、变电站通信机房、变电站通信屏体信息、数据采集与监视控制系统（SCADA） 采集点以及其他各种设备信息，总计有36个分类、95000多条记录。自投运以来总共记录有效服务呼叫8546 条，电力通信网和管理信息化共关闭8492 条，完成比率达99 %。
杭州市电力局通信部门I T 服务管理系统固化了18 种处理流程及衡量标准、20项事件流程服务指标、10 项工作量考核指标、28种事件分类指标等可量化的I T运行维护指标, 电力通信网和管理信息化都分别设置了流程经理, 每个流程又明确了流程负责人，负责处理流程时限、效率和质量。I T 服务管理系统提供了可观、可测、可控、可量化的工作环境, 工作量考核、系统风险识别、流程实施关键绩效指标（KPI） 、人员技术能力等都可用“数字说话”。通过系统实施，事件处理更加高效, 变更管理更加规范、问题管理更加可控、IT服务水平和人员素质得到了极大提高，为IT管理人员提供了方便高效的管理手段。
四、结语
IT服务管理系统运行两 年的实践证明了ITSM是一套科学的方法论。实施效果表明该体系应用成效显著，流程清晰, 责权分明, 运行维护内容可量化，服务质量可考核，运作模式彻底告别了被动的救火队式的管理，开始步入主动的有预案的IT服务管理良性发展轨道。通过系统的实施，各流程的关键绩效指标越来越好，问题的可控程度也越来越高。因此，有计划、分步骤地将各流程应用在日常的系统运行维护和管理中去是现阶段最切实可行的方法。
参考文献
[1]曹汉平，王强，贾素玲．现代IT服务管理——基于ITIL的最佳实践[M]．清华大学出版社，2005．
[2]孙强，左天祖，刘伟．IT服务管理——概念、理解与实施[M]．机械工业出版社，2007．
篇5
关键词：企业合同 信息管理 系统
该系统采用目前流行的B/S架构，支持个人电脑的各类型操作系统，对各类主流浏览器都有很好的兼容性。该套系统采用主流的大型数据库管理软件Oracle管理、存储合同信息，应用程序部署在Tomcat应用服务器之上。
根据常见的业务需求，合同管理系统分为三大模块，分别是合同会签管理，合同变更管理，合作伙伴管理。根据业务模块的划分和需求分析，设计关系模式并建立如下数据库表和其中字段：1、合同信息表（合同ID，合同名称，合同简介，合作伙伴ID，合同类别ID，合同年份，项目ID，总金额，经办人，经办部门，合同履行开始时间，合同履行结束时间，归档人，归档日期，工作流序号，工作流状态，验收终止日期，企业编码）。2、合同类别表（合同类别ID，合同类别名，识别码，说明，修改人，是否使用）。3、合同变更申请表（合同变更ID，合同变更编号，合同ID，经办人，申请部门，变更类型，原合同金额，现合同金额，变更理由，备注，工作流序号，工作流状态，起草人，起草日期，企业编码）。4、合作伙伴信息表（合作伙伴ID，合作伙伴性质ID，重要程度ID，行业ID，合作伙伴编号，合作伙伴名称，公司负责人，基本介绍，业务范围，主要业绩，公司地址，联系电话，电子邮箱，公司网址，法人代表，纳税人资格，开户银行，帐号，注册资金，备注）。5、用户信息表（用户ID，用户工号，用户姓名，是否使用，企业编码）。
其中合同会签管理又可分为合同会签起草，合同会签审批，合同会签查询三个子模块。
1.合同会签起草页面由合同起草人对合同信息进行登记，登记完之后可保存、上报给部门会签和领导审批。登记内容包括合同名称、合同类别、合同登记年月、项目名称（需要关联项目的合同）、供应商、合同履行开始结束时间、上传附件等内容。
2.合同会签审批页面提供可视化的工作流审批查询功能，实时查询合同审批节点信息以及各节点审批人及审批意见。经办部门提交合同后，根据合同的不同类别，进行不同的审批流程，流程在各个相关单位及领导之间流转。在合同审批页面除了可以查看合同基本信息，还设计了签字、会签表、会签查询三个按钮，分别用于签字审批，查看会签表，查看会签审批流程信息功能。
3.合同会签查询由两个部分组成，即查询条件和合同列表。查询条件由合同信息的一些关键字段如登记日期，合同编号，合同名称，供应商，经办人，签字状态构成，根据这些条件可以进行过滤查询，精确查找到需要的合同。合同列表则把正在审批流程中及已经审批结束的合同按行展示出来，每行显示合同信息的关键字段，如合同编号、合同名称、供应商、总金额、经办人、会签状态等字段。
合同变更管理模块支持合同按照要求的变更活动。即可以在固定节点控制合同是否可以进行变更。支持变更合同的审批。系统记录合同的变更记录，如资金变动情况。系统能重新生成变更审批表，合同的变动情况在台账和统计功能中自动反映出来。系统记录合同变更的原因、影响，并将变更依据作为附件导入系统，从而兼顾了变更过程管理的严谨和自动性，关联结果，有据可查，权责明晰。此模块分为三个子模块，即合同变更申请、合同变更审批、合同变更查询。
1.合同变更申请页面在进行合同变更时，首先选择原来的合同，这样系统就会自动带出原合同的相关信息，在此页面可以对包括合同名称、合同经办人、合同金额在内的一些字段信息进行修改，并填写变更原因，上传变更后的合同文本后保存，保存之后即可走合同变更审批流程，此时系统会自动生成合同变更号。
2.合同变更审批页面是在合同变更之后，根据企业制定的审批流程合同变更信息会像上面的合同会签一样走一个审批流程。当合同变更信息走到对应部门负责人或相关领导节点时，其有权限对合同变更信息进行查询，进而做出同意或者退回的审批意见。
3.合同变更查询页面可以对企业所有的合同变更信息进行查询统计。
合作伙伴管理模块通过对合作伙伴基本信息的录入保存，提供了统一的准入机制、审核标准，实现了对合作伙伴注册信息的审核、定期评价、分级归类的管理。合作伙伴管理模块分为两个子模块，即供应商信息登记、合作伙伴综合管理两个子模块。
1. 供应商信息登记页面实现了新增、修改、查询合作伙伴基础信息的功能，在此页面可以对供应商全称，供应商级别，公司负责人，企业类别，企业行业，企业性质，公司简介，合作经历以及合作伙伴的联系方式进行登记。当企业信息发生变化时，也可在此页面对企业相关信息进行修改。
篇6
关键词:管道;生产管理系统;运行维护;管理
中图分类号：C93文献标识码： A
1 管道生产管理系统
管道生产管理系统主要包括调运管理、运销计量管理、计划管理、能耗及周转量管理、天然气用气需求预测、日指定、辅助功能、统计报表、SCADA数据采集、对外接口等10 个模块。
1.1 调运管理
实现调度日报的生成，调度指令、场站作业的起草、审批及下达，值班日志的填报，成品油批次计划的起草及下达、收发球管理等功能；实现生产调度过程的监管与控制。
1.2 运销计量管理
从SCADA 系统及相关系统自动获取计量交接数据，并实现管道计量交接数据、气质分析数据、原油化验数据的审核和上报、统计报表的汇总、运销台帐及销售结算单的自动生成。
1.3 计划管理
实现原油、成品油、天然气销售计划的制定、审批及下发及计划完成情况的跟踪分析。
1.4 能耗及周转量管理
实现输油气周转量的自动计算、能耗统计数的上报、自动汇总及报表展现，实现能源统计指标和工艺参数的自动计算。
1.5 天然气用气需求预测
根据历史用气量、气象数据、经济模式等因素预测客户的天然气用气需求，为日指定、销售计划、管输计划等的制定提供支持。
1.6 日指定
根据合同要点进行客户用气日指定管理，实现气田、终端供应量、储气库吞吐能力及客户需求量的综合平衡。
2 运行维护管理体系
管道生产系统以运行维护管理的最佳实践ITIL（信息技术基础架构库）理念为核心，以先进的运行维护管理平台为手段，开展各项运行维护工作。
2.1 运行维护工作内容
运行维护计划制定：主要包括运行维护工作目录的确定、运行维护工作进度安排、服务级别管理、服务改进计划、成本及费用预算。
日常运行维护管理：主要包括用户支持、系统巡检、用户培训、软硬件维护及配置及变更管理等。
突发事件处理：主要包括应急预案的编制及演练、灾备系统建设、突发事件的处理等等。
系统拓展：主要包括新投管道及新建组织机构的系统实施工作。
功能提升：主要包括新功能的开发建设、软硬件平台的升级、系统性能优化等等。
2.2 运行维护流程
以ITIL v3 体系为蓝图，结合项目自身特点制定了配置管理、变更管理、事件管理、问题管理、管理、知识管理等6 个操作流程。
配置管理：指识别和确认系统的配置项，记录和报告配置项状态，根据用户的请求完成变更及检验配置项的服务管理流程。变更管理：在规定时间内完成基础架构或服务的变更而对其进行控制的服务管理流程。事件管理：指对引起或有可能引起服务中断或服务质量下降的事件进行处理的管理流程。问题管理：指通过调查分析查明事件发生的潜在原因，并制定解决方案和防止再次发生的措施，将问题对业务产生的负面影响降到最低的服务管理流程。管理：是负责计划与实施IT 服务变更的管理流程，通过规范的流程控制服务及测试的过程，确保应用系统的质量。知识管理：是进行知识库内容收集、更新、检索以及知识应用、知识关联的服务管理流程。
2.3 运行维护理论
ITIL 是CCTA（英国国家计算机和电信局）于20 世纪80 年代末开发的一套IT 服务管理标准库，其将英国各个行业在IT 管理方面的最佳实践归纳起来变成规范，旨在提高IT 资源的利用率和服务质量。
管道生产管理系统的运行维护工作在借鉴ITIL理念的基础上，制定了配置管理、变更管理、管理、事件管理和问题管理的具体操作流程，并在服务规划、成本控制、年度总结等工作中充分吸收了ITIL 的服务级别管理、能力管理、IT 财务管理、IT 服务持续性管理、可用性管理的理念和方法论，实现了服务成本、服务能力与服务目标（用户需求）的平衡与统筹规划。
2.4 运行维护平台
系统运行维护平台主要包括事件报警平台和运行维护流程管理平台。事件报警平台为HPOpenView 平台中的OVO 和OVIS 软件套件，能够实现系统状态的监控和自动化报警。运行维护流程管理平台主要实现日常运行维护工作的流程化管理。事件报警平台和运行维护流程管理平台通过报表平台进行数据展现，并为帮助台的日常工作提供支持。
2.5 运行维护的实施
以ITIL v3 体系为基础，对配置管理、变更管理、事件管理、问题管理、管理等进行了深入的梳理与研究，在借鉴最佳实践的基础上摸索出了符合项目实际的运行维护方法论，对运行维护工作起到了很大的支持作用。
在处理系统变更请求的过程中，项目组根据工作类型的不同对变更管理流程进行了细分，针对新建天然气客户这一类操作的规律性和重复性，制定了新增天然气客户的操作流程，作为变更管理的子流程专门用于新增客户所需完成的基础信息、权限、报表、工作流、数据流等一系列的操作。同时在运行过程中根据业务发展变化更新完善业务流程，使其运转更加流畅。
通过运用可用性管理、服务级别管理、成本管理与持续性管理，对自身的服务提供能力进行了深入的分析与研究，进而明确了针对不同的服务所能达到的不同级别，同时将各种服务级别与对应的成本关联起来，进一步量化了运行维护工作，也为运行维护工作的考核提供了科学的依据。
参考文献：
[1] 赵宏振. FLUKE744在天然气管道控制系统测试中的应用[J]. 自动化仪表. 2009(07)
[2] 周中.天然气管道防腐问题的探讨[J]. 煤气与热力. 2001(03)
篇7
1运行控制系统的柔性业务需求
航站运行控制系统的核心主要是航班飞行计划,签派和飞行跟踪系统,载重和平衡系统,决策支持系统,机组管理系统进,其他功能系统都是在该几个核心模块上进行扩展得到的。
航班管理委员会的运力任务安排将极大优化,不在向所有分公司和协调运力资源,只向三个生产部门运力计划进行资源协调,而总队、客舱、飞机维修部门能够实现统一资源调度,进行工作任务安排,实现集中管理的目标。
2业务角色设计
2.1 系统管理员用分析
系统管理员拥有对设变流程的所有操作权限。设计变更流程开发完成以后,流程的系统管理人员应该能对流程的相关输出电子表单进行灵活定义,根据业务需求的变化,系统管理员可以对设计变更流程进行重新编排基本达到随需应对的目标,包括对新流程及各流程节点的访问权限的设定,流程关键节点的运行状况可以实时监控,包括关键节点运行时间,运行状态等。新编排的流程应能并运行在流程服务器上,并与相应的监控程序相关联,以实现对流程的实时监控。
2.2 SOC管理人员用分析
SOC管理人员是参与流程运转工作的相关人员,目前主要包括按照航站管理中的部门中所对应的功能模块等,随着业务需求的改变,可能会发生一定的变化。
设计变更流程在运转过程中,会产生一些相应的人员交互,主要包括启动,查看或停止流程,对设计变更票业务进行SOC管理,或转派给其他人员操作,相关人员对设计变更票进行会签,对各种设计变更票进行归档等操作。
3管理流程设计
3.1 SOC管理流程的设计
jBPM是一个灵活的、易扩展的开源工作流管理系统,也是一个基于J2EE的轻量级工作流管理系统。jBPM的另一个特色是它使用Hibernate来实现流程持久化。Hibernate是目前Java领域最好的一种数据持久化层解决方案,它解决了不同数据库SQL dialect差异的问题,使得jBPM能适应现有的所有数据库,而且通过Hibernate,jBPM将数据的管理职能分离出去,自已专注于业务逻辑的实现。
3.2 SOC流程实例的获取
SOC管理流程的执行为SOC管理平台的核心模块,负责SOC管理流程的部署、解析和调度。
不同情况下获取流程实例的方法是不一样的,本文通过从数据库获取流程实例,其代码如下。
//获取实例类JbpmSessionFactory的唯一一个实例
static JbpmSessionFactory jbpm SessionFactory=
JbpmSessionFactory.buildJbpm SessionFactory();
JbpmSession jbpmSession jbpm SessionFactory.openJbpmSession();
Try{
jbpmSession.beginTransaction};//开始一个事务
//从数据库中查询流程定义
ProcessDefmition process Definition=jbpmSession.getGraph Session().省略mitTransaction();//进行其他业务操作
}Catch(Exception e){}
finally{
//关闭jbpmSession
jbpmSession.close(); }
通过在数据库中查询已部署的流程定义,利用该流程定义创建新的流程实例,此方法用于流程定义已被部署,要开始一个新的流程实例的情况。由于要与数据库打交道,必然要跟事务相联系,所以应将对流程的操作放在单独的事务操作中,此处放在jbpmSession.省略mtiTransaction()范围中,事务操作完后,不管它成功如否,都要将事务进行关闭,即调用jbpmSession.close()方法。
3.3 SOC管理流程的监控
SOC管理流程的监控功能贯穿整个SOC管理平台,把流程监控管理模块视为一个专用的应用程序模块,在每张页面中都提供该模块。在系统中不同的流程操作角色具有不同的流程监控权限。其中项目申请人只能查看具有权利的项目,而系统管理员可通过工作流引擎获取当前全部流程实例的信息,对SOC管理流程进行监控和督办。
流程监控的功能主要由MonitorBean类中的showSerchInstances()、inspectT asklnstance()方法和processI nstanceBean类中的signal(), selectTran sition()方法实现。
4结语
本文从SOC系统的流程出发,分析了柔性SOC设计的需要和设计思想,然后给出了柔性SOC系统的角色控制,并提出了基于工作流技术的SOC系统,分析了工作流引擎是整个系统的核心,最后结合jBPM工作流引擎的特点,设计了系统的要求。航空SOC项目如能够成功实施,将极大改进和优化航空运行控制、机组管理的业务和流程,较大程度的提高航空在运行控制方面的工作效率和决策水平,从而提高航空的运行水平,通过提高正点率、合理调配航班、飞机、机组三大资源,使航空公司降低成本、提高服务水平。
参考文献
[1] 王宁,王延章,于淼.以知识管理为核心的办公信息流处理系统研究[J].计算机应用研究,2006,23(2):67～69.
篇8
变更配置保证应用效率
对此，Forrester Research指出，近20%的业务核心应用软件的瘫痪，是因为计划中变更的相关性，没有考虑IT部件和核心业务之间的关联而引起的。另据Gartner Group调查显示，40%意想不到的应用程序瘫痪是由应用程序的故障造成的;40%是因为操作错误;只有20%的原因是由于硬件环境因素以及各种灾难造成。
目前，市场上相应的产品已经不少，例如:HP OpenView Application Manager using Radia、 CAAllFusion Harvest Change Manager、BMC 变更和配置管理（Change and Configuration Management,CCM ）解决方案、Microsoft Systems Management Server（SMS），它们都具有自动部署并维护的特点，这是企业进行管理所必不可少的。面对如此众多的产品，如何选择？
惠普在收购了变更和配置管理解决方案供应商Novadigm之后，将公司的业务资产―包括Radia管理套件成功地整合到其软件产品事业部中。该产品的最大特点就是帮助用户够把所需要的自动化管理解决方案和最佳实践转化为资产，增强灵活性。
Microsoft SMS为基于Windows的桌面计算机和服务器系统提供了具有可伸缩性能的变更和配置管理。它建立在行业标准管理协议的基础上，在任何规模的网络中都容易安装、配置和维护。
但是，用户在选型时仍发现了不少问题，例如:缺少在不同地点和架构中，不同层面的标准程序和变更实施的最佳方案;缺少在IT环境中，可以不断发现和执行理想状态的一种集中、标准的配置管理实践;手动的执行客户端和服务器端软件升级，以及经常被置于变更和释放流程（Change and Release Process）外的安全补丁。
变更管理核心为CMDB
BMC负责变更和配置管理解决方案的高级经理Steve Balentine认为，变更和配置管理最关注的一点就是要能够对各个组建之间的关系进行记录。CMDB就像是一个数据模型，装载着各个要素之间的关系，是实现变更和配置管理的核心所在。
因为所有的操作都会形成一个核心的CMDB。为了达到数据同步化，CMDB应该是在ITIL架构下，用于增加管理业务和技术变更的效率与可靠性，以及IT环境的控制能力和安全性，最终统一到一个平台下，方便用户操作。
在Balentine看来，一个完整的变更和配置解决方案，除了具有CDMB之外，还应该包含用于发现与察觉业务关联的IT资产发现套件、基于流程的变更管理及决方案和基于策略的配置管理及决方案，这个四个部分必不可少。
IT资产发现套件用来鉴别业务核心的IT环境，包括:Discovery Express（发现快车）―让客户鉴别哪些业务部分组成IT环境、Configuration Discovery（配置发现）―用于显示资产的配置情况、Topology Discovery（布局发现）―显示系统是如何连接以及应用软件之间的关联，这三个组件都是以基于标准的CMDB为基础的。
篇9
【关键词】定期试验；软件开发；结果统计
0 概述
2015年4月，海南核电成立了定期试验管理小组，管理小组以“定期试验监督要求”为上游文件建立了一套定期试验管理体系。经过实践检验，该管理体系可以满足核安全监管当局对定期试验的监管要求。但随着1、2号机组相继商运，定期试验管理经验不断积累，现行管理体系逐渐展现出定期试验报告线下审批流程繁琐、管理人员投入大、缺少定期试验数据记录手段等现实问题。为此，海南核电正在开发一款定期试验管理软件，以解决上述问题。
1 定期试验管理软件功能及流程设计
定期试验管理软件主要包括账户管理、数据库、定期试验日常项目、定期试验大修项目、项目审批流程、结果查询、系统维护、项目变更八个模块。
1.1 账户管理模块
为管理定期试验账户操作权限，分专业显示定期试验各项目清单，账户管理模块可对账户权限进行分配，权限包括两个字段：“权限等级”、“权限种类”。
权限等级包括：管理员权限、软件维护权限、定期试验管理权限、定期试验监督权限、试验数据查询权限、定期试验执行权限、高级阅览权限、阅览权限。权限种类包括：“定期试验管理权限”细分为QSR、非QSR；“定期试验执行权限”按处室分类。
1.2 数据库模块
数据库模块由预存在软件中的定期试验台账、试验重要信息以及定期试验历史数据组成。
数据库模块列表包括：项目编号（唯一）、序号、机组号、系统、试验物项、试验项目、准则、周期、规程代码、责任部门、备注、安全等级、PMRQ、零点时间、最近执行时间、下次执行时间、项目备注1、项目备注2、日常/大修项目、机组状态要求、是否可在线执行、扩展项（不少于10项）、历史数据。其中历史数据包括：历史执行时间、工单号、判定结果、未合格原因、《定期试验报告页》。
1.3 定期试验日常/大修项目管理模块
定期试验日常/大修项目模块预留6台机组，定期试验日常项目模块通过预存在数据库中的PMRQ查找EAM中已生成的工单，根据工单触发时间进行排序并匹配试验项目。项目列表仅显示当前日期向后1个月内及目前暂未合格的试验项目信息。定期试验大修项目模块软件提供项目导入模板进行导入，并与EAM系统工单进行匹配。
待某项试验对应EAM系统的工单状态为“已完工”时，执行人员可将该项试验的试验状态由“正在执行”改为“试验结束”，软件自动将该试验项目推至“项目审批流程”。
1.4 项目审批流程模块
项目审批流程模块的主要功能是在定期试验项目执行结束后，对定期试验报告审批情况进行总体展现，同时也可链接至各个子流程。不同部门仅能看到各自部门的项目审批情况。
1.4.1 数据/报告上传子模块
数据/报告上传子模块是定期试验完成、报告审批的第一步，也可将试验退回至试验未完成状态。项目列表由项目基本信息及“报告上传”、“试验退回至未完成状态”的链接窗口。
点击“报告上传”生成《定期试验报告页》。《定期试验报告页》包括：项目基本信息、试验数据及判定结果、必要的文字说明、部门审批路径设置、试验规程上传、重要附件上传等。其中，“试验数据及判定结果”包括：该项试验对应试验参数、各参数对应的试验值、各参数判定结果；“部门审批路径设置”包括：报告类别、部门审批账户、审批时间、意见、审批结果。
1.4.2 部门审批子模块
部门审批子模块是根据《定期试验报告页》设置的审批路径进行内部审批。待审批项目由项目基本信息及“报告审批”链接组成。点击“报告审批”进入审批流程。如部门各级对试验项目审批结果为合格，则《定期试验报告页》进入“监督部门审批”子模块，并将EAM系统的工单关闭；如任何一级审批判定为不合格或待定，则《定期试验报告页》进入“不合格/待定”子模块。
1.4.3 监督部门审批子模
监督部门审批子模块是对《定期试验报告页》进行第三方审批。待审批项目由项目基本信息及“报告审批”链接组成。点击“报告审批”进入审批流程。如监督部门各级对试验项目的审批结果为合格，则《定期试验报告页》保持至软件数据库中；如任何一级审批判定为不合格或待定，则《定期试验报告页》进入“不合格/待定”子模块。
1.4.4 不合格/待定子模块
不合格/待定子模块给定期试验执行处室提供再次判定或重新试验的选择。待审批项目由项目基本信息及“报告审批”链接组成。点击“报告审批”进入审批流程。试验执行人员可根据项目审批人员反馈的意见提供进一步证据，并将试验返回至“部门审批”或“监督部门审批”子模块。如试验确实不满足定期试验监督要求，则可将该试验退回至未完工状态。
1.4.5 个人待审批子模块
为提高效率，此模块可将登陆账号在“部门审批”、“监督部门审批”、“不合格/待定”子模块的项目进行汇总，并提供审批链接。
1.5 结果查询模块
此模块提供定期试验项目查询、结果统计、趋势分析及定期试验报表等功能。
“项目查询”可根据指定的项目编号、序号、机组号、系统、试验物项、周期、规程代码、责任部门、安全等级、PMRQ自动查询符合条件的清单。
“结果统计”可根据指定的时间段、机组号、QSR/非QSR，自动统计不同专业的计划执行项目数、实际执行项目、未开展项目、已开展未合格项目、利用裕度超A%项目、一次合格项目等，并形成定期试验统计表。
“趋势分析”可查询定期试验任意关键参数对应试验结果在选定区间内的趋势图。
“定期试验报表”可查询选定时间段内定期试验项目已执行清单或计划执行清单。
1.6 系统维护模块
系统维护模块可对数据库、定期试验日常项目、定期试验大修项目模块进行维护。维护后需填写的《维护信息单》。待模块维护后，《维护信息单》保存至软件数据库中。
1.7 项目变更模块
项目变更模块通过填写《定期试验项目变更审批单》执行裕度审批、定期试验大纲变更、大修执行机组状态变更功能。《定期试验项目变更审批单》由项目信息、变更类型、变更原因、变更时间、审批路径设置组成。待《定期试验项目变更审批单》审批通过后，自动保存至软件数据库中。定期试验管理人员可据此对软件数据进行调整。
2 总结
定期试验管理软件通过对工作流程的改进和优化，在降低定期试验管理的人员投入，简化执行处室的项目审批流程和工单关闭流程，提高定期试验工作效率方面预期将起到良好效果。同时，该软件还将提供定期试验结果的统计和趋势的分析手段，随着定期试验结果的不断累积，在设备可靠性分析中将发挥重要作用。
篇10
关键词：IT运维；管理平台；设备管理
1 设备管理平台的需求及流程设计
从设备管理的角度来看，整个运维管理平台应该能够包含[1]：台帐管理模块、系统管理模块、文件管理模块以及报表统计模块等。台帐管理模块包含设备的名称、类型及型号、序列号等疾病信息；系统管理模块主要对平台内相关的代码和权限等进行管理，以记录设备管理平台使用人员的操作记录；文件管理模块可以对设备的维护记录、设备采购、报废信息等进行管理。
设计基于IT运维的设备管理平台时，可以在遵循上述需求分析的情况下，进行数据库、中间代码以及前端等的设计，设计后同时进行数据库、中间件及客户端的部署。考虑到以后的管理及维护成本，可以采用B/S架构；数据库选择Mysql，其高性能及高并发性会给设备管理平台提供高效的数据引擎支持；为提供报表管理功能，设备管理平台也会提供数据导入导出工具。
基于IT运维的设备管理平台能够对设备管理的全过程进行动态管理，不论是进行设备的采购、维修还是报废等工作，都需要根据设备管理的操作流程进行，而且设备管理流程的每个步骤都要能够根据操作人员的角色进行业务处理，从而快速、高效的管理设备。作为平台的核心功能模块，设备故障处理要经过故障申报、故障处理以及处理结果等步骤，每一步骤完成后会显示步骤的操作人员和处理时间。
2 IT运维管理平台的功能模块
缺陷管理模块中可以创建关联的变更单，此时有缺陷的被管理设备的状态被标记为“搁置”，缺陷问题被创建后，一旦缺陷问题被成功关闭，则可以根据缺陷的解决状态进行设备的状态变更，解决的缺陷其状态被变更为“已解决”。缺陷的记录一般由发现缺陷的人员进行，缺陷验收合格后，设备管理平台的运维人员需要注明缺陷处理的相关信息，并注销缺陷。
IT设备经常会遇到变更关联设备的情况，如果某设备有关联的设备存在，那么此设备的关联关系在被关闭前，此设备不能被移除。设备的变更管理包括用户接入、安装调试、检修以及配置管理等内容，如图1所示：
图1 设备变更管理的内容
其中，用户接入指的是用户提交设备变更单，对于处理完成的变更单，如果其达到预期目标，那么此变更单相关的设备变更流程即可关闭，否则此变更处理流程需要被返回。检修人员作出的检修申请形成变更申请单，如果此变更申请单涉及到的是通信的检修或停退，需要判断此检修过程是否存在检修计划，目的是让用户明确的知晓，从而指导设备管理[2]。安装人员提交安装调试的变更申请，只有当所有变更资料都提交完后，才去验收安装调试过程是否合格；如果安装调试过程达到预期目标，则可以关闭此变更申请单。配置管理变更申请一般是由用户提出，配置管理人员会判断是否需要备份处理。
日常巡检管理模块根据巡检的设备来执行不同的标准，巡检记录可以根据不同的预定义规则生成。设备管理平台的运维人员根据巡检标准、巡检周期等进行设备的定期巡检，并记录相关的巡检日志。相关设备的维护人员对此巡检日志进行分析，并给出是否正常、是否有缺陷等结论，如果发现设备的缺陷，则依据前文介绍的缺陷管理模块进行处理。
3 基于IT运维的设备管理平台
基于IT运维的设备管理平台的设备管理流程包括请实现、事件管理以及配置管理，其总共规划目标是实现设备管理的快捷性、全局性以及经济性。从整体结构上而言，设备管理平台从上而下分为表示层、业务逻辑层以及数据访问层三层。表示层用户和用户交互，业务逻辑层制定业务规则并实现相关的业务流程，充当表示层和数据访问层之间的桥梁；数据访问层的作用是访问数据库。这三层之间的依赖关系是向下的，底层无法感知上层的存在，对上层的任何设计上的改变都不会影响底层。
设计基于IT运维的设备管理平台的目的是对基于IT运维的设备管理、维护中的各项功能及非功能性需求进行设计，其中最重要的一部分是数据库，不仅要明确数据库的表名、字段名等数据信息，还要进行存储过程等数据库脚本的扩展。具体设计数据库时，要考虑系统模块相关概念的设计、数据关系图设计以及数据的逻辑结构设计等。使用设备管理系统的人员主要是系统管理员、维护人员以及一般用户，不同角色应该有不同的操作权限。数据逻辑结构的设计包括设备数据库关系图、故障信息数据库关系图以及系统管理数据库关系图等[3]。设备数据库关系图包括设备的信息表、设备相关资料表等；故障信息关系图包含发生故障设备信息表、设备备件维修信息表等；系统管理关系图包含设备单位信息表、厂商信息表等等。
参考文献
[1]李晓禹.基于SOA的设备管理信息系统平台的研究与实现[D].南京大学，2013.
[2]孙艺新.大型电网企业特高压设备运维检修模式浅析[J].中国设备工程，2014.
