首页范文工程变更管理流程十篇工程变更管理流程十篇

工程变更管理流程十篇

发布时间:2024-04-26 08:31:14

工程变更管理流程篇1

按照UCm的方法,我们也将Cpmm的组成部分抽象为不同的工作流,其中最重要的工作流程包括:

1、变更预估流程(ChangeForecastprocess,CFp);

2、变更请求与处理流程(Changeapplyandmanageprocess,Camp);

3、变更评估流程(Changeevaluationprocess,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

关键词:载人航天器;软件需求;变更控制;改进流程

中图分类号:tp301文献标识码:a文章编号:1672-7800(2013)006-0023-03

作者简介:李皖玲(1980-),女,硕士,中国空间技术研究院载人航天总体部工程师,研究方向为载人航天器信息系统。

0引言

软件需求在软件产品的整个生存期中占有重要位置,是软件工程项目的依据和出发点,无论是软件开发还是软件维护,都是以满足软件需求为最终目的[1,2]。

在实际工程研制中,用户需求变更的现象不可避免。美国StandishGroup公司对8400个软件项目的调查和研究指出3种最经常使项目遇到困难的因素,其中,不断改变的需求和规格说明占所有项目的12%[3]。同时,eSpiti机构根据3800个调查人的回答,管理(更改)需求是被调查者回答的软件研制过程中最难解决的两个最大问题之一[4,5]。以航天某型号的某个子系统为例,共有软件配置项14个,全生命周期共发生需求变更34次,涉及软件11个,占到软件总数的78.6%,发生过4次及4次以上需求变更的软件有4个,占到软件总数的28.5%。

如何及时、有效地控制软件需求变更问题,已成为软件工程化管理不可回避的课题。如果不能对需求变更进行及时有效的控制管理,很可能对整个软件项目造成“牵一发而动全身”的影响[6]。

1需求变更原因及管理现状

1.1需求变更原因

载人航天器软件工程化的一项重要工作是对变更进行控制,以将变更对工作量、工期和质量的影响降低到最小。根据型号研制工作经验,造成需求变更的原因可总结为以下方面:

(1)系统复杂导致需求理解不完整、不明确。载人航天器研制是个庞大的系统工程,由13个分系统构成,一个系统级功能及任务需层层分解至某个软件或某几个软件来实现,带来软件内部、软件与软件之间信息流设计复杂、信息交互频繁。系统需求的复杂性,带来了对软件需求理解的不确定性及不完整风险。

载人航天器软件需求分析需经过系统级、分系统级、配置项级三级开展,在需求分析阶段,若系统级或分系统级未对软件需求进行深入论证、分析,软件研制人员也未重视分系统级及系统级人员的参与,导致需求分析工作各自独立,没有设计出良好的软件结构适应变化,造成后期频繁的需求变更。

(2)工程周期长导致需求不断加以完善。载人航天器的软件研制需经历初样、正样阶段,一般研制周期为2~3

年。在初样阶段,建立初步的软件功能基线后,开发工作即开始启动。随着软件研制工作的深入,分系统会提出新的需求。同时,载人航天器系统与子系统按照同一节点进行开发,即使建立的功能基线是无遗漏的、明确的,但随着工程深入,其中的某个子系统发生任务变更,由此带来该子系统软件或其相关软件需求发生变化。

(3)软件需求本身特点。软件需求作为整个软件项目的最关键的一个输入,同硬件产品不同,具有模糊性、不确定性、变化性和主观性等特点,它的自身特点就决定了变化的可能[5]。

1.2需求变更管理存在的问题

载人航天器软件工程化的需求管理方法经过近10年的运行和实践,确保了多艘航天器软件安全、稳定运行,详细流程见图1所示。但目前需求变更控制流程仍然存在待改进地方,主要体现在以下方面:

(1)需求变更控制方式单一。载人航天器软件工程化对需求变更的控制方式单一的主要表现,其一是未区分软件研制不同阶段需求变更的处理流程,对需求变更控制和管理均是按照图1所示的流程进行,实际上,初样和正样阶段的需求变更,对计划和质量的影响是完全不同的;其二是对所有的需求变更一视同仁,未区分关键性需求和改进性需求,致使需求变更频繁发生,导致工作量和资源投入的不理性增加。

(2)变更影响域分析滞后。对于分系统提出的变更,多是从技术的角度出发,经过系统级、分系统两级论证通过后,以技术要求方式下达。一旦软件研制单位接收到技术要求,按照软件工程化要求进行软件变更及影响域分析时,发现由于此次需求变更对软件架构和研制进度带来较大影响,并引入了质量风险,也只能按照影响域分析结果进行变更。

2需求变更管理流程改进

设计一个清晰的、明确的、可控的、有效管理的需求变更工作流程,有利于促进软件开发过程中的人员分工和合作;有利于对需求变更的处理阶段进行实时监控和跟踪[7]。

需求变更控制改进后流程见图2所示。

2.1变更申请

软件需求变更申请可由需求方(分系统级)提出,也可由开发方(软件研制方)提出。

提出的软件需求变更由开发方归入“需求变更池”进行管理,“需求变更池”由需求变更时间、需求变更定义、变更原因、提出变更人等信息组成。

根据软件研制特点和软件进展阶段,需求方定义需求变更周期,每一个需求变更周期对“需求变更池”的需求进行统一处理。如在初样尚未进入编码阶段,需求变更周期定义为两周,若在初样已完成编码阶段,需求变更周期定义为一个月,在正样阶段,将“需求变更池”的处理周期定义为事件驱动。在每一个需求变更周期内,需求方将与开发方一同,对“需求变更池”内的需求处理一次。

采取“需求变更池”管理的好处是将需求变更流程变为周期性,既能确保所有需求申请都能够得到及时处理并经历正规的需求管理流程,又能尽可能地减少对软件研制过程的干扰。

2.2影响域分析论证

当需求变更周期到达时,需求方和开发方将一同进行变更的影响域分析。

若需求方提出需求更改申请,需与软件经理共同编制需求更动论证及影响分析报告。需求方从更动的必要性、可行性及变更带来的影响方面进行论证,即是否必须进行设计变更才能满足预期的性能指标要求和使用要求,或是对此有明显改善、提出的变更技术上是否合理,工程上是否可行,变更对产品的可靠性、安全性及接口的影响。开发方根据需求跟踪矩阵,标识并实施因分配需求的更改而引起的项目计划、软件工作产品(包含文档和代码)和活动的更改。开发方的影响分析包含软件功能、性能等技术类分析,还应包含管理类的非技术影响分析。

若开发方提出需求更改申请,开发方单独编写需求更动论证及影响分析报告,需重点从软件配置项角度论述更改带来的影响。

在该流程中,影响域分析论证由需求方和开发方在申请得到响应的第一时间内共同完成,需求变更影响域分析将更全面、更系统也更具体。同时,通过影响域分析,将需求方变更也纳入到了工程化管理,既对需求方更改进行了控制,以减少不必要的软件变更,又使得开发方能够及早地参与影响域分析论证,及时应对需求变更。

2.3需求变更评审

软件配置控制委员会(SCCB)(组成人员中包含需求方、软件专家)评估需求变更论证及影响分析报告。

2.4需求变更分级管理实施

在进行需求变更评审时,需对需求变更进行定级,针对定级情况实行分级管理,以达到对需求变更的控制和管理。

根据变更影响域分析,可将需求变更定义为4个级别。一级为变更关键性需求,如若不变更,意味着整个项目不能正常交付使用,前期工作也会被全部否定;二级变更影响后续关键性需求,不影响前面工作内容的交付,但不变更,新的项目内容无法提交或继续;三级变更为后续重要需求,如果不被满足会令整体项目工作的价值和开发人员技术价值下降;四级需求是改良性或可选性需求,没有实施变更并不影响已有功能的使用,代表个人喜好[8,9]。

一二三等级变更,需实施更改;对于四级需求,如果时间和资源条件允许,可实施更改或是后续版本更改。

需求方提出的变更申请,需求方对分配需求进行更改,将变更后的《软件任务书》批准、受控,下发至软件研制单位。开发方接收到正式变更要求,类同开发方提出的变更申请,按照软件工程化管理规定,办理更改的三单审批流程,实施更改。

2.5通报和跟踪

SCCB确认需求已进行实际的变更。软件配置管理工程师通知所有受影响的小组和个人。开发方将因更改而引起的情况通报给受影响的组和个人,对已标识的相关更改进行跟踪,直到更改结束。

3需求变更管理实践

上述需求变更管理流程,已被成功应用到某型号某软件研制过程,该软件为嵌入式C程序,代码规模约为12000~15000行。在实践过程中,初样阶段“需求变更池”处理周期为1个月,正样阶段处理周期定义为“新的需求提出”。至软件交付时,该软件共发生软件需求变更15项,需求方提出需求变更6项,开发方提出需求变更9项,通过需求变更评审,需求变更一级为3项、二级为4项、三级为2项、四级为6项。

通过需求变更管理,该软件共发生的15项需求变更中,实施了13项,有效地控制了软件需求变更比率。在未增加开发人员和资源情况下,同软件开发计划相比,软件过程文档编写数量减少了16份以上,初步预算节省软件工程组人员工时80人时以上;同时软件研制过程可见、受控,软件研制进展顺利,交付进度较计划时间提前了约60天;软件在交付使用后,其功能性能满足用户需求。

4结语

通过分析软件项目开发过程中需求变更产生的原因,提出了软件工程化管理过程中存在的问题,并在此基础上提出了需求变更管理主流程,该流程保证变更实施在可控范围内进行,将影响域分析提至系统级层面,并将需求变更实施分级管理,从而将变更带来的影响尽可能地降到最小。需求变更管理流程真正将需求方、开发方与需求变化、变更请求和项目管理紧密结合在一起。通过某型号某软件3年的软件工程化管理实践,证实该管理流程使需求变更在项目开发中得到了有序有效管理,保证了项目的顺利完成,提高了项目的质量。

参考文献:

[1]韩万江,姜立新.软件项目管理案例教程[m].北京:机械工业出版社,2005.

[2]张海藩.软件工程[m].第1版.北京:清华大学出版社,2006.

[3]eRaCaRYa,mieCZYSLaw.anarchitectureforsoftwarethatadaptstochangesinrequirement[J].JournalofSystemandSoftware,2000(50).

[4]StanDiSHGRoop.Usersurveyreport[R].europeanSoftwareprocessimprovementtraininginitiative,1995.

[5]秦众森,李娟.需求变更管理过程机器工具分析与展望[J].计算机工程与设计,2009(11).

[6]SUZanneRoBeRtSon,JameSRoBeRtSon.掌握需求过程[m].王海鹏,译.北京:人民邮电出版社,2003.

工程变更管理流程篇3

关键词:技术资源管理系统;tRS;设计工作流;变更工作流

中图分类号:tp311文献标识码:a文章编号:1009-3044(2012)17-4110-03

技术资源管理系统(technologicalResourcemanagementSystem,以下简称tRS或系统)是作者公司总结多年的大型变压器制造业的相关知识经验研发升级而成的新型综合管理系统。tRS的目标是把逻辑上将各个技术信息孤岛集成起来,使之成为一个串行化的逻辑整体并建立一个并行化的协作环境,利用计算机系统对整个产品的售前、设计研发、售后过程进行控制,同时通过设计研发过程逐步建立虚拟的产品模型,最终形成完整的产品描述、生产过程描述以及生产过程反馈数据。tRS拥有强大的产品数据管理、工作流管理、工艺数据管理、文档管理等功能,其中工作流管理是tRS重要的基本功能之一。

工作流是针对具有固定程序的常规活动而提出的一个概念,通过将工作活动分解成定义良好的任务、角色、规则和过程来完成执行和监控[1]。工作流管理系统是一个真正的“人-机”系统,用户是系统中的基本角色,是直接的任务分派对象,他或她可以直接看到电脑针对自己列出的“任务清单”,跟踪每一项任务的状态,或继续一项任务,而不必从一个模块退出,进入另一个模块,搜索相应任务的线索。前者是面向功能或对象的,而后者是直接面向用户的。这样,用户的任务分派和任务的完成状态,可以被最大程度地电脑化和受到控制[2]。过程用来指示某个任务完成后需要进行的下一个任务。规则用来控制过程中角色的权限和对任务中所承载的对象进行必要的标准化检验及改变对象的生命周期状态。

1设计工作流

在产品开发的过程中,首先由设计项目主管制定开发方案和实施计划,向设计人员下达设计任务,设计人员按设计要求进行设计。然后工艺主管下达工艺计划(可与设计主管同时下达计划),工艺人员按照计划进行工艺会签任务。最后由标检人员对图纸工艺路线进行标准化检查,没有错误了才能归档图纸下发到生产等部门。流程如图1所示。

1.1设计者提交审批

系统为设计者提供了提取图纸标题栏和Bom的CaD集成工具,在提取时进行必要的标准化检查,如果通过检查那么则生成相应的部件并创建产品结构,否则提示设计者进行修改。而标检部门可以修改检查规则以适应不同时期企业标准化的需要。这样做的好处就是在数据的源头保证准确性,避免以后出现一物多号(物料号)的情况。新产品开发往往是在老产品的基础上进行导变变形设计,系统对Bom的配置管理置管理提供了相应的功能,设计人员可以只把新图纸或文档提交到流程中同时对各自设计的部件或整个产品进行配置,从而快速生成设计Bom,提到工作效率。此时图纸、部件的生命周期状态是正在工作。

1.2设计部门审批

设计完成后填依次进入校对、审核、审定任务。审批者可以直接在图纸上进行批注,当然这些批注在最后图纸归档和打印时会被隐藏掉,因此不必担心会把图纸审批过程中的批注带到正式的图纸版本。当审批者同意时流程进入下一个任务节点,签字工具会自动在图纸上留下审批人签名;若发现错误可以在审批说明中写明问题并将错误图纸勾选出来单独退回到设计任务节点,这样的好处是设计者能够立刻知道是那张图纸出了问题而不用每张图纸都打开。此时图纸、部件的生命周期状态由正在工作变为正在审阅或已退回。

1.3工艺部门审批

经过设计部门审批后,流程进入工艺部门,工艺会签者在任务列表处接收设计信息,开始设计工艺卡片。如果工艺会签者发现图纸或Bom有错误可在审批说明中写明问题并将它们勾选出来单独退回到设计部门,其他图纸可以提交到工艺校核任务节点继续审批流程,这样退回到设计的图纸由设计者进行修改,工艺校核者可以继续做他的工作而不必等待设计修改完图纸,整个流程由原来的单流程任务变为多流程并发任务,各个活动的任务由系统分配权限进行控制,保证每个任务数据的正确性和整个数据的完整性。工艺校对者如果发现工艺路线有错误则可以将工艺卡片退回到工艺会签者,这样在工艺部门有形成一个小的审批流程,小流程与整个流程既有联系又要区分权限,目的只有一个就是尽最大可能减少等待的时间,充分利用各个活动任务的人力技术资源。当工艺会签者同意时流程进入下一个任务节点同时在图纸上自动签名。

1.4标检部门审批

经过工艺部门审批后,进入标准化部门,标检者在任务列表处接收设计信息,进行标准化检查。

如果标检者发现图纸或Bom有错误可在审批说明中写明问题并将它们勾选出来单独退回到设计部门,其他图纸只需要等待这些图纸合格后统一。任务退回到设计部门后由设计人员对图纸、Bom进行修改,然后再进行设计部门审批。如果不是图纸缺失的情况这时设计人员可以自行决定是否跳过校核、审核节点以节省时间提高效率,但是不能跳过审定节点和工艺过程;如果是图纸缺失的情况那么需要设计人员添加图纸和提取Bom然后完整的进行整个审批流程,只有这样才能保证图纸上的签名信息是完整的。那为什么不把流程中的参与者都先保存起来等到流程结束在签名?站在流程参与者的角度来思考:每个任务都在图纸上签名非常直观,能够非常清楚的看到上个任务的负责人是谁,这样做符合流程参与者的传统习惯,使他们对软件的体验度大大提高。

1.5审批结束

整个流程完成之后系统将自动打印矢量不可编辑的图纸(如:dwf文件、pdf文件等)并将部件归档。此时图纸、部件的生命周期状态由正在审阅变为已。

图1设计流程

2变更工作流

在产品生产制造过程中出现问题时、当客户需求发生更改时、供应商发生变化时、以及标准化部门新的标准化规则时,都可能提出图纸变更的需求,因此图纸变更是制造型企业生产经营业务活动中一项十分重要的业务。虽然变更是十分重要的,但是无论发生什么样的更改,都要保证产品数据的完整性、有效性、一致性和可追溯性。只有做到以上几点才能在以后的工作中避免重复错误的发生,减少图纸更改的次数,形成知识的积累和沉淀,为设计人员和管理人员提供历史版本图纸的快速查询,提高技术人员的技术水平和企业的生产效率。

变更工作流可以单独进行也可以嵌套在其他流程中进行,它并不是一个单一的工作流,而是根据不同的需求采取不同的流程配置。变更工作流主要分为三种流程:变更申请、设计变更、工艺变更。

2.1变更工作流

当生产、市场、采购部门要求变更时变更工作流是根据变更申请通知单的结果来决定是否运行实施的。需求部门发出变更申请,经过本部门的负责人的批准后发送到设计或工艺部门进行申请变更。如果设计或工艺产品经理同意则发起变更工作流;如果不同意则驳回申请,让编制者修改申请或者直接结束流程。如果需求部门认为需要变更而设计部门认为不需要变更则需要公司高层领导进行仲裁,依仲裁结果来决定是否发起变更工作流。流程结束后图纸归档Bom及部件,通知相关部门负责人查收变更结果。流程如图2所示。

图2变更申请

2.1.1变更申请

编制者提交变更申请,设定变更图纸的内容和发放范围,然后提交到中间审批环节。中间审批环节由n个任务节点构成(n>=0)。中间审批环节完成后到批准任务节点,批准者同意后到设计或工艺的产品经理处审批,产品经理决定是否实施变更。这其中的每个任务都可以在变更申请的内容中添加批注并保存相应批注人,任务完成时自动添加审批人签名,这样可以保证每个变更申请的有效性和可追溯性。

2.1.2变更实施

当变更的对象是图纸、Bom、文档时则激活设计变更流程;当对象是工艺卡片时则激活工艺变更流程。

2.1.3变更完成

流程结束后系统将变更申请归档并按照编制者设置的发放范围发送email通知相关部门负责人查收变更结果。

2.2设计变更

当设计部门要求变更时不需要提交变更申请,直接进行设计变更就可以。设计产品经理设定变更计划,指派设计人员修改相应的图纸、Bom、文档,其中图纸、部件的新版本由系统自动生成,然后工艺主管下达工艺计划,工艺人员按照计划进行工艺会签任务。接着由标检人员对图纸工艺路线进行标准化检查,最后新版本的图纸、Bom、文档。整个流程和设计流程规则一致,不再此冗述。

2.3工艺变更

当工艺部门要求变更时也不需要提交变更申请,直接进行工艺变更就可以。工艺产品经理设定变更计划,指派工艺人员修改相应的工艺卡片,系统自动生成相关部件的新版本,保证数据的完整性和统一性。工艺者完成修改任务后交由工艺校核者进行校核工作。接着由标检人员对工艺路线进行标准化检查,最后新版本的部件及工艺卡片。流程如图3所示。

图3工艺变更

3结束语

trs中的工作流高效、简便、实用、注重细节。在信息化实施的项目中起到非常重要的作用并获得了用户的肯定。用户对工作流的肯定是对我们最大的支持和鼓励,我们将沿着使工作流更好的方向继续探索下去。

参考文献:

工程变更管理流程篇4

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.44m变更实施部门对变更过程中可能出现的意外要有应对预案;

4.2.54m变更实施部门及相关部门需修订变更涉及事项(如工程图纸、Sop、Fmea、控制计划,Sip,eCn,Bom,QC工程图,工艺流程图等);

54m变更管理类别:送样,申请,记录

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批作出标识。

工程变更管理流程篇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.

工程变更管理流程篇6

自从2002年和来自CSC的HowardSmith共同撰写《业务流程管理:第三次浪潮》(Businessprocessmariagement:thethirdwave)后,就经常有人问我Bpm的发展趋势。但是最近我才学会怎么回答,多亏了我的姐姐。有一天,姐姐告诉我关于一个外地人询问如何去一家餐馆的故事,答案竟让我惊讶:“直走,随时调整方向。”

当然了,这正是我一直该给Bpm新手的指示。很多Bpm的新手容易误认为采用Bpm是一个顺理成章的流程,有点像过去他们购买eRp和CRm软件包的流程和体验。你仅仅需要安装这些“可恶”的东西,难用、昂贵,还可能耗时,“砰”一下,你撕破并替换这些老软件,不再对其感兴趣,然后运行新的软件。

对于Bpm来说,情况并非如此,因为业务流程有不同的形式和规模,并且拥有一个恶习就是在应答现实世界的快速变更中经常改变。再加上,当另一部分现实世界摆出他丑陋的嘴脸,所谓的“异常”时,事情变得非常的有趣。流程类型

让我们列出流程类型的一个简化领域,通过需求的异常处理度来分类。

直通事务处理

直通事务处理(Straight-thrutransactionprocessing):整合式Bpm。其实,很多早期的Bpm几乎都是备用Backoffice整合。

在这种情况下,Bpm成为了下一代企业应用整合(eai)软件,其实质就是一个it开发者的工具,没有必要流程分析。直通事务处理类似于高尔夫球中的一个洞,有一些异常可以通过它来处理。这几乎都和效率,以及严格业务控制相关。满足这些业务流程表示,Backoffice是业务流程管理的战略形式。

结构化工作流

结构化工作流(Structuredworkflow):传统工作流式Bpm。给工作重定路线和需求权限是结构化异常处理的两种途径,这已经让传统工作流变得非常有用。工作流已经变得更加灵活,尤其当和业务规则引擎组合的时候,业务引擎给分析师相当多的异常处理能力。由于工作流的能力可能是动态变化的,这是对人系统(system-to-human,S-2-H)自动化的主要概念,其中工作流时预定义的,仅仅把人当作装配线上的齿轮一样,基于许多可能发生的异常,通过选择把任务从一个状态移动到另一个状态。这仍然如同高尔夫球赛,直通流程在任何时刻都表示一个球洞,而工作流要求处理已定义的异常:沙土障碍,与队友协作,经常和裁判商谈。但是工作流的最终目标是:把球敲进洞。

特殊case管理

特殊case管理(ad-HocCasemanagement):每一个case就是一个异常。当每一个流程都是例外时,事情就变得非常有趣了。我们可以从Derekmiers的著作中提取一个特殊的case管理实例:“简化不能实现核心业务流程的全面自动化”。这种特殊流程不足以成为标准。

以医疗和金融为例,需求的是在员工开展工作的时候给与他们帮助和支持,尽可能实现自动化检索信息。在这种情况下,最有效的手段就是采用一个通用的流程来维护手中的case,这个流程可由任意数量的支持流程来支持,每一个支持流程都和通过用户的判断和工作需求而不是由预算来决定的parentnas关联。事实上,知识工作者的角色,在流程范畴中流行。这正好和工作流机器中把人当作齿轮的系统相反。现在,人们在更高的层面上,在特殊的流程中把标准流程视为由人引导的齿轮。

人机交互管理

人机交互管理(Humanin-teractionmanagement):创新流程。“到没有流程抵达的地方”或许是区分创新的、敏捷的、合作的,由人驱动(human-drive)的工作流程的最直观的描述方式。这样的流程既不是人一机系统(human-to-system,H-2-S)模式,也不是系统一人(system-to-human,S-2-H)的模式。而是人一人(human-to-human,H-2-H)交互流程。

这种工作流程需要人的判断、导航和交付来决定下一个步骤。其结构是一点点浮现的,而不像工作流程中的那样被预先定义好。换句话说,这些工作流程会根据工作的进度不断的改变自己的结构和参与者。这些流程超越了组织的边界,尤其是当一家企业拥抱开放创新以获取竞争优势。支撑人机交互管理需求的技术不同于整合和工作流式的Bpm。它需要一个能够处理“交付处理”而不是“信息处理”的人机交互管理系统(HimS)。

Bpm之旅

现在你已经拥有流程管理了。可是,没有“Bpm”这么一回事,至少在流程分类和支持工具中没有。总体来说,整合式Bpm要比直通事务处理更好。

对于任务挖掘和路由决策制定来说,工作流式的Bpm更优越。不过,在某种程度上和马斯洛的需求层次理论很相似,当我们转移到特殊case管理类的业务流程时,Bpm的价值从效率向对用户操作的“应答”转变。

最终,这是异常处理的终点,此特殊的状态叫做创新,表示一个想要自我实现的企业最高层面的价值。而这一切都与人机交互管理所需的技术相关。

工程变更管理流程篇7

关键词软件配置管理;软件生命周期;KCFlow

DoiDoi:10.11907/rjdk.162381

中图分类号:tp301

文献标识码:a文章编号文章编号:16727800(2017)002002603

0引言

随着软件规模的日益增大,软件复杂度逐步提高,软件产品处于不断更新变化中,为了确保整个软件项目生命周期内产品的完整性、一致性和可追踪性,必须对软件进行配置管理。

软件配置管理(SCm,SoftwareConfigurationmanagement)指标识和确定软件系统配置项的过程,在软件系统的整个生命周期内控制这些项的投放和更改,记录并报告配置的状态和更改要求,验证配置项的完整性和正确性[1],通常包括配置标识、配置控制、配置状态记录、配置审核等活动。软件配置管理是整个软件开发生命周期中一个非常核心的管理过程,贯穿了从需求分析、架构设计、项目管理、开发、集成及测试的全过程,可以有效管理配置项版本,记录配置项开发过程,保证软件质量,提高软件重用率。

在软件开发这个庞大而复杂的过程中,涉及到各方面人员,产生许许多多产品。由于规程过于繁琐,手工方法实施软件配置管理是难以想象也是不可能的,因此,有效的软件配置管理需要结合工具来实现。使用软件配置管理工具,可以确保软件项目中基线和配置项随时保持条理清晰,迅速找到工作产品,保证工作产品的版本、内容不会出错,提高管理水平。

1工具介绍

软件配置管理工具KCFlow采用C/S架构,以软件配置管理项的版本管理为核心,具有软件配置策划管理、变更控制、产品一致性管理、软件问题追踪管理、软件配置审计管理等功能,实现了对配置管理工作的全流程、全方位支持。

KCFlow具有以下特点:C/S软件架构使项目中的各类人员可以在工具提供的平台上分布式工作,确保各项工作有序、规范地实施;具有策划配置项标识功能;支持独立的配置项,单独策划入库、出库和更动审批,能够自动按照策划结果实施入库、出库和更动控制;支持基线的多版本管理功能;支持用户自定义软件问题类别、问题级别、更动类别等,以适应不同的使用需求;支持多个软件开发人员在线提交软件入库申请、出库申请、更动申请等。

2软件配置管理

软件配置管理是Cmm重要的过程域,本文结合配置管理工具给出配置管理实施方法。

项目启动后,配置管理组根据项目情况策划配置管理活动并建立配置管理系统。首先制定配置管理计划,根据计划建立配置管理系统,通过版本控制、变更控制、基线管理和配置审核等方法,对配置管理系统中的工作产品实施控制和监督。软件配置管理流程如图1所示。

图1软件配置管理流程

2.1配置管理计划

经过批准的软件配置管理计划是实施软件配置管理活动的依据[2]。在进行配置管理前应根据项目的具体情况制定软件配置管理计划,内容包括:

(1)确定配置管理机构和人员职责,审批流程。组织机构主要有软件配置控制委员会、软件配置管理组。软件配置控制委员会负责出入库控制、变更及基线的建立和;软件配置管理组负责相关制度的建立和维护、工具的推广、培训和技术支持、配置管理审核等。

(2)描述具体配置管理活动,包括标识要纳入配置管理的配置项,规定提交时间、确定项目研制各阶段的基线、基线建立的时机和配置管理项等。配置项根据控制力度分为基线配置项和非基线配置项两类。基线配置项一般包括软件研制任务书、软件需求规格说明、设计说明、设计文档、测试文档、代码、用户手册等;非基线配置项包括计划类文档、开发环境、会议纪要等。标识配置项为每个软件配置项赋予唯一的标识符。在软件开发生存周期中,软件配置项标识应包括文档标识、程序标识和数据标识等[3]。

(3)确定更动申请流程及更动申请方法。

(4)描述配置管理报告内容、报告时机、报告人和通告对象等。

(5)制定配置审核时机、审核内容及审核问题的解决方法,软件配置管理所使用的工具、技术和方法。

使用KCFlow配置管理平台,制定配置管理计划,并依据配置管理计划实时自动化约束配置管理活动,客观记录配置管理活动。KCFlow可对配置管理计划中的机构组织、基线、基线下包含的配置管理项、工作产品标识、问题类型、问题来源、更动流程、修改类别、项目基本信息等进行配置策划。一般基线策划有3条:功能基线、分配基线和产品基线。配置项标识应按照相关的配置项标识规范进行,一般文档、程序标识采用以下格式表示:文件名称英文缩写V主版本号.次版本号;问题类型可分为程序、文档、数据库等;问题来源有计划、方案、设计、编码、数据库、测试、使用和维护等。

2.2配置管理系统

配置管理计划经过评审后,由配置管理员依照配置管理计划建立开发库、受控库和产品库,对库结构进行策划,明确基线内容,定期备份配置管理库,为相关人员分配权限并发送用户帐号信息单给相关人员。

开发库、受控库和产品库应独立管理。开发库存放开发过程中需保留的各种信息;受控库存放已通过评审且作为阶段性产品的软件配置项;产品库存放已定型(鉴定)供交付生产、检验验收的软件配置项。在KCFlow中创建受控库一般包括功能基线、分配基线、产品基线及非基线配置项。功能基线包含软件研制任务书等文档;分配基线包含软件需求规格说明、接口需求规格说明等文档;产品基线包含软件设计说明、接口设计说明、软件测试说明、软件测试报告、固件保障手册、源代码、目标码、软件版本说明、软件研制总结报告、软件配置管理报告、软件质量保证报告等;非基线配置项主要包含计划类工作产品。

2.3配置控制

配置控制是配置管理的组成部分,包含评估、协调、批准/拒绝、配置项的变更[4]。配置库建好后,配置管理员按照配置管理计划进行日常的配置管理活动,主要包括版本控制、变更控制、基线管理等。

2.3.1基线管理

基线是软件生命周期中各开发阶段的一个特定点,它的作用是把开发各阶段工作明确划分,使本来连续的工作在这些点上断开,以便于检查和肯定阶段成果[5],是进一步开发的基础。

在软件生命周期中主要有3种基线:功能基线、分配基线和产品基线。功能基线是开展软件研制工作的依据,一般是在软件研制任务书评审并纳入受控管理后建立;分配基线在软件需求规格说明评审并纳入受控管理后建立;产品基线在产品后建立。

基线包含的配置项全部入库后才可建立基线,配置管理员提交《基线建立和申请单》,通过软件配置控制委员会审批通过授权后,方可建立和基线。基线后,配置管理员要把基线的结果通告给相关人员,通告内容包括基线名称和标识、所包含的配置项及配置项版本等信息。

对基线的变更需要通过正式的变更流程来完成。首先提出变更请求,然后进行变更评估,变更批准后再进行变更。变更评估包括:软件变更分类、技术影响分析、接口影响分析、进度及预算影响分析。

2.3.2变更控制

对已进入受控库和产品库的任一软件配置管理项的更改,要履行规定的申请和审批手续。配置管理工具KCFlow提供了两种更动流程供选择,一般采用的更动流程是:填写问题报告、提出更动申请、更动出库、实施和验证更动和更动入库,具体更动流程如图2所示。

(1)发现问题,并填写《问题报告单》。变更人发现问题后首先填写问题报告单,在问题报告单中详细描述问题,说明问题来源并对问题进行分析,确定问题类型。

(2)提出更动申请,填写《更动申请单》。《更动申请单》要详细填写问题来源、问题类别、问题级别、更动类型和修改类别等,描述更动方案、影响域分析及验证办法,待更动申请批准后方可进行更动。

(3)更动出库。更动申请通过审批后,更改实施人填写《更动出库单》,审批通过后,检出待更改的配置项准备实施更动。待更改配置项出库后,处于待更动状态,禁止其他人使用。

图2更动流程

(4)实施和验证更动。更动出库后可由变更实施人对待更动配置项实施更改,并请同行专家验证变更结果。验证结果合格后将变更后的配置项更动入库,如果验证没通过,则重新实施更改。

(5)更动入库。更动完成并通过验证后,变更实施人填写《更动入库申请单》。审批通过后,将更动后的配置项更动入库。

2.3.3版本控制

版本控制是全面实施软件配置管理的基a,其目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,保证产品的可追溯性[6]。对配置项在初次完成时确定初始版本,在每次更改后确定新的版本。版本号由主版本号和次版本号组成,当发生更改时,若变动较大,次版本号加0.1,若变动较小,次版本号加0.01。

2.4配置管理记录和报告

配置状态记录和报告通常称为配置状态纪实。配置状态记录主要对配置管理活动进行记录和报告,一般包括以下内容:配置项纪录(名称、标识和版本)、变更纪录、基线纪录、出入库纪录、审核纪录、备份记录和测量信息等。

配置管理工具KCFlow可以根据配置库中的内容生成配置状态报告,确保配置管理报告和配置管理库的客观一致性。在项目每个阶段结束时,配置管理员从KCFlow导出该阶段的配置状态报告,总结该阶段的配置管理活动,统计配置管理相关数据,并将配置状态报告发送给相关人员。

2.5配置审核

配置审核是一种软件验证方法,其目的是检查软件产品和过程是否符合标准和规程,是变更控制的补充。配置审核包括功能配置审核、物理配置审核和管理配置审核。

功能配置审核一般由项目经理审核配置项的实际功能特征是否达到功能基线文档中所规定的要求。物理配置审核是通过对配置项的检测,鉴定文、图、物的一致性,保证软件更改的完整性。配置管理组定期(每季度)进行配置管理审核。配置管理审核主要是对配置管理过程进行审核,确认配置管理记录和配置项是否完整、一致和准确。审核过程中,相关人员按照审核内容形成《配置审核检查单》,对不符合项进行记录和处理。

KCFlow具有灵活的配置审核功能,能够策划适合本单位的软件配置管理审核准则。每次入库时,相关人员进行物理审核,在基线建立及变更时进行功能审核。

图3配置审核策划

3结语

软件配置管理贯穿整个软件生命周期,在软件开发过程中采用有效的工具进行配置管理,能够弥补人工管理出现的纰漏,规范开发流程,保证软件产品质量,减少软件缺陷,缩短软件开发周期,降低软件维护成本。本文结合配置管理工具,对软件配置管理流程及实施方法进行了研究。为提高软件开发的效率与质量,今后的工作中应结合项目实际情况及本单位的配置管理相关规定,对配置管理工具的适应性进行研究,以满足各种软件开发要求。

参考文献:

[1]石柱.软件工程标准手册[m].北京:中国标准出版社,2007.

[2]何新贵,石柱,王纬,等.GJB5000军用软件能力成熟度模型实施指南[m].北京:国防工业出版社,2004.

[3]王忠贵,刘姝.航天型号软件工程方法与技术[m].北京:中国宇航出版社,2015.

[4]董越.未雨绸缪理解软件配置管理[m].北京:电子工业出版社,2012.

工程变更管理流程篇8

关键词:电力建设;工程变更;影响;问题;管理控制

中图分类号:F407文献标识码:a

引言

全面分析了工程变更对电力建设项目的影响以及我国现阶段电力建设项目工程变更管理的现状,提出了时电力工程变更管理的若干思考,即实施工程变更的分类控制,运用现代信息化技术改造传统的电力建设项目工程变更管理方法和流程,合理确定工程变更价款以及促进工程变更管理信息化。

一、工程变更对电力建设项目的影响分析

1、对工程投资的影响

现如今,国家财政是我国电力系统一些基础设施项目建设的主要支持。正是在这种现状下,许多的不合规定的问题频繁出现,主要就是一些电力建设项目的负责人在前期的项目策划中,具体的包括工程设计以及可行性等方面,故意少说项目建设的规模以及一些项目建设,这样当开始进行项目的建设时,这些负责人又不断改变项目建设方案,增加一些项目,增加项目建设的整体规模,提升项目建设的标准,从而导致整个项目的资金急剧增加,超过当时工程建设项目在设计初的资金预算,最终使得整体工程项目的资金漏洞变得不可控制。

2、对建设工期的影响

鉴于电力工程建设的独特性,我们知道个体项目与整体项目,还有不同独立项目间的关系都是非常密切的,其内部的工程设计是一环连一环的。假如经常性的对于一个正在进行的电力建设工程进行变更,会导致许多邻接工艺,前续工艺以及后续工艺被迫重新进行甚至是被迫停止运作,这种影响在一些重要电力线路的施工建设中显得格外的严重,具体表现就是使得整个电力项目的建设周期被大大的增加,远远超过初期的设计期限,从而导致一些列的严重后果。同时,对于一些不那么重要的电力线路的建设进行变更,加入变更后的周期远远大于此电力工程初期设计的总期限的,同样也会严重影响工程的进度。

3、对项目管理的影响

当电力工程建设项目设计经常被变更,会给项目的管理人员以及业主带来许多的麻烦,主要就是他们之间必须的频繁的进行沟通协调,而且也加大了电力项目承包方在建设过程进行监管的难度。比如,当电力建设项目发生变更后,为了使工程能够顺利的进行建设,电力项目的管理人员必须经常的组织业主们开会讨论,双方进行沟通,同时还要经常地召集电力项目的承包公司的人员、电力项目建设的设计人员以及电力项目前期进行勘探的人员来进行商讨。特别是,对于一些变动巨大并且十分关键的地方,还必须再次进行电力项目建设的调研以及勘测。总而言之,经常地进行电力项目建设的变更必然会给电力工程的监管带来恶劣的影响,具体表现在以下方面:增加业主的成本,减慢电力工程的建设进度,消耗许多额外的人力资源等。

二、目前电力建设项目工程变更管理中存在的问题

1、信息化程度较低

受技术限制的影响,我国在处理电力建设项目的工程变更时,一般都还是采用人工作业的方式进行管理,并没有充分利用当前先进的信息技术。很多文件都是以纸质档案进行记录和传阅,这在很大程度上降低了处理效率,也容易造成信息的丢失。目前我国还没有建立起一个健全完善的电力建设项目工程变更管理软件,严重影响了管理效率。

2、缺乏对工程变更全过程的管控

一般来讲,工程变更的控制和管理是需要贯穿在整个工程项目实施全过程中的,但是目前人们普遍将工程变更的重点放在了施工阶段,这显然不是最佳的管控手段。因为施工前期的勘查和设计阶段才是控制工程变更的重要阶段,施工过程和施工竣工阶段都需要根据施工设计来安排作业施工和管理控制。

3、合同变更条款设定不够完善

对于工程变更的管理与控制来讲,最有效的控制方法就是在合同中对变更条款做出详细的约定,并将责任划分清楚,这样当出现工程变更时,就可以按照合同约定的要求进行处理,而不至于发生索赔或纠纷。但事实上,很多电力建设项目的甲乙双方在订立合同时,并没有对合同变更条款给予应有的重视。因而造成了很多合同纠纷。

三、对加强电力建设项目工程变更管理的若干思考

1、实施工程变更的分类控制

1.1重大变更

重大变更涉及的范围较广,通常要求必须保持在一定的额定限制之上,其中包含项目的设计方案,在具体施工过程中的方案、项目各项技术规范、项目整体的建设规模以及标准,总而言之内容较广。以火电厂为例来说,变更相关工艺的生产流程、变更获取资源的形式、变更高压供电系统的具体路径等都属于重大变更。变更的实施在最开始需要由监理工程师进行初步的审核,随后由总的监工进行复查审核。完成上诉步骤后,将变更报给业主,业主街道报送的变更后再进行相应的审核设计工作。

1.2重要变更

重要变更相比较重大变更在变更幅度上响度较小,一般在一定的额定限制范围内。例如变电场调整改动生产厂房局部地方的标高或者搞懂生产工序执行过程中实施方案。这种变更初步通常是由监理工程师进行审核,然后报送总工程师批准通过后再付诸实施。

1.3一般变更

一般变更相对于前两者指的是在额定限制范围以下的变更,主要包括在设计过程中出现的错误、设计过程中缺少的不完整的部分、材料的更换和替代以及具体施工过程中发生的突发性修改,这种修改往往需要马上作出决定。一般变更的审核就没有那么严格,一般监理工程师审核同意后就可以执行。

2、合理确定工程变更价款

国内现行建设工程施工合同条件和相关研究文献均有关于工程变更价款的确定方法和原则主要有:合同中已有适用于变更工程的价格,按合同已有价格变更合同价款;合同中只有类似于变更工程的价格,可以参照类似价格变更合同价款;合同没有适用于或类似于变更工程的价格,由承包商提出适当的变更价格,经监理工程师确认后执行;承包商在双方确定变更后14天内不向监理工程师提出变更工程价款报告时,视为该项变更不涉及合同价款的变更;监理工程师应在收到变更工程价款报告之日起14天内予以确认,监理工程师无正当理由不确认时,自变更工程价款报告送达之日起14天后视为变更工程价款报告已被确认;监理工程师不同意承包商提出的变更价款,按合同争议的约定处理;因承包商自身原因导致的工程变更,承包商无权要求追加合同价款。

3、实现工程变更管理信息化

我国电力建设项目变更管理信息化尚处于起步阶段,而制造业对工程变更管理的信息化研究起步较早。制造业工程变更管理应用系统一般基于产品数据管理系统(pDm)和支持团队工作的工作流技术平台开发,实现eCm功能与pDm的集成,以充分利用pDm的产品信息管理模块和流程管理模块。制造业有关工程变更管理的概念、模型和方法为电力建设项目工程变更管理信息化搭建了高起点的研究平台,有助于加速我国电力建设项目工程变更管理的信息化进程,缩短相关应用系统开发周期。

根据实际的工程变更需求,可以将eC过程分解为请求、评估、和实施3个环节。其中:eC请求包括描述问题的症状,发出正式的变更请求和提出解决建议方案3个步骤,eC评估包括技术评估、造价评估、工期评估和价值分析4个步骤,eC实施包括矛式的工程变更指令和实施工程信息更改。实现工程变更管理信息化,必须构建以人员组织、变更流程和数据管理3大要素为核心的工程变更管理信息系统。建立以数据管理为基础,以变更流程为主线的工程变更管理策略是实施有效工程变更管理的关键所在。

4、重视施工环节的变更管理

项目管理作为劳动生产率与经济利益提高的有效方法,强化成本管理,可有效控制工程造价,对工程项目的施工阶段实施全面变更管理,需要注意下列问题:

一是做好工程基本资料的收集工作,及时发现问题,对工程图纸不明确问题要及时提出询问,对于一些材料及设备参数要提出相应变更要求,当施工现场实际情况与施工管线图纸不相符的时候,尤其是管线之间相互交叉碰撞,承包商应该对施工图纸提出修改,以确保工程施工的质量,并防止形成事实后再实施变更,尽量将变更带来造价损失降为最低;

二是做好工程项目变更与签证工作,对于施工过程所提出的设计错误纠正,以及为满足现场施工条件而作出的设计修改等,应该出具变更通知单与变更洽商单,以规范变更管理,签证主要是指设计变更及施工图纸以外的内容,因施工现场各种问题,出现了和施工合同不相符的条件与事实,要由监理、业主及承包商等负责人进行共同签署,证实在施工阶段出现了一些特殊状况,如施工条件变化引发的工程量变化、工程变更引起的返工,工程应及时做好工程量的签证手续;

三是做好合同管理工作,加强施工合同的分析,在施工合同中有关变更、工程价款与索赔等有关条款,应该尽量做到详实,工程结算、办理程序与审核价之间的差距幅度应该明确界定,对于监理合同,应该明确业主及监理的责权利,由于监理方面原因带来的造价不合理增加,应该由监理方进行赔偿。

结束语

总之,在电力建设的项目管理工作中,必须要对工程变更管理与控制给予一定的重视。从电力建设立项开始就应该加强工程变更预防控制,并在合同中对变更条款作出详细的约定,划分工程变更所引起的经济责任。同时,面对当前我国电力建设项目工程变更管理信息化水平较低这一现状,还要进一步加强工程变更管理的信息化建设,提高工程变更管理和控制水平。

参考文献

工程变更管理流程篇9

针对目前国内电力企业工程造价管理信息化建设处于起步阶段,信息化管理存在条块分割、信息壁垒等诸多问题,提出了基于内蒙古电力(集团)有限责任公司现有的eRp系统、ppm系统和基建项目辅助管理系统构建一体化工程造价管理平台设计方案,通过系统功能和应用范围的扩展及深化,实现内外网的流程贯通和数据共享。一体化工程造价管理平台建成后,能够实现项目全过程的造价业务流和信息流管理,将造价管理的管控节点前移至项目的施工阶段,使项目建设阶段的造价数据真实、可控。

关键词:

电力企业;一体化工程造价管理平台;基建项目辅助管理系统;工程造价管理;过程结算

0引言

近年来,随着电力体制改革的不断深入和内蒙古地区经济的快速增长,内蒙古电网建设与改造取得了显著成效。但随着电网建设工程数量的增加、建设及投资规模的加大,工程造价管控程度及水平对电网发展的影响越来越显著,如何做好电网工程建设项目的造价管控、合理利用有限的建设资金是电网工程建设与管理的重要工作[1-2]。

1电力企业工程造价管理信息化现状

近年来,我国工程造价管理信息化建设与应用取得了长足进展,但与西方发达国家相比仍有较大差距[3]。国内电力企业的工程造价管理信息系统的功能比较单一,通用的行业管理软件基本定位在概预算编制和清单编制管理阶段,缺乏全过程和全方位的工程造价管控,过程中的造价控制管理相对薄弱,缺少信息化手段的支撑。以内蒙古电力(集团)有限责任公司(以下简称内蒙古电力公司)为例,目前公司基建工程造价管理软件使用的是博微单机版软件,用于工程造价的概算编制和清单编制,使用eRp系统完成项目执行过程中设备材料、建筑安装、其他费用3大类费用的最终结算,2大信息系统数据无法实现有效共享。eRp系统中的建筑安装类费用结算主要是以合同付款为节点的结果性结算录入和记录,并不能体现基建工作中各类费用发生的明细以及费用在执行过程中的各类变更情况,结算数据的管理相对粗放,缺少过程管控和监督,难以对工程的过程造价实现有效监管和合理规划。

2一体化工程造价管理平台设计分析

为加强内蒙古电力公司基建工程全过程的造价管控力度,提升公司总体造价管理水平,公司工程建设部在基建工程全过程的造价管控方面提出了具体实施要求,在开展基建工程施工全过程造价管控时,关注工程过程阶段的总造价和过程阶段的造价组成部分,便于合理控制过程阶段造价,进而提升公司基建工程造价管理水平。为此,急需利用信息化手段将参与全过程造价的单位及数据纳入信息系统,提升造价管理数据的规范性、合理性,提升公司基建工程全过程造价管控的精细化水平。

2.1设计目的

内蒙古电力公司一体化工程造价管理平台的构建,其主要目的是实现项目全过程的造价业务流和信息流管理,将造价管理的管控节点前移至项目的设计和施工阶段,实现概算、清单、过程结算、竣工结算全口径、全流程的在线业务处理[4],提升工程技经数据互联互通、高度融合与共享的信息化支撑能力,做好工程实施过程中工程量的管理,实现施工阶段“工完量清”的管理目标,提高工程结算效率,提升造价管理分析能力。

2.2设计思路

为避免同一工作多系统交叉重叠、用户操作不畅的问题,一体化工程造价管理平台的应用架构设计基于内蒙古电力公司现有的eRp系统(构建在内网环境)、ppm系统(构建在外网环境)和基建项目辅助管理系统来扩展。通过深化基建项目辅助管理系统的造价管理功能和应用范围,构建业务环节覆盖从初步设计到竣工阶段全过程,实施单位覆盖包含公司本部和各盟(市)供电局的两级工程建设管理部门,以及设计、监理和施工等外部参建单位,实现基建项目造价管理业务的上下联动及内外协同。通过系统功能和应用范围的扩充及深化,并结合网络技术实现内外网之间的流程贯通和数据共享,实现一体化工程造价管理平台的构建。具体建设内容主要包括以下4个方面:(1)完善造价基础数据库(定额库、清单库、设备材料库)的建设,实现工程技经数据在各系统之间的顺畅流转;(2)规范公司过程结算编制标准及业务流程,实现工程量在线编制及组价形成过程结算报价,并实现工程量及组价的在线审核;(3)利用信息系统实现工程结算与财务资金支付流程的整合与集成,遵循工程进度款拨付额度不得超过过程结算累计计量计价额度,确保施工阶段资金支付规范并及时到位;(4)利用信息系统快速准确地出具竣工结算报表的特点,丰富造价实时管控手段,提升过程造价管控水平。

3系统功能设计

3.1造价基础数据库建设

造价基础数据库建设包括定额库、清单库、物料库、供应商库、合同库、项目库的建设和管理。造价基础库需在eRp系统和ppm系统中同时搭建,实现与各个数据系统的无缝链接。

3.2输变电工程及审核流程管理

设计招标结束后,通过eRp系统下达项目信息,系统自动识别项目的设计单位,并将工程任务推送至设计单位;设计单位可在当前工程列表中查看到具体的工程,并在ppm系统中直接进行工程概预算的编制,编制任务完成后提交概预算书至eRp系统,由建设单位进行概算造价的审核;提交审核后,系统会将工程状态更新为“审核”;审核通过后,工程状态设置为“审定”,并且归档。

3.3物料清册生成

造价工程中的设备材料库通过与物料系统编码绑定,在工程审定后,可在造价工程的“物料清册”页面直接查看当前工程的设备材料汇总,并支持推送至eRp系统形成设备清册,同时支持导出excel文件。

3.4概预算编制

实现对电力工程概预算的编制、费用调整、报表生成,同时兼容标准excel格式造价文件上报并转换为具有完整造价数据的造价工程文件。概预算编制功能使用标准的电力预规目录,每个目录都使用标准的wBS编码标准进行编码,概预算编制完成后,系统支持多个工程多阶段的费用自动抽取及对比。该功能需同时在eRp系统和ppm系统中搭建,并实现数据的交互和共享。

3.5清单编制

清单编制包含了清单招标控制价、招标工程量清单编制、中标清单的导入,支持完整的工程量清单编制及报表结果输出,支持工程清单的合同绑定。项目进入招投标阶段,eRp系统中的项目信息下达后,系统自动根据项目信息创建工程清单并识别清单编制单位,清单编制单位可在ppm系统中直接打开工程清单,进行清单招标控制价的编制;编制完成后,编制单位需提交清单审核,系统会将审核任务推送至eRp系统中的建设单位并最终完成审核流程;审核通过后,系统生成适用于招标要求的工程量清单文件。

3.6过程结算管理

过程结算管理用于电力工程从中标到结算过程的监管及控制,提供了清单完成工程量监控及计价功能、清单综合单价组成分析功能与施工单位工程量申报及审核流程管理功能。施工单位在ppm系统中申报完成工程量时,需打开工程清单,输入实际完成的清单工程量,提交工程量审核申请;系统进入审核流程,工程的监理单位、咨询单位、建设单位根据各自的职责流程在ppm系统或eRp系统中审核施工单位提交的工程量;工程量审核通过后,汇总至已完成工程量,系统实现清单工程量的计价,建设单位可实时监控项目投资情况。工程量审核时,各审核单位均以只读方式打开清单工程,展开清单明细,在系统中查看清单详细的组价方式,使用的人材机消耗量详细信息、取费方式、设备材料价格等完整的工程量信息。

3.7变更及签证管理

变更及签证管理功能包含设计变更、非设计变更与签证的管理。工程变更与签证的发起单位根据变更和签证的类型确定,变更及签证发起后则进入审核主流程,各审核单位根据流程的角色完成变更、签证的审核工作。

4设计功能的实现及建议开发方向

4.1基础数据标准化

该设计方案实施的关键和难点是基础数据的标准化工作和系统集成设计,现阶段已实现了以eRp系统中的wBS编码和物料编码为基础关联概算、清单和结算数据的功能,基础数据编码贯穿初设、工程招标、工程实施和竣工结算所有阶段,满足了工程造价各阶段数据的可追溯、可对比和可分析的管理需求。

4.2一体化平台建设建议

(1)工程造价管理信息化建设离不开信息技术水平的提高,必须结合大数据资源的挖掘与利用,研发完善、科学的数据指标体系,利用现代化的手段将传统经验值数据变得更为庞大、更加系统、更具价值。因此可以考虑借助专业软件公司的力量,吸取成功企业管理系统的经验,形成软件系统,对造价信息进行深加工,不断扩大造价信息成果数据库规模,提高造价管理的技术含量。

(2)工程造价管理信息化建设涉及项目的概算和结算数据、施工技术、施工质量、设备材料供应等多方面,因此,如何健全工程造价管理信息化工作机制也是需要深入思考的问题。在充分调研的前提下,相关部门应制订符合工程管理信息化发展的总体规划;并从健全工作机制入手,完善工程管理信息化的实施方案,出台工程造价信息管理制度,明确相关利益主体的职责;建立信息化咨询方机制,降低工程造价管理信息化的风险,推进信息资源的共同开发利用[5]。

5结语

通过对电力企业工程造价管理信息化的现状进行分析,探讨了内蒙古电力公司一体化工程造价管理平台建设的必要性、设计思路,并展望了工程造价管理信息化的未来。一体化工程造价管理平台建成后,能够实现项目全过程的造价业务流和信息流管理,将造价管理的管控节点前移至项目的施工阶段,使项目建设阶段的造价数据真实、可控,为提升造价管理分析能力奠定基础。

作者:常虹单位:内蒙古电力(集团)有限责任公司

参考文献:

[1]马楠.工程造价管理[m].北京:机械工业出版社,2009:27-31.

[2]聂金明.论述工程造价管理目的和意义及改革建议[J].大科技,2012(3):434-435.

[3]刘志勇.关于我国工程造价管理信息化完善与应用的分析[J].科技风,2010(5):15.

工程变更管理流程篇10

新近被追崇的业务流程管理(Bpm),不但能使公司摆脱功能堆积,激发出企业的活力,还能帮助企业在一个竞争残酷和变化快速且经常不可预测的时代里,更容易获得成功

现在,纷繁复杂的业务正让贝尔等国际巨头头疼不已,呼唤一个新的管理流程来解决这些错综复杂的问题,成为当务之急。

Bpm(Businessprocessmanagement),即业务流程管理,是一套达成企业各种业务环节整合的全面管理模式。Bpm涵盖了人员、设备、桌面应用系统、企业级Backoffice应用等内容的优化组合,从而实现跨应用、跨部门、跨合作伙伴与客户的企业运作。Bpm通常以internet方式实现信息传递、数据同步、业务监控和企业业务流程的持续升级优化,不但涵盖了传统“工作流”的流程传递、流程监控的范畴,而且突破了传统“工作流”技术的瓶颈。

日前,贝尔加拿大公司开始进行几项意义深远的革新,以改变其向客户提供新的基于网络协议的服务方式。这家加拿大最大的运营商决定制定端对端的业务流程,从而将在订购及提供服务中所使用的各种分散的应用连接在一起。这个整体性的方式将可以为客户提供新服务时间从几周降为几天。

同贝尔加拿大一样,更多的公司正在将他们的注意力转移到流程上,竞相实现更出色更快捷的工作,争相采用业务流程管理(Bpm)技术使他们可以独立于具体部门和功能来监控流程。

利用Bpm方法,公司需要从战略和整个企业的角度来探索Bpm理念。那些将其运用得当的公司,有可能对运营实现前所未有的控制,并在运用流程方面真正地先人一步,使之成为竞争亮点。正如贝尔加拿大公司amirShah所注意到的,“Bpm是未来的潮流”。

流程管理的挑战

从计时器到六西格玛、tQm和业务流程再造工程,管理者们一直努力工作,以实现对其运营方式进行更好地控制。而Bpm正是在这种历史之上建立起来的,并致力于改善全面的、端对端的运作,如从订单到递送,包含了一系列跨职能边界的活动,范围常常从供应商到客户。其目标是消除转手及内部职能间的分离,并专注于整体业务的最终结果――典型的服务到户。

这种理念极具吸引力,但是事实证明很难付诸实施。虽然许多业务已经能够跨职能实现自动操作和整合,但端对端流程的每日管理能力滞后。的确,流程管理还停留在大量的手工阶段。毕博企业业务流程管理团队董事JackLangowski说,为了得到显示客户服务业绩的全面数字,管理人员通常要提出申请,由技术专家们展开广泛的数据挖掘活动,然后由一名人力专家对结果进行分析。他说:“可能在几周内你会得到想要的数字,但它们不仅晚了,并且还经过了下层人员的过滤。”

改变这些流程甚至更麻烦。管理业务流程的规定通常被写入诸如财务或客户关系管理等相关应用中。Bpm专家peterFingar说:“当商业世界改变时,如果你想改变你的业务流程,你就要钻研这些细节。”这意味着与it小组反复商讨,这样的情况通常更容易淹没。

Langowski说,整体而言,大公司中重要的流程转变可能会极为缓慢。他说:“光研究一个流程并收集相关数据就可能会花上9个月,然后还要再花6个月来达到他们想要的效果。这些时间框架对业务管理者完全没有吸引力。”因此,沮丧的高级经理人会倾向于授权流程管理活动,并将他们寻求战略改善的注意力转移到其他地方。

Gartner公司应用开发及体系结构副总裁、Bpm权威人士JanelleHill说:“理念很简单,如果流程管理得当,就能提高业务绩效。”的确,管理人员希望做的不仅是简单地提高其流程效率。Hill说:“许多公司都在考虑如何变得更灵活更具适应性,以便更轻松地改变和响应外部压力。或者更理想的情况是,如何改变其业务模式,从而使他们能够预见变革并从中获利。”

挑战来得正是时候。

企业的新希望

难道就没有一个方法来解决流程管理中遇到的问题?现在有一种称为业务流程管理系统(BpmS)的新兴技术,使一些公司重新认识业务流程管理。毕博高级副总裁markLee说:“Bpm系统正在迅速成为一种主流技术。”

据了解,目前的业务流程管理系统技术结合了用于系统连接的企业应用整合能力;工作流程管理技术被用于处理人力互动;尖端的业务规则方法及网络服务,使分散的系统和流程得以通过网络共同运作。总体来说,他们从基本的it应用中将关于流程的信息进行分离,使独立管理一个特定的流程成为可能。该方法与20世纪80年代相关数据库类似,它们将数据与应用系统分开,开发了一代依靠共享核心数据的企业系统。

Fingar说:“这种理念是在你现有的系统之上建立一个流程层。你可以在此创建并改良业务流程。”这种方法使公司在其流程管理中有了更多的自由和更高的精密度。Fingar认为,凭借当今众多的BpmS技术,“你可以对一个流程的整体生命周期进行管理,从发现流程,分析公司当前运作状况,到新流程的设计或修改,再到实施或执行该流程,从流程中获得反馈从而实现流程优化。”

BpmS技术远不同于用于设计和管理业务流程的神秘的图表和系统。其中许多都提供面板,使管理人员准确地、近乎实时地了解流程绩效,并在出现问题时自动发出警报。剑桥麻省Forrester研究机构首席分析师KenVollmer说:“现在你可以让一个业务部门的执行副总裁坐在那里,通过面板了解那个部门中每一刻所发生的任何事情,这很了不起。”

不仅如此,管理人员还可以更详细地找出问题的源头。许多BpmS技术还能帮助管理人员模拟各种修改并看到可能的结果,以提出问题的解决方案。例如,他们可以显示分配人员或产品线会如何影响部件的制造时间。合作型工具使经理团队及管理人员共同合作,探索各种前景并快速就最佳方法达成一致。但可能最重要的是,管理人员可以通过该系统实现有效变革,自动将新流程的定义扩展到支持流程的系统。

最终,这些新系统使管理人员可以不必担心处理公司基础系统的复杂性,不断地进行事前流程管理。简而言之,他们可以基于业务战略而不是技术限制来进行决策。

让企业重新焕发竞争活力

由于可以更好地管理端对端流程,公司便能更迅速地对变革做出回应。Vollmer说:“Bpm使组织更灵活地跨边界活动,因为每个人都很了解目前状况。”有了这样的了解,经理人可以消除瓶颈,并轻松地调整流程。

毕博董事总经理peterHorowitz说,公司还可以根据整体业务目标使用Bpm来实现巨大的流程改善。毕博曾经帮助一家主要经纪商通过使用Bpm工具和技术来监督并调整其新客户流程。结果,Horowitz注意到,虽然工作量不断增加,但公司从事处理新客户的人数却从100名降为22名。它还将错误率从50%降到10%,并将平均8天的新客户开户时间缩短为1天。从更广泛的范围来看,对使用Bpm的财务服务行业进行的研究显示,“公司报告说他们还节约了运作成本,达到30%至50%不等。”

贝尔加拿大公司的Shah指出,Bpm使流程改善得以在更持续的平台上实现。公司可以在问题产生的时候就解决它们,因为流程变革不再与季度或半年度it更新及修改计划相挂钩。他说:“我们可以相当快速地改变业务流程,并连续实现流程改善。我们可以在不依靠较长系统革新周期的基础上在Bpm层次进行流程定义。”

从另一个层次上说,流程增加的活力能够使公司更灵活地与伙伴公司的组织系统进行合作。如果公司与信用服务供应商之间出现质量问题,且供应商的流程与其自身流程联系紧密,则它可以在不担心重新安排一系列关系的情况下轻松地替换该供应商,寻求更有能力的合作伙伴。

peterFingar指出,互联网所带来的连接性和Bpm提供的灵活性相结合,的确可以创造盈利机会。他举了维珍集团的例子,该集团与Sprint组建的合资企业进入美国移动电话市场。维珍集团没有建立自己的基础设施,而是通过Sprint的网络提供电话服务,而维珍则负责客户服务及用户管理。“现在,这一家于2002年新成立的维珍美国移动,已拥有了3百万用户。

在演变过程中,BpmS工具突破了许多原本使管理人员与流程管理相分离的障碍。但是想要全面利用Bpm,公司则不应该局限于使用这些工具,利用并处理那些可能会帮助或破坏Bpm计划的组织、技术及“人员”因素。

Vollmer说:“其中的人员方面比工具重要得多。”作为一种管理方法,Bpm转移了职能型经理的权力,并要求可能进行内部争斗的部门相互协作并共享信息。这种文化上的挑战非常关键,以至于Vollmer常对人说“他们的项目小组中应该配备一名心理学家,因为触动了许多方面的权利。”