产品开发过程和与供应商协同管理

       去年在进行方案诊断时，我和兰姐曾经分享了目前产品开发与供应商协同的短板与不足，可能存在的挑战，力求更好的实现企业内的产品开发与供应商之间的准确、及时传递；但受项目范围的限制，只能采用最简单的方式先实现最初步的集成；后来在定义优化的计划时，本来计划通过专项立项进行实施，但因为项目已经结束且离开项目组，所以实现的PLM产品开发与供应商集成协同的IT实现并不是很理想。

宝哥是公司供应链的专家，对供应链的如何架构和运行，甚至面向未来更大的扩展的复杂的变化都有深思熟虑，我看过并参与过宝专家的部分规划，尤其是和研发相关的沟通，很多思路和前期我参与规划和实施的项目对供应链的协同高度一致，因此很多时候也和宝哥交流对应的思路；在结项的日子，也希望将当前运行的情况，以及曾经答应兰姐和宝哥，针对这部分实施经验汇总，形成专题进行分享；本篇文章就是对分享内容的细化，若是对大家有用，就可以发挥更大的价值。

首先先问大家一个问题：说起PLM与SRM的集成内容，大家可能会想起什么？

 对于大部分常识，PLM是负责产品开发的图纸、物料和BOM定义，SRM是负责供应商或供应链管理，在企业的业务中，若进行定制化生产，需要将图纸集成供应商，确保供应商可准确获取图纸，变更时获取更新的图纸——的确，基础的需求就这么简单。

 但是，随着企业产品开发的日益复杂，迭代加速和周期的缩短，竞争的加剧等多重因素，也对集成企业和供应商的关系进行了重新定位，甚至供应链的稳定性，供应商的技术可能直接成为产品的瓶颈，影响利润的达摩克利斯之剑；因此SRM也进化成为SCM，企业与供应商的关系也在悄然的发生变化，甚至成为盟友，利益共同体，甚至出现交叉持股的情况，也远远超出传统的关系；在某一些场景甚至可以看到和供应商签署的排他性协议(这个是不合法的，但也是存在的)。

 过去几年，参与过多次针对研发与供应商深度协同项目的实施，为了做好项目，也研究了多个行业针对研发与供应商协同的实施案例，在经过团队的攻坚克难，基本也都在企业落地；产品开发若按照生命周期进行规划，供应商也应该在生命周期会全局参与的，因此在产品开发时，将与供应商的协同从结果协同延伸到生命周期协同，那么将有不一样的收获。按照这种思路，我们分析了一下企业与供应商协同的几种模式：

1. 仅物料采买，无协同：这种指直接在市场上采买供应商生产的标准产品即可使用，因此很多时候除非商务和价格的沟通，原则上与产品开发不存在协同的；
2. 仅按企业图纸设计要求的定制交付：这种场景在企业中属于最常见的，企业完成产品的定义，然后寻找供应商进行加工，只要供应商可按照图纸要求进行交付即可；针对这种场景，只要将发布的图纸传递给供应商，供应商接收后按照订单要求进行生产；在源头变更时，只要确保变更及时传递即可；
3. 按企业图纸设计要求和管理要求的协同：针对汽车的零部件，或者部分企业存在对物料可靠性要求比较高的企业，会存在专门针对供应商物料引入的管理要求，参与的供应商必须按照行业规范，企业管理要求参与物料开发的质量管理要求；例如汽车整机或者大部件企业完成设计后，寻源制造商进行制造，为了确保制造商具备制造能力满足质量控制要求，IATF16949等行业规范定义了详细的过程控制，例如图示的PPAP的，就是供应商为了满足正式供货要求，必须提交的认可资料(前面分享的MPN物料的认证，也属于类似的管理要求)；

1. 初步参与研发过程的协同：随着企业生产零部件的复杂性，若是完全设计完成后再交付供应商审核和制造，此时若供应商发现不合理的设计缺陷导致可制造性受到影响或者成本增加，此时再返工修改就会造成不必要的变更，以及产品开发周期的增长，因此此时企业在设计完成后需要先引入制造商进行设计评审(DRM,设计评审管理)，供应商提供专业的制造能力在设计发布前期就参与审核确认，这样就可以降低后续不必要的变更，此时供应商已经开始初步参与设计过程，不过是设计完成后的审核，这种改善可以对供应商协同价值带来很大提升；
2. 深度参与研发过程的协同：随着产品复杂性的持续提升和周期缩短，以及部分模块的专业性，企业需要寻找行业供应商的最合适方案支撑企业产品开发，例如新能源汽车的电池大量找宁德时代，包括我所在公司的储能柜体等，企业提供整体设计和不同功能模块的规格要求，以及与不同系统的接口规范，此时需要供应商参考这些约束提供专业的设计能力和功能模块的交付支持；产品的快速迭代也要求供应商同步、深度参与到产品开发过程中，确保同企业内部开发节拍步骤保持一致，此时供应商就像产品团队的一个伙伴，是需要及时有效的参与产品开发过程。

不同等级的协同对供应商参与企业产品开发的深度不一样，给企业带来的价值也存在很大差异，我们对市场上现状分析后，识别到主要存在以下三个核心的挑战：

• 已实施SCM系统，但仅侧重于零部件供应商采购过程管理
• 专业的系统仅管理了发布零部件的采购，缺少生命周期数据追溯功能；
• 大量的业务过程文档在ERP和SCM中管理，但数据缺失关联；
• 缺少与供应商的协同产品开发平台
• 在方案阶段已要求提前识别关键部件和供应商，但文档提交后缺少过程追踪；
• 供应商产品开发进度和交付仅靠线下邮件等方式管理，没有控制；
• 无法针对不同等级部件针对不同供应商形成差异化管理要求；
• 与供应商没有形成闭环的质量管理闭环
• 供应商无法获取产品零部件的运行状态数据，很难准确高效的提供产品质量改进和运维服务提升；
• 备件定义和管理上的利益冲突；

在《EIA-649B配置管理》标准中，将供应商协作零部件定位同内部开发部件，受配置管理的控制，包括：1️⃣供应商的协作和控制过程，必须和配置管理要求保持一致，遵守统一的规则，并进行配置纪实； 2️⃣供应商协作若涉及到按照买方规范开发，必须按照配置要求控制全生命周期；若是仅作为购买产品，需要验证与当前产品集成的可行性，再选择是否采购； 3️⃣测试和验证是确定供应商满足程度的一个必要环节。

所以在更详细的方案分享之前，可以先引入一个变量：变更管理；针对变更，对于企业内部执行的复杂性在于将变更传递到计划、物控和生产部门并按照切换计划和处置意见进行执行；但是对于供应商制造，复杂度也上升了一个层级，供应商的生产受企业采购订单驱动，那么当设计变更时，如何将新版变更及时准确的传递给供应商，并且针对未关闭的采购单及时建立断点，在供应商的交付中也能清晰区分交付的版本差异性，这样才能将库存和出库来料牵引到生产过程的实际执行切换；但若是供应商帮忙生产的是组件，例如对于汽车企业的发动机，或者储能产品的柜体，若产品中比较基层的一个零件进行了修改，如何将变更影响向上逐层传递到采购层级？如何将组件图纸完整的传递给供应商，并且在变更时还能准确识别的受影响到采购组件，这对与供应商协同的几种模式中都非常重要，也直接会影响供应商交付产品的质量（如图示，若百叶窗的固定结构件变更，如何将变更影响传递到储能柜体的供应商？）。

最后在与供应商协同的过程中传统的都是单向的，但随着智能产品的逐步推广，供应商参与产品开发和交付时，也希望知道交付产品在实际应用中的可靠性以及针对产品改进的需求；但传统的管理中供应商与实际用户之间实际隔离着整机产品提供商，所以数据很难打通，那么在深度协同时，也需要将实际产品运营的状态反馈到供应商，方便供应商基于反馈的问题和数据对产品及时的整改和优化，共同提升产品的质量，目前这种场景非常多，集成产品提供商还可以通过与供应商分享数据提升产品的议价能力，也是企业降本增效的一种渠道。

针对上述不同类型的研发协同，尤其随着成熟度的上升，企业的确需要建立专门面向供应商的协同开发平台，支撑与供应商的开发平台对接，实现业务的无缝衔接和数据的精准传递。

在企业实施中，也构建了专门的面向协同的平台，通过集成来源于不同渠道和IT系统的数据，实现与SRM的协同和更深纬度的供应商参与便利性，功能架构如图示。

   通过这个平台，目前在实施中，主要解决以下问题：

1. 设计发布时，或者向供应商下发采购订单时，对应的物料及版本、图纸、技术规格书等相关文件的发布；若是组件时，则提供组件的BOM清单及关联的文件，供供应商单个或者批量下载(通过建立统一的文件共享服务器，将下载的文件压缩从SRM或者PLM主业务系统中迁移到专门的协同平台上)；
2. 当源头设计文件变更时，可以通过BOM关系和物料处置意见识别到未关闭的采购订单，并生成是否处理采购断点的任务，任务直接发送给采购工程师，然后结合物控和计划的规划，判断是否进行采购断点；针对变更其实后来还增加了ECR评审的集成，当ECR的初审通过后，若变更导致当前订单不能使用需立即切换时，可直接传递供应商切换，而不是等正式发布后，这样进一步降低企业可能的变更损失；
3. 供应商针对物料开发的认可认证文件的上传和集成，这里包括开发过程中的认证资料，包括PPAP的审核资料，后来也增加了部分关键部件的制造过程数据和检验结果数据，这部分是在二期项目中从SRM迁移到协同平台中；
4. 研发过程图纸和技术文件的审核，针对结构设计和硬件设计的图纸，若制造类型是外协件，在提交正式审核之前，必须先发起供应商的设计审核DRM；供应商创建的文件可实时同步到设计工程师，工程师可对问题跟踪处理或者与供应商沟通，仅必要的问题处理完成后，才能允许正式审核；后来在某企业，针对这块功能又增加了供应商报价功能，将线下的报价表单线上化，在产品开发前期已经获知供应商的报价；

1. 设计任务的在线发布和供应商在线设计协同，支持企业在内部平台中发起委外设计申请，通过基线管理将包含架构设计的需求、模块、功能逻辑、接口文件、CAD骨架、技术文件、交付物要求、必要的技术文件模版等信息全部打包，当完成审核后，即可同步传递到协同平台中，这样当供应商登录系统时，即可下载展开设计(当时原计划供应商直接在线设计，但协助企业到多加供应商调研时，发现很多企业都有自己的系统，若是让供应商登录不仅要求协同平台也必须时类PDM的功能，也增加企业的管理负担，因此后来就改为统一数据标准(参考航天的写作模式))；
2. 产品和零部件故障信息的开放和在线追踪：企业内部运维的后市场管理系统中，若识别到是供应商物料的问题，即可将任务通知发送供应商参与问题的分析和解决方案的定义；这部分功能上线比较晚，因为涉及到如何准确根据故障分析失效物料的供应商的完整追溯，避免遗漏问题，也避免不必要的泄密。
3. 随着后市场维护要求的增强，在此平台上又补充了面向运维的备件清单和BOM的定义功能，供应商可以根据产品的特性，选择按里程维护或者时间维护等逻辑，并定义不同逻辑下的备件定义和手册上传，并与企业审核达成一致意见；这样企业内部在转换服务BOM时，可直接从协同平台获取数据，避免线下传递不及时或者丢失信息的场景。