Quali sono i punti di attenzione nei progetti SAP S/4HANA?

Cosa conviene fare per prepararsi? Come approcciare le novità?

1) Greenfield o Brownfield?

Ne abbiamo già parlato in questo post. Ma cosa conviene fare?

Greenfield: l'upgrade diventa una rivisitazione globale dei processi attualmente in essere. Come se fosse, per alcuni aspetti, un progetto di nuova implementazione.

Si tratta di un'ottima occasione per rivedere processi, migliorandone parti oppure sfruttando le novità della suite.

Attenzione questo tuttavia può comportare un tempo maggiore di analisi e complessità. Devi tenerne conto se vuoi intraprendere questa strada. Conseguentemente anche gli aspetti di profilazione possono diventare molto più impegnativi rispetto ad un upgrade "tecnico" o brownfield.

Brownfield: in questo caso si tratta di un upgrade più tecnico. Ovvero tutte le funzionalità (o quasi) del passato continuano a funzionare introducendo nessuna o poche novità delle nuova release.

Può essere relativamente più semplice rispetto al greenfield tuttavia in alcuni contesti è comunque impegnativo.

Ricordati che se hai definito un buon concetto autorizzativo un upgrade di questo tipo può essere sicuramente meno complicato rispetto a non aver definito un concetto autorizzativivo o non aver rispettato le regole di gestione della profilazione SAP.

Purtroppo in molti casi, siccome le autorizzazioni comunque "funzionano" indipendentemente da come le si è gestite si scoprono difficoltà solo durante i momenti di upgrade o aggiornamento di release.

Gli strumenti che SAP mette a disposizione funzionano solamente se si sono rispettate tutte le best practices di costruzione dei ruoli SAP.

Leggi qui sul perché durante gli upgrade di release le autorizzazioni SAP sono spesso dimenticate.

2) Co-Deployement o Embedded, quale architettura S/4HANA?

Esistono diversi modi per costruire l'architettura di S/4HANA. Sono necessari diversi componenti ad esempio:

• Il Front End Server (FES)
• Il Back End Server (BES)

Il primo (FES) rappresenta il SAP Gateway dove vengono esposte le APP (Applicazioni) nel secondo (BES) l'ERP. Per la collocazione del Gateway esistono diversi modi di deployment.

In generale dal punto di vista delle autorizzazioni la differenza è se il SAP Gateway (FES) è sulla stessa macchina dove risiede il backend oppure se è su una macchina diversa a se stante.

Nel caso in cui sia su su una macchina a se stante dovrai definire lì dei ruoli (chiamati Cataloghi e Gruppi) che definiscono le APP che un utente potrà vedere nell'interfaccia FIORI.

Mentre se il BES e FES coincidono avverrà tutto sulla stessa macchina.

Quali sono i punti di attenzione?

• Definire i gruppi e cataloghi può richiedere tempo, attivati appena possibile per capire quali APP devono essere attivate e come devono essere raggruppate
• Definisci una naming convention tra il BES e FES nel caso in cui siano diversi. Può essere utile nel caso sia necessario fare attribuzioni anche senza avere un Identity Management
• Attenzione all'oggetto S_RFCACL nel caso in cui BES e FES siano due sistemi diversi. Questo deve essere opportunamente segregato

Guarda qui il video sull'argomento:

3) Business Partner BP

Questa rappresenta una delle novità più importati ed impattanti, anche per l'aspetto autorizzativo.

Una serie di transazioni legate all'anagrafica dei clienti e fornitori sono sostituite da una unica transazione, già presente in SAP, chiamata BP Business Partner.

Questa transazione a seconda dell'utilizzo può operare su clienti o su fornitori. Era già capitato in passato una sostituzione analoga ma per la parte legata alla movimentazione merce, ovvero la transazione MIGO.

A proposito, sai cosa significa MIGO?

• M - Materials Management
• I - Inventory Management
• GO - Goods Movement

Esistono anche diverse versioni:

• MIGO_GI: "Goods Issue"
• MIGO_GO: "Goods Receipt Production Order " (GR for production order) MIGO_GR: "Goods Receipt" (GR from external procurement)
• MIGO_GS: "Goods Movement Subsequent Adjustment (subsequent adjustment of material provided)
• MIGO_TR: "Transfer Posting"

Cosa fare quindi?

• Le transazioni vecchie possono rimanere nei ruoli in quanto se usate vengono indirizzate verso la nuova transazione BP
• Gli oggetti autorizzativi delle transazioni XK* FK* o XD* etc sono comunque gli stessi (con alcune eccezioni). In alcuni casi alcune segregazioni potrebbero non funzionare, tieni conto di questo aspetto
• Potrebbe essere utile lavorare sull'oggetto B_BUPA_FDG in questo caso tramite il BP Analyzer, comando BDT_ANALYZER è possibile vedere tutti i campi che possono essere segregati (attenzione, sono cablati nel codice e non possono essere personalizzati)

• Attenzione sei hai una matrice dei rischi non dimenticare che deve essere aggiornata o adeguata

3) SAP S/4HANA 1909

In passato SAP, durante i rilasci di nuove release, ha sempre deciso di limitare gli impatti sul business, se possibile.

Ovvero, nel caso delle funzionalità security, queste dovevano essere esplicitamente attivate una volta effettuato l'aggiornamento.

Altrimenti erano presenti nel sistema ma non attive. Dalla release 1909, per alcuni profili d'istanza SAP, è stato deciso di attivarli in modalità operativa. In altre parole, se prima il valore di questi parametri era "conservativo" da questa release diventa il più restrittivo possibile.

Ecco quali sono:

Vedi anche nota OSS: 2713544 - New security settings during conversion to S4HANA 1909 with SUM 2.0 SP6

4) Attiva funzionalità security se servono

Alcune nuove funzionalità sono disponibili pur non avendo S/4HANA, tuttavia durante questo passaggio può essere importante valutarli e pensare di attivarli.

Cosa? Ad esempio:

• Ruoli PFCG legati al mandante, puoi finalmente fare in modo che la modifica dei ruoli sia legata all'apertura del mandante. Chiaramente nei sistemi produttivi. In questo modo non sarà possibile modificare il contenuto del ruolo nei sistemi di produzione (vedi OSS Note: 1723881 - Application of client-specific Customizing settings to role maintenance)
• UCON è un acronimo che significa Unified Connectivity permette di tracciare tutte le chiamate verso i sistemi SAP, vedere cosa e chi viene richiamato e creare a seguito una whitelist per impedire chiamate non desiderate

5) Security Database fai la crittografica prima di partire

La sicurezza del database è uno degli aspetti importanti, oltre alla sicurezza applicativa guarda qui.

Attiva prima di partire la crittografia a livello di database HANA e sfrutta tutte le funzionalità security che questo database di offre.