Aziende

Durante il mio percorso professionale come consulente ho operato presso molte aziende, di settori diversi; l'elenco seguente riporta le principali:

  • Allergan (finance SAP);
  • Avery Dennison (finance Peoplesoft, vendite ACG);
  • Aviointeriors (finance, controllo di gestione, acquisti, logistica, produzione);
  • Averna (system management SAP);
  • Bard (finance, magazzino, System/21 JBA);
  • Baxter (finance ACG, integrazione vendite PIVOT);
  • Benacquista Assicurazioni, Latina (brokeraggio assicurativo);
  • Bose (finance SAP);
  • Brill Manitoba (produzione, logistica ACG);
  • Bristol Myers Squibb (finance SAP);
  • Castalia (controllo di gestione);
  • CIT Viaggi (consulenza, direzione, front/back office agenzie);
  • Consip (e-procurement);
  • Consorzio Agrario Provinciale di Latina (finance ACG);
  • Credifarma (finance ACG, segnalazioni PUMA);
  • Edilpro (controllo di gestione);
  • Engelhard (finance ACG);
  • Ethicon (magazzino p.f. PRISM, promotori, forecast produzione);
  • Eurovita (consulenza);
  • Fincosit (st. di fattibilità portale corporate ed intranet);
  • Finegil, gr. Espresso (consolidamento contabilità, ACG);
  • Fon S.p.A. (automazione pratiche mutuo);
  • Glitsch (finance, magazzino, vendite, produzione ACG);
  • Kemon (finance, vendite, magazzino, system management SAP);
  • Klopman (finance ACG, vendite DATATEX, acquisti ACG, claims, ecc.);
  • ICCRI (promotori);
  • Infrasud (controllo di gestione);
  • ITTIERRE (finance SAP, integrazione con Hyperion e STEALTH);
  • Lafargessi (finance, vendite ACG, EDI);
  • Manetti & Roberts (produzione, magazzino ACG);
  • Pennacchi Costruzioni (vendite calcestruzzi, finance e controllo ACG);
  • Pfizer (configuration change control);
  • Sangemini (auditing sistemi, consulenza);
  • SICAMB (finance, costing produzione MAPICS);
  • SIL Leasing (consulenza);
  • SIPLEDA (system management SAP);
  • STOLL (vendite, workflow automation);
  • SVEI (Controllo di gestione);
  • UBAE Arab Italian Bank (rete locale OS/2, office automation, Notes);
  • Uniroyal Chemical (sviluppi custom);

Ho anche avuto spesso occasione di stabilire partnership o collaborazioni con primarie aziende di servizi o società di consulenza:

  • IBM (APDC, laboratorio di sviluppo software applicativo, ed altri settori);
  • Arthur Andersen;
  • BNL Multiservizi;
  • Boston Consulting;
  • Booz-Hallen & Hamilton;
  • KPMG;
  • SAP Italia Consulting.

Il rapporto con i collaboratori è sempre molto formale...

 
Progetti

Riporto nel seguito alcuni progetti o risultati che ritengo particolarmente significativi, per l'impegno richiesto, per il livello di innovazione introdotto, o per le particolari problematiche di integrazione affrontate.

2001/2003
Portale finanziario e di Trading online Puntoborsa

Presso: Banca Finnat Euramerica S.p.A.

Il punto di partenza del progetto era una versione "beta" per un'applicazione TOL, che non era riuscita mai a decollare, oltre alla necessità di contenere possibilmente i budget per un progetto non strategico. Le risorse interne diponibili erano inoltre scarse, in quanto già impegnate in altri progetti. I requisiti non erano tuttavia facili:

  • informativa di mercato e news in tempo reale,
  • funzioni avanzate di monitoraggio in tempo reale degli ordini di Borsa,
  • position keeping e situazione di liquidità e portafoglio in tempo reale, a fronte di un sistema legacy inerentemente batch.

La soluzione disegnata si è basata sull'outsourcing della parte di front-end Web dell'applicazione, presso una società Olandese, integrandovi anche l'informativa finanziaria. L'applicazione usa delle componenti di base sviluppate da tale società, integrate con delle servlet Java custom, per la presentazione dei dati del portafoglio, e l'interazione con i sistemi di middle-tier. L'application server è Resin.
Il disegno grafico del sito è stato realizzato da una giovane Web-agency romana, che già collaborava con successo con la nostra azienda.

E' stato poi progettato un server di middle-tier, che elaborasse sia la parte di controllo accessi (per non avere informazioni sensibili esterne all'azienda), sia tutta la parte informativa legata al portafoglio del Cliente ed il trattamento degli Ordini. Questo componente si è integrato nei nostri sistemi di Raccolta Telematica Ordini (normalmente usati per la clientela istituzionale), apparendo come un ulteriore canale di alimentazione.
La realizzazione di questo componente è stata affidata ad una software house specializzata nella progettazione Java.
Come DBMS di appoggio al server di middle-tier è stato scelto MySQL.

Una parte centrale del progetto è stata l'analisi dell'interfaccia fra front-end e server di middle-tier: ho deciso di adottare lo standard SOAP (ancora non si parlava di Web services!). La gestione del progetto, ed in particolare della stesura delle specifiche di interfaccia, è stata affidata ad un consulente esterno di un'altra azienda, specializzata in applicazioni Web.
Quest'ultima azienda ha poi implementato anche un server per la raccolta di notizie da varie fonti, la loro normalizzazione, e l'alimentazione del repository di news del server di front-end.

Durante il periodo di beta testing, è emersa una criticità legata alle prestazioni del server di middle-tier. Ho così deciso di riprendere "in house" lo sviluppo di questo componente, scorporando tutta la parte di accesso ai dati legacy, scritta originariamente usando SQL e JDBC.
Ho quindi disegnato un componente object oriented, che rappresentasse le informazioni del portafoglio (lire e titoli) del cliente in tempo reale, tenendo in considerazione l'accavallarsi delle diverse fasi batch nei sistemi legacy centrali. Nel componente sono state integrate tecnologie più efficenti per l'accesso ai dati su host.
La realizzazione del componente è avvenuta internamente, formando un team di persone senza esperienza specifica, a sviluppare in Java, avvalendosi di strumenti di versioning (CVS), componenti Open Source, metodologie specifiche di documentazione e change control.
Il risultato è stato un drammatico miglioramento delle performance (la ricostruzione di una posizione è passata da circa un minuto a pochi secondi), e la disponibilità di un componente riutilizzabile anche in altri contesti, in cui è concentrata, in modo univoco, la logica applicativa propria dei vari pacchetti che compongono il legacy.

L'architettura aperta del sistema ha anche consentito di sperimentare un sistema di autenticazione dell'utente mediante one-time password, inviata ad ogni login tramite un SMS.

Il meccanismo di autenticazione è stato anche esteso anche al canale di contatto con la clientela rappresentato dal Call Center: l'applicazione (nativa iSeries IBM) che gli operatori avevano a disposizione è stata integrata con un modulo che, interagendo con il server middle-tier, consente il riconoscimento del Cliente usando gli stessi codici utilizzati per l'accesso via Web.

1999/2000
Centrale Acquisti Pubblica Amministrazione Centrale
 

Presso: CONSIP S.p.A.
In collaborazione con: Booz Hallen & Hamilton

Il progetto, di ampio respiro, si è articolato in una fase di definizione del modello di business, una di progettazione della struttura informatica, dell'impianto normativo e dei processi, ed una realizzativa. L'obiettivo era la costituzione di una struttura che operasse come Ufficio Acquisti per tutta la Pubblica Amministrazione Centrale e, facoltativamente, anche per le altre amministrazioni pubbliche, usando tecnologie Web ed applicazioni di eProcurement.

All'interno del progetto, ed in particolare della seconda fase, sono stato il responsabile del team che aveva il compito di disegnare la struttura informatica per la gestione degli acquisti.
Ho quindi dovuto studiare in profondità l'offerta di mercato per applicazioni di eProcurement, dimensionare un'architettura in grado di smaltire il notevole carico di lavoro previsto (migliaia di utenti, centinaia di fornitori interconnessi, decine di migliaia di ordini l'anno, spalmati su 15/20 categorie merceologiche diverse.

E' stato anche necessario studiare e comprendere gli aspetti normativi e legali connessi al processo di acquisto: le possibilità di dare valore legale a transazioni eseguite via web, i requisiti di autenticità dei dati, le specifiche normative che si applicano agli acquisti della P.A., la formulazione di bandi di gara e contratti di fornitura che prevedano il web come unico canale di scambio di informazioni e transazioni.

A sostegno del lavoro, è stato anche realizzato un benchmarking con quanto realizzato in altre Nazioni europee ed extra-EU; in particolare ho visitato organizzazioni analoghe in Danimarca, Inghilterra ed Olanda, e studiato il materiale relativo ad iniziative analoghe in California, Australia, Malayisia.

1990/1993
Sviluppo di moduli e documentazione utente per ACG IBM
 

Presso: IBM APDC / HFCC.

In questo periodo ho coordinato diversi team di progetto, sotto la direzione del Laboratorio di Sviluppo di Software Applicativo di IBM, per realizzare alcuni moduli di varie versioni di questo popolare gestionale. Lo sviluppo è stato condotto su piattaforma AS/400, in linguaggio RPG.

L'attività ha richiesto l'adozione da parte del team di metodologie proprie dello sviluppo di software industriale, con particolare enfasi rivolta alla formalizzazione dei requisiti, all'analisi, alla cura dell'interfaccia utente, alla documentazione, ed al controllo di qualità.

Particolarmente interessante è stata la collaborazione con la struttura IBM dedicata all'ingegnerizzazione della Human Interface.

1995
Sviluppo di un'applicazione per delivery dati alla Rete dei Promotori Finanziari
 

Presso: ICCRI
In collaborazione con: IBM, TAS

La Banca stava costituendo una rete di promotori, ed il progetto prevedeva la realizzazione di un'infrastruttura per trasferire sul portatile la situaizone del Cliente. Nell'ambito del team proposi l'uso di Lotus Notes come strumento per la gestione di un database distribuito. L'applicazione risultante veniva alimentata centralmente da due interfacce verso l'Host (3090):

  • una prelevava una sintesi delle posizioni della clientela da un database DB2, replicandola su una struttura di database Notes. La connessione avveniva usando un client DB2 su Windows NT, collegandosi via RACF al database su Host, ed utilizzando un'applicazione Notes (Pump) per la replica dei dati.
  • La seconda era basata su una DLL scritta in C++, che veniva richiamata da una transazione CICS, ed alimentava (usando le API pubbliche di Notes) il database Notes centrale.

Tutte le informazioni sul database centrale erano corredate di informazioni per la restrizione degli accessi, in funzione della struttura gerarchica della rete dei promotori, e, sfruttando i meccanismi di replica selettiva di Notes, venivano inoltrati su rete frame-relay sui server delle sedi, e da qui sui singoli portatili.

L'applicazione Notes era corredata anche di un'interfaccia utente per la navigazione sui dati e la produzione di alcuni report per la clientela.

Le altre società nel team hanno realizzato l'applicazione di acquisizione degli ordini (che poteva collegarsi direttamente al CICS su Host, oppure alimentare il database Notes, operando offline), le parti su Host, e l'attività sistemistica per l'installazione della rete geografica.

Al termine del progetto realizzai anche un prototipo di interfaccia Web verso l'applicazione, che avrebbe consentito alla clientela di interrogare le proprie posizioni, con un meccanismo abbastanza sofisticato di sicurezza.
I tempi del boom del trading online erano ancora lontani, e la Direzione dell'Istituto non ritenne una tale funzionalità di interesse per la clientela.

1992
Applicazione di gestione dei dati di tracciabilità dei prodotti
 

Presso: Ethicon S.p.A.

L'Azienda aveva la necessità di costituire un archivio con i dati di tracciabilità dei prodotti spediti a Clienti.
L'applicazione di gestione Vendite e Produzione era PRISM, e l'implementazione della gestione dei lotti (indispensabile su tale prodotto per gestire uno storico di tracciabilità) era considerata troppo onerosa e di impatto sugli altri processi.

Proposi quindi una soluzione esterna a PRISM, realizzata a vari livelli:

  • una rete di terminali portatili, collegati ad una base radio presso il Magazzino, e quindi con una linea dedicata sull'AS/400 ubicato presso il plant. I terminali consentivano agli operatori che effettuavano il prelievo di interagire direttamente con l'elaboratore centrale.
  • Un'applicazione, realizzata appositamente per le caratteristiche dei terminali, che consentisse la rilevazione dei dati dei lotti durante il processo di picking, sfruttando il lettore di codici che corredava i terminali.
  • Integrazioni a PRISM, che consentivano, in fase di stampa delle packing list e della documentazione di accompagnamento di riscontrare e confermare i dati di tracciabilità rilevati sul campo.
  • Un'applicazione Access che scaricava dall'AS/400 i dati di tracciabilità, e li archiviava su un supporto magneto-ottico, rispondente alla normativa in materia; l'applicazione consentiva anche l'interrogazione, per varie chiavi, dell'archivio.

Molte delle tecnologie utilizzate erano, al tempo innovative: l'uso di terminali radio portatili era all'inizio: dovetti aiutare l'Azienda ad espletare le pratiche di autorizzazione alla trasmissione radio presso il Ministero PP.TT. L'integrazione di tali terminali su AS/400 era anche nuova: il fornitore non aveva esperienze specifiche in Italia. Il packaging dei prodotti era spesso inadeguato alla lettura automatica dei codici a barre (ad esempio per il posiizonamento delle stripe di alluminio per apripre il cellphane delle confezioni, per cui fu necessario interagire con i plant statunitensi di origine. Il drive magnetoottico era di recente introduzione, Access era alla versione 1.0, ed i driver per collegarsi in ODBC con l'AS/400 ancora poco stabili.

Una particolare cura richiedette inoltre l'ingegnerizzazione delle applicazioni per il picking e packing, in modo da non interferire con l'efficenza dei processi, e considerando la scarsa dimestichezza con strumenti informatici del personale addetto.

1990
Migrazione da UNISYS ad AS/400
 

Presso: Klopman International

L'azienda doveva migrare da un elaboratore Unisys alla piattaforma AS/400 di IBM. Le applicazioni erano state tutte sviluppate internamente, in COBOL e con tool propri della piattaforma Unisys, ed il personale IT aveva esperienza esclusivamente in quest'area.

Ho diretto una parte del progetto di migrazione, che prevedeva l'adozione di applicazioni di mercato (ACG per la parte finanza, magazzino, acquisti e DATATEX per le vendite e la produzione).

La strategia seguita è stata di puntare molto sulla formazione del personale IT, valorizzando il know how specifico dei processi dell'azienda proprio di ogni persona, e lavorando molto al loro fianco fino a renderli sufficientemente autonomi sul nuovo sistema. La formazione è stata accompagnata da un forte supporto nell'analisi e realizzazione di personalizzazioni, programmi di migrazione, reportistica, in modo da non penalizzare i tempi di completamento del progetto.

Dopo pochi mesi l'azienda era operativa con la nuova piattaforma, ed il suo reparto IT era rimasto l'interlocutore principale dell'utenza, malgrado la centralità della mia figura (e del mio staff) nelle attività di analisi funzionale e tecnica.

Dopo meno di un anno, il settore sistemistico è stato in grado di effettuare in autonomia un'avanzata riconfigurazione dello storage sui propri AS/400, su sistemi in produzione, testimoniando un'assoluta padronanza anche delgi aspetti più peculiari della nuova piattaforma.

1985
Procedura di Workflow Automation per l'erogazione di mutui
 

Presso: Credito Fondiario ed Industriale (FONSPA)

Il Cliente aveva l'obiettivo di migliorare l'efficenza del suo processo di definizione di una pratica di mutuo.

All'epoca non si era ancora affermata la disciplina del Workflow Automation, tuttavia la soluzione che ho ideato era in tal senso.
L'indicazione tassativa del Cliente era sull'utilizzo della piattaforma AS/400, per cui la soluzione fu incentrata sull'uso del Word Processor nativo di questa piattaforma, all'interno del prodotto Office Vision.
Su questo strumento fu costruita l'automazione del contratto di mutuo, sfruttando veramente al massimo le possibilità dello strumento. Il contratto fu quindi realizzato come un documento con un forte livello di automazione, in cui le parti variabili venivano ricavate dal database, ed una logica condizionale governava la selezione delle sezioni rilevanti.

Una serie di moduli specializzati consentiva ai diversi attori (funzionari addetti alla stipula, estimatori, notai, provvista, ecc.) di gestire i dati di propria pertinenza.

La soluzione andò in produzione in u quinto del tempo stimato a suo tempo dal reparto IT interno dell'azienda, e consentì al cliente di rispettare il time to market richiesto per il lancio di marketing delle nuove caratteristiche del servizio.