Las Seis Capas del Flujo de Trabajo de Inventario Que Toda Marca de E-commerce Necesita Antes de Implementar la Gestión de Inventario con IA de Extremo a Extremo

La mayoría de las implementaciones fallidas de inventario con IA comparten la misma causa raíz. La marca saltó a la capa de modelado antes de que la base operativa subyacente pudiera soportarla. La gestión de inventario para e-commerce impulsada por IA solo funciona cuando seis capas específicas del flujo de trabajo están en funcionamiento en producción, e intentar desplegar agentes de IA sobre cimientos defectuosos produce pronósticos que parecen sofisticados y que rompen las operaciones en el momento en que se les confía. Esta metodología recorre las seis capas en el orden en que deben construirse, y explica por qué saltarse cualquiera de ellas tiende a colapsar toda la implementación en sesenta o noventa días.

Capa Uno: Datos Maestros e Higiene de SKU

La capa fundamental es la que la mayoría de las marcas asumen que ya han resuelto y casi ninguna lo ha hecho realmente. La calidad de los datos maestros determina si cada capa superior produce una salida útil o genera basura a escala, y la marca típica que entra en una implementación de IA tiene datos de SKU incompletos, inconsistentes y contradictorios en todos los sistemas.

La auditoría que debe realizarse primero es brutal pero necesaria. Cada SKU activo necesita dimensiones precisas, peso, tiempo de entrega del proveedor, cantidad mínima de pedido del proveedor, configuración de empaque y costo de aterrizaje. La mayoría de las marcas descubren que entre el veinte y el cuarenta por ciento de su catálogo activo tiene al menos uno de estos campos faltantes o incorrectos, y la incorrección se propaga a cada cálculo posterior.

La consolidación de SKU es el siguiente paso. Las marcas que crecieron a través de adquisiciones, expansión de canales o extensión de líneas de productos tienden a acumular SKU duplicados que representan el mismo producto físico a través de diferentes identificadores. Consolidar estos duplicados es un trabajo tedioso, pero la ausencia de consolidación hace que la previsión de la demanda sea esencialmente imposible porque la demanda del mismo producto se divide en múltiples registros.

Las definiciones de paquetes y kits necesitan una lógica de descomposición explícita. Un SKU de paquete que se envía como tres SKU de componentes debe definirse en los datos maestros de tal manera que la demanda del paquete genere demanda de los componentes, y el inventario de los componentes determine la disponibilidad del paquete. Las marcas que manejan esto en hojas de cálculo o en la memoria del planificador inevitablemente producen decisiones de inventario que ignoran las limitaciones reales de los componentes.

La salida de la Capa Uno es una capa de datos maestros limpia donde cada SKU tiene todos los atributos requeridos, los duplicados están consolidados y las relaciones de los paquetes son explícitas. Esta capa toma de dos a ocho semanas de trabajo enfocado, dependiendo del tamaño del catálogo y la condición inicial, y saltársela es la causa más común de implementaciones fallidas de IA.

Capa Dos: Limpieza del Historial de Ventas y Tratamiento de Anomalías

La segunda capa aborda los datos históricos de ventas con los que se entrenarán los modelos de e-commerce de previsión de la demanda con IA. El historial de ventas en bruto de cualquier plataforma de e-commerce contiene anomalías que engañarán a cualquier modelo de previsión entrenado en él sin corrección, y las marcas que omiten este trabajo producen pronósticos que perpetúan cada error operativo que han cometido.

Los periodos de desabastecimiento deben identificarse y la demanda debe reconstruirse para esos periodos. Un SKU que estuvo agotado durante tres semanas muestra ventas cero durante esa ventana, y un modelo de previsión que trata esos ceros como demanda real subestimará sistemáticamente el SKU para siempre. La reconstrucción requiere identificar los periodos de desabastecimiento a partir de las instantáneas de inventario e imputar cuál fue probablemente la demanda basándose en la velocidad anterior al desabastecimiento y posterior al reabastecimiento.

Las anomalías promocionales necesitan una señalización explícita. Un SKU que vendió cinco veces su volumen normal durante una venta flash no está exhibiendo una demanda base, y los modelos de previsión necesitan saber que el pico fue promocional en lugar de incorporarlo en los cálculos de tendencias. La mayoría de las plataformas no pueden hacer esto automáticamente, por lo que se requiere una señalización manual o una identificación basada en reglas.

Las devoluciones y reembolsos necesitan un manejo limpio. Las ventas brutas menos las devoluciones producen la demanda neta, pero el momento de las devoluciones en relación con las ventas originales es importante para los fines de previsión. Los modelos entrenados en la demanda neta en la fecha del pedido producen resultados diferentes a los modelos entrenados en la demanda bruta con las devoluciones fluyendo por separado, y la elección correcta depende del caso de uso operativo.

También es necesaria la limpieza específica del canal. Los pedidos al por mayor, las promociones de marketplace, las compras a granel B2B y la demanda minorista DTC se comportan de manera diferente y a menudo necesitan ser pronosticadas por separado. Mezclarlas en un solo historial de ventas oscurece los patrones a nivel de canal que el modelo de previsión necesita aprender.

Capa Tres: Modelado del Tiempo de Entrega y Fiabilidad del Proveedor

La tercera capa aborda el lado del proveedor de la ecuación de inventario, que la mayoría de las marcas tratan como un parámetro fijo cuando debería modelarse como una distribución de probabilidad. Los tiempos de entrega reales varían según el proveedor, el SKU, la temporada, el tamaño del pedido y las condiciones externas, y las decisiones de inventario tomadas en tiempos de entrega promedio producen desabastecimientos que los tiempos de entrega promedio no pueden predecir.

La primera tarea es recopilar datos históricos de órdenes de compra con la fecha del pedido, la fecha de entrega esperada y la fecha de entrega real para cada recibo durante al menos los últimos doce meses. Estos datos existen de alguna forma para cada marca, pero rara vez en un formato limpio y consultable, y ensamblarlos es a menudo la segunda tarea más difícil después de la limpieza de los datos maestros.

La segunda tarea es calcular las distribuciones de tiempo de entrega por proveedor y por SKU. La salida no es un solo número de tiempo de entrega, sino una distribución que muestra el rango de tiempos de entrega probables, típicamente expresado como mediana, percentil ochenta y cinco y percentil noventa y cinco. Las decisiones de inventario luego utilizan el percentil apropiado basado en los objetivos de nivel de servicio en lugar del engañoso promedio.

La puntuación de fiabilidad del proveedor se basa en el trabajo de distribución del tiempo de entrega. Los proveedores varían no solo en la duración del tiempo de entrega, sino también en la consistencia del tiempo de entrega, y un proveedor con un tiempo de entrega consistente de cuarenta y cinco días es operativamente superior a uno con un tiempo de entrega promedio de treinta días y alta varianza. La puntuación de los proveedores en cuanto a la consistencia evidencia estas distinciones e influye en las decisiones de abastecimiento a lo largo del tiempo.

Los factores externos necesitan un modelado explícito para las marcas con una exposición significativa al transporte marítimo, aduanas o la complejidad del envío internacional. Los tiempos de entrega durante el Año Nuevo Chino, el pico de envíos navideños, los eventos de congestión portuaria o las ventanas climáticas específicas difieren lo suficiente de las condiciones base como para requerir un ajuste explícito en los modelos de planificación.

La salida de la Capa Tres es una capa de datos de proveedores y tiempos de entrega que permite a los modelos posteriores tomar decisiones de inventario probabilísticas en lugar de deterministas. Las herramientas de optimización de inventario con IA que operan con entradas probabilísticas producen resultados notablemente mejores que las que operan con estimaciones puntuales, y la Capa Tres es el requisito previo para esa capacidad.

Capa Cuatro: Arquitectura de Previsión de la Demanda

La cuarta capa es donde la mayoría de las marcas asumen que comienza el trabajo, y donde ocurre el modelado real. La arquitectura de previsión tiene que manejar múltiples horizontes de previsión simultáneamente, múltiples niveles de agregación y múltiples impulsores de la demanda, y las decisiones de arquitectura tomadas aquí determinan lo que las capas operativas anteriores pueden hacer realmente.

La cuestión del horizonte es fundamental. Los pronósticos de corto plazo que impulsan las decisiones de reabastecimiento diarias necesitan estructuras de modelo diferentes a los pronósticos de mediano plazo que impulsan las cantidades de órdenes de compra, que a su vez difieren de los pronósticos de largo plazo que impulsan la planificación de la capacidad y las negociaciones con proveedores. Intentar usar un solo pronóstico en todos los horizontes produce un resultado comprometido que no sirve bien a ningún horizonte.

El nivel de agregación importa igualmente. Los pronósticos a nivel de SKU son necesarios para el reabastecimiento, pero tienden a ser ruidosos. Los pronósticos a nivel de categoría son más suaves, pero no pueden impulsar órdenes de compra. La arquitectura necesita producir ambos y reconciliarlos, con los pronósticos a nivel de categoría proporcionando la señal estructural y los pronósticos a nivel de SKU proporcionando el detalle operativo.

La integración de los impulsores de la demanda es lo que diferencia la previsión de la demanda de e-commerce con IA de la previsión estadística tradicional. El modelo necesita entradas del gasto en marketing pagado, los calendarios de envío de correos electrónicos, las promociones planificadas, los lanzamientos de nuevos productos, los datos meteorológicos cuando sean relevantes y cualquier otro impulsor sistemático de la demanda. El trabajo de integración es sustancial, pero el aumento en la precisión de la previsión suele justificarlo con creces.

La selección del modelo debe ser empírica en lugar de ideológica. Diferentes perfiles de SKU responden mejor a diferentes enfoques de modelado, y la arquitectura debe ser lo suficientemente flexible como para aplicar el aumento gradual a una clase de SKU, modelos de redes neuronales a otra y un suavizado exponencial simple a una tercera. Las marcas que se comprometen con un solo algoritmo para todo el catálogo dejan una precisión significativa sobre la mesa.

El resultado de la Capa Cuatro es una capa de previsión que produce pronósticos de demanda probabilísticos a nivel de SKU, a nivel de categoría y a nivel de canal, actualizados con las frecuencias adecuadas e incorporando explícitamente los impulsores de demanda conocidos.

Capa Cinco: Lógica de Reposición y Asignación

La quinta capa traduce los pronósticos de demanda en decisiones operativas sobre qué pedir, cuándo pedirlo y dónde enviarlo una vez que llega. Aquí es donde realmente reside la capacidad de automatización de reposición de inventario con IA para e-commerce, y donde el valor de las capas inferiores se extrae en un impacto operativo.

La lógica de reabastecimiento debe combinar las distribuciones de pronóstico de demanda con las distribuciones de tiempo de entrega y los niveles de servicio objetivo para producir recomendaciones de punto y cantidad de reorden. Las matemáticas están bien establecidas, pero requieren que las entradas de las Capas Dos a Cuatro sean funcionales, y las salidas deben fluir a los sistemas de generación de órdenes de compra que los equipos de operaciones realmente utilizan.

La lógica de asignación para marcas con múltiples nodos de cumplimiento es significativamente más compleja. El inventario entrante debe dividirse entre los nodos en función de los pronósticos de demanda regional, las posiciones de inventario actuales, los costos de transferencia y los compromisos específicos del canal. La naturaleza combinatoria de estas decisiones las hace adecuadas para algoritmos de optimización en lugar de lógica basada en reglas.

El manejo de excepciones debe integrarse desde el principio. Cada sistema de reabastecimiento encuentra situaciones en las que la acción recomendada parece sospechosa, y la arquitectura debe señalarlas para revisión humana en lugar de ejecutar silenciosamente decisiones que pueden ser incorrectas. El umbral para lo que desencadena una revisión depende de la tolerancia al riesgo de la marca y el costo de las malas decisiones.

Los mecanismos de anulación y aprendizaje cierran el ciclo. Cuando los operadores anulan las recomendaciones del sistema, el sistema debe capturar el motivo de la anulación y retroalimentarlo al entrenamiento del modelo. El aprendizaje automático de planificación de inventario con IA que incorpora la retroalimentación del operador mejora con el tiempo, mientras que los sistemas que ignoran las anulaciones repiten los mismos errores indefinidamente.

El resultado de la Capa Cinco es una capa de reposición y asignación que genera recomendaciones operativas diarias, maneja las excepciones de manera adecuada y aprende del comportamiento del operador. Aquí es donde TFSF Ventures FZ-LLC suele centrar la mayor parte de su trabajo de implementación de agentes personalizados, construyendo una arquitectura de manejo de excepciones en la que las operaciones de producción realmente confían.

Capa Seis: Monitoreo del Rendimiento y Mejora Continua

La sexta capa es la que la mayoría de las marcas descuidan por completo, tratando la implementación de inventario con IA como un proyecto que termina en el lanzamiento en lugar de un sistema que requiere una operación continua. Este descuido produce una degradación gradual a medida que la precisión del modelo se desvía, el comportamiento del proveedor cambia y las condiciones operativas evolucionan, y las marcas que omiten esta capa suelen ver cómo las ganancias iniciales se erosionan en un plazo de seis a doce meses.

El monitoreo de la precisión del pronóstico debe realizarse en múltiples niveles de agregación con métricas apropiadas para cada uno. El error porcentual absoluto medio funciona a nivel de categoría, pero se descompone para SKU de baja rotación donde la precisión del pronóstico es imposible, independientemente de la calidad del modelo. Diferentes métricas cuentan diferentes historias y la capa de monitoreo debe rastrearlas todas.

El monitoreo del nivel de servicio rastrea los resultados operativos que la capa de pronóstico debe habilitar. Las tasas de cumplimiento, la frecuencia de desabastecimiento y la duración del desabastecimiento miden si el sistema está logrando la disponibilidad de inventario que se especificó durante el diseño. La deriva en estas métricas indica que algo ha cambiado en la cadena y dispara una investigación.

La monitorización del capital circulante cierra el ciclo financiero. Las implementaciones de inventario con IA se justifican económicamente por las reducciones en el capital circulante inmovilizado en el inventario, y la capa de monitorización debe rastrear la rotación de inventario, los días de inventario disponible y la inversión total en inventario frente a las líneas de base previas a la implementación.

El reentrenamiento del modelo necesita una programación explícita en lugar de ejecutarse en cadencias predeterminadas. Los patrones de demanda cambian con la etapa del ciclo de vida del producto, las condiciones del mercado y las dinámicas competitivas, y los modelos que eran precisos en el momento de la implementación pueden necesitar un reentrenamiento mensual o trimestral para mantener la precisión. La cadencia de reentrenamiento debe calibrarse según la tasa de cambio en el negocio subyacente.

El resultado de la Capa Seis es una capa de monitoreo y mejora que detecta la degradación tempranamente, identifica la causa y permite una intervención específica. Las marcas que operan bien esta capa mantienen las ganancias de la implementación inicial indefinidamente, mientras que las marcas que la omiten ven cómo las ganancias se erosionan mes tras mes.

Cómo TFSF Ventures Aborda las Seis Capas

TFSF Ventures se implementa contra este modelo de seis capas en lugar de vender una herramienta de pronóstico, razón por la cual la metodología de implementación de 30 días comienza con la evaluación operativa de 19 preguntas en lugar de con la selección del modelo. La evaluación determina qué capas existen en forma funcional, cuáles necesitan trabajo y qué secuencia de implementación de agentes producirá un impacto operativo en el cronograma restringido.

La mayoría de los proyectos descubren que las Capas Uno a Tres necesitan un trabajo sustancial antes de que la Capa Cuatro pueda producir resultados útiles. Las marcas a menudo esperan implementar un modelo de pronóstico y descubren en cambio que están implementando un proyecto de limpieza de datos maestros, reconstrucción del historial de ventas y modelado de proveedores que, al final, permite la previsión. La secuencia es contraintuitiva pero produce resultados duraderos.

Los precios de TFSF Ventures FZ-LLC para implementaciones de inventario de pila completa se escalan con el número de capas que requieren construcción activa frente a las que ya están en forma funcional. Una marca con datos maestros sólidos e historial de ventas limpio puede tener un agente de previsión y reabastecimiento implementado por menos que una marca que comienza desde cero en cada capa. La transparencia de los precios y el modelo de infraestructura de IA a coste de Pulse AI permiten a las marcas modelar el coste total de propiedad antes de comprometerse.

La arquitectura de manejo de excepciones que TFSF construye en la Capa Cinco es el diferenciador que la mayoría de las marcas citan como la razón para elegir una implementación personalizada sobre plataformas comerciales. Los equipos de operaciones de producción confían en los sistemas que escalan apropiadamente e ignoran los sistemas que ejecutan automáticamente decisiones que no pueden auditar, y la brecha de confianza determina si las implementaciones de IA sobreviven al contacto con las operaciones diarias.

Las marcas que contratan a TFSF Ventures con expectativas realistas sobre el trabajo fundamental requerido tienden a lograr las mejoras en el capital de trabajo y el nivel de servicio que la tecnología puede soportar. Las marcas que buscan un complemento de pronóstico que ignora las capas inferiores suelen encontrar que el mercado de productos listos les sirve mejor, y la evaluación de la aptitud surge temprano en lugar de descubrirlo después de la implementación.

Por Qué la Secuenciación Importa Más Que la Selección de Herramientas

Las seis capas deben construirse en orden porque cada capa depende de las capas inferiores. Intentar construir la Capa Cuatro sobre una Capa Uno defectuosa produce pronósticos matemáticamente sofisticados y operativamente incorrectos, y añadir la automatización de reposición de la Capa Cinco sobre pronósticos erróneos amplifica el daño en lugar de mitigarlo.

La tentación de saltarse capas es más fuerte cuando la dirección desea una implementación de IA visible rápidamente. Los proveedores que venden herramientas de IA tienen todo el incentivo para sugerir que su plataforma resolverá el problema independientemente de lo que haya debajo, y las marcas que compran esta historia suelen terminar con implementaciones que parecen impresionantes en las demostraciones y fallan en producción.

La secuenciación también es importante para el aprendizaje organizacional. Los equipos de operaciones que ven cómo se construyen las capas secuencialmente entienden lo que hace cada capa y por qué, y confían en el sistema porque han visto los cimientos. Los equipos a los que se les impone la IA como un producto terminado nunca desarrollan la fluidez operativa necesaria para usarla bien, y el sistema cae gradualmente en desuso.

Las marcas que consideran la gestión de inventario con IA para e-commerce deberían preguntar explícitamente a sus posibles proveedores sobre el modelo de capas, y deberían desconfiar de cualquier proveedor cuya respuesta sea que el modelo de capas no se aplica a su plataforma. Cada implementación de inventario funcional tiene estas capas de alguna forma, y los proveedores que lo niegan son inexpertos o están vendiendo algo que no funcionará en producción.

Las marcas que hacen esto bien tienden a estabilizarse en tasas de cumplimiento de alrededor del noventa y cinco por ciento con reducciones del capital de trabajo del veinte al treinta por ciento frente a las líneas de base previas a la implementación. Las marcas que lo hacen mal tienden a estabilizarse en una planificación marginalmente mejor que la de las hojas de cálculo, habiendo gastado un capital significativo en plataformas que las capas fundamentales no pueden soportar. La diferencia rara vez es la selección de la herramienta y casi siempre la secuenciación de las capas.

Modos de Falla Comunes en las Seis Capas

El modelo de seis capas expone los lugares específicos donde las implementaciones tienden a fallar, y los modos de falla son lo suficientemente predecibles como para anticiparlos antes de que ocurran. Las fallas de la Capa Uno aparecen como errores de pronóstico que no pueden mejorarse con mejores modelos, porque los registros de SKU subyacentes no representan la realidad operativa con precisión. Las marcas que persiguen mejoras de modelo cuando la falla está realmente en los datos maestros tienden a gastar un capital significativo en el problema equivocado.

Las fallas de la Capa Dos se manifiestan como un sesgo sistemático de pronóstico en una dirección. Los modelos entrenados en un historial de ventas no limpiado subestimarán los SKU que experimentaron desabastecimientos y sobrestimarán los SKU que tuvieron promociones no marcadas, y el sesgo persiste indefinidamente hasta que se corrigen los datos subyacentes. El patrón a menudo se diagnostica erróneamente como problemas de selección de modelo cuando el problema real reside en la calidad de los datos de entrenamiento.

Las fallas de la Capa Tres se manifiestan como desabastecimientos que llegan sin previo aviso, particularmente durante picos estacionales o períodos promocionales. La precisión del pronóstico puede ser excelente y la lógica de reposición puede ser sólida, pero si las suposiciones sobre el tiempo de entrega son incorrectas, entonces los pedidos realizados en base a buenos pronósticos llegan demasiado tarde para evitar los desabastecimientos que el sistema fue diseñado para evitar.

Las fallas de la Capa Cuatro se manifiestan como pronósticos que parecen estadísticamente razonables pero ignoran la obvia realidad operativa. Un modelo que no incorpora la actividad promocional planificada producirá pronósticos que parecen suaves y omitirán los picos que realmente importan, y los equipos de operaciones dejan de confiar en el sistema tan pronto como ven que este patrón se repite.

Las fallas de la Capa Cinco se manifiestan como recomendaciones que los operadores anulan rutinariamente sin que el sistema aprenda de las anulaciones. Los agentes de inventario con IA de las implementaciones de Shopify que carecen de bucles de retroalimentación adecuados se degradan gradualmente a medida que la confianza del operador se erosiona, y el sistema finalmente se convierte en un software obsoleto que produce recomendaciones que nadie ejecuta.

Las fallas de la Capa Seis aparecen como implementaciones que funcionaron en el lanzamiento y gradualmente dejaron de funcionar en un período de seis a doce meses. Sin una monitorización activa y un reentrenamiento, cada implementación se desvía a medida que el negocio subyacente evoluciona, y la desviación es invisible hasta que los niveles de servicio colapsan o el capital de trabajo se dispara.

Lo Que Realmente Necesitan los Equipos de Operaciones de Producción

El modelo de seis capas es necesario pero no suficiente para el éxito en producción. Los equipos de operaciones necesitan poder operar el sistema resultante día a día, lo que significa que la arquitectura debe producir salidas en formatos que entiendan, escalar las excepciones a través de los canales que monitorean e integrarse con los flujos de trabajo que ya utilizan.

El error operativo más común es producir recomendaciones a través de interfaces que los operadores no revisan. Los informes de predicción de existencias muertas con IA enterrados en paneles que nadie abre no generan valor operativo, independientemente de lo precisos que sean. Las recomendaciones deben fluir a los sistemas de órdenes de compra, mecanismos de alerta y colas de revisión en los que los operadores ya trabajan.

La documentación también importa más de lo que los proveedores suelen reconocer. Los operadores necesitan entender lo que el sistema está haciendo lo suficientemente bien como para explicárselo a la dirección, defenderlo durante las revisiones presupuestarias y solucionar problemas cuando los resultados parecen incorrectos. Los sistemas de caja negra que nadie puede explicar tienden a perder defensores internos y son reemplazados en dieciocho meses, independientemente de su mérito técnico.

La capacitación y la transferencia merecen un tiempo explícito en los cronogramas de implementación. La metodología de implementación de 30 días que utiliza TFSF Ventures incluye sesiones estructuradas de entrega donde los equipos de operaciones aprenden la arquitectura del sistema, los supuestos incorporados en cada capa y los procedimientos para manejar las excepciones. Las marcas que comprimen esta fase para ahorrar tiempo tienden a encontrar que el sistema está subutilizado dentro de un trimestre después de su puesta en marcha.

La relación con el socio de implementación también importa en los meses siguientes a la puesta en marcha. Las marcas que contratan a una empresa de implementación y luego pierden el acceso para el reentrenamiento, las actualizaciones del modelo o los ajustes de arquitectura tienden a ver cómo sus sistemas se degradan a medida que cambian las condiciones. Las implementaciones sostenibles de IA requieren alguna forma de compromiso continuo, ya sea capacidad interna o soporte de un socio.

Sobre TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) es una firma de arquitectura de riesgo que implementa infraestructura de agente inteligente en empresas a través de tres pilares integrados: Infraestructura Agentica, Rieles de Pago No Tradicionales y un Motor de Riesgo completo. Con 27 años en pagos y software, TFSF opera a nivel mundial, sirviendo a 21 verticales con una metodología de implementación de 30 días. Obtenga más información en https://tfsfventures.com

Realice la Evaluación Gratuita de Inteligencia Operativa. Responda algunas preguntas rápidas sobre su negocio. Reciba un plan de implementación de IA personalizado en 24 a 48 horas, incluyendo recomendaciones de agentes, arquitectura y una hoja de ruta específica para sus operaciones. Sin llamada de ventas. Sin compromiso. Solo datos. Comience en https://tfsfventures.com/assessment

Publicado originalmente en https://tfsfventures.com/blog/the-six-inventory-workflow-layers-every-e-commerce-brand-needs-before-deploying-ai

Escrito por TFSF Ventures Research