Leading Practices for Integrating ETRM & ERP Systems

Introduction

Managing commodity supply and trading operations in a volatile marketplace often demands the flexibility of purpose-built commodity trading and risk management systems with powerful position/exposure reporting capability. In today’s regulatory environment, the robust financial controls afforded by a tightly integrated record-to-report process are a necessity. Leveraging leading practices for ETRM solution integration with ERP back office systems enables energy companies to achieve quick time-to-value, manage implementation risk, and optimize total cost of ownership.

The Need for ETRM & ERP Integration

Integrating two different enterprise-class software solutions to provide for a high degree of transactional fidelity across systems or to enable value-added analytical scenarios can be a complex endeavor. Business and IT leaders most commonly find themselves undertaking this integration challenge in instances where:

  • Clients have an existing ERP footprint and require the power and flexibility of a dedicated ETRM solution
  • Companies pursue a “best of breed” IT application strategy resulting in ETRM and ERP solutions from different software vendors
  • Firms are seeking to replace a mainframe/midrange or custom trading solution with a commercial “off-the-shelf” system
  • M&A activity results in a heterogeneous application environment necessitating ETRM to ERP integration
  • Organizations that are in the process of migrating existing ERP or ETRM platform(s) to the Cloud
Challenges of ETRM and ERP Integration

Once a management team makes the decision to implement a dedicated ETRM solution and integrate it with an existing ERP footprint, the inherent differences between the platforms will likely lead to a set of challenges for the project and support teams to address. Some of the issues commonly facing ETRM and ERP integration projects include:

  • Variations in the methods by which certain key calculations are performed by the respective systems (e.g., COGS, inventory value)
  • Timing mismatches and interdependencies between real-time and batch processes across solutions (e.g., snapshots, month-end close)
  • Differences in precision, rounding, currency conversion, unit of measure conversion (e.g., mass and density to volume)
  • Technology and architecture differences between the ETRM system and the ERP environments (e.g., SOA, development tools, source and configuration management)
  • Inconsistent and, often, poorly understood data models between the ETRM and the ERP systems (e.g., customer vs. business partner)
Where to Draw the Line

Typically, both ETRM and ERP software systems are developed by their authors under the assumption that the entire origination-to-settlement lifecycle will be processed wholly within the single system. Integrating ETRM and ERP systems generally necessitates breaking that transaction flow at one--or more--execution steps. For example, a deal that begins life in the enterprise trading system may be settled in the ERP application. If the architecture is not considered carefully, this can result in unfinished processing in one system and incomplete information in another.

The best results are typically achieved when the integration occurs along the transaction lifecycle at natural breaks in the process such as:

  • Integration Scenario 1: After deal capture and/or contract generation
  • Integration Scenario 2: After scheduling and actualization
  • Integration Scenario 3: After billing and invoicing
Each basic alternative offers distinct advantages, disadvantages, benefits, and costs. We’ll explore each of the above here but there are many more in-between scenarios and options that could be considered to tailor the resulting integrated solution to the particular needs of any given client.

Integration Scenario 1: After Deal Entry

In this scenario, the commodity trader will enter their deals into the ETRM system. Once the deal has completed the requisite verification or confirmation process(es), the trade is sent to the ERP system. A purchase or sale contract is created in the ERP system mirroring the original deal recorded in the ETRM platform.

Advantages & Benefits

  • Allows for notional trade P&L in the ETRM system from the moment the trade is captured for all forward contracts.
  • Results in a straightforward, one-way interface. Any change in the deal from the ETRM system is simply pushed to the ERP application as a modification to the purchase or sale contract.
  • Minimizes the number of correction and cancellation scenarios to just those impacting the primary economic terms of the deal resulting in more straightforward business rules for the interface development.
  • Minimizes the disruption to downstream ERP processes such as credit or treasury management that depend on purchase/sale contract information, movement data, etc. for timeliness and accuracy.
Disadvantages & Costs
  • Must map data elements between two different, complex pricing engines so that the trade can be settled in the ERP system the same way it was contracted in the ETRM.
  • Real-time scheduling and actualization data is not made available to the ETRM system for up-to-date position keeping.
  • Only secondary cost information directly associated with the trade itself will be available in the ETRM system for P&L reporting and evaluating trade economics.
  • Counterpart credit information such as current AR balance will not be available in the ETRM system at the time of deal capture.
  • Requires duplication of market data feeds to ensure that pricing is available for notional P&L in the ETRM system and for settlement pricing in the ERP.
This first integration scenario can work well in instances where a minimal ETRM footprint is required and is serving limited lines of business. A prime example would be a small, specialty products refiner implementing a SaaS ETRM solution to manage a very limited, non-core wholesale diesel and gasoline business. Another case could be a power utility leveraging a limited number of seats for a packaged ETRM solution to manage coal purchases for a legacy generation asset with a relatively short operating horizon.

Integration Scenario 2: After Actualization

The second integration scenario explored represents a kind of middle ground between relatively ETRM-centric and ERP-centric models. In this case, trades are entered, confirmed, scheduled, and ticketed in the ETRM system and then interfaced to the ERP.

Advantages & Benefits

  • Utilizes only the pricing engine of the ETRM application feeding the final, calculated settlement price to the ERP for billing and/or payment processing.
  • Real-time position keeping data is available in the ETRM system and automatically updated as movements are scheduled and actualized.
  • Only “stable” trade data is sent to the ERP platform, limiting the number of correction and cancellation scenarios that must be accounted for via integration logic.
  • No duplication of market data feeds is required since all pricing calculations are performed in the ETRM solution.
Disadvantages & Costs
  • Certain processes like split orders, partial deliveries, etc. require more complex interface business rules.
  • Corrections will sometimes require actions in both systems if they occur late in the transaction lifecycle.
  • Credit and treasury in the ERP system will have a very limited forward view of counterparty exposure and liquidity forecasts.
Integration Scenario 2 can be a particularly good fit in instances where the client has a broad, mature ERP footprint already in place but also demands robust position, exposure, mark-to-market, VaR, etc. that the dedicated ETRM can more readily provide. A real-world example could be a large, independent refining company with a more sophisticated asset-backed trading strategy necessitating the use of more-- and more complicated--hedging programs to manage risk.

Integration Scenario 3: After Invoicing

In the instance of developing the integration from the ETRM system to the ERP system after invoicing deals are entered, confirmed, scheduled, ticketed, and invoiced in the ETRM system and then interfaced to the ERP creating AR, AP and GL entries.

Advantages & Benefits

  • Utilizes only the pricing engine of the ETRM application feeding the final, calculated settlement price to the ERP for billing and/or payment processing.
  • Real-time position keeping data is available in the ETRM system and automatically updated as movements are scheduled and actualized.
  • Offers a simple cross-system correction process; cancel and re-bill/re-invoice the transaction in the ETRM and reverse/repost all accounting entries in the ERP.
  • No duplication of market data feeds is required since all pricing calculations are performed in the ETRM solution.
Disadvantages & Costs
  • This model does not leverage the ERP platform’s native cross-module integration--likely eroding some of the value contemplated in the original business case for ERP implementation.
  • Moving scheduling and ticketing to the ETRM system will require significant change to mid/back-office processes and procedures.
  • Credit and treasury in the ERP system will have no forward view of counterparty exposure and liquidity forecasts.
  • Current counterparty credit information will not be available in ETRM at the time of deal entry since payments posted to accounts exist only in the ERP system.
This 3rd integration scenario can yield positive results in terms of time-to-value for delivering an integrated solution in situations where the existing ERP footprint is very limited or in short transition M&A situations. A realistic application of this model could be the case where a large independent refining company acquires another smaller peer that has an existing, mature ETRM solution already in place--allowing for a more rapid integration of the acquisition with limited initial change to the related systems & processes of the acquired entity.

Conclusions

The three integration scenarios explored above are not the only options available to firms engaged in energy trading, but may serve as a directional guide to the available alternative integration models. Spending time up front to determine the integration framework that delivers the best mix of advantages, disadvantages, benefits, and costs in a particular business context will prove well worth the effort. Regardless of the integration model selected to arrive at a solution that combines the strengths of today’s ETRM and ERP platforms, the following principles should also be carefully considered:

  • Cleanse core master and reference data and tighten related information management processes to simplify cross-references and reduce the potential for integration errors.
  • Integrate to support the timely and accurate completion of business processes--as opposed to simply to provide data to an existing OLTP system for reporting.
  • Consider utilizing ETL to a data warehouse or other analytics solution to provide for cross-system reporting and reconciliation capabilities.
  • Try and minimize back-and-forth between systems. One-way interfaces are more straightforward to design, develop, test, and support in the long-term.
  • Avoid synchronous cross-system calls where feasible--to improve integration performance and limit cross-system processing dependencies.
  • Carefully consider your company’s IT delivery and support core competencies when architecting the integrated solution and either (a) align the solution with your organization's strengths, or (b) plan for training and expert 3rd party assistance.