|
RoryHopefully my mini-essay will clear out more concepts for you, without annoying other people on this list, because sometimes my e-mouth runneth over.
For our company, inventory accuracy is a hell of a lot more important than tracking labor details. Although in times past, labor details were important to help with the quoting of new similar parts.
There are some trade offs in BPCS where you can generate reports with lots of useful data, ONLY if at some place in the reporting process, sufficient data has been entered into the system so that those reports can be produced. There is a profit margin issue. If you expend less clerical effort capturing some details about what the company is doing, then there is greater profit, without knowing precise details about where you making money. To get that detail requires tracking what's going on to a detail level that adds to the cost of doing business.
With that in mind, take a look at the layout of the files FLT and ITH. The process varies a bit by version of BPCS, and how you capture what level of labor reporting detail. We are heavily dependent on MRP to tell us what shop orders need to be released, and MRP in turn is heavily dependent on accurate information in the BOM and Routing files data I mentioned earlier.
We have modified the shop paperwork to streamline the process of reporting progress on the orders. Of primary importance are:
* How much has been completed so far, at which operation? * How much scrap if any at which operation? We might have for some item, operations 100 200 300 400 500 etc. Materials get consumed at operations 100 300 500 sayBy reporting the labor through JIT600 batches, the operations that consume raw materials, or sub-component, they generate CI (Component Issue) transactions needed to make 100 300 500 whatever, and also corresponding to scrap. The item we are making gets RJ (reject) transaction tracking scrap reporting, and when the final operation is completed, we get PR (Production Receipt) transaction adding to inventory whatever got made. This takes care of inventory accuracy, except for what might be called a WIP black hole, where inventory money goes into WIP (Work in Progress), and not come out again until the shop order is completed.
This labor reporting through JIT600, in addition to generating the CI RJ PR transactions into inventory history ITH file, also generates labor transactions into labor history FLT file, in which there is a labor ticket # tracking field that can be used to link the corresponding data that goes into ITH and FLT. We also did a modification to add a 3rd file to track machine tooling usage to help with factory preventative maintenance.
If you look at the layout of these files, to see what fields actually get populated .... ITH uses some fields differently for different kinds of transactions, you can see that there is a great deal of data captured by them, relative to what you are trying to get out of the system. We have an abundance of reports that we get out of this.
For example, we have a concept we call "earned hours" The work that got done, relative to what we will end up getting reimbursed by customers for doing, compared to the "actual" costs to make the parts.
We have reports showing percentage scrap by work center.On our labor ticket, there is a start time and stop time associated with the factory workers time on any given shop order operation ... but this is an area we recently stopped tracking, because it was costing the company one clerical worker just to get that data entered to the computer, and a management level decided that the information we were getting out of this, was not worth the cost of tracking at that level.
We do need to capture quantity made, scrapped, to manage the shop orders, what is left to make, but the time actually spent, from moment we start production, until completion, which includes date and time (hours and minutes) is of value only for your kind of report, efficiencies relative to standard earned hours, reconciling factory labored hours with payroll hours, and accuracy of overtime costs. Your company has to decide at some management level if having that data is worth the clerical overhead to get the labor reporting into the computer system.
For us, there is an issue of whether the scrap is being reported correctly. We do not have 100% accuracy, like we ought ot, with BOM, Routings, engineering change tracking, MRP coding, labor reporting, and so forth. When there are inaccuracies going into inventory consumption tracking, we can end up with two bad phenomena: * BPCS thinks we are consuming more than we really are, causing Purchasing to spend money replenishing raw materials that we have plenty of * BPCS fails to fully consume materials that we really are using up, and we find out by going to use something that aint there, sometimes known as a surprise shortage.
Well all that data, that labor reporting is capturing, can be used to get at some kind of reasonableness checking to help identify these problems before they seriously bite us. For example, our items have a sample weight, that is used in cycle counting tiny components ... we know what an empty container weighs ... subtract that from weight of a partially filled container ... divide into the remainder by the sample weight, and this gives us a count of the tiny components that are in there. Not 100% precision, but good enough for us.
The same kind of thing can be used to audit scrap reporting. Some work center machine has a scrap bin sitting beside it.Labor reported there identifies the work center machine used to make the reported labor, which goes into our third tracking file. Go down the BOM (Bill of Material) of the reported scrap, and multiply out what must be the scrap weight of what went into that bin of scrap of diverse components, and they should agree with the weight of the bin. If not, we have a flaw in our labor reporting, or our engineering precision.
You might also take a look at the file layout of FSO FOD FMA files associated with shop orders. When completed shop orders are purged, the actual cost of what was made gets updated from what has been captured in those files, and those shop order detail records go away.
We made a modification. Right before a shop order purge, we copy from FSO into another file called COSTMEMORY what all shop orders are coded completed, including what their standard and actual costs are before the purge, and also whatever is copied to COSTMEMORY is also copied to COSTMONTH The purge does not change standard cost, but sometimes we doing a cost rollup at around the same time, and that can update standard cost without a before after audit trail, although we can copy standard costs to simulated before the rollup then afterwards show what costs are now different from simulated. Anyhow after purge completion, we can compare COSTMEMORY to what's now in the CMF cost master file, or CIC summary, to see the impact of the purge ... which items costing unreasonable, have efficiencies that look like perhaps something missing from labor reporting. COSTMEMORY does this for an individual purge run, COSTMONTH for aggregate volume over an entire month.
In addition to this, we also print, before purge, a modified CST270 which shows with great clarity where the costs came from for any given shop order ... later we can search the data of this report to back track where cost variances came from for any given cost variance. While the shop orders are still open, we have other reports we use to drill down where cost variances are coming from.
We use query/400 very heavily. In recent months I been creating a lot of what I call "Excel-friendly" outputs from query/400 where instead of report output, I get a work file, then from there through various steps, including Ops/Nav the data ends up in a format that some people are comfortable working with.
When our inspectors reject some part as not meeting whatever standards, it gets moved to warehouse x9, then when QC (Quality Control) dept decides what can be done with it (totally scrap, can be repaired), it leaves that warehouse. Both the going in, and going out, has an ITH transaction with date and time stamp. I recently contemplating adding a report to show what has gone in there, and how long it been in there, so that the oldest unresolved is more obvious.
Al, Thanks for the explanation. It cleared out many concepts. What I'm trying to do is to measure the average time that some specific product lines take, from the moment we start production until we handle the products to the quality dept (by closing the production order). I was thinking of having a report, per production order (in those selected lines), with the dates (start and finish), quantity of the order and quantity released. Does this make sense ? Thanks, Rony On 3/29/06, Al Mac <macwheel99@xxxxxxxxxxx> wrote: > > Rory > > BPCS handles this stuff quite handily, but if you are not experienced in > manufacturing engineering, it can seem like rocket science. > > 1. Within the Routings (FRT file) you provide the math for how long it > takes to make the parts, using the program SFC100, after having setup > various other files in support of the Routings, such as the Work Center > Master file (the guts of the <G> warp engine). > > There is a TBC Time Basis Code > You make some # each hour > or in some time period you make 1,000 or 10,000 or whatever > > Then when you release shop orders, that math is taken into consideration. > Operation 100 get done in 1 day > Operation 200 take 2 days > etc. > Need the whole part done on Friday, it gives date earlier in week to get > done with the earlier operations, based on quantity to make in the shop > order, vs. math in Routings how long it going to take. > > 2. There is also concept of move time between steps. > You can allow for a few hours between production steps, such as to allow > for inspection, getting enough staged to keep factory workers busy. You > can > factor in setup time. > > In our case we have overlap. I might not be using the correct terminology > for overlap. What I mean by that ... we might have some part in which we > need to make several thousand, and this will take the better part of more > than a day at each operation. The first operation gets like 1,000 or so > done, and the people there continue to be busy with the machine churning > out more, but without waiting the 2-3 days or however long it will take to > get that operation completed, the folks at the next operation take the > work > that has been done so far, and they start doing the next step. So when > the > first operation actually gets done, the last operation is perhaps 2-3 > hours > away from completion. Think like an assembly line with worker clumps at > multiple points on the line. > > If you have zero move times between manufacturing steps, BPCS assumes 100% > complete one step before the next one starts, but we have overlap, so we > can put in a negative number for the move time in between, and BPCS > correctly calculates the math for how long that will take. You have to > understand the math in the Routings for this to work correctly, and you > have to put that math into your Routings. > > 3. There is also a concept of LEAD TIME. > When we order raw materials from our suppliers, we need to allow 30 days > 60 > days whatever, because our suppliers cannot manufacture instantaneously > for > us, and deliver by Star Trek teleporter, through SGC worm hole, HG Wells > Time Machine, matter transmission by e-mail, or whatever is your favorite > fantasy. In the real world, we have to allow time for our vendors to get > the raw materials to us. > > If you have more than one facility, you can have different lead time and > other rules by combination of item and facility. > > Locate the file BPCSDOC > Then locate the members within it that talk about BOM and SFC. > Those two explain how to setup the engineering with this data > > Then when the team is making progress doing that > Locate the members on MRP and CAP which I think are the most important > planning modules of BPCS > MRP for materials planning which is what you asked about > > CAP for capacity ... your company might not have infinite capacity ... > which means you might not be able to do millions of hours of work one day > and a few hundred another day ... you may need to even it out so you are > using about the same size work force each day continuously > > There's also BPCS vendors that can teach you this stuff, help you setup > the > engineering files to work well for your industry. > > Al Macintyre > > >Dan, > > > >I was talking about cycle time (i.e - Lead time of production). I guess > that > >since this is not my primary area of expertise, I didn't use the right > >words. The explanation about cycle counts was useful tough, since I'll > talk > >to our inventory guys and check out how they are doing this. > > > >Do you have any ideas about calculating lead time of production ? > > > >Thanks again, > > > >Rony > > > > > >On 3/29/06, Dan Sweeney <dsweeney@xxxxxxxxxxxxxxxx> wrote: > > > > > > Rony, > > > > > > As a rule whenever an item goes negative for any reason it is > > > automatically selected for cycle count the next time that you generate > > > the cycle count sheets. > > > > > > I have found that a good rule of thumb for cycle count frequency is to > > > use ABC analysis for the timing. > > > > > > For example if 80% of the inventory value are classified as A, B > and/or > > > C item then they should be counted more frequently as that is where > the > > > inventory and usage value resides in your inventory system. > > > > > > Once you have calculated each category of an item then it is up to you > > > and your users as to the frequency for counting the items. > > > > > > Hope that this helps! > > > > > > Dan Sweeney > > > > > > Senior Technical Consultant > > > > > > PHOENIX Business Consulting, Inc. > > > > > > Tel: 724.836.4446 x7, Cell: 860.490.6712, > > > > > > E-Fax: 832-550-5144 > > > > > > www.phoenixbcinc.com > > > > > > SSA GLOBAL Recognized Services Provider > > > > > > > > > -----Original Message----- > > > From: bpcs-l-bounces+dsweeney=phoenixbcinc.com@xxxxxxxxxxxx > > > [mailto:bpcs-l-bounces+dsweeney=phoenixbcinc.com@xxxxxxxxxxxx] On > Behalf > > > Of Rony Mayer > > > Sent: Wednesday, March 29, 2006 1:00 PM > > > To: SSA's BPCS ERP System > > > Subject: [BPCS-L] Cycle Time > > > > > > Hi guys, > > > > > > We're having a bit of a problem trying to calculate cycle times for > some > > > of > > > our product lines, since our team does not know if BPCS offer a > > > standard, > > > easy-to-use way to do that. They are trying to calculate it through > some > > > queries and manipulate the info in access, but from what I've seen, > the > > > information is not going to be very trustworthy. Do you guys know a > > > standard > > > way to get this ? I can't believe BPCS does not offer this, as I've > been > > > told. > > > > > > Thanks in advance, > > > > > > Rony > > > -- > 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: rony@xxxxxxxxxxxxxxxxxx > -- 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: macwheel99@xxxxxxxxxxx
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.
midrange.com
