Fiori role design best practices for SAP S/4HANA

Cosa significa pensare come creare un modello autorizzativo nell'ambito Fiori per SAP S/4HANA?

Ma cosa suggerisce la SAP in questo caso?

Cosa è SAP Fiori e cosa è SAP S/4HANA?

SAP Fiori è l'interfaccia grafica nel contesto del sistema SAP ERP S/4HANA. Permette di definire quella che viene chiamata l'esperienza utente (UX User Experience) per i fruitori del sistema.

SAP Fiori come impostare il modello autorizzativo

Ancora una volta, nel contesto SAP, non esiste una unica modalità per decidere come impostare questi aspetti. Nel corso del tempo, ormai, abbiamo visto parecchi modi di gestire quest'aspetto. 

La SAP ha definito quali sono gli oggetti principali in questo ambito ovvero:

1. Ruoli SAP (i ruoli PFCG)
2. Cataloghi (ovvero i contenitori tecnici delle applicazioni)
3. Spazi (ovvero la modalità con la quale le applicazioni vengono presentate all'utente) questo oggetto ha sostituito gli ormai obsoleti gruppi. Ma quando spariranno davvero i gruppi (almeno fino alla release 2025 saranno ancora disponibili): 
   •  3500249 - SAP S/4HANA Cloud Private Edition and SAP S/4HANA: Replacement of Groups (deprecated) by Spaces and Pages 
   • 3148424 - What FES version will Fiori Groups be removed now that SAP provides Spaces and Pages?
     

Ma come questi oggetti possono/devono essere assemblati tra loro?

Ancora una volta, così come per i ruoli classici SAP (senza parte Fiori) sono ben noti gli ingredienti, la ricetta è ancora segreta.

Quale domanda comune che abbiamo visto/discusso durante le attività progettuali:

1. Quanti cataloghi definire
2. Si parte dai cataloghi SAP o meglio costruire da zero il tutto
3. Si parte copiando i ruoli SAP ed assegnando quelli (tenendo i cataloghi standard al loro interno)
4. Si deve definire la parte degli spazi oppure ogni utente si crea i propri preferiti
5. Quante applicazioni ci devono essere in ogni pagina/spazio
6. Ma le sezioni a cosa servono?
7. Gli spazi sono in ogni ruolo singolo che vado a creare oppure sono per figura professionale e quindi per ruolo composto

Molte altre sfumature è possibile trovare quando si iniziano ragionamenti di questo tipo. 

In generale va considerato anche il contesto naturalmente, al di là delle best practies. Ad esempio:

• Mancanza di tempo. Uso i ruoli SAP direttamente o copie
• Vincoli normativi. Posso certamente usare i ruoli SAP, per poi accorgermi che la quantità di applicazioni al loro interno è estremamente alta e quindi dovrò rivederne il contenuto a seguito per essere conforme
• Licenze SAP, come sopra, i ruoli SAP stessi contengono potenziali abilitazioni che fanno incrementare i costi delle licenze (nel contesto FUE)

Ma cosa ci suggerisce quindi la SAP?

Nella nota "3804102 - Fiori role design best practices for SAP S/4HANA on-premise" ci sono indicazioni a riguardo.

Quali i punti principali:

Progettazione per funzione aziendale. I ruoli vanno costruiti sulle mansioni e sulle persona di business, non sui moduli o sulle singole app. I ruoli standard SAP_BR_* servono solo come modello: vanno copiati nel namespace cliente e adattati, senza mai usarli in produzione così come sono né modificarli direttamente.

Requisiti di business confermati prima di lavorare in PFCG. Il business deve indicare la funzione o persona, i processi e le attività, le unità organizzative (società, divisione, organizzazione commerciale, ecc.), il livello di accesso richiesto (visualizzazione, modifica, creazione, approvazione) e i vincoli di SoD. 

Costruzione del ruolo tramite cataloghi. In PFCG si assegnano i business catalog dalla scheda Menu (opzione SAP Fiori Tile Catalog) anziché i singoli servizi OData, così le autorizzazioni sui servizi vengono derivate in automatico. Le restrizioni a livello organizzativo si completano nella scheda Autorizzazioni, e a ogni ruolo si associa uno space del launchpad (la best practice è uno space per ruolo). [Nota: nel ruolo collettivo]

Può davvero sembrare un tema semplice, ma molte sfumature in termini di gestione operativa ed infine di percezione utente (dato che viene deciso cosa e come gli utenti fruiscono il sistema) sono coinvolte e devono essere valutate.

Infine la gestione di tutti questi aspetti, spesso non pensata durante il progetto in relazione alla manutenzione continuativa a seguito.

Vuoi confrontarti con noi sul tema? Contattaci.