In my previous employment I was tasked with creating a new product identification scheme. The company had over 560 products with many variables making each one distinct. Many of these variables never noted in sales, production logs, or warehouse manifests creating major headaches for data analysis.

This blog is an attempt to give some guidance to anyone looking to create a product coding scheme and can serve as an example of what I did and what was useful.

Product Code in this blog post is specifically reffering to a single code that differentiates any one product from any other, similr or disimilar, product. This could be a random string or sequential number but here I am talking about generating a product code that is made up of the products variables and is human readable/decipherable and so able to be easily broken down into those component variables.

Background Information

The company had 5 departments that used Product Codes: Sales, Customer Support, Production, QA, and Warehouse. When I started each department had developed its own code and used that, causing incorrect products to be produced, shipped, or billed.

My first step was to figure out and diagram the business process that utilized our Product Code. This is what it looked like:

Workflow with Blank Data Boxes

I left the tapezoid boxes (which will hold the data inputs leading into the next step) blank. This then allowed me to figure out what data was needed for each step. Below is what I discovered was used for each step:

Workflow with Filled Data Boxes

The data in these boxes became my variables. From this data you must extract what variables are used in product coding. This would be any variable that distinguishes one product from another.

An aside on the collection of these variables

To collect these variables I primarily talked with the people who performed these steps. I always made sure to ask "Why is this variable collected?" It led to a lot of "Because we always have," answers which helped me to determine that some variables weren't actually useful at various parts of the process.

The harder task was finding the missing variables. For years the size of the cardboard core had not been noted anywhere. Only 2 customers took a 3" core and so it was known by the production supervisors, warehouse manager, and sales staff that those products were on a 3" core. This meant that when I discussed what variables they used they never mentioned the core size. They had never written the core size because in their mind the customers name was an identifier for that core size.

My key recommendation to find those forgotten or invisible variables is to watch the process, if possible. I watched as our warehouse manager marked products to ship and asked how he knew the correct packages for a customer. He noted that the label on the package stated their name and that meant the 3" core they desired was used, and that was why he could not ship them a similar set of packages. From this I discovered the missing variable.

Development of Varibles

Once you've uncovered the variables needed we can write a description of each. This will help in documenting what information these variables provide, and will help us decide how to codify them.

Describing the Variables

These are the variables that we realized made up our product code. We wrote their brief description (one sentence) as such:

  • Specification - The specification (internally used QA testing parameters) the product is to be run to.
  • Backer - The backing material that must be used to make the product.
  • Color - The color the product must be run as.
  • Width - The width (in inches) the final product needs to be cut to.
  • Length - The length (in feet) the final product needs to be cut to.
  • Core - The cardboard-core diameter (2" or 3") that the product must be rolled onto.
  • Labels - The labels that must be put onto the final product.
  • Rolls per Package - The number of rolls to be placed into one package.

Codifying the Variables

For this section we needed to determine how the variables would be written. For some, like length, it was easy. For others, such as color, we needed to create a lookup chart that converted our used names into a single codified phrase.

Below is what we developed for each variable and an example.

  • Specification - A numbered ID system ranging from 101-999. (e.g. 901 or 814)†
  • Backer - The first letter of the backers type, followed by the backers ounce per square yard. (So polyester with a .4 OSY would be P0.4)
  • Color - Codified colors with a lookup chart. Many colors were run the same but called different names, this prevented that. (e.g. PK for Pink or ND for No Dye which was used both to call something yellow or colorless.)
  • Width - Width in inches to 4 decimal places, with trailing zeroes. (e.g. 22.5000 for 22.5")
  • Length - Length in feet, with leading zeroes. (e.g. 500 for 500' or 050 for 50')
  • Core - Either 2 or 3 for the diameter in size
  • Labels - An ID system starting at L001 and incrementing by 1 for each ID.‡
  • Rolls per Package - The number of rolls in the package. (e.g. 2 for 2 rolls per package.)

With this codifying complete we could put this together into one Product Code. Using what we made above 901P0.4PK22.50005002L0012 would be a valid product code.

Because our product code was always the same length we had no need to use a seperator between each variable. Any excel sheet or program could take in this code (usually via barcode) and seperate it into it's component pieces with ease.

Next Steps for the Process

Now that the process has been designed and a unified code has been created you could move onto the next step. Integrating the product code into your systems. This is by far the hardest part of the tasks and requires a good deal of forward thinking and teamwork. In my next blog post I'll discuss this.

Footnotes:

I've provided a bit more look into how we codified our two variables of Specification and Label but might follow this up with an example later.

† Our number system categorized products into pre-determined categories with the first number in the sequence, and then reserved the first 9 numbers for standardized products, all after 10 being one-off products. This was done so that a 01-*09 meant a standard product for that category.

‡ The labels were printed from Microsoft Excel by the QA technician. For this sytem we had them scan the product code's barcode into excel, type in some production run information, and select the label from the other sheets (named L001-L008). Those sheets had the proper styling and info on each one, and could be printed directly to the thermal printers.