Hello community,
this is my first blog post overall and also my first blog post relating the transformation to SAP S/4HANA. Today I want to show you the findings of my master thesis research on how to accomplish accurate effort estimation. I want to show it using the custom code migration as an example.
Introducción
Moving to SAP S/4HANA towards digital transformation is still one of the major challenges. One of the major challenges that accompanies the SAP S/4HANA migration is providing an accurate effort estimation. The effort estimation is required by different stakeholders for example customers, solution architects and project managers. It’s a key point in every transformation.
Desafío principal
¿Alguna vez te has preguntado cómo puedes realizar adecuadamente una estimación de esfuerzo para la migración a SAP S/4HANA, especialmente la migración de código personalizado?
En la publicación de SAP –
Extensiones personalizadas en Implementaciones de SAP S/4HANA Una guía práctica para líderes de TI senior
– (Página 34) puedes encontrar el siguiente pasaje:
“Ningún proyecto de conversión escapa al debate sobre la estimación del esfuerzo para la adaptación del código personalizado, que, por supuesto, debe ser lo más precisa posible” (Página 34)
Por supuesto, la adaptación del código personalizado en un proyecto de transformación no sucede por sí sola. Además, el proyecto de transformación completo debe considerarse en la estimación del esfuerzo. Pero, ¿cómo puedes realizar una estimación precisa del esfuerzo? Quiero mostrarte mi enfoque.
Cómo no hacerlo
He basado mi investigación en la práctica/experiencia y en la experiencia de SAP (por ejemplo
Extensiones personalizadas en Implementaciones de SAP S/4HANA Una guía práctica para líderes de TI senior)
.
SAP señala que los modelos de estimación de esfuerzo más sofisticados que tuvieron en cuenta la cantidad y variabilidad de hallazgos, complejidad del código y habilidades de los desarrolladores, aún se equivocaron.
En cambio, SAP sugiere pedir a los miembros de tu equipo que estudien las notas de SAP que describen el impacto del código personalizado (la lista se puede encontrar en la herramienta SAP Readiness Check) y permitirles dedicar una o dos semanas trabajando en algunos de los hallazgos en el código. Después de eso, pídeles una estimación de rango. La respuesta que recibas será mucho más precisa que el resultado del modelo de estimación más sofisticado. Además, SAP tiene algunos consejos prácticos. Primero, es útil distinguir entre las correcciones de código técnico puramente y las que requieren conocimiento de la aplicación. El primero puede ser realizado por un desarrollador ABAP generalista, mientras que el segundo requiere que tus arquitectos funcionales investiguen el asunto primero y podría llevar a solicitudes de desarrollo nuevas. Segundo, los equipos de desarrollo de cualquier tamaño pueden volverse mucho más eficientes si los miembros individuales se especializan en cambios de código particulares (es decir, un conjunto de notas de SAP).
Cómo deberías hacerlo
Basado en la sugerencia de SAP y el intercambio con diferentes Desarrolladores ABAP y Consultores SAP, he creado un modelo/método para cumplir con el requisito de una estimación precisa del esfuerzo. Me gustaría usar la migración de código personalizado (CCM) como ejemplo para explicar cómo funciona.
Proyecto de transformación SAP S/4HANA - metodología de estimación del esfuerzo
El nivel de consideración son los elementos de simplificación de CCM determinados en la fase de preparación y no los hallazgos individuales u objetos ABAP (como sugiere SAP). Además del ítem de simplificación, hay otras tareas que no están descritas por un ítem de simplificación. Por lo tanto, la agrupación del ítem de simplificación (notas de SAP) y tareas adicionales se basa fundamentalmente en el aspecto de la
tarea
a realizar.
En este nivel, las tareas son procesadas por las personas responsables. El análisis detallado aclara el alcance de la tarea y las actividades requeridas para ello. También se identifica el número de hallazgos por tarea, lo que permite evaluar los cambios necesarios (
criterios
).
Debe utilizarse una
combinación de métodos
para utilizar un proceso iterativo para acercarse a una estimación de costos lo más realista posible. Basado en los hallazgos de la persona responsable de la tarea, se realiza una estimación del tiempo y los recursos necesarios para corregir los hallazgos. Este proceso puede repetirse cualquier cantidad de veces por diferentes expertos para cada tarea, siempre que la estimación necesite ser más precisa (ver método de Delphi). Esto evita una gran variación en la estimación. También se discuten nuevamente los aspectos que pueden no