distributed generation business modellingd 5.1 distributed generation business modelling eesd...

Business Models in a World Characterised by Distributed Generation

NNE5/2001/256

Distributed Generation Business Modelling

Vera Kartseva, Jasper Soetendal, Jaap Gordijn, Hans Akkermans, Joost Schildwacht

Vrije Universiteit Amsterdam

Identifier: VUA_DGB_WP05_01_01

Date: April 2, 2004

Class: Deliverable

Responsible Partner: VUA

Distribution: Public

Overview: This document describes the e3-value methodology for DG

D 5.1 Distributed Generation Business Modelling EESD Project NNE5/2001/256 BUSMOD

BUSMOD: Business Models in a World Characterised by Distributed Generation

Page

2

The BUSMOD Consortium consists of:

IBERDROLA Principal Contractor & Coordinator Spain LABEIN Principal Contractor Spain VUA Principal Contractor The Netherlands ECN Principal Contractor The Netherlands SINTEF Principal Contractor Norway UMIST Principal Contractor United Kingdom EnerSearch Principal Contractor Sweden

Control Versions:

Version Date Author Description of Changes

VUA_DGB_WP03_01_00 31-08-2003

VUA_DGB_WP03_01_01 16-09-2003 Kartseva Chapter 2

VUA_DGB_WP03_01_02/D3.1-v1.3.06

17-10-2003 J. Schildwacht Diverse changes in Chapters 1-6, Chapter 7

VUA_DGB_WP05_01_01/D5.1-v1.10

25-03-2004 J. Schildwacht Diverse changes in all Chapters and Appendixes



Page

3

Table of Contents

Chapter 1 Introduction 17

1.1 The BusMod methodology 17

1.2 Reading guide 18

Chapter 2 A Case Study in Distributed Generation Modelling 20

2.1 E3-value methodology in a nutshell 21

2.2 Spanish case 23

2.2.1 Technology, stakeholders and their goals 23

2.2.2 Value model 25

2.2.3 Financial analysis 27

2.2.3.1 Data 27

2.2.3.2 Profitability sheets 28

2.3 Sensitivity analysis 31

2.3.1 Investment analysis 32

2.3.2 Discovering new value models 34

2.3.2.1 Business model: Distributed generation to solve shortage in distribution capacity 35

Chapter 3 DG Business models 39

3.1 Introduction 39

3.1.1 Goals 39

3.1.2 Technology 39

3.1.3 Business Value Model 40

3.1.4 Financial Model 41

3.2 Value activities in a nutshell 41

3.3 DG Goal hierarchy 43

3.3.1 Strategic goals 44

3.3.2 Operational goals 46

3.3.3 Make profit goal 46

3.3.4 Consume Electricity goals 46

3.3.5 Provide market functioning goals 47

3.3.6 Goal hierarchy of operational goals 47

3.3.7 Relating strategic goals and operational goals 52



Page

4

3.3.8 Relation operational goals and value activities 53

3.4 DG Technology Hierarchy 54

3.4.1 Performance characteristics 54

3.4.2 Economic characteristics 55

3.4.3 Size and availability characteristics 57

3.4.4 Technology characteristics estimation 58

3.4.5 How to use the technology hierarchy 60

3.5 A reference business value model for DG 60

3.5.1 Value activities 61

3.5.1.1 Scenario paths 61

3.5.1.2 DG Value activities 64

3.5.1.2.1 Electrical System Regulation 64

3.5.1.2.2 Policy Making 65

3.5.1.2.3 Trade 66

3.5.1.2.4 Network management 67

3.5.1.2.5 Generation 67

3.5.1.2.6 Transmission 68

3.5.1.2.7 Distribution 69

3.5.1.2.8 Supply 70

3.5.1.2.9 Consumption 71

3.5.1.2.10 Manufacturing 71

3.5.1.2.11 Leasing 72

3.5.1.2.12 Balancing 72

3.5.1.2.13 Energy efficiency 73

3.5.1.2.14 Aggregation 74

3.5.1.2.15 Metering 75

3.5.1.2.16 Fuel Supply 75

3.5.1.2.17 Heat Supply 76

3.5.1.2.18 Market management 76

3.5.1.2.19 A reference value model 77

3.5.2 Variations on the reference value model 79

3.5.2.1 Regulation activity 79

3.5.2.2 Policy making activity 81

3.5.2.3 Consumer payments 81

3.5.2.4 Buy or Lease 82



Page

5

3.5.2.5 Bilateral contracts 83

3.5.3 Actors 84

3.5.3.1.1 Regulatory Authorities 85

3.5.3.1.2 Policy maker 85

3.5.3.1.3 Market Operator 85

3.5.3.1.4 Transmission System Operator 85

3.5.3.1.5 Independent System Operator 86

3.5.3.1.6 Distribution System Operator 86

3.5.3.1.7 Producer 86

3.5.3.1.8 Final customer 86

3.5.3.1.9 Supplier 87

3.5.3.1.10 Utility 87

3.5.3.1.11 Energy Service Company 88

3.5.3.1.12 Manufacturer 90

3.5.3.1.13 Lease Company 90

3.5.3.1.14 Autoproducer 90

3.5.3.1.15 Independent Power Producer 90

3.5.3.1.16 Green Producer 91

3.5.3.1.17 Distributed Producer 91

3.5.3.1.18 Retailer 91

3.5.3.1.19 Marketer 91

3.5.3.1.20 Broker 92

3.5.3.1.21 Retail Shop 92

3.5.3.1.22 Aggregator 92

3.5.3.1.23 Buying Pool 93

3.5.3.1.24 Load Management Group 93

3.5.3.1.25 Balance Group 94

3.5.3.1.26 Metering Company 94

3.5.3.1.27 Fuel Supplier 94

3.5.3.1.28 Heat Supplier 94

3.5.3.1.29 ICT service provider 94

3.5.4 Relating value activities and actors 95

Chapter 4 DG Business modelling 99

4.1 Step 1: Business case description 101



Page

6

4.1.1 Tasks to do 101

4.1.2 Questions to ask 102

4.1.3 Guidelines to use 102

4.1.4 Example 102

4.2 Step 2: Goal selection 104

4.2.1 Strategic goals selection 104




4.2.5 Example 105

4.2.6 Operational goals selection 106




4.2.10 Example 108

4.3 Step 3: Technology selection 111




4.3.4 Example 115

Step 4: Value activity selection 119




4.3.8 Example 121

4.4 Step 5: Value interface selection 121




4.4.4 Example 124

4.5 Step 6: Ports connection 127




4.5.4 Example 128



Page

7

4.6 Step 7: Actor selection 130




4.6.4 Example 133

4.7 Step 8: Scenario Path Identification 136




4.7.4 Example 139

4.8 Step 9: Information System Model construction 140




4.8.4 Example 143

4.9 Step 10: Base-line profitability sheets calculation 145




4.9.4 Example 151

4.9.4.1 Create profitability sheets 151

4.9.4.2 Determine timeframe and common measurement units 152

4.9.4.3 Determine valuation functions 153

4.9.4.4 Collect data 156

4.9.4.5 Calculate profitability sheets 157

4.10 Step 11: Sensitivity analysis 160




4.10.4 Example 161

4.11 Investments analysis 162

4.11.1 Net present value calculation 162

4.11.2 Internal rate of return 163

4.11.3 Value modelling and investment analysis 163




Page

8

4.11.5 Example 164

Chapter 5 Guidelines for the e3-value methodology 167

5.1 Business models – Economic Value perspective 167

5.1.1 Representing Value Models 167

5.1.2 Three sub-viewpoints 167

5.1.2.1 The global actor viewpoint 168

5.1.2.2 The detailed actor viewpoint 176

5.1.2.3 The value activity viewpoint 178

5.1.2.4 Scenarios by Use Case Maps 180

5.1.3 Constructing Correct Value Models 183

5.1.3.1 Creating value interfaces 184

5.1.3.1.1 Identify value objects and ports 184

5.1.3.1.2 Group ports into value offerings 185

5.1.3.1.3 Group value offerings into value interfaces 186

5.1.3.1.4 Identify value exchanges 187

5.1.3.2 New actors 187

5.1.3.3 Creating scenario paths 188

5.1.3.3.1 Identify use case maps 188

5.1.3.3.2 Identify paths 191

5.1.3.3.3 Global actor, detailed actor and value activity viewpoints 191

5.1.3.3.4 Global actor viewpoint 192

5.1.3.3.5 Detailed actor viewpoints 192

5.1.3.3.6 Value activity viewpoints 192

5.1.3.4 A cyclic process 193

5.1.3.5 Deconstruct and reconstruct value models 193

5.1.3.6 Develop other viewpoints 193

5.2 Financial models 194

5.2.1 Evaluate e-commerce ideas 194

5.2.1.1 Create profitability sheets 194

5.2.1.2 Assign economic value to objects 196

5.2.1.2.1 Assign economic value to objects: enterprise perspective 197

5.2.1.2.2 Assign economic value to objects: end-consumer perspective 198

5.2.1.3 Evaluate using evolutionary scenarios 199

5.2.1.3.1 Evolutionary scenarios 199



Page

9

5.2.1.3.2 Elicit evolutionary scenarios 200

Chapter 6 Commonly Made Mistakes 203

6.1 Mistake 1: Modelling physical processes 203

6.2 Mistake 2: Modelling information exchange 204

6.3 Mistake 3: Modelling investments 205

6.4 Mistake 4: Excluding important alternatives 206

Chapter 7 Guide on how to create a value model using the e3-value tool 208

7.1 Guide on how to create a value model using the e3-value tool 208

7.1.1 Step 0: Opening the editor 208

7.1.2 The graphical components 209

7.1.3 Step 1. Adding market segments and actors to the edit workspace 211

7.1.4 Step 2. Add value activities 213

7.1.5 Step 3. Adding value interfaces, ports and exchanges 215

7.1.6 Step 4. Add stimuli to the e3-value model 217

7.1.7 Step 5. Editing the e3-value Properties 219

7.1.8 Step 6. Adding value objects and value transactions. 220

7.1.9 Step 7: Modelling value transactions 221

7.1.10 Step 8. Editing scenario ports, adding weights 224

7.1.11 Step 9. Creating formulas and adding them to the model 224

7.1.12 Step 10. Saving your business model 227

7.2 How to create profitability sheets with the e3-value editor 228

7.2.1 Introduction 228

7.2.2 Profitability sheet generation 228

7.2.3 Profitability sheet document structure 231

Appendix A Goal hierarchy spreadsheet 234

A.1. Strategic goals. 234

A.2. Operational goals. 235

Appendix B Goal-Technology checklist 237

B.1 Strategic goals 237

B.2 Operational goals 238



Page

10

Appendix C Some technologies and their characteristics 241

Appendix D Goal-conflict matrix 242

Appendix E Value Interface Library 243

Appendix F Goal-Activity-Value Interface Template 262

Appendix G Structure of a profitability sheet of an actor 263

Appendix H Actors and Activities matrix in the Electrical System 264

Appendix I Installation of the e3-value editor 267

Appendix J E3-value editor technical reference 269

10.1 RDF generation steps 269

10.1.1 Create instances 269

10.1.1.1 Simple mapping 269

10.1.1.2 Merging objects 270

10.1.1.3 Rules for merging model concepts 271

10.1.2 Assign attributes 273

10.1.3 Generate RDF files / file stream 273

10.2 Profitability sheet generation 274

10.2.1 Approach 274

10.2.2 Profitability sheet generation steps 274

10.2.3 Assign occurrences to the value ports and the value transactions. 275

10.2.4 Parse all formulas 288

10.2.5 Create a ‘Formula Sheet’ for all formulas (or placeholders). 288

10.2.6 Assign ‘Default Valuation Formulas’ to each value port 289

10.2.7 Update the Formula sheet with ‘Default Valuation Formulas’ 291

10.2.8 Create Excel sheets for each e3-value ontology class 291

10.2.9 Create Excel (profitability) sheets for any Value Source instance. 292

Appendix K E3-value editor: tips, tricks and error messages 295

11.1 Import shortcuts and tricks 295

11.2 Error messages 296

11.3 Formulas: Reserved names 304



Page

11

11.4 Formula Syntax 305

11.5 Formulas: Formula limitations 308

11.6 Merging Objects 308

11.7 Valuation functions 311

Appendix L E3-value editor: appendix for the programmer 314

12.1 Batik 314

12.1.1 Details 314

12.1.2 Implementation 315

12.2 Jakarta POI HSSF 315

12.2.1 Details 315


12.2.3 Limitations 316

12.3 JGo™ Java diagram graphics libraries 316

12.3.1 Details 316


12.4 GOLD Parser 317

12.4.1 Details 317


12.5 RDF2Java 318

12.5.1 Details 318


12.6 Customizing third party software 319

12.6.1 JGo 319

12.6.1.1 JGoDocument.java 319

12.6.1.2 JGoTextEdit.java 320

12.6.1.3 JGoView 321

12.6.2 Gold 321

12.6.2.1 GOLDParser.java 321

12.6.2.2 LookAheadStream.java 321



Page

12

List of Figures

Figure 1. A shopper obtains a good from a store and offers money in return. So do the other actors. The scenario path shows that in reaction to a start stimulus (a consumer need), the store needs to buy a good also, and so does the wholesaler. 21 Figure 2. In this scenario the distribution company is forced to buy all the electricity generated by renewable producers, resulting in a situation where the amount of electricity generated is always equal to the amount of electricity sold. Moreover, the price of electricity bought from the renewable producer is also fixed. The abolishment of the fixed electricity price and obligation to buy all the electricity from renewable sources can render the renewable production business unprofitable. 26 Figure 3 The model of the deregulated market. The electricity is sold via the pool, organized by the market operator. Final customers have a possibility to choose a supplier. Note that the model shows only the exchange of economic valuable objects between actors, and not the physical flow of electricity. Physically, the producer is placed into the transmission grid, represented by TSO. 34 Figure 4. The situation without distribution grid capacity problems. 36 Figure 5. The situation with distribution grid capacity problems. 37 Figure 6. Strategic and operational goal hierarchy got distributed generation. 44 Figure 7. An example of a scenario path. 62 Figure 8. Scenario path: AND-fork. 63 Figure 9. Scenario path: OR-Fork. 64 Figure 10. Electric System Regulation. 65 Figure 11. Policy Making. 66 Figure 12. Trade. 66 Figure 13. Network Management. 67 Figure 14. Generation. 68 Figure 15. Transmission. 69 Figure 16. Distribution. 70 Figure 17. Supply. 71 Figure 18. Consumption. 71 Figure 19. Manufacturing. 72 Figure 20. Leasing. 72 Figure 21. Balancing. 73 Figure 22. Energy Efficiency. 74 Figure 23. Aggregation. 74 Figure 24. Metering. 75 Figure 25. Fuel Supply. 76 Figure 26. Heat Supply. 76 Figure 27. Market Management. 77 Figure 28. A Reference Value Model. 78 Figure 29. Reference value model incl. regulation activity. 80 Figure 30. Consumer payments – Combined payment. 81 Figure 31. Consumer payments – Separate payments. 82 Figure 32. Buying equipment. 83 Figure 33. Leasing equipment. 83 Figure 34. Bilateral contracts. 84 Figure 35 Diagram of the process steps 100 Figure 36. The tree different types of activities (core, direct- and in-direct environmental) shown for the Autoproducer example. 123 Figure 37. Graphical model after step 5. 126 Figure 38. Graphical model after making connecting trivial connections of value interfaces. 128 Figure 39. Graphical model after step 6. 129



Page

13

Figure 40. Market segment. 132 Figure 41. Assigning actors and splitting. 133 Figure 42. The model after grouping. 135 Figure 43. The complete value model. 136 Figure 44. A notation for variable operational expenses. 138 Figure 45 A notation for fixed operational expenses 138 Figure 46. The final model to be analysed. 140 Figure 47. Information System Model Example. 142 Figure 48. Information System Model. 144 Figure 49. An example of profitability sheet creation. 146 Figure 50. An example of profitability sheet creation: OR-construction. 147 Figure 51. An example of multiple exchanges of a value interface. 147 Figure 52. An example of AND construction. 148 Figure 53. Example of a value exchange in the electricity sector. 148 Figure 54 Profitability sheets for model in Figure 46. 159 Figure 55 Profitability for each actor 159 Figure 56. Use more than one value model to make investment decision. 164 Figure 57. Value model for a free Internet access service: the global actor viewpoint. 169 Figure 58. Actor a can decide to exchange value objects with actor b, or actor c. 172 Figure 59. A value exchange can be in multiple transactions. 173 Figure 60. A value model without and with market segment. 175 Figure 61. Value model for the free Internet case: the detailed free Internet service provider actor view. 176 Figure 62. Value model for the free Internet case: the value activity view. 179 Figure 63. UCM constructs. 181 Figure 64. Use Case Maps applied to the global actor viewpoint. 182 Figure 65. Use Case Maps applied to the detailed actor viewpoint. 182 Figure 66. Value interfaces with each having an offering containing only one port. 187 Figure 67. Identification of use case maps and paths. 190 Figure 68. Don’t do this… (Modelling physical processes). 203 Figure 69. … do this! (Modelling value exchanges). 204 Figure 70. Don’t do this… (Modelling information exchange). 205 Figure 71. … do this! (Modelling value exchanges). 205 Figure 72. Don’t do this… (Exclude important alternatives). 207 Figure 73. … do this! (Including an important alternative). 207 Figure 74. Overview e3-value editor. 208 Figure 75. Edit text in the edit box. 210 Figure 76. Step 1 : drop market segments and actors on the workspace. 211 Figure 77. Edit text in the edit box. 212 Figure 78. Enlarge an object by click and dragging the green rectangles. 212 Figure 79. Adding value activities with the e3-value tool. 213 Figure 80. Move text on an object to another location. 214 Figure 81. e3-value model after completing step 1 and step 2. 214 Figure 82. Adding value interface on an activity, an actor or a market segment. 215 Figure 83. Adding and removing value ports. 215 Figure 84. Move the text on the value exchange line to another location. 216 Figure 85. Value model after step 3. 216 Figure 86. Selecting and rotating the ‘and’ and ‘or’ scenario elements. 217 Figure 87. Connect the black dots on the scenario elements to create a scenario path. 217 Figure 88. Final e3value model after fulfilling step 1 until 4. 218



Page

14

Figure 89. Right clicking the market segment opens the context menu. 219 Figure 90 Choosing the Edit E3Properties pops the E3Properties Editor. 219 Figure 91 The context menu of a value port opens the collection editor of value objects 220 Figure 92 E3Properties Editor invoked from the collection editor on a value object 221 Figure 93 E3Properties Editor invoked on a value transaction 221 Figure 94 Example: Incorrect value transactions 222 Figure 95 Example: Incorrect value transactions 223 Figure 96 Example: Correct value transactions 223 Figure 97 The properties option in the context menu of a scenario port 224 Figure 98. Assigning formulas to objects 225 Figure 99 Save as dialog - export profitability sheets 229 Figure 100 Merged concepts dialog example 230 Figure 101 Error message dialog example 230 Figure 102 “Unseen objects” dialog example 231 Figure 103 Actor-sheet example 232 Figure 104. Matrix of possible connections. 243 Figure 105. Test if a recent version of the Java Runtime Environment is installed. 267 Figure 106 starting the tool from the console 268 Figure 107. The “about”-button reveals the version and other important settings. 268 Figure 108 Object-merging: Two graphical objects may conceptually be identical. 270 Figure 109 - some merged instances in a Map 271 Figure 110 Example of multiple graphical objects representing a single conceptual object 309 Figure 111 Example of multiple graphical objects representing a single conceptual object 309 Figure 112 Example of default valuation formulas 313



Page

15

List of Tables

Table 1. Reading guide. ___________________________________________________________ 19 Table 2. Profitability sheets. ________________________________________________________ 29 Table 3. Profitability for each actor. _________________________________________________ 30 Table 4. Profitability for specific RES producers. _______________________________________ 30 Table 5. Strategic goals description. _________________________________________________ 45 Table 6. Operational goal descriptions. _______________________________________________ 47 Table 7. Relating strategic goals with operational goals. _________________________________ 52 Table 8. Relations between sub-goals of the “Make profit goal”, and associated value activities.__ 53 Table 9. An example of technological characteristics for the Reciprocating diesel engine. _______ 58 Table 10. DG technology characteristics estimation._____________________________________ 59 Table 11. Actors and Activities matrix in the Electrical System. ____________________________ 96 Table 12. General interfaces. ______________________________________________________ 125 Table 13. Goal specific value interfaces. _____________________________________________ 125 Table 14. Added activity: Supply. ___________________________________________________ 128 Table 15. Tariff structure._________________________________________________________ 153 Table 16. Premiums paid to various generation sources._________________________________ 155 Table 17. Generation data (Source: Red Eléctrica de España, "El Sistema Eléctrico Español - Informe 2001", available in http://www.ree.es/index_sis.html ). ___________________________ 156 Table 18. Sketches of cash flows. ___________________________________________________ 165 Table 19. NPV and IRR calculation._________________________________________________ 166 Table 20. Various value exchange types. _____________________________________________ 177 Table 21. Structure of a profitability sheet. ___________________________________________ 196 Table 22. Actors and Activities matrix in the Electrical System. ___________________________ 265 Table 23 Error message overview __________________________________________________ 303 Table 24 Reserved formula names __________________________________________________ 305 Table 25 Writing formulas - top level object reference syntax _____________________________ 305 Table 26 Writing formulas - sub-level object reference syntax ____________________________ 307 Table 27 Writing formulas - Attribute reference syntax __________________________________ 307 Table 28 Criteria for merging graphical objects _______________________________________ 311



Page

16

Executive summary

For the electricity industry, Distributed Generation (DG) of power imposes a major challenge. While in the recent past only a few very large generators were used for a country or region, nowadays many small electricity generation facilities are in use. These small scale facilities are a result of technological innovation (CHP, PV-cells, etc) but are also important to address societal driven issues like CO2 reduction.

So, the electricity industry is facing substantial changes: a move from a few generators to many, new forms of electricity generation, and re-regulation such as split up of enterprises doing supply and distribution of electricity.

Generally, a changing industry leads to new constellations of enterprises, new services and products, and even new enterprises. In addition, the DG industry is facing also a change in regulation. As a result, a whole industry needs to be re-designed.

The aim of the BusMod (Business Modelling) methodology is to provide techniques and guidelines for such a redesign on the business case level. To put it differently, the BusMod methodology is of help during the development and exploration of a business case in which distributed generation technology plays an important role.

The BusMod methodology consists of a series of steps. A first step is about making a textual statement of the DG business case in mind. For doing so, the methodology provides a template that can be used to express the idea in structured English. Each step provides background material, questions to ask (e.g. during workshops) and guidelines. A next step is to formulate the goal(s) of a DG business case, both on the strategic and operational level. If known, these goals are used to select candidate DG technologies that can contribute to reaching the goals. Then a series of steps follow that comprise the construction of a business value model. Such a model states the customers and enterprises involved as well as the exchanges of economic value between parties. The BusMod methodology provides a wealth of terminology, guidelines and presentation techniques to create such models. Once a value model for a specific DG case has been created, it should be analyzed for potential profitability. Each enterprise that is needed to let an idea work should be able to make profit with the DG business case. A final step is to make a sensitivity analysis of the DG business case at hand: which factors influence the success of the DG business case.

The result of applying the BusMod methodology is that all parties involved have a shared understanding of the DG business case. In case multiple cases are explored, they become comparable, and the most promising cases can be selected for further analysis.



Page

17

Chapter 1 Introduction

1.1 The BusMod methodology

Business cases for distributed generation tend to be complex for a number of reasons. First, many actors (enterprises and end-consumers) are involved. The DG-business can be literary characterized as a networked business. Many actors result in many interests, and thus in cluttered and somewhat unclear discussions between actors. A second reason for the complexity of DG-business cases is the government-based market de- and re-regulation. This regulation imposes all kinds of difficult constraints on e-business cases, and in many situation, re-regulation is actually needed to make DG-business cases work. Third, DG business cases typically require substantial long-term investments. In some cases, even only a portfolio of business cases may justify a DG-investment.

The aim of the BusMod methodology is to help and guide the DG-business developer by building a DG business case. The BusMod methodology does so in a number ways. First, the BusMod methodology helps to explore a business case in the field of distributed generation. To do so, a business idea has to be described by means of a pre-defined template, which is used to make a business model of the DG-case at hand. Such a model facilitates further analysis and evaluation. In the case of BusMod, analysis focuses on a financial understanding of the business case, both from an investment and operational cash flow perspective. Evaluation takes the form of “what if” scenarios. For instance, because many cases depend on regulations, is important to assume a scenario that supposes a substantial change in regulation over the lifetime of the DG-investment.

Second, the BusMod methodology can be of help in creating a common understanding of the business case. As mentioned, DG cases typically require the involved of multiple actors, each represented by many stakeholders. Discussing a business case in such a broad audience may result in a poor, and not shared understanding of the business case. By explicitly modelling a DG case using a shared and well-defined terminology, the BusMod methodology contributes to a better and shared understanding of the business case at hand.

The BusMod methodology is grounded on two different pillars. First, BusMod uses established business modelling methodologies for networked enterprises such as e3value [Gordijn, 2002]. This methodology has been used in the realm of e-commerce. Additionally, BusMod uses traditional economic investment assessment techniques such as calculation of net present value and internal investment rate for a portfolio of business cases. Second, the BusMod methodology offers a terminology and way of working specialized into the domain of DG. An important part of the BusMod project was to explore current and future scenarios on DG (deliverables D 2.1/2.2). These scenarios have been used to create a specific DG terminology usable for the description of DG business cases, and have been used to create a series of steps, specifically for the DG domain, to be performed to describe a DG business case.

We have tested earlier versions of the methodology by doing two cases: a study for Iberdrola (see also Chapter 2 of this document), and a study for SINTEF. We have also pre-tested a



Page

18

workshop set-up related to this version of the BusMod methodology with SINTEF. In the coming period, the practical use of the methodology has to be tested by WP4, which contains a series of serious DG case studies. We will carefully follow these case studies, and incorporate the learning’s and outcomes in this document. Finally, as a service to reader, the next section contains a reading guide for this document.

1.2 Reading guide

This document contains a lot of information with its 322 pages. Not all readers will be interested in all sections of the document. The exploration of new business ideas involves different stakeholders with different background. The e3 value methodology is used to bridge the gap between different stakeholders like CxO’s, operational management and IT-departments. All these stakeholders are needed to put an idea into operation, but all from a different viewpoint and with different backgrounds. The e3 value methodology facilitates a clear communication- and decision taking process and a way to evaluate new business ideas.

The bottom-line of this document is ‘How to use the e3 value methodology and how to apply it to distributed generation specific issues’. This is explained in 7 chapters, all covering a part of this bottom line.

Chapter 2 shows a specific case study in the field of distributed generation, using the methodology we will explain later on in the document.

Chapter 3 describes how the generic e3value methodology can be applied to the electricity market and specific DG cases.

Chapter 4 is a ‘manual for constructing value models’. This chapter can be used as cookbook while constructing a value model, describing step by step what actions need to be taken.

Chapter 5 contains guidelines for the e3 value methodology and starts where chapter 3 ended. In-depth information how to construct correct value models is provided.

Chapter 6 describes a set of commonly made mistakes, to prevent you to make the same mistakes all the others made.

Chapter 7 describes a step by step guide on creating e3-value models using the VUA editing tool.

As we noticed early, putting a business idea into operation requires a lot of stakeholders. But no matter how much stakeholders involved, regarding the e3-value methodology, all stakeholders can be divided in three groups:

o Those who will have to understand value models and profitability sheets;

o Those who will have to construct value models and profitability sheets;

o Those who will need in-depth knowledge about the construction of value models and profitability sheets for completely new business ideas, including activities and actors



Page

19

not mentioned in this document;

Needless to say that it’s easier to learn how to understand and interpret value models and profitability sheets than how to construct them. The first to groups do not need to read the whole document, because large parts of the text describe in-depth how to construct value models.

For each group, a set of chapters can be defined which are necessary, or at least helpful, to read. This is shown in Table 1.

Table 1. Reading guide.

Chapters Target group

1 2 3 4 5 6 7

Those who need to know how to understand and interpret value models and profitability sheets. ● ● ●

Those who need to know how to construct value models and profitability sheets. ● ● ● ● ●

Those who will need in-depth knowledge about the construction of value models and profitability sheets for completely new business ideas, including activities and actors not mentioned in this document.

● ● ● ● ● ●



Page

20

Chapter 2 A Case Study in Distributed Generation Modelling

The electricity sector in Europe and elsewhere is rapidly changing due to business as well as technology drivers. New players emerge (e.g. wholesalers of electricity) as well as new services (real-time pricing, home services, building management, IP over the electricity grid, demand-side management). A key question for players in the electricity sector is how to find corresponding new, competitive business models. In this section we will demonstrate how our design-oriented methodology can be used to explore new business models for the electricity sector, using technological advances in distributed generation technology, and taking into account government motivated re-regulation.

An important trend, occurring on the level of European policy, is a support of the technologies producing fewer emissions. In this connection should be mentioned the current promotion of expensive renewable technologies by government subsidizing schemes. These schemes lead to the emergence of new business models, however, since most of them rely on uncertain subsidizing schemes, the evaluation and sensitivity analysis of such business models is essential.

The business scenario from the Spanish market taken as an example in this chapter is a typical instance of a business supported by a subsidizing scheme. The Spanish government subsidizes producers that comply with the “special rules”, namely electricity generation plants of less than 50 MW capacities, which generate electricity using cogeneration systems or renewable energy sources. The subsidy is delivered according to the amount of the electricity produced, in other words, the “special rules” get a higher price for the generated electricity. In addition, there are other promotion schemes to support “special rules” generation in Spain, such as the obligation for the distribution company to accept renewable DG units.

In this chapter we evaluate the business scenario that considers the utilization of a subsidizing scheme described above. This chapter is structured as follows. First, we shortly describe the main concept of e3-value business modelling methodology [Gordijn, 2002]. Then, we give an example of application of the methodology for evaluation of the Spanish business scenario, including the analysis of goals of stakeholders, analysis of the technological solution, building the graphical conceptual model and financial evaluation. Finally, we show several evolutionary scenarios.



Page

21

2.1 E3-value methodology in a nutshell

The e3-value methodology provides modelling concepts for showing which parties exchange things of economic value with whom, and expect what in return. The conceptualisation of a business idea can be graphically represented (see for example

Figure 1) in a rigorous and structured way. For diagramming purposes, the reader can download a VISIO tool stencil from our website at http: //www.cs.vu.nl/~gordijn/research.htm. What follows is a summary of the most important concepts.

Figure 1. A shopper obtains a good from a store and offers money in return. So do the other actors. The scenario path shows that in reaction to a start stimulus (a consumer need), the store needs to buy a good also, and so does the wholesaler.

Actor. An actor is perceived by its environment as an independent economic (and often also legal) entity. An actor makes a profit or increases its utility. In a sound, sustainable, business model each actor should be capable of making a profit. In the electricity there are a common set of actors, as, for example, producer, distribution system operator, transmission system operator, and government. With market deregulation there are new actors appear, namely, the supplier, but also grid balancing groups, energy service companies, metering companies, etc.

Value Activity. The electricity sector performs several activities, namely: generation, transmission, distribution, supply, coordination of sales, system operation, etc.



Page

22

Value Object. Actors exchange value objects, which are services, products, money, or even consumer experiences. The important point here is that a value object is of value for one or more actors.

Value Port. An actor uses a value port to show to its environment that it wants to provide or request value objects. The concept of port enables us to abstract away from the internal business processes, and to focus only on how external actors and other components of the business model can be ‘plugged in’.

Value Offering. A value offering models what an actor offers to or requests from his/her environment. The closely related concept value interface (see below) models an offering to the actor’s environment and the reciprocal incoming offering, while the value offering models a set of equally directed value ports exchanging value ports. It is used to model e.g. bundling: the situation that some objects are only of value in combination for an actor.

Value Interface. Actors have one or more value interfaces, grouping individual value offerings. A value interfaces shows the value object an actor is willing to exchange in return for another value object via its ports. The exchange of value objects is atomic at the level of the value interface.

Value Exchange. A value exchange is used to connect two value ports with each other. It represents one or more potential trades of value objects between value ports.

Market segment. The concept market segment shows a set of actors that for one or more of their value interfaces, value objects equally from an economic perspective.

The concepts above allow us to model who wants to do business with whom, but can not represent all value exchanges needed to satisfy a particular end-consumer need. It occurs often that, to satisfy an end consumer need, several other actors have to exchange objects of value with each other. As an example think of a store that exchanges economic values with an end consumer: as a result, the store must also exchange values with a wholesaler. It is our experience that showing all such value exchanges to satisfy an end consumer need contributes largely to a common understanding of an e-business idea. To that purpose we use an existing scenario technique called Use Case Maps, which show which value exchanges should occur as a result of a consumer need (which we call a start stimulus), or as a result of other value exchanges. Below, the main UCM modelling constructs are briefly discussed.

Scenario path. A scenario path consists of one or more segments, related by connection elements and start and stop stimuli. A path indicates via which value interfaces objects of value must be exchanged, as a result of a start stimulus, or as result of exchanges via other value interfaces.

Stimulus. A scenario path starts with a start stimulus, which represents a consumer need. The last segment(s) of a scenario path is connected to a stop stimulus. A stop stimulus indicates that the scenario path ends.

Segment. A scenario path has one or more segments. Segments are used to relate value interfaces with each other (e.g. via connection elements) to show that an exchange on one value interface causes an exchange on another value interface.

Connection. Connections are used to relate individual segments. An AND fork splits a



Page

23

scenario path into two or more sub paths, while the AND join collapses sub paths into a single path. An OR fork models a continuation of the scenario path into one direction that is to be chosen from a number of alternatives. The OR join merges two or more paths into one path. Finally, the direct connection interconnects two individual segments.

The e3value modelling concepts described above are the core of the business modelling methodology, presented in this document. The ultimate goal of the business modelling is to evaluate the business idea and discover a business scenario, feasible for every stakeholder. A business scenario is described in terms of e3value modelling methodology and consists of the business model and scenario path. A business model is a set of value activities and value objects, exchanged between these value activities. In the electricity sector there is a number of value activities that are common for the electricity business, namely: generation, transmission, distribution, supply, coordination of sales, etc. Actors in the electricity business are producers, distribution system operators, transmission system operator, supplier, etc. Each actor can perform one or more such value activity.

2.2 Spanish case

In this section we introduce the elements of a DG business model by exemplifying the development of the business scenario of subsidizing the renewable energy in Spain. The development of the business model starts with clarifying what goals the business scenario targets to achieve and what technology will bring the best possible solution. Then, after decisions about goals and technology are made, we develop a business value model by using e3-value modelling methodology. Putting a business value model into operation has financial effects, which are represented by a financial model. Finally, because the fore mentioned models are subject to uncertainty, we develop a sensitivity model to discover potential strengths and weaknesses in the DG case at hand.

2.2.1 Technology, stakeholders and their goals

Business idea description. The starting point of business modelling is to outline the business idea in terms of business process, stakeholders, regulatory incentives, etc. In our case we would like to model the situation of subsidizing renewable producers in the Bask Autonomous region.

The initiator of the business scenario is Iberdrola Group, a former utility, which now, to satisfy European laws, is divided into several companies to separate generation, distribution and supply. The business idea, as described by Iberdrola group, is to install a small generator based on renewable energy sources (RES), to sell electricity to the grid. In this particular case, the producer may be a household customer, purchasing electricity at tariff price, and the generator will be small and based on any of the following renewable energy sources: photovoltaic, solar thermal, small hydro, wind, geothermal, wave energy, tidal energy.

Iberdrola is firmly committed to renewable energies, aiming to become world leader in this business and plan to invest up to 2.5 billion euro in generation from renewable sources, which will give a 14% of the total capacity of the group at the end of 2006. Ibedrola also mentions the growing contribution of the Renewable Energies division to the profits of the



Page

24

Iberdrola group in the first half of 2002 (see www.iberdrola.com). Iberdrola has already implemented the business idea, described above. But why would they want to investigate the business scenario that already claimed to bring profit?

Currently in Spain the expensive renewable technologies are artificially supported by a premium system. The Distribution System Operator (DSO) is forced to purchase all the energy produced from RES, and to pay a premium for it. The premium is paid for all the electricity generated, not only for the surplus. Different generators receive different premiums regarding their size and technology: it starts from about 21Euro/MWh for electricity generated by Combined Heat Power (CHP), and till an extreme number 360,61 Euro/MWh for electricity generated by 5MW photovoltaic panel. Already in 2002 José Folgado, the Spanish Energy Minister, has stated his belief that Spain's support mechanism for renewable energy producers should be 'phased out', and argued in favour of a system of green certificates. How the changes will influence the business scenario and what will it mean for Iberdrola? What are the best ways to sponsor renewables and what will happen if the premium is cut down? And how much is the influence of the premium system on every participant of the business scenario?

Stakeholders. A business idea is initiated by some parties called stakeholders. In the electricity business there are many stakeholders (enterprises and people representing these). In this specific case the following stakeholders are distinguished. Iberdrola group, the former electricity utility, consists of Iberdrola Generation, the producer, and Iberdrola Distribution, the distribution system operator, which is monopolistic in the region. Another stakeholder is the Spanish government, which subsidizes different kinds of renewable generation.

Goals. Goals of every stakeholder somehow influence the business case, and understanding of, and reasoning about goals of stakeholders is essential for the creation of the sustainable DG business model.

In the electricity sector all the goals can be classified as an environmental, market development, and quality and efficiency goal. Environmental goals are those contributing to generation of less emissions, the market development goals can be associated with acquisition of new customers, new technology, and new services, and the quality and efficiency goals improve the performance and security of the electricity system.

First of all, a stakeholder has some long-term goals to achieve. These long-term goals are called strategic goals. In the Spanish case, as a result of fulfilling the Kyoto obligations, the Spanish government has a long-term environmental goal to reduce environmental emissions. The Iberdrola group, the initiator and the potential owner of the renewable generation facilities, being initially the centralized utility, invests into the small-scale renewable generation, because the long-term market development goal is to increase market share.

A stakeholder has also some short-term goals, called operational goals. As stated in the business idea description, Iberdrola Generation is going to make profit by obtaining additional payment for generation electricity from renewable sources; in other words, Iberdrola Generation has a short-term goal to Benefit from generating subsidized Renewable Energy Source (RES) electricity. Short-term goals can be also thought as incentives of a business scenario. In this case there are regulatory incentives present, namely the obligation of the Distribution System Operator to purchase all the energy produced from sources, complying with Special Rules, and a premium paid for “Special Rules” generation.



Page

25

Unlike strategic goals, the operational goals are strongly connected to value activities a stakeholder performs. The goal “benefit from generating subsidized RES electricity” is related to the generation activity (renewable producer). The goals “pay premium for “Special Rules” generation” and “oblige DSOs to purchase all the energy produced from “Special rules” sources” is related to the regulation activity (Spanish government). Finally, the Iberdrola Distribution, which carries out distribution, has short-term goal “purchase all the energy produced from renewable sources”. All the mentioned operational goals are classified as environmental, because they aim to reduce environmental emissions.

Technology. In this case it is evident that to reach the strategic goals the producer should generate electricity with technology entitled to receive subsidy: the technology that complies with “Special Rules” of the Spanish law. According to the law, the subsidy is given to hydro, wind, biomass, photovoltaic, waste generators, and some other types of generation. Other technological characteristics to be taken into account in this specific case are emissions, since the subsidy is delivered only to those technologies having low or zero emissions, and capacity, since the amount of subsidy depends on the size of the generator.

2.2.2 Value model

After the goals of stakeholders are more or less clear, value models have to be built. Actually, there are two tracks to take. We can focus on the overall picture of the business idea rather than on the business of the particular actor, and take the market driven track. Or we take an actor driven track to evaluate the performance of a specific key actor, which in our case is a producer investing in the renewable technology. From the modelling perspective these two tracks are rather close, so we can use the same value model with minor changes for both tracks.

The model (see Figure 2) represents generation of electricity by a renewable generator, which is installed into the distribution grid. We follow the scenario path to explain the business model.

The final customer is any legal or natural person buying electricity for its own use. The scenario starts when a final customer wants to purchase electricity in return for a fee.

The distribution company performs the transportation of electricity on medium-voltage and low-voltage distribution systems, and the physical delivery of electricity to the customers. In addition to that, the distribution company performs sale and procurement functions (electricity purchasing and selling). The distribution company is a natural monopolist that serves one geographic region. There are a number of these companies in a country, each serving their own region, so Figure 2. shows an additional shaded distribution company. Note that both distribution companies cannot be seen as a market segment, because otherwise the customer could select a specific distribution company, which is not the case. The distribution company delivers electricity to the final customer, and it directly receives the electricity retail fee in return (see annotation (a)).



Page

26

Distribution company 2

Renewable producer

Distribution company1

Final customer

Market Operator

Electricity

RESpremium

Electricityfee RES

subsidy

RESgeneration Legal

Obligation

TotalRES taxes

Producer

Electricityfee

Electricity

Electricityretailfee

Electricity

(a)

(b)(c)

(e)

Transmissionoperator

Transmissionfee

Transmission

capacity

(d)

(f)

(g)

(h)

Figure 2. In this scenario the distribution company is forced to buy all the electricity generated by renewable producers, resulting in a situation where the amount of

electricity generated is always equal to the amount of electricity sold. Moreover, the price of electricity bought from the renewable producer is also fixed. The abolishment

of the fixed electricity price and obligation to buy all the electricity from renewable sources can render the renewable production business unprofitable.

Following the scenario path, we can see that the path splits into two sub-paths (see Figure 2, annotation (b)). The left sub-path presents that energy must be obtained, either from a renewable producer (Figure 2, annotation (c)), or from a traditional producer (exploiting non-renewable energy, (Figure 2, annotation (d)). The right sub-path shows that for all energy exchanged between customer and the distribution company, a Renewable Energy Source (RES) tax has to be paid to the market operator (Figure 2, annotation (e)). The market operator is in charge of managing the wholesale energy market including coordination of sales. He builds a fund that can be used to pay producers of renewable energy a premium for generating such energy. If we assume that the distribution company decides to obtain renewable energy, the scenario continues in the direction of annotation (c), and again splits into two sub-paths. The leftmost sub-path, (Figure 2, annotation (f)) models that renewable energy is bought, and the renewable energy producer receives a fee and premium for the energy. The distribution company obtains the premium fee to be paid from the market operator, as can be seen from the sub-path annotated (g). In sum, Figure 2 clearly shows that all energy funds renewable energy, so that the in principal more expensive renewable energy can be offered for the same price as conventional energy. It is important to stress that the energy company in this specific case was not able to articulate and explain this business model without our graphical technique, let alone to reason about the model.

Distribution of electricity involves a long-distance high-voltage network, called the transmission grid, and a short distance medium voltage network, typically serving a limited geographical area, and called the distribution grid. DG producers operate small-scale



Page

27

generators, which are plugged into the distribution grid directly, and do not need a long distance electricity transmission grid. From Figure 2, it can be seen that both renewable and traditional producers require access to the energy transmission network. So basically we do not show distributed generation here, because there is no difference in pricing electricity delivered by DG so there is no need to model DG separately.

The distribution company is forced by law to first exhaust all renewable energy connected to its distribution grid, and once exhausted it is allowed to buy other types of energy from regular producers. This is suggested by dashed lines, implying that first all scenario paths with solid lines should be executed.

The renewable producer’s profitability is strongly dependent on regulation, which establishes the RES tax for final customers and forces the distribution company to accept DG. If the RES premium is withdrawn, the distribution company will no longer pay premiums for renewables and the cost of "green" electricity will be equal to the cost of the electricity produced by the ordinary generator minus transportation fees. This will harm the business of the renewable producer, because its initial investments are usually high. Although this finding is consistent with that in many literature sources, our model provides a clear graphical picture of the situation.

2.2.3 Financial analysis

Evaluation of a business scenario answers the question whether a scenario is profitable for each actor involved. It is important for stakeholders to reason about profitability, and to do a sensitivity analysis. This contributes to a better understanding of the business idea, in this case from a profitability perspective. To do so, we (1) create profitability sheets for each actor involved in the value model, (2) ask actors to assign economic value to objects delivered and received, and (3) use evolutionary scenarios to determine effects of expected changes in the future that influence profitability.

2.2.3.1 Data

In these calculations we take a look at the Bask Autonomous region, and assume the generation facilities and data in this region only. The data about generation facilities in the Bask region are presented in the following table. The source is Red Eléctrica de España, "El Sistema Eléctrico Español - Informe 2001", available in http://www.ree.es/index_sis.html (only in Spanish)

Capacity Generation O&M total Premium Total premium MW MWh Euro/MW Euro/MW

h Euro

COMMON RULES producers

1 307 2 259 000 32 038 740,00 0,00

Fuel-gas 919 1 015 000 17 760 000,00 0 0,00 Imported coal 217 1 099 000 7 194 600,00 0 0,00 Fuel 66 0 990 000,00 0 0,00 Other (Hydro) 105 338 000 6 094 140,00 0 0,00 Consumption for generation

-193 000

SPECIAL RULES 413 966 000 13 989 980,00 22 697 552,00



Page

28

Renewable Energy Sources

104 288 000 3 132 800,00 8 272 424,00

Hydro 43 123 000 1 434 180,00 29,46 3 624 072,00 Wind 24 86 000 933 100,00 29,46 2 533 904,00

Waste 22 43 000 430 000,00 21,34 917 448,00 Biomass 15 36 000 335 520,00 33,25 1 197 000,00

Non-Renewables 309 678 000 10 857 180,00 14 425 128,00 Natural gas 219 547 000 8 214 070,00 21,28 11 637 972,00 Refined gas 58 17 000 1 176 770,00 21,28 361 692,00 Waste heat 20 86 000 1 031 660,00 21,28 1 829 736,00 Fuel-gas-oil 12 28 000 434 680,00 21,28 595 728,00

SUM 1 720 3 225 000 46 028 720,00 22 697 552,00

The operational expenses of the TSO in 2002 were 195.297.000 €; in the whole Spanish system, the energy demand was 210.278 GWh (source: Red Eléctrica de España, the Spanish TSO). From the generation data we can see that in year 2001 3 225 GWh was generated in the Bask region. Extrapolating the costs, TSO operational costs for the Basque Country can be assumed to be 2.995.238 €.

The distribution company, which satisfied all the demand in the region, delivered 56.558.005MWh in 2002 areas in Spain, which means a cost of 10,50 €/MWh. Thereby, we can assume the operational expenses of the DSO in the Basque Country in 2001 to be about 33.862.500€.

According to the electricity tariff the electricity price, paid to the generator, is 15.57€/MWh - 46% of the total electricity price paid by customer; the rest is RES tax (16.50%), transmission fee (4.7%), distribution fee (20.1%), commercialising fee charged by supplier (1.9%), and other taxes and fees1 (10.8%). The price of electricity taken is 30.19 €/MWh (we did not include “other taxes and fees” in calculations).

2.2.3.2 Profitability sheets

Profitability sheets are constructed for each actor involved. A profitability sheet is constructed by following the scenario path. For every actor the incoming and outgoing objects are added to the profitability sheets, and then numerical values within common timeframe and measurement units are assigned.

An example of profitability sheets for the value model in Figure 2 is shown in Table 2. The first row of the table lists the headers of the column: Value Object In, Value in, Value Object Out, and Value Out. The second row names the actor, Final Customer, to be analysed. The

1 Other taxes and fees include: contract between REE and EdF (1,1%); costs of extra-peninsular systems (1,5%): since there is no location discrimination in electricity price, all the electricity purchases are charged a percentage to pay the over-cost of extra peninsular systems of Spanish islands and enclaves in Morocco (Ceuta and Melilla); costs of the Market Operator (0,1%), costs of the System Operator (0,1%); costs of the National Energy Commission (0,1%); stranded costs (3,6%): paid to non-feasible power plants to keep them in the system in order to guarantee the supply; nuclear moratorium (3,5%): paid to recover the investments of prohibited nuclear plants; nuclear fuel treatment costs (0,8%)



Page

29

third row names another actor, DSO, and in- and outgoing objects and their values (according to the headers in the first row) that this actor exchanges with the Final Customer. The remaining part of the table is structured in the same way, and lists all the actors presented in the graphical model. Every value object appearing in the profitability sheets also has a corresponding value object from the graphical value model. For the RES producer we not only specify data for all the market segment of RES producers, but also showed some specific producers (hydro, mass, biomass etc.) to be able to evaluate them separately.

The “crosses’ of the actor’s space notify total operational expenses of the actor. Total operational expenses are the sum of variable operational expenses and fixed operational expenses. Total operational expenses have to be included into the profitability sheet of the actor with outgoing value object “O&M fee” and ingoing value object “Total O&M”. The operational expenses for TSO, DSO, Producer and RES producers were calculated in the previous section.

Table 2. Profitability sheets.

Value Object In Value In Value Object Out Value Out Final Customers

DSO (Electricity) 97 370 041 Elect. retail fee 97 370 041,30

DSO FC Elect. retail fee 97 370 041,30 (Electricity) TSO (Transmission

capacity) Transmission fee 5 130 484,24

MO (Legal Obligation) Total RES taxes 18 011 274,46 DSO (O&M) Total O&M

expenses 33 862 500,00

Conventional path Producer (Electricity) Electricity fee 35 172 630,00

Renewable Path MO RES subsidy 22 697 552,00 (RES generation) RES producer (Electricity ) RES premium 22 697 552,00

Electricity fee 15 040 620,00 TSO

DSO Transmission fee 5 130 484,24 (Transmission capacity) TSO (O&M) Total O&M

expenses 2 995 238,80

MO DSO Total RES taxes 18 011 274,46 (Legal Obligation)

Renewable Path DSO (RES generation) RES subsidy 22 697 552,00

RES Producer Renewable Path

DSO Electricity fee 15 040 620,00 (Electricity) Premium 22 697 552,00

RES producer (O&M) Total O&M expenses

13 989 980,00

SOME SPECIFIC RENEWABLE PRODUCERS



Page

30

Hydro DSO Electricity fee 1 915 110,00 (Electricity)

Premium 3 624 072,00 Hydro producers

(O&M) Total O&M expenses

1 434 180,00

Wind DSO Electricity fee 1 339 020,00 (Electricity)

Premium 2 533 904,00 Wind producers


933 100,00

Refined gas DSO Electricity fee 264 690,00 (Electricity)

Premium 361 692,00 Refined gas producers


1 176 770,00

Producer Conventional path

DSO Electricity fee 35 172 630,00 (Electricity) Producer (O&M) Total O&M

expenses 32 038 740,00

To calculate profitability of each actor we sum up corresponding values of the incoming objects with values of outgoing objects (note, that values of outgoing objects is taken with “minus”). The result of profitability numbers for each actor is shown in Table 3.

Table 3. Profitability for each actor.

Producer RES producer MO TSO DSO Final Customer 3 133 890,00 23 748 192,00 -4 686 277,54 2 135 245,44 -9 847 467,39 0,00

Producer. The profitability of the producer is positive.

RES producer. The profitability of the RES producers is positive, which means that in total, RES producers have profit. If we look specifically at some types of renewable producers in the region (see Table 3), then hydro and wind have a positive cash flow, while refined gas producers have negative cash flows, which means that their expenses are not covered.

Table 4. Profitability for specific RES producers.

MO. The incoming value objects for the market operator are RES taxes, and outgoing objects are subsidies. The total profitability of the MO is negative, which means that there is more money paid for subsidies than collected form RES taxes. The total amount of RES taxes, paid both for RES electricity, and traditional electricity, does not cover subsidy paid to RES producers.

TSO. The profitability of TSO is positive.

DSO. The DSO has a negative cash flow, which means that DSO has higher operational and maintenance expenses than the money it receives from final customers. If we take a close look at value exchanges, the DSO only provides a transporting mechanism for subsidies; it

Producers Hydro Wind Refined gas Profitability 4 105 002,00 2 939 824,00 -550 388,00



Page

31

receives subsidies from the MO and delivers to RES producers.

Final Customer. The Final customer has zero profitability. The Value in of the Final Customer is Electricity, and the value out is the Electricity retail fee. We assume that the final customer estimates the price of electricity as 30.19 Euro/MWh, which is equal for the electricity retail price. Further, if the electricity retail price increases (reduces), it will be higher (lower) than the electricity retail price estimated by the final customer, resulting in the negative (positive) profitability number for the customer.

2.3 Sensitivity analysis

The negative cash flows of some actors in the financial analysis in the previous section are the evidence that the business model does not bring profit to every actor involved, and, therefore, is not sustainable. In this section we perform sensitivity analysis to discover a sustainable business model. We can observe how the change of initial data will influence every party involved.

1. Market operator. One of the ways to make the profitability of the market operator positive, which means to remove the gap between RES tax paid and premium paid, is to increase the RES tax, paid by the customers. The other way - is to cut premiums. The first row of the table below is a null-scenario. The second row shows how the cash flow of the actors changes when the RES tax is increased till 7.04 Euro/MWh, and the third row displays the situation when the premium paid to wind and hydro generators is zero.

Premium for wind

Renewable producers

MO Final Customer

Hydro Wind

Null-scenario 23 748 192 -4 686 278 0 4 105 002 2 939 824 Increase RES tax

23 748 192 6 448 -4 692 725

4 105 002 2 939 824

Cut wind and hydro premium

17 590 216 1 471 698 0

480 930 405 920

2. Refined gas. The cash flow of the refined gas producers can be made positive by increasing the production. As the table below indicates, in case the production with refined gas increased till 36000 MWh a year, the cash flow becomes positive. However, it also influences other actors. In particular, it increases expenses of the market operator, and it increases the expenses of DSO.

Generation with refined

gas

Renewable producer

MO TSO DSO

Refined gas

17000 MWh (Null-scenario)

23 748 192 -4 686 278 2 135 245 -9 847 467 -550 388

36000 MWh 24 299 876 -4 984 409 2 147 825 -9 905 483 1 296

To achieve the positive cash flow both for the market operator and for the refined gas



Page

32

producer we combine these two scenarios. First, the combination of increased RES tax and increased production of refined gas will give the following cash flows:

Renewable producer MO TSO

Final Customer DSO Hydro Wind

Refined gas

24 299 876 505 709 2 147 825 -5 498 933 -9 905 483 4 105 002 2 939 824 1 296

The RES tax here is increased till 7.28 Euro/MWh, because only then the profitability of the MO becomes positive. Second, the combination of the increased refine gas production with the cut wind and hydro premium will give the following results:

Renewable producers MO TSO

Final Customer DSO Hydro Wind Refined gas

18 141 900 1 173 567 2 147 825 0 -9 905 483 480 930 405 920 1 296

Both of the solutions delivered positive cash flows for the MO and the refined gas producers. In the second case, the profitability of the MO is higher than in the first case, which means that probably, more premiums can be paid. The cash flow for the renewable producers is reduced in the second case, however, it is still positive. Also, in the first case the situation is improved for by increasing the fee paid by the Final Customer. Still, the DSO has negative cash flows: as we have seen, DSO’s profitability does not depend on the premium system, rather on financing of DSO and its operational expenses; to achieve the positive DSO profitability, other measures than the regulation of premium system are required, for example, other taxes are paid to DSO to cover its expenses.

2.3.1 Investment analysis

As was shown in the sensitivity analysis, the RES producer still makes profit by generating with wind turbine. However, it is known that the wind turbine requires huge initial investments, and the premium system was introduced to attract investors to the renewable generation business.

To evaluate the feasibility of scenario from the investor viewpoint, in addition to the e3value modelling we utilize some financial analysis instruments, namely net present value (NPV) and internal rate of return (IRR).

The Net Present Value criterion is an important assessment, which calculates the expected net monetary gain or loss from a project by discounting all expected future cash flows and inflows to the present, using some predetermined minimum desired rate of return. NPV is a very useful tool because it allows for a comparison of current expenses to undertake a project versus the potential benefits, in this case revenues that the project will yield sometime in the future.

The internal rate of return is the rate of interest at which the present value of expected cash inflows from a project equals the present value of expected cash outflows of the project. IRR, on the other hand, computes a break-even rate of return. It shows the discount rate below which an investment results in a positive NPV (and should be made) and above which an investment results in a negative NPV (and should be avoided). It's the break-even



Page

33

discount rate, the rate at which the value of cash outflows equals the value of cash inflows.

An important task for the calculations above is the analysis of incoming and outgoing flows. The value models, developed before are useful in identifying those.

We will calculate the net present value and internal rate of return for investment in the wind turbine. First, we assume the situation, when wind producer receives a premium of 29.464 Euro for 1WMh of electricity generated. As an example we took the wind turbine with capacity 900 kW with energy output 2 250 MWh/year; The initial investment to be made is 1 058 400 € (taking into account Added Value Tax Discount). The profitability sheet for this particular electricity producer looks like the following:

Wind turbine, capacity 900 kW, output 250 MWh-year DSO Electricity fee 35 032,50 (Electricity)

Premium 66 294,00 RES producer (O&M) Total O&M

expenses 25 200,00

According to this profitability sheet, the total outcome flow is 76 126,50 €. Assuming that the useful lifetime of the generator is 20 years we calculated the following numbers:

Discount rate 7% Discount rate 4% Discount rate 3% Present value 806 485 € 1 062 619 € 1 132 570 Net present value -251 914 € 4 219 € 74 170

A company evaluating this investment using cash flow discounted at 7% would compute a negative NPV of -251 914 €, which is not a spectacular result, advising not to invest in the project. But if the company evaluates the same investment at 4%, the project has a present value of only € 4 219, essentially just breaking even, and at 3% the project’s present positive value is € 74 170. The IRR is a fraction of a percentage point above 3.5%; at that discount percentage, the investment's NPV is zero.

As the investment analysis shows, even the subsidy of more than 100% of initial price does not make the wind generation attractive for investments. Therefore, we will not investigate the attractiveness of investments into the wind turbine for the less favourable situation with the premium withdrawn. According to the analysis above, the suggestion can be made for policy makers:

1. Not to cut the premium for wind producers, but rather look into alternative scenarios, e.g. the scenario of increasing RES tax, OR

2. Cut the premium, but offer favourable schemes for investors

For the wind generation investors:

1. IRR is 3.5% for a situation when premium is paid; IRR will be lower if the premium is withdrawn

2. Take a look at another sponsoring scheme for wind energy: currently in Spain there is a subsidizing scheme, according to which the producer pays a fixed price of 62.8 €/MWh (instead of 45.03 €/MWh, which was assumed in this analysis). Then the IRR is about 9%, which indicates that investments are feasible for any rate below 9%.



Page

34

2.3.2 Discovering new value models

The model presented in Figure 2 neglects the introduction of a resale role in many European countries. The reseller will supply energy to final customers, and in turn buys energy from others. To understand this situation, we built the model shown in Figure 3. It shows a wholesale electricity market managed by the market operator (MO), where producers sell electricity via a pool to suppliers of electricity. This model does not show elements of distributed generation yet.

Figure 3 The model of the deregulated market. The electricity is sold via the pool, organized by the market operator2. Final customers have a possibility to choose a

supplier. Note that the model shows only the exchange of economic valuable objects between actors, and not the physical flow of electricity. Physically, the producer is

placed into the transmission grid, represented by TSO.

The model shows deregulation by introducing supplier actors. Final customers can choose an electricity supplier, whereas the business model explained in the previous section contains no choice for a specific supplier. An important consequence of deregulation is that

2 Note, although trading via the pool is becoming a common practice, the major part of electricity is still traded via bilateral contracts between Producer and Supplier, or Producer and Final Customer. For example, in Norway only about 30% of the whole flow is traded via NordPool; the rest is traded bilaterally, based on constant price contracts or floating prices linked to the spot price. Different schemes of trading electricity are described later in section 3.5.2.



Page

35

the party who normally would distribute the electricity to the final customer (the distribution company in Figure 2), does not sell the electricity anymore to the final customer, but rather provides a physical distribution service only (see the distribution system operator in Figure 3). Selling is now done by a supplier, whose main role is to buy electricity as cheaply as possible and to sell that energy to final customers.

The business model in Figure 3 makes no exceptions for renewable energy. Producers are treated equally. Since renewable producers are not able to compete on costs with the big power plants, (because usually the technology requires significant investments, and even high maintenance costs), alternative business models for renewables must be explored. One such a business model we introduce in the next section.

2.3.2.1 Business model: Distributed generation to solve shortage in distribution capacity

It is difficult to say when DG will become economically attractive. As stated in deliverable D1.2 and D2.1, DG may be economically attractive as a replacement for centralized power plants only in scenarios with system constraints, such as lack in the capacity in the distribution network. In such a case, there are insufficient means to transport electricity from the long distance transportation network to final customers via a short distance distribution network.

The idea of the business model presented in Figure 4 and 7 is to delay a necessary distribution grid upgrade by installing a distributed generator, which delivers electricity directly to final customers. If the physical location of the generator is strategically chosen (in practice close to a substantial amount of consumers), parts of the distribution grid can be avoided for transportation of electricity, and consequently an upgrade of this grid can be postponed.

By following the scenario path, we can see how this idea works. The scenario starts with a final customer who wants to obtain electricity in return for a fee, and continues into alternative directions. First, if there is sufficient distribution grid capacity, the scenario path goes as presented in Figure 4. Electricity is obtained from a market operator, who in turn obtains electricity from a producer. Additionally, the supplier buys distribution capacity from an operator and pays a fee for this. In this model, we assume this producer is a not-renewable electricity producer because the scenario path stops at the producer. There are variations on this model possible, but this is matter of design. To highlight such design choices is one of the goals of using our e3-value description technique.

Second, if there is insufficient grid capacity, the scenario path is as stated in Figure 5. The supplier buys distribution capacity from an operator, but now the operator is not capable of delivering this capacity. There is however a renewable energy producer whose site is physically located near the final customers who need the electricity. This producer can deliver the electricity by using only a portion of the distribution grid. Moreover, we assume that this specific portion has no capacity problems. This situation is modelled by stating that the renewable producer delivers to the distribution operator virtual grid capacity (or the avoidance of a need for grid capacity). At the same time, the regular electricity producer cannot deliver its electricity anymore (at least the part that now will be provided by the renewable electricity producer). In this specific model the producer agrees not to generate the electricity, but to buy electricity from the renewable producer: He buys the DG electricity and pays the DG electricity fee in return. There are other solutions for this, but again this is



Page

36

a matter of business design choices, which we want to represent and reason about.

Figure 4. The situation without distribution grid capacity problems.



Page

37

Figure 5. The situation with distribution grid capacity problems.

There are several conditions key to the success of this scenario. First, the producer has to agree to buy electricity from the distributed producer in case of distribution grid capacity problems. If the producer agrees, all the amount of the DG electricity has to be traded. If not, then the surplus of renewable electricity (which is not needed for solving distribution capacity problems) will flow into the transportation (long distance) grid. This requires some agreement to be arranged between the distribution system operator and each producer about the guarantee that the renewable electricity will be sold. Furthermore, if the electricity fee is lower than a renewable electricity fee, the producer trades at a loss and its losses have to be recovered. Finally, only controllable technology can be deployed in this scenario. For example, wind turbine systems, which “rely upon the variable and somewhat unpredictable wind”, are renewable, but uncontrollable for continuous power needs, and therefore, they cannot be exploited in geographical regions with a too low probability of wind.

We should stress even more that the model in Figure 4 and Figure 5 is not implemented in any country, and is taken as an example. The general idea of using DG to solve the capacity problem is correct and was often talked over during BUSMOD project meetings. However, as one can notice from the graphical model, the implementation of the scenario is not so simple, because one has to take into account the regulatory system of a particular country.



Page

38

In Norway, for example, the proposed scenario may not succeed due to lack of incentives for Producers: a Producer itself does not have any economic or regulatory incentive to resolve congestions in the distribution grid, and probably it is not possible physically, since Producers have day-ahead generation schedule. Therefore, at least in Norway, it would be more logical if DSO itself will try to use DG for reduction of net loads. But again, appropriate regulation incentives for DSOs to support Distributed Generation in their concession areas have to be developed.

References

D2.1(2002) Ignacio Garcia-Bosch. D2.1: Arising Scenarios on Distributed Generation Business. BUSMOD 2002

Gordijn (2002) Jaap Gordijn, Value-based Requirements Engineering - Exploring Innovative e-Commerce Ideas. PhD thesis, Vrije Universiteit, Amsterdam, NL, 2002. Also available from http: //www.cs.vu.nl/~gordijn/

Horngren and Foster (1987) Charles T. Horngren and George Foster. Cost Accounting: A Managerial Emphasis, sixth edition. Prentice-Hall, Englewood Cliffs, NJ, 1987.

Kartseva, Gordijn, and Akkermans (2003) Vera Kartseva, Jaap Gordijn, and Hans Akkermans, A Design Perspective on Networked Business Models: A Study of Distributed Generation in the Power Industry Sector, BLED, Slovenia 2003

Red Eléctrica de España (2001) Red Eléctrica de España, El Sistema Eléctrico Español - Informe 2001, Spain, 2001 available in http://www.ree.es/index_sis.html



Page

39

Chapter 3 DG Business models

3.1 Introduction

In this chapter we introduce the elements of a DG business model. First, the goals (section 3.1.1) a specific business model tries to satisfy need to be clear. To reach a goal, we need a specific kind of DG technology. Additionally, to reach a goal with a specific kind of DG technology, we need a business value model (section 3.1.3). Before we introduce these DG specific models in the coming sections, we briefly rephrase the elements in a more generic way.

3.1.1 Goals

There are many stakeholders (enterprises and people representing these enterprises) in the distributed generation business. Each stakeholder has a set of goals with respect to a specific DG business case. These goals, which stakeholders may not always be in harmony and, in fact, very often conflict, as each party tries to adopt strategies to maximize their individual benefit. In contrast, the goals of stakeholders may be mutually beneficial, and therefore, their bundling can be favourable for a DG business case. In sum, understanding of, and reasoning about the goals of stakeholders is essential for the creation of a sustainable DG business model.

We distinguish two categories of goals. Firstly, there are strategic goals; these are goals on the long term (typically 5 to 20 years). Secondly, there are operational goals. These are goals on the short term (typically 1 to 5 years). They contribute to reaching a strategic goal and therefore can be seen as sub goals of strategic goals.

According to this classification, we have a goal hierarchy, which includes goals, specific for the DG domain. This goal hierarchy is concisely presented in Appendix A. The goal hierarchy was built on various sources of information, including D1.2, D2.1, and D2.2. We cannot claim that this hierarchy covers all the goals possible to appear in the DG domain, but, at least, it covers the goals, derived from the business scenarios described in the BUSMOD project, namely in D1.2, D2.1, and D2.2. For details about the goal hierarchy see further sections of this chapter.

3.1.2 Technology

Knowing the goals for a specific DG-case, the next step is to select the appropriate DG technology (note that sometimes you may want to start with a particular technology and then want to select the goals it can contribute to and the related value activities). Although many factors can influence the DG business, the technology remains crucial for the success of the business scenario, and, therefore, has to be taken into account from the very first stage of the process of business model development. Some of the DG technologies offer high efficiency, but emit a large amount of pollutions; others, being environmental friendly, are not



Page

40

cost-efficient; and others are not suitable for an application because of the lack of continuous output. With so much to consider, it is difficult to determine which technology will deliver the best output of the scenario and achieve both operational and strategic goals.

We provide a classification of the distributed generation technologies. We do not provide a technology overview, but rather we describe the characteristics of the technologies to be considered when developing the business model. The technology characteristic classification can be used to give preliminary requirements for DG technology in the business case. Furthermore, technological requirements can be derived from the goals of the business case. For example, the requirement to use technology with low emissions comes forth from the goal “Reduce environmental emissions”. To facilitate the determination of the technological requirements, we have developed the Goal-technology checklist (see Appendix B). For detail about the technology classification see sections 3.3 of this chapter.

3.1.3 Business Value Model

To develop a business model of a case we use the e3value methodology. This methodology has been developed originally for exploration of innovative e-business cases, and is the foundation for the BusMod methodology outlined in this document.

The e3value methodology is a conceptual modelling approach with clearly defined modelling constructs, originally with the aim to design and to reach common understanding about an e-business model. Conceptual modelling is an approach that stems from computer science to specify rather formally required functionality of information systems. Since the development of such systems typically involve many stakeholders, it is important to create a common understanding of the functionality to be developed, and reaching such understanding is the aim of conceptual modelling.

The e3value approach offers a number of interrelated core concepts, also called an ontology, which are used to build a semi-formal conceptual (e-)business model. The approach is unique because we focus on the concept of economic value as a central conceptual modelling construct. As such, we employ a rigorous conceptual modelling approach known from computer science but we borrow terminology from business science.

A conceptual value modelling approach has the following advantages. Firstly, it facilitates, by clearly articulating the value proposition, in reaching a better shared understanding and agreement between actors on a service or product to be offered, rather than using a ambiguous free text representation of the model. As we will show, we are capable to represent the heart-beat of a non-trivial e-business value model with just a few pictures, which can easily be communicated by stakeholders and have a clear meaning. Secondly, our technique allows for evaluation of a business value model. Evaluation assesses whether the business model is profitable, or increases economic utility, for all stakeholders involved. The intention of evaluation is not to give precise calculations about profit to expect, but more to build confidence in the commercial viability of the e-business model. To increase confidence, we exploit what-if scenarios, which evaluate an e-business model for expected changes (e.g. economic oriented) in the future. Such evaluations, however, require a clearly articulated e-business model, rather than an ambiguous business idea. The e3value methodology is described in more detail in Chapter 5.



Page

41

3.1.4 Financial Model

We use a conceptual e-business value model not only to create a common understanding of the e-business idea amongst stakeholders, but also to evaluate the economical feasibility of an e-business idea. We call this the evaluation of the business idea, because it is based on an assessment of the value of objects by actors. Feasibility is in reach if all actors involved are able to make profit or increase their economic utility with an e-business idea. Again, our technique for determining feasibility is a light weight approach, and focuses on building confidence that an e-business idea is of interest for the actors involved, rather than offering a precise calculation of all profits. Our e-valuation approach consists of the following steps:

1. Creation of profit/utility sheets for all actors, and/or value activities;

2. Determination of a valuation scheme for each actor;

3. Evaluation of what-if scenarios.

The e3value methodology is described in more detail in Chapter 5.

3.2 Value activities in a nutshell

Because value activities are a key element in the DG business modelling methodology we start with a short explanation of specific DG value activities.

Generally, a value activity can be defined as a collection of operational activities, which can be assigned as a whole to actors. A value activity must yield profit or should increase economic value for the performing actor. In this paragraph we will describe the possible value activities for the DG domain. For now, we will restrict these descriptions to a simple explanation; in section 3.5.1.2 we will discuss all value activities in detail.

The deregulated electrical sector can be divided into the following activities:

• Electrical System Regulation

Electrical system regulation is the overall control of the electrical system. Its targets are guaranteeing a fair operation of the system, for all actors involved in it. To accomplish this, laws, rules and standards should be made.

• Policy making

Besides regulation, policies are necessary for the proper functioning of the electricity system. With policies, the actor who performs this activity, can stimulate or impose specific behaviour to actors.

• Trade

Trade is about buying electricity and reselling it for a higher price. It can be done by any actor, the most representative actor is the wholesale power exchange.



Page

42

• Network management

Network management is the technical operation of the system to ensure the continuity and security of the electricity supply, co-ordinating production and transmission systems.

• Generation

Generation is the production of electricity.

• Transmission

Transmission is the transport of electricity on the high-voltage interconnected system with a view to its delivery to final customers or to distributors, but not including supply.

• Distribution

Distribution is the transport of electricity on medium-voltage and low-voltage distribution systems with a view to its delivery to customers, but not including supply.

• Supply

Supply is the sale of electricity to customers.

• Consumption

Consumption is the final use of electricity.

• Manufacturing

Manufacturing is producing and selling equipment for generation of electricity.

• Leasing

Leasing is providing another actor the right to use some sort of equipment in exchange for a payment agreed in a leasing contract.

• Grid Balancing

Grid balancing is balancing the total power provided to the network with the total power consumption.

• Energy efficiency

Energy efficiency is providing services and/or equipment to reduce the total amount of consumed energy.

• Aggregation

Aggregation is combining the load or supply of multiple final customers in facilitating the sale and purchase of electricity, transmission, and other services on behalf of these customers.

• Metering



Page

43

Metering is the metering of the amount of electricity the consumers consume.

• Fuel Supply

Fuel Supply is the supply of this fuel.

• Heat Supply

Heat Supply is the supply of heat.

• Market management

Market management is the process of accepting bids for energy production and consumption, matching supply and demand and assigning contracts to the participants. Market management is about managing the wholesale energy market (short and long term) and the organisation of the power exchange (pool). It is a separate value activity, and does not include the trade of electricity, which is the Trade activity.

3.3 DG Goal hierarchy

There are many stakeholders (enterprises and people representing these) in the distributed generation business. Each stakeholder has a set of goals with respect to a specific DG business case. These goals stakeholders may not always be in harmony and, in fact, very often conflict, as each party tries to adopt strategies to maximize their individual benefit. In contrast, the goals of stakeholders may be mutually beneficial, and therefore, their bundling can be favourable for a DG business case. In sum, understanding of, and reasoning about the goals of stakeholders is essential for the creation of the sustainable DG business model.

Goal modelling is a widely used technique in the software requirements engineering (Anton (1996), Leiter and Lamsweerde (2002) ). In requirements engineering, goals provide a rationale and drive the elaboration of requirements that put them into operation, and provide criteria against which the requirements are validated. By adopting a goal-oriented thinking for DG business modelling we aim to facilitate the development and analysis of DG business models.



Page

44

Profit Electricity consumption

Generate and sell electricity

Supply electricity

Distribute electricity

Provide efficient system functioning

Provide metering services

Supply DG equipment

Lease DG equipment

Goals of activities

Market development goals

Environmental goals

Efficient market functioning

Strategic Operational

Quality and efficiency goals

Goals of business model

Figure 6. Strategic and operational goal hierarchy got distributed generation.

Goals can be classified into two categories. Firstly, there are strategic goals; these are goals on the long term (typically 5 to 20 years). Secondly, there are operational goals. These are goals on the short term (typically 1 to 5 years). They contribute to reaching a strategic goal and therefore can be seen as sub goals of strategic goals. Goals are concisely presented in Appendix A.

3.3.1 Strategic goals

Strategic goals can be classified into Market development goals, Environmental goals and Quality and Efficiency goals.

Market development can be associated with acquisition of new customers, new technology, and new services. The necessity of introducing this type of goals is e.g. existing market deregulation, which brings plenty of business opportunities. Examples of market development goals are “Increase market share”, “Enter the heat business”, or “Enter the electricity DG business”. It is difficult to predefine market development goals, because they are specific for each business case.

Environmental goals are about the improvement of the environment. They reflect societal goals to reduce pollution and to prevent exhaustion of fuel. The environmental goals can be, for instance, “Reduce environmental emissions” or “Reduce use of primary fuel”. The typical characteristics of a business model having environmental goal will be application of low-



Page

45

emitting technologies and financial support for “green” electricity.

Quality and efficiency goals aim to improve quality and efficiency of the system. The quality and efficiency of the electricity system first of all considers quality and efficiency of different parts of the system, such as physical services, or market management services. Therefore, the quality and efficiency goals are about the improvement of some activity or a bundle of activities.

Table 5. Strategic goals description.

Goal hierarchy Description Market development Can be associated with acquisition of new

customers, new technology, and new services.

S1.1 Enter new business An actor/actors want to start some business in the electricity sector; it implies a new player to enter the market

S1.2 Increase market share An actor/actors have some business in the electricity sector, but they want to extend it by, for example, providing new services or investing in new technology

S1

S1.3 Long-term sustainable development An actor/actors aims to implement scenarios with a perspective of a long term sustainable development; it also some implies environmental goals

S1.4 Minimize costs of infrastructure investments Saving is crucial in this case; such scenarios as “DG instead of grid upgrade” or “Local producer” for remote areas. Often goes with quality and efficiency goals.

S1.5 Smoothen the electricity price fluctuations Scenario wants to provide measures to avoid price difference during different time periods

… Other market development goal(s) Environmental goals Implies a scenario that contributes to the

improvement of the environment S2.1 Reduce environmental emissions Reduce (CO2) emissions of generation; often

implies renewable technology

S2

S2.2 Reduce use of primary fuel/dependence on primary fuel

Implies another technology with a fuel that is easier to deliver or is less expensive

S2.3 Promote use of renewable energy Implies some regulatory schemes aimed to promote renewable energy sources

S2.4 Maximize output of DG environmental benefits

Implies scenario that uses DG because of its environmental benefits

… Other environmental goal (s) S3. Quality and efficiency To improve quality and efficiency of the

electricity system; often includes load management, network management, grid upgrade, etc.

S3.1 To improve facilities To improve security by means of new technology

S3.2 To improve network management To improve security by means of network management

… Other quality and efficiency goal(s) QE



Page

46

3.3.2 Operational goals

Operational goals contribute to a strategic goal and are achieved by performing one or more value activities. In other words, performing a value activity contributes to an operational goal, which in the end contributes to a strategic goal.

Operational goals can further be classified as follows: (1) goals related to making profit, (2) goals related to consuming electricity, and (3) goals related to efficient market functioning.

3.3.3 Make profit goal

The make profit goal can be reached by performing one or more of the activities: generation, supply, distribution, consumption, metering, manufacturing, leasing, network management, grid balancing, aggregation, and market management. The following sub goals are related to making profit:

1. Generate electricity (goals of generation activity)

2. Supply electricity (goals of supply activity)

3. Distribute electricity (goals of distribution activity)

4. Trade electricity (goals of trade activity)

5. Supply DG equipment (goals of equipment manufacturing activity)

6. Lease DG equipment (goals of lease activity)

7. Provide metering services (goals of metering activity)

8. Efficient system functioning (Goals of various value activities such as network management, market management, aggregation, energy efficiency, etc).

a. Provide network management services (goals of network management, distribution, transmission, and balancing activities)

b. Represent groups of customers/suppliers/generators (goals of aggregation activity)

c. Provide Energy efficiency (goals of energy efficiency activity)

d. Provide market management services (goals of market management activity)

More detailed description of the above-listed goals and their sub-goals can be found below in Table 6.

3.3.4 Consume Electricity goals

The electricity consumption goal is needed to reflect interests of end-consumers. They may have the following sub goals:



Page

47

1. Reduce energy consumption expenses

2. Obtain a higher service quality

These sub goals have themselves sub goals, which are stated in Appendix A. More detailed description of the consume electricity goals can be found below in Table 6.

3.3.5 Provide market functioning goals

Market functioning goals correspond to goals (often of regulating authorities and government) to change market constellations and to implement strategic goals related to environmental impact. Sub goals defined in the goal hierarchy are:

1. Fair system operation

2. Fulfil Kyoto-like obligations

Value activities contributing to the goals are regulation and policy making.

3.3.6 Goal hierarchy of operational goals

Table 6 provides textual description of each goal defined in the goal hierarchy. As described above, goals in the goal hierarchy are classified into three categories: make profit goals, electricity consumption goals, and market functioning goals. Generation, supply, distribution, supply or lease equipment value activities are all performed to make profit, and, therefore, goals related to these activities are sub-goals of the goal “Make profit”. End consumers, or actors performing consumption activity may have goals that are placed as sub goals of “Consume electricity” goal. And, finally, regulatory authorities and policy makers, or actors carrying out regulation activity, may have goals placed under the goal “Provide market functioning”.

Of course, it is impossible to predict all the possible goals that may occur in the electricity business. The goal hierarchy in Table 6 below are derived from the scenarios described in deliverables 2.1 and 2.2, but it can be extended. To extend the goal hierarchy use the slot “Other goal(s)” that suggest placing a goal as a sub-goal into already existing structure. We suggest all the goals not listed in Table 6 to be placed as sub goals of goals marked with ‘*’.

Table 6. Operational goal descriptions.

Goal hierarchy Description O1. Make profit* The main goal of an actor/actors is to

make profit. These goals are achieved by performing such value activities as generation, supply, distribution, and supply or lease equipment.

G. Generate electricity* Goals of an actor who makes profit by generating electricity

G1 Increase generation efficiency The market development goal to increase efficiency of the generation (e.g. by using more efficient technology)



Page

48

Goal hierarchy Description G2 Benefit from generating subsidized RES electricity To make profit by generating electricity

with technology that is subsidized. An environmental goal if the technology that subsidized is renewable.

G3 Reduce emissions of generation An environmental goal to increase profit by generating electricity with fewer emissions. Unlike previous goal, in this case electricity is not subsidized, but there are some other reasons that make cleaner electricity more profitable (e.g. emissions penalties)

G4 Provide network management services An actor makes profit by generating electricity to provide network management services (such as demand and supply management or reserved capacity); Quality and efficiency goal

… Other goal(s) (G) Should be decomposed further is necessary

S. Supply electricity * Goals of an actor who makes profit by supplying electricity

S1 Sell reserved electricity in peaking hours To make profit by supplying electricity in peaking hours. QE goal, because it contributes to the quality and security of the system

S2 Benefit from green electricity incentives To make profit by supplying electricity generated by renewable sources (that’s why an environmental goal). Implies RES promotion schemes that involve supplier’s interest

S3 Avoid purchases in peaking hours The supplier tries to avoid purchasing expensive peaking-hour electricity

… Other goal(s) (S) Should be decomposed further is necessary

D. Transmit/Distribute electricity* Goals of an actor who makes profit by transmitting or distributing electricity

Reduce expenses An actor wants to reduce expenses D1.1 Reduce investments expenses An actor wants to reduce infrastructure

investments expenses

D1

D1.2 Reduce operational expenses An actor wants to reduce operational expenses

Improve transmission/distribution service quality An actor wants to improve quality of transmission/distribution. Quality and efficiency goal

D2.1 To reduce the need for peak reserved capacity

An actor wants to improve quality during peaking periods. Quality and efficiency goal

D2.2 Subcontract DG producer to avoid grid upgrade

An actor wants to avoid grid upgrade by using DG. Quality and efficiency goal

D2

D2.3 Reduce network losses An actor wants to reduce network losses. Quality and efficiency goal

… Other goal(s) (D) Should be decomposed further is necessary



Page

49

Goal hierarchy Description T. Trade electricity* An actor wants to make profit by trading

electricity. The typical actor: a power exchange

… Other goal(s) (T) Should be decomposed further is necessary

ES. Supply DG equipment* Goals of an actor who makes profit by selling DG equipment

ES1 Increase utilization of DG The market development goal of an actor wants to increase sales of DG equipment

ES1.1 Increase sales RES generators An actor wants to increase sales of renewable DG equipment; environmental goal

ES1.2 Increase sales New efficient technologies An actor wants to increase sales of more efficient equipment; quality and efficiency goal

ES1.3 Increase sales of ICT equipment for managing DG

An actor wants to increase sales of ICT products that will contribute to quality and efficiency of an electricity system

… Other goal(s) (ES) Should be decomposed further is necessary

EL. Lease DG equipment* Goals of an actor who makes profit by leasing DG equipment

EL1 Lease RES An actor wants to lease renewable DG equipment; environmental goal

EL2 Lease New generators An actor wants to lease more efficient equipment; quality and efficiency goal

… Other goal(s) (EL) Should be decomposed further is necessary

M. Provide metering services* A market development goal of an actor who provides metering services

O1-1. Efficient system functioning* The main goal of an actor/actors is to improve security and efficiency of the electricity system; This goal is achieved by performing such value activities as network management and market management, but also involves aggregation, energy efficiency, metering, etc.

NM. Provide network management services* An actor improves system efficiency by providing network management services; Quality and efficiency goal

Provide ancillary services for transformation grid An actor provides network management services on the level of transmission; Quality and efficiency goal

NM1.1 Provide voltage control An actor provides voltage control; Quality and efficiency goal

NM1.2 Provide frequency control An actor provides frequency control; Quality and efficiency goal

NM1

NM1.3 Provide black start (?) An actor provides “black start”; Quality and efficiency goal

… Other goal(s) (NM1) Should be decomposed further is necessary



Page

50

Goal hierarchy Description Provide active management of distribution grid An actor provides active management of

load in the grid; Quality and efficiency goal

NM2.1 Provide demand side management (DSM)

An actor provides demand side management by influencing the amount of electricity consumed

NM2.2 Provide supply side management (SSM) An actor provides supply side management by influencing the amount of electricity generated

NM2

NM2.3 Provide balancing services An actor provides balancing services to the transmission, distribution, or trade

… Other goal(s) (NM2) Should be decomposed further is necessary

A. Represent groups of customers/suppliers/generators * Market development goal of an actor who wants to represent groups of small generators, customers or suppliers as participants on the market. This goal should be decomposed further is necessary

EE. Provide Energy efficiency* An actor wants to provide energy efficiency services for on the level of final customer (see ESCO); Market development goal

EE1 Provide on-site load management (LM) services (passive measures)

An actor provides load management on the level of final customers. For example, preventing consumption during peaking periods. Quality and efficiency goal

EE2 Provide other energy efficiency services for customers

An actor receives revenue from saving energy expenses by influencing consumption of final customers; Targets increased efficiency

… Other goal(s) (EE) Should be decomposed further is necessary

MM. Provide market management services* A market development goal of an actor that provides market management: organizes a pool, matches bids, etc. This goal should be decomposed further is necessary

O3. Provide market functioning* Actors having this goal perform activities that guarantee secure and efficient market functioning; actors issuing laws and regulations

R. Guarantee a fair operation of the system* Goals to guarantee fair treatment of every market participant; market development goal

R1 Oblige distribution companies to connect RES An regulation about giving priority to renewable generators; environmental goal

R2 Oblige distribution companies to connect DG An regulation about giving priority to distributed generators; market development goal

R3 Oblige suppliers to accept RES A regulation that obliges suppliers to buy electricity from RES at first

R4 Oblige MO to give priority to RES A regulation that obliges a market operator to buy give priority to RES



Page

51

Goal hierarchy Description … Other laws and obligations (R) Should be decomposed further is

necessary K. Fulfil Kyoto obligations* Environmental goals related to fulfilment

of goals set up in Kyoto agreement; K1 Increase government investments in the RES/DG A goal to increase investments in RES

and DG to achieve environmental benefits;

K2 Develop RES promotion schemes A goal to develop promotion schemes K2.1 Tax exemption (Netherlands, Spain) Tax exemption like in Netherlands K2.2 Premiums system (Spain) Subsidizing schemes like in Spain K3 Organize “green” market A goal is to organize market for trading

green energy K3.1 ROC certificate market Create market for trading renewable

obligation certificates … Other goal(s) (K) Should be decomposed further is

necessary O4. Consume electricity * These are goals of final customers and

any other actors performing consumption activity

C. Reduce costs* Market development goal to reduce electricity bill

C1 Reduce consumption in peaking hours Reduce consumption of expensive peaking hours electricity; also targets overall efficiency and quality improvement

C2 Efficient use of heat Make the heat services more efficient (e.g. by using CHP); quality and efficiency goal;

C3 Avoid transmission and distribution costs Market development goal to buy electricity not being distributed (on-site generation);

C4

Perform on-site generation activity Market development goal to generate electricity by him/herself and this way to reduce electricity bill;

C5 Use energy efficiency services Buy energy efficiency services to reduce the bill

… Other goal(s) (C) Should be decomposed further is necessary

Q. Improve electricity service quality* It is necessary to improve quality and efficiency; in this case quality is crucial

Q1 Provide power in remote/isolated area Implies remote area that has no distribution grid; autoconsumption scenario; here technology is crucial

Q2 Provide back-up power within short timeframe A goal is to provide independent system that replaces the normal source if it fails; implies power critical devices

Q3 Provide back-up power with continuous output The same as Q1, but with a back up power system that can function for a long period of time

Q4 Provide continuous reliable power Because high power quality is needed, a DG technology is used as primary source of power

… Other goal(s) (Q) Should be decomposed further is necessary



Page

52

3.3.7 Relating strategic goals and operational goals

We already said that strategic goals and operational goals are related with each other. Strategic goals can be classified into Market development goals, Environmental goals and Quality and Efficiency goals. We said that operational goals have a more complicated classification structure, which was presented in Table 6. However, an operational goal can also be classified as Market development, Environmental or Quality and Efficiency goal, and thus, the connection between operational and strategic goals is established.

Operational goal

Strategic goal

Consumeelectricity

Provide marketfunctioning

EnvironmentalMarket

developmentQuality and efficiency

Make profit

Value activity

By building the hierarchy in this way we can say that all the operational goals having environmental type are sub goals of environmental strategic goals, and the same goes for market development and quality and efficiency goals. By introducing this relation between operational and strategic goals we introduce the relation of contribution: operational goals contribute to strategic goals. Table 7 exemplifies such a relation for the operational goals generate and sell electricity.

Table 7. Relating strategic goals with operational goals.

Operational (sub) goals Strategic goal

Generate electricity

1. Reduce generation costs Quality/Efficiency, Environmental Avoid emissions penalties Environmental 2.

2.1 Reduce emissions of generation Environmental



Page

53

2.2 Subcontract Renewable Producer Environmental 3. Benefit from generating subsidized RES electricity Environmental

It is important to identify the relation of contribution between strategic and operational goals. In the goal hierarchy, strategic goals are defined as long-term goals, and are not connected to any value activity, while an operational goal is a short-term goal related to some value activity that has to be done to achieve this goal. This way, by establishing the relation of contribution between strategic and operational goals we identify what short-term (operational) goals have to be achieved to reach certain long-term (strategic) goals.

3.3.8 Relation operational goals and value activities

To reach operational goals, value activities have to be performed. The activities are tied to operational goals. Table 8 shows relations between sub-goals of the “Make profit goal”, and associated value activities.

For example, the generation activity may contribute to the goals “Reduce generation costs” and “Avoid emission penalties”; the distribution activity positively influences the “Reduce network losses” or “Reserve grid capacity” goals.

Table 8. Relations between sub-goals of the “Make profit goal”, and associated value activities.

There are two heuristics that can be followed to identify activities performed to reach a goal:

1. The execution of an activity should contribute to satisfaction of the identified goal;

2. The execution of an activity should contribute to the utilization of DG.

For example, the goal “Reduce generation costs” announces the aim to make the generation

Goal Value activity Generate and sell electricity Generation Supply electricity Supply Distribute electricity Distribution,

Transmission

Provide metering services Metering Supply DG equipment Manufacturing Lease DG equipment Leasing Efficient system functioning

o Provide network management services Network Management o Provide grid balancing services Grid Balancing

o Provide customer-side load management services Energy efficiency

o Provide aggregation service Aggregation o Provide market management services Market Management o Provide energy efficiency services Energy efficiency



Page

54

more competitive by generating cheaper electricity, and it contributes to the DG, because it provides more efficient technology to achieve this goal.

The goal “Avoid emission penalties” is about making electricity cheaper by reduction of the part of the total electricity costs, corresponding to penalties. The contribution to DG is about reduced emission of generation, which can be provided by some DG technologies.

The goal “Generate subsidized electricity” improves the performance of the Generation activity, because the generator receives additional income from subsidies. The contribution to DG utilization is that some DG technologies can get the subsidy as well, and fulfilment of this goal will spread DG.

3.4 DG Technology Hierarchy

Knowing the goals for a specific DG-case, the next step is to select an appropriate DG technology (note that sometimes you may want to start with a particular technology and then select the goals whith the related value activities where it can contribute to). Although many factors can influence the DG business, the technology remains crucial for the success of the business scenario, and therefore has to be taken into account from the very first stage of the process of the business model development. Some of the DG technologies offer high efficiency, but emit a large amount of pollutions; others, being environmental friendly, are not cost-efficient; and others are not suitable for an application because of the lack of continuous output. With so much to consider, it is difficult to determine which technology will deliver the best output for the scenario and achieve both operational and strategic goals.

In this section we classify the distributed generation technologies. We do not aim to provide a technology overview, but rather to describe characteristics of technologies to be considered when developing a business model. By specifying parameters of characteristics it is possible then to approximately select the technology. We distinguish the following characteristics: (1) performance characteristics, (2) economic characteristics, and (3) size & availability characteristics.

In the following sections the technology characteristics are described. An explanation of each characteristic includes a definition of this characteristic, the scale taken to measure the characteristic, and the approximate ranges for the scale. An example of a characteristic is efficiency. With a scale we mean that a characteristic can take on a specific value, for example, High, Middle, or Low. With an approximate range for the scale we assign some ranges of the characteristic to be considered within the specified scale: for example, according to the scale High-Middle-Low we consider an efficiency to be High if it is more or equal 80%. The data used in examples are taken from the literature [D1.2], Little (1999, RDC (2002.

3.4.1 Performance characteristics

Efficiency

Definition. The sum of the electrical and thermal outputs divided by the total fuel heat input (LHV) for a generation unit.



Page

55

Scale High Good Low Range (%) More than 60% 40%-60% Lower than 40%

In some applications, such as generating electricity to provide reserved grid capacity or selling peaking power, the efficiency of the generator is important only when measured in part-time basis performance. In such a case the efficiency of technologies has to be compared with respect to their performance on part-time basis.

CO2 Emissions

Definition. The amount of CO2 emitted by the generator.

Scale High Middle Null Range (lb/MWh)

> 1000 About 1000 0

Start-up Time

Definition. The start time of the generator. The quick start-up time is decisive for some backup power applications.

Scale Very Quick Quick Slow Range Less then 10 sec Less then 1 min Hours

Thermal Output

Definition. The ability to use the technology to providing thermal output. Only some kinds of technologies that can be configured to operate as CHP generator can be utilized for heat generation.

Scale Possible Not possible Range Yes. Configuration for thermal

output is possible No. Configuration for thermal output is not possible

3.4.2 Economic characteristics

Total Expenses include Capital Expenses and Installation Expenses:

Capital Expenses

Definition. Expenses for all equipment in a complete generator set including the prime mover, generator, and packaging.

Installation Expenses

Definition. Expenses necessary to prepare a packaged unit for operation on a site. These expenses include engineering studies, permitting, interconnection, and set-up expenses.

Fixed Operation & Maintenance Expenses



Page

56

Definition. The portion of total Operating and Maintenance expenses that is independent of the hours of operation and capacity factor. These expenses generally consist of inspection and other annual/semi annual service expenses and those expenses that are a function of the number of hours that equipment operates rather than the amount of energy produced.

Variable Operation & Maintenance Expenses

Definition. Those operating and maintenance expenses that are directly proportional to the amount of energy produced. Expenses such as worn equipment replacement, consumables, disposal charges, etc. are generally variable.

Scale. With regards to the scale of estimation, the costs of technology can be low or high, if compared to other technologies available on the market. Expenses also depend on many factors, for example capacity.

The following table is an example of comparative costs of various technologies. The source is Assessment of Distributed Generation Technology Applications - a report prepared by the Resource Dynamics Corporation for the Maine Public Utilities Commission, February 2001.

Size Range (kW)

Capital costs ($/kW)

Installation Costs ($/kW)

Fixed O&M ($/kW – year)

Variable O&M ($/kWh)

Reciprocating Engines

Spark Ignition 30-5,000 300-700 150-600 5-15 0.007-0.01 Diesel 30-5,000 200-700 150-600 10-18 0.005-0.008

Dual Fuel 100-5,000 250-550 150-450 10-18 0.005-0.008

Turbines Microturbines Non-Recup.

30-200 700-1000 250-600 3-10 0.005-0.01

Microturbines Recup.

30-200 900-1300 250-600 3-10 0.005-0.01

Industrial Turbines

1,000-5,000 200-850 150-250 10-25 0.0025-0.004

Fuel Cells

PEM 5-10 4,000-5,000 400-1,000 3-10 0.01-0.04

Photovoltaic Acid

200 3,000-4,000 360 3-10 0.013-0.016

Renewable

Photovoltaic 5-5,000 5,000-10,000 150-300 - 0.001-0.004

Wind 5-1,000 1,000-3,600 500-4,000 0.01-0.02

According to the table below you can characterise Fuel cells and photovoltaic as having high total costs, and gas turbine as having low total costs. Since the costs strongly depend on other technological characteristics, the comparison of technologies expenses has to be made after all other desirable characteristics are determined. Other sources for assessment



Page

57

of the DG technologies costs are available in the Deliverable 1.2 Analysis of Distributed Generation Characteristics.

3.4.3 Size and availability characteristics

Unlike performance and economical characteristics, size and availability characteristics of technology do not describe the generator itself, but rather the performance of the generator in the specific environment. These characteristics are capacity, grid connection and predictability.

Capacity

Definition. The amount of electric power of a generating unit, generating station, or other electrical apparatus rated either by the user or manufacturer. Capacity is measured in W, kW, GW, etc. Building upon the D1.2 we classified the capacity of technologies as follows:

Scale Micro Mini Very Small Small Medium Large Range (kW)

5-10 Maximum 100

Maximum 1000

Maximum 10.000

Maximum 50.000

>50.000

We offered the classification below to bring some integrity to the estimation of capacity of power generation systems. However, some of these scales already exist and are used in countries. In D1.2 Table 2-1 (Summary of treatment renewable DG in Spain) gives an overview of a Spanish subsidizing scheme for each technology, where the subsidy of technology depends not only on the capacity, but also on the type of technology (e.g. hydro, wind, etc.). In the analysis of such subsidizing schemes the business modelling decision will be made not on the classification we provided in the table above, but on the classification, required by the government (in this case the Spanish government). This classification differs from the classification we offer, for example, the table below shows relations between classification we offer and the classification taken by Spanish government.

Scale Micro Mini Very Small

Small Medium Large

Range (kW)

5-10 Maximum 100

Maximum 1000

Maximum 10.000

Maximum 50.000

>50.000

Spanish system

-Very small sun -Small wind -Very small hydro

Small sun - Small CHP - Small hydro - Small waste

Medium sun, geothermal, wave, hydro, biomass, waste

Big sun, geothermal, wave, hydro, biomass, waste

Table 7-2 in D1.2 proposes the scale of hydropower stations used in Norway.

Scale Micro Mini Very Small Small Range (kW) 5-10 Maximum

100 Maximum 1000 Maximum 10.000

Norway system Micro power plant Mini power plant Small power plant



Page

58

Grid connection

Definition. High-, middle- or low-voltage connection of the generation unit to the grid. Also in some cases no grid connection is required.

Scale High voltage Middle voltage

Low voltage

Not required

Range (kW) The grid connection is not required

Predictability

Definition. The ability to predict the output of the generator.

Scale High Low Range The amount of electricity

generated is dependent on controllable resources, e.g. fuel

The amount of electricity generated is dependent on uncontrollable recourses, e.g. weather

3.4.4 Technology characteristics estimation

The fore mentioned characteristics should be assigned a value (e.g. the amount of electricity, which can be potentially generated by the specific DG technology). The value of characteristics can be assigned only with regards to some specific generator. For example, the figure below shows the characteristics for the Reciprocating diesel engine with the values assigned:

Table 9. An example of technological characteristics for the Reciprocating diesel engine3.

Technology: Reciprocating diesel engine

1 Efficiency 85-90% High

2 CO2 Emissions 1-8 g/kWh High

3 Start-up Time 10s Very Quick

4 Thermal Output Possible Yes

5 Capital Expenses 350- 1300 € Low

6 O&M Fixed Expenses 10 €/kW - year High

7 O&M Variable Expenses

0.005-0.008 €/kWh Low

8 Predictability The amount of electricity generated is dependent fuel

High

9 Capacity 30-5000 kW Mini - Small

There are several types of technologies available on the market. There are renewable

3 Data source: Assessment of Distributed Generation Technology Applications - A report prepared by the Resource Dynamics Corporation for the Maine Public Utilities Commission, February 2001.



Page

59

technologies, including wind turbines, photovoltaic panels, hydro generators, generators based on biomass, and others. The non-renewable technologies include reciprocating engines, turbines, and fuel cells. The classification of the non-renewable technologies can be scaled to the lower level according to their size range, efficiency, fuel used and other technological specifics.

Each characteristic listed in sections 3.4.1, 3.4.2, and 3.4.3 is dependent on a number of factors. For example, installation expenses can vary with interconnection requirements, labour rates, ease of installation, and other site-specific factors. Although with such a variety of different technologies on the market it is difficult to make some global estimation of each type of technology, some generalization is, however, possible. In the Table 10 we exemplify some characteristics, based on D1.2, D2.1, and D2.2.

Table 10. DG technology characteristics estimation.

Technology

Effi

cien

cy

CO

2 E

mis

sion

s

Sta

rt-u

p T

ime

The

rmal

Out

put

Tot

al E

xpen

ses

O&

M F

ixed

E

xpen

ses

O&

M V

aria

ble

Exp

ense

s P

redi

ctab

ility

Not renewable

Reciprocating engines

High

Very High

Very quick

Yes

Low

High

Low

High

Microturbines Good

High

Quick

Yes

Low

Low

Low

High

Fuel cells Good

Low

Quick –Slow

Yes

High

Low

High

High

Renewable

Wind turbines Null - No High Low High Low

Solar Null - No High Low Low Low

Micro hydro Low High

Biomass Low High

Geothermal, wave, tidal

Low High

Waste reduction Low High

The estimations are of comparable nature. For example, we say that microturbines have low efficiency, because other technologies have much higher efficiency, and there fore they are better suited for applications where the low efficiency is good enough. It is difficult to estimate expenses, which vary based on size, fuel and other factors. In general larger units are less expensive (per kWh) than smaller units, and units designed for peaking power are less expensive than units designed for base load operation.

The renewable technologies have, in general, high capital expenses. The predictability of wind turbines and PV panels is dependent on the weather. Therefore, they are not suitable for peaking power or emergency generation. The advantage of these technologies is low or zero emission rates.



Page

60

3.4.5 How to use the technology hierarchy

The technology hierarchy described in the sections above can be used to give the preliminary requirements for the DG technology to be used in the business case. Selection of the appropriate DG technology is a next step after defining the goals for a specific DG-case (although sometimes you may want to start with a particular technology and then want to select to goals it can contribute to and the related value activities). The requirements for technology can be expressed via ranges of the characteristics, described in the section above. To facilitate the requirements definition, the Goal-technology checklist in Appendix B can be used.

The further example demonstrates how to select technological characteristics by using goal-technology checklist. Suppose that a strategic goal to be achieved by a business scenario is to enter the heat business. We have this goal in the strategic goal hierarchy, so we find this goal in the goal-technology spreadsheet:

Goal hierarchy for Strategic goals

Hig

h E

ffici

ency

Low

CO

2 E

mis

sion

s

Qui

ck S

tart

-up

Tim

e

Hig

h P

redi

ctab

ility

The

rmal

Out

put

Cap

acity

con

stra

ints

Grid

con

nect

ion

Low

Cap

ital E

xpen

ses

Low

Fix

ed E

xpen

ses

Low

Var

iabl

e E

xpen

ses

Goal: Strategic development Market development

S1.1 Enter the heat business ✦ ✦ ✧ ✧

S1

S1.2 Increase market share ✦ ✧ ✧

We select technological characteristics that are marked for this goal. As we can see, high efficiency and thermal output are important technological characteristics, and low fixed expanses and low variable expenses are less important to achieve this goal.

3.5 A reference business value model for DG

In this section we present a reference business value model for the DG domain. First, detailed descriptions of all value activities will be provided. Next, these activities will be combined in a value model, to conclude with a description of actors, which can perform these activities.

The strict distinction between actors and activities is an important concept in this document. A value activity is a collection of operational activities, which can be defined as a whole to one actor and yields profit for this actor. An actor is a natural or legal person performing those activities. This difference is made because with the rise of new business ideas, activities can be performed by different actors. For example, with µCHP, the activity ‘generation’ can be performed by the actor ‘final consumer’.

Another motivation for this distinction is the differences between different countries. What is called a ‘DSO’ in one country is different from the ‘DSO’ in another country. In all cases the ‘DSO’ will perform the activity ‘distribution’, but in some countries the ‘DSO’ is also



Page

61

performing the activity ‘supply’, while this is not the case in other countries. So the activities performed by a certain actor vary from country to country, from region to region and even from business idea to business idea.

We will start this section with an introduction to value activities and so-called scenario paths. Furthermore, we introduce a list of possible activities, a reference value model, and we conclude with a list of possible actors.

3.5.1 Value activities

A value activity can be defined as a collection of operational activities, which can be assigned as a whole to actors. A value activity must yield profit or should increase economic value for the performing actor. Consequently, we only distinguish value activities if at least one actor, but hopefully more, believes that s/he can execute the activity profitable. Value activities can be decomposed into smaller activities, but the same requirement stays: the activity should yield profit [2].

3.5.1.1 Scenario paths

A scenario path is used to relate objects of value (e.g. electricity) exchanged by one actor to each other. A scenario path is a (not necessarily chronological) representation of what value exchanges take place in a specific scenario.

A scenario path always starts with a start stimulus, a red dot, representing a (consumer) need. Then, a red line indicates a scenario path, ending in one or more end stimulus, a red line, right-angled on the scenario path. A scenario path connects all value exchanges needed to fulfil the (consumer) need that started the scenario path. A simple example is presented in Figure 7.



Page

62

Shopper

Store

Wholesaler

Manufacturer

goodmoney

goodmoney

goodmoney

Legend

Startstimulus

Scenariopath

Endstimulus

Figure 7. An example of a scenario path.

In this figure the scenario path starts with a consumer need for ‘a good’. This good can be exchanged for money with a store. To be able to provide this good, the store needs to exchange an amount of money for this good with a wholesaler, etc. A manufacturer does not need to exchange any values to provide ‘a good’ because it manufactures it itself, so the scenario path ends there.

To deliver a certain value object, it may be necessary to obtain multiple value objects from other value interfaces. In this case an AND-fork is introduced in the scenario path. In Figure 8, a AND-fork is added, because the shopper buys his good over the Internet now. The Online store needs to exchange objects via both value interfaces to fulfil the consumer need.



Page

63

Shopper

Online Store

goodmoney

Wholesaler

Manufacturer

goodmoney

goodmoney

ShippingCompany

shipmentmoney

Figure 8. Scenario path: AND-fork.

Finally, we introduce the OR-fork for the scenario paths. In Figure 9 you see an example of an OR-Fork. To handle shipment, the Online Store can choose between different Shipping partners, for example DHL and UPS.

Each value activity in the next paragraph has a predefined scenario path in it. Most of these paths will be trivial, but complex paths will be explained.



Page

64

Shopper

Online Store

goodmoney

Wholesaler

Manufacturer

goodmoney

goodmoney

UPS

shipment

money

DHL

shipment

money

Figure 9. Scenario path: OR-Fork.

3.5.1.2 DG Value activities

In this paragraph we will discuss the actors and value activities involved in the deregulated electricity sector. First, we will start with defining the value activities typical for the deregulated electricity sector. After that we will introduce the possible actors, and value activities they can be involved in.

3.5.1.2.1 Electrical System Regulation

Electrical system regulation is the overall control of the electrical system. Its targets are guaranteeing a fair operation of the system, for all actors involved in it. To accomplish this, laws, rules and standards should be made.

Because of the nature of this activity, electrical system regulation should be done by actors, which are fully independent of the interests of the electricity industry. Usually this activity is performed by the government or related entities.

The existence of effective regulation is an important feature in guaranteeing non-discriminatory access to the network. The performing actor should at least have the



Page

65

competence to fix or approve the tariffs, or at least, the methodology underlying the calculation of transmission and distribution tariffs. These tariffs should be published prior to their entry into force4. Another important task in this activity is to continuously monitor the market to ensure non-discrimination, effective competition and the efficient functioning of the market, as well as giving support and incentive to the research, development and demonstration of the new technologies and promote the new policies.

Figure 10. Electric System Regulation.

For each activity we will present an example of possible value ports and interfaces. Above the value ports and interfaces of the Electric System Regulation activity are presented. Electric System Regulation offers regulation to some (in this case 5) activities involved in the market. In return, they expect economic & ecological benefits for society.

3.5.1.2.2 Policy Making

Besides regulation, policies are necessary for the proper functioning of the electricity system. With policies, the actor who performs this activity can stimulate or impose specific behaviour to actors.

For example, policies exist to reduce the amount of CO2-emission, by penalizing emission above a certain amount. Alternatively, policies can stimulate the use of renewable energy sources by providing incentives to green producers.

Because of these characteristics, policy making should be done by actors, which are fully independent of the interests of the electricity industry. Usually this activity is performed by the government or related entities.

4 European Commission, op.cit., adoption motive (12)



Page

66

Figure 11. Policy Making.

Policy Making offers policies to most (and maybe all) activities in the market. These activities are obliged to accept and obey these policies. So Policy Making expects acceptance in return.

Scenario path:

Mention the start stimuli in this activity. In most cases Policy Making is not necessary for the fulfilment of a consumer need, but since the government insists on policy making, a start stimulus is drawn.

3.5.1.2.3 Trade

Trade is the activity, which buys electricity and resells it to the different party. Potentially, trade can be performed by any actor but the most vivid trade actor is an energy power exchange such as OMEL in Spain, or APX in the Netherlands.

Trade

electricityfee

electricity

electricityfee

electricity

economic & ecologicbenefits

regulation

Figure 12. Trade.

Trade virtually buys and sells electricity: they buy electricity and pay a fee or price in return, and then they sell this electricity and expect a fee or price in return. Besides, they have to obey the regulation as provided by Electric System Regulation.



Page

67

Scenario path:

To perform their activity, market management (and other value activities) is committed to regulation. The scenario path enters the lower ‘electricity fee <-> electricity’ value exchange. To be able to perform this exchange, in other words, to be able to sell electricity, they do not only need to buy electricity, they also need to fulfil regulation. An AND-fork is introduced to represent this.

3.5.1.2.4 Network management

Network management is the technical operation of the system to ensure the continuity and security of the electricity supply, co-ordinating production and transmission systems. Network management includes tasks like:

• Controlling the correct exploitation of the production and transmission systems according to reliability and security criteria.

• Managing energy imbalances: ensuring that the energy production matches the consumption on a second by second basis.

The managing of energy imbalances by matching supply and demand on a second by second basis is called ‘program responsibility management’ in some countries. This is part of network management.

Because of the nature of these tasks, it is often performed by the same actor performing transmission, in close co-operation with the actor performing market management.

Figure 13. Network Management.

Network Management offers network management to transmission. In return they expect a network management fee in return.

3.5.1.2.5 Generation

Generation is the production of electricity5. The production of energy can be done in many different ways; varying from production in big electric power plants to “autoproduction” using a small-scale hydropower. Actors performing generation are responsible for building, operating and maintaining their power producing equipment.

In deregulated markets generation is a free activity, so the produced energy can be sold in the wholesale market or directly to an eligible customer with bilateral contracts. Even in some non-deregulated markets, generation is a free activity where the performing actors

5 European Commission, “Amendments to Directive 96/92/EC”, Article 2



Page

68

arrange bilateral contracts with the utilities (vertically integrated corporations covering generation, transmission, distribution and supply). In markets where generation is a regulated activity, the government imposes where and when to build a new generation plant, as well as the fuel to be used.

Figure 14. Generation.

Generation offers electricity and expects an electricity fee in return. To be able to generate electricity, equipment has to be acquired. In return for equipment a fee (the product price) is paid. Generation could also be subject to regulation of the Electric System Regulation.

Scenario path:

To perform the generation of electricity, regulation needs to be fulfilled, and equipment is needed. But the acquisition of equipment for the generation of electricity cannot be represented with a simple AND-fork. An AND-fork would imply that for each start stimulus equipment needs to be bought. That is not true; in fact for each n number of start stimuli, one value exchange for the acquisition of equipment needs to be performed. This is represented with the implosion-symbol in Figure 14 (a vertical line with a ‘N:1’ notation).

3.5.1.2.6 Transmission

Transmission is the transport of electricity on the high-voltage interconnected system with a view to its delivery to final customers or to distributors, but not including supply6. The performing actor is responsible for operating, ensuring the maintenance of and, if necessary, developing the transmission system in a given area and, where applicable, its interconnections with other systems, and for ensuring the long-term ability of the system to meet reasonable demands for the transmission of electricity.7

The transmission activity usually remains as a monopolistic activity within a service area, even in deregulated markets. Thereby, the price for using the transmission network is determined by the access fee approved by the government.

Transmission can be divided into multiple other activities:

• Managing the ancillary services market.

6 European Commission, op.cit., Article 2




Page

69

• Foreseeing and controlling the medium and long-term level of electricity supply of the system.

• Foreseeing the medium and short-term use of generation equipment according to the demand foreseen.

• Taking into account technical restrictions and agree the scheduling of certain units with the actor performing market management.

• Establishing the international exchange schedules.

• Receiving the damage and maintenance information in order to communicate them to the actor performing market management.

• Making service replacement in case of system failures.

• Providing electricity producers (including DG) access to the electricity spot market.

All these functions require a good co-ordination between the actor performing market management and the actor performing transmission.

Figure 15. Transmission.

The main activity of transmission is to provide transmission. A transmission fee is expected in return. To maintain their network, network management is needed, for which they will pay a fee. Besides, transmission is subject to regulation provided by Electric System Regulation.

3.5.1.2.7 Distribution

Distribution is the transport of electricity on medium-voltage and low-voltage distribution systems with a view to its delivery to customers, but not including supply8. The actor performing distribution is responsible for operating, ensuring the maintenance of and, if necessary, developing the distribution system in a given area and, where applicable, its interconnections with other systems and for ensuring the long-term ability of the system to meet reasonable demands for the distribution of electricity.9





Page

70

Distribution activity usually remains a monopolistic activity within a service area, even in deregulated markets. Thereby, the price for using the distribution network is determined by the access fee approved by the government.

Figure 16. Distribution.

Distribution is about delivering electricity to the final customer. Therefore transmission is needed for which a transmission fee is paid. For providing distribution, a fee for both distribution and transmission is asked. This is called T&D fee in the value interface above. Besides, distribution has to obey the regulation provided by the Electric System Regulation.

3.5.1.2.8 Supply

Supply is the sale of electricity to customers10. Supply is a retail trade of electricity to final customers. Actors performing supply sell electricity to eligible customers in the free marketplace. Although the distributing actor does the physical delivering of electricity, the supplier handles the payment of electricity (billing).

In electricity markets where deregulation is taking place, but is not completed, the electricity to non-eligible customers has to be sold at tariff price, fixed by the government. Electricity can be provided to eligible customers who decide to remain under tariff, both in completely deregulated markets and markets in deregulation process. The actors performing supply are also responsible for reporting the specified and forecasted obligations for the coming planning period to the actors performing market management and transmission.




Page

71

Figure 17. Supply.

Supply sells electricity to final customers. First electricity is bought for the current market price. Then a retail price is asked for the electricity they deliver to final customers. Besides this price, a fee for transmission and distribution is asked. To physically deliver electricity, supply needs transmission and distribution. A fee for distribution and transmission is paid for these services.

3.5.1.2.9 Consumption

Consumption is the final use of electricity, both for eligible or non-eligible customers. (This division of customers will be discussed later.)

Figure 18. Consumption.

To buy electricity both an electricity retail price and a fee for transmission and distribution has to be paid. In return electricity is provided.

Scenario path:

The consumer need for electricity is the main start stimulus of this model. Notice the start stimulus (the red dot) in the figure above. The AND-fork to Energy Efficiency Service is an optional one, because not all consumers will perform this value exchange.

3.5.1.2.10 Manufacturing

Manufacturing is the production of equipment for generation of electricity. In most cases, the actors performing this task are only supplier to producers, assuming that they will profit, and therefore out of scope for the business modelling. But in some cases manufacturing actors



Page

72

can play a different and more ‘visible’ role in the power system, e.g. if such manufacturers have specific arrangements as shareholders, or other mechanisms to stimulate sale of DG equipment.

Figure 19. Manufacturing.

A manufacturer offers equipment for the generation of electricity. It expects in return a fee, the retail price of the equipment.

3.5.1.2.11 Leasing

With leasing, a lessor passes the rights to use some sort of equipment in exchange for the payments agreed in a leasing contract. In other words, the lessor leases (lends) to the lessee money in the form of goods, permits to use it and enters into a contract with the lessee providing the repayment of the value of the goods over a longer period of time, by stipulating respective interest for the provided service.

For example, a lessor can lease a micro-CHP installation to a final customer, to avoid high investments for the latter.

Leasing

fee Use of equipment

Figure 20. Leasing.

A lessor offers the right to use equipment. It expects in return a fee, which is a payment agreed in a leasing contract.

3.5.1.2.12 Balancing

The balancing activity is balancing the total power provided to the network with the total power consumption. The most popular utilization of balancing services is done by transmission companies (e.g. TSO), but it can also be used by DSO and wholesale energy traders (e.g. energy pools).

An actor performing the grid balancing is responsible for the determination of the planned power consumption and planned power generation of all its “balance group contractors”. Balance group contractors are power users, which can be either power consumers or power providers. Within a balance group, the total consumed power must be equal to the total generated or contracted power, usually measured in ¼ hour intervals.



Page

73

Although network management is also about balancing generation and consumption, grid balancing is a different activity. Balancing is done by network management is done on a second to second basis, physically necessary for the proper functioning of the system. Grid balancing is done in longer intervals (e.g. ¼ hour) and more an economically business opportunity, to provide a service to network management, reducing the needed physical balancing.

By the implementation of balance groups, the possibility of balancing and, thus, minimising the energy imbalances is created between electric power generation and electric power consumption. Thereby, users can be physically connected to the network at any point.

Balancing

Balancingservices

fee

feeSpecific

generationpattern

feeSpecific

consumptionpattern

Figure 21. Balancing.

Balancing offers balancing services to the transmission, distribution, or energy trade. In return they expect a fee for this service.

To deliver balancing services, the balancing actor buys an opportunity to influence demand or supply of customers and generators. The balancing offers a fee to the generation to receive a specific generation pattern in return (known as the demand-side management); the balancing offers a fee to the customers, often represented by supply, to receive a specific generation pattern in return (known as the supply-side management).

Scenario path:

Balancing is a need of actors receiving balancing services (TSO, DSO, or energy pool) need. That is why a start stimuli is not drawn. The OR-fork split up in two value exchanges notifying that whether demand or supply side has to be influenced. Actually, sometimes both demand and supply sides are managed, which implies using the AND-fork instead of the OR fork.

3.5.1.2.13 Energy efficiency

Energy efficiency is reducing the total amount of consumed energy. This is an activity that is



Page

74

actually a sub-set of both supply and consumption. This is because energy efficiency can be accomplished by reducing consumption or enhancing supply.

Figure 22. Energy Efficiency.

Energy efficiency provides energy efficiency services to consumers. In return a percentage of the savings accomplished by their services is expected.

3.5.1.2.14 Aggregation

Aggregation is combining the load or supply of multiple final customers in facilitating the sale and purchase of electricity, transmission, and other services on behalf of these customers.

There are two types of aggregation:

• Load aggregation: Managing procurement. Representing a lot of small consumers, by aggregating all the small loads in big ones, obtaining better conditions in electricity purchases in the retail market.

• Supply aggregation: As load aggregation does, supply aggregation is offering a service in which many small producers are grouped together and negotiate favourable terms in the market.

In both cases, actors that perform aggregation activities are paid by the parties they aggregate for.

Figure 23. Aggregation.

Aggregation is about combining the needs (or loads) of a group of small parties into one big need (or load). With these aggregated needs, better conditions can be obtained. These benefits are redirected to the parties providing the non-aggregated needs.



Page

75

Scenario path:

Aggregation combines multiple non-aggregated needs into one aggregated need. To represent this, an implosion symbol is used. This represents that a number of n non-aggregated needs is bundled into one aggregated need.

3.5.1.2.15 Metering

Metering is the metering of the amount of electricity the consumers consume. Nowadays in most cases this must be done by physically reading a meter. This is a time-consuming activity for the actor who needs to do this. In the future technology and/or businesses may be developed that makes it profitable to do metering as a profitable business activity.

Metering

Meteringservice fee

Figure 24. Metering.

Metering offers metering services to another party and expects a fee in return.

3.5.1.2.16 Fuel Supply

Some technologies for electricity generation need fuel. Conventional technologies need oil, coal, gas or uranium. But other distributed and/or renewable technologies need fuel also. For (micro)CHP gas is needed and for Biogas animal manure is needed.

Fuel Supply is the supply of this fuel. In some cases it may be needed to model fuel supply, in other cases it is not. If fuel is available for a (more or less) fixed price, and the fuel supplier has no other interests or (strategic) coals then delivering fuel, it should not be modelled, because the purchase of fuel is just an operational expense as any other. But if a fuel supplier has other interests besides fuel supply, like co-investing, or if the availability of fuel is important to the business idea (like animal manure, which isn’t easy available everywhere) fuel supply should be modelled.



Page

76

Figure 25. Fuel Supply.

Fuel Supply offers fuel to another party (a producing actor) and expects a fee in return.

3.5.1.2.17 Heat Supply

Heat Supply is the supply of heat to a consuming party, for the heating of buildings and/or water. Some technologies for electricity generation, like (micro)CHP produce electricity and heat simultaneously. Actually, in most cases more heat than electricity is produced. This heat can be used to heat buildings.

Heat Supply

heat fee

Figure 26. Heat Supply.

Heat Supply offers heat to another party (a consuming actor) and expects a fee in return.

3.5.1.2.18 Market management

Market management is the process of accepting bids for energy production and consumption, matching supply and demand and assigning contracts to the participants. Market management is about managing the wholesale energy market and the organisation of the power exchange (pool). The performing actor can be both a private and public company independent from electricity industry interests. Market Management is a separate value activity, and does not include the trade of electricity, which is modelled with the Trade activity.

Another part of market management is performing the settlements, using the measurement data sent by the system operator. Producers not producing their contracted power (produce more or less), and customers not consuming their contracted power must pay the over-costs due to the management of their energy imbalances.



Page

77

Market Management

market mangemenservices

fee

economic & ecologicbenefits

regulation

Figure 27. Market Management.

All the services provided by market management actor are market management services. Parties using these services pay a fee for them. Also the regulation can be modelled: MM is a regulated activity.

3.5.1.2.19 A reference value model

Like a jig-saw puzzle, all the example of value interfaces can be combined into one reference value model. Below, such a value model based on the discussed main activities is constructed.



Page

78

Figure 28. A Reference Value Model.



Page

79

At first glance, this model seems to be quite complicated. But the only thing we have done is connecting the value ports of the earlier presented value activities with each other. It is a jig saw puzzle that fits correctly!

3.5.2 Variations on the reference value model

3.5.2.1 Regulation activity

The attentive reader noticed that the regulation activity is absent in the reference model of Figure 28, although we presented multiple value exchanges and scenario paths to it in the value activity examples in section 3.5.1.2. The reason of this absence is that there are two options to represent the regulation activity in a model. The difference between those two options is the way we regard regulation.

One way to regard regulation is to see it as an external factor that influences the value objects. This choice implies that Regulation is not regarded as a value activity. The value model will not show an Electric System Regulation activity.

The other way to consider regulation is to see it as a value activity. In section 3.5.1.2 and in the Value Interface Library the Electric System Regulation activity is presented, with value interfaces like “regulation <-> economic & ecological benefits”, “subsidy <-> ecological benefits” and “regulation <-> fulfilment”. These value interfaces connect with other value activities as is shown in Figure 29. A specific value interface can be chosen for each activity with which regulation is interacting, matching regulation for this activity.



Page

80

Figure 29. Reference value model incl. regulation activity.



Page

81

3.5.2.2 Policy making activity

For the activity ‘Policy making’ applies exactly the same as for ‘Regulation’ discussed in the previous section; The decision should be made whether to regard policy making as a separate actor, or to regard is as an external factor, influencing the valuation of value objects.

3.5.2.3 Consumer payments

In the reference model of Figure 28 consumers pay a fee to their supplier. This fee is paid for a combination of good and services. The fee includes payment for electricity and payment for distribution and transmission. This is shown in Figure 30. In this case a consumer gets only one bill, a combination of electricity fee and transmission & distribution fee.

Figure 30. Consumer payments – Combined payment.

Another way to handle consumer payments is to bill electricity fee and distribution & transmission fee separately. In this case the consumer gets two bills, one from the DSO and one from the Supplier. This option is modelled in Figure 31. Notice that Consumption has two different payment value interfaces now, and the value exchange between supply and distribution disappeared. It may even be possible that a consumer gets a third bill from a regulator or government, for paying his taxes on electricity.



Page

82

Figure 31. Consumer payments – Separate payments.

3.5.2.4 Buy or Lease

In the reference model the generating party buys its equipment for electricity generation from a manufacturer. This is shown in Figure 32, a detail of Figure 28.



Page

83

Figure 32. Buying equipment.

Another possibility is that the actor performing generation does not buy his equipment, but leases it from a leasing company. This option is shown in Figure 33.

Figure 33. Leasing equipment.

3.5.2.5 Bilateral contracts

In deregulated markets generation is a free activity, so producers can sell the energy produced at the wholesale market or directly to a supplier with bilateral contracts. The direct sale of electricity to suppliers is not modelled in the reference model in Figure 28, as you can see in more detail in Figure 34(a).

If these bilateral contracts exist in the electrical system, these can be modelled like presented in Figure 34(b). The only change is a new value exchange between Supply and Generation, in which they exchange electricity for a fee directly, without interference of Market management.

In some cases, electricity can be delivered straight from generation to consumer. In this case both market management and supply are skipped, and electricity is delivered straight to a consuming party. This is shown in Figure 34(c).



Page

84

Figure 34. Bilateral contracts.

3.5.3 Actors

An actor is perceived by his/her environment as an economically independent (and often also legal) entity. Enterprises and end-consumers are examples of actors [2]. On the electricity market, a lot of actors are involved. Some of these are necessary for the proper functioning of the electricity market, others are functioning in a niche-market.

Most actors are closely related to the activity they are performing. To distinguish the difference between activities and actor, the question “Who is doing what?” should be asked. The ‘Who’ in this case is an actor, the ‘what’ an activity. So an actor is a person, a group of persons or a company performing a certain activity.

The actors mentioned in this section are prototypical assignments of the value activities of



Page

85

the previous paragraph to parties (persons or companies).

3.5.3.1.1 Regulatory Authorities

Regulatory authorities are those parties responsible for electrical system regulation. These authorities should be fully independent of the interest of the electricity industry, so usually they are the government and other related entities.

Depending on each country’s legislation, governments may include federal, state, county, regional, etc. governments.

Value interests:

• Law forces regulators to regulated activities.

• They can have income from taxes and/or penalties.

3.5.3.1.2 Policy maker

Policy makers are those parties responsible for making policies as described in 3.5.1.2.2. These authorities should be fully independent of the interest of the electricity industry, so usually they are the government and other related entities.

Value interest:

• They profit from economical or environmental benefits.

• They can have income from taxes and/or penalties.

3.5.3.1.3 Market Operator

The Market Operator is the actor responsible for market management. The Market Operator is a private company fully independent from electricity industry interests.

Value interest:

• Market Operators make profit by asking fees for their service.

3.5.3.1.4 Transmission System Operator

The Transmission System Operator (TSO) is a natural or legal person responsible for transmission (see 3.5.1.2.6)

The transmission activity usually remains as a monopolistic activity within a service area, even in deregulated markets. Thereby, the price for using the transmission network is determined by the access fee approved by the government.

The functions mentioned in this activity (see 3.5.1.2.6) require a good co-ordination between the Transmission System Operator and the Market Operator.



Page

86

Another name for the Transmission System Operator is Transmission Network Operator.

Value interest:

• Transmission System Operators charges producers for using the transmission network.

3.5.3.1.5 Independent System Operator

An independent system operator or simply System Operator, is responsible for network management (see 3.5.1.2.4)

Value interest:

• An independent system operator charges a fee for their network management.

3.5.3.1.6 Distribution System Operator

The Distribution System Operator (DSO) is a natural or legal person responsible for distribution (see 3.5.1.2.7).

The distribution activity usually remains as a monopolistic activity within a service area, even in deregulated markets. Thereby, the price for using the distribution network is often determined by the access fee approved by the government.

In most cases the DSO is also responsible for metering (see 3.5.1.2.15).

Other names used for this actor are Distribution Network Operator, Distribution Company, or Distributor.

Value interest:

• Distribution System Operators charges the customer or supplier for using the distribution network.

3.5.3.1.7 Producer

The producer (or generator) is a natural or legal person performing generation (see 3.5.1.2.5).

Value interest:

• Producers make profit by selling their produced electricity to the market.

3.5.3.1.8 Final customer

This is the actor purchasing electricity. Customers can be divided into eligible customers and non-eligible customers. Eligible customers have access to competitive suppliers of electricity, whilst non-eligible customers must purchase electricity at tariff price. The eligible



Page

87

customers are the customers, who are free to purchase electricity from the supplier of their choice within the Community. EU Member States shall ensure that eligible customers are:11

a) Until 1st of July of 2004, those customers with annual consumption higher than 20 GWh. Each Member State can establish lower limits for energy consumption,

b) from 1st of July of 2004 at the latest, all non-household customers,

c) from 1st of July of 2007 at the latest, all customers.

A final customer is an eligible or non-eligible customer, who purchases electricity for his/her own use. Therefore, final customers are also called consumers.

Inside final customers, two kinds can be distinguished: household customers and non-household customers. A household customer purchases electricity for his/her own household consumption, excluding commercial or professional activities. On the other hand, a non-household customer is a natural or legal person purchasing electricity, which is not for its own household use.12

Value interest:

• Customers need electricity for their daily functioning. Therefore they are willing to pay for electricity.

3.5.3.1.9 Supplier

Suppliers are the companies performing supply (see 3.5.1.2.8).

Competitive suppliers have to purchase electricity, so they are eligible customers, but they do not consume that electricity, so they are called wholesale customers. A wholesale customer, or supplier, is a natural or legal person who purchases electricity for the purpose of resale inside or outside the system where it is established.

Value interest:

• Suppliers make profit for charging more money for electricity to their customers then they paid for it at the wholesale market.

• Suppliers charge customers for secondary services they provide.

3.5.3.1.10 Utility

Traditional utilities are vertically integrated corporations, covering all the parts of the electricity business: generation, transmission, distribution and supply. In order to achieve meaningful wholesale and retail competition in the electricity market, it is essential to separate monopoly functions from competitive functions.





Page

88

The term utility is currently used for corporations coming from an unbundled traditional utility.

Value interest:

• Utilities ask money for their electricity, transmission, distribution and/or services.

3.5.3.1.11 Energy Service Company

The Energy Service Company (ESCO), or energy efficiency company, is a company which deals with the final customer on-site, specialising in energy efficiency and load management services, but an ESCO may also sell power, taking on the additional role of a retailer. ESCOs do not need the electrical market to be open, instead of selling electricity, so they are operating all around the world. Historically, the energy service industry is relatively young. Most ESCOs place the industry’s origins in the late 1970s and early 1980s when energy prices rose dramatically following the 1973 Arab oil embargo and the Iranian Revolution in 1979. These events created the opportunity to make business out of reducing customers’ growing energy costs. Typically, the ESCO carries out the following tasks, which are bundled into the project’s cost and are repaid through the money savings generated:

1. Develop, design, and finance energy efficiency projects.

2. Install and maintain the energy efficient equipment involved.

3. Measure, monitor, and verify the project’s energy savings.

4. Assume the risk that the project will save the amount of energy guaranteed.

The main ESCO services are listed below:

• Energy savings: ESCO projects are comprehensive, which means that the ESCO employs a wide array of cost-effective measures to achieve energy savings. These measures often include high efficiency lighting, high efficiency heating and air conditioning, efficient motors and variable speed drives, and centralised energy management systems. What sets ESCOs apart from other firms, which offer energy efficiency, like consulting firms and equipment contractors, is the concept of performance-based contracting. When an ESCO undertakes a project, the company’s compensation, and often the project’s financing are directly linked to the amount of energy, which is actually saved.

• Financing: Typically, the comprehensive energy efficiency retrofits inherent in ESCO projects require a large initial capital investment and offer a relatively long payback period. The customer’s debt payments are tied to the energy savings offered under the project so that the customer pays for the capital improvement with the money which comes out of the difference between pre-installation and post-installation energy use and other costs. ESCO interests are about half any bank’s interests.

• Maintenance: Most performance-based energy efficiency projects include the maintenance of all or some of the portion of the new high-energy efficiency equipment over the life of the contract (7-10 years). The cost of this ongoing maintenance is folded into the overall cost of the project. Therefore, during the life of the contract, the customer receives the benefit of reduced maintenance costs, in addition to reduced energy costs.



Page

89

As an additional service in most contracts, the ESCO provides any specialised training needed so that the customer's maintenance staff can take over when the contract ends.

• Education: Energy efficiency projects also include the education of customers about their own energy use patterns in order to develop an “energy efficiency partnership” between the ESCO and the customer. A primary purpose of this partnership is to help customers understand how their energy use is related to the business they conduct.

• Hazardous materials management: Included in the complementary services provided in a typical performance-based energy efficiency contract, are the removal and disposal of hazardous materials from the customer’s facility. When, for example, existing ballasts which contain PCBs, and fluorescent light tubes which contain traces of mercury are replaced, the old equipment must be disposed off as hazardous waste. Upgrades to heating, air conditioning, and ventilation systems may involve the removal of asbestos, which would also be properly disposed of by the ESCO.

Three kinds of contract can be signed between the ESCO and the Customer:

1. Guaranteed Savings Contract: The customer finances the design and installation of the efficiency measures by borrowing the funds from a third party, usually a commercial bank. Financing is typically arranged by the ESCO, but it has no relationship with the bank financing the project; it is the customer who has the duty of repayment on the loan. The ESCO assumes project performance risk under this project structure, because it guarantees energy savings will meet agreed-upon minimum, usually enough to cover debt service. If minimum is not met, the ESCO pays the customer the difference. If minimum is exceeded, the customer agrees to pay the ESCO an agreed-upon percentage of the savings. Guaranteed savings contracts are the most common type of contract used in the United States.

2. Shared Savings Contract: The ESCO finances the project, either from its own funds or by borrowing from a third party. Thus, the ESCO takes not only the performance risk, but also the risk associated with the customer’s creditworthiness. Savings percentages paid to ESCO are higher than in guaranteed savings contract, in which the ESCO assumes only the performance risk.

3. Pay for Savings Contract: This is a subcategory of guaranteed savings contract, but instead of fixed payments for the customer to repay the loan, the payment schedule depends on the level of savings. The more the savings, the quicker the repayment. Pay from Savings Contracts are generally less risky than Guaranteed Savings projects, which makes this contract more popular in situations where cost-based construction is prominent, such as in the public sector.

The main activity of ESCOs is energy efficiency (see 3.5.1.2.13). Sometimes, in addition to energy efficiency measures, the ESCO offers to its customers electricity supply. This supply can be done by either obtaining electricity from a third party, or installing a distributed generator, which can be owned by the customer, or by the ESCO.

Value interest:

• ESCOs profit from the Savings Contracts. The way this profit is redirected from customer to ESCO can vary, as is explained above.



Page

90

3.5.3.1.12 Manufacturer

A manufacturer is a natural or legal person manufacturing equipment for electricity generation (see 3.5.1.2.10). In most cases this actor is not used in business modelling, because it is only acting as supplier, assumed to perform a profitable value-activity. But in some cases a manufacturer can play a more visible role, with other value activities than supply of equipment only. (A good example of this is the role of cellular phone manufacturers in the telecom-sector. The manufacturer has interest in providing its phones to as much users as possible, because they also deliver equipment for the telecom-network itself.)

Value interest:

• A manufacturer makes profit from the selling of equipment.

3.5.3.1.13 Lease Company

A lease company is a natural or legal person who leases equipment to another party (see 3.5.1.2.11). By doing this, a lessee can use expensive equipment without the need of high investments.

Value interest:

• A lease company profits from the interest it’s calculating in the payment.

3.5.3.1.14 Autoproducer

The autoproducer is a natural or legal person generating electricity essentially for its own use.13 An autoproducer is therefore performing generation (see 3.5.1.2.5), but only for its own use.

Value interest:

• The autoproducers save the money he had to pay the supplier when he did not autoproduce.

• The autoproducer needs electricity for its daily functioning. In case he is not connected to the grid, he has to autoproduce electricity.

3.5.3.1.15 Independent Power Producer

The Independent Power Producer (IPP) is an electricity producer who does not carry out electricity transmission or distribution functions in the territory covered by the system where it is established.14 An IPP is therefore performing generation (see 3.5.1.2.5).





Page

91

Value interest:

• Independent Power Producers make profit by selling their produced electricity to the market.

3.5.3.1.16 Green Producer

The Green Producer generates electricity from renewable energy sources. A green producer is therefore performing generation (see 3.5.1.2.5).

Value interest:

• Green Producers make profit by selling their produced electricity to the market

• Green Producers can have additional income out of incentives for green electricity

• Green Producers contribute to a better environment

3.5.3.1.17 Distributed Producer

The Distributed Producer is an electricity producer who carries out electricity directly to the distribution system. This electricity can be the total production of the distributed producer, or just the surplus after own consumption. A distributed producer is therefore performing generation (see 3.5.1.2.5).

Value interest:

• Distributed Producers make profit by selling their produced electricity to the market

• Distributed Producers can save money from the electricity they would have paid for if they didn’t consume part of the electricity they produced.

• Distributed Producer can rely on their own power sources anytime, even in case of power failures on the grid.

3.5.3.1.18 Retailer

A retailer is an actor performing supply (see 3.5.1.2.8). A retailer supplies in direct transaction with a final customer.

Value interest:

• Retailers have income by charging a higher fee for the electricity they provide then the price they paid for it. In other words: they earn from retail.

3.5.3.1.19 Marketer

A marketer is an actor performing supply (see 3.5.1.2.8). A marketer buys electric energy, transmission and other services from traditional utilities and other suppliers, and resells those services at wholesale or to a final customer. The marketer takes no title to any of the



Page

92

electricity purchased or sold.

Value interest:

• Marketers have income by charging a higher fee for the service they provide then the total price they paid for it.

3.5.3.1.20 Broker

A broker is an actor performing supply (see 3.5.1.2.8). A broker acts as an agent for other in negotiating contracts, purchases or sales of electric energy, transmission, and other services between buyers and sellers, without owning any transmission or generation facilities. The broker takes no title to any of the electricity purchased or sold.

There are two kinds of broker:

1. Affiliated broker: This actor operates representing a supplier, and offers its products, so the supplier can reach more customers. Consequently, a final customer can contact an affiliated broker of a supplier, instead of entering the retail market. The affiliated broker obtains revenues from the supplier he/she represents.

2. Procurement manager: Customers which can not pay attention to the retail market, but want to enter there, hire a procurement manager, in order to obtain electricity in the retail market. This way, the customer will obtain electricity relatively cheap, but has to pay the manager.

Value interest:

• The broker obtains revenues from the supplier he/she represents

3.5.3.1.21 Retail Shop

A retail shop is an actor performing supply (see 3.5.1.2.8). A retail shop offers a bundle of services, such as metering, innovative billing services, etc. or even bundling of electricity, gas, phone, water, etc.

Value interest

• The retail shop makes profit from the fee it charges for the supply of bundled services.

3.5.3.1.22 Aggregator

An aggregator is any marketer, broker, public agency, city, county, special district, or any other (legal) person which performs aggregation as mentioned in 3.5.1.2.14.

In most cases, it is too expensive for small actors to enter the market. In order to overcome this trouble, small actors can hire an aggregator who pays once for entering the market, and distributes that enter-fee between all the small actors.

Value interest:



Page

93

• The aggregator makes profit from the fee he asks from the small customers or producers he represents.

3.5.3.1.23 Buying Pool

A Buying Pool is a coalition of customers entering the retail market, created to obtain better conditions for their participants. The Buying Pool does not contract any load aggregator, so customers do not have to pay anyone, but they have to manage correctly their bids.

A Buying Pool can only perform its activities in deregulated markets. The current trend for buying pools is that they are on the way out from the market, because price reduction for participants is usually marginal.

Value interest:

• A buying pool makes profit out of the favourable conditions of representing a large group of buyer.

3.5.3.1.24 Load Management Group

In addition to wholesale customers (suppliers), final customers can also make profit in a deregulated market, managing their consumption. Final customers can manage their consumption themselves, or entering into a group of customers.

If the customer consumes electricity in low-demand periods, electricity will be cheaper than in peak-demand periods. The customer may purchase electricity in the day-ahead market and if the next day hour-ahead market price grows, he/she can manage his/her consumption to sell the electricity purchased the day before. The customer will not consume electricity in peak-demand periods, but in low-demand periods, so he/she can purchase electricity in the hour-ahead market at a low price.

Load Management Groups are customers associations entering electricity markets, in order to obtain the most profitable prices. The Load Management Group can act as a Buying Pool, but the most usual way to operate is signing an agreement with the Distribution System Operator.

The Load Management Group consumes electricity when the DSO indicates (usually low demand periods), and receives retribution in return. On the other hand, the Load Management Group has to release the consumption of loads in required periods (usually high demand periods). This way, the demand curve will be smoothed and DSO will not have to upgrade the distribution grid.

The biggest problem for Load Management Groups is how to manage their load. Two ways are used, on the one hand, demand-side management can be used in order to change customer’s habits and, on the other hand, energy storage can be applied.

Value interest:

• Load Management Groups can make profit from adopting their electricity demand to the current price.



Page

94

3.5.3.1.25 Balance Group

A balance group is an actor performing grid balancing (see 3.5.1.2.12).

Value interest:

• Balance groups profit from the commercial incentives for balancing the power to be produced with the power to be consumed.

3.5.3.1.26 Metering Company

A metering company is a company providing metering services (see 3.5.1.2.15) as their primary process.

Value interest:

• Metering companies profit from the fee they ask for their metering services.

3.5.3.1.27 Fuel Supplier

A fuel supplier is a natural or legal person supplying fuel (see 3.5.1.2.16) to actors who perform generation.

Value interest:

• Fuel suppliers profit from the fee they ask for their fuel.

3.5.3.1.28 Heat Supplier

A heat supplier is a natural or legal person supplying heat to consuming actors. In most cases this person is a producer which uses a technology that produces electricity and heat simultaneously (for example CHP). Both heat and electricity are sold.

If a customer uses µCHP, its first concern is the production of heat. The generated electricity is seen as efficient ‘side-effect’ and used for own consumption or sold to a supplier.

Value interest:

• Heat suppliers profit from the fee they ask for their heat.

3.5.3.1.29 ICT service provider

ICT service provider is also a kind of manufacturer or a leaser, and can be modelled as fulfilling with manufacturing of leasing activity.

Value interest:

An ICT service provider profits from selling or leasing ICT hard- and software, by providing ICT services, and by maintaining the ICT equipment.



Page

95

3.5.4 Relating value activities and actors

In practice, only a limited set of actors are interested to perform specific value activities. Table 11 shows which actors are potentially interested in performing value activities. We distinguish main actors, which are the driving actors for the specific value activity and optional actors, which play a more facilitating role. A regulated main actor is an actor who is assigned to perform the activity by law or government.

D 5.1 D

istributed Generation B

usiness Modelling

EE

SD

Project N

NE

5/2001/256 BU

SM

OD

BU

SM

OD

: Business M

odels in a World C

haracterised by Distributed G

eneration

Page

96

Tab

le 11. Acto

rs and

Activities m

atrix in th

e Electrical S

ystem.

R

Regulated M

ain Actor

M

Main actor

O

Optional actor

Regulatory authorities

Policy Maker

Market Operator

Transmission System Operator

Independent System Operator

Distribution System Operator

Producer

Final Customer

Supplier

Utility

Energy Service Company

Manufacturer

Lease Company

Autoproducer

Independent Power Producer

Green Producer

Distributed Producer

Retailer

Marketer

Broker

Retail Shop

Aggregator

Buying Pool

Load Management Group

Balance group

Metering company

Fuel Supplier

Heat Supplier

ICT services provider

Electric S

ystem R

egulation R

Policy m

aking

R

Trade

M

O

O

O

O

O

Generation

M

O

O

O

O

O

O

Transm

ission

R

O

Netw

ork managem

ent

O

R

O

Distribution

R

O

Supply

M

O

O

O

O

O

O

O

O

O

D 5.1 D


usiness Modelling

EE

SD

Project N

NE

5/2001/256 BU

SM

OD

BU

SM

OD

: Business M

odels in a World C


eneration

Page

97


Policy Maker

Market Operator




Producer

Final Customer

Supplier

Utility


Manufacturer

Lease Company

Autoproducer


Green Producer


Retailer

Marketer

Broker

Retail Shop

Aggregator

Buying Pool


Balance group

Metering company

Fuel Supplier

Heat Supplier


Consum

ption

M

O

O

O

O

Manufacturing

O

M

O

Leasing

O

O

O

O

M

O

Balancing

O

O

O

O

O

O

O

O

O

M

Energy E

fficiency

M

Aggregation

O

O

O

O

O

M

O

O

Metering

M

O

O

O

O

O

O

O

O

O

O

Fuel S

upply

O

M

Heat S

upply

O

O

O

O

O

M

Market M

anagement

R



Page

98

References

Anton (1996) A. I. Anton, Goal-Based Requirements Analysis, Proceedings of the 2 t Int. Conf. On Requirements Analysis, ICRE '96, 1996, pp.136-144.

D1.2 (2002) Goran Strbac, Joseph Mutale and Thomas Bopp. D1.2: Analysis of Distributed Generation Characteristics. BUSMOD, UMIST 2002. See also http: //busmod.e3value.com

D2.1(2002) Ignacio Garcia-Bosch. D2.1: Arising Scenarios on Distributed Generation Business. BUSMOD 2002

D2.2 (2002) Andrei Z. Morch, André Lambine and Ove Wolfgang (SINTEF Energy Research), Iñaki Laresgoiti, Carlos Madina (LABEIN), M.J. Elswijk; J. Kester; I.G. Kamphuis (ECN), Joseph Mutale and Goran Strbac (UMIST). D2.2: Future Scenarios on Distributed Generation Businesses, BUSMOD 2002

Little (1999) Arthur D. Little, Distributed Generation: Understanding the Economics (white paper), Arthur D. Little, Cambridge, MA, 1999

Leiter and Lamsweerde (2002) E. Letier and A. van Lamsweerde, Derivng Operational Software Specifications from System Goals Proceedings FSE'10 - 10th ACM S1GSOFT, Symp. on the Foundations of Software Engineering, Charleston, November 2002

RDC (2002) Resource Dynamics Corporation, Assessment of Distributed Generation Technology Applications, Systems Analysis Laboratory, Vienna, AT, 2001



Page

99

Chapter 4 DG Business modelling

In this chapter we focus on the business modelling process for DG. This chapter supposes that the reader has already read Chapter 3. If you are not familiar with modelling constructs, introduced in Chapter 3, then we advice to read it before starting with this proceeding.

The graphical description of the process of building a business case for DG is illustrated in Figure 35. Business case building includes a number of sequentially executed steps. The result of each step is input into the following step, and the outcome of the whole process is a business model including a graphical representation and corresponding financial profitability sheets, which facilitate sensitivity analysis of the business case.

The general idea of business modelling is to identify actors and value exchanges between them, and to perform financial evaluation of the business case. In general, the process of modelling includes the following activities:

1. Concise statement of the DG business idea

2. Identification of the goals of the business case

3. Identification of possible technological solutions

4. Building the (graphical) value model

5. Building the financial model

6. Performing sensitivity analysis



Page

100

Figure 35 Diagram of the process steps



Page

101

4.1 Step 1: Business case description

Start to write down a textual, just first attempt, short business case description to express the business idea. Such a description should not be too long (not more than 10 sentences) Use the terminology defined in the methodology (see Chapter 3). For example, name a company responsible for distribution services a Distribution System Operator, but not the Network Operator, or Network System Operator. Doing so, avoid misunderstandings and time-consuming discussions.

An e3 value model is a representation of the real world. Such a representation cannot include all objects of the real world. Before the modelling process start, it is important to consider what needs to be modelled and what not: what parties need to be modelled what activities need to be modelled?

A business plan can only succeed if all involved actors regard it as a profitable idea. All involved actors should have benefits from the business idea, and the only way to calculate the profitability is to include these actors in the value model. So, the basic rule is to include all involved actors and activities in the business model process. A profitability sheet is necessary for all involved actors, to calculate whether a business idea is profitable to it or not. Only when a certain activity is assumed to be profitable, it is possible to exclude it from the modelling process.

For example, it is assumed that a banking company can profit from providing loans. So if a loan is needed for a certain business idea, just assume that a bank is willing to provide this loan, and exclude the banking activity from the business modelling process. But if a banking company, or other investor, becomes a shareholder, and receives a certain percentage of income of profit, it should be modelled.

4.1.1 Tasks to do

Task 1.1 State concisely the DG business idea. Start with defining a one-liner stating the idea. This one-liner stating should only be a few sentences long.

Task 1.2 When needed, add details regarding the business idea to make the one-liner understandable by non-specialists in the domain.

Task 1.3 Proceed with defining the scope of the business model. Think about at what region you want to do the business (e.g. a whole country, a specific region, a district etc.), what is your target group, or who will buy your services (small house-hold customers, middle-scale customers, large power plants, distribution companies, etc.), what are the specific conditions for the region (e.g. facilities, regulation, weather conditions). Describe which assumptions apply to this business model.

Task 1.4 In few sentences, describe the business process: who is buying and selling what and to whom.

Task 1.5 After the business process is defined, define who are the actors, what are their goals (each actor can have different goals), what value activities do they perform, or are going to perform. Also define who is the owner of the technology. Think about who are the key actors in this business idea.



Page

102

Task 1.6 Think about what technology is to be used. Maybe you already target a specific technology. This task should not get into deep details but should describe the used technology on a more global level.

Task 1.7 Finally, write down what incentives you have to take into consideration.

4.1.2 Questions to ask

Question 1.1 What are the main goals to be achieved by this specific idea (use Appendix A)?

Question 1.2 What are the commercial offerings?

Question 1.3 Who do you expect to buy your service? What region do you target at?

Question 1.4 Who are the driving actors and who are the most important customers (consider e.g. revenue generators)?

Question 1.5 What are the main activities of actors (see Chapter 3)?

Question 1.6 Which technology may be of use to realize the idea (see Chapter 3) and who will own it?

Question 1.7 What incentives (e.g. subsidies) can be thought of?

4.1.3 Guidelines to use

Guideline 1.1 Mention strategic and operation goals.

Guideline 1.2 Keep the statement of the idea short and concise, so that everyone can read it quickly.

Guideline 1.3 Focus on economic value creation, distribution and consumption, not how this practically done.

4.1.4 Example

Business case description Highlighted issue

The business idea is to install a small generator based on renewable energy sources, to sell electricity to the grid

Business idea

We are going to analyse the feasibility of the business idea by modelling the Bask Autonomous region

Scope

The customer owning the generation unit sells electricity to the Distribution System Operator to satisfy his/her needs, and sells all the electricity generated, so he/she receives a premium for all the

Business process



Page

103

electricity generated

The owner of the generator may be a residential, non-eligible customer. (Non-eligible implies that the customer buys energy from the Distribution System Operator, i.e. no supplier is involved)

In this business opportunity the main actor is the Renewable Energy Producer, because he/she the one performing the business idea. Since the Renewable Energy Producer must enter into the electrical system to sell the electricity generated, other actors will appear managing it, such as the Energy Directorate, the Distribution System Operator, and the Market Operator.

Ownership, Actors

In this particular case we focus on the small generation unit, based on any of the following renewable energy sources: photovoltaic, solar thermal, small hydro, wind, geothermal, wave energy, tidal energy.

Technology

The incentives are (1) the obligation of the Distribution System Operator to purchase all the energy produced from sources, complying with Special Rules, and (2) premium paid for “Special Rules” generation.

Regulatory incentives

Data about generation and facilities of the Bask autonomous region is provided below.

Data

Note that in reality such a concise statement of the idea can only be given after a full-blown DG business model track.

Additional data that are used for financial analysis are generation data for the Bask Autonomous region15 presented in the table below:

Capacity Generation MW GWh COMMON RULES 1 307 2 259 SPECIAL RULES 413 966 Renewable Energy Sources 104 288 Non-Renewables 309 678 SUM 1 720 3 225 TOTAL CONSUMPTION 16 800 IMPORT 13 575

15 Source: Red Eléctrica de España, "El Sistema Eléctrico Español - Informe 2001", available in http://www.ree.es/index_sis.html (only in Spanish)



Page

104

4.2 Step 2: Goal selection

Whereas the first step is about phrasing the business idea shortly and concisely, the next steps are meant to specify and analyse the idea in far more detail. A first action is the understanding of goals of stakeholders, to which a business idea should contribute.

There are many stakeholders (enterprises and people representing these enterprises) in the distributed generation business. Each stakeholder has a set of goals with respect to a specific DG business case. These goals stakeholders have may not always be in harmony and, in fact, very often conflict, as each party tries to adopt strategies to maximize their individual benefit. In contrast, the goals of stakeholders may be mutually beneficial, and therefore, their bundling can be favourable for a DG business case.

Understanding of, and reasoning about the goals of stakeholders is essential for the creation of the sustainable DG business model. The explicit picture of goals sketches potential contributors for the business case. One can also search for a successful combination of goals as well as for crucial bundles. Moreover, goals restrict the requirements for DG technology to be used for the business case. Finally, an important outcome of the goals is the restriction of the scope of the model in terms of included actors and activities.

We distinguish two categories of goals. Firstly, there are strategic goals; these are goals on the long term (typically 5 to 20 years). Secondly, there are operational goals. These are goals on the short term (typically 1 to 5 years). They contribute to reaching a strategic goal and therefore can be seen as sub goals of strategic goals.

According to this classification, we have a goal hierarchy, which includes goals, specific for the DG domain. This goal hierarchy is concisely presented in Appendix A. The goal hierarchy was built on various sources of information, including D1.2, D2.1, and D2.2. Of course, we cannot claim that this hierarchy covers all the goals possible to appear in the DG domain, but, at least, it covers the goals, derived from the business scenarios described in the BUSMOD project, namely in deliverables 1.2, 2.1, and 2.2. For details about the goal hierarchy see Chapter 3.

4.2.1 Strategic goals selection

Strategic goals can be classified into Market development goals, Environmental goals and Quality and Efficiency goals. Market development can be associated with acquisition of new customers, new technology, and new services. Environmental goals are about the improvement of the environment; they imply low-emitting technologies and financial support for “green” electricity. Quality and efficiency goals aim to improve quality and efficiency of different parts of the system, such as physical services, or market management services. The goal hierarchy of strategic goals is discussed in 3.3.1.

4.2.2 Tasks to do

Task 2.1 Select strategic goals. Select strategic goals that are relevant to the business case. First start by defining goals for each actor. Next, use the Goal



Page

105

Hierarchy spread sheet (see section A.1 of Appendix A) to fill in the defined goals in this sheet. In the spreadsheet checkmark the “Apply” cell for the goal selected.

Task 2.2 Add goal not listed. If in the list A.1 there is no listed strategic goal that matches your business case, then introduce a new goal. Use the business idea description and knowledge of domain experts. Use questions listed below to discover a strategic goal. After you have determined a strategic goal for you business case, define whether this goal is “Environmental”, “Market development”, or “Quality and efficiency” goal.

Task 2.3 Identify a stakeholder. In the column “Stakeholder” of the Goal Hierarchy spread sheet (see section A.1 of Appendix A) write the name of the stakeholder that has the selected goal.


Question 2.1 Who is the main initiator of the business case? What is his goal?

Question 2.2 Who are the customers? What are their goals?

Question 2.3 What are (main long-term) goals of the business case that exceed individual enterprise interest? Use section A.1 of Appendix A.

Question 2.4 What stakeholders have these goals? Who contribute to the business case and who can potentially loose?

Question 2.5 What is the type of the goal? Is this goal “Environmental”, “Market development”, or “Quality and efficiency” goal?


Guideline 2.1 Use the goal hierarchy spreadsheet for Strategic goals (use Appendix A).

Guideline 2.2 Use the business case description to identify goals, not listed in the goal hierarchy.

Guideline 2.3 Use the business case description to relate goals and stakeholders.

4.2.5 Example

In our case we selected “Reduce environmental emissions” goal to be a strategic goal of our example business scenario. The part of spreadsheet is shown below:



Page

106

4.2.6 Operational goals selection

Operational goals contribute to a strategic goal and are achieved by performing one or more value activities. In other words, performing a value activity contributes to an operational goal, which in the end contributes to a strategic goal. Operational goals can be classified as (1) goals related to making profit, (2) goals related to consuming electricity, and (3) goals related to efficient market functioning. Generation, supply, distribution, supply or lease equipment value activities are all performed to make profit, and, therefore, goals related to these activities are sub-goals of the goal “Make profit”. End consumers, or actors performing a consumption activity may have goals that are placed as sub goals of “Consume electricity” goal. And, finally, regulatory authorities and policy makers, or actors carrying out a regulation activity, may have goals placed under the goal “Provide market functioning”. The goal hierarchy of operational goals is discussed in 3.3.2.

We already said that strategic goals and operational goals are related to each other. Strategic goals can be classified into Market development goals, Environmental goals and Quality and Efficiency goals. Above we described the classification for operational goals. However, an operational goal can also be classified as Market development, Environmental or Quality and Efficiency goal, and this establishes the relation of contribution between strategic and operational goals. In the goal hierarchy strategic goals are defined as long-term goals, and are not connected to any value activity, while an operational goal is a short-term goal related to some value activity that has to be done to achieve this goal. This way, by establishing the relation of contribution between strategic and operational goals we identify what short-term (operational) goals have to be achieved to reach certain long-term (strategic) goals.

4.2.7 Tasks to do

Task 2.4 Select operational goals. Select operational goals that are relevant to the business case using the Goal Hierarchy spread sheet (see section 0 of Appendix A). In the spreadsheet checkmark the “Apply” cell for the goal is selected.

Task 2.5 Add goal not listed. If you consider a goal that is not listed in the operational goal hierarchy (see section 0 of Appendix A), then introduce a new goal. Pay attention that operational goals are defined for a particular activity. After you determine an operational goal for an activity, define whether this goal is “Environmental (E)”, “Market development (M)”, or “Quality and efficiency (QE)” goal.

Goal hierarchy Type Apply Stakeholder

Market development M

S1.1 Enter new business M

S1

S1.2 Increase market share M Yes Iberdrola Group

… Other market development goal(s) M

Environmental goals E S2

S2.1 Reduce environmental emissions

E Yes Spanish Government

… Other environmental goal (s) E



Page

107

Task 2.6 Identify a stakeholder. In the column “Stakeholder” of the Goal Hierarchy spread sheet (see section 0 of Appendix A) write the name of the stakeholder that has the selected goal. Check if the name of the activity in the “Activity” column is appropriate for the stakeholder. For example, if the goal you selected is related to the activity “Generation”, then the stakeholder having this goal should perform this activity. If the activity is not relevant to the stakeholders’ business (for example, the stakeholder you assigned is a distribution company, which does not do generation), then the selection is incorrect. Then again search the correct goal in the operational goal hierarchy.

Task 2.7 Check for comparability. The goals you select together have to form a combination that positively contributes to the implementation of a business case. The first thing to check is the correlation between strategic and operational goals; correlation means here that an operational goal contributes positively to a strategic goal. Observe the following rule:

The type of at least one operational goal has to match the type of one of the strategic goals.

The type of a goal means goal being of one of the following types: “Environmental (E)”, “Market development (M)”, or “Quality and efficiency (QE)”. Not keeping the above mentioned rule implies that the strategic goal lacks contribution of value activities, which results in the increased probability to have obstacles and complexity while meeting the goal.

Task 2.8 Check for contradictions. Check whether an operational goal you have selected does not prevent the fulfilment of others. For example, if you selected a strategic goal “Reduce dependency on subsidies”, then the goal for the generation activity“ To benefit from the subsidizing schemes” contradicts with this strategic goal. Note that contradictions are not necessarily between strategic and operational goals, but also between different operational goals, and different strategic goals.

You can use the goal-conflicts matrix (Appendix D) to determine which goals may conflict with each other and which goals support each other strongly. For the goals that give a conflict, modify the goals or remove them from the selection.

Task 2.9 If needed, modify the selected goals. Lack of comparable goals and the existence of contradictory goals result in an increased probability to have obstacles and complexity while meeting goals. Actually, the presence of the contradictory operational goals indicates that it will be difficult for stakeholders to agree about some issues. The absence of comparable operational goals says that stakeholders have no external drivers to be wiling to execute the business case; in other words, the stakeholders are not likely to commit to the investigated business case unless being inspired by opportunities delivered by this business case.

On the other hand, a non-favourable result of the goal analysis can mean that not all the goals have been discovered. So, always consider that there can be some goals that you are not aware of. To discover new goals think about stakeholders that are likely to participate in the scenario, and question yourself about their expected attitude and goals of their business, their obligations, and regulations they have to fulfil. See also list of questions below.



Page

108

Task 2.10 Update Goal-Activity Value Interface table. After goals have been selected (or discovered), write them down in the column “Goal Name” of the Goal-Activity-Value Interface table. Find the template for the Goal-Activity-Value Interface table in Appendix F.

Task 2.11 Review selected goals. Check both the operational and strategic goals set in the spreadsheets with the business case description from task 1. Add missing goals or change the business case description according the selected goals in this task. You may have to look at results from task 1.5 specific.


Question 2.6 What are the main short-term goals of the key initiator of the case?

Question 2.7 What are the main short-term goals/expected regulation activities of the government? What incentives (e.g. subsidies) can be thought of?

Question 2.8 What are the main short-term goals of each stakeholder including customers?

Question 2.9 What is the type of a goal: is it an “Environmental”, “Market development”, or “Quality and efficiency” goal?

Question 2.10 Does a goal contribute to at least one strategic goal? Or is the type of a goal similar to the type of at least one strategic goal selected?

Question 2.11 Does a goal prevent any strategic or other operational goals?


Guideline 2.4 Use the goal hierarchy spreadsheet (section 0 of Appendix A) to check and mark operational goals.

Guideline 2.5 Use the business idea description (Step 1) to identify goals, not listed in the goal hierarchy.

Guideline 2.6 Use the business idea description (Step 1) to relate goals and stakeholders.

Guideline 2.7 Use selected strategic goals to define if the type of an operational goal is similar to the type of at least one strategic goal selected.

4.2.10 Example

The figure below shows parts of the goal hierarchy spreadsheet. The goals, relevant for the RES producer case, are selected by putting mark in the “Apply” column.

Goal hierarchy Type Value Activity Apply Stakeholder O1. Make profit M



Page

109

Goal hierarchy Type Value Activity Apply Stakeholder G. Generate electricity G1 Increase generation efficiency M G2 Benefit from generating subsidized RES

electricity E ✔

Iberdrola Generation

… Other goal(s)

Generation

S. Supply electricity Supply D. Distribute electricity Distribution O3. Efficient market functioning R. Guarantee a fair operation of the system R1 Oblige distribution companies to connect

RES E ✔ Energy Directorate

… Other laws and obligations

Regulation

K. Fulfil Kyoto obligations E K1 Investments subsidies E K2 Develop RES promotion schemes E K2.1 Tax exemption (Netherlands,

Spain) E

K2.2 Premiums system (Spain) E ✔ Energy Directorate

… Other goal(s)

Regulation Policy making

Three goals have been selected. In this case each of the goal has an E-type (Environmental goal), which matches the type of the selected strategic goal. The selected goals do not contradict with each other. There is no need to update the goal list in this case.

The selected goals have been tested using the goal-conflict matrix. In the example below only two strategic goals have been tested conflicts. You should complete this matrix for all the operational and strategic goals.

Goal conflict matrix for Strategic goals

S1.

1

S1.

2

S1.

3


S1.1 Enter the heat business ++ 0

S1

S1.2 Increase market share ++ +

S1.3 .. 0 +

Based on the values in the table, no goals have been removed or modified for this example.

The selected operational and strategic goals are written to the Goal-Activity-Value Interface table:

Interface Goal Goal Name/Regulation description Activity

Value In Value Out



Page

110

S1.2 Increase market share S2.1 Reduce environmental emissions

G1 Benefit from generating subsidized RES electricity

R1 Oblige distribution companies to connect RES K2.2 Develop a premium system promotion scheme



Page

111

4.3 Step 3: Technology selection

Knowing the goals for a specific DG-case, the next step is to select the appropriate DG technology (note that sometimes you may want to start with a particular technology and then want to select to goals it can contribute to and the related value activities). Although many factors can influence the DG business, the technology remains crucial for the success of the business scenario, and, therefore, has to be taken into account from the very first stage of the process of business model development. Some of the DG technologies offer high efficiency, but emit a large amount of pollution; others, being environmental friendly, are not cost-efficient; and others are not suitable for an application because of the lack of continuous output. With so much to consider, it is difficult to determine which technology will deliver the best output of the scenario and achieve both operational and strategic goals.

We provide a classification of the distributed generation technologies. We do not provide a technology overview, but rather describe the characteristics of the technologies to be considered when developing the business model.

The technology characteristics classification can be used to give the preliminary requirements for the DG technology in the business case. The requirements for technology can be expressed via defining ranges of the characteristics. On the other hand, the technological requirements can also be derived from the goals of the business case. For example, the requirement to use technology with low emissions comes forth from the goal “Reduce environmental emissions”. To facilitate the determination of the technological requirements, we developed the Goal-technology checklist (see Appendix B). For details about the technology classification see Chapter 3.

Selection of appropriate technology is essential for the success of any DG project. The way technology should be selected varies. In some cases, the business idea is more oriented to support a certain technology, in other cases a business idea focuses on functionality and goals, but does not explicitly gives claims for a certain technology. Here we describe the second case when the business idea is built upon goals, and technology has to satisfy these goals.

4.3.1 Tasks to do

Task 3.1 Select technology characteristics. For each operational and strategic goal, selected in Step 2 define the necessary technological characteristics that comply with such a goal. Use the Goal-Technology checklist from Appendix B for goals, defined in the goal hierarchy, or extend the Goal-Technology checklist for goals introduced. See more information about technology characteristics in Chapter 3 and Appendix C.

Task 3.2 Determine ranges for selected technology characteristics. Assign ranges to the selected technological characteristics. See for more information about technology characteristics and their ranges in Chapter 3.



Page

112

Task 3.3 Select technological solution. Find technology to comply with ranges of technological characteristics, defined on previous step. See more information about technology in Chapter 3.

Task 3.4 Regulation constraints. Think about additional characteristics and requirements for technology that can constraint your selection. These constraints can be required by, for example, subsidizing schemes, environmental laws, available resources, etc. Formalize the regulations, which apply to this business case by using the regulations-overview and regulations-details table.

Select all the involved actors in the scenario and put them in columns next to each other in the regulations-overview table. Next, select rules, levy and subsidy which apply to the selected technology. For each rule, levy or subsidy supply the following details into the regulations-detail table: Start/end (from and to which date does this regulation apply), regulation description, formula, constrains on regulations, the involved actors for this regulation, procedures and references, viewpoint (from which viewpoint do you look at this regulation), value constraint in and value constrains out. With value constraint in you think about what the actor (seen from the viewpoint you selected) is receiving. This may be a subsidy but this could also be e.g. a certificate. In the field Value constraint out you put the rule, subsidy or levy what the involved actor(s) will receive.

Add a unique number for each row. Enter this unique number in the regulations-overview table. It is possible that a certain rule, levy or subsidy does also apply for another technology. You can use this regulations overview table to enter this row number for the applying technologies. Make sure there are no duplicate regulation rows in the regulations-detail table, use the regulations-overview table to make clear which regulation rows apply to multiple technologies.



Page

113

Regulations-overview table.

Legend: Use the following symbols:

{n} Number of regulation from the regulations-detail table − No regulation applicable

Producers Consumers

Sub

sidy

Levy

Rul

es

Sub

sidy

Levy

Rul

es

Sel

ecte

d T

echn

olog

y

Fin

anci

al

ince

nti

ves

No

n-

fin

anci

al

ince

nti

ves

Fin

anci

al

ince

nti

ves

No

n-

fin

anci

al

ince

nti

ves

Fuel cells

Steam turbines

Gas turbines

Combined Cycle Gas Turbines

Small-scale: Microturbines / Stirling engines

Combined Heat Power 1 2,4 3,5,7,9 15 13 6,10,14

Wind turbines

Solar

Micro hydro

Biomass


Waste reduction



Page

114

¬ Table 1. Regulations-detail table.

No. Start/end period

Regulation description Formula, constrains on regulation

Involved actors Procedures, references Viewpoint Value constraint in Value constraint out

1. July 2003 - unknown

Environmental Quality Energy Production Act (MEP) subsidy for generation energy for CHP, fixed fee per kWh: € 0,0057.

RA (EnerQ), TSO (TENNET), Producers

Producer generates CHP and applies for a subsidy at EnerQ. TENNET pays the subsidy on behalf EnerQ to the producer.

Producers TSO for payment of the subsidy (MEP) to the producers.

CHP generated electricity to the RA.

2. January 1st 2003 – December 31st 2003

Income VAT (6%) for each produced kWh

1 kWh RA (Belastingdienst), Producers

The Belastingsdienst charges the producer, based on their income, for the generated electricity per kWh.

Producers Regulations from RA (For general use by Government).

VAT Payment for each produced kWh to the RA (Belastingdienst).

x. .. .. .. .. .. .. .. ..



Page

115

Task 3.5 Validate the selected technology. Make sure the selected technology focuses on the important goals set in step 2. In addition, validate if the business case description and scope set in task 1.1 and 1.2 apply the selected technology.


Question 3.1 Which technology may be of use to realize the idea?

Question 3.2 What technology characteristics are essential for the business case, especially for the fulfilment of goals?


Guideline 3.1 Use Goal-Technology checklist from Appendix B to relate goals and technology characteristics.

Guideline 3.2 Use the business case description (see section 4.1 ) to identify additional technology requirements.

4.3.4 Example

Select technology characteristics. What you can see in the table that, when adding the score, the goals that would most benefit based on the selected technology characteristics are goals G1 and R2. The most important technology-characteristics for this scenario is ‘low emissions’. You can keep that in mind when selecting the technology solution.

Goal Name

Hig

h E

ffici

ency

Low

Em

issi

ons

Qui

ck S

tart

-up

Tim

e

Hig

h P

redi

ctab

ility

The

rmal

Out

put

Cap

acity

co

nstr

aint

s

Grid

con

nect

ion

Low

Cap

ital C

osts

Lo

w F

ixed

Cos

ts

Low

Var

iabl

e C

osts

To

tal

S1.2 Increase market share ✧ ✧ ✧

3

S2.1 Reduce environmental emissions ✦ 2



Page

116


✧ ✦ ✦ ✧ ✧ ✧ 8

R1 Oblige distribution companies to connect RES

✧ ✦ ✦ ✧ ✧ ✧ 8

K2.2 Develop a premium system promotion schemes ✦ ✦

4

Total: 2 8 4 2 3 3 3

Determine ranges for selected technology characteristics.

Technology Characteristics Range Low Emissions Low – Null Capacity constraints Micro – Small

According to the table in Appendix C the only technologies having null CO2 emissions are wind and photovoltaic, and with low emissions are Fuel Cells.

Therefore, the technological solution is:

Technology

Wind turbine

Solar

Fuel cells

Micro hydro

Biomass


Waste reduction

Capacity is not included in the table Appendix C, because this is an availability characteristics (see Chapter 3), and it is specific for every project. Capacity constraints imply that in this project we have to remember that the capacity of the generator influences the amount of subsidy paid to the producer. We consider this fact later in the financial analysis.

Regulation contraints. An additional characteristic that narrows our choice is the requirement of the technology to be subsidized. Remember that according to the business idea description we look only at the subsidizing scheme, not at all the technologies). According to the subsidizing rules in Spain, the fuel cells technology can be subsidized only if it functions as CHP, so we have to consider CHP instead of fuel cells. The final version of technological solution looks like the following:

Technology

Wind turbine



Page

117

Solar

CHP

Micro hydro

Biomass


Waste reduction

We selected one regulation rule for the actor ‘producers’ for the technology CHP in this example. We did not fill in all other regulations to the selected technology since this would create a very large and hard to read table in this example.

The regulation-overview table looks like this:

The regulation-details table:

No. Start/end period

Regulation description

Formula, constrains on regulation

Involved actors

Procedures, references

Viewpoint Value constraint in

Value constraint out

1. July 2003 - unknown

Environmental Quality Energy Production Act subsidy for generation energy for CHP, fixed fee per kWh: € 0,0057.

TSO, Producers

Producer generates CHP and apply for a subsidy at TSO.

Producers TSO for payment of the subsidy (MEP) to the producers.

CHP generated electricity.

Producers

Sub

sidy

Levy

Rul

es

Sel

ecte

d T

echn

olog

y

Fin

anci

al

ince

nti

ves

No

n-

fin

anci

al

ince

nti

ves

Combined Heat Power 1



Page

118



Page

119

Step 4: Value activity selection

In this step we select value activities to be included in the value model. For doing so, we use the operational goals hierarchy. The operational goal hierarchy is built in a way that every goal has an activity associated with this goal. The most common value activities in the electricity business are the following:

o Regulation

o Policy making

o Trade

o Network management

o Generation

o Transmission

o Distribution

o Supply

o Consumption

o Manufacturing

o Leasing

o Balancing

o Energy Efficiency

o Aggregation

o Metering

o Fuel Supply

o Heat Supply

o Selling of electricity

o Market management

The definition of every value activity listed above can be found in Chapter 3. Note value activities present in your value model are not limited to the list above, even though it includes value activities most common in the electricity business.

Value activities can easily be extracted from the goal hierarchy spreadsheet. As a result of



Page

120

this step we fill in the “Activity” column of the Goal-Activity-Value Interface table. Follow the instructions below to accomplish Step 4.

4.3.5 Tasks to do

Task 4.1 Select activities. Select activities associated with selected operational goals using the Goal hierarchy spreadsheet, and fill them into the corresponding cell of the “Activity” column in the Goal-Activity-Value Interface table (see Appendix F).

In addition, look at the regulation-overview table, created in task 3.4. For each of the regulations numbers for the selected technology, add an activity in the activity column. Add the regulation-description from the regulation-detail table to the corresponding selected regulation number in the ‘Goal Name/Regulation description’ column.

Task 4.2 Select additional activities. Think about other activities that may take place in order to have value exchanges. These exchanges may not have direct relation with a goal but are necessary for to have important value exchanges.

Task 4.3 Add missing activities. If some value activities were not chosen via goals analysis, but you are quite sure that it is essential to model them, then add these goals to the “Activity” column of the Goal-Activity-Value Interface table.

Task 4.4 Validate selected activities. Check whether the selected activities correspond with the goals in step 2. When you added new activities in task 4.3, make sure these activities are also visible in the goals in step 2.


Question 4.1 What activities have to be done to achieve goals selected in Step 2? Which activities can be selected from the regulation-overview table from task 3.4?

Question 4.2 What activities listed in section 3.5 of Chapter 3 are necessary to show in the value model?

Question 4.3 Are there other value activities, not listed in section 3.5 of Chapter 3, to be shown in the value model? Value activities present in your value model are not limited to those listed in section 3.5 of Chapter 3, even though it lists the most common value activities in the electricity business.


Guideline 4.1 Use the following criteria to distinguish a value activity: someone should be able to make profit by doing the activity.

Guideline 4.2 Use the operational goals selected in Step 2 and the Goal hierarchy spreadsheet (section 0 of Appendix A) to fill in the goal Goal-Activity-Value Interface table.



Page

121

4.3.8 Example

For the running example four goals have been selected (see Step 2 Goal selection).

In this step we add value activities, associated with the selected goals; the Goal hierarchy spreadsheet is used for that. The selected goals and associated value activities are written to the Goal-Activity-Value Interface table below:

Interface Goal Goal Name/Regulation description Activity Value

In Value Out

G1 Benefit from generating subsidized RES electricity Generation

R1 Oblige distribution companies to connect RES Regulation

K2.2 Develop premiums system promotion scheme Regulation

From regulation-details table

Environmental Quality Energy Production Act subsidy for generation energy for CHP, fixed fee per kWh: € 0,0057.

Regulation

4.4 Step 5: Value interface selection

In the previous step we have selected all activities necessary to model this business case. In this step we will select all value interfaces necessary for the business case at hand.

These value interfaces can be selected from a library of interfaces (See Appendix D). In this value interface library, general and optional interfaces are provided for each activity. For each selected value activity of the previous step, at least the general interface(s) should be modelled. Depending on the scope and the goals to accomplish, the optional interfaces can be added to the model.

4.4.1 Tasks to do

Task 5.1 Select general value interfaces. Select all general value interfaces for the selected activities. These can be easily found in the value interface library (Appendix D).

Task 5.2 Select necessary optional value interfaces. Except general interfaces, the value interface library also provides optional interfaces. For each optional value interface you should decide whether or not to select it.

Questions to ask are:

a. Is the exchange of value objects via this value interface needed to accomplish one of the selected goals?



Page

122

b. Is the activity exchanging these value objects?

c. Is this value interface inside the scope we use for this model?

If one of the questions above can be answered with ‘yes’, the value interface should be added to the selection of necessary value interfaces.

Example when to stop modeling:

The main purpose for constructing DG value models is to understand which actors need to be involved, which objects of economic value they exchange with each other, and if they all can do so in profitable way. A first guideline to decide whether to include an activity and performing actor or not, is to ask whether the actor can perform the activity profitably or not. For instance, in the energy industry, specific forms of obtaining fossil fuels are known to be profitable. Since these activities and actors are known to be profitable already, they need not to be considered. However, sometimes such activities/actors need to be shown in the model, at least what they are offering to and requesting from their environment. For instance, Combined Heat Power (CHP) facilities need fuel, which is an important factor to determine potential profitability of such a CHP device. Consequently, we model then a fuel provision actor, but only what it is offering (the fuel) and what it is requesting in return (the fee). We do not analyze the fuel actor for profitability itself.

For each value model, we can define three types of activities:

1. Core activities: these activities need to be examined in the business case in order to say whether these activities are profitable or not.

2. Direct environmental activities: For these activities we assume that they are profitable, so for the business case we do not analyse the question whether these activities and actors are profitable or not, but we do model the existing value exchanges in the value model and within the profitability sheets.

3. In-direct environmental activities: These activities are not core activities nor direct environmental activities. These activities are needed for the direct-environmental activities only in order for these direct-environmental activities to exist or operate. We may recognize these activities and actors when modelling a value model, but we do not draw them in the value model. In addition, these in-direct environmental actors do not have a direct connection to a core actor. In all cases the in-direct environmental actors are linked to direct environmental actors.



Page

123

In the figure below are these activity types distinguished for an Autoproducer example.

Figure 36. The tree different types of activities (core, direct- and in-direct environmental) shown for the Autoproducer example.

Task 5.3 Select or construct all goal-specific value interfaces. To accomplish a goal, certain value objects need to be exchanged. For each goal selected in step 2 (Goal selection), one or more value interfaces should be contributing to the fulfilment of this goal. Although some of the goals may be covered with the ‘optional value interfaces’ of the previous task, some goals need new value interfaces to be constructed. How to construct correct value interfaces will be discussed in detail in section 5.1.3. Make sure that all goals are covered by the current set of value interfaces. As long as this is not the case, more value interfaces need to be added, to



Page

124

represent the uncovered goals.

Task 5.4 Check completeness. For each activity the decision should be made, based on domain knowledge and business idea description, if value interfaces have been forgotten. Are there any value interfaces, which must be regarded because of regulation, requirements or constraints? If so, these should be added.

Task 5.5 Check correctness. The last thing to do is to check whether each value activity is correct. For each value interface, question if this value activity really yield profit or increase economic value for a performing actor? Do incoming value objects match the needs to perform this activity? Do outgoing value objects match the output of this value activity? If all questions can be answered yes, no action is needed. If one of these questions is answered ‘no’, tasks 5.1 to 5.3 need to be done again to complete and correct this value interface.


Question 5.1 Are all generic value interfaces selected for each activity?

Question 5.2 Are all goals (selected in Step 2) covered with the current set of value interfaces?

Question 5.3 Are there any value interfaces, which must be regarded because of regulation, requirements or constraints?

Question 5.4 Does a value activity really yield profit or increase economic value for at least one performing actor?


Guideline 5.1 Use the value interface library to find generic and optional value interfaces

Guideline 5.2 Use the list of selected goals (Step 2) to add goal-specific value interfaces

Guideline 5.3 Use the business idea description (Step 1) to extract other missing value interfaces

Guideline 5.4 Use the guidelines from section 5.1.3 to construct value interfaces, if needed

4.4.4 Example

For the RES producer case, we start with the results of the previous step, the list of activities. These activities are: generation, regulation, and distribution.

o Select generic value interfaces. First we select for each activity the general value



Page

125

interfaces from the library. For generation this is value interface 5.1 from the library, numbered 2 in the figure below (electricity <-> fee, in this case renamed to RES electricity <-> fee). Regulation has no general value interfaces, because regulation can have many goals and many implementations. Distribution has one general value interface, 7.1 in the library, numbered 7 in the figure (T&D fee <-> Distribution). The numbers in the last column in the Table 12 refer to the Figure 37.

Table 12. General interfaces.

General Interface Interface in the model Activity

Value In Value Out Value In Value Out Figure 37

Generation Electricity fee Electricity Fee RES electricity

2

Distribution T&D fee Distribution T&D fee Distribution 7

o Select or construct all goal-specific value interfaces. Now we take a look at the goals of each activity as defined in the first two steps. The goal of generation is to “benefit from generating subsidised electricity”. So generation needs to receive RES subsidies for their generation of RES. The value library provides no optional interface to this value exchange. So we construct our own value interface, where RES subsidy is provided in exchange for RES generation. Value interface 1 is added to our list. Regulation has two goals: “Develop RES/DG premium promotion scheme” and “oblige distribution companies to connect RES/DG”. For both goals, the library provides optional value interfaces. The first goal can be accomplished with value interface 1.2, the second goal with 1.3. The value object of these value interfaces are renamed, to provide a more specific description of each value object (e.g. subsidy is renamed to RES subsidies and ecological benefits is renamed to RES generation). To accomplish the goal “Oblige distribution companies to connect to RES”, a new value interface is constructed, because the value interface library provides no optional value interfaces to accomplish this goal. The value objects of this value interface, and the others, can be found in Table 13.

Table 13. Goal specific value interfaces.

Interface Goal Goal Name Activity Library

reference Value In Value Out Figure 37


Generation - RES subsidies

RES generation 1


Regulation 1.3 Fulfilment Obligation to accept DG 5

K2.2 Develop premiums system promotion scheme

Regulation 1.2 RES generation

RES subsidies 4

o Check completeness. Based on domain knowledge and business idea description, we do not consider any other value interfaces regarding regulation or any other constraints.



Page

126

o Check correctness. In the last step we check if each value activity is correct. Generation is OK, income from sale and extra income from RES subsidy may yield profit. Regulation is incorrect. This activity provides RES subsidy, but without any income for doing so. Consequently we have to add a value interface that provides income for regulation to allow for provision of RES subsidies. A way to implement this is to oblige another activity to pay RES taxes. So value interface 3 (RES taxes <-> obligation) is added.

Interface Activity

Value In Value Out Figure 37

Regulation RES Taxes Obligation 3

Now regulation is correct. Distribution is also correct: it delivers distribution services and retrieves T&D fee in return.

The result of step 5 is a set of activities including all necessary value interfaces. This is shown in Figure 37.

GenerationRES subsidies

RES generation fee

RES electricity

Regulation

RES taxes

obligation RES generation

RES subsidies

DistributionT&D fee

distribution

fulfillment

obligation toaccept DG


fulfillment

1 2

3 4

5

6 7

Figure 37. Graphical model after step 5.



Page

127

4.5 Step 6: Ports connection

In the previous step we have selected necessary value interfaces to model the business case at hand. We have a ‘unconnected’ value model. In this step we connect all value interfaces with each other to get a ‘connected’ value model. It’s like completing a jigsaw puzzle, the pieces are available and this step is to get the picture.

4.5.1 Tasks to do

Task 6.1 Make trivial connections. First of all trivial connections can be made. Trivial connections are those value exchanges with similar value objects which can obviously be connected. In this way most ports of the value interfaces can be connected.

Task 6.2 Rename to connect. For the remaining unconnected value interfaces each possible ‘couple’ of exchanges should be considered for connectivity. Maybe some renaming should be done to make this possible.

Task 6.3 Add missing activities and interfaces. It is possible that one or more value interfaces cannot be connected with others. Then there are two possibilities: a value interface is forgotten or an activity is forgotten. If the remaining interface should connected with an already modelled activity, return to step 5 to add an interface. If it cannot be connected with an existing activity, an activity that should have been modelled is forgotten. In this case the missing activity should be identified, and return to step 4 to add this activity.


Question 6.1 What interfaces connect, in other words, what interfaces have similar value objects?

Question 6.2 Can all value interfaces be connected?


Guideline 6.1 Use the value model you built so far.

Guideline 6.2 Use the value interface library (Appendix D) to find possible activities to connect value exchanges. Each value interface has a set of activities with which it connects.

Guideline 6.3 Use the guidelines of chapter 6 to check the correctness of the value activities and exchanges.



Page

128

4.5.4 Example

The result of the previous step was presented in Figure 37. We use the numbers mentioned in this figure and we try to connect these value exchanges.

o Make trivial connections.

Value interface 1 can be connected with 4. Value objects are identical: regulation offers RES subsidies directly to generation, and RES generation is offered in return. Value interface 5 can be connected with 6. The value objects are the same: regulation obliges distribution to accept DG. The model we create after performing these connections is shown in Figure 38.

Figure 38. Graphical model after making connecting trivial connections of value interfaces.

o Rename to connect. Three value interfaces are not connected yet. There are no similar objects exchanged, that is why the renaming procedure cannot help to connect them. New activities and value interfaces have to be added to complete the model.

o Add missing activities and interfaces. Value interface 2 should deliver electricity to some value activity and obtain a fee in return. According to the value interface library, the activity that possesses a value interface, “fee <-> electricity”, reverse to the value interface 2, is the supply activity.

Table 14. Added activity: Supply.

Standard Interface Interface in the model Activity

Library

Reference Value In Value Out Value In Value Out

Supply 8.1 Electricity Electricity fee RES electricity Fee

8.2 T&D services T&D fee Distribution Fee



Page

129

8.3 Electricity retail fee

Electricity Retail fee Electricity

We connect value interface 2 to the supply activity. Value interface 7 “Distribution services <-> fee” can also be connected to the correspondent generic interface of the supply activity “Distribution <->T&D fee”, if the latter is renamed.

Finally, the supply activity has one unconnected value interface left: “Retail fee - Electricity”. This interface notifies the delivery of electricity to the consumption activity. So we go back to step 3 to introduce the consumption activity, and connect correspondent value interfaces.

The final graphical model is shown in Figure 39.

Consumption

GenerationRES subsidies

RES generation

fee

Regulation

DistributionT&D fee

distributionobligation toaccept DG

fulfillment

Supply

RES taxes

obligation

RESelectricity

retailfee electricity

Figure 39. Graphical model after step 6.

Actually, this is almost a complete value model; all activities are modelled and connected. The only step to complete the value model is to assign each activity to a performing actor.



Page

130

4.6 Step 7: Actor selection

Except for the absence of actors, the value model is complete now. The next step is to assign an actor to each of the modelled activities. Each activity should be performed by an actor. This is not a strict one-to-one relation. Some actors perform more than one activity, and in some cases an activity should be divided over two actors. In the latter case a value activity is split, and value interfaces are added. We will explain this later.

If all activities are assigned to actors, some grouping and layout work can be done to make the value model understandable.

4.6.1 Tasks to do

Task 7.1 Assign actors to activities. For each activity, the performing party has to be assigned. A helpful resource is the activity/actor matrix from Appendix H. This matrix provides for every activity which actor can perform it. The first step is to recognise the trivial activity/actor combinations and to assign the corresponding actors to these activities. For example, ‘distribution’ is performed by ‘DSO’. Notice that often one actor performs more than one activity.

For the remaining activities, you should ask yourself for each value interface who is actually receiving the incoming value objects, and who is offering the outgoing value objects. The answer to these questions is the performing actor.

If still activities remain unassigned, there are two options. First, no actor has been foreseen to perform this activity. A new, not yet existing actor should perform this activity. Think of a name for such an actor, and assign the activity to this actor. Second, an activity can not be assigned to an actor because its performed by two or more actors. In the latter case, splitting of the value activity is needed.

Task 7.2 Consider splitting value activities. The assignment of actors to activities might still be incorrect. Activities may remain unassigned, or some actor-activity combinations may be incorrect because actually two or more actors are performing an activity. In this case such activities may need to be split. For each unassigned activity, you need to check whether it actually is a combination of activities performed by more than one actor. For each assigned activity, you should check whether this activity is in fact a combination of multiple activities. To check this, ask the following questions for each value interface of each actor:

o Is the actor really receiving the incoming value object?

o Is the actor really offering the outgoing value object?

o Are both parties aware of this value exchange?

If one of the answers of these questions is ‘no’, it can be the case that a part of this value activity is performed by or outsourced to another party. In this case the activity should be



Page

131

split.

Task 7.3 Splitting. Whether an activity needs to be split, should be based on the question “which actor is performing which value exchanges?”. A correct activity consists of value interfaces, which are offered by the same actor. Likewise, the value interfaces are split to new activities, according to the actor offering the value interfaces. For each value interface of the activity to be split, should be considered which actor is offering this value interface. If a certain activity seems to be a combination of n different activities, you start by drawing n new activities (n rounded rectangles), if possible with more specified names (For example, ‘electricity transport’ can be split in ‘distribution’ and ‘transmission’). For each value interface of the old activity, you decide to which new activity it should be moved. If all value activities are moved to a new activity, the old activity can be removed. When an activity is split, it may be needed to introduce one or more new value exchanges between the new activities. A good example is shown in Figure 41, where regulation is split in two different regulation activities (because one part is performed by the Electric System Regulation, and the other by the DSO, but this will be discussed in detail later). One of the new activities receives RES taxes, while the other pays RES subsidy. RES subsidy should be paid from RES taxes, so in one way on another the ‘receiving’ activity should exchange the RES taxes/subsidy with the ‘paying’ activity. So a new value interface (RES subsidy <-> RES generation) is introduced.

Task 7.4 Grouping. Now all activities are assigned to their performing actors. Some actors may perform more than one activity. Those activities, performed by the same actor may be scattered throughout the model. So the last step is to do some layout work; grouping and moving activities and actors so that the value model is more readable. For example, see the difference between Figure 41 (B) and Figure 42, where the regulation activity performed by the DSO is moved to a place near the other activities of the DSO.

Task 7.5 Check for completeness. In this step you check whether no actors or activities have been forgotten in the model. The list of actors so far is based on the list of goals in step 2. It may be possible that some actors are not mentioned in the model, but needs to be analysed. In step 10 and 11 we will present profitability sheets and evolutionary scenarios for each actor in the model. If these financial models are needed for actors who are not modelled yet, these actors should be added to the model now. To add an actor, step 4 to 7 have to be performed again to introduce the activity performed by the missing actor.

Task 7.6 Identify market segments. After all the actors are grouped, the market segments should be identified. Some activities are performed by one actor, like regulation or distribution. Other activities are performed by a group of actors who are supposed to value objects equally. This is called a market segment. For example, a market segment can be a large group of final customers, each of them buying electricity and paying a fee for it. We do not model these actors individually. Graphically, a market segment is shown as three stacked actors, see Figure 40. In this figure only one supplier exists in the value model, but multiple consumers exist, which are grouped into a market segment.



Page

132

Figure 40. Market segment.


Question 7.1 Which actors perform the activity in this case?

Question 7.2 Is the actor really receiving the incoming value object?

Question 7.3 Is the actor really offering the outgoing value object?

Question 7.4 Are both parties aware of this value exchange?

Question 7.5 Are all the activities of the actor grouped?

Question 7.6 Are there actors missing?


Guideline 7.1 Use Table 11 (Activity-Actor table) to assign some actors to activities

Guideline 7.2 Check with the goal list (see Step 2), that the actors performing the operational goals match the actors exchanging correspondent value interfaces.

Guideline 7.3 If some activities remain unassigned, use the business idea description (Step 1) to discover additional actors

Guideline 7.4 If an actor who is part of a market segment had additional value interfaces, which other actors of that segment do not have, that actor should be modelled explicitly.

Guideline 7.5 Think about what is the scope of your analysis in terms of region, number of parties participating, and detail level. Use and extend the business idea description for that (Step1). Do not model actor and activities which fall outside the scope of analysis.



Page

133

4.6.4 Example

The result of the previous step was the connected value model, presented in Figure 39. Now we are going to assign each activity to its performing actor. We start with the trivial activity/actor combinations, based on domain knowledge and the activity/actor matrix of paragraph 4.4.

Assign actors to activities. Generation is obviously performed by a producer, a RES producer in this case. Distribution is in almost al cases, surely in this case, done by the DSO (Distribution System Operator). Consumption in this case is performed by final customers. So we draw these actors as rectangles around these activities in the model. Another easy to understand assignment would be to assign supply to supplier. But in this particular case this is not correct, because the supply is done by DSO.

One activity is remaining: regulation. The activity/actor matrix tells us that this activity is regulatory assigned to regulatory authorities. But in this specific case regulation is delegated to the market operator. So we assign the regulation activity to the market operator.

No other activities remain unassigned. No new, non-existing, actors should be introduced. The results so far are shown in Figure 41 (A).

Market Operator

DSO

Regulation

Regulation

RES gen.

RES subsidy

RES Producer Market Operator

DSO

Consumer

Supply

Generation

Distribution

Regulation

Consumption

RES electricity fee

RES generation RES subsidy

obligation to accept DG fulfillment

electricity retail fee

RES taxes

obligation

Distribution services

fee

RES Producer

DSO

Consumer

Supply

Generation

Distribution

Consumption

RES electricity fee

RES generation RES subsidy

obligation to accept DG fulfillment

electricity retail fee

RES taxes

obligation

Distribution services

fee

(A) (B)

Figure 41. Assigning actors and splitting.

Splitting. Now we ask ourselves for each value interface of each actor the following questions:

o Is the actor really receiving the incoming value object?

o Is the actor really offering the outgoing value object?

o Are both parties aware of this value exchange?



Page

134

These questions can be answered positive in all cases, except the value exchange of RES subsidy for RES generation between the market operator and regulator. Domain expertise tells us that the RES subsidy for RES generation is actually exchanged by the DSO and the RES producer. So the regulation value activity should be split up, so that DSO is paying RES Subsidy to the RES producer.

But if we split it up, a new value exchange should be added, because the Market Operator receives the RES taxes to pay RES subsidy. They pay this RES subsidy to the regulation activity of the DSO, who pays it in its turn to the RES producer. The results until now are shown in Figure 41 (B).

Grouping. Last step is to layout the model so it is more understandable. Because of the splitting up of the regulation activity, DSO has three activities now. These activities should be graphically grouped together into one actor ‘rectangle’. You can see this in the right value model of the figure below. Notice that the only change is to move the DSO-regulation part; the rest of the model remains the same.



Page

135

RES Producer

DSO

Consumer

Market Operator

Generation

Supply

Regulation

Regulation

Consumption

RESelectricity

feeRES

generationRES

subsidy

subsidy

RES generation

electricityfee

RES tax

obligation

Distribution


fulfillment

T&Dservices

fee

Figure 42. The model after grouping.

Check for completeness. The model in Figure 42 considers the renewable producer only. However, as we know from Step 1, the region we consider has other producers, which are not renewable. The non-renewable producers generate about 2500 GWh electricity a year. It is also important to consider non-renewable producers, because they also pay taxes. And, what is very important, they also pay a RES tax. So we add the Producer actor. Since these producers are not distributed generators, transmission is needed for the transport of electricity, so a TSO actor is added also. (See Figure 46) Notice that the addition of these new actors is done by redoing the steps 4 to 7 for these activities and actors.

Identify market segments. In this scenario there is more than one Consumer, Producer and RES producer. It is a whole region of consumers, so we extend the notion of a single consumer by the notion of the correspondent market segment. We also want to analyse the scenario for the Bask autonomous region, i.e. more than one RES producer has to be



Page

136

considered; that is why for the RES producer we introduce the market segment notion rather than a single actor. The same goes for the Producer. Although there is more than one DSO in Spain, we show only one actor in the model, because there is only one DSO (which is Iberdrola Distribution) in the region under consideration. There is only one market operator (which is OMEL) in the region. The result is shown in Figure 43.

RES Producer

DSO

Consumer

Market Operator

Generation

Supply

Regulation

Regulation

Consumption

fee

RESgeneration

RESsubsidy

subsidy

RES generation

electricityfee

Producer

Generation

electricityfee

RES tax

obligation

Distribution

TSO

Transmission

T&Dservices

fee

feetransmissionservices

RESelectricty

fulfillment


Figure 43. The complete value model.

4.7 Step 8: Scenario Path Identification

In section 3.5.1.1 we have introduced the concept of scenario paths. Step 8 is about the identification of scenario paths in the value model. To summarize the concept of a scenario path: A scenario path is used to explicate cause-effect relationships by travelling over paths through a system. By travelling over the scenario path you can see which actor starts to exchange, and what exchanges are done as a result of this start. Scenario paths allow to count the number of value exchanges in a given time period; count ability is important to do profitability analysis.

4.7.1 Tasks to do

Task 8.1 Use scenario paths from reference model. Sections 3.5.1.2.19 and 3.5.2 describe a reference value model. This model contains a scenario path, which can be used as a reference for constructing scenario paths. In section 3.5.1.2 all value



Page

137

activities are shown with an example scenario path. In most cases scenario paths can be constructed by using these examples. If this is impossible or unclear, task 8.2 to 8.5 explain how to build scenario paths from scratch.

Task 8.2 Identify the start stimulus. The start stimulus represents which actor starts a scenario. The start of a scenario is always a need, in many cases a consumer need. Think about which actor has a (consumer) need. In many cases this will be the consumer.

Task 8.3 Identify parts of a path within an actor. A scenario path enters an actor by (1) a start stimulus or (2) an incoming path from one of its value interface with other actors. Question for each incoming scenario path or start stimulus via which value interfaces an actor has to exchange value objects as a result of this event. Now, the scenario path enters another actor. Question for this actor again what value interfaces are needed as a result of the value interface where the scenario path enters. To continue with the example, the scenario path enters the actor ‘Supply’ by the value interface ‘electricity <-> fee’. Which value interfaces is needed to provide electricity? In this case more than one value interface are needed. Electricity needs to be bought, and transmission and distribution is needed. When multiple value interfaces need to be performed all together, an AND-fork should be added to the path. If an actor needs to choose one value interface out of multiple possibilities, an OR-fork needs to be introduced. Examples for scenario paths for each activity are provided in chapter 4.

Task 8.4 Identify stop stimuli. In some cases, a scenario path enters an actor, and this actor does not need to perform any other value interfaces. In this case a stop stimulus is drawn. A stop stimulus indicates that we do not consider any other value interfaces (and thus financial effects) anymore. A scenario path is complete when all paths are ended with a stop stimulus.

Task 8.5 Question completeness. When a scenario path is complete, question if you identified all scenario paths. Are there any scenarios possible that are not identified yet? What (consumer) needs can be identified? What scenarios of interaction between the actors can be identified? If scenarios need to be added, start again with the identification of a start stimulus.

Task 8.6 Mark operational expenses. There are also means to include operational expenses into the calculations. We distinguish variable and fixed operational expenses.

Variable operational expenses of an actor are a result of doing a value activity, and they change in direct proportion to the volume of value objects exchanged by this actor. Graphically, variable operational expenses are shown with a “cross” on the part of the scenario path which touches the correspondent value interface. As shown in Figure 44, by putting a “cross” at a part of the scenario path that touches a Producer’s value interface, we notify the operational costs that vary according to the volume of the outgoing value object Electricity exchanging via this value interface.



Page

138

Supplier Producer

Wholesale Fee

Electricity

Figure 44. A notation for variable operational expenses.

The “cross” on the producer’s scenario path notifies variable operational expenses of Producer, and results in the following changes in the profitability sheets (see Step 10): the profitability sheet of the Producer acquires an ingoing object Maintenance, and outgoing object Maintenance fee. Consequently, the Electricity will be a parameter in a formula for the Maintenance fee.

Fixed operational expenses on an actor are expenses that remain unchanged in total for a given timeframe despite changes of volume of value objects exchanged by this actor. Graphically, fixed operational expenses are shown with a “cross” on a rectangle specifying an actor. As shown in Figure 45, by putting a “cross” on the Producer, we notify the operational costs that are fixed and do not depend on the volume of value objects exchanged by the Producer. According to this notation, the profitability sheet of the Producer acquires ingoing object Maintenance, and out going object Fixed maintenance fee.

Supplier Producer

Wholesale Fee

Electricity

Figure 45 A notation for fixed operational expenses


Question 8.1 What (consumer) needs can be identified?

Question 8.2 What value exchanges need to be performed to fulfil this (consumer) need?

Question 8.3 Are all scenario paths identified? Are there (consumer) needs not yet represented in a scenario path?


Guideline 8.1 Base start stimuli on an end-consumer need



Page

139

Guideline 8.2 Ensure all the value object exchanged are captured by scenario paths

Guideline 8.3 Refer to section 3.5.1.1 about scenario paths

Guideline 8.4 Use an OR construct if an actor can choose from a number of value interfaces of other actors to satisfy his/her needs

Guideline 8.5 Use an AND construct if an actor must use multiple value interfaces to exchange values to satisfy his/her needs

Guideline 8.6 Use other guidelines of chapter 6.

4.7.4 Example

The scenario starts when a final customer wants to purchase electricity in return for a fee. At the DSO the scenario path has an AND fork, and it splits into three subpaths:

One subpath has an OR fork, which say that there is a choice for distribution company to buy electricity from the Producer or from the RES producer.

1) The DSO buys electricity from the RES producer; in addition to purchase of electricity, the DSO performs two other value exchanges: it obtains RES subsidy from the Market Operator and pays this subsidy to the RES producer.

2) The DSO buys electricity from the Producer; it pays only an electricity fee.

The second sub path of the AND-fork shows the obligation to pay RES taxes. Note that both RES producer and producer pay RES taxes (that is why we use the AND-fork here).

The third path illustrates that the DSO has to fulfil an obligation to accept DG. The consequence of that obligation is also reflected by making the path to the Producer dotted. This says that the decision (OR-fork) to buy electricity from the Producer can be done ONLY if all the electricity from the RES producer is bought.

Finally, we are going to take into account fixed operational expenses for DSO and TSO, which is depicted with crosses on the actors in the graphical model. In principal, we have to take into account operational costs for RES producer and Producer. However, in their cases we do not model operational expenses, because, first of all, in this analysis we focus on the subsidizing scheme, rather then on profitability of these actors, and, secondly, it is more appropriate to investigate the profitability of a RES producer in the investment analysis, which is done in section 4.11 .



Page

140

RES Producer

DSO

Consumer

Market Operator

RESelectricity

feeRES

generationRES

subsidy

subsidy

RES generation

electricityfee

RES tax

obligation to transfer taxes

Producer

electricityfee

(1)(2)

OR-fork

AND-fork

1

3

4

56 7

TSO

feeTransmission

servces2

Other taxesand fees

(3)

Figure 46. The final model to be analysed.

4.8 Step 9: Information System Model construction

Now we have constructed a correct value model, we shift our view towards the information system needed to support such a model. In a future world characterised by distributed generation, the importance of ICT systems will increase more and more. The expenses related to these systems should be taken into account when calculating the prospects of a DG business idea. In this step we will construct an Information System Model, which describes the physical allocation, ownership and communication of hardware systems and software systems. Based on this model we can roughly estimate the expenses related to the ICT system for each actor.

These calculations of expenses (both investments and operational) are the main reason to construct an Information System Model. This calculation is only necessary if the needed software systems need substantial investments and/or operational expenses. Substantial means here: substantial in relation to investments for DG technology for the case at hand. If these investments are in the order of magnitude of million euros, we don’t need to construct an Information System Model for software systems with investments and expenses in the order of magnitude of thousand euros.



Page

141

4.8.1 Tasks to do

Task 9.1 Make a list of needed, expensive software systems. Some activities or tasks may require a software system. For each activity, or set of activities, think of needed software systems. In the Information System Model we want to represent only those software systems that need substantial investments and/or operational expenses.

Task 9.2 Define quality parameters. For each software system, define the quality parameters to which these systems need to comply. Only quality parameters, which influence the price and maintenance expenses of a software system, should be taken into account. Some parameters, which should be defined, are: Hardware reliability, performance, storage capacity, needed bandwidth, latency, etc. Notice that the definition of quality parameters may strongly influence the expenses of software system. For example, 99,9999% hardware reliability triples the price of 99% hardware reliability.

Task 9.3 Make a list of needed hardware systems. Each of the software systems mentioned above, should run on a hardware system (desktop computer/server/etc.). For each software system, mention the hardware system on which it will run. By placing a software system on a hardware system, take the quality parameters in account. Remember that multiple software systems can be placed on one hardware system.

Task 9.4 Define interaction between software systems. For the proper functioning of the system, actors and their software systems should communicate. In this step you define which software systems should communicate with each other.

Task 9.5 Define needed hardware connections. If two software systems communicate, a connection between these systems is necessary. For each couple of communicating software systems, define which connection is needed. When the two software systems are on different hardware systems, a physical connection (like a Wide Area Network) is needed. All physical connections impose operational expenses. Connections with substantial expenses, and thus most importance in this step, are comprehensive WANs (Wide Area Networks). To estimate operational expenses on WANs (and other connections) the following quality parameters are needed:

o Bandwidth

o Latency

o Physical distance to bridge

o Required uptime (e.g. 99% or 99.9999%)

o Number of physical sites to interconnect

Task 9.6 Model this knowledge in an Information System Model. Based on the knowledge of the previous step, an Information System Model can be easily realised. Start with the value model and remove al interfaces and exchanges (these aren’t needed in an Information System Model). In this ‘empty value model’ you can place all hardware and software systems, communication and connections using the symbols presented in Figure 47.



Page

142

Inte

rface

Figure 47. Information System Model Example.

An Information System Model models ownership of hardware systems, software systems and connections. Since all these systems and connections are assigned to a value activity and all value activity are assigned to actors, ownership of the system and connections and the related costs are clear.


Question 9.1 What software systems are currently used?

Question 9.2 What expensive software systems will be necessary to use in the system?

Question 9.3 What quality parameters need to be defined? (e.g. reliability, bandwidth, real time performance)

Question 9.4 What influence do these quality parameters have on price and cost?

Question 9.5 On which hardware system should these software systems run?

Question 9.6 Which software systems need to communicate with each other?

Question 9.7 At which site are the hardware systems located?

Question 9.8 Which connections between hardware systems are needed? (in particular: Which WAN are needed between hardware systems?)



Page

143


Guideline 9.1 Fowler, M & Scott, K. (2000), ‘UML Distilled, 2nd edition’, Addison Wesley Longman

4.8.4 Example

In our example, there are no expensive software or hardware systems needed. For the sake of the example, we will model the SCADA-software of the RES producer, the only known software system used in this example.

Our list of needed software thus contains:

o SCADA Software. SCADA stands for Supervisory Control And Data Acquisition. Essentially SCADA is a software package designed to display information, log data and show alarms. This can be graphical and tabular formats, words or pictures. This data is for the producer’s information only, for the proper functioning of the PV panel.

Since malfunction of the SCADA Software will not influence the performance of the PV panel, there are no specific quality parameters for hardware reliability, performance, storage capacity, needed bandwidth, latency, etc. So any standard equipment for SCADA systems on the market will provide sufficient quality parameters.

Now we need to make a list of needed hardware. In this example we will use the Sunny Boy Control+ SCADA System, recommended by Iberdrola. A data acquisition and diagnosis unit is connected with the PV panel, for gathering data, and a Personal Computer to analyse this data. So we need the SCADA device itself and a PC.

List of needed hardware:

o SCADA device

o Personal Computer

Next step is to define interaction between different software systems. Since we defined only one software system, there won’t be any interaction.

For the last task, a hardware connection between the SCADA device and the PC is needed, to communicate and interpret the gathered data. This connection is a RS-232 connection, a standard connection which is provided with the SCADA device. The SCADA system is for the producer's information only, and all communication between other actors do not need a digital/electrical connection.

With this information we can compose the Information System Model in Figure 48. To make the model more simple, we reduced the size of the all the actors but the RES producer.



Page

144

DSO

Consumer

MarketOperator

Producer

TSO

RES ProducerWindows PC

RS 232

SCADA Software

Sunny Boy Control+

Figure 48. Information System Model.



Page

145

4.9 Step 10: Base-line profitability sheets calculation

Evaluation of a business scenario focuses on the question whether a scenario is feasible from an economic point of view, and whether a scenario is profitable for each actor involved. To asses profitability we (1) create profitability sheets for each actor involved in the value model, (2) ask actors to assign economic value to objects delivered and received, and (3) use evolutionary scenarios to determine effects of expected changes in the future that influence profitability. In this section we describe first two steps, and the third step is described in the next section.

4.9.1 Tasks to do

Task 10.1 Create profitability sheets by following scenario paths (see section Step 8: Scenario Path Identification). For each actor create a profitability sheet, which includes in- and out-going objects, and probability for each path coming out of OR-forks.

The structure of a profitability sheet of an actor is shown in Appendix G. A profitability sheet is constructed for each actor involved by following the scenario path. To understand how the profitability sheets are constructed, read the following steps and use Figure 49 as an example.

Step A. Start at the start stimulus and follow the path;

Step B. If you encounter on the path a value interface, and objects are leaving and entering the actor, then update the profitability sheet of that actor:

i. Fill in outgoing objects in the column “Value Object Out”

ii. Fill in ingoing objects in the column “Value Object In”

Step C. Follow the value exchange(s) connected to the value interface, to find the other interface(s) called peer interfaces connected to this value interface. Since value objects are crossing, update the profitability sheets of the actors owing these peer interfaces;

Step D. Continue the path at the peer interfaces. If the end-stimulus is reached, the paths ready.



Page

146

A B

X

Y

STEP A

STEP D

Value Object In Value Object OUT Y X

Actor: A Value Object In Value Object OUT

X Y

Actor: B

STEP B STEP C START STIMULUS

END STIMULUS

PEER VALUE INTERFACE

Figure 49. An example of profitability sheet creation.

What should we do if we encounter OR- or AND-constructions on the scenario path? Below we explain how to handle these special cases.

Special case 1 OR-constructions

OR constructs model that an actor can choose which path to follow. For example, Figure 50 actor A can choose to satisfy his need by exchanging objects via interface #1, by exchanging objects via interface #2. OR constructs (see Figure 50) result in multiple routes, and, therefore, should be handled differently. Use the following steps to create profitability sheets when your diagram has OR-forks:

Step A. Start at the start stimulus and follow the path;

Step B. If you encounter an OR-fork, find the probability that one of the continuation paths is chosen and follow that path;

Step C. If the path you follow encounter value interfaces, just act as in the general case, but add to profitability sheets a probability.

Figure 50 illustrates an example of OR-fork in the scenario path, and the corresponding profitability sheets.



Page

147

A

C

Value Object In Value Object OUT

Y1 X1

Actor: A

B

X2

Y2

Y1

X1

40%

60%

Y2 X2

60%#1

#2

40%


X1 Y1

Actor: B

60%


X2 Y2

Actor: C

40%

Figure 50. An example of profitability sheet creation: OR-construction.

Special case 2 Multiple value exchanges

Another variation that can occur is a value interface exchanging value objects with more than one value interface. An example of this specific case is shown in Figure 51.

A

C

I2

B

I3

I1

X

Y

Y

X

Figure 51. An example of multiple exchanges of a value interface.

In this case, exchanges via interface I1 of actor A can be with B or with C (or both). You should account for that in the profitability sheets for B and C. For example, you might suppose a probability for the distribution of exchanges via B and C, and handle this construction in the same way as the OR-constraint (see the previous section).

Special case 3 Handle AND-constructions

An AND construction introduces multiple paths (see Figure 52). In this figure the AND fork models that to satisfy his need actor A has to exchange value objects via interface #1 and interface #2. In this situation, the paths after the AND-fork are treated as paths that, as a result of a start stimulus, are both executed. Consequently, there is no need for a probability; both paths count for 100%. Of course, you have to consider them both in the sheets.



Page

148

A

C

B

X2

Y2

Y1

X1

AND

#1

#2

Figure 52. An example of AND construction.

Task 10.2 Determine timeframe and common measurement units

Each scenario path results in a set of profitability sheets, which consist of a set of ingoing, and outgoing value objects. Further values are assigned to the value objects with the help of valuation functions. In order to assign values to value objects correctly, it is important to stick to a common timescale and a common dimension for value objects of the same type.

Dimension.

All the value objects of similar type should be measured by the same dimension. For example, in Figure 53 the electricity value object exchanged between the customer and supplier should be measured in the same units (e.g. GWh). It is wrong, if one value object is measured in GWh per year, and the other one in MWh/month.

Consumer Supplier

Retail Fee

Electricity

Producer

Wholesale Fee

Electricity

Figure 53. Example of a value exchange in the electricity sector.

Timeframe and number of scenario occurrences.

To calculate profitability for each actor involved, we need to know the number of scenarios per timeframe. Each scenario path starts with a start stimulus, which usually expresses a consumer need. For example, the start stimulus in Figure 53 can be interpreted as the consumer’s need to have electricity. A start stimulus is a driver for scenario paths. Consequently, to estimate the number of scenario occurrences we need to estimate the



Page

149

number of start stimuli occurring per timeframe.

First, choose a timeframe, for which you want to evaluate the scenario. It can be a day, an hour, a month, a year etc. For example, in a statement “In a particular region in year 2001 there was 100 GWh of electricity consumed” it is assumed that the timeframe is a “YEAR”. If you selected a particular timeframe, the values of all the value objects in the model should be calculated in terms of this timeframe.

Then calculate how many start stimuli occur during the selected timeframe. The number of start stimuli means the number of actors in a market segment holding this start stimulus. For example, in Figure 53 each consumer needs in average 10kWh electricity per year. So as a result of one stimulus execution 10kWh electricity is traded within one year. In the market segment of consumers there are, say 10.000 consumers who have needs for electricity (10.000 is a number of stimulus), so in total during one year 100 GWh electricity is delivered to consumers. All the further values of objects have to be calculated in terms 10.000 consumers and 10 GWh of electricity per year.

Task 10.3 Determine valuation functions

For ports exchanging money objects, determine valuation functions. Such a function calculates the amount of money to be paid or to be received for obtaining another value object(s) via ports of the same value interface.

Note that the valuation function should return a value in monetary units. For example, the fee of electricity in the value exchange shown in Figure 53 can be have the following valuation function:

Fee [Euro/year] = Electricity price [Euro/GWh] X Electricity Consumed [GWh-year]

An outgoing object, e.g. representing a payment in the form of money (in Euro), has a valuation function that represents the amount of money to be paid for an ingoing object (e.g. 1kWh electricity). As in the example in Figure 53, the ingoing fee is the amount of money to be paid for the outgoing electricity.

In most cases the function is more complicated, and includes taxes and other additional payments. In some cases, for example a tariff structure and pricing functions can be utilized for a valuation function.

Enterprise and end-consumer actors

There is a difference in handling enterprises and end-consumers when estimating their profitability. For enterprise actors not all ports need to have valuation functions, but only those having money value objects. For end-consumer all value ports need valuation functions, but only in case you need to analyse effects for end-consumer. Use the following guideline:

o Ports of enterprises need only valuation functions if these ports represent money (e.g. payments, fees). For enterprises we are only interested in the net-cash flow. See Chapter 6 for more details.

o All ports of end-consumers need valuation functions, i.e. not only ports exchanging money objects. In this way we can evaluate whether customers are really interested



Page

150

in the products they obtain. For non-money objects, as estimate should be given of the economic value of such products, assigned by the customer. To learn more about consumer values see Chapter 6.

To identify whether an actor is an enterprise actor or end-consumer actor, analyse value activities of this actor. Enterprise actors produce, resell or distribute objects to make profit, or at least to cover their expenses. In the electricity sector these are actors, performing any activity except consumption. End-consumers do not resell value objects, but use these obtained objects, and, in terms of terminology provided in Chapter 3, they perform consumption value activity. In some cases an actor performs the consumption value activity together with other value activities: such an actor can be handled both as enterprise and end-consumer.

Task 10.4 Collect data

After valuation functions of each value object are known, collect data to be substituted into formulas. To understand what data you need, look at the parameters of every valuation function and collect all numbers you need to retrieve numeric values of functions. Remember that collected data must stick to the timeframe and common measurement units selected in Task 10.2.

In addition, we should also mention, that the data collection process is crucial for the quality of the analysis. The more precise and detailed data collected, the better quality of the analysis will be.

Task 10.5 Calculate profitability sheets

Calculate a value of a value object by substituting parameters of a correspondent valuation function. Fill in the result into cells corresponding to this value object in the profitability sheets.

Task 10.6 Calculate final profitability numbers for each actor. Calculate for each actor a final profitability number as a sum of the values of the incoming objects and values of the outgoing objects taken with “minus”.


Question 10.1 Do you have at least one profitability sheet for each actor?

Question 10.2 Are all the ingoing and outgoing objects present in profitability sheets?

Question 10.3 Did you create separate profitability sheets of actors for each paths coming out from an OR-fork? Did you include the probability?

Question 10.4 Do all value objects exchanged as a result of an AND fork subpaths are included in profitability sheets?

Question 10.5 Are all the values of value objects are defined according to a common timeframe and measurement unit?

Question 10.6 Are all the valuation functions correct?



Page

151

Question 10.7 Are all the money objects included in the profitability sheets?

Question 10.8 For an end-consumer: is every value object is estimated in monetary units and included in profitability sheets?

Question 10.9 Are the profitability numbers of each actor positive?

Question 10.10 What is the reason of a negative profitability number?


Guideline 10.1 If a profitability number of an actor is negative then check if the valuation functions and values are correct.

Guideline 10.2 If a profitability number of an actor is negative and there are no mistakes in the valuation functions and values then either a model should be changed such that each actor has positive profitability numbers, or, if such change is not possible, the business idea seems not to be feasible.

Guideline 10.3 Use guidelines in Chapter 6 for more details.

4.9.4 Example

4.9.4.1 Create profitability sheets

The model presented in Figure 46 is a final value model. Building upon the scenario paths, actors, value objects and exchanges shown in this model, we create profitability sheets. To create profitability sheets we follow guidelines described in previous sections. The final version of profitability sheets structure is shown in Figure 54.

The model has five actors (Consumer, DSO, Market operator, RES producer and producer) that implies at least five profitability sheets (one for each actor) have to be created. We start at the start stimulus superimposed on the Consumer actor and follow the path. We come across a value interface, which notifies that the Consumer exchanges two value objects: pays a fee and receives electricity; consequently, we annotate this value interface in the profitability sheet of the Consumer by adding an ingoing value object “Electricity” and out going value object “Fee”. The next value interface to be annotated is a peer value interface of the previous one. It is located at the DSO, so to the DSO’s profitability sheet we add an ingoing value object “Fee” and an outgoing value object “Electricity”. Following the path, we encounter an AND-fork, which the path splits into three paths. Following path 2, we add the value object “obligation to transfer taxes” as ingoing object to the DSO’s sheet, and as outgoing object to Market Operator’s sheet; we add the value object “RES tax” as outgoing object to the DSO’s sheet, and as ingoing object to Market Operator’s sheet.

Following path 1, we encounter an OR-fork, which splits on two paths. Further in the document we name the left path “Renewable generation”, since it notifies the exchanges with renewable producers; we name the right path “Conventional generation”, because it includes exchanges with non-renewable producers. To deal with OR construct we follow the guidelines described in Task 10.1.



Page

152

In this specific case it is not needed to estimate the probability of the paths following the OR-fork. In this model, the DSO is obliged to buy all the electricity produced by the renewable producers, which is notified by dotting the “Conventional generation” path. Basically, the “Conventional generation” path will not be executed unless all the electricity from RES producers is exhausted.

The value interfaces listed above are added to the profitability sheets. The “Renewable generation” path results in the following value exchanges:

o Added to the DSO spreadsheet: ingoing value object “Subsidies” and outgoing value object “RES generation” (with MO), ingoing value object “RES Electricity” and outgoing value object “Fee” (with RES producer), and ingoing value object “RES generation” and outgoing value object “RES subsidy” (with RES producer);

o Added to the RES Producer spreadsheet: ingoing value object “Fee” and outgoing value object “RES Electricity” (with DSO), and ingoing value object “RES subsidy” and outgoing value object “RES generation” (with DSO);

o Added to the Market Operator spreadsheet: ingoing value object “RES generation” and outgoing value object “Subsidies” (with DSO).

The “Conventional generation” path results in the following value exchanges:

o Added to the DSO spreadsheet: ingoing value object “Electricity” and outgoing value object “Fee” (with Producer);

o Added to the Producer spreadsheet: ingoing value object “Fee” and outgoing value object “Electricity” (with DSO).

4.9.4.2 Determine timeframe and common measurement units

As shown in Figure 46, the start stimulus is located at the Consumer actor. Being activated by this start stimulus a consumer buys electricity and pays a fee in return. At this point we have to define (1) what units we use to measure electricity received by consumer, and money paid for the electricity, and (2) how much electricity have consumers receive and (3) during what period. Let us stick to the following assumptions:

Measurement Electricity measured in MWh; fee or money objects measured in Euro

Timeframe 1 year

Amount of electricity consumed

In total consumers receive 3 225 000 MWh/year electricity

To calculate values of electricity and fee exchanged after the start stimulus we have selected (1) measurement units, (2) a timeframe, and (3) a number of start stimuli occurring during this timeframe (or amount of value objects retrieved). During the remainders of the modelling we stick to these assumptions. In other words, we decide that all the electricity objects are measured in MWh, all the fees are measured in Euro, all the calculations are made for 1 year period assuming that final customers in the Bask region consume 3 225 000 MWh/year (see section 4.9.4.4).



Page

153

4.9.4.3 Determine valuation functions

Below we describe how to value each object exchanged. The names and numeration of value exchanges and value objects correspond to those in Figure 46.

We consider valuation of enterprises, which implies that we define valuation functions for money objects only. We do not look at the customer viewpoint in this analysis.

The valuation of each exchanged object is described in the form of a table. The description for each value exchange is represented as a table. The first row of the table indicates a value object exchanged, and the second row gives the function.

Value exchange 1:

Value exchange 1 (see Figure 46) contains a money value object Fee, which is a fee paid by Final customers for electricity. In this model we consider the retail price that customer pays is calculated according to an electricity tariff. The tariff had the following structure. The retail price includes the actual electricity generation price 46%, transmission fee 4.7%, distribution fee 20.1%, commercialising fee 1.9%, the tax to support renewable generation (RES tax) 16.5%, and other taxes and fees16. In sum, the tariff structure is presented in the following table:

Table 15. Tariff structure.

Tariff fee/tax name % Price in 2001(€/MWh)

Electricity 46,00 15,57

Transmission 4,70 1,59

Distribution 20,10 6,80

Commercialising 1,90 0,64

RES tax 16,50 5,58

Other taxes and fees17 10,80 3,65

Retail Price 100,00 33,84

16 Other taxes and fees are not included in further calculations

17 Other taxes and fees include: contract between REE and EdF (1,1%); costs of extra-peninsular systems (1,5%): since there is no location discrimination in electricity price, all the electricity purchases are charged a percentage to pay the over-cost of extra peninsular systems of Spanish islands and enclaves in Morocco (Ceuta and Melilla); costs of the Market Operator (0,1%), costs of the System Operator (0,1%); costs of the National Energy Commission (0,1%); stranded costs (3,6%): paid to non-feasible power plants to keep them in the system in order to guarantee the supply; nuclear moratorium (3,5%): paid to recover the investments of prohibited nuclear plants; nuclear fuel treatment costs (0,8%)



Page

154

The first column of the table shows the name of a certain tariff fee or tax. The second column shows what the part (in percents) of this fee is the total retail price. The third column shows the monetary value of the fee or tax. For example, the RES tax amounts 16.50% of the total retail price, which means that the price for one MWh the customer pays, the amount of € 5,58 is the RES tax. The actual electricity price is 46% or 15,57 €/MWh.

In further research we take no notice of the “Other taxes and fees” part of the price. Therefore, the Retail price is taken as 30.19 €/MWh. We do so because we do not know how exactly these taxes are distributed, so we cannot make any considerations about their influence on the profitability of actors.

The valuation function for the Fee value object look as following:

1 Fee

(Electricityconsumed) X RetailPricetariff

The parameters in the formula are Electricityconsumed (MWh)– The amount of electricity consumed by customers per year, and RetailPricetariff(€/MWh) – a price, that the Final customer pays for 1 MWh of electricity.

Value exchange 2

Value exchange 2 (see Figure 46) contains a money value object Fee, which is a fee paid to the TSO for transporting electricity (Electricitytransported). According to the tariff structure, the transmission fee is charged as a part of the retail fee, namely as 4.7% of the retail price:

2 (Transmission) Fee 0.047 X RetailPricetariff X Electricitytransported =

0.047 X RetailPricetariff X Electricityconsumed

In this formula we make it clear that the electricity transmitted (Electricitytransported) is equal to the electricity consumed (Electricityconsumed). Although in case of distributed generation it is not the fact, because DG does not use transmission services, the mechanism implemented in Spain charges transmission fee not according to how much electricity is transmitted, but according to how much electricity is consumed.

Value exchange 3

Value exchange 3 (see Figure 46) contains a money object RES Tax, which is the total amount of RES Tax paid by Final customers. According to the tariff structure (see Table 15) the RES tax equals 16.5% of the retail price, and the amount of RES Tax paid depends on the amount of electricity consumed (see Electricityconsumed).

3 RES tax 0.165 X RetailPricetariff X Electricityconsumed

Value exchange 4 and 5

Value exchanges 4 and 5 (see Figure 46) actually contain similar objects. The DSO receives the subsidy from the Market Operator and delivers the subsidy to the RES producers. In return in both cases the value object “RES generation” is delivered.

The money value object RES subsidy is a total amount of subsidies delivered to DSO to be paid to RES producers. According to the regulation, the premium varies, depending on the



Page

155

type of the facility. Table 16 is used to determine what subsidy is paid for 1MWh produced by different generation sources.

Table 16. Premiums paid to various generation sources.

Type of generation source Premium (€/MWh)

Hydro 29,464 Wind 29,464 Biomass 33,25 Waste 21,336 PV 360,61 Non-RES 21,276

Consequently, the amount of subsidy paid to one type of subsidized electricity is calculated as a product of premium for this type and the amount of electricity generated. The total amount of subsidies paid in the region is a sum of those products:

4, 5 RES Subsidy Σ (ElectricityRES by type [MWh] X Premium by type [€/MWh] )

In the formula, ElectricityRES by type (MWh) is the amount of RES electricity generated. Since the RES electricity is sponsored according to the type of generation source, the subsidized energy source (see Table 17); Premium by type (€/MWh) is the premium paid for 1MWh of electricity generated by a certain type of energy source (see Table 16).

Value exchange 6

Value exchange 6 (see Figure 46) has a money object Fee, which is an amount of money paid to renewable generators for the electricity generated. This fee is calculated according to the wholesale price, which is a part of the retail price, and according to the electricity tariff (see Table 15) equals 46% of the retail electricity price paid by final customers.

6 (Elecricity) fee 0.46 X RetailPricetariffX ElectricityRES

The Fee value object takes into account only electricity produced by RES producers, and therefore in the formula we have ElectricityRES - the amount of MWh electricity supplied from RES producers.

Value exchange 7

Value exchange 7 (see Figure 46) has a money object Fee, which is an amount of money paid to producers for the electricity generated. This fee is calculated according to the wholesale price, which is a part of the retail price, and according to the electricity tariff (see Table 15) equals 46% of the retail electricity price paid by final customers. In this model this price is the same paid to the RES producers.

7 (Elecricity) Fee 0.46 X RetailPricetariffX Electricitynon-RES

Unlike in value exchange 6, in this value exchange the fee is paid for all electricity produced by conventional generators, and the parameter Electricitynon-RES is the amount electricity supplied from the Producer.



Page

156

4.9.4.4 Collect data

After the valuation functions for all the money objects are determined, the data has to be collected to calculate the functions.

RetailPricetariff is already known (see Table 15). In further research we take no notice of the “Other taxes and fees” part of the price and the retail price is taken as 30.19 €/MWh. We do that because we do not know how exactly “Other taxes and fees” are distributed, so we cannot make any considerations about their influence on the profitability of actors.

Premium by type – a premium paid for each type of the RES producer, is also known (see Table 16).

The remaining data have to be collected:

Electricityconsumed (MWh)– the amount of electricity consumed by customers per year;

ElectricityRES by type (MWh) is the amount of RES electricity generated. Since the RES electricity is sponsored according to the type of generation source, the subsidized energy source;

ElectricityRES - the amount of MWh electricity supplied from RES producers.

Electricitynon-RES is the amount electricity supplied from the Producer.

The table below shows the generation data in the Basque Autonomous Community in 2001. First column list the generation facilities. The second column shows the amount of electricity generated by a facility in 2001.

Table 17. Generation data (Source: Red Eléctrica de España, "El Sistema Eléctrico Español - Informe 2001", available in http://www.ree.es/index_sis.html ).

Electricity plants in the Bask region

ElectricityRES by type (MWh/ year)

Electricitynon-RES 2 259 000 "Special rules"

Hydro 123 000 Wind 86 000 Biomass 36 000 Waste 43 000 PV 0 Non-RES 678 000

ElectricityRES 966 000 Electricityconsumed 3 225 000

The total generation by conventional generation is 2 259 000 MWh (Electricitynon-RES). This number does not include the autoconsumption. We exclude autoconsumption, because producers do not pay taxes for the electricity self-consumed.

The generation data for every type of RES producer is shown in the last column. In total the “Special rules” generators sell (and generate) 966 000 MWh of electricity (ElectricityRES).



Page

157

This generation data consider the electricity acquired by the DSO. The premium is paid both for the electricity delivered to the DSO and for the electricity consumed, but we do not have the data of autoconsumption. We do not show the generation data for PV installation, because we do not have data on them.

We assume that the electricity consumed by customers is the same as electricity generated by producers, so Electricityconsumed equals 3 225 000 MWh/year. This number has already been mentioned in section 4.9.4.2 while determining the number of start stimuli occurring during a year.

4.9.4.5 Calculate profitability sheets

After the valuation functions and values are determined, we fill them into the correspondent cells in the profitability sheets. The result is shown in Figure 54.

The first row of the table lists the headers of the column: Value Object In, Value in, Value Object Out, and Value Out. The second row names the actor, Final Customer, to be analysed. The third row names another actor, DSO, and in- and outgoing objects and their values (according to the headers in the first row) that this actor exchanges with the Final Customer. The remaining of the table is structured in the same way, and list all the actors presented in the graphical model. Every value object appearing in the profitability sheets also has a correspondent value object from the graphical value model.

In this calculations we assume that the Bask Region consumes in total 3 225 000 MW/h electricity per year (see Value In Electricity object for Final Customer). The electricity produced by renewable generators is 966 000 MW/h (see Value Out RES Electricity object of RES producer) and the electricity produced by regular generators is 2 259 000 MW/h (see Value Out Electricity object of Producer). According to the electricity tariff the electricity price, paid to the generator, is only 46% of the total electricity price paid by customer; the rest is RES tax (16.50%), transmission fee (4.7%), distribution fee (20.1%), commercialising fee (1.9%), and other taxes and fees (10.8%). The price of electricity taken is 30.19 €/MWh (we did not include “Other taxes and fees” in the calculations).

Value Object In Value In Value Object Out Value Out

Final Customers

Exchanges with DSO

(Electricity) (3 225 000) Fee -97 370 041,30

TSO

Exchanges with DSO

Fee 5 130 484,24 (Transmission services)

Fixed operational expenses

(Maintenance) Maintenance fee - 5 130 484,24

DSO



Page

158

Exchanges with Final Customer

Fee 97 370 041,30 (Electricity) (3 225 000)

Exchanges with MO

(Obligation) RES Taxes -18 011 274,46

Exchanges with TSO

(Transmission services) Fee -5 130 484,24

Fixed operational expenses

(Maintenance) Maintenance fee - 24 015 032,61

Renewable generation path

Exchanges with MO

Subsidies 22 697 552,00 (RES Generation) (966 000)

Exchanges with RES Producer

(RES Generation) Subsidies -22 697 552,00

(Electricity) (966 000) Fee -15 040 620,00

Conventional generation path

Exchanges with Producer

(Electricity) (2 259 000) Fee -35 172 630,00

RES Producers


Exchanges with DSO

Fee 15 040 620,00 (Electricity) (966 000)

RES Subsidy 22 697 552,00 (RES Generation)

MO

Exchanges with DSO

RES Tax 18 011 274,46 (Obligation) (3 225 000)


Exchanges with DSO

RES generation Subsidy -22 697 552,00

Producer

Conventional generation path

Exchanges with DSO

Fee 35 172 630,00 (Electricity) (2 259 000)



Page

159

Figure 54 Profitability sheets for model in Figure 46.

In Figure 54 there is a profitability sheet for each actor present in Figure 46. A profitability sheet of an actor contains all the incoming and outgoing objects of this actor. To calculate an actor’s profitability we sum up the values of the incoming objects with values of the outcoming objects (note, that values of the outcoming objects is taken with “minus”). The result of profitability numbers for each actor is shown in Figure 55.

Final Customers DSO MO RES Producer Producer TSO

-97 370 041,30 0 -4 686 277,54 37 738 172,00 35 172 630,00 0

Figure 55 Profitability for each actor

DSO. The DSO has zero profitability. This means, that, basically, the sponsoring of renewables has no influence on the profitability of DSO. And if we take a close look at the value exchanges, the DSO only provides a transporting mechanism for subsidies: it receives subsidies from the MO and delivers them to RES producers. (Note, that in these calculations the Fixed maintenance expenses of DSO are hypothetical).

MO. The incoming value objects for the market operator are RES taxes, and outgoing objects are subsidies. The total profitability of the MO is negative, which means that there is more money paid for subsidies than received form RES taxes. The total amount of RES tax paid in both renewable and conventional generation paths is about 80% of the total subsidies paid for RES producers in the region, which means that the RES tax paid in the region is not enough to cover all the subsidies of RES producers.

The negative profitability of the renewable generation path means that the renewable generators do not pay enough taxes to provide premiums for themselves. And, indeed, if we take a closer look, the RES tax paid in the renewable generation path is only about 23% of the total subsidies paid for RES producers.

We should recall, however, that in the calculations not all the sources of income of the MO were taken into account. Namely, the “Other taxes and fees” part of the retail price was ignored. If we take it into account, the profitability of the market operator will be positive. The negative profitability of the market operator obtained in this analysis reflects that the RES taxes do not cover all the premiums paid in the region.

Producer and RES producer. An interesting fact comes out of the profitability numbers of Producer and RES producer. As you one can see, the RES producers receive almost the same amount of money for electricity generated, as the Producers, while the latter supplies 2.3 times more electricity. Of course, this is caused by subsidies paid to RES producers.

The profitability numbers of these actors are positive, which is not surprising, because in their cases we did not model operational expenses explicitly. We did not do that because, first of all, in this analysis we focus on the subsidizing scheme, rather then on profitability of these actors, and, secondly, it is more appropriate to investigate the profitability of a RES generator in investment analysis, which is done below in section 4.11 .



Page

160

4.10 Step 11: Sensitivity analysis

During the execution of a business scenario the profitability of each actor estimated by using profitability sheets, valuation functions, and scenario occurrences and path probabilities, may change substantially. To estimate the feasibility of a business idea in future we use evolutionary scenarios – scenarios that describe events that can possibly take place in future. Analysis of evolutionary scenarios effects on profitability may lead to changed value models, and/or increased confidence in, and better understanding of the business idea by stakeholders.

4.10.1 Tasks to do

Task 11.1 Calculate profitability sheets for Null period. The null scenario refers to a situation described in Step 10: Base-line profitability sheets calculation.

Task 11.2 Elicit evolutionary scenarios for multiple periods. The null-based scenario is a starting point for further analysis. An evolutionary scenario is a scenario that can occur in future time periods, and it can differ from the null-based scenario in terms of value model structure, valuation functions, values, probabilities and number of start stimuli occurrences. Discover different types of evolutionary scenarios:

a. Scenarios which result in changed valuation functions;

b. Scenarios that result in changed numbers of scenario paths occurrences and probabilities;

c. Scenarios that result in changed value model structure.

Task 11.3 Calculate profitability sheets for other multiple periods. After evolutionary scenarios are identified, calculate profitability sheets for these scenarios. The process of calculating profitability numbers, described in section 4.8 , is also applicable for evolutionary scenarios.


Question 11.1 What are possible evolutionary scenarios for a business idea: scenarios which result in changed valuation functions, scenarios that result in changed numbers of scenario paths occurrences and probabilities, or scenarios that result in a changed value model structure:

Question 11.2 What changes in the regulation are possible and can have effect on a business idea?

Question 11.3 What changes in fees and tariff structures are possible?

Question 11.4 Use questions in section 4.9.2



Page

161

Question 11.5 Does a business idea contribute to the profit of participating actors?


Guideline 11.1 Elicit scenarios by interviewing stakeholders and/or doing workshops. While doing these interviews and workshops keep in mind possible variations of scenarios in terms of valuation functions, numbers of scenario paths occurrences and probabilities, and value model structure

Guideline 11.2 Focus on the outcome of analysis of evolutionary scenarios effects on profitability and the possible changes of value models. Discover different scenarios that will increase the feasibility of your business idea.

Guideline 11.3 Use guidelines in section 4.9.3 for more details

4.10.4 Example

In the previous section the profitability numbers for the null scenario were calculated. In this section we will demonstrate an evolutionary scenario “Varying RES tax”.

The null scenario is based on the generation and consumption data of 2001, which are explicitly shown in Table 17. In the null scenario the profitability number of the market operator was negative. In this evolutionary scenario we investigate how to make the MO profitable.

A way to increase the profitability of the MO is to increase RES tax. Several profitability sheets similar to those shown in the previous section were calculated for different amounts of RES tax. As a result, the dependency of profitability of the Market operator on the RES tax is shown in the diagram below. According to the diagram, the profitability of the market operator is directly proportional to the amount of RES tax paid for MWh. The profitability of the Market Operator becomes equal zero when the RES tax is about 7 Euro/MWh. In this case the subsidizing of renewable producers in the Bask region can be covered by RES tax collected in that region.



Page

162

-10 000 000,00

-9 000 000,00

-8 000 000,00

-7 000 000,00

-6 000 000,00

-5 000 000,00

-4 000 000,00

-3 000 000,00

-2 000 000,00

-1 000 000,00

0,00

4,37 4,98 5,58 6,19 7,04

REX tax, Euro/MWh

MO

pro

fita

bil

ity

Consequently, we build the profitability sheets and calculate profitability numbers of actors for the situation when the RES tax increases till 7.04 Euro/MWh. With the condition that all the other parameters remain the same (also electricity price and other taxes), the profitability of the actors become as shown in the table below:

DSO MO RES Producer Producer Final Customers

24 015 032,61 6 448,00 37 738 172,00 35 172 630,00 -102 062 766,85

The profitability of the market operator becomes positive meaning that subsidies in the Bask region are covered by RES tax collected in that region. The profitability of DSO and producers do not change. And the final customers have to pay a higher price for the electricity; namely, the retail price changes from 30,19 Euro/MWh till 31.65 Euro/MWh.

4.11 Investments analysis

After a scenario is chosen, a detailed analysis of financial aspects should be made. In previous sections, we were focused on the overall picture of the business scenario and evaluated the profitability of all the actors. In this section we focus on investment-decision aspects. From the financial analysts we obtain several standard criteria for investment analysis. Some of them, namely net present value (NPV) and internal rate of return (IRR), are discussed in this section.

4.11.1 Net present value calculation

Net Present Value criterion is an important assessment, which calculates the expected net monetary gain or loss from a project by discounting all expected future cash flows and inflows to the present, using some predetermined minimum desired rate of return. NPV is a very useful tool because it allows for a comparison of current expenses to undertake a project versus the potentials benefits, in this case revenues, which the project will yield sometime in the future. The formula for calculating NPV is:



Page

163

NPV=-I+ n CFi/(1+r)i

where: I= initial investment, CFi=cashflow in year i, r=discount rate, n=time horizon of the project. If the NPV is greater than 0, then the current value of the cash flow that will be generated by the project or business is positive. A simple example follows: A simple example follows: Suppose the cost of project XYZ is €200,000 which is expected to lose money for the first 2 years before implies as €75,000 in year 1 and €10,000 in year 2 before a profit of €60,000 in year 3, and €200,000 in year 4. The discount rate is the rate of return, which you may have had on the €200,000 if it is not invested in project XYZ, let us suppose this is 5%. Then:

NPV=-200000 + (-75000/(1+0.05)1) + (-10000/(1+0.05)2) + (60000/(1+0.05)3) + (200000/1+0.05)4) = -64128.20

Therefore the NPV of project XYZ is currently -64,128.20 or to state it another way, the current value of the cash flows generated by this project in the future is -€64,128.20 compared with investing the money with an interest rate of 5%. Therefore on a cost/value basis it should not be initiated, as the negative Internal rate of return during the period for which the project is losing money is greater, cumulatively, than the corresponding positive IRR for which the project begins to generate positive cash flow.

4.11.2 Internal rate of return

The internal rate of return is the rate of interest at which the present value of expected cash inflows from a project equals the present value of expected cash outflows of the project.

IRR, on the other hand, computes a break-even rate of return. It shows the discount rate below which an investment results in a positive NPV (and should be made) and above which an investment results in a negative NPV (and should be avoided). It is the break-even discount rate, the rate at which the value of cash outflows equals the value of cash inflows.

4.11.3 Value modelling and investment analysis

The net present value and internal rate of return offer measures to make investment decisions. The value model delivers information about cash flows to calculate NPV and IRR. In practice, the company deals with more than one value model at the same time. For example, the windmill park can generate revenues by generating electricity and selling it at the energy pool (the first value model), by receiving subsidy from the government (the second value model), by making a bilateral agreement with some party to deliver electricity (the third value model), etc. In such a case the correct investment decision can only be made if the revenue flows of all these value models are taken into account (see Figure 56).



Page

164

Figure 56. Use more than one value model to make investment decision.

4.11.4 Tasks to do

Task 12.1 Identify initial investments. Identify what sum is to be invested, select a minimum desired rate, and a desired period for return.

Task 12.2 Draw a sketch of relevant cash inflows and outflows. Use the value model and profitability sheets for that. Include operational costs in your calculations, if not included before. Identify what value objects flowing in and out the actor, receiving investment. Identify valuation functions for these value objects.

Task 12.3 Calculate the net present value (see section 4.11.1). The positive net present value indicates that the rate of return exceeds the desired minimum. The net present value equal zero indicates that the rate of return equals the desired minimum. The negative net present value indicates that the rate of return is below desired minimum.

Task 12.4 Calculate IRR. If the minimum desired rate is less than IRR then the project will be profitable. If the minimum desired rate exceeds IRR, then the cash inflow will be insufficient to pay interest and repay the principal of the hypothetical loan.

4.11.5 Example

Identify initial investments. Suppose the renewable producer in the value model shown in Figure 46 wants to invest into a wind turbine with capacity 900 kW, which generates 2 250 MWh electricity a year. The capital costs of such a wind turbine are € 1 260 000, however, taking into account that the government offers 16% of the Added Value Tax discount, the initial investments are taken as €1 058 400.

Value model 1

Value model 2

Value model 3

NPV

Cash

Flows INVESTMENT DECISISION



Page

165

Draw a sketch of relevant cash inflows and outflows. According to the profitability sheet, the Renewable producer exchanges value objects as shown in the following table. Additionally, we included fixed operational expenses undertaken by the RES producer to generate electricity.

As one can see, the RES producer receives a fee and subsidy for electricity generated. Accordingly the following valuation functions are assigned:

Fee = Electricity (MWh/year) X Electricity price (€/MWh)

RES Subsidy = Electricity (MWh/year) X Premium (€/MWh)

Maintenance fee (for 900 kW wind turbine)= 25 200 (€/year)

Taking that in 2001 the electricity price was 33.84 €/MWh, the premium paid for electricity generated with to this type of wind turbines is 28.97 €/MWh, the inflow will be 141 315,75 per €/year. The outflow is the maintenance expenses, and equals 25 200 (€/year). Assuming that the useful lifetime of the wind turbine is 20 years and there is no change in prices and valuation functions, the following in- and out-flows are sketched in Table 18.

Table 18. Sketches of cash flows.

Year 0 Year 1 Year 2 … Year 20

Inflow (€/year) 141 315,75 141 315,75 141 315,75 … 141 315,75

Outflow (€/year) -25 200,00 -25 200,00 -25 200,00 … -25 200,00

Cash flows 116 115,75 116 115,75 116 115,75 … 116 115,75

NPV and IRR calculation and analysis. Table 19 considers three scenarios for minimum desired rates 7%, 9% and 10%, each involving an initial investment of €1 058 400. The investment returns €116 117,75 (undiscounted) per year in each of the twenty years after the initial investment (see Table 18).

The present value of flows for, for example 7% discount rate, is calculated as follows:

Present value of flows = (116117,75/(1+0.07)1) + (116117,75/(1+0.07)2) + (116117,75/(1+0.07)20) = 1 230 153

The net present value then is the difference between present value of flows and initial investment. For example, for 7% rate: NPV = 1 230 153 - 1 058 400 = 171 753.

Value object In Value Object Out

RES Producer

Exchanges with DSO Fee (Electricity) RES Subsidy (RES Generation) Fixed operational expenses

(Maintenance) Maintenance fee



Page

166

Table 19. NPV and IRR calculation.

Discount rate

7% 9% 10%

Present value of flows

1 230 153 1 059 977 988 576

Initial investment

1 058 400 1 058 400 1 058 400

NPV 171 753 € 1 577 -€ 69 824

IRR slightly more than 9%

A company evaluating this investment using cash flow discounted at 7% would compute an NPV of € 171 753, a decent but not spectacular result. But if the company evaluates the same investment at 9%, the project has a present value of only € 1 577, essentially just breaking even, and at 10% the project's present value is negative. The IRR is a fraction of a percentage point above 9%; at that discount percentage, the investment's NPV is zero.



Page

167

Chapter 5 Guidelines for the e3-value methodology

In chapter 2 we introduced the e3-value methodology with a case, in chapter 3 we provided an overview of this methodology, in chapter 4 and 5 we defined a process to construct DG specific value models and in this chapter we will discuss the details of the e3-value methodology. This chapter can be used as a reference while constructing value models for DG specific cases, to guarantee correct value models.

This chapter is constructed from parts of the PhD thesis “Value-based Requirement Engineering” from Jaap Gordijn, edited and supplied with additional texts to fit in the context of this document.

5.1 Business models – Economic Value perspective

5.1.1 Representing Value Models

In this section, we present the e3-value methodology in more detail. We illustrate the methodology with an example project, a project carried out in the free Internet service provisioning arena. The e-commerce idea underpinning this project is that users, in order to access the Internet, only have to pay a fee for a telephone connection, what they are used to do for other, paid, Internet access services also. In short, these telephone connection revenues are used to finance the entire operation. This e-commerce value model is shown in Figure 57 (global actor viewpoint), Figure 61 (detailed actor viewpoint), and Figure 62 (value activity viewpoint). These three sub-viewpoints will be discussed in the next chapter.

5.1.2 Three sub-viewpoints

The e3-value methodology is organized in three sub viewpoints, each discussing related requirement expressions we often encounter in e-commerce projects

• The global actor viewpoint shows:

1. the actors involved in an e-commerce idea;

2. the objects of economic value created, exchanged, and consumed by these actors;

3. objects of value, which actors expect in return for an object of value delivered, or the mechanism of economic reciprocity;

4. objects which are offered or requested in combination;

5. phenomena that cause exchanges of objects between actors.



Page

168

• The detailed actor viewpoint(s) shows:

1. partnerships between actors, which show that actors request or offer objects of value jointly;

2. constellations of actors, which need not to be seen on the global actor viewpoint, e.g. to avoid unnecessary complexity;

3. plus: requirement expressions as on the global actor viewpoint, but then only for actors expressed on the detailed viewpoint.

• The value activity viewpoint(s) shows:

1. the value-creating or adding activities and their assignment to actors.

The main purpose of the global actor viewpoint is to explain the overall value model to all stakeholders, including CxO type of stakeholders, involved. It hides complexity, which can be shown on detailed actor viewpoints. The reason to introduce a detailed actor viewpoint can be twofold: (1) representation of constellations: a decomposition of a part of the global actor viewpoint to reduce complexity, and, (2) representation of partnerships: actors who decide to offer and/or request products or services as one virtual actor to/from other actors. The value activity viewpoint(s) shows what actors do to create profit or to increase value for themselves. Its main motivation is to separate discussions of who is participating in the e-commerce idea from who is doing what.

5.1.2.1 The global actor viewpoint

The explanation of our methodology is structured by presenting an example for each concept, based on the project carried out in the free Internet service provisioning arena. The global actor viewpoint of this project is depicted in Figure 57.



Page

169

Figure 57. Value model for a free Internet access service: the global actor viewpoint.

Actor. An actor is perceived by his/her environment as an economically independent (and often also legal) entity. Enterprises and end-consumers are examples of actors. A profit and loss responsible business unit, which can be seen as economically independent is an actor, although such a unit needs not to be a legal entity.

Economically independent refers to the ability of an actor to be profitable after a reasonable period of time (in case of an enterprise), or to increase value for him/herself (in case of an end-consumer). For a sound and viable e-commerce idea, we require that each actor can be profitable or can increase his/her value. Nevertheless, we acknowledge that in the recent past, many e-commerce ideas were put in operation were this was not case. Such ideas are not sustainable and are consequently not in the scope of our research.

Properties. An actor has a name, e.g. a company name, or a name that represents the role such an actor plays.).

Visualization. An actor is depicted by a rectangle, with his/her enterprise or role name.

Example. The global actor viewpoint (see Figure 57) shows a free Internet service provider and a local operator. Also, surfers are presented as a market segment (to be discussed), which essentially is a set of actors valuing objects equally. The free Internet service provider is an actor who offers a service the surfer is interested in: Internet access for free. The local operator exploits the local loop: the last mile of copper wire between a telephone switch and the home of a surfer. This loop is needed to set up a telephone connection between a surfer and the free Internet service provider. This telephone connection is used by the surfer’s and provider’s telecommunication equipment to access the Internet.

Value Object. Actors exchange value objects. A value object is a service, a product, or even an experience, which is of economic value for at least one of the actors involved in a value model. Actors may value an object differently and subjectively, according to their own valuation preferences [Holbrook 1999].



Page

170

From a modelling point of view, we are interested in the kind of value objects which actors exchange, and not so much in the actual instances themselves. Therefore, when we speak about value object, we mean the kind of value object, or the prototype for all instances of a particular value object. In some cases, it is necessary to refer to the actual instances of objects of value exchanged by actors. We then call these objects value object instances.

Properties. A value object has a name. While choosing a name, one should keep in mind that it expresses the object from an economic value point of view.

Visualization. A value object is presented by showing the name of the object nearby a value exchange (to be discussed below), representing a potential trade of such an object, or by showing the name nearby value ports offering or requesting objects (see below).

Example. Many value objects in Figure 57 speak for themselves. The value object termination possibility is however non-trivial. Termination in the world of telecommunication operators means that if someone tries to set up a telephone connection by dialling a telephone number, someone else must pick up the phone, that is, terminate the connection. If someone is willing to cause termination of a large quantity of telephone calls, most telecommunication operators are willing to pay such an actor for that. This is exactly what the free Internet service provider does: s/he aggregates a large number of termination possibilities from surfers and gets paid for that.

Also, the value object interconnection needs explanation. At the time the project was carried out there was in The Netherlands only one actor who operated the local loop, the last mile of copper wire between a telephone switch and the home of a surfer. From a surfer point of view, this local operator delivers an end-to-end telephone connection, in this case between the surfer and the free Internet service provider. However, the local operator does not operate a network that connects the surfer with the free Internet service provider directly. S/he only owns a part of that network. In such a case, the local operator must use an additional network, connected to the free Internet provider, which is owned by another operator to provide the surfer an end-to-end connection. In other words: the local operator must obtain interconnection from another Telco. In return for this, the local operator pays an interconnection fee.

Value Port. An actor uses a value port to provide or request value objects to or from his/her environment, consisting of other actors. Thus, a value port is used to interconnect actors so that they are able to exchange value objects. Such a value object flowing into or out an actor denotes a change of ownership, or a change in rights.

The concept of port is important, because it enables to abstract away from the internal business processes, and to focus only on how external actors and other components of the e-commerce value model can be ‘plugged in’. This is the value analogue of the separate external interfaces familiar from technical systems theory [Borst 1997]. Take, for example, a bipolar in+out value multi-port, which is a characteristic combination occurring in e-commerce value models: an e-service port out and a money port in, or the other way around. Such a bipolar value port combination can be very well compared to an electrical wall outlet. As an external user, you don’t want to be involved in what happens behind the wall outlet as long as it gives the right quality of service. The same approach holds for how external parties in an e-commerce value model view the value ports of a service-offering actor: the ports only define how the external connections to other actors should be made.

Properties. A value port has a direction, which can have the values in (shortly called an in-



Page

171

port) or out (called an out-port) indicating whether a value object flows into or out an actor (seen from that actor).

Relations. A value port offers or requests one value object. This cardinality constraint again emphasizes that we are not so much interested in value object instances, but rather in the prototype for such instances. A value object can be requested by or offered by zero or more value ports.

Visualization. The value port is depicted by a small black filled circle (see Figure 57). Value in-ports have an incoming arrow. The name of the value object offered/requested by the port can be depicted.

Value Offering. A value offering models what an actor offers to (an out-going offering) or requests from (an in-going offering) his/her environment, and closely relates to the value interface concept (see below). A value interface models an offering of an actor to his/her environment, and the offering such an actor requests in return from his/her environment. An offering is a set of equally directed value ports exchanging value objects, and implies that all ports in that offering should exchange value objects, or none at all.

A value offering is of use for representing a number of situations. First, some objects may only be of value for an actor if they are obtained in combination. In-ports exchanging such objects then form an in-going offering. Second, actors may decide to offer objects only in combination to their environment. Ports offering such objects then form an out-going offering. An example of an out-going offering is the case of mixed bundling. Mixed bundling refers to the mechanism that an actor wants to offer value objects in combination rather than separately, because that actor supposes that different products sold in combination yield more profit than that if they were sold separately [Choi 1997].

Relation. A value offering consists of one or more equally directed value ports. A value port is in exactly one offering.

Value Interface. Actors have one or more value interfaces. In its simplest form, a value interface consists of one offering, but in many cases, a value interface groups one in-going and one out-going value offering. It shows then the mechanism of economic reciprocity. Economic reciprocity refers to rational acting actors. We suppose that actors are only willing to offer objects to someone else, if they receive adequate compensation (i.e. other value object(s) in an in-going offering) in return. So, with the value interface, we can model that an actor is willing to offer something of value to his/her environment but requests something in return, whereas a value offering models that objects can only requested or delivered in combination.

The exchange of value object instances is atomic at the level of the value interface. Either all ports in a value interface (via value offerings) each precisely exchange one value object instance, or none at all. This ensures that if an actor offers something of value to someone else, s/he always gets in return what s/he wants. How this is ensured is a matter of a robust business process design, trust and associated control mechanisms (see e.g. [Tan 2002]), legal agreements, or sometimes use of technology, but this is not expressed by the value model.

Relations. A value interface is assigned to zero or one actor and consists of one or two value offerings, in the latter case being an out-going offering and an in-going offering. Each actor has its own value interface. Multiple value interfaces can be assigned to an actor and a



Page

172

value offering belongs to exactly one value interface.

Visualization. The value interface is visualized by a rounded box at the edge of an actor. Value ports are drawn in the interior of the rounded box. Note that a value offering is not visualized explicitly. However, value offerings can be easily seen by grouping all out-going value ports in a value interface (the out-going offering), or by grouping all in-going value ports in a value interfaces (the in-going offering).

Example. Consider in Figure 57 the surfer. The in-going offering consists of telephone connection and Internet access. These objects are seen as one offering because they are only of value in combination for the surfer. An Internet connection is worthless without the telephone connection that is used for data transport. Also, for a surfer, the telephone connection is not of value without Internet access. The out-going offering contains the compensations for the obtained telephone connection and Internet access. These two offerings are grouped into a value interface to show that a surfer compensates its environment for obtaining a telephone connection and Internet access, with a fee and a termination possibility.

Value Exchange. A value exchange is used to connect two value ports with each other. It represents one or more potential trades of value object instances between value ports. As such, it is a prototype for actual trades between actors. It shows which actors are willing to exchange value object instances with each other. So, it does not model actual exchanges of value object instances, which we call value exchange instances.

Relations. The value ports involved in a value exchange are represented by the has in and has out relations, which relate to exactly one in-port and exactly one out-port. A value port may connect to zero or more value exchanges.

Figure 58 exemplifies a situation with a port connected to more than one value exchange. Value ports of actor a, offering/requesting value objects y and z, connect via value exchanges to ports of actor b, but also connect to ports of actor c. This situation models that actor a and actor b are willing to exchange objects of value, and so do actor a and actor c. Note that the model does not represent the number of value exchange instances over time, nor their ordering in time.

a

b c

y z

Figure 58. Actor a can decide to exchange value objects with actor b, or actor c.

Visualization. A value exchange is shown as line between value ports. The name of the value object which is exchanged, is presented nearby the value exchange.



Page

173

Value transaction. A value interface prescribes the value exchanges that should occur, seen from the perspective of an actor the value interface is connected to, because all ports in a value interface should exchange objects, or none at all. Sometimes, it is convenient to have a concept that aggregates all value exchanges, which define the value exchange instances that must occur as consequence of how value exchanges are connected, via value interfaces to actors. We call this concept a value transaction. In its simplest form, a transaction is between two actors. However, a transaction can also be between more than two actors. We call such a transaction a multi-party transaction. Figure 57 shows a multi-party transaction between a surfer, a local operator, and a free Internet service provider.

Relation. A value transaction consists of one or more value exchanges. Note that the exchanges in a transaction should be consistent with the way these exchanges are connected to value interfaces. A value interface requires that if a value object is exchanged via a port, also exchanges must occur via all its other ports. These exchanges must be also part of the transaction.

Figure 59 exemplifies why a value exchange can be in multiple transactions. In this example, actor a offers two value objects, and wants to have two value objects in return. There are two sets of actors who are a capable of participating in the exchange of values with actor a: actors {b1,c}, and actors {b2, c}. Clearly, actor a must exchange values with actor c (there is no alternative), but there is a choice between actor b1 and actor b2 for the other exchanges. Consequently, we can distinguish two transactions with overlapping value exchanges. Transaction 1 consists of the value exchanges e1, e2, e3, and e4 and transaction 2 consist of the value exchanges e1, e2, e5, and e6. Value exchanges, which are in more than one transaction, occur in multi-party transactions, of which Figure 59 is an example.

a

cb1 b2

t1

t2

e1 e3e2 e4 e5 e6

Figure 59. A value exchange can be in multiple transactions.

Visualization. A value offering is shown by a line intersecting the value exchanges it contains. The intersection points are shown by small filled circles.

Example. Figure 57 shows a three-party offering between the free Internet service provider, a surfer, and a local operator. A surfer needs both to obtain Internet access, and to obtain a telephone connection, to be able to browse the Internet. From the surfer’s value interface can be concluded that all four value exchanges connected to it are part of one transaction: either all ports of surfer’s interface each exchange a value object or none at all.



Page

174

Market segment. In marketing literature [Kotler 1988], a market segment is defined as a concept that breaks a market (consisting of actors) into segments that share common properties. We employ the notion of market segment to show that a number of actors assign economic value to objects equally. This construct is often used to model that there is a large group of end-consumers who value objects equally. We realize that in practice no actor will value objects exactly the same, but supposing an equal valuation for some actor groups is a simplification needed to arrive at comprehensible value models.

In most cases, the individual actors of a market segment are left implicit. With implicit we mean that we do not model these actors individually. This is also the modelling purpose of the market segment construct: to have a shorthand for a large number of actors. However, actors are independent companies or individuals. As such, a specific actor, being part of a market segment, may exchange also other value objects than those mentioned in that market segment. Consequently, a market segment groups value interfaces of actors, exchanging objects that are valued equally, rather than that it groups actors themselves. If an actor, who is part of a market segment, has additional value interfaces, which other actors in that segment do not have, we model such an actor also explicitly.

Finally, value exchanges drawn to a segment can be seen as a shorthand notation for value exchanges to all actors in that segment. If we assume that market segment b (implicitly) consists of actors b1, b2, and b3, and these actors value objects the same way, Figure 60 (b) is a shorthand notation for Figure 60 (a).



Page

175

Figure 60. A value model without and with market segment.

Properties. A market segment is given a name, in must cases in plural form, such as customers, surfers, or alike. A market segment has a count, which indicates the number of actors in the segment. The count can be a number, unbound, or unknown.

Relations. Because a market segment is a set of actors, a value interface can be assigned to zero or one market segment, just as an interface can be assigned to an actor. Objects exchanged via this value interface are valued equally by actors in the segment.

An actor can be in a market segment. This relationship is needed to represent actors who have, besides value interfaces of a market segment, additional value interfaces of themselves. The additional interfaces are then related to the actor him/herself, while the relationship between actor and market segment is used to represent an actor’s interfaces s/he has as a result of his/her membership in a market segment.

Visualization. A market segment is shown as three stacked actors. A value interface of a market segment is presented on one of the edges of the topmost actor. An explicitly modelled actor who is also part of a market segment is mentioned in the name of the market segment.

Example. The surfers segment (Figure 57) consists of implicit actors who want to access the Internet.

Summary. In conclusion, the global actor viewpoint shows the top-level actors in a value model, without discussing constellations and partnerships yet. Also, the assignment of value



Page

176

activities to actors is not shown by this viewpoint. The global actor viewpoint shows the objects of value exchanged between actors. The market segment notion is useful if a large number of actors exists, who are supposed to assign economic value to value objects the same way.

The global actor viewpoint can be constructed in brainstorm sessions and workshops with all key actors. Also, this viewpoint can be used to present and explain the overall value model to stakeholders.

For the free Internet access service, the global actor viewpoint illustrates that the so-called free service is offered to surfers, but is not for free at all, since the surfer has to pay for a telephone connection. Also, this viewpoint shows that a local operator is needed to offer an Internet access service to surfers.

5.1.2.2 The detailed actor viewpoint

Internet serviceprovider Telco

terminationfee

termination

free Internet service provider

Legend

Compositeactor

Internetaccess

terminationpossibility

interconnection

interconnection

fee

Figure 61. Value model for the free Internet case: the detailed free Internet service provider actor view.

The purpose of a detailed actor viewpoint (see Figure 61) is twofold. First, a detailed actor viewpoint can be used to detail an actor identified on the global actor viewpoint into more actors. We call such an actor a value constellation. A value constellation can be used to isolate parts of the value model to a limited number of actors, who can decide on that specific part without consulting other actors participating in the e-commerce idea too much. A value constellation is also a way to reduce complexity on the global actor viewpoint, such that all actors can understand this viewpoint. A second reason to introduce a detailed viewpoint is the representation of partnerships between actors. As such, a number of actors may decide to present themselves, as a virtual enterprise actor, to their environment (see e.g. [Davidow 1992]). These actors then decide on one common value interface to their environment.

Composite actor and elementary actor. For both aforementioned modelling purposes, we specialize the actor concept into a composite actor, and an elementary actor.

A composite actor groups value interfaces of other actors. Also, a composite actor has its own value interfaces to its environment. These composite actor’s value interfaces allow us to (1) abstract away from the composite’s internals, or (2) to show a common value interface



Page

177

from actors who decide to present themselves as a virtual enterprise.

An elementary actor does not contain value interfaces of other actors. Such an actor is the lowest decomposition level that can be reached from an actor perspective.

Note we group value interfaces and not actors into a composite actor. The reason for this is that in case of partnerships, an actor may decide to offer objects jointly with objects of other actors, but also may decide to offer other objects on its own. Consequently, it is not the actor that is grouped, but what s/he is offering for a specific case. The same holds for introducing a composite actor in case of value constellations. Such an actor can group a number of value interfaces of the actors it contains, while interfaces of these actors may also appear somewhere else in the value model.

Relations. A composite actor is an actor. An elementary actor is also an actor. This means that all properties and relations identified for actors will also hold for composite and elementary actors. A composite actor consists of minimal two value interfaces of other actors. We need at least two interfaces to be able to group meaningfully.

Visualization. A composite actor is visualized by drawing a rectangle around the actors whose value interfaces are grouped. Inside this rectangle, the value interfaces of the actors must be shown, which are grouped by the composite actor.

Example. The free Internet service provider appears to be a value constellation, which consists of two other actors: (1) an Internet service provider offering Internet access (e.g. by exploiting access servers), and (2) a specific Telco handling interconnection of telephone calls between the Internet service provider and the local operator.

The detailed actor viewpoint shows also exchanges of value objects between the Internet service provider and Telco. The provider terminates connections by exploiting an Internet access server (effectively a large modem-bank), which answers telephone calls made by the modems of surfers. Termination of large quantities of telephone calls is of value for Telco. Consequently, Telco pays the Internet service provider a termination fee.

Value exchange revisited. We have introduced the value exchange concept earlier to relate ports of actors exchanging objects. These connected ports have opposite directions. The value exchange construct is also used to relate value ports of a composite actor to value ports of actors being part of the composite. In this case, connected ports have equal directions. An object offered via an out-port of a composite actor still has to be offered via an out-port of one of the actors in the composite. Also an object requested via a composite actor’s in-port must be requested by an in-port of one of the actors it contains.

Properties. To represent the various applications of value exchanges, we distinguish four types (see Table 20). A type 1 exchange relates ports of actors trading objects, while a type 2exchange relates ports of a composite actor with ports of the actors it contains. Other types are discussed in the remainder of this chapter.

Table 20. Various value exchange types.

Value exchange Relates port 1 of With port 2 of an Ports have



Page

178

type an …direction

1 Actor Actor Opposite

2 Composite actor Actor Equal

3 Elementary actor Value Activity Equal

4 Value Activity Value Activity Opposite

Relations. To stress that a type 2 value exchange, which connects ports with equal directions is different from a type 1 value interface which connects ports with opposite directions, other associations are shown in the ontology. A value exchange has a first value port of the composite actor, and has a second value port of one the actors contained by the composite actor.

Example. Figure 61 exemplifies a type 2 value exchange. The ports of the composite actor free Internet service provider are mapped on ports of value interfaces of the Internet service provider and Telco.

Summary. The detailed actor viewpoint intends to represent actors jointly offering or requesting a product or service to their environment, also called a partnership. Moreover, the viewpoint is used to detail specific parts of an e-commerce value model, which are abstracted away on the global actor viewpoint (the value constellation). Strictly spoken, a composite actor groups value interfaces of other actors, not the actors themselves.

5.1.2.3 The value activity viewpoint

The main purpose of the value activity viewpoint is to illustrate the assignment of value activities to actors. Figure 62 shows this viewpoint for parts of the free Internet service provider. How value activities are assigned to the various possible actors is a free variable that, as a result of the extended enterprise network setting, leads to many design options and choices in e-commerce value models. Hence, this assignment is a key consideration in strategic e-commerce decision-making.



Page

179

Figure 62. Value model for the free Internet case: the value activity view.

Value Activity. An important issue in value model design is the assignment of value activities to actors. Therefore, we are interested in the collection of operational activities, which can be assigned as a whole to actors. Such a collection we call a value activity. Actors perform value activities, and to do so, a value activity must yield profit or should increase economic value for the performing actor. Consequently, we only distinguish value activities if at least one actor, but hopefully more, believes that s/he can execute the activity profitable. Value activities can be decomposed into smaller activities, but the same requirement stays: the activity should yield profit. This also gives a decomposition stop rule.

Relations. A value activity has one or more value interfaces, just like actors and market segments. A value interface belongs to exactly zero or one value activity. A value activity is performed by precisely one elementary actor. Finally, multiple value activities can be performed by an actor.

Visualization. A value activity is graphically presented by a rounded box, which is drawn inside the actor who performs the activity.

To draw readable diagrams, we sometimes omit value interfaces, ports and exchanges. In Figure 62, the Internet service provider shows no value interfaces anymore, while Figure 61 shows for the same actor two value interfaces. If a value interface of an actor has the same structure as a value interface of a value activity s/he performs, we may decide not to present the value interface of the actor. Two value interfaces have the same structure if each port of the first value interface can be matched with precisely one port of the second value interface, and vica versa. Matching of two ports is possible if both ports have the same direction and if they exchange the same value object. However, an omitted value interface conceptually exists, and also value exchanges to connect an actor’s value interface to a value interface of his/her value activity conceptually exist. The same holds for composite actors: we may decide to omit value interfaces of a composite actor if they have the same structure as the value interfaces of actors the composite actor exists of.

Example. The Internet service provider performs an Internet access provisioning activity.



Page

180

This activity comprises investment in and maintenance of Internet access servers. Another activity, which might be thought of is e.g. a web hosting service. Telco executes an activity named call delivering. This activity is the exploitation of a physical network between the local operator and the Internet service provider for data transport. For all these activities, we assume that they are, after some period, profitable for the actors performing these activities.

Value exchange revisited. We also use the value exchange to connect ports of value activities with ports of the actor performing these activities. These are called type 3 value exchanges. Such ports must have the same direction. Also, ports of value activities, which are performed by the same actor can be connected by using type 4 value exchanges. These exchanges represent ‘internal’ trades of an actor. Such exchanges connect ports with an opposite direction.

Summary. The value activity viewpoint represents the assignment of value activities to actors. By assuming that a value activity is commercially interesting to be performed by at least one actor, but preferably more actors, we can shift activities from one actor to another actor, thereby discussing who is doing what. Especially if roles of actors are not clear, which is often the case for innovative e-commerce projects, negotiating the assignment of activities to actors is an important part of the exploration track.

5.1.2.4 Scenarios by Use Case Maps

Operational scenarios are used to capture parts of the e-commerce idea and to contribute to a common understanding between stakeholders. Moreover, we use operational scenarios to evaluate an e-commerce model.

In this section, we focus on a scenario’s role to capture parts of an e-commerce value model, and more specifically we show how scenarios are used to specify by what phenomena exchanges of objects are caused. To represent operational scenarios, we utilize Use Case Maps, a generic lightweight scenario representation mechanism. The following sections discuss UCMs, bind UCMs to our e3-value ontology, and discuss differences between our use of UCMs, and Buhr’s UCMs.

Use Case Maps. A UCM is a visual notation to be used by humans to understand the behaviour of a system at a high level of abstraction [Buhr 1998]. It is a scenario-based approach intended to explicate cause-effect relationships by travelling over paths through a system.



Page

181

Figure 63. UCM constructs.

The basic UCM notation is very simple, and consists of three basic elements: responsibilities, paths and components. The term component should be interpreted in a broad sense: it may be a software component, but it can also represent a human actor or a hardware system. A simple UCM exemplifying the basic elements is shown in Figure 63. A path is executed as a result of the receipt of an external stimulus. Imagine that an execution pointer is now placed on the start position (bullet at the top). Next, the pointer moves along the indicated scenario path, thereby entering and leaving components, and touching responsibility points. A responsibility point represents a place where the state of a system is affected or interrogated. The effect of touching a responsibility point is not defined in the UCM itself since the concept of state is not part of a UCM; typically, this effect is described in natural language. Finally, the end position is reached (stroke perpendicular to the scenario path) and the pointer is removed from the diagram.

In the same Figure 63, two frequently used UCM constructs are shown. The AND construct is used to spawn (AND-fork) and synchronize (AND-join) multiple parallel scenario paths. The OR construct is a means to express that a scenario path continuous in alternative directions.

Binding UCMs to e3value. To be meaningful, the UCM notation must be bound to some other notation, in our case the e3-value ontology. More specifically, we have to articulate the components UCM scenario paths can touch using responsibility points. Therefore, we present UCM’s the same way as we did for our e3-value ontology, and relate scenario paths to e3-value ontology constructs.

Below we discuss the various UCM constructs, and exemplify their use in the free Internet access project. Value viewpoints enriched with Use Case Maps are shown in Figure 64 (the global actor viewpoint), and Figure 65 (a detailed actor viewpoint).



Page

182

Figure 64. Use Case Maps applied to the global actor viewpoint.

Figure 65. Use Case Maps applied to the detailed actor viewpoint.

We utilize a simple form of Buhr’s Use Case Maps. The two constructs used are dependency elements and connection elements. Connection elements interconnect dependency elements like value interfaces, resulting in scenario paths.

Dependency element. A scenario is expressed by dependency elements, interconnected by connection elements (see Figure 65). Essentially, a scenario gives dependencies between value interfaces (a kind of connection element) so that we can reason for an entire value model what happens with other value interfaces if we exchange values via one particular value interface.

Properties. Each dependency element can have a textual label for naming purposes.



Page

183

Relations. A dependency element has one upper connection element and one lower connection element.

Visualization. Dependency elements are drawn using normal lines.

Connection element. A connection element connects various dependency elements. Dependency elements can be start and stop stimuli, AND/OR forks or joins and value interfaces (see Figure 65).

Properties. Each connection element can have a textual label for naming purposes.

Relations. A connection element has zero or more up-dependency elements. The same holds for down-dependency element.

Visualization. Connections elements are visualized, depending on their specific kind (see below).

Stimulus element. Scenarios start with one or more start stimuli. A start stimulus represents an event, possibly caused by an actor. If an actor causes an event, the start stimulus is drawn within the box representing the actor. A scenario also has one or more end stimuli. They have no successors.

Visualization. A start stimulus is visualized by a filled circle; an end-stimulus is presented by a line, placed in an angle of ninety degrees on the line visualizing a dependency element. If an actor causes a stimulus, it is drawn in the interior of such an actor.

Example. The need for an actor to surf on the Internet is an example of a start stimulus. Such a stimulus results in a number of value exchanges between the actors participating in the value model.

AND and OR continuation elements. An AND fork connects a dependency element to one or more dependency elements, while the AND join connects one or more dependency elements to one other dependency element. It splits a scenario into more sub scenarios or merges sub scenarios into one scenario (see for a path the discussion below). An OR fork models a continuation of the scenario into one direction, to be chosen from a number of alternatives. The OR join merges two or sub scenarios into one scenario.

Visualization. An AND fork/join is shown as a line, placed in an angle of ninety degrees between lines visualizing dependency elements. An OR fork/join is presented by a number of lines joining into one (a join), or by a line splitting into more lines (a fork).

Value interface. Another way to connect dependency elements is to use a value interface. We use value interfaces (connected by dependency elements) to create profitability sheets on a per actor basis to assess profitability. Such a sheet shows when objects of value are leaving or entering an actor as a result of scenario path execution.

5.1.3 Constructing Correct Value Models

In chapter 5 we described the 11 steps to take to construct a value model and to valuate the profitability. These steps will guide you during the construction of a value model, providing support (like the goal/activity matrix, value interface library, etc) to make the value model as



Page

184

correct as possible. But this support isn’t exhaustible, in some cases parts of the value model need to be constructed without the help of these references. In these cases it’s important that the self-constructed parts are correct. In this paragraph we will discuss the guidelines to use to construct (parts of) a value model as correct as possible.

5.1.3.1 Creating value interfaces

In step 5 of the process, value interfaces should be selected and constructed. Some of the value interfaces will be copied from the value interface library; others should be constructed, based on the identified goals. For each goal one or more value interfaces can be constructed to accomplish this goal.

A value interface consists of one or more offerings. In turn, an offering contains ports which offer or request value objects, depending on the port’s direction. For each actor, all these constructs have to be identified. To do so, we have the following steps:

1. Identify value ports and objects exchanged by ports;

2. Group value ports into value offerings;

3. Group value offerings into value interfaces.

In some cases it may be more useful to identify value exchanges first instead of value ports. Therefore a fourth step can be identified, apart from the first three;

4. Identify value exchanges.

5.1.3.1.1 Identify value objects and ports

We use a number of guidelines to find value objects and ports: (1) the e-commerce idea and scenarios should trigger value objects, (2) actors want something in return for value objects they offer (economic reciprocity), and (3) actors need to obtain other value objects to offer a value object themselves (causally related value objects).

Guideline 1: Use products and services mentioned in the e-commerce idea and scenarios to find value objects.

Explanation. The e-commerce idea and scenarios should trigger identification of value objects. If a scenario does not provide any ground for value objects, the scenario is likely not defined in terms of customers, but perhaps defined in terms of operational business processes.

Guideline 2: Use the economic reciprocity property to find value objects.

Explanation. A second guideline we use is to ask actors which value object(s) they want return for an already identified value object they offer. We call such value objects shortly reciprocal value objects. It is our experience that in nearly every situation reciprocal value objects can be found.



Page

185

Guideline 3: Use causally related value objects to find value objects.

Explanation. Thirdly, we search for causally related value objects. To be able to offer a value object to his/her environment, it is likely that an actor must obtain one or more other objects, which we call causally related value objects. This is for instance the case for a trading company. Objects, which are sold, must also be bought.

Guideline 4: How to determine if something is a value object? A value object must be of economic value for at least one of the two actors exchanging the object.

Explanation. The criterion used for distinguishing value objects is that a value object must be of economic value for at least one actor. Following this formulation a value object needs not to be of value for both actors exchanging the object. This is motivated by the observation that valuation of objects depends largely on an individual actor [Holbrook 1999], and consequently not both actors have to assign economic value to an object.

Guideline 5: How to determine the direction of ports? The direction models the direction into which ownership will be transferred, or to whom rights are granted.

Explanation. Each value object delivered or requested by an actor results in a port for doing so. For such a port, the direction has to be determined. The criterion to decide whether a port has a direction in or out is to assess whether an actor will obtain (in-port) or loose ownership (out-port) once the object has been exchanged. For service oriented objects, the criterion is the grant (in-port) of the right to receive the service, or the obligation (out-port) to deliver the service.

5.1.3.1.2 Group ports into value offerings

We have in our e3-value methodology two mechanisms for grouping value ports. The value offering is used to group equally directed ports, e.g. for showing mixed bundling, while the value interface is used to model the notion of economic reciprocity (to be discussed in the next section). In case of a value offering, different motivations apply for grouping in- and out-ports.

Guideline 6: If value objects obtained via in-ports are only of value for an actor in combination, then group the in-ports into an offering.

Explanation. In-going ports are grouped into an offering to express that an actor only assigns economic value to objects if they come in combination. This is exemplified in paragraph 5.1.1: a surfer who wants to access the Internet, must obtain an Internet access connection from an Internet Service Provider (ISP) and must obtain a telephone connection between him/herself and the ISP for data transport.

Guideline 7: If value objects offered via out-ports are only available in combination, e.g. as a result of mixed bundling or cost-effects, then group the out ports into an offering.

Explanation. There can be several reasons to group out-going objects into one offering, rather than to offer these objects separately. Here we distinguish two considerations, which can used as a guideline: (1) to model mixed bundling, and (2) to model cost avoidance.



Page

186

Mixed bundling is a way to increase total profit for a supplier of objects. An actor then supposes that different products sold in combination yield more profit than that if they were sold separately [Choi 1997]. Suppose there are three customers (Alice, Bob, and Charlie), and two products X and Y offered by a supplier S. Product X is valued Euro 40, 50, and 60 by Alice, Bob and Charlie respectively. Product Y is valued the same, but in the reverse order of Charlie, Bob, and Alice. Also suppose that both products cost supplier S Euro 40, and that they are sold for Euro 50. In this situation, X is sold to Bob and Charlie, while product Y is sold to Alice and Bob. Total profit for S is Euro 40. As an alternative, supplier S may also consider to sell X and Y only in combination for Euro 100. In such a case, Alice, Bob and Charlie buy X and Y. Total profit is then Euro 60.

A second reason for grouping out-going ports is that some objects can only be cost-effectively offered in a bundle rather than separately. This is the case in the project outlined in (Gordijn 2002), which is about a service of a newspaper offering its archive of news articles to its subscribers via the Internet also. In this e-commerce idea, the entire operation of Internet service provisioning (telephone connections, Internet access and web hosting) is outsourced to another party, a Telco. This Telco is capable of offering connectivity, access and hosting for a low fee, if all equipment is co-located at a telephone switch. In contrast, if e.g. the Internet access servers and the telephone switch are hosted at a different location, a higher fee is asked. In this case, grouping is used to express that, for a low fee, the value objects denoting connectivity, Internet access and hosting can be obtained, but only in combination.

5.1.3.1.3 Group value offerings into value interfaces

Value interfaces are used to model the notion of economic reciprocity, a guideline we also use to find value objects and ports. For each port of an actor, which is part of an offering, other port(s) of opposite direction are searched for, which compensate for objects exchanged via the first port. The offerings, which contain these ports, are grouped into a value interface. To find value interfaces we use the following guidelines: (1) a value interface consists of two opposite offerings, and (2) causally related offerings are not grouped into a value interface.

Guideline 8: A value interface should consist of two reciprocal offerings.

Explanation. Reciprocity is our experience that in nearly all cases, a value interface consists of two opposite directed offerings. The direction of an offering is equal to the direction of its ports. The reason for this guideline is that a rational actor only is willing to exchange an object oout, if s/he obtains another object oin in return. Moreover, s/he must assign to object oin a higher economic value than to object oout.

However, we did not formalize this rule in our e3-value methodology. The reason for this is that we can think of cases where the act of exchanging objects between actors is positively valued by both actors involved. In Figure 66 actor a assigns value to delivering an object of value (this is e.g. the case if the object is waste from an actor a perspective), while actor b assigns value to obtaining the object (waste of someone else can be a resource for another party). However, in real-life projects we did not encounter such a situation. Therefore, if a value interface consists of only one offering, this is an indication for a yet undiscovered value object and port, and a motivation to redo identification of value ports and objects.



Page

187

Figure 66. Value interfaces with each having an offering containing only one port.

Guideline 9: Never group causally related offerings.

Explanation. We do not group value offerings, which are causally related. Two offerings are causally related, if a port in the first offering is causally related to a port in the second offering. Two ports are causally related if, in order to produce a value object oout by a port, a value object oin must be obtained by the other port. An actor does so by performing a value activity: s/he adds value to object oin, resulting in object oout. Note that the direction of causally ports differs: the port offering object oout is an out-port, while the port requesting object oin is an in-port. We do not group these ports into one value interface, because the value interface is a construct that shows which objects are offered, and which objects are requested, as a compensation, in return. Instead, the causal relation between in- and out-ports is represented using a scenario path. Such a path shows which exchanges on value interfaces cause exchanges on other value interfaces.

5.1.3.1.4 Identify value exchanges

A market oriented approach starts with the identification of value exchanges rather than ports. The difference between both approach is that during the actor oriented approach, we ask for a specific actor what s/he offers and request to and from his/her environment (other actors), while during the market oriented approach, we ask a number of actors (in many cases two or three actors), what they offer each other.

Guideline 10: Use guidelines 2.6-2.9 also for identification of value exchanges.

Explanation. The aforementioned guidelines for finding ports following an actor-oriented track can also be used to find value exchanges by using a market oriented track. Already identified scenarios provide a starting point for finding value exchanges (guideline 2.6). Also reciprocal value exchanges, similar to reciprocal value ports can be identified (guideline 2.7). Note that if an actor a1 offers a value object to some other actor a2, actor a1 needs not to be compensated by the same actor a2. As a third guideline, already identified value exchanges can be used to find causally related value exchanges, in the same way as we identify causally related value ports (guideline 2.8). Finally, value objects are only modelled if they are of economic value for at least one actor (guideline 2.9).

5.1.3.2 New actors

In chapter 4 a list of possible actors on the electricity market is provided. But in the future



Page

188

new actors or activities will appear which are not described in this document. The guidelines in this paragraph can be used to identify these new actors.

Guideline 11: Deal with yet unknown actors by distinguishing identified and non-identified actors.

Explanation. It sometimes occurs that it is known that a specific kind of actor is needed, who is not yet explicitly identified by name. This is for instance the case if some specific actors decide to explore an e-commerce idea, and discover they can not put into operation the idea solely by themselves. To this end, we distinguish two kinds of actors:

1. identified actors, such as they are described in chapter 4 of this document;

2. non-identified actors, which are necessary for the value model, but yet unknown.

A similar distinction has also been made by Ould (1995) who distinguishes an actor (e.g. George Bush) from a role instance (e.g. the president of the United States).

Guideline 12: Use environmental actors for actors which are needed to let the value model work but which are not of interest for profitability analysis.

Explanation. Many modelling techniques have the notion of an environment of a model. A value model may also have an environment. The environment of a value model consists of actors (or value activities) we are not interested in from a profitability perspective, but who are needed to let the value model work. Such an environmental actor is only shown because another actor, who is part of the value model, must be able to obtain his/her value objects from someone.

5.1.3.3 Creating scenario paths

A scenario is modelled using one or more scenario paths. Scenario paths show which value objects need to be exchanged via actors’ interfaces as a result of the execution of a scenario. As such, scenarios paths are traces through a use case map. To identify scenario paths, we first have to construct one or more use case maps on top of the value model, and hereafter we have to identify the paths through such maps (see Figure 67).

5.1.3.3.1 Identify use case maps

Essentially, use case maps are developed by taking a start stimulus and finding value exchanges an actor must do, to fulfil needs expressed by such a stimulus. In doing so, we distinguish the following steps (see Figure 67):

1. identification of the start stimuli themselves;

2. identification of parts of a use case map within an actor. Such a partial map models via which value interfaces an actor must exchange value objects as a result of: (1) a start stimulus, or (2) the exchange of value objects via one of his/her other value interfaces. In the first case, the partial map connects a start stimulus with one or more responsibility points touching value interfaces of the same actor, in the second case,



Page

189

the partial map connects responsibility points touching value interfaces of the same actor.

3. identification of parts of a use case map between actors. This partial map models which value exchanges (via which interfaces) must occur between actors, if one actor decides to exchange value objects.

4. identification of a stop stimulus. If an actor exchanges value objects via one of his/her value interfaces, s/he may need to exchange other value objects, or the scenario may end.

Guideline 13: Base start-stimuli on end-customer needs.

Explanation. A scenario description relies on customer needs. Some of the customers are end-consumers: they buy a product or service for consumption and do not re-sell it anymore. Such customers often cause start-stimuli, which cause a cascade of value exchanges.

Guideline 14: If an actor can choose from more than one of his/her value interfaces to satisfy his/her needs caused by a stimulus or exchanges via another value interface, then use an OR element to connect the stimulus/responsibility points touching these interfaces.

Explanation. An actor will exchange value objects via one of his/her interfaces as a result of: (1) a start stimulus, or (2) exchanges via another value interface of the same actor, shown by a responsibility element touching such a value interface. Each of these causes that an actor exchanges objects via one of his/her other value interfaces to satisfy his/her needs (or a stop stimulus occurs). To do so, it can be the case that an actor may choose from alternative value interfaces s/he has. An OR fork is then needed to connect the stimulus/responsibility element with responsibility elements touching all these alternative value interfaces, modelling that different continuations along different paths of the scenario are possible. Note that introducing an OR-fork results in different scenario paths for the same scenario.

It can also be the case that exchanges via a value interface can be caused by exchanges via other, alternative, value interfaces of the same actor, or by alternative start stimuli. An OR join is then needed to connect the start stimuli/responsibility points of these alternative value interfaces with the responsibility point of the first mentioned value interface.

Guideline 15: If an actor must use multiple value interfaces of his/herself to satisfy his/her needs caused by a stimulus or exchanges via another value interface, then use an AND construct to connect the stimulus/responsibility points touching these interfaces.

Explanation. It occurs that, to satisfy a need, multiple objects, which are obtained via different value interfaces of a same actor, are required. In such a case, an AND fork is needed to connect the stimulus/responsibility elements with the responsibility elements touching the different value interfaces satisfying the need.

Similarly, it can be the case that as result of exchanging value objects via more than one value interface, an actor will exchange value objects via only one other interface. In such a case, an AND join must be used to connect the responsibility points touching the value



Page

190

interfaces.

Identifyscenarios

Identifyactors

Identify valueexchanges

Identify valueinterfaces&

offerings

Identify valueinterfaces&

offerings

Identify valueexchanges

IdentifyUCMs

scenario list

actor list

stakeholder agreed &ontology compliant model+paths?

[Not agreed/notontology compliantmodel andscenario paths]

[Marketdriven track]

[Actordriven track]

value model+ paths

[Agreed/ontologycompliant model andscenario paths]

value model

Track?

value model

Figure 67. Identification of use case maps and paths.



Page

191

Guideline 16: If value ports of two value interfaces of different actors exchange value objects with each other, and all these ports are connected with each other by value exchanges, then connect the responsibility points touching these interfaces.

Explanation. In many situations actors exchange objects of value with each other on a bilateral basis. Then two actors, each with one value interface, are connected by relating all value ports of these interfaces by value exchanges. In such a case, the two responsibility points touching the value interfaces must be connected.

Guideline 17: If three or more value interfaces of different actors exchange value objects, then connect the responsibility points touching the interfaces with an AND construct.

Explanation. It is possible that the exchange of value objects via an actor’s interface results in exchanges with more actors and consequently with more value interfaces. For instance, in Figure 64 a surfer needs to exchange value objects with both a local operator and a free Internet service provider. In such a case, an AND fork is needed on the scenario path to denote that the scenario path forks into to sub paths which each must be executed. Also, exchanges via multiple value interfaces may result into exchanges via one other value interface. In such a case, an AND join is needed

Guideline 18: If an actor can choose from a number of value interfaces of other actors to satisfy his/her needs, then use an OR construct to connect responsibility points touching the value interfaces.

Explanation. An actor’s value ports in a particular value interface may be connected to multiple other value ports of different actors (see Figure 58). This models that an actor can choose from a number of actors to fulfil his/her needs. This should also be reflected in the use case map by adding OR elements.

5.1.3.3.2 Identify paths

Different paths in a case map exist if OR constructs have been used. Note that OR constructs result in multiple routes, while AND constructs only introduce sub paths, which all are executed.

Guideline 19: Find scenario paths by focusing on OR constructs in a use case map.

Explanation. Paths can be identified by ‘executing’ the scenario by starting at the start stimulus, and traversing through the map. Each time an OR construct is encountered, multiple scenario paths, depending on the number of path continuation elements connected to the OR construct, can be identified. Note that it is not necessarily the case that such a path exists; not all theoretical possible paths through a use case map need to be paths which exist in the Universe of Discourse.

5.1.3.3.3 Global actor, detailed actor and value activity viewpoints



Page

192

As discussed in paragraph 5.1.2, a value model may consist of various sub viewpoints: (1) a global actor viewpoint explaining the overall value model to all stakeholders involved, (2) detailed actor viewpoints representing partnerships between actors or constellations of actors, and (3) value activity viewpoints representing who is doing what.

5.1.3.3.4 Global actor viewpoint

In simple exploration tracks, the viewpoint containing all actors is the global actor viewpoint. However, as discussed below, there can be motivations to detail the global actor viewpoint into constellations or partnerships.

5.1.3.3.5 Detailed actor viewpoints

There are two reasons to introduce viewpoints: (1) to model constellations of actors to reduce complexity, and (2) to model partnerships between actors: a joint offering of actors to their environment.

Guideline 20: Use a detailed actor viewpoint (value constellations) to reduce complexity.

Explanation. Value constellations capture parts of a value model. The main reason for doing so is reduction of complexity of discussions and the resulting model. Sometimes, discussions between stakeholders concern not all actors, but only a specific subset of actors. Moreover, these discussions may not contribute much to an overall understanding of the value model. In such a case, we introduce a detailed actor viewpoint to hide to complexity of these specific actor discussions for all other stakeholders involved.

Guideline 21: Use a detailed actor viewpoint (partnerships) to model that actors have joint value interfaces.

Explanation. A second reason to introduce a detailed actor viewpoint is to represent that actors are jointly offering or requesting objects to or from their environment. In such a case, two or more actors bundle objects they offer and request into one value interface of the composite actor. This can e.g. be used if objects are offered for a lower price as a whole, than that they were offered separately by individual actors. In such a case, a detailed actor viewpoint must be developed, because is represents a case of bundling.

5.1.3.3.6 Value activity viewpoints

Value activities are introduced for the following reasons: (1) to discuss alternative assignments of activities to performing actors, and (2) to model the environment of a value model.

Guideline 22: Use value activity viewpoints to discuss alternative assignments of value activities to actors.

Explanation. Value activity viewpoint(s) show the assignment of value activities to performing actors. Multiple viewpoints can be used to show alternative assignments. During the development of a value model as described in this section, we assume the existence of one value activity for each elementary actor involved, with the same value interfaces as the actor has. This assumption is not modelled explicitly yet. Studying other activities as well



Page

193

alternative assignments of value activities to actors is part of deconstructing and reconstructing value models (see paragraph 5.1.3.5).

Guideline 23: Use environmental value activities for activities which are needed to let the value model work but which are not of interest for profitability analysis.

Explanation. We introduce environmental value activities if we are not interested in profitability analysis of these activities, but simply assume that they exist, and are capable of delivering objects of value. Such activities are typically introduced if an actor participating in the value model already performs an activity, and wants to develop some other activity. See also guideline 2.4.

5.1.3.4 A cyclic process

Chapter 5 describes 11 steps to be executed to develop a value model. To our experience, these steps have to be taken a number of times, before actors agree on a value model and before they understand it. Decisions to be taken while executing a step are in practice too heavily interrelated with decisions in other steps. Also, to comply with concepts, relationships and constraints formulated by e3-value ontology, a number of iterations are needed. In sum, we advocate that the formulation of a value model takes a number of exploration cycles.

After execution of a number of cycles, a value model should be found, such that (1) all stakeholders understand it and tentatively agree on it (execute decision making is done after evaluation of an e-commerce idea), and (2) it complies with the e3-value ontology.

5.1.3.5 Deconstruct and reconstruct value models

If a value model is known, it can be used to find variations. A way to find such variations is to deconstruct and reconstruct a value model.

Deconstruction and reconstruction takes the following steps. First, we deconstruct value objects and ports into smaller value objects and ports to find smaller portions, which can be requested or offered by an actor from or to his/her environment, Second, we debundle value interfaces and value offerings, into value interfaces and offerings with a smaller number of value ports. Third, we deconstruct value activities into smaller value activities. Finally, we reassemble new value models, by assigning the newly found value activities to actors.

5.1.3.6 Develop other viewpoints

The focus in this chapter is how to execute an exploration track from a value perspective. However, in this chapter we argued earlier that it is important to develop other viewpoints, such as a business process viewpoint and an information system viewpoint. How to explore these other viewpoints is not a topic of this section. However, the outcomings are important. On the one hand, these viewpoints can indicate whether a value model is operational and technical feasible. As such, exploring these viewpoints may cause changes in a value model. In (Gordijn & van Vliet 1999) we discuss how the exploration of a security viewpoint influences the value model at hand. On the other hand, exploration of process and



Page

194

information system viewpoints yields knowledge about operational and capital expenses, which are of use to construct profitability sheets.

Guideline 24: Start with a value viewpoint, but develop other viewpoints as soon as possible to reveal insight in operational and technical feasibility as well as substantial expenses quickly.

Explanation. It is our experience that the exploration tracks we have carried start out with an articulation of a value model. However, after the construction of such a model, it is worthwhile to explore other viewpoints also, because they can reveal important information regarding operational feasibility of an e-commerce idea. If it turns out that a value model is hardly operationally feasible, further exploration of the model can be stopped, or alternatives can be searched for. Moreover, early exploration may gain insight in substantial operational and capital expenses.

5.2 Financial models

5.2.1 Evaluate e-commerce ideas

This chapter focuses on exploration of the value viewpoint, so we continue with a discussion on e-commerce evaluation from a value perspective.

Evaluation of an e-commerce idea focuses on the question whether an idea is feasible from an economic point of view that is whether an idea is profitable for each actor involved. It is our experience that numbers on profitability themselves are not are very useful for stakeholders involved, because it is not possible to predict profitability numbers for innovative e-commerce ideas accurately. Results of exploitation such innovative ideas are unknown by definition, which makes it very difficult, if not impossible, to estimate important numbers to determine profitability, e.g. the number of scenario occurrences per timeframe. What is however important for stakeholders, is to reason about profitability, and to do a sensitivity analysis. This contributes to a better understanding of the e-commerce idea, in this case from a profitability perspective. To do so, we (1) create profitability sheets for each actor involved in the value model, (2) ask actors to assign economic value to objects delivered and received, and (3) use evolutionary scenarios to determine effects of expected changes in the future that influence profitability.

5.2.1.1 Create profitability sheets

Profitability sheets. Profitability sheets are constructed for each actor involved, and present revenues and expenses associated with the execution of the e-commerce idea under consideration. The structure of a profitability sheet is shown in



Page

195

Table 21. It contains for each actor value objects flowing into- and out as a result of scenario path execution. Also, substantial operational expenses as a result of performing activities and expenses caused by exploiting an information system and performing operational activities are shown by a profitability sheet. In this section, we focus on the creation of profitability sheets based on the value viewpoint.

Guideline 25: Create profitability sheets by following scenario paths.

Explanation. To create profitability sheets for actors, we utilize our UCM scenario paths (see paragraph 5.1.2.4). These paths are put into operation a scenario, and show which value objects are exchanged by actors via their value interfaces, as a result of the occurrence of one or more start-stimuli. If, as a consequence of scenario path execution, an actor needs to exchange value objects, the path touches the value interface of that actor. Touching such a value interface by a scenario path is represented by a scenario path’s responsibility point.

Profitability sheets are constructed by following for each scenario its scenario paths. By following a scenario path, and by searching for responsibility points on that path, we find the objects of value each actor exchanges as a result of executing the path. So each time we find a responsibility point, we examine the value interface it touches. The object(s) flowing out the interface of that actor are added to the actor’s profitability sheet in the column value object out, while the objects flowing into an actor are added to the actor’s profitability sheet the in column value object in.

Estimate scenario occurrences.

To calculate profitability for each actor involved, we need to know the expected number of scenario occurrences per timeframe (e.g. per month), and the likelihood that a scenario path of a scenario is executed.

Guideline 26: Estimate the number of scenario occurrences by estimating the number of start stimuli occurrences.

Explanation. Scenarios are described by scenario paths, of which start stimuli are part of. These stimuli are the drivers for scenario paths. Consequently, to estimate the number of scenario occurrences, we must estimate the number of start stimuli.

Guideline 27: The percentages of likelihoods for scenario paths, which put a scenario into operation, should sum up to 100 %.

Explanation. A number of scenario paths put into operation a specific scenario. To calculate the profitability of the execution scenario occurrences per timeframe, we must therefore know the chance that each scenario path will be executed. Likelihood percentages for paths of such a scenario must sum up to 100 %. Otherwise, scenario paths have been forgotten, or estimations are not adequate.



Page

196

Table 21. Structure of a profitability sheet.

Actor X

Viewpoint value viewpoint

Scenario A

Occurrences/timeframe …

Value Object In Value Object Out

Scenario path 1

Likelihood …%

Euro x1 Euro y1

… …

Scenario path N

Likelihood …%

Euro xn Euro yn

Scenario …

Scenario Z

Viewpoint Business process

Scenario Similar to the value viewpoint, but with potentially a different number of scenario paths.

Viewpoint Information system

Scenario Similar to the value viewpoint, but with potentially a different number of scenario paths.

5.2.1.2 Assign economic value to objects

After a profitability sheet for each actor has been constructed, actors are asked to assign economic value to objects flowing into or out themselves. We then can calculate profitability numbers for each actor. Note that if we only calculate this ‘profitability’ for the value viewpoint, we do not take in account operational expenses as a result of executing business processes and exploiting an information system. Also, investments needed are not part of this profitability number. However, if for one of the actors profitability is less or equal to zero,



Page

197

the e-commerce idea is not likely to be profitable for such an actor, given the identified model and estimations on scenario occurrences, on scenario path likelihoods, and on valuation of objects by actors.

We distinguish two actor types, who assign economic value to objects in a different way:

1. Enterprises: these are actors who produce, resell, or distribute objects to make profit, or at least to cover their expenses;

2. End-consumers: these are actors who do not resell value objects, but use obtained objects to create economic value for themselves.

5.2.1.2.1 Assign economic value to objects: enterprise perspective

Guideline 28: Assume enterprise actors strive for profit maximization: they value only money objects.

Explanation. Enterprises want to maximize their profit: in short revenues minus expenses to generate revenues. As such, we only take in account value objects representing money flows to calculate an enterprise’s profitability sheet. This also suggested by investment theory (see e.g. Horngren & Foster 1987), who take in consideration cash-in and -outflows only. We assume that all other objects (not representing money) flow into an enterprise, and after some time flow out the same enterprise, and are not of relevance for determining profitability.

We distinguish the following steps in investigating valuation of objects by enterprise actors. First, for each value port representing the exchange of money objects, we determine its valuation function. The valuation function returns the amount of money to be paid for obtaining other, money, value objects. Second, we must assess whether each non-money value object, which flows into an enterprise, also flows out this enterprise. To do so, we reduce the profit sheet by removing non-money value objects, which are flowing into and out an actor.

Determine valuation functions for ports exchanging money objects.

Value objects are offered and requested via ports of a value interface. In many cases, at least one object exchanged via a port in an interface represents money. For such a port, we determine a valuation function. This function calculates the amount of money to be paid or to be received for obtaining another value object(s) via ports of the same value interface.

A valuation function is in many cases determined by the actor receiving a payment, but can also be a result of a negotiation between actors. The function uses a number of properties, e.g. properties of the product to be sold, to calculate the amount of money. Investigating these properties, as well as assigning values to these properties is part of determining a valuation function.

Reduce other (non-money) value objects.

Objects representing something else than money are not considered in the enterprise’s profitability sheet. However, to check whether all in-flowing non-money objects are also leaving the enterprise actor (and vice versa) we reduce the profitability sheet of an actor. Reduction means removal of non-money value objects of a profitability sheet if these objects



Page

198

are causally related.

Guideline 29: Use objects, which cannot be reduced, to find yet undiscovered actors or value activities.

Explanation. In some cases, it is not possible to reduce objects, because the causally related in- of out-going object have not been modelled. This can be an indication that actors have been forgotten, or part of the environment of the value model has been omitted (e.g. actors or value activities in which we are not interested from a profit perspective, but which are needed to let the value model work, see section 5.1.3). Then the value model itself needs to be reconsidered.

In sum, valuation from an enterprise perspective consists of finding valuation functions for objects exchanging money. Non-money objects are removed from an actor’s profitability sheet, if other causally related non-money objects can be found.

5.2.1.2.2 Assign economic value to objects: end-consumer perspective

Guideline 30: Assume end-consumers strive for consumer value maximization: they value all objects.

Explanation. End-consumer actors do not aim at profit. Rather, they want to satisfy their needs. To do so, end-consumers can generally select from a number of different value objects offered by others. In general, these value objects satisfy end consumer’s needs not to an equal extent. Some objects will fulfil end-consumer’s needs nearly completely, while others do so only very limited. Which object will be chosen by an end-consumer?

To make a decision, an end-consumer assigns an economic utility to each object (see e.g. Kotler 1988). Second, to obtain an object, an end-consumer must give another object in return. In most cases this is a fee in Euros or Dollars. According to (Kotler 1988) the end-consumer then will choose for the object that delivers the most utility per Euro, if s/he is a rational acting person. This is in axiology literature also known as consumer value maximization [Holbrook 1999]. As a consequence, to assess to what extent an end-consumer maximizes his/her consumer value we need to know how an end-consumer assigns economic value, especially to non-monetary objects. To do so, we identify market segments to find actors who value objects equally, and then identify valuation functions for value objects exchanged via ports of the aforementioned market segments. These functions return the utility assigned to an object in terms of a monetary unit (Euros or Dollars). By doing so, we make non-monetary objects comparable with monetary objects seen from a utility perspective.

Determine valuation functions for ports of an end-consumer

For each value object exchanged by an end-consumer we provide a valuation function. This function returns, given a number of properties, the economic value in terms of a monetary unit assigned to an object by an end-consumer. These properties can be observable object properties, but can also be consumer specific properties.

Guideline 31: Assume end-consumers use a multi-criteria approach to assign value to object.

Explanation. We assume end-consumer actors use a number of criteria to ‘calculate’ the



Page

199

value of a non-money object. Also, these criteria can be weighted differently. To elicit these criteria, we utilize Holbrook’s [Holbrook 1999] consumer value framework.

For money objects, also a valuation function must be available. In most cases, an enterprise selling an object determines this valuation function, or the function is a result of a negotiation process.

5.2.1.3 Evaluate using evolutionary scenarios

5.2.1.3.1 Evolutionary scenarios

The profitability for each actor estimated by using profitability sheets, valuation functions, and scenario occurrences and path likelihoods, may differ substantially from reality, during execution time of an e-commerce idea. There can be various reasons for this.

First, a value model (including UCM scenario paths and valuation of objects by actors) may be incomplete. Expenses and revenues, which occur during execution of the e-commerce idea, then have not been foreseen. Moreover, if profitability sheets are only based on a value viewpoint, and not on process- and information system viewpoints or additional viewpoints, profitability numbers surely will not reflect reality. They should then be seen as a surplus of money needed to cover additional expenses.

Second, estimates such as valuation functions and the number of scenario occurrences may be subject to uncertain estimate. For instance, real consumer behaviour can be different from estimations made during idea exploration. Also, future events may cause profitability numbers, which differ from estimated numbers. With respect to future events, (Heijden 1996) distinguish the following uncertainties: (1) risks, (2) structural uncertainties, and (3) unknowables. Risks are events, which can be predicted, in many cases based on historical date, and likelihood for the occurrence of such an event can be estimated. Structural uncertainties are not frequently occurring events, which can be thought of, but for which the likelihood of occurrence cannot be estimated. Finally, unknowables are events, which cannot be foreseen.

In sum, it is very likely that identified profitability numbers will not be the profitability numbers once an e-commerce idea is put into operation. Moreover, profitability numbers will vary during the time span the e-commerce idea is in execution.

What is then the value of profitability sheets? First, positive numbers on profitability can contribute to an increase of stakeholders’ confidence that an e-commerce idea can be successful. Also negative profitability numbers found for actors act as drivers to redo parts of value model construction process, which may lead in a better understanding of the idea. Either the value model should be changed such that each actor has positive profitability numbers, or, if such a change is not possible, the e-commerce idea seems not to be feasible. Second, the profitability sheets can be used to reason about conditions, which influence profitability of an e-commerce. It can explain to stakeholders critical factors, and make stakeholders aware of strong and weak points of the e-commerce idea.

To facilitate reasoning about profitability sheets we employ evolutionary scenarios. In contrast to operational scenarios, which describe behavioural aspects, evolutionary



Page

200

scenarios describe events, which are expected to possibly occur in the future. As such, effects of events underlying risks and structural uncertainties are analysed, as well as effects of wrong estimations.

5.2.1.3.2 Elicit evolutionary scenarios

Scenario techniques to evaluate effects of expected events occuring in the future are used in a number of disciplines. From a business perspective, (Heijden 96) discusses scenarios as a tool for executive decision making (see also Ringland 1998). In the realm of software engineering, properties of information systems are evaluated during the development using evolutionary scenarios [Bass 1997].

Two extreme positions on finding scenarios exist [Carroll 1992]. On the one extreme, scenarios can be collected empirically. This is often done by interviewing stakeholders, or having workshops on scenario identification. On the other extreme, some theory of scenarios can be used. Such a theory identifies the kinds of scenarios that exist. These types of scenarios are used to organize scenarios, but also to generate scenarios.

Guideline 5.8

Guideline 32: Find evolutionary scenarios by asking stakeholders, while keeping various kinds of scenarios in mind.

Explanation. In practice, we elicit scenarios by interviewing stakeholders and/or doing workshops. While doing these interviews and workshops we keep in mind various kind of scenarios which may occur: (1) scenarios which result in changed valuation functions, (2) scenarios which result in changed numbers of UCM scenario occurrences and likelihoods, and (3) scenarios which result in a changed value model structure.

Guideline 33: Use a change in a valuation function to find an evolutionary scenario.

Explanation. Enterprises may decide, during execution of an e-commerce idea to price objects differently than was estimated during idea exploration. They change then their valuation function for money objects. They are motivated to do so, if valuation functions for end-consumers are not estimated correctly. Valuation functions can also change as a result of other causes.

Guideline 34: Use a change in the number of expected UCM scenario occurrences and likelihoods to find an evolutionary scenario.

Explanation. A realistic estimation on the number of UCM scenario occurrences per timeframe, as well as the likelihood of scenario paths is important but difficult. It is difficult because innovative e-commerce ideas are about new, unknown value propositions, so hardly any historical data can be used to estimate the number of UCM scenario occurrences. A realistic estimation is important, because the number of scenario occurrences directly relates to the number of value exchanges per timeframe, and affects the profitability sheet. This estimation becomes even more important if for the execution of the e-commerce idea investments are needed, which depend on the number of scenario occurrences. Consider for instance our previously discussed project on free Internet access. Offering such a service requires substantial investments in computer hardware such as access servers, and capacity in telephone switches. These investments are done before the e-commerce idea is put into operation. If such a service e.g. is based on about 1000 scenario executions per



Page

201

hour, and in practice only 100 scenario executions per hour occur, it can be expected that the estimated profitability will decrease. Therefore, it is worthwhile to identify a number of events, such as a complete failure of the e-commerce idea, (formalized by very few scenario occurrences), and a success of the idea.

Guideline 35: Use a change in a value model’s structure to find an evolutionary scenario.

Explanation. Also the structure of the model consisting of actors, activities, exchanges, interfaces, etc. can evolve. Evolutionary scenarios can be used to study these effects. Likely changes are shifts in value activities, new actors (e.g. competitors), and disappearing actors.



Page

202

References

Bass, L., Clements, P. & Kazman, R. (1997), Software Architectures in Practice, Addison-Wesley, Reading, MA.

Borst, P. (1997), Construction of Engineering Ontologies for Knowledge Sharing and Reuse, PhD thesis, Universiteit Twente, Enschede, NL.

Buhr, R. J. A. (1998), ‘Use case maps as architectural entities for complex systems’, IEEE Transactions on Software Engineering 24(12), 1131–1155.

Carroll, J. M. & Rosson, M. B. (1992), ‘Getting around the task-artifact cycle: How to make claims and design by scenario’, ACM Transactions on Information Systems 10(2), 181–212.

Choi, S.-Y., Stahl, D. O. & Whinston, A. B. (1997), The Economics of Doing Business in the Electronic Marketplace, MACMillan Technical Publishing, Indianapolis, IN.

Davidow, W. H. & Malone, M. S. (1992), The Virtual Corporation – Structuring and Revitalizing the Corporation for the 21st Century, HarperCollings, New York, NY.

Gordijn, J. (2002), Value-based Requirement Engineering, PhD thesis, Vrije Universiteit, Amsterdam, NL

Gordijn J. & van Vliet, J. C. (1999), On the interaction between business models and software architecture in electronic commerce, in M. Lemoine, ed., ‘Addendum to the proceedings of the 7th European Software Engineering Conference/Foundations of Software Engineering, Toulouse’.

van der Heijden, K. (1996), Scenarios: The Arts of Strategic Conversation, John Wiley & Sons Inc., New York, NY.

Holbrook, M. B. (1999), Consumer Value: A Framework for Analysis and Research, Routledge, New York, NY.

Horngren, C. T. & Foster, G. (1987), Cost Accounting: A Managerial Emphasis, 6th edition, Prentice-Hall, Englewood Cloffs, NJ.

Kotler, P. (1988), Marketing Management: Analysis, Planning, Implementation and Control, Prentice Hall, Englewood Cliffs, NJ.

Ould, M. A. (1995), Business Processes – Modelling and Analysis for Reengineering and Improvement, John Wiley & Sons, Chichester, UK.

Ringland, G. (1998), Scenario Planning: Managing for the Future, John Wiley & Sons Inc., New York, NY.

Tan, Y.-H. (2002), ‘Formal aspects of a generic model of trust for electronic commerce’, Journal of Decision Support Systems and Electronic Commerce.



Page

203

Chapter 6 Commonly Made Mistakes

Now we have mentioned all guidelines to use while constructing correct value models, we will present a list of commonly made mistakes. Based on our experiences we know what mistakes are likely to happen, and provide some examples to prevent their occurrence.

6.1 Mistake 1: Modelling physical processes

One of the most occurring mistakes is the modelling of physical processes. The method of business modelling presented in this document is not about modelling physical processes, or the exchange of information, but about the exchange of value. A value exchange is only a correct value exchange if both actors are aware of each other and the value exchange. For example: The distribution of electricity is physically done from generation to transmission to distribution to consumer. But the consumer is buying electricity from a supplier. From his/her point of view, the consumer buys electricity from the supplier.

In Figure 68 you can see the commonly made mistake: There are two different ‘flows’; the physical electricity flow, from generation to transmission, distribution and consumption, and the payment flow, from consumption to supply, market management and generation. This is incorrect. In these value models we do not represent the physical flow of electricity.

Figure 68. Don’t do this… (Modelling physical processes).

Take a look at Figure 69, the right way to model the flow of electricity. Generation is selling its produced electricity to market management, which sells it to supply. Supply at last, sells electricity to consumption. To make this selling possible, supply needs to pay a fee for transmission and distribution.



Page

204

Generation

Transmission

DistributionSupply

Consumption

Market management

electricityfee electricity

electricityfee electricity

T&D fee

distribution

transmissionfee transmission

electricityretailfee

electricityT&Dfee

Figure 69. … do this! (Modelling value exchanges).

Conclusion: Don’t model physical exchange of objects or information. Only model value exchanges. For each value exchange, ask yourself:

Is at least one of the value objects of economic value for at least one of the involved actors?

Is the actor really receiving the incoming value object?

Is the actor really offering the outgoing value object?

Are both parties aware of this value exchange?

If one of these questions can be answered with ‘no’, it isn’t a value exchange.

6.2 Mistake 2: Modelling information exchange

The value models presented in this document don’t represent the flow of data or information. These models only represent the exchange of value objects.



Page

205

Figure 70. Don’t do this… (Modelling information exchange).

For example, when a new customer signs in at the desk of a hotel, he needs to fill in his personal data (name, address) on a form, and then he/she pays a fee before he/she receives a key and has access to a hotel room (Figure 70). The exchange of this information should not be modelled in the value model. We are only interested in the exchange of value objects. That is, in this case, the fact that a person is willing to pay a certain fee to have a hotel room for one night (Figure 71).

Figure 71. … do this! (Modelling value exchanges).

Conclusion: The exchange of information or data is not represented in the value models. Model only the exchange of value objects.

6.3 Mistake 3: Modelling investments

Investments and other one-time expenses should not be modelled in the value model. The main target of the business modelling process in this document is to explore the profitability of business idea. Most important criterion is whether the profitability sheets justify the forecasted investments.

For a proper investment analysis, described in 4.11 , it’s important to strictly separate



Page

206

investments from operational expenses and income. In other words, only value objects which are exchanged depending on the number of start stimuli, need to be modelled. All investments and one-time expenses are only used in the investment analysis in the last step of the business modelling process.

6.4 Mistake 4: Excluding important alternatives

The business modelling process in this document explores the profitability of new business ideas. This exploration should include an exploration of the advantage of the idea in comparison with the most important alternatives.

To explore this advantage, it may be helpful to model these alternatives in the business idea too. You should at least question what alternatives could be included in the business model, instead of excluding them in advance.

For example, if a RES producer wants to enter the market, it will be very helpful to model the ‘conventional’ producers also. In this way you can see the results of choosing for RES or conventional generation in the profitability sheets for all actors. This may lead to very helpful insights. In Figure 72 and Figure 73 you can see an example of including an important alternative.

When, in this example, it turns out that the RES electricity fee for the consumer is far higher than the ‘conventional’ electricity fee, it will strongly influence the success rate of the business idea.



Page

207

Figure 72. Don’t do this… (Exclude important alternatives).

Figure 73. … do this! (Including an important alternative).



Page

208

Chapter 7 Guide on how to create a value model using the e3-value tool

7.1 Guide on how to create a value model using the e3-value tool

In this chapter we create a value model by using the e3-value tool. You can use it as an example as how to create your own model. Also the tool provides help functionality for guidance. The whole process is described in steps, starting with the opening the editor.

Installation instructions about how to install the e3-value tool can be found in Appendix I.

7.1.1 Step 0: Opening the editor

Create a value model from scratch using the e3-value tool After loading the e3-value edit tool, the following main screen appears:

Figure 74. Overview e3-value editor.



Page

209

Menu bar: The menu bar displays functions for storing, opening and printing a model. The following functions do also have shortcuts: New: CTRL-N, Open: CTRL-O, Save: CTRL-S, Cut: CTRL-X, Copy: CTRL-C, Paste: CTRL-V, Print: CTRL-P.

Palette workspace: In this part of the screen at the left you select palette icons to build up your model.

Edit workspace: This central part of the screen displays the model under construction. You drag icons from the palette workspace and drop them on this area to build your model.

7.1.2 The graphical components

In the next figure on the next page the collection of visual elements is shown. Most of the concepts in the e3-value ontology you will find in this figure. The grey areas represent actors (both composite and elementary), market segments and value activities. Because in the graphical editor they have significant common behaviour we refer to these concepts as “value sources”. On the edge of these value sources you find oval white areas. These are the value interfaces. The triangles on these value interfaces represent value ports. Some ports are directed outward from a value source others are directed inward. We distinguish in- and out ports. On the outward side ports are connected to other value sources. These connections represent value exchanges. The dotted lines on the value sources represent connection elements; they connect scenario elements. In the figure all types of scenario elements are displayed: The start stimulus, the end stimulus, the OR fork, the OR join, the AND fork, the AND join and the value interface. The value interface we mentioned before in its role as a bundler of value ports.

The editor also knows scenario ports (black dots on the scenario elements), the exchange label, the name label and the comment. These are only visual constructs and therefore not part of the ontology. When you move you mouse on one of the graphical objects a tool tip might show up. It tells you the unique (in the scope of this diagram), non-editable ID that the graphical editor assigned to this object and the name of the object. At creation every graphical object is given a default name by the editor. This default name is a combination of the object type and its ID. The user can change this name in whatever he chooses. In some cases the tool regards objects with the same name as identical even as the ID’s might differ. This will be explained later on. See section 11.6 .

At the bottom of the figure you see the Value Transactions Collection Editor. It is one of the several types of windows, which can be opened by the user. It displays a list of several value transactions and allows the user to maintain this list and to edit the value transaction. We will discuss these windows later in greater detail. See section 7.1.9.

A value transaction is like the value object an invisible object but part of the e3-value ontology and hence part of the diagram. They are maintained in separate windows on the workspace, which are opened on with the right mouse button. In the Value Transactions Collection Editor you see value transaction vt132 highlighted, representing that the edit and the delete button applies here. In this particular state, the workspace highlights the value exchanges, which belongs to this particular value transaction vt132. Clicking on a value exchange will toggle its belonging to this value transaction. In this way you can partition the



Page

210

value exchanges into value transactions.

Figure 75. Edit text in the edit box.



Page

211

7.1.3 Step 1. Adding market segments and actors to the edit workspace

From the palette workspace, drag the ‘market segment’ icon or the ‘actor’ icon and drop the item to the icon on the edit workspace. This action is represented in the figure below. The newly added element gets a unique name, which can be changed by the user.

Figure 76. Step 1 : drop market segments and actors on the workspace.

Step 1b. Repeat this step until all market segments are in place.

Step 1c. Next, drag an actor icon from the palette workspace and drop the icon to some position on the edit workspace. If you drop an actor on a market segment or on another actor, the dropped actor becomes part of the second object. Later you can release this actor again by dragging it to another position.

Step 1d. Repeat this step until all actors are in place.

Edit text



Page

212

To change the name of a market segment or actor, click once on the text ‘market segment_{x}’ which will bring you in the edit mode. Change the name to your liking and exit the edit mode by clicking anywhere in the edit workspace.

Figure 77. Edit text in the edit box.

You can change the size of each object (e.g. an actor) by clicking on one of the green rectangles on each corner of the object, click, hold and drag the green rectangle to a desired direction.

Figure 78. Enlarge an object by click and dragging the green rectangles.



Page

213

7.1.4 Step 2. Add value activities

In this step we add value activities to actors and market segments. From the palette editor, drag the ‘value activity’ icon to the edit workspace and drop it on some actor or market segment.

Figure 79. Adding value activities with the e3-value tool.

At this moment it is worthwhile to consider the attachment of value sources to each other because reattaching or releasing now is still easy. Changing locations only without changing the attachments will remain easy of course, but reattaching and releasing after the exchanges are already in place is less efficient.

Again you can edit the label as described before. Alternatively you can drag the text by first selecting the text (see Figure 80. Move text on an object to another location.) and then press the Escape button. Now you will get green rectangles around the text box. You can move the text by clicking, holding and moving the textbox with your cursor.



Page

214

Figure 80. Move text on an object to another location.

The results from step 1 and 2 combined are presented in the following figure:

Figure 81. e3-value model after completing step 1 and step 2.



Page

215

7.1.5 Step 3. Adding value interfaces, ports and exchanges

In this step we add value exchanges between value sources. From the palette editor select the value interface icon and drag it on a value source. The position at which you release the mouse button is critical (!) and therefore visualized in the next figure. When dragging the icon (1), you will see a white rectangle with a mouse arrow above it. Do not focus on this arrow, but do focus on the rectangle (2). Be sure the rectangle is really inside the value source. The tool will adjust the interface to the edge so give it some leeway.

Figure 82. Adding value interface on an activity, an actor or a market segment.

You can add value ports to an interface by double clicking it. The Interface Properties Dialog pops up. When you click on the ‘In++’ button an extra ‘in’ value port will be added. When you click on the ‘Out++’ button an extra ‘out’ value port will be added. To remove ports you select them and press the ‘delete’ key or the ’back space’ key on your keyboard. Alternatively right clicking on a port opens the properties dialog with the ‘Cut’ option.

Figure 83. Adding and removing value ports.

Step 3a. Add selected value exchanges.

Step 3b. Repeat step 3a until all the value exchanges are in place.

Step 3c. Next, we will add a value exchange between two value ports. Select a port with your mouse, keep the button pressed and move to another port. You will see that the editor tries to make a connection from the selected port to some other port directed by your mouse. When the ‘hand’ cursor is on its destination, release the mouse button. The value exchange line will then be drawn. The editor allows only sensible exchanges between ports.

Figure 12. Creating a value exchange.

Step 3d. Create all the value exchanges by repeating step 3c. Sometimes all ports of an



Page

216

interface are to be connected to another not yet existing interface. In this case a shortcut comes in handy. Select the existing interface and click with the ‘Ctrl’ and the ‘Shift’ keys pressed on the position where the new interface will appear with all its ports rightly connected.

Figure 84. Move the text on the value exchange line to another location.

Changing texts and positions of the labels attached to the value exchanges is achieved as before.

After step 3, the following overall model is created:

Figure 85. Value model after step 3.



Page

217

7.1.6 Step 4. Add stimuli to the e3-value model

In this step we are adding the start and stop stimuli in the value diagram.

Step 4a. Drag the start stimulus from the palette and drop it on a value source in the workspace.

Step 4b. Repeat this with ‘and’ or ‘or’ scenario elements (1). You can rotate the ‘and’ or ‘or’ element by double clicking it. The ‘Scenario Element Dialog’ will pop up. If you click on ‘rotate 90’ (2) button, the icon will rotate in the palette editor. Press ‘OK’ to leave the Scenario Element Dialog.

Figure 86. Selecting and rotating the ‘and’ and ‘or’ scenario elements.

Step 4c. Finally you add one or more stop stimuli to your value sources

Step 4d. Finish the scenario path by connecting the black dots from the scenario elements to each other. E.g. click on the black dot of a scenario element until it gets green. Next, hold the right mouse button and drag the mouse cursor to the middle of a value exchange. On the black dot of the value exchange, release the mouse button. A scenario path is automatically drawn (right in the figure).

Figure 87. Connect the black dots on the scenario elements to create a scenario path.

Step 4e. Repeat these steps until all scenario paths are in place.



Page

218

After step 1 until 4, the following final e3-value model has been created in the e3-value editing tool.

It is a simple but complete visualization of a business model.

Figure 88. Final e3value model after fulfilling step 1 until 4.



Page

219

7.1.7 Step 5. Editing the e3-value Properties

All elements from the e3-value ontology share the properties of the e3-value_object. Right clicking on such element allows the user of the editor to edit these properties.

Figure 89. Right clicking the market segment opens the context menu.

The properties option opens a dialog for all the graphical parameters. Here you can change the colour, the thickness of the edge and so on. The copy and cut options are as in Windows. More interesting is the Edit E3Properties option. It opens the following dialog:

Figure 90 Choosing the Edit E3Properties pops the E3Properties Editor.

The “Name:” text field allows you to change the name of this e3-value object. Further, the editor allows you to maintain a list of formulas assigned to this market segment. The highlighted formula is being edited in the text field below. The “oops” button allows you to undo your edits so far. The last formula for prefix displays an E3 formula. This will be explained later in full detail. The editor may add construct dependent formulas, such as a count formula for start stimuli. The capitals in the formula indicate that COUNT is a reserved



Page

220

word and the formula is not to be removed. The left hand side of such formulas is not to be changed.

7.1.8 Step 6. Adding value objects and value transactions.

In the e3-value ontology, value ports have a value object. Additionally, value exchanges are part of a value transaction. The editor provides facilities to create value objects and value transactions, and to relate these to value ports and value exchanges respectively. Right clicking in the background of the workspace allows you to open the collection editor for value objects or value transactions. These are semi modal windows in the sense that they do not completely disable the workspace. Firstly value ports/ value exchanges are highlighted indicating they belong to the value object/ value transaction selected in collection editor. Secondly clicking any value port/ value exchange will toggle its membership to the selected value object/ value transaction. This will be reflected by the highlighting in the workspace and by the displayed number of members in the collection window.

Assigning a value object to a value port will release it from other value ports. For convenience, this value object will also be assigned to all free value ports connected to this first value port by value exchanges. This propagates recursively through the model.

Figure 91 The context menu of a value port opens the collection editor of value objects

In Figure 91, the value object money is checked. This indicates that the value port from which the editor was opened transmits money. Initially this is also the value object selected in the collection editor as indicated by the highlight. In the workspace, all the value ports transmitting money are highlighted. From the highlighted line in the figure, you see that thirteen value ports transmit money. Because a value object is not a visible object it is not possible to right click it to get its context menu. Editing its E3properties is therefore accomplished with the edit button in the collection editor. It opens the usual E3Properties Editor as a dialog on the selected value object. In the next figure you see this editor invoked on the value object money.



Page

221

Figure 92 E3Properties Editor invoked from the collection editor on a value object

Figure 93 E3Properties Editor invoked on a value transaction

The FRACTION formula in the above editor represents an integer attribute in the e3-value ontology. It applies in cases when several value transactions originate from the same value interface. It measures as a weight the part of the occurrences that are transmitted through this value transaction. The FRACTION formula is automatically added with initial value 1. When creating new formulas the editor automatically generates a left hand side that can be changed in the lower text field.

7.1.9 Step 7: Modelling value transactions

When modelling value exchanges, it is important that you also create the appropriate value transactions, and assign them to the value exchanges correctly.

The e3-value tool uses value transactions in the process of generating parts of the profitability sheets, and therefore it is required that these are included in your models. If the value transactions are not present, or if they have not been modelled correctly, this will cause problems with profitability generation. In the best event, the e3-value tool will detect



Page

222

the problem and display an error message. In the worst-case scenario, some of the value exchanges will simply be ignored.

Make sure that your model is complete (and correct) before generating profitability sheets!

Below you will find a number of simple examples of correct and incorrect usage of value transactions.

Example 1 – Incomplete model: No value transactions

In this simple example, we have not added any value transactions to the model:

Figure 94 Example: Incorrect value transactions

Attempting to generate a profitability sheet from this model will result in a failure, and an error message will be displayed; without value transactions, the e3-value tool will not be able to find a (scenario) path.

Example 2 – Incomplete model: Incomplete value transactions

In this simple example, one value transaction has been added to the model, but the other one has been 'forgotten'.



Page

223

Figure 95 Example: Incorrect value transactions

Generating a profitability sheet from this example model would not result in an error in contrast to the previous example). Instead, it will result in a corrupt profitability sheet. The e3-value tool will simply ignore the two value exchanges (ve76 and ve75) because they are not involved in a value transaction.

Example 3 – Complete model

Figure 96 Example: Correct value transactions

In the example above, the value exchanges have been correctly bundled into two value transactions. The e3-value tool will recognise both scenario paths and generate a correct profitability sheet.



Page

224

7.1.10 Step 8. Editing scenario ports, adding weights

Scenario ports are not part of the e3-value ontology and therefore do not have E3 properties. Clicking the right mouse button for the context menu gives only one option for the properties. Making this choice brings forward a card layout as shown in the figure below.

Figure 97 The properties option in the context menu of a scenario port

The graphics card gives access to the graphical parameters of the scenario port. The fraction card shown here allows us to change the value of the Fraction attribute of this scenario port. This fraction plays a similar role as the fraction of value transactions in the previous section. It is most important in OR and AND forks as it controls as before the fraction of the occurrences flowing through the assigned scenario path.

7.1.11 Step 9. Creating formulas and adding them to the model

In this paragraph we explain formulas as they are represented in the e3-value tool, how to write them, and how to attach them to objects in your model.

Formulas in the e3-value tool are based on Microsoft Excel (98). This makes it possible to write formulas in the e3-value tool and maintaining them when we want to generate profitability sheets (which are created in the Excel 98 format). This means that you can use Excel-functions and expressions in the e3-value tool!

Before we go into the specifics of formula syntax and structure, we will discuss how to create them and attach them to other objects in the e3-value tool.

Step 1. To create a formula, right click the object you wish to attach it to.

In the context menu, select ‘Edit E3properties’. The ‘E3properties Editor’ screen appears:



Page

225

Figure 98. Assigning formulas to objects

Step 2. Now create a new formula by clicking ‘create’. A new formula should appear in the list below. Highlight it and then enter the formula in the ‘current’ field at the bottom of the screen. A formula should always start with an identifier name, followed by a ‘=’ symbol, and then the formula itself. Click ‘OK’ to save your formula.

Writing formulas

While the formulas are based on Excel, and you can use Excel expressions and syntax in the e3-value tool, there is one difference between e3-value formulas and Excel formulas. This difference lies in the way in which formulas can refer to other values (references).

Where, in Excel, you would typically refer to cells, in the e3-value tool you refer to attributes of e3-value objects.

To be able to refer to e3-value objects and their attributes we use a simple language that consists of a small number of simple syntax rules.

To insert these references into your Excel-style formulas just add ‘e3 {REFERENCE}’ into your formulas where you would normally write cell references in Excel. Of course, you



Page

226

should make sure to replace ‘REFERENCE’ with a reference to an attribute.

Although the syntax counts quite a number of expressions, the structure itself is very simple and straightforward. Any reference can be written as:

‘e3 {TopLevelObject.SubLevelObject.AttributeName}’

Reference expressions always start with ‘e3 {’, and always end with ‘}’

Object-references are separated by a ‘.’.

A top-level object is an object that has to be unique in the scope of a model. Actors, Market segments, Value Objects, all Scenario constructs and Value Interfaces are seen as top-level objects.

If the object is a sub-level object it can be accessed from another object that is on the level above it. This may be done multiple times if necessary, depending on the number of levels. However, you need to start always at a top-level object.

If the object is a top-level object the ‘SubLevelObject’ reference may be omitted.

The best way to give more insight into the way this works in practise is by giving a simple example. Say you want to refer to the valuation of a value-object with the name “x” (the value-object being the object and the valuation being the object’s attribute.). You could write a simple formula that would look like this:

‘Y=e3{ValueObject(“X”).valuation}’

Reserved formula names

A small number of formulas have been reserved for e3-value specific purposes:

• “COUNT”

• “FRACTION”

• “OCCURRENCES”

• “VALUATION”

• “NORM_VALUE”

If you use the names listed above as formula names (within the corresponding scope), your formulas will be used as if they were a corresponding e3-value attribute. For example,



Page

227

adding a formula named “OCCURRENCES” to a start stimulus will result in that formula being used to calculate the value of the occurrences attribute of that start stimulus.

For a full list of these names, including their respective descriptions, please refer to section 11.3

Formula limitations

Currently the e3-value tool does not support formulas containing unary operators (e.g. the ‘minus’ symbol in the expression ‘-1’). This functionality will be added in future versions of the tool. For more detailed information please refer to section 11.5

7.1.12 Step 10. Saving your business model

Finally, do not forget to save the business model. Press the ‘save’ button in the menu bar or press CTRL-S. Thus a save dialog pops up if you are saving the diagram for the first time otherwise it will save to the same file you have chosen before. In all circumstances you should save your diagram to the xsvg format, which allows you to reload the diagram in exactly the same state. Besides you might consider saving to the jpg or svg formats which gives you a graphical complete but ontological incomplete representation of your model. Exporting to the RDF format gives an ontological complete but graphical incomplete representation and finally exporting to the xls format gives a financial representation of the business model. These last two formats will be discussed later on in detail.



Page

228

7.2 How to create profitability sheets with the e3-value editor

7.2.1 Introduction

One of the main objectives of the tool is to produce profitability sheets to assess the viability of the business model. These sheets will be in the spreadsheet format .xls of Microsoft Excel. In this spreadsheet tool the sheets can be loaded, financial parameters can be changed and the financial outcomes of the business model can be inspected or processed further.

7.2.2 Profitability sheet generation

After you have created and saved you business model the e3-value tool can generate the profitability sheets.

In this paragraph, we show you a step-by-step demonstration on how to generate profitability sheets using the e3-value tool, and we will briefly discuss the structure of the profitability sheets produced in the form of Excel ’98 documents.

Step 1.Assuming that you have started the e3-value tool and loaded a correctly modelled e3-value business model, the first step is to open a ‘save as’ dialog. Select ‘save as’ from the ‘File menu’.

Step 2.Select ‘Microsoft Excel export only’ from the ‘Files of type’ drop-down box:



Page

229

Figure 99 Save as dialog - export profitability sheets

Step 3.Using the ‘save as’ dialog, browse to the directory in which you want to store the profitability sheets, and enter a file name in the ‘File name’ text field. (Note: the filename should end with ‘.xls’). Then click ‘Save’.

Step 4. User information dialogs.

During profitability sheet generation, the e3-value tool may display a number of information dialogs (depending on the model).

“Merged concepts” dialog. - If your model contains two or more graphical objects that conceptually represent the same object, a ‘merged objects’ dialog will be displayed, showing a list of graphical objects that have been merged for the profitability sheet generation. For more specific information please refer to the section ‘Merging instances’.



Page

230

Figure 100 Merged concepts dialog example

This dialog will only be displayed if there is relevant information to show – e.g. if your model does not contain any objects that need to be merged this dialog will not be displayed.

“Error message” dialog. - At this point, it is possible that you are notified of an error in the generation process through an error message dialog:

Figure 101 Error message dialog example

When generating the profitability sheets, the e3-value tool checks your model against a number of rules. If it detects any conflicts or errors in the model, it will notify the user by displaying a specific error message.

If this dialog appears, you should fix the model (see section 11.2 ‘Error Messages’ for more detailed information on specific error messages) and repeat Step 1.



Page

231

“Unseen objects” dialog. – This dialog displays a list of object instances that have not been ‘seen’ during generation, meaning that the object is not involved in any scenario paths.

Figure 102 “Unseen objects” dialog example

If an object appears in this dialog it is possible (but not necessary) that the model is flawed, or that it contains object that have no real purpose. If this dialog appears, you are advised to check the model for errors.

Step 6. The spreadsheet has been created and saved. The .xls file can be opened and viewed in Microsoft Excel (’98 or later).

7.2.3 Profitability sheet document structure

In this paragraph we will discuss the general structure and layout of the profitability sheets generated by the e3-value tool. Please note that this structure may change slightly with the release of future versions of the tool. The Excel documents generated by the e3-value tool can be divided into three sections, each section consisting of one or more.

• Formula sheet • Model concept sheets • Actor / Value Activity / Market Segment sheets

Each of these sections will be discussed individually. Formula sheet This is a single Excel sheet that contains a list of all object instances and their respective attributes and formulas that are in the model. The formula sheet is purely used as a storage place for attributes and formulas. Model concept sheets A separate sheet is created for each e3-value class (e.g. ‘value interface’) of which instances exist in the model. Each of these sheets contains an overview of all instances of its particular class, and of course the respective attributes and formulas for each of these instances.



Page

232

Actor / Value Activity / Market Segment sheets A separate sheet is created for each instance of the following classes:

• Elementary actor • Composite actor • Market Segment • Value Activity

The sheet-layout is the same for all four types of sheets.

Figure 103 Actor-sheet example

The sheets are structured as follows:

• Column A – List of value interfaces for this actor.

• Column B – Value ports for each interface (total for this value interface is shown at the top).

• Column C – Value exchanges for each value port

• Column D – Number of occurrences for each port / exchange-combination.

• Column E – The corresponding valuation function.

• Column F – Economic value (valuation multiplied by the number of occurrences).

Each sheet contains an overview of the occurrences, valuation, and economic value of its corresponding object instance. These values are grouped per value interface (column A in the example) and aggregated at the bottom of the sheet (Row 9 in the example)

Note: In case a value port offers or requests a value object with the name ‘MONEY’ the number of occurrences, valuation function and economic value fields will appear for each combination of value ports and value exchanges. (Because the valuation function might be different for each individual combination)



Page

233

If a value port offers or requests a value object of a type other than ‘MONEY’, only one row will appear in the spreadsheet, displaying the number occurrences, valuation function and economic value for that port and ‘all it’s connected’ value exchanges (Because the same valuation applies to all port/exchange-combinations if the value object is not ‘MONEY’).

More information regarding tips, tricks and error messages can be found in Appendix K (E3-value editor: tips, tricks and error messages). A more technical reference (including details for programmers) can be found in Appendix J (E3-value editor technical reference) and Appendix L (E3-value editor: appendix for the programmer).



Page

234

Appendix A Goal hierarchy spreadsheet

Legend

M Market development goal E Environmental goal QE Quality and efficiency goal

Note

The information in tables in Appendix A covers only goals that were present in the scenarios in deliverables D2.1 and D2.2.

A.1. Strategic goals.

Goal hierarchy Type Apply Stakeholder

Market development M

S1.1 Enter new business M

S1.2 Increase market share M

S1

S1.3 Long-term sustainable development M

S1.4 Minimize costs of infrastructure investments M

S1.5 Smoothen the electricity price fluctuations M

… Other market development goal(s) M

Environmental goals E

S2.1 Reduce environmental emissions E

S2

S2.2 Reduce use of primary fuel/dependence on primary fuel

E

S2.3 Promote use of renewable energy E

S2.4 Maximize output of DG environmental benefits E

… Other environmental goal (s) E

S3. Quality and efficiency QE

S3.1 To improve security of supply QE

S3.2 Provide energy storage QE

… Other quality and efficiency goal(s) QE



Page

235

A.2. Operational goals.

Goal hierarchy Type Value Activity Apply Stakeholder O1. Make profit M G. Generate electricity G1 Increase generation efficiency M G2 Benefit from generating subsidized RES electricity E G3 Reduce emissions of generation E … Other goal(s)

Generation

S. Supply electricity S1 Sell reserved electricity in peaking hours M S2 Benefit from green electricity incentives E S3 Avoid purchases in peaking hours M S4 Sell electricity on power market M … Other goal(s)

Supply

D. Transmit/Distribute electricity

Reduce expenses M D1.1 Reduce investments expenses M

D1

D1.2 Reduce operational expenses M Improve distribution service quality QE

D2.1 To reduce the need for peak reserved capacity QE

D2.2 Subcontract producer to avoid grid upgrade QE

D2

D2.3 Reduce network losses QE … Other goal(s)

Transmission Distribution

T. Trade electricity M … Other goal(s)

Trade

ES. Supply DG equipment ES1 Increase utilization of DG M

ES1.1 Increase sales RES generators E ES1.2 Increase sales New efficient technologies QE

ES1.3 Increase sales of ICT equipment for managing DG QE

… Other goal(s)

Manufacturing

EL. Lease DG equipment M EL1 Lease RES E EL2 Lease New generators QE … Other goal(s)

Leasing

O2. Efficient system functioning QE

NM. Provide network management services QE Network Management

Provide ancillary services for transformation grid QE

NM1.1 Provide voltage control QE NM1.2 Provide frequency control QE

NM1

NM1.3 Provide black start (?) QE … Other goal(s)

Transmission

Provide active management QE Distribution Transmission

NM2

NM2.1 Provide demand side management (DSM) QE Balancing



Page

236

Goal hierarchy Type Value Activity Apply Stakeholder NM2.2 Provide supply side management (SSM) QE Balancing NM2.3 Provide balancing services M Balancing

… Other goal(s) A. Represent groups of customers/suppliers/generators M Aggregation EE. Provide Energy efficiency QE

EE1 Provide on-site load management (LM) services (passive measures) QE

EE2 Provide other energy efficiency services for customers QE

Energy efficiency

M. Provide metering services M Metering

MM. Provide market management services QE Market Management

O3. Efficient market functioning R. Guarantee a fair operation of the system R1 Oblige distribution companies to connect RES E R2 Oblige distribution companies to connect DG M R3 Oblige suppliers to accept RES E R4 Oblige MO to give priority to RES E … Other laws and obligations

Regulation

K. Fulfil Kyoto obligations E K1 Investments subsidies E K2 Develop RES promotion schemes E K2.1 Tax exemption (Netherlands, Spain) E K2.2 Premiums system (Spain) E K3 Organize “green” market E K3.1 ROC certificate market E … Other goal(s)

Regulation Policy making

O4. Consume electricity C. Reduce costs M C1 Reduce consumption in peaking hours QE

C2 Efficient use of heat QE, M

C3 Avoid transmission and distribution costs M

C4

Perform on-site generation activity M

C5 Use energy efficiency services QE

Consumption

… Other goal(s) Q. Improve electricity service quality QE

Q1 Provide power in remote/isolated area QE

Q2 Provide back-up power within short timeframe QE

Q3 Provide back-up power with continuous output QE

Q4 Provide continuous reliable power QE

… Other goal(s)

Consumption



Page

237

Appendix B Goal-Technology checklist

Legend

✦ Important characteristic ✧ Moderately Important/ Important in certain applications

. Relatively Unimportant (field may be left empty)

For calculating the total score column, use the following scoring system:

✦ 2 points ✧ 1 point . 0 points

Note

The information in tables in Appendix B covers only goal-technology relations that were present in the scenarios in deliverables D2.1 and D2.2.

B.1 Strategic goals


Hig

h E

ffici

ency

Low

CO

2 E

mis

sion

s

Qui

ck S

tart

-up

Tim

e

Hig

h P

redi

ctab

ility

The

rmal

Out

put

Cap

acity

con

stra

ints

Grid

con

nect

ion

Low

Cap

ital E

xpen

ses

Low

Fix

ed E

xpen

ses

Low

Var

iabl

e E

xpen

ses

To

tal

Goal: Strategic development

Market development . . . . . . . ✦ ✦ 4

S1.1 Enter new business ✦ . . . . . . ✧ ✧ 4

S1.2 Increase market share . . . . . . . ✧ ✧ 2

S1.3 Long-term sustainable development ✧ ✧ . . . . . .

. 2

S1.4 Minimize costs of infrastructure investments . . . . . ✧ . ✧ ✧ 3

S1

S1.5 Smoothen the electricity price fluctuations . . . . . . . . .

…

Other market development goal(s)

Environmental goals . ✦ . . . . . . . 2

S2.1 Reduce environmental emissions . ✦ . . . . . . . 2

S2.2 Reduce use of primary fuel/dependence on primary fuel . ✦ . . . . . .

. 2

S2

S2.3 Promote use of renewable energy . ✦ . . . . . . . 2



Page

238


Hig

h E

ffici

ency

Low

CO

2 E

mis

sion

s

Qui

ck S

tart

-up

Tim

e

Hig

h P

redi

ctab

ility

The

rmal

Out

put

Cap

acity

con

stra

ints

Grid

con

nect

ion

Low

Cap

ital E

xpen

ses

Low

Fix

ed E

xpen

ses

Low

Var

iabl

e E

xpen

ses

To

tal

S2.4 Maximize output of DG environmental benefits . ✦ . . . . . .

. 2

… Other environmental goal (s)

Quality and efficiency ✦ . ✦ ✦ . . . . ✧ 7

S3.1 To improve security of supply ✦ . . ✦ . . . . . 4

S3.2 Provide energy storage . . . . ✦ ✦ ✦ . . 6

S3

… Other quality and efficiency goal(s) . . . . . . . . . Total 7 11 2 4 2 3 2 5 3 3

B.2 Operational goals

Goal hierarchy for Operational goals

Hig

h E

ffici

ency

Low

Em

issi

ons

Qui

ck S

tart

-up

Tim

e

Hig

h P

redi

ctab

ility

The

rmal

Out

put

Cap

acity

con

stra

ints

Grid

con

nect

ion

Low

Cap

ital E

xpen

ses

Low

Fix

ed E

xpen

ses

Low

Var

iabl

e E

xpen

ses

To

tal s

core

O1. Make profit

G. Generate electricity G1 Increase generation efficiency ✦ . . . . . . . ✦ G2 Benefit from generating subsidized RES

electricity ✧ ✦ . . . ✦ . . ✧

G3 Reduce emissions of generation . ✦ . . . . . . . … Other goal(s) S. Supply electricity

S1 Sell reserved electricity in peaking hours ✧ . ✦ ✦ ✧ ✦ ✦ . ✦

S2 Benefit from green electricity incentives ✧ ✦ . . . . . . . S3 Avoid purchases in peaking hours . . . . . . . . . … Other goal(s)

D. Transmit/ Distribute electricity

Reduce expenses . . . . . . . ✦ ✦ D1.1 Reduce investments expenses . . . . . . . ✦ ✧

D1

D1.2 Reduce operational expenses . . . . . . . ✧ ✦ Improve transmission/distribution service quality

D2.1 To reduce the need for peak reserved capacity . . ✦ . . ✦ ✦ ✦

✦

D2

D2.2 Subcontract producer to avoid grid upgrade

✦ . ✦ . ✦ . ✦ ✧



Page

239


Hig

h E

ffici

ency

Low

Em

issi

ons

Qui

ck S

tart

-up

Tim

e

Hig

h P

redi

ctab

ility

The

rmal

Out

put

Cap

acity

con

stra

ints

Grid

con

nect

ion

Low

Cap

ital E

xpen

ses

Low

Fix

ed E

xpen

ses

Low

Var

iabl

e E

xpen

ses

To

tal s

core

D2.3 Reduce network losses . . ✦ . . . . . . … Other goal(s) ✦ ✧ . . . ✦ ✦ ✧ ✧ T. Trade electricity … Other goal(s) ES. Supply DG equipment ES1 Increase utilization of DG ES1 ✧ ✧ ✧

ES1.1 Increase sales RES generators

✦ ✧ ✧

ES1.2 Increase sales of new efficient technologies

✦ ✧ ✧

ES1.3 Increase sales of ICT equipment for managing DG ✦

… Other goal(s) EL. Lease DG equipment EL1 Lease RES ✧ ✦ ✧ ✧ EL2 Lease New generators ✦ ✧ ✧ ✧ … Other goal(s)

O1-1. Efficient system functioning

NM. Provide network management services NM1 Provide ancillary services for

transformation grid ✦ ✦ ✦ ✦

NM1.1 Provide voltage control ✦ ✦ ✦ ✦ NM1.2 Provide frequency control ✦ ✦ ✦ ✦ NM1.3 Provide black start (?) ✦ ✦ ✦ ✦ … Other goal(s)

Provide active management of distribution grid ✦ ✦ ✦

NM2.1 Provide DSM ✦ ✦ ✦ ✦ ✧ NM2.2 Provide SSM ✦ ✦ ✦ ✦ ✧

NM2

NM2.3 Provide balancing services ✦ ✦ ✦ ✦ ✧ … Other goal(s) A. Represent groups of customers/suppliers/generators ✧

EE. Provide Energy efficiency

EE1 Provide on-site load management (LM) services (passive measures)

✧ ✧ ✦ ✦ ✧

EE2 Provide other energy efficiency services for customers

✧

M. Provide metering services ✦ ✦ ✦ ✦ ✦

MM. provide market management

O2. Efficient market functioning

R. Guarantee a fair operation of the system



Page

240


Hig

h E

ffici

ency

Low

Em

issi

ons

Qui

ck S

tart

-up

Tim

e

Hig

h P

redi

ctab

ility

The

rmal

Out

put

Cap

acity

con

stra

ints

Grid

con

nect

ion

Low

Cap

ital E

xpen

ses

Low

Fix

ed E

xpen

ses

Low

Var

iabl

e E

xpen

ses

To

tal s

core


✧ ✦ ✧ ✦ ✧ ✧

R2 Oblige distribution companies to connect DG

✦ ✧ ✧ ✦ ✧ ✧

R3 Oblige suppliers to accept RES ✦ ✧ R4 Oblige MO to give priority to RES ✦ ✧ … Other laws and obligations ✧ ✧ ✧ K. Fulfil Kyoto obligations

K1 Investments subsidies ✦ ✦ K2 Develop RES promotion schemes ✦ ✦

K2.1 Tax exemption (Netherlands, Spain) ✦ ✦

K2.2 Premiums system (Spain) ✦ ✦ K3 Organize “green” market K3.1 ROC certificate market … Other goal(s) ✦ ✦

O2. Consume electricity C. Reduce costs

C1 Reduce consumption in peaking hours ✦ ✧ ✦

C2 Efficient use of heat ✦ ✦

C3 Avoid transmission and distribution costs

✦ ✦ ✧ ✧

C4

Perform on-site generation activity ✦ ✧ ✦

C5 Use energy efficiency services ✦ ✦ ✦ ✦

… Other goal(s)

Q. Improve electricity service quality

Q1 Provide power in remote/isolated area ✦ ✦ ✧ ✦

Q2 Provide back-up power within short timeframe

✦ ✦ ✦

Q3 Provide back-up power with continuous output

✦ ✦ ✦ ✦

Q4 Provide continuous reliable power ✦ ✦ ✧ ✧

… Other goal(s)

Total: .. .. .. .. .. .. .. .. .. .. ..



Page

241

Appendix C Some technologies and their characteristics

Technology

Effi

cien

cy

CO

2 E

mis

sion

s

Sta

rt-u

p T

ime

The

rmal

Out

put

Tot

al E

xpen

ses

O&

M F

ixed

E

xpen

ses

O&

M V

aria

ble

Exp

ense

s P

redi

ctab

ility

Not renewable

Reciprocating engines

High

Very High

Very quick

Yes

Low

High

Low

High

Microturbines Good

High

Quick

Yes

Low

Low

Low

High

Fuel cells Good

Low

Quick –Slow

Yes

High

Low

High

High

Renewable

Wind turbines Null - No High Low High Low Solar Null - No High Low Low Low Micro hydro Low High Biomass Low High


Low High

Waste reduction Low High



Page

242

Appendix D Goal-conflict matrix

Legend

++

Goals which enhances each other

0 Goals which do not enhance nor give a conflict with each other

-- Goals which give a serious conflict with each other

Note

This goal-conflict matrix is only an example of how the table should look like. This table is not complete and should contain both the strategic and tactical goals. The goals in this table should be revised, changed or deleted from the selected goals list.

Goal conflict matrix for Strategic goals

S1.

1

S1.

2

S1.

3


S1.1 Enter the heat business ++ --

S1

S1.2 Increase market share ++ +

S1.3

Reduce the use of CHP to make other renewable profitable -- +



Page

243

Appendix E Value Interface Library

This appendix provides the value interface library. For each activity defined in chapter 4, this value interface library provides general and optional interfaces. This library can be used while selecting and connecting value interfaces in step 5 and 6 of the methodology.

For each value interface, a matrix like

Figure 104 is presented. This matrix represents the activities with which the value interface will possibly connect. In this figure, the value interface will only connect with another value interface from distribution or supply.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. M

ngm

t.G

ener

atio

nT

rans

mis

sion

Dis

trib

utio

nS

uppl

yC

onsu

mpt

ion

Man

ufac

turin

gLe

asin

gG

rid B

alan

cing

Ene

rgy

Eff.

Agg

rega

tion

Met

erin

gM

arke

t Mng

mt.

Figure 104. Matrix of possible connections.



Page

244

1. Electric System RegulationActivity:

General interface(s)

economic & ecological benefitsregulationElectric System Regulation is enforced by law to provide regulationto one or more activities. This is done to obtain economic andecological benefits for the regulating party, the system and/or thesociety.

Multiple instances of this interface can be used.

Value in:Value out:Description:

1.1

regulationeconomic &ecologicalbenefits

Optional interface(s)R

egul

atio

nP

olic

y M

akin

gT

rade

Net

w. M

ngm

t.G

ener

atio

nT

rans

mis

sion

Dis

trib

utio

nS

uppl

yC

onsu

mpt

ion

Man

ufac

turin

gLe

asin

gG

rid B

alan

cing

Ene

rgy

Eff.

Agg

rega

tion

Met

erin

gM

arke

t Mng

mt.

Possible connections with:

ecological benefitssubsidyElectric System Regulation may provide subsidy to stimulateenvironment-friendly behaviour. In exchange for these ecologicalbenefits they provide subsidy.



1.2

subsidyecologicalbenefits


fullfilmentregulationIn some cases Electric System Regulation prohibits or obligescertain behavior, without having explicit benefits in return for it. Inthis case fullfilment is returned.



1.3

regulation fullfilment


Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

245

2. Policy MakingActivity:


acceptancepoliciesBy providing policies, the policy making party is able to stimulate orimpose specific behavior to other parties. Acceptance of thesepolicies is expected in return, because the are enforced by law.



2.1

Optional interface(s)

policies acceptance


Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

246

3. TradeActivity:


electricityfeeTrade buys electricity from generation. They pay a electricity fee forit, based on the current market price.


3.1


economic &ecologicbenefits

regulationeconomic & ecologic benefitsIf Electric System Regulation is done in the model, a valueinterface like this should be modeled. Regulation is received,obligated by law, and economic and/or ecologic benefits areprovided to the regulating party.


regulation

3.3

feeelectricity

fee electricity

3.2 feeelectricityThe electricity (bought from generation) is resold. An electricity feeis paid for it, based on the current market price.





Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Market management servicesmarket management feeIf the activity uses market management services, they have to payfor that


3.4

marketmanagement

services

marketmanagement

fee Possible connections with:

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

247

4. Network ManagementActivity:


Network management feenetwork managementNetwork management provides network management. The expecta network management fee in return.


4.1



regulationeconomic & ecologic benefitsIf Electric System Regulation is done in the model, a valueinterface like this can be modeled. Regulation is received, obligatedby law, and economic and/or ecologic benefits are provided to theregulating party.


regulation

4.2

networkmanagement

fee

networkmanagement Possible connections with:


Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

248

5. GenerationActivity:


electricity fee

feeelectricityGeneration generates electricity, providing this to another party, inexchange for a fee.


5.1

fee

equipmentfeeIn some cases you want to model the purchase of equipmentneeded for the generation of electricity. In that case equipment forthe generation of electricity is exchanged for a fee, the (retail)priceof the equipment.


5.3


equipment




regulation

5.2

fee

use of equipmentfeeIn some cases, you want to model the lease of equipment neededfor the generation of electricity. In that case the use of equipment(leasing) is exchanged for a fee as mentioned in the lease contract.


5.4

use of equipment





Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

5.5 See value interface 3.4



Page

249

6. TransmissionActivity:


transmission fee

feetransmissionTransmission provides transmission in exchange for a fee.


6.1

fee

network managementfeeFor the proper functioning of the transmission network, somenetwork management needs to be done. So network managementis required in exchange for a fee.


6.2


networkmanagement




regulation

6.3




Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

250

7. DistributionActivity:


T&Dservices

fee

feetransmission and distribution servicesDistribution offers transmission and distribution services and get afee in return.


7.1

fee

feetransmission servicesIn many cases, distribution needs transmission to distribute theelectricity. In this value interface transmission is acquired for acertain fee.


7.2


transmissionservices




regulation

7.3




Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

251

8. SupplyActivity:


electricityelectricity

retailfee

Electricity retail feeelectricitySupply offers electricity to final customers. In return they ask aelectricity retail price, a fee for electricity, distribution and services.


8.2





regulation

8.4

electricityelectricityfee

electricityelectricity feeBefore supply can supply electricity, they need to buy electricity(f.e. from market management or directly from generation). Inexchange they offer an electricity price.


8.1

T&Dfee

T&Dservices

transmission and distribution servicestransmission and distribution feeTo bring the electricity to the final customer, transmission anddistribution is needed. Supply offers a T&D fee for these services.


8.3





Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

8.5 See value interface 3.4



Page

252

9. ConsumptionActivity:


% energysavings

energy efficiency servicespercentage of accomplished energy savingsIn some cases, a energy efficiency services providing actorprovides the consuming party with services to save on energycosts. They expect a percentage of these energy savings in return.


9.2


energyefficiencyservices




regulation

9.3

electricityelectricity

retailfee

electricityelectricity retail feeFor their daily functioning, consumers need electricity. Electricity isexchanged for an electricity retail price, including electricity,distribution and services.


9.1




Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

253

10. ManufacturingActivity:


equipment fee

feeequipmentManufacturing provides equipment for the generation of electricityto producers. They ask a fee (the retail price) in return.


10.1



Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

254

11. LeasingActivity:


use ofequipment

fee

feeuse of equipmentLeasing offers the right to use equipment needed for the generationof electricity to producers. They ask a fee in return, as agreed in thelease contract


11.1



Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

255

12. BalancingActivity:


feespecific

generation pattern

specific generation patternfeeTo be able to deliver balancing services, supply-side managementis done: the balancing pays a fee for a possibility to receive aspecific generation pattern from generation activity


12.1

balancingservice

feebalancing serviceBecause balancing is able to balance the supply and demand, theycan provide balancing services, and ask a fee for it.


12.3


fee




regulation

12.4




feespecific

consumption pattern

specific consumption patternfeeTo be able to deliver balancing services, demand-sidemanagement is done: the balancing pays a fee for a possibility toreceive a specific consumption pattern from customers, which canbe represented by suppliers, aggregators, etc.


12.2


Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

256

13. Energy EfficiencyActivity:



% energysavings

percentage of accomplished energy savingsenergy efficiency servicesEnergy efficiency provides services and/or equipment to finalcustomers to reduce the cost of energy. In return they ask apercentage of the accomplished energy savings.


13.1

energyefficiencyservices


Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

257

14. AggregationActivity:


benefitsnon-aggregated

needs

non-aggregated needs and a fee (optional)benefitsAggregation combines the needs of multiple relatively ‘small’parties into a bigger one. This improves the position of theaggregator, so it can negotiate better conditions. These benefits areredirected to the ‘small parties.


14.1

aggregatedneeds

benefitsaggregated needsThe aggregated needs are used to negotiated better conditions(benefits) with the supplier of these needs.


14.2


benefits


Possible connections with:R

egul

atio

nP

olic

y M

akin

gT

rade

Net

w. M

ngm

t.G

ener

atio

nT

rans

mis

sion

Dis

trib

utio

nS

uppl

yC

onsu

mpt

ion

Man

ufac

turin

gLe

asin

gG

rid B

alan

cing

Ene

rgy

Eff.

Agg

rega

tion

Met

erin

gM

arke

t Mng

mt.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

258

15. MeteringActivity:


meteringservices fee

feemetering servicesMetering offers metering services to another party. Most usualconstruction is that the party responsible for metering outsourcesthis activity to a metering actor. A fee for the metering service isasked in return.


15.1





regulation

15.2



Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

259

16. Fuel SupplyActivity:


fuel fee

feefuelFuel Supply offers fuel to another party (a producing actor) andexpects a fee in return


16.1





regulation

16.2



Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

260

17. Heat SupplyActivity:


heat fee

feeheatHeat Supply supplies heat to a consuming party, for the heating ofbuildings and/or water.


17.1





regulation

17.2



Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

261

18. Market ManagementActivity:


Market management feemarket management servicesMarket management provides market management services. Theyexpect a market management fee in return.


18.1





regulation

18.2

marketmanagement

fee

marketmanagement

servicesPossible connections with:


Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.

Reg

ulat

ion

Pol

icy

Mak

ing

Tra

deN

etw

. Mng

mt.

Gen

erat

ion

Tra

nsm

issi

onD

istr

ibut

ion

Sup

ply

Con

sum

ptio

nM

anuf

actu

ring

Leas

ing

Grid

Bal

anci

ngE

nerg

y E

ff.A

ggre

gatio

nM

eter

ing

Mar

ket M

ngm

t.



Page

262

Appendix F Goal-Activity-Value Interface Template

Interface Goal Number Goal Name Activity

Value In Value Out



Page

263

Appendix G Structure of a profitability sheet of an actor

Actor X1

Viewpoint value viewpoint

Scenario A1

Occurrences/timeframe

…

Value Object In Value Object Out

Scenario path 1

Likelihood …%

Euro x1 Euro y1

… …

Scenario path m

Probability …%

Euro xn Euro yn

Scenario …

Scenario Ai



Page

264

Appendix H Actors and Activities matrix in the Electrical System

D 5.1 D


usiness Modelling

EE

SD

Project N

NE

5/2001/256 BU

SM

OD

BU

SM

OD

: Business M

odels in a World C


eneration

Page

265

Tab

le 22. Acto

rs and

Activities m

atrix in th

e Electrical S

ystem.

R

Regulated M

ain Actor

M

Main actor

O

Optional actor


Policy Maker

Market Operator




Producer

Final Customer

Supplier

Utility


Manufacturer

Lease Company

Autoproducer


Green Producer


Retailer

Marketer

Broker

Retail Shop

Aggregator

Buying Pool


Balance group

Metering company

Fuel Supplier

Heat Supplier


Electric S

ystem R

egulation R

Policy m

aking

R

Trade

M

O

O

O

O

O

Generation

M

O

O

O

O

O

O

Transm

ission

R

O

Netw

ork managem

ent

O

R

O

Distribution

R

O

Supply

M

O

O

O

O

O

O

O

O

O

D 5.1 D


usiness Modelling

EE

SD

Project N

NE

5/2001/256 BU

SM

OD

BU

SM

OD

: Business M

odels in a World C


eneration

Page

266


Policy Maker

Market Operator




Producer

Final Customer

Supplier

Utility


Manufacturer

Lease Company

Autoproducer


Green Producer


Retailer

Marketer

Broker

Retail Shop

Aggregator

Buying Pool


Balance group

Metering company

Fuel Supplier

Heat Supplier


Consum

ption

M

O

O

O

O

Manufacturing

O

M

O

Leasing

O

O

O

O

M

O

Balancing

O

O

O

O

O

O

O

O

O

M

Energy E

fficiency

M

Aggregation

O

O

O

O

O

M

O

O

Metering

M

O

O

O

O

O

O

O

O

O

O

Fuel S

upply

O

M

Heat S

upply

O

O

O

O

O

M

Market M

anagement

R



Page

267

Appendix I Installation of the e3-value editor

Three steps are needed to run the tool:

• Ensure the Java Runtime Environment version 1.4.2 or later is installed.

• Get E3Current.jar on your system.

• Run the command Java –jar E3Current.jar

How to accomplish this in Windows 98, ME, NT, 2000 or XP will be explained next.

To check the JRE is properly installed open the Windows Start Menu and choose the run option. Give the command “cmd” and a command box will open. In this command box give the command “Java –version” and the version number of your JRE if any is displayed.

Figure 105. Test if a recent version of the Java Runtime Environment is installed.

If this test fails, you have to visit: http://Java.sun.com/j2se/1.4.2/download.html and follow the instructions.

To download your copy of E3Current.jar visit: http://www.cs.vu.nl/~gordijn/research.htm and press the here link at the top.

Finally, you click on the jar file that you just downloaded and the tool will start otherwise



Page

268

open a command box as before and issue the command

“Java –jar yourpath\E3Current.jar” as in the figure below.

Figure 106 starting the tool from the console

Once you have started the tool the 'About' button display some information about the settings. Important is the version number. Every time you download a new version, you are advised to keep a copy of the old version, as there is no guarantee the business models you created before can be loaded in a newer version.

Figure 107. The “about”-button reveals the version and other important settings.



Page

269

Appendix J E3-value editor technical reference

In this appendix we will describe the process of generating various outputs from the (graphical) business models created by the user.

10.1 RDF generation steps

In this section, we will describe the process of generating an RDF representation from the diagrams, which are drawn in the JGo environment by the user.

In order to be able to represent diagrams in the RDF format we use a set of Java classes, which mirror the e3-value ontology. These classes (found in the ‘www.cs.vu.nl.gordijn.e3value.ontology’ package) were first generated from the original RDFS schema using the RDF2Java tool. The process of exporting diagrams comes down to mirroring the instances of objects created by the user (using the editor GUI) as instances of the ‘RDF’ classes. It can be broken down to the following steps.

1. Create instances of the ‘RDF’-classes for each relevant model concept in the diagram. 2. Assign attributes (including references to other instances) to each of these newly

created instances.

Each of these steps is discussed in its corresponding paragraphs below.

10.1.1 Create instances

In this paragraph, we will discuss the process of instantiating objects of the ‘RDF2Java’ classes that will be used to generate RDF files later on.

10.1.1.1 Simple mapping

The first step in the process of generating the RDF is to instantiate an ‘RDF2Java’ counterpart for every single instance that exists in the JGo (user interface) world. In addition, there are model concepts that are not explicitly represented in the user interface that we do want to include in the final RDF representation (namely ‘value offerings’). These will also be instantiated. We start by iterating the ‘JGo’ instances in the diagram.

For each instance we determine the class type, which is mapped to its corresponding ‘RDF’ class. A new instance of the corresponding ‘RDF’ class is created18.

18 in some cases model concepts are merged, in which case there are a number of exceptions regarding instantiation of the respective classes. Please refer to the paragraph ‘merging instances’ for more information.



Page

270

If the model concept’s class type is that of ‘value_interface’, two additional instances of the ‘RDF’ class ‘value_offering’ will be created 2, one for each of the value interface’s implicit value offerings.

All newly created instances are stored in a HashMap where the key is a string containing the unique ID from the ‘JGo’ instance, and the corresponding value is a reference to the ‘RDF’ instance. This is done so we can look the instances up later on.

10.1.1.2 Merging objects

Besides the straight-forward mapping of ‘JGo’ instances to ‘RDF2Java’ instances where one ‘JGo’ instance corresponds with one ‘RDF2Java’ counterpart, there may also be cases where the user creates two (or more) objects which conceptually represent the same model concept, but are practically two different instances in the ‘JGo’ world. For example:

Figure 108 Object-merging: Two graphical objects may conceptually be identical.

In the example (Figure 108) you can see that it is possible to use the user interface to model the same model concept more than once. Obviously, when exporting to RDF, we would want to see each model concept represented only once. This means we need some mechanism to detect ‘JGo’ objects that represent the same model concept, and merge them (if possible) into one ‘RDF’ instance.

This mechanism is implemented during the process of instantiating the ‘RDF’ model concepts. See below for a step-by-step guide to the way this mechanism works:

1. For each ‘JGo’ instance j: a. Check whether we have already created one or more ‘RDF’ instance r where

(r.name = j.name AND NOT r.name = “”)

AND (r.class matches 19 j.class)

19 Note: By matching the class types, we mean that both class types should correspond to each other, NOT that they should be of the exact same type. For example, a ‘JGo’ instance of class “E3tor_value_exchange” would be considered to match any ‘RDF’ instance of class ‘value exchange’ because they represent the same type of model concept.



Page

271

If false, proceed to step 3, otherwise proceed to 1b.

b. for each r, check whether it is allowed to merge with j based on a set of rules20. If false: abort export process and throw an error message.

2. Instead of making a new ‘RDF’ instance to mirror j, make a new entry in the HashMap where the key is a string containing the unique ID from instance j, but the value is a reference to instance r.

3. Create a new ‘RDF’ instance and proceed as usual.

If the ‘RDF’ instance for a certain model concept needs to be ‘merged’ with another concept, and no conflicts are detected, we will add a new entry to the HashMap, but instead of creating a new instance, we add a reference to the existing instance. Effectively the instances are now ‘merged’. The reason the duplicate pointers are added in the table is because later on, when assigning attributes to the instances, we will need to be able to look up which instance represents which model concept.

10.1.1.3 Rules for merging model concepts

When two ‘JGo’ objects are considered for merger, there is a number of constraints to be considered.

1. Both objects must have the same name (excluding “” – empty string) 2. Both objects must be of a same class type. 3. Both objects should be in the same scope.

The scopes of both objects should be equal, but can depend on the class type. For example: For some classes it may be sufficient if both instances are in the global scope (which is always true per definition).

If one or more of these criteria are not met, the two model concepts will simply not be merged. A new instance will be created for each of them. If they are met, another number of criteria is evaluated. While these criteria are specific for each class type, they can be divided into two categories.

1. The collections of formulas of both objects must be merge-able – if two objects have one or more formulas with the same name (header), the formulas’ bodies must be equal.

2. The attributes of both objects should be equal. This includes fractions, but also references to other objects (in which case both the name and class type should be equal).

20 See section: ‘rules for merging model concepts’ (section 10.1.1.3)

‘RDF’ instance

#1 Reference to actor_a

#2 Reference to value_exchange_toB

#3 Reference to actor_a

Figure 109 - some merged instances in a Map



Page

272

A specific list of criteria (per class):

Market Segment Merge if the same name is used by any other MS and formulas are merge-able.

Actor Merge if: same name is used by another Actor and both Actors' parents must

((Be null, or have the same name, or be of the same class)) and (parent must be of class el_ac, comp_ac, ms, activity) and formulas must be merge-able.

ValueObject Merge if same name is used by any other V.O.

Formulas must be merge-able.

SimpleDependencyElement Merge if same name is used by any other simple D.E. of the same class, both share attributes of the same name and their formulas are merge-able.

ComplexDependencyElement (except ValueInterface)

Merge if same name used by any other D.E. of the same class

ConnectionElement Merge if same name used by any other C.E. if both share the same characteristics - names of the objects in the following fields must be equal: up_de, down_de. In addition, the formulas must be merge-able.

Value Activity in scope A. Merge if same name used by another Activity and both Activities' parents must

((be null or have the same name, and be of the same class)) (Parent must be of class el_ac, comp_ac, ms, activity) and formulas must be merge-able.

Value Activity in scope M.S. Merge if same name used by another Activity and both Activities' parents must ((be null or have the same name, and be of the same class)) (parent must be of class el_ac, comp_ac, ms, activity) And formulas must be merge-able.

Value Offering in scope V.I. Not applicable

Value Port in Scope V.O. Merge if same name used by another V.P. which shares the same parent (of class V.I.) and is equally directed.

Value Exchange in Scope V.P.

Merge if same name used by another V.E. which is connected to the same ports (both in and out)



Page

273

Value Interface Merge if same name used by any other V.I. and formulas are merge-able

Value Transaction Merge if same name used by any other V.T. and formulas are merge-able

If the first three criteria (same name, class type, and scope) are met, but one of more of the criteria in the above list is not, then the export process will be aborted and an error message will be displayed.

10.1.2 Assign attributes

After all ‘RDF instances’ have been created, we assign the correct attributes (and object references) to each instance. This is done by iterating over the collection of all (JGo) objects that exist in the document of the graphical business model.

1. For each ‘JGo’ object instance ‘j’:

a. Look up the corresponding ‘RDF’ object instance ‘r’ from the HashMap. b. Invoke the ‘initialize( E3Object)’ method on object ‘r’, where ‘j’ is passed as

the argument variable – e.g.: ‘r.initialize( j )’ Each of the ‘RDF’ classes has an ‘initialize’ method, which, if invoked, collects all relevant attributes and references of the ‘JGo’ object passed as an argument. Attributes are directly copied and stored in the ‘RDF’ object. References to other ‘JGo’ objects are replaced (with a reference to the corresponding ‘RDF’ object) before they are stored. ‘JGo’ objects that have been ‘merged’ into a single ‘RDF’ counterpart both have their own unique ‘key’ pointers as entries in the HashMap, where each of these are pointing to the same ‘RDF’ instance. This means that the attributes and references of both ‘JGo’ objects will be assigned to the same ‘RDF’ object, effectively merging them.

10.1.3 Generate RDF files / file stream

The actual RDF generation is done by the RDF2Java API, which has a built-in function to generate RDF files directly from the ‘RDF’ object instances we created earlier. It uses the Java reflection API directly serialize and de-serialize Java objects, and produces RDF output which can then be read using various RDF tools / analyzers (e.g. OntoServer).



Page

274

10.2 Profitability sheet generation

10.2.1 Approach

To be able to generate profitability sheets we assume that we have a conceptual representation of the business model in the form of a set of ‘RDF2Java’ objects (instances of the ‘RDF2Java’ classes, which were created by exporting the graphical representation of the business model to RDF: Error! Reference source not found..

10.2.2 Profitability sheet generation steps

Profitability sheet generation takes place through the following steps:

1. Assign the number of occurrences to each value port and each value transaction in the model.

2. Parse all formulas

3. Create a ‘Formula Sheet’ to which we write all formulas (or placeholders) that are present in the model.

4. Assign ‘Default Valuation Formulas’ to each value port

5. Update the Formula sheet with ‘Default Valuation Formulas’

6. Create Excel sheets for each e3-value ontology class

7. Create Excel (profitability) sheets for instance of the Actor, Market Segment, and Value Activity classes.

Each of these steps is discussed below.



Page

275

10.2.3 Assign occurrences to the value ports and the value transactions.

The first step in calculating the economical value of a value port is to determine the number of times its transactions are executed. This is done by taking the number of occurrences assigned to each start stimulus and propagating it across the model through the scenario paths.

Below you will find a highly simplified representation of the algorithm used to propagate the occurrences throughout the business model. The purpose of this paragraph is not to give a fully detailed explanation of the process, but instead to give an impression of the mechanism that is used.

The syntax that was used is an informal mixture of Java syntax and pseudo-code. Some of the method names may not literally correspond to the actual Java code. This was done for readability purposes. The algorithm described below also assumes that the business model is correctly modelled. In reality, of course, it contains code which actually checks the integrity of the model. These parts of the code were however omitted here, for the sake of readability.

Please see the next page for a detailed overview.



Page

276

AssignOccurences{

For each STARTSTIMULUS {

Pathfound = TraverseDependencyElement (STARTSTIMULUS ,STARTSTIMULUS.occurrences)

//the TraverseSimpleDependencyElement method returns a boolean value. If this value is

//false this means that there was no complete scenariopath and no ENDSTIMULUS to

//be found, in which case an error is thrown.

IF NOT Pathfound throw ERROR (“no end stimulus reached”).

}

}

TraverseSimpleDependencyElement(Element, occurences){

//This method takes handles the propagation of occurrences for simple dependency

//elements: STARTSTIMULUS, and ENDSTIMULUS

Returnvalue = FALSE // false by default

IF Element HAS BEEN VISITED throw new ERROR (“loop detected” )

ELSE ELEMENT.setVisited(TRUE);

IF Element ISA STARTSTIMULUS{

NEXTELEMENT = ELEMENT.getNextElement();

IF NEXTELEMENT ISA ANDFORK {

Returnvalue =

TraverseAND (NEXTELEMENT, occurrences, ELEMENT)

}



Page

277

IF NEXTELEMENT ISA ORFORK {

Returnvalue =

TraverseOR (NEXTELEMENT, occurrences)

}

IF NEXTELEMENT ISA SIMPLEDEPENDENCYELEMENT{

Returnvalue =

TraverseSimpleDependencyElement(NEXTELEMENT, occurences)

}

IF NEXTELEMENT ISA VALUEINTERFACE{

Returnvalue =

TraverseValueInterface (NEXTELEMENT, myOccurences, ELEMENT, Null)

}

//Set visited value to be false so the element may be visited again (in the context //of a different scenariopath.

ELEMENT.setVisited(FALSE);

//We are returning the returnvalue of the just executed ‘traverse methods’. This //makes sure that in the event an end stimulus has been found to complete the //scenariopath, it is recursively passed along.

RETURN Returnvalue

}

IF Element ISA ENDSTIMULUS{

Element.SetOccurences(occurrences)

//We are returning the value ‘true’ to signal that the scenariopath

//has been completed

RETURN TRUE;



Page

278

}

}

TraverseAND (Element, occurrences, SourceElement){

//This method takes handles the propagation of occurrences for AND forks

Returnvalue = TRUE // true by default




Collection NextElements = ELEMENT.getDownConnectedElements()

IF ELEMENT IS_DIRECTED_AS_AND-SPLIT{

For each Element in NextElements{

myOccurences = Occurences


tempReturnvalue = TraverseSimpleDependencyElement(NEXTELEMENT, myOccurrences)

IF tempReturnvalue IS FALSE THEN Returnvalue = FALSE

}

IF NEXTELEMENT ISA ANDFORK{



Page

279

tempReturnvalue =



}

IF NEXTELEMENT ISA ORFORK{

tempReturnvalue =

TraverseOR (NEXTELEMENT,myOccurrences)


}


tempReturnvalue =


}

//Set visited value to be false so the element may be visited again (in the context

//of a different scenariopath.


//We are returning the combined returnvalue of the just executed ‘traverse

//methods’. This makes sure that in the event an end stimulus has been found to

//complete the scenariopath, it is recursively passed along. If even one of them

//returns false our returnvalue should also be false.

RETURN Returnvalue

}

}

ELSE IF ELEMENT IS_DIRECTED_AS_AND-MERGE{

//remember which element was the source from which this fork was traversed //forthe very first time. Only



Page

280

allow further traverse for the same source

IF FIRST_TOUCHED_BY_ELEMENT == NULL{

FIRST_TOUCHED_BY_ELEMENT = Source_Element

}

IF FIRST_TOUCHED_BY_ELEMENT == Source_Element{






}


tempReturnvalue =



}


tempReturnvalue =



}



Page

281


tempReturnvalue =


}




}





If (NextElements.COUNT == 0) Returnvalue = false

RETURN Returnvalue

}

}

TraverseOR (Element, occurrences){

//This method takes handles the propagation of occurrences for OR forks




Page

282




Collection NextElements = ELEMENT.getDownConnectedElements()


//find the fraction of occurrences to send to this element by

// dividing the total of fraction (all elements in NextElement) by the fraction of NextElement

myOccurences = Occurences * (NextElements.getTotalFraction() / NextElement .getMyFraction())




}


tempReturnvalue =



}


tempReturnvalue =



}



Page

283


tempReturnvalue =


}

}








If (NextElements.COUNT == 0) Returnvalue = false

RETURN Returnvalue

}

TraverseValueInterface (Element, occurrences, SourceElement, SourceTransaction){

//This method takes handles the propagation of occurrences for ValueInterfaces





Page

284


ELEMENT.SetOccurences(occurrences)

// Find all valueExchanges that are connected to ELEMENT in such a way that they are admissible for traversal –

// meaning that depending on the direction in which they are attached to value ports (inward, outward, first, or second)

// ports are chosen, or they are rejected. This is done because we only want to traverse forward, not backwards.

Collection nextValueExchanges = findAdmissableValueExchanges( )

// Find all valueTransactions that contain valueExchanges which are contained in nextValueExchanges

For each element in nextValueExchanges{

Collection NextTransactions. Add( exchange.getValueTransactions ( ))

}

// calculate totalFraction

For each element in nextTransactions{

totalFraction = totalFraction + exchange.getFraction ( )

}

// remember via which sub transaction this value interface was traversed/for the very first time.

// Only allow further traverse for the same source. This mechanism allows value interfaces to work as AND-fork merges.

ALLOW_TRAVERSE = false // default value

IF FIRST_TOUCHED_BY_VALUEINTERFACE == NULL AND FIRST_TOUCHED_VIA_TRANSACTION == NULL{

FIRST_TOUCHED_BY_VALUEINTERFACE = Source_Element



Page

285

FIRST_TOUCHED_VIA_TRANSACTION = SourceTranscation

}

IF FIRST_TOUCHED_BY_ELEMENT == Source_Element AND FIRST_TOUCHED_VIA_TRANSACTION == SourceTranscation {

ALLOW_TRAVERSE = TRUE;

}

IF ALLOW_TRAVERSE {

// traverse

For each element in nextTransactions{

Collection myExchanges = Transaction.getExchanges( );

For each element in myExchanges {

// Ask the value exchange to give us the value interface which is on the other side (as opposed to ELEMENT)

ValueInterface NEXT_VI = Exchange.getValueOtherExchange(ELEMENT)

myOccurences = (totalFraction / Transaction.getFraction() ) * Occurences

TraverseValueInterface (NEXT_VI, myOccurences, ELEMENT, Transaction)

}

}

}

//All Value interfaces that were connected via value exchanges have now been traversed.

//Now it is time to traverse all dependency elements connected via connection elements.

Collection NextElements = getDownConnectedDependencyElements( );



Page

286






}


tempReturnvalue = TraverseAND (NEXTELEMENT, occurrences, ELEMENT)


}


tempReturnvalue = TraverseOR (NEXTELEMENT,myOccurrences)


}


tempReturnvalue = TraverseValueInterface (NEXTELEMENT, myOccurences, ELEMENT, Null)


}

}



Page

287








If (NextElements.COUNT == 0 AND NextVIs.COUNT == 0) Returnvalue = false

RETURN Returnvalue

}



Page

288

10.2.4 Parse all formulas

The formulas are represented as strings in the graphical editor and have the structure of the formulas of Excel with the one exception that values can be represented by an e3-value formula. These e3-value formulas have a strict syntax. They start with ‘e3{‘ and they end with ‘}’. The text between these fixed symbols consists of two parts. The first part represents an e3-value object in the model and the second part is either an ontology property of that object or a formula of that object. The first part resembles the structure of a package name as it consists of parts separated by dots allowing for navigation in a hierarchical structure. Two examples of e3-value formulas will clarify the structure.

• E3{ ElementaryActor(“L1”).ActorInMarketSegment(“Listeners”).Count}

• E3{ValueExchangeHasInPort(“MusicPort”).Valuation}

The first formula starts with an absolute reference to an elementary actor named “L1” that must be present in the scope of the model. It is followed by a relative reference ActorInMarketSegment(“Listeners”) to a MarketSegment named “Listeners” to which “L1 “must belong. Count is an ontological property of MarketSegment.

The second formula starts with a relative reference that only makes sense if this formula belongs to a value exchange. In that case it refers to its port named “MusicPort”. So this second function represents the valuation function of this port. In the profitability sheets this formula will be replaced by a reference to the field containing the value of this valuation function. Only when the sheets are numerically processed a numerical value will be substituted for this e3-value formula.

In the parsing operation all e3-value formulas in the model are replaced by the reduced form E3{#UID.name}. Here UID is an integer that uniquely identifies the e3-value object in the model and name is the name of a function or of an ontological property of that object. The Gold parser, a third party package as described before, does this job. It needs to be fed before with the grammar we use in our formulas.

We traverse all e3 objects in the model. For each object we traverse all the formulas. Each formula is broken up in E3 formula parts and plane Excel parts. The E3 formula parts are reduced as just described and the Excel parts are kept unchanged. The resulting formula is stored in a Map belonging to the object.

10.2.5 Create a ‘Formula Sheet’ for all formulas (or placeholders).

The first step of actually creating Excel sheets is to create the so-called ‘Formula Sheet’. The ‘Formula Sheet’ is a single sheet containing all formulas and attributes of all objects from the business model. The purpose of the ‘Formula Sheet’ is that it serves as a reference for all other sheets.

Initially the formulas are first ‘dumped’ onto the formula sheet in the form of literal strings. These ‘dummy’ strings are not the actual formulas and serve as nothing but placeholders.



Page

289

Each time a formula- or attribute-string is dumped to the formula sheet, its coordinates on the sheet are remembered in the form of a cell reference.

After all formulas have been assigned a location (coordinates) on the Formula Sheet, we can iterate over all the dummy formulas and replace object references with the actual cell references that we have just assigned. For example, the expression

‘e3 {SomeObject.AttributeName}

Would be replaced by the expression:

‘Formulasheet!A2’

The first run in which we wrote the dummy formulas to the spreadsheet is necessary because we need to assign the cell locations first, before we are able to reference them.

After the formula sheet has been created it is referenced by the other sheets. This prevents redundancy of information.

10.2.6 Assign ‘Default Valuation Formulas’ to each value port

It is of course possible to define a valuation function for each value port instance in the model, but this would be a lot of work, and it would also not be necessary in most cases. To reduce the number of valuation functions in the models the e3-value tool uses so called ‘default valuation functions’. These functions are formulas that are automatically generated for each port in the model, and they are used for profitability sheet generation when the e3-value tool is unable to find a custom valuation for a port under consideration.



Page

290

Figure 1 Example of default valuation formulas

“Default” valuation formulas are automatically generated by collecting the existing ‘VALUE’ formulas for all value ports that are part of a value interface which is attached to a ‘autonomous’ actor, activity or market segment. (IE: all actors, value activities, and market segments that connected via an in- or out-connected value exchange) These valuation formulas are then cascaded onto the other value ports in the model (the ones that only have first- or second-connected value exchanges). The default valuation functions are cascaded throughout the model as follows:

Value interfaces are divided into two categories: The ones that contain value ports, which connect value exchanges through the in-out mechanism21, and the ones that do not.

The value ports belonging to value interfaces of the first category are taken as a basis, and a starting point, from which the valuation functions are spread inwards across the rest of the model; onto the value ports, which belong to value interfaces that belong to the second category. For each value port ‘p0’ that exists in the business model and belongs to the first category:

1. For value port

1.1. If the direction of ‘p0’ is inward, add all ports connected to ‘p0’ through ‘first connected’ value exchanges to the collection ‘c_next’ and add all ports connected to ‘p0’ through ‘second connected’ value exchanges to the collection ‘c_previous’

21 As opposed to the first/second mechanism



Page

291

1.2. If the direction of ‘p0’ is outward, add all ports connected to ‘p0’ through ‘second connected’ value exchanges to the collection ‘c_next’, and add all ports connected to ‘p0’ through ‘first connected’ value exchanges to the collection ‘c_previous’.

1.3. If ‘p0’ belongs to the first category

1.3.1. ‘p0.DEFAULT_VALUATIONFUNCTION = p0.find ValuationFunction()’

1.4. else

1.4.1. ‘p0.DEFAULT_VALUATIONFUNCTION’ is the weighed average of the default valuation functions of the peer ports in ‘c_previous’, where the weight is determined by number of occurrences of the peer port; for example: ‘((peer_port1.defaultvaluationfunction * peer_port1.occurences) + (peer_port2.defaultvaluationfunction * peer_port2.occurences) + (…))/(peer_port2.occurences +peer_port2.occurences+…)’

1.5. For each value port ‘p1’ in ‘c_next’

1.5.1. Execute step 1.

Note: All value ports of the first category are required to have a valuation function (either assigned to the port itself or, if the port exchanges a money object, via a bi-laterally agreed valuation function – where the valuation function is located on the value exchange, or via an in-out connected peer-port) If no valuation can be found for these value ports, an exception occurs and an error is thrown.

10.2.7 Update the Formula sheet with ‘Default Valuation Formulas’

After default valuation formulas have been assigned to the value ports in the model, the formula sheet should be updated, replacing the default valuation function formula placeholders with the actual formulas. The reason that this step is separated from step 10.2.5 is that that in order to be able to create the default valuation formulas it is required that for all value ports the coordinates of its default valuation function is known (even if it does not exist!). Therefore, adding ‘dummy’ formulas to the spreadsheet creates placeholders. These ‘dummies’ are later replaced by the actual formulas.

10.2.8 Create Excel sheets for each e3-value ontology class

For each e3-value class we create an individual sheet (provided the class is used in the business model). These sheets contain a list of all instances of that class, and their respective properties. This is done so that users will not have to bother searching through the entire formula sheet to look up a specific attribute value.



Page

292

10.2.9 Create Excel (profitability) sheets for any Value Source instance.

For each instance of the aforementioned classes a separate excel sheet is created.

Figure 2

These sheets are created by adding cells in the following way:

1. For each value interface ‘a’ attached

1.1. Create a new entry to column ‘A’

1.2. For each value port ‘b’ in ‘a’

1.2.1. Create a new entry to column ‘B’

1.2.2. In case a ‘b’ exchanges a “MONEY” object

1.2.2.1. For each value exchange ‘c’ connected to ‘b’

1.2.2.1.1. Create a new entry to column ‘C’

1.2.3. In case a value port exchanges other objects than a “MONEY” object:

1.2.3.1. Create a single (generic / composite) entry to column ‘C’ representing all value exchanges connected to ‘b’ since all of them share the same valuation function.

So, the follow columns are created (also see Figure 2)

• Column A – List of value interfaces for this actor.

• Column B – Value ports for each interface (total for this value interface is shown at the top).

• Column C – Value exchanges for each value port

• Column D – Number of occurrences for each port / exchange-combination.

• Column E – The corresponding valuation function.



Page

293

• Column F – Economic value (valuation multiplied by the number of occurrences).

In the e3-value tool, valuation functions are represented as special formulas, and they can be attached to value ports or value exchanges. To create a valuation function for one of these objects you can simply create a new formula and name it “VALUATION”.

When generating profitability sheets from your models, the e3-value tool will attempt to decide which valuation should be used for which value ports, and the outcome of this decision depends on the type of value object that has been attached to each of the value ports. It makes a distinction between the following three possibilities:

• The port under consideration is attached to a value object of the type “MONEY”.

• The port under consideration is attached to a value object of another type.

• The port under consideration is not attached to a value object.

This factor plays a role in determining where the tool will search for a valuation function to assign to the value port.

This search is conducted using the following rules:

1. In case a value port exchanges a “MONEY” value object via a value exchange:

1.1. If a valuation formula is found for the value exchange under consideration connected to the port under consideration, it is used.

1.2. If a valuation formula is found for the port under consideration, it is used (the ordering of these two rules models that bi-literal price arrangements override uni-lateral, overall arrangements)

1.3. If a valuation formula is found for the “peer”-port connected to the port under consideration (via the value exchange under consideration), it is used.

1.4. If the value port under consideration belongs to a container (actor / value activity/market segment) which in turn belongs to another (composite) container, the e3-value tool will use a default valuation function (created by propagating the valuation functions of other ports nearby to the value port under consideration – See section:10.2.6 “Default valuation functions”)

1.5. If no valuation formula is found, this results in an error. The same holds if a different valuation formula is found on both ports.

2. In case a value port exchanges other objects than a “MONEY” object:

2.1. If a valuation formula for that port is specified it is used.



Page

294

The value entered in the ‘occurrences’ field of each value exchange is derived from the fact that the number of occurrences of each value transaction in the model is known (see section 10.2.3). Therefore, we can find the number of occurrences for a value exchanges by taking the sum of the occurrences of all value transactions in which it is involved.

The economical value is calculated by multiplying the each of the occurrence values listed in column C with the corresponding valuation function from column D.

Finally, a new row is created at the bottom of the sheet containing the aggregated values of each of the columns to give an overview of the actual profitability of this actor.



Page

295

Appendix K E3-value editor: tips, tricks and error messages

This appendix contains user documentation for the e3-value tool and is intended purely as a source for reference information.

11.1 Import shortcuts and tricks

• Sometimes you want to select a value port or a scenario port. Using the normal way by clicking the object the editor tries drawing a connection to another port. Now you have two options. The first is to let it happen and then to delete the unwanted connection. You are back where you started. The second option is to release the connection at some impossible place from any port. Your port is selected and your goal achieved.

• CTRL-Z will undo your previous action(s).

• Selecting a single value interface and clicking on another value source will connect all ports of the selected interface instantly to a new value interface with corresponding ports on the other value source. A value transaction is created with all new value exchanges.

• Selecting a value interface and pressing the home and end keys will move a value interface around the edge of its value source.

• Selecting a single value port or scenario port and pressing the up and down arrow will change that port’s position in the value interface or scenario element. Pressing the del key or the backspace key will delete a port and select another.

• Selecting several value ports on one value interface and the pressing the right mouse button will allow you to split these ports of to a new value interface.

• Selecting several value interfaces and then pressing the right mouse button will allow you to join these value interfaces into one interface.



Page

296

11.2 Error messages

In this paragraph, you will find a list of possible error messages that may be displayed by the e3-value tool during RDF-export and Profitability-sheet generation.

There are a few specific error messages that may be displayed by the e3-value tool because of incomplete or incorrect transaction modelling which you should look out for, namely:

• “Cannot find end-stimulus when calculating path” Indicates that some value exchanges may not have been bundled into value transactions.

• “Value interface not modelled correctly: Each connected transaction should connect every of it’s ports via an exchange”

• “Value port is involved in a value transaction (more than once)”

• “Value port not involved in value transaction”

Error messages related to modelling (visual)

Message: “AND-port has not been connected correctly (possible loop)”

Explanation: See: “Object is involved in a loop.”

Screenshot: N / A

Message: “At least one start stimulus required”

Explanation: When generating profitability sheets it is required that one (or more) start-stimuli are included in the model.

Screenshot: N / A

Message: “Both ports connected by a value exchange should have the same value object.”

Explanation: Both ports connected by the same value exchange should be assigned to the same value object.

Screenshot: N / A



Page

297

Message: “Can not connect start-/end-stimulus as 'down' / ‘up’”

Explanation: A collision of scenario paths has been detected. Make sure that each possible scenario-path is connected to a start stimulus on one end and an end stimulus on the other.

Screenshot:

Message: “Cannot find end-stimulus when calculating path” (starting at start stimulus [ID])”

Explanation: There exists one or more scenario paths that cannot be traced to an end-stimulus. Check if there are end-stimuli and whether they are connected to said start stimulus through a scenario path. This error may also occur if the value transactions in the diagram are not chosen / assigned correctly.

Screenshot:



Page

298

Screenshot:

Message: “AND has an OCCURRENCES-Merge error”

Explanation: Occurrences of incoming paths involved in an and-merge are not equal (note: an error margin of 1% is taken into account)

Screenshot:

Message: “Value interface has an OCCURRENCES-Merge error”

Explanation: Occurrences of incoming paths involved in an “and-merge” are not equal (note: an error margin of 1% is taken into account)

Note: though the scenario path may be connected correctly, the connection

made by the two value exchanges in the example to the left will not be recognised

as such unless both exchanges are bundled through a value transaction.



Page

299

Screenshot:

Message: “Value interface not modelled correctly: Each connected transaction should connect every of it’s ports via an exchange”

Explanation: Make sure that all value transactions have been correctly assigned to the value exchanges in the model.

Screenshot:

Message: “Object is involved in a loop.”

Explanation: A scenario-path loop has been detected.



Page

300

Screenshot:

Message: “Value port is involved in a value transaction (more than once)”

Explanation: Value ports are only allowed to be involved in the same value transaction once.

Screenshot: N / A

Message: “Value port not involved in value transaction”

Explanation: If a value port is involved in a value transaction, so should the other ports in that value interface.

Screenshot:

Error messages related to formulas



Page

301

Message: “Grammar not loaded, can not continue.”

Explanation: The formula.cgt file needs to be in the e3-value tool install directory.

Message: “Invalid COUNT defined on market segment [ID]”

Explanation: An invalid value has been entered for the formula named “COUNT” for market segment [ID] .An Integer is expected.

Message: “Invalid down-attribute for connection element [ID]”

Explanation: An invalid value has been entered for the down-attribute for connection element [ID] .An Integer is expected.

Message: “Invalid up-attribute for connection element [ID]”

Explanation: An invalid value has been entered for the up-attribute for connection element [ID] .An Integer is expected.

Message: “Invalid OCCURRENCES defined on start stimulus [ID]”

Explanation: An invalid value has been entered for the formula named “OCCURRENCES” for start stimulus [ID] .An Integer is expected.

Message: “Missing "}" after "e3{" in formula [f] of the class [c] named [n];”

Explanation: When using object references in formulas, always close the ‘e3{’ tag with a ‘}’.

Message: “No COUNT defined for market segment [ID]”

Explanation: Every market segment is required to have a formula named “COUNT”.

Message: “No OCCURRENCES defined for start stimulus [ID]”

Explanation: Every start stimulus is required to have a formula named



Page

302

“OCCURRENCES”.

Message: No model concept with [ID] found in model.

Message: Not found globally: a [Object] named: [Name]

Explanation: A formula is referring to an object which does not exist in the model.

Message: “No ‘FRACTION’ formula found for value transaction [ID]”

Explanation: No “FRACTION” formula has been found for this transaction. This formula is required.

Message: “No valuation function found for value_port [ID]”

Explanation: No “VALUATION” function found when dealing with a port that requests or offers a 'MONEY' object. Please see the section “Valuation Functions” for more details.

Message: “Parse error”

Explanation: There is a syntax error in one of the formulas entered,

Message: “Syntax error in formula of [Object]”

Explanation: Syntax error detected.

Message: “Syntax error (multiple"=" symbols in formula)”

Explanation: Syntax error detected; Only one "=" symbol per formula allowed.

Message: “Unary operator used - please see user documentation for guidelines on writing formulas”

Explanation: The current version relies on a third party software package (Apache POI / HSSF) for spreadsheet generation, which does not support unary operators such as the "-" operator in the expression "-x". A work-



Page

303

around for this problem is to rewrite the expression as "(0-x)". This functionality will be added later. See section 'Writing formulas' for more information.

Table 23 Error message overview



Page

304

11.3 Formulas: Reserved names

A small number of names have been reserved for e3-value -specific attributes:

Formula name

Attribute: “Count” attribute

Scope: Used as an attribute of market segments.

COUNT

Constraints: Formula body must be an integer.

Attribute: “Fraction” attribute

Scope: Used as an attribute of value transactions

FRACTION


Attribute: “Occurrences” attribute

Scope: Used as an attribute of start stimuli

OCCURRENCES


Attribute: Valuation function VALUATION

Scope: Used as a valuation function if formula is attached to a value port or a value exchange.




Page

305

NORM_VALUE Attribute: Valuation function

Scope: Used as a ‘default’ valuation function if no user-specified valuation function can be found.

Constraints: This formula is reserved for internal purposes only. Users are not allowed to specify custom values.

Table 24 Reserved formula names

Note that these names should be spelled exactly as above. They are case-sensitive!

11.4 Formula Syntax

Below is a list of expressions (and syntax) ordered by categories (top-level object references, sub-level references and a selection of attribute references)

Top-level object reference

MarketSegment(“object_name”)

ElementaryActor(“object_name”)

CompositeActor(“object_name”)

ValueObject(“object_name”)

ConnectionElement(“object_name”)

DependencyElement(“object_name”)

ValueInterface(“object_name”)

Table 25 Writing formulas - top level object reference syntax



Page

306

Sub-level object reference

ActorHasValueInterface(“object_name”)

ActorInMarketSegment(“object_name”)

ElementaryActorPerformsValueActivity(“object_name”)

CompositeActorConsistsOfValueInterface(“object_name”)

ConnectionElementHasDownDependencyElement(“object_name”)

ConnectionElementHasUpDependencyElement(“object_name”)

DependencyElementWithDownConnectionElement(“object_name”)

DependencyElementWithUpConnectionElement(“object_name”)

MarketSegmentConsistsOfActor(“object_name”)

MarketSegmentHasValueInterface(“object_name”)

ValueActivityHasValueInterface(“object_name”)

ValueActivityPerformedByElementaryActor(“object_name”)

ValueExchangeHasFirstValuePort(“object_name”)

ValueExchangeHasSecondValuePort(“object_name”)

ValueExchangeHasInPort(“object_name”)

ValueExchangeHasOutPort(“object_name”)

ValueExchangeInValueTransaction(“object_name”)

ValueInterfaceAssignedToMarketSegment(“object_name”)

ValueInterfaceAssignedToValueActivity(“object_name”)

ValueInterfaceConsistsOfOffering(“object_name”)

ValueOfferingConsistsOfValuePort(“object_name”)

ValueOfferingInValueInterface(“object_name”)

ValuePortFirstConnectsToValueExchange(“object_name”)



Page

307

ValuePortInConnectsToValueExchange(“object_name”)

ValuePortInValueOffering(“object_name”)

ValuePortOutConnectsToValueExchange(“object_name”)

ValuePortRequestsOrOffersValueObject(“object_name”)

ValuePortSecondConnectsToValueExchange(“object_name”)

ValueTransactionConsistsOfValueExchange(“object_name”)

Table 26 Writing formulas - sub-level object reference syntax

Attribute reference Applicable when Parent Object is a:

Name e3object

UID e3object

UpFraction ConnectionElement

DownFraction ConnectionElement

FirstFraction ConnectionElement

SecondFraction ConnectionElement

InFraction ConnectionElement

OutFraction ConnectionElement

Direction Port

Valuation Port or ValueExchange

Fraction Transaction

Table 27 Writing formulas - Attribute reference syntax



Page

308

11.5 Formulas: Formula limitations

The current version of the tool relies on a third party API - Jakarta POI / HSSF - for spreadsheet generation. This API currently does not support unary operators, e.g.: the "-" operator in the expression "-x". Because of this, it is currently not possible to use such expressions when writing formulas in the tool. A work-around for this problem is to rewrite the expression as "(0-x)".

HSSF is expected to support unary operators in the near future, and this feature will be integrated in the tool as soon as possible.

11.6 Merging Objects



Page

309

In the e3-value tool it is possible to model multiple (graphical) objects so that they are representations of the same e3-value object.

Figure 110 Example of multiple graphical objects representing a single conceptual object

Figure 111 Example of multiple graphical objects representing a single conceptual object

These are two examples of models containing multiple graphical objects that represent a single conceptual object instance. When generating profitability sheets the e3-value tool takes the model created by the user and transforms it (if necessary) into a conceptual model, merging the object instances where possible. This new model is then used to generate the actual spreadsheet.

Besides the object name there is a number of other conditions that are tested:

4. Both objects must have the same name (excluding “” – empty string)

5. Both objects must be of a corresponding class type.

6. Both objects should be in the same scope.

The scopes of both objects should be equal, but can depend on the class type. For example: for some classes it may be sufficient if both instances exist in the global scope (which is always true per definition), but two value ports will not be merged unless they have the same names as well as exist in the scope of the same value interface.

If one (or more) of these criteria is not met, the two model concepts will simply not be merged. A new instance will be created for each of them. If they are met, another number of criteria is evaluated. While these criteria are specific for each class type, they can be divided into two categories.



Page

310

3. The collections of formulas of both objects must be mergable – if two objects have one or more formulas with the same name (header), the formulas’ bodies must be equal.

4. The attributes of both objects should be equal. This includes fractions, but also references to other objects (in which case both the name and class type should be equal).

Merge Criteria (per class):

Market Segment Merge if: the same name is used by any other market segment and their formulas are mergable.

Actor Merge if: the same name is used by another Actor, both actors exist in the same scope, and their formulas are mergable.

Value Object Merge if: the same name is used by any other value object and their formulas are mergable.

Simple Dependency Element Merge if the same name is used by another simple dependency element of the same class, both share attributes (including connections to connection elements) of the same name, and their formulas are mergable.

Complex Dependency Element (except ValueInterface)

Merge if the same name is used by any other dependency element of the same class.

Connection Element Merge if the same name is used by any other connection element if both share the same characteristics: the names of the objects in the following fields must be equal for both instances: up_de, down_de; and their formulas are mergable.

Value Activity (in scope Actor / Market Segment)

Merge if the same name is used by another value activity, both exist in the same scope, and their formulas are mergable.

Value Offering Not applicable.

Value Port

(in Scope Value Offering)

Merge if the same name is used by another value port which shares the same parent (of class Value Interface) both instances have the same direction (inward / outward).



Page

311

Value Exchange

(in Scope Value Port)

Merge if the same name is used by another value exchange which is connected to the ports bearing the same name (both in and out).

Value Interface Merge if the same name is used by any other value interface and their formulas are mergable.

Value Transaction Merge if the same name is used by any other value transaction and formulas are mergable.

Table 28 Criteria for merging graphical objects

If more of the criteria in the above list are not met, then the export process will be aborted and an error message will be displayed.

11.7 Valuation functions

When you are creating models using the e3-value tool, it is important to understand the way in which value ports are assigned valuation functions. This will be discussed in this section.

In the e3-value tool, valuation functions are represented as special formulas, and they can be attached to value ports or value exchanges. To create a valuation function for one of these objects you can simply create a new formula and name it “VALUATION”.

When generating profitability sheets from your models, the e3-value tool will attempt to decide which valuation should be used for which value ports, and the outcome of this decision depends on the type of value object that has been attached to each of the value ports. It makes a distinction between the following three possibilities:

• The port under consideration is attached to a value object of the type “MONEY”.

• The port under consideration is attached to a value object of another type.

• The port under consideration is not attached to a value object.

This factor plays a role in determining where the tool will search for a valuation function to assign to the value port.

This search is conducted using the following rules:

3. In case a value port exchanges a “MONEY” value object via a value exchange:

3.1. If a valuation formula is found for the value exchange under consideration connected to the port under consideration, it is used.

3.2. If a valuation formula is found for the port under consideration, it is used (the ordering of these two rules models that bi-literal price arrangements override uni-literal, overall arrangements)



Page

312

3.3. If a valuation formula is found for the “peer”-port connected to the port under consideration (via the value exchange under consideration), it is used.

3.4. If the value port under consideration belongs to a container (actor / value activity/market segment) which in turn belongs to another (composite) container, the e3-value tool will use a default valuation function (created by propagating the valuation functions of other ports nearby to the value port under consideration – See paragraph: 10.2.6 “Default valuation functions”)

3.5. If no valuation formula is found this results in an error. The same holds if a different valuation formula is found on both ports.

4. In case a value port exchanges other objects than a “MONEY” object:

4.1. If a valuation formula for that port is specified it is used.

Note: If any of the steps above result in an error, profitability-sheet generation is aborted.



Page

313

Default valuation functions

It is of course possible to define a valuation function for each value port instance in the model, but this would be a lot of work, and it would also not be necessary in most cases. To reduce the number of valuation functions in the models the e3-value tool uses so called ‘default valuation functions’. These functions are formulas that are automatically generated for each port in the model, and they are used for profitability sheet generation when the e3-value tool is unable to find a custom valuation for a port under consideration.

Figure 112 Example of default valuation formulas

“Default” valuation formulas are automatically generated by collecting the existing ‘VALUE’ formulas for all value ports that are part of a value interface which is attached to a ‘autonomous’ actor, activity or market segment. (IE: all actors, value activities, and market segments that connected via an in- or out-connected value exchange.) These valuation formulas are then cascaded onto the other value ports in the model (the ones that only have first- or second-connected value exchanges).



Page

314

Appendix L E3-value editor: appendix for the programmer

In this appendix, you will find an overview of the third party software packages the e3-value tool uses, as well as a more detailed description of their functions and implementation.

The e3-value tool uses the following third party software packages.

• Batik

• GOLD Parser

• Jakarta POI HSSF

• JGo™ Java diagram graphics libraries

• RDF2Java

Each package will be discussed individually.

12.1 Batik

12.1.1 Details

Batik is a Java(tm) technology based toolkit for applications or applets that want to use images in the Scalable Vector Graphics (SVG) format for various purposes, such as viewing, generation or manipulation. SVG is a W3C recommendation; it is a language for describing two-dimensional graphics in XML. SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), images and text.

Name: Batik SVG toolkit

Version: 1.5

URL: http://xml.apache.org/batik/index.html

Developer: The Apache Software Foundation

Developer URL: http://www.apache.org/foundation/



Page

315

12.1.2 Implementation

The business model created in the e3-value graphical editor can be represented in two graphical formats. One of them is the SVG format. JGo uses the Batik software in order to produce documents in this format. The API is only used indirectly via the JGo software. We only had to include the batik software in our libraries.

12.2 Jakarta POI HSSF

12.2.1 Details

The e3-value tool uses the POI HSSF API for spreadsheet generation. The Apache Software Foundation as part of their ‘Jakarta’ project have developed the POI HSSF.

The POI project consists of APIs for manipulating various file formats based upon Microsoft's OLE 2 Compound Document format using pure Java.

HSSF is the POI Project's pure Java implementation of the Excel '97(-2002) file format. It provides a way to read spreadsheets create, modify, read and write XLS spreadsheets.

Name: Jakarta POI HSSF

Version: 2.0 - Final 20040126

URL: http://jakarta.apache.org/poi/hssf/index.html

Developer: The Apache Software Foundation

Developer URL: http://www.apache.org/foundation/


The HSSF API is used by the e3-value profitability sheet generator component, and it is used to create XLS workbooks as well as write them. The API is used ‘as is’, meaning that no alterations have been made to the source code.



Page

316

12.2.3 Limitations

Currently the e3-value tool does not support formulas containing unary operators (e.g. the ‘minus’ symbol in the expression ‘-1’). This is because of the fact that the HSSF API currently does not support them. Because of this, it is currently not possible to use such expressions when writing formulas in the tool. A work-around for this problem is to rewrite the expression as "(0-x)".

HSSF is expected to support unary operators in the near future, and this feature will be integrated in the tool as soon as possible.

12.3 JGo™ Java diagram graphics libraries

12.3.1 Details

JGo™ is a Java graphics library that makes it easy to build custom interactive diagrams. It has built-in support for many shapes, text, images, containers, links, arrowheads, scrolling, zooming, selection, drag-and-drop, resizing, in-place text editing, tool tips, and printing. JGo offers a package of classes that need to be extended to create a custom application. In these extended classes the behaviour and attributes specific to that application are defined. JGo is based on the Model View Control architecture.

Name: JGo: Java diagram graphics libraries

Version: 5.0

URL: http://www.nwoods.com/go/jgo.htm

Developer: Northwoods Software

Developer URL: http://www.nwoods.com


All graphical elements in the editor are derived from JGoObject. These are the atoms of the framework. They are owned by a JGoDocument, essentially a container class ( the Model ), seen in a JGoView (the View) and managed by the editor (the Control ). Some JGoObjects are JGoAreas, graphical containers that can hold other JGoObjects. This way hierarchical graphical objects can be built. Some JGoObjects are JGoPorts. JGoPorts are linkable to each other using JGoLinks. Deriving from these JGo classes enabled us to use most of their rich functionality. We managed to do this without altering the JGo source code. Only in three instances we had to introduce some slight modification. One fixed a bug and the other two



Page

317

are enhancements.

12.4 GOLD Parser

12.4.1 Details

GOLD Parser is a software package that allows the e3-value tool to parse formulas written using a simple grammar specifically designed to be able to refer through object in the e3-value ontology.

Name: GOLD Parser

Version: 2.06

URL: http://www.devincook.com/goldparser/

Developer URL: http://www.devincook.com/goldparser/contributors/index.htm


Formulas in the e3-value tool are based on Microsoft Excel (‘98). This makes it possible to write formulas in the e3-value tool and maintaining them when we want to generate profitability sheets (which are created in the Excel ‘98 format). However, there is one difference between e3-value formulas and Excel formulas. This difference lies in the way in which formulas can refer to other values (references).

Where, in Excel, you would typically refer to cells, in the e3-value tool you refer to attributes of e3-value objects. To this end, we have developed a simple grammar / formula language (using the GOLD Parser grammar-building tool) that allows end-users to refer to e3-value objects in the scope of the business models.

A second component of the GOLD Parser solution is the GOLD engine, a parsing engine that has been implemented in the e3-value Profitability sheet generator. This engine reads the output of the grammar-building tool (a so called ‘grammar file’) and uses it to parse the complex formulas created by the user into their most elementary form. These elementary references are then mapped to cell coordinates in the Excel sheets.

The GOLD Parser engine is used ‘as is’, meaning that no alterations have been made to the source code.



Page

318

12.5 RDF2Java

12.5.1 Details

The RDF2Java tool allows RDF files to be imported into Java and Java objects to be exported to RDF files.

Simple Java classes (these classes are derived from the e3-value ontology RDFSchema using the same RDF2Java tool) serve this purpose (similar to the JavaBeans mechanism, put and get methods are used). It uses the Java reflection API to directly serialize and de-serialize Java objects.

Name: RDF2Java

Version: 20010705

URL: http://www.dfki.uni-kl.de/~schwarz/RDF2Java/doc/index.html

Developer: DFKI (German Research Centre for Artificial Intelligence), Kaiserslautern.

Developer URL: http://www.dfki.de/dfkiweb/start.htm


We have used the RDF2Java tool to generate simple Java classed from the e3-value RDFSchema. These generated Java classes mirror each of the classes from the e3-value ontology. The classes are used by the following e3-value tool components:

• e3-value RDF exporter

• e3-value Profitability sheet generator

The RDF exporter creates instances of these ‘ontology mirror classes’ to represent the business models created by the user in a way that is conforming to the e3-value ontology. These instances are assigned attributes (literals as well as object references) and then exported to an RDF stream using the RDF2Java export function.

The Profitability sheet generator uses the output from the RDF exporter to generate profitability sheets. The RDF exporter offers the sheet generator a conceptual representation of the business models created by the user in the form of class instances of the ‘ontology



Page

319

mirror classes’.

12.6 Customizing third party software

We used third party software unchanged as much as possible. In a few cases a slight change was necessary. For future reference we will describe these changes, their purpose and their necessity

12.6.1 JGo

12.6.1.1 JGoDocument.java

The method setMaintainsPartID is changed to the following:

/**

* Change whether this document assigns a unique PartID to each JGoIdentifiablePart

* as it is added to the document.

* <p>

* Setting this property to true will also invoke ensureUniquePartID().

* Setting it to false will clear the HashMap that findPart uses, but will

* not modify any JGoIdentifiablePart PartID.

*/

public void setMaintainsPartID(boolean bFlag)

{

boolean old = myMaintainsPartID;

if (old != bFlag) {

myMaintainsPartID = bFlag; // in original code myMaintainsPartID = old;

fireUpdate(JGoDocumentEvent.MAINTAINS_PARTID_CHANGED, 0, null, (old ? 1 : 0), null);

if (bFlag)

ensureUniquePartID();

else

myParts = null;

}

}



Page

320

The original code is showed as a comment.

A short reflection will convince you that the original code was at fault. It resulted in the impossibility to maintain unique ID’s automatically in the editor. Repairing the bug in the derived class E3tor_diagram is impossible because the field myMaintainsPartID is private.

12.6.1.2 JGoTextEdit.java

public JComponent createComponent(JGoView view) {

JTextComponent textc;

if (myMultiline) textc = new JGoJTextArea(myOriginalText, this);

else textc = new JGoJTextField(myOriginalText, this);

textc. addCaretListener( new Listener(textc) ); // this line is added

return textc;

}

And the following class is added:

private class Listener implements CaretListener{

private JTextComponent c;

Listener(JTextComponent c){

this.c = c;

}

public void caretUpdate(final CaretEvent e){

Rectangle r = getBoundingRect();

int longest_line =0 , lines = 0;

for(StringTokenizer token = new StringTokenizer(c.getText(),"\n"); token.hasMoreTokens();++lines) {

String s = token.nextToken();

int l = s.length();

if(longest_line < l) longest_line = l;

}

r.width = 20 + longest_line * 6;

r.height = 17 + lines * 17;



Page

321

setBoundingRect(r);

update();

}

}

These changes result in textfields that grow while adding text. The original JgoText field only resize after completing the editing. One might consider to derive JGoTextEdit a custum class E3TextEdit that implements the desired feature by overriding createComponent.

12.6.1.3 JGoView

The method pickNearestPort is rewritten in order no nearest port is picked that is too close to a port already selected. The return statement of the method has been replaced by the next piece of code.

if ( currentBestPort == null || myTempStartPort == null ) return currentBestPort;

Point dest = currentBestPort.getSpotLocation(JGoObject.Center);

Point src = myTempStartPort.getSpotLocation(JGoObject.Center);

int dist = (src.x - dc.x)*(src.x - dc.x) + (src.y - dc.y)*(src.y - dc.y) ;

if( dist < 100 && (dest.x - dc.x)*(dest.x - dc.x) + (dest.y - dc.y)*(dest.y - dc.y) >

dist ) return null;

return currentBestPort;

It is not possible to achieve this effect in the derived class View because myTempStartPort is a private field in JGoView.

12.6.2 Gold

The JAVA-Gold parser environment normally reads the strings to parse from a file. We have changed the Java-Gold parser engine to read from a string as follows:

12.6.2.1 GOLDParser.java

The method openFile(filename) will be called with the string to parse, rather than the filename that contains the file to be parsed.

12.6.2.2 LookAheadStream.java

The method openFile(file) is changed into:



Page

322

public boolean openFile(String file) throws ParserException

{

// try

// {

// buffR = new PushbackReader(new FileReader(new File(file)));

buffR = new PushbackReader(new StringReader((file)));

unreadme = new char[kMaxBufferSize];

bufferPos = 0;

// }

// catch(IOException ioex)

// {

// throw new ParserException("Source file could not be opened.");

// }

return true;

}

This code does not open a file, but places the string to parse directly in the PushbackReader.

distributed generation business modellingd 5.1 distributed generation business modelling eesd...

Documents