【译】负库存:你所不知道的东西会让事情变得更糟糕

“那不可能!”

“我们怎么可能有负库存呢?”

“什么样的库存数量会比没有更少呢?”

“它是不是像个黑洞,在库存存在之前就将它吸收掉?”

“负库存是不是像反物质?如果它正好跟正库存相反,那它会在连续的时空中创造一个裂痕吗?”

面对着负库存,人们可能会变得非常兴奋,因为这个概念听起来相当可笑。让人奇怪的是,负库存是一个非常常见的现象,它可能甚至是一些流程的“正常”环节。尽管负的库存余额当然会反映某些问题,但是那不并代表你必须人工将库存调整回来才能修复它。在某些时候,负库存只是一个时间问题。举个例子,假如物料刚刚完成生产入库和出库装运,但是出库装运的事务可能会比汇报生产完成的事务要早处理完。这会产生一些临时的负库存余额,直到生产完工的数量汇报事务处理完成。当然,你可以强制要求生产完工入库的事务处理要优先于产品的装运出库,但事实上,无论谁先完成,并不会产生多大真正的损失。因为当生产最终完工入库后(希望在同一天的晚些时候),数量最终还是会正确的。

事务处理的时点当然不是导致负库存的唯一原因。任何会影响现有量余额的事务都可能导致负库存,如果它没有被正常的执行。重要的是,我们能够将由于事务处理时间差导致的负库存与由于事务处理错误产生的负库存区分开。同样地,我们还要明确区分地点级负库存和物料级负库存。

地点级负库存余额

当一个事务的地点弄错了或者地点转移事务的数量弄错了,地点级负库存余额就可能会产生。举个例子,假如我有100个物料存放在地点“X”,接着销售发运了50个,但是一不小心将这50个从地点“Y”发出去了。最终结果是,地点“X”中依然有100个物料,而在地点“Y”就会显示-50。尽管在地点“Y”中产生了负库存,但物料级库存余额(所有地点的库存相加)50个是正确的。当你进行物料在地点间转移时,你录入一个错误的来源地点或者录入的数量大于真正转移的数量,类似的情况也一样发生。例如,我有100个物料存储在地点“X”,并且将其全部转移到地点“Z”,但是错误地将转移的数量录入为1000,那么就产生这样的结果:1000个物料在地点“Z”,-900的数量在地点“X”。同样地,在物料级的库存100依然是正确的。尽管地点级库存余额会给仓库管理带来问题,但是这不会影响计划系统。


物料级负库存余额

那就是说,物料级的负库存余额则会影响计划系统。这类负库存的可能是由各种各样的事务处理错误导致的。报告了比实际情况多的废料数量,周期盘点调整错误,运用倒冲法时报告了比实际情况多多的产成品数量,发料过多,重复的事务,以及销售发运过多都可能是导致物料级负库存的原因。


纠正负库存

我们要区分清楚各种负库存的原因是为保证后续采取的结下负库存的行动不会让库存问题变得更严重。如果你要去调整一个由时差原因产生的负库存,那就产生库存问题,因为一旦延后的事务处理完后,库存数量就会由于你调整的事务而变得不准确。同样地,你去将地点级负库存调整过来,也会产生问题。让本来是正确的物料级的库存余额变得多了。

跟时差问题无关的物料级负库存同样在采取任何行动前也要仔细调查清楚。一般来说,你需要明确其产生的原因,然后用同样的事务处理程序去录入抵销其影响的事务。对于制造系统来说这更是如此。因为不正确执行的事务可能会导致除了本物料之外其他物料也产生错误(例如:采用倒冲法的事务处理)。

尽管负库存看上去蛮复杂的,但他们实际也很容易处理。只要通过一张报表将所有小于0的物料现有量库存显示出来,就是我们所需要找到的负库存记录。另外,一般情况,也很容易去定位产生负库存的来源,因为错误的事务就是那一条将库存变成负的事务(如果不是的话,那它也很可能发生在负库存产生不久前的一个时间段内)。


负库存对计划系统的影响

除了要了解清楚负库存产生的原因之外,我们还要知道它对计划和执行系统的各种影响。在大部分计划系统里,一个物料级负库存一般都会当作是正向的需求。基本上系统会告诉你去制造或者采购更多物料来抵销掉这部分负库存。明显地,当负库存余额很大时这会成为一个大问题,同时,在某些特定情况下小额的负库存也会带来不少严重的问题。举个例子,你将一个物料设置为按需制造或生产(order as needed),就是说只当有实际需求(订单)才会采购或制造存储的物料,一个错误的调整让其余额变成了-5,那么系统就会自动推荐一个5的采购。不过按需制造或采购的设置一般是针对那些滞销或者过时的产品,你可能只是增添了一个过时的问题。在一个制作系统里使用MRP,一个负余额的顶层物料会通过物料清单结构产生级联的需求:这样很可能会产生成百上千的低层物料的订单。当你的系统处理负库存的逻辑跟正常一样的话,以上情况就会发生。某些程序,无论是有目的的还是编程编得不好,遇到负库存时可能并不会按不能正常的执行。它们可能直接忽略这此负库存的记录或者直接报错,因为他们本来就不是设计出来去处理负库存的。

尽管在遇到负库存时不让一个程序执行下去有一定的合理性,但是这样做也会带来一些潜在的问题。因为你实际上是需要执行一些正常的业务处理,但是由于负库存导致计算给延迟了,你无法获取足够信息去支持你的业务操作。由于需求计划系统的复杂性,特别是MRP/DRP这些系统,其实在编程过程中并没“最好”的方法去处理这些负库存问题。像仓库管理系统和制造执行系统这样的执行系统一样会遇到由负库存产生的问题。或许你并不希望去为了负库存问题而去刻意地修改你的系统处理逻辑,但是你至少也要了解到当你的系统遇到负库存时会发生什么。

最终,在开始的时候避免负库存就成了最好的解决方案。然而,要做完全避免负库存是非常困难的,所以你需要制定一个备选方案。既然目前大部分的计划系统依然采用批处理模式(在晚上或者周末运行),你可以在运行这些程序前处理掉所有冲突以便消除掉所有的负库存余额。当然,执行系统一般情况都是实时运行,你就不能这样奢侈了。所幸的是,一般情况下对执行系统的影响要比计划系统的影响小得多。

在这里,我依然想不厌其烦地再强调一下,你必须在修复负库存之前仔细想清楚你的每一个行动。简单地,想通过运行一张报表然后将其全部直接调整回去的想法肯定引发其他更多的问题。记住,你不能对由于时差原因产生的负库存进行调整,你只需要使用地点转移程序去纠正地点级的负库存问题,然后通过在产生负库存的同一程序里录入抵销的事务来处理其他原因导致的负库存问题。

原作者是:Dave Piasecki,通过美国的CPIM(生产与库存管理认证),东南威斯康星州和伊利诺伊州东北部的制造商和分销商提供服务的一家咨询公司咨询公司的所有者/经营者。他在仓储和库存管理拥有超过15年的经验,可以通过他的网站(http://www.inventoryops.com)获取额外的相关信息和链接。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14925582/viewspace-712681/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/14925582/viewspace-712681/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在信号处理领域,DOA(Direction of Arrival)估计是一项关键技术,主要用于确定多个信号源到达接收阵列的方向。本文将详细探讨三种ESPRIT(Estimation of Signal Parameters via Rotational Invariance Techniques)算法在DOA估计中的实现,以及它们在MATLAB环境中的具体应用。 ESPRIT算法是由Paul Kailath等人于1986年提出的,其核心思想是利用阵列数据的旋转不变性来估计信号源的角度。这种算法相比传统的 MUSIC(Multiple Signal Classification)算法具有较低的计算复杂度,且无需进行特征值分解,因此在实际应用中颇具优势。 1. 普通ESPRIT算法 普通ESPRIT算法分为两个主要步骤:构造等效旋转不变系统和估计角度。通过空间平移(如延时)构建两个子阵列,使得它们之间的关系具有旋转不变性。然后,通过对子阵列数据进行最小二乘拟合,可以得到信号源的角频率估计,进一步转换为DOA估计。 2. 常规ESPRIT算法实现 在描述中提到的`common_esprit_method1.m`和`common_esprit_method2.m`是两种不同的普通ESPRIT算法实现。它们可能在实现细节上略有差异,比如选择子阵列的方式、参数估计的策略等。MATLAB代码通常包含预处理步骤(如数据归一化)、子阵列构造、旋转不变性矩阵的建立、最小二乘估计等部分。通过运行这两个文件,可以比较它们在估计精度和计算效率上的异同。 3. TLS_ESPRIT算法 TLS(Total Least Squares)ESPRIT是对普通ESPRIT的优化,它考虑了数据噪声的影响,提高了估计的稳健性。在TLS_ESPRIT算法中,不假设数据噪声是高斯白噪声,而是采用总最小二乘准则来拟合数据。这使得算法在噪声环境下表现优。`TLS_esprit.m`文件应该包含了TLS_ESPRIT算法的完整实现,包括TLS估计的步骤和旋转不变性矩阵的改进处理。 在实际应用中,选择合适的ESPRIT变体取决于系统条件,例如噪声水平、信号质量以及计算资源。通过MATLAB实现,研究者和工程师可以方便地比较不同算法的效果,并根据需要进行调整和优化。同时,这些代码也为教学和学习DOA估计提供了一个直观的平台,有助于深入理解ESPRIT算法的工作原理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值