标签: 需求

摘自畅销书《采购与供应链管理：一个实践者的角度》。刘宝红著，机械工业出版社出版。当当、京东、亚马逊等各大网站有售，纸质和电子版。 《采购与供应链管理：一个实践者的角度》第一版出版后，我围绕该书推出培训，到2015年月已经做了近80次，培训了几千名职业人。培训是很好的互动机会，期间不少学员问到如何去管理需求，下面予以更深入地解释。 "大采购"的重要特征是从供给导向转向需求导向，即通过有效管理、理顺需求来管理供给。很多供给问题其实是需求问题的延伸。例如紧急需求来了，供应商没有足够的响应时间，加班加点，打乱整个生产计划，导致骨牌效应，出现整体按期交货问题；设计定型了，目标成本达不到，供应商的降本建议又没法纳入设计，于是就剩下采购与供应商死磕，玩利润转移的零和游戏（注意：需求在这里是个广义概念。销售的订单是需求，生产计划是需求，工程师的图纸和规范也是需求）。理顺需求，供给端的大多问题就迎刃而解。 鉴于采购是内部支持职能，这里讲的主要是内部需求的管理。作为采购，如果积极地和业务、计划、生产、设计联系，及早、主动收集需求信息，就能更好地做好供应计划，以及应急安排。这些都要在需求完全确定前做。等需求完全确定了，例如客户的订单拿到了、设计的图纸定型了，往往就太迟了，因为没有足够的采购前置期，于是就不得不催货跟单，陷入"小采购"的泥淖。 对于设计驱动的需求，采购要通过正面影响设计来实现，通过优化设计来降低成本、增加产品的可制造性。举个例子。建筑行业的通行做法是设计和设备选型做好后，图纸、规范转到采购，由采购来跟设备供应商、承包商来谈价。为达到目标成本，供应商往往建议设计变更，但这太晚了。熟悉建筑行业的朋友都知道，等施工图出来后，牵一发而动全身，这样的设计变动意味着结构、管线等全面变动，要通过几无可能。于是就只有采购与供应商死磕的份，做利润转移的游戏。其实不管是建筑业还是其他行业，百分之七八十的成本是设计阶段决定的。采购把关键供应商早期纳入设计、采纳他们的好点子，是积极影响设计，从而影响需求的有效举措。这也是采购从"小采购"转变为"大采购"的一种体现，需要的是积极主动，未雨绸缪。 对于营销驱动的需求，需求管理的对象主要是订单落地之前的预测。很多产品受国家政策、经济环境、新技术、竞争对手的影响都很大，预测难做，但并不是说就不应该做预测，或者说预测不存在。销售总会有一系列的生意在谈，有些成功的概率可能高达80%，有些可能只有30%。这些信息，做运营的（不光是采购）可通过跟销售和市场部的互动得知，以采取适当的行动。例如如果主要零部件的通用性高，采购周期长的，可考虑在成功可能性达到一定程度（例如50%）的时候就录入需求，驱动采购。万一这生意不成功，这些零部件还可以被别的产品、客户消化掉，无非是需要一段时间。相反，如果定制件较多、库存呆滞风险高，则应该及时反馈给销售端，让他们理解潜在的风险，要么是承担风险，提前驱动供应链；要么是规避风险，等生意谈成后再采购、生产，销售应理解得等一段时间才能拿到货。这样，销售至少是参与了决策，到时候果真拿到订单、紧急要货的话他们也能理解为什么没货。内部客户的满意度低，很多情况下是因为他们没有选择的余地、没有参与决策。"小采购"心态下，采购坐等需求落地，等到后就催供应商，催不来就抱怨销售给的交货时间太少，总觉得自己是无辜受害者，都是别人的错。采购地位低，说句公道话，是采购对公司的贡献低，需求管理不到位，打铁自身不硬。 对于预测，我有三个简单规则，希望对大家有帮助。 规则1：所有的预测都是错的，但有个预测要比没有强。 在客户订单落地之前，从生产计划的角度讲，只有有了预测，MRP才能运作，驱动材料采购与生产。预测相当于宇宙第一推动力。没有预测，生产计划、供应计划就无从谈起，或者说至少没法系统地做。在一些公司，销售为保证预测的可靠性，迟迟不肯"在沙子里插个棍子"，给出个预测来，这事就拖着。一旦预测变得相当可靠，甚至变成了客户订单，录入系统了，但客户要求的交货日期也在跟前了，留给生产和采购的时间所剩无几。要打破这种僵局，除了给销售部门的责任机制外，关键是要制造宽松的氛围，产、供、销及早协作，理解预测的风险，鼓励承担精心计算过的风险，尽早设定预测。在这里，采购和运营不单是预测的接受者，而且也是预测的贡献者，因为他们最能理解预测带来的库存、产能投资风险。每一个预测都是机会与风险的平衡，这就注定预测不只是销售的事，因为销售熟悉机会，而熟悉风险的是生产运营和采购。 这里特别强调的是严谨但非惩罚性。所有的预测都是错的。只要内部客户做了严谨的分析，配以最佳职业判断，做出的预测即使错了也不可“秋后算账”。营销当然知道早给预测的重要性。为什么不给呢？一个原因就是怕生产和采购“秋后算账”。秋后算账不能少，这是供应链前端（营销）和后端（生产、采购）的反馈机制；但是，秋后算账要分清楚情况：预测不准，是因为市场和客户本身难以预见，还是因为营销没有尽职。对于前者要宽容。这对促进跨职能协作和鼓励前端尽早拿出预测很重要。 对新产品开发、新项目而言，预测更多地是定性的理解。例如新产品、新项目的概念一出来，采购要有足够的敏感，了解这是针对大众还是小众、全国还是地方市场。基于这种定性的理解，采购大致可估计对供应商的技术、产能要求，在选择供应商的时候加以考虑，支持好新产品开发，并为日后的量产打好基础。这里的误区是采购不了解大的方向与要求，没有做好供应商选择，或者供应商选择纯粹由设计部门做主，为日后各种问题埋下祸根，犯了"小采购"经常犯的错。 规则2：预测需要多职能参与，每个部门都得各尽其责。 这在规则1中也提到，意味着采购、运营、计划和产品部都得介入，在预测过程中做自己的贡献。放到公司与公司之间，就是所谓的CPFR（协同计划、预测和补货）。采购或许要问，这产品销售预测归销售管，跟我们做采购的有什么关系？其实大家都在同一条供应链上，采购应该与计划部门密切联系，跟踪公司的主要活动，促使早日生成预测计划。采购与运营往往觉得自己是预测的受害者，部分原因也是他们对自己的定位认识不清。他们只是被动地等预测，而没有意识到自己也是预测过程的一部分，至少应该盯紧计划，促使他们早日生成预测。 其次就是从供应的角度判断、量化库存风险，供营销和计划参考，上面已经提过。另外，供应商往往接触多个客户和行业，对市场变化有独到的认知，例如他们可以从别的客户处感知市场在升温还是降温，从而预知下一步是出现短缺还是过剩。例如在2009年的元器件短缺前，很多供应商早就感受到了，而主机厂则没有。原因很简单：供应商在采买元器件，主机厂越来越少介入。这个信息，如果及早反映到主机厂的话，主机厂可以适当建立库存、增加采购前置期等，以便积极应对。而这类信息传入主机厂的主要渠道就是采购。要明白计划是在平衡预测需求和供给，如果供给情况可能有变，是采购的责任提前告知计划。等交期到了或者快到了，采购才知道这货没法按时拿到，那太晚了，又成了"小采购"。 这里还需要说明的是，多职能参与并不意味着没有单一责任人。在很多公司，预测的责任机制不很明确（或许这部分解释了这些公司为什么运营地不够理想）。这种情况下，最简单的就是责任倒逼：采购/生产/运营向计划部门要预测，计划部门就成为直接责任人；计划向产品/销售要预测，产品或销售就成了直接责任人，依次类推。要避免的是计划说销售没有预测，所以啥也做不了，拖着，出了问题就往销售推；销售就怪市场、怪竞争对手和客户，结果就是不了了之。这是极端不负责任的做法，对不起我们拿的一份工资。销售看不起运营和采购，往往跟后者的这种不作为有关。而运营、采购之所以没出息，也在于他们在预测过程中没有履行自己的义务。用柯维《成功人士的七种习惯》里的说法，就是他们太dependent on（取决于）计划与销售，而没意识到自己也是解决方案的一部分，各部门都是interdependent（相互关联）的。这种采购还是典型的"小采购"心态。只履行管理供给的职责、不履行管理需求/预测的职责，采购永远摆脱不了"小采购"的帽子。 规则3：预测不是一锤子买卖，需要循环预测，逐渐逼近。 预测刚开始的时候都不准，需要不断循环预测，及时纳入新信息，修正预测。一个销售预测，从产生到采购、生产完工，变动是正常的。不正常的是没有循环预测机制，及时来修正预测。管理不善的公司往往忽视这点，对预测的修正频率不够，修正往往是拖到最后一刻做，而这时候采购的料已经在途，生产线上的半成品也快完工了，呆料、积压就不可避免了。缺乏循环预测机制，没有逐次“微变”的过程，一变就是巨变，供应链很难一下子消化，就成了问题，要么是短缺，要么是积压，都带来成本。 计划、运营和采购的人经常诉苦，说最后一分钟的销售计划变动如何害苦了他们。我从来不相信这变动就是最后一分钟发生的。相反，这一定是个过程，销售人员一定在某个时候就知道大致有多大的可能会变动。他们不愿意主动说，因为有他们的顾虑；计划、运营的人主动问了没有？我管理全球计划团队多年，出现这样的问题，我问的第一个问题就是做销售的没说，那我们做计划没问？他没主动说，打他的板子；你没主动问，同样罪在不赦。 图：任何需求都有个“十月怀胎”的过程 图片来源：http://blog.jreevesphotography.com/wp-content 那循环预测的场合是什么？产销协调会。凡是个生产性公司，这个协调会都有，不管是正式还是非正式的。问题是，在有些管理不善的公司，这协调会大多成了走过场，成了销售与生产、采购互相揭短的"批斗会"，而不是共同解决问题的场所。有个公司压了很多库存，都是产销不平衡造成的。问有没有产销协调会，说有。问多久开一次，说今年已经开过一次了。好样的，今年都小半年了，你就开了一次？相反，另一个在行业里领头的企业就做得挺不错，每周销售与生产、物料的协调会雷打不动。销售带来销售预测，生产带来各地的成品、半成品库存信息，采购带来在途库存，大家三头一凑，就能很好地修正预测。 ------------------------------------------------------------------- 2016年1月份，我来深圳和上海，围绕我的畅销书，第78、79次推出专题培训。这个培训从一个实践者的角度出发，聚焦采购与供应商管理，为期1天，安排在周六。 应众多读者要求，这次是大课，以降低成本，希望更多的人能够负担得起学费。人数限制在100人，招满为止，现在就报名。 培训名称：《采购和供应商管理：一个实践者的角度》 时间地点：深圳（1月16日，周六）、上海（1月23日，周六） 培训费用：2500元/人（公司付费，开国内咨询类**） 1500元/人（公司付费3人及以上，或自费。自费开美国**） 800元/人（自费2人及以上。自费开美国**） 报名详情，请联系我的助手吴**177 2795 9069 | info@scm-blog.com。 谢谢。我们培训现场见。 刘宝红 | Bob Liu 畅销书作者，供应链管理专栏创始人（www.scm-blog.com） 专著《采购与供应链管理：一个实践者的角度》第2版全新出版，继续领跑畅销榜  

   首先先从这方面来开始讲诉自己对于需求文件的一个概况“软件项目开发过程中需求文件”。见于 http://wenku.baidu.com/view/5c14e71fc281e53a5802ff4d.html?re=view， 真实情况来说以这张ppt来开启今天所要讲诉的一个话题。   对于软件来说如果能够按照这上面一系列的文档来验证的话，我相信我们的产品即使有着bug，但是对于当中一些的功能还是比较信得过的.而对于软件，这边我们需要扩散一个知识点---CMMI,而啥叫能力成熟度模型综合。请看下面这张图。   如果大家想要了解这方面的知识点，请看这份文档“CMMI体系简介及软件工作流程”； http://wenku.baidu.com/view/37df9ccfda38376baf1faec7.html ，有点扯远了，那么接下来话归一点，作为硬件来说要出哪些文档呢？ 假如大家想要了解这当中的要求的话，请见于这份文档“硬件开发流程及规范” http://wenku.baidu.com/view/636c6b60ddccda38376baf4a.html ，其实真正来说今天我要讲的是当中自己的一些有关于这方面的一个体会，就是一个项目要真真正正的出来需要那些文档，    首先是基本功能需求；            诊断需求；            接口需求；            总线需求；            刷新需求；            ODI需求；            DBC文件；            需求规格书；            OS功能需求；    针对这些文档都会有相应的规范，而这就是相应的客户的要求或者是自己的公司所要求的，当然了自己之针对这当中自己所接触的一些项目而已才敢于说这样的话题，而这个是站在一个项目的总体方面，如果你想要全面的了解，就需要你必须要把当中的规范给各个击破，而对于上面所出的一些什么硬件设计说明或者是PCB设计规范都是需要根据相应的规范而来的，所以对于我们来说本质方面就是了解相应的规范，好做相应的对策与分析。就好比你去做硬件设计的时候需要去参考客户的需求以及当中GWM14082，而对于当中的DV验证你就必须要参考GWM3172，做EMC的话你就要参考GWM3097是通用的道理，只不过我们所做的就是依据当中来编制相应的文档。    本篇博客资料见于百度云分享； http://pan.baidu.com/s/1mgkuq28

   随着嵌入式处理器尤其是 ARM 处理器的广泛使用，嵌入式操作系统也曾爆发之势。对于初学者来讲以哪种系统作为学习对象成为一个问题。之所以说初学者，因为对老鸟来讲从一个系统转换到另外一个系统并不是一个费力的过程。但对初学者来讲，学的太杂会出现一直在低水平徘徊的危险。    由于市场的需求是多种多样，必然产生的嵌入式操作系统也是多种多样。由于本人一直从事信号处理相关行业，自然关注的也是对高性能 CPU 比较友好的操作系统。从个人的角度看，一个操作系统至少要有这么几个特点。 1、 实时性能，实时不仅仅意味着反应快，也意味着程序效率，对信号处理来讲对性能和效率的追求是没有上线的； 2、 要有相对完整的驱动框架，可以让内核和 BSP 分别开发而不要融合在一起； 3、 能够实现应用与系统的分离，不然每次改动程序都要更新整个系统，有些太麻烦，如果客户需要二次开发的功能，简直就无能为力了； 4、 有独立的调试工具，目前 GDB 是比较常用的调试手段； 5、 最好有自己的开发环境，不过如果包含上面功能，一般都必须要有自己的开发环境了，有开发环境可以大大的提高工作效率； 6、 可以裁剪，毕竟对嵌入式来讲，不必要的功能会占用宝贵的资源，影响效率。     如果能够开源就更好了，开源的好处对商业来讲意味着比较大的自由。一个自由是可以减小项目开始的投入，想买就买不想买也没人逼你，毕竟还没商用。不必去花钱购买一套软件，往往这种软件价格不菲。项目成功或者盈利后这些花销或许不是什么，但在开始对很多中小公司或个人来讲项目开始就有这么大的投入还是有些压力的。    另外一个自由最重要，可以根据自己的需求特点对系统做些更改或扩展，我想 Linux 之所以如此火爆，这个应该是个很重要的原因。想象一下，如果 arm 绑定 Windows 发展，那多核和大小核的应用要等到猴年马月。从市场的规律看，供给总是落后于需求，这种扩展的灵活性一方面可以避免被人卡脖子，另一方面也给形成自己的独特优势提供了可能。

看着今年带的嵌入式队伍慢慢的发展起来，都能基于msOS做一些实际的项目，心中也挺欣慰。在对他们的培养过程中，让我感受最深的，不是他们技术问题，而是他们无法理解需求，不知道为什么要这个功能，导致很多疑惑，而这个疑惑，对我来说觉得很正常不过的，他们却一点都无法理解。   比如我一个同事，她无法理解，程序中为什么需要存储单元，所以看不懂代码，在她眼中，程序只要起来，运行即可啊，在我给她举了不少例子，比如手机密码，电话本，短信等，这些设置之后不能一掉电就没有了吧，她才恍然大悟，这些其实都是生活中的东西。   比如按键部分代码，里面涉及到一个叫JitterCounter的计数器，从名字上看就知道是抖动计数器，跟抖动有关，但这个大家不容易看明白 ，这次写msOs文档，我专门把这个词改了，改成DoubleHitCounter，看名字就可以知道跟双击有关，而按键，很容易因为接触不良导致双击，尤其是鼠标，用久了会导致双击事件。这个是DoubleHitCounter变量引入的原因，是防止二次点击产生。 需求源自生活，只有对生活敏感的人，才能真正理解的好需求，而本身对生活不敏感的，那只能做大家所谓的码农了，虽然很辛苦，但除了辛苦还是辛苦，不值得同情。所以msOS的文档，尽可能从需求入手来写作，每一个功能的引入，首先要讲它原来碰到了什么问题。 技术只是用来描述我们想要的需求，借用msOS群内网友小皮的一句话：所以有时候看起来是外行人却还把一个产品作成了，从本能需求入手 。

  经常有朋友感叹，现在生意难做，贸易利润越来越低，做产品呢，不知道做那种产品好，于是经常接触各类人群，去打听现在哪方面有需求，可以做做生意，做做产品。 这个方法没错，绝大部分人都是这么做的，但有一点是有疑问的：别人说的就是对的吗？靠自己调查的几个样本就能准确吗？若这类人群普遍觉得一样东西该做的时候，他们为什么不去做而等你去做呢？真正的商机，别人会告诉你吗？ 我认为，大部分人都看到的东西，一般是不值得做的，就算你做了，可能是帮别人做的，并且这个最后就是拼资金，所以具有雄厚实力的企业，往往做大部分人都认为对的事情，因为他们会在最后的竞争中胜出，而其他的竞争者，只是帮他培育这个市场罢了。 那作为一个小创业者，他的需求来自哪儿，我认为，来自自己的真实需求，自己在一个行业内混久了，总能获得不少同行的抱怨，这个抱怨就是需求，自己在使用这些行业内的东西，总有一些地方不方便吧，这个就是需求，只要我们把这类需求解决了，那就是商机，何必苦苦的求别人呢！ 自己物料不好买，就能想到别人也可能不好买，这个就可以做贸易了，自己觉得不好用，就能想到别人也可能觉得不好用，就有改进的余地了，这个就可以做产品，或者改装产品了，等等，博主的电阻电容电感样品本怎么来的，就是因为自小觉得买这类小东西不方便，存放也不方便，于是就想到别人也有这个问题，就有了创易电阻电容样品本。博主觉得手机很好，可以当作一台低成本的移动电脑，接各类传感器即可成为一个设备，想到别的电子爱好者也有这样的想法，于是就把手机开放出来，就有了手机开发模块，今天，博主觉得进口的PLC太贵，国产的价格还可以但还是有些贵，并且质量也不认可，梯形图对于我来说不熟悉，于是想到一部分嵌入式人员也有这类的想法，就开始着手做msPLC，开源解决自己的需求，同时把一部分的嵌入式人员的需求也解决了。 经常有这样的思维，出来一个个的成果，于是影响了身边的人，兄弟公司也把这套思想应用于他们机械自动化行业，满怀信心。 真正的需求，来自于自己。