Abstract The four companies controlling the production of oil and gas in Abu Dhabi (ADNOC, ADCO, ADMA and ZADCO) are pioneering an effort to organize their wealth of exploration and production (E&P) information into one integrated system. This paper describes the business fundamentals driving the system, the original vision, the project management and the lessons learned as this project nears completion. With the Exploration and Production Information System (EXPRIS), we decided to manage the full spectrum of E&P technical data: geology, geophysics, geodetic, drilling, well and completion, core, petrophysics (logs), PVT, tests, facilities and equipment, production, injection, storage and shipments. The coverage is as wide as is diverse. The four companies have different data models, mainframes and application software. In addition to the old core database systems, there are valuable data in a multitude of "private" scattered databases such as stacks of floppy disks in engineers' drawers! Valuable information exists in non-digital form. Nomenclature and codes such as well naming convention, markers, m stratigraphy, well status and so on are different. Also, each company has a different set of applications linked to various sources of data. EXPRIS is a modern database management system backed by an integrated E&P data model based on a commercial package close to evolving industry standards. The project includes populating the model with legacy data from historical sources, making efficient loading procedures for loading new data, preparing user-friendly data access and visualization tools and connecting the integrated database to a wide range of available applications. Extensive user training and complete documentation are given full consideration. Introduction Abu Dhabi is the largest emirate in the United Arab Emirates. It is rich in oil, gas and condensate reserves. ADNOC is Abu Dhabi's national oil company and is fully owned by the government. ADCO (onshore) and ADMA and ZADCO (offshore) are the operating companies (OPCOs) which deliver about 95% of Abu Dhabi's oil production. ADNOC's share in these companies ranges from 60–88%. The remaining shares are owned by several major oil companies: BP, SHELL, TOTAL, EXXON, MOBIL, JODCO (Japan) and PARTEX (Portugal). By law, all gas reserves and production (associated and non-associated) in Abu Dhabi are owned by the government and exploited by ADNOC on behalf of the government. Figure 1 is a map of Abu Dhabi's oil companies. ADNOC needs continuous and efficient access to the OPCOs data for performance monitoring and technical and planning studies. The OPCOs kept their data on different mainframes and in various databases in digital and non-digital files. Users of main applications, such as reservoir simulators and seismic interpretation packages had their own independent powerful workstations and stand alone data files containing the data needed for these application. Access control and sharing of the vital E&P data was difficult and time consuming. Meanwhile, the E&P industry began nmoving away from mainframes to distributed client server environment using powerful PCs and workstations. Many new core applications are used by multi-disciplinary teams that require simultaneous access to project data.

Summary Software development is today steered by developers rather than by engineers as a result of sweeping changes in our industry. Though this produced higher computational efficiency and more flexible GUI's, the applications often lack the robustness, transparency and accurate description of the physics of the old programmes. The professional profile of the user also changed: the expert has been replaced by occasional users who often lack a deep knowledge of the application and of its technical background. This is not entirely matched by an increased "engineering" expertise from the vendors nor by an effort to make the programmes more transparent and the users more informed. Choosing the right software therefore requires to go through a 3 step process, the critical one being an extensive test and validation. Selected examples from the Company's portfolio of programmes are presented to demonstrate the risks of introducing software without testing. Examples of costs incurred in testing petroleum engineering software, from easy to complex applications, show that it is time consuming and expensive, mainly because it requires training of expert teams with the right mix of skills. The activity is difficult to justify when all what we do is scrutinized with a short term perspective to find areas for cost cutting. Centralizing the service in the Company headquarters is one option for containing the cost without compromising on the quality. Greater savings could possibly be achieved by insourcing back part of the software development and by setting alliances between client companies sharing the same interest. Introduction Petroleum engineers today have the option of choosing amongst several programmes developed by specialist vendors for various platforms. The days when they had to write and compile their own programmes in FORTRAN or Basic have since long gone. Significant progresses were achieved in terms of user friendliness, portability, integration and data management, all aspects that an engineer writing his own code did not, and could not, address. But what happened to the technical robustness and transparency of the old programmes? Did the vendors succeeded in providing the same level of improvement in this area as in all other IT areas ? Is the user provided with sufficient information to make the right choice and what are the screening criteria? The answers to these questions are not straightforward nor are probably unique for all users. But whereas answering the first two will mainly involve an assessment of the programmes, the answer to the third requires an understanding of the technical profile of the current users, of the work process and of the data flow on the one hand and of the expertise, aims and resources of the software developers on the other hand. All this has dramatically changed in the last two decades and even greater changes are likely to occur in the next few years. Review of the industry trends The history. Engineers in the 70's were often writing their own software to help them in their duties. More complex programmes with thousands of code lines, such as reservoir simulators, were bought and maintained by few specialized vendors. Both of them were not user friendly, were run in batch mode, required time and patience to process and display in- put/output and were installed on the Company's single platform (mainframe). Porting to other platform was not an Issue and the integration was not sought for. These programmes, though technically robust, had a limited IT content: they were basically the coding of complex algorithms. In a four quadrant plot (Fig. 1) with the engineering aspects (reliability and robustness of algorithms and code, transparency) in the y-axis and the IT aspects in the x-axis, these programmes would be described by point. The availability of more powerful and faster computers along with the diffusion of software applications led to increasing the IT content: user friendly I/O utilities, interactive applications and the need of integration made it difficult for engineers to develop programmes accepted by their peers. P. 141

Abstract The popularity of Laptop computers has dramatically increased because of their portability, low cost and increasing competitiveness with Workstations and mini-computers performance. As a result, many organizations are beginning to migrate their engineering applications to Laptop Computers. In 1994 Schlumberger Dowell started to migrate the full suite of mini-computer based CADE (Computer Aided Design and Evaluation) applications to Laptop computers. This paper chronicles the issues faced and resolved during the successful migration of the software. Introduction Over a period of 10 years, Dowell had developed 6 CADE (Computer Aided Design and Evaluation) software products, consisting of approximately 650 thousand lines of code (KLOC), which resided on VAX/VMS systems. A need was identified to quickly and economically move this software to a fast and portable computer platform. The company has made 4 major transitions since 1975 (General Electric Time Sharing to Honeywell 6000 to IBM 4341 to VAX/VMS). The last phase has lasted 10 years. The objective of this project was to migrate the CADE software to a laptop computer as quickly and economically as possible. The resulting system was required by the customer to work on a typical 1994 laptop computer configuration, i.e., a PC with a 486 - 33 MHz processor with 8 MB of RAM and less than 50 MB of free disk space. This paper describes the experiences encountered and the solutions used during the migration effort. The pre-migration status, the feasibility study prior to migration and a description of the actual development phase are covered. The section on the feasibility phase gives the details on how third party software was selected. The paper concludes with a postmortem of the project and a summary of the lessons learned. Historical Background The CADE software is a suite of computer applications for designing and evaluating the various services provided by an oilfield service pumping company. These services include hydraulic fracturing, matrix acidizing, coiled tubing, cementing and sand control. The software was developed using Ada, Fortran and C languages. About 70% (450 KLOC) of the product was developed in Ada and approximately 30% (200 KLOC) in Fortran with only a trace of C. Fortran was used exclusively for numerical calculations, while Ada was used for the Human Interface and the remainder of the numerical calculations. Ada was the predominant language because of its strong data typing, information hiding and generic template features which made the source code easy to maintain. Ada also helped to minimize the most common programming errors made using the more prevalent mainstream languages. The original CADE software was developed for use on the DEC MicroVAX II mini-computer. More than 200 of these mini-computer machines are networked together around the world using the company's worldwide network. At the introduction of the CADE software in 1985, the mini-computer offered a significant performance improvement over the previously used time sharing computing facility. The mini-computers also allowed the software to be used in remote locations where low telephone communication quality had precluded connection to the time sharing computer. User Survey. A survey of the CADE user community was conducted in late 1992 to determine user satisfaction and the direction of future development. The user response was considered excellent at 59%, with 71 of a total 120 questionnaires being returned. The survey contained questions about the user profile and specific issues regarding the various products. P. 157

Abstract In developing mission-critical, real-time applications, the authors have found historical testing methods to be inadequate for personal computers (PC's). A major problem is the myth of "PC compatibility"; i.e. the notion that all PC's are interchangeable and function independently of the software. The authors propose that the interactions between PC hardware and software are extensive and complex, and require that system specification and testing be modified to include integrated hardware/software testing. Introduction One of the primary reasons for the widespread use of the personal computer in commercial applications has been the openness of the system, allowing many competing vendors to develop hardware and software components. This competition has produced surprisingly rapid advances in computer technology and in system capabilities. However, the main goal of application developers continues to be producing applications that are usable, reliable and cost-effective, both to develop and to support. The historical approach to application development has included independently specifying and testing the hardware and software components of the system. This has proven to be inadequate for mission-critical PC applications, due in large part to the fact that modern PC's are high-performance machines containing an array of specialized components. The open architecture of the PC, compared to the previous closed (proprietary) designs, creates the situation where each of these hardware and software components can come from multiple, independent sources, resulting in a neverending stream of possible combinations. The differences between PC's and the complex interactions between the software and various hardware components requires that specification and test procedures be modified to include rigorous testing of all hardware/software combinations. In addition, due to the continuing evolution and changes in PC hardware and in software development tools, these test procedures must continue in some form throughout the product's life cycle. This paper describes the authors' experience in developing and distributing PC-based applications, emphasizing practical solutions and anticipated future improvements. Impact of the Compatibility Problem The industry relies on personal computers to provide data acquisition, increases in personal productivity, and assistance with data analysis. We are increasingly dependent on these devices and their associated software. We have all been faced with mixed emotions when upgrading our personal computers to either new operating systems, new hardware or both. We welcome the prospects of an analysis taking 20 to 50% less time and in some cases doing things not possible at all a few years ago without massive investments in workstations, mainframes and specialized training. However, will our old applications still function in a predictable manner? Will we spend weeks on the phone in non productive time in an attempt to contact a living and knowledgeable technical support staff member or be relegated to a combination of voice and fax back hell? If the personal computer industry can build a device that operates 2500 percent faster than the original IBM PC, why can't all my applications still work? Sadly, the true answer is that computers do provide the desired benefits only after a start up learning curve. The game, therefore, becomes an effort to reduce this learning curve to a minimum, searching for the quickest answer to the question "The hardware has changed again; does everything still work?". P. 129

Introduction Amoco Canada Petroleum Company Ltd. is a $4 billion corporation engaged in oil and gas exploration and production. In October 1992 the company signed a five-year "transitional outsourcing" contract valued at $70 million to $90 million with a leading outsourcing vendor Amoco Canada like many other organizations, has chosen to outsource information technology services as a way to meet the challenge of reducing costs while implementing technological changes and maintaining services at acceptable levels. Outsourcing is a growing trend as evidenced by a study done several years ago by the Yankee Group, a Boston Massachusetts based information technology consulting firm. They predicted that every Fortune 500 company would consider information systems outsourcing and 20% would outsource at least some portion of their information technology functions by 1994. Recent studies by The Gartner Group suggest that this indeed is happening. What is outsourcing? In its most basic form it is the purchase of goods or services previously provided internally and is not exclusive to information technology. Information systems outsourcing is not a new phenomenon and in fact has been around since the dawn of data processing. In addition to data processing services it has included, use of contract programmers, time sharing and purchase of packaged software. A renewed interest in information technology outsourcing stems from its changing nature. Companies are not just approaching outsourcing as a way to reduce costs, as has been the case in the past, but as a strategic tool in the management of information technology. The data centre is now just one of many functions being outsourced. More companies are including the management of local and wide area networks, desktop computer systems, applications development, and midrange computer systems in their outsourcing. P. 85^

Abstract The buzz-phrase of the 90's in the petroleum industry has become "Buy, don't Build". For an end user in an oil company, this generally means acquiring application software rather than developing it internally. For a software developer, either within an oil company or with a software vendor, the concept of "buy don't build" can apply to software toolkit components and can expedite the development of an application as well as reduce future support requirements. This paper presents several software tools and the process by which they were evaluated for use in a commercial petroleum engineering application (DeskTop VIP). It highlights the tendency in the software development process to underestimate the complexity of the development process, as well as to underestimate the value of the services provided by a software tool. Ultimately, the decision of "buy don't build" should be an economic decision. As a slogan, it reminds us that whenever one considers building or developing new software, one should also consider the possibility that buying off-the-shelf software could cost less in the long run and bring a product to completion quicker. Introduction The desire to reduce costs within the oil exploration and production industry led several companies to investigate the significant expenses related to software development costs. The overwhelming conclusion of these investigations begot a slogan for the 90's: Buy, don't Build. Taken at face value, the slogan indicates that given a choice between building or developing a software application and purchasing a similar one from a software vendor, the logical choice is to purchase the application. The basis for the slogan is not much different from another common slogan "Why reinvent the wheel?". In the past a lot of software applications and components of all different types were re-invented throughout the industry, sometimes even within the same organization. This re-invention process has often been attributed to the "not-invented-here" syndrome. Since the software had not been developed within the specific group in the organization, it was deemed to be inferior or to not exist at all. The only way to truly get the desired product was to develop or re-invent it internally. The complexity of today's software applications has reached the point where this re-invention process is very costly. P. 321^

Introduction Software licenses are the foundation for building win-win relationships between software vendors and clients. The basis for a good contract is that it is beneficial to both parties. A good foundation will cement the responsibilities and obligations of the parties after areas of agreement has been negotiated. Unfortunately, software licenses do not always reflect what is best for all. Some clauses are definitely for the benefit of the vendor while others are required by a prudent client. The resulting contract is then a matter of reasonable compromise to achieve a good business relationship. Major issues of warranty, liability, training, support, and payment may be in conflict. Topics such as maintenance, testing, patents, extent of use, and return of software are often overlooked or addressed unevenly. Application Legal counsel should always be consulted before signing a software contract. During negotiations all parties benefit from a practical working knowledge of what must be included in the agreement. An understanding of the consequences of certain legal phrases is also of value. Better understanding of the viewpoints of both vendor and client results in a better working relationship. Discussion The first item of discussion for a software client must obviously be, "What are we getting for our money?' In a legal sense we are not usually buying" a computer program. If something is "owned" then the has the full rights to do with the asset as they wish: modify it, sell it, or give it away. In the computer software industry we are usually purchasing is a license to use the computer software. If the agreement's term is limited in time we commonly refer to the license as a lease. If the term is open, we should commonly call the agreement a perpetual license. The major difference is the term of the agreement and the agreed action on termination. The important factor is that for both types of licenses the software remains the property of the vendor. Since it is the vendor's property, the client may use it only under the conditions agreed upon in the license. There is another common type of software agreement in the petroleum industry: a joint industry project where a major deliverable is software. In this type of agreement a research organization, either a private firm or a university allied organization, agrees to perform specified research under the joint funding of an industry group. All results of the research, research reports, and computer software, usually belong to the industry group. Any restrictions specified in the agreement most often deal with confidentiality. This type of agreement is different in that at the beginning of the project no assets exist. P. 331^

Abstract As most companies move to improve the effectiveness of their information systems, one of the most important goals is to ensure that corporate data is easy to access, monitor, and share. In trying to achieve this goal, petroleum companies face the challenge of managing data stored across numerous, disparate databases and accessed by independent applications. Pembina is pursuing an integration strategy to achieve greater efficiency in their management of corporate data. One project involves the retrieval of well and production information from the data source and the update of corporate reserves and land applications. Merak Projects, an engineering software vendor, and Digitech Information Services, a data vendor, are working with Pembina to automate this process. Merak's Helios program integrates diverse information systems and databases across multi-platform configurations, thereby improving data consistency and accessibility. This is Pembina's first step towards an automated, corporate wide information system which will span a variety of applications residing on UNIX and PC systems on Novell networks. Access to the most recent and reliable data will improve the quality of decisions and assist Pembina in maintaining a competitive advantage. Introduction Pembina Corporation makes use of numerous computer applications running on a variety of platforms. The sharing of common data sets between applications on different platforms is often problematic. Data sets of various applications were inconsistent and the data was often inaccurate. The objective of this project was not only to ensure consistent data across the system, but also to automate the integration for easy access and update of data. This paper discusses the process by which a common set of data was created, maintained, and made available for use by one set of applications. The applications for this project included a PC based production database, a UNIX based land system, and a third party data vendor. The challenge was to build and maintain a common data set of all wells in which Pembina has an interest. P. 343^

Abstract Field automation systems provide an enormous amount of information. In older existing systems, this information is presented to the field staff as text. Significant improvements in the staffs effectiveness and efficiency can be achieved by utilizing a Graphical User Interface. However, quantifying these improvements is a difficult task. Introduction Field automation systems have been utilized in domestic oil and gas fields since the 1960's. These systems are typically referred to as Supervisory Control And Data Acquisition (SCADA) systems. Each consists of a host computer, communications equipment, and Remote Terminal Units (RTUs). The host computer, located at the field office, collects data from RTUs, processes the data into information, and provides that information to field operators via terminals and printers. Typical data collected from the RTUs consists of pressures, temperatures, flowrates, volumes, and various physical states. The predominate mode of communications between the host computer and RTUs is via radio at 600 to 2400 baud. The RTUs, most of which are solar powered, are located at the well or facility and serve as the collection point for the various sensing devices. Systems range considerably in size and can incorporate up to several hundred RTUs. SCADA systems are an integral part of operating a field. For example, the system is used to identify possible environmental and safety problems such as spills and leaks, and has the capability to shut down a well or facility. In addition, the system is used to identify abnormally low production and off-production wells, automatically schedule and complete well tests, and control production to match delivery requirements. Finally, the system eliminates unnecessary trips to remote facilities by the field staff just to "check-it out." Unfortunately, the vast majority of users are required to interact with our company's field automation systems through a text-based, keyboard-driven interface. This results in underutilization of the systems since many users have difficulty in quickly discerning useful information from a screen or, in some cases, multiple screens of text. Vendor developed plant automation systems addressed this same limitation many years ago by utilizing a Graphical User Interface (GUI) instead of text as the primary user interface. P. 125^

Abstract Technical computing in the oil and gas industry has undergone tremendous changes during the past ten years. Applications initially developed in BASIC, spreadsheet programs, FORTRAN, etc. have advanced into multifunctional, integrated products that are portable across several platforms (various computer systems). One aspect that has not kept pace with these technological advances is support. As in other businesses, a product, service or line of business that is not properly supported will quickly falter and subsequently be dropped. Support is critical in turning a product or business line into an asset. Technical computing should be viewed in the same light. Hundreds of thousands of dollars can be spent on technical applications, hardware, training, etc. Such investments should be viewed as adding value to a company's asset base. Without clearly defined support roles and responsibilities, these investments can quickly become non-performing assets or even liabilities. Introduction Approximately ten years ago, the oil industry witnessed the emergence of personal computers (PCs) in day-to-day business operations. Overnight, columnar pads, plotting paper and map colors were replaced by a sundry of spreadsheet, word processing, graphics and desktop publishing applications. Shortly thereafter, the industry saw software vendors peddling "technical" applications (BUY VS. BUILD) at their doorsteps. Staff personnel quickly became "expert" programmers, developing multitudes of applications (BUILD VS. BUY) that performed a single task. By default, some staff members became multi-disciplinarians, augmenting their "home" disciplines by becoming applications "programmers," systems support (Help Desk), trainers, etc. Soon, they became champions of the new technology, but at a price: management expected them to maintain their "home" discipline objectives and they did not receive adequate recognition for their contributions in technical computing. Quickly, these champions decided it was in their best interests to abandon secondary activities and focus on their primary objectives. Thus, many homegrown applications faltered and support for PCs became a scarce commodity. So began the philosophical discussions about whether this new technology was an asset or a liability. This paper describes the method that was used in Mobil Exploration and Producing to: * Analyze the issue of adequate support * Generate recommendations * Implement formal, recognized support

Abstract The 1992 SPE PETROLEUM COMPUTER CONFERENCE introduced a new concept, the SOFTWARE SHOWCASE. This new program is intended to be similar to the "COMPARATIVE SOLUTIONS IN RESERVOIR SIMIULATION" project that has been a popular feature of the SPE Symposium in Reservoir Simulation for a number of years. The Program Committee chose pressure transient analysis software as the SHOWCASE topic for the initial outing. A total of four (4) problem sets were developed from actual field data-sets from CONOCO and TEXACO. Ten vendors and service companies answered the call for papers and the results of their efforts are presented in this paper. We should point out that there is no "correct" or "unique" to the four sample problems based upon the information furnished to the participants. The overall intent of this paper is NOT to present either a direct or implied endorsement of any one software product but to spur spirited discussion in the area of well testing software and to provide a service to SPE members who might be involved in the evaluation of transient pressure analysis programs. Introduction Pressure transient analysis software was chosen for the initial SOFTWARE SHOWCASE. As stated in SPE Monograph No. 5, ADVANCES IN WELL TEST ANALYSIS: "Reliable information about in-situ reservoir conditions is important in many phases of petroleum engineering. The reservoir engineer must have sufficient information about the reservoir to adequately analyze reservoir performance and predict future production under various modes of operation. The production engineer must know the condition of production and injection wells to coax the best possible performance from the reservoir. Much of the information can be obtained from pressure transient tests." The authors feel that pressure transient analysis is an integral part of both production and reservoir engineering and includes such testing methods as: drawdown buildup injectivity / fall-off interference / pulse multi-rate

Abstract The Petrotechnical Open Software Corporation (POSC), as an industry-wide consortium, is building a software integration platform, a specification of standard interfaces between technical applications that allows greater portability and inter-operability. A standard data model is a primary component of the software integration platform, providing the common vocabulary and rules for information of interest to exploration and production (E and P). This paper describes the motivation and rationale behind a standard E and P data model, describes the procedures being used in its construction, and presents several of the innovative concepts being incorporated. When released publicly in early 1993, the E and P data model will provide a much needed tool for applications developers, end users and data administrators by providing an integrated structure that bridges the currently unconnected islands of information found throughout the industry. Introduction As the E and P industry seeks to meet new challenges with every change in market conditions, the desire to improve the efficiency of the exploration and production process increases. A significant effort to improve efficiency involves the use of computer technology to leverage the ability of highly skilled professionals to produce more and better opportunities. With the advancement of specialized applications, however, has come unexpected difficulties of having to build integration bridges between isolated and sometimes contrary applications. With the current downsizing within E and P, most companies have begun to acquire more applications and data from vendors, aggravating these problems. Computing Technologies. Many computing technologies are impacting the opportunities available to E and P companies. The ongoing synergy of the E and P process is bringing together disparate information from traditionally isolated departments to either reduce the duplication of efforts or create new interpretations and ideas. Distributed databases and object-oriented data descriptions are providing new architectures for data systems that can co-operate with the organizational structure of a company rather than fight against ft. Advances in hardware and software are providing more powerful and cost effective desktops, which may be linked to faster supercomputers and larger data systems. In some cases, new industries, such as GIS, are defining new capabilities and requirements for information. These advances, however, have increased the difficulty of managing computing resources and data effectively. Data Modeling. The technique of data modeling is one tool to help E and P companies address some of these issues. Data modeling describes the basic characteristics of interesting information, which is captured in a data dictionary. First, this provides a vocabulary, consisting of terms and definitions that precisely describe the information of interest. Developing standard naming conventions and definitions are an important part of building this vocabulary. P. 47^

SPE Member Abstract The petroleum industry has reached a point where significant breakthroughs in future computer-related productivity gains are constrained by currently productivity gains are constrained by currently implemented computer systems and applications software. This paper discusses in detail the problems associated with these existing petroleum software systems, leading to specifications for enhancements and the relevant industry standards required to solve those problems. In addition, the pros and cons of a "multi-company consortium" will be weighed as the most cost-effective means of developing a true petroleum industry standard for technical computing. Introduction The current generation of petroleum software consists mostly of PC-based, stand-alone applications and their associated proprietary data bases or data files. While these software tools have, in the past, contributed greatly to the overall effectiveness of the petroleum professional, their lack of integration and interoperability greatly diminishes the potential for future gains. In order to address this situation, the next generation of petroleum software must be significantly more powerful and analytically sophisticated than current systems. It must be characterized by multi-vendor applications and database systems that reside on hardware platforms specially tuned to optimize their performance, and integrated to a degree not currently implemented anywhere in the petroleum industry. In addition, these software tools must be significantly easier to use than today's petroleum software systems. PROBLEM STATEMENT PROBLEM STATEMENT Petroleum software developers (vendors and oil companies Petroleum software developers (vendors and oil companies alike) are currently pursuing potentially divergent paths in the areas of networking and communications, user interface design, graphics standards, database architecture and data dictionary definition. The reasons are relatively straightforward: o For software vendors, there has been andcontinues to be a competitive advantage increating and maintaining proprietary solutions in the aforementioned areas of software development, especially where databases are involved. This tendency has been perpetuated by the need to protect or increase market share. o For oil company in-house software developers, there has been little or no incentive until recently to consider any sort of cooperative software development effort with other oil companies or software vendors. Many companies have issued management directives that prohibit such cooperation because of the perceived risks of "accidental" dissemination of valuable proprietary analytical algorithms to the general industry. The result is a lack of integration and interoperability in the existing generation of petroleum applications software and data management systems, which impacts the petroleum industry in a myriad of ways, both directly and petroleum industry in a myriad of ways, both directly and indirectly. The direct effect is substantially higher development and maintenance costs for a given level of software sophistication. This is attributable to the inordinate amount of effort currently devoted by each developer to user interface design, graphics standards, database architecture and data dictionary definition. P. 243

Abstract Personal computers alone cannot change the effectiveness of energy professionals. This will be achieved only through the development and implementation of useful software tools. Software developers, either internal staffs or third party vendors, must establish strategies and standards which determine the design and function of the final product. The environment in which the software operates must be compatible with the philosophy of the developer, while simultaneously addressing all of the legitimate needs of the user community. Introduction Engineering applications should be easy enough to use that training on the system is not essential for engineers to utilize them effectively. The objective should be to promote the use of advanced computer technology to its maximum potential, without requiring engineers to become computer experts. The result will be increased company value and decreased costs. This objective is usually attainable regardless of the complexity of the task. However, we must avoid the tendency to overdevelop the applications, leading to the .. one-button" solution syndrome, which is characterized by applications that over simplify the problem that they are meant to solve. This oversimplification and resulting lack of user interaction usually leads to the application's misuse, and consequently, in erroneous answers. In many instances, existing engineering applications satisfy the basic analytical needs of the engineering professional. They accept input data, calculate the results and output those results to the engineer for interpretation and analysis. Most were written before the PC was invented, utilizing input and output methods that are inadequate by current standards. These older applications usually require an extensive amount of training to use even their basic features. The more advanced capabilities are sometimes never used because they are too cumbersome and time consuming to learn. As such, these applications are not conducive to increasing productivity among the engineers using them. We therefore believe that most of these older engineering applications must either be rewritten to incorporate enhancements to the user interface, or replaced with a new generation of applications. This is the key to the substantial gains in productivity that management is seeking to justify their investments in computer technology. To investigate how this new generation of engineering applications might be developed, we will discuss several critical areas of application development methodology, analyzing how each area applies specifically to engineering applications. These areas of interest are: – Establishing a development philosophy. – User needs versus development philosophy. – The software development cycle. – Organizational approaches. – Potential problems. P. 23^

Abstract One of the primary justifications for the use of personal computers is increased productivity, to be obtained through the achievement of specific goals. The process of selecting and implementing PC software applications has a direct impact on achieving productivity gains, therefore goals must be kept clearly In mind throughout any evaluation. In order to achieve success, the goals set for productivity must be straightforward, concise and reasonable, or the process will attain only limited success, or could fail altogether. This paper outlines how a selection/implementation committee can bring order to this chaotic process. Introduction Success in selecting the best PC applications depends upon an organization's ability to coordinate among departments, recognize any relevant policy matters, interact with suppliers, analyze all information from potential vendors according to a published plan, and arrive at a solution which efficiently and effectively accomplishes its goals. The tasks involved are not clear cut, nor are they easily accomplished. Organizations may be asked to modify long standing policies and work habits. If software task forces or committees are formed to help in the selection process, they must not only deal with the issues just outlined above, but also may have to educate themselves on new topics. As a consequence, many companies do not approach this job with all the objectivity applied to other business decisions. The framework discussed here involves the formation of a selection committee and is presented to assist individuals, committees and organizations with the selection and implementation of software applications. Several reasons to consider the task force approach are as follows: – Many large companies take this approach. – Can represent diverse user needs. – Information Systems, acting alone, could make a flawed selection. Methodologies designed to quantify the productivity of PC systems are currently being studied. It has not been determined if effective productivity can be measured in a quantifiable manner for all, or even any situations (note references 6, 7 and 8). Some applications are adaptable to recognized techniques, but the remainder require subjective criteria, some of which will be presented here for discussion. ASSUMPTIONS The framework for selection and implementation of PC software will be examined. Any examples shown are intended only as an illustration of the techniques being discussed. Business decisions and contract requirements could modify the average circumstances referenced here. Basic and essential assumptions are as follows: – A large company is evaluating the software, many vendors are available and a committee has been formed to undertake the evaluation. With a smaller company and/or limited vendors, some elements in the framework could be shortened or possibly eliminated. P. 63^