× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: BPCS MRP vs. KANBAN
  • From: "Tim Armstrong" <tma@xxxxxxxxxxxxxx>
  • Date: Mon, 9 Aug 1999 22:04:22 -0500

e-mail from Al at Tim's PC at work

>BPCS 6.0.02plf full C/S on an AS/400
>
>We have been live on BPCS for almost a year.  Prior to BPCS we had a
homegrown
>system built around a manufacturing package that was almost as old as
DBOMP.
>We did not run MRP in the old system.  Inventory demand was controlled by a
>safety stock trigger mechanism that alerted the buyer each day.  We did not
run
>shop orders of any kind, using instead a homemade customer order scheduling
>system.  It may not have been sophisticated, but it was simple and easy to
use
>and to understand
>
>Now to the question..
>
>Over the years the manufacturing group at our company had implemented a
facility
>wide Kanban system.  We have been unsuccessfull at integrating the MRP with
this
>system.  If there is a company out there that has integrated Kanbans and
MRP, we
>would like to talk to you.
>
>Reply to the List, or off line to lfry@tokheim.com

The issue is whether you want or need to run the business
by KANBAN
by MRP
or by some mixture.

As I understand KANBAN, inventory is stored in containers that include
re-order information & when the last bin is opened, or when the on-hand
quantity reaches some thresh-hold, the re-order document is used to order
replacement stock, and thanks to the miracles of bar coding - the re-order
document does not have to leave the supply that is left.  However, it is not
unusual to have several KANBAN re-order cards with the inventory - one is
pulled each time some stock is re-ordered & that card is used to define what
is to be re-ordered, then when the replacement stock arrives, it is also
accompanied by the appropriate number of re-order cards.  Historical
analysis has been used to estimate how much you want to have on-hand at any
given moment, and this is re-visited as the BOM mix of common sub-components
shifts with new business & engineering changes.  MRP, on the other hand,
predicts what will be needed, and generates orders to replenish before you
run out.  Safety stock can be used with MRP - it generates orders so that
not only do you not run out, you should not dip below the safety stock
volume.  Thus safety stock in your item masters can be perceived as a
virtual KANBAN system with MRP running your business, instead of a reliance
on the visually reassuring punched cards mentality, where it does not matter
how accurate the data is in the computer, the point of re-order cards are in
plain sight.  Either system works.

BPCS JIT is conceptually similar to KANBAN.  Instead of using MRP540 to
generate shop orders off of planned production orders, you use JIT540.  Your
production paperwork can still be generated via SFC520/SFC550, or use
JIT550.  SFC60* & JIT60* are also interchangeable depending on whether you
want to report labor independently of inventory transactions.  We have been
using some JIT - you need to chat with a BPCS site that uses it much more
heavily than us.  Many SFC reports, such as SFC230, have their JIT
counterparts, such as JIT275.

Here are some ways you can tell the difference between SFC from MRP, and JIT
with BPCS, which I transcribed from our BPCS documentation.  Some of the
differences may be BPCS version on hardware platform specific.

CIM supports production reporting via bar coding - in which it does not
matter whether you use SFC or JIT - CIM still works conceptually the same
way to get your reporting into BPCS.  However, you might want to incorporate
bar coding onto your KANBAN re-order inventory cards.

KANBAN is an alien concept to SFC, from MRP
KANBAN re-order cards can be released as part of a JIT production order.
Since we are not using these cards, it may be that BPCS is misusing the
concepts, compared to my understanding of this concept.

SFC captures labor by shop order.  Some other transaction is needed for
reporting inventory.
JIT updates labor & inventory by shop order or item #, as one consolidated
entry.
We use JIT for 99% of our labor & inventory reporting, with SFC for minor
corrections & accelerated order closings.

Orders released manually by SFC500, via MRP540, or JIT540, can be reported
against using either SFC or JIT - mix & match the features & options that
are relevant to you, but be careful not to screw it up, by using the right
method in the wrong circumstances.

SFC assumes component hard allocation & that inventory reporting will be via
INV500.
JIT updates inventory & labor with one simulataneous "batch" transaction -
in which the JIT600 screens look just like SFC600 (except for our
modifications) but do so much more, with inventory consumption at point of
operation.

SFC supports alternative routing operations - we can make modifications to
our orders on the fly, to allow for substitution of equivalent components
(e.g. more expensive alloy when the standard is not in stock), or work
around a critical path bottleneck constraint.
JIT assumes repetitive same kind of production.

SFC is reported by operation.
JIT can be reported by operation or work center.

There is something about non-collectable operations that I do not
understand.

SFC captures actual resource hours.
JIT has the option of that, or standard hours.

BPCS also has
RCS = Repetitive Customer Scheduling, which we are not using.
This works with ORD & other modules to drive input to MPS/MRP, such as from
EDI.
It can generate daily updates into JIT.

BPCS also has
RSS = Repetitive Supplier Scheduling, which we are not using.
This works with PUR & other modules, such as receiving against vendor
contracts.

Hoping I have not volunteered stuff you already knew.
____________________________________________
Al Macintyre
Central Industries of Indiana, Inc.
www.cen-elec.com


+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.