×
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 mailing list archive is Copyright 1997-2025 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.