The Preliminary Specification Part XXVI (AV Part IV)
Today I want to talk about the domain of the Joint Operating Committee. It is clear in the discussion of the Accounting Voucher that we are concerned about capturing and recording the business of the Joint Operating Committee. And clearing the costs and revenues of the property to the producers. What the Draft Specification talks about is Transaction Design which deals with the optimal location for a transaction to occur. The firm or the marketplace.
So much of what the Accounting Voucher aspires to do is to remove the user from the mundane aspects of dealing with transactions. With Information Technologies (IT) that are available today this is not only possible, but a competitive necessity. For instance you can buy an App for a phone that will take a picture of a receipt and code it to an accounting application. This is what I did in 1977 as my first job in oil and gas. The point of the Draft Specification is that users should be designing transactions as the key to building business value. This aspiration is what is so poorly discussed in the Draft Specification, but when your knee deep in papers, that’s the way the world looks.
Designing transactions, more or less from the point of view as to where the transaction will be conducted, in the firm or in the market, is part of the point of the exercise. What and How are two of the traditional questions of how to get things done. Now we need to answer the question, “where” will the transaction occur, and that is answered in the Accounting Voucher. The research and science on TCE that is referenced in the Draft Specification points to a means of determining where the transaction should occur. And that is what are called “thin crossing points”. However the first determination is the assessment of the capabilities of the group that is being assessed for the work that needs to be done. There is of course no sense in trying to determine the thinnest crossing points as the determining factor of who gets the deal.
It may seem intuitive to reduce the point of the transaction between two firms down to the thinnest point being the transfer of the invoice from one firm to the other. And that would score high on an exam but it would fail in terms of implementation of what the possibilities of Transaction Cost Economics could achieve. What if there were a system development, like People, Ideas & Objects Preliminary Specification, that was user community based that included the service industry as part of that user community? Would that provide an opportunity to define some service industry level systems integration that would be complementary to the Accounting Voucher of the People, Ideas & Objects application? Why couldn’t the service industry provider have their people populated into the Work Order system that we discussed earlier? Or, if the user community deemed that a Purchase Order system was worthwhile that this could also be used as means of direct communication between the producers represented in the Joint Operating Committee in the Accounting Voucher and the service industry providers.
There may ultimately be the thinnest of crossing points for the transaction being the invoice that crosses from the vendor to the joint account. Ultimately making the transaction the most efficient from the organizational point of view. However, with the use of IT we can also build on the information that is known and unknown in all of the producers and all the vendors that are party within a “transaction”.
What may not be clear is the need to design the transaction to ensure the business value is realized by the Joint Operating Committee. There is a general rule that whatever operation your conducting in the field, it is generally going to be conducted based on the understanding of the least experienced individual that is present in the field. It just seems to happen that way. Designing the transaction with these constraints in mind can help to mitigate the unknown factors from causing problems down the road. Also, because most of the “transactions” that occur in the marketplace are of such a large size, building of a compressor, building of a gathering system, drilling a well. The ability to apply further scientific strategic “game theory” type attributes in to the People, Ideas & Objects software is possible.
For the industry to successfully provide for the consumers energy demands, it’s necessary to build the systems that identify and support the Joint Operating Committee. Building the Preliminary Specification is the focus of People, Ideas & Objects. Producers are encouraged to contact me in order to support our Revenue Model and begin their participation in these communities. Those individuals that are interested in joining People, Ideas & Objects can join me here and begin building the software necessary for the successful and innovative oil and gas industry.