progetto di gestione dei processi aziendali
Post on 12-Aug-2015
26 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
1
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
2
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
3
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 all’incirca 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 l’azienda 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 l’uso 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
all’azienda. 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.
Progetto di gestione dei processi aziendali
4
AZIENDA
Evidence: un'azienda informatica che opera nel
settore del software per sistemi embedded real-
time. Si trova in località Ghezzano - La Fontina Via Carducci, 56,
56010 San Giuliano Terme.
Progetto di gestione dei processi aziendali
5
E’stata 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, dell’automotive,
dell’automazione 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
6
Vision
L’origine universitaria spinge l’azienda 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
RTOS, with configuration
and schedulability
analysis tool
Automatic code
generator for control
systems
Embedded Linux and
Linux real-time products
and services
Progetto di gestione dei processi aziendali
7
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 un’accurata
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 all’azienda
l’attuale iter di preventivo; su tale procedimento dovremo
evidenziare possibili difetti e lacune che portano l’azienda 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 all’azienda 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
Progetto di gestione dei processi aziendali
8
mensili, TFR (trattamento di fine rapporto), tredicesima mensilità
e tasse varie. Tra i costi indiretti più significativi ci sono spese di
affitto dei locali dell’azienda, spese di tasse quindi luce, acqua,
gas, spese per acquistare i terminali e spese per le attività degli
amministrativi, che sono necessarie per l’azienda 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 l’incidenza 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
l’azienda per mantenere alle proprie dipendenze uno sviluppatore.
Figura 1 - Costo annuo di uno sviluppatore
Progetto di gestione dei processi aziendali
9
Ma quanto costa all’azienda 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 un’idea 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
10
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,
l’azienda 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
Progetto di gestione dei processi aziendali
11
I prezzi sono “gonfiati”, ovvero includono un margine di
guadagno rispetto all’effettivo costo orario di una risorsa.
Ma come viene realizzato il preventivo?
LIVELLO 0
Figura 5 - Livello 0
Progetto di gestione dei processi aziendali
12
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
Progetto di gestione dei processi aziendali
13
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.
L’azienda 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 l’evoluzione 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 l’azienda 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à, dell’esperienza 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 l’errore 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
Progetto di gestione dei processi aziendali
14
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 l’appunto
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
Progetto di gestione dei processi aziendali
15
A questo punto bisogna stabilire con esattezza quanto costa al
cliente un’ora 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 un’idea di quanto costerà al cliente un’ora
di sviluppo del suo progetto. Bisogna precisare che le cifre del
listino non sono rigide e vincolanti, sono solo un documento che
l’azienda utilizza per avere un riferimento rispetto a progetti con
caratteristiche simili svolti in passato.
Progetto di gestione dei processi aziendali
16
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 l’azienda 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
Progetto di gestione dei processi aziendali
17
in base alla disponibilità e, possibilmente, in base all’esperienza. 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 dell’offerta 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.
Progetto di gestione dei processi aziendali
18
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
Progetto di gestione dei processi aziendali
19
PROBLEMI
IMPUTAZIONE COSTI INDIRETTI
L’azienda 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 all’azienda. L’azienda 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
Progetto di gestione dei processi aziendali
20
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 dall’attuale
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. L’incentivo è finalizzato a produrre più celermente
in modo che ogni dipendente abbia l’obiettivo 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
all’azienda anche sotto l’aspetto della spesa economica. Nel
momento in cui si riesca ad alimentare una sorta di gara,
allora ciascun sviluppatore si impone l’obiettivo di essere più
bravo degli altri in modo tale da essere premiato dall’azienda.
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
Progetto di gestione dei processi aziendali
21
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.
Progetto di gestione dei processi aziendali
22
Con l’attuale base di imputazione, l’azienda perde di vista
l’effettivo peso che ha uno specifico progetto nell’economia
complessiva dell’azienda. L’azienda 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 dell’azienda 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 dall’azienda 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.
Progetto di gestione dei processi aziendali
23
COSTI COMMERCIALI
Tra le varie attività che vengono stimate e che vanno a formare il
preventivo, l’azienda 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 l’iniziativa 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
dell’azienda. Tale giustificazione non è plausibile, innanzitutto
perché le attività commerciali sono costi a tutti gli effetti che
l’azienda 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, l’azienda ne tiene in considerazione solo nella
valutazione del margine economico. Con quali conseguenze??
Progetto di gestione dei processi aziendali
24
La prima conseguenza è che allora tale margine non è profitto, ma
“nasconde” costi che l’azienda 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
l’aspetto commerciale del progetto, ma viene trascurato e valutato
in maniera approssimativa, come se non incidesse sull’economia
del progetto.
Progetto di gestione dei processi aziendali
25
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 nell’approntarli. 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.
Progetto di gestione dei processi aziendali
26
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
l’effettivo 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) all’azienda Evidence di
analizzare un progetto che hanno precedentemente svolto in modo
Progetto di gestione dei processi aziendali
27
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. L’idea
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 all’azienda 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 dall’inizio.
Progetto di gestione dei processi aziendali
28
MODIFICHE E VARIANTI
Come vengono gestiti eventuali modifiche o varianti al progetto?
E’ ovvio che, qualora nasca l’esigenza 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 l’autorizzazione a procedere.
Progetto di gestione dei processi aziendali
29
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.
Progetto di gestione dei processi aziendali
30
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.
Progetto di gestione dei processi aziendali
31
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
Progetto di gestione dei processi aziendali
32
"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.
Progetto di gestione dei processi aziendali
33
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
Progetto di gestione dei processi aziendali
34
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.
Progetto di gestione dei processi aziendali
35
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.
Progetto di gestione dei processi aziendali
36
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.
Progetto di gestione dei processi aziendali
37
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.
Progetto di gestione dei processi aziendali
38
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à.
Progetto di gestione dei processi aziendali
39
Mappatura del processo AS IS
Figura 10 - Mappatura processo AS IS (1 di 3)
Progetto di gestione dei processi aziendali
40
Figura 11 - Mappatura processo AS IS (2 di 3)
Progetto di gestione dei processi aziendali
41
Figura 12 - Mappatura processo AS IS (3 di 3)
Progetto di gestione dei processi aziendali
42
Mappatura del processo TO BE
Figura 13 - Mappatura processo TO BE (1 di 2)
Progetto di gestione dei processi aziendali
43
Figura 14 - Mappatura processo TO BE (2 di 2)
Progetto di gestione dei processi aziendali
44
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.
top related