Appunti
Transcript
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.).