Considerazioni prima del check-in
Se dai tempi della pandemia non hai ancora preso voli internazionali, preparati perché la prima volta potrebbe essere uno shock. Rispetto al passato l’esperienza riserva molte più variabili. Durante gli spostamenti nell’aeroporto di Heathrow, avevo il terminal praticamente tutto per me: regnava un silenzio surreale per quella che consideravo l’ora di punta. Invece, poche settimane dopo, eccomi di nuovo a fare un’ora di coda solo per lasciare i bagagli dopo il check-in per un breve volo europeo. E, più recentemente, mi sono anche imbattuto nel temutissimo annuncio di "volo cancellato", comunicato solo alle 23:00.
Che cosa c’entra tutto questo con RISE with SAP® e la gestione dei dati di prova (oltre alla nostra soluzione Data Sync Manager™)? La mia esperienza con entrambi mi suggerisce che è tutta una questione di pianificazione, per non andare incontro a inutili criticità e costi extra indesiderati.
Spazio e tempo
Si prevede sempre l’aumento di spazio dell’ambiente di produzione SAP per garantire una capacità sufficiente per il costante incremento dell’archiviazione di dati da parte dell’azienda. Nella pianificazione potresti anche considerare questo impatto sui sistemi di test, in linea con la strategia e le tempistiche di refresh.
Prima del passaggio a RISE, questa operazione può essere effettuata reagendo a posteriori ogni volta che si verifica un problema. Quello che invece ti assicuri quando passi a un modello di costo come RISE è la possibilità di concordare in anticipo l’entità dei volumi che il tuo sistema andrà ad acquisire per l’intera durata del contratto. Abbiamo visto organizzazioni acquistare la suite Data Sync Manager (DSM) in un secondo momento per ridurre le dimensioni dei sistemi non di produzione, non ottenendo tuttavia un pieno risparmio sui costi rispetto a un contratto RISE sottoscritto con il sistema di test le cui dimensioni sono di un quarto rispetto alla produzione.
HANA multiplier
Potresti anche portare il tuo sistema esistente a RISE senza un aggiornamento S/4HANA immediato, ma la maggior parte delle organizzazioni passerà a S/4HANA nell’ambito della propria strategia RISE with SAP. Il costo di un sistema di test sovradimensionato potrebbe non essere troppo vantaggioso per i sistemi di database tradizionali, ma quando si passa al database HANA, la tecnologia in-memory richiesta ha un costo molto più elevato (in genere più di tre volte il costo, secondo la nostra esperienza) e la capacità di scalare in piccoli incrementi scompare. Quando un sistema supera il limite di spazio, la dimensione successiva raddoppia, con conseguente impatto sui costi (meno alcune economie di scala, si spera).
Ferma il contatore!
Il bello di utilizzare Client Sync, parte della suite DSM, per aggiornare i sistemi di test non sta solo nella possibilità di migrare tali sistemi su un dispositivo HANA più piccolo o nella capacità di dimensionamento paragonabile a un hyperscaler, ma anche nella possibilità di congelare i tuoi sistemi di test a quelle dimensioni, anche se la produzione cresce notevolmente. In genere Client Sync viene utilizzato per creare un sistema di test con cronologia delle transazioni pari a 3, 6 o 12 mesi. Quindi, in occasione dell’aggiornamento previsto per l’anno successivo, la dimensione aumenterà solo se:
-
l’azienda sta effettuando molte più transazioni rispetto al passato
-
vengono creati molti più dati anagrafici.
Anche se solo una di queste condizioni si verifica, puoi modificare leggermente il dimensionamento alterando la data della sezione o limitando il sistema di test solo a specifici codici aziendali. Anche se questa rappresenta unicamente una misura a breve termine fino al ciclo contrattuale successivo.
Includi DSM in RISE
DSM possiede tre certificazioni, tra cui quella che ne attesta il "funzionamento con RISE with SAP". Se implementi DSM prima di passare a RISE o nell’ambito del progetto di transizione verso RISE, non legarti a un contratto RISE per ottenere più spazio del necessario per sfruttare i sistemi non di produzione.
Lascia un commento: