SAP no es IT: sin negocio, no hay consultoría de verdad

Antes de tocar una transacción, un consultor SAP solvente debería entender cómo late una fábrica, cómo se tensiona una cadena de suministro y cómo duele una mala decisión en producción, logística o finanzas

Vamos a decirlo sin rodeos: saber SAP no es lo mismo que entender una empresa.

Y este matiz lo cambia todo.

Porque una cosa es conocer cómo funciona una transacción, cómo se configura un parámetro, cómo se enlazan unos datos maestros o cómo se diseña un flujo en el sistema. Y otra muy distinta es entender qué está pasando de verdad en el negocio cuando una planta se retrasa, cuando un proveedor falla, cuando una orden de fabricación se descuadra, cuando un coste se dispara o cuando un stock aparentemente correcto en pantalla es, en la práctica, un problema brutal para operaciones.

Ahí está la diferencia entre un perfil técnico que trabaja sobre SAP y un consultor SAP que realmente aporta valor.

SAP no debería entenderse como un software de IT. SAP debería entenderse como el gran coordinador de las operaciones de una compañía. Es el punto en el que convergen compras, producción, mantenimiento, calidad, logística, controlling, finanzas, ventas, planificación y muchas otras áreas. Es, en cierto modo, el sistema nervioso de la empresa.

Y por eso mismo, cuando alguien conoce el sistema pero no conoce el negocio, se queda corto. Muy corto.

Puede hacer cosas, sí. Puede configurar, documentar, probar, incluso implantar determinados procesos. Pero le falta algo decisivo: criterio operativo. Le falta comprender qué consecuencias reales tiene lo que propone. Le falta ver más allá de la pantalla. Le falta entender que detrás de cada dato hay personas, ritmos, restricciones, urgencias, costes, errores, tensiones y una operativa diaria que no perdona soluciones de laboratorio.

Porque una empresa industrial no se gestiona desde PowerPoint. Se gestiona desde la realidad.

Y la realidad mancha.

Por eso, bajo mi experiencia, un consultor SAP de verdad no debería construirse solo desde la tecnología. Debería construirse también desde haber pasado antes por funciones reales del negocio. Desde haber estado metido en operaciones. Desde haber tenido responsabilidades de verdad en áreas como producción, logística, finanzas, compras, supply chain, ingeniería o excelencia operacional.

Es ahí donde se forma algo que no te da ningún manual técnico: la visión completa.

Porque cuando has estado dentro de la operación, entiendes cosas que no aparecen en ninguna especificación funcional.

Entiendes lo que significa que una línea no se pare.

Entiendes lo que supone prometer una fecha que luego no se puede cumplir.

Entiendes cómo un pequeño error en un dato maestro puede generar un problema enorme aguas abajo.

Entiendes que un proceso bonito en el sistema puede ser una pesadilla en planta.

Entiendes que una solución técnicamente correcta puede ser operacionalmente absurda.

Y eso es exactamente lo que diferencia a un consultor solvente de uno que simplemente sabe moverse dentro de SAP.

El gran error: confundir consultoría SAP con soporte técnico de IT

Durante años se ha colado una visión demasiado estrecha de esta profesión. Se mete al consultor SAP en el cajón de “los de sistemas” o “los de informática” y se pierde por el camino lo más importante.

Porque un consultor SAP no debería limitarse a responder preguntas del tipo:

• Cómo se configura esto

• Qué transacción hace aquello

• Qué campo controla esta validación

• Qué desarrollo podemos pedir

• Qué tabla guarda este dato

Eso forma parte del trabajo, sí. Pero no es el corazón del trabajo.

El corazón del trabajo es otro: entender cómo funciona el negocio y traducirlo en un uso inteligente del sistema.

Y eso exige una mentalidad completamente distinta.

Exige escuchar no solo lo que el usuario pide, sino lo que realmente necesita.

Exige detectar cuándo una petición es un parche y no una solución.

Exige saber decir que no cuando algo va a empeorar la operación aunque técnicamente sea viable.

Exige proponer alternativas que encajen con la realidad del día a día.

Exige entender el impacto cruzado entre áreas.

Exige, en definitiva, tener visión de compañía.

Porque cuando esa visión no existe, pasa algo muy habitual: el consultor se convierte en un mero ejecutor. Hace lo que le piden. Configura lo solicitado. Documenta el requerimiento. Lo transporta. Lo prueba. Lo cierra.

Pero no cuestiona.

No enriquece.

No anticipa.

No alerta.

No mejora.

Y eso, aunque a veces pase por buen servicio, en realidad es una forma bastante pobre de consultoría.

Un consultor SAP sin negocio detrás suele dar soluciones cojas

Esto conviene decirlo claro porque afecta muchísimo a la calidad real del servicio.

Cuando un consultor SAP no ha tenido un background potente en operaciones, lo normal es que termine cayendo en varios errores bastante típicos:

• Entender solo una parte del proceso

• Proponer soluciones correctas en el sistema pero malas en la operación

• Limitarse a ejecutar lo pedido sin cuestionar si es lo mejor

• No detectar impactos aguas arriba o aguas abajo

• No ofrecer alternativas más eficientes

• No comprender los condicionantes reales del negocio

• Diseñar procesos poco usables para el día a día

• Pensar más en el sistema que en la empresa

Y esto no ocurre por mala fe. Ocurre, muchas veces, por falta de recorrido. Por falta de barro. Por falta de haber vivido antes lo que luego SAP intenta ordenar.

Porque SAP no vive en el vacío.

SAP vive pegado a una realidad física, económica y organizativa.

Vive en almacenes que se saturan.

Vive en fábricas que producen con presión.

Vive en cierres contables que no esperan.

Vive en compras urgentes.

Vive en planificaciones que cambian.

Vive en problemas de calidad.

Vive en retrasos logísticos.

Vive en desviaciones de coste.

Y si tú no entiendes todo eso de verdad, tu capacidad para asesorar bien queda muy limitada.

El consultor SAP que más valor aporta suele haber pasado antes por el negocio

Aquí es donde, para mí, está una de las claves más importantes de todas.

Un consultor SAP que ha tenido antes responsabilidades reales en otras áreas suele llegar a la consultoría con una ventaja brutal. No porque sepa más pantallas. No porque memorice más transacciones. No porque sea más técnico. Sino porque entiende mejor el contexto.

Y cuando entiendes el contexto, mejoras radicalmente la calidad de tus decisiones.

Porque ya no escuchas una incidencia solo como incidencia. La escuchas como síntoma de algo mayor.

Ya no ves una petición funcional solo como requerimiento. La ves como reflejo de una necesidad operativa, de una carencia de proceso o de una oportunidad de mejora.

Ya no diseñas para cumplir un ticket. Diseñas para ayudar a que el negocio funcione mejor.

Eso cambia por completo la conversación con el cliente interno o externo.

Porque dejas de ser “el que toca SAP”.

Y te conviertes en alguien que entiende su mundo.

En alguien que habla su idioma.

En alguien que sabe por qué le duele lo que le duele.

En alguien que no solo responde, sino que orienta.

En alguien que no solo implementa, sino que acompaña.

Y eso, en consultoría, vale muchísimo.

Producción: en una empresa industrial no basta con saber PP

Vamos con un primer ejemplo claro: producción.

Sobre el papel, alguien puede decir que conoce SAP PP, órdenes de fabricación, listas de materiales, hojas de ruta, centros de trabajo, MRP, confirmaciones y consumos. Perfecto. Todo eso es importante.

Pero ahora bajemos a una fábrica real.

En una empresa industrial, producción no es solo una secuencia lógica dentro de un sistema. Producción es ritmo, capacidad, cuellos de botella, mermas, retrabajos, restricciones físicas, tiempos muertos, calidad, disponibilidad de materiales, preparación de máquinas, dependencias entre operaciones, prioridades comerciales y presión constante por cumplir.

Y aquí aparece la pregunta de verdad: ¿puede asesorar bien sobre SAP PP alguien que no entiende cómo funciona eso en la realidad?

Mi respuesta es bastante clara: muy difícilmente.

Porque una cosa es parametrizar una orden. Y otra entender qué implica lanzar una orden demasiado pronto, demasiado tarde o con una estructura de operaciones que no refleja la vida real de planta.

Una cosa es definir confirmaciones. Y otra entender si esa forma de confirmar genera disciplina operativa o genera datos falsos porque el proceso diseñado no encaja con cómo se trabaja de verdad.

Una cosa es configurar un aprovisionamiento a línea. Y otra entender si el almacén, los tiempos de reposición y la organización física de la planta soportan ese modelo.

Una cosa es definir una BOM o una routing. Y otra muy distinta entender si eso representa fielmente el proceso productivo o si solo queda bonito en SAP.

Un consultor con experiencia real en operaciones productivas no se queda en el sistema. Va más allá. Hace preguntas distintas.

Pregunta si la secuencia propuesta se parece a lo que ocurre de verdad en planta.

Pregunta si los tiempos estándar tienen sentido o son pura fantasía de escritorio.

Pregunta si la captura de datos puede mantenerse sin romper la operativa.

Pregunta si la solución ayuda al supervisor o le mete una carga administrativa absurda.

Pregunta si el proceso mejora la trazabilidad sin matar la agilidad.

Pregunta si la planificación está conectada con la realidad de capacidad o si se está vendiendo humo en formato sistema.

Y ahí está el salto de nivel.

Porque entonces ya no hablamos de un consultor que sabe PP. Hablamos de un consultor que entiende producción y usa PP para mejorarla.

Eso es otra liga.

Ejemplo concreto en producción: el caso de las confirmaciones y consumos

Imaginemos una planta industrial donde se quiere tener control fino del avance de fabricación y del consumo de materiales.

Un perfil puramente técnico puede proponer algo aparentemente impecable: confirmaciones detalladas por operación, consumos obligatorios en cada fase, control exhaustivo de tiempos, imputación precisa de scrap y captura completa de incidencias.

En una presentación suena fenomenal.

Pero luego llega la realidad.

La línea va con presión.

Los mandos intermedios van justos.

Los operarios no pueden convertirse en administrativos.

Hay operaciones que se solapan.

Hay materiales que se consumen en bloque y no exactamente como figura en el estándar.

Hay variabilidad real.

Hay momentos de estrés.

Hay retrabajos.

Hay urgencias.

Y entonces lo que parecía una solución muy completa acaba generando otra cosa: datos mal introducidos, confirmaciones masivas ficticias, rechazos al sistema, pérdida de tiempo y una sensación general de que SAP estorba.

¿Qué hace aquí un consultor con background operativo?

Hace algo mucho más valioso: aterriza la solución.

No renuncia al control, pero entiende que el control tiene que ser viable.

Busca el equilibrio entre trazabilidad y usabilidad.

Diseña capturas donde aportan valor real.

Reduce complejidad donde solo aporta burocracia.

Escucha a supervisores, planificadores y personal de planta.

Ajusta el sistema a la realidad sin destruir el rigor.

Eso no te lo da solo saber SAP. Eso te lo da haber entendido antes cómo respira una operación productiva.

Finanzas: FI o CO no se entienden de verdad sin entender el negocio

Segundo ejemplo: finanzas.

Aquí también se comete mucho el error de pensar que dominar SAP FI o CO es, sobre todo, dominar estructuras, cuentas, centros de coste, órdenes internas, clases de coste, periodificaciones, liquidaciones, activos, cierres y reporting.

Todo eso importa, claro que sí.

Pero volvemos a lo mismo: si no entiendes cómo funciona la empresa por dentro, te quedas en la superficie.

Porque finanzas en una empresa industrial no es solo contabilidad. Es lectura económica del negocio. Es entender qué está pasando de verdad detrás de un coste, de una desviación, de un inventario, de una imputación o de un margen.

Y eso exige haber tenido sensibilidad operativa.

Pongamos un ejemplo muy claro. Una planta detecta desviaciones relevantes entre coste estándar y coste real.

El perfil técnico puede centrarse en revisar determinaciones contables, clases de coste, esquemas de liquidación, parametrización del controlling o estructura de objetos CO.

Bien.

Pero un consultor con visión de negocio irá más allá.

Se preguntará si el problema está realmente en el sistema o en la operativa.

Se preguntará si hay tiempos improductivos mal absorbidos.

Se preguntará si las rutas están mal mantenidas.

Se preguntará si hay consumos no declarados correctamente.

Se preguntará si existen reprocesos recurrentes que nadie está atacando.

Se preguntará si las mermas reales no coinciden con el modelo teórico.

Se preguntará si hay un problema de disciplina en planta, de datos maestros o de lógica de imputación.

Y entonces la conversación cambia por completo.

Porque ya no estás hablando solo de contabilidad en SAP.

Estás hablando de cómo la empresa gana o pierde dinero de verdad.

Y ahí, otra vez, la consultoría útil no nace solo del conocimiento del sistema. Nace del cruce entre sistema y operación.

Ejemplo concreto en finanzas: el cierre que aparentemente cuadra pero no explica nada

Esto pasa muchísimo.

Se logra cerrar.

Los asientos están hechos.

Las liquidaciones corren.

Las reconciliaciones no muestran grandes errores.

El sistema, en apariencia, funciona.

Pero negocio sigue incómodo.

¿Por qué?

Porque cerrar no es lo mismo que entender.

Puedes tener un cierre técnicamente correcto y, aun así, no estar ayudando al negocio a comprender qué le está pasando.

Puedes tener costes bien registrados y seguir sin explicar por qué una línea se deteriora en rentabilidad.

Puedes tener inventario valorado y seguir sin ver dónde está el verdadero agujero.

Puedes tener una cuenta de resultados impecable en estructura y, al mismo tiempo, completamente desconectada de la conversación operativa que la empresa necesita tener.

Aquí es donde un consultor con recorrido real en operaciones marca una diferencia enorme. Porque no se conforma con que el asiento cuadre. Quiere que el dato explique. Quiere que sirva. Quiere que dialogue con producción, con logística, con compras, con Supply Chain y con dirección.

Ese enfoque vale oro.

Porque el mejor entorno SAP financiero no es el que solo contabiliza bien.

Es el que ayuda a decidir mejor.

Logística: donde más se nota si alguien ha pisado o no el terreno

Tercer ejemplo: logística.

Aquí la distancia entre teoría y realidad puede ser directamente escandalosa.

Sobre el papel, la logística en SAP puede parecer ordenada: entradas, salidas, transferencias, ubicaciones, lotes, stocks especiales, movimientos, entregas, picking, staging, inventarios, aprovisionamiento interno, trazabilidad.

Todo muy limpio.

Hasta que pisas el almacén.

Hasta que ves pasillos estrechos, urgencias, material mal ubicado, transportes que no llegan, embalajes que no ayudan, referencias parecidas que generan errores, operarios con presión, reubicaciones improvisadas, problemas de espacio, materiales críticos mezclados con otros no críticos y una operativa que muchas veces sobrevive más por experiencia de la gente que por perfección del sistema.

En ese entorno, un consultor SAP sin experiencia operativa corre el riesgo de diseñar procesos logísticos muy correctos sobre el papel y muy torpes en la realidad.

Porque puede no entender cosas esenciales:

• Qué nivel de trazabilidad es realmente necesario

• Qué complejidad operativa puede absorber el almacén

• Qué movimientos generan valor y cuáles generan burocracia

• Qué diseño de ubicaciones tiene sentido físico

• Qué secuencias son viables en el día a día

• Qué datos maestros son críticos para evitar errores reales

• Qué impacto tiene una mala definición del flujo sobre producción y servicio

Y en logística esto se paga rápido. Muy rápido.

Porque una mala decisión en este campo no se queda en SAP. Se traduce en retrasos, errores de preparación, pérdidas de tiempo, stock aparentemente disponible pero no utilizable, desorden físico, reprocesos y tensión constante entre áreas.

Ejemplo concreto en logística: stock correcto en SAP, desastre en la realidad

Este caso lo resume todo.

Imagina una empresa industrial donde el stock en SAP dice una cosa, pero operaciones vive otra muy distinta.

El sistema indica disponibilidad.

La producción dice que no encuentra el material.

El almacén asegura que entró.

Compras dice que ya está recepcionado.

Finanzas lo tiene valorizado.

Y, sin embargo, la línea sigue esperando.

¿Qué ha pasado?

A veces no falla un campo. Falla la comprensión del proceso completo.

Quizá la ubicación lógica no coincide con la física.

Quizá el diseño de staging es deficiente.

Quizá se recepciona antes de tiempo para “dejarlo hecho”.

Quizá el flujo entre descarga, inspección, almacenaje y suministro interno está mal resuelto.

Quizá hay una disciplina operativa débil.

Quizá el circuito diseñado en SAP no refleja la realidad del almacén.

Quizá se ha forzado un modelo estándar sin tener en cuenta la casuística de la planta.

Un consultor meramente técnico intentará ajustar movimientos o revisar parametrización.

Un consultor con visión end-to-end hará algo mucho más útil: reconstruirá el proceso real.

Bajará al detalle.

Hablará con almacén, logística interna, producción y planificación.

Verá el flujo físico.

Entenderá dónde se rompe la cadena.

Y solo entonces propondrá cómo debe ayudar SAP.

Eso es consultoría de verdad.

Lo otro, muchas veces, es solo tocar botones.

SAP es el coordinador del negocio, no un adorno tecnológico

Aquí está, para mí, una de las ideas más importantes de todo el artículo.

SAP no es una capa de software puesta encima de la empresa.

SAP es, en gran medida, la forma en que la empresa articula sus procesos, conecta sus áreas, disciplina sus operaciones y convierte su realidad en información, control y capacidad de decisión.

Por eso tratar SAP como si fuera únicamente IT es quedarse en la parte más pobre del asunto.

Claro que hay una dimensión tecnológica. Por supuesto que la hay. Hay arquitectura, desarrollo, integración, seguridad, datos, configuraciones, transportes, roles, automatizaciones y muchas otras piezas técnicas que son fundamentales.

Pero eso no invalida la idea principal: la esencia de SAP está mucho más cerca del negocio que de la informática pura.

Quien no entienda eso, se pierde la mitad de la película.

Y a veces algo peor: hace perder tiempo y dinero a la empresa.

Porque cuando SAP se diseña desde una lógica demasiado técnica y poco operativa, sucede algo bastante habitual: el sistema deja de ser una ayuda y pasa a sentirse como una imposición.

Y eso es gravísimo.

Porque el mejor SAP no es el más sofisticado.

Es el que mejor encaja con la realidad de la compañía sin renunciar al orden, al control y a la mejora.

La analogía de El Corte Inglés: primero conocer el negocio por dentro

Aquí hay una analogía que, para mí, explica muy bien todo esto.

Durante muchos años, en la empresa española El Corte Inglés, existía una lógica muy potente para formar a quienes iban a asumir responsabilidades de management: hacerles pasar por distintas funciones del negocio, empezando muchas veces por puestos de base, para que entendieran de verdad cómo funcionaba la empresa desde dentro.

Eso tenía muchísimo sentido.

Porque quien ha pasado por distintas capas del negocio entiende mejor el conjunto.

Entiende mejor los problemas reales.

Entiende mejor a las personas.

Entiende mejor los límites de cada área.

Entiende mejor dónde se generan las ineficiencias.

Entiende mejor qué decisiones son brillantes en teoría pero pobres en la práctica.

Y, sobre todo, desarrolla una visión end-to-end que luego hace muchísimo más sólido su criterio.

Pues bien: ese mismo enfoque debería aplicarse mucho más a la figura del consultor SAP.

Si de verdad quieres un consultor solvente, no deberías conformarte con alguien que solo domina el sistema. Deberías valorar muchísimo más a alguien que, además, ha pasado por negocio. Que ha entendido procesos reales. Que ha tenido responsabilidades. Que ha tomado decisiones con impacto. Que ha vivido la presión de la operación.

Porque entonces no solo conoce SAP.

Conoce la empresa.

Y un consultor SAP sin empresa dentro se queda, inevitablemente, cojo.

El consultor pobremente orientado al negocio suele quedarse en el “dime qué quieres y te lo hago”

Este es otro de los grandes problemas.

Cuando falta background operativo, muchas veces la consultoría cae en una dinámica peligrosa: la de limitarse a ejecutar peticiones.

El usuario pide algo.

El consultor lo documenta.

Lo analiza desde SAP.

Lo construye o parametriza.

Lo entrega.

Y listo.

Pero ese modelo tiene una carencia enorme: no hay verdadera asesoría.

Porque asesorar no es obedecer.

Asesorar es entender, cuestionar, enriquecer y orientar.

A veces el usuario pide una solución concreta porque no conoce otra.

A veces pide una transacción adicional cuando lo que necesita es revisar el proceso.

A veces pide un desarrollo porque nadie le ha enseñado una opción estándar mejor.

A veces pide más controles donde lo que falta es disciplina operativa.

A veces pide rapidez sacrificando trazabilidad sin entender el impacto.

Y ahí es donde se ve si tienes delante a un mero ejecutor o a un auténtico consultor.

El auténtico consultor no despacha tickets. Ayuda a pensar mejor.

Y eso solo lo haces bien cuando tienes amplitud de visión.

La visión end-to-end no es un lujo: es un must

A veces se habla de visión end-to-end como si fuera un plus elegante para poner en una presentación. Como si fuera un concepto bonito, moderno y más o menos deseable.

No.

En SAP, especialmente en entornos industriales, la visión end-to-end no es un adorno. Es un must.

Porque los procesos no viven aislados.

Compras impacta en producción.

Producción impacta en costes.

Costes impactan en finanzas.

Logística impacta en servicio.

Calidad impacta en plazos.

Planificación impacta en todo.

Y SAP está justo en medio de toda esa conversación.

Por eso, cuando alguien interviene en SAP sin entender el encadenamiento completo, corre un riesgo altísimo de mejorar una parte empeorando el resto.

Y eso no es mejora. Eso es mover el problema de sitio.

La visión end-to-end es la que te obliga a pensar completo.

A no quedarte solo con tu módulo.

A no enamorarte de una solución local.

A entender que el verdadero valor está en el equilibrio global del proceso.

Y eso, otra vez, tiene muchísimo más que ver con negocio que con IT.

Lo que de verdad debería buscar una empresa en un consultor SAP

Si una empresa industrial quiere de verdad incorporar o apoyarse en consultores SAP de nivel, para mí debería mirar mucho más allá del conocimiento técnico puro.

Debería valorar perfiles que aporten cosas como estas:

• Comprensión real de procesos de negocio

• Experiencia previa en áreas operativas

• Capacidad para hablar con negocio sin traducir desde la jerga técnica

• Sensibilidad para entender restricciones reales de la operación

• Visión end-to-end de la compañía

• Criterio para proponer alternativas y no solo ejecutar peticiones

• Capacidad para equilibrar sistema, control y usabilidad

• Mentalidad de mejora real y no solo de cumplimiento técnico

Porque todo eso multiplica el valor de SAP.

Y porque, sinceramente, el mercado está lleno de perfiles que saben bastante sistema pero muy poco negocio.

Y eso se nota.

Se nota en las soluciones.

Se nota en las reuniones.

Se nota en los diseños de proceso.

Se nota en las implantaciones.

Se nota en la calidad del acompañamiento.

Se nota en la confianza que generan.

Y se nota, sobre todo, en los resultados.

La conclusión que de verdad importa

Conviene romper este mito de una vez: SAP no es igual a IT.

Reducir SAP a informática es no entender lo que representa dentro de una empresa. Es no entender su impacto. Es no entender el nivel de criterio que exige trabajar bien con él.

SAP, en realidad, está mucho más cerca de la operación, del proceso, de la gestión y del negocio de lo que mucha gente cree.

Por eso, quien de verdad quiera ser un consultor SAP solvente debería preocuparse muchísimo por entender cómo funciona una compañía de verdad. Cómo compra. Cómo produce. Cómo almacena. Cómo transporta. Cómo contabiliza. Cómo planifica. Cómo se desvía. Cómo sufre. Cómo mejora.

Y para entender eso no basta con leerlo.

Hay que vivirlo.

Hay que haber estado dentro.

Hay que haber tenido responsabilidades reales.

Hay que haber pisado el fango.

Porque desde ahí es desde donde se construye el criterio que luego convierte a alguien en un consultor útil de verdad.

No en un mero técnico de sistema.

No en un ejecutor de tickets.

No en un especialista encerrado en su módulo.

Sino en alguien capaz de mirar una empresa de punta a punta, entender sus tensiones reales y usar SAP como lo que de verdad es: una herramienta potentísima para ordenar, conectar y mejorar el negocio.

Y eso exige algo más que saber pantallas.

Exige empresa.

Exige proceso.

Exige realidad.

Exige fondo.

Exige cicatriz.

Exige haber estado antes donde luego SAP pretende ayudar.

Por eso, para mí, un gran consultor SAP no es el que más transacciones conoce.

Es el que mejor entiende el negocio que esas transacciones intentan sostener.

Y esa diferencia no es pequeña.

Esa diferencia lo es todo, absolutamente todo.