En este artículo, revisaremos la funcionalidad de “órdenes sugeridas” en Epicor BisTrack, explicaremos sus limitaciones y resumiremos cómo la Planificación y optimización inteligente del inventario (Smart IP&O) puede ayudar a reducir el inventario y minimizar los desabastecimientos al evaluar con precisión las compensaciones entre los riesgos de desabastecimiento. y costos de inventario.

Automatización del reabastecimiento en Epicor BisTrack
Los “Pedidos sugeridos” de Epicor BisTrack pueden gestionar el reabastecimiento sugiriendo qué pedir y cuándo mediante políticas basadas en puntos de reorden, como mínimo-máximo y/o semanas de suministro especificadas manualmente. BisTrack contiene algunas funciones básicas para calcular estos parámetros en función del uso o las ventas promedio, el tiempo de entrega del proveedor y/o los ajustes estacionales definidos por el usuario. Alternativamente, los puntos de reorden se pueden especificar de forma completamente manual. Luego, BisTrack presentará al usuario una lista de pedidos sugeridos conciliando el suministro entrante, el actual disponible, la demanda saliente y las políticas de almacenamiento.

Cómo funciona el “pedido sugerido” de Epicor BisTrack
Para obtener una lista de pedidos sugeridos, los usuarios especifican los métodos detrás de las sugerencias, incluidas las ubicaciones para realizar pedidos y cómo determinar las políticas de inventario que rigen cuándo se hace una sugerencia y en qué cantidad.

Primero, el campo "método" se especifica entre las siguientes opciones para determinar qué tipo de sugerencia se genera y para qué ubicación(es):

Compra – Generar recomendaciones de órdenes de compra.

1. Centralizado para todas las sucursales: genera sugerencias para una única ubicación que compra para todas las demás ubicaciones.
2. Por sucursal individual: genera sugerencias para múltiples ubicaciones (los proveedores enviarían directamente a cada sucursal).
3. Por sucursal de origen: genera sugerencias para una sucursal de origen que transferirá material a las sucursales a las que presta servicio (“hub and Spoke”).
4. Sucursales individuales con transferencias: genera sugerencias para una sucursal individual que transferirá material a las sucursales a las que presta servicios ("centro y radio", donde el "centro" no necesita ser una sucursal de origen).

Fabricar – Generar sugerencias de órdenes de trabajo para productos manufacturados.

1. Por rama de fabricación.
2. Por sucursal individual.

Transferir de la rama fuente – Generar sugerencias de transferencia de una sucursal determinada a otras sucursales.

A continuación se especifica el “pedido sugerido a” entre las siguientes opciones:

1. Mínimo: sugiere pedidos "hasta" la cantidad mínima disponible ("min"). Para cualquier artículo cuyo suministro sea inferior al mínimo, BisTrack sugerirá un pedido para reponer hasta esta cantidad.
2. Máximo cuando es inferior al mínimo: sugiere pedidos “hasta” una cantidad máxima disponible cuando se incumple la cantidad mínima disponible (por ejemplo, una política de inventario mínimo-máximo).

3. Basado en cobertura (uso): sugiere pedidos basados en la cobertura para un número de semanas de suministro definido por el usuario con respecto a un plazo de entrega específico. Dado interno uso Según la demanda, BisTrack recomendará pedidos donde la oferta sea menor que la cobertura deseada para cubrir la diferencia.

4. Basado en exceso (ventas): sugiere pedidos basados en la cobertura para un número de semanas de suministro definido por el usuario con respecto a un plazo de entrega específico. Dado ordenes de venta Según la demanda, BisTrack recomendará pedidos donde la oferta sea menor que la cobertura deseada para cubrir la diferencia.

5. Solo máximo: sugiere pedidos “hasta” una cantidad máxima disponible donde el suministro es menor que este máximo.

Finalmente, si permite que BisTrack determine los umbrales de reorden, los usuarios pueden especificar una cobertura de inventario adicional como stock de reserva, tiempos de entrega, cuántos meses de demanda histórica considerar y también pueden definir manualmente esquemas de ponderación período por período para aproximar la estacionalidad. El usuario recibirá una lista de pedidos sugeridos según los criterios definidos. Luego, un comprador puede generar órdenes de compra para proveedores con solo hacer clic en un botón.

Limitaciones

Métodos de regla general

Si bien BisTrack permite a las organizaciones generar puntos de reorden automáticamente, estos métodos se basan en promedios simples que no capturan la estacionalidad, las tendencias o la volatilidad en la demanda de un artículo. Los promedios siempre estarán por detrás de estos patrones y no pueden captar las tendencias. Considere un producto altamente estacional como una pala quitanieves: si tomamos un promedio de la demanda de verano/otoño a medida que nos acercamos a la temporada de invierno en lugar de mirar hacia adelante, entonces las recomendaciones se basarán en los períodos más lentos en lugar de anticipar la demanda futura. Incluso si consideramos un año entero de historia o más, las recomendaciones compensarán en exceso durante los meses más lentos y subestimarán la temporada alta sin intervención manual.

Los métodos de regla general también fallan cuando se utilizan para amortiguar la variabilidad de la oferta y la demanda. Por ejemplo, la demanda promedio durante el plazo de entrega podría ser de 20 unidades. Sin embargo, un planificador a menudo querrá almacenar más de 20 unidades para evitar desabastecerse si los plazos de entrega son más largos de lo esperado o la demanda es mayor que el promedio. BisTrack permite a los usuarios especificar los puntos de reorden en función de múltiplos de los promedios. Sin embargo, debido a que los múltiplos no tienen en cuenta el nivel de previsibilidad y variabilidad de la demanda, siempre tendrá un exceso de existencias de artículos predecibles y una falta de existencias de los impredecibles. Lee esto artículo para obtener más información sobre por qué múltiplos del promedio fallan cuando se trata de desarrollar el punto de reorden correcto.

Entrada manual
Hablando de la estacionalidad mencionada anteriormente, BisTrack permite al usuario aproximarla mediante el uso de "pesos" ingresados manualmente para cada período. Esto obliga al usuario a decidir cómo será ese patrón estacional para cada artículo. Incluso más allá de eso, el usuario debe dictar cuántas semanas adicionales de suministro debe llevar para protegerse contra desabastecimientos. y debe especificar el plazo de entrega para planificar. ¿Es suficiente un suministro adicional de 2 semanas? ¿Es suficiente con 3? ¿O es demasiado? No hay forma de saberlo sin adivinar, y lo que tiene sentido para un elemento puede no ser el enfoque correcto para todos.

Demanda intermitente
Muchos clientes de BisTrack pueden considerar ciertos elementos "impredecibles" debido a la intermitente o “grumosos” de su demanda. En otras palabras, artículos que se caracterizan por una demanda esporádica, grandes picos de demanda y períodos de poca o ninguna demanda. Los métodos tradicionales, y especialmente los enfoques empíricos, no funcionarán para este tipo de artículos. Por ejemplo, 2 semanas adicionales de suministro para un artículo estable y altamente predecible podría ser demasiado; para un artículo con una demanda muy volátil, esta misma regla podría no ser suficiente. Sin una forma confiable de evaluar objetivamente esta volatilidad para cada artículo, los compradores se quedan sin saber cuándo comprar y cuánto.

Volver a hojas de cálculo
La realidad es que la mayoría de los usuarios de BisTrack tienden a realizar la mayor parte de su planificación fuera de línea, en Excel. Las hojas de cálculo no están diseñadas específicamente para realizar pronósticos y optimizar el inventario. Los usuarios a menudo utilizan métodos definidos por el usuario. regla de oro inventadas por el usuario, métodos que a menudo hacen más daño que bien. Una vez calculado, los usuarios deben ingresar la información nuevamente en BisTrack manualmente. La naturaleza lenta del proceso lleva a las empresas a calcular sus políticas de inventario con poca frecuencia. Pasan muchos meses y, en ocasiones, años entre actualizaciones masivas, lo que lleva a un enfoque reactivo de "configúrelo y olvídese", donde el único momento en que un comprador/planificador revisa la política de inventario es en el momento de realizar el pedido. Cuando las políticas se revisan después de que ya se haya incumplido el punto de orden, ya es demasiado tarde. Cuando el punto de orden se considera demasiado alto, se requiere una interrogación manual para revisar el historial, calcular pronósticos, evaluar las posiciones del buffer y recalibrar. El gran volumen de pedidos significa que los compradores simplemente liberarán los pedidos en lugar de tomarse el minucioso tiempo de revisarlo todo, lo que genera un importante exceso de existencias. Si el punto de reorden es demasiado bajo, ya es demasiado tarde. Ahora puede ser necesaria una aceleración, lo que aumentará los costos, suponiendo que el cliente no se vaya simplemente a otra parte.

Epicor es más inteligente
Epicor se ha asociado con Smart Software y ofrece Smart IP&O como un complemento multiplataforma para sus soluciones ERP, incluido BisTrack, un ERP especializado para la industria de la madera, el hardware y los materiales de construcción. La solución Smart IP&O viene completa con una integración bidireccional con BisTrack. Esto permite a los clientes de Epicor aprovechar las mejores aplicaciones de optimización de inventario diseñadas específicamente para su propósito. Con Epicor Smart IP&O puede generar pronósticos que capturen tendencias y estacionales sin configuraciones manuales. Podrá recalibrar automáticamente las políticas de inventario utilizando modelos estadísticos y probabilísticos de vanguardia probados en el campo que fueron diseñados para planificar con precisión demanda intermitente. Las existencias de seguridad tendrán en cuenta con precisión la variabilidad de la oferta y la demanda, las condiciones comerciales y las prioridades. Puedes aprovechar la planificación impulsada por el nivel de servicio para que tenga suficiente stock o activar métodos de optimización que prescriben las políticas de almacenamiento y niveles de servicio más rentables que consideran el costo real de mantener el inventario. Puede respaldar las compras de materias primas con pronósticos precisos de la demanda en horizontes más largos y ejecutar escenarios hipotéticos para evaluar estrategias alternativas antes de ejecutar el plan.

Los clientes inteligentes de IP&O obtienen habitualmente rendimientos anuales de siete cifras gracias a la reducción de los plazos, el aumento de las ventas y el menor exceso de existencias, al mismo tiempo que obtienen una ventaja competitiva al diferenciarse por un mejor servicio al cliente. Para ver un seminario web grabado organizado por el Grupo de Usuarios de Epicor que describe la plataforma de optimización de inventario y planificación de la demanda de Smart, por favor regístrese aquí.

¿Se considera el stock de seguridad como repuestos de emergencia o como un amortiguador diario contra picos en la demanda? Conocer la diferencia y configurar su ERP correctamente marcará una gran diferencia en sus resultados.

Él Stock de seguridad campo en tu ERP sistema puede significar cosas muy diferentes dependiendo de la configuración. No comprender estas diferencias y cómo afectan sus resultados es un problema común que hemos visto surgir en las implementaciones de nuestro software.

La implementación del software de optimización de inventario comienza cuando los nuevos clientes completan la implementación técnica para que los datos fluyan. Luego reciben capacitación de usuarios y pasan semanas configurando cuidadosamente sus existencias de seguridad iniciales, niveles de reorden y pronósticos de demanda de consenso con Smart IP&O. El equipo se siente cómodo con las predicciones de rendimiento clave (KPP) de Smart para los niveles de servicio, los costos de pedido y el inventario disponible, todo lo cual se pronostica utilizando las nuevas políticas de almacenamiento.

Pero cuando guardan las políticas y los pronósticos en su sistema de prueba ERP, a veces los pedidos sugeridos son mucho más grandes y más frecuentes de lo que esperaban, lo que aumenta los costos de inventario proyectados.

Cuando esto sucede, el principal culpable es cómo está configurado el ERP para tratar el stock de seguridad. Estar al tanto de estos ajustes de configuración ayudará a los equipos de planificación a establecer mejor las expectativas y lograr los resultados esperados con menos esfuerzo (¡y motivo de alarma!).

Estos son los tres ejemplos comunes de configuraciones de inventario de seguridad de ERP:

Configuración 1. El inventario de seguridad se trata como stock de emergencia que no se puede consumir. Si se pronostica un incumplimiento del stock de seguridad, el sistema ERP forzará una aceleración sin importar el costo para que el inventario disponible nunca caiga por debajo del stock de seguridad, incluso si ya se ha pedido un recibo programado y está programado para llegar pronto.

Configuración 2. El inventario de seguridad se trata como Reserva de estabilización que está diseñado para ser consumido. El sistema ERP colocará un pedido cuando se pronostique un incumplimiento del stock de seguridad, pero se permitirá que el inventario disponible caiga por debajo del stock de seguridad. La reserva de reserva protege contra el desabastecimiento durante el período de reabastecimiento (es decir, el tiempo de entrega).

Configuración 3. El sistema ignora el inventario de seguridad y lo trata como un indicador visual. ayuda de planificación o regla empírica. Los cálculos de planificación de suministro lo ignoran, pero el planificador lo utiliza para ayudar a realizar evaluaciones manuales de cuándo hacer un pedido.

Nota: Nunca recomendamos usar el campo de inventario de seguridad como se describe en la Configuración 3. En la mayoría de los casos, estas configuraciones no fueron intencionadas sino que son el resultado de años de improvisación que han llevado a usar el ERP de una manera no estándar. En general, estos campos se diseñaron para influir mediante programación en los cálculos de reposición. Entonces, el foco de nuestra conversación estará en las Configuraciones 1 y 2. 

Los sistemas de optimización de inventario y pronóstico están diseñados para calcular pronósticos que anticiparán la reducción del inventario y luego calcularán las existencias de seguridad suficientes para proteger contra la variabilidad en la demanda y el suministro. Esto significa que el stock de seguridad está destinado a ser utilizado como tampón protector (Configuración 2) y no como emergencia escasa (Configuración 3). También es importante entender que, por diseño, el inventario de seguridad será consumido aproximadamente 50% de la época.

¿Por qué 50%? Porque los pedidos reales superarán un pronóstico imparcial la mitad de las veces. Vea el gráfico a continuación que ilustra esto. Un pronóstico "bueno" debe arrojar el valor que se acercará más al real con mayor frecuencia, de modo que la demanda real sea mayor o menor sin sesgo en ninguna dirección.

Si configuró su sistema ERP para permitir correctamente el consumo de existencias de seguridad, entonces el inventario disponible podría verse como el gráfico a continuación. Tenga en cuenta que se consume algo de stock de seguridad, pero se evita un desabastecimiento. El nivel de servicio al que se dirige al calcular el stock de seguridad determinará la frecuencia con la que se agota el stock antes de que llegue la orden de reposición. El inventario promedio es de aproximadamente 60 unidades durante el horizonte de tiempo en este escenario.

Si su sistema ERP está configurado para no permita el consumo de existencias de seguridad y trate la cantidad ingresada en el campo de existencias de seguridad más como repuestos de emergencia, ¡entonces tendrá un exceso de existencias masivo! Su inventario disponible se vería como el gráfico a continuación con pedidos acelerados tan pronto como se espera una violación del stock de seguridad. El inventario promedio es de aproximadamente 90 unidades, un aumento de 50% en comparación con cuando permitió que se consumiera el stock de seguridad.

Recientemente nos reunimos con el equipo de TI de uno de nuestros clientes para analizar los requisitos de datos y la instalación de nuestra integración basada en API que extraería datos de la instalación local de su sistema ERP. Tanto el gerente de TI como el analista expresaron una gran preocupación por proporcionar estos datos y cuestionaron seriamente por qué era necesario proporcionarlos. Incluso expresaron su preocupación de que sus datos pudieran ser revendidos a su competencia. Su reacción fue una gran sorpresa para nosotros. Escribimos este blog pensando en ellos y para que sea más fácil para otros comunicar por qué ciertos datos son necesarios para respaldar un proceso de planificación de la demanda eficaz. 

Tenga en cuenta que si es analista de pronósticos, planificador de demanda o profesional de la cadena de suministro, la mayor parte de lo que leerá a continuación será obvio. Pero lo que esta reunión me enseñó es que lo que es obvio para un grupo de especialistas no será obvio para otro grupo de especialistas en un campo completamente diferente. 

Los cuatro tipos principales de datos que se necesitan son:  

1. Transacciones históricas, como órdenes de venta y envíos.
2. transacciones de uso de trabajo, como qué componentes se necesitan para producir productos terminados
3. Transacciones de transferencia de inventario, como qué inventario se envió de un lugar a otro.
4. Precios, costos y atributos, como el costo unitario pagado al proveedor, el precio unitario pagado por el cliente y varios metadatos como la familia de productos, la clase, etc.  

A continuación, se incluye una breve explicación de por qué se necesitan estos datos para respaldar la implementación del software de planificación de la demanda de una empresa.

Registros transaccionales de ventas históricas y envíos por cliente
Piense en lo que se extrajo del inventario como la "materia prima" requerida por el software de planificación de la demanda. Esto puede ser lo que se vendió a quién y cuándo o lo que envió a quién y cuándo. O qué materias primas o subensamblajes se consumieron en las órdenes de trabajo y cuándo. O qué se suministra a un almacén satélite desde un centro de distribución y cuándo.

El software analiza el historial de estas transacciones y lo utiliza para producir pronósticos estadísticos que extrapolan los patrones observados. Los datos se evalúan para descubrir patrones como tendencia, estacionalidad, patrones cíclicos e identificar posibles valores atípicos que requieren atención comercial. Si estos datos no son generalmente accesibles o no se actualizan en intervalos irregulares, entonces es casi imposible crear una buena predicción de la demanda futura. Sí, podría usar el conocimiento comercial o la intuición, pero eso no escala y casi siempre introduce un sesgo en el pronóstico (es decir, pronostica constantemente demasiado alto o demasiado bajo). 

Se necesitan datos a nivel transaccional para respaldar pronósticos más detallados a nivel semanal o incluso diario. Por ejemplo, cuando una empresa entra en su temporada alta, es posible que desee comenzar a realizar pronósticos semanales para alinear mejor la producción con la demanda. No puede hacerlo fácilmente sin tener los datos transaccionales en un almacén de datos bien estructurado. 

También podría darse el caso de que ciertos tipos de transacciones no deban incluirse en los datos de demanda. Esto puede suceder cuando la demanda resulta de un gran descuento o alguna otra circunstancia que el equipo de la cadena de suministro sabe que sesgará los resultados. Si los datos se proporcionan en conjunto, es mucho más difícil segregar estas excepciones. En Smart Software, llamamos al proceso de averiguar qué transacciones (y los atributos transaccionales asociados) deben contarse en la señal de demanda como "composición de la señal de demanda". Tener acceso a todas las transacciones permite a una empresa modificar su señal de demanda según sea necesario a lo largo del tiempo dentro del software. Solo proporcionar algunos de los datos da como resultado una composición de demanda mucho más rígida que solo puede remediarse con trabajo de implementación adicional.

Precios y Costos
El precio por el que vendió sus productos y el costo que pagó para adquirirlos (o materias primas) es fundamental para poder pronosticar los ingresos o los costos. Una parte importante del proceso de planificación de la demanda es obtener conocimiento comercial de los clientes y los equipos de ventas. Los equipos de ventas tienden a pensar en la demanda por categoría de producto o cliente y hablan el lenguaje de los dólares. Por lo tanto, es importante expresar un pronóstico en dólares. El sistema de planificación de la demanda no puede hacer eso si el pronóstico se muestra solo en unidades. 

A menudo, la previsión de la demanda se utiliza para impulsar o al menos influir en un proceso de planificación y elaboración de presupuestos más amplio y la entrada clave para un presupuesto es una previsión de ingresos. Cuando se utilizan pronósticos de demanda para respaldar el proceso de ventas y operaciones, el software de planificación de la demanda debe promediar el precio de todas las transacciones o aplicar conversiones "por fases" que consideren el precio vendido en ese momento. Sin los datos sin procesar sobre precios y costos, el proceso de planificación de la demanda aún puede funcionar, pero se verá gravemente afectado. 

Atributos del producto, detalles del cliente y ubicaciones
Los atributos del producto son necesarios para que los pronosticadores puedan agregar pronósticos a través de diferentes familias de productos, grupos, códigos de productos básicos, etc. Es útil saber cuántas unidades y la demanda dolarizada total proyectada para las diferentes categorías. A menudo, el conocimiento comercial sobre cuál podría ser la demanda en el futuro no se conoce a nivel de producto, pero se conoce a nivel de familia de productos, nivel de cliente o nivel regional. Con la adición de atributos de producto a su feed de datos de planificación de la demanda, puede "resumir" fácilmente los pronósticos desde el nivel de artículo hasta el nivel de familia. Puede convertir pronósticos en estos niveles a dólares y colaborar mejor sobre cómo se debe modificar el pronóstico.  

Una vez que se aplica el conocimiento en forma de anulación de pronóstico, el software conciliará automáticamente el cambio con todos los elementos individuales que componen el grupo. De esta forma, un analista de pronósticos no tiene que ajustar individualmente cada parte. Pueden hacer un cambio a nivel agregado y dejar que el software de planificación de la demanda haga la reconciliación por ellos. 

La agrupación para facilitar el análisis también se aplica a los atributos del cliente, como el vendedor asignado o la ubicación de envío preferida del cliente. Y los atributos de ubicación pueden ser útiles, como la región asignada. A veces, los atributos se relacionan con una combinación de producto y ubicación, como proveedor preferido o planificador asignado, que pueden diferir para el mismo producto según el almacén.

Una nota final sobre la confidencialidad

Recuerde que nuestro cliente expresó su preocupación de que pudiéramos vender sus datos a un competidor. Nunca haríamos eso. Durante décadas, hemos utilizado los datos de los clientes con fines formativos y para mejorar nuestros productos. Somos escrupulosos a la hora de salvaguardar los datos de los clientes y anonimizar cualquier cosa que pueda usarse, por ejemplo, para ilustrar un punto en una publicación de blog.

“A pesar de lo que has visto en tus caricaturas de los sábados por la mañana, los elefantes no pueden saltar, y hay una razón simple: no tienen que hacerlo. La mayoría de los animales nerviosos (canguros, monos y ranas) lo hacen principalmente para alejarse de los depredadores”. — Patrick Monahan, Science.org, 27 de enero de 2016.

Ahora sabe por qué las empresas de ERP más grandes no pueden desarrollar las mejores soluciones de alta calidad. Nunca tuvieron que hacerlo, por lo que nunca evolucionaron para innovar fuera de su enfoque principal. 

Sin embargo, a medida que los sistemas ERP se convirtieron en productos básicos, las brechas en su funcionalidad se volvieron imposibles de ignorar. Los jugadores más grandes buscaron proteger su parte de la cartera de los clientes prometiendo desarrollar aplicaciones complementarias innovadoras para llenar todos los espacios en blanco. Pero sin ese “músculo de la innovación”, muchos proyectos fracasaron y se acumularon montañas de deuda técnica.

Las mejores empresas de su clase evolucionaron para innovar y tener una profunda experiencia funcional en verticales específicos. El resultado es que los mejores complementos de ERP son más fáciles de usar, tienen más funciones y ofrecen más valor que los módulos de ERP nativos que reemplazan. 

Si su proveedor de ERP ya se ha asociado con un innovador proveedor de complementos*, ¡ya está listo! Pero si solo puede obtener lo básico de su ERP, opte por un complemento de primera clase que tenga una integración personalizada con el ERP. 

Un excelente lugar para comenzar su búsqueda es buscar complementos de planificación de la demanda de ERP que agreguen inteligencia a la fuerza del ERP, es decir, aquellos que respaldan la optimización del inventario y la previsión de la demanda. Aproveche las herramientas complementarias como las aplicaciones de pronóstico estadístico, planificación de la demanda y optimización de inventario de Smart para desarrollar pronósticos y políticas de almacenamiento que se retroalimentan al sistema ERP para impulsar los pedidos diarios. 

*Las tiendas de aplicaciones son una licencia para que lo mejor de su clase venda en la base de empresas de ERP, siendo sociedades cotizadas.

La verificación y validación de datos son esenciales para el éxito de la implementación de software que realiza análisis estadísticos de datos, como Smart IP&O. Este artículo describe el problema y sirve como una guía práctica para hacer el trabajo correctamente, especialmente para el usuario de la nueva aplicación.

Cuanta menos experiencia tenga su organización en la validación de transacciones históricas o atributos maestros de artículos, más probable es que haya problemas o errores con la entrada de datos en el ERP que hasta ahora han pasado desapercibidos. La regla de basura que entra, basura que sale significa que debe priorizar este paso del proceso de incorporación del software o correr el riesgo de demoras y posibles fallas en la generación de retorno de la inversión.

En última instancia, la mejor persona para confirmar que los datos en su ERP se ingresan correctamente es la persona que conoce el negocio y puede afirmar, por ejemplo, "esta parte no pertenece a ese grupo de productos". Esa suele ser la misma persona que abrirá y usará Smart. Aunque un administrador de base de datos o soporte de TI también puede desempeñar un papel clave al poder decir: "Esta parte fue asignada a ese grupo de productos en diciembre pasado por Jane Smith". Asegurarse de que los datos sean correctos puede no ser una parte habitual de su trabajo diario, pero se puede dividir en pequeñas tareas manejables para las que un buen director de proyectos asignará el tiempo y los recursos para completar.

El proveedor del software de planificación de la demanda que recibe los datos también tiene una función. Confirmarán que los datos sin procesar se ingirieron sin problemas. El proveedor también puede identificar anomalías en los archivos de datos sin procesar que apuntan a la necesidad de validación. Pero confiar en el proveedor de software para asegurarle que los datos se ven bien no es suficiente. No desea descubrir, después de la puesta en marcha, que no puede confiar en la salida porque algunos de los datos "no tienen sentido".

Cada paso en el flujo de datos necesita verificación y validación.  La verificación significa que los datos en un paso siguen siendo los mismos después de pasar al siguiente paso. La validación significa que los datos son correctos y utilizables para el análisis. 

El flujo de datos más común se ve así:

Con menos frecuencia, el primer paso entre los datos maestros de ERP y los archivos de interfaz a veces se puede omitir, donde los archivos no se utilizan como interfaz. En cambio, una API creada por TI o el proveedor de software de optimización de inventario es responsable de que los datos se escriban directamente desde el ERP a la base de datos reflejada en la nube. El proveedor trabajaría con TI para confirmar que la API funciona como se esperaba. Pero el primer paso de validación, incluso en ese caso, todavía se puede realizar. Después de ingerir los datos, el proveedor puede hacer que los datos reflejados estén disponibles en archivos para la verificación de DBA/TI y la validación comercial.

La confirmación de que los datos duplicados en la nube completan el flujo hacia la aplicación es responsabilidad del proveedor del software como servicio. Los proveedores de SaaS prueban continuamente que el software funcione correctamente entre la aplicación de front-end que ven sus suscriptores y los datos de back-end en la base de datos en la nube. Si los suscriptores todavía piensan que los datos no tienen sentido en la aplicación incluso después de validar los archivos de interfaz antes de ponerlos en marcha, ese es un problema que se debe plantear con el servicio de atención al cliente del proveedor.

Independientemente de cómo se obtengan los archivos de interfaz, la mayor parte de la verificación y validación recae en el director del proyecto y su equipo. Deben realizar una prueba de los archivos de interfaz para confirmar:

1. Coinciden con los datos del ERP. Y que se extrajeron todos y solo los datos del ERP que era necesario extraer para su uso en la aplicación.
2. Nada “salta” a la empresa como incorrecto para cada uno de los tipos de información en los datos
3. Están formateados como se esperaba.

Tareas de verificación de DBA/TI

1. Probar el extracto:

El paso de verificación de TI se puede realizar con varias herramientas, comparando archivos o importando archivos a la base de datos como tablas temporales y uniéndolos con los datos originales para confirmar una coincidencia. TI puede depender de una consulta para extraer los datos solicitados en un archivo, pero ese archivo puede no coincidir. La existencia de delimitadores o retornos de línea dentro de los valores de datos puede hacer que un archivo sea diferente de su tabla de base de datos original. Esto se debe a que el archivo se basa en gran medida en delimitadores y retornos de línea para identificar campos y registros, mientras que la tabla no se basa en esos caracteres para definir su estructura.

2. Sin malos personajes:

Los campos de entrada de datos de forma libre en el ERP, como las descripciones de productos, a veces pueden contener retornos de línea, tabuladores, comas y/o comillas dobles que pueden afectar la estructura del archivo de salida. No se deben permitir retornos de línea en valores que se extraerán a un archivo. Los caracteres iguales al delimitador se deben eliminar durante la extracción o, de lo contrario, se debe usar un delimitador diferente.

Consejo: si las comas son el delimitador de archivo, los números superiores a 999 no se pueden extraer con una coma. Use "1000" en lugar de "1,000".

3. Confirmar los filtros:

La otra forma en que los extractos de consulta pueden arrojar resultados inesperados es si las condiciones de la consulta se ingresan incorrectamente. La forma más sencilla de evitar las cláusulas "where" erróneas es no usarlas. Extraiga todos los datos y permita que el proveedor filtre algunos registros de acuerdo con las reglas proporcionadas por la empresa. Si esto produce archivos de extracción tan grandes que se dedica demasiado tiempo informático al intercambio de datos, el equipo de DBA/TI debe reunirse con la empresa para confirmar exactamente qué filtros en los datos se pueden aplicar para evitar el intercambio de registros que no tienen sentido para el solicitud.

Consejo: Tenga en cuenta que la información de activo/inactivo o del ciclo de vida del elemento no debe utilizarse para filtrar registros. Esta información debe enviarse a la aplicación para que sepa cuándo un elemento se vuelve inactivo.

4. Se consistente:

El proceso de extracción debe producir archivos de formato consistente cada vez que se ejecuta. Los nombres de archivo, los nombres de campo y la posición, el delimitador y el nombre de la hoja de Excel si se usa Excel, los formatos numéricos y los formatos de fecha, y el uso de comillas alrededor de los valores nunca deben diferir de una ejecución del extracto de un día a otro. Se debe preparar y utilizar un informe de no intervención o un procedimiento almacenado para cada ejecución del extracto.

Fondo de validación comercial

A continuación se desglosa cada paso de validación en consideraciones, específicamente en el caso en que el proveedor haya proporcionado un formato de plantilla para los archivos de interfaz donde cada tipo de información se proporciona en su propio archivo. Los archivos enviados desde su ERP a Smart están formateados para exportarlos fácilmente desde el ERP. Ese tipo de formato hace que la comparación con el ERP sea un trabajo relativamente simple para TI, pero puede ser más difícil de interpretar para el negocio. La mejor práctica es manipular los datos del ERP, ya sea mediante el uso de tablas dinámicas o similar en una hoja de cálculo. TI puede ayudar proporcionando archivos de datos reformateados para que la empresa los revise.

Para profundizar en los archivos de interfaz, deberá comprenderlos. El proveedor proporcionará una plantilla precisa, pero generalmente los archivos de interfaz consisten en tres tipos: datos de catálogo, atributos de artículos y datos transaccionales.

• Los datos del catálogo contienen identificadores y sus atributos. Los identificadores suelen ser para productos, ubicaciones (que podrían ser plantas o almacenes), sus clientes y sus proveedores.
• Los atributos de artículo contienen información sobre productos en ubicaciones que se necesitan para el análisis de la combinación de producto y ubicación. Tal como:
  • Política de reabastecimiento actual en forma de mínimo y máximo, punto de reorden o período de revisión y orden hasta el valor o stock de seguridad
  • Asignación de proveedor principal y tiempo de entrega nominal y costo por unidad de ese proveedor
  • Requisitos de cantidad de pedido, como cantidad mínima de pedido, tamaño de lote de fabricación o múltiplos de pedido
  • Estado activo/inactivo de la combinación de producto/ubicación o indicadores que identifican su estado en su ciclo de vida, como pre-obsoleto
  • Atributos para agrupar o filtrar, como comprador/planificador asignado o categoría de producto
  • Información de inventario actual, como cantidades disponibles, en pedido y en tránsito.
• Los datos transaccionales contienen referencias a identificadores junto con fechas y cantidades. Como la cantidad vendida en una orden de venta de un producto, en una ubicación, para un cliente, en una fecha. O la cantidad colocada en la orden de compra de un producto, en una ubicación, de un proveedor, en una fecha. O la cantidad utilizada en una orden de trabajo de un producto componente en una ubicación en una fecha.

Validación de datos del catálogo

Teniendo en cuenta primero los datos del catálogo, es posible que tenga archivos de catálogo similares a estos ejemplos:

1: Comprobar un recuento razonable de registros de catálogo

Para cada archivo de datos del catálogo, ábralo en una herramienta de hoja de cálculo como Hojas de cálculo de Google o MS Excel. Responde estas preguntas:

1. ¿Está el récord en el estadio de béisbol? Si tiene alrededor de 50 000 productos, no debería haber solo 10 000 filas en su archivo.
2. Si es un archivo corto, tal vez el archivo de ubicación, puede confirmar exactamente que todos los Iidentificadores esperados están en él.
3. Filtre por cada valor de atributo y confirme nuevamente que el recuento de registros con ese valor de atributo tenga sentido.

2: Comprobar la exactitud de los valores en cada campo de atributo

Alguien que sepa cuáles son los productos y qué significan los grupos necesita tomarse el tiempo para confirmar que realmente es correcto, para todos los atributos de todos los datos del catálogo.

Por lo tanto, si su archivo de producto contiene los atributos como en el ejemplo anterior, filtraría por Estado de activo y verificaría que todos los productos resultantes estén realmente activos. Luego filtre por Estado de Inactivo y verifique que todos los productos resultantes estén realmente inactivos. Luego filtre por el primer valor de Grupo y confirme que todos los productos resultantes estén en ese grupo. Repita para Group2 y Group3, etc. Luego repita para cada atributo en cada archivo.

Puede ayudar hacer esta validación con una comparación con un informe ya existente y confiable. Si tiene otra hoja de cálculo que muestra productos por grupo por cualquier motivo, puede comparar los archivos de interfaz con ella. Es posible que deba familiarizarse con la función BUSCARV que ayuda con la comparación de hojas de cálculo.

Validación de datos de atributos de artículos

1: Comprobar un recuento razonable de registros de artículos

La confirmación de los datos de los atributos del artículo es similar a los datos del catálogo. Confirme que el conteo de combinación de producto/ubicación tenga sentido en total y para cada uno de los atributos únicos del artículo, uno por uno. Este es un archivo de datos de elementos de ejemplo:

2: Encuentra y explica números raros en el archivo del artículo

Suele haber muchos valores numéricos en los atributos del artículo, por lo que los números "raros" merecen una revisión. Para validar los datos de un atributo numérico en cualquier archivo, busque dónde está el número:

• falta por completo
• igual a cero
• Menos que cero
• Más que la mayoría de los demás, o menos que la mayoría de los demás (ordenar por esa columna)
• No es un número en absoluto, cuando debería ser

Una consideración especial de los archivos que no son archivos de catálogo es que es posible que no muestren las descripciones de los productos y ubicaciones, solo sus identificadores, lo que puede no tener sentido para usted. Puede insertar columnas para contener los descriptores de productos y ubicaciones que está acostumbrado a ver y completarlos en la hoja de cálculo para ayudarlo en su trabajo. La función BUSCARV también funciona para esto. Ya sea que tenga o no otro informe para comparar el archivo de artículos, tiene los archivos de catálogo para productos y ubicación que muestran tanto el identificador como la descripción de cada fila.

3: Verificación al azar

Si le frustra descubrir que hay demasiados valores de atributo para verificar manualmente en un período de tiempo razonable, la verificación puntual es una solución. Se puede hacer de una manera que pueda detectar cualquier problema. Para cada atributo, obtenga una lista de los valores únicos en cada columna. Puede copiar una columna en una hoja nueva y luego usar la función Eliminar duplicados para ver la lista de valores posibles. Con eso:

1. Confirme que no hay valores de atributos presentes que no deberían estar presentes.
2. Puede ser más difícil recordar qué valores de atributo faltan que deberían estar allí, por lo que puede ser útil buscar otra fuente para recordarlo. Por ejemplo, si están presentes los grupos 1 a 12, puede consultar otra fuente para recordar si estos son todos los grupos posibles. Incluso si no se requiere para los archivos de interfaz para la aplicación, puede ser fácil para TI extraer una lista de todos los grupos posibles que están en su ERP que puede usar para el ejercicio de validación. Si encuentra valores adicionales o faltantes que no espera, lleve un ejemplo de cada uno a TI para investigar.
3. Ordene alfabéticamente y explore hacia abajo para ver si dos valores son similares pero ligeramente diferentes, tal vez solo en la puntuación, lo que podría significar que un registro tenía los datos del atributo ingresados incorrectamente.

Para cada tipo de artículo, tal vez uno de cada grupo de productos y/o ubicación, verifique que todos sus atributos en cada archivo sean correctos o al menos pase una verificación de cordura. Cuanto más pueda verificar al azar de una amplia gama de elementos, es menos probable que tenga problemas después de la puesta en marcha.

Validación de datos transaccionales

Todos los archivos transaccionales pueden tener un formato similar a este:

1: Encuentra y explica números extraños en cada archivo transaccional

Estos deben verificarse en busca de números "raros" en el campo Cantidad. Luego puede proceder a:

1. Filtre las fechas fuera del rango que espera o las que faltan por completo.
2. Encuentre dónde faltan los identificadores de transacción y los números de línea. No deberían serlo.
3. Si hay más de un registro para una determinada combinación de ID de transacción y número de línea de transacción, ¿es un error? Dicho de otra manera, ¿deberían sumarse las cantidades de los registros duplicados o se trata de una doble contabilización?

2: Cantidades sumadas de verificación de cordura

Realice una verificación de cordura filtrando a un producto en particular con el que esté familiarizado, y filtre a un rango de fechas relacionado, como el mes pasado o el año pasado, y sume las cantidades. ¿Es esa cantidad total lo que esperaba para ese producto en ese período de tiempo? Si tiene información sobre el uso total de una ubicación, puede dividir los datos de esa manera para sumar las cantidades y compararlas con lo que espera. Las tablas dinámicas son útiles para la verificación de datos transaccionales. Con ellos, puede ver los datos como:

El total anual de los productos puede ser fácil de verificar si conoce bien los productos. O puede BUSCARV para agregar atributos, como un grupo de productos, y pivotar sobre eso para ver un nivel superior que le resulte más familiar:

3: Conteo de verificación de cordura de los registros

Puede ser útil mostrar un recuento de transacciones en lugar de una suma de cantidades, especialmente para datos de órdenes de compra. Tal como:

Y/o el mismo resumen en un nivel superior, como:

4: Comprobación puntual

La verificación puntual de la corrección de una sola transacción, para cada tipo de artículo y cada tipo de transacción, completa la diligencia debida. Preste especial atención a qué fecha está vinculada a la transacción y si es adecuada para el análisis. Las fechas pueden ser una fecha de creación, como la fecha en que un cliente le hizo un pedido, o una fecha de promesa, como la fecha en que esperaba entregar el pedido del cliente en el momento de crearlo, o una fecha de cumplimiento, cuando realmente entregó en el orden. A veces, una fecha prometida se modifica días después de crear el pedido si no se puede cumplir. Asegúrese de que la fecha de uso refleje más fielmente la demanda real del producto por parte del cliente.

Qué hacer con los datos incorrectos 

Si las entradas erróneas son pocas o únicas, puede editar los registros de ERP a mano a medida que se encuentran, limpiando los atributos de su catálogo, incluso después de la puesta en marcha de la aplicación. Pero si grandes franjas de atributos o cantidades de transacciones están desactivadas, esto puede impulsar un proyecto interno para volver a ingresar los datos correctamente y posiblemente cambiar o comenzar a documentar el proceso que debe seguirse cuando se ingresan nuevos registros en su ERP.

Se debe tener cuidado para evitar un retraso demasiado prolongado en la implementación de la aplicación SaaS mientras se esperan atributos limpios. Divida el trabajo en partes y use la aplicación para analizar primero los datos limpios, de modo que el proyecto de limpieza de datos ocurra en paralelo con la obtención de valor de la nueva aplicación.

Microsoft Dynamics 365 F&SC y AX pueden administrar el reabastecimiento al sugerir qué ordenar y cuándo a través de políticas de inventario basadas en puntos de reorden. Un desafío que enfrentan los clientes es que los esfuerzos para mantener estos niveles están muy orientados a los detalles y que el sistema ERP requiere que el usuario especifique manualmente estos puntos de pedido y/o pronósticos. Como alternativa, muchas organizaciones terminan generando políticas de inventario a mano utilizando hojas de cálculo de Excel u otros enfoques ad hoc.

Estos métodos consumen mucho tiempo y es probable que ambos den como resultado cierto nivel de inexactitud. Como resultado, la organización terminará con un exceso de inventario, escasez innecesaria y una desconfianza general en sus sistemas de software. En este artículo, revisaremos la funcionalidad de pedidos de inventario en AX / D365 F&SC, explicaremos sus limitaciones y resumiremos cómo la Planificación y optimización de inventario inteligente puede ayudar a mejorar la posición de efectivo de una empresa. Esto se logra mediante un inventario reducido y desabastecimientos minimizados y controlados. El uso de Smart Software ofrece una funcionalidad predictiva que falta en Dynamics 365.

Políticas de reabastecimiento de Microsoft Dynamics 365 F&SC y AX

En el módulo de gestión de inventario de AX y F&SC, los usuarios pueden ingresar manualmente los parámetros de planificación para cada artículo en existencia. Estos parámetros incluyen puntos de pedido, plazos de entrega de existencias de seguridad, cantidades de existencias de seguridad, ciclos de reorden y modificadores de pedidos, como cantidades de pedido mínimas y máximas impuestas por el proveedor y múltiplos de pedido. Una vez ingresado, el sistema ERP conciliará el suministro entrante, la disponibilidad actual, la demanda saliente y los pronósticos definidos por el usuario y las políticas de almacenamiento para calcular el plan de suministro o el cronograma de pedidos (es decir, qué ordenar y cuándo).

Hay 4 opciones de política de reposición en F&SC y AX: Cantidad fija de reorden, Cantidad máxima, Lote por lote e Impulsada por pedido del cliente.

• Cantidad de reorden fija y Máx. son métodos de reabastecimiento basados en puntos de pedido. Ambos sugieren pedidos cuando el inventario disponible alcanza el punto de reorden. Con ROQ fijo, el tamaño del pedido se especifica y no variará hasta que se cambie. Con Max, los tamaños de los pedidos variarán según la posición del stock en el momento del pedido y los pedidos se realizarán hasta el Max.
• Lote por lote es un método de reabastecimiento basado en pronósticos que agrupa la demanda total pronosticada durante un marco de tiempo definido por el usuario (el "período de acumulación de lotes") y genera una sugerencia de pedido que totaliza la cantidad pronosticada. Entonces, si su demanda total pronosticada es de 100 unidades por mes y el período de acumulación del lote es de 3 meses, entonces su sugerencia de pedido sería igual a 300 unidades.
• Impulsado por pedidos es un método de reabastecimiento basado en pedidos. No utiliza puntos de pedido ni pronósticos. Piense en ello como una lógica de "vender uno, comprar uno" que solo realiza pedidos después de que se ingresa la demanda.

Limitaciones

Cada una de las configuraciones de reabastecimiento de F&SC / AX debe ingresarse manualmente o importarse a través de cargas personalizadas creadas por los clientes. Simplemente no hay forma de que los usuarios generen entradas de forma nativa (especialmente las que no son óptimas). La falta de una funcionalidad creíble para la previsión a nivel de unidad y la optimización del inventario dentro del sistema ERP es la razón por la que tantos usuarios de AX y F&SC se ven obligados a confiar en hojas de cálculo para la planificación y luego establecer manualmente los parámetros que necesita el ERP. En realidad, la mayoría de los planificadores terminan configurando manualmente las previsiones de demanda y reordenando.

Y cuando pueden usar hojas de cálculo, a menudo se basan en métodos generales generales que dan como resultado el uso de modelos estadísticos simplificados. Una vez calculados en la hoja de cálculo, estos deben cargarse en F&SC/AX. A menudo se cargan a través de engorrosas importaciones de archivos o se ingresan manualmente. Debido al tiempo y esfuerzo que se necesita para construirlos, las empresas no actualizan estos números con frecuencia.

Una vez que se establecen, las organizaciones tienden a emplear un enfoque reactivo a los cambios. La única vez que un comprador/planificador revisa la política de inventario es anualmente o en el momento de las compras o la fabricación. Algunas empresas también reaccionarán después de encontrar problemas con niveles de inventario cortos (o demasiado altos). Gestionar esto en AX y F&AS requiere una interrogación manual para revisar el historial, calcular pronósticos, evaluar las posiciones del búfer y recalibrar.

Microsoft reconoce estas limitaciones en sus ERP centrales y comprende los desafíos importantes para los clientes. En respuesta, Microsoft ha posicionado la previsión bajo su pila de AI Azure. Este método está fuera de los principales ERP. Se ofrece como un conjunto de herramientas para que los científicos de datos lo utilicen para definir estadísticas y cálculos complejos personalizados según los deseos de la empresa. Esto se suma a algunos cálculos simples básicos como punto de partida que se encuentran actualmente en sus fases iniciales de desarrollo. Si bien esto puede generar ganancias a largo plazo, actualmente este método significa que los clientes comienzan casi desde cero y definen lo que Microsoft actualmente llama "experimentos" para medir la planificación de la demanda.

La conclusión es que los clientes se enfrentan a grandes desafíos para conseguir que la pila de Dynamics ayude a resolver estos problemas. El resultado es que los CFO tienen menos efectivo disponible para lo que necesitan y que los ejecutivos de ventas tienen oportunidades de ventas sin cubrir y una posible pérdida de ventas porque la empresa no puede enviar los productos que el cliente desea.

Ser más inteligentes

¿No sería mejor simplemente aprovechar el mejor complemento de su clase para la planificación de la demanda? y la mejor solución de optimización de inventario de su clase para administrar y equilibrar los costos y los niveles de cumplimiento? ¿No sería mejor poder hacer esto diariamente o semanalmente para tomar sus decisiones lo más cerca posible de la necesidad, conservando efectivo mientras satisface la demanda de ventas?

Imagine tener una integración bidireccional con AX y F&AS para que todo funcione fácil y rápidamente. Uno donde:

• podría recalibrar automáticamente las políticas en ciclos de planificación frecuentes utilizando modelos estadísticos de vanguardia probados en el campo,
• podría calcular pronósticos de demanda que tengan en cuenta la estacionalidad, la tendencia y los patrones cíclicos,
• Aprovecharía automáticamente los métodos de optimización que prescriben las políticas de almacenamiento y los niveles de servicio más rentables que consideran los costos reales de mantener el inventario y las interrupciones de existencias, brindándole una imagen económica completa,
• Puede liberar efectivo para usar dentro de la empresa y administrar sus niveles de inventario para mejorar el cumplimiento de pedidos al mismo tiempo que libera este efectivo.
• tendría existencias de seguridad y niveles de inventario que darían cuenta de la variabilidad de la oferta y la demanda, las condiciones comerciales y las prioridades,
• podría apuntar a niveles de servicio específicos por grupos de productos, clientes, almacenes o cualquier otra dimensión que haya seleccionado,
• aumenta las ganancias generales de la empresa y la salud del balance general.

Amplíe Microsoft 365 F&SC y AX con Smart IP&O

Para ver una grabación del seminario web de Microsoft Dynamics Communities que muestra Smart IP&O, regístrese aquí:

https://smartcorp.com/inventory-planning-with-microsoft-365-fsc-and-ax/