随着中国建筑企业参与国际市场竞争及国家政策的推动，我国工程总承包模式发展迅速，已逐渐成为大型建筑企业发展的方向。但总体而言，工程总承包管理模式的发展还处于积极的探讨阶段，推行过程中出现的一系列问题亟待解决。 思路决定出路 新的管理要求需要新的管理思维 工程总承包模式蕴含的多专业、多界面、多个管理对象，促使工程总承包项目必须有一个精准的项目管理策划，一个良好的开端就是成功的一半。 01 工程总承包卓越管理要求 对总承包方而言，相比传统的施工总承包，工程总承包管理拉伸了工程管理线条，企业能从项目规划、设计、采购、安装、施工、培训等更多环节获取效益，能开发更大的市场。同时工程总承包卓越管理对建筑企业也提出了新的要求。 1. 管理目标要求更高 工程总承包的管理目标在满足业主和总承包方设立的质量目标、费用目标、时间目标和效益目标的基础上，更强调员工能力增值目标和社会价值目标的最大化。 2. 对员工自我管理 和团队价值创造要求更高 工程总承包模式是建筑行业的新模式，同所有的管理组织一样，也需要卓越的管理者。卓越的管理者应具备对自我管理的关注和实践、善于支配时间、重视贡献、重视协调、发挥人的长处和有效的决策等六大必备要素，通过不懈努力，实现设计、采购、施工的高度融合，发挥项目每个线条、每位员工的最大能动性，团队合作，为项目创造最大价值。 3. 对项目协调要求更高 工程总承包不是一般意义上的设计、采购和施工环节的简单融合，它有自己独特的管理内涵，需要重视协调和整合能力，对市场资源的掌握以及对各专业分包的管理，协调设计、采购、施工在项目前期的深度融合，协调接口管理等。 02 工程总承包卓越管理方略 我国工程总承包管理模式的发展还处于积极的探索阶段，对建筑企业也提出了新的要求，“新的管理要求需要新的管理思维”，所谓思维也罢，理念也罢，实际上是一种管理方略。建筑企业高质量发展需要建立适应工程总承包发展的卓越管理方略，主要包括以下七个方面。 1. 体系先行的管理理念 工程总承包是一种新型的工程建设管理模式，其管理内容和特点决定了必须要建立适应其管理要求的管理体系。 在卓越工程总承包管理模式中，需要建立一个完整的工程总承包项目管理体系和十一个线条管理体系，建立八个管理团队及专业化项目部。项目管理体系实行总承包项目经理部与专业项目部分离的管理模式，十一个线条管理体系是：设计管理体系、采购管理体系、建造管理体系、商务管理体系、资金管理体系、信息化管理体系、进度管理体系、质量管理体系、安全管理体系、协调管理体系、试运行管理体系；八个管理团队是：市场营销管理团队、设计控概管理团队、采购招标管理团队、计划工筹管理团队、施工方案管理团队、商务合约管理团队、财务资金管理团队及协调组织管理团队；专业化项目部根据项目具体管理内容设置，如：土建项目部、机电项目部、钢结构项目部等。 2. 设计为主的管理理念 “设计是龙头、建造是核心”是工程总承包项目管理者需要具备的最基本的理念。 ● 限额设计有利于控制投资。工程总承包项目克服传统管理接口多、协调难、管理周期长的缺点，使设计、设备、施工等无缝接入，从项目管理程序有利于业主进行投资控制；其次设计阶段决定了项目的投资水平，业内普遍认同的观点是：项目产品成本的80%～90%是约束性成本，在设计阶段就已经确定，在工程实施阶段影响项目投资的比例在10%～20%，因此设计水平就代表了项目的投资水平。 ● 设计标准保障了项目质量。在设计阶段需要考虑业主标准、综合投资，又要统筹考虑自身的施工能力，从工艺优化、设备选型、材料选择等进行方案优化，从技术层面保证了项目质量。尤其在以工艺技术为核心的大型项目中，项目的建设质量取决于设计质量。 ● 设计方案可以最大限度缩短工期。在设计阶段，从工期角度进行方案的优化比选，根据工艺水平选择结构形式、施工方法，缩短项目施工工期；在设计阶段，通过各专业联动提前考虑设备的单机调试和联动调试，缩短试运行时间；设计工作贯穿于项目建设的全过程，通过前期和采购、施工的深度交叉，减少设计失误，在确保各阶段合理工期的前提下缩短总体建设周期。 ● 合理设计也是总承包单位降本增效的核心。据统计，在工程总承包模式中，总承包单位效益的80～90%来自于设计阶段，施工阶段仅占5%～10%，设计水平不仅要满足履约要求，更要通过自己的资源库，从效益角度进行方案优化，实现与业主的双赢。 3. “控圆缩方”的成本管理理念 “控圆缩方”是工程企业进行成本管控和创效的一种有效方法，首创于中国建筑第五工程局。将项目的成本组成、效益来源全部清晰标识于成本管理方圆图中，成本管理外圆内方。 通过控圆缩方，可以将项目的合同造价和项目的责任成本区分开，达到价本分离目的。 4. 接口管理出效益的管理理念 工程总承包的管理过程主要就是大量接口管理的过程，就是不断协调的过程。主要包括以下方面的接口：其一是各管理环节之间的接口，如纵向管理中的设计与采购、设计与施工、设计与试运行、采购与施工等之间的工作接口；其二是同一环节的接口，如总包设计与分包设计的接口、施工总包与分包的接口、机电专业各设备间的接口；其三是各专业间的接口，如土建与机电、机电与装修等；组织管理中的场地接口、时间接口等诸多内容。 只有充分识别接口和界面关系，明确界面标准，做好对接，项目管理才能有序推进，否则容易出现延误、返工等情况，影响项目履约和效益。 5. 建立分包人为伙伴关系的管理理念 在工程总承包的实施过程中，会有设计分包、土建专业分包、机电专业分包、劳务分包、设备供应商、材料供应商、专业运维商和其他专业分包商，专业分包人数量庞大，大量的工作是分包人在具体负责，对分包人的管理就是工程总承包的基本管理，总包和分包的关系是唇齿相依的关系，成也分包、败也分包，分包管理是企业的核心竞争力。 在一些优秀的建筑企业和工程总承包项目中，总包和分包的关系是建立在合同为基础的战略伙伴关系。战略伙伴关系能够使总包与分包更紧密地联合在一起，能够使分包进行较为长期的资源配备和战略安排，并将实质性地改变总包的资源获得模式和成本，增加总包在市场中竞争优势。分包位于项目管理的下游，与总包建立伙伴关系也是分包在竞争激烈市场中稳固生存空间的迫切需要，因此可以规划共同利益框架，共同开拓市场，共享利润，共担分险，最终以较小的经济成本获取更高的收益。 6. 注重工程筹划的管理理念 工程总承包模式蕴含的多专业、多界面、多个管理对象，促使工程总承包项目必须有一个精准的项目管理策划，一个良好的开端就是成功的一半。 工程筹划是对工程项目的整体策划，涉及项目管理框架、项目经理和总工等主要人员、专业分包方案、技术方案、商务目标、主要材料设备的采购、人力资源调配等方面内容，涉及项目管理的各个方面，同时项目已经中标，正式进入合同履约期，需要快速决策，避免延误时机，因此工程筹划需要“精准、有效、全方位”，强调企业主管牵头、专家参与、全部门参加的有效筹划，保障筹划能及时落地。 7. 协调增效的管理理念 重视协调是一个卓越管理者必备的基本素质，对工程总承包项目而言，协调能力就是管理能力。工程总承包的管理就是不间断的协调过程，通过协调有效整合项目资源，提高项目综合履约能力，降低项目运行成本，增加项目收益。 项目协调一般遵循分包服从总包安排、部门服从项目总体、进度和成本服从安全和质量、局部服从整体的原则。在不同阶段有不同的协调内容，如项目起始阶段侧重于部门工作、专业内容的协调，以设计为主导部门；施工阶段侧重于各部门、各专业对施工现场的保障协调，以施工为核心；试运行阶段侧重于对机电专业、对运行系统的管理和对业主的培训方面进行协调。…

如果各阶段的设计工作都在全过程工程咨询单位或者所组成的联合体承包范围，项目在设计阶段的投资控制措施你能想到多少呢？ 这个时候，相信会有人罗列出大部分切实可行的方法，比如：严格把控标准化设计、鼓励设计人员进行设计创新、建立投资控制奖励机制、建立设计成果校审制度、严把设计方案的选择与审核、建立标准化设计管理制度、适当增加可行性研究报告的深度……等等 不得不承认以上这些都是设计阶段投资控制的主要措施，对于全过程工程咨询单位而言也是一项必要的内部控制机制。但我其实想跟大家聊一聊另外两种方法：设计方案的内部竞选和目标投资成本的限额设计。今天我们先说说设计方案的内部竞选。 设计方案内部竞选多发生在项目的方案设计阶段，方案设计一直以来都是作为编制项目投资估算的重要依据之一，假设估算编制不足，项目在后续的实施阶段将会带来很多实际问题。 一个常见的例子就是除去投资方项目资金运作不当的因素后的“烂尾楼”。或者是在初步设计、施工图设计阶段，为了满足项目的投资需要，不得不缩减一些建筑使用功能，原本可以乘坐电梯的，现在只能自己爬楼梯了。这一切都在表明一个现实问题：项目干到一半就没钱了！这绝非投资方真正想要看到的结果。 我自己就亲身经历过这样一个工业项目。该项目主要是建造一条生产、加工草果及其他农副产品的生产线（含加工厂房、办公楼等建筑的建设），采用的技术是微波烘烤工艺，建设目标为一年生产加工鲜草果3000吨，但因在方案设计阶段投资限额，加之对草果这种农副产品有足够的时间，试验了解其特性，最后导致烘烤时间不足，年生产能力远不足预期。最后，投资单位不得不再次追加投资，经多次技改后，勉强满足投资方的要求。不得不说，无论是对于投资单位还是总包单位都这是一件极为悲催的事。 由此看来，在方案设计阶段，其设计成果的质量非常重要，尤其是对于一项新工艺、新技术而言，更应重点对待。因为它将会成为影响项目成功的一大重要性因素。 好的设计方案，不但能够在使用功能上和资金编制上满足投资方的要求，而且还要在项目的人文理念及城市区域或整体规划上得到地方政府的极大认可。它决定了整个项目建设期80%甚至更高的投资额，这符合20/80原则。 通常情况下，绝大多数投资方在方案设计阶段都会采用多方案比选。他们会同时邀请多家设计单位共同编制各自的设计方案，在规定的时间、确定的地点进行评审，从中选取一个认为质量最优、性价比最高的作为项目的最终实施方案。 这其实就是多方案竞选的过程！那么，在全过程工程咨询项目管理模式下，又该怎么进行内部的多方案比选呢？ 我们先看一个例子。比如作为总咨询师的你面对一个旧城更新改建安置房项目，需要建设一个三层地下室，在施工前你得事先考虑深基坑支护的方式。 于是你组织项目的设计团队，开展深基坑设计方案的论证。你让设计团队出具了两套方案进行比选，一套方案是基坑边坡喷锚护壁加止水帷幕支护，此方案造价为1200万，另一套方案则是内支撑结构，此方案造价约为1900万。根据地质勘察报告，位于某栋安置房下地下水位低且土质干涸，开挖土方时对四周建筑物的影响不大，于是，你决定采用第一种方案，并把你的意见汇同两种方案比选的过程和结果以书面形式向投资方进行详细汇报，经会议讨论后，投资方认可了你的意见。为此，你节约了项目投资近700万元。 我们注意到，在整个比选过程中，总咨询师起到至关重要的作用，他不仅是评审者，他还是组织者，承担了更多的建设方代理责任。 这时有人可能会问：这跟方案设计有什么关系？其实，方案设计的比选过程类似于上述基坑方案的比选，只不过阶段不同罢了。本质上并没有什么区别！ 说完什么是多方案竞选，我再来谈谈咨询单位方案设计竞选的必要性以及在我看来需要注意的几个问题。 不知道你是否经历过这样一个场景，一个设计成果好不容易弄出来，却被投资方要求修改多次却仍然通不过甚至完全被否定。同时，还被投资方狂喷，说你这样不行，那样不行？我相信任谁都无法忍受，这其实是单一方案所带来的结果，投资方没有更多可选择的空间，此时，如果你能够为投资提供多个不同的解决方案作为比选，兴许情况会有所不同。但这就要求你找到多个设计师共同来完成。 事实上，不同的设计师对于同一项目的理解和视角是不同的，设计方案的先进性、合理性取决于设计师以往的见识、理念、经验以及文化水平、学识等。 方案设计既要满足投资方的需求，还得考虑项目今后在运营阶段的商业盈利，同时还得考虑与项目周边的过渡与衔接。要达到很好的效果，满足投资方的需要，看似简单，实则并不容易。 正如上面的基坑方案比选过程一样，在你单位实力允许的前提下，同时召集几位在某一方面或几方面都比较优秀的设计师同时开展方案设计工作，哪种方案更加适合投资方的胃口，更加符合项目的特点、定位，就用哪个设计师的方案。同时，任命选中的设计师为本项目设计工作组的组长，再加以一定的激励措施，这其实就是设计方案的内部竞选过程。 内部竞选对于投资方而言，是有利的，他可以从多个不同的方案中选取一个最能体现其构想、质量较高的设计成果。但对于全过程工程咨询单位而言，则是不利的。因为要让多个设计师同时开展设计方案，是否有那么多合适的设计师先不说，单单就没有选中方案的设计师，咨询单位同样也得付出相应的薪酬，它是一项成本。需要在激励方式以及在投标报价中综合考虑到相关问题。（不同的企业有不同的实力以及成本承受限额，具体怎么激励？上哪找那么多设计师？这已经超出了本文所讨论的范畴，不再累赘） 作为对问题的一种平衡，建议投资方，如果是在方案设计前期对全过程工程咨询单位进行招标的话，招标文件中应明确要求采用多方案比选，并且在项目其他费中考虑一定费用作为方案比选的费用。这样做的目的，是为了花极小的代价，得到质量最优、性价比最高的设计成果。 以上就是我今天想要为大家所分享的全部内容，欢迎大家批评指正。这里需要说明的是，以上内容均是假设方案设计任务包括在全过程工程咨询合同内所讨论的。 文章最后，还想提醒一下投资方。如果你所要拟建的项目将要采用一项全新的工艺、全新的技术，为了便于责任的追朔，建议投资方将方案设计联同其他阶段的设计任务共同打包。这样可以尽可能地减轻或规避由于两阶段设计任务的分离，由此对投资方带来的技术或运营风险。正如我上面所经历的那个项目一样。 如果说方案设计是初步确定项目投资目标的话，那么，以下各设计阶段，全过程工程咨询单位在设计阶段将要做的投资控制任务就是目标成本投资的限额设计。将在下一节重点与大家详细聊一聊相关话题。

导读 汽车生产产量大及精益管理对制造与物流有更高的要求，而BOM数据是物流与制造管理的基石；日趋激烈的市场竞争要求企业的研发与制造在质量、时间和成本三要素上不断提升，因而对BOM管理也提出了更为严苛的要求。   一、BOM问题的背景 企业由于产品BOM问题所造成的困扰在汽车制造行业显得尤为突出，其客观原因在于汽车制造业本身的行业特性与所面临的业务环境的挑战，如：全球化市场产品多样性需求的增长导致了汽车平台、车型和配置数量的急速增加；日益提升的技术不仅大大增加了汽车零部件的数量，也增加了对零部件设计的管控难度； 汽车生产产量大及精益管理对制造与物流有更高的要求，而BOM数据是物流与制造管理的基石；日趋激烈的市场竞争要求企业的研发与制造在质量、时间和成本三要素上不断提升，因而对BOM管理也提出了更为严苛的要求。 另一方面，从企业的业务应用来看，对BOM数据的应用已渗透到企业的各个业务环节，从工程、工艺到采购/供应、制造、物流、售后和财务，以至于CAE仿真、KD件生产出口、部件深度重用和成本工程等，都对BOM管理有着不尽相同的需求，或者说，要求有不同状态及形态的BOM数据来支持各自的业务运作，而作为企业运作基础的整车BOM数据又被要求具有高度的一致性与准确性，这都增加了BOM管理的难度。 第三，企业对于BOM的管理比较难以有个标准模式，各企业基本是随业务的发展逐渐形成一套适合自身业务模式的BOM管理体系。有些企业的BOM系统已经历数十年，仍在不断改进或逐步替换升级，如通用的GPDS系统；有些则投入大量资金与资源，走了许多弯路后开发了全新的系统，如丰田的SMS。 所有这些著名厂商的BOM系统往往蕴含了其业务管理的精髓，都是由企业针对自身的业务运作模式而自行开发的，因此，至今在市场上还没有一套完整的商业化的BOM管理软件。由于产业发展过程不同，国内汽车制造商与国际著名厂商在作业环境与业务成熟度上有较大的差异，因此，国内整车制造商很难找到一个可完全复制的BOM管理的标杆模式，所以不得不在借鉴与探索中前行。 综上，BOM管理是汽车制造商一个普遍的管理难点，对于国内汽车制造业而言，更是制约了企业业务目标的达成与核心竞争力的提升。BOM管理与业务目标达成的相关度很高，业界有个较为权威的结论：BOM管理领先的汽车制造企业，较之于BOM管理不佳的企业更能够达成他们产品开发和生命周期管理的目标，从而推动产品盈利。 一般来说，前者达成目标的几率是后者的两倍，统计数据表明大致在89％对35％的量化指标。因此，国际上很多著名汽车制造商不遗余力地投入大量资源以完善与提升企业的BOM管理能力，把先进的BOM管理体系作为其市场竞争的利器。 二、BOM问题的分析与管理目标 简单地说，汽车设计与制造商在整车BOM管理上所遇到的种种问题，其根源可归结为CAD、BOM及整车物理实体三者间的匹配。即工程设计（CAX文件等）、面向不同业务目的的物料清单（BOM文件）与现场实际制造的整车实体（Physical Vehicle）这三者自身的准确度及三者间一致性的问题，如图1所示。 图1 BOM管理的问题 BOM管理所要达成的目标也可简单地归纳为3个“C”，即通用性（Commonality）、可配置性（Configuration）和完整性（Completeness）。 上述对于BOM的问题及管理目标的陈述看似简单，而实际上却涉及十分丰富的业务、管理与技术内涵，由于各个汽车制造商处在不同的企业发展阶段或有其各自的业务特点，BOM问题所造成的各种现象在每个企业的表现也是错综复杂，对于国内的汽车制造商而言，最为典型的与BOM相关的问题现象有以下几类。 (1)当企业的车型品种与产量大幅提高时，物料与零部件的规格、品种也成倍增加，作业管理的难度与成本也迅速上升，而往往随着产品销量及营业额的增加，利润率却在下降。 (2)BOM工程师不仅忙于设计与修改CAD图样，还要在Excel上编制BOM数据或稽核数模（3D等）数据向下游发放，经常要加班加点来完成对CAD与BOM间一致性的稽核，以及疲于应付由数模、工艺与BOM数据衔接上的错误所造成的各种问题。 (3)常常听到各个部门对BOM数据的抱怨，财务人员认为BOM不对，成本核不出来；生产及物流部门也认为BOM数据不对，供应商向现场错发料或不得不缺料停线；ME工程师则表示现场的部件与工程图样版本不符。 (4)主要依靠物理样车的制造来纠正设计与工艺上的缺陷，为赶进度，现场临时变更很多，以至于没有完全记录到变更管理系统之中。 (5)BOM数据分散在各个部门或系统中，有的在ERP中，有的在销售系统中，有的在各自的Excel表上，经常需要电话沟通来协调诸如颜色、可销售的配置等问题。 (6)随着企业的兼并收购，不断有其他的产品研发、生产体系以及产品型号加入，各产品BOM发布也自成体系，如何有效地整合这些全球化的资源，实现企业全球化的战略呢？BOM体系的整合从哪里入手比较有效呢？ (7)正致力于自主品牌的企业往往有更多的困扰： 我们的自主品牌刚开始，不知如何规划、部署BOM系统以满足未来业务扩张的要求，如何防止将来推倒重来，重复某些企业的错误； 我们的BOM体系已经发展了好多年，不断修补维护而问题却随着业务的发展越来越多，不知如何确定一个完善的改进与优化方案。 原先我们依靠外部合作方来进行BOM管理，而今随着合作的结束，我们不得不独立承担BOM的管理，现有的面向下游的运作多年的BOM体系如何与我们即将形成的自身的研发体系衔接？ 我们也参照一些国际上标杆企业的BOM体系，自主进行BOM管理软件的开发，投入了大量的资源，而需求与问题却越来越多，我们的技术路线是否正确？ 通过分析许多中国汽车制造企业（主要是国内自主品牌或自主生产的企业）以上这些具体的问题和现象，我们深入了解了企业对于BOM问题的各种表述与改进期望，综合我们的经验与理解，列出了如下六点企业反馈集中度最高的、认为需优先应对的BOM的问题： 完善或建立一个可支持业务发展并持续扩展的BOM管理体系； 维持BOM在整个产品生命周期中的准确性与一致性； 管理跨配置与变体（Variants）的BOM及其变更； 确立一个有一致性约束、同时可面向多种应用（或称为不同视角）的BOM数据模型体系； 保证下游能同步获得与应用BOM的发布数据，以及及时完成变更；压缩平台数量，提高部件的重用度及产品模块化程度，从而降低产品BOM的复杂度。 三、BOM解决方案的业务实践与系统设计要点 综合上述分析可以看出，BOM问题往往不是某个点上的简单问题，而是需要一个体系化的完整的方案来应对解决，这样的方案涉及企业技术、业务和管理等诸多方面的要素，需要各方同时推进才有可能取得成效。 对于如何确立一个体系化的解决方案，国际上一些著名的汽车制造商在经历了长期的业务实践后逐步形成了完整的方案与最佳实践，无论是欧美，还是日韩的厂商，虽各自具体的管理模式有所不同，但BOM管理的理念与做法在本质上很相似，这种不约而同的相似性正反映了BOM管理业务实践与解决方案的共通性，可供国内厂商借鉴参考。同时由于信息技术的发展，如轻量级3D模型、面向服务的集成架构SOA等，都为构建新型的BOM系统提供了更有效的技术手段。 1 BOM体系与方案所应考虑或包含的要素 BOM问题需要综合性的解决方案，需要考虑如下一些要素：1)产品配置，面向产品架构、涵盖销售与技术的配置；2)产品架构（或称为分组或整车功能视图）、平台化、模块化设计及零部件重用度；3)BOM数据自动采集、跨部门流转及统一的发布管理；4)BOM的变更、通知及执行管理；5)BOM数据完整性与准确性的系统验证；6)数模（3D模型等）与BOM数据的匹配与可视化验证；7)集中BOM控制模式及全球多地点研发及制造的BOM协同管理；8)企业级BOM系统规划与实施路线图，包括BOM系统的创建、改进或替换升级方案。 2 BOM系统需要覆盖时间与业务两个维度上的数据 1)时间维度的BOM包括：产品方向、产品架构、早期BOM（项目启动前用于评估的BOM数据）、不同成熟度的工程BOM、工艺BOM、SOP后的制造BOM及各类BOM数据的变更增量等；2)业务对象维度上的BOM包括：整车BOM、CADBOM、PDM中整车结构、工艺BOM、采购BOM、制造BOM、特定工厂BOM、KD散件BOM、售后备件备品BOM、重量BOM、工程样车BOM、CAE BOM、机电一体BOM和电子BOM等。 3 独立的BOM创作与发布流程 在整车开发流程中，有很多工作子任务，其中与BOM相关的工作主要有项目评估与启动、数模设计与发布、BOM数据创建与发布、CAD-BOM匹配与数字验证等。在最佳实践的BOM方案中，数模设计与BOM创建是两个相对独立的工作，其起点在于统一的整车架构与配置体系，以及零部件号的分配与发布，其终点在于BOM与数模进行匹配校验后的生产发布。基于这样的作业模式，一般都建议设置专门的、熟悉整车结构的BOM工程师来进行日常的BOM创建与维护的工作。独立的BOM创作与发布体系符合BOM业务作业的本质，具有许多优势，如何从现场BOM的角度对整车的数模状态进行校验、可以不拘泥于设计数据的形式而自由地表达下游所需的数据形态等。 图2 一个典型的业务BOM数据模型 4 基于业务BOM的管理体系 业务BOM，即所谓的Usage BOM，也就是按照部件的使用场景（验证及配置条件）来编制扁平化的BOM行。图2是一个基本的业务BOM数据模型。整个业务BOM数据存储结构及表现形式可以看成一个二维的Excel表，其中“功能结构”可以用以表达该部件的功能及分类视图编码或两者的匹配信息，“解析码/串”则是该部件在此应用场合的配置变量与逻辑表达式。 从逻辑的等价性而言，平面的业务BOM所表达的内容与一般的树状结构的CAD…

全过程工程咨询单位在项目的施工阶段，对建设工程的投资管理活动中，主要工作涉及到招标工程量清单的编制以及施工过程中工程款的支付、工程变更现场签证及索赔管理等几个方面的工作。工程变更及现场签证管理。这都是基于我们通过目标的分解在第58小节文章中所确定下来的投资管控组织架构。 工程变更及现场签证是施工单位最喜欢的工作，那是因为它能使施工单位口袋变得更加丰满，而对于建设单位和全过程工程咨询单位来说，则总是为此担惊受怕，那是因为一方面他们要面对审计，另一方面变更和签证就像是魔鬼，会慢慢吞噬他们的投资。 故而，在全过程工程咨询项目中一度被沦为在施工阶段投资管理最大的风险不可控因素，但在绝大多数情况下，在具体的工程实践当中，又往往不可避免，须重点管控。怎么管控呢？我们今天详细聊一聊。和上一篇文章一样，来点实战点的，如下文。 （一）工程变更管理 1、依据 工程变更是施工阶段费用增加的主要途径，全过程工程咨询单位必须重视工程变更的管理。工程变更的主要依据： （1）国家、行业、地主有关技术标准及质量验收规范及规定等； （2）《建设工程工程量清单计价规范》（GB50500-2013） （3）施工合同 （4）施工图纸 （5）人工、材料 、机械台班信息价及市场价 （6）施工单位投标工程量清单 （7）变更通知书及变更指示 （8）计量签证 2、工作内容 在工程施工过程中，由于各种原因，会出现工程变更和合同争执等情况。这些问题的产生，一方面是由于设计疏漏或错误，导致在施工过程中发现了设计没有考虑或考虑不周的施工项目，从而不得不补充设计或变更原设计。另一方面是由于发生了不可预见的事故，如自然或社会原因引起的停工或工期拖延等。由于工程变更所引起的工程量变化、施工索赔等，都有可能使得投资超出全过程工程咨询单位对投资管控的目标要求，故而在工程实施过程当中，需要特别重视工程变更及其价款的管理。 工程变更管理主要工作是审查工程变更资料，审查的重点包括但不限于变更理由是否充分、变更程序是否合法合规、变更估价是否准确。 此外，对于全过程工程咨询单位所提出的工程变更，需要以函件的形式下发至施工单位；对于施工单位所提出的工程变更，若不影响使用功能的情况下，需得到全过程工程咨询单位的同意和许可，所有的工程变更经全过程工程咨询各专业设计咨询师的技术审核、总咨询师同意后，向施工单位发出。 全过程工程咨询单位在进行工程变更管理过程中，须建立严格的审批制度和审批程序，其目的在于防止任意提高设计标准、改变工程规模，增加工程投资，切实把投资控制在目标范围内。 3、工作方法 全过程工程咨询单位进行工程变更管理的主要工作有以下几点： （1）审查变更理由是否充分 对施工单位所提出的变更申请，应严格审查变更的理由是否充分，预防施工单位利用变更增加工程量、工程造价，减少自己应承担的风险和责任。区分施工单位所提出的变更是技术变更还是经济变更，对其提出的合理降低工程造价的变更则应该积极支持。 全过程工程咨询单位自身所提出的设计变更，则应进行内部审核、评定，若因不能满足使用功能需求或在确保投资目标达到的前提下提高设计标准，可以变更。 （2）审查变更程序的合规合法性 全过程工程咨询单位应审查施工单位所提出变更程序的合规合法性，主要依据是在双方签订合同时对变更程序的约定下进行审核。如果在合同中没有约定，则应根据《建设工程价款结算暂行办法》（财建【2004】369号）文中的规定进行审查，在审查过程中主要应注意以下4个关键环节。 1）施工中发生工程变更、施工单位按照经全过程工程咨询单位出具的变更设计文件进行变更施工，其中，若是政府投资项目的重大变更，需按基本建设程序报批后方可施工。 2）在工程设计变更确定后14天内，设计变更涉及合同价款调整的，由施工单位向全过程工程咨询单位提出，经发包人审核同意后调整合同价款； 3）工程设计变更确认后14天内，如施工单位未提出变更工程价款报告，则全过程工程咨询单位可根据所掌握的资料决定是否调整合同价款和调整的具体金额。重大工程变更涉及工程价款变更报告和确认的时限由双方或三方（建设单位、全过程工程咨询单位和施工单位）共同协商确定。 4）收到变更工程价款报告的一方，应在收到之日起14天内予以确认或提出协商意见，自变更工程价款报告送达之日起14天内，对方未确认也未提出协商意见时，视为变更工程价款报告已确认。 （3）审查变更估价的准确性 在工程变更管理过程当中，全过程工程咨询单位对工程变更估价的处理应遵循以下原则： 1）合同中已有适用于变更工程的价格，按合同中已有价格变更合同价款； 2）合同中只有类似于变更工程的价格，可参照类似价格变更合同价款； 3）合同中没有适用或类似于变更工程的价格，由施工单位提出适当的价格，经全过程工程咨询单位确认后执行。 4）合同中另有约定的，按约定执行。 按照一般规定在合同中没有适用或类似于变更的价格由承包单位提出适当的变更价格，经全过程工程咨询单位造价咨询师审核，给出意见，并由总咨询师及建设单位确认后执行。 全过程工程咨询单位为了有效控制项目投资，应在施工合同专用条款中对上述条款进行补充和修改为：在合同没有适用或类似于变更的工程价格由施工单位提出适当的变更价格，经全过程工程咨询单位审核。若总包单位对全过程工程咨询单位最后确认的价格有异议，而又无法套用或无法参考相关定额时，由全过程工程咨询单位、施工单位双方共同进行市场调研，力争达成共识。对涉及金额较大的项目，由全过程工程咨询单位、施工单位等相关方共同编制补充定额，报建设单位审批后确定变更工程价款。 4、注意事宜 （1）若不能满足工程验收规范要求、不能满足使用功能需求或施工技术要求，则必须进行工程变更； （2）在满足工程验收规范要求、满足于使用功能需求和施工技术要求的前提下，尽管变更理由非常充分，如果总投资不可控，则全过程工程咨询单位也不能同意变更； （3）如果相关单位、全过程工程咨询单位审核同意变更的，则应按变更管理程序变更工程的综合单价。 5、成果性文件 （1）工程变更审批流程表 表1：工程变更审批表 （2）工程变更汇总表 表2：工程变更汇总表 （二）现场工程签证管理 1、依据 全过程工程咨询单位在进行现场签证管理时，主要的依据是： （1）国家、行业和地方政府有关规定； （2）施工合同 （3）其他专业现场资料 （4）现场变化的相关依据；…

众所周知，在我国，几乎所有的房建项目都需要经过：方案设计、初步设计和施工图设计三个阶段。而我们通常习惯于把这三个阶段统称为建设项目的“设计阶段” 每个阶段成本控制的工作程序和方法虽不尽相同，但主要环节和步骤在时间上和管理职能上的逻辑关系却是不变的，即从粗放到精细的过程。有人说：这是成本控制工作的共性，对此我深以为然。 设计阶段的成本控制是一种事先控制的方法，同时也是一种动态控制的过程。之所以这样说，是因为在设计阶段发生在施工阶段之前就要完成，但成本控制工作却做着与施工阶段相同的事，即：需要在目标值确定的前提下，定期地把实际值与计划值相比较，由此判断其行为是否偏离目标，以及偏离目标的程度，进而分析原因，采取相应的举措把实际值控制在计划值范围之内。从这个意义来说，成本控制的过程应贯穿于项目整个建设期。 全过程工程咨询单位在总咨询师的组织下，定期进行技术经济分析、造价成本分析是非常有必要的。其目的在于实际成本不要超出建设方给出的投资限额。 另外，我们也不能简单地认为在设计阶段，成本控制行为是被动的。在每个设计阶段，无论是事前、还是事中都应积极邀请建设单位参加到你的设计任务中来。否则的话，你幸苦得来的设计成果很可能会被建设方全盘否定。而这起决于你与建设单位的沟通是否通畅、是否明确了建设方真正的需要，是否及时把中间成果向建设方作为汇报…… 不要自以为是，也不要闭门造车，更不要不好意思骚扰建设方，因为建设方配合设计工作本来就是他的责任之一，尽管设计工作本来就是全过程工程咨询单位的份内工作。 那么，在设计阶段，哪些成本控制工作是全过程工程咨询单位份内的呢？ 如果不明确这点，很多人、很多事将陷入到迷茫。故而，有必要在设计工作的每一阶段，在正式开展之前就要赋予它一个清晰且准确的使命。工作任务的不清晰将会是后续一切混乱的开始，低效或无效。 项目的每个设计阶段，成本控制的主要任务其实是不同的。比如： 方案设计阶段，成本控制的任务主要是：编制项目的总造价估算，达到建设方的投资要求并得到建设方的初步认可； 初步设计阶段，成本控制的任务主要是：明确概算指标、编制项目的总概算，得到建设方的最终认可，确定建设方的投资目标。对设计的深化严格控制在估算计划值内。 施工图设计阶段，成本控制的任务主要是：完成施工图预算的编制，在充分考虑满足项目使用功能的前提下，尽量挖掘节约投资的可能性、确定项目在施工阶段的建管模式、编制招标文件，在项目的施工阶段定期进行投资计划值与实际值的比较。 有效的结果输出必然是由全过程工程咨询单位在总咨询师的组织下以及无数次建设方对中间设计成果的认可下完成的。这里涉及到建设单位和全过程工程咨询单位二方责任主体。 需要注意的是：在某项设计任务上建设方管理人员与设计人员的职能分工，特别是对于某些需要建设方参与的设计任务，责任一定要分清。 比如，建设方要求项目的整体造价控制在1个亿，在实施过程中，建设方总认为使用功能无法达到预期，于是通知你增加设备、增加室内房间数量，结果实施下来，却发现项目实际总造价为1.2个亿，于是你被建设方一顿狂喷。 再比如，建设方临时要求增加几部电梯或者某项建筑使用功能，这时你几乎已经完成了建筑专业和结构专业的大部分设计工作，为了响应建设方的要求，在有限的时间内，只能在原有的图纸上进行局部修改。但在施工过程中，却发现很多问题，最终的整体效果显得是那么地格格不入。结果你被建设方说得一无是处。 ……等等，诸如上述问题还会有很多，这里只呈现了冰山一角。而这一系列的问题，请问是谁的责任？你能分得清吗？ 有人会说，那肯定是建设方的责任呀，临时增加那么多东西，造价不偏离目标才怪！那么，建设方也会说：是全过程工程咨询的设计团队不行，就因为没有考虑到我才要求增加的，要是我全都能考虑到，要你设计干嘛？要你全过程工程咨询干嘛？ 公说公有理，婆说婆有理！幸运的是很少会有因为设计与建设单位的责任不清晰，导致的诉讼官司发生。但对于管理而言，则应是极力避免发生的，因为这会带来很多后续问题的纠缠，这无论是对于建设方还是全过程工程咨询方，其实都是一种潜在的风险。 规避或减轻此类风险最好的办法莫过于，请求建设方在每个设计阶段工作开展之前书面给予一个正式的《设计任务书》，并在全过程工程咨询合同中明确把它分阶段地作为双方履行全过程工程咨询设计任务的依据。这在我本系列文章的第21节到23节也多次谈到过这个问题。对此有兴趣的朋友不妨到我的个人主页去回看一下。 除此之外，全过程工程咨询单位在设计阶段还需要时刻关注于自己的设计成果是否超出了投资限额。这个很容易理解，但在具体工作实施过程中却很容易因赶进度而被忽视，或者是直接把投资目标和投资限额的概念搞混淆了。 投资目标并不等同于投资限额。可以把投资目标理解成项目的估算，而投资限额则可看成是项目的概算，估算是方案设计及可研的成果，而概算是初步设计的成果。估算要大于概算（一般为投资目标的80%左右）。 之所以要在初步设计进行限额设计，来源于《政府投资条例》（国务院令第712号），其中就规定：“初步设计提出的投资概算超过经批准的可行性研究报告提出的投资估算10%的，项目单位应当向投资主管部门或其他有关部门报告，投资主管部门或者其他部门可以要求项目单位重新报送可行性研究报告。” 当然了，大量的实践和经验也在告诉我们在初步设计阶段进行限额设计才是最好时间点！ 由此可见，限额设计这个概念是从初步设计开始的。是在建设方确定投资限额以后的深化设计。此时的总咨询师在初步设计阶段就要时刻提醒各位设计师们要有控制成本的意识，超出投资限额的设计，无论你设计得有多好，都要被认为是不合理的存在，也是建设方不可接受的。设计人员也应当自觉遵守，在成本控制人员的配合下主动复核设计成果，直到满足投资限额为止。

纵观各类科技企业，由于自身所处环境不同，因此其软件研发管理模式也不尽相同，这其中有基于CMMI能力成熟度模型指导下构建的研发管理体系，也有基于IPD集成产品研发框架指导下构建的研发管理体系，当然也有一些目前不少小企业、互联网企业推崇的敏捷研发管理体系。 01 基于CMMI的研发体系CMMI能力成熟度模型相信大家都不陌生，从一级到五级，覆盖了22个过程域，一般能达到CMMI3级别的基本上可以理解为各类流程、过程规则等已经达到一个较好的水平。 当然，这里主要是指企业能够确实按照CMMI模型去实践，这种实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。 虽然老谭所在的公司通过了CMMI5的级别，但是实际执行的过程中，我们并不会完全按照CMMI5进行，需要根据实际情况进行裁剪，相比于它对实际研发过程的指导作用，我感觉CMMI认证更多的为公司增加一种重要资质，以期在招投标中获得更好的加分。 对于互联网企业，特别是To C的互联网企业，CMMI认证的意义并不是特别大，因为在C端你无需依赖这些资质证明能力，而是以产品制胜。 02 基于IPD的研发体系 IPD的核心内容是以市场为导向的产品开发，关注客户需求，将产品开发看成一项投资（商业价值），通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品（各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付）。 去年开始负责研发时，我在公司更倾向采用IPD的模式构建研发体系，把技术团队和产品开发团队做了分离，也融合了近几年比较火的中台思想，其目的是将过去分散式的研发体系做适度的统一和整合，加强技术能力建设。 但经过这段时间的运行来看，其实也出现了水土不服的现象，其根本原因是IPD是是一个相对重量级的体系，要落地执行往往需要从整个公司层面去整体考虑和推动，而不仅仅是研发团队内部的变革，需要高密度的跨部门协作，所以对于中小企业来说，IPD也并不一定适用，因为： IPD需要对产品拆分为技术开发、平台开发和产品开发，一般中小公司没有这么复杂和巨大的产品； IPD的流程繁琐复杂，虽然可以裁剪，但也很多，针对众多研发项目，需要方方面面考虑周到，对中小公司来说管理成本太高； IPD的关键要素，无论是跨部门团队、管道管理，还是优化投资组合等都是针对市场，一般中小公司的市场驱动较弱。 03 基于敏捷模式的研发体系 在这个快鱼吃慢鱼的互联网时代，对用户和环境越来越要求要快速响应。 敏捷研发是当前不少互联网企业、中小企业推行的研发管理体系，主要理念就是敏捷迭代、小步快跑，快速改进、拥抱变化，用户参与等等。 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。 首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发，而不是一次性完成项目的交付；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发或者可以理解为小步快跑的开发模式，一次只交付客户一部分的特性或功能，如下图： 传统的外部客户的项目如果更适合CMMI管理的话，那么对于产品研发，不论是互联网产品研发还是To B的软件产品研发，敏捷模式都是更加适合的。 敏捷的交付是持续的一个过程，软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长；敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品。 老谭在负责一块互联网业务时，更多的是采用敏捷的开发模式，基本两周一个迭代的快速改进。 敏捷模式下，迭代的节奏是非常重要的，基于统一的节奏，产品、开发、测试、发布等不同岗位的人员就像建立了生物钟一样有规律的执行，团队间的协同能力得到极高的体现。 在这个研发体系里，敏捷团队负责人的主要工作除了执行例行的会议、任务分派以外，我认为最核心的就是对于sprint backlog的控制，既要照顾到需求方的关切，又不能轻易破坏节奏。 04 总结 这三种开发模式中，IPD的层级最高，既包括了“做正确的事”，又包括了“把事情做正确”，是公司级的运营级流程，CMMI和敏捷是同一个层级流程，是工程方面的实践级流程。CMMI和敏捷不具备高层决策能力，而一种“把事情做正确”的开发模式。 华为公司早在2009年正式发文在全公司现在流程IPD、CMMI的基础上，所有产品线的软件开发团队全面推行敏捷开发，可见这三个体系并不是孤立存在的，而是可以相融互补的。 由上图所示IPD关注整个产品的开发管理，包括市场、开发（软件、硬件）、结构、生产、采购、财务等各个方面，CMMI/Agile流程关注其中的软件研发过程的管理，CMMI是在研发过程中走瀑布模型，而敏捷是走版本迭代的模式。 所以如何建设自己的研发体系，并没有标准的答案，而要关注自己团队的发展阶段、规模大小、业务形态，根据上面三个体系的指导，建立一个适合自己发展研发体系。而且研发体系也不是一成不变的，也要根据业务的变化不断的迭代调整，以符合业务发展的需要。

  1. 对软件研发管理体系的一些概念认知 1.1. 研发管理是什么 关于研发管理，百度百科中这样定义：研发管理就是在研发体系结构设计和各种管理理论基础之上，借助信息平台对研发过程中进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等的一系列协调活动。 也就是说，研发管理首要一点就是要根据公司业务的发展确定相应的研发体系结构，之后按照这种研发体系结构组件一支高水平的研发团队，设计高效合理的研发流程，借助合适的研发信息平台支持研发团队高效工作，以绩效管理调动研发团队的积极性，以风险管理控制研发风险，以成本管理使研发在成本预算范围内完成研发工作，以项目管理确保研发项目的顺利进行，而知识管理使得研发团队的智慧联网和知识沉淀。 纵观各类软件企业，由于自身所处环境不同，因此其软件研发管理模式也不尽相同，这其中有基于CMMI能力成熟度模型指导下构建的研发管理体系，也有基于IPD集成产品研发框架指导下构建的研发管理体系，当然也有一些目前不少小企业、互联网企业推崇的敏捷研发管理体系。不同的研发管理体系其实都会有相应的交叉部分，最终追求的目标都是能否适合企业的发展，给企业带来市场和财务上的成功。 1.2. 基于CMMI的研发管理 CMMI能力成熟度模型相信大家都不陌生，从一级到五级，覆盖了22个过程域，一般能达到CMMI3级别的基本上可以理解为各类流程、过程规则等已经达到一个较好的水平。当然，这里主要是指企业能够确实按照CMMI模型去实践，这种实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。然则，实际上，大部分企业尤其是国内企业并不会严格按照这个模型去做，因为如果每一个过程域都不打折扣地执行地话，需要非常标准化的流程和强大的资源支撑，在这个讲究快速响应变化的时代其实是很难做到的，通常这个时候都会进行相应的裁剪，甚至会结合敏捷迭代等方面的模式，从而逐步形成自己公司的研发管理体系。 1.3. 基于敏捷模式的研发管理 在这个快鱼吃慢鱼的互联网时代，对用户和环境越来越要求要快速响应。敏捷研发是当前不少互联网企业、中小企业推行的研发管理体系，主要理念就是敏捷迭代、小步快跑，快速改进、拥抱变化，用户参与等等。目前这方面也有不少公司除了有相应的敏捷研发体系之外，还有相应的成熟工具做支撑。例如，腾讯的TAPD敏捷研发平台就是其中的代表。通过对用户故事的层级拆分，实现对需求的有效管控和分解，从而确保持续迭代上线。 敏捷研发管理在当前我们以业务为导向、项目为主的情况下，要全面实施尚有较大困难，当然并非是完全不能做，主要是当前所处的环境、所面向的业务、项目开发模式、人员结构等可能较难满足敏捷模式推行的需要。 1.4. 基于IPD的研发管理 之前有简单了解过IPD产品研发管理体系，我认为其中的核心就是“四四四”模型，四四四代表了四大团队、四个流程、四个支撑体系。 四大团队建设包括建立集成产品管理团队（IPMT）、建立产品市场团队（PMT）、建立产品开发团队（PDT）、建立技术开发团队（TDT）。 四大流程建设包括建立产品战略流程、建立需求管理流程、建立产品开发流程、建立技术开发及平台开发流程。 四个支撑体系建设包括建立项目管理体系、建立质量管理体系、建立绩效管理体系、建立成本管理体系。 个人感觉，基于IPD的产品研发管理从整体上来看是一个相对重量级的体系，要落地执行往往需要从整个公司层面去整体考虑和推动。 IPD的理念和敏捷开发理念在本质上是基本一致的，比如以市场需求（用户价值）为核心，将产品开发看成一项投资（商业价值），通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品（各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付）。 从理论上来讲，IPD研发管理体系是一个较全面的体系，在当前我们的现状下也可能容易出现水土不服的情形，当然其中有一些好的做法是值得借鉴的。 2. 什么样的软件研发管理体系适合我们的发展 从项目及产品的研发角度来看，发展到一定阶段的传统IT企业在研发管理上多数都是基于瀑布型的传统研发模式，由于项目的特点及人员的组织结构等因素，项目开发及产品研发的周期往往较长，较难适应市场快速变化的需要，也较难做到对客户的需求进行快速响应。而大部分的互联网公司及一些大厂，推行了敏捷研发模式，或者是在标准化项目管理和敏捷迭代两者融合上进行了相应的实践。 那么，针对当前我们所面临的一系列问题，究竟什么样的软件研发管理体系在未来一定时期内适合我们的发展？我们需要重构我们的软件研发管理体系吗？我们有必要重构我们的软件研发管理体系吗？带着这些问题，我想主要思考几个方面的问题。 2.1. 能否快速适应未来业务的发展变化 技术是为业务发展而服务的，因此在考虑软件研发管理体系构建时，第一个要考虑的问题就是我们的软件研发管理体系能否快速适应公司未来业务的发展变化。特别是在传统IT业务与互联网新兴业务加速融合的大环境下，信息化能力是越来越多客户的第一选择，因此在业务的快速发展方面需要更加强有力的技术支撑，而这个支撑的背后就是需要我们能够有一套能够快速响应变化、敏捷高效的研发体系，特别是能够有一定的前瞻性并支撑到老业务的快速转型和新业务的拓展。 2.2. 在业务出现较大波动时能否弹性伸缩 另外一个问题就是，业务在发展过程中，受大环境等诸多因素的影响，定然很难一直都是呈现直线上升的发展趋势，这当中必然会有波峰波谷，只不过这个波峰波谷是大是小的问题。而我们面临的问题则是，当出现较大的波峰波谷的时候，我们的研发管理体系应该如何适应？特别是在软件业务处于相对低谷时，既能够继续保持对技术研发的持续投入，又能够在应用开发等方面有一定的可伸缩性，从而正确地处理好软件生产效益问题。这里面可能会涉及到中高层次软件人才的相对稳定和低层次软件人才的灵活流动等问题。特别是在我们业务多样化的背景下，不同业务单元的发展会有不同的发展路径，对软件研发能力的诉求也有所不同，那么这里面首先涉及到的一点就是如何有效平衡基础研发能力和行业研发能力。 对于基础研发能力，个人认为应该是一个软件公司最内在的核心技术能力，往往很多时候基础研发工作很难像做行业应用开发那样立竿见影，但这项工作干得不好往往又容易成为行业研发能力的掣肘，这也是我们当前在人工智能、区块链等新技术潮流背景下总感觉难以发力的原因之一。 对于行业研发能力，个人认为应该要从两个方面去考虑，一个是产品化的能力，其二才是应用开发能力。应用开发能力很好理解，就是目前我们这么多年以来一直在做的各种类型的项目开发，而这里面大部分的项目开发其实都是偏应用层面的开发。而产品化的能力则是最近一两年以来我们重新关注的一个内容，不过这条路上我们尚开始起步，还有很长的路要走，也还有不少坑要踩。个人认为，产品化的能力能否真正发展起来，其中很重要的一点就是要考虑如何与基础研发能力做充分融合。产品化不等同于应用开发，应用开发更多是定制化的开发，是客户导向的软件开发，通常面向的是一个或少数几个的客户；而产品化则是要综合行业、市场、客户群体、新技术等多方面因素的研发，是市场导向的软件开发，面向的是一个或多个的客户群体，甚至面向的是一个市场或跨界市场。 2.3. 新技术研发及成果转化能否跟上业务变化 最近几年，新技术层出不穷，在软件架构的发展方面也非常迅猛，历经了单体架构、垂直架构、SOA架构、微服务架构的演化。从我们公司目前的技术研发实际来看，我们有少量的项目/系统采用了SOA架构，然则大部分的项目/系统仍然采用的是单体架构和垂直架构。单从这一点来看，我们在技术领域的持续跟进及成果转化方面已然有落后趋势，这方面需要我们奋起直追才行。当然，出现如今这种局面固然由众多因素催生而成。比如，已有开发框架前端兼容性的问题最近一两年以来常常被诟病，诚然有它内在的好处，然则最近一两年以来，用户对系统的用户体验要求更高了，不再是单纯地满足于功能实现层面，而是开始追求良好的人机交互和界面展现。因此，这方面势必对新技术的要求更加迫切。最近几年，当不少团队都在往前后端分离走的时候，我们至今的绝大部分软件项目开发仍然停留在前后端分离之前，对不少用户界面展现要求高的软件项目而言，难以快速有效响应变化，同时对一些相对比较成熟的软件产品而言也难以做到接口自动化。 因此，能否在新技术的研发上抓住正确的方向并加快研发成果转化，为业务的快速变化提供强有力的技术支撑，是一个摆在我们面前急需解决的课题。从当今新技术的发展趋势来看，研发架构方面，我们虽说不能完全抛弃传统的单体/垂直架构，但我们必须要往微服务架构方向迈进，除了与最新技术接轨之外，更重要的是如何进行业务解耦，沉淀行业积累，并反向推动人员组织层次的变革，提升软件生产效率，提高软件质量。 除此之外，对于人工智能、区块链等新领域，也是需要综合业务应用场景打造适合我们自身发展的技术+业务融合之路。 2.4. 在标准化和敏捷迭代之间如何平衡 标准化的软件研发道路固然有不少好处，有严谨的流程、规范的体系、固定的套路，当然更多的则是瀑布开发模式，虽然最近几年也陆续有迭代开发的模式，但更多的是被动式响应，而且这种迭代开发模式基本上是大阶段的划分，在每一个大阶段里面依旧是一个典型的瀑布开发模式，即历经需求分析、交互原型设计、UI设计、Web前端开发、程序开发、系统测试、部署实施等步骤，横跨周期往往较长，一旦发生需求变更，变动的代价过高。 敏捷开发强调以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 那么，问题来了，既然标准化项目管理模式下存在太多流水线作业及效率低下等问题，那么我们能够直接转向敏捷迭代模式呢？世界上万事万物都是对立统一的，个人认为不论是标准化项目管理模式还是敏捷迭代项目管理模式都有其擅长的一面。一方面，在现有的以项目为主导的软件开发体系中，标准化模式是我们一直以来的主要做法，也积累了不少经验做法；另一方面，采用敏捷迭代模式对于产品复杂不断有新需求加入等场景是比较适合的。所以这里面更多的是考虑如何更好地平衡标准化项目管理和敏捷迭代两者之间的关系。基本的思路就是结合标准化项目管理和敏捷迭代的优缺点进行适度裁剪，既能提高软件质量和软件开发效率，也能够保留一定的规范性和软件过程文档。例如，针对项目管理，通常是五个过程组：启动、规划、执行、监控、收尾，那么我们其实可以结合实际将规划提前，将监控贯穿于执行过程，这样就势必要求在启动时也要做好项目计划相关工作，在执行过程中抓住关注点并定期监控其执行情况，在收尾阶段做好项目回顾总结。 不论采用何种模式，我们的根本目标就是达到更低的成本实现更快速、更可靠的交付。近年来比较火热的是DevOps。DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 因此，我们的软件研发管理体系中是否应该引入DevOps，进而改善公司组织文化、提高员工的参与感、提高交付效率，我想这也是需要重点关注和考虑的。 2.5. 组织过程资产能否持续积累并盘活 组织过程资产指一个学习型组织在项目操作过程中所积累的无形资产。组织过程资产的累积程度是衡量一个项目组织管理体系成熟度的重要指标，项目组织在实践中形成自己独特的过程资产，构成组织的核心竞争力。 组织过程资产主要包括但不限于以下内容：项目组织在项目管理过程中指定的各种规章制度、指导方针、规范标准、操作程序、工作流程、行为准则和工具方法等。项目组织在项目操作过程中所获得的经验和教训，其中既包括已经形成文字的档案，也包括留在团队成员脑子中没有形成文字的思想。项目组织在项目管理过程中形成的所有文档，包括知识资料库、文档模板、标准化的表格、风险清单等。 项目组织在以往的项目操作过程中留下的历史信息。 经过多年的软件开发，我们做了大大小小形形色色的软件项目和产品，也逐渐积累了一些行业化的软件项目，但总的来看，能够形成规模化效应的软件产品尚较为匮乏，更多的是以定制化开发为主的软件系统，当然也积累了不少项目经验。在这过程中，也积累了不少标准、规范、流程、模板等各类软件过程资源。然而，从目前掌握的情况来看，这些资源是分散的，不够体系化的，还谈不上真正意义上的资产，至少在价值的发挥上还不充分。况且，软件行业这几年的人才流动率明显加快，人员更替的速度以及未能体系化的过程资产积累，加剧了组织过程资产的盘活难度。 那么，构建一个相对健全的、动态的、能够适应未来业务发展的组织过程资产库就显得尤为重要。这既是软件研发管理体系的一个重要组成部分，也是公司层面应该给予充分重视的。在组织过程资产库构建的过程中，其中很重要的一点就是如何让研发知识与经验成为公司的宝贵财产，这里就要充分考虑研发知识管理。知识管理把“隐形知识显性化”，是一项涉及知识库、过程资产、环境和交流等元素的整合过程，所管理的知识将作为一个团组织中过程资产的重要组成部分。对于软件研发而言，我们需要考虑怎么把业务人员和技术人员脑中的蓝图转化为显性知识。…

如果说知识摄入的多少与思维复杂程度成正比，做工程造价实践很重要，即使是高学历人才，也要立足实践，这里有个同行提问（见图1）： 图1 工程价款调整的前提和方法的合同约定 截图中的文字并没有什么描述不清晰的地方，但提问人却不明白“合同条款未说明合同结算模式是单价合同还是总价合同”，也就是操作人不知道面对这份合同结算时是调整总造价还是调整综合单价。 在此笔者用一个数学模型对这道题进行解答： 一个批发商向手机厂家订购了100部手机，单价5000元/部，预付50%货款，约定货到验收完成后支付剩余货款，货到时验收发现，有2部手机因运输过程中损坏，批发商要求向厂家提出退货申请并得到了厂家同意，问批发商还应该再向手机厂家支付多少货款？ 公式： （100×50%－2）×5000=240000.00元 这道题解题方法有多种，题中要说的核心内容就是因为货物数量发生变化，导致最终货款发生了变化，换一种分列式的解题方法。 此项采购合同价款 =100×5000=500000.00元 已经支付的预付款 =500000.00×50%=250000.00元 剩余货款 =500000.00－500000.00×50%=250000.00元 因为货物数量发生变化导致剩余货款总价转变为： 250000.00-2×5000=240000.00元 再看图1中的合同条款，第1、第2项内容说的都是数量的变化，设计变更首先也是项、量的变动。因为有了第1、第2项合同约定的前提，导致最终工程总造价在结算时因为量变而可以发生变化。 数学模型中的手机单价在任何一个公式中都没有发生改变，清单计价的核心原则也是结算时清单项目综合单价不能调整，这就是我们常说的“单价合同”或称“固定单价合同”，现在我们常用的清单计价模式都是“单价合同”模式，合同条款中不管注没注明结算模式，只要是清单计价结算操作过程中就不能调整清单项目的综合单价。 说到此如果还有人没有看懂为什么笔者能确定合同一定是单价合同结算模式，下面就继续看“合同价款调整”小节的最后一段话。 最后一段话第一句“发生以上两条之一时按照中标单价依实调整”，合同内清单项目工程量发生变化（不管是因为工程量编制错误还是设计图差导致），总之就用最终的竣工图纸工程量（或依据实体工程量）减合同清单工程量，得出的量差（也许有负数量差）×合同内的清单项目综合单价=清单项目量差合价。 最后一段话后两句话意思是：如果变更项目在合同内能找到相同的工序，仍然要参考合同内的工序单价，如合同内项目特征描述是挖二类土，实际挖运的是三类土，挖土方的工序单价可以重新组价，但运土方的工序单价要照抄合同内单价不能改变。 合同内没有变更项目可以参照的清单综合单价，可以与审计单位协商定价，如合同内项目特征描述是挖二类土，实际挖的是淤泥，变更的土方项目挖淤泥项目，不管挖淤泥还是运淤泥，合同内都没有可以参照的单价，这就需要双方坐下来重新组价，协商定价的基础就要用到“组价原则”这个清单计价的重要概念，也就是说虽然变更项目与合同内清单项目没有可以参照的工序可以借用，变更项目中出现的与合同内相同的人、材、机单价，要执行合同内的人、材、机单价。 如人工费单价投标时按150元/工日计价，变更项目的结算时人工费单价仍然要执行150元/工日，如果同合同条款内还注明有“人工费单价结算时可以按某期信息价调整价差”，这句合同条款与清单项目综合单价组价无关，因为组价原则指的是投标时的组价原则，结算时的价格变化属于人、材、机单价调整范畴，不属于清单项目综合单价调整的内容。费率与人、材、机单价同理，投标时税率是10%，结算时税法税率已经变成了9%，结算时税率仍然以10%计算，结算后再讨论如何退还税差。 如果图1中的问题出现在造价师考试题中，应该是100%的送分题，也许试题题库的编辑人也与笔者有同感，所以没有把此题收入题库中，导致许多同行遇到此类问题不知如何求解，最可怕的是问题的回复中有许多说是可以调整综合单价的答案，这种误导不知道依据何在，笔者对着截图反复推敲过多次，也没看出任何可以调整综合单价的暗示，问题的回复人可能把“调整清单项目综合单价”和“重组清单项目综合单价”的概念搞混淆了。 总之，工程造价的境界应该是把复杂的问题简单化才是正解，可实际操作中，能用基础知识解答的问题，非要使用复杂的方法去解释图1的问题，无疑会降低效率，通过实践摸索出高效方法，实践出真知。

  长期以来，中国高端装备的研发主要采用跟随仿制的策略。我国多数工业企业只具备逆向工程能力，难以产生创新性设计，产品的功能和性能远不及仿制对象。更为严重的是，长期跟踪仿制和逆向设计形成了基因性后遗症，科技人员普遍存在害怕创新的保守心态，整个工业体系缺乏产品正向设计的理论和实践，甚至对正向设计的理解都一知半解，似是而非。 一、什么是正向设计 美国科学家PAUL ROOK 1980年提出软件工程V模型，目的是减小BUG和ERROR出现的概率。V模型是对瀑布模型的修正，强调了验证活动，它反映了测试活动与分析和设计的关系。如图1（a）所示。 图1.复杂产品的研发过程 系统工程科学家们认为PAUL ROOK提出的V模型适合于普适系统工程（其实，软件工程本身就是一种系统工程过程），于是就将此模型修订为系统工程V模型，反映了系统开发的技术过程。不同系统工程学派、企业和机构的研究与实践所采用的V模型具有一定差异，这些模型具有不同的流程边界划分方式，某些流程活动名称相似但内涵不同。我们综合系统工程的经典理论和在中国企业的实践，提出了如图1（b）所示的系统工程V模型。 表1给出了产品研发过程V模型的说明。其中，第1至9是系统工程内部流程，而第0（涉众需求）和第10（系统验收）则是对外流程。考虑到各学派和不同实践中所用名称的差异，本表也给出了相似过程的其他常见名称。 表1. 系统工程V模型说明 序号 过程名称 主要内容 其他常见名称 0 涉众需求 利益相关者的需求，包括用例想定、使命任务和使用构想等。 利益相关者期望 1 需求定义 汇总所有利益相关者的输入，并将它们转化为技术需求。 需求建模、需求分析 2 功能分解 获取逻辑解决方案的过程，用于进一步理解已定义需求和需求间的关系。 逻辑分解、功能架构、功能分析、功能分配 3 系统综合 将需求定义和功能分解的输出，转化为可选解决方案和确定最终解决方案的过程。 方案设计、物理架构、系统架构 4 物理设计 最终实现系统分解结构中底层系统组件方案的过程。系统组件可以是新设计、采购或重用。 详细设计 5 工艺试制 单机设备的工艺设计和加工等，形成系统设计中指定的所有单机设备。本书在有些情况也将工艺与试制分为两个活动。 产品实现 6 部件验证 针对零部件、单机设备进行试验验证，确认符合设计预期。 部件试验 7 系统集成 将底层系统组件转化为高层系统组件的过程。 综合集成 8 系统验证 确认系统组件与设计初衷相符，即回答“是否做对？” 9 系统确认 回答“是否设计了正确产品？” 10 系统验收…

核心观点 1、国内部分车企热衷于IPD不如回归到将国际车企整车开发流程吃透、执行到位，对企业的长远发展更为有利。 2、BOM通过配置特征有效地建立起车型-配置-零部件的关系，才能使得产品策划、产品定义过程的销量规划、成本评估获得一致的数据载体，实现产品策划过程的盈利分析。 3、规划驱动BOM体现了正向开发对产品策划的重视以及策划成果通过BOM承载的思想。 提出规划驱动BOM的概念，这是一个针对BOM问题反复深入思考的结果。规划驱动BOM概念的提出，是相对于传统的BOM基于设计结果数据（CAD数据）产生的方式而言的。提出这个概念，是希望从各种BOM问题的表象回归到BOM的本质，更好地理解BOM产生的条件、产生的方式、产生的目的、服务的对象、参与的角色、管理的内容等。从中国汽车行业长达十多年的实践来看，车企走过不少弯路。各车企所走的弯路虽不尽相同，但归根到底有一条是相同的，就是最终回到规划驱动BOM的思路上来。 因此，当我们构建新的BOM体系的时候，规划驱动BOM将会是一条重要的指导思想。 企业当前都强调正向研发。产品定义是正向开发过程中一个非常关键的活动。可以说，没有明确的产品定义过程，就谈不上产品正向开发。 产品定义的过程包含要研发的产品在市场方面的考虑、未来销量方面的考虑、产品盈利方面的考虑（经济性及其它如重量）等等。产品定义的过程，是一个多业务领域逐步规划的过程。BOM在这个过程中自然产生。因此，理解了产品定义过程，将对规划驱动BOM有更深的体会与理解。 从提出规划驱动BOM概念以来，本人又经历了不少商用车企业级BOM体系构建的案例。商用车在这方面的体现尤为显著。因此，本文将以商用车的产品定义过程为例，结合模块化的落地，来探讨BOM是如何一步一步规划出来的。 正向开发过程的产品定义 产品定义是产品正向开发过程中的非常重要的一环，产品定义决定了工程开发的范围。没有产品定义就谈不上产品正向开发。产品定义是产品规划的结果。产品集成开发（IPD，Integrated Product Development）理念强调面向盈利目标的集成化产品规划。IPD框架下产品管理、技术开发、产品开发三者的关系如图一所示： 图一：IPD高级流程框架(来自IBM IPD说明材料) 产品管理流程是基于市场对企业要研发的产品进行准确定位的过程。产品管理主要工作为通过对市场环境、趋势、客户及竞品分析，制定市场细分以提供产品定位的标准，确定可实现的产品投资组合；基于市场洞察和已确定的产品投资组合，结合业务战略制定产品规划，并制定相应的资源计划，达到优化组合。技术开发则是指平台架构开发或者关键技术、零部件开发。架构、关键技术、关键零部件最终要在合适的时点被用到产品开发过程中来。技术开发是一种先期技术储备，为产品开发提供平台、关键技术、关键零部件支持，从而达到缩短开发周期、提高产品开发质量的目的。逐步成熟的平台技术、关键零部件被应用到产品开发中来的过程，也是产品规划的一个重要方面。 从市场角度的产品管理流程结合企业的技术规划，实现正向开发过程中的产品规划。在产品开发流程中的概念/策划阶段，依据产品规划的结果进行产品定义，确定工程开发的范围。产品规划与产品定义可以表达为图二所示的关系： 图二：产品正向开发过程中的产品规划与产品定义 产品规划过程预先界定产品的选项组合, 纳入开发项目并成为商品销售的主要内容。在产品规划过程中, 同时形成产品概念以及结构化的产品分类及规格，建立客户需求和产品规格之间的市场规则。产品定义的用途是用来管理产品的变型，以满足客户多样化的需求。产品分类的结构用来识别产品线/平台、产品、变型产品的等级关系，以及决定各层级产品的要素。这些要素通常以配置或者参数的形式进行定义。一般而言，特别是变型产品层级的变因，即图二中的决定变型产品的关键配置，在企业中最好形成相应规范。基于这些关键配置项的组合，规划出变型产品。而变型产品之上的层级一般由能够表征平台特性、架构特性的更为基础的配置或者参数决定。在这一框架内，基于市场规划所需要满足的需求，规划出产品层级下的配置，并以变型产品为单位规划这些配置的标配选配情况。 完成这一层级的定义，基本上确定了新产品开发的工程开发范围。在规划的配置基础上，下一步的工作则是对模块进行规划，即基于配置定义的基础上，确定模块的品类、每个模块品类的驱动因子（典型如配置驱动的模块变型）及由此而产生的模块变型。结合企业资源情况，确定产品开发项目所需要开发的模块。确定模块的开发策略，即确定哪些模块沿用、哪些模块新开发、哪些模块在沿用基础上修改。接下来，基于模块的基础上规划出零部件清单。 综上，产品定义过程可以简单描述为：以产品规划为输入，定义出产品开发项目所需要开发的产品组合、变型产品、配置清单以及模块/零部件清单。这一过程回答了新产品开发项目要开发什么产品（平台架构特性、关键配置组合形成的变型产品）、具备哪些功能（配置，一般以特征族/特征值来表达）、采用什么方式实现（模块/零部件）等关键问题。 从IPD理念来看，以产品管理流程和技术开发流程为前导的产品定义，尽量保证了产品开发项目开发出来的产品将是市场需要、同时能够体现企业独特的技术优势的产品。同时，需要进一步考虑定义出来的产品是能够盈利的，具有成本竞争力的。这就需要对定义出来的产品未来的销量进行预测，对成本进行评估。销量规划与预测基于产品及配置组合展开；对成本的评估则基于模块/零部件。这也是产品定义过程非常重要的方面。 上述产品定义过程体现了IPD面向盈利目标的集成化产品规划的思想。 商用车产品定义过程 在上文阐述产品定义的时候，我试图以IPD的流程框架来探讨产品定义的过程。这是因为IPD框架足够简明，更容易说清楚这个问题。但这并不代表这个产品定义过程是IPD所独有的。一个正向开发的过程，产品定义就应当遵循上述的原则。汽车产品无论从产品还是供应链的角度，都可以说是制造业非常复杂的产品，在制造业中非常具有典型性。汽车产品经过上百年的持续发展，其产品开发流程充分考虑、吸收了产品创造的各种先进实践，其中包括IPD所推崇的实践，同时也会比IPD更为结构化，更加贴合汽车这种复杂产品开发的特点。从这个意义上，我认为国内部分车企热衷于IPD不如回归到将国际车企整车开发流程吃透、执行到位，对企业的长远发展更为有利。 在汽车行业的产品开发流程中，国际上先进的车企，其产品定义过程与上述IPD框架下的产品定义过程极为相似，只是更为落地，更具有针对汽车产品的可操作性。 针对商用车，产品定义过程可以描述成图三所示的框架。 图三：商用车产品定义过程框架 产品定义过程涉及到市场、规划、产品、采购等多个业务领域。市场部门负责提供市场需求、销量计划，作为产品定义的输入。规划部门在产品定义过程中承担主要职责，负责车型产品及配置的定义及与销量计划匹配的基于车型、配置组合的销量规划。由功能层落实到实现层的定义，则需要产品团队、特别是模块策划/设计团队的参与。成本评估过程则需要采购团队提供零部件供应商及价格等信息。上述过程可以归结为四个步骤： 1、平台车型规划 基于产品线，按照平台、架构涉及的基础要素对平台车型进行定义。基础要素主要是产品技术特性，特别是与平台技术密切相关的底盘的技术特性，如GVW、驱动等。在平台车型划分的基础上进行主销量规划。主销量规划所基于的关键输入信息包括：车型需求清单、参考平台车型数据、决定平台车型主要驱动因素（基础配置）以及市场部门提供的销量计划。在此基础上，规划部门基于细分市场应用和产品主要技术特征对产品组合内车型进行分类和描述，定义出一定数量的平台车型；根据销量计划，规划模块化平台未来5-10年的主销量，并按照模块化平台基础配置进行销量分解。基础配置的销量分解过程通常是按照配置比例、配置组合逐层进行分解。 2、车型规划 车型规划是在上述基于基础配置划分出的平台车型基础上，再根据关键配置（体现不同配置梯度的关键特征）进一步对车型进行划分。无论是按照基础配置划分出平台车型，还是按照关键配置划分出变量车型（变型产品），都是基于配置逐层形成相对确定的产品组合，降低产品开发的复杂度。车型规划所基于的关键输入信息包括：主销量规划的输出信息、体现配置梯度的关键要素（变型驱动要素）、参考项目的车型数据以及销量计划等。变型驱动要素即关键配置往往包括发动机型号、变速器型号等，部分车企还会将车桥等因素纳入进来。 车型规划的结果是车型清单以及在此基础上规划的车型销量。 3、配置清单规划 根据市场细分需求、目标定位以及公司的技术路线规划，在变量车型的基础上进一步定义出该车型为了满足市场需求所涉及的配置特征。配置清单规划所基于的关键输入信息包括：市场需求、技术路线规划、车型规划、参考项目特征清单以及销量计划。 配置清单规划的成果包括主控车型定义、配置特征清单、特征清单与车型之间的标配选配关系、规划的特征销量以及特征占比。主控车型是在变量车型基础上根据市场需求定义的100%完整的单车。通常一个变量车型定义出若干能够最大程度代表变量车型的主控车型，用于验证、成本管控等目的。 4、整车零件矩阵规划 从我们接触的汽车行业案例来看，无论是整车企业还是零部件企业，零件矩阵（Part Matrix）都是在产品开发早期阶段的一份重要交付物。之所以重要，是因为它是推动产品研发项目管理的数据基础。在完成车型配置规划之后，零部件矩阵规划便可进行。对于推行模块化的企业，这个过程将变得更自然、更为容易一些。 首先，可以从企业标准规范上定义模块与配置的关系。模块化管理的要点之一是需要管理模块的变型因子，从而能够根据变型因子策划模块组合数量。模块变型因子往往可以和配置挂钩。因此当完成车型配置规划，便可借助模块与配置的关系以及配置本身的约束关系计算模块的理论组合。 其次，不是所有的理论组合都需要成为项目的开发范围，还需要考虑企业的资源匹配，来确定本项目所需要开发的模块清单。 在此基础上，进行模块开发策略的制定，即确定哪些模块可以沿用、哪些可以在沿用基础上修改、哪些是全新开发。基于模块开发策略基础上规划出模块清单及模块所涉及的零部件。 针对一个功能，在早期的规划中，可能有多个工程方案可以满足。这个时候，就需要从技术实现以及成本等方面对多方案进行选择。因此，零件矩阵规划过程，往往是一个工程方案选型的过程。 在产品定义阶段需要规划出整车零件矩阵的意义在于：只有规划出了整车零件矩阵，才可以比较落地地评估整车产品的成本，从而能够在整车开发过程中持续地评估成本目标、盈利目标是否能够实现。 上述产品定义过程，通过特征组合一步步定义车型，逐层进行销量规划。销量基于特征占比及组合进行规划，通过组合逻辑保证了整车完整性，同时又与市场需求进行了很好对应。落实到零件层面的整车零件矩阵规划，使得成本评估能够落地。整个过程很好地体现了面向盈利的集成化产品规划与定义的思想。 当然，每家企业都不相同，如何划分平台、车型，将哪些要素作为驱动要素、抽取哪些要素作为配置特征，每家企业都需要根据具体的产品进行分析。 BOM构建过程与产品定义的关系 在一个正向开发流程中，BOM的构建过程与产品定义的过程高度一致，是产品定义过程自然产物。这一关系表达如图四所示： 图四：BOM构建与产品定义的关系 产品定义过程前面已详细描述，从平台车型规划、变量车型规划、配置清单规划到整车零件矩阵规划，按四个步骤进行，兹不赘述。从BOM架构来看，完成完整的BOM定义需要确定三个层级的内容：第一层级是车型之间关系的定义，或者说是车型型谱的定义。这一层级确定了BOM构建所覆盖的车型范围。产品定义过程中，根据市场细分对产品组合进行管理，通过基础要素划分出平台车型、通过关键要素划分出变型产品（变量车型）的过程，正是完成BOM所需要的车型关系的构建过程。第二层级是车型配置的定义，确定要开发的车型所涉及的配置特征清单以及这些特征与不同梯度车型之间的标配选配关系。产品定义过程中对配置清单的规划，其输出即是车型配置表。第三层次则是模块、零部件的定义，确定要实现相应配置功能的具体工程方案。产品定义过程完成整车零件矩阵规划，完成了BOM的初始构建，形成了BOM领域的早期BOM。 上述过程可以看出，从产品正向开发的角度来看，BOM正是这么一步一步规划出来的。规划驱动BOM体现了正向开发对产品策划的重视以及策划成果通过BOM承载的思想。BOM通过配置特征有效地建立起车型-配置-零部件的关系，才能使得产品策划、产品定义过程的销量规划、成本评估获得一致的数据载体，实现产品策划过程的盈利分析。 反观从CAD出BOM这一思路，则显然人为隔断了产品规划、产品定义成果在产品数据上的完整、高效表达。而国内车企普遍畏惧的在BOM上维护配置条件的问题以及配置条件维护质量普遍较低的原因，正是因为没有从正向规划的角度理顺配置与车型、零部件之间的关系，而是从逆向的角度生硬维护的必然结果。…