(06-12-2012, 08:46 AM)phil Wrote: why is time important in determining where a product sits in it's lifecycle - I can think of some products that keep on giving?)
Why timing is important?
Usually tests are done on limited locations with limited stock. Once the test is successful, then more stock is produced or ordered and it is sold on more locations.
Example:
You bought / produced 50 units of product X to be tested in 3 locations of your 10 available locations.
You start selling and after 10 days you have sold 25 units. Congratulations! You’ve found a great product, so you need to hurry up and order / produce more, get more shelf space for it, print promotional material, etc. If you react only after the 60 days, you missed 50 days of good sales. As soon as you detect a new item is a good seller, it should be removed from TEST and changed to ACTIVE, get more stock, send it to more locations, increase price, etc.
On the other side: Let’s say after the 60 days test you have sold 10 units out of the 50. Oh s***! You chose a bad one. For the 40 remaining stock it is better you get rid of it asap. Sell on discount, send it to outlet type locations, take it out from prime expensive shelves, etc. So change from TEST to BAD asap is also important.
For sure pricing, competing products, etc also affect, but for retail businesses timing is important. I can understand it does not make much sense to a machinery workshop or to carburator producers (having much longer product lifes). In retail some products have 3 months life, so reaction should be fast based on what happens related to a period of time.
(06-12-2012, 08:46 AM)phil Wrote: I really do think a different field for stageinlifecycle is appropriate. You could make it so changing this flag alters the GL postings. Perhaps we create a table as we have for sales postings for stock postings so GL posting codes are derived from a combination of factors rather than being solely on stock category as things stand.
Regarding GL postings, I’m not sure how will work when we have for one item 2 different fields indicating GL postings.
Currently categoryid indicated the correct GL accounts for stock. Stocks.php change the postings if the item has changed category. But if we add the lifecycle field on it, could cause errors. What should take precedence for posting? Lifecycle or categoryid?
That’s why I think categoryid fits for this purpose as well (and follows the KISS principle). Following your example: You could have “Test Set Top Boxes”, “Active Set Top Boxes” and “Bad Set Top Boxes”, all of them pointing to the appropriate GL accounts. Once the category is changed, the GL postings follow automatically.
Of course it implies a multiplication of stock categories.
I will be really happy to get a new field lifecyclestage if we are able to manage the GL postings accordingly (no clue how to do it, sorry).
(06-12-2012, 08:46 AM)phil Wrote: What we need I think is a method for webERP to determine those products that had a peak sales that have now tapered off - this then alters the flag to BAD when the sales reach say 5% of their peak or other configurable percentage. This will have to be done on some statistical basis where sales units for the last period are gathered from sales analysis and the statistics run - with periods of no stock removed - to get the trend. This mechanism would need to factor out those products whose sales have fallen off because of periods of stock outs.
About getting an automated (or almost automated) method fitting a wide range of businesses to determine how to change stages in life cycle I think it is extremely difficult. I would be happy to get some reports or selection of items so webERP makes product manager tasks easier.
Some of the key questions that can be done are:
1) List of items in one stage with very good sales. Very good sales could be a percentage of sales out of stock available, or speed of sales (units/day), gross profit, on X top sales hall of fame, etc. Useful to extract TEST items that should be changed to ACTIVE,
2) List of items in one stage with very bad sales. Again the definition of bad sales can be done in several ways: percentage of stock available, speed of sales, gross profit below certain point, etc. Useful to
3) List in one stage for more than X days. Will help to detect those items forgotten by other reports, but that should be revised. Some metrics would help the product manager to decide what to do.
Again, these scripts should be a help selecting or guiding the product manager, but many different reasons can be taken into consideration (some of them not accountable, as it is a very different/funky/blinky/cool product attracting passing by customers to our shop, but it is extremely expensive, so we do not sell many but it acts as a “magnet”, so it is worth keeping it ACTIVE even if its sales performance is bad).
Just reducing the desk work load of the product manager to 50% with some scripts or reports will be a big success.
We could start with some report type scripts and later on someone bright can get the automatization stage, as happened with inventory planning and MRP previously ;-)
