Appunti

Fasi di una commessa software e interazione tra cliente e fornitore
(appunti per il corso GIAR – 08/09)
Lo svolgimento di una commessa per un nuovo software determina interazioni complesse tra il
provider (ossia la società informatica che realizza il progetto) e l’azienda cliente. Tali interazioni
richiedono, da parte del personale delle due aziende, competenze non solo tecniche ma anche
organizzative, commerciali, giuridiche. Inoltre possono venire ad essere interessati anche altri
soggetti (ad es. studi legali, fornitori di hardware, consulenti, ecc.).
Facciamo qui riferimento in modo generico al caso di un sistema complesso non standard, come ad
es. un nuovo ERP che richiede analisi e personalizzazioni specifiche, ed esaminiamo le principali
fasi della commessa stessa. Quel che viene qui presentato riassume e sintetizza un vasto studio di
vari casi di aziende informatiche analizzati nel 2008 e 2009; naturalmente ciascuna azienda opera in
modo personale, e tuttavia è possibile identificare alcuni aspetti tipici e comuni del modo di gestire
la commessa.
1. La commessa può avere inizio da una proposta del provider, che quindi cerca e contatta il
cliente. Può essere un cliente noto cui si propone ad es. un aggiornamento o nuovi moduli
del sistema in precedenza venduto, oppure un cliente completamente nuovo identificato
tramite opportune azioni di marketing (contatti telefonici, fiere, ecc.). Nel primo caso il
provider deve disporre di personale di vendita che segua il proprio parco clienti in modo
continuativo; nel secondo caso si richiede l’organizzazione di campagne di marketing
mirate, per le quali sono necessarie risorse adeguate (nel mondo degli ERP, peraltro,
quest’ultima modalità è rara e generalmente viene adottata solo dalle grandi società).
In altri casi è il cliente che contatta il provider, esprimendo un’esigenza specifica. In questo
secondo caso o si tratta di un vecchio cliente (che ricontatta il proprio provider) oppure un
cliente nuovo. Ad ogni modo la fiducia e la reputazione guadagnate sul campo, nonché il
meccanismo del “passaparola”, rappresentano per il provider meccanismi essenziali su cui
fare leva.
2. Per dare inizio al progetto si deve innanzitutto formulare un’offerta, e per questo è
necessario che il provider raccolga informazioni preliminari sul cliente e sul problema da
risolvere. Questo punto è delicato: si tratta di fare un’analisi di massima dei fabbisogni del
cliente, di prospettare le possibili soluzioni che il provider può fornire, e i relativi prezzi. Per
il provider questa fase può rappresentare un rischio d’impresa. Da un lato si deve formulare
un’offerta sufficientemente sostenibile e dettagliata per poter essere valutata dal cliente, e a
tale scopo bisogna investire risorse, ad es. inviando personale dal cliente a raccogliere
indicazioni dai manager, ad analizzare i processi, ecc. Tuttavia investire troppe risorse in
questo lavoro potrebbe essere rischioso in quanto potrebbe avvenire che poi l’offerta non
venga accettata. Specialmente per i piccoli provider che non possono investire troppe risorse
in fase commerciale la questione è problematica, a maggior ragione con i nuovi clienti.
Anche per l’azienda cliente ci sono comunque rischi: infatti anche il cliente deve impegnare
tempo e risorse per spiegare al provider i propri problemi e fabbisogni, fornire materiale per
consentire l’analisi (dando anche accesso a informazioni sulla propria azienda e sui propri
processi), ecc. Tutto ciò potrebbe risultare sprecato nel caso in cui poi la relazione
commerciale non prosegua.
3. Segue la formulazione dell’offerta. È un’attività molto delicata e difficile per il provider, che
come dicevamo deve definire i contenuti dell’offerta al cliente in modo sufficientemente
dettagliato e convincente ma senza poter entrare eccessivamente nei particolari, e soprattutto
riuscire a fissare un prezzo. Il provider deve qui evitare di prendere impegni che non si
riescono poi a mantenere in fase di progetto, o di fare preventivi troppo bassi che potrebbero
determinare perdite oppure obbligare a successive richieste di adeguamento del prezzo (il
che però aprirebbero inevitabilmente contenziosi con il cliente). D’altro canto, l’offerta non
può essere troppo generica, anche perché il cliente deve essere in grado di valutarla. Spesso
in questa fase il provider fornisce una prima bozza di documento dei requisiti, e spesso
presenta anche alcune demo del sistema (ad es. schermate tipo, magari usate in altri progetti
passati). Naturalmente il provider riesce ad essere più circostanziato e incisivo se ha già
esperienze con clienti simili o nello stesso settore (anche per questo spesso le società di
software - in particolare nel caso ERP - tendono a specializzarsi per settore o campo di
applicazione). Dal canto suo, anche per il cliente la presentazione dell’offerta comporta
problemi: non sempre il personale interno ha elementi sufficienti per valutare l’offerta sia
nelle implicazioni tecniche sia riguardo gli aspetti economici (si veda qui ad es. le
problematiche di valutazione economica dei costi e benefici di un progetto informatico): si
tratta dunque per il cliente di un’assunzione di rischio, e che spesso è fondata non tanto su
un giudizio oggettivo sul progetto in quanto tale quanto su altri elementi, tra cui la fiducia e
la reputazione del provider. Per minimizzare i rischi spesso il cliente mette a gara tra loro
diversi provider confrontando varie proposte per la soluzione dello stesso problema. Per un
provider questo vuol dire maggiori opportunità di mercato (ossia si può venire chiamati a
partecipare a molte gare) ma anche maggiore competizione. Per il cliente significa ampliare
il portafoglio di opportunità, ma anche impegnare risorse nell’analisi e nella selezione
(“vendor selection”), operazione che fra l’altro richiede criteri e modalità appropriate e per
le quali non tutte le società clienti dispongono di competenze interne (e infatti alcune
imprese si rivolgono a propri consulenti – ovviamente a pagamento - per selezionare le
offerte). L’offerta può essere seguita da una fase di negoziazione per correggere o definire
nei dettagli parti dell’offerta. Ovviamente è un’operazione onerosa e complessa per ambo le
parti, e che è quindi più probabile avvenga nel caso di progetti complessi o costosi. Il
provider deve mettere in campo competenze commerciali e capacità negoziali; il personale
di vendita deve conoscere sufficientemente bene il proprio prodotto ma anche la posizione
della propria azienda relativamente alla commessa (ossia quali margini si può accettare, la
priorità assegnata al cliente, ecc.).
4. Una volta accettata l’offerta si passa alla sigla del contratto (le due attività possono essere
naturalmente viste anche come contestuali). Il contratto traduce in termini giuridici formali i
contenuti del preventivo, specificando condizioni, eventuali penali, service level agreement,
come si procede nel caso di varianti, i tempi di consegna, le obbligazioni reciproche (ad es.,
per il cliente, la disponibilità all’accesso a dati interni), ecc. I contratti (spesso corposi)
hanno ovviamente validità legale, quindi il mancato rispetto può comportare sanzioni o dare
luogo a contenziosi (anche se va detto che il contratto rappresenta spesso più un deterrente,
dato che ricorrere ad azioni legali è poi oneroso per entrambe le parti). Molti provider fanno
ricorso a moduli-contratto preconfezionati già usati in precedenti progetti. In alcuni casi si
usa il supporto di uffici legali, anche se nel campo delle commesse informatiche c’è chi
sostiene che non è sempre facile trovare specialisti.
5. Per le fasi della commessa prima indicate a volte si deve impegnare molto tempo e molte
risorse, in qualche caso paragonabili alla realizzazione tecnica in senso stretto. Siglato il
contratto si può passare al lavoro vero e proprio. Innanzitutto si deve pianificare le fasi di
progetto (assegnando risorse e tempi), e costituire il team di progetto (che spesso è
congiunto o quantomeno comprende anche un referente dell’azienda cliente). Generalmente
questa pianificazione è fatta in accordo con il cliente, o quantomeno viene da questo
validata. Nominato il capoprogetto (normalmente un professionista con esperienza) inizia la
fase di analisi dettagliata (ad es. in un progetto ERP si dovrà analizzare e mappare i processi
e l’organizzazione, esaminare i sistemi esistenti, ecc.), con la successiva stesura di un un
documento dei requisiti completo, eventualmente da illustrare e far validare al cliente. Qui
conta molto, per il team di progetto, la capacità di comunicare efficacemente anche gli
aspetti di dettaglio. Impostato e validato il lavoro si passa alla realizzazione tecnica (ad es.,
per un ERP, scelta di moduli, eventuale aggiornamento, realizzazioni di parti di codice,
strutturazione di database, ecc); in questa fase può essere richiesto anche l’aggiornamento di
alcune parti di hardware, e in tal caso entra in gioco il possibile ruolo dei fornitori di
tecnologia. Naturalmente nella fase di esecuzione del progetto possono sempre sorgere
problemi inattesi e che potrebbero allungarne il tempo o accrescere i costi. Qui la capacità di
provider e cliente di relazionarsi, e la fiducia che si instaura tra le parti, sono ancora una
volta importanti per risolvere eventuali controversie.
6. Realizzata la versione finale del sistema (eventualmente realizzando prototipi successivi)
segue una fase di test che può avvenire prima sulle macchine del provider (su dati
incompleti o fittizi) e poi presso il cliente (con basi dati reali). Fatte eventuali modifiche
correttive, si passa all’implementazione completa (il cosiddetto “GoLive”), lavoro delicato
perché si va a interferire con l’operatività quotidiana dell’azienda cliente. Qui ci sono due
modalità tipiche. La prima è la migrazione istantaneamente dal vecchio modo di lavorare al
nuovo sistema (detto anche “big bang”): ossia si fissa una data precisa per il passaggio
completo e istantaneo al nuovo sistema. La cosa è vantaggiosa perché si evita la coesistenza
di due modalità di lavoro o sistemi in parallelo, ma richiede che gli utenti siano già
sufficientemente addestrati per lavorare con il nuovo sistema, e c’è il rischio che nel caso di
malfunzionamenti imprevisti si blocchi l’operatività dell’azienda. Per ridurre questi rischi
l’altro modo è procedere gradualmente (ad es. implementando o attivando un modulo ERP
alla volta), il che significa però che per un certo tempo si devono tenere in vita due sistemi
(con duplicazione di costi e possibili incoerenze di dati). L’implementazione è naturalmente
tanto più complicata quanto più sono le postazioni utente (in effetti i provider classificano i
clienti non sulla base della loro dimensione economica ma della dimensione del progetto
come numero di postazioni utente).
7. Altra fase importante (che in parte precede, in parte è contestuale e in parte segue
l’implementazione) è la formazione degli addetti, che può avvenire con varie modalità: corsi
veri e propri (ma sempre più brevi), affiancamento (ossia un addetto del provider che resta
per un certo tempo presso il cliente), assistenza diretta (specialmente le prime settimane - in
loco o in remoto), autoapprendimento (con manuali e demo scaricabili, accessi a
“knowledge base” ecc.). Segue l’uso operativo vero e proprio, e qui il provider (quantomeno
per i sistemi complessi) generalmente continua a fornire un’assistenza in vari modi (help
desk, assistenza in remoto, ecc.), e inoltre segue l’evoluzione del sistema fornendo o
proponendo adeguamenti (ad es., per un ERP, adeguamenti di moduli secondo nuove
normative, adeguamenti tecnici, nuovi processi da implementare, modifiche locali, ecc.).