Struttura del file di configurazione

In base alle modifiche illustrate precedentemente, la struttura del file xml di configurazione del BusinessFramework `e stata ampliata.

17_{In realt`a si parla di gruppi di variabili.} 18_{Si intende il coefficiente angolare.}

Parametro del nuovo tipo system per l’impostazione del sistema: case

[Valore numerico intero]

Indica il numero identificativo del caso per il quale il sistema dovr`a impostare il proprio funzionamento (attualmente i valori assumibili sono 1 o 2 ).

Aggiunta ai parametri di tipo variables: ritardo ultimo acquisto

[Valore booleano]

Indica se bisogna considerare la variabile relativa al ritardo del- l’ultimo acquisto.

ratio ultimo acquisto [Valore booleano]

Indica se bisogna considerare la variabile di ritardo dell’ulti- mo acquisto sulla somma di media e deviazione standard della distanza di acquisto.

resi fatturato

[Valore booleano]

Indica se bisogna considerare la variabile relativa al rapporto fatturato resi su fatturato.

resi acquisti

[Valore booleano]

Indica se bisogna considerare la variabile relativa al rapporto numero di resi su numero di acquisti.

La nuova struttura complessiva del file di configurazione finale, nel caso del BusinessFramework, si presenter`a in questo modo19:

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <configuration>

<system>

<case>2</case> </system>

<input> <acquisti>5,10,15</acquisti> <vita>1,2,3</vita> <abbandono>10,15,20</abbandono> <data>01/01/2006</data> </input> <database> <url>jdbc:postgresql:database</url> <user>user</user> <password>0,0,0,0,0,0,0,0,0,0,0,0</password> </database> <variables> <fatturato_margine>true</fatturato_margine> <sconto_fama>true</sconto_fama> <fama_numacq>true</fama_numacq> <insoluto_fatturato>true</insoluto_fatturato> <insoluto_r_fatturato>true</insoluto_r_fatturato> <ritardo_riacquisto>true</ritardo_riacquisto> <distanza_acquisti>true</distanza_acquisti> <frequenza>true</frequenza> <ratio>true</ratio> <settore/> <agente/> <categoria_fatturato/> <categoria_margine/> <ritardo_ultimo_acquisto>true</ritardo_ultimo_acquisto/> <ratio_ultimo_acquisto>true</ratio_ultimo_acquisto> <resi_fatturato>true</resi_fatturato> <resi_acquisti>true</resi_acquisti> </variables> <model> <minnumobj>10,30,60</minnumobj> <difference>0,1</difference> <mode>true</mode> <k>3,6,9,12,24</k> <h>0,3,6,9,12,24</h> <trindex/> <teindex/> <thr>0.0,0.3,0.5</thr>

<giorni>false</giorni> <distance>false</distance> <multitest2>false</multitest2> </model> <security> <pbe>0,0,0,0,0,0,0,0</pbe> </security> </configuration>

Per la DMU, invece, il file di configurazione `e pi`u compatto:

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <configuration> <input> <acquisti>10</acquisti> <vita>2</vita> <abbandono>15</abbandono> <data>01/01/2010</data> </input> <database> <url>jdbc:postgresql:database</url> <user>user</user> <password>0,0,0,0,0,0,0,0,0,0,0,0</password> </database> <model> <soloabbandoni>true</soloabbandoni> <unionlista>false</unionlista> </model> <security> <pbe>0,0,0,0,0,0,0,0</pbe> </security> </configuration>

Si fa notare che nella DMU innanzitutto occorre specificare un unico valore dei parametri di input, perch´e questi ultimi devono corrispon- dere esattamente ai parametri usati nel particolare modello caricato (nel BusinessFramework, al contrario, possono essere inseriti pi`u valo- ri per permettere di generare un vasto numero di modelli per tutte le combinazioni possibili). Non compare inoltre il campo per lo switch del caso di studio: essendo un tool dedicato all’utenza finale e che

quindi pu`o essere usato esclusivamente per un’unica azienda, si `e pen- sato che questa informazione fosse meglio cablarla nel codice, in modo da non poterla modificare. La struttura della DMU rimane comune la medesima in ogni caso e mantiene tutti i moduli in maniera completa, viene modificato solamente un flag interno per l’impostazione del caso da utilizzare.

L’unico cambiamento rispetto al file di configurazione della suite di partenza `e la sua sinteticit`a: sono riportati solamente i campi stret- tamente necessari, mentre sono tagliati fuori tutti quelli che servono esclusivamente al BusinessFramework.

4.3

Comportamento complessivo dei tool

dopo l’estensione

Vediamo ora il comportamento complessivo di BusinessFramework e DMU, dopo aver subito le variazioni precedentemente illustrate. BusinessFramework

Dalle modifiche descritte precedentemente possiamo dire che il Busi- nessFramework `e notevolmente cambiato, o pi`u correttamente si pu`o dire che `e stato ampliato.

Riassumendo tutto quello fin qua detto, la fase di ETL per ogni dataset da generare prevede:

1. inizio generazione del dataset solo se non presente 2. campionamento se richiesto e mancante

3. trasformazione se richiesta 4. ottimizzazione se richiesta 5. estrazione della clientela 6. etichettatura della clientela 7. generazione delle variabili

Il comportamento restante che riguarda la fase di Data Mining, ossia la generazione e la validazione del modello, rimangono invariati, cos`ı come la creazione dei file risultanti.

Figura 4.2: Comportamento del BusinessFramework

DMU

Per quanto riguarda invece la DMU, il comportamento per la singola esecuzione `e rimasto lo stesso, tuttavia `e possibile utilizzare un avvio in cui vengono lanciate pi`u istanze sequenzialmente per testare la pre- visione per pi`u date a distanze regolari di tempo.

I due processi contemporaneamente in esecuzione avranno un proprio flusso di controllo separato, tuttavia l’applicazione principale rimarr`a in attesa che l’altra sia terminata prima di continuare e successiva- mente lanciare l’esecuzione di un’altra DMU.

Simulazioni e test

In questo capitolo verranno illustrati i risultati ottenuti con la so- luzione software descritta nei precedenti capitoli, implementata per automatizzare il processo di previsione degli abbandoni per il caso aziendale trattato. Il risultato consiste in uno o pi`u modelli generati a partire da una combinazione ottimale di valori dei parametri coinvolti, ottenuti tramite simulazioni; i modelli definitivi vengono scelti sulla base di successivi test.

5.1

Processo di generazione e verifica dei

modelli

Per ottenere un modello secondo l’analisi e le caratteristiche mostrate nel capitolo 2, i passi da eseguire sono i seguenti:

1. Generazione di molteplici modelli tramite massicce simulazioni in cui vengono provate pi`u combinazioni di parametri di input 2. Analisi e selezione dei modelli migliori

3. Test di previsione dei modelli scelti per periodi temporali ravvi- cinati

4. Analisi dei risultati e selezione dei modelli che hanno generato il minor numero di errori

Alla fine di questo lungo procedimento otterremo uno o pi`u model- li adatti a predire gli abbandoni per l’azienda in questione; nel caso questo non si verificasse, o se comunque si volessero avere risultati mi- gliori, occorre ripeterlo cambiando i parametri usati per le simulazioni. Nelle sezioni successive verranno discusse le tappe principali che por- teranno ad avere un buon modello di previsione per il caso aziendale che ci interessa.