Embedded Files
In retail, the common approach to define categories is based on product attributes. It is the natural result of how consumers may search for a product when they are shopping in a (physical or online) store. They might have a very clear idea of what they want to buy, or maybe they know the general area of need and are searching for some inspiration from the retailer. In any case, categories will lead them to the right section of the store, and when there is a match it is win-win for both parties.
Although product attributes are the starting point, from a planning perspective it is not as clear as what consumers see. First of all, companies have a tendency to define categories within a product hierarchy (division > department > class), which usually aligns with an organization structure managing the business with clear roles & responsibilities. If the retailer has a stable business, these product-driven definitions would usually converge in a manageable structure over time (after many painful "reclass" efforts in IT systems). However, the critical assumption here is ''stability" and as a lecturer of mine in grad school used to say strong assumptions mean weak theorems.
In the retail age of multi/omni-channels & social shopping, parts of these legacy hierarchies could lose relevance soon after they are laboriously defined in systems. Retailers would find themselves in a tough spot, unless they have a planning capability to:
add/remove categories like peanuts
define categories outside your product hierarchy (such as channel, region, or other attributes like customer segments)
manage categories at different levels (class in one channel and department in another).
In a planning software implementation it would be very difficult to nail these definitions forming the building blocks of the process. Having quick implementation cycles and an iterative approach to revisiting "business requirements" without depleting budget would certainly help.
Özgür
January, 2024
Page updated
Google Sites
Report abuse