Deliverable 2 and 3: Documentation of 2008 SPE Digital Energy Conference Workshop Content on JVR

Up one level to Standard Use Case Format

Up two levels to the Project Process

Summary of workshop experience: During the workshop, only two groups concentrated their discussion on the subject of JVR. Their efforts have been compiled as shown in the following sections. The groups were given an example of use case documentation by Merrick Systems (Appendix D). In order to better document the workshop content, the COT team has placed them into the format outlined in Appendix D on use case documentation.

The workshop experience showed many instances where the JVR content could be expanded and carried towards processes with no direct involvement in the end results. For example, each group’s approach has been observed to cover processes at the pumps, well tests, and even reservoir simulation data processing. Most of the members of the audience may have been exposed to forming a use case scenario for the first time. Learning use cases and their purpose may have added to the uncertainty and chaos of the thought process during the workshop. More importantly, each company/person has a different experience within the JVR process; hence, no two workflows developed in the workshop were identical. In a sense, no workflow exists in isolation from all other processes in the Operator-Partner relationship. Therefore, the workshop attendants needed to go back to the basic upstream processes before they could effectively discuss specific issues in JVR.

Lessons learned as a suggestion for future workshops of a similar nature:

  1. The tool utilized in the workshop should be very simple and straightforward for participants of the workshop to follow. Pre-screening can be performed if the use of a complex tool is absolutely necessary. Otherwise, a basic questionnaire might be sufficient to gather input from the community.
  2. Pre-screening is also suggested so that workshop participants can be ranked according to their level of expertise. This way, workshop teams can be formed around encompassing a broad range of expertise (i.e. match less experienced participants with more experienced participants) on a particular subject. This framework would create a better balance of knowledge within workshop teams.
  3. Each workshop team should be provided with specific focus points. The topic should be divided into basic concepts to guide discussions. A questionnaire can be administered to participants at the beginning of the workshop to collect specific information regarding the main theme of the workshop.
  4. Previously identified opposing viewpoints within the themes/discussion topics should be emphasized in workshop materials to guide discussions. These viewpoints could be included in the tool of choice or in the discussion points provided for each workshop team. If teams are aware of universal problems or disagreements on a subject, participants may be more interested in staying on task within their discussions.
  5. Consideration should be given to providing a knowledgeable facilitator for each team.



1. Pumpers- lease Operators
2. Maintenance/Mechanics
3. Optimization Technician
4. Production Engineer
5. POC
6. RTU
7. Automation System

Methods to Make RTO Data Available

1. EDI, XML (PRODML, WITSML), CSV, proprietary formats
2. Web services or other APIs pull data from SCADA/DCS systems or data librarians
3. Portal for online access, data loading, alarms, notifications, dashboards

Source Data for RTO Workflows

1. Monthly oil, gas, water rates
2. Revenue by well, lease, field
3. Costs by well, lease, field
4. Lease operating statements
5. Field tickets
6. Well tests – oil, gas, water rates, psi, pressure transient analysis
7. Fluid composition – PVT data
8. Reservoir simulation data
9. Petrophysical data
10. Production log data
12. Forecasted and actual targets

PURPOSE: Optimize production and reduce costs of many low volume wells.

BRIEF DESCRIPTION: Optimization should concentrate on instrumentation for the most impact. Shell uses low cost pressure meters to capture information in order to high grade a well model. Shell has successfully reduced costs and number of workovers.


• Pumper: Data collection, well status evaluation (currently, pumpers drive routes).
• Maintenance: Fix well.
• Optimization Engineer: Take results and make recommendations to optimize.
• Production Engineers: Decline analysis and data analysis.

Second Flow:
• Instrumentation: POC RTU, PLC - gather data.
• Pumper: Inspection of the Well 0 Dynographs
• Maintenance, etc. the same.




ISSUES: Security, tracking delivery, service level agreements, and contractual commitments


A partial swim lane diagram has been created based on the discussions in this group as follows. The table below depicts the tasks of each actor with no specific order in the events.

Corporate Management Daily/monthly reporting to shareholders. Asset management strategy. Production target setting.
Field/Asset Manager Monthly production planning, operational schedules, integrated activity planning. Incident reporting - HSSE production shortfalls. Responsible for overall field performance and manpower allocation.
Pumper, Field Operator Gathers oil, gas, water rates. Adjusts well chokes to maximize production. Well/asset surveillance. Production optimization. First point of entry into field data capture system.
Production Supervisor Manages pumpers and workover crews. Validation of data collected from Pumpers.
Production Engineer Responsible for well production analysis. Generates workovers, recompilations, production logs, and monthly forecasts.
Reservoir Engineer Analyzes well and reservoir performance. Analyzes and validates well tests. Moves production, reservoir, and geologic data to reservoir simulation models.
Maintenance Foreman Responsible for maintenance of surface facilities, preventive maintenance, and work orders. Reports downtime and production losses due to maintenance. Detects trends in equipment failures.
Production Accountant Responsible for revenue accounting, joint interest billing, hydrocarbon allocation. Reconciliation and balancing of production and allocation data. Allocation of volumes to wells and zones. Quality of volume. Caloric content of gas. API gravity of oil. Monthly and daily Partner Reports.
Facilities Engineer Optimizes flow of fluids through surface facilities. Flow rates, pressures, and temperatures. Scheduled maintenance interventions. Communicate changes in facilities configuration to Production Accountant to maintain allocation model.
IT Department Maintains computing infrastructure. Collects automated data. Integrates historical and transactional systems. Maintains automated reporting systems. Maintains E&P data bases, network infrastructure, email, structured/unstructured data, and SCADA/DCS systems.
Partner Asset Manager Field KPIs, AFE approvals, capital planning, and budgeting. Partner performance analysis, sales/revenues, Forecasted versus actual production and revenues. HSE incidents and fines.
Partner Reservoir Engineer Well performance analysis, reserves analysis, AFE review/approval. Field development strategy, forecasting and analysis
Partner Production Accountant Revenue accounting, joint interest billing. Collects non-operated data and enters into accounting system.



1. Operators
2. Production Engineers
3. Reservoir Engineers
4. Production Accountants
5. Partner(s)
6. Regulators
7. FDC System (aggregate of people, process, and systems)
8. Allocation System

PURPOSE: Provide data to companies and organizations that have an interest in production volumes but do not operate the wells. Pre-conditions:
• Data already in place via Field Data Capture (includes pressure, temperature, volume, and downtime)
• Report generation and delivery is not a concern



FLOW: See photos of work on flipcharts in Appendix E. A description of flipcharts (with the help of SME meeting Appendix B #28) is included here.




ISSUES: Data quality and availability are the major underlying causes for trouble in Partner reporting.

COMMENTS: Trust both internally and externally is a key factor to address.

The diagrams depicted in the photos (see Appendix E) were drawn by James Crompton. Some explanation of this group’s work has been clarified by Cheryl Dugger during the SME meetings (Appendix B-#9) and James Crompton (Appendix B-#28).

Raw measurements come from SCADA systems or some other FDC system. Engineers and accountants receive this data and perform some statistical analysis. The accounting department receives this raw data for cost allocation. Back allocation of data is where there is a need for a better work process. If there is a problem with the numbers, it should be addressed before/during the time they are sent to the finance department since they “cleanse” the numbers to suit the production requirements.

There was also discussion on data quality. It is very seldom that joint Partners receive the same data as the financial departments. The Partners would prefer to see the numbers coming straight from the SCADA systems to prevent their manipulation by the accounting department. The SCADA system captures data from RTUs (Real Time Units) and sensors, which are then put into technical data repositories (like OSI Pi system). Earlier there were limited ways to gather data, now that there are many varied methods of data capture the JV Partners would like to see the data regularly to increase the efficiency of production.


All information gathered from the workshop has been incorporated into the project in terms of providing the impetus for questions to ask in meetings with SMEs or direct incorporation with the workflow documentation as descriptors and variations of the reporting process.

Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License