软件产品研发管理体系

  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 系统验收…

BOM构建和产品定义

核心观点 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上维护配置条件的问题以及配置条件维护质量普遍较低的原因，正是因为没有从正向规划的角度理顺配置与车型、零部件之间的关系，而是从逆向的角度生硬维护的必然结果。…

3个行业案例：BOM的重要性

工厂BOM物料管理

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

联合体模式下如何做好工程总承包项目管理

工程项目管理软件（EPC、业主甲方、工程ERP系统） – 【华腾】领先专业项目管理软件商-工程施工、科研研发、基建投资大数据项目管理系统平台。 

产品懂IPD做企业级产品规划

  IPD的理论基础来源于PACE（产品及周期优化法），这套理论中包含了业界不错的产品开发模式所包含的各个方面，给企业带来的最为典型的收益体现在产品开发的生产力提高、浪费减少、投入市场时间缩短和效益大幅增加。下面作者从实践方面、理解方面以及企业层面讲解了IPD的经营模式，一起来看看吧。 苹果联合创办人史蒂夫乔布斯说过：“并行工程的目标,是为了提高质量、降低成本、缩短产品开发周期和产品上市时间。” 并行工程的具体做法是：在产品开发初期，组织多种职能协同工作的项目组，使有关人员从一开始就获得对新产品需求的要求和信息，积极研究涉及本部门的工作业务，并将需求提供给设计人员，使许多问题在开发早期就得到解决，从而保证了设计的质量，避免了大量的返工浪费。 同时期的华为创始人兼总裁任正非是这么表达的：“只有上帝做的东西才没问题，当时没问题，时间长了也有问题：客户有这样那样的需求，产品要不断地改进升级。” 以上，我们基本能看出一个领导者在企业生存发展的战略大局，对质量、成本、周期、协作、迭代等问题商的思考和见解。 而这些问题和本文要聊的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…

汽车售后SBOM管理体系构建

摘要：本文介绍了奇瑞汽车售后SBOM管理体系构建的背景、目标及业务流程设计、IT系统集成管理平台，以及体系应用与切换策略。该体系经过售后备件业务实践，实现了售后备件业务的效率提升、优化成本与提高售后满意度，提升管理能力并满足全球化售后市场的差异化需求。同时，为国内车企实施售后SBOM管理体系提供了实践案例和经验总结。 1前言 汽车售后服务管理水平不仅是消费者购车的重要衡量指标，而且也是各车企重要的盈利来源之一。随着国家对整车售后政策的日益重视，对车企的售后管理水平也提出了新的要求。对于车企来说，提升售后及备件的体系能力及业务管理水平，已成为在激烈的竞争环境中生存及发展的核心竞争力之一。 完善的售后服务业务体系包含三部分[1]，即备件供应链运行流程体系、备件技术定义及供应商准备流程体系、工程变更支撑流程体系。相对于国外汽车企业相对完善的售后服务业务体系，自主品牌随着市场的成熟和新的管理体系的导入，尚处于逐步完善的过程中。 售后SBOM是根据汽车售后维修的需求，包含售后专用件、修理包、拆散件、电泳总成等，具备售后备件销售、订购、仓储、包装等业务指导的整车售后服务的物料清单。 本文全面分析和总结了奇瑞汽车售后SBOM管理体系构建的背景、目标及业务流程设计、IT系统集成管理平台，以及体系切换与应用策略，为国内车企实施售后SBOM管理体系提供了成功的实践案例。 2体系建设背景 奇瑞汽车企业级BOM管理平台通过全价值链信息集中维护，及关键业务系统的深度集成，已实现企业级统一的BOM管理体系，覆盖国内与海外研发中心，及国内全部工厂。作为企业级BOM体系建设的一环，售后备件业务尚未纳入到统一的BOM管理体系，见图1，主要存在以下问题： 1）主数据管理 •零部件启用新编码规则，但售后专用件无定义，影响保障市场备件需求 •备件拆分件号无数模，拆分件号状态及变更过程无法追溯，制图困难 •PDM系统零件属性不完整，售后无法确认零件具体状态如颜色、尺寸等信息，业务部门确认难度大 2）变更管理 •变更、切换传递渠道多，手工维护，人工跟踪，耗时，易错、漏，易造成终端用户抱怨 •切换断点控制不严格，经销商查询断点区域内车型零件时易错，造成错订和索赔 •变更影响通用性时研发未严格按照要求编号区分，经销商错订，索赔，售后未及时区分管理 3）SBOM维护管理 •SBOM解析结构为2Y结构，CGBOM为扁平化结构，通过参考EBOM/CAD结构转化，手动解析，工序繁杂、人工成本高； •EBOM与MBOM因断点和结构导致的差异，渠道确认差异件是否装车，是否需要定义到SBOM 4）图册制作 •零件数模获取困难，符合售后制图要求的数模图无获取渠道，制图周期长、覆盖率低 •外协件总成或散件无数模图，备件制图困难，经销商备件订购确认时间长。 图1售后SBOM业务流程现状 3体系建设目标 售后SBOM与EBOM采用配置化的超级BOM管理，并且与EBOM采用相同的管理单元，以实现售后和产品工程的同步开发，售后SBOM的集中管理和系统互通并支持下游关联业务为目标，建设以BOM系统为唯一数据源、变更系统为驱动的的业务/数据管理平台，如图2所示。 图2售后SBOM体系建设目标 1）构建配置化BOM管理模式的一体化售后SBOM集成管理平台，实现SBOM的精准定义与发布。 •基于企业级BOM管理体系拓展，实现EBOM、P/MBOM、KDBOM、SBOM一体化管理； •拓展EBOM管理范围，将备件专用件、修理包、电泳备件等纳入EBOM管理，实现广义EBOM定义与发布； •售后SBOM采用与EBOM相同的BOM管理单位，即房间定义； •售后SBOM包含整车的变更历史数据，用于追溯和订单管理； •实现全球一体化售后SBOM管理，包含国内整车、CBU、KD等。 2）构建分段闭环的售后变更管理流程，实现设计变更、制造变更与售后变更流程集成与闭环管理。 •设计变更的发起统一由产品部门负责； •设计变更、制造变更及产品停产时，要评估备件建储与切换条件； •售后工程师根据备件库存状态，确定切换计划时间、并执行售后SBOM变更及发布工作。 3）打通BOM系统与售后SBOM应用系统的集成，实现售后SBOM的单一数据源与高效应用。 •BOM与EPCM的集成，实现备件主数据及售后SBOM的集成传递。 •BOM系统与SAP系统集成，实现自制备件主数据的集成传递； •BOM系统与PDM系统集成，实现配置主数据及生产配置的传递； •BOM系统与变更系统集成，实现变更流程驱动备件主数据及售后SBOM的发布与变更； •PDM系统与EPCM的集成，实现售后图册数据的集成传递。 4业务规范与流程设计 EBOM中定义备件专用、修理包、拆分件等，由售后工程师结合自制备件及售后策略和维修需求，由系统实现EBOM的信息完整、自动传递到SBOM，包含配置条件；工程变更对EBOM的更改，以及制造变更对自制备件的更改，通过售后变更流程闭环、自动遗漏的传递到SBOM上，SBOM通过系统集成方式自动传递到下游的SAP及EPCM系统。 图3售后SBOM业务流程 售后SBOM业务流程见图3，以实现： 1)由产品研发工程师通过EWO进行EBOM数据的维护，定义ASLOU、ASLOA的结构，定义物料级别的Make/Buy。 2)工艺/制造工程师通过MWO维护备件的工艺数据以及生产切换信息（如果备件与整车生产的切换-关联时，需要在一个MWO中进行变更）。MBOM数据发布后，通过ERP集成接口传递物料数据和结构数据到ERP中以便组织生产。 3)售后备件工程师，基于前期的EWO以及MWO的数据，识别哪些是售后件，并通过SWO进行售后的SBOM中ASR数据的维护。在SWO完成后，将SBOM信息信息传递给EPCM进行图册的制作以及备件订购等数据。 5系统设计及集成框架 构建统一的BOM管理系统承担备件物料主数据管理以及数据发布切换管理，根据业务需要通过集成接口向SAP与EPCM等系统发送数据，以满足备件的采购、生产、销售。备件SBOM系统集成平台主要包括三部分，即BOM系统与SAP系统集成、BOM系统与EPCM系统集成、BOM系统与PDM系统集成。系统集成框架见图4： 图4系统集成框架图 5.1 BOM系统与SAP系统集成 BOM与SAP系统集成共包括两部分内容，即物料主数据及变更、BOM及变更。…