Conversione al sistema SAP S/4HANA: un confronto con i fermi macchina di un aggiornamento di EhP

SAP S/4HANA

,

SAP

Conversione al sistema SAP S/4HANA: un confronto con i fermi macchina di un aggiornamento di EhP

Sergio Ferrari | Giu 05, 2019

Recentemente con Luca Grilli abbiamo discusso di come ridurre i tempi di fermo macchina grazie alla Robotic Process Automation (RPA). In questa intervista continueremo sul tema del Business Downtime, una delle principali cause di preoccupazione per molti clienti.

Come dicevamo, nelle nostre esperienze pratiche di conversione a SAP S/4HANA via brownfield, la conversione tecnica si riesce a contenere all’interno di un fine settimana. In alcuni casi abbiamo seguito la strategia “resource-minimized”, mentre in altri quella di “downtime-minimized”.

Limitare i tempi di inattività aziendali al fine-settimana diventa così uno dei principali obiettivi del progetto di conversione.

In questa intervista, parleremo con Andrea Taccolini per confrontare i tempi di inattività legati all’aggiornamento di Enhancement Package (EhP) con quelli del progetto di conversione e rivedere le fasi salienti del Business Downtime.

Ciao Andrea, sai come funziona: raccontaci qualcosa di te!

Beh, sono un appassionato SAP Basis Consultant da circa 20 anni. Mi piace sperimentare per primo nuove tecnologie, ma ho un debole per la SAP Business Suite, che è un po’ il mio cavallo di battaglia. Sono stato tra i primi ad adottare la tecnologia di database SAP HANA su sistemi SAP BW e sui sistemi SAP S/4HANA.

Potresti mettere a confronto i tempi di fermo macchina a cui siamo abituati quando effettuiamo l’aggiornamento ad un nuovo EhP con quelli relativi alla conversione a SAP S/4HANA?

Certo, ormai ho analizzato i log tecnici della conversione innumerevoli volte! Dal punto di vista tecnico, le operazioni sono assolutamente paragonabili. L’istanza shadow, la creazione del mondo del workbench sono simili ad un EhP. Le differenze arrivano con la migrazione del database ad HANA e il popolarsi di nuove tabelle (es. la famosa ACDOCA). Il tempo impiegato, qui, è proporzionale al volume di dati e alla potenza dell’infrastruttura. Il lavoro in parallelo è ben supportato e il numero di CPU disponibili è cruciale.

Lavorando con altri nostri specialisti del Global S/4HANA  LaunchPad Team in Techedge, siamo riusciti a ridurre notevolmente la fase di Riconciliazione dei dati FI.

Secondo te, che cosa influisce sui tempi di inattività aziendale più di quanto ci si aspetta?

Il fermo macchina relativo alla conversione a SAP S/4HANA può essere suddiviso in due momenti principali:

il primo è quando il Software Update Manager (SUM) entra nella fase “Execution”, dove il sistema SAP viene chiuso e il SUM avvia il processo di migrazione.

Nella nostra ultima esperienza su un’infrastruttura «on-premise», abbiamo convertito un sistema da 1,7TB in circa 20 ore lanciando 75 processi in parallelo. Abbiamo lavorato sodo per ottimizzare il numero di processi sull'infrastruttura disponibile. Il database SAP HANA è installato su una macchina con 64vCPU e 950GB di RAM.

Il secondo momento importante si ha quando inizia la «migrazione dei dati FI». Tecnicamente siamo già in SAP S/4HANA, ma il popolamento delle nuove tabelle (es. ACDOCA) deve essere eseguito prima di consegnare il sistema all’utente finale. Qui collaboriamo con il team funzionale per individuare la migliore distribuzione del carico di lavoro (n. di background job SAP) sui SAP Application Server dedicati.

Nella nostra ultima esperienza, la “migrazione dei dati FI” si è conclusa con successo in meno di 10 ore, con 2 Application Server in esecuzione su 24vCPU e 32GB di RAM (ciascuno).

...quindi ci avete messo meno tempo del previsto?

Posso dire che non abbiamo riscontrato grandi differenze nelle migrazioni di sistemi eterogenei rispetto agli upgrade fatti in passato, come modifica infrastruttura SAP (hardware e database) congiuntamente con aggiornamenti di EhP.

Ultima domanda: hai qualche ulteriore proposta per limitare i tempi di inattività aziendali?

Sì, certo. Abbiamo stabilito ottime partnership con i principali Hyperscale Cloud Provider e disponiamo di una configurazione specifica dell’infrastruttura calibrata esattamente per questo scopo. In questo modo possiamo offrire tutta la potenza necessaria in determinate fasi e cambiare la configurazione una volta che la conversione è completata, tutto a costi sostenibili. Ovviamente questo vantaggio è disponibile solo se il cliente si orienta verso il Public Cloud, che dispone di una potenza inimmaginabile.

Conversione a SAP/S4HANA

 

Per maggiori informazioni sulla conversione a SAP S/4HANA non mancare di iscriverti a questo blog. Di seguito riportiamo un indice degli argomenti trattati in questa serie di approfondimenti:


Interessato a Scoprire di più?

Scopri come aiutiamo le aziende in tutto il mondo verso la conversione a SAP S/4HANA rapidamente, con l'implementazione e i servizi di gestione.

 Scopri di più 

Iscriviti!