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



Bob

It is first important to know what applications the customer is running.

If you do not have good engineering (BOM and Routings) on the Customer Parts that you want to know how much labor needed to get the job done, then you might as well forget about using BPCS to figure that out for you.

We have MRP which takes the work that is needed to be done whether shop orders released or not, and calculates all components due when, assuming the BOM and Routings are reasonably accurate, then we run CAP which looks at the planned requirements that exist on the stuff for which no shop orders released yet, and at the cases where there are shop orders out there, and figures how many labor and machine hours needed to make all the parts involved.

Actually if shop orders have been released, this can complicate the picture.
Let's suppose a customer order is due middle of March and shop orders are released so that we will make the part on time.
Let's suppose the customer changes mind and says now they need it last week of Feb.
The MRP says that the shop order for the end customer part perhaps should be finished sooner, but says nothing about the sub-assemblies should be made sooner. The MRP assumes we know what we are doing by not pulling up all the orders for the components needed to meet the revised customer schedule ... we have to be looking at reports or inquiry that tell us that our planned date is no longer the right date, then when we fix due date on end item, the MRP replans ONE LEVEL DOWN, so depending on the complexity of our parts, we cannot be responsive to changes in customer desires.


Unless we look at the MRP differences report rigorously, make lots of maintenance changes, and update paperwork on shop floor, then rerun MRP net change to get the new story, look at new differences, rerun MRP net change, look at new differences. Keep up the loop until no more differences needing action. And that's why some companies buy RPM so they find out all the differences one time, fix them all, be done with it, and dramatically lower the risk of being past due on orders where we told the customer that we could make it on time.

Now there can be some problems with past due stuff vs. the dates used in planning.
For example, if a customer order is past due when it is entered, does MRP CAP plan it properly, or say that it is due RIGHT NOW?
Or suppose a new part comes in, and is engineered using effectivity date of TODAY, and the lead times are such that we should have ordered the materials 30 days ago, only we did not know 30 days ago that we would have this order, will the MRP correctly call for the requirements, when they were due before the date that we got this new item and had the effectivity date on the day we got the new part?
I don't think so.
Many BPCS fields default to values other than what the company wants ... for example, do you want MRP to plan these items or ignore them? BPCS default is to ignore them.


So the engineering on all the parts have to be correct, run the MRP and CAP with valid planning dates, and now the associated work files have the grand total labor hours needed to make all the parts, whether or not anything other than customer orders have been entered, and you can look at that detail by end customer item using SFC350, or write a query to study contents of the L* CAP work files ... we have queries that show # of wires to be cut (our first operation) by customer by facility by date due, with CAP computed # of hours needed by week, so we can plan staffing people in different departments of the factory based on the work volume anticipated.

We made a modification so we could track what end items and their components for what end customers ... I do not believe that capability comes with BPCS. We needed this because as parts approach completion, we can have a capacity problem combined with fluctuation in customer demand that we want to finish some customer parts first, and see what is needed to do so.

We also found some fields in item master that we could add some info about the part (we could use some more fields like that), then use the contents of those fields TIMES customer order data to help manage factory load. For example, a small part of our business is electrical cords, so that means we not have much capacity for the electric wall plug socket construction ... but when we do get a bunch of orders on that, it can rapidly turn into a bottleneck, so we put some codes on the end customer item to say that at some point in the production they go through this bottleneck, and put that info on relevant reports, so that the right people know about it, and not let the bottleneck go idle when there is work that could go thru it.

In one of our modifications, we created a new file that has in it a combination of facility customer end item that we sell that customer, and there is a field = # of hours to make one of those parts, ignoring the impact of scrap or setup time. Then we have a program that goes down the BOM to get at all manufactured components of the end item, then look at the routings to calculate how long to make one item, and factor in the number of copies of that component needed in the final assembly. The program to recalculate this based on current customer orders can be run at any time on JOBQ.

Then with that info updated ... hours needed to make end items, ignoring setup and scrap and move time, which depends on the quantity and common efficiencies, we are then able to run a report off of customer orders left to ship, to get a broad idea of the total hours by end item with sub-total on customer. This does not subtract based on WIP already completed ... it is just a big picture overview of CAP simulation by customer, without allowing for MRP date staggering.

But if the customer is not using MRP DRP CAP, or not using them properly, but does have good engineering accuracy, then this approach might be taken.

, you wrote:
Perhaps I did not make myself clear in what we are looking for.
We have a backlog of customer orders that have come in.  We would like to
know how many labor hours it will take to produce the products on those
customer orders. This is not looking at what we have done for product
already made but what will it take to produce enough of an item to meet the
customer orders we have still open.

It sounds to me like we should be using Capacity Planing but I don't think
that is set up to be used at all.

I was hoping to be able to create a query or a quick program to produce the
number of labor hours required to fill existing customer orders.

TIA,
Bob


-----Original Message----- From: bpcs-l-bounces+rsmith17=carolina.rr.com@xxxxxxxxxxxx [mailto:bpcs-l-bounces+rsmith17=carolina.rr.com@xxxxxxxxxxxx] On Behalf Of Bob Kohlndorfer Sent: Thursday, February 10, 2005 3:43 PM To: BPCS-L@xxxxxxxxxxxx Subject: [BPCS-L] Labor Load for customer orders


BPCS v6.02 We are looking to find the amount of labor it will take to produce the items ordered by customers. The Customer Orders have not yet been turned into Shop Orders so I cannot get the information from the FSO file for Labor Hours remaining. Is there an easy way to find how much labor it will take to produce a certain item or items (by item class) for the open customer orders on our system?

TIA,
Bob
--

Al Macintyre http://www.ryze.com/go/Al9Mac


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.