Re: MRP -> Shop Orders

You dont have to report labor. In companies where I worked where material
was 75% of the cost, labor 5-10% and overhead 15-20%, we didn`t bother
reporting labor.  It`s basically a management strategy: what more value is
there in reporting labor? Is someone going to use this information?

Daniel Warthold


----- Original Message -----
From: "Al Mac" <macwheel99@xxxxxxxxxxx>
To: "BPCS_L discussion" <bpcs-l@xxxxxxxxxxxx>
Sent: Tuesday, August 30, 2005 2:36 AM
Subject: [BPCS-L] MRP -> Shop Orders


> Managers are questioning the level of clerical support needed to launch
> paperwork to our shop floor, so I'm reviewing what alternatives may be
> available to 405 CD.
> * Do we really need to report actual time for the labor, since the
quantity
> done is good enough for the dispatch report?  What is the cost to the
> company tracking that, and what is the benefit knowing performance and
> actual costs, when we don't track everything anyway, such as setup
> time?  And if we can eliminate actual time, then we not need to know which
> employee did it, just plug in a dummy clock # for everything.
> * We have a proposal for discussion on the table to alter the sequence of
> shop paperwork from by shop order to by shop dept, then item, then shop
order.
> * I have rejected several requests to have MRP250 sub-assembly data by end
> item customer, because no one in the company seems willing to enter and
> maintain correct info by item what customer it is for, figure out which is
> the right customer for components that are common to several customers,
and
> other variations
>
> We do full MRP500 600 CAP600 regen nitely, then production planning uses
> MRP250 (a several hundred page report which we have modified), MRP540,
> SFC550.  If there's a rush item (which happens a lot): SFC500, SFC520.
The
> only JIT we do is JIT600 series.
>
> Is anything obviously missing from this picture?
>
> I think what we'd like to have is
> 1. A way to put a stop order on MRP requirements we not want to make right
> now, with optional reasons
> 1.1 Engineering Change in the works, hold off on production start until
> this done
> 1.2 Onsies uneconomical, live without them
> 1.3 Tooling down for repair, hold off on adding to the bottleneck until
> they get done
> 1.4 Serious shortage, don't aggravate
> 1.5 This work is to be moved to another factility, wrap up what is here
> 2. Then when we have flagged stop on everything MRP says we need, that
> production planning says we not gonna make, at this time, have something
> that will automatically release & print 100% planned orders in some date
> range, whose MRP251 conclusions would be "Ok to release" 100% because we
> have all the raw materials needed, and where there are multiple
> requirements for same item within the selected date range, aggregate the
> whole thing into a single shop order ... this would replace production
> planning now having to individually release stuff ... which is several
> thousand new shop orders each week
> 3. Full regen would not undo the "stop flag"
> 4. Reports listing stuff with the "stop flag" for review which to take off
> that condition
> 5. This way we shift focus from manual effort getting the non-exceptions
> paperwork on its way, to managing the stop conditions that we never seem
to
> have time to deal with, and thus they tend to pile up, complicating the
> task of selecting what to release
>
> -
> Al Macintyre  http://www.ryze.com/go/Al9Mac
> BPCS/400 Computer Janitor ... see
> http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
> --
> This is the SSA's BPCS ERP System (BPCS-L) mailing 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.
>
> Delivered-To: daniel.warthold@xxxxxxxxxxxx