Roles y responsabilidades esenciales del equipo de implementación de SAP

Una implementación de SAP necesita ocho roles con responsables concretos y dedicados: patrocinador ejecutivo, director de proyecto, líderes funcionales, líder de TI, líder de migración de datos, líder de gestión del cambio, socio de implementación y un asesor independiente del programa. RISE with SAP suma los contactos de entrega de la propia SAP y hace explícita la responsabilidad sobre el clean core. Esta guía es para patrocinadores y directores de programa que están formando un equipo o reparando uno. Explica qué responsabilidad tiene cada rol, qué se rompe cuando falta, qué tamaño de equipo corresponde a cada tamaño de empresa y cómo construir el Centro de Excelencia (CoE) antes del go-live. Empiece por comprobar cuál de los ocho roles lo ocupa alguien que además tiene un trabajo diario. Ese es su mayor riesgo.

He trabajado con decenas de equipos SAP a lo largo de los años. He visto proyectos bien financiados y con proveedores experimentados fracasar porque faltaban roles clave o estaban repartidos entre personas con otros trabajos. También he visto proyectos con poco presupuesto salir bien porque las personas adecuadas estaban en la sala, totalmente comprometidas y con responsabilidades claras.

Un minorista global con el que trabajé tenía presupuesto, respaldo de la dirección y SAP como ERP elegido. Pero su equipo de implementación era un desastre. Faltaban roles clave. Nadie era responsable de las decisiones críticas. La comunicación iba en todas las direcciones sin llegar a ninguna parte. Los plazos se retrasaron, los costos subieron y la confianza se desplomó.

Toda implementación de SAP necesita que estos roles estén cubiertos. El título importa menos que la responsabilidad.

1. Patrocinador ejecutivoDecisiones, financiación, escalamiento
   Asesor del programa ERPSupervisión independiente, riesgos, alineación con la dirección
2. Director de proyectoCronograma, presupuesto, coordinación

• Líderes funcionales y expertosDiseño de procesos, configuración de módulos
• Líder de TI y equipoIntegración, desarrollo, seguridad
• Líder de migración de datosCalidad de datos, secuencia de cargas, cutover
• Líder de gestión del cambioFormación, adopción, comunicación
• Socio de implementaciónArquitectura, diseño de integración, entrega

Rol	Responsabilidad principal	Qué se rompe sin él
Patrocinador ejecutivo	Decisiones estratégicas, financiación, autoridad de escalamiento	Deriva, disputas de alcance, nadie desempata
Director de proyecto	Cronograma, presupuesto, coordinación entre equipos	Retrasos, bloqueos sin resolver, sobrecostos
Líderes funcionales y expertos	Diseño de procesos de negocio, configuración de módulos	Configuración errónea, soluciones provisionales tras el go-live
Líder de TI y equipo	Integración, desarrollo, seguridad, rendimiento	Deuda técnica, interfaces rotas, inestabilidad
Líder de migración de datos	Calidad de datos, secuencia de cargas, precisión del cutover	Datos inutilizables, go-live fallido, meses de depuración
Líder de gestión del cambio	Formación, adopción, comunicación	Resistencia de los usuarios, hojas de cálculo paralelas
Socio de implementación	Arquitectura, diseño de integración, entrega	Sobreconstrucción, fallos de integración
Asesor del programa ERP	Supervisión independiente, riesgos, alineación con la dirección	Decisiones tomadas de forma aislada, errores evitables

Patrocinador ejecutivo

El patrocinador no es un nombre en una presentación del comité directivo. Toma las decisiones que nadie más puede tomar: presupuesto, cambios de alcance, compromisos de recursos entre departamentos. Cuando el rol es ceremonial, los proyectos van a la deriva.

Trabajé con una empresa que se saltó este rol. El proyecto se fue a la deriva. Sin decisiones, sin avances, con el dinero tirado.

Los patrocinadores eficaces se quedan durante todo el hypercare. Asisten a las sesiones mensuales del comité directivo después del go-live y toman las pequeñas decisiones que desbloquean asuntos atascados durante semanas. Mi guía para crear un comité directivo de SAP eficaz explica cómo estructurar ese foro.

Director de proyecto

El director de proyecto lleva el día a día: cronograma, registro de riesgos, coordinación, informes de avance. En un programa SAP grande es un puesto a tiempo completo para alguien que ya lo ha hecho antes.

Vi cómo un cliente perdía a su desarrollador principal a mitad de la implementación. Todo el proyecto se detuvo durante semanas mientras buscaba un reemplazo.

El problema contrario es igual de dañino. Trabajé con una empresa que tenía más de 30 personas en su equipo. Nadie sabía quién era responsable de las decisiones. Los cambios simples requerían cinco reuniones. El cronograma pasó de 12 a 18 meses solo por la sobrecarga de comunicación.

Líderes funcionales y expertos en la materia

Estas personas traducen las operaciones del negocio a configuración de SAP. Necesitan conocer el negocio lo bastante bien para cuestionar los procesos deficientes, y conocer SAP lo bastante bien para saber qué es posible.

Trabajé con un cliente de manufactura cuyo equipo destacó porque sus líderes funcionales pasaron tiempo en la planta antes de diseñar los procesos.

Los expertos que se comprometen a medias siempre dejan huecos. O el proyecto recibe su atención, o recibe su nombre en una hoja de aprobación. No es lo mismo.

Líder de TI y su equipo

El equipo de TI es responsable de la base técnica: desarrollo, Basis, seguridad, integración y rendimiento. En S/4HANA también es responsable de la disciplina de clean core, es decir, de mantener el código a medida fuera del núcleo.

La integración es lo que la mayoría de los equipos subestima. Cada conexión con un sistema externo hay que diseñarla, construirla, probarla y asignarle un responsable. Las interfaces se rompen en las UAT cuando nadie mapeó los flujos de datos. Incluya a TI en las sesiones de blueprint, no después de tomadas las decisiones.

Líder de migración de datos

Este rol se asigna tarde y con pocos recursos. Cuando aparecen los problemas de datos, el programa ya está bajo presión de calendario.

Un cliente creyó que podía saltarse la depuración de datos. Gran error. Su sistema fue inútil durante meses. Depurar los datos con un sistema en producción cuesta más que una depuración adecuada desde el principio.

Un líder de migración dedicado ejecuta conciliaciones en cada carga, y así es como los problemas estructurales salen a la luz antes del go-live. Eso no ocurre cuando el rol lo ocupa alguien con otros tres frentes de trabajo. Mi artículo sobre por qué fracasa la migración de datos de SAP y cómo corregirlo explica el método.

Líder de gestión del cambio

Es el rol al que con más constancia se le asignan pocos recursos. He visto sistemas de millones de dólares sin usar porque nadie quería cambiar su forma de trabajar.

Vi fracasar una implementación técnicamente perfecta porque a los usuarios no les gustó. La configuración era correcta y el diseño de procesos, sólido. Pero quienes lo usaban a diario no habían participado en el diseño. No entendían por qué las cosas habían cambiado y siguieron usando sus antiguos archivos de Excel.

Un cliente de retail tuvo éxito porque escuchó las preocupaciones de sus cajeros sobre el nuevo sistema y ajustó su enfoque.

El mínimo para un programa empresarial son dos personas dedicadas a la gestión del cambio. Una sola persona no puede cubrir a la vez el diseño de la formación, la comunicación, la gestión de la resistencia y el seguimiento de la adopción.

Asesor del programa ERP

Un asesor independiente no es el socio de implementación. Su trabajo es supervisar y corregir el rumbo: comprobar que la dirección sigue teniendo sentido, detectar riesgos que el equipo de entrega ve demasiado de cerca para apreciar, y cerrar la brecha entre lo que los directivos creen que ocurre y lo que ocurre de verdad.

He desempeñado este rol para clientes con equipos de entrega sólidos pero sin una voz independiente. Trabajé con un cliente de manufactura que casi implementa los módulos equivocados porque nadie había vinculado su estrategia de crecimiento con su hoja de ruta de SAP.

Detectar los problemas a tiempo es la otra mitad. Una vez identifiqué una brecha crítica de competencias en el equipo de datos de un cliente tres meses antes de que retrasara el go-live. La corregimos antes de que se convirtiera en una crisis.

El modelo de ocho roles sigue vigente. Hay tres cosas que conviene integrar en él en 2026.

Los contactos de entrega de SAP en RISE

En RISE with SAP en nube privada, SAP gestiona la infraestructura y las operaciones técnicas. Su documento de roles y responsabilidades establece que los clientes acuerdan los servicios con un SAP Cloud Architect Advisor, un Client Delivery Manager o el equipo del centro de atención al cliente de nube privada de SAP. Incluya en su equipo a quien SAP asigne, junto al equipo del socio, y designe a la persona de su lado que será responsable de esa relación. En instalaciones propias (on-premise), SAP es un proveedor de software y esto no se aplica.

Responsabilidad sobre el clean core y las extensiones

En S/4HANA Cloud Public Edition, el clean core se impone por diseño: las extensiones pasan por API publicadas, herramientas para usuarios clave o SAP BTP. En nube privada y on-premise todavía es posible hacer modificaciones, pero cada una dificulta las actualizaciones. Alguien tiene que ser responsable de esa línea.

En programas grandes, esa persona es un arquitecto de clean core o un líder de extensiones en BTP que depende del arquitecto de soluciones. En programas de mercado medio, el arquitecto de soluciones suele asumirlo, pero la responsabilidad debe quedar por escrito. Al evaluar socios, pregunte cuántas extensiones en BTP han entregado y pida ver ejemplos.

La IA cambia la productividad, no la responsabilidad

SAP Joule for Consultants (disponible con carácter general desde 2025) responde preguntas de configuración a partir de la base de conocimiento de la propia SAP y explica código ABAP. SAP Build Code genera código de extensión en Java y JavaScript en SAP BTP. Microsoft Copilot redacta resúmenes para el comité directivo e informes de estado.

Las mejoras se notan en los roles con mucho flujo de trabajo, como el análisis de requisitos, los informes de estado y el desarrollo a medida, y solo cuando las personas usan las herramientas de forma constante. Trate cualquier cifra de productividad que le citen como una afirmación que debe comprobar en su propio programa.

El equipo es algo más pequeño de lo que el mismo alcance requería antes de estas herramientas, pero no de forma drástica. Escriba las herramientas en las definiciones de los roles en lugar de tratarlas como una actividad aparte. La IA redacta más rápido. Las personas siguen siendo responsables de lo que dice el borrador.

La tabla muestra el dimensionamiento típico de cada rol según la escala de la empresa. Tómela como punto de partida y ajústela según el alcance y la geografía. Para la misma pregunta fuera de SAP, vea mi guía del equipo de implementación de ERP.

Rol	Pequeña empresa	Mercado medio	Gran empresa
Patrocinador ejecutivo	Director sénior	CIO o CFO	Alta dirección con comité directivo
Director de proyecto	1 a tiempo completo	1-2 a tiempo completo	Director de programa más directores de proyecto por frente de trabajo
Líderes funcionales	1-2 por módulo	Dedicados por módulo	Varios por módulo
Equipo de TI	2-3 (compartidos)	4-6 (dedicados)	8 o más especialistas
Migración de datos	1 líder	1 líder más analistas	Frente de trabajo dedicado
Gestión del cambio	1 como mínimo	2 como mínimo	3-5 dedicados
Líder de clean core o de extensiones en BTP	Arquitecto de soluciones	Arquitecto de soluciones	Rol dedicado
Contactos de SAP (RISE)	Un contacto designado	Un contacto designado	Contactos designados con revisiones trimestrales
Socio de implementación	5-10 consultores	15-25 consultores	30 o más con un director de programa

Las habilidades técnicas logran que el sistema se construya. La inteligencia emocional decide si la gente lo usa.

Trabajé con una empresa de manufactura en la que el jefe de almacén sonreía en las reuniones pero socavaba el proyecto a espaldas de todos. Un responsable de gestión del cambio atento detectó las señales a tiempo y lo convirtió en defensor del proyecto. Descubrirlo en el go-live habría sido mucho más difícil de arreglar.

El director de proyecto de un cliente era técnicamente brillante, pero no sabía adaptar su mensaje. Un CFO necesita una comunicación distinta que el personal de almacén. El resultado fue una adhesión baja en toda la organización y un go-live doloroso.

La respuesta a «¿empleados o consultores?» casi siempre es: ambos.

Los empleados conocen el negocio: los procesos, la política interna y las soluciones provisionales que nadie documenta. Trabajé con una empresa de manufactura cuyos empleados detectaron problemas de implementación que los consultores externos pasaron por alto por completo. Esas observaciones la salvaron de una configuración de almacén desastrosa.

A los empleados a menudo les falta experiencia en implementación. Un cliente de retail insistió en tener un equipo totalmente interno. A los seis meses iban desesperadamente retrasados, porque estaban aprendiendo SAP mientras lo implementaban.

Los consultores aportan reconocimiento de patrones. Incorporé a un consultor para un cliente que identificó de inmediato un enfoque de migración de datos que habría hecho fracasar su go-live.

El riesgo con los consultores es la transferencia de conocimiento. Si nadie dentro de la empresa aprende el sistema, los honorarios de consultoría siguen mucho después del lanzamiento.

El modelo que funciona: parejas de acompañamiento. Un cliente farmacéutico asignó a cada consultor una contraparte interna que será responsable de esa área después del go-live. El consultor entrega, la contraparte aprende y el conocimiento se queda. En torno a ese modelo, seis prácticas marcan la diferencia:

1. Forme el equipo antes de elegir el software. Un cliente compró módulos que su equipo no podía mantener, y siguieron seis meses de caos.
2. Dedique a las personas por completo. A tiempo parcial significa que el trabajo diario gana cuando llega la presión. He visto configuraciones críticas esperar semanas porque alguien estaba demasiado ocupado.
3. Reúna al equipo en el mismo lugar cuando sea posible. Un cliente de manufactura ahorró semanas de idas y venidas al poner a su equipo en la misma sala tres días a la semana.
4. Defina las vías de escalamiento desde el principio. Un cliente de retail tenía un documento de una página que mostraba exactamente cómo subían las decisiones por la cadena. Evitó incontables retrasos.
5. Escriba las decisiones con su justificación. Trabajé con una empresa que registraba qué decidía y por qué. Eso evitó discusiones interminables cuando se incorporaron nuevos directivos a mitad del proyecto.
6. Marque los hitos por el camino. Un cliente de manufactura celebraba eventos mensuales de reconocimiento. Algo pequeño, pero mantuvo alta la moral durante una implementación agotadora de 18 meses.

El error que cometen las empresas después del go-live es disolver el equipo de implementación. Justo entonces el CoE debe hacerse cargo de las mejoras, las actualizaciones, la gobernanza, la formación de nuevos usuarios y de mantener la configuración alineada con la forma en que el negocio funciona de verdad.

Planifíquelo durante la implementación. Tuve un cliente de manufactura que ignoró este consejo. Tres meses después del go-live, sus expertos clave en configuración se fueron. Nadie sabía cómo mantener lo que se había construido, y el sistema empezó a degradarse de inmediato.

Estos son los roles del CoE que conviene planificar desde los primeros meses de la implementación.

Rol del CoE	Responsabilidad principal
Director del CoE	Estrategia SAP, alineación con los objetivos del negocio, operación del CoE
Arquitecto de soluciones	Arquitectura, diseño de integración, gobernanza del clean core
Líder de clean core o de extensiones en BTP	Catálogo de extensiones, análisis del impacto de las actualizaciones
Consultores funcionales	Optimización de módulos, mejora de procesos
Consultores técnicos	Desarrollo, Basis, rendimiento, seguridad
Líder de cambio y formación	Adopción, formación, mejora de capacidades
Líder de gobierno de datos	Calidad y estándares de los datos maestros
Líder de integración	Middleware, API, flujos de datos entre sistemas
Líder de soporte	Resolución de incidencias, mejora continua
Responsable de la relación con SAP (RISE)	Escalamientos a SAP, revisiones del servicio, alineación con la hoja de ruta

Una empresa farmacéutica asignó responsables de módulo que debían aprobar cualquier cambio que pudiera afectar a su área. Esa gobernanza evitó los cambios descoordinados que suelen volver difícil de usar un sistema pasados dos o tres años.

Un cliente invirtió el 10 % del presupuesto de su CoE en aprendizaje continuo. Tres años después estaba implementando funciones que sus competidores no podían tocar. Así es un CoE que funciona.

¿Por qué fracasan los equipos de implementación de SAP aunque el plan parezca sólido?

Normalmente porque el plan cubre la tecnología e ignora a las personas. Los patrones habituales son roles clave ocupados por personas con otros trabajos, expertos en la materia que vuelven a la operación a mitad del proyecto y la gestión del cambio tratada como una función de formación. Cuando nadie es responsable de una decisión y no existe una vía de escalamiento, los bloqueos se acumulan durante semanas y el proyecto fracasa por falta de coordinación, no por la tecnología.

¿Qué roles no son negociables en cualquier implementación de SAP?

Seis roles necesitan personas dedicadas y responsables: patrocinador ejecutivo, director de proyecto, al menos un líder funcional por cada módulo principal, un líder de TI, un líder de migración de datos y un líder de gestión del cambio. Si falta cualquiera de ellos, el hueco aflora en las últimas semanas antes del go-live. La gestión del cambio es el rol con menos recursos. En RISE, añada un responsable claro de las extensiones y de la relación con los contactos de entrega de SAP.

¿Qué cambia en el diseño del equipo con RISE with SAP?

SAP gestiona la infraestructura y las operaciones técnicas, así que usted trabaja con contactos asignados por SAP, como un Client Delivery Manager o un Cloud Architect Advisor. Inclúyalos en el equipo y designe a su propio responsable de la relación. La responsabilidad sobre el clean core también debe ser explícita: un arquitecto dedicado en programas grandes, o el arquitecto de soluciones en los de mercado medio.

¿Debe un equipo de proyecto SAP estar formado por empleados o por consultores?

Por ambos. Los empleados aportan un contexto de negocio que los consultores no pueden replicar con rapidez. Los consultores aportan un reconocimiento de patrones de implementación del que los empleados suelen carecer. Empareje a cada consultor con una contraparte interna que será responsable de esa área después del go-live, para que el conocimiento se quede cuando los consultores se vayan. Las empresas que se saltan este paso suelen pagar durante años un soporte que deberían haber gestionado internamente.

¿Cuándo debe empezar a construirse el CoE de SAP?

Durante la implementación, idealmente desde los primeros meses. Los mejores miembros de su CoE suelen ser sus colaboradores más sólidos en la implementación, y si espera hasta el go-live se van antes de que los haya identificado. Un cliente de manufactura que esperó perdió a sus expertos clave en configuración tres meses después del go-live, y nadie sabía cómo mantener lo que se había construido.

¿Cómo cambia la IA el diseño de los equipos SAP en 2026?

Herramientas como SAP Joule for Consultants, SAP Build Code y Microsoft Copilot elevan la productividad en los roles con mucho flujo de trabajo cuando las personas las usan de forma constante. El equipo es algo más pequeño de lo que el mismo alcance requería antes de estas herramientas, pero no de forma drástica. Incorpore las herramientas a las definiciones de los roles y deje la responsabilidad en las personas: la IA redacta más rápido, las personas siguen siendo responsables de lo que dice el borrador.