Progetto di Gestione dei Processi Aziendali

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


CASO DI STUDIO 4: Software/hardware per infomobilità .................................................... 37

Introduzione ............................................................................................................................... 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



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


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.


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.


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.


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

http://www.evidence.eu.com/content/view/27/254/



http://www.evidence.eu.com/content/view/175/216



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


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


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


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


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


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


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


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


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.


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


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.


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


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


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


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.


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.


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??


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.


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.


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


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.


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.


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.


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.


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


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.


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


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.


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.


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.


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.


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.


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.


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à.


39

Mappatura del processo AS IS

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


40



41



42

Mappatura del processo TO BE

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


43

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


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.


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.

Progetto di Gestione dei Processi Aziendali

Documents

Transcript of Progetto di Gestione dei Processi Aziendali