导读 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) 实施难度不同…

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

MES和ERP两款系统，在生产制造届早已经名声响亮，但至今还是有很多人分不清这两个系统究竟有什么区别，下面就来讲解一下。 要区分两者，首先就要弄清楚它们是什么。 MES系统 MES全称为制造执行系统（Manufacturing Execution System），是位于上层的计划管理系统与底层的工业控制之间的面向车间层的管理信息系统”，它为操作人员/管理人员提供计划的执行、跟踪以及所有资源(人、设备、物料、客户需求等)的当前状态。 ERP系统 ERP全称为企业资源计划(Enterprise Resource Planning)，是一个对企业资源进行有效共享与利用的系统。相对于MES的“专一”，ERP系统更倾向于企业整体流程的管理，通过信息系统对信息进行充分整理、有效传递，使企业的资源在购、存、产、销、人、财、物等各个方面能够得到合理地配置与利用，从而实现企业经营效率的提高。 一、MES系统如何管理生产制造 MES主要应用在流程型和离散型两个方面的工业制造领域。 流程型制造行业如石油石化、化工、冶金矿业、制药和食品饮料等民生行业。 离散型制造行业如汽车、机械制造和电子通信等行业。 而在生产制造管理方面，MES系统主要从以下几个方面来进行： 1、过程管理： 监视生产过程，自动纠偏或为操作者提供决策支持以纠正和改善生产活动。它可包括报警管理。可能通过数据采集/获取提供智能设备与MES的接口。 2、质量管理： 及时提供产品和制造工序测量尺寸分析以保证产品质量控制，并辨别需要引起注的问题。它可推荐一些矫正问题的措施。也可以包括SPC/SQC跟踪、离线检测操作以及在实验室信息管理系统(LIMS)中分析。 3、设备管理： 跟踪和指导设备及工具的维护活动以保证这些资源在制造进程中的可获性，保证周期性或预防性维护调度，以及对应急问题的反应（报警），并维护事件或问题的历史信息以支持故障诊断。 4、产品跟踪和谱系： 提供所有时期工作及其处置的可视性。其状态信息可包括：谁在进行该工作；供应者提供的零件、物料、批量、序列号；任何警告、返工或与产品相关的其它例外信息。其在线跟踪功能也创建一个历史记录，该记录给予零件和每个末端产品使用的可跟踪性。 5、性能分析： 提供实际制造操作活动的最新报告，以及与历史记录和预期经营结果的比较。运行性能结果包括对诸如资源利用率、资源可获取性、产品单位周期、与排程表的一致性、与标准的一致性等指标的度量 6、物料管理： 管理物料（原料、零件、工具）及可消耗品的移动、缓冲与储存。这些移动可能直接支持过程操作或其它功能，如设备维护或组装调整。 MES系统建立起规范的生产管理信息平台，使企业内部现场控制层与管理层之间的信息互联互通，由此提高企业核心竞争力。 二、ERP系统如何进行生产制造管理？ ERP是一个统筹企业资源，并进行资源合理分配的整体管理系统，管理企业的人事、行政、销售、生产等多个环节。作为一个整体性的企业管理系统，ERP是如何进行生产制造管理的呢？ 1、制定生产计划 首先，制定切实可行的生产计划，该计划除了包含由销售环节转来的订单外，用户也可直接输入生产计划，如有紧急订单时，可通过追加临时生产计划，直接生成物料需求计划并下达到生产车间。 2、细分物料需求计划 “ERP”中生产系统根据企业的特点，将物料需求计划设计成正排产、倒排产两种方式。物料需求计划把生产计划细分为制造件的生产进度计划和原材料、外购件的采购进度计划，确定制造件的投产日期和完工日期，原材料、外购件的订货、采购和入库日期。生成车间订单和采购请购单，分别由车间作业系统和采购系统处理。保证生产过程中既不出现短缺，又不积压库存。 3、车间订单下达 紧接着，车间管理系统按车间订单下达日期，并分别下达到相应的生产车间。在车间订单下达的过程中，将配套生成相应的领料单、流动卡和工艺路线单等车间作业形成文档，同时，通知物料部门发料。 作业订单下达到车间之后，规定出一个开始日期和完工日期。车间定单中规定的作业时间不是纯工艺时间，它包含有管理时间，也就是说为该车间主任或调度留有一定节余时间，他们可以在权限范围内根据经验灵活调整各个定单的实际作业时间。 4、生产回报 尽管车间管理人员可以在定单规定的范围内调整订单的作业情况，但具体的完成情况必须及时回报计划部门。生产回报的方式很简单，填写每一道工序的流动卡即可。流动卡中规定了各个工序的建议时间和管理及技术要求，作业人员把该工序实际执行情况（实际开始时间、准备时间、加工时间、正品数量、次品数量和原因、作业人员和班次等）填入流动卡。 生产完工报告记录了各工序的实际耗费，并作为成本分析的依据，自动生成生产日报表，提供截止到当日的产品生产汇总信息。 即使ERP在企业管理方面比较强大，但是在生产管理方面确实也存在缺点，所以在生产制造行业人们一般都会将ERP和MES相提并论，相互配合使用。

任正非曾经说过：华为之所以有今天的世界级产品竞争力，其中一个很重要的原因是源于华为研发组织结构和治理架构的变革——2002年产品线的大变革，使研发组织彻底地从单纯的功能部门（大研发），变成了担负E2E经营职责和使命的产品线，这也是IPD帮助华为不断迈向成功的关键。 在华为，把研发体系按照产品来划分产品开发组织，将产品线定位成利润中心，按照利润中心的方式核算、考核、激励，是华为组织变革中非常有特色的运作机制。那么华为的产品线组织是如何产生和运作的呢？ 1. 产品线组织的产生 1.1 职能研发组织的问题 1.1.1 职能型研发部 在早期，华为针对产品成立了职能的研发部，在研发部下面设置了针对具体产品的开发项目组，开发出来的产品交到销售部进行销售。这种状态下，职责很明确，责任也很清晰。那么这里有没有问题呢？有问题。当市场竞争不力的时候，会得到两个组织这样的反馈：研发部会说研发已经做得很好了，就是市场上卖不出去，而市场部反馈是当前市场形势一片大好，就是研发做不出来，双方谁也不买账。 华为产品的实际现状是什么呢？当时华为做的早期交换机等有些产品，确实在市场上客户不认可。产品竞争力不行，大家都有责任，但问题怎么解决呢？ 1.1.2 大研发体系 经过一系列的思考，华为便开始逐步完善研发组织，起步建设大的研发体系，主要想解决三个问题：第一个是应当做什么样的产品， 把方向找到；第二个是能把想做的产品做得出来；第三个是能把想做的产品做好。 针对这三个问题，华为成立的大研发体系建立了三个组织。第一个组织叫产品战略研究规划办，它的职责就是负责回答要做什么样的产品，避免做错的问题。平时他们不断的研究市场，研究技术发展趋势，研究全球的竞争，研究客户的需求，目的就是一条，想做的产品就是客户想要的。第二个组织是中央研究部，它的使命就是负责把想做的产品做得出来，能够交付得上，使命必达。当时针对具体的业务特点，华为成立了无线产品业务部、传送产品业务部、交换产品业务等等一系列的职能研发部门，负责具体产品的开发。第三，产品开发出来未必质量好，所以又成立了中试部，不断地进行产品的测试和试制，反馈研发产品存在的在软件、硬件等方方面面的问题，使得中央研发部不断的对产品进行改进，让产品做得出来也能稳定质量好的状态，能批量供货，能够规模化生产。 这三个组织在当时的历史阶段，给华为公司带来了巨大的进步。同样地，这种研发组织形式也是非常多企业正在采用的组织形式。那么问题是不是全都解决了呢？没有完全解决。因为华为发现这三个组织还是段到段，“铁路警察各管一段”，当时面临三个新问题很难得到解决。 第一，当某个产品销售不好的时候，就发现没有人负责，哪个部门都有责任，但谁都不对结果负责。这涉及到端到端经营的问题。 第二，当客户反馈问题的时候，发现可能这个问题会跟市场服务、研发等等部门都相关，每个部门都认为是别的部门的问题，都不愿意去牵头协同解决，协同非常困难。 第三，当在制造环节发现产品的可制造性问题时，当在供应环节发现采购想上量或者供应弹性的问题时，当想降低安装交付的成本时，华为发现这些问题都不是单一部门可以解决的，都需要多部门的协作才能够解决，研发部门也必须要重度参与。 而这些问题要如何解决呢？需要设置一种新的组织形式来加以解决。 1.2 产品线组织 华为公司选择的路线是在传统的职能研发组织的基础上，向上生长孵化出产品线组织。 首先明确了产品线的定位，产品线要端到端对产品负责，把产品的经营和产品本身的竞争力真正的管理起来，并持续进行改进。端到端是指从客户需求端出发，到满足客户需求端去，提供端到端服务，端到端的输入端是市场，输出端也是市场。 完美体育WM把一个公司研发组织涉及的主要业务流环节都打开来看一下。首先最基本的产品开发职能是各个公司都具备的。同时研发组织还会承担一部分技术开发工作，还有一部分研究性工作，这也就是完美体育WM所称的专业研发部门。 一个广义的研发组织除了涉及上述内容，沿着业务流水平向前、向后看，向前要负责产品的规划，要对产品进行管理；在产品开发之后，还要对产品的营销上市甚至制造供应提供支持，最后还要支持产品的销售服务，而这些都需要研发组织进行支撑和管理——这一部分就需要有端到端的产品研发组织对它来进行负责。而这对于很多公司来说的确是一个巨大的挑战。 从下图可以看到，①就是完美体育WM常见的专业研发部门；②是承担了端到端（E2E）经营责任的产品研发组织，在华为叫做产品线 在华为，产品线组织不是凭空产生的，也是由职能的研发部逐步发展出来的。在最开始，华为只有研发管理部这么一个职能部门，沿着水平业务流建立了两个新的部门，一个是产品管理部，来解决产品规划、产品管理这方面的问题，让产品能够打得准；同时成立了营销工程部，解决产品做出来之后能够卖得好，能够高效上市的问题。 当然一个产品要做出来并上市交付到客户，不仅仅需要这三个部门，还需要制造、供应链、销售和服务等配合，而制造、销售、服务等，在一个公司经常是分解在其他大的职能部门之下的，为产品线进行支撑，这里用虚线的方式表示由产品线对它们进行管辖。除了这几个一线的业务部门外，为了支持产品的经营取得成功，华为又新建了两个支撑性组织，一个是财经管理部，一个是质量运营部，这两个组织能够对产品的经营损益、项目的管理、质量的持续改进以及高效的运营负责。 这些部门纷纷成立之后，一个产品线组织基本就生长完整了。它包括直线直辖的部门，例如研发管理部、产品管理部、营销工程部等等，也包括非直线而是用虚线方式管辖的，对应其产品线的制造、销售、服务等部门。这样产品线就能够对端到端业务流程进行管理。 2. 产品线组织的运作机制 看了上面产品线组织的示意图（组织阵型），你是否会有疑问：完美体育WM公司/事业部的组织架构也是这么设计的，华为产品线组织有什么特殊的呢？为什么它会成功？华为产品线组织是怎么运作的？ 2.1 IPD集成产品开发 华为产品线组织的成功，离不开IPD。华为从1998年开始引入IPD，在IBM 顾问的指导下，完成了首次试运行IPD 流程，产品研发总周期缩短了50%左右。随后进行产品线组织及运作大变革，使研发组织彻底地从统一的大功能部门，变成担负E2E职责和使命的产品线，并从组织到干部，从考核激励到运营管理体系上，完成了以产品线为运营中心的管理与组织变革。 完美体育WM总是听说IPD，很多企业也说“完美体育WM搞不了IPD”，什么是IPD呢？简单说，IPD，Integrated Product Development，集成产品开发，是一套产品开发的模式、理念和方法，对产品开发中各种最佳实践进行集成，实现对产品开发工作有效管理的理念和方法。IPD产品开发模式主要包括7个关键要素：①结构化流程；②跨部门团队；③项目及管道管理；④业务分层、异步开发与共用基础模块（CBB）；⑤需求管理；⑥投资组合管理；⑦衡量指标。 完美体育WM要反复强调，华为所说的产品开发，不是传统的职能研发部门（产品实现），而是指产品线组织，承担端到端经营责任。完美体育WM反复提到的“端到端（流程）”，具体包括了市场管理过程、需求管理过程和集成产品开发，如下图所示，覆盖了企业从商业机会到商业计划、商业开发再到商业兑现的商业实现过程。 引用《从偶然到必然》一书中的总结：IPD通过分析客户需求，优化投资组合，保证产品投资的有效性；通过运用结构化流程，采用项目管理与管道方法，保证产品开发过程的规范进行；通过业务分层建设并重用共用基础模块，采用异步开发模式缩短开发周期，降低综合成本；通过建立重量级的跨部门管理团队和开发团队，建立配套的管理体系来保证整个产品管理和开发的有效进行。IPD管理体系是用来保障IPD有效运作的管理支持系统，包括组织、角色与职责，考核与激励，决策与评审机制等。IPD把上面的所有各项业界最佳要素紧密结合起来，集成化运作，保证了产品开发的高效。 顺便提一下，上图的市场管理（MM，Market Manaement）是IBM1994年总结提出的一套面向市场的战略规划方法论和流程，华为从2001年开始应用市场管理MM方法论建立了战略管理体系，并取得了显著成效。IBM把MM从IPD体系中分离出来，将MM前三步骤的内容划分为战略意图，市场洞察，创新焦点、业务设计四个战略要素，将MM第四、五步骤中有关行动方案，组织及流程、人员及技能方面的内容，参照Tushman组织变革模型归纳为关键任务、组织、人才、文化及氛围4个执行要素，并强调由业绩差距、机会差距激发战略，通过执行关闭差距，从而归纳了了BLM框架和相关要素。2009年后华为从IBM引进BLM，按照BLM重构了战略规划（SP）流程，并纳入到DSTE（从战略到执行，Develop Strategy To Execution）流程体系中。 从价值实现的角度来看，华为的企业价值链模型（下图左）相对迈克尔·波特价值链模型（下图右）有了比较大的调整与创新。上面三个（从线索到回款LTC、集成产品开发IPD、从问题到解决ITR）是价值创造流程，下面五个是价值实现的支撑业务模块。顺便地，LTC是指从线索到回款进行管理地端到端流程，包括线索管理、验证商机、设计方案、投标、商务谈判、合同评审、合同签订、合同履行等环节。华为著名的“铁三角”运作机制就是通过LTC流程保证的。 IPD产品开发模式7个关键要素中，①结构化流程，③项目及管道管理，④业务分层、异步开发与共用基础模块（CBB），⑤需求管理，⑥投资组合管理都有专门的职能部门负责，与人力资源/OD关系密切的有②跨部门团队，⑦衡量指标。接下来，完美体育WM就重点谈一谈涉及组织、角色与职责的跨部门团队——重量级团队运作机制，涉及考核与激励的产品线组织的考核模式。 2.2 重量级团队 根据产品线组织示意图，产品线的具体管理机制是采取重量级团队方式，设置了IPMT和PDT团队来端到端拉通，进行管理。重量级团队IPMT（Integrated Portfolio Management…