Fasi di un progetto di implementazione di SAP: la realizzazione (2 di 4 – lo sviluppo del software)

Questo articolo è parte di una serie sulle fasi di un progetto di implementazione di SAP.

Nel precedente articolo abbiamo visto come la fase realizzativa sia formata dalle attività di parametrizzazione e dalle attività di sviluppo.

In questo post vediamo cosa sono le attività di sviluppo del software.

Lo sviluppo si occupa di tutte le funzionalità richieste dal cliente che non sono disponibili come standard o configurabili con una parametrizzazione come abbiamo visto nel precedente post.

Esistono diversi “livelli” di sviluppo.

A volte è possibile adattare alle nostre necessità il programma gestionale standard utilizzando delle “finestre di intervento” che fornisce la stessa SAP senza effettivamente modificare il programma standard. Si tratta delle cosiddette “User-exit” (letteralmente vie di uscita a disposizione del cliente e quindi delle vere e proprie finestre di software a disposizione) e le cosiddette BADI (Business Add-In) apparse nei programmi SAP più recentemente con finalità simili alle User Exit, ma che permettono delle modifiche più avanzate.

In altri casi è invece necessario scrivere un nuovo programma da zero.

La terza possibilità (ma lo sconsiglio vivamente) è di modificare il programma standard.

La modifica del codice di SAP comporta vari problemi. In base agli accordi sulla licenza software tra SAP e il cliente, nel caso di modifica del programma standard SAP (la compagnia) non è più obbligata ad offrire supporto sul loro prodotto.

Il secondo motivo è che quando si passa ad una nuova versione del software (“upgrade”) dovremo fare delle attività extra sulle applicazioni modificato (l’aggiornamento potrebbe sovrascrivere i cambiamenti, o potrebbero apparire delle incompatibilità).

Le attività di sviluppo si dividono in Analisi Funzionale (il momento in cui si documentano quali sono le nuove funzionalità che verranno implementate e come le stesse verranno sviluppate) ed Analisi Tecnica (un documento che verrà condiviso con i programmatori che spiega come dovrà funzionare il codice).

Alcuni consigli basati sulla mia esperienza nei progetti di implementazione.

1. Il progetto deve prevedere l’approvazione scritta delle analisi funzionali da parte del cliente. Ho visto sviluppi riscritti nuovamente (con notevole perdita di tempo e di costi) perché le analisi non erano state approvate oppure non erano chiare.
2. Non inviate l’analisi funzionale al cliente senza un incontro esplicativo: questo permetterà di capire se siamo in linea con le loro aspettative, rispondere a dubbi o domande ci permette di fare delle correzioni prima di rilasciare la versione definitiva del documento per approvazione.
3. Anche le analisi tecniche devono essere comunicate in forma scritta ai colleghi sviluppatori. Le istruzioni verbali possono generare equivoci, fraintendimenti e incomprensioni.
4. Anche nel caso dell’analisi tecnica, non inviate il documento senza aver prima fatto un incontro (o una teleconferenza). È possibile inoltre che in fase di sviluppo il programmatore abbia dei dubbi o trovi soluzioni più efficaci per alcune parti del programma: in questo caso occorre sempre aggiornare documentazione. Un documento non aggiornato è una mina vagante nell’oceano della documentazione progettuale.
5. Prevedete sempre dei test prima di rilasciare la funzionalità al cliente, anche sui processi collegati.

Nei prossimi articolo vedremo nel dettaglio la definizione delle interfacce con altri programmi.