REASONING ABOUT CUSTOMER NEEDS IN MULTI-SUPPLIER

ICT SERVICE BUNDLES USING DECISION MODELS

Sybren de Kinderen, Jaap Gordijn and Hans Akkermans

The Network Institute, VU University Amsterdam, The Netherlands

Keywords:

Commercial services, Service bundling, Customer dialogue, Computational reasoning, Ontologies.

Abstract:

We propose a method, e

service , to reason about satisfying customer needs in the context of a wide choice of

multi-supplier ICT service bundles. Our method represents customer needs, their ensuing consequences, and

the services that realize those consequences in a service catalogue. This catalogue is then used by a reasoner,

which elicits customer needs, computes their consequences, and automatically matches these consequences

with services offered by suppliers. The e

service method has been implemented and tested in software to

demonstrate its feasibility.

1 INTRODUCTION

Commercial ICT services, such as VoIP, bandwidth,

email, web hosting, etc., are electronic, i.e. they can

be ordered by the customer online and provisioned

by the suppliers online. Usually, services never come

alone: customers typically need an ICT service bun-

dle to satisfy their needs. Moreover, these services

can be obtained from multiple competing suppliers.

So, the customer has to decide online about the best

selection — both in terms of the offered services and

of their supplier. In this paper, we show how this

customer-driven decision process can be facilitated

by automatic reasoning and match-making tools that

bridge the gap between general customer needs and

actual ICT services on offer. The key idea to enable

this is to employ a Propose/Critique/Modify (PCM)

problem-solving method (Motta, 1999) that iterates a

number of times through a knowledge-based dialogue

with the customer, so as to gradually and mutually ad-

just solutions (services) to problems (needs).

2 THE e

service ONTOLOGY

We use a running motivating example of a customer

who wants to communicate with family abroad, and

employs hosted email as a solution to do so. We then

show how this example can be represented by using

our e

service ontology for service need and service

bundle modeling. This ontology considers two dif-

Specified_by

Depends on

Core enhancing

1...N

0...N

0…N

Functional

consequence

Contained in

Scale

nominal

ordinal

0..1Has

0...N

Optional bundling

Want

Quality

consequence

Need

0...N

Has 1...N

Has 0...1

Core enhancing

0...N

Optional bundling

Consequence

Figure 1: Ontology used for reasoning about service

bundling from the customer perspective.

ferent perspectives: the customer perspective (section

2.1), and the supplier perspective (section 2.2).

2.1 Customer Perspective Ontology

The customer perspective in the e

service ontology is

presented in Figure 1; for an overview of its back-

ground ideas, see (de Kinderen and Gordijn, 2008).

Below, we summarize the key concepts and relation-

ships.

Need. A need represents a problem statement or

goal, independently from a solution direction (Arndt,

1978). EXAMPLE: A customer may have a need

‘communicate with family abroad’. Note that this

need does not yet include a notion of a solution.

Consequence. A consequence is anything that results

from consuming (a combination of) valuable service

properties (Gutman and Reynolds, 1988).

131

de Kinderen S., Gordijn J. and Akkermans H. (2009).

REASONING ABOUT CUSTOMER NEEDS IN MULTI-SUPPLIER ICT SERVICE BUNDLES USING DECISION MODELS.

In Proceedings of the 11th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

131-136

DOI: 10.5220/0001985001310136

 SciTePress

• Functional consequence. A functional consequence

represents the functional goal that can be achieved

through consumption of a service that has a certain

valuable property. EXAMPLE: A functional conse-

quence from the want ‘email’ is ‘send and receive

text’.

• Quality consequence. A quality consequence

expresses qualitive properties of functional conse-

quences in customer terminology. EXAMPLE: The

consequences‘small mailbox’and ‘large mailbox’ are

quality consequences of the functional consequence

‘send and receive text’.

Relations in this part of the ontology are:

• Speciﬁed by. A need is speciﬁed by zero or more

consequences. The consequences - as results of a ser-

vice - show how a need is satisﬁed. EXAMPLE: The

consequences ‘send and receive text’ and ‘hear and

speak voice’ are ways to satisfy the need ‘communi-

cate with family abroad’.

• Core enhancing/Optional bundling. Consequences

can be value-enhancing with respect to a core conse-

quence. To acquire the enhancing consequence, the

core consequence must also be acquired. An optional

bundling relation between two consequences A and B

indicates that consequence B can add value to con-

sequence A, but that consequence B can also be ac-

quired separately from A. EXAMPLE: As an exam-

ple of core/enhancing consequences, the consequence

‘reduce reception of unwanted text messages’ adds

value to the consequence ‘send and receive text’.

• A consequence depends on one or more other con-

sequences. This relation states that one consequence

cannot be acquired without another consequence. EX-

AMPLE: ‘Use at any site with connectivity’ and ‘lo-

cal’ (e.g. indicating a pre-conﬁgured PC) are two con-

sequences indicating the location from where ‘send

and receive text’ can be used.

• A consequence may consist of one or more other

consequences. Such consequence laddering (Gutman

and Reynolds, 1988) can be used to specify abstract

consequences into more concrete consequences until

a sufﬁciently detailed consequence is found for which

solutions can be offered. EXAMPLE: ‘send and re-

ceive text’can be speciﬁed by the consequences ‘send

text’ and ‘receive text’.

Want. A want is a speciﬁc, supplier-independent

solution that is commercially feasible to be provi-

sioned on its own. However, as a want indicates a

solution available in the market, at least one supplier

should be willing to provide the solution. Wants,

interpreted as supplier-independent solutions, can be

typically found in existing service taxonomies such as

the NAPCS. Relations in this part of the ontology are:

• A want has one or more consequences. These con-

Figure 2: Example for supply-side concepts: resources, ser-

vice ports and service interfaces.

sequences are used to state how the want, being a ser-

vice that can be provisioned commercially by a sin-

gle supplier, satisﬁes a need. EXAMPLE: the want

‘email’ has the consequence ‘send and receive text’,

which in turn is a way to satisfy the need ‘communi-

cate with family abroad’.

• A want is in a Core-Enhancing relationship with

zero or more other wants. The Core-Enhancing re-

lationship indicates that for a certain want A, pro-

vided that want A is acquired, there exist wants B that

could add value to A. This relationship exists also be-

tween consequences; the same relation is relevant on

the level of wants, as these wants actually package

sets of consequences available in the market. Analo-

gously, a want may be in an Optional Bundling re-

lationship with zero or more other wants. EXAM-

PLE: The value-enhancing want ‘Spam ﬁltering’ is

in a Core-Enhancing relationship with the basic want

‘email’, since there is no business logic in acquiring

a spam ﬁlter without an email service. The Core En-

hancing relationship between consequences indicates

why a spam ﬁlter want adds value to an email want.

Scale. In e

service we use scales to cluster related

quality consequences. We use two well-known types

of scales:

• Nominal. A nominal scale indicates that a relation-

ship exists between quality consequences, but intro-

duces no ordering or ranking on these consequences.

EXAMPLE: ‘use at any site with connectivity’ and

‘local’ are nominal categories that indicate email ac-

cess options. The preference for either one depends

on the customer.

• Ordinal. An ordinal scale introduces an ordering

on consequences such that it is possible to state that

consequence X is better than Y (but not how much it

is better). EXAMPLE: Deﬁning ≤ 0.2 GB as a ‘small

mailbox’ and > 2 GB as a ‘large mailbox’ yields an

ordinal scale for the size of an email box.

2.2 Supplier Perspective Ontology

The e

service supplier ontology is depicted in Figure

2 using an example ICT service. For a detailed dis-

cussion of this ontology, see (Baida, 2006).

Consequence. A consequence is anything that results

ICEIS 2009 - International Conference on Enterprise Information Systems

132

from consuming (a combination of) valuable service

properties (Gutman and Reynolds, 1988). Similar to

the customer perspective ontology, there exist sev-

eral supply-side types of consequences and of rela-

tions between consequences. Since consequences are

used both in the customer and supplier perspective of

service , they form the glue between both ontologi-

cal perspectives. Hence, the concept of consequences

is the ontological as well as reasoning keyin matching

customer needs to supply-side services on offer.

Service Property. A service property is a supplier-

speciﬁc attribute. Relations in this part of the ontol-

ogy are:

• Realized by: A consequence is realized by one

or more service properties. EXAMPLE: The conse-

quence ‘send and receive text’ is realized by the ser-

vice properties ‘protocol=POP3’ and ‘upspeed = 256

kbps’ and ‘downspeed=512 kbps’, all provided by the

supplier (say) KPN.

• A service property is always part of a supplier-

speciﬁc resource. The distinction that we make be-

tween a service property and a resource is that a re-

source can be provisioned on its own commercially,

while a property cannot. A property is therefore al-

ways part of a resource. EXAMPLE: consider that the

service properties ‘upspeed = 256 kbps’ and ‘down-

speed= 512 kbps’ from KPN are part of the resource

‘KPN IP access’. Here, up- and downspeed from

KPN can only be delivered in combination with IP

access from KPN.

• A resource is always attached to one or more ser-

vice ports. In turn, each service port is always part of

exactly one service interface. EXAMPLE: consider

the KPN IP access service in Figure 2. Here, one sees

that the resource IP access is attached to a service port

(the arrowhead), which in turn is part of the service

interface of the IP access bundle. The service inter-

face indicates the actual bundling of resources from

a (multi-)supplier perspective: all resources should

be exchanged between the customer and supplier, or

none at all. So, by considering the KPN-IP-access in-

terface of our example, you know that you will also

have to give up customer lock-in and a certain fee

since these additional resources are attached to the

other ports in this interface.

The important point here is that consequences also

exist at the supply side. We furthermore assume that

consequences ensuing from a supply-side service cat-

alogue are expressed in a marketing vocabulary that

represents the customer perspective. This is crucial

for the match-making process, discussed below.

3 FROM CUSTOMER NEEDS TO

ICT SERVICE BUNDLES

How to derive a service bundle, given a customer

need? The high-level reasoning process is shown in

Figure 3. We have implemented this reasoning pro-

cess in a software tool for demonstration and valida-

tion purposes.

SupplierConsumer

Choose need

Choose consequences Find service bundles

Trade-off positive/negative consequences

[not ok,

adjust reqs]

Select bundle

[ok]

Desired consequences

Consequences per bundle

[no bundle found ]

[value-enhancing

wants]

[no more value-

enhancing wants]

Figure 3: The generic reasoning structure of the e

service

method.

3.1 Needs & Functional Consequences

Starting from a customer need, we derive an initial

set of consequences specifying this need. In the cus-

tomer perspective ontology (section 2.1), we do this

by expanding the relation ‘speciﬁed by’ from a sin-

gle need to one or more consequences specifying this

need. First we focus on functional consequences only,

since a functional consequence shows (partly) what

goals can be achieved by a service and so shows how a

service can satisfy a need. The reasoning process ﬁrst

asks the customer to choose a particular consequence

(via prioritization) and then checks whether the se-

lected consequence ‘consists of’ other, more detailed,

consequences. If so, the customer is again asked to

make a choice after which, for all chosen and implied

consequences, the reasoning process again reviews

whether considered consequences ‘consist of’ other

consequences. This continues until no more ‘consist

of’ relationships are found. This process is also called

‘laddering’and is a well-knownpractice from market-

ing theory (Gutman and Reynolds, 1988).

Next, our e

service tool derivesone or more wants

that this consequence is a part of. Here, the assump-

tion is that the experts that created the service cata-

REASONING ABOUT CUSTOMER NEEDS IN MULTI-SUPPLIER ICT SERVICE BUNDLES USING DECISION

MODELS

133

logue used for the reasoning process have deﬁned so-

lutions upfront for detailed (i.e. leaf) consequences.

Then, using this want as a starting point, the reason-

ing mechanism derives additional consequences that

are also part of the want. Thus, this ﬁrst step is a kind

of bootstrapping process to ﬁnd a highly ranked con-

sequence, and it continues by evaluating wants (that

includes this consequences) to ensure that needs elic-

itation is grounded in services that are in fact available

on the market (i.e., wants).

Case Example. We start with the need: ‘communi-

cate with someone over a distance’. By following the

relation ‘speciﬁed by’, we derive the functional con-

sequences ‘send and receive text’ and ‘hear and speak

voice’. Let’s assume that the customer chooses ‘send

and receive text’. Subsequently, we look whether

this consequence is speciﬁed further by reviewing

whether a ‘consists of’ relationship exists. When we

look at the service catalogue used for this speciﬁc case

(Figure 4) we see that ‘send and receive text’ is not

speciﬁed further. Next, we derive the want that con-

tains ‘send and receive text’. For this simple case, the

only want containing ‘send and receive text’ is ‘email

access’. Then, our tool derives all possible functional

consequences from the want ‘email access’; in this

case we derive, next to ‘send and receive text’, also

the consequence ‘use for newsletter’. Thus, the con-

sumer is presented with the group of consequences

‘send and receive text’, which the tool indicates as a

solution result satisfying the need ‘communicate over

a distance’, but also the additional possibility ‘use for

newsletter’.

3.2 Choose Additional Consequences

When a particular functional consequence is selected,

we derive its quality consequences by following the

relation depends on in our customer ontology. These

quality consequences are then grouped by scale by

(1) deriving, for each quality consequence, its scale

by following the relation ‘has’ between quality con-

sequence and scale and (2) grouping together quality

consequences that are deﬁned on the same scale.

Now that the conseqeunces are grouped per scale,

we let the customer decide, per scale, on consequence

prioritization. Depending on the type of scale (recall

that different types of scales exist, e.g., nominal or

ordinal) the customer is presented with two different

prioritization tasks: (1) When consequences are de-

ﬁned on a nominal scale, the customer is asked to as-

sign to each of the consequences an importance value

ranging from 1 (unimportant) to 10 (must-have, i.e.

the offered service bundle should always include this

consequence); (2) When consequences are deﬁned on

Customized domain

Communicate

over a

distance

E-mail access VoIP

Send and

receive text

Hear and

speak voice

Access type

(nominal)

* Local

* Use at any site

with IP-access

Mailbox size

(ordinal)

* Large mailbox

* Small mailbox

O/B

Need Want

Consequence

Scale

legend

Use for

newsletter

Create

personalized e-

mail address

….

Figure 4: Customer catalogue for the email example.

an ordinal scale, the customer is asked to assign a

preference ordering to the scale only and not to the

consequences in the scale. For the scoring of conse-

quences, we use the ranking from best to worse which

is inherent to an ordinal scale. How we convert this

best-to-worse ranking of consequences into a score, is

discussed in the next step (compose and rank service

bundles, see below). Finally, by default, the selected

functional consequence receives an importance rank-

ing of ‘10’ (must have). We can now use the customer

preferences expressed in terms of their consequences

to compose the appropriate service bundles.

Case Example. By following the relation depends

on, we infer that there are four quality consequences

that depend on the functional consequence ‘send and

receive text’: ‘small mailbox’, ‘large mailbox’, ‘lo-

cal’ and ‘use at any site with connectivity’ (cf. Fig-

ure 4). These quality consequences are grouped per

scale, resulting in two scales of two quality conse-

quences each: (1) the ordinal scale mailbox size with

the quality consequences ‘small mailbox’ and ‘large

mailbox’ and (2) the nominal scale ‘access type’ with

the quality consequences ‘local’ and ‘use at any site

with connectivity’. Now, the customer is asked to pri-

oritize the consequences from these scales. For the

nominal scale ‘access type’, our tool presents the con-

sequences ‘local’ and ‘use at any site with connectiv-

ity’. Say, the customer gives the score ‘1’ to ‘local’

and the score ‘8’ to ‘use at any site with connectivity’,

since s/he wants to be able to communicate from any-

where. Next, the customer is asked to assign an im-

portance ranking to the ordinal scale ‘mailbox size’.

Suppose s/he attaches an importance ranking of ‘3’ to

this scale, since the size of a mailbox is of little impor-

tance for satisfying his/her need: ‘communicate with

family abroad’. Finally, by default, the importance

ranking ‘10’ is attached to the consequence ‘send and

receive text’ since this is the selected functional con-

sequence.

ICEIS 2009 - International Conference on Enterprise Information Systems

134

3.3 Composing Service Bundles

After this customer dialogue, we ﬁrst match the set

of consequences desired by the customer to conse-

quences deﬁned from a supplier’s perspective. We can

do this because (cf. section 2.2) the concept and the-

ory of consequences provides the bridging connection

between the customer and supply sides for the match-

making process. The computational result of this con-

sequence matching is a subset of supply-side conse-

quences that, together with the prioritization scores

provided by the customer, can be used to reason about

(1) ﬁnding (composing) service bundles and (2) rank-

ing service bundles according to prioritization scores.

We ﬁrst search for those service bundles that can

satisfy all ‘must-have’ consequences. To ﬁnd these

bundles, we search for: (1) the supplier-speciﬁc ser-

vice properties jointly satisfying the consequence; (2)

supplier-speciﬁc resources that contain these prop-

erties; and ﬁnally (3) bundles that contain these re-

sources. Depending on the scale type, we evaluate on

the basis of the consequences in hand whether a bun-

dle can satisfy all consequences from nominal scales

that are marked as must-haves, and contains at least

one consequence from each ordinal scale marked as a

must-have.

Case Example. From the previous step, we have

the functional consequence ‘send and receive text’

with importance ‘10’ and four quality consequences:

‘small mailbox’ and ‘large mailbox’ from the scale

‘mailbox size’ (the latter with an importance rank-

ing of 3) and ‘local’ (importance 1) and ‘use at any

site with connectivity’ (importance 8) from the scale

‘access type’. These are matched to all supply- side

consequences, see Figure 5. Next, we ﬁnd the bun-

dles that satisfy the must-have consequence ‘send

and receive text’. For this, we ﬁrst ﬁnd all possible

sets of supplier-speciﬁc service properties satisfying

this consequence. An example in this case could be

‘POP3’ or ‘upspeed= 128 kbps’. These service prop-

erties belong to the resources ‘email access (KPN)’

and ‘IP access KPN’ which are attached to two ser-

vice ports of the bundle ‘KPN email bundle’ (Fig-

ure 5). ‘KPN email bundle’ is therefore satisfying all

must-have consequences and hence can be considered

further, as is the case with all other bundles shown in

this ﬁgure since they can all provide the consequence

‘send and receive text’.

3.4 Ranking Service Bundles

The next step is to rank the found relevant bundles.

For this, we convert the best-to-worse ordinal rank-

ing of consequences to a numerical ranking, by using

the Rank-Order Centroid method (ROC, (Barron and

Barrett, 1996)). Additionally, we need to provide a

score to indicate whether a consequence deﬁned on

a nominal scale is present in a service bundle. This

score we provide in a binary way: if a consequence is

present in a bundle it scores 1, else 0.

Now that we have numerical values to express

consequence scores and as well as importance scores

from the customer, we calculate a ranking score for

each service bundle by using the multi-attribute scor-

ing formula SB

∑

j= 1

, where SB

is the rank-

ing score for service bundle i, w

is the importance

ranking of consequence j as provided by the cus-

tomer, and v

is the numerical value for the conse-

quence j of service bundle i. After having calcu-

lated to what extent a service bundle ﬁts with cus-

tomer preferences, we ﬁnd for each bundle additional

consequences that a customer also must acquire. For

each service bundle we then obtain service ports ad-

ditional to those already found by reviewing their ser-

vice interface. Taking these additional service ports

as a starting point we then derive consequences by

using the process of ﬁnding service ports based upon

consequences described before, only then in reverse.

Case Example. To rank the bundles, we calculate

a score for the consequences deﬁned on the ordinal

‘mailbox size’ scale. Using ROC, we derive the score

0.75 for the consequence ‘large mailbox’ and 0.25 for

the consequence ‘small mailbox’. Now, we calculate

a ranking score for each of the possible bundles by us-

ing the above multi-attribute formula, and then com-

pute its full set of consequences. For example, in the

case of the KPN g-mail bundle, we ﬁnd two additional

service ports: one containing the resource ‘fee’ with

a service property of ‘EUR 20’, the other contain-

ing the resource ‘lock-in’ with a service property of

‘12 months’. From this, we derive the consequences

‘IP-access fee’ and ‘lock-in’. With the consequences

already found, we ﬁnally arrive at the following full

set of consequences for the KPN g-mail bundle: send

and receive text, large mailbox, access mail at any site

with connectivity, IP access fee, lock-in.

3.5 Trade-off Decision Making

Next, we present the found bundles in a ranking to the

customer, together with a speciﬁcation of the conse-

quences received from a bundle and the consequences

s/he has to give up to acquire a bundle. Furthermore,

the tool shows a speciﬁcation in terms of a pricing

model (cf. (de Miranda, 2006)). The customer has

the option to either select a bundle from the ranking

or, in case s/he ﬁnds the costs incurred for the bundles

too high, to go back to the step ‘choose consequences’

REASONING ABOUT CUSTOMER NEEDS IN MULTI-SUPPLIER ICT SERVICE BUNDLES USING DECISION

MODELS

135

Figure 5: Supplier catalogue for email example.

and change his/her requirements.

For the selected bundle, we consider possible

value-enhancing wants for that bundle. As in the step

‘choose consequence’, the customer makes a choice

based on a combination of a want (the solution) and

a consequence (why the solution is valuable). Then,

we iterate again through the steps described above to

derive a set of possible service bundles, only now for

the value-enhancing wants.

4 CONCLUSIONS

Our general claim and contribution is that it is pos-

sible to have automated support that helps bridging

the gap between the customer and supplier perspec-

tives on complex service bundles. We have prac-

tically demonstrated this for a case of ICT service

bundles. Although these two perspectives are funda-

mentally different, and are therefore associated with

differing ontologies and vocabularies, match-making

is possible through the introduced marketing the-

ory concept of consequences (Gutman and Reynolds,

1988). On this basis, a Propose/Critique/Modify

problem-solving method (Motta, 1999) intertwined

with a customer-driven dialogue system employing

existing decision theory, is helpful in selecting and

composing ICT service bundles on the supply side

that match expressed general needs on the customer

side. More speciﬁcally, when ranking service bun-

dles, we use a combination of the compensatory de-

cision technique of (Barron and Barrett, 1996) and

the non-compensatory decision technique MoSCoW

from DSDM (Stapleton, 1997). We have imple-

mented the presented reasoning processes in our

service software tool. The services and needs are

ontologically described as an RDF dataset that com-

plies with the e

service RDF schema. The reason-

ing process has been implemented as a Java program

using an RDF service catalogue that is the basis of

the structured knowledge-driven interactive dialogue

with the customer.

REFERENCES

Arndt, J. (1978). How broad should the marketing concept

be? Journal of Marketing, 42(1):101–103.

Baida, Z. (2006). Software-aided service bundling. PhD

thesis. VU University Amsterdam.

Barron, F. H. and Barrett, B. E. (1996). Decision quality

using ranked attribute weights. Management Science,

42(11):1515–1523.

de Kinderen, S. and Gordijn, J. (2008). e

service - an

ontological approach for deriving multi-supplier IT-

service bundles from consumer needs. In Proceedings

41st Hawaii International Conference on System Sci-

ences (HICSS-41). IEEE Computer Society.

de Miranda, B. (2006). An ontological approach for the use

of pricing models to sell services. Technical report.

VU University Amsterdam.

Elrod, T., Johnson, R., and White, J. (2004). A new inte-

grated model of noncompensatory and compensatory

decision strategies. Organizational Behavior and Hu-

man Decision Processes, 95(1):1–19.

Gutman, J. and Reynolds, T. (1988). Laddering theory -

analysis and interpretation. Journal of Advertising Re-

search, 28(1):11.

Motta, E. (1999). Reusable Components for Knowledge

Modelling: Case Studies in Parametric Design Prob-

lem Solving. IOS Press. Amsterdam.

Stapleton, J. (1997). Dynamic Systems Development

Method. Addison Wesley Longman. Reading, MA.

ICEIS 2009 - International Conference on Enterprise Information Systems

136