Progetto di gestione dei processi aziendali

Mappatura del processo di formulazione di un preventivo per una software house

Aiuto Salvatore Fabio Bianucci Federico Bont Irene

Progetto di gestione dei processi aziendali

Indice
INTRODUZIONE .............................................................................................................................. 3 Mission ............................................................................................................................................ 5 Vision ............................................................................................................................................... 6 PROCESSO: REALIZZAZIONE PREVENTIVO ........................................................................ 7 LIVELLO 0 .................................................................................................................................... 11 LIVELLO 1 .................................................................................................................................... 12 ESEMPIO DI PREVENTIVO ........................................................................................................ 16 PROBLEMI ...................................................................................................................................... 19 IMPUTAZIONE COSTI INDIRETTI ........................................................................................... 19 COSTI COMMERCIALI ............................................................................................................... 23 HIDDEN COSTS ........................................................................................................................... 25 MODIFICHE E VARIANTI .......................................................................................................... 28 CASI DI STUDIO ............................................................................................................................ 29 CASO DI STUDIO 1: Software per aeronavigazione............................................................... 29 Introduzione ............................................................................................................................... 29 Periodo iniziale .......................................................................................................................... 29 Offerta iniziale ........................................................................................................................... 30 Cambio di specifiche .................................................................................................................. 31 Problemi riscontrati nel progetto e soluzioni adottate ............................................................... 31 CASO DI STUDIO 2: Software per radar................................................................................. 33 Introduzione ............................................................................................................................... 33 Problemi riscontrati nel progetto e lezioni imparate .................................................................. 33 CASO DI STUDIO 3: Software/hardware in ambito biomedicale .......................................... 35 Introduzione ............................................................................................................................... 35 Problemi riscontrati nel progetto e lezioni imparate .................................................................. 35 CASO DI STUDIO 4: Software/hardware per infomobilit .................................................... 37 Introduzione ............................................................................................................................... 37 Problemi riscontrati nel progetto e lezioni imparate .................................................................. 37 Mappatura del processo AS IS ................................................................................................... 39 Mappatura del processo TO BE ................................................................................................. 42 CASO DI STUDIO 5: Firmware per hardware del cliente ...................................................... 44 Introduzione ............................................................................................................................... 44 Problemi riscontrati nel progetto e lezioni imparate .................................................................. 44

Progetto di gestione dei processi aziendali

Indice delle Figure

Figura 1 - Costo annuo di uno sviluppatore ......................................................................................... 8 Figura 2 - Numero ore di sviluppo di una persona in un anno............................................................. 9 Figura 3 - Costo orario a persona ....................................................................................................... 10 Figura 4 - Esempio di listino .............................................................................................................. 10 Figura 5 - Livello 0 ............................................................................................................................ 11 Figura 6 - Livello 1 ............................................................................................................................ 12 Figura 7 - Livello 2: calcolo giorni/uomo .......................................................................................... 14 Figura 8 - Livello 2: Decisione prezzo orario .................................................................................... 15 Figura 9 - Esempio di preventivo ....................................................................................................... 18 Figura 10 - Mappatura processo AS IS (1 di 3) ................................................................................. 39 Figura 11 - Mappatura processo AS IS (2 di 3) ................................................................................. 40 Figura 12 - Mappatura processo AS IS (3 di 3) ................................................................................. 41 Figura 13 - Mappatura processo TO BE (1 di 2) ............................................................................... 42 Figura 14 - Mappatura processo TO BE (2 di 2) ............................................................................... 43

Progetto di gestione dei processi aziendali INTRODUZIONE

Lo scopo del presente documento quello di illustrare i risultati dello studio svolto presso la Evidence s.r.l, software house di Pisa con allincirca venti sviluppatori, che si occupa principalmente di implementare software real-time. In particolar modo, il nostro obiettivo analizzare e mappare la realizzazione del preventivo che svolge lazienda in questione. L'analisi e l'attivit svolta sul campo sono state seguite dalla rielaborazione dei dati raccolti da parte dei membri del gruppo di lavoro, al fine di produrre una relazione organica contenente anche i diagrammi di flusso dei processi aziendali. I diagrammi di flusso sono stati inseriti nel presente documento con due diverse notazioni, in particolare si scelto di inserire anche una mappa dei processi realizzata utilizzando il linguaggio di modellazione IDEF0, oltre alle mappe realizzate con la notazione classica attraverso luso di ARIS Business Architect for SAP. Il presente documento contiene anche proposte per il miglioramento dei processi dell'azienda; in particolare si sono analizzati dei casi di studio relativi a progetti precedentemente sviluppati e che hanno creato difficolt e perdite economiche allazienda. Per ogni caso di studio si mappato lo stato attuale (AS IS) dei sottoprocessi critici e formalizzato con una mappatura TO BE il miglioramento possibile per quel determinato caso di studio.
3

Progetto di gestione dei processi aziendali

AZIENDA

Evidence: un'azienda informatica che opera nel settore del software per sistemi embedded realtime. Si trova in localit Ghezzano - La Fontina Via Carducci, 56, 56010 San Giuliano Terme.

Progetto di gestione dei processi aziendali

Estata fondata alla fine del 2002 come spin-off del Laboratorio Retis della Scuola Superiore Sant'Anna (Pisa, Italia) da un gruppo di ricercatori esperti in analisi della programmazione in tempo reale, sistemi operativi, sistemi di controllo, e tecniche di programmazione multiprocessore. Oggi, Evidence una societ dinamica con collaborazioni nel campo dell'elettronica, delle telecomunicazioni, dellautomotive, dellautomazione industriale e dei mercati, come ad esempio Altera Corporation, Ericsson Lab Italia, Navionics. Mission Fornisce soluzioni software innovative per la progettazione e lo sviluppo di sistemi embedded real-time, con un focus particolare sulle piattaforme hardware multi-core.

Progetto di gestione dei processi aziendali

Vision Lorigine universitaria spinge lazienda ad una continua ricerca di nuovi sviluppi tecnologici in modo che possa fornire ai clienti soluzioni software avanzate per le loro esigenze presenti e future.

Operating Systems and Code Generators

Minimal Embedded Automatic code RTOS, with configuration generator for control and schedulability systems analysis tool

Embedded Linux and Linux real-time products and services

Progetto di gestione dei processi aziendali PROCESSO: REALIZZAZIONE PREVENTIVO

Come per tutte le software house, la stesura di un preventivo un processo critico, in quanto non facile riuscire a priori a prevedere tempi e costi che saranno necessari durante il lavoro. Quando si realizza un software, molto del lavoro da svolgere caratterizzato da una forte soggettivit da parte di chi lo sviluppa e dalle sue capacit informatiche; sono inoltre necessarie attivit di coordinamento tra i membri di un team e unaccurata progettazione che riduca il pi possibile i potenziali imprevisti che possono verificarsi. Evidence realizza progetti complessi per cui facile che durante la stesura del preventivo vengano trascurati aspetti che in seguito incideranno notevolmente sul costo iniziale pattuito. Il compito nostro sar di revisionare insieme allazienda lattuale iter di preventivo; su tale procedimento dovremo evidenziare possibili difetti e lacune che portano lazienda ad avere uno scostamento sensibile tra ci che pensavano fosse il costo del prodotto software e ci che in realt il costo effettivo per realizzarlo. La base fondamentale da cui partire per poi approfondire il processo del preventivo senza dubbio quella di stabilire il costo della risorsa umana, ovvero quanto costa allazienda uno sviluppatore. Su di una risorsa umana incidono costi diretti di produzione, cio costi direttamente imputabili allo sviluppatore, e costi indiretti, cio non direttamente imputabili a colui che programma, ma che incidono indirettamente sul suo lavoro. I costi diretti (su base annua) individuati sono: sommatoria degli stipendi
7

Progetto di gestione dei processi aziendali mensili, TFR (trattamento di fine rapporto), tredicesima mensilit e tasse varie. Tra i costi indiretti pi significativi ci sono spese di affitto dei locali dellazienda, spese di tasse quindi luce, acqua, gas, spese per acquistare i terminali e spese per le attivit degli amministrativi, che sono necessarie per lazienda ma che, ovviamente, ricadono sui costi indiretti perch non strettamente legate alle attivit di sviluppo software. I costi indiretti, non essendo direttamente imputabili ad una singola risorsa, vanno divisi per il numero totale di sviluppatori, in modo da avere lincidenza media dei costi indiretti sulla singola persona. Sommando dunque costi diretti e indiretti su base annua relativi ad una risorsa umana otteniamo il costo annuale che ha lazienda per mantenere alle proprie dipendenze uno sviluppatore.

Figura 1 - Costo annuo di uno sviluppatore

Progetto di gestione dei processi aziendali

Ma quanto costa allazienda ogni singola ora di lavoro di uno sviluppatore? E facile capire che tale parametro di fondamentale importanza perch in base al tempo complessivo che sar necessario per svolgere il software si pu avere unidea di quello che sar il costo totale del prodotto.

Figura 2 - Numero ore di sviluppo di una persona in un anno

Progetto di gestione dei processi aziendali Si divide quindi il costo annuale della risorsa per il numero di ore di lavoro annuali.

Figura 3 - Costo orario a persona

Una volta fatto il calcolo del costo orario di una risorsa umana, lazienda Evidence tiene un listino non pubblico come riferimento, nel quale i costi variano a seconda della difficolt del progetto e del tempo che occorre per svilupparlo.

Figura 4 - Esempio di listino

10

Progetto di gestione dei processi aziendali

I prezzi sono gonfiati, ovvero includono un margine di guadagno rispetto alleffettivo costo orario di una risorsa. Ma come viene realizzato il preventivo?

LIVELLO 0

Figura 5 - Livello 0

11

Progetto di gestione dei processi aziendali LIVELLO 1

Figura 6 - Livello 1

Premettendo che il tutto viene svolto in maniera approssimativa e sulla base della semplice esperienza personale di chi interagisce con in cliente, Evidence segue un procedimento classico che presenta alcune lacune che approfondiremo. Partendo da quelle che sono le specifiche del progetto e dalla data di consegna che il cliente impone, inizia una fase in cui viene stimato in termini di mesi/uomo il tempo necessario per svolgere il progetto. Per evitare di non riuscire a consegnare il prodotto in tempo, Evidence stabilisce un cosiddetto margine temporale ovvero progetta le proprie attivit come se dovesse consegnare il
12

Progetto di gestione dei processi aziendali prodotto in un tempo inferiore a quanto stabilito con il cliente. Nella realizzazione di un prodotto software, utilizzare un margine temporale un meccanismo intelligente in quanto tipicamente lo sviluppo di un software un processo condizionato da una forte imprevedibilit che pu causare dei ritardi rispetto ai tempi previsti per realizzarlo. Lazienda realizza i propri lavori attraverso la definizione di un team dedicato esclusivamente allo sviluppo di quel progetto. Viene nominato un project manager cio colui responsabile di seguire levoluzione dello sviluppo. Il project manager stima quanti mesi/uomo sono necessari, ovvero individua approssimativamente quanto tempo impiegherebbe una singola persona a svolgere interamente ci che stato commissionato. Sulla base di tale stima e considerando il tempo che ha a disposizione lazienda per completare il lavoro, il project manager decide quante persone faranno parte del team che realizza il progetto, in modo tale che il lavoro stimato per una singola persona venga diviso tra i membri del team e si riesca cos a rispettare la data di consegna al cliente. Nasce cos un team di persone con a capo il project manager. I membri del team vengono scelti sulla base della disponibilit, dellesperienza e delle competenze per lo specifico lavoro che andranno a svolgere. Vincolo da tenere in considerazione la tabella del carco di lavoro di uno sviluppatore. Senza tale vincolo il project manager pu commettere lerrore di scegliere sviluppatori gi impegnati in altri progetti. A questo punto il team si riunisce ed insieme stabiliscono quali saranno tutte le attivit che si dovranno fare e verranno stimati
13

Progetto di gestione dei processi aziendali quanti giorni/uomo sono necessari per completare ciascuna attivit. Questa fase fondamentale: non bisogna tralasciare nessuna attivit pi o meno significativa, in quanto una dimenticanza incide notevolmente sulla stima finale dei giorni/uomo che effettivamente servono per sviluppare il progetto. Sommando i tempi di esecuzione di ogni attivit si ottiene un valore che va confrontato con quello che il project manager aveva previsto inizialmente e tramite il quale aveva stabilito il numero dei membri del team. Se il valore ottenuto per lappunto sensibilmente diverso vuol dire che il project manager aveva sbagliato la sua stima, per cui sar necessario aggiungere o togliere membri dal team.

Figura 7 Livello 2: calcolo giorni/uomo

14

Progetto di gestione dei processi aziendali

A questo punto bisogna stabilire con esattezza quanto costa al cliente unora di sviluppo del progetto commissionato. Per fare ci si prendono in considerazione due parametri: - La durata del progetto: Ricavata dalla data di consegna - La difficolt del progetto: Valutata dal project manager responsabile del progetto

Figura 8 - Livello 2: Decisione prezzo orario

A questo punto, con i parametri durata e difficolt si sfrutta il listino prezzi per avere unidea di quanto coster al cliente unora di sviluppo del suo progetto. Bisogna precisare che le cifre del listino non sono rigide e vincolanti, sono solo un documento che lazienda utilizza per avere un riferimento rispetto a progetti con caratteristiche simili svolti in passato.
15

Progetto di gestione dei processi aziendali

ESEMPIO DI PREVENTIVO

Illustriamo qui un esempio di calcolo di preventivo discusso direttamente in azienda. Il progetto riguarda lo sviluppo di un software per un simulatore di volo. Il cliente fornisce le specifiche. Si decide di partire il 1 Luglio. e Il project manager valuta, in base al tipo di lavoro da fare, il tempo di sviluppo nel quale svolgere tutte le attivit necessarie. In questo caso, chi commissiona il progetto non ha imposto un tempo massimo di sviluppo per cui lazienda stima di completare il lavoro in un tempo inferiore a quanto realmente ci vorrebbe per realizzarlo, ovvero prevedendo un margine temporale in modo da avere dei giorni necessari per gestire eventuali imprevisti. Si decide dunque che la consegna del progetto fissata per il 1 Novembre, dunque durata lavori: 4 mesi. Un project manager, dunque, decide in maniera del tutto soggettiva che la stima iniziale per terminare il progetto di 12 mesi/uomo cio una persona impiegherebbe 12 mesi per sviluppare tutto il progetto. Per attenersi ai tempi di consegna che ci si prefissati ovvero ai 4mesi di tempo, si forma quindi un team composto di 3 persone. Dopo un mese di lavoro si fa una verifica per valutare se i tempi prefissati si stanno rispettando o se pi utile inserire altre persone per riuscire a rispettare la data di consegna. Si scelgono 3 persone
16

Progetto di gestione dei processi aziendali in base alla disponibilit e, possibilmente, in base allesperienza. Il team sar quindi formato dalle 3 persone pi il project manager. Il team si riunisce per stilare la lista delle attivit. Per ogni attivit il team specifica il tempo di esecuzione (vengono incluse anche riunioni, consegne, telefonate, acquisto di licenze,ecc.).

Esempio lista delle attivit: Stesura dellofferta formale per il cliente (1g x 3) Meeting kick-off assieme al cliente (1g x 3) Meeting intermedi assieme al cliente una volta al mese (1g x 3 x 3) Acquisto server per lo sviluppo e installazione SO (1g) Design protocollo comunicazione (10g) Implementazione protocollo comunicazione (5g) Design interfaccia grafica (5g) Implementazione interfaccia grafica (10g) Salvataggio su file della configurazione (3g) Training al cliente (2g x 1)

I giorni/uomo di ogni attivit sono stimati solamente a scopo esemplificativo.

17

Progetto di gestione dei processi aziendali

Si ottiene un totale di 51giorni/uomo necessari. A questo punto in base al listino, che include il margine di guadagno, si ottiene:

Figura 9 - Esempio di preventivo

18

Progetto di gestione dei processi aziendali PROBLEMI IMPUTAZIONE COSTI INDIRETTI

Lazienda imputa i costi indiretti sulle persone, ovvero considera tali costi uniformemente divisibili tra gli sviluppatori come se la loro incidenza avvenga in maniera omogenea tra tutti. Questa valutazione non tiene conto dei seguenti aspetti:

- Differenza di produttivit tra le persone: normale pensare che ogni persona ha delle capacit diverse dagli altri e per ci ha una diversa produttivit. Colui che particolarmente bravo svolge un determinato compito in un tempo minore ad un collega meno bravo, che impiegher molto pi tempo e quindi indirettamente consumer pi luce o altro. Quello pi bravo maggiormente produttivo e pu utilizzare il tempo risparmiato per altre mansioni utili allazienda. Lazienda non pu trascurare la loro differenza di produttivit perch i costi indiretti non incidono in eguale modo tra due soggetti con diverse capacit produttive.

- Carico di lavoro: da una base di imputazione costituita dalle persone in senso quantitativo, bisognerebbe valutare il corrispettivo carico di lavoro di ogni sviluppatore. Quando si decide quanto debbano incidere i costi indiretti su di una
19

Progetto di gestione dei processi aziendali persona, bisognerebbe prima verificare il suo effettivo orario di lavoro. Uno sviluppatore con un orario intenso e ricco di impegni dovr avere un peso maggiore nella valutazione di chi influisce sul totale dei costi indiretti, perch la sua incidenza maggiore rispetto a chi lavora di meno. Il tutto sintetizzabile dalla logica: chi pi lavora pi consuma.

- Premialit: altro aspetto che viene trascurato dallattuale imputazione dei costi indiretti la premialit. Se tutti gli sviluppatori sono valutati allo stesso modo, ovvero tutti sono responsabili della medesima porzione di incidenza sui costi indiretti, senza evidenziare alcuna differenza tra loro, allora inevitabile che non venga innescato alcun meccanismo di incentivo. Lincentivo finalizzato a produrre pi celermente in modo che ogni dipendente abbia lobiettivo personale di fare velocemente la sua parte, affinch si riduca il totale dei costi indiretti. A lungo andare nel tempo chi pi bravo non gradisce che tutti vengano valutati allo stesso modo ma pretende che gli venga riconosciuto di essere utile allazienda anche sotto laspetto della spesa economica. Nel momento in cui si riesca ad alimentare una sorta di gara, allora ciascun sviluppatore si impone lobiettivo di essere pi bravo degli altri in modo tale da essere premiato dallazienda. Sarebbe pi corretto avere un parametro pi oggettivo, che faccia incidere i costi indiretti pi su uno sviluppatore piuttosto che su un altro. Sarebbe corretto avere un sistema di
20

Progetto di gestione dei processi aziendali gestione che possa discriminare i vari casi in modo da non mettere sullo stesso piano due sviluppatori con capacit produttive diverse e con orari di lavoro diversi. Attenzione per: bisogna inoltre valutare che ogni sviluppatore ha un impegno diverso a seconda della commessa. Un numero di ore elevato su di un determinato progetto incide in maniera differente sui costi indiretti rispetto ad un impegno inferiore in un altro progetto. importante, dunque, discriminare i costi indiretti in base allo sforzo della persona nel singolo progetto e non avere, invece, un parametro che sintetizzi una media tra le ore impiegate da uno sviluppatore in commesse diverse. Se il parametro di imputazione dei costi indiretti fosse ad esempio il numero di ore di lavoro che ciascun sviluppatore impiega effettivamente in quel progetto allora, in fase di preventivo, sarebbe pi facile riuscire ad avere una stima pi accurata del costo indiretto del progetto. La nostra proposta stata quindi di riuscire ad avere un sistema di conteggio delle ore di lavoro di ogni persona in un determinato progetto. Si potrebbe quindi utilizzare un time sheet personale per ogni sviluppatore, che si impegna a registrare e tenere aggiornato il totale delle ore effettivamente trascorse sul progetto. Infine, attraverso i time sheet aggiornati, si deve dividere il totale dei costi indiretti per il totale di ore che il progetto ha impiegato. Cos facendo i membri del team di quel progetto sono consapevoli che ogni singola ora del loro lavoro incide sul costo finale del progetto.

21

Progetto di gestione dei processi aziendali Con lattuale base di imputazione, lazienda perde di vista leffettivo peso che ha uno specifico progetto nelleconomia complessiva dellazienda. Lazienda non si rende conto di quanto possa avere inciso un progetto sui costi indiretti e quindi pu cadere nel tranello di valutare in maniera ottimistica il margine economico di una commessa in quanto i costi indiretti sono nascosti e non identificati. Quindi, il guadagno finale potrebbe essere inferiore a quanto si potesse pensare. Se Evidence adottasse il sistema da noi proposto riuscirebbe ad avere una visione pi chiara di quanto il progetto realizzato ha inciso sui costi indiretti dellazienda e in questo modo avrebbe la possibilit di giostrare meglio il suo margine economico. I time sheet, che tengono memoria delle ore trascorse sul progetto, sono in realt utilizzati dallazienda ma ad essi non viene data sufficiente importanza perch ogni risorsa umana tende a riportare sul personale time sheet di aver lavorato il massimo delle ore possibili per una giornata. E evidente che il problema non il sistema di gestione bens la mancanza di controlli su di esso. La nostra idea proposta all Evidence di riuscire periodicamente ad effettuare delle procedure di review che consentano di intervistare il project manager per sapere se i membri del team hanno realmente lavorato per le ore che hanno registrato sul time sheet.

22

Progetto di gestione dei processi aziendali COSTI COMMERCIALI

Tra le varie attivit che vengono stimate e che vanno a formare il preventivo, lazienda trascura le attivit commerciali, ovvero le normali iniziative commerciali che vengono svolte per accaparrasi i clienti, andare a parlare con loro, curare i vari rapporti relativi alle vendite o gli aspetti commerciali con i fornitori, ma anche per promuovere liniziativa nel suo complesso e per promuovere i servizi nei confronti dei vari target. Il tempo utilizzato per queste attivit fondamentale e non va trascurato. In genere le software house tendono a trascurare questo aspetto perch si concentrano esclusivamente sulle attivit legate direttamente allo sviluppo del software, tralasciando attivit di contorno di uguale importanza e che sono necessarie per poi procedere nella stesura del preventivo. Evidence ci ha confessato che vi una profonda incertezza nella quotazione di tali costi commerciali, giustificandosi dicendo che ad occuparsene non un membro del team bens un responsabile dellazienda. Tale giustificazione non plausibile, innanzitutto perch le attivit commerciali sono costi a tutti gli effetti che lazienda sostiene e che, quindi, vanno pattuiti col cliente e messi nel preventivo; inoltre, il tempo di un responsabile ancor pi prezioso di un qualunque sviluppatore, perch il responsabile potrebbe sfruttare il proprio tempo per svolgere altri lavori, dunque, a maggior ragione, i costi sostenuti a scopo commerciale vanno decisamente considerati. Se tali costi non sono ben identificati, lazienda ne tiene in considerazione solo nella valutazione del margine economico. Con quali conseguenze??
23

Progetto di gestione dei processi aziendali La prima conseguenza che allora tale margine non profitto, ma nasconde costi che lazienda non ha ben quantificato. Questo meccanismo d origine ad una distorsione del calcolo della redditivit, da cui consegue una valutazione economica diversa dalla realt. Seconda conseguenza che tale meccanismo non professionalizza laspetto commerciale del progetto, ma viene trascurato e valutato in maniera approssimativa, come se non incidesse sulleconomia del progetto.

24

Progetto di gestione dei processi aziendali HIDDEN COSTS

Con hidden costs indichiamo i costi della non qualit, cio costi che rappresentano la differenza tra i costi di un prodotto/servizio e i costi dello stesso prodotto/servizio se non ci fosse alcuna possibilit di errore nellapprontarli. Uno dei principali obiettivi dell'ingegneria della qualit la riduzione dei costi del prodotto (prevenzione degli errori, minore necessit di assistenza). L'analisi dei costi deve essere un elemento fondamentale del controllo di qualit. Il Costo della Qualit il costo legato alla prevenzione, ricerca e correzione dei difetti. Tale costo pu essere significativamente ridotto: una delle funzioni chiave della qualit consiste nella riduzione del costo totale della qualit associato ad un prodotto.

Vediamo pi in dettaglio come i costi della qualit possono essere classificati: costo della prevenzione: riguarda le attivit finalizzate alla prevenzione dei difetti (quali errori di progettazione, di codifica, nella manualistica, nella documentazione), lo sviluppo di prototipi, la chiarezza nelle specifiche, l'accuratezza della documentazione, la valutazione degli strumenti di sviluppo.

25

Progetto di gestione dei processi aziendali costo della valutazione: riguarda le attivit di ricerca dei problemi (test e ispezione del codice), revisioni del progetto, la formazione degli addetti al test. costo interno degli errori: riguarda la correzione degli errori, il ritardo nei progetti, la ripetizione dei test, la rischedulazione delle attivit. costo esterno degli errori: riguarda il tempo degli operatori al servizio assistenza, la rispedizione del prodotto, il costo di gestione di release multiple, vendite perse, fiducia del cliente persa, costi in garanzia, penali, etc.

La "non-qualit" implica s la sostituzione del materiale difettoso, la pratica degli sconti, ecc., ma significa sempre riduzione dell'immagine professionale, con conseguenze negative sulle vendite. Un sistema di controllo dei costi relativi alla qualit deve essere considerato un fondamentale strumento di gestione. Tutte le attivit che vengono stimate per realizzare il preventivo devono essere esaustive e non tralasciare alcun aspetto che pu incidere sulla qualit del prodotto software e di conseguenza sul prezzo finale. Tutti gli imprevisti che si verificano in fase di sviluppo creano uno scostamento tra il valore stimato in preventivo e leffettivo costo del progetto. In poche parole bisognerebbe riuscire a prevedere gli imprevisti in modo da prevenire spese aggiuntive non considerate a priori. Abbiamo chiesto (senza esito postivo) allazienda Evidence di analizzare un progetto che hanno precedentemente svolto in modo
26

Progetto di gestione dei processi aziendali da intervistare gli attori protagonisti dello sviluppo, al fine di verificare se le attivit realmente effettuate dagli sviluppatori fossero tutte ex-ante stimate dal team in fase di preventivo. Lidea era quella di creare una check-list con possibili attivit del team in quella specifica commessa e chiedere ad ogni sviluppatore quali difficolt o situazioni anomale gli si fossero presentate e se avessero causato un rallentamento o un cambiamento di programmi rispetto a quanto prefissato. Una raccolta di queste informazioni pu essere utile allazienda per mettere in atto un sistema di gestione che metta il Project Manager in allerta con dei warning qualora il team proceda in una direzione diversa dalla rotta che si deciso di seguire fin dallinizio.

27

Progetto di gestione dei processi aziendali MODIFICHE E VARIANTI

Come vengono gestiti eventuali modifiche o varianti al progetto? E ovvio che, qualora nasca lesigenza di una qualche modifica alle specifiche del cliente, necessario disporre di un sistema di controllo varianti per non indebolire la trattativa col cliente. Con i clienti si pattuisce un prezzo per svolgere determinate attivit, ma pu accadere che in fase di sviluppo nascano situazioni che portano ad una revisione del progetto, con conseguenti modifiche inevitabili. Se tali modifiche implicano una variazione sostanziale di prezzo rispetto al preventivo, pertanto necessario chiedere al cliente un meeting per decidere il da farsi. Evidence, ogni qualvolta si presenta una simile situazione convoca il cliente, discute insieme a lui delle modifiche da apportare, propone una variazione di prezzo necessaria per le nuove attivit da fare ed, infine, chiede al cliente lautorizzazione a procedere.

28

Progetto di gestione dei processi aziendali

CASI DI STUDIO

CASO DI STUDIO 1: Software per aeronavigazione

Introduzione Viene commissionato alla nostra azienda lo sviluppo di un software client-server per aeronavigazione civile. L'azienda che lo commissiona lavora per conto di una terza azienda, che il cliente finale del prodotto. Tuttavia, alla nostra azienda viene preclusa la visibilit del cliente finale.

Periodo iniziale L'azienda che ci commissiona il lavoro propone un breve periodo iniziale "di ambientamento" per i dipendenti che dovranno fare lo sviluppo, in modo che possano avere un'idea della complessit del lavoro da svolgere e fare un'offerta economica a corpo. Il periodo di ambientamento si dimostra completamente inutile: in tale periodo gli sviluppatori non possono che prendere atto della completa mancanza di specifiche del progetto. La stesura delle specifiche, inoltre, stata commissionata ad una quarta azienda esterna invece di essere commissionata a chi dovr sviluppare il software.

29

Progetto di gestione dei processi aziendali

Offerta iniziale Al termine del periodo "di ambientamento", la nostra azienda fornisce un'offerta economica che preveda anche un raffinamento iniziale delle specifiche mancanti, ed un chiarimento delle interfacce del sistema. Tale offerta economica viene accettata. Il cliente, tuttavia, chiede che lo sviluppo venga portato avanti presso la propria sede, in modo da poter dare un feedback agli sviluppatori. Dopo poco tempo, ci si accorge che gli sviluppatori presso il cliente stanno seguendo nuove direttive impartite dal cliente piuttosto che seguire la scaletta stabilita nell'offerta economica. Il lavoro viene perci sospeso e viene organizzato un meeting di chiarimento, nel quale si concorda il pagamento del tempo trascorso dagli sviluppatori presso il cliente e la presentazione di una nuova offerta economica che prenda in maggiore considerazione i bisogni del cliente (che inizialmente ci erano stati tenuti nascosti). Questa volta si stabilisce che il lavoro venga portato avanti presso la nostra sede, in modo da evitare che il cliente cerchi di prendere in mano la gestione del progetto.

30

Progetto di gestione dei processi aziendali Cambio di specifiche Durante lo sviluppo, ci si accorge che il cliente non ha le idee chiare riguardo le specifiche del progetto, e spesso "tira a indovinare" quello che il cliente finale vuole. Inoltre, anche il cliente finale non ha un'idea chiara. Di conseguenza, le specifiche cambiano di settimana in settimana. Altre volte, quando interpellato riguardo alcuni chiarimenti, il cliente risponde che non sa ancora come vadano sviluppati. Come soluzione, la nostra azienda decide di procedere formalmente, mettendo "nero su bianco" ogni cosa stabilita durante gli incontri, in modo da trattare con offerte economiche separate ogni cambio a quanto stabilito nel periodo passato.

Problemi riscontrati nel progetto e soluzioni adottate 1. Mancanza di visibilit del cliente finale. La soluzione stata quella di considerare il nostro cliente come il cliente finale, delegando a lui il potere decisionale riguardo i requisiti. Ogni scelta fatta dal nostro cliente viene scritta all'interno di documenti formali ed ha lo stesso valore di una specifica di progetto. 2. Tentativo di gestire il progetto da parte del cliente. La soluzione stata quella di portare lo sviluppo presso la nostra sede, organizzando meeting periodici presso il cliente per mostrare l'evoluzione del progetto e per rilasciare il codice sviluppato fino a quel momento. Indicativamente, lo sviluppo deve sempre essere svolto presso la nostra sede e sotto la nostra guida a meno che non si tratti di attivit di
31

Progetto di gestione dei processi aziendali "body rental". Tra le condizioni generali dell'offerta economica viene riportata la seguente condizione: "Ove possibile, le attivit di sviluppo e documentazione verranno svolte presso la nostra sede". 3. Cambio continuo di specifiche. La soluzione stata quella di considerare all'interno dell'offerta un periodo di raffinamento dei requisiti. Ogni scelta successiva viene scritta all'interno di documenti formali ed ha lo stesso valore di una specifica di progetto. Ad ogni cambiamento delle specifiche, viene fornita al cliente un'ulteriore offerta economica che comprenda soltanto lo sviluppo di quanto richiesto dalle nuove specifiche di progetto. Il cliente libero di accettare la nuova offerta oppure di non accettarla (nel qual caso il software rispetter la vecchia specifica). Tra le condizioni generali dell'offerta economica viene riportata le seguenti clausole: a. In caso di impossibilit a proseguire il lavoro a causa di mancanza di informazioni o di disponibilit agli incontri da parte del cliente, la nostra azienda si riterr libera di allocare i propri consulenti su altri progetti di breve durata. Questo potr comportare un ritardo di durata non predicibile nella consegna, del quale la nostra azienda non si riterr responsabile. b. Eventuali richieste di modifica delle attivit da svolgere rispetto a quanto concordato saranno oggetto di contrattazione separata.

32

Progetto di gestione dei processi aziendali CASO DI STUDIO 2: Software per radar

Introduzione Viene commissionato alla nostra azienda lo sviluppo del firmware per un sistema embedded. La piattaforma hardware viene stabilita dal cliente. L'offerta economica viene curata senza considerare tutti i fattori legati allo sviluppo su un sistema embedded.

Problemi riscontrati nel progetto e lezioni imparate 1. Piattaforma hardware sulla quale non avevamo mai lavorato. Non bisogna sottovalutare il tempo di start-up relativo a lavorare su hardware sul quale non abbiamo mai lavorato prima. Il tempo necessario a prendere confidenza con l'hardware pu arrivare anche a 2 mesi/uomo. E' necessario considerare questo tempo nel break-down delle attivit fatto in fase di offerta. 2. Difficolt legate alla poca memoria disponibile. Questo ha richiesto di implementare gli algoritmi in maniera diversa. L'analisi iniziale prima dell'offerta economica deve comprendere un'analisi dei rischi legati al fatto di lavorare su hardware embedded. E' buona norma fare un brainstorming per cercare di elencare questi rischi e di valutarli in termini di tempo. 3. Problemi hardware legati alla board di sviluppo utilizzata. Si sono verificati problemi con l'interfaccia di rete non
33

Progetto di gestione dei processi aziendali funzionante. Anche in questo caso, resta valido quanto detto al punto precedente. Inoltre, importante riuscire a contattare il FAE (Field Application Engineer) dell'hardware che si sta utilizzando. Per accelerare la risoluzione del problema, bene indagare se qualche azienda all'interno della propria rete di conoscenze abbia un contatto diretto con l'azienda produttrice dell'hardware difettoso. Nel nostro caso, il dispositivo non funzionante era fornito non dalla casa madre ma da una azienda terza, che non ha saputo proporre soluzione ai nostri problemi. 4. Gestione del progetto. La gestione di ogni progetto richiede un check periodico (meglio se giornaliero) e la presenza puntuale di un Project Manager che controlli l'evoluzione del progetto e segnali al cliente ogni eventuale problema riscontrato. In questo progetto, la gestione stata affidata ad un socio della nostra azienda, sopravvalutando la sua disponibilit in termini di tempo. Questo ha comportato che il progetto andasse alla deriva per diversi mesi senza un controllo su cosa stesse succedendo.

34

Progetto di gestione dei processi aziendali CASO DI STUDIO 3: Software/hardware in ambito biomedicale

Introduzione Un'azienda ci commissiona lo sviluppo del firmware per un apparecchio in ambito biomedicale. Noi siamo responsabili della fornitura sia dell'hardware che del software.

Problemi riscontrati nel progetto e lezioni imparate Mancando delle specifiche chiare, abbiamo organizzato meeting periodici con il cliente mostrando l'evoluzione del progetto per avere un feedback. Fin dall'inizio il progetto stato seguito da un dipendente del cliente, che ha sempre dato responso positivo a quanto mostrato. La realt che il dispositivo era un remake di uno gi esistente, ma la persona incaricata non era a conoscenza di come tale dispositivo doveva funzionare. Una volta terminato il software, abbiamo fatto la consegna ufficiale. Per la prima volta ha partecipato il cliente, il quale ha detto che il sistema era diverso da quanto atteso, e che il software andava re-implementato da capo, altrimenti non avrebbe pagato lo sviluppo.

35

Progetto di gestione dei processi aziendali La lezione imparata stata quella di aggiungere tra le condizioni generali dell'offerta economica le seguenti clausole: 1. Qualora, nonostante il prodotto risulti conforme a quanto concordato, il compenso pattuito non venga corrisposto dal cliente secondo le modalit e gli importi stabiliti, la nostra azienda avr automaticamente ogni diritto sulle parti realizzate e non adeguatamente corrisposte. 2. Il cliente si impegna ad indicare al momento dell'ordine il nominativo del suo referente che avr il compito di: a. seguire l'evoluzione del progetto; b. fornire indicazioni riguardo il comportamento atteso dal sistema; c. verificare la conformit con le specifiche del progetto; d. segnalare tempestivamente l'eventuale mancanza di conformit con le specifiche. 3. In particolare, il referente del cliente dovr: a. essere esperto del dominio applicativo; b. essere disponibile ogniqualvolta la nostra azienda abbia necessit di chiarimenti o feedback riguardo la propria attivit; c. avere capacit decisionale.

36

Progetto di gestione dei processi aziendali CASO DI STUDIO 4: Software/hardware per infomobilit

Introduzione Un'azienda ci commissiona lo sviluppo di una soluzione hardware/software con sensori per la risoluzione di problemi legati alla logistica del traffico. Presentiamo un'offerta unica che comprenda anche lo sviluppo dell'hardware, per il quale ci affidiamo al nostro fornitore di fiducia mediante accordi verbali.

Problemi riscontrati nel progetto e lezioni imparate A ridosso di una milestone, il fornitore ci fornisce il prototipo hardware con appena 2 giorni di anticipo rispetto alla scadenza per la consegna. Nei 2 giorni successivi, non si riesce a far funzionare il sistema. Si scopre poi che la parte in Radio-Frequenza sull'hardware, molto complessa, non funziona. Per una milestone successiva, il fornitore decide di cambiare completamente l'hardware senza concordare il cambiamento con la nostra azienda. Questo ci obbliga a modificare il firmware allungando i tempi di consegna. La lezione imparata consiste nell'avere sempre accordi formali e per iscritto anche con i fornitori/clienti di fiducia, in modo da evitare ogni possibile equivoco e incomprensione durante il lavoro. Gli accordi devono prevedere una specifica chiara di ci che verr fornito ed i tempi massimi di consegna.
37

Progetto di gestione dei processi aziendali Inoltre, i ritardi nella consegna hanno fatto si che il cliente perdesse alcune opportunit di business, per cui, per cercare nuovi sbocchi, abbiamo dovuto subire cambi di specifiche non detti in modo chiaro. Di fatto il cliente non ha competenze tecniche specifiche, per cui era difficile per il cliente capire che cosa fosse possibile fare e cosa non fosse possibile fare. Infine, il cliente ha dovuto per forza di cose interagire con il progettista hardware, che con il tempo ha guadagnato la simpatia del cliente, facendo risultare agli occhi del cliente molti dei problemi del sistema come causati unicamente dallo sviluppo software, mettendoci pertanto in difficolt.

38

Progetto di gestione dei processi aziendali Mappatura del processo AS IS

Figura 10 - Mappatura processo AS IS (1 di 3)

39

Progetto di gestione dei processi aziendali

Figura 11 - Mappatura processo AS IS (2 di 3)

40

Progetto di gestione dei processi aziendali

Figura 12 - Mappatura processo AS IS (3 di 3)

41

Progetto di gestione dei processi aziendali Mappatura del processo TO BE

Figura 13 - Mappatura processo TO BE (1 di 2)

42

Progetto di gestione dei processi aziendali

Figura 14 - Mappatura processo TO BE (2 di 2)

43

Progetto di gestione dei processi aziendali CASO DI STUDIO 5: Firmware per hardware del cliente Introduzione Un cliente ci commissiona lo sviluppo del firmware per il prototipo di una nuova board che ha appena sviluppato.

Problemi riscontrati nel progetto e lezioni imparate Durante lo sviluppo, sorgono diversi problemi. Inizialmente non si capisce se i problemi siano computabili all'hardware o al software. Dopo diversi giorni di indagini, si scopre che il problema era hardware, e precisamente nelle resistenze usate nei terminatori del bus di memoria. La lezione imparata stata quella di aggiungere tra le condizioni generali dell'offerta economica le seguenti clausole: 1. Il cliente fornir alla nostra azienda tutte le informazioni, i documenti e 2 piattaforme hardware per tutta la durata della fornitura e per i 3 me si successivi alla data di rilascio della fornitura (in modo da poter dare opportuna consulenza tecnica). 2. L'importo non comprende eventuali ore di lavoro addizionali impiegate dalla nostra azienda per individuare malfunzionamenti hardware o errori nelle informazioni fornite dal cliente. Queste ore di lavoro addizionali verranno segnalate tempestivamente al cliente e quotate a parte al momento della consegna della fornitura per un costo orario pari a ...Euro/h.
44