i Penultimate Draft John Graham, Mesbah Khan, Chris Partridge AACE Membership Number: 26311 NORSOK Z-014: A 21st Century Update June 2015 -- 1 of 31 -- ii Table of Contents Table of Contents ............................................................................................................................. ii List of Tables ................................................................................................................................... iv List of Figures ................................................................................................................................... v Abstract ........................................................................................................................................... vi Introduction ..................................................................................................................................... 1 Background ...................................................................................................................................... 1 Cost Classifications Scope ............................................................................................................ 2 NORSOK Z-014 SCCS History ........................................................................................................ 2 NORSOK Z-014 Overview ............................................................................................................. 2 The Purpose of a Cost Classification System ................................................................................... 2 Why Classify? ............................................................................................................................... 3 What to Classify? ......................................................................................................................... 3 Who is Classifying? ....................................................................................................................... 3 How to Classify? ........................................................................................................................... 4 Roots and Entrenchment ................................................................................................................. 4 Structural Problems ..................................................................................................................... 5 Semantic Problems ...................................................................................................................... 5 Implementation ........................................................................................................................... 7 General Approach for Building a Modern Classification System ..................................................... 8 How to Modernize? ..................................................................................................................... 8 The Modernization Approach ...................................................................................................... 9 Extracting a Clearer Data Model ................................................................................................ 10 Diagnosing the issue .............................................................................................................. 11 Design Principle 1: Uniqueness .............................................................................................. 11 Simple Examples – Identifying Repetition ......................................................................... 11 Simple Examples – Eliminating Repetition ........................................................................ 12 -- 2 of 31 -- iii Design Principle 2 Minimal Divisions .................................................................................... 14 Design Principle 3: Symmetry ................................................................................................ 14 Design Principle 4: Meaningfulness ....................................................................................... 15 What Really Needs Improving ....................................................................................................... 16 How It Needs Improving ............................................................................................................ 17 A Modern Structure for a Modernized Classification System ................................................... 17 Formalization of Facet ............................................................................................................... 17 Building the Modern Classification System ................................................................................... 18 When Should Classifications Use Facets? .................................................................................. 19 How to Code the Classifications ................................................................................................ 19 Conclusion ...................................................................................................................................... 19 Appendix A – Key Concepts ........................................................................................................... 21 Facet ........................................................................................................................................... 21 System Entropy .......................................................................................................................... 21 DRY - Don’t Repeat Yourself ...................................................................................................... 21 Separation of Concerns .............................................................................................................. 21 Bibliography ................................................................................................................................... 22 -- 3 of 31 -- iv List of Tables Table 1 – Repetitions/overlaps in SAB and COR Code ..................................................................... 6 Table 2 – PBS: Drilling, Part of Topsides .......................................................................................... 7 Table 3 – PBS: Mono-hull, Sub-type of Substructure ...................................................................... 7 Table 4 – PBS: Simple Name Repetition Test ................................................................................. 11 Table 5 – PBS: Structures Examples ............................................................................................... 12 Table 6 – PBS: J-tubes Hierarchy .................................................................................................... 12 Table 7 – PBS and SAB: Onshore-Offshore Classifications............................................................. 13 Table 8 – PBS: Wells Classifications ............................................................................................... 13 Table 9 – SAB: Pipeline Operations Hierarchy ............................................................................... 15 Table 10 – Duplicate ‘Architectural Equipment’ Entries................................................................ 15 Table 11 – PBS Onshore and Offshore Process Hierarchies .......................................................... 16 Table 12 – SAB: Original versus Modernization Comparison ........................................................ 18 -- 4 of 31 -- v List of Figures Figure 1 – Three Levels of Data Architecture ................................................................................ 10 Figure 2 – Different Partitions of the Same Domain ..................................................................... 17 Figure 3 – Two Facets Shown As a Hierarchy ................................................................................ 18 Figure 4 – Modernized SAB Classification Facets .......................................................................... 18 -- 5 of 31 -- vi Abstract One reason oil and gas companies adopt a standard cost coding system is to facilitate benchmarking. NORSOK Z-014 Standard Cost Coding System (SCCS) is an example of this kind of system. This paper describes a set of issues found in a project that attempted to adopt this standard. These were issues whose analysis revealed problems with the standard’s fundamental structure. Further analysis showed that these types of problems are well-understood outside the project controls community and resolvable using a classification technique technically known as ‘facets’. The paper provides examples of these issues and indicates how they can be resolved. It also describes the systematic modernization approach adopted by the project to resolve the issues throughout the standard. The aim of this paper is to introduce to the project controls community an understanding of the importance of these issues for raising the quality of their data and the new techniques to provide improved foundations for standard cost coding systems for the oil and gas industry in the 21st Century. -- 6 of 31 -- 1 Introduction This paper describes the adoption of a standard cost coding system being undertaken by an independent upstream oil company. The work was done within a project that is part of a data foundation development program. The program aims to build a common information standard across the company’s business. One project within the program dealt with the standard for cost estimating and management systems. The program adopted a policy of building on existing standards where feasible. In the case of cost coding standards, only one standard suitable for oil and gas was found - NORSOK Standard Cost Coding System (hereafter in this paper called SCCS) [10]. However, after attempting to apply it to the current business, the Project developed reservations about the suitability of the standard in its original form. Analysis of the content and structure of the standard revealed problems in its structural foundations. Further analysis revealed this as a well-understood problem in classification – one for which there is a solution outside the project controls community. Hence, the project decided that the only practical option was to modernize the foundations of the standard, aligning it to the technological advancements of the 21st Century. This paper describes the issues with the current standard, how the Project resolved them. From the authors’ research, it was discovered that only a small number of the oil and gas owner/operators, some of whom are majors, are currently heavily committed to using elements of the SCCS standard in its existing form in various ways. This leaves a significant segment that has not yet committed to a standard and potentially will face the same problems as this project. This paper addresses this segment of the oil and gas industry with the goal of providing them with an alternate solution. This paper will first explain the background of the scope of classification for cost engineering, the history of the NORSOK SCCS. It will then expose the issues faced when developing an all-encompassing classification standard that is relevant across the industry, including the importance of classification standards for cost engineering and issues related to the type of content that is covered by the classification and the issue of multiple perspectives (i.e. the influence of the different the stakeholders are and their individual requirements). Based on these issues and requirements, it will expose some structural, semantic and implementation problems with NORSOK SCCS, that reflects its historical roots. Once these issues are highlighted, the paper will explain the approach for modernizing the classification system followed by some basic principles for developing a clear data model that can be used as a basis for the modern classification system. The paper will proceed to then outline the areas of improvement and the right tools, namely facets, that can be used to implement the data model into a useable classification system. Background This section gives a brief overview of scope of the cost classification and the history of the SCCS. It will explain the context of cost classification in an upstream oil company and the history of the NORSOK SCCS. -- 7 of 31 -- 2 Cost Classifications Scope The scope of the cost classifications within the upstream oil company, and hence the scope of the project, includes the whole hydrocarbon life cycle; from exploration through development, production operations and finally to abandonment and decommissioning for both onshore and offshore fields. A Rich Picture [1] of the project management and controls function was developed that situates the cost management discipline in context and illustrates the typical range of the various information handoffs. One of the key findings of this work was that information exchange between departments and contractors are complex and driven by multiple, often conflicting perspectives. NORSOK Z-014 SCCS History The standard clearly sets out its objectives: “The SCCS was originally developed in 1989 by the three Norwegian oil companies Norsk Hydro, Saga Petroleum and Statoil with purpose of standardisation and specification of a cost coding system. The Norwegian Petroleum Directorate (NPD) joined the work to ensure consistency between the new standard and NPD`s requirements for reporting to their INVERS database.” [p. 4, 10]. It was first published as a standard over 25 years ago, in 1989 [7]. A second edition was published in 1992 [8]. This has had two further revisions, the first published in in 2002 [9] and the second in 2012 [10]. There have been no substantial changes to the structure in the history of the standard. NORSOK Z-014 Overview The standard states that the SCCS was “designed to provide a uniform coding basis for the estimate preparation and to serve as a standard for collecting/collating historical data” [p. 4, 10]. It purports to classify costs and quantities related to exploration, development and operation of oil and gas production and processing facilities within the petroleum, petrochemical and natural gas industry. It is intended to be used by owners, operators, contractors as well as regulatory bodies. The SCCS has three key aspects, namely: physical asset, coded by the Physical Breakdown Structure (PBS); the activity, coded by the Standard Activity Breakdown (SAB); and resource, coded by the Code of Resources (COR). Hence, the SCCS is composed of three, in principle, complementary and non-overlapping sub- classifications, each one dealing with one of the aspects. This is technically known as poly-hierarchical or facetted classification system [16]. The Purpose of a Cost Classification System Before the assessment of the SCCS could commence, the project needed to develop a sufficiently clear understanding of the business’ rationale and context for classifying costs. This was understood by determining the purpose (why), the scope (what), the stakeholders (who) and the process (how) of the classification process. -- 8 of 31 -- 3 Why Classify? In the context of cost estimating and control, the classification system provides a basis for organizing cost and quantities data consistently. One of the purposes for this is to be able to compare costs across projects – to be able to benchmark and create norms for estimates. It is an information management tool that provides a framework for gathering project management data for cost control and for future reuse in estimating. What to Classify? The classification system classifies the costs and quantities for petroleum industry projects and operations. These can be quite complex. For example, a typical field development would be composed of a capital project that lasts between 5-10 years followed by routine production operations for the life of a field, which could last 20-40 years. This would involve the management of complex, globally dispersed and deep supply chains for engineering, procurement and installation operations. The complexity of the supply chain and the associated contracting strategies adopted by the oil industry create an equally complex data integration problem. Who is Classifying? A typical project will involve many stakeholders who are classifying the data. They have at least three to four tiers of contractors who will generate millions of records of cost and progress. Such data are stored and organized in different formats and organized using different classifications and levels of granularity. What is more problematic is that these stakeholders use a variety of different classification schemes, nomenclature, and terminology. The data also needs to be supplied to partners and regulatory bodies in various and who classify the data using their own requirements and perspective. Because of the multiple perspectives for the classifications, it becomes increasingly difficult for the the operator/license holder, often practically impossible, to consume and communicate, in any sensible and usable way, these large volumes of heterogeneous data generated during the life of a project or asset. This is an interoperability problem, where interoperability is the ability of systems and organizations to share data effortlessly while preserving the semantics of the underlying information [12, 13]. The interoperability requirement is not only limited to inter-organizational exchanges (for example, between partners), but also intra-organizational handoffs of data across different departments and disciplines, (e.g. between planning and cost estimating, between accounting and cost control). The challenge posed by this requirement is that each function and department within an organization will usually have legitimate reasons for organizing its data based on its own perspective/drivers/requirements. Therefore, the same activity may be coded using a variety of different classification schemes. A common cost standard that recognizes all these requirements provides one solution to this problem. SCCS aspires to be such a standard. -- 9 of 31 -- 4 How to Classify? The simplest approach to standardization in this context is to issue a classification system along with definitions that use the same structure and nomenclature for describing the objects that are covered by a particular classification. The underlying assumption is that a hierarchical list of names with associated comprehensive definitions is sufficient to meet the needs of all the parties involved in the data exchange. SCCS uses this approach. There is a very large list of classifications in the SCCS that is intended to cover every resource, equipment and activity type relevant for capital project development in the upstream oil industry. For independent oil and gas companies with limited technical engineering resources, SCCS is an attractive “shortcut” for acquiring the required infrastructure for organizing its cost data. Roots and Entrenchment As this paper attempts to show, it turned out that things were not as easy as they first seemed. When trying to implement NORSOK in the organization, many structural and semantic issues emerged. These problems emerged from the roots of the standard was a paper format which brings with it structural constraints (e.g. in terms of a single dimension for layout and organization of content). With this way of treating information influencing the approach and thinking, the standard was developed based upon the requirements of the particular organizational/regulatory/contractual/geographic context of large major operators in the Norwegian oil industry. Three decades ago, when SCCS was being formulated, computing technologies and their use in the oil and gas industry were a relatively new. Furthermore at that time, cost estimators, the main developers of the standard, typically had a background in engineering and not in information management, as such this approach led to solutions optimized for pre-computing environments. These solutions were unable to exploit fully the opportunities that computing now offers. There are several indicators of this approach that still exist in the latest version of the standard; these include using:  Using word processors as opposed to spreadsheets or databases to store and present the information.  Using narrative definitions as the sole means for explaining items in the classification, rather than a data structure  Intelligent, hierarchical codes for identifying the classifications rather than an explicit structure. This was used to both store information about the structure and as a readymade sorting mechanism for presentation layout. A major drawback of the above approach was that the developers of the standard had assumed certain organizational strategies and engineering designs and an underlying paradigm rigidly embedded these in the structure. These included: -- 10 of 31 -- 5 1) A particular set of engineering designs relevant for the Norwegian Continental Shelf leading to a fixed set of configurations of physical assets as opposed to a component based approach. 2) Contracting strategies typical for large oil majors rather than independents, e.g. the preference of majors to be more involved in the overall management and engineering supervision of EPC contracts as opposed to independents who favor turnkey contracts, with lease options for operations and maintenance. 3) An operator/owner’s perspective rather than a contractors When these organizational, engineering and technological biases were combined, it resulted in a standard strongly entrenched in its original restricted context that not only had great difficulty adapting to different geographic/contractual/organizational contexts but also contained many structural and semantic problems. Structural Problems Structurally, there were many issues including numerous repetitions, inconsistencies and fixed levels, some of which are examined in detail later. Here is a brief overview to illustrate the problem. Because the SCCS structure was a tree hierarchy, it was necessary to repeat items. For instance in the SAB, ‘installation’ appears under each type of main activity (e.g. offshore/inshore/atshore/onshore installation). It is due to the tree structure of the SAB that a choice has to be made regarding which aspect should be treated first. In the case of the SCCS, the location aspect (offshore/onshore) was chosen before the activity type (installation/construction etc.). This led to the same type of activity being repeated under each location. This is an arbitrary choice, because the same result could have been achieved by choosing activity type first and then distinguishing by location. In both cases however, the tree structure forces the design in repeat the same terms multiple times. There were numerous inconsistencies/asymmetries across different branches of the hierarchies that related to similar objects, for instance the offshore and onshore sections of the PBS had different levels of detail for process and utilities. The various sections were updated manually by the developers and they relied on manual checking to ensure consistency, this was confirmed by a number of the participants of the development of the standard. Lastly, there was the issue of fixed 'levels'. Understandably, from a human readability perspective, NORSOK appears to have restricted the levels in the hierarchy to a manageable depth (five or six at the most) and, in places, to align the same “type of things” at the same level. This prioritizing of human readability over accuracy resulted in some awkward structures. It led to extra dummy levels. For example, in the COR a duplicate level was created for architectural equipment (EA/EAA). It also led to missing levels, to flattened hierarchies. For example, the COR Y codes for Landbased Plant and Equipment. Semantic Problems Semantically, there are issues in terms of ambiguities, duplications and implicit relations in the system. -- 11 of 31 -- 6 Ambiguities There were, as often happens, a number of implicit assumptions made about what would typically fall under a particular category. In some cases, this led to ambiguities in the exact scope or meaning of codes. For example, the COR for K: Engineering Manpower is for externally contracted work because the code H: Owner’s Personnel covers internal work. So there is no explicit code for owner engineering. As a workaround, the standard suggests that the code for K: Engineering Manpower is used. One result of this is that the real costs for Owner’s Personnel are split across two codes (K and H) in a way where the overall cost is not immediately recoverable. Organizations have typically kept this information in different systems. For example, a company specific chart of accounts or project specific WBS, which erodes the value of a standard coding system that is common across the industry. Duplications As noted above, SCCS’s three hierarchies (facets) were designed by NORSOK to be disjoint (non-overlapping to avoid double counting. However, there is duplication of meaning across the three hierarchies. One reason that this happens is sometimes a single hierarchy is chosen by the users of the SCCS for presentation/layout of reports and so a requirement emerges for summarization of the data by only using a single hierarchy. One example is the use of the SAB hierarchy for management level reporting, which resulted in components of the COR hierarchy (such as Construction management, Unit Work and General) being included in the SAB– see Table 1. SAB Code SAB Name COR Code COR Name 12 Construction management CAA Construction management 23 Construction supervision HEB Construction supervision 6 Unit Work S Unit Work 7 General A General Table 1 – Repetitions/overlaps in SAB and COR Code Relationships Semantics of the breakdown relation could be either that the child was a part of the parent or a sub- type/sub-classification. For example, Drilling Area is part of Topsides, shown in Table 2. -- 12 of 31 -- 7 PBS Code PBS Name AA Topsides AAA Drilling area AAB Wellhead and riser area AAC Process and utilities AAD Living quarter AAE Helideck AAF Flare AAG Deck appurtenances AAH Deck structure Table 2 – PBS: Drilling, Part of Topsides However, monohull is a sub-type of Substructure, shown in Table 3. PBS Code PBS Name AB Substructures ABA Jacket ABB Gravity base structure – GBS ABC Jack-up ABD Compliant tower ABK Semi submersible ABL Tension leg substructure – TLP ABM Ship type substructure (monohull) ABN Barge type substructure ABP Multicolumn deep floater ABQ Single column deep floater ABR Circular barge type substructure ABS Artificial seabed Table 3 – PBS: Mono-hull, Sub-type of Substructure There is no way in the standard to distinguish between these two types of breakdown; the semantics of the breakdown relation is not made explicit. From a classification management perspective this is problematic because when a system is used to analyse the data, one has to write more complicated rules to make sure that the structure is consistent. E.g. if a data validation rule would be required to inform the computer system that for an individual facility, only one type of substructure can be used and that for its topsides more than one component part can be used, thus driving the aggregation and roll up in a different way. Implementation These structural and semantic issues led to difficulties in implementation, making the overall system and the associated data deteriorate over time. The classification was difficult to evolve because the fixed hierarchical structure of the standard prevented new items from being added in a sensible way. One particular issue was how to extend SAB for exploration, drilling and production operations. The SAB has prefixes phase codes (e.g. E for exploration), however, there was no coding for exploration or production activities (e.g. seismic -- 13 of 31 -- 8 acquisition and processing, plant maintenance, workovers). Additionally, the data collected reflected the difficulties in finding the right code and the multiple possible interpretations of the same code. It seemed that the issue was not about refinement or repair of the existing system. It was not just a matter of removing the inconsistencies and ambiguities in the meaning of a particular code or section. In fact, some issues were due to the incremental upgrades to specific parts of the classifications in response to emerging oil and gas technologies. These updates had been done to parts of the structure without considering its global impact on the consistency and semantics of the whole set of classifications and codes. All these issues seemed rooted in the original paper based paradigm of the current SCCS classification system. It was something that would not support change over time, with varying organizational/geographic/engineering contexts it would not be possible to govern the semantics without considerable effort. One indication of the standard’s paper based paradigm is that the standard was issued as a Portable Document Format (PDF), rather than a spreadsheet or database, for example. The PDF document was often printed and searched manually, which gave rise to classification errors. A number of operator organizations have exported the classifications into a spreadsheet or database. The authors collaborated with these organizations to review the results of these conversions from PDF to spreadsheets and a number of transcription errors were found. One common response to the issue of complicated hierarchies was to simplify the task by implementing a modified subset sometimes merely sections of one of the hierarchies. When the project discussed and verified this with the authors of the SCCS standard and other operators, it was discovered that every user had slightly modified or different versions of the SCCS implemented in their computer systems. This means that the SCCS standard is not really being used in its entirety or consistently across the industry. This situation presented the project with an opportunity to rethink the paradigm, because the SCCS in its current form did not meet the objectives and efficiencies expected of the standardization. General Approach for Building a Modern Classification System Given the program’s dissatisfaction with the underlying paradigm of the existing standard, it decided that a fundamental modernization approach needed to be adopted. One that would preserve the useful aspects of its content while allowing the deficient aspects of its structure to be modernized. The next section describes the decision process to modernize the existing standard. How to Modernize? There is an obvious relevance of the system entropy (see Appendix A) concept to the current state of the SCCS.. Not only has the existing classification deteriorated over time, but also new requirements, particularly in terms of digital technology (such as being able to easily implement in computer systems and analytics tools), have emerged that have not yet been adequately addressed. It was decided by the Project that in this -- 14 of 31 -- 9 case modernization would be driven by a paradigm shift; one that preserved the content of the standard, but allowed it to be viewed from perspectives of the all stakeholders involved in the industry as outlined in the Who’s Classifying section. The Modernization Approach There were three principles to the approach: 1. Salvage the investment in the existing classification – all the useful information in the original NORSOK standard classification should be migrated (e.g. the technical knowledge about the types of equipment, resources and activities), albeit in a different form, to the modernized classification. The deficient information (i.e. structural/semantic issues as identified in detail below) should, be eliminated. 2. Clearly identify the modernized foundations required for the new classification – in particular, these should fix the defective information in the original classification. 3. Use a systematic process to migrate from the original to the modernized classification. The particular systematic migration process takes account of the nature of the classification being migrated and relies upon the differences between the last two of these three broad levels of data architecture: 1. Lists – where there are no explicit links between the items. 2. Classifications– where items are organized into hierarchies 3. Data Models– where items are linked in a variety of ways. As illustrated below in Figure 1, these have increasing power and complexity. -- 15 of 31 -- 10 Figure 1 – Three Levels of Data Architecture The particular process adopted trades on the differences in power between the classification and the data model. The stages are: 1. Map the existing classification onto a clearer data model. 2. Identify the most appropriate classification over the clearer data model It is designed to take advantage of the data model’s increased power. A classification is a perspective. The data model provides an environment in which the classification’s particular perspective can be stripped away and a clearer picture built. In this way, one salvages the ‘useful’ information in the classification, and eliminates the redundant and ambiguous. Extracting a Clearer Data Model The process of extraction is governed by a number of straightforward principles. The computing world has developed memorable ways of characterizing these principles [2] [3] [15] [18]. The principles will be described in non-technical terms and then illustrated with examples. These principles are used in the data management industry for detecting and eliminating structural issues in information/classification systems; however, implementing these techniques require data architecture skills that are not commonly found within the project controls community and require cross-industry collaboration. -- 16 of 31 -- 11 Diagnosing the issue The first step is a focus on detecting issues in classification by looking for symptoms of a violation of the basic design principles. These symptoms are not errors or flaws per se, however they are “a surface indication of a deeper problem in the system [Ch3, 3]. They are "structures in the design that indicate violation of fundamental design principles and negatively impact design quality" [p. 258, 15]. Identifying and eliminating these symptoms is a good mechanism for raising design quality. Design Principle 1: Uniqueness One key principle for designing a classification is to have unique and distinct classes for every type of thing. This principle, also known as DRY (See Appendix A) is a focus on eliminating repetition and redundancy in a system. If this principle is applied successfully, then every classification should have a single, unambiguous, authoritative place within a system. One key benefit of this is that it reduces the number of classifications, and therefore the burden of maintenance. Another is that a modification of a classification should not require a change in other logically unrelated elements, additionally; elements that are logically related all change predictably and uniformly. Simple Examples – Identifying Repetition A simple rough test for breaches of the repetition principle is seeing how often a name repeats in the classification. The repetition test applied to the PBS portion of the SCCS classification shows that just under a third of the rows (239/31%) contain duplicate names. These results are illustrated in Table 4. Total items (rows) including duplicates 766 Total number of individual names (non-duplicates) 527 Total number of duplicated names (rows) 239 Number of groups with name duplicated 119 % of total items (rows) that are duplicates 31% % of individual names belonging to duplicated groups 23% Table 4 – PBS: Simple Name Repetition Test This is only a rough test because two different types of things can legitimately have exactly matching names. This is illustrated in Table 5 below. The name “structure” has two different descriptions since they are for two different types of things; a hull and seabed structure. Also, the same type of thing can have two different names. However, it is a useful guide – in this case showing the level of repetition and so the scale for improvement. -- 17 of 31 -- 12 Code Name Definition ABRA Structure “The structure (hull) consists of a cylinder shaped column. The hull is subdivided in several compartments/tanks for oil, slop, ballast, seawater, etc. …” [p. 50, 10] ADDA Structure “A seabed founded structure fabricated/constructed normally in steel, which houses and provides support and protection for subsea separation/booster/injection station equipment and systems. …” [p. 63, 10] Table 5 – PBS: Structures Examples Simple Examples – Eliminating Repetition Eliminating the repetition can be quite convoluted. However, a simple example shows how this works. J-tubes One of the repetitions identified by the simple names test was ‘J-tubes’ – as shown in Table 6 below. Code Name Code Name Code Name AB Substructures AB Substructures AB Substructures ABA Jacket ABB Gravity base structure – GBS ABD Compliant tower ABAE Risers/J-tubes and caissons ABBC Risers/J-tubes ABDF Risers/J-tubes and caissons ABAEC J-tubes ABBCC J-tubes ABDFC J-tubes Table 6 – PBS: J-tubes Hierarchy There are three entries for J-tubes in the classification; ABAEC, ABBCC and ABDFC, all have exactly the same lengthy description: “A string of steel pipe of varying diameters installed during mechanical outfitting of the jacket structure. The J-tubes extends from surface facilities vertically through guidedecks/guides to the lower jacket base area where a long radius bend extends and exits above the mudline/seabed. J- tubes form a conduit for later pull- in, pull-through of flowlines, pipelines, umbilicals and cables from subsea entry point through the J-tube to surface facilities.” [p. 26, 10] The three entries refer to the same type of thing. Looking at the hierarchy in which the entries appear, the reason they are repeated becomes clear. Within the classification, there are three types of structures in which they can be used; Jackets, Gravity Base Structures and Compliant Towers. They appear once under each of these classifications. This confuses two different aspects of the meaning, ‘what J-tubes (things) are’ with ‘where J-tubes (things) are used’. When these classifications are extracted to the data model, the two aspects are kept separate (a method known -- 18 of 31 -- 13 as separation of concerns (See Appendix A). As there is only one type of J-tube (home for the ‘what J-tubes are’ aspect), the three NORSOK classifications collapse into a single class for J-tubes. Offshore – Onshore The original classification is poly-hierarchical, divided into three separate hierarchies; SAB, PBS and COR. Some divisions are repeated across as well as within the hierarchies. This is the case with the offshore- onshore division. It appears in all three hierarchies, but for simplicity, Table 7 below only shows PBS and SAB. Type Code Name Type Code Name PBS A Offshore field installations SAB 41 Onshore construction PBS B Land based installations SAB 42 Atshore construction SAB 43 Inshore construction SAB 44 Offshore construction SAB 51 Land based operations SAB 52 Offshore operations SAB 541 Onshore drilling and completion SAB 542 Offshore drilling and completion Table 7 – PBS and SAB: Onshore-Offshore Classifications The PBS contains a single onshore-offshore division (analyzed further below). The SAB contains a number of distinct onshore-offshore divisions; linked to construction, operations, and drilling and completion. The appearance of the division across the hierarchies, suggests that a further separation can be made, this being a single division across all the hierarchies. The SAB also introduces two new sub-divisions of offshore; atshore and inshore. Offshore – Onshore Wells One interesting side effect of the top-level onshore-offshore division in the PBS is that this division propagates through the whole structure. It was found that there is no single class for wells; instead, there are separate ones for onshore and offshore wells. Note the similarity of the descriptions in Table 8 below. Code Name Descriptions AC Wells “The wells transport wellstream products (oil/gas/water/sand) from subterranean reservoirs to the mud line for subsea wells or to the wellhead area for platform drilled wells.” [p. 52, 10] BF Onshore wells “Wells hereunder are the facility that transports wellstream products (oil/gas/water/sand) from the sub-terrain reservoirs to the onshore surface for the purposes of petroleum exploration.” [p. 114, 10] Table 8 – PBS: Wells Classifications -- 19 of 31 -- 14 In this (separation of concerns) extraction strategy, no longer constrained by top level divisions, one can recognize that even though onshore or offshore wells are different in some respects, they are both wells. With this insight, the location of the well can be separated from the well itself and one can introduce a single classification of well independent of location. Design Principle 2: Minimal Divisions This principle states that a good classification should not introduce an unnecessary division that makes it unusable in certain contexts. An important part of the analysis was to test the PBS structure against actual cases. This revealed another symptom where the classification did not meet this design principle. The PBS division of offshore and land (onshore) installations, assumes that an installation is either onshore or offshore. However, the test identified installations that do not fit into this ‘neat’ structure. A test PBS for a portion of installations was constructed, where an offshore well and pipeline was connected to an onshore processing facility. In this case, the whole field installation was neither onshore nor offshore, but its components were. Analysis indicates that there is a separation between ‘what an installation is’ and ‘whether a component of the field installation is offshore or onshore’. Interestingly, one company using the SCCS chose to work around this constraint by stipulating that all installations had to be either onshore or offshore. In cases where an installation had both onshore and offshore components, they would stipulate that this was two separate but connected installations and built two separate sets of costs. This imposes a constraint upon the way companies can organize their projects. This illustrates of the lengths one may have to go to follow the current SCCS classification system. Design Principle 3: Symmetry Another important design principle is that it should have a certain level of symmetry in the structure so that it is easier to organize. As shown above, the original classification system has a substantial number of repetitions. It was noted that, where there is a repetition, a requirement to keep the repeated classifications synchronized arises. If there is not a repetition, this requirement does not exist. Where the synchronization is not made, the disorder within the classification increases. These failures of synchronization lead to visible asymmetries in the classification hierarchy. For example consider the case of ‘Pipeline Operations’ in SAB. This has two classifications, one for onshore (513: Pipeline operations) and another for offshore (524: Pipeline operations). The latter has four (4) sub-divisions, where the first has none. This is illustrated in Table 9. The difference is arbitrary and appears to have arisen solely due to a failure of synchronization between the two pipeline operations. -- 20 of 31 -- 15 Code Name Code Name 5 Operations 5 Operations 51 Land based operations 52 Offshore operations 513 Pipeline operations 524 Pipeline operations 5241 Pipelaying 5242 Tie-in 5243 Hydro testing 5244 RFO Table 9 – SAB: Pipeline Operations Hierarchy Once ‘Pipeline Operations’ is separated from their onshore-offshore distinction and the four subdivisions are applied to the ‘pure’ pipeline division, this arbitrary difference disappears. Design Principle 4: Meaningfulness One important principle is that the design should not create meaningless content to preserve an arbitrary structure. One symptom of the violation of this principle is when there are some fixed levels in a hierarchy that are more important to preserve at the cost of meaningfulness. Within the tree structure of the SCCS, items have to be situated in a particular level. For example, level one of the PBS is ‘A: Offshore field installations’ and ‘B: Land based installations’. Occasionally, the classifications are manipulated to ensure an entry appears at a particular level. One obvious example is the duplicate ‘Architectural equipment’ entries shown in Table 10. These are used to shift ‘Architectural equipment’ from level two to level three, because all the other resource categories are at the same level for the other disciplines Code Name EA Architectural equipment EAA Architectural equipment Table 10 – Duplicate ‘Architectural Equipment’ Entries There was an understandable reluctance of the designers of the classification to exceed five levels. This led to some anomalies. One example is in the PBS. This is broadly divided into ‘A - Offshore field installations’ and ‘B - Land based installations’. However, there are substantially more offshore classifications (452) than onshore classifications (213). This has led to situations where subdivisions are made in the onshore division but left out of the offshore, as there are not enough levels. One apparent example of this is Process, which has no subdivisions under offshore, but two levels of subdivisions (with 18 classifications) under onshore as shown in Table 11. This is clearly a deliberate choice, as some of the land based detailed classifications are mentioned in the descriptions of the offshore classifications. -- 21 of 31 -- 16 Code Name Code Name A Offshore field installations B Land based installations AA Topsides AAC Process and utilities AACA Process BK Process – hydro carbons – gas/oil BKA Process – pretreatment and separation BKAA Receiving facilities BKAB Pretreatment facilities BKAC Separation facilities BKB Process – LPG/NGL BKBA Fractionation BKBB Product treatment BKC Process – crude refining BKCA Crude distillation BKCB Coking BKCC Visbreaking BKCD Fluid catalytic cracking BKCE Hydrocracking BKCF Hydrotreating BKCG Catalytic reforming BKCH Isomerisation BKCI Alkylation BKCJ MTBE (methyl tertiary butyl ether) Table 11 – PBS Onshore and Offshore Process Hierarchies When these aspects are separated in the data model, there is only a single process classification with the full sub-hierarchy. This means that a single process list would be available for use on both offshore and onshore facilities. Although currently some of these processes are not used for offshore facilities, there is in principle no reason why they should not be e.g. Floating LNG or GTL. If or when they are used, the single process breakdown offers a futureproofed classification. What Really Needs Improving The gaps between the original classifications and the modernized model were examined to identify the areas where the original classification system had issues. The majority of the gaps arose from repetitions and had the same underlying cause. This was the use of a simple tree hierarchy, which forced separate independent attributes to be made dependent and so repeated. One obvious example of this is the top level PBS onshore- offshore divide discussed earlier. Once a divide has been made in a simple tree structure, all the independent classifications have to fit underneath and so become dependent upon it and repeated. This indicates a clear requirement for a classification structure that does not create these artificial dependencies. -- 22 of 31 -- 17 How It Needs Improving The modernized model provides a basis for refining this general requirement, by identifying the independent attributes that need to be kept independent. This provided a reasonably specific statement of the requirements. A Modern Structure for a Modernized Classification System A decision was made to adopt the only reasonably well established classification mechanism for handling the requirement for classifying a number of independent attributes – the facet (See Appendix A). Formalization of Facet The underlying structure of facets revealed in the modernized model is quite rich. To provide a sufficiently strong structure it turned out useful to formalize the facets using the mathematical notion of a partition (i.e. a disjoint and complete division of the population). as shown in Figure 2 and Figure 3. Figure 2 – Different Partitions of the Same Domain -- 23 of 31 -- 18 Figure 3 – Two Facets Shown As a Hierarchy There are a significant number of implicit facets in the SCCS in addition to the three explicit ones. Figure 4 shows the facets within a modernized SAB. Figure 4 – Modernized SAB Classification Facets Building the Modern Classification System The proper extraction of the original classifications to a data model produces a clearer structure. The data model is capable of supporting this process because of its superior power. In this case, the extraction was largely driven by eliminating all the identified repetition and separating the identified aspects. The modernized model provides a foundation for a modernized classification system in two ways.  Firstly, it has methods for identifying where the original classification system needs to be improved.  Secondly, it provides a foundation for building the modernized classification system. This modernization results in a simpler (fewer classifications), richer (more distinctions) structure. The work done on SAB provides an illustration, shown in Table 12. Classifications Distinctions Original SAB ~150 ~150 Modernized SAB ~100 >100,000 Improvement ~1/3 reduction > x600 Table 12 – SAB: Original versus Modernization Comparison Note that in the original SAB, classifications correspond to distinctions. Whereas, in the modernized SAB, classifications are ways of making distinctions, so classifications can be combined to make further distinctions. It was clear early on that the modernization was more an information management exercise than a cost engineering exercise. This illustrates the need for introducing information management expertise into cost -- 24 of 31 -- 19 engineering discipline when working and using classification systems. It is important to understand the root cause for the current state of art in the cost classification and coding system is that it was developed by cost engineering professionals with sufficient use of information management concepts and tools. Therefore it is important to bring these two communities together to work on the problem jointly. During the building of the modernized classification, a number of issues arose. Two interesting representative issues are described below. When Should Classifications Use Facets? Facets solve a particular problem. Where the domain of a classification system has a variety of independent aspects, then facets are a good solution. But independence comes in degrees, some aspects could be dependent and others independent. In this case, the dependencies need to be managed, resources need to be introduced to handle them [17]. How to Code the Classifications The second ‘C’ in SCCS stands for ‘Coding’. The coding provides identifiers for the classifications. In a tree hierarchy there is a simple way to set up codes, where a child classification is prefixed by its parent classification. For example, the code ‘AB’ contains the code ‘A’ of its parent. This is known as a lexicographical classification. This is the way the codes are set up in the three SCCS hierarchies. This needs extending for facets, where a classification can have multiple parents. Even though the SCCS has facets, it offers no guidance on how to make this extension. In practice, within the company people tend to concatenate the three codes in an agreed order with an agreed delimiter (e.g. A/1/K for PBS/SAB/COR) – this is called a colexicographical ordering. In the modernized classification, a number of different possible codings were presented. It is currently an open question which one(s) will be adopted. Conclusion This paper has described a set of issues found in a project that attempted to adopt the SCCS standard. It described the issues the project found and the problems with the standard’s fundamental structure. It has shown how these can be resolved using a classification technique technically known as ‘facets’ - and how the standard has already adopted a simple example of this technique to resolve a similar problem by using the three facets of SAB, COR and PBS. It has noted that that these types of problems are well-understood outside the project controls community, but less well-understood inside the community – and how this implies a requirement for the community to improve its understanding. To aid this, it has provided a simple introductory description of facets. It has described a modernization approach (one adopted by the project) that can be used to resolve the issues throughout the standard. A key feature of the approach was the use of a systematic process. The first stage of the modernization process built a data model. This clearly identified the shortcomings in the original standard and showed how adopting facets would avoid these in the -- 25 of 31 -- 20 modernized classification. The second stage built the facetted classification system, based upon a formalized notion of a facet. It is hoped that the introduction to the project controls community of an understanding of these issues and the new techniques will lead to improved foundations for standard cost coding systems for the oil and gas industry. -- 26 of 31 -- 21 Appendix A – Key Concepts Facet The term ‘facet’ was coined by the Indian librarian S. R. Ranganathan and first used in his Colon Classification [14] in the early 1930s. However, the idea was not (as Ranganathan freely admitted) new. It probably had its roots in Dewey's device of place (location) as using a standard number, a device now known as a facet indicator (see the Introduction to [16] for more details). System Entropy This tendency of information systems to deteriorate over time is well recognized in many industries. In the software industry, the deterioration of software systems is a major problem. As a software system is modified and new requirements emerge, typically its disorder, or entropy, increases [pp. 69–70, 5]. Thomas Kuhn [6] describes the deterioration as part of a natural process of the evolution of theories. One that inevitably leads to a revolution that modernizes the domain. One of his key insights was that these revolutions did not add new data but developed a more explanatory and elegant theory about the existing data. He described this as seeing the same underlying information in a new way, or with a new ‘paradigm' – hence the term ‘paradigm shift’ – and used optical illusions that can be seen from two perspectives[11]. The lesson here is that effective modernisation can be achieved by shifting the paradigm rather than modifying or adding to the existing content – or rebuilding from scratch. DRY - Don’t Repeat Yourself This is an acronym for 'Don’t Repeat Yourself'. The DRY principle is closely related to another principle – Single Source of Truth (SSoT) – in that if the DRY this principle is applied successfully, and then every classification should have a single, unambiguous, authoritative place within a system. Separation of Concerns The idea is very old, but the phrase ‘separation of concerns’ was probably coined within computing by Edsger Dijkstra [2]. The basic idea is to treat independent aspects independently, and so avoid creating unnecessary dependencies. This simplifies the development and maintenance of the classification. “When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.” [18] -- 27 of 31 -- 22 Bibliography No. Description 1 Avison, D. E., Golder, P. A., Shah, H. U. 1992 Towards an SSM Toolkit: Rich Picture Diagramming Page(s) 397–408 European Journal of Information Systems. 1 Palgrave Macmillan 2 Dijkstra, E. W. 1982 On the Role of Scientific Thought Selected Writings on Computing: A Personal Perspective Page(s) 60-66 Springer-Verlag 3 Fowler, M., Beck, K., Brant, J., Opdyke, W., Roberts, D. 1999 Refactoring: Improving the Design of Existing Code Addison-Wesley Longman, Inc., Massachusetts 4 Gotze, J., Jensen-Waud, A. 2013 Chapter by Mesbah Kahn, Embedding Systemic Thinking into Enterprise Architecture Beyond Alignment: Applying Systems Thinking in Architecting Enterprises. College Publications 5 Jacobson, I., Christerson, M., Jonsson, P., Övergaard, G. 1992 Object-Oriented Software Engineering: A Use Case Driven Approach Addison-Wesley, New York -- 28 of 31 -- 23 6 Kuhn, T. S. 1970 The Structure of Scientific Revolutions University of Chicago Press, Chicago 7 Norsk Sokkels Konkuranseposisjon 1989 NORSOK Standard Z-014, Standard Cost Coding System (SCCS) 1st Edition, 1989 Standard Norge, Lysaker 8 Norsk Sokkels Konkuranseposisjon 1992 NORSOK Standard Z-014, Standard Cost Coding System (SCCS) 2nd Edition, May 1992 Standard Norge, Lysaker 9 Norsk Sokkels Konkuranseposisjon 2002 NORSOK Standard Z-014, Standard Cost Coding System (SCCS) 2nd Edition, Revision 1, Oct 2002 Standard Norge, Lysaker 10 Norsk Sokkels Konkuranseposisjon 2012 NORSOK Standard Z-014, Standard Cost Coding System (SCCS) 2nd Edition, Revision 2, May 2012 Standard Norge, Lysaker 11 Partridge, C. 1996 Business Objects: Re-Engineering for Re-Use -- 29 of 31 -- 24 First Edition Butterworth Heinemann, Oxford 12 Partridge, C. 2002 LADSEB-CNR - Technical report 05/02 - The role of Ontology in Integrating Semantically Heterogeneous Databases The BORO Program, LADSEB CNR, Italy, Padova 13 Partridge, C. 2002 The Role of Ontology in Semantic Integration Second International Workshop on Semantics of Enterprise Integration at OOPSLA 2002 Seattle 14 Ranganathan, S. R. 1933 Colon Classification First Edition Madras Library Association, Madras 15 Suryanarayana, G., Samarthyam, G., Sharma, T. 2014 Refactoring for Software Design Smells: Managing Technical Debt First Edition Morgan Kaufmann, MA, USA 16 Taylor, A. G. 2006 Introduction to Cataloging and Classification 10th Edition Library and Information Science Text Series Libraries Unlimited, Westport, Connecticut - London -- 30 of 31 -- 25 17 Tzitzikas, Y., Analyti, A., Spyratos, N., Constantopoulos, P. 2007 An Algebra for Specifying Valid Compound Terms in Faceted Taxonomies Data and Knowledge Engineering. 62(1) Page(s) 1-40 -- 31 of 31 -- (OWN-2007) NORSOK Z-014 A 21 st Century Update John Graham Mesbah Khan Chris Partridge Please use microphone for all questions and comments! 2 Contents Slide Bios Introduction What is NORSOK Z-014 ? What is a Facet? Example Classification System Modernisation Modernisation Design Principles Identifying and Eliminating Repetition Identify and Eliminate Unnecessary Division Eliminate Meaningless Content Identifying Asymmetry and Exposing Symmetry Modernised SAB: An Example Summary and Conclusion Introduction Background Project is to build a cost classification system. Only standard found was NORSOK Z-014 - Standard Cost Coding System (he