配销需求规划drp【一】：mrp运算逻辑(上)

《配销需求规划drp【一】：mrp运算逻辑(上)》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、配销需求规划【】：（上）──以时尚消费商品之流通领域为例GR()=PO()+Fsc.()+GR(PastDue)()+Sys.RGR(t)=PO(t)+Fsc.(t)+Sys.R(t)()()(PastDue)()POH=OH+SR+SR-AL-GR(t)(t-)(t)(t)POH=PAB+SR-GR(T)(T)(T)(T)ifPOH>=SSthenNR=0elseNR=SS-POHPORC(T)=ifNR(T+)>0thenmax{NR(T+),LS}elsePORC(T)=0(T)(T+)POR=PORC本文是〈配销需求规划DRP〉系列篇章发表的第一稿，主要讨论物料需求规划MRP相关技术

2、；但因MRP在整个企业运营规划体系架构中牵涉甚广，包括BOM的构造及开展、MPS管理流程、PAC生产控制、产销模式与销货预测、批量法则与存货政策…，等等相关专业技术领域，为免失焦，本文将讨论的范围集中在MRP的运算逻辑。上列图例，是其基本框架。从MRP到ERP所谓运算逻辑，即IT专业领域中经常提到的演算法Algorithm。实务上，这是让很多软件编程师或IT项目经理伤透脑筋的课题；能够编写功能函数(function)的工程师很多，但真的能夠合理而有效定义演算法的工程师很少。在1950、60年代，MRP最早的雏型就是以相当于一种演算法的型态出现，这时电脑的应用，才刚开始不久，大型商用电脑还处

3、于实验室验证阶段，个人电脑PC尚未诞生；MRP相关技术应用的渐次普及，则是70年代后随着电脑应用的普及化而渐次展开。在此基础之上，在80年代则有所谓MRPⅡ制造资源规划(ManufacturingResourcesPlanning),以及90年代开始流行的ERP企业资源规划(EnterpriseResourcesPlanning)。在国内，ERP这个词汇经常可以听到，大部分与商业或企业经营管理有关的功能软件，都会被冠上这个＂称号＂；但听过MRP的却很少，能理解应用的又更少，包括IT专业背景的技术人员、专家顾问也不例外。但实际上，MRP是ERP的核心，相关的产能需求规划CRP、配销需求规划DR

4、P、生产活动控管PAC等等，皆与之密切相关，其核心机制，都由MRP运算逻辑推导出来。可以这么说，MRP是ERP的核心，而MRP的运算逻辑又是核心中的核心。也唯有掌握住核心关键，才有可能因势利导，以不变应万变，面对实务上遇到各式各样的瓶颈或问题，开发出相应的解决方案。若不能究明其中根由，仿其形而失其神，追求无谓的管理机制或工具，舍本逐末，白白浪费资源而已。我们先不说什么是MRP，在此先告诉各位，MRP有一个「谑称」，MoreRidiculousPlanning更可笑的规划。这样的说法或看法，其实与所谓＂ERP是骗人的＂这种思维大同小异，同属似是而非，相关论点请参阅《转型为ITConsultin

5、g的巽风堂》。当然，之所以会有这样的误解，其来有自。打开百度，查寻MRP有关的文字讯息，大部分的中文资料都将MaterialRequirementsPLANNING翻译为物料需求计划；那么，这就会产生一个问题，就是MaterialRequirementsPLAN应该如何理解。若真正理解MRP的人，必然知道两种MRP之间的区别与它们各自在实务上的功能和位阶，必然知道POR这个动作在真正Release之前和之后应该有什么不同的考量？对系统有何不同的影响？各种数据资料属性究应归属于规划档(PlanningFile)、交易档(TransectionFile)，又如何关联到主档(MasterFile)

6、？当规划档或交易档与客观现实不相符时，要怎么去分别因应？EST与LST、Forward与Backward在MRP逻辑当中是如何取舍？时间栅(TimeFence)如何设定和调控？真正理解MRP的人，必然明白这两种MRP，绝不只是后面有没有ing的差别而已；更别说，美国企业资源管理学会APICS出版的字典，已将两种MRP予以明确的界定。在国内，各种概念转译的过程中，类似这种Ridiculous的事例不在少数；例如，把消费者对品牌Preference的经营被理解为品牌＂美誉度＂的提升，又把编程取向的Object-Oriented说成是＂面对对象＂，后文会提到的LeadTime在清华大学出版社出版的

7、J.R.TonyArnold教科书中文译本中竟变成＂提前时间＂。笔在一再强调，对事物的理解认知不同，相对应的行为取向自然有所不同。荒谬多由误解造成，然而，误解多半不是因为它本身难以理解，而是因为＂格义＂，即用已知去理解未知。如此一来，还是在原来的框框打转，不但未能跳脱出原先的认知界限，反而带来更大的障碍。笔者的想法是，趁MRP相关技术还没被大规模＂糟踏＂之前，花点力气说清楚，应该是有必要的；虽然会认真去看这种