|
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 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.