Avalados por :
Otimização do tempo de inatividade na conversão do SAP ERP 6.0 para o SAP S/4HANA 1809 com o SAP NZDT
- Creado 01/03/2024
- Modificado 01/03/2024
- 8 Vistas
0
Cargando...
Introdução
Se você está planejando uma conversão do seu sistema SAP ERP 6.0 para o SAP S/4HANA 1809 ou superior, seja on-premise ou movendo-se para um hiperscaler, existem várias opções disponíveis para otimizar o tempo de inatividade. A demanda por continuidade nos negócios no mundo empresarial atual tem desafiado os profissionais de TI a realizar atualizações do sistema com o menor tempo de inatividade possível. O serviço SAP NZDT (Near Zero Downtime Technology) é um serviço que pode ajudá-lo a atender aos requisitos de tempo de inatividade da sua próxima conversão.
Tive a sorte de trabalhar com a equipe da NZDT em um projeto recente no qual um cliente global utilizou o serviço SAP NZDT para uma conversão do SAP S/4HANA 1809 para a AWS. Devido ao tamanho do seu banco de dados (~25 TB) e aos rigorosos requisitos de tempo de inatividade, a abordagem padrão do SUM não era possível. A equipe de serviço da SAP NZDT forneceu expertise na configuração da infraestrutura e na tecnologia de replicação delta em cada ciclo de conversão, enquanto o cliente e o parceiro da SAP concluíam o SUM e a conversão financeira. O projeto foi lançado com sucesso e gostaria de compartilhar os resultados finais com você.
Por favor, observe que no momento da publicação deste blog, existem três abordagens possíveis de tempo de inatividade para uma conversão para o SAP S/4HANA usando o SUM. Atualmente, apenas a abordagem padrão do SUM e o NZDT estão disponíveis, enquanto a Conversão Otimizada de Tempo de Inatividade está em fase piloto. Consulte as seguintes Notas disponíveis para cada metodologia e requisitos adicionais.
Revisão Rápida:
A partir do gráfico, a duração do tempo de inatividade diminui à medida que você se move para a direita, no entanto, haverá mais complexidades.
Aqui estão alguns passos-chave de alto nível do diagrama abaixo: Após a preparação e registro de dados, um clone do sistema é criado na etapa (3). O SUM/DMO é executado no sistema clonado (5) enquanto os dados são continuamente registrados no sistema original. Os negócios continuam como de costume para os usuários finais. Conforme nos aproximamos do tempo de inatividade empresarial, o sistema de destino já está no S/4HANA. Reproduções Delta são necessárias (10,11,12) no sistema de destino S/4HANA (sistema convertido) para colocar todos os ajustes em dia, já que a cópia clonada do banco de dados foi criada em uma data e hora anteriores. Durante o tempo de inatividade, (14) ocorre a migração delta final, que é significativamente mais rápida em comparação com a etapa (7). Durante as etapas (17 e 18), qualquer trabalho pós-processamento que precise ser realizado agora é independente do NZDT.
Se você está planejando uma conversão do seu sistema SAP ERP 6.0 para o SAP S/4HANA 1809 ou superior, seja on-premise ou movendo-se para um hiperscaler, existem várias opções disponíveis para otimizar o tempo de inatividade. A demanda por continuidade nos negócios no mundo empresarial atual tem desafiado os profissionais de TI a realizar atualizações do sistema com o menor tempo de inatividade possível. O serviço SAP NZDT (Near Zero Downtime Technology) é um serviço que pode ajudá-lo a atender aos requisitos de tempo de inatividade da sua próxima conversão.
Tive a sorte de trabalhar com a equipe da NZDT em um projeto recente no qual um cliente global utilizou o serviço SAP NZDT para uma conversão do SAP S/4HANA 1809 para a AWS. Devido ao tamanho do seu banco de dados (~25 TB) e aos rigorosos requisitos de tempo de inatividade, a abordagem padrão do SUM não era possível. A equipe de serviço da SAP NZDT forneceu expertise na configuração da infraestrutura e na tecnologia de replicação delta em cada ciclo de conversão, enquanto o cliente e o parceiro da SAP concluíam o SUM e a conversão financeira. O projeto foi lançado com sucesso e gostaria de compartilhar os resultados finais com você.
Por favor, observe que no momento da publicação deste blog, existem três abordagens possíveis de tempo de inatividade para uma conversão para o SAP S/4HANA usando o SUM. Atualmente, apenas a abordagem padrão do SUM e o NZDT estão disponíveis, enquanto a Conversão Otimizada de Tempo de Inatividade está em fase piloto. Consulte as seguintes Notas disponíveis para cada metodologia e requisitos adicionais.
Revisão Rápida:
A partir do gráfico, a duração do tempo de inatividade diminui à medida que você se move para a direita, no entanto, haverá mais complexidades.
- Abordagem padrão - Geralmente disponível na ferramenta SUM. Etapas longas do SUM, como migração de dados, atualização de software, XPRAS_AIMMRG / Conversão FI, são executadas na fase de tempo de inatividade técnico
- Otimização de Tempo de Inatividade (Apenas em Piloto Inplace) Em comparação com a abordagem padrão, é possível reduzir parcialmente o tempo de inatividade técnico movendo a Conversão e a migração de dados durante o tempo de atividade do SUM, reduzindo assim o tempo de inatividade geral. Reproduções delta são realizadas para qualquer alteração no tempo de atividade. Consulte a Nota 2293733 e Nota 2547309 para mais informações.
- SAP NZDT - Serviço fornecido pela equipe da SAP MDS (Minimize Downtime Service). As etapas do SUM são tratadas no tempo de atividade em um clone do NZDT para reduzir o tempo de inatividade empresarial geral ao reduzir o tempo de inatividade técnico usando um HW dedicado para o sistema clonado, ativando a instalação de origem, as instalações dos plug-ins DMIS e a replicação delta do processamento de dados. Observe que todas as etapas de pós-processamento, como reconciliação e validação, não podem ser otimizadas por abordagens de otimização de tempo de inatividade.
Como funciona o SAP NZDT?
Aqui estão alguns passos-chave de alto nível do diagrama abaixo: Após a preparação e registro de dados, um clone do sistema é criado na etapa (3). O SUM/DMO é executado no sistema clonado (5) enquanto os dados são continuamente registrados no sistema original. Os negócios continuam como de costume para os usuários finais. Conforme nos aproximamos do tempo de inatividade empresarial, o sistema de destino já está no S/4HANA. Reproduções Delta são necessárias (10,11,12) no sistema de destino S/4HANA (sistema convertido) para colocar todos os ajustes em dia, já que a cópia clonada do banco de dados foi criada em uma data e hora anteriores. Durante o tempo de inatividade, (14) ocorre a migração delta final, que é significativamente mais rápida em comparação com a etapa (7). Durante as etapas (17 e 18), qualquer trabalho pós-processamento que precise ser realizado agora é independente do NZDT.
Facebook
Twitter
Pinterest
Telegram
Linkedin
Whatsapp
Sin respuestas
No hay respuestas para mostrar
Se el primero en responder
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
Hola ¿Puedo ayudarte?