Buy vs. build: On reinventing the ETRM wheel

Larry Hickey,FRM, Sapient, London

Take a close look at your paycheck. Note that you're not actually paid by the company you work for. You're probably paid by a payroll processing company, perhaps ADP which pays 1/6th of all working Americans. Your company has outsourced the payroll function.

Payroll is critically important and involves highly sensitive data. But management recognized that your company has no comparative advantage in the provision of payroll services. So the function was outsourced to a payroll company which can provide the service securely, reliably, and cheaply.

"Securely" and "reliably" because payroll companies have developed specialized expertise in this area. They have a comparative advantage in the provision of payroll services. "Cheaply" due to economies of scale. The incremental cost of servicing another company is far less than it would cost your company to do it itself. Adam Smith would be proud.

If your company's do-it-yourself ethos extends to issuing paychecks, you can probably stop reading at this point. And good luck with your ETRM build!

The same considerations come into play when a company decides whether to buy a commercially available ETRM solution or attempt to build one from scratch.

First and foremost, the company must make a sober determination if the ETRM system is a competitive differentiator. Is the way you handle your portfolio over its lifecycle so different from the competition that it is part of your firm's competitive advantage? This is a high hurdle for a number of reasons.

What we do here is completely different. Really? By virtue of all trades having counterparties, there is at least one other entity wrestling with the same issues. How are they solving them?

Industry leading solutions provide full lifecycle support so the portfolio can be managed and optimized at the highest level of aggregation. A single system handles multiple commodities, integrates physical and financial transactions, and takes positions from forwards through physical delivery. Certain analyses such as credit and VaR only have meaning at the highest level of aggregation. Reiner Musier, chief marketing officer at Allegro Development, describes this "single version of the truth" as a key motivation for new customers coming from spreadsheets or in-house systems they have outgrown.

"Customers recognize that a patchwork quilt of point solutions is simply not scalable," says Musier. "They can do better."

Ditto at OpenLink where Wolfgang Ferse, executive vice president for commodity and energy solutions, reports about 10 instances over the past three years of oil companies that have outgrown in-house systems and are looking for a scalable, end-to-end system. So with end-to-end ETRM systems widely available, the need to roll up data from disparate point solutions is a weak argument for internal development.

Furthermore, leading solutions are modular and support plugins. Let's say your firm has a proprietary credit methodology that you believe is key to your profitability. But your deal capture, confirmations, risk analysis, position reporting, and invoicing are standard. You can quickly implement those specific modules to support your standard processes and then plug in your custom credit methodology.

The same goes for option valuation. Customers frequently implement proprietary option models or smile logic. So, even the need for proprietary pricing models is not a valid argument for internal development.

Against all odds, let's assume your portfolio handling is a competitive differentiator. The next question to ask is whether systems development is your core competency. An internal build will require not only the time of development resources. If the project is to be successful, it will also require extensive input from the front, middle and back offices. Do you really have the skills and bandwidth necessary to develop an ETRM system from scratch? Is systems development the best use of those resources?

Michael Schwartz, Triple Point Technology's chief marketing officer, notes, "There is a particular danger if an internal development initiative isn't business driven. Even if an organization has available IT staff, it doesn't mean they have the skills or experience to build a highly functional commodity management system…in fact, they almost never do."

It's easy to underestimate the effort required to develop a capable system. Consider a case from over a decade ago in Germany where a coalition of large energy companies joined forces to develop an ETRM system. The idea was for the IT departments to work with a development group to produce a system that would compete with established vendors. But they grossly underestimated the cost of doing so. About four years and 100 Mio DM later, the project was quietly abandoned.

Wolfgang Ferse notes that OpenLink's flagship product Endur is the culmination of "over 3,000 man-years of development and testing, with hundreds more going in every year." That's hard to replicate.

The relative stability of the ETRM business is another signal that significant barriers to entry exist. OpenLink, Triple Point, SunGard, SolArc, and Allegro are the top five names in the space. The youngest company is 18 years old. Much larger names have tried and failed to enter the space.

If companies that do internal builds do in fact have a comparative advantage in software development, one would think internally developed systems would be offered for sale alongside other commercial packages. But they aren't.

Just recently a major European energy company undertook a two-year analysis project to determine the feasibility of replacing a gaggle of third-party applications with internal development. In the end, the board decided that internal development was too risky and that software development was not the company's core competency. So they decided to license an enterprise solution to replace the legacy systems.

In addition to developing, testing and deploying your new system, you will also need to fully document and conduct training on it.

The facts on the ground

Allegro recently did a survey of energy companies regarding ETRM systems. The company received more than 250 responses, three-fourths of which were from trading, risk, or finance departments. They found a roughly even three-way split between a commercial system, spreadsheets, and an in-house developed system to run their trading and risk management business.

In 2010 Energy Risk reported on a poll with 190 valid responses where 54.7% described their software as mostly offthe-shelf with some in-house add-ons. 17.6% reported having mostly in-house build systems with some off-the-shelf. At the extremes, 17.1% reported using off-the-shelf software only and 10.6% said their software was in-house company-developed software only.

Both surveys have in-house development at roughly 30%. Is there any trend toward internal development?

"No. There are always some companies analyzing or starting in-house initiatives. But the trend is in the other direction," says Wolfgang Ferse. "Not only have commercial applications gained wide acceptance in the market, now we're seeing a push towards outsourcing the hardware the applications run on as well."

So this discussion is framed in a meaningful way, let's stipulate that ETRM implementations are complex undertakings that often involve a variety of systems. A 2003 survey found that 33% of the time a module of another system is used next to their main system. If the system of record at the center is a commercial system, that counts as a buy. If it's an in-house system, that counts as a build.

Let's say there is a valid theoretical basis for an internal build and you actually succeed in developing the software. Will you be able to maintain it?

Markets change. New regulatory requirements emerge. A key advantage of commercial packages is that the vendor is responsible for keeping abreast of changing regulatory and compliance requirements. This makes sense – one vendor instead of every energy company.

This service comes at the cost of maintenance payments, which are also used to fund enhancements to the system. By this means, the insights and requirements of the client base are reflected in the system.

Michael Schwartz notes that "Triple Point's multi-commodity solution, CXL, is an evolving best practices platform. Clients with deep market expertise request enhancements and modifications. Triple Point responds and, in so doing, the product is continually improved to better fit the markets we serve. Although every client doesn't request every improvement, everyone gets them. So our clients mutually benefit from each others' enhancement ideas. The more clients, the more great ideas that wind up in the product."

OpenLink's Endur fields enhancement requests from 15 of the top 25 energy and commodity trading firms by market capitalization. So, whereas internal development can only reflect the perceived needs of a small group, commercial applications leverage a much wider knowledge base.

In addition to maintaining and enhancing the product, vendors also have to provide migration tools to move to new releases and from de-supported to supported technologies.

Finally, let's state the obvious. Commercial software can be implemented quickly. It is thoroughly tested and is cheaper. The economies of scale are undeniable.

Reiner Musier notes that "With Allegro's component based software and agile deployment methods, energy companies can complete focused projects and start realizing value in as little as four months."

In the "choose your poison" category, there is the issue of becoming dependent on the system provider. If you buy, you will be dependent on the vendor. That didn't work out so well for customers on Contango when Vedaris failed in 2004. But failure among ETRM vendors is a rare occurrence. If you build, you will become hostage to…err, dependent on internal IT resources.

There are negatives associated with off-the-shelf ETRM systems. Let's address them.

First of all, even if they're cheaper than internal development over the lifecycle, licensing, and maintenance is expensive. Second, the software may require extensive customization to fully capture your business practices. This can blur the line between buying and building. You may investigate the business processes that drove the software to its current state and adapt accordingly or you may decide to choose a highly configurable application to support your processes as is. You will find that trying to shoehorn the last 5% of your requirements into the system can be prohibitively expensive. Finally, there is a wide perception that system tweaks are turned around faster on in-house systems. There are some perks to having the development shop on site.

It is perhaps for this last reason that users reported higher satisfaction with in-house systems in a 2003 satisfaction survey. In-house systems scored a 7.6 rating against a 5.7 for off-theshelf systems. The authors were unable to choose between two competing explanations.

In-house systems are on average better than off-the-shelf systems because they better fulfill the needs of the user or users of in-house systems are ignorant of the alternative. Put simply, inhouse systems are on average not better or worse than systems of external suppliers, but the close involvement in its development gives users a good feeling about it. Seven years later, a 2010 survey confronted the issue head on. Respondents, who were mostly happy with their systems, were asked – if budget was not an issue – whether they would upgrade their existing system, buy a new system or build a new one. 54% choose upgrade. 33% would buy a new system, and less than 13% would build a new system. That's 87% buy, 13% build.

And that's with the build enabling assumption that "budget was not an issue." It turns out budget is an issue on this planet.

Is it reasonable to assume that your IT shop is going to successfully deliver a capable system on budget, on deadline, and without you becoming a hostage to the developer? For the sake of argument and in the face of all experience, let's assume the answer is "Yes." Once developed, can the system evolve to meet new trading and regulatory requirements? Will it reflect anything more than the insights and requirements of a small group?

On balance, the evidence in favor of buying is overwhelming. The comparative advantage and economies of scale enjoyed by vendors trounce claims of uniqueness. The facts, it would seem, have a pro-buy bias.

Let's address the elephant in the elevator. I have spent the past 13 years implementing commercial ETRM systems. So I can hardly feign objectivity on this issue. While this is true, I am highly confident that the facts bear me out. Like black swans and Bigfoot, I have heard of successful, large-scale, internal builds. I just haven't seen one.

On the other hand, details on failed efforts are readily available. The stakes can be high. With rumors that a billion-dollar implementation exists, it pays to get this decision right. How much sympathy will there be for the next management that lets hope triumph over experience?

About the author