Conversione del sistema a SAP S/4HANA: il ruolo di SAP Solution Manager

SAP S/4HANA

,

SAP

Conversione del sistema a SAP S/4HANA: il ruolo di SAP Solution Manager

Sergio Ferrari | Lug 22, 2019

SAP Solution Manager è la soluzione di gestione del ciclo di vita più completa per SAP, poiché consente ai clienti di mantenere sempre protetti i loro investimenti, sfruttare l’innovazione e ottenere valore dalle loro soluzioni SAP.

In questa intervista con Renato Moltrasio, analizziamo più nel dettaglio come SAP Solution Manager può supportare la conversione a SAP S/4HANA.

Ciao Renato, hai voglia di presentarti?

Ciao Sergio, grazie per avermi invitato a far parte della serie di blog sulla conversione a SAP S/4HANA.

Sono un senior specialist in Change & Control Management e IT Service Management, nonché un SAP Solution Architect da oltre 20 anni. Ho iniziato dalle «classiche» configurazioni ABAP TMS e da 8 anni a questa parte uso Solution Manager per guidare ALM. Mi piace considerare SAP Solution Manager come il sistema «ERP» del reparto IT e mi rendo conto giorno dopo giorno che si tratta di una vera innovazione nel modo di lavorare in ambito informatico.

Pensi che SAP Solution Manager possa supportare la conversione a SAP S/4HANA?

Sì, certo. SAP Solution Manager è una funzionalità chiave che può aiutare a plasmare il proprio progetto SAP S/4HANA nel caso di implementazioni sia greenfield che brownfield.

Nella conversione a S/4, una delle principali problematiche è la sincronizzazione delle modifiche tra il sistema «live» e l’ambiente di progetto. Una delle migliori caratteristiche di Solution Manager in questo senso è lo Standalone Retrofit, una funzione che tiene traccia di tutte le modifiche consolidate eseguite nell’ambiente AMS e fornisce uno strumento in grado di trasferire le modifiche nel sistema di sviluppo dell’ambiente del progetto di conversione, semplificandoti la vita nelle attività di doppia manutenzione!

Molto interessante! C’è altro che vorresti dirci?

Certo! Un altro tema caldo è la documentazione del processo che si sta implementando o regolando.

SAP Solution Manager prevede uno scenario di «Process Management» (ex «Solution Documentation») che può documentare e rappresentare tutti i processi di business compresi nell’ambito del processo di conversione. È possibile creare e memorizzare tutti i classici documenti di progetto, dalle specifiche funzionali ai documenti tecnici, documenti relativi ai test, ecc. La cosa interessante è che tutte queste informazioni diventeranno l’unica “fonte di verità” del progetto e, successivamente, della «Soluzione» che verrà implementata o migrata.

La Soluzione è il concetto cardine del Solution Manager, poiché riassume tutti i sistemi, le applicazioni e i processi aziendali e funge da contenitore per le diverse versioni della relativa documentazione.

Dal momento che la documentazione della Soluzione include i casi di test, sarà possibile generare tutti i piani di test necessari utilizzando lo scenario «Test Suite». I piani di test possono poi essere utilizzati per orientare e controllare in maniera continuativa la fase di test dell’accettazione da parte dell’utente, componente cruciale di ogni progetto. Nelle immagini che seguono si può vedere un esempio di analisi che è possibile sfruttare nel Test Suite per avere un’idea del tipo di test in corso.

SAP Solution Manager Process Management scenario per SAP S/4HANA Conversion

blog-s4-solman-2

Infine, tutti questi piani di test possono essere riutilizzati anche durante la fase di manutenzione, dopo il go-live del progetto, per eseguire il Test di non regressione, o NRT.

Fantastico! Prossima domanda: per quanto riguarda i casi di risultati difettosi nei test, Solution Manager può essere d’aiuto?

Speravo solo che me lo chiedessi, e la risposta è sì, assolutamente!

SAP Solution Manager fornisce un altro scenario chiamato ITSM (IT Service Management), che consente di gestire i difetti tramite «defect documents», utilizzando il processo ITSM predefinito. Si tratta di uno strumento per la gestione degli incident molto utile e semplice da usare, che tiene traccia di tutti i difetti e permette al team di elaborarli in modo ben organizzato. Alla fine saprai di aver completato tutti i casi di prova necessari e corretto anche i minimi difetti individuati durante la fase di test.

Questo scenario consente anche di ottenere un’idea più chiara di cosa rimane da aggiustare, analizzando lo stato dei «defect documents».

Infine, dopo il go-live potrai sfruttare lo scenario ITSM per la gestione generale degli incident durante la fase di manutenzione. La cosa migliore, però, è che si può integrare a ITSM anche un altro scenario: il Change & Control Management (ex ChaRM).

ChaRM incorpora le migliori pratiche SAP per quanto riguarda la gestione dei trasporti, in quanto consente di utilizzare di default il meccanismo del Trasporto di copie (nelle Normal changes). Inoltre, fornisce il collegamento tra i requisiti aziendali e la loro implementazione tecnica sottostante, passando attraverso la Documentazione della soluzione.

ChaRM dispone di un meccanismo di trasporto completamente integrato e di un sistema di controllo delle modifiche per gestire i cambiamenti tra stack tecnologici e componenti applicativi e, dulcis in fundo, è altamente integrato in altri scenari SAP Solution Manager.

Ultima domanda: qual è la tua funzionalità di SAP Solution Manager preferita?

In realtà ne ho due. La prima è il BPCA (Business Process Change Analyzer), una sorta di funzionalità «classica» che riassume due dei diversi scenari di Solution Manager che ho nominato prima: Documentazione della soluzione e Test Suite. Questa funzione consente di identificare l’impatto delle modifiche sui processi già implementati. È possibile inserire un elenco di richieste di trasporto o change document, ottenendo i processi già implementati che sono impattati (eseguibili nella documentazione della soluzione). In questo modo ci si può concentrare su un numero limitato di casi di test durante la fase di No-Regression Testing. 

La mia seconda funzionalità preferita è il CSOL (Cross System Object Lock) e DGP (Downgrade Protection). Si tratta di una funzione davvero semplice ma efficace, che viene utilizzata sia in CharRM che nello Standalone Retrofit per fornire una sorta di meccanismo di locking «logico», in grado di integrare il classico meccanismo di locking del workbench ABAP anche quando la richiesta di trasporto è già stata rilasciata, ma non ha ancora completato il suo ciclo di vita (cioè non è stata importata nel sistema di produzione).

Conversione a SAP S/4HANA

Grazie per esserti unito a noi e non dimenticare di iscriverti per ricevere gli ultimi aggiornamenti! Di seguito riportiamo un indice degli argomenti trattati in questa serie di approfondimenti:

 

Sei interessato a saperne di più?

Scopri come stiamo aiutando le aziende di tutto il mondo nella conversione a SAP S/4HANA con servizi di consulenza, implementazione e gestione. 

Scopri di più 

Iscriviti!