Metodologie di progettazione di e-service come sistemi di supporto

alle transazioni

Chiara Francalanci

1 giugno 2004

2

Sommario

Stato dell’arte e problemi aperti Una metodologia di progettazione di e-service:

dall’analisi dei requisiti organizzativi all’implementazione

Una metodologia di supporto alla progettazione di sistemi di negoziazione cooperativa

3

Una metodologia di progettazione di e-service: obiettivi

Definire un insieme di metodi e modelli concettuali in grado di supportare la progettazione di e-service per la gestione semi-automatica delle transazioni in ambienti cooperativi.

Progettare ed implementare strumenti informatici in grado di coadiuvare la modellazione delle transazioni.

4

Coordinamento nelle imprese virtuali

L’impresa virtuale (Virtual Enterprise, VE):

Si configura come l’esatto contrario rispetto all’impresa integrata verticalmente.

È un insieme di unità operative autonome che agiscono in modo integrato ed organico.

È caratterizzata da una catena del valore frammentata e flessibile che aumenta la necessità di coordinamento e di ri-configurazione in tempi brevi e con costi limitati.

Il potere del cliente La varietà Il cambiamento La velocità

Impresa tradizionale

Impresa virtuale

5

E-service

Gli e-service sono: Elementi computazionali autonomi indipendenti dalla piattaforma informatica universalmente individuabili ed accessibili.

Descritti, pubblicati, programmati ed organizzati con l’obiettivo di sviluppare applicazioni interoperazionali distribuite.

Strumenti che possono essere implementati su software e sistemi già esistenti ed operativi senza dover effettuare modifiche sulle rispettive

architetture. In grado di gestire semiautomaticamente lo scambio di informazioni e il pieno coordinamento di organizzazioni indipendenti rispetto ad obiettivi comuni grazie ad un’architettura composta da un Service Provider, un Service Broker e un Service Requester.

6

Passi metodologici

Fase - 1 Specifica orientata agli obiettivi dei requisiti cooperativi con l’ i *

Passo 2.1 Operazionalizzazione degli obiettivi, delle attività e delle risorse

Fase - 2 Specifica concettuale dei requisiti cooperativi con l’UML

Passo 2.2 Specifica delle eccezioni e delle azioni compensative

Passo 2.3 Specifica dei sequence diagram

Fase - 3 Implementazione

Passo 1.2 Raffinamento degli obiettivi di coordinamento e controllo, delle attività e delle risorse

Passo 1.1 Specifica degli attori e delle dipendenze

Passo 3.1 Mappatura della transazione su di un insieme di e - service

Passo 3.2 Implementazione della descrizione degli e - service (WSDL)

Passo 3.3 Implementazione dello schema di invocazione (BPEL4WS)

Specifica statica attraverso la quale si individueranno e si raffineranno attori,

dipendenze, attività, risorse e obiettivi della transazione.

Specifica dinamica attraverso la quale si operazionalizzeranno gli elementi individuati

nella fase statica e si completerà la descrizione temporale e causale della transazione.

Traduzione delle specifiche della transazione attraverso i linguaggi degli e-service.

7

Passo 1 - Specifica di attori e dipendenze: notazione (1)

Concetti fondamentali: Attore: organizzazioni cooperanti all’interno del distretto (istanza o ruolo)

Elementi intenzionali:

obiettivi strategici (softgoal), obiettivi (goal)

attività (task): trasformazione di un input in un output

risorse (resource): risorsa informativa (controllo e coordinamento)

Se gli elementi decisionali sono al di fuori degli attori, si usa il concetto di delega/dipendenza

Relazioni intenzionali:

decomposizione (task, goal, risorse)

means-end (mette in relazione un goal con il task svolto per soddisfarlo se entrambi si trovano all’interno dello stesso attore)

8

Passo 1 - Specifica di attori e dipendenze: notazione (2)

DipendenzeDecomposizione

Means-end

(1) Attori e dipendenze (2) Scomposizione

9

Passo 1 - Specifica di attori e dipendenze: struttura di una transazione

Diagramma di “livello 0” L’insieme delle dipendenze deve contenere almeno una “goal dependency” dal compratore al venditore. Il venditore fornisce inoltre il task che permette di soddisfare il goal.

La specifica deve inoltre modellare o un obiettivo del venditore che può essere esplicitamente delegato al compratore o meno.

Alternativa 1 Alternativa 2

10

Passo 2 - Raffinamento

Raffinamento orientato al controllo: processo iterativo attraverso il quale i softgoal sono scomposti in sotto-obiettivi per mezzo di alberi AND-OR. Lo scopo è la definizione di goal operazionalizzabili riconducibili agli obiettivi di controllo e la loro successiva attribuzione ai super-task o ai task direttamente responsabili del loro soddisfacimento.

Raffinamento orientato al coordinamento: scomposizione delle risorse in sotto-risorse specializzate. Lo scopo è quello di fornire ad un task solo le informazioni di cui necessita nel momento in cui ne necessita.

Esempio di raffinamento orientato al controllo

11

Esempio 1: transazione di mercato

12

Esempio 2: comakership

13

Esempio 3: Distretto di Matera

optimize the use of materials <<goal >>

control panel’s cleanness <<goal >>

provide high quality outputs <<goal >>

reduce costs but use good materials

<<goal >>

use good materials <<goal >>

minimize production costs <<goal >>

control wood wetness <<goa l >>

control backbone strength

<<goal >>

And

And

And

minimize the cost of rough materials <<goal >>

And

optimize procurement activities

<<goal >>

apply a just-in-time policy

<<goal >>

control the quantity of wood used to produce

each panel <<goal >>

reuse a sufficient amount of scraps <<goal >>

And

control panel’s smoothness <<goal >>

Or

do not overcome cost limits <<goal >>

Control backbones’ costs <<goal >>

14

Passo 2 – Specifica concettuale: operazionalizzazione

Risorsa di controllo: è associata ad un set di tuple Mi=meij, meaij con meij j-esima metrica e meaij j-esima misura di una risorsa ri.

Risorsa di coordinamento: è associata ad un set di tuple obbligatorie Ai=aij, tij, con aij j- esimo attributo obbligatorio e tij j-esimo tipo della risorsa ri, e ad un set di attributi opzionali OAi=oaij, tij, con oaij j-esimo attributo opzionale e tij j-esimo tipo di una risorsa ri.

Goal: è associato ad un set di tuple PREi=tij, preij, con tij j-esimo task che contribuisce al conseguimento del goal gi e preij j-esima pre-condizione che deve essere verificata prima di eseguire tij, e ad un set di tuple POSTi=tij, postij, con tij j-esimo task che contribuisce al raggiungimento del goal gi e postij j-esima post-condizione che deve essere verificata dopo l’esecuzione di tij.

15

Esempio di operazionalizzazioneControl resource Perspective Control goal

Resource/ attribute name

Metric Measure

control backbone strength

weight maximum weight kg/m2

control panel smoothness

frequency maximum frequency s-1

Goals delegated to the seller

reuse a sufficient amount of scraps

reused scraps % of reused scraps pure number

Goals owned by the buyer

control panel size size attribute of order resource

area m2

Resource name Mandatory attribute Type

wood type string

wood drying type string

size real

number of ordered backbones integer

Optional attribute Type

order

delivery date date

Control goal Pre-cond. Post-cond. Task

control panel smoothness

- frequency 0,85 component production

control backbone strength

- maximum weight 10 kg/m2

backbone quality control

control backbones costs cost ? 100 € order

scheduling

control panel size size 1,5 m2

- order scheduling

16

Passo 2 – Specifica concettuale: violazioni e compensazioni (1)

Struttura delle ECA Evento: Inizio e fine di un task

Condizione: espresse come combinazione logica (and, or, not) di

goal operazionalizzati (lead-time, tolleranze, prezzo, costi, requisiti di qualità…),

ricezione invio di informazioni (resource dependencies),

successo o insuccesso di eventuali azioni di compensazione.

Azioni: suddivise in classi e espresse come combinazione logica. Presente anche l’operatore Sequence().

ritardo (Wait-for<time>, Wait-for<time, actor/role, resource>, Delay<time, actor, task>)

informativa (Urge<time, actor/role, resource>, Notify<time, actor/role, resource>)

ri-negoziazione (Relax<time, actor, goal>, Tighten<time, actor, goal>, Delete<time, actor, goal>),

ri-esecuzione (Re-execute<time, actor, task>, Re-execute-from<time, actor, task>, Skip<time, actor, task>),

sostituzione (Replace<time, task>).

17

Passo 2 – Specifica concettuale: formalizzazione della dinamica

Automa a stati finiti (la transazione termina sempre con un commit o con un abort),

gerarchico,

compensazioni time-consuming,

tempo di residenza negli stati limitato,

stati marcati con gli attori coinvolti.

NotazioneOR-state

State1

e [c]/a

State2

State1

Administrativetask

Actor

State2

State1

Actor

State1

H

State2

State3

Actor

Actor1

Administrativetask

AND-state State marked withhistory

Simple hierarchicalstate

Actor2

Actor

State transitionOR-state

State1

e [c]/a

State2

State1

Administrativetask

Actor

State2

State1

Actor

State1

H

State1

H

State2

State3

Actor

Actor1

Administrativetask

AND-state State marked withhistory

Simple hierarchicalstate

Actor2

Actor

State transition

18

Esempio: distretto di matera

ExecutionExecution

NegotiationNegotiation

Post-SettlementPost-Settlement

H

End(Backbones’ quality control) [minimum weight < 10 kg/m2] | (Notify<-, seller, maximum weight> Relax <[2,5],seller, cost>)

OrderScheduling

<[1,3]days>

ComponentProduction

<[8,10]days>

Payment<60days>

Backbones’quality control

<1day>

Beg(Order Scheduling)[(Order.size>1,5 m2 (Done(Urge<[0,3], buyer, order.size>))]|Urge<[0,3], buyer, order.size>;

End(Order Scheduling)[(cost>100 euro) (Done(Notify< , buyer, cost>))]|Notify<, buyer, cost>;

End (Component production)[(frequency< .85) ( Done(Notify<, buyer, cost>))]| Notify<frequency>);

End(Negotiation) [Received ([1,3], seller, order) ]|

End(Negotiation) [Fulfilled(Relax <[2,5], seller, cost>)]|(Re-execute task from <component production> Reset_history<post-settlement>)End(Negotiation)[Fulfilled(Relax <[2,5], seller, cost>)]|

BBT

COMMIT

End(quality control) [(minimum weight < 10 kg/m2 ) Done(Re-execute task from <[1,3], Seller, component production>)]|

H

End(Order Scheduling)[(cost>100 euro) (Order.size1,5 m2)]|End(Order Scheduling)[Done(Notify< , buyer, cost>) (Order.size1,5 m2)]|

End(Order Scheduling) [(frequency<.85)]|End(Order Scheduling) [Done(Notify< , buyer, cost>)]|

ABORT

H

End(Negotiation)[Received ([1,3], seller, order) ]|

supplier

supplier, producer

supplier

producer

ExecutionExecution

NegotiationNegotiation

Post-SettlementPost-Settlement

H

End(Backbones’ quality control) [minimum weight < 10 kg/m2] | (Notify<-, seller, maximum weight> Relax <[2,5],seller, cost>)

OrderScheduling

<[1,3]days>

ComponentProduction

<[8,10]days>

Payment<60days>

Backbones’quality control

<1day>

Beg(Order Scheduling)[(Order.size>1,5 m2 (Done(Urge<[0,3], buyer, order.size>))]|Urge<[0,3], buyer, order.size>;

End(Order Scheduling)[(cost>100 euro) (Done(Notify< , buyer, cost>))]|Notify<, buyer, cost>;

End (Component production)[(frequency< .85) ( Done(Notify<, buyer, cost>))]| Notify<frequency>);

End(Negotiation) [Received ([1,3], seller, order) ]|

End(Negotiation) [Fulfilled(Relax <[2,5], seller, cost>)]|(Re-execute task from <component production> Reset_history<post-settlement>)End(Negotiation)[Fulfilled(Relax <[2,5], seller, cost>)]|

BBT

COMMIT

End(quality control) [(minimum weight < 10 kg/m2 ) Done(Re-execute task from <[1,3], Seller, component production>)]|

H

End(Order Scheduling)[(cost>100 euro) (Order.size1,5 m2)]|End(Order Scheduling)[Done(Notify< , buyer, cost>) (Order.size1,5 m2)]|

End(Order Scheduling) [(frequency<.85)]|End(Order Scheduling) [Done(Notify< , buyer, cost>)]|

ABORT

H

End(Negotiation)[Received ([1,3], seller, order) ]|

supplier

supplier, producer

supplier

producer

19

Verifica

Proprietà strutturali (es. deadlock, conseguenze fallimenti delle compensazioni, …),

Performance e qualità del servizio (superamento del lead-time massimo in funzione del comportamento standard + quello eccezionale, …),

Livello di soddisfazione come conseguenza delle azioni di compensazione

La verifica è possibile riducendo il modello in un automa descrivibile attraverso il linguaggio fornito da un model checker.

20

Passo 3 – Implementazione: mappatura delle transazioni in e-service

Strategie Monolitica: negoziazione su singolo attributo, range predefinito.

Negoziazione disaccoppiata: negoziazione multi-attributo oppure non definita a priori.

Post-settlement disaccoppiato: politiche di controllo standardizzate

Negoziazione e post-settlement disaccoppiati

Esecuzione distribuita: sub-task erogabili anche separatamente dal tutto

Controllo distribuito: responsabilità del controllo delegata a terze parti che non siano gli attori “che siglano l’accodo di cooperazione” (signatory parties).

Esecuzione e controllo distribuito

21

Passo 3 – Implementazione: implementazione degli e-service

WSDL Resource dependencies mappate in messaggi WSDL (input-output)

Risorse di controllo

controllo locale = fault messages

controllo delegato = messaggi WSDL (input – output)

Compensazioni realizzate come servizio a parte

Compensazioni gestite nel BPEL intermediario attraverso fault handlers

BPEL4WS code <faultHandlers> <catch faultName = “ECA #1”> … <invoke partnerLink = “” operation = “re-negotiate +”_OP”” inputVariable = “resource r1” </invoke> </catch> </faultHandlers>

ECA rule name: ECA #1 class: control exception event: begin of t1 condition: pre11 and not pre21 action: re-negotiate < r1>

WSDL code … <portType name = “…” operation = “t1.name + ”_OP”” input message = “…” output message = “…” <fault name = “ECA #1” message=”Error” </fault> </portType>

22

Esempio: scheletro WSDL

<definitions name=”BackboneProductionService”targetNamespace=”http://www.elet.polimi.it/Matera/BackboneProductionService”xlmns:tns=”http://www.elet.polimi.it/Matera/BackboneProductionService”xlmns=”http://schemas.xmlsoap.org/wsdl/”xlmns:soap=”http://schemas.xmlsoap.org/wsdl/soap”xlmns:xsd=”http://www.w3.org/1999/XMLschema”

Example of message <message name= “OrderInformation”> <part name = “WoodType” type=“xsd:string”/> <part name = “WoodDryingType” type=“xsd:string”/> <part name = “Size” type=“xsd:real”/> <part name = “NumberOfOrderedBackbones” type=“xsd:integer”/> <part name = “DeliveryDate” type=“xsd:string” /> </message> … Example of operation and port-type 

<portType name=“BackboneProduction_PT” <operation name=“OrderScheduling_OP”> <input message=“tns:OrderInformation” /> Example of fault message*  <faultName=“frequency” message=“frequency_error” />  </operation>…</porType>…</definitions> 

messaggio

Port-type e operation

Fault message

23

Esempio: scheletro BPEL (1)

Pull interaction Push interaction

resource r1

Task t1 ack resource r1

request

Customer Provider Customer Provider

<receive partnerLink =”i* actor ” portType = “ ” operation = “ ” variable = “request” </receive> … <reply partnerLink =”i* actor ” portType = “ ” operation = “ ” variable = “resource r1” </reply>

<invoke portType = “s.name + “_PT” ” operation = “t.name + “_OP” ” inputVariable = “resource r1” outputVariable = “ack” </invoke>

24

Esempio: scheletro BPEL (2)

Invocation schema Exception handling <definitions … xmlns:bprod=”http://elet.polimi.it/ service/BackboneTransaction” location=”http://localhost:8080/bpws-samples/ BackboneProduction/backboneproduction.wsdl … </definitions> <process name=BackboneProdTransaction … location=”http://localhost:8080/bpws-samples/ BackboneProduction/backboneproduction.wsdl … //the sofas producer sends an order to its backbone supplier// <invoke portType=“bprod:BackboneProduction_PT” operation name=“bprod:OrderScheduling_OP”> inputVariable=“bprod:OrderInformation”/> </invoke> … //hang on for a request of bank data// <receive partnerLink=“SofasBackboneProducer” portType=“” operation=“” variable=“bprod:Request” </receive> … //provide bank data resource as required// <reply partnerLink=“SofasBackboneProducer” portType=“” operation=“” variable=“bprod:BankData” </reply> … </process>

<faultHandlers> … //relax the goal on maximum weight // <assign name = “WeightRelaxation”> … <copy> <from expression=“9”/> <to variable=“Weight_VA” part=“MaximumWeight”> </copy> </assign> //invoke the compensation e-service // <catch faultName=“FinalQualityControl” message=“weight_error”> … <invoke partnerLink=“” operation=“ns:MaximumWeightViolation+”_OP”” inputVariable=“ns:weight” </invoke> </catch> </faultHandlers> *even if not specified, ns is a namespace for the compensation service.

25

Una metodologia di supporto alla progettazione di sistemi di negoziazione cooperativa

Negoziazione cooperativa: stato dell’arte Elementi del modello Protocollo di negoziazione Applicazione al settore assicurativo

26

Negoziazione cooperativa: stato dell’arte

Non esiste letteratura consolidata nello studio della progettazione di sistemi per la negoziazione cooperativa

Esistono tentativi isolati di adattamento di algoritmi per la negoziazione in ambiente competitivo al caso cooperativo: Trade-off based negotiation Argumentation-based negotiation

27

Negoziazione cooperativa: stato dell’arte

Trade-off based Negotiation Un agente sceglie come contro-offerta quella che, a parità di

utilità, è più simile all’offerta proposta dalla controparte

Argumentation-based Negotiation Le offerte sono accompagnate da informazioni “accessorie” per

convincere l’avversario (espresse attraverso linguaggi derivati dalla logica del primo ordine)

28

Elementi del modello

Modello di negoziazione bilaterale multi-attributo con un cliente C (customer) e un fornitore S (supplier)

Il servizio negoziabile è costituito da n diversi attributi con 1 ≤ j ≤ n, il vettore degli attributi è X.

Il calcolo del prezzo p deriva dal valore assunto dagli attributi del servizio negoziato (dimensioni di qualità)

Ciascuna offerta al tempo t, perciò, è definita come :

(in questo caso l’offerta è fatta da C a S, gli indici si invertono nel caso in cui sia il fornitore a fare l’offerta)

jx

t

CSt

CSt

CS pXO ,

29

Elementi del modello: calcolo del prezzo

Il prezzo è calcolato a partire dai valori assunti dagli attributi del servizio negoziabile

Nel caso più semplice la funzione di calcolo del prezzo è lineare:

Per il cliente

Per il fornitore

Xfp

n

jSCjSC jxvp

1

n

jCSjCS jxcp

1

30

Elementi del modello: funzioni di utilità

Cliente e fornitore valutano la qualità di una determinata offerta attraverso una funzione di utilità n-dimensionale

Queste funzioni misurano le preferenze relative ai trade-off sulle caratteristiche del servizio dei partecipanti al processo di negoziazione

XVS XVC

31

Protocollo di negoziazione

Il protocollo è descritto assumendo il punto di vista del fornitore (tornerà utile per l’applicazione al settore assicurativo)

Il cliente fa un’offerta al tempo t: Il fornitore definisce una contro-offerta:

Il fornitore invia la sua contro-offerta al cliente solo nel caso in cui: e

Altrimenti accetta l’offerta del cliente al tempo t

t

SCt

SCt

SC pXO ,

111 , tCS

tCS

tCS pXO

tSCS

tCSS XVXV

1

n

j

tSCj

tSC jxcp

1

32

Definizione della contro-offerta: attributi di negoziazione

è ottenuto da (offerta precedente del fornitore) muovendosi verso di una certa quantità lungo la direzione di minima discesa della funzione

Si noti che è possibile adottare altre regole per generare il nuovo vettore degli attributi

1

tCSX 1

t

CSXt

SCX

tSS XVS

33

Definizione della contro-offerta: prezzo Il fornitore calcola il prezzo che assegnerebbe al

vettore di attributi e il prezzo ottenuto attraverso uno stimatore

della funzione di prezzo del cliente

Il prezzo associato alla contro-offerta sarà:

se

se

In prima approssimazione si può considerare uno stimatore lineare in base alle offerte del cliente negli istanti precedenti

n

j

tCSj jxcp

1

1

n

j

tCSj jxvp

1

1ˆˆ

pp tCS ˆ1

pp ˆ pptpp St

CS ˆ1

pp ˆ

tSCSCSC OOO ,,, 10

34

Applicazione al settore assicurativo

Nel caso del settore assicurativo deve essere eseguita una prima corrispondenza semantica tra gli elementi del modello e la realtà: Prezzo Premio Attributi Dimensioni di qualità del contratto assicurativo Funzioni di utilità Preferenze del cliente (misurano quanto il

cliente è disposto a cedere sulle caratteristiche di un attributo rispetto agli altri)

35

Il caso del settore assicurativo

Il modello adattato può essere sfruttato per creare servizi a valore aggiunto per siti web di compagnie assicurative (in particolare, calcolo e contrattazione automatica del premio in ambiente B2B)

In questo caso il modello è descritto per il fornitore, l’utente non sarà un agente, ma interagirà con il sito web della compagnia

Questa caratteristica implica la stima del comportamento del cliente nella scelta della strategia di negoziazione

36

Il caso del settore assicurativo: ruolo dell’utente

E’ stato introdotto un approccio alla negoziazione di tipo Q&A (Question and Answer)

Come avviene nei casi reali, l’utente interagisce con la compagnia rispondendo a domande relative alle caratteristiche del proprio contratto

Esistono vari tipi di domande: Funzionali: per fissare le caratteristiche del prodotto assicurativo Non-funzionali: per fissare l’interesse del cliente nell’affare o le

sue preferenze sugli attributi del prodotto

37

Definizione del vettore X

Scelta della classe di prodotto e corrispondenti attributi di qualità (predefiniti). Esempio:

Automobili RC auto

Animali Ristorazione

Marca autoModelloChilometraggio annualeTipo di utilizzoInformazione proprietario

Tipo di animaleRazzaSituazione veterinaria

Tipo di attivitàInformazioni stabileInformazioni generali/extra

•Tipo di cucina•Smaltimento rifiuti

•Età dello stabile•Locazione geografica•Impianto elettrico

•Storico assicurativo•Attività supplementari (es. musica live, giochi)•Richieste speciali

38

Definizione dell’offerta iniziale

Questionario iniziale che definisce l’offerta iniziale del cliente. Esempio (ristorazione):

Valutazioni generali

Sei il proprietario dello stabile in cui svolgi la tua attività?

Sei l’unico responsabile della tua attività?

Sei già assicurato con la nostra compagnia?

Valutazione requisiti funzionali

In quale tipo di stabile ha luogo la tua attività?

Quanti anni ha lo stabile?

In che hanno è stato controllato l’impianto elettrico, idraulico, gas?

Con che tipo di attività confina lo stabile?

Che stile di cucina utilizzi?

Quando hai cambiato l’ultima volta il sistema di smaltimento oli esausti?

Valutazione storico assicurativo.

Qual è la tua compagnia assicurativa attuale?

Che tipo di copetura del rischio fornisce?

Quante volte ti sei rivolto all’assicurazione nell’ultimo anno?

A quanto ammonta l’insieme dei risarcimenti negli ultimi tre anni?

Lo stabile è per qualche ragione ipotecato?

39

Definizione del prezzo iniziale

Esistono diversi modi per associare il premio alle risposte del cliente Il cliente può specificare un range di prezzo (ampio) che si

aspetta di pagare per la qualità del servizio che richiede Il cliente non esprime un premio, il premio caratterizza solo

l’offerta del fornitore Il cliente formula puntualmente il premio ritenuto opportuno in

base alla qualità che richiede

La nostra scelta è di utilizzare fasce predefinite per la prima offerta, tale offerta viene aggiustata durante il processo di negoziazione

40

Definizione dell’offerta iniziale

Domande a risposta multipla per permettere l’elaborazione automatica dei dati. I valori scelti vengono tradotti in valori numerici per essere elaborati dal modello.

Nel vettore X esistono due tipi di attributi: Attributi fissi: definiti dal questionario iniziale, non possono

essere cambiati durante il processo di negoziazione, a meno di errore che non consideriamo (es. caratteristiche stabile)

Attributi variabili: possono essere variati dal processo di negoziazione (es. diversi rischi da coprire, richieste speciali)

41

Associazione fra risposte e vettore X

In linea di principio, potrebbe essere costruita una base di conoscenza che classifichi la risposta del cliente all’interno di una categoria a cui è associata un valore numerico per l’elaborazione.

Abbiamo scelto più semplicemente di dare domande a risposte multipla tradotte staticamente (a priori) in valori numerici.

42

Associazione fra risposte e vettore X

Valutazione requisiti funzionali

Con che tipo di attività confina lo stabile?

Fabbrica di fuochi artificiali

Oratorio

Attività industriale

Attività commerciale

(Un valore alto implica un rischio più alto da coprire)

1

0.75

0.5

0.25

VettoreX

Tipo di copertura verso atti criminali

Totale

Minima

Media

Esclusi atti vandalici

1

0.75

0.5

0.25

VettoreX

43

Definizione del premio

Il calcolo del premio non può essere lineare come nel modello di partenza.

E’ necessario considerare principi di matematica attuativa e copertura bilanciata del rischio.

Le informazioni relative al rischio da coprire sono estratte direttamente dal vettore X, inclusi gli attributi definiti precedentemente come “variabili” maggiormente responsabili della personalizzazione della polizza.

44

Modello di rischio

Ciascun contratto assicurativo è definito da una serie di rischi

La diversa copertura dei rischi definisce i diversi tipi di polizze

La raccolta di informazioni empiriche per la definizione di un modello reale per il calcolo di rischio e premio è oggetto del lavoro corrente.

45

Definizione della funzione di utilità

Che cosa vuol dire fare la contro-offerta? Proporre nuove caratteristiche con nuovo prezzo (se il prezzo del

cliente/fornitore è inadeguato a quello che ha chiesto) La funzione di utilità del fornitore è definita secondo le proprie

caratteristiche di gestione del rischio per il prodotto assicurativo scelto (i trade-off si riflettono sull’utilità di una certa combinazione del valore degli attributi in relazione al bilanciamento del rischio su più polizze)

Una contro-offerta è costituita da un insieme di valori per gli attributi e un valore monetario del premio

46

Definizione della strategia

Nel modello teorico, la funzione α indica di quanto il fornitore/cliente è disposto a venire incontro alle richieste del cliente/fornitore in termini di qualità di servizio, in generale è una funzione crescente nel tempo

La funzione indica di quanto il fornitore/cliente è disposto a venire incontro alle richieste del cliente/fornitore in termini di prezzo,

Stiamo pensando a meccanismi di cooperazione che partano fortemente dall’offerta del cliente nella formulazione della contro-offerta da parte del fornitore.

tss

tSS

47

Stima della funzione di utilità del cliente

Il fornitore potrebbe sviluppare dei meccanismi per stimare la funzione di utilità del cliente

Per ora, il fornitore genera le sue offerte a partire dalle offerte della controparte e stima solamente il suo modello di calcolo del premio a partire dal valore degli attributi

48

Stima del premio

Il modello di calcolo del premio del cliente viene calcolato grazie a uno stimatore sui valori (insieme delle offerte precedenti del cliente)

In prima approssimazione può essere considerato uno stimatore lineare ai minimi quadratiIpotizzando che il calcolo del premio sia lineare ( ), il fornitore stima la seguente relazione minimizzando

Considerando k offerte possiamo scrivere la relazione in notazione vettoriale

Lo stimatore ai minimi quadrati del vettore dei coefficienti B è

2e

tSCSCSC OOO ,,, 10

enxxp nt

SC ...110

EXBP

PXXXB TT 1ˆ

49

Risultati ottenuti

E’ stato sviluppato un modello di negoziazione bilaterale più semplice interamente basato su un approccio di tipo Q&A

Tre gruppi di domande (per cliente e fornitore): Valutazione dell’interesse nella cooperazione della controparte Valutazione di requisiti/competenze Valutazione di ritorni/costi derivanti dalla fornitura del servizio

Le simulazioni si sono concentrate sulla scelta del miglior comportamento nelle risposte alle domande e sulla scelta dell’ordine delle domande ottimo in relazione al tipo di servizio negoziato

1) costs >> returns 2) costs ≈ returns 3) costs << returns

Is a sincere behavior beneficial?

The client can be deceived by an insincere supplier and should underestimate the supplier’s commitment to cooperation.

Sincerity does not affect results significantly. Sell and buy prices are mainly driven by requirements and competences.

The supplier can be deceived by an insincere client and should underestimate the client’s commitment to cooperation.

What is the best order of questions?

The client should start from the evaluation of the supplier’s commitment to cooperation.The order of questions asked by the supplier does not affect results significantly.

The supplier should ask questions in the following order: returns-requirements-commitment to cooperation.The client should leave the negotiation process after he provides requirements and understands competences.

The supplier should start from the evaluation of the client’s commitment to cooperation.The order of questions asked by the client does not affect results significantly.

Should costs/returns be disclosed to the counterpart?

If both parties behave sincerely, the best agreement is reached when both disclose costs and returns (>60%).

Disclosing costs/returns does not affect results significantly.

The client has no interest in showing his great returns. The small amount of supplier’s costs do not affect results significantly

Decision variables

Service