An ontological approach for the use of pricing models to sell services Master thesis in Information Sciences

Transcription

1 An ontological approach for the use of pricing models to sell services Master thesis in Information Sciences Benito de Miranda Vrije Universiteit Amsterdam, The Netherlands June 2005

2 Dedicated to my beloved Mother and Father 2

3 Preface This Master thesis is the result of several months of research. It is the final product of the Information Sciences study at the Vrije Universiteit in Amsterdam, the Netherlands. Two people have supervised this research: Z. Baida, M.Sc. Vrije Universiteit Faculty of Sciences, department of Business Informatics de Boelelaan 1081a 1081 HV Amsterdam The Netherlands dr. ing. J. Gordijn Vrije Universiteit Faculty of Sciences, department of Business Informatics de Boelelaan 1081a 1081 HV Amsterdam The Netherlands Acknowledgements I hereby would like to thank my mentor Ziv Baida very much for his support, feedback and patience throughout the process of this work. I also want to thank Jaap Gordijn for his valuable contributions to this research. Very special thanks are dedicated to my partner Yacine Diallo for the guidance, insight and direction she has provided me with. Furthermore, I want to thank Edward van Meeuwen for his useful tips. Last but not least, I want to thank my family and friends for their support in this final stage of my studies. 3

4 Management summary The goal of this research is to investigate the way pricing models of services can be incorporated in the service ontology, which has been developed by Baida et al. (2003). An ontology is a formal representation of a domain, and serves as an important tool in making domain knowledge machine-readable. In the context of this research, services are considered to be business activities, deeds and performances that often result in intangible outcomes or benefits. The aforementioned service ontology has been developed with the focus on service bundles to realize two goals, which will be discussed in the next two paragraphs. A service bundle is a package of two or more elementary (single) services, possibly offered by multiple suppliers. Pricing models were not incorporated in the first version of the service ontology, however, these play an important role in both goals. This will be explained for each goal. First goal: The realization of complex online service offerings (e-services) E-services are considered to be services (as described in the first paragraph) where the Internet is used as a channel to interact with customers. Nowadays, businesses offer their services more and more via Internet, either parallel to or instead of the traditional channels. Statistics show an immense growth in the percentage of households with Internet access that actually shop online. These statistics also show the dominant and growing role and the importance of e-services in a variety of industries. In the first goal, supply side and also demand side business logics are used to make the decision to offer certain e-services (single or bundled) to a customer. Information on the price of a service, which is present in the pricing model, is required for selling that service. Thus, when pricing models are incorporated in the service ontology, a business can sell e-services by employing this ontology. Second goal: Performing business analyses of e-service bundles for networked enterprises In order to perform such analyses, the design and assessment of a business model is required. In other research, a conceptual modeling approach has been developed, which helps reach a better understanding of the business model and enables an assessment of the profitability of the suggested models. This modeling approach is expressed in an ontology, which is used together with the service ontology in order to achieve the second goal. In this goal, the service ontology is necessary to design feasible service bundles. When these two ontologies are used together and pricing models are incorporated in the service ontology, it is possible to calculate the eventual cash flow when performing business analyses of e-service bundles for networked enterprises. In this research, a proposal to incorporate pricing models of both elementary (single) services and service bundles in the service ontology is discussed. The above mentioned goals highlight the importance of incorporating pricing models in the service ontology: selling e-services and calculating the eventual cash flow when performing business analyses of e-service bundles for networked enterprises. 4

5 Table of contents PREFACE 3 ACKNOWLEDGEMENTS 3 TABLE OF CONTENTS 5 CHAPTER I INTRODUCTION PROBLEM STATEMENT DEFINITIONS THE GOAL RESEARCH METHODOLOGY 9 CHAPTER II LITERATURE OVERVIEW PRICING MODELS OF ELEMENTARY SERVICES PRICING MODELS OF ELEMENTARY SERVICES IN GENERAL PRICING MODELS OF VARIOUS SPECIFIC ELEMENTARY SERVICES PRICING MODELS OF INFORMATION GOODS GROUPING OF THE PRICING MODELS OF ELEMENTARY SERVICES PRICING OF SERVICE BUNDLES THE STRATEGY OF BUNDLING PRICING MODELS OF SERVICE BUNDLES EXAMPLES OF PRICING MODELS OF SERVICE BUNDLES FROM PRACTICE TWO WAYS TO CALCULATE THE PRICE OF SERVICE BUNDLES MATHEMATICAL REPRESENTATION OF THE PRICING MODELS ANALYSIS OF A MATHEMATICAL FORMULA FORMULAS OF THE PRICING MODELS OF ELEMENTARY SERVICES AND SERVICE BUNDLES 25 CHAPTER III CASE STUDIES THE SINTEF CASE STUDY COMPARISON OF THE TEXTUAL REPRESENTATIONS COMPARISON OF THE MATHEMATICAL REPRESENTATIONS RESULTS OF THE SINTEF CASE STUDY THE SENA CASE STUDY COMPARISON OF THE TEXTUAL REPRESENTATIONS COMPARISON OF FORMULAS USED IN THE SENA CASE STUDY RESULTS OF THE SENA CASE STUDY CONCLUSIONS OF THE CASE STUDIES 37 CHAPTER IV THE ONTOLOGIES THE SERVICE ONTOLOGY THE SERVICE OFFERING PERSPECTIVE THE E³-VALUE ONTOLOGY THE E³-VALUE ONTOLOGY EXPLAINED USE CASE MAPS EXAMPLE OF A VALUE MODEL 49 5

6 CHAPTER V PROPOSAL TO INCORPORATE PRICING MODELS IN THE SERVICE ONTOLOGY WHY INCORPORATE PRICING MODELS IN THE SERVICE ONTOLOGY? RELATIONSHIPS OF THE MODEL PROPOSAL RELATIONSHIP BETWEEN THE PRICING MODEL CONCEPT AND THE PROPERTY CONCEPT RELATIONSHIP BETWEEN THE PRICING MODEL CONCEPT AND THE SERVICE PORT CONCEPT RELATIONSHIP BETWEEN THE PRICING MODEL CONCEPT AND THE SERVICE PORT CONCEPT WHEN DEALING WITH ELEMENTARY SERVICE ELEMENTS RELATIONSHIP BETWEEN THE PRICING MODEL CONCEPT AND THE SERVICE PORT CONCEPT WHEN DEALING WITH SERVICE BUNDLES RELATIONSHIP BETWEEN PRICING MODEL AND SERVICE PORT CONCEPT TO SUPPORT THE FIRST WAY TO CALCULATE THE PRICE OF SERVICE BUNDLES RELATIONSHIP BETWEEN THE PRICING MODEL CONCEPT AND THE LINK CONCEPT RELATIONSHIP BETWEEN PRICING MODEL AND LINK CONCEPT TO SUPPORT THE SECOND WAY TO CALCULATE THE PRICE OF SERVICE BUNDLES EXTENSION OF THE MODEL PROPOSAL INCLUDING USEFUL INFORMATION ABOUT THE DIFFERENT TYPES OF PRICING MODELS KEY NOTES OF THE MODEL PROPOSAL MODEL PROPOSAL IN AN EARLIER STAGE OF THE RESEARCH 64 CHAPTER VI PROPOSAL TO INCORPORATE PRICING MODELS IN A SOFTWARE TOOL REASONING ABOUT THE PROPOSAL PROPOSAL TO INCORPORATE PRICING MODELS OF SERVICE ELEMENTS THAT ARE PART OF A SIMULATED SERVICE BUNDLE FIRST FUNCTIONALITY: SIMULATE BUNDLE SECOND FUNCTIONALITY: EDIT/ASSIGN PRICING MODELS OF SERVICE ELEMENTS THAT ARE PART OF A SIMULATED BUNDLE REPRESENTATION OF AND THE VALUES USED IN THE PRICING MODELS MAPPING BETWEEN SIMULATED AND CONFIGURED SERVICE BUNDLES ALGORITHM TO CALCULATE PRICES OF BOTH ELEMENTARY SERVICE ELEMENTS AND SERVICE BUNDLES IN THE SERVICE TOOL 70 CHAPTER VII MAPPING BETWEEN THE SERVICE ONTOLOGY AND THE E³-VALUE ONTOLOGY MAPPING FROM THE SERVICE ONTOLOGY TO THE E³-VALUE ONTOLOGY MAPPING OF AN ELEMENTARY SERVICE ELEMENT INTO THE E³-VALUE ONTOLOGY MAPPING OF A SERVICE BUNDLE INTO THE E³-VALUE ONTOLOGY CONCLUSIONS OF THE MAPPING FROM THE SERVICE ONTOLOGY TO THE E³-VALUE ONTOLOGY MAPPING FROM THE E³-VALUE ONTOLOGY TO THE SERVICE ONTOLOGY MAPPING OF AN ELEMENTARY ACTOR INTO THE SERVICE ONTOLOGY MAPPING OF A COMPOSITE ACTOR INTO THE SERVICE ONTOLOGY CONCLUSIONS OF THE MAPPING FROM THE E³-VALUE ONTOLOGY TO THE SERVICE ONTOLOGY PROBLEMS WITH PRICING MODELS IN THE E³-VALUE ONTOLOGY 84 CHAPTER VIII VALIDATION VALIDATION PROCESS VALIDATING THE FINDINGS OF THE LITERATURE OVERVIEW VALIDATING THE REPRESENTATIONS OF THE PRICING MODELS OF ELEMENTARY SERVICES VALIDATING THE REPRESENTATIONS OF THE PRICING MODELS OF SERVICE BUNDLES VALIDATING THE MODEL PROPOSAL TO INCORPORATE PRICING MODELS IN THE SERVICE ONTOLOGY 90 6

7 8.3.1 VALIDATING THE MODEL PROPOSAL FOR ELEMENTARY SERVICE ELEMENTS VALIDATING THE MODEL PROPOSAL FOR SERVICE BUNDLES CONCLUSIONS OF THE VALIDATION 98 CHAPTER IX CONCLUSION 100 LIST OF FIGURES 101 LIST OF TABLES 102 REFERENCES 103 7

8 Chapter I Introduction 1.1 Problem statement Core elements of this research are pricing models and version 1.0 of the service ontology developed by Baida et al. (2003). The service ontology formally describes a shared view on what services are and aims to compose (or: configure) complex services out of more elementary (single) services possibly supplied by different suppliers. Version 1.0 of this ontology does not support pricing models. However, it is reasonable to assume that if a service has no price, it cannot be sold. The price of an elementary service may depend on the amount consumed (usage-based pricing model), or consist of a fixed amount plus an additional usage based charge (two-part tariff pricing model). When services are bundled, the resulting bundle may have a different price than the sum of the prices of the services that are part of the bundle. This is one of the reasons to bundle services. Consider the following cases: If a customer buys KWh of electricity per year, he pays M euros. However, if he buys KWh per year as a bundle, he will only pay 1.8 x M, instead of 2 x M. Service X costs 1000, service Y costs 1500, and service Z costs If X is bundled with Y, the price of X will be 800 instead of However, if X is bundled with Z, the price of X will be 700 instead of Therefore, the following problem is formulated: Version 1.0 of the service ontology does not suppor t the modeling of pricing models of both elementary services and service bundles, while these models are necessary to reason about the price and the selling of these services. In this research, the types of pricing models of services and the way they are constructed is examined. Moreover, it is verified if they are representative for services in practice. These two aspects serve as a basis to find a suitable proposal to incorporate pricing models in version 1.0 of the service ontology. 1.2 Definitions This section gives the definitions of frequently used terms throughout this research. Pricing model and pricing strategy A pricing model is a representation of the way a company plans to set its prices (Daly 2002). In other words, a pricing model is a representation of the way a price is derived, and is closely related to a pricing strategy. According to Lovelock (2001), the foundations of a pricing strategy are costs, competition and value to the customer. Lovelock (2001) further states that the price of a service must be based on these three elements. The upper limit of the price is determined by the value to the customer, while the lower limit of the price is determined by the organizational costs. The price charged by the competitors should also be taken into account. Thus, the price of a service is derived from a pricing model, and the price must be set between the limits that are determined by the pricing strategy. 8

9 Service and product The interpretation of the term service used in this research is business activities, deeds and performances that often result in intangible outcomes or benefits, as described in various textbooks about service management and marketing (Grönroos 2000, Kotler 1988, Lovelock 2001, Zeithaml and Bitner 1996). Some examples of services are insurances, transportation, Internet access and conference organizing. According to Payne (1993), when discussing products and services there is often confusion over terminology. Payne (1993) defines a product as an overall concept of objects or processes which provide some value to customers. Goods and services are subcategories which describe two types of products. Therefore, the term product is frequently used in a broad sense to indicate manufactured goods and services. In this research, the term product refers to both services and manufactured goods. Bundling and service bundle Bundling is defined as the practice of marketing two or more goods or services in a single package for a special price (Guiltinan 1987). Furthermore, a service bundle is a package of two or more elementary (single) services (Grönroos 2000), which can possibly be offered by different suppliers. 1.3 The goal The problem statement is the initiation of this research. Solving this problem requires knowledge of what types of pricing models of services there are and the way they are constructed. The goal of this research is to investigate the way pricing models of services can be incorporated in the service ontology. 1.4 Research methodology An extensive study of the services marketing literature, with the focus on pricing, was conducted to gain more insight in what types of pricing models of services there are, and the way they are constructed. This literature yielded very little information on the way service bundles are priced in practice. Therefore, examples from practice were used to gain a better grip on that subject. All these findings generated input for the main issue of this research: investigating the way to incorporate pricing models in the service ontology. In an earlier phase of the research, a model proposal was suggested, but it was soon discovered that this approach had several shortcomings. A second and more elaborate proposal was developed in a later stage, which yielded very fruitful results. This proposal was validated by testing if the results from the literature study were representative for services in practice, and if pricing models of these services can be modeled in accordance with the model proposal. 9

10 Chapter II Literature overview In order to incorporate pricing models in the service ontology, it is necessary to understand what types of pricing models of services there are and the way they are constructed. This chapter presents an overview of pricing models of services, which is based on the services marketing literature with the focus on pricing. The first section will discuss pricing models of elementary (single) services, and information goods. The studied literature discusses different types of pricing models of elementary services which are often referred to with different names, although their representations are similar. As a result, the second section will describe a grouping of these pricing models. This will be followed by the third section that will discuss pricing models of service bundles. The fourth and final section will describe the mathematical representations of the most broadly used types of pricing models of services (elementary and bundled). 2.1 Pricing models of elementary services Pricing models of elementary services in general Dolan and Simon (1996) discuss the following pricing models: Two-part tariff: consists of a fixed price and an additional price per unit. This form is typical for a telephone company offering a fixed price and a price per service unit. Another example is a purchasing club, where members pay an annual membership fee and can buy services at a lower price. Two-block tariff: a price per unit (p) is charged for any units, up to a certain quantity (q2), and then the price per-unit changes to (p2) for all units greater than (q2). The two-block tariff model is often used in transportation and utility services. Different variant of two-block tariff (with two two-part tariffs combined): each of the two blocks has a fixed and variable price component. This pricing model is often used by mobile providers and utilities. For example, an electricity supplier can offer the following options: o Tariff A has a fixed price of 4.0 and a variable part of 0.6 per o 100 kwh Tariff B has a fixed price of 10.0 and a variable part of 0.2 per 100 kwh According to Dolan (1987), the n-block tariff (with n > 2) pricing model is defined similar to the two-block tariff model. Simkovich (1998) mentions the multi-dimensional pricing model, and argues that it is often used by telephone companies. In this pricing model, the customer no longer pays a single price for the service, but two or more prices: a flat monthly fee plus a certain price per unit. Daly (2002) states that an activity based pricing model (ABPM) is developed to help management determine the real costs of a product, in order to establish a suitable price. According to Daly (2002), ABPM is used by service businesses which offer professional services such as accountancy, consultancy and audits. These service businesses often use a pricing model based on a work program list of the tasks to be performed, a list of the hours required to perform each task and a different billing rate for each type of personnel involved with the task. Daly (2002) further states that ABPM has not yet been adopted by many service businesses. 10

11 Berends (2004) gives a view on several pricing models of services: Fixed price: a fixed price for a certain service. Commission: a commission is a percentage fee or fixed fee that is paid only if a service is successful. Time and material: the actual cost of labor and material is paid according to agreed labor rates and material costs. For example, a cable TV repair service is based on /hour plus additional fixed price for cables, switches, etc. In order to facilitate reasoning about the described pricing models, it is useful to make an overview. Below is an overview of the previously discussed pricing models. Table 1: Pricing models of elementary services in general Pricing model Two-part tariff (Dolan and Simon 1996) Two-block tariff (Dolan and Simon 1996) Two-block tariff (with two two-part tariffs combined) (Dolan and Simon 1996) Multi-dimensional pricing (Simkovich 1998) Activity based pricing model (Daly 2002) Fixed price (Berends 2004) Commission (Berends 2004) Time and material (Berends 2004) Description A fixed price and an additional price per unit. A price per unit (p) is charged for any units, up to a certain quantity (q2), and then the price per-unit changes to (p2) for all units greater than (q2). Each of the two blocks has a fixed and a variable price component. A flat monthly fee plus a varying price per unit is charged. Consists of a work program list of the tasks to be performed, a list of the hours required to perform each task and a different billing rate for each type of personnel involved with the task. A fixed price for a certain service. A percentage fee or fixed fee that is paid only if a service is successful. Actual cost of labor and material is paid according to agreed labor rates and material costs Pricing models of various specific elementary services This section gives an overview of pricing models used for more specific elementary services. These pricing models are also discussed to obtain a broader view on the different types of pricing models that are applicable for elementary services. Pricing models of various services such as Internet access, music, and telephone According to Essegaier, Gupta and Zhang (2002), telecommunication, fitness club and Internet access services often use one or more of the following pricing models: Flat fee pricing: the user pays a fixed amount to gain access. Usage based pricing: the user is charged on the basis of actual usage. Two-part tariff pricing: this is a combination of the former two models in which the user pays a fixed price to gain access plus a price based on actual usage. 11

12 Choi, Stahl and Whinston (1997) argue that services such as cable TV, telephone and Internet access are often sold by subscription. In addition, subscription based services are often priced at a flat rate, with no control over consumer usage. Looking at pricing models for Internet access, McKnight and Bailey (1995) highlight two different models: Flat fee or subscription: user pays a fixed amount to get access. Usage sensitive: user pays a portion of the Internet bill for a connection and a portion of each bit sent and received. Looking further at pricing models for Internet access, Odlyzko (2001) discusses the flat rate pricing model, where the user pays a fixed amount, and the usagesensitive pricing model, where the user is charged on the basis of usage. Furthermore, Choi, Stahl & Whinston (1997) argue that flat-rate pricing is the most common pricing model for Internet access. They state that flat rate pricing consists of a fee for a certain bandwidth usage that is independent of the actual usage. Wu, Chen and Anandalingam (2002) argue that the flat fee, usage based and two-part tariff are three commonly used pricing models of services such as software application services provided by an online ASP over the Web, online discounted brokerage, SMS and WAP services. Looking at pricing models used for online music access services, Bhattacharjee and Gopal (2003) state that most online music access services mirror almost the same pricing models as traditional brick-andmortar stores, in which consumers select and then pay a per-unit price for a music item. They further specify the following online pricing models: Per-unit pricing: per unit price for a digital music item. Subscription model: a flat-rate price for a subscription service. A subscribing consumer has access to all music items, and may download and own the items as desired. Online mixed option model: the provider offers a choice of the per-unit and/or subscription pricing model. MacKie-Mason and Riveros (1997) discuss two pricing models for electronic access to scholarly literature. The first pricing model discussed is the per-article model, in which a user can buy unrestricted access to a specific article for a fixed price. The second model is traditional subscription, where a user or library can buy unlimited access to a set of articles in a journal volume. The following table gives an overview of the discussed pricing models of various specific services. Table 2: Pricing models of various specific elementary services Pricing model Flat fee pricing (Essegaier et al. 2002), (Wu et al. 2002) Usage based pricing (Essegaier et al. 2002), (Wu et al. 2002) Two-part tariff pricing (Essegaier et al. 2002), (Wu et al. 2002) Flat rate (Choi et al. 1997) Subscription (Choi et al. 1997) Flat fee or subscription (McKnight and Bailey 1995) Description The user pays a fixed amount to gain access. The user is charged on the basis of actual usage. This is a combination of the former two models in which the user pays a fixed price to gain access plus a price based on actual usage. Fee for a certain usage that is independent of the actual usage. Flat rate independent of usage. User pays a fixed amount to get access. 12

13 Pricing model Usage sensitive (McKnight and Bailey 1995) Flat rate (Odlyzko 2001) Usage-sensitive Odlyzko 2001) Per-unit pricing (Bhattacharjee and Gopal 2003) Subscription model (Bhattacharjee and Gopal 2003) Online mixed option model (Bhattacharjee and Gopal 2003) Per-article (MacKie-Mason and Riveros 1997) Traditional subscription (MacKie-Mason and Riveros 1997) Description User pays a portion of the Internet bill for a connection and a portion of each bit sent and received. The user pays a fixed amount. The user is charged on the basis of usage. Per unit price for a digital music item. A flat-rate price for a subscription service. The provider offers a choice of the per-unit and/or subscription pricing model. A user can buy unrestricted access to a specific article for a fixed price. A user or library can buy unlimited access to a set of articles in a journal volume. Pricing models of professional services According to Kotler and Bloom (1984), there are several pricing models that are used for professional services: Time and expenses: fees are set by multiplying the number of hours/days of professional service provided by an hourly/daily billing rate and then adding fixed expenses incurred by the professionals for materials, travel, etc. Fixed sum: fees are set at some fixed amount prior to providing services. Percentage: fee is set as a percentage of some value. For example, advertising agencies receive a commission of 10 percent on the media space purchased for their client. Travel agents receive a 20 percent commission on the value of the travel they arrange. Retainer: fees are set prior to a covered time period during which the client receives a predetermined level of service without paying any extra fees. Hybrid: fees are determined by using a combination of the time and expenses, fixed sum, percentage and/or retainer pricing models of professional services. Gummesson (1981) argues that there is no commonly accepted definition of professional services. However, the author gives a more general definition which consists of the following criteria. First of all, the service should be provided by qualified personnel, be advisory and focus on problem solving. Second of all, the professional should have an identity and thus be known under a specific name such as consultant or lawyer. Third of all, the service should be assigned from buyer to seller. Finally, the professional should be independent of suppliers of other services. Examples of professional services are public relation consultancy, management consultancy, auditor and lawyer. The following table gives an overview of the discussed pricing models of professional services. 13

14 Table 3: Pricing models of professional services Pricing model Time and expenses (Kotler and Bloom 1984) Fixed sum (Kotler and Bloom 1984) Percentage (Kotler and Bloom 1984) Retainer (Kotler and Bloom 1984) Hybrid (Kotler and Bloom 1984) Description Fees are set by multiplying the number of hours/days of professional service provided by an hourly/daily billing rate and then adding fixed expenses incurred by the professionals for materials, travel, etc. Fees are set at some fixed amount prior to providing services. Fee is set as a percentage of some value. Fees are set prior to a covered time period during which the client receives a predetermined level of service without paying any extra fees. Fees are determined by using a combination of the time and expenses, fixed sum, percentage and/or retainer pricing models of professional services. Pricing models of water services Water services can be priced by using marginal cost pricing (Dewees 2002). In this pricing model, the user pays a fee that is based on usage plus the marginal costs that are associated with that usage. Marginal cost is defined as the increase or decrease in costs as a result of one more or one less unit of output 1. Dewees (2002) highlights other pricing models of utility services: Two-part tariff: consists of a subscription fee for access to the service and an additional price for each unit purchased. Time-Of-Use pricing (TOU): price is set according to peak demand at specific times of day. Seasonal pricing: different rates are used during different seasons of the year. The OECD (1987) highlights several pricing models of piped water services (water supply, sewerage and sewage treatment). These models are: Flat rate: a flat rate is charged for the use of water services, the fees are not directly related to quantities of water used. Charges can be based on different aspects like the number of residents, number and type of rooms, number of taps, etc. Average cost pricing: to generate a unit cost, all water services costs (except access costs) are grouped together and divided among the total number of units expected to be sold. Declining block tariffs: consist of a fixed charge and succeeding blocks of units of water are sold at declining prices. Increasing or progressive block tariffs: consist of a fixed charge and succeeding blocks of units of water are sold at increasing prices. Two-part tariff: consists of a fixed element and a charge based on usage. Marginal cost pricing: in this model, the price reflects the incremental costs to the community of satisfying marginal demands. Incremental costs are defined as quantitative and qualitative resource depletion costs, damage costs and various capital and operating resource costs. In other words, the 1 (Last visited May 2005) 14

15 price of a liter of water used or disposed of would be equal to the marginal cost of providing that water service. The following table gives an overview of pricing models that are used for water services. Table 4: Pricing models of water services Pricing model Flat rate (OECD 1987) Average cost pricing (OECD 1987) Declining block tariffs (OECD 1987) Increasing or progressive block tariffs (OECD 1987) Two-part tariffs (OECD 1987) Marginal cost pricing (OECD 1987) Two-part tariff (Dewees 2002) Time-of-use pricing (Dewees 2002) Seasonal pricing (Dewees 2002) Marginal cost pricing (Dewees 2002) Description Flat rate for the use of water services. To generate a unit cost, all water services costs (except access costs) are grouped together and divided among the total number of units expected to be sold. Consist of a fixed charge and succeeding blocks of units of water sold at declining prices. Consist of a fixed charge and succeeding blocks of units of water sold at increasing prices. Consists of a fixed element and a charge based on usage. The price reflects the incremental costs to the community of satisfying marginal demands. Consists of a subscription fee for access to the service and an additional price for each unit purchased. Price is set according to peak demand at specific times of day. Different rates are used during different seasons of the year. The user pays a fee that is based on usage plus the costs that are associated with that usage. Pricing models of electricity services Pricing models of both regulated and de-regulated electricity markets are discussed below. Dewees (2001) argues that competitive, de-regulated electricity markets have generally produced pricing models similar to those that are being used in a regulated market. Borenstein (2001), and Borenstein et al. (2002) highlight two different pricing models that are used in a de-regulated market: Real-Time Pricing (RTP): charges are based on different retail electricity prices for different hours of the day and for different days. The retail price under RTP could be based on the wholesale price. Borenstein and Holland (2002) state that RTP is commonly referred to as peak-load pricing in other literature. Time-Of-Use pricing (TOU): price varies in a preset way within certain blocks of time. For example, weekdays 0,4$/KWh from 10pm to 6am and 0.7$/KWh from 6am to noon. TOU is often combined with demand charges: a monthly charge based on the customer's maximum usage during the month. It is a way to charge for a customer's peak usage. Dewees (2001) further mentions that a fixed pricing model is used in a deregulated competitive electricity market where the price is set at the weighted average expected spot price. The spo t price is the present delivery price of a given commodity being traded on a spot market. In such a market, commodities as crude oil or electricity are bought and sold for cash and delivered immediately. 15

16 Pricing models that are used for electricity services in a regulated electricity market are also discussed by Dewees (2001). He mentions three pricing models: Peak-load-pricing: see Real-Time Pricing Time-Of-Use pricing: charges vary at different times of day according to a fixed schedule. The price differs in each period/block: peak, semi-peak, offpeak. Seasonal plan: the price varies between seasons in accordance with the expected seasonal variation in the spot price. The table below gives an overview of pricing models that are used to price electricity services. Table 5: Pricing models of electricity services Pricing model Real-Time Pricing (Borenstein 2001), (Borenstein et al. 2002) Time-Of-Use pricing (Borenstein 2001), (Borenstein et al. 2002), (Dewees 2001) Fixed price (Dewees 2001) Seasonal plan (Dewees 2001) Peak-load-pricing (Dewees 2001) Description Charges are based on different retail electricity Prices for different hours of the day and for different days. Price varies in a preset way within certain blocks of time. The price is set at the weighted average expected spot price. The price varies between seasons in accordance with the expected seasonal variation in the spot price. see Real-Time Pricing The previous two sections present an overview of the pricing models of elementary services. The grouping of these pricing models will be described in section 2.2, after the pricing models of information goods are discussed Pricing models of information goods A broadly accepted definition of information goods is anything that can be digitized (Shapiro and Varian 1999). Examples are text, images, voice, data, audio, video, electronic journals, software, etc. The reason why information goods are discussed in this literature overview is because these goods are often related to services, which are offered online. A simple example illustrates this relation: a consumer can purchase a journal article online, but access to the article itself is in fact a service. This relation makes it worthwhile to briefly discuss pricing models of information goods. According to Fishburn and Odlyzko (1997), a flat-rate and a usage-based pricing model can be applied to information goods. In the former model, a fixed price was paid to purchase the goods and in the latter model, charges are based on usage. Brooks and Durfee (2000) consider three different pricing models of information goods. The first model discussed is per-good pricing, where the consumer pays a fixed price for each good. The second model is two-part tariff, in which the consumer pays an admission fee and a price for each good. The third model is nonlinear pricing, where the consumer pays a different price for each good as the 16

17 number of units purchased increase. Sundararajan (2004) makes mention of different pricing models for several types of information goods. Among these are: Nonlinear usage based pricing for software: the price is based on the total processing speed of the servers on which the software runs. Fixed-fee pricing models for different types of information goods (such as an online news and music): the user pays a fixed price that is independent of the usage. Two-part tariff pricing: a combination of the fixed-fee and usage based pricing model. Cox (2002) identified three different pricing models to purchase online journal articles. The author speaks of a simultaneous user pricing model in which the price is linked to an assumed level of usage. Then there is mention of the population-based pricing model, where the price is based on full-time equivalents (FTE s). FTE s are defined as full time enrollments in education or the number of employees in an organization. This pricing model consists of a fixed payment to gain access for a certain group of FTE s. Cox also gives his view on usage-based pricing, where the user is only charged on usage. Table 6 gives an overview of pricing models that are applicable for information goods. Table 6: Pricing models of information goods Pricing model Flat-rate (Fishburn and Odlyzko 1997) Usage-based (Fishburn and Odlyzko 1997) Per-good pricing (Brooks and Durfee 2000) Two-part tariff (Brooks and Durfee 2000) Nonlinear pricing (Brooks and Durfee 2000) Nonlinear usage based pricing for software (Sundararajan 2004) Fixed-fee (Sundararajan 2004) Two-part tariff (Sundararajan 2004) Simultaneous user pricing (Cox 2002) Population-based pricing (Cox 2002) Usage-based pricing (Cox 2002) Description A fixed price is paid to purchase the goods. Charges are based on usage. The consumer pays a fixed price for each good. The consumer pays an admission fee and a price for each good. The consumer pays a different price for each good. The price is based on the total processing speed of the servers on which the software runs. User pays a fixed price that is independent of the usage. A combination of the fixed-fee and usage based pricing model. The price is linked to an assumed level of usage. Consists of a fixed payment to gain access for a certain group of FTE s. The user is only charged on usage. 17

18 2.2 Grouping of the pricing models of elementary services A pricing model is defined as a representation of the way a company plans to set its prices (Daly 2002). The representations of the pricing models that are discussed in the previous sections are textual. From the overview of pricing models of elementary services, it can be concluded that there are different types of pricing models which are often referred to with different names, although their representations are similar. This section describes a grouping of those pricing models. This grouping is based on the representations of the four most broadly used types of pricing models of elementary services. The pricing models of information goods will also be included in the grouping to see if these models are applicable for elementary services. The textual representation of the four most broadly used types of pricing models of elementary services are described in the table below. From this point forth in this research, the fou r most broadly used types of pricing models o f elementary services are referred to as the four types o f pricing models of elementary services. Table 7: Textual representation of the four types of pricing models of elementary services Pricing model Flat-rate Usage-based Two-part tariff N-block tariff (with n = 2) Formula The user pays a fixed amount which is independent of usage. The user is charged on basis of usage. The user pays a fixed amount plus an additional usage based charge. A price per unit (p) is charged for any units, up to a certain quantity (q2), and then the price per-unit changes to (p2) for all units greater than (q2). Remark: the n-block tariff with n > 2 is defined similarly. The grouping of the pricing models of elementary services is displayed in the table below. Table 8: Grouping of the pricing models of elementary services Flat-rate Usage-based Two-part tariff N-block tariff (with n 2) Fixed price (Berends 2004), (Dewees 2001) Online mixed option model (Bhattacharjee and Gopal 2003) Per-article (MacKie-Mason and Riveros 1997) Fixed sum (Kotler and Bloom 1984) Flat rate (Choi et al. 1997), (OECD 1987), (Odlyzko 2001) Usage based (Essegaier et al. 2002), (Wu et al. 2002), (Odlyzko 2001) Online mixed option model (Bhattacharjee and Gopal 2003) Usage sensitive (McKnight and Bailey 1995) Per-unit pricing (Bhattacharjee and Gopal 2003) Information goods: Usagebased (Fishburn and Odlyzko 1997), (Cox 2002) Two-part tariff pricing (Essegaier et al. 2002), (Wu et al. 2002), (Dewees 2002), (OECD 1987), (Dolan and Simon 1996) Hybrid (Kotler and Bloom 1984) Time and expenses (Kotler and Bloom 1984) Time and material (Berends 2004) Multi-dimensional pricing (Simkovich 1998) Two-block tariff (with two two-part tariffs combined) (Dolan and Simon 1996) Declining block tariffs (OECD 1987) Seasonal pricing model (Dewees 2001, 2002) Real-Time Pricing (Borenstein 2001), Borenstein et al. 2002), (Dewees 2001) Increasing or progressive block tariffs (OECD 1987) 18

19 Flat-rate Usage-based Two-part tariff N-block tariff (with n 2) Commission (Berends 2004) Information goods: Nonlinear usage based pricing for software (Sundararajan 2004) Information goods: twopart tariff (Brooks and Durfee 2000), (Sundararajan 2004) Two-block tariff (Dolan and Simon 1996) Subscription (Choi et al. 1997), (McKnight and Bailey 1995), (Bhattacharjee and Gopal 2003), (MacKie-Mason and Riveros 1997) Flat fee pricing (Essegaier et al. 2002), Wu et al. 2002), (McKnight and Bailey 1995) Retainer (Kotler and Bloom 1984) Percentage (Kotler and Bloom 1984) Hybrid (Kotler and Bloom 1984) Information goods: Flatrate (Fishburn and Odlyzko 1997) Information goods: Fixed-fee (Sundararajan 2004) Information goods: Population-based pricing (Cox 2002) Information goods: Simultaneous user pricing (Cox 2002) Information goods: per-good pricing (Brooks and Durfee 2000) Time-Of-Use pricing (Dewees 2002), (Borenstein 2001, Borenstein et al. 2002), (Dewees 2001) Information goods: Nonlinear pricing (Brooks and Durfee 2000) The grouping highlight that the pricing models of information goods can be grouped under the four types of pricing models of elementary services. This means that the pricing models of information goods are also applicable for elementary services (offered online), which further acknowledges their close relation. There are some pricing models which cannot be grouped under one of the four types of pricing models. These are: Average cost pricing (OECD 1987), Marginal cost pricing (OECD 1987), (Dewees 2002), and Activity based pricing (Daly 2002). These are very specific pricing models of elementary services since they do not occur often in the studied literature. 2.3 Pricing of service bundles As stated in section 1.2, a service bundle is a package of two or more elementary (single) services (Grönroos 2000), which can possibly be supplied by different suppliers. The studied literature mostly discusses pricing strategies when looking at the ways to price service bundles. However, the focus of this research is on pricing models of services and not on pricing strategies of services. A pricing model is a representation of the way a price is derived. According to Lovelock (2001), the foundations of a pricing strategy are costs, competition and value to the customer. 19

20 A pricing model is closely related to a pricing strategy, because the price of a service must be set between the limits that are determined by the pricing strategy, and the price itself is derived from a pricing model. Due to this relation, this section will discuss pricing strategies of bundling to obtain more insight in the constructions of pricing models used for service bundles. This section will also discuss the few variants of pricing models that are mentioned in the literature. Additionally, examples of the way service bundles are priced in practice are also used to obtain more insight in the constructions of pricing models used for service bundles. This section ends with a description of two pricing models that are applicable for service bundles. These are derived from the studied literature and examples from practice The strategy of bundling The strategy of bundling products into a single package is broadly known in the literature, and widely used in many industries. Yet, there is no consensus on how to define the term bundling (Stremersch and Tellis 2002). In spite of the lack of a common definition, most definitions share a common core, as defined by Stremersch and Tellis (2002): bundling is the sale of two or more separate products in one package (in their discussion on pricing and bundling strategies, the researchers make a distinction between product bundling and price bundling, which is beyond the scope of the current discussion). Another well-accepted definition is given by Guiltinan (1987), who also refers to the price of a bundle in his definition: bundling is the practice of marketing two or more goods or services in a single package for a special price. In addition to this definition, Dolan and Simon (1996) identified an exception for bundling, since they state that a discount is not a necessary condition for bundling. They name an example in which the complete set of collector s items can be much more expensive than the sum of the individual components of the set. However, in most studied literature, the strategy of bundling is applied in accordance with the definition given by Guiltinan (1987). Therefore, this research also applies the strategy of bundling in accordance with that definition. Adams and Yellen (1967) discuss two forms of bundling, namely pure bundling and mixed bundling. Pure bundling is combining two or more goods or services, not sold separately, into a single package (also see Bakos and Brynjolfsson 1999). Mixed bundling is combining two or more goods or services, also sold separately, into a single package. Furthermore, there are two variants of mixed bundling (Guiltinan 1987): Mixed-leader bundling: the price of one of the two services is discounted when the other service (the leader service) is purchased at the regular price (also see Kasper et al. 1999, Kurtz and Clow 1998). Mixed-joint bundling: the bundle price is lower than the individual prices of the services, which are part of the bundle (also see Kasper et al. 1999, Kurtz and Clow 1998). Dolan and Simon (1996) describe the multi-person pricing strategy, in which price discounts are awarded to an additional person who buys the same service. Typical industries which use this kind of pricing strategy are airlines and hotels. Furthermore, Hitt and Chen (2004) consider the customized bundle pricing strategy to price bundles of information goods and services. In customized bundling, the consumer has the right to choose up to a quantity of M services from a 20

21 larger pool of N services for a fixed discounted price. This pricing strategy corresponds with individual selling when M=1, and pure bundling when M=N. The table below gives an overview of the discussed pricing strategies for service bundles. Furthermore, Hanson and Martin (1990) discuss a methodology for developing a bundling strategy for a product line consisting of a large number of items. The methodology consists of a mixed integer linear programming algorithm for determining the profit-maximizing set of bundles and bundle prices. Below is an overview of the different types of bundling strategies. Table 9: Overview of bundling strategies Bundling strategy Pure bundling (Adams and Yellen 1967) Mixed bundling (Adams and Yellen 1967) Mixed-leader bundling (Guiltinan 1987, Kasper et al. 1999, Kurtz and Clow 1998) Mixed-joint bundling (Guiltinan 1987, Kasper et al. 1999, Kurtz and Clow 1998) Multi-person pricing (Dolan and Simon 1996) Customized bundle pricing (Hitt and Chen 2004) Methodology for developing a bundling strategy (Hanson and Martin 1990) Description Combining two or more goods or services, not sold separately, into a single package Combining two or more goods or services, also sold separately, into a single package The price of one of the two services is discounted when the other service (the leader service) is purchased at the regular price The bundle price is lower than the individual prices of the services, which are part of the bundle Price discounts are awarded to an additional person who buys the same service The consumer has the right to choose up to a quantity of M products from a larger pool of N products for a fixed discounted price. This pricing strategy corresponds with individual selling when M=1 and pure bundling when M=N Methodology consists of a mixed integer linear programming algorithm for determining the profit-maximizing set of bundles and bundle prices Pricing models of service bundles The few variants of pricing models that are mentioned in the literature are described in this section. Dolan and Simon (1996) discuss the all-units quantity discount pricing model to price a bundle of services. The all-units quantity discount pricing model is described as follows: when a certain quantity level is exceeded, a discounted price is applied to all units. The authors describe an example of this pricing model in which a fitness centre offers exercise services and charges 6 for one session, 50 for ten sessions ( 5 per session) and 90 for 20 sessions ( 4.5 per session). Theaters and telephone companies often have a similar pricing model for subscribers. Altinkemer (2001) describes an example in which a two-part tariff pricing model is applied for a service bundle. This pricing model consists of a fixed part, plus an additional price per unit. In the example of Altinkemer (2001), a company offering electronic payment bundles, charges $8.95 per month for a bundle of up to 25 electronic payments, plus 50 cents per transaction above that. The price of the bundle is lower than the total price of the electronic payments when these are purchased separately. Table 10 gives an overview of the discussed pricing models of service bundles. 21

22 Table 10: Pricing models of service bundles Pricing model All-units quantity discount (Dolan and Simon 1996) Two-part tariff (Altinkemer 2001) Description When a certain quantity level is exceeded, a discounted price is applied to all units. The price of the bundle consists of a fixed part, plus an additional price per unit. The price of the bundle is lower than the total price of the services that are part of the bundle when these are purchased separately Examples of pricing models of service bundles from practice In the literature not many variants of pricing models of service bundles are discussed. Therefore, examples of the way service bundles are priced in practice are used to get more insight in the constructions of pricing models used for service bundles. These examples may give more insight on the way the price of a service bundle is calculated. See the table below for some examples of service bundles from practice. The table also displays the corresponding pricing strategies. (All the links in the table were last visited in March 2005). Table 11: Examples of service bundles from practice Type of services TV, telephone and Internet Dialup and hosting DSL Internet and TV Internet, Telephone and Cable TV Phone, digital TV and broadband Internet TV and radio Rental services Description of service bundle A customer can choose to bundle TV, telephone and Internet services. The bundle is sold as a subscription for a fixed price per month. The price is discounted with a fixed amount when the services are bundled. The discount is higher when all three services are part of the bundle. A customer can purchase a bundle of dialup and hosting services for a fixed price, and receive 10% discount on both services. A customer can purchase a subscription consisting of Internet and TV services. The bundle is sold for a fixed price per month, and the customer saves up to $10 every month for bundling the services. %20DSL%20Internet%20TV%20Bundle?opendocument&~v1=_is A customer can purchase a subscription consisting of a bundle of Internet, telephone and Cable TV services. The bundle is sold for a fixed price per month. The customer can choose any two services and save up to $20 a month, or choose all three services and save $25 a month. All subscription services are sold as a bundle for a fixed discounted price. Both TV and radio subscription services are sold in a bundle for a fixed discounted price. Customers can choose different plans that enable them to simultaneously borrow N videos for a fixed price of p(n) dollars per month where multiple values of N are allowed (e.g. 2, 3, 4, 5, and 8). Pricing strategy Mixed bundling Mixed bundling Mixed bundling Mixed bundling Mixed bundling Pure bundling Customized bundle pricing 22

23 Type of services Newspaper access Congress and exposition Description of service bundle Customers have four options to pay for a subscription to gain access to the newspaper archives: e.g. Sunday only access for $13.60, or $0.75 per article. Every second person of the same organization gets in for free at a congress and exposition. Courses When two persons enroll for a course, the second person gets 5% discount. When three persons enroll, the second person gets 5% and the third gets 10%. When four people enroll, the second person gets 5%, the third gets 10% and the fourth gets 15% ibm.com/services/learning/ites.wss/be/nl?pageType=page&cont entid=a Electricity A customer can bundle an electricity account with any or all of the other services - natural gas, internet or phone services for a fixed price per month. By bundling the services, the customer can save up to $230 on a 2-year contract. default.htm Pricing strategy Customized bundle pricing Multi-person pricing Multi-person pricing Mixed bundling The above examples do not give detailed information about the constructs of the pricing models used for the service bundles. Thus, the exact way in which the price of the service bundles from practice is calculated is still unknown. If the focus is not on the construction of the pricing models but more on the way the bundles are sold, then it can be concluded that the bundles are sold at a fixed price, often by a subscription. In the literature, it is also stated that service bundles are often sold at a fixed price. For example, Choi et al. (1997) argue that service bundles are often sold by subscription. Additionally they state that subscription based services are mostly priced at a fixed price. Shapiro and Varian (1999) also state that bundles of two or more products are sold at a fixed price. Furthermore, the examples from practice highlight that providers sell service bundles by giving a discount in either a fixed amount or by a percentage. Thus, it can be concluded that the service bundles from practice are sold at a fixed discounted price, often by subscription Two ways to calculate the price of service bundles The all-units quantity discount and the two-part tariff pricing models of service bundles (see section 2.3.2) are very specific pricing models of service bundles, given that they are not discussed elsewhere in the studied literature. The previous three sections, the studied literature (sections and 2.3.2), and examples from practice (section 2.3.3) do not give enough detailed information on the way the price of a service bundle is calculated. However, the recurring element in the sections is that a discount is applied to the price of a service bundle. The discount is either a fixed amount or a percentage. 23

24 If this discount is used as a starting point to calculate the price of a service bundle, it can be concluded that the price of a service bundle can be calculated in two ways. 1. First the individual price of each service element that is part of a service bundle has to be formulated. Then the price of the service bundle is calculated by applying a specific price discount, which is calculated from the combined prices of the service elements that are part of the bundle. This is derived from Tung et al. (1997). 2. First a discount is applied to the price of one or more service elements that are part of the service bundle. Then the price of the bundle is calculated by adding up these prices. This is derived from the mixed-leader pricing strategy. These two ways to calculate the price of service bundles are the pricing models of service bundles, which will be used throughout this research. The representations of these pricing models are different than those of the four types of pricing models of elementary services. The pricing models of service bundles consist of a discount, and of the outcomes of the pricing models of the services that are part of the bundle. These constructs are not present in the pricing models of elementary services. 2.4 Mathematical representation of the pricing models Up to this point, only textual representations of pricing models of services are considered. However, the representation can also be mathematical, in the form of a formula. A mathematical formula is needed to actually derive the price as a mathematical unit. The following section describes the way a formula is constructed in mathematics. The section after that gives an overview of the formulas of the four types of pricing models of elementary services, and the two types that are applicable for service bundles Analysis of a mathematical formula In mathematics 2, a formula is a fact, rule, or principle that is represented in terms of mathematical symbols. Examples of symbols are operands and operators. A formula consists of one or more expressions and every expression consists of at least one operand and can have one or more operators. An operand is a mathematical object upon which an operator acts. An operator is a symbol that represents a specific action. For example, a plus sign (+) is an operator that represents addition. The basic mathematic operators are addition (+), subtraction (- ), multiplication (x), division (/). Operators are ranked by precedence levels, which indicate that operators with a higher precedence level bind more strongly than those of a lower level. A formula can consist of a binary operation, which is an operation that applies to two expressions. The basic binary operations are: Addition: The combining of two or more quantities using the plus operator. The individual numbers being combined are called addends, and the total is called the sum. The first of several addends, or the one to which the others are added, is sometimes called the augend. The opposite of addition is subtraction. A sum is the result of an addition, and the numbers being 2 The mathematical descriptions are taken from (last visited April 2005) 24

25 summed are called addends. The summation operation can also be indicated using a capital sigma (Σ) with upper and lower limits written above and below, and the index indicated below. Sigma is defined as: n x i = xm + xm xm xn 1 + xn. i= m Here, i represents the index of summation: m is the lower limit of summation, and n is the upper limit of summation. Subtraction: Is the operation of taking the difference of two numbers p and q. Here, p is called the minuend, q is called the subtrahend, and the symbol between the p and q is called the minus sign. The expression p q is read p minus q. Subtraction is the inverse of addition. Multiplication: Is the process of calculating the result when a number p is taken q times. The result of a multiplication is called the product of p and q, and each of the numbers p and q is called a factor of the product p x q. The symbol x is known as the multiplication sign. Division: Taking the ratio p/q of two numbers p and q. Here, p is called the dividend, q is called the divisor, and p/q is called a quotient. The symbol "/" is called a solidus (sometimes, the "diagonal"). Division is the inverse operation of multiplication Formulas of the pricing models of elementary services and service bundles Below is an overview of the formulas of the four types of pricing models of elementary services. These formulas are derived from Dolan (1987). List of terms used in the formulas: C is the total charge to the customer. q and q_2 are usage amounts. Fix is a fixed price. p and p_2 are prices per quantity. Table 12: Formulas of the four types of pricing models of elementary services Pricing model Flat-rate Usage-based Two-part tariff N-block tariff (with n = 2) Formula C = Fix C = p x q C = Fix + p x q p x q (for: 0 q q_2) C = p x q_2 + p_2(q q_2) (for: q > q_2) Remark: the n-block tariff with n > 2 is defined similarly. The two ways to calculate the price of service bundles are discussed in section These two ways are the pricing models of service bundles. The formulas of these pricing models are presented in Table 13. In the table, type 1 is the formula of the first way to calculate the price of a service bundle, and type 2 of the second way. 25

26 List of terms used in these formulas: C is the total charge to the customer. PM_elem is the pricing model of an elementary service that is part of the bundle. discount is an amount that can be calculated as a fixed amount or as a percentage of the (total) price of elementary services that are part of the bundle. discount_elem is the discount of an elementary service that is part of the bundle. Table 13: Formulas of the two types of pricing models of service bundles Pricing model Type 1 Type 2 Formula n C = PM _ elem i= m n i= m i discount C = (( PM _ elemi ) ( discount _ elemi )) 26

27 Chapter III Case studies The reason to include case studies in this research is to see if the representations of the pricing models of services (elementary and bundled), which are described in the literature overview chapter, are representative for services in practice (i.e. to validate the theory). To realize this, the representations of these pricing models of services will be compared with pricing models of services from practice. Given that the representation of a pricing model can be textual and mathematical (formula), these will both be included in the comparisons. This chapter will present an overview of the comparisons. In the first section, the pricing models of services from practice that are identified in the SINTEF case study (Morch et al. 2004) will be used in the comparisons. In the second section, the pricing models identified in the SENA case study (Gordijn et al. 2004) will be used. In the third section, the results of the first two sections will be combined, which will lead to a revision of the formulas of the four types of pricing models of elementary services. 3.1 The SINTEF case study The SINTEF case study describes several core services that are offered by TrønderEnergi AS, which is an electrical utility company with several subsidiaries. Their core product is electricity. A core service describes the way the supplier s business adds value to a value chain (Akkermans et al. 2004). The core services that are described in the SINTEF case study are: Electricity supply, Heat pump, Energy control system, Broadband access, ASP-service, Hot water, Remote control, Safety check and Internal control. The pricing models of the remote control core service are not described in the case study, because the company that made it possible to offer this service is no longer in the market. Pricing models of service bundles are not included in this case study. This is because the work concerning the evaluation of different bundles offered by TrønderEnergi AS was on a theoretical level, and at the time of the case study it did not offer bundles to customers. By bundling the core product of TrønderEnergi AS with other services, the company can be more differentiated in the power market and give a steadier portfolio to the customer. One of the reasons for bundling was that the total costs for both TrønderEnergi AS and the customers would be reduced, but no calculations concerning this have been performed. Thus, for this case study only the four types of pricing models of elementary services will be included in the comparisons. 27

28 3.1.1 Comparison of the textual representations In this section, the textual representation of the four types of pricing models of elementary services are compared with the core services that are described in the SINTEF case study. The textual representations of these types of pricing models of services are described in the literature overview in Table 7. See the table on the next page for the comparison. 28

29 Table 14: Comparison of the textual representation of the pricing models described in the SINTEF case study with the four types of pricing models of elementary services Core service Pricing model of the core service Textual representation of the pricing model of the core service Corresponding pricing model from the literature overview Electricity supply Electricity supply Electricity supply Electricity supply Electricity transmission Electricity transmission Electricity transmission Variable Contract with variable price based on usage. Usage based: The user is charged on basis of usage. Fixed Contract with fixed price for a defined period (Different possibilities 1, 2 or 3 years). Flat-rate: The user pays a fixed amount which is independent of usage. Spot-hourly Contract with spot price on an hourly basis. N-block tariff (with n = 2): A price per unit (p) is charged for any units, up to a certain quantity (q2), and then the price per-unit changes to (p2) for all units greater than (q2). Remark: the n-block tariff with n > 2 is defined similarly. Spot-monthly Contract with spot price on a monthly basis. N-block tariff (with n = 2): A price per unit (p) is charged for any units, up to a certain quantity (q2), and then the price per-unit changes to (p2) for all units greater than (q2). Remark: the n-block tariff with n > 2 is defined similarly. Traditional household Fixed price plus energy price per kwh. Two-part tariff: The user pays a fixed amount plus an additional usage based charge. Seasonal household Power industrial Fixed price plus two different energy prices per kwh for summer and winter. Contains a fixed price, an energy price per kwh and a power price per kw for the peak load consumption. Two-part tariff: The user pays a fixed amount plus an additional usage based charge. Two-part tariff: The user pays a fixed amount plus an additional usage based charge. Heat pump Pump type (ASY9L or ASY12L) Fixed charge is based on fixed installation costs plus the price of the heat pump. Flat-rate: The user pays a fixed amount which is independent of usage. 29

30 Core service Pricing model of the core service Textual representation of the pricing model of the core service Corresponding pricing model from the literature overview Energy control system Broadband access Installation type (new or existing) Subscription (Basic, Regular, Luxurious, Industrial-luxury, Fiber- Basic, Fiber-Regular, Fiber-Luxurious) Fixed price for the electric heater plus installation labor costs. Fixed charge is based on the subscription type. Two-part tariff: The user pays a fixed amount plus an additional usage based charge. Flat-rate: The user pays a fixed amount which is independent of usage. ASP Basic subscription Fixed price for the standard product. Flat-rate: The user pays a fixed amount which is independent of usage. ASP ASP ASP Remote connection subscription Basic subscription & helpdesk Remote connection subscription & helpdesk Fixed price for the standard product with safe logging to Internet. Fixed price for the standard product plus consulting service that is charged per hour. Fixed price for the standard product with safe logging to Internet plus consulting service that is charged per hour. Hot water Standard Fixed yearly price and an energy price per unit hot water consumed. Safety check Internal control Basic Building type (small, medium, large) Fixed charge. Fixed charge based on the building type. Flat-rate: The user pays a fixed amount which is independent of usage. Two-part tariff: The user pays a fixed amount plus an additional usage based charge. Two-part tariff: The user pays a fixed amount plus an additional usage based charge. Two-part tariff: The user pays a fixed amount plus an additional usage based charge. Flat-rate: The user pays a fixed amount which is independent of usage. Flat-rate: The user pays a fixed amount which is independent of usage. 30

31 3.1.2 Comparison of the mathematical representations In this section, the mathematical representation (formula) of the four types of pricing models of elementary services are compared with the core services that are described in the SINTEF case study. The formulas of the four types of pricing models of elementary services are described in the literature overview in Table 12. Below is a list of terms used in these formulas: C is the total charge to the customer. q and q_2 are usage amounts. Fix is a fixed price. p and p_2 are prices per quantity. See the table on the next page for the comparison. 31

32 Table 15: Comparison of the mathematical representation of the pricing models described in the SINTEF case study with the four types of pricing model of services Core service Pricing model of the core service Formula of the pricing model of the core service Electricity supply Variable electricity price x electricity consumption Usage based: p q Electricity supply Fixed fixed price Flat-rate: Fix Electricity supply Spot-hourly (electricity spot price in hour_1 x electricity consumption in hour_1) + + (electricity spot price in hour_n x electricity consumption in hour_n) Remark: n = 24 Corresponding formula of the pricing model from the literature overview N-block tariff (with n = 2): p x q (for: 0 q q_2) C = p x q_2 + p_2(q q_2) (for: q > q_2) Electricity supply Spot-monthly (average electricity spot price in month_1 x total electricity consumption in month_1) + + (average electricity spot price in month_n) x (total electricity consumption in month_n) Remark: the n-block tariff with n > 2 is defined similarly. N-block tariff (with n = 2): p x q (for: 0 q q_2) C = p x q_2 + p_2(q q_2) (for: q > q_2) Electricity transmission Electricity transmission Electricity transmission Remark: n = 12 Remark: the n-block tariff with n > 2 is defined similarly. Traditional household fixed price + (energy price x energy consumption) Two-part tariff: Fix + p q Seasonal household fixed price + ((energy price in summer x energy consumption in summer) + (energy price in winter x energy consumption in winter)) Power industrial fixed price + ((energy price x energy consumption) + (power price x peak load consumption)) Two-part tariff: Fix + p q Two-part tariff: Fix + p q 32

33 Core service Heat pump Energy control system Pricing model of the core service Pump type (ASY9L or ASY12L) Installation type (new or existing) Formula of the pricing model of the core service fixed installation costs + price of heat pump fixed price for the electric heater + (labor rate x hours) Corresponding formula of the pricing model from the literature overview Flat-rate: Fix Broadband access Subscription fixed price Flat-rate: Fix ASP Basic subscription fixed price Flat-rate: Fix ASP ASP ASP Remote connection subscription Basic subscription & helpdesk Remote connection subscription & helpdesk fixed price + fixed price fixed price + (hourly rate x hours) (fixed price + fixed price) + hourly rate x hours Two-part tariff: fix + p x q Flat-rate: Fix Two-part tariff: Fix + p x q Two-part tariff: Fix + p x q Hot water Standard fixed price + (energy price x hot water consumption) Two-part tariff: Fix + p x q Safety check Basic fixed price Flat-rate: Fix Internal control Building type fixed price Flat-rate: Fix 33

34 3.1.3 Results of the SINTEF case study The textual representations of the pricing models that are described in the SINTEF case study correspond with a textual representation of one of the four types of pricing models of elementary services. However, the mathematical representation (formula) of pricing models of three services from the case study, differ slightly from the corresponding pricing model of the four types of pricing models. This is discussed further below for each service. Pricing models of the electricity transmission service The mathematical representation of the seasonal household and power industrial pricing models of the electricity transmission service, differ slightly from the corresponding pricing model of the four types of pricing models of elementary services. The corresponding pricing model here is the two-part tariff pricing model. The formula of the two pricing models has multiple usage-based parts, whereas the formula of the corresponding two-part tariff pricing model has one usage-based part. The formula of a two-part tariff pricing model with multiple usage-based parts is a valid mathematical formula, because a formula can consist of multiple expressions, and multiple usagebased parts can be seen as expressions. This is derived from the analysis of a mathematical formula in the literature overview chapter. As a result, the seasonal household and power industrial pricing models are a further specification of the twopart tariff pricing model because of the following two reasons: 1. The textual representation of the seasonal household and power industrial pricing models corresponds with that of the two-part tariff pricing model. 2. The formula of the seasonal household and power industrial pricing models is a valid mathematical formula. Thus, the formula of the two-part tariff pricing model can be rewritten as: C = Fix + ( pxq) n i= m i Pricing model of the heat pump service The mathematical representation of the pump type pricing model of the heat pump service differs slightly from the corresponding pricing model of the four types of pricing models. The corresponding pricing model here is the flat-rate pricing model. The formula of the pump type pricing model consists of multiple fixed parts, whereas the formula of the corresponding flat-rate pricing model consists of one fixed part. The formula of a flat-rate pricing model, with multiple fixed parts, is a valid mathematical formula, as discussed earlier. As a result, the pump type pricing model is a further specification of the corresponding flat-rate pricing model because of the following two reasons: 1. The textual representation of the pump type pricing model corresponds with that of the flat-rate pricing model. 2. The formula of the pump type pricing model is a valid mathematical formula.

35 Therefore, the formula of the flat-rate pricing model with multiple fixed parts can be rewritten as: C = n i= m Fix i Pricing models of the ASP-service The mathematical representation of the remote connection subscription pricing model of the ASP-service differs slightly from the corresponding pricing model of the four types of pricing models. The corresponding pricing model here is the flat-rate pricing model. However, the formula of the remote connection subscription pricing model consists of multiple fixed parts, whereas the formula of the corresponding flat-rate pricing model consists of one fixed part. As a result, the remote connection subscription pricing model is the same further specification of the flat-rate pricing model, as discussed for the pricing model of the heat pump service. The mathematical representation of the remote connection subscription & helpdesk pricing model of the ASP-service differs slightly from the corresponding pricing model of the four types of pricing models. The corresponding pricing model here is the two-part tariff pricing model. However, the formula of the remote connection subscription & helpdesk pricing model has multiple fixed parts, whereas the formula of the corresponding two-part tariff pricing model has one fixed part. A formula, which consists of multiple fixed parts, is a valid mathematical formula, as discussed for the pricing model of the heat pump service. As a result, the remote connection subscription & helpdesk pricing model is a further specification of the two-part tariff pricing model because of the following two reasons: 1. The textual representation of the remote connection subscription & helpdesk pricing model corresponds with that of the two-part tariff pricing model. 2. The formula of the remote connection subscription & helpdesk pricing model is a valid mathematical formula. As a result, the formula of the two-part tariff pricing model can be rewritten as: n i= m C = Fix i + ( pxq) n i= m i 3.2 The SENA case study The SENA case study discusses pricing models that are used for the Music Rights Clearance (MRC) service. MRC is a service in which right holders provide users with the right to use one or more music tracks in return for a fee. Whenever a music track is used for commercial goals, a user has to pay some money to the right holders of this track, for the right to use it. Internet and ethereal radio stations are an example of such a user. The SENA handles only the right to make music public, limited to two rights holders only: artists and producers. Pricing models of service bundles are not described in the case study. Therefore, only the representations of the four types of pricing models 35

36 of elementary services will be compared with the MRC service that is described in the SENA case study Comparison of the textual representations In this section, the textual representation of the four types of pricing models of elementary services will be compared with the pricing models of the MRC service that are described in the SENA case study. First, more details are given about the pricing models of the MRC service. In the SENA case study, two pricing models are described for an Internet radio station that uses the MRC service. The first pricing model is described as follows: an Internet radio station must pay a fee per listener per track to the SENA to legally stream music. In the case study it is stated that a stream corresponds with a program broadcast via a channel, and it will play multiple tracks. Typically, a radio station will have multiple streams. In the second pricing model, small Internet radio stations that have hardly any audience pay a fixed fee to stream music. For a traditional ethereal radio station, the SENA calculates fees on the basis of potential audience. This means that the potential audience of the ethereal radio station is measured and then multiplied with a tariff to yield the price to be paid. There are other users of the MRC service that are not identified in the SENA case study. According to the website of the SENA 3, users that publicly use music such as offices, supermarkets and catering industries must also pay a fee for the MRC service. These users must pay a fixed fee to the SENA according to the amount of square meters (m²) of the business in which the music can be heard. For example, a catering company must pay 385 for up to 100 m², 543,56 for 101 until 200 m², etc. The textual representations of the four types of pricing models of elementary services are described in the literature overview in Table 7. See the table below for the comparison. Table 16: Comparison of the textual representation of the pricing models described in the SENA case study with the four types of pricing models of elementary services User of the MRC service Internet radio station Internet radio station Ethereal radio station Offices, supermarkets and catering industries Textual representation of the pricing model Internet radio station must pay a fee perlistener-per-track. Internet radio station must pay a fixed fee to stream music. Potential audience of the ethereal radio station is multiplied with a tariff. Users must pay a fixed fee to the SENA according to the amount of square meters of the business in which the music can be heard. Pricing model from literature overview Usage-based: The user is charged on basis of usage. Flat-rate: The user pays a fixed amount which is independent of usage. Usage-based: The user is charged on basis of usage. Flat-rate: The user pays a fixed amount which is independent of usage. 3 (last visited May 2005) 36

37 3.2.2 Comparison of formulas used in the SENA case study In this section, the mathematical representation (formula) of the four types of pricing models of elementary services are compared with the MRC service that is described in the SENA case study. The formulas are described in the literature overview in Table 12. The terms used in the formulas are also described in the literature overview. See the table below for the comparison. Table 17: Comparison of the mathematical representation of the pricing models described in the SENA case study with the four types of pricing models of elementary services User of the MRC service Internet radio station Internet radio station Ethereal radio station Offices, supermarkets and catering industries Formula x number-of-listeners-pertrack fixed fee tariff x potential audience Fixed price for the amount of the business in which the music can be heard. Formula of the pricing model from the literature overview Usage-based: p q Flat-rate: Fix Usage-based: p q Flat-rate: Fix Results of the SENA case study The comparisons show that the textual and mathematical representations of the pricing models that are described in the SENA case study correspond with a representation of one of the four types of pricing models of elementary services. These are the only results for this case study since only few pricing models of the MRC are discussed. 3.3 Conclusions of the case studies From the results of both case studies it can be concluded that the four types of pricing models of elementary services are representative for services from practice. Both case studies do not include pricing models of service bundles. However, these pricing models are also representative for services in practice, because the pricing models are partially derived from the way service bundles are priced in practice. This is discussed in the literature overview, in section Pricing models identified in the SINTEF case study have lead to a further specification of the formulas of the flat-rate and two-part tariff pricing model. The seasonal household and power industrial pricing models of the electricity transmission service, and the remote connection subscription & helpdesk pricing model of the ASP-service are a further specification of the two-part tariff pricing model. The pump type pricing model of the heat pump service is a further specification of the flat-rate pricing model. 37

38 Therefore, a revised overview of the formulas of the four types of pricing models is given below. List of terms used in the formulas: C is the total charge to the customer. q and q_2 are usage amounts. Fix is a fixed price. p and p_2 are prices per quantity. Table 18: Revised formulas of the four types of pricing models of elementary services Pricing model Flat-rate Usage-based Two-part tariff N-block tariff (with n = 2) Formula C = n i= m C = p x q n i= m Fix i C = Fix i + ( pxq) n i= m p x q ( f or: 0 q q_2) C = p x q_2 + p_2(q q_2) (for: q > q_2) Remark: the n-block tariff with n > 2 is defined similarly. i 38

39 Chapter IV The ontologies This chapter will explain the constructs of the service ontology. The constructs of the e³-value ontology will also be explained given that both ontologies are needed to facilitate a methodology to perform a business analysis of e-service bundles for networked enterprises (see Chapter seven for more details). This chapter is organized as follows. The first section will discuss the service ontology, and the second section the e³-value ontology. Notions that appear in multiple figures are explained only once in a legend. 4.1 The service ontology This section explains the various concepts that form the service ontology. It is a summary of Baida et al. (2003) and Baida (2005). An ontology is an explicit formal specification of the terms in a domain and relations among them (Gruber 1993). Ontologies serve as an important tool in making domain knowledge machine-readable. The service ontology includes two perspectives: service value perspective and service offering perspective. The service value perspective describes the service from a customer s perspective. It expresses the customer needs or demands that should be satisfied by acquiring a service of a certain quality, in return for a certain sacrifice (including price, but also intangible costs such as inconvenience costs and access time). The service offering perspective describes the service from a supplier s perspective. The focus of this research is on the service offering perspective given that the supplier determines the pricing models. This section discusses important concepts within this perspective that are relevant for this research. Some cardinalities, as well as concepts and relations of secondary importance were omitted from the figures for the sake of clarity. Cardinality indicates the number of instances of concept B that can (or must) be associated with each instance of concept A (last visited April 2005) 39

40 4.1.1 The service offering perspective The service offering perspective (see Figure 1) represents the supply-side viewpoint of a service. This perspective centers around the concept service element. Figure 1: Service sub-ontology representing the service offering perspective 40

41 Service element. Service elements represent what a supplier offers to its customers, as presented by the supplier to its customers. It is what the business science literature defines as service, a business activity (performance) of mostly intangible nature. Examples are money transfer, loans, medical treatment, transportation, haircuts, insurance, Internet connection, electricity supply and cleaning services. The concept service element is visualized in Figure 2. Figure 2: Service element Service bundle. A service element can be a composite concept, meaning that is it built of smaller components, each of which is a service element as well. A service element can thus be decomposed to smaller elements, as long as the smaller service elements can be offered to customers separately or by different suppliers. The smallest decomposed service element is called an elementary service element. A composite service element is referred to as service bundle: it consists of one (the trivial case) or more service elements (each of which may be elementary of a bundle itself). A link indicates that a service element is part of a service bundle. The principle of aggregating multiple services and goods into a single package (bundle) is broadly known in the business science literature. Researchers from business science distinguish between two cases: (1) offering only a bundle, and (2) offering both a bundle and its separate elements (Normann 2001). A well-known example of bundling physical goods is the selling of a PC that a customer can design by combining separate elements: a processor, a motherboard etc. Lovelock (2001) points out that many services are sold with physical goods without being charged separately, and that many services are in fact a bundle of more elementary services, possibly with physical goods as well. 41

42 Businesses use the principle of bundling for divergent reasons. Bundling is defined as the practice of marketing two or more goods or services in a single package for a special price (Guiltinan 1987). In other words, the bundle is financially more attractive to the customer than the sum of the separate elements. The low price, however, often reflects also lower costs for suppliers too. The various business activities that are packaged into a bundle may use common processes, technological and human infrastructure of service suppliers. Once combined into a bundle, the cost of providing several services is lower than the cost of providing the same services separately. Bundling can also be a means to attract customers and gain market share. Especially highly standardized products as electricity are hard to market, since the differences between the products of competing suppliers are minimal, and often also the prices are almost the same. In such situations suppliers may want to bundle these standardized products with other products that help them differentiate themselves and compete in the market. The service ontology is configuration-biased. This implies that it is possible to use existing configuration methods to bundle (or: configure) services. Configuration is a constructive task, where predefined components are configured into a larger, complex component, based on the availability of a set of predefined connections, and associated parameters and constraints (Mittal & Frayman 1989, Löckenhoff & Messer 1994, Gruber et al. 1996). Applying configuration constructs to services means considering services to be components (a notion from configuration theory) that can be configured into a larger, service bundle (complex component). According to configuration theory, components have service ports, interfaces, properties and constraints. Thus, input and outcome service ports, interfaces and properties and constraints can be identified for service elements. A service port indicates a certain resource that is either a pre-requisite for carrying out this service element (input service port), or that is the result (outcome) of carrying out this service element. A service element is then characterized by its required inputs and by the outcomes it produces. A link indicates that two service ports are connected. The notion of ports stems from the technical system theory (Borst et al. 1997b). The set of all input service ports, respectively all outcome service ports of a service element form the element s input interface, respectively outcome interface. Every service element has exactly one input interface and one outcome interface. All elements within the input interface must be available, for the service to be provided. The provisioning of a service elements results in the availability of all elements in the outcome interface of this service element. Resources can either be required for the provisioning of some service element (input), or be the result of a service element (outcome). Inputs and outcomes may be tangible (e.g., a credit card) or intangible (e.g., the ability to perform worldwide money transactions). Some service elements may produce outcomes that are pre-requisites for other service elements. In such a case an outcome of one service element will be the input of another. Since inputs and outcomes may refer to the same thing(s), they are called resources: every service port then stands for a resource. 42

43 The natural way to understand a resource is in the sense of resources for carrying out a business process. This is however not the case here. The resources that are referred to in the service offering perspective describe what is being offered (which service), rather than how the service is being offered (business process). There may definitely be some overlapping between the two, but they are conceptually different. Example resources for both are: Service offering: credit card transaction fee, the capability to pay electronically Business process: employees required to carry out the process: office space: machinery required to produce a credit card: information about a customer s account status. Several types of resources have been identified (e.g., information, experience, and capability) but only the monetary resource is relevant for this research. Refer to Baida et al. (2003) for more details about the other types of resources. Monetary resources are mostly money, but one could also consider stocks or similar value-papers. The values of monetary resources are often not constant, but a formula, determined by the supplier (e.g. usage-based price). Furthermore, resources have attributes that are important for the configuration of service bundles out of service elements. Only the compositeness attribute is relevant for this research. Compositeness refers to whether and how two or more resources of the same type (possibly, but not necessarily resources of different service elements) can be united into and modeled as one resource, when they appear in the same interface. Resources may either not be united into one resource (e.g., tables of type A, and tables of type B both physical resource cannot be united into one resource), or they may be united. A common example for the compositeness property is the (financial) costs of services. If two service elements within a service bundle require a payment, it is not necessarily the case that there are two different payment inputs in the input interface of the bundle: instead, they may be united to one payment input. Likewise, if an input of 1000 Euro is available for a bundle, and the bundle includes tow services that require 500 Euro each, the input of 1000 Euro may be decomposed to two inputs of 500 Euro. So the compositeness attribute describes whether the resource is of a composable nature. However, sometimes a business may decide not to combine resources. For example, to payment resources may be combined into one payment (implying one bill for two services) or not (implying that every service generates its own bill). Although the nature of money resources is composable, businesses may decide not to compose these services. Consequently, also a service port has the compositeness attribute. So the resource compositeness describes whether a resource is of composable nature, and the service port compositeness describes whether the resource in the service port should be composed if necessary, and if the resource is also of a composable nature. Once a resource is associated with an input- or outcome-service port, it becomes a service input or a service outcome. A service input is thus a resource that is a prerequisite for a specific service element, and a service outcome is a resource that is the result of a specific service element. Those two terms make it easier for us humans to understand that resources may be required for providing a service, or be the result of providing a service, but in fact they are the same thing: a resource. 43

44 Service elements and resources are both subtypes of design element. Design elements have certain properties that encapsulate business knowledge on the service/resource. They are often referred to as attributes or parameters. The term property is preferred, since attributes and parameters are loaded terms: they are often associated with primitive data types, as characters, strings or integers. A property, on the other hand, may be of a more complex nature. For example, the property quality may be defined by a set of criteria. So far it is found that service properties may be described by resource properties. Nevertheless, keeping in mind future scenarios, the concept property is related to design element (and hence to resources and to service elements), instead of relating property to resource only. As stated before, a service element is characterized by its required inputs and by the outcomes it produces. Often it is possible to achieve the same outcomes with different inputs. In such a case, the different options will stand for different service elements. This distinction is shown in Figure 3. Service inputs A B Service element M C D Service outcomes Service inputs E B Service element N C D Service outcomes Figure 3: Two different service elements different inputs, but the same outcomes A constraint (Gruber et al. 1996) is a description that limits the permissible values for properties of a service element (refer to the word properties in its dictionary definition, rather than only the above mentioned properties). A constraint may refer to resources (inputs or outcomes), to service ports or to relationships between resources. Since the concept property is related to design elements, rather than to resources, the ontology also supports possible future constraints on service elements (e.g. a maximum number of suppliers for a service bundle). 44

45 Two types of constraints are distinguished in the service ontology, namely, constraints that represent domain knowledge and inherent constraints. Only the first mentioned constraint is relevant for this research. These constraints include two types: Constraints on the possible values of properties are referred to as conditional outputs. Constraints on the relations between services are referred to as service dependencies. The service ontology uses three types of conditional outputs. A conditional output 1. Refers to one resource (e.g., the value of the property postcode of resource X may be ). 2. Refers to two or more resources within one service elements (a conditional output determines the value of a property, possibly by means of other properties). 3. Refers to 2 or more resources in 2 or more services (e.g., if the payment resource in service X has value 1000, then the invoice resource in service Y has value 1000 as well). A conditional output (see Figure 4) always determines the value of some (property of a) design element. Hence the relation design element has a 0..* conditional output. And hence also the cardinality 1 for conditional output hasrange property. The first type of conditional outputs (see above) has no domain, but only a range (e.g., the value of property X is always between 1 and 10). In this case the cardinality of conditional output hasdomain property is zero. In the other cases (property X depends on property Y), property Y is the domain, so the cardinality of conditional output hasdomain property is 1. Figure 4: Conditional output and service dependency 45

46 Service dependency is a relationship between two service elements that defines a dependency between these service elements (see Figure 4). It represents a constraint on the way these two service elements may or may not be bundled. This is not like the earlier mentioned conditional outputs that refer to the internal characteristics of a service element. A service dependency is thus a constraint of the configuration (or: bundling) of services, rather than on the service elements themselves. A service dependency is defined as a formula, that receives two inputs of type service elements (A the dependees is a set of service elements, and B the dependents is also a set of service elements), and produces as output a set of possible configurations of these two inputs. A resource has constraints and several properties. Properties are domain-specific, but some appear more often. Example properties may be: Quality. A customer identifies two main dimensions of quality: process quality and product quality. Although this is a generic concept, in accordance with (Grönroos 2000) and other research, quality definition has to be verified by every business. The use of this concept is domain or company specific. Download speed (in an Internet connection) Amount (for a payment resource) Supplier. The term supplier is quite straightforward: it is an economically independent entity that offers services and/or goods to its environment, in return for certain sacrifices. An important ontological decision is defining the relation between a supplier and a service element: does a supplier supply a whole service bundle, on the one extreme? Or only an elementary service element, on the other extreme? The first option contradicts with the goal of enabling collaborative ecommerce scenarios, where a customer can bundle services of multiple suppliers. It seems undesired and not useful to limit the relation between a supplier and a service element. Therefore, an elementary service element is related to one supplier. An elementary service element is supplied by one supplier. A complex service element in essence a service bundle can be offered by multiple suppliers. 4.2 The e³-value ontology This section explains the various concepts that form the e³-value ontology. Both the service ontology and the e³-value ontology are needed to facilitate a methodology to perform a business analysis of e-service bundles for networked enterprises (see Chapter seven for more details). The description of this ontology is based on Gordijn and Akkermans (2003). Refer to that paper for more detailed information on the e³-value ontology. 46

47 4.2.1 The e³-value ontology explained The ontology is based on economics and business science literature on e-commerce (Holbrook 1999, Porter 2001, Tapscott et al. 2000), combined with formal ontology of systems theory (Borst et al. (1997). Moreover, the ontology uses a conceptualization of use case maps (Amyot 2000). Below is a graphical representation of the e³-value ontology. Figure 5: The e³-value ontology Actor: an actor is an independent economic (and often also legal) entity. An actor makes a profit or increases its utility. In a sound, sustainable, e-business model, each actor should be capable of making a profit. Value Object: actors exchange value objects, which are benefits of services, products, money, or even consumer experiences. The important point here is that a value object is of economic value for one or more actors. 47

48 Value Port: an actor uses a value port to show his environment that he wants to provide or request value objects. The concept of a value port enables to abstract away from the internal business processes, and to focus only on the way external actors and other components of the e-business model can be plugged in. Value Offering: a value offering models what an actor offers to or requests from his 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 where some objects are only of value used in combination for an actor. Value Interface: actors have one or more value interfaces, grouping individual value offerings. A value interface 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: a market segment is a concept that breaks a market (consisting of actors) into segments that share common properties (Kotler 1988). Accordingly, 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. Composite actor: to provide a particular service, a number of actors may decide to work together, and to offer objects of value jointly, using one value interface to their environment. Such a partnership is called a composite actor. Value Activity: an important issue in value model design is the assignment of value activities to actors. Therefore, it is interesting to look at the collection of operational activities, which can be assigned as a whole to actors. Such a collection is called a value activity. A value activity is performed by precisely one elementary actor Use case maps The concepts described above allow a user to model who wants to do business with whom, but cannot represent all value exchanges needed to satisfy a particular endconsumer need. 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. Experience from practice shows that all such value exchanges to satisfy an endconsumer need contribute largely to a common understanding of an e-business idea. To that purpose, an existing scenario technique called Use Case Maps (UCMs) (Buhr 1998) is used. UCMs show which value exchanges should occur as a result of a consumer need (which is called a start stimulus), or as a result of other value exchanges. Below, the main UCM modeling constructs are briefly discussed. 48

49 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 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 Example of a value model A number of generic concepts, relationships and rules have been identified in the e³value ontology to express a value model. Such a model represents a network of actors creating, distributing and consuming valuable products, such that each actor can make a profit. Figure 6 (on the next page) shows an example of a value model. The concepts of the e³-value ontology that are used in the model are displayed in a legend. 49

50 Figure 6: An example of a value model The value model shows that a shopper receives a good and pays money in return. The shop obtains goods from a store, which buys them from a wholesaler. The wholesaler obtains goods from a manufacturer. 50

51 Chapter V Proposal to incorporate pricing models in the service ontology This chapter begins with a description of different reasons to incorporate pricing models in the service ontology. In the next section, the relationships of the model proposal will be explained one-by-one. This is followed by a discussion of an extension of the model proposal. After that, it will be explained the way useful information (the name and construction) of the different types of pricing models can be included in the model proposal. Then the key notes of the model proposal will be presented. The chapter ends with a description of a model proposal which was considered in an earlier stage of this research. 5.1 Why incorporate pricing models in the service ontology? There are three reasons why it is important to incorporate pricing models in the service ontology. First of all, pricing plays a significant role in determining the value for the customer, and also gives a perception of quality (Payne 1993). The price charged for a service signals to customers the quality they are likely to receive. Consider for example a restaurant that displays its menu in the window for potential customers to view. The menu gives potential customers an idea of what to expect in terms of quality of food and service levels (Payne 1993). Second of all, pricing models facilitate reasoning about the prices of services. If the price of a service is known, then a customer can compare the prices of services and purchase the cheaper one. Additionally, pricing models facilitate reasoning about the price of service bundles, since the price can be a requirement for the bundling (configuring) of services. For example, if the price is a requirement for the bundling of services, it is possible to only configure bundles that have a certain price or price range. Third of all, information on the price of a service, which is present in the pricing model, is required for the selling of a service. It is common sense that if a service has no price, it cannot be sold. Figure 7 displays part of the service ontology, including the model proposal to incorporate pricing models in the service ontology. Some cardinalities, as well as relationships of secondary importance are omitted from the figure for the sake of clarity. Notions that appear in multiple figures are explained only once in a legend. 51

52 Figure 7: Service sub-ontology representing the service offering perspective, including the proposal to incorporate pricing models The focus of this proposal is on the service offering perspective of the service ontology given that the supplier determines the pricing models. Figure 7 displays that the pricing model concept has a relationship with the property concept, the service port concept and the link concept. The following sections discuss the model proposal by looking oneby-one at all these relationships, including their cardinalities. Cardinality indicates the number of instances of concept B that can (or must) be associated with each instance of concept A. 52

53 5.2 Relationships of the model proposal Relationship between the Pricing model concept and the Property concept The relationship between the pricing model concept and the property concept is indirect, since this relationship is already present in another part of the service ontology. This other part of the service ontology is discussed in section 5.3. The indirect relationship consists of two parts, which are both discussed in this section. First part of indirect relationship: pricing model and property The first part of the indirect relationship states that a pricing model determines the value of a property. The following reasoning explains why this relationship is needed. A pricing model of a service element determines its price. The price can be seen as a resource since it is required for the provisioning of some service element. In addition, the value of a resource is modeled as the value of its property. A pricing model determines this value. Given that the price of a service element is expressed in a monetary unit, the type of the resource is monetary. A monetary resource is mostly money, but one could also consider stocks or similar value-papers. These resources are often not constant, but a formula, determined by the supplier. A pricing model determines the value of one property, namely, the price. Hence, the relationship, including its cardinality, can be further specified: a pricing model determines the value of 1 property of a monetary resource. This relationship implies that a pricing model also describes a resource. Second part of indirect relationship: pricing model and property The second part of the indirect relationship between the pricing model concept and the property concept states that a pricing model can use the values of properties. From the SENA (Gordijn et al. 2004) and SINTEF (Morch et al. 2004) case studies, it can be derived that the prices per quantity, which are needed by the pricing models to calculate the price, are not modeled for the services that are identified in the case studies. On the other hand, most usage amounts, which are also needed by the pricing models, are modeled as properties of resources. This is why the second part of this indirect relationship is needed. The following example from the SINTEF case study explains this further. In this example, the electricity supply service element from the case study is used. This service element has two service inputs, lock-in and payment, and has one service outcome, energy. A service input is a resource that is a pre-requisite for a specific service element, while a service outcome is a resource that is the result of a specific service element. A pricing model of this service element can be constructed as follows: price per KWh x electricity consumption. In this pricing model, the price per KWh is not modeled for the service. However, the electricity consumption can be derived from the energy resource. More specifically, the electricity consumption is derived from the value of a property of the energy resource. This example shows that the value of a property of a resource can be used as a value inside a pricing model. A property is not always used as a value inside a pricing model, since not all properties are relevant for a pricing model. Additionally, a pricing model can use multiple properties of resources, as seen in 53

54 the SINTEF and SENA case studies. Therefore, the relationship, including its cardinality, can be further specified: a pricing model uses 0..* values of properties of resources (to calculate the price) Relationship between the Pricing model concept and the Service port concept The next relationship in the model proposal that will be discussed is: a pricing model can be assigned to a service port of a service element. Why assign a pricing model to a service port? A pricing model can be assigned to a service port of a service element, because service ports describe the interface of a service element. This means that the outcome of a pricing model that is assigned to a service port describes partly the way the interface will look like. Moreover, a pricing model can be assigned to a service port given that a service port is a unique characteristic of a service element. Thus, a pricing model assigned to service port is also such a unique characteristic. A pricing model is not assigned to a resource, for the reason that a resource can be linked to multiple service elements, while a pricing model is only applicable for one service element. Relationship explained: pricing model and service port The previous section states that a pricing model determines the value of a property of a monetary resource. Given that a service port indicates a resource, a pricing model can be assigned to a service port indicating a monetary resource. Below is an explanation why there is a cardinality of 0..* in the relationship between the pricing model concept and the service port concept and the inverse relationship (see Figure 7). The cardinality 0..* must be read as zero or more. A pricing model does not have to be assigned to a service port that indicates a monetary resource, since not all service elements have a pricing model or a monetary resource. Thus, the cardinality 0 is possible. Multiple pricing models can be assigned to a service port that indicates a monetary resource, since these can be applicable for a service element, as seen in the SINTEF and SENA case studies. Thus, the cardinality 0..* is possible. A pricing model can be assigned to multiple service ports of a service element that indicate a monetary resource, since more then one service port of a service element can indicate a monetary resource, and thus a pricing model can be assigned to any of those service ports. Thus, the cardinality 0..* is possible. As a result, the relationship can thus be further specified: 0..* pricing models can be assigned to 0..* service ports that indicate a monetary resource. From this point forth, a service port o f a service element that indicates a monetary resource, will be referred to as a monetary service por t o f a service element. In the rest of the discussion about the relationship 0..* pricing models can be assigned to 0..* service ports that indicate a monetary resource, a distinction is made between the way this relationship applies to elementary service elements and to service bundles. 54

55 A distinction is made because in the literature overview chapter it is stated that the price of a service bundle is calculated differently than that of an elementary service element. This price is calculated differently because a service bundle is sold at a discounted price, and it includes the prices of the services that are part of the bundle. Below is a description of the way the relationship applies to elementary service elements and to service bundles Relationship between the Pricing model concept and the Service port concept when dealing with elementary service elements The relationship 0..* pricing models can be assigned to 0..* service ports that indicate a monetary resource is sufficient when dealing with pricing models of elementary service elements. This is due to the fact that only one price needs to be calculated, namely, the price of the elementary service element. See the figure below for an example. In this example a pricing model of an elementary service element is assigned to its monetary input service port. Figure 8: Example of a pricing model of an elementary service elements that is assigned its monetary service port Representation of the pricing models The representation of the pricing models used in this proposal is in the form of a mathematical formula. In the service ontology, these formulas can be expressed as a String. A String is a linear sequence of symbols, and these symbols can be characters, words or phrases (last visited March 2005) 55

56 5.2.4 Relationship between the Pricing model concept and the Service port concept when dealing with service bundles This section discusses the way the relationship 0..* pricing models can be assigned to 0..* service ports that indicate a monetary resource applies to service bundles. First the two ways to calculate the price of service bundles, which are discussed in the literature overview (see section 2.3.4), are repeated. Two ways to calculate the price of service bundles According to the literature overview, a service bundle is sold at a discounted price and this discount is either a certain percentage or a fixed amount. The price of a service bundle can be calculated in two ways. These two ways are the pricing models that are applicable for service bundles. 1. The price of the service bundle is calculated by applying a specific price discount, which is calculated from the combined prices of the service elements that are part of the bundle. 2. First a discount is applied to the price of one or more service elements that are part of the service bundle. Then the price of the bundle is calculated by adding up these prices. The above distinction between the two ways to calculate the price of a service bundle is on a process level. However, since the service ontology is a conceptual model, it is also necessary to make this distinction on a conceptual level. To make this distinction, it must be known where the information that is needed to calculate the price of a service bundle is modeled. This is as follows: 1. In the first way to calculate the price of a service bundle, the information is modeled inside the monetary service ports of the service elements that are part of a service bundle. This is explained further in section In the second way to calculate the price of a service bundle, the information is also modeled inside the monetary service ports of the service elements that are part of a service bundle. It is also modeled in the connection between the service elements that are part of the service bundle and the service bundle itself. This is explained further in sections and The relationship 0..* pricing models can be assigned to 0..* service ports that indicate a monetary resource only supports the first way to calculate the price of a service bundle. This is because the second way to calculate the price of a service bundle implies that a discount can be applied to the pricing models of one or more service elements when they are part of a service bundle. Additionally, the discounts, and thus also the prices, of the service elements that are part of a service bundle, depend on the service bundle of which they are a part. The relationship does not support this. The way the proposal supports the second way to calculate the price of a bundle is discussed in sections and The following section discusses the way the relationship supports the first way to calculate the price of a service bundle. 56

57 5.2.5 Relationship between pricing model and service port concept to support the first way to calculate the price of service bundles In the first way to calculate the price of a service bundle, a pricing model of the bundle can be assigned to the monetary service ports of the bundle. To calculate the price of the bundle, a specific discount is calculated from the combined prices of two or more service elements that are part of the bundle. The combined price of a service bundle consists only of the prices of the service elements that are part of the bundle with is a link between the monetary service ports of these service elements and the monetary service ports of the bundle. A link indicates that a service element is part of a service bundle, and that two service ports are connected. The prices of the service elements that are not linked with the service bundle are provided internally. According to Akkermans et al. (2004), a service bundle s interface must provide all the inputs of all the bundle s service elements, unless they are provided internally. An input is provided internally when a service element, which is part of a service bundle, produces an outcome that a different service element, part of the same bundle, consumes as an input. Relationship explained: example See Figure 9 for an example of the first way to calculate the price of a service bundle. PM is an abbreviation of pricing model PM of the service bundle is assigned to a monetary service port > PM = (PM1 +PM2) x 85% > PM = ( ) x 85% = PM1 is assigned to a monetary service port > PM1 = 5 * 10 PM3 is assigned to a monetary service port > PM3 = 5 * 2.5 Service element 1 Service element 3 Service element 2 Service bundle PM2 is assigned to a monetary service port > PM2 = 7 x 5 Figure 9: Example of the first way to calculate the price of a service bundle 57

58 The figure displays three service elements that are part of a service bundle. A pricing model is assigned to the monetary input service ports of the three service elements, and of the service bundle. The figure shows that only the prices of service element 1 and service element 2 are used to calculate the price of the service bundle. The price of service element 3 is not used, because there is no link between a monetary service port of service element 3 and a monetary service port of the bundle. This means that the price of service element 3 is provided internally. The price of the service bundle is calculated by first adding up the price of service elements 1 and 2, and then multiplying the sum of the prices by a discount. In this example, a 15% discount has been applied to the price of the bundle, which means that the sum of the prices is multiplied by 85% (100% - 15%). This is because the formula of a pricing model must be a valid mathematical formula Relationship between the Pricing model concept and the Link concept This section discusses the way the proposal also supports the second way to calculate the price of a service bundle. The relationship 0..* pricing models can be assigned to 0..* service ports that indicate a monetary resource cannot cope with the second way to calculate the price of a service bundle. This is because of two reasons, first of all the second way to calculate the price of a service bundle implies that a discount can be applied to the pricing models of one or more service elements when they are part of a service bundle. Second of all, the discounts, and thus also the prices of the service elements that are part of a service bundle depend on the service bundle of which they are a part, while a service port of a service element is not related to the bundle in which this service is. As a result, another relationship must be added to the proposal to support the second way to calculate the price of a bundle. Before this relationship is discussed, some more details will be given about the two reasons mentioned above. This will be done in the form of examples. Examples The first example explains why the second way to calculate the price of a service bundle implies that a discount can be applied to the pricing models of one or more service elements when they are part of a service bundle. Consider for example three service elements X, Y and Z that are sold together as a service bundle. In this example the prices of the service elements are as follows: service X costs 5, service Y costs 7 and service Z costs 2. All the three service elements are sold as a service bundle for 11, which means that one or more service elements are sold at a discounted price because they are part of this specific bundle. In this specific bundle, service element X is sold for 4, service element Y is sold for 5 and service element Z is sold for 2. This example shows that a certain discount can be applied to the pricing models of one or more service elements when they are part of a specific service bundle. The second example explains why the discounts, and thus also the prices, of the service elements that are part of a service bundle depend on the service bundle. Consider for example that a service bundle consists of service elements X and Y (these are the same service elements of the previous example). This specific service bundle is sold for 9, which means that one or both service elements are sold at a discounted price because 58

59 they are part of this specific bundle. In this specific bundle, service element X is sold for 2, and service element B is sold for 7. In the previous example, service element X was sold for 4 in a service bundle, however, in this example service element X is sold for 2 in a (different) service bundle Relationship between pricing model and link concept to support the second way to calculate the price of service bundles To support the second way to calculate the price of a service bundle, the following relationship is added to the proposal: a pricing model can be assigned to a link. A link indicates that a service element is part of a service bundle, and that two service ports are connected. The following reasoning explains why this relationship is also needed in the model proposal. A pricing model can be a relationship between the bundle and a service element that is part of this bundle. A link describes a relationship between a bundle and a service element that is part of it. Therefore, a pricing model can be assigned to a link. Due to the relationship a pricing model can be assigned to a link, the model proposal supports the situation in which service elements are sold at a discounted price when they are part of a certain service bundle. Below is an explanation why there is a cardinality of 0..* in this relationship between the pricing model concept and the service port concept and the inverse relationship (Figure 7): A pricing model does not have to be assigned to a link, since not all service elements that are part of a service bundle are sold at a discounted price. Thus, the cardinality 0 is possible. A pricing model can be assigned to multiple links, since multiple service elements can be sold at a discounted price when they are part of a service bundle. Thus, the cardinality 0..* is possible. Multiple pricing models can be assigned to a single link, since these can be applicable for a service element, as seen in the SINTEF and SENA case studies. Thus, the cardinality 0..* is possible. As a result, the relationship can thus be further specified: 0..* pricing models can be assigned to 0..* links. Relationship explained: the role of links As stated before (in section 5.2.5), the combined price of a service bundle consists only of the prices of the service elements that are part of the bundle with a link between the monetary service ports of these service elements and the monetary service ports of the bundle. This means that a pricing model assigned to a link is only used to calculate the price of a bundle, if this link is between the monetary service ports of the service elements that are part of the bundle and the monetary service ports of the bundle itself. As a result, the following two cases can occur when the price of a service bundle is calculated, when dealing with the second way to calculate the price of a service bundle. 1. A service element is sold at a discounted price in a specific service bundle, because it is part of that bundle. There is also a link between a monetary service port of the bundle and a monetary service port of the service element. In this 59

60 case, the pricing model with the discount is added to that link, and it is used to calculate the price of the service bundle. 2. A service element is not sold at a discounted price in a specific service bundle, but there is a link between a monetary service port of the bundle and a monetary service port of the service element. In this case, a pricing model is not assigned to that link. The pricing model of the service element itself (pricing model that is assigned to its monetary service port) is used to calculate the price of the service bundle. Relationship explained: example See the figure below for an example of how the price of a service bundle is calculated in the second way, including both cases that can occur when the price of a bundle is calculated. PM is an abbreviation of pricing model PM link 1 is assigned to the link between service element 1 and the service bundle > PM link 1 = PM1 x 80% PM of the service bundle is assigned to a monetary service port > PM = (PM link 1 + PM2) > PM = ( ) = 75 PM1 is assigned to a monetary service port > PM1 = 5 * 10 PM3 is assigned to a monetary service port > PM3 = 5 * 2.5 Service element 1 Service element 3 Service element 2 Service bundle PM2 is assigned to a monetary service port > PM2 = 7 x 5 PM link 3 is assigned to the link between service element 1 and service element 3 > PM link 3 = PM3 x 80% Figure 10: Example of the second way to calculate the price of a service bundle 60

61 The figure displays three service elements that are part of a service bundle. A pricing model is assigned to the monetary input service ports of the three service elements, and of the service bundle. There is also a pricing model assigned to the link between the monetary input service port of the bundle and the monetary input service port of service element 1. In this example, this pricing model consists of the pricing model of service element 1 (PM1), and a discount of 20% applied to the outcome of PM1 (see Figure 10). This means that service element 1 is sold at a 20% discounted price in this specific bundle. Furthermore, a pricing model is assigned to the link between the monetary outcome service port of service element 1, and the monetary input service port of service element 3. This pricing model consists of the pricing model of service element 3 (PM3), and a discount of 20% applied to the outcome of PM3 (see Figure 10). This means that service element 3 is also sold at a 20% discounted price in this specific bundle. However, the pricing model assigned to the link of service element 3 is not used to calculate the price of the bundle, because a pricing model assigned to a link is only used to calculate the price of a bundle, if this link is between the monetary service ports of the service elements that are part of the bundle, and the monetary service ports of the bundle itself. This means that the price of service element 3 is provided internally. The price of the bundle is calculated by adding up the outcome of the pricing model assigned to the link of service element 1, and of the pricing model assigned to the monetary input service port of service element Extension of the model proposal The model proposal is further extended with the following relationship: the pricing model concept is a subtype of the conditional output concept. Part of the service ontology, including the extended model proposal, is displayed in Figure 11 on the next page. 61

62 Figure 11: Service sub-ontology including the extension of the model proposal Relationship explained: pricing model and conditional output A pricing model describes a resource, because it determines the value of a property of a resource. As a result, a pricing model is also a constraint on the values of the properties of resources. In the ontologies chapter (section 4.1.1), it is stated that a constraint is a description that limits the permissible values for properties. Constraints on the properties of resources are called conditional outputs. This means that a pricing model is also a conditional output. However, a pricing model is a specific type of conditional output, because it also relates to service ports and links, whereas not all conditional outputs do. This means that the pricing model concept is a subtype of the conditional output concept, and thus the pricing model concept inherits all the relationships of the conditional output concept. Indirect relationship further explained: pricing model and property As stated earlier in section 5.2.1, the relationship between the pricing model concept and the property concept is indirect, since this relationship is already present in another part of the service ontology. This other part of the service ontology consists of two parts: (1) the relationship between the pricing model concept and the conditional output concept and (2) the relationships between the conditional output concept and the property concept (see Figure 11). There is an indirect relationship between these two concepts in Figure 7, because the pricing model concept inherits the relationships of the conditional output concept. A direct relationship between the pricing model concept and the property concept is thus redundant. 62

63 Furthermore, there are two relationships between the pricing model concept and the property concept (see section 5.2.1). These relationships, including their cardinalities, are: 1. A pricing model determines the value of 1 property of a monetary resource. 2. A pricing model uses 0..* values of properties of resources. There are also two relationships between the conditional output concept and the property concept. These relationships are: 1. Conditional output has Range 1 property. 2. Conditional output has Domain 0..* property. The first relationship between the pricing model concept and the property concept corresponds with the first relationship between these two concepts. The same holds for the second relationship. Given that the pricing model concept inherits the relationships of the conditional output concept, the relationships can also be written as: pricing model has Range 1 property, and pricing model has Domain 0..* property. 5.4 Including useful information about the different types of pricing models From the literature overview chapter, it can be concluded that there are in total six types of pricing models applicable for service elements: four types for elementary service elements and two for service bundles. For a consistent use of these pricing models, it is useful to include their name and construction in the model proposal. This information can be included in two ways: 1. The different types of pricing models can be modeled as subtypes of the pricing model concept (the supertype). The subtype relationship is as follows: if concept B represents a concept that is a kind of A, then B is a subtype of A (Noy and McGuinness 2000). In other words, a subtype (B) represents a concept that is more specific than the supertype (A). 2. As attributes of the pricing model concept. However, there are several rules of thumb that help decide when to introduce a subtype, or not (Noy and McGuinness 2000). Some of these are: a subtype has additional properties that the supertype does not have, and a subtype participates in different relationships than the supertype. Due to these rules, the first approach described above is not applicable for the model proposal. This is because in this approach, the pricing model concept and its subtypes (the different types of pricing models) will have the same properties, namely, the name and construction of the formula. Additionally, the subtypes will participate in the same relationships as the pricing model concept. As a result, to include useful information of the different types of pricing models in the model proposal, this information must be modeled as attributes of the pricing model concept. 63

64 5.5 Key notes of the model proposal In short, the following relationships are applicable for pricing models of elementary service elements and service bundles: Pricing model has Range 1 property Pricing model has Domain 0..* property. 0..* pricing models can be assigned to 0..* service ports that indicate a monetary resource Additionally, the relationship 0..* pricing models can be assigned to 0..* links is also applicable for service bundles. Useful information of the different types of pricing models, the name and construction, is modeled as attributes of the pricing model concept. 5.6 Model proposal in an earlier stage of the research In an earlier stage of this research, a different model proposal to incorporate pricing models in the service ontology was considered. In this model proposal, there was one relationship between the service element concept and the pricing model concept. The relationship, including its cardinality, stated that a service element has 0..* pricing models. However, it was soon discovered that this proposal has several shortcomings. Some of these are: The properties of resources cannot be used in the pricing model, because there is no relationship between the pricing model concept and the property concept. In the literature overview chapter, it is stated that the pricing model of a bundle consists of the sum of the prices of the service elements that are part of the bundle. This model proposal does not support this, because it is not possible to use the pricing models of service elements that are part of the bundle to calculate its price. 64

65 Chapter VI Proposal to incorporate pricing models in a software tool In other research (Baida et al 2004c), a software tool has been developed which uses the domain knowledge that is modeled with the service ontology. The tool enables users to model services, based on the service ontology, by using a friendly graphical user interface. The goals of this software tool are: (1) modeling elementary service elements and supporting constructs, and (2) configuring service bundles using these elements as well as customer requirements. From this point forth in this research, the abovementioned software tool will be referred to as the service tool. This section discusses a proposal to incorporate pricing models in the service tool. This proposal is also discussed next to the proposal to incorporate pricing models in the service ontology, because the service tool uses the domain knowledge that is modeled with the service ontology, as described above. This chapter begins with the reasoning process of the model proposal. In the next section, the proposal to incorporate pricing models of service elements that are part of a service bundle will be discussed. After that, a mapping between this proposal and the proposal of the service ontology will be described. This mapping is only applicable for service bundles. The chapter ends with a discussion of a generalized algorithm that enables the service tool to calculate the prices of both elementary service elements and service bundles, based on their pricing models. 6.1 Reasoning about the proposal In this proposal, there is a distinction between the calculation of the price of an elementary service element and of a service bundle. The reason for this distinction is as stated in the literature overview chapter, that the price of a service bundle is calculated differently than that of an elementary service element. This is because a service bundle is sold at a discounted price. The proposal to incorporate pricing models of elementary service elements in the service tool is as described in the proposal of the service ontology (see section 5.2.3). Elementary service elements are thus not discussed again in this proposal. Two situations can occur in the proposal of the service tool when dealing with pricing models of service bundles: 1. A pricing model is assigned to a service bundle after it has been configured. In this situation, a pricing model can be assigned to the service elements that are part of the configured bundle, and to the bundle itself. A proposal for this situation in the service tool is as described in the proposal of the service ontology (see the sections until 5.2.7). Configured service bundles will thus not be discussed again in this proposal. 2. A pricing model is assigned to a service bundle before it has been configured. In order to achieve this, the service bundle must be simulated. However, the price of a service bundle can only be calculated if the bundle is configured (see section 6.3 for more details). Thus, the way to assign pricing models of a simulated bundle itself is not discussed in this proposal. This chapter will only discuss the 65

66 way to assign pricing models of the service elements that are part of a simulated service bundle. As stated in the ontologies chapter (section 4.1.1): configuration is a constructive task where predefined components are configured into a larger, complex component, based on the availability of a set of predefined connections, and associated parameters and constraints (Mittal & Frayman 1989, Löckenhoff & Messer 1994, Gruber et al. 1996). Applying configuration constructs to services means considering services to be components (a notion from configuration theory) that can be configured into a larger service bundle (complex component). 6.2 Proposal to incorporate pricing models of service elements that are part of a simulated service bundle This proposal consists of two functionalities which will be discussed in the following sections First functionality: Simulate bundle With this functionality it is possible to simulate service bundles. As an example, this functionality can be accessible through the main menu of the service tool. Consider that a user wants to simulate a service bundle. This can be achieved in three steps: 1. The user must model, or has already modeled, the service elements that must be included in the bundle. In this example, it is assumed that the user modeled four service elements: A, B, C and D. 2. The user can select the functionality Simulate bundle from the main menu of the service tool, which triggers the following screen. Note that all the screenshots in this proposal are suggestions of the way the proposal might look like in the service tool. Figure 12: Screenshot of the simulate bundle functionality in the proposal of the service tool 66

67 This screen displays all the modeled service elements from step 1. In this step, the user can select the service elements which must be included in the bundle. It is assumed that the user selects service elements A, B and C. 3. The user can click on OK to actually simulate the bundle, or click on Cancel to stop. In this example, it is assumed that the user chooses OK and thus simulates a bundle consisting of service elements A, B and C. It is further assumed that the user simulated a bundle consisting of service elements A and B Second functionality: Edit/assign pricing models of service elements that are part of a simulated bundle With this functionality, the user can edit or assign pricing models of the service elements that are part of a simulated service bundle. This functionality can for example be accessible through the main menu of the service tool. An example will use the service bundles that are simulated in section The first bundle consists of service elements A, B and C and the second of service elements A and B. The functionality Edit/assign pricing models of service elements that are part of a simulated bundle will be explained in five steps: 1. The user can select the functionality from the main menu of the service tool which triggers the following screen. Figure 13: Screenshot of step 1 in the Edit/assign pricing models of service elements that are part of a simulated bundle functionality in the proposal of the service tool In this screen, the user must select a simulated bundle in order to edit/assign pricing models of the service elements that are part of the bundle. It is assumed that the user chooses the service bundle consisting of service elements A, B and C and then clicks on OK. 2. After the user has selected a simulated bundle in step 1, the following screen is triggered. 67

68 Figure 14: Screenshot of step 2 in the Edit/assign pricing models of service elements that are part of a simulated bundle functionality in the proposal of the service tool This screen displays the service elements that are part of the selected bundle from step 1. Instead of having one screen per service element, all screens are united into one screen with a tab per service element. In this step, the user has to select a service element in order to edit/assign its pricing models. Figure 14 displays that the user selected service element A. The values that are displayed in this figure will be explained in steps 3 and Next, the user can edit/assign pricing models of the selected service element, which in this example is service element A. Not e that the pricing models that are assigned in this step belong to the selected service element when it is part of the selected simulated service bundle (from step 1). According to the proposal of the service ontology, multiple pricing models can be assigned to multiple service ports that indicate a monetary resource, which is also applicable for this proposal. Figure 14 displays that service element A has two service ports that indicate a monetary resource (X and Y). Furthermore, two pricing models are assigned to the service port indicating resource X, and one pricing model to the service port indicating resource Y. The user can assign multiple pricing models by clicking on In this step, a discount can be applied to the outcome of the pricing models that are assigned in step 3. According to the literature overview (see section 2.3.4), the discount is either a fixed amount or a percentage. In this example, the user chooses to apply a discount of 25% to the outcome of the pricing model that is assigned to the service port indicating resource Y (see Figure 14). 5. In the case that multiple pricing models are assigned in step 3, the user must also select which pricing model is set active. This is necessary since it must be known which pricing model must be used to calculate the price of the monetary resource. If only one pricing model is assigned to a service port that indicates a monetary resource, that pricing model is set active by default. The user can click on OK to save the changes, or click on Cancel to stop. 68

69 6.2.3 Representation of and the values used in the pricing models The representation of the pricing models of the service elements that are part of a simulated service bundle is in the form of a mathematical formula. The following situations can occur when the user wants to edit/assign the values used in the formulas of these pricing models. The user can manually edit/assign the values used in the pricing model The user can refer to the values of the properties of resources. This is discussed in the proposal of the service ontology in section The values may refer to the pricing model of the same service element, when it is not part of a simulated bundle. The user can assign a discount to the outcome of a pricing model. The user can use a combination of the above mentioned situations in a formula. Note that these situations apply to both configured service bundles and simulated service bundles in the service tool. 6.3 Mapping between simulated and configured service bundles In section 6.1, it is argued that the price of a service bundle can only be calculated if the bundle is configured. Additionally, it is stated that a proposal to incorporate pricing models of configured service bundles in the service tool is as described in the proposal of the service ontology (see the sections until 5.2.7). In this proposal it is stated that: The price of a service bundle consists only of the prices of the service elements that are part of the bundle with a link between the monetary service ports of these service elements and the monetary service ports of the bundle. This can only be derived if the service bundle is configured. As a result, this section describes a mapping between simulated service bundles (proposal of the service tool), and configured service bundles (proposal of the service ontology). This mapping is needed since the service tool is focused on configured service bundles, and the price of a service bundle can only be calculated if the service bundle is configured. The following mapping is applied when a simulated service bundle is the result of a configuration process: In the description of this mapping, a service bundle is simulated with the functionality Simulate bundle. Additionally, a pricing model of a service element, which is part of the simulated bundle, is assigned to a service port that indicates a monetary resource. This is achieved by using the functionality Edit/assign pricing models of service elements that are part of a simulated bundle. If the simulated bundle is a result of a configuration process, the aforementioned pricing model will be assigned to a link of the configured service bundle. The reason for this is as follows. The pricing model of the service element, which is part the simulated bundle, is a relationship between these two. According to the proposal of the service ontology, a link describes a relationship 69

70 between a bundle and a service element that is part of it. Therefore, a pricing model can be assigned to a link of the configured service bundle. Refer to section for more details. The following two situations can occur in the case that a pricing model is assigned to a link of a configured service bundle: 1. The pricing model is assigned to a link between a monetary service port of the configured service bundle and a monetary service port of the service element that is part of the bundle. 2. The pricing model is assigned to a link between the monetary service ports of two service elements that are part of the configured bundle. The proposal of the service ontology further explains the way the price of a configured service bundle is calculated (see sections until 5.2.7). 6.4 Algorithm to calculate prices of both elementary service elements and service bundles in the service tool This section describes a generalized algorithm that enables the service tool to calculate the prices of both elementary service elements and service bundles, based on their pricing models. The algorithm is based on the proposal of the service ontology. It is written in a Java like form. Java is a programming language developed by Sun Microsystems that creates code for (interactive) applications, which can execute on any platform 6 : Mac, PC, etc. The algorithm is displayed on the next page: 6 (last visited May 2005) 70

71 Figure 15: Algorithm to calculate the prices of elementary service elements and service bundles in the service tool

72 Lines 1 until 14 describe the specific terms used in the algorithm. The algorithm begins by entering the main method (line 16) to calculate the price of all service elements (line 17). This method returns no value, hence the void in line 16. In Java, void is used as a keyword in method declarations to specify that the method does not return a value 7. The algorithm continues by examining all elementary service elements (line 18). All the service ports that indicate a monetary resource of each elementary service element are then examined (line 19). The algorithm checks if there is a pricing model assigned to each of these service ports (line 20). If this is the case, the outcome of the pricing model (line 21) that is assigned to the service port will be calculated in the method Calulate_price_of_ESE. The pricing model that is assigned to the service port of the elementary service element itself is used as an input for this method, hence the (ESE.Port.PM) in line 21. In this method (line 41), the aforementioned pricing model is used to calculate its outcome (line 42). The method returns the outcome (line 43) as a double, hence the double in line 41. In Java, this is a number that can have decimal points (Horstmann 1998). A decimal point is a dot separating the ones and the tenths places in a decimal number 8 (e.g., 0.8, 8.33, and ). The algorithm continues by examining all service bundles (line 25). All the service ports that indicate a monetary resource of each service bundle are then examined (line 26). The algorithm checks if there is a pricing model assigned to each of those service ports (line 27). Two situations can then be applicable: 1. A pricing is assigned to a service port of the bundle that indicates a monetary resource. In this situation, the variable total_price_of_bundle is first set to zero (line 28). This is necessary since it is used to calculate the total price of the pricing model. The outcome of the pricing model (line 29) will then be calculated in the method Calulate_price_of_SB. The service bundle itself is used as an input for this method, hence the (SB) in line 21. This method will be explained after the second situation. 2. A pricing model is not assigned to a service port of the bundle that indicates a monetary resource (line 30). In this situation, the algorithm first checks if the value of the property of the resource (indicated by the service port) is known (line 31). In the case that the value is unknown, the variable total_price_of_bundle is first set to zero (line 32). The value of the property of the resource will then be calculated in the method Calulate_price_of_SB. The method Calulate_price_of_SB (line 46) is split up in two main parts: 1. The method checks all links between the service ports of the bundle and the service ports of the elementary service elements that are part of the bundle (line 47). All the service ports in this method indicate a monetary resource. Other elementary service elements that are part of the service bundle are not considered. This is because in the proposal of the service ontology, it is stated that: the price of a service bundle consists only of the prices of the service elements that are part of the bundle with a link between the monetary service ports of those service elements and the monetary service ports of the bundle (see section 5.2.5). In this first main part of the algorithm two situations can apply: 7 (last visited May 2005) 8 (last visited May 2005)

73 A pricing model is assigned to a link between a service port of the service bundle and a service port of the elementary service element that is part of the bundle (line 48). If this is the case, the pricing model assigned to the link is used to calculate the price of the bundle (line 49). This is because in the proposal of the service ontology, it is stated that: a pricing model assigned to a link is used to calculate the price of a bundle, i f this link is between the service ports of the service elements that are part of the bundle and the service ports o f the bundle itself (see section 5.2.7). There is no pricing model assigned to a link between a service port of the service bundle and a service port of the elementary service element (line 50). In this case, the pricing model of the elementary service element that is part of the bundle is used to calculate the price of the bundle (line 51). 2. The method checks all service bundles with a link between a service port of the main service bundle (SB) and another service bundle (SB*) (line 54). The service bundle (SB) of which the other service bundle (SB*) is a part, is referred to as the main service bundle. Other service bundles that are part of the main service bundle are not considered since their prices are not used to calculate the price of the bundle, as discussed above in the first part. In this second main part of the algorithm, two situations can apply: A pricing model is assigned to a link between a service port of the main service bundle and a service port of the bundle that is part of the main service bundle (line 55). If this is the case, the pricing model assigned to the link is used to calculate the price of the main service bundle (line 56). There is no pricing model assigned to a link between a service port of the main service bundle and a service port of the service bundle that is part of the main service bundle (line 57). In this case, the algorithm will recursively 9 calculate the price of the service bundle that is part of the main bundle (line 58), used as an input for the method Calulate_price_of_SB (hence the (SB.SB*) in line 58). When the algorithm is finished with the calculation of the price of the service bundle that is part of the main service bundle, that price is added to the price of the main service bundle (line 58). As soon as all the links between the service ports of the bundle and the service ports of the elementary service elements that are part of the bundle are examined, the method Calulate_price_of_SB returns the total price of the service bundle as a double (line 61). This algorithm does not calculate the price of all the service elements that are part of a service bundle, but only of those that are relevant in the calculation of the price. This is discussed above in the first part of the method Calulate_price_of_SB. 9 Recursion occurs when a method calls itself, either directly or by way of an intermediate method, source: (last visited April 2005) 73

74 Chapter VII Mapping between the service ontology and the e³-value ontology This chapter discusses the mapping of services, including their pricing models, between the service ontology and e³-value ontology. Both ontologies are described in chapter four. Baida et al. (2004a) present a methodology for a business analysis of e-service bundles for networked enterprises. The methodology consists of the following steps: 1. Create an initial business model, using the e³-value ontology. Elementary services can be identified in this model. 2. Model these services using the service ontology, and define feasible service bundles by applying this ontology. 3. Reason about the identified service bundles, using knowledge modeled in the service ontology, and choose the preferred service bundles. 4. Use the e³-value ontology to assess profitability of the chosen service bundles. To support this methodology, the service ontology needs to be mapped into the e³value ontology, and vice versa. Ontology mapping is defined as the task of relating the vocabulary of two ontologies tha t share the same domain of discourse in such a way that the mathematical structure of ontological signatures and their intended interpretations, as specified by the ontological axioms, are respected (Kalfoglou and Schorlemmer 2003). In other words, ontology mapping is a process of finding and defining commonalities between the ontologies. The discussion in this chapter is based on a mapping between the two ontologies, which is described by Baida (2004b). Since the focus of this research is on pricing models of services, the way these are mapped between the ontologies will also be discussed. If pricing models are mapped, it will become possible to calculate the eventual cash flow when the service ontology interacts with the e³-value ontology in the abovementioned methodology. This occurs in step 4 of the methodology, which is described above. This chapter does not discuss the complete mapping between the two ontologies, but only the mapping of services, including their pricing models. The pricing models are used in accordance with the model proposal to incorporate pricing models in the service ontology. This chapter is organized as follows. Firstly, the mapping from the service ontology into the e³-value ontology will be discussed. This mapping is divided into two parts: the way an elementary service element is mapped into the e³-value ontology, and the way a service bundle is mapped into the e³-value ontology. Secondly, the mapping from the e³-value ontology to the service ontology will be discussed. This mapping highlights the way an elementary actor and a composite actor are mapped into the service ontology. Thirdly, a description will be given of three problems that must be solved in order to successfully use pricing models in the e³-value ontology. 74

75 7.1 Mapping from the service ontology to the e³-value ontology Mapping of an elementary service element into the e³-value ontology The following figure displays the way an elementary service element, which is modeled with the service ontology, is mapped into the e³-value ontology. The numbers (no.) in the figure explain the way the mapping is done. For example, no. 1 in the service ontology is mapped as no. 1* in the e³-value ontology. Figure 16: Mapping of an elementary service element into the e³-value ontology The mapping is described in Table 19 below. Table 19: Mapping of an elementary service element into the e³-value ontology Number Service ontology e³-value ontology 1 Elementary service element Value activity that is performed by an elementary actor. 2a Input service port Value port that requests a value object. 2b Outcome service port Value port that offers a value object. - - The value ports are assigned to a value interface of the value activity. - - All the value interfaces related to a value activity appear also as value interfaces of the elementary actor. 75

76 Number Service ontology e³-value ontology 3a&b* - Value exchanges are added between a port related to a value activity, and the corresponding port related to an elementary actor. 4a Input resource Value object that is requested by a value port. 4b Outcome resource Value object that is offered by a value port. 5 Property of a resource This is not mapped. 6 Pricing model is assigned to an input service port. Pricing model is assigned to a value port that requests a value object indicating money. Some aspects of the mapping outlined in Table 19 require more details: Number 1: According to the e³-value ontology, a value activity is performed by precisely one elementary actor. Number 5: In the model proposal to incorporate pricing models in the service ontology, it is stated that a pricing model of a service element can use the values of properties of resources. In Figure 16, the pricing model of the elementary service element (no. 6) uses a value of a property of the product resource (no. 5). In the mapping, this information is lost in two ways: 1. The user can select which resources of which elementary service elements should be mapped. If a pricing model of an elementary service element uses the value of a property of a resource that is not mapped, this information is lost. 2. In the mapping described by Baida (2004b), it is stated that the properties of resources in the service ontology are not mapped between the two ontologies. This is due to the fact that the e³-value ontology does not include a similar construct. Number 6: In the model proposal to incorporate pricing models in the service ontology, it is stated that a pricing model can be assigned to a service port that indicates a monetary resource. The pricing model of the service element in Figure 16 is assigned to the input service port (no. 2a) that indicates a monetary resource (no. 4a). A monetary resource corresponds with a value object that represents money. A resource is mapped as a value object. An input service port of an elementary service element is mapped as a value port that requests a value object. An outcome service port of an elementary service element is mapped as a value port that offers a value object. These value ports are assigned to a value interface of the value activity. According to these mappings, a pricing model of an elementary service element that is assigned to an input or outcome service port is mapped into: a value port of a value activity that offers (outcome) or requests (input) a value object indicating money. The pricing model is in the form of a formula, which has the same format as the elementary service element. Additionally, in the e³-value ontology, a (valuation) formula assigned to a value por t can be used as a pricing model of a product. In Figure 16, the pricing model of the elementary service element is mapped into: the value port (no. 2a*) that requests the Fee value object (no. 4a*). The pricing model of the elementary service element uses a value of a property of the product resource. This information, however, will be lost in the mapping. This is due to the fact that properties of resources are not mapped between the two ontologies, as discusses above for Number 5. 76

77 This has the following consequences for the mapping of a pricing model of an elementary service element into the e³-value ontology: The values that are used in the pricing model must be mapped directly into the pricing model that is mapped into the e³-value ontology. In the case that the values of properties of resources must also be mapped, a construct must be added to the e³-value ontology that supports the mapping of these values Mapping of a service bundle into the e³-value ontology The figure on the next page displays the way a service bundle, which is modeled with the service ontology, is mapped into the e³-value ontology. The numbers (no.) in the figure explain the way the mapping is done. 77

78 Figure 17: Mapping of a service bundle into the e³-value ontology 78

79 The mapping is described in Table 20 below. Table 20: Mapping of a service bundle into the e³-value ontology Number Service ontology e³-value ontology 1 Service bundle Composite actor. 2a,b Elementary service element Value activity performed by an elementary actor. 3a,b,c,d Links Value exchanges are added between a port related to an elementary actor and the corresponding port related to a composite actor. 4 Pricing model is assigned to a link. Pricing model is assigned to the corresponding value exchange. 5a,b Pricing models of the elementary service elements are assigned to the input service ports. Pricing models are assigned to the value ports that request a value object indicating money. 6 Input service port of the bundle. This is not mapped. 7 Pricing model of the bundle is This is not mapped. assigned to the input service port. 8a&b - All the value interfaces related to elementary actors are grouped into one value interface on the composite actor level (this is the idea of bundling). Some aspects of the mapping outlined in Table 20 require more details: Number 1: In the mapping described by Baida (2004b), it is stated that the e³-value ontology does not include the notion of a composite value activity, which would be equivalent to a service bundle in the service ontology. Elementary service elements that are part of the service bundle are mapped as value activities (see section 7.1.1). The only way to represent multiple value activities as one whole (the service bundle) is by bundling several value activities into one actor: the composite actor. Number 2a&b: The mapping of elementary service elements (2a&b) that are part of the service bundle is as described in the mapping of an elementary service element into the e³-value ontology (see section 7.1.1). Number 4: A link is mapped as a value exchange between a port related to an elementary actor and the corresponding port related to a composite actor. Therefore, a pricing model assigned to a link (no. 3a) is mapped into: a value exchange (no. 3a*) between a port related to an elementary actor and the corresponding port related to a composite actor. In the case that a pricing model assigned to a link uses values of properties of the resources, this information will be lost in the mapping. This is due to the fact that properties of resources are not mapped between the two ontologies. This has the same consequences for the mapping of the pricing model, as the ones described in the mapping of a pricing model of an elementary service element into the e³-value ontology. Number 5a&b: The mapping of the pricing models of the elementary service elements (5a&5b) is as described in section Number 6: A service port is mapped as a value port. The service input port of the bundle (no. 6) is not mapped into the e³-value ontology. This is because that port is a composite service port, and the e³-value ontology does not include the notion of a composite value port. In the service ontology chapter (see section 4.1.1), it is stated that compositeness refers to whether and how two or more resources of the same type can be united into and modeled as one resource, when they appear in the same interface. The port compositeness describes whether the resource in the port should be composed.

80 Number 7: The pricing model of the service bundle that is assigned to a composite input service port cannot be mapped into the e³-value ontology, because the ontology does not include the notion of a composite value port. This is a bottleneck in the mapping, which will not be dealt with here due to the resource limitations of this project Conclusions of the mapping from the service ontology to the e³-value ontology This section summarizes which information can be mapped, and which information is lost in the mapping of pricing models of both elementary service elements and service bundles into the e³-value ontology. Information concerning pricing models of elementary service elements that can be mapped A pricing model of an elementary service element that is assigned to an input or outcome service port is mapped into: a value port of a value activity that offers (outcome) or requests (input) a value object indicating money. Information concerning pricing models of elementary service elements that cannot be mapped The values of properties of resources in the service ontology are not mapped into the e³-value ontology. This is due to the fact that the e³-value ontology does not include a similar construct. Hence, if a pricing model of an elementary service element uses the values of properties of resources, this information will be lost in the mapping. This has the following consequences for the mapping of a pricing model of an elementary service element into the e³-value ontology: The values that are used in the pricing model must be mapped directly into the pricing model that is mapped into the e³-value ontology. In the case that the values of properties of resources must also be mapped, a construct must be added to the e³-value ontology that supports the mapping of these values. Information concerning pricing models of service bundles that can be mapped Which information can be mapped, and which information is lost in the mapping of pricing models of elementary service elements that are part of a service bundle is as described above. A pricing model assigned to a link is mapped into: a value exchange between a port related to an elementary actor and the corresponding port related to a composite actor. Information concerning pricing models of service bundles that cannot be mapped In the case that the pricing model assigned to a link uses values of properties of resources, this information will be lost in the mapping. This is due to the fact that properties of resources are not mapped between the two ontologies. This has the same consequences for the mapping of the pricing model, as the ones described above for elementary service elements. A pricing model of a service bundle that is assigned to a composite service port of a service bundle cannot be mapped into the e³-value ontology, because the ontology does not include the notion of a composite value port. 80

81 7.2 Mapping from the e³-value ontology to the service ontology Mapping of an elementary actor into the service ontology This section describes the way an elementary actor, which is modeled with the e³-value ontology, is mapped into the service ontology. Besides pricing models, this mapping is the opposite of mapping an elementary service element into the e³-value ontology. More details about the mapping of pricing models will be explained underneath Figure 18. The numbers (no.) in the figure clarify the way the mapping is done. For example, no. 1 in the e³-value ontology is mapped as no. 1* in the service ontology. 3b Product 2b 3a Fee 2a 1 Value activity Elementary actor Pricing model is assigned to a port that requests a value object 4 e³-value ontology service ontology 3a* 3b* Fee Product 2a* 1* 2b* Elementary service element Pricing model is assigned to this input service port 4* Figure 18: Mapping of an elementary actor into the service ontology From the opposite mapping (see section 7.1.1), it can be derived that a pricing model assigned to a value port of a value activity that offers or requests a value object indicating money is mapped into: an input (requesting) or outcome (offering) service port that indicates a monetary resource. The values of properties of resources are not mapped between the two ontologies. This has the following consequences for the mapping of a pricing model assigned to a value port of a value activity into the service ontology: The values that are used in the pricing model must be mapped directly into the pricing model that is mapped into the service ontology. Consider for example that a pricing model in the service ontology uses values, which are modeled as values of properties of resources. In this case, the dependency between these values must be manually added to the pricing model after the mapping. 81

82 7.2.2 Mapping of a composite actor into the service ontology This section describes the way a composite actor, which is modeled with the e³-value ontology, is mapped into the service ontology. Besides the pricing models, this mapping is the opposite of mapping a service bundle into the e³-value ontology. More details about the mapping of pricing models will be explained underneath Figure 19. The numbers (no.) in the figure explain the way the mapping is done. Figure 19: Mapping of a composite actor into the service ontology 82

83 The way pricing models are mapped in this mapping will be described in three parts: Part 1: A pricing model (no. 5) assigned to a value exchange (no. 3a) between a port related to an elementary actor and the corresponding port related to a composite actor is mapped into: the corresponding link (no. 3a*). The values of properties of resources are not mapped between the two ontologies. This has the same consequences for the mapping of the pricing model, as the ones described in the mapping of an elementary actor into the service ontology (see section 7.2.1). Part 2: A pricing model assigned to a value port of a value activity is mapped in accordance with the mapping of an elementary actor into the service ontology (see section 7.2.1). Part 3: A pricing model which is assigned to a value port of a composite actor that offers or requests a value object indicating money is not mapped into the service ontology. This is due to the fact that a service port of a service bundle can be composite, and the e³-value ontology does not include the notion of a composite value port (service ports are mapped as value ports). Although the pricing model is not mapped into the service bundle, its price can be derived from the pricing models that are assigned to the links of the bundle and the service elements that are part of the bundle. This is due to the fact that in the model proposal of the service ontology, it is stated that the price of a service bundle consists only of the prices of the service elements that are part of the bundle with a link between the monetary service ports of these service elements and the monetary service ports of the bundle. Additionally, a pricing model assigned to a link is used to calculate the price of a bundle, if this link is between the monetary service ports of the service elements that are part of the bundle and the monetary service ports of the bundle itself (see sections and for more details). A monetary service port is referred to as a service port that indicates a monetary resource Conclusions of the mapping from the e³-value ontology to the service ontology This section summarizes which information can be mapped, and which information is lost in the mapping of pricing models when dealing both elementary actors and composite actors into the service ontology. Information concerning pricing models when dealing with elementary actors that can be mapped A pricing model that is assigned to a value port of a value activity that offers or requests a value object indicating money is mapped into: an input (requesting) or outcome (offering) service port that indicates a monetary resource. Information concerning pricing models when dealing with elementary actors that cannot be mapped There is no information lost in this mapping. Given that values of properties of resources, which can be used by pricing models in the service ontology, are not mapped between the two ontologies, this has the following consequences for pricing models assigned to a value port of a value activity: The values that are used in the pricing model must be mapped directly into the pricing model that is mapped into the service ontology. Consider for example that a pricing model in the service ontology uses values, which are modeled as values of properties of resources. In this case, the 83

84 dependency between these values must be manually added to the pricing model after the mapping. Information concerning pricing models when dealing with composite actors that can be mapped Which information can be mapped, and which information is lost in the mapping of pricing models used for elementary actors that are part of a composite actor is as described above. A pricing model assigned to a value exchange between a port related to an elementary actor and the corresponding port related to a composite actor is mapped into: the corresponding link. Information concerning pricing models used for composite actors that cannot be mapped The values of properties of resources are not mapped between the two ontologies. This has the same consequences for the mapping of a pricing model assigned to a value exchange, as the ones described above for a value activity. A pricing model which is assigned to a value port of a composite actor is not mapped into the service ontology. This is due to the fact that a service port of a service bundle can be composite, and the e³-value ontology does not include the notion of a composite value port. 7.3 Problems with pricing models in the e³-value ontology The previous sections describe the mapping of pricing models between the service ontology and the e³-value ontology. In addition, this section discusses three problems that must be solved in order to successfully use pricing models in the e³-value ontology. Consider the following example to understand the first problem that occurs when pricing models are used in a value model. A value model is expressed using the e³-value ontology. Figure 20: First problem with bundling in the e³-value ontology 84

85 In this value model (Figure 20), there is one composite provider actor that consists of two elementary provider actors. These two elementary provider actors sell a product to the customer, and thus both must receive a fee from the customer. Furthermore, the products are sold to the customer as a bundle. In the value model, the composite actor has one value interface that consists of three value ports, two ports for the products and one port for the fee. In addition, the value interface of the customer actor also consists of three value ports. The value interfaces represent the bundle that the customer purchases. The problem highlighted by this example is that the fee in the value interface of the composite provider actor is divided between the two elementary provider actors (see the lines in bold in Figure 20). Such a division in the value interface means that elementary actor provider 1 or elementary actor provider 2 receives this fee. However, both elementary provider actors must receive a fee, since both sell a product. The problem outlined above can be solved by adding a value port to the interface of the composite provider actor and the customer actor. Therefore, the value model displayed in Figure 20 will be revised as follows. Figure 21: Second problem with bundling in the e³-value ontology The main difference between this value model and the one displayed in Figure 20 is that in this model, the customer pays two fees for the bundle. However, in practice, a company charges a customer only one fee for a bundle. Due to this contradiction, the revised value model displayed in Figure 21 is not a suitable solution for the above outlined problem. 85

86 The second problem occurs when a pricing model for a subscription is modeled. Consider the following example: a customer purchases a subscription for 10 at an online music store, and can download an unlimited amount of mp3 songs during a given period. Thus, it is not known in advance how many mp3 s a user will download in the given period. This subscription cannot be modeled with the e³-value ontology because it is unknown how many value exchanges (downloaded mp3 s) must be modeled. Furthermore, it is not possible to model multiple exchanges (mp3 s) in return for one exchange (the payment of 10). This is because assigning cardinality to a value exchange is not supported by the e³-value ontology. The third problem that occurs is that it is not possible yet to add multiple valuation formulas for a single product. In a value model, which is expressed using the e³-value ontology, a valuation formula attached to a value port or a value exchange can be used as a pricing model of a product. In practice, multiple pricing models can often be applicable for a product. Consider for example the electricity supply service described in the SINTEF case study (Morch et al. 2004). There are four pricing models applicable for this service: variable, fixed, spot-hourly, and spot-monthly. The type of the pricing model does not depend on the type of the customer (e.g. household or industrial). Moreover, the customer can choose which pricing model must be applied when the service is purchased. Further analysis of these, and other possible problems, falls beyond the scope of this project. Further research is needed to find other possible problems that can arise when pricing models are incorporated into the e³-value ontology. In addition, more research is required to find suitable solutions for the problems that are mentioned in this section. 86

87 Chapter VIII Validation Validation is an essential step in a research since the outlined theories are being tested. If the theories are not based on sound facts and good arguments, they will not pass the validation test. This chapter describes the validation of the theories that are outlined in this research. These theories can be divided in two parts: the findings of the literature overview and the model proposal to incorporate pricing models in the service ontology. Both parts of this research must be validated. The proposal to incorporate pricing models in the service tool will not be validated in this research, because the validation of that proposal requires it to be implemented in the service tool. Additionally, the conceptual model (service ontology) behind the tool is one of the core elements of this research, and this is being validated. In the first section of this chapter, the validation process will be described. In the second section, the findings from the literature overview will be validated. In the third section, the model proposal to incorporate pricing models in the service ontology will be validated. In the fourth and final section, the conclusions of the validation will be presented. 8.1 Validation process The findings of the literature overview are the representations of the four types of pricing models of elementary services, and the two types that are applicable for service bundles. The representations can either be textual and mathematical, in the form of a formula. The model proposal to incorporate pricing models in the service ontology uses the findings of the literature overview as a starting point. Given that the service ontology must be applicable in practice, research done on the ontology must also be so. As a result, services from practice are the starting point of the validation of the theories outlined in this research. The services identified in the case study chapter, which is based on the SINTEF and SENA case studies, will be used to validate the findings of the literature overview. The validation will test whether these findings are representative for the services identified in the case studies. Moreover, the validation will test whether the services from practice, and especially their pricing models, can be modeled in accordance with the model proposal to incorporate pricing models in the service ontology. The following steps are followed to achieve this: Step 1: Identify the relationships of the model proposal that are relevant for the modeling of a service, including its pricing model(s). Step 2: Explain and then display the way a service is modeled. Also display the way the pricing models of the service are modeled in accordance with the identified relationships in the model proposal. Step 3: Explain the way the pricing models of a service are modeled in accordance with the identified relationships in the model proposal. Also explain where the information used by the pricing model is modeled. 87

88 8.2 Validating the findings of the literature overview The findings of the literature overview are the textual and mathematical representations (formula) of the four types of pricing models of elementary services, and the two types that are applicable for services bundles. In this section, the representations of the pricing models of elementary services, and service bundles will be validated Validating the representations of the pricing models of elementary services The representations of the four types of pricing models of elementary services are validated when they are representative for services from practice. These four types are: the flat-rate, two-part tariff, usage-based, and n-block tariff pricing models. The textual representations of these pricing models are described in the literature overview in Table 7. The formulas are also described in the literature overview chapter in Table 12. The services from practice that will be used in this validation are those that are identified in the case study chapter, which is based on the SINTEF and SENA case studies. Validation with the SINTEF case study From the SINTEF case study chapter, it can be concluded that the textual representation of the pricing models used in the case study correspond with a textual representation of one of the four types of pricing models identified in the literature overview. The mathematical representation (formula) of pricing models of three services from the case study (electricity transmission, ASP, and heat pump) differs slightly from the corresponding types of pricing models that are mentioned above. This is discussed further below for each service. The seasonal household and power industrial pricing models of the electricity transmission service correspond with the two-part tariff pricing model. However, the formulas of the seasonal household and power industrial pricing models have multiple usage-based parts, whereas the formula of the corresponding two-part tariff pricing model has one usage-based part. In the SINTEF case study chapter, it is stated that the seasonal household and power industrial pricing models are a further specification of the corresponding two-part tariff pricing model. This is because of the following two reasons: (1) the textual representation of the seasonal household and power industrial pricing models corresponds with that of the two-part tariff pricing model, and (2) the formula of the seasonal household and power industrial pricing models is a valid mathematical formula. The pump type pricing model of the heat pump service corresponds with the flat-rate pricing model. The formula of the pump type pricing model consists of multiple fixed parts, whereas the formula of the corresponding flat-rate pricing model consists of one fixed part. Furthermore, in the SINTEF case study chapter it is stated that the pump type pricing model is a further specification of the corresponding flat-rate pricing model, because of the following reasons: (1) the textual representation of the pump type pricing model corresponds with that of the flat-rate pricing model, and (2) the formula of the pump type pricing model is a valid mathematical formula. 88

89 The remote connection subscription pricing model of the ASP-service corresponds with the flat-rate pricing model. According to the SINTEF case study, the remote connection subscription pricing model is the same further specification of the flat-rate pricing model, as discussed for the pricing model of the heat pump service. The remote connection subscription & helpdesk pricing model of the ASP-service corresponds with the two-part tariff pricing model. The formula of the remote connection subscription & helpdesk pricing model has multiple fixed parts, whereas the formula of the corresponding two-part tariff pricing model has one fixed part. In the SINTEF case study chapter it is stated that the remote connection subscription & helpdesk pricing model is a further specification of the corresponding two-part tariff pricing model, because of two reasons: (1) the textual representation of the remote connection subscription & helpdesk pricing model corresponds with that of the two-part tariff pricing model, and (2) the formula of the remote connection subscription & helpdesk pricing model is a valid mathematical formula. Validation with the SENA case study From the SENA case study chapter it can be concluded that the textual representation of the identified pricing models from the case study corresponds with one of the four types of pricing models of elementary services. To highlight this, two pricing models that are identified in the SENA case study will be used as examples. The pricing models are used by an Internet radio station, which makes use of the Music Rights Clearance (MRC) service. The textual representation of the first pricing model is Internet radio station must pay a fee per-listener-per-track. That of the second pricing model is Internet radio station must pay a fixed fee to stream music. The first pricing model corresponds with the usage-based pricing model, while the second corresponds with the flat-rate pricing model. Thus, the corresponding textual representation of the first pricing model is the user is charged on basis of usage, and of the second pricing model is the user pays a fixed amount which is independent of usage. From the SENA case study chapter, it can be concluded that the mathematical representation (formula) of the identified pricing models from the case study corresponds with one of the four types of pricing models of elementary services. To highlight this, the formulas of the pricing models from the above examples will be outlined. The formula of the first pricing model from the example is x numberof-listeners-per-track, and the formula of the second pricing model is fixed fee (e.g. 50). The corresponding formula of the first pricing model is C = p x q, while the one of the second pricing model is C = Fix. Refer to in the literature overview for more details about these two aforementioned formulas Validating the representations of the pricing models of service bundles The representations of the two pricing models of service bundles are validated when they are representative for services from practice. The textual representations of these pricing models are described in the literature overview in section 2.2. The formulas are described in the literature overview chapter in Table 13. The studied literature, examples of service bundles in practice, and the case studies do not give enough detailed information on the representations of pricing models of service bundles. Nonetheless, it can be argued that the representations of the two pricing models that are applicable for services bundles are representative for services in practice, given that the pricing models 89

90 are partially derived from the way service bundles are priced in practice. This is discussed in the literature overview in section Validating the model proposal to incorporate pricing models in the service ontology The proposal to incorporate pricing models in the service ontology is discussed in chapter five. The service sub-ontology representing the model proposal to incorporate pricing models in the service ontology is displayed below. Figure 22: Service sub-ontology representing the proposal to incorporate pricing models The proposal is validated when services from practice, and especially their pricing models, can be modeled in accordance with the model proposal. In the validation, the model proposal for both elementary service elements and service bundles will be analyzed. 90

91 8.3.1 Validating the model proposal for elementary service elements Two elementary service elements, providing hot water and ASP, from the SINTEF case study chapter will be used as examples to validate the model proposal for elementary service elements. The validation will be done in three steps, as described in the validation process. Step 1: Relationships applicable for elementary service elements According to proposal to incorporate pricing models in the service ontology (see section 5.5), the following relationships (including the cardinality) are applicable for elementary service elements: * pricing models can be assigned to 0..* service ports that indicate a monetary resource. (the cardinality 0..* must be read as zero or more) 2. pricing model has Range 1 property, and pricing model has Domain 0..* property. Step 2: Elementary service element providing hot water According to the SINTEF case study chapter, the providing hot water service is an elementary service element that has one service input (payment), and two service outcomes (energy and energy reduction). A service input is a resource that is a prerequisite for a specific service element, while a service outcome is a resource that is the result of a specific service element. Furthermore, from the SINTEF case study it can be derived that there is one pricing model applicable for the providing hot water service, namely the standard pricing model. It is further stated that this pricing model corresponds with the two-part tariff pricing model. Figure 23 displays the elementary service element providing hot water. The figure also displays the way the standard pricing model of the elementary service element is modeled in accordance with the model proposal. More details about this are given in step 3. Figure 23: Elementary service element 'providing hot water' in the validation 91

92 Step 3: Modeling of the pricing model Note that the values used in Figure 23 are derived from an example that is discussed in the SINTEF case study. The discussion of the way the pricing model of the elementary service element providing hot water is modeled in accordance with the model proposal is divided in three parts (1, 2, and 3 in Figure 23). This discussion explains which relationships identified in step 1 support the modeling of the pricing model of this elementary service element. Part 1: The pricing model uses information that is modeled as a value of a property of the energy resource. This value is the domain of the pricing model. Part 1 is supported by the following relationship of the model proposal: pricing model has Domain 0..* property. Note that the prices ( 45 and 0.08) used by the pricing model (see part 2) are added directly in the pricing model. However, if these prices were assigned to one or more properties of a resource, then they would be domains of the pricing model. Part 2: The pricing model of the elementary service element is assigned to the service port that indicates a monetary resource, in this case the payment resource. Additionally, the range and domain of the pricing model are also displayed in part 2. The range is a value of a property of the payment resource, and the domain is a value of a property of the energy resource. Part 2 is supported by the following relationships of the model proposal: 0..* pricing models can be assigned to 0..* service ports that indicate a monetary resource, pricing model has Range 1 property, and pricing model has Domain 0..* property. Part 3: The outcome of the pricing model is modeled as a value of a property of the payment resource. This value is the range of the pricing model. Part 3 is supported by the following relationship of the model proposal: pricing model has Range 1 property. The second service that is used in the validation of the model proposal for elementary service elements is the ASP-service. This service element is displayed in Figure 24. The validation will be done in three steps as described in the validation process. Step 1: is the same as described above. Step 2: Elementary service element ASP-service The ASP-service has two service inputs (broadband Internet and payment) and two services outcomes (office application usage and support). From the SINTEF case study chapter, it can be derived that there are four pricing models applicable for the ASP-service, namely the basic subscription, remote connection subscription, basic subscription & helpdesk, and remote connection subscription & helpdesk. The ASP-service is always sold with the basic subscription, which is thus included in the remote connection subscription. Moreover, in the SINTEF case study it is stated that the first two pricing models correspond with the flat-rate pricing model. The third and fourth pricing models correspond with the two-part tariff pricing model. In the validation, the ASP-service is modeled with support as a resource outcome. The ASP-service can be modeled in different ways, which will not be discussed here since they are not relevant for the validation. The basic subscription & helpdesk and remote connection & helpdesk pricing models are applicable for the ASPservice that is modeled in Figure 24. Moreover, it is assumed that the ASP-service is 92

93 offered with remote connection, which means that only the remote connection & helpdesk pricing model is applicable for the service. Figure 24 displays the way the remote connection & helpdesk pricing model of the ASP-service is modeled in accordance with the model proposal. More details about this are given in step 3. Figure 24: Elementary service element ASP-service in the validation Step 3: Modeling of the pricing models Note that the values used in Figure 24 are derived from an example that is discussed in the SINTEF case study (the 15 hours for the support resource outcome is an estimation). The discussion of the way the pricing model of the elementary service element ASP-service is modeled in accordance with the model proposal is divided in three parts (1, 2, and 3 in Figure 24). This discussion explains which relationships identified in step 1 support the modeling of the pricing model of this elementary service element. Part 1: The pricing model uses information that is modeled as a value of a property of the office applications usage resource. This value is the domain of the pricing model. Part 1 is supported by the following relationship of the model proposal: pricing model has Domain 0..* property. Part 2: The pricing model of the elementary service element is assigned to the service port that indicates a monetary resource, in this case the payment resource. Additionally, the ranges and domain of the pricing model are also displayed in part 2. The range is a value of properties of the payment resource, and the domain is a property of the support resource. Part 2 is supported by the following relationships of the model proposal: 0..* pricing models can be 93

94 assigned to 0..* service ports that indicate a monetary resource, pricing model has Range 1 property, and pricing model has Domain 0..* property. Part 3: The outcome of the pricing model is modeled as a value of the property of the payment resource. This value is the range of the pricing model. Part 3 is supported by the following relationship of the model proposal: pricing model has Range 1 property Validating the model proposal for service bundles This section discusses the validation of the model proposal for service bundles. Given that in the proposal for the service ontology, a distinction is made between two ways to calculate the price of a service bundle, this distinction is also made in the validation of the model proposal for service bundles. As discussed in the literature overview, the two ways to calculate the price of a service bundle are: 1. The price of the service bundle is calculated by applying a specific price discount, which is calculated from the combined prices of the service elements that are part of the bundle. 2. First a discount is applied to the price of one or more service elements that are part of the service bundle. Then the price of the bundle is calculated by adding up these prices. The validation will be done in three steps as described in the validation process. Validating the first way to calculate the price of a service bundle: Step 1: Applicable relationships From the proposal of the service ontology (see section 5.5), it can be derived that the following relationships (including the cardinality) are applicable for service bundles. These relationships apply when considering the first way to calculate the price of a service bundle * pricing model can be assigned to 0..* service ports that indicate a monetary resource. 2. pricing model has Range 1 property, and pricing model has Domain 0..* property. Step 2: Service bundle electricity supply, ASP-service, and broadband access The SINTEF case study describes a service bundle electricity supply, ASP-service, and broadband access, which will be used in the validation. The service bundle is displayed in Figure 25. Since the service bundle is not modeled with the service ontology in the SINTEF case study, it is unknown which service inputs and outcome(s) the bundle exactly has. In this validation, it is assumed that the following services are at least part of the bundle: electricity supply, broadband access and ASP. Furthermore, it is assumed that another service element, service X, is part of the service bundle. Other services that may be part of the service bundle are not considered in the validation. The service bundle has three service inputs (see Figure 25): payment, lock-in and broadband access. The SINTEF case study does not discuss a pricing model of the service bundle, and thus it is assumed that the service bundle has one pricing model. It is further assumed that the service bundle is sold with a discount of 15%, which means that the outcome of the pricing model of the bundle is deducted by this percentage. Figure 25 displays the service bundle electricity supply, ASP-service, and broadband access. In step 3, more 94

95 details are given about the way the pricing model of the service bundle and the pricing model of the service elements that are part of the bundle are modeled in accordance with the model proposal. Figure 25: Service bundle electricity supply, ASP-service, and broadband access Note that the values used in Figure 25 are derived from an example that is discussed in the SINTEF case study. The figure displays that the service bundle and the services that are part of the service bundle are modeled as service elements. The figure only displays the resources that are needed to calculate the price of the service bundle. Additionally, the figure displays the outcomes of the pricing models of the service elements that are part of the service bundle. These pricing models are assigned to a service port of the service element that indicates a monetary resource (payment resource). The lines in bold in Figure 25 are the links between the service elements that are part of the service bundle and the bundle itself. These links are in bold because in the proposal to incorporate pricing models in the service ontology chapter, it is clearly stated that: the combined price of a service bundle consists only of the prices of the service elements that are part of the bundle with a link between the monetary service ports of these service elements and the monetary service ports of the bundle. The pricing model that is assigned to the input service port of service element X is thus not used to calculate the price of the service bundle. 95

96 Step 3: Modeling of the pricing models Figure 25 displays the way the pricing model of the service bundle, and the pricing model of the service elements that are part of the bundle, are modeled in accordance with the model proposal. This is divided into two parts (1 and 2 in Figure 25). Additionally, the discussion also explains which relationships identified in step 1 support the modeling of the pricing model of this service bundle. Part 1: The pricing model of the service bundle, and the pricing models of the service elements that are part of the bundle are assigned to a service port that indicates a monetary resource, in this case the payment resource. Additionally, the range and domains of the pricing model of the service bundle are displayed in part 1. The range is the value of a property of the payment resource. The domains are the outcomes of the pricing models of the service elements that are used to calculate the price of the bundle. This price is calculated by first adding up PM1, PM2 and PM3, and then multiplying the sum by 85%. In this example, a 15% discount has been applied to the price of the bundle, which means that the sum of the prices is multiplied by 85% (100% - 15%). This is because the formula of a pricing model must be a valid mathematical formula. Part 1 is supported by the following relationships of the model proposal: 0..* pricing models can be assigned to 0..* service ports that indicate a monetary resource, pricing model has Range 1 property, and pricing model has Domain 0..* property. Part 2: The outcome of the pricing model is modeled as a value of a property of the payment resource. This value is the range of the pricing model. Part 2 is supported by the following relationship of the model proposal: pricing model has Range 1 property. Below is the validation of the model proposal, when considering the second way to calculate the price of service bundles. The validation will be done in three steps, as described in the validation process. Validating the second way to calculate the price of a service bundle: Step 1: Applicable relationships According to proposal to incorporate pricing models in the service ontology (see section5.5), the following relationships (including the cardinality) are applicable for service bundles. These relationships apply when considering the second way to calculate the price of a service bundle * pricing model can be assigned to 0..* service ports that indicate a monetary resource. 2. pricing model has Range 1 property, and pricing model has Domain 0..* property * pricing model can be assigned to 0..* links Step 2: Service bundle dialup and hosting A list with service bundles from practice is given in the literature overview. The service bundle dialup and hosting from this list will be used to validate the model proposal for service bundles, when considering the second way to calculate the price of a service bundle. Since the service bundle is not modeled with the service ontology, it is unknown which service inputs and outcome(s) the bundle exactly has. It is assumed that at least the dialup and hosting services are part of the bundle. Furthermore, it is assumed that 96

97 another service element, service X, is part of the service bundle. Other services that may be part of the service bundle are not considered in the validation. It is further unknown which pricing model the service bundle has, and thus in the validation it is assumed that the service bundle has one pricing model. It is further assumed that a discount of 10% is applied to the price of the services that are part of this bundle. Figure 26 displays the service bundle dialup and hosting. Figure 26: Service bundle dialup and hosting in the validation Note that the values used in Figure 26 are estimations. The figure displays that the service bundle and the services that are part of the service bundle are modeled as service elements. The figure only displays the resources that are needed to calculate the price of the service bundle. The figure shows the outcomes of the pricing models of the services that are part of the service bundle. These pricing models are assigned to a service port of the service element that indicates a monetary resource (payment resource). Furthermore, there is a pricing model assigned to all links of this service bundle, because the service elements that are part of the service bundle are sold at a discounted price. The lines in bold in Figure 26 are the links between the service elements that are part of the service bundle, and the service bundle itself. These links are in bold because in the proposal to incorporate pricing models in the service ontology (see section 5.2.7), it is clearly stated that: the combined price of a service bundle consists only of the prices of the service elements that are part of the bundle with a link between the monetary service ports of these service elements and the monetary service ports of the service bundle. Moreover, it is stated that: a pricing model assigned to a link is only used to calculate the price of a bundle, if this link is between the service elements that are part of the bundle, and the bundle itself. The pricing model that is 97

98 assigned to the link between the hosting service element and service element X is thus not used to calculate the price of the service bundle. The same stands for the pricing model that is assigned to the input service port of service element X. Step 3: Modeling of the pricing models Figure 26 also displays the way the pricing model of the service bundle, and the pricing model of the service elements that are part of the service bundle, are modeled in accordance with the model proposal. This discussion of the way the pricing model of the service bundle is modeled in accordance with the model proposal is divided in three parts (1, 2 and 3 in Figure 26). Additionally, the discussion explains which relationships identified in step 1 support the modeling of the pricing model of this service bundle. Part 1: The services that are part of the service bundle are sold at a 10% discounted price, because they are part of the service bundle. As a result, the discount of the prices must also be modeled. The pricing models, with the discount applied, of the dialup and hosting service elements are added to the links in bold between the service elements and the service bundle. The pricing model, with the discount applied, of service element X is assigned to the link between service element X and the hosting service element. In this example, a 10% discount has been applied to the price of the services, which means that the outcome of the pricing model of these services is multiplied by 90% (100% - 1%). Part 1 is supported by the following relationship of the model proposal: 0..* pricing models can be assigned to 0..* links. Part 2: The pricing model of the service bundle, and the service elements that are part of the bundle, are assigned to a service port that indicates a monetary resource, in this case the payment resource. Additionally, the range and domains of the pricing model of the service bundle are also displayed in part 2. The range of the pricing model of this service element is the value of a property of the payment resource. The domains are the outcomes of the pricing models that are assigned to the links in bold of the service bundle. Part 2 is supported by the following relationships of the model proposal: 0..* pricing models can be assigned to 0..* service ports that indicate a monetary resource, pricing model has Range 1 property, and pricing model has Domain 0..* property. Part 3: The outcome of the pricing model is modeled as a value of a property of the payment resource. This value is the range of the pricing model. Part 3 is supported by the following relationship of the model proposal: pricing model has Range 1 property. 8.4 Conclusions of the validation The findings from the literature overview are now validated since the textual and mathematical representations of the pricing models of elementary services and service bundles are representative for services from practice. In addition, the formulas of pricing models of the electricity supply, heat pump, and ASP services identified in the SINTEF case study chapter, are a further specification of the flat-rate and two-part tariff pricing model. The model proposal to incorporate pricing models in the service ontology has been validated given that services from practice, and especially their pricing models, can be modeled in accordance with the model proposal. 98

99 Shortcomings of the validation The validation has the following shortcomings. First of all, the validation of the model proposal to incorporate pricing models of services (elementary and bundled) in the service ontology was tested with only few services from practice. This is due to resource limitations of this project. Second of all, various assumptions were made in the validation of the model proposal to incorporate pricing models of service bundles. One reason for this is that the SINTEF and SENA case studies do not give enough details about the pricing models of service bundles. Another reason is that not many variants of pricing models of service bundles are discussed, as can be concluded from the literature overview. Moreover, the literature overview also shows examples of service bundles from practice that do not give enough detailed information about the constructs of pricing models used for service bundles. 99

100 Chapter IX Conclusion The main question posed at the beginning of this work was the way pricing models can be incorporated in the first version of the service ontology in order to reason about the price and the selling of services (elementary and bundled). This chapter clarifies the way this question has been answered. From an extensive study of the services marketing literature, with the focus on pricing, it can be concluded that there are four most broadly used types of pricing models of elementary services. These are the flat-rate, usage-based, two-part tariff, and n-block tariff pricing models. Furthermore, from the studied literature and services from practice, it can be concluded that there are two ways to calculate the price of service bundles. These two ways are the pricing models that are applicable for service bundles. In the first way, the prices of the services that are part of the bundle are summed up, and a discount is applied to the sum. In the second way, a discount can be applied to the prices of the services that are part of the bundle, and then the price of the bundle is the sum of those prices. Several services that are identified in two case studies were used to verify if the abovementioned pricing models were representative for services in practice. The result is that the pricing models of both elementary services and service bundles were representative. This finding served as input for the development of the model proposal to incorporate pricing models in the service ontology. In this proposal, the way pricing models of elementary services and service bundles can be incorporated in the ontology has been extensively discussed. Examples were also provided. In addition to this proposal, the way pricing models of services can be incorporated in a software tool was examined. This was also described because the tool uses the domain knowledge that is modeled with the service ontology, and facilitates end-user modeling of services. A mapping between the service ontology and the e³-value ontology was then presented, which highlights how pricing models can be mapped between the two ontologies. The mapping between the two ontologies is needed to support a methodology to perform business analyses of e-service bundles for networked enterprises. However, some problems were identified that must be solved before pricing models can be successfully used in the e³-value ontology. Nonetheless, if these problems are solved, it will become possible to calculate the eventual cash flow when the service ontology interacts with the e³-value ontology in the aforementioned methodology. In the final part of this research, the findings of the literature study and the model proposal have been successfully validated. This indicates that the four most broadly used types of pricing models of elementary services and the two types of service bundles are indeed representative for services in practice. Additionally, the validation highlights that the model proposal to incorporate pricing models in the service ontology is applicable for services in practice. These are important conclusions of this research since they point out that it is possible to reason about the prices of services (elementary and bundled) in the service ontology. Additionally, with the model proposal, the service ontology can be used for the selling of services in practice. In conclusion, the problem outlined in the beginning of this research has been solved and pricing models are now incorporated in the service ontology in accordance with the model proposal. 100

101 List of Figures Figure 1: Service sub-ontology representing the service offering perspective 40 Figure 2: Service element 41 Figure 3: Two different service elements different inputs, but the same outcomes 44 Figure 4: Conditional output and service dependency 45 Figure 5: The e³-value ontology 47 Figure 6: An example of a value model 50 Figure 7: Service sub-ontology representing the service offering perspective, including the proposal to incorporate pricing models 52 Figure 8: Example of a pricing model of an elementary service elements that is assigned its monetary service port 55 Figure 9: Example of the first way to calculate the price of a service bundle 57 Figure 10: Example of the second way to calculate the price of a service bundle 60 Figure 11: Service sub-ontology including the extension of the model proposal 62 Figure 12: Screenshot of the simulate bundle functionality in the proposal of the service tool_ 66 Figure 13: Screenshot of step 1 in the Edit/assign pricing models of service elements that are part of a simulated bundle functionality in the proposal of the service tool 67 Figure 14: Screenshot of step 2 in the Edit/assign pricing models of service elements that are part of a simulated bundle functionality in the proposal of the service tool 68 Figure 15: Algorithm to calculate the prices of elementary service elements and service bundles in the service tool 71 Figure 16: Mapping of an elementary service element into the e³-value ontology 75 Figure 17: Mapping of a service bundle into the e³-value ontology 78 Figure 18: Mapping of an elementary actor into the service ontology 81 Figure 19: Mapping of a composite actor into the service ontology 82 Figure 20: First problem with bundling in the e³-value ontology 84 Figure 21: Second problem with bundling in the e³-value ontology 85 Figure 22: Service sub-ontology representing the proposal to incorporate pricing models 90 Figure 23: Elementary service element 'providing hot water' in the validation 91 Figure 24: Elementary service element ASP-service in the validation 93 Figure 25: Service bundle electricity supply, ASP-service, and broadband access 95 Figure 26: Service bundle dialup and hosting in the validation 97

102 List of Tables Table 1: Pricing models of elementary services in general 11 Table 2: Pricing models of various specific elementary services 12 Table 3: Pricing models of professional services 14 Table 4: Pricing models of water services 15 Table 5: Pricing models of electricity services 16 Table 6: Pricing models of information goods 17 Table 7: Textual representation of the four types of pricing models of elementary services 18 Table 8: Grouping of the pricing models of elementary services 18 Table 9: Overview of bundling strategies 21 Table 10: Pricing models of service bundles 22 Table 11: Examples of service bundles from practice 22 Table 12: Formulas of the four types of pricing models of elementary services 25 Table 13: Formulas of the two types of pricing models of service bundles 26 Table 14: Comparison of the textual representation of the pricing models described in the SINTEF case study with the four types of pricing models of elementary services 29 Table 15: Comparison of the mathematical representation of the pricing models described in the SINTEF case study with the four types of pricing model of services 32 Table 16: Comparison of the textual representation of the pricing models described in the SENA case study with the four types of pricing models of elementary services 36 Table 17: Comparison of the mathematical representation of the pricing models described in the SENA case study with the four types of pricing models of elementary services 37 Table 18: Revised formulas of the four types of pricing models of elementary services 38 Table 19: Mapping of an elementary service element into the e³-value ontology 75 Table 20: Mapping of a service bundle into the e³-value ontology

103 References Adams, W.J. and Yellen, J.L., Commodity Bundling and the Burden of Monopoly. Quarterly Journal of Economics, Vol. 90, pp , Akkermans, J.M., Baida, Z. and Gordijn, J., Value Webs: Ontology-Based Bundling of Real-World Services, IEEE Intelligent Systems, Vol. 19, No. 44, pages , July/August Altinkemer, K., Bundling e-banking services, Communications of the ACM, Vol. 44, No. 6, pp , Amyot, D., Mussbacher, G., On the extension of UML with use case maps concepts. In: Evans A, Kent S, Selic B (eds) UML 2000: The Unified Modeling Language: advancing the standard. Lecture notes in computer science, Vol. 1939, Springer, Berlin Heidelberg New York, pp 16 31, Baida, Z., Gordijn, J. and Akkermans, H., Service ontology, OBELIX project, Deliverable 6, Version 0.3, Baida, Z., Gordijn, J., Morch, A.Z., Sæle, H. and Akkermans, H., Ontology-Based Analysis of e-service Bundles for Networked Enterprises, in Proceedings of The 17th Bled ecommerce Conference, Bled, Slovenia, 2004a. Baida, Z., Value Ontology & Service Ontology, OBELIX project (internal document, not published), June 2004b. Baida, Z., Gordijn, J. and Akkermans, H., Implementation of the Service Ontology in Tools, OBELIX project, Deliverable 6.2, Version 0.4, 2004c. Baida, Z., Service Ontology, FRUX project (internal document, not published), Version 1.1, March Bailey, J.P. and McKnight, L.W., Internet Economics: What Happens when Constituencies Collide, Presented at INET'95, Honolulu, HI, June 27-30, pp , 1995 ( Bakos, Y. and Brynjolfsson, E., Bundling Information Goods: Pricing, Profits and Efficiency. Management Science, Vol. 45, Berends, W., Price & Profit: The Essential Guide to Products and Service Pricing, Berends and Associates, Oakville, Ontario, Bhattacharjee, S., R. D. Gopal, K. Lertwachara, and J. Marsden, No More Shadow Boxing with Online Music Piracy: Strategic Business Models to Enhance Revenues, Proceedings of the Thirty-Sixth Hawaii International Conference on System Sciences (HICSS-36), Hawaii, Jan

104 Bhattacharjee, S., Gopal, R.D., Lertchwara, K. and Marsden, J., Economics of Online Music Sharing, Proceedings of the Fifth International Conference on Electronic Commerce, Pittsburgh, PA, Bigné, E., Martínez, C. and Maria José Miquel, The Influence of Motivation, Experience and Satisfaction on the Quality of Service of Travel Agencies. In Kunst, P. and Lemmink, J. (editors) Managing Service Quality (Volume III), pages 53-70, London, UK, 1997, Paul Chapman Publishing Ltd. Borenstein, S., Frequently Asked Questions About Implementing Real-Time Electricity Pricing in California for Summer 2001, University of California Energy Institute, 2001 ( Borenstein, S., Jaske, M., Ronsenfeld, A., Dynamic Pricing, Advanced Metering, and Demand Response in Electricity Markets, University of California Energy Institute Paper CSEM Working paper 105, 2002 ( Borst, W.N., Akkermans, J.M., Top, J.L., Engineering ontologies, International Journal of Human Computer Studies, Vol. 46, pp , Brooks, C.H. and Durfee, E.H., Toward Automated Pricing and Bundling of Information Goods. AAAI Workshop on Knowledge-based Electronic Markets, pp. 8-13, August, Buhr, R. J. A., Use case maps as architectural entities for complex systems, IEEE Transactions on Software Engineering, Vol. 24, No. 12, pp , Carmon, Z., Shanthikumar, J.G. and Carmon, T.F., (1995), A Psychological Perspective on Service Segmentation Models: The Significance of Accounting for Consumers Perceptions of Waiting and Service, Management Science, 41 (11), p Cendoya et al., H., Business needs, Applications and Tools Requirements, OBELIX project, Deliverable 3, Version 0.2, Choi, S., Stahl, D.O., and Whinston, A.B., The Economics of Electronic Commerce, Macmillan Technical Publishing, Indianapolis, Indiana, Chuang, J. and Sirbu, M., Optimal bundling strategy for digital information goods: network delivery of articles and subscriptions, Information Economics and Policy, Vol. 11, No. 1, pp , Cox, J., Pricing Electronic Information: A Snapshot of New Serials Pricing Models, Serials Review 28, no. 3, pp , Daly, J., Pricing for Profitability: Activity Based Pricing for Competitive Advantage, John Wiley & Sons, Inc., New York, NY,

105 Dewees, D.N., Pricing Municipal Services: The Economics of User Fees, Canadian Tax Journal, Vol. 50, No 2, pp , Dewees, D.N., Price and Environment in Electricity Restructuring, Working papers University of Toronto, Department of Economics, ( Dolan, R.J., Quantity Discounts: Managerial Issues and Research Opportunities, Marketing Science, Vol. 6, No. 1, pp. 1-22, Dolan, R. J. and Simon, H., Power pricing. How Managing Price Transforms the Bottom Line, The Free Press, New York, NY, Essegaier, S., Gupta, S. and Zhang, Z.J., Pricing Access Services, Marketing Science Vol. 21, pp , Fishburn, P. C., Odlyzko, A. M. and Siders, R., Fixed fee versus unit pricing for information goods: competition, equilibria, and price wars, in Internet Publishing and Beyond: The Economics of Digital Information and Intellectual Property, D. Hurley, B. Kahin, and H. Varian, eds., MIT Press, Gordijn, J. and Akkermans, J.M., Value based requirements engineering: Exploring innovative e-commerce idea, Requirements Engineering Journal, Springer Verlag, Vol. 8, No. 2, pp , Gordijn, J., Sweet, P., Omelayenko, B. and Hazelaar, B., Digital Music Value Chain Application, OBELIX project, Deliverable 7.1, Version 1.12, Grönroos, C., Service Management and Marketing: A Customer Relationship Management Approach, 2 nd edition, John Wiley & Sons, Chichester, UK, Gruber, T., A Translation Approach to Portable Ontology Specification, Knowledge Acquisition Vol. 5, pp , Gruber, T., Olsen, G., and Runkel, J., The configuration design ontologies and the VT elevator domain theory. International Journal of Human-Computer Studies, 44: , Guiltinan, J.P., The Price Bundling Services: a Normative Framework, Journal of Marketing, Vol. 51, Gummesson, E., The Marketing of Professional Services - 25 Propositions, Marketing of Services, J. H. Donnelly and W. R. George, eds. Chicago: American Marketing Association, , Hanson, W. and Martin, R.K., Optimal bundle pricing. Management Science, Vol. 36, No.2, pp ,

106 Hitt, L.M. and Chen, P., Bundling with Customer Self-Selection: A Simple Approach to Bundling Low Marginal Cost Goods, 2004 (in review) ( Holbrook, M.B., Consumer value: a framework for analysis and research, Routledge, New York, Horstmann, C., Computing Concepts with Java Essentials, John Wiley & Sons, Kalfoglou, Y. and Schorlemmer, M., The Knowledge Engineering Review, Vol. 18, No. 1, pp. 1-31, March Kasper, H., van Helsdingen, P. and de Vries, W., Service Marketing Management: An International Perspective, John Wiley & Sons, West Susex, UK, Kotler, P., Marketing Management: Analysis, Planning, Implementation and Control, 6 th edition, Prentice Hall, Englewood Cliffs, NJ, Kotler, P. and Bloom, P.N., Marketing Professional Services, Prentice Hall, Englewood Cliffs, NJ, Kurtz, D.L. and Clow, K.E., Services Marketing, John Wiley & Sons, New York, NY, Löckenhoff, C. and Messer, T., Configuration, In Breuker, J. and De Velde, W. V., editors. The CommonKADS Library for Expertise Modeling Reusable Problem Solving Components, Chapter 9, Amsterdam, The Netherlands, IOS Press. Lovelock, C., Services Marketing, People, Technology, Strategy, 4 th edition, Prentice Hall, Englewood Cliffs, NJ, MacKie-Mason, J., and Riveros, J.F., Economics and electronic access to scholarly information, Conference on Economics of Digital Information and Intellectual Property, Conference at Harvard University, January, Mittal, S. and Frayman, F., Towards a Generic Model of Configuration Tasks, In Proceedings of the Eleventh International Joint Conference on Artificial Intelligence (IJCAI-89), pages , San Francisco, CA, Morgan Kaufmann. Morch, A.Z., Sæle, H., Lambine, A. and Baida, Z., Energy E-services Case Study Results for TrønderEnergi AS, OBELIX project, Deliverable 7.2, Version 2.1, Normann, R., Service Managemen t: Strategy and Leadership in Service Business, 3rd edition edn, John Wiley & Sons, Chichester, UK, Noy, N. F., and McGuinness, D., Ontology Development 101: A Guide to creating your first Ontology, Stanford KSL Technical Report KSL-01-05,

107 Odlyzko, A.M., Internet pricing and the history of communications, Computer Networks, vol. 36, pp , OECD report, Pricing of Water Services, Paris, Payne, A., The Essence of Services Marketing, Prentice Hall, Englewood Cliffs, NJ, Porter, M.E., Strategy and the Internet. Harvard Business Rev., pp , March Shapiro, C. and Varian, H.R. Information Rules: A Strategic guide to the Network Economy, Harvard Business School, Boston, Massachusetts, Simkovich, B., The Sophisticated Pricing of Services, The Journal of Professional Pricing, No. 4, pp. 7-12, Stremersch, S. and Tellis, G. J., Strategic bundling of products and prices: A new synthesis for marketing, Journal of Marketing, Vol. 66, No.1, pp , Sundararajan, A., Nonlinear pricing of information goods, Forthcoming, Management Science, Last revised: July 2004 ( Tapscott, D., Ticoll D., and Lowy A., Digital capital harnessing the power of business webs. Nicholas Brealy, London, Tung, W. Capella, L.M. and Tat, P.K., Service pricing: a multi-step synthetic approach, The Journal of Services Marketing, Vol. 11 No. 1, Wu, S., Chen, P. and Anandalingam, G., Optimal pricing scheme for information services, CEME working papers, 2002 ( Zeithaml, V. and Bitner, M.J., Services Marketing, Mcraw-Hill, New York, NY,