2015年以前，部分工程总承包试点项目取得了显著成效，但主要集中在冶金、化工等工艺性很强的行业，在房屋建筑和市政基础设施领域工程总承包模式推行得并不理想。2016年住建部《住房和城乡建设部关于进一步推进工程总承包发展的若干意见》（建市〔2016〕93号）[1]、2017年国务院办公厅《国务院办公厅关于促进建筑业持续健康发展的意见》（国办发〔2017〕19号）[2]等文件出台以来，房屋建筑和市政基础设施项目工程总承包在全国各地广泛推行，但却走出了长期以来发展缓慢的状态。经过多年市场培育，以2019年住房城乡建设部及国家发展和改革委员会共同颁发的《房屋建筑和市政基础设施项目工程总承包管理办法》[3]出台为标志，工程总承包踏上了发展的快车道。在此办法中，工程总承包定义为“承包单位按照与建设单位签订的合同，对工程设计、采购、施工或者设计、施工等阶段实行总承包，并对工程的质量、安全、工期和造价等全面负责的工程建设组织实施方式”，这意味着在房屋建筑和市政基础设施领域，现阶段推行的工程总承包将以设计、采购、施工（EPC）和设计、施工（DB）模式为主，而现实中EPC模式也是国内最常用的工程总承包模式。 在此市场环境下，设计院和施工单位联合中标的EPC项目越来越多，这类项目的概算编制业务也随之增多。因项目建设组织模式不同，EPC项目的概算编制与传统建设模式项目有着必然的差异，其中尤其需要注意施工单位牵头EPC项目的概算编制。目前，很多概算编制人员（联合体配合单位设计方）仍按传统方式编制这类项目概算，导致施工图预算或EPC合同结算价超概算价的矛盾比较突出，而国家却未针对这类EPC项目概算编制发布相应的指导文件。因此，对EPC项目尤其是施工单位牵头的EPC项目概算编制进行研究，归纳容易出现的问题，和传统模式对比分析产生问题的原因，最终提出解决思路，为EPC项目提供参考具有极其必要的现实意义。 1 EPC项目的分类及研究范围 1.1 以项目阶段为主线，按EPC项目发承包阶段不同划分 根据《住房城乡建设部关于进一步推进工程总承包发展的若干意见》（建市〔2016〕93号）[1]及《房屋建筑和市政基础设施项目工程总承包管理办法》[3]规定，工程总承包项目的发包阶段，可以在“可行性研究、方案设计或者初步设计完成后”进行，以及“采用工程总承包方式的政府投资项目，原则上应当在初步设计审批完成后进行”。虽然政府投资项目原则上要求在初步设计审批后进行工程总承包发包，但对非政府投资项目的总承包发包阶段并未规定和强行要求。在实践中，非政府投资项目依然存在相当数量的初步设计前进行EPC发包的项目。根据项目的阶段不同进行EPC发包的情况可分为以下三类： （1）在项目完成可研立项后进行EPC发承包，承接阶段包含工程项目的方案设计、初步设计、施工图设计、勘察、采购及施工等工作； （2）在项目方案设计完成后进行EPC发承包，承接阶段包含工程项目的初步设计、施工图设计、勘察、采购及施工等工作； （3）在项目初步设计审批后进行EPC发承包，承接阶段包含工程项目的施工图设计、采购及施工等工作。 其中，在初步设计审批后进行EPC发承包的项目，初步设计概算已由业主委托的初步设计单位完成，不属于EPC承包单位的工作，故不在本次分析范围。 在项目完成立项后或者项目方案设计完成后进行EPC发承包的项目，初步设计属于承包单位的工作范围，初步设计概算作为初步设计的组成部分，需要由承包单位完成，因此此两种阶段发包的EPC项目是本次分析的主要对象。 1.2 以实施者为主线，按承担EPC牵头作用的主体不同划分 目前我国民用建筑工程总承包主要采用“设计+施工”联合体形式招标。联合体双方基于不同的分工及承担角色的不同，存在“设计牵头”和“施工牵头”两种EPC项目实施方式。 （1）由“设计牵头”的EPC项目，设计概算属于初步设计的组成部分。设计单位除了清楚设计概算的作用和对如何编制有着多年的经验之外，编制过程中能直接获取EPC承包范围和承包价等相关信息，能代表EPC方与甲方、财政评审机构等政府职能部门直接对话和决策，和传统建设方式项目编制概算的操作模式差异不大。 （2）由“施工牵头”的EPC项目，施工单位就项目的造价应全面对建设单位负责。但施工单位对设计概算的作用不清楚，对概算编制依据、方法和内容不了解、不熟悉，通常还是由EPC配合方的设计单位编制概算。但设计单位只是配合单位，且概算由设计单位委托其专门编制概算的部门来完成，概算编制人需要了解的信息需通过设计人再传达到施工单位。因为施工单位对概算重要性的不了解造成对概算的不重视，或者多重传达造成信息的不对称，往往导致沟通结果并不理想，造成最终核定概算和工程实际需求有脱节，给后期造价管控带来隐患。因此对“施工牵头”的EPC项目设计概算编制进行研究分析迫在眉睫。 2 施工单位牵头EPC项目概算编制过程中的常见问题 2.1 施工单位不重视概算编制工作，未起到牵头作用 施工单位没有从本质上理解“施工单位牵头”EPC模式的要求，特别是对于项目的造价管控要求还停留在传统模式上，对概算不重视，在设计概算编制过程中并未起到牵头作用。施工单位以为概算编制还是设计单位的事情，和自身利益无关或觉得不重要，不仅对概算编制不要求、不参与、不主导，甚至还按传统的盈利模式在施工过程中尽量把预算做大以致于超出概算，以此一方面向甲方申请增加投资，另一方面以设计超过限额、概算投资未打足等理由和设计单位扯皮，造成EPC联合体双方内部互不信任、内耗严重，不仅对人力、物力等资源是极大的浪费，还失去了项目采用EPC模式的优势。 2.2 设计单位忽略了施工单位牵头EPC项目对概算编制的特殊要求 由施工单位牵头EPC项目的概算一般由联合体的设计单位下属概算编制部门完成，设计人员以及概算编制人员思维还未转变，未思考概算编制有什么特殊要求：与EPC承包合同是否有关；为配合牵头方的造价管控要求，概算编制精度要求有何不同，需估算费用的部分如何计算；设计人员的设计方案需注意的问题等。 2.3 设计单位与施工单位沟通不到位造成编制的设计概算与EPC合同要求脱节 由于施工单位的“牵头”缺位以及设计单位的不主动，EPC模式下双方的沟通不足，造成概算编制考虑的因素不全面、不充分，给造价管控带来极大的风险。具体体现在： （1）未将EPC合同作为概算编制的参考依据，不能厘清概算编制的范围与EPC合同的范围是否一致，概算是否能为EPC合同所用；未参考EPC合同中的单价约定编制概算，不能保持造价管控标准的一致性； （2）设计单位与施工单位牵头方没有深入沟通了解影响概算费用的项目情况，如现场实际情况、贴合项目实际的施工措施方案等，形成“你编你的，我做我的”的现状，编制的概算与实际出入较大； （3）在设计方案的调整深入过程中，双方未就设计方案进行充分沟通和交流，设计人员容易看重方案的技术性而忽视经济性；双方未在设计方案与材料采购、货源组织、实施进度等之间主动寻求平衡点，没有在实现双方的共同利益方面形成合力，造成概算与实际偏离；忽视施工图与初设图前后一致的重要性而变更随意，让初设概算控制造价成为一句空话。 3 施工单位牵头EPC项目概算编制问题的原因分析及解决思路 3.1 投资控制责任主体发生变化，作为EPC牵头方的施工单位应转变观念 在传统模式的施工承包项目中，施工单位对于承包的项目结算产值总是希望越高越好，只为产值和利润，而对于该项目是否控制在批准的概算范围内，则不是施工单位关心的主要问题，特别是在目标利润没满足的情况下更是不会考虑建设单位的投资控制需求，投资控制的责任方主要在建设单位。而在EPC模式下，《房屋建筑和市政基础设施项目工程总承包管理办法》[3]中提到工程总承包“是指承包单位按照与建设单位签订的合同……并对工程的质量、安全、工期和造价等全面负责的工程建设组织实施方式”,明确了承包单位对造价全面负责，且在实际工作中，建设单位把这个要求也明确在EPC承包合同中，施工单位牵头的EPC项目应由施工单位牵头贯彻实施。由于施工单位所管理的工程范围由传统的施工扩大到设计、采购等环节，施工单位的投资管控难度和管理幅度也增加。由此可见，基于施工单位牵头的EPC模式下的建设项目，建设单位把很大一部分的风险转嫁给了施工单位，包括大部分管理风险、外界风险、工期风险和投资控制风险等，造价控制的责任主体已经从建设单位转变成施工单位。 对于本文分析的EPC类型的总承包项目，包含初步设计并且有总价控制要求，作为既不能突破合同投资上限也要能包住EPC结算价的概算编制就显得相当重要，概算编制不再像传统模式项目只是设计单位的事情，而是事关项目投资控制成败的关键。作为牵头方的施工单位应及时转变观念，重视并主导概算编制，即使施工单位对概算编制缺乏经验，事前双方也应在联合体合作协议中明确责任主体，由谁主导概算编制及对后续预算结算的连贯性把控。 3.2 概算编制依据的重大变化 概算编制除了依据图纸计算之外，也要考虑图纸中没有包含的影响概算费用的其他因素，如项目周边的情况、施工措施等，特别是费用可能比较高的特殊施工措施更不能遗漏。但是因为建设阶段的原因，传统建设模式下的概算编制人只能根据经验或类似工程暂估，暂估费用的准确性很大程度依赖于编制人的经验。在通常情况下，概算主要起控制投资的作用，和实际如何施工并无直接联系。为了打足投资，初设图中不能反映的暂估费用一般尽量按富余估计。即便如此，实际工作中施工图预算或实施后的结算超概算的情况仍时有发生，当然原因是多方面的，但其中分段式建设和分段式投资管控造成概算精度不高、初步设计和实际施工脱节是主要原因。 在包括初设概算工作内容在内的EPC模式下，特别是施工单位牵头的EPC项目，合同中已约定EPC结算方式，给本应作为前期控制造价的概算增加了编制的约束条件，造成概算事实上的后置，和传统模式相比发生了根本性的变化。对需要包住EPC总承包合同价格的概算的要求精度更高，概算编制就需要参考EPC合同，通过合同范围和合同计价方式得到更真实的依据，进而对概算投资限额能更好地把控；影响概算费用的项目有关信息、施工信息通过施工单位牵头能得到更贴合实际的技术支撑。 因此，EPC总承包合同作为概算编制的依据非常有必要，且按概算编制依据中人工费、材料费等计取和调整原则计算的费用不能小于按EPC合同规定的计取原则计算的费用；措施费、规费等计取文件计算的费用也不能小于按EPC合同约定文件计取的费用。以EPC合同计价原则为参考编制概算也能保持前后造价计算原则的连贯性，便于过程中进行费用对比和投资控制。 3.3 设计方与施工方关系的变化，需要双方调整工作方式 在传统建设模式中，项目的设计方和施工方是利益基本互不影响的两家独立的单位，是建设项目五方责任主体的其中两方，分别只对建设单位负责，如果项目投资失控，双方还可能互相推诿责任；在施工单位牵头的EPC模式下，设计方和施工方构成了EPC项目的利益共同体，合二为一共同对建设单位负责，投资控制是以施工单位牵头的双方的共同责任。而设计阶段对于项目的投资控制起到绝大部分的作用，特别是初步设计阶段。因此，在设计阶段控制好投资，是项目最终投资能满足合同要求的基本保障，设计方作为配合方，对投资控制的影响不亚于牵头方。一旦投资失控，不管是设计方还是施工方的原因，对双方都会有影响，谁都不能独善其身。 因此，和传统模式相比，设计方和施工方的关系发生了截然不同的变化，从互相独立的个体变成利益一致的命运共同体。因此，双方需要从设计阶段就加强沟通，从投资控制的源头——概算编制抓起，主动利用限额设计和设计优化等手段，特别是牵头人施工单位，是投资控制的主体单位，要行使牵头人的作用主导概算编制，以批复的上一阶段的估算要求进行限额初步设计，设计方也要有项目主人翁的意识，在设计中主动与施工方交流，充分利用双方的最有利资源，在保证设计方案技术性的同时，加强对经济性、落地性的考虑，采用多方案比选进行设计优化等，最终选择功能成本比最大、价值最优的方案，为实现项目投资控制的目标打下坚实的基础。 结语 虽然在房屋建筑和市政工程领域，工程总承包经过最近几年的发展已经越来越走向成熟，但是距离相对成熟的、能充分体现优势的工程总承包还有相当长的一段路要走。 前述关于现阶段施工单位牵头EPC项目概算编制问题的解决思路，有些暂时还缺乏推行的基础，如关于投资控制责任主体转变的问题，建设单位和施工单位短时间还不能把握好转换的尺度；由施工单位牵头概算编制还缺乏技术支撑；如设计、施工双方调整工作方式的问题，还存在联合体双方因特殊原因是“拉郎配”的项目，设计、施工无法做到深度融合，施工单位作为牵头方不能调动设计阶段的投资控制优势，造成投资失控等。 随着工程总承包的大力发展，通过更多的项目检验，参建各方会越来越找准自己的位置适应工程总承包的发展。对于由施工单位牵头的EPC项目，希望能够实现施工单位主动承担起投资控制责任并起到牵头作用，设计单位（包括设计人员及概算编制人员）主动配合，集各单位所长，编制出贴合项目真实建设情况的设计概算，真正起到投资控制的作用。

一、EPC的“设计优化”与“工程变更”的定义与变更起因在EPC（Engineering, Procurement, and Construction）项目中，设计优化和工程变更是两个重要的概念。 设计优化是指通过对工程设计方案进行改进和调整，在不改变项目基本要求和范围的前提下，提高设计方案的经济性、可靠性、可持续性和可操作性等方面的性能。设计优化的目的是在保持工程质量的前提下，提高工程效益，实现最佳结果。 工程变更是指在项目实施阶段，根据实际情况和需要，对设计方案、工程施工方案、物资采购方案等进行修改和调整的行为。工程变更的目的是满足项目实施过程中的需求变化、风险控制、技术难题解决以及项目范围的调整等。 工程变更的起因可能包括以下几个方面： 需求变化：项目实施过程中，需求可能会出现变化，例如客户对工程功能、性能、质量等方面的要求发生变动。 技术优化：在项目实施过程中，新的技术或方法可能出现并取得突破，需要对设计方案进行调整以提升工程效益。 风险控制：项目实施过程中可能出现新的风险或问题，需要对设计方案进行修正以降低工程风险。 施工条件限制：实际施工条件可能与原设计方案存在差异，需要对施工方案进行调整。 二、如何区分EPC项目中“设计优化”与“工程变更”？ 在EPC项目中，设计优化与工程变更有以下区别： 目的不同：设计优化的目的是提高工程方案的性能和效益，而工程变更的目的是应对需求变化、风险控制等实际情况调整设计方案。 字面意义不同：设计优化是对原有设计进行改进，优化设计方案，而工程变更是对已经确定的设计方案进行修改和调整。 时间点不同：设计优化主要在设计阶段进行，旨在提高设计方案的质量，而工程变更主要在项目实施阶段进行，根据实际情况进行调整。 落实“设计优化”与“设计变更”基本思路以及应对策略有哪些？ 三、落实“设计优化”与“设计变更”的基本思路和应对策略 建立明确的项目管理机制：通过建立完善的项目管理体系，包括项目计划、 沟通机制、变更控制等，确保项目按照计划进行，及时识别和处理变更需求。 强化设计和施工的协同合作：设计和施工部门之间需要密切协作，及时沟通，确保设计方案的可行性和施工方案的实施性。 制定规范的变更管理程序：建立科学的变更管理程序，明确变更发起、评估、审批和实施等环节，确保变更的时效性和可控性。 严格质量控制：加强质量控制，确保任何变更都不会影响项目的质量和安全性。 充分利用信息化技术：通过建立信息化管理系统，实现对设计文档和变更记录的有效管理和跟踪，提高变更管理的效率和准确性。 在EPC项目中，设计优化和工程变更是为了更好地满足项目需求，提高工程效益和安全性的重要手段。项目管理和质量控制是确保设计优化和工程变更有效落实的关键要素，而信息化技术的运用则可以提高管理效率和准确性。

1、项目团队管理 系统支撑：研发团队工作日志管理；产品开发团队结构、开发团队角色、决策评审团队结构、决策评审团队角色、研发项目信息管理。 2、项目计划管理          支撑项目计划管理过程，具有以下基本功能：  支撑项目工作分解与报批、计划模板、项目计划的审批；  支撑项目计划变更过程。 3、项目计划监控          A、进入项目计划管理模块的计划将自动跟踪与控制： B、对已发布的项目计划，系统将按项目计划提前期进行跟踪与催办； C、以督促项目计划责任人及时有效的执行； D、项目计划执行效率与员工计划完成率等绩效指标的统计分析。 E、 公司决策层监控体系 4、项目风险管理  端到端的风险管理：项目风险提出、确认、跟踪闭环控制过程。 5、项目计划技术          提供Gantt图、WBS定义、项目与流程接口定义；提供项目基线管理。项目计划相关统计工作。 6、项目计划与流程结合           提供项目计划与流程结合管理，对项目状态、交付进行管理。 7、集成化项目管理           A、 项目预算与成本管理（需要ERP按按项目成本管理支持） B、 项目基线管理 8、绩效管理（需要与客户共同制定，二次开发）           A、 基于项目绩效考核KPI统计 B、绩效考核流程（按客户绩效流程二次开发） PLM研发管理系统项目管理模块功能界面展示 项目管理模块（例）—基于WBS的项目计划管理 l         基于WBS的项目计划编制 l         WBS编码管理 l         甘特图 l         项目计划多级嵌套 l         项目计划模板，知识重用 项目管理模块（例）— IPD具有完整的任务处理机制 计划变更时，变更计划后打项目计划基线。 支持PMP管理要求，支持中国式灵活管理 项目管理模块（例）—紧密集成MS PROJECT 项目管理模块（例）—项目成本控制与管理 l         项目成本逐级细分和自动累加 l         固定成本管理 l         资源成本管理 l         资源费率管理 l         项目成本预算 l         实际成本与预算成本比较和控制 l         为项目绩效和项目变更提供单一数据源…

一、功能说明 1、以项目管理为基线的文档管理：以项目计划为主线，文档进行管理。 2、提供完整的文档生命周期管理：将研发过程信息文档、研发最终文档的审批、核准、分发和归档综合一体（包括研发组织内的所有用户和所有文档）。文档生命周期管理记录所有的文档审核、修改、会签意见等过程信息；对文档生命过程所有信息具有完整的记录。 3、提供完整的文档安全管理。按项目专业小组、按工作角色、按特别授权进行控制访问。 4、流程文档归档、物料编码文档管理。 5、文档具有版本管理。项目具有版本库管理。所有进行到系统中的文档具有防删功能。 6、文档管理系统：具有过程日志管理。 7、产品具有版本发展路线图管理。 8、支持迭代开发，在多次迭代开发后从多个版本库中，形成产品最新文档集。 9、支持单个文档借用，项目版本库管理 10、支持文档系统CHECK-OUT完整备份 11、支持SVN文档统一管理 12、支持PDM/PLM接口（需要二次开发） 文档管理模块（例）—集成项目文档管理管理过程资产（PAL） 文档管理模块（例）—技术文档管理－与对象的版本控制 版本控制能够有效地保证技术资 料的正确性和一致性。        对象的签入（checkin）和签出（checkout）               –  签出对象修改               –  签入对象更改 文档管理模块（例）—技术文档管理 通过相关文件归档流程归档 文档管理模块（例）—文档摸索

质量管理模块功能说明 一、 QA管理 研发流程与过程审计、QA事务、质量评审。     研发质量管理流程体系、研发质量管理评审和决策流程、研发质量管理考核标准。 二、质量门径管理 在研发管理流程中、项目管理中建立门径，管理问题、风险、成本等。 三、检视问题跟踪 对源代码、原理图、文档等重要交付进行检视；保证所有问题得到闭环。 四、质量度量体系（需要与客户共同定制，需要二次开发）     产品缺陷度量包括：缺陷密度度量、缺陷数趋势度量和解决率；     缺陷密度度量根据分母的不同可以分成三个不同的角度：从设计规模的角度度量缺陷密度；从制造规模的角度度量缺陷密度；从运行规模的角度度量缺陷密度；缺陷数趋势包括内部和网上新增问题趋势、遗留问题趋势。 问题管理模块功能说明 一、问题生产命期流程管理 定义问题流程；通过流程管理闭环每一个问题。 二、从测试用例直接产生问题 建立产品测试用例清单，从用例记录问题。 三、信息查询 每用户建立一套视图方便查询与检索。所有数据可导出数量 质量管理模块（例）— IPD系统中质量控制体系与QA Gates 质量管理模块（例）— IPD系统中建立ChickList控制 1、流程中将ChickList与任务结合；流程执行时则调用需要的CHICKLIST。 2、 ChickList最终将结果存贮到数据中，方便统计与分析。 3、检查结果作为QA审计重点。 质量管理模块（例）— 将检视与产品交付、配置管理相结合 源代码检视过程与SVN相结合，所有问题闭环后才可以打基线！ 质量管理模块（例）—产品问题与原理图结合，保证问题闭环 质量管理模块（例）—问题管理

  什么是项目、项目群、项目组合？ 项目（Projects） 项目群（Programs） 项目组合（Portfolios） 定义 创造指定范围的一个独特产品或服务。项目是项目群和项目组合的构成基础 一个项目群由多个项目所构成，它是战略性的、实施周期较长 一个项目组合由多个项目或项目群构成，它们具有共同特性，为了管理需要而把它们组织在一起进行管理 特点 短期、战术性的 长期、战略性的 管理周期（每季度、每年） 重点 过程 1)计划与实施项目 2)活动的管理 1) 根据战略定义项目 2) 项目与业务过程的管理 1) 选择项目、项目群；设置项目优先级 2) 连续管理 企业为什么需要企业级项目管理?(1) 企业不仅仅是管理单个的项目，而是管理整个企业内的所有IT项目，并且使企业在IT方面的投入更好地适应业务发展方向和目标。 企业需要IT系统支持各级用户管理 IPD系统符合项目管理的国际标准：PMI PMBOK 项目管理的国际标准：PMI PMBOK   eIPD系统支持完整的项目生命周期管理 IPD系统组合管理介面(1) IPD系统中的：组合项目、项目群、项目   IPD系统组合管理介面(2) IPD系统组合分析 IPD系统组合管理中的项目管理 IPD系统组合管理中的项目研发流程

一、测试用例管理      以需求管理为基础的，测试编制、测试用例分类（单无测试、集成测试、系统测试、可靠性测试）。 二、测试管理      A、从需求管模型制定单元测试计划、集成测试计划、系统测试计划等，将每一项测试工作纳入到项目计划中。      B、源码可视化软件白盒测试（需求到源码特定模块支持）。      C、测试数据保存，按产品版本、按测试计划将所有测试数据保存到系统中。按测试用例形成测试控制统计体系。 三、测试与质量管理结合 四、测试集成      A、测试与项目计划集成      B、从测试用例直接提交问题，与问题管理集成      C、测试用例与需求结合      D、历史测试信息与测试计划结合，保证风险大的测试项目得到控制      E、测试计划单数据分析与比较 测试管理模块（例）—实现从需求出发的，迭代式测试管理 测试管理模块（例）—将需求、测试、质量紧密结合（W模型） W模型是eIPD系统中从需求到测试的理论基础。通过W理论，可减少测试工作量，提高产品质量。 测试管理模块（例）—产品测试计划与历史测试结论相关联，提高测试效率 测试管理模块（例）—测试计划执行情况 测试管理模块（例）—需求基线维度，产品测试通过率 测试管理模块（例）—从产品维度，测试计划与覆盖情况

流程模块功能      提供将所有设计出来的管理流程全部IT化；满足所有流程控制功能要求。流程具有邮件、待办催办，并可实行升级管理。 提供标准化的研发管理参考流程 A、提供支持企业不同类型的研发模型、产品开发流程。定制出不同产品开发流程模型。根据客户定义的IPD主流程，配置出产品开发流程模式。 B、提供技术评审流程、决策评审流程、检视评审流程、项目变更申请流程、技术变更申请流程、项目状态报告、工程变更处理流程、IPD项目计划管理、项目任命流程、项目基线发布流程、基线变更流程、开发合同管理、新物料导入流程、非优选项目选用申请单、研发样品物料申购流程、质量月报、内部问题报告单、QA工作记录电子流、问题跟踪流程、集成测试流程、系统测试流程、过程文档归档、正式版文档归档、BOM清单归档等支持。 C、“项目流程化、流程项目化”功能，将项目管理与流程管理100%结合在一起。 D、流程中终审过的文档归档文档管理系统中。 流程具有SVN相关接口功能，满足检视管理要求。 流程具有邮件、手机短信等催办。 流程具有超期升级管理，及时知会相关领导与流程责任人。 流程管理模块（例）—产品开发流程可完成进入IPD系统 IPD研发管理系统中，IPD产品开发主流程可以导入到系统中，系统流程管理模块设置子流程，每个流程中的活动都有活动说明： 流程管理模块（例）—产品规划与技术规划流程在IPD系统中 技术规划流程：   产品规划流程： 流程管理模块（例）—市场管理流程在IPD系统中 MM市场管理流程： MM市场管理流程对应的交付文档： 流程管理模块（例）—将研发流程与项目计划管理紧密结合 解决流程与项目脱节问题：项目流程化，流程项目化 流程管理模块（例）—通过IPD项目计划调整，实现IPD流程裁剪 通过项目计划调整裁剪IPD流程： 流程管理模块（例）— IPD系统中开盒即用的IPD子流程 IPD研发管理系统中许多IPD子流程都是瑞泽思实施过多家优秀企业总结出来的结晶：

一、物料项目管理（零部件管理）   研发管理系统基本信息维护管理 物料项目管理、项目信息维护、描述性元素、项目状态控制、项目删除、项目拷贝、替代管理。 二、MBOM管理 制造BOM录入、制造BOM导入、制造BOM拷贝、制造BOM检查、制造BOM比较。 三、工程变更（EC变更） 四、BOM信息查询 属性查询 、用途反查、制造清单查询、位号查询、变更单查询、制造清单报表、工程清单报表、工程变更报表、制造商资料维护、基础资料维护、项目清单导入、项目拷贝、替代物料反查。 研发管理系统PART(项目信息)维护管理界面 研发管理系统BOM(工程清单)管理界面 研发管理系统BOM(制造清单)管理界面 研发管理系统变更(工程变更)管理界面 研发管理系统物料编码属性管理界面一 研发管理系统物料编码属性管理界面二 研发管理系统基本信息维护管理界面 研发管理系统BOM拷贝管理界面 研发管理系统BOM自动检查分析界面 研发管理系统BOM比较分析界面 研发管理系统EC变更单管理界面

实现需求端到端的管理。 1、管理公司所有项目需求信息，即公司“需求池”的管理；可持续优化需求信息，避免需求丢失；同时将客户信息、关联产品信息、客户优先级、竞争对手优先级、公司优先级等全部纳入管理。 2、管理产品包的需求与实现过程，规范产品包需求收集、需求分析、需求验证、需求变更控制等工作。 3、管理需求变更过程，保证所有需求变更历史均有记录。 4、具有从需求到测试信息一体化跟踪模式。  A、管理从需求信息到需求测试用例、最终测试信息一体化的信息跟踪；  B、跟踪每个需求的实现、及项目计划信息；所有需求信息全程跟踪。 C、需求基线管理 5、需要管理中的特别要求的功能（支持大团队与高可靠产品研发） A、需求跟踪到源代码；支持白盒测试、源代码检视、CBB B、需求跟踪到原理图；支持产品维修与质量跟踪、支持CBB IPD系统可以解决需求管理中的哪些问题？ 需求管理是确保设计的产品符合人们的要求及期望。但在需求实现过程中，需求管理的困难与问题就暴露出来了。以下为中国企业普遍存在的需求管理问题： l         需求收集往往是不完整的。需求不总是显而易见的，而且它可来自各个方面。 l         需求并不总是可以用文字明白无误地表达出来。 l         需求的数量、种类过多，且其详细程度各不相同，在产品开发过程中难以管理。 l         需求相互之间、与开发流程间、及其他可交付工作件之间以多种方式相关联。而在实际的产品开发过程中缺乏这种联系。 l         需求有唯一的特征或特征值，在实际工作中没有捕捉到并提取。 l         在实际工作需求管理只是研发部门的职责，而需求涉及众多相关利益责任方，意味着需求要由跨职能的各组人员来管理。 l         需求会变更，在实际工作中需求的变更缺乏管理。 l         需求缺乏层次、优先级别管理。 当上述问题出现，同时团队处理问题的技能不足并缺乏易用的工具时，许多团队就会对需求管理失去信心。瑞泽思开发出指导团队提高需求管理技能的专业技术,并使用相应的工具使得上述的流程和专业技术得以实现；eIPD系统解决上述8大需要管理问题。 eIPD系统中的需求定义 需求是对产品或过程的操作、功能和设计的特性或约束的表述，这些表述是明确的、可测试的、可度量的，而且对于产品或过程的可接受性（被顾客或内部质量保证措施）来说是必须的。——IEEE1220-1998 IPD系统中的需求定义与IEEE1220-1998类似：“正在构建的产品、系统、技术模块必须符合的条件、具备的功能、验证的条件及相关事务”。 2． IPD系统中的产品需求管理模型 IPD系统中需求集合为，除上述定义的范围外，还包含测试相关的测试用例。为此IPD包含：市场需求、产品包需求、设计需求、系统集成测试用例、系统测试用例、单元测试用例。 需求分层次、类型及转换过程。如下图所示，不同层次的需求和同一层次的需求之间存在转换关系；各转换关系内部存在追踪关系。eIPD系统实现了需求间完整的转换关系与追踪关系。 需求管理模型简述如下： 产品开发团队首先必须从客户原始要求中获得业务和用户需求，对其进行描述，并区分它们的优先级；其次从客户期望或需求出发，对产品或系统特性达成一致意见，并与内部需求、行业标准与约束共同形成产品包需求；再者从产品包需求形成设计需求与构架设计需求；最后由产品或各级系统特性来抽取软件需求、硬件需求、结构需求。需求管理模型中，测试需求则转换为测试用例模型的方式来描述。从测试的角度来看，测试项一定来自于设计需求，即设计需求中确定了哪些需求项，测试用例需根据这些需求项来制定和实现。 IPD系统中需求管理界面 需求定义 需求组合 产品组合 需求基线管理 需求追踪 从开发需求生成WBS三、四级开发计划