Immagina di traslocare in una casa nuova. Hai vissuto nella vecchia per vent'anni: sai dove sono le chiavi di ogni stanza, hai copia delle chiavi per chi ti aiuta, qualcuna è stata duplicata nel tempo senza troppa documentazione, alcune stanze non le apri da anni ma le chiavi girano ancora.
Il trasloco è il momento in cui potresti, finalmente, fare il punto: decidere quali chiavi servono davvero, a chi darle, con quale responsabilità.
Oppure potreste prendere il mazzo intero, trasferirlo nella casa nuova e ricominciare esattamente come prima.
La migrazione da SAP ECC a SAP S/4HANA funziona esattamente così, quando si parla di autorizzazioni. Il sistema nuovo è diverso: architettura diversa, interfacce diverse, processi ridisegnati, e le chiavi vecchie non aprono tutte le porte nuove.
C'è un momento, inevitabile, in cui il role concept deve o può essere ripensato.
La domanda non è se farlo: è come farlo, e se cogliere quell'occasione per costruire qualcosa di migliore o per replicare, nella nuova casa, tutti i problemi della vecchia.
In questo articolo analizziamo perché la migrazione a S/4HANA può imporre una revisione strutturale delle autorizzazioni, cosa cambia rispetto a SAP ECC, quali sono gli errori più frequenti e come trasformare quello che molti vivono come un ostacolo in un vantaggio competitivo concreto.
La risposta breve è: perché S/4HANA è un sistema diverso, non un aggiornamento del precedente. SAP S/4HANA non è ECC con qualche funzione nuova è una piattaforma ridisegnata, con un modello di dati semplificato, un'interfaccia utente radicalmente diversa e processi che sono stati riscritti per sfruttare le capacità del database in-memory HANA.
Queste differenze si riflettono in modo diretto sulla struttura delle autorizzazioni.
In SAP ECC, gli utenti lavorano principalmente tramite SAP GUI, le tradizionali schermate a transazione. In S/4HANA, l'interfaccia primaria è SAP Fiori (se si decide di adottarla): un ecosistema di applicazioni web, organizzate in cataloghi e gruppi (o meglio spazi), accessibili da browser e dispositivi mobili.
SAP Fiori non è solo un cambiamento estetico: è un cambio di paradigma nel modo in cui le autorizzazioni vengono gestite.
Ogni app Fiori richiede autorizzazioni su oggetti specifici e deve essere assegnata all'utente tramite la configurazione dei Business Catalog e degli Space (Spazi) del Fiori Launchpad.
Un utente che in ECC aveva accesso alla transazione ME23N (visualizzazione ordine di acquisto) non vede automaticamente l'app Fiori equivalente in S/4HANA: deve avere le autorizzazioni specifiche per quell'app, configurate nel Launchpad.
Questo significa che ogni ruolo ECC deve essere analizzato transazione per transazione e mappato sulle app Fiori corrispondenti, un lavoro che non può essere automatizzato completamente.
S/4HANA ha eliminato o sostituito centinaia di transazioni SAP GUI presenti in ECC.
Alcune sono state rimosse perché il processo sottostante è stato semplificato, il nuovo modello di dati HANA non richiede più le tabelle aggregate che in ECC alimentavano certi report.
Altre sono state sostituite da app Fiori equivalenti o da nuove transazioni con logica diversa.
Il risultato è che un role concept ECC trasportato direttamente in S/4HANA contiene inevitabilmente autorizzazioni su transazioni che non esistono più, autorizzazioni "morte" che occupano spazio nel sistema senza servire a nulla, e manca di autorizzazioni su funzionalità nuove che gli utenti si aspettano di trovare.
È come portare nella casa nuova le chiavi di porte che non ci sono più, e scoprire che alcune porte nuove non si aprono perché non avete le chiavi giuste.
S/4HANA introduce nuovi oggetti di autorizzazione che non esistono in ECC, in particolare nelle aree che hanno subito la maggiore semplificazione. L'area Finance è emblematica: il nuovo Universal Journal, la tabella ACDOCA che in S/4HANA unifica contabilità generale, controlling e asset accounting in un'unica struttura, introduce oggetti di autorizzazione specifici che in ECC non erano necessari.
Un role concept ECC in area FI-CO che non include questi nuovi oggetti produce errori di autorizzazione su operazioni che in ECC funzionavano perfettamente.
Per le aziende che adottano S/4HANA in modalità cloud o in scenari ibridi con estensioni su SAP Business Technology Platform (BTP), il perimetro delle autorizzazioni si estende ulteriormente.
La BTP ha un proprio modello di autorizzazione, basato su role e role collection, diverso dalle logiche della SAP GUI e Fiori.
Gestire le autorizzazioni in un ambiente ibrido S/4HANA + BTP richiede una competenza che va al di là del tradizionale SAP Security on-premise.
C'è una metafora che descrive bene la condizione delle autorizzazioni in molti sistemi SAP ECC maturi: il sedimento geologico (stratificazione).
Ogni anno, ogni progetto, ogni richiesta urgente ha depositato un nuovo strato, un ruolo aggiunto, un profilo allargato, un'autorizzazione eccezionale mai revocata.
Dopo dieci, quindici, vent'anni di esercizio, il sistema di autorizzazioni assomiglia più a una formazione rocciosa che a un disegno progettuale: stratificato, opaco, difficile da interpretare senza una conoscenza storica che spesso appartiene a persone che non lavorano più in azienda.
La migrazione a S/4HANA porta questo sedimento alla luce perché lo rende incompatibile con il nuovo sistema. Non è possibile trasferire tutto senza analizzarlo, e l'analisi rivela inevitabilmente ciò che nel sistema ECC era rimasto nascosto sotto gli strati:
SAP_ALL o equivalenti, create per sbloccare interfacce in produzione e mai rivisitate
Per molti team SAP Security, la migrazione a S/4HANA è la prima occasione in anni in cui è possibile anzi, necessario fare un inventario completo e onesto dello stato delle autorizzazioni.
È un'occasione scomoda, perché rivela problemi accumulati nel tempo. Ma è anche l'unica finestra in cui il "reset" ha una giustificazione tecnica inattaccabile: il sistema nuovo è diverso, e le autorizzazioni devono essere ridisegnate comunque.
Di fronte alla necessità di rivedere le autorizzazioni in S/4HANA, le aziende si trovano di fronte a tre approcci fondamentalmente diversi con implicazioni molto diverse su effort, rischio e qualità del risultato.
È l'approccio che richiede meno effort nel breve termine e che produce i risultati peggiori nel lungo periodo. Consiste nel trasportare i ruoli ECC esistenti in S/4HANA con le modifiche minime necessarie per far funzionare il sistema, aggiungendo le autorizzazioni Fiori mancanti (applicazioni Fiori obbligatorie) e eventualmente rimuovendo i riferimenti alle transazioni dismesse, senza riprogettare la struttura complessiva.
Il risultato è un sistema S/4HANA con il debito tecnico delle autorizzazioni ECC intatto, più le inefficienze introdotte dall'adattamento forzato. Gli utenti accedono alle nuove app Fiori, ma il role concept sottostante è ancora quello di dieci anni fa, con tutte le sue incongruenze, i suoi accessi eccessivi e le sue violazioni di SoD. Il sedimento geologico è stato trasferito nella nuova casa, strato per strato.
Questo approccio viene scelto quando la pressione sul calendario del progetto è molto alta e il team SAP Security non ha il tempo o le risorse per un redesign strutturale.
È una scelta comprensibile ma costosa: il debito tecnico non scompare, si consolida nella nuova piattaforma e diventa progressivamente più difficile da affrontare.
È l'approccio intermedio, quello che offre il miglior equilibrio tra effort e qualità del risultato per la maggior parte delle aziende. Parte dall'analisi dell'utilizzo reale delle autorizzazioni in ECC chi ha effettivamente eseguito quali transazioni nell'ultimo anno, per identificare cosa serve davvero e cosa può essere eliminato.
SAP mette a disposizione strumenti come il Security Audit Log e il Workload Monitor (STAD) che permettono di analizzare i log di utilizzo delle transazioni per utente.
Questa analisi produce spesso risultati sorprendenti: una quota significativa delle autorizzazioni assegnate, spesso il 30-50%, non viene mai utilizzata. Eliminarla senza impattare l'operatività è il punto di partenza per un role concept più pulito.
Su questa base, il nuovo role concept S/4HANA viene progettato partendo dai processi reali degli utenti, non dalla struttura dei vecchi ruoli e mappato sulle app Fiori e sugli oggetti di autorizzazione specifici di S/4HANA.
Il risultato non è perfetto come un redesign completo, ma è significativamente migliore del lift and shift e richiede un effort gestibile nell'ambito del progetto di migrazione.
È l'approccio più ambizioso e quello che produce i risultati migliori, sia in termini di sicurezza che di manutenibilità nel tempo.
Parte da zero, o quasi, progettando il role concept S/4HANA sulla base dei processi aziendali, del principio del minimo privilegio e dei requisiti di Segregation of Duties, senza essere vincolati dalla struttura dei vecchi ruoli ECC.
SAP promuove questo approccio nell'ambito della sua strategia "Clean Core": un sistema S/4HANA con personalizzazioni minimali, processi standard e un role concept progettato per essere mantenibile nel tempo senza accumulare debito tecnico.
È l'approccio giusto per le aziende che vogliono fare della migrazione a S/4HANA una trasformazione reale, non solo un aggiornamento tecnologico, e che sono disposte a investire il tempo e le risorse necessarie.
Il limite principale è l'effort: un redesign completo richiede tipicamente (in contesti enterprise) tra 6 e 8 mesi di lavoro, con coinvolgimento dei key user per la definizione dei processi e un testing approfondito prima del go-live. Può non essere sempre compatibile con i calendari di progetto compressi che caratterizzano molte migrazioni S/4HANA.
Indipendentemente dall'approccio scelto, alcune trappole si ripresentano con una frequenza che merita una menzione esplicita perché sono prevedibili, e quindi evitabili.
Le app Fiori non sono semplicemente "la GUI nuova di SAP GUI". Hanno una logica di autorizzazione propria; Cataloghi, Spazi, Servizi, Pagine, che richiedono competenze specifiche e un effort di configurazione che molti progetti di migrazione sottostimano sistematicamente.
Il risultato tipico è un sistema S/4HANA in cui le app Fiori o non compaiono nel Launchpad degli utenti o generano errori di autorizzazione alla prima apertura. Questo è uno dei problemi più comuni nelle prime settimane di Hypercare post-migrazione.
Il role concept non è un documento tecnico che il team SAP Security produce in autonomia: è la traduzione informatica di chi fa cosa in azienda.
Senza il coinvolgimento dei key user, che conoscono i processi reali, le eccezioni, i ruoli ibridi e le situazioni non standard, il role concept progettato in astratto produce inevitabilmente autorizzazioni mancanti in produzione.
I key user dovrebbero essere coinvolti per quanto più possibile nella fase di progettazione e nel testing, non solo nella validazione finale.
La migrazione è il momento in cui la Segregation of Duties dovrebbe essere ridefinita su basi solide. Invece, in molti progetti viene trattata come un problema da affrontare "dopo la migrazione", quando il sistema è stabile. Il risultato è che le violazioni SoD di ECC vengono replicate in S/4HANA, spesso in forma diversa, perché le transazioni sono cambiate, e il lavoro di cleanup post-migrazione è significativamente più complesso di quanto sarebbe stato farlo durante il progetto
.
Le utenze tecniche ad esempio quelle usate per RFC, interfacce batch e API vengono spesso "trasportate" in S/4HANA così come sono, perché "le interfacce devono funzionare".
Il risultato è che le utenze tecniche con profili eccessivi di ECC diventano utenze tecniche con profili eccessivi di S/4HANA, spesso con accessi a funzionalità nuove che in ECC non esistevano.
La migrazione è l'occasione giusta per censire le utenze tecniche, eliminare quelle non più necessarie e ricalibra re i profili di quelle attive.
Il testing delle autorizzazioni in S/4HANA richiede che ogni figura professionale esegua i propri processi completi in ambiente di test non solo le transazioni principali, ma l'intero flusso dall'inizio alla fine, inclusi i casi eccezionali.
Comprimere questa fase per rispettare il calendario di progetto produce invariabilmente errori di autorizzazione nel primo mese di produzione.
Gli errori di autorizzazione che emergono in produzione costano molto di più, in termini di effort, di pressione operativa e di rischio normativo, di quelli corretti durante il testing.
Un role concept progettato correttamente per S/4HANA, con ruoli granulari, nomi coerenti, documentazione aggiornata e logica trasparente è significativamente più facile da mantenere nel tempo rispetto a quello che eredita dalla stratificazione di anni di ECC.
Ogni nuova richiesta di accesso, ogni cambio di mansione, ogni audit futuro diventa più semplice da gestire. Il costo dell'investimento in fase di migrazione si ripaga in efficienza operativa negli anni successivi.
Le violazioni di SoD, gli accessi eccessivi, le utenze tecniche non governate che in ECC erano diventate "parte del paesaggio, invisibili proprio perché presenti da troppo tempo, possono essere corrette in S/4HANA senza la resistenza organizzativa che si incontrerebbe nel tentare di farlo su un sistema in produzione da anni.
La migrazione crea una finestra di legittimità per il cambiamento: "il sistema nuovo funziona diversamente" è una spiegazione accettabile per modifiche che in ECC avrebbero richiesto lunghe negoziazioni interne.
Un role concept S/4HANA progettato con attenzione alla Segregation of Duties, al principio del minimo privilegio e alla tracciabilità degli accessi è già in buona misura allineato ai requisiti di normative come la NIS2, il GDPR e i framework di audit SOX.
Costruire la compliance normativa nel sistema fin dall'inizio costa molto meno che aggiungerla in seguito e riduce il rischio di dover affrontare un audit normativo con un sistema di autorizzazioni disordinato.
Non completamente. SAP S/4HANA introduce nuove transazioni, nuovi oggetti di autorizzazione e le app SAP Fiori che richiedono autorizzazioni specifiche non presenti nel vecchio role concept ECC.
Un trasporto diretto dei ruoli ECC in S/4HANA produce un sistema parzialmente funzionante, con accessi mancanti e autorizzazioni eccessive. La migrazione a S/4HANA richiede una revisione strutturata del role concept.
Il reset delle autorizzazioni è il processo di ridefinizione completa del role concept per adattarlo alla nuova architettura S/4HANA, alle app Fiori e ai processi semplificati della piattaforma. Non significa perdere il lavoro fatto in ECC: significa progettare un sistema di autorizzazioni pulito, aderente al principio del minimo privilegio e senza il debito tecnico accumulato negli anni.
Le differenze principali includono: le app SAP Fiori come interfaccia primaria con oggetti di autorizzazione dedicati; la rimozione di numerose transazioni SAP GUI; nuovi oggetti di autorizzazione per processi semplificati come l'Universal Journal in area Finance; e l'integrazione con SAP BTP per scenari cloud con modelli di autorizzazione distinti dall'on-premise.
SAP fornisce strumenti di analisi che identificano i gap tra ECC e S/4HANA, ma una conversione automatica completa non è possibile né consigliabile. La progettazione dei ruoli richiede decisioni su chi deve fare cosa e come separare i processi, decisioni che richiedono la conoscenza del business e non possono essere delegate a un tool.
Stai pianificando una migrazione a SAP S/4HANA e vuoi capire come strutturare la revisione delle autorizzazioni? O hai già completato la migrazione e il role concept non è quello che speravi? Contattaci per una valutazione del tuo punto di partenza.