新产品开发中，供应链的速度太慢怎么办？

　　在很多企业，供应链是围绕量产需求设计，以效率为导向，成本能做低，但速度做不快。这往往成为新产品开发的挑战，因为研发虽然关注成本，但更关注速度。研发的需求得不到有效满足，就对供应链很不待见。看上去这是研发的行为问题（对供应链不好，不待见），其实解决方案在供应链的能力上：（供应链）不改变（支持新产品的）能力，（研发）就不会改变（不待见供应链）的行为。所以，表面上看是（研发的）行为改变，实质上是（供应链的）能力建设问题。让我们拿个案例来说明。

　　硅谷有个高科技制造企业，一二十亿美金的规模。跟任何技术公司一样，该公司的研发人员整天被最后期限赶着走，不管是来自客户、新产品还是项目的，日子过得很悲催。他们对供应链的最大抱怨呢，就是速度太慢。比如工程师们想买点简单的东西，做个试验什么的，知道了供应商，知道了价格，光让供应链部门下个订单，不等个3天5天的时间，这订单就是出不了门。

　　为什么这么慢呢？两个主要原因：其一，采购员既支持量产，也支持新产品开发，采购员的面前任何时候都排着一长串儿的订单，主要是量产的。先来后到，工程师的订单来了，排队动不动就得一两天。其二，公司的制度、流程是围绕量产的、重复性需求设定，对于研发的一次性采购，要加上额外的审批，采购审完财务审，层层审批显著增加了周转周期。速度慢，研发人员很有意见，就给供应链很多压力，支持新产品开发的采购经理的日子就很难过，很少有人能熬过两年。

　　那怎么办？你不能在研发人员难伺候上做文章；你得从有效满足他们的合理需求上着眼。那就是提高供应链的能力，以满足工程师们的需求，从而改变他们对供应链不友好的行为。这样，我们的聚焦点就成了能力建设。前面已经多次说过，能力是个三位一体的概念：组织、流程和系统。这个高科技企业的供应链部门正是从这三个方面出发，提高供应链支持新产品开发的能力。

　　先说组织。为加强对新产品的支持力度，该公司配备了几个专职的采购员。这些采购员不处理量产订单；他们的全职工作就是支持设计人员的需求，从确认需求到下订单、跟单、收货，尽可能快地满足工程师需求。这样，订单的处理周期大幅缩短。除了人员建制外，组织措施还包括绩效考核。比如对这几个新产品的采购员，该公司开始统计订单发送速度，比如在X小时内，应该有Y%的订单发送给供应商，每周、每月考核。绩效考核驱动员工行为：这些采购员自然更加认真地及时处理工程师的订单。

　　再说系统。对于工程师的一次性零星需求，该公司设计了一个简单的Excel表格，让工程师填写要买的零星物料和供应商信息，填写完毕就发送到一个专用的Email信箱。表格一旦进入那个Email信箱，系统就开始计时。那几个全职的新产品采购员呢，时时都紧盯着这个共用信箱，看到Excel表格就尽快处理。人们提到系统，总觉得需要投入很多资源，其实未必，比如这里的系统措施，在收发邮件的Outlook系统里稍作设置即可，不需要任何额外投资。

　　最后说流程。组织调整了，比如设立专门的新产品采购员，也意味着流程的调整：工程师的采购需求产生了，就再也用不着跟量产需求一起排队。在审批流程上，该公司也简化了采购对工程师需求的审批。想想看，工程师想买点杂七杂八的东西，用途大多是研发项目，作为技术外行的采购，你何德何能，能够判断花费是否合适？

　　谁能判断这些需求是否合理？——是工程师们自己的老板。是花研发部门自己的钱，工程师的老板，有时候是老板的老板都批准了，还要采购批准啥呢？这些小额采购，金额不大，即使给工程师们打了“水漂”，又有多少损失呢？我不是说不应管控这个风险；我说的是风险管控与制造的麻烦相比，性价比不一定合算——我们在解决一个问题的时候，往往会制造另一些问题，关键是要看解决的问题多，还是制造的问题多。

　　对于硅谷的这个企业来说，订单处理速度只是供应链改变能力、技术人员改变行为的一个简单例子。这些举措其实都没有什么特别的技术含量，也不用多少投资。关键是要意识到，内部客户对待支持职能的态度（行为），根本上是取决于我们支持职能的能力；不改变支持职能的能力，就很难改变内部客户的行为。让我们再举个例子，看这个公司是如何改变供应链的能力，以改变工程师的行为的。

　　拿产品的入库为例。和很多公司一样，硅谷这个高科技公司的设计人员火急火燎，催促供应商快点交货，但一旦货到了自家仓库门口，就如石沉大海，“走流程”动辄就得几天时间。比如在这个硅谷公司，供应商的产品送到仓库，就得排队，等候录入ERP，这一等就是小半天——跟上面的订单处理一样，随时都有一大堆量产的物料在等着入库；好不容易录入ERP，又开始排队，等着搬到货架上，小半天又过去了；上了货架，还得排队，等候送到工程师的办公室。就这样，工程师一边在火急火燎催货，供应链却在慢条斯理，按部就班地走流程。你说工程师们能给供应链好脸色吗？又是一个典型的工程师的行为，取决于供应链的能力。

　　那解决方案呢，还是得从供应链的能力建设着手。这个企业的供应链先从系统上开始，把所有工程师的订单都识别出来（这容易，比如SAP里，以47开头的一般是工程师订单）；对这些订单，要求供应商用橘色的包装来识别。然后他们培训供应链上的各个职能，从物流到仓储到搬运，凡是看到橘色的包装，都得放下手头的活儿，优先处理橘色包裹——这也是组织和流程措施。一下子，这就把大段大段的排队等候给拿掉了。

　　想想看，仓库收发的材料中，绝大多数的是给生产线的；现在让为数甚少的研发订单插队，对生产线的总体影响没什么，但对工程师们来说却是天壤之别：以前收发流程慢，经常见工程师自己驾车到供应商处拿货，浪费工程师的宝贵时间不算，后续的账实不符、供应商付款问题又是一大堆（工程师拿到料了，却没有及时或干脆不补流程，账实不符）；现在有了橘色包装、优先通道，入库的延误尽量减少了，仓库又设了一个专人，整天的任务就是给工程师们送货（组织措施），工程师们自然就用不着到供应商现场去拿货了，而相应的账实不符问题也得到了根治。又是一个工程师的行为改变（不到供应商处拿货），取决于供应链的能力提升。

　　上面两个例子只是该公司的供应链提升能力、更好满足新产品开发的一部分，从而改变内部客户的行为，改善与供应链的关系。各种举措，不管是组织、流程还是系统措施，其实都没多少“技术”含量，也用不着多少投资，却对提升新产品开发的支持力度有显著意义。

　　不理解这些的呢，总是抱怨研发太强势，不愿“善待”供应链；理解这些的呢，则善于从自身找问题。毕竟，用一句老话讲，会埋怨的埋怨自己，不会埋怨的埋怨别人。企业人是理性的，组织行为也是。在一个公司里，一个职能不被“待见”，根本原因，鲜有例外，都在于那个职能的能力：能力不足，没法有效解决内部客户的问题，或者制造的问题比解决的还多时，受到影响的职能怎么会拿正眼看你呢？（作者：刘宝红 来源：《伺服与传动》）