I vantaggi della tecnologia SLO per il consolidamento di sistemi SAP

Adattare i dati di un sistema SAP a condizioni di business in evoluzione (cessioni societarie, M&A, quadro normativo, etc…) non è un impresa semplice.

Saperlo fare in modo rapido, chirurgico e preciso è ancora più difficile.

Scopri come la metodologia SLO offra una valida alternativa agli approcci tradizionali!

In cosa consiste la tecnologia o metodologia SLO?

La tecnologia o metodologia SLO (System Landscape Optimization) anche nota con l’acronimo LT (Landscape Tansformation) consiste in una serie di programmi (software) e step progettuali volti a “trasformare il Landscape SAP esistente in nuovo landscape”, come riflesso di nuove e mutate esigenze di business (es. acquisizioni o cessioni societarie), o normative (Unbundling per le utilities, GDPR, etc..) o tecnologiche (preparazione e upgrade a S/4HANA, etc..).

Come funziona un software o “tool” SLO, e quali sono le differenze rispetto agli approcci tradizionali di ripresa dati?

Il nòcciolo del funzionamento di un software SLO è la capacità di modifica del dato direttamente a livello Database. I dati, o insiemi di record di tabelle applicative, possono essere estratti, letti e convertiti in runtime, per poi venire inseriti nelle corrispondenti tabelle di un sistema SAP di destinazione, oppure sovrascritti nella stesse tabelle su cui si esegue la lettura.

L’update dei nuovi valori nel database avviene a livello diretto (direct input), eludendo pertanto i controlli dell’applicativo SAP.

Per ricorrere ad un esempio, ipotizziamo di voler “migrare” le anagrafiche clienti da un sistema SAP sorgente ad un sistema SAP di destinazione.

Un tipico Software SLO contempla le seguenti funzionalità:

• Connessione del sistema SAP sorgente al sistema SAP di destinazione via RFC (Remote Function Call)
• Selezione dal sistema sorgente dei record delle tabelle rilevanti (nel caso dell’esempio i record delle varie tabelle anagrafiche clienti KNA1, KNB1, etc…)
• Conversione (eventuale) dei dati estratti secondo definite regole di mappatura e ri-numerazione
• Inserimento dei record estratti nelle corrispettive tabelle del sistema di destinazione

Il classico Batch Input è invece lo strumento per l’inserimento e la modifica massiva dei dati in SAP. Esso consiste nelle seguenti procedure:

• Registrazione dei comandi di una transazione con simulazione dell’attività manuale di inserimento dati lato utente (ad esempio simulo la creazione di una nuova anagrafica cliente via transazione XD01)
• Traduzione della registrazione in un programma ABAP per eseguire la modifica o l’inserimento massivo sulla base di un tracciato dati in input.
• Estrazione e preparazione del tracciato file di input
• Esecuzione massiva con posting del nuovo contenuto dati nel database del sistema SAP.

Esemplificando, l’approccio SLO può essere visto come un’ operazione di “copia e incolla” ovvero una replica fedele del dato originale, fatta salva l’introduzione – ove voluta – di regole di ri-mappatura specifiche di alcuni campi.

Il Batch Input è invece una ri-produzione ex-novo di uno “spartito” (tracciato file).

La differenza più evidente è che con la migrazione SLO il “creatore” del “nuovo” dato resterà invariato, così come la data di creazione e tutta la storia del documento ripreso e delle sue modifiche.

Mentre con esecuzione via Batch-Input il “creatore” delle nuove anagrafiche prenderà il nome dell’utente di Batch Input (ad esempio BIUSER) e la data di creazione sarà quella dell’esecuzione massiva.

Un’altra differenza sostanziale è nella velocità di esecuzione. L’approccio SLO, lavorando direttamente a livello DB, è indicativamente di un ordine di grandezza più veloce dell’approccio via Batch Input.

Per la processazione di grandi volumi di dati, l’approccio SLO è in grado di condensare l’attività di estrazione e inserimento all’interno di un week-end ( < 48 H ) con minimizzazione del tempo di downtime.

Diversamente, il Batch Input può richiedere giorni di runtime e tempo di fermo macchina non trascurabile.

Quali sono i business case tipici per un approccio SLO?

In linea di principio si possono identificare quattro macro-scenari per cui ha senso ricorrere all’approccio SLO:

1 – Armonizzazione e Riorganizzazione dei dati: ad esempio per la conversione del piano dei conti o per l’applicazione di una conversione valutaria di una vecchia valuta ad una valuta di nuovo corso.

L’armonizzazione e la riorganizzazione tipicamente avvengono sulla medesima basi dati di un unico sistema SAP ( = leggo, converto e riscrivo nello stesso DB)

2 – Dismissioni / chiusure o cessioni societarie (Carve-Out): qui gli approcci SLO sono indicati per la cancellazione selettiva di dati societari all’interno di un unico sistema (società dismessa o ceduta), oppure per l’estrazione e la migrazione selettiva di dati societari specifici verso un sistema SAP di destinazione (scenario di Carve-Out)

3 – Cambio di Tecnologia: ad esempio in progetti di Upgradi o adozione nuove soluzioni (da ECC a SAP S/4HANA)

4 – Integrazioni Societarie (M&A) o Consolidamento sistemi: ad esempio quando, in seguito all’acquisizione di una nuova società, si ha l’esigenza di integrarne i dati all’interno del landscape SAP esistente. Oppure quando si vogliono “fondere” più sistemi SAP separati in un unico sistema centralizzato, al fini del contenimento del TCO e della preparazione a futuri upgrade (es. S/4HANA).

Naturalmente ogni scenario applicativo ha i propri vincoli da rispettare e le proprie complessità. Ad esempio, un conto è operare un carve-out di dati societari con contestuale migrazione in un sistema “vuoto”, un altro conto è voler consolidare un sistema SAP in un altro sistema SAP già “popolato” di dati.

Nel secondo caso dovranno essere predisposte delle ulteriori logiche di ri-numerazione (per evitare sovrapposizioni con i dati esistenti) e di armonizzazione del customizing e del repository SAP, che incidono sulla complessità e sui tempi di progetto.

Quali sono le tempistiche tipiche di un progetto SLO?

E’ arduo definire delle tempistiche assolute di un progetto SLO. Molto dipende dal tipo di scenario in ambito e dal volume della base dati oggetto della conversione e/o migrazione.

In linea di massima è possibile prevedere una durata di circa 3 – 4 mesi per un progetto di carve out dei dati applicativi di una società (Company Code SAP) in un sistema di destinazione vuoto.

Mentre per un progetto di consolidamento di sistemi (System Client Merge) i tempi indicativi sono circa 10 – 12 mesi, articolati su più clicli di test (Quality Cycles) prima dell’ esecuzione live.

A chi rivolgersi per un progetto SLO?

SAP dispone di un Hub di consulenti tecnici esperti in Data Management per la realizzazione di progetti SLO che si avvalgono di software SAP (LT 2.0, CWB, MWB etc…) per l’implementazione e l’esecuzione del progetto.

In alternativa è possibile rivolgersi a consulenti certificati LT o a società che hanno sviluppato tool proprietari con tecnologia SLO.

Noi di Inquaero sappiamo supportare i clienti SAP nella realizzazione di un progetto SLO sia attraverso l’utilizzo di SAP LT 2.0, sia tramite il ricorso al software proprietario Inquaero® VELOCE.