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
Top Related