Best practices for inventory control basics such as assigning SKU numbers?
January 10, 2009 12:01 PM Subscribe
What are best practices for assigning SKU numbers to products? And is there a book that covers the absolute basics of inventory control?
I'm setting up an e-commerce site for a small business that will sell hardware accessories and soft goods over the internet. The business has essentially no inventory control system in place, so that's step one. I'm looking for a good book or even just advice on the basics of inventory management.
I want to assign Stock Keeping Units to all of their product variations. There seem to be advantages to using a schema more complex than just an integer for each product, so that the SKU itself carries information about the product. Some of the examples I've seen separate the SKU into fields with meanings, such as product groups, sizes, or colors. Are there standard ways of creating such distinctions with an appropriate granularity? I associate this with composite keys in relational database design, but I'm not sure how applicable that is, and I feel like I'm reinventing the wheel.
Most of the inventory control books I've found on Amazon appear to be about more advanced topics like stock forecasting. I need to get my head around the basics. Can anyone recommend a general reference, or help me improve my understanding of this particular task?
I'm setting up an e-commerce site for a small business that will sell hardware accessories and soft goods over the internet. The business has essentially no inventory control system in place, so that's step one. I'm looking for a good book or even just advice on the basics of inventory management.
I want to assign Stock Keeping Units to all of their product variations. There seem to be advantages to using a schema more complex than just an integer for each product, so that the SKU itself carries information about the product. Some of the examples I've seen separate the SKU into fields with meanings, such as product groups, sizes, or colors. Are there standard ways of creating such distinctions with an appropriate granularity? I associate this with composite keys in relational database design, but I'm not sure how applicable that is, and I feel like I'm reinventing the wheel.
Most of the inventory control books I've found on Amazon appear to be about more advanced topics like stock forecasting. I need to get my head around the basics. Can anyone recommend a general reference, or help me improve my understanding of this particular task?
Best answer: I was the IT manager at a plastics manufacturer, so this comes from my experience with their inventory control system.
What you're talking about with embedding information in the SKU is generally known as "smart numbers". The problem with smart numbers is that over time they usually fail somehow. You set aside one digit for color, and marketing comes up with eleven colors; you set aside two digits for model, and in the product line that's a runaway success, you end up with more than 100 models. The idea of a smart number is to allow someone who understands the system to be able to predict the smart number, or read a smart number; but unless you're willing to allow a lot of extra placeholder digits to accommodate unpredictable future growth, making the smart number unwieldy long, it will eventually break down with a variety of exceptions and special cases, and people will still be stuck reading it off a piece of paper. Also, smart numbers partition the SKU space, and render large chunks of it unusable because its reserved for future growth (that may never happen); this increases the number of digits you need.
My advice: assign SKUs arbitrarily, and treat it as nothing more than a serial number. Have a system for the model name that describes the item. The SKU is the primary key for that item in your database, and marketing considerations don't enter into technical matters. This way, if you have a five digit SKU, you can have all 100,000 SKUs; if you're doing smart numbers, you'll need six, seven, or eight digits to accommodate the same number of items, which makes the SKU less useful, not more, because it's longer.
I can't recommend references in the area--all my learning was on the job--but from what I saw, inventory control was headed in the direction of SKUs being arbitrary and computer generated in line with various barcode schemes and wireless labels. Human control via serial number is decreasing in favour of automated warehouses. The more you can decouple the product's SKU from it's human readable labelling, the more in line you'll be with industry best practice.
posted by fatbird at 1:09 PM on January 10, 2009 [1 favorite]
What you're talking about with embedding information in the SKU is generally known as "smart numbers". The problem with smart numbers is that over time they usually fail somehow. You set aside one digit for color, and marketing comes up with eleven colors; you set aside two digits for model, and in the product line that's a runaway success, you end up with more than 100 models. The idea of a smart number is to allow someone who understands the system to be able to predict the smart number, or read a smart number; but unless you're willing to allow a lot of extra placeholder digits to accommodate unpredictable future growth, making the smart number unwieldy long, it will eventually break down with a variety of exceptions and special cases, and people will still be stuck reading it off a piece of paper. Also, smart numbers partition the SKU space, and render large chunks of it unusable because its reserved for future growth (that may never happen); this increases the number of digits you need.
My advice: assign SKUs arbitrarily, and treat it as nothing more than a serial number. Have a system for the model name that describes the item. The SKU is the primary key for that item in your database, and marketing considerations don't enter into technical matters. This way, if you have a five digit SKU, you can have all 100,000 SKUs; if you're doing smart numbers, you'll need six, seven, or eight digits to accommodate the same number of items, which makes the SKU less useful, not more, because it's longer.
I can't recommend references in the area--all my learning was on the job--but from what I saw, inventory control was headed in the direction of SKUs being arbitrary and computer generated in line with various barcode schemes and wireless labels. Human control via serial number is decreasing in favour of automated warehouses. The more you can decouple the product's SKU from it's human readable labelling, the more in line you'll be with industry best practice.
posted by fatbird at 1:09 PM on January 10, 2009 [1 favorite]
Another problem with meaningful SKUs: In an hierarchical categorization scheme, the leaves always end being unique to the branch they're on. At my old workplace, the last digit meant the number of drawers if you were talking about a chest of drawers, or the volume in quarts for planters, or whether or not it had wheels if it was a stackable container. In other words, the categorization scheme quickly becomes too complex to be meaningfully encoded in the SKU, so over time, people can't "read" a SKU anyway. A more explicit, flexible model numbering scheme is preferable.
posted by fatbird at 1:16 PM on January 10, 2009
posted by fatbird at 1:16 PM on January 10, 2009
Definitely echoing fatbird. A former employer had very elaborate SKUs, and sometimes it was very useful to be able to say "oh yeah, a XUB554 is just like an XUB553, except it has more capability." On the other hand, then you get to XUB559 and suddenly you have a problem, so now you have XUB990 because that was the next available space, even though the XUB900s are almost totally unrelated. Offhand, I'd say the system (a couple of decades old) worked for 90% of the entries, which comprised 70% of the actual production - since newer stuff, which was more likely to have one of those exceptions, comprised a greater share of what we actually worked with.
If you try to do smart SKUs, it'll seem really cool at first, and then at some point something will break, probably pretty dramatically, and it'll all start to fall apart. Before long, you'll have to explain to a new employee that R means Red, but B means Blue only some of the time, because sometimes it gets used to refer to Baked, and if you understand the rest of the SKU it's obvious which B you'd use, and G is always Green but light green is X because L is taken by Lemon and there's only one character for color....
posted by Tomorrowful at 1:27 PM on January 10, 2009
If you try to do smart SKUs, it'll seem really cool at first, and then at some point something will break, probably pretty dramatically, and it'll all start to fall apart. Before long, you'll have to explain to a new employee that R means Red, but B means Blue only some of the time, because sometimes it gets used to refer to Baked, and if you understand the rest of the SKU it's obvious which B you'd use, and G is always Green but light green is X because L is taken by Lemon and there's only one character for color....
posted by Tomorrowful at 1:27 PM on January 10, 2009
Fatbird is 100% right. In our previous ERP we used "smart" numbers, that only made sense to the initiated (I was one of them), but we ran into all kind of trouble because we kept growing and growing, and that was when we only had around 11.000 SKU's. Somewhere in the future you will run into trouble with these "smart" numbers. We got to the point that there was only one person in the company who was able to make new products, because of all the do's and don'ts of our number system. Very inconvenient.
Currently, we have a simple 6-digit product code and in the material master we have a couple of extra fields with product properties like product group, size, color, season and target market, which we can easily query and re-use. It makes material management much easier.
posted by IAr at 1:31 PM on January 10, 2009
Currently, we have a simple 6-digit product code and in the material master we have a couple of extra fields with product properties like product group, size, color, season and target market, which we can easily query and re-use. It makes material management much easier.
posted by IAr at 1:31 PM on January 10, 2009
Speaking more generally, proper inventory control tracks quite closely with proper database design, so reasoning from the latter to the former is a good idea for both technical and business reasons.
posted by fatbird at 2:26 PM on January 10, 2009
posted by fatbird at 2:26 PM on January 10, 2009
Response by poster: Thanks, that makes sense. Assigning SKUs arbitrarily sounds better in light of the evidence that "smart" numbers break down. That does move the task squarely out of the realm of human decisions and into the realm of software, so I suppose I really need to find appropriate software for single-warehouse inventory management.
posted by wam at 3:20 PM on January 10, 2009
posted by wam at 3:20 PM on January 10, 2009
That does move the task squarely out of the realm of human decisions and into the realm of software
That's actually the big advantage. Remove the decision altogether and you won't have to hire a potentially expensive decision-maker.
posted by Civil_Disobedient at 7:39 PM on January 10, 2009
That's actually the big advantage. Remove the decision altogether and you won't have to hire a potentially expensive decision-maker.
posted by Civil_Disobedient at 7:39 PM on January 10, 2009
This thread is closed to new comments.
posted by fixedgear at 12:58 PM on January 10, 2009