Datalogic (www.datalogic.com) è una delle poche aziende multinazionali nata in Italia: con una strategia bilanciata fra R&d e acquisizioni strategiche, in Italia e all’estero, è arrivata a circa 1000 dipendenti in dodici sedi europee, oltre che in Usa, Giappone, Cina e Australia; con una rete di oltre 500 partner in circa 60 Paesi serve clienti come Benetton, Blockbuster, Bmw, Carrefour, Castorama, Conad, Coop, Daimler Chrysler, Dell. L’organizzazione è suddivisa in tre unità di business che identificano altrettante famiglie di prodotti: la Hand Held Readers (lettori portatili e penne ottiche per applicazioni industriali e retail); la Mobile Computers (dispositivi portatili e terminali ergonomici per applicazioni verticali, con elaborazione dati raccolti e inoltro ai sistemi centrali – e relativi strumenti di sviluppo e soluzioni per la comunicazione wireless e networking); e la Unattended Scanning Systems (Uss, con lettori ottici per il codice a barre, sistemi di identificazione Rfid, stazioni di decodifica). Filosofia unificante delle tre business unit è garantire con la qualità i ritorni di soddisfazione del cliente e di riduzione dei costi. La Quality Assurance permea i processi di progettazione, gestione risorse, produzione e servizi post vendita.
Unificazione dei processi: best practice e cultura della configurabilità
Software Quality Assurance Manager dell’ingegnerizzazione software, per definizione il cruciale comun denominatore delle tre business unit, è da sei anni Alberto Bonechi, che ha la responsabilità di guida funzionale e supervisione (su un personale di circa 90 persone in ruoli diversi nelle tre Bu) dello sviluppo software per tutti i prodotti Datalogic, in un contesto di “processi di sviluppo eterogenei, dai microprocessori a 8 bit installati nei lettori hand held ai più complessi sistemi di Self Scanning dei supermercati, con tecnologie diverse da Java, C#, C++ ad ambienti di sviluppo embedded”. Bonechi ci descrive lo scenario trovato sei anni fa sostanzialmente in termini di silos isolati di sviluppo di componenti software.
Ma ecco il quadro degli obiettivi di qualità che si è prefisso. Primo passo: best practice condivise tra le business unit per la qualità funzionale di prodotto e di processo, su tutto il ciclo dello sviluppo, dai requirement ai test di accettazione, unificando i rilasci funzionali su due canali distributivi: il classico rilascio in produzione del software e dei tool a chi deve programmare le apparecchiature; in alternativa il portale su cui vengono distribuite le patch e i programmi per configurare e monitorare i prodotti finali. Secondo passo: messa sotto controllo della qualità delle componenti rilasciate al Repository (per la condivisione fra linee di business), unificando e “militarizzando” criteri di utilizzo (i componenti software realizzano l’algoritmo atteso – e in particolare, certezza del versioning, a garanzia di identificare e mantenere la corretta versione software), o criteri di riutilizzo (i componenti software vengono condivisi, mai “clonati”); nonché imponendo loro “proprietà agnostiche” rispetto all’ambiente target cui andranno ad appartenere. “Abbiamo sistematizzato il processo di sviluppo del software per le tre business unit, con l’obiettivo strategico di conferirgli regole che potessero essere condivise da tutti, al di là delle ovvie differenze, e di creare una cultura di configurazione” commenta Bonechi. “Con il 2002 è cominciato l’utilizzo sistematico di due strumenti per la configurazione software già presenti (Visual SourceSafe e PVCS Version Manager) e utilizzati fino ad allora per isole”. E dal 2004 sono stati sostituiti con Dimensions di Serena (www.serena.com ).
Dalla configurabilità al change management del core business
Gli ulteriori progressi nella razionalizzazione dello sviluppo core business si legano da questo momento all’esperienza nell’utilizzo di Dimensions (dal 2004 V9 e dal 2006 V10 in beta). Dimensions V9 è stato scelto inizialmente per la gestione della configurazione nel core business (cioè nello sviluppo software per prodotti Datalogic e non per altri processi aziendali, affidati a Sap sia per l’operatività che per lo sviluppo, su data base Oracle), e per il rilascio in repository con versioning per il software sviluppato esternamente, in modo che i test di accettazione identifichino esattamente i difetti. L’utilizzo di questo strumento ha subito offerto dello sviluppo e del processo software una visione finalmente unitaria, con la disponibilità di tutti i metadati (in sinergia col database Oracle); nonché la mappabilità delle componenti in termini di usabilità (Design Part Structure). Con queste premesse, è arrivato il momento del change management: l’introduzione del workflow fra i test di accettazione di nuove funzionalità o di regressione di funzionalità evolutive (con Test Director di Mercury) e il processo di pianificazione dei requisiti e di rimozione dei difetti (con TeamTrack di Dimensions), con cui fasare strettamente la pianificazione dello sviluppo software e la gestione dei difetti ai fini dei test di validazione. Consigli e “lezioni apprese” per la sempre delicata fase di adozione? Un accurato lavoro di formazione e di attenzione alla messa a punto processuale hanno facilitato il passaggio a Dimensions. Importante la strategia di ingaggio del nuovo strumento: prima il “mostrami come” con un progetto pilota in un sottogruppo della linea di business Unattended Scanning Systems. Poi l’estensione a tutta la linea entro fine 2004, e nel 2005 l’allargamento alle altre due business unit. Soprattutto vincente è stata la scelta di una sottounità il più possibile né troppo avanzata né ovviamente arretrata, ai fini di una più facile portabilità al resto delle business unit. Apprezzate “l’alta scalabilità” del prodotto, che ha permesso una progressione graduale, anche di investimenti, nonché la consulenza professionale del vendor, che ha evitato a Datalogic il ricorso a servizi di system integrator.
La gestione dei requisiti e il controllo sistemico delle regole
Terminato “da poco” il beta di Dimensions V10, Bonechi vi ha trovato l’incorporazione del Requirement tracking manager (Rtm, vedi l’articolo a pag. 26 del numero di marzo di ZeroUno). Il che soddisfa il preciso requirement espresso a Serena di una gestione requisiti, in modo che essa possa condivisa con le linee di business. E perché non anche uno strumento di gestione del portafoglio progetti, chiediamo noi? “Il dipartimento It di Datalogic nel suo insieme (engineering dei prodotti Datalogic, applicazioni di business e infrastruttura) – risponde Bonechi – gestisce naturalmente il suo portafoglio progetti per costruire, dare le giuste priorità ai progetti che ai requirement rispondono, ma è un processo, questo, che per ora non si avvale di uno specifico strumento di governance (Project Portfolio Management), disponibile sul mercato”.
Tra i vantaggi rilevati rispetto alla V9, il manager rileva notevoli progressi dal punto di vista dell’usabilità, come per esempio l’integrazione di Explorer. Una maggiore maturità in termini di processo di sviluppo: lo strumento è più vicino al processo reale riducendo la necessità di investire in formazione. È lo strumento che impone allo sviluppo una sorta di percorso obbligato, con forse una maggior laboriosità nel seguire i passaggi, che però alla fine paga in termini di aspettative soddisfatte nel mantenere il controllo. Anzi, Bonechi ha ritrovato nella V10 regole di processo “imposte” che con la V9 erano a carico dello sviluppo e che ora non serve più controllare (per ogni componente, identificazione e utilizzo di una data versione, garanzia di condivisione e non clonazione). Apprezzata inoltre la disponibilità di “precise misure che vengono elaborate e incrociate accedendo sia al database di Dimensions sia a quello della piattaforma Erp”, il che permette una vista condivisa con il business e “l’individuazione istantanea” di ogni mancanza di conformità. In definitiva, il controllo sistemico del processo di sviluppo nel core business “permette di puntare a nuovi livelli di certificazione”. Inoltre resta la prospettiva di estendere la gestione dei requisiti e la change governance oltre l’ambito core business (delle tre business unit) per ampliarne i benefici alla governance d’impresa.
