Whats in a name?
In my many years of Master data management one of the main problem areas with Master data consistency seems to be around naming conventions. Often its an area that is unintentionally overlooked after all its just a description isn't it? "Surely with everything else we are dealing with its the least of our issues?"
Lets have a look at Product description as an example.
Product descriptions as entered can be used in and by many areas of a business a few examples might be:
- customer services when deaing with queries, complaints or trying to up/cross sell
- Warehouse and distribution teams
- Manufacturing teams
- In Catalogues or Ecomm sites
- Invoices, confirmations, shipping documents etc
- Business reporting
In many ERP systems the main description is limited to a number of characters lets say 40. Why? Well the ERP system can work off the product number it doesn't care about the description, remember it's really just a massive database and databases run off keys not nice descriptions. Humans however like to understand what something 'is' and for that we need a description.
So inevitably with limited characters we already have an obvious problem 'abbreviations', how many organisations have an agreement on abbreviations ? Why is this even important? If you want unique and consistent descriptors you must have agreed abbreviations, not only does it make it easier for business colleagues to understand the data they are looking at but helps in data analysis and helps avoid duplicates. Only a human knows that Grn, Gr, Gn and Green could all be the same thing !
Next consider where the description is going to be used, and so what it needs to contain, if it's only used internally then you have more flexibility if it's going on invoices or external documentation or being used directly on an ecommerce site then it needs much more consideration. What actually needs to be included in the description, are certain elements captured elsewhere (but watch that these are also accessible elsewhere) for example weights, colours or size?
Finally how should the description be structured? My recommendation would be that the most important element or element that best differentiates the item is used first or last (many systems allow wildcard searching so this just makes life easier for everyone).
Some factors to consider:
How does your organisation first think of the product or if used externally how might the customer think of the product for example, is it a
Table Square Wooden Large
Large Square Table Wooden
Wooden Square Large Table
Where is the description used or consumed ? (I have experience of situations where only the first 'x' characters are interfaced to external systems)
Can you describe all of your product types or categories using the same format and are there any exceptions?
What format do you want your descriptions in usually this is a decision between Uppercase and Sentence case. Uppercase is easier to manage and often technically preferred, but characters loose their shape and therefore don't always read as well.
Are there any industry standards for naming products could these be exploited?
What characters are you going to allow (or indeed can you allow)? In some circumstances special characters (non alpha or numeric) can affect how descriptions are handled when interfaced or exported.
Once all areas have been considered and an agreement reached for each product stream/ type then document the rules, be prepared for these rules to change.
So in summary:
1. Establish where, when the description is going to be used and by whom (be prepared for this to change) thereby understanding limitations.
2. Consider what the important elements are and agree a naming structure or convention for each relevant stream, brand consider any exceptions.
3. Develop an acceptable abbreviations catalogue.
4. Document and publish ALL of the above.
Finally consider that these rules could be applied to any descriptor in your system.