Planificación de la asignación de recursos en proyectos SAP

Planificar la asignación de recursos en un proyecto SAP significa decidir qué roles necesita, en qué fase de SAP Activate, cuántas horas a la semana, y comprobar luego cada semana si la realidad sigue coincidiendo. Asigne personal por rol, no por número genérico de personas. Ajuste el plan a la curva de la fase: perfiles funcionales en Explore, técnicos en Realize, datos, Basis y cambio en Deploy. Confirme la disponibilidad por escrito con los jefes de línea. Esta guía es para directores de programa, PMO y CIO que construyen o rescatan un plan de recursos de S/4HANA. Use las tablas de FTE y los rangos de tarifa diaria que siguen como referencias de partida.

He visto a decenas de implementaciones tropezar con los mismos problemas de recursos. El plan da por supuesta una estabilidad que desaparece en cuanto empieza la ejecución.

Una vez vi a un equipo perder una semana entera porque nadie se había dado cuenta de que el responsable de seguridad tenía vacaciones y formación seguidas. No se señaló, no se registró y retrasó nueve días una revisión crítica de accesos al sistema.

La mayoría de los planes de SAP se apoyan en estimaciones ordenadas, disponibilidad a tiempo completo y flujos de trabajo predecibles. Esa versión del mundo rara vez sobrevive al primer mes de Realize.

Planifico en torno a tres cosas: lo que el trabajo exige realmente, lo que las personas disponibles entregarán realmente y qué cambia cuando la realidad difiere del plan. Un plan que se sostiene cubre seis dimensiones:

1. Personas por rol y por fase de Activate. No una asignación plana. Explore no se parece en nada a Realize.
2. Horas por semana confirmadas por el jefe de línea. Por escrito, no supuestas.
3. Compromisos simultáneos por persona. Alguien listado al 100 % que además cubre el soporte de producción entregará mucho menos.
4. Suplente para cada rol de la ruta crítica. La formación cruzada no es opcional en un programa de 18 meses.
5. Dependencias entre flujos de trabajo. Cada una con un responsable con nombre, una fecha límite y una vía de escalado, visible el día en que se retrasa.
6. Cadencia de actualización. Semanal en las fases activas. El plan del kick-off es la versión uno.

Los planes fallan cuando quien planifica usa roles genéricos de TI. SAP exige una especialización funcional y técnica concreta. El conjunto estándar para un programa S/4HANA:

Dirección del programa. Director del programa, responsable de la PMO y arquitecto de soluciones. El arquitecto responde de la coherencia del diseño entre módulos.

Consultores funcionales. Un líder por cada módulo del alcance: Contabilidad financiera (FI), Controlling (CO), Gestión de materiales (MM), Ventas y distribución (SD), Planificación de la producción (PP), Extended Warehouse Management (EWM), además de Gestión del capital humano (HCM), Mantenimiento de planta (PM) y Sistema de proyectos (PS) cuando estén en el alcance. Si todavía usa el Warehouse Management (WM) clásico, planifique el cambio: los derechos de uso del compatibility pack en S/4HANA on-premise terminaron a finales de 2025.

Consultores técnicos. Desarrolladores ABAP para informes, interfaces, conversiones, ampliaciones, formularios y flujos de trabajo (RICEFW), y para extensiones clean core sobre API liberadas o SAP BTP. Especialistas en integración para SAP Integration Suite (Cloud Integration, antes CPI), SAP Process Orchestration donde todavía funciona y cualquier middleware de terceros.

Plataforma. Consultores Basis para HANA, parches del kernel, transportes, copias de sistemas y ajuste del rendimiento. Consultores de seguridad para el diseño de roles, el análisis de segregación de funciones y SAP GRC Access Control cuando esté en el alcance.

Datos. Especialistas en migración que usan la aplicación «Migrate Your Data» de SAP S/4HANA Migration Cockpit (la transacción LTMC, más antigua, está obsoleta), el Migration Object Modeler para objetos a medida y SAP Data Services para transformaciones complejas. Mi guía sobre por qué fracasa la migración de datos de SAP explica por qué este equipo tiene que empezar antes de lo que permiten la mayoría de los planes.

Cambio. Líder de cambio, líder de formación y responsable de la preparación del negocio. Suele haber poco personal, porque la necesidad solo se hace visible en Deploy.

Lado del cliente. Analistas de negocio (uno por módulo principal), responsables de proceso (uno por dominio de proceso) y probadores procedentes de operaciones para UAT.

Tratar estos perfiles como casillas intercambiables es el error de planificación más común. Un consultor senior de FI no puede dirigir una sesión de diseño de SD. Un desarrollador ABAP junior no puede diseñar la arquitectura de una integración. Para las responsabilidades rol por rol, consulte mi lista de roles esenciales del equipo de implementación de SAP.

La demanda de recursos no es plana. Las fases de Activate crean curvas predecibles que una asignación plana no recoge.

Prepare (normalmente semanas 1 a 4). Ligera. Director del programa, arquitecto y un líder por módulo para definir el alcance. Los usuarios de negocio confirman el alcance. Basis y seguridad inician la preparación de los entornos.

Explore (normalmente meses 2 a 5). Mucha carga en consultores funcionales y usuarios de negocio, con los talleres de diseño marcando el calendario. ABAP e integración, poca hasta que se toman las decisiones de diseño. Basis prepara los sistemas sandbox y de calidad.

Realize (normalmente meses 5 a 12). Mucha carga en perfiles técnicos: configuración, construcción, pruebas unitarias y de integración. La carga de ABAP alcanza su pico. Los usuarios de negocio se suman a los ciclos de pruebas. El equipo de datos construye los objetos de migración y ejecuta ensayos.

Deploy (normalmente meses 12 a 14). Mucha carga en migración de datos, Basis, seguridad, cambio y formación. Las UAT consumen capacidad del negocio. Los ensayos de cutover requieren equipos en el mismo lugar. Empieza la planificación del hypercare.

Run (desde el mes 14; el hypercare suele durar de 30 a 90 días). Un equipo central reducido y mucha cobertura de soporte. Basis y la gestión de aplicaciones aumentan mientras los consultores se retiran.

Si trata estas fases como ventanas de igual demanda, sobredimensionará Prepare, infradimensionará Realize y se quedará corto en migración de datos en Deploy. La curva de fases es la forma más importante del plan.

1. PrepareUnos 11 FTESemanas 1 a 4. Los líderes definen el alcance, Basis prepara el entorno
2. ExploreUnos 36 FTEMeses 2 a 5. Perfiles funcionales y usuarios de negocio
3. RealizeUnos 56 FTE, el picoMeses 5 a 12. Construcción, y la carga de ABAP alcanza su pico
4. DeployUnos 42 FTEMeses 12 a 14. Datos, Basis, seguridad, cambio
5. RunUnos 12 FTEDesde el mes 14. El hypercare suele durar de 30 a 90 días

Emergencias constantes. Cuando el equipo siempre está apagando fuegos, el plan ha dejado de predecir la realidad. Una sola ausencia no debería poder descarrilar un flujo de trabajo.

Los usuarios de negocio desaparecen cuando se los necesita. Las sesiones de diseño y las UAT se paralizan porque los usuarios de negocio no están disponibles. Es una de las fuentes de retraso más comunes. La causa casi siempre es la misma: el tiempo se dio por supuesto, no se comprometió formalmente. La presión operativa gana siempre que el compromiso no se formalizó.

Perfiles técnicos repartidos entre demasiadas tareas. El trabajo de Gerald Weinberg sobre la gestión del software estimó que quien se reparte entre tres proyectos entrega en torno al 60 % de su capacidad total, y el resto se pierde en los cambios de contexto. El resumen de la American Psychological Association sobre la investigación del cambio de tareas recoge una pérdida del mismo orden de magnitud: los breves bloqueos mentales al pasar de una tarea a otra pueden costar hasta el 40 % del tiempo productivo. El plan parece eficiente. El resultado no.

La ruta crítica cambia cada semana. Las reorganizaciones constantes, los flujos de trabajo que arrancan tarde y los cambios de prioridad semanales suelen remontarse a un alcance poco claro o a dependencias mal secuenciadas. Arregle el alcance antes de arreglar el plan de recursos.

1. Disponibilidad falsa. Alguien listado al 100 % que además se ocupa del cierre mensual y del soporte de producción. Pregunte cuántas horas a la semana, en qué más trabaja y si su jefe de línea lo ha confirmado por escrito.
2. Roles compartidos sin límites. Una persona que hace a la vez diseño de la solución, pruebas y gestión del cambio. Reparta las responsabilidades por tarea, no por cargo, y no haga nunca crítica a una misma persona en dos sitios a la vez.
3. Falta de tiempo de los usuarios de negocio. Los talleres se retrasan y las aprobaciones de UAT tardan semanas más. Consiga que el tiempo quede comprometido por escrito y firmado por el jefe de departamento, controle la asistencia y escale pronto los patrones.
4. Sin margen. Una ausencia paraliza un flujo de trabajo. Construya margen a nivel de tarea, no solo de fase, y forme de manera cruzada al menos a una persona en cada rol central.
5. Un plan que nunca se actualiza. Se construye en el kick-off y nunca se revisa. Revíselo cada semana durante la ejecución, vincúlelo a las puertas de fase y actualícelo cuando la realidad cambie.

Empiece por la disponibilidad confirmada. Hable con los jefes de línea antes de que arranque el proyecto. Confirme las horas por semana y los demás compromisos, y documéntelos. Cuando la disponibilidad cambie a mitad del proyecto, esa línea base es su fundamento para escalar.

Moldéelo por fases. La carga de un desarrollador ABAP en Explore difiere de la de Realize. Los usuarios de negocio alcanzan su pico en Explore, por el diseño, y en Deploy, por las UAT. Una asignación plana parece equilibrada sobre el papel y fracasa sobre el terreno.

Mapee las dependencias de forma explícita. La migración de datos alimenta las pruebas de integración, que alimentan las UAT, que impulsan el cutover. Dé a cada dependencia un responsable, una fecha y una alerta, para que un retraso sea visible el mismo día.

Proteja el tiempo de los usuarios de negocio a nivel del comité directivo. Su trabajo diario continúa. Sin una aprobación explícita de su dirección sobre las horas por semana, abandonarán el proyecto cuando llegue la presión operativa. El patrocinador, no el director del proyecto, debería pedir ese tiempo a los jefes de departamento.

Actualice el plan cada semana. Un plan sin tocar durante dos semanas probablemente está mal. Compare la utilización real con la planificada. Alguien al 120 % durante dos semanas seguidas es una señal de que está sobrecargado o de que el plan está mal.

Son rangos indicativos de plantilla y de tarifas para usar como referencias de partida. El sector, el alcance, la geografía y el socio los mueven. Use las tablas como comprobaciones de sensatez, no como cotizaciones.

Brownfield de mercado medio (de 5 a 15 millones de dólares, unos 12 meses)

Alcance típico: una sola entidad jurídica o un grupo pequeño, tres o cuatro módulos (normalmente FI, CO, MM, SD), procesos estándar y desarrollo a medida limitado.

Flujo de trabajo	Prepare	Explore	Realize	Deploy	Run
Director del programa	1	1	1	1	0,5
Arquitecto de soluciones	1	1	1	0,5	0
Consultores funcionales (FI/CO, MM, SD más uno)	1	4	4	2	1
ABAP y técnicos	0	1	3	1	0,5
Integración	0	0,5	2	1	0,5
Basis	0,5	0,5	1	2	1
Seguridad y autorizaciones	0	0,5	1	1,5	0,5
Migración de datos	0	1	2	3	0
Responsable de pruebas	0	0,5	1	1	0
Cambio y formación	0,5	1	1	2	0,5
Analistas de negocio del cliente	1	4	3	2	1
FTE total máximo	5	14	20	17	5

Brownfield empresarial (de 30 a 80 millones de dólares, de 15 a 18 meses)

Alcance típico: varias entidades, de seis a nueve módulos, integración compleja, desarrollo a medida significativo y varios despliegues por país.

Flujo de trabajo	Prepare	Explore	Realize	Deploy	Run
Director del programa y PMO	2	2	3	3	1
Arquitectos de soluciones (líder más de módulo)	2	3	3	1,5	0,5
Consultores funcionales (todos los módulos del alcance)	2	10	12	5	2
ABAP y técnicos	0	3	8	3	1
Integración y middleware	0,5	2	5	2	1
Fiori y UI5	0	1	3	1	0,5
Basis	1	1	2	4	2
Seguridad y GRC	0,5	1,5	2	3	1
Migración de datos	0	2	5	6	0,5
Pruebas	0,5	1	3	4	0
Cambio y formación	1	2	3	5	1
Analistas de negocio del cliente	2	8	7	5	2
FTE total máximo	11	36	56	42	12

Tarifas diarias por rol y región (2024 a 2025)

Son tarifas facturadas por el socio por especialista, no salarios. La tarifa combinada del programa suele resultar entre un 30 y un 50 % inferior a la tarifa onshore senior, porque la mayoría de los programas mezclan arquitectos onshore con ejecución offshore.

Rol	Onshore EE. UU./Reino Unido/Alemania	GCC (EAU/Arabia Saudita)	Nearshore (LatAm/Europa del Este)	Offshore (India)
Arquitecto de soluciones (senior)	2.000 a 3.500 USD	1.500 a 2.500 USD	900 a 1.500 USD	500 a 1.000 USD
Consultor funcional (senior)	1.500 a 2.800 USD	1.200 a 2.000 USD	700 a 1.400 USD	300 a 700 USD
Consultor funcional (intermedio)	1.000 a 1.800 USD	800 a 1.400 USD	500 a 900 USD	200 a 500 USD
ABAP y técnico (senior)	1.400 a 2.500 USD	1.000 a 1.800 USD	600 a 1.200 USD	300 a 700 USD
Especialista en integración	1.500 a 2.800 USD	1.100 a 1.900 USD	700 a 1.300 USD	350 a 800 USD
Basis	1.400 a 2.200 USD	1.000 a 1.800 USD	600 a 1.100 USD	300 a 700 USD
Seguridad y GRC	1.500 a 2.500 USD	1.100 a 1.900 USD	700 a 1.300 USD	350 a 800 USD
Migración de datos	1.300 a 2.200 USD	1.000 a 1.700 USD	600 a 1.100 USD	300 a 700 USD
Líder de cambio y formación	1.200 a 2.000 USD	900 a 1.500 USD	500 a 1.000 USD	250 a 600 USD
Consultor junior (cualquier rol)	800 a 1.400 USD	500 a 900 USD	400 a 700 USD	150 a 350 USD

El reparto entre onshore, nearshore y offshore

La mayoría de los programas SAP combinan regiones. Es una decisión de costo frente a velocidad, no una decisión binaria.

Los programas del sector privado de EE. UU. suelen funcionar con entre un 30 y un 60 % onshore por FTE. El onshore se concentra en arquitectura, cambio, análisis de negocio y perfiles funcionales senior, donde importa la cercanía con el negocio. El offshore se concentra en ABAP, construcción de integración y ejecución de la migración de datos, donde el trabajo es más fácil de especificar. Los programas del gobierno federal de EE. UU. suelen ser totalmente onshore, con restricciones de personal estadounidense (US-person), según la carga de trabajo.

Los programas del GCC suelen funcionar con entre un 60 y un 70 % onshore, porque las normas locales de contratación y los requisitos de idioma árabe elevan esa proporción. El trabajo offshore se inclina hacia los centros del sur de Asia por la coincidencia de husos horarios. Los programas europeos varían: la manufactura suele rondar el 50 % onshore, mientras que el sector público y los sectores regulados suben más por razones de residencia de datos.

Un error común es optimizar el reparto solo por costo. Un equipo con un 80 % offshore y un 20 % de arquitectos onshore parece barato en la hoja de cálculo. Los costos ocultos son el ciclo diario de traspasos y los talleres de diseño más lentos, sin contexto de negocio. El equipo más barato rara vez entrega el programa más barato. Cuando compare socios, mi guía de socios de implementación de SAP por nivel explica cómo difieren entre ellos las tarifas y la composición del equipo.

Un plan construido una vez y nunca reexaminado no es un plan. Trate cada supuesto como una hipótesis que hay que probar en la primera semana de ejecución, y en cada semana posterior.

¿Qué es la planificación de la asignación de recursos en proyectos SAP y por qué importa?

Es decidir qué personas necesita el proyecto, cuándo y con cuánto de su tiempo, y después comprobar si eso coincide con la realidad.

Los proyectos SAP dependen de personas concretas: el líder de FI/CO que entiende su plan de cuentas, el especialista en migración que conoce sus datos heredados, el líder de cambio con relaciones en el negocio. Cuando no están disponibles en el momento justo, el trabajo se detiene o se hace mal. Muchos retrasos que parecen técnicos son en realidad problemas de recursos.

¿Cómo causa retrasos en los proyectos SAP una mala asignación de recursos?

Por las dependencias. Un líder de configuración es reasignado a otro proyecto en Realize. Su trabajo se detiene, lo que retrasa las pruebas de integración, luego las UAT y después la preparación del cutover. Una ausencia de dos semanas en la semana ocho puede convertirse en un retraso de seis semanas en el go-live.

Los pequeños huecos del principio se convierten en grandes retrasos al final. Cuando el impacto se hace visible, la recuperación cuesta varias veces lo que habría costado una corrección temprana.

¿Cómo consigo que los usuarios de negocio se comprometan con un proyecto SAP cuando tienen su trabajo diario?

Obtenga un compromiso por escrito de su jefe de línea antes de que empiece el proyecto: horas por semana, qué fases los necesitan más y qué aprobación se requiere si cambia la disponibilidad.

Controle su asistencia como la de cualquier otro recurso. Cuando baje, escale a nivel del comité directivo. Los jefes de departamento pueden hacer cumplir el compromiso; el equipo del proyecto no.

¿Cómo debo gestionar la salida de una persona clave a mitad del proyecto?

Evite los puntos únicos de fallo desde el principio: al menos otra persona debería entender cada flujo de trabajo crítico lo bastante bien como para mantenerlo en marcha.

Cuando alguien se va, recoja de inmediato lo que sabe: decisiones no documentadas y la justificación de la configuración. A menudo eso es más difícil que encontrar un sustituto. Para el relevo, un documento de traspaso, sesiones grabadas y una semana de solapamiento son el mínimo.

¿Cuándo debo escalar un problema de recursos?

Antes de lo que resulta cómodo. Escale cuando el responsable de una dependencia con nombre lleva más de una semana sin estar disponible, un usuario de negocio sigue faltando a las sesiones, un recurso técnico supera el 120 % de utilización durante dos semanas o un flujo de trabajo está bloqueado por una decisión de dotación aplazada.

El costo de escalar demasiado pronto es una conversación incómoda. El costo de escalar demasiado tarde son semanas de retraso.

¿Cómo deben gestionarse los recursos compartidos entre varios proyectos?

Dé por hecho que las personas compartidas priorizarán otra cosa cuando llegue la presión. Acuerde horas concretas por semana con su responsable principal, incorpore margen en el trabajo que depende de ellas y manténgalas fuera de su ruta crítica salvo que tenga un plan alternativo.

En el caso de los usuarios de negocio compartidos, la petición tiene que venir del patrocinador. Un director de proyecto que pide tiempo a un jefe de departamento perderá siempre frente a las prioridades operativas.