Saltar al contenido principal
2026·ML Industrial & Retail·En curso

Pronóstico de demanda para vidrio automotriz

Pronóstico de demanda de componentes de vidrio automotriz para GM, Ford y Stellantis, más los bots que van por los datos a una docena de portales de cliente. Nada exótico debajo: series de tiempo y regresión sobre datos que extraigo y depuro yo mismo.

Cliente: Fabricante de vidrio automotriz (anonimizado)

VD
Cliente bajo confidencialidad. Los detalles técnicos están disponibles; los nombres se omiten por acuerdo.
3Armadoras atendidas
12+Portales automatizados
días → 1Disparador por flujo

El contexto

El cliente fabrica el vidrio que termina en los parabrisas de GM, Ford y Stellantis. Planear esa producción depende de anticipar la demanda de cada armadora, y esa información no llegaba sola: vivía detrás de una docena de portales de cliente, cada uno con su carácter.

El reto técnico

Dos problemas encadenados. El primero, que la mitad del trabajo era conseguir y depurar los datos, que es la mitad que nadie mete en la presentación. El segundo, que un pronóstico que nadie abre no sirve de nada, y la entrega es donde se mueren en silencio la mayoría de los modelos.

La solución

Bots autónomos programados como jobs en Databricks resuelven solos cómo atravesar los portales de cliente y traen la información. Sobre esos datos corren modelos de series de tiempo y regresión en Python y PySpark, con el ciclo de vida completo cubierto entre Databricks y Azure: preparación, entrenamiento, evaluación y versionado. Los resultados salen por su cuenta como reportes ejecutivos diarios en correo, PDF y archivos de Office.

PythonPySparkDatabricksAzurePlaywrightMLOps

Decisiones clave

  • Series de tiempo y regresión antes que algo más sofisticado: el cuello de botella estaba en los datos, no en el modelo.
  • Los bots resuelven solos cómo atravesar cada portal, en vez de un script por portal que se rompe cuando cambia el HTML.
  • Los reportes se mandan solos. La entrega es donde se mueren en silencio la mayoría de los modelos.
  • El ciclo de vida completo entre Databricks y Azure, con versionado: es la parte menos vistosa y la razón de que los modelos sigan acertando seis meses después.

Resultados

Los ciclos de planificación se acortaron y el inventario se ajustó. Un flujo que antes se comía días ahora corre con un disparador, y el equipo ya se olvidó felizmente de que existe. En esa oficina nadie ha tenido que pedir un reporte desde entonces, y para mí ese es el logro.

Mi rol

Ingeniero de IA y científico de datos, como consultor. Me hago cargo del pronóstico, de los bots que traen los datos, del esquema de MLOps y de sentarme con los dueños del negocio y con TI para que el pronóstico sea uno que de verdad vayan a usar.

Lo que aprendí

La parte que decide si un modelo sobrevive no es el modelo. Es que los datos lleguen sin que nadie los persiga y que el resultado aparezca donde la gente ya está mirando.

¿Quieres algo similar para tu organización?

Hablemos de tu proyecto. Respondo en menos de 24 horas.