Find out everything you need to know before starting an ETRM system implementation.
Over the last two decades many energy companies that engaged in the purchase and sale of commodities as a matter of course in transacting their day-to-day business elected to implement purpose-built trading and risk management systems. These technology projects were often proven to be more expensive and time consuming than originally anticipated. While a number of factors can and do contribute to the overall cost of these initiatives there are certain recurring themes that emerge when looking back at similar programs across clients in recent years.
In many cases, companies have opted to use an IT project as a catalyst for organizational and process change compounding the problem. Once software has been purchased and the technology delivery team is on board costs begin to mount rapidly. Spending time upfront addressing certain themes prior to the kickoff of an IT project to implement an energy or commodity trading and risk management (E/CTRM) system can significantly reduce the risk of budget and/or schedule overrun. This concept is equally applicable to organizations considering a greenfield implementation compared to those contemplating a business transformation leveraging an existing technology platform.
Frame the Commercial Strategy
Ultimately, the implementation of an ETRM system is intended primarily to provide technology enablement for the execution of a commercial strategy in the context of a particular business model to create value while ensuring adequate institutional control. The primary themes examined here concentrate on the ways in which IT implementation cost can be managed by efficiently describing these objectives. A well-formed commercial strategy will articulate how exactly the trading organization’s vision and mission supports that of the broader corporation, how the business unit will pursue value creation and the ways in which the function’s contribution will be measured. All of these elements can have a material impact on ETRM application configuration, customization and integration required to satisfy business objectives.
By way of example, let’s consider a downstream organization embarking on a business transformation from supply buying and fuels marketing to asset-backed trading. A shift from balancing supply and demand obligations to maximizing value created via trading in a way that exploits opportunities originating from advantages inherent in the company’s asset base will necessitate certain features and functions within the trading and risk management system in order to identify opportunities, execute the necessary transactions and measure results. In this case, the requirements will go beyond simply tracking the profitability of purchase and sale pairs to necessitating examination of where in the value chain financial contribution occurs, as well as contemplating the costs that erode this value proposition. For instance, which commodities will be traded and in what markets in order to maximize the value of the asset portfolio?
This set of requirements will inform how a strategy hierarchy (i.e., book structure) is defined, what transaction/trade types are utilized and what reports (i.e., KPIs) are needed to demonstrate performance. Further, will these metrics be applied at business unit level? Regionally? Across commodity groups? At the individual trader level?
All of these factors will drive IT implementation cost because they fundamentally bound the scope of the project. A requirement in identifying how much money has been made by capitalizing on geographical arbitrage opportunities by trader results in a certain strategy structure to indicate commercial intent, the need for transportation deals with associated secondary/ancillary costs to isolate value creation and a contribution margin for each trader on the team. Waiting to frame these needs until software is licensed and consultants are staffed will inflate costs as the implementation awaits definition or continually reworks solutions while the organization learns.
Define the Risk Policy
Every business venture involves the deliberate taking of risk to afford the opportunity for value creation. Certain risks are inherent in the fundamental business model, anticipated by stakeholders and accepted by the organization. Others must be managed and mitigated in a manner aligned with the company’s overall mandate and supportive of the commercial strategy described previously. A robust risk management policy will describe these residual risks, assign ownership and prescribe methods for delegated authority, define how they will be assessed and monitored and identify what tools may be applied to manage them.
From the perspective of an IT trading and risk management system implementation project the decisions on each of these points will identify tool configuration and customization needs. An independent refining and marketing company may assert that its board-assigned remit is to achieve the day-of-refining margin. This commercial objective indicates that commodity price volatility occurring outside the window during which the material is work-in-progress at the refinery is an unacceptable risk and must be managed. A hedging strategy will be selected by the trading business unit and the risk policy will authorize who can use what quantities of certain instruments (e.g., futures, call options) to mitigate the market price risk and capture the day-of-refining margin.
In the course of system implementation, requirements like those above will inform the IT team as to what trade types will be configured within the ETRM, what exchanges or brokers might be integrated to/from (e.g., the Chicago Mercantile Exchange, the Intercontinental Exchange, etc.), how price curves will be configured, the ways in which risks will be decomposed, the quotes necessary to perform valuation, how limits will be applied, what risk metrics (e.g., VaR, Sharpe ratio, RITC) are to be computed, etc.
Identify Regulatory & Compliance Obligations
Reporting is a key area for trading control and risk management that will be informed by the basic control framework (e.g., COSO/COBIT), as well as external regulatory requirements (e.g., Dodd-Frank, MiFID II/MiFIR, SOX). Formalizing these control and compliance obligations as any IT project is being chartered will aid in providing scope, cost and schedule certainty for project sponsors and key stakeholders. Often, it’s these needs in particular that unexpectedly expand IT project scope beyond the boundaries originally established.
Technology leaders have a natural tendency to approach these kinds of projects from the perspective of the features and functions common to E/CTRM technology platforms. However, some of the most important capabilities within the regulatory and compliance domain often lie outside the frame typically addressed by this type of solution, bleeding into areas dominated by ERP vendors such as SAP, JDE and Oracle Financials or purpose-built compliance monitoring tools like B-Next or TradingHub. Will financial reporting and disclosure requirements change as the enterprises move to this new business model? Is there a need to monitor trader communications to ensure compliance? In each of these cases, incremental investment is demanded of the IT project in order to integrate to and/or modify the functioning of the ERP backbone, provide more extensive integration along the transaction life cycle with such solutions, or procure and implement targeted regulatory and compliance technologies.
Establish Business Model & Corporate Structure
On the surface, this might seem to be a silly question to even ask at the outset of a trading and risk management system implementation. As previously indicated, companies often take advantage of the occasion of a major system implementation to affect organizational change, which commonly extends to transitions in the business model. These kinds of business model shifts can include important considerations such as the migration of commercial activity to tax-advantaged jurisdictions or the concentration of all business activity into one legal entity so as to create a single face to the market.
Changes such as these can have far reaching implications for IT systems projects extending well beyond what typically resides within an E/CTRM deployment. Will all trading activity be domiciled in a tax-advantaged jurisdiction in order to maximize profitability? Will the commercial organization own all inventory of raw materials and finished products and take LIFO accounting under U.S. GAAP wherever permissible? At what transfer price will inter-affiliate transactions occur and what level of automation is required to efficiently facilitate the internal purchases and sales associated with this activity?
The answers to questions like those above will determine if additional technology purchases, implementations or the restructuring of existing solutions will be necessary to achieve business objectives. If these kinds of decisions change during the project life cycle of an E/CTRM implementation then they can have a dramatic impact on cost and schedule given their structural nature. This could result in changes to company configuration, internal business associates, strategy hierarchy (i.e., book structure), etc. within the E/CTRM, as well as changes to master/reference data in the ERP backbone, including company codes, profit centers, and the like. In addition, obtaining certain specific tax licenses or certificates combined with the necessary determination software or ERP/ETRM configuration may find their way onto the project’s critical path.
Conclusion
Energy or commodity trading and risk management technology system implementations are no small undertaking in their own right. The introduction of new IT skills and specializations, the extensive nature of the necessary cross-system integration requirements, the learning curve inherently demanded of IT experts as they learn trading and risk industry jargon, on top of the fundamental complexity of the trade-to-cash lifecycle, all contribute to project delivery risk. Deliberate action taken prior to the initiation of a technology project in order to solidify business requirements in key thematic areas can play a significant role in controlling project scope, schedule and cost. Business and IT leaders have the opportunity to manage implementation risk as described, but also to more clearly set expectations and establish the case for change surrounding E/CTRM projects from the outset in a way that will pay dividends in the short- and long-term.
