DEV Community: Datalaria

Clarity AI: How Rebeca Minguela and AI Are Redefining and Quantifying Financial Sustainability

Daniel — Fri, 03 Apr 2026 08:11:46 +0000

In the intersection between cutting-edge technological innovation and global regulatory pressure, the efficient allocation of capital towards sustainable goals has become the most complex macroeconomic challenge of the 21st century. For decades, this effort has been burdened by analog methodologies: traditional rating agencies that relied on the subjective judgments of human analysts to issue opaque assessments on corporate performance. This "black box" created a profound disconnect with reality and left the doors wide open for the dreaded greenwashing.

In this landscape of informational chaos, Clarity AI was born in 2017—a technology platform with a disruptive foundational premise: to leverage Artificial Intelligence (AI), Machine Learning, and Big Data to transform sustainability into a quantifiable, auditable, and globally scalable science. Behind this massive architectural milestone is the Spanish engineer and entrepreneur, Rebeca Minguela.

The Founder’s Profile: Technical Rigor and Global Vision

The unprecedented success of Clarity AI is inseparable from Minguela’s trajectory. Born in Cuéllar (Spain), she forged a mindset geared toward absolute precision through her honors degrees in Telecommunications Engineering from the Universidad Politécnica de Madrid (UPM) and the University of Stuttgart. Her early professional years in high-demand environments, such as the German Space Agency and Siemens, cemented her zero-tolerance for systemic failures.

She subsequently rounded out her analytical profile with an MBA from Harvard Business School, venturing into the insular ecosystem of private equity with firms like Bain Capital. It was there that she identified the systemic flaw: capital flowed based on corporate narratives because there were no tools to objectively measure the true impact of investment portfolios.

Backed by her proven entrepreneurial capacity (she founded the successful startup Blink Booking, which was acquired by Groupon within 18 months) and her experience leading the digital transformation at Banco Santander, Minguela conceived Clarity AI to solve this massive bottleneck.

The Technological Solution: From Opinion to Computational Evidence

Clarity AI shatters the analog paradigm by pioneering an API-first and AI-native approach. Instead of armies of people filling out annual spreadsheets, Clarity AI’s platform deploys complex Natural Language Processing (NLP) and Machine Learning algorithms that ingest and process tens of millions of data points bi-weekly.

These engines consume regulatory reports, financial news, NGO databases, and even data from satellite remote sensing, substituting subjective "Ratings" with hyper-granular "Scores". Within the platform, 100% of the information—from a company's gender pay gap to its carbon-equivalent emissions—is mathematically traceable back to its original primary source, providing the investor with the highly sought-after "Explainable AI" (XAI).

Furthermore, to mitigate the chronic lack of information in private or emerging markets, Clarity AI's data scientists employ parametric inference models. Through complex predictive proxy triangulations, they successfully estimate hidden impacts (such as elusive Scope 3 emissions), effectively tripling the coverage of the financial universe and warding off enormous legal risks for asset managers.

Institutional Backing and Retail Reach

The architectural superiority of this Amazon Web Services (AWS)-based ecosystem has dazzled global venture capital, attracting over $335 million in funding from giants such as the SoftBank Vision Fund, Seaya Ventures, and, above all, BlackRock. The deep and native integration of Clarity AI into Aladdin (BlackRock's omnipotent operating system) definitively established the Spanish firm as the inescapable backbone of global sustainable finance.

However, Minguela's vision stretched far beyond Wall Street. In 2025, Clarity AI strategically acquired the Berlin-based fintech ecolytiq in a key cross-border operation, simultaneously establishing a powerful synergy with the multinational payments giant Visa. This move scaled the AI down to the citizen's pocket: inserting "Sustainability-as-a-Service" technology directly into retail banking applications (such as HSBC Kinetic). Now, advanced algorithms educate consumers in real time about the carbon footprint of their daily purchases, enabling automated micro-donations and channeling domestic capital toward the climate transition.

The 2026 Horizon: SFDR 2.0 and the "Verification Tax"

Despite its dominant position—unanimously recognized by analysts like Forrester—the future poses colossal challenges for financial planning systems.

Global Regulatory Divergence: While Europe prepares the draconian framework of SFDR 2.0 (which threatens to re-categorize 40% of current "green funds" if they fail to meet stricter metrics), the United States grapples with a tense socio-political "ESG Backlash". Clarity's algorithms will have to simultaneously navigate contradictory jurisdictions without service friction.
The "Verification Tax": With the massive deployment of GenAI and LLMs, the risk of systematic "hallucinations" (the swift propagation of synthetic errors rooted in false data) threatens the global economy. Clarity AI's competitive advantage is no longer merely the raw capacity to process information, but an absolute algorithmic hygiene that keeps its Scores unassailable against government fines.
The Thermodynamic Paradox: A fascinating challenge. The immense neural networks required to monitor the climate consume vast amounts of electricity (often from non-renewable sources) and millions of liters of fresh water for cooling. Clarity AI has actively advocated for instituting transparent "Responsible AI" frameworks, ensuring that the technological cure does not end up devouring the very resources it aims to protect.

Conclusion

The global consolidation of Clarity AI—and the exemplary technical leadership career forged by Rebeca Minguela—proves an irrevocable phenomenon: transformational changes in our global survival ecosystem are not achieved through sheer commercial goodwill, but by building elastic, mathematically infallible codebase infrastructures.

Clarity AI has not merely created outstanding software; it has grown to become the de facto tectonic plate upon which planetary sustainability orbits, is legislated, and is arbitrated. Faced with the inorganic chaos of Big Data and the incessant labyrinth of global regulations, Minguela's mathematics have, once again, conquered the fog.

Sources of Interest:

Clarity AI: Cómo Rebeca Minguela y la IA Están Redefiniendo y Cuantificando la Sostenibilidad Financiera

Daniel — Fri, 03 Apr 2026 08:08:04 +0000

En la intersección entre la innovación tecnológica puntera y la presión regulatoria global, la asignación eficiente del capital hacia fines sostenibles se ha convertido en el desafío macroeconómico más complejo del siglo XXI. Durante décadas, este esfuerzo ha estado lastrado por metodologías analógicas: agencias de calificación tradicionales que dependían de los juicios subjetivos de analistas humanos para emitir dictámenes opacos sobre el desempeño corporativo. Esta "caja negra" generaba una profunda desconexión con la realidad y abría las puertas de par en par al temido greenwashing.

En este escenario de caos informativo, nace en 2017 Clarity AI, una plataforma tecnológica con una premisa fundacional disruptiva: utilizar la Inteligencia Artificial (IA), el Machine Learning y el Big Data para transformar la sostenibilidad en una ciencia cuantificable, auditable y escalable globalmente. Y detrás de este gigantesco hito arquitectónico se encuentra la ingeniera y emprendedora Rebeca Minguela.

El Perfil de la Fundadora: Rigor Técnico y Visión Global

El éxito sin precedentes de Clarity AI es inseparable de la trayectoria de Minguela. Nacida en Cuéllar (España), forjó una mentalidad orientada a la precisión absoluta mediante sus estudios con matrícula de honor en Ingeniería de Telecomunicaciones por la Universidad Politécnica de Madrid (UPM) y la Universidad de Stuttgart. Sus primeros años profesionales en entornos de alta exigencia, como la Agencia Espacial Alemana y Siemens, cimentaron su tolerancia cero a los fallos sistémicos.

Posteriormente, completó su perfil analítico con un MBA en la Harvard Business School, adentrándose en el hermético ecosistema del capital inversión con firmas como Bain Capital. Fue allí donde identificó la falla sistémica: el capital fluía basándose en narrativas corporativas porque no existían herramientas para medir objetivamente el verdadero impacto de las carteras de inversión.

Respaldada por su demostrada capacidad emprendedora (fundó la exitosa startup Blink Booking, adquirida por Groupon en 18 meses) y su experiencia liderando la transformación digital en Banco Santander, Minguela concibió Clarity AI para solucionar este inmenso cuello de botella.

La Solución Tecnológica: De la Opinión a la Evidencia Computacional

Clarity AI rompe el paradigma analógico siendo pionera en un enfoque API-first y AI-native. En lugar de ejércitos de personas rellenando hojas de cálculo anuales, la plataforma de Clarity AI despliega complejos algoritmos de Procesamiento de Lenguaje Natural (NLP) y Machine Learning que ingieren y procesan quincenalmente decenas de millones de puntos de datos.

Estos motores consumen informes regulatorios, noticias financieras, bases de datos de ONGs e incluso datos procedentes de teledetección satelital, sustituyendo las subjetivas "calificaciones" (Ratings) por "puntuaciones" (Scores) hiper-granulares. En la plataforma, el 100% de la información —desde la brecha salarial de género de una empresa hasta sus emisiones de carbono equivalentes— es matemáticamente rastreable hasta su fuente primaria original, dotando al inversor de la tan ansiada "explicabilidad predictiva" (XAI).

Además, para paliar la crónica falta de información en mercados privados o emergentes, los científicos de datos de Clarity AI emplean modelos paramétricos de inferencia que logran estimar, mediante complejas triangulaciones proxy, el impacto oculto (como las emisiones limitantes de Alcance 3), triplicando la cobertura efectiva del universo financiero y conjurando enormes riesgos legales para las gestoras.

El Respaldo Institucional y la Capilaridad Minorista

La superioridad arquitectónica de este ecosistema basado en Amazon Web Services (AWS) ha deslumbrado al capital riesgo mundial, atrayendo más de 335 millones de dólares en financiación de gigantes como el SoftBank Vision Fund, Seaya Ventures y, sobre todo, BlackRock. La profunda y nativa integración de Clarity AI dentro de Aladdin (el omnipotente sistema operativo de BlackRock) consagró a la empresa española como la ineludible capa base (backbone) de las finanzas globales.

Sin embargo, el objetivo de Minguela iba mucho más allá de Wall Street. En 2025, Clarity AI adquirió estratégicamente la fintech berlinesa ecolytiq en una operación transfronteriza clave, estableciendo a su vez una potente sinergia con la multinacional Visa. Este movimiento permitió escalar la IA hasta el bolsillo del ciudadano: insertando tecnología de "Sustainability-as-a-Service" directamente en aplicaciones de banca minorista (como HSBC Kinetic). Ahora, algoritmos avanzados educan en tiempo real al consumidor sobre la huella de carbono de sus compras diarias, permitiendo micro-donaciones automatizadas y canalizando el capital doméstico hacia la transición climática.

El Horizonte 2026: SFDR 2.0 y el "Impuesto de Verificación"

A pesar de su posición dominante, reconocida unánimemente por analistas como Forrester, el futuro plantea colosales desafíos para los sistemas S&OP (Sales and Operations Planning) financieros.

La Divergencia Regulatoria Mundial: Mientras Europa prepara el draconiano marco de la SFDR 2.0 (que amenaza con re-categorizar al 40% de los actuales "fondos verdes" si no cumplen métricas más estrictas), Estados Unidos lidia con un tenso "ESG Backlash" socio-político. Los algoritmos de Clarity tendrán que navegar simultáneamente por jurisdicciones contradictorias sin fricciones de servicio.
El "Impuesto de Verificación": Con el uso masivo de GenAI y LLMs, el riesgo de "alucinaciones" sistemáticas (la propagación veloz de errores sintéticos originados en datos falsos) amenaza a la economía global. La ventaja competitiva de Clarity AI ya no es la mera capacidad de procesar, sino la absoluta higiene algorítmica que mantiene sus "Scores" inexpugnables frente a las multas gubernamentales.
La Paradoja Termodinámica: Un desafío fascinante. Las inmensas redes neuronales necesarias para monitorizar el clima consumen vastas cantidades de electricidad (a menudo no renovable) y millones de litros de agua dulce para su refrigeración. Clarity AI ha instado activamente a instaurar y transparentar normativas propias de Inteligencia Artificial Responsable (Responsible AI), asegurando que el remedio no acabe devorando los escasos recursos que trata de proteger.

Conclusión

La consolidación mundial de Clarity AI —y la ejemplar carrera de liderazgo técnico forjada por Rebeca Minguela— demuestra un fenómeno irrevocable: los cambios transformacionales en el ecosistema global de supervivencia no se acometen mediante buena voluntad comercial, sino construyendo infraestructuras de código elásticas y matemáticas infalibles.

Clarity AI no se ha limitado a crear un software sobresaliente; se ha convertido de facto en la placa tectónica sobre la que orbita, se legisla y se arbitra la sostenibilidad planetaria. Ante el caos inorgánico del Big Data y el incesante laberinto regulatorio mundial, las matemáticas de Minguela han vuelto a dominar la niebla.

Fuentes de Interés:

Nextail: Cómo la IA Prescriptiva de una Startup Española Está Derrotando a Excel en el Retail de Moda

Daniel — Tue, 31 Mar 2026 06:12:06 +0000

En el competitivo universo del fast fashion, donde las tendencias nacen y mueren en semanas y una talla equivocada en la tienda equivocada puede significar la diferencia entre vender a precio completo o malvender en rebajas, hay una verdad incómoda que la industria ha tardado décadas en aceptar: las decisiones más críticas del negocio—qué enviar, a dónde y cuándo—se siguen tomando con hojas de cálculo, intuición y mapas mentales.

Esta es la historia de Nextail, una startup madrileña fundada en 2014 por un equipo que conocía esa realidad desde dentro y decidió destruirla con matemáticas. Es el caso de estudio de cómo la analítica prescriptiva y la optimización estocástica están sustituyendo al Excel en una industria que mueve miles de millones.

El Origen: Cuando Zara No Era Suficiente

La génesis de Nextail está ligada directamente al epicentro del fast fashion global. Joaquín Villalba, ingeniero industrial por la Universidad Politécnica de Valencia con un MBA por INSEAD, ejerció como Director de Logística Europea en Zara-Inditex, donde supervisó operaciones para más de mil tiendas con un volumen de ventas superior a los 10.000 millones de dólares. Desde esa atalaya privilegiada, Villalba analizó los cimientos del imperio de Amancio Ortega y llegó a una conclusión que definiría su carrera: el modelo logístico de Zara era revolucionario en su estructura, pero las decisiones diarias sobre qué enviar a cada tienda seguían dependiendo de la intuición humana.

Los clientes se marchaban frustrados sin encontrar su talla. La causa no era falta de stock global, sino una distribución demasiado estática para reaccionar a las fluctuaciones micro-locales de la demanda. Villalba vio una oportunidad inmensa para llevar la agilidad del retail al siguiente nivel inyectando ciencia de datos e investigación operativa directamente en el núcleo del merchandising.

Para materializar esta visión se asoció con Carlos Miragall, un experto en finanzas corporativas con experiencia escalando startups desde cero hasta más de 150 empleados y levantando más de 60 millones de dólares en financiación, y con Javier Lafuente García como CTO. Juntos fundaron Nextail con una misión diáfana: democratizar la excelencia operativa del fast fashion mediante la precisión matemática.

El Problema: La Explosión Combinatoria que Destruye a Excel

Para entender por qué Nextail existe, hay que comprender un fenómeno matemático que los equipos de merchandising sufren cada día: la explosión combinatoria. Un retailer de moda no toma decisiones agregadas. Cruza miles de productos (SKUs), multiplicados por varias tallas, distribuidos en cientos de tiendas, con actualizaciones necesarias varias veces por semana. El resultado: millones de puntos de decisión diarios.

Las hojas de cálculo colapsan. Literalmente. Como señala Mark Scouller, veterano del merchandising en firmas como Next, New Look y Mountain Warehouse, los equipos lidian con archivos que se bloquean al superar el medio millón de filas, sostenidos por miles de macros que se rompen con cualquier cambio.

Pero el colapso técnico es solo la superficie. Las consecuencias de negocio son devastadoras:

Agrupamiento forzado de tiendas (Store Clustering): Incapaces de calcular la demanda por tienda individual, los equipos agrupan establecimientos en categorías amplias y aplican distribuciones homogéneas. El resultado: sobrestock en unas tiendas y roturas en otras del mismo clúster.
Dependencia del "mapa mental": Las decisiones terminan basándose en la intuición subjetiva del buyer, un enfoque ciego ante cambios de tendencia intersemanales.
El abandono de la "clase media": Los equipos dedican todo su tiempo a reponer los best-sellers agotados o liquidar los peores productos, abandonando completamente los mid-sellers y las tiendas de volumen medio. Como resume Scouller: son precisamente estos productos ignorados los que "drenan el margen de beneficio de forma silenciosa".
Rebajas destructivas: La lentitud procedimental obliga a ejecutar campañas de markdowns masivas al final de temporada para liquidar inventario acumulado.

"El futuro del retail no cabe en Excel" — Mark Scouller

La Solución: Un Cerebro Matemático que Piensa en Probabilidades

La arquitectura de Nextail ataca el problema en tres capas perfectamente orquestadas dentro del proceso S&OP (Sales and Operations Planning):

1. Datos "Listos para IA" (Data Ingestion & Optimization)

La premisa fundacional es la pureza del dato. Los conjuntos de datos del retailer provienen de una miríada de sistemas inconexos (ERPs, WMS, POS). La plataforma consolida y limpia toda esta información diariamente, corrigiendo fenómenos como el "stock fantasma" (donde el sistema indica existencias de prendas que han sido robadas o extraviadas), imputando valores nulos y generando una única fuente de verdad que elimina la fricción entre departamentos.

2. Predicción Probabilística Hiperlocal

A diferencia del forecasting tradicional que genera un único número de previsión, los algoritmos de Nextail construyen una distribución completa de probabilidad para cada combinación de SKU, tienda y día. No solo anticipan el volumen esperado; cuantifican la incertidumbre. Esa previsión se calibra con restricciones reales: capacidad de trastienda, logísticas de empaquetado, distribución de tallas por demografía del código postal, y mínimos de presentación visual.

3. Optimización Prescriptiva (El Motor MILP)

Aquí reside la verdadera innovación. Cuando el modelo probabilístico dicta cuánta demanda ocurrirá, dónde y cuándo, el sistema debe prescribir la acción operativa exacta. Para ello despliega algoritmos de Programación Lineal Entera Mixta (MILP) combinados con optimización estocástica.

En términos conceptuales, el motor resuelve una función objetivo que maximiza la probabilidad de venta a precio completo (full-price sell-through) de cada SKU en cada tienda, ponderada por el margen bruto, menos los costes logísticos de cada transferencia. Todo ello sujeto a restricciones infranqueables: conservación de inventario, espacio físico disponible, estándares estéticos de la marca, y coherencia en la distribución de curvas de tallas.

El sistema evalúa miles de millones de permutaciones y decide: ¿es más rentable retener stock en el centro de distribución para proteger el e-commerce, o despacharlo de urgencia a una tienda con alta probabilidad inminente de rotura de stock?

El resultado no es un informe estático, sino una directiva de ejecución accionable entregada a los sistemas ERP y WMS en minutos. La automatización libera hasta el 75% del tiempo de los equipos de merchandising para reenfocarse en decisiones estratégicas.

Más Allá de la Asignación: El Rebalanceo Inteligente

Una de las funcionalidades más disruptivas de Nextail es el rebalanceo de inventario entre tiendas (Store Transfers). Cuando los productos se acercan al final de su ciclo de vida, la demanda se fragmenta: unas tiendas tienen exceso de tallas que nadie quiere, mientras otras necesitan exactamente esas tallas.

Tradicionalmente, ese stock remanente iba directo a rebajas. Nextail hace lo contrario: el optimizador rastrea pares de tiendas origen-destino, calcula si el aumento de probabilidad de venta a precio completo justifica el coste logístico de la transferencia, y reagrupa activamente las tallas desparejadas en centros de demanda activa. Así, las rebajas dejan de ser un mal endémico para convertirse en una herramienta de ultimísimo recurso.

El Impacto: ROI en 30 Días

La analítica prescriptiva no sería relevante sin resultados. Los números de Nextail hablan con contundencia:

Métrica	Impacto
Cobertura de inventario	Reducción de hasta un 30%
Roturas de stock	Disminución de hasta un 60%
Ventas directas	Incremento del 5-10%
Tiempo de merchandisers liberado	Hasta un 75%
ROI demostrable	En los primeros 30 días

Marcas internacionales como Pepe Jeans, River Island, Guess, Scotta, Bimani, Silbon y Sports Emotion han integrado la plataforma para superar los cuellos de botella de su escalado omnicanal. El caso de Pepe Jeans es particularmente ilustrativo: una marca con lead times de hasta seis meses que pasó de previsiones estáticas a una optimización dinámica capaz de adaptarse al consumidor en semanas.

La Trayectoria Financiera y la Transición de Liderazgo

La cronología corporativa revela un patrón de crecimiento respaldado por la élite del capital riesgo europeo:

Ronda	Fecha	Cantidad (USD)	Inversor(es) Principal(es)
Seed	2016	$1.6M	Nauta Capital
Serie A	Jun 2018	$10M	Nauta Capital
Inversión 2024	Nov 2024	Multi-millonaria	Inversores existentes

Tras una década liderando la visión del producto y posicionando la plataforma para automatizar más de mil millones de decisiones de inventario por temporada en un parque de 20.000 tiendas, Joaquín Villalba orquestó una sucesión ejecutiva en 2024. Adoptó el rol de Embajador Corporativo—en línea con su reconocimiento como Pionero Tecnológico por el Foro Económico Mundial—y cedió la dirección ejecutiva a Carlos Miragall, cofundador y ex-CFO, para capitanear la compañía en la era de los LLMs y los sistemas agénticos.

El reconocimiento institucional ha sido contundente: Mejor Plataforma de Merchandising de Retail de Moda 2025 (EU Business News), triple victoria en los Just Style Excellence Awards 2025, y reconocimiento reiterado como Representative Vendor por Gartner en sus guías de mercado de optimización retail.

La Montaña Sociológica: El Mayor Obstáculo No Es la Tecnología

A pesar de la superioridad técnica, el mayor obstáculo para la adopción no es computacional—es humano. Como advierte Mark Lewis, estratega tecnológico del retail: "La mayor barrera para el éxito de la IA en la moda es pura y exclusivamente una cuestión de mentalidad colectiva".

Existe una peligrosa falacia que percibe la IA como "magia oscura" incomprensible. Esto genera expectativas irreales en las directivas o un rechazo visceral por parte de los profesionales de merchandising que temen al dictamen de la "caja negra". Los retailers invierten millones en plataformas que terminan infrautilizadas porque no han reestructurado sus equipos ni invertido en formación.

La clave, según Scouller, es entender que la IA "no es magia oscura, sino lógica aplastante: procesamiento masivo de datos limpios y la aplicación iterativa de matemáticas a una escala y velocidad inhumanas". Y el punto de inflexión corporativo se alcanza en un momento muy concreto: cuando el dolor de la ineficiencia supera a la inercia del confort operativo.

El Futuro: IA Generativa, Agentes Autónomos y el Escudo Regulatorio ESPR

La hoja de ruta de Nextail converge en tres fuerzas que definirán el retail de 2026:

1. Interfaz Conversacional con RAG: La IA Generativa no reemplazará los motores de optimización MILP (los LLMs fallan en cálculo numérico masivo a coste eficiente). Su papel será actuar como capa de orquestación cognitiva: un director comercial podrá interactuar con el cerebro matemático en lenguaje natural, pidiendo análisis de rentabilidad de un rebalanceo concreto y autorizando ejecuciones automáticas.

2. Sistemas Multi-Agente de IA: Gartner proyecta que para finales de 2026, más del 40% de las aplicaciones empresariales incorporarán agentes de IA. En el contexto del S&OP, un "enjambre" de agentes monitorizará autónomamente variables volátiles—clima, roturas en la cadena, viralidad de tendencias en redes sociales—y recalibrará el optimizador sin intervención humana.

3. El Escudo ESPR: El marco regulatorio europeo ESPR 2026 penalizará (incluso prohibirá) la destrucción de inventario textil no vendido. Los sobrantes ya no serán "costes hundidos" sino pasivos ambientales auditables. En este contexto, la capacidad de Nextail para reducir la sobreproducción y minimizar leftovers deja de ser solo una ventaja financiera para convertirse en un requisito de supervivencia legal.

Conclusión: Las Matemáticas Ganan la Partida

La historia de Nextail es la crónica de una industria que ha cruzado un punto de no retorno. La complejidad del retail omnicanal moderno ha superado definitivamente la capacidad humana de gestión manual. Las hojas de cálculo no son un inconveniente menor; son un riesgo sistémico que drena silenciosamente los márgenes de beneficio.

Nextail ha demostrado que la respuesta reside en la fusión de predicción probabilística, optimización estocástica y una cultura de datos limpia. Su viaje demuestra que, a veces, la revolución no llega con una idea completamente nueva, sino con la aplicación rigurosa de las matemáticas a un problema que todos daban por perdido.

Como Villalba descubrió en los pasillos de Zare: la agilidad del futuro no se construye con intuición, sino con ecuaciones.

Fuentes de Interés:

Nextail: How a Spanish Startup's Prescriptive AI Is Defeating Excel in Fashion Retail

Daniel — Tue, 31 Mar 2026 06:03:52 +0000

In the cutthroat world of fast fashion, where trends are born and die in weeks and the wrong size in the wrong store can mean the difference between selling at full price or slashing margins in clearance sales, there's an uncomfortable truth the industry has taken decades to accept: the most critical business decisions—what to ship, where, and when—are still being made with spreadsheets, gut feeling, and mental maps.

This is the story of Nextail, a Madrid-based startup founded in 2014 by a team that knew that reality from the inside and decided to destroy it with mathematics. It is a case study of how prescriptive analytics and stochastic optimization are replacing Excel in an industry worth billions.

The Origin: When Zara Wasn't Enough

Nextail's genesis is directly linked to the epicenter of global fast fashion. Joaquín Villalba, an industrial engineer from the Universitat Politècnica de València with an MBA from INSEAD, served as European Logistics Director at Zara-Inditex, where he oversaw operations for over a thousand stores with annual sales exceeding $10 billion. From that privileged vantage point, Villalba analyzed the foundations of Amancio Ortega's empire and reached a conclusion that would define his career: Zara's logistics model was revolutionary in its structure, but daily decisions about what to send to each store still depended on human intuition.

Customers left frustrated without finding their size. The cause wasn't a lack of global stock, but a distribution model too static to react to micro-local demand fluctuations. Villalba saw an immense opportunity to take retail agility to the next level by injecting data science and operations research directly into the core of merchandising.

To bring this vision to life, he partnered with Carlos Miragall, a corporate finance expert with experience scaling startups from scratch to over 150 employees and raising more than $60 million in funding, and Javier Lafuente García as CTO. Together they founded Nextail with a clear mission: democratize the operational excellence of fast fashion through mathematical precision.

The Problem: The Combinatorial Explosion That Breaks Excel

To understand why Nextail exists, you need to grasp a mathematical phenomenon that merchandising teams endure daily: the combinatorial explosion. A fashion retailer doesn't make aggregated decisions. It crosses thousands of products (SKUs), multiplied by several sizes, distributed across hundreds of stores, requiring updates several times a week. The result: millions of decision points every day.

Spreadsheets collapse. Literally. As Mark Scouller notes, a merchandising veteran at firms like Next, New Look, and Mountain Warehouse, teams deal with files that freeze beyond half a million rows, held together by thousands of interdependent macros that break with any change.

But the technical collapse is just the surface. The business consequences are devastating:

Forced Store Clustering: Unable to calculate demand per individual store, teams group locations into broad categories and apply uniform distributions. The result: overstock in some stores and stockouts in others within the same cluster.
"Mental Map" Dependency: Decisions end up relying on the buyer's subjective intuition, an approach blind to week-over-week trend shifts.
The Abandoned "Middle Class": Teams spend all their time replenishing sold-out best-sellers or liquidating worst-sellers, completely neglecting mid-sellers and mid-tier stores. As Scouller puts it: these ignored products are the ones that "silently drain profit margins."
Destructive Markdowns: Procedural slowness forces massive end-of-season clearance campaigns to liquidate accumulated inventory.

"The future of retail doesn't fit in Excel" — Mark Scouller

The Solution: A Mathematical Brain That Thinks in Probabilities

Nextail's architecture attacks the problem across three perfectly orchestrated layers within the S&OP (Sales and Operations Planning) process:

1. "AI-Ready" Data (Data Ingestion & Optimization)

The foundational premise is data purity. Retailer datasets come from a myriad of disconnected systems (ERPs, WMS, POS). The platform consolidates and cleanses all this information daily, correcting phenomena like "phantom stock" (where the system reports inventory for garments that have been stolen or misplaced), imputing null values, and generating a single source of truth that eliminates friction between departments.

2. Hyper-Local Probabilistic Forecasting

Unlike traditional forecasting that produces a single prediction number, Nextail's algorithms build a complete probability distribution for each combination of SKU, store, and day. They don't just anticipate expected volume; they quantify uncertainty. That forecast is then calibrated against real constraints: backroom capacity, packing logistics, size distribution by ZIP code demographics, and minimum display requirements.

3. Prescriptive Optimization (The MILP Engine)

This is where the real innovation lives. Once the probabilistic model dictates how much demand will occur, where, and when, the system must prescribe the exact optimal operational action. To do this, it deploys Mixed-Integer Linear Programming (MILP) algorithms combined with stochastic optimization.

Conceptually, the engine solves an objective function that maximizes the probability of full-price sell-through for each SKU at each store, weighted by gross margin, minus the logistics costs of each transfer. All subject to hard constraints: inventory conservation, available physical space, brand aesthetic standards, and size curve coherence.

The system evaluates billions of permutations and decides: is it more profitable to hold stock at the distribution center to protect e-commerce, or rush it to a store showing high imminent probability of a stockout?

The output isn't a static report, but an actionable execution directive delivered to ERP and WMS systems within minutes. This automation frees up to 75% of merchandising teams' time to refocus on strategic decisions.

Beyond Allocation: Intelligent Rebalancing

One of Nextail's most disruptive features is inventory rebalancing between stores (Store Transfers). As products approach end-of-life, demand fragments: some stores have excess sizes nobody wants, while others need exactly those sizes.

Traditionally, that leftover stock went straight to markdowns. Nextail does the opposite: the optimizer scans store pairs, calculates whether the increase in full-price sale probability justifies the logistics cost of the transfer, and actively regroups broken size curves into active demand centers. This way, markdowns stop being an endemic evil and become a tool of absolute last resort.

The Impact: ROI in 30 Days

Prescriptive analytics wouldn't matter without results. Nextail's numbers speak for themselves:

Metric	Impact
Inventory coverage	Reduction of up to 30%
Stockouts	Decrease of up to 60%
Direct sales	Increase of 5-10%
Merchandiser time freed	Up to 75%
Demonstrable ROI	Within the first 30 days

International brands such as Pepe Jeans, River Island, Guess, Scotta, Bimani, Silbon, and Sports Emotion have integrated the platform to overcome the bottlenecks of their omnichannel scaling. The Pepe Jeans case is particularly illustrative: a brand with lead times of up to six months that shifted from static forecasts to dynamic optimization capable of adapting to consumer behavior in weeks.

Financial Trajectory and Leadership Transition

The corporate timeline reveals a growth pattern backed by the European venture capital elite:

Round	Date	Amount (USD)	Lead Investor(s)
Seed	2016	$1.6M	Nauta Capital
Series A	Jun 2018	$10M	Nauta Capital
2024 Investment	Nov 2024	Multi-million	Existing investors

After a decade leading the product vision and positioning the platform to automate over one billion inventory decisions per season across a park of 20,000 stores, Joaquín Villalba orchestrated an executive succession in 2024. He adopted the role of Corporate Ambassador—in line with his recognition as a World Economic Forum Tech Pioneer—and handed the CEO position to Carlos Miragall, co-founder and former CFO, to captain the company into the era of LLMs and agentic systems.

Institutional recognition has been emphatic: Best Fashion Retail Merchandising Platform 2025 (EU Business News), triple victory at the Just Style Excellence Awards 2025, and repeated recognition as a Representative Vendor by Gartner in their retail optimization market guides.

The Sociological Mountain: The Biggest Obstacle Isn't Technology

Despite technical superiority, the biggest hurdle to adoption isn't computational—it's human. As Mark Lewis warns, a retail technology strategist: "The biggest barrier to AI success in fashion is purely and exclusively a matter of collective mindset."

There's a dangerous fallacy that perceives AI as incomprehensible "dark magic." This generates unrealistic expectations in boardrooms or visceral rejection from merchandising professionals who fear the "black box" verdict. Retailers invest millions in platforms that end up underutilized because they haven't restructured their teams or invested in training.

The key, according to Scouller, is understanding that AI "isn't dark magic, but crushing logic: massive processing of clean data and the iterative application of mathematics at an inhuman scale and speed." And the corporate tipping point arrives at a very specific moment: when the pain of inefficiency exceeds the inertia of operational comfort.

The Future: Generative AI, Autonomous Agents, and the ESPR Regulatory Shield

Nextail's roadmap converges on three forces that will define retail in 2026:

1. Conversational Interface with RAG: Generative AI won't replace the MILP optimization engines (LLMs fail at massive numerical computation at efficient cost). Its role will be to act as a cognitive orchestration layer: a commercial director will be able to interact with the mathematical brain in natural language, requesting profitability analyses for a specific rebalancing and authorizing automatic executions.

2. Multi-Agent AI Systems: Gartner projects that by end of 2026, more than 40% of enterprise applications will incorporate AI agents. In the S&OP context, a "swarm" of agents will autonomously monitor volatile variables—weather, supply chain disruptions, trending virality on social media—and recalibrate the optimizer without human intervention.

3. The ESPR Shield: The European ESPR 2026 regulatory framework will penalize (and even ban) the destruction of unsold textile inventory. Surpluses will no longer be "sunk costs" but auditable environmental liabilities. In this context, Nextail's ability to reduce overproduction and minimize leftovers transforms from a financial advantage into a legal survival requirement.

Conclusion: Mathematics Wins the Game

Nextail's story is the chronicle of an industry that has crossed a point of no return. The complexity of modern omnichannel retail has definitively exceeded human capacity for manual management. Spreadsheets are not a minor inconvenience; they are a systemic risk that silently drains profit margins.

Nextail has proven that the answer lies in the fusion of probabilistic forecasting, stochastic optimization, and a clean data culture. Its journey demonstrates that sometimes, revolution doesn't arrive with an entirely new idea, but with the rigorous application of mathematics to a problem everyone had given up on.

As Villalba discovered in the corridors of Zara: the agility of the future isn't built on intuition—it's built on equations.

Sources of Interest:

S&OP Engineering V: The Autonomous Brain (Agentic AI)

Daniel — Fri, 27 Mar 2026 18:02:39 +0000

1. The Execution Chasm

Companies invest millions in planning software and ERPs. They spend months integrating data, cleaning records, and tuning demand forecasts. Yet, at the end of the day, execution often relies on an analyst staring at a dashboard. A human reading charts, finally drafting an email to the plant director to request production adjustments.

That human delay is inefficient, error-prone, and, frankly, unnecessary in the modern era. Pure mathematics has no value if it isn't executed.

The solution isn't a rigid automation script, nor is it a chatbot you ask questions to. True modernization requires Agentic AI. We are not talking about ChatGPT. We are talking about Autonomous Agents: software entities with a specific role, a clear goal, and integrated with Tools that allow them to interact with real-world databases and APIs.

2. The Architecture: CrewAI + Supabase

For this Autonomous Brain, we have implemented a multi-agent architecture using CrewAI. Our digital team ("The Agency") is composed of two key agents:

Senior Supply Chain Analyst: Its job is purely analytical. We don't give it a PDF to summarize; we equipped it with a Python @tool that allows it to execute SQL queries against our Supabase database. It extracts the optimal production plan generated by PuLP in Chapter 4, identifies bottlenecks, and pinpoints the months where production stress is most critical.
Procurement & Plant Manager: Acts as the executor. Based strictly on the mathematical conclusions drawn by the Analyst, it drafts the definitive executive orders.

Crucial fact: They do not hallucinate. Their decisions are anchored in hard data mathematically retrieved from the central database.

3. The Code: Tools over Prompts

The true power of Agentic AI lies in providing LLMs with the ability to interact with external systems. The C-Suite must understand that we aren't handing an Excel sheet to a language model; we are embedding our code with the ability to "think" and execute actions using the ReAct (Reasoning and Acting) pattern.

Here is a snippet of how we connect our Agent to Supabase:

from crewai.tools import tool
from supabase import create_client

@tool("fetch_latest_supply_plan")
def fetch_latest_supply_plan() -> str:
    """
    Connects to the Supabase database, finds the most recent execution of the 
    optimized production plan, and extracts the strategic plan for the 
    next 3 months across all SKUs.
    """
    supabase = create_client(SUPABASE_URL, SUPABASE_KEY)

    # 1. Find the most recent execution
    latest = supabase.table("supply_plans").select("execution_date").order("execution_date", desc=True).limit(1).execute()
    exec_date = latest.data[0]["execution_date"]

    # 2. Extract the optimal plan generated by PuLP
    response = supabase.table("supply_plans").select("*").eq("execution_date", exec_date).execute()

    # ... Format into structured Markdown to prevent hallucinations ...
    return report

# Instantiate the Analyst Agent by connecting it to the tool
analyst_agent = Agent(
    role='Senior Supply Chain Analyst',
    goal='Analyze the master production plan to detect bottlenecks and inventory risks.',
    backstory='You are a relentless analyst seeking capital efficiency. You hate excess inventory but fear stockouts...',
    verbose=True,
    allow_delegation=False,
    tools=[fetch_latest_supply_plan], # <-- We inject Database access here
    llm=gemini_llm
)

By compiling the agents into a Process.sequential pipeline, we orchestrate a workflow where the Analyst's output directly fuels the actions of the Plant Manager.

4. The Money Shot

If we execute our "Crew", this is exactly what the model returns in the terminal after querying the database and reasoning around the factory's 12,000 monthly unit capacity limit:

[!NOTE]
SUBJECT: URGENT - July-September Production Plan | Bottleneck Alert

Hi Carlos,

After running the mathematical optimization model for the upcoming quarter, I confirm the Master Production Plan. We are facing a critical capacity bottleneck (12,000 units/month) during the summer that requires strict execution.

July (100% Capacity - Critical Risk):
The entire plant capacity must be exclusively dedicated to SKU-001 (12,000 units). Halt the SKU-002 and SKU-003 lines this month. The model has pulled forward this production to prevent stockouts in the following months.

August (100% Capacity - Production Mix):
The factory will remain at its limit. The distribution will be:

SKU-001: 5,000 units

SKU-002: 15 units

SKU-003: 6,985 units (High priority for the seasonal campaign)

September (83% Capacity - Stabilization):
The pressure will decrease. We will manufacture 8,000 units of SKU-001, 10 units of SKU-002, and 2,000 units of SKU-003, ensuring a buffer for line maintenance.

Please coordinate with purchasing to secure the raw materials for SKU-001 immediately for the first week of July. The algorithm leaves no margin for error regarding the 12,000 units for that month.

Regards,
Agentic S&OP Copilot (On behalf of Operations Management)

This email isn't a generic template. It is an operational, justified, and unbiased decision, generated autonomously from a linear programming model and delivered in seconds.

5. The Sandbox

Want to see how they reason in real-time? I have prepared an interactive notebook so you can test the system yourself.

👉 Open the Agentic S&OP Google Colab

For security reasons, we have simulated the database return in the public environment. But if you insert your own Gemini API Key (it's free), you will be able to watch the agents' step-by-step reasoning process in the logs before they issue the final order.

6. Series Conclusion: The CTO Pitch

We have reached the end of our "S&OP Engineering" journey. Over the course of five chapters, we have evolved enterprise planning from its grimiest foundations to the technological bleeding edge:

Foundations: We cleaned and normalized years of unstructured historical data.
Vision: We implemented iterative Artificial Intelligence engines to forecast future demand with high precision (Prophet).
Logic: We introduced Decision Sciences and Linear Programming to balance inventory constraints (PuLP).
Scale: We elevated the mathematical model to the Enterprise level, dealing with shared capacity constraints and parallelized MLOps.
Execution: We gave the system an Autonomous Brain to bridge the gap between the Dashboard and the real world.

The CTO Pitch: If your company is still planning demand with moving averages in Excel, you are bleeding money. Capital efficiency, stockout reduction, and intelligent workflow automation are no longer the future; they are the operational standard demanded by today's margins.

It's time to retire static models. Let's talk about how to modernize your Supply Chain from its roots all the way to autonomous execution.

Ingeniería S&OP V: El Cerebro Autónomo (Agentic AI)

Daniel — Fri, 27 Mar 2026 17:56:38 +0000

1. El Abismo de la Ejecución

Las empresas invierten millones en software de planificación y ERPs. Pasan meses integrando datos, limpiando registros y afinando previsiones de demanda. Y aun así, al final del día, la ejecución suele depender de un analista frente a un dashboard. Un humano leyendo gráficos para, finalmente, redactar un correo electrónico al director de la fábrica solicitando cambios en la producción.

Ese delay humano es ineficiente, propenso a errores y, francamente, innecesario en la era moderna. Las matemáticas puras no tienen valor si no se ejecutan.

La solución no es un simple script de automatización rígido, ni tampoco un chatbot al que hacerle preguntas. La verdadera modernización requiere Agentic AI. No estamos hablando de ChatGPT. Hablamos de Agentes Autónomos: piezas de software con un rol específico, un objetivo claro, e integrados con herramientas (Tools) que les permiten interactuar con bases de datos y APIs del mundo real.

2. La Arquitectura: CrewAI + Supabase

Para este Cerebro Autónomo, hemos implementado una arquitectura multi-agente utilizando CrewAI. Nuestro equipo digital ("La Agencia") está compuesto por dos agentes clave:

Senior Supply Chain Analyst: Su trabajo es puramente analítico. No le damos un PDF para resumir; le hemos equipado con una herramienta de Python (@tool) que le permite ejecutar consultas SQL contra nuestra base de datos en Supabase. Extrae el plan de producción óptimo que generó PuLP en el Capítulo 4, identifica los cuellos de botella y señala los meses donde el nivel de estrés productivo es más crítico.
Procurement & Plant Manager: Actúa como el ejecutor. Basándose estrictamente en las conclusiones matemáticas del Analista, redacta las órdenes ejecutivas definitivas.

Dato crucial: No alucinan. Sus decisiones están ancladas en los datos duros recuperados matemáticamente desde la base de datos central.

3. El Código: Tools over Prompts

El verdadero poder del Agentic AI radica en proporcionar a los LLMs la capacidad de interactuar con sistemas externos. El C-Level debe entender que no le estamos dando un Excel a un modelo de lenguaje; le estamos dotando de la capacidad de "pensar" y ejecutar acciones utilizando el patrón ReAct (Reasoning and Acting).

Este es un fragmento de cómo conectamos nuestro Agente a Supabase:

from crewai.tools import tool
from supabase import create_client

@tool("fetch_latest_supply_plan")
def fetch_latest_supply_plan() -> str:
    """
    Se conecta a la base de datos Supabase, busca la ejecución más 
    reciente del plan de producción optimizado y extrae el plan estratégico 
    de los próximos 3 meses para todos los SKUs.
    """
    supabase = create_client(SUPABASE_URL, SUPABASE_KEY)

    # 1. Buscar ejecución más reciente
    latest = supabase.table("supply_plans").select("execution_date").order("execution_date", desc=True).limit(1).execute()
    exec_date = latest.data[0]["execution_date"]

    # 2. Extraer el plan óptimo generado por PuLP
    response = supabase.table("supply_plans").select("*").eq("execution_date", exec_date).execute()

    # ... Formateo en Markdown estructurado para evitar alucinaciones ...
    return report

# Instanciamos el Agente Analista conectándolo a la herramienta
analyst_agent = Agent(
    role='Senior Supply Chain Analyst',
    goal='Analizar el plan maestro de producción y detectar cuellos de botella y riesgos de inventario.',
    backstory='Eres un analista implacable que busca la eficiencia del capital. Odias el exceso de inventario pero temes las roturas de stock...',
    verbose=True,
    allow_delegation=False,
    tools=[fetch_latest_supply_plan], # <-- Aquí inyectamos el acceso a la Base de Datos
    llm=gemini_llm
)

Al compilar a los agentes en un Process.sequential, orquestamos un flujo de trabajo donde la salida del Analista alimenta directamente las acciones del Manager de Planta.

4. El Resultado Final

Si ejecutamos nuestra "Crew", esto es exactamente lo que el modelo escupe en la terminal después de consultar la base de datos y razonar sobre los 12.000 límites de capacidad mensuales de la fábrica:

[!NOTE]
ASUNTO: URGENTE - Plan de Producción Julio-Septiembre | Alerta de Cuello de Botella

Hola Carlos,

Tras ejecutar el modelo de optimización matemática para el próximo trimestre, te confirmo el Plan Maestro de Producción. Nos enfrentamos a un cuello de botella crítico de capacidad (12.000 unidades/mes) durante el verano que requiere ejecución estricta.

Julio (Capacidad 100% - Riesgo Crítico):
Toda la capacidad de la planta debe dedicarse exclusivamente al SKU-001 (12.000 unidades). Paralizad las líneas del SKU-002 y SKU-003 este mes. El modelo ha adelantado esta producción para evitar roturas en los meses siguientes.

Agosto (Capacidad 100% - Mix de Producción):
La fábrica seguirá al límite. La distribución será:

SKU-001: 5.000 uds

SKU-002: 15 uds

SKU-003: 6.985 uds (Prioridad alta para la campaña estacional)

Septiembre (Capacidad 83% - Estabilización):
La presión bajará. Fabricaremos 8.000 uds del SKU-001, 10 uds del SKU-002 y 2.000 uds del SKU-003, lo que nos permitirá margen para mantenimiento de las líneas.

Por favor, coordina con compras para asegurar la materia prima del SKU-001 de forma inmediata para la primera semana de Julio. El algoritmo no contempla margen de error en las 12.000 unidades de ese mes.

Saludos,
Agentic S&OP Copilot (En nombre de Dirección de Operaciones)

Este correo no es una plantilla genérica. Es una decisión operativa, justificada e imparcial, generada autónomamente a partir de un modelo de programación lineal y enviada en segundos.

5. The Sandbox

¿Quieres ver cómo razonan en tiempo real? He preparado un cuaderno interactivo para que pruebes el sistema tú mismo.

👉 Abre el Google Colab de Agentic S&OP

Por motivos de seguridad, en el entorno público hemos simulado el retorno de la base de datos, pero si insertas tu propia API Key de Gemini (es gratuita), podrás observar en los logs el proceso de razonamiento paso a paso de los agentes antes de emitir la orden final.

6. Conclusión de la Serie

Hemos llegado al final de nuestro viaje "S&OP Engineering". A lo largo de cinco capítulos, hemos evolucionado la planificación empresarial desde sus cimientos más sucios hasta la vanguardia tecnológica:

Fundamentos: Limpiamos y normalizamos años de datos históricos desestructurados.
Visión: Implementamos motores de Inteligencia Artificial iterativos para prever la demanda futura con alta precisión (Prophet).
Lógica: Introdujimos Ciencias de la Decisión y Programación Lineal para equilibrar el inventario (PuLP).
Escalabilidad: Llevamos el modelo matemático a nivel Enterprise lidiando con restricciones de capacidad y MLOps paralelizado.
Ejecución: Le dimos un Cerebro Autónomo al sistema para cerrar la brecha entre el Dashboard y el mundo real.

The CTO Pitch: Si tu empresa sigue planificando la demanda con promedios móviles en Excel, estás perdiendo dinero. La eficiencia del capital, la reducción de roturas de stock y la automatización inteligente ya no son el futuro; son el estándar operativo que exigen los márgenes actuales.

Es hora de jubilar los modelos estáticos. Hablemos de cómo modernizar tu Cadena de Suministro desde la raíz hasta la ejecución autónoma.

S&OP Engineering IV: Scaling to Enterprise (Multi-SKU & Bottlenecks)

Daniel — Fri, 20 Mar 2026 06:57:16 +0000

Your MVP works. One product, one model, one perfect plan. Congratulations: you just solved the easiest problem in Supply Chain.

Now add 3 products sharing the same factory. Product A needs 14,000 units in July. Product C needs 13,000 that same month. Your factory produces 15,000. Who gets shorted?

If your answer is "we'll figure it out in Thursday's meeting," your company has an engineering problem, not a management one.

Executive Summary: In chapters 1, 2 and 3 we built a working MVP for a single product. In this Chapter 4, we break it. We inject 3 years of history with 3 SKUs of radically different demand profiles (Core, Intermittent, and Seasonal), parallelize Prophet model training with MLOps, and build a unified Linear Programming model where products compete mathematically for limited factory capacity. Welcome to Theory of Constraints executed in code.

The Fatal Error: Optimizing in Silos

The biggest sin in Supply Chain Planning isn't using dirty data (we fixed that in Chapter 1). It's optimizing each product as if the factory were infinite.

Imagine three product managers, each with their optimized Excel:

SKU-001 Manager (Core): "I need to produce 6,000/month. Already calculated."
SKU-002 Manager (Spare Part): "I only need 15/month. No big deal."
SKU-003 Manager (Seasonal): "In July I need 14,000. Non-negotiable."

Sum: 6,000 + 15 + 14,000 = 20,015 units. Your factory produces 15,000. Each manager is right individually. Collectively, it's a collapse.

This is what Eli Goldratt described in The Goal as Theory of Constraints: the system is not optimized by summing local optima. It's optimized by identifying the bottleneck and letting mathematics allocate the resources.

Stress-Test: The 3 Profiles That Break Your MVP

To validate the Enterprise architecture, we generated a 3-year dataset (2023-2025) with three SKUs designed to break any naïve model:

SKU	Profile	Average Demand	Trap
SKU-001	Core Product	~200/day	High variance + 3x Black Friday
SKU-002	Intermittent Spare	~0.6/day	70% zero-demand days
SKU-003	Seasonal Summer	~250/day	500+ peaks in July, zero in winter

We injected real ERP noise: outliers (x50), corrupted dates, nulls, negatives. This isn't a toy tutorial. It's what comes out of a production SAP on any given Tuesday.

MLOps: Parallelizing the Forecasting

With a single product, training Prophet takes 2 seconds. With 50 SKUs in a for loop, you wait 100 seconds. With 500, you go home.

The solution is the same one production pipelines use: parallelization. Each SKU is statistically independent, so each model can train on its own thread:

from concurrent.futures import ThreadPoolExecutor

def process_sku(sku, df_sku, months, country_code):
    """Worker: trains Prophet for one SKU."""
    predictor = ProphetPredictor(df_sku, sku_name=sku)
    predictor.preprocess_daily_aggregation()
    predictor.train_model(country_code=country_code)
    return predictor.generate_forecast(months=months)

with ThreadPoolExecutor(max_workers=3) as executor:
    futures = {
        executor.submit(process_sku, sku, df, 12, "ES"): sku
        for sku, df in sku_dataframes.items()
    }

3 Prophet models, 3 seconds. Not 6. Three. If you add 50 SKUs like any mid-sized company has, the difference between sequential and parallel is the difference between an operational pipeline and a script nobody wants to run.

Negative Clipping: The Business Rule Prophet Ignores

Prophet can generate negative predictions. Mathematically it makes sense (the regression doesn't know demand can't be -12 units). Operationally it's a disaster.

Our forecasting_engine_v2.py applies a Negative Clipping post-prediction:

# Business Rule: Demand cannot be negative
for col in ["yhat", "yhat_lower", "yhat_upper"]:
    self.forecast[col] = self.forecast[col].clip(lower=0)

One line. One fewer production bug. This is what separates MLOps from "Machine Learning in a Jupyter Notebook."

Fault Tolerance: One SKU Doesn't Kill the Pipeline

What happens if SKU-002 has only 10 records and Prophet fails? In an amateur script, the entire pipeline dies. In an Enterprise system:

sku_name, forecast_df, error = future.result()
if error:
    print(f"[!!] {sku_name}: FAILED - {error}")
    result["skus_failed"] += 1
else:
    forecasts.append(forecast_df)
    result["skus_success"] += 1

The 2 healthy SKUs finish their work. The failed one gets logged. This is the difference between a script and a system.

The Mathematics of Bottlenecks: Unified PuLP Model

Here's the intellectual core of the entire chapter. In Chapter 3 we optimized one product. Now we create a single LP model where all SKUs coexist:

# ── MULTI-DIMENSIONAL decision variables ──
production[sku][t]  # How much to produce of SKU s in period t
inventory[sku][t]   # Inventory of SKU s at end of period t

# ── Objective Function: TOTAL system cost ──
problem += lpSum(
    prod_cost[sku] * production[sku][t]
    + hold_cost[sku] * inventory[sku][t]
    for sku in skus for t in range(T)
), "Total_System_Cost"

# ── THE KEY CONSTRAINT: Shared Capacity ──
for t in range(T):
    problem += (
        lpSum(production[sku][t] for sku in skus) <= SHARED_MAX_CAPACITY,
        f"SharedCapacity_t{t}"
    )

Read that last constraint. It's a single line of code, but it contains Goldratt's entire Theory of Constraints encoded:

lpSum(production[sku][t] for sku in skus) <= 15,000

You're telling the machine: "The factory produces at most 15,000 units per month. I don't care if it's 15,000 of SKU-001 or 7,500 of each. You decide the allocation that minimizes total system cost."

And the solver decides. No meetings. No politics. No "we always prioritize the big client." Mathematics.

The Result: Intelligent Capacity Allocation

Our solver with real Supabase data:

  SKU-001: demand=70,879 | prod=70,579 | avg_inv=5,754 | cost=855,394 EUR
  SKU-002: demand=143   | prod=128   | avg_inv=6     | cost=6,775 EUR
  SKU-003: demand=84,298 | prod=84,098 | avg_inv=115   | cost=1,265,970 EUR

  Total production cost:       1,973,660 EUR
  Total holding cost:            154,479 EUR
  ** TOTAL SYSTEM COST:        2,128,139 EUR **

Observe the decisions the algorithm made:

SKU-001 (prod_cost=€10, hold_cost=€2): Cheap to store. The solver produces ahead during cheap months and stockpiles inventory (avg 5,754 units). Intelligent pre-build.
SKU-002 (prod_cost=€50, hold_cost=€5): Expensive part. Strict just-in-time production (avg_inv=6 units). Doesn't stockpile a single extra piece.
SKU-003 (seasonal): Minimum inventory at safety stock. Produces exactly what it needs each month, following the seasonal wave.

No human with Excel can calculate this with 3 products and 13 months. And they definitely can't recalculate it every week when the forecast changes.

The Ah-Ha Moment: The Bottleneck Visualized

Look at the summer months. Combined demand from the 3 SKUs exceeds factory capacity (red line). What does the algorithm do? Instead of breaking stock, it decides to advance production of the cheapest-to-store SKU (SKU-001) to spring, freeing factory space for the critical seasonal product (SKU-003) in summer. This is Theory of Constraints executed by a machine.

If you look at the chart, it seems like SKU-002 (spare parts) doesn't exist. But it's there. It represents 0.1% of the factory's volume, but in manual management, it usually consumes 20% of the planner's mental time due to its high volatility. By delegating this to a Linear Programming model, the system manages large volumes and the long tail simultaneously without stress.

Open Kitchen: Break the System

I distrust theories that can't be put into practice. I've prepared a new Enterprise Google Colab where you can run the most revealing experiment of the entire series:

Lower the SHARED_MAX_CAPACITY variable to 12,000. Watch the solver start juggling: it sacrifices SKU-001 inventory to prioritize SKU-003 in July. Lower it to 10,000 and you'll see the model declare INFEASIBLE — the factory literally cannot meet demand even with the best possible planning. That's your inflection point for investing in capacity expansion.

📎 Open the Multi-SKU Enterprise Google Colab

Change the maximum factory capacity, modify holding costs, add a fourth SKU. Do engineering, not faith.

The Full Chain: From MVP to Enterprise

With this fourth chapter, we've scaled a single-product prototype to a Multi-SKU Enterprise architecture:

Next Step: The Autonomous Brain

Our Supabase database now has the perfect master plan. Three products, thirteen months, every unit assigned to the optimal month considering costs, seasonality, and physical capacity.

But databases don't send emails to suppliers. They don't negotiate with plant directors. They don't generate purchase orders at 6am on Monday.

In Chapter 5 (Grand Finale), we'll connect this plan to AI Agents (CrewAI) to execute operations autonomously. The algorithm decides how much to buy. The agent executes the purchase. The human... supervises.

The difference between a company that plans and one that optimizes is a mathematical model between its data and its decisions. And between its decisions and its actions, an autonomous agent.

Ingeniería S&OP IV: Escalando a Enterprise (Multi-SKU y Cuellos de Botella)

Daniel — Fri, 20 Mar 2026 06:50:04 +0000

Tu MVP funciona. Un producto, un modelo, un plan perfecto. Enhorabuena: acabas de resolver el problema más fácil del universo de Supply Chain.

Ahora mete 3 productos que comparten la misma fábrica. El Producto A necesita 14.000 unidades en julio. El Producto C necesita 13.000 ese mismo mes. Tu fábrica produce 15.000. ¿A quién dejas sin stock?

Si tu respuesta es "lo vemos en la reunión del jueves", tu empresa tiene un problema de ingeniería, no de gestión.

Executive Summary: En los capítulos 1, 2 y 3 construimos un MVP funcional para un solo producto. En este Capítulo 4, lo destruimos. Inyectamos 3 años de histórico con 3 SKUs de perfiles radicalmente distintos, paralelizamos el entrenamiento de modelos Prophet con MLOps, y construimos un modelo unificado de Programación Lineal donde los productos compiten matemáticamente por una capacidad de fábrica limitada. Bienvenido a la Theory of Constraints ejecutada en código.

El Error Fatal: Optimizar en Silos

El mayor pecado en Supply Chain Planning no es usar datos sucios (eso lo resolvimos en el Capítulo 1). Es optimizar cada producto como si la fábrica fuera infinita.

Imagina tres directores de producto, cada uno con su Excel optimizado:

Director del SKU-001 (Core): "Necesito producir 6.000/mes. Ya está calculado."
Director del SKU-002 (Spare Part): "Solo necesito 15/mes. Sin problema."
Director del SKU-003 (Seasonal): "En julio necesito 14.000. No negociable."

Suma: 6.000 + 15 + 14.000 = 20.015 unidades. Tu fábrica produce 15.000. Cada director tiene razón individualmente. Colectivamente, es un colapso.

Esto es lo que Eli Goldratt describió en The Goal como Theory of Constraints: el sistema no se optimiza sumando óptimos locales. Se optimiza identificando el cuello de botella y dejando que las matemáticas repartan los recursos.

Estrés-Test: Los 3 Perfiles que Rompen tu MVP

Para validar la arquitectura Enterprise, generamos un dataset de 3 años (2023-2025) con tres SKUs diseñados para romper cualquier modelo naïve:

SKU	Perfil	Demanda Media	Trampa
SKU-001	Core Product	~200/día	Alta varianza + Black Friday 3x
SKU-002	Intermittent Spare	~0.6/día	70% días con demanda cero
SKU-003	Seasonal Summer	~250/día	Picos de 500+ en julio, cero en invierno

Le inyectamos ruido ERP real: outliers (x50), fechas corruptas, nulos, negativos. Esto no es un tutorial de juguete. Es lo que sale de un SAP en producción un martes cualquiera.

MLOps: Paralelizando el Forecasting

Con un solo producto, entrenar Prophet toma 2 segundos. Con 50 SKUs en un bucle for, esperas 100 segundos. Con 500, te vas a casa.

La solución es la misma que usan los pipelines de producción: paralelización. Cada SKU es independiente estadísticamente, así que cada modelo puede entrenarse en su propio thread:

from concurrent.futures import ThreadPoolExecutor

def process_sku(sku, df_sku, months, country_code):
    """Worker: entrena Prophet para un SKU."""
    predictor = ProphetPredictor(df_sku, sku_name=sku)
    predictor.preprocess_daily_aggregation()
    predictor.train_model(country_code=country_code)
    return predictor.generate_forecast(months=months)

with ThreadPoolExecutor(max_workers=3) as executor:
    futures = {
        executor.submit(process_sku, sku, df, 12, "ES"): sku
        for sku, df in sku_dataframes.items()
    }

3 modelos Prophet, 3 segundos. No 6. Tres. Si agregas 50 SKUs como tiene cualquier PYME mediana, la diferencia entre secuencial y paralelo es la diferencia entre un pipeline operativo y un script que nadie quiere ejecutar.

Negative Clipping: La Regla de Negocio que Prophet Ignora

Prophet puede generar predicciones negativas. Matemáticamente tiene sentido (la regresión no sabe que la demanda no puede ser -12 unidades). Operativamente es un desastre.

Nuestro forecasting_engine_v2.py aplica un Negative Clipping post-predicción:

# Business Rule: La demanda no puede ser negativa
for col in ["yhat", "yhat_lower", "yhat_upper"]:
    self.forecast[col] = self.forecast[col].clip(lower=0)

Una línea. Un error en producción menos. Esto es lo que separa MLOps de "Machine Learning en un Jupyter Notebook".

Fault Tolerance: Un SKU No Mata al Pipeline

¿Qué pasa si el SKU-002 tiene solo 10 registros y Prophet falla? En un script amateur, el pipeline entero muere. En un sistema Enterprise:

sku_name, forecast_df, error = future.result()
if error:
    print(f"[!!] {sku_name}: FAILED - {error}")
    result["skus_failed"] += 1
else:
    forecasts.append(forecast_df)
    result["skus_success"] += 1

Los 2 SKUs sanos terminan su trabajo. El que falló queda en el log. Esto es la diferencia entre un script y un sistema.

La Matemática del Bottleneck: PuLP Unificado

Aquí está el núcleo intelectual de todo el capítulo. En el Capítulo 3 optimizamos un producto. Ahora creamos un único modelo LP donde todos los SKUs coexisten:

# ── Variables de decisión MULTI-DIMENSIONALES ──
production[sku][t]  # Cuánto fabricar del SKU s en el periodo t
inventory[sku][t]   # Inventario del SKU s al final del periodo t

# ── Función Objetivo: Coste TOTAL del sistema ──
problem += lpSum(
    prod_cost[sku] * production[sku][t]
    + hold_cost[sku] * inventory[sku][t]
    for sku in skus for t in range(T)
), "Total_System_Cost"

# ── LA RESTRICCIÓN CLAVE: Capacidad Compartida ──
for t in range(T):
    problem += (
        lpSum(production[sku][t] for sku in skus) <= SHARED_MAX_CAPACITY,
        f"SharedCapacity_t{t}"
    )

Lee esa última restricción. Es una sola línea de código, pero contiene toda la teoría de restricciones de Goldratt codificada:

lpSum(production[sku][t] for sku in skus) <= 15,000

Le estás diciendo a la máquina: "La fábrica produce máximo 15.000 unidades al mes. Me da igual si es 15.000 de SKU-001 o 7.500 de cada uno. Tú decides el reparto que minimice el coste total del sistema."

Y el solver decide. Sin reuniones. Sin política. Sin "siempre le damos prioridad al cliente grande". Matemáticas.

El Resultado: Asignación Inteligente de Capacidad

Nuestro solver con datos reales de Supabase:

  SKU-001: demand=70,879 | prod=70,579 | avg_inv=5,754 | cost=855,394 EUR
  SKU-002: demand=143   | prod=128   | avg_inv=6     | cost=6,775 EUR
  SKU-003: demand=84,298 | prod=84,098 | avg_inv=115   | cost=1,265,970 EUR

  Coste producción total:     1,973,660 EUR
  Coste almacenamiento total:   154,479 EUR
  ** COSTE TOTAL SISTEMA:     2,128,139 EUR **

Observa las decisiones que tomó el algoritmo:

SKU-001 (prod_cost=10€, hold_cost=2€): Es barato de almacenar. El solver produce por adelantado en meses baratos y acumula inventario (avg 5.754 uds). Pre-build inteligente.
SKU-002 (prod_cost=50€, hold_cost=5€): Pieza cara. Producción just-in-time estricta (avg_inv=6 uds). No stockea ni una pieza de más.
SKU-003 (estacional): Inventario mínimo en safety stock. Produce exactamente lo que necesita cada mes siguiendo la ola estacional.

Ningún humano con Excel puede calcular esto con 3 productos y 13 meses. Y definitivamente no puede recalcularlo cada semana cuando cambia el forecast.

The Ah-Ha Moment: El Cuello de Botella Visual

Observa los meses de verano. La demanda combinada de los 3 SKUs supera la capacidad de la fábrica (línea roja). ¿Qué hace el algoritmo? En lugar de romper stock, decide adelantar la producción del SKU más barato de almacenar (SKU-001) a primavera, dejando hueco en la fábrica para el producto estacional crítico (SKU-003) en verano. Esto es Theory of Constraints ejecutada por una máquina.

Si miras la gráfica, parece que el SKU-002 (repuestos) no existe. Pero está ahí. Representa el 0,1% del volumen de la fábrica, pero en la gestión manual suele consumir el 20% del tiempo mental del planificador por su alta volatilidad. Al delegar esto a un modelo de Programación Lineal, el sistema gestiona los grandes volúmenes y la larga cola simultáneamente sin estrés.

Open Kitchen: Rompe el Sistema

Desconfío de las teorías que no se pueden poner en práctica. He preparado un nuevo Google Colab Enterprise donde puedes hacer el experimento más revelador de toda la serie:

Baja la variable SHARED_MAX_CAPACITY a 12.000. Observa cómo el solver empieza a hacer malabares extremos: sacrifica inventario de SKU-001 para dar prioridad a SKU-003 en julio. Bájala a 10.000 y verás el modelo declarar INFEASIBLE — la fábrica literalmente no puede satisfacer la demanda ni con la mejor planificación posible. Ese es tu punto de inflexión para invertir en ampliar capacidad.

📎 Abrir el Google Colab Multi-SKU Enterprise

Cambia la capacidad máxima de la fábrica, modifica los costes de almacenamiento, añade un cuarto SKU. Haz ingeniería, no fe.

La Cadena Completa: De MVP a Enterprise

Con este cuarto capítulo, hemos escalado un prototipo de un solo producto a una arquitectura Enterprise Multi-SKU:

Siguiente Paso: El Cerebro Autónomo

Nuestra base de datos Supabase ya tiene el plan maestro perfecto. Tres productos, trece meses, cada unidad asignada al mes óptimo considerando costes, estacionalidad y capacidad física.

Pero las bases de datos no envían emails a proveedores. No negocian con los directores de planta. No generan las órdenes de compra a las 6am del lunes.

En el Capítulo 5 (Gran Final), conectaremos este plan a Agentes de Inteligencia Artificial (CrewAI) para que ejecuten las operaciones de forma autónoma. El algoritmo decide cuánto comprar. El agente ejecuta la compra. El humano... supervisa.

La diferencia entre una empresa que planifica y una que se optimiza es un modelo matemático entre sus datos y sus decisiones. Y entre sus decisiones y sus acciones, un agente autónomo.

Ingeniería S&OP III: El Fin de Excel (Programación Lineal para Supply Planning)

Daniel — Fri, 13 Mar 2026 07:25:29 +0000

"Siempre queremos X semanas de cobertura." Esta frase, repetida como mantra en todas las reuniones de S&OP del planeta, es financieramente tóxica.

¿Por qué? Porque es una regla fija aplicada a un sistema dinámico. Si tu demanda en enero es 200 unidades y en julio es 20, te estás obligando a mantener 800 y 80 unidades respectivamente "por si acaso". En enero te queda corto. En julio inmovilizas capital sin motivo.

La alternativa no es intuición más sofisticada. Es matemáticas.

Resumen Ejecutivo: En este capítulo, conectamos el forecast probabilístico del Capítulo 2 con un motor de Programación Lineal (PuLP) que calcula el plan de producción exacto que minimiza el coste total (producción + almacenamiento) respetando la restricción de Safety Stock. Pasamos de la predicción pasiva a la prescripción activa.

Del Forecast a la Decisión: Arquitectura

En el Capítulo 1 limpiamos la señal. En el Capítulo 2 predijimos la demanda. Ahora damos el paso que Excel no puede dar: optimizar.

Nuestro pipeline en GitHub se conecta a Supabase, lee la tabla demand_forecasts (el futuro que predijimos), y genera una nueva tabla supply_plans. El sistema ha pasado de descriptivo (¿qué pasó?) a predictivo (¿qué pasará?) y ahora a prescriptivo (¿qué debo hacer?).

Esto es Investigación Operativa. La misma disciplina que optimiza rutas aéreas, logística militar y cadenas de suministro globales. Y la ejecutamos con 50 líneas de Python.

Las Matemáticas del Negocio

No vamos a esconder las ecuaciones. Son el corazón de la decisión. Aquí está el fragmento central de nuestra clase SupplyOptimizer:

# Función Objetivo: Minimizar coste total
problem += pulp.lpSum(
    production_cost * production[t] + holding_cost * inventory[t]
    for t in range(T)
), "Total_Cost"

# Restricción: Balance de Inventario (Ley de Conservación de Masas)
for t in range(T):
    prev_inv = initial_inventory if t == 0 else inventory[t - 1]
    problem += (
        inventory[t] == prev_inv + production[t] - demand[t],
        f"Balance_t{t}"
    )

# Restricción: Safety Stock (Política de Riesgo)
for t in range(T):
    problem += (
        inventory[t] >= safety_stock,
        f"SafetyStock_t{t}"
    )

Tres decisiones de ingeniería que merecen explicación:

La Función Objetivo no busca "tener mucho stock" ni "producir mucho". Busca el mínimo coste financiero: el equilibrio entre fabricar (caro) y almacenar (caro también). El solver encuentra automáticamente el punto exacto donde el coste combinado es mínimo.

El Balance de Masas es una restricción física: no puedes vender lo que no tienes. El inventario de hoy es el de ayer, más lo que fabricas hoy, menos lo que vendes. No hay magia. Las ecuaciones prohíben las trampas.

El Safety Stock es la política de riesgo: nunca permitas que el inventario baje por debajo de un mínimo de seguridad. En nuestro caso, 1,5 meses de demanda media. Esto lo calcula el sistema, no una hoja de cálculo con un número puesto a dedo.

El Plan Maestro: De Algoritmo a Decisión de Negocio

Esto es lo que el Director de Operaciones necesita ver. El algoritmo no fabrica uniformemente: si detecta un pico enorme de demanda en un periodo, decide "pre-construir" (pre-build) inventario en los meses anteriores para aplanar la carga de producción. Si el Holding Cost es alto, mantiene el almacén vacío y fabrica Just-in-Time. Excel no hace esto solo; las matemáticas sí.

El resultado de nuestro solver con los datos de prueba:

Coste de producción: 1.680 EUR
Coste de almacenamiento: 540 EUR
Coste total optimizado: 2.220 EUR

Este número no es una estimación. Es el mínimo global demostrable dadas las restricciones. Si alguien propone un plan más barato con los mismos parámetros, está violando alguna restricción.

Open Kitchen: Juega con el Solver

Desconfío de las teorías que no se pueden poner en práctica. Por eso, he preparado un Google Colab donde puedes ejecutar el optimizador sobre un snapshot de nuestros datos reales.

El experimento más revelador: cambia el holding_cost a un valor altísimo (por ejemplo, 50 EUR/unidad). Observa cómo el algoritmo, automáticamente, decide fabricar Just-in-Time y mantener el almacén prácticamente vacío. Luego baja el coste de producción y mira cómo prefiere fabricar de golpe y almacenar. Las matemáticas se adaptan. Las reglas fijas de Excel, no.

📎 Abrir el Google Colab Interactivo

Modifica los costes, las restricciones de capacidad, el Safety Stock. Haz ingeniería, no fe.

La cadena completa: De Datos a Decisiones

Con este tercer capítulo, hemos construido un sistema S&OP end-to-end que va desde el CSV sucio del ERP hasta un plan de producción óptimo:

Siguiente Paso: Escalando a Enterprise

Ya tenemos el plan perfecto en nuestra base de datos. Pero solo para un producto. ¿Qué pasa cuando metes 3 SKUs que comparten la misma fábrica?

En el Capítulo 4 rompemos el MVP: inyectamos datos multi-producto con perfiles radicalmente distintos, paralelizamos el forecasting con MLOps, y construimos un modelo unificado de Programación Lineal donde los productos compiten matemáticamente por la capacidad de producción compartida.

La diferencia entre un Director de Operaciones que planifica y uno que optimiza es una función objetivo entre su intuición y la realidad.

S&OP Engineering III: The End of Excel (Linear Programming for Supply Planning)

Daniel — Fri, 13 Mar 2026 07:16:12 +0000

"We always want 4 weeks of coverage." This phrase, repeated like a mantra in every S&OP meeting on the planet, is financially toxic.

Why? Because it's a fixed rule applied to a dynamic system. If your demand in January is 200 units and in July is 20, you're forcing yourself to maintain 800 and 80 units respectively "just in case." January falls short. July immobilizes capital for no reason.

The alternative isn't more sophisticated intuition. It's mathematics.

Executive Summary: In this chapter, we connect the probabilistic forecast from Chapter 2 with a Linear Programming engine (PuLP) that calculates the exact production plan minimizing total cost (production + storage) while respecting Safety Stock constraints. We move from passive prediction to active prescription.

From Forecast to Decision: Architecture

In Chapter 1 we cleaned the signal. In Chapter 2 we predicted demand. Now we take the step Excel can't: optimize.

Our pipeline on GitHub connects to Supabase, reads the demand_forecasts table (the future we predicted), and generates a new supply_plans table. The system has evolved from descriptive (what happened?) to predictive (what will happen?) and now to prescriptive (what should I do?).

This is Operations Research. The same discipline that optimizes airline routes, military logistics, and global supply chains. And we run it with 50 lines of Python.

The Mathematics of Business

We're not going to hide the equations. They're the heart of the decision. Here's the core fragment from our SupplyOptimizer class:

# Objective Function: Minimize total cost
problem += pulp.lpSum(
    production_cost * production[t] + holding_cost * inventory[t]
    for t in range(T)
), "Total_Cost"

# Constraint: Inventory Balance (Conservation of Mass)
for t in range(T):
    prev_inv = initial_inventory if t == 0 else inventory[t - 1]
    problem += (
        inventory[t] == prev_inv + production[t] - demand[t],
        f"Balance_t{t}"
    )

# Constraint: Safety Stock (Risk Policy)
for t in range(T):
    problem += (
        inventory[t] >= safety_stock,
        f"SafetyStock_t{t}"
    )

Three engineering decisions worth explaining:

The Objective Function doesn't seek "lots of stock" or "high production." It seeks the minimum financial cost: the equilibrium between manufacturing (expensive) and storing (also expensive). The solver automatically finds the exact point where the combined cost is minimal.

The Mass Balance is a physical constraint: you can't sell what you don't have. Today's inventory equals yesterday's, plus what you produce today, minus what you sell. No magic. The equations forbid cheating.

The Safety Stock is the risk policy: never let inventory drop below a safety minimum. In our case, 1.5 months of average demand. The system calculates this, not a spreadsheet with a number pulled from thin air.

The Master Plan: From Algorithm to Business Decision

This is what the Operations Director needs to see. The algorithm doesn't produce uniformly: if it detects a massive demand spike in one period, it decides to "pre-build" inventory in preceding months to flatten the production load. If Holding Cost is high, it keeps the warehouse empty and manufactures Just-in-Time. Excel doesn't do this on its own; mathematics does.

The result from our solver with test data:

Production cost: €1,680
Storage cost: €540
Total optimized cost: €2,220

This number is not an estimate. It's the provable global minimum given the constraints. If someone proposes a cheaper plan with the same parameters, they're violating a constraint.

Open Kitchen: Play with the Solver

I distrust theories that can't be put into practice. That's why I've prepared a Google Colab where you can run the optimizer on a snapshot of our real data.

The most revealing experiment: change holding_cost to an extremely high value (e.g., €50/unit). Watch how the algorithm automatically decides to manufacture Just-in-Time and keep the warehouse practically empty. Then lower the production cost and watch it prefer to produce in bulk and store. Mathematics adapts. Excel's fixed rules don't.

📎 Open the Interactive Google Colab

Modify the costs, capacity constraints, Safety Stock. Do engineering, not faith.

The Complete Chain: From Data to Decisions

With this third chapter, we've built an end-to-end S&OP system that goes from a dirty ERP CSV to an optimal production plan:

Next Step: Scaling to Enterprise

We now have the perfect plan in our database. But only for one product. What happens when you add 3 SKUs sharing the same factory?

In Chapter 4 we break the MVP: we inject multi-product data with radically different profiles, parallelize the forecasting with MLOps, and build a unified Linear Programming model where products compete mathematically for shared production capacity.

The difference between an Operations Director who plans and one who optimizes is an objective function between their intuition and reality.

Ingeniería S&OP II: Demand Planning, de la Adivinación a la Probabilidad

Daniel — Sat, 07 Mar 2026 08:36:47 +0000

Tu Excel dice "venderemos 100 unidades". Es un número redondo, bonito, determinista. ¿Y si vendes 120? Rotura de stock, cliente insatisfecho, penalización contractual. ¿Y si vendes 50? 50 unidades ocupando almacén, inmovilizando capital que podría estar generando rendimiento.

El problema no es la predicción en sí. Es la arrogancia del número único.

En el Capítulo 1 construimos una "Válvula de Calidad" que elimina el ruido de los datos del ERP. Ahora que tenemos una señal pura, vamos a hacer algo que Excel no puede: medir la incertidumbre.

Resumen Ejecutivo: Un forecast probabilístico no te dice "venderás 100". Te dice "con un 95% de probabilidad, venderás entre 35 y 157". Esa banda de incertidumbre es la base matemática para calcular tu Safety Stock sin recurrir a reglas de dedo.

La Arquitectura: MLOps, no Scripts

No hemos escrito un script de usar y tirar. Hemos conectado nuestro cerebro matemático (Python/Prophet) directamente a nuestra Single Source of Truth (Supabase/PostgreSQL).

El diseño clave es la tabla demand_forecasts. Observa una columna que la diferencia de un tutorial básico:

CREATE TABLE demand_forecasts (
    id              UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    execution_date  DATE NOT NULL,     -- ← Cuándo corrimos el modelo
    ds              DATE NOT NULL,     -- Fecha futura predicha
    yhat            NUMERIC NOT NULL,  -- Predicción central
    yhat_lower      NUMERIC NOT NULL,  -- Límite inferior (Safety Stock)
    yhat_upper      NUMERIC NOT NULL,  -- Límite superior (Riesgo)
    model_version   TEXT NOT NULL,     -- Trazabilidad
    UNIQUE(execution_date, ds)         -- Un forecast por ejecución y fecha
);

¿Por qué execution_date? Porque dentro de 6 meses, cuando quieras auditar si tu modelo era preciso, necesitas saber cuándo hiciste la predicción frente a qué ocurrió realmente. Esto es lo que en MLOps se llama Snapshotting: registrar el contexto de cada ejecución para poder evaluar el drift del modelo a lo largo del tiempo.

Sin esta columna, tienes un modelo. Con ella, tienes un sistema auditable.

La Ingeniería: Por qué Prophet (y no un ARIMA de manual)

Prophet es un motor de series temporales desarrollado por Meta que fue diseñado para datos de negocio irregulares: gaps, festivos, cambios de tendencia. Exactamente lo que tiene una cadena de suministro real.

Aquí está el fragmento central de nuestra clase ProphetPredictor:

def train_model(self, country_code='ES'):
    """
    Entrena Prophet con dos configuraciones clave para S&OP:
    - interval_width: Ancho del intervalo de confianza
    - country_holidays: Contexto operativo del país
    """
    self.model = Prophet(
        interval_width=0.95,     # ← Intervalo de confianza del 95%
        weekly_seasonality=True,
        yearly_seasonality=True
    )
    # Festivos que alteran patrones de carga/descarga
    self.model.add_country_holidays(country_name=country_code)
    self.model.fit(self.ts_df)

Dos decisiones de ingeniería que nos separan de un tutorial de YouTube:

interval_width=0.95: No es un parámetro decorativo. El límite superior (yhat_upper) representa la demanda máxima probable con un 95% de confianza. Esto es literalmente tu base de cálculo para el Safety Stock: Safety Stock = yhat_upper - yhat. Sin este intervalo, tu stock de seguridad es una corazonada; con él, es matemática.

add_country_holidays('ES'): En S&OP, los festivos no son "días libres". Son anomalías operativas: la fábrica cierra, el almacén no despacha, el transporte para. Si el modelo no sabe que el 15 de agosto España está de vacaciones, interpretará la caída de pedidos como una tendencia a la baja. Esto corrompe la predicción de septiembre.

Traduciendo Matemáticas a Decisiones de Negocio

La teoría es bonita. Pero un Director General no aprueba presupuestos basándose en código Python. Necesita ver evidencia visual.

El Forecast Probabilístico

Los puntos negros son tu demanda histórica real. La línea azul central es la predicción (yhat). La banda sombreada es el intervalo de confianza al 95%. A mayor volatilidad histórica, más ancha es la banda → más Safety Stock necesitas → más caja inmovilizas. Esta banda es la conversación que deberías tener con tu CFO.

Explicabilidad: Separar Tendencia de Ruido Estacional

Esto es XAI (Explainable AI) aplicado al negocio. El modelo separa la Tendencia (¿el negocio crece o decrece?) de la Estacionalidad (¿hay picos por época del año?) y del efecto de los festivos. Esto es lo que el Director General necesita ver para aprobar el plan de operaciones: saber si el crecimiento es real o si es solo un efecto del calendario.

Open Kitchen: Pruébalo tú mismo

Desconfío de las teorías que no se pueden poner en práctica. Por eso, he preparado un entorno aislado donde puedes entrenar el modelo sobre un snapshot anonimizado de los datos que acabamos de limpiar en el Capítulo 1.

No necesitas instalar Python, ni Prophet, ni configurar Supabase. Solo necesitas un navegador:

📎 Abrir el Notebook interactivo en Google Colab

Dale a "Play" en las celdas y observa cómo se genera un forecast probabilístico con bandas de incertidumbre. Modifica el horizonte, el país, el intervalo de confianza. Haz ingeniería, no fe.

Siguiente Paso: De la Predicción a la Decisión

Ahora sabemos la probabilidad de lo que vamos a vender. La pregunta deja de ser "¿cuánto venderemos?" y pasa a ser "¿qué debemos fabricar o comprar para maximizar margen y minimizar riesgo?".

En el Capítulo 3, introduciremos Optimización Matemática (PuLP) y Teoría de Restricciones para transformar las predicciones en decisiones de suministro: cuánto comprar, cuándo producir y cómo distribuir recursos finitos minimizando costes.

La diferencia entre un Director de Operaciones que reacciona y uno que decide es un modelo matemático entre los datos y la acción.

S&OP Engineering II: Demand Planning from Guessing to Probability

Daniel — Sat, 07 Mar 2026 08:30:46 +0000

Your Excel says "we'll sell 100 units." A round, clean, deterministic number. What if you sell 120? Stockout, unhappy customer, contractual penalty. What if you sell 50? 50 units sitting in your warehouse, immobilizing capital that could be generating returns.

The problem isn't the forecast itself. It's the arrogance of the single number.

In Chapter 1 we built a "Quality Valve" that filters ERP noise. Now that we have a pure signal, we're going to do something Excel can't: measure uncertainty.

Executive Summary: A probabilistic forecast doesn't tell you "you'll sell 100." It tells you "with 95% probability, you'll sell between 35 and 157." That uncertainty band is the mathematical foundation for calculating your Safety Stock without resorting to rules of thumb.

The Architecture: MLOps, Not Scripts

We haven't written a throwaway script. We've connected our mathematical brain (Python/Prophet) directly to our Single Source of Truth (Supabase/PostgreSQL).

The key design is the demand_forecasts table. Notice one column that separates this from a basic tutorial:

CREATE TABLE demand_forecasts (
    id              UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    execution_date  DATE NOT NULL,     -- ← When we ran the model
    ds              DATE NOT NULL,     -- Predicted future date
    yhat            NUMERIC NOT NULL,  -- Central prediction
    yhat_lower      NUMERIC NOT NULL,  -- Lower bound (Safety Stock)
    yhat_upper      NUMERIC NOT NULL,  -- Upper bound (Risk)
    model_version   TEXT NOT NULL,     -- Traceability
    UNIQUE(execution_date, ds)         -- One forecast per execution and date
);

Why execution_date? Because in 6 months, when you want to audit whether your model was accurate, you need to know when you made the prediction versus what actually happened. This is what MLOps calls Snapshotting: recording the context of each execution to evaluate model drift over time.

Without this column, you have a model. With it, you have an auditable system.

The Engineering: Why Prophet (and Not a Textbook ARIMA)

Prophet is a time series engine developed by Meta, designed for irregular business data: gaps, holidays, trend changes. Exactly what a real supply chain has.

Here's the core fragment from our ProphetPredictor class:

def train_model(self, country_code='ES'):
    """
    Trains Prophet with two key S&OP configurations:
    - interval_width: Confidence interval width
    - country_holidays: Country operational context
    """
    self.model = Prophet(
        interval_width=0.95,     # ← 95% confidence interval
        weekly_seasonality=True,
        yearly_seasonality=True
    )
    # Holidays that alter loading/unloading patterns
    self.model.add_country_holidays(country_name=country_code)
    self.model.fit(self.ts_df)

Two engineering decisions that separate us from a YouTube tutorial:

interval_width=0.95: This is not a decorative parameter. The upper bound (yhat_upper) represents the maximum probable demand with 95% confidence. This is literally your calculation basis for Safety Stock: Safety Stock = yhat_upper - yhat. Without this interval, your safety stock is a gut feeling; with it, it's mathematics.

add_country_holidays('ES'): In S&OP, holidays aren't "days off." They're operational anomalies: the factory closes, the warehouse doesn't dispatch, transportation stops. If the model doesn't know that August 15th is a national holiday in Spain, it will interpret the drop in orders as a downward trend. This corrupts the September prediction.

Translating Math into Business Decisions

Theory is nice. But a CEO doesn't approve budgets based on Python code. They need visual evidence.

The Probabilistic Forecast

The black dots are your actual historical demand. The central blue line is the prediction (yhat). The shaded band is the 95% confidence interval. The greater the historical volatility, the wider the band → the more Safety Stock you need → the more cash you immobilize. This band is the conversation you should be having with your CFO.

Explainability: Separating Trend from Seasonal Noise

This is XAI (Explainable AI) applied to business. The model separates Trend (is the business growing or shrinking?) from Seasonality (are there spikes by time of year?) and holiday effects. This is what the CEO needs to see to approve the operations plan: knowing whether growth is real or just a calendar effect.

Open Kitchen: Try It Yourself

I distrust articles I can't execute. That's why I've prepared an isolated environment where you can train the model on an anonymized snapshot of the data we just cleaned in Chapter 1.

You don't need to install Python, Prophet, or configure Supabase. You just need a browser:

📎 Open the interactive Notebook on Google Colab

Hit "Play" on the cells and watch a probabilistic forecast with uncertainty bands being generated. Modify the horizon, the country, the confidence interval. Do engineering, not faith.

Next Step: From Prediction to Decision

Now we know the probability of what we're going to sell. The question shifts from "how much will we sell?" to "what should we manufacture or purchase to maximize margin and minimize risk?".

In Chapter 3, we'll introduce Mathematical Optimization (PuLP) and Theory of Constraints to transform predictions into supply decisions: how much to buy, when to produce, and how to distribute finite resources while minimizing costs.

The difference between an Operations Director who reacts and one who decides is a mathematical model between the data and the action.