Caso FS:
automatización de extremo a extremo sin sacrificar el clean core

Existe una decisión silenciosa que separa los proyectos de tecnología que envejecen mal de los que se convierten en un activo estratégico. Casi nunca aparece en el business case, pero define todo lo que viene después: cuánto del problema resuelves dentro del core del ERP y cuánto resuelves fuera de él.

FS atravesó exactamente ese punto de decisión. Y la forma en que lo condujo, junto a Exed, transformó un proceso operativo crítico en un modelo de referencia para la industria. En palabras de Fernando Hamrick, CIO de la compañía, al evaluar el resultado: “tuvimos una reducción del 70% en el tiempo de procesamiento.” Pero la cifra, como veremos, es solo la punta visible de una elección de arquitectura mucho más profunda.

Quién es FS — y por qué el contexto importa

FS — Fueling Sustainability — es la primera productora de etanol e ingredientes para nutrición animal exclusivamente a partir del maíz, la tercera mayor productora de etanol de Brasil y la de menor costo de producción entre las más grandes del país. Lleva la sostenibilidad en su propio nombre, junto con una ambición que da la dimensión del negocio: convertirse en la mayor productora de combustible carbono negativo del mundo.

Las cifras de operación ayudan a entender la magnitud del desafío de TI que hay detrás: 5,4 millones de toneladas de maíz procesado, 2.400 millones de litros de capacidad productiva, 1,9 millones de toneladas de coproductos y 657.000 MWh de energía eléctrica generada al año.

Esa escala no es un accidente del mercado. El etanol de maíz pasó de 520 millones de litros en 2017 a cerca de 8.200 millones de litros en la zafra 2024/25 — un avance superior al 1.500% en menos de una década, según la Unión de la Industria de Caña de Azúcar y Bioenergía (UNICA). Para la zafra 2025/26, la Compañía Nacional de Abastecimiento (Conab) proyecta una producción récord, con el etanol de maíz superando los 10.000 millones de litros y representando más de una cuarta parte de todo el etanol brasileño. A diferencia de la caña, que es estacional, el maíz permite producción durante todo el año — lo que aporta regularidad al abastecimiento, pero también impone a la operación un ritmo continuo, sin entrezafra para “respirar”.

Como resume el propio Hamrick sobre la posición de la empresa: “somos los pioneros en traer el etanol de maíz a Brasil hace diez años.” Ser pionero en un sector que crece a esa velocidad significa una cosa para el área de tecnología: la operación no puede ser el cuello de botella del crecimiento.

El contexto: complejidad fiscal y logística que no cabe en un manual

FS opera en un entorno de alta complejidad logística y fiscal. Su cadena intercompany integra múltiples unidades productivas y diversos canales de distribución, con un volumen elevado de transacciones entre empresas del grupo y la exigencia de un cumplimiento riguroso de la regulación del sector.

En la práctica, vender el etanol producido implicaba una secuencia larga de etapas — creación de órdenes de venta, órdenes de compra, entregas, facturas, ajustes de valores en la gestión de patio, generación de flete — que dependían de la interacción manual y de un conocimiento concentrado en pocas personas. Era un proceso con un bajo nivel de madurez y un alto volumen operativo. El riesgo clásico: un error en cualquier eslabón de la cadena comprometía el plazo de entrega, la calidad del servicio y el cumplimiento fiscal.

El desafío que llegó a la mesa de tecnología, según Hamrick, era directo: “cómo ayudamos a la compañía a implementar un proceso totalmente automatizado para tomar esta cadena del etanol… y automatizarla por completo, sin embarcarnos en un proyecto megacomplejo, de mucha personalización en nuestro core.”

Esa última frase es la clave de todo. Aquí reside el dilema que todo CIO, COO y CFO reconoce. La salida fácil sería personalizar fuertemente el ERP hasta que hiciera exactamente lo que la operación pedía. Es el camino que parece más rápido — y es también el que crea la deuda técnica que aprisiona a la empresa años después. SAP es explícita sobre el costo de esa elección: con el tiempo, los entornos de ERP cargados de código personalizado, cambios no documentados e integraciones difíciles de mantener pierden flexibilidad, ralentizan las actualizaciones y elevan el costo total de propiedad. La propia estrategia de clean core de SAP nace para resolver esto: mantener el núcleo estandarizado y estable, y diferenciar el negocio mediante extensiones fuera del core.

El dato de Gartner refuerza la urgencia de la disciplina: la consultora proyecta que, para 2027, más del 70% de las iniciativas de ERP implementadas recientemente no cumplirán plenamente los objetivos de sus business cases originales. Buena parte de ese fracaso es arquitectónico — sistemas que se vuelven rígidos justamente por haber sido moldeados a la fuerza. FS optó por el camino opuesto: back to standard. Reducir personalizaciones, preservar la adherencia al core y buscar el máximo de automatización con el mínimo de fricción manual.

El punto de inflexión: la plataforma y la alianza

Definida la disciplina — automatizar sin inflar el core —, faltaba el cómo. La respuesta fue la SAP Business Technology Platform (BTP) como engranaje central de automatización y orquestación. En la arquitectura recomendada por SAP, BTP es exactamente la capa donde ocurre la innovación: extensiones side-by-side, integraciones y automatización que corren al lado del ERP, conectadas por APIs, sin tocar el núcleo. Es la traducción técnica del clean core.

Pero elegir la plataforma correcta no disuelve el riesgo de ser el primero en recorrer un camino. Hamrick es honesto sobre la vacilación inicial: “al principio teníamos algunas dudas sobre si realmente debíamos ir por un camino tan innovador, dado que en SAP BTP no teníamos nada aplicado de esa forma.”

Fue en ese momento cuando entró Exed — y la naturaleza de esa entrada es lo que diferenció al proyecto. No como proveedora de un software a medida, sino como socia de arquitectura. Según el CIO: “Exed demostró ser no solo una desarrolladora enfocada exclusivamente en entregar un software específicamente para nosotros, sino más bien una socia que nos ayudó a arquitectar una plataforma.” A medida que la relación maduró, la duda dio paso a la convicción de que ese era el mejor camino — y de que Exed era el socio adecuado para recorrerlo.

La solución: el Proyecto E-Log

E-Log construyó un proceso de venta–orden intercompany totalmente automatizado, con control de extremo a extremo e integración fiscal nativa. En lugar de personas cosiendo manualmente cada documento, el flujo pasó a generar de forma automática la orden de venta, la orden de compra, la entrega y la factura; a ajustar valores en la gestión de patio; a emitir la orden de flete; y a registrar la entrada física y la entrada fiscal virtual en la ECE — la Empresa Comercializadora de Etanol — sin intervención manual en cada paso.

Tres decisiones de arquitectura sostienen el resultado:

• BTP como orquestador, y el core intacto. La inteligencia del proceso vive fuera del ERP. El núcleo sigue siendo estándar, actualizable y estable — coherente con la estrategia clean core y con la meta declarada de simplificar futuras actualizaciones y reducir el costo de mantenimiento.
• Experiencia distribuida en 25 aplicaciones Fiori. El flujo se fragmentó en pantallas claras e intuitivas, con un bajo nivel de interacción manual. El operador deja de ser el motor del proceso para convertirse en su supervisor.
• Integración fluida entre negocio, TI y fiscal. Las tres áreas que suelen operar en silos pasaron a hablar el mismo idioma dentro del mismo flujo — lo que, en un proceso con tanta exposición tributaria, es tan importante como la automatización en sí.

Para dar la dimensión de ingeniería detrás de la simplicidad aparente: el proyecto entregó 264 vistas CDS, 18 servicios, 7 includes y un proceso descompuesto en 62 etapas (45 de salida y 17 de entrada). Todo ello operando sobre volúmenes reales — cerca de 380.000 m³ en el total de las operaciones, movilizados por más de 6.300 camiones, de los cuales aproximadamente 35.000 m³ en el proceso de exportación.

Los resultados: la lectura del propio CIO

“Fue un proyecto que trajo grandes ganancias a FS, y yo separaría esas ganancias en tres grandes bloques”, dice Hamrick. Vale la pena seguir su estructura, porque mapea con precisión a los tres interlocutores ejecutivos del caso — el CFO, el COO y el CIO.

1. Viabilización de una operación nueva (la lectura del CFO). La primera ganancia no es eficiencia — es ingresos y margen. Con la operación automatizada, el 100% del volumen de la productora pasó a ser procesado por la ECE, habilitando el crédito de ICMS (IVA estatal) sobre el flete y optimizando directamente el EBITDA. En otras palabras: la tecnología destrabó un arreglo fiscal que antes era inviable de operar a escala. Es el tipo de ganancia que aparece en el resultado financiero de la compañía, no solo en el informe de TI.

2. Productividad (la lectura del COO). Un proceso que tomaba, en promedio, 15 minutos pasó a completarse en cuatro a cinco. En el proceso de exportación, la reducción en el tiempo de creación del flujo de documentos llegó al 70%. Sumando las ganancias a lo largo del año, fueron más de 20.000 horas de tiempo optimizado — capacidad operativa liberada sin contratar a una sola persona más.

3. Escalabilidad (la lectura del CIO). Aquí está la parte más técnica y, quizás, la más estratégica. FS evitó prácticamente 12.000 horas de desarrollo dentro de su propio core y redujo en un 66% los desarrollos que existían en su SAP — dos de cada tres simplemente dejaron de existir. Más del 90% de las personalizaciones pasaron a vivir fuera del core. “Evitamos prácticamente 12.000 horas de desarrollo dentro de nuestro core”, resume el CIO. El proceso ganó trazabilidad y monitoreo online de lo que está ocurriendo, totalmente integrado y de manera síncrona con el core.

SAP estima que alrededor del 70% de los procesos de negocio pueden estandarizarse y automatizarse bajo una estrategia de clean core, con actualizaciones más rápidas y un menor costo operativo. E-Log es una demostración concreta de ese principio aplicado a un proceso de misión crítica.

El futuro: una base, no un proyecto

La ganancia más subestimada de una arquitectura limpia es lo que permite después. La plataforma construida para E-Log no resolvió solo la operación que estaba sobre la mesa en aquel momento — dejó lista la base para las próximas. Cada nueva operación que FS quiera automatizar parte ahora de un nivel más alto, reaprovechando lo que ya existe, en lugar de empezar desde cero.

Es la diferencia entre comprar una solución y construir una capacidad. La escalabilidad dejó de ser una promesa de diapositiva para convertirse en una característica de arquitectura: FS puede crecer sin que el costo operativo crezca en la misma proporción. En un sector que se expande a dos dígitos al año, eso no es un alivio — es una ventaja competitiva.

El papel de Exed

Lo que Exed entregó no fue un software; fue una arquitectura y un modelo de referencia. La combinación de experiencia en el sector con dominio de proyectos SAP BTP permitió transformar un proceso crítico — y fiscalmente sensible — en un estándar replicable para la industria. El papel fue el de quien diseña los cimientos para que sostengan no solo el edificio de hoy, sino los pisos que aún vendrán.

El cierre de Hamrick sintetiza el valor de la alianza mejor que cualquier métrica aislada: “desde el punto de vista de innovación, gobernanza, controles y escala — que era nuestro principal objetivo —, alcanzar nuestras metas… Exed nos ayudó con eso.”

Lo que enseña el caso FS

Para un ejecutivo, la lección de E-Log no es sobre etanol ni sobre BTP. Es sobre una elección de principio: la mejor forma de automatizar un proceso crítico rara vez es doblar el ERP hasta que quepa en la operación. Es mantener el core limpio y mover la complejidad a una capa hecha para cambiar.

Cuando esa disciplina se respeta, las tres ganancias del caso FS dejan de ser la excepción y se vuelven la regla: margen destrabado para el CFO, capacidad liberada para el COO y deuda técnica evitada para el CIO. Innovación, gobernanza y escala no tienen que ser objetivos en competencia. Con la arquitectura correcta, son el mismo objetivo.