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