在开展EPC总承包过程中设计院财务遇到的相关问题 设计院转型牵头做EPC总承包业务，具有技术、人力资源、进度控制等方面的显著优势，但是也存在很多困难和不足。 财务部门作为项目的核算部门，参与了从项目开工到竣工验收的全过程管理，因而对设计院转型有非常重要的补充和促进作用。相对纯粹的设计业务而言，总承包（EPC）项目的财务风险、计价方式、合同关系、权利关系、分包关系和归责原则均有不同，从项目评估到工程施工，从工程款支付到日常开支，各种费用支付无不贯穿其中。设计院在工程总承包（EPC）项目的费用支付管理中，为实现资金的合理化运筹和优化配置，本着量入为出、有序支付的原则，就以下几个财务问题进行探讨。 ▌1. EPC总承包模式下如何做好保证金支付、履约担保 设计院单位应充分关注EPC总承包项目保证金支付的流程管控，保证金包括投标保证金、履约保证金和工程质量保证金。在招标文件保证金条款支付方式可选的前提下，应逐步改变传统转账方式，优先考虑以工程保函的形式支付。工程保函包括银行保函、保险机构保证保险和融资担保公司保函三种。投标保证金支付审批手续必须提早几个工作日完成，履约保证金和工程质量保证金需根据合同条款确定支付时间。EPC采用联合体投标形式的，联合体投标若约定由施工方承担保证金时，应先确认该保证金全款到账后再办理保证金支付事项。保函工作没有做好的话，企业就会面临非常大的资金压力，不利于后续各项工作的顺利开展，同时也应同业主单位做好充分的沟通，尽可能降低保证金的支付比例，减轻企业资金压力，提高资金使用效率。 ▌2. 保证EPC总承包项目建设资金、工程款正常使用问题 设计院单位必须要加强EPC总承包项目建设资金的控制和管理、防范资金风险、确保资金安全、提高资金的使用效益和效率。设计院单位承接的EPC总承包项目中标启动后，工程款支出因金额占比较大、支付频率较高等特点，应制定专门的支付审批手续。设计院单位应设立专门的EPC执行部门，由该部门组织编制项目收支预算表，财务部根据该预算表和合同条款，视不同情况编制现金流量计划，原则上应当在工程进度款到账后再办理该项目的支付流程和结算手续，根据实际情况决定具体方式。设计院单位应建立健全EPC项目建设资金、工程款管理和使用内部管理支付，形成动态台账管理，对建设资金、工程款使用情况进行日常监督检查，按规定接受审计和外部检查。 ▌3. 规范、预防和解决拖欠农民工工资问题 规范、预防和解决拖欠农民工工资问题根据《住房城乡建设部关于进一步推进工程总承包发展若干意见》，按照工程总承包EPC项目中工程总承包单位对工程项目的设计、采购、施工等实施全过程的承包，并对工程的质量、安全、工期和造价等全面负责的原则，经人社部门研究明确如下意见：工程总承包项目中工程总承包单位应负责农民工工资专用账户的开设。设计院单位应按照有关规定开设农民工工资专用账户，专项用于支付该EPC项目中的农民工工资。EPC总承包单位应当在工程项目部的现场配备劳资专管员，对于劳动用工进行现场监督管理，掌握施工现场用工、考勤、工资支付等情况，编制农民工工资支付表，并建立管理台账。EPC总承包单位应将农民工工资支付发放到农民工本人，并保证农民工工资及时足额发放。 ▌4. 加强EPC总承包项目专项专户管理 设计院单位应对EPC总承包项目设置专职财务负责人，分项目单独列账，明确各EPC总承包项目资金收支情况。尽可能实现收支两条线管理资金，让收入和支出变得更加明了清晰有条理，防止出现资金流失的情况。现场所有的费用支出应当进行相应的审批，根据EPC总承包管理部门编制的EPC总承包收支预算表来综合考虑支付，从而让费用支出更加合理、更加科学。EPC总承包项目涉及资金量大，资金存量及增值效益明显，应进一步梳理EPC总承包项目收付款流程，多部门联动建立制度化、流程化支付体系，扩大财务利润增值。 ▌5. 承接EPC总承包项目对财务人员的要求 设计院作为牵头人承接EPC总承包项目对财务人员提出了更高的要求，要求财务工作者在项目的投标、设计出图、项目施工生产过程、工程保修期结束等一系列的过程中参与管理。加强EPC总承包项目的财务管理，实施有效的成本控制，是科学细化施工企业管理的关键环节。 （1）EPC总承包项目涉及各个地区，不同的地区税务机关工作人员对税务相关法律、法规、流程的理解和解释都不一样。负责EPC总承包项目的财务人员必须要加强对税法条款的研究，做好纳税筹划，加强同税务人员的交流，在合法、合规、合理的前提下维护企业的正当权益。 （2）负责EPC总承包项目相关财务人员应当熟悉物资采购、设备采购的成本控制；熟悉施工阶段成本控制，深入研究施工图，在图纸交底会审时，有关管理人员向设计部门提出优化意见，可以直接降低工程成本；熟悉全过程的成本控制措施。 （3）负责EPC总承包项目相关财务人员应当参与到各个合同的签订中，这可以为事前监督工作打下非常好的基础。对于同一个合同，如何签订、选择什么样的结算方式都会对企业后续的税务方案确定产生影响，财务人员需要特别重视合同中有关税务问题的条款。 设计院财务应注重业财融合，参与EPC总承包项目的重点工作部署 为适应整个建筑市场的发展潮流，设计院单位应设立专门的EPC管理部门，谨记“安全—利润—可持续”的发展理念，持续夯实体系建设，将整个设计院中建造师等总承包资源纳入部门管理，在防控风险的前提下，积极联动整个其他部门，加快传统设计人员转型，组建成熟的管理团队，打造公司新的利润增长点，为公司可持续发展注入新的活力。设计院财务可以从以下几个方面参与重点部署相关EPC管理工作。 ▌1. 财务人员应参与EPC项目招投标评审管理工作 （1）增加对业主方工程资金来源、工程造价、付款节点等方面的评估，对项目联合体成员单位及业主单位的企业规模、资金状况也应有所了解，避免小业主大项目的履约风险。 （2）实施联合体投标的项目，原则上优先选择和公司有战略合作协议的施工单位，对于无合作协议的其他联合体成员必须严格评估其履约能力、类似工程业绩、团队负责人能力要求等方面。在参与EPC项目投标前，应当先签订标前联合体协议书后再递交投标文件。 （3）重点评审项目应建立会议流程，强化技术方案分析；各专业总工负责制，提出优化意见。加强评审，线上和线下相结合，注重线下标前评审，全面分析工程可能存在的各项风险点；线上OA系统为辅助手段进行严格评审，并及时将评审资料、评审结果归档。 ▌2. 财务人员应参与EPC总承包项目全过程管理工作 设计院财务人员对EPC总承包项目的管理应当是全过程的工作，应动态掌握业务的实施状况，审查及确定各专业界面，协调各子项、各专业进度及技术关系，研究并解决存在的问题。在EPC总承包项目中，设计工作起着主导作用，各种设计图纸和文件将成为采购和施工的主要依据。另外，需要加强变更管理的合规性，针对已实施项目，认真梳理项目合同内工程量，针对合同外可能产生费用的工程变更必须完善纸质签字流程，规避费用风险；应将采购管理纳入工程总承包的管理范围；增强全员风险意识，守好安全红线。对各标段、各阶段信息进行收集、整理、汇总和加工，提供宏观的、综合的概要性工程进展报告，为全过程管理控制提供信息支持，为多个管理层次进行组织协调和决策提供信息保障。EPC总承包项目全过程管理中对关键节点进行控制，各参与单位对实施反馈信息进行整理。 ▌3. 财务人员可建议设计院选择合适的EPC总承包项目管理软件 现代化的EPC总承包项目管理是一个大系统，各系统之间存在的关联性很强，需要储存和使用大量的数据和信息，且需要通过非常专业化的管理来处理各种复杂的关系。设计院单位转型升级从事EPC总承包项目，可以选择一套适合的管理软件，对项目预算编制与控制、项目计划与任务执行、资源计划与工时、项目收入、项目成本、项目利润、异常预警提示等实现各方面的实时管控。搭建业务基础信息共享平台，实现各个部门各个系统间功能模块的信息传递，使EPC总承包项目现场管理部门、设计部门、财务部门、经营部门等实现信息共享，更利于EPC项目的远程管控。继承项目预算管控，支持多端口应用，支持通过银企直连在线支付，发票自动查重验真，自动生成财务凭证，不再盲目审批，成本费用统计不再滞后。建立投标云、合同云、物资云、费控云、发票云、资金云、成本云、财务云、现场云、人事云、办公云等全方位的管理，为设计院转型做EPC总承包项目保驾护航，加快设计院企业管理转型升级。 ▌4. 设计院财务可建议院里加强专业人员团队建设 建立一个好的企业文化，打造一个优秀的团队，对提高企业的凝聚力、提高企业经济效益，具有非常重要的意义。设计院牵头做EPC总承包项目，对设计院内的设计师、设计项目负责人等提出了更高的要求。因此，设计院成功升级转型必须要建设高质量人才队伍，培养自己的团队，建立自己特立独行的企业文化以适应转型升级的需求。通过开展专业化培训、外派人员学习、专题讲座等方式提升设计人员的综合素养。同时，设计院也要提升招聘门槛，引进一些有工程商务、施工管理经验且懂施工图设计的人员，使设计人员与现场施工管理人员合二为一。总承包企业需要重新整合内部资源，采用各种方式激发设计人员的工作积极性，让每位设计师都能够具备成本意识，将设计院企业的设计优势转化为成本优势。设计人员、施工技术管理人员既要具备设计上的专业知识，还要有施工管理和现场应对经验，才能更好地适应当下的管理模式。 ▌5. 设计院财务应参与EPC总承包项目管理体系建设 当前我国的EPC总承包项目管理体系比较混乱，只有很小部分采用国际标准进行项目管理，很多项目管理体系并没有接轨EPC项目工程建设的实际发展。设计院单位应当进一步完善EPC总承包项目管理体系文件，早日打造成熟的EPC项目管理体系，已竣工的EPC项目应尽快录入“四库一平台”系统，助力单位完成产业升级。项目管理体系应包含工程施工质量管理体系、项目进度管理体系、总分包供应商责任体系，具有与质量计划相配套的质量责任制，能够反映以工序为基本单元的过程检验，包括设备、材料等的检验情况，能够体现以分项工程为主体的评定情况，落实监理、总包、分包、供应商等责任体系。 ▌6. 财务人员可建议加强EPC总承包项目执行过程中的文档、资料管理 由于EPC总承包项目的管理模式在我们国家企业应用比较晚，所以与之相对应的EPC总承包文档管理专业人员非常少。普通的档案管理人员大多只有档案专业技能，普遍缺乏工程项目管理的相关知识。在工作中无法参与到整个项目的全程跟踪中，在很大程度上影响了工程项目档案的归档质量。由于EPC总承包项目存在参与单位很多、工程资料很复杂等特点，因而EPC总承包的文档、资料管理工作存在一定难度。如何采取相关措施，保证EPC文档、资料的齐全完成和有效利用，这是我们必须要重视的问题。EPC总承包管理中各个单位、部门使用文档集中管理服务器，并具有快捷检索、查询等工具，能够按照预定的流程进行流转、审批、分包，有助于项目执行过程中竣工资料的整理和电子档案管理。EPC项目档案也应根据项目的特征，制定与之相应的文件收集制度，如果对档案收集工作不予以足够的重视，会导致一些重要的文件得不到收集、整理及归档，不能被有效利用。 综上所述，开展EPC总承包是设计院发展转型的一个必然阶段和必然趋势。EPC总承包模式下财务人员应注重业财融合，努力提高自身能力水平。

  EPC即为工程总承包模式，是设计采购施工一体化（EPC即Engineering(设计)、Procurement(采购)Construction(施工)）。 工程总承包是指工程总承包企业受业主委托，依据合同约定对建设项目的设计、采购、施工、试运行实行全过程或若干阶段的承包。（源自GB/T 50358-2017 建设项目工程总承包管理规范） 工程总承包的优势 对业主而言，与传统设计、施工分别招标的模式相比，EPC工程总承包模式的优势主要有： 合同关系简单清晰。EPC 工程总承包模式将过去分别签署的设计、施工、采购等多个合同简化为EPC工程总承包合同，合同主体简化，合同关系简单清晰，业主的建设过程管理责任、审计的工作量和风险源数量大幅度降低，有助于业主方管理的主动。 沟通渠道更为直接。EPC 工程总承包模式是集设计、采购、施工为一体的承包方式。通过这种将专业化程度高、彼此熟悉的各分工单位集合在一起的总承包模式，有助于减小沟通环节，提高项目工作效率和建设速度，科学合理分配项目工期，实现工程优化。 同时，由于EPC 工程总承包项目投标时，需要投标单位在编制投标文件时需要完成一定深度的图纸设计，投标单位的投标成本大幅增加，所以从一定程度上减少了肆意报名、无诚意的投标行为，一定程度上提高了投标的针对性和有效性。 适宜采用工程总承包模式的项目 建设内容明确、技术方案成熟的项目，适宜采用工程总承包方式。（引自住建部《工程总承包管理办法》） 工程总承包的招标阶段 业主应当在发包前完成项目审批、核准或者备案程序。采用工程总承包方式的企业投资项目，应当在核准或者备案后进行工程总承包项目发包。采用工程总承包方式的政府投资项目，原则上应当在初步设计审批完成后进行工程总承包项目发包；其中，按照国家有关规定简化报批文件和审批程序的政府投资项目，应当在完成相应的投资决策审批后进行工程总承包项目发包。（引自住建部《工程总承包管理办法》） 因此，采用工程总承包模式时，一般将设计分为两部分招标，一部分为方案及初步设计内容，在工程总承包招标前完成，一部分为施工图设计，包含在工程总承包招标范围内。 在项目建设总工期允许时，一般在初步设计完成，并完成初步设计审查后，进行工程总承包招标。 招标文件内容要求 业主应当根据招标项目的特点和需要编制工程总承包项目招标文件，主要包括以下内容： （一）投标人须知； （二）评标办法和标准； （三）拟签订合同的主要条款； （四）发包人要求，列明项目的目标、范围、设计和其他技术标准，包括对项目的内容、范围、规模、标准、功能、质量、安全、节约能源、生态环境保护、工期、验收等的明确要求； （五）业主提供的资料和条件，包括发包前完成的水文地质、工程地质、地形等勘察资料，以及可行性研究报告、方案设计文件或者初步设计文件等； （六）投标文件格式； （七）要求投标人提交的其他材料。 业主可以在招标文件中提出对履约担保的要求，依法要求投标文件载明拟分包的内容；对于设有最高投标限价的，应当明确最高投标限价或者最高投标限价的计算方法。 推荐使用由住房和城乡建设部会同有关部门制定的工程总承包合同示范文本。 （引自住建部《工程总承包管理办法》） 方案和初步设计单位可以参与工程总承包投标 政府投资项目的项目建议书、可行性研究报告、初步设计文件编制单位及其评估单位，一般不得成为该项目的工程总承包单位。 政府投资项目招标人公开已经完成的项目建议书、可行性研究报告、初步设计文件的，上述单位可以参与该工程总承包项目的投标，经依法评标、定标，成为工程总承包单位。（引自住建部《工程总承包管理办法》） 业主承担的风险 （一）主要工程材料、设备、人工价格与招标时基期价相比，波动幅度超过合同约定幅度的部分； （二）因国家法律法规政策变化引起的合同价格的变化； （三）不可预见的地质条件造成的工程费用和工期的变化； （四）因业主原因产生的工程费用和工期的变化； （五）不可抗力造成的工程费用和工期的变化。 具体风险分担内容由双方在合同中约定。 鼓励业主和工程总承包单位运用保险手段增强防范风险能力。 （以上引自住建部《工程总承包管理办法》） 合同与计量 企业投资项目的工程总承包宜采用总价合同，政府投资项目的工程总承包应当合理确定合同价格形式。采用总价合同的，除合同约定可以调整的情形外，合同总价一般不予调整。 业主和工程总承包单位可以在合同中约定工程总承包计量规则和计价方法。 （以上引自住建部《工程总承包管理办法》） 工程总承包模式的特点与管控建议 与传统设计、施工分别招标模式相比，工程总承包模式就是设计施工加设备采购的一体化，其他合同都是相同的，比如造价咨询、工程监理等委托服务以及市政配套等专项工程仍然由业主单独委托。 所以说，工程总承包模式中遇到的管控问题，在传统设计、施工分别招标模式中，同样会遇到。但因为工程总承包模式是设计、施工一体化形式，招投标范围和合同约定与传统模式存在的一定的不同，因此遇到同样的问题后，可能解决问题的方式不尽相同。 为了更好的分析解决问题，首先，从公平合理角度，我们对工程总承包合同双方各自应承担的责任分配分析如下： (1) 业主应该承担外部环境风险，比如需求变化的风险、比如政策风险、比如规范变更的风险、比如价格上涨的风险。 因为这些风险无论采用任何一种承包模式，都是承包商难以预料的，和承包商的管理水平、决策能力关联度不大，反而和建设时期所处的大环境息息相关。 对于这样的无论采用任何建设模式、选择任何承包企业，都会遇到和面临的问题，宜由业主承担为妥。 (2) 工程总承包方应该承担内部实施风险，比如管理风险、质量风险、安全风险、因图纸质量变更的风险、各专业设计之间冲突的风险、图纸与工程进度不匹配的风险等。…

PLM是一个企业产品开发信息化工作和管理系统，很多的企业更是利用PLM来实现商业战略的支持管理系统，所以PLM越来越受到企业的重视。不仅是制造行业，在建筑行业、餐饮等行业中，具有超前意识的部分企业开始实现产品工业化，过程中也开始应用PLM来管理产品的开发设计工作。 但是在许多的企业应用PLM过程中，总是会有各种困难和问题，应用和运行不尽人意。笔者从事过多年的产品设计开发工作，再后来也从事多年的PLM产品推广、实施交付、售后支持、案例总结等工作，对此颇有心得和体会。一般的内因是决定的因素，本文重点分析企业的自身的原因，希望能对相关的企业和用户有所帮助，走出误区和困境。 01 统一思想的问题 个人认为，上好PLM项目首要是解决思想认识的问题。许多的企业用户认为PLM只是一个研发设计提升效率的工具，如果在实施PLM项目后增加了用户的工作量那就不如不上。 不同的行业、同行业的不同产业链、同一个企业处在不同的发展阶段可能对的PLM需求程度和实施方案一般会存在一定差异。但是无论如何，一个企业想行稳致远，质量一定是高于成本效率首要目标。 产品的质量始于设计开发，而非制造生产。对于产品的设计研发而言如果需要确保设计输出准确并且长期稳定，就需要数据的规范和工作流程的规范。规范是产品设计研发管理的需求，也是PLM的核心理念。 一句话，质量方能行稳致远，质量始于规范。 PLM的数据和流程管理包含了规范的管理理念，对于大部分的企业而言上PLM系统不只是简单的把原有的工作方式和流程往PLM系统落地，更是要依托PLM规范、优化原来的设计管理。 由于规范带来的工作流程节点和内容的增加企业用户应该正确对待，必要时也可以要求增加角色来分担工作内容。而对于重复性的工作和输入，是信息化方案应该处理的重点内容和目标，也是通过优化完全能够解决的问题。 PLM能促进企业研发管理阶段的提升 总之，PLM提升对企业效率的提升是整体的和长期的，是以规范为基础的，因规范需要而增加的工作量是必要的。而且整体和长远来看，效率应该是提高的。 关于工作效率的问题只是PLM项目建设中思想分歧的典型的问题之一。帮助用户从思想上解决问题，是项目的首要问题。企业上下统一了思想，才能在项目过程克服困难继续向前，而非遇到一点问题就停滞不前，放弃一个功能板块甚至整个项目。 02 把握企业的核心需求 需求是无限的，而资源是有限的。我们需要集中有限的资源优先处理重要的核心的需求，再考虑其他的各种需求。 对PLM的功能需求应该是理性和客观的。通过一次PLM项目一步到位实现所有需求，一劳永逸的解决问题是一部分企业立项时的想法。企业的信息化过程是长期的，很难通过一次实施一蹴而就。甚至，许多的企业在深入对系统的应用理解后才了解到重点的需求。 PLM项目在企业的应用与拓展 因此项目的实施应该做好需求的整体管理规划目标，分阶段和期限的逐渐去实现。 对于真正影响工作效率的瓶颈功能： 🔹 能够通过IT方案解决的应该尽量解决，实现起来有技术困难的需要通过其他的业务方案降低影响； 🔹 对于易用的需求或者其他次要的需求，可以考虑在后续的优化中实现； 🔹 对于意义不大，解决成本高的需求应该及时放弃； 🔹 通过其他专业设计工具能解决的需求，在项目推进的前期应该优先考虑集成设计工具的方案，而非在PLM上开发替代功能的方案。 03 熟练操作PLM系统 其次是要让用户熟悉系统功能，熟练应用系统来完成相关工作。很多的设计研发部门用户以研发任务交期紧为由，拒绝项目的推行实施、或者参加实施过程的培训、甚至利用系统进行工作。用户熟练掌握系统是用户工作方式转换的基础，需要用户特别重视和项目实施的重点关注。 熟练的掌握应用系统就PLM而言其实并无太多的内容：图文档的上传，检入检出、物料的申请、变更流程处理、项目计划、流程发起及处理…… 项目的实施团队应该加强对用户的操作培训甚至考核，在上线后加强操作的指导。这样才能克服应用难和效率低的问题。有的企业PLM项目的部分功能在项目上线不久就没用了，有些是使用一段时间后逐渐弃用了。究其原因是不会用、不想用、从而不用。因此在技术人员流动的情况下，企业需要建立知识传承机制。 04 长期应用  深入优化 总的来讲，对于本身有很强研发管理规范和标准制度的企业来讲，上系统的难度要小很多，自然也更容易成功并长期用好。PLM项目是“一把手”工程，也是技术部门的全员工程。对于依托信息化系统来提升研发管理系统的企业尤其如此。 直白地讲，在PLM上线后的需要建立起或者有一个推动PLM系统的深入应用、长期应用的制度。离开制度的支撑，离开企业的意志，系统的应用会不断的弱化，甚至废弃。 坚持长期应用的基础上，会有更多的需求，这就需要不断优化，以最大程度地利用好PLM系统提升工作效率。 05 其他方面 解决好企业自身的困难和问题后，PLM项目的软件选型、交付团队的选型、蓝图方案设计等交付过程管理等非常的重要。 在这其中，相对而言选好交付团队尤为重要。实施团队中应该有业务分析规划、需求管理、系统配置开发各个方面的专业顾问。经验丰富的专业团队才能设计好蓝图，处理好实施中的各种问题。 总之，企业应该以提升研发管理体系层次、改善研发管理工作流程、构建产品知识平台和研发工作管理平台为PLM项目的首要目标，而非保持现有的研发工作方式不变的同时，提升个人所有工作的效率（现有的研发工作方式是否可以保留需要具体的去分析）。认识到这一点，有利于许多的企业上好PLM项目。

导读：关于BOM系统，国内汽车企业的一个传统做法是在PDM/PLM中搭建研发端BOM。在此基础上，各业务部门根据不同的业务需求，再衍生出BOM的其他形态，如制造BOM、售后服务BOM、KD BOM等。这种方式诞生的BOM往往是信息零散、缺乏规划的。   在实践中会发现，业务上的矛盾点频繁地、集中地体现在BOM上。这不仅引起了各业务部门对BOM管理的抱怨，还导致了业务部门在不同时点提出不同和BOM相关的要求，然后研发单位以BOM以外的方式进行应对。这种恶性反馈如果通过点对点的措施，无法根除问题，反而问题越解越多。 正是由于以上问题，车企在长期实践中探索出一条新的BOM管理思路——将BOM系统独立出来，用一种上下游业务链和产品完整生命周期的全局视角，规划搭建BOM主数据（工程BOM、制造BOM、售后服务BOM等），并通过配置管理和变更管理来保证不同形态BOM的过程受控。 纵观全球著名车企，大部分采用独立的BOM系统，而不是在PDM或PLM系统中管理BOM。而国内的情况也非常类似，很多传统车企经历了十几年PDM/PLM实践之后，最终还是将BOM独立出来，很多新能源车企更是一开始就将独立的企业级BOM系统作为首批重点规划的系统进行实施。 于是这就引出一个问题：PDM/PLM与EBOM同平台管理和异平台协同管理各有怎样的优劣点，为什么大多数车企在PDM/PLM系统外要建立一套独立的BOM系统？ 下面就两种BOM管理模式进行初步探讨。在探讨这两种模式之前，先就工程定义和采用关系这两个术语做一个说明。 工程定义：定义零部件物理设计特性（材料、尺寸、重量、质量要求等）及其二维、三维数据，它是设计BOM的核心内容； 采用关系：定义整车、零部件非物理设计特性（名称、数量、质量、颜色、配置等）及其结构关系，它是EBOM的核心内容。 “模式1：PDM/PLM与EBOM同平台管理” BOM系统：实现MBOM、售后BOM等其它形态BOM定义及发布。 PDM/PLM与EBOM一体化平台：通过和CAD工具集成，实现EBOM采用关系定义、工程定义，以及EBOM、三维数模、二维图纸的发布。 PDM/PLM与BOM间接口：通过PDM/PLM,EBOM一体化平台与BOM系统深度集成，实现EBOM视图向BOM系统的定期更新，保证PDM/PLM与EBOM一体化平台和BOM系统中BOM数据的一致性。BOM系统基于EBOM视图，开展MBOM、SBOM等其它形态BOM的管理。如图1所示： PDM/PLM与EBOM同平台管理，设计BOM即为EBOM，对设计人员最大的诱惑是，这种管理方式似乎有“工程定义和采用关系对接效率高”、“设计数据一致性好”、“省了工作量”等优势。但深入分析，便不难发现这种模式的局限性。 1.1 BOM结构冗余，变更管理复杂 在这一模式下，EBOM的诞生完全依赖于数据设计的成熟度，并且EBOM结构形式、组织方式与CAD结构十分接近。很多人认为这是这种模式的优势所在，因为这种模式下，工程BOM好像不必花力气去搭建，而是直接由CAD结构形成，能够保持与CAD结构的同步和一致性。但恰恰相反，这种EBOM，会给企业的BOM管理带来巨大的复杂性以及信息的不一致性，造成跨业务的信息壁垒。原因如下两点： 1.1.1 零件按照几何关系组织，降低BOM管理效率。 构建CAD结构主要是为了数模的组织、数字样机（DMU），往往在CAD结构中间搭建虚拟逻辑层级。虚拟逻辑层级的建立完全取决于是否需要承载几何位置关系。而EBOM的构建目的是为了各业务部门协同相关成本、采购、售后、工艺等方面的工作，其作用是跨业务领域的协同。如果EBOM也按照CAD结构这种模式组织，必然会带来大量的数据冗余。同时这些不必要的信息传递到上下游业务部门，必然带来信息使用时的困惑以及信息转化时的出错风险。 1.1.2 从精确装配的角度而言，对下层零部件进行更改时，需要层层锁定上层结构，甚至有的企业一直需要锁定到产品。 这给设计带来极大的麻烦，这就是业界典型的关于“变更冒泡”问题。如果EBOM采用与CAD结构十分接近的构建模式，那么这一“变更冒泡”问题必然会带到BOM领域，将产生大量对上下游没有意义的变更，同时大大降低BOM的发布效率。 1.2 造成Early BOM与EBOM是不同的两个BOM BOM是驱动相关业务活动展开的信息基础以及承载各业务领域活动成果的信息载体。从工程设计往前看，即产品规划、概念阶段BOM管理状况，由CAD结构驱动的EBOM显然不能覆盖这一要求。企业如果要管理设计之前的活动，需要另行搭建Early BOM。这种Early BOM必然与EBOM是完全不同的兩个BOM，中间不太可能有数据一致性的保障。 而从Early BOM、EBOM的作用和构建目的来看，二者应该是相同的，差别只在于对应的产品开发阶段不同。因此，理想方式应该是早期BOM与工程BOM从构建模式、BOM架构、承载信息上是一致的，只是针对不同阶段由于产品成熟度不同，控制方式有所差异而已。 1.3 整车开发各阶段BOM之间无法有效衔接 从工程设计往后看，即生产准备阶段BOM管理状况。由于EBOM从CAD结构而来，较少考虑物料层面的管理要求，必然与作为承载生产准备结果、面向ERP、MES等要求的制造BOM有非常大的差异。这种差异之大，往往导致MBOM是参照EBOM另外搭建的，二者之间的同步，特别是当变更发生的情况下的同步不太可能通过系统的方式达到。这种模式造成整车开发各阶段BOM之间无法有效衔接。 1.4 EBOM适用性存在风险 模式1将使商品化EBOM产品为满足业务个性化需求所做的适应性改善，相比独立定制化EBOM复杂得多。鉴于国内自主品牌乘用车研发领域业务成熟度尚且不高，EBOM的适应性改善在所难免，而改善是否成功，直接影响业务的运行，这个风险客观存在。 1.5 投资、运行、推广费用代价大 模式1的EBOM实施的投资及运行费用远高于定制化独立EBOM系统；因为，实施PDM/PLM/EBOM一体化方案将使超级EBOM的业务管理功能向PDM/PLM转移，这将增加PDM/PLM的投资及运行费用。我们应充分考虑到高昂的PDM/PLM与EBOM一体化方案投资及运行费用，以及未来推广时企业各应用板块的承受能力。 模式2：PDM/PLM与EBOM异平台协同管理 所谓“异平台“是指需要建立独立的BOM系统；所谓“协同”是指，兼顾设计与下游制造、生产、采购等环节对产品数据认知的一致以及全生命周期各环节BOM数据延续、贯通。方案示意如图2所示： BOM：由EarlyBOM自然成熟到EBOM，并由EBOM发布直接产生MBOM、SBOM等； PDM/PLM：建立图纸/数模与零部件号的关联，实现工程定义、DMU应用等； PDM/PLM与BOM间接口：通过PDM/PLM和BOM两系统间的高度集成，以BOM系统建立的EBOM结构驱动PDM/PLM系统CAD结构的建立。 图2：PDM/PLM与EBOM异平台管理模式简图 以下从3个方面阐述模式2相对于模式1在PDM/PLM系统和BOM系统建设上进行的改进和提升。 2.1 保证设计环节产品设计数据一致性 模式2通过BOM系统的EBOM模块向PDM/PLM系统传递零部件号、配置定义、结构等信息，实现EBOM结构与CAD结构、整车及零部件设计属性、版本的相对一致性（因为EBOM结构与CAD结构本就不可能完全一致，这一点在1.1.1章节已经做过论述）、发布流程的同步。 与模式1的设计过程在一个系统完成相比，模式2的设计过程需要在两个系统（PDM/PLM系统和BOM系统）完成，其用户体验显得略有不足，所以很多车企（如通用汽车，上汽乘用车，宝沃汽车等）分别设立PDM/PLM数据管理工程师和BOM数据管理工程师的工作岗位。 2.2 BOM系统全价值链贯通性 模式2可以使BOM系统从一开始就贯穿产品策划、工程设计、生产准备、售后等业务领域；支持企业的正向设计，以规划驱动BOM设计，使得BOM系统能够真正形成贯穿企业全业务流程的、全业务链的信息索引，并具备以下特点：…

  「 1. 数字孪生的一般定义 」 数字孪生是指针对物理世界中的物体，通过数字化的手段构建一个在数字世界中一模一样的实体，借此来实现对物理实体的理解、分析和优化。从更加专业的角度来说，数字孪生集成了人工智能(AI)和机器学习(ML)等技术，将数据、算法和决策分析结合在一起建立模拟，即物理对象的虚拟映射，以期在问题发生之前先发现问题，监控物理对象在虚拟模型中的变化，诊断基于人工智能的多维数据复杂处理与异常分析，并预测潜在风险，合理有效地规划或对相关设备进行维护。数字孪生是形成物理世界中某一生产流程的模型及其在数字世界中的数字化镜像的过程和方法(图1)。数字孪生有五大驱动要素——物理世界的传感器、数据、集成、分析和促动器，以及持续更新的数字孪生应用程序。 图1 数字孪生是在数字世界对物理世界的映射 生产流程中配置的传感器可以发出信号，数字孪生可通过信号获取与实际流程相关的运营和环境数据。传感器提供的实际运营和环境数据将在聚合后与企业数据合并，企业数据包括物料清单、企业系统和设计规范等，其他类型的数据包括工程图纸、外部数据源及客户投诉记录等。传感器通过集成技术(包括边缘、通信接口和安全)达成物理世界与数字世界之间的数据传输。数字孪生利用分析技术开展算法模拟和可视化程序，进而分析数据、提供洞见，建立物理实体和流程的准实时数字化模型，数字孪生能够识别不同层面偏离理想状态的异常情况。若确定应当采取行动，则数字孪生将在人工干预的情况下通过促动器展开实际行动，推进实际流程的开展。当然，在实际操作中，流程(或物理实体)及其数字虚拟镜像明显比简单的模型或结构要复杂得多。图2是数字孪生的概念框架。 图2 数字孪生的概念框架 「 2. 数字孪生与数字纽带 」 伴随着数字孪生的发展，美国空军研究实验室和美国国家航空航天局同时提出了数字纽带(Digital Thread，也译为数字主线、数字线程、数字线、数字链等)的概念。数字纽带是种可扩展、可配置的企业级分析框架，在整个系统的生命周期中，通过提供访问、整合及将不同的、分散的数据转换为可操作信息的能力来通知决策制定者。通过分析和对比数字孪生和数字纽带的定义可以发现，数字孪生体是对象、模型和数据，而数字纽带是方法、通道、链接和接口，数字孪生体的相关信息是通过数字纽带进行交换、处理的。以产品设计和制造过程为例，产品数字孪生体与数字纽带的关系如图3所示。 图3 融合了产品数字孪生体和数字纽带的应用示例 仿真分析模型的参数可以传递至产品定义的全三维模型，再传递至数字化生产线加工/装配成真实的物理产品，继而通过在线的数字化检验/测量系统反映到产品定义模型中，进而反馈到仿真分析模型中。通过数字纽带实现了产品全生命周期各阶段的模型和关键数据双向交互，使产品全生命周期各阶段的模型保持一致性，最终实现闭环的产品全生命周期数据管理和模型管理。 「 3. 数字孪生关键技术说明 」 基于数字孪生的智能制造系统如图4所示。 图4 基于数字孪生的智能制造系统 数字孪生的概念最早由密歇根大学的Michael Grieves博士于2002年提出(最初的名称为“Conceptual Ideal for PLM”)，至今有超过15年的历史。Michael Grieves与NASA长期合作。在航天领域，航天器的研发和运营必须依赖于数字化技术：在研发阶段，需要降低物理样机的成本；在运营阶段，需要对航天器进行远程状态监控和故障监测。这也是后来NASA把数字化双胞胎(即数字孪生)作为关键技术的原因。图5展示了数字孪生技术在装备行业的应用。 图5 数字孪生技术在装备行业的应用 数字孪生技术帮助企业在实际投入生产之前即能在虚拟环境中优化、仿真和测试，在生产过程中也可同步优化整个企业流程，最终实现高效的柔性生产、实现快速创新上市，锻造企业持久竞争力。数字孪生技术是制造企业迈向“工业4.0”战略目标的关键技术，通过掌握产品信息及其生命周期过程的数字思路将所有阶段(产品创意、设计、制造规划、生产和使用)衔接起来，并连接到可以理解这些信息并对其做出反应的生产智能设备。数字孪生将各专业技术集成为一个数据模型，并将PLM (产品生命周期管理软件)、MOM (生产运营系统)和TIA (全集成自动化)集成在统一的数据平台下，也可以根据需要将供应商纳入平台，实现价值链数据的整合，业务领域包括“产品数字孪生”“生产数字孪生”和“设备数字孪生”(图6)。 图6 数字孪生技术在装备行业的应用 在产品的设计阶段，利用数字孪生可以提高设计的准确性，并验证产品在真实环境中的性能。这个阶段的数字孪生的关键能力包含：数字模型设计，使用CAD工具开发出满足技术规格的产品虚拟原型，精确地记录产品的各种物理参数，以可视化的方式展示出来，并通过一系列验证手段来检验设计的精准程度——模拟和仿真，通过一系列可重复、可变参数、可加速的仿真实验，来验证产品在不同外部环境下的性能和表现，在设计阶段就可验证产品的适应性。产品数字孪生将在需求驱动下，建立基于模型的系统工程产品研发模式，实现“需求定义-系统仿真-功能设计-逻辑设计-物理设计-设计仿真-实物试验”全过程闭环管理，从细化领域将包含如下几个方面(图7)： 图7 数字孪生技术在装备行业的应用——产品数字孪生 在产品的制造阶段，生产数字孪生的主要目的是确保产品可以被高效、高质量和低成本地生产，它所要设计、仿真和验证的对象主要是生产系统，包括制造工艺、制造设备、制造车间、管理控制系统等。利用数字孪生可以加快产品导入的时间，提高产品设计的质量，降低产品的生产成本和提高产品的交付速度。产品生产阶段的数字孪生是一个高度协同的过程，通过数字化手段构建起来的虚拟生产线，将产品本身的数字孪生同生产设备、生产过程等其他形态的数字孪生高度集成起来，具体实现如下功能(图8)： 图8 数字孪生技术在装备行业的应用——生产数字孪生 关键指标监控和过程能力评估。通过采集生产线上的各种生产设备的实时运行数据，实现全部生产过程的可视化监控，并且通过经验或者机器学习建立关键设备参数、检验指标的监控策略，对出现违背策略的异常情况进行及时处理和调整，实现稳定并不断优化的生产过程。作为客户的设备资产，产品在运行过程中将设备运行信息实时传送到云端，以进行设备运行优化、可预测性维护与保养，并通过设备运行信息对产品设计、工艺和制造迭代优化(图9)。 图9 数字孪生技术在装备行业的应用——设备数字孪生 通过工业物联网技术实现设备连接云端、行业云端算法库以及行业应用APP，以西门子MindSphere平台为例说明运营数字化双胞胎的架构(图10)。该架构包含连接层MindConnect:支持开放的设备连接标准，如OPCUA，实现西门子与第三方产品的即插即用，并对数据传输进行安全加密。平台层MindSphere：为客户个性化APP的开发提供开放式接口，并提供多种云基础设施，如SAP、AWS、Microsoft Azure，并提供公有云、私有云及现场部署。应用层MindApps：应用来自西门子与合作伙伴的APP，或由企业自主开发的APP，以获取设备透明度与深度分析报告。预测性服务可将大数据转变为智能数据。数字化技术的发展可让企业洞察机器与工厂的状况，从而在实际问题发生之前，对异常和偏离阈值的情况迅速做出响应。 图10 数字孪生和物联网技术在装备行业的应用

和大家一样，本人也对中国工业软件行业持续疲软的现象有所不解，工业软件行业的甲乙双方，似乎始终都只能在PLM以及ERP等单一系统的圈子里厮混。多年前，本人参与了IBM发起的和SOA系统架构技术相关的各种吃螃蟹活动，并曾有过利用中间件技术为某个汽车制造企业构建一体化产品研发平台、以及为某个知名配套企业构建一体化营销平台的实战经历。令人费解的是，在当年中间件工具平台的基础上，当今的IT行业又新添了云计算、数据中台以及大数据平台等各种先进的开发工具，但我国的工业软件并没有因此而有所突破。本次征文活动仍然还是关于PLM系统应用技术的探讨，这多少也能反映出这一行业仍可满足于拿来主义的现状。中国的工业软件到底怎么啦，为什么拥有如此优越的开发条件，却仍然只能在原地踏步，为什么如此前卫的SOA架构技术，却始终无法进一步推广和普及呢。 一、关于企业业务及系统架构设计的谜团 因为持续的疫情以及持续高于40度的气温，本人只好一直躲在空调房中读书消遣，其中有一本亨利∙本格森的《创造进化论》给了本人很多启发。据此，本人编写完成了《企业进化论》的书稿，并将其发表在了小鹅通的知识服务平台之中。本人开始意识到，未来企业管理机器的设计理论体系，应该结合企业生命体进化理论基础来加以研究。企业在推动完成专业化能力建设的基础工程之后，能否进一步发展成为飞龙型企业，其决定性的因数，是在于企业能否形成整体协同以及运营管控的本能化作业模式，通俗地说，就在于是否能完成企业生命体的长、短链路神经网络系统的优化工程。下面这张图，便是经简化处理后的企业管理机器的示意图，大家不妨先理解一下。 本人认为，企业首先应该按照企业生命体的进化逻辑，来分析业务架构在不同阶段的能力建设需求，如缺乏这样的进化思维，则不可能勾勒出未来工业软件的发展规划蓝图。换句话说，企业如不能首先完成业务架构层面的重构设计，也就失去了利用一体化的系统架构技术，来实现所谓数字化转型的前提，这是本人回答上述困惑的第一个重要结论。理由很简单，不同的业务架构，代表的是不同的运营管控模式，不同的运营管控模式，则意味着不同的规范化设计，也就是说，企业的业务架构设计是系统架构设计的前置条件。当前，绝大多数企业还处于专业化能力的建设阶段，故仍都还在采用传统的、按专业职能区分的业务架构，这就是绝大多数企业只须关注单一系统建设需求的主要原因。 上图中表达的平台化的业务架构，就是未来企业必须首先完成的基础工程。该示意图中的四个一体化运营平台，可以理解为企业生命体的四大核心功能体。其中的供需链平台就是企业生命体维持新陈代谢能力的核心功能体，而产品研发和品牌推广两大平台，则是企业根据市场竞争条件、动态调整生存模式的智慧型功能体。如果说，上图中的产品研发平台就是企业管理机器的四大总成之一的话，那么，企业现有的PLM等单一系统，就只是该平台中的零部件而已。虽然，PLM系统已被称之为“产品全生命周期管理”系统，并已形成数据管理、图文档管理、开发进程管控以及静态知识管理等功能。但这些系统功能仍属于企业专业化能力建设阶段的产物，还远没有达成整体协同以及运营管控本能化的设计目标。至少，在系统功能层面，还存在各种“先天性的结构缺陷和基因缺陷”。例如，尚未关注如何敏锐感知自身短板、如何有效激发团队创新意愿以及如何敏捷响应市场客服体验改善需求等全新的功能设计课题，如用一句话来表达，那就是：还无法形成跨平台的企业级协同作业模式和运维管理模式。 因此，企业如想要构建具有纵横向整合能力的产品研发平台，首先必须在业务架构的重构设计层面达成充分共识，并能获得足够权威的项目实施授权。其次，才能考虑设计和配置类似下图所示的基于中台技术的系统架构。当然，企业如能完成这一架构层面的、最关键的基础工程，剩下的问题，就是如何逐一实施上述各种“基因缺陷”的修补项目，并逐步构建完成真正意义上的企业级产品研发平台。 二、关于整体协同本能化的实现逻辑简析 盛夏期间，除了各种哲学书籍之外，自己还阅读了不少标题很吸引眼球的科技书籍，如《万物原理》、《终极算法》以及《算法的力量》等等。不过，最大的收获是发现自己的理科基础实在太差的事实。当然，在极其困难的阅读过程中，自己也多少体会到了一点逻辑思考的趣味性，这对于自己进一步理解企业一体化平台产品的开发难度，确实帮助很大。在这里，我们以企业产品研发平台开发必然会面对的如下各种协同难题为例，来试着说明工业软件行业难以破壁的真实原因。 ●基于多维度市场需求数据分析的产品策划管理（产品研发创意激发） ●跨平台的产品数据发布同步处理（主数据精度） ●设计变更在线发布及实施跟踪管理（确保数据流和实物流的一致性） ●定制订单技术可行性咨询管理（营销客服体验改善） ●产能数据的自动采集和预处理（可承诺交期咨询智能应答） ●定制产品报价BOM快速配置（营销客服体验改善） ●产品技术差异化目标定位分析（产品改进立项支持） ●面向产品研发的动态知识管理（创新意愿激发） ●平台运行指标动态分析的可视化（面向决策的数据服务） ●…… 很显然，以上各种多维度的协同作业难题，都需要建立企业级的协同作业规范，都需要配置一体化的产品研发平台系统。但是，为什么中国的软件行业一直都没有关注这些真正影响企业产品研发能力的软件开发需求呢？在这一点上，《终极算法》的作者给了本人不少启示。其中，符号派算法通过逆向演绎完善业务原型的思路，联结派算法通过反向传播确立信息协同链路缺陷的思路，以及进化学派通过基因编程技术形成平台运维循环的思路，都可用来说明并帮助解决基于中台技术构建一体化平台的实施难度。 对此，首先需要说明的是，现有的单一系统产品，主要解决的是专业模块的执行能力问题，系统中的各种有形或无形机器人的算法逻辑，都是基于成熟的规范加以设计和配置的，故相对容易落地。但如要利用上述一体化的系统架构技术，来配置上述各种企业级的协同功能组件，则肯定会面对各种规范难以固化、资源冲突干扰以及实施变量众多等设计和实施问题。这正是基于中台架构，难以形成更先进的软件产品的主要原因。也可以说，面向制造企业的软件行业，对于如何利用各种学习型算法，来逐渐固化整体协同作业规范的设计理论体系还在襁褓之中，更别奢谈什么通过反复迭代的软件产品了。一句话，开发基于中台架构技术的软件产品，目前还只能采用量体裁衣和现场定制的开发模式，其设计和实施难度确实远远超出大家的预期。 举例来说，产品研发平台的产品策划管理功能组件，可视为产品研发平台的动力原料输入装置，如此类输入不足，则企业通过研发或改进产品以应对市场需求的原动力就不足。但现有的PLM系统，显然很难应对这一事关企业生存的功能配置需求。为此，企业应考虑在产品研发平台中，建立如下以BPM流程组件为中心的产品策划管理组件，据此形成多维度的市场情报收集渠道，并建立具有充分激发创意特征的产品策划管理模式。 但是，产品策划管理模块实现本能化协同作业模式的设计重点，在于持续提高市场需求感知的敏锐性以及激励大家积极提案的主动性，并通过持续积累具有实证分析作用的历史数据，逐渐提高和产品策划相关的数据分析能力。因此，对于软件开发需求来说，还必须经历一个业务原型、数模环境以及算法功能的设计和持续改进过程（如下图所示），才能逐渐形成成熟的功能组件。因此，对于这一类一时难以见效的功能开发需求，软件开发商显然缺乏直接承诺的底气，企业的决策者自然也很难就此做出果断的决策。 再举例来说，企业生命体在市场丛林世界中的生存能力要素之一，就是要始终关注如何“取悦客户”的执行和管控模式。对于企业产品研发平台而言，这里的“客户”不仅仅指终端用户，还包括DFX链路上的特殊客户（工艺、品质、制造、成本管理、销售以及售后等）。也就是说，产品研发平台的“表现”如何，只能是这些客户说了算。为了清楚说明这一层关系，大家可先探讨一下如下图所示的协同作业场景，表达的是一个由客户代表触发的面向定制订单产品的技术可行性咨询功能组件。 很显然，上图是一个具有AI功能设计的产品技术内部咨询应答服务组件，其中的自动对比分析组件，可采用《终极算法》提到的类推型学派的算法思路，但实现基准BOM精准定位计算的前提，是企业具有充分的历史数据积累。因此，这样的在线协同模式，在大多数只有单一系统的企业是难以实现的。产品研发平台拥有企业核心的数据和知识服务能力，如该平台缺乏必要的“客户”服务意识和数据服务条件，则企业取悦客户的能力自然会大打折扣。总之，在企业不同平台之间配置各种协同作业功能组件，是企业数字化转型需要关注的攻关难题之一。， 三、企业研发平台运营管控瓶颈简析 在《万物原理》这本科技名著中，居然会提出了人类社会只有保持“谦逊和自尊”的品质、才能持续发展的论点。本人据此得到的启示是：未来的工业软件必须关注敏锐感知自身运营缺陷以及持续优化平台功能的设计需求。前面探讨的产品策划功能组件，其实反映的是产品研发平台获取其它模块协同支持的场景，而第二个例子表达的是产品研发平台为相关部门提供协同支持的场景。但要确保此类协同作业模式逐步实现本能化的设计目标，还存在一个持续推进变革的问题，也就还存在一个和执行者“自由意志”相关的问题。目前，依赖机器人来推动企业进化的可能性几乎为零。因此，在未来企业产品研发平台的设计课题中，最有价值和最有前景的优化设计对象，应该是和员工类执行者的任职能力评定密切相关的设计课题。 根据各种成熟的企业管理理论，大家都清楚，企业文化对于企业员工类执行者的影响力是至关重要的。但企业文化绝不只是空洞的口号和贴在墙上的标语，而应实实在在地体现在平台运营管控规范之中。其中，形成基于不同分类评价数据（业务价值、执行力、创新价值）的任职能力管理模式，应该是未来工业软件应该关注的主攻课题之一。本人曾是某个汽车制造企业技术中心的技术管理主管，在如何利用数据评定技术人员的任职能力方面，曾有过一些自主探索和实战经历。所以，本人坚信的理念之一就是：真正有价值的工业软件，必须具有直接影响企业员工自由意志的成长性设计要素。如大家还有所怀疑，不妨回想一下，当年毛泽东领导的红军和解放军是如何打败不可一世的蒋家王朝。应该相信：最顶级的软件设计，一定和人的自由意志有关。总之，一旦完成了和任职能力评估相关的规范化以及结构化的基础工作，便可在平台中配置下图所示的BPM流程组件，其设计要点在于任务交付模板识别对象的完整性以及评价规则的合理性。 大家可以设想一下，如果在企业的产品研发平台中，已经配置了基于数据评价员工业务价值、执行力以及创新价值的功能组件的话，企业在整体管控层面还会产生这样那样的非理性的烦恼吗。当然，对于如何评价，还存在一个敏感的问题，那就是应该由谁来评价的问题。大家也许会认为，应由第三方的人事部门来承担，但这并不是理想的设计。这是因为，只要由人来执行此类评价，必然会出现东拉西扯、怎么也说不清楚的现象。因此，最适合担当该角色的执行者，只能是铁面无私的“机器人”，也就是说，一切都由算法说了算，我们的主要精力应该放在评价规则和算法逻辑的设计方面。 因此，如果企业的任职能力管理的设计方案能够确保评价依据的客观性以及执行规范的公正性，就可在产品研发平台中配置如下图所示的基于数据分析的任职能力管理功能组件。不过，实事求是地说，当前大多数企业还不具备配置此类功能组件的实施环境，这应该也是基于中台架构技术的软件产品还很难登场的原因之一吧。 以上，我们探讨的都是和一体化产品研发平台相关的设计思路，虽然，限于篇幅，无法充分展开，但应该可以回答本文一开始提到的困惑。本人认为，中国工业软件如想要实现自主前行并超越西方的目标，则必须能够明确回答如下问题： ●企业整体协同和运营管控的业务原型应该是怎样的？ ●企业整体协同及运营管控本能化的实现逻辑是怎样的、其主要实施瓶颈是什么？ ●未来软件开发商以及企业实施团队的能力模型应该发生怎样的变化？ ●…… 总之，企业也是一个生命体，当前，绝大部分企业仍处于专业化能力建设的进化阶段，现有单一系统的应用现状，也充分体现出了这样的阶段性。中国的工业软件如希望有所突破，则必须站在企业生命体进化理论的高度来加以探索，并据此确立符合企业进化规律的攻关方向和推进思路。  

今天我们分享MES系统导入的三个核心问题~ ✎导 读  MES系统导入不是一次性的工作，而是伴随企业管理提升而不断优化提升的长期工程。 01 mes系统首先用来解决什么问题？  本周，和一家企业管理软件公司谈合作事宜。在交流过程中，对方的项目经理提到一个业内的数据， MES系统软件一次导入成功率不足40%，比ERP系统软件导入成功率（不到60%）还要低。 作为一个成熟的企业管理软件系统，为什么导入成功率会这么低？MES系统软件到底是用来解决什么问题？MES系统软件能不能降低成本？MES系统软件最大的作用是什么？ 就这些问题，作为一个有着ERP与MES导入和运用经验的前企业管理者，与拥有丰富的MES管理设计、开发和导入经验的管理者，进行了亲切友好的交流。 MES系统首先用来解决什么问题？很多人会自然而然地认为，MES系统是用来解决管理问题的，是为了明确管理流程的，是为了建立管控标准的…… 甲方会有很多很多想解决的问题，甚至在系统导入过程中，各个部门也会提出希望解决的各种问题。就我等经验来说，提出想解决的问题越多，乙方越是为难，然后为了满足甲方的要求，不断赋予MES系统各种使命，最终的结果就是在实际运用中会发现，MES运行流程的复杂性、管控标准的滞后性、条件变更的呆滞性……还没有导入系统前顺畅。 举一个实际的案例：在冲压产线或挤压产线上，品质巡检发现有细微的毛边，就会将存在这一情况的产品挑出来，指示作业员在生产中进行处理。做这件事的时候，品检是不会开单子或者说走流程的，毕竟不是什么大的品质不良，处理了就可以了。 但是，作为生产部门、生产计划部门、模具部门，就需要这个处理毛边的详细描述和数据。因为生产计划部门需要进行单位工时与BOM表的标准比对排查出影响生产计划达成的主要因素，生产部门需要根据工时效率数据分析有价作业时间、辅助作业时间、浪费时间的动作并提出改善措施消除浪费，模具部门需要根据发生毛边的位置、发现毛边的数量和批次、结合生产数据、刀头冲压数据等信息，判断出毛边与刀头的寿命以及模具的状态，提前做好准备。这些数据都可以通过MES系统采集得到，但需要品质部门的配合。 换句话说，如果要想解决生产部门、生产计划部门、模具部门的管理问题，就需要增加品质部门的工作负担。 同样的，要想解决品质部门的管理问题，也就需要增加其他部门的工作负担。如果想一次性解决各个参与MES系统导入部门的问题，将会带来难以想象的工作负荷。这也是为什么，明明是按照大家的期望进行调整的MES系统，在实际运用中却用不起来的原因。 那么MES系统首先用来解决什么问题呢？根据我的运用经验，MES系统首先解决的是数据不被造假的问题。 即，通过ERP系统和MES系统的数据交互，以订单为单位，将材料使用数据、生产工时数据以及设备使用数据进行有效的串联，用这三个数据链还原并验证出该订单的成本数据，确保了成本数据难以造假。 不要小看这个问题，现代企业管理一切的原点在于成本数据的真实性。只靠ERP系统或者只靠MES系统，是无法串联、还原并验证成本数据的真实性的。没有真实的成本数据为基础，很多降本增效举措、进/出/存数量、实际能效分析等，都是浮云。 所以，MES系统导入首先解决的是数据真实性的问题。而要确保数据真实性就需要解决以下几点问题： （1）MES系统与ERP系统的数据交互时间设定问题，交互时间越是及时，数据的真实性和准确性越高。 （2）以成本数据还原计算为基础，以单位订单为轴心，以BOM表数据为参照，搭建数据关联性架构，确保数据间验证关系。 （3）搭建监控数据的管理组织，原则上需要分成数据输入、数据分析与应对、数据监管三个管理责任划分。 （4）明确数据细化颗粒度的标准。数据细化颗粒度不建议一次性细化太多，数据颗粒度越小，管控软硬件以及组织要求越高。 MES系统与ERP系统最大的不同在于，MES系统的数据采集颗粒度可以根据软件功能和设备硬件的提升而不断细化，不断细化的MES系统需要更高的成本投入和更多的管理分析时间进行维护。 所以，MES系统导入不是一次性的工作，而是伴随企业管理提升而不断优化提升的长期工程。因此，在第一次导入MES系统的时候，要清楚地知道，MES系统导入后首先用来解决什么问题。 02 　　MES系统导入后能否降低成本？ 根据我的经验，给的答案是不一定。MES系统导入以后怎么会不能降低成本呢？能否降低成本的关键不在于MES系统本身，而在于企业的管理组织和管理能力能否适应MES系统。 为什么要这样说？在MES系统导入前，一般生产型企业车间管理形式主要有2种，第一种为纸质条件下的规范化流程管理。比如某台设备发生故障，在纸质条件下，先填《设备保修单》→交设备部门领导派单→设备维修→设备维修结束→找设备担当或设备部门主管签字确认→交设备部门领导签字确认→交设备专员或自己在设备电子台账上进行手工输入。 从设备发生故障到这件事情真正反映到电子台账上最少需要1天时间，除非是重大设备故障或者影响到交货的设备故障，一般这种信息企业领导是无法及时了解的。 而MES系统导入以后，只要安装模块发挥作用，一旦发生设备故障信息，在第一时间就将会相关部门或岗位或人员共享，不需要走一系列的审批流程，设备部门就需要及时安排有时间人员前往处置。 您也许会想，这不是简化流程，提高了效率了吗？这里有一个关键前提，就是有时间的人员。 要想确保设备部门常备有时间的人员，要不就是车间设备故障率非常低（那就意味着日常维护支付得到保证或者设备相对比较新）、要不就是设备备品备件或备用机备的比较充足（那就意味着日常设备备品备件资金和场地得到保证）、要不就是有超过故障发生时间的人员储备（那就意味着会出现设备人员的超额配置），那一项不意味着需要增加成本。 如果不投入这些成本，数据会很快反映到主管和领导那边，将会被“重点关照”。因此，那些本身现场问题一大堆，靠着时间慢慢腾挪处置并向企业高层隐瞒的车间来说，导入MES系统意味着暴露车间真实情况，意味着压力、负荷和成本。 第二种，完全是靠着信任“一些大师傅”来自主协调应对的。比如某台设备发生故障，一个电话给大师傅→大师傅根据设备情况进行判断和维修→临时回复生产使用→后面根据领导颜色或者自己的记忆力请购部件→没记录、没有数据，都在大师傅的脑子里。 问题来了，MES系统导入以后，这种自主性被打破了，真实的数据呈现了，改善课题出来了，大师傅开始作妖了。既要保证自己的唯一性，又要把数据搞得好看点，除了各种作妖，还能怎么办。 因此，你会发现，MES系统导入后，问题还是存在、人员还是不够、扯皮情况更多，怎么可能降低成本。 所以，MES系统导入意味着数据反馈的及时性和准确性，也意味着问题暴露得更多、更快、更广。如有没有建立一个与MES系统相适应的管理组织，问题暴露的越多、越快、越广，企业内耗越多、时间效率越低、运营成本越高。 当然，MES系统是可以大幅度降低成本的有效工具，关键是能否正视所暴露的问题，搭建有效的管理团队，不断优化和改善，同时提升数据管理的颗粒度，那么降低成本就是水到渠成的事情。 按照我个人的经验，在导入MES系统第一阶段（1~2年左右时间）是不断暴露问题、解决问题、锻炼团队的时期；第二阶段（第3~4年左右时间）是不断推进、落实、验证各项针对性改善的时期；第三阶段（第5~7年左右时间）不断导入少人化、无人化设备以及MES和MES相关联系统进一步优化提升的时期。 第一阶段，是增加成本的时期，第二阶段是降低成本的时期，第三阶段是增加投资的时期。我也是导入MES系统的第4个年头开始通过减少时间浪费，提高产量，减少用工人数，实现运营成本的降低，在第5个年头才实现计划的投资回报率。 所以，MES系统能不能降低成本，不在于MES系统工具本身，而在于企业在导入MES系统之前有没有真正摸清车间的管理现状？有没有设置好能够推动现场改善的组织？有没有准备好为了解决车间问题的持续投资？ 03 MES系统首先用来干什么？ 在导入MES系统之前，作为一家日资企业也按照TPS标准，推进了车间5S、可视化看板、多技能工培养机制、TPM等等精益管理工作，表面上来看也是取得了很好的效果（我自己认为）。 但是在MES系统导入并实现与ERP系统数据交互以后，在最初的一个月，我就发现之前推出的精益，只是表面光鲜。由于数据的精确和信息反馈的及时，很多问题都浮出了表面。 比如，人员技能培训，我个人觉得人员技能培训体系做的已经很不错的了，最起码从月度操作节拍工时与BOM标准工时比数据来看，基本上都在95%~99%之间波动。 在导入MES系统以后，我可以在第二天快速的拉出来个工作岗位员工操作节拍工时与BOM标准工时精准的对比数据，经过一周的数据分析，我惊讶的发现老员工的节拍工时达成率最高可以达到130%，而入职一个月的不到员工的节拍工时达成率最高只在85%左右，入职三个月~半年的员工节拍工时达成率最高可以提升到95%左右。 为什么？我先向车间管理团队展示了数据统计数据，然后带领他们一起到现场进行了观察和视频拍摄，终于发现问题所在。 以前的培训工作主要集中在产品装配的标准动作，无论老员工还是新员工，在产品装配上的标准动作上是没有太多区别的，但是在装配之外，比如备料的放置和拿取、完成品的放置、品质自检方法等等存在太多的差异，特别是在这次的观察中，发现老员工普遍在使用一种简易、自制的品质自检工装，通过这个工装，可以将自检时间缩短将近20%。 之所以没有按照改善提案制度进行上报，主要是当时的改善提案制度都需要提案人自己提出、自己验证、自己联系生产部门和品质部门进行联合审核、再上报申请奖励。 提案人要做的事情太多、责任太大、周期太长、还需要自己解决跨部门验证的问题，作为普通作业人员根本没有时间和精力做这些事情，所以还不如直接由班组长确认没有质量风险后，就可以闷声大发财了。 带着管理团队，就发现的问题分派了大家的课题： （1）现有的BOM是否正确？…

一、研发绩效管理要考虑哪些要素 由于研发人员要具备一定的技术能力，同时研发成果具有一定滞后性，直接与财务和市场指标挂钩要通过营销实现，同时其工作方式大部分以项目存在，基础研究、技术攻关和产品开发的工作内容和工作难度都不一样，产出模式也不相同，因此研发的绩效管理一直是一个难题。 有的企业通过平衡记分卡，采用严格的KPI制度，但是往往没有考虑过程的难度和风险的评估，尤其是技术攻关和技术探索，导致能力强的人做风险高的项目还不如能力弱的人做风险小的项目，这样无法鼓励优秀的研发人员创新，不利于构建一种创新的氛围。 有的企业实行矩阵管理，对项目进行考核，由于项目的周期长，而且没有按阶段规划小项目周期，导致一个人在长时间内承担多个项目，绩效管理工作量特别大，绩效管理变成了简单应付。 有的企业没有进行任职资格建设，也没有规定行为准则，不先对项目进行考核，一味地对研发人员进行强制分布，导致业绩好的团队和业绩差的团队区别不大，影响了业绩好的团队的绩效管理。有的企业不进行财务成本考核，导致研发人员没有组织绩效，只是注重个人能力的提升，钻研新技术，最终企业研发人员能力提升了但是企业组织绩效没有提高。 因此，研发绩效管理要解决以下综合要素，避免一些误区。 1、区分组织绩效和个人绩效，组织绩效主要是市场和财务的成功，个人绩效必须在组织绩效上进行分解。 2、企业研发组织绩效的首要任务是在老产品改进上的毛利率提升，其次才是新产品、新技术的开发。 3、将预研、产品开发和需求及规划人员的绩效考核进行区分，产品开发人员必须与当年所支撑的产品的收入挂钩，预研人员可以与三年内预研成果转化成产品成果所带来的收入挂钩。 4、研发人员的能力、过程和结果及项目的关键点分别以不同的绩效手段管理和考核。 5、尽量将项目划分成一个个阶段，减少每个阶段的时间，使得一个人在一段时间内尽量承接的项目少，实现精力聚焦的同时，减少绩效考核的工作量。 6、将产品维护工作与产品开发工作分开，产品维护的项目按任务数进行考核，产品开发的项目按计划进度及质量要素考核。 7、建立任职资格，将不同层级的研发人员的考核模式与薪酬结构分开，低层次人员主要考核基本行为规范，中、高级人员的考核应该结合过程考核结果，高层次人员主要考核结果。 8、创新性的预研工作主要考核领军人物的任职资格。针对以上需要考虑的综合要素，企业对研发人员的绩效管理不仅包括能力、结果和过程，更要结合不同类型的项目（预研项目、产品开发项目、技术项目、平台项目）通过多种手段实现研发人员分层、分级、分项目的绩效管理。 二、绩效管理有哪五种手段？ 由于研发人员的绩效考核要综合考虑能力、过程和最终结果，同时还要让研发人员完成组织绩效，因此研发人员的绩效管理句括以下综合应用的五种手段。 （1）任职资格：主要是对员工的能力进行评价，包括经历、能力和基本素质以及关键业务活动和必备知识等要素； （2）行为准则∶指每一个职位必做的相关工作及职位要求活动的基本要求，通常也可理解为PI（Performance Indicator）; （3）PBC：（Personal Business Commitments）主要对员工的过程进行评价，来自年度和季度计划，主要指当月必须完成的一些工作，强调过程、路径； （4）KPI（Key Performance Indicator）∶关键绩效指标，通常对组织进行考核，来自企业的发展战略财务指标、市场指标及必须要解决的问题，更多的是强调组织绩效，强调实现战略目标的挑战性的指标； （5）KCP（Key Control Point）∶对项目关键路径上的关键资源的活动进行绩效管理，以区分项目成功的贡献和风险。 不同层级、不同类别的研发人员可以针对这五种手段组合考核，如∶ （1）高层管理人员∶主要考核KPI、KCP和任职资格; （2）预研人员∶主要考核任职资格、KCP和PBC; （3）产品开发的高级别人员∶主要考核KPI、任职资格、PBC、KCP; （4）产品开发的低级别人员∶主要考核行为准则、任职资格、PBC; （5）研发体系的职能部门∶最好不要考核KPI，主要考核其任职资格和行为准则及PBC。 三、如何将绩效管理的五种手段和薪酬对应 绩效管理必须与对应的薪酬结构相结合，针对绩效管理的五种手段，应该分别对应不同的薪酬结构，绩效管理的五种手段和薪酬的对应关系如图11-1-1所示。 （1）任职资格确定工资包，其中按比例确定基本工资和绩效工资; （2）行为准则作为扣款的依据； （3）PBC确定过程奖励（季度或月度绩效工资）; （4）KPI确定年度奖励（年度绩效工资或年终奖）； （5）KCP确定特别项目的贡献，但要有一定比例限制； （6）战略补贴确定优秀的高手做有风险的增量项目的补贴。 四、如何进行组织绩效的分解 绩效管理的总体流程通常从组织绩效分解着手，先进行组织KPI的分解，通过对组织KPI的分解寻找路径，落实到个人，再加上个人的能力提升指标，落实到月度计划，形成PBC。具体的流程详见图11-1-2。 需要注意的是∶ （1）组织绩效从组织规划开始按产品线分解，再分解到一级、二级部门，再分解到个人; （2）从KPI关键活动分解，找出路径，设定个人PBC。

集成产品开发（IntegratedProduct Development，简称IPD）是一套领先的、成熟的产品开发管理思想、模式和方法，是以产品运营为主线的流程管理解决方法。集成产品开发思想是根据大量成功的产品开发管理实践总结出来的，它被IBM、波音、诺基亚、杜邦、思科、华为、方太、许继电气等国内外许多企业成功实施，被证明是一种高效的产品开发模式。 集成产品开发思想在国内外许多企业的成功实施，使得国内其他企业逐步借鉴和推行集成产品开发思想。信息技术的进步为团队的管理和运作提供了有力的支持工具，随着PDM/PLM(product lifecycle management，PLM)技术在企业研发部门的实施应用，越来越多的企业关注PLM如何更好的与IPD管理思想融合起来。本文介绍PLM技术与集成产品开发项目的一体化集成管理思想，阐述IPD管理过程，为企业实施IPD提供参考意见。 华为IPD三大流程解析（视频） ，时长06:07 一、 IPD和PLM的挑战 中国企业所面临的共同挑战 在“互联网+”和“中国制造2025”时代面临的挑战 在“工业4.0”时代面临的挑战 二、产品开发的成熟度模型 三、什么是IPD？ 四、IPD对产品生命周期 五、IPD出色的项目管理 IPD项目管理的关键要素 5.1、执行管理-IPMT  高级管理人员有权批准项目集分配资源 5.2、产品开发团队（PDT） 专业团队的领导者对产品的成功负责 5.3、在阶段审核中制定结构化决策 对所有项目的相同阶段采取统一审核 5.4、结构化的开发流程 结构化的开发流程是团队执行项目的路线图 六、对产品开发流程进行优化非常重要 七、价值路线图 八、产品开发系统 九、PLM对IPD的支持 PLM解决方案能够优化产品开发 十、PLM管理&控制所有的产品数据 PLM解决方案能够优化产品开发 十一、优化IPD流程的执行-概述 PLM解决方案能够优化产品开发 十二、优化IPD流程的执行-案例 PLM解决方案对IPD流程进行优化案例 十三、PLM系统支持IPD的部署 IPD的研究是个热门，因为通信业界翘楚华为的成功，所有很多企业认为可以复制，为“我”所用，其实，任何一种不假思索的套用或借鉴，都是一条死路，因为组织和人、环境都变了，别人的成功不可能复制，适合自己的就是最好的，因此，IPD框架的落地，一定要进行IPD咨询，找到适合自己企业的路子和方法，才能获得成功。本文算是一个引子，后续笔者会详细阐述。

2019年5月27日，华为车BU正式成立。经过短短2年时间，在2021年4月上海车展上，华为车BU发布各类量产品类，尤其联合北汽极狐的全栈解决方案自动驾驶量产系统的发布，更是成为车展前最大的热点。 新车全栈系统解决方案包含了华为自研的激光、毫米波雷达和视觉感知单元，中央单元是自研的芯片、操作系统、全套应用软件，高清地图，还有自研的云端数据和仿真系统。业界达到这么大能力范围的企业，是尚未量产的来自于GOOGLE的Waymo，他们成立于2009年，估值300亿美元。同样市值的由通用、微软、本田、软银等多家巨头投资的Cruise成立于2013年，还没有这么全的方案。 相对于这两者，华为在2年内走出了不一样的道路并快速走向量产。如果现在华为车BU上市，其估值应该也可以达到百亿美元级别。发布会后，北汽蓝谷更是连续三次涨停，一周上涨近50%。 让我们看一下华为车BU已经上市的产品和本次发布的新品。 再看GOOGLE， Cruise自动驾驶车和华为北汽自动驾驶量产车的造型对比，我们能清晰通过顶部能看到明显的巨大差异。 华为的研发就是这么硬核！就像“别人家的孩子”，2年做车BU，就惊艳了一个行业。 那么，你是否好奇： 为什么这么大的企业还能这么灵活和充满动力？ 面对如此复杂的项目，2年才立的新组织怎么能这么快就达到行业领先？ 为什么华为能够快速汇集这么多人才？还能让一个新团队发挥超强战斗力？ 为什么先面向量产乘用车的高阶辅助驾驶，而不像Google/Cruise/百度等先主攻全自动驾驶ROBOTAXI? 我们在此把这个案例打开，解析华为硬核研发体系的先进之处，看看与一般企业研发相比，到底有哪些不一样的地方。 明确的研发定位和获取分享机制： 研发是利润中心，而不是成本中心 很多公司将销售作为利润中心，研发作为成本中心。 但在华为，客户满意、长期商业成功和引领产业进步是研发成功的最终标准。因此，华为让每一个研发产品线都以经营和利润为中心，员工收入也和产品线的经营结果息息相关。 如此，华为车BU本质上就和一个向公司借钱运营的初创公司是一样的，即使不用外部融资，一样面临投资回报和商业机会窗的双重压力和动力。华为车BU的员工比初创公司的员工还要辛苦地加班加点，战斗力爆棚。也正因此，华为才实现了2年破局的巨大成就。 而利润中心就决定了研发一定会以市场和客户为中心，而不是以内部、技术为中心。虽然挑战最难的Robotaxi对研发人员最有技术吸引力，但市场上当前需求最大的是乘用车的辅助驾驶和商用车限制场景的自动驾驶。因此，在发布会上，可以明显看出华为的“沿途下蛋”的稳健商业策略，即面向未来的自动驾驶技术上进行目标系统设计和攻关，但是落地上却稳健地实现了以自动驾驶硬件平台、多种传感器和高阶辅助驾驶软件的逐步商业变现。在长周期不确定性商业应用高风险研发中，沿途孵化出一个又一个可以对行业增值和快速落地的产业，更符合“精益创业“的先进思路。 死磕端到端的用户体验、技术和成本的竞争力，面向规模商用场景。只有大部分人都能用得起，规模才起得来，才能进一步摊薄成本。因此，华为的IPD研发体系，每个产品线都是一个联合财务、销售、供应链、开发、质量等重量级管理团队下的管理团队。这种管理方式，也能实现业务为核心+平台部门专业性平衡下的团队快速集结，在保障端到端的用户体验，上来就面向商用要求的端到端的质量和可接受的成本，把高昂的激光传感器，自动驾驶芯片、软件和系统集成成本都控制下来。 最后，面向客户的获取分享制，把公司各个研发体系拧到一股绳上。车BU盈利，所有的支撑部门都会分享收益。如销售和供应链部门、技术平台和研究部门，他们的成本都将计入产品线损益表。对应的，如果赚钱，产品线的利润也能分享到每一个部门。在这种机制下，一方面，各部门会合力来增加贡献以分享未来的收益，而不是扯皮。另一方面，如果内部的地图、云、激光和毫米波雷达传感器的技术和成本都不如合作，那么也不会被产品线轻易采用。这样的压力和动力机制，既避免了“创新者的窘境”中描述的类似柯达把自己研发的数码相机束之高阁的问题，也保证压力被一层层传递过来而不是被保护起来，还能保证产业生态的协同不被破坏。 如果您也是有规模的行业领先企业，请您对照思考以下三个问题： 谁对新品的商业成功负责，谁对端到端的成本和技术竞争力负责？ 研发体系是否有可匹敌初创公司的动力和干劲？ 研、产、销、服务等各个部门是否精诚合力，共同面向竞争力和创新？ 面向定位布局， 是有追求领先者应该有的定位和气势 初创公司始终面临资金压力。作为一个有追求的大公司，进入新领域和初创公司有什么不一样？华为车BU案例给了一个参考答案： ·给最终用户带来不一样的价值体验； ·解决方案以创新和差异化方案引领行业； ·能对行业做出独特贡献； ·支撑公司对规模、对市场份额的诉求。 因此，一旦决策进入汽车领域后，可以明显看到华为投资的超大手笔。例如直接投入2000人的研发团队，起步就面向量产和端到端全栈开发，上来就是面向中国最大、世界范围内都能排进第一梯队的超大投资。也只有这样的大手笔，才能够帮助中国汽车产业在量产智能车中，可以全栈能力挑战和超越西方强劲对手，而不是慢慢跟随，最终要么被别人卡住脖子，要么在巨头入局的竞争中难以突围。 面向定位布局，这才是一个有追求领先者应该有的定位和气势。 如果您也在投入新的领域，请您对照思考以下二个问题： 公司对战略新品的定位什么？对产业带来什么样独特的创新和增值？ 对战略新品的投资逻辑是什么？是慢慢来，小步快跑，还是首战即决战？ 独特的技术和平台体系， 站在巨人的肩膀上，避免从零开始 华为独特的技术和平台体系，把长期积累构建到可共享的平台和技术上，确保创新和起步是站在巨人的肩膀上，而不是从零开始。 众所周知，华为每年超过10%的收入投到研发中，还要保证一定比例的费用要用于技术和平台体系，以构建中长期核心竞争力。而且技术体系实现了公司级的协同和相对独立体系管理。让每一个领域的沉淀，在公司内都可以分享，再叠加公司的获取分享制增加分享的动力，这样让新的产品线创新和起步都是在雄厚的技术积累上，而不是从零开始。这些都形成了公司的研发底蕴。 以汽车BU发布会上展示的产品为例：·汽车用的人工智能芯片，来自于海思在视频、计算、AI芯片上积累的达芬奇和泰山架构，SOC芯片开发能力。从发布会来看，同样的架构还用在云和服务器中的鲲鹏、昇腾系列中。只有具备这样的积累和规模，才有可对抗英伟达、INTEL、高通这样世界一流企业的技术和成本。而且更厉害的是，华为还实现了在商用时间上领先行业标杆英伟达。·汽车用的操作系统AOS，这个操作系统和分时系统的Android，Windows等都很不同，来源于2012操作系统团队在实时、高安全操作系统上多年的积累，叠加这些操作系统已经广泛用在华为所有的ICT系统中。持续竞争力的提升，使得华为快速改造出一个既适合自动驾驶的高实时性、高安全性、高性能要求的的高端操作系统，又能在成本上占优势。·毫米波雷达来自于无线技术体系多年在射频、芯片、算法上的积累，并实现了2年走向量产，3年研发出4D成像雷达的惊人研发成果。发布会上宣称未来2年可以实现百万级的发货，更是振奋人心。华为正以“肉眼可见的速度”在成为中国车用雷达TOP供应商，助力中国车企以创新的感知部件，提升智能驾驶竞争力。·激光传感器来自于光通讯领域积累的精密制造能力以及先进的工艺装备实验室。华为还披露已经建立了第一条车规级激光雷达的产线，已按照年产10万套/线在推进，未来可以支持百万套需求。这些，才是华为能将业界几千美元昂贵的激光传感器成本降到几百美元的“独门内功”，从而帮助中国车企实现成本可控，弯道超越特斯拉纯视觉方案。·高质量体系能力：ICT领域产品的生命周期平均要求也是10年以上，可靠性要求均在99.999%以上，在质量管理和可靠性设计领域多年的积累和品牌，也帮助车BU这么多的软硬件能够匹配汽车零部件10年以上长周期，高质量的高门槛。满足高端专业客户的质量要求，放心使用华为的部件，突破了国产高端零部件在主机厂的质量困局。毕竟对汽车主机厂来说，任何一个部件质量问题造成的召回成本，通常都是数倍，甚至数十倍于造成问题的零部件成本。 技术和平台体系还是孵化新业务中心。由于技术体系的管理有相对的独立性，比产品研发要看的更远，更发散，因此更早就洞察了自动驾驶体系是未来一个巨大的产业，并早已开始前期研究。因此，在2012实验室下面成立自动驾驶新业务的孵化团队，也是推动孵化下一代EBO（Emerging Business Opportunities）的内部动力。自动驾驶在华为内部小团队预研，至少可以回溯到2015年。 从结果来看，该架构很好的避免了“创新者的窘境”中的多个陷阱。使华为公司能在一个又一个产业周期性变化中，提前储备，踩在时代的脉搏上。 此处，也请您对照思考： 您的公司积攒了什么样的核心竞争力？在公司内易分享吗？ 新品多大程度上是站在公司的深厚积累之上？ “研发体系”作为产品来开发， 不再是凭经验 华为把“研发体系”本身也作为产品来开发，并科学化积累，不再是凭经验。 相比于初创公司的迭代式开发，如何把10万人的研发团队，而且全部是知识员工的效率提升翻倍，对华为的意义巨大。系统提升研发开发效率，确保新产品开发商业持续成功，实现可复制的“从偶然到必然”成为建设华为研发体系的强有力诉求。为此，华为把研发体系的科学建设作为一个明确的科学课题并花巨资从IBM引入IPD后，用20年进行本土化，并持续改进。 这个科学体系在车BU这个场景下也是这样：i.正式投资前小型预研团队摸清底细，以先期的技术摸底、标准摸底，同步专利构建，为高难度开发、大团队投入明确方向和降低风险。同时，进行早期专利布局。ii.重视规划，以“往前，往前，再往前”的目标，努力实现研产销前端协同，包括在详细的市场调研基础上的战略规划、解决方案和产品规划，以及技术规划。这些规划都基于千锤百炼，人人熟用的BLM模型。其中，战略规划确定公司以什么方式进入市场？是做整车还是部件？谁是我们的客户？商业模式怎样？应该投资哪些产品？可以在哪些领域创新？带来什么样的产业增值？未来5年整体的投资规划怎样才合适？解决方案和产品规划包括解决方案规划、各个子产品，子部件的规划，以及输出基于公司的积累, 合作伙伴的能力和竞争态势下的路标：创新特性路标、质量和成本的路标、产品的投入产出预测和产业合作路标。技术规划，是梳理面向更长久的技术储备和合作路径、标准、专利和生态布局。规划中，研发、销售、生产制造、采购、质量都进来，在前端就开始进行联合创新和规划，包括销售模式如何创新，客户如何协同，制造如何提前准备，供应商合作策略，质量的目标要求和体系。因为规划造成的问题在后端是指数级放大的，要想减少浪费，提高效率，领先企业就要努力尽早进行协同。通过持续迭代，渐进清晰的规划工作，帮助车BU避免解决方案和产品的反复，短时间取得好成就。…