Perché è necessario Data Sync Manager prima dell’aggiornamento a S/4

S/4 arriverà, è solo questione di tempo

Molti nostri clienti Data Sync Manager (DSM) hanno scelto di acquistare DSM nell’ambito di progetti di ampio respiro. Spesso l’occasione si presentava quando emergeva in una fase precoce il rischio che il progetto si scontrasse con sistemi di test obsoleti e dati imprecisi. In una situazione che vede numerose organizzazioni programmare l’avvio del percorso verso S/4, ritengo utile illustrare come essere un cliente DSM può aiutare prima, durante e dopo quello che si prefigura forse come il più grande progetto SAP che si profili all’orizzonte, ossia la migrazione a S/4.

Prima: Razionalizzare l’infrastruttura prima di una migrazione brownfield

Molte organizzazioni si trovano a fare i conti con ambienti SAP non di produzione cresciuti in modo tentacolare. Alcuni sistemi sono vecchie copie di produzione, mentre altri sistemi a mandante multiplo sono solo residui di progetti terminati ormai da tempo. Negli ultimi 20 anni, lo storage per le imprese è diventato più economico e gestibile, con la conseguenza che alle infrastrutture SAP è stato permesso di occupare sempre più spazio. Con l’incombente prospettiva di S/4 e sapendo che la tecnologia database in-memory è molto più costosa del disco, il momento di liberarsi del bagaglio in eccesso non è più procrastinabile. E, al contempo, assicurati di possedere validi dati di test per ogni capitolo del progetto S/4, indipendentemente da come deciderai di affrontarlo. Con DSM è possibile attivare nuove shell di sistema, popolarle con mandanti snelli contenenti dati mascherati e utilizzarle per sostituire i sistemi di test esistenti. In alternativa, puoi affidarti alle potenti funzionalità di cancellazione di Client Sync per rimuovere i mandanti ridondanti ed eliminare quelli che desideri reimpostare con dati validi. copri come portare alla luce i dati di prova SAP invisibili per recuperare i costi.

Prima: Fasi di preparazione per S/4

Ancor prima dell’avvio del tuo progetto S/4 puoi condurre una serie di operazioni preliminari quali la Customer Vendor Integration. Questo, unitamente ad altri fattori, potrebbe innescare una fase di cancellazione e pulizia dei dati. La possibilità di convogliare i dati on-demand direttamente al sistema di sviluppo o sandbox potrebbe rendere questi progetti preliminari funzionali molto meno dispendiosi in termini di tempo e tendenzialmente più capaci di far emergere con chiarezza il lavoro da eseguire sulla produzione. Dati di prova affidabili, quando ne hai bisogno; seleziona e copia solo i dati necessari. Scopri come funziona Object Sync .

Prima: Maschera i dati sensibili

Il tuo progetto S/4 potrebbe vedere coinvolti diversi integratori di sistemi e consulenti specializzati, i quali potrebbero avere la necessità di prendere visione dei tuoi sistemi non di produzione per poter formulare raccomandazioni, redigere relazioni di analisi e sondare varie soluzioni progettuali. Queste organizzazioni potrebbero essere in collegamento da tutto il mondo, con la necessità di visionare dati accurati, MA non dati personali reali. Il numero di violazioni dei dati da titolo di giornale in tutto il mondo è in crescita: non rischiare allora che qualcuno scarichi una tabella di dati sensibili da un sistema QA e la rivenda al miglior offerente. Data Secure ti permette di esercitare un controllo completo su tutti i dati sensibili.

Durante: Sandbox

Prima che il progetto inizi a pieno regime, SAP raccomanda la creazione di una sandbox. Per saperne di più su cosa accade nella sandbox, fai clic qui. Sarebbe ovviamente auspicabile una sandbox quanto più accurata possibile, sapendo tuttavia che per una copia completa della produzione occorrerebbe un’appliance più grande e costosa. Affidati a DSM per creare una sandbox snella e dedicata per il progetto e valuta l’ipotesi del cloud, sapendo che la durata del progetto sandbox non è mai chiara e nel frattempo devi continuare a prestare supporto al business. Scopri come Ballance Agri ha utilizzato DSM nella fase Sandbox di S/4.

Durante: Ricostruire l’ambiente non di produzione a partire dalla nuova produzione

Per chiunque adotti l’approccio brownfield, consiglierei di valutare attentamente l’ampiezza dello scarto tra configurazione, personalizzazione e codice nel sistema di sviluppo e produzione. Nel corso degli anni, il divario è diventato sempre più ampio, con l’abbandono del vecchio codice Z, la configurazione trasferita in QA e poi il progetto annullato, fino a componenti aggiuntivi di terze parti caricati in fase di sviluppo, ma mai disinstallati. I nostri team di migrazione ricorrono a DSM per ricostruire un nuovo ambiente non di produzione a partire dal sistema di produzione, nell’ambito della strategia di migrazione al cloud. Anche nel tuo caso l’approccio alla migrazione S/4 potrebbe prevedere una situazione simile.

Ricreare gli ambienti di sviluppo e QA a partire dalla produzione si traduce in un avvio più agile sul versante opposto, con un gap più contenuto tra sviluppo e produzione, quindi un minor rischio che si insinuino difetti. Le organizzazioni che hanno tentato questa via con copie complete nel percorso di migrazione si sono rese conto dei costi sull’altro versante quando era ormai troppo tardi. Presumibilmente, la riduzione del volume di codice personalizzato da sottoporre a refactoring gioca fortemente a favore in questo senso. Il ricorso a DSM per creare nuovi sistemi di test e sviluppo più circoscritti può produrre lo stesso vantaggio in termini di contenimento del divario tra sviluppo e produzione e di riduzione della quantità di codice Z da rilavorare, ma ad un costo nettamente inferiore, dal momento che si possono utilizzare appliance più contenute.

Durante: Abilitazione delle opzioni di cloud ibrido

Con la possibilità di mascherare i dati all’uscita, puoi anche optare per mantenere un ambiente di produzione on-premise e trasferire tutti i sistemi non di produzione sul cloud. Sono questi i sistemi che possono beneficiare maggiormente dell’elasticità delle risorse cloud. Puoi attivare i sistemi durante le fasi chiave del progetto e disattivarli quando non sono necessari. Con Object Sync e Client Sync che mantengono aggiornati i dati di prova, non vi sono persone reali o dati sensibili che lasciano la rete.

Dopo: TDMS non supportato su S/4

Anche una volta che il sogno di S/4 si è trasformato in realtà, il tuo percorso non è ancora giunto al traguardo. I team funzionali vorranno adottare S/4 come digital core per l'impresa intelligente. È probabile che seguano poi numerosi altri progetti legati alle potenzialità dell’intelligenza artificiale, del machine learning, ecc., in risposta all’azione portata avanti dalla tua azienda per trovare o mantenere il vantaggio competitivo. Tutti questi progetti avranno bisogno di dati di test accurati e di un’agile infrastruttura non di produzione. La tanto criticata soluzione TDMS, che ha indotto molti dei nostri clienti a rivolgersi in prima battuta a DSM, non supporta S/4, e alla luce delle modifiche che abbiamo apportato alla nostra architettura negli ultimi quattro anni per gestire le nuove tecnologie utilizzate da S/4, non vediamo proprio come possa riuscirci. DSM è una soluzione utilizzata su S/4, supportata su S/4 e certificata su S/4.

Dopo: Mantenere i sistemi di prova nella stessa appliance, anche se la produzione cresce

Con l'accelerazione del sistema SAP sull’altro versante della migrazione a S/4, il suo footprint è destinato fatalmente a crescere. Le tue appliance dovranno essere adattate o dimensionate di conseguenza, ma non necessariamente la tua infrastruttura non di produzione. Con un’attenta pianificazione e l’utilizzo di DSM Client Sync, hai la possibilità di tenere aggiornate le appliance di prova più piccole con sottoinsiemi provenienti dalla produzione, il che consente di rallentare notevolmente il tasso di crescita dei sistemi di test rispetto alla produzione.

Cerchi aiuto per la pianificazione della tua migrazione a S/4?

La nostra relazione di valutazione S/4 è in grado di fornire suggerimenti di alto livello sul probabile grado di impegno che richiede ciascun approccio e un preallarme in caso di blocchi considerevoli che potrebbero restare in attesa, tra cui:

• Controlli di idoneità SAP di interesse per il tuo sistema

• Numero di clienti/fornitori senza BP collegati

• Blocchi tecnici come un sistema non Unicode

• Aree SAP utilizzate dal tuo sistema ma non più supportate

• Quantità di codice personalizzato

• Dashboard visivo interattivo del sistema per inquadrare le conversazioni interne