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