Or can you?
This week, I’d like to talk about drilling software. There seems to be two schools of thought when it comes to designing, or even choosing, drilling engineering software. The first is to try to cobble as many different capabilities as possible into one big package; a “jack of all trades, master of none” mentality. The other is to focus on modularity – a specific team of programmers and software designers focus upon one specific element of drilling engineering that they are expert in, say Temperature Modeling, and build a module for that. Many of these modules share setup files, so that a well set up in one module can be transferred and used as a base file for another module – saves a lot of BHA reentering… I bet everyone reading this has an opinion, one way or the other, on which way to go is best; I also bet it is a strong opinion!
HXR’s goal was to focus on drilling and use other modules as add-ons for more advanced applications, so, to an extent, we “split the difference”, in that we had a clear picture as to what capabilities were “mandatory”, and which were specialized enough to require their own module. For example, ERDPro® has strong Managed Pressure Drilling capabilities, but we use a separate module specifically designed for Underbalanced Drilling – gets too complicated with inputs for gas injection rates, parasite string lengths, etc. It took us quite a while, a lot of searching and evaluating (to the point of leasing or purchasing outright several different software packages…), to find a developer that could combine 100% of all of the capabilities a drilling engineer would need to design and monitor a complex ERD or offshore/deepwater well, but with additional software modules for the more rare or specialized operations. It was never our intention to put everything, absolutely everything, into one package, and we surely were never going to cobble in a few capabilities here, a few capabilities there, and call it complete. Our feeling was that there are indeed operations that are so rare, or so specialized, that to add them would only add to the complexity, and possible inaccuracy, of the main software. Plus, again, why have basic capability in one package, when you have access to a significant amount of capability? And why incur the time and cost of duplicating?
I thought this was a reasonably good decision, a real “management call”, and after more time and cost than I care to write about here, I found out that, well….
I was wrong. At least, to some people I was.
Just how strong these different ways of viewing drilling software are was brought home to me recently when a potential client of ours sent me a list of things that they wanted HXR’s Drilling Specialists to be able to do, on the rig, from an engineering standpoint. This is not an unusual request, and one we have never had issues with before. So, I looked at the list, and knew that we could do all of that, and much more, between our main software, ERDPro®, and a couple special modules from our developer. To be frank, I thought nothing more of it.
I was told that the client wanted all of the capability in one software package. There were 17 main items on the list with several subheadings each, but only two individual operations our software did not do internally (a relatively rare circumstance of tripping through multi-wt. and rheology fluids, which we use a separate module for, and cementing ECD, which again, we can model; we simply use another module available). Not to mention we offer extended reach drilling services and wellbore stability/geomechanics services our competitors do not…
I didn’t see the problem. The client, however, was not impressed….
Well, you can’t win them all, folks, and we offer capabilities above and beyond our competitors, so I took comfort in that and, hey, that is just part of running a company, right? But it got me thinking – where does it all end? How much capability, and user complexity, is enough for one software package? Must a single package have MPD and UBD? Must it have triaxial stress internal to it? How about tube move? If one of my competitors has Multi-Fluid Capability internal to their software, but I have a module for Multi-Fluid Capability, as well as modules for Temp Modeling, UBD, multiple fluid displacements, and tube move, is THEIR software “better”? Or is mine? A good software package like ours has the capability to adjust mw and rheology, by depth, using a temperature adjustment input; must that software also inherently have the capability to actually produce the temperature model itself? Or will another module suffice?
We’re an ERD company – wellbore stability and rock mechanics are absolutely critical to the success of a complex well. But we use specialized software (itself modular!…) to make earth models. Does that need to be part of a program as well?
Look at it another way – how little capability is acceptable in one software package for a given operation? How little can you “get away with”? And if you don’t have quite enough capability inherent in the software, won’t you then just have to go and use an outside module, or even another software package, anyway? What have you gained?
I guess in the final analysis, we’ve all got a job to do, and our names and reputations are on the line, so whatever works for you, I’d say keep doing it. Because it’s not all about the software – it’s mainly about the people using it, their experience, their capabilities. But the next time you’re faced with the decision between having 100% of the engineering capabilities you need to do a job right in 3 interchangeable modules, or the ease of 1 module but only 60% of the capability, you might have to weigh the pros and cons very carefully.
And whatever you decide? You’ll still be wrong…
We’d love to hear your thoughts on this subject.
Chris Speziale, President
About the Author