La canalización de extracción de datos

Este documento tiene como objetivo servir de guía para los departamentos de TI en la construcción de un pipeline que extrae datos de los sistemas comerciales existentes y pone estos datos a disposición dentro de la plataforma de Lokad. La configuración de un pipeline de extracción de datos es una de las fases iniciales de una iniciativa Supply Chain Quantitativa. El documento abarca el enfoque que recomienda Lokad, incluyendo el alcance de los datos a 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 Supply Chain Quantitativa como aquella que proporciona una receta numérica que automatiza decisiones (o al menos recomendaciones) frente a los desafíos de supply chain. Lokad cuenta con una plataforma programática que ha sido diseñada para la resolución de problemas de optimización predictiva relacionados con supply chain.

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 se deben mover stocks dentro de la red

Si la empresa logra optimizar estas decisiones, generalmente puede disminuir sus costos operativos, reducir sus requerimientos de capital de trabajo y aumentar su calidad de servicio. Como mínimo, la empresa debería ser capaz de revisar esta combinación de costo, efectivo y servicio para hacerla más alineada con su estrategia global de supply chain.

La receta numérica, que aborda el problema de interés, está diseñada para ser implementada dentro de Lokad. Como resultado, la receta numérica requiere que se disponga de datos relevantes de la empresa en la plataforma de Lokad. Esto conlleva las siguientes preguntas:

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

Aunque los problemas listados anteriormente son variados, los datos de entrada relevantes son muy similares y, por lo general, se obtienen a través de los datos históricos transaccionales centrales 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 pipeline de extracción de datos. En las siguientes secciones se explicará en detalle lo que se requiere específicamente del departamento de TI.

Una vez creado el pipeline de extracción de datos, los ingenieros del lado de Lokad - denominados Supply Chain Scientists - son responsables de la configuración y el mantenimiento de la receta numérica. Con frecuencia, dichos ingenieros son provistos por Lokad como parte de un acuerdo de servicio “Platform+Experts”, pero también es posible que el cliente internalice esta competencia. Sin embargo, incluso cuando dichos ingenieros son internos, recomendamos ubicarlos en el departamento de supply chain, en lugar del de TI.

Independientemente de si esta parte de la iniciativa de supply chain se externaliza o no, la perspectiva expuesta 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, de manera realista, no pueden implementarse como parte de un sistema transaccional tradicional.

Cada cuenta de Lokad viene con un sistema de archivos que puede ser accedido 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 (más bien para el suministro de dashboards para usuarios no especializados). Se espera que los datos relevantes, normalmente extraídos de los sistemas transaccionales centrales utilizados por la empresa, se exporten como archivos planos (más sobre esto a continuación) y se suban al sistema de archivos de Lokad.

Salvo acuerdo en contrario, el departamento de TI del cliente es responsable de todo lo relacionado con los datos hasta el momento en que los archivos planos se suben al sistema de archivos de Lokad. El diseño de la plataforma de Lokad permite procesar fallos parciales en la extracción de datos (más sobre esto a continuación), por lo que el departamento de TI tiene cierta discreción al respecto.

Una vez que los datos se ponen a disposición de Lokad, una serie de scripts de Envision (Envision es el lenguaje de programación específico de dominio desarrollado por Lokad) los procesa y genera las decisiones optimizadas de supply chain de interés.

Existen varias aplicaciones prácticas de dicha extracción de datos, muchas de las cuales van más allá de la iniciativa de optimización de supply chain de Lokad. Los equipos de marketing, finanzas y ventas –por nombrar solo tres– son potenciales 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 “data lake” – que se reserve exclusivamente para proporcionar dichos datos a los equipos apropiados y a los sistemas analíticos de terceros (como la plataforma de Lokad).

La creación de un data lake no es un requisito para usar Lokad, sino simplemente una posible arquitectura que facilita las operaciones para la empresa. Cabe destacar que un data lake también facilita la aparición de una “práctica de datos” dentro de una empresa – en caso de que tal práctica no exista ya.

El alcance de los datos relevantes

El supply chain 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 que describen cualquier flujo que se produce dentro de la empresa. Estos datos se encuentran típicamente en los sistemas de negocio transaccionales del cliente.

Como se mencionó anteriormente, la plataforma de Lokad es bastante flexible en sus capacidades de procesamiento, por lo tanto, no hay requisitos estrictos en lo que respecta a los datos. Es muy probable que el cliente no pueda proporcionar muchos de los elementos de datos enumerados a continuación, y Lokad es capaz de operar dentro de tales limitaciones. Así, la lista a continuación intenta ser lo más completa posible en la identificación de fuentes de datos útiles, sin exigir la provisión estricta de cada una.

Catálogo de productos: La lista de productos (o ítems, artículos, partes) que la empresa compra, transforma, ensambla y/o vende. Esta lista es relevante porque muchas decisiones se toman a nivel de “producto”. La jerarquía (por ejemplo, categorías, familias, subfamilias), de estar presente, es relevante –tanto para fines de reporte como 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 supply chain – es relevante. Las relaciones entre productos – como las listas de materiales (BOMs) – también son relevantes.

Historial de órdenes de venta: La lista de órdenes de venta históricas del cliente. Esta lista es relevante porque las ventas casi siempre son el mejor proxy que tiene la empresa para estimar la demanda de mercado. Estos datos deberían incluir los montos monetarios asociados a las transacciones, ya que la optimización de supply chain debe realizarse desde una perspectiva financiera. (Esta perspectiva financiera se retoma más adelante con mayor detalle.) Donde sea posible, es (siempre) preferible proporcionar transacciones de órdenes en bruto, en lugar de agregados diarios/semanales/mensuales. (Este punto también se discute con mayor detalle a continuación.) El historial de órdenes de venta puede incluir órdenes pendientes, órdenes canceladas, órdenes pospuestas, órdenes modificadas, devoluciones, etc., todos los cuales son puntos de datos potencialmente relevantes. Si en estos datos se identifican clientes, los identificadores anónimos de los mismos se vuelven relevantes. (Los datos personales tienen su propia sección a continuación.)

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

Órdenes de producción: La lista de órdenes de producción históricas del cliente (si aplica), y las órdenes de producción pendientes (aún por ejecutar). Esta lista es relevante porque estas órdenes reflejan el flujo de transformación de bienes que se produce dentro de la empresa, además de permitir identificar los cuellos de botella que puedan existir en supply chain. Dependiendo de la situación, la producción puede tener rendimientos variables o, a veces, los lotes pueden ser descartados por problemas de calidad. Estos eventos son relevantes.

Movimientos de inventario: La lista de movimientos de inventario históricos del cliente si existen múltiples ubicaciones. Esta lista es relevante porque arroja luz sobre el origen del stock utilizado, ya sea para iniciar procesos de producción o para atender a los clientes. Dependiendo de la situación, los plazos para estos movimientos pueden variar. De ser 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 SKUs (unidad de mantenimiento de stock) del cliente con su stock actual. Esta lista es relevante porque caracteriza el estado actual de supply chain. Dependiendo de la industria, la representación del inventario puede ser más compleja que simples niveles de SKU. También pueden estar presentes las fechas de caducidad. Parte o la totalidad del inventario puede ser rastreada a nivel de número de serie. Si se utiliza inventario por número de serie, toda la lista de números de serie y sus ubicaciones asociadas es relevante. De manera general, todos los elementos que describen el estado presente de los activos de inventario de la empresa son relevantes.

Etiquetas de precios: La lista de precios que practica el cliente al atender los bienes (y posiblemente los servicios asociados). Esta lista es relevante porque la política de precios actual del cliente puede diferir de lo que solía cobrar. Los precios nuevos impactan la demanda futura, pero también la rentabilidad de las decisiones de supply chain. Pueden estar presentes promociones, rebajas u opciones de precios. Todos los elementos que contribuyen al cálculo de lo que se le cobra a los clientes son relevantes.

Las instantáneas de los niveles de stock pasados, las etiquetas de precios pasadas y las órdenes de compra pendientes pasadas también son relevantes para la mayoría de los propósitos de supply chain (sin embargo, estos datos rara vez están disponibles en los sistemas de negocio). En cuanto se establezca un pipeline de extracción de datos, tales instantáneas pueden implementarse 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 existen más fuentes de datos relevantes de las que se han listado aquí. Como regla general, si una pieza de información es de utilidad para la división de supply chain, es muy probable que sea relevante para fines de optimización predictiva y deba ser enviada a Lokad.

Esquema priorizado de los datos preparados

La lista de tablas de datos potencialmente relevantes citada anteriormente no tiene la intención de abrumar. En la práctica, es importante identificar qué tablas son requeridas 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 Supply Chain Scientists avancen más allá de la fase de extracción de datos y pasen a la de optimización.

Así, como parte de nuestra práctica de supply chain, Lokad recomienda que los Supply Chain Scientists produzcan un esquema priorizado de los datos preparados y compartan este documento con el departamento de TI del cliente al inicio de la iniciativa. Este documento lista las tablas – y sus campos – que se espera estén disponibles al final del segmento de preparación de datos. Este documento también enumera las respectivas prioridades de todos los campos solicitados.

Este esquema proporciona una lista de deseos a alto nivel para los datos a extraer. Sin embargo, este documento no debe interpretarse como una especificación para los archivos generados en la etapa de extracción de datos. Los Supply Chain Scientists son los encargados de la preparación de datos. Es aceptable (y común) que el esquema de los datos, tal como lo provea el pipeline de extracción de datos, difiera extensamente del esquema “idealizado” asociado con los datos preparados. Este punto se retoma con mayor 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 a extraer, generalmente existen dos preocupaciones distintas. Primero, ¿hasta qué punto en el pasado debe extenderse la extracción de datos? Segundo, ¿cuál es la profundidad histórica mínima necesaria para que la iniciativa de supply chain tenga éxito?

En términos generales, recomendamos extraer todo el historial disponible para todas las tablas que tengan menos de 1 billón de líneas. Editar el historial se traduce en perder datos que podrían ser relevantes para evaluar la evolución a largo plazo de supply chain. Los filtros se implementarán del lado de Lokad como parte de la preparación de datos, de todos modos, por lo que transferir más datos no se traduce necesariamente en más recursos computacionales 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 pueden ser estimados. Sin embargo, los profesionales de supply chain, que necesitan tomar las decisiones de interés, antes de la iniciativa de Lokad, están sujetos a las mismas limitaciones. La receta numérica de Lokad se implementará de manera que capitalice la profundidad histórica disponible, incluso si al cliente le parece escasa.

Datos faltantes

While modern business systems are typically extensive, there is invariably a lot of data that appears to be missing. As data is perceived to be missing, the viability of the quantitative supply chain initiative is challenged. However, no matter how much data happens to be “missing”, employees within the organization still manage to take the decisions that are needed for the supply chain to operate. In short, there is a way. Lokad’s technological approach relies on doing the most with whatever happens to be available – just like employees do. This approach is the opposite of mainstream enterprise software that comes with final data requirements and will not operate unless all the requirements are met.

En nuestra experiencia, existen dos grandes categorías de datos “faltantes” que se deben distinguir: primero, los datos que deberían integrarse en el sistema empresarial; segundo, los datos que se consideran muy beneficiosos para el sistema analítico (como Lokad).

Las Cantidades Mínimas de Pedido (MOQs), descuentos por precio y las semanas cerradas de los proveedores son datos que frecuentemente faltan en los sistemas empresariales. Sin embargo, estos datos son valiosos desde la perspectiva de optimizar la supply chain. Dichos datos pueden estar dispersos en hojas de cálculo y correos electrónicos, lo que impide cualquier análisis estructurado directo del lado de Lokad. Al enfrentar estas situaciones, sugerimos utilizar heurísticas (a ser codificadas por Lokad) y emplear hojas de cálculo ad hoc (para ser subidas a Lokad). Una vez que la receta numérica se vuelva operativa, Lokad involucrará al departamento de IT del cliente para incorporar los datos al/los sistema(s) empresarial(es). Además, la receta numérica en sí aclara cuáles datos son realmente importantes y en qué medida.

Los datos de inteligencia competitiva, como los precios de los competidores, conforman una categoría que se considera sumamente útil, pero, en nuestra experiencia, esto no es evidente por sí mismo. Anecdóticamente, obtener este tipo de datos a menudo conlleva un costo considerable, 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.

Extracciones transaccionales sin procesar

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

Intentar preparar los datos resulta invariablemente en pérdida de datos. Si esta pérdida es aceptable o no, depende de las decisiones específicas de la supply chain de interés. Si los datos ya se han perdido para cuando llegan a la plataforma de Lokad, no se puede hacer nada para recuperarlos. Las extracciones transaccionales sin procesar aseguran que la totalidad de la información disponible en los sistemas empresariales sea accesible en Lokad.

Además, la preparación de datos introduce su propia capa de complejidad sobre la complejidad inherente de los sistemas empresariales. Es cierto que la receta numérica que ofrece la optimización deseada de la supply chain no puede evitar enfrentarse a clases de complejidad intrínseca. Sin embargo, si esta receta numérica tiene además que lidiar con la complejidad accidental introducida por la preparación previa de datos, convierte un problema ya difícil en uno irrazonablemente complicado. Las extracciones transaccionales sin procesar aseguran que Lokad no termine enfrentándose a un problema aún mayor del que necesita ser resuelto.

Desde la perspectiva de IT, las extracciones transaccionales sin procesar son simples. Se deben utilizar copias literales de tablas (por ejemplo, SELECT * FROM MyTable), que es la forma más sencilla de realizar consultas en una base de datos relacional. Dichas consultas son simples, ya que no implican filtros, y eficientes, dado que no se utiliza ninguna unión. Sin embargo, las tablas muy grandes requieren una atención dedicada. Este punto se aborda a continuación.

Si existe un data lake, entonces este debe reflejar los datos relacionales tal como se encuentran en los sistemas empresariales. Todos los sistemas de bases de datos convencionales disponen de capacidades de replicación incorporadas. Recomendamos aprovechar estas capacidades al configurar el data lake. Además, replicar datos es mucho más sencillo que preparar datos, especialmente desde la perspectiva del departamento de IT, ya que la preparación de datos depende en gran medida del problema específico que se deba abordar.

El antipatrón de extracción BI

Los datos que se envíen a Lokad no deben originarse a partir de una fuente secundaria (por ejemplo, un sistema de Business Intelligence (BI)) en el que los datos ya han sido ampliamente modificados, generalmente en beneficio del consumo directo por parte del usuario final. Aunque extraer datos de un sistema BI es más fácil que hacerlo desde un ERP, esto invariablemente genera problemas irresolubles a futuro. Por diseño, se pierden los aspectos transaccionales de los datos, ya que estos se agregan en series temporales diarias, semanales o mensuales.

Además, muchas complicaciones difíciles de visualizar pero relevantes, como los pedidos con múltiples líneas, se eliminan de los sistemas de Business Intelligence (como los cubos BI). Estos detalles son valiosos ya que reflejan la esencia de las situaciones de supply chain que deben ser abordadas.

Datos erróneos

Según la experiencia de Lokad, los casos de datos erróneos son raros. Por el contrario, los sistemas empresariales transaccionales (como los ERPs) suelen contar con datos precisos. Las entradas de datos transaccionales incorrectas son poco comunes y, normalmente, se presentan una o dos veces por cada 1000 entradas. Cuando se utilizan códigos de barras o dispositivos similares, la tasa de error es aún menor. El verdadero problema radica en el software que realiza suposiciones incorrectas sobre los datos, en lugar de los datos en sí siendo erróneos.

Los niveles de stock en tienda para grandes redes minoristas B2C son casi siempre inexactos. Sin embargo, desde la perspectiva de Lokad, esta situación se trata de datos ruidosos, no de datos erróneos. Si se asume (incorrectamente) que dichos niveles de stock son precisos, los resultados carecerán de sentido. Abordamos esta situación específica con una visión probabilística de los niveles de stock, aceptando la incertidumbre en lugar de descartarla.

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

Datos personales

Una iniciativa de supply chain casi nunca necesita datos personales para operar. Por lo tanto, desde la perspectiva de la supply chain, recomendamos tratar los datos personales como una responsabilidad y no como un activo. Desaconsejamos firmemente 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 (véase la 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 otros anónimos opacos, si la información es relevante desde la perspectiva de la supply chain. Por ejemplo, los identificadores opacos de clientes son útiles porque permiten a Lokad identificar patrones relacionados con la fidelidad del cliente, como el impacto negativo de los faltantes de stock. A diferencia de la mayoría de las tecnologías de forecast que solo pueden operar con una perspectiva de series temporales, la plataforma de Lokad puede aprovechar datos históricos ultra-granulares, hasta e incluyendo el nivel transaccional.

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

Datos financieros

Los montos monetarios para los bienes comprados, transformados y vendidos por el cliente son de suma relevancia para la optimización de la supply chain que proporciona Lokad. De hecho, Lokad enfatiza una perspectiva financiera de la supply chain 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 de un cliente, si están disponibles. Lógicamente, los costos de la supply chain más angustiosos se concentran en los extremos; una demanda inesperadamente alta genera faltantes de stock; y una demanda inesperadamente baja genera bajas de inventario. Entre ambos, el inventario rota adecuadamente. Por lo tanto, para optimizar verdaderamente las decisiones de inventario, es necesario hacer un compromiso financiero respecto a estos riesgos. Lokad aprovecha los datos financieros de un cliente para calcular un compromiso adecuado.

Canal de datos vs extracción única

Un canal 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 alto. Esta automatización funciona mejor si se instala desde el Día 1. Sin embargo, las extracciones parciales únicas utilizadas para identificar tablas relevantes pueden ser útiles. Este punto se discute en los siguientes pasajes.

Existen tres razones principales para respaldar un enfoque de canal de datos.

Primero, desde la perspectiva del profesional de supply chain, los datos de hace 3 semanas son historia antigua. Los resultados obtenidos a partir de datos obsoletos son irrelevantes en lo que respecta a las decisiones actuales de supply chain. Una extracción única produciría resultados basados en una única instantánea de la historia empresarial del cliente. Esto generaría resultados de valor limitado. Además, los profesionales de supply chain necesitan ver el sistema analítico en acción para ganar confianza en su capacidad para manejar la variabilidad diaria.

Segundo, aunque diseñar un canal de datos altamente confiable es difícil, es preferible a las alternativas. Un canal de datos poco fiable pone en peligro toda la iniciativa de Supply Chain Quantitativa, ya que ninguna cantidad de análisis puede solucionar problemas básicos de datos, como no disponer de niveles de stock actualizados.

Generalmente, se requieren 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 el canal de datos lo antes posible, de modo que Lokad pueda identificar y resolver cualquier inconveniente. En particular, las ejecuciones programadas son también una de las opciones más seguras para evaluar el rendimiento de extremo a extremo de toda la secuencia de procesos, incluidos aquellos que conducen a la entrega de las decisiones recomendadas de supply chain.

Tercero, en nuestra experiencia, la causa más frecuente de retraso en las iniciativas de Supply Chain Quantitativa es la configuración tardía del canal de extracción de datos. Reconocemos que los departamentos de IT a menudo están bajo mucha presión para entregar numerosos proyectos, y construir un canal de extracción de datos es una tarea más con la que deben lidiar. Por lo tanto, es tentador —para el departamento de IT— posponer la parte del canal, 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, además de impedir que Lokad identifique clases enteras de problemas potenciales lo antes posible (como se describió en el párrafo anterior).

Frecuencia de extracción de datos

Recomendamos actualizar todos los canales 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 contradictorio, pero, en nuestra experiencia, las actualizaciones automatizadas frecuentes son la única forma de lograr un proceso de extremo a extremo altamente fiable.

Para la mayoría de las situaciones de supply chain, recomendamos una rutina de extracción que proporcione una imagen completa de los datos hasta el cierre del día laboral actual (por ejemplo, extrayendo el jueves por la tarde todos los datos históricos pertinentes hasta el cierre del negocio del jueves). El canal de extracción de datos se ejecuta al final de la jornada laboral, y el procesamiento analítico —dentro de la plataforma de Lokad— sigue. Los resultados actualizados están disponibles desde el inicio del siguiente día laboral.

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

Cuando los datos sean demasiado grandes para ser re-subidos en su totalidad a Lokad cada día, se deben utilizar cargas incrementales. Recomendamos que tales cargas sigan la regla 2+1 para incrementos: la ventana de tiempo de la carga diaria debe cubrir las últimas dos semanas completas, más la actual. Seguir esta regla es importante para garantizar la alta fiabilidad de la solución de Lokad.

El canal de extracción de datos fallará de vez en cuando, independientemente de Lokad. En nuestra experiencia, incluso los departamentos de IT excelentes experimentan entre 1 y 2 fallos en el canal por año. Cuando la carga diaria falla, el último día de datos queda comprometido. Si cada carga diaria solo cubre un día (sin superposición entre cargas), a Lokad le queda un historial de datos parcialmente corrupto. Corregir este historial, por parte de Lokad, requiere una segunda intervención manual del departamento de IT, además de arreglar lo que impidió que el canal de extracción de datos funcionara correctamente en primer lugar. Es probable que esta “corrección del historial de datos” se retrase unos días, ya que es una operación inusual para el departamento de IT. 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 dos últimas semanas completas de operaciones, más la actual, una ejecución fallida del canal de extracción de datos se beneficia de una recuperación completa al día siguiente. De hecho, dado que el canal de extracción de datos forma parte de las operaciones rutinarias del departamento de IT, es probable que la reanudación del estado normal de funcionamiento ocurra en un día hábil. Esta recuperación no requiere ninguna interacción específica entre el departamento de IT y el personal de soporte de Lokad ni con los usuarios finales de la solución de Lokad. La corrección de datos se entrega automáticamente mediante las sobrescrituras que se realizan a diario, abarcando la ventana de tiempo 2+1.

La regla 2+1 refleja un compromiso basado en la experiencia de Lokad: cuanto más larga es la ventana de tiempo, más resistente se vuelve el canal de extracción de datos ante problemas transitorios. Aunque podemos esperar que cualquier inconveniente con el canal de extracción se resuelva en un día hábil, es posible que el departamento de IT tenga asuntos más urgentes. De hecho, el fallo en el canal de extracción de datos puede ser solo un síntoma de un problema más grave que el departamento de IT priorice resolver. Así, la recuperación puede tardar algunos días. La regla 2+1 garantiza que, siempre que el departamento de IT logre reparar el canal en el transcurso de dos semanas, las operaciones puedan reanudarse con normalidad y con el menor impacto posible en la iniciativa de optimización. Sin embargo, si la ventana de tiempo es demasiado amplia, entonces la carga incremental se vuelve demasiado pesada en términos de recursos computacionales, lo que anula la razón misma por la que se introdujeron las cargas incrementales.

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

Identificando las tablas y columnas relevantes

La gran mayoría del software empresarial se construye sobre bases de datos relacionales. Aunque pueden existir APIs web, según nuestra experiencia, tales APIs rara vez ofrecen un rendimiento satisfactorio cuando se trata de extracciones programadas de todo el historial. Por el contrario, consultar directamente la base de datos mediante SQL frecuentemente resulta ser tanto sencillo de implementar como bastante eficiente, ya que las consultas SQL recomendadas por Lokad no requieren la realización de ningún join.

Así, una vez que un sistema de negocio (por ejemplo, ERP) ha sido considerado una fuente de datos relevante para la iniciativa, y suponiendo que se pueda acceder a la base de datos relacional subyacente, se debe identificar el listado específico de tablas y columnas relevantes. Muchos sistemas de negocio contienen cientos de tablas y miles de columnas, la mayoría de las cuales son irrelevantes para la iniciativa de supply chain. Como regla general, una iniciativa de supply chain 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 cuenta con un experto que esté familiarizado con 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 se puede realizar en una o dos semanas (incluso en presencia de un sistema bastante complejo). Además de aprovechar la documentación técnica que esté disponible sobre el sistema en cuestión, sugerimos comenzar con una extracción completa del esquema de la base de datos, que incluya:

• 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 detallada de las tablas más grandes, ya que es ahí donde usualmente se pueden descubrir las más relevantes (para una iniciativa de supply chain optimizada). Para inspeccionar una tabla, sugerimos una inspección visual de unas pocas docenas de líneas de datos. Las observaciones deben añadirse 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 las tablas:

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 las tablas:

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 Lokad soporta formatos de archivo de texto plano, formatos de archivos planos (típicamente CSV o TSV), así como hojas de cálculo de Microsoft Excel, tanto para operaciones de lectura como de escritura. La sección Read and Write Files documenta las capacidades de entrada/salida de Lokad. Aunque Lokad soporta un conjunto bastante diverso de opciones de formateo, recomendamos lo siguiente:

• Plain text se utiliza en lugar de hojas de cálculo (ver discusión abajo).
• La primera fila contiene los encabezados de las columnas y coincide con los nombres originales de las columnas.
• Los nombres de las columnas no contienen espacios ni guiones.
• UTF-8 se utiliza 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.
• 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 que, por convención, se usa para depositar los archivos extraídos.

Siempre que un archivo plano extraído sea mayor de 100MB, recomendamos comprimir el archivo utilizando GZIP.

En cuanto a la transferencia, recomendamos utilizar SFTP con autenticación por clave pública.

Tablas particionadas

Recomendamos particionar las tablas que son demasiado grandes para ser recargadas en su totalidad a Lokad de forma diaria. 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 justifican el esfuerzo que implica particionarlas.

Al particionar una tabla en una lista de archivos, el patrón de nomenclatura recomendado consiste en agrupar los archivos en una subcarpeta dedicada dentro de /input (nombrada según la tabla respectiva), y en 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
/..

Aunque todas las líneas dentro de un archivo tengan el mismo valor de “date” (que coincide con el encontrado en el nombre del archivo), recomendamos mantener esta columna “date” como parte del archivo.

Microsoft Excel

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

Las hojas de cálculo son aceptables si los archivos se cargan manualmente en Lokad, en lugar de ser transferidos a través de la canalización automatizada de extracción de datos. Las cargas manuales son aceptables si:

• Los datos no existen (aún) en los sistemas de negocio.
• Los datos se actualizan muy infrecuentemente.

/manual es la carpeta del lado de Lokad que, por convención, recibe los archivos subidos manualmente.

Sobrescritura de archivos

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

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

• una única columna llamada LastTransfer
• una única línea de datos (dos líneas contando la cabecera) con una marca de tiempo de la transferencia más reciente

Este archivo puede usarse para desencadenar una secuencia de proyectos que procese los datos recién actualizados.

Salud de los datos

La canalización de extracción de datos debe operar de manera confiable. La propia plataforma de Lokad puede usarse para instrumentar la salida de la canalización de extracción y evaluar la integridad, completitud y actualidad de los datos extraídos. Así, como primer paso de la canalización dentro de Lokad, recomendamos implementar tableros de salud de los datos. Estos tableros están destinados al departamento de IT (aunque no se espera que ellos se hagan cargo de ellos). El propósito colectivo de los tableros es identificar cualquier problema de datos y acelerar la eventual resolución por parte del departamento de IT. Se espera que esta implementación, como el resto de la receta numérica que impulsa la iniciativa de supply chain optimizada, sea realizada por un Supply Chain Scientist, posiblemente por el equipo de Lokad (en el caso de una suscripción Platform+Experts).

Especificación de la extracción de datos

Una vez que la canalización de extracción de datos se haya estabilizado, recomendamos elaborar una especificación para la extracción de datos. Este documento debe enumerar todos los archivos esperados y sus columnas, así como el calendario para la extracción de datos. Se espera que la estabilización de la canalización de datos ocurra dentro de los seis meses posteriores al inicio de la iniciativa. Este documento debe ser acordado conjuntamente por el departamento de IT y por el departamento de supply chain. Este documento contiene los pormenores de los datos que se espera que el departamento de IT ponga a disposición de la plataforma de Lokad de manera oportuna.

El formato de los datos aún puede ser revisado en una fecha posterior, pero se espera que el departamento de IT notifique al departamento de supply chain antes de realizar cualquier cambio en el formato de los datos o en el calendario asociado. En general, una vez que se haya acordado la especificación, se debe prever que las operaciones de supply chain dependan, para efectos de producción, de la integridad de la extracción de datos. Así, en caso de cualquier cambio, el departamento de supply chain debería 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).

Dado que elaborar una especificación detallada requiere tiempo y esfuerzo significativos, recomendamos retrasar la producción de este documento hasta que la canalización se estabilice. En nuestra experiencia, durante los primeros meses, la canalización –tanto sus segmentos de extracción de datos como analíticos– sufre una evolución rápida. Es probable que esta rápida evolución deprecie los primeros intentos de producir tal especificación.

Ciclo de retroalimentación

Las decisiones de supply chain (por ejemplo, los reabastecimientos de inventario) generadas dentro de la plataforma de Lokad pueden exportarse como archivos planos para ser reintegrados en el/los sistema(s) de negocio. Este mecanismo se conoce como el ciclo de retroalimentación. Nuestra experiencia indica que es poco probable que el ciclo de retroalimentación se implemente dentro de los cuatro meses posteriores al inicio de la iniciativa. La confianza en la receta numérica requerida para permitir que incluso una parte de supply chain funcione en piloto automático es considerable, y este grado de confianza puede tardar varios meses en cultivarse. Así, el ciclo de retroalimentación no es una preocupación al comienzo de la iniciativa.

En nuestra experiencia, la configuración del ciclo de retroalimentación es un desafío mucho menor que la configuración de la canalización de extracción de datos. Por ejemplo, se espera que las cifras, producidas dentro de Lokad, sean autoritativas y definitivas; si existen reglas adicionales para convertir esas cifras en números accionables (por ejemplo, MOQs aplicados), entonces la receta numérica está incompleta y necesita ser corregida en el lado de Lokad. Por otra parte, la plataforma de Lokad tiene la capacidad de procesar y producir cualquier forma de datos, siempre que estén razonablemente tabulados. Así, la sencillez del ciclo de retroalimentación está diseñada para reflejar la sencillez de las decisiones de supply chain. Por ejemplo, puede haber docenas de restricciones que definan si una orden de compra determinada es válida o no, pero el contenido de la orden de compra final es una lista directa de cantidades asociadas a números de parte.

Sin embargo, recomendamos que a la plataforma de Lokad no se le conceda acceso directo a los sistemas de negocio del cliente. En su lugar, los archivos deben estar disponibles de manera oportuna en el sistema de archivos de Lokad. El departamento de IT sigue siendo responsable de importar estos datos de vuelta a los sistemas de negocio. Esto garantiza que una posible vulneración de la seguridad de la cuenta de Lokad no pueda utilizarse 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 llevada a cabo por IT sobre el/los sistema(s) de negocio.

Dado que el ciclo de retroalimentación implica, por definición, datos relativos a las operaciones de supply chain en el mundo real, recomendamos elaborar una especificación dedicada a este proceso. Esta especificación refleja a la de extracción de datos, pero con los datos siendo transferidos en sentido contrario. También se espera que este documento sea acordado conjuntamente por los departamentos de IT y de supply chain.