Recuperación de un ERP en FMCG: informes unificados con SAP Analytics Cloud

Este caso práctico es para directores financieros y responsables de TI que gestionan más de un ERP y no consiguen una única versión de las cifras. La versión corta: un proyecto de informes transfronterizo, estancado, entre Oracle en Singapur y SAP en el Reino Unido se recuperó en seis meses. Lo lograron cinco cosas. Un comité directivo más pequeño y con autoridad real. Un alcance recortado a los informes que impulsan decisiones. Definiciones acordadas en ambos sistemas. SAP Analytics Cloud como única capa de informes. Y campeones locales en lugar de formación en aula. Si usted está en la misma situación, empiece por la gobernanza y las definiciones, no por el debate sobre la herramienta.

La historia empieza con un proyecto de analítica ERP estancado en un conocido grupo FMCG con sede en Singapur. El grupo tenía una participación del 26 % en una empresa británica de bebidas energéticas. Aunque era una participación minoritaria, el control de la gestión estaba en Singapur, así que la estrategia que se decidía en las salas de consejo de Asia marcaba los informes y la planificación diarios en Europa.

La tecnología lo complicaba aún más. Singapur trabajaba con Oracle ERP. El Reino Unido, con SAP ERP. Cada sistema funcionaba por su cuenta y, juntos, generaban un problema de informes que ya había consumido meses de esfuerzo.

Las cifras casi nunca coincidían. Las conciliaciones se alargaban durante días. Hasta el informe de ingresos más básico salía distinto según el sistema que se consultara.

A los seis meses de iniciarse el trabajo de recuperación, lo que parecía una iniciativa fallida se había convertido en un modelo de informes transfronterizo en el que confiaban tanto finanzas como operaciones.

Antes de la recuperaciónEn el relanzamiento

GobernanzaAntes de la recuperaciónComité directivo numeroso, decisiones aplazadasEn el relanzamientoSolo quienes deciden de verdad, decidiendo en la reunión

AlcanceAntes de la recuperaciónUna pizarra llena de peticionesEn el relanzamientoInformes que impulsan decisiones

DefinicionesAntes de la recuperaciónLa misma etiqueta, un significado distinto en cada ERPEn el relanzamientoIngresos, costos y margen acordados

InformesAntes de la recuperaciónConciliación en Excel que tardaba díasEn el relanzamientoDatos de Oracle y SAP en un solo modelo en SAP Analytics Cloud

AdopciónAntes de la recuperaciónFormación en aula y vuelta a ExcelEn el relanzamientoCampeones locales, un equipo cada vez

La tabla resume la situación de partida y cómo se resolvió cada problema.

Reto	Impacto	Resolución con SAP Analytics Cloud
Dos ERP: Oracle en Singapur, SAP en el Reino Unido	Las cifras no cuadraban; la conciliación llevaba días	Ambos alimentaban un único modelo de informes
Responsabilidad poco clara sobre los informes entre países	La estrategia en Asia chocaba con los datos operativos en Europa	Unos KPI estándar hicieron que ambas entidades informaran las mismas métricas
Informes de ingresos lentos	Las cifras diferían según el sistema de origen y retrasaban las decisiones	La planificación y los informes unificados acortaron el ciclo
Planificación desalineada	Singapur fijaba la estrategia; el Reino Unido ejecutaba con supuestos distintos	Los modelos de planificación compartidos alinearon a ambos negocios

Informes a través de dos ERP

Con Oracle en Singapur y SAP en el Reino Unido, informar era como dirigir dos negocios distintos. Finanzas extraía la misma métrica de cada sistema y obtenía respuestas diferentes. En una revisión mensual, Singapur presentó una cifra de ingresos y el Reino Unido la rebatió al instante con otra. La discusión duró más que la revisión.

La gente volvía a Excel porque le parecía más seguro: horas de exportar, conciliar y construir cada uno su propia versión de la verdad. A corto plazo funcionaba, y a la larga provocó retrasos crónicos en la información de grupo. Mi artículo sobre por qué los CFO siguen recurriendo a Excel trata ese patrón con más amplitud.

Consolidación del cierre mensual

El cierre mensual era lo más difícil. Un costo registrado en «operaciones» en un ERP a veces acababa en «administración» en el otro. Una vez vi un borrador de consolidación en el que el mismo gasto aparecía dos veces bajo epígrafes distintos. Eso acabó con la confianza en las cifras. Los resultados tardíos se volvieron lo habitual y, cuando el grupo por fin publicaba, solían llegar revisiones.

Informes operativos

Los problemas iban más allá de finanzas. Oracle controlaba los envíos, SAP controlaba el stock y no existía una fuente única. Un jefe de almacén me contó que en una sola semana había recibido tres informes de stock distintos, todos con saldos diferentes. Se reía al contarlo, pero aquello frenaba decisiones reales. El reabastecimiento se retrasaba y los retrasos en los envíos eran más difíciles de explicar porque operaciones no confiaba en los paneles.

El debate sobre la herramienta

Elegir la herramienta de informes acabó siendo un proyecto en sí mismo. A algunos directivos les gustaba el perfil de costos de Power BI; otros defendían SAP por su hoja de ruta más larga. Estuve en un taller en el que la mitad del tiempo se fue en «por qué SAC y no Power BI» en lugar de hablar de las necesidades de informes. El debate duró meses y se llevó el impulso del proyecto.

Resistencia de los usuarios

Incluso después de que salieran los primeros paneles, la adopción siguió siendo baja. Recuerdo ver a alguien, en una reunión de finanzas, abrir un panel, echarle un vistazo, cerrarlo y volver a su hoja de Excel. Nadie lo cuestionó. La gente confiaba en lo que conocía, y los paneles todavía no se habían ganado esa confianza.

Reiniciar la gobernanza. Las reuniones parecían interminables y la gente salía sin saber quién había tomado la decisión. La dirección redujo el comité directivo a quienes realmente decidían. Las sesiones se hicieron más cortas y más resolutivas, y las escalaciones llegaban rápido a las personas adecuadas. No era perfecto, pero las cosas empezaron a moverse. Mi guía sobre cómo dirigir un comité directivo de SAP expone los mismos principios.

Poner el alcance bajo control. Se discutía sin parar qué cifras debían figurar en la vista de grupo, y la lista de requisitos se había vuelto inmanejable. Recuerdo la pizarra de un taller cubierta de punta a punta con peticiones, la mitad sin relación con ninguna decisión real. El planteamiento que funcionó: los informes solo tienen que cubrir lo que impulsa decisiones. Una vez acordado eso, la entrega se aceleró.

Una comunicación que resultara relevante. Las actualizaciones anteriores eran genéricas, así que finanzas, operaciones y TI sacaban cada una una interpretación distinta. Pasamos a actualizaciones a medida: plazos de los informes para finanzas, cambios en los procesos logísticos para operaciones, una hoja de ruta técnica para TI. La gente empezó a hacer mejores preguntas porque las actualizaciones hablaban su idioma.

Campeones locales. La formación por sí sola no había funcionado: la gente aguantaba las sesiones y a la mañana siguiente volvía a Excel. El cambio vino de los campeones locales, compañeros que ya tenían credibilidad en sus equipos y explicaban los paneles de manera informal, con sus propias palabras. Asistí a una de esas sesiones y la diferencia era notable. La gente hacía preguntas que nunca habría hecho en una clase. La adopción mejoró equipo por equipo.

La tabla resume qué cambió y por qué funcionó.

Área de enfoque	Qué cambió	Impacto
Reinicio de la gobernanza	Se redujo el comité directivo a quienes deciden de verdad; sesiones más cortas y más precisas	Las decisiones se tomaban en la reunión; las escalaciones avanzaban rápido
Control del alcance	Se recortaron los requisitos a los informes que impulsan decisiones	Menos debate, modelos de datos más claros, menos objetivos cambiantes
Comunicación a medida	Actualizaciones separadas para finanzas, operaciones y TI	Cada equipo entendió lo que le importaba; volvió la confianza
Campeones locales	Coaching entre compañeros en grupos pequeños en lugar de clases formales	La adopción mejoró equipo a equipo; se redujo la dependencia de Excel

Cuando por fin concluyó la selección de la herramienta, ganó SAC, en parte porque podía reunir los datos de Oracle y de SAP en un solo modelo sin mucho desarrollo a medida. Eso rebajó la tensión de la discusión. Los informes reflejaban los cambios mucho más rápido que el antiguo ciclo de exportación. Una controller financiera dijo que era la primera vez que no tenía que esperar a la actualización nocturna de los datos para empezar su jornada.

La primera vez que el responsable de finanzas vio los datos de Oracle y de SAP juntos en un mismo panel, se quitó un peso de encima. Ese momento cerró el debate.

SAC también abarcaba más que finanzas. Operaciones quería una vista de la logística y los almacenes, y recursos humanos quería planificación de la plantilla. Tener la planificación, los informes y la visualización en una sola plataforma marcó la diferencia entre un parche táctico y una base a más largo plazo. Las plantillas predefinidas dieron al equipo una ventaja inicial, aunque algunas parecieran genéricas, y la rapidez de esa primera entrega devolvió la confianza tras meses de retraso.

Un apunte técnico si piensa copiar este diseño. Las conexiones de datos en vivo de SAC se limitan a fuentes SAP como SAP HANA, BW, S/4HANA, BPC embedded, los universos de BusinessObjects y SAP Datasphere. Los datos que no son de SAP, como un ERP Oracle, suelen entrar mediante una conexión de importación, un universo o una capa de datos intermedia. Decida esa arquitectura pronto, porque de ella depende lo frescas que pueden estar las cifras de cada lado.

El primer hito fue el modelo de datos. Oracle y SAP tenían que alimentar una misma estructura, y era más difícil de lo que parecía. Los campos tenían la misma etiqueta, pero significaban cosas distintas en cada sistema. Hicieron falta semanas de mapeo de definiciones hasta que finanzas se puso de acuerdo en qué significaban realmente ingresos, costos y margen.

Los paneles se desplegaron por fases. Primero finanzas, después ventas y operaciones, cada uno con informes construidos en torno a su trabajo real. Las primeras versiones resultaban demasiado rígidas. Los usuarios lo dijeron y tenían razón. Los paneles mejoraron y unos KPI acordados sustituyeron a lo que antes eran discusiones mensuales constantes.

El relanzamiento se completó en seis meses. Por primera vez, los datos de Oracle y de SAP convivían en un solo modelo dentro de SAC. Las discusiones sobre conciliaciones disminuyeron y los directivos revisaban las cifras sin esperar a que circularan archivos de Excel.

Los ciclos de planificación que antes llevaban semanas pasaron a llevar días. Los planificadores podían modelar escenarios y compararlos con los datos reales. Algunos directivos querían más detalle del que ofrecían los paneles, pero el hecho de que confiaran en las cifras ya era significativo.

Un jefe de almacén comentó que, por primera vez, los niveles de stock de su informe coincidían con los que mostraba finanzas. Esa alineación discreta entre departamentos fue el verdadero indicador. Nadie pidió volver al proceso anterior.

La tabla recoge los errores que paralizaron el proyecto y la lección de cada uno.

Error	Qué provocó	Lección
Gobernanza poco clara	Reuniones interminables, ninguna decisión, retrasos crecientes	Redefinir pronto los roles y los derechos de decisión
Deriva del alcance	Los objetivos de los informes no paraban de cambiar	Mantener el alcance acotado y ligado a las decisiones
Ignorar a los usuarios	Los usuarios perdieron confianza y la adopción se frenó	Implicar pronto a los usuarios y darles contexto
Exceso de personalización	Tiempo perdido reconstruyendo informes	Empezar con plantillas y conectores estándar; personalizar después
Gestión del cambio débil	La formación no dio en el blanco; los viejos hábitos se mantuvieron	Incorporar pronto campeones locales y coaching entre compañeros

Tres lecciones destacan sobre las demás. La gobernanza importa más que la herramienta: sin una responsabilidad clara en un entorno con varios ERP, los informes se desmoronan sea cual sea la plataforma. Hay que alinear las definiciones de datos antes de elegir la herramienta: el debate entre Power BI y SAC no daba en el clavo, porque ninguna herramienta arregla definiciones que no coinciden. Y la gestión del cambio decide la adopción: sin campeones y sin una comunicación bien dirigida, los paneles habrían quedado sin uso.

Cambiarían tres cosas si el mismo trabajo empezara hoy.

Habría una capa de datos entre SAC y las fuentes. SAP Datasphere, que hoy forma parte de SAP Business Data Cloud, da acceso federado a fuentes SAP y no SAP, con un modelo semántico encima. En un caso de dos ERP como este, armonizar los datos de Oracle y de SAP en esa capa es más limpio que hacerlo dentro de cada historia de SAC. Además, da a SAC una conexión en vivo con el modelo armonizado.

Las preguntas en lenguaje natural sustituirían algunas construcciones de paneles. La consulta en lenguaje natural de SAC y Joule permiten a finanzas pedir, por ejemplo, los ingresos por región del trimestre, Singapur frente al Reino Unido. No hace falta construir antes ninguna historia. Eso acelera el trabajo una vez armonizados los datos. No cierra una brecha de definiciones.

La conversación comercial partiría del contrato del ERP. Compruebe qué analítica incluye ya su contrato de ERP en la nube antes de negociar SAC. La planificación completa de SAC se licencia por separado, y los entornos híbridos, con una entidad en ERP en la nube y otra que no, siguen exigiendo un análisis cuidadoso de las licencias.

El reinicio de la gobernanza, la disciplina de alcance, los campeones locales y la comunicación a medida no cambiarían. Esos patrones valen sea cual sea la tecnología. El trabajo humano de lograr que dos ERP informen las mismas cifras no se automatiza. Para saber más sobre SAC, consulte mi guía de SAP Analytics Cloud.

¿Por qué se estancó el proyecto de informes ERP de este grupo FMCG?

Singapur trabajaba con Oracle y el Reino Unido con SAP, y cada mes finanzas unía las cifras a mano. Llevaba días y nadie confiaba del todo en el resultado. Las revisiones se atascaban cuando Singapur presentaba una cifra y el Reino Unido la rebatía con otra. Además, el comité directivo era demasiado grande, así que nadie tomaba decisiones. Los costos subieron, la confianza se resintió y el proyecto fue a la deriva.

¿Qué cambió el rumbo de la recuperación?

La dirección reconoció que el proyecto estaba atascado y acordó un plan de recuperación. El comité directivo se redujo a un grupo pequeño de quienes realmente decidían, se fijaron prioridades, se eligió SAP Analytics Cloud como única herramienta de informes y la comunicación pasó a adaptarse a cada audiencia. Las reuniones dejaron de buscar culpables y pasaron a ocuparse de lo que venía después, y la gente empezó a creer que el proyecto podía cumplir.

¿Cómo manejó SAP Analytics Cloud tanto Oracle como SAP?

SAC reunió los datos de Oracle y de SAP en un solo modelo de informes, de modo que ambos aparecían juntos en un único panel, sin archivos de conciliación manuales. Ver los dos sistemas en una sola vista fue el momento que puso fin al debate sobre la herramienta. Tenga en cuenta que las conexiones en vivo de SAC solo admiten fuentes SAP; los datos de Oracle suelen llegar mediante una conexión de importación, un universo de BusinessObjects o una capa de datos como SAP Datasphere.

¿Por qué los usuarios se resistieron al principio a los paneles?

Los paneles se lanzaron sin suficiente contexto de negocio. A los usuarios se les dijo que usaran SAC, pero nadie les mostró cómo se aplicaba a su trabajo diario, y la formación era genérica. La gente confía en lo que conoce, y los paneles aún no se habían ganado esa confianza. Los campeones locales, que explicaban los paneles con sus propias palabras, cambiaron eso.

¿Cómo es una recuperación exitosa de los informes ERP?

Rara vez es una sola cosa. Aquí fue un reinicio de la gobernanza, una reducción del alcance, definiciones acordadas, comunicación a medida y campeones entre compañeros trabajando juntos. SAC ayudó porque reunió ambos ERP en un solo modelo sin mucho desarrollo a medida, pero la tecnología por sí sola no habría salvado el proyecto. A los seis meses, quienes habían estado esperando a que se viniera abajo presentaban paneles que ellos mismos habían construido.