Prácticas recomendadas para la fase de planificación

Durante la fase de planificación de una implementación desde cero de SAP, el proyecto suele enfrentarse a varios desafíos y oportunidades. En esta sección se analizan cinco aprendizajes clave basados en SAP sobre implementaciones totalmente AWS nuevas en las que ha participado el equipo de Servicios AWS Profesionales. Puede implementar algunas de estas recomendaciones incluso antes de que comience un proyecto o de que el equipo de consultoría se involucre. Brindar borradores de documentos, como la matriz de funciones y responsabilidades o la lista de contactos del equipo, ayuda a acelerar el proceso de puesta en marcha.

Crear una matriz RACI

Crear una matriz de asignación de responsabilidades para el equipo de infraestructura es fundamental para cualquier proyecto de implementación. Esta matriz adopta la forma de un gráfico integral responsable, confiable, consultado e informado (RACI). RACI se utiliza para aclarar las funciones, las asignaciones y las tareas en una estructura de equipo compleja. Debe desarrollarse en colaboración con el equipo de AWS SAP Cloud, el equipo de SAP Basis, el integrador de sistemas (SI) de SAP y el cliente. Esto lo puede impulsar cualquiera de esos grupos o un administrador de proyectos. Crear una RACI sin la participación de estas partes interesadas crea inconsistencias, brechas y, a veces, incluso conflictos. Es importante tener en cuenta todas las fases del proyecto. Contar con la RACI por adelantado fortalece la colaboración entre todas las partes involucradas y permite tener claridad. Lo ideal es que la RACI se complete antes del inicio del proyecto.

El siguiente es un fragmento de un ejemplo de matriz RACI para un proyecto de implementación desde cero de SAP.

Descargar la matriz RACI completa

Revise el SoW

Comprenda todos los elementos de la declaración de trabajo (SoW) para los servicios de AWS consultoría y asesoramiento, y revise la SoW conjuntamente con las principales partes interesadas para que todos entiendan claramente los resultados. Si el equipo de infraestructura tiene la intención de hacer más de lo que define la SoW, asegúrese de documentarlo en el registro de riesgos, suposiciones, acciones, problemas, dependencias y decisiones (RAAIDD). En un proyecto de implementación de SAP totalmente nuevo, es de suma importancia mantenerse ágil y ágil, por lo que es habitual desviarse de la SoW. Sin embargo, las expectativas pueden oscurecerse si el socio de AWS implementación comienza a ofrecer más de lo que está documentado. Cuando se produzcan cambios, debe mantener una lista actualizada del nuevo alcance del trabajo y de las posibles compensaciones que haya que hacer. Para adoptar un enfoque de proyecto en cascada, se debe definir e implementar un proceso de administración del cambio de alcance. En el caso de un proyecto ágil, un proceso de priorización de las tareas pendientes es más apropiado para administrar el alcance.

Consideraciones:

• A medida que avance el proyecto, asegúrese de captar el nuevo alcance y definir los nuevos resultados. Esto ayudará a gestionar las expectativas y a buscar ayuda para priorizar las tareas pendientes.

• Identifique y priorice los cambios y las tareas de la documentación junto con la entrega de tareas pendientes, de modo que la documentación se produzca durante toda la vida del proyecto, no solo en el final.

• Realice un recorrido periódico de SoW a lo largo del proyecto para mantenerse al día con los objetivos y las prioridades.

• Para la transición a la producción, asegúrese de que se apruebe una SoW con acceso de solo lectura con al menos 12 meses de antelación para facilitar el hipercuidado.

Crear un organigrama del equipo y una lista de contactos

Cree un organigrama general que describa los equipos y la estructura de liderazgo. Profundice más y desarrolle una lista de contactos para todos los equipos que incluya el nombre, el cargo y la función de todos los miembros del equipo de infraestructura y los puntos de contacto clave para diversas funciones, como las operaciones de seguridad, red y firewall, Microsoft Active Directory, las operaciones internas en la nube y las operaciones de servidor. Todos deberían saber quiénes participan y qué rol desempeñan en el proyecto. Los retrasos y los errores de comunicación se producen inevitablemente cuando el equipo no dispone de esta información. También es importante comprender los cargos de las partes interesadas. Por ejemplo, no querrá invitar a los directivos a las sesiones de trabajo sobre diseño o a las reuniones de pie diarias, a menos que sean personas clave para esos debates. Conocer los cargos y funciones permite invitar a las personas adecuadas a las reuniones importantes. Poder visualizar los equipos en un organigrama ayuda a comprender cómo están estructurados los equipos y cómo trabajan juntos en el proyecto.

El siguiente diagrama proporciona un ejemplo de un organigrama típico de SAP sobre infraestructura. AWS

Establecer un modelo de compromiso con el equipo interno en la nube

Si su organización de TI tiene un equipo de AWS nube interno, debe establecer un modelo de compromiso con ese equipo y aclarar el trabajo que desempeñará, en comparación con lo que debe hacer el socio de AWS implementación (por ejemplo, el AWS socio o los servicios AWS profesionales). Una responsabilidad clave para tener en cuenta es el soporte de los entornos una vez creados y entregados. Por ejemplo, si solo hay dos arquitectos de AWS SAP Cloud que están creando una infraestructura de múltiples paisajes y entornos para una docena de aplicaciones de SAP, no tendrán el ancho de banda necesario para soportar el entorno que terminan de crear y construir nuevos entornos al mismo tiempo. Una opción es pedir al equipo interno en la nube que se encargue del soporte de los entornos terminados. Esto brinda al equipo interno la oportunidad de aprender y hacerse cargo de los entornos. Con el tiempo, serán responsables del mantenimiento y la expansión de estos entornos, cuando el proyecto avance y se identifique el alcance de un nuevo de trabajo.

La infraestructura de nube interna y DevOps los equipos de nube también deberían ponerse de acuerdo sobre el tipo de software de automatización que se utilizará, por ejemplo, si utilizar Terraform AWS CloudFormation o Terraform como una herramienta de infraestructura como código (IaC). Del mismo modo, podrían decidir utilizar AWS Systems Manager Ansible para tareas de configuración, como el arranque de volúmenes y, posiblemente, de instalaciones de SAP. Estas decisiones deben registrarse. Además, si se requiere un panel de monitoreo y observabilidad de terceros, pero este no estaba incluido en la SoW, considere la posibilidad de colocar enlaces de monitoreo y registro mediante Amazon y CloudWatch Amazon Simple Notification Service (Amazon SNS) mientras tanto. Más adelante, el equipo interno en la nube puede implementar la integración con una solución de monitoreo de terceros.

El modelo de contratación o el acuerdo de soporte también deberían formar parte de la matriz de la RACI y estar articulados en la SoW. Existe un nivel significativo de automatización que se puede lograr mediante el uso AWS de los servicios. La matriz de SoW y RACI debe identificar lo que se debe lograr como parte del nuevo proyecto de implementación de SAP y lo que se puede delegar en el equipo de operaciones.

Al establecer un modelo de compromiso, determine si el método clave para avanzar será un enfoque en cascada, ágil o mixto. AWS Los servicios profesionales observaron un aumento del 300 por ciento en la finalización de las tareas y una reducción del 94 por ciento en el tiempo de planificación en las contrataciones que implementaban un enfoque ágil o mixto en comparación con un enfoque en cascada. En la fase de planificación, también debe seleccionar un plan de comunicación y un enfoque de herramientas con la ayuda del cliente. La siguiente tabla muestra un ejemplo de plan de comunicación.

Por último, asegúrese de identificar al cliente y al equipo de SAP Basis que apoyará el proyecto desde el principio. Capacitarlos a medida que se implementan y migran nuevas soluciones es clave para iniciar las sesiones de transferencia de conocimientos con antelación.

Documentar el proceso de creación e implementación de la nube

Si la organización de TI tiene un equipo interno en la nube, ese equipo debe registrar el proceso de creación e implementación de la nube mediante diagramas de flujo de procesos y compartirlos con todo el equipo. Es importante que las principales partes interesadas detecten fácilmente cualquier obstáculo o ineficiencia en el proceso y comprendan el papel que desempeñan los procesos internos actuales a la hora de generar ineficiencias o retrasos. En el siguiente ejemplo, puede ver cómo los procesos de unión a Active Directory y de actualización del Sistema de nombres de dominio (DNS) tardan más en completarse. Observar esta imagen podría motivar a los equipos a colaborar y a descubrir cómo reducir el tiempo de ese paso del proceso.

Consideraciones:

• Registre el proceso y el flujo de trabajo de la mesa de ayuda por separado, comparta esta información con el equipo de infraestructura y asegúrese de que todos tengan acceso a las herramientas de la mesa de ayuda para que no dependan de una sola persona. A menudo, el proceso de los tiques de uniones a Active Directory, las actualizaciones del DNS, la apertura de firewalls y la solicitud de claves de cifrado pueden ser complejos y lentos. Es fundamental registrar estos procesos y tener en cuenta el acuerdo de nivel de servicio (SLA) de cada equipo en la fase de planificación del proyecto. Esto también ayuda a explicar los motivos de un retraso o un obstáculo cuya eliminación requiere una atención especial.

• Asigne un punto de contacto designado para las tareas de Active Directory y de firewall o redes. Esos recursos exclusivos deben formar parte del proyecto. Si tiene que confiar en los tiques de servicio, no puede controlar el SLA del servicio.

Hojas de ruta del proyecto y registro de hitos

Los siguientes gráficos proporcionan un ejemplo de hoja de ruta para un proyecto plurianual de SAP sobre AWS nuevas instalaciones.

El siguiente gráfico muestra ejemplos de plazos de contratación con los Servicios AWS Profesionales para el mismo proyecto.

El siguiente gráfico muestra un registro de los hitos de la puesta en marcha de este proyecto.