Qué hacen realmente los consultores: una visión realista

Los consultores de SAP configuran, construyen, prueban y estabilizan SAP para un negocio. En la práctica, la mayor parte de su valor se entrega a mitad del programa. Aclaran el alcance que se ha desviado, hacen los recorridos guiados que nadie hizo, clasifican los defectos de UAT y estabilizan las operaciones tras el go-live. Los consultores funcionales son responsables de la configuración de los módulos, los técnicos de las extensiones y las integraciones, y los de programa y cambio de la entrega y la adopción. Este artículo es para líderes que deciden si traer ayuda externa y para quienes se plantean la consultoría como carrera. Si usted es líder, la tabla de señales de abajo le dice cuándo llamar. Si es consultor, las secciones sobre el día a día muestran en qué consiste realmente el trabajo.

La pregunta aparece cada vez que alguien sopesa un apoyo externo: ¿qué hace exactamente un consultor que no podamos hacer nosotros mismos?

La respuesta honesta no es especialmente halagüeña para el sector de la consultoría. Gran parte del valor viene de arreglar cosas que no deberían haberse roto. De hacer preguntas que ya deberían haberse hecho. Y de aportar capacidad y claridad en el momento en que el equipo interno se queda sin ambas.

Eso no es una crítica a los equipos internos. Así es como suelen ejecutarse los programas de SAP. El equipo interno está al límite. El integrador de sistemas tiene sus propias prioridades. Las decisiones se acumulan y el alcance se desvía. Seis meses después de un programa de doce, alguien abre el registro de incidencias y encuentra veinte puntos marcados como «por resolver» que llevan ahí desde la semana tres.

Normalmente es entonces cuando entra la llamada.

Algunos consultores se incorporan durante el blueprint o la planificación. A muchos se les llama a mitad de proyecto, a menudo tras dos o tres meses de avance lento o de traspasos fallidos. Los informes del comité directivo se ven en naranja. El equipo trabaja duro. El avance es lento y nadie sabe decir exactamente por qué.

1. ExploreTalleres y brechasTalleres de fit-to-standard, brechas documentadas
2. RealizeDesarrollo y recorridos guiadosConfiguración y extensiones. A mitad de proyecto es cuando suelen llegar las llamadas de recuperación
3. DeployTriaje de UAT y cutover¿Brecha de configuración, de proceso o de formación? El triaje decide
4. HypercareEstabilizaciónEl primer cierre mensual y la cola de incidencias

Los puntos de entrada típicos:

1. El alcance se ha desviado. Lo aprobado en Explore ya no coincide con aquello en lo que trabaja el equipo de desarrollo. Se añadieron requisitos de manera informal en los talleres, el registro de cambios no se mantuvo y nadie tiene una lista de alcance definitiva.
2. Un frente de trabajo crítico se ha estancado. La migración de datos lleva semanas con la misma tasa de errores y sin un plan para mejorarla. UAT abre más defectos de los que cierra.
3. La fecha de go-live está fijada y el plan no la respalda. El consejo fijó la fecha. El plan no se ha conciliado con el avance real. El director del programa sabe que la trayectoria no llega a la fecha, pero aún no lo ha escalado.

En cada caso, el trabajo no es sumar personas al plan existente. Es mirar lo que realmente está pasando, nombrar el problema con claridad y trazar un camino a seguir. Mi guía para volver a encarrilar los proyectos SAP cubre esa secuencia de recuperación.

Aclaración del alcance y de los procesos

A veces la configuración es correcta, pero el proceso que la rodea está roto. Un patrón habitual: el equipo configuró según un documento de fit-to-standard de Explore, y los usuarios de negocio no han vuelto a ver la configuración desde la aprobación. Se les dijo lo que se estaba construyendo, no se les mostró.

La solución no es técnica. Es una brecha de conversación. El trabajo consiste en guiar a los usuarios de negocio por la configuración antes de UAT y elaborar una lista clara de cambios antes de que se abran las pruebas.

Eso no tiene nada de glamuroso. Así es el trabajo.

Traducir entre los equipos técnicos y de negocio

Los programas de SAP producen con regularidad algo técnicamente correcto que el negocio no puede usar. Una determinación de precios que funciona en el 90 % de los casos y falla en los pedidos de exportación. Un movimiento de mercancías que se contabiliza correctamente pero genera un documento financiero que el equipo de conciliación no reconoce.

El consultor funcional cierra esa brecha. No por ser la persona más técnica de la sala. Sino por entender el comportamiento del sistema y el impacto en el negocio lo bastante bien como para que las personas adecuadas puedan tomar la decisión adecuada.

Soporte de UAT

Las pruebas de aceptación de usuario (UAT) son el momento en que las decisiones acumuladas de un programa se sostienen o se desmoronan. Cada atajo en Explore, cada ampliación informal del alcance y cada caso de prueba escrito a nivel de resumen aflora aquí.

Un buen soporte de UAT significa clasificar bien los defectos, separando las brechas de configuración de las brechas de proceso y de las brechas de formación. También significa gestionar el ánimo cuando los usuarios de negocio tropiezan con una racha de fallos que sacude su confianza en todo el programa. Sin eso, cada defecto en una sesión de UAT se convierte en un motivo para cuestionar el go-live, normalmente porque el triaje fue débil y nadie había definido qué significaba «listo para el go-live».

Estabilización tras el go-live

El trabajo menos glamuroso de la consultoría SAP es el hypercare. El go-live ocurrió, salieron los correos de celebración y el equipo de implementación empezó a retirarse. Entonces llega el primer cierre mensual. Las contabilizaciones no coinciden con el formato de conciliación. Las órdenes de producción se completan pero no se liquidan. El centro de ayuda se llena de usuarios que fueron formados pero no preparados para los casos límite.

Aquí es donde se entrega buena parte del valor real y donde la mayoría de los programas tienen menos recursos. El equipo de hypercare trabaja la cola de incidencias de forma sistemática, separa los problemas sistémicos de los errores puntuales y reconstruye la confianza en el sistema.

La estructura del trabajo no ha cambiado. La combinación de tiempos, sí.

La documentación se redacta casi sola. SAP Joule for Consultants, disponible con carácter general desde 2025, responde preguntas de configuración a partir de la propia base de conocimiento de SAP, incluidas las SAP Notes, y explica código ABAP. Los asistentes basados en Joule de SAP Cloud ALM redactan requisitos y casos de prueba a partir del material de los talleres. El consultor funcional dedica menos tiempo a escribir documentos y más a cuestionar las conclusiones de los talleres.

El código se revisa más de lo que se escribe. Los asistentes para desarrolladores de SAP redactan código, incluido SAP Build Code para extensiones en Java y JavaScript en SAP BTP. Los consultores técnicos ahora lo revisan, lo aseguran y lo prueban.

El servicio de hypercare recibe menos consultas rutinarias. Joule puede responder consultas rutinarias, como saldos de vacaciones o el estado de un gasto, dentro de las aplicaciones SAP, lo que quita algo de carga al servicio de hypercare. El tiempo del consultor se desplaza hacia las brechas de proceso, los problemas de datos maestros y los casos que necesitan a una persona.

El motivo para contratar a un consultor no ha cambiado. Los consultores que han aprendido estas herramientas dedican más tiempo al criterio, la comunicación y el escalado, y menos al trabajo que la IA ya redacta de forma adecuada. La propia descripción de SAP de Joule for Consultants es un buen resumen de lo que cubre.

Los consultores funcionales se especializan en módulos como FI, CO, SD, MM, PP, EWM o SuccessFactors. Configuran el sistema en torno a los procesos de negocio y cierran la brecha entre el estándar de SAP y los requisitos del cliente. Su valor es la profundidad en el módulo más el conocimiento de los procesos de negocio.

Los consultores técnicos (desarrolladores ABAP, especialistas en SAP BTP, arquitectos de integración, Basis) construyen las extensiones e integraciones que la configuración no puede cubrir. En los programas modernos de S/4HANA, los principios de Clean Core empujan las nuevas extensiones hacia SAP BTP o las API liberadas, lo que requiere un conjunto de habilidades distinto de la modificación ABAP clásica.

Los directores de proyecto y de programa aportan la estructura de entrega: gobierno, riesgos, calendario y resolución de incidencias, con visibilidad sobre todo el programa para que los problemas se escalen antes de convertirse en crisis.

Los consultores de gestión del cambio trabajan en el lado humano: formación, comunicación, implicación y el gobierno que decide si los usuarios adoptan el sistema o lo esquivan.

La mayoría de los grandes programas SAP necesitan los cuatro. Los programas del segmento medio suelen tener menos personas cubriendo varios roles, y ahí es donde se forman las brechas. Los marcos de consultoría y las habilidades que importan en la consultoría son los mismos en los cuatro. Si es consultor y está trazando su propia ruta por estos roles, SAPopedia recoge rutas profesionales y cursos, y ERPCV le ayuda a presentar esa experiencia a los reclutadores.

El error de consultoría más caro es traer a alguien demasiado tarde. Una revisión de riesgos previa al cutover, cuatro a seis semanas antes del go-live, puede encontrar problemas críticos cuando aún hay tiempo. Un encargo de recuperación tras un cutover fallido cuesta mucho más. Además ocurre bajo presión operativa, en una organización que ha perdido la confianza en el sistema.

La tabla muestra las señales y la ayuda que requiere cada una.

Señal	Qué suele significar	Ayuda que conviene traer	Qué debería entregar en dos semanas
Puntos del registro de incidencias abiertos más de cuatro semanas sin fecha de resolución	Un problema de gobierno, no técnico	Asesor independiente del programa	Una lista de decisiones con responsables y fechas
Go-live en menos de 60 días y sin ensayo de cutover	Cutover sin probar; las sorpresas en el go-live no se pueden recuperar en tiempo real	Responsable de cutover o de programa	Un plan de cutover ensayado y criterios de go/no-go
Los responsables de negocio han dejado de asistir	UAT fracasará sin una intervención deliberada	Responsable de cambio más un responsable funcional	Recorridos guiados con usuarios clave y un plan para recuperar su participación
Un frente de trabajo atascado con la misma tasa de errores durante semanas	No se ha encontrado la causa raíz	Especialista en ese frente	Un análisis de causa raíz y un plan de recuperación
Los informes del integrador son la única visión de la salud del programa	Sin control independiente	Asesor del lado del cliente	Una evaluación honesta de la salud del programa para el patrocinador

¿Qué hacen realmente los consultores de SAP en un proyecto?

Analizan los requisitos de negocio, configuran SAP para respaldarlos y cierran la brecha entre los valores por defecto de SAP y lo que necesita el negocio. En Explore dirigen talleres de fit-to-standard y documentan las brechas. En Realize construyen la configuración y trabajan con los desarrolladores en las extensiones. En Deploy apoyan UAT, gestionan los defectos y preparan el cutover. En hypercare resuelven los problemas posteriores al go-live. Lo que no figura en las descripciones de puesto es clasificar las brechas entre fases y mantener la disciplina de entrega bajo presión.

¿Cuándo necesitan realmente las organizaciones a un consultor?

Tres situaciones cubren la mayoría de los encargos. La recuperación de un programa, cuando el alcance se ha desviado, un frente de trabajo se ha estancado o la fecha de go-live está en riesgo. La capacidad especializada, cuando al equipo le falta una habilidad de módulo o técnica, como la configuración de PP-PI o la integración en SAP BTP. Y el gobierno, cuando la organización quiere supervisión independiente de un programa dirigido por un integrador de sistemas. Esperar a que las cosas se deterioren antes de llamar es el patrón más común y el más caro.

¿Cuál es la diferencia entre un consultor SAP funcional y uno técnico?

Los consultores funcionales configuran SAP para respaldar los procesos de negocio en módulos como FI/CO, SD, MM, PP o EWM, y trabajan directamente con los usuarios de negocio en los requisitos. Los consultores técnicos construyen lo que la configuración no puede: extensiones en ABAP y BTP, integraciones y administración del sistema mediante Basis. Los principios de Clean Core están desplazando el trabajo técnico desde las modificaciones ABAP dentro del sistema hacia extensiones en BTP y API liberadas.

¿Cómo saber si un consultor aporta valor?

Tres indicadores. Saca a la luz supuestos que nunca se probaron y decisiones que se aplazaron, en lugar de confirmar las opiniones existentes. Las decisiones que llevaban semanas bloqueadas empiezan a tomarse. Y el registro de incidencias se reduce porque se corrigen las causas raíz, no porque se cierren puntos sin resolverlos. Un registro que mantiene la misma longitud pese a la actividad significa que los problemas son sistémicos o que las soluciones no llegan a la causa.

¿Cuál es la parte más difícil del trabajo de consultoría?

Nombrar los problemas que el cliente ya conoce pero no ha atendido: el alcance desviado, los casos de prueba sin escribir, el patrocinador que dejó de implicarse. Eso exige la confianza suficiente para ser escuchado, la credibilidad suficiente para ser creído y la franqueza suficiente para decir cosas incómodas. Los consultores que protegen la relación a costa del diagnóstico son un asentimiento muy caro.

¿Por qué contratar a un consultor independiente si el cliente ya tiene un integrador de sistemas?

El integrador de sistemas responde de entregar el alcance contratado. Un consultor independiente responde ante el cliente por el resultado. Son trabajos distintos. El asesor del lado del cliente cuestiona los supuestos del diseño y valida que el diseño cumple las necesidades del negocio. Protege la posición comercial del cliente en el control de cambios y da a la dirección una visión de la salud del programa que no pasa por el filtro de los informes del integrador. Eso es un conflicto de intereses estructural, no una crítica a los integradores.