随着用户需求定制化加深+宏观不可抗因素的增加，在企业产品更新迭代加快的同时，对供方资源质量、效率的要求也成为业务的重中之重，是供应链管理的核心之一。
在芯片流项目中，供方资源的前置引入可以确保预测需求的及时发布与承接，另一方面从源头确保了供方质量，杜过程中资源不足，导致的交付周期拉长。
同样地，项目组拉通芯片资源库全流程：触发→寻源→评审→入池→淘汰，识别业务变革点：
1、触发：核心解决寻源触发无规则的问题。在做LTC流程优化的时候，一方面识别到部分物料下单后才启动寻源，拉长整个交付周期，另一方面，寻源触发源头多（新品设计，客户指定，独家供货等），不可控；
复盘供方寻源场景，定寻源触发6规则，对源头进行清洗，主要包括：
①新品开发：型谱外新品开发、海外ODM项目等；
②技术预研：新市场、新技术等预研项目；
③年度预测：年度预测供需有缺口（本项目识别点）；
④降本需求：物料成本≥10%同类物料，内部经营降本；
⑤独家供货：品类供方独家供货；
⑥储备底线：各类芯片储备数量≥3家（本项目识别点）。
2、寻源：核心解决渠道少的问题，一方面通过寻源9渠道，识别路径，支撑业务寻源；另一方面，从管理上，新增寻源登记表，系统留痕；
3、评审/入池：通过准入规则，对寻源供方质量进行评价，建系统审批流，对芯片资源实施动态管控（任务待办防漏，资源库定期更新）；
4、淘汰：重点在供方绩效管理，完善供方绩效规则（增预测回复及时、准确率，提货周期达率、履约达率等指标），月度维护通排，对不合格供方按规则降配额或者汰换。
今天，结合IT方案，回头看该专项，重点在品类准入规则植入、增供方绩效维护功能、年度规划系统植入（触发寻源需求）。而在立项汇报资料中，遗漏了资源汰换相关内容，除此之外，还发现一些地方不够细，比如：
1、寻源触发只识别了场景，但是未细化到触发点，比如年度预测，当预测供需缺口达到多少时才触发，还是一有缺口马上触发，如果是即将淘汰的老品，也需触发寻源吗？第二点是怎么触发的问题，涉及哪些系统，谁审批等未考虑清；
2、寻源9渠道不够落地，还没有到最后一公里，且方案里面没有找到对应的位置，我们没有做好需求的逆向跟踪。方案上考虑是否可以通过网络python，自动识别、锁定寻源供方。这9个场景，有多少可以自动识别？否则没有从根本上提升业务寻源的效率；
3、供方绩效管理，方案中除了供方绩效维护功能外，没有讲清楚整个汰换的业务规则和业务流（或者本人对这块不甚了解，需深入了解）；
4、IT方案中研发资源库选配相关内容未展开，即如何通过芯片组、物料组、快速锁定资源（立项中有识别）？但是方案中只讲到根据缺口，前置更新资源库，更新资源库的目的是支撑研发选型，存断点。
反思，本专项往大了说就是企业供方资源管理的缩影。除项目组聚焦的上述变革点外，应该跳出芯片流，又站在芯片流这个项目上看资源的全生命后期管理和基础支撑点，比如：资源目录管理、品类管理、跨公司的资源共享及最基础的资源组及标签定义等。
网友评论