Commodity Management and CTRM – where is the Beef? Opinion
A few years ago, ComTech had a go at defining a variety of software categories including ‘Commodity Management’, ‘CTRM’ and ‘ERP for Commodities.’ Since then, with an increasing interest on moving and managing physical commodities and declining trading margins, more emphasis has been rightly placed on supply chains in terms of increasing efficiencies and reducing operational and other risks. Now that is an important trend in the industry, it means that more companies are looking for not just CTRM – which focuses on the trade – but for Commodity Management – which focuses on the entire supply chain.
ComTech encourages everyone to be consistent in use of terminology to promote a common understanding of terms across the industry and we utilize the terms – CTRM, Commodity Management and ERP for Commodities as follows taken from that white paper,
ComTech defines Commodity Management as the superset of software solutions that encompasses CTRM and ERP for Commodities where:
- ERP for Commodities naturally focuses on physical commodities and emphasizes production/procurement/origination, movement, storage, and handling of bulk and packaged commodities. This will usually include contract management, procurement, production, logistics, inventory management, assays/chemical analysis, pricing and fixation, hedging, settlements, and accounting. The primary users of this type of software are producers, industrial consumers, and processors.
- CTRM will have a trade-centric design with a focus on capturing and tracking both physical and financial trades, with configurable book and reporting structures, position calculation and valuation, PnL, and various aspects of risk, including market and credit risk. The primary users of CTRM software are traders and merchants.
We think these definitions make sense and that consistent application of those definitions is helpful in ensuring common meaning. However, we have noted even a few years ago the clash of software categories as CTRM vendors realized they needed to add certain ERP-like functionality and ERP vendors saw an opportunity to move in trading with CTRM-like functionality. This has only continued over the last couple of years further muddying the water. However, the differentiation can still be made.
So, if a solution comes with trade-centric functionality primarily including market risk and support for book structures but lacks functions like movements (by any mode of transport and including estimated and actual costs), inventory, analysis and assays, document management and so on, then it is a CTRM solution. Conversely, if a solution comes with all of that type of ERP functionality but lacks a complete ability to support trade management, then clearly it is ERP for Commodities. A solution that is both a trade management solution and supports ERP-type functions for supply chain processes is Commodity Management by our definition.
Unfortunately what happens in software marketing is that popular terms are ‘hijacked’ by marketers seeking to ensure their product gets looked at even when that term is really inappropriate for the product. It is akin to suggesting functionality is forthcoming as opposed to already included.
So the moral of this story is to always query the terminology. If you are told it is Commodity Management, test that by asking does it include ERP-type functionality to support the supply chain? And so on. Our Sourcebook is one good tool for reviewing the extent of functionalities. A quick demonstration of that software is another tool to check. Simply renaming CTRM as CM or vice versa really isn’t helping anyone as the names are meant to define the content of the application and if this trend continues then we will be left with three interchangeable synonymous and meaningless terms and even more confusion.
At least, that is my opinion.
Keep in touch and sign up to our Newsletter
