This is a diatribe against standardization in E&P software technology.

And also a diatribe against customization in E&P software technology.

That’s because while One Size can *almost* Fit All, it never quite gets there. Skip to the end for some tips on balancing between standardization and customization!

When I was a newbie reservoir engineer at ExxonMobil in 2003, I knew that I was joining a serious group of nerds. But it really hit home after a couple of years, when I realized that like half of my coworkers at the Upstream Research Lab had written their own reservoir simulator software at some point. This kind of blew my mind, because I thought of myself as “one of them”, but I never would have considered doing that.

With 20 years of hindsight, I have a better understanding of not only why they wanted to do that, but also why it’s a terrible idea. Doing customer software development is really expensive and almost always ends in an impossible-to-maintain mess. But on the other hand, a software package that tries to meet everyone’s needs guarantees that it doesn’t exactly meet anyone’s needs. So let’s talk about how to walk this tightrope…

The Case Against Standardization

E&P businesses aren’t quite snowflakes, but they sure do feel like it sometimes. They are all trying to make money producing hydrocarbons, but they are big and small, fast and slow, young and old. They operate in different basins, have different financing, and different expected lifespans (18 months as Validus had to have set a record, right?!). Basically every E&P I know has a unique “tech stack” (slang for the set of software tools you use). They mix-and-match software vendors, have duplicate tools with overlapping capabilities, and often use spreadsheets to get core workflows done.

Why do they end up there, when so much about the business of an E&P is similar from company to company? I see three main reasons, in decreasing order of importance:

1. Differences in business objectives
2. Personal preferences of team members
3. Inertia (It ain’t broke, don’t fix it.)

With all these factors pulling companies towards unique combinations of off-the-shelf tools (or even custom software development), standardizing tech stacks between companies don’t make much sense. And even asking that a single piece of software be consistently implemented across multiple customers can be too much.

Why’s that? Let’s take production allocation software as a for-instance. Some companies have rod pumps, some gas lift, and some free-flowing wells. Some production batteries have bulk-test systems, others single-well measurement, and on and on. If they’re all using the same software, why would you expose all of that complexity to the end user if you didn’t have to? Let big, complex organizations use big, complex software. Let smaller, simpler organizations use smaller, simpler software!

Oh, we have reasons not to customize. Many, many reasons.

The Case Against Customization

We see three big reasons that customization is killing the E&P industry’s ability to digitize the business:

1. The long tail of low-utilization tools
2. Constant reskilling of professionals
3. Barriers to successful M&A

There are many hundreds of software tools targeting E&Ps, but based on our E&P Software Survey, only a handful of tools have over 25% market share – ARIES, WellView, maybe Merrick and CygNet. Everything else is lower, often much lower. That means that lots of low-utilization tools struggle to earn enough revenue to justify real investment from the software companies. So feature lists stagnate, integrations are slow and painful, and cost per customer stays high.

Our second big reason is the constant reskilling required for E&P professionals to move from company to company. Switching tools isn’t quite like learning a new language, but it gets close. That hurts worker productivity. Worse yet, what happens even more often is that healthy staff churn *doesn’t* occur because Merrick people stick with Merrick, Enertia people stick with Enertia, and WellView people stick with WellView.

Finally, mergers and acquisitions have substantial execution risk due to the need to consolidate these diverse tools post-merger. Those consolidation efforts are necessary to achieve synergies, but they are slow, painful, and expensive. And while the staff is distracted with that work, base operations can suffer.

Walking the tightrope

So how do we balance these competing needs? Three tips to keep you balanced:

1. Write down your decision criteria. This sounds so simple and easy, yet it so rarely happens. If you’re choosing standardization, why? If you’re choosing customization, why? Lay them side by side and really understand your options.
2. Be honest about risk aversion. I often see software decisions that are being made by inertia and fear of the unknown, but nobody wants to admit it. I believe that risk aversion by E&Ps is rational (see our prior blog post on this), but if you pretend you’re choosing status quo for the wrong reasons, you’re only fooling yourself.
3. Involve your C-Suite in tech stack decisions. It isn’t always easy to get them engaged, but your CEO, CFO, and COO need to understand how your software decisions are getting made, and to help IT and mid-managers understand how the long-term vision might be impacted.

We hope this is helpful. There aren’t easy choices in this area, but letting yourself stumble into a choice without weighing the pros and cons is a choice in itself. Give us a call if you want to talk about this kind of thing!