|
|
|||||||||||||||||||||||||||||||
contents:
|
User Case DescriptionWhilst the real proof of the BOF's applicability will come from Geco's user case, it will be difficult with this alone to illustrate the concept to those not familiar with the seismic business. The following is a description of the user case requirements going into the project.1 The seismic acquisition business processThe marine seismic acquisition process is a complex business process involving many sub-processes and stakeholders. The various stakeholders in the marine acquisition process has different goals. This is illustrated in the figure below (see fig. 1 below). The primary goal is to deliver quality seismic images to our clients. The key process to achieve this is the seismic data refinement process from raw measurements to a seismic cube. This is illustrated in fig. 2. In this area improved interoperability between our systems would give functional differentiation.Figure 1 Stakeholders in the MSA business process.
Figure 2 The overall seismic data workflow.
Another key process is the management of the acquisition process itself. Here we talk about tools helping in improving operational efficiency and control, and thereby give us differentiation on cost. Figure 3 describes the acquisition process seen from an operational management point of view. Figure 3 The marine seismic acquisition business process.
In the first phase of the user-case demonstrator, we will focus on the operational business process and tools/ products that assist management to control and improve the operation efficiency. The first prototype will concentrate on vessel activity monitoring and reporting, including equipment performance. Later we will also add tools for monitoring the data quality (seismic and position data). This will be very challenging because of the big data volume. 2 Defining and Understanding Area of ConcernThe first prototype will focus on the production planning, reporting and monitoring of the marine seismic acquisition process. Production planning, reporting and monitoring is a very general business process and should be a good case for defining requirements to a BOF.What is special in our case is that the various sites (vessels) are not always online available. This makes our case also a variation of "the travelling business man" business pattern. Figure 4 illustrates the distribution aspect of our case. Since all the vessels are in continuous operations all over the world, this requires high up-time on the system. The figure also illustrates the security problem we have by also bringing the client into the system. The security issues must be handled. The system must also be able to differentiate the access rights and views based on the various users roles. Goals: The overall goal is to make the production planning and monitoring processes more automatic, efficient and user friendly. It will be important to integrate the different Vessels and the systems that are used today. Produced information should be available for different actors both on shore and off shore. The information should be presented in a convenient form. Different actors are interested in different information and different kinds of presentation styles. Figure 4. The vessel network.
The business model for the planning, reporting and monitoring system is shown in figure 5. Here we can see the various activities and roles participating in this process. The use case is identified by studying the transactions the various roles have with the system. The parent business model is shown in fig. 3, and indicates the relationship to the vessel schedule and the workorder process. Figure 5. The various activities and roles in the production planning, reporting and monitoring system.
SEL, June 11, 1999 |
