Digital Energy Journal- NDB - functional eExcellence depends on Technical Software

Join | Existing Member Login

You are Home » News » View Article

NDB - functional eExcellence depends on Technical Software

Thursday, August 13, 2015

If you don't know what software is being used in each case for mapping, well correlation or geo-cellular modelling for example, you may not be in control of what is being done in the name of geology in your organisation, said Ed Evans of NDB

Having a structured system and process for deciding what software applications your company is going to use, and where, could go a long way to improving the quality of work from your geoscience staff, said Ed Evans, managing director of oil and gas consultancy New Digital Business.

He was speaking at the Finding Petroleum conference in Aberdeen on March 12, 'Transforming Subsurface Interpretation'.

There are challenges associated with selecting technical software applications and most users have preferences but the organisation must manage applications actively to best support 'Technical Excellence'.

"It is never a popular subject speaking to geoscientists about process or standardisation, as it felt that process can destroy creativity," he said. "I believe process enhances creativity: it gives you more time to think about things that really make a difference'.

For the geoscientist or engineer the impact of the software portfolio, what software tools you have available to do your job, plays a key part in effectiveness. But despite its apparent importance to the business the software portfolio is rarely 'actively managed'. "What I'm really arguing against is laisse faire, just buying [a software package] because somebody wants it based on a demo or a personal preference," he said.

"Taking away the software you don't need, ensuring selected applications are available for particular core activities, saves a lot of money and leads to improved quality," he said.

Functional excellence

Good management of software applications can help oil and gas companies achieve 'functional excellence'.

"A client I've been working with, a chief geophysicist, was using the term 'functional excellence' as a description of a range of activities implemented to improve the quality of technical work being done within Geophysics" he said. "He defined a functional excellence framework." Software tools and organisational competence with the software was a key part of this framework.

However the term Functional Excellence is not always used in the same way. 'Some people define it as continuous improvement, others say, its about our expertise or team being better than everybody else's,' Mr Evans said. 'In reality, it's about supporting the technical team in the organisation to do a better job'.

'One way to improve functional excellence is to make sure they have the right software tools and know how to use them', he said.

Good software practise

Good software practise means 'a user can work through a process without any assistance, they are familiar with all the tools, the data doesn't need re-formatting,' he said.

Also 'handovers are predictable, the geologist knows what they will get from geophysicist and vice versa, there's no surprises, they've got software that fits with key technical workflows," he said. "The users are skilled in the software available and the support organisation is fit for purpose'.

Many organisations have the opposite of this, with working processes where "every step requires a re-format of the data. Handover depends on which tool the previous person prefers. There's quite often too many choices of software."

"I've seen situations where, because of the recent skills shortage, people would come from different organisations to join an oil company with different skills and experience. There was no regulation about what software anybody used. There was a whole range of tools from different platforms to different generations from the same supplier. People even brought their own tools, on laptops, because they were familiar with it."

If we believe that exploration and production is a team effort then a situation where models are built and shared in an uncontrolled systems environment makes the work more difficult.

"The head of geophysics [in one company] said he found it very difficult to supervise his team when they were using Petrel because he wasn't familiar with it. He'd spent his whole life using Geoframe."

Software you know

There can be high costs associated with asking someone to change to a different software package. "The quickest way to make a competent geophysicist incompetent is to change the software they use," he said.

"It is not rocket science. It takes some time to go from a tool you've been using for 15 years, to another tool, where the developer has splattered everything around on different pages using different icons."

One example was a geoscientist who had been transferred to Trinidad, where people were using a different subsurface software. She had to make the decision of whether to continue with technology with which she was familiar and rebuild the model, or learn the other package. "Either way it means it will take 2-3 months before that person is effective in that part of their role," he said. "These things are often not thought out in advance."
Experienced geoscientists have developed an extensive understanding of the validity and risks of the different techniques and models they have employed throughout their careers. This 'organisational' competency can be undermined by the use of inappropriate, inaccurate or unfamiliar software. For example when asked to peer review technical work within a tight timescale, a lack of familiarity with the application presented may limit the challenge and guidance that can be given. This could lead to under-reduced risks, poor techniques and poor models getting through the stage-gates and therefore leading to drilling failures. There are many examples of this kind of process failure in organisations where poorly built models make it through despite there being many very experienced geoscientists.

Model of your environment

In order to make sure staff have the right software applications available, you need to understand what technical processes staff perform, and which tools they need to do them. In most circumstances the tasks are fairly standard from one company to another, what varies according to the geological situation and the maturity of the understanding, is the data available and the impact any given technical task has on reducing risk.

You start by building a simple model of your technical environment showing the tasks carried out and the software tools they have available to do it.

You can list all the software applications you have to do a specific task. "It's not unusual to have 4 or 5 software tools that all do the same thing - and individuals have their own preference of which software to use,' he said.

It is a straight-forward process to map the applications being used for technical work. NDB does this from the 'work or task' perspective first rather than from a 'list of the applications' perspective. The Discipline teams can then review the software identified for their own part of the science, the 'Geology Toolkit' for example, and make a choice to keep or retire each application. Along the way the discipline team can select the core software tools to be used for creating the core models within their discipline.

The Software applications can be grouped into 'toolkits' associated with each technical discipline. Specialist tools can be retained for specialist tasks or when additional modelling is required

NDB builds a 'dogtag map' which puts all the software tools in the context of the business, and which tasks they are used for, colour coded according to the function (which tools each person uses).

"You can pretty quickly see what tools a reservoir engineer has at their disposal, the same for the geologist or geophysicist," he said. These toolkit lists can be presented back to the team for refinement.

"Going through that exercise engages IM/IT with the business in a more focused way and the focus on key software means that the exercise often pays for itself."

HQ and asset

A common problem is that asset teams (people working on specific assets) push for certain specialist software packages to be purchased.

But if this issue is looked at from a company-wide perspective, it will probably make more sense to determine that certain software applications are available throughout the company, and other applications are only available to specialists, perhaps within the skill centre or for smaller companies via contracted work.

"We split the tools up into core or 'asset' tools, and specialist tools,' he said. "'Asset' tools or 'core' tools are what each geologist or geophysicist can expect. Specialist tools might be tools just kept in headquarters, only available to 1 or 2 people."

Discipline Practice determined by the tools

The hardest part of the software management process is making decisions about what applications to keep and what to retire.

The best person to make such a decision is often the discipline head and their team. Such as the Head of Geophysics and the individuals who are recognised authorities in the organisation for example your best person on gravmag, your expert in QI or in 4D.

If the discipline head is responsible for work done in the company in that field, it fits that the discipline head should choose the software applications, since the choice will make a big impact on the quality of the work.

The important thing is that the discipline head is actually able to make a solid decision for the company based on specific criteria, not a guess, he said.

"It is very difficult sometimes to get users engaged in making decisions about process, data and applications," he said. "But when we can make the case that the practice within the discipline is determined by the tools we get more involvement and ownership'.

Active Maintenance

NDB also offers services to help companies with this process. 'We have worked with functional leadership and the IT people in many organisations in order to develop 'Active Application Management' and improved ownership of the software portfolio by the teams who really depend upon it,' he said.

NDB has a simple three-step, quick-turnaround process, of 'map the Technical Applications, review and classify with each discipline team, and implement the changes,' he said.

'The effort will often pay for itself,' he said.

'The smallest company can reduce license costs and maintenance by $100,000s. For larger companies the savings can be in the millions. Savings are repeated each year. Reducing complexity makes support more efficient. Users can focus on skills development and knowledge capture.'

You can watch Ed Evans' talk on video and download slides at www.findingpetroleum.com/video/1284.aspx

Associated Companies
» New Digital Business

CREATE A FREE MEMBERSHIP

To attend our free events, receive our newsletter, and receive the free colour Digital Energy Journal.