Le piccole imprese spesso tralasciano l’importanza e la semplicità degli strumenti software per la pianificazione e la gestione delle vendite. In tantissime occasioni mi è capitato di dialogare con clienti che si riferiscono alla attività di vendita come ad un’alchimia fatta di bravura ed esperienza.
Come al solito l’esperienza di consulenza mi insegna ad oggi che il commento migliore ad un’affermazione di questo tipo è dipende. Dipende dalla struttura del mercato, dai concorrenti, dalle competenze distintive dell’impresa che hanno portato al prodotto. Dipende da molteplici fattori, anche dall’esperienza.
Il punto focale non è a mio avviso centrato su ciò che è necessario per finalizzare la vendita. Bensì su tutte le attività preliminari che in qualche maniera devono mitigare il rischio di mancata vendita. In altre parole è logico pensare che con una misura approssimata del rischio un venditore possa massimizzare quantitativi di vendita ed ottimizzare percorsi e tempo.

Il software

Dal punto di vista del software, l’offerta di piattaforme SaaS (a consumo) o di applicazioni customer managed è vasta. Dalle applicazioni verticali per la gestione delle vendite (ticket management platform) sino alle applicazioni CRM, per l’approccio customer-centric, che integrano sinergicamente le attività di Marketing e di Pianificazione Strategica.

OK, quindi SaaS (software a consumo) o piattaforma in gestione al cliente?

La domanda non è semplice. Per fare una valutazione è necessario comprendere a fondo i requisiti dei clienti. Tuttavia per un piccolo di Team di vendita un applicazione SaaS può essere efficace se ben configurata. In ogni caso è necessaria un’attività minuziosa di comprensione dei requisiti e di configurazione della piattaforma remota. Spesso le informazioni richieste al cliente finale della soluzione sono così’ tante da indurlo ad abbandonare l’idea di utilizzare un software per la gestione delle vendite.

In definitiva il software deve sapersi adeguare al meglio al ciclo di vita del processo di vendita. Altrimenti si corre il rischio di duplicare le informazioni, di operare scelte errate, di separare e disallineare i dati e di creare molti altri bug umani di difficile risoluzione.

Miglior soluzione CRM?

La miglior soluzione CRM non esiste. La più congrua con le aspettative del cliente sì, ma esistono infinite combinazioni.
Ho personalmente testato diversi SaaS CRM platform. Tra tutte, la più completa è sicuramente Salesforce sulla quale presto o tardi scriverò un post.

Tra le applicazioni customer managed opensource spiccano invece:

• SugarCRM (PHP + MYSQL), che è dotata di un numero incredibile di moduli. a mio parere SugarCRM ben si adatta ad aziende di servizio.
• ConcursiveCRM (prima nota come Centric CRM, JAVA + POSTGRES) che è sicuramente più robusta ed è predisposta all’Enterprise Social Networking.
• OpenbravoERP, idonea solo per aziende di produzione; integra alla perfezione il modulo CRM con i moduli di gestione della produzione e degli approvigionamenti.

Ma conviene affidarsi ad applicazioni “in the cloud”?

Come al solito la risposta è “dipende”; ciò nonostante presto il SaaS si diffonderà e questo è inevitabile.
Nelle situazioni in cui siamo stati chiamati ad operare scelte, la soluzione di Groupware di Google (esempio calzante di SaaS) ha risolto diversi problemi di gestione. Le condizioni di abbonamento del groupware di BigG sono perfette per la piccola impresa: i primi 50 utenti gratuiti, dal 51esimo il costo per utente è di circa 40$.
Persino le applicazioni verticali che offre Jumpbox (SugarCRM, DimDim Web Conferencing, Asterisk) sono nei prezzi d’abbonamento molto competitive se paragonate all’installazione ed alla gestione di una piattaforma su macchine in housing o dedicated hosting.

Quindi conviene …

Certo pensando ai costi di una infrastruttura IT, della manutenzione delle macchine, dell’assistenza sistemistica ed altro si risparmia un bel po’ pur accettando delle soluzioni preconfigurate e poco personalizzate.
Questo però non risparmia le imprese dal dover acquistare consulenza per la configurazione dei sistemi virtuali e per la formazione. In un certo senso adesso la fornitura di soluzioni enterprise si è frammentata in componenti più piccole e in quest’ottica di disgregazione l’elemento di costo non è più la fornitura di sistemi, ma la consulenza professionale mirata a risolvere lo specifico problema aziendale con gli strumenti a disposizione.

Non c’è più spazio per i “real programmers”.

Secondo me, ed è una opinione assolutamente personale, il tempo dei 2 programmatori che sviluppano soluzioni dalla A alla Z si è chiuso da un pezzo. Il mercato richiede una sempre più spiccata capacità di adeguamento e di interpretazione dei requisiti del cliente. Il “Real programmer” è tenuto oggi a interpretare, configurare, verificare e migliorare. L’attenzione è rivolta ai clienti più che alle soluzioni.

Se i programmatori “configurano”, chi programmerà?

I programmatori non sono limitati alla “configurazione” delle soluzioni. Possono lavorare fianco a fianco con il cliente per trovare soluzioni con gli strumenti a loro disposizione e possono al contempo impiegare (e questo è un investimento) parte del loro tempo allo sviluppo di progetti opensource.
In sintesi non c’è più spazio per le botteghe artigiane del software. O ci si affida ai colossi del software e/o si inizia a lavorare tutti insieme, condividendo parte del tempo a disposizione ed investendo sulle alternative opensource.

Proprio a questo proposito la mia attenzione si è focalizzata sulla piattaforma opensource NUXEO EP (http://www.nuxeo.org/xwiki/bin/view/Main/). NUXEO EP è parte della piattaforma ECM (Enterprise Content Manager) Nuxeo DM. Sviluppata con tecnologia J2EE, supporta una implementazione JCR (JSR 170), lo standard openLDAP e tante altre feature, tra cui spicca in particolare la presenza di una interfaccia REST.

Se pure impegnativa nello sviluppo, la piattaforma consente di progettare velocemente applicazioni personalizzate che possiedono workflow ed oggetti su misura del cliente. Lo sviluppo è veloce, c’è un ottimo tutorial per la configurazione di Eclipse ed il codice è ben organizzato.

La potenzialità della piattaforma è evidente quando si usa il Document Manager standard di NUXEO. Infatti è possibile separare in maniera netta contenuti e presentazione. Per i contenuti è possibile progettare workflow di creazione, revisione, approvazione; si possono anche utilizzare funzionalità di collaborazione, condivisione cartelle, controllo di versione e gestione decentralizzata degli utenti (ognuno decide cosa, quando e come decidere). L’accesso ai contenuti (che vengono memorizzati su repository JCR e su db) può essere effettuato da un qualsiasi client JCR compatibile. L’integrazione con WebDAV rende semplice la visualizzazione delle folder nel proprio sistema oeprativo.

La presentazione dei contenuti è un’attività completamente separata. Si possono implementare logiche separate per il retrieving e l’ordinamento dei dati, interfacce dinamiche e mutevoli al variare dell’utenza. Si può anche pensare alla presentazione dei contenuti come ad un’attività separata dal flusso di revisione  e pertanto esternalizzata ad appositi professionisti e consulenti di comunicazione web e marketing (pubblicità occulta: www.managingcomplexity.it).

Mi piace particolarmente questa piattaforma. Impegnativa di certo: lo sviluppo JAVA non è una passeggiata (io collaboro con altre 2 persone per sviluppare un’applicazione di test). Ma offre la spalla ad un web pensato in maniera differente, a misura di chi lo visita.

Di seguito una lista di esempi interessanti:
http://component-showcase.icefaces.org/component-showcase/showcase.iface

La separazione tra business logic e visualizzazione è tale che in fase di implementazione dei singoli componenti di una applicazione web, ci si scorda letteralmente dell’HTML (vi è mai capitato di prender nota delle modifiche HTML in fase di progettazione di una applicazione?!?!?!?!?!? tedious … ).
Rende anche la pianificazione del lavoro più semplice e snella, alla luce del fatto che gli incontri con i grafici sono considerevolmente ridotti in numero. Inoltre, e questa è la cosa che mi ha colpito di più, il fatto che JSF sia uno standard ha permesso la creazione di tool visuali automatizzati per il design delle UI.

Al momento sto testando alcune interazioni AJAX su componenti JSF, incluse nella libreria opensource creata da Icefaces (http://www.icefaces.org/main/home/). Al termine del test pubblicherò qualche piccolo esempio.

Accettato il 2.0 come modello organizzativo allora ci si deve confrontare con due obiettivi, evidentemente correlati: il primo, che è quello di reperire la base di dati rilevanti su cui lavorare, pone il problema del livello di accessibilità dei dati sia in termini di costi finanziari sia in termini di costi di gestione (selezione e aggiornamento etc.); il secondo è quello di individuare criteri di aggregazione efficaci rispetto all’obiettivo che ci si prefigge, e cioè alla qualità del metadato che si vuole ottenere.

Molti dei “guru” del web 2.0 osservano che si tratta di un modello che può anche considerarsi virtuosamente “parassitario”, in quanto può fondarsi su iniziative che mirano anche solo a rendere più efficiente e intelligente l’aggregazione di dati già reperibili sul web, ma in forma assolutamente disorganica e frammentaria.
Questo di sicuro sposta gli equilibri consolidati del segmento della gestione informatica dei dati ed apre spiragli interessanti per chi sarà in grado di innovare e rinnovarsi continuamente.

In particolare in questo progetto abbiamo cercato di sperimentare l’integrazione di un CRM e di un service ticket manager nel segmento delle certificazioni ambientali. La procedura di certificazione è in assoluto una delle procedure più codificabili, tuttavia nella esecuzione dei diversi task devono essere considerate delle opportune finestre di dialogo con il cliente. In sintesi è possibile dire che l’attività di certificazione in sé è Agile, adattabile al variare dei contesti e delle situazioni. Bene inteso, per attività di certificazione se ne intendono i processi che permettono ad un valutatore di stabilire l’aderenza ai criteri prefissati. Lungi da me il voler attribuire flessibilità ai parametri di valutazione.

Codifica dei processi

Fianco a fianco con un consulente Managing Complexity (nel 2008 non esisteva ancora il brand, ma il team era già consolidato) e spalla a spalla con il responsabile qualità di Natifortunati abbiamo redatto una codifica formale dei processi (BPR) identificando attori, attività ed applicazioni coinvolte. Successivamente sono stati definiti gli indici di performance (KPI).

Al termine dell’attività di progettazione abbiamo quindi realizzato una serie di diagrammi di stato, di input per la definizione del software;

Il software

La piattaforma realizzata offre due interfacce differenti per l’accesso ai servizi. La prima dedicata agli addetti alla vendita ed alla certificazione, la quale include:

- gestione dei workflow attraverso meccanismo dei ticket;

- gestione documentale;

- gestione della knowledge base e strumenti per la formazione continua.

La seconda è dedicata allo staff marketing ed ai responsabili di vendita e permette la gestione della relazione con i clienti (CRM). La piattaforma è basata sul software opensource Sugar CRM (http://www.sugarcrm.com). Si è resa necessaria anche una ulteriore pianificazione dei processi di vendita e delle policy di accesso ai dati.

Criticità

Il progetto è stato lungo e complesso. La piattaforma software è stata sviluppata in fase di startup della società e questo ha caratterizzato variazioni sensibili di contenuti e tecnologie in corso d’opera. Ciò nonostante in 4 mesi di sviluppo è stata messa a punto l’infrastruttura di comunicazione, di groupware e di gestione. L’integrazione di diverse competenze ha avuto un ruolo centrale.

Il progetto originario si basa sulla considerazione che nell’ambito dei dati territoriali, il ciclo di vita di un dato può essere modificato se si introducono meccanismi di collaborazione e condivisione. In particolar modo un dato territoriale che descrive una informazione georiferita cessa la sua utilità per il singolo progettista nel momento in cui il progetto cui quel dato si riferisce viene chiuso.

La probabilità di riutilizzare quella informazione è mediamente bassa. La condivisione del dato offre invece l’opportunità di accedere ad un insieme denso di informazioni che proprio perché già fruite da coloro i quali le condividono sono selezionate, catalogate e verificate. Contrariamente alla prassi condividere dati conviene.

Per quel che concerne la tipologia dei dati condivisi è possibile fare una distinzione tra:

1. - dati che sono la diretta emanazione di vincoli normativi (vincoli ambientali SIC, ZPS, cartografie, ortofotocarte);
2. - dati descrittivi che in particolari condizioni offrono una conoscenza migliore del territorio (dati di geomarketing, rilievi puntuali, progetti urbani)

Lo sviluppo della piattaforma

Sulla base di questa premessa il nostro ruolo nel progetto si è incentrato sulla identificazione di formati aperti che potessero agevolare i meccanismi del riutilizzo e sulla selezione e configurazione di una piattaforma di aggregazione dei dati georiferiti. La scelta opportuna di un formato di interscambio dei dati ha condizionato in parte la scelta della piattaforma.

Abbiamo sin da subito messo in luce la potenzialità dei formati aperti per i dati territorialD ed in particolare i formati WMS per immagini e WFS per vettori. A valle di questa considerazione abbiamo progettato il catalogo dei dati condivisi, implementandolo in un GIS, anch’esso opensource: la scelta è ricaduta sul Mapguide Opensource prima ed il Geoserver ultimamente.

Al sistema GIS è stato associato un sistema per la gestione di repository di dati con controllo di versione per la duplice gestione di dati condivisi e dati privati ed un database server POSTGRES/POSTGIS per richieste high-efficiency e teamwork territoriale.

Abbiamo anche sviluppato una interfaccia con le librerie EXT e supporto a Google Maps per l’utilizzo più immediato del sistema.

Il formato dei dati

Per evitare problemi di disallineamento o di proliferazione di standard di rappresentazione, ci siamo avvalsi della consulenza di un team di ingegneri civili e di urbanisti. Il problema della uniformità degli standard di rappresentazione è in effetti molto presente tra amministrazione e progettisti.

In particolare possono riscontrarsi:

1. - sistemi di coordinate differenti per la rappresentazione dei dati;
2. - simbologie di rappresentazione differenti;
3. - modalità di rilievo differenti;
4. - formati digitali differenti.

Si è pertanto proceduto alla definizione di uno standard di ripubblicazione dei dati cui attenersi indicativamente.
Si è anche progettata la funzionalità di valutazione dei dati all’interno della piattaforma, affinché pur evitando di escludere dati non correttamente formattati, si possa dare evidenza a dati completi e coerenti.

Fruizione dei dati

Al progettista che ne ha fatto richiesta sono state fornite le credenziali per l’accesso al sistema. Durante il primo contatto sono state fornite informazioni dettagliate sulla connessione del client al server GIS MAXMAP. Le reazioni in alcuni casi sono state sorprendenti: la possibilità di progettare e verificare immediatamente la compatibilità vincolistica ha entusiasmato così tanto i progettisti che ci ha spinto a sviluppare un prodotto server (hw + software opensource preconfigurato) per l’archiviazione collaborativa dei dati all’interno di contesti professionali ristretti. Il data server aziendale è poi collegato all’archivio collaborativo di MAXMAP.

Criticità

MAXMAP si è connotato sin dall’inizio come un progetto complesso e ci ha messo a dura prova perché ha significato rimettere in discussione prassi e orientamenti diffusi tra i progettisti. Questo ha richiesto una buona dose di flessibilità, una enorme dose di follia e modifiche in corso d’opera senza eguali. Un  progetto così ambizioso non avrebbe potuto essere sviluppato che con una metodologia Agile.

Ad oggi

Il progetto MAXMAP ha subito diverse modifiche: un rebranding (adesso infatti prende il nome di puntoglobo), l’ambito geografico di riferimento (che si è esteso all’intera nazione), una nuova piattaforma software ancora più incentrata sul controllo di versione e la creazione di annotazioni collaborative (metadati) sui dati condivisi.
Per portare a compimento le modifiche il servizio web è al momento sospeso, il supporto tecnico ovviamente no. Il nuovo MAXMAP vedrà la luce a gennaio 2010.

SSS, SideScan Sonar

I rilievi dei fondali marini sono stati effettuati mediante l’ausilio di un particolare strumento acustico, il side-scan sonar, che è in grado di rivelare tutte le anomalie del fondale come ad esempio rocce isolate. Emettere impulsi sonori ad alta frequenza (120 Khz)e ne registra i tempi di ritorno.

Tiling KML

Per poter quindi procedere all’integrazione tutti i dati (curve di livello vettoriali ed immagini) sono stati convertiti nel formato KML, utilizzando per le immagini il meccanismo di tiling per la veloce visualizzazione.

Il tiling è un meccanismo molto semplice. A differenti livelli di zoom si suddivide l’immagine in rettangoli. A zoom molto ravvicinati si ottengono molti rettangoli, allo zoom esteso, si utilizza la singola immagine di partenza.

Per poter automatizzare la procedura e garantire al cliente autonomia nella conversione dei dati abbiamo scritto un po’ di codice che con l’ausilio delle librerie FWTools e GDAL opera automaticamente la trasformazione di file di immagine con correlazione (TIFF + TFW, JPG + JGW, … ) in file KML con tiling (KML, file di testo descrittivo della griglia del tiling + cartella con singole tile in formato TIF, JPG, …).

In maniera programmata (è bastato aggiungere una linea al crontab) il programma esegue la scansione dei file in una cartella condivisa e ne copia il risultato “tiled” nella cartella del webserver da cui si approvvigiona il client web.

Conversione vettoriale in KML

Il KML è un ottimo formato descrittivo per i dati territoriali. Si adatta bene a formati d’immagine e si adatta ancora meglio a formati vettoriali. Per questo motivo abbiamo convertito i dati vettoriali rivenienti dai rilievi cartografici nel formato SHP in KML, utilizzando gli FWTools ed operando nel mentre una trasformazione di coordinate in WGS84. Il sistema WGS84 ci ha permesso poi di sovrapporre i dati alle mappe di Google.

Client web

A conclusione, grazie alle API di Google Maps, e con una buona dose di javascript e librerie PHP (SOAP) abbiamo assemblato l’interfaccia finale, basandoci principalmente sul criterio della semplicità e della facilità d’accesso. Giovanni, il nostro esperto di interfacce ha realizzato uno studio splendido, testando con un campione di 5 progettisti differenti soluzioni alternative (un ringraziamento va al team di Managing Complexity che ha curato la pianificazione e la creazione dei survey per i test).

Criticità

Abbiamo lavorato particolarmente bene nel progetto G.E.Co. non vi sono state grosse evoluzioni dell’idea iniziale e questo ci ha permesso di tener sotto controllo tempi e costi. Nel contempo abbiamo maturato expertise nell’ambito della ottimizzazione e del caching dei dati KML, un ambito nuovo che ci ha fatto sperimentare nuove soluzioni.

Evoluzioni

Il progetto G.E.Co. si è concluso nel 2008, tuttavia siamo così orgogliosi del lavoro fatto che abbiamo deciso di integrare nel progetto MAXMAP alcune delle funzionalità sviluppate, riscrivendo parte del codice.

SL è un metaverso tridimensionale multiutente e interattivo ( … cosa che in effetti suona complessa … ), tutti i contenuti grafici 3D sono creati dai suoi residenti e sono poi “animati” da un linguaggio di scripting: LSL. LSL è modulare e orientato agli eventi.

Abbiamo subito notato che SL supporta nativamente un sistema per conferenze chat e audio di gruppo, quindi è bastato creare il nostro gruppo e abbiamo avuto a disposizione un canale privato con cui comunicare. La cosa che ci è parsa subito evidente, è che mancavano alcuni utilissimi strumenti presenti su altre piattaforme, come la condivisione di file e desktop.

Nonostante quest’ultima non sia supportata da SL, nulla ci vieta di creare una lavagna sulla quale visualizzare immagini, o addirittura video, si potrebbero creare poi lavagne da visualizzare a tutto schermo (oggetti HUD) per ogni utente, controllate dalla lavagna principale.

Quello che in uno script non mancherà mai è lo state default, che è lo stato iniziale in cui si trova un oggetto; successivamente si possono creare altri stati personalizzati, per esempio una porta potrà avere gli stati open e close per indicare che la porta è aperta o chiusa.


integer n, card;
default{
state_entry(){ //questo evento si scatena quando entriamo in uno stato in questo caso all'avvio dello script
card=llGetInventoryNumber(INVENTORY_TEXTURE);
//card contiene il numero di texture presenti nell'inventario dell'oggetto
n=0;
}
touch_start(integer total_number){ //questo evento è eseguito quando faccio click sull'oggetto
string texture_name;
if(n<card){
n++;
}else{
n=0;
}
texture_name=llGetInventoryName(INVENTORY_TEXTURE, n);
llSetTexture(texture_name, ALL_SIDES);
}
}


Questo script, attaccato in un prim (una primitiva geometrica) a forma di parallelepipedo, crea una rudimentale lavagna, quindi basta riporre tutte le immagini nell’ inventario dell’oggetto. Facendo click su di esso cambiamo immagine, fino a scorrerle tutte per  poi rincominciare dall’inizio.

Con SL il meeting online è pertanto semplice e possibile

Sono alle prese con lo sviluppo di un catalogo aziendale di dati georiferiti. In particolare l’ingegnere responsabile del settore Logistica mi ha chiesto se fosse possibile ottimizzare gli spostamenti di materie prime tra le differenti sedi di produzione.

Sul momento ho pensato che in effetti il problema è facilmente risolvibile: utilizzando qualche vecchio brandello di codice in MATLAB, un po’ di ricerca operativa e di programmazione lineare ed il gioco è fatto. Poi però, ho pensato che senza ricorrere al risolutore di Excel (o meglio al risolutore What’s Best) avrei potuto cercare di integrare questo tipo di  strumenti in un gis opensource, ad esempio in udig.

In ArcMap questo genere di problemi sono risolti con l’estensione Network Analysis e se non ricordo male anche Geomedia dovrebbe avere un tool del genere (se non ricordo male il Transportation Manager). Tuttavia a pensarci bene mi è venuto in mente che non esiste nulla del genere per udig e qgis. Una breve ricerca conferma il mio sospetto.

L’unica alternativa opensource è GRASS che in effetti non è poi così user friendly.  Ciò nonostante ho voluto fare qualche prova con i tutorial di GRASS reperibili in rete.

Le prove

Download ed Installazione di Grass 6 su Mac

Fortunatamente esiste una versione precompilata per Mac (il pc che ho utilizzato è un Macbook con MacOSX Leopard) di Grass 6. Per procedere con l’installazione del software, è però necessario installare prima alcune librerie.
Le istruzioni dettagliate sono su http://grass.itc.it/grass64/binary/macosx

Step 1. Installazione delle librerie necessarie.

Operazione relativamente semplice da svolgere. Si apre il link http://www.kyngchaos.com/software:frameworks e si scaricano tutte le immagini DMG delle librerie, che successivamente devono essere installate.

Questa è la lista delle librerie che ho installato.

• FFTW3 framework v3.1.3-1
• FreeType framework v2.3.9-1
• UnixImageIO framework v1.0.31
• PROJ framework v4.6.1-3
• GEOS framework v3.1.1-2
• SQLite3 framework v3.6.16-1
• GDAL framework v1.6.1-8
• ECW plugin v1.6.1-1

Step 2. Installazione di Grass

L’immagine DMG di Grass 6.4 RC5 è scaricabile da GRASS.app 6.4 RC5-3 (Leopard)

Caricamento dei dati d’esempio

— continua —