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.

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:

1. How are your Sourcing teams and Category Managers organized?
At the very least, you want to be able to segregate purchasing and invoicing data by responsibility.  This enables reporting by category manager / procurement stream for performance tracking and RFP/go to market planning.  In addition, if you can get to a granularity level where you can filter within a category to sub-categories of products which you can convert to lists with which to go to RFP, than a further granularity level adds value.  But beware, complexity is the enemy of efficiency if not mastered by your team.

2. How detailed do you want to get in your spend analysis?
How fragmented is the current spend environment in the company?  Other than satisfying borderline OCD analysts like myself with more data, what are the tangible/intangible benefits attached to going down into further levels of granularity than, for example, “writing instruments” for everything you can write with that is purchased?  I am much more of the opinion that if your maturity is low, you should start out with a simple, effective nomenclature to address your big buckets of potential savings and that you can elaborate more detailed commodity code levels for areas of spend that require it when your sourcing organization gets to higher maturity levels.

3. What else will the commodity code be used for? (ie. Search, Process behavior, accounting)
If you are leveraging a commodity for for things like search (which is often done for MRO), then this can sway your nomenclature towards being much more complicated and precise so as to enable maintenance technicians and planners to find the right parts for example.  Personally, I think this is a perversion of the commodity code and that the data to enable search should be captured in the material number nomenclature or in a classification mechanism (such as in SAP ECC where you assign classes and characteristics to material masters).

If you are using commodity codes to drive different processes (in solution enhancements or configurations), then you may get your hands tied later on when you want to make changes to this commodity code structure as configuration or blocks of code will require modifications before you can change your commodity codes.  Therefore, be weary of mapping to these.  However, that being said, it is sometimes the only valid discriminator to route a process.

If you are using commodity codes to default accounting for non-stock purchases, then you may want to bring the chart of accounts into the fold when designing your nomenclature.  Usually, you will only be able to map a single General Ledger (GL) account to each commodity code so this has to be considered in the design.  Usually the business will opt for adding complexity to the commodity code structure instead of simplifying the GL structure but it’s always a valid fight to fight!

In short, it doesn’t really matter which nomenclature you use… As long as you have a single, common one in your organization and that it serves your purposes while being as simple as possible, you have a good commodity code nomenclature policy.  People will stop spending time arguing about which codes should be included/excluded, which codes new materials should be mapped to and which configurations/developments need to be changed and will spend more time doing what you need them to be doing which is cultivating potential savings with sourcing activities.

– Joël

What has been your experience with commodity code nomenclatures?  How does your view differ from mine?  Have you seen any organizations benefit from tremendously granular commodity code structures?

If you liked this post, why not Subscribe