L’ERP life-cycle vendor side

La sequenza di fasi in cui si esplode l’ERP life-cycle vendor side si basa sulla rielaborazione dello schema dell’ERP supply chain proposto da Ponis et al. (2007).

Le fasi iniziali contemplano le operazioni che definiscono l’ossatura dell’ERP e il ciclo si conclude con l’evoluzione continua del prodotto, che trae stimolo sia dalle nuove esigenze dei clienti, sia dal progredire della tecnologia (si pensi ad esempio alle ricadute del cloud computing sul deployment degli ERP).

Lo spettro di attività è dunque molto ampio (progettazione iniziale, programmazione informatica, testing, ecc.), tanto da comportare sette fasi (Figura 7).

42

La prima fase, l’analisi dei requisiti dell’ERP (ERP requirement), si propone di individuare e comprendere il “problema” e le opportunità. In altre parole, in questa fase si cerca di determinare – prima della progettazione – cosa l’ERP sarà chiamato a fare dai potenziali clienti (adopter organization e relativi utenti finali) considerate le tendenze in atto. Non a caso questa fase viene anche denominata user analysis.

Le principali attività di questo blocco riguardano:

 la definizione del project management plan, comprendente le tempistiche, i costi e le risorse umane da impiegare in relazione alle funzionalità dell’ERP. Questo piano guida l’esecuzione dei lavori e supporta le valutazioni di fattibilità;

 la determinazione dell’analysis plan, collegato al precedente documento e contenente la descrizione delle attività ed eventuali strumenti di supporto;

 la raccolta dei requirement. Queste informazioni derivano da fonti interne (system developer, business analyst) ed esterne (clienti potenziali, specialisti dei settori target);

 la specificazione delle funzionalità del sistema, la cui definizione è coerente ai requirement e alle indicazioni provenienti dagli analisti di sistema;

 la preparazione della documentazione funzionale allo svolgimento delle precedenti attività (schemi di struttura, modelli di comportamento, ecc.).

Il fine ultimo della progettazione (design of modules) è quello di dare soluzione al “problema”. Pertanto, questa fase comporta la traduzione delle informazioni raccolte durante l’analisi dei requisiti in un blueprint organico, funzionale a progettare appropriatamente non solo i moduli dell’applicativo, ma soprattutto l’interazione fra gli stessi. In questa fase le principali attività attengono a:

 la determinazione della strategia e del design plan, vale a dire la presa di decisioni circa le funzionalità effettive del sistema (il quale potrebbe rispondere completamente o parzialmente ai requisiti definiti in precedenza) e la definizione di un project plan;

 la definizione della computing architecture e del tipo di infrastruttura. Si tratta di scelte che riguardano i profili tecnici e in parte caratterizzano il deployment dell’ERP (possibili modalità di installazione e funzionamento dell’applicativo), come la

43

configurazione dell’architettura (client-server), il tipo di infrastruttura (server infrastructure), le specificità dell’hardware, del software, ecc.;

 la progettazione degli strumenti di supporto, la specificazione dei profili di sicurezza, dei livelli di controllo (quindi anche le boundary resource, si veda il capitolo 3);

 la progettazione delle interfacce utente (struttura, navigabilità, ecc.);

 l’indicazione delle classi usate per realizzare gli oggetti del sistema e dei relativi blocchi di codice.

Lo sviluppo dei moduli dell’ERP comprende un blocco di attività che trova nella programmazione il proprio comun denominatore. Si tratta della realizzazione del sistema e ciò implica un progetto volto a gestire e coordinare le attività, nel rispetto dei tempi previsti, e a definire un test plan, ossia una serie di controlli finalizzati a validare il sistema. A questo stadio è assai rilevante la produzione di una documentazione destinata ai programmatori e agli analisti di sistema, vale a dire la documentazione di sistema, come pure la predisposizione delle guide per gli utenti finali, ossia la user documentation, atte ad aiutarli nell’utilizzazione degli applicativi.

Di solito questa fase si chiude con l’elaborazione dei modelli di riferimento, funzionali ad esempio alla parametrizzazione degli ERP.

Nella fase del testing si condensano una serie di prove e di attività che si prefiggono di:

 “stressare” il sistema in modo da scoprire la maggior parte delle problematiche connesse all’integrazione e al lavoro congiunto di classi, moduli, database, ecc. Le possibilità di test sono svariate. Fra gli altri ci sono i test sulle interfacce utente, sull’interazione dei processi, sul livello di sicurezza offerto, sulla performance dell’ERP, sull’accessibilità e sull’appropriatezza della documentazione disponibile e via dicendo;

 verificare il consenso e l’accettazione del prodotto da parte del cliente finale, in modo da aver la conferma che quest’ultimo incontri i desiderata dei clienti;

 lanciare un test pilota, vale a dire una versione beta del prodotto, che viene utilizzata come se fosse la release finale, allo scopo di giungere, attraverso anche attività di fine tuning, alla versione da commercializzare.

44

La fase dell’implementation services riguarda la definizione da parte del software vendor del ventaglio di servizi che si accompagnano alla vendita. Tra questi quelli di maggior spicco sono riferibili ai servizi di:

 business process reengineering (BPR), forniti per l’ottimizzazione dei processi dell’adopter organization;

 installazione (attività di customizzazione e di testing on site);

 consulenza (successiva al go-live) ad esempio sui servizi di system support;

 training per le diverse figure (end user, amministratori, ecc.);

 manutenzione, per lo più connessi all’aggiornamento, e assistenza (help desk). In realtà l’attività di manutenzione non è facilmente delimitabile in quanto si tratta di applicativi in continua evoluzione. Pertanto, se in passato la manutenzione si configurava come un’attività con uno scope stabile e alquanto circoscritto, nel tempo questo genere di attività si è oltremodo arricchito, tanto da rientrare – almeno in parte – nello sviluppo del prodotto.

Infatti, secondo alcuni autori (Lientz e Swanson, 1980; Rajlich e Bennett, 2000), fra i compiti di manutenzione ci sono le attività volte a: perfezionare certune funzionalità (prospettiva perfective); modificare l’ambiente (prospettiva adaptive); correggere gli errori (prospettiva corrective), introdurre aggiornamenti al fine di evitare errori futuri (prospettiva preventive).

Alla luce di ciò, si capisce bene che posizionare tutte queste attività “manutentive” nella fase di implementazione può risultare inappropriato. Di fatto, i confini della fase di implementation services possono essere facilmente superati e agli occhi di chi scrive pare coerente attribuire alla penultima fase dell’ERP life-cycle vendor side solo gli interventi rispondenti ad una prospettiva corrective, associando alla fase successiva (continuous development) le altre tipologie di manutenzione.

L’ultima fase, infine, riguarda l’evoluzione continua del prodotto e, con riferimento a quanto appena analizzato abbraccia gli interventi di natura: perfective, adaptive e preventive.

In particolare, la fase in oggetto accoglie una ricca serie di attività, ad esempio: l’aggiornamento periodico del sistema; la ricezione e l’analisi dei feedback (degli user, del

45

sistema e degli sviluppatori e degli analisti di sistema); la predisposizione e l’integrazione di nuove funzionalità e nuovi moduli; l’adattamento/verticalizzazione settoriale; la formazione continua e l’addestramento del personale e dei partner.

Paradossalmente, l’assenza di evoluzione continua del prodotto pone le premesse per l’ingresso degli applicativi – che iniziano ad essere ritenuti legacy – prima nel phaseout, dove il vendor cerca di guadagnare quanto più possibile senza investire in alcun aggiornamento del prodotto, e poi nel closedown, che avvia l’applicativo al ritiro dal mercato.

46

Figura 7 – Le principali relazioni nell’extended ERP life-cycle

47