marketing plan

Buona parte dei blogger sono esperti di comunicazione e marketing.
Io no.
Per questo nell'assegnazione dei compiti per il nostro prossimo piano di marketing mi sono candidato per fare un lavoro di basso profilo: scrivere un articolo multifunzione, lasciando ai miei soci altri compiti ben più ardui quali frequentare il circolo del tennis, o del golf, sperando di conoscere qualche imprenditore potenzialmente interessato ai nostri servizi oppure attivare qualche venditore per diffondere il verbo.
Articolo multifunzione ? Certo:
Funzione a) documentare un progetto;
Funzione b) fornire ai venditori uno strumento per capire e far capire quello che devono vendere;
Funzione c) creare materiale commerciale per un convegno prossimo.

Mi fermo qui.
Ah, stamattina ho scritto la bozza della premessa. Se qualche anima pia ha voglia di leggerla e dare buoni consigli, assicuro che avrà l'anteprima esclusiva anche delle bozze successive.
Eccola:

Premessa – la scelta di SDWEB

In questo articolo illustreremo come un'Azienda, appartenente alla classica categoria delle PMI, abbia potuto rapidamente ottenere significativi benefici dall'utilizzo del servizio di accesso web ai sistemi direzionali(di seguito: SDWEB).

Il percorso inizia nel dicembre 2003, quando l'Azienda, circa 4 milioni di euro annui di fatturato con 1500 clienti attivi, avverte l'esigenza di sostituire il sistema informativo, che viene utilizzato “con soddisfazione” da oltre 10 anni. L'espressione “con soddisfazione” sta a significare che il sistema assolve adeguatamente le varie funzioni e necessità di ambito operativo, tuttavia il sistema appare totalmente inadeguato alle esigenze di controllo di gestione, dettate dalla situazione di mercato sempre più competitiva.

Dopo avere valutato approfonditamente una ipotesi di sostituzione del sistema informatvo con un erp di nuova generazione, l'Azienda decide di seguire una strada diversa, che mira alla rapida e diretta soluzione del problema più cogente: disporre di un efficiente e flessibile sistema di controllo delle aree commerciale e produttiva, nei tempi più rapidi ed ai costi più contenuti.

Nel corso dello studio di fattibilità per la sostituzione del sistema informativo, infatti, ci si rende conto di disporre di una base dati ricca ed aperta (il data base è Microsoft SQL Server); quello che manca, in realtà, è il Sistema Direzionale: quell'insieme di viste e di reports che permettono di eseguire adeguate analisi sulle dinamiche di gestione.

La scelta cade quindi sul servizio SDWEB per i seguenti principali motivi: a) l'esperienza dello staff di Koan srl nelle attività d'impianto dei sistemi di controllo aziendali; b) i costi certi e contenuti, basati sulla formula del canone d'uso, e l'assenza d'investimenti hardware e software (per l'accesso al servizio è necessario disporre esclusivamente di un collegamento ad internet); c) la possibilità di fruizione del servizio sempre e dovunque: il servizio infatti è attivo 24 ore su 24 e, in quanto accessibile via web, può essere consultato da qualunque postazione collegata ad internet, permettendone la fruizione anche da parte di collaboratori esterni all'azienda (es.: agenti, consulenti, ecc.) dotati di personali chiavi di accesso. (fine prima parte)

30/12/04 (seconda parte)

La fase di setup
A questo punto, siamo nel gennaio 2004, inizia la fase di impostazione del sistema.
Abbiamo detto prima che il data base era aperto, tuttavia una difficoltà particolare, che è quasi la norma in questi casi, derivava dalla totale mancanza di documentazione del data base stesso; nè si poteva fare affidamento su risorse aziendali che potessero conoscerlo, mancando completamente una figura di responsabile edp o equivalente; infine i rapporti con la software house fornitrice del sistema erp erano piuttosto "difficili" e non si riteneva fosse il caso di chiedere il loro aiuto per avere indicazioni su come reperire rapidamente le informazioni necessarie all'interno del db.
Quindi ci siamo dovuti rimboccare le maniche ed abbiamo dovuto scavare nel db, spulciando fra tabelle e viste, spesso con nomi molto simili fra loro, alla ricerca di quelle che facessero al caso nostro.
Ripeto, questa situazione è la norma, non l'eccezione, e non a caso questo tipo di attività è stato definito di "data mining", termine che rende proprio la fatica di procedere per tentativi alla caccia dei dati che servono.
In questa attività l'esperienza del professionista che esegue l'esame del db, l'individuazione delle tabelle "interessanti" e la verifica dei dati così rintracciati, costituisce la sottile differenza che può passare fra un fallimento totale del progetto (o, il che è lo stesso, un suo costo insostenibile) ed un successo.
Nel nostro caso l'individuazione delle tabelle (anagrafiche clienti e prodotti, movimenti di magazzino), la successiva verifica dei dati così individuati (es: quadratura del fatturato per cliente), e l'impostazione della query di estrazione delle informazioni da indirizzare al nostro datawarehouse, ha richiesto un impegno contenuto in circa 3 giornate di lavoro, che ci sentiamo di qualificare come "rapido".
(fine seconda parte)

07/01/05 (terza parte)

Una volta individuate le fonti delle informazioni di base si trattava ora di costruire il Sistema Direzionale vero e proprio.
La struttura avrebbe previsto i seguenti livelli:
a) estrazione ed aggiornamento periodico del datawarehouse
b) universo dati
c) set di reports e viste

Per quanto riguarda i dati da estrarre periodicamente essi possono essere raggruppati in dati anagrafici, dati temporali e dati quantitativi.
Dati anagrafici sono:
* codici e ragioni sociali dei clienti;
* codici e ragioni sociali degli agenti;
* codici di aggregazione dei clienti: categoria (rivenditori, utilizzatori, ecc.); città, provincia, zona, regione, nazione.
* codici e descrizioni dei prodotti;
* codici di aggregazione dei prodotti: (categoria merceologica, ecc.)
* unità di misura dei prodotti
Dati temporali sono:
* data ordine;
* data spedizione;
* data fattura;
* aggregazioni temporali (mese, anno di fatturazione).
Dati quantitativi sono:
* quantità venduta
* quantità (omogenea) venduta (espressa in kg)
* ricavo netto (in euro)
* costo del venduto
* provvigione di vendita

Si è previsto di aggiornare il datawarehouse, attraverso l'estrazione di queste informazioni elementari, in corrispondenza della chiusura della fatturazione mensile. Pertanto ogni mese, con una apposita query, vengono estratti i nuovi dati e trasferiti su una tabella. La tabella viene poi trasferita, a mezzo Ftp, sul server che ospita il datawarehouse e, a questo punto, scatta l'aggiornamento del datawarehouse stesso, mediante un processo di acquisizione dei nuovi dati.
Tale processo non è altro che una query di accodamento, definita come data transformation service ("dts": un componente standard di Microsoft SQL Server, che permette di impostare ed eseguire automaticamente, anche ad intervalli di tempo predefiniti, varie operazioni sulle tabelle di data base).

L'importanza dei servizi dts è notevole: essi permettono di rendere automatiche le tre fasi di aggiornamento del database, che sono:

estrazione dei dati “grezzi” dal database di origine;
importazione dei dati estratti, tramite ftp, nel server di destinazione;
aggiornamento, a partire dai nuovi dati estratti, delle tabelle che formano il datawarehouse.

Inoltre, grazie all'agente di pianificazione di Sql Server, è possibile impostare l'avvio automatico di tali operazioni ad intervalli di tempo prestabiliti.

A questo punto tutto era pronto per la pubblicazione dei reports destinati alla Direzione Aziendale.

La struttura dei reports adottata ha previsto un Report, il primo del menu, specificamente destinato alla consultazione a video: questo report, basato su un tool java, permette di eseguire all'interno del browser di internet le classiche operazioni di “esplorazione dati”. Partendo da una semplice struttura che mostra una tabella pivot con i dati aggregati per regione / mese, è possibile eseguire operazioni di “drill down” (letteralmente trapanare giù) disaggregando le chiavi di lettura in zone, agenti, clienti, famiglie di prodotti, e singoli articoli. Naturalmente è possibile poi il processo inverso di ritorno alle aggregazioni superiori, cioè di “drill up”.

Gli altri reports pubblicati sono invece espressamente progettati per la stampa, pertanto alla loro apertura viene caricato acrobat reader ed i dati (tabelle e grafici) vengono esposti in formato pdf, particolarmente adeguato per la stampa. Questa caratteristica non deve però far pensare che si tratti di reports statici. Anche questi, infatti, sono direttamente connessi con il datawarehouse e vengono aggiornati nel momento stesso della loro visualizzazione e, successivamente, a richiesta dell'utente.

Conclusioni

La più grande soddisfazione di questo progetto è notare come oggi l'Azienda trovi normale tutto questo ed abbia dimenticato l'epoca, non così lontana nel tempo ma veramente un'altra epoca, in cui ci si doveva accontentare di una conoscenza solo aprossimativa dei propri dati fondamentali, per citarne solo alcuni: clienti, prodotti, quantità vendute, importi fatturati.

collegamento auto-sponsorizzato: in questo blog a volte si parla di business intelligence, qui invece la si pratica di continuo.