Emilio Paolucci Paolo Neirotti Marco Sandrone La gestione della conoscenza nella produzione di software “a pacchetto”: il caso Dylog Emilio Paolucci Paolo Neirotti Marco Sandrone Politecnico di Torino Bressanone, 15 settembre 2006

L’azienda – breve storia Nata a Torino nel 1980. Nei primi anni di attività produzione di software solo su commessa. Da fine anni 80 specializzazione sul realizzare prodotti standardizzati dedicati a particolari nicchie di mercato e di prodotto (es. sw per commercialisti, agenzie pratiche auto, amministratori di condominio, etc.) Continua crescita basata su: acquisizione di software house focalizzate su particolari nicchie creazione di una piattaforma tecnologica comune sulla quale sviluppare nuovi prodotti specifici tramite il ri-uso di codice La proprietà è ancora oggi coinvolta nella direzione aziendale Punto di svolta a fine anni 80. inizia fase di intensa crescita guidata dall’acquisto di sw house focalizzate su particolari nicchie o su espansione in una nicchia tramite acquisizione di clienti, e al contempo dallo sviluppo di alcune architetture di prodotto trasversale ai prodotti e fondata sul ri-uso di moduli di codice Tanto per indenterci a fine 2005 l’azienda ha acquisito il 51% di Buffetti, alla base di questa operazione vi è una logica di integrazione verticale a valle, in modo da migliorare l’accesso diretto al mercato soprattutto per quanto riguarda I prodotti relativi all’automazione di ufficio (es. Pacchetit x commercialisti)

L’azienda – informazioni generali Fatturato (migliaia di euro) Fatturato 2005: 28 Mil. € Dipendenti 2005: 300 circa 4 sedi in Italia (Torino, Milano, Parma e Castelfranco Veneto), 1 in Francia, 1 in India. 50.000 applicativi installati, 3/4 nuovi prodotti ogni anno, 300 upgrades all’anno 3 linee di business differenti: Software gestionali Soluzioni per il controllo qualità (ispezione mediante Raggi X) software per la videosorveglianza Alcune informazioni per comprendere meglio la competitività dell’azienda

Il ruolo della gestione della conoscenza in Dylog Fondamentale assorbire la conoscenza di mercato dai clienti per la manutenzione evolutiva dei prodotti (capire nuove esigenze emergenti, debugging dei prodotti lanciati). Elevato “sforzo organizzativo” nell’assistenza post-vendita: 100 persone impegnate nell’attività di help-desk telefonico. Importante tenere traccia delle indicazioni/problematiche riportate dai clienti “non sempre il cliente più arrabbiato è quello che ha le indicazioni più preziose per il miglioramento del prodotto” Tre architetture di prodotto alla base di un portafoglio prodotti estremamente ampio (utilizzo di architetture modulari)

Il modello organizzativo Logimax e Amax Area tecnica 2 Segmento di mercato 1 (Gestionale per PMI) Area tecnica 1 Segmento 2 (Pratiche auto) Segmento n (...) Area tecnica n Area commerciale 1 Area commerciale 2 Area commerciale n Core tecnico Conoscenza di architetturale Conoscenza tecnica modulare Conoscenza di mercato Core tecnico: sviluppa e gestisce le architetture di prodotto Aree tecniche: realizzano prodotti specifici per un segmento di mercato. Rappresentano la “fabbrica del software” Aree commerciali: focalizzate sulla distribuzione, assistenza post-vendita e sull’analisi delle esigenze dei clienti di un singolo segmento di mercato Logimax e Amax: lavorano su commessa per la personalizzazione di applicativi per grandi aziende

Il processo di sviluppo prodotto Definizione del concept di prodotto (area commerciale) dal 70% dello sviluèèp Analisi funzionale (area tecnica) Manuale d’uso (area tecnica e “terzisti”) Identificazione clienti pilota (area commerciale) Sviluppo software (area tecnica) Revisioni progetto (area tecnica e clienti pilota) Analisi dei requisiti. Il responsabile di prodotto di un’area individua il concept del prodotto. Analisi funzionali. Quali funzionalità deve avere il prodotto. A quali architetture si appoggia, quali nuovi moduli è necessario sviluppare. Individuazione clienti pilota, saranno quelli che aiuteranno meglio a definire il concept del prodotto e le funzionalità che esso deve avere. Verranno coinvolti nelle fase di testing del prodotto attraverso la distribuzione di versioni beta. A questo punto si pasa allo sviluppo vero e proprio del nuovo prodotto. Quando si è giunti al 70% parte la fase di redazione del manuale d’uso del nuovo sw. questa fase viene in larga parte esternalizzata a terzisti, collaboratori in partita iva o piccole sw house. TESTING  in questo caso la gestione della conoscenza interviene in modo rilevante. Un responsabile di test individu funzionamento di sw di fronte a casistiche standard legate a semplici transazioni registrate dal sistema informativo e a casistiche particolari individuate dalle indicazioni dei clienti. Un db mappa le casistiche e I problemi riscontrati a questo db accedono gli sviluppatori dell’area tecnica Test automatico (software ideato da Dylog) Test di prodotto (area commerciale) Lancio preliminare (area commerciale)

Processo di manutenzione evolutiva Ricezione della chiamata (Help-desk) Compilazione del database Verifica fattibilità degli interventi (Project Manager e responsabile tecnico) Realizzazione interventi programmati (Area tecnica) Test di prodotto (Area commerciale) Decisione priorità e pianificazione interventi (Responsabile prodotto e direttore commerciale) Revisione manuale d’uso (Area tecnica e consulenti esterni)

Livello di esplici-tazione Tasso obsolescenza Cono-scenza Natura Deriva-zione Dove viene capita-lizzata Livello di esplici-tazione Tasso obsolescenza Specifi-cità rispetto a mercato Architet-turale Definizione standard, algoritmi e architetture di prodotto Interna   Core tecnico Alto Basso Media Operativa Linguaggi Program-mazione, db, sistemi operativi Reperibile sul mercato Back-office Medio Bassa Tecnica modulare Sviluppo/aggiornamento codice Singole aree tecniche Alta Appli-cativa di mercato Legata a esigenze dei clienti e a caratteri-stiche del mercato Cliente Singole aree com-merciali Elevato Librerie di codici

Il modello di gestione della conoscenza La gestione della conoscenza fortemente legata alla progettazione organizzativa e di prodotto ancor prima che all’utilizzo di strumenti ICT (librerie di codice, applicativi per il testing di prodotto). Elevata specializzazione dei ruoli e management intermedio (responsabile tecnico, responsabile commerciale di prodotto, project managers) con aree di responsabilità sovrapposte. Limitata attenzione sulla valutazione delle performance degli strumenti di gestione della conoscenza; interesse rivolto a performance “aggregate” (tassi di abbandono dei clienti, nuovi clienti, crescita fatturato, etc.). Sforzo continuo ad “orientare” tutta l’azienda verso il cliente.

Punti di forza e limiti Presupposti culturali e organizzativi: Modello che ha senso adottare dove upgrades dei prodotti costituiscono notevole fonte di ricavi e di vantaggio competitivo Modello adatto solo ai mercati di nicchia (elevata “vicinanza” con il cliente) Punti di forza: Percorso di continua crescita basato sul riutilizzo della base di competenze posseduta. Approccio evolutivo al prodotto: attenzione al continuo sviluppo di conoscenza applicativa di mercato (diviene rapidamente obsoleta, difficile da trasferire, lenta da accumulare) Modello sostenibile per le PMI in generale: “coerenza” tra modello organizzativo, configurazione di prodotto e caratteristiche delle conoscenze utilizzate Limiti: Impossibilità di realizzare innovazioni radicali lungo la dimensione tecnica (es.: raggi X e videosorveglianza)