Progetto gestione indici commerciali o semplicemente G.I.C.

Il progetto gestione indici commerciali (G.I.C) ha occupato gran parte del mio tempo all’interno di un azienda manufatturiera, e ha richiesto una non poca capacità di progettazione del Sistema Informativo Territoriale (S.I.T.) L’idea del progetto è nata durante alcuni analisi preliminari con lo scopo di poter analizzare  alcuni indicatori di carattere economico-commerciale e di poterli visualizzare sul territorio.

E’ stato necessario affrontare il problema della progettazione dell’intero progetto con la tecnica top-down, e quindi a partire da quelle che sono le esigenze a grandi linee di alcuni dipartimenti, si è poi scesi alla realizzazione vera e propria del S.I.T, ovviamente sempre all’interno di un contesto a più fasi del progetto. Di seguito gli argomenti principali dell’articolo:

L’azienda e le nuove esigenze di mercato
Gli indici commerciali: quali sono?
Pianificazione e sviluppo del progetto G.I.C.
Fase 1: lo studio di fattibilità
Fase 2: analisi dei requisiti
Fase 3: fonti di dati disponibii e valutazione degli strumenti Hardware & Software
Fase 4: dal modello concettuale al modello relazionale
Fase 5: pianificazione e costruzione base dati
Fase 6: prototipo e fase di integrazione del sistema
Osservazioni sul progetto G.I.C.

L’azienda e le nuove esigenze di mercato

Nel corso di questi ultimi anni l’azienda in cui è stato sviluppato il progetto è cresciuta moltissimo sia nell’ambito commerciale che produttivo, ma un aspetto un pò trascurato è l’elaborazione e la raccolta di alcuni dati di importanza strategico-commerciale. In particolare, fino a questo momento non sono mai stati raccolti dati relativi al numero di offerte effettuate dal gruppo agenti, rivenditori o partner, o quali di queste si siano trasformate in ordini. Non si conosce quale sia l’articolo più richiesto in un certo ambito territoriale e non si comprende di consenguenza la distribuzione nel territorio italiano.

In questo momento storico l’azienda ha l’esigenza di poter elaborare alcuni piani di marketing-commerciale per poter “gestire” più propriamente la propria presenza nel territorio italiano e con tale obiettivo è stato avviato con la partecipazione di alcuni consulenti esterni all’azienda un progetto di gestione degli indici commerciali.

Gli indici commerciali: quali sono?

Da una serie di incontri tra i vari dipartimenti dell’azienda è stato possibile definire alcuni indici di carattere commerciale. Quali indici?

Nel contesto dell’azienda sono stato individuati quattro settori: il settore recupero crediti, il settore magazzino, il settore agenti e infine il settore partners/rivenditori/altri clienti. All’interno di questo settori sono stati trovati degli indicatori come il numero di contestazioni, il valore della controversia, il valore medio ordine il rapporto (numero ordini agenti / numero ordini front-office interno all’azienda), lo scostamento su obiettivo del fatturato degli agenti dei partners, dei rivenditori e degli altri clienti e così via. La tabella successiva mostra dettagliatamente gli indici commerciali previsti dal progetto.

Pianificazione e sviluppo del progetto G.I.C.

Per quanto riguarda la progettazione e lo sviluppo del progetto SIT si possono adottare più o meno tre modelli di cicli di vita: a cascata, a spirale e infine quello incrementale iterativo. Il primo modello (v. figura 1) è quello che più spesso viene utilizzato ed è quello dettato dal buon senso: un analisi iniziale, a cui segue un fase di progetto vera e propria e in ultima la fase di implementazione.

Il secondo modello (v. immagine 2) è quello che inizia con un analisi, poi il progetto e infine un implementazione e in seguito le tre fasi si ripetono fino ad ottenere un buon livello qualitativo. Nelle prime tre fasi vengono dichiarati solo gli intenti generici e poi successivamente si aggiungono altre funzionalità.

Il terzo e ultimo modello (v. immagine 3), quello ideale, divide il progetto in sotto-progetti all’interno dei quali si applica il modello a cascata. Così facendo ogni sotto-progetto è indipendente dagli altri e solo l’unione permette di costituire un prodotto utilizzabile. Anche se frammentato il progetto,  esso riesce a proporre delle parti (i sotto progetti) che possono essere utilizzate anche in altri progetti dando la possibilità di risparmiare un sacco di tempo in altri progetti. Il concetto chiave di questo modello è il riutilizzo delle parti.

Per quanto riguarda il ciclo di sviluppo del progetto in questione ho deciso di mantenere e riproporre alcune delle fasi descritte nella dispensa degli “APPUNTI DEL CORSO DI PROGETTAZIONE SISTEMI INFORMATIVI TERRITORIALI” di Giovanni Conforti e Rodolfo Fabiani con il contributo di Giorgio Ghelli e Maria Vittoria Masserotti. In base alla dispensa suddetta le fasi dello sviluppo del progetto SIT possono essere così elencate:

1. Studio di fattibilità
2. Analisi dei requisiti
3. Progettazione concettuale
4. Rassegna dei dati disponibili
5. Rassegna dell’hardware e software disponibile
6. Pianificazione e progettazione dettagliata del database
7. Costruzione del database
8. Prototipo / Benchmark
9. Acquisto e configurazione di hardware e software SIT
10. Integrazione del sistema
11. Sviluppo di applicazioni SIT
12. Uso e manutenzione del SIT

Le prime cinque fasi costituiscono il momento dell’analisi, mentre per quanto concerne il momento del progetto, esso comprende  le fasi 6),7),8),9). Infine, le fasi 10),11),12) strutturano l’implementazione del progetto. Ad ogni modo, le varie fasi verrano descritte più in seguito in questa breve relazione e secondo lo svolgere del progetto Gestione Indici Commerciali sono state affrontate la fase dello studio di fattibilità, l’analisi dei requisiti, la progettazione concettuale con obiettivo un modello relazionale del database, una rassegna dell’hardware e software disponibile, una fase di pianificazione e costruzione del database e infine la fase di prototipo e poi di integrazione del sistema.

Per riassumere per il progetto Gestione Indici Commerciali (G.I.C) sono state prese in considerazione le seguenti fasi:

FASE 1: lo studio di fattibilità

Lo studio di fattibilità fornisce un idea di quella che sarà l’implementazione del progetto specifico e ha lo scopo di fornire i requisiti di progetto in una prima forma generica  dopo una breve fase di concettualizzazione che normalmente comprende una fase di “brainstorming” con la definizione del problema e le possibili soluzioni.

La definizione del problema

Come già descritto all’inizio della relazione il progetto Gestione Indici Commerciali nasce come soluzione possibile alle continue richieste dell’azienda di poter visualizzare degli indici strategico-commerciali o più semplicemente indici commerciali sul territorio italiano. In pratica gli indici dovrebbero misurare l’efficienza dell’Azienda e dei suoi collaboratori.

Nell’ambito del progetto Gestione Indici Commerciali (G.I.C.) lo studio di fattibilità è stato fatto con un incontro tra i dirigenti dei vari dipartimenti dell’azienda e gli utenti dei sistemi informativi. Da tale incontro sono emerse alcune questioni sulle seguenti domande:

1. Cosa rappresentano gli indici commerciali?
2. Come possono essere raccolti gli indici commerciali?
3. Come possono essere visualizzati ed analizzati gli indici commerciali?

La soluzione al problema

Alla prima domanda posta precedentemente rispondo col dire che gli indici commerciali sono dei parametri che vengono utilizzati per la costruzione di una griglia di valutazione. La griglia di valutazione dovrebbe misurare l’efficienza dell’azienda, degli agenti e dei clienti.

L’esempio successivo chiarirà il concetto di indice commerciale, e la procedura di costruzione della griglia di valutazione.

Nell’esempio è valutata l’efficienza degli agenti in termini di fatturato, solvibilità e qualità del servizio ai clienti. Il fatturato, la solvibilità e la qualità del servizio costituiscono gli indici che dovrebbero essere in grado di misurare e valutare l’efficienza degli agenti.

Per l’indice fatturato costruiamo la seguente tabella

La colonna dell’obiettivo target è importante poichè si identifica con l’obiettivo di fatturato che l’azienda attribuisce all’ipotetico agente Pippo che lavora in provincia di Milano. A tale obiettivo si attribuisce un peso indice relativo all’obiettivo prefissato. Così, se per Pippo realizzare 100 milioni di fatturato in provincia di Milano significa ottenere un valore di peso indice di 40, allo stesso modo per Mario che lavora in provincia di Cagliari realizzare un obiettivo di 50 milioni significa ottenere un punteggio di 40 di peso indice. Ciò stà a significare che non si utilizza un scala di valutazione assoluta nel misurare l’efficienza di un agente ma si utilizza una scala di valutazione relativa all’obiettivo target che proviene da un analisi del mercato e del territorio ove operano gli agenti. La colonna dell’elemento di valutazione rappresenta il fatturato reale dell’agente e infine la colonna del peso relativo rank è definita dalla seguente formula:

(Elemento di valutazione / Obiettivo) * 100

Nella valutazione dell'agente si attribuisce un peso assoluto ai vari indici (che non è altro che la colonna "Peso Indice" presente nella tabella precedente, così per esempio all'indice fatturato attribuisco un peso di 50, all'indice solvibilità un peso di 30 e infine all'indice qualità di servizio un peso di 20.  Infine, il peso assoluto per ciascun indice si ricava con la seguente formula:

Peso relativo (Rank) * Peso conferito all'indice (Peso indice)

In seguito dopo aver costruito una tabella per la solvibilità e una tabella per la qualità del servizio si procede alla realizzazione della griglia di valutazione degli agenti.

Così per l'agente pippo il peso assoluto per l'indice fatturato è di 4000, quello per l'indice solvibilità è di 2000 e infine quello per l'indice qualità del servizio è di 900. Questo valore dipende dal peso dell'indice, dal fatturato realmente realizzato dall'agente e dall'obiettivo proposto dall'azienda.

In seguito, si sono determinate delle aree di valutazione chiamate BOLLE o SETTORI in cui si sono costruite le griglie di valutazione. Le bolle utilizzate in tale progetto sono state le seguenti:

1. La Bolla Agenti.
2. La Bolla Magazzino.
3. La Bolla Recupero Crediti.
4. La Bolla Partners / Rivenditori.

All'interno di tali bolle sono stati definiti degli indici che poi avrebbero composto la griglia di valutazione e non sono altro che gli indici già descritti precedentemente nella tabella 1.

Successivamente, si è parlato della realizzazione del progetto e le domande sono state le seguenti:

1. Come realizzare la raccolta dei dati per la gestione degli indici commerciali?
2. Quali applicativi utilizzare per visualizzare i dati raccolti?
3. Chi si occupa della realizzazione e dell'implementazione del progetto?

Dagli incontri a livello dirigenziale in seguito alle domande poste è emerso che:

Alcuni degli indici commerciali sono degli indicatori che servono a monitorare il grado di presenza dell'azienda sul territorio italiano; Non solo, gli indicatori saranno utilizzati per capire lo stato di efficienza degli agenti, dei partner, del sistema di gestione dell'azienda comprensivo della rete vendita (agenti) e della rete clienti (partner, rivenditori, posatori, architetti, privati, imprese).

Le fonti dati utili per costruire gli indici commerciali è stata individuata nell'esistente gestionale ERP presente nell'azienda di progetto e dall'applicativo da sviluppare per la raccolta di alcuni dati prettamente commerciali. In questo momento non si è ancora parlato della tecnologia utilizzata per la realizzazione del software di raccolta dati e nè della natura del software di visualizzazione dei dati.

La realizzazione e l'implementazione del progetto è stata attribuita a me e a un mio collega. In seguito, si è stabilito che per la visualizzazione degli indici commerciali si vorrebbero utilizzare strumenti free software poichè le applicazioni proprietarie hanno dei costi assolutamente insostenibili.

Sempre all'interno di tali incontri con la proprietà aziendale si è parlato del tempo necessario per ottenere dei primi risultati; Questo purtroppo dipendeva principalmente dal tempo che avevo a disposizione.

A chi interessano gli indicatori del progetto di Gestione Indici Commerciali.

Data l'importanza delle informazioni provenienti dagli indici commerciali nella valutazione dell'efficienza dell'Azienda nel suo complesso, i dati vengono esclusivamente utilizzati dai titolari dell'azienda e dalla componente diregenziale che attualmente si compone di un direttore commerciale italiano, da un direttore commerciale estero, da un direttore amministrativo, da un direttore del marketing e da un direttore produttivo. Fino ad ora l'andamento aziendale evidenziato dagli indici non era mai stato compreso nel suo complesso, ma ogni parte dell'azienda proseguiva  nell'ambito dei suoi step, quindi oltre ad avere un significato importante nell'indicazione dell'efficienza questo progetto permette di organizzare alcune informazioni che prima erano o forse non erano patriminio di un solo dipartimento. I dati ora ci sono e sono organizzati, prima i dati c'erano ma non erano organizzati: una grande differenza.   

FASE 2: analisi dei requisiti

Analisi dei requisiti

Con la fase dell'analisi dei requisiti si dovrebbero raccogliere tutte le informazioni necessarie per lo sviluppo del progetto Gestione Indici Commerciali in relazione alla visualizzazione di alcuni indicatori sul territorio italiano.

Per prima cosa si è identificato il contesto in cui il progetto G.I.C. nasce, poi si è chiesto ai vari dipartimenti dell'azienda ciò che volevano specificatamente dal progetto G.I.C. e quindi si è potuto determinare quali funzionalità implementare nel progetto. Infine, i dati fin qui raccolti sono stati riassunti in un documento di specifica che li analizza.

Detto ciò, diciamo che l'analisi dei requisiti si divide in due fasi: la raccolta dei requisiti che produce una serie di informazioni sull'utilizzazione del S.I.T., e una fase di stesura dei requisiti che produce un documento di riassunto della precendente fase di raccolta.

Il contesto aziendale

Per quanto riguarda il contesto aziendale, oltre ad una breve introduzione iniziale su chi è l'azienda e quali siano le esigenze attuali, potrei aggiungere soltanto che il progetto G.I.C. nasce internamente come richiesta di alcuni dipartimenti di poter verificare se l'azienda e chi lavora con essa siano “efficienti” sul territorio italiano. Per tale motivo si è scelto di rappresentare le informazioni geo-referenziando i dati raccolti a livello di Provincia per poi proseguire con analisi specifiche con tali dati.

Raccolta dei requisiti

Prima di procedere con la definizione dei documenti relativi alla stesura dei requisiti (punto di partenza del progetto) si procede a realizzare alcuni moduli da consegnare agli utenti utilizzatori del progetto G.I.C per poter così capire cosa serve e quali informazioni visualizzare.

Elenco dei moduli per la raccolta dati:

• Descrizione Applicazione G.I.S.
• Formato Mappa
• Formato Report
• Diagramma di Flusso
• Descrizione dati.

Per quanto concerne i moduli dei diagramma di flusso, data la loro complessità sono sviluppati  all'interno dei sistemi informativi per cui possono essere considerati documenti interni e non divulgati agli utenti utilizzatori.

Per cui l'elenco dei moduli si restringe ai seguenti:

• Descrizione Applicazione G.I.S.
• Formato Mappa
• Formato Report
• Descrizione dati.

Dai moduli di raccolta delle analisi dei requisiti sono emerse le seguenti applicazioni richieste dal SIT.

1. Interrogazione sulla distribuzione territoriale degli agenti, fornitori, rivenditori.
2. Interrogazione del fatturato degli agenti, fornitori, rivenditori sul territorio italiano.
3. Interrogazione indice Fatture solute / Fatturato totale per agenti, fornitori, rivenditori sul territorio italiano.
4. Visualizzazione nuovi clienti per agente sul territorio italiano. La scala interessata è quella provinciale.
5. Visualizzazione numero ordini agenti / numero ordini totali azienda sul territorio italiano
6. Scostamento fatturato su obiettivo azienda per agente, partner, rivenditore.

In sintesi le applicazioni richieste coincidevano con alcuni degli indici commerciali emersi durante le riunioni a conferma che già in quella fase l'analisi dei requisiti era già a buon punto.

La Master Data List (stesura preliminare).

La tabella seguente rappresenta la master data list del progetto G.I.C., cioè una versione preliminare del modello concettuale, delle entità e degli attributi che lo costituiranno.

Per la costruzione della master data list si integrano le diverse descrizioni dei dati e delle applicazioni producendo un'unica lista contenente tutte le unità o features e i loro attributi per la realizzazione del SIT.

FASE 3: fonti di dati disponibili e valutazione degli strumenti Hardware & Software

Elenco delle fonti di dati disponibili del progetto Gestione Indici Commerciali

Strumenti Hardware & Software per il progetto G.I.C.

Per la raccolta dei dati relative alle offerte clienti, alle richieste disponibilità, agli ordini clienti è stato sviluppato un software in linguaggio java (dal sottoscritto) su dbms mysql community 5.1 La scelta di questo dbms è stata fatta poichè oltre ad un vantaggio economico (essendo il software definito free-software), la gestione risulta particolarmente semplice. Putroppo, mysql non supporta appieno le funzionalità spaziali come il dbms postgres, ma in questo contesto non è richiesta tale funzionalità o per lo meno l'utilizzo di funzioni spaziali non è richiesta. Oltre a ciò, le analisi dei dati aziendali sono state fatte con Qlik e poi successivamente salvate in formato file di testo per poi essere utilizzate dal software Geoserver nella visualizzazione.

Il sistema di condivisione dei dati e di visualizzazione dei dati è il WebGis GeoServer che oltre ad una notevole semplicità di installazione permette anche una visualizzazione veloce dei dati da rappresentare.

Infine, il server in cui opera il tutto è un server ML-370 di Hp con Dual Xeon con 2 Gb di Ram, una configurazione RAID 5 per affidabilità e sicurezza dei dati, estremamente potente e veloce nell'esecuzione delle query e nel supporto a Geoserver. Il server ML-370 erà già presente in azienda per la gestione del magazzino automatico, quindi non abbiamo fatto altro che utilizzare ciò che già c'era. Per quanto riguarda le sessioni utenti sono abbastanza veloci grazie al motore Tomcat di Apache.

FASE 4: dal modello concettuale al modello relazionale

Il modello concettuale: verso una realizzazione

Per realizzare il modello concettuale utilizzerò il modello di Calkins che risulta essere una estensione del modello concettuale Entità/Relazioni. Per lo sviluppo del modello concettuale ho utilizzato il programma in linguaggio Java di Alessandro Ballini Java Diagrammi ER ver 1.3 (v. immagine n.4) che mi ha permesso di disegnare lo schema concettuale.

Per la proposta di schema concettuale era importante l'analisi dei requisiti e l'individuazione delle entità e degli attributi, cosa che è stato fatto nella Master Data List.

In un secondo momento, in seguito ad una analisi più approfondita dei requisiti raccolti è emerso che le entità erano più numerose di quelle trovate nella stesura preliminare della Master Data List e quindi ho proposto una seconda “Master Data List” pubblicata nella pagina seguente.

Le nuove entità entrate a far parte dello schema concettuale sono l'AreaComunalediinteresse, DatiIstat, Richieste, Fatturato, e Altro; La prima entità si riferisce all'area di azione dell'Agente a livello di area comunale. La seconda entità i DatiIstat è relativa alle informazioni specifiche di popolazione al censimento 2001, all'altitudine, e a tutti I codici istat relativi a Regioni, Provincie, Comuni e Località e anche al tipo di località. La terza entità le Richieste sono quei dati relativi alla raccolta delle richieste pervenute agli utenti commerciali in forma di telefonata, e-mail, fax, o direttamente dai partners, agenti o rivenditori. Ho aggiunto anche la figura di altro che comprende sia privati che imprese. L'entità Fatturato si riferisce al fatturato reale dei richiedenti (agenti, partner, rivenditori, e altro) suddiviso per mesi e inoltre è presente anche il numero di fatture non solute (dato utile per la costruzione degli indici commerciali).

Dopo aver adottato una strategia mista per lo sviluppo dello schema con la combinazione della strategia Top-down e Bottom-up sono giunto allo schema concettuale mostrato nella figura seguente.

Infine, ho adottato una fase di ristrutturazione dello schema con la eliminazione delle generalizzazioni. Le entità figlie si legano al padre con delle associazioni uno ad uno (v. immagine 6).

Traduzione verso il modello Relazionale (logico).

Inizio col tradurre quelle entità che hanno gli identificatori interni perchè sono più facili da tradurre.

Traduco l'entità UtenteReteVendita nella relazione seguente.

Poi, traduco l'entità UtenteReteDistribuzione nella relazione successiva.

Ora, traduco l'entità Fatturato nella relazione seguente.

Poi, traduco l'entità DatoIstat nella relazione successiva.

Infine, traduco l'entità Richiesta nella relazione successiva.

Per quanto riguarda le entità spaziali Comune, Provincia, Regione sono presenti all'interno di un file shape e non all'interno del database MYSQL utilizzato per memorizzare i dati non spaziali, per tale motivo non vengono tradotte in un modello relazionale.

Continuando nella traduzione ora analizziamo le ASSOCIAZIONI MOLTI A MOLTI  che nello schema concettuale costruito non sono presenti.

Passiamo quindi alle ASSOCIAZIONI UNO A UNO (POSSIEDE, POSSIEDE).

Esiste un vincolo di integrità referenziale tra gli attributi CodiceUtente e Ambiente della relazione Fatturato e gli attributi CodiceUtente, Ambiente della relazione UtenteReteVendita.

Allo stesso modo per le due relazioni successive

Esiste un vincolo di integrità referenziale tra gli attributi CodiceUtente e Ambiente della relazione Fatturato e gli attributi CodiceUtente, Ambiente della relazione UtenteReteDistribuzione.

Ora, traduco le ASSOCIAZIONI UNO A MOLTI (EFFETTUARE, EFFETTUARE, ASSOCIAZIONE, LAVORA).

Traduco l'associazione EFFETTUARE nel modello relazionale. Eseguo la traduzione come quella MOLTI A MOLTI e quindi ottengo così di seguito.

Data un UtenteReteVendita possono esserci più richieste o non esserci proprio, quindi la chiave dell'associazione effettuare è soltanto il Numerorichiesta e non la chiave composta CodiceUtente e Ambiente. Lo stesso UtenteReteVendita può effettuare più di una richiesta. Ma una richiesta appartiene ad un solo UtenteReteVendita. Risulta quindi che l'entità Effettuare e Richiesta posseggono la stessa chiave e quindi così di seguito.

Esiste un vincolo di integrità referenziale tra gli attributi CodiceUtente e Ambiente della relazione Richiesta e gli attributi CodiceUtente, Ambiente della relazione UtenteReteVendita.

Traduco l'associazione EFFETTUARE nel modello relazionale. Eseguo la traduzione come quella MOLTI A MOLTI e ottengo come di seguito descritto.

Per le considerazioni dette per la traduzione precedente ottengo la seguente.

Esiste un vincolo di integrità referenziale tra gli attributi CodiceUtente e Ambiente della relazione Richiesta e gli attributi CodiceUtente, Ambiente della relazione UtenteReteDistribuzione.

A questo punto traduco l'associazione ASSOCIAZIONE, quindi eseguo la traduzione come quella MOLTI A MOLTI e ottengo la prossima.

Dato un Comune possono esserci più località e quindi la chiave è il Pro_Com. Considerando che l'entità Pro_Com e l'associazione Associazione hanno la stessa chiave possiamo unirle e ottenere così la seguente.

Esiste un vincolo di integrità referenziale tra gli attributi Loc della relazione Datoistat l'attributo Loc della relazione AreaComunalediinteresse.

A questo punto non resta che tradurre l'associazione LAVORA e ottenere la seguente.

L'utente appartenente alla rete Vendita può avere più comuni ove lavora. Quindi la chiave nell'associazione Lavora è Pro_Com. Essendo uguali le chiavi tra Lavora e AreaComunalediinteresse possiamo unirle e ottenere così la seguente.

Esiste un vincolo di integrità referenziale tra gli attributi CodiceUtente, Ambiente della relazione AreaComunalediinteresse e l'attributo CodiceUtente, Ambiente della relazione UtenteReteVendita.

Infine la traduzione nel modello relazionale si riassume nella seguente.

Il modello relazionale prodotto è utilizzato per raccogliere le informazioni dai file di testo provenienti da Qlik e da quelli in formato excel di Istat. Allo stesso modo sono presenti anche i dati provenienti dall'applicativo da me realizzato in java per la raccolta delle richieste dei richiedenti.

FASE 5: pianificazione e costruzione base dati

Pianificazione e costruzione base di dati.

Una volta creato il modello relazionale per la raccolta dei dati provenienti dalle fonti dati già descritte nel capitolo quattro, elaboro uno schema (v. immagine 7) che mostra le base di dati coinvolte, e gli strumenti con cui ho effettuato la raccolta dati e lo strumento utilizzato per la visualizzazione dei dati territoriali e cioè GEOSERVER.

Come si vede nell'immagine  i dati provengono essenzialmente da quattro fonti: un file di testo esportato dal programma Qlik per i dati relativi al fatturato e in genere ai dati del gestionale elaborati, un file di tipo excel contenente i dati istat, i dati in formato Tab (MapInfo) di tipo spaziale contenenti le geometrie delle Regioni, Provincie, Comuni, e i dati provenienti da un applicativo Java utilizzato per la raccolta delle richieste provenienti dagli agenti, partner, rivenditori e altro inserite dagli utenti commerciali presenti in azienda.

Come si vede nell'immagine per l'inserimento delle informazioni dei dati istat e quelli provenienti da Qlik ho dovuto sviluppare una procedura di importazione in linguaggio java che mi riversasse i dati all'interno del modello relazionale precedentemente preparato all'interno della base di dati Mysql. Da aggiungere, come le fonti dati collegate a Geoserver sono essenzialmente Mysql e il file Tab (MapInfo).

Per quanto riguarda le fonti dati in excel non subiranno alcuna modifica durante l'importazione e verranno riversate sullo schema concettuale elaborato precedentemente durante la fase dl modello concettuale. Una volta pronti tutti i dati essi verranno caricati in GeoServer e successivamente visualizzati con OpenLayers.

Nell'immagine successiva possiamo osservare il flusso da e verso Geoserver.

Come si vede Geoserver utilizza i dati da diversi DBMS e formati, e attraverso i protoccoli WFS, VMS e WCS visualizza le informazioni in formato GML, JPEG, KML,GeoTiff e così via. Come client di visualizzazione per il progetto ho utilizzato OpenLayers. Nella prossima fase segue l'implementazione del progetto e una fase di prototipo con un piccolo esempio realizzato.

FASE 6: prototipo e fase di integrazione del sistema

Prototipo del sistema e integrazione.

Per quanto riguarda il prototipo del sistema ho scelto nel visualizzare tramite OpenLayer una delle interrogazioni emerse nel corso dell'analisi dei requisiti e in particolare la seguente.

Visualizzazione del numero di richieste disponibilità (offerte) effettuate da agenti, partners, rivenditori o altro per provincia nel periodo di test di un mese sul territorio Nord – Italiano.

Il risultato all'interrogazione è riassunto nell'immagine seguente. A seconda del numero di richieste l'area colorata più scura o più chiara (tematizzazione).

Il linguaggio utilizzato per la visualizzazione della parte di territorio con l'aiuto di Geoserver è OpenLayers che nel modo di programmare è simile a java e la sintassi è quella presente  nel  piccolo esempio successivo.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <link rel="stylesheet" href="/geoserver/style.css" type="text/css" />
    <style type="text/css">
        body {
            margin: 1em;
        }
        #map {
            width: 800px;
            height: 475px;
            border: 1px solid black;
        }
    </style>
    <script src="openlayers/OpenLayers.js"></script>
    <script type="text/javascript">
        OpenLayers.IMAGE_RELOAD_ATTEMPTS = 3;

        var map;
        function init(){
            map = new OpenLayers.Map('map');
            var political = new OpenLayers.Layer.WMS(
                "State",
                "/geoserver/wms",
                {layers: 'topp:tasmania_state_boundaries',
                 format: 'image/png'}
            );

            var water = new OpenLayers.Layer.WMS(
                "Water",
                "/geoserver/wms",
                {
                    layers: 'topp:tasmania_water_bodies',
                    transparent: 'true',
                    format: 'image/png'
                }
            );

            var roads = new OpenLayers.Layer.WFS(
                "Roads",
                "/geoserver/wfs",
                {typename: 'topp:tasmania_roads'},
                {
                    typename: 'tasmania_roads',
                    featureNS: 'http://www.openplans.org/topp',
                    extractAttributes: false
                }
            );
            roads.style = OpenLayers.Util.applyDefaults({strokeColor: "#ff0000"},
                    OpenLayers.Feature.Vector.style["default"]);

            var cities = new OpenLayers.Layer.WFS(
                "Cities",
                "/geoserver/wfs",
                {typename: 'topp:tasmania_cities'},
                {
                    typename: 'tasmania_cities',
                    featureNS: 'http://www.openplans.org/topp',
                    extractAttributes: false
                }
            );
            cities.style = OpenLayers.Util.applyDefaults({strokeColor: "#0000ff"},
                    OpenLayers.Feature.Vector.style["default"]);

            map.addLayers([political, water, roads, cities]);


            var panel = new OpenLayers.Control.Panel(
                {displayClass: 'olControlEditingToolbar'}
            );
            
            var drawLine = new OpenLayers.Control.DrawFeature(
                roads, OpenLayers.Handler.Path,
                {displayClass: 'olControlDrawFeaturePath'}
            );
            drawLine.featureAdded = function(feature) {
                feature.layer.eraseFeatures([feature]);
                // cast to multilinestring
                feature.geometry = new OpenLayers.Geometry.MultiLineString(
                    feature.geometry
                );
                feature.style.strokeColor = "#ff0000";
                feature.state = OpenLayers.State.INSERT;
                feature.layer.drawFeature(feature);
            }

            var drawPoint = new OpenLayers.Control.DrawFeature(
                cities, OpenLayers.Handler.Point,
                {displayClass: 'olControlDrawFeaturePoint'}
            );
            drawPoint.featureAdded = function(feature) {
                feature.layer.eraseFeatures([feature]);
                // cast to multipoint
                feature.geometry = new OpenLayers.Geometry.MultiPoint(
                    feature.geometry
                );
                feature.style.strokeColor = "#0000ff";
                feature.state = OpenLayers.State.INSERT;
                feature.layer.drawFeature(feature);
            }

            panel.addControls(
                [new OpenLayers.Control.Navigation(), drawLine, drawPoint]
            );

            map.addControl(panel);
            map.addControl(new OpenLayers.Control.LayerSwitcher());

            map.zoomToExtent(
                new OpenLayers.Bounds(145.51045,-44.0,149.0,-40.5)
            );
        }
    </script>
  </head>
  <body onload="init()">
    <h3>OpenLayers WFS-T demo: Tasmania cities and roads</h3>
    <a href="#" onclick="map.layers[2].commit();return false">Save Roads</a><br />
    <a href="#" onclick="map.layers[3].commit();return false">Save Cities</a>
    <div id="map"></div>
  </body>
</html>

Per quanto riguarda l'integrazione del sistema, l'installazione del server Mysql è stata effettuata all'interno di un server GNU/LINUX (distribuzione Fedora Core 6), mentre per quanto riguarda GEOSERVER si è preferita l'installazione su SERVER WINDOWS 2012 poichè non avevamo altre macchine a disposizione per fare 'girare' Geoserver senza problemi di lentezza. L'applicativo Java è stato installato sui client e in questo momento dieci postazioni lo adoperano senza problema.

Osservazioni sul progetto G.I.C.

Perchè una presentazione geografica. Quale vantaggio in questo caso specifico rispetto ad un report tabellare?

Effettivamente, una rappresentazione tabellare avrebbe potuto soddisfare ampiamente la comprensione degli indici commerciali, ma per quanto una tabella possa essere organizzata e rappresentare alcune informazioni, la rappresentazione geografica ha delle possibilità di comunicazione maggiori di un tabella, una capacità di organizzare le informazioni non solo rispetto a delle celle di una tabella, ma a delle ben precise locazioni in ambito geografico.

In fondo le applicazioni (interrogazioni) che sono emerse dall'analisi dei requisiti sono prevelentemente riferite ad un ambito geografico (provincia, comune) e via dicendo, quindi la scelta della rappresentazione geografica non è un semplice modo di rappresentare ma si presta benissimo a delle considerazioni complessive che in un report tabellare difficilmente potrebbero essere svolte; In particolare penso alle distribuzioni spaziali di alcune interrogazioni. In riferimento a queste distribuzioni spaziali considero importante sia le funzioni dei vari attori che partecipano al progetto e sia le funzioni che intercorrono tra loro a livello spaziale.

Nell'ambito del progetto G.I.C. Le funzioni non spaziali fanno riferimento ai dati numerici degli indicatori e alla loro appartenenza ad un determinato attore (agente, partner, rivenditore, altro), mentre le dimensione corologica fa riferimento alla distribuzione spaziale degli agenti, rivenditori, partner, altro e alla loro interazioni spaziali (compreso la distanza del loro campo di azione, il tipo di attività svolta se agente, o rivenditore o partner). Insomma, le interrogazioni spaziali o 'corologiche' difficilmente si prestano ad una rappresentazione non geografica.

Conclusioni

La raccolta e la rappresentazione degli indici commerciali è stato un progetto che ha portato un valore aggiuntivo all'azienda e un soddisfazione personale nella realizzazione. E' ovvio, che questo articolo è una sintesi alquanto breve di quanto fatto, ma sicuramente da una buona idea di come è stato pensato e realizzato il progetto.

Spero di aver trattato l’argomento in modo esaustivo, ma se qualcuno volesse esporre una qualche perplessità o domanda non esitate a “postare” dei commenti o ad inviarmi un e-mail a webmaster@megalinux.cloud.

Sostenete The Megalinux: In un mare di siti web sovraccarichi di pubblicità invadente, The Megalinux si distingue come l’unico rifugio libero da annunci. Abbiamo scelto di offrirvi un’esperienza di navigazione pulita e ininterrotta, ma per fare ciò, abbiamo bisogno del vostro supporto. Considerate l’idea di contribuire alla nostra missione inviando Bitcoin al nostro indirizzo. Anche una piccola donazione può fare la differenza e ci aiuterà a mantenere il sito libero da pubblicità.

È davvero difficile immaginare che esista qualcuno che, indipendentemente dalle donazioni ricevute (che non ci sono), continui a scrivere in totale libertà, tutto ciò o quasi che trova interessante?

3LpoukFpvDHTZPn5qGbLwUzve3rX9zsSq6