A Perspective on ERP/Procurement System Commodity Codes

I was recently asked about my take on how to configure material/system commodity codes in ERP/Procurement systems.  Here are my main takeaways from multiple implementations of a set of commodity codes.

When implementing a new Source-to-Pay solution, you can usually either put in your own hierarchy or use a standard nomenclature such as the United Nations Standard Products and Services Codes (UNSPSC). For companies that have refined their own nomenclature in legacy systems over time to have a really good, industry/business specific list that is fine tuned for their context, I advise against trying to convert to UNSPSC because the benefit is marginal in comparison with the change management impacts this will inevitably bring on. The principal benefit to using a standard like UNSPSC is that you are using a common language with the outside world.  This may make your Business Network Vendor Onboarding process a bit easier as you won't have to maintain UNSPSC to custom commodity code mappings but the majority of your vendors are not maintaining this data for their products.  The real value of commodity codes is use within the company's walls therefore you always have to consider how the data will be used later in the process to determine the best way forward.

Concrete Examples

To illustrate, here is what I view as the most important points to consider when selecting your commodity code nomenclature - the underlying assumption being that the commodity code is a set of data which should serve and be owned by procurement:

Subscribe to Premium to read the rest.