Sabemos que para instalar SAP en una empresa podemos usar distintas metodologías conocidas como ASAP para SAP ECC, y Activate para SAP S4Hana.
Hoy, leyendo sobre migrar bases de datos, me entero de otra metodología que busca reducir considerablemente el tiempo de caída del sistema. En los últimos años, se han realizado progresos significativos en la ampliación de la disponibilidad general de los sistemas SAP.
Actualmente, los sistemas de las empresas deben estar en linea las 24 horas.
Un tiempo de inactividad natural como noches o fines de semana ya no existe en los negocios hoy en día.
Tiempo de Inactividad Planificado
Con la creciente demanda de soluciones de negocios que pueden operar 24x7, se desarrollaron tecnologías que mejoraron la disponibilidad del sistema. La confiabilidad de los sistemas mejoró significativamente. Los tiempos de inactividad no planificados se redujeron y ahora tienen una duración aceptables para la mayoría de los clientes.
En esta situación, el tiempo de inactividad planificado se convirtió en una gran importancia con respecto a la disponibilidad del sistema. La necesidad de actualizar el software en todas las capas de la pila vertical (desde el hardware, a través del nivel del sistema operativo, el nivel de la base de datos hasta el software de la aplicación) da como resultado la interrupción de las operaciones del sistema. Cortas interrupciones del sistema - 30-60 min - pueden ser aceptadas por usuarios comerciales.
Sin embargo, hay muchos eventos de mantenimiento que requieren interrupciones más largas del sistema. Esto se aplica al mantenimiento de la base de datos y al software de la aplicación. Actualmente, los clientes con altos requisitos de disponibilidad están expuestos a un tiempo de inactividad acumulado de 80 a 160 horas por año.
Aquí, los costos de los tiempos de inactividad individuales aumentan fuertemente con la duración del corte. Por lo tanto, la mayoría de los clientes preferirían una mayor cantidad de tiempos de inactividad más cortos que un solo tiempo de inactividad prolongado.
SAP mejora constantemente las herramientas para las actualizaciones de software. Por otro lado, la complejidad del software de la aplicación, las nuevas funcionalidades y el ajuste resultante de los datos existentes provocan que no se cumplan los requisitos de inactividad empresarial.
Mínima inactividad técnica
La reducción del tiempo de inactividad empresarial requiere la minimización del tiempo de inactividad técnica (optimización de las herramientas de actualización de software) y la minimización del tiempo dedicado a otras tareas ejecutadas en el tiempo de inactividad, por ejemplo reducción gradual, implementación de transportes de clientes, procedimientos de validación.
Método NZDT
Un procedimiento que reduciría el tiempo de inactividad general de los sistemas SAP a menos de 20 horas al año satisfaría a la mayoría de los clientes.
Contenido del Documento
Este documento detalla el método "Near Zero DownTime (NZDT)", que brinda la oportunidad de cumplir con este objetivo.
1 Introduction - pág.: 3
2 Technical Description - pág.: 5
2.1 General Description - pág.: 5
2.2 Cloning and Isolation - pág.: 6
2.2.1 Cloning Procedure - pág.: 6
2.2.2 Isolation of the Clone - pág.: 6
2.3 Table Classification - pág.: 7
2.4 Recording - pág.: 7
2.5 Replay of Data - pág.: 8
2.6 Resynchronization and Switch - pág.: 8
2.7 Data Conversions - pág.: 8
2.8 Unicode Conversion - pág.: 9
2.9 Integration of Customer's Transports in NZDT - pág.: 9
2.10 Technical Reconciliation - pág.: 10
2.11 Workbench - pág.: 10
3 NZDT Project - pág.: 12
3.1 Initial Information - pág.: 12
3.2 Planning Workshop - pág.: 12
3.3 Near Zero Downtime Project13
3.3.1 Pre-requisites - pág.: 13
3.3.2 End-to-End Tests and Dry Runs - pág.: 15
3.3.3 Go-Live – Cut-Over – Business Downtime - pág.: 16
3.3.4 NZDT High-Level Project Plan - pág.: 17
4 Impact on Business - pág.: 19
4.1 Soft Freeze - pág.: 19
4.2 Hard Freeze - pág.: 19
5 Risk Estimation - pág.: 21
5.1 Risk Resulting from NZDT - pág.: 21
5.1.1 Risk During Recording - pág.: 21
5.1.2 Risk During On-line Delta Replay - pág.: 21
5.1.3 Restricted Availability of Some Functions - pág.: 21
5.2 Risk Reduction Through NZDT - pág.: 21
6 Applicability - pág.: 23
6.1 Near Zero Downtime – Use Cases - pág.: 23
6.2 Near Zero Downtime – Reusability - pág.: 23
7 Near Zero Downtime Methods for Further SAP Products - pág.: 26
7.1 Near Zero Downtime Maintenance for PI (Pilot) - pág.: 26
7.2 Near-Zero Downtime Maintenance for Portal (Pilot) - pág.: 28
Cómo descargar documento NZDT
Muy fácil y rápido, sigue estos pasos:
- Unirte a la lista #1 de SAP +1, sumate ahora!
- Dale "me gusta" a nuestra página de Consultoria-SAP en Facebook.
Y no te olvides de seguirnos en las redes sociales para no perderte ninguna novedad: - Copia la URL de éste artículo, e ingresa al foro de Ayuda SAP en español, ve a la parte de Manuales-SAP, y abre un tema nuevo explicando por qué te interesa aprender más sobre SAP, pega ahí la URL que has copiado, para que sepamos que estás cumpliendo estos tres puntos.
Recuerda que en nuestra comunidad de Ayuda SAP no es solo "pedir" y nada más, lee las normas de solicitudes que tendrás que cumplir para descargar gratis.
No te pierdas los beneficios de ser VIP en Consultoria-SAP
Aprendiendo más hoy sobre SAP BASIS y buscando información sobre la transacción SE93 de SAP, que por lo general la usamos para que nos indique qué programas (y con qué parámetros) se ejecutan transacciones desarrolladas -no estándar, llegué a la siguiente consulta:
