|
Regarding your MRP reorg questions. We have similar problems regarding negatives we have 8 warehouse, with 5 different facilities. We normally have 5,000 to 6,000 shop orders open on any given day, with the shop floor personnel posting roughly one third of those orders. Our master schedule changes on a daily basis because of what was run for production that day, therefore the MRP 100 Forecast will change and due to the lead times in the MRP 140 for some purchased parts as well as some manufactured parts, we found it necessary to run the reorg. every day that way when one of the planners or buyers is looking at the MRP records it is up to date. Currently after having studied the negative problem in our facilities for the past year we have found that they are due to human error 99% of the time, (not posting scrap, not substituting parts, not using accurate counts) since we have at least 3 people in charge of these warehouses divided up equally we monitor the negatives either daily or weekly. Another problem that we have are our BOM being accurate, if they are not accurate then it can produce negatives At any rate we have found that by running the following programs nightly helps tremendously CST 920 MRP500 MRP600 CAP500 CAP600 Then we run the BOM900 weekly. In order for the system to be accurate you must have a good accuracies with inventory. Also you probably should not rely as heavily on the Queries there are other reports within BPCS that would be better and more useful or at least in the 6.0.04 version. There is the PRF which is the performance measurement. The FOR forecasting which you can retrieve various reports there are also several reports within the SFC that you could use. Hope this helps -----Original Message----- From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On Behalf Of bpcs-l-request@xxxxxxxxxxxx Sent: Sunday, January 04, 2004 12:00 PM To: bpcs-l@xxxxxxxxxxxx Subject: BPCS-L Digest, Vol 2, Issue 2 Send BPCS-L mailing list submissions to bpcs-l@xxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://lists.midrange.com/mailman/listinfo/bpcs-l or, via email, send a message with subject or body 'help' to bpcs-l-request@xxxxxxxxxxxx You can reach the person managing the list at bpcs-l-owner@xxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of BPCS-L digest..." Today's Topics: 1. Normal Rates (Alister Wm Macintyre) ---------------------------------------------------------------------- message: 1 date: Sat, 03 Jan 2004 14:43:01 -0600 from: Alister Wm Macintyre <macwheel99@xxxxxxxxxxx> subject: Normal Rates Are there any kind of industry statistics about what is normal that we can compare to to see if our efforts at continuous improvement are in a good place? * Using non-BPCS reports in BPCS ... how heavy is normal? * Scrap rate fluctuations ... are we out of line? * Negatives ... is it normal to have perception of drowning in them? We are 405 CD Mixed Mode tracking by facility. Reliance on Query/400 and modifications ------------------------------------------------------------ A large number of the reports used to run our company, to make planning decisions, to run the shop floor production, are either Query/400 listings or RPG programs that I wrote. Is it normal for companies to be under-relying on the report programs that came with BPCS? Is it normal for companies to be using Query/400 as a source of reports used to run the business? When I first learned Query, I understood what it was good for was a detective investigative tool, period. Query is very habit forming because it is incredibly fast to get a nice looking report, compared to how long it takes to write a high level language program. Plus, we usually have several end users able to create their own query reports. I do not trust Query/400 on percentages because I suspect that if the math should go to XXXXXX.XXXXXXXXX based on the numbers going into the math and we chose to print XX.X % the losses in rounding is something fierce Do query professionals recommend two step math 1. use a work field big enough to contain the wildest variations so as to get a good number without rounding 2. move that result into to pretty print XX.X result I was planning a review of all query definitions to see if the default dates need to be moved up now that we are in a new year, and contemplating what else is worth reviewing. I do not trust Query/400 total time average percent because averages at total time are an average of the numbers in the column above, not a recalculation of the total line, and our data is lumpy. Am I being unrealistic unreasonable? What kind of scrap rate is normal ? ------------------------------------------------- I run some scrap reports for people regularly. There is one department I watch from week to week (wire cutting). I get percentage scrap from grand total made vs. total scrap reported via labor, not relying on query/400 math. One week has been as high as 6-7% or as low as 1.5 % usually it hovers around 4 % give or take a % one week to the next it can go up or down, but it is pretty rare to go up or down by more than 2 % I know we have discussed here before the many different definitions of scrap, but for those companies that track reported scrap as a percentage of what is made in production, do the figures I shared, assuming our reporting is reasonably accurate, do they sound about normal, good, bad ? I had been contemplating that it might be useful to do a totals only report a bit different from what we now run ... we now show total by department or some such break down, for some date range. I thought it might be useful to see total for each of several date ranges, for some department, with totals by date or date range, to see how the percent fluctuates over the long haul. I am not supposed to create new software just because I think it is a good interesting idea, but rather because of a need expressed by my users, or to accomplish my computer janitorial duties. How much of a hassle are negatives for other companies? ------------------------------------------------------------------------ ---------- Years ago, I used to kick everyone off the 400 once a week to run various reorg, but I came under pressure due to complaints by people who expect 24x7 access, so I began to do the reorg less often. In the last few months, research into how come MRP did not plan stuff we needed, causing shortages, showed that when there is a big negative in customer or shop allocations, MRP can under-plan by that amount. Assuming all negatives are unwanted, that means MRP under-planning also unwanted. The result is that now I am back to doing reorgs weekly, with some interest in more often. There is also a renewed interest in what causes the negatives and how much is reasonable. At any given moment, we have 5,000 shop orders open. Each day we post in the neighborhood of 1,000 labor tickets against them We have 1.64 million records in our inventory history file, and store the transactions for one year Assuming the dead records are not a major problem, this means we are inputting approx 30,000 inventory transactions a week. Checking a random month in the middle of December, I see that week we added 25,000 ITH records. I run a daily query to see how bad the negatives are (how urgent is a reorg?) this looks at negative allocations in the item master. We go up by 40-90 items a day after a prior nite reorg They are dominated about 50-50 raw materials and sub-assemblies We just did EOM EOY A few days before this, production people have to clean up negatives in shop orders. We believe they are caused by failure to do proper labor reporting and corrections. We run lists of all order operations where the inventory requirements are negative on hand inventory is negative other unwanted stuff it is not unusual for us to have 25 pages (25 items to a page) in need of clean up. - Al Macintyre http://www.ryze.com/go/Al9Mac Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/ ------------------------------ _______________________________________________ This is the SSA's BPCS ERP System (BPCS-L) digest list To post a message email: BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/bpcs-l or email: BPCS-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/bpcs-l. End of BPCS-L Digest, Vol 2, Issue 2 ************************************
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.
midrange.com
