引言 随着时代的发展和社会的进步，EPC 工程总承包模式得到了越来越广泛的应用。工程造价管理和成本控制是EPC 工程总承包模式的核心内容。 目前EPC工程计价模式主要有三种模式：总价包干计价模式、按照定额计算下浮费率计价模式、模拟清单计价模式。 各种计价模式各有优缺点，在实际工程中也各有应用；目前在大量的政府类投资项目中，因为建筑特异性、建设周期短、前期研究时间不足、无法及时完成初步设计、确定投资概算等各种原因，导致总价包干计价模式、模拟清单计价模式得不到采用，往往采用按照定额计算下浮费率的计价模式；采用这种计价模式时不可避免涉及到在实施过程中需要对大量的材料设备进行认质核价，给造价控制和管理带来新的难题。本文就EPC项目实施中材料核价难点要点进行分析和阐述，以资参考。 01 费率下浮计价模式下的材料认质核价难点及要点 EPC 总承包就是指建设单位委托总承包单位来包揽建设工程项目的设计-采购-施工。和传统的工程模式相比EPC总承包模式有着很多的应用优势：首先建设单位只需要和总承包联合体单位签订合同，合同的结构也相对简单；其次业主方管理团队相对于平行发包模式要简单，无需面对很多个平行施工单位、设计、勘察单位；还能够充分发挥总承包单位的主动性，整合设计、采购、施工资源，实现主动的造价控制和成本优化。 目前大量的政府类投资项目中采用定额计算费率下浮的计价模式下，合同约定一般均为“结算按照XX定额组价并按照投标下浮比例下浮，其中原材料价格采用方式：工程造价信息上有的材料价格采用信息价，信息价上没有的材料价格按照发包人认质核价价格计取。”。基本上都是约定需要实施过程中进行材料认质核价。 1.1 费率下浮EPC项目中询价的难点主要有 （1）房屋建筑、安装工程使用了各种品牌、类别、规格、参数不同的材料设备，这些材料的品牌、参数、规格均对材料价格有实质性影响。而造价信息不可能、也做不到将各种施工过程中需要使用的材料、设备都列出，尤其是公共建筑，特别是体育馆、展览馆、医院等大型公共建筑，由于建筑的特异性涉及到施工中使用很多新材料、新工艺，这些新材料在其他项目中很少会使用，因此给材料核价造成了很大的困扰。 （2）项目中均存在核价材料价值大（占工程造价比例达到40-60%），市场上材料价格不透明，很多知名品牌区域供应商只有单一供应商，因此形成询价核价困难； （3）因为费率下浮的EPC项目均是总承包，没有列材料暂估价，也没有办法由业主单独进行材料招标，造价咨询人在询价过程中，往往遇到厂家不报价、报价不准确（严重偏高）的情况，造成询价核价困难； （4）因为询价过程中，厂商很容易判断出咨询人和业主只是询价，不会购买材料设备；因此厂家给出的报价只是初步报价，和实际市场上成交价有差异；实际的成交价与材料供应距离、交货方式、保修时间、付款方式都有很大关系，因为是询价没有办法作更深的谈判，因此询价结果比成交价高出的比例判断很困难，造成询价和核价困哪； （5）造价咨询人及业主合约管理部门一般均积累了部分材料价格库，但是材料的品牌、参数、规格、材料涨跌情况这些的影响，在实际中用类似项目价格判断核价合理性还是有局限； （6）询价平台提供的报价准确度不高，非常规材料报价满足不了核价要求，造成询价核价困难； （7）因为核价没有采用市场竞争定价，是协商定价；在定价前承包人已经选定，变成了发包人/咨询人与承包人的博弈过程，造成核价困难。 1.2 费率下浮的EPC项目核价的要点主要有 （1）询价准备：列出询价材料规格、参数，供货地点； （2）多途径询价，通过询价平台、厂家询价、电话询价多种方式询价；主要还是依据厂家报价，电话询价、平台询价只能作参考； （3）分析询价结果，加权平均，做合理修正； （4）核价过程，坚持公平、同时不轻易让步； （5）在争议解决不了的时候，利用类似项目投标价格、核价价格作为佐证资料，处理争议，实在解决不了争议，要求承包人提供采购合同、发票等资料。 1.3 某公共场馆项目材料核价的步骤 该项目为成都市地标性公共建筑，建设地点位于成都市四环路内；地上建筑面积约7万m2，为大型场馆类公共建筑，承发包模式为勘察-设计-施工总承包（EPC）模式；结算中工程建设费按照实际工程量计量，采用四川省15建设工程定额组价后按照投标费率下浮计价。 合同专用条款约定结算材料价格“材料价格以施工图完成行政审查当月成都市造价管理站发布的《工程造价信息》中当地市场综合价作为结算价格，可调材料价格按合同“16.1物价波动引起的调整”中条款执行。除商品砼、预拌砂浆、钢筋、钢型材、管材、电线电缆采用成都市市场信息价作为结算价格外，其余材料由发包人出具的材料核价单作为结算依据”；该项目涉及到大量的幕墙材料、钢结构、金属屋面、安装材料、总平景观绿化材料需要核价。 该项目地上全部为钢结构，涉及到钢结构总量约1.5万吨，涉及材料价格约1个亿。因此钢结构合理核价直接关系到项目投资控制和顺利推进。本项目钢结构询价核价（以下均为不含税价）过程如下： （1）承包人在2020年11月进行钢结构订货，预计在2020年11月至12月进场安装，钢结构施工期间在2020年11月至2021年3月。因此造价咨询人根据项目实际进度，要求承包人按照2020年11月基准期上报核价单；承包人在12月初上报了钢结构的核价申报价如下： （2）在承包人准备造价咨询单位在准备钢结构订货的同时，在11月中旬至下旬进行了成品钢结构市场材料调查询价，发出询价单格式如下： （3）通过多途径收到共7家钢结构厂家报价单，均有钢结构专业承包一级资质企业报价。其中有三家国内知名的钢构均报价偏高，且没有提供报价明细、生产地施工现场距离远（超过1000km），进行了排除。经过筛选后剩余的4家比较合理报价单分析如下： （4）分析成品钢结构价格组成及合理价格区间： 通过市场调研，成品钢结构价格组成主要如下： 成钢结构的到场价格=原材料价格+加工损耗费+制作费+深化设计费+防锈底漆费+运输费+上下车费+厂家管理费、利润+（采管费）。采管费一般占1.5-3%左右，本项目询价时没有列采管费，厂家报价也没有单独报采管费。 经过统计2020年11月“我的钢铁网”上西南地区钢材原材料价格，Q355B钢板价格平均价在3826元/t(按照不含税价报价+140元钢材市场到厂家运杂费)。Z15/Z25钢材价格一般比同等级钢材价格高200元/t。 按照钢构价格组成分析成品钢结构的合理价格区间： （5）对比询价综合平均价、价格区间、相关资料价格： 成都市造价信息上没有成品钢结构价格，但是四川省造价信息上有部分地区有造价信息，上面有部分类似钢结构的信息价，进行综合平均价、合理价格区间、信息价三类价格来源对比： 经分析，综合平均价略低于造价信息价格，位于合理价格区间中值位置，价格水平适中；因此按照询价综合平均价作为核价建议价向业主汇报。 （6）汇报业主后向承包人核价： 向业主汇报后，因询价依据充分，价格与类似同期项目价格水平吻合，业主同意向承包人按照此价格核价；在核对过程中通过反复的拉锯，施工单位提出此核价价格偏低，且咨询人的询价结果中没有包含承包人的采管费在内； 通过反复协商解释，造价咨询人和业主要求施工单位提出偏低的理由，或者提供其他项目同期的核价资料、或者本项目的钢结构订货合同。造价咨询人提供了与同期其他地区信息价的比较表给施工单位，证明核价价格是比较合适的价格；同时解释咨询人的询价是厂家的报价，实际签约价应当低于报价，采管费应当考虑在签约价低于报价那部分，不应当再单独计取。施工单位拿不出合理的资料证明核价价格偏低； 最终反复核对协商后达成一致意见，发承包人同意了按照咨询人核价建议价格作为基准期（2020年11月）成品钢结构核价价格，钢结构核价工作顺利完成。 02 总结及思考 近年来EPC项目越来越多，在按照费率下浮计价的模式下存在大量的材料价格需要核价。这些材料价格根据目前的相关法律、合同条款又不属于暂估价，也没有办法拿出来由发包人与承包人共同招标，因此造价站咨询人和业主合约管理部门在施工过程中管理难度非常大。如何做到有效控制投资又能够顺利推进项目，是造价咨询人和业主的合约管理部门面临的新课题。 2.1 笔者总结了几个步骤和要点以供参考 （1）大量常规的材料，例如防水材料、保温材料、安装管线、开关插座、水暖元器件等材料，可以按照同期项目价格进行核价，在市场询价也比较好询，承包人没有能力封锁询价途径；这些价格也比较透明，可以通过询价平台网络询价、电话询价询到比较准确价格。 （2）对于大宗材料，例如钢结构、金属屋面、特殊规格玻璃这类材料，在询价平台网站上询价差异非常大，而且每种材料涉及金额非常大，在施工中核价不能采用询价平台的报价，应当通过电话联系厂家要求厂家或者供应商提供盖章报价单。这类材料询价过程中承包人可能会通过向经销商打招呼封锁报价渠道，但是可以通过采用其他项目名称，或者通过其他省的经销商进行报价解决。承包人也没有能力把全国的询价途径封锁完，因此询价还是能够解决。 （3）对于新材料、特殊材料，例如蜂窝铝板，特种门、安装的大型暖通设备、定制特殊规格电梯、屏蔽体等，这类材料类似项目中使用比较少；而且像蜂窝铝板因为需要根据曲面进行加工定制、曲面曲度、安装精度、板面的厚度影响价格比较大，特种门的安防等级、认证情况对价格影响也比较大。这类材料询价比较困难，厂商的报价差异也很大，属于核价比较困难的类别。…

  导读 PDM与PLM是产品创新数字化领域中极为常见的两个名词，然而不论在销售环节、实施环节，很多人经常在概念上混淆和滥用，本文力图对这两个概念所关注的领域进行一定的差异说明。 1、PDM PDM作为产品创新数字化的重要概念，是Production Data Management的缩写，顾名思义，关注点在于产品数据的信息管理，并且在传统的理解中，更确切的是指产品研发过程的数据管理，即Engineering Process Management，内容一般会包括如下常规部分： 1) 文档管理 文档是产品数据中不可缺少的部分，如各类行业设计标准及规范、产品的市场需求、产品研发过程产生的的需求分析、详细设计等技术文件，甚至包括这些文档的模板，都需要进行良好的管理和标准化。当然，为了更顺畅进行文档的内容更改记录和结果管理，往往需要在此环节涉及PDM系统与Office办公工具软件的集成。 2) 图纸管理 图纸是产品设计的重要结果数据文件，是PDM关注的核心，而在PDM逐渐成熟的过程中的早期，国内市场上大量存在的是图文档管理系统。直到现在，很多国产PDM系统依然以图文档管理作为核心功能。 3) CAD集成 产品在完美体育WM的生活中无处不在，用于进行产品设计的工具软件也种类繁多，为了更好的进行图纸管理，将图纸信息（甚至包括图面信息的提取）如何顺畅的从CAD环境传递到PDM系统并保持同步性和关联性，则带来了CAD集成这样一个重要的实施部分。常见的CAD软件如AutoCAD、基于AutoCAD的二次开发软件、NX、Pro/E，以及Protel、Cadence等。 4) 可视化管理 由于图文档均被纳入到PDM的管理数据，然而由于相应的图文档编辑软件种类极为繁多，PDM中的使用者（包括各级领导）面临大量不同格式的图文档浏览需要，如果人人都安装各种编辑软件是不可想象的。提供统一的公共的可视化管理成为必需。 5) 物料管理与产品结构管理 在PDM系统中仅仅管理图文档的管理是远远不够的。按照PDM的传统理念，是以产品结构为中心组织各类数据，产品结构由各种类型的物料所构成，也成为每份图文档文件所依附的节点。物料管理作为一个独立的话题，还面对很多内容，如物料的编码系统，物料的创建申请，物料的可用状态的变化等等。 6) 产品配置管理 越来越多的产品需要在标准配置或功能基础上，为客户进行不同程度的个性化定制，这带来了设计环节思路上的重要变化，即产品配置管理。可以为客户提供大量的丰富的可选功能部件，满足不同的客户需求。如针对功能的标准型、高级型、豪华型，如针对不同地区的型号，针对不同性别年龄的型号等很多角度的产品设计资料的配置。 7) 工作流管理 正如上面所提及的，不论是图纸还是文档、物料以及产品结构，都需要从草稿状态到最终发布生效（甚至是多次的阶段性发布生效），相应的大量签审过程都属于工作流管理的范畴。可以这样讲，工作流驱动机制使得PDM能够管理数据状态的不断变化。 8) 其余基础部分（组织管理、权限管理等） 理所当然的，为了能够在PDM中创建和访问数据，相应的要管理必要的人员组织以及权限等基础性架，以上提及的，是PDM的常规涉及范围，而PLM，则代表了更全面的视角。 2、PLM PLM是伴随着PDM的不断实施而发展出来的概念，即Production Lifecycle Management，关注点在于产品的生命周期。产品生命周期是一个非常宽广的概念，也为PLM的行业带来了更多的业务机会。 PLM的观点认为，一个标准完整的产品生命周期应该起源于需求。这种需求可能来自于市场的调查、分析或者反馈，也可能来自于企业自身不断创新推出新产品引领市场的需要。由于成本原因、技术风险原因或者市场条件变化等原因，最终有多少需求能够真正反映到企业的新产品中是一个值得探讨和管理的话题。因此在PLM系统中第一个关注的就是需求管理，跟踪有多少需求是最终有效的，以及这些需求的实现结果，并为后续新品的开发积累基础。 当相应的需求不断细化后，接下来会展开概念设计的工作，此阶段产生大量的技术尝试方案和原型系统以支持可行性论证等工作，虽然此时并非正式的产品研发，但作为企业的宝贵知识资产必须进行合理的管理和总结分析。 当企业真正确定了产品将采用的技术方案后，则进入了Production Engineer环节，即以往PDM的管理范畴，在此不再赘述。 从工作环节划分上，在完成产品的基本设计后，为了支持后续的生产，还必须要经过工艺设计。在不同产品类型和生产类型的企业中，工艺可能是指设计工艺，也可能是指生产工艺。这部分工作涉及到了工艺路线、工艺规程、工艺卡片等，也就是以往在中国广泛存在的CAPP系统的范畴。在PLM的大概念下，将工艺环节纳入并作为一个不可缺少的实施环节。 产品经过工艺设计后，会安排小批量的试制或者试验，试验数据也将对产品量产或交付上市前的完善产生重要参考支持，即TDM（Test Data Management）所关注的业务环节。 产品最终交付给客户后，通常还需要进行售后维护，那么该何时定期维护、如何管理和跟踪产品的实际状态以决定预防性维修，如何制定产品出现问题后的维护策略（如就地维护还是返厂维护等），则是一个目前新兴的重要业务领域，即MRO，同时MRO的大量信息也需要来自于最初的设计部门的产品设计资料以及产品出库和交付过程的大量记录信息。 最终随着市场的发展和更新换代的需要，一些型号的产品不再安排生产和售后维护从而真正的退出市场，意味着这类产品生命周期的结束。 这样的一个完整过程是产品生命周期理念的精髓和管理价值所在，同时在此过程中，必须要解决项目管理视角的数据组织、质量管理体系的建设、与周边ERP系统以及MES系统的信息交互，各种类型BOM数据的转换交付文档的动态内容出版解决方案，以及需要集成更多种类的工具软件（CAE/CAM）等大量细节问题。 3、总结 通过上面的表述，相信很多人已经对PDM和PLM的概念能够做出相应的区分判断。大致的差异有两点总结： 1) 关注范围不同 PDM关注的是研发数据的管理，虽然也会涉及其余部门，一般会重点集中于设计部门进行实施，而PLM关注整个产品生命周期，实施范围可能涉及市场、销售、研发、工艺、制造、工程和售后维护等大量环节，每个环节都有可能成为实施的关注点。可以说，在业务范围和功能深度上，PLM做了大量的延伸。 2) 实施难度不同…

一、项目背景   1949年5月，红星前身——华北酒业专卖公司实验厂成立，其后收编源升号等十二家老酒坊，全面继承了北京二锅头传统酿造技艺。作为北京地区第一家国营酿酒厂，酿制出第一批红星牌二锅头酒，向新中国的诞生献礼。由于出色完成任务，红星成为唯一一家参加过开国大典的酒企。同时，红星也成为北京第一家将二锅头工艺名称用作产品名称的企业，开创了北京二锅头品类。 红星是著名中华老字号企业和国家级非物质文化遗产保护单位，70多年来始终践行“为人民酿好酒”的历史使命，成为老百姓餐桌上的当家酒。1951年，红星商标成为新中国首批核准注册的商标之一，被誉为“二锅头家族第一标”。1958年，红星对“红星牌二锅头酒”进行商标全注册。1965年，红星对19家郊县酒厂进行归口管理，并倾心传授二锅头技艺，使二锅头品类从一枝独秀到百花齐放；1997年，红星56度大二被国家技术监督局认定为二锅头酒国家实物标准样，成为品质标杆。   项目简介   作为业内优秀的信息化解决方案服务商，北京华胜龙腾软件技术有限公司（以下简称：完美体育WM软件）秉承着创新和卓越的理念，致力于为企业提供先进的信息化工具和技术支持。完美体育WM软件依靠自身产品优势成功中标北京红星股份有限公司（以下简称：红星股份）基建项目管理系统项目。此项目将为红星的基建项目管理和运行提供先进的信息化工具支持，这一战略合作标志着双方迈向新的里程碑。 双方此次合作搭建项目管理系统将充分利用完美体育WM软件的先进技术和丰富经验，为北京红星股份有限公司的基建项目提供全方位的管理和控制。该系统将覆盖项目的全生命周期，从项目立项、计划管理、资源分配到进度控制、质量管理等各个环节，实现全面的信息化管理。   本次项目建设目标主要围绕以下四方面开展： 建立健全基建合规管理体系：将根据红星基建管理业务需求和业务流程，通过信息化手段制定一个全面科学的项目管理体系，优化项目资源的分配和利用，建立从项目批复到项目建成使用的全过程流程，并确保每个阶段的工程资料得到完整存档。这将有助于日后的项目维护和管理，并为可能出现的审计和验收提供依据。 实现基建项目投资动态化管理：通过动态化和透明化的投资管理，全面跟踪项目投资的各个阶段，包括批复预算、合约分解、投资控制、合同签约、产值确认、付款、现场变更和结算等。该项目管理方案将在基建投资规划期间，以合同为核心，对预算进行合理的统筹规划，明确未来合同的投资额度是否存在超出预算的风险。在投资执行期间，它将监督每笔投资花费与投资规划的偏差，并提醒投资者当前存在的超出预算的风险。在投资管理后期，它将实时反馈预算的结余数据，以便对剩余投资余额进行合理调配。 实现内外部资源集中化管理平台：以提高工程相关部门之间的协作效率。通过该平台，各参与单位可以轻松共享信息、文件和沟通记录，确保信息传递的及时性和准确性。通过信息化的手段，实现任务自动分发，确保责任的透明度和监控项目的进展。 实现对基建项目数据全面收集及监测分析：这些数据将与预设的标准范围进行比较，一旦项目超出标准范围，完美体育WM将按照对应的预警机制进行预警通知。   通过引入基建项目管理系统，北京红星股份有限公司将实现项目管理的标准化、规范化和自动化，有效提高项目管理的工作效率和项目运行的质量。系统将提供强大的数据分析和报告功能，帮助企业进行即时决策和精准管理，更好地掌握项目的进展和风险。北京红星股份有限公司与完美体育WM软件的合作，将为基建项目管理带来全新的变革，提升行业的效能和竞争力。期待这次合作取得圆满成功，为双方带来共同的进步和发展。          

IPD适用于软件企业吗？IPD与CMMI、敏捷是啥关系？软件企业应该如何推行IPD？ IPD的概念诞生于上个世纪八十年代，由IBM在九十年代进行实践应用，上个世纪末传入华为，近些年随着华为的兴起而广为人知，并随着华为系咨询培训团队的壮大而走入了众多的企业。时至今日，基本上快到了谈研发管理必称IPD的地步。 IPD被看作是第三代研发管理的代表，它在第二代研发管理–面向项目成功的研发管理的基础上，将市场管理、需求管理、技术管理与新产品开发管理进行了有机的融合，从战略和执行层面有效的解决了新产品开发的市场导向问题（IBM最初将其称为WWDS：Worldwide Development Strategy 全球开发战略 ），并将管理委员会制度以IPMT的形式进行落实，实现了企业研发由管理到治理的转变，并为矩阵式管理的落地提供了有力的抓手。并通过基于团队的管理、结构化的流程、业务分层管理、异步开发来实现对技术创新的风险性及产品开发的时间性、稳定性的兼顾。 无论是上个世纪的IBM还是现在的华为，虽然对软件都很重视，但企业提供的毕竟是硬件为主、软硬件兼顾的产品或解决方案，真正的软件与信息技术服务公司推行IPD成功的经典案例基本上没见过。这是因为纯软件开发和硬件产品开发或软硬件一体的产品开发有很大的差异性。 ·产品设计：硬件产品开发历史悠久，标准化程度高，产业链相对成熟，企业只需要进行部分内容设计及系统集成。而软件的开发往往需要企业负责所有的策划、设计和开发工作。 ·开发周期：硬件产品的开发经过策划、设计、验证、生产等一系列的复杂流程，需要循序渐进的展开，直到最后交付成熟产品，因而开发周期较长且相对固定。而软件项目则可以更加快速地进行迭代，在具备一定功能和成熟性后即可推出，后续再逐步完善，其开发周期多变。 ·产品交付：硬件产品设计定型后可以批量生产，产品质量通过质量检测体系可以得到保障。但是生产、加工过程一旦失误，硬件产品可能就会因为质量问题而报废。而软件产品不能用传统意义上的制造进行生产，就目前软件开发技术而言，软件生产还是“定制”的，只能针对特定问题进行设计或实现。 ·开发成本：硬件产品的开发涉及很多的过程物料，成本较高；而软件产品的开发主要是人工成本，其他物料成本较低。 ·物料管理：硬件项目涉及到大量开发物料，需要考虑物料采购和库存管理，要有严格的入库标准和出库流程，而软件项目在这方面相对简单，只需要做好版本管理即可。 ·测试：硬件项目的测试比软件项目的测试更加严谨和复杂，需要进行多个环节的测试，如硬件元器件测试、系统整体测试等。因为硬件问题的修复成本太高。 ·质量问题：得益于成熟的产业链及开发过程中严谨的测试，硬件相关质量问题较少，其质量特性符合浴盆曲线，但一旦出现质量问题，对系统的影响往往是致命的。而软件相关的质量问题较多，误操作、病毒、逻辑问题等等都会引发软件问题，而软件设计标准化程度较低，很少能借用业内成熟的通用设计，也是造成软件质量问题较多的原因，但软件问题解决相对容易，通过系统重置或软件升级能够解决大部分的问题。 由以上可见，软硬件开发的差异更多的表现在项目的操作执行层面。 在回答IPD是否适用于软件企业之前，完美体育WM先看一下IPD、CMMI以及敏捷的区别。 总的来讲，IPD主要从战略层面、企业整体经营管理的层面来看研发行为，关注市场成功，涉及的范围包含了研发、采购供应、生产制造、质量管理、服务支持等多个部门，是一种系统的产品开发经营管理的思想、方法、模式。CMMI最早起源于美军标对供应商的要求，主要涉及软件开发领域，它不是标准，也不是流程，而是一个实践模型、一种软件质量管理体系，它给企业提供了一个可预期的改进路线，可以帮助软件企业提升开发效率和产品质量，CMMI和软件开发的关系就如同企业经营管理与ISO的关系。敏捷一般是指敏捷软件开发，它是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称，其核心思想是从瀑布式开发所代表的“固定范围、弹性时间”转向“固定时间、弹性范围”，以资源为约束，实现“项目范围”最大化实现，从计划驱动转向为价值驱动。因此可以说，IPD可以告诉完美体育WM在方向层面选择什么不选择什么，CMMI则在项目层面指导完美体育WM应该做什么，敏捷可以保证开发中的举措更好的在团队落实，因此三者是相辅相成的。 近年来，研发管理总体的发展趋势为在时间轴上表现为逐渐左移，即研发管理工作更注重早期的全面思考、系统规划；在管理轴上表现为逐渐上移，即由研发部门层面上升到公司战略层面。虽然在VUCA时代对快速响应提出了更高的要求，但这种快速响应一定是在方向基本明确、需求相对清晰、目标一致情况下有条不紊的响应，而不是如无头苍蝇般的胡乱响应。因此，将IPD与CMMI、敏捷相结合，将是软件企业研发管理的发展方向之一。 对于一定规模的软件企业，一般具有多年的软件开发经营，已经在项目层面熟悉了CMMI流程以及敏捷开发模式，IPD推行应该更多的关注其面向市场开发理念下的治理机制以及管理决策手段的应用。因此建议软件企业在以下几个方面借鉴IPD的管理思想： –实现产品开发市场导向，针对任何一个软件的开发，都要先在商业方案分析，从市场细分、产品定位、市场机会、市场壁垒、竞争优势、产品战略、市场风险、财务收益等方面进行分析，确定在确定有市场、有优势、有收益的情况下在进行产品的开发工作，避免拍脑袋决策，提升产品的商业成功率。 –做好需求管理，由于软件需求是无形的、主观的，且难以描述和检测，所以软件需求的把握难度更高。在这方面可借鉴IPD的管理理念，搭建需求管理组织，建设需求管理流程，从而实现对需求的规范化管理。 –做好IPD与敏捷的融合，明确应用敏捷应用的层次和范围。 –重视项目策划工作，要尽可能的详细策划、快速决策、快速执行。 –搭建投资管理和技术评审的组织，让企业有固定的组织为相应的项目投资收益负责、为技术评审负责，并需要这两个组织具有快速决策、快速评审的能力。 –做好决策评审和技术评审，根据软件项目特点，做好决策评审点、技术评审点设计，使其能够满足项目投资风险控制与质量控制要求；做好决策评审、技术评审的流程、汇报模板和相应的检查表，尽可能消除个人能力差异对评审结果的影响。 –对复杂产品做好前瞻性技术规划，系统性策划，模块化设计，分阶段开发。 总之，软件企业的IPD应用不能照搬照抄现在硬件型或软硬件一体的方案型企业的经验和案例，需要结合软件企业的特点，从战略层面、项目的策划和决策层面应用IPD的研发管理思想，实现IPD与CMMI、敏捷的有机融合。

两周前，在一家企业探讨面向大批量定制的产品开发管理方案，其中讨论比较多的就是当企业的产品开发从MTS到MTO，一直到随着市场针对产品迭代周期持续缩短，企业为了适应快速变动的市场，必须投放更多面向不同细分市场领域的产品，产品种类也急剧增加，大量定制化需求也不得不响应，产品开发交付模式就变成了CTO和ETO；那么有无更高效的办法满足这种定制化市场的产品开发方法？都说IPD是面向市场开发的“神丹妙药”，那么通过IPD的思路是否可以解决这方面的问题？ 其实华为的确在二十多年前就识别到了产品面向不同需求时，传统的缺少整体策划的开发方法对与面向市场的复杂高效交付过程有很大挑战，因此将技术开发和产品开发分层异步运行，成立了“中研部”和“中试部”；并且在这个过程中逐步将无须的产品开发转型向有规则的平台开发，并且通过平台支撑企业的产品开发，例如C&C08平台的成功策划，不仅支撑了华为从困境中的转型，而且基于此平台衍生出大量的产品，满足了华为征战四方的很多领域的产品。 很多企业担心平台战略会阻碍企业的技术创新，但是我也认为这是一种不正确的看法，例如华为不允许投放市场的产品创新超过30%，否则就是浪费和冒风险，也就是说至少70%可以基于企业的沉淀进行重用，才能降低并可预测；及时针对特定的项目、产品进行了创新，但为了让创新被重复使用产生更大的价值，那么的确也是需要将创新融入企业的平台，这样平台的飞轮才能转动起来；平台不会阻碍创新，平台会支撑企业更多的创新有序进行，也降低了创新的风险；企业坚持平台战略，有前瞻性和持久地大规模投入，确保平台可以被不断的积累和重用，推动飞轮转动；当然，平台建设要耐得住寂寞，就像华为说的“板凳要坐十年冷”。针对企业平台建设的飞轮，当然也没有企业能一蹴而就，循序渐进的过程，我的建议如下：什么是平台，如何定义平台呢？关于这方面的资料很多很多，不同人有不同的看法，属于百家之言；这里可参考华为制定了十大核心原则来指导平台与架构的设计： 全面解耦原则：对业务进行抽象建模，业务数据与业务逻辑解耦，软件和硬件解耦，平台和产品解耦，系统各部件间解耦； 服务化、组件化原则：以服务、数据为中心，构建服务化、组件化架构，具备灵活、按需组合的能力。 接口隔离及服务自治原则：通过接口隐藏服务、组件的实现细节，服务、组件间只能通过接口进行交互，接口契约化、标准化，跨版本兼容；服务、组件可独立发展、独立发布、独立升级；服务自治，可视、可管、可控、可测、可维、故障自愈。 弹性伸缩原则：构建全分布式云化架构，或借鉴云化架构思想，每种服务具备横向扩展能力，支持按需使用、自动弹性伸缩，可动态替换、灵活部署，支撑高性能、高吞吐量、高并发、高可用业务场景。 安全可靠环保原则：构建最小权限、纵深防御、最小公共化、权限分离、不轻信、开放设计、完全仲裁、失效安全、保护薄弱环节、安全机制经济性、用户接受度以及加强隐私保护的安全体系，确保系统、网络和数据的机密性、完整性、可用性、可追溯；以业务系统零故障为导向，按需构筑分层分级的可靠性，通过故障的预测、预防、快速恢复，避免故障的发生；系统资源使用效率最大化，实现节能、节地、节材、环保。 用户体验和自动化运维原则：面向业务获取和使用场景，构建实时、按需、在线、自助、社区化、方便易用的用户体验；支持远程、自动、智能、安全、高效地完成网规／网设、安装、部署、调测、验收、扩缩容、软件升级、打补丁、日常维护、问题处理。 开放生态原则：面向生态场景，按需开放平台设施、中间件、数据、业务逻辑、UI等能力，构建开放生态，支持分层、远程、自动、自助、简单高效地完成定制、集成、第三方应用开发。 高效开发原则：创建支持迭代、增量、持续交付的架构，支持部件独立开发、自动化编译构建、测试、集成验证，并易于高效修改和持续优化；支持开发组织小型化、扁平化，支持小团队独立高效并行开发。 柔性供应制造原则：模块化设计，模块、物料归一化、标准化，支持自动化、数字化、智能化、随需应变的柔性制造。 持续演进原则：架构并非一蹴而就，需要有效地管理架构需求，持续构建和发展架构，适应业务需求变化，适时引入业界最佳实践，及时重构，确保架构生命力和竞争力。 平台的策划和设计非常专业，我在这里不浪费文字进行啰嗦；但是对于组成平台的子项架构设计，却在多家企业参与过咨询和辅导，一步一步走来，收获颇丰，感触也很多。 策划平台的架构时，组成最核心的是模块(什么是模块？)，当然这里的模块在很多企业容易理解成为产品研发设计部门内的模块，当然这在一定程度上可以提升产品开发的效率，但是跨部门协同的壁垒依旧存在，因此这种模块化完美体育WM认为是企业的意识觉醒，即模块化2.0，要是提升模块化协同，必须向更高的层级层级提升，这样才能产生更大的应用价值。 那么如何定义模块呢？其实基本规则也很简单，按照模块的概念定义，有明确的输入，经过模块过程处理后，有确定的输出——其实和什么都没说一样，或者简单说就是可以独立实现一定的功能；那么提供一个产品，如何考虑模块呢？步骤如下： 功能从粗到细拆解：因为功能过细会增加过程管理的复杂性，因此按需逐步深入和细化； 评估是否建立与装配工艺分离面：就是可以单独在某一工艺单位完成使用，例如工厂/产线/工位段/工位等； 是否可以独立进行任务分工：每一个模块都有独立的负责人，负责模块的开发、验证和交付，因此必须进行拆分； 基于重用度继续拆分：将变化频率比较高的结构和比较低的分开，这样可以继续提升模块重用度，减少不必要的复杂变更； 当然，针对模块的定义，我在日常的工作中，也进行了复盘和总结，基本思路包括： 独立性原则：模块的选择、替换、生产和制造相对独立，接口耦合尽量少； 粒度适中原则：模块的粒度和数量必须控制在合理范围内，但可逐步细化； 重用性原则：通过将更多模块由客户定制选项升为备用选项提前开发，增加重用和效率； 唯一性原则：针对特定产品，模块仅唯一定义，包括左右件也属于不同模块； 设计分离面与工艺分离面一致原则：模块划分需要考虑设计和工艺的独立与协同； 单级分层原则：模块不能嵌套使用，这样可简化配置和有效性管理； “只加”原则：指模块可以像搭积木一样调整，满足客户差异配置需求(大批量定制)； 广义原则：模块是一个组建的逻辑组合，同时可包含需求、功能、设计、工艺、制造和检验数据； 以产品坐标系为参考坐标系原则：基于产品，建立唯一的方向、位置主坐标系； 以安装件为参考原则：模块包含主体件和支撑主体的连接件； 当然对于一个真实的产品，这些只是最基本的产品平台策划、架构定义和模块划分的原则，实际操作起来受企业很多方面的约束 更多详细方案：科研研发项目管理软件（IPD产品研发、PLM全生命周期管理系统） – 【完美体育WM】领先专业项目管理软件商-工程施工、科研研发、基建投资大数据项目管理系统平台。

企业如何从传统的单产品设计转型到面向平台的产品开发？ 说起面向平台的产品开发，现在在市场上、网络上看到的资料几乎是汗牛充栋，但是几乎说明的都是优势，尤其是华为IPD的成功，更是带火了一波针对企业对平台的重视；在企业咨询中，很多企业也都希望面向平台展开产品开发，并且梳理了一定数量的平台，执行效果确不进人意；有些企业希望细细的打磨平台，结果当市场订单多的时候，在交付优先的情况下，这个肯定不是第一优先级，当市场销售不好时，这个好像又没有必要了。总之，平台是好的，但企业落地起来第一有点盲人摸象，第二有点鸡肋。 什么是平台？企业如何构建自己的产品平台，我也一直在寻找这个问题的答案；我查了百度，告知产品平台是为系列产品所共用和共享的，强调的共同要素，尤其是决定性技术(决定性的技术也是比较抽象的定义，完美体育WM先暂认为是一样的技术路线)，再向源头追溯一下可能的资料，先来看两个产品平台的概念定义： 《PACE-产品及周期优化法》中，定义产品平台是关于产品规划及其战略决策而制定的一个概念，它是整个系列产品所采用的共同要素，特别是基本的决定性技术的集合； 《Porduct Design And Develppment》中，定义产品平台指由一系列共享的一整套资产，零件和部件经常是这些资产中最重要的部分； 所以在企业从常规产品开发向平台开发转型时，的确需要思考一些问题，贸然推进的确摸不到产品平台入门的路径，这个路径也只能企业自己去梳理和探索，对任何第三方专家和顾问的“直接喂入”都要三思。 在一家重型车企业，完美体育WM在一起进行了很细致车型平台的讨论，这里最关键就是核心技术路线的确定，就是在繁杂的衍生中，明确基层核心技术的一致性，然后在此基础上可以衍生面向不同细分市场和领域的型号，并且在型号的基础上，实现面向不同企业应用的产品配置/定制和交付；这里以牵引车为例，刚开始将牵引车划分为柴油发动机和新能源两个大的平台，但是经过讨论，发现这样太粗了，因为牵引车按照功率不同，底盘架构和动力传递系统设计是有很大差异的，因此针对柴油发动机系列，再次细分了重型车、准重型车、中型车和轻型车四个大平台，但是是否进一步细化平台时，大家争论比较大，有人建议用型号，也就是在这里衍生出了“大平台”和“小平台”的概念，当决策思路不一样，针对平台的划分就会出现差异的结果——其实最终完美体育WM的确按照型号来梳理了车型，并且在此基础上进一步整理了面向不同细分市场的标准配置(参考车辆用途、工况特征、客户构成、车辆收入、核心诉求点、产品需求6大维度进行分析) 这个项目在推广时，其实也遇到了很大的挫折，各种型号衍生和产品定制出现了失控，边界也模糊了，企业也没有感觉到平台共享技术和模块带来的多大的优势；所以这么几年来，我也多次复盘问题的原因，也和一些专家探讨过问题：企业明明在这块投入了很对还推广不是很顺利，那么对于大量中小企业，是不是更没有迈入平台的机会了？ 直到我在一家企业完成将航空航天的构型管理思想向装备制造的迁移，并且为了保证常规装备设计的灵活性，也融入了大量产品工程的管理理念，后来也在一些企业咨询实施模块化管理，逐渐复盘出了一些道理：企业仅关注与平台的策划，却缺失了对平台架构的设计；或者也策划了平台架构，但是在产品开发中却没有按照策划的架构进行产品开发活动。 如下图所示，这是一个我汇总多个不同版本的技术开发、项目开发、产品开发和平台开发的关系架构图，完美体育WM可以通过几个维度推导落地的过程： 产品平台的建设和落地并不是一蹴而就的过程：几乎没有企业一开始就能完全策划好平台，并且针对不同细分市场和领域都进行了充分的调研和需求分析，然后在实现产品的架构上进行了充分的设计；随着产品推向市场，在应用过程中收集更多有价值的功能方案，产品平台必须有一个持续完善的过程；因此在产品开发中，必须有一个面向客户或者需求定制的通道，可以持续接收需求，并在产品平台上完善，支撑面向客户的配置或定制，或将在项目开发中的通用模块，按照一定的管理流程进行升级，更新到产品平台中； 不管是定制项目开发，或者单产品开发，都必须基于统一的平台架构：这一点很容易被忽略，认为平台开发是企业平台部门的事情，其实是一种共同协作的PDCA，项目开发和产品开发可基于平台快速配置和衍生，一个好的平台是支持灵活的配置和衍生管理，此时很容易保证结构的一致性，但是当平台无法满足要求时，针对特定场合定制很容易出现管理失控，这样定制的模块就无法直接被在此循环重用，或者只有被在此萃取和提炼后，才能继续进入产品或者平台中； 定制开发产品的新模块最好经过产品的再次验证再决策是否进入平台：虽然企业的产品开发和交付都是围绕着核心技术进行开展，但在激烈的市场竞争环境下，不排除提供了超出平台架构能力的定制开发；因此若存在定制模块，一定要有一个验证期，验证新开发模块是否被其他客户或者市场重用，只有重用度高的模块才能逐步被升级到平台中(面向大批量定制，这里提供的是一种更灵活的模式，不是必须在平台中完善后才能支撑产品配置，而是随着配置的增长和重用动态优化平台架构和模块)；为了支撑这种循序渐进的架构，在策划业务逻辑和平台时，必须定义非平台中的功能和模块的重用逻辑(即游离模块)，同时必须对平台中的模块，以及非平台中的模块重用过程进行监控； 技术平台的构建必须与产品平台保持一致的架构策略：按照平台的概念，其实是基于共性技术衍生出面向不同需求的产品解决方案，因此技术开发只有和平台保持一致的架构策略，才能最便捷的路径实现技术开发向平台开发的技术迁移；若是技术开发缺少一个整体策划和布局，那么在迁移时和重用时，就需要更多的迁移周期和成本(对技术迁移到产品上的影响范围和模块进行评估)；当然技术存在更多预研的创新，很多企业因此也担心这种规则会阻碍企业的创新，针对这方面我也查询了很多国内外的数据，有序的创新方法实际必不确定的创新有更大的价值，常见的创新管理方法QFD和TRIZ等，都非常重视对架构的策划，并基于架构的模块实现内驱和接口改善产品的创新；因此在技术实现上，若产品的架构无法满足要求时，技术开发可以创建新的架构，等技术验证成熟后再评估向平台迁移的可行性，或者创建新的平台——也就是说，技术架构是产品架构的前哨； 企业的技术开发也需要分层管理：针对产品开发需要分层，已经在很多企业得到认同，但针对技术开发的分层在很多企业却没有得到重视；不管按照红海战略、蓝海战略等什么战略，企业将产品开发与技术开发分离，实际上是希望部分研发人员能更专注于技术的探索和预研，更多面向企业的战略和未来的市场目标，这和产品/交付管理还是存在差异时；面向技术预研，企业需要根据竞争策略识别短板或优势，有目的性的突破和成长，此时技术层和技术树的构建就非常重要，就像打仗一样，必须有一定战略的布局和出击，例如从传统能源发动机到氢能发动机的布局中，企业就需要了解氢能动力实现路径的所有关键技术，评估自研、协同开发或外购等，提前进行专利布局，或者传动发动机热效的提升，可能本身发动机架构无法改变，但针对底层材料的突破也许会有提升，那么技术创新实际就在材料研发；所以只有经过深思熟虑的技术分层分析，才能进行更完整的布局和突击。 一个业务架构的完整实现就像平台的构建一样，也是一个循序渐进的过程，那么有没有更简易的探索手段呢？其实是有的，以下步骤可以适应大部分企业的开发管理过程： 建立企业级的产品平台开发联合团队：产品开发跨部门联合团队面向产品的生命周期管理和架构管理，这是启动企业产品平台化开发的第一步；团队必须是核心的产品管理人员和架构师(很多企业喜欢将一些助理，或者非专家人员安排处理这些非救火的事情)，除非企业的核心开发人员都忙着救火而没有时间进行面向未来的改善； 从小范围的试点开始建立企业进行改善的决心：从传统的产品开发模式到产品开发是一种创新，开发和管理思路与传统方式有比较大的差异，即使企业再有信息也不要忽略过程中可能遇到的阻力，学习党和政府改革开放的措施，先建立特区，从试点开始逐步推进，及时纠偏和总结经验，然后再持续开放；平台开发也是如此，先从实现开始，试点推广好了，会建立明显的对比，会吸引更多的产品逐步向平台开发迁移； 找一个企业认为比较成熟的平台产品，定义平台的架构，即组成产品的功能模块，在分解功能模块的时候，可以进行分层，包括系统层、子系统层、子子系统层等，具体拆分逻辑可参考《关于生命周期模块化定义的规则说明》，定义完成后，肯定还存在不完美的地方，别追求完美，那就按照这次架构进行产品开发，在产品开发中完善； 确保产品开发必须按照这个结构开发：这个步骤很难，很多时候出现问题时，大家的第一意识不是是修复完善规则，而是尝试辟蹊径逃过规则，其实当规则开始破防时，失控也就在路上；在经历好几个项目上，前期都有大量的投入，结果都是倒在这一步上，尤其是公司的高层发话，不能影响工程师对产品的交付，或者直接责问是否对交期影响负责——这里忽视了一点，任何变革都是有阵痛的，只要改变都有可能遇到阻力，哪怕完美体育WM明知道未来是光明(影响短期利益也不行) 对策划的平台和交付的模式使用情况进行持续的监控：因为完美体育WM知道平台和架构的实现是一个持续的过程，企业的平台文化也需要持续培训和导航去深入，支撑平台运维的管理人员也有一个成长过程；因此在平台开发的过程中，需要同步提供一个监控的渠道和方式，监控的指标包括几个方面： 产品开发或项目开发时，对平台的模块使用率：有企业说自己的零件重用率很高，但这个没有多大实际意义，因为零件层的变化组合的状况更多，合理的建议是模块使用率，这才是促进模块化推广的重要手段； 平台中模块的重用率：对平台中已经存在的模块进行分析，识别使用率的及时移除，不进对平台进行瘦身，也是保证平台新陈代谢的重要手段； 非平台游离模块的重用率：平台不阻止面向需求时的功能定制，这也是大批量定制的核心；那么在此过程中就需要监控新增模块的重用度，及时将重用度高的模块更新到产品平台中； 接收建议和包容变化：在平台推进过程中，因为要覆盖生命周期范围，因此在架构设计和业务规则定义时，难免有考虑不周的地方，因此要广开言路，吸收执行过程中的意见反馈，但是要认证甄选合理的建议进行改善，也就是开放严谨； 团队的持续学习和提升：改善是无止境的，工欲善其事，必先利其器，这里的“器”就是方法和工具，因此必须建立学习型组织，不仅加强内部学习，更需要向外部组织学习，广泛吸收不同渠道的方法和思路武装自己，去开拓企业的产品战略和目标。 关于生命周期模块化定义的规则说明 上一篇关于“平台架构设计和模块化设计的基本原则”的文章，得到很多人的关注，特别感谢认可；但是也有人感觉后面针对模块划分规则有点匆匆收尾，因此给我留言；的确有点抱歉，当时的确是有点困了，就没有细致的展开，因此在这里进行补充。 什么是生命周期模块？ 在模块化成熟度管理中，的确提出了一个“生命周期模块”的概念，也就是说定义的模块是面向产品开发的生命周期，而不仅仅是设计阶段，那么从设计向工艺制造转换呢？若是不能保持模块的独立性，就无法确保信息的有效传递，因此在考虑模块化过程中，随着成熟度的增加，就需要逐步提升到生命周期模块，这样才能充分发挥模块的价值；如图所示，在基于生命周期模块开发时，就可以承载产品开发信息从需求向后传递，同时也可以建立交付产品服务运维失效与产品开发的闭环，因为数据维度是一致的，因此可以确保生命周期的不同业务是针对同一模块展开的，规避了非模块因素造成的影响。 什么是“分离面”以及作用？ 在探讨生命周期模块时，有一个概念是“分离面”例如设计与工艺制造的分离面，或者设计工艺运维模块的分离面；定义分离面的主要原因，企业很难定义唯一的结构支撑产品开发生命周期的所有业务，因此通过多视图功能来满足不同的场景，例如设计视图BOM、制造视图、成本视图、质量视图等，不同视图会有不同的顶层结构，来满足不同的业务场景，即使同一视图，例如制造视图，A、B工厂制造路线不同，也完全有可能是不同的BOM结构和层级构造。针对模块的子项也无法保证不同视图完全一致，例如设计要求更加详尽，但工艺需要真实表达工艺构成，那么保持不变的，基于模块的“中间层”，就是所谓的“分离面”，在分离面之上，不同视图可以有不同的结构，分离面之下也可以有不同的结构，这样分离面就可以沿着“分离面”实现生命周期传递。 生命周期模块是产品正向开发，准守开发体系的基本功；包括在讨论MBSE时，其实离不开上述要求同样的逻辑，才能展开MBSE的工作(生命周期模块化是开展MBSE的基础)。 回归正题，那么模块定义的规则，如何思考呢？这里进行更详细的说明，如下： 独立性原则：模块的选择、替换、生产和制造相对独立，接口耦合尽量少 模块的定义时，常见的逻辑是“低耦合，高内聚”；低耦合是指模块或组件之间的关联性较弱，彼此之间的依赖性较小。低耦合的模块或组件，具有较好的可重用性、可维护性和可扩展性，能够实现模块化的开发和组装；高内聚是指模块或组件内部的元素相互之间紧密关联、密切配合，完成单一的、具体的任务。高内聚的模块或组件，具有较好的功能独立性，易于维护和复用；因为模块之间的接口是必须的，但在模块划分时，尽量规范不同模块之间的接口，甚至可以形成分析模板，这样不管是分析模块的影响关系，实现参数有效传递，或者进行失效分析，或者进行选配逻辑分析，或者变更受影响对象分析时，都非常的重要。 粒度适中原则：模块的粒度和数量必须控制在合理范围内，但可逐步细化 若按照模块化进行产品开发，那么模块本身就会承载大量的管理诉求，例如按照产品工程，或者IPD开发，在计划阶段，需要策划早期BOM、分解需求和关联、质量目标、成本目标等，那么要是模块划分的过细，就会导致概念和计划阶段的策划工作过多，但实际这个阶段很多时候可能做不到那么详细，就会造成维度不一致的管理偏差，例如早期BOM策划到模块层级，但成本目标仅能分解到子系统层级； 在划分模块时，完美体育WM建议企业可以先从大的功能模块开始，随着应用成熟度的增加，再逐步按需细化模块层级。 重用性原则：通过将更多模块由客户定制选项升为备用选项提前开发，增加重用和效率 从传统产品开发模式转型到模块化开发模式，首要目的就是通过优先的模块组合，最大化的满足客户对产品不同配置需求，因此在模块策划中，需要尽量识别功能模块中的可变部分和不变部分，然后进一步对功能拆分；简单的例子就是硬件上安装软件实现某一功能，软件经常升级，但硬件一般确定后很少变动，那就在策划时分开；我在企业也遇到过一个案例，就是控制柜，箱体基本一致，但是箱体面板会随客户对内部安装模块差异导致开孔和按钮位置差异，那么在箱体定义时，也进行了分离，除前端面板的箱体是一个模块，箱体的面板是一个模块。 唯一性原则：针对特定产品，模块仅唯一定义，包括左右件也属于不同模块 这个原则刚开始我是没有关注的，尤其是在进行部分产品开发时，里面存在重复性的功能和模块，常见如飞机的左右发动机、汽车的轮子、风力发电机的叶轮和叶片，发动起气缸中的活塞等；其实使用完全一样的零部件进行装配，那么这里为什么还要唯一性呢？要想理解，完美体育WM还必须按照生命周期视角查看，设计结果一样，但是在集成测试时，不代表测试一个就代表其他相同的就OK了，或者服务运维时，必须清晰表达相同的设计到底哪一个失效或有问题，此时若采用模块唯一性原则的就可以快速识别，但是若像风机，直接写数量3，就无法清晰准确的定位，这是理解模块唯一性原则的一种常见视角——按照这种策略，一般在一个产品中，所有的系统和模块的数量都是1. 设计分离面与工艺分离面一致原则：模块划分需要考虑设计和工艺的独立与协同 分离面的原则已经在前面说明了，目标就是为了设计与工艺的协同，也就是常见的DFA的理念，基于分离面，设计团队和工艺团队在产品概念和计划阶段就可以异步并行开发；当然分离面的定义时，也需要考虑第十条原则。 单级分层原则：模块不能嵌套使用，这样可简化配置和有效性管理 在按照模块化的理念进行管理时，模块之下是不允许再存在模块的，这也是为了简化管理的复杂度，若是模块下存在模块，完美体育WM构思一种场景配置管理，那么如何重复的表达选配关系呢？可能出出现交叉的死循环；若是在实际的策划中，出现一个更大的模块下嵌套了一个小的模块，那只能说明要么被嵌套的模块小了，要么是嵌套子模块的模块太大了；很多企业针对这块的理解误区是CBB，很多企业在管理中，是允许大的CBB下引用小的CBB，但从模块化的管理理念中，CBB最大不能超过模块的划分，否则就会降低构造的灵活性。 “只加”原则：指模块可以像搭积木一样调整，满足客户差异配置需求(大批量定制) 这里的“只加”并不是说只能添加模块，而是只能添加或者删减模块实现不同客户需求的个性化需求的配置；和传统的产品开发方法相比，例如BOM上的模块不满足需求时，常见的方法是仅修改差异的模块即可，但是在模块化的管理理念和方法中，实际是创建一个新的模块——新的模块和原来的模块遵守一致的架构和接口；当然新增加的模块也会重新进入的模块的配置库中，支撑后续更多业务的选项和配置；在业务推广时，很多工程师很难理解，为什么明明就是仅换一个零件就可以解决的事情，为什么需要从模块层级增加模块呢？其实这就是模块化开发的一种持续更新模块的一种措施和方法；但这也不是说模块的方案可不限制的增加，增加模块数量会增加选项的复杂性，因此也需要进行控制。 广义原则：模块是一个组建的逻辑组合，同时可包含需求、功能、设计、工艺、制造和检验数据 生命周期模块承载更多信息，因此在产品开发时，更多给抽象成为一个“管理模块”的载体，完美体育WM在产品开发中设计交付的模块，一般称呼为模块的“实例”，即当前模块的一种解决方案，工艺文件也是针对这种解决方案的工艺实现描述；因此这里就可以有第二种方案和第三种方案，每一种方案也都有完整的数据集，按照这种思路理解模块，就明白生命周期模块如何承载生命周期的信息。 以产品坐标系为参考坐标系原则：基于产品，建立唯一的方向、位置主坐标系…

限额设计是控制工程造价的主要技术手段，在工程设计中投资分解和工程量控制是实现限额设计的有效途径和主要方式。限额设计也是EPC项目管理中的一项重要环节，一种重要举措。在整个设计流程中，将设计工程技术人员和经济技术人员密切联系，以实现科技水平和经济效益的统一。要做好EPC项目的限额设计，需要注意以下五点： （1）提前介入，超前谋划 在工程总承包项目中总包单位一定要摒弃“等、靠、要”的思想，要超前谋划，组织设计、方案选定、积极和业主单位对接、明晰项目使用要求及设计意图、减少后续图纸变更。 （2）角色转变，改变传统设计思维 EPC项目模式打破了传统的建设思维，设计、采购、施工由工程总承包方统筹完成。EPC项目中参建施工方和设计方均要进行角色转变。EPC项目中的设计工作不是以高端、新颖为目标，而不考虑成本、造价，不考虑总包方的利润诉求；不能忽略设计优化在EPC项目中的必要性及重要性。EPC项目中的施工方不能按照传统思维来管理项目，不能坐等设计图纸出来后就照图施工。设计、采购、施工各方应加强协调沟通，转变观念，将工作的重点放在造价和成本指标方面。即满足业主的使用需求，又能有效控制预算。 （3）限额设计要有全局观念 限额设计技术指标分解到各专业，导致工程设计人员只注重实现本专业的限制技术指标，在工程设计时缺乏全局观点。而防止此类情形出现的最有效方法是提高经济技术人员的参与性。要使经济技术人员更加重视施工图纸的费用测算，从方案选定阶段就予以全面重视，对设计方案、材料设备的选型做好总体分析。 （4）做好施工方案比选 施工技术方法是施工生产中的根本性纲领，施工方法的合理选用直接关系到项目是否能够提高质量、减少成本、增加项目经济效益和社会效益。在施工之前，对建筑方案进行技术分析与经济比选，以选择最佳方案，在确保方案可行、质量可靠的基础上,降低施工难度,提高施工效益。同时，与业主多沟通交流，以科学、合理为原则，从安全及业主单位降本增效的角度出发,征得业主认可。 （5）推行限额设计的实施方法，“技术”与“经济”紧密配合 在传统项目中，工程设计人员和经济技术管理工作之间没有紧密联系，工程设计技术人员只关注工程设计速度、技术和产值，而不重视工程设计中的费用管理和经济技术分析。而经济技术管理人员则只是按照工程的设计图纸进行事后核算，并没有积极地参与设计与施工全环节。因此进行限额设计，首先需要上述两类人员统一思想认识，加强“技术”与“经济”紧密结合。工程设计技术人员在投标阶段重视方法选用，在施工阶段严格控制图纸预算，进一步强化设计变更管理，以形成动态管理意识。经济技术管理人员要从企业经营角度参加工程设计阶段的全过程管理工作，为工程设计技术人员提出相关的经济指标，并正确论证节约资金的技术方法，使工程概算资金准确合理，以实现有效控制资金、实现最大限额设计的目的。

导读：企业经营的本质就是为客户提供产品，产品力的高低决定了企业的核心竞争力。在激烈的市场竞争环境下，时间就是金钱，一项优秀的产品越早上市，越能够帮助企业占领市场，确立行业领导地位，获取更大利润。   2006年，华为公司在无线BTS3012基站设备的研发过程中，采用IPD研发管理体系，对研发项目的进度、成本、质量进行有效的管理，并取得了进度偏差4%，相比上一代产品成本降低40%，质量得分95%的好成绩。新产品每提前一天上市，就为华为多带来300万利润，产品推出10年间为华为带来30亿美元营收、5亿美元利润；其PDT研发团队基于IPD流程和项目管理，创造性地完成“不可能完成的任务”，助力华为无线成为行业领导者。 从上面的例子可以看出，IPD流程和项目管理是华为研发的制胜法宝，目前，国内大量制造业企业也意识到研发管理的重要性，纷纷采用了项目管理方法管理研发过程，但有相当数量的研发项目并没有给企业带来预期效益。 以项目进度控制为例，虽然在立项阶段定义了项目计划，但到项目执行时，总会因为种种原因导致项目延期，真正能够按期完成的研发项目屈指可数。为了解决这个问题，很多企业也尝试使用PLM/OA/移动应用等手段来改善研发管理的质量、提高信息沟通的效率，但往往应用效果不尽人意。通过PLM系统的项目管理虽然能够实时地了解项目延期的情况，但延期已经发生，根本问题并未得到解决。 研发项目管理的困境 1 缺乏有所为、有所不为的产品战略 据国际知名研发管理咨询公司PRTM（IPD研发管理体系的最早提出者）的统计数据显示：在R&D项目中，约有 40% 在技术上未能最终完成；而获得技术上成功的项目中，约有45%的项目没有对产品进行开发；已经商品化的项目，约有60%不能在经济上获利。 在IPD的管理思想中，产品研发的终极目标是商业成功，企业在产品研发时，必须要考虑研发资源的投入产出比。但是大量制造业企业缺乏产品战略规划和严谨的研发立项管理，营销部门掌握着企业绝对的话语权，只从部门或个人的销售业绩视角看待问题，绑架了企业产品发展的战略方向，最终导致的结果就是研发部门看起来非常忙，但只有少数产品能够给企业带来主要的经济价值。 2 缺乏研发管道控制， 以有限资源去挑战无限产能 对任何企业来说，研发人力资源都是有限的，大量的需求导入到研发部门，在定义项目计划的过程中，未从多项目组合管理的视角考虑资源平衡，以无限产能的假设安排项目时间计划，最终导致人力资源供给不上，计划跟不上变化，即便使用了相关信息化管理系统，仍旧导致项目延期，虽然能通过信息化系统在第一时间获得项目延期的信息，但延期的事实已经发生，没有解决根本问题。 3 未采用矩阵式管理模式， 各部门协作困难 虽然企业也提出了项目管理的理念，但并未按照IPD所倡导的矩阵式管理思想组建项目团队，很多企业仍以管理职能部门和例行工作的方式来管理项目，指派的所谓的项目经理其实是产品负责人或系统工程师，只对产品技术进行总负责，项目管理的范围难以超出部门范围。 而当产品研发进行到工程样机、小批试制等阶段时，必须让采购、生产、质量等部门参与甚至是主导工作，这种情况下只能在职能部门内起作用的项目经理，无法统筹指挥、监督和考核其他部门的相关人员，仅起到沟通、协调的作用。在部门墙的壁垒下，各部门人员只面向本部门负责，不对项目负责，无法实现良好的E2E流程对接，项目流程执行不顺畅，导致进度大概率会滞后。 如何利用PLM辅助控制项目进度 1 通过PLM管理产品投资组合过程， 聚焦研发资源投入 产品研发本质上是一种投资行为，任正非2012年在听取网络能源产品线的汇报时指出：“不赚钱的产品就关闭压缩。我不会投资非战略性的产品，除非你们的滚动投入能够交出高额的利润！” 很多企业只有营销部门，没有市场管理部门；而对于产品的投资，选择合适的目标市场，准确把握客户痛点，满足客户需求，才能获得最大利润。MM（市场管理）方法论能够帮助企业对市场走势、竞争态势客户需求进行分析，建立合理的市场细分规则，定义基于商业投资角度的产品上市顺序计划（产品路标），进而围绕产品路标，整合研发、营销、生产等各领域资源进行投入，确保产品上市，获得商业成功。 在市场管理流程中，主要通过SP/BP/Charter流程实现产品规划和立项审批的过程，分析这些流程的特点可以看出，企业实际执行的工作过程均遵守了项目管理的方法，即不管是SP/BP/Charter流程，还是产品研发流程，都可以通过PLM的项目管理工具对其流程进行管控： 利用PLM系统，辅助企业实现SP/BP/Charter流程管理，输出符合企业投资战略的产品路标规划，才能有效地减少低价值的研发项目数量，进而释放研发资源，降低项目进度延期的可能性。 2 利用PLM提前做好资源规划， 实现研发管道控制 研发资源的核心是人力资源，为了避免项目进度延期，应在项目规划阶段根据未来人力资源的使用情况进行合理的计划安排。考虑到绝大多数企业都会存在多个项目开展的情况，因此在根据未来的人力资源安排项目计划时，不能单纯只考虑一个项目的情况，必须综合多个在研项目，根据项目优先级、人力资源基线、能力基线安排项目计划，实现研发管道控制，这是减少项目延期的前提条件。 如果按照无限产能的方式安排项目计划，必然会导致多个项目之间的人力资源冲突，不可避免的出现项目延期，这时候即便通过PLM向管理者通过甘特图、项目统计汇总等手段展示延期结果，也无法改变项目已经延期的结果。 在不借助IT手段的前提下实现研发管道控制是非常困难的，需要人工计算人力资源投入计划、人力资源基线和能力基线，而且是随着时间的推移，项目的优先级可能因市场、客户等各种外部因素而进行调整，依靠人工统计分析，即不及时、也不准确。因此，应充分利用PLM系统在研发管道控制方面所提供的数据统计分析优势，辅助企业更加合理的安排人力资源计划。 上图是一个典型的人力资源基线数据分析报表，当需要针对某个新项目进行工作任务的资源分配，以便形成项目计划时，可从报表中非常直观地了解到未来时间里资源被占用的情况。除此之外，还能预测企业研发资源超出现有资源总和的时间段；在什么项目上投入资源的比例较高；同时还为HR提供了资源需求的参考数据，以便HR能够通过招聘、人员培养、购买外部研发能力等手段为研发部门提供人力资源支撑。 3 利用PLM支撑矩阵式研发管理团队， 提高团队协作能力 产品研发从来不是研发部门自己能够独立完成的工作。在整个产品研发项目过程中，可能包括多个学科，按照IPD理论，让市场、销售、采购、制造以及财务等各个部门的人员尽早参与到项目中来，以便更好的实现并行开发，典型管理方法是采用重度矩阵式的管理方法，成立包含各部门、各学科的项目团队，以便能够更加及时的在项目团队内部进行信息的沟通和交流。 企业可以利用PLM系统支持，从沟通协调效率、信息共享效率、知识检索效率等维度提高团队协作能力。 一方面，将研发过程中产生的所有文件、数据、流程、单据存储在PLM系统中，并创建与项目任务之间的关联关系，让项目团队能够通过系统快速以项目任务维度索引信息，从而提高信息共享的效率。 另外一方面，让从属于各部门的项目成员，能够通过PLM系统快速接受项目执行过程中的各种端到端工作流，实现流程渠道，减少不必要的人为沟通和提醒。 写在 最后 产品研发项目的进度控制，受到很多因素影响，本文仅从产品规划、管道控制和研发团队协调视角进行了简述，企业还可以通过分层并行开发、技术规划、研发/生产一体化等手段改善管理流程，并通过PLM系统实现流程落地、知识管理，从而提高研发项目进度管控的能力，缩短产品上市时间，为企业打造更好的产品力，实现商业成功！

      有些企业的员工对“需求”这个词的理解没有共识，导致在产品开发交流中理解存在偏差，形成各种误解。如销售人员的视角，需求主要是未来的销量，研发人员的视角，需求主要是功能需求。对需求的概念不统一，这样团队之间就很难进行有效传递、沟通，并做出正确的决策。      其实，对于“需求”这个词，在英文中有不同的英文单词来表达，翻译成汉语都是需求。       第一个是needs，描述的是人性层面的需求，属于人类的基本欲望。马斯洛需求模型中的需求就是needs，它和交易行为无关，是作为人类的生存和发展的需求，通常是冰山以下的，需求调研通常要深挖，要挖到根上，挖到needs层面就对了。如人感觉渴了，需要喝水，这个需求就是needs。 第二个词是demands，通常是具有购买能力的客户或用户，对某种特定产品的欲望，特定产品和购买能力是对应的，她是达成交易的基础。产品作为解决客户问题和帮助客户完成任务的工具，可能要求是一个，也可能是多个，企业要搞清楚能够愿意购买并买得起的客户的数量以及他们需要多少。如需要多少人需要水来解渴，每人需要几瓶，一瓶还是十瓶，这个需求最终会构成市场的容量，这个需求就是demands。这通常就是销售人员特别关注的，未来客户量的需求。 第三个词是requirement，这个需求是对解决客户问题的工具更加具体的要求描述，如功能、性能、外观、质量等。如瓶装水是330ml的还是550ml、以及对水的品牌、瓶子造型、口味、包装等的需求。很多研发人员最希望客户能够直接给出这样对产品的需求，然而这样具体的需求描述会掩盖客户真正的needs。所以，需求调研中更重要的是探索needs以及客户对特定产品的需求产品的动机。 因此，市场调研需要包含两个方面的内容，一部分是demands，市场需求market demands，也就是市场未来的产品需求数量，和未来的产品销量相关。决定了市场空间、增长率和利润潜力。基于market demands来进行销量预测，基于销量预测，采购人员人员规划正确的存货数量，生产人员进行产能评估和规划产出，财务人员进行财务分析。销售人员填的市场需求表中的数据，很多时候只是“拍脑袋”的数据，需要进行进一步的市场分析和评估。 另外一方面就是客户对特定产品的功能、性能、可靠性等方面的诉求以及产品这些诉求的动机，这些通常是由客户或用户在完成工作、任务或生活中的麻烦、障碍产生的，也就是客户要解决的问题。这些是研发人员，特别是SE最为关注的，描述客户购买产品的动机可以用$APPEALS模型来描述。 与客户问题相对应的是产品需求，简写为PR（Product Requirement)，也就是产品需求，这个通常是由SE团队来进行分析而形成，是产品设计、开发、验证、交付的依据。相对的客户需求就是URS。 因此，看待市场需求要一分为二来看待，一个是damends，也就是未来新产品的需求量，另一个是对客户问题，也就是客户在完成其任务时，在什么场景下，遇到什么麻烦和障碍，需要得到解决，这也是研发团队设计产品的出发点。

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项目，希望能够实现施工单位主动承担起投资控制责任并起到牵头作用，设计单位（包括设计人员及概算编制人员）主动配合，集各单位所长，编制出贴合项目真实建设情况的设计概算，真正起到投资控制的作用。