M A N A G E M E N T

MANAGING DATA ASSETS TO IMPROVE BUSINESS PERFORMANCE

P .C. Lesslar and F.G. van den Berg, SPE, Sarawak Shell Bhd.
SUMMARY

A project to improve integration of data and computer applications for exploration, appraisal, and field-development planning is ongoing at Sarawak Shell Bhd. An increased awareness of the importance of data as an asset has resulted in definition of a project aimed at improving the exploitation and management of this asset. This is expected to affect business through increased staff productivity and realization of new development opportunities through better subsurface interpretation and field management.
INTRODUCTION

During 199596, Sarawak Shell underwent an organizational review to transform itself into an asset-based organization. Integrated asset teams that encompass exploration, development, and reservoir-management activities were formed. During the review phase, subsurface- and surface-data management were identified as key areas that needed to be addressed and improved. Small teams were subsequently set up to define the scope and terms of reference for these projects. This paper describes the objectives and setup of the Subsurface Data Integration (SSDI) project.
PROJECT MANAGEMENT AND LOGISTICS

between them. General connectivity among all these is hampered because each application and each database has its own data model. The aim of the SSDI project is to integrate the data along the entire business process and to make it available and easily accessible to the asset-team technical professionals. For example, the results of seismic interpretation and well correlation would be fed to mapping, then to three-dimensional modeling and simulation, next to development planning, and finally to volumetrics and economics. An off-the-shelf solution that would incorporate third-party and Shell packages was not available. Therefore, integration of the various data groups involved has been prioritized and phased (Fig. 3). For data groups that have not yet been included, mapping of data items across databases and applications is necessary to ensure compatibility. As Fig. 3 shows, the main data groups covered during the first year of the project are topography, geology, seismic, log, and core data. In addition, some other data were included in some of the project databases on request. In this way, the SSDI team learns about points on these data groups early in the project.
PROJECT AND CORPORATE DATABA SES

The goal of the SSDI project is to address the following main activities: data integration, project and corporate databases, applications-portfolio management, data ownership, and procedures. Fig. 1 shows the data challenge, a key value driver for the initiative. The data challenge is from an in-house Shell study that suggested that technical professionals spend 60% of their time looking for data. The SSDI project team coordinates and drives the project and helps the business units implement the improvements. A companywide steering group makes key decisions with representatives from these business units and technical service groups. Fig. 2 illustrates the relationships between the project team, the steering group, and the asset teams. The activities carried out as part of the project are facilitated and supported by the project team but owned and driven by the asset teams through the steering group. This ensures that business requirements drive the tasks and priorities for the project team.
DATA INTEGRATION

At the start of the project, no single database existed that would address all the needs. Fig. 4 shows the database structure that is being implemented. It is based on a combination of Landmark's Openworks and Shell's proprietary Petroleum Engineering Integrated Environment, which includes IBM's Project Data Store. The structure with two project databases is not ideal and may lead to difficulties maintaining the integrity of data between them. The choice of this solution was driven, however, by the desire to implement fast and by the strategy to refrain from building new software packages. Project databases have been set up for most of the assets, and the first benefits are being reaped in faster turn-around time for subsurface interpretations, leading to better understanding of the subsurface and more development opportunities.
APPLIC ATIONS-PORTFOLIO MANAGEMENT

Over the years, a large number of software applications have been implemented to cater to the needs of subsurface interpretation, field-development planning, and reservoir management. Many of these have their own relational databases. In addition, several large corporate databases feed data to these applications. Data transfer and connectivity between these applications and databases have always been difficult issues because many one-to-one links exist
Copyright 1998 Society of Petroleum Engineers Original SPE manuscript received 1 January 1998. Paper (SPE 39728) originally presented at the 1998 SPE Asia Pacific Conference on Integrated Modeling for Asset Management held in Kuala Lumpur, 2324 March. This paper has not been peer reviewed.

Management of the portfolio of applications and databases improves the effectiveness of the company's investment in information technology (IT). Where decisions for purchase or development of software previously were made by different groups (e.g., exploration and development), the asset-based organization allows a companywide approach. This leads to a rationalization of the number of applications packages and eliminates overlaps between corporate databases. A selected number of applications forming the heart of the business process are tightly linked to the project databases and given maximum support level. For other applications, a lower level of linking and support is acceptable. In some cases, asset teams or business units may justify an outstep for business requirements (i.e., they may pay for and support an application for a specific purpose).
MAY 1998

54

SSDI Steering Group Five Business Units Three Technical Service Groups One Capabilities Manager One Business Unit Manager One Technical Service Group Manager

SSDI Team Six Staff

BU Resources Staff as Needed (around three to five).

Fig. 1The data challenge is to reduce the amount of time spent looking for and collating data needed for interpretive work.

DATA OWNERSHIP AND PROCEDURES

All data available in the company must have an owner who is responsible for ensuring their availability and validity. To support this, procedures must be in place to guide the approach to storage, quality control, naming, and other such factors. In the past, lack of clear ownership of data has been a key problem in data management. The majority of data types (e.g., well and production data) typically are used by many people spread over various teams and often are used by teams remote from those who generate the data. Most professionals manage only the data necessary for their own areas of interest. Also, many data items fall into more than one discipline (for example, wireline pressure data). This typically results in incomplete or missing data, data that are not updated, data without an audit trail, or simply data that are inconsistent with respect to standards and conventions. Fig. 5 shows a framework for defining data ownerships. The framework has four parties. The asset manager delegates the authority for all data management to the data-set owner. He or she distributes the responsibility for the various data groups in the asset to a number of data-value owners who are responsible for actual management of the data (i.e., ensuring completeness, quality control, storage, and adherence to standards and guidelines). These standards and guidelines for all data items are defined by data-definition owners, who are senior discipline experts. The last role is that of the database custodian. Each corporate database has one companywide database custodian to look after it. Within this framework, the intention is to clean up all data involved in the subsurface-related business process. In 1998, all data that are already available in digital form will be tackled. In the

Steering Group: Manages IT to Evolve Development Concepts Agrees on scope, budget, resources, and project for management approval. Provides technical steering and sets priorities within project scope. Makes resources available from business units and technical service groups. Regularly reviews progress. Informs management at milestones. Ensures that interfaces with other Sarawak Shell Bhd. plans, projects, and systems are addressed.

Fig. 2SSDI structure showing relationships: BU=business unit, and TS=technology services.

following years, all other data (often in reports, well files, and other such forms) will be addressed.
TRANSFER OF KNOWLEDGE

In a project where many activities and goals are being addressed for a large customer base, awareness within the asset teams and transfer of knowledge to the teams form essential activities. The project setup induces a key element in the transfer of knowledge. The manpower in the project team is too small to carry out data operations for the asset teams. The project team can only provide the structure, the tools, and the knowledge. As a result, the asset teams themselves provide a significant part of the required manpower and, in the process, learn from the SSDI team. In addition, the project team arranges for vendor training on specific packages and for general-database-related hands-on training. Technical presentations are made frequently to stimulate discussions and generate user feedback to the project team. Customer awareness has been promoted by an SSDI Web site on Shell's intranet and by an SSDI coffee mug.
FURTHER INTEGRATION

Topographic Data Seismic Data Log and Core Data Geological Data
Reservoir Engineering Data

Another initiative to improve integration of data within the company is the Surface Data Integration project, which is similar in nature to the SSDI project and targets the engineering- and operations-related areas. Management and integration of nontechnical data (finance and human resources, for example) also are targeted for improvement.

Production Data
Mechanical Well Data Economics, Cost Data
Third-Party Specialist Databases

Fig. 3Data groups progressively added to the project database shared attribute set.
MAY 1998

Fig. 4Current database structure supporting the E&P community: OW=Openworks, PDS=Project Data Store, and TIES=Tigress Import/Export System.
55

Business-Unit-Level Openworks Project Database

quality field-development planning, and recognition of more opportunities for field development and production optimization. Key factors in the success of the project to date have been the steering mechanism, providing buy-in from business-unit decision makers; the small project team, leading to transfer of knowledge to the asset teams; the integrated nature of the project, catering to exploration, development, and production requirements; and the project team's enthusiasm.
ACKNOWLEDGMENTS

Geologist, Petrophysicist Prod. Geologist for the Field

We thank Sarawak Shell Bhd. and Petronas for permission to publish this paper. We also thank our enthusiastic and supportive colleagues who helped to make this project a success.
Philip C. Lesslar is Team Leader of Subsurface Data Management for Sarawak Shell Bhd. in Miri, Sarawak, Malaysia. His technical interests are in subsurface-data integration, the man/machine interface, data-access tools, data van den Berg Lesslar mining, Web technologies, and tertiary micropaleontology. He has held various positions in micropaleontology and data management in Malaysia as well as a 3-year crossposting to Shell Intl. in The Hague, The Netherlands. Frans G. van den Berg is Manager of Production Opportunities for Sarawak Shell Bhd. in Miri. His technical interests are in reservoir characterization, subsurface-model building, field-development planning, asset management, and subsurfacedata integration. He has worked for Shell in various positions in The Netherlands, Thailand, and Malaysia. van den Berg holds MS and PhD degrees in physics from Leiden U. in The Netherlands.

Fig. 5Framework for definition of data ownerships: TDM= topographical data management, SGS=stratigraphical and geochemical services, SDE=senior discipline expert, QC=quality control, and EPT=E&P Technical Services.

In the next year, the goal is to map out and plan integration of the data used by the subsurface and surface spheres of interest and of the data that fall between these areas. Typically, such data include production data and data needed to optimize production for the system of reservoirs, wells, and surface facilities for one or more platforms.
CONCLUSIONS

With the introduction of the SSDI project, the company has taken management of its data assets seriously. The project addresses subsurface-data integration, management of the IT portfolio, and data management at a companywide level. Benefits are expected in the areas of increased productivity of technical professionals, better

58

MAY 1998