Metodologie di progettazione di e-service come sistemi di supporto alle transazioni Chiara Francalanci 1 giugno 2004

2 Sommario Stato dellarte e problemi aperti Una metodologia di progettazione di e-service: dallanalisi dei requisiti organizzativi allimplementazione 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 Limpresa virtuale (Virtual Enterprise, VE): Si configura come lesatto contrario rispetto allimpresa 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 tradizionaleImpresa 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 lobiettivo 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 unarchitettura composta da un Service Provider, un Service Broker e un Service Requester.

6 Passi metodologici 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 allinterno 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 allinterno dello stesso attore)

8 Passo 1 - Specifica di attori e dipendenze: notazione (2) Dipendenze Decomposizione Means-end (1) Attori e dipendenze (2) Scomposizione

9 Passo 1 - Specifica di attori e dipendenze: struttura di una transazione Diagramma di livello 0 Linsieme 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

14 Passo 2 – Specifica concettuale: operazionalizzazione Risorsa di controllo: è associata ad un set di tuple M i = me ij, mea ij con me ij j- esima metrica e mea ij j-esima misura di una risorsa r i. Risorsa di coordinamento: è associata ad un set di tuple obbligatorie A i = a ij, t ij, con a ij j-esimo attributo obbligatorio e t ij j-esimo tipo della risorsa r i, e ad un set di attributi opzionali OA i = oa ij, t ij, con oa ij j-esimo attributo opzionale e t ij j-esimo tipo di una risorsa r i. Goal: è associato ad un set di tuple PRE i = t ij, pre ij, con t ij j-esimo task che contribuisce al conseguimento del goal g i e pre ij j-esima pre-condizione che deve essere verificata prima di eseguire t ij, e ad un set di tuple POST i = t ij, post ij, con t ij j- esimo task che contribuisce al raggiungimento del goal g i e post ij j-esima post- condizione che deve essere verificata dopo lesecuzione di t ij.

15 Esempio di operazionalizzazione

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 loperatore Sequence(). ritardo (Wait-for, Wait-for, Delay ) informativa (Urge, Notify ) ri-negoziazione (Relax, Tighten, Delete ), ri-esecuzione (Re-execute, Re-execute-from, Skip ), sostituzione (Replace ).

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. Notazione

18 Esempio: distretto di matera

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 laccodo 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

22 Esempio: scheletro WSDL <definitions name=BackboneProductionService targetNamespace= xlmns:tns= xlmns= xlmns:soap= xlmns:xsd= Example of message … Example of operation and port-type <portType name=BackboneProduction_PT Example of fault message* … … messaggio Port-type e operation Fault message

23 Esempio: scheletro BPEL (1)

24 Esempio: scheletro BPEL (2)

25 Una metodologia di supporto alla progettazione di sistemi di negoziazione cooperativa Negoziazione cooperativa: stato dellarte Elementi del modello Protocollo di negoziazione Applicazione al settore assicurativo

26 Negoziazione cooperativa: stato dellarte 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 dellarte Trade-off based Negotiation Un agente sceglie come contro-offerta quella che, a parità di utilità, è più simile allofferta proposta dalla controparte Argumentation-based Negotiation Le offerte sono accompagnate da informazioni accessorie per convincere lavversario (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 lofferta è fatta da C a S, gli indici si invertono nel caso in cui sia il fornitore a fare lofferta)

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

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

31 Protocollo di negoziazione Il protocollo è descritto assumendo il punto di vista del fornitore (tornerà utile per lapplicazione al settore assicurativo) Il cliente fa unofferta 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 lofferta del cliente al tempo t

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

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

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, lutente 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 dellutente E stato introdotto un approccio alla negoziazione di tipo Q&A (Question and Answer) Come avviene nei casi reali, lutente 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 linteresse del cliente nellaffare 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 AnimaliRistorazione Marca auto Modello Chilometraggio annuale Tipo di utilizzo Informazione proprietario Tipo di animale Razza Situazione veterinaria Tipo di attività Informazioni stabile Informazioni 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 dellofferta iniziale Questionario iniziale che definisce lofferta iniziale del cliente. Esempio (ristorazione): Valutazioni generali Sei il proprietario dello stabile in cui svolgi la tua attività? Sei lunico 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 limpianto elettrico, idraulico, gas? Con che tipo di attività confina lo stabile? Che stile di cucina utilizzi? Quando hai cambiato lultima 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 allassicurazione nellultimo anno? A quanto ammonta linsieme 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 lofferta 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 dellofferta iniziale Domande a risposta multipla per permettere lelaborazione 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 allinterno di una categoria a cui è associata un valore numerico per lelaborazione. 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) VettoreX Tipo di copertura verso atti criminali Totale Minima Media Esclusi atti vandalici 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 sullutilità 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 dallofferta del cliente nella formulazione della contro-offerta da parte del fornitore.

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 quadrati Ipotizzando 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 è

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 dellinteresse 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 dellordine delle domande ottimo in relazione al tipo di servizio negoziato 1) costs >> returns2) costs returns3) costs << returns Is a sincere behavior beneficial? The client can be deceived by an insincere supplier and should underestimate the suppliers 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 clients commitment to cooperation. What is the best order of questions? The client should start from the evaluation of the suppliers 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 clients 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 suppliers costs do not affect results significantly Decision variables Service