I participated this week in what I though were two excellent panel discussions at Commodities People’s Energy Trading Week events. The first panel was on Technological innovations in risk management moderated by Sadar Abdul Rasheed, Director of Commodity Risk Control, Savola Group and featuring Ami Daniel, Co-founder & CEO, Windward, Jose Lopez, Digital Strategy Director, TradeFlow Capital Management and Ganesh Natarajan, COO, Enuit. The second was What Do Future ETRM Systems Look Like?, moderated by Richard Payne, Partner at Capspire and featuring Chirag Ahuja, ETRM Support, Varo Energy,Richard Williamson, CEO, Gen Ana García Arias, Head of GEM Digital Strategy & Cybersecurity, Iberdrola and Alex Whittaker, Risk Manager, Bonroy Petchem Co ltd – along with myself. The discussion on both panels was first class and frankly 40 minutes was nowhere near enough!
However, for me, one key moment was when Alex Whittaker talked about the need for critical thought when implementing ETRM and one aspect of the point that he was making that ComTech has tried many times to explain. That is that highly configurable ETRM and CTRM software is also complex and difficult to get to know during an evaluation and implementation process. In fact, quite often, even some of the vendor’s own team do not fully appreciate the depth of configurability built into a product, and this is absolutely key to successfully implementing and avoiding the pitfalls that so many others encountered.
While we can have discussions about adopting the business processes implicit in the software and just how far you can go with the during an implementation (and that does take critical thought!), making work arounds or even worse, code enhancements, for a bit of functionality that actually, the system can achieve out of the box via a bit of obscure configurability has to rank somewhere in the top 10 list of implementation mistakes list. In my career, I have seen this occur innumerable times and it was always avoidable with a bit more time, patience and yes, thought.
The problem is as stated above that many times only a small ‘braintrust’ at a vendor truly know all of the ins and outs and capabilities built into the software. Quite often since no one has this knowledge on a project team and since the braintrust is not consulted, a gap is identified that actually isn’t a gap at all! This then results in a work around or an enhancement request. This issue can arise multiple times on the same project as well! This adds costs and complexity to the implementation and results in downstream support issues as well if those enhancements are one-offs. Yet, with a little more time spent with the software and a little more questioning of the vendor, many of these may have been avoided altogether. I thought Alex explained this remarkably well.
It is undoubtedly something that happens very frequently and yet, unless you have experience of implementing CTRMs, you may never think of it as a risk. You may not even get what I am talking about until you experience it yourself. The key to avoiding this common mistake is to take a bit more time, have your team play with the software and liaise with the experts at the vendor as to how best to use it and always be on the look out for lack of knowledge – even from vendor staff – about a the capabilities of a product.