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

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

  长期以来，中国高端装备的研发主要采用跟随仿制的策略。我国多数工业企业只具备逆向工程能力，难以产生创新性设计，产品的功能和性能远不及仿制对象。更为严重的是，长期跟踪仿制和逆向设计形成了基因性后遗症，科技人员普遍存在害怕创新的保守心态，整个工业体系缺乏产品正向设计的理论和实践，甚至对正向设计的理解都一知半解，似是而非。 一、什么是正向设计 美国科学家PAUL ROOK 1980年提出软件工程V模型，目的是减小BUG和ERROR出现的概率。V模型是对瀑布模型的修正，强调了验证活动，它反映了测试活动与分析和设计的关系。如图1（a）所示。 图1.复杂产品的研发过程系统 工程科学家们认为PAUL ROOK提出的V模型适合于普适系统工程（其实，软件工程本身就是一种系统工程过程），于是就将此模型修订为系统工程V模型，反映了系统开发的技术过程。不同系统工程学派、企业和机构的研究与实践所采用的V模型具有一定差异，这些模型具有不同的流程边界划分方式，某些流程活动名称相似但内涵不同。完美体育WM综合系统工程的经典理论和在中国企业的实践，提出了如图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的思路上来。 因此，当完美体育WM构建新的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、整车零件矩阵规划 从完美体育WM接触的汽车行业案例来看，无论是整车企业还是零部件企业，零件矩阵（Part Matrix）都是在产品开发早期阶段的一份重要交付物。之所以重要，是因为它是推动产品研发项目管理的数据基础。在完成车型配置规划之后，零部件矩阵规划便可进行。对于推行模块化的企业，这个过程将变得更自然、更为容易一些。 首先，可以从企业标准规范上定义模块与配置的关系。模块化管理的要点之一是需要管理模块的变型因子，从而能够根据变型因子策划模块组合数量。模块变型因子往往可以和配置挂钩。因此当完成车型配置规划，便可借助模块与配置的关系以及配置本身的约束关系计算模块的理论组合。 其次，不是所有的理论组合都需要成为项目的开发范围，还需要考虑企业的资源匹配，来确定本项目所需要开发的模块清单。 在此基础上，进行模块开发策略的制定，即确定哪些模块可以沿用、哪些可以在沿用基础上修改、哪些是全新开发。基于模块开发策略基础上规划出模块清单及模块所涉及的零部件。 针对一个功能，在早期的规划中，可能有多个工程方案可以满足。这个时候，就需要从技术实现以及成本等方面对多方案进行选择。因此，零件矩阵规划过程，往往是一个工程方案选型的过程。 在产品定义阶段需要规划出整车零件矩阵的意义在于：只有规划出了整车零件矩阵，才可以比较落地地评估整车产品的成本，从而能够在整车开发过程中持续地评估成本目标、盈利目标是否能够实现。 上述产品定义过程，通过特征组合一步步定义车型，逐层进行销量规划。销量基于特征占比及组合进行规划，通过组合逻辑保证了整车完整性，同时又与市场需求进行了很好对应。落实到零件层面的整车零件矩阵规划，使得成本评估能够落地。整个过程很好地体现了面向盈利的集成化产品规划与定义的思想。 当然，每家企业都不相同，如何划分平台、车型，将哪些要素作为驱动要素、抽取哪些要素作为配置特征，每家企业都需要根据具体的产品进行分析。 BOM构建过程与产品定义的关系 在一个正向开发流程中，BOM的构建过程与产品定义的过程高度一致，是产品定义过程自然产物。这一关系表达如图四所示： 图四：BOM构建与产品定义的关系 产品定义过程前面已详细描述，从平台车型规划、变量车型规划、配置清单规划到整车零件矩阵规划，按四个步骤进行，兹不赘述。从BOM架构来看，完成完整的BOM定义需要确定三个层级的内容：第一层级是车型之间关系的定义，或者说是车型型谱的定义。这一层级确定了BOM构建所覆盖的车型范围。产品定义过程中，根据市场细分对产品组合进行管理，通过基础要素划分出平台车型、通过关键要素划分出变型产品（变量车型）的过程，正是完成BOM所需要的车型关系的构建过程。第二层级是车型配置的定义，确定要开发的车型所涉及的配置特征清单以及这些特征与不同梯度车型之间的标配选配关系。产品定义过程中对配置清单的规划，其输出即是车型配置表。第三层次则是模块、零部件的定义，确定要实现相应配置功能的具体工程方案。产品定义过程完成整车零件矩阵规划，完成了BOM的初始构建，形成了BOM领域的早期BOM。 上述过程可以看出，从产品正向开发的角度来看，BOM正是这么一步一步规划出来的。规划驱动BOM体现了正向开发对产品策划的重视以及策划成果通过BOM承载的思想。BOM通过配置特征有效地建立起车型-配置-零部件的关系，才能使得产品策划、产品定义过程的销量规划、成本评估获得一致的数据载体，实现产品策划过程的盈利分析。 反观从CAD出BOM这一思路，则显然人为隔断了产品规划、产品定义成果在产品数据上的完整、高效表达。而国内车企普遍畏惧的在BOM上维护配置条件的问题以及配置条件维护质量普遍较低的原因，正是因为没有从正向规划的角度理顺配置与车型、零部件之间的关系，而是从逆向的角度生硬维护的必然结果。…

一、晶圆制造厂的BOM 以IDM为例，公司的销售不是简单的市场营销，更多的是技术性营销。晶圆产品，通常要满足行业内的基本要求，有的还涉及到客户的追加、改造功能（定制化）。 销售人员根据客户需求，制作内部报价单，经晶圆厂研究后，对客户进行报价。这个过程中，如何报价的核心，就是BOM，当然是完美体育WM说的主数据BOM（标准）。 销售完后的售后服务，对晶圆厂来说也很重要，不是简单的交付后了事，而是要持续跟进客户需求，经常派技术骨干继续上门服务，此时的上门服务，BOM信息依旧不可或缺。、 在根据订单进行生产时，BOM作为产品规格的重要甚至是唯一信息源，可以说是全部业务的核心，是DNA。 二、整车厂的BOM 汽车行业，是整车厂主导供应链的典型行业。这一点和PC组装厂还不同，PC的零部件总体来说是标品，单一或几个CP组装厂是无法控制整个供应链的，不同标品的各种组合，给了上游供应商很大的自主空间。 整车厂就不同了，一辆汽车包括几十万个零部件，这些零部件的规格、专用性能，几乎都是由整车厂决定的。小鹏汽车选用的座椅是小鹏的专用品，无法用在蔚来车上面，可能仅有车胎、车内立体音响等行业规定的标品可以互换。 完美体育WM来看看整车厂的BOM。 构成汽车的零部件可以分为汽车引擎、座椅、车顶等大型零配件和车窗等小型零配件。在汽车组装的生产线中，第一步是组装焊接汽车地板、车顶、前悬、侧板等车身边板，构成一个车身的外形，这也称之为“车身车间”，再继续组装车身的边板。生产大型车的时候，还需要加装承重架。汽车外形基本OK后，再将车身送到喷涂车间，冲压、清洗，对车内外进行喷涂。 喷涂车间之后是组装工序，包括内饰生产线、底盘生产线、总装生产线和检查生产线。每条工艺路线具体由几十道工序组成。 即便同一个车型，也有不同颜色、等级（低配、中配、高配）等，可以看出，汽车BOM的特点，是变化多样、选项众多。因此，在整车厂，BOM的维护管理，是一项重要工作，一般都有一套独立的BOM系统，而且需要耗费很多人力来管理。 三、化妆品厂的BOM 化妆品厂面临的供应链管理问题，天然就更困难。 新产品的开发时间必须短，新产品投入市场的时间必须紧跟季节性的潮流，以及广告的投放效果。广告的效果好坏，渠道的多元化，市场的需求难以预测。产品性质就是品类多样，例如同一种产品，也有小瓶样品、试用装、标准装等多种。为了达到销售的最好效果，交期也很短，必须在“双十一”之类的节日期间，快速满足市场的需求。 对化妆品厂而言，短期内快速开发产品、准确把握市场需求（虽然很难）、有效应对需求变动的灵活性和爆发力，是核心竞争力。核心竞争力的基础数据，就是BOM数据，这些数据还要在化妆品企划、设计、生产技术、制造、采购、物流和销售等各部门之间灵活共享、应用。

  一、什么是BOM？ 来个定义性的文字：BOM就是以物料数据为中心的产品结构、生产工序相关的标准信息，以及派生的历史信息。 这个是狭义的BOM，广义的BOM，应该是：由物料数据、工艺路线（工序表）、设计图纸、生产指令和生产实绩报告等历史信息构成的，与物料相关的庞大的信息体系。其中，工艺路线最重要，它与BOM是表、里的关系。 二、配置BOM为了什么？ 生产制造部： BOM是物料管理的关键，工艺路线都在BOM里面啊。如果没有材料标准，如何能根据生产计划供应物料？也无法根据订单来控制生产。 售后维护部： 什么产品使用什么零部件，都要根据BOM来配置、确定。如果不知道产品中各零部件的用途，后续如何在进行作业时，继续追踪？ 财务部： 计算各种产品时，当然要根据BOM来啦。 销售部： 客户的需求总是变化的，很多时候都不是标准规格的产品。难道我要拿着客户的问题，一个个的去问设计部、财务部？如果不知道产品的成本组成，怎么和客户谈判时，对产品定价呢？实际上，最后产品的交付，很多时候也只能现场估计。 设计部： 完美体育WM是制作设计图纸、零部件表的部门。其他部门使用的BOM，都是在完美体育WM制作的设计图基础上。完美体育WM设计部的主要工作之一，就是在设计新产品时，做好零部件通用化工作，尽量使用原有的设计图纸、原有的零件表。 库管部： 完美体育WM靠BOM表和实际消耗、使用情况，来不断更新库存信息，保证原材料、零部件处于安全库存水平之上。 采购部： 有了BOM表，完美体育WM才好按照规定好的产品单价、规格，结合实际使用情况，提前材料。 三、BOM有几种？ BOM的信息，实际上分为三种。 第一种，主数据。 本人理解为在产品生产出来时的标准数据，这种数据录入之后，一般不会轻易更改。重要的是，主数据的逻辑要一致。比如A产品，由具体XX和XX构成，XX的物料是XXX、XXX、XXX。 第二种，用于生产指示的历史/交易数据。 有了标准，但是实际生产时所附上的指示清单，由于材料采购、备货的具体情况（比如某一种物料临时涨价很快、某一零部件维修很麻烦，其他物料/零部件可以替代），很多时候是与主数据不同的。生产部门按用于生产指示的历史/交易数据，从仓库中提货生产。 第三种，实际生产出来的历史/交易数据。 这是生产产品时各项流程中的实际数据。现实中，历史数据经常被废弃，或仅仅被临时保存。历史/交易数据，常常与主数据不一样。它是实际记录了什么、多少的零部件、物料、用量投入到了生产中。但是售后维护部门，就需要根据每批产品的序号，BOM数据的维护历史等，来维护售后的产品。设计部门也要根据这些实际数据，来不断优化BOM。 咱们举个例子，主数据是公司的花名册，历史/交易数据是员工每天的考勤记录。实际工作中，很少每天全员到岗，有的被借调、出差、请假等等各种情况。 四、尽调时可关注企业内部对产品的编码，是否统一。 统一产品编码是构建BOM的大前提。应该对所有产品进行统一的编码。 BOM包括产品内在属性的物料主数据，可以将BOM看作为录入了各种产品属性的“账簿”。 企业内部各部门沟通时，要想准确的传达如生产指示、订单、发货等关键信息时，仅仅靠某单一品种的名称，在产品丰富多样化的情况下，是难以区别的。 五、零部件是否也要统一编码？ 这是一个难题。有的零部件在设计部是零部件，在其他部门是物料。有时在设计新产品时，零部件又变成了物料等种种情况。 实际上，从工作要求上来讲，所有的物料都应该统一编码。个人猜测企业实操中，能把零部件也统一编码、维护的企业，真的不多。这里还是不多论述了。   六、关注企业在BOM中，如何将零部件实现通用化？ 其实这一点，本人认为是企业研发实力强、内部各部门有序配合的一个表现。 现在高端制造业研发设计，基本都告别图纸了，用到诸如3D-CAD这种专业绘图软件（计算机辅助设计，Computer Aided Design），比如：工艺管道、仪表流程、机械结构、建筑结构、建筑施工、机械产品构造、电子产品构造等设计图纸的绘制。 那么在研发的过程中，如何降低成本、引进轻量化、廉价化的零部件，就是对设计部门的考验。最终想达到的目的是，相同品质的产品使用更少、更便宜的原材料和零部件。   七、关注企业在BOM中，是否以及如何构建BOM中的“顺序、母子关系”？ 为什么会提出这个问题呢，因为这就是工艺路线。这种BOM中的物料母子关系、顺序，系统描述了具体哪一种材料从哪儿采购、通过什么工艺路线/步骤，最终形成产品的全过程。 一般来讲，在结构上，BOM的“母子关系”（从上至下、总分）是：产品→零部件→副产品→原材料/物料。这些都是可以在专业绘图软件中录入。 八、关注企业的BOM数据，由哪个部门录入、维护。 这是一个老大难题了，实践尽调中，发现是企业内部互相扯皮的一个重要点，因为工作量很大、很繁琐。当然通过观察，可以了解到BOM信息的维护程度、企业管理层对研发设计是否真正重视和理解等。 （一）录入、维护BOM，不能只靠一个部门。 举例，BOM中的制造零件表，最早由设计部制作，包括机械、电机、控制等几类，还按不同类别进行编码，这后续将与多个生产部门关联。设计部设计具体工序、生产步骤，并将制造零件表嵌入到产品设计图中。然而，在实际生产制造过程中，某一道工序需要新的零部件或原材料，这个时候企业内部由谁来负责维护、更新这些BOM，就会很有意思了。一旦因为这些扯皮的事耽误工时，产品的良率、最终交付，都会受到影响。 （二）录入、维护BOM，应当遵循发生源输入原则。 这个原则，可以理解为在情况发生的位置输入，目的是为了保证数据的“新鲜度”、同时权责相关联，便于执行。举例，前几道工序的数据，让后一道工序的部门来负责输入、维护，谁也不会心甘情愿干，最终结果就是数据的滞后。 （三）录入、维护BOM，应注意在各部门之间的项目/产品编码，是统一的。 不要觉得这个问题很肤浅。实践中，因为各部门只负责各自几道工序或产线，很多对同一零部件、半成品的编码是不一样的，甚至还有一个“零部件编码对照表”。而这个对照表也是要维护的（哭脸），时间长了，很容易对不上。 （四）合理分工…

引言 　　BOM与业务的关系，历来是一种若即若离的关系。虽然有人认为BOM很重要，但更多的人认为BOM管得好、管不好也就那么回事，因为BOM似乎并不与企业的利润、竞争力直接相关。 　　事实上，BOM管得好的企业，BOM思想已经融化在整个管理体系之中，像水中的盐，只知咸味而不见盐的存在，企业高效运作背后，BOM早成了“无名英雄”，看不出其与业务绩效的直接关系。正是由于这种关系并不直观、直接，导致很多企业其实很难真正对BOM给予足够的重视。 　　完美体育WM如果从OTD的角度深入思考以下场景，也许情况就大不一样了： 　　首先，完美体育WM期望可以将完美体育WM的产品完整、准确地呈现在客户面前，供客户选择、引导客户选择。有哪些产品、每种产品有哪些配置项、哪些是标配、哪些是选配等等。 　　其次，客户选择完美体育WM的产品，往往期望能够立刻知道价格。那完美体育WM就得根据客户所选的产品配置，迅速知道导致价格差异的零部件清单，以便能够参考零部件成本迅速定出合理的产品价格。 　　第三，客户点好订单，希望完美体育WM能够迅速告诉他们订单是否可行、如可行需要多长时间交付。因此，完美体育WM期望客户选出来的东西最好能够落在完美体育WM的最大化设计（包括模块及产品组合）范围、生产准备范围之内，这样才能够保证最快把产品生产出来交付给客户。 　　第四，即便客户有特殊要求，完美体育WM也能够快速识别满足该产品的基本零部件清单，然后专注于通过专用件的设计满足特殊需求，而不需要在基础产品上花费过多的时间和成本，从而保证能够尽可能缩短交付周期、降低成本。 　　第五，为了提高完美体育WM设计和生产准备的命中率，完美体育WM期望有很好的产品规划、产品组合管理，能够更精准地吸收客户需求、预测客户需求。 　　第六，为了在更低的成本下满足更多的需求，完美体育WM希望能够实现更多的产品组合，进而能够进行模块化的设计，基于最大化设计进行虚拟验证。这样产品才会足够丰富，满足更多的个性化需求。 　　第七，完美体育WM希望工艺设计更为高效，一张工艺卡片不只是描述某个单一配置产品的单一零件。 　　第八，完美体育WM希望售后维修时能够精准定位到维修件，准确提供备件。 　　以上过程可谓涉及到产品研发以及OTD交付的各个方面，从销售到定价一路反向追溯，对销售与生产预测、生产准备过程、工艺设计过程、产品设计、成本管理、产品规划等等都提出了“理想化”的、但至为合理的需求。当完美体育WM看到这些需求的满足和BOM管理水平密切相关的时候，也许完美体育WM对BOM的重视程度才能够真正上一个台阶。 　　在当今社会，制造业在智能化、互联网化的大环境下，都面临着巨大的转型。完美体育WM所面临的竞争环境比以往任何时候都在呼唤企业按照上述“理想化”的模型进行转型。 　　管理高效的企业，BOM体系内嵌于产品研发与OTD流程之中，成为人体的血液、成为呼吸的空气，因此“没有BOM怎么行”是他们对于BOM系统的重要意义的回答。 　　与之相对照的是，有很多传统的、落后的制造企业，年复一年地重复着并行工程、模块化设计等概念而不落地，却在始终叩问BOM的意义何在。 　　因此，在当今这个变革的时代，完美体育WM所要强调的BOM的意义，不再是一些技术管理的要素，比如信息可追溯、减少数据重复输入、保持数据一致性等等。完美体育WM只有从推动业务转型的角度来看待BOM的基础支撑作用，才可以说真正将BOM摆在了企业体系建设的正确位置。 　　当然，在这里不是说这些技术管理要素不重要。恰恰相反，这些要素仍然非常重要！但只有从BOM更高的定位角度来对待这些问题，这些问题才能够迎刃而解、不解自解，否则就走向完美体育WM过去十几年甚至几十年的头痛医头脚痛医脚的老路。 以BOM的变革为引擎推动业务变革 　　第一点，大规模个性化制造要求的最基础、最本质的能力在于低成本、高效率运作。 　　第二点，大规模个性化定制是一个非常传统的话题。上世纪八十年代末、九十年代初就有了大量的研究。但时至今日，当完美体育WM在探讨智能制造的时候大规模定制却被列为新兴业态，且是智能制造成熟度达到5级的水准。 　　以上的两点给了完美体育WM一些启示：一个概念从提出到现在至少二、三十年的历史，而目前仍处于“新兴业态”，说明大规模个性化制造其难度非常之大，大到可能超出完美体育WM许多人的设想。而其最根本的难点在于低成本、高效率运作。 　　低成本、高效率的运作说起来很简单，但实际上对企业的各个层面要求都非常高。产品开发、产品交付的各个环节，牵涉到的人员非常之多，如何把事情一次做好，或者至少在开始的时候做得尽量好非常关键。BOM在这一多部门跨价值链协同过程中无处不在，支撑着关键业务的开展。 　　下图表达了BOM与全流程业务活动之间的关系： 图1BOM与全流程业务活动之间的关系 　　在产品规划阶段，重要的业务活动包括产品规划与产品组合管理、成本及重量目标管理以及先期采购规划等活动。市场需求需要转化成为产品规划的要素，规划配置表在此过程中扮演重要作用，负责将市场的要求沉淀成为对新产品的装备要求，同时实现规划内容向设计的传递，成为产品设计的重要输入。 　　通过早期BOM驱动成本和重量的目标规划工作：在早期阶段有BOM的支持，才能达到成本和重量管理的必要的精细程度，为面向成本的设计服务。而BOM的构建过程本身是研发、采购、工艺不断确定制造加工深度的过程，在此过程中确定每个零部件的采购/自制策略，形成采购业务的工作基础，以便于进行先期采购项目管理工作。 　　由此可见，基于规划驱动BOM尽早产生，通过BOM这条信息索引驱动产品开发早期的各种业务协同活动开展，推动业务变革，使得这些先进的业务实践能够在企业落地。 　　在产品设计阶段，好的产品设计需要具备基于产品系列进行设计、数字化验证的能力，需要模块化设计能力以及需要面向成本的设计能力。一切产品数据都需要以系列化的产品为基础才与设计活动本身相匹配，从而达到高效运作的效果。模块化设计中模块的组合关系如果能够基于BOM中的配置关系进行自动组合再供设计人员选择，将使得模块的管理更为简便。 　　而反过来，如果模块能够沉淀成为BOM的配置层级，将简化配置管理、并能够与销售和定价建立更直观的联系。一个产品的成本绝大部分在设计阶段就已经确定，因此“低成本”的关键在早期阶段对成本的管理，面向成本的设计要求在产品设计阶段能够不断对产品的估计成本与目标成本进行比较，以及时采取相应的设计改进措施达成成本目标。在这一过程的复杂性还表现在大量的变更需要考虑进来，如果缺乏对BOM的高效管理，那么面向成本的设计就会变成空中楼阁。 　　在工艺制造阶段，如果产品按照系列化进行组织，即以配置化的超级BOM模式组织产品数据，那么工艺卡片本身也可以融入配置化管理体系之中，通过配置元素增加每张工艺卡片的适应性，提高工艺设计的效率。 　　在生产物流阶段，精益化生产、物流拉动和精准的投产生效控制都是提高生产运营效率的最佳模式，而这一切首先是以研发、制造一体化的BOM管理模式和闭环的变更管理模式为基础的业务运作。 　　在售后支持阶段，准确的备件技术定义是备件供应链运行的基础，只有及时定义备件，备件的寻源定点、采购、备货工作才能及时开展。 　　对于OTD流程而言，BOM的变革将会带动销售预测方式、定价、产品销售方式朝着更先进的模式进行一系列变革。如全配置模式的BOM管理将促使销售预测、生产预测模式按照配置项进行，通过超级BOM计算零部件毛需求。 　　通过基于工程配置以及销售策略定义的销售配置，成为基于选装进行销售定价和销售点单的基础，从而使得直接反映产品设计的菜单式销售成为可能。在订单实现方面，全配置BOM模式是优化订单排程的基础。 　　在整个价值链的运作环节中，客户既是起点又是终点。对外而言，完美体育WM谈论的是客户的要求、客户对于产品规格、产品配置的选择；对内而言，完美体育WM谈论的是零部件设计、物料筹措。而BOM将是将这两套语言直接无缝联系起来的唯一方式。因此，打通客户端将是BOM终极价值的体现，将使得制造业真正超着低成本、高效率运作迈上一个新台阶。 支持关键业务能力建设需要什么样的BOM系统？ 　　如上文所言，大规模个性化定制需要的最核心的能力是低成本、高效率运作的能力。如何达到这一能力要求呢？下文完美体育WM试图对这一核心能力进行分解，并从这些分解的业务能力来看对于BOM的要求。 　　首先，面向产品族的产品管理以及产品设计能力非常重要，因为这是保证完美体育WM创造足够多的正确的产品的前提。同时，这一产品族进行规划的思想要贯彻到生产准备过程和销售环节。 　　这一业务能力建设对BOM系统的要求是：BOM的构建必须是全生命周期的配置化管理模式。这样，才能够保证在产品开发的任何阶段，以BOM为主线的管理单元是一致的，从而能够保证上下游衔接的一致性。 　　全生命周期的配置管理包括规划阶段的规划配置管理、设计阶段的工程配置管理、生产准备阶段以及生产阶段的生产配置管理、销售阶段的销售配置管理。BOM系统需要保证这一系列的配置管理之间的关联性，而BOM本身的准确程度正是基于这些不同阶段的配置数据进行解析的结果。 　　第二大业务能力是模块化设计能力。模块化设计本质上是一种产品设计的思路、规划或者方式，而不是一种数据组织的方式，对完美体育WM的设计水平和设计工作的组织能力要求都非常高，且是一个没有止境的过程。 　　国内许多企业将模块化停留在数据组织上，很难取到模块化的真正效果，是一种缘木求鱼的做法。但好的BOM组织模式确实可以支持模块的规划，提高模块化设计的效率，而且模块化的结果需要由BOM来承载。 　　因此，从模块化设计能力建设上，对BOM系统都要求可以概括为：BOM的定义方式需要支持模块规划与定义，具体能够做到以下三个方面的内容： 　　配置特征与产品结构管理，支持各模块产品设计配置方案的前期规划。 　　通过工程配置辅助计算模块设计方案配置组合。 　　模块作为BOM的配置层进行定义。 　　第三大业务能力是并行工程能力。缩短产品开发周期、提高产品交付响应速度离不开部门之间的良好协同以及同步工作的能力，但这一机制的建立并不容易，因为当缺乏必要的信息基础的时候，并行工程往往会导致工作返工、浪费以及员工之间的抱怨。 　　并行工程的一个前提是信息是充分共享的，且信息是有一定质量的信息。而代表各阶段产品构成的BOM信息无疑是重中之重的信息。 　　从并行工程的角度而言，对BOM的要求是：BOM必须在相关部门开展业务之前产生，驱动业务工作的展开，因此BOM要尽早产生，因此BOM不只是设计的自然结果，而是规划驱动产生的结果。 　　且在业务进程中需要有好的共享方式，特别是在早期变更频繁发生的情况下，让相关方轻易地获取BOM信息，同时一目了然地知道与上次获取的BOM差异所在将大大提升相关部门并行开展工作的可行性。 　　第四大业务能力是与客户互动、沟通的能力。互联网浪潮下的C2M、C2B等模式，都在强调客户的参与。正如前文所言，打通客户端是BOM的终极使命。那么，从这个角度而言需要什么样的BOM呢？ 　　下图揭示的是一个简单的客户点单行为对BOM的要求： 图2客户点单行为对BOM的要求 　　第五大业务能力是柔性制造能力。从上世纪八、九十年代的计算机集成制造到现在的智能制造，柔性制造能力一直都处于核心地位，因此其重要性不言而喻。而柔性制造与BOM的关联更为直接。事实上，传统制造业所面临的BOM问题主要是如何解决生产制造领域由于BOM质量问题带来的生产问题。…

2016年，住房和城乡建设部发布《关于进一步推进工程总承包发展的若干意见》，提出深化建设项目组织实施方式改革，推广工程总承包，提升工程建设质量和效益。此后，《建设项目工程总承包管理规范》（GB/T50358–2017）、《建设项目工程总承包合同（示范文本）》《房屋建筑和市政基础设施项目工程总承包管理办法》（以下简称《管理办法》）等一系列文件陆续发布，提高了建设项目工程总承包管理水平，促进了建设项目工程总承包管理的规范化，不断培育和扩大了工程总承包市场。 《管理办法》的出台，确立了设计和施工“双资质”制度，要求工程总承包单位应当同时具有与工程规模相适应的工程设计资质和施工资质，或者由具有相应资质的设计单位和施工单位组成联合体。联合体模式已成为建筑业企业开展工程总承包的一种重要承接模式。然而，在实践过程中，如何充分发挥设计与施工联合体双方的优势，实现工程总承包项目控制造价、节约人力、缩短工期、降低风险的目标，成为联合体各方亟待研究的重要课题之一。本文以中建一局集团建设发展有限公司所承接的联合体模式下工程总承包项目为例，从联合体合同模式、内/外部协调管理等方面，对联合体模式下工程总承包项目管理展开探讨，以期为工程建设从业人员提供参考和借鉴。 联合体合同模式的管理 发包及结算模式 对于工程的发包模式，由施工单位与设计单位组成联合体，由施工单位牵头，建设单位完成初步设计之后进行发包。对于投标报价，建安工程费用招标控制价为最高投标限价，工程总承包单位在此基础上进行下浮报价。对于合同结算，合同执行期间，按照“建安工程费=审定的建安工程费用预算价×建安工程费中标下浮率”执行，并以此作为进度款拨付依据。 合同界面管理 施工界面管理。项目的施工承包范围包括土石方工程、基坑支护、建筑、结构、常规机电、消防、泛光照明、景观及市政配套工程、建筑室内设备设施、人防等全部施工设计图纸及工程量清单等有关资料范围内的工程总承包，商业室内装修、高低压变配电、电梯的采购与安装、样板房室内软装等内容不包含在工程总承包施工范围内。 设计界面管理。其主要为设计主体是联合体设计单位和业主独立发包设计单位的界面管理。为做好设计界面分工管理，具体设计界面分工内容如表1所示。 表1 设计界面分工内容 联合体内部协调管理 联合体协议 在工程总承包项目中，联合体各方应共同与发包单位签订工程总承包合同，联合体协议作为各方工程总承包合同的一个部分。 联合体协议中还应进一步明确以下几方面的内容：一是进一步明确联合体各方的工作范围、职责，约定各方应该承担的责任；二是制定联合体内部沟通配合机制，设计管控流程；三是梳理专项设计界面，明确各专项设计单位、图纸审查各方职责及设计费用分担情况；四是编制全专业、全过程的设计进度计划，在满足合同、现场施工进度前提下，预留审图、图纸调整的时间；五是细化联合体双方的违约责任，保证与主合同一致性或更为严格。 设计院的协调管理 制定沟通协调机制 如何协调好设计院与施工单位之间的沟通，实现设计与施工的对接，是工程总承包项目设计管理的重点。而在设计阶段，设计院及施工单位在设计协调管理工作中沟通协调机制的制定和有效执行，是项目成功的关键。 联合体沟通机制确定的事项。在制定联合体沟通机制中，需主要确定以下事项：一是需明确联合体双方需提供的资料，如建筑与其他专业设计互提资资料、业主提资设计院的设计相关资料、各专业计算书、模型等，便于施工单位了解设计情况。二是依据设计进度计划，商定过程版图纸的提供时间节点。施工单位参与施工图审图工作，以施工的角度提出建议，保证后期施工顺利。同时，确定施工单位提资图纸优化建议的时间及设计院反馈时间，形成周期性管理。三是文件传递采用公共邮箱的形式往来文件，方便管理避免混乱。四是设计院与施工单位双方须确定特定的对接人进行资料的传递，可简化流程，避免资料或问题的重复提出等。 设计过程中的执行与审核。在联合体机制约束下，双方应严格执行联合体协议。双方定期互相提供进度报告，并按总承包合同规定的里程碑计划时间和节点，动态审核双方执行情况。施工单位可依据图纸审查设计院对施工单位提出建议的落实情况，避免过程中有遗漏，保证设计管理工作的效果及工作效率。 设计质量管理 联合体模式下的工程总承包项目，设计院的设计质量管理应满足《建筑工程设计文件编制深度规定（2016版）》的深度要求、满足工程总承包合同中《设计任务书》的设计要求、满足施工单位的优化建议及设计施工融合的修改要求，并通过过程中的动态监控，将这些内容在图纸中明确。 对于设计图纸质量，项目的上位要求、规范图集的符合性主要由设计单位控制。从组织角度来讲，总包单位的设计质量管理包括设计单位设计质量控制体系是否健全、设计人员配置是否满足要求等；从业务角度来讲，主要包括发包人建设标准一致性、施工可行性及简便性、设计方案成本合理性、图纸错漏碰缺问题、其他合理化建议等。 施工单位对设计图纸的审核常见控制点包括以下几方面内容：项目材料品牌技术性能是否满足发包人要求；材料的可施工性和对项目工期影响；项目总平面布置是否易于现场施工组织；项目主体设计能否满足项目施工临时措施要求；场地竖向设计及土方平衡设计是否合理；图纸深度是否满足相关规范要求，为避免引起结算争议，减少图集参考，要明确材料实际参数；图纸是否存在各专业不交圈问题，平立剖面不交圈问题；综合考虑工期、成本、品质多方面考虑，是否有推荐新材料、新做法建议。 总之，工程总承包单位应把控好设计阶段的质量管理，为项目顺利履约及策划创效起到积极的助推作用。 对设计院的进度风险管控 工程总承包项目管理是从设计出发，将设计、采购与建造融合为一体。在设计阶段，进度风险主要分为两大方面： 一是明确设计实施条件。包括设计标准、功能定位是否明确，材料、设备等相关参数是否明确，限额设计指标是否限定，设计范围界面是否明确等内容。为推动设计工作的快速展开，这些设计实施条件需联合体双方及早确定。 二是设计组织实施阶段管理。在设计组织实施阶段，进度风险管控点包含设计院各专业间相互配合、执行的标准规范、设计图纸深度要求等方面。 另外，做好设计院的进度风险控制，通常需要通过联合体内部的审核与联合体约束机制来进行规避，应定期对设计院的设计图纸深度及出图的计划进行监控，以规避设计院的进度风险。 施工单位内部协调管理 各专业间的协调管理 在设计实施阶段，从设计说明、统一技术措施、专业间提资到过程版图纸，施工单位需开展机电、土建以及各专项的联合审图工作。将机电和土建交界面的层高控制等问题、机电管道和结构是否有碰撞等问题，书面提交设计院进行调整，同时与设计院相关专业做好协调、跟踪和确认工作。例如，在项目地下车库的设计阶段，土建、机电专业可依据设计院设计成果，借助BIM建模软件进行碰撞检查、管综优化。此外，加强各专业在设计阶段的联系，规避后期施工阶段交叉问题。 各部门间的协调管理 在前期设计阶段，施工单位相关部门应做好协调工作。一般来讲，对设计图纸的优化建议往往是由技术部门提出，商务部门和工程部门做配合。工程总承包是从施工的可行性、成本的可控性及实际施工效果等多方面对设计图纸进行优化，满足工程总承包项目合同需求，需要施工单位各部门配合牵头专业统筹协调各个部门和专业开展设计图纸优化工作。以防水做法优化为例，可先由项目技术部门收集当地其他同类型项目的防水做法，再交由商务部门进行询价，同步提交给工程部门咨询建议。在询价工作完成后，各部门召开会议进行沟通，技术部门说明各防水材料的性能及优缺点，工程部门说明实际施工的难易度及损耗率，最后由商务部门综合询价结果及各方意见提出方案建议，经技术部门将做法提供资料给设计部门审核，最终才能实现内部各部门间的联动，保证对设计图纸的优化意见满足各方要求。 对施工单位的进度风险管控 施工单位在设计阶段对每一版次的过程版图纸审图问题，应准确及时反馈给设计院，为设计院预留出足够的调整时间，保证设计时间节点，有效做好进度风险管控。 在工程总承包项目实施过程中，为了避免施工单位带来的进度风险，需联合体内部规定设计院给施工单位提交过程版图纸时间，施工单位对设计图纸优化并提出建议的反馈时间。从施工角度来讲，施工单位做好人力安排，统筹需考虑与设计院后续沟通、调整图纸的时间，避免对设计节点时间造成影响。 联合体外部协调管理 对优化单位的协调管理 业主所聘请的优化单位一般在方案或初步设计阶段便已介入，主要是对建筑、结构及机电专业的图纸进行优化。各专业的优化内容如表2所示。 表2 各专业优化内容 建筑优化设计工作主要是在前期方案或初步设计阶段进行，施工图设计阶段优化单位的工作重心在结构及机电专业的图纸优化上。因此，施工图设计阶段工程总承包方主要是对优化单位所提的结构、机电优化意见进行管控。 优化单位的取费依据业主方的限额要求，按优化量来计费，这就容易造成优化单位可能会为了减少工程成本费用而进行部分不合理优化。施工单位需要就优化建议与业主沟通，提前向业主说明参与优化意见的审核，以规避后期对施工的影响。同时，工程总承包方应提醒业主规定优化意见的资料提供时间，对优化单位进行约束，避免对设计节点时间造成影响。 对业主单位的协调管理 工程总承包合同中，业主对项目的施工图设计完成、施工许可证的获取、单体达到预售条件等一些重要时间节点进行控制。工程总承包方必须严格遵守节点时间要求，合理安排进度计划，避免逾期被扣罚进度款。值得注意的是，在设计过程中，业主往往会因建筑布局、外立面效果调整和选材等原因，要求设计院对设计图纸进行反复修改，占用了大量时间；施工单位的优化意见反馈较晚，也极易对设计院的设计进度造成影响，加大设计院的设计压力。为此，在设计阶段，需要加强对于业主单位的协调管控，及时采取规避进度风险。 针对设计阶段来自业主方的进度风险，总承包商需要提前对业主进行提示。由设计院说明因业主原因造成的进度延后的影响程度、调整所需时间，明确进度延误的责任主体，规避误期罚款的风险。 独立发包的专项设计协调管理 工程实施过程中，由业主方独立发包的专项设计，如电梯的采购与安装、高低压变配电、商业室内装修等专业单位未进场，可能会导致设计院的设计输入参数不准确。总承包商在前期就应协调业主方，提醒需让各专项设计介入设计阶段的工作，提供必须的参数，待后期施工图设计完成再进行二次深化设计工作。例如，电梯的专业参数可咨询同类型住宅项目的厂家，在初步设计阶段进行配合设计，如有二期的住宅项目，在电梯井道尺寸及基坑深度的参数上，需参考一期住宅项目的电梯厂家意见进行设计，避免后期专项设计入场后所做深化与现有设计内容产生冲突。 结语 联合体模式已成为建筑业企业开展工程总承包的一种重要承接模式，做好联合体模式下工程总承包项目管理，需要施工总承包企业与业主方和设计单位之间建立相互信任、优势互补、协作共赢的管理机制，及时做好设计指导施工，施工及时对施工图进行评阅等。在项目实施过程中，各参与方需遵守规范，加强沟通，联合体模式方能在高质量的轨道上稳步推进。 工程项目管理软件（EPC、业主甲方、工程ERP系统） – 【完美体育WM】领先专业项目管理软件商-工程施工、科研研发、基建投资大数据项目管理系统平台。 

  IPD的理论基础来源于PACE（产品及周期优化法），这套理论中包含了业界不错的产品开发模式所包含的各个方面，给企业带来的最为典型的收益体现在产品开发的生产力提高、浪费减少、投入市场时间缩短和效益大幅增加。下面作者从实践方面、理解方面以及企业层面讲解了IPD的经营模式，一起来看看吧。 苹果联合创办人史蒂夫乔布斯说过：“并行工程的目标,是为了提高质量、降低成本、缩短产品开发周期和产品上市时间。” 并行工程的具体做法是：在产品开发初期，组织多种职能协同工作的项目组，使有关人员从一开始就获得对新产品需求的要求和信息，积极研究涉及本部门的工作业务，并将需求提供给设计人员，使许多问题在开发早期就得到解决，从而保证了设计的质量，避免了大量的返工浪费。 同时期的华为创始人兼总裁任正非是这么表达的：“只有上帝做的东西才没问题，当时没问题，时间长了也有问题：客户有这样那样的需求，产品要不断地改进升级。” 以上，完美体育WM基本能看出一个领导者在企业生存发展的战略大局，对质量、成本、周期、协作、迭代等问题商的思考和见解。 而这些问题和本文要聊的IPD有着莫大的关系： 概念层面的IPD 实践层面的IPD 理解层面的IPD 与系统集成并无必然关系05与敏捷开发的关系 IPD适合小企业吗？ 一、概念层面的IPD IPD是英文（Integrated Product Development）的写，中文翻译为“集成产品开发”，它是一套产品开发的模式、理念与方法。 IPD的理论基础来源于PACE（产品及周期优化法），这套理论中包含了业界的产品开发模式所包含的各个方面，给企业带来的最为典型的收益体现在产品开发的生产力提高、浪费减少、投入市场时间缩短和效益大幅增加。 IPD的整体框架： IPD整合了客户需求、市场分析和产品开发，建立了需求和产品之间的联系，开辟了战略规划、市场分析和产品开发三者之间的渠道。 同时IPD在流程层面也进行了集成，在产品开发的过程中，整合了各职能部门的角色，以及集成了QFD、工业设计、项目管理、质量管理等。集成式的流程体系加快了产品开发，确保了产品的质量。 二、实践层面的IPD 在中国，IPD之所以名气这么大，是因为一直在传播两个案例：一个是郭士纳上任时，蓝色巨人IBM面临各种危机，是郭士纳引入IPD流程，让IBM起死回生。 另一个案例是IBM尝到了IPD流程的甜头，回过头来把IPD流程输出给华为，使华为在后面十几年实现了高速增长，一跃成为通信行业的霸主。 这两个例子因为和世界顶级公司IBM和华为相关，因此格外吸引人的眼球。 事情是这样的，1992年，IBM在激烈的市场竞争下遭遇严重的财政困难，公司收入停止增长，利润急剧下滑。 为了重拾竞争优势，郭士纳提出压缩一半产品上市时间、减少一半研发费用但不得影响产品质量的要求。 IBM在业界率先应用了IPD（集成产品开发）的方法，从流程重整和产品重整两个方面来达到缩短产品上市时间、提高产品利润、有效地进行产品开发、为顾客和股东提供更大价值的目标。 IBM实施IPD的显著改进在于: 花费在中途废止项目上的费用明显减少； 产品研发周期大大缩短； 产品成本降低研发费用占总收入的比例下降； 人均产出率显著提高产品质量普遍提高。 1997年，华为遇到了IBM当初遇到的问题,在战略管理和项目管理之间矛盾重重。当时的华为技术人员重功能开发，轻产品可靠性和服务质量。在1999年之前，华为已经出现了“增产不增收”的效益递减现象。 为了解决问题,华为自己摸索实施IPD，在遭遇失败后转向花费巨资请IBM实施IPD咨询。 为了确保IPD的顺利实施，任正非将IPD上升到了华为的生存层面，制定了“先僵化，后优化，再固化”的实施模式，连续投入大量的人力、物力和财力，最终确保IPD在华为的落地。 华为取得全球瞩目的成绩，与IPD有着不可分割的关系。 随后美国波音等公司也相继实施IPD并取得了较大的成功，IPD已经成为世界500强企业通用的产品开发流程和管理体系。 三、理解层面的IPD IPD的理论一套一套的，甚至晦涩。尽管看到成功案例。但是可以做自己的解读。 1. IPD的三个核心内容 其实IPD的核心内容是： 以市场为导向的产品开发，关注客户需求； 把产品开发在公司内部也作为一项投资来看待，建立了虚拟的投资决策委员会（IPMT），对产品开发团队（PDT）的活动在一些关键点上进行决策； IPD所建立的产品开发团是跨部门的，可以打破部门之间的沟通壁垒，并给出了跨部门业务流程指导跨部门团队运作。 本质就是如何把事情做正确： 2. 不是一套最终确定的流程 IPD是一套产品及研发管理的体系，是从产品投资与开发的角度来审视产品与研发管理的思想和架构。通过构建优秀的管理体系来达到提升产品管理与研发绩效的目的。 严格来讲，IPD是一套经营管理模式。是一套产品开发模式、理念和方法，包括许多不错的实践。 作为一种模式，其核心理念和思想是普遍适宜的。比如以投资为导向的决策，以市场为导向的创新，跨部门的功能团队等等。这些理念与企业规模可以说完全没有关系。 它不是一套最终确定的流程，实施IPD咨询的关键在于管理理念的引导，有针对性、完整的方案设计和落地实施。 但目前很多人，甚至包括某些咨询公司的顾问，将IPD理解为一套流程体系没有结合企业自身特点相结合，导致很多企业陷入“照搬照抄”的误区。 四、与系统集成并无必然关系 IPD是英文（Integrated…