In cosa consiste effettuare un M&A merge and Aquisition in SAP?

Quali le differenze tra M&A e Carve out, quali i punti di attenzione relativamente alla sicurezza dei dati?

SAP Merge and Acquisition, Carve Out

Le operazioni di unione ed acquisizione di società sono comuni. Solitamente a seguito dell'acquisizione o dell'unione di più società si pone il problema di quale sistema gestionale usare.

• La società che ha acquisito impone il proprio sistema (non necessariamente SAP), quindi un sistema viene inglobato nell'altro
• Viene creato un nuovo sistema (spesso usato anche per attività di Joint Venture o consorzi o collaborazioni di società)
• Viene mantenuto lo stesso sistema per le società coinvolte (caso più raro)
• esistono diverse casistiche 

Quali casi reali abbiamo affrontato?

In generale con il M&A nella mia esperienza ho visto molti più casi di società acquistate ed inglobate nel proprio SAP (caso più semplice sotto alcuni aspetti). Poche hanno abbandonato SAP. In diversi casi anche attività di Carve-out. Ovvero per vendita, ad esempio, di un ramo di azienda. In questo caso tutti i dati relativi a quella società sono stati spostati su un nuovo sistema.

Solo in un caso ho assistito allo scorporo di due società (per ragioni di unbundling) mantenendo i dati nello stesso sistema. Forse il caso più complesso

Quali in generale i punti di attenzione?

Nel caso di sistemi diversi è possibile utilizzare delle soluzioni o servizi, per "fare pulizia" dei dati (chiamati System Landscape Optimization - SLO), in questo caso prima di rilasciare il sistema agli utenti è possibile rilasciare (nel sistema) solo i dati di competenza o potenzialmente cancellarli nel sistema di origine.

Nel caso invece di un singolo sistema? In questo caso le attività sono più complicate. Perché di fatto non si possono "pulire i dati" dato che dovranno rimanere nello stesso sistema ma essere consultati da persone diverse (quanto in precedenza non vi era la necessità di questa segregazione).

Quali i punti di attenzione?

• Segregazione tramite oggetti autorizzativi standard (possono non essere sempre sufficienti)
• Non sempre sono disponibili oggetti autorizzativi relativi alle transazioni custom (non perché non siano stati inseriti del tutto, ma perché al momento dello sviluppo non si era pensato ad una necessità di segregazione di questo tipo)
• Profondità storica del dato. In alcuni casi i dati devono essere accessibili per entrambe le parti ma a profondità storiche diverse (non semplice). Vedi anche "Come limitare la visibilità ad alcuni esercizi finanziari"
• La tematica prettamente IT. In diversi casi questo genere di utenti accede a funzionalità che non sono state pensate da SAP per essere segregate in maniera articolata, proprio perché necessarie ad amministratori. Quindi come segregare gli accessi alle transazioni SE16 (lettura diretta dei dati dalle tabelle) e similari o SM30 (modifiche dei dati in tabella) o le query, transazioni SQ* ma esistono diversi altri casi (es. transazione DB02 etcc)
• Le query possono essere un problema anche lato utente finale. Ma come conviene gestire le query? Leggi qui.
• Potrebbe essere necessario introdurre delle logiche di "chi ha visto cosa" in SAP. Da standard non esistono meccanismi automatici per farlo (Data Masking e Logging)
• Potrebbe essere necessario dotarsi di strumenti di Masking, ma non sempre in questi casi sono applicabili vista la mole dati da gestire (e richiedono inoltre licenze da acquistare)
• I sistemi collegati. Spesso i sistemi gestionali sono costellati di altri sistemi (master o slave) su diversi altri processi. Anche in questo caso potrebbe esserci un impatto da gestire sui sistemi collegati. Di limitazione interfacce o segregazione dei dati anche in questi sistemi