El Canal de Extracción de Datos

Este documento está destinado como una guía para los departamentos de TI para construir un canal que extraiga datos de los sistemas empresariales existentes y ponga estos datos a disposición en la plataforma de Lokad. La configuración de un canal de datos es una de las primeras fases de una iniciativa cuantitativa de la cadena de suministro. El documento cubre el enfoque que Lokad recomienda, incluyendo el alcance de los datos que se deben extraer y poner a disposición en la plataforma de Lokad, el formato de los datos y las estrategias de transferencia de datos.

Motivación y contexto

Lokad define una iniciativa cuantitativa de la cadena de suministro como aquella que ofrece una receta numérica que automatiza decisiones (o al menos recomendaciones) frente a desafíos de la cadena de suministro. Lokad cuenta con una plataforma programática que ha sido diseñada para la resolución de problemas de optimización predictiva relacionados con la cadena de suministro.

Los problemas típicos incluyen:

• Decidir las cantidades de stock a reponer
• Decidir las cantidades de stock a producir
• Decidir si aumentar o disminuir los precios
• Decidir si los stocks deben ser movidos dentro de la red

Si la empresa tiene éxito en la optimización de estas decisiones, generalmente puede disminuir sus costos operativos, reducir sus requisitos de capital de trabajo y aumentar su calidad de servicio. Como mínimo, la empresa debería poder revisar esta combinación de costos, efectivo y servicio para que esté más alineada con su estrategia general de cadena de suministro.

La receta numérica, que aborda el problema de interés, está destinada a ser implementada dentro de Lokad. Como resultado, la receta numérica requiere que los datos relevantes de la empresa estén disponibles en la plataforma de Lokad. Esto lleva a las siguientes preguntas:

• ¿Qué datos deben transferirse a Lokad?
• ¿Qué formato se debe utilizar para los datos?
• ¿Qué patrones de transferencia se deben utilizar para actualizar los datos?

Si bien los problemas mencionados anteriormente son variados, los datos de entrada relevantes son muy similares y generalmente se prestan a través de los datos históricos transaccionales básicos de la empresa (ventas históricas, por ejemplo).

El departamento de TI del cliente suele ser responsable de la configuración y el mantenimiento del canal de extracción de datos. En las secciones siguientes, se explicará en detalle lo que se requiere específicamente del departamento de TI.

Una vez que se crea el canal de extracción de datos, los ingenieros de Lokad, conocidos como Supply Chain Scientists, son responsables de la configuración y el mantenimiento de la receta numérica. Estos ingenieros suelen ser proporcionados por Lokad como parte de un acuerdo de servicio “Plataforma+Expertos”, pero también es posible que el cliente internalice esta competencia. Sin embargo, incluso cuando estos ingenieros están en la empresa, recomendamos ubicarlos en el departamento de cadena de suministro en lugar del departamento de TI.

Independientemente de si esta parte de la iniciativa de la cadena de suministro se externaliza o no, la perspectiva descrita en este documento sigue siendo la misma.

Perspectiva técnica de alto nivel

Lokad es una capa analítica que opera sobre los sistemas transaccionales existentes del cliente. En otras palabras, Lokad no reemplaza al ERP; lo complementa con capacidades de optimización predictiva que, realísticamente, no se pueden implementar como parte de un sistema transaccional tradicional.

Cada cuenta de Lokad viene con un sistema de archivos al que se puede acceder a través de los protocolos SFTP y FTPS. También está disponible una interfaz web, aunque esta interfaz no está destinada típicamente a nuestra audiencia de TI (sino a la provisión de paneles de control para usuarios no especializados). Esperamos que los datos relevantes, típicamente extraídos de los sistemas transaccionales principales utilizados por la empresa, se exporten como archivos planos (más detalles a continuación) y se carguen en el sistema de archivos de Lokad.

A menos que se acuerde lo contrario, el departamento de TI del cliente es responsable de todo lo relacionado con los datos hasta el punto en que los archivos planos se cargan en el sistema de archivos de Lokad. El diseño de la plataforma de Lokad es tal que puede procesar fallas parciales en la extracción de datos (más detalles a continuación), por lo que el departamento de TI tiene cierta flexibilidad al respecto.

Una vez que los datos están disponibles para Lokad, una serie de scripts de Envision (Envision es el lenguaje de programación específico del dominio desarrollado por Lokad) los procesan y generan las decisiones optimizadas de la cadena de suministro de interés.

Hay varias aplicaciones prácticas de esta extracción de datos, muchas de las cuales van más allá de la iniciativa de optimización de la cadena de suministro de Lokad. Marketing, finanzas y equipos de ventas, por nombrar solo tres, son posibles beneficiarios de los mismos datos históricos de ventas que Lokad procesa eventualmente. Por esta razón, Lokad recomienda consolidar los datos transaccionales en una capa de servicio dedicada, un “lago de datos”, que esté exclusivamente reservado para la provisión de dichos datos a equipos apropiados y sistemas analíticos de terceros (como la plataforma de Lokad).

La creación de un lago de datos no es un requisito para usar Lokad, simplemente es una arquitectura potencial que facilita las operaciones de la empresa. Vale la pena señalar que un lago de datos también facilita la aparición de una “práctica de datos” dentro de una empresa, en caso de que dicha práctica aún no exista.

El alcance de los datos relevantes

La cadena de suministro se trata de optimizar decisiones relacionadas con el flujo de bienes físicos (compras, transporte, producción, ventas, etc.). Como resultado, los datos más relevantes para una iniciativa de optimización predictiva son casi siempre los datos que describen los flujos que ocurren dentro de la empresa. Estos datos se encuentran típicamente en los sistemas de negocios transaccionales del cliente.

Como se mencionó anteriormente, la plataforma de Lokad es bastante flexible en cuanto a sus capacidades de procesamiento, por lo tanto, no hay requisitos estrictos en cuanto a los datos. Lo más probable es que el cliente no pueda proporcionar muchos de los elementos de datos enumerados a continuación, y Lokad puede operar dentro de esas limitaciones. Por lo tanto, la siguiente lista intenta ser lo más completa posible al identificar fuentes de datos útiles, sin requerir la provisión estricta de cada una.

Catálogo de productos: La lista de productos (o artículos, partes) que la empresa compra, transforma, ensambla y/o vende. Esta lista es importante porque muchas decisiones se toman a nivel de “producto”. La jerarquía (por ejemplo, categorías, familias, subfamilias), si está presente, es relevante, tanto para fines de informes como para fines analíticos. Los atributos estructurados (por ejemplo, color, tamaño, peso, forma) que califican los productos también son útiles. Como regla general, cualquier dato que describa los productos, desde una perspectiva de cadena de suministro, es relevante. Las relaciones entre productos, como las listas de materiales (BOM, por sus siglas en inglés), también son relevantes.

Historial de pedidos de venta: La lista de los pedidos de venta históricos del cliente. Esta lista es importante porque las ventas casi siempre son el mejor indicador que tiene la empresa para estimar la demanda del mercado. Estos datos deben incluir los montos monetarios asociados con las transacciones, ya que la optimización de la cadena de suministro debe realizarse desde una perspectiva financiera. (Esta perspectiva financiera se aborda con más detalle más adelante). Cuando sea posible, es (siempre) preferible proporcionar transacciones de pedidos en bruto, en lugar de agregados diarios/semanales/mensuales. (Este punto también se discute con más detalle a continuación). El historial de pedidos de venta puede incluir pedidos pendientes, pedidos cancelados, pedidos pospuestos, pedidos modificados, devoluciones, etc., todos los cuales son puntos de datos potencialmente relevantes. Si los clientes están identificados en estos datos, los identificadores de clientes anonimizados se vuelven relevantes. (Los datos personales tienen su propia sección a continuación).

Órdenes de compra: La lista de las órdenes de compra históricas del cliente, así como las órdenes de compra pendientes (aún por recibir). Esta lista es importante porque las órdenes de compra casi siempre son el mejor indicador para estimar los tiempos de entrega del proveedor y su calidad de servicio. Las órdenes de compra pendientes reflejan el “stock en pedido”. Las órdenes de compra también deben incluir los montos monetarios asociados con las transacciones. Cuando sea posible, también es (siempre) preferible proporcionar el historial de órdenes en bruto en lugar de agregados. El historial de órdenes de compra debe incluir, si están disponibles, las fechas relevantes: fecha de pedido, fecha de envío, fecha de entrega, etc.

Órdenes de producción: La lista de las órdenes de producción históricas del cliente (si corresponde), y las órdenes de producción pendientes (aún por ejecutar). Esta lista es importante porque estas órdenes reflejan el flujo de transformación de bienes que ocurre dentro de la empresa, así como nos permiten identificar los cuellos de botella que pueden existir en la cadena de suministro. Dependiendo de la situación, la producción puede tener rendimientos variables o a veces los lotes pueden ser desechados debido a problemas de calidad. Estos eventos son relevantes.

Movimientos de inventario: La lista de los movimientos de inventario históricos del cliente si hay múltiples ubicaciones. Esta lista es importante porque arroja luz sobre el origen del stock utilizado para desencadenar procesos de producción o atender a los clientes. Dependiendo de la situación, los tiempos de entrega para estos movimientos pueden ser variables. Si es así, los detalles de las fechas (fecha de orden de transferencia, fecha de envío, fecha de recepción) también son relevantes.

Niveles de stock: La lista de todos los SKU (unidad de mantenimiento de stock) del cliente con su nivel de stock actual. Esta lista es importante porque caracteriza el estado actual de la cadena de suministro. Dependiendo de la industria, la representación del inventario puede ser más compleja que simples niveles de SKU. También puede haber fechas de vencimiento. Algunos o todos los inventarios pueden rastrearse a nivel de número de serie. Si se utiliza un inventario serializado, toda la lista de números de serie y sus ubicaciones asociadas son relevantes. En general, todos los elementos que describen el estado actual de los activos de inventario que posee la empresa son relevantes.

Etiquetas de precio: La lista de los precios que practica el cliente al prestar los bienes (y posiblemente los servicios asociados). Esta lista es importante porque la política de precios actual del cliente puede diferir de lo que solía cobrar. Los precios más nuevos afectan la demanda futura, pero también la rentabilidad de las decisiones de la cadena de suministro. También puede haber promociones, descuentos de precios u opciones de precios. Todos los elementos que contribuyen al cálculo de lo que se cobra a los clientes son relevantes.

También son relevantes instantáneas de los niveles de stock pasados, las etiquetas de precio pasadas y los pedidos de compra pendientes pasados para la mayoría de los propósitos de la cadena de suministro (sin embargo, estos datos rara vez están disponibles en los sistemas empresariales). Tan pronto como se establezca un canal de extracción de datos, estas instantáneas se pueden implementar dentro de Lokad mismo, sin intervención directa del departamento de TI del cliente.

Aunque esta lista ya es considerable, cuando se trata de empresas, generalmente hay más fuentes de datos relevantes de las que se han enumerado aquí. Como regla general, si una pieza de información es útil para la división de la cadena de suministro, es muy probable que sea relevante para fines de optimización predictiva y debe dirigirse a Lokad.

Esquema priorizado de los datos preparados

La lista de tablas de datos potencialmente relevantes mencionadas anteriormente no pretende abrumar. En la práctica, es importante identificar qué tablas son necesarias para llevar la iniciativa a producción, en lugar de ser agradables de tener. También es importante priorizar adecuadamente las extracciones para permitir que los científicos de la cadena de suministro pasen de la fase de extracción de datos a la de optimización.

Por lo tanto, como parte de nuestra práctica de cadena de suministro, Lokad recomienda que los científicos de la cadena de suministro elaboren un esquema priorizado de los datos preparados y compartan este documento con el departamento de TI del cliente al comienzo de la iniciativa. Este documento enumera las tablas, y sus campos, que se espera que estén disponibles al final del segmento de preparación de datos. Este documento también enumera las prioridades respectivas de todos los campos solicitados.

Este esquema proporciona una lista de deseos de alto nivel para los datos que se van a extraer. Sin embargo, este documento no debe entenderse como una especificación para los archivos generados en la etapa de extracción de datos. Los científicos de la cadena de suministro son responsables de la preparación de los datos. Es aceptable (y común) que el esquema de los datos, tal como está disponible a través del canal de extracción de datos, difiera ampliamente del esquema “idealizado” asociado con los datos preparados. Este punto se revisa con más detalle en la sección “Extractos transaccionales en bruto” a continuación.

Profundidad histórica de los datos

Cuando se trata de la profundidad histórica de los datos que se van a extraer, generalmente hay dos preocupaciones distintas. Primero, ¿hasta qué punto en el pasado debe llegar la extracción de datos? Segundo, ¿cuál es la profundidad histórica mínima necesaria para que la iniciativa de la cadena de suministro tenga éxito?

En general, recomendamos extraer toda la historia disponible para todas las tablas que tienen menos de mil millones de líneas. Editar el historial implica perder datos que podrían ser relevantes para evaluar la evolución a largo plazo de la cadena de suministro. De todos modos, se implementarán filtros en Lokad como parte de la preparación de datos, por lo que transferir más datos no necesariamente se traduce en más recursos informáticos para Lokad.

En cuanto a la profundidad histórica, no hay un requisito mínimo. Si el historial del sistema es corto (por ejemplo, seis meses), entonces ciertos patrones estadísticos, como la estacionalidad, no se pueden estimar. Sin embargo, los profesionales de la cadena de suministro, que necesitan tomar las decisiones de interés antes de la iniciativa de Lokad, están limitados por las mismas limitaciones. La receta numérica de Lokad se implementará de manera que aproveche cualquier profundidad de historia que esté disponible, incluso si parece escasa para el cliente.

Datos faltantes

Si bien los sistemas empresariales modernos suelen ser extensos, invariablemente hay muchos datos que parecen faltar. A medida que se percibe que faltan datos, se cuestiona la viabilidad de la iniciativa cuantitativa de la cadena de suministro. Sin embargo, no importa cuántos datos falten, los empleados dentro de la organización aún logran tomar las decisiones necesarias para que la cadena de suministro funcione. En resumen, hay una manera. El enfoque tecnológico de Lokad se basa en hacer lo máximo con lo que esté disponible, al igual que lo hacen los empleados. Este enfoque es opuesto al software empresarial convencional que viene con requisitos finales de datos y no funcionará a menos que se cumplan todos los requisitos.

En nuestra experiencia, hay dos amplias clases de datos “faltantes” que deben distinguirse: primero, datos que deberían integrarse en el sistema empresarial; segundo, datos que se consideran muy beneficiosos para el sistema analítico (como Lokad).

Las cantidades mínimas de pedido (MOQ), los descuentos por volumen y las semanas cerradas de los proveedores son datos que a menudo faltan en los sistemas empresariales. Sin embargo, estos datos son valiosos desde una perspectiva de optimización de la cadena de suministro. Estos datos pueden estar dispersos en hojas de cálculo y correos electrónicos, lo que impide cualquier análisis estructurado directo en Lokad. Cuando se enfrenta a estas situaciones, sugerimos utilizar heurísticas (que Lokad codificará) y utilizar hojas de cálculo ad hoc (que se cargarán en Lokad). Una vez que la receta numérica se vuelva operativa, Lokad involucrará al departamento de TI del cliente para que los datos formen parte del sistema (o sistemas) empresarial(es). Además, la receta numérica en sí misma aclara qué datos son realmente importantes y en qué medida.

Los datos de inteligencia competitiva, como los precios de los competidores, son una categoría que se considera muy útil, pero en nuestra experiencia, esto no es evidente por sí mismo. Anecdóticamente, obtener este tipo de datos a menudo conlleva un costo sustancial, de lo contrario, las empresas ya lo harían. Por esta razón, proporcionar dichos datos no es un requisito. En cualquier caso, la receta numérica de Lokad será fundamental para evaluar, en una fecha posterior, las ganancias financieras reales asociadas con datos adicionales.

Extractos transaccionales en bruto

Recomendamos encarecidamente preservar la forma original de los datos. Los datos enviados a Lokad no deben ser más que copias en bruto de las tablas y columnas originales, tal como se encuentran en el RDBMS que respalda los sistemas empresariales de la empresa. Toda la preparación de datos debe delegarse en la plataforma de Lokad, que ha sido especialmente diseñada para la preparación de datos.

Intentar preparar los datos inevitablemente resulta en pérdida de datos. Si los datos ya se han perdido cuando llegan a la plataforma de Lokad, no se puede hacer nada para recuperar esta pérdida. Los extractos transaccionales en bruto aseguran que toda la información disponible en los sistemas empresariales sea accesible dentro de Lokad.

Además, la preparación de datos introduce su propia capa de complejidad además de la complejidad de los propios sistemas empresariales. Es cierto que la receta numérica que ofrece la optimización de la cadena de suministro deseada no puede evitar tratar con clases de complejidad intrínseca. Sin embargo, si esta receta numérica también tiene que lidiar con la complejidad accidental introducida por la preparación previa de datos, convierte un problema ya difícil en uno irrazonablemente difícil. Los extractos transaccionales en bruto aseguran que Lokad no termine abordando un problema aún mayor que el que necesita ser resuelto.

Desde una perspectiva de TI, los extractos transaccionales en bruto son simples. Se deben utilizar copias de tablas simples (por ejemplo, SELECT * FROM MyTable), que es la forma más sencilla de consultas en una base de datos relacional. Estas consultas son simples, ya que no hay filtros involucrados, y son eficientes, ya que no hay uniones involucradas. Sin embargo, las tablas muy grandes requieren cierta atención especial. Este punto se trata a continuación.

Si hay un lago de datos en su lugar, entonces el lago de datos debe reflejar los datos relacionales tal como se encuentran en los sistemas empresariales. Todos los sistemas de bases de datos principales tienen capacidades de reflejo incorporadas. Recomendamos aprovechar estas capacidades al configurar el lago de datos. Además, reflejar datos es mucho más fácil que preparar datos, especialmente desde la posición del departamento de TI, ya que la preparación de datos depende en gran medida del problema específico que se debe abordar.

El antipatrón de extracción de BI

Los datos que se enviarán a Lokad no deben provenir de una fuente secundaria (por ejemplo, un sistema de inteligencia empresarial (BI)) donde los datos ya se hayan modificado ampliamente, generalmente en beneficio del consumo directo por parte del usuario final. Aunque extraer datos de un sistema de BI es más fácil que de un ERP, esto inevitablemente crea problemas insolubles a largo plazo. Por diseño, los aspectos transaccionales de los datos se pierden, ya que los datos se agregan en series de tiempo diarias / semanales / mensuales.

Además, se eliminan de los sistemas de inteligencia empresarial (como los cubos de BI) muchas complicaciones relevantes pero difíciles de visualizar, como los pedidos de varias líneas. Estos detalles son valiosos ya que reflejan la esencia de las situaciones de la cadena de suministro que deben abordarse.

Datos incorrectos

En la experiencia de Lokad, las instancias de datos incorrectos son raras. Por el contrario, los sistemas empresariales transaccionales (como los ERPs) suelen tener datos precisos. Las entradas incorrectas de datos transaccionales son raras y suelen ocurrir una o dos veces por cada 1000 entradas. Cuando se utilizan códigos de barras u otros dispositivos similares, la tasa de error es aún menor. El verdadero problema radica en el software que hace suposiciones incorrectas sobre los datos, más que en los propios datos siendo incorrectos.

Los niveles de stock en tienda para redes minoristas B2C casi siempre son inexactos. Sin embargo, desde la perspectiva de Lokad, esta situación es un caso de datos ruidosos, no de datos incorrectos. Si se asume (incorrectamente) que dichos niveles de stock son precisos, los resultados serán absurdos. Abordamos esta situación específica con una visión probabilística de los niveles de stock, abrazando la incertidumbre en lugar de descartarla.

En resumen, los sistemas de Lokad han sido diseñados para recibir datos y permitir que el cliente opere su cadena de suministro sin preocuparse por estos problemas. Lokad establece una semántica de datos para abordar estos problemas y esto representa la parte más desafiante de la etapa de preparación de datos.

Datos personales

Casi nunca es necesario utilizar datos personales en una iniciativa de cadena de suministro. Por lo tanto, desde una perspectiva de cadena de suministro, recomendamos tratar los datos personales como una responsabilidad, no como un activo. Desaconsejamos enérgicamente la transferencia de datos personales a la plataforma de Lokad. En la práctica, esto generalmente significa filtrar las columnas de la base de datos (ver discusión a continuación) que contienen identificadores personales (por ejemplo, nombre, dirección, número de teléfono, correo electrónico, etc.).

Estos identificadores personales pueden ser reemplazados por identificadores anónimos opacos, si la información es relevante desde una perspectiva de cadena de suministro. Por ejemplo, los identificadores opacos de los clientes son útiles porque permiten a Lokad identificar patrones relacionados con la lealtad del cliente, como el impacto negativo de los faltantes de stock. A diferencia de la mayoría de las tecnologías de pronóstico que solo pueden operar con una perspectiva de series de tiempo, la plataforma de Lokad puede aprovechar datos históricos ultra-granulares, hasta y incluyendo el nivel de transacción.

Si no está seguro de la posición de Lokad sobre la Información de Identificación Personal (PII), este tema se aborda en las Secciones 1, 3 y 4 de nuestro documento de seguridad.

Datos financieros

Los montos monetarios de los bienes comprados, transformados y vendidos por el cliente son de suma relevancia para la optimización de la cadena de suministro que Lokad proporciona. De hecho, Lokad enfatiza una perspectiva financiera de la cadena de suministro que optimiza dólares de retorno sobre porcentajes de error.

A diferencia de los proveedores que solo consideran datos relacionados con las cantidades de stock, Lokad utiliza los datos financieros del cliente, si están disponibles. Lógicamente, los costos de cadena de suministro más preocupantes se concentran en los extremos; una demanda inesperadamente alta genera faltantes de stock y una demanda inesperadamente baja genera cancelaciones de inventario. En el medio, el inventario rota sin problemas. Por lo tanto, para optimizar realmente las decisiones de inventario, se debe hacer un equilibrio financiero con respecto a estos riesgos. Lokad utiliza los datos financieros del cliente para calcular un equilibrio adecuado.

Tubería de datos vs extracción única

Una tubería de extracción de datos actualiza automáticamente los datos transferidos a Lokad. Esta configuración representa un esfuerzo mayor que una extracción única de datos. Si es posible, recomendamos encarecidamente automatizar la extracción de datos, posiblemente con un enfoque gradual si el número de tablas relevantes es grande. Esta automatización funciona mejor si se instala desde el primer día. Sin embargo, las extracciones únicas parciales utilizadas para identificar tablas relevantes pueden ser útiles. Este punto se discute en los siguientes pasajes.

Hay tres razones principales para respaldar un enfoque de tubería de datos.

En primer lugar, desde la perspectiva del profesional de la cadena de suministro, los datos de hace 3 semanas son historia antigua. Los resultados obtenidos a partir de datos obsoletos no son relevantes en cuanto a las decisiones de la cadena de suministro actuales. Una extracción única produciría resultados basados en una única instantánea del historial comercial del cliente. Esto produciría resultados de valor limitado. Además, los profesionales de la cadena de suministro necesitan ver el sistema en acción analíticamente para ganar confianza en su capacidad para manejar la variabilidad diaria.

En segundo lugar, aunque la ingeniería de una tubería de datos altamente confiable es difícil, es preferible a las alternativas. Una tubería de datos poco confiable pone en peligro toda la iniciativa cuantitativa de la cadena de suministro, ya que ninguna cantidad de análisis puede solucionar problemas básicos de datos, como no tener acceso a niveles de stock actualizados.

Por lo general, se necesitan numerosas ejecuciones programadas para perfeccionar el proceso de extracción, ya que algunos problemas solo se presentan de forma intermitente. La forma más segura de solucionar estos problemas es comenzar a ejecutar la tubería de datos lo antes posible, lo que permite a Lokad identificar y resolver cualquier problema. En particular, las ejecuciones programadas también son una de las opciones más seguras para evaluar el rendimiento de principio a fin de toda la secuencia de procesos, incluidos aquellos que conducen a la entrega de decisiones recomendadas de la cadena de suministro.

En tercer lugar, en nuestra experiencia, la causa más frecuente de retraso en las iniciativas cuantitativas de la cadena de suministro es la configuración tardía de la tubería de extracción de datos. Reconocemos que los departamentos de TI suelen estar bajo mucha presión para entregar muchos proyectos y construir una tubería de extracción de datos es una tarea más con la que deben lidiar. Por lo tanto, es tentador, para el departamento de TI, posponer la parte de la tubería, optando en su lugar por comenzar con una serie de extracciones únicas. Aunque este enfoque es viable, presenta el riesgo de introducir retrasos en la iniciativa, así como de evitar que Lokad identifique clases enteras de problemas potenciales lo antes posible (como se describe en el párrafo anterior).

Frecuencia de extracción de datos

Recomendamos actualizar todas las tuberías de datos, tanto los segmentos de extracción como los segmentos analíticos, al menos una vez al día, incluso cuando se trate de cálculos mensuales o trimestrales. Esto puede parecer contraintuitivo, pero, en nuestra experiencia, las actualizaciones automáticas frecuentes son la única forma de lograr un proceso de principio a fin altamente confiable.

Para la mayoría de las situaciones de la cadena de suministro, recomendamos una rutina de extracción que proporcione una imagen completa de los datos hasta el cierre del día hábil actual (por ejemplo, extrayendo el jueves por la noche todos los datos históricos pertinentes hasta el cierre del negocio del jueves). La tubería de extracción de datos se ejecuta al final del día de trabajo y el procesamiento analítico, dentro de la plataforma Lokad, sigue. Los resultados frescos están disponibles desde el comienzo del próximo día hábil.

Profundidad de extracción de datos: la regla 2+1 para incrementos

Cuando los datos son demasiado grandes para volver a cargarlos por completo en Lokad todos los días, se deben utilizar cargas incrementales. Recomendamos que estas cargas sigan la regla 2+1 para incrementos: la ventana de tiempo de la carga diaria cubre las últimas dos semanas completas, más la actual. Seguir esta regla es importante para garantizar la alta confiabilidad de la solución de Lokad.

La tubería de extracción de datos fallará de vez en cuando, independientemente de Lokad. En nuestra experiencia, incluso los excelentes departamentos de TI experimentan de 1 a 2 fallas en la tubería por año. Cuando la carga diaria falla, el último día de datos se ve comprometido. Si cada carga diaria solo cubre un día (sin superposición entre las cargas), Lokad se queda con un historial de datos parcialmente corrupto. Arreglar este historial, desde el lado de Lokad, requiere una segunda intervención manual por parte del departamento de TI, además de solucionar lo que impidió que la tubería de extracción de datos se ejecutara correctamente en primer lugar. Esta “corrección del historial de datos” probablemente se retrasará unos días, ya que es una operación inusual para el departamento de TI. Mientras tanto, los resultados devueltos por Lokad se ven afectados negativamente, ya que algunos datos recientes resultan estar parcialmente corruptos.

Por el contrario, si cada carga diaria cubre las últimas dos semanas completas de trabajo, más la actual, una ejecución diaria fallida de la tubería de extracción de datos se beneficia de una recuperación completa al día siguiente. De hecho, como la tubería de extracción de datos es parte de las operaciones de rutina cubiertas por el departamento de TI, es probable que se reanude el estado normal de operación en un día hábil. Esta recuperación no requiere ninguna interacción específica entre el departamento de TI y el personal de soporte de Lokad o los usuarios finales de la solución de Lokad. La corrección de datos se entrega automáticamente a través de las sobrescrituras que ocurren diariamente en la ventana de tiempo de 2+1.

La regla de 2+1 refleja un compromiso basado en la experiencia de Lokad: cuanto más largo sea el intervalo de tiempo, más resistente se vuelve la tubería de extracción de datos contra problemas transitorios. Aunque podemos esperar que cualquier problema con la tubería de extracción de datos se resuelva en un día hábil, el departamento de TI puede tener problemas más urgentes. De hecho, la tubería de extracción de datos fallida puede ser solo un síntoma de un problema más grave que el departamento de TI prioriza resolver. Por lo tanto, la recuperación puede llevar algunos días. La regla de 2+1 garantiza que siempre que el departamento de TI logre solucionar la tubería dentro de las dos semanas, las operaciones puedan reanudarse como de costumbre con el menor impacto posible en la iniciativa de optimización. Sin embargo, si la ventana de tiempo es demasiado larga, entonces la carga incremental se vuelve demasiado pesada en términos de recursos informáticos, lo que va en contra de la razón misma por la que se introdujeron las cargas incrementales en primer lugar.

Si las últimas tres semanas representan menos de 100MB de datos, sugerimos adoptar la variante mensual de la regla de 2+1: la ventana de tiempo de la carga diaria cubre los últimos dos meses completos, más el actual.

Identificación de las tablas y columnas relevantes

La gran mayoría del software empresarial se basa en bases de datos relacionales. Si bien pueden existir API web, en nuestra experiencia, dichas API rara vez ofrecen un rendimiento satisfactorio cuando se trata de extracciones completas programadas de historial. Por el contrario, consultar directamente la base de datos a través de SQL a menudo resulta tanto fácil de implementar como bastante eficiente, ya que las consultas SQL recomendadas por Lokad no requieren realizar ninguna unión.

Por lo tanto, una vez que se ha considerado que un sistema empresarial (por ejemplo, ERP) es una fuente de datos relevante para la iniciativa y suponiendo que se puede acceder a la base de datos relacional subyacente, se deben identificar las tablas y columnas relevantes específicas. Muchos sistemas empresariales contienen cientos de tablas y miles de columnas, la mayoría de las cuales no son relevantes para la iniciativa de la cadena de suministro. Como regla general, una iniciativa de cadena de suministro rara vez necesita más de una docena de tablas para comenzar y solo unas pocas docenas para lograr un alto grado de cobertura de datos.

Si la empresa tiene acceso a un experto que conoce el esquema de la base de datos del negocio, aprovechar esta experiencia es la forma más sencilla de identificar las tablas relevantes dentro de la base de datos. Sin embargo, si no hay un experto, la ingeniería inversa de la base de datos para identificar las áreas de interés generalmente aún se puede hacer en una o dos semanas (incluso en presencia de un sistema bastante complejo). Además de aprovechar cualquier documentación técnica accesible sobre el sistema de interés, sugerimos comenzar con una extracción completa del esquema de la base de datos, que incluye:

• el nombre de la tabla
• el nombre de la columna
• el tipo de columna
• el tamaño de la tabla

Sugerimos recopilar esta información en una hoja de cálculo. Las tablas potenciales se pueden identificar por sus nombres y tamaños. Sugerimos comenzar con una inspección más cercana de las tablas más grandes, ya que ahí es donde generalmente se pueden descubrir las más relevantes (para una iniciativa de cadena de suministro optimizada). Para inspeccionar una tabla, sugerimos una inspección visual de varias docenas de líneas de datos. Las observaciones deben agregarse a la hoja de cálculo a medida que avanza el trabajo.

Diagnóstico del esquema de PostgreSQL

La consulta para extraer todas las tablas y columnas:

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name = '‘table_name'’;

Ver también https://stackoverflow.com/questions/20194806/how-to-get-a-list-column-names-and-datatypes-of-a-table-in-postgresql

La consulta para extraer todos los tamaños de tabla:

select table_name, pg_relation_size(quote_ident(table_name))
from information_schema.tables
where table_schema = '‘public'’

Ver también https://stackoverflow.com/questions/21738408/postgresql-list-and-order-tables-by-size

La plantilla de consulta para extraer una muestra de filas:

select column from table
order by RANDOM()
limit 10000

Ver también https://stackoverflow.com/questions/19412/how-to-request-a-random-row-in-sql

Diagnóstico del esquema de Oracle

La consulta para extraer todas las tablas y columnas:

SELECT table_name, column_name, data_type FROM ALL_TAB_COLUMNS

La consulta para extraer todos los tamaños de tabla:

SELECT table_name, num_rows FROM ALL_TABLES

La plantilla de consulta para extraer una muestra de filas:

set colsep ,
set headsep off
set pagesize 0
set trimspool on
spool c:/temp/oracle/output/foo_my_table.csv
SELECT * FROM FOO_MY_TABLE FETCH FIRST 10000 ROWS ONLY;
spool off

Formatos de archivo y transferencias

La plataforma de Lokad admite formatos de archivo de texto plano (generalmente formatos CSV o TSV) y hojas de cálculo de Microsoft Excel, tanto para operaciones de lectura como de escritura. La sección Leer y escribir archivos documenta las capacidades de E/S de Lokad. Si bien Lokad admite una amplia variedad de opciones de formato, recomendamos lo siguiente:

• Texto plano se utiliza en lugar de hojas de cálculo (ver discusión a continuación).
• La primera fila contiene los encabezados de columna y coincide con los nombres de columna originales.
• Los nombres de columna no contienen espacios en blanco ni guiones.
• Se utiliza UTF-8 para la codificación de caracteres.
• Punto (.) es el separador decimal para números fraccionarios.
• Todas las fechas comparten el mismo formato en todas las tablas.
• Las cantidades monetarias aíslan la moneda en una columna separada.
• El nombre del archivo coincide con el nombre original de la tabla.
• /input es la carpeta del lado de Lokad utilizada, por convención, para depositar los archivos extraídos.

Cuando un archivo plano extraído es mayor de 100MB, recomendamos comprimir el archivo usando GZIP.

En cuanto a las transferencias, recomendamos utilizar SFTP con autenticación de clave pública.

Tablas particionadas

Recomendamos particionar las tablas que son demasiado grandes para ser convenientemente vuelvas a cargar en Lokad en su totalidad a diario. La partición generalmente permite cargas incrementales si la partición refleja la antigüedad de los datos. Como regla general, las tablas que tienen menos de 1 millón de líneas generalmente no valen el esfuerzo que lleva particionarlas.

Al particionar una tabla en una lista de archivos, el patrón de nomenclatura de archivos recomendado consiste en reunir los archivos en una subcarpeta dedicada dentro de /input (llamada como la tabla respectiva) y agregar un sufijo a cada archivo con el segmento extraído correspondiente:

/input/mytable/mytable-2022-10-17.csv
/input/mytable/mytable-2022-10-18.csv
/input/mytable/mytable-2022-10-19.csv
/..

Incluso si todas las líneas dentro de un archivo tienen el mismo valor de “fecha” (que coincide con el que se encuentra en el nombre del archivo), recomendamos mantener esta columna de “fecha” como parte del archivo.

Microsoft Excel

La plataforma de Lokad admite la lectura de datos desde hojas de cálculo de Microsoft Excel, siempre que la hoja de cálculo siga un formato tabular (la primera línea contiene los encabezados y luego un registro por línea). Sin embargo, el canal de extracción de datos debe evitar transferir hojas de cálculo a Lokad.

Las hojas de cálculo son aceptables si los archivos se cargan manualmente en Lokad, en lugar de transferirse a través del canal de extracción de datos automatizado. Las cargas manuales son aceptables si:

• Los datos no existen (aún) en los sistemas comerciales.
• Los datos se actualizan con muy poca frecuencia.

/manual es la carpeta del lado de Lokad utilizada, por convención, para recibir archivos cargados manualmente.

Sobrescritura de archivos

Los archivos dentro del sistema de archivos de Lokad representan los datos tal como los ve Lokad. Sobrescribir archivos existentes es la forma recomendada de actualizar las tablas extraídas que no están particionadas. En el caso de una tabla particionada, la expectativa predeterminada es tener un nuevo archivo creado para cada período (un archivo por día, semana o mes).

Una vez que todos los archivos que se van a crear (o sobrescribir) se transfieren a Lokad, recomendamos crear (o actualizar) un archivo llamado /input/end-of-transfer.csv que contenga:

• una sola columna llamada LastTransfer
• una sola línea de datos (dos líneas al contar el encabezado) con una marca de tiempo de la transferencia más reciente

Este archivo se puede utilizar para activar una secuencia de proyectos que procese los datos actualizados recientemente.

Salud de los datos

El canal de extracción de datos debe funcionar de manera confiable. La propia plataforma de Lokad se puede utilizar para instrumentar la salida del canal de extracción y evaluar la integridad, la completitud y la actualidad de los datos extraídos. Por lo tanto, como primer paso del canal dentro de Lokad, recomendamos implementar paneles de salud de los datos. Estos paneles están destinados al departamento de TI (aunque no se espera que se hagan cargo de ellos). El propósito colectivo de los paneles es resaltar cualquier problema de datos y acelerar la eventual resolución por parte del departamento de TI. Se espera que esta implementación, al igual que el resto de la receta numérica que impulsa la iniciativa de cadena de suministro optimizada, sea realizada por un experto en cadena de suministro, posiblemente por el equipo de Lokad (en el caso de una suscripción de Plataforma+Expertos).

Especificación de la extracción de datos

Una vez que el canal de extracción de datos se haya estabilizado, recomendamos producir una especificación para la extracción de datos. Este documento debe enumerar todos los archivos esperados y sus columnas, así como el cronograma para la extracción de datos. Se espera que la estabilización del canal de datos ocurra dentro de los seis meses posteriores al inicio de la iniciativa. Este documento debe ser acordado conjuntamente por el departamento de TI y el departamento de cadena de suministro. Este documento contiene los detalles de los datos que se espera que el departamento de TI ponga a disposición de la plataforma de Lokad de manera oportuna.

El formato de los datos aún se puede revisar en una fecha posterior, pero se espera que el departamento de TI notifique al departamento de cadena de suministro antes de realizar cualquier cambio en el formato de los datos o en el cronograma asociado. En general, una vez que se haya acordado la especificación, se espera que las operaciones de la cadena de suministro dependan, para fines de producción, de la integridad de la extracción de datos. Por lo tanto, en caso de cualquier cambio, el departamento de cadena de suministro debe esperar un “período de gracia” razonable que sea suficiente para actualizar la lógica dentro de Lokad (para adaptarse al formato de datos revisado).

Como la producción de una especificación detallada requiere tiempo y esfuerzo significativos, recomendamos retrasar la producción de este documento hasta que el canal se haya estabilizado. En nuestra experiencia, durante los primeros meses, el canal, tanto en su extracción de datos como en sus segmentos analíticos, experimenta una rápida evolución. Esta rápida evolución es probable que invalide los primeros intentos de producir dicha especificación.

Bucle de retroalimentación

Las decisiones de la cadena de suministro (por ejemplo, reabastecimientos de inventario) generadas dentro de la plataforma Lokad se pueden exportar como archivos planos para ser reintegradas en el sistema o sistemas comerciales. Este mecanismo se conoce como el bucle de retroalimentación. Nuestra experiencia indica que es poco probable que el bucle de retroalimentación se implemente en los primeros cuatro meses del inicio de la iniciativa. La confianza en la fórmula numérica necesaria para permitir que incluso una parte de la cadena de suministro funcione en piloto automático es considerable, y este grado de confianza puede tardar varios meses en cultivarse. Por lo tanto, el bucle de retroalimentación no es una preocupación al comienzo de la iniciativa.

En nuestra experiencia, la configuración del bucle de retroalimentación es un desafío mucho menor que la configuración del canal de extracción de datos. Por ejemplo, las cifras, tal como se producen dentro de Lokad, se espera que sean autorizadas y finales; si hay reglas adicionales que se deben aplicar para convertir esas cifras en números accionables (por ejemplo, MOQ aplicados), entonces la fórmula numérica está incompleta y necesita ser corregida en el lado de Lokad. Por otro lado, la plataforma de Lokad tiene la capacidad de procesar y producir cualquier forma de datos siempre que sea razonablemente tabular. Por lo tanto, la simplicidad del bucle de retroalimentación está diseñada para reflejar la simplicidad de las decisiones de la cadena de suministro. Por ejemplo, puede haber docenas de restricciones que definan si un determinado pedido de compra es válido o no, pero el contenido del pedido de compra final es una lista sencilla de cantidades asociadas a números de parte.

Sin embargo, recomendamos que la plataforma de Lokad no tenga acceso directo a los sistemas comerciales del cliente. En su lugar, los archivos deben estar disponibles de manera oportuna dentro del sistema de archivos de Lokad. El departamento de TI sigue a cargo de importar estos datos de vuelta en los sistemas comerciales. Esto garantiza que una posible violación de seguridad de la cuenta de Lokad no se pueda utilizar para acceder a otros sistemas dentro de la empresa. Además, esto proporciona la capacidad de posponer esta operación de retroalimentación si entra en conflicto con otra operación realizada por TI en los sistemas comerciales.

Dado que el bucle de retroalimentación implica, por definición, datos relacionados con operaciones de la cadena de suministro del mundo real, recomendamos producir una especificación dedicada a este proceso. Esta especificación refleja la de extracción de datos, pero con los datos transferidos en dirección opuesta. También se espera que este documento sea acordado conjuntamente por los departamentos de TI y cadena de suministro.