Season codes in style numbers? Let's stop this madness.

Most of the consumer brand companies I worked with had seasonal businesses. Their products were designed and sold for a specific season. These companies tried to follow the latest trends and switched their product offerings accordingly. Some of their products strike a chord with the consumers and are carried across seasons. Thus, these companies ended up offering a mix of carry-over (also referred to as season-less) and seasonal products in their lineup at the same time.

When I consulted for such companies, I made a point to check out their style numbers. You will be surprised how many had their season codes embedded in their styles. Now, this may not look like a big deal, but it does cause a lot of trouble. When these companies tried to sell the same product across seasons, guess what they ended up doing. Yes, you guessed it right - they created a new style number for the same product and moved the inventory from the old to the new style number.

For example, let's assume we introduced a new jacket for the Fall 2019 season and numbered the style as JacketF19. This style came with multiple colors and sizes; thus, we created a dozen variants - such as JacketF19-Black-Medium. Let's assume this jacket ended up being really popular with our customers. Now, we want to carry it over to the Fall 2020 season. Well, we need to create a new style number called JacketF20 and also its variants - such as JacketF20-Black-Medium. After creating a dozen new SKUs, we now have to move the left-over inventory from the old SKUs to new SKUs in order to sell them in Fall 2020. Imagine that you have to do this across 100 styles which means the creation of 1,200 SKUs and execution of 1,200 inventory transfers. What a waste of time and effort.

We need to question something even more fundamental. What is this season code for? Are we trying to track when this product was designed? Are we trying to track the season we are selling it in? In fact, you would quickly realize that there are multiple seasons in play. I ended up categorizing them as design seasons that were attached to the product and transaction seasons that were attached to the transactions (sales, purchase, etc.).

Finally, it is more common to see colors being carried over across seasons rather than the style itself. In the previous example, you may find that JacketFY19-Black carried over, but not JacketFY19-Blue. Thus, seasons are more lined up with colors than the styles themselves. The right data model will link the season code (FY19) to a color (Blue) rather than the style (Jacket).

So, next time you see a season code in a style number, please stop and ask the question - what is this season code for? I hope you will remember this post and make the right modeling choices.

If you are interested to learn more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.

My name is Cem and this has been another gem.

Previous
Previous

How to use multi-language for global ERP deployments

Next
Next

How to enable shared services within your ERP