【请教】请问如何将看板管理库存和传统ERP系统中计划运行后的送料生产结合起来。

swordagan

我们已经做到生产线的物料配送管理和erp的完美结合，erp是qad，物料配送模块是定制开发。
前面有个介绍是通过卡片进行管理。我们在实施时主要还是靠工位电脑。物料部门可以了解
工位需求，工位物料消耗实时扣减，系统自动物料报警。通用件和专用件管理相结合，采用不同的发料方式。产品下线后物料自动回冲。整个系统把计划，装配，物料，物流跟踪结合在一起。是erp系统的补充和扩展。案例可参考重庆康明斯MES系统。

icepoint

最初由 smallwood 发布
[B]我试着说一下吧
在使用KANBAN的MRP系统中，MRP的运算任务仍然是需要的

MRP的运算用于较长期（可能是1周-1年）这样时间短内物料的需求状况。
这个计算的结果用于向供应商下达指导性的订单（并非实际的要货指令），在内部，这个计算的结果用于计算将来的时间短内是否存在产能上的约束等。

在使用KANBAN的层级，实际上是操作级和短时间跨度的。
供应商已经接到了MRP运算的预测计划，接下来KANBAN将作为交货的指令，在运行比较稳定的一个系统里，供应商收到看板后，在规定的响应时间内就需要把物料送至客户的指定地点。
（具体的运送方式，很可能是MILK RUN的形式；此外，实际使用中的向供应商发出的看板已经未必是实际的卡片，现在已经开始通过EDI系统或者由供应商自行登陆客户的指定网络地址，获取“看板”）

同外部的联系基本如此

至于企业内部，其实最初看板在使用的时候，是没有MRP系统的。
在20世界90年代，人们才意识到ERP和JIT的结合，此后关于这些方面的论述很多。

一般的所谓结合，只是在物料管理部分实现条码的读取，看板的打印等，库存通过看板的数量来控制，而看板的张数可以在系统中调节（例如冻结部分看板）

///////////
至于拉动还是推动 通常是这样认为的：
KANBAN 是拉动式的，因为从操作层看，是前工序按后工序的消耗或者指令进行生产

而计划生产，则可能是推也可能是拉
比如按照订单组装的模式（ATO），就是前推后拉 [/B]

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
谢谢你的回复。可能我对看板的理解不是很准确，但我不是很理解你所说得供应商收到“kanban”后给厂商送料的这个流程和原有的mrp有什么区别？
既然供应商通过某种渠道能得到厂商的“送货命令”也就是“kanban”，以此为送料的依据对厂商发料，然受厂商接收检验入库后通过设定的数量转换公式转换成库存数量，以此数量接收记录来匹配供应商开过来的发票。那在某种程度上“kanban”和原来mrp运算出来的计划采购单有什么区别？不都是一个单据到供应商那，然后供应商供货（料），然后到时间了付款并匹配收货（料）的记录，那看板的优势在哪？

icepoint

最初由 hzauer110 发布
[B]例如，一标箱是10套，也就是1*10=一标箱，只有一标箱用完了才会去取下一个标箱，但由于10套用得快，也就无须去统计，那一箱到底剩下几套。卡只对标箱。但是这样的办法适合标准件，要是那些大规模定制生产或非标品多的工厂，我看还是用BOM+MRP比较好。

即使对于重复生产的企业，完全的拉动好难做，一般而言在工艺流程中的几个工段的结合点上都会布置缓冲库存。缓冲库存的量受影响的因素比较多，包括生产节拍、缺料的历史统计等。 [/B]

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
这边所说的“套”是不是标箱中存放了多种物料，还按照工位的要求分成的“套”？那如果有报废或是质量问题怎么办，可能一“套”中就一个物料有问题，那这一“套”都要回退？那核算的时候怎么理清楚那些“套”中的那些物料有问题，不可能这一“套”物料都报废吧！

icepoint

11楼，你们的物料配送模块的设计思路是怎样的，是怎么和erp系统做结合的。有相关的介绍资料吗？能不能共享出来啊，呵呵，方便的话。

smallwood

最初由 icepoint 发布
[B]

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
谢谢你的回复。可能我对看板的理解不是很准确，但我不是很理解你所说得供应商收到“kanban”后给厂商送料的这个流程和原有的mrp有什么区别？
既然供应商通过某种渠道能得到厂商的“送货命令”也就是“kanban”，以此为送料的依据对厂商发料，然受厂商接收检验入库后通过设定的数量转换公式转换成库存数量，以此数量接收记录来匹配供应商开过来的发票。那在某种程度上“kanban”和原来mrp运算出来的计划采购单有什么区别？不都是一个单据到供应商那，然后供应商供货（料），然后到时间了付款并匹配收货（料）的记录，那看板的优势在哪？ [/B]

还是时间跨度的问题
举个例子 假设每天可能发出8次看板（甚至是12次）
供应商按照看板的内容送货（可能每次发出的看板对应的货物的种类和数量都是不同的）

想一下 MRP能在一天内做8次运算么？

当然  我举的是个极端的例子

注意：你不能把一天的8次货一次送到，因为客户那里没有地方可以放的

icepoint

mrp为什么要做8次运算？一次运算不就可以生成不同的计划采购单吗，对仓库中缺料的原材料进行采购，把单据传到供应商那就可以了。

还有“kanban”到底是管理生产厂商内部的库存还是把供应商的库存也给管了，如果“kanban”发出一次供货命令，供应商就要根据命令发一次货，那对整个系统的要求是不是太高了，对物流的压力也太大了。我要是供应商还不如在你仓库里给你建个备件库，你要多少料你自己去取，时间到了结算一下。

sallywish

关注。。。。。。。

smallwood

最初由 icepoint 发布
[B]mrp为什么要做8次运算？一次运算不就可以生成不同的计划采购单吗，对仓库中缺料的原材料进行采购，把单据传到供应商那就可以了。

还有“kanban”到底是管理生产厂商内部的库存还是把供应商的库存也给管了，如果“kanban”发出一次供货命令，供应商就要根据命令发一次货，那对整个系统的要求是不是太高了，对物流的压力也太大了。我要是供应商还不如在你仓库里给你建个备件库，你要多少料你自己去取，时间到了结算一下。 [/B]

抛开一楼的问题
仅就这段话说一下吧：
1。“对仓库中缺料的原材料进行采购”

客户没有库存的，没有仓库，因为谈到看板的起源，就是丰田在用
就现在丰田使用看板的情况，客户那里一般有40分钟到一小时的“库存”  
为什么？    不为什么  零件太多 体积太大 没法放

那么 送8次货应该是必须的了

２“一次运算不就可以生成不同的计划采购单吗”


仍然看汽车制造企业　在什么时间才知道要生产的车子的型号呢？？　

在汽车总装生产线的某个工位点，姑且称为关键工位吧，过了这个工位，才能知道这辆车生产出来是什么样，此前没有人知道的。
谁决定呢？　市场。

对供应商来说，车子过了这个点，才知道要不要天窗，什么颜色的内饰，发动机是１。６还是１。８　，变速箱是手动还是电动　　等等

那么，ＥＲＰ如何提前跑出来准确地订单数量和到货时间呢？　

一旦做不到，很显然要么造成很大库存，要么就会生产线断线。


好了，那么一定会有这样的说法：汽车制造厂为什么不事先确定下来生产什么型号的车子呢？　这样供应商不就好做了么？　

那问问上海通用去，通用曾经失误的生产了数千台蓝色的别克（没有按照市场来生产），损失严重。

说了这么多，其实就只有一句话：供应链的快速响应


如果忽略了这句话，根本无法理解高频次送货，无法理解ＪＩＳ供货。因为始终是想办法逃避，事实上，逃避不了

集约的，快速响应的，少库存的丰田获得了竞争优势，连续１７年获利。


３“我要是供应商还不如在你仓库里给你建个备件库”
“那对整个系统的要求是不是太高了，对物流的压力也太大了”

必须有响应很快的系统作为支持的

我对戴尔的系统不了解，但是我猜测一定也是快速响应的。同时，供应商也不会有太多的库存的。

“我要是供应商还不如在你仓库里给你建个备件库”

既然能实现每天多次的配送，那么库存总是有的。
两种：其一就是供应商就在客户附近，所谓的“备件库”就是供应商的成品库，一般也会有部分的库存。

所以，＂备件库＂已经有了。　　如果再建库，没有意义，备件库需要捡货，装车，没有任何节约。


另一种情况，具体点，比如轮胎吧，一定是在客户附近备有大量库存的。
因为客户不放心远距离的及时配送。

smallwood

供应链的快速响应
供应链整体库存的减少

如果不承认这两句话　那么讨论都无意义了

smallwood

想了下你一楼的问题
１。丰田使用看板的时候，还没有ＥＲＰ
２。即使没有ＥＲＰ，也可以使用看板
３。看板和ＥＲＰ的结合，在不同方面有不同的理解

比如思想上，９０年代确立了两者的结合，之前业界有过很大范围的讨论

操作的结合方面，就是一个长期、运营层；一个短期，操作层。

软件的结合方面，不好说　ＳＡＰ　　ＯＲＡＣＬＥ　　ＱＡＤ都有看板的模块

金碟　神州数码也有的

这些模块就是把看板功能结合进去了
比如可以打印看板，可以接扫描枪扫描，可以冻结看板。倒冲销账　等

再具体的话，恐怕一个软件一个样子了