COSA È SAP ACTIVATE: METODOLOGIA,

BEST PRACTICE, CONFIGURAZIONE

GUIDATA

SAP Activate è il nuovo “acceleratore di implementazione SAP” – in pratica la metodologia e gli

strumenti che SAP suggerisce di utilizzare quando si implementa l’ERP.

Si tratta di tre cose in una: una metodologia, le “SAP Best Practice” (i processi aziendali considerati
migliori e suggeriti da SAP) e degli strumenti di configurazione guidata del programma. Rilasciato
nel 2015 fornisce un quadro di riferimento per aiutare il cliente attraverso tutto il ciclo di vita
dell’implementazione.

Sono la metodologia e gli strumenti che SAP suggerisce di utilizzare quando si implementa SAP
S/4HANA. Può essere usato anche per l’implementazione di altri prodotti – la Business Suite di SAP
ERP, SAP Customer Relationship Management, SAP Supply Chain Management e anche alcune
soluzioni cloud come SuccessFactors, Customer Experience e Ariba.

Activate è uno strumento flessibile: supporta infatti vari punti di partenza (nuove implementazioni,
conversioni di sistemi, migrazione di dati selettiva) e diversi scenari, sia on premise che cloud.
Non è obbligatorio utilizzare tutti e tre i suoi componenti: se ad esempio stiamo lavorando a una
conversione di sistema da SAP Business Suite a S/4HANA potremmo scegliere di scartare le best
practice ed utilizzare solo la metodologia e l’installazione guidata.

SAP Activate propone una metodologia in 4 passi che sostituisce la metodologia ASAP,
considerata troppo rigida (se non siete familiari con ASAP potete vedere questo articolo).

1. Preparare (Prepare): La fase di preparazione è quella in cui un progetto viene pianificato e

avviato utilizzando le “best practices”.

2. Esplorare (Explore): La fase di esplorazione è quella in cui diversi team della società cliente
si riuniscono con i consulenti e determinano quali funzionalità dell’ERP soddisferanno i
requisiti per i quali viene implementato SAP.

3. Realizzare (Realize): La fase di realizzazione è quella in cui SAP viene configurato ed i

consulenti che lo implementano cercano di avere dei feedback frequenti da parte degli
utenti per confermare che il progetto stia andando nella direzione corretta. Questo modo
di lavorare, se avete esperienze di programmazione, ricorda molto da vicino i concetti della
metodologia Agile (la validazione frequente dei risultati aiuta a diminuire le incomprensioni
e a favorire l’accettazione dei risultati).

4. Lancio (Deploy): La fase di lancio del sistema prevede la preparazione del cut-over (il
momento transitorio in cui gli utenti smettono di utilizzare il sistema preesistente
nell’impresa per passare al nuovo sistema).

Oltre alle quattro fasi di progetto del metodo Activate ci sono anche quattro “quality gates” (punti
del processo in cui viene controllata la qualità del lavoro) alla fine di ogni fase.

Questo è un requisito minimo – per programmi di implementazione più complessi possono essere
necessari (o molto consigliati) ulteriori quality gates.

La metodologia proposta da SAP Activate può essere vista come una combinazione di elementi di
un processo “a cascata” con altri di un processo “agile”.

Una metodologia a cascata (waterfall) divide le attività del progetto in fasi successive con una serie
di passaggi sequenziali chiari e ben definiti. I passaggi vanno completati in sequenza e non si può
iniziare il successivo sino a quando non si è completato il precedente.

I requisiti sono definiti prima di iniziare, ed i risultati tendono ad essere visibili solo alla fine del
processo di sviluppo.

Una metodologia Agile invece è più veloce e flessibile. I progetti vengono completati in cicli
successivi, ed in ogni ciclo ci si concentra su ciò che è più importante in quel momento. Vengono
fatte varie iterazioni, ognuna delle quali produce un pezzo di software funzionante.

Permette di incorporare nelle sviluppo cambi e nuove richieste. Promuove inoltre una
collaborazione accentuata tra sviluppatori ed utenti finali.
In SAP Activate la fase Realizzare (Realize) ha una struttura agile, mentre le altre fasi hanno una
struttura a cascata.

La configurazione guidata (immagine qui sotto) è invece un insieme di strumenti che aiutano a
configurare la soluzione, testare i processi, effettuare la migrazione dei dati, etc.

Come accennato in precedenza le “best practices” sono in pratica dei processi aziendali standard
e “pronti all’uso” che sono stati ottimizzati per funzionare in S/4HANA.

Questi processi aziendali pronti all’uso sono basati sulle conoscenze e dalle esperienze fatte con
l’implementazione del gestionale da migliaia di clienti SAP.

Offrono dei processi “pronti all’implementazione”, dati e strutture organizzative modello per
supportare gli obiettivi strategici del business e accelerare l’implementazione di SAP. I processi
pronti all’uso per S/4HANA si integrano anche con le soluzioni cloud di SAP come Ariba e
SuccessFactors.

L’adozione dei processi e delle soluzioni standard eviterà anche dover lavorare ad ulteriori
requisiti di personalizzazione. Questo ridurrà il costo non solo il costo dell’implementazione ma
anche il complessivo di manutenzione del sistema.

Sono organizzati per processo di business (per esempio “Contabilità fornitori” o “Produzione per il
magazzino”).

Una soluzione ancora più standardizzata è quella di usare una “SAP Model Company”.
Si tratta di un servizio aggiuntivo offerto da SAP nel quale è possibile scegliere delle “imprese
preconfigurate” per i settori ed i paesi che ci interessano (ad esempio “Aerospaziale e Difesa”,
“Bancario”, “Vendita al dettaglio”, “Assicurazioni” e così via).

Si tratta della soluzione che minimizza gli sforzi di implementazione (massimizzando la

standardizzazione), ed è l’evoluzione della Rapid Deployment Solution.

Ordinando le soluzioni proposte da SAP da minore a maggiore standardizzazione avremo dunque:

1. Best Practices

2. Rapid Deployment Solution

3. SAP Model Company

Il beneficio principale percepito da molti utenti che utilizzano la metodologia SAP Activate è la
riduzione del tempo di implementazione (e quindi anche dei costi associati), oltre a una
diminuzione dei rischi che deriva dall’uso dei processi ampiamente testati definiti nelle “best
practice”.

_____________________________________________________________________________________________________

Una specifica funzionale è un documento formale che si utilizza nel progetto quando viene
effettuata la personalizzazione di un elemento di SAP come ad esempio rapporti, le interfacce, i
flussi di lavoro, etc.

Queste personalizzazioni vengono normalmente effettuate perché ci sono delle differenze tra
come è configurato SAP inizialmente e come lo vuole il cliente finale.

Si utilizzando quindi frequentemente quando viene implementato SAP per la prima volta ma
possono essere necessarie anche quando si installa un componente aggiuntivo o un
aggiornamento del sistema.

Gli elementi per i quali vengono creati sono collettivamente chiamati “RICEF” – acronimo inglese
dei termini Reports, Interfaces, Conversions, Enhancements, Forms.

WRICEF stands for Workflow, Report, Interface, Conversion, Enhancement, and Forms. It covers any kind
of custom development or enhancement. WRICEF configuration units can group all configuration,
development, and documentation that belongs to the enhancement.

Metodi Waterfall e Agile

I due metodi più famosi e utilizzati di project management sono il

metodo Waterfall e quello Agile.

Di seguito una breve descrizione delle due tipologie di gestione di

progetto e un’analisi sintetica dei vantaggi e degli svantaggi di ognuno di
essi.

Metodo Waterfall:

Il metodo Waterfall (anche noto come Liner Sequential Life Cycle Model)
corrisponde a una gestione del progetto di tipo tradizionale e
sequenziale; si basa su una successione a cascata di fasi distinte dello
sviluppo del software (analisi dei requisiti, design, sviluppo, collaudo,
deploy, eventuale manutenzione) ben documentate, ognuna delle quali
generalmente termina prima che inizi la successiva. In tale metodologia il
prodotto viene consegnato al cliente alla fine del processo.
Di seguito una lista dei principali vantaggi e svantaggi del modello:

Vantaggi:

• Pianificazione e progettazione più semplici: gli sviluppatori e i clienti

concordano su ciò che verrà consegnato già all’inizio del ciclo di vita del
processo; ciò rende possibile una consegna più rapida del progetto.

• È uno dei modelli più facili da gestire: per sua natura, ogni fase ha
risultati (deliverables) specifici e un processo di revisione.

• Processo e risultati possono essere ben documentati perché noti

dall’inizio.

• Metodo facilmente adattabile per lo spostamento di squadre: ogni

gruppo è a conoscenza di cosa deve fare e delle tempistiche da rispettare;
a seconda della fase attiva del progetto è possibile che vari membri del
team siano coinvolti o continuino con altri lavori.

• Ad eccezione di revisioni, approvazioni, riunioni sullo stato, ecc., la

presenza del cliente non è strettamente necessaria dopo la fase dei
requisiti.

• Interfaccia con gli stakeholders coinvolti risulta semplice, grazie alla

documentazione presente e alla impostazione definita di tempistiche e
attività.

 Poiché la progettazione è completata nelle prime fasi del ciclo di

vita dello sviluppo, questo approccio si presta a progetti in cui è
necessario progettare più componenti software (a volte in
parallelo) per l’integrazione con sistemi esterni.

Svantaggi:

• Poca comunicazione con il cliente perché i requisiti vengono definiti

all’inizio

• Modello rigido: raramente i progetti reali seguono il flusso lineare del

modello

• Non è un modello ideale per un progetto di grandi dimensioni: se c’è un

ritardo, tutti i processi di conseguenza slittano fino a che il processo in
questione non è terminato.

• Il processo di test inizia al termine dello sviluppo. Quindi a valle dello

sviluppo si possono trovare dei bug costosi da riparare.
• Molto difficile tornare indietro per apportare modifiche nelle fasi
precedenti.

• Possibilità che il cliente non sia soddisfatto del prodotto software

consegnato. Dal momento che tutti i risultati finali si basano su requisiti
documentati all’inizio del progetto, un cliente potrebbe non vedere ciò
che verrà consegnato finchè il prodotto non sarà quasi finito. A quel
punto, i cambiamenti possono essere difficili e costosi da attuare.

• Durante le fasi iniziali e finali si verificano delle situazioni di blocco

dovute al fatto che alcuni membri del progetto devono aspettare che altre
persone concludano le loro attività per proseguire il lavoro. Queste fasi di
inoperatività causano così uno spreco di risorse e tempi.

 A volte la soluzione tecnica implementata si rivela ben presto

tecnologicamente vetusta.

Metodo Agile:

Il metodo Agile fa riferimento ad un tipo di gestione innovativo e

iterativo in quanto comprende gli stessi step del metodo Waterfall, ma in
chiave iterativa: si lavora su pezzi di requisiti (e non su tutto in un’unica
soluzione) rendendo così possibile eseguire simultaneamente le attività
di sviluppo e test e di effettuare più deploy durante l’intera vita del
progetto:
A differenza del metodo a cascata, in cui la pianificazione delle attività è
definita all’inizio, nel metodo Agile il tempo è suddiviso in fasi di durata
definita (di solito settimane) chiamate ‘sprint’; all’inizio di ogni sprint
viene pianificato e definito, con il cliente, un elenco di prodotti finali da
consegnare entro la durata del relativo sprint. Se non è possibile
completare tutto il lavoro pianificato, il lavoro viene ridistribuito e le
informazioni vengono utilizzate per la pianificazione del successivo
sprint. Una volta completato, il lavoro può essere rivisto e valutato dal
team di progetto e dal cliente, attraverso build giornaliere e
dimostrazioni di fine sprint.

Anche il metodo Agile ha i suoi vantaggi e svantaggi. Vediamoli insieme.

Vantaggi del modello Agile:

• È un processo client focalizzato: il cliente è costantemente coinvolto in
ogni fase del progetto in quanto collabora ampiamente e direttamente
con il team di progetto durante tutta la durata del progetto

• Obiettivi periodici: grazie al fatto che i requisiti sono incrementali il

cliente ha frequenti opportunità di vedere il lavoro consegnato e di
prendere decisioni e cambiamenti in itinere.

• I team agili sono auto-organizzati e multidisciplinari: ognuno è

responsabile di una serie di task concatenate tra loro in modo che,
ottimizzando il tempo e le risorse umane, possano produrre il valore e i
risultati concordati con il cliente, guidati da un project manager che
organizza il lavoro e si interfaccia con essi.

• Qualità dello sviluppo: è possibile consegnare al cliente un’applicazione

in componenti funzionali completi e non in un’unica soluzione alla fine.

 La tecnologia utilizzata non può essere considerata vetusta

perché gli sviluppi si ripetono costantemente.

Contro del Metodo Agile:

Il lavoro risulta meno strutturato ed i flussi di lavoro meno chiari

• Il coinvolgimento dei clienti spesso porta ad aggiungere funzionalità

non definite nell’architettura e nel design iniziali con conseguente
aumento di tempi e i costi di implementazione.
• Poiché il metodo si concentra sulla consegna in time-box e sulla
frequente riprioritizzazione, è possibile che alcune attività non vengano
completate entro il lasso di tempo assegnato. Potrebbero essere necessari
sprint aggiuntivi oltre a quelli inizialmente previsti, aumentando il costo
del progetto.

• Funziona al meglio quando i membri del team di sviluppo sono

completamente dedicati al progetto e per progetti di sviluppo ampi.

• Il progetto può facilmente andare fuori strada se al project manager

non è chiaro quale risultato il cliente desidera

 Le strette relazioni di lavoro in un progetto Agile sono più facili

da gestire quando i membri del team si trovano nello stesso
spazio fisico, il che non è sempre possibile. Tuttavia, esistono
diversi modi per gestire questo problema, come webcam,
strumenti di collaborazione, ecc.

Volendo riassumere quanto detto, le differenze chiave tra il modello

Waterfall e Agile sono le seguenti:

• Waterfall è un processo di progettazione sequenziale, mentre Agile

segue un approccio incrementale.

• Nella metodologia Waterfall i test arrivano dopo la fase di sviluppo,

mentre in quella Agile i test sono eseguiti contemporaneamente allo
sviluppo del software.

• Il metodo Waterfall è da seguire per progetti con budget e tempi

relativamente definiti in cui gli attori coinvolti sono molti e si ha la
necessità di una maggiore strutturazione delle attività; il metodo Agile è
perseguibile in condizioni più flessibili, in cui il focus è prevalentemente
sulle esigenze di business.

 La metodologia Waterfall non consente di modificare i requisiti

una volta avviato lo sviluppo del progetto; il metodo Agile
consente di apportare modifiche ai requisiti di sviluppo del
progetto anche se la pianificazione iniziale è stata completata.

Non è facile rispondere alla domanda ‘quale metodo è migliore?’ poiché

la vera sfida da affrontare è trovare la giusta via e il giusto modo per
gestire progetti e interlocutori diversi, attingendo ai vari modelli con
flessibilità e lungimiranza. Ogni supplier dovrebbe essere flessibile e
tenere conto di tempistiche fisse con requisiti mutevoli (Agile) e di
tempistiche mutevoli con requisiti statici (Waterfall).

Quando si lavora a un progetto di consulenza, infatti, non esistono

più una serie di passaggi prefissati; tutto deve adattarsi alle
esigenze individuali del cliente specifico e modificato qualora
sorgano degli imprevisti, ma allo stesso tempo ci sono strutture e
obiettivi, con tabelle di marcia predeterminate, da cui non ci si può
allontanare.