Judy Miller
17th December 2007, 22:07
I have a client who has chosen to create 1800 standard smart part numbers instead of using the product configurator. They run MPS now. Of these 1800part numbers about 90% of the orders come from 10% of the part numbers. They have built planning bills but the percentages on many of the items are so small that they are almost insignificant. They do not wish to use the configurator. We are looking for customers who may be doing the same to discuss the best way to manage MPS and in particular all of the lower lever MRP parts. Any suggestions would be greatly appreciated.
Martin Jung
18th December 2007, 10:28
Hi Judy,
we have a similar problem with about 900 items and a strong seasonal fluctuation. We evaluated pros and cons of the MPS and decided to use the MRP forecast instead. The table (timrp001) is updated by a session which reads a few new tables and parameters.
It works fine for us and keeps the system simple. In my opinion the MRP is easier to understand and to track rather than the MPS.
By the way: would the configurator solve the problem? If yes - why?
Best regards,
Martin
avpatil
18th December 2007, 14:04
Here is one solution that I have used in past. BAsically there is no need to do the planning for those 1800 parts. One can create a Generic MPS item and can create a Generic Bill of Material. In that BOM one can maintain the components directly with the specific percentage. The components can be MRP. For e.g. say we are making trucks and need to plan for different engines, transmissions etc, it is very difficult to forecast each and every model , as the end item is only decided during Final Assembly Schedule. In such scenario one can create Generic Item called Truck and maintain the compoents like Engine 1, Engine 2 etc with same position but differen sequence. One can forecast the Generic item. This will drive the MRP for the component. However, when the actual schedule comes, one should remove the forecast from Generic item and put it on real item, and that can be without any planning. This work very nicely and it is meant for this purpise. If you use MRP forecast as sugguested, the draw back is that there is no forecasr consumption.
in my opinion this will give you a solution what you are looking for and one can tweak it to get the desired result like some kind of automation. Let me know if you need any help as this is the area of my interest.
Arvind Patil
avpatil@hotmail.com
Judy Miller
18th December 2007, 19:17
We really cannot use the MRP forecast as that would require forecasting each and every item and the forecast does not get consumed. We are looking into forecasting at a lower level so we can forecast the common components and then use SIC for the odd ball add ons. The product config would be perfect and they used it at one time but could not keep up with completing the projects. The less maintenance here the better because the volumn is very high. Thanks for you responses.
avpatil
19th December 2007, 14:36
Judy,
Did you see my repsonse on Generic Item and MPS. This is the ideal situation. You don't have to use Product Configurator
Arvind Patil
Judy Miller
19th December 2007, 19:39
Avrind,
Yes I saw the reply but they do not want to be mainting the forecast so much. We are looking into dropping down one level in the bill and forecasting the most common components. They deliver hundreds of units a day so manually changing the forecast is a problem. Thanks for your help. It was a good suggestion and I shall remember that one.
Judy
avpatil
20th December 2007, 14:23
Judy,
All you need is to forecast only one Generic item and system will breakdown ti the components based on Generic BOM. I think this is the minimum that you need to do.
Arvind
Judy Miller
20th December 2007, 17:19
Arvind,
We will accomplish the same thing using planning bills. We will forecast the family and drive the components with percentages there. Thanks.
Martin Jung
21st December 2007, 10:07
We really cannot use the MRP forecast as that would require forecasting each and every item and the forecast does not get consumed..
Well, this is correct. Our customization solves this problem by recalculating the MRP forecast on daily basis with the following logic:
1) calculate the percentage of each item from the global product mix (based on tdinv700 and a certain time range)
2) calculate a daily forecast quantity according to the desired daily output (= units per day)
3) compare this quantity to the already present salesorders for each item
4) insert the difference (if positive) into table timpr001
Sounds more complicated than it really is :) .
Anyway, the key feature is the daily output and I guess this is very specific in our situation. It actually reflects the bottleneck in our production process: the shipping department. The key figure is "units per day" and is not as flexible as in other industries. Therefore the sales departement has to announce the desired quantities 3 months in advance.
It took us several years during which we "played" with the standard Baan features like MPS and SIC, until we finally developed this solution.
Best regards,
Martin
avpatil
21st December 2007, 17:11
Judy,
I am just wrting this for argument sake. Planning BOM and Generic BOM are quiet different and one cannot accomplish same thing. For e.g. Say if you are making TRUCK and you need Engine (3 variannts), Transmission (4 variants) etc, in Planning BOM sum of all should be 100% while what really needed is sum of 3 variants engine should be 100%, 4 Tranmission variant should be 100% and so on. This is only possible in Generic BOM.In Generic BOM you can overplan also. Also these items need not be MPS item in planning BOM while in Generic BOM it can be MPS or MRP. Generic BOM is mostly suitable in ATO environment where few variants results in number of end items. IN ATO the other approach is ofocurse forecasting each sub-assemblies or parts. The other approach is to derive a percentage for each variant, and one can go multilvel in it. Also one can based forecast consdering the seasonality into account. Generic BOM is quiet suitable for doing so.
Arvind Patil