SAP Shell Copy, Container copy o Frame Copy?
Sai cosa sono?
Sinonimi di un sistema SAP vuoto, ma con configurazione, programmi e struttura simile ad un sistema SAP “pieno” di riferimento.
Spesse volte nasce l’esigenza di disporre di un clone SAP vuoto e senza dati applicativi, da poter popolare alla bisogna con un estratto o subset di dati.
Business case tipici di un carve-out societario o di un roll-out selettivo di solo una o alcune società del gruppo verso SAP S/4HANA.
Leggi il post e scopri perché potresti aver bisogno di una Shell Copy.
In un sistema SAP (SAP ECC, S/4HANA, CRM…) si distinguono 2 tipologie di dati:
- Dati applicativi:
- Dati transazionali (transactional data)
- Dari anagrafici (master data)
- Dati di configurazione:
- Customizing
- Metadata (Data dictionary), cioè dati che definiscono come gli altri dati devono essere strutturati
Esemplificando esistono alcuni dati che definiscono la modalità di esecuzione di un processo di business (customizing / configurazione e data dictionary) e altri dati che sono il prodotto o la materia prima di un processo di business (dati transazionali e anagrafiche).
Ci sono delle situazioni particolari, ad esempio quando si acquisisce o si cede una società o un ramo di società, in cui è necessario scindere tra le due tipologie di dati.
Ad esempio, se acquisisco una società, devo essere in grado di operare immediatamente con il nuovo business, questo significa che, con la cessione degli asset aziendali, deve essere trasferita anche la base dati informatica, fondamentale per garantire la continuità operativa.
Tuttavia, nel caso venga ceduto solo un ramo di azienda o una società parte di un gruppo, è necessario che nella cessione del sistema informativo siano trasferiti solo i dati applicativi di pertinenza del ramo o della società ceduti.
Un’altra situazione - recentemente molto diffusa - che richiede la distinzione tra dati di business e dati di configurazione, si determina quando si decide di portare solo una particolare società o organizzazione su un nuovo sistema informatico.
Ad esempio, una organizzazione, già operante su SAP ECC, decide di valutare l’evoluzione del proprio ERP tramite S/4HANA, avviando il processo solo per una particolare società o solo per un particolare modulo (ad esempio solo per i dati finanziari FI).
In quest’ultimo caso, si presentano due opzioni:
- Creo un nuovo sistema S/4HANA su cui devo replicare tutta la configurazionepresente in ECC, frutto di anni di customizzazione del sistema.
- Aggiorno una copia del sistema SAP ECC ad S/4HANA, ma in questo caso devo essere in grado di mantenere nel sistema copiato solo i dati applicativi della società che voglio trasferire su S/4HANA(tramite migrazione dati o ripresa delle anagrafiche e delle partite aperte).
In tutte queste situazioni, si palesa la necessità di creare un sistema SAP che, da una parte contenga i dati di configurazione, ma dall’altra sia privo dei dati applicativi, in modo da poter caricare successivamente solo i dati applicativi ambito della cessione o dell’aggiornamento tecnologico.
Ci sono due modalità per ottenere tale sistema vuoto ( conosciuto col nome di “empty shell”, o “frame copy” o “container copy”):
- Copia del sistema originale e cancellazione successiva dei dati applicativi
- Creazione di un sistema tramite un tool software che sia in grado di copiare solo i dati di configurazione
Nel primo caso, si tratta di effettuare una copia del sistema, di cancellare il client (mandante) con i dati applicati e di creare un mandante tramite il tool standard di copia mandante, selezionando solo i dati di customizing.
Il secondo approccio, invece, non è disponibile in una installazione SAP standard, in quanto richiede dei tool proprietari dedicati. A tal proposito esistono varie opzioni, e SAP mette a disposizione il tool SAP TDMS.
Quindi il vantaggio principale del primo approccio è che rientra nel disponibilità di tool standard che la licenza di un sistema SAP mette a disposizione.
Il vantaggio del secondo approccio è, invece, la semplificazione del processo e anche dal punto di vista della tempistica: una cancellazione standard di un mandante, da un sistema con parecchi anni di dati, può richiedere infatti anche molti giorni di esecuzione, a cui va aggiunta la tempistica per la copia del mandante con solo customizing.
Inoltre, bisogna considerare che il rapporto tra dati applicativi e dati di configurazione sul volume totale è solitamente di circa di 80 a 20 (80% di dati applicativi e 20% di dati di configurazione).
Questo significa anche che per la creazione del sistema di copia si richiedono le stesse risorse (per quanto riguarda lo storage) del sistema d’origine (per lo meno nella fase iniziale), quando magari alla fine il sistema copiato richiederà molto meno spazio. Considerazione valida soprattutto nel caso di sistemi HANA che hanno dei costi molto elevanti dal punto di vista dell’hardware.
Come anticipato, SAP metta a disposizione un tool chiamato SAP TDMS (Test Data Migration Server). Come si intuisce dal nome, il TDMS è in origine nato come tool per creare sistemi di test SAP con una limitata quantità di dati applicativi che siano però il più aggiornati possibile.
Ad esempio grazie al TDMS è possibile generare un sistema di test che contenga i dati applicativi del sistema di produzione dell’ultimo mese. In questo modo il sistema di test non richiede le risorse del sistema produttivo, mantenendo allo stesso tempo dati aggiornati e prossimi alla produzione, requisito fondamentale per test precisi ed accurati.
Come step iniziale per creare questo sistema di test con un volume ridotto di data, il TDMS include il servizio di Shell Creation, che crea un sistema contenente solo i dati di configurazione.
Su questo sistema generato ex-novo saranno – successivamente - migrati i dati applicativi selezionati o per data (a partire da) o per struttura organizzativa (codice società).
Il limite del TDMS è che, proprio perché nato per creare sistemi di test più possibile allineati alla produzione, durante la shell creation copia solo i dati di configurazione del dictionary e del workbench (i metadati), ma non i dati di customizing.
In quanto il customizing viene ripreso nella fase successiva, durante la migrazione selettiva per data e/o codice società.
In entrambi gli scenari anticipati (cessione o upgrade tecnologico di un solo ramo d’azienda), rimane uno step aggiuntivo per recuperare il customizing, con una copia del mandante con solo customizing.
Inquaero, proprio alla luce delle limitazione del TDMS di SAP, ha preferito sviluppare una nuova soluzione proprietaria Inquaero® NUX, che – grazie all’esperienza accumulata in molteplici progetti di carve-out, - permette di creare direttamente un nuovo sistema contenente solo i dati di configurazione (metadati e customizing).