TOTAL COST OF OWNERSHIP AT THE GRONINGEN GAS FIELD: AN ASSET MANAGEMENT INVESTMENT DECISION MAKING TOOL
by
J.M. KAMPHUIS
University of Groningen Faculty of Economics and Business and Newcastle University Business School
Msc Dual Degree Technology and Operations Management and Operations and Supply Chain Management
December 2014
First supervisor dr. Jasper Veldman, University of Groningen Second supervisor dr. Jingxin Dong, Newcastle University Organisation Nederlandse Aardolie Maatschappij
Abstract
Table of content
Abstract ... 2 List of Tables ... 6 List of Figures ... 6 Acknowledgement ... 7 1. Introduction ... 8 1.1 NAM... 81.2 NAM Asset Groningen... 9
1.3 The business problem ... 10
2. Literature background ... 11
2.1 TCO in general ... 11
2.2 TCO as part of ALCM ... 12
3. Methodology ... 15 3.1 Introduction ... 15 3.2 Problem investigation ... 15 3.3 Solution design ... 17 3.4 Design validation... 18 3.5 Implementation... 19 3.6 Data collection... 19
4. Problem investigation: What is the problem? ... 20
4.1 Who are the stakeholders, their goals and corresponding requirements and ... wishes? ... 20
4.1.1 Stakeholders and their goals ... 20
4.1.2 Requirements ... 22
4.1.3 Wishes ... 29
4.2 What are the difficulties in reaching the requirements and wishes when implementing a TCO decision making tool?... 30
4.2.1 Requirements ... 30
4.2.2 Wishes ... 31
5. Solution design: Which solution is designed? ... 36
5.1 Which TCO decision making tools are available? ... 36
5.2 Can existing TCO decision making tools be assembled to build new solutions? ... 39
5.3 Which steps are taken to design a solution? ... 40
5.3.1 Additional building blocks ... 43
5.3.2 Steps taken in the design process ... 45
6. Design validation: Is the design valid? ... 53
6.1 Internal validity: Would this design, implemented in this problem context, satisfy the criteria identified in the problem investigation? ... 53
6.1.1 Causal question: In problem domain D, would solution S have effects E? ... 53
6.1.2 Value question: Do effects E satisfy stakeholder criteria C? ... 55
6.2 Trade-offs: How would slightly different designs, implemented in this context, satisfy the criteria? ... 61
6.3 External validity: Would this design, implemented in slightly different contexts, ... also satisfy the criteria? Is the solution generalizable? ... 62
7. Implementation: How can this solution be implemented? ... 63
8. Discussion ... 64
8.1 Discussion of contribution to literature ... 64
8.2 Discussion of practical contribution ... 65
8.3 Limitations and recommendations ... 68
9. Conclusion ... 71
References ... 72
Appendices ... 74
Appendix A – Interview guide ... 74
Appendix B – Communication plan additional to tool ... 76
Appendix C – Findings visit NedTrain ... 83
Appendix D – Email conversation Amsterdam Airport Schiphol... 85
Confidential Appendices ... 88
Confidential Appendix A – Operational Excellence Blade 20 – Total Cost of Ownership . 88 Confidential Appendix B – Transcripts of the Interviews ... 88
Confidential Appendix C – Email conversations about TCO in 2012 ... 88
List of Tables
Table 4-1: Paired comparison of wishes ... 32
Table 4-2: Hierarchy of wishes after paired comparison ... 33
Table 4-3: Interdependencies between requirements ... 33
Table 5-1: TCO tools in Shell ... 38
Table 5-2: Satisfying of requirements by the found tools ... 40
Table 6-1: List of wishes and reasoning behind satisfying ... 59
Table 8-1: Expected increase on Blade 20 TCO assessment ... 66
Table 8-2: Wishes unsatisfied by the tool ... 69
List of Figures
Figure 2-1: Life cycle phases of process asset systems ... 12Figure 2-2: ALCM model for the process industry ... 13
Figure 2-3: Life cycle cost categories ... 13
Figure 3-1: Methodology ... 16
Figure 4-1: ORP with focus area for Modification process ... 24
Figure 4-2: Roles of participants in project development ... 25
Figure 4-3: Accuracy of cost estimating in each Project phase ... 25
Figure 5-1: Screenshot of Tool 5: CMCP Group Template TCO model ... 41
Figure 5-2: Top row of template ... 45
Figure 5-3: Room for entering the Potential Cost Avoidance ... 46
Figure 5-4: Design for a single option in designed TCO decision making tool ... 48
Figure 5-5: Example of chart for a single option ... 50
Acknowledgement
One of the reasons to decide upon studying the Dual Award Operations Management, consisting of the MSc Technology and Operations Management at the Faculty of Economics and Business of the University of Groningen and the MSc Operations and Supply Chain Management of the Newcastle University Business School, was the broad possibility for a tailored master’s thesis. After several introducing meetings, I have decided on writing my master’s thesis at NAM Asset Groningen. My period at NAM started after finishing my research proposal in July 2014. Due to the open atmosphere and the interest every employee at NAM had towards my research subject, made that I have the feeling that I could really develop something not only interesting from an academic point of view, but is also supportive for the employees I’ve worked with for several months.
To start with, I would really like to thank all employees of NAM Asset Groningen for making time available when I asked for it. Due to this opportunity I really have the feeling that I’ve come to know the employees and the business. In special, I would like to thank the Delivery Engineering team and the Cost Engineers. But most of all, I own thanks to my supervisor, Sander van Minnen, the Business support manager, for involving me in the processes and for giving me the opportunities, support and feedback I needed.
Next to the employees of NAM, I also want to express my thanks to the supervision from the universities. To start with I want to express my respect to my first supervisor dr. Jasper Veldman. Although he was struggling with his own activities, he was always available for me and open for a good discussion about my research and academia in general. Next to that, I’ve had support from my second supervisor dr. Jingxin Dong from the Newcastle University and the opportunity to discuss several matters with dr. ir. Wilfred Alsem, a former NAM employee and now a lecturer at the University of Groningen. The insights given by these three academics really added to the value of this report.
Lastly, I would like to thank my family and friends. Their support, mentally and financially, really kept me going when I was doubtful how to continue. I own finishing these two masters to them.
1. Introduction
Total Cost of Ownership (TCO) was introduced as a life cycle approach for asset management investment decisions in the early 1990s (Ferrin and Plank, 2002). In literature, some has been written about the application of TCO in practice. Ferrin and Plank (2002) have discussed that there is a need for a general model of TCO. However, Korpi and Ala-Risku (2008) state that Life Cycle Costing (LCC) methods are very case-specific and that there is a need for tailored methods.
The Dutch oil and gas company NAM (in Dutch: Nederlandse Aardolie Maatschappij) would like to apply TCO to its operations. In this master thesis, the application of TCO in practice will be investigated. This will result in a tool that will assist NAM in making more optimal investment decisions over the life cycle of an asset in the Groningen gas field.
This master thesis is written for two reasons, to contribute to practice and to contribute to theory. The contribution to practice is to assist NAM in applying TCO to its asset management investment decision making. The contribution to theory is to fill a gap between theory and practice in order to provide the academic world with more input in the discussion. NAM and its business problem will first be discussed. In chapter 2 a literature background is given.
1.1 NAM
1.2 NAM Asset Groningen
The Asset Groningen of NAM is handling the gas production of the Groningen gas field and the two underground gas storages in Grijpskerk and Norg (Langelo). The surface area of the Groningen field is 900 km2 and the annual production is capped by the minister of economic affairs on 42.5 billion m3 gas for 2014. This volume is produced by approximately 300 wells, across 20 production sites. NAM anticipates producing gas from the Groningen field for at least 50 more years. The underground gas storages were set up in the mid-1990s to facilitate as a buffer for the peak demand for gas in the winter period. The capacity of the Groningen field can thus be transferred from summer to winter period, allowing the Groningen field to have a lower maximum daily production capacity and still be able to meet peak demand. Next to that, there are the RBI and a tank park in Delfzijl, and the Well Resevoir & Facility management. The RBI (in Dutch: Rest Bewerkings Installatie) is a location where side products of the produced gas is processed. These side products can be stored and prepared for transport at the tank park, or used for other purposes.
Three relevant departments of Asset Groningen can be distinguished. The maintenance department of NAM Asset Groningen, also called Engineering and Maintenance (E&M), is responsible for the planning and control of all maintenance activities that have to be performed to all production facilities, the underground gas storages and some additional smaller installations in the Groningen field that facilitate the production of gas, such as pipelines, flashovers, etc. This is done parallel to a projects department, which is responsible for all new facilities and major modifications to existing facilities. A third important department in the Asset Groningen is the operations department, concerned with the daily delivery of gas to GasTerra via the pipelines of GasUnie, as specified in the Gas Building (in Dutch: Gasgebouw).
1.3 The business problem
There are several reasons for NAM Asset Groningen’s desire to incorporate TCO into its daily practice. The first reason is that TCO is used in the tender process when selecting a contractor for a long term period. Yet, not much is done with TCO in the day to day business with this contractor. Secondly, every five year period each asset within Shell gets assessed on the so-called Operational Excellence, which is a set of bundles of theories of which TCO is a part. This will be explained in chapter 2. The score of the latest assessment of TCO in 2011 was too low, and because the assessment questions have changed since, the current score is expected to be even lower. Thirdly, the maintenance and operations departments have little influence on what equipment the projects department hands over. Several employees within the operations and maintenance department think that TCO can function as leverage. Fourthly, a newly developed method was introduced within the maintenance department for the technical discipline engineers. This method is used to specify the work that GLT-PLUS has to perform for NAM and in this process TCO is expected to enable more optimal investment decision making. Lastly, the Business support manager has recently been made responsible for TCO within the maintenance department and therefore is in search of a suitable manner to research the possibility of applying TCO to the daily practice of NAM Asset Groningen.
From the interviews held with different stakeholders of the above mentioned issues, as will be discussed in chapter 4, it becomes evident that these stakeholders desire rigorous research into the applicability of TCO.
2. Literature background
This section concerns the background of Total Cost of Ownership in academic literature. TCO will be discussed in general, and as part of asset life cycle management (ALCM). As a conclusion the identified gap will be presented as well as the contribution to theory.
2.1 TCO in general
TCO was first introduced in the early 1990s by Ellram as a purchasing tool and philosophy (Ellram, 1995; Ferrin and Plank, 2002). Applying TCO requires that a buying firm determines which costs it considers most important or significant in the acquisition, possession, use and subsequent disposition of a good or asset or service (Ellram, 1995). Companies formerly only applied a “price only” focus. TCO, on the contrary, emphasizes on all costs that arise in the life cycle of an asset (Degraeve and Roodhooft, 1999). The costs that occur in the life cycle of an asset are called life cycle cost (LCC). Knowledge of the LCC put the purchase price of an asset into perspective and shows how much it actually costs the organization to use, maintain and dispose of the asset during its lifetime. TCO can be seen as the approach to take LCC into account. This will be elaborated upon later on in section 2.2. TCO may include, next to the purchasing price, all other sorts of costs, depending on what a user of TCO regards relevant. Consequently, no standard approach is present. Subsequently, the TCO models that are used in practice vary widely by company, and may even differ within companies (Hurkens, Van der Valk and Wynstra, 2006). TCO is considered to be very complex, which limits its widespread standardised adoption. One of the reasons might be the lack of readily available accounting and costing data. Next to that, the change towards more TCO focused operations has been very slow (Ellram, 1995). An explanation for this slow change is that TCO adoption may require cultural change, from a price orientation towards total cost understanding.
As this research is done at NAM Asset Groningen, the TCO approach used complies with how Shell has defined TCO in Operational Excellence – Blade 20 TCO, as described below. This is a monetary-based method, which allocates the costs of purchasing an offering (good or service) to the different cost components (Hurkens et al., 2006). The method used in NAM Asset Groningen to allocate all costs will be explained in chapter 4. This is a method that can be considered an Activity Based Costing method as mentioned by Hurkens et al. (2006), because the costs are allocated to the different cost components based on true costs.
2.2 TCO as part of ALCM
Asset management in this research will be defined as a strategic, integrated set of comprehensive processes to gain greatest lifetime effectiveness, utilization and return from physical assets. To gain even greater value, the asset management process should extend from design, procurement and installation through operations, maintenance and retirement, i.e. over the complete life cycle (Schuman and Brent, 2005). These life cycle phases can be seen in Figure 2-1: Life cycle phases of process asset systems. The management of an asset during its life cycle is called asset life cycle management (ALCM).
Figure 2-1: Life cycle phases of process asset systems
Source: Blanchard & Fabrycky (1998)
Given above are merely the life cycle phases in ALCM. Schuman and Brent (2005) have given a more detailed overview of an ALCM model in the process industry, the business in which NAM Asset Groningen operates. The model can be found in Figure 2-2: ALCM model
for the process industry. Figure 2-2 shows a lot of similarity with the model used in Shell to
Figure 2-2: ALCM model for the process industry
Source: Schuman and Brent (2005)
TCO can be seen as a part of ALCM, similar to life cycle costing methods (Schuman and Brent, 2005). Life cycle costing (LCC) is often used for economic analysis of total costs that occur during the life of an asset. It incorporates all direct costs plus indirect costs, variable costs and costs associated with the procurement, operations, support and disposal of the system (Ferrin and Plank, 2002). TCO, using the phraseology of Ellram (1995), consists of all elements of LCC, with the addition of fixed and linked costs. This can for instance be pre-transaction costs, pre-transaction costs of procurement and post-pre-transaction elements during the life cycle. Different life cycle cost categories are presented in Figure 2-3: Life cycle cost
categories.
Figure 2-3: Life cycle cost categories
A more precise content of LCC is given by Korpi and Ala-Risku (2008), who state that LCC focusses more on operations and maintenance costs, and consists of (a) Affordability studies; (b) Source selections studies; (c) Design trade-offs, (d) Repair level analysis; (e) Warranty and repair costs, and; (f) Suppliers sales strategies.
As can be concluded, literature has no clear distinction between TCO and LCC. In Operational Excellence – Blade 20 TCO the following definitions are used: “The total cost of ownership of an item of material takes into account all the costs of acquisition, personnel, training, operation, maintenance, modification and disposal, and is used for the purpose of making decisions on new or changed requirements and as a control mechanism in service, for existing and future items. Life cycle costs are defined as the cumulative and combined costs of having and operating equipment for the life of an asset. LCC is sometimes referred to as “cradle to grave” or “womb to tomb” costs. LCC allows an analysis of business function interrelationships, e.g. low development costs may lead to high maintenance or customer service costs in the future; therefore, the LCC gives a balanced view of all costs to allow fairer analysis and comparisons for future project.” See Confidential Appendix A – Operational Excellence Blade 20 – Total Cost of Ownership. So, Blade 20 within Shell identifies the difference between TCO and LCC as the decision making aspect. As this thesis’ subject is asset management decision making, to apply to existing items (= maintenance) when requirements are new or changed, this thesis will speak of TCO. Moreover, this is also due to the argument of Ellram (1995) who thinks of TCO as the broader definition when compared to LCC.
3. Methodology
As described above, NAM has the feeling that TCO can contribute to its practice. Besides that, there is a gap in literature that can be filled by describing how TCO can be applied in practice. This empirical research will follow an academic methodology, in order to assure that this research does not only add to practice, but by using consistent and validated techniques also adds to theory. The purpose of the methodology section is to structure a design science research that investigates the applicability of TCO to the practice of NAM.
3.1 Introduction
The goal of this methodology section is to describe how this research is performed. The purpose of research is to acquire knowledge critically. The research question is formulated in close corporation with NAM. This research will answer the following research question:
How can the maintenance department of NAM Asset Groningen apply Total Cost of Ownership to improve their Asset Management investment decision making?
Presenting an answer to the research question will be attained by rationally structuring the research according to the regulative cycle as introduced by Van Strien (1997). This regulative cycle, as modified by Wieringa (2009), consists of four steps: (1) Problem investigation; (2) Solution design; (3) Solution validation, and; (4) Implementation. Each step has its own sub research question and is discussed within a chapter of this thesis. A detailed figure of these steps can be seen in Figure 3-1: Methodology and the methodology of all steps are elaborated upon in the corresponding paragraphs. Important to note is that although in the figure the process seems sequential, it actually is an iterative process, in which some steps forward lead to adjusting one or more steps already taken.
3.2 Problem investigation
Figure 3-1: Methodology
Chapter 4: Problem investigation: What is the problem?
Design problem
Stakeholders Goals Requirements and wishes Diagnosis / Analysis Hierarchical ordering of wishes Interdependencies of requirements and wishes Research Question + Conceptual Framework
Chapter 5: Solution design: Which solution is designed?
Chapter 6: Design validation: Is the design valid?
Solution design Which solutions are available? Can existing solutions be assembled?
Which steps are taken to design a solution? Difficulties resolving requirements Solution development (modeling) Internal validity: Requirements satisfied? Trade-offs External validity
Chapter 7: Implementation: How can this solution be implemented?
Causal question Value question Sensitivity Different context Generalization
The following step is the diagnosis/analysis, where the possible causes of the difficulties of resolving the requirements are identified. All requirements have to be met; however the wishes are optional as long as they don’t compromise the requirements. An order in which the wishes have to be treated to derive to a possible working solution is identified. All requirements and wishes are maintained throughout the entire research. The problem investigation is complete when the stakeholders, their requirements and wishes are known and analysed. This is done by answering the following questions:
Chapter 4: Problem investigation: What is the problem?
4.1 Who are the stakeholders, their goals and corresponding requirements and wishes?
4.2 What are the difficulties in reaching the requirements and wishes when implementing a TCO decision making tool?
4.3 What are the interdependencies of the requirements and wishes in the TCO decision making tool?
These questions will be answered in Chapter 4. The next paragraph looks into the methodology of the solution design.
3.3 Solution design
Following the reasoning and terminology of Wieringa (2009), in this section how the solution is designed will be explained. The design of a solution can be seen as a plan in which the means for an end is laid down. The solution design is finalised when all stakeholder goals are completed. The means to reach this end is the designed solution, which may consist of all kinds of things (e.g. new or improved technique, algorithm, process, etc.) to reach the desired stakeholder goals. The plan to reach the end of the solution design is always specified to some extent, for communication purposes. The form is which specification occurs can differ and is not a description of the world or an explanation. This is because the specified solution does not exist yet. Rather, the specification is the expression of a possible commitment to act in a certain way (Wieringa, 2009).
The process of deriving to a possible satisfying solution is a process in which choices are made. This can yield different solutions. The choices made are described in Chapter 5, by answering the following questions:
Chapter 5: Solution design: Which solution is designed? 5.1 Which TCO decision making tools are available?
5.2 Can existing TCO decision making tools be assembled to build new solutions? 5.3 Which steps are taken to design a solution?
In the next stage, the designed solution is validated in order to solve the problem best.
3.4 Design validation
According to Wieringa (2009), for the validation the following knowledge question needs to be answered: Is the design valid? To answer this question, a division is made into several sub questions:
Chapter 6: Design validation: Is the design valid?
6.1 Internal validity: Would this design, implemented in this problem context, satisfy the criteria identified in the problem investigation? This contains two sub-questions:
6.1.1 Causal question: In problem domain D, would solution S have effects E? 6.1.2 Value question: Do effects E satisfy stakeholder criteria C?
6.2 Trade-offs: How would slightly different designs, implemented in this context, satisfy the criteria? To answer this question a sensitivity analysis can be performed.
6.3 External validity: Would this design, implemented in slightly different contexts, also satisfy the criteria? Is the solution generalizable?
3.5 Implementation
The implementation of a solution depends highly on the solution itself (Wieringa, 2009). The implementation is successful when the designed and validated tool is implemented to the practice of NAM. The question asked in this chapter therefore is:
Chapter 7: Implementation: How can this solution be implemented?
3.6 Data collection
The data for this research is collected in different ways. First, general theory is collected through literature search. This is presented in the literature background, but is also part of the following steps in the research process. Further, introducing interviews are held to get a better understanding of the problem and the context in which this research is performed. The researcher found it useful to conduct more interviews for data collection; around fifty semi-structured interviews are conducted additional to the introducing interviews. Interview guides are made beforehand; an example of an interview guide can be found in Appendix A – Interview guide. The Wiki of Shell contains lots of information; this is consulted for additional data. Meetings with supervisors, from NAM and both involved universities are another source of data. Observations of the researcher are a source of data that is also used. The data analysis method depends on the collection method. For the literature search and the data collected from the Wiki of Shell conceptual analysis followed. Interviews are analysed in a qualitative manner, reports of relevant findings in the interviews are presented, after which conclusions are drawn. Relevant observations of the researcher and outcomes of the meetings with supervisors are reported and incorporated in the research.
4. Problem investigation: What is the problem?
As described in the methodology section, the problem investigation has to answer the question what the problem is. This is done by structurally answering the following questions: Chapter 4: Problem investigation: What is the problem?
4.1 Who are the stakeholders, their goals and corresponding requirements and wishes?
4.2 What are the difficulties in reaching the requirements and wishes when implementing a TCO decision making tool?
4.3 What are the interdependencies of the requirements and wishes in the TCO decision making tool?
4.1 Who are the stakeholders, their goals and corresponding requirements and wishes?
This chapter will first discuss the stakeholders and their goals, then the requirements and afterwards the wishes.
4.1.1 Stakeholders and their goals
From NAM side:
Maintenance Manager, the head of the Engineering and Maintenance department Maintenance Delivery engineering team, a team of 8 employees
Business Support team, a team of 16 including a cost controller and cost estimator Rotating discipline team, a team of 5 engineers
Mechanical static discipline team, a team of 4 engineers Civil discipline team, a team of 6 engineers
Electrical discipline team, a team of 4 engineers
Process engineering discipline team, a team of 7 engineers
PACO (process automation, control and optimization) discipline team, a team of 6 engineers
Reliability and maintenance engineering team, a team of 16 engineers including field support team and integrity engineering
Operations Manager Projects Manager
Joint Tender Board, on the cutting edge of NAM and GLT-PLUS, with three NAM representatives and three GLT-PLUS representatives
From GLT-PLUS side: Engineering manager Business support manager
At the NAM side of business, all stakeholders except the Operations Manager, the Projects Manager and the Joint Tender Board, report directly or indirectly to the Maintenance Manager. Primary goal for NAM is to produce gas in a safe, sustainable and cost efficient matter. For the maintenance department, the integrity of the Asset Groningen is of the highest importance.
During the phase in which the interviews were held, the researcher was invited to attend a decision gate meeting in which decisions were made about which modification projects to execute in what manner. This meeting is the formal meeting about the specification process for the work GLT-PLUS has to execute, mentioned in the business problem as one of the reasons this research is performed. In this meeting, the researcher received confirmation about the direction of the assignment. The solution has to be implemented in this process. This decision about the direction of the research is validated by the Maintenance Manager, the Operations Manager, and all other attendants of the meeting. Other attendants of this meeting are representatives of the Maintenance Delivery team and the six different discipline teams.
The Engineering manager of GLT-PLUS is a stakeholder because his engineers will be working with a possible other or adjusted way of working. The goal of GLT-PLUS is to be key to enable NAM Asset Groningen to fulfil its role and deliver its targets without failure, with a healthy return for GLT-PLUS in reward for this business contribution. GLT-PLUS thus adjusts its way of working to NAM’s. Good communication is important, so when NAM’s way of working changes, this should be communicated with the involved departments of GLT-PLUS. The head of the department involved is the Engineering manager. Next to that, also the Business support manager is identified as stakeholder. As described, TCO analyses rely highly on the availability of data and the Business support manager of GLT-PLUS is responsible for the data management systems.
During the interviews, a lot of empirical data was gathered about the relevance of TCO for both theory and practice. This will be elaborated on in the discussion. Now the stakeholders are discussed, the next step is to go into their requirements.
4.1.2 Requirements
After answering who the stakeholders and their goals are, the following part of question 4.1 is to answer what the corresponding requirements and wishes are. The requirements are discussed first; the wishes will follow in the following section.
1. Keep the tool simple.
i) It has to be fool proof and prescriptive.
ii) The tool must not be too demanding for people who have to work with it. 2. Make the solution compatible with the current organization.
i) Implementation in current Maintenance Modification process ii) Implementation in EOM (Extra-ordinary Maintenance) process
iii) Follow the Operational Excellence – Blade 20 TCO as close as possible
iv) Data: Currently we do not have the right data of old projects to do a TCO analysis. For future projects this has to be done with this solution.
v) Communication plan additional to the tool with background information both on TCO as an explanation of the tool itself.
3. Entire life cycle of project that is proposed will be reviewed. 4. Reasonable reliability of cost estimates.
5. Clear list of assumptions under which the tool is constructed. i) Boundaries when to use the model have to be determined.
These requirements will now be discussed in detail, in order to give a good explanation of them and to be able to discuss possible trade-offs.
1. Keep the tool simple
The first requirement is to keep the solution simple. By making the solution fool proof and prescriptive, the intention is that is assured that due to the large amount of stakeholders the solution will be used similarly by all people who have to work with it. Next to that, the solution must also not be too demanding due to limited resources.
2. Make the solution compatible with the current organization
Secondly the solution has to be compatible with the current organization. There are two processes in which the solution has to be implemented. As already discussed, the solution will have to be applied to the modification process.
2 i) Implementation in current Maintenance Modification process
The delivery engineer for modifications is the chair of bi-weekly meetings and has to assure that the needed documents for this meeting are present. These documents, for which a template is made, are to be written by the concerned discipline engineer. Often these projects are multi-disciplinary; then the most involved discipline engineer has the lead. The document that is written evolves through the decision gates from DG1 to DG3 and results in a Basis for Design, a BFD. In this BFD the project is functionally described. In Decision gate 1, an opportunity or a problem is identified. In Decision gate 2, different concepts for this opportunity or problem are presented, of which one is picked for a more thorough evaluation. In Decision gate 3, the optimal concept is confirmed. After DG3 this document is handed over to the contractor GLT-PLUS to do the detailed design for the corresponding project. This is pictured in Figure 4-1: ORP with focus area for Modification process. Focus areas for TCO are decision gates 2 and 3, indicated in the figure with ovals. As described in the literature background, TCO has to be thought of early in the life cycle of a project because in early phases decisions have the largest influence on cost.
Figure 4-1: ORP with focus area for Modification process
Source: Shell Opportunity Realisation Standards – Guidance July 2013
Figure 4-2: Roles of participants in project development
Source: ISO 15663-3:2001(E)
In the Identify phase of the ORP, a very rough cost estimate is given for what it costs to do nothing about an identified problem. In the Assess phase, a cost estimate Level 1 with accuracy of +40%/-25% is given for at least two different options to solve the identified problem. In the select phase, a cost estimate Level 2 with accuracy +25%/-15% is given for the selected option. This can be seen in Figure 4-3: Accuracy of cost estimating in each
Project phase. All estimates have a 50% confidence level, which means that there is an equal
chance that the costs of the project will show an over or under expenditure. In statistical terms, this is usually referenced to as “P50 estimate” (standard normal distribution) and means that the estimate given is the median of range of possible final expenditure outcomes.
Figure 4-3: Accuracy of cost estimating in each Project phase
The define and execute phases are outsourced to the contractor GLT-PLUS, to be specific to the Engineering department for the detailed design. The resulting requisition has to be approved by NAM. The discussed process here is the modification process. There is another process having place in the maintenance department, which is called the extra-ordinary maintenance process. This will now be discussed.
2 ii) Implementation in EOM process
The second place where the TCO-solution will have to be implemented is the EOM (extra-ordinary maintenance) process. A maintenance project becomes an EOM when its project cost is estimated above a certain amount, usually €50,000. At this moment, no life cycle costs are taken into account. A second possibility for a maintenance project becoming an EOM is when additional attention is required. EOMs are usually large preventive maintenance activities. A modification extents the current functionality of the installed base and is mostly undertaken pro-actively by a discipline engineer. An EOM, on the contrary, is an already scheduled preventive maintenance activity of which the detailed scope has not been determined yet. When a project is characterized as an EOM, a dedicated employee is to monitor these projects. This is the delivery engineer for EOMs. Approximately there are 70 EOMs annually, and a few more modifications (~90). Together these two categories determine more than half of the maintenance budget, while they concern less than 15% of the work orders. Where there is a whole process for a modification to follow, this is not the case for an EOM. In most cases, an EOM is the replacement of an expensive piece of equipment, or anticipating on equipment becoming obsolete. There is no need for a heavy process such as the ORP to determine which option should be selected, because the equipment will not drastically change. However a similar method considering TCO is required for EOMs to monitor the total cost.
2 iii) Follow the Operational Excellence – Blade 20 TCO as close as possible
2 iv) Data availability
An important aspect mentioned above in the TCO-blade is data availability. From several interviews it came forward that in 2012 there was another research about TCO in the Asset Groningen, in reaction to the low score on Blade 20 in 2011. This research has focussed on the data availability and how historic data could be used for future TCO decision making. This research has not yielded a satisfying result, due to several reasons. The reasons will now be discussed. Transcripts of the interviews concerning this subject can be found in Confidential Appendix B – Transcripts of the Interviews as support for these statements. Firstly, the data that is used for budgeting and cost control is not functionally arranged for TCO analysis. Budgeting and cost control is comparable with the internal accounting department, reporting to the finance lead of NAM Asset Groningen. This function is responsible for controlling all costs made by the maintenance department. These costs are allocated to eight general locations, and are not specified on equipment level. When seeing it as a tree, the locations to allocate costs to are the trunk and the eight heaviest branches, while for TCO analysis even the smallest twigs and leaves are needed. Refer back to the left side of
Figure 4-2 and think of the eight functional locations as locations high in the field level of
Due to this lack of structure in entering data in SAP Bleuprint, the data that is present is not useful for TCO analyses. Recently a decision is made by the Maintenance Manager not to change anything about this, because for budgeting and cost control the data is available. Conclusion is that no efforts are taken to improve the availability of historic data for TCO analyses. The requirement is that data should be made available for future projects.
2 v) Communication plan additional to the tool
A last sub requirement to make the solution compatible within the current organization is to create a suitable communication plan, for example by adding a slide pack with information about TCO and the tool itself to it.
3. Entire life cycle of project that is proposed will be reviewed.
The third requirement is that the entire life cycle of the project will be reviewed. As the disposal cost is a part of the TCO, this has to be included in the analyses. As for different projects or different equipment the life cycle is different, also the time span to look at will be adaptable in the solution. Currently in the organization a horizon of 5 years is used, so applying TCO will be a major change to the current way of working and thinking.
4. Reasonable reliability of cost estimates.
The fourth requirement is a reasonable reliability of the cost estimates. As explained by the first requirement, TCO analyses can become very complex. Not incorporating all data one can think off, makes a model less trustworthy. So, there is a trade-off here. The requirement is set to at least work with an estimate accuracy of +25%/-15%. This requirement is set to make the solution resemble reality, but not to get stuck in too much detail. When spoken of a reasonable reliability an estimating accuracy of +25%/-15% is meant. As can be seen in
Figure 4-3 this is the level that is used for economic analyses.
5. Clear list of assumptions under which the tool is constructed.
4.1.3 Wishes
Now that the requirements are discussed, the wishes are listed. This is an extensive list; these wishes will not be discussed in detail:
1. NAM Engineering & Maintenance department would like to have more grip on GLT-PLUS’ decisions.
2. The discipline engineers of NAM Engineering & Maintenance department would like to be more involved in the decision making process after Decision gate 3.
3. Control loops: several control loops could be installed if these are not already there and actual audits have to take place.
a. A control loop to check whether the scope of a project is delivered within time and under budget and where possible changes come from.
b. A control loop, additional to above mentioned, to check whether the cost estimate was a good indication, and if future estimates have to be adapted.
c. A control loop by colleagues (or different functions) to give feedback on the documents for the different process steps.
4. All stakeholders would like to have something in place to improve communication between NAM departments.
a. The NAM employees of the Joint Tender Board would like to be earlier involved in the Modification process, with respect to for instance equipment with significantly long lead times (e.g. > 9 months).
b. The cost estimator of the projects department (who has to make an estimate for the Capital expenditure [Capex]) has no insight in Operational expenditure (Opex): the estimate for Opex budgets could be based on service masters from the maintenance department. There could be more communication between these two cost estimators. c. The hand over from projects to operations as described in the Operational Excellence
Blade 20 could be better. It would be nice if a possible solution can change this.
d. Approval from Management Team (Asset Manager) can be asked after a satisfying prototype solution.
5. NAM Engineering & Maintenance would like maintainability to become a stronger part of the concept select phase.
7. NAM Engineering & Maintenance would like spare parts policy to become a stronger part of the concept select phase.
8. The Operational Excellence Blade 20 would like to see that somebody is made responsible for TCO (and thus TCO-data). With responsibility come also the duties and the powers (authority).
9. What gets measured gets done: there could be a TCO trend line for comparison and visibility on a regular basis, quarterly or yearly.
An answer to the sub research question “Who are the stakeholders, their goals and
corresponding requirements and wishes?” has been presented above. The next step is to
discuss difficulties in reaching the requirements and wishes.
4.2 What are the difficulties in reaching the requirements and wishes when implementing a TCO decision making tool?
First the difficulties in reaching the requirements will be discussed; the wishes will follow after the requirements.
4.2.1 Requirements
As the requirements have to be satisfied, it is no option to overlook the difficulties. Any difficulty not mitigated, will make a possible solution unsatisfying. These difficulties will have to be monitored thoroughly when opting for a possible solution.
1. Keep the tool simple
This may seem rather straightforward, but this will be hard to accomplish. Research in literature and within Shell has resulted in some TCO models that are used elsewhere. These models tend to be rather complex, due to the large number of life cycle costs that are taken into account (Degraeve and Roodhooft, 1999). Being prescriptive and making the tool fool proof will make sure that working with the tool will not be too difficult.
2. Make the solution compatible with the current organization.
For Blade 20, see Confidential Appendix A – Operational Excellence Blade 20 – Total Cost of Ownership. Difficulties especially rise where the current organization is complex and different opinions about the way of working are present. A possible solution will have some difficulties with overcoming this complexity. A good measure to overcome this is already mentioned by providing a communication plan additional to the solution to inform stakeholders about the identified difficulties and give insight in the manner to overcome these. An example of a difficulty that can arise when implementing a TCO tool is that it can be used in different manners. This can be prevented by making the communication plan that is added to the tool crystal clear, so that the tool will be used in the way it is supposed to.
3. Entire life cycle of project that is proposed will be reviewed.
To satisfy this requirement, a lot of data is needed. This will yield some difficulties, because some data is not available and will have to be estimated. Furthermore, it will be hard to find data that should be known because of the structuring of data in NAM. It will also yield some difficulties to communicate which life cycle is meant, for instance the economic, technical or actual life cycle. Next to that, when a project is multidisciplinary not all pieces of equipment will have a similar life cycle so then the project life cycle will be leading.
4. Reasonable reliability of cost estimates.
As explained, this is already in line with the current practice; biggest addition is that life cycle costs are taken into account. If cost estimators are instructed properly on their future tasks and responsibilities, then this might not become really difficult. A sensitivity analysis can be executed to prove that the solution is reliable. This might yield some difficulties, because this has to be done for several scenarios. Additional data will be needed.
5. Clear list of assumptions under which the tool is constructed.
This list of assumptions, as already mentioned, is a prerequisite. Difficulties are that some assumptions might be contradictory, this has to be explained and trade-offs will have to be discussed. It is merely a matter of keeping track.
4.2.2 Wishes
Not all wishes can be implemented in a viable solution without harming one of the requirements or other wishes. To overcome this difficulty, the wishes are compared to each other following paired comparison analysis (David, 1963). This is a method that compares every wish individually to every other wish, and a preference of one over the other must be given. This results in a prioritization of the wishes, so that the more important wishes are implemented when a trade-off prevents both wishes from being implemented. This method, paired comparison analysis, is used preliminary in cases when the objects, in this case the wishes, can be judged only subjectively (David, 1963).
In discussion with the Business support manager, all wishes were compared. This can be seen in Table 4-1: Paired comparison of wishes. A positive score in the table means that the wish on the left hand side is preferred over the wish on the top row of the table. For wish 3 and wish 4, the sub-wishes share one point together, in order not to give them too much weight. The resulting scores are summed in the last column of the table by the following method: the sum of the vertical scores is subtracted from the sum of the horizontal scores. For example for wish 4, this means that the result is: (0.25+0.25+0.25+0.25+1-1+1+1+1) – (-1-1-1-0.33-0.33-0.33) = 8.
From Table 4-1 it can be concluded that there is a hierarchy available for incorporating the wishes in a possible solution. After a satisfying solution is found for the requirements, these wishes will be dealt with in this hierarchical manner. If a wish violates a requirement or a higher ranked wish, then this wish will be disregarded. The hierarchy can be seen in Table
4-2: Hierarchy of wishes after paired comparison. This is the sequence in which the wishes
will be dealt with when all requirements are met.
Table 4-2: Hierarchy of wishes after paired comparison
# Wish 6 4 5 1 4c 4b 4a 3a 3b 8 3c 4d 2 3 7 9
Score 10 8 6 5 2,75 2,25 0,75 0,33 -0,33 -3 -3 -4,25 -5 -5 -5,50 -9
Now that the difficulties in reaching the requirements and the hierarchical order of the wishes are discussed, the next step is to discuss the interdependencies.
4.3 What are interdependencies of the requirements and wishes in the TCO decision making tool?
Now that the requirements and wishes are discussed, the interdependencies will be analysed to show the complexity of designing a useful solution. The interdependencies between the requirements will first be discussed. In Table 4-3: Interdependencies between requirements an overview of the identified interdependencies is given by colouring the box yellow and indicate with “yes”. These will be discussed by starting with the first; discuss the most important interdependencies with the other requirements and then proceeding to the next.
Table 4-3: Interdependencies between requirements
1 2 3 4 5
1 Yes Yes Yes Yes
2 Yes Yes
3 Yes
4 Yes
1. Keep the tool simple
The first requirement has overlap with all other requirements, because to keep the tool simple implies that every requirement or wish added compromises the simplicity of the tool. This conflicts especially with reasonable reliability, the fourth requirement. Building a model means that reality is displayed in a simple matter and that certain levels of detail are left aside. So the trade-off here is the simpler the tool is made, the less reliable it becomes. Next to the reliability, the compatibility with the current organization is interdependent of the simplicity. The organization of NAM Asset Groningen itself is rather complex. On top of that, there is the contractor GLT-PLUS that consists of four different companies, with the accompanying struggles of the partner-companies. As can be seen in chapter 4, there are a lot of stakeholders identified. This can have a major effect on the simplicity.
2. Make the tool compatible with the current organization
The second interdependency is that the solution has to be compatible with the current organization, while currently not much is done with TCO at all. This is best featured in the third requirement, which compels that the entire life cycle of a project has to be reviewed. This goes against the current organization, because this is not daily practice at the moment. However, if NAM Asset Groningen wants to implement TCO to their decision making process, then the current way of working has to change. How impactful this change is, depends on the solution. The third requirement thus means that the second requirement will not be followed where life cycle cost are taken into account: this is where the organization will have to change due to applying TCO to its daily practice, depending on the impact.
3. Entire life cycle of project that is proposed will be reviewed
Currently, the entire life cycle of equipment is not taken into account. When implementing this, it will probably take the organization some time to adapt to that new situation. This means that especially the first period the TCO decision making tool will be used the cost estimates will not satisfy the reliability of a cost estimate Level 2 as it is currently used.
4. Reasonable reliability of cost estimates
5. Clear list of assumptions under which the tool is constructed
The fifth requirement is influencing all other requirements as well, but as described this is more a matter of keeping track. Strict boundaries will increase the simplicity, when these boundaries are realistic this will also increase reliability. A realistic boundary is to assume the cost estimating process as a given process, but there will be more boundaries identified that are interdependent of other requirements. This is described accordingly in chapter 6, the validation.
Next to the requirements amongst themselves, there are also interdependencies with the wishes. Some are pretty straightforward; others are only on a deeper level. These interdependencies will come to play when a preliminary solution is designed in which the requirements are satisfied and the hierarchical list of wishes becomes subject of discussion. This is also the place where these interdependencies will be addressed.
With this extensive discussion of the requirements and wishes, preceded by the stakeholders and their goals, the problem of NAM Asset Groningen is analysed. An answer to the question
“What is the problem?” is given with this chapter. It is clear that there is a complex problem,
5. Solution design: Which solution is designed?
This chapter will explain how a solution for the problem is designed. This is done by answering the following sub questions:
5.1 Which TCO decision making tools are available?
5.2 Can existing TCO decision making tools be assembled to build new solutions? 5.3 Which steps are taken to design a solution?
By answering these questions, eventually the path towards the designed solution is explained, different options are elaborated on and the choices made are discussed. First, an overview of already available TCO decision making tools is given.
5.1 Which TCO decision making tools are available?
This paragraph will give an overview of available TCO decision making tools. There are three sources identified: literature, other companies and Shell. Not all found alternatives will be given, only the alternatives that satisfy some or most requirements.
TCO decision making tools in literature
As described in the literature background, there are no standard TCO models identified. This is due to the fact that a user of a TCO model can incorporate every aspect he finds relevant to the calculation. This makes that TCO models used vary widely by company, and even within companies (Hurkens et al., 2006). Aspects of TCO that should be included in the tool are mentioned in the literature background. Some resemble requirements listed in the previous chapter, such as the life cycle of a project and the assumptions under which the tool is made. These are taken into account in the process of designing a solution; however no specific TCO decision making tool from literature is adapted to form a basis for the design of a TCO decision making tool at NAM.
TCO decision making tools in other companies
The second company investigated is NedTrain. Within NedTrain, several academic initiatives have already been deployed (see for instance Parada Puig, Basten and Van Dongen, 2013). These initiatives have not focused, however, on improving the cost efficiency of the maintenance services (as the TCO tool in this thesis does), but on key decision made by maintenance organizations during initial fielding of new equipment (Parada Puig et al., 2013). NedTrain has a dedicated department, called RAMSHE-LCC (Reliability, Availability, Maintainability, Safety, Health, Environment and Life Cycle Cost), which is amongst others responsible for LCC and thus TCO. This department is only involved in the bigger projects, such as conversion activities. See Appendix C – Findings visit NedTrain for a report of the visit to NedTrain. The organizational structure at NedTrain can be compared to the situation within NAM Asset Groningen, where there is a dedicated projects department for the bigger projects. The sheets used within the RAMSHE-LCC department of NedTrain are not suited to be applied to the E&M department of NAM Asset Groningen.
A third company was not visited, though via email the required information was received. This company is Amsterdam Airport Schiphol, where a master thesis research about TCO was conducted in 2013 (Puijn, 2013). In this thesis an “Asset Life Cycle Management system” is developed, consisting of a methodology selection process and a process redesign. From the email conversation with the Senior programmanager Asset Wise, as can be seen in Appendix D – Email conversation Amsterdam Airport Schiphol, it comes forward that Amsterdam Airport Schiphol wants to use a TCO tool for future investment decision making. This, however, is an empty format, and how this tool will be filled is not (yet) determined. It can be concluded that no large steps are taken after the research of Puijn in 2013.
Some other companies have also been contacted, but no other indications of a TCO tool that is actually in use were found. The information obtained at these external sources will be used again in chapter 6, the design validation.
TCO decision making tools in Shell
Table 5-1: TCO tools in Shell
Name Source Date
Characteristics
Goal Complexity Covered areas
1 Gas Turbine
TCO Tool DEV Shell wiki aug-09 Supplier - model selection Complex
Capex - Only Gas Turbines 2 OCP TCoO
model Shell wiki jul-98
Onshore Compression
Plant: Tendering assisting Complex
Capex - Opex – Maintex 3 TCO tool
example Shell wiki
before aug-09
Difference between fuel
dispenser and car wash Medium
Capex – Maint. - Disposal cost 4 P604ab cost of investment Shell Moerdijk aug-12
Determine most optimal
design for spare pumps Medium Capex - Opex 5 CMCP Group
Template TCO model
CP Shell
Global sep-09
Identify key cost and
value drivers Medium
Purchase - Acquisition - Usage - End of life 6 Delta life cycle
cost calculation Shell wiki
before aug-09
Insight difference Capex -
Opex and Capital charge Simple Capex - Opex
As can be seen from the table, these tools differ a lot, even when they are only categorized based on their purpose, complexity and the areas they cover. Their origin is not mentioned in the table, this also highly differentiates, varying from a department of Shell Global Solutions, a United States based consultancy firm working for Shell, to an engineer of Shell Chemical in Moerdijk. However, as much as these tools differ from each other, there is one big commonality: all tools are made in the software program Microsoft Office Excel. Therefore, Excel will be the program used for a new solution to be built in, because this clearly satisfies requirement 2: Make the solution compatible with the current organization. The tools will now briefly be discussed.
Tool 3 and Tool 4 are rather uncomplicated. This has a reason: they are made for only one purpose. Tool 3 is made for determining the difference between a fuel dispenser and a car wash; Tool 4 is specifically made for determining which of four designs in the case of two pumps would result in optimal TCO. There are no other options where these tools can be used for.
Tool 5 is rather simple in design, however when taking a closer look the possibilities of entering data seem endless. The years covered are year 0 till year 5, but additional years can manually be entered. For the categories that are predetermined – Purchase price, Acquisition cost, Usage cost and End of life cost – two types of cost can be given, but this also can be manually enlarged. For comparison, manually another option can be entered below the given template. An example is given on a separate tab. The tool generates an NPV and it is up to the user to select the most satisfying option.
Tool 6 is the most simplistic of all the found tools in Shell. This tool has input for three input options (Capex, Opex and Revenue) and seven assumptions (six financial / fiscal assumptions and the life cycle), with which it calculates the NPV and a percentage for Capital Charge if the NPV ~ 0. This Capital Charge can be seen as a measure to take the tax regime into account, and still be able to have some return on investment.
Now that the relevant tools found in Shell are discussed, the next step is to assess if one of these found tools or a combination can satisfy the requirements identified in the previous chapter.
5.2 Can existing TCO decision making tools be assembled to build new solutions?
Table 5-2: Satisfying of requirements by the found tools
Name Requirement
1 2 3 4 5
1 Gas Turbine TCO
Tool DEV - - + + +
2 OCP TCoO model - + + - -
3 TCO tool example +/- + + - -
4 P604ab cost of
investment +/- - + + +
5 CMCP Group
Template TCO model +/- - +/- + +
6 Delta life cycle cost
calculation + - +/- - -
As mentioned above, from the six relevant TCO tools found in Shell, they all have some elements that satisfy one or more requirements. Tool 4 and Tool 5 are tools that satisfy most requirements. There are several reasons to select Tool 5 over Tool 4. Firstly, Tool 5 is not made for one purpose but already is more generic. Secondly, Tool 5 leaves more room for open purpose. Thirdly, the lay-out of Tool 5 is more open and simple. So, Tool 5 is used as basis for the design process. Elements of other tools that can be included are added to this tool in order to come up with a feasible design. Which steps are taken to design a solution is discussed in the next paragraph.
5.3 Which steps are taken to design a solution?
As can be seen in the figure above, the template of Tool 5 is rather straightforward. The grey cells are cells where the user can insert data. On the left hand side are the 4 identified categories (Purchase price, Acquisition cost, Usage cost and End of life cost), and under the years (from 0 till 5) the amount and value of these parts can be specified per year. In the light blue cells the NPV is given, and a corresponding graph with the different costs and the NPV is visually presented. Apart from the grey cells, the user does not have to adjust anything for this option. Some Excel-experience comes to play when willing to add a second option, an additional line for parts input per category, or an additional year to consider. This has to be inserted manually. What this tool basically does is, based on cost of capital given in the top left grey cell calculate the cash flow and the corresponding PV per year, and per category. This is graphically presented and automatically calculated.
In this section the steps to design a solution that satisfy all requirements are discussed, therefore the requirements are once more listed:
1. Keep the tool simple.
i. It has to be fool proof and prescriptive.
ii. The tool must not be too demanding for people who have to work with it. 2. Make the solution compatible with the current organization.
i. Implementation in current Maintenance Modification process ii. Implementation in EOM (Extra-ordinary Maintenance) process
iii. Follow the Operational Excellence – Blade 20 TCO as close as possible
iv. Data: Currently we do not have the right data of old projects to do a TCO analysis. For future projects this has to be done with this solution.
v. Communication plan additional to the tool with background information both on TCO as an explanation of the tool itself.
3. Entire life cycle of project that is proposed will be reviewed. 4. Reasonable reliability of cost estimates.
5. Clear list of assumptions under which the tool is constructed. i. Boundaries when to use the model have to be determined.
5.3.1 Additional building blocks
As stated above, Tool 5 is satisfying requirements 1, 4 and 5: it is rather simple, reasonable reliable and the assumptions under which the tool functions are mentioned on a separate tab. This can be updated according to the set requirements in a relative simple manner. Requirements 2 and 3 are not met, as will be discussed next. Afterwards also some additional requirements of Operational Excellence – Blade 20 TCO are discussed.
Requirement 2 – Make the solution compatible with the current organization
For requirement 2, some additional functionality has to be added, so that the tool can function in the Modification Process. This is the adapted Opportunity Realization Process as it is used by the maintenance department, which is discussed in chapter 4. For Decision Gate 2 (DG2) at least two different options have to be compared, and an optimal one has to be selected. This selection of the optimal option, to satisfy requirement 1, should go automatically. An example of an automatic selection mechanism was found in Tool 1. Current organizational practice of an option to be considered is an initial screening value of a positive NPV. This cost estimate has the accuracy of L1 (+40%/-25%). The selection criterion then is the highest VCR of the options that are compared. This VCR will now be explained.
VCR stands for Value Cost Ratio, an economic evaluation measure used in Shell. The value of VCR is calculated by dividing the NPV by the PV of the investment. This comes down to:
Value Cost Ratio: 𝑉𝐶𝑅 = NPV of cash in−and outflows𝑃𝑉 𝑜𝑓 𝑐𝑎𝑠ℎ 𝑜𝑢𝑡𝑓𝑙𝑜𝑤𝑠 . When the VCR > 0, the option should
have a higher cash inflow than cash outflow and thus is worth investing in. In Shell, it is practice to have a managerial decision about the lowest VCR to be considered; mostly this is a value of 0.4. The philosophy behind this is that there is a constraint on financial resources, and if the value of 0.4 is not met, then the available financial resources are invested in a project that does meet the VCR requirement of > 0.4. VCR has similarities with the Internal Rate of Return (Alchian, 1955), but in Shell it is called VCR to emphasize on Opex decision making.
